---
title: "RAG는 모델보다 답을 찾는 경로를 바꾸는 일이었다"
slug: "rag-changes-answer-path-not-model"
category: "RAG"
topic: "rag"
subtopic: "retrieval"
tags: ["RAG","Amazon Bedrock","Knowledge Bases","Hybrid Search","HyDE","Parent Document","Reranking"]
status: "published"
created: "2026-07-22"
updated: "2026-07-22"
summary: "AWS의 RAG 강연을 따라가며 모델 단독 답변, 기본 RAG, 관리형 Knowledge Bases, 고급 검색 파이프라인이 무엇을 다르게 만드는지 정리했다."
kind: "Study Note"
evidence: "AWS Korea YouTube 강연과 한국어 자동 자막 313개 구간 확인"
---

[RAG를 사용하여 생성형 AI 애플리케이션의 응답 품질 높이기](https://www.youtube.com/watch?v=Epy9LJiy1Po)를 봤다. Amazon Web Services Korea가 2024년에 공개한 41분짜리 강연이다.

제목만 봤을 때는 Amazon Bedrock 기능을 소개하는 영상이라고 생각했다. 실제로 제품 설명과 콘솔 데모의 비중이 크다. 그런데 처음부터 끝까지 따라가 보니 더 큰 흐름이 있었다.

```text
모델이 모르는 답을 억지로 생성하게 둔다.
→ 외부 문서에서 근거를 찾아 함께 준다.
→ 그 근거를 더 잘 찾도록 검색 파이프라인을 개선한다.
```

내가 이해한 이 영상의 핵심은 **RAG가 모델 자체를 다시 학습시키는 기술이라기보다, 모델이 답을 만들기 전에 올바른 근거를 찾게 만드는 시스템**이라는 것이다.

이 글은 영상의 한국어 자동 자막 313개 구간을 확인하고 명백한 인식 오류를 문맥에 맞게 고쳐 정리했다. AWS 기능과 지원 범위는 영상이 공개된 2024년 시점의 설명이다.

## 이 영상이 말하고 싶었던 것

파운데이션 모델은 넓은 범위의 지식을 학습했지만 모든 회사의 내부 문서, 특정 산업의 세부 지식, 학습 이후에 생긴 최신 정보까지 알지는 못한다. 모르는 내용을 질문받았을 때 답을 거부하는 대신 그럴듯한 내용을 만들기도 한다.

영상은 이 한계를 해결하는 방법으로 네 가지를 먼저 비교한다.

| 방법 | 바꾸는 대상 | 적합한 상황 |
|---|---|---|
| 프롬프트 엔지니어링 | 질문과 지시문 | 단순한 작업이나 출력 방식 조정 |
| RAG | 모델에 제공하는 외부 근거 | 최신 문서, 사내 문서, 사실 기반 답변 |
| 파인튜닝 | 모델의 행동과 학습된 패턴 | 특정 도메인이나 반복 작업 적응 |
| 모델 자체 훈련 | 모델 전체 | 많은 비용을 감수하고 전용 모델이 필요한 경우 |

이 가운데 영상이 집중한 것은 RAG다. 비교적 적은 비용으로 모델이 학습하지 않은 정보를 답변에 반영할 수 있기 때문이다.

다만 “벡터 DB를 붙이면 끝난다”는 설명에서 멈추지 않는다. 기본 RAG를 만들고, 검색 실패의 원인에 따라 Hybrid Search, RAG Fusion, HyDE, Parent Document, Reranking을 더하는 과정까지 보여 준다.

그래서 영상의 메시지를 한 문장으로 줄이면 다음과 같다.

> 하나의 모델이 모든 비즈니스 지식을 알기를 기대하지 말고, 필요한 근거를 검색해 전달하는 경로를 설계하자.

## 영상의 줄거리

강연은 개념 설명, 관리형 서비스 소개, 두 번의 데모 순서로 진행된다.

| 시간 | 내용 | 흐름에서 맡은 역할 |
|---|---|---|
| 1분 13초~4분 47초 | 프롬프트, RAG, 파인튜닝, 모델 훈련 비교 | 왜 RAG를 선택하는지 설명한다. |
| 4분 48초~10분 17초 | 검색, 증강, 생성과 임베딩 | 기본 RAG의 동작을 설명한다. |
| 10분 18초~15분 46초 | Amazon Bedrock Knowledge Bases | 직접 구축할 때 생기는 운영 복잡도를 줄인다. |
| 16분 2초~21분 16초 | 다섯 가지 고급 RAG와 멀티모달 검색 | 기본 검색이 놓치는 문제를 나눈다. |
| 21분 18초~29분 40초 | 주주서한 데모 | RAG가 없을 때와 있을 때를 비교한다. |
| 29분 41초~37분 23초 | 경제적 영향 보고서 데모 | 고급 기법을 추가했을 때 답변 변화를 보여 준다. |
| 37분 24초~40분 56초 | 운영 구조와 결론 | 관리형과 직접 구축의 선택 기준을 정리한다. |

앞부분은 “왜 모델만으로 부족한가”를 설명하고, 중간은 “기본 RAG를 어떻게 빠르게 만드는가”를 보여 준다. 후반은 “RAG를 붙였는데도 답이 만족스럽지 않으면 무엇을 바꿀 것인가”에 답한다.

## 원래 방식은 모델이 기억한 것만으로 답하게 했다

영상의 첫 번째 데모는 Claude 3 Sonnet에 Amazon의 연도별 주주서한을 요약해 달라고 질문한다. RAG는 연결하지 않은 상태다.

모델은 2018년부터 2022년까지의 내용을 요약한다. 2023년 주주서한을 자세히 설명해 달라고 다시 묻자 실제 문서를 찾지 못한다. 모델 학습 당시에는 해당 문서가 발행되기 전이었기 때문이다. 그 결과 실제 문서가 아니라 2023년 상황을 바탕으로 만든 가상의 답변이 나온다.

여기서 기존 방식의 문제는 생성 모델의 문장 능력이 부족하다는 것이 아니다. 모델에게 최신 문서를 조회할 경로가 없다는 것이다.

```text
사용자 질문
  ↓
파운데이션 모델의 학습된 기억
  ↓
답변
```

이 구조에서는 다음 문제가 생긴다.

- 모델 학습 시점 이후의 정보를 알 수 없다.
- 회사 내부 자료나 비공개 문서를 알 수 없다.
- 답변이 어느 문서에서 나왔는지 확인하기 어렵다.
- 모르는 내용을 그럴듯하게 만들 수 있다.

프롬프트를 더 정교하게 써도 모델이 보지 못한 2023년 문서의 사실을 만들어 낼 수는 없다. 파인튜닝으로 새 정보를 넣을 수도 있지만 문서가 바뀔 때마다 다시 학습시키는 방식은 최신 정보 조회 문제에 비해 무겁다.

## 영상에서는 외부 문서를 먼저 찾게 했다

RAG를 적용하면 질문을 바로 생성 모델에 보내지 않는다. 먼저 외부 지식 저장소에서 답과 관련된 문서 조각을 찾고, 질문과 검색 결과를 함께 모델에 전달한다.

```text
사용자 질문
  ↓
관련 문서 검색
  ↓
질문 + 검색된 근거
  ↓
파운데이션 모델
  ↓
근거 기반 답변
```

영상에서는 2019년부터 2023년까지의 실제 주주서한을 S3에 올린다. Amazon Bedrock Knowledge Base의 동기화를 실행하면 문서 청킹, 임베딩, 벡터 DB 저장이 자동으로 진행된다.

같은 질문을 다시 했을 때 차이가 생긴다.

- 실제 2023년 문서를 바탕으로 답한다.
- 이전보다 구체적인 내용이 나온다.
- 답변 문장에 각주가 붙는다.
- 각주에서 근거로 사용한 문서와 청크 메타데이터를 확인할 수 있다.

모델이 갑자기 2023년 지식을 학습한 것은 아니다. 답변할 때마다 필요한 문서를 찾아 읽게 된 것이다.

## 직접 만든 RAG와 Knowledge Bases의 차이

기본 RAG의 개념은 단순하지만 직접 운영하려면 해야 할 일이 많다.

```text
데이터 소스 연결
→ 문서 파싱과 청킹
→ 임베딩 생성
→ 벡터 DB 적재
→ 변경 문서 증분 갱신
→ 질문 임베딩
→ 유사 문서 검색
→ 프롬프트 구성
→ 모델 호출
```

여기에 권한, 확장, 실패 복구, 자동화도 필요하다. 영상은 이 복잡성을 줄이기 위해 Amazon Bedrock Knowledge Bases를 소개한다.

발표 시점 기준으로 S3를 데이터 소스로 연결하고, 청킹 전략과 Titan Text Embeddings를 선택하고, OpenSearch Serverless 같은 벡터 저장소를 지정할 수 있었다. `RetrieveAndGenerate` API는 검색부터 생성까지 묶어서 처리하고, `Retrieve` API는 검색 결과만 돌려줘 이후 흐름을 직접 제어하게 한다.

둘의 차이는 RAG를 쓰느냐가 아니다. **반복되는 데이터 수집과 검색 기반을 누가 운영하느냐**에 가깝다.

| 직접 구축 | Bedrock Knowledge Bases |
|---|---|
| 파이프라인과 저장소를 직접 연결한다. | 콘솔이나 API에서 관리형 워크플로를 구성한다. |
| 세부 동작을 자유롭게 바꿀 수 있다. | 기본 구성이 빠르고 운영할 요소가 줄어든다. |
| 고급 기법을 원하는 방식으로 조합하기 쉽다. | 제공되는 옵션과 확장 지점 안에서 시작한다. |
| 구현과 장애 대응 책임이 크다. | 편의성이 높지만 서비스 의존성이 생긴다. |

영상 후반도 두 경로를 모두 남겨 둔다. 빠르게 시작하려면 Knowledge Bases를 사용하고, 더 많은 제어가 필요하면 S3, Step Functions, Bedrock, OpenSearch Serverless, SageMaker를 조합해 직접 구성한다.

## 기본 RAG만으로 끝나지 않은 이유

문서를 벡터 DB에 넣었다고 항상 올바른 근거가 검색되는 것은 아니다. 영상에서 소개한 고급 기법은 각각 다른 실패를 고치려 한다.

### 키워드와 의미 검색이 서로 다른 문서를 찾는다

키워드 검색은 제품명, 코드, 고유명사처럼 정확한 표현에 강하다. 반면 같은 뜻을 다른 말로 표현하면 놓칠 수 있다. 시맨틱 검색은 의미가 가까운 문서를 찾지만 정확한 단어 일치를 놓치거나 의미가 비슷한 엉뚱한 문서를 가져올 수 있다.

Hybrid Fusion은 두 검색을 동시에 실행하고 결과를 Rank Fusion으로 합친다. 어느 하나를 정답으로 고르는 대신 서로 다른 후보를 모으는 방식이다.

### 질문 표현과 정답 문서 표현 사이에 차이가 있다

RAG Fusion은 하나의 질문을 여러 관점의 질문으로 확장해 검색 범위를 넓힌다.

HyDE는 질문으로 가상의 답변을 먼저 만든 뒤 그 답변을 임베딩해 실제 문서를 검색한다. 질문은 짧고 정답 문서는 설명문인 경우가 많기 때문에, 가상 답변을 중간에 두어 두 표현 사이의 간격을 줄이려는 방법이다.

처음 HyDE를 들었을 때는 가상의 답변을 쓰는 일이 환각을 다시 끌어들이는 것처럼 보였다. 하지만 이 가상 답변을 최종 사실로 사용하지 않는다. 실제 문서를 더 잘 찾기 위한 검색 질의로만 사용하고, 최종 답변의 근거는 검색된 문서에서 가져온다.

### 작은 청크와 큰 청크의 장점이 다르다

작은 청크는 질문과 정확히 맞는 부분을 찾기 쉽다. 대신 앞뒤 문맥이 잘릴 수 있다. 큰 청크는 문맥을 보존하지만 여러 주제가 섞여 검색 점수가 흐려질 수 있다.

Parent Document 방식은 작은 자식 청크로 검색하고, 최종 모델에는 연결된 더 큰 부모 문서를 전달한다. 검색 정확도와 문맥 보존을 같은 청크 크기로 해결하지 않는다는 점이 인상적이었다.

### 관련 문서를 찾아도 순서가 나쁠 수 있다

1차 검색 결과에 정답 문서가 포함되어 있어도 뒤쪽에 있으면 모델이 놓칠 수 있다. 영상은 이를 `lost in the middle` 문제와 연결한다.

Reranking은 1차 검색 후보를 별도 모델이 다시 읽고 질문과의 관련성 순으로 재정렬한다. 검색 후보에 정답이 없으면 복구하지 못하지만, 후보는 맞고 순서가 나쁜 문제에는 효과가 있다.

### 표와 이미지는 텍스트 임베딩만으로 찾기 어렵다

PDF나 프레젠테이션의 중요한 내용이 표나 차트에만 들어 있을 수 있다. 영상은 문서를 텍스트, 이미지, 표로 분리하고 Claude 3 Sonnet으로 이미지와 표를 요약한 텍스트를 만든 뒤 함께 임베딩한다.

멀티모달 RAG는 단순히 이미지 파일을 벡터 DB에 넣는 일이 아니었다. 이미지와 표가 가진 의미를 검색 가능한 표현으로 바꾸는 전처리 과정이 필요했다.

## 고급 RAG 데모에서는 무엇이 달라졌나

두 번째 데모의 문서는 이미지와 표가 포함된 `2023 AWS 경제적 영향 보고서`다. 질문은 AWS가 한국 지역사회에서 무슨 일을 하는지다.

데이터를 넣는 과정은 다음과 같다.

```text
복합 문서 파싱
→ 텍스트·이미지·표 분리
→ 이미지와 표를 Claude 3 Sonnet으로 요약
→ 작은 청크와 큰 부모 청크 연결
→ Amazon Titan으로 임베딩
→ OpenSearch Serverless에 저장
```

질문을 처리하는 과정은 더 길다.

```text
사용자 질문
→ Claude 3로 HyDE 가상 답변 생성
→ 질문과 가상 답변 임베딩
→ 시맨틱 검색 + Nori 기반 키워드 검색
→ Rank Fusion
→ SageMaker의 한국어 Reranking 모델로 재정렬
→ 상위 5개 문서 선택
→ Claude 3 Sonnet이 최종 답변 생성
```

영상은 기법을 단계적으로 추가하며 결과를 비교한다.

| 적용한 구성 | 영상에서 보인 답변 변화 |
|---|---|
| Hybrid Search + 복합 문서 처리 | 관련 활동이 짧게 나열된다. |
| Parent Document + HyDE 추가 | 교육, 일자리, 지역경제, 지속가능성처럼 내용이 더 풍부하게 구조화된다. |
| Reranking 추가 | 관련 근거가 다시 정리되고 세부 프로그램과 데이터가 더 분명하게 나온다. |

여기서 주의할 점도 있다. 영상은 답변이 길어지고 구조화되는 모습을 보여 주지만, 정확도 지표나 평가셋으로 각 기법의 개선 폭을 증명하지는 않는다. 화면에서 더 좋아 보이는 답변과 실제로 더 정확한 답변은 같지 않을 수 있다.

그래서 이 데모를 “다섯 가지 기법을 모두 넣으면 정답이 된다”로 받아들이면 안 된다고 생각한다. 발표자도 모든 기법을 무조건 적용하지 말고, 자신의 문제를 해결하는 기법을 검토한 뒤 적용하라고 말한다.

## 원래 방식과 영상의 방식을 한 번에 비교하면

| 비교 항목 | 모델만 사용 | 기본 RAG | 영상의 고급 RAG |
|---|---|---|---|
| 지식 출처 | 학습 당시 모델 파라미터 | 외부 문서 청크 | 텍스트·표·이미지와 여러 검색 결과 |
| 최신·사내 정보 | 알 수 없음 | 문서 동기화 후 반영 | 문서 반영과 검색 품질 개선 |
| 검색 | 없음 | 주로 임베딩 기반 유사도 검색 | 키워드 + 시맨틱 + HyDE + Rank Fusion |
| 문맥 | 모델 내부 기억에 의존 | 검색된 고정 크기 청크 | Parent Document로 검색 단위와 전달 단위 분리 |
| 후보 순서 | 해당 없음 | 벡터 유사도 순서 | 별도 Reranking 모델로 재정렬 |
| 근거 확인 | 어렵다 | 출처와 청크 확인 가능 | 선별된 근거와 출처 확인 가능 |
| 운영 복잡도 | 가장 낮다 | 수집·임베딩·벡터 DB 필요 | 품질은 조정 가능하지만 구성과 비용 증가 |

가장 큰 차이는 생성 모델의 종류가 아니다. 모델 앞단에 어떤 정보가 어떤 순서로 들어가는지가 달라졌다.

## 영상을 보고 느낀 점

### RAG는 하나의 기능이 아니라 실패를 나눈 파이프라인이었다

이전에는 RAG를 “문서를 임베딩해서 벡터 DB에서 찾는 구조”로 짧게 이해했다. 영상은 그 설명이 시작점일 뿐이라는 것을 보여 줬다.

검색 결과가 나쁘다고 해도 원인은 여러 가지다.

- 질문과 문서의 단어가 다를 수 있다.
- 의미 검색이 정확한 고유명사를 놓칠 수 있다.
- 청크가 너무 작아 문맥이 잘릴 수 있다.
- 청크가 너무 커 의미가 희석될 수 있다.
- 올바른 문서가 후보에 있지만 순서가 낮을 수 있다.
- 답이 표나 이미지 안에 있어 텍스트 검색 대상에서 빠질 수 있다.

Hybrid Search, HyDE, Parent Document, Reranking은 이름만 다른 유행 기술이 아니라 서로 다른 실패 원인에 대응한다. 어떤 실패인지 확인하지 않고 모두 넣으면 지연 시간과 비용만 늘고, 무엇이 품질을 바꿨는지 알기 어려워진다.

### 관리형 서비스는 완성된 품질보다 출발점을 제공한다

Bedrock Knowledge Bases는 데이터 연결, 청킹, 임베딩, 벡터 저장 같은 반복 작업을 줄여 준다. 하지만 관리형 서비스를 선택했다고 검색 품질까지 자동으로 해결되는 것은 아니다.

어떤 문서를 넣을지, 청크 크기를 어떻게 정할지, 몇 개를 검색할지, 키워드 검색을 합칠지, 답변을 어떻게 평가할지는 여전히 애플리케이션의 책임이다. 관리형 서비스의 가치는 판단을 없애는 것이 아니라 판단해야 할 범위를 줄이는 데 있다고 느꼈다.

### 좋은 생성 모델보다 올바른 근거가 먼저일 수 있다

첫 번째 데모에서 문제는 Claude 3 Sonnet의 문장 생성 능력이 아니었다. 실제 2023년 주주서한을 보지 못했다는 것이 문제였다.

잘못된 근거를 넣고 더 좋은 모델로 바꿔도 사실성은 보장되지 않는다. 반대로 같은 모델에 실제 문서를 제공하자 답변이 달라졌다. 생성 모델 교체 전에 검색 결과가 정답을 포함하는지 확인해야 한다는 순서가 남았다.

### 출처 표시는 품질 관측 장치다

각주와 원문 청크를 확인할 수 있다는 점도 중요했다. 출처가 있다고 답이 자동으로 참이 되는 것은 아니다. 잘못 검색한 문서를 충실하게 요약할 수도 있다.

그래도 어느 문서가 답변에 들어갔는지 알면 검색 실패와 생성 실패를 나눠 볼 수 있다. 사용자에게 근거를 제공하는 기능이면서, 개발자에게는 RAG를 디버깅하는 관측 장치가 된다.

## 새로 알게 된 것

이 영상을 보고 다음 내용을 분명하게 구분하게 됐다.

1. **RAG와 파인튜닝은 같은 문제를 풀지 않는다.** 최신 사실을 조회하는 문제에는 RAG가 자연스럽고, 모델의 행동 패턴을 바꾸는 문제에는 파인튜닝이 더 가깝다.
2. **RAG와 에이전트의 경계가 있다.** 정적인 문서 검색은 RAG이고, DB 조회나 API 호출처럼 실시간 정보와 행동이 필요하면 도구와 에이전트가 필요하다.
3. **검색 단위와 모델 입력 단위는 같을 필요가 없다.** Parent Document는 작은 단위로 찾고 큰 단위로 읽히게 한다.
4. **Reranking은 Recall을 복구하지 못한다.** 1차 검색 후보에 정답이 있어야 순서를 개선할 수 있다.
5. **멀티모달 검색은 전처리 설계 문제이기도 하다.** 표와 이미지의 의미를 검색 가능한 텍스트나 표현으로 바꾸어야 한다.
6. **고급 기법의 수가 품질 지표는 아니다.** 동일한 질문과 정답 기준으로 변경 전후를 평가해야 한다.

## 지금 직접 적용한다면

처음부터 영상의 고급 아키텍처를 그대로 만들지는 않을 것 같다. 다음 순서로 작게 시작하겠다.

```text
모델 단독 답변을 기준선으로 측정한다.
→ 기본 시맨틱 RAG를 붙인다.
→ 검색 후보에 정답이 포함되는지 Recall@k로 확인한다.
→ 정확한 용어를 놓치면 Hybrid Search를 비교한다.
→ 표현 차이가 크면 Query Expansion이나 HyDE를 시험한다.
→ 문맥이 잘리면 Parent Document를 시험한다.
→ 후보는 맞지만 순서가 나쁘면 Reranking을 붙인다.
```

최종 답변만 보고 평가하지 않고 다음 항목을 따로 남기고 싶다.

- 검색 후보에 정답 문서가 있었는가
- 정답 문서가 몇 번째에 있었는가
- 모델이 제공된 근거를 실제로 사용했는가
- 답변의 문장마다 근거를 연결할 수 있는가
- 각 기법이 추가한 지연 시간과 비용은 얼마인가

영상이 알려 준 것은 “Bedrock을 쓰면 RAG가 해결된다”가 아니었다. 내가 얻은 결론은 더 단순하다.

**모델이 틀렸다고 바로 모델부터 바꾸지 말고, 모델이 어떤 근거를 받아 답했는지 먼저 확인해야 한다.** RAG의 품질은 생성 단계 하나가 아니라 문서를 준비하고, 찾고, 고르고, 전달하는 전체 경로에서 만들어진다.

## 참고

- Amazon Web Services Korea, [RAG를 사용하여 생성형 AI 애플리케이션의 응답 품질 높이기](https://www.youtube.com/watch?v=Epy9LJiy1Po), 2024.