'AI로 만들면 빠르다'는 명제는 이제 누구나 안다. 그런데 정작 프론트엔드 현장에서 자주 빠지는 함정이 있다. 빠르게 만드는 데 성공한 순간, 검증과 품질 고도화 단계를 건너뛰고 싶어진다는 것이다. 최근 세 가지 사례—Claude를 파트너로 2일 만에 프로덕션을 출시한 선거 대시보드, React Compiler가 watch()를 조용히 건너뛰는 이유, 그리고 한 줄 명령으로 코드베이스 건강을 진단하는 React Doctor—는 이 세 단계가 분리된 이슈가 아니라 하나의 연속된 워크플로우임을 보여준다.
1단계: 제약이 아키텍처를 만든다—Claude와 2일 프로덕션
dev.to에 공개된 사례에서 개발자 Karthikeyan Gopal은 타밀나두 선거 개표 당일 24개국 2만 4천 명이 방문하고 43만 건의 요청을 처리한 실시간 대시보드를 단 이틀 만에 출시했다. 인프라 비용은 0원이었다. 흥미로운 건 AI를 쓴 방식이다. Claude는 Python 스크래퍼, 프론트엔드 전체, Cloudflare Worker API를 작성했다. 하지만 핵심 의사결정—스크래퍼를 클라우드가 아닌 로컬 노트북에서 실행할지, KV 스토어 vs 데이터베이스, 폴링 vs 웹소켓—은 모두 사람이 내렸다.
이 사례에서 진짜 주목할 지점은 Claude가 얼마나 많이 썼느냐가 아니라, 개발자가 제약을 어떻게 설계했느냐다. '무료 티어 + 수천 명 동시 접속 + 48시간'이라는 세 조건을 동시에 충족하려면 아키텍처가 먼저 옳아야 한다. CDN 엣지 캐시 120초, 브라우저 폴링 30초, KV 쓰기 997회로 하루를 버틴 구조는 제약이 좋은 설계를 강제한 결과다. 개표 당일 60개 이상의 커밋을 밀어 넣으면서도 무너지지 않은 건 AI 덕분이 아니라, AI에게 맡길 수 있을 만큼 아키텍처를 단순하게 유지했기 때문이다. 빠른 프로토타이핑의 진짜 선결 조건은 '무엇을 AI에게 물어볼지 아는 것'이다.
2단계: 빠르게 만든 코드가 Compiler 앞에서 조용히 무너지는 순간
속도를 내다 보면 자연스럽게 라이브러리 편의 API에 손이 간다. React Hook Form의 watch()가 대표적이다. velog의 TIL 아티클은 React Compiler가 watch()를 만났을 때 왜 조용히 최적화를 포기하는지 정확히 짚어낸다. 컴파일러가 자동 메모이제이션을 수행하려면 한 가지 전제가 성립해야 한다: 같은 입력에는 반드시 같은 출력. 이게 '순수성(purity)'이다.
watch('schoolName')은 겉으로는 인자 하나를 받는 함수처럼 보이지만, 실제로는 RHF 내부 스토어라는 외부 상태를 몰래 읽는다. 컴파일러 입장에서 이 함수는 캐싱이 불가능하다—같은 인자를 넣어도 호출 시점에 따라 결과가 달라지기 때문이다. 그래서 React Compiler는 해당 컴포넌트를 최적화 대상에서 조용히 제외한다(silently bail out). 코드가 깨지는 게 아니라, 최적화 혜택을 받지 못하는 것이다. 해결책은 간단하다. useWatch()를 쓰면 된다. 이 Hook은 React의 구독 모델을 따르기 때문에 Compiler가 정상적으로 처리할 수 있다.
AI가 빠르게 생성한 코드일수록 이런 함정에 빠질 가능성이 높다. Claude나 Copilot은 동작하는 코드를 만들어 주지만, React Compiler의 순수성 요구사항까지 항상 고려하지는 않는다. 빠르게 만들고 난 직후, 코드가 React의 규칙을 실제로 준수하는지 검증하는 단계가 반드시 필요한 이유가 여기 있다.
3단계: 한 줄 명령으로 코드베이스를 진단하는 React Doctor
그렇다면 검증을 어떻게 워크플로우에 녹일 것인가. Million.js 팀이 공개한 React Doctor는 이 질문에 실용적인 답을 제시한다. npx -y react-doctor@latest . --verbose 한 줄이면 60개 이상의 규칙으로 코드베이스를 스캔하고 0~100점 사이의 건강 점수를 뱉는다. 상태 관리, 성능, 아키텍처, 번들 사이즈, 보안, 접근성, Next.js 특화 규칙까지 자동으로 감지한다.
실제로 tldraw, excalidraw처럼 숙련된 팀이 관리하는 오픈소스 프로젝트들도 점수가 84점에 머문다. 100점을 목표로 삼을 필요는 없다. 중요한 것은 진단 결과가 가리키는 구체적인 파일과 라인이다. CI에 GitHub Actions로 연동하면 PR 단위로 변경된 파일만 스캔하는 diff 모드를 쓸 수 있어, 기존 부채는 건드리지 않고 새로 도입되는 안티패턴만 잡아낼 수 있다.
특히 눈에 띄는 기능은 AI 코딩 에이전트에 'skill'을 설치하는 옵션이다. Cursor, Claude Code, Copilot 등에 React 베스트 프랙티스 규칙 47개 이상을 주입해, 코드를 작성하는 시점에 문제를 미리 잡아낼 수 있다. 사후 감사가 아니라 사전 예방으로 품질 루프를 당기는 셈이다.
세 단계가 수렴하는 곳
이 세 사례는 결국 같은 방향을 가리킨다. 프로토타이핑 속도는 AI가 책임지고, 아키텍처 판단은 사람이 내리고, 코드 품질은 자동화가 지켜야 한다. 2일 만에 프로덕션을 출시했더라도, React Compiler가 조용히 건너뛰는 컴포넌트가 없는지 확인해야 하고, 그 확인을 사람이 일일이 하는 게 아니라 React Doctor 같은 도구가 PR마다 자동으로 수행해야 한다.
AI 코딩 도구가 생산성을 끌어올리는 만큼, 품질 검증의 자동화 수준도 함께 올라가야 한다. 빠르게 만들되, 제대로 검증하는 루프—이것이 지금 프론트엔드 워크플로우가 풀어야 할 핵심 방정식이다.