> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 핵심 개념

> 이 문서는 **[GenAI 개념](/blog/guides/genai-concepts/overview)** 섹션의 일부입니다.

[\< LLM 기초 목차로 돌아가기](overview)

***

## 토큰 (Token)

LLM이 텍스트를 처리하는 최소 단위입니다. LLM은 "글자"나 "단어"가 아닌 **토큰** 단위로 텍스트를 읽고 생성합니다.

**토큰화 과정 구체 예시**:

| 입력 텍스트        | 토큰화 결과                        | 토큰 수 |
| ------------- | ----------------------------- | ---- |
| `Hello world` | `["Hello", " world"]`         | 2    |
| `안녕하세요`       | `["안", "녕", "하세요"]` (모델마다 다름) | 2\~5 |
| `Databricks`  | `["Data", "bricks"]`          | 2    |
| `인공지능`        | `["인공", "지능"]`                | 2\~4 |

> **주의**
> **한국어 토큰 비용 문제**: 한국어는 영어 대비 동일한 의미를 전달하는 데 약 2~~3배 더 많은 토큰을 사용합니다. 이는 곧 API 호출 비용이 2~~3배 높다는 의미입니다. 프롬프트 설계 시 이를 고려하세요.

## 토큰화 알고리즘 비교

"토큰"이라는 개념은 단순해 보이지만, **어떻게 텍스트를 토큰으로 나누느냐** 는 모델 성능과 비용에 큰 영향을 미칩니다. 주요 토큰화 알고리즘을 비교합니다.

| 알고리즘                        | 사용 모델            | 핵심 원리                                 | 특징                            |
| --------------------------- | ---------------- | ------------------------------------- | ----------------------------- |
| **BPE**(Byte Pair Encoding) | GPT 시리즈, Llama   | 가장 자주 등장하는 바이트 쌍을 반복적으로 병합            | 가장 널리 사용. 빈도 기반이라 직관적         |
| **WordPiece**               | BERT, DistilBERT | BPE와 유사하지만 병합 시 우도(likelihood) 최대화 기준 | Google이 개발. `##` 접두사로 서브워드 표시 |
| **SentencePiece**           | Llama, T5        | 언어 독립적 (공백도 토큰으로 처리)                  | 전처리 없이 raw text에서 직접 토큰화      |
| **Unigram**                 | T5, 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             | \~12             | 2.4배 |
| "매출이 전분기 대비 15% 증가했습니다" / "Revenue increased 15% QoQ" | \~7             | \~18             | 2.6배 |
| "Databricks Unity Catalog를 설정합니다"                     | \~6             | \~11             | 1.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 Sonnet    | 200K 토큰      | 책 약 300페이지 | 장문 분석 강점 |
| Claude 4 Opus/Sonnet | 200K (1M 확장) | 책 수 권 분량   | 최대급 컨텍스트 |
| Gemini 1.5 Pro       | 1M\~2M 토큰    | 책 10권+     | 최대 컨텍스트  |
| Llama 3.1 405B       | 128K 토큰      | 책 약 200페이지 | 오픈웨이트 최대 |
| DBRX                 | 32K 토큰       | 책 약 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.40 | 0.40  | O             |
| 2   | "부산" | 0.25 | 0.65  | O             |
| 3   | "인천" | 0.15 | 0.80  | O             |
| 4   | "대구" | 0.08 | 0.88  | O             |
| 5   | "대전" | 0.05 | 0.93  | O (0.9 초과 지점) |
| 6   | "광주" | 0.03 | 0.96  | X (컷오프)       |
| 7   | "울산" | 0.02 | 0.98  | X             |
| ... | ...  | ...  | ...   | X             |

위 예시에서 상위 5개 토큰의 누적 확률이 0.93으로 p=0.9를 초과하므로, 이 5개 토큰만 샘플링 후보가 됩니다. 확률이 매우 낮은 "광주", "울산" 등은 제외됩니다.

**Temperature vs Top-p의 차이**:

* **Temperature**: 확률 분포의 **모양(shape)** 을 변경합니다. 낮으면 뾰족하게(높은 확률 토큰에 집중), 높으면 평평하게(모든 토큰에 골고루).
* **Top-p**: 확률 분포의 **꼬리(tail)** 를 잘라냅니다. 분포 모양은 유지하되, 누적 확률 p 이후의 저확률 토큰을 제거합니다.

**실무 설정 가이드**:

| 사용 사례          | Temperature | Top-p     | 설명           |
| -------------- | ----------- | --------- | ------------ |
| 분류, 추출, SQL 생성 | 0.0         | 1.0       | 완전 결정적 출력    |
| 일반 대화, 요약      | 0.5\~0.7    | 0.9\~0.95 | 균형 잡힌 품질     |
| 브레인스토밍, 창작     | 0.8\~1.0    | 0.95\~1.0 | 다양성 극대화      |
| 코드 생성 (정확성 우선) | 0.0\~0.2    | 0.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 아키텍처](transformer) | [다음: LLM 학습 과정 >](training)