P6-2.3 길이·비용·청크를 바꾸는 토큰화(tokenization)¶

Section ID: P6-2.3 Version: v2026.07.24

P6-2.2에서는 tokenizer 출력에서 토큰 문자열, 토큰 수, 토큰 ID, token ID 순서열을 구분했습니다. 이제는 어떻게 읽는가에서 한 걸음 더 나아가, 토큰화 결과가 실제 판단을 어떻게 바꾸는지 봅니다.

이 절의 중심은 tokenizer 출력값을 다시 판독하는 데 있지 않습니다. 원문 문자열이 어떤 경계와 ID 순서로 바뀌는 순간, 입력 길이, 비용, 청크 경계, 출력 보존 판단이 함께 달라진다는 점을 붙잡는 데 있습니다.

토큰화는 어떤 절차인가¶

토큰이 계산 단위라는 점을 알았다면, 이제 문자열이 실제로 그 계산 단위로 어떻게 바뀌는지를 봐야 합니다. 토큰화(tokenization)는 원문 텍스트를 모델이 읽는 토큰 시퀀스로 바꾸는 절차입니다.

사람이 보는 글자가 그대로 계산되는 것은 아닙니다. tokenizer가 경계를 잡고, vocabulary에 있는 조각을 고르고, 그 조각을 ID로 바꾸는 흐름을 먼저 봐야 합니다.

토큰화는 왜 따로 필요한가¶

사람은 문장을 글자, 단어, 문장으로 봅니다. 하지만 모델은 이 단위를 그대로 계산에 쓰지 않습니다. 먼저 입력을 계산 가능한 조각들로 바꿔야 하고, 그 조각에 번호를 붙여 계산으로 넘겨야 합니다.

즉 토큰화는 부가 기능이 아니라, 원문 문자열 -> 토큰 시퀀스 -> 토큰 ID로 넘어가는 첫 관문입니다.

여기서 중요한 점은 토큰화가 단순한 띄어쓰기 분리가 아니라는 것입니다. tokenizer는 원문을 보고 가능한 조각 경계를 만들고, 그 조각이 vocabulary 안에 있는지 맞춰 보며, 최종적으로 모델이 받을 ID 순서를 만듭니다. 그래서 토큰화 결과를 읽을 때는 아래 세 질문을 순서대로 던지는 편이 안전합니다.

토큰화는 실제로 무엇을 하나¶

토큰화에서는 보통 다음 일이 함께 일어납니다.

• 원문 문자열을 끊을 경계를 정한다.
• 끊어 낸 조각을 토큰 vocabulary와 연결한다.
• 각 조각을 토큰 ID로 바꿔 모델 계산으로 넘긴다.

사람이 보기에는 한 단어처럼 보여도 더 잘게 나뉠 수 있고, 공백이나 구두점처럼 사람이 뜻 단위로 강하게 의식하지 않는 부분도 토큰 경계에 영향을 줄 수 있습니다.

같은 과정을 더 단계적으로 적으면 다음과 같습니다.

즉, 토큰화는 문자열을 자른다에서 끝나지 않고, 어떤 조각을 vocabulary 항목으로 볼 것인가와 그 조각을 어떤 ID로 넘길 것인가까지 포함하는 절차입니다.

같은 절차를 작은 예시로 보면 더 분명합니다. 아래 값은 실제 tokenizer 출력이 아니라, 판독 순서를 보여 주기 위한 설명용 예시입니다.

이 표에서 확인할 것은 숫자 자체가 아닙니다. 원문 -> 토큰 문자열 -> 토큰 ID로 바뀌는 동안, 사람이 느끼던 단어 경계가 tokenizer의 계산 경계로 다시 정해진다는 점입니다.

토큰화 절차를 한 줄로 그리면¶

flowchart TD
  A["원문 텍스트"]
  B["토큰으로 분할"]
  C["모델이 토큰 시퀀스를 읽음"]
  D["다음 토큰 예측"]

  A --> B
  B --> C
  C --> D

이 흐름에서 토큰화가 맡는 자리는 문자열을 토큰 시퀀스와 토큰 ID로 바꾸는 단계입니다. 그다음에야 ID가 벡터 표현으로 조회되고 계산으로 이어집니다.

토큰화 절차 사례 및 예시¶

사례 1. 단어처럼 보이는 것을 그대로 믿을 때¶

고객 지원 문서에 환불정책이라는 표현이 반복된다고 해 봅시다. 사람은 이 표현을 뜻이 붙은 한 단어로 빨리 읽습니다. 그래서 tokenizer도 이 문자열을 그대로 한 조각으로 넘길 것이라고 생각하기 쉽습니다.

이 기준의 한계는 사람이 느끼는 단어 경계를 tokenizer 경계와 같은 것으로 본다는 데 있습니다. 토큰화 단계에서는 환불정책이 하나의 vocabulary 항목으로 남을 수도 있지만, 환불, 정책 또는 더 작은 조각으로 나뉠 수도 있습니다.

이 사례에서 확인해야 할 결과는 단어처럼 보이는가가 아니라 원문이 어떤 경계로 끊기고, 그 조각이 vocabulary의 어떤 항목과 연결되어, 어떤 ID 순서가 되는가입니다. 숫자는 설명용 예시입니다.

따라서 더 안전한 판단은 원문을 보고 바로 토큰 수나 ID를 추측하지 않고, tokenizer가 만든 경계, vocabulary 조각, ID 순서를 차례로 확인하는 것입니다.

사례 2. 공백이 있으니 단위도 같을 것이라고 생각할 때¶

회의는 내일 오전 10시에 시작합니다 같은 문장을 보면 사람은 공백을 기준으로 단어가 나뉜다고 먼저 생각합니다. 그래서 공백으로 나눈 단어 수가 곧 토큰 수와 비슷하다고 느끼기 쉽습니다.

이 기준의 한계는 tokenizer가 공백만 보고 자르지 않는다는 데 있습니다. 숫자, 조사, 어미, 시간 표현은 vocabulary와 분할 규칙에 따라 다른 조각 경계를 만들 수 있습니다. 10시에는 한 덩어리로 남을 수도 있고, 10, 시, 에처럼 나뉠 수도 있습니다.

이 사례에서 확인해야 할 결과는 토큰화가 공백 분리가 아니라, 공백 밖의 숫자·조사·어미 경계까지 다시 정하는 절차라는 점입니다.

따라서 더 안전한 판단은 공백 단어 수를 토큰 수로 바꾸어 생각하지 않고, tokenizer가 실제로 만든 조각 경계와 그 경계에 대응하는 ID 순서를 보는 것입니다.

사례 3. 문장을 바로 계산한다고 느낄 때¶

사용자가 환불정책을 요약해 줘라고 입력하면, 사람은 모델이 이 문장을 통째로 읽고 바로 의미를 잡는다고 상상하기 쉽습니다. 하지만 토큰화 관점에서는 먼저 문자열이 조각으로 나뉘고, 각 조각이 vocabulary 항목과 연결된 뒤, 토큰 ID 순서로 바뀝니다.

이 기준의 한계는 문장 입력과 계산 입력 사이의 변환 단계를 지워 버린다는 데 있습니다. 토큰화가 빠지면 모델이 실제로 받는 것이 원문 문자열인지, 토큰 조각인지, 토큰 ID인지 구분할 수 없습니다.

이 사례에서 확인해야 할 결과는 토큰화가 부가 작업이 아니라, 문자열을 실제 계산 입력으로 넘기는 출발 단계라는 점입니다. 이때 출발 단계는 문장 하나를 받았다가 아니라 조각을 고르고 ID 순서로 바꿨다까지 포함합니다.

절차 설명은 어디까지 필요한가¶

토큰화를 처음 읽을 때는 아래처럼 사람이 보는 단위와 모델이 계산에 넘기는 단위를 분리해 두면 충분합니다.

여기서 멈추면 토큰화 절차를 외우는 데 그칠 수 있습니다. 이 절에서 더 중요한 질문은 바로 다음입니다. 그렇게 조각과 ID가 달라지면, 비용 예산, 청크 경계, 출력 한도 판단 중 무엇을 다시 봐야 하는가?

실제 tokenizer 출력이나 로그를 볼 때도 절차 자체보다 그 뒤의 판단 변화를 함께 읽습니다.

무엇과 무엇을 구분해야 하나¶

토큰화를 이해할 때는 아래 세 층위를 구분하는 편이 안전합니다.

이 구분이 없으면 토큰이 곧 단어인가, 모델이 문장을 그대로 읽는가 같은 혼동이 반복됩니다.

여기서 중요한 것은 tokenizer 계열 이름을 외우는 일이 아닙니다. 원문 문자열이 바로 계산되지 않고, 토큰화 단계에서 조각과 ID로 바뀐 뒤 모델 입력으로 넘어간다는 흐름을 읽는 일입니다. 이 흐름이 잡혀야 뒤에서 비용, 청크, 출력 길이가 왜 함께 흔들리는지 이해할 수 있습니다.

토큰화 결과는 무엇을 바꾸는가¶

토큰화가 무엇인지 알았다면, 이제 그 결과가 실제로 무엇을 흔드는지 봐야 합니다. 핵심은 단순합니다.

토큰화는 단순 분리가 아니라, 길이·비용·청크·출력 해석을 함께 바꾸는 과정이다.

토큰화 규칙 자체보다 먼저 볼 값은 토큰화 뒤에 드러나는 관찰값입니다. 같은 원문이라도 토큰 수가 달라지고, 문맥이 갈라지는 위치가 달라지고, 출력에 남길 수 있는 여유가 달라질 수 있습니다. 그래서 어떻게 잘리는가를 본 뒤에는 곧바로 그 결과 어떤 판단을 다시 해야 하는가를 물어야 합니다.

왜 같은 문장도 달라지나¶

같은 의미라도 표기 방식이 달라지면 토큰 경계와 토큰 수가 함께 달라질 수 있습니다.

• 줄임말 사용
• 숫자 표기 방식
• 특수문자 포함 여부
• 영어와 한국어 혼용

사람 눈에는 비슷한 문장이어도, 모델 쪽에서는 다른 길이와 다른 비용으로 읽힐 수 있는 이유가 여기서 생깁니다.

같은 뜻인데도 어디서 차이가 생기는지 아주 작게 풀어 쓰면 다음과 같습니다.

숫자는 실제 tokenizer 결과가 아니라 판단 흐름을 보여 주기 위한 설명용 값입니다. 핵심은 문장 의미 비교가 아니라, 어떤 표기 요소가 계산 조각을 늘릴 수 있는가를 먼저 보는 데 있습니다. 이 한 단계가 빠지면 비슷한 문장이니 비용도 비슷하겠지라는 직관으로 너무 빨리 넘어가기 쉽습니다.

토큰 경계가 운영 판단으로 이어지면¶

flowchart TD
  A["원문 텍스트"]
  B["토큰화"]
  C["토큰 수"]
  D["비용과 문맥 사용량"]
  E["검색 / 생성 동작"]

  A --> B
  B --> C
  C --> D
  B --> E

이 도식에서 확인해야 할 결과는 하나입니다. 토큰 경계가 달라지면 뒤의 서비스 판단도 함께 달라진다는 점입니다.

실제로 바뀌는 것 1. 비용¶

짧아 보이는 문장도 숫자, 기호, 이메일, URL이 섞이면 실제 토큰 수가 빨리 늘 수 있습니다. 그래서 짧은 문의니까 비용도 작겠지라는 직관이 자주 빗나갑니다.

실제로 바뀌는 것 2. 문맥 길이와 청크¶

문서를 나눌 때 사람은 문단 수나 눈대중 길이를 먼저 봅니다. 하지만 토큰화 기준에서는 원칙과 예외, 질문과 조건이 서로 다른 조각으로 갈라질 수 있습니다. 그러면 검색은 원칙만 가져오고 중요한 예외를 놓칠 수 있습니다.

실제로 바뀌는 것 3. 출력 길이¶

응답 형식을 길게 만들수록 출력 토큰도 늘어납니다. 표, 목록, 코드 블록, 부가 설명이 늘어나면 마지막 핵심 문장이 잘릴 위험도 함께 커집니다.

운영 판단이 바로 흔들리는 장면¶

토큰화는 전처리 세부처럼 보이지만, 실제로는 운영 판단을 직접 흔듭니다.

• 짧아 보이는 문장이 실제로는 더 비쌀 수 있습니다.
• 보기 좋은 문단 분할이 검색에는 불리할 수 있습니다.
• 친절한 출력 형식이 마지막 핵심 문장을 잘라 버릴 수 있습니다.

즉, 토큰화 차이는 문자열이 어떻게 잘리나에서 끝나지 않고 무엇을 남기고 무엇을 포기할 것인가라는 운영 선택으로 이어집니다.

운영 판단 사례 및 예시¶

아래 도식은 반복해서 보는 세 장면을 먼저 한눈에 묶어 둔 것입니다. 판독 흐름은 겉보기에는 왜 별문제 없어 보이는가 -> 토큰화 관점에서는 무엇이 달라지는가 -> 운영 판단이 어디서 바뀌는가입니다.

flowchart TD
  A["같은 토큰화 질문"]
  B["비용 추정<br/>토큰 수가 더 빨리 늘어나는가?"]
  C["RAG 청킹<br/>문맥이 함께 유지되는가?"]
  D["응답 길이 제한<br/>핵심 끝부분이 살아남는가?"]

  A --> B
  A --> C
  A --> D

도식만으로는 그래서 실제로 어떤 실패가 생기는가가 아직 추상적으로 남을 수 있으므로, 바로 아래 세 사례에서 같은 장면을 조금 더 천천히 풀어 읽습니다.

같은 장면을 아주 짧게 다시 묶으면 다음과 같습니다.

사례 1. 짧은 문의가 비용 판단을 바꿀 때¶

회의는 내일 10:00 AM입니다. Zoom 링크는 mail@example.com으로 보냈어요 같은 문장은 화면에서는 짧아 보입니다. 하지만 숫자, 콜론, 영문, 이메일 주소가 섞이면 실제 토큰 수는 기대보다 더 빨리 늘 수 있습니다.

이 사례의 문제 장면은 짧은 일정 안내라 비용도 작을 것이라고 판단하는 순간입니다. 사람이 먼저 쓰는 기준은 화면에 보이는 줄 수와 글자 수입니다. 그 기준의 한계는 숫자, 특수문자, 영어, 이메일처럼 tokenizer가 더 잘게 나눌 수 있는 요소를 놓친다는 데 있습니다. 그래서 여기서 토큰화가 바꾸는 판단은 글자 수가 짧은가에서 실제 계산 조각이 몇 개인가로 이동합니다.

작은 관찰값으로 바꾸면 판단 차이가 더 분명합니다. 숫자는 설명용 예시입니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 결과를 보지 않으면 짧아 보인다는 첫 판단이 비용 판단까지 잘못 끌고 갈 수 있습니다.

사례 2. 검색 결과가 청크 판단을 바꿀 때¶

규정 문서에서 연차는 3일 전 신청과 긴급 병가는 사후 보고 가능이 서로 다른 청크로 갈라지면, 검색은 원칙만 가져오고 중요한 예외를 놓칠 수 있습니다.

이 사례의 문제 장면은 검색 결과가 원칙 문서를 가져왔으니 검색은 성공했다고 판단하는 순간입니다. 사람이 먼저 쓰는 기준은 검색 결과에 관련 문서가 포함됐는지입니다. 그 기준의 한계는 답에 필요한 원칙과 예외가 같은 토큰 묶음 안에 남았는지를 보지 못한다는 데 있습니다. 그래서 여기서 토큰화가 바꾸는 판단은 검색 결과가 맞는가에서 함께 남아야 할 문맥이 같은 청크 안에 있는가로 이동합니다.

같은 장면을 관찰값으로 바꾸면 다음처럼 읽을 수 있습니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 뒤의 청크 경계를 보지 않으면 검색은 됐다는 판단이 예외 조건 누락을 가릴 수 있습니다.

사례 3. 친절한 형식이 출력 보존 판단을 바꿀 때¶

배송 지연 안내 한 문단이면 끝날 답에 표와 주의사항 목록을 계속 붙이면, 마지막 환불 조건 문장이 출력 한도에서 잘릴 수 있습니다. 그래서 친절한 형식과 끝까지 남겨야 할 핵심을 구분해야 합니다.

이 사례의 문제 장면은 표와 목록을 붙이면 답이 더 친절해진다고 판단하는 순간입니다. 사람이 먼저 쓰는 기준은 답변이 보기 좋고 충분히 자세한지입니다. 그 기준의 한계는 표 머리글, 구분 기호, 반복 문구도 모두 출력 토큰을 사용한다는 점을 놓친다는 데 있습니다. 그래서 여기서 토큰화가 바꾸는 판단은 더 친절한 형식인가에서 반드시 남아야 할 문장이 출력 한도 안에 남는가로 이동합니다.

출력 쪽에서도 토큰화 결과는 관찰값으로 드러납니다.

따라서 이 사례에서 닫아야 할 문장은 이것입니다. 토큰화 뒤 출력 토큰의 사용처를 보지 않으면 친절한 형식이 오히려 마지막 핵심 조건을 밀어낼 수 있습니다.

이제 토큰화 결과는 비용, 청크, 출력 보존이라는 세 판단을 바꾸는 관찰값으로 읽을 수 있습니다.

토큰화 뒤에 바뀌는 판단¶

토큰화가 실제로 무엇을 바꾸는지 붙잡으려면, 아래처럼 겉보기 변화와 운영 판단 변화를 한 번에 나란히 보는 편이 좋습니다.

이 절의 핵심 적용은 토큰화 차이를 전처리 세부로 끝내지 않고, 곧바로 비용·청크·출력 선택 문제로 연결해 읽는 일입니다.

같은 판단을 독자가 손으로 적용할 수 있게 다시 쓰면 아래처럼 됩니다.

이 중간 적용 표가 없으면 토큰화 설명은 문자열을 어떻게 자르는가에서 멈추기 쉽습니다. 하지만 이 Section의 목표는 절단 규칙 암기가 아니라, 절단 결과를 보고 입력 예산, 청크 경계, 출력 보존 판단을 바꾸는 데 있습니다.

연습 및 예제¶

아래 연습은 토큰 수를 정확히 맞히는 문제가 아닙니다. 먼저 실제 tokenizer SDK로 입력이 몇 토큰이 되는지 확인하고, 그 값을 비용·청크·출력 보존 판단으로 옮겨 봅니다. 질문마다 먼저 스스로 답한 뒤, 바로 아래 해설과 비교합니다.

예제. tiktoken으로 입력 예산과 출력 여유 확인하기¶

이 예제는 OpenAI의 tiktoken 라이브러리로 같은 인코딩에서 입력 토큰 수를 직접 세어 봅니다. 특정 모델의 최신 문맥 길이를 외우는 예제가 아니라, 입력 토큰과 예상 출력 토큰을 합쳤을 때 운영 판단이 어떻게 바뀌는지 보는 예제입니다. 여기서는 o200k_base 인코딩을 사용합니다.

여기서 실제 tokenizer가 계산하는 값은 input_tokens입니다. expected_output_tokens, token_budget, chunk_size는 서비스 설계자가 놓는 운영 가정값입니다. 이 둘을 구분해야 SDK가 모든 판단을 자동으로 내려 준다고 오해하지 않습니다. tokenizer는 입력이 몇 조각으로 바뀌었는지를 알려 주고, 사람은 그 값을 출력 여유와 청크 여유 판단에 연결합니다.

직접 조작할 값은 samples의 text, expected_output_tokens, token_budget, chunk_size입니다. 실행 결과에서 먼저 볼 값은 input_tokens, remaining_tokens, chunk_margin입니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# tiktoken으로 실제 입력 토큰 수를 세고, 비용·청크·출력 여유 판단으로 연결하는 예제입니다.
import tiktoken

encoding = tiktoken.get_encoding("o200k_base")

samples = [
    {
        "case": "plain_notice",
        "text": "회의는 내일 열립니다.",
        "expected_output_tokens": 40,
        "token_budget": 120,
        "chunk_size": 80,
    },
    {
        "case": "mixed_schedule",
        "text": "회의는 내일 10:00 AM에 열립니다. Zoom 링크는 mail@example.com으로 보냈어요.",
        "expected_output_tokens": 55,
        "token_budget": 120,
        "chunk_size": 80,
    },
    {
        "case": "policy_with_exception",
        "text": "연차는 3일 전 신청합니다. 단, 긴급 병가는 사후 보고가 가능하며 증빙을 첨부해야 합니다.",
        "expected_output_tokens": 70,
        "token_budget": 120,
        "chunk_size": 30,
    },
    {
        "case": "verbose_output_request",
        "text": "배송 지연 사유를 표로 정리하고, 주의사항 목록과 환불 제한 조건을 마지막에 덧붙여 주세요.",
        "expected_output_tokens": 95,
        "token_budget": 120,
        "chunk_size": 80,
    },
]

for sample in samples:
    input_tokens = len(encoding.encode(sample["text"]))
    total_tokens = input_tokens + sample["expected_output_tokens"]
    remaining_tokens = sample["token_budget"] - total_tokens
    chunk_margin = sample["chunk_size"] - input_tokens
    print(
        sample["case"],
        "input_tokens=", input_tokens,
        "expected_output_tokens=", sample["expected_output_tokens"],
        "total_tokens=", total_tokens,
        "remaining_tokens=", remaining_tokens,
        "chunk_margin=", chunk_margin,
    )

실행 결과 예시는 다음처럼 읽을 수 있습니다. 아래 출력은 로컬 .venv에서 tiktoken==0.13.0으로 확인했습니다.

1
2
3
4

plain_notice input_tokens= 7 expected_output_tokens= 40 total_tokens= 47 remaining_tokens= 73 chunk_margin= 73
mixed_schedule input_tokens= 24 expected_output_tokens= 55 total_tokens= 79 remaining_tokens= 41 chunk_margin= 56
policy_with_exception input_tokens= 31 expected_output_tokens= 70 total_tokens= 101 remaining_tokens= 19 chunk_margin= -1
verbose_output_request input_tokens= 30 expected_output_tokens= 95 total_tokens= 125 remaining_tokens= -5 chunk_margin= 50

이 결과에서 읽어야 할 핵심은 숫자 하나가 아니라 판단의 이동입니다. 입력 토큰은 실제 tokenizer 결과이고, 출력 토큰·예산·청크 크기는 독자가 바꿔 볼 수 있는 조건입니다.

수치 움직임을 그림으로 보면, 긴 입력보다도 예상 출력 형식이 전체 예산을 더 빠르게 잠식하는 장면이 보입니다.

이 예제의 목적은 tokenizer의 내부 규칙을 외우는 것이 아닙니다. 실제 token count를 확인한 뒤 짧아 보이는가, 문단이 자연스러운가, 출력이 친절한가라는 사람 기준을 입력 예산, 청크 여유, 출력 보존 기준으로 바꾸어 읽는 것입니다.

연습 1. 짧은 공지의 판단값 고르기¶

관찰값:

먼저 스스로 답해 봅니다.

• 이 장면에서 먼저 다시 볼 값은 무엇인가?
• 짧은 공지라는 화면 기준만으로 충분한가?
• 입력과 예상 출력을 합치면 몇 토큰으로 판단해야 하는가?
• 이 판단은 비용, 청크, 출력 중 어디에 먼저 연결되는가?

해설: 먼저 다시 볼 값은 입력 토큰 수와 그에 따른 비용입니다. 입력은 12 + 31 = 43토큰이고, 예상 출력 50토큰까지 합치면 전체 판단값은 93토큰입니다. 화면상 1문단이어도 URL, 쿠폰 코드, 날짜 표기는 토큰 조각을 빠르게 늘릴 수 있습니다. 따라서 이 장면은 청크나 출력보다 먼저 짧아 보이는 입력이 실제로 얼마나 많은 토큰으로 바뀌었는가를 확인해야 합니다.

연습 2. 검색 결과에서 예외가 빠지는 이유 찾기¶

관찰값:

먼저 스스로 답해 봅니다.

• 이 장면에서 먼저 다시 볼 값은 무엇인가?
• 원칙과 예외를 한 청크에 함께 담으려면 최소 몇 토큰이 필요한가?
• 검색기가 원칙 문장을 찾았는데도 답이 틀릴 수 있는 이유는 무엇인가?
• 이 판단은 비용, 청크, 출력 중 어디에 먼저 연결되는가?

해설: 먼저 다시 볼 값은 chunk size와 overlap입니다. 원칙 42토큰과 예외 18토큰을 함께 담으려면 최소 60토큰이 필요합니다. 현재 chunk size가 50이고 overlap도 없으므로 둘은 쉽게 갈라집니다. 검색기가 원칙 문장을 찾았더라도 예외 문장이 같은 토큰 묶음 안에 없으면 답은 중요한 조건을 놓칠 수 있습니다. 따라서 이 장면은 비용보다 함께 남아야 할 문맥이 같은 청크 안에 있는가를 먼저 확인해야 합니다.

연습 3. 마지막 결론이 잘리는 이유 찾기¶

관찰값:

먼저 스스로 답해 봅니다.

• 이 장면에서 먼저 다시 볼 값은 무엇인가?
• 현재 출력 구성이 제한 안에 들어가는가?
• 친절한 형식이 왜 실패 원인이 될 수 있는가?
• 이 판단은 비용, 청크, 출력 중 어디에 먼저 연결되는가?

해설: 먼저 다시 볼 값은 max output tokens와 출력 형식입니다. 현재 구성은 35 + 32 + 18 = 85토큰이므로 80토큰 제한을 넘습니다. 표와 목록은 보기에는 친절하지만, 구분 기호와 반복 문구가 출력 토큰을 먼저 사용합니다. 따라서 이 장면은 답을 더 예쁘게 만들 것인가가 아니라 핵심 제한 조건을 끝까지 남길 것인가를 기준으로 출력 형식을 다시 줄여야 합니다.

세 연습을 마치면 아래 한 문장으로 정리할 수 있어야 합니다.

토큰화 결과는 전처리 세부가 아니라 입력 비용, 청크 문맥, 출력 보존 판단을 다시 보게 만드는 관찰값이다.

체크리스트¶

• 같은 의미의 문장도 표기 방식이 달라지면 토큰 수가 달라질 수 있다는 점을 말할 수 있는가?
• 토큰화가 비용, 청크 설계, 출력 길이 제한을 함께 흔든다는 점을 설명할 수 있는가?
• 토큰화 변화가 문자열 분리에 그치지 않고 운영 판단까지 이어진다는 점을 이해했는가?

출처와 참고 자료¶

• OpenAI Help Center, What are tokens and how to count them?, 확인 날짜: 2026-07-19. 입력·출력 토큰 수가 사용량과 비용, 요청 길이 판단에 연결된다는 설명 확인에 사용했다.
• OpenAI Help Center, Controlling the length of OpenAI model responses, 확인 날짜: 2026-07-19. 응답 길이를 max_output_tokens 또는 max_completion_tokens 같은 출력 토큰 제한으로 제어한다는 설명 확인에 사용했다.
• OpenAI, tiktoken README, 확인 날짜: 2026-07-19. 같은 텍스트라도 tokenizer 인코딩 결과가 서비스 판단의 관찰값이 된다는 배경 근거로 사용했다.
• Rico Sennrich, Barry Haddow, Alexandra Birch, Neural Machine Translation of Rare Words with Subword Units, ACL 2016, 확인 날짜: 2026-07-19. 부분 단어 단위가 희귀어와 미등록어 처리에 쓰인다는 배경 근거로 사용했다.
• Daniel Jurafsky, James H. Martin, Speech and Language Processing, 3rd ed. draft, online manuscript released January 6, 2026, 확인 날짜: 2026-07-19. Words and Tokens 장을 토큰화와 단어 경계 설명의 일반 NLP 배경 근거로 사용했다.