토큰이 뭐길래 요금이 붙나: 컨텍스트 윈도우를 돈으로 읽는 법

요금이 글자 수로 붙지 않는 이유

LLM API를 붙이고 나면 요금이 어떻게 계산되는지가 궁금해집니다. 문서에는 "100만 토큰당 얼마"라고 적혀 있는데, 토큰이 무엇인지 감이 안 오면 비용을 예측할 수가 없습니다.

토큰은 모델이 글자를 다루는 단위입니다. 글자 하나도 아니고 단어 하나도 아닙니다. 자주 등장하는 조각일수록 하나의 토큰으로 묶여 있습니다.

영어 문장은 대략 단어 하나가 토큰 하나에 가깝고, 흔하지 않은 단어는 여러 조각으로 쪼개집니다. 한국어는 영어보다 토큰을 많이 씁니다. 같은 의미의 문장이라도 한국어 쪽이 더 많은 토큰으로 분해되는 경향이 있어, 비용 추정을 영어 기준으로 하면 실제보다 낮게 잡히게 됩니다. 정확한 비율은 모델과 토크나이저에 따라 다르므로, 쓰려는 모델의 토크나이저로 실제 문장을 넣어 세어보는 것이 유일하게 정확한 방법입니다.

입력과 출력의 가격이 다르다

대부분의 제공자가 입력 토큰과 출력 토큰에 다른 단가를 매깁니다. 보통 출력이 더 비쌉니다.

이 사실이 설계에 영향을 줍니다. 긴 문서를 넣고 짧은 요약을 받는 작업은 입력 위주라 상대적으로 저렴하고, 짧은 지시로 긴 글을 생성하는 작업은 출력 위주라 비쌉니다. 같은 기능이라도 "요약해줘"와 "이 주제로 글을 써줘"의 비용 구조가 다릅니다.

그래서 비용을 줄이려 할 때 프롬프트만 다듬는 경우가 많은데, 출력이 긴 기능이라면 최대 출력 길이를 제한하는 쪽이 훨씬 효과가 큽니다.

컨텍스트 윈도우는 한 번에 들고 갈 수 있는 양

컨텍스트 윈도우는 모델이 한 번의 요청에서 다룰 수 있는 토큰의 총량입니다. 입력과 출력이 이 한도를 함께 나눠 씁니다. 입력을 한도 가까이 채우면 출력할 자리가 없어 응답이 중간에 끊깁니다.

대화형 기능을 만들 때 이게 조용히 문제가 됩니다. 대화가 길어지면 이전 내용을 계속 함께 보내게 되고, 매 요청의 입력 토큰이 누적됩니다.

1번째 요청: 시스템 프롬프트 + 질문1
2번째 요청: 시스템 프롬프트 + 질문1 + 답변1 + 질문2
3번째 요청: 시스템 프롬프트 + 질문1 + 답변1 + 질문2 + 답변2 + 질문3

대화가 20번 오가면 마지막 요청의 입력은 처음의 수십 배가 됩니다. 비용이 대화 길이에 비례하는 게 아니라 제곱에 가깝게 늘어난다는 뜻입니다. 이걸 모르고 채팅 기능을 열어두면 요금 고지서에서 발견하게 됩니다.

그래서 무엇을 하나

대화 길이를 관리합니다. 오래된 메시지를 잘라내거나, 앞부분을 요약본으로 대체해 넣는 방식이 일반적입니다. 무엇을 잘라도 되는지는 기능마다 다르므로, 모든 맥락이 항상 필요한지부터 따져봐야 합니다.

시스템 프롬프트를 다이어트합니다. 시스템 프롬프트는 매 요청에 따라붙습니다. 여기 들어간 한 문단이 전체 호출 횟수만큼 곱해집니다. 길게 쓴 지시문이 실제로 결과를 바꾸는지 확인해볼 가치가 있습니다.

출력 상한을 겁니다. 기능에 필요한 길이보다 넉넉하게 열어두면 모델은 그만큼 씁니다.

캐싱을 씁니다. 같은 입력이 반복된다면 결과를 저장해두고 재사용합니다. 제공자에 따라 반복되는 앞부분 입력에 할인을 적용하는 기능을 제공하기도 하는데, 이 경우 변하지 않는 내용을 앞쪽에 배치하는 것이 유리합니다.

모델을 작업별로 나눕니다. 분류나 추출처럼 단순한 작업까지 가장 큰 모델로 처리할 이유가 없습니다. 작은 모델로 충분한 구간을 분리하면 비용 구조가 달라집니다.

비용 추정은 이렇게 시작한다

월 비용 ≈ (요청당 입력 토큰 × 입력 단가 + 요청당 출력 토큰 × 출력 단가) × 월 요청 수

여기서 대부분이 틀리는 지점은 "요청당 입력 토큰"입니다. 시스템 프롬프트, 붙여 넣는 문서, 대화 이력을 빠뜨리고 사용자 질문만 세는 경우가 많습니다. 실제 호출 한 번을 보내보고 응답에 함께 오는 사용량 정보를 확인하는 것이 가장 확실합니다. 대부분의 API가 요청마다 소비한 토큰 수를 응답에 담아 돌려줍니다.

그 숫자를 로그에 남겨두면 나중에 어떤 기능이 비용을 쓰는지 바로 보입니다. 기능별·사용자별로 누적해두면 상한을 걸 근거도 생깁니다.

토큰 수를 미리 정확히 알 수 있나요?

요청을 보내기 전에 토크나이저로 세면 입력 토큰은 정확히 알 수 있습니다. 출력은 생성해봐야 알기 때문에 상한으로 관리하는 수밖에 없습니다. 다만 제공자와 모델마다 토크나이저가 다르므로, 다른 모델의 계산기로 센 값을 그대로 적용하면 어긋납니다.

컨텍스트 윈도우가 크면 전부 넣는 게 낫지 않나요?

넣을 수 있는 것과 넣는 게 좋은 것은 다릅니다. 우선 넣는 만큼 비용이 붙고, 응답도 느려집니다. 그리고 관련 없는 내용이 많이 섞이면 정작 중요한 부분이 묻혀 품질이 떨어지는 경우가 있습니다. 필요한 것만 골라 넣는 작업이 여전히 유효한 이유입니다.

스트리밍을 쓰면 비용이 줄어드나요?

아닙니다. 스트리밍은 생성된 토큰을 나눠 보내는 전송 방식일 뿐, 생성량은 같습니다. 다만 사용자가 중간에 멈출 수 있게 만들면 그 시점 이후의 생성이 중단되므로 실질적으로 줄어드는 효과는 있습니다.

숫자를 한 번 찍어보는 것부터

지금 만들고 있는 기능에서 실제 호출 한 번의 입력·출력 토큰을 확인해보세요. 예상과 다른 경우가 대부분이고, 그 차이가 어디서 오는지 보면 줄일 곳도 같이 보입니다.

AI 기능이 들어간 프로젝트를 만들었다면 Vibeollio에 프로젝트 등록해서 공개해보세요. 실제 사용자가 쓰기 시작하면 예상과 다른 입력이 들어오는데, 비용 구조는 그 지점에서 처음 드러납니다.