RAG 구현 다음 단계는? 검색 정확도를 높이는 RAG 고도화 방법 4가지

벡터 데이터베이스에 문서를 저장하고, 임베딩으로 유사한 문서를 찾아 LLM에 전달하는 RAG 시스템. 직접 구현해 본 개발자라면 기본적인 작동 원리는 익숙할 거예요.

그런데 RAG를 실제 서비스에 적용하면 예상하지 못한 문제가 발생합니다. 분명 문서에 답이 있는데도 챗봇이 찾지 못하거나, 비슷하지만 다른 정보를 가져오기도 하죠. 관련 문서를 제대로 검색했는데 최종 답변이 부정확한 경우도 있습니다.

이런 문제를 해결하기 위해 필요한 것이 'RAG 고도화'입니다. 2024년 Anthropic이 공개한 연구는 기본 RAG에 얼마나 많은 개선 여지가 있는지 보여줍니다. 문서에 맥락 정보를 추가하고 키워드 검색과 재정렬을 결합했더니, 특정 실험 환경에서 관련 문서를 놓치는 비율이 5.7%에서 1.9%로 감소했습니다. 검색 실패율이 약 67% 줄어든 것이죠.

물론 모든 RAG 서비스에서 같은 효과를 얻는다는 의미는 아닙니다. 중요한 점은 같은 문서를 사용하더라도 검색 시스템을 어떻게 설계하느냐에 따라 결과가 크게 달라질 수 있다는 사실입니다.

그렇다면 기본 RAG에서 발생하는 문제를 어떻게 개선할 수 있을까요? 실무에서 활용할 수 있는 네 가지 RAG 고도화 방법과 각각의 적용 기준을 살펴보겠습니다.

1. 기본 RAG는 왜 검색 정확도가 떨어질까?

기본적인 RAG는 다음과 같은 순서로 작동합니다.

1. 문서를 일정한 크기로 나누어 저장합니다. 이를 청킹(Chunking)이라고 합니다.

2. 나눈 문서를 임베딩 모델로 벡터화합니다.

3. 사용자의 질문과 의미적으로 유사한 문서를 검색합니다.

4. 검색한 문서를 LLM에 전달해 답변을 생성합니다.

구조는 비교적 간단하지만, 실제 데이터가 복잡해질수록 여러 문제가 발생할 수 있습니다.

문제 ① 문서를 나누는 과정에서 맥락이 사라진다

예를 들어 한 기업의 실적 보고서를 여러 개의 청크로 나누었다고 가정해 보겠습니다. 그중 하나에 다음과 같은 문장이 있습니다.

"해당 분기 매출은 전년 대비 12% 증가했다."

문장 자체는 명확하지만, 이 부분만 보면 어느 기업의 어떤 분기 실적인지 알 수 없습니다. 원래 문서에서는 제목과 앞뒤 문단을 통해 충분히 이해할 수 있었던 정보가 청킹 과정에서 분리된 것이죠.

이런 청크를 개별적으로 임베딩하면 검색 시스템이 문서의 맥락을 충분히 반영하지 못할 수 있습니다.

문제 ② 의미는 비슷하지만 정확한 정보가 다른 문서를 가져온다

벡터 검색은 단어가 정확히 일치하지 않아도 의미가 유사한 문서를 찾는 데 유용합니다. 하지만 제품명, 오류 코드, 부품 번호처럼 정확한 일치가 중요한 정보에서는 한계가 나타날 수 있습니다.

사용자가 'TPS-240 모델의 사양'을 물었는데, 검색 시스템이 'TPS-250 모델'의 문서를 더 관련성이 높다고 판단하는 상황이 대표적입니다.

두 문서는 의미적으로 비슷하지만 사용자가 원하는 정답은 아닙니다.

문제 ③ 여러 문서를 연결해야 하는 질문에 취약하다

'A 기업이 투자한 B 자회사의 2026년 임원 명단'을 묻는 질문을 생각해 볼까요?

답하려면 먼저 A 기업이 투자한 자회사를 확인하고, 그중 B 기업을 식별한 뒤, 해당 기업의 임원 명단을 찾아야 할 수 있습니다. 기본 RAG도 필요한 문서가 한 번에 검색된다면 이런 질문에 답할 수 있습니다.

하지만 관련 정보가 여러 문서에 흩어져 있으면 한 번의 검색으로 필요한 자료를 모두 찾기 어렵습니다.

이처럼 기본 RAG의 한계는 단순히 LLM의 성능 문제가 아닙니다. 어떤 형태로 문서를 저장하고, 어떤 방식으로 검색하며, 검색한 정보를 어떻게 활용하는지에 따라 답변 품질이 달라집니다.

이제 각각의 문제를 해결하는 고도화 방법을 살펴보겠습니다.

2. Contextual Retrieval: 문서에 맥락을 추가해 검색 정확도 높이기

첫 번째 방법은 검색 이전에 문서를 저장하는 방식부터 개선하는 것입니다.

대표적인 접근법이 Anthropic이 2024년 9월 공개한 Contextual Retrieval, 즉 문맥 보강 검색입니다.

청크마다 원본 문서의 맥락을 추가한다

앞서 살펴본 '해당 분기 매출은 전년 대비 12% 증가했다'라는 문장을 다시 생각해 보겠습니다. 기본 RAG에서는 이 문장이 포함된 청크를 그대로 임베딩합니다.

Contextual Retrieval은 조금 다르게 접근합니다. LLM이 원본 문서를 참고해 청크에 대한 맥락 설명을 생성하고, 이를 청크 앞에 추가합니다.

예를 들어 다음과 같이 바꿀 수 있습니다.

이렇게 하면 원본 문서를 통째로 검색하지 않아도 각 청크가 어떤 정보를 담고 있는지 더 명확하게 파악할 수 있습니다.

Anthropic이 제안한 방식은 이렇게 맥락을 추가한 텍스트를 임베딩 검색과 BM25 키워드 검색 양쪽에 활용합니다.

실제 검색 실패율은 얼마나 줄었을까?

Anthropic은 코드, 논문, 소설 등 여러 유형의 문서를 활용해 Contextual Retrieval의 성능을 실험했습니다.

실험에서 상위 20개 검색 결과에 관련 문서가 포함되지 못한 비율은 다음과 같이 변화했습니다.

여기서 주의할 점이 있습니다. 67%는 최종 답변의 정확도가 아니라, 상위 20개 검색 결과에서 관련 문서를 놓친 비율의 상대적 감소를 의미합니다. 실제 개선 폭은 데이터와 검색 환경에 따라 달라집니다.

또한 문맥 정보를 생성하려면 문서 전처리 단계에서 LLM을 추가로 사용해야 합니다. Anthropic은 프롬프트 캐싱으로 이 비용을 줄일 수 있다고 설명했지만, 실제 비용은 모델과 문서 규모에 따라 달라집니다.

모든 문서에 Contextual Retrieval이 필요할까?

그렇지는 않습니다. 청크에 원본 문서의 정보가 충분히 포함되어 있다면 별도의 맥락 보강이 필요하지 않을 수 있습니다.

반면 방대한 보고서나 계약서처럼 문서 제목, 작성 시점, 소속 조직 등 앞뒤 맥락을 알아야 내용을 정확하게 이해할 수 있는 자료에서는 검토할 가치가 있습니다.

이외에도 문서의 맥락 손실을 줄이는 방법이 있습니다.

• 의미 단위 문서 분할(Semantic Chunking): 일정한 토큰 수로만 나누지 않고 문단이나 주제의 흐름을 고려해 분할하는 방법

• 상위 문서 검색(Parent-Document Retrieval): 작은 청크로 검색하되, 답변 생성에는 해당 청크가 속한 더 큰 문서 단위를 활용하는 방법

• 메타데이터 기반 색인: 문서 제목, 작성일, 부서, 섹션 등의 정보를 저장해 검색 조건으로 활용하는 방법

이 중 어떤 방법이 효과적인지는 문서의 구조와 질문 유형에 따라 다릅니다.

핵심은 청크를 더 정교하게 나누는 것 자체가 아니라, 답변에 필요한 맥락이 검색 과정에서 사라지지 않도록 설계하는 것입니다.

3. 하이브리드 검색: 의미 검색과 키워드 검색 결합하기

두 번째 방법은 검색 방식 자체를 개선하는 것입니다. 앞에서 살펴본 TPS-240과 TPS-250의 사례처럼, 의미가 비슷하다는 이유만으로 문서를 선택하면 정확한 정보를 놓칠 수 있습니다.

이때 활용할 수 있는 방법이 하이브리드 검색(Hybrid Search)입니다.

의미 검색과 키워드 검색은 무엇이 다를까?

두 방식은 문서를 찾는 기준이 다릅니다.

예를 들어 '로그인 오류 해결 방법'이라고 검색하면, 벡터 검색은 '인증 실패 대처 방법'처럼 표현이 다른 문서도 찾을 수 있습니다.

반면 'ERR_AUTH_401'이라는 특정 오류 코드를 검색할 때는 정확한 용어 일치를 활용하는 방식이 유리할 수 있습니다.

하이브리드 검색은 두 방식을 함께 사용합니다. 먼저 벡터 검색과 키워드 검색을 각각 실행한 뒤, 결과를 통합해 최종 검색 후보를 선정합니다.

이때 서로 다른 검색 결과의 순위를 결합하는 RRF(Reciprocal Rank Fusion) 같은 방법을 사용할 수 있습니다.

단, BM25가 언제나 정확한 용어를 찾아내는 것은 아닙니다. 특히 한국어에서는 조사와 어미 변화, 복합명사 등을 고려한 형태소 분석과 토큰화 설정이 검색 성능에 영향을 미칩니다.

질문 자체를 개선하는 방법도 있다

검색 알고리즘을 개선해도 사용자의 질문이 너무 짧거나 모호하면 원하는 문서를 찾기 어려울 수 있습니다. 이때는 검색 전에 질문을 변환하는 방법을 활용합니다.

① 질문 재작성(Query Rewriting)

사용자의 질문을 검색하기 쉬운 형태로 바꾸는 방법입니다.

예를 들어 이전 대화에서 '2026년 상반기 실적 보고서'에 관해 이야기하다가 사용자가 '그때 매출은?'이라고 질문했다고 가정해 보겠습니다.

시스템은 앞선 대화의 맥락을 반영해 검색어를 '2026년 상반기 매출 실적'으로 바꿀 수 있습니다. 단, 사용자가 말하지 않은 기간이나 조건을 임의로 추가하지 않도록 주의해야 합니다.

② HyDE(Hypothetical Document Embeddings)

사용자의 질문에 대해 LLM이 가상의 답변 문서를 먼저 생성한 뒤, 해당 문서의 임베딩을 활용해 실제 자료를 검색하는 방법입니다.

질문보다 답변 형태의 텍스트가 검색 대상 문서와 의미적으로 더 가까울 수 있다는 아이디어에서 출발했습니다. 다만 가상 문서에 잘못된 내용이 포함되면 검색 방향도 왜곡될 수 있으므로 평가가 필요합니다.

③ 다중 질문 검색(Multi-query)

하나의 질문을 여러 표현으로 바꾸어 각각 검색한 뒤 결과를 통합합니다. 예를 들어 'LLM 응답 속도 개선'이라는 질문을 'LLM 추론 지연 최적화', 'LLM 서빙 성능 개선' 등으로 확장할 수 있습니다.

검색 범위를 넓힐 수 있지만 불필요한 문서가 함께 검색될 가능성도 있습니다. 질문 변환은 특히 짧은 질문이나 후속 질문이 자주 등장하는 챗봇에서 유용하게 검토할 수 있습니다.

4. 재정렬부터 GraphRAG까지, 더 복잡한 질문을 해결하는 방법

검색 방식을 개선한 뒤에도 관련 문서의 순위가 낮거나, 여러 문서의 정보를 연결하지 못하는 문제가 남을 수 있습니다.

이때 고려할 수 있는 방법이 재정렬과 GraphRAG, Agentic RAG입니다.

① Reranking: 검색한 문서의 우선순위 다시 정하기

재정렬(Reranking)은 1차 검색 결과를 다시 평가해 질문과 관련성이 높은 문서를 위쪽에 배치하는 과정입니다.

예를 들어 사용자 질문과 관련된 문서 50개가 검색되었다고 가정해 보겠습니다. 그중 실제 정답이 있는 문서가 35번째에 있다면, 상위 5개 문서만 LLM에 전달하는 시스템에서는 해당 정보를 활용하지 못할 수 있습니다.

재정렬 모델은 검색한 문서들을 질문과 다시 비교해 순위를 조정합니다. 대표적인 방식인 Cross-encoder는 질문과 문서를 한 쌍으로 입력받아 관련성을 평가합니다. 벡터 검색보다 정교한 비교가 가능하지만, 추가 계산이 필요합니다.

실무에서는 다음과 같은 2단계 방식을 고려할 수 있습니다.

1. 벡터 검색이나 하이브리드 검색으로 관련 문서 후보를 넉넉하게 확보합니다.

2. 재정렬 모델로 후보들의 순위를 다시 매긴 뒤 상위 문서를 LLM에 전달합니다.

한국어 RAG에서도 활용 사례가 있습니다. AWS는 2024년 한국어 재정렬 모델을 적용한 사례에서 검색 결과의 Hit Rate와 MRR이 개선되는 결과를 소개했습니다.

여기서 Hit Rate는 평가에 필요한 정답 문서가 검색 결과에 포함되었는지 확인하는 지표이고, MRR은 관련 문서가 얼마나 높은 순위에 등장하는지 평가하는 지표입니다.

다만, 재정렬에도 한계는 있습니다. 처음 검색한 후보에 정답 문서가 없다면, 재정렬만으로는 그 문서를 찾아낼 수 없습니다. 따라서 검색 누락과 검색 순위 문제를 구분하는 것이 중요합니다. 또한 재정렬은 추가 연산과 응답 지연을 발생시키므로, 후보 수와 모델 크기를 함께 고려해야 합니다.

② GraphRAG: 문서 전체의 관계와 주요 주제 파악하기

재정렬이 이미 검색한 문서의 순서를 개선하는 기술이라면, GraphRAG는 정보를 구조화하는 방식부터 다르게 접근합니다.

Microsoft Research가 2024년 공개한 GraphRAG는 문서에서 주요 개체와 관계를 추출해 지식 그래프를 구성하고, 연관된 정보들을 그룹으로 묶어 요약합니다.

예를 들어 수백 개의 기업 내부 보고서가 있다고 가정해 보겠습니다. 사용자가 '지난 1년간 여러 사업부에서 반복적으로 등장한 주요 문제는 무엇인가?'라고 질문한다면, 특정 문서 몇 개만 검색해서는 전체 흐름을 파악하기 어려울 수 있습니다. GraphRAG는 문서 전체에서 추출한 관계와 그룹별 요약을 활용해 이러한 질문에 접근합니다.

Microsoft Research의 'From Local to Global' 연구에서는 문서 집합 전체를 이해해야 하는 질문에 대해 기존 RAG 방식보다 답변의 포괄성과 다양성이 개선되는 결과를 보고했습니다.

다만 GraphRAG를 모든 RAG의 상위 기술이라고 볼 수는 없습니다. 특정 제품의 사양이나 계약서의 한 조항처럼 개별 사실을 찾는 질문에는 일반적인 검색 방식으로도 충분할 수 있습니다.

반대로 문서 전체의 주제, 조직 간 관계, 사건 간 연결 등을 파악해야 한다면 그래프 기반 접근이 유용할 수 있습니다.

문서에서 관계를 추출하고 그래프를 구축하는 데 추가 비용이 들며, 데이터가 자주 변경되는 환경에서는 유지 관리 부담도 고려해야 합니다.

③ Agentic RAG: 필요할 때 추가 검색하고 검증하기

지금까지 살펴본 기법들은 검색할 문서를 더 잘 찾거나 정리하는 데 초점을 맞췄습니다. Agentic RAG는 여기에 검색 과정에 대한 판단을 추가합니다.

예를 들어 사용자가 'A 기업의 최신 투자 현황과 주요 자회사의 실적을 비교해 줘'라고 질문했다고 가정해 보겠습니다. 한 번의 검색으로 필요한 정보를 모두 확보하기 어려울 수 있습니다.

이때 Agentic RAG는 질문을 여러 단계로 나누고, 처음 검색한 자료가 부족하다고 판단하면 검색어를 바꾸거나 추가 검색을 수행하도록 설계할 수 있습니다.

반드시 여러 에이전트가 필요한 것은 아닙니다. 하나의 에이전트가 검색 결과를 확인하고 추가 검색 여부를 결정하는 방식도 가능합니다.

관련 연구로는 다음과 같은 접근법이 있습니다.

• Corrective RAG(CRAG): 검색된 문서의 관련성을 평가하고, 정보가 충분하지 않다면 추가 자료를 활용해 보완하는 방식

• Adaptive RAG: 질문의 복잡도에 따라 검색 전략을 다르게 적용하는 방식

두 접근법 모두 2024년 공개된 연구를 바탕으로 하며, 검색 과정에 판단과 적응 기능을 추가한다는 공통점이 있습니다.

다만 여러 번 검색하고 검증하는 과정에서는 응답 시간이 길어지고 비용이 증가할 수 있습니다.

따라서 모든 질문에 복잡한 검색 과정을 적용하기보다, 단순한 질문은 빠르게 처리하고 추가 정보가 필요한 질문에만 검색 단계를 확장하는 방식이 합리적일 수 있습니다.

5. 어떤 RAG 고도화 기술을 선택해야 할까?

여기까지 살펴보면 RAG 고도화 방법은 다양합니다.

그렇다고 Contextual Retrieval, 재정렬, GraphRAG, Agentic RAG를 모두 적용해야 하는 것은 아닙니다.

실무에서 중요한 것은 어떤 기술이 더 발전했는지 판단하는 것이 아니라, 현재 서비스에서 어떤 문제가 발생하는지 파악하는 일입니다.

검색 실패 원인에 따라 개선 방법이 달라진다

예를 들어 고객 지원 챗봇이 정확한 제품명을 자주 놓친다면 GraphRAG를 도입하기보다 키워드 검색을 개선하는 것이 먼저일 수 있습니다.

반면 여러 사업부의 보고서를 종합해 공통된 이슈를 분석해야 한다면 GraphRAG가 적합한지 검토할 수 있겠죠.

또한 실제 서비스에서는 응답 속도, 비용, 데이터 갱신 방식도 함께 고려해야 합니다.

검색 정확도가 조금 높아지더라도 응답 시간이 지나치게 길어지거나 운영 비용이 크게 증가한다면 반드시 좋은 선택이라고 볼 수는 없습니다.

RAG 성능을 어떻게 평가할까?

고도화 효과를 확인하려면 정량적인 평가가 필요합니다.

RAG 평가는 크게 세 영역으로 나눠 생각할 수 있습니다.

검색 품질이 개선되었다고 최종 답변 품질까지 반드시 개선되는 것은 아닙니다. 필요한 문서를 잘 찾더라도 LLM이 내용을 잘못 해석하거나, 검색 결과와 무관한 내용을 답변에 포함할 수 있기 때문입니다.

따라서 검색 단계와 답변 생성 단계를 구분해 평가해야 합니다. 이때 Ragas, DeepEval, TruLens 등의 평가 도구를 활용할 수 있습니다. 실제 질문과 검증된 정답으로 구성한 평가 데이터셋을 만들고, 같은 조건에서 변경 전후의 성능을 비교하는 방식입니다.

예를 들어 재정렬 모델을 적용하기 전과 후에 동일한 질문 100개를 테스트한다면, 관련 문서가 상위 검색 결과에 포함되는 비율이 개선되었는지 확인할 수 있습니다. 여기에 최종 답변 품질과 응답 시간, 비용까지 함께 측정하면 기술 도입의 효과를 더 객관적으로 판단할 수 있습니다.

RAG 고도화는 새로운 기술을 추가하는 작업이 아니라, 문제를 측정하고 개선한 결과를 검증하는 과정입니다.

6. LLM 엔지니어에게 RAG 고도화 역량이 중요한 이유

RAG 고도화는 단순히 검색 라이브러리를 추가로 배우는 것과 다릅니다. 문서의 구조와 특성을 이해하고, 임베딩과 검색 알고리즘을 선택하며, LLM의 답변 품질을 평가하는 여러 역량이 함께 필요합니다. 실제 LLM 서비스 개발에서는 검색 성능뿐 아니라 모델 배포, 데이터 처리, 응답 속도와 운영 비용까지 고려해야 하죠.

LLM 엔지니어 관련 채용에서도 RAG 파이프라인 구축, 벡터 데이터베이스 활용, 모델 서빙, LLMOps와 같은 역량이 요구될 수 있습니다. 다만 기업마다 검색 시스템 개발, 모델 학습, 서비스 운영 중 어느 영역에 더 집중하는지는 다릅니다.

그렇다면 RAG 관련 프로젝트 경험을 어떻게 보여주는 것이 좋을까요? 단순히 'LangChain과 벡터 DB로 RAG 챗봇을 구현했다'는 설명보다, 다음과 같은 개선 과정이 드러나면 기술적 판단 역량을 더 구체적으로 보여줄 수 있습니다.

1. 문제 발견: 제품명과 오류 코드에 대한 검색 정확도가 낮다는 문제를 확인

2. 원인 분석: 벡터 검색에서 의미가 비슷한 다른 제품 문서가 상위에 검색되는 현상을 분석

3. 개선 방법 선택: 키워드 검색을 결합한 하이브리드 검색과 재정렬 적용

4. 성능 검증: 동일한 평가 데이터셋으로 개선 전후의 검색 품질, 답변 품질, 응답 시간을 비교

중요한 것은 기술 이름 자체가 아닙니다. 어떤 문제가 있었고, 왜 그 기술을 선택했으며, 결과적으로 무엇이 개선되었는지 설명할 수 있어야 합니다.

이는 LLM 엔지니어뿐 아니라 AI 에이전트나 기업용 검색 서비스를 개발하려는 엔지니어에게도 유용한 실무 역량입니다.

RAG를 구현하는 개발자에서, 성능을 개선하는 LLM 엔지니어로

RAG 시스템을 처음 구현할 때는 문서를 검색하고 LLM으로 답변을 생성하는 것만으로도 의미 있는 결과를 얻을 수 있습니다.

하지만 실제 서비스에서 중요한 것은 그다음입니다. 검색 결과가 부정확할 때 원인을 찾아야 하고, 서비스에 맞는 개선 방법을 선택해야 하며, 변경한 시스템이 실제로 좋아졌는지 검증할 수 있어야 합니다. 이러한 경험을 쌓으려면 기본적인 RAG 구현을 넘어 검색 시스템 설계와 평가, LLM 서비스 운영까지 연결해 보는 과정이 필요합니다.

팀스파르타가 운영하는 AI 캠퍼스 KANT의 LLM 엔지니어 과정에서도 이러한 역량을 단계적으로 학습합니다. 청킹과 문서 임베딩, 벡터 데이터베이스를 활용한 RAG 기초부터 하이브리드 검색, 재정렬, 질문 변환 등 고도화 기법을 배우고, RAG 기반 Q&A 서비스를 직접 구현합니다. 이후에는 LangGraph 기반 AI 에이전트 개발, vLLM을 활용한 모델 서빙, LLMOps와 배포 환경까지 학습 범위를 확장합니다.

총 9개월의 오프라인 교육 과정으로, 실제 비즈니스 데이터를 활용한 실무 프로젝트 5회와 기업 과제 기반 프로젝트 경험을 제공합니다. KDT 국비지원 과정으로 교육비는 전액 지원되며, 개인별 지급 조건에 따라 월 최대 40만 원의 훈련장려금도 받을 수 있습니다.

RAG를 구현하는 수준을 넘어 실제 서비스의 성능을 개선하는 역량을 키우고 싶다면, KANT LLM 엔지니어 과정의 커리큘럼을 살펴보세요.

참고 자료

1. Anthropic Engineering, Introducing Contextual Retrieval (2024)

2. Anthropic Cookbook, Contextual Embeddings Guide

3. Microsoft Research, GraphRAG: Unlocking LLM discovery on narrative private data (2024)

4. Edge et al., From Local to Global: A Graph RAG Approach to Query-Focused Summarization (2024)

5. AWS 기술 블로그, 한국어 Reranker를 활용한 검색 증강 생성(RAG) 성능 올리기 (2024)

6. Yan et al., Corrective Retrieval Augmented Generation (2024)

7. Jeong et al., Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity (2024)