LabHub

블로그

LLM 완전 가이드 — Transformer·Attention·RLHF·RAG·Agent·Evaluation (Season 2 Ep 6, 2025)

2026-04-15 · 19 분 읽기 · #llm#transformer#attention#rlhf#dpo#rag#ai-agent#evaluation#ai-engineering#reasoning-models#season-2

들어가며 — LLM을 "잘 쓰는 사람"과 "잘 만드는 사람"의 차이

2023년엔 프롬프트 엔지니어링이 뜨거웠고, 2024년엔 RAG가 핵심이었다면, 2025년엔 LLM 내부 구조를 이해하는 것이 엔지니어의 분수령이 되었다.

왜?

이 글은 LLM을 블랙박스에서 꺼내 회로도까지 내려보는 한 편이다.

1부 — Transformer 아키텍처: 왜 이것이 모든 것을 바꿨나

1.1 이전 패러다임 (RNN/LSTM)의 한계

1.2 "Attention Is All You Need" (2017)

Vaswani et al.의 6명 저자 8페이지 논문이 AI를 재편. 핵심 아이디어:

"토큰 간의 관계를 직접 계산하자. 순차 처리 없이."

1.3 Transformer 블록 구조

Input Tokens
    ↓
Embedding + Positional Encoding
    ↓
┌─ N개 반복 ─────────────────┐
│  Multi-Head Self-Attention │
│         +                  │
│  Layer Norm + Residual     │
│         +                  │
│  Feed-Forward Network      │
│         +                  │
│  Layer Norm + Residual     │
└────────────────────────────┘
    ↓
Output (logits over vocabulary)

Decoder-only (GPT 계열): 위 블록이 여러 개 쌓인 구조.

1.4 현대 Transformer 변형 (2023~2025)

2부 — Attention 메커니즘 완전 이해

2.1 Self-Attention 수식

Attention(Q,K,V)=softmax(QKTdk)V\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V

각 토큰을 Query, Key, Value 세 벡터로 투영:

  1. Q와 K의 내적 → 토큰 간 "관련도 점수"
  2. sqrt(d_k)로 스케일링 (gradient 안정)
  3. softmax로 확률 분포화
  4. V에 가중합 → 컨텍스트 벡터

2.2 직관적 이해

문장 "The cat sat on the mat"에서 "sat"이라는 토큰을 처리할 때:

2.3 Multi-Head: 여러 관계를 동시에

하나의 Attention이 여러 종류의 관계(문법·의미·참조)를 다 잡기는 어렵다 → H개 병렬 head로 분할 후 concat.

2.4 Causal Mask (Decoder)

GPT 같은 생성 모델은 미래 토큰을 보면 안 됨 → 위쪽 삼각 행렬을 -inf로 마스킹해 softmax 후 0이 되게.

2.5 Attention의 계산 복잡도 문제

3부 — LLM 학습 파이프라인 4단계

3.1 Pre-training (사전 학습)

3.2 Supervised Fine-Tuning (SFT)

3.3 RLHF (Reinforcement Learning from Human Feedback)

  1. Reward Model 학습: 인간이 2개 응답 중 선호 선택 → "좋은 응답 점수" 학습
  2. PPO로 LLM 업데이트: Reward Model 점수 최대화

3.4 DPO (Direct Preference Optimization, 2023)

3.5 Constitutional AI / RLAIF

3.6 2024~2025 추론 모델 (o1, DeepSeek-R1, Claude 3.7 Thinking)

4부 — Tokenization: 모든 비용과 한계의 근원

4.1 BPE (Byte Pair Encoding)

GPT·Claude가 사용. 자주 나오는 문자쌍을 병합해 토큰 생성.

"Hello, world!" → ["Hello", ",", " world", "!"]  (4 tokens)
"안녕하세요" → ["안", "녕", "하", "세", "요"]  (5 tokens, UTF-8 바이트 수 더 많음)

4.2 언어별 효율 편차

언어1000자 → 토큰
영어~750
한국어~1500~2000
중국어~1500
일본어~1500
코드(Python)~600

한국어는 영어 대비 2~3배 토큰: 비용·컨텍스트 한계 그만큼 불리.

4.3 Context Window의 현실

2025년 주요 모델:

하지만: "컨텍스트 128K = 128K 모두 잘 사용"이 아니다. Needle-in-Haystack 테스트에서 중간 부분 정확도 하락.

5부 — RAG: 3세대 진화

5.1 RAG가 필요한 이유

5.2 1세대: Naive RAG

Query → [Vector Search] → Top-K chunks → [Stuff into context] → LLM

5.3 2세대: Advanced RAG

개선 포인트 6가지:

  1. Query Rewriting: 사용자 질문을 검색에 유리하게 재작성
  2. HyDE (Hypothetical Document Embedding): 가상의 답변을 생성해 그것으로 검색
  3. Hybrid Search: Dense(벡터) + Sparse(BM25) 병용
  4. Reranking: Cross-encoder로 Top-K 재정렬 (Cohere Rerank 등)
  5. Contextual Retrieval (Anthropic 2024): 청크 앞에 요약 붙여 저장
  6. Query Routing: 질문 유형별 다른 검색 경로

5.4 3세대: Agentic RAG

LLM이 능동적으로 검색 전략을 결정:

User Query
  ↓
[LLM Agent]
  ├→ "이 질문은 최신 뉴스가 필요해" → Web Search
  ├→ "이건 내부 문서에 있을 거야" → Vector DB
  ├→ "계산이 필요해" → Code Interpreter
  └→ "두 결과를 합쳐야 함" → Synthesis
  ↓
Final Answer

특징: 반복적 검색, 자기 수정, 다중 소스 통합.

5.5 RAG 아키텍처 결정 트리

Q1. 문서가 몇 개인가?
  <100 → 전체 컨텍스트에 stuff (RAG 불필요)
  100~10,000 → Naive RAG + Rerank
  10K~1M → Advanced RAG + 하이브리드 검색
  1M+ → Agentic RAG + 샤딩

Q2. 질문 복잡도?
  단일 fact lookup → Naive
  다중 홉(multi-hop) → Advanced + Query Decomposition
  계산·비교·요약 → Agentic

Q3. 지연시간 예산?
  <500ms → Cache + 단순 검색
  <3s → Standard RAG
  <30s → Agentic 가능

5.6 2024~2025 핵심 기술

6부 — Agent 설계 패턴

6.1 ReAct (Reasoning + Acting)

Thought: 사용자가 서울 날씨를 묻는다
Action: search_weather(city="Seoul")
Observation: 18°C, 맑음
Thought: 정보 확보, 답변 생성
Final Answer: "서울은 현재 18°C 맑음입니다."

가장 단순·강력한 Agent 패턴. 대부분의 Agent가 이 변형.

6.2 Plan-and-Execute

Plan:
  1. 서울 기온 조회
  2. 뉴욕 기온 조회
  3. 차이 계산
  4. 더 따뜻한 도시 반환
Execute step-by-step

복잡한 멀티스텝에 유리. 계획 수립 단계가 추가되어 안정성 ↑.

6.3 Reflection / Self-Critique

1. 답변 생성
2. 스스로 비평: "누락된 것 있는가?"
3. 수정본 생성

품질 ↑, 비용·지연 ↑.

6.4 Multi-Agent

6.5 Tool Use (Function Calling)

tools = [{
    "name": "search",
    "description": "Search the web",
    "parameters": {
        "type": "object",
        "properties": {"q": {"type": "string"}},
        "required": ["q"]
    }
}]

response = llm.complete(messages, tools=tools)
if response.tool_calls:
    for call in response.tool_calls:
        result = execute(call.name, call.args)
        # result를 다시 LLM에 전달

2025 트렌드: MCP (Model Context Protocol, Anthropic)로 도구 정의 표준화.

7부 — LLM Evaluation: 미해결 문제

7.1 왜 평가가 어려운가

7.2 전통 메트릭의 한계

메트릭한계
BLEU문자열 매칭, 의미 미반영
ROUGE요약 평가, 순서·의미 약함
Perplexity모델 비교용, 품질과 상관 약함
Exact Match다양한 정답 허용 안 됨

7.3 LLM-as-a-Judge (2023~)

"더 큰 LLM이 작은 LLM의 답을 채점"

장점: 뉘앙스·맥락 평가 가능 단점:

7.4 현대 평가 스택 (2024~2025)

  1. Unit Test: 예상 동작 단위 테스트
  2. Eval Set: 100~1000개 대표 예시 + 평가 기준
  3. LLM Judge + Rubric: 명시적 기준으로 judge 유도
  4. Human-in-the-loop: 샘플링 검수
  5. A/B 테스트: 프로덕션에서 실제 지표 (전환율, 만족도)

7.5 주요 벤치마크

벤치마크측정
MMLU다학제 지식
HumanEval / MBPP코딩
GSM8K / MATH수학
HellaSwag상식 추론
TruthfulQA진실성
MT-Bench다중 턴 대화
ARC-AGI추상 추론
SWE-bench소프트웨어 엔지니어링

2025 현실: 기존 벤치마크 상당수 포화. 새 벤치마크 지속 등장.

8부 — 프로덕션 LLM 시스템 설계

8.1 운영 시스템 구성 요소

User
  ↓
[Rate Limit + Auth]
  ↓
[Prompt Cache (KV Cache)]
  ↓
[Input Safety Filter]
  ↓
[Router] → Model A (빠름·싼 것) / Model B (추론·비싼 것)
  ↓
[Streaming Response]
  ↓
[Output Safety Filter]
  ↓
[Logging + Eval + Feedback Loop]

8.2 비용 최적화 6가지

  1. Prompt Caching (Anthropic, OpenAI): 고정 앞부분 캐시 → 90% 비용 감소
  2. Batching: 여러 요청 합침 (offline 작업)
  3. Model Routing: 쉬운 건 Haiku/mini, 어려운 건 Opus/o1
  4. Fine-tuning 작은 모델: 특정 태스크는 소형 모델이 대형보다 싸고 빠름
  5. Quantization: Self-hosting 시 INT8/INT4로 메모리·속도 ↑
  6. Semantic Cache: 유사 질문 → 같은 답 재사용

8.3 지연시간 최적화

8.4 안전성·신뢰성

9부 — 2024~2025 LLM 생태계 지도

9.1 Foundation Model Tier

Tier예시특징
FrontierGPT-5, Claude 4, Gemini 2.5최첨단, 비쌈
Reasoningo1/o3, Claude Thinking, DeepSeek-R1긴 사고, 복잡 문제
BalancedClaude Sonnet, GPT-4o가성비 최상
FastHaiku, GPT-4o-mini, Gemini Flash저렴·빠름
Open-weightLlama 3/4, Mistral, Qwen, DeepSeek자가 호스팅

9.2 오픈소스의 급부상 (2024~2025)

"오픈 모델이 Frontier를 6개월 안에 따라잡는" 패턴 반복.

9.3 추론 시간 스케일링 (Test-time Compute)

2024~2025 패러다임 전환:

10부 — AI 엔지니어의 2025년 스킬 로드맵

Month 1~2: 기초

Month 3~4: RAG

Month 5~6: Agent

Month 7~8: Evaluation

Month 9~10: 운영

Month 11~12: 심화

11부 — LLM 체크리스트 12

  1. Self-Attention 수식을 말할 수 있다 (Q, K, V + softmax)
  2. Tokenization이 비용에 미치는 영향을 언어별로 안다
  3. Pre-training → SFT → RLHF → DPO 순서와 역할을 안다
  4. DPO가 PPO보다 인기 있는 이유를 안다
  5. RAG 1/2/3세대의 차이를 설명할 수 있다
  6. Contextual Retrieval (Anthropic 2024)의 아이디어를 안다
  7. ReAct · Plan-and-Execute · Reflection 차이를 안다
  8. MCP (Model Context Protocol)의 목적을 안다
  9. LLM-as-a-Judge의 4가지 편향을 말할 수 있다
  10. Prompt Caching의 비용 절감 원리를 안다
  11. 추론 모델(o1, R1)의 학습 방식을 안다
  12. 오픈소스와 폐쇄 모델의 현재 격차를 안다

12부 — LLM 안티패턴 10

  1. 프롬프트에 모든 컨텍스트 우겨넣기: 비용 ↑, 정확도 ↓. 선택적 RAG
  2. Naive RAG 그대로 프로덕션: Rerank·Hybrid 없이는 정확도 부족
  3. Temperature 0만 쓰기: 창의 작업엔 0.7~1.0 필요
  4. Eval 셋 없이 배포: 변경 영향 측정 불가
  5. LLM-as-a-Judge 맹신: Position Bias 인식 못하면 잘못된 결론
  6. 하나의 모델로 모든 것: Router로 태스크별 분리해야 비용·지연 ↓
  7. Streaming 안 쓰기: TTFT 체감 품질 핵심
  8. Prompt Injection 방어 없음: 사용자 입력을 시스템 프롬프트에 직결
  9. LLM에게 수학·정밀 계산 맡기기: Tool (Code Interpreter) 써야
  10. Caching 미적용: Anthropic Prompt Cache는 90% 할인. 안 쓰면 손해

마치며 — LLM은 도구이자 조합 언어다

LLM은 "새로운 프로그래밍 언어"로 볼 수 있다. 프롬프트가 코드, 모델이 컴파일러, Eval이 테스트.

이 언어를 잘 쓰는 엔지니어와 못 쓰는 엔지니어의 차이는 2025년에 연봉 2~3배 차이로 벌어지고 있다.

핵심은:

  1. 내부 구조 이해: Transformer·Attention·Tokenization
  2. 학습 파이프라인 이해: RLHF vs DPO, 왜 추론 모델이 등장했나
  3. RAG·Agent 설계 패턴: 2~3세대, 5가지 Agent 패턴
  4. Evaluation 능력: eval 셋 설계, LLM-as-a-Judge 한계 이해
  5. 운영 감각: Caching, Routing, 비용·지연·안전

이 5가지가 2025년 AI 엔지니어의 베이스라인이다.

다음 글 예고 — "MLOps 완전 가이드: 모델 배포·Feature Store·Drift·A/B 테스트·GPU 운영"

Season 2 Ep 7은 ML을 프로덕션에 올리는 실전. 다음 글은:

논문에서 프로덕션까지의 거리, 다음 글에서 이어진다.

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-llm-complete-guide-transformer-attention-rlhf-rag-agent-evaluation-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다