그들은 실수로 $81,267를 썼습니다...

...그리고 저는 의도적으로 $1.39를 썼습니다

지난주, 핀테크 스타트업 Slash는 전 직원에게 AI 코딩을 적극 활용하라고 지시했습니다. 한 직원은 그 지시를 개인적으로 받아들여, Claude와 함께 앉아 비디오 게임을 만들었습니다.

그러자 청구서가 날아왔습니다: $81,267. 단 일주일 만에 말이죠. 그것도 회사 카드로 말입니다.

게임의 이름은 Brainrot Shooter입니다. 이 게임은 바이럴 밈(Skibidi Toilet, Tung Tung Tung Sahur 등 브레인롯(brainrot) 신전의 모든 것들)의 이름을 딴 캐릭터들을 쏘며 돌아다니는, 아주 기본적인 블록 형태의 Minecraft 스타일 1인칭 슈팅 게임(FPS)입니다. Slash는 이 영수증을 가장 제정신인 방식으로 처리했습니다. 바로 인터넷에 게시하고, 마케팅 비용으로 처리할 수 있도록 사람들이 게임을 플레이해 달라고 간청한 것입니다. 그리고 이 게임은 바이럴이 되었습니다. 그 멍청하고 작은 게임이 실제로 관객을 찾아낸 것입니다.

그 직원은 스스로 상황을 이렇게 요약했습니다: "이건 정말 미친 짓이에요. 제가 AI 지출이 어떻게 통제 불능 상태가 될 수 있는지에 대한 사례 연구(case study)가 되는 건가요?"

네, 맞습니다. 당신은 그렇게 될 것입니다. 그리고 이것이 바로 그 사례 연구입니다. 하지만 당신이 생각하는 그런 사례는 아닙니다.

모두가 잘못된 것을 비난했습니다

인터넷의 결론은 "봐라, AI 코딩은 돈 먹는 하마(money pit)다"였습니다. 그것은 게으른 해석이며, 틀렸습니다. 모델 자체가 그에게 8만 달러의 비용을 발생시킨 것이 아닙니다. 그가 모델을 사용하는 방식이 비용을 발생시킨 것입니다.

여기에 X(구 트위터)의 누구도 설명하려 하지 않았던 부분이 있습니다.

코딩 에이전트(coding agent)는 상태가 없습니다(stateless). 모델은 턴(turn) 사이의 기억을 유지하지 않습니다. 따라서 당신이 전송 버튼을 누를 때마다, 하네스(harness)는 필요한 컨텍스트(context)를 다시 보냅니다: 시스템 프롬프트(system prompt), 지금까지의 대화 내용, 그리고 모델이 살펴봐야 할 파일 내용들 말입니다. 모델은 매 턴마다 이 모든 것을 처음부터 새로 읽습니다. 그리고 당신은 매 턴마다 이 모든 것에 대해 매번 새로 비용을 지불합니다.

이제 활발한 개발이 이루어지는 하루 동안 어떤 일이 발생하는지 지켜보십시오. 당신의 코드베이스 (codebase)는 성장합니다. 당신의 대화 내용도 성장합니다. 에이전트 (agent)는 "프로젝트 전체를 보고 이 한 가지만 수정할 수 있도록" 하기 위해 계속해서 대용량 파일들을 컨텍스트 (context)로 불러옵니다. 그 모든 턴 (turn) 하나하나가 당신이 불과 5분 전에 이미 보여주었던 모든 것에 대해 다시 비용을 청구합니다. 점점 커지는 코드베이스 위에서 수백 번의 턴을 반복하면, 비용 측정기는 결코 돈을 내어주지 않는 슬롯머신처럼 미친 듯이 돌아갑니다.

이것은 AI가 비싼 것이 아닙니다. 당신이 모델로 하여금 똑같은 코드를 수백 번 다시 읽게 만드는 데 비용을 지불하고 있는 것입니다.

단서는 토큰 분할 (token split)에 있습니다

이제 구체적인 내용이 나옵니다. 그리고 이 부분은 개발자가 실제로 활용할 수 있는 부분입니다.

Claude Opus 4.8은 입력 (input) 토큰과 출력 (output) 토큰을 서로 다른 비율로 청구합니다. 이 글을 쓰는 시점을 기준으로, Anthropic의 공식 발표에 따르면 다음과 같습니다:

입력 (Input): 100만 토큰당 $5
출력 (Output): 100만 토큰당 $25

출력이 토큰당 5배 더 비쌉니다. 그래서 당신의 직감은 돈이 출력에서 나간다고 말할 것입니다. 하지만 에이전트 기반 코딩 (agentic coding)에서는 그 반대입니다. 출력 토큰은 모델이 작성하는 것이며, 모델이 작성할 수 있는 속도에는 한계가 있습니다. 입력 토큰은 모델이 읽는 것이며, 모델이 동일한 파일을 몇 번이나 다시 읽게 할 수 있는지에 대한 제한은 없습니다. 입력은 토큰당 가격은 더 저렴하지만, 그 양(volume) 때문에 파멸적인 비용을 초래합니다. 왜냐하면 그 양은 턴이 거듭될수록 복리로 쌓이기 때문입니다.

따라서 코딩 비용이 폭발적으로 증가한다면, 그것은 거의 항상 입력 토큰이 주도한 결과입니다. 저는 Slash 직원의 대시보드를 가지고 있지 않으므로, 그의 정확한 분할 수치를 인용하는 척하지는 않겠습니다. 하지만 단 하루의 반복적인 개발로 발생한 다섯 자리 수($10,000 이상)의 청구서는 컨텍스트 재로드 (context reloading)의 명백한 특징입니다. 즉, 수백 번의 턴이 깊어지는 동안 동일한 대용량 파일들을 계속해서 다시 읽은 것입니다. 그것이 메커니즘입니다. 그것이 카드를 태워버린 원인입니다.

그래서 저는 테스트에 대한 아이디어가 떠올랐습니다.

같은 게임. 단 한 번의 시도. 의도적으로.

저는 Brainrot Shooter를 처음부터 다시 만들었습니다 (제 것은 당연하게도 jBrainRot이라고 부릅니다). 동일한 전제, 동일한 블록 형태의 세계, 콤보 카운터가 올라가는 동안 당신을 향해 뒤뚱거리며 다가오는 동일한 밈 (meme) 적들까지 모두 같습니다. 차이점은 제가 어떻게 요청했느냐에 있었습니다.

모델이 매 턴마다 점점 커지는 코드베이스를 다시 읽어야 하는 하루 종일 이어지는 대화 대신, 저는 단 하나의 완전하고 독립적인 프롬프트(prompt)를 작성했습니다. 기술적 제약 사항, 컨트롤, 적, 게임의 느낌 등 모든 것을 포함한 전체 사양(spec)을 한꺼번에 담았습니다. 단 하나의 메시지. 단 한 번의 시도(One shot). "이제 파일을 다시 보고 이것을 수정해줘"와 같은 루프(loop)는 없었습니다. 왜냐하면 그 루프가 바로 비용 누수의 원인이기 때문입니다.

또한 저는 중간에 제가 직접 만든 MCP 도구인 jCodeMunch를 실행하여, 컨텍스트(context)가 모델에 도달하기 전에 불필요한 데이터(dead weight)를 제거했습니다. (솔직히 말씀드리면, 이것은 제 제품입니다. 사용하시든 안 하시든 상관없지만, 원칙은 변하지 않습니다.)

결과는 플레이 가능한 브라우저 게임이었습니다. 그리고 여기 영수증이 있습니다:

입력(Input): 11,900 토큰 (tokens) = $0.0595
출력(Output): 53,400 토큰 (tokens) = $1.335
총계: $1.39

이 비율을 보십시오. **출력 중심(output-heavy)**입니다. 모델은 게임을 다시 읽는 데 토큰을 쓴 것이 아니라, 게임을 작성하는 데 토큰을 사용했습니다. 이것이 바로 재로딩 함정(reloading trap)의 정확한 반대이며, 비용 숫자가 다섯 자리가 아닌 소수점 앞의 숫자로 나타나는 이유입니다.

그의 $81,267와 저의 $1.39. 똑같이 멍청한 게임을 만드는 데 들어간 비용이 약 58,000 대 1의 차이가 납니다.

예산을 낭비하지 마세요 (Don't Nick-Up Your Budget)

이런 상황을 피하기 위해 반드시 제 도구가 필요한 것은 아닙니다 (하지만 있으면 정말 도움이 될 것입니다). 여러분에게 필요한 것은 로봇이 다시 읽게 만드는 데 비용을 지불하는 것을 멈추는 것입니다. 실제로 비용을 줄여주는 몇 가지 규칙은 다음과 같습니다:

명세를 엄격하게 작성하고, 그다음 쓰게 하세요 (Spec hard, then let it write). 가장 큰 레버리지는 수백 번의 작은 "다시 읽고 수정하기" 과정을 단 한 번의 잘 정의된(well-specified) 과정으로 바꾸는 것입니다. 다시 읽기(Re-reads)가 곧 비용입니다. 모델이 다시 읽는 대신 바로 쓸 수 있도록 사고 과정을 앞단에 배치(Front-load)하세요. 출력(Output) 비중이 높은 청구서는 건강한 청구서입니다.
프롬프트(Prompt)뿐만 아니라 컨텍스트 윈도우(Context window)를 주시하세요. 비싼 토큰은 당신이 인지하지 못한 채 300번이나 반복해서 보내는 토큰입니다. 만약 당신의 에이전트(Agent)가 매 턴마다 거대한 파일들을 불러오고 있다면, 그것이 바로 비용 누수 지점입니다. 이를 다듬으세요.
프롬프트 캐싱(Prompt caching)을 활성화하세요. Anthropic의 프롬프트 캐싱은 반복되는 컨텍스트를 캐시 읽기(Cache-read) 요율로 청구하며, 이는 새로운 입력(Fresh input)보다 최대 90% 저렴합니다. 이를 사용하지 않고 긴 세션을 실행하고 있다면, 정적인 파일들을 다시 읽기 위해 전체 비용을 지불하고 있는 셈입니다. 이것만으로도 Nick의 청구서 같은 금액을 대폭 줄일 수 있었을 것입니다.
지출 한도를 설정하고, 미터기를 주시하세요. 인보이스(Invoice)를 받은 후가 아니라, 시작하기 전 하네스(Harness) 내에 엄격한 예산 한도를 설정하세요. 그리고 실시간 수치를 모니터링하세요. 토큰 사용량, 절감액, 처리량(Throughput)을 추적할 뿐만 아니라, 임계값 알림(Threshold alerts)을 보내 통제되지 않는 누수가 발생했을 때 다섯 자릿수 금액의 깜짝 놀랄 일로 나타나기 전에 경보를 울려주는 저희의 무료 jmunch-console 같은 도구를 사용해 보세요. (공개: 제 것이기도 합니다. 중요한 것은 카테고리입니다.) "내 능력을 과소평가했다"는 말은 아름다운 문장이지만, 끔찍한 예산 관리 전략입니다.
기본값(Defaults)을 주의하세요. Opus 4.8은 높은 노력(High effort)을 기본값으로 하며, 사고 토큰(Thinking tokens)을 출력 요율로 청구합니다. 어려운 문제에는 훌륭하지만, 사소한 문제에는 낭비적입니다. 작업의 난이도에 맞춰 노력의 수준을 맞추세요.

[

]

이 중 어느 것도 생소한 것이 아닙니다. 그저 CFO가 벽에서 당신의 명패를 떼어내기 전까지는 아무도 말해주지 않는 것들일 뿐입니다.

실제 교훈

이 이야기의 바이럴(viral) 버전은 "AI가 한 남성에게 81,000달러를 쓰게 만들었다"입니다. 진실된 버전은 "한 남성이 모델이 자신의 코드를 수백 번 다시 읽게 만드는 데 비용을 지불했고, 아무도 한도를 설정하지 않았다"입니다.

돈을 잡아먹는 구덩이는 모델이 아닙니다. 당신의 컨텍스트 윈도우 (context window)입니다. 그것을 주의한다면, 5자리 숫자의 청구서를 발생시켰던 것과 동일한 작업이 거의 비용이 들지 않게 될 것입니다...

*제가 사용한 전체 원샷 프롬프트 (one-shot prompt)와 (그것이 구축한 게임인 jBrainRot)는 리포지토리 (repo)에서 무료로 제공됩니다. 더 많은 토큰 효율성 (token-efficiency) 도구는 jcodemunch.com에서 확인하세요.