파이썬 기초부터 Local LLM, LangGraph, MCP, RAG, FastAPI를 거쳐 실전 배포까지 순차적으로 학습합니다. 매일 하나의 강의노트가 추가되어 아래 목록에 이어서 쌓입니다.
Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분 🎯 학습 목표 함수 체이닝 방식 대비 그래프 기반 에이전트 프레임워크가 필요한 이유를 설명할 수 있다 State, Node, Edge의 역할과 관계를 이해한다 2~3개 노드로 구성된 최소 동작 LangGraph 예제를 직접 작성하고 실행할 수 있다 1. 왜 단순 함수 체이닝으로는 부족한가 LLM 애플리케이션을 처음 만들 때는 보통 이렇게 짭니다. ...
Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분 🎯 학습 목표 add_conditional_edges로 라우터 함수 기반의 분기 그래프를 설계할 수 있다 Checkpointer(MemorySaver, SqliteSaver)로 그래프 상태를 영속화하는 원리를 이해한다 thread_id를 이용해 중단된 그래프를 이어서 실행할 수 있다 1. 왜 조건부 엣지가 필요한가? Day 11에서 다룬 기본 그래프는 노드가 순차적으로 실행되는 선형(linear) 구조였습니다. 하지만 실제 에이전트는 “이 답변이 충분한가? 아니면 재시도해야 하는가”, “도구 호출이 필요한가, 아니면 바로 종료할 수 있는가” 같은 판단을 매 스텝마다 내려야 합니다. ...
Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분 🎯 학습 목표 interrupt_before/interrupt_after로 그래프 실행을 특정 노드 앞뒤에서 일시 정지시킬 수 있다 사람의 승인/수정을 받은 뒤 State를 갱신하고 그래프를 재개하는 흐름을 구현할 수 있다 이메일 발송, 결제 등 민감한 액션 전에 HITL(Human-in-the-loop) 게이트를 설계할 수 있다 1. 왜 사람이 개입해야 하는가? LLM 에이전트가 자율적으로 도구를 호출하는 것은 강력하지만, 되돌릴 수 없는(irreversible) 작업 — 이메일 발송, 결제, 프로덕션 배포, 데이터 삭제 — 을 맡기기엔 위험합니다. 모델이 착각(hallucination)했거나 사용자 의도를 잘못 해석했을 경우, 실행 전에 사람이 검토할 기회가 반드시 있어야 합니다. ...
Phase 5: MCP | 예상 학습 시간: 40분 🎯 학습 목표 MCP(Model Context Protocol)가 표준화하려는 문제와 “USB-C for AI” 비유의 의미를 설명할 수 있다 MCP Server가 노출하는 세 가지 프리미티브(Tool, Resource, Prompt)의 차이를 구분할 수 있다 Python mcp SDK로 도구 하나를 노출하는 최소 MCP 서버를 작성할 수 있다 1. MCP가 해결하는 문제 LLM 에이전트가 외부 시스템(파일, DB, API, SaaS 툴)과 상호작용하려면 “이 도구가 뭘 하는지, 어떻게 호출하는지"를 모델에게 알려줘야 합니다. MCP 이전에는 이 연동을 각 애플리케이션(Claude Desktop, IDE 플러그인, 커스텀 에이전트)마다 각자 다른 방식으로 구현했습니다 — N개의 클라이언트가 M개의 도구와 연동하려면 N×M개의 통합 코드가 필요한 상황이었습니다. ...
Phase 5: MCP | 예상 학습 시간: 40분 🎯 학습 목표 MCP의 두 가지 표준 전송 방식(stdio, Streamable HTTP)의 동작 원리와 차이를 설명할 수 있다 각 전송 방식이 적합한 배포 시나리오(로컬 데스크톱 vs 네트워크 서비스)를 판단할 수 있다 HTTP로 MCP 서버를 노출할 때 필요한 인증/보안 설정을 구성할 수 있다 1. 전송 방식이 왜 두 개로 나뉘는가? MCP 프로토콜 자체(JSON-RPC 2.0 메시지 구조)는 전송 방식과 무관하게 동일합니다. 하지만 “이 메시지를 어떻게 실어 나를 것인가"는 완전히 다른 문제입니다. Day 14에서 만든 서버는 로컬에서 클라이언트가 직접 실행하는 프로세스였지만, 팀 전체가 공유하는 내부 도구 서버를 만든다면 네트워크 너머의 여러 클라이언트가 접속해야 합니다. 이 두 시나리오를 위해 MCP는 두 가지 표준 전송(transport)을 정의합니다. ...
Phase 6: 툴 콜링 & 구조화 출력 | 예상 학습 시간: 40분 🎯 학습 목표 Function Calling(Tool Use)이 모델-호스트-실행 환경 사이에서 동작하는 전체 흐름을 설명할 수 있다 타입, required, description을 정확히 채운 JSON Schema 도구 정의를 작성할 수 있다 잘못된 도구 호출을 유발하는 흔한 스키마 설계 실수를 식별하고 고칠 수 있다 1. Function Calling의 동작 원리 LLM은 실제로 함수를 “실행"하지 않습니다. 모델이 하는 일은 오직 하나입니다 — 주어진 도구 목록(스키마)을 보고, “지금 상황에서는 이 도구를 이런 인자로 호출하는 게 적절하다"는 구조화된 텍스트(JSON) 를 생성하는 것뿐입니다. 실제 실행은 항상 모델 바깥의 호스트 애플리케이션이 담당합니다. ...
Phase 6: 툴 콜링 & 구조화 출력 | 예상 학습 시간: 40분 🎯 학습 목표 LLM이 자연어 대신 검증 가능한 구조화된 데이터를 반환하도록 강제하는 방법을 이해한다 Pydantic 모델로 LLM 출력의 스키마를 정의하고 파싱/검증하는 흐름을 구현할 수 있다 검증 실패 시 재시도(retry) 루프를 설계할 수 있다 1. 왜 “구조화 출력"이 필요한가 LLM의 기본 출력은 자유 형식 텍스트입니다. 하지만 실제 프로덕션 시스템에서는 LLM의 응답을 프론트엔드에 렌더링하거나, DB에 저장하거나, 다른 API에 전달해야 하는 경우가 대부분입니다. 이때 “대략 JSON처럼 생긴 텍스트"는 쓸모가 없습니다 — 파싱이 실패하거나, 필드가 누락되거나, 타입이 틀리면 시스템 전체가 죽습니다. ...
Phase 7: RAG | 예상 학습 시간: 40분 🎯 학습 목표 RAG 파이프라인 전체 흐름(수집 → 청킹 → 임베딩 → 저장 → 검색 → 증강 → 생성)을 설명할 수 있다 청크 크기와 오버랩이 검색 품질에 미치는 영향을 이해한다 고정 크기/재귀적/시맨틱 청킹 전략의 장단점을 비교하고 상황에 맞게 선택할 수 있다 1. RAG란 무엇이고 왜 필요한가 **RAG(Retrieval-Augmented Generation)**는 LLM이 답변을 생성하기 전에 외부 지식 베이스에서 관련 정보를 검색(retrieve)해 프롬프트에 삽입(augment)하는 아키텍처입니다. ...
Phase 7: RAG | 예상 학습 시간: 40분 🎯 학습 목표 임베딩 모델이 텍스트를 어떤 형태의 벡터로 변환하는지, 그 의미를 설명할 수 있다 임베딩 모델 선택 시 고려해야 할 기준(차원 수, 도메인 적합성, 비용)을 이해한다 코사인 유사도/내적/유클리드 거리의 차이와 ANN 검색이 필요한 이유를 설명할 수 있다 1. 임베딩이란 무엇인가 **임베딩(Embedding)**은 텍스트(단어, 문장, 문서)를 고정된 길이의 실수 벡터로 변환한 것입니다. 예를 들어 “고양이는 귀엽다"라는 문장은 [0.021, -0.384, 0.157, ..., 0.093]처럼 768차원 또는 1536차원의 숫자 배열이 됩니다. ...
Phase 7: RAG | 예상 학습 시간: 40분 🎯 학습 목표 순수 벡터 검색이 정확한 키워드 매칭을 놓치는 이유를 설명할 수 있다 BM25(희소 검색)와 벡터 검색(밀집 검색)을 결합하는 하이브리드 검색과 RRF를 이해한다 2단계 정밀 필터로서의 리랭커 도입 시점과 지연시간 트레이드오프를 판단할 수 있다 1. 벡터 검색의 맹점 — “정확히 그 단어"를 놓친다 Day 19에서 다룬 임베딩 기반 벡터 검색은 의미적 유사성을 잘 포착하지만, 역설적으로 정확한 키워드 매칭에는 약합니다. ...