byteforce

CPN 한국어 자습서 · 러닝패스 2 / 4 — Building with the Claude API

RAG

RAG 시작하기

Introducing Retrieval Augmented Generation

수백 페이지짜리 문서에 구체적인 질문을 던지려면, 그 정보를 어떻게든 Claude에게 전달해야 합니다. 방법은 크게 둘 — 문서 전체를 프롬프트에 넣기, 그리고 관련 부분만 찾아 넣기. 두 번째가 바로 RAG(검색 증강 생성)입니다. 이 장에서는 왜 RAG가 필요한지, 그리고 RAG 파이프라인의 큰 그림을 잡습니다.

전체 내레이션영상 나레이션 한국어 번역 (전체)›

Stephen Grider · Anthropic 기술 스태프

어떤 회사의 아주 큰 금융 문서가 있다고 해봅시다. 수백 페이지, 어쩌면 천 페이지가 넘을 수도 있습니다. 그리고 우리는 그 문서에 대해 아주 구체적인 질문을 하고 싶습니다. 예를 들어 "이 회사의 주요 리스크 요인은 무엇인가?" 같은 질문이죠. 이 질문에 답하려면 문서 안의 정보를 어떻게든 Claude에게 줘야 합니다. 크게 두 가지 방법이 있습니다.

첫 번째 방법은 단순합니다. 문서 전체 텍스트를 그냥 프롬프트에 통째로 집어넣고 질문을 던지는 것입니다. 이게 될 수도 있고, 안 될 수도 있습니다. 그런데 이 방식에는 분명한 단점이 세 가지 있습니다.

하나, 모든 모델에는 입력 길이의 하드 리밋(컨텍스트 윈도우)이 있습니다. 문서가 그 한계를 넘으면 프롬프트를 보내는 순간 곧바로 에러가 납니다. 둘, 프롬프트가 길수록 Claude의 정확도가 떨어지는 경향이 있습니다. 정보가 너무 많으면 그 안에서 우리가 정말 무엇을 원하는지 파악하기가 더 어려워지기 때문입니다. 셋, 프롬프트가 길수록 비용이 올라가고 응답도 느려집니다. 사용자 입장에서는 답을 받기까지 오래 기다려야 하니 경험이 나빠집니다.

두 번째 방법이 바로 RAG입니다. 핵심 아이디어는 이렇습니다. 문서 전체를 넣는 대신, 질문과 가장 관련 있는 부분만 골라서 넣자는 것입니다. 이건 두 단계로 나뉩니다.

1단계는 사전처리입니다. 사용자가 아직 아무 질문도 하기 전에, 우리는 큰 문서를 미리 작은 조각들 — 청크(chunk) — 로 쪼개 둡니다. 2단계는 질의 시점입니다. 사용자가 질문을 하면, 그 질문과 가장 관련 있는 청크를 찾아서 그 청크만 프롬프트에 넣고 Claude에게 보냅니다.

이렇게 하면 장점이 많습니다. Claude는 관련 있는 내용에만 집중할 수 있고, 문서가 아무리 크거나 여러 개여도 확장할 수 있으며, 프롬프트가 작으니 더 빠르고 더 저렴합니다.

물론 단점도 있습니다. 우선 시스템이 복잡해집니다. 문서를 미리 처리하고, 관련 청크를 찾는 검색 메커니즘을 만들고, 무엇이 "관련 있다"는 것인지 정의해야 합니다. 또 우리가 고른 청크가 답에 필요한 맥락을 전부 담고 있다는 보장이 없습니다. 게다가 문서를 청크로 쪼개는 방법이 한 가지가 아닙니다 — 길이로 균등하게 자를 수도, 헤더를 기준으로 자를 수도 있죠. 그래서 어떤 방식이 우리 상황에 맞는지 평가가 필요합니다.

이 두 번째 방법이 바로 RAG, 즉 Retrieval Augmented Generation(검색 증강 생성)입니다. 적용하기 전에 우리 use case에 정말 맞는지 단계별로 따져 봐야 한다는 점만 기억하면 됩니다. 다음 장부터는 이 파이프라인을 한 단계씩 직접 구현해 보겠습니다.

이 장에서 배우는 것What you'll learn

약 7분

큰 문서의 정보를 Claude에 주는 두 가지 방법

옵션1 — 전체 텍스트를 프롬프트에: 단점 3가지(길이 한계·정확도↓·비용/지연↑)

옵션2 — RAG: 관련 청크만 찾아 넣기

RAG의 2단계 — 사전처리(청킹)와 질의(검색)

RAG의 장점(집중·확장·저렴)과 단점(복잡도·맥락·청킹 선택)

RAG 파이프라인의 큰 그림: 문서 → 청크 → 검색 → 프롬프트

먼저 짚고 갈 용어

RAG: Retrieval Augmented Generation, 검색 증강 생성. 질문과 관련된 부분만 찾아 프롬프트에 넣어 답을 만드는 방식.
청크 (chunk): 큰 문서를 쪼갠 작은 텍스트 조각. RAG는 문서 전체가 아니라 관련 청크만 모델에 넣는다.
컨텍스트 윈도우: 모델이 한 번에 받을 수 있는 입력의 최대 길이. 이를 넘으면 에러가 난다.
검색 (retrieval): 질문과 가장 관련 있는 청크를 찾아내는 과정. RAG의 R.

문제 — 큰 문서에 구체적 질문

A big document, a specific question

수백 페이지짜리 회사 금융 문서가 있고, 거기에 "이 회사의 주요 리스크 요인은?" 같은 아주 구체적인 질문을 하고 싶다고 해봅시다. 답하려면 문서 속 정보를 어떻게든 Claude에게 전달해야 합니다. 방법은 크게 두 가지입니다.

핵심 질문

문서가 클수록 "전부 넣을까, 일부만 넣을까"의 선택이 중요해집니다. 이 장은 그 선택을 다룹니다.

두 가지 방법, 나란히

Two options compared

옵션 1은 문서 전체를 프롬프트에 통째로 넣는 것이고, 옵션 2는 질문과 관련된 부분만 골라 넣는 것입니다. 카드를 눌러 각 방식의 장단점을 펼쳐 보세요.

두 방법 비교 · 카드를 눌러 장단점 펼치기

옵션 1전체 텍스트를 프롬프트에

✓구현이 가장 단순. 문서를 통째로 붙여 넣고 질문만 하면 끝.

✗길이 하드 리밋. 컨텍스트 윈도우를 넘으면 보내는 순간 에러.

✗정확도 저하. 정보가 많을수록 의도를 파악하기 어려워 답이 흐려짐.

✗비용·지연 증가. 프롬프트가 길수록 더 비싸고 더 느림 → UX 부담.

▶ 짧은 문서엔 충분하지만, 크고 많아지면 무너집니다.

옵션 2관련 청크만 찾아 넣기 (RAG)

✓질문과 관련된 청크만 골라 넣어 Claude가 집중.

✓확장성. 문서가 크거나 여러 개여도 검색으로 감당.

✓작은 프롬프트. 더 빠르고 더 저렴.

✕복잡도. 사전처리·검색 메커니즘·"관련성" 정의가 필요.

✕고른 청크가 필요한 맥락을 다 담는다는 보장이 없음.

✕청킹 방법이 여러 가지 → 평가가 필요.

▶ 이 방식이 바로 RAG입니다.

옵션 2(RAG)는 공짜가 아닙니다 — 복잡도를 떠안는 대신 대용량·다문서·저비용을 얻습니다. 적용 전 우리 use case에 맞는지 따져야 합니다.

옵션 2가 곧 RAG

Option 2 is RAG

관련 청크만 찾아 넣는 두 번째 방법이 바로 RAG(Retrieval Augmented Generation, 검색 증강 생성)입니다. RAG는 두 단계로 동작합니다.

RAG의 두 단계

1단계 · 사전처리(질문 전): 큰 문서를 미리 작은 청크로 쪼개 둡니다.
2단계 · 질의(질문 시): 질문과 가장 관련 있는 청크를 찾아 그 청크만 프롬프트에 넣고 Claude에 보냅니다.

RAG 파이프라인 · 큰 그림

원본 문서

수백 페이지의 큰 문서

→

청킹

작은 청크들로 쪼갬
(사전처리)

→

정리 & 점검

Recap & check

핵심 정리

큰 문서의 정보를 Claude에 주는 두 방법 — 전체 텍스트 vs 관련 청크만(RAG).
옵션 1의 단점: 길이 하드 리밋, 정보 많을수록 정확도↓, 비용·지연↑.
RAG는 사전처리(청킹) + 질의(검색)의 두 단계.
장점: 집중·확장·저렴. 단점: 복잡도·맥락 보장 없음·청킹 선택의 평가 필요.

Q1RAG에서 "R"이 뜻하는 것은?

Q2문서 전체를 프롬프트에 넣는 방식의 단점이 아닌 것은?

Q3RAG의 두 단계를 옳게 묶은 것은?

다음 장

RAG의 큰 그림을 잡았습니다. 이제 파이프라인의 첫 단계 — 문서를 작은 청크로 쪼개는 청킹을 직접 구현합니다. → 텍스트 청킹 전략