게임 공장 에필로그 — 모든 모델을 변경하고 비용이 움직이다

게임 공장 시리즈의 9번째 포스팅입니다.

저는 끝났다고 말했습니다. 8번째 포스팅은 공장을 주차한 상태로 끝났습니다. 기능적이고, 검증되었으며, 제가 계속 다듬을 필요가 없는 상태였습니다. 그러다 저는 돌아와서 파이프라인의 모든 모델을 변경했고, 이전에 거꾸로 알고 있던 무언가를 배웠습니다.

제가 돌아오게 만든 것은 하나의 숫자였습니다. 단일 실행에서 한 에이전트가 모델에 약 780,000 토큰을 입력하고 대략 5,000 토큰을 돌려받았습니다. 입력 대비 출력 비율은 150 대 1입니다. 그 에이전트는 Builder였는데, 몇 달 동안 저와 싸웠던 바로 그 에이전트였습니다. 이 시점에서는 모델을 거의 사용하지 않았습니다. 그런데 왜 실행당 75만 토큰을 소모하고 있었고, 왜 제가 가진 모델 중 가장 비싼 것이었을까요?

공장이 도달한 지점

시리즈의 나머지 부분을 읽지 않으셨다면 간단히 말씀드리자면 다음과 같습니다. 여섯 개의 에이전트가 한 문장의 테마를 배포 가능한 플레이 가능한 슬롯 머신으로 만듭니다. Designer가 사양을 작성하면, 이미지 에이전트들이 아이콘과 배경을 만들고, Builder가 코드를 다시 작성하며, Tester가 브라우저에서 이를 플레이하고, Deployer가 이를 배포합니다.

Builder는 결국 제가 프로그램으로 되돌린 것이었습니다. 재설계 후에는 대략 99% 결정론적이어서, 소스 코드를 미러링한 다음 순수 Python에서 색상, 글꼴, 문자열만 교체하면 되었습니다. 모델에게 남겨진 유일한 것은 선택적인 장식용 CSS였습니다: 빛을 주거나(nudge a glow), 키프레임을 조정하는 정도입니다. 빌드당 몇 가지 작은 수정에 불과했습니다.

이것이 제가 아직 질문하지 않았던 질문의 배경입니다. 에이전트 내의 모델이 거의 아무것도 하지 않는다면, 왜 가장 많은 작업을 수행하는 에이전트에 사용하는 것과 같은 최고 수준의 모델을 사용해야 할까요?

작업에 맞는 모델 매칭하기

그래서 저는 지도를 만들었습니다. 각 에이전트에게 있어 모델이 실제로 '사고'하는 부분은 얼마나 되고, 배관(plumbing)인 부분은 얼마나 되는지 말입니다.

• Designer: 대화(conversation)로부터 사양(spec)을 생성합니다. 이 부분이 창의적인 영역입니다. 취향이 드러나는 곳이죠.
• Image-Gen / Background-Gen: 창의적인 작업은 이미지 모델 내부에서 일어납니다. 에이전트는 그저 프롬프트를 반복하고 파일을 저장하는 역할을 합니다. 창의적인 핵심(creative core) 주변을 감싸는 배관(plumbing)에 가깝습니다.
• Builder: 99%가 결정론적(deterministic)인 Python 코드, 1%만 장식적인 CSS입니다. 전형적인 배관(Plumbing) 역할입니다.
• Tester: 절반은 결정론적입니다 (브라우저를 구동하고 스크린샷을 찍는 작업), 나머지 절반은 판단(judgment)에 의존합니다 (결과물을 보는 비전 모델).
• Deployer: 거의 전적으로 결정론적입니다. 배관(Plumbing) 역할입니다.

이 지도를 통해 저는 결정을 명확히 내릴 수 있었습니다. 에이전트가 '생각'하는 부분에는 강력한 모델을 유지하고, 단순히 배관 역할을 하는 곳에는 비용이 저렴하고 빠른 모델을 사용해야 합니다.

이것들이 제가 2026년 말 Bedrock에서 받은 제안들로부터 결정한 할당 목록입니다:

빌더(Builder)가 빨라졌습니다. 수상할 정도로 빨랐는데, 정말 작동했는지 다시 확인하게 만드는 종류의 속도였습니다. 실제로 작동했습니다. 그리고 나서 저는 토큰 청구서를 봤습니다.

780,000 입력, 5,000 출력

출력은 매우 작았고, 그것이 핵심입니다. 5,000개의 토큰은 모델이 전체 실행 과정에서 방출한 모든 것 — 계획(plan), 도구 호출(tool calls), 그리고 그 안에 포함된 소수의 작은 CSS 패치들까지 — 을 포괄합니다. 이는

Qwen은 제가 사용하던 Bedrock 경로에서 프롬프트 캐싱을 지원하지 않았습니다. Claude Sonnet 5는 지원했고, 제 자체 통합(integration)은 Anthropic 모델 ID에 대해서만 캐싱을 활성화했습니다. 즉, 전체 코드 경로를 통제하는 하나의 is_anthropic() 확인 절차가 있었습니다. Bedrock은 Anthropic 모델뿐만 아니라 더 많은 모델에 대해 캐싱을 지원하므로, 이것은 플랫폼의 규칙이 아니라 저의 두 후보(candidate)와 제 구현 방식에 대한 사실입니다.

그리고 프롬프트 캐싱은 바로 이런 루프를 해결하는 핵심 요소입니다. 매 턴마다 재전송되는 크고 안정적인 접두사(prefix)는 첫 번째 이후에는 아주 적은 비용으로 청구됩니다. 그 반복되는 스타일시트—50만 토큰—는 캐시에 이상적인 형태이며, Qwen에서는 아무것도 캐싱되지 않았기 때문에 모든 재전송이 '풀 프레이트(full freight)'로 계산되었습니다.

따라서 제가 중요하게 생각하는 비교는

두 번째는 제가 우연히 마주친 제약 사항입니다. Qwen3-Coder-480B 모델은 128K의 컨텍스트 창을 제공하며 출력에 대해서는 16K 제한이 있습니다. 파일 하나를 열 때마다 컨텍스트가 28,000 토큰씩 증가하는 에이전트의 경우, 이 상한선은 보이는 것보다 훨씬 가깝습니다. 저는 대화 기록을 명시적으로 제한하고 응답할 공간을 확보해야 했고, 그렇지 않으면 루프 자체가 입력만으로 오버플로우되어 호출이 실패했을 것입니다. 컨텍스트 제한은 일반적으로 입력과 출력 사이에 공유되는데, 이것은 Qwen만의 특이점은 아닙니다. 하지만 제가 가진 여유 공간이 충분히 빠듯해서 단순한 회계적 세부 사항을 넘어섰습니다. 컨텍스트 비대화(context bloat)는 단순히 비용만 많이 드는 것이 아니었습니다. 이 모델에서는 빌드를 망가뜨릴 가능성이 가장 높은 요인이기도 했습니다.

세 번째는 이 모델이 여기서 사고하고 있지 않다는 점입니다. 출력물을 다시 보세요. 21번의 호출에 걸쳐 5,000 토큰입니다. Builder는 아키텍처에 대해 추론하는 것이 아니라 몇 가지 미적인 수정만 하고 도구를 호출할 뿐입니다. 에이전트가 대부분 배관 작업(plumbing)이라면, 애초에 품질을 많이 발휘하지 못하고 있는 영역이기 때문에 평범한 모델을 사용한다고 해서 품질을 크게 잃는 것은 아닙니다.

이 모든 결정은 하나의 표에 요약됩니다:

가장 아래 행이 '아니요'라면, 가장 위 행은 중요하지 않게 되고 속도가 승리합니다. 따라서 배관 작업 에이전트는 Qwen을 유지하고, 가장 아래 행이 '예'인 디자이너(Designer)는 Sonnet을 유지합니다.

실제로 고쳐야 할 부분

깔끔한 결론은 '에이전트별로 적절한 모델을 선택하라'일 것입니다. 그것은 사실이지만, 진짜 교훈를 가립니다. 그 핵심은 비용이 많이 든 부분이 모델 자체가 아니었다는 점입니다. 비용이 많이 든 부분은 66 KB 파일을 컨텍스트에 넣고 20번 재전송하는 것이었습니다.

모델 선택으로 돈과 많은 시간(wall-clock)을 절약할 수는 있었습니다. 하지만 전체 파일을 전송하지 않는 것이 훨씬 더 많은 것을 절약해 줄 것입니다. Builder는 어쩌면 여섯 개의 규칙 블록, 몇백 토큰만 건드리면 되는데, 28,000 토큰이 아닙니다.

두 스타일시트가 컨텍스트 내에서만 차지하는 토큰은 779,474개 중 약 646,000개입니다. 이는 18번의 호출에 걸쳐 하나, 5번에 걸쳐 다른 하나를 사용한 경우입니다. 이들을 제거하면 시스템 프롬프트(system prompt), 도구 사양(tool specs), 사양 조회(spec lookups), 도구 결과(tool results), 모델 자체 답변 등 매 턴마다 재전송되는 모든 것이 약 133,000개로 줄어듭니다. 모델에게 전체 파일 대신 추출된 규칙 블록을 전달하면 약 140,000개 근처에 도달합니다. 이는 5분의 1 절감 효과이며, 어떤 모델이 엔드포인트 뒤에 있는지와는 아무 관련이 없습니다.

(제가 산술 계산을 하기 전에 추측했던 것보다 적은 20분의 1 절감이 아닙니다. 매 턴마다 재전송되는 기준선 자체가 남아있는 대부분입니다.)

저는 아직 그것을 출시하지 않았습니다. 하지만 이것이 더 유용한 교훈이기 때문에 기록합니다. 저는 모델에서 비용 절감을 찾으려 했지만, 제 자체 컨텍스트 관리에서 그 해답을 발견했습니다.

전이할 것들

• 모델 최적화 전에 입력 대비 출력을 측정하세요. 150 대 1의 비율은 똑똑한 에이전트가 아니라 재독하는 에이전트입니다. 토큰 수는 모델이 '생각한' 양이 아니라 당신이 '보낸' 양을 측정합니다.
• 에이전트가 실제로 하는 일에 맞춰 모델을 선택하세요. 추론(reason)에는 강력한 모델을, 단순 처리(plumb)에는 평범한 모델을 사용하세요. 에이전트를 정직하게 매핑하세요. 이 파이프라인에서 대부분은 단순 처리에 해당했습니다.
• 캐싱이 더 저렴한 가격표보다 나을 수 있습니다. 크고 안정적인 접두사(prefix)를 캐싱하는 프리미엄 모델은 모든 것을 재전송하는 예산형 모델과 비슷한 범위에 도달할 수 있습니다. 교체 비용을 책정하기 전에, 당신의 저가 후보가 아예 캐싱을 지원하는지 확인하세요. 플랫폼의 모든 모델이 그렇지는 않습니다. 토큰당 비율이 아닌 작업 부하(workload)를 비교하세요.
• 가장 저렴한 토큰은 두 번 보내지 않는 토큰입니다. 모델을 교체하기 전에, 매 턴마다 재청구되는 컨텍스트에 무엇이 자리 잡고 있는지 살펴보세요.

내가 만든 가장 신뢰할 수 있는 에이전트는 그것을 프로그램으로 되돌린 것이었습니다. 가장 저렴한 것은 내가 필요 없는 파일들을 계속 넘겨주지 않을 때 동일한 에이전트가 될 것입니다. 이 시리즈 전체에서 얻은 교훈과 같습니다. 한 층 더 깊이 들어가서: 모델에게서 작업을 계속 제거하여 남는 것이 오직 모델의 본질적인 역할만 남도록 만드세요.

이 글은 game-factory series의 에필로그입니다. 가장 관련 있는 이전 게시물로는 Builder agent와 lessons이 있습니다.