GitHub Copilot이 프리미엄 요청 방식에서 사용량 기반 과금 (usage-based billing) 방식으로 전환되었습니다. 이 단 한 번의 변화로 고객들로부터 질문의 물결이 밀려왔으며, 그중 대부분은 다음과 같았습니다:

"어떻게 하면 토큰 지출을 줄일 수 있을까요?"

이것은 잘못된 질문입니다. 적어도, 올바른 질문의 아주 작은 버전일 뿐입니다.

더 나은 질문은 다음과 같습니다: 우리가 사용하는 토큰을 어떻게 최대한 활용할 것인가? 목표는 요청당 토큰 수를 줄이는 것이 아닙니다. 목표는 _성공적인 결과 (successful outcome)_당 낭비되는 토큰을 줄이는 것입니다. 관점을 이렇게 바꾸면, 비용을 쫓는 대신 품질을 쫓게 되며, 비용 문제는 자연스럽게 해결됩니다. 왜냐하면 대부분의 토큰 낭비는 실패한 실행과 과도하게 채워진 컨텍스트 (stuffed contexts)에서 발생하기 때문입니다.

이 포스트는 제가 에이전트 품질 (agent quality) 및 토큰 최적화 (token optimization)에 대해 진행하는 워크숍의 긴 버전입니다. 우리는 그 이유와 기초, 그리고 오늘 바로 적용할 수 있는 실질적인 제어 방법들을 다룰 것입니다.

이 포스트의 슬라이드 이미지는 유사한 이름의 GitHub 워크숍 자료에서 영감을 얻었으며, GitHub의 출처를 밝힙니다. 해석과 문장은 저의 것입니다.

이 포스트의 기반이 된 워크숍.

바쁜 개발자를 위한 요약 (TL;DR)

시간이 딱 2분 있다면:

1. 단순 토큰 수가 아닌, 성공적인 결과당 비용을 최적화하세요. 대부분의 토큰 낭비는 실패한 실행과 과도하게 채워진 컨텍스트 (Context)에서 발생합니다.
2. 품질은 복리로 작용합니다. 단계별 정확도가 95%일 때, 50단계의 에이전트 (Agent) 워크플로우의 최종 정확도는 8%로 떨어집니다. 모든 품질 개선 요소는 확실한 보상을 제공합니다.
3. 컨텍스트 (Context)가 핵심 레버입니다. 계획 수립에는 추론 모델 (Reasoning models)을, 구현에는 더 작은 모델을 사용하세요. "필요할지도 모르는" 파일들을 절대 무작정 채워 넣지 마세요. /clear를 자주 사용하세요.
4. 결정론적 가드레일 (Deterministic guardrails)을 사용하세요. 테스트, 린터 (Linters), 보안 스캔 등이 이에 해당합니다. Copilot CLI 팀은 매주 500개의 PR을 배포하며, 코드베이스의 53%가 테스트입니다. 이것이 정석입니다.
5. 에이전트 설정을 엔지니어링처럼 다루세요. 사람이 직접 작성한 작은 copilot-instructions.md 파일이 그 어떤 영리한 프롬프트 (Prompt)보다 낫습니다.

오늘 바로 실행할 수 있는 다섯 가지 구체적인 행동 지침은 하단에 있습니다.

로켓 문제

비유를 통해 설명해 보겠습니다. 무엇이 변했는지 설명하는 가장 쉬운 방법입니다.

스푸트니크 (Sputnik) 시대

이를 스푸트니크 시대로 불러봅시다. 초기 단계의 실험적이고, 저렴하게 느껴지며, 일단 발사하고 배우는 에너지가 넘치는 시기입니다. 로켓은 저렴하고, 주말 사이에 20개를 만들 수 있으며, 단 하나만 착륙하면 되기에 대략 올바른 방향으로만 겨냥하면 됩니다.

많은 사람이 에이전트 (Agent)를 사용하는 방식이 바로 이와 같습니다. 약간의 컨텍스트 (Context)를 제공하고, 빠른 프롬프트 (Prompt)를 작성한 뒤, 에이전트를 보냅니다. 결과가 좋으면 배포하고, 그렇지 않으면 또 다른 것을 보냅니다. 그리고 또 보냅니다. 비용이 눈에 보이지 않기 때문에 도박처럼 느껴져도 부담이 없습니다.

대부분의 팀이 여전히 에이전트를 사용하는 방식: 더 많이 발사하고, 하나라도 맞기를 기도한다.

팔콘 (Falcon) 시대

이제 발사 비용이 실제 발사 비용만큼 비싸다고 상상해 보세요. SpaceX의 Falcon은 저렴하지 않습니다. 20번이 아니라 한두 번의 기회만 주어집니다. 따라서 엔지니어링의 과제는 다음과 같이 변합니다: 실제로 목적지에 도달할 뿐만 아니라, 재사용할 수 있도록 발사대로 다시 착륙하는 로켓을 만드는 것입니다.

그것이 바로 현재 우리가 에이전트(Agents)를 대하는 상황입니다. 사용량 기반 과금(Usage-based billing)은 토큰을 절대적인 의미에서 비싸게 만든 것이 아닙니다. 그것은 _도박(gambling)_을 비싸게 만들었습니다. 해결책은 더 저렴한 연료가 아닙니다. 해결책은 더 적지만, 더 잘 설계된 발사(launches)입니다.

발사대에서 폭발하는 비싼 로켓의 시대

이름을 붙일 만한 가치가 있는 세 번째 실패 모드(failure mode)가 있으며, 이는 가장 고통스러운 것입니다. 당신은 엄청난 양의 토큰을 태우면서도 여전히 발사대에서 폭발해 버리는, 매우 무겁고 매우 비싼 에이전트를 충분히 만들 수 있습니다. 관련이 있을지도 모르는 모든 파일로 가득 채워진 거대한 컨텍스트 윈도우(Context window). 모든 MCP(Model Context Protocol) 활성화. 세 개의 추론 모델(reasoning models)을 체인으로 연결. 루프 내의 테스트(tests in the loop) 없음. 정지 신호(stop signal) 없음. 완료 정의(definition of done) 없음.

에이전트는 제자리를 맴돌며 추론합니다. 당신이 필요하지 않은 도구(tools)를 호출합니다. 고장 나지 않은 것을 "수정"합니다. 40번째 턴(turn)에 이르면 원래 목표에서 벗어나, 친절하게 환각(hallucinating)을 일으키며 당신의 월간 예산을 태워버립니다. 마침내 결과물이 도착했을 때, 그것은 틀려 있습니다.

이것이 세 가지 중 최악입니다. 당신은 달 탐사 미션 비용을 지불했는데, 발사대까지 날려버린 셈입니다.

이 부분에 대해서는 포스트 전반에 걸쳐 다시 다루겠습니다. 뒤이어 나오는 대부분의 제어 사항들은 바로 이러한 로켓을 만들지 않기 위한 것들입니다.

토큰을 세는 것이 잘못된 질문인 이유

ROI를 결정하는 것은 토큰 절약이 아니라 품질입니다

에이전트에 표준 ROI(투자 대비 수익) 공식을 적용해 봅시다:

에이전트 ROI = (에이전트 출력의 가치 − 토큰 비용) / 토큰 비용 × 100%

이를 깔끔하게 계산할 수는 없습니다. 아무도 할 수 없습니다. 당신을 위해 기능을 작성한 에이전트의 가치를 어떻게 수치화할 수 있을까요? 많은 기업이 여전히 이 문제를 파악하고 있습니다. 하지만 이 공식이 가이드로서 유용하기 위해 반드시 측정 가능할 필요는 없습니다.

핵심 통찰: 가치가 0이면 결과는 −100%입니다. 여기서 분모를 최적화하는 것은 무의미합니다. 무료로 얻은 오답도 여전히 오답입니다. 심지어 더 나쁜 것은, 낮은 비용을 목표로 최적화하는 것이 종종 낮은 가치를 _유발_한다는 것입니다. 저렴한 모델과 부실한 컨텍스트는 좋지 않은 출력을 만들어내고, 당신은 그 출력에 디버깅 비용을 지불합니다. 이제 당신은 잘못된 실행에 대한 토큰, 디버그 세션에 대한 토큰, 수정 작업에 대한 토큰, 그리고 당신 자신의 시간까지 소비했습니다.

반대 측면: 근원지에서 낭비를 줄이면, 품질과 비용이 함께 개선됩니다. 개발자로서 우리가 잘못하는 대부분의 일은 다음과 같습니다:

• 관련 없는 파일을 컨텍스트 창에 채워 넣는 것
• 계속 지불하게 되는 쓸모없는 턴(turn)으로 대화가 복리되어 쌓이게 두는 것
• 하나의 모델에게 더 작고 저렴한 모델이 더 잘 처리할 수 있는 작업을 맡기는 것

이것들을 다듬으면, 청구서 금액은 줄어들고 품질은 올라갑니다.

명확히 하자면: 이 글에서 제시하는 일부 제어 장치들은 단일 실행의 토큰 수를 _증가_시킬 것입니다. 추론 모델(reasoning model)은 작은 모델보다 비용이 많이 듭니다. 루프 내 테스트(Tests in the loop)는 도구 호출(tool calls)을 추가합니다. 서브에이전트(Subagents)는 두 번째 컨텍스트를 구동합니다. 여기서의 트레이드오프는 요청당 원시 토큰 수(raw tokens per request)가 아니라 시도 전체의 총비용입니다.

에이전트에 적용된 표준 ROI(Return on Investment) 계산법: 비용 대비 순가치(net value over cost), 백분율.

복리 오류 문제 (The compounding error problem)

품질이 생각보다 더 중요하다는 또 다른 이유가 있습니다. LLM은 비결정적(non-deterministic)입니다. 오차 범위가 존재합니다. 매 단계마다 100% 정확하지 않습니다. 다단계 에이전트 워크플로우에서, 그 오류는 복리됩니다.

수학을 보겠습니다:

단계별 정확도	10단계 후	50단계 후
99%	90%	61%
...
읽으신 그 표를 두 번 읽어보세요. 매 단계 95퍼센트라는, 굉장히 좋아 보이는 수치로도 긴 워크플로우에서는 8퍼센트에 머무릅니다. 대부분의 실제 에이전트 세션은 50단계보다 훨씬 많은 내부 단계를 가집니다.

이것이 모든 에이전트가 실패한다는 의미는 아닙니다. 여러분이 수행하는 모든 품질 개선이 선형적인(linear) 이득을 가져다주지 않는다는 의미입니다. 대신 복리(compounding)적인 이득을 가져다줍니다. 그리고 모든 실수(miss)는 실제 비용을 발생시킵니다. 낭비된 토큰(tokens), 버그 수정 실행, 리뷰 사이클, 인간의 시간, 그리고 때로는 운영 환경(production)에서의 장애(incident)까지 말입니다.

복리적인 정확도: 단계당 99%의 정확도는 50단계를 거치면 여전히 61%에 불과합니다.

전통적인 소프트웨어에서는 이를 '시프트 레프트(shift-left)' 운동으로 해결했습니다. 품질, 테스트, 보안을 앞당기는(shift-left) 것입니다. 이 운동은 에이전트 시스템(agentic systems)에서 훨씬 더 중요합니다. 초기에 올바르게 처리하는 비용은 나중에 틀렸을 때 발생하는 비용보다 훨씬 작습니다.

한 줄 요약

토큰의 개수를 세는 대신, 모든 토큰이 가치를 갖게 하세요.

더 높은 정확도로 더 적은 로켓을 보내면, 연료 비용은 자연스럽게 줄어듭니다.

전체 핵심 내용을 한 줄로 요약하면 이렇습니다.

기초: 에이전트가 실제로 작동하는 방식

이해하지 못하는 것은 최적화할 수 없습니다. 짧은 요약입니다. 이미 이 분야에 익숙하다면 건너뛰셔도 좋습니다.

LLM은 토큰 확률 기계입니다

LLM은 텍스트를 입력받아 텍스트를 출력하는 기계입니다. 내부적으로는 토큰 확률 기계(token probability machine)입니다. 입력된 모든 정보와 학습 데이터(training data)를 바탕으로, 가장 확률이 높은 다음 토큰을 예측합니다. 그다음 토큰, 그다음 토큰을 예측합니다. '다음 단어'라는 개념이 멘탈 모델(mental model)로서 충분히 적절합니다.

최신 모델들은 추론(reasoning), 도구 사용(tool use), 더 큰 컨텍스트(context), 그리고 코드에 대한 편향(biases)을 추가합니다. 하지만 근본적인 엔진은 동일합니다.

핵심 원칙: 컨텍스트 균형

LLM을 다룰 때 가장 중요한 단 하나의 규칙은 다음과 같습니다:

가능한 한 적은 컨텍스트를 제공하되, 필요한 만큼은 제공하라.

어느 한 방향으로든 균형을 놓치면 품질을 잃게 됩니다.

**너무 많은 컨텍스트 (Too much context)**는 모델이 무관한 정보에 편향되게 만듭니다. 수학적으로는 "유용한 정보"와 "노이즈 (noise)"를 구분하지 못합니다. 작은 변경 사항을 위해 거대한 코드베이스를 컨텍스트에 집어넣으면, 모델은 수백 개의 상충하는 신호들과 싸워야 합니다.

너무 적은 컨텍스트 (Too little context) 역시 마찬가지로 좋지 않습니다. 모델은 학습을 통해 알고 있는 지식으로 그 공백을 채우려 하며, 이는 보완을 위한 환각 (hallucination)으로 이어질 수 있습니다. 이런 일이 발생할 때 에러 메시지는 나타나지 않습니다. 모델은 "정보가 더 필요합니다"라고 말하지 않습니다. 그저 무언가를 지어낼 뿐입니다. 수학적으로는 환각과 사실을 구분하지 못합니다.

컨텍스트 엔지니어링 (Context engineering)은 근본적인 기술입니다. 다음에 이어지는 모든 것은 이 기술의 변형들입니다.

하네스 (Harness), LLM, 그리고 당신의 설정

컨텍스트 부패 (Context rot): 중간에서의 상실 (lost in the middle), 최신성 편향 (recency bias)

긴 컨텍스트 창 (long context windows)에서는 두 가지 현상이 성능을 저하시킵니다. 두 현상 모두 실제로 존재하며 문서로 입증되었고, 여러분의 작업 방식을 변화시켜야 할 대상입니다.