- Published on
AI에게 유리한 새 언어를 만들기 전에 청구서를 보세요
- Authors
- Name
- Indo Yoon
AI가 코드를 쓰는 시대니까, AI가 읽기 좋은 프로그래밍 언어를 새로 만들면 기존 언어를 이길 수 있지 않을까. 문법을 짧게 하고, 중괄호를 없애고, 의미를 압축하면 토큰이 줄고 청구서도 줄 것 같아요.
이 글은 그 가정을 청구서 쪽에서 반박합니다. 결론은 이래요.
코드 텍스트는 에이전트 청구서의 0.8%입니다. 사용자가 손댈 수 있는 모든 항목을 다 지워도 6%입니다.
그리고 직접 재봤더니, 리포지토리가 29배 커져도 입력 토큰은 18%만 늘었습니다.
즉 "새 언어"는 최적화 대상이 아니에요. 진짜 비용은 매 턴 다시 청구되는 것에서 나옵니다.
청구서를 뜯어보면
"Token Reduction Is Not Cost Reduction"(arXiv 2607.12161, 2026-07)은 Claude Code 세션 1,212개, 요청 11,773건을 구성요소별로 분해했습니다. 토큰 수가 아니라 비용 기준으로요.
| 구성요소 | 컨텍스트 비중 | 비용 비중 |
|---|---|---|
| 하네스 기본(시스템 프롬프트·툴 정의) | 71.6% | 74.7% |
| 숨은 사고(hidden thinking) | 21.8% | 19.4% |
| 툴 출력 | 3.5% | 3.3% |
| 툴 호출 인자 | 1.6% | 1.4% |
| 디스크에서 읽은 파일 텍스트 | 0.9% | 0.8% |
| 대화 히스토리 | 0.5% | 0.5% |
읽는 사람이 실제로 손댈 수 있는 항목이 여기 다 있어요. 그리고 코드는 맨 아래입니다.
에이전트 청구서를 구성요소별로 쪼갠 값(비용 기준). 코드는 0.8%로 맨 아래입니다. 출처: arXiv 2607.12161 Table 1.
한 가지 범위를 밝혀둘게요. 이 표는 Claude Code + Haiku 4.5 가격 기준 특정 워크로드의 실측 평균입니다. 원논문도 "These are empirical averages from the coding-agent workloads evaluated in this study, not industry averages" 라고 못밖혀요. 다른 모델·하네스에서는 비율이 달라질 수 있습니다. 그래도 코드가 맨 아래라는 순서는 제 자체 측정(29배 → 18%)과 같은 방향입니다.
여기서 핵심이 하나 나옵니다. 하네스 프롬프트는 매 턴 다시 청구돼요. 코드는 한 번 읽고 끝나지만, 시스템 프롬프트와 툴 스키마는 200턴이면 200번 냅니다.
| 개입 | 절감 |
|---|---|
| 코드 50% 압축 | 0.4% |
| 턴 10% 감소 | 약 7.5% (74.7% × 10%) |
같은 표에서 계산한 두 개입의 절감 효과. 코드 압축은 0.4%, 턴 감소는 7.5%로 약 18배 차이입니다.
같은 표에서 나오는 산술입니다. 턴을 10% 줄이는 게 코드를 반으로 줄이는 것보다 약 18배 큰 효과예요. 새 언어로 코드를 반으로 줄이는 일은, 청구서의 반올림 오차를 건드리는 일입니다.
직접 재봤습니다: 리포가 29배 커지면?
인용만으로는 부족해서 제가 돌려봤어요. 같은 버그를 7파일 리포와 202파일 리포에 각각 넣고, 같은 프롬프트로 에이전트를 돌렸습니다.
먼저 병렬로 5개씩 동시에 돌렸는데, 결과가 이렇게 나왔어요.
| 조건 | 7파일 | 202파일 |
|---|---|---|
| 병렬(동시 5) | 6, 21, 40, 35, 43 → 평균 29.0 | 10, 12, 10, 12, 40 → 평균 16.8 |
작은 리포가 더 오래 걸린다는 이상한 결과가 나왔습니다. 원인은 리포가 아니라 동시 실행이었어요. 작은 리포 5개를 먼저 돌리고 큰 리포 5개를 나중에 돌렸기 때문에, 대기 시간이 조건과 완전히 겹쳐 있었습니다.
그래서 하나씩 순차로 다시 돌렸습니다.
순차 실행 8회의 턴 수 분포. 점 하나가 실행 1회입니다. 두 리포의 범위가 7~11턴으로 완전히 겹치고, 차이의 95% 신뢰구간이 0을 가로지릅니다.
| 조건 | 7파일 턴 수 | 202파일 턴 수 |
|---|---|---|
| 순차(동시 1) | 7, 11, 9, 11 → 평균 9.50 | 10, 11, 10, 11 → 평균 10.50 |
차이는 1.0턴이고, 95% 신뢰구간은 -1.92~+3.92턴, p=0.38입니다(Welch t=1.00, df=3.54, d=0.71). 0이 구간 안에 들어오니까 "차이 없음"으로 읽는 게 맞아요.
결론: 리포가 29배 커져도 턴은 사실상 안 늘어납니다. 같은 리포, 같은 과제가 병렬에서 40턴 걸렸다가 혼자 돌리니 7턴이 됐어요. 앞의 "+50%"도 "-86%"도 전부 잡음이었습니다.
토큰은 어땠을까요.
| 리포 | 평균 입력 토큰 | 턴 |
|---|---|---|
| 7파일 | 161,602 | 9.50 |
| 202파일 | 190,729 | 10.50 |
파일 수는 29배인데 입력 토큰은 1.18배입니다. 나머지는 어디서 나왔을까요. 턴당 입력을 보면 답이 보입니다. 순차 8회에서 턴당 입력은 14,710~21,092토큰이었고, 한 줄짜리 버그를 고치는 데도 그만큼을 매 턴 다시 보냈어요. 그리고 청구 토큰의 54.5%가 캐시 읽기였습니다(개별 실행 50.6~59.7%). 같은 대화를 매 턴 재전송한다는 뜻입니다. 시스템 프롬프트와 툴 스키마가 매 턴 다시 올라간 겁니다.
실행별 입력 토큰 구성. 오른쪽 분홍색이 캐시 읽기, 즉 같은 대화를 매 턴 다시 보낸 몫입니다. 8회 합계 54.5%.
이게 이 글의 요점입니다. 당신이 코드를 어떻게 생기게 하든, 청구서의 대부분은 코드가 아닙니다.
압축하면 싸질까? 반대입니다
"그래도 문법을 압축하면 조금은 싸지지 않나"에 대한 직접 반증이 있어요.
"Beyond Human-Readable"(arXiv 2604.07502, 2026-04):
aggressive compression increased total session cost by 67% despite reducing input tokens by 17%
입력 토큰은 17% 줄었는데 세션 비용은 67% 늘었습니다. 모델이 압축된 형식을 해석하느라 더 많이 추론하기 때문이에요. 저자들의 결론은 "의미 밀도 최적화"이지 "최소 토큰"이 아닙니다.
다른 압축 실험도 환율이 나쁘긴 마찬가지예요.
| 개입 | 토큰 절감 | 품질 손실 |
|---|---|---|
| 코드 미니피케이션 (2606.01326) | -42% 입력 토큰 | 해결률 -12%p |
| 파일 탐색 → Tree-sitter 지식그래프 (2603.27277) | 10배 적은 토큰 | 답변 품질 83% vs 92% |
토큰을 42% 아끼려고 해결률 12%p를 내는 거래예요. 지식그래프 쪽은 토큰을 10분의 1로 줄이는 대신 품질이 9%p 떨어졌습니다.
토크나이저 쇼핑은 이미 끝났습니다
"그럼 토크나이저가 유리하게 쪼개지는 문법을 만들면?" 이것도 이미 측정됐어요.
Tokka-Bench(arXiv 2610.08794)는 20개 프로그래밍 언어를 재고 이렇게 결론냅니다.
programming-language efficiency has converged among recent tokenizers
최근 토크나이저들 사이의 차이는 cl100k vs o200k로 -1.4% ~ +2.4% 수준입니다. 게다가 Anthropic의 최신 토크나이저는 같은 텍스트에 토큰이 약 30% 더 많아요. 추세가 새 언어 설계자에게 불리한 방향입니다.
언어는 16%짜리 변수입니다
언어가 아예 무의미하다는 건 아닙니다. 정확히 재면 이래요.
| 연구 | 발견 |
|---|---|
| Barbero (arXiv 2410.16292) | 모델 성능 분산 중 언어가 설명하는 것은 약 16% |
| Multi-LCB (arXiv 2606.20517) | 잘 훈련된 모델은 Rust에서 Python과 0.6%p 차이 |
| 2607.22807 (2,000 궤적) | 정확도는 언어에 거의 안 흔들리는데 토큰은 최대 1.69배 흔들림 |
모델 성능 분산에서 언어가 설명하는 몫은 16%입니다. 출처: arXiv 2410.16292 (GPT-4o-mini, 8개 언어, Codewars).
즉 84%는 모델·과제·프롬프트입니다. 그리고 그 16%조차 "언어가 좋아서"가 아니라 "모델이 그 언어로 얼마나 사고했는지" 에 달려 있어요. 논문 표현으로 "process cost is not surface cost" — 비용은 표면이 아니라 과정에서 나옵니다.
그리고 결정적인 관찰이 하나 더 있습니다. 모델들은 낯선 언어를 만나면 Python으로 먼저 프로토타이핑하고 번역합니다. 새 언어를 주면 그 언어로 사고하는 게 아니라, 익숙한 언어로 사고한 뒤 옮겨요. 번역 비용이 새 문법의 절약분을 즉시 잡아먹습니다.
그러면 뭘 해야 하나
같은 돈을 쓰면서 효과가 큰 순서입니다. 전부 언어를 바꾸지 않고 할 수 있는 일이에요.
| 순위 | 레버 | 측정된 효과 |
|---|---|---|
| 1 | 하네스 고정비용 줄이기 | 리포 29배 → 입력 18% 증가뿐 (제 실측) |
| 2 | 툴 호출을 코드로 | 150,000 → 2,000 토큰, -98.7% (Code Mode) |
| 3 | 피드백에 대안을 넣기 | 14/50 → 36/50, +44%p (VeriHarness) |
| 4 | 편집 형식을 diff로 | 20% → 61% (Aider, 같은 모델·같은 언어) |
| 5 | 언어 표면 | 분산의 16% 상한 |
| — | 문법 압축 | 청구서의 0.4% |
4번이 특히 시사적이에요. Aider는 언어를 그대로 두고 편집 형식만 unified diff로 바꿔서 성공률을 3배로 올렸습니다. 논문 제목이 "Unified diffs make GPT-4 Turbo 3X less lazy" 예요. 진단도 정확합니다.
GPT is terrible at working with source code line numbers … choose an edit format that GPT is already familiar with
훈련 분포와 일치하는 형식이 이깁니다. 새 언어가 지는 이유도, diff가 이기는 이유도, 코드 모드가 이기는 이유도 전부 같아요.
그리고 검증기 없이 자기교정을 기대하면 안 됩니다. "LLMs Cannot Self-Correct Reasoning Yet"(arXiv 2310.01798, ICLR 2024)는 외부 피드백이 없으면 성능이 오히려 나빠질 수 있다고 보고합니다.
실무 체크리스트
새 언어나 새 DSL을 검토 중이라면, 만들기 전에 이 네 개부터 재보세요.
- 총 세션 비용을 재라. 입력 토큰이 아니라. 입력이 줄고 비용이 느는 경우가 실제로 있습니다(-17% → +67%).
- 턴 수를 종속변수로 삼아라. 코드 압축률은 지표가 아니에요. 압축을 잘해도 턴이 그대로면 돈도 그대로입니다.
- 하네스부터 의심하라. 시스템 프롬프트·툴 스키마·메모리 주입이 매 턴 얼마나 올라가는지 세어보세요. 제 측정에서는 턴당 입력이 1.4만~2.1만 토큰이었고, 청구 토큰의 54.5%가 캐시 읽기였습니다.
- 형식을 먼저 바꿔라. 언어를 바꾸는 것보다 편집 형식을 바꾸는 게 3배 쌉니다.
이 글의 한계
정직하게 적어둘게요.
- 제 실측은 n=4입니다. 순차 4회씩, 총 8회예요. 리포 규모 효과가 없다는 결론은 "이 표본에서" 유효하고, 더 큰 효과가 없다고 단정하지는 않습니다.
- 병렬 측정은 실패한 실험이에요. 조건과 대기 순서가 겹쳐 있었습니다. 그래서 순차로 다시 쟀고, 이 글에는 둘 다 적었습니다.
- 인용 논문을 재현하지 않았습니다. 2607.12161의 0.8%·74.7%, Aider의 20%→61%, VeriHarness의 14/50→36/50은 원문 보고값입니다. 제가 다시 돌린 건 리포 규모 실험 하나뿐이에요.
- "턴 10% → 비용 7.5%"는 산술입니다. 74.7%가 매 턴 재청구된다는 구조에서 계산한 값이지, 그 자체를 실험한 논문이 있어서 인용한 게 아닙니다.
- 원래 이 글에는 제 산술 오류가 있었어요. "청구 토큰의 98.7%가 캐시 읽기"라고 썼는데,
billed = input + cacheRead + output이 8회 전부에서 정확히 맞아떨어지므로 두 항목은 더해지는 별개 값입니다. 나머지로 나눈 게 틀렸고, 올바른 값은 54.5% 입니다. 발행 전 수치 대조에서 잡아 바로잡았습니다.
그래도 방향은 뒤집히지 않는다고 봅니다. 하네스가 청구서의 4분의 3을 차지하고, 코드는 1% 미만이라는 두 사실은 서로 다른 측정에서 나왔고, 제 실측(29배 → 18%)도 같은 방향을 가리켜요.
새 언어를 만들 생각이라면, 만들기 전에 청구서를 한 번 뜯어보세요. 대개는 거기서 답이 나옵니다.