속도는 충분히 빨라졌다. 문제는 그다음이다
AI 코딩 도구가 일상이 된 지금, 프론트엔드 개발자들이 공통으로 마주치는 질문이 있다. "빠르게 만들었는데, 이게 진짜 괜찮은 건가?" 최근 dev.to에 올라온 세 편의 글—Claude Code 리팩토링 경험담, Astro vs Next.js 성능 비교, PostHog + Next.js App Router 트러블슈팅—은 각기 다른 맥락처럼 보이지만, 결국 같은 지점을 가리키고 있다. 검증 없는 속도는 절반짜리 결과물이라는 것.
Claude Code가 자기 코드를 비판했을 때
한 개발자가 6일 전 Claude Code로 작성한 기능을 확장해달라고 요청했다. 돌아온 답은 확장이 아니었다. "이 코드, 리팩토링부터 하는 게 좋겠어요. 에러 핸들링이 일관되지 않고, 함수가 이름과 다른 일을 하고, 중복 검증 블록이 있어요." 비판한 코드를 작성한 것도 Claude Code였다.
처음엔 이게 AI의 결함처럼 보인다. 세션 간 메모리가 없으니 이전에 자신이 작성한 코드를 기억하지 못하고, 마치 타인의 코드를 보듯 냉정하게 평가한 것이다. 그런데 이 글의 저자는 이 시점에서 관점을 뒤집는다. AI의 세션 단절이 버그가 아니라 피처일 수 있다는 것.
인간이 일주일 전 자신이 쓴 코드를 리뷰할 때는 수많은 인지적 편향이 작동한다. 그 당시의 맥락, 마감 압박, 타협의 이유—모든 것이 비판적 시각을 흐린다. 반면 새 세션의 Claude Code는 그 코드가 어떻게 탄생했는지 전혀 모른다. 그냥 코드만 보고 판단한다. 이보다 깨끗한 코드 리뷰는 없다.
여기서 도출되는 실용적 워크플로우가 흥미롭다. 기능을 완성하고 커밋한 다음 날, 새 세션을 열어 "이 코드 리뷰해줘"라고 요청한다. 어제의 자신이 남긴 결정에 얽매이지 않은 눈으로 문제를 찾아낸다. CLAUDE.md는 재론할 필요 없는 결정을 기록하는 문서지, 코드의 역사를 남기는 일지가 아니다. 에이전트에게 연속성을 줄수록 오히려 이 냉정한 리뷰어로서의 가치를 잃는다는 역설.
프레임워크 선택: 요구사항을 먼저 쓴 팀이 이긴다
두 번째 사례는 계산기 사이트 12개를 Astro로 배포한 경험이다. 수년간 Next.js를 써온 개발자가 이번엔 Astro를 선택했고, 결과는 모바일 Lighthouse 96점, 페이지당 JS 4~6kb였다. Next.js 프로토타입에서 같은 페이지가 94kb, Lighthouse 81점이 나왔던 것과 비교하면 격차가 선명하다.
이 글에서 주목할 부분은 프레임워크 자체의 우열이 아니다. 저자는 프레임워크를 고르기 전에 제약 목록을 먼저 작성했다는 점이 핵심이다. 트래픽의 95%가 Google 롱테일 검색에서 온다, 모바일 Lighthouse 95+ 필수, 백엔드·DB·인증 없음, Cloudflare 무료 티어 배포. 이 목록을 보면 Next.js가 왜 틀린 선택인지가 자명해진다.
Astro의 아일랜드 아키텍처는 이 요구사항에 정확히 맞는 형태다. 상호작용이 필요한 계산기 위젯에만 JS를 보내고, FAQ·공식 설명·관련 링크는 순수 HTML로 내보낸다. Core Web Vitals는 "신경 써야 할 지표"가 아니라 SEO 경쟁에서 살아남기 위한 입장 조건이었고, Astro는 그 조건을 기본값으로 충족시켰다.
반대로 저자는 Next.js가 여전히 옳은 선택인 상황도 명확히 짚는다. 사용자 인증과 개인화 데이터, 실시간·스트리밍 UI, 복잡한 다단계 폼, 대형 React 모노레포 통합—이런 조건이라면 Astro를 선택하는 게 오히려 프레임워크와 싸우는 일이 된다. 도구의 우열이 아니라 프로젝트의 형태와 도구의 형태가 맞는가가 질문이다.
6일간 침묵한 애널리틱스가 준 교훈
세 번째 사례는 Next.js 16 App Router에서 PostHog 연동이 6일 동안 완전히 죽어 있었던 포스트모템이다. 개발자는 PostHogProvider를 일단 빈 스텁으로 교체하고 "나중에 고치겠다"고 했다. 6일 후 애널리틱스 그래프가 완전히 평탄한 것을 보고서야 문제를 인지했다. 웨이트리스트 신청이 들어오고 있었지만, 이벤트는 아무것도 기록되지 않았다.
트러블슈팅 과정에서 세 가지 함정이 드러났다. 첫째, posthog-react는 더 이상 별도 패키지가 아니며 posthog-js/react 서브패스를 써야 한다—2024년 이전 블로그 포스트를 그대로 따르면 "모듈을 찾을 수 없음" 에러를 만난다. 둘째, useSearchParams()를 사용하는 클라이언트 컴포넌트는 반드시 <Suspense> 안에 있어야 한다. 이걸 빠뜨리면 해당 라우트 전체가 정적 렌더링에서 조용히 이탈하고 TTI가 느려진다. Next.js의 App Router는 이 규칙을 빌드 타임에 에러로 잡아주지만, 놓치면 성능 비용이 소리 없이 쌓인다. 셋째, posthog.__loaded 플래그를 init 측과 capture 측 양쪽에서 체크해야 React 18 StrictMode의 이중 실행과 초기화 타이밍 레이스를 함께 막을 수 있다.
이 글에서 가장 인상적인 부분은 기술적 해결책보다 검증 방법론이다. "대시보드가 조용하다"를 "아무도 안 왔다"로 해석하지 말고 "파이프라인이 끊겼다"는 신호로 먼저 의심하라. 수정 후 확인은 대시보드가 아니라 Chrome 네트워크 탭으로 한다. posthog.com으로 필터링해서 /decide/와 /e/에 실제로 200 응답이 오는지 눈으로 확인하는 것이 유일한 진실이다.
세 사례가 함께 가리키는 것
이 세 편의 글은 각기 다른 도구와 다른 문제를 다루지만, 공통된 구조를 갖고 있다. 빠르게 만들었고, 동작하는 것처럼 보였고, 그런데 실제로는 아니었다. Claude Code가 생성한 코드는 테스트를 통과했지만 구조적 문제가 있었다. Next.js 프로토타입은 빌드됐지만 성능 요구사항을 충족하지 못했다. PostHog 연동은 배포됐지만 6일간 아무것도 기록하지 않았다.
프론트엔드 개발에서 AI 도구가 가져온 가장 큰 변화는 첫 번째 버전을 만드는 속도다. 그 속도가 빨라질수록, 역설적으로 검증에 투자해야 할 비중이 높아진다. AI가 짜준 코드를 새 세션으로 다시 리뷰하고, 프레임워크를 고르기 전에 요구사항 목록을 먼저 쓰고, 배포 후 대시보드가 아닌 네트워크 탭으로 확인하는 것—이것들은 개발 속도를 늦추는 절차가 아니라 속도가 빨라진 세계에서 품질을 유지하는 최소한의 안전망이다.
"빠르게 프로토타이핑하고, 검증하고, 고도화한다"는 흐름은 이미 익숙한 말이다. 하지만 지금 현장에서 실제로 일어나는 일을 보면, 프로토타이핑은 AI 덕분에 극적으로 빨라졌고 고도화도 AI의 도움으로 어느 정도 자동화됐는데, 정작 검증 단계만 예전 방식 그대로다. 세 사례가 공통으로 지적하는 병목이 바로 여기다. 속도는 AI가 해결했다. 지금 남은 숙제는 '내가 만든 것이 실제로 의도대로 동작하는지 확인하는 루프'를 얼마나 빠르고 신뢰할 수 있게 설계하느냐다.