정의

LLM을 데모가 아닌 프로덕션 시스템·제품으로 통합할 때 반복적으로 등장하는 7가지 엔지니어링 패턴. 각 패턴은 (1) 성능 향상 vs 비용·리스크 절감, (2) 데이터 가까움 vs 사용자 가까움이라는 두 축 위에 배치된다.

핵심 속성

  • 7대 패턴 (데이터→사용자 순):
    1. Evals — 성능 측정. 작업별 eval 데이터셋(EDD, Eval Driven Development) 구축. BLEU/ROUGE 같은 전통 지표는 인간 판단과 상관 낮음. G-Eval처럼 LLM-as-judge가 새 표준 (단 position/verbosity/self-enhancement bias 보정 필요).
    2. RAG (Retrieval-Augmented Generation) — 외부 지식 주입으로 hallucination 감소. Hybrid retrieval (BM25 + semantic embedding) > 단일 방식. 핵심 기법: DPR, FiD, RETRO, HyDE. ANN 인덱스로 ScaNN/HNSW/FAISS.
    3. Fine-tuning — 특정 작업 성능·통제 강화. LoRA/QLoRA가 진입점 (전체 파라미터 0.1~3.6%만 업데이트해도 full FT 근접). InstructGPT는 13k 시연 + 33k 비교 + 31k RLHF 프롬프트 사용.
    4. Caching — 지연·비용 절감. 의미 기반 캐싱은 위험 (MI2 vs MI3 충돌). 안전 대안: item ID, ID 페어, 제한된 입력 변수 기반. 사용 패턴이 power law일 때 효과적.
    5. Guardrails — 출력 품질 보장. 구조적(Guidance, JSON 스키마), 구문적(SQL/코드 검증), 의미적(원문과 코사인 유사도), 안전(욕설/유해성), 입력 가드레일. NeMo-Guardrails는 LLM-as-validator.
    6. Defensive UX — 오류·불일치 우아한 처리. MS/Google/Apple Human-AI 가이드라인 종합. 사용자 여정 단계별 원칙: 초기 능력 명시, 중간 컨텍스트 활용, 잘못 시 효율적 정정, 시간 흐름에 따른 학습.
    7. Collect User Feedback — 데이터 플라이휠 구축. 명시적(thumbs up/down) + 암시적(다운로드, 재생성 클릭) 신호 수집 → 다음 fine-tuning 데이터.
  • 두 축: 성능↔리스크/비용, 데이터 가까움↔사용자 가까움.
  • 권장 순서: Evals를 시작점으로 둘 것 (EDD). 측정 없이 다른 패턴 적용은 “장님 비행”.
  • 핵심 통찰: 데모 → 제품 사이의 간극은 이 7개 패턴의 누적 적용으로 메워진다.

관계

  • 20260508-llm-wiki-pattern — 대조 / 보완. LLM Wiki 패턴은 RAG의 “쿼리마다 재발견” 모델 대신 “지식 컴파일·누적” 모델을 제안. 이 글의 RAG 섹션과 직접 대비된다.
  • 📎 원문 — 같은 영역(LLM 시스템 설계)의 다른 관점

인용

“There is a large class of problems that are easy to imagine and build demos for, but extremely hard to make products out of.” — Karpathy (인용)

“Building solid evals should be the starting point for any LLM-based system or product.”

“How important evals are to the team is a major differentiator between folks rushing out hot garbage and those seriously building products in the space.”

출처

📎 클리핑 · eugeneyan.com