웹 개발 커뮤니티의 오래된 습관 하나는 많은 결정이 '느낌'으로 이뤄진다는 점이다. 어떤 프레임워크는 '엄청나게 빠르다'고 하고, 어떤 도구는 개발을 '폭발적으로 끌어올린다'고 하지만, 정작 근거가 붙는 경우는 드물다. 블로거 놀란 로슨(Nolan Lawson)은 이런 세태를 비판해 온 인물로, 앨릭스 러셀이 '프론트엔드의 잃어버린 10년'이라 부르고 발두르 뱌르나손이 '프로그래밍은 대중문화'라고 꼬집은 흐름을 짚으며, 자신은 수치와 벤치마크로 이 경향에 맞서 왔다고 말한다.
흥미로운 지점은 코딩 에이전트 시대에도 이 '바이브' 문화가 그대로 남아 있다는 관찰이다. 개발자가 더 이상 손으로 코드를 타이핑하지 않으니 개발자 경험(DX)에 덜 얽매일 법한데도, '이 프레임워크가 에이전트에게 더 낫다'거나 '에이전트가 실수를 덜 한다'는 주장이 여전히 근거 없이 오간다. 로슨은 '그럼 벤치마크는 어디 있느냐'는 질문을 던지며, 직접 실험을 설계했다.
실험은 어떻게 설계됐나
대상 앱은 포켓몬 목록에 타입, 기술, 게임별 데이터를 붙이고 검색·필터를 제공하는, 상호작용이 적은 콘텐츠 중심 사이트다. 로슨 스스로 이것이 완벽한 실험은 아니며 피그마나 지메일보다는 위키백과에 가까운 하나의 유형일 뿐이라고 전제한다. 공정성을 위해 각 프레임워크는 공식 MCP나 스킬을 쓰도록 했고, SSR이냐 CSR이냐 같은 아키텍처는 강제하지 않았다. 스펙을 Opus 5.5에 높은 노력 수준으로 주고 각 프레임워크의 최신 버전을 쓰라고만 지시했으며, 에이전트는 샌드박스 안에서 성능·접근성 테스트가 있을 거라는 사실을 모른 채 작업했다. CSS 방법론도 테일윈드·부트스트랩 같은 컴포넌트 프레임워크만 금지하고 스펙 토큰 기반 디자인을 요구해, 초점이 JS 프레임워크에 머물도록 했다.
중요한 한계도 솔직히 적어 둔다. LLM은 본질적으로 확률적이라, 운이 나쁘면 에이전트가 엉뚱한 길로 새 토큰을 낭비하기도 한다. 라이트하우스 역시 LCP(최대 콘텐츠 페인트)가 매 실행마다 다른 요소를 '가장 큰' 것으로 지목하는 등 결과가 들쭉날쭉하다. 그래서 각 프레임워크로 같은 앱을 5회씩 만들어 중앙값을 취했고, 두 번 실패한 앵귤러만 3회로 집계했다.
비용과 유지보수에서 드러난 패턴
빌드 비용(클로드 코드가 보고한 API 가격 기준)에서는 분산이 컸다. 리액트 라우터의 중앙값이 Hono+htmx보다 약 1달러 비쌌지만, 가장 저렴한 리액트 라우터(2.82달러)는 가장 비싼 Hono+htmx(3.19달러)보다 쌌다. 그럼에도 스벨트킷, Gracile+Lit, 앵귤러가 유독 비싸다는 경향은 반복됐다. 스벨트킷은 에이전트가 매번 v3 마이그레이션 가이드를 읽었는데, 너무 최신이라 모델 학습 데이터에 없기 때문으로 보인다. Gracile은 에이전트가 프레임워크를 잘 몰라 저장소를 복제하거나 node_modules의 컴파일된 소스를 읽었다. 토큰과 소요 시간도 비용과 비슷하게 움직였다.
MCP나 스킬이 항상 쓰인 것도 아니다. TanStack Start의 스킬 파일은 5회 중 2회만 발견됐고, Nuxt의 MCP는 한 번도 사용되지 않았으며, Next.js는 스킬을 1회, AGENTS.md를 2회만 읽었다. 로슨은 이것이 오히려 현실적이라고 본다. 실제 '바이브 코더' 상당수도 대문자로 MCP를 쓰라고 외치지 않고 그냥 건너뛰기 때문이다. 흥미롭게도 'UI 프레임워크 없이 바닐라 JS/TS와 Vite만' 쓰라고 한 경우가 여러 프레임워크보다 성적이 낮았는데, 이는 아무것도 없는 것보다 어떤 프레임워크라도 있는 편이 나을 수 있음을 시사한다.
성능·품질, 그리고 실무적 함의
라이트하우스의 성능·접근성·CLS 점수는 프레임워크별 차이가 거의 없이 포화 상태에 가까웠다. 변별력이 있는 지표는 전송된 자바스크립트 바이트였고, 이는 클라이언트 측 프레임워크 크기를 그대로 반영했다. 메인 스레드 점유에서 나오는 총 차단 시간(TBT)은 JS 바이트만의 함수는 아니었지만 전반적으로 값이 작았다. LCP는 변동이 심한 가운데서도 SPA에 불리하고 MPA에 유리한 큰 흐름을 보였으며, 대체로 번들 크기에 좌우됐다. 다만 Qwik은 클라이언트 라우팅을 쓰는 SPA인데도 MPA 계열과 비슷한 점수를 낸 예외였다. 앵귤러의 실패 두 건은 역방향 프록시 뒤에 둔다고 명시했는데도 로컬호스트가 아닌 접속을 거부하는 SSR 앱을 만든 경우였다.
유지보수성은 전체 코드 줄 수라는 단순한 지표로 봤다. 로슨은 리치 해리스의 말을 빌려 '프레임워크는 코드를 정리하는 도구가 아니라 생각을 정리하는 도구'라고 짚는데, 에이전트 시대에는 코드 양이 곧 향후 수정 때 드는 토큰, 즉 실제 유지보수 비용으로 직결되기에 이 관점이 더 무겁게 다가온다. Hono+htmx가 앵귤러의 약 70% 코드로 비슷한 결과를 더 빠르게 냈다는 대목이 그 예다. 그는 서비스 워커나 이미지 최적화, 지연 로딩 같은 성능 기법으로 에이전트를 유도하지 않았는데, 전형적인 바이브 코더가 그렇게 하지 않기 때문이라고 설명한다. 포켓몬 HTML을 전부 정적 자산으로 미리 생성하는 '꼼수'는 동적 데이터 처리를 흉내 내려는 실험 취지에 어긋나므로 명시적으로 금지하고 테스트 하네스에서 검사했다. 단일 앱 유형, 크로미움 단일 브라우저, 하나의 에이전트라는 조건은 분명한 한계이며, 벤치마크 전체가 깃허브에 공개돼 있어 누구나 조건을 바꿔 재현할 수 있다. 결국 이 실험의 값어치는 특정 프레임워크의 우열을 못박는 데 있다기보다, '에이전트에게 더 낫다'는 주장을 느낌이 아니라 측정으로 검증하는 틀을 제시했다는 데 있다.