JavaScript 프레임워크의 AI 비용: 비교와 직접 측정
Nolan Lawson의 12개 프레임워크 벤치마크에서는 Hono+htmx의 추정 API 비용 중앙값이 가장 낮았고 Angular가 가장 높았습니다. 비용, 시간, 토큰, 소스 코드 줄 수를 비교하고 도구 사용 관찰과 인과관계를 구분합니다. 캐시 사용, 실패한 시도, 인수 검증을 함께 기록하는 Claude Code 실험 방법을 설명합니다.
목차
콘텐츠 중심 앱에서 AI 코딩 비용이 중요하다면 Hono+htmx와 Astro를 먼저 시험 후보로 검토합니다. Nolan Lawson의 벤치마크에서 Hono+htmx의 추정 API 비용 중앙값은 $2.67로 가장 낮았고, Angular는 $4.97였습니다. 기존 프로젝트라면 프레임워크를 바꾸기 전에 실제 작업을 대표하는 변경 사항으로 비용을 측정합니다.
어떤 프레임워크의 AI 비용이 가장 낮았습니까?
이 결과는 콘텐츠 중심 앱에 사용할 프레임워크의 시험 후보를 고르는 데 활용합니다. Lawson은 2026년 10월 28일에 실험을 공개했습니다. 공개된 실행 기록과 측정 결과는 Claude Code 2.1.310과 claude-opus-5-5를 사용했으며, 추론 수준은 high였습니다.
각 에이전트는 검색, 필터, 상세 페이지가 있는 동일한 PokéAPI 앱을 만들었습니다. 아래 표는 2026-11-06 기준으로 공개된 결과를 정리한 것입니다. 버전은 실험에 사용된 프레임워크 패키지를 식별하며, 지금 설치할 버전을 추천하는 목록은 아닙니다.
| 프레임워크와 실험 버전 | 추정 API 비용, USD 중앙값(최솟값–최댓값) | 시간(분) | 토큰(백만) | 소스 코드 줄 수 |
|---|---|---|---|---|
| Hono 4.13.14 + htmx 2.0.11 | $2.67 ($2.23–$3.19) | 8.6 | 4.26 | 1,370 |
| Astro 7.4.2 | $2.76 ($2.16–$3.63) | 8.2 | 4.13 | 1,461 |
| Nuxt 4.6.2 | $2.82 ($2.39–$4.25) | 9.0 | 3.85 | 1,415 |
| Vanilla + Vite 8.3.5 | $2.98 ($2.24–$3.37) | 10.1 | 5.00 | 1,492 |
| Next.js 16.4.3 | $3.14 ($2.58–$4.13) | 10.9 | 4.99 | 1,539 |
| Qwik 1.20.2 / 1.20.3 | $3.27 ($2.35–$3.80) | 10.7 | 5.64 | 1,744 |
| TanStack Start 1.169.4 | $3.54 ($3.11–$3.96) | 10.3 | 7.07 | 1,697 |
| SolidStart 2.1.0 | $3.79 ($2.84–$4.81) | 11.2 | 7.13 | 1,630 |
| React Router 8.5.0 | $3.81 ($2.82–$3.97) | 12.5 | 7.58 | 1,564 |
| SvelteKit 3.1.0 | $4.28 ($3.59–$4.65) | 10.8 | 8.53 | 1,611 |
| Gracile 0.11.0 + Lit 3.3.3 | $4.65 ($3.92–$5.07) | 12.1 | 9.04 | 1,717 |
| Angular 22.2.3 | $4.97 ($3.19–$6.82) | 17.2 | 9.76 | 2,009 |
각 지표의 중앙값은 개별적으로 계산했습니다. 비용, 시간, 토큰에는 프레임워크별 5회의 시도가 모두 포함됩니다. Angular의 코드량은 앱 3개를 기준으로 계산했습니다. 나머지 2개는 리버스 프록시 뒤에서 측정할 수 없었습니다.
토큰 수에는 세션 전체의 캐시되지 않은 입력, 캐시 쓰기, 캐시 읽기, 출력이 포함됩니다. 소스 코드 줄 수에서는 빈 줄, JSON, 의존성 잠금 파일, 테스트, 생성된 파일, 복사한 디자인 파일을 제외합니다. 주석은 줄 수에 포함합니다.
표의 달러 금액은 Claude Code가 계산한 추정 API 비용입니다. Lawson은 구독을 사용했으므로, 앱을 만들 때마다 실제로 이 금액을 지불했다는 뜻은 아닙니다. 호스팅 요금과 사람이 결과를 검토하는 시간도 포함하지 않습니다.
반올림된 중앙값으로 계산하면 Angular와 Hono+htmx의 차이는 $4.97 − $2.67 = $2.30입니다. Angular의 비용은 Hono+htmx의 4.97 / 2.67 ≈ 1.86배로, 이 작업에서는 약 86% 높았습니다.
Next.js와 Astro의 차이는 앱 제작 1회당 $0.38이며, 관찰된 비용 범위는 서로 겹칩니다. Hono+htmx와 Astro의 차이도 $0.09에 불과합니다. 이 차이는 작은 비교 실험을 해 볼 근거가 되지만, 모든 프로젝트에 적용할 확실한 순위를 뜻하지는 않습니다.
왜 SvelteKit과 Angular의 비용이 더 높았습니까?
추가 문서를 읽는 작업과 생성된 앱의 코드량이 비용에 영향을 주었을 가능성은 있습니다. 다만 이 실험에서는 각 요인의 영향을 따로 분리해 측정하지 않았습니다.
Lawson은 SvelteKit 에이전트가 매 실행에서 v3 마이그레이션 가이드를 읽었다고 관찰했습니다. 그는 v3가 모델의 학습 데이터보다 최신일 수 있다는 가설을 제시했습니다. 공식 마이그레이션 가이드에는 설정을 Vite로 옮기는 등의 실제 변경 사항이 나옵니다. 이 문서만으로 모델이 학습 중 무엇을 배웠는지는 알 수 없습니다.
Gracile의 경우 Lawson은 에이전트가 저장소를 복제하거나 node_modules의 컴파일된 파일을 살펴봤다고 보고했습니다. 이 과정에는 추가 조사 작업이 필요합니다. 하지만 이런 파일 읽기가 비용 차이에서 차지한 비중은 측정하지 않았습니다.
Angular의 소스 코드 줄 수 중앙값은 2,009였고, Hono+htmx는 1,370이었습니다. Hono+htmx의 코드량은 Angular의 약 68%로, Lawson이 제시한 약 70%라는 비교와도 맞습니다. 파일이 커지면 이후 읽고 수정해야 할 작업이 늘어날 수 있지만, 이 실험은 유지보수 비용을 측정하지 않았습니다.
전체 토큰 수를 해석할 때도 주의가 필요합니다. Nuxt의 토큰 중앙값은 3.85백만으로 가장 낮았지만, 달러 비용 중앙값까지 가장 낮지는 않았습니다. 캐시 사용 방식에 따라 전체 토큰 수와 가격의 관계가 달라집니다. 비용을 비교할 때는 토큰 종류별 사용량을 구분해야 합니다.
프레임워크의 MCP 서버와 스킬은 도움이 됩니까?
이 벤치마크만으로 MCP 서버나 스킬이 비용을 줄이는지는 판단할 수 없습니다. 사용 가능한 도구를 실제로 활용한 정도는 제각각이었습니다. 각 프레임워크에서 도구를 켠 경우와 끈 경우를 짝지어 비교한 실험은 아닙니다.
Lawson은 공식 도구가 있는 경우 이를 설치했습니다. 일부 프레임워크에는 그런 도구가 없었습니다. 그가 관찰한 사용 현황은 다음과 같습니다.
| 프레임워크 | 5회 실행에서 관찰된 사용 현황 |
|---|---|
| Hono+htmx | Hono의 Skill 도구를 5/5회 사용 |
| SvelteKit | MCP를 5/5회 사용 |
| Nuxt | MCP를 0/5회 사용 |
| Next.js | 스킬 파일을 1/5회 읽음; AGENTS.md를 2/5회 읽음 |
| TanStack Start | 함께 배포된 스킬 파일을 2/5회 발견 |
Nuxt의 MCP가 사용되지 않았다는 사실은 그 도구가 효과 없다는 증거가 아닙니다. SvelteKit의 비용이 높았다는 사실도 MCP 때문에 차이가 생겼다는 증거가 아닙니다. 도구 설치, 실제 호출, 완료한 작업의 비용 개선은 각각 다른 문제입니다.
Next.js의 현재 지침은 설치 버전에 맞는 문서와 작업을 조율하는 스킬을 구분합니다. 문서를 읽은 모든 작업을 MCP 호출로 취급하지 말고, 에이전트가 실제로 어떤 자료를 사용했는지 기록합니다.
직접 실험할 때는 claude mcp list 또는 /mcp로 서버 사용 가능 여부를 확인합니다. 그런 다음 실제 도구 호출 기록을 살펴봅니다. 같은 프레임워크에서 도구가 없는 조건, 사용 가능한 조건, 도구 사용을 명시적으로 요청한 조건을 비교합니다. 후속 측정에는 MCP 컨텍스트 측정 가이드를 참고할 수 있습니다.
이 실험으로 알 수 없는 것은 무엇입니까?
결과는 작은 콘텐츠 중심 앱에 사용할 후보를 좁히는 자료로 활용합니다. 다음 4가지 한계에 따라 결과를 적용하는 범위도 달라져야 합니다.
- 작업 유형: 상호작용이 적은 카탈로그는 복잡한 편집기, 대시보드, 게임을 대표하지 않습니다. 렌더링 구조의 선택도 에이전트에게 맡겼습니다.
- 표본 크기: 5회의 시도는 유용한 사례와 범위를 제공하지만, 차이가 작은 후보의 순위는 여전히 불확실합니다. 표에 나온 범위는 관찰된 최솟값과 최댓값이며, 신뢰구간이 아닙니다.
- 환경: 하나의 모델, 에이전트, 추론 수준만 시험했습니다. Qwik은 첫 실행 이후
1.20.2에서1.20.3으로 바뀌었습니다. Gracile+Lit 조합을 요청했지만, 2개의 구현에서는 Lit을 사용하지 않았습니다. - 결과: Lighthouse의 모바일 페이지 로딩 측정은 모든 상호작용이나 운영 환경의 요구사항을 평가하지 않습니다. 소스 코드 줄 수는 크기 지표이며, 유지보수 비용을 예측하는 검증된 지표는 아닙니다.
Angular에서 발생한 예외도 고려해야 합니다. 공개 기록에는 5회 모두 인수 테스트를 통과했다고 나오지만, 운영용 앱을 대상으로 한 측정은 2회 실패했습니다. 자체 실험에서도 테스트 통과와 배포 성공을 따로 기록합니다.
프로젝트에서 Claude Code 비용을 직접 측정하는 방법
먼저 후보 2개를 정하고, 각 후보를 새로 시작한 상태에서 3회씩 시험합니다. 결과가 비슷하면 5회로 늘립니다. 이는 직접 해 볼 수 있는 예비 실험의 설계안이며, 추가로 실행한 벤치마크 결과는 아닙니다.
1. 작업과 시작 상태를 고정합니다
범위가 제한된 기능 하나를 정하고, 같은 인수 테스트로 요구사항 충족 여부를 확인합니다. 기존 제품을 비교한다면 현재 사용 중인 프레임워크를 후보에 포함합니다. 수정 작업의 시간을 측정하기 전에 두 후보의 시작 프로젝트를 모두 준비합니다. 처음부터 앱을 만드는 비용을 측정하려면 양쪽 모두 초기 설정 과정을 포함합니다.
SPEC.md에 구체적인 작업을 적습니다. 예를 들어 동일한 기능의 카탈로그 페이지와 같은 제품 테스트 데이터를 준비한 뒤 다음과 같이 요청합니다.
Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.의존성 버전을 고정하고 잠금 파일을 보관합니다. 수정 실험을 시작하기 전에 의존성을 설치합니다. 두 프로젝트 모두 npm run build와 npm test를 제공하는지 확인하고, 인수 테스트의 변경되지 않은 복사본도 보관합니다.
각 시도에서는 시작 소스 코드, 프롬프트, 모델, 추론 수준, 권한, 사용할 프레임워크 도구, 과금 경로를 동일하게 유지합니다. 매번 새 복사본에서 새 대화를 시작합니다. 프레임워크 실행 순서를 번갈아 배치하고 캐시 사용량을 기록합니다.
동작에 영향을 줄 수 있는 사용자 지침, 훅, 플러그인도 기록합니다. 원래 실험의 앱과 기존 검증 절차를 사용하려면 Lawson의 벤치마크 실행 도구에서 시작합니다.
2. 실행 기록과 최종 결과를 저장합니다
인증이 완료된 Claude Code와 jq가 설치된 Bash 환경을 사용합니다. claude auth status --text로 인증 상태를 확인합니다. 필요하면 실험 전에 claude auth login을 실행합니다.
실험 후 폐기할 수 있는 개발용 컨테이너에서 실행합니다. 아래 허용 목록은 파일 변경과 셸 명령 실행을 자동으로 승인합니다. 사용할 MCP 도구의 호출도 각 실험 환경에서 실제로 불러오는 권한 규칙으로 미리 승인합니다. 서버를 연결하는 것만으로는 충분하지 않습니다.
조건별로 서로 다른 trial_label을 지정합니다. 이 예시는 문서에 설명된 비대화형 CLI를 사용하며, 실행 결과마다 고유한 출력 디렉터리를 만듭니다.
trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1
claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"
trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
--model claude-opus-5-5 \
--max-budget-usd 10 \
--allowedTools "Read,Edit,Write,Bash" \
--output-format stream-json --verbose \
"Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
> "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
|| trial_status=$?
printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"
jq -s '
[.[] | select(.type == "result")] | last
| if . == null then error("No final result; record an incomplete run")
else {
session_id,
subtype,
is_error,
estimated_usd: .total_cost_usd,
reported_wall_minutes: (.duration_ms / 60000),
modelUsage,
permission_denials
} end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"
cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"$10은 예시로 정한 예산 기준입니다. --max-budget-usd는 추정 API 지출을 기준으로 동작하며, 지출이 설정값을 넘을 수도 있습니다. 모든 조건에 같은 기준을 적용하고, 예산 때문에 중단된 시도도 기록합니다.
2026-11-06 기준으로 CLAUDE_CODE_EFFORT_LEVEL은 --effort보다 우선합니다. 다만 조직에서 정한 추론 수준 제한은 선택한 수준을 여전히 제한할 수 있습니다. 모델을 불러올 수 없다면 비교를 계속하기 전에 Opus 5.5 설정 문제를 해결합니다.
요약 결과에는 estimated_usd, reported_wall_minutes, modelUsage와 발생한 permission_denials가 있어야 합니다. JSONL 실행 기록에는 도구 이벤트가 남으므로 나중에 확인할 수 있습니다. 의도한 모델이 결과에 표시되는지 확인하고, 추가로 사용된 모델도 기록합니다.
3. 검증을 통과한 결과를 비교하고 실패도 기록합니다
에이전트와 하위 에이전트 전체의 토큰을 집계할 때는 modelUsage를 사용합니다. inputTokens, outputTokens, cacheReadInputTokens, cacheCreationInputTokens는 구분해서 기록합니다. 최종 결과 메시지의 usage 필드에는 하위 에이전트의 사용량이 포함되지 않습니다.
최종 결과는 한 번만 읽어 집계합니다. 여러 누적 결과의 합계를 다시 더하지 않습니다. 기존 세션을 재개한 실행을 새로운 시도로 취급해서도 안 됩니다.
변경되지 않은 테스트와 운영용 빌드를 에이전트와 별도로 직접 실행합니다. 의존성 파일과 테스트 파일이 바뀌지 않았는지도 확인합니다. 에이전트가 성공 결과를 반환했다고 해서 앱이 명세를 충족했다는 뜻은 아닙니다.
최종 결과가 없거나 형식이 잘못되었다면 stderr.log를 확인합니다. 해당 시도는 비용을 알 수 없는 미완료 실행으로 기록하며, 비용을 0으로 입력하지 않습니다. MCP가 사용되지 않은 이유를 에이전트의 선택으로 해석하기 전에 권한 거부 문제부터 해결합니다.
프레임워크별로 전체 시도 중 검증을 통과한 수, 성공한 실행의 중앙값과 범위, 모든 시도의 추정 비용 합계를 보고합니다. 전체 실험에서 검증을 통과한 결과 하나당 비용은 모든 시도의 추정 비용 합계를 검증 통과 건수로 나눠 계산합니다.
Total quoted cost of all attempts / Number of accepted results
비용 데이터가 없는 시도가 하나라도 있으면 전체 비용 집계가 불완전하다고 표시합니다. 검증을 통과한 결과가 없다면 유한한 건당 비용을 제시하지 말고 실패로 보고합니다. 사람이 검토한 시간은 따로 기록합니다.
수동 세션에서도 현재 Claude Code 비용 보고 기능의 /usage에서 같은 종류의 추정치를 확인할 수 있습니다. 명령어 문서는 2026-11-06 기준으로 /cost를 /usage의 별칭으로 설명합니다. 구독의 사용 한도와 제공자가 실제로 청구한 금액은 이 추정치와 구분합니다.
검토나 마이그레이션에 드는 작업이 작은 토큰 절감 효과보다 크다면 기존 기술 스택을 유지합니다. 대안이 동일한 검증을 반복해서 통과하고, 도입 이후 운영·유지보수 비용도 수용할 수 있을 때 이 판단을 바꿉니다.
프레임워크를 선택한 뒤에는 별도의 실험으로 다른 모델이나 접속 경로를 시험합니다. 코딩 모델 비교는 프레임워크 실험에서 여러 변수를 한꺼번에 바꾸지 않으면서 다음 시험 후보를 고르는 데 도움이 됩니다.
