파이썬 기초부터 Local LLM, LangGraph, MCP, RAG, FastAPI를 거쳐 실전 배포까지 순차적으로 학습합니다. 매일 하나의 강의노트가 추가되어 아래 목록에 이어서 쌓입니다.
Phase 8: 벡터 데이터베이스 | 예상 학습 시간: 40분 🎯 학습 목표 Chroma(인프로세스 프로토타이핑)와 Qdrant(Docker 기반 프로덕션형)의 차이와 각각의 적합한 사용 시점을 이해한다 두 벡터 DB 모두에서 컬렉션 생성, 벡터+메타데이터 upsert, 필터 조건이 포함된 쿼리를 직접 작성할 수 있다 1. Chroma vs Qdrant — 언제 무엇을 쓰는가 지금까지 RAG의 개념(청킹, 임베딩, 유사도, 하이브리드 검색)을 다뤘다면, 오늘은 이 모든 것을 실제로 담아내는 저장소인 벡터 데이터베이스를 직접 다뤄봅니다. ...
Phase 8: 벡터 데이터베이스 | 예상 학습 시간: 35분 🎯 학습 목표 Milvus의 분산 아키텍처와 pgvector의 “Postgres 확장” 철학의 차이를 설명할 수 있다 프로젝트 규모, 운영 부담, 기존 스택을 기준으로 벡터 DB를 선택할 수 있다 pgvector 기본 SQL(확장 설치, 컬럼 타입, 거리 연산자)을 직접 작성할 수 있다 1. 두 가지 철학: “전용 벡터 DB” vs “기존 DB의 확장” Day 21에서 다룬 Qdrant, Chroma가 “처음부터 벡터 검색을 위해 설계된” 전용 DB라면, Milvus와 pgvector는 스펙트럼의 양 극단을 보여주는 좋은 대조군입니다. ...
Phase 9: 백엔드 API | 예상 학습 시간: 40분 🎯 학습 목표 FastAPI가 LLM 백엔드의 사실상 표준으로 자리잡은 이유를 설명할 수 있다 Pydantic 모델을 이용해 LLM 호출용 REST 엔드포인트를 직접 작성할 수 있다 Path/Query/Body 파라미터와 의존성 주입(Dependency Injection)의 기본 패턴을 이해한다 1. 왜 LLM 백엔드는 FastAPI로 수렴하는가 지금까지 만든 에이전트, RAG 파이프라인, 벡터 검색 로직은 결국 어떤 형태로든 프론트엔드나 다른 서비스에 “API"로 노출되어야 합니다. Python 생태계에는 Flask, Django도 있지만, LLM 백엔드에서는 FastAPI가 사실상 표준입니다. ...
Phase 9: 백엔드 API | 예상 학습 시간: 40분 🎯 학습 목표 SSE와 WebSocket의 차이와 각각이 적합한 상황을 구분할 수 있다 FastAPI에서 토큰 단위 스트리밍 응답과 WebSocket 채팅 엔드포인트를 구현할 수 있다 API Key와 JWT 기반 인증 미들웨어의 기본 구조를 이해한다 1. 왜 스트리밍이 필요한가 LLM은 토큰을 순차적으로 생성합니다. 전체 응답이 완성될 때까지 기다렸다가 한 번에 반환하면, 답변이 길수록 사용자는 수 초에서 수십 초를 아무 반응 없이 기다려야 합니다. ChatGPT류 UI에서 글자가 하나씩 나타나는 이유가 바로 이 토큰 스트리밍입니다. ...
Phase 10: Multi-Agent | 예상 학습 시간: 40분 🎯 학습 목표 하나의 거대 프롬프트(mega-prompt) 대신 역할을 분리한 멀티 에이전트가 신뢰성을 높이는 이유를 설명할 수 있다 Planner/Researcher/Coder/Reviewer의 대표적인 역할 분담 패턴을 이해한다 역할 간 작업 인계(handoff)가 공유 상태 또는 메시지 전달로 이루어지는 방식을 구분할 수 있다 1. 왜 역할을 쪼개는가 하나의 프롬프트에 “계획을 세우고, 조사하고, 코드를 짜고, 검토까지 해줘"라고 요청하면 모델은 각 단계를 대충 뭉뚱그려 처리하는 경향이 있습니다. 컨텍스트가 길어질수록 앞서 세운 계획을 잊거나, 코드를 작성하면서 동시에 스스로를 비판적으로 검토하는 이중 역할을 잘 수행하지 못합니다. ...
Phase 10: Multi-Agent | 예상 학습 시간: 40분 🎯 학습 목표 Supervisor(오케스트레이터) 에이전트가 워커 에이전트를 라우팅하고 종료를 판단하는 방식을 설명할 수 있다 단기 메모리(대화 버퍼)와 장기 메모리(벡터 저장소 회상)의 차이와 사용 시점을 구분할 수 있다 메모리를 언제 영속화하고 언제 휘발시켜야 하는지 판단 기준을 세울 수 있다 1. Supervisor 패턴 — 중앙에서 라우팅하는 오케스트레이터 Day 25에서 다룬 Planner/Researcher/Coder/Reviewer가 “고정된 순서"로 흘러가는 파이프라인이었다면, Supervisor 패턴은 그보다 한 단계 유연합니다. Supervisor는 스스로 작업을 수행하지 않고, 매 턴마다 “다음에 누가 일해야 하는가"를 판단해서 적절한 워커 에이전트에게 작업을 위임하는 라우터 겸 종료 판단자 역할을 합니다. ...
Phase 11: 관찰성 | 예상 학습 시간: 35분 🎯 학습 목표 LLM 애플리케이션에서 로깅/트레이싱이 일반 웹 서비스보다 훨씬 중요한 이유를 설명할 수 있다 Langfuse로 LangGraph/LangChain 에이전트의 실행을 trace/span/generation 단위로 계측할 수 있다 호출당 비용, 지연시간, 토큰 사용량을 추적하고 대시보드에서 분석할 수 있다 1. 왜 LLM 앱은 “블랙박스 디버깅"이 되는가 일반적인 백엔드 서비스는 입력이 같으면 출력도 같습니다(결정적, deterministic). 하지만 LLM 기반 에이전트는 다음과 같은 특성 때문에 전통적인 디버깅 방식이 통하지 않습니다. ...
Phase 11: 관찰성 | 예상 학습 시간: 35분 🎯 학습 목표 자유 형식 텍스트 출력을 평가하는 것이 왜 근본적으로 어려운지 이해한다 LLM-as-judge, 규칙 기반 지표, 사람 평가를 상황에 맞게 선택할 수 있다 작은 평가 데이터셋을 구축하고 프롬프트/모델 변경 전 회귀 테스트에 활용할 수 있다 1. “정답이 하나가 아닌” 출력을 어떻게 채점하는가 전통적인 소프트웨어 테스트는 assert result == expected로 충분합니다. 하지만 LLM 출력은 다음과 같은 이유로 단순 비교가 통하지 않습니다. ...
Phase 12: 파인튜닝 | 예상 학습 시간: 40분 🎯 학습 목표 전체 파인튜닝(Full Fine-Tuning)이 왜 비용/메모리 측면에서 비현실적인지 설명할 수 있다 LoRA의 저랭크 어댑터 원리와 QLoRA가 여기에 4비트 양자화를 더하는 이유를 이해한다 PEFT 라이브러리로 LoRA 파인튜닝을 실행하고 어댑터를 베이스 모델에 병합할 수 있다 1. 전체 파인튜닝(Full Fine-Tuning)이 비싼 이유 전체 파인튜닝은 사전학습된 모델의 모든 파라미터를 학습 대상으로 삼아 역전파(backpropagation)로 업데이트하는 방식입니다. 7B(70억) 파라미터 모델 기준으로 메모리 요구량을 계산해보면: ...
Phase 12: 파인튜닝 | 예상 학습 시간: 40분 🎯 학습 목표 사전학습부터 정렬까지 이어지는 표준 LLM 학습 파이프라인의 각 단계를 설명할 수 있다 RLHF의 보상 모델 + PPO 구조가 왜 복잡하고 불안정한지 이해한다 DPO가 별도 보상 모델 없이 선호 데이터를 직접 학습에 반영하는 원리를 이해하고, SFT만으로 충분한 경우와 DPO까지 필요한 경우를 구분할 수 있다 1. 표준 정렬 파이프라인: Pretrain → SFT → Preference Tuning 오늘날 대부분의 상용/오픈 LLM(GPT, Claude, Llama 등)은 단일 학습 단계가 아니라 여러 단계를 거쳐 만들어집니다. ...