Skip to main content
< LLM 기초 목차로 돌아가기

​
토큰 (Token)

LLM이 텍스트를 처리하는 최소 단위입니다. LLM은 “글자”나 “단어”가 아닌 토큰 단위로 텍스트를 읽고 생성합니다. 토큰화 과정 구체 예시:
입력 텍스트토큰화 결과토큰 수
Hello world["Hello", " world"]2
안녕하세요["안", "녕", "하세요"] (모델마다 다름)2~5
Databricks["Data", "bricks"]2
인공지능["인공", "지능"]2~4
주의 한국어 토큰 비용 문제: 한국어는 영어 대비 동일한 의미를 전달하는 데 약 23배 더 많은 토큰을 사용합니다. 이는 곧 API 호출 비용이 23배 높다는 의미입니다. 프롬프트 설계 시 이를 고려하세요.

​
토큰화 알고리즘 비교

“토큰”이라는 개념은 단순해 보이지만, 어떻게 텍스트를 토큰으로 나누느냐 는 모델 성능과 비용에 큰 영향을 미칩니다. 주요 토큰화 알고리즘을 비교합니다.
알고리즘사용 모델핵심 원리특징
BPE(Byte Pair Encoding)GPT 시리즈, Llama가장 자주 등장하는 바이트 쌍을 반복적으로 병합가장 널리 사용. 빈도 기반이라 직관적
WordPieceBERT, DistilBERTBPE와 유사하지만 병합 시 우도(likelihood) 최대화 기준Google이 개발. ## 접두사로 서브워드 표시
SentencePieceLlama, T5언어 독립적 (공백도 토큰으로 처리)전처리 없이 raw text에서 직접 토큰화
UnigramT5, mBART큰 어휘에서 시작하여 불필요한 토큰을 제거확률적 토큰화 (같은 문장도 다르게 분할 가능)
BPE 작동 원리 (간략):
  1. 모든 글자를 개별 토큰으로 시작 (예: l, o, w, e, r)
  2. 학습 데이터에서 가장 자주 등장하는 인접 토큰 쌍을 찾음 (예: l+o → lo)
  3. 이 쌍을 하나의 새 토큰으로 병합
  4. 원하는 어휘 크기에 도달할 때까지 2~3을 반복
결과적으로 자주 등장하는 단어(“the”, “is”)는 하나의 토큰이 되고, 드문 단어(“pneumonoultramicroscopicsilicovolcanoconiosis”)는 여러 서브워드 토큰으로 분할됩니다.

​
한국어 토크나이저의 현실

20년간 한국어 데이터를 다뤄온 경험에서 단언컨대, 한국어 토큰화는 현재 LLM 생태계에서 가장 과소평가된 비용 요인 입니다. GPT의 cl100k_base에서 한국어가 비효율적인 이유: BPE 알고리즘은 학습 데이터에서 자주 등장하는 패턴 을 토큰으로 만듭니다. GPT의 학습 데이터에서 영어가 차지하는 비중은 약 90% 이상이고, 한국어는 1~2% 미만입니다. 따라서:
  • 영어 "Hello" → 학습 데이터에서 수억 번 등장 → 1토큰 으로 병합됨
  • 한국어 "안녕하세요" → 학습 데이터에서 상대적으로 드물게 등장 → 바이트 단위로 분해 → 3~5토큰
이것은 알고리즘의 문제가 아니라 학습 데이터 분포의 편향 문제입니다. 한국어 데이터가 충분했다면 “안녕하세요”도 1~2토큰으로 병합되었을 것입니다. 구체적 비교 예시:
문장영어 토큰 수 (GPT-4)한국어 토큰 수 (GPT-4)비율
”오늘 날씨가 좋습니다” / “The weather is nice today”~5~122.4배
”매출이 전분기 대비 15% 증가했습니다” / “Revenue increased 15% QoQ”~7~182.6배
”Databricks Unity Catalog를 설정합니다”~6~111.8배

​
토큰 비용 최적화 실무 전략

동일한 의미의 한국어 프롬프트가 영어 대비 2~3배 비용이라면, 이를 줄이는 전략이 필요합니다. 전략 1: 영어 키워드 활용 System Prompt에서 반복되는 지시사항은 영어로 작성합니다. LLM은 영어 지시를 한국어보다 더 잘 이해하는 경우도 많습니다. 
# 비효율적 (한국어 System Prompt)
"당신은 데이터브릭스 전문 기술 지원 엔지니어입니다. 고객의 질문에 한국어로 답변하세요."

# 효율적 (영어 System Prompt + 한국어 출력 지시)
"You are a Databricks technical support engineer. Answer in Korean."
전략 2: 불필요한 조사와 어미 제거 한국어는 조사와 어미가 풍부한 교착어입니다. 프롬프트에서 격식체를 줄이면 토큰을 절약할 수 있습니다. 
# 토큰 많음
"아래에 제공되는 문서의 내용을 기반으로 하여 사용자의 질문에 대해 정확하게 답변해 주시기 바랍니다."

# 토큰 적음 (의미 동일)
"아래 문서 기반으로 질문에 정확히 답변하세요."
전략 3: Few-shot 예시 최소화 한국어 few-shot 예시는 토큰을 많이 소모합니다. 가능하면 few-shot 대신 명확한 지시(instruction)로 대체하세요. 꼭 필요하다면 예시를 간결하게 작성합니다.
참고 비용 절감 효과: 위 전략을 종합 적용하면 한국어 프롬프트의 토큰 사용량을 30~50% 절약할 수 있습니다. 월 수천 건 이상의 API 호출이 있는 프로덕션 환경에서는 연간 수백만 원의 차이가 납니다.

​
컨텍스트 윈도우 (Context Window)

모델이 한 번에 처리할 수 있는 최대 토큰 수입니다. 입력 + 출력 토큰을 모두 포함합니다. 왜 컨텍스트 윈도우에 제한이 있는가? Self-Attention은 모든 토큰 쌍의 관계를 계산합니다. 토큰 수가 N이면 계산량은 N^2에 비례합니다. 즉, 컨텍스트가 2배 길어지면 메모리와 계산량은 4배로 증가합니다. 이것이 물리적 제한의 핵심 원인입니다.
모델컨텍스트 윈도우대략적 분량비고
GPT-3.5 (2022)4K 토큰책 5~6페이지초기 세대
GPT-4o (2024)128K 토큰책 약 200페이지실용적 범용
Claude 3.5 Sonnet200K 토큰책 약 300페이지장문 분석 강점
Claude 4 Opus/Sonnet200K (1M 확장)책 수 권 분량최대급 컨텍스트
Gemini 1.5 Pro1M~2M 토큰책 10권+최대 컨텍스트
Llama 3.1 405B128K 토큰책 약 200페이지오픈웨이트 최대
DBRX32K 토큰책 약 50페이지효율성 중심
참고 실무 팁: 컨텍스트 윈도우가 크다고 항상 좋은 것은 아닙니다. “Lost in the Middle” 현상 — 긴 컨텍스트 중간에 있는 정보를 놓치는 문제 — 이 알려져 있습니다. 핵심 정보는 프롬프트의 처음이나 끝 에 배치하세요.

​
Temperature

모델 출력의 무작위성을 조절하는 파라미터입니다.
값특성용도
0.0결정적 (항상 같은 응답)분류, 추출, 코드 생성
0.3~0.7균형일반 대화, 요약
0.8~1.0창의적 (다양한 응답)브레인스토밍, 창작

​
Top-p (Nucleus Sampling)

누적 확률이 p에 도달할 때까지의 토큰만 후보로 사용합니다. Temperature와 함께 출력 다양성을 조절합니다. 동작 원리 (단계별):
  1. 모델이 다음 토큰의 확률 분포를 계산합니다
  2. 토큰을 확률이 높은 순서대로 정렬합니다
  3. 위에서부터 누적 확률을 더해 나갑니다
  4. 누적 확률이 p에 도달하면, 그 지점까지의 토큰만 후보로 남깁니다
  5. 남은 후보 중에서 확률에 비례하여 샘플링합니다
구체 예시(Top-p = 0.9인 경우):
순위토큰확률누적 확률후보 포함?
1”서울”0.400.40O
2”부산”0.250.65O
3”인천”0.150.80O
4”대구”0.080.88O
5”대전”0.050.93O (0.9 초과 지점)
6”광주”0.030.96X (컷오프)
7”울산”0.020.98X
…………X
위 예시에서 상위 5개 토큰의 누적 확률이 0.93으로 p=0.9를 초과하므로, 이 5개 토큰만 샘플링 후보가 됩니다. 확률이 매우 낮은 “광주”, “울산” 등은 제외됩니다. Temperature vs Top-p의 차이:
  • Temperature: 확률 분포의 모양(shape) 을 변경합니다. 낮으면 뾰족하게(높은 확률 토큰에 집중), 높으면 평평하게(모든 토큰에 골고루).
  • Top-p: 확률 분포의 꼬리(tail) 를 잘라냅니다. 분포 모양은 유지하되, 누적 확률 p 이후의 저확률 토큰을 제거합니다.
실무 설정 가이드:
사용 사례TemperatureTop-p설명
분류, 추출, SQL 생성0.01.0완전 결정적 출력
일반 대화, 요약0.5~0.70.9~0.95균형 잡힌 품질
브레인스토밍, 창작0.8~1.00.95~1.0다양성 극대화
코드 생성 (정확성 우선)0.0~0.20.95정확하되 약간의 유연성
주의 실무 권장: Temperature와 Top-p 중 하나만 조절 하는 것을 권장합니다. 둘 다 동시에 크게 변경하면 예측하기 어려운 출력이 발생할 수 있습니다. 일반적으로 Temperature를 먼저 조절하고, Top-p는 기본값(0.9~1.0)으로 두세요.

​
Prompt 구조 (System / User / Assistant)

대부분의 LLM API는 세 가지 역할의 메시지를 사용합니다.
역할목적예시
System모델의 행동 규칙 정의”당신은 한국어 전문 번역가입니다”
User사용자 입력”이 문장을 영어로 번역해주세요”
Assistant모델의 응답”Here is the translation…”
< 이전: Transformer 아키텍처 | 다음: LLM 학습 과정 >