BPE, 토큰 측정, 비용 최적화
마크다운 문서를 Claude API에 넣었을 때 토큰 한도 초과 오류가 떴습니다. 글자 수는 분명 제한 이내였는데도 말입니다. 그날 처음으로 "토큰이 글자 수랑 같은 게 아니구나"를 몸으로 깨달았습니다. 문서를 아무리 읽어도 체감이 안 됐던 개념이, 오류 한 번에 단번에 박혔습니다.
사실 이 오류를 겪기 전까지 저는 "대충 글자 수 비슷하게 맞추면 되겠지"라고 생각하고 있었습니다. 이건 흔한 오해입니다. 그리고 이 오해는 개발 중 어느 시점에 반드시 문제로 터집니다. 저처럼 오류를 직접 맞닥뜨리거나, 아니면 예산이 예상을 훌쩍 넘어서는 청구서를 받고 나서야 깨닫게 됩니다. 이 글은 그 오류를 맞닥뜨린 뒤 하나씩 파헤친 경험을 바탕으로 씁니다.
BPE와 토큰의 작동 원리
AI 언어 모델은 텍스트를 문자 단위가 아닌 토큰(Token) 단위로 처리합니다. 토큰이란 단어 전체일 수도 있고, 단어의 일부 조각일 수도 있는 텍스트의 최소 처리 단위입니다. 영어 기준으로는 대략 4글자가 1토큰이고, 한국어는 글자 1~2개가 1토큰에 해당하는 경우가 많습니다.
이 토큰을 어떻게 나눌지 결정하는 방식이 BPE(Byte Pair Encoding)입니다. BPE는 원래 데이터 압축 분야에서 쓰이던 알고리즘으로, 자주 등장하는 문자 쌍을 하나의 단위로 합치는 방식을 자연어 처리에 적용한 것입니다. 쉽게 말해, 훈련 데이터에서 "un"과 "able"이 자주 붙어 나온다면 "unable"을 통째로 하나의 토큰으로 만드는 식입니다.
여기서 제가 중요하게 생각하는 부분이 있습니다. BPE의 핵심은 "학습 데이터에 얼마나 자주 등장하느냐"에 따라 토큰이 결정된다는 점입니다. 즉, 모델이 어떤 데이터로 훈련됐느냐에 따라 같은 단어라도 토큰 수가 달라질 수 있습니다. 이 사실을 그냥 "압축 기법을 NLP에 응용한 것"으로만 알고 넘어가면 실무에서 꽤 중요한 함의를 놓치게 됩니다.
제 경험상 이게 가장 두드러지는 곳은 전문 도메인 텍스트입니다. 의료, 법률, 금융 같은 분야의 용어들은 일반 텍스트보다 훨씬 비효율적으로 토큰화될 가능성이 높습니다. 학습 데이터에 해당 용어가 드물게 등장했다면, 모델은 그 단어를 통째로 인식하지 못하고 잘게 쪼개서 처리합니다. 결과적으로 같은 문서라도 전문 용어가 많을수록 토큰 수가 예상보다 훨씬 많이 나옵니다. 이게 비용 예측에서 가장 조심해야 하는 포인트입니다. 설계 단계에서 "우리 서비스는 일반 텍스트를 다루는가, 전문 용어를 다루는가"를 먼저 따져보지 않으면 나중에 청구서 보고 당황하게 됩니다.
오류를 겪은 그날 바로 tiktoken을 설치해 돌려봤습니다. 눈으로 확인한 건, 코드 블록 안의 들여쓰기와 빈 줄이 생각보다 꽤 많은 토큰을 소비하고 있다는 사실이었습니다. 마크다운 기호들, 특히 백틱 세 개로 감싸는 코드 펜스나 헤더의 # 기호들도 토큰을 차지합니다. 글자 수 기준으로 입력 제한을 걸면 이런 서식 문자들이 조용히 토큰을 갉아먹는 걸 놓치게 됩니다. 솔직히 이건 직접 숫자로 보기 전까지는 체감이 잘 안 됩니다.
토큰 측정과 비용 최적화
직접 겪어보니 습관이 완전히 바뀌었습니다. 지금은 API에 텍스트를 넣기 전에 토큰 수를 먼저 측정하는 유틸 함수를 반드시 만들어둡니다. 이게 없으면 개발 중에 예상치 못한 오류가 계속 나옵니다.
토큰 수를 줄이는 전략으로 자주 거론되는 방법 중 하나가 포맷팅 최소화입니다. 마크다운 헤더, 코드 블록, 번호 목록 같은 서식을 줄이면 동일한 내용을 더 적은 토큰으로 전달할 수 있습니다. 이 전략은 비용 측면에서는 분명히 효과가 있습니다.
그런데 저는 이 부분에서 단순화된 조언에 비판적입니다. 구조화된 포맷은 모델이 맥락을 파악하는 데 도움을 주는 경우가 많아서, 포맷을 무조건 걷어내면 출력 품질이 떨어지는 경우도 있습니다. 토큰 절감과 출력 품질 사이의 트레이드오프를 고려해야 합니다. 비용만 보고 서식을 날리면 나중에 응답 품질 문제로 더 큰 손해를 볼 수 있습니다. "포맷을 줄이면 무조건 좋다"는 말은 반쪽짜리입니다. 제가 실제로 겪은 케이스에서 JSON 출력을 요구하는 프롬프트의 서식을 지워봤더니, 모델이 간간이 형식을 어기는 빈도가 높아졌습니다. 토큰은 줄었지만 파싱 오류가 늘었고, 결국 재처리 비용이 발생했습니다. 줄이기 전에 실험부터 하는 게 맞습니다.
컨텍스트 윈도우(Context Window)라는 개념도 함께 이해해야 합니다. 컨텍스트 윈도우란 모델이 한 번에 처리할 수 있는 최대 토큰 수를 의미합니다. 입력 토큰과 출력 토큰을 합산한 값이 이 한도를 초과하면 오류가 발생하거나 앞쪽 내용이 잘려나갑니다. 긴 대화나 문서 요약 기능을 만들 때 이 한도를 항상 염두에 두어야 합니다.
실무에서 토큰 비용을 관리할 때 제가 실제로 적용하는 체크포인트는 이렇습니다. API 호출 전 tiktoken으로 입력 토큰 수를 측정하는 유틸 함수를 작성하고, 도메인 특화 텍스트는 별도 토큰 검증 테스트를 진행하며, 시스템 프롬프트를 최대한 간결하게 유지해 매 호출마다 낭비되는 토큰을 최소화합니다. 컨텍스트 윈도우 대비 예상 출력 토큰을 사전에 계산하고 버퍼를 확보하는 것도 빠뜨릴 수 없습니다.
지금은 팀원이 새로 합류하면 tiktoken으로 직접 토큰을 세어보는 실습을 제일 먼저 시킵니다. 이론으로 설명하는 것보다 직접 텍스트를 넣어보고 숫자가 달라지는 걸 눈으로 확인하는 편이 훨씬 빠르게 체감됩니다. 같은 텍스트를 한국어로 쓸 때와 영어로 쓸 때 토큰 수 차이가 얼마나 나는지, 마크다운 서식을 넣었을 때와 뺐을 때가 얼마나 다른지를 직접 확인하는 것만으로도 설계할 때 시야가 완전히 달라집니다.
토큰은 AI 비용과 성능 모두에 직결되는 개념입니다. 글자 수랑 비슷한 거라고 퉁치고 넘어가면 결국 어느 시점에 저처럼 오류를 맞닥뜨리게 됩니다. tiktoken을 한 번이라도 직접 돌려보는 것, 그게 가장 빠른 이해의 시작입니다. BPE가 학습 데이터 기반으로 작동한다는 사실, 도메인 특화 텍스트일수록 토큰 소비가 늘어난다는 사실, 그리고 포맷팅 축소에는 품질 트레이드오프가 따른다는 사실을 설계 단계부터 고려해두면 나중에 훨씬 덜 고생합니다.
참고
OpenAI Tokenizer: https://platform.openai.com/tokenizer
tiktoken GitHub: https://github.com/openai/tiktoken
BPE 논문 원본: https://arxiv.org/abs/1508.07909