새 웹 프로젝트의 프레임워크를 고르는 회의에서 “AI가 이 도구를 잘 다루는가”는 이제 빼기 어려운 질문이 됐다. 화면 초안, API 연동, 반복적인 폼과 목록을 빠르게 만들 수 있기 때문이다. 하지만 요구사항 단계에서 더 먼저 답해야 할 질문은 따로 있다.
AI가 만든 코드를 우리 팀이 어디서 실행되고, 어떤 데이터를 쓰며, 실패하면 어떻게 보이는지 빠르게 설명할 수 있는가.
AI가 작성 시간을 줄일수록 프레임워크의 비용은 코드 입력량보다 맥락 파악, 요구사항 검증, 수정 범위 확인, 운영 중 오류 추적에서 더 크게 드러난다. 따라서 새 프로젝트에는 “AI가 많이 아는 프레임워크”보다 AI가 만든 변경을 팀 규칙과 테스트로 판정하기 쉬운 프레임워크가 더 적합할 수 있다.
이 글의 결론은 특정 제품의 순위가 아니다. 서버와 브라우저의 역할을 강하게 통일해야 하는지, 브라우저 상호작용이 제품의 중심인지, 기존 팀의 기술 기반을 유지해야 하는지에 따라 후보군을 먼저 나누고, 같은 요구사항으로 검증해 선택해야 한다.
프레임워크 선택은 세 가지 프로젝트 조건에서 갈린다
모든 웹 프로젝트에 같은 답을 적용하기는 어렵다. 다만 요구사항 단계에서는 다음 세 조건으로 후보를 크게 좁힐 수 있다.
서버 렌더링과 데이터 경계를 통일해야 하는 프로젝트
콘텐츠 목록, 상세 페이지, 검색 결과, 공개 정보 화면처럼 URL 단위의 화면 흐름이 중요한 서비스라면 서버가 먼저 HTML을 만들고 필요한 데이터를 연결하는 방식이 후보가 될 수 있다. 이 유형에서는 페이지, 데이터 요청, 오류 화면, 권한 확인의 위치를 프레임워크 관례에 맞춰 통일하기 쉽다는 점이 중요하다.
AI가 새 페이지를 만들 때도 팀이 정한 경로를 따르게 만들 수 있다면 검토 범위가 줄어든다. 반대로 서버와 브라우저 어느 쪽에서 데이터를 읽는지 화면마다 달라지면, 같은 기능처럼 보여도 오류 원인과 성능 문제를 추적하기 어려워질 수 있다.
이 유형의 후보를 검증할 때는 다음을 확인해야 한다.
- 목록과 상세 화면의 초기 데이터가 어느 환경에서 읽히는가
- 검색 조건과 필터가 URL, 서버 요청, 브라우저 상태 중 어디에 저장되는가
- 로그인 정보나 권한에 따라 달라지는 화면을 어디에서 판정하는가
- 데이터 요청 실패, 권한 없음, 빈 결과가 각각 다른 화면으로 구분되는가
- AI가 추가한 화면이 기존 데이터 요청 규칙을 어기면 테스트가 이를 잡아내는가
이 조건에서는 기능을 만들 수 있는 선택지의 수보다, 기본 경로를 벗어났을 때 그 예외가 코드와 테스트에서 눈에 띄는지가 더 중요하다.
브라우저 안의 상호작용이 제품의 중심인 프로젝트
편집기, 복잡한 입력 화면, 실시간 상태 변화, 드래그 앤드 드롭, 여러 단계의 작업 흐름처럼 사용자가 브라우저에서 오래 조작하는 제품은 상태 관리 방식을 우선 비교해야 한다. 여기서 상태란 사용자가 입력한 값, 선택한 항목, 저장 전 변경 내용, 현재 작업 단계처럼 화면이 기억해야 하는 정보를 말한다.
이 유형에서 프레임워크를 고를 때는 “상호작용을 풍부하게 만들 수 있는가”만 보면 부족하다. AI가 만든 코드가 상태를 여러 곳에 나누어 저장하거나, 화면마다 다른 방식으로 동기화할 때 어떤 문제가 생기는지 확인해야 한다.
특히 다음 항목을 PoC, 즉 작은 검증용 구현에서 확인할 만하다.
- 같은 정보를 URL, 브라우저 메모리, 서버 응답 중 어디에 둘지 팀이 일관되게 정할 수 있는가
- 뒤로 가기, 새로 고침, 다른 탭 열기에서 사용자의 작업 상태가 요구사항대로 유지되는가
- 저장 실패와 네트워크 지연이 발생했을 때 화면이 어떤 상태인지 사용자가 이해할 수 있는가
- AI가 기능 하나를 추가한 뒤 기존 입력값, 저장 처리, 오류 안내를 깨뜨리지 않는가
- 상태 관련 테스트가 실패했을 때 수정해야 할 코드 범위를 좁힐 수 있는가
브라우저 상호작용이 중심인 제품에서는 자유도가 높은 구조가 유리할 수 있다. 다만 그 자유도는 팀이 상태 위치와 변경 규칙을 미리 정했을 때만 유지보수 가능한 선택지가 된다.
기존 생태계와 팀 숙련도를 우선해야 하는 프로젝트
기존 제품이 이미 특정 프레임워크와 배포 방식, 테스트 도구, 공통 컴포넌트, 운영 절차 위에서 돌아간다면 새 프로젝트도 같은 기반을 선택하는 편이 나을 수 있다. 이것은 기존 기술이 항상 더 좋다는 뜻이 아니다. 장애가 발생했을 때 누가 구조를 읽고, 누가 수정하고, 누가 배포 결과를 확인할 수 있는지가 이미 정해져 있다는 뜻이다.
AI는 낯선 코드의 초안을 만들 수 있다. 그러나 생성된 변경이 조직의 권한 규칙, 디자인 규칙, 배포 절차, 장애 대응 방식과 충돌하는지까지 대신 판단하지는 않는다. 기존 기술 기반을 유지할 때는 새 프레임워크가 주는 작성 편의보다 전환 과정에서 잃는 검증 능력을 먼저 따져야 한다.
이 경우에는 후보별 기능 비교보다 다음 질문이 더 유용하다.
- 현재 팀이 오류 화면과 데이터 요청 흐름을 코드만 보고 추적할 수 있는가
- 기존 테스트가 AI가 만든 변경을 충분히 판정할 수 있는가
- 공통 컴포넌트와 인증, 로깅, 배포 절차를 새 프레임워크에서도 다시 만들어야 하는가
- 새 구조를 이해하는 사람이 소수에게만 묶이지 않는가
후보 A·B·C를 같은 기준으로 평가하는 표
프레임워크 선정 회의에서는 인기, 데모 완성도, 한 번의 생성 결과만으로 결론을 내리기 쉽다. 이를 피하려면 후보 A·B·C에 동일한 작은 요구사항을 적용하고 아래 기준으로 통과 여부를 기록하는 편이 낫다.
| 비교 축 | 확인할 질문 | 통과 기준의 예시 |
|---|---|---|
| 렌더링 경계 | 서버와 브라우저가 각각 무엇을 처리하는가 | 목록, 상세, 권한 화면의 처리 위치를 문서 한 페이지와 코드 구조로 설명할 수 있다 |
| 상태 위치 | 검색어, 필터, 입력값, 저장 전 변경 내용은 어디에 남는가 | 같은 종류의 상태가 화면마다 다른 장소에 흩어지지 않는다 |
| 오류 경로 | 요청 실패, 권한 없음, 빈 결과를 어떻게 구분하는가 | 사용자 화면, 로그, 테스트에서 세 조건을 각각 확인할 수 있다 |
| 테스트 가능성 | AI가 만든 기능이 요구사항을 지켰는지 어떻게 판정하는가 | 기능 시나리오와 접근성 확인이 자동 또는 반복 가능한 절차로 남는다 |
| 연속 변경 비용 | 작은 수정 뒤 어떤 코드와 테스트가 영향을 받는가 | 변경 후 실패한 테스트가 수정 범위를 좁히는 데 도움을 준다 |
| 팀 숙련도 | 담당자가 바뀌어도 구조를 읽고 고칠 수 있는가 | 특정 프롬프트 작성자나 한 명의 전문가 없이 기능 경로를 추적할 수 있다 |
점수까지 매기고 싶다면 각 항목을 0점, 1점, 2점으로 단순화할 수 있다. 0점은 설명이나 검증 경로가 없을 때, 1점은 담당자가 설명할 수 있지만 자동 검증이 약할 때, 2점은 팀 규칙과 테스트가 함께 작동할 때다. 중요한 것은 총점 자체보다 낮은 점수를 받은 항목이 프로젝트의 핵심 요구사항과 충돌하는지다.
예를 들어 공개 콘텐츠 서비스라면 렌더링 경계와 성능 검증의 비중이 커질 수 있다. 반면 복잡한 업무 화면이라면 상태 위치, 오류 처리, 연속 변경 비용이 더 큰 선택 기준이 된다.
AI 활용에서는 첫 생성보다 연속 변경 시험이 더 중요하다
프레임워크 후보를 비교할 때 첫 화면을 만드는 시간만 재면 AI의 장점을 쉽게 과대평가할 수 있다. 생성 모델의 결과에는 편차가 있고, 같은 요청도 실행마다 다른 코드 구조와 수정 경로를 만들 수 있다. 따라서 한 번 잘 나온 결과보다 같은 요구사항과 같은 판정 기준에서 반복했을 때 어떤 구조가 안정적으로 나오는지 봐야 한다.
작은 검증 과제는 화면 하나를 만드는 데서 끝내지 않는 편이 좋다. 다음처럼 변경을 이어 붙이면 프레임워크와 팀 규칙의 차이가 더 드러난다.
- 목록과 상세 화면을 구현한다.
- 검색 조건을 URL로 공유할 수 있게 바꾼다.
- 요청 실패, 권한 없음, 빈 결과를 구분해 보여 준다.
- 키보드만으로 검색과 필터를 조작할 수 있는지 확인한다.
- 기존 화면을 깨지 않고 데이터 항목 하나를 추가한다.
여기서 기록할 것은 생성 시간만이 아니다. 변경 후 실패한 테스트가 어디를 가리키는지, 기존 규칙을 어긴 코드가 얼마나 빨리 발견되는지, 새 의존성이 필요한지, 팀원이 수정 경로를 설명할 수 있는지를 함께 본다.
성능 점수는 한 번의 숫자로 비교하지 않는다
성능은 프레임워크 선택에서 중요한 축이지만, 단일 점수로 우열을 정하기에는 조건이 많다. Lighthouse 성능 점수는 측정 기기, 네트워크 경로, 브라우저 환경 등 실행 조건에 따라 달라질 수 있다. 비교하려면 같은 조건에서 여러 번 측정하고 결과의 분포를 봐야 한다.
세부 지표도 함께 확인해야 한다. 예를 들어 LCP는 사용자가 페이지에서 가장 중요한 콘텐츠가 보인다고 느끼는 시점을 가리킨다. 총 차단 시간은 브라우저가 긴 작업에 묶여 사용자 입력에 늦게 반응하는 정도와 연결된다. 레이아웃 이동은 읽거나 누르려던 요소가 뒤늦게 움직이는 경험과 관련된다.
따라서 “성능 점수가 높다”보다 다음 질문이 더 낫다.
- 중요한 콘텐츠가 보이기까지의 시간이 후보별로 어떻게 달라지는가
- AI가 추가한 기능이 브라우저의 긴 작업을 늘리는가
- 데이터가 늦거나 실패할 때도 화면 구조가 안정적으로 유지되는가
- 같은 측정 조건에서 결과 편차가 큰가
요구사항 문서에는 프레임워크 이름보다 운영 규칙을 먼저 적는다
새 프로젝트의 요구사항 문서에는 후보 제품명만 적지 말고, 선택 뒤에도 지켜야 할 규칙을 함께 넣는 편이 좋다.
- 기본 렌더링 방식과 데이터 요청 경로를 팀이 한 페이지로 설명한다.
- 검색 조건, 필터, 로그인 상태, 임시 입력값의 저장 위치를 구분한다.
- AI가 생성한 변경은 기능 시나리오, 접근성 확인, 오류 조건 확인을 통과해야 한다.
- 새 패키지를 추가할 때는 해결하려는 문제와 기존 도구로 해결하기 어려운 이유를 남긴다.
- 기본 규칙을 벗어난 구현은 예외 이유와 되돌리는 방법을 코드 또는 문서에 기록한다.
- 성능은 통제된 조건의 반복 측정과 세부 지표로 검토한다.
프레임워크 선정 회의의 마지막 질문은 “어느 도구가 가장 빠르게 화면을 만들었는가”가 아니라 “어느 후보가 다음 변경 요청을 가장 적은 추측으로 처리하게 하는가”여야 한다. 그 답을 작은 PoC와 공통 평가표로 확인한 뒤 선택하면, AI의 생성 속도는 유지하면서도 검증과 운영의 부담을 줄일 수 있다.
