LLM 앱 프레임워크 5축 — 확장 8 도식

코어 6 + 사용자 여정 + 데이터 모델 · 2026-09-21

🎯 추가 선정 기준 (10개 중 2개 픽) ✅ journey (사용자 여정) — "왜 RAG?" 사용자 동기 + UX 흐름. 시스템 이해의 출발점.
✅ classDiagram (데이터 모델) — 시스템이 어떤 객체로 구성돼 있는지. 구현 시 class/Type 설계 기준.
❌ 제외한 2개와 이유
  • erDiagram — classDiagram과 역할 중복(DB 관점). 둘 중 하나면 충분.
  • gantt — 프로젝트 일정. "프레임워크 이해"라는 주제와 거리 있음. 별도 산출물로.
📑 목차
  1. 큰 그림 mindmap
  2. 전략 맵 quadrantChart
  3. 데이터 흐름 flowchart
  4. 시간 순서 sequenceDiagram
  5. 내부 구조 flowchart subgraph
  6. 상태 전이 stateDiagram-v2
  7. ⭐ 사용자 여정 journey
  8. ⭐ 데이터 모델 classDiagram

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

LLM 앱 프레임워크가 풀어야 할 5가지 문제를 한 눈에 보여줘.

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

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

각 프레임워크를 "단순↔복잡" × "오프라인/데이터↔온라인/추론" 2차원에 배치.

왜 필요한가: "내 상황에 어느 프레임워크?" 시각적 의사결정.
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 데이터 흐름.

왜 필요한가: "데이터가 어디서 어디로 가는지" 한 장으로.
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. 시간 순서 — 런타임 호출

사용자 질문이 들어와서 응답이 나가는 런타임 호출 시퀀스.

왜 필요한가: "이 함수가 언제 실행돼?" 디버깅의 기준점.
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. 내부 구조 — 레이어드 아키텍처

시스템을 계층으로 분리. 어디에 어떤 컴포넌트가 사는 보여줌.

왜 필요한가: "내 코드는 어디 폴더에 둬야 하지?" 구성의 기준.
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. 상태 전이 — 문서·질의 라이프사이클

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

왜 필요한가: "이 데이터는 지금 어떤 단계지?" 추적의 기준.
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 --> [*] }

7. ⭐ 사용자 여정 — UX 흐름 추가 픽

RAG 시스템에서 사용자가 어떤 경험을 하는지. 만족도 스코어(1~5)와 함께 표현.

왜 픽했나: 시스템 내부만 보면 "사용자가 진짜 원하는 것"을 놓침. UX 흐름을 먼저 보면 어떤 기능이 가치 있는지 우선순위가 잡힘.
journey title RAG 시스템 사용자 여정 section 문제 인식 정보 부족 인식: 3: User 시스템 접속: 5: User section 검색 시도 질문 입력: 5: User, System 벡터 검색 실행: 4: System 관련 문서 추출: 4: System section 답변 생성 컨텍스트 구성: 3: System LLM 응답 생성: 5: System 출처 인용 표시: 4: System section 검증 답변 확인: 4: User 후속 질문: 3: User 만족/피드백: 4: User

8. ⭐ 데이터 모델 — 클래스 관계 추가 픽

시스템을 흐르는 핵심 객체들의 구조와 관계.

왜 픽했나: 7번(여정)이 "왜 만드나"라면, 이건 "뭘 만드나". 구현 시 class/type/dataclass 설계의 출발점. ER과 중복이라 ER은 제외.
classDiagram class Document { +String id +String title +String source +DateTime createdAt +Metadata metadata } class Chunk { +String id +String docId +String text +Int position +Int tokenCount } class Embedding { +String chunkId +String model +Float[] vector +Int dimensions } class VectorIndex { +String id +String name +Int dimensions +DistanceMetric metric +upsert(Embedding) +query(Float[]) Chunk[] } class Query { +String text +Float[] embedding +Int topK } class RetrievedChunk { +String chunkId +Float score +String text } class Prompt { +String systemMsg +String userMsg +Chunk[] context } class Response { +String answer +RetrievedChunk[] sources +DateTime generatedAt } Document "1" --> "*" Chunk : splits into Chunk "1" --> "1" Embedding : has Embedding "*" --> "1" VectorIndex : stored in Query --> VectorIndex : searches VectorIndex --> RetrievedChunk : returns RetrievedChunk --> Prompt : context for Prompt --> Response : input to Response --> Query : answers