출력만 늘었을 뿐인데 왜 한도에 걸릴까 — 바이브 코더가 알아야 할 토큰의 진실

클로드 코드로 며칠째 기능 하나를 붙잡고 있던 날이었다.

리팩터링 범위가 좀 컸다. 파일을 여러 개 고치고, 로그를 길게 뽑아 확인하고, 에이전트가 코드를 잔뜩 출력하게 만들었다.

그런데 이상했다. 한도 경고가 평소보다 훨씬 빨리 떴다. 분명 어제는 비슷한 시간 작업해도 멀쩡했는데, 오늘따라 세션이 자꾸 리셋됐다.

처음엔 "오늘따라 서버가 이상한가" 싶었다. 그런데 몇 번 더 겪어보니 패턴이 보였다.

출력이 많이 나오는 작업일수록 유독 빨리 한도에 부딪혔다. 운이 아니었다. 토큰이 소모되는 구조 자체의 문제였다.

 

 

 

토큰, 정확히 뭘 세는 걸까

토큰은 단어도, 글자도 아니다. 그 중간 어딘가에 있는, AI가 텍스트를 이해하고 만들어내는 최소 단위다.

"안녕하세요" 같은 자연스러운 한 단어도 내부적으로는 "안녕"과 "하세요"로 쪼개질 수 있다. 반대로 영어 단어 하나가 통째로 토큰 하나가 되기도 한다. 크기가 일정하지 않다는 게 핵심이다.

여기서 한국어 사용자라면 알아둘 게 하나 있다. 한글은 초성·중성·종성이 결합된 문자 구조라, 토큰화 과정에서 영어보다 더 잘게 쪼개지는 경향이 있다. 여러 매체에서 한국어가 영어보다 2~5배 많은 토큰을 쓰는 것으로 보고하고 있다. 국내 개발자가 유독 한도를 빨리 체감하는 이유 중 하나다.

토큰에는 두 종류가 있다. 내가 입력하는 프롬프트가 소비하는 입력 토큰, AI가 만들어내는 출력 토큰.

이 둘은 무게가 다르다. Claude API 기준으로 출력 토큰의 가격은 입력 토큰의 5배다. 모델이 한 토큰씩 순차적으로 계산해 만들어내는 자기회귀적 생성 방식 때문에, 출력 과정 자체의 계산량이 입력을 한 번에 처리하는 것보다 크다.

그러니까 코드를 잔뜩 뽑아내거나 긴 설명을 쓰게 만드는 작업일수록, 한도가 유독 빨리 닳는다.

 

모델별 입력 토큰과 출력 토큰 가격을 비교하는 표

 

 

 

 

왜 하필 출력이 많을 때 한도가 먼저 오나

진짜 원인은 이거다. LLM은 대화를 기억하지 않는다. 매 요청마다 지금까지의 대화 전체를 컨텍스트 윈도우 안에 다시 통째로 담아 처리한다.

대화가 길어질수록, 그 안에 담긴 출력이 많을수록 — 다음 요청 하나를 처리하는 데 드는 토큰 양이 계속 쌓인다.

리팩터링 작업을 예로 들어보자. 에이전트가 파일 하나를 고치면서 수정된 코드 전체를 출력한다. 다음 요청에서는 방금 출력했던 코드까지 포함한 대화 전체가 다시 입력으로 들어간다.

코드 몇 줄 고쳤을 뿐인데, 실제로 처리되는 토큰 양은 기하급수적으로 늘어난다. 출력이 많은 작업에서 유독 빨리 한도에 걸렸던 것도 정확히 이 구조 때문이었다.

 

대화 턴이 반복될수록 컨텍스트가 누적되어 한도에 도달하는 과정을 보여주는 다이어그램

 

 

 

 

compact가 뜨는 순간, 실제로 무슨 일이 벌어지나

한도가 가까워지면 "대화를 압축(compact)하겠다"는 안내가 뜬다.

"그동안 작업한 게 다 날아가나" 싶어 불안해하는 사람이 많다. 하지만 정확히는 대화 전체를 버리는 게 아니라 핵심만 남기고 나머지를 요약으로 대체하는 과정이다.

문제는 이 압축 과정에서 초반에 세워둔 세부 규칙이나 맥락이 요약본에 다 담기지 못할 수 있다는 것. 그래서 compact 이후에 에이전트가 방금 전 지시사항을 살짝 놓친 것처럼 느껴지는 순간이 온다.

리셋처럼 느껴지지만, 사실은 "기억을 재정리"하는 쪽에 더 가깝다.

이런 컴팩션 이슈까지 포함해서 에이전트가 일하는 환경 자체를 어떻게 설계할지 궁금하다면 하네스 엔지니어링이란? AI 에이전트를 덜 망가뜨리는 실전 방법도 같이 보면 도움이 된다.

 

컴팩션 전과 후의 대화 컨텍스트 크기 변화를 비교하는 다이어그램

 

 

 

 

RAG는 이거랑 무슨 상관일까

토큰·컨텍스트 윈도우와는 결이 조금 다른 개념이지만, 자주 같이 언급되는 게 RAG(검색증강생성)다.

모델은 학습된 시점까지의 정보만 안다. 최신 정보나 특정 문서 내용은 애초에 모를 수 있다.

RAG는 이럴 때 외부 지식 베이스에서 관련 정보를 검색해와 답변 생성에 활용하는 기술이다. 모르는 걸 그때그때 찾아보고 답하는 것과 비슷하다고 생각하면 된다.

한도나 압축 문제를 직접 해결해주진 않는다. 다만 "모델이 왜 이건 모르지"라는 궁금증을 풀어주는 개념이라 함께 알아두면 좋다.

 

 

 

토큰을 많이 쓸수록 진짜 생산적일까 — '토큰 맥싱' 논쟁

최근 실리콘밸리에서는 토큰을 최대한 많이 쓰는 걸 자랑스러워하는 문화가 화제였다. 이른바 토큰 맥싱(token maxxing).

사내에서 누가 토큰을 더 많이 썼는지 순위를 매기고, 1등한테 상까지 준다는 얘기도 나온다. "토큰을 많이 쓸수록 더 생산적"이라는 전제가 깔려 있는 셈이다.

근데 이 전제, 항상 맞는 건 아니다.

실제로 겪어보면 안다. 출력을 무작정 많이 뽑아낸다고 작업이 빨리 끝나지 않는다. 오히려 불필요한 코드나 설명까지 딸려 나와 한도만 더 빨리 소진되는 경우가 많다.

진짜 생산성 차이는 토큰을 '얼마나' 쓰느냐가 아니라 '어떻게' 쓰게 만드느냐에서 갈린다. 필요한 만큼만 정확하게 출력하도록 요청을 다듬는 게, 무작정 많이 뽑아내는 것보다 결과적으로 낫다.

어떤 모델을 어떤 작업에 써야 비용 대비 효율이 좋은지는 Claude Mythos 비용 폭탄 피하는 법: 강한 AI 모델을 정확히 쓰는 6가지 기준에서 더 자세히 다뤘다.

 

 

 

그래서 리셋을 덜 겪으려면

몇 번 리셋을 겪고 나서 바꾼 습관이 있다.

하나의 기능 단위 작업이 끝나면, 다음 작업으로 넘어가기 전에 미리 compact를 걸어 대화를 정리한다. 출력이 길어질 게 뻔한 작업(전체 코드 재출력, 긴 로그 확인 등)은 애초에 필요한 부분만 보여달라고 요청 범위를 좁힌다.

세션이 길어질수록 한도 도달 속도도 같이 빨라진다. 그래서 큰 작업은 아예 여러 세션으로 나눠서 진행한다.

이런 실전 판단 기준을 더 넓게 정리한 글은 Vibe Coding을 믿기 전에 봐야 할 AI 코딩 실전 기준에 담아뒀다.

토큰은 결국 눈에 보이지 않는 자원이다. 한도에 부딪히고 나서야 그 존재를 실감하게 된다.

그 구조를 한 번 제대로 이해하고 나면, 다음부턴 "왜 또 리셋이지"보다 "아, 이 작업은 나눠서 해야겠다"는 판단이 먼저 선다.

 

 

 

 

자주 묻는 질문

 

왜 갑자기 한도 경고가 뜨나요?

매 요청마다 지금까지의 대화 전체가 다시 처리되기 때문이다. 대화가 길어지고 출력이 많아질수록 토큰 소모가 누적돼서, 출력 많은 작업일수록 한도에 더 빨리 도달한다.

 

compact 하면 지금까지 작업한 게 사라지나요?

아니다. 전부 지우는 게 아니라 핵심만 남기고 나머지를 요약으로 대체하는 것이다. 다만 세부 규칙까지 요약에 다 담기지는 않을 수 있다.

 

 

참고 자료

• 가격 정책 - Claude Docs
• 컨텍스트 윈도우 - Claude Platform Docs
• 컨텍스트 윈도우 살펴보기 - Claude Code Docs
• RAG(검색 증강 생성)란? - 모두의연구소
• Token maxxing - Wikipedia