프롬프트 토큰을 줄이면 정말 돈이 굳을까? 토큰 압축의 함정

요즘 다들 "토큰 아끼자"고 하잖아요

LLM(거대 언어 모델, 쉽게 말하면 챗GPT 같은 AI 모델)을 API로 가져다가 서비스를 만들다 보면, 제일 먼저 부딪히는 현실이 바로 '비용'이거든요. 이 모델들은 글자 수가 아니라 '토큰(token)'이라는 단위로 요금을 매겨요. 토큰이 뭐냐면, 모델이 글을 잘게 쪼개서 이해하는 조각이에요. 영어 단어 하나가 토큰 하나가 되기도 하고, 긴 단어나 한글은 여러 조각으로 나뉘기도 해요. 어쨌든 입력에 넣는 토큰이 많을수록, 그리고 모델이 뱉어내는 토큰이 많을수록 돈이 더 나가는 구조예요.

그러다 보니 자연스럽게 "그럼 입력을 압축해서 토큰을 줄이면 돈이 굳지 않을까?" 하는 발상이 나와요. 특히 JSON처럼 중괄호, 따옴표, 반복되는 키 이름이 잔뜩 들어가는 데이터를 모델한테 넘길 때, 이걸 더 짧고 빽빽한 포맷으로 바꾸면 토큰이 확 줄 거라는 거죠. RTK 같은 '토큰 압축' 방식이 바로 이런 아이디어에서 출발했어요. 그런데 이번 글을 쓴 개발자는 여기에 대고 "정말 그게 이득이 맞아요?" 하고 솔직하게 의심을 던집니다. 오늘은 그 회의론이 왜 설득력이 있는지 차근차근 풀어볼게요.

압축이 생각만큼 안 먹히는 첫 번째 이유: 토크나이저

가장 먼저 알아야 할 게 있어요. 토크나이저(tokenizer)는 글자 수로 세지 않아요. 우리가 보기엔 따옴표랑 공백을 다 지웠으니 글자가 절반으로 줄었다 싶어도, 토큰 개수는 그만큼 줄지 않는 경우가 많거든요.

왜냐면 요즘 모델들은 BPE(Byte Pair Encoding)라는 방식을 써요. 이게 뭐냐면, 자주 같이 등장하는 글자 묶음을 통째로 하나의 토큰으로 기억해두는 방법이에요. 예를 들어 JSON에서 "name": 같은 패턴은 워낙 흔하게 나오니까 토크나이저가 이걸 거의 한두 토큰으로 효율적으로 처리해버려요. 그래서 우리가 "키 이름이 기니까 줄여야지" 하고 빡세게 압축해봤자, 정작 토큰 절감은 기대치의 절반도 안 나오는 일이 흔합니다. 반대로 낯선 약어나 특수문자를 막 집어넣으면 오히려 토큰이 잘게 쪼개져서 더 늘어나기도 해요.

두 번째 이유: 정확도라는 숨은 비용

더 무서운 건 따로 있어요. 모델은 인터넷에 널려 있는 JSON을 어마어마하게 학습했어요. 그래서 JSON은 모델한테 '모국어'에 가까운 익숙한 포맷이거든요. 그런데 토큰 아끼겠다고 듣도 보도 못한 압축 포맷을 들이밀면, 모델이 살짝 헷갈려 해요. 필드를 잘못 매칭하거나, 값을 빠뜨리거나, 엉뚱하게 해석하는 일이 늘어나는 거죠.

그러면 어떻게 될까요? 출력이 이상하게 나오니까 다시 호출하게 되고, 결국 토큰을 더 쓰게 돼요. 입력에서 아낀 토큰을 재시도하느라 다 까먹는 셈이죠. 게다가 잘못된 결과가 그대로 사용자한테 나가버리면 그건 돈보다 더 큰 손해고요. 그래서 토큰 압축은 단순히 '몇 토큰 아꼈나'만 볼 게 아니라 '정확도가 떨어지지 않았나'를 반드시 같이 봐야 해요.

세 번째 이유: 진짜 돈이 새는 곳은 따로 있어요

그리고 냉정하게 보면, 데이터 포맷에서 아끼는 토큰은 사실 푼돈인 경우가 많아요. 진짜 비용을 잡아먹는 건 매번 똑같이 붙는 긴 시스템 프롬프트, 예시를 잔뜩 넣는 few-shot(모델한테 "이렇게 답해줘" 하고 보여주는 샘플들), 그리고 무엇보다 모델이 출력하는 토큰이거든요. 출력 토큰은 보통 입력보다 단가가 더 비싸기까지 해요. 그런데 사람들은 정작 큰돈이 새는 출력 쪽은 안 건드리고, 입력 데이터 포맷을 1%씩 쥐어짜는 데 시간을 쏟곤 합니다.

업계에서는 이런 흐름이에요

사실 이건 RTK만의 이야기가 아니에요. 최근에 TOON(Token-Oriented Object Notation)처럼 "JSON보다 토큰을 적게 먹는 포맷"을 표방하는 시도가 계속 나오고 있고, CSV나 YAML로 데이터를 넘기자는 논쟁도 자주 벌어져요. 한쪽에는 LLMLingua 같은 '프롬프트 압축' 연구도 있는데, 이건 아예 모델을 한 번 더 써서 프롬프트에서 덜 중요한 부분을 솎아내는 방식이라 결이 좀 달라요. 공통점은 다들 "토큰이 곧 돈"이라는 압박에서 나온 해법이라는 거예요. 다만 어느 것도 "무조건 이득"인 만능 해법은 아니라는 게 핵심이에요.

한국 개발자에게 주는 시사점

실무에서 바로 적용할 교훈은 명확해요. 추측하지 말고 측정하세요. 압축 포맷을 도입하기 전에 본인이 실제로 쓰는 모델의 토크나이저(예: tiktoken)로 우리 데이터를 직접 돌려보고, 진짜 몇 토큰이 줄어드는지 숫자로 확인하는 게 먼저예요. 그리고 그 절감액이 정확도 하락이라는 위험을 감수할 만큼 큰지도 따져봐야 하고요.

오히려 더 큰 효과를 보고 싶다면, 요즘 대부분의 API가 지원하는 프롬프트 캐싱을 먼저 켜보세요. 매번 똑같이 들어가는 시스템 프롬프트를 캐싱해두면 그 부분 비용이 확 떨어지거든요. 포맷 쥐어짜기보다 훨씬 안전하고 효과도 커요. 결국 비용 최적화는 '느낌'이 아니라 '계측'의 영역이에요.

마무리

한 줄로 정리하면, 토큰 압축은 글자를 줄이는 게 아니라 토큰을 줄여야 의미가 있고, 그마저도 정확도와 맞바꾸면 손해일 수 있다는 거예요. 여러분은 토큰 비용 줄일 때 포맷부터 손대는 편인가요, 아니면 캐싱·출력 길이부터 잡는 편인가요? 실제로 압축 포맷 도입해서 효과 본 적 있다면 그 경험도 들려주세요.