토큰의 2%만 코드에 쓰인다 — AI 코딩의 진짜 비용과 낭비 줄이기

안녕하세요, Tom입니다.

요즘 AI 코딩 도구를 자랑할 때 다들 비슷한 단어를 씁니다. "한 시간 만에 앱을 만들었다", "에이전트 세 개를 동시에 돌렸다", "코드 수천 줄을 자동으로 뽑았다." 그런데 저는 요 며칠 올라온 글들을 보면서 질문이 하나 바뀌었어요. 빨리 많이 만드는 게 정말 잘하는 걸까요, 아니면 덜 낭비하는 게 잘하는 걸까요?

제 생각엔 AI 코딩의 경쟁축이 조용히 이동하고 있습니다. "얼마나 빨리 만드나"에서 "얼마나 안 낭비하나"로요. 여기서 낭비는 두 가지예요. 하나는 토큰(=돈)의 낭비, 다른 하나는 유지보수 부담의 낭비. 이 두 축으로 보면 최근 GeekNews에 올라온 세 가지 소식이 사실 같은 이야기를 하고 있다는 게 보입니다.

토큰의 98%는 코드를 만드는 데 안 쓰인다

먼저 돈 이야기부터요. GeekNews에 올라온 claude-ns-hub 소개글에 인상적인 측정이 하나 있어요. 만든 사람 주장에 따르면 Claude Code를 쓸 때 토큰의 약 2%만 실제 코드 생산에 쓰이고, 나머지 대부분은 "같은 컨텍스트를 반복해서 다시 적재하거나, 사라진 결정을 재추론하는 데" 낭비된다는 거예요.

claude-ns-hub는 이 낭비를 줄이려고 만든 오픈소스 컨텍스트 허브입니다. 세션 간에 결정 메모리를 유지해서 같은 분석을 다시 안 하게 하고, tmux 브랜칭으로 컨텍스트를 자동 관리하는 식이에요. 만든 사람은 2주 운영 후 Claude 청구액이 절반으로 줄었고, 컨텍스트를 569KB에서 42KB로 압축(약 93% 감소)했다고 적어 뒀습니다. 다만 이 수치들은 개인 사용기 수준이고 GitHub 링크에 404가 뜬다는 댓글도 달려 있으니, 검증된 벤치마크가 아니라 "한 사람의 측정"으로 받아들이는 게 맞아요.

수치의 정확도보다 제가 주목한 건 문제의 정의 방식입니다. AI 코딩의 비용을 "토큰을 얼마나 쓰느냐"가 아니라 "쓴 토큰 중 몇 %가 실제 일을 했느냐"로 보기 시작했다는 점이요. 이건 생성 속도가 아니라 효율을 지표로 삼겠다는 선언입니다.

빨리 만든 결과물이 곧 부채가 되는 패턴

두 번째 축은 유지보수예요. 바이브코딩을 'ADHD 증폭기'라 부른 글이 이 부분을 아프게 찌릅니다. 글쓴이는 Claude나 Codex 같은 도구가 무관한 작업을 여러 화면에서 동시에 벌이게 만들어서, 생산성이 높아진 듯한 착각을 준다고 해요.

실제 성적표는 이렇습니다. 간단한 스크립트 요청으로 시작했는데 한 시간 뒤엔 원래의 작은 문제도 해결 안 된 채 프로젝트만 커지고, 결국 Rust 음성인식, Jellyfin 클론, 게임 엔진 같은 게 미완성으로 쌓였다는 거예요. 글쓴이가 지운 프로젝트만 50개쯤 되고, SaaS를 제외한 대부분은 쓸모보다 유지보수 부담이 더 큰 코드로 남았다고 합니다.

여기서 첫 번째 소식과 두 번째 소식이 만나요. 토큰 낭비와 유지보수 낭비는 같은 뿌리에서 나옵니다. 컨텍스트가 휘발되니 같은 결정을 매번 다시 시키고(토큰 낭비), 그 과정에서 방향이 흐트러져 안 쓸 코드를 잔뜩 만든다(유지보수 낭비)는 거죠. 결과물의 '양'은 분명 늘었는데, 그 양 자체가 비용으로 돌아오는 구조입니다.

손에서 안목으로 — 장인정신도 같은 곳을 가리킨다

세 번째 소식은 한 단계 위에서 같은 결론에 도착합니다. O'Reilly의 세 번째 AI Codecon 정리글인데, 팀 오라일리와 Addy Osmani가 진행한 행사예요. 핵심 메시지는 장인정신이 사라지는 게 아니라 이동한다는 것. "코드를 짓는 손에서 시스템을 설계하는 안목으로" 옮겨간다는 표현이 나옵니다.

에이전트가 구현을 기계 속도로 맡으면, 사람의 병목은 코딩 속도가 아니라 개념적 일관성과 아키텍처 판단으로 바뀝니다. 행사에서도 긴장이 그대로 드러났어요. Ryan Carson은 에이전트에 최대한 자율성을 주자고 한 반면, Anthropic의 Cat Wu는 human-in-the-loop 설계를 강조했고요. Nicole Koenigstein은 데모에선 안 보이지만 프로덕션에서 터지는 실패 모드를 경고했습니다. 특히 Wes McKinney의 말이 인상적인데, 결정적 우위는 가장 많은 세션을 병렬로 돌리는 사람이 아니라 머릿속에 개념 모델을 유지하는 사람에게 있다고 했어요.

이 세 소식을 한 줄로 꿰면 이렇습니다. 토큰 효율(낭비 안 하기), 유지보수 절제(쓸 것만 만들기), 그리고 판단력(안목으로 설계하기)은 전부 "양보다 효율·지속가능성"이라는 같은 지표를 다른 층위에서 말하고 있어요. 비슷한 맥락을 저는 예전에 Claude Code의 K자형 생산성 글에서도 정리한 적이 있는데, 코드 줄 수가 아니라 제품 개선 속도가 진짜 지표라는 이야기와 정확히 같은 방향입니다.

솔직한 반론: 효율 강박이 또 다른 함정일 수 있다

물론 이 주장에도 빈틈은 있어요. 첫째, claude-ns-hub의 2%·50% 같은 숫자는 검증된 데이터가 아니라 개인 측정이라, 그대로 일반화하면 안 됩니다. 둘째, "낭비를 줄이자"는 구호가 자칫 초기 탐색까지 위축시킬 수 있어요. 바이브코딩이 만든 미완성 프로젝트 50개 중 일부는 실패였지만, 그 빠른 시도 덕에 SaaS 하나가 나왔을 수도 있잖아요. 탐색적 낭비와 구조적 낭비는 구분해야 합니다.

셋째, 컨텍스트 허브나 결정 메모리 같은 도구도 결국 새로운 복잡도를 더합니다. 토큰을 아끼려고 도입한 인프라가 또 다른 유지보수 대상이 되는 역설이요. 효율을 측정하는 지표가 없으면 "효율적인 척"만 늘어날 위험도 있고요. 평가축 자체가 흔들리고 있다는 점은 SWE-bench의 구조적 한계 글에서도 다룬 적이 있는데, 무엇을 '잘함'으로 측정할지부터 아직 합의가 없는 상태예요.

한국 개발자 입장에서

한국 개발자 입장에서 이 흐름은 꽤 현실적인 신호로 읽혀요. 환율 때문에 토큰 비용이 체감상 더 무겁고, 작은 팀이나 1인 개발자가 많아서 "빨리 많이 뽑은 코드"의 유지보수가 곧바로 본인 부담으로 돌아옵니다. 그래서 저는 토큰 효율과 유지보수 절제가 해외보다 한국 환경에서 더 빨리 절실해질 거라고 봐요. 화려한 데모보다, 같은 결정을 두 번 시키지 않는 워크플로우를 갖춘 사람이 결국 비용에서 이깁니다. 이건 제 의견이지만, 청구서를 직접 받아 본 사람이라면 공감할 거예요.

구체적인 takeaway

추상적인 결론 대신 당장 점검할 것 세 가지로 마무리할게요.

첫째, 다음 청구서가 오면 "토큰을 얼마 썼나"가 아니라 "같은 컨텍스트를 몇 번 다시 적재했나"를 의식해 보세요. 세션을 새로 열 때마다 같은 설명을 반복하고 있다면 그게 바로 98%쪽입니다. CLAUDE.md나 결정 기록 파일에 "확정된 결정"을 적어 두는 것만으로도 재추론 비용이 줄어요.

둘째, 새 프로젝트를 시작하기 전에 "이걸 6개월 뒤에도 유지보수할 건가"를 한 번 물어보세요. 바이브코딩 글의 교훈은 시도하지 말라가 아니라, 유지보수할 것과 버릴 실험을 처음부터 라벨링하라는 거예요.

셋째, 에이전트를 몇 개 돌리느냐로 자신을 평가하지 마세요. McKinney 말처럼 머릿속에 시스템의 개념 모델이 남아 있는지가 더 중요한 지표입니다. 안목이 없는 병렬 세션은 그냥 빠른 부채 생산기일 뿐이에요.

근거가 된 소식: claude-ns-hub: AI 코딩 월 비용을 절반으로, ADHD 증폭기로서의 바이브코딩, AI 시대의 소프트웨어 장인정신 (O'Reilly AI Codecon)