4단계: 프롬프트 엔지니어링, RAG, Agentic AI

1부. 이론적 기초 — "왜 이 기술들이 필요한가?"

3단계에서 우리는 LLM의 내부 구조를 파헤쳤다. GPT 같은 모델이 어떻게 토큰 하나하나를 예측하며 텍스트를 생성하는지, LoRA로 어떻게 그 거대한 모델을 도메인에 맞게 '미세 조정'하는지 배웠다. 그런데 잠깐, 거기서 한 가지 근본적인 질문이 남는다. "잘 훈련된 LLM에게 그냥 질문하면 되지 않나? 왜 '프롬프트 엔지니어링'이나 '에이전트'같은 복잡한 개념이 필요할까?" 이 질문에 제대로 답하는 것이 4단계 전체의 출발점이다.

LLM은 기본적으로 다음 토큰을 확률적으로 예측하는 기계다. 3단계에서 배운 Transformer 구조를 떠올려 보면, 모델은 입력된 토큰들의 어텐션을 계산하고, 방대한 파라미터를 통해 "이 문맥 다음에 올 가장 그럴듯한 단어"를 고른다. 이 메커니즘 자체는 강력하지만, 세 가지 구조적 한계를 태생적으로 지닌다.

첫 번째 한계는 **추론 실패(Reasoning Failure)**다. "닭이 3마리 있고, 소가 5마리 있다면 다리는 몇 개냐?"처럼 단계적 계산이 필요한 문제를 단순하게 물어보면 LLM은 종종 틀린다. 이건 모델이 멍청해서가 아니다. 토큰 예측 과정이 중간 계산 단계를 '명시적으로' 거치지 않기 때문이다. 마치 어떤 학생이 복잡한 수학 문제를 암산으로만 풀려고 할 때 실수가 생기는 것과 같다. 2단계에서 Transformer의 어텐션이 시퀀스 전체를 한 번에 보는 방식을 배웠는데, 바로 그 구조가 "차례차례 생각하는" 과정을 자연스럽게 지원하지 않는다.

두 번째 한계는 **지식의 단절(Knowledge Cutoff)**이다. LLM은 훈련 데이터가 수집된 시점 이후의 정보를 모른다. 오늘의 주가, 어제 발표된 논문, 우리 회사의 내부 문서 같은 것들은 아무리 강력한 GPT-4라도 알 방법이 없다. 더 심각한 문제는 모른다는 사실을 모른 채로 그럴듯한 거짓말을 만들어낸다는 것인데, 이를 '환각(Hallucination)'이라 부른다. 학교 역사 선생님이 수업 자료를 들고 오지 않고 기억에만 의존해서 가르치다가, 기억이 흐릿한 부분에서 슬며시 이야기를 지어내는 상황을 상상해보라.

세 번째 한계는 **자율성의 부재(Lack of Autonomy)**다. LLM은 기본적으로 '한 번 물어보면 한 번 답하는' 단발성 도구다. 복잡한 실세계 문제는 웹 검색, 코드 실행, 데이터베이스 조회처럼 여러 외부 도구를 순서대로 사용하며 여러 단계에 걸쳐 해결해야 한다. 사람이 어떤 프로젝트를 진행할 때 구글에서 검색하고, 스프레드시트를 열고, 계산기를 쓰고, 동료에게 물어보는 것처럼 말이다. 단순한 질문-답변 LLM에게는 이런 '행동 루프'가 없다.

[노트 기록] LLM의 세 가지 구조적 한계:

추론 실패 → 해결책: 프롬프트 엔지니어링 (CoT, ToT, ReAct)
지식 단절 / 환각 → 해결책: RAG (Retrieval-Augmented Generation)
자율성 부재 → 해결책: Agentic AI (LangChain, AutoGen, CrewAI)

이 세 가지 한계와 세 가지 해결책은 서로 완전히 독립적이지 않다. 앞으로 배우겠지만, 에이전트는 RAG를 도구로 쓰고, ReAct는 에이전트의 핵심 프레임워크가 되며, 이 모두가 프롬프트로 조율된다. 퍼즐 조각들이 어떻게 맞춰지는지 머릿속에 그리면서 읽어나가자.

2부. 프롬프트 엔지니어링 — LLM의 성능을 극대화하는 기술

2-1. 프롬프트란 무엇인가 — 단순한 질문이 아닌 '인지 설계'

초등학생에게 설명한다면, 프롬프트는 그냥 "AI에게 던지는 말"이다. 그런데 전문가의 관점에서 보면, 프롬프트는 **LLM의 거대한 파라미터 공간에서 특정 행동 패턴을 활성화시키는 인지적 자극(cognitive trigger)**이다. 3단계에서 배운 LoRA처럼 파라미터 자체를 바꾸지 않고, 입력 텍스트만으로 모델의 출력 분포를 완전히 달리할 수 있다는 것이 핵심이다.

여기서 잠깐 생각해보자. 같은 사람에게 "이 문제 답이 뭐야?"라고 물을 때와 "이 문제를 단계별로 천천히 설명해줘"라고 물을 때 받는 대답의 질이 다르다. LLM도 마찬가지다. 그 '어떻게 물어볼 것인가'를 체계적으로 연구하는 분야가 **프롬프트 엔지니어링(Prompt Engineering)**이다. 이것은 단순한 말장난이 아니라, 모델의 내부 계산 과정 자체를 다른 경로로 유도하는 기술이다.

2-2. Chain-of-Thought (CoT) — 생각의 사슬을 펼쳐라

2022년 Google의 Wei et al.이 발표한 논문 "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"은 AI 커뮤니티에 충격을 줬다. 방법이 너무나 단순했기 때문이다. 결론부터 말하면, "답을 바로 내지 말고 중간 과정을 써라" 라는 한 줄 지시가 LLM의 수학 추론 능력을 극적으로 향상시켰다.

구체적으로 어떻게 작동하는지 보자. 일반적인 프롬프트 방식(Standard Prompting)은 예제를 이렇게 제공한다. "Q: 사과가 5개 있었는데 3개를 먹었다. 남은 사과는? A: 2개." 반면 CoT 방식은 "Q: 사과가 5개 있었는데 3개를 먹었다. 남은 사과는? A: 처음에 사과가 5개 있었다. 3개를 먹으면 5 - 3 = 2다. 따라서 남은 사과는 2개다." 이렇게 중간 추론 과정을 포함한 예제 몇 개를 앞에 보여주면, 모델은 비슷한 문제에서 자동으로 단계적 추론을 흉내낸다.

더 강력한 변형이 있다. Zero-shot CoT는 예제 없이 단순히 프롬프트 끝에 "Let's think step by step." 이라는 문장 하나를 추가하는 것이다. Kojima et al. (2022)의 연구에서 이 단순한 마법 문장이 다양한 추론 벤치마크에서 성능을 크게 올렸다. 왜 이게 작동하는가? 훈련 데이터에 "step by step"으로 사고하는 텍스트 패턴이 대량으로 포함되어 있어서, 이 문장이 그 패턴을 활성화하는 트리거로 작동하기 때문이다.

[노트 기록] CoT의 두 가지 형태:

Few-shot CoT: 중간 추론 과정이 포함된 예제를 2~8개 제공
Zero-shot CoT: "Let's think step by step" 또는 "단계별로 생각해봐" 추가

CoT의 한계도 중요하다. CoT는 기본적으로 **선형적 사고(linear thinking)**를 유도한다. A → B → C → 답. 이 경로가 막히면? 다른 경로를 시도할 방법이 없다. 이 지점에서 다음 기술이 등장한다.

2-3. Tree of Thoughts (ToT) — 여러 가능성을 탐색하는 나무

2023년 Princeton과 Google DeepMind의 Yao et al.이 발표한 "Tree of Thoughts: Deliberate Problem Solving with Large Language Models"는 CoT를 한 차원 높인다. CoT가 하나의 추론 사슬을 따라가는 것이라면, ToT는 여러 추론 경로를 동시에 탐색하고 평가한다. 마치 장기나 체스에서 "이 수를 두면 다음에 어떻게 될까, 저 수를 두면 어떻게 될까"를 미리 머릿속에서 시뮬레이션하는 것처럼.

ToT의 구조를 이해하려면 트리(Tree) 자료구조를 알아야 한다. 트리는 노드(node)들이 부모-자식 관계로 연결된 구조다. ToT에서 각 노드는 **부분적인 해결책(thought)**이다. 루트 노드는 문제 자체고, 각 분기는 그 다음 단계의 가능한 생각들이다. 모델은 이 트리를 탐색하면서 가장 유망한 경로를 찾는다.

실제 구현은 네 단계로 이루어진다. 먼저 Thought Decomposition: 문제를 중간 단계로 분해한다. 다음으로 Thought Generation: 각 단계에서 가능한 여러 생각을 생성한다. 그리고 State Evaluation: 각 생각이 얼마나 유망한지 LLM 자체로 점수를 매긴다. 마지막으로 Search Algorithm: BFS(너비 우선 탐색)나 DFS(깊이 우선 탐색)으로 트리를 탐색한다. 이 과정에서 LLM이 '생성자'와 '평가자' 두 역할을 동시에 한다는 점이 흥미롭다.

예를 들어, 창의적인 글쓰기 과제를 생각해보자. CoT는 "첫 문단 → 둘째 문단 → 셋째 문단" 하나의 경로를 직진한다. ToT는 "첫 문단 후보 A, B, C를 생성하고, 각각을 평가해서 가장 좋은 것을 선택한 뒤, 다시 둘째 문단 후보들을 생성하는" 방식으로 진행한다. 탐색 공간이 지수적으로 넓어지지만, 그만큼 더 창의적이고 최적화된 결과가 나온다.

2-4. ReAct — 생각과 행동을 엮는 프레임워크

여기서부터 에이전트의 영역과 맞닿는다. 앞서 말한 LLM의 세 번째 한계인 '자율성 부재'를 해결하는 핵심 프롬프팅 패턴이 ReAct다. Yao et al. (2022)의 논문 "ReAct: Synergizing Reasoning and Acting in Language Models"에서 제안됐다. 이름 자체가 Reasoning(추론) + Acting(행동)의 합성어다.

ReAct의 핵심 아이디어는 단순하면서도 강력하다. LLM이 추론(Thought)과 행동(Action)을 번갈아 수행하도록 프롬프트를 구조화한다. 그리고 행동의 결과(Observation)가 다음 추론의 입력으로 들어간다. 이 사이클을 반복하면서 목표에 도달한다.

Thought: 이 질문에 답하려면 먼저 최신 주가를 검색해야 한다.
Action: Search["삼성전자 주가 2025년 3월"]
Observation: 삼성전자 현재 주가는 72,400원이다.
Thought: 주가를 알았으니 이제 작년과 비교해야 한다.
Action: Search["삼성전자 주가 2024년 3월"]
Observation: 2024년 3월 삼성전자 주가는 79,200원이었다.
Thought: 72,400 / 79,200 - 1 = -8.6% 하락했다. 이제 답할 수 있다.
Answer: 삼성전자 주가는 지난 1년간 약 8.6% 하락했습니다.

이 구조에서 LLM은 단순히 텍스트를 생성하는 게 아니라, 외부 도구를 언제 어떻게 사용할지 스스로 결정한다. 이 패턴이 뒤에서 배울 에이전트(Agent)의 근간이 된다. CoT가 "내부 추론"을 구조화했다면, ReAct는 "내부 추론 + 외부 세계 상호작용"을 구조화한다는 점에서 패러다임의 전환을 의미한다.

[노트 기록] ReAct 루프: Thought → Action → Observation → Thought → Action → Observation → ... → Answer

3부. RAG — 외부 지식을 LLM에 연결하다

3-1. 왜 RAG인가 — 환각을 넘어서

LLM이 거짓말을 한다는 것, 즉 환각(Hallucination)을 일으킨다는 것은 앞서 이야기했다. 이를 해결하는 가장 직관적인 접근이 **"모를 것 같으면 먼저 찾아보고 답하게 하는 것"**이다. 이것이 RAG(Retrieval-Augmented Generation)의 본질이다. Lewis et al. (2020)의 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"에서 처음 제안된 이 방법은 현재 실무에서 가장 널리 쓰이는 LLM 강화 기법 중 하나다.

RAG는 크게 세 단계로 이루어진다. Retrieval(검색): 사용자의 질문과 관련된 문서를 외부 데이터베이스에서 찾아온다. Augmentation(증강): 찾아온 문서를 원래 질문과 함께 프롬프트에 포함시킨다. Generation(생성): 증강된 프롬프트를 바탕으로 LLM이 답변을 생성한다. 이 과정에서 모델은 "훈련 때 배운 것"이 아니라 "지금 방금 검색해서 가져온 실제 정보"를 근거로 답변한다.

3-2. 벡터 임베딩 — 의미를 숫자로 변환하는 마법

여기서 핵심 기술적 개념이 등장한다. "관련된 문서를 찾는다"는 게 어떻게 작동하는가? 단순한 키워드 검색(예: 구글에서 단어를 검색하는 방식)으로는 의미적으로 비슷하지만 표현이 다른 문서를 찾기 어렵다. "강아지가 짖는다"와 "개가 소리를 낸다"는 표현은 달라도 의미는 비슷하다. 이 '의미적 유사성'을 계산하기 위해 **벡터 임베딩(Vector Embedding)**이 필요하다.

벡터 임베딩은 텍스트(단어, 문장, 문서)를 고차원 실수 벡터로 변환하는 과정이다. 2단계에서 Transformer를 배울 때 잠깐 나왔던 개념이다. BERT나 text-embedding-ada-002 같은 임베딩 모델은 텍스트를 512차원, 1536차원 같은 고차원 벡터로 변환한다. 이 벡터들은 의미가 비슷한 텍스트일수록 벡터 공간에서 가까이 위치하도록 훈련된다.

수학적으로, 두 벡터의 유사도는 **코사인 유사도(Cosine Similarity)**로 측정한다. $cos (θ) = \frac{a \cdot b}{∣ a ∣∣ b ∣}$ . 두 벡터가 같은 방향을 향할수록 코사인 값은 1에 가까워지고, 직교(무관)하면 0, 반대 방향이면 -1이 된다. "강아지"와 "개"의 임베딩 벡터는 코사인 유사도가 0.9 이상으로 높게 나타나고, "강아지"와 "양자역학"은 낮게 나온다.

[노트 기록] 임베딩과 유사도:

텍스트 → 임베딩 모델 → 고차원 실수 벡터 (예: [0.12, -0.87, 0.34, ...])
두 텍스트의 의미적 유사도 = 코사인 유사도 = $\frac{a \cdot b}{∣ a ∣∣ b ∣}$

3-3. 벡터 데이터베이스 — 의미를 저장하고 검색하는 창고

수백만 개의 문서를 임베딩 벡터로 변환했다면, 이것들을 어떻게 저장하고 빠르게 검색하는가? 일반적인 관계형 데이터베이스(MySQL, PostgreSQL)는 고차원 벡터 유사도 검색에 최적화되어 있지 않다. 여기서 **벡터 데이터베이스(Vector Database)**가 필요해진다. FAISS(Facebook AI Similarity Search), Pinecone, Chroma, Weaviate 같은 것들이 대표적이다.

벡터 DB의 핵심 기능은 ANN(Approximate Nearest Neighbor) 검색이다. 정확한 최근접 이웃을 찾으려면 모든 벡터와 비교해야 하는데, 이는 벡터 수가 많아지면 너무 느리다. ANN 알고리즘(예: HNSW - Hierarchical Navigable Small World)은 약간의 정확도를 희생하는 대신 대규모 데이터에서 매우 빠르게 근사적인 최근접 이웃을 찾는다. 실무에서는 이 "약간의 부정확함"이 사실상 문제가 되지 않는다.

RAG 파이프라인의 전체 흐름을 이제 그릴 수 있다. 오프라인(인덱싱) 단계: 외부 문서들(PDF, 웹페이지, DB 등)을 적절한 크기로 잘라(Chunking), 임베딩 모델로 벡터화하고, 벡터 DB에 저장한다. 온라인(쿼리) 단계: 사용자 질문이 들어오면, 그 질문도 임베딩 벡터로 변환하고, 벡터 DB에서 가장 유사한 청크들을 검색하고(Retrieval), 검색된 청크들을 프롬프트에 붙여서 LLM에 보낸다.

3-4. 실무적 RAG 최적화 — Chunking과 Reranking

단순히 "문서 잘라서 벡터 DB에 넣으면 끝"이 아니다. 실제 성능에 직결되는 두 가지 핵심 기술이 있다.

첫 번째는 Chunking 전략이다. 문서를 어떻게 자르느냐가 검색 품질을 결정한다. 너무 크게 자르면 하나의 청크에 너무 많은 정보가 담겨서 임베딩이 뭉뚱그려지고, 너무 작게 자르면 맥락이 끊긴다. 고정 크기 청킹(Fixed-size Chunking), 문장/단락 단위 청킹, 재귀적 청킹(Recursive Character Text Splitter), 의미 단위 청킹(Semantic Chunking) 등 다양한 전략이 있다. 실무에서는 보통 청크 사이에 일정 비율의 **오버랩(Overlap)**을 두어 맥락이 끊기지 않게 한다.

두 번째는 Reranking이다. 벡터 유사도 검색은 빠르지만 완벽하지 않다. 검색된 상위 K개 문서 중 실제로 가장 관련 있는 것이 순위가 낮을 수 있다. Reranking은 Cross-encoder 모델(쿼리와 문서를 함께 입력으로 넣어 관련도를 정밀하게 계산하는 모델)을 사용해서 검색 결과를 다시 정렬한다. Bi-encoder(임베딩)로 빠르게 100개를 찾고, Cross-encoder로 다시 정밀하게 상위 5개를 선별하는 Two-stage Retrieval 패턴이 현재 실무의 표준이다.

4부. Agentic AI — 스스로 생각하고 행동하는 AI

4-1. 에이전트란 무엇인가

**에이전트(Agent)**는 AI 분야에서 오래된 개념이다. 고전적 정의는 "환경(Environment)을 인식(Perceive)하고, 목표(Goal)를 향해 행동(Act)하는 자율적 시스템"이다. LLM 기반 에이전트는 여기서 한발 더 나아간다. LLM이 두뇌(Brain) 역할을 하면서, 외부 도구들을 사용해 실세계와 상호작용하며 복잡한 목표를 달성한다.

LLM 에이전트의 네 가지 핵심 구성요소를 기억하자.

Planning(계획): CoT/ToT/ReAct 등의 방법으로 작업을 분해하고 계획
Memory(기억): 단기 기억(대화 맥락, Context Window)과 장기 기억(외부 DB, 벡터 DB)
Tools(도구): 웹 검색, 코드 실행, API 호출, 파일 조작 등 외부 도구
Action(행동): 계획에 따라 도구를 호출하고 결과를 다음 단계에 반영

이 구성요소들이 ReAct 루프 안에서 연결된다. "생각 → 어떤 도구를 써야 할까 → 도구 실행 → 결과 관찰 → 다시 생각 → ..." 이 반복이 에이전트의 핵심 실행 패턴이다.

[노트 기록] 에이전트 = Brain(LLM) + Memory + Tools + Action Loop

4-2. LangChain — 에이전트 구축의 기초 프레임워크

LangChain은 현재 가장 널리 쓰이는 LLM 애플리케이션 프레임워크다. "체인(Chain)"이라는 이름처럼, 여러 구성요소를 연결(chain)하여 복잡한 파이프라인을 만든다. LangChain의 핵심 추상화를 이해하면 RAG와 에이전트 구현이 훨씬 수월해진다.

LangChain의 주요 구성요소는 다음과 같다. LLMs/Chat Models: OpenAI, Anthropic, HuggingFace 등 다양한 모델을 통일된 인터페이스로 사용. Chains: 여러 컴포넌트를 직렬로 연결(예: 프롬프트 → LLM → 출력 파서). Agents: ReAct 같은 루프를 구현하며 도구를 자율 선택. Tools: 에이전트가 사용할 수 있는 함수들(검색, 계산, 코드 실행 등). Memory: 대화 기록 관리(Buffer, Summary, Vector Memory 등). Retrievers: 벡터 DB와 연동한 문서 검색.

LangChain의 최신 버전(LangChain Expression Language, LCEL)은 파이프(|) 연산자로 체인을 선언적으로 구성한다. prompt | llm | output_parser 같은 방식으로, Unix 파이프라인처럼 각 단계의 출력이 다음 단계의 입력이 된다. 이 패턴은 함수형 프로그래밍의 **함수 합성(Function Composition)**과 동일한 개념이다.

4-3. AutoGen과 CrewAI — 다중 에이전트 협업

단일 에이전트만으로는 한계가 있다. 복잡한 문제는 여러 전문 에이전트가 협력해야 해결된다. AutoGen(Microsoft Research, Wu et al., 2023)과 CrewAI는 이 멀티-에이전트(Multi-Agent) 시스템을 구축하는 프레임워크다.

AutoGen의 핵심은 **에이전트 간 대화(Agent Conversation)**다. 여러 에이전트가 서로 메시지를 주고받으며 협력한다. 예를 들어, "코드 작성 에이전트"가 코드를 쓰면 "코드 리뷰 에이전트"가 검토하고, "디버그 에이전트"가 오류를 수정하는 식이다. 인간도 그룹 채팅에 참여할 수 있어 인간-AI 협업 시스템도 구현할 수 있다.

CrewAI는 조금 더 구조화된 방식을 취한다. 역할(Role), 목표(Goal), 배경(Backstory)을 가진 에이전트들이 팀(Crew)을 이뤄 순차적 또는 병렬로 작업(Task)을 처리한다. 실제 회사의 팀 구조를 모방한 셈이다. 연구 에이전트가 정보를 모으고, 분석 에이전트가 가공하고, 작성 에이전트가 최종 보고서를 쓰는 파이프라인을 코드 몇 줄로 구현할 수 있다.

두 프레임워크의 차이를 한 줄로 요약하면: AutoGen은 자유도 높은 대화형 협업, CrewAI는 구조화된 역할 기반 협업이다. 어떤 문제냐에 따라 선택이 달라진다.

[노트 기록] 에이전트 프레임워크 비교:

LangChain: 단일 에이전트, 범용적, RAG/체인 구성에 강점
AutoGen: 에이전트 간 대화 기반, 자유도 높음, 코딩/디버깅 태스크에 강점
CrewAI: 역할 기반 팀 구조, 워크플로우 명확, 비즈니스 자동화에 강점

5부. 프로젝트 — 40분 실전 과제

지금까지 배운 내용을 실제로 적용해보자. 세 가지 프로젝트를 순서대로 풀어보되, 답은 스스로 찾아야 한다. 막히는 부분은 위의 이론 내용을 다시 읽거나, 논문과 공식 문서를 직접 찾아보는 것이 진짜 학습이다.

프로젝트 1: 프롬프트 설계 챌린지 (약 15분)

맥락: 당신은 AI 스타트업의 신입 프롬프트 엔지니어다. 아래 문제들을 CoT, ToT, ReAct 개념을 활용해 최적화된 프롬프트로 해결해야 한다. 프롬프트 텍스트 자체를 직접 작성하라. 코드가 아닌 "LLM에게 줄 프롬프트 문장"을 설계하는 것이다.

문제 1-A: 다음 추론 문제를 풀기 위한 Zero-shot CoT 프롬프트를 설계하라.

상황: 창고에 빨간 박스 4개, 파란 박스 7개, 초록 박스 3개가 있다. 파란 박스를 모두 트럭에 싣고, 빨간 박스의 절반을 다른 창고로 옮겼다. 그 후 초록 박스가 2배로 늘어났다. 현재 창고에 있는 박스는 총 몇 개인가?

이 문제를 LLM이 틀리지 않게 풀도록 프롬프트를 설계할 때, 어떤 문장을 앞이나 뒤에 추가해야 하는가? 그리고 왜 그 문장이 도움이 되는지 2단계에서 배운 토큰 예측 메커니즘과 연결해서 설명하라.

문제 1-B: 아래와 같은 창의적 글쓰기 과제에서 ToT 방식이 CoT보다 유리한 이유를 설명하고, ToT 방식으로 LLM을 유도할 수 있는 프롬프트 구조(뼈대)를 직접 설계하라.

과제: "2050년 서울을 배경으로 하는 SF 단편소설의 도입부 3가지 버전을 쓰고, 각 버전의 강점과 약점을 평가해서 가장 좋은 것을 추천하라."

프롬프트 안에 어떤 지시사항을 어떤 순서로 넣어야 하는지, 왜 그 순서여야 하는지 이유를 함께 써라.

문제 1-C: ReAct 패턴을 이해했다면, 아래 시나리오에서 Thought → Action → Observation 사이클이 최소 2회 이상 반복되어야 하는 이유를 설명하고, 각 사이클에서 어떤 Action이 필요한지 상세히 설계하라.

시나리오: "우리 회사 경쟁사인 A사가 최근에 새 제품을 출시했다는 소식을 들었다. 이 제품의 주요 기능, 가격, 시장 반응을 조사해서 요약 보고서를 작성하라."

프로젝트 2: RAG 시스템 아키텍처 설계 (약 15분)

맥락: 당신은 AI 컨설턴트로서, 대형 법률 회사로부터 다음 의뢰를 받았다. 회사에는 20년치 판례 문서(약 50만 페이지 분량의 PDF)가 있으며, 변호사들이 특정 사건 관련 판례를 질문하면 즉시 답변해주는 AI 시스템을 원한다. 실제 코드를 작성하는 것이 아니라, 시스템 아키텍처와 설계 결정을 문서화하는 것이 목표다.

문제 2-A (Chunking 전략): 50만 페이지의 법률 판례 PDF를 어떻게 청킹할 것인가? 다음 세 가지 전략 중 어느 것을 선택하고, 왜 선택했는지 법률 문서의 특성과 연결해서 설명하라.

고정 크기 청킹 (500 토큰 단위, 50 토큰 오버랩)
단락/섹션 단위 청킹 (제목, 날짜, 판결문 구조에 따라 분할)
의미 단위 청킹 (임베딩 유사도가 급변하는 지점에서 분할)

단순히 하나를 선택하는 것에서 그치지 말고, **이 세 전략의 트레이드오프(trade-off)**를 표나 설명으로 정리하라. 특히 청크 크기가 너무 크거나 작을 때 각각 어떤 문제가 생기는지, 위에서 배운 임베딩과 코사인 유사도 개념을 이용해서 설명하라.

문제 2-B (Two-stage Retrieval): 변호사가 "계약 해지 후 손해배상 범위에 관한 판례"를 물어봤을 때, Two-stage Retrieval 파이프라인이 어떻게 작동하는지 다음 항목을 포함해서 단계별로 서술하라.

1단계(Bi-encoder)에서 어떤 쿼리가 벡터 DB로 들어가는가
1단계 결과에서 어떤 문서들이 나올 수 있는가 (예시 포함)
2단계(Cross-encoder Reranking)에서 어떤 기준으로 재정렬하는가
최종적으로 LLM에 넘겨줄 프롬프트를 어떻게 구성하는가

문제 2-C (평가): 완성된 RAG 시스템이 잘 작동하는지 어떻게 평가할 것인가? 단순히 "답변이 맞다/틀리다"보다 더 정교한 평가 지표를 3가지 이상 제안하고, 각각의 의미를 설명하라. (힌트: Faithfulness, Relevance, Completeness 같은 개념을 검색해보라. 단, 그냥 복사하지 말고 법률 판례 검색 시스템에 맞게 재해석하라.)

프로젝트 3: 멀티 에이전트 시스템 설계 (약 10분)

맥락: 투자 회사에서 "AI 주식 분석 멀티 에이전트 시스템"을 만들어달라는 의뢰가 왔다. 사용자가 특정 회사 이름을 입력하면, 뉴스 분석, 재무제표 분석, 경쟁사 비교를 자동으로 수행하고 투자 의견을 제공하는 시스템이다. 코드 없이 에이전트 아키텍처를 다이어그램(텍스트로도 OK)과 설명으로 설계하라.

문제 3-A (역할 설계): 이 시스템에 필요한 에이전트를 최소 4개 이상 설계하라. 각 에이전트에 대해 다음을 정의하라.

이름과 역할: 이 에이전트가 담당하는 구체적인 책임
사용할 도구(Tools): 어떤 외부 도구/API를 사용하는가
입력과 출력: 무엇을 받아서 무엇을 돌려주는가
실패 시나리오: 이 에이전트가 실패하면 전체 시스템에 어떤 영향이 있는가

문제 3-B (오케스트레이션 전략): 위에서 설계한 에이전트들이 어떤 순서로, 어떤 방식으로 협력할 것인지 설계하라. 다음 질문에 답하라.

어떤 에이전트는 병렬로 실행해도 되고, 어떤 에이전트는 반드시 순서를 지켜야 하는가? 그 이유는?
만약 중간 에이전트가 오류를 반환하거나 신뢰할 수 없는 데이터를 가져온다면, 시스템은 어떻게 처리해야 하는가?
AutoGen 방식과 CrewAI 방식 중 이 시스템에 더 적합한 것은 무엇인가? 위에서 배운 두 프레임워크의 특성을 근거로 선택하라.

평가 기준 (스스로 체크해보기)

과제를 마쳤다면, 제출 전 아래 기준으로 스스로 점검하라. 이것이 실제 4단계 평가에서 사용될 기준이기도 하다.

프롬프트 효과성 (40점): 설계한 프롬프트가 왜 효과적인지를 이론적 근거(토큰 예측, 훈련 데이터 패턴, 중간 추론 단계 등)와 연결해서 설명했는가? CoT/ToT/ReAct의 적용이 적재적소에 이루어졌는가? 단순히 "~라고 하면 잘 나와요"가 아니라 메커니즘 수준에서 설명했는가?

에이전트 자율성 (40점): RAG 파이프라인과 에이전트 설계가 실제로 작동할 수 있는 수준인가? 각 컴포넌트의 입출력이 명확하게 정의됐는가? 실패 케이스와 엣지 케이스를 고려했는가? 단순한 해피 패스(happy path)만 설계하면 감점이다.

시스템 데모 (20점): 전체 시스템의 흐름을 처음부터 끝까지 하나의 시나리오로 설명할 수 있는가? 각 프로젝트에서 설계한 내용이 서로 연결되는가? (힌트: 잘 설계된 RAG는 에이전트의 도구가 된다. 잘 설계된 에이전트는 ReAct 루프를 핵심으로 돌린다. 이 연결이 명시적으로 드러나야 한다.)

지금 이 순간, 너는 단순히 AI를 사용하는 수준을 넘어 AI가 왜, 어떻게 작동하는지를 설계하는 관점으로 올라서고 있다. 이 단계의 기술들 — CoT, RAG, 에이전트 — 은 2025년 현재 AI 산업에서 가장 뜨겁게 활용되는 것들이다. 프로젝트에서 막힌다면, 그 막힘 자체가 배움이다. 어느 개념이 흐릿한지를 확인하고, 해당 섹션을 다시 읽어라. 참고 논문들(Wei et al. 2022, Yao et al. 2022, 2023, Lewis et al. 2020)을 직접 찾아 abstract와 introduction만이라도 읽어보는 것을 강력히 권한다. 논문이 어렵게 느껴지는 것이 당연하지만, 그게 지금 네가 서 있어야 할 자리다.

인공지능 및 생성형 AI