토큰과 컨텍스트 윈도우: LLM 비용과 한계를 결정하는 단위

LLM 요금표는 “100만 토큰당 몇 달러"로 적혀 있고, 모델 스펙표에는 “컨텍스트 윈도우 100만 토큰"이 적혀 있습니다. 이 두 숫자를 정확히 읽을 수 있으면 LLM 도입 비용 계산의 절반은 끝난 셈입니다. 결론을 먼저 적으면, 토큰은 모델이 텍스트를 처리하는 최소 단위이고, 컨텍스트 윈도우는 한 번의 요청에서 모델이 볼 수 있는 토큰 총량의 상한입니다. 비용도, 성능 한계도, 아키텍처 선택도 결국 이 단위 위에서 결정됩니다. API 비용 구조 전반은 LLM API vs 자체 호스팅에서 다뤘고, 이 글은 그 계산의 기초가 되는 단위 자체를 정리합니다.

토큰: 단어도 글자도 아닌 서브워드 #

모델은 텍스트를 단어나 글자가 아니라 토큰(token) 단위로 처리합니다. 학습 데이터에서 자주 등장하는 문자열 조각을 사전으로 만들어 두고, 입력 텍스트를 그 조각들로 쪼개는 방식입니다. BPE(Byte Pair Encoding) 계열 알고리즘이 널리 쓰입니다.

• 영어는 자주 쓰는 단어가 통째로 토큰 하나가 되는 경우가 많아, 대략 4글자당 1토큰꼴입니다.
• internationalization처럼 긴 단어는 international + ization 식으로 몇 조각으로 나뉩니다.
• 한국어, 일본어 같은 언어는 사전에서 차지하는 비중이 영어보다 작아, 같은 내용을 표현해도 토큰 수가 더 많이 나옵니다. 모델에 따라 다르지만 영어 대비 1.5〜2배 정도로 잡는 것이 안전합니다.

여기서 중요한 사실이 하나 나옵니다. 토큰 수는 모델(정확히는 토크나이저)마다 다릅니다. 같은 문서라도 A사 모델과 B사 모델의 토큰 수가 다르고, 같은 회사 안에서도 모델 세대가 바뀌면서 토크나이저가 교체되어 동일 텍스트의 토큰 수가 30% 가까이 달라진 사례가 실제로 있습니다. 다른 모델용 토크나이저 라이브러리로 추정한 수치를 그대로 믿으면 안 되고, 각 벤더가 제공하는 토큰 카운트 API로 실제 사용할 모델에 대해 측정해야 합니다.

비용 구조: 입력과 출력은 단가가 다릅니다 #

LLM API 요금은 입력 토큰과 출력 토큰을 따로 계산하고, 출력 단가가 입력의 3〜5배입니다. 생성은 토큰을 하나씩 순차적으로 만들어야 해서 연산 비용이 더 들기 때문입니다. 그래서 같은 100만 토큰이라도 “긴 문서를 읽고 짧게 요약"과 “짧은 지시로 긴 글 생성"의 비용은 크게 다릅니다.

대화형 서비스라면 한 가지가 더 붙습니다. LLM API는 상태가 없어서, 매 턴마다 이전 대화 전체를 입력으로 다시 보냅니다. 10번째 턴의 입력에는 앞선 9턴의 질문과 답변이 전부 포함됩니다. 대화가 길어질수록 턴당 입력 토큰이 누적으로 늘어나므로, 총 비용은 턴 수에 비례가 아니라 그보다 가파르게 증가합니다. 긴 대화를 방치하면 비용이 조용히 불어나는 구조입니다.

이 구조를 완화하는 장치가 두 가지 있습니다.

• 프롬프트 캐싱: 매 턴 반복 전송되는 앞부분(시스템 프롬프트, 대화 히스토리)을 서버 측에 캐시해 두면, 캐시된 구간은 정가의 10분의 1 수준으로 처리됩니다. 캐시 기록 시에는 소폭의 프리미엄이 붙지만, 같은 프리픽스를 두 번 이상 쓰면 이득입니다. 단 캐시는 앞에서부터의 완전 일치(prefix match)라서, 프롬프트 앞부분에 타임스탬프처럼 매번 바뀌는 값을 넣으면 캐시가 전부 무효화됩니다.
• 배치 API: 실시간 응답이 필요 없는 작업을 모아 보내면 대부분의 벤더가 50% 할인을 제공합니다.

컨텍스트 윈도우: 모델이 한 번에 보는 범위 #

컨텍스트 윈도우는 한 요청에서 모델이 다룰 수 있는 토큰 총량입니다. 시스템 프롬프트, 대화 히스토리, 첨부 문서, 도구 정의, 그리고 모델이 생성하는 출력까지 전부 이 안에 들어가야 합니다. 2026년 현재 주요 모델은 20만〜100만 토큰이 표준이고, 그 이상을 제공하는 모델도 있습니다. 100만 토큰이면 대략 소설 열 권 분량의 텍스트입니다.

두 가지를 구분해야 합니다.

요청 시 지정하는 max_tokens는 출력 상한을 정하는 값입니다. 너무 낮게 잡으면 응답이 문장 중간에서 잘리고, 잘린 응답을 다시 요청하면 이중으로 비용이 듭니다. 응답이 잘렸는지는 응답에 포함된 종료 사유(stop reason) 필드로 확인할 수 있습니다.

큰 컨텍스트의 함정: 넣을 수 있다와 잘 쓴다는 다릅니다 #

컨텍스트 윈도우가 커지면서 “문서를 통째로 넣으면 되지 않나"라는 접근이 가능해졌지만, 두 가지 함정이 있습니다.

1. 성능 저하: 컨텍스트가 매우 길어지면 모델이 중간에 위치한 정보를 놓치는 경향이 보고되어 있습니다(lost in the middle). 최신 모델은 많이 개선됐지만, 컨텍스트를 가득 채운 상태의 정확도가 짧은 컨텍스트와 같다고 가정하면 안 됩니다. 중요한 정보는 앞이나 뒤에 배치하는 것이 여전히 유효한 요령입니다.
2. 비용: 입력 토큰은 매 요청 과금됩니다. 100만 토큰짜리 문서를 넣고 질문 10개를 던지면 입력 비용을 10번 내는 셈입니다. 캐싱으로 완화할 수 있지만, 필요한 부분만 검색해서 넣는 RAG가 구조적으로 저렴한 경우가 많습니다.

문서 전체를 넣을지, 검색해서 일부만 넣을지, 아예 모델에 학습시킬지의 판단 기준은 RAG vs 파인튜닝 vs 롱 컨텍스트에서 자세히 다뤘습니다.

실무 체크리스트 #

• 측정부터 합니다. 대표 프롬프트를 벤더의 토큰 카운트 API로 실측하고, 거기에 예상 트래픽을 곱해 월 비용을 추정합니다. 다른 모델 기준의 추정치를 재사용하지 않습니다.
• 한국어 서비스는 토큰 팽창을 반영합니다. 영어 기준 벤치마크 비용에 1.5〜2배를 곱해 보수적으로 잡습니다.
• 히스토리를 관리합니다. 오래된 턴을 요약하거나 잘라내는 로직을 처음부터 넣습니다. 벤더에 따라 서버 측에서 자동으로 압축해 주는 기능도 제공됩니다.
• 캐싱을 전제로 프롬프트를 설계합니다. 고정 내용(시스템 프롬프트, 도구 정의)은 앞에, 매번 바뀌는 내용은 뒤에 배치합니다.
• max_tokens와 종료 사유를 함께 봅니다. 잘림을 감지하지 못하면 불완전한 응답이 그대로 사용자에게 나갑니다.

정리 #

• 토큰은 서브워드 단위이고, 토큰 수는 토크나이저마다 다릅니다. 실제 사용할 모델의 카운트 API로 측정하는 것이 유일하게 정확한 방법입니다.
• 한국어는 같은 내용도 영어보다 토큰을 더 씁니다. 비용 추정에 반영해야 합니다.
• 요금은 입력·출력 단가가 다르고, 대화는 히스토리 재전송 때문에 길어질수록 가파르게 비싸집니다. 프롬프트 캐싱과 배치 API가 주요 완화 수단입니다.
• 컨텍스트 윈도우는 입력과 출력을 합친 상한이고, 최대 출력 토큰은 별도 스펙입니다.
• 넣을 수 있다고 다 넣는 것이 최선은 아닙니다. 긴 컨텍스트는 성능과 비용의 함정이 있고, RAG와의 선택은 워크로드에 따라 갈립니다.