Field Log · Entry
RAG Agent 공부 순서: 토큰부터 Harness까지 한 장으로 보기 (1/10)
오늘의 결론
- RAG Agent는 LLM 하나가 아니라 검색 시스템, 생성 모델, 제어 루프, 평가 장치를 묶은 소프트웨어입니다.
- 공부 순서는 제품 이름이 아니라 데이터가 흐르는 순서로 잡아야 합니다.
- 첫날 10편은 텍스트가 답변으로 변하는 최소 경로를 완성합니다.
- 이후에는 chunking, sparse/dense/hybrid retrieval, reranking, evaluation, agent와 harness를 깊게 파고듭니다.
RAG를 만들다 보면 낯선 단어가 한꺼번에 쏟아집니다. embedding, cosine similarity, chunk, reranker, context window, tool calling, memory, evaluation…. 하나씩 검색해도 서로 어떻게 연결되는지 보이지 않으면 금방 지칩니다.
이 글의 목적은 용어를 많이 알려 주는 것이 아닙니다. 사용자의 질문 한 줄이 근거 있는 답 한 줄로 바뀌는 동안 어떤 부품을 통과하는지 먼저 보여 주는 것입니다. 앞으로의 모든 글은 이 지도 위에 위치를 표시하며 읽을 수 있습니다.
그림 1. RAG Agent는 모델 호출 하나가 아니라 데이터, 검색, 생성, 제어, 평가, 운영 계층이 이어진 시스템이다.
RAG와 RAG Agent는 어디가 다른가
가장 단순한 RAG는 고정된 파이프라인입니다.
질문 → 관련 문서 검색 → 질문과 문서를 LLM에 전달 → 답변반면 RAG Agent는 현재 상태를 보고 다음 행동을 고릅니다.
질문
→ 질문을 그대로 검색할까, 여러 검색어로 분해할까?
→ 검색 결과가 충분한가?
→ 다른 도구나 DB를 호출해야 하는가?
→ 답을 만들 수 있는가, 추가 검색해야 하는가?
→ 인용 근거가 실제 주장을 뒷받침하는가?즉 RAG가 검색을 붙인 생성 파이프라인이라면, RAG Agent는 검색을 포함한 여러 행동을 상태에 따라 반복·선택하는 제어 시스템입니다. 그래서 LLM API 사용법만 알아서는 운영 가능한 Agent를 만들기 어렵습니다.
질문 하나가 통과하는 여섯 계층
예시 질문을 하나 두겠습니다.
“장비 X에서 E17 알람이 발생했을 때 점검 순서는?”
이 질문은 다음 계층을 통과합니다.
| 계층 | 하는 일 | 실패하면 보이는 증상 |
|---|---|---|
| 1. 데이터 | 매뉴얼을 파싱하고 검색 가능한 단위로 자름 | 표와 제목이 사라지고 문맥이 끊김 |
| 2. 검색 | 질문과 관련된 후보 문서를 찾고 순위를 매김 | 정답 문서가 context에 들어오지 않음 |
| 3. 생성 | 질문과 근거를 읽고 답을 구성함 | 근거는 맞는데 답이 빠지거나 왜곡됨 |
| 4. Agent | 검색어 수정, 재검색, 도구 선택을 결정함 | 불필요한 루프 또는 너무 이른 종료 |
| 5. 평가 | 검색과 답을 각각 측정함 | “답이 별로다” 외에 원인을 모름 |
| 6. Harness | 권한, 예산, 로그, 재시도, 중단 조건을 강제함 | 데모는 되지만 운영 중 통제 불가 |
여기서 중요한 습관이 하나 있습니다. 답이 틀렸을 때 곧바로 “LLM이 나쁘다”고 결론 내리지 않는 것입니다. 정답 청크가 아예 검색되지 않았다면 생성 모델을 바꿔도 해결되지 않습니다. 검색 결과에는 정답이 있었지만 답변이 왜곡됐다면 그때 생성 프롬프트나 모델을 봐야 합니다.
왜 토큰과 Transformer부터 공부하는가
RAG를 빨리 만들고 싶다면 바로 vector DB 튜토리얼을 따라 하고 싶어집니다. 하지만 기초가 없으면 다음 질문에 답할 수 없습니다.
- chunk를 왜 문자 수가 아니라 토큰 수로 잘라야 할까?
- embedding 차원이 클수록 항상 검색이 좋아질까?
- cosine similarity 점수 0.8은 정말 “80% 정확”이라는 뜻일까?
- BERT 계열 encoder와 GPT 계열 generator는 왜 역할이 다를까?
- context가 길어지면 왜 비용과 지연 시간이 커질까?
- KV cache는 대화 기억인가, 연산 캐시인가?
이 질문들은 모두 RAG의 성능과 비용을 결정합니다. 그래서 오늘은 라이브러리보다 아래 10개의 기초 개념을 먼저 연결합니다.
오늘 읽을 10편
| 순서 | 글 | 읽고 나면 답할 수 있는 질문 |
|---|---|---|
| 1 | 전체 지도 | RAG Agent를 어떤 계층으로 분해할까? |
| 2 | 토큰화 | 모델이 보는 입력 단위와 context 예산은 무엇인가? |
| 3 | 벡터와 임베딩 | 의미를 좌표로 바꾸고 유사도를 재는 이유는? |
| 4 | 신경망 학습 | logit, softmax, loss, gradient는 어떻게 이어지는가? |
| 5 | 언어모델 | “다음 토큰 예측”으로 어떻게 문장을 생성하는가? |
| 6 | Attention | Q·K·V는 어떤 정보를 섞는가? |
| 7 | Transformer | attention 외에 residual, normalization, FFN은 왜 필요한가? |
| 8 | BERT와 GPT | encoder와 decoder를 어디에 써야 하는가? |
| 9 | LLM 추론 | prefill, decode, sampling, KV cache는 무엇인가? |
| 10 | 첫 RAG | ingestion부터 답변까지 최소 파이프라인을 어떻게 조립하는가? |
오늘의 10편이 끝나면 “작동하는 RAG”의 전체 경로를 설명할 수 있습니다. 다음 묶음부터는 각 병목을 분리해 chunking, BM25, dense retrieval, hybrid search, reranker와 평가로 내려갑니다.
앞으로의 전체 커리큘럼
긴 학습 과정은 다음 7단계로 진행합니다.
- 수학과 모델 기초: 벡터, 확률, 미분, neural network, language modeling
- Transformer와 LLM: attention, encoder/decoder, 학습, 정렬, 추론, serving
- Retrieval: chunking, BM25, embedding, ANN, hybrid, reranking, query transformation
- RAG 설계: context 조립, 인용, structured output, GraphRAG, RAPTOR, multimodal
- 평가와 관측: golden set, Recall@k, MRR, nDCG, faithfulness, latency, cost, tracing
- Agent: tool calling, state, planning, memory, reflection, multi-agent 판단 기준
- Harness와 운영: 권한, 예산, 실패 복구, validation loop, 보안, 배포와 실험
새 논문은 이 기반 위에 얹습니다. 예를 들어 Agentic RAG 논문을 읽을 때도 “검색 전략을 상태에 따라 바꾸는 제어 계층”이라고 위치를 잡으면, 새로운 이름에 압도되지 않습니다.
학습할 때 지킬 세 가지 규칙
1. 용어를 데이터 타입으로 번역한다
“embedding”을 멋진 AI 표현이라고 외우지 말고 실수 배열이라고 번역합니다. “retriever”는 질문을 받아 문서 ID와 점수 목록을 반환하는 함수로 봅니다. 이렇게 바꾸면 구현과 디버깅이 쉬워집니다.
2. 검색과 생성을 따로 평가한다
최종 답변 정확도 하나만 보면 원인을 찾을 수 없습니다. 최소한 아래 둘을 분리합니다.
- 검색 평가: 정답 근거가 top-k 안에 들어왔는가?
- 생성 평가: 주장이 전달된 근거에 의해 지지되는가?
3. 작은 수치 예제를 손으로 계산한다
2차원 벡터의 cosine, 세 토큰의 softmax, 네 토큰의 attention 행렬을 손으로 한 번 계산하면 라이브러리 옵션을 훨씬 덜 오해합니다. 이 시리즈는 가능한 한 작은 수치 예제를 넣습니다.
5분 실습: 지금 만든 RAG를 한 줄씩 추적하기
현재 개발 중인 RAG Agent의 질문 하나를 고르고 아래 표를 채워 보세요. 아직 모르는 칸은 비워도 됩니다.
| 확인할 것 | 내 시스템의 값 |
|---|---|
| 원문 형식 | PDF / HTML / Markdown / DB / 기타 |
| chunk 단위와 크기 | |
| embedding 모델과 차원 | |
| 검색 방식과 top-k | |
| reranker 유무 | |
| LLM에 전달된 실제 context | |
| 생성 모델과 sampling 설정 | |
| 실패 시 재검색 조건 | |
| 검색 평가 지표 | |
| 답변 평가 지표 |
빈칸은 부끄러운 부분이 아니라 앞으로 공부할 위치입니다. 이 표를 시리즈가 진행될 때마다 갱신하면 공부와 현재 프로젝트가 분리되지 않습니다.
자주 하는 오해
“RAG는 LLM이 모르는 지식을 학습시키는 방법이다.”
일반적인 RAG는 모델 파라미터를 다시 학습하지 않습니다. 요청 시점에 외부 문서를 찾아 context로 제공합니다. fine-tuning과 목적이 다릅니다.
“Agent를 쓰면 검색 품질이 자동으로 좋아진다.”
Agent는 잘못된 검색기를 여러 번 호출할 수도 있습니다. 기본 retriever와 평가가 먼저 안정적이어야 합니다.
“context window가 크면 retrieval은 필요 없다.”
긴 context도 비용, 지연, 주의 분산, 최신성, 접근 권한, 출처 추적 문제가 있습니다. “모두 넣기”와 “필요한 것 찾기”는 다른 설계입니다.
스스로 확인하기
- RAG와 RAG Agent의 차이를 “반복”과 “상태”라는 단어를 써서 설명할 수 있는가?
- 정답 문서가 검색되지 않은 실패와, 검색됐지만 답이 틀린 실패를 어떻게 구분할 것인가?
- 현재 프로젝트에서 가장 불확실한 계층은 데이터·검색·생성·Agent·평가·Harness 중 어디인가?
다음 글에서는 이 파이프라인의 가장 작은 입력 단위인 토큰과 context window를 다룹니다.