내 프롬프트는 몇 토큰일까?

언어 모델은 글자나 단어를 읽지 않습니다. 학습 데이터로부터 얻은 고정 어휘에 따라 텍스트를 쪼갠 조각, 즉 토큰을 읽습니다.

흔한 단어는 보통 토큰 하나입니다. 희귀한 단어는 여러 조각으로 쪼개집니다. 공백은 대개 다음 토큰의 앞에 붙기 때문에, 같은 단어라도 문장 맨 앞에 오느냐에 따라 개수가 달라질 수 있습니다.

GPT-4o의 토크나이저로 실제로 측정해 보면, unbelievable이라는 단어는 단독으로 놓였을 때 토큰 세 개입니다. un + bel + ievable로 쪼개지죠. 반면 문장 속에 실제로 등장하는 형태, 즉 앞에 공백이 붙은 unbelievable은 토큰 하나입니다. 앞선 공백 규칙이 작동한 결과입니다. 이 단어는 실제 글에서 거의 언제나 공백이 앞에 붙은 채로 나타나므로, 모델이 학습한 항목도 공백이 붙은 형태입니다. the와 international도 마찬가지로, 공백을 포함하면 각각 토큰 하나입니다.

토큰 개수가 예측하기 어렵게 느껴지는 이유가 여기 있습니다. 그 단위는 언어학적이지 않고 통계적입니다. 학습 코퍼스에서의 빈도가 어떤 것이 토큰 하나인지 네 개인지를 결정합니다.

영어 산문 기준으로, GPT-4o의 토크나이저를 써서 구어체에 가까운 글부터 기술 문서에 이르기까지 여러 문체에 걸쳐 측정한 값입니다. 아래 수치는 어디까지나 영어에 대한 것이며 한국어에는 그대로 적용되지 않습니다:

• 1토큰 ≈ 4.3~5.9글자
• 1토큰 ≈ 0.75~0.95단어
• 1,000단어 ≈ 1,050~1,350토큰
• 표준 한 페이지(약 500단어) ≈ 530~680토큰

문체가 미치는 영향은 대부분의 경험칙이 인정하는 것보다 큽니다. 가볍게 대화하듯 쓴 글은 이 범위의 아래쪽, 1,000단어당 약 1,060토큰에 머뭅니다. 흔한 단어로 이루어진 좁은 어휘를 되풀이해 쓰는데, 그런 단어는 하나하나가 토큰 하나에 들어맞기 때문입니다. 밀도 높은 기술 산문 — 이 사이트의 가이드들도 여기 속합니다 — 은 전문 용어가 여러 조각으로 쪼개지는 탓에 범위의 위쪽, 약 1,310토큰에 자리합니다. 흔히 인용되는 1,000단어당 1,300토큰이라는 단일 수치는 이 범위의 중간이 아니라 기술 문서 쪽 끝이며, 그래서 평범한 글은 5분의 1가량 과대평가합니다. 다만 컨텍스트 창 예산을 잡을 때라면 틀리더라도 그쪽으로 틀리는 편이 안전합니다.

일반적인 산문을 벗어나면 이 기준은 금방 무너집니다:

콘텐츠 유형	대략적인 수치
영어 산문	문체에 따라 토큰당 0.75~0.95단어
코드	같은 글자 수의 산문보다 약 1.2배, 같은 내용을 양쪽으로 표현했을 때는 대략 1.5배
긴 키를 가진 JSON	매우 높음 — 문장 부호와 따옴표가 별도 토큰
중국어, 일본어, 한국어	문자당 약 0.6~0.7토큰 — 글자 수보다는 적지만, 같은 글자 수의 영어에 비하면 몇 배
키릴 문자, 데바나가리, 아랍어	같은 내용의 영어보다 약 1.4~1.6배
URL과 해시	극도로 높음 — 무작위 문자열은 토큰화 효율이 나쁨
반복된 공백	비싸지 않고 오히려 쌈 — 바이트 페어 인코딩이 긴 묶음을 하나로 합치므로 공백 마흔 개가 토큰 하나

다국어 격차는 실재하지만 흔히 도는 이야기보다는 훨씬 작습니다. 이 사이트의 영어 페이지와 그 전문 번역본을 측정해 보면, 일본어판은 영어의 약 1.7배, 한국어판은 약 1.5배, 중국어판은 약 1.2배, 힌디어판은 약 1.6배, 아랍어판은 약 1.4배입니다. 예전 cl100k_base 토크나이저에서는 같은 쌍이 각각 2.3배, 2.3배, 1.7배, 4.7배, 2.9배였고, "영어의 두세 배"라는 널리 퍼진 수치는 여기서 나왔습니다. 그때는 사실이었지만, 새 어휘들이 그 격차를 상당 부분 좁혔습니다.

모델 계열마다 자체 어휘를 가진 고유한 토크나이저를 사용하므로, 같은 텍스트도 개수가 다르게 나옵니다.

GPT 모델은 바이트 페어 인코딩의 변형을 사용합니다. GPT-4 시대 모델은 cl100k_base, 더 최신 모델은 o200k_base입니다. Claude는 다른 어휘를 가진 별도의 토크나이저를 사용합니다. Llama, Mistral 같은 오픈 모델도 각각 자체 토크나이저를 씁니다.

어휘 차이가 가장 크게 벌어지는 곳은 코드와 영어 이외의 텍스트이며, 개수 차이도 바로 거기서 가장 크게 벌어집니다.

실무적으로 이것이 의미하는 바는:

• 한 토크나이저의 개수는 다른 모델에 대해서는 추정치일 뿐입니다.
• 정확한 과금 기준 숫자는 해당 제공사의 토크나이저만 알려줍니다.
• 한도에 딱 맞추기보다 여유를 두고 예산을 잡으세요.

토큰 계산기는 GPT-4o 기준 개수와 Claude 추정치를 나란히 보여줍니다. GPT-4o 쪽 숫자는 실제 토크나이저로 센 값입니다. Claude 쪽 숫자는 의도적으로 그렇지 않습니다. Anthropic은 브라우저에서 실행할 수 있는 토크나이저를 공개하지 않으므로, 3.5글자당 1토큰이라는 글자 수 기반 추정치를 씁니다. 영어 산문에서 이 추정치는 GPT-4o 개수보다 22~50% 높게 나오며, 일반적인 글에서는 3분의 1가량 높습니다. 따라서 두 숫자의 차이는 두 모델 계열 사이에서 실제로 측정된 차이가 아니라 추정의 폭으로 읽어야 합니다. 그래도 이 두 숫자면 프롬프트가 한도 안에 여유 있게 들어가는지 아슬아슬한지 판단하기에는 충분합니다. 숫자가 정확해야 한다면 해당 제공사의 계산기를 쓰세요.

비용. API 가격은 토큰 단위이며 입력과 출력이 따로 책정되고, 출력이 보통 몇 배 더 비쌉니다. 시스템 프롬프트를 두 배로 늘리면 매 호출마다 그 비용이 두 배가 됩니다. 테스트에서는 보이지 않다가 규모가 커지면 비싸지는 대표적인 사례입니다.

컨텍스트 한도. 창에는 모든 것이 포함됩니다. 시스템 프롬프트, 대화 기록, 검색된 문서, 현재 메시지, 그리고 답변을 위해 남겨둔 공간까지요. 긴 대화가 실패하는 이유는 어느 한 메시지가 길어서가 아니라 기록이 누적되기 때문입니다.

잘림. 입력이 한도를 넘으면 무언가가 버려집니다. 종종 아무 알림 없이, 그리고 종종 가장 이른 내용부터요. 지시를 "잊어버린" 모델은 사실 지시가 잘려 나간 경우가 많습니다.

검색을 위한 청킹. 임베딩용 문서 분할은 글자가 아니라 토큰 단위로 이루어집니다. 글자 수로 자른 청크는 크기가 들쭉날쭉해지고, 문장 중간에서 끊긴 청크는 검색 품질이 나쁩니다. 그래서 검색 파이프라인에는 문장과 문단 구조를 존중하는 분할기가 필요합니다. 저희 텍스트 분할 도구는 그런 도구가 아닙니다. 최대 2,000자의 고정 크기 청크로 자르되 가장 가까운 공백에서 끊기 때문에 단어가 반으로 갈리지는 않지만, 청크가 문장 중간에서 끝날 수 있습니다. 긴 문서를 컨텍스트 창이나 붙여넣기 한도에 맞춰 넣을 때 쓰시고, 검색용 임베딩 청크를 만드는 데는 쓰지 마세요.

효과가 큰 순서대로 대략 정리하면:

1. 대화 기록 줄이기. 긴 대화에서는 이것이 다른 모든 것을 압도합니다. 이전 턴을 그대로 다시 보내지 말고 요약해서 보내세요.
2. 중복 지시 제거. 같은 규칙을 세 가지 방식으로 반복한다고 지켜질 확률이 세 배가 되지는 않습니다. 그 규칙의 비용만 확실히 세 배가 됩니다.
3. 서식 잔재 제거. 보이지 않는 문자, 반복된 공백, 장식용 구분선은 모두 토큰이 됩니다. 다만 하나하나는 흔히 생각하는 것보다 쌉니다. 바이트 페어 인코딩이 긴 묶음을 하나로 합치기 때문에, 연속된 공백 마흔 개는 토큰 하나이고 하이픈 마흔 개짜리 구분선은 둘인 반면 바로 위 문장은 열셋입니다. 그래도 순수한 군더더기이고, 절마다 구분선이 들어간 문서에서는 쌓이면 무시할 수 없습니다. 보이지 않는 문자 제거로 눈에 보이지 않는 것들을 지울 수 있습니다.
4. JSON 키 짧게 하기. 구조화된 프롬프트에서 {"n": ...}과 {"customer_full_name": ...}의 차이는 천 개 레코드에 걸쳐 누적되면 상당합니다.
5. 관련 부분만 보내기. 문서 전체를 붙여넣는 것보다 관련 문단 세 개를 찾아 보내는 편이 낫고, 보통 비용뿐 아니라 답변 품질도 더 좋습니다.

도움이 되지 않는 것들: 일반 문장 부호 제거, 관사 삭제, 전보체처럼 뚝뚝 끊는 문체. 절약 폭은 미미한데 출력 품질 손상은 그렇지 않습니다.