AI 엔지니어 on 매일 한 가지

Day 01 — Python & Linux: AI 엔지니어의 개발 환경

Sat, 04 Jul 2026 00:00:00 +0000

Phase 1: 기초 | 예상 학습 시간: 40분

🎯 학습 목표

AI 엔지니어링에서 Python이 사실상 표준 언어인 이유를 설명할 수 있다
Linux 기본 명령어로 GPU 서버 환경을 다룰 수 있다
가상환경(venv)과 패키지 관리 흐름을 이해한다

1. 왜 Python인가?

대부분의 GPU 제공업체(Runpod, Lambda, AWS)와 딥러닝 프레임워크(PyTorch, Transformers, LangChain, LangGraph)는 Python 기반입니다.

Day 02 — Docker: 앱을 컨테이너로 패키징하기

Sat, 04 Jul 2026 00:00:00 +0000

Phase 1: 기초 | 예상 학습 시간: 40분

🎯 학습 목표

이미지(image)와 컨테이너(container)의 차이를 설명할 수 있다
Python/GPU 애플리케이션을 위한 Dockerfile을 직접 작성할 수 있다
docker build/run/exec와 nvidia-container-toolkit으로 GPU 컨테이너를 실행할 수 있다

1. Docker가 필요한 이유

LLM 애플리케이션은 특정 버전의 Python, CUDA, PyTorch, 시스템 라이브러리(예: libgomp, ffmpeg)에 강하게 의존합니다. “내 컴퓨터에서는 되는데 서버에서는 안 되는” 문제는 대부분 이런 환경 불일치에서 발생합니다.

Day 03 — GPU & CUDA: LLM 추론/학습을 위한 하드웨어 이해

Sat, 04 Jul 2026 00:00:00 +0000

Phase 1: 기초 | 예상 학습 시간: 40분

🎯 학습 목표

GPU가 LLM 연산(행렬 곱셈)에 CPU보다 적합한 이유를 설명할 수 있다
nvidia-smi 출력을 읽고 GPU 상태를 진단할 수 있다
모델 파라미터 수로부터 필요한 VRAM을 추정할 수 있다

1. CPU vs GPU — 왜 GPU인가

CPU는 소수의 강력한 코어(보통 8~64개)로 순차적/분기적 연산을 빠르게 처리하도록 설계되어 있습니다. 반면 GPU는 수천 개의 단순한 코어로 동일한 연산을 대량의 데이터에 동시에 적용하는 데 특화되어 있습니다.

Day 04 — Transformer 아키텍처: 현대 LLM의 근간

Sat, 04 Jul 2026 00:00:00 +0000

Phase 1: 기초 | 예상 학습 시간: 40분

🎯 학습 목표

Self-Attention의 Q/K/V 개념과 계산 흐름을 설명할 수 있다
Multi-Head Attention과 Positional Encoding의 필요성을 이해한다
인코더-디코더 구조와 디코더 전용(decoder-only) 구조의 차이, 그리고 왜 대부분의 LLM이 후자를 택했는지 설명할 수 있다

1. Transformer 이전의 한계 — RNN의 순차성 문제

2017년 “Attention Is All You Need” 논문 이전, 자연어 처리의 주류는 RNN/LSTM이었습니다. RNN은 토큰을 순서대로 하나씩 처리하기 때문에 두 가지 근본적 한계가 있었습니다.

Day 05 — Token / Embedding / Context Window / KV Cache

Sat, 04 Jul 2026 00:00:00 +0000

Phase 1: 기초 | 예상 학습 시간: 40분

🎯 학습 목표

BPE 토큰화 방식과 임베딩이 텍스트를 숫자로 바꾸는 과정을 설명할 수 있다
컨텍스트 윈도우가 실무에서 어떤 제약으로 작동하는지 이해한다
KV 캐시의 목적과 메모리 비용 공식을 계산할 수 있다

1. 토큰화(Tokenization) — 텍스트를 숫자로

LLM은 텍스트를 직접 이해하지 못합니다. 먼저 텍스트를 **토큰(token)**이라는 단위로 쪼개고, 각 토큰을 정수 ID로 변환해야 모델에 입력할 수 있습니다.

Day 06 — Ollama: 가장 간단한 로컬 LLM 실행

Sat, 04 Jul 2026 00:00:00 +0000

Phase 2: 로컬 LLM | 예상 학습 시간: 40분

🎯 학습 목표

Ollama로 로컬에서 LLM을 설치, 실행, 커스터마이징할 수 있다
Ollama의 REST API를 사용해 애플리케이션에서 로컬 모델을 호출할 수 있다
Ollama와 vLLM 중 상황에 맞는 도구를 선택하는 기준을 이해한다

1. Ollama란

Ollama는 로컬 환경(개인 PC, 서버)에서 오픈소스 LLM을 손쉽게 다운로드하고 실행할 수 있게 해주는 도구입니다. 내부적으로 llama.cpp를 엔진으로 사용하며, 모델 다운로드·양자화 버전 관리·REST API 서버·CLI를 하나로 통합해 “가장 진입장벽이 낮은 로컬 LLM 실행 도구"로 자리잡았습니다.

Day 07 — vLLM: 고성능 추론 서버 구축

Sat, 04 Jul 2026 00:00:00 +0000

Phase 2: 로컬 LLM | 예상 학습 시간: 40분

🎯 학습 목표

Hugging Face generate()의 한계와 vLLM이 이를 해결하는 원리(PagedAttention, Continuous Batching)를 설명할 수 있다
vllm serve로 OpenAI 호환 API 서버를 실행하고 핵심 실행 플래그를 이해한다
처리량(throughput)과 지연시간(latency) 사이의 트레이드오프를 판단할 수 있다

1. 왜 naive `generate()`로는 부족한가

Ollama(Day 06)는 “개인이 로컬에서 편하게” 모델을 돌리는 도구였다면, vLLM은 “여러 사용자의 요청을 동시에, 최대한 빠르게” 처리해야 하는 서빙(serving) 상황을 위한 도구입니다.

Day 08 — 양자화 & 추론 최적화: GGUF/GPTQ/AWQ, Tensor Parallel, Flash Attention, Speculative Decoding

Sat, 04 Jul 2026 00:00:00 +0000

Phase 2: 로컬 LLM | 예상 학습 시간: 40분

🎯 학습 목표

GGUF, GPTQ, AWQ의 차이와 각각을 언제 선택해야 하는지 설명할 수 있다
Tensor Parallelism과 Flash Attention이 추론 속도를 개선하는 원리를 이해한다
Speculative Decoding의 draft-verify 구조와 속도 향상 메커니즘을 설명할 수 있다

1. 양자화(Quantization)란 무엇이고 왜 필요한가

LLM의 가중치는 보통 16비트(FP16/BF16) 부동소수점으로 저장됩니다. 70억 개 파라미터 모델이면 대략 14GB, 700억이면 140GB — 개인 GPU는커녕 서버 GPU 여러 장도 부족할 수 있습니다.

Day 09 — Runpod 기초: Pod, Persistent Volume, Template

Sat, 04 Jul 2026 00:00:00 +0000

Phase 3: Runpod & 인프라 | 예상 학습 시간: 35분

🎯 학습 목표

Runpod의 Pod와 Serverless의 차이를 이해하고 상황에 맞게 선택할 수 있다
Persistent Volume과 Container Disk의 차이를 설명할 수 있다
Template을 활용해 재현 가능한 GPU 작업 환경을 구축할 수 있다

1. Runpod이란

Runpod은 시간 단위로 GPU를 대여할 수 있는 클라우드 GPU 서비스입니다. AWS/GCP 대비 훨씬 저렴한 가격에 A100, H100, RTX 4090 등 다양한 GPU를 즉시 대여할 수 있어, 개인이나 소규모 팀이 vLLM 서빙(Day 07)이나 파인튜닝 실습을 할 때 널리 쓰입니다.

Day 10 — SSH / tmux / nvidia-smi: 원격 GPU 서버 운영

Sat, 04 Jul 2026 00:00:00 +0000

Phase 3: Runpod & 인프라 | 예상 학습 시간: 35분

🎯 학습 목표

SSH 키 설정과 포트 포워딩으로 원격 GPU 서버에 안전하게 접속할 수 있다
tmux로 세션을 유지해 연결이 끊겨도 장시간 작업이 살아있게 만들 수 있다
nvidia-smi 출력을 읽고 GPU 상태를 실시간으로 모니터링할 수 있다

1. SSH 키 설정 — Runpod 접속의 첫걸음

Runpod Pod(Day 09)는 기본적으로 SSH로 접속합니다. 비밀번호 대신 공개키 방식을 씁니다.

Day 11 — LangGraph 개념: State, Node, Edge

Sat, 04 Jul 2026 00:00:00 +0000

Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분

🎯 학습 목표

함수 체이닝 방식 대비 그래프 기반 에이전트 프레임워크가 필요한 이유를 설명할 수 있다
State, Node, Edge의 역할과 관계를 이해한다
2~3개 노드로 구성된 최소 동작 LangGraph 예제를 직접 작성하고 실행할 수 있다

1. 왜 단순 함수 체이닝으로는 부족한가

LLM 애플리케이션을 처음 만들 때는 보통 이렇게 짭니다.

Day 12 — Conditional Edge & Checkpoint — 분기와 상태 저장

Sat, 04 Jul 2026 00:00:00 +0000

Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분

🎯 학습 목표

add_conditional_edges로 라우터 함수 기반의 분기 그래프를 설계할 수 있다
Checkpointer(MemorySaver, SqliteSaver)로 그래프 상태를 영속화하는 원리를 이해한다
thread_id를 이용해 중단된 그래프를 이어서 실행할 수 있다

1. 왜 조건부 엣지가 필요한가?

Day 11에서 다룬 기본 그래프는 노드가 순차적으로 실행되는 선형(linear) 구조였습니다. 하지만 실제 에이전트는 “이 답변이 충분한가? 아니면 재시도해야 하는가”, “도구 호출이 필요한가, 아니면 바로 종료할 수 있는가” 같은 판단을 매 스텝마다 내려야 합니다.

Day 13 — Interrupt & Human-in-the-loop — 사람이 개입하는 워크플로우

Sat, 04 Jul 2026 00:00:00 +0000

Phase 4: 에이전트 프레임워크 | 예상 학습 시간: 40분

🎯 학습 목표

interrupt_before/interrupt_after로 그래프 실행을 특정 노드 앞뒤에서 일시 정지시킬 수 있다
사람의 승인/수정을 받은 뒤 State를 갱신하고 그래프를 재개하는 흐름을 구현할 수 있다
이메일 발송, 결제 등 민감한 액션 전에 HITL(Human-in-the-loop) 게이트를 설계할 수 있다

1. 왜 사람이 개입해야 하는가?

LLM 에이전트가 자율적으로 도구를 호출하는 것은 강력하지만, 되돌릴 수 없는(irreversible) 작업 — 이메일 발송, 결제, 프로덕션 배포, 데이터 삭제 — 을 맡기기엔 위험합니다. 모델이 착각(hallucination)했거나 사용자 의도를 잘못 해석했을 경우, 실행 전에 사람이 검토할 기회가 반드시 있어야 합니다.

Day 14 — MCP 개념 — Server/Client, Tool, Resource, Prompt

Sat, 04 Jul 2026 00:00:00 +0000

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개의 통합 코드가 필요한 상황이었습니다.

Day 15 — stdio vs Streamable HTTP — 전송 방식 이해와 실습

Sat, 04 Jul 2026 00:00:00 +0000

Phase 5: MCP | 예상 학습 시간: 40분

🎯 학습 목표

MCP의 두 가지 표준 전송 방식(stdio, Streamable HTTP)의 동작 원리와 차이를 설명할 수 있다
각 전송 방식이 적합한 배포 시나리오(로컬 데스크톱 vs 네트워크 서비스)를 판단할 수 있다
HTTP로 MCP 서버를 노출할 때 필요한 인증/보안 설정을 구성할 수 있다

1. 전송 방식이 왜 두 개로 나뉘는가?

MCP 프로토콜 자체(JSON-RPC 2.0 메시지 구조)는 전송 방식과 무관하게 동일합니다. 하지만 “이 메시지를 어떻게 실어 나를 것인가"는 완전히 다른 문제입니다. Day 14에서 만든 서버는 로컬에서 클라이언트가 직접 실행하는 프로세스였지만, 팀 전체가 공유하는 내부 도구 서버를 만든다면 네트워크 너머의 여러 클라이언트가 접속해야 합니다. 이 두 시나리오를 위해 MCP는 두 가지 표준 전송(transport)을 정의합니다.

Day 16 — Function Calling & JSON Schema

Sat, 04 Jul 2026 00:00:00 +0000

Phase 6: 툴 콜링 & 구조화 출력 | 예상 학습 시간: 40분

🎯 학습 목표

Function Calling(Tool Use)이 모델-호스트-실행 환경 사이에서 동작하는 전체 흐름을 설명할 수 있다
타입, required, description을 정확히 채운 JSON Schema 도구 정의를 작성할 수 있다
잘못된 도구 호출을 유발하는 흔한 스키마 설계 실수를 식별하고 고칠 수 있다

1. Function Calling의 동작 원리

LLM은 실제로 함수를 “실행"하지 않습니다. 모델이 하는 일은 오직 하나입니다 — 주어진 도구 목록(스키마)을 보고, “지금 상황에서는 이 도구를 이런 인자로 호출하는 게 적절하다"는 구조화된 텍스트(JSON) 를 생성하는 것뿐입니다. 실제 실행은 항상 모델 바깥의 호스트 애플리케이션이 담당합니다.

Day 17 — Structured Output & Pydantic 검증

Sat, 04 Jul 2026 00:00:00 +0000

Phase 6: 툴 콜링 & 구조화 출력 | 예상 학습 시간: 40분

🎯 학습 목표

LLM이 자연어 대신 검증 가능한 구조화된 데이터를 반환하도록 강제하는 방법을 이해한다
Pydantic 모델로 LLM 출력의 스키마를 정의하고 파싱/검증하는 흐름을 구현할 수 있다
검증 실패 시 재시도(retry) 루프를 설계할 수 있다

1. 왜 “구조화 출력"이 필요한가

LLM의 기본 출력은 자유 형식 텍스트입니다. 하지만 실제 프로덕션 시스템에서는 LLM의 응답을 프론트엔드에 렌더링하거나, DB에 저장하거나, 다른 API에 전달해야 하는 경우가 대부분입니다. 이때 “대략 JSON처럼 생긴 텍스트"는 쓸모가 없습니다 — 파싱이 실패하거나, 필드가 누락되거나, 타입이 틀리면 시스템 전체가 죽습니다.

Day 18 — RAG 개념과 Chunking 전략

Sat, 04 Jul 2026 00:00:00 +0000

Phase 7: RAG | 예상 학습 시간: 40분

🎯 학습 목표

RAG 파이프라인 전체 흐름(수집 → 청킹 → 임베딩 → 저장 → 검색 → 증강 → 생성)을 설명할 수 있다
청크 크기와 오버랩이 검색 품질에 미치는 영향을 이해한다
고정 크기/재귀적/시맨틱 청킹 전략의 장단점을 비교하고 상황에 맞게 선택할 수 있다

1. RAG란 무엇이고 왜 필요한가

**RAG(Retrieval-Augmented Generation)**는 LLM이 답변을 생성하기 전에 외부 지식 베이스에서 관련 정보를 검색(retrieve)해 프롬프트에 삽입(augment)하는 아키텍처입니다.

Day 19 — Embedding Model & Similarity Search

Sat, 04 Jul 2026 00:00:00 +0000

Phase 7: RAG | 예상 학습 시간: 40분

🎯 학습 목표

임베딩 모델이 텍스트를 어떤 형태의 벡터로 변환하는지, 그 의미를 설명할 수 있다
임베딩 모델 선택 시 고려해야 할 기준(차원 수, 도메인 적합성, 비용)을 이해한다
코사인 유사도/내적/유클리드 거리의 차이와 ANN 검색이 필요한 이유를 설명할 수 있다

1. 임베딩이란 무엇인가

**임베딩(Embedding)**은 텍스트(단어, 문장, 문서)를 고정된 길이의 실수 벡터로 변환한 것입니다. 예를 들어 “고양이는 귀엽다"라는 문장은 [0.021, -0.384, 0.157, ..., 0.093]처럼 768차원 또는 1536차원의 숫자 배열이 됩니다.

Day 20 — Hybrid Search & Reranker

Sat, 04 Jul 2026 00:00:00 +0000

Phase 7: RAG | 예상 학습 시간: 40분

🎯 학습 목표

순수 벡터 검색이 정확한 키워드 매칭을 놓치는 이유를 설명할 수 있다
BM25(희소 검색)와 벡터 검색(밀집 검색)을 결합하는 하이브리드 검색과 RRF를 이해한다
2단계 정밀 필터로서의 리랭커 도입 시점과 지연시간 트레이드오프를 판단할 수 있다

1. 벡터 검색의 맹점 — “정확히 그 단어"를 놓친다

Day 19에서 다룬 임베딩 기반 벡터 검색은 의미적 유사성을 잘 포착하지만, 역설적으로 정확한 키워드 매칭에는 약합니다.

Day 21 — Qdrant / Chroma 실습

Sat, 04 Jul 2026 00:00:00 +0000

Phase 8: 벡터 데이터베이스 | 예상 학습 시간: 40분

🎯 학습 목표

Chroma(인프로세스 프로토타이핑)와 Qdrant(Docker 기반 프로덕션형)의 차이와 각각의 적합한 사용 시점을 이해한다
두 벡터 DB 모두에서 컬렉션 생성, 벡터+메타데이터 upsert, 필터 조건이 포함된 쿼리를 직접 작성할 수 있다

1. Chroma vs Qdrant — 언제 무엇을 쓰는가

지금까지 RAG의 개념(청킹, 임베딩, 유사도, 하이브리드 검색)을 다뤘다면, 오늘은 이 모든 것을 실제로 담아내는 저장소인 벡터 데이터베이스를 직접 다뤄봅니다.

Day 22 — Milvus / pgvector 비교와 선택 기준

Sat, 04 Jul 2026 00:00:00 +0000

Phase 8: 벡터 데이터베이스 | 예상 학습 시간: 35분

🎯 학습 목표

Milvus의 분산 아키텍처와 pgvector의 “Postgres 확장” 철학의 차이를 설명할 수 있다
프로젝트 규모, 운영 부담, 기존 스택을 기준으로 벡터 DB를 선택할 수 있다
pgvector 기본 SQL(확장 설치, 컬럼 타입, 거리 연산자)을 직접 작성할 수 있다

1. 두 가지 철학: “전용 벡터 DB” vs “기존 DB의 확장”

Day 21에서 다룬 Qdrant, Chroma가 “처음부터 벡터 검색을 위해 설계된” 전용 DB라면, Milvus와 pgvector는 스펙트럼의 양 극단을 보여주는 좋은 대조군입니다.

Day 23 — FastAPI 기초 — REST API 설계

Sat, 04 Jul 2026 00:00:00 +0000

Phase 9: 백엔드 API | 예상 학습 시간: 40분

🎯 학습 목표

FastAPI가 LLM 백엔드의 사실상 표준으로 자리잡은 이유를 설명할 수 있다
Pydantic 모델을 이용해 LLM 호출용 REST 엔드포인트를 직접 작성할 수 있다
Path/Query/Body 파라미터와 의존성 주입(Dependency Injection)의 기본 패턴을 이해한다

1. 왜 LLM 백엔드는 FastAPI로 수렴하는가

지금까지 만든 에이전트, RAG 파이프라인, 벡터 검색 로직은 결국 어떤 형태로든 프론트엔드나 다른 서비스에 “API"로 노출되어야 합니다. Python 생태계에는 Flask, Django도 있지만, LLM 백엔드에서는 FastAPI가 사실상 표준입니다.

Day 24 — WebSocket & Streaming Response, 인증(Authentication)

Sat, 04 Jul 2026 00:00:00 +0000

Phase 9: 백엔드 API | 예상 학습 시간: 40분

🎯 학습 목표

SSE와 WebSocket의 차이와 각각이 적합한 상황을 구분할 수 있다
FastAPI에서 토큰 단위 스트리밍 응답과 WebSocket 채팅 엔드포인트를 구현할 수 있다
API Key와 JWT 기반 인증 미들웨어의 기본 구조를 이해한다

1. 왜 스트리밍이 필요한가

LLM은 토큰을 순차적으로 생성합니다. 전체 응답이 완성될 때까지 기다렸다가 한 번에 반환하면, 답변이 길수록 사용자는 수 초에서 수십 초를 아무 반응 없이 기다려야 합니다. ChatGPT류 UI에서 글자가 하나씩 나타나는 이유가 바로 이 토큰 스트리밍입니다.

Day 25 — Planner / Researcher / Coder / Reviewer 역할 분리

Sat, 04 Jul 2026 00:00:00 +0000

Phase 10: Multi-Agent | 예상 학습 시간: 40분

🎯 학습 목표

하나의 거대 프롬프트(mega-prompt) 대신 역할을 분리한 멀티 에이전트가 신뢰성을 높이는 이유를 설명할 수 있다
Planner/Researcher/Coder/Reviewer의 대표적인 역할 분담 패턴을 이해한다
역할 간 작업 인계(handoff)가 공유 상태 또는 메시지 전달로 이루어지는 방식을 구분할 수 있다

1. 왜 역할을 쪼개는가

하나의 프롬프트에 “계획을 세우고, 조사하고, 코드를 짜고, 검토까지 해줘"라고 요청하면 모델은 각 단계를 대충 뭉뚱그려 처리하는 경향이 있습니다. 컨텍스트가 길어질수록 앞서 세운 계획을 잊거나, 코드를 작성하면서 동시에 스스로를 비판적으로 검토하는 이중 역할을 잘 수행하지 못합니다.

Day 26 — Supervisor 패턴 & Memory 설계

Sat, 04 Jul 2026 00:00:00 +0000

Phase 10: Multi-Agent | 예상 학습 시간: 40분

🎯 학습 목표

Supervisor(오케스트레이터) 에이전트가 워커 에이전트를 라우팅하고 종료를 판단하는 방식을 설명할 수 있다
단기 메모리(대화 버퍼)와 장기 메모리(벡터 저장소 회상)의 차이와 사용 시점을 구분할 수 있다
메모리를 언제 영속화하고 언제 휘발시켜야 하는지 판단 기준을 세울 수 있다

1. Supervisor 패턴 — 중앙에서 라우팅하는 오케스트레이터

Day 25에서 다룬 Planner/Researcher/Coder/Reviewer가 “고정된 순서"로 흘러가는 파이프라인이었다면, Supervisor 패턴은 그보다 한 단계 유연합니다. Supervisor는 스스로 작업을 수행하지 않고, 매 턴마다 “다음에 누가 일해야 하는가"를 판단해서 적절한 워커 에이전트에게 작업을 위임하는 라우터 겸 종료 판단자 역할을 합니다.

Day 27 — Langfuse: Logging & Tracing

Sat, 04 Jul 2026 00:00:00 +0000

Phase 11: 관찰성 | 예상 학습 시간: 35분

🎯 학습 목표

LLM 애플리케이션에서 로깅/트레이싱이 일반 웹 서비스보다 훨씬 중요한 이유를 설명할 수 있다
Langfuse로 LangGraph/LangChain 에이전트의 실행을 trace/span/generation 단위로 계측할 수 있다
호출당 비용, 지연시간, 토큰 사용량을 추적하고 대시보드에서 분석할 수 있다

1. 왜 LLM 앱은 “블랙박스 디버깅"이 되는가

일반적인 백엔드 서비스는 입력이 같으면 출력도 같습니다(결정적, deterministic). 하지만 LLM 기반 에이전트는 다음과 같은 특성 때문에 전통적인 디버깅 방식이 통하지 않습니다.

Day 28 — Metrics & Evaluation: 에이전트 품질 측정

Sat, 04 Jul 2026 00:00:00 +0000

Phase 11: 관찰성 | 예상 학습 시간: 35분

🎯 학습 목표

자유 형식 텍스트 출력을 평가하는 것이 왜 근본적으로 어려운지 이해한다
LLM-as-judge, 규칙 기반 지표, 사람 평가를 상황에 맞게 선택할 수 있다
작은 평가 데이터셋을 구축하고 프롬프트/모델 변경 전 회귀 테스트에 활용할 수 있다

1. “정답이 하나가 아닌” 출력을 어떻게 채점하는가

전통적인 소프트웨어 테스트는 assert result == expected로 충분합니다. 하지만 LLM 출력은 다음과 같은 이유로 단순 비교가 통하지 않습니다.

Day 29 — LoRA / QLoRA / PEFT: 효율적 파인튜닝

Sat, 04 Jul 2026 00:00:00 +0000

Phase 12: 파인튜닝 | 예상 학습 시간: 40분

🎯 학습 목표

전체 파인튜닝(Full Fine-Tuning)이 왜 비용/메모리 측면에서 비현실적인지 설명할 수 있다
LoRA의 저랭크 어댑터 원리와 QLoRA가 여기에 4비트 양자화를 더하는 이유를 이해한다
PEFT 라이브러리로 LoRA 파인튜닝을 실행하고 어댑터를 베이스 모델에 병합할 수 있다

1. 전체 파인튜닝(Full Fine-Tuning)이 비싼 이유

전체 파인튜닝은 사전학습된 모델의 모든 파라미터를 학습 대상으로 삼아 역전파(backpropagation)로 업데이트하는 방식입니다. 7B(70억) 파라미터 모델 기준으로 메모리 요구량을 계산해보면:

Day 30 — SFT / DPO / RLHF: 정렬(Alignment) 기법 비교

Sat, 04 Jul 2026 00:00:00 +0000

Phase 12: 파인튜닝 | 예상 학습 시간: 40분

🎯 학습 목표

사전학습부터 정렬까지 이어지는 표준 LLM 학습 파이프라인의 각 단계를 설명할 수 있다
RLHF의 보상 모델 + PPO 구조가 왜 복잡하고 불안정한지 이해한다
DPO가 별도 보상 모델 없이 선호 데이터를 직접 학습에 반영하는 원리를 이해하고, SFT만으로 충분한 경우와 DPO까지 필요한 경우를 구분할 수 있다

1. 표준 정렬 파이프라인: Pretrain → SFT → Preference Tuning

오늘날 대부분의 상용/오픈 LLM(GPT, Claude, Llama 등)은 단일 학습 단계가 아니라 여러 단계를 거쳐 만들어집니다.

Day 31 — 통합 프로젝트: Runpod → vLLM → Local LLM → LangGraph → MCP → RAG → FastAPI → Web UI

Sat, 04 Jul 2026 00:00:00 +0000

Final Project | 예상 소요 시간: 1~2주 (파트타임 기준)

🎯 프로젝트 목표

지난 30일 동안 조각조각 배운 GPU 인프라, 로컬 LLM 서빙, 에이전트 프레임워크, 도구 연동, 검색 증강, API 서버, 관찰성, 파인튜닝을 하나의 파이프라인으로 엮습니다. 이 프로젝트를 마치면 다음이 모두 갖춰진 상태가 됩니다.

AI 엔지니어 on 매일 한 가지

Day 01 — Python & Linux: AI 엔지니어의 개발 환경

🎯 학습 목표

1. 왜 Python인가?

Day 02 — Docker: 앱을 컨테이너로 패키징하기

🎯 학습 목표

1. Docker가 필요한 이유

Day 03 — GPU & CUDA: LLM 추론/학습을 위한 하드웨어 이해

🎯 학습 목표

1. CPU vs GPU — 왜 GPU인가

Day 04 — Transformer 아키텍처: 현대 LLM의 근간

🎯 학습 목표

1. Transformer 이전의 한계 — RNN의 순차성 문제

Day 05 — Token / Embedding / Context Window / KV Cache

🎯 학습 목표

1. 토큰화(Tokenization) — 텍스트를 숫자로

Day 06 — Ollama: 가장 간단한 로컬 LLM 실행

🎯 학습 목표

1. Ollama란

Day 07 — vLLM: 고성능 추론 서버 구축

🎯 학습 목표

1. 왜 naive generate()로는 부족한가

Day 08 — 양자화 & 추론 최적화: GGUF/GPTQ/AWQ, Tensor Parallel, Flash Attention, Speculative Decoding

🎯 학습 목표

1. 양자화(Quantization)란 무엇이고 왜 필요한가

Day 09 — Runpod 기초: Pod, Persistent Volume, Template

🎯 학습 목표

1. Runpod이란

Day 10 — SSH / tmux / nvidia-smi: 원격 GPU 서버 운영

🎯 학습 목표

1. SSH 키 설정 — Runpod 접속의 첫걸음

Day 11 — LangGraph 개념: State, Node, Edge

🎯 학습 목표

1. 왜 단순 함수 체이닝으로는 부족한가

Day 12 — Conditional Edge & Checkpoint — 분기와 상태 저장

🎯 학습 목표

1. 왜 조건부 엣지가 필요한가?

Day 13 — Interrupt & Human-in-the-loop — 사람이 개입하는 워크플로우

🎯 학습 목표

1. 왜 사람이 개입해야 하는가?

Day 14 — MCP 개념 — Server/Client, Tool, Resource, Prompt

🎯 학습 목표

1. MCP가 해결하는 문제

Day 15 — stdio vs Streamable HTTP — 전송 방식 이해와 실습

🎯 학습 목표

1. 전송 방식이 왜 두 개로 나뉘는가?

Day 16 — Function Calling & JSON Schema

🎯 학습 목표

1. Function Calling의 동작 원리

Day 17 — Structured Output & Pydantic 검증

🎯 학습 목표

1. 왜 “구조화 출력"이 필요한가

Day 18 — RAG 개념과 Chunking 전략

🎯 학습 목표

1. RAG란 무엇이고 왜 필요한가

Day 19 — Embedding Model & Similarity Search

🎯 학습 목표

1. 임베딩이란 무엇인가

Day 20 — Hybrid Search & Reranker

🎯 학습 목표

1. 벡터 검색의 맹점 — “정확히 그 단어"를 놓친다

Day 21 — Qdrant / Chroma 실습

🎯 학습 목표

1. Chroma vs Qdrant — 언제 무엇을 쓰는가

Day 22 — Milvus / pgvector 비교와 선택 기준

🎯 학습 목표

1. 두 가지 철학: “전용 벡터 DB” vs “기존 DB의 확장”

Day 23 — FastAPI 기초 — REST API 설계

🎯 학습 목표

1. 왜 LLM 백엔드는 FastAPI로 수렴하는가

Day 24 — WebSocket & Streaming Response, 인증(Authentication)

🎯 학습 목표

1. 왜 스트리밍이 필요한가

Day 25 — Planner / Researcher / Coder / Reviewer 역할 분리

🎯 학습 목표

1. 왜 역할을 쪼개는가

Day 26 — Supervisor 패턴 & Memory 설계

🎯 학습 목표

1. Supervisor 패턴 — 중앙에서 라우팅하는 오케스트레이터

Day 27 — Langfuse: Logging & Tracing

1. 왜 naive `generate()`로는 부족한가