같은 기능의 웹앱을 코딩 에이전트에게 맡겨도, 어떤 웹 프레임워크를 고르느냐에 따라 만드는 비용과 사용자가 내려받는 코드의 양이 달랐다. 개발자 놀런 로슨(Nolan Lawson)이 10월 28일 공개한 실험에서는 가장 낮은 실행당 비용 중앙값이 2.67달러, 가장 높은 값이 4.97달러였다. 기능을 만드는 데 드는 돈과 완성된 앱의 품질을 따로 봐야 한다는 결과다.
프레임워크는 화면과 데이터 연결 등을 만들 때 쓰는 개발 도구의 틀이다. 로슨은 Claude Code에서 Opus 5.5 모델의 추론 노력 수준을 high로 설정하고, 동일한 포켓몬 도감을 12개 개발 방식으로 각각 다섯 번 만들게 했다. Next.js나 SvelteKit 같은 프레임워크 외에 Hono+htmx 조합, UI 프레임워크 없이 Vite와 자바스크립트 또는 타입스크립트만 쓰는 방식도 포함했다.
검색과 필터가 있는 도감을 12개 방식으로 만들었다
공통 과제는 포켓몬 목록을 검색하고 유형과 세대로 좁히며, 상세 페이지에서 능력치와 진화 관계, 기술을 살펴보는 앱이었다. 공개 포켓몬 데이터 서비스인 PokéAPI의 로컬 사본에서 데이터를 가져온다. 아래는 로슨이 원문에 제시한 앱 화면으로, 검색창과 두 필터 아래에 포켓몬 목록이 놓여 있다.
에이전트는 명세와 기능 시험을 받았고, 시험이 통과할 때까지 작업했다. 시험은 특정 HTML 구조 대신 보조 기술에 노출되는 역할과 이름, 텍스트를 확인했다. 제출한 앱만 새 컨테이너로 옮겨 원래 시험을 실행하므로, 에이전트가 시험 파일을 고쳐 통과하는 방식도 막았다.
데이터를 미리 읽어 모든 페이지를 정적 파일로 만들어 두는 방법은 허용하지 않았다. 빌드 때와 실행 때 다른 데이터를 제공해, 실행 중 API에서 정보를 가져오는지 확인했다. 서버가 HTML을 만들어 보내는 방식과 브라우저가 코드를 실행해 화면을 그리는 방식 중 무엇을 쓸지는 에이전트가 골랐다. 이 선택까지 포함한 비교다.
최저 비용 순위보다 실행마다 달라진 폭을 봐야 한다
실행당 API 환산 비용의 중앙값은 Hono+htmx 2.67달러, Astro 2.76달러, Nuxt 2.82달러였다. Next.js는 3.14달러, SvelteKit은 4.28달러, Angular는 4.97달러였다. 아래 표는 12개 방식 전체의 중앙값과 실행 범위다. 로슨은 월 100달러 Max 요금제를 사용했으므로, 이 금액은 건별로 추가 결제한 돈이 아니라 Claude Code가 보고한 API 가격 기준 환산값이다.
순위가 곧 매번의 승패는 아니다. React Router의 중앙값은 3.81달러로 Hono+htmx보다 높았지만, 가장 저렴한 React Router 실행은 2.82달러였다. 가장 비싼 Hono+htmx 실행의 3.19달러보다 낮다. 한 번 돌려 나온 금액만으로 특정 도구가 늘 저렴하다고 판단하기 어렵다.
코드를 쓰기 전에 정보를 찾아 읽는 과정도 비용에 들어간다. 로슨의 관찰에서 SvelteKit 에이전트는 매번 버전 3 마이그레이션 가이드를 읽었고, Gracile을 쓴 에이전트는 저장소를 복제하거나 설치된 패키지의 소스를 들여다봤다. 로슨은 모델이 새 버전이나 낯선 도구를 익히는 과정이 비용을 늘렸을 가능성을 짚었다.
공식 문서 연결 도구인 MCP나 작업 지침인 스킬을 준비해 두어도 반드시 쓰지는 않았다. Nuxt의 MCP는 한 번도 사용되지 않았고, TanStack Start의 스킬은 다섯 번 중 두 번 발견됐다. 이 실험은 프레임워크 자체뿐 아니라 당시 문서와 보조 도구를 에이전트가 찾아 쓰는 과정까지 측정한 셈이다.
접근성은 모두 100점인데 내려받는 코드는 달랐다
완성된 홈페이지는 웹 품질 검사 도구 Lighthouse로 평가했다. 접근성 점수 중앙값은 전부 100점이었고, 성능 점수 중앙값은 97~100점에 모였다. 총점만으로는 차이가 작아 보였지만 첫 화면에서 전송한 자바스크립트 양은 달랐다. Astro는 원문 반올림 기준 중앙값 0KiB, 범위 0~1KiB였고 Next.js는 중앙값 142KiB였다. KiB는 1,024바이트를 뜻한다.
주요 콘텐츠가 화면에 표시되기까지 걸리는 LCP 중앙값도 Astro 810밀리초, Hono+htmx 978밀리초, Next.js 2,090밀리초로 차이가 났다. 검사는 모바일 환경을 모사해 CPU 속도를 네 배 늦추고 Slow 4G 네트워크 조건을 적용했다. 콘텐츠를 먼저 HTML로 보내는 방식에 유리한 첫 로딩 검사이며, 검색을 반복하거나 화면 안에서 이동할 때의 반응성은 측정하지 않았다. 편집기나 복잡한 업무 대시보드에 같은 순위를 적용할 수는 없다.
실패한 결과를 어느 집계에 넣었는지도 구분해야 한다. Angular는 다섯 번 중 두 번, 역방향 프록시 뒤에서 실행한다는 조건과 맞지 않는 앱을 만들었다. 비용에는 실패한 두 번을 포함한 다섯 번을 모두 넣었지만, 성능과 코드량은 측정 가능한 세 앱으로 계산했다.
처음 만드는 비용과 고치는 비용은 따로 남는다
빈 줄을 뺀 소스 코드 줄 수 중앙값은 Hono+htmx 1,370줄, Angular 2,009줄이었다. 로슨은 코드가 많으면 이후 수정 때 에이전트가 읽어야 할 토큰도 늘 수 있다고 해석했다. 줄 수는 코드량의 단서이지 유지보수 비용 자체는 아니다. 이 실험에서 후속 기능 추가나 버그 수정에 드는 비용을 재지는 않았다.
새 프로젝트의 도구를 고를 때는 검색이나 상세 조회처럼 실제 서비스에서 반복할 기능을 같은 명세로 맡기고, 여러 번 실행한 비용과 기능 통과 여부를 함께 남길 수 있다. 이후 수정 작업까지 시험하면 처음의 저렴한 선택이 계속 유리한지도 비교할 수 있다. 이미 운영 중인 제품이라면 이 작은 도감의 순위만으로 재작성할 근거는 부족하다. 팀이 읽고 고칠 수 있는 코드인지와 실제 사용 흐름에서 어떤 부담이 생기는지도 선택에 들어간다.
프레임워크뿐 아니라 모델을 실행하는 도구도 비교 대상이다. 같은 모델을 여러 실행 도구에 연결한 실험은 그 차이를 따로 살펴본 사례다.
출처: Nolan Lawson, The AI cost of JavaScript frameworks · 실험 저장소와 공통 명세