필사 모드: AI Engineering 프로덕션 실전 완전 가이드 — RAG·Evals·Fine-tuning·LLMOps·Guardrails·Prompt Caching·비용 최적화까지 2025-2026년 현장 노하우
한국어> “Demo is easy. Production is hard. Evals are the only way you know which one you have.” — Hamel Husain
[2026년 기술 지형 예측]에서 우리는 LLM Next Wave와 Agents 주류화가 2026년의 핵심이라고 정리했다. 이제는 **그걸 실제로 어떻게 만드는가**로 내려간다.
2023년은 ChatGPT API wrapper의 해였다. 2024년은 RAG의 해였다. 2025년은 **Agents + Evals**의 해였다. 많은 팀이 Jupyter 데모는 만들었지만, **프로덕션 LLM 시스템**을 제대로 굴리는 팀은 여전히 소수다. 이 글은 그 간극을 메운다.
대상: 일반 백엔드·풀스택 엔지니어가 LLM 기능을 프로덕션에 넣어야 할 때. ML 박사 지식 없이도 실용적으로 작동하는 AI Engineering 전반을 다룬다.
목차
1. AI Engineer vs ML Engineer — 역할 구분
2. 아키텍처 전체 그림 — prompt → tool → RAG → agent → eval
3. RAG 파이프라인 — chunking, embedding, retrieval, reranking
4. Evals — LLM-as-Judge·pairwise·rubric·regression
5. Fine-tuning vs Prompt vs RAG 결정 트리
6. Agent 구축 — LangGraph·DSPy·MCP
7. LLMOps — tracing, logging, versioning
8. Guardrails — 입출력 안전성·prompt injection 방어
9. Prompt Caching과 비용 최적화
10. Latency 최적화 — streaming·speculative decoding·routing
11. 한국어·도메인 특화 이슈
12. 체크리스트와 안티패턴
1. AI Engineer vs ML Engineer — 역할 구분
1.1 역할 분화
**ML Engineer (전통)**:
- 데이터셋 구축, feature engineering, 모델 학습.
- PyTorch/TensorFlow, distributed training, GPU.
- 논문 → 재구현 능력.
**AI Engineer (2023+ 신조어, Chip Huyen 정립)**:
- **Foundation model을 조립**하는 엔지니어.
- Prompt·RAG·Tool·Agent·Eval 조합.
- 대부분 SWE 스킬 + 약간의 ML 이해.
1.2 실무 비율
Chip Huyen "AI Engineering" (2024) 기준 — **AI Engineer가 전체 LLM 팀의 80%**, ML Engineer는 20%. Foundation model은 OpenAI/Anthropic/Meta 등 소수가 만들고, 나머지는 조립한다.
1.3 이 글의 타겟
- 백엔드/풀스택 3년+ 경험.
- ML 수학에 깊이 들어갈 시간은 없음.
- 그러나 프로덕션 LLM 기능을 설계·배포·유지해야 함.
2. 아키텍처 전체 그림
2.1 5 레이어 모델
┌──────────────────────────────────────────┐
│ 5. Evals & Observability │
├──────────────────────────────────────────┤
│ 4. Agent / Orchestration │
├──────────────────────────────────────────┤
│ 3. Tool use / Function calling │
├──────────────────────────────────────────┤
│ 2. RAG / Context engineering │
├──────────────────────────────────────────┤
│ 1. Prompt + Model │
└──────────────────────────────────────────┘
2023년 1~2 레이어만 있었다. 2024년 3~4 레이어 추가. 2025년 5 레이어가 표준이 됨.
2.2 데이터 흐름
User query
↓
Prompt template + guardrail (input)
↓
Context retrieval (RAG)
↓
LLM (tool calls ↔ tool exec)
↓
Post-process + guardrail (output)
↓
Logging + eval trace
↓
Response to user
각 단계가 관측 가능해야 한다. LangSmith·Langfuse·Arize Phoenix가 이 역할.
3. RAG 파이프라인 — chunking, embedding, retrieval, reranking
3.1 RAG가 필요한 이유
- **Fresh data** — 모델 학습 cutoff 이후 정보.
- **Private data** — 회사 문서·DB.
- **Citation** — 출처 제공 가능.
- **Cost** — context에 전체 corpus 넣는 것보다 싸다.
3.2 Naive RAG의 문제
초창기 RAG 코드 — “chunk 1024 + top-k 5 → LLM”. 실패 원인:
- **Chunking** — 의미 단위를 쪼개면 맥락 상실.
- **Embedding mismatch** — question embedding ≠ document embedding 공간.
- **Top-k 낮음** — 정답 청크가 top-k 밖.
- **No reranking** — 유사도만으론 부정확.
3.3 2025 현대 RAG 스택
1. **Document preprocessing**
- PDF → **Unstructured, LlamaParse, Reducto** (표·그림·수식).
- HTML → Readability·trafilatura.
- PowerPoint·Excel 전용 파서.
2. **Chunking 전략**
- **Semantic chunking** — embedding similarity로 문단 경계.
- **Structural chunking** — Markdown heading, HTML DOM.
- **Parent-child** — 작게 검색, 크게 제공.
- **Sliding window + overlap** — 문맥 유지.
3. **Embedding**
- **OpenAI text-embedding-3-large** — 범용 강자.
- **Cohere embed-v3** — multilingual.
- **Voyage AI, Jina AI** — 도메인 특화.
- **Nomic embed, BGE-M3** — 오픈소스.
- **Matryoshka embeddings** — 차원 유연성.
4. **Vector DB**
- **pgvector (PostgreSQL)** — 기본 선택. Supabase가 잘 만들어놨다.
- **Qdrant, Weaviate, Milvus, Pinecone** — 전용.
- **LanceDB, ChromaDB** — 임베디드·로컬.
- **Vespa** — 검색+벡터 통합.
5. **Retrieval**
- **Hybrid search** — BM25 + vector (70:30 또는 50:50).
- **Query expansion** — HyDE (hypothetical document), multi-query.
- **Self-query** — LLM이 filter 조건 생성.
6. **Reranking**
- **Cohere Rerank v3** — 프로덕션 표준.
- **BGE-reranker** — 오픈소스.
- **ColBERT v2** — 정밀 but 비용.
- Top-50 → rerank → top-5.
7. **Context compression**
- LongLLMLingua·LLMLingua-2로 불필요 토큰 제거.
3.4 평가 지표
- **Retrieval** — Hit@k, MRR, NDCG.
- **Generation** — Faithfulness, Answer Relevance, Context Precision/Recall.
- **End-to-end** — RAGAS, TruLens.
3.5 Graph RAG와 최신 흐름
- **GraphRAG (Microsoft, 2024)** — 문서에서 knowledge graph 추출 → 커뮤니티 요약.
- **Late interaction** — ColBERT 스타일, 토큰 레벨 매칭.
- **Agentic RAG** — 에이전트가 retrieval을 여러 번 반복.
- **Long-context as RAG** — Gemini 1.5의 2M context로 RAG 불필요 주장(문서 수량 제한).
4. Evals — LLM-as-Judge·pairwise·rubric·regression
4.1 Evals가 왜 결정적인가
"If you can't measure it, you can't improve it." LLM 시스템의 품질은 **주관적**이기에 측정 체계 없이는 프로덕션이 불가능.
Hamel Husain(『LLM Evals』 저자) — *"Evals는 AI 엔지니어링의 테스트 슈트다. 없으면 리팩터링도 모델 교체도 못 한다."*
4.2 Eval 종류
1. **Reference-based**
- **BLEU, ROUGE, BERTScore** — 번역·요약의 고전.
- Golden answer 필요. 작성·유지 비용.
2. **Reference-free (LLM-as-Judge)**
- GPT-4 급 모델이 출력 평가.
- **Pairwise** — A vs B 중 선택.
- **Rubric** — 5점 척도 + 이유.
- **Critique** — 자유 서술.
3. **Rule-based**
- 정규식, JSON 스키마 검증, 금칙어.
4. **User feedback**
- 👍/👎, 5-star, follow-up 발생률.
4.3 Eval Dataset 구축
- **Seed set** — 실제 로그에서 50~200 케이스 선별.
- **Synthetic augmentation** — LLM으로 variation 생성.
- **Labeling** — 실제 전문가가 ground truth 작성.
- **Versioning** — DVC·git-lfs로 버전 관리.
4.4 Eval Harness
pytest-style
├─ test_rag_hit.py # retrieval 정확도
├─ test_factuality.py # LLM-as-judge
├─ test_refusal.py # 거부 시나리오
├─ test_jailbreak.py # 적대적
└─ test_latency.py # p50/p95
CI에서 매 PR마다 실행. 회귀 방지.
4.5 툴
- **OpenAI Evals, Anthropic Evaluation Suite** — 각 벤더 자체 툴.
- **Promptfoo** — YAML로 A/B 비교.
- **DeepEval, Ragas, TruLens** — Python.
- **Braintrust, Langfuse, LangSmith, Arize** — SaaS 관측+eval.
- **Patronus AI, Lakera** — 안전성 특화.
4.6 Judge 편향
- **Position bias** — 첫 번째를 선호.
- **Length bias** — 긴 답변 선호.
- **Style bias** — 자기 스타일 선호.
대응: swap 실험, 길이 정규화, 다수결(3 judges).
5. Fine-tuning vs Prompt vs RAG 결정 트리
5.1 먼저 시도할 순서
1) Prompt engineering (1 day)
2) RAG (1~2 weeks)
3) Prompt + RAG + examples (few-shot)
4) Fine-tuning (1~2 months, only if above fail)
5.2 언제 Fine-tuning이 맞는가
- **스타일/포맷** — 특정 JSON 스키마, 말투.
- **지식 주입은 비추천** — RAG가 낫다.
- **저비용 추론** — 작은 모델로 big model 대체.
- **예시 1,000개 이상** 확보 가능할 때.
5.3 LoRA·QLoRA
- **Full fine-tuning** — 큰 비용, catastrophic forgetting.
- **LoRA** — 작은 adapter만 학습. 80% 케이스.
- **QLoRA** — 4-bit quantization + LoRA. 단일 A100에서 70B 학습.
- **DPO, ORPO, KTO** — preference learning.
- **Unsloth** — 2-5x 빠른 fine-tuning 라이브러리.
5.4 인스트럭션 튜닝 데이터
- **Alpaca 포맷** — instruction + input + output.
- **ShareGPT 포맷** — multi-turn 대화.
- **품질 > 양** — 1,000개 고품질 > 100,000개 저품질.
- **Self-instruct, Evol-Instruct** — synthetic augmentation.
5.5 Deploy
- **vLLM, SGLang, TensorRT-LLM** — 고성능 추론 서버.
- **Text Generation Inference (HF)** — 편의성.
- **Ollama, LMStudio** — 로컬 개발.
- **Modal, Baseten, RunPod, Replicate** — 서버리스 GPU.
6. Agent 구축 — LangGraph·DSPy·MCP
6.1 Agent의 정의
단순 프롬프트 ≠ Agent. Agent는:
1. **Loop** — 반복적 판단.
2. **Tool use** — 외부 행동.
3. **Memory** — 상태 유지.
4. **Goal-oriented** — 목표 달성까지.
6.2 LangGraph
LangChain의 그래프 기반 대체. **상태 기계**로 agent 모델링.
from langgraph.graph import StateGraph
graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_fn)
graph.add_node("reason", reason_fn)
graph.add_node("respond", respond_fn)
graph.add_edge("retrieve", "reason")
graph.add_conditional_edges("reason", should_continue, {
"continue": "retrieve",
"end": "respond",
})
장점: 명시적 상태, checkpointing, human-in-the-loop.
6.3 DSPy
Stanford 연구. **Prompt를 수동 작성 대신 컴파일**.
- Signature로 input/output 정의.
- Module로 reasoning 패턴 조합.
- **MIPRO, BootstrapFewShot** — 자동 프롬프트 최적화.
프로덕션 채택은 아직 실험적이나, eval-driven prompt engineering의 미래.
6.4 CrewAI·AutoGen
- **CrewAI** — "role-based" 다중 에이전트. 마케터·분석가·작가 역할.
- **AutoGen (Microsoft)** — conversation-based multi-agent.
- 실험은 멋있으나 프로덕션 성숙도 낮음.
6.5 MCP 통합
from mcp import Client
client = Client("internal-docs-mcp-server")
tools = client.list_tools()
LLM에게 tools 제공
**MCP 서버 자체를 만드는 것**이 2026년 핵심 스킬. Anthropic·OpenAI·Google 모두 지원.
6.6 Agent 실패 패턴과 대응
- **Infinite loop** — max iterations 강제 (10~30).
- **Tool hallucination** — 스키마 엄격 검증, JSON mode.
- **Cost blow-up** — per-run budget alert.
- **Stale memory** — TTL, 명시적 reset.
7. LLMOps — tracing, logging, versioning
7.1 왜 기존 APM으론 부족한가
전통 로그는 HTTP status·latency. LLM은 **입력 프롬프트·출력 텍스트·토큰 수·cost·tool calls·retrieval 결과** 전부 필요.
7.2 Tracing 필수 요소
- **Trace ID** — end-to-end 상관.
- **Span 계층** — prompt → retrieval → LLM call → tool → LLM call…
- **Inputs/outputs** — 원문 저장 (PII 주의).
- **Tokens in/out, cost, latency**.
- **Model version, prompt version**.
- **User feedback** — 👍/👎 연결.
7.3 툴 선택
- **LangSmith** — LangChain/LangGraph 네이티브, SaaS.
- **Langfuse** — 오픈소스 self-host 가능.
- **Arize Phoenix** — ML 관측성 기반.
- **Braintrust** — eval 중심.
- **OpenLLMetry** — OpenTelemetry 기반, 벤더 중립.
- **Helicone, Portkey** — 프록시 레이어.
7.4 Prompt Versioning
- Prompt를 코드처럼 관리.
- **Prompt Hub (LangSmith)**, **PromptLayer**, **git + YAML**.
- A/B 테스트: prompt v1 vs v2 production traffic 분할.
7.5 Shadow deployment
- 새 모델·프롬프트를 prod traffic 복사본에 흘려보낸다.
- 실 사용자에겐 영향 없음.
- Eval 점수 비교 후 승격.
7.6 Continuous evaluation
- 매일 샘플링된 prod traces → LLM-as-Judge → 대시보드.
- 품질 drift 감지.
- 회귀 시 alert.
8. Guardrails — 입출력 안전성·prompt injection 방어
8.1 위협 모델
- **Prompt injection** — 사용자 입력이 system prompt 덮어쓰기 시도.
- **Data exfiltration** — LLM이 DB·파일 읽어서 유출.
- **Jailbreak** — 안전 훈련 우회.
- **PII leakage** — 학습 데이터 또는 context 유출.
- **Hallucination** — 그럴듯한 거짓말.
8.2 입력 Guardrails
- **PII scrubbing** — Presidio, LLM-guard.
- **Prompt injection detection** — ProtectAI Rebuff, Lakera Guard.
- **Content filter** — OpenAI Moderation API, Perspective API.
- **Policy violation** — 자체 classifier.
8.3 출력 Guardrails
- **JSON schema validation** — Pydantic, Zod.
- **Factuality check** — secondary LLM verification.
- **Toxicity filter** — detoxify, Perspective.
- **PII leak** — 출력에서도 scrub.
8.4 툴
- **NVIDIA NeMo Guardrails** — Colang DSL.
- **Guardrails AI** — Python rails.
- **LLM Guard** — 오픈소스 통합.
- **Protecto, Lasso Security** — 엔터프라이즈.
8.5 Defense in Depth
- **시스템 프롬프트 격리** — 사용자 입력과 명확한 구분.
- **Least privilege tool** — tool별 권한 최소화.
- **Output sandbox** — 에이전트가 생성한 코드는 격리 실행 (Modal, E2B).
- **Human-in-the-loop** — 고위험 작업(결제·이메일 전송)은 승인.
9. Prompt Caching과 비용 최적화
9.1 LLM 비용 구조
- **Input tokens** — 대부분 비중. RAG context·시스템 프롬프트.
- **Output tokens** — 단가 3~5배. 짧게 만들기.
- **Tool calls, embeddings, reranking** — 별도.
9.2 Prompt Caching
- **Anthropic Prompt Caching** (2024.8) — 불변 prefix 캐시. 90% 할인.
- **OpenAI prompt caching** (2024.10) — 자동, 50% 할인.
- **Google Gemini Context Caching** — 명시적 TTL.
**활용 패턴**:
- System prompt, instruction, few-shot 예제를 prefix에.
- 사용자별 변화 부분을 suffix에.
- 세션 길어도 prefix 재사용.
9.3 Model routing
- **Simple query → gpt-4o-mini** or Haiku.
- **Complex → gpt-4o** or Sonnet.
- **Router model** — Martian, LiteLLM, OpenRouter가 자동 선택.
9.4 Batch API
- **OpenAI Batch API** — 50% 할인, 24h 완료.
- **Anthropic Message Batches** — 50% 할인.
- 비실시간 작업(eval, bulk 처리).
9.5 Quantization과 Self-host
- 7B~70B 오픈 모델 + vLLM + 자체 GPU.
- **INT8, INT4 quantization** — AWQ, GPTQ.
- GPU 시간당 비용 vs API 토큰 비용 비교. 트래픽 높으면 자체 호스팅이 저렴.
9.6 Cost observability
- **Tokens per request, cost per request, cost per user**.
- **Helicone, Portkey, LangSmith** cost 집계.
- Budget alert: 하루 $X 초과 시 throttle.
10. Latency 최적화 — streaming·speculative decoding·routing
10.1 TTFT와 TPS
- **TTFT (Time To First Token)** — 사용자 체감 speed.
- **TPS (Tokens Per Second)** — 생성 속도.
- 챗봇은 TTFT 800ms 이하 목표.
10.2 Streaming
- **Server-Sent Events (SSE)** — 브라우저 지원, 간단.
- **WebSocket** — 양방향 필요시.
- 첫 토큰 도착 즉시 UI 업데이트.
10.3 Speculative decoding
- 작은 draft model이 여러 토큰 예측 → 큰 model이 검증.
- vLLM, TensorRT-LLM 지원. 2~3x 속도.
10.4 KV cache 최적화
- **PagedAttention (vLLM)** — 메모리 효율.
- **Prefix caching** — 공통 prefix 재사용.
- **Continuous batching** — 요청별 다른 길이 혼합.
10.5 Routing
- Latency 중요 경로는 Groq/Cerebras (1000+ TPS).
- 품질 중요 경로는 Claude Opus·GPT-4o.
10.6 Geographic edge
- **Cloudflare Workers AI** — 300+ PoP에서 추론.
- **Fireworks, Together** — 미국 중심.
- 한국 사용자는 일본 리전 권장.
11. 한국어·도메인 특화 이슈
11.1 토큰 효율성
- GPT-4o 한국어 토큰 수 영어의 **1.5~2x**. 비용·latency 불리.
- **ko-BERT tokenizer** 기반 모델 — HyperCLOVA X, EXAONE 유리.
- 프롬프트 일부는 영어로 작성하면 토큰 절약.
11.2 한국어 임베딩
- **ko-sroberta-multitask, KoE5** — 한국어 특화.
- **BGE-M3** — multilingual 중 한국어 성능 괜찮음.
- OpenAI embedding은 한국어도 준수하나 토큰 비용 부담.
11.3 도메인 예시
- **법률** — 판례 RAG, 계약서 생성. Lex Machina·Casetext 벤치마크.
- **의료** — 진료 기록 요약. 한국은 개인정보보호법·의료법 엄격.
- **금융** — 공시·리포트 분석. 신뢰성 vs 창의성 균형.
- **커머스** — 상품 설명, 리뷰 요약, CS 봇.
11.4 규제
- **개인정보보호법** — LLM에 PII 입력 시 위험.
- **금융권 망분리** — 외부 LLM API 호출 제한.
- **AI 기본법 (2026)** — 고위험 AI 영향평가 의무.
대응: **자체 호스팅 + VPC 내부 LLM**, 또는 금융 전용 클라우드.
12. 팀 구성과 개발 프로세스
12.1 최소 AI 팀
- **AI Engineer** 1~2명 — 시스템 설계·구현.
- **Product Manager** 1명 — 사용자 니즈·품질 기준.
- **Domain Expert** — part-time, eval labeling.
- **DevOps/Platform** — GPU·observability.
12.2 개발 사이클
1. **Use case 선정** — ROI 계산.
2. **Eval set 먼저** — 20~50 케이스.
3. **Prompt baseline** — 즉시 측정.
4. **RAG 추가** — 필요시.
5. **Fine-tune** — 마지막 수단.
6. **Guardrail + observability** — 배포 전 필수.
7. **Shadow → canary → prod**.
8. **Continuous eval**.
12.3 Prompt engineering 문화
- 프롬프트는 코드와 함께 리뷰.
- Change log 관리.
- 실험은 **before/after eval 점수**로 증명.
체크리스트
1. ☐ Eval dataset이 최소 50케이스 이상 있다.
2. ☐ CI에서 매 PR마다 eval이 돈다.
3. ☐ Tracing(LangSmith·Langfuse 등)이 모든 LLM 호출을 기록한다.
4. ☐ Prompt가 git에 버전 관리된다.
5. ☐ Input guardrail(PII·injection)이 있다.
6. ☐ Output guardrail(schema·toxicity)이 있다.
7. ☐ Cost budget과 alert이 설정되어 있다.
8. ☐ 모델 장애 fallback(다른 벤더·다른 모델)이 있다.
9. ☐ Latency p95를 측정·SLO로 관리한다.
10. ☐ User feedback 루프가 trace와 연결된다.
11. ☐ Shadow deployment로 모델·프롬프트 교체를 검증한다.
12. ☐ 보안팀·법무팀과 데이터 흐름을 리뷰했다.
자주 보는 안티패턴 10가지
1. **Eval 없이 프롬프트 무한 튜닝** — 주관 vibe check. 회귀 감지 불가.
2. **Chunk 1024·top-k 5 고정** — 문서 유형·도메인 무시한 기본값.
3. **Fine-tuning 먼저 시도** — 프롬프트·RAG 여력 남았는데.
4. **JSON mode 없이 파싱** — hallucinated 필드에 깨짐.
5. **Guardrail 없이 prod** — 첫 prompt injection 이슈에 사고.
6. **Cost 관측 없음** — 월말 청구서 쇼크.
7. **단일 벤더 종속** — OpenAI down에 전체 서비스 다운.
8. **Prompt 하드코딩** — 변경마다 재배포 필요.
9. **Human-in-the-loop 없는 고위험 자동화** — 결제·외부 이메일 발송 등.
10. **PII 무심코 벤더에 전송** — 개인정보보호법·GDPR 위반.
다음 글 예고 — “AI Engineer 커리어 완전 가이드: 주니어에서 시니어·스태프·프린시플까지”
AI Engineering을 **구축**하는 법을 배웠다면, 이제 **커리어**의 문제다.
- AI Engineer의 레벨별 역량 맵
- 주니어 → 시니어 → 스태프 → 프린시플 전환
- 면접과 포트폴리오
- 국내 vs 글로벌 원격 vs 해외 취업
- 2026년 기준 연봉 구조와 보상
- 10년 뒤 AI Engineer는 어떻게 진화할 것인가
학습 엔진 세팅 → 기술 지형 예측 → AI Engineering 실전 → 이제 **자신의 커리어**를 설계할 차례다.
현재 단락 (1/328)
[2026년 기술 지형 예측]에서 우리는 LLM Next Wave와 Agents 주류화가 2026년의 핵심이라고 정리했다. 이제는 **그걸 실제로 어떻게 만드는가**로 내려간다.