RAG 직접 만들기: 내 문서를 AI가 답변하게 하는 검색증강 구조 입문

1. RAG는 답을 만들기 전에 자료를 찾는다

LLM은 학습한 일반 지식으로 답할 수 있지만, 내 서비스의 문서·고객센터 자료·사내 정책처럼 별도로 제공한 정보까지 자동으로 알고 있지는 않습니다. RAG는 질문과 관련된 문서를 먼저 검색한 뒤, 그 내용을 답변의 참고자료로 주입하는 구조입니다.

조코헌트의 분야 집계를 보면 AI 도구는 전체 출시 프로덕트의 42%를 차지합니다. 그만큼 AI 기능을 붙이는 것 자체보다, 내 데이터에서 정확한 근거를 찾아 답하게 만드는 설계가 1인 빌더에게 중요한 차별점이 될 수 있습니다.

일반 챗봇과 다른 점

일반 챗봇은 질문을 곧바로 모델에 전달합니다. RAG 챗봇은 질문 → 관련 문서 검색 → 검색 결과와 질문을 함께 전달 → 답변 생성의 단계를 거칩니다. 모델을 다시 학습시키지 않아도 문서를 추가하거나 수정할 수 있다는 점이 핵심입니다.

전체 흐름을 네 단계로 보기

문서를 읽기 좋은 작은 조각으로 나눕니다.
각 조각을 임베딩이라는 숫자 표현으로 변환해 저장합니다.
사용자의 질문도 같은 방식으로 변환하고 가까운 문서 조각을 검색합니다.
검색 결과를 컨텍스트로 넣어 모델이 답변하게 합니다.

처음 구조가 낯설다면 코딩 한 줄 몰라도 시작하는 LLM 앱 만들기에서 챗봇의 기본 요청 흐름부터 확인해도 좋습니다.

2. 검색 품질은 문서를 나누는 순간 결정된다

RAG를 처음 만들 때 모델 선택부터 고민하기 쉽지만, 실제로는 어떤 단위로 문서를 저장하느냐가 검색 결과에 큰 영향을 줍니다.

청킹은 문맥이 끊기지 않는 단위로

문단을 무조건 같은 길이로 자르면 제목과 설명이 분리되거나, 조건과 예외 조항이 서로 다른 조각에 들어갈 수 있습니다. 먼저 제목·소제목·목록을 기준으로 나누고, 너무 긴 부분만 추가로 쪼개는 방식이 다루기 쉽습니다.

조각 하나만 읽어도 주제를 알 수 있도록 문서 제목이나 상위 섹션을 함께 붙여 저장하세요. 조각 사이에 약간의 겹침을 두는 방법도 있지만, 겹침이 지나치면 검색 결과에 비슷한 내용이 반복될 수 있으므로 실제 질문으로 확인해야 합니다.

메타데이터를 함께 저장하기

본문만 벡터로 저장하지 말고 문서명, 섹션명, 작성일, 공개 여부, 제품 영역 같은 메타데이터도 함께 보관하세요. 나중에 특정 버전만 검색하거나 비공개 문서를 제외할 때 유용합니다. 필터링 조건은 벡터 검색 뒤에 덧붙이는 것이 아니라, 가능한 경우 검색 단계에서 적용하는 편이 안전합니다.

3. 검색 결과가 틀리면 생성 프롬프트보다 먼저 점검한다

답변이 엉뚱할 때 모델에게 “정확하게 답하라”고 반복하는 것만으로는 해결되지 않습니다. 모델이 받은 컨텍스트 자체가 틀렸을 가능성이 크기 때문입니다.

검색 결과가 엉뚱할 때

실패한 질문을 모아 다음을 확인하세요.

질문에만 등장하는 표현과 문서의 표현이 다른가?
한 조각에 필요한 조건과 예외가 함께 들어 있는가?
검색 결과가 너무 적거나, 반대로 비슷한 조각으로 가득한가?
최신 문서와 오래된 문서가 동시에 반환되는가?

질문을 검색용 표현으로 다시 작성하는 단계나, 키워드 검색과 의미 검색을 함께 사용하는 방식도 후보가 됩니다. 다만 어떤 방식이 좋은지는 문서 종류와 질문 패턴에 따라 달라지므로 작은 평가 세트로 비교하세요.

답변이 과장될 때

컨텍스트에 없는 내용은 “확인할 수 없다”고 말하게 하고, 답변 뒤에 사용한 문서의 제목이나 위치를 표시하도록 설계하면 검토가 쉬워집니다. 이는 모델이 항상 정답을 보장한다는 뜻이 아니라, 틀린 답을 발견하고 수정할 수 있는 구조를 만드는 일입니다.

프롬프트의 명세와 제약을 정리하는 법은 AI에게 코드를 잘 시키는 프롬프트 작성법과도 연결됩니다. RAG에서도 출력 형식, 근거 범위, 모를 때의 행동을 문장으로 명확히 적는 것이 도움이 됩니다.

4. 1인 개발자를 위한 최소 구현 순서

처음부터 모든 문서를 넣지 말고, 질문이 자주 나오는 한 종류의 문서로 시작하세요. 예를 들면 제품 사용 가이드나 정책 문서처럼 정답의 범위가 비교적 분명한 자료가 좋습니다.

먼저 문서 10~20개 정도를 수동으로 정리하고, 청킹 결과를 직접 읽어 봅니다. 다음으로 대표 질문을 적어 검색된 조각이 실제로 답에 필요한지 확인하세요. 그 뒤에야 저장소, 임베딩 모델, 생성 모델을 연결하면 원인과 결과를 구분하기 쉬워집니다.

구현이 복잡해지면 AI 코딩 도구에 문서 구조와 검색 실패 사례를 함께 전달하세요. 프로젝트 규칙 파일에 데이터 흐름과 금지 조건을 남기는 방법은 AI 코딩 도구에 컨텍스트 잘 주는 법에서 힌트를 얻을 수 있습니다.

5. 출시 전에는 정답보다 실패를 측정한다

RAG의 첫 버전은 화려한 답변보다 틀렸을 때 안전하게 멈추는지가 중요합니다. 다음 체크리스트를 실제 질문으로 반복해 보세요.

관련 문서가 검색되는가?
검색된 조각만으로 답변이 가능한가?
문서에 없는 내용을 추측하지 않는가?
오래된 문서가 최신 문서를 가리지 않는가?
사용자가 답변의 근거를 다시 확인할 수 있는가?

조코헌트에는 197개의 프로덕트와 157명의 출시 메이커가 모여 있습니다. 처음부터 거대한 지식 시스템을 만들기보다, 내가 해결하려는 한 가지 반복 질문을 안정적으로 줄이는 작은 RAG부터 출시하고 실제 질문 로그를 바탕으로 청킹과 검색을 개선해 보세요. RAG의 경쟁력은 기술 용어의 개수보다, 사용자가 믿고 다시 확인할 수 있는 답변 흐름에서 나옵니다.

이 글의 목차