LLM이란 무엇인가¶

이 챕터에서 배우는 것

LLM은 결국 "다음 단어 맞히기"를 반복하는 기계라는 한 줄 직관
토큰 · 컨텍스트 윈도우 · 온도 · 시스템 프롬프트 — 앞으로 모든 챕터에서 쓰일 4개 용어의 감각
파이썬 10줄로 첫 호출을 해보고, 응답이 한 글자씩 어떻게 만들어지는지 눈으로 확인한다
왜 LLM이 때때로 거짓말을 하는가(hallucination)에 대한 구조적 이해

1. 시작 — 당신은 이미 LLM의 친척을 쓰고 있다¶

스마트폰에 "안녕하세" 까지 치면 "요"가 제안됩니다. 검색창에 "오늘 날" 까지 치면 "씨"가 튀어나옵니다. 이메일 앱은 "수고하" 뒤에 "셨습니다"를 붙여줍니다.

이 기능들은 모두 같은 원리로 동작합니다.

지금까지 본 텍스트 다음에 올 가능성이 가장 높은 글자/단어를 예측한다.

LLM(Large Language Model, 거대 언어 모델)은 이걸 훨씬 큰 규모로, 훨씬 긴 문맥에 대해, 훨씬 다양한 지식으로 해낼 뿐입니다.

한 줄만 기억하세요

LLM = 지금까지의 텍스트 뒤에 올 다음 토큰(≈단어 조각)을 반복해서 고르는 기계.
이 챕터의 나머지 개념은 모두 이 문장에서 파생됩니다.

2. 토큰 — 글자도 단어도 아닌 것¶

LLM은 "글자"나 "단어"가 아니라 토큰(token) 이라는 단위로 텍스트를 읽고 씁니다. 토큰은 글자보다 크고 단어보다 작거나 같은, 의미 있는 조각입니다.

영어 예시¶

원문	토큰 분리	각 토큰의 역할
`unbelievable`	`un` · `believ` · `able`	접두사 · 어근 · 접미사
`tokenizer`	`token` · `izer`	어근 · 접미사

한국어 예시¶

원문	토큰 분리
`안녕하세요`	`안녕` · `하` · `세요`
`자연어처리`	`자연` · `어` · `처리`
`먹었습니다`	`먹` · `었` · `습니다`

모델은 이 토큰들을 내부적으로 정수 ID(예: 안녕→42, 하→7, 세요→118)로 매핑해 처리합니다. 사람에게는 글자·단어가 자연스럽지만 모델은 숫자 시퀀스만 봅니다.

왜 이게 중요한가¶

길이·비용의 기준이 토큰입니다. API 요금은 글자가 아니라 토큰 수로 매겨집니다.
영어는 대략 1 토큰 ≈ 4글자, 한국어는 1 글자 ≈ 1~2 토큰 — 한국어는 같은 의미라도 토큰이 더 많이 쓰입니다.
"GPT-4는 왜 영어로 프롬프트를 주면 더 싸고 빠를까?" — 정답이 바로 이거예요.

직접 확인해보기

OpenAI의 Tokenizer 또는 Anthropic의 토크나이저로 한국어 문장이 몇 토큰인지 확인해보세요. "안녕하세요"가 영어 "Hello"보다 토큰이 더 많을 수 있습니다.

3. 다음 토큰은 어떻게 "골라지나"¶

LLM의 내부 작동을 아주 단순화하면 3단계입니다.

다음 토큰 한 번 생성하기

2단계 LLM이 뽑은 확률 분포 예시 — 김치찌개 42% · 샌드위치 18% · 라면 12% · 그 외 28%. 온도가 0이면 항상 최상위(김치찌개), 높을수록 다양해집니다.

그리고 뽑힌 토큰을 입력에 이어붙여 이 과정을 반복합니다. 문장이 완성되거나 종료 조건을 만날 때까지.

스텝	입력 (누적 컨텍스트)	LLM이 뽑은 다음 토큰
1	`오늘 점심은`	`김치찌개`
2	`오늘 점심은 김치찌개`	`가`
3	`오늘 점심은 김치찌개가`	`좋겠다`
4	`오늘 점심은 김치찌개가 좋겠다`	`.` (종료)

우리가 보는 "한 문장 응답"은 사실 이 루프가 수십~수백 번 돈 결과입니다¹.

4. 컨텍스트 윈도우 — 모델이 한 번에 볼 수 있는 "종이"¶

모델은 무한한 텍스트를 보지 못합니다. 한 번에 볼 수 있는 토큰 수가 정해져 있고, 이걸 컨텍스트 윈도우(context window) 라고 부릅니다.

비유: 책상 위의 종이 한 장

LLM을 사람이라고 상상해보세요. 이 사람은 눈앞의 종이 한 장만 볼 수 있습니다. 종이에 쓸 수 있는 글자 수가 컨텍스트 윈도우입니다. 종이를 벗어난 내용은 기억하지 못해요.

컨텍스트 윈도우

컨텍스트 윈도우(예: 200,000 토큰) 안에 이 다섯 요소가 합쳐 들어가야 합니다. 넘치는 건 앞에서부터 잘립니다.

모델별 대략 크기 (2026 기준)¶

모델 계열	컨텍스트	대략 감
소형·빠른 모델	8K~32K	긴 대화 한두 번
중형 (대부분의 챗봇)	128K	책 한 권의 핵심
대형·고컨텍스트	1M+	책 여러 권 또는 대규모 코드베이스

왜 이게 Part 3의 RAG와 연결되는가¶

우리 회사의 모든 매뉴얼을 컨텍스트에 넣는 건 불가능합니다 — 너무 크고, 너무 비쌉니다.
그래서 질문에 관련된 부분만 검색해서 컨텍스트에 넣는 기법이 필요합니다. 그게 RAG입니다.
컨텍스트 윈도우의 한계가 RAG의 존재 이유입니다.

5. 온도(Temperature) — 창의성 다이얼¶

똑같은 질문을 해도 GPT가 어떤 날은 평범하게, 어떤 날은 엉뚱하게 답하는 경험 해보셨나요? 그 뒤에는 온도(temperature) 라는 설정값이 있습니다.

비유: 주사위의 무게

다음 토큰 후보 3개가 있다고 해봅시다: '김치찌개'(42%) · '샌드위치'(18%) · '라면'(12%).
- 온도 0 → 항상 가장 높은 확률(김치찌개)만 고름. 예측 가능·지루함.
- 온도 1 → 확률 그대로 주사위를 던짐. 대부분 김치찌개, 가끔 다른 것.
- 온도 1.5 → 주사위에서 확률 차이가 희미해짐. 라면이 나올 수도 있음.

어떤 값을 써야 하나¶

작업	권장 온도	이유
분류, 추출, 사실 확인	0.0 ~ 0.3	일관성이 최우선
요약, 번역	0.3 ~ 0.7	정확성+자연스러움
브레인스토밍, 카피라이팅	0.7 ~ 1.2	다양성이 무기

온도 0이 '답이 항상 같다'는 뜻은 아닙니다

온도 0에서도 모델 서버의 부동소수점 연산 차이·병렬화 때문에 완전히 같은 응답이 보장되지 않을 수 있습니다. "재현성이 중요"한 상황이라면 이 사실을 기억해두세요.

수학적으로 온도 \(\tau\)는 확률 분포의 "뾰족함"을 조절합니다:

\[ P(t_i \mid t_{<i}) = \mathrm{softmax}\!\left(\frac{z_i}{\tau}\right) \]

\(\tau\)가 작아지면 분포가 뾰족해져(한 토큰에 몰림), 커지면 평평해져(여러 토큰이 비슷한 확률).

6. 시스템 프롬프트 — 모델에게 주는 "업무 지침"¶

LLM을 처음 만지면 messages에 "role": "user" 만 있는 예제를 보게 됩니다. 그런데 실전에서는 거의 항상 "role": "system" 메시지가 하나 더 있습니다.

비유: 신입사원 첫날의 브리핑

사용자 메시지는 "오늘 고객 문의 처리해줘"라는 업무 지시,
시스템 프롬프트는 입사 첫날 팀장이 해주는 "우리 팀은 이런 원칙으로 일해. 이런 건 해도 되고, 이런 건 절대 안 돼" 같은 상시 지침입니다.

역할 비교¶

메시지 종류	내용	빈도
`system`	역할·어조·규칙·금칙 사항	대화 시작 시 1회 (보통)
`user`	실제 질문·요청	매 턴
`assistant`	모델의 응답	매 턴

좋은 시스템 프롬프트의 체크리스트¶

✅ 역할: "당신은 회사의 IT 지원 어시스턴트입니다."
✅ 어조: "친절하지만 간결하게. 불필요한 인사말 금지."
✅ 도구·지식의 경계: "제공된 문서 외의 정보로 답하지 마세요."
✅ 실패 시 행동: "모르면 '확인 후 답변드리겠습니다'라고 답하세요."
✅ 출력 형식: "항상 3줄 이내로 답변."

이 한 덩어리가 AI Assistant의 성격과 안전성 대부분을 결정합니다. Part 2에서 다시 깊이 다룹니다.

7. 왜 LLM은 때때로 거짓말을 하는가 (Hallucination)¶

LLM이 없는 사실을 그럴듯하게 지어내는 현상을 hallucination(환각) 이라고 부릅니다. 왜 생길까요?

hallucination이 생기는 순간

LLM은 "모른다" 를 구별하는 내장 메커니즘이 없습니다. "가장 그럴듯한 다음 토큰"을 뽑는 기계이기 때문에, 진실 여부와 상관없이 자연스러운 문장을 만들어냅니다.

대표적인 원인¶

학습 데이터에 없는 내용 — 특히 최신 정보, 특정 회사 내부 문서.
학습 데이터에 틀린 내용이 많은 주제 — 모델이 그 틀린 패턴을 학습.
모호한 질문 — 모델이 질문을 마음대로 해석.
긴 응답의 끝부분 — 앞부분에 맞추려고 뒷부분이 점점 창작됨.

대응 방법 (이 책에서 다룰)¶

기법	어디서	효과
시스템 프롬프트에 "모르면 모른다고"	이 챕터 §6	낮~중
구조화 출력 (JSON Schema)	Part 2	중
RAG (문서 기반 답변)	Part 3	높음
LLM-as-a-Judge로 검증	Part 4	중
파인튜닝	Part 7	중~높음

8. 실습 — 파이썬 10줄로 첫 호출¶

이제 실제로 LLM을 불러봅시다.

준비¶

Colab에서 실행로컬에서 실행

상단의 "Open in Colab" 배지를 클릭
상단 메뉴 → Secrets → ANTHROPIC_API_KEY 추가
첫 셀부터 차례로 실행

pip install anthropic
export ANTHROPIC_API_KEY="sk-ant-..."

코드¶

hello_llm.py
from anthropic import Anthropic  # (1)!

client = Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",  # (2)!
    max_tokens=256,
    system="당신은 친절한 한국어 설명 도우미입니다. 3줄 이내로 답하세요.",  # (3)!
    messages=[
        {"role": "user", "content": "LLM을 초등학생에게 설명해줘"}  # (4)!
    ],
)

print(response.content[0].text)  # (5)!

API 키는 환경변수 ANTHROPIC_API_KEY에서 자동으로 읽힙니다.
Claude Opus — 고성능 모델. 간단한 태스크는 Haiku로 바꿔도 됩니다 (claude-haiku-4-5).
시스템 프롬프트 — §6에서 배운 그것. 역할과 형식을 한 번에 선언.
실제 사용자 질문. 대화가 길어지면 이 리스트에 assistant와 user가 번갈아 추가됩니다.
응답은 "콘텐츠 블록"의 리스트 — 첫 블록의 텍스트를 꺼냅니다.

실행 결과 예시¶

LLM은 아주 많은 책을 읽은 똑똑한 앵무새예요. 
'이 다음엔 어떤 단어가 올까?'를 엄청 잘 맞혀서 
사람처럼 말하는 것처럼 보이는 거예요.

코드가 내부적으로 하는 일¶

#	보낸 곳	받는 곳	오가는 내용
1	내 코드	Anthropic 서버	시스템 프롬프트 + 질문 전송
2	Anthropic 서버	Claude 모델	토큰화해서 입력
3	Claude 모델	자기 자신	다음 토큰 확률 계산 → 샘플링 (응답 끝날 때까지 반복)
4	Claude 모델	Anthropic 서버	생성된 토큰 시퀀스
5	Anthropic 서버	내 코드	텍스트로 디코딩해 반환

우리가 client.messages.create(...)를 한 번 호출하면 내부에서는 이 5단계가 돌아갑니다. 3번이 수십~수백 번 반복되기 때문에 긴 답변일수록 오래 걸려요.

9. 손으로 감 잡기 — 파라미터 놀이¶

같은 질문을 온도만 바꿔서 여러 번 호출해봅니다. 결과가 얼마나 달라지는지 체감하는 게 중요합니다.

temperature_play.py
import os
from anthropic import Anthropic
client = Anthropic()

for temp in [0.0, 0.7, 1.2]:
    print(f"\n=== temperature = {temp} ===")
    for i in range(3):
        r = client.messages.create(
            model="claude-haiku-4-5",
            max_tokens=60,
            temperature=temp,
            messages=[{"role": "user", "content": "점심 메뉴 하나 추천해줘. 한 줄로."}],
        )
        print(f"{i+1}. {r.content[0].text.strip()}")

관찰 포인트:

온도 0에서 3번 호출한 결과가 거의 같은가?
온도 1.2에서는 얼마나 다양한가?
가끔 이상한 답(라면 + 피자 같이)이 나오는 건 언제?

10. 자주 깨지는 포인트¶

실수 1. max_tokens이 너무 작아 응답이 잘림

max_tokens은 출력 길이의 상한입니다. 요약 작업에 200을 주면 중간에 뚝 잘립니다. 모르면 일단 1024로.

실수 2. 온도 0이면 항상 같다고 가정

서버 병렬화·부동소수점 차이로 100% 같은 응답은 보장 안 됨. 테스트에서 == 비교하지 마세요.

실수 3. 컨텍스트에 과거 대화 안 넣고 '왜 기억 못해?' 라고 묻기

LLM은 stateless입니다. 이전 대화를 기억하려면 messages 리스트에 전체 히스토리를 매번 보내야 합니다. Part 5에서 이걸 자동화하는 방법(메모리)을 다룹니다.

실수 4. 한국어에서 토큰 수를 영어 기준으로 예상

한국어는 영어보다 토큰이 1.5~2배 더 나옵니다. 비용 견적 시 주의.

11. 운영 시 체크할 점¶

프로덕션에 넣기 전 이 챕터 범위에서 미리 생각할 것:

API 키를 환경변수 또는 시크릿 매니저에 보관 (코드에 하드코딩 금지)
비용 상한을 API 키 단위로 걸어두기
타임아웃과 재시도 — 네트워크 이슈는 일상
온도를 유즈케이스별로 명시적으로 정하기 (기본값 임의 변경 방지)
max_tokens을 유즈케이스별 표로 관리
사용자 입력이 너무 길면 사전에 자르거나 거부 (컨텍스트 넘으면 에러)

12. 확인 문제¶

손으로 직접 해봐야 다음 챕터가 편해집니다.

"안녕하세요"와 "Hello"를 Tokenizer에 넣어 토큰 수 비교 스크린샷
§8의 코드를 돌리고, 시스템 프롬프트를 "오직 이모지로만 답하라"로 바꿨을 때 응답이 어떻게 변하는지 확인
max_tokens=20으로 줄였을 때 응답이 어떻게 잘리는지 확인
§9의 코드를 돌려 온도 0 · 0.7 · 1.2의 체감 차이를 한 문단으로 정리
자신만의 hallucination 유도 질문을 하나 만들고, 시스템 프롬프트에 "모르면 모른다고 답하라"를 추가했을 때의 차이를 기록

13. 한눈 요약¶

LLM 한 번의 호출, 전체 흐름

"다음 토큰 → 다시 입력에 이어붙임 → 또 다음 토큰" 루프가 종료 조건(최대 길이 · stop token · 자연 종료) 까지 반복.

다음 챕터 → AI Assistant 시스템 개요
여기까지 이해하면 이제 "내 Assistant는 어떤 블록들로 구성돼야 하는가"를 설계할 준비가 됐습니다.

실제 서빙에서는 KV 캐시·스페큘레이티브 디코딩 등으로 이 루프를 훨씬 빠르게 돌립니다. Part 7에서 다룹니다. ↩