LLM을 "써보는 것"에서 "서비스로 만드는 것"으로 넘어가려는 분을 위한 출발점입니다. LLM 애플리케이션의 전체 구조, RAG·Agent·파인튜닝 중 무엇을 언제 쓰는지, 프레임워크 지형도, 평가·운영까지 — AI 실전 개발 카테고리의 가이드를 어떤 순서로 보면 되는지 로드맵으로 정리합니다.
LLM을 "써보는 것"에서 "서비스로 만드는 것"으로 넘어가려는 분을 위한 출발점입니다. LLM 애플리케이션의 전체 구조, RAG·Agent·파인튜닝 중 무엇을 언제 쓰는지, 프레임워크 지형도, 평가·운영까지 — AI 실전 개발 카테고리의 가이드를 어떤 순서로 보면 되는지 로드맵으로 정리합니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
모델과 프롬프트만 보지 않고, 데이터 흐름, 평가, 배포 이후의 운영 지표까지 한 번에 연결해서 봅니다.
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 AI 실전 입문 & 로드맵를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
AI 실전 입문 & 로드맵를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
| 구성 요소 | 역할 | 담당 가이드 |
|---|---|---|
| 모델 | 텍스트 이해·생성의 엔진 (API 또는 오픈소스) | Hugging Face |
| 체인 / 파이프라인 | 프롬프트·모델·파서를 연결하는 흐름 | LangChain |
| 검색 (Retrieval) | 질문과 관련된 내 문서를 찾아 컨텍스트로 제공 | LlamaIndex, 벡터 DB |
| Agent / 워크플로우 | 도구 호출과 분기·반복을 가진 상태 기반 흐름 | LangGraph, Multi-Agent |
| 도구 연결 표준 | LLM과 외부 도구·데이터의 연결 규격 | MCP |
| 평가 · 운영 | 품질 측정, 비용·지연 모니터링, 배포 | Agent Evaluation, LLMOps |
LLM 서비스의 4가지 구현 패턴은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 패턴 | 구조 | 적합한 경우 | 예시 |
|---|---|---|---|
| ① 프롬프트 + API | 시스템 프롬프트 + 사용자 입력 → 모델 | 일반 지식으로 충분한 요약·번역·분류 | 리뷰 감성 분석, 메일 초안 작성 |
| ② RAG | 질문 → 문서 검색 → 검색 결과 + 질문 → 모델 | 내 데이터·최신 정보 기반 답변 | 사내 규정 Q&A, 제품 매뉴얼 챗봇 |
| ③ Agent (Tool Use) | 모델이 도구 호출을 결정 → 실행 → 결과로 다시 판단 (반복) | 여러 단계 작업, 외부 시스템 조작 | 일정 등록, 데이터 조회 후 리포트 작성 |
| ④ 파인튜닝 | 내 데이터로 모델 자체를 추가 학습 | 고정된 형식·말투·도메인 용어가 중요 | 특정 포맷 보고서 생성, 사내 용어 분류 |
무엇을 언제 쓰나: 선택 기준표은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 증상 | 원인 | 먼저 시도할 것 |
|---|---|---|
| 사내 정보를 모른다 / 최신 정보가 틀린다 | 지식 부족 | RAG |
| 답변 형식이 매번 다르다 | 지시 불명확 | 프롬프트 개선 + 구조화 출력(JSON 스키마) |
| 계산·조회·실행이 필요하다 | 능력 부족 | Agent + Tool Use |
| 프롬프트로도 말투·형식이 안 잡힌다 | 행동 패턴 | 파인튜닝 (마지막 수단) |
| 답변이 너무 느리거나 비싸다 | 모델 크기·호출 수 | 소형 모델, 캐싱, 호출 단계 축소 |
프레임워크 지형도: 무엇이 어떤 문제를 푸나은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 도구 | 핵심 역할 | 강점 | 언제 선택 |
|---|---|---|---|
| LangChain | 프롬프트·모델·도구를 조립하는 범용 체인 | 통합 생태계가 가장 넓음 | 다양한 모델·도구를 빠르게 연결할 때 |
| LlamaIndex | 문서 적재·인덱싱·검색 특화 | RAG 파이프라인 구성이 간결 | 문서 기반 Q&A가 핵심일 때 |
| LangGraph | 상태 그래프 기반 Agent 워크플로우 | 분기·반복·사람 승인 흐름 제어 | 여러 단계 Agent, 장기 실행 작업 |
| MCP | LLM ↔ 도구/데이터 연결 표준 프로토콜 | 한 번 만든 도구를 여러 AI 클라이언트에서 재사용 | 도구를 표준화해 여러 앱에 제공할 때 |
| Hugging Face | 오픈소스 모델 허브 + 학습·추론 라이브러리 | 모델 선택 폭, 파인튜닝 | 자체 호스팅·파인튜닝이 필요할 때 |
| 벡터 DB | 임베딩 저장·유사도 검색 | pgvector(기존 DB 활용), Chroma(간편), Pinecone(관리형) | RAG의 검색 계층 |
여기서는 첫 RAG 30줄: 문서 기반 Q&A의 뼈대을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
# pip install openai numpy
import numpy as np
from openai import OpenAI
client = OpenAI()
docs = [
"연차는 입사 1년 후 15일이 부여되며, 2년마다 1일씩 추가됩니다.",
"재택근무는 주 2회까지 가능하며 팀장 사전 승인이 필요합니다.",
"경조사 휴가는 본인 결혼 5일, 자녀 결혼 1일입니다.",
]
def embed(texts):
res = client.embeddings.create(model="text-embedding-3-small", input=texts)
return np.array([d.embedding for d in res.data])
doc_vecs = embed(docs) # ① 문서 임베딩 저장
def ask(question, k=2):
q = embed([question])[0]
scores = doc_vecs @ q # ② 코사인 유사도(정규화된 벡터)
context = "\n".join(docs[i] for i in scores.argsort()[::-1][:k])
res = client.chat.completions.create( # ③ 검색 결과로 답변
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "아래 문서만 근거로 답하고, 없으면 모른다고 답하세요.\n\n" + context},
{"role": "user", "content": question},
],
)
return res.choices[0].message.content
print(ask("재택근무 몇 번까지 돼?"))AI 서비스 아키텍처: 프로덕션의 모습은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 계층 | 필요한 것 | 관련 가이드 |
|---|---|---|
| API 서버 | 스트리밍 응답, 인증, 요청 제한(rate limit), 타임아웃 | FastAPI, Python AI |
| 데이터 파이프라인 | 문서 수집·분할·임베딩 갱신 배치 | LlamaIndex |
| 캐시 | 동일 질문 응답 캐싱으로 비용·지연 절감 | Redis |
| 가드레일 | 입력 검증, 프롬프트 인젝션 방어, 출력 필터 | Agent Evaluation |
| 관측성 | 요청별 프롬프트·토큰·지연·비용 추적 | LLMOps |
| 배포 | 컨테이너화, 오토스케일, 모델 버전 관리 | Docker, Kubernetes |
시작 전 준비물은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 영역 | 필요 수준 | 확인 방법 |
|---|---|---|
| Python | 함수·클래스·비동기(async/await)·타입 힌트 | 비동기로 API 3개를 동시에 호출하는 코드 작성 |
| HTTP / REST API | 요청·응답·상태 코드·JSON | FastAPI로 CRUD 엔드포인트 구현 |
| LLM 기초 개념 | 토큰, 컨텍스트, 임베딩, temperature | LLM Fundamentals 가이드 요약 가능 |
| 데이터 다루기 | JSON, 텍스트 처리, 기초 SQL | PDF·CSV에서 텍스트 추출 |
| Git · Docker | 버전 관리, 컨테이너 실행 | 내 앱을 Docker 이미지로 빌드 |
단계별 로드맵: 첫 API 호출부터 프로덕션까지은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 단계 | 목표 | 학습 내용 | 가이드 | 완료 체크 |
|---|---|---|---|---|
| 0. 기초 | Python과 LLM 개념 | 비동기 Python, 토큰·임베딩 개념 | Python AI, LLM Fundamentals | LLM API로 구조화 JSON 출력 받기 |
| 1. 모델 다루기 | 모델 선택과 로컬 실행 | 모델 허브, 토크나이저, 추론 파이프라인 | Hugging Face | 오픈소스 모델로 텍스트 분류 실행 |
| 2. 체인 | 프롬프트 파이프라인 구성 | 프롬프트 템플릿, 출력 파서, 체인 조합 | LangChain | 요약→분류→번역 3단 체인 구현 |
| 3. RAG | 내 문서로 답하는 AI | 로더, 청킹, 임베딩, 벡터 검색, 재순위화 | LlamaIndex, 벡터 DB | 출처를 표시하는 문서 Q&A 챗봇 |
| 4. Agent | 도구를 쓰는 AI | Tool Use, 상태 그래프, 사람 승인 단계 | LangGraph | 검색+계산 도구를 쓰는 Agent |
| 5. 도구 표준화 | 재사용 가능한 도구 서버 | MCP 서버·클라이언트, 리소스·프롬프트 | MCP | 사내 DB 조회 MCP 서버 구현 |
| 6. 멀티 에이전트 | 역할 분담 협업 | Supervisor, 핸드오프, 병렬 실행 | Multi-Agent | 조사·작성·검토 3-Agent 파이프라인 |
| 7. 평가 & 운영 | 신뢰할 수 있는 서비스 | 평가 데이터셋, LLM-as-judge, 추적, 비용 관리 | Agent Evaluation, LLMOps | 회귀 평가를 CI에 연결 |
10주 학습 플랜: 하루 1~2시간 기준은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 주차 | 주제 | 결과물 |
|---|---|---|
| 1주 | LLM API, 구조화 출력, 스트리밍 | JSON으로 답하는 리뷰 분석 CLI |
| 2주 | Hugging Face 모델 실행 | 오픈소스 모델 분류기 + API 모델과 비교 표 |
| 3주 | LangChain 체인 구성 | 다단계 문서 요약 체인 |
| 4~5주 | RAG: 청킹, 임베딩, 벡터 DB, 재순위화 | 출처 표시 문서 Q&A (FastAPI + 벡터 DB) |
| 6주 | LangGraph Agent | 도구 3개를 쓰는 리서치 Agent |
| 7주 | MCP 서버 | 내 데이터를 제공하는 MCP 서버 |
| 8주 | 멀티 에이전트 | 작성자-검토자 2-Agent 파이프라인 |
| 9주 | 평가 | 질문 30개 평가셋 + 자동 채점 스크립트 |
| 10주 | 배포와 관측 | Docker 배포 + 토큰·지연 대시보드 |
프로젝트 아이디어: 난이도별은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 난이도 | 프로젝트 | 핵심 기술 |
|---|---|---|
| ★☆☆ | 회의록 요약 + 할 일 추출기 | 구조화 출력, 프롬프트 설계 |
| ★★☆ | 사내 규정·매뉴얼 Q&A 챗봇 | RAG, 출처 표시, 벡터 DB |
| ★★☆ | GitHub 이슈 자동 분류·라벨링 봇 | 분류 체인, 웹훅 연동 |
| ★★★ | 데이터 분석 Agent (SQL 생성 → 실행 → 차트) | Tool Use, LangGraph, 가드레일 |
| ★★★ | 고객 문의 처리 멀티 에이전트 | Supervisor, 핸드오프, 평가 파이프라인 |
AI 실전 개발에서 자주 하는 실수은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 실수 | 결과 | 대신 이렇게 |
|---|---|---|
| 처음부터 Agent·멀티 에이전트로 설계 | 디버깅 불가능한 복잡도 | 단순 프롬프트 → RAG → Agent 순으로 확장 |
| 평가 없이 프롬프트를 수정 | 한 곳 고치면 다른 곳이 깨짐 | 고정 평가셋으로 매 변경마다 비교 |
| 청킹을 기본값으로 방치 | 검색 품질 저하 → 엉뚱한 답변 | 문서 구조(제목·문단) 기준 분할 + 검색 결과 직접 확인 |
| 모든 요청에 최대 모델 사용 | 비용·지연 폭증 | 작업 난이도별 모델 라우팅, 캐싱 |
| 도구 권한을 넓게 부여 | 프롬프트 인젝션 시 데이터 유출·오작동 | 최소 권한, 위험 작업은 사람 승인 |
| LLM 출력을 검증 없이 사용 | 파싱 오류, 잘못된 값 저장 | 스키마 검증(Pydantic) + 재시도 |
핵심 용어 사전은 선택지가 갈리는 지점입니다. 표를 기준으로 각 방법의 쓰임새와 운영상의 차이를 비교해두면 이후 판단이 훨씬 쉬워집니다.
| 용어 | 한 줄 설명 |
|---|---|
| 청킹 (Chunking) | RAG를 위해 문서를 검색 가능한 작은 조각으로 나누는 작업 |
| 재순위화 (Reranking) | 1차 검색 결과를 더 정밀한 모델로 다시 정렬해 정확도를 높이는 단계 |
| 하이브리드 검색 | 키워드 검색(BM25)과 벡터 검색을 결합한 방식 |
| 구조화 출력 | 모델 응답을 JSON 스키마 등 정해진 형식으로 강제하는 기능 |
| Tool Use / Function Calling | 모델이 호출할 함수와 인자를 결정해 반환하는 기능 |
| ReAct | 추론(Reason)과 행동(Act)을 번갈아 수행하는 Agent 패턴 |
| 가드레일 (Guardrail) | 입력·출력을 검사해 위험하거나 잘못된 응답을 차단하는 장치 |
| 프롬프트 인젝션 | 입력에 숨긴 지시로 모델의 원래 규칙을 우회하는 공격 |
| LLM-as-a-Judge | LLM을 채점자로 사용해 다른 LLM의 답변 품질을 평가하는 방법 |
| 트레이싱 (Tracing) | 요청 하나가 거친 프롬프트·도구 호출·토큰을 단계별로 기록하는 것 |