개요
이번 과정에서는 단순히 LLM API를 호출하고 답변을 받아보는데서 끝나지 않았습니다. LLM의 기본 동작을 이해하는 것에서 시작해 Prompt Engineering ,RAG Evaluation , AI Agent , Multi-Agent , Observability , Cost Optimization , Security , Fine-tuning까지 실제로 AI 시스템을 설계하고 운영하기 위해 필요한 요소들을 살펴보았습니다.
각 주차의 주제는 서로 독립적이지 않고 ,모델의 출력이 왜 달라지는지 이해를 하고 Prompt로 이를 제어를 하고, 모델이 알지 못하는 외부 지식을 RAG로 연결을 했습니다.
그리고 , 검색과 답변 품질을 평가하고 , 여러 Tool을 동적으로 사용하는 Agent를 설계했습니다. Agent가 복잡해지면서 실행 과정을 추적하기 위해 Observability를 적용했고 , 운영 단계에서 발생하는 비용과 보안 문제까지 확장해서 살펴보았습니다.
1주차 : LLM 기초와 구조화된 출력
1주차에서는 LLM이 무엇인지 Token과 Context Window가 어떤 의미를 가지는지, 모델이 입력을 바탕으로 다음 Token을 생성하는 Autoregressive 구조로 동작한다는 점을 정리했습니다.
또한 모델 선택 시 단순한 성능뿐 아니라 비용,응답 속도 , 언어 지원 , 출력 제어 가능성을 함께 고려해야 한다는 점을 확인했습니다.
2주차 : Prompt Engineering
2주차에서는 Prompt Engineering을 단순히 모델에게 말을 잘 거는 기술이 아니라, 모델의 판단 기준과 출력 형식을 설계하는 첫 번째 제어 수단으로 이해를 했습니다.
Zero-shot , Few-Shot , Chain-of-Thouht , Self-Consistency 를 각각 적요해서 같은 모델이라도 Prompt 구성에 따라 결과가 달라지는 것을 확인할 수 있었습니다.
의료급여 본인부담률처럼 여러 조건과 수치가 함께 등장하는 문제를 대상으로 실험을 진행했고 ,구조화된 JSON 출력으로 결과를 비교할 수 있도록 구성을 했습니다. 실험에서는 Zero-shot만으로도 일정 수준의 성능을 확인할 수 있었지만, Few-shot을 적용했을 때 정해진 출력 패턴과 판단 기준을 더 안정적으로 따르는 결과를 얻었습니다. CoT는 복잡한 추론에 도움을 줄 수 있었지만 Token과 응답 시간이 증가할 수 있었고 , Self-Consistency는 여러 추론 경로를 비교하는 대신 비용이 커질 수 있었습니다.
⇒ 이를 통해 Prompt 기법은 무조건 많이 적용하는 것이 중요한 것이 아니라, 작업의 복잡도와 비용 , 속도 , 요구사항에 맞게 선택해야 한다는 점을 배울 수 있었습니다.
3주차 : 기본 RAG 구축
3주차에서는 LLM이 가진 지식의 한계와 Context Window 문제를 보완하기 위해 RAG를 구축해보았습니다.
RAG는 모델 내부의 가중치에만 의존하는 것이 아니라, 외부 문서에서 질문과 관련된 정보를 검색한 뒤 그 결과를 Context로 제공하여 답변을 생성하는 방식입니다.
실습에서는 의료급여제도 PDF를 대상으로 다음 흐름을 구성했습니다.
PDF 로드 → Chunking → Embedding 생성 → ChromaDB 저장 → 질문 Embedding → 유사도 검색 → 관련 Context 제공
사용자가 질문하면 질문도 벡터로 변환하고, 저장된 문서 벡터와의 유사도를 계산해 관련 청크를 검색하도록 만들었습니다.
이 과정에서 RAG는 단순히 문서 검색 기능을 추가하는 문제가 아니라는 점도 확인했습니다.
특히 다음 요소들이 최종 답변 품질에 직접적인 영향을 미쳤습니다.
- PDF의 표와 수식 처리 방법
- 페이지 구조 처리
- Chunk 크기
- Chunk Overlap
- 검색된 Context를 LLM에 전달하는 형식
⇒ 즉, RAG의 핵심은 단순히 검색하는 것이 아니라 LLM에게 어떤 Context를 제공할지를 제어하는 것이었습니다.
4주차 : Advanced RAG와 검색 품질 개선
4주차에서는 기본 Vector Search의 한계를 보완하기 위해 Advanced RAG를 구현했습니다.
Vector Search는 의미가 비슷한 문서를 찾는 데 강하지만, 다음과 같이 정확한 표현이 중요한 질문에서는 한계가 발생할 수 있습니다.
- 정확한 키워드
- 수치
- 연도
- 규정명
이를 개선하기 위해 한국어 형태소 분석 기반 BM 계열 검색을 추가하고, Vector Search와 Keyword Search 결과를 RRF 방식으로 결합했습니다.
그 이후에는 Cohere Reranker를 사용하여 검색된 후보 문서를 질문과의 관련도에 따라 다시 정렬했습니다.
또한 2025년과 2026년 문서를 하나의 Vector Database에서 관리하면서 source_year Metadata를 추가해, 사용자의 질문에서 요구한 연도의 문서만 참고하도록 구성했습니다.
PDF의 표를 Markdown 형태로 변환하고 연도 Metadata와 문서 출처를 Context에 함께 표시하면서 검색 결과의 정확성과 추적 가능성도 높였습니다.
⇒ 이 과정에서 검색 품질은 단순히 Top-K를 늘린다고 해결되는 것이 아니라,
검색 방식 + Metadata + Reranking + 문서 구조화가 함께 설계되어야 한다는 점을 확인했습니다.
5주차 : Advanced RAG와 검색 품질 개선
5주차에서는 RAG 시스템을 감으로 평가하는 대신 정량적인 지표를 사용해 비교했습니다.
다음 RAG 구조를 동일한 질문과 Golden Dataset으로 평가했습니다.
- Basic RAG
- Hybrid RAG
- Rerank RAG
- Metadata-Full RAG
또한 검색 단계와 생성 단계를 분리해서 분석했습니다.
- 질문
- 기준 답안
- 기준 Context
- 난이도
- 출처 연도
이를 기반으로 Ragas의 다음 지표를 적용했습니다.
| 평가 지표 | 설명 |
|---|---|
| Context Precision | 검색된 문서 중 실제로 질문과 관련 있는 문서의 비중을 평가합니다. |
| Faithfulness | 생성된 답변이 제공된 근거(Context)를 벗어나지 않고 충실하게 작성되었는지 평가합니다. |
| Answer Relevancy | 사용자의 질문과 생성된 답변이 얼마나 관련되어 있는지 평가합니다. |
| Answer Correctness | 생성된 최종 답변이 기준 답안(Ground Truth)과 얼마나 일치하는지 평가합니다. |
따라서 Context Recall이 낮다면 필요한 근거 문서를 찾지 못한 문제일 수 있고, Context Precision이 낮다면 불필요한 문서가 너무 많이 검색된 문제일 수 있습니다.
검색은 제대로 되었지만 답변이 근거를 벗어났다면 Faithfulness 문제를 의심할 수 있고, 최종 답변이 기준 답안과 다르다면 Answer Correctness를 살펴봐야 합니다.
또한 Advanced 기법을 추가한다고 해서 항상 성능이 좋아지는 것은 아니며, 실제 데이터와 평가 지표를 통해 검증해야 합니다.
하나의 점수만 보는 것이 아니라 실패한 문항을 직접 확인하고 검색 문제인지 생성 문제인지를 구분하는 것이 Evaluation의 핵심이었습니다.
6주차: AI Agent 설계
6주차부터는 정해진 문서를 검색해서 답하는 RAG를 넘어, 사용자의 요청과 현재 상황을 분석하고 다음 행동을 선택하는 AI Agent를 설계했습니다.
실습에서는 KBO 야구장 직관 플래너 Agent를 기획했습니다.
이 Agent는 다음과 같은 정보를 사용자의 상황에 맞게 조합하는 서비스입니다.
- 경기 일정
- 날씨
- 좌석
- 이동 동선
- 티켓팅
- 관전 포인트
- 주변 장소
같은 야구장을 방문하더라도 다음 조건에 따라 필요한 Tool과 실행 순서가 달라질 수 있습니다.
- 낮 경기인지 저녁 경기인지
- 날씨가 어떤지
- 홈 팬인지 원정 팬인지
- 출발지가 어디인지
이 주차에서 가장 중요했던 것은 구현 자체보다 설계였습니다.
먼저 다음을 정의했습니다.
- 정말 Agent가 필요한 문제인가?
- 어떤 Tool을 사용할 것인가?
- Tool 호출이 실패하면 어떻게 대응할 것인가?
- 필수 정보가 없으면 무엇을 사용자에게 질문할 것인가?
- 언제 실행을 종료할 것인가?
⇒ 이를 통해 Agent는 단순히 여러 Tool을 연결한 챗봇이 아니라, 현재 상황을 관찰하고 다음 행동을 선택하는 실행 시스템이라는 점을 이해할 수 있었습니다.
7주차: Multi-Agent와 Agentic Design Pattern
7주차에서는 단일 Agent의 구조를 확장해 여러 역할이 협업하는 Multi-Agent 구조를 살펴봤습니다.
- Multi-Agent를 이해하기 위해 다음 세 가지 관점으로 구분했습니다.
| 구분 | 설명 |
|---|---|
| Tool 또는 Capability | Agent가 수행할 수 있는 기능이나 능력을 의미합니다. |
| Execution Pattern | 해당 능력을 어떤 순서와 조건으로 사용할지 정의한 실행 절차입니다. |
| Agent Archetype | 특정 Tool/Capability와 Execution Pattern을 결합해 구성한 Agent의 역할 유형입니다. |
- 다음과 같은 Agent 실행 패턴을 비교했습니다.
- Prompt Chaining
- Routing
- Parallelization
- ReAct
- Plan-and-Execute
- Reflection
- Orchestrator-Workers
- Graph / State Machine
→ 모든 기능에 하나의 패턴을 사용하는 대신, 문제 특성에 따라 선택해야 합니다.
→ 예를 들어 계획이 명확한 작업에는 Plan-and-Execute를 사용할 수 있고, Tool의 실행 결과에 따라 다음 행동이 달라져야 한다면 ReAct가 적합할 수 있습니다.
→ Multi-Agent가 항상 더 좋은 것도 아닙니다. 단순한 작업을 여러 Agent로 나누면 오히려 통신 비용과 시스템 복잡성만 증가할 수 있습니다.
⇒ 따라서 먼저 단일 Agent나 Workflow로 해결 가능한지 확인하고, 전문성과 책임을 실제로 분리해야 할 필요가 있을 때 Multi-Agent를 적용하는 것이 중요합니다.
8주차 : LLM Observability
8주차에서는 Agent의 실행 과정을 추적하기 위한 LLM Observability를 정리했습니다.
Agent의 최종 답변만 확인해서는 내부에서 어떤 판단이 이루어졌는지 알기 어렵습니다. 실패 원인을 분석하려면 다음과 같은 내용을 확인할 수 있어야 합니다.
- 어떤 Prompt가 사용되었는가
- 어떤 Context가 전달되었는가
- 어떤 Retrieval Query가 사용되었는가
- 어떤 문서가 검색되었는가
- 어떤 Tool을 호출했는가
- Tool에 어떤 인자를 전달했는가
이를 위해 하나의 요청을 Trace로 기록하고 그 내부에 다음 항목을 Span과 Step 형태로 연결했습니다.
Prompt 구성 → Retrieval → Tool Call → LLM Call → Guardrail → Final Answer
⇒ Evaluation이 결과가 좋은지 나쁜지를 판단하는 것이라면, Observability는 왜 그런 결과가 발생했는지를 추적하는 것입니다. Observability는 디버깅 외에도 비용 및 보안과 연결됩니다.
⇒ Trace를 이용하면 불필요한 Token과 Tool 호출을 찾아 비용을 줄일 수 있고, Prompt Injection이나 민감정보 노출 같은 보안 문제도 분석할 수 있습니다. 또한 실패 Trace를 Regression Dataset으로 변환하여 Prompt와 Agent를 개선하는 데 사용할 수 있습니다.
9주차 : Cost Optimization
9주차에서는 AI Agent 운영 비용을 최적화하는 방법을 살펴봤습니다.
Agent 비용은 단순히 모델의 Token 가격만으로 결정되지 않습니다.
다음 요소들이 모두 누적됩니다.
- 모델 호출 횟수
- 대화 History
- Retrieval Context
- Tool Description
- Tool Result
- Retry
- Multi-Agent 호출
- Evaluation 비용
먼저 실제 입력을 모델별로 Tokenize하고 다음 항목을 구분해 요청당 비용을 계산해야 합니다.
- Input Token
- Output Token
- Cached Token
반복되는 긴 System Prompt나 Tool Schema가 있다면 Prompt Caching을 검토할 수 있습니다.
즉시 응답이 필요하지 않은 대량 평가나 분류 작업은 Batch 처리로 분리할 수 있습니다.
애플리케이션에서는 Single Turn과 Multi Turn을 구분해야 하고, 오래된 대화에는 Trim 또는 Summarize를 적용할 수 있습니다.
또한 현재 단계에서 사용하지 않는 Tool은 숨기고, Retrieval 결과나 Tool Result에도 Token Budget을 설정해야 합니다.
인프라 관점에서는 Managed API와 Self-hosted GPU를 다음 조건으로 비교할 수 있습니다.
- 실제 트래픽
- GPU Utilization
- 운영 역량
반복 질문에는 Semantic Cache를 적용할 수도 있습니다.
⇒ 결국 비용 최적화란 단순히 가장 싼 모델을 선택하는 것이 아니라, 필요한 품질은 유지하면서 불필요한 Token·호출·재시도·유휴 인프라를 줄이는 것입니다.
10주차 : AI Security와 Alignment
10주차에서는 AI 시스템의 보안 위험을 다음 관점에서 살펴봤습니다.
- 데이터
- Prompt
- Context
- 출력
- 행동
- 모델
AI 보안은 단순히 모델에게 "위험한 요청은 거절해"라고 지시한다고 해결되는 문제가 아닙니다.
예를 들어 RAG Knowledge Base 안에 오염된 문서가 들어가면 생성된 답변 자체가 왜곡될 수 있습니다.
외부 문서나 이메일에 악성 지시문이 포함되어 있으면 간접 Prompt Injection이 발생할 수 있습니다.
이외에도 사용자가 직접 지시문을 삽입하는 직접 Prompt Injection, 역할극이나 가상 시나리오를 이용해 안전 제한을 우회하는 Jailbreak를 확인했습니다.
방어를 위해서는 외부 Context를 명령이 아니라 참고자료로 취급해야 합니다.
System Prompt에는 API Key나 DB 접속 정보를 넣지 않아야 하며, 실제 권한 검사는 LLM이 아니라 애플리케이션 코드와 인프라에서 수행해야 합니다.
Guardrail과 Safeguard는 입력·출력의 위험성을 탐지하는 보조 수단입니다.
다음과 같은 고위험 행동은 별도의 정책 검사 및 사용자 또는 사람의 승인을 거쳐야 합니다.
- 메일 발송
- 결제
- 데이터 삭제
- 권한 변경
또한 RLHF와 DPO 같은 Alignment·안전 학습을 살펴봤지만, 모델 정렬만으로 완전한 보안을 보장할 수는 없습니다.
따라서 확률적인 모델 위에 결정론적인 권한·정책·로그·모니터링 체계를 겹쳐 놓는 것이 중요합니다.
11주차 : LLM Training과 Fine-tuning
11주차에서는 Pre-training과 Post-training을 구분하고 Fine-tuning이 실제로 어떤 문제에 적합한지 살펴봤습니다.
Pre-training
대규모 데이터에서 언어, 코드, 일반적인 패턴과 지식을 학습하여 Base Model을 만드는 단계입니다.
Post-training
이미 만들어진 모델이 다음을 잘 수행하도록 조정하는 단계입니다.
- 사용자의 지시를 잘 따르기
- 원하는 출력 형식 유지
- 원하는 말투 유지
- 안전한 응답 생성
Fine-tuning은 Post-training 과정 안에서 특정 업무, 출력 형식, 판단 기준, 스타일을 모델에게 반복 학습시키는 방법입니다.
실습에서는 고객 문의 분류와 금융 뉴스 구조화 출력 사례를 이용하여 다음 메시지 구조를 설계했습니다.
System → User → Assistant
또한 다음 개념도 함께 확인했습니다.
- Tokenization
- 모델별 Chat Template
- Assistant 응답만 학습 대상으로 사용하는 Label Masking
⇒ Fine-tuning의 핵심은 새로운 지식을 무조건 모델에게 외우게 하는 것이 아닙니다. 예를 들어 최신 정책이나 계속 변경되는 문서는 RAG가 더 적합할 수 있습니다.
⇒ 단순한 출력 형식 제어라면 Prompt Engineering만으로 충분할 수도 있습니다. Fine-tuning은 특히 반복되는 판단 기준과 출력 형식을 안정적으로 따르게 만드는 문제에 적합합니다. 또한 Fine-tuning의 성능은 모델 설정뿐 아니라 학습 데이터의 일관성과 품질에 크게 좌우됩니다.
마치며
11주차의 과정을 거치며 LLM에 대한 기본적인 이해부터 AI Agent를 구축하기 위해 필요한 다양한 개념들을 학습할 수 있었습니다. 또한 단순히 Agent를 구현하는 것을 넘어, 실제 서비스로 운영하기 위해 고려해야 할 품질, 비용, 보안, 모니터링 등의 요소도 함께 살펴볼 수 있었습니다.
이제까지 학습한 내용을 바탕으로 직접 서비스를 구축하고 실제로 사용할 수 있는 형태로 발전시켜 나가려고 합니다. 구현 과정에서 발생하는 문제를 분석하고 지속적으로 개선하면서, 실제 환경에서 안정적으로 동작하는 AI 서비스를 만들어가는 것을 다음 목표로 삼고자 합니다.
