LLM 앱 프레임워크가 풀어야 할 5가지 문제를 한 눈에 보여줘. 멘탈 모델을 먼저 잡고, 나머지 도식이 어디에 위치하는지 기준점을 만들어.
💡 핵심 개념: LLM은 텍스트를 입력받아 텍스트를 출력하는 함수에 불과. 실전 LLM 앱은 그 함수를 둘러싼 5가지 주변 문제(외부 지식, 도구 사용, 프롬프트 관리, 타입 안전성, 에이전트 흐름)를 풀어야 함. 이 5가지가 프레임워크 비교의 진짜 축.
mindmap
root((LLM 앱
프레임워크))
RAG Pipeline
인덱싱
문서 로드
청크 분할
임베딩
검색·생성
벡터 검색
리랭킹
컨텍스트 주입
에이전트
오케스트레이션
ReAct 루프
Tool 호출
State 관리
Human-in-loop
프롬프트 최적화
시그니처
모듈 조립
컴파일러
평가 메트릭
타입 안정성
Pydantic Schema
DI
모킹
시스템 통합
🔧 5가지 축의 의미
- RAG Pipeline — LLM이 모르는 외부 지식을 검색해 컨텍스트로 주입. 왜? LLM 학습 cutoff 이후 데이터, 사내 문서, 실시간 DB는 직접 모름.
- 에이전트 오케스트레이션 — LLM이 스스로 도구를 골라 반복 실행. 왜? 단일 호출로 끝나지 않는 다단계 추론(검색→읽기→코딩→검증).
- 프롬프트 최적화 — 사람이 손으로 짜는 프롬프트를 컴파일러가 자동 튜닝. 왜? 모델 변경 시 프롬프트 재작성이 부담, few-shot 예시도 데이터로 관리.
- 타입 안정성 — LLM의 자유 텍스트 출력을 구조화된 객체로 강제. 왜? JSON 파싱 실패가 프로덕션 장애 원인 1위.
📋 구체적 예시: 사내 HR 정책 챗봇을 만든다고 치면 —
- RAG: HR 정책 PDF를 인덱싱해서 "연차 며칠?"에 정확히 답하게
- Agent: "내 연차 잔여 알려줘" → DB 조회 tool 호출 → 답변
- Prompt Opt: "답변 톤"을 컴파일러로 자동 튜닝
- Type Safety: tool 결과를 Pydantic 모델로 파싱 (실패 시 graceful)
⚠️ 흔한 함정:
- 한 축(예: RAG)만 깊게 파고 나머지를 무시 → 나중에 통합 지옥
- "LangChain = 다 된다"는 환상 → 범용성은 깊이 희생
- 5축을 다 처음부터 만들려 함 → RAG → Agent → Type 순서로 단계적 도입이 안전
🛠️ 관련 프레임워크: 각 축의 1등 시민 — LlamaIndex/Haystack(RAG), LangGraph/AutoGen/CrewAI(Agent), DSPy(Prompt Opt), Pydantic AI/Instructor/Semantic Kernel(Type Safety).