RAG 아키텍처 설계 가이드 - 검색 품질부터 답변 생성까지

RAG가 필요한 이유

LLM만으로 서비스 기능을 만들면 최신 문서, 내부 지식, 사내 정책 같은 정보를 정확하게 반영하기 어렵습니다.

RAG는 외부 지식을 검색해서 답변 생성에 주입하는 구조입니다.

User Query
 -> Query Rewrite
 -> Retrieve Documents
 -> Rerank
 -> Prompt Compose
 -> LLM Generate
 -> Final Answer

핵심은 “모델이 똑똑한가”보다 “어떤 정보를 얼마나 적절하게 꺼내오느냐”입니다.

RAG를 구성하는 기본 단계

1. 문서 수집

대상 소스는 보통 아래와 같습니다.

사내 위키
PDF 매뉴얼
제품 문서
고객센터 FAQ
운영 가이드
코드/설정 문서

문서 품질이 낮으면 검색 성능도 같이 무너집니다. 최신성, 중복, 잘못된 문서를 먼저 정리해야 합니다.

2. 문서 전처리

전처리에서 많이 하는 작업:

HTML/PDF 텍스트 추출
표/코드 블록 보존
헤더 구조 유지
중복 제거
문서 메타데이터 추가

메타데이터 예:

{
  "source": "docs/api/authentication.md",
  "category": "api",
  "product": "console",
  "updated_at": "2026-04-10"
}

이 메타데이터는 필터 검색과 답변 출처 표시에 매우 중요합니다.

3. 청킹

청킹은 단순히 글자 수를 자르는 작업이 아닙니다.

좋은 청킹 원칙:

제목과 본문 맥락이 함께 유지되게 자르기
코드 블록은 중간에 끊지 않기
표/리스트를 가능한 한 묶어서 유지
300~800 토큰 범위에서 실험
10~20% overlap으로 문맥 손실 완화

너무 작게 자르면 검색은 되지만 의미가 약해지고, 너무 크게 자르면 관련 없는 정보가 같이 들어옵니다.

임베딩과 인덱싱

임베딩 모델은 문서를 벡터로 바꿔서 유사도 검색이 가능하게 만듭니다.

실무 선택 기준:

한국어 성능
비용
인덱싱 속도
쿼리 지연시간
벡터 차원 수

초기에 중요한 건 “최고 성능 모델”보다 “일관된 기준으로 빠르게 재색인 가능한 파이프라인”입니다.

검색 품질을 올리는 핵심 포인트

1. Query Rewrite

사용자 질문은 종종 너무 짧거나 애매합니다.

예:

“권한 오류”
“로그인 안됨”
“배포 실패”

이 질문은 검색 전에 확장해야 합니다.

원문: "권한 오류"
확장: "AWS IAM 권한 부족으로 API 호출이 실패하는 경우의 원인과 해결 방법"

2. Hybrid Search

벡터 검색만으로 충분하지 않은 경우가 많습니다.

권장 방식:

BM25 키워드 검색
Vector similarity 검색
결과 병합

에러코드, API 이름, 클래스명처럼 정확한 토큰이 중요한 경우에는 키워드 검색이 훨씬 강합니다.

3. Reranking

Top-k를 바로 LLM에 넣지 말고, 리랭킹 모델로 재정렬하면 답변 품질이 크게 좋아집니다.

특히 긴 문서가 많은 환경에서는 리랭킹이 체감 품질을 좌우합니다.

프롬프트 구성 예시

RAG 프롬프트는 검색 결과를 붙여 넣는 것으로 끝나지 않습니다.

System:
너는 제품 문서를 기반으로 답변하는 기술 지원 어시스턴트다.
검색된 문서에 근거해서만 답하고, 근거가 부족하면 모른다고 말한다.

Context:
[문서 1 요약]
[문서 2 요약]

User Question:
인증 토큰 만료 시 재발급 흐름이 어떻게 되나요?

여기서 중요한 점:

모델 역할을 명확히 지정
답변 근거 범위를 제한
불확실한 경우의 행동을 정의
출처 표시 형식을 통일

답변 품질보다 더 중요한 것

RAG 서비스는 “그럴듯한 답변”보다 “틀렸을 때 안전한 답변”이 중요합니다.

반드시 고려해야 할 항목:

검색 결과가 없을 때 fallback 처리
오래된 문서 경고
출처 링크 제공
민감 정보 필터링
권한 기반 문서 접근 제어

예를 들어 사내 문서를 검색하는 서비스라면 사용자 권한에 따라 검색 가능한 문서 자체가 달라져야 합니다.

RAG 평가 방법

모델 평가를 감으로 하면 운영 품질이 흔들립니다.

최소한 아래는 측정해야 합니다.

Retrieval precision
Retrieval recall
Answer groundedness
Hallucination rate
Citation accuracy
End-to-end latency

평가셋 예:

{
  "question": "토큰 재발급 API는 어떤 조건에서 호출되나요?",
  "expected_docs": ["auth/token-refresh.md"],
  "must_include": ["refresh token", "expiration"],
  "must_not_include": ["password reset"]
}

운영 단계에서 자주 생기는 문제

문서 최신화가 늦음

문서가 바뀌었는데 임베딩이 재생성되지 않으면 RAG 답변은 바로 낡아집니다.

청킹 기준이 제각각임

문서마다 분할 기준이 다르면 검색 품질 편차가 심해집니다.

검색 결과가 너무 많음

Top-k를 무작정 늘리면 오히려 모델이 혼란스러워집니다.

UI에 출처가 없음

사용자가 답변을 검증할 수 없으면 실무 도구로 신뢰를 얻기 어렵습니다.

마무리

RAG 시스템의 품질은 LLM보다 데이터 파이프라인과 검색 전략에서 더 많이 결정됩니다.

성공하는 팀은 처음부터 모든 것을 복잡하게 만들지 않습니다.

문서를 정리하고
청킹 기준을 잡고
검색 품질을 측정하고
출처 기반 답변을 만들고
평가 루프를 계속 돌립니다

이 과정을 꾸준히 운영하는 것이 결국 좋은 RAG 서비스의 핵심입니다.