대부분의 AI 에이전트가 프로덕션에 도달하기 전에 죽는 단 하나의 문제가 있습니다.
저장해두세요 :)
모델이 당신의 데이터를 모릅니다.
당신 회사의 제품을 모릅니다. 문서를 모릅니다. 고객 이력을 모릅니다. 학습 데이터에 없는 것은 아무것도 모릅니다.
대부분의 비즈니스 애플리케이션에서 가치는 전적으로 당신의 데이터에 있습니다. 인터넷의 데이터가 아닙니다. 당신의 데이터입니다.
RAG(검색 증강 생성)가 이걸 해결합니다. RAG는 모든 AI 모델에 문서, 데이터베이스, 지식 베이스, 위키, 전사 스크립트 등 특정 데이터에 접근할 수 있게 해주며, 해당 데이터를 진실의 원천으로 삼아 질문에 답하고 작업을 완료할 수 있게 합니다.
RAG 없이는 당신의 AI 어시스턴트는 잘 읽은 낯선 사람일 뿐입니다. RAG와 함께라면, 회사가 만든 모든 문서를 읽은 동료가 됩니다.
이 코스를 통해 RAG를 기초부터 배우게 됩니다. 끝까지 하면, 인용과 함께 정확하게 당신의 데이터로 답변하는 AI 에이전트를 구축할 수 있습니다.
RAG가 실제로 하는 일 (쉬운 설명)
Claude에게 이렇게 물었다고 상상해보세요: “기업 고객을 위한 환불 정책은 무엇인가요?”
RAG 없이는 Claude가 환불 정책을 모릅니다. “모릅니다”라고 하거나, 그럴듯하지만 틀린 환각(hallucination)을 내놓을 것입니다.
RAG가 있으면 애플리케이션이 다음을 수행합니다:
1단계: 질문을 의미를 담은 수학적 표현(임베딩)으로 변환합니다. 2단계: 문서 컬렉션을 검색하여 질문과 가장 관련 있는 청크를 찾습니다 — 환불 정책 문서, 기업 서비스 약관, 고객 지원 가이드라인 등. 3단계: 해당 관련 청크들을 질문과 함께 Claude에게 전달합니다. 4단계: Claude가 관련 문서를 읽고 해당 문서가 말하는 바에 기초해 질문에 답변합니다.
결과: 실제 문서에 기반한 정확하고 근거 있는 답변, 그리고 정보가 정확히 어디서 왔는지 인용할 수 있는 능력.
RAG는 모델을 파인튜닝하지 않습니다. 모델을 전혀 변경하지 않습니다. 생성 시점에 모델이 접근할 수 있는 정보를 변경합니다. 질문하기 전에 누군가에게 참고서를 주는 것과 같다고 생각하세요 — 책을 암기하는 게 아니라 관련 섹션을 찾아보는 것입니다.
RAG 파이프라인: 5단계
모든 RAG 시스템은 동일한 파이프라인을 따릅니다. 이 5단계를 이해하는 것이 RAG 애플리케이션 구축의 기초입니다.
1단계: 문서 수집(Ingestion)
데이터는 다양한 포맷으로 존재합니다 — PDF, 워드 문서, 웹 페이지, 데이터베이스, 스프레드시트, Slack 메시지, 이메일 아카이브. RAG가 이 데이터를 사용하려면 시스템이 처리할 수 있는 포맷으로 변환해야 합니다.
수집 프로세스:
소스 문서를 wherever they live에서 수집합니다. 모든 것을 일반 텍스트로 변환합니다. PDF는 텍스트 추출이 필요하고, 워드 문서는 파싱이 필요하며, 웹 페이지는 HTML 제거가 필요하고, 데이터베이스는 쿼리 내보내기가 필요합니다.
텍스트를 정리합니다. 의미 없는 헤더, 푸터, 내비게이션 요소, 포맷 아티팩트를 제거합니다.
청킹(Chunking) — 전체 RAG 시스템에서 가장 중요한 결정입니다.
문서는 더 작은 청크로 분할해야 합니다. 모델에는 컨텍스트 제한이 있고, 작고 집중된 청크가 전체 문서보다 더 정밀한 검색 결과를 생성하기 때문입니다.
청킹 전략:
- 고정 크기 청크: 500 토큰마다 텍스트 분할. 간단하지만 문장 중간이나 단락 중간에 분할되어 의미가 깨질 수 있음.
- 의미 기반 청크: 자연스러운 경계(단락 나눔, 섹션 헤더, 주제 전환)에서 분할. 의미 보존하지만 불균일한 청크 크기 발생.
- 재귀적 청킹: 먼저 단락에서 분할 시도. 청크가 여전히 너무 크면 문장에서 분할. 그래도 크면 고정 문자 수로 분할. 최고의 범용 접근법.
- 겹침 청크: 각 청크가 이전 청크와 50~100 토큰씩 겹치게 함. 청크 경계에 걸친 정보가 손실되지 않도록 보장. 저장 공간은 약간 증가하지만 검색 품질을 크게 향상.
대부분의 에이전트를 위한 최적 지점: 청크당 300500 토큰, 50100 토큰 겹침. 너무 작으면 컨텍스트 부족, 너무 크면 관련 없는 정보로 희석됨.
2단계: 임베딩(Embedding)
각 청크를 벡터(의미를 담은 수학적 표현)로 변환해야 합니다. 이것을 임베딩이라고 합니다.
유사한 주제를 논하는 두 청크는 완전히 다른 단어를 사용하더라도 유사한 벡터를 가집니다. 임베딩은 키워드뿐만 아니라 의미를 포착합니다.
사용할 임베딩 모델:
대부분의 애플리케이션에서는 OpenAI의 text-embedding-3-small이나 선호하는 제공업체의 동등한 모델을 사용하세요. 저비용으로 고품질 임베딩을 생성합니다.
특수 도메인(의료, 법률, 금융)의 경우 해당 분야 텍스트로 학습된 도메인 특화 임베딩 모델을 고려하세요. 일반 모델보다 도메인 어휘와 관계를 더 잘 이해합니다.
모든 청크를 임베딩하고 원본 텍스트와 함께 저장하세요. 둘 다 필요합니다: 검색용 벡터, 모델 전달용 텍스트.
3단계: 저장(Storage)
청크와 벡터를 저장할 장소가 필요합니다. 이것을 벡터 데이터베이스라고 합니다.
복잡도별 옵션:
- 학습 및 소규모 프로젝트용: Chroma. 오픈소스, 로컬 실행, 간단한 API, 시작하기 완벽.
- 프로덕션 애플리케이션용: Pinecone, Weaviate, Qdrant. 스케일링, 백업, 성능 최적화를 처리하는 관리형 서비스.
- 기존 PostgreSQL 사용자용: pgvector 확장. 별도 시스템 배포 없이 기존 데이터베이스에 벡터 검색 추가.
벡터 데이터베이스는 각 청크를 원본 텍스트, 임베딩 벡터, 메타데이터(소스 문서 이름, 페이지 번호, 섹션, 날짜, 필터링에 유용한 기타 속성)와 함께 레코드로 저장합니다.
4단계: 검색(Retrieval)
사용자가 질문하면 검색 단계에서 데이터베이스에서 가장 관련 있는 청크를 찾습니다.
프로세스:
동일한 임베딩 모델을 사용하여 사용자의 질문을 임베딩합니다. 질문 임베딩과 가장 유사한 청크를 위해 벡터 데이터베이스를 검색합니다. 상위 3~10개 가장 관련 있는 청크를 반환합니다.
검색 품질 개선:
- 하이브리드 검색: 벡터 유사도 검색과 전통적인 키워드 검색 결합. 어떤 질문은 의미적 유사도로, 다른 것은 정확한 키워드 일치로 가장 잘 답변됨. 하이브리드 검색은 두 경우 모두 커버.
- 메타데이터 필터링: 검색 전에 관련 메타데이터로 필터링. 사용자가 특정 제품에 대해 질문하면 해당 제품 문서에서만 검색. 최근 정책을 묻는다면 날짜로 필터링. 더 적고 더 관련 있는 청크가 더 많고 덜 관련 있는 청크보다 낫습니다.
- 리랭킹(Re-ranking): 초기 검색 후, 특정 질문의 컨텍스트에서 각 청크의 관련성을 평가하여 결과를 재정렬하는 2차 패스 실행. Cross-encoder 모델은 리랭킹에 탁월합니다.
5단계: 생성(Generation)
마지막 단계에서는 검색된 청크를 사용자의 질문 및 제공된 문서를 바탕으로 답변하도록 지시하는 시스템 프롬프트와 함께 Claude에게 전달합니다.
시스템 프롬프트 구조:
당신은 제공된 컨텍스트 문서를 바탕으로 질문에 답변하는 유용한 어시스턴트입니다.
규칙:
- 제공된 컨텍스트의 정보에만 기반해 답변하세요
- 컨텍스트에 질문에 완전히 답하기에 충분한 정보가 없다면 명시적으로 그렇게 말하세요
- 주장하는 모든 것에 대해 소스 문서를 인용하세요
- 컨텍스트에 없는 정보를 지어내지 마세요
- 컨텍스트에 상충되는 정보가 있다면, 두 관점을 모두 제시하고 충돌을 언급하세요
컨텍스트 문서:
{retrieved_chunks}
사용자 질문: {question}컨텍스트에서만 답변하라는 명시적 지시는 매우 중요합니다. 이 없이는 Claude가 일반 지식으로 보충할 것이며, 이는 특정 도메인에서는 오래되었거나 틀릴 수 있습니다.
첫 RAG 애플리케이션 구축하기
최소 기능 RAG 시스템입니다. 먼저 이것을 구축하고, 그다음 정교함을 추가하세요.
1단계: 도메인에서 10~20개 문서 수집 — 제품 문서, FAQ, 정책 문서 등 사용자가 질문할 만한 것들.
2단계: 재귀적 청킹으로 문서 청킹 — 400 토큰 청크, 100 토큰 겹침 사용.
3단계: 임베딩 API로 각 청크 임베딩 — 청크와 벡터를 Chroma에 저장.
4단계: 검색 함수 구축 — 쿼리를 임베딩하고, Chroma에서 상위 5개 가장 유사한 청크를 검색하여 반환.
5단계: 생성 함수 구축 — 검색된 청크와 사용자 질문을 받아, 위 시스템 프롬프트로 프롬프트 구성하고 Claude에게 전송.
6단계: 간단한 인터페이스 구축 — 질문용 텍스트 입력창과 답변 표시 영역. Next.js나 간단한 명령줄 인터페이스 사용.
7단계: 답을 아는 20개 질문으로 테스트 — 시스템 답변을 정답과 비교. 실패 지점과 이유 파악.
이 최소 시스템은 주말에 구축할 수 있습니다. 완벽하진 않겠지만 작동할 것이며, 여기서부터 모든 개선은 점진적입니다.
5가지 가장 흔한 RAG 실패 (및 해결법)
실패 1: 잘못된 청크 검색됨
시스템이 질문과 관련 없는 청크를 반환합니다. 답변이 틀리거나 일반적입니다.
해결: 청킹 전략 개선. 청크가 너무 크면 관련 부분 옆에 너무 많은 관련 없는 정보가 포함됨. 너무 작으면 충분한 컨텍스트 부족. 청크 크기 실험. 검색 공간을 좁히기 위해 메타데이터 필터링 추가. 벡터 검색이 놓치는 키워드별 쿼리를 잡기 위해 하이브리드 검색 구현.
실패 2: 검색된 청크에 답 없음
답변이 문서에 존재하지만, 관련 청크가 상위 결과에 없었음.
해결: 검색된 청크 수 증가(5→10 또는 15). 가장 관련 있는 청크를 상단으로 밀어올리기 위해 리랭킹 구현. 청킹 전략이 관련 정보를 두 청크로 분할하는지 확인 — 그렇다면 겹침 증가.
실패 3: 컨텍스트가 있음에도 환각
Claude가 제공된 컨텍스트에 없는 정보를 생성하여 마치 문서에서 온 것처럼 제시함.
해결: 시스템 프롬프트 강화. 매우 명시적으로: “제공된 컨텍스트에서만 답변하세요. 답변이 컨텍스트에 없으면 ‘제공된 문서에서 이 정보를 사용할 수 없습니다’라고 말하세요.” Claude가 각 주장의 근거가 되는 특정 구절을 인용하는 검증 단계 추가.
실패 4: 중복 청크로 결과 왜곡
동일한 정보의 여러 복사본이 검색된 청크에 나타나 다른 관련 청크를 밀어냄.
해결: 수집 시 중복 제거 추가. 각 청크 해시화하고 중복 건너뛰기. 검색 시, 모델로 보내기 전에 근사 중복 결과 확인하고 제거.
실패 5: 오래된 데이터
문서는 변경되지만 벡터 데이터베이스에는 여전히 이전 버전이 포함됨.
해결: 새로고침 파이프라인 구현. 소스 문서가 업데이트되면, 변경된 문서를 재수집하고 재임베딩. 메타데이터로 문서 버전 추적. 자주 변경되는 데이터의 경우 정기적인 새로고침 주기 예약 — 빠르게 변하는 콘텐츠는 일별, 안정적인 콘텐츠는 주별.
MVP에서 프로덕션까지
주말에 만든 RAG 시스템이 작동합니다. 이제 프로덕션급으로 만드는 방법:
인증 추가. 사용자가 계정을 만들고 자신이 볼 권한이 있는 문서만 접근할 수 있어야 합니다. 문서 수준 접근 제어는 모든 비즈니스 애플리케이션에 중요합니다.
소스 인용 추가. 모든 답변에 특정 소스 문서에 대한 링크나 참조 포함. 신뢰 구축하고 사용자가 정보를 검증할 수 있게 함.
피드백 수집 추가. 사용자가 답변을 도움이 됨/안 됨으로 평가하게 함. 이 피드백을 사용해 어떤 문서에 더 나은 청킹이 필요한지, 어떤 질문이 지속적으로 실패하는지, 어디에 새 문서가 필요한지 파악.
모니터링 추가. 쿼리 볼륨, 검색 품질, 답변 품질, 지연 시간, 오류율 추적. 이 데이터가 지속적 개선을 주도합니다.
문서 업데이트 파이프라인 추가. 소스 문서가 변경되면 RAG 시스템이 변경 사항을 자동으로 감지하고, 수정된 문서를 재처리하며 벡터 데이터베이스 업데이트.
결론
RAG는 일반 AI와 당신의 특정 도메인 사이의 다리입니다. 없으면 AI는 일반적인 답변을 합니다. 있으면 AI는 실제 데이터에 근거한 답변을 합니다.
파이프라인은 간단합니다: 문서 수집, 청킹, 임베딩, 벡터 데이터베이스 저장, 각 쿼리에 대해 관련 청크 검색, 해당 청크에서 답변 생성.
이번 주말에 최소 기능 시스템을 구축하세요. 테스트하세요. 실패를 고치세요. 프로덕션 기능을 점진적으로 추가하세요.
모든 비즈니스에는 아무도 읽지 않는 문서에 갇힌 지식이 있습니다. RAG는 그 갇힌 지식을 즉시 정확하게 답변하는 AI 시스템으로 바꿉니다.
지금 RAG 시스템을 구축하는 비즈니스들은 매일 더 많은 문서를 추가함에 따라 복리로 쌓이는 지식 우위를 가질 것입니다.
더 많은 기술 딥다이브, 구축 가이드, AI 아키텍처 분석을 원하시면 @eng_khairallah1 을 팔로우하세요.
유용했다면 공유해주세요, Khairallah ❤️