LLM in Production
LLM을 프로덕션 시스템에서 효율적으로 학습·서빙·평가하는 엔지니어링 패턴
개요
LLM이 프로토타입에서 프로덕션으로 넘어가면서, 추론 비용·지연·품질 보장·스케일링이 핵심 엔지니어링 과제로 부상했다. 프롬프트 엔지니어링 → SFT → RL의 점진적 성숙 경로와, RAG → Graph RAG → 에이전틱 검색의 검색 진화가 동시에 진행 중이다.
프롬프트 → SFT → RL: 점진적 성숙 경로
| 단계 | 장점 | 단점 | 적합 시점 |
|---|---|---|---|
| 프롬프트 엔지니어링 | 빠른 구축, 유연 | 외부 API 의존, 느린 추론, 프라이버시 | 프로토타이핑 |
| SFT (Supervised Fine-Tuning) | 데이터 내부 유지, 빠른 추론 | 레이블 데이터·학습 인프라 필요 | 민감 데이터 + 지연 요구 |
| RL (Reinforcement Learning) | 인간 레이블 없이 자기 개선 | 보상 설계 어려움, 불안정 | 대규모 스케일링 |
Booking.com — SFT 기반 여행 추천
- LLM Fine-Tuning — 7B 모델을 LoRA/QLoRA로 파인튜닝
- p99 추론 지연 67% 감소 (약 3배), Hit@5 8% 향상 (사용자 위치 컨텍스트)
- 레이블 설계: 예약 > 역순 클릭 > LLM-as-Judge 필터 조회
- K 제어: 학습 샘플에 정수 prepend → 정확히 K개 추천
Netflix — Post-Training 스케일링
- LLM Fine-Tuning — SFT + RL 통합 프레임워크
- On-the-fly 시퀀스 패킹(FFD 빈 패킹)으로 4.7x 토큰 처리량 향상 (92-97% 효율)
- 모델 개발자 40-60%의 시간이 데이터 준비 → 표준화된 데이터 추상화로 해결
LLM 서빙 최적화
LinkedIn — SGLang 기반 랭킹
- ML Ranking Systems — prefill-only 워크로드에 특화된 4단계 최적화
- 배치 토큰화 → 스코어링 전용 패스 → 인배치 프리픽스 캐싱 → Python 런타임 최적화
- 3x 처리량 향상 (750 → 2,200 items/s/GPU)
- GPU가 빨라지자 Python GC/GIL이 병목 →
gc.freeze()로 100-300ms 지연 제거
Spotify Wrapped — 14억 LLM 리포트
- LLM 호출은 쉬운 부분, 진짜 일은 용량 계획과 안전 시스템
- 디스틸레이션으로 비용 최적화
RAG의 진화
Vanilla RAG → Graph RAG → 에이전틱 검색
- RAG — 구조 파괴, 고정 Top-K, 교차 페이지 기억상실 문제를 단계적으로 해결
| 세대 | 접근 | 한계 |
|---|---|---|
| Vanilla RAG | 벡터 유사도 Top-K | 구조 파괴, 고정 K |
| Graph RAG | 지식 그래프 + 커뮤니티 요약 | $33K 인덱싱 비용 |
| LAD-RAG++ | 문서 그래프 + 에이전틱 루프 | 엔지니어링 복잡도 높음 |
핵심 기법
- Triple-hybrid 검색: BM25 + Dense + SPLADE + ColBERT 리랭킹
- 러닝 메모리: 인간 독자 시뮬레이션으로 교차 페이지 연결
- 결정론적 링킹: LLM은 시맨틱 판단만, 엣지 생성은 규칙 기반
- 메모리 토큰 75-80% 감소 (시간 기반 감쇠)
비용 최적화
- 선택적 그래프 구축으로 10~90% 비용 절감
- 하이브리드 벡터-그래프 아키텍처가 단일 방식 대비 최적
실전 RAG 구축 교훈
- 1TB 기술 문서 대상 로컬 RAG 구축에서 데이터 품질이 가장 중요한 요인
- 배치 처리 + 체크포인트 필수, ChromaDB(HNSW)로 벡터 저장
- GPU 투입으로 인덱싱 가속 (738K 벡터, 54GB 인덱스)
LLM 평가
자동화된 품질 보증
- LLM Evaluation — LangChain Deep Agent eval, DSPy 프롬프트 최적화
- LLM-as-Judge — Zalando 검색 품질 ($250), Dropbox 관련성 (45% 에러 감소)
평가 원칙
- 벤치마크 점수보다 프로덕션 실패 패턴 기반 eval
- 정확성 + 효율성(Ideal Trajectory) 이중 메트릭
- pytest 태그로 eval 서브셋 실행
- Booking.com처럼 LLM-as-Judge를 레이블링에도 활용
에이전트 메모리와 컨텍스트
큰 컨텍스트 윈도우보다 구조화된 메모리가 효과적이다.
- Context Engineering — 5대 패턴, Context Anchoring, 마크다운 메모리
- AI Agent — LangChain Agent Builder: 단기/장기/절차적 메모리
- 런북 기반 접근으로 반복 실행 시 토큰 90% 이상 절감
트레이드오프 테이블
| 선택 | 이점 | 비용 |
|---|---|---|
| 외부 API 프롬프트 | 빠른 시작 | 지연, 비용, 프라이버시 위험 |
| 내부 SFT | 빠른 추론, 데이터 보호 | 학습 인프라, 레이블 데이터 |
| Vanilla RAG | 간단한 구현 | 장문 문서에서 실패 |
| Graph RAG | 구조 보존, 교차 참조 | 인덱싱 비용, 엔지니어링 복잡도 |
| LLM-as-Judge | 대규모 자동 평가 | 평가자 자체의 편향 |
관련 위키
- Cost and Efficiency — 추론·토큰 비용 구조
- Evaluation and Measurement — judge 정렬·드리프트·다중 검정을 아우르는 상위 토픽
- Semantic and Ontology Stack — context layer가 정확도에 미치는 영향
- LLM Fine-Tuning
- RAG
- LLM Evaluation
- LLM-as-Judge
- AI Agent
- Context Engineering
- ML Ranking Systems
- Knowledge Representation — RAG + 지식 그래프 연결
- Feature Store — 실시간 ML 피처 서빙
- LLM Platform Engineering — Whatnot: velocity/reliability/trust, Teads: MCP 에이전트 통합
- AI-Ready Data — AI 시스템에 최적화된 데이터 속성과 성숙도 경로
도구 호출 에이전트의 파인튜닝 (Shopify)
Shopify가 프론티어 모델을 자체 파인튜닝 모델로 대체한 실전 사례:
- Python DSL 전환으로 구문·의미 정확도 대폭 향상
- 프로덕션-학습 환경 미러링의 미세한 차이가 정확도에 영향
- 벤치마크 동등 → 실제 배포 시 35% 격차 → LLM Judge + 태그 기반 2주 해소
- 주간 플라이휠: 수집 → 판정 → 보강 → 재학습 → 배포
- LLM Fine-Tuning — Shopify Flow 에이전트
Entity-Level Sentiment 최적화 (Meltwater)
단일 패스 인코딩으로 O(n) → O(1) per document 전환:
- 추론 비용 45.5% 절감, 정확도 3.02% 향상
- 비용 절감으로 더 큰 모델 배포 가능 → 정확도 향상의 부수 효과
멀티에이전트 프로덕션 시스템
Informatica CLAIRE
50-60 모델 콜을 조율하는 엔터프라이즈 데이터 관리 멀티에이전트 시스템. 오케스트레이션 에이전트가 의도 감지·계획·라우팅을 담당하고, 전문 에이전트가 각 도메인을 처리. 시맨틱 레이어로 에이전트별 정확한 컨텍스트 전달. 3개월 → 수일 워크플로우 단축.
- AI Agent — 검증 체크포인트, 에이전트별 전문 eval 메트릭
Meta AI Second Brain
60,000명 규모의 Claude Code 기반 지식 작업자 생산성 플랫폼. PARA 워크스페이스로 에이전트 컨텍스트를 구조화하고, Progressive Disclosure로 토큰 낭비를 방지. MCP 인프라 레이어가 내부 도구 접근을 제공.
- AI Agent — Skills as Markdown, 바이럴 채택, 컴포저빌리티
dew_277~286 — 평가자의 라이프사이클과 하드웨어 현실
judge를 정적 아티팩트가 아니라 라이프사이클로
Netflix의 추천 설명 사례가 LLM-as-Judge에 빠져 있던 층을 채운다 — Birth(벤치마크) → Training(정렬) → Deployment(gate+critic) → Monitoring(드리프트), 각 단계에 사람 오너.
핵심 실패 모드: judge가 라벨은 맞히면서 틀린 이유로 맞힌다. 대시보드에서는 완벽히 정렬된 것으로 보이지만, judge를 critic으로도 쓰는 순간 self-refinement에 오도하는 가이던스를 준다.
RART가 답이다 — focus set에 라벨 불일치 ∪ “맞는 라벨, 틀린 이유”(Meta-Judge가 rationale 비교)를 넣고 rubric 텍스트만 수정한다(모델 재학습 없음). ablation에서 라벨 전용 루프는 rubric을 degenerate하게 만들어 시작보다 나빠졌고 RART는 안정적으로 유지했다.
라벨 전용 optimizer는 불건전한 추론을 통해 옳은 라벨에 도달할 수 있고, 불건전한 추론은 새 데이터에 일반화되지 않는다.
⭐ 드리프트 임계를 그 주 rater들의 불일치 폭으로 — 고정 임계 대신 평균 rater보다 2σ 아래보다 나쁘지 않을 것. 어려운 주는 밴드도 넓어지므로 judge가 사람들도 느낀 난이도로 벌받지 않는다.
⚠️ 드리프트 탐지는 judge를 현재 rubric에 정렬시킨다. 지속적 인간 리뷰만이 rubric 자체가 좁거나 불완전할 때를 알려준다. (모호한 형용사가 rubric을 기술적으로 만족시키는 경우, 참조 자체가 부적절한 경우 등)
gate와 critic — 하나의 judge, 두 역할
정렬이 비싼 부분이니 judge 하나를 제대로 만들어 한 번 이상 써라. 다만 재시도는 제한한다 — 12회 수정 실험에서 가파른 부분은 초기였고, 결정적으로:
수정은 약한 generator를 구조하는 게 아니라 유능한 generator를 증폭한다.
그리고 드롭 > 서빙 — “나쁜 출력은 신뢰 위험이고, 없는 출력은 기회를 포기할 뿐이다.”
⚠️ 오프라인 judge 일치는 필요했지만 사용자 가치를 보이기에 충분하지 않았다 — 별도 온라인 A/B가 필요했다.
프롬프트 최적화도 에이전트에게
Instacart의 Catalog Attribute Extraction — 수동으로 라운드당 2시간 × 최대 20라운드 ≈ 1주였던 프롬프트·모델 최적화를 에이전트 루프로. recall +8.1%p, precision은 하한 위 유지.
인상적인 것은 적응 과정이다: 프롬프트 수정 실패 → 더 직접적 레버(reasoning effort, 모델) → 강한 모델이 precision 하한 위반 → 기각 → 프롬프트 변형 6개 전부 실패했지만 “이 모델에서 프롬프트 편집은 recall↔precision 트레이드일 뿐” 을 학습 → 17라운드에서 그 교훈을 앞선 발견과 연결해 왜 강한 모델이 실패했는지 분석하고 지침을 수정.
추론 비용은 decode의 메모리 대역폭이 결정한다
AI Accelerator Architecture가 서빙 최적화의 물리적 근거를 준다:
| 페이즈 | 연산 | 병목 |
|---|---|---|
| Training / Prefill | GEMM | compute-bound |
| Decode | GEMV | memory-bandwidth-bound |
토큰 하나를 만들려면 모델의 모든 가중치를 훑고 KV Cache를 완전히 읽어야 하는데 산술 연산은 토큰 하나 분량뿐이다. continuous batching·speculative decoding·multi-token prediction이 GEMV를 GEMM으로 승격시키지만 ⚠️ 긴 컨텍스트에서는 weight-bandwidth-bound가 KV-bandwidth-bound로 옮겨갈 뿐이다.
Tokenization Economics와 함께 보면 서빙 비용 최적화의 레버가 프롬프트보다 배칭 전략 쪽에 있는 경우가 많다.
벡터 DB는 인프라 결정이다
Vector Database Selection — 공개 벤치마크는 작은 데이터셋·합성 워크로드·낮은 동시성을 쓴다. 프로덕션 형태 평가의 필수 요소: 전체 규모(1억), filtered a-KNN, 동시 write 하의 read, P99, 그리고 ⭐ 모든 후보를 동일 recall(~0.99)로 정규화 — 안 하면 “더 대충 찾는 시스템”이 이긴다.
가장 중요한 교훈은 특정 벤더가 아니라 평가 자체의 소유권이었다.
그리고 마이그레이션을 가능하게 한 것은 평가가 아니라 훨씬 이전의 추상화였다 — 모든 DB 접근이 사내 서비스 뒤에 있어 대부분의 팀에게 마이그레이션이 설정 변경 수준이었다.
관련 위키 (추가)
- LLM-as-Judge — 라이프사이클, RART, 드리프트 밴드
- Agentic ML Modeling — 프롬프트·모델 선택 최적화 루프
- AI Accelerator Architecture — 서빙 비용의 하드웨어 근거
- Tokenization Economics
- Vector Database Selection
- Loop Engineering
- Consensus Engineering — 답이 아니라 trace를 평가
관련 이슈: DEW #256, #257, #258, #261, #262, #263, #264, #265, #266, #267, #268, #269, #277, #278, #280, #284, #285, #286