쉽게 이해하기

토큰은 LLM이 텍스트를 읽기 위해 사용하는 조각입니다. 영어 단어 하나가 한 토큰이 될 때도 있지만, 긴 단어는 여러 토큰으로 쪼개지고, 공백이나 기호도 별도 토큰이 될 수 있습니다. 그래서 "단어 수"와 "토큰 수"는 같지 않습니다.

토크나이저는 문장을 토큰 ID의 배열로 바꿉니다. 모델은 실제 글자를 직접 보는 것이 아니라 이 숫자 배열을 보고 다음에 올 가능성이 높은 토큰을 계산합니다. 답변도 다시 토큰 ID에서 사람이 읽는 텍스트로 decode됩니다.

비유와 예시

토큰은 문장을 레고 블록으로 분해한 것에 가깝습니다. "unbelievable" 같은 단어는 한 블록이 아니라 "un", "believ", "able"처럼 여러 블록으로 나뉠 수 있습니다. 반대로 자주 등장하는 표현은 하나의 큰 블록처럼 처리될 수 있습니다.

예를 들어 같은 문장이라도 영어, 한국어, 코드, 이모지, 특수기호가 섞이면 토큰 수가 달라집니다. LLM 요금표에서 "1M input tokens"라고 쓰는 이유도 이 단위가 실제 모델 계산량과 더 직접 연결되기 때문입니다.

한눈에 비교

구분	의미	토큰과의 관계
문자	사람이 보는 글자 단위	너무 잘게 쪼개져 모델 입력으로 비효율적일 수 있음
단어	사람이 읽는 의미 단위	언어마다 경계가 달라 모델 단위로 쓰기 어려움
토큰	모델이 쓰는 처리 단위	비용, context limit, latency 계산의 기준
토큰 ID	vocab 안의 숫자 인덱스	embedding lookup으로 들어가는 실제 입력

어디서 왜 중요한가

토큰 수는 LLM 비용을 직접 바꿉니다. 같은 질문이라도 system prompt, conversation history, RAG 문서, tool 결과가 길어지면 입력 토큰이 늘어납니다. 답변이 길수록 출력 토큰도 늘어납니다.

또한 context window는 토큰 단위로 제한됩니다. 모델이 128k context를 지원한다는 말은 "토큰 기준으로 입력과 출력에 쓸 수 있는 총 예산이 그 정도"라는 뜻입니다. 긴 문서를 넣을 때는 단어 수가 아니라 토큰 수를 기준으로 잘라야 합니다.

자주 하는 오해

토큰은 항상 단어 하나가 아닙니다. 언어, tokenizer, 모델 계열에 따라 같은 텍스트의 토큰 수가 달라질 수 있습니다.

"토큰 수를 줄이면 무조건 품질이 오른다"도 아닙니다. 불필요한 반복을 줄이는 것은 좋지만, 필요한 맥락까지 빼면 모델이 판단 근거를 잃습니다.

"토큰은 사용자가 입력한 글만 센다"도 틀립니다. system prompt, developer instruction, tool schema, retrieved context, model output까지 모두 토큰 예산에 들어갈 수 있습니다.

대화에서는 이렇게

"이 프롬프트는 토큰을 너무 많이 먹어서 RAG chunk를 줄여야겠어요."

"출력 토큰 상한을 낮추면 비용은 줄지만 답변이 중간에 잘릴 수 있습니다."

"한국어 문서라서 글자 수 기준이 아니라 실제 tokenizer로 토큰 수를 재야 합니다."

함께 읽으면 좋은 용어

• 선행
  Tokenizer: 텍스트를 토큰 ID로 바꾸는 구성 요소.
• 선행
  Embedding: 토큰 ID가 모델 내부의 벡터 표현으로 바뀌는 단계.
• 확장
  Context Window: 입력과 출력에 사용할 수 있는 토큰 예산.
• 확장
  Prompt Caching: 반복되는 입력 토큰을 캐시해 비용과 latency를 줄이는 기능.