LLM 앱 프레임워크 5축

1. 큰 그림 — 5축 멘탈 모델

LLM 앱 프레임워크가 풀어야 할 5가지 문제를 한 눈에 보여줘. 멘탈 모델을 먼저 잡고, 나머지 도식이 어디에 위치하는지 기준점을 만들어.

왜 필요한가: 큰 그림 없이 세부 도식을 보면 길을 잃음. 첫 화면에서 "5개 영역이 있고, 각 영역이 무엇을 푸는지"만 잡으면 됨.

mindmap root((LLM 앱
프레임워크)) RAG Pipeline 인덱싱 문서 로드 청크 분할 임베딩 검색·생성 벡터 검색 리랭킹 컨텍스트 주입 에이전트
오케스트레이션 ReAct 루프 Tool 호출 State 관리 Human-in-loop 프롬프트 최적화 시그니처 모듈 조립 컴파일러 평가 메트릭 타입 안정성 Pydantic Schema DI 모킹 시스템 통합

2. 전략 맵 — 프레임워크 위치

각 프레임워크를 "단순↔복잡" × "오프라인/데이터↔온라인/추론" 2차원에 배치. 내 상황에 맞는 프레임워크를 고를 때 기준이 됨.

왜 필요한가: "LangChain vs LlamaIndex" 같은 선택을 단순 비교표가 아니라 위치로 보여주면 의사결정이 빨라짐.

quadrantChart title LLM 프레임워크 전략 맵 x-axis "단순한 사용성 --> 복잡한 워크플로우" y-axis "오프라인/데이터 --> 온라인/추론" quadrant-1 "복잡 에이전트 (오케스트레이션)" quadrant-2 "프롬프트·타입 (경량 추론)" quadrant-3 "데이터 중심 (RAG/ETL)" quadrant-4 "고급 데이터 파이프라인" LlamaIndex: [0.55, 0.50] Haystack: [0.65, 0.40] LangGraph: [0.85, 0.90] AutoGen: [0.75, 0.85] CrewAI: [0.65, 0.85] DSPy: [0.70, 0.75] Pydantic AI: [0.45, 0.80] Semantic Kernel: [0.80, 0.75] Instructor: [0.35, 0.70]

3. 데이터 흐름 — RAG Pipeline

RAG Pipeline의 end-to-end 데이터 흐름. 인덱싱이 벡터 DB를 채우고, 검색·생성이 그걸 읽어 LLM으로 보냄.

왜 필요한가: "데이터가 어디서 어디로 가는지" 한 장으로 보여줘야 구현할 때 헤매지 않음. 굵은 화살표(==>)가 두 단계 사이의 핵심 흐름.

flowchart LR subgraph OFF["📥 인덱싱 (오프라인·배치)"] D[문서]:::off C[청크]:::off E[임베딩]:::off D --> C --> E end VDB[("🗄️ 벡터 DB")]:::store subgraph ON["🔍 검색·생성 (온라인·추론)"] Q[질의]:::on R[검색·리랭킹]:::on G[컨텍스트 주입]:::on Q --> R --> G end LLM{{"🧠 LLM"}}:::llm A["📨 응답"]:::resp E ==>|"bulk upsert"| VDB VDB ==>|"top-k retrieve"| R G --> LLM --> A classDef off fill:#fef3c7,stroke:#f59e0b,color:#000 classDef on fill:#dbeafe,stroke:#3b82f6,color:#000 classDef store fill:#e5e7eb,stroke:#6b7280,color:#000 classDef llm fill:#f3e8ff,stroke:#a855f7,color:#000 classDef resp fill:#dcfce7,stroke:#10b981,color:#000

4. 시간 순서 — 런타임 호출

사용자 질문이 들어와서 응답이 나가는 런타임 호출 시퀀스. 어느 컴포넌트가 언제 누구에게 호출하는지 보여줌.

왜 필요한가: "이 함수가 언제 실행돼?" "API는 어디서 호출돼?" 같은 디버깅 질문의 답. 흐름도와 다르게 시간 축을 기준으로 정렬.

sequenceDiagram actor User as 👤 사용자 participant API as 🖥️ API participant R as 🔍 Retriever participant VDB as 🗄️ Vector DB participant L as 🧠 LLM User->>API: 질문 입력 activate API API->>R: 검색 요청 (질의) activate R R->>R: 질의 임베딩 R->>VDB: top-k 검색 activate VDB VDB-->>R: 관련 chunk들 deactivate VDB R-->>API: 리랭킹된 chunk들 deactivate R API->>L: 컨텍스트 + 질문 activate L L-->>API: 응답 생성 deactivate L API-->>User: 최종 응답 deactivate API

5. 내부 구조 — 레이어드 아키텍처

시스템을 계층(layer)으로 분리해서 어디에 어떤 컴포넌트가 사는 보여줌. 각 계층의 책임이 명확해짐.

왜 필요한가: "내 코드는 어디 폴더에 둬야 하지?" "이 컴포넌트는 어느 서비스에 들어가?" 같은 구성 질문의 답.

flowchart TB subgraph CL["🖥️ 클라이언트 레이어"] U[👤 사용자] end subgraph AL["🌐 API 레이어"] A["FastAPI 서버"] end subgraph RL["📦 RAG 레이어"] RP["RAG Pipeline"] RT["Retriever"] RD["Indexer"] end subgraph LL["🧠 LLM 레이어"] LP["LLM Provider"] end subgraph SL["💾 스토리지 레이어"] VDB[("Vector DB")] MDB[("Metadata DB")] end subgraph XL["🔁 횡단 관심사"] AG["🤖 Agent"] PO["✨ Prompt Opt"] TS["🛡️ Type Safety"] end U <--> A A --> RP RP --> RD RP --> RT RD --> VDB RT <--> VDB RT --> A A --> LP LP --> A RD <--> MDB AG -.도구.-> LP PO -.최적화.-> LP TS -.검증.-> A

6. 상태 전이 — 문서·질의 라이프사이클

하나의 문서가 어떻게 변환되고, 사용자의 질문이 어떻게 답으로 바뀌는지 상태 전이로 표현.

왜 필요한가: "이 데이터는 지금 어떤 단계지?" "chunk는 어디서 만들어졌지?" 같은 데이터 추적 질문의 답. 각 상태마다 책임 컴포넌트가 다름.

stateDiagram-v2 [*] --> Raw: 문서 입력 Raw: 원본 문서 (PDF/HTML/...) Loaded: 로드 완료 Chunked: 청크 분할 완료 Embedded: 임베딩 완료 Indexed: 벡터 DB 저장 완료 Raw --> Loaded: Loader Loaded --> Chunked: Splitter Chunked --> Embedded: Embedder Embedded --> Indexed: Indexer Indexed --> [*] state QueryFlow { [*] --> Asked Asked: 질의 받음 Embedded2: 질의 임베딩 Retrieved: 검색됨 Augmented: 컨텍스트 구성 Answered: LLM 응답 Asked --> Embedded2: Embedder Embedded2 --> Retrieved: Retriever Retrieved --> Augmented: Composer Augmented --> Answered: LLM Answered --> [*] }