WORXPHERE

🤖 Career Agent 개발기 (4) : RAG (Retrieval-Augmented Generation)

RAG는 각 질의에 특화된 컨텍스트를 만들어내는 기술입니다

🚀 들어가며

Career Agent 프로젝트에서 RAG 파이프라인과 벡터 DB 구성은 공통 플랫폼 팀에서 담당해 주셨고, 저희 팀은 OpenSearch 기반의 하이브리드 검색을 활용하는 구조를 설계했습니다.

솔직히 고백하자면, RAG 관련 용어들은 저에게 가장 생소한 영역이었습니다. 리랭킹(Re-ranking)은 어떤 원리로 동작하는지, 하이브리드 검색은 내부적으로 어떻게 이루어지는지 궁금한 것 투성이였습니다. 그래서 이번 편에서는 직접적인 구현 경험보다, 그 과정에서 새롭게 배운 용어와 개념 위주로 정리해 보겠습니다. 저처럼 RAG가 처음인 분들께 작은 이정표가 되었으면 합니다.

🔎 RAG: 에이전트에게 적절한 컨텍스트를 제공하는 기술

Career Agent를 개발하며 마주한 가장 큰 벽은 데이터의 양이었습니다. 에이전트가 수만 건의 채용공고를 참고해 답변해야 하는데, 이 방대한 정보를 프롬프트에 전부 담을 수는 없었기 때문입니다. 결국 각 질의에 꼭 필요한 정보만 골라 컨텍스트를 구성하는 방법이 핵심이며, 여기에는 크게 두 가지 패턴이 있습니다.

• RAG 패턴: 외부 데이터 소스에서 관련 정보를 검색하여 컨텍스트를 구성합니다. 모델의 지식 한계를 보완하고 최신 정보를 반영하는 데 주로 사용됩니다.
• 에이전트 패턴: 웹 검색이나 API 같은 도구를 직접 사용하여 실시간으로 정보를 수집합니다. 단순 정보 전달을 넘어 현실 세계와 상호작용하며 작업을 자동화합니다.

RAG(Retrieval-Augmented Generation)는 한마디로 모델에게 ‘참고서’를 쥐여주는 기술입니다. 사용자가 질문할 때마다 관련 정보만 골라 모델에게 건네줌으로써, 모델의 기억력(컨텍스트 길이) 한계를 극복합니다. 컨텍스트가 너무 길어지면 모델이 엉뚱한 정보에 집중하거나 비용과 지연 시간이 늘어나는 문제가 발생하는데, RAG는 필요한 정보만 콕 집어 전달해 성능과 효율을 동시에 잡습니다.

🏗️ RAG 아키텍처

RAG의 구조는 생각보다 직관적입니다. 정보를 검색하는 검색기와, 검색된 정보를 기반으로 응답을 생성하는 생성 모델. 이 두 가지가 전부입니다. 다만, RAG의 성공은 검색기의 품질에 달려 있으며, 검색기에는 색인화와 질의라는 두 가지 주요 기능이 있습니다.

문서 전체를 그냥 검색하면 컨텍스트가 지나치게 길어질 수 있습니다. 이를 방지하기 위해 문서를 더 관리하기 쉬운 청크(chunk)로 분할합니다. 관련성 높은 데이터 청크를 검색하는 것이 질의의 목표이고, 검색된 청크를 사용자 프롬프트와 합치는 후처리를 거쳐 최종 프롬프트가 생성 모델에 입력됩니다.

📦 청킹: 데이터를 얼마나 잘게 자를 것인가

RAG를 공부하며 처음 생각이 든 질문이 “데이터를 얼마나 잘게 잘라야 하지?”였습니다. 청킹은 긴 문서를 의미 있는 작은 단위로 나누는 전략인데, 데이터를 어떻게 색인화할지는 나중에 어떻게 검색할 것인지에 따라 결정됩니다. 이 청킹 전략 하나가 검색 시스템의 성능에 상당한 영향을 미칩니다.

• 고정 크기 청킹: 글자 수나 토큰 수를 기준으로 동일하게 나눕니다. 구현이 쉽지만 문맥이 중간에 끊길 수 있습니다.
• 중첩 청킹: 고정 크기로 나누되 앞뒤 청크를 10~20% 정도 겹치게 하여 문맥 끊김을 방지합니다.
• 재귀적 문자 청킹: 문단 구분자, 줄바꿈, 공백 순으로 우선순위를 두어 의미 단위가 깨지지 않게 나눕니다. LangChain 등에서 기본으로 추천하는 방식입니다.
• 의미론적 청킹: 문장 간 의미적 유사도를 측정하여 내용이 달라지는 지점을 찾아 나눕니다. 정보 일관성이 가장 높지만 임베딩 연산 비용이 추가됩니다.

청크 크기가 작을수록 더 다양한 정보를 담을 수 있고, 넓은 범위를 검색하는 데 도움이 됩니다. 하지만 너무 작으면 중요한 정보가 손실되고, 벡터 검색 공간이 커져 검색 속도가 느려질 수 있습니다. 청킹은 방대한 데이터를 AI가 소화하기 좋은 크기로 잘라주는 과정입니다. 너무 크게 자르면 비용이 상승하고 노이즈가 늘어나며, 너무 작게 자르면 문맥을 상실합니다.

📄 컨텍스트 검색: 청크에 맥락을 되돌려주기

RAG를 구현할 때 문서를 청크로 자르면, 잘린 조각이 앞뒤 문맥을 잃어버린다는 문제가 있습니다. 예를 들어 “2026년 1분기 매출은 전년 대비 15% 증가했다”라는 청크에 어느 회사인지 정보가 없다면, 검색 엔진은 이 조각을 제대로 매칭하지 못합니다.

컨텍스트 검색(Contextual Retrieval)은 각 청크를 저장하기 전에 해당 청크가 전체 문서에서 어떤 의미를 갖는지 설명을 덧붙이는 기술입니다. LLM이 문서 전체를 먼저 읽고, 각 청크에 “이 조각은 [A 회사]의 [재무 보고서] 중 [매출 현황] 섹션에 해당함”과 같은 짧은 맥락을 생성한 뒤, 원본 청크와 합쳐서 저장합니다. Anthropic의 실험에 따르면 이 방식으로 검색 실패율이 최대 49%까지 감소한다고 합니다.

다만 모든 청크마다 LLM을 호출해야 하므로 초기 인덱싱 비용이 증가합니다. 한 번 저장하면 검색 시에는 추가 비용이 들지 않지만, 덧붙이는 맥락이 너무 길면 원본 데이터의 핵심 의미가 희석될 수 있으므로 적절한 길이 조절이 필요합니다.

🔍 검색 알고리즘: 용어 기반 vs 임베딩 기반

청크를 잘 만들었다면, 이제 그 청크들 중에서 어떤 것을 가져올지 결정해야 합니다. 관련성 점수를 계산하는 방법에 따라 크게 두 가지 접근법이 있습니다.

• 용어 기반 검색(렉시컬 검색): 키워드를 사용하여 검색합니다. 역색인을 활용하는 엘라스틱서치나 BM25가 대표적입니다. 역색인은 책 뒤의 찾아보기처럼 단어를 기준으로 그 단어가 포함된 문서 ID를 저장하는 방식으로, 빠르고 비용이 적지만 의미가 아닌 단어의 형태만으로 관련성을 계산합니다.
• 임베딩 기반 검색(시멘틱 검색): 문서의 의미가 질의와 얼마나 가까운지를 기준으로 순위를 매깁니다. 원본 데이터 청크를 임베딩 벡터로 변환하여 벡터 데이터베이스에 저장하고, 질의 벡터와 유사한 벡터를 찾습니다. 큰 데이터셋에서는 근사 최근접 이웃(ANN) 알고리즘을 사용합니다.

용어 기반 검색은 색인화와 질의 모두에서 일반적으로 임베딩 기반보다 빠르고 비용이 적습니다. 하지만 성능 향상을 위해 조정할 수 있는 요소가 적습니다. 반면 임베딩 기반 검색은 시간이 지나면 상당히 개선되어 더 좋은 성능을 낼 수 있습니다.

🗄️ 벡터 데이터베이스: 의미를 저장하고 검색하는 엔진

임베딩 기반 검색을 이야기하면서 “벡터 데이터베이스에 저장한다”고 했는데, 이 벡터 데이터베이스가 정확히 무엇인지 궁금했습니다.

전통적인 관계형 데이터베이스는 SELECT * FROM jobs WHERE title = '백엔드 개발자'처럼 정확한 일치(exact match)로 검색합니다. 하지만 "서버 엔지니어", "Backend Developer"도 같은 의미라는 것은 이해하지 못합니다. 이 격차를 시맨틱 갭(Semantic Gap)이라 하며, 벡터 데이터베이스는 바로 이 갭을 메우기 위해 등장했습니다.

벡터 임베딩은 텍스트, 이미지, 오디오 같은 비정형 데이터를 고차원 숫자 배열(예: [0.12, -0.34, 0.78, ...])로 변환한 것입니다. 의미가 비슷한 데이터는 벡터 공간에서 가까이 위치하고, 다른 데이터는 멀리 떨어집니다. 벡터 데이터베이스는 이 임베딩 벡터를 저장하고, 유사한 벡터를 빠르게 찾아주는 데 특화된 데이터베이스입니다.

“기존 DB에 벡터 인덱스만 추가하면 되지 않나?”라고 생각할 수 있지만, 단순 벡터 인덱스 라이브러리에는 CRUD 연산, 메타데이터 필터링, 스케일링과 복제, 장애 복구 같은 프로덕션 필수 기능이 없습니다. 벡터 데이터베이스는 벡터 검색의 시맨틱 파워와 데이터베이스의 운영 기능을 결합한 것입니다.

벡터 간 유사도를 측정하는 거리 메트릭도 중요합니다. 코사인 유사도는 벡터의 방향만 비교하여 텍스트 임베딩에 가장 널리 쓰이고, 유클리디안 거리는 직선 거리를 측정하여 이미지 임베딩에 적합하며, 내적(Dot Product)은 추천 시스템의 사용자-아이템 매칭에 자주 활용됩니다.

벡터 데이터베이스의 동작은 크게 세 단계로 나뉩니다.

1단계 — 인덱싱: 수백만 개의 벡터를 하나씩 비교하면 너무 느리기 때문에, 검색 속도를 높이는 인덱싱 알고리즘이 핵심입니다.

• HNSW(Hierarchical Navigable Small World): 벡터들을 계층적 그래프로 연결하여, 상위 레이어에서 대략적 위치를 잡고 하위로 내려가며 정밀 탐색합니다. 속도와 정확도 균형이 뛰어나 가장 널리 사용됩니다.
• IVF(Inverted File Index): 벡터 공간을 여러 클러스터로 나누고, 가까운 클러스터만 탐색합니다. 도서관에서 해당 분류 코너만 찾아가는 것과 비슷합니다.
• PQ(Product Quantization): 고차원 벡터를 압축하여 저장 용량을 90% 이상 줄입니다. 정확도를 약간 희생하는 대신 메모리에 훨씬 더 많은 벡터를 올릴 수 있습니다.
• DiskANN: 1억 개 이상의 대규모 벡터에서 인메모리 인덱스는 수백 GB의 RAM이 필요합니다. DiskANN은 인덱스 대부분을 NVMe SSD에 저장하면서도 2~3ms 수준의 추가 지연만으로 효율적인 검색을 가능하게 합니다.

이 알고리즘들은 모두 근사 최근접 이웃(ANN) 방식으로, 수학적으로 완벽한 결과 대신 약간의 정확도를 포기하고 검색 속도를 극적으로 높이는 전략입니다. 성능 평가 시에는 Recall(재현율)과 Throughput(처리량, QPS)의 트레이드오프가 핵심인데, Recall을 높이려면 더 넓은 범위를 탐색해야 하고 그만큼 처리량은 줄어듭니다.

2단계 — 질의: 사용자의 질의를 동일한 임베딩 모델로 벡터로 변환한 뒤, 인덱스를 탐색하여 가장 유사한 벡터들을 찾습니다. 여기서 중요한 점은 저장할 때와 동일한 임베딩 모델을 사용해야 한다는 것입니다. 서로 다른 모델의 벡터는 같은 공간에 있지 않기 때문에 비교 자체가 무의미합니다.

3단계 — 후처리: 검색된 결과에 메타데이터 필터를 적용하거나 재정렬합니다. Career Agent에서 “서울 지역 백엔드 공고”를 검색할 때, 벡터 유사도로 후보를 뽑되 “지역=서울” 조건을 추가 적용하는 것이 후처리에 해당합니다. (일반적으로는 메타데이터 필터는 후처리에서 적용하는 경우도 있지만, 전처리에서 우선 적용합니다.)

현재 많이 사용되는 벡터 데이터베이스를 정리하면 다음과 같습니다.

• Milvus : 오픈소스이며 무료로 사용 가능. 수십억 규모의 벡터까지 확장할 수 있어 대규모 프로덕션에 적합
• Pinecone : 완전 관리형 클라우드 서비스로 인프라 운영 부담 없이 바로 사용 가능. 다만 비용이 발생하고 벤더 종속성이 있음
• Weaviate : 벡터화 모듈이 내장되어 있어 별도 임베딩 파이프라인 없이도 텍스트를 바로 벡터로 변환·검색 가능
• Qdrant : Rust 기반으로 고성능·저지연 검색에 강점. 필터링과 페이로드 관리 기능도 우수
• ChromaDB : 경량 설계로 로컬 프로토타이핑과 빠른 실험에 적합. 프로덕션 규모에는 한계가 있음
• OpenSearch : 키워드 검색(BM25)과 벡터 검색(k-NN)을 동시에 지원하는 몇 안 되는 엔진 중 하나. 기존 검색 인프라가 있다면 별도 벡터 DB 없이 확장하여 사용 가능

Career Agent에서는 이미 OpenSearch를 사용하고 있었기 때문에, 별도의 벡터 DB를 도입하지 않고 k-NN 플러그인을 활성화하여 기존 인프라를 그대로 활용할 수 있었습니다.

🔀 하이브리드 검색과 리랭킹

하이브리드 검색 + 리랭킹

Q. 그렇다면 둘 중 뭘 써야 할까요?

정답은 “둘 다”입니다. 최근에는 두 방식을 결합하는 하이브리드 검색이 많이 사용됩니다. 먼저 비용이 적은 용어 기반 검색으로 후보군을 추려내고, 비용이 많이 드는 임베딩 검색으로 최상의 결과를 찾는 것이죠.

리랭킹(Re-ranking)은 검색의 정확도를 비약적으로 높여주는 최종 검수 단계입니다. 하이브리드 검색만으로도 단일 검색기보다 나은 결과를 얻을 수 있지만, 후보군이 수백 건이 넘어가면 여전히 노이즈가 많습니다. 리랭킹은 이 후보군을 한 번 더 걸러서 진짜 관련 있는 문서만 모델에 전달하는 역할을 합니다.

Bi-Encoder vs Cross-Encoder

하이브리드 검색과 리랭킹을 이해하려면, 그 뒤에서 동작하는 두 가지 인코딩 방식의 차이를 알아야 합니다.

바이-인코더(Bi-Encoder)는 질의와 문서를 각각 독립적으로 인코딩하여 벡터를 만든 뒤, 코사인 유사도 등으로 비교하는 방식입니다. 핵심은 질의와 문서가 서로의 존재를 모른 채 각각 임베딩된다는 점입니다. 문서 벡터를 사전에 계산하여 인덱싱해 둘 수 있기 때문에, 검색 시에는 질의만 인코딩하면 됩니다. 수백만~수억 건의 문서에서도 밀리초 단위 검색이 가능한 이유입니다.

크로스-인코더(Cross-Encoder)는 질의와 문서를 하나의 입력([CLS] query [SEP] document [SEP])으로 결합하여 모델에 넣고, 관련성 점수를 직접 출력합니다. 질의와 문서의 모든 토큰이 Self-Attention을 통해 상호작용하기 때문에, "백엔드 개발자"와 "서버 엔지니어"처럼 표면적으로 다르지만 의미가 같은 표현도 정확하게 연결합니다.

정확도 차이의 핵심은 정보 병목(Information Bottleneck)에 있습니다. 바이-인코더는 전체 문장을 하나의 고정 벡터(예: 1024차원)로 압축하기 때문에, 아무리 벡터 차원이 높아도 원문의 모든 뉘앙스를 담기 어렵습니다. 반면 크로스-인코더는 원문 토큰들이 직접 만나므로 정보 손실이 적습니다.

결국 바이-인코더는 하이브리드 검색의 Dense Retrieval 축을 담당하고(BM25가 Sparse 축), 크로스-인코더는 리랭킹 전용으로 사용됩니다. 사전 인덱싱이 불가능한 크로스-인코더를 1차 검색에 쓰는 것은 사실상 불가능하기 때문입니다.

다단계 퓨널 (funnel)

실제로 리랭킹 파이프라인은 단계별로 비용과 정밀도의 균형을 맞추는 다단계 퓨널(funnel) 구조로 설계됩니다.

하이브리드 검색 + 리랭킹 + LLM 분석

1차 — 하이브리드 검색으로 후보 추출: 용어 기반 검색과 임베딩 기반 검색을 동시에 실행하여 Top 100 정도의 후보를 빠르게 추려냅니다. 이 단계의 목표는 정밀도보다 재현율(recall), 즉 관련 문서를 빠뜨리지 않는 것입니다. 바이-인코더(Bi-encoder) 방식으로 질의와 문서를 각각 독립적으로 임베딩하기 때문에 속도가 빠르지만, 질의와 문서 간의 세밀한 상호작용은 포착하지 못합니다.

2차 — Cross-encoder 리랭킹: 1차에서 뽑은 후보들을 더 정교한 모델로 다시 점수화합니다. 리랭킹에는 크게 두 가지 접근법이 있습니다.

• Cross-Encoder 리랭킹 — 질의와 문서를 하나의 입력으로 결합하여 토큰 수준에서 상호작용을 분석합니다. “백엔드 개발자”라는 질의와 “서버 엔지니어를 모집합니다”라는 문서가 있을 때, 바이-인코더는 각각을 별도로 임베딩하지만, 크로스-인코더는 둘을 나란히 놓고 의미적 관계를 직접 파악합니다. 모델이 상대적으로 작아(수백MB) 추론 속도가 빠르고, fine-tuning도 비교적 용이합니다. 다만 모든 후보에 대해 개별 추론이 필요하므로, 1차에서 후보를 먼저 좁히는 것이 중요합니다.
• LLM 리랭킹 — RankGPT처럼 LLM에게 문서 목록을 주고 관련성 순으로 정렬하도록 요청하는 방식입니다. fine-tuning 없이도 zero-shot으로 높은 품질의 리랭킹이 가능하고, 복잡한 의미적 뉘앙스 파악에 강합니다. 다만 API 호출 비용과 지연 시간이 크고, 컨텍스트 윈도우 제한으로 한 번에 처리할 수 있는 문서 수에 한계가 있습니다.

어떤 방식이든 리랭킹의 출력은 재정렬된 문서 순서일 뿐, 답변을 생성하지는 않습니다. 본질적으로 검색 품질을 높이는 작업이므로, 검색 서버의 영역에 해당합니다.

리랭킹을 직접 구현할 필요 없이, 이미 상용화된 모델과 서비스들이 있습니다. 대표적인 것들을 간단히 소개하면:

• Cohere Rerank: API 호출 한 번으로 질의와 문서 목록을 보내면 관련성 점수를 반환해 주는 서비스입니다. 별도의 모델 운영 없이 바로 적용할 수 있어 도입 장벽이 낮습니다.
• Jina Reranker / Voyage AI Rerank: 마찬가지로 API 형태로 리랭킹 기능을 제공하며, 다국어 지원이나 특정 도메인에 특화된 모델을 선택할 수 있습니다.
• BGE-reranker / ms-marco-MiniLM: Hugging Face에 공개된 오픈소스 크로스-인코더 모델입니다. 직접 호스팅해야 하지만 커스터마이징이 자유롭고 비용을 통제할 수 있습니다.
• OpenSearch ML 플러그인: OpenSearch 환경이라면 검색 파이프라인 안에서 리랭킹 모델을 바로 통합할 수 있어, 별도의 외부 서비스 호출 없이 처리가 가능합니다.

3차 — LLM 기반 정밀 분석: 크로스-인코더로 좁혀진 Top 10~20개 문서에 대해서만 LLM을 활용합니다. LLM은 단순 유사도를 넘어 질의의 의도와 맥락까지 고려한 판단이 가능합니다. 예를 들어, “성장할 수 있는 환경”이라는 질의에 대해 단순히 “성장”이라는 키워드가 있는 공고가 아니라, 멘토링 프로그램이나 교육 지원 제도를 언급하는 공고를 더 높게 평가할 수 있습니다.

비용이 가장 높기 때문에 소수의 최종 후보에만 적용하는 것이 핵심입니다. 실무에서는 대부분의 RAG 파이프라인이 1차(하이브리드 검색) + 2차(리랭킹)까지만 수행하고, 리랭킹된 결과를 바로 LLM의 컨텍스트에 넣어 답변을 생성합니다.

이처럼 단계가 깊어질수록 비용은 올라가지만 처리 대상은 줄어드는 구조로 설계하면, 전체 비용을 통제하면서도 최종 결과의 품질을 극대화할 수 있습니다. 리랭킹은 모델의 컨텍스트에 맞추거나 입력 토큰 수를 줄이기 위해 검색된 문서 수를 줄여야 할 때 특히 유용합니다.

LLM은 어디에 있는 걸까?

여기서 한 가지 짚고 넘어갈 점이 있습니다. 하이브리드 검색과 리랭킹(LLM Reranking 포함)까지는 검색 서버의 영역입니다. 출력이 “정렬된 문서 목록”이기 때문입니다. 하지만 그 문서를 받아서 사용자에게 답변을 생성하고, 답변의 품질을 검증하는 것은 에이전트 서버의 영역입니다.

저도 처음에 오해했던 부분인데, 에이전트 서버와 RAG 검색 서버가 분리되어 있다면 검색 서버 안에서도 LLM을 돌려야 한다고 생각했습니다. 검색된 청크에 대한 응답 생성까지 검색 서버가 담당하는 것이 자연스러워 보였거든요. 하지만 일반적인 아키텍처에서는 역할이 명확히 나뉩니다.

• 검색 서버 — 하이브리드 검색, 리랭킹(Cross-Encoder 또는 LLM Reranking)을 수행하여 관련성 높은 청크를 정렬·반환
• 에이전트 서버 — 반환된 청크를 바탕으로 LLM이 답변을 생성하고, 답변이 근거에 의해 뒷받침되는지 품질을 검증

같은 LLM을 사용하더라도, 검색 서버에서는 “이 문서들의 순서를 매겨라”(리랭킹)라고 요청하고, 에이전트 서버에서는 “이 문서들을 참고해서 질문에 답해라”(답변 생성)라고 요청합니다. 목적이 다르기 때문에, 자연스럽게 서버도 분리됩니다.

Agentic RAG로의 확장

이 3차 LLM 분석을 더 정교하게 발전시키면, 최근 주목받고 있는 Agentic RAG 패턴으로 이어집니다. 단순히 “검색 → 생성”이라는 일직선 파이프라인이 아니라, 에이전트가 검색 결과를 평가하고 부족하면 질의를 재작성하여 다시 검색하거나, 질문 유형에 따라 벡터 DB·SQL DB·웹 검색 등 서로 다른 데이터 소스를 동적으로 선택하는 구조입니다.

이 방향으로 발전한 대표적인 연구 두 가지를 소개하면:

• CRAG(Corrective RAG) — Yan et al.이 제안한 방식으로, 검색된 문서의 관련성을 경량 평가 모델로 판단합니다. “관련 있음 → 바로 생성”, “관련 없음 → 웹 검색으로 대체”, “애매함 → 둘 다 활용”으로 분기하여, 검색 품질이 낮을 때 자동으로 보정합니다.
• Self-RAG — Asai et al.이 제안한 방식으로, LLM 자체가 reflection token을 학습합니다. “지금 검색이 필요한가?”, “검색 결과가 충분히 관련 있는가?”, “생성한 답변이 근거에 의해 뒷받침되는가?”를 모델 스스로 판단하여, 외부 평가 모델 없이도 자기 교정이 가능합니다.

이런 조건 분기와 반복이 필요한 흐름은 일직선의 체인(chain)으로는 표현하기 어렵습니다. LangGraph 같은 프레임워크가 주목받는 이유가 여기에 있습니다. 상태(state)를 가진 그래프 구조로 “검색 → 평가 → 관련 없으면 질의 재작성 → 재검색”과 같은 순환 흐름을 자연스럽게 구현할 수 있기 때문입니다. 즉, 여러 에이전트를 조합한 멀티 에이전트 구조로 더 정교한 Agentic RAG를 구성할 수 있는 것입니다.

역순위 퓨전(RRF)으로 검색 결과 결합하기

여러 검색기를 동시에 사용해 후보를 가져온 다음, 다양한 순위를 결합하여 최종 순위를 생성할 수 있습니다. 이를 역순위 퓨전(Reciprocal Rank Fusion, RRF)이라 하며, 각 검색기에서 받은 순위를 점수로 변환한 뒤 합산하는 방식입니다.

예를 들어 “백엔드 개발자 서울”이라는 질의에 대해 용어 기반 검색과 임베딩 기반 검색을 동시에 실행했다고 가정해 보겠습니다.

역순위 퓨전 계산법

공고 A는 두 검색기 모두에서 상위권에 등장했기 때문에 최종 1위가 됩니다. 반면 공고 B와 D는 한쪽 검색기에서만 나타났기 때문에 점수가 낮습니다. 이렇게 여러 검색기의 “의견”을 종합하면, 단일 검색기보다 더 균형 잡힌 결과를 얻을 수 있습니다.

✏️ 질의 전략: 좋은 질의를 작성하는 법

Career Agent에서 특히 중요했던 영역입니다. 구직자들의 질문은 대부분 “워라밸 좋은 곳 찾아줘”처럼 추상적이거나, “PD 채용공고”처럼 짧고 모호합니다. 아무리 검색 엔진이 뛰어나도, 질의 자체가 부실하면 좋은 결과를 얻기 어렵습니다. 질의 전략은 이 문제를 해결하는 세 가지 접근법을 포괄합니다.

질의 재작성(Query Rewriting) — 질문을 다듬기

가장 기본적인 전략으로, 투박한 질문을 검색기가 이해하기 좋은 형태로 변환하는 과정입니다.

• 모호함 제거: “그거 어떻게 해?”에서 ‘그거’가 무엇인지 이전 대화 맥락을 파악해 구체적으로 바꿉니다.
• 어휘 불일치 해결: 사용자는 “워라밸 좋은 곳”이라고 했지만 공고에는 “유연근무”, “야근없음”으로 적혀 있을 때 이를 연결합니다.

Career Agent에서도 “워라밸 좋은 공고 찾아줘”라는 추상적 요청을 “야근없음”, “유연근무”, “주 4.5일 근무”와 같은 구체적 키워드로 변환하는 것이 바로 질의 재작성의 적용 사례입니다.

Multi Query — 같은 질문을 여러 관점으로

질의 재작성이 질문을 “다듬는” 것이라면, Multi Query는 하나의 질문을 여러 관점으로 확장하는 전략입니다.

예를 들어 “성장할 수 있는 회사 추천해줘”라는 질의가 들어오면:

• “교육 지원 제도가 있는 회사”
• “멘토링 프로그램 운영하는 기업”
• “사내 스터디 활성화된 회사”

이렇게 세 가지 질의로 변환하여 별도로 검색합니다. 사용자가 “성장”이라고 했을 때 채용공고에는 “교육”, “멘토링”, “스터디” 등 다양한 표현으로 적혀 있을 수 있기 때문에, 하나의 표현으로는 놓칠 수 있는 문서를 여러 관점에서 잡아내는 것이 목적입니다. 각 질의가 독립적이므로 병렬 실행이 가능하고, 재현율(recall)을 높이는 데 효과적입니다.

Decomposition — 복잡한 질문을 나눠서 해결

Multi Query와 비슷해 보이지만, 핵심 차이는 같은 의미를 다르게 표현하는 것이 아니라 질문 자체를 다른 하위 질문으로 분해한다는 점입니다. “서울에서 백엔드 개발자로 3년 경력이면 연봉이 얼마나 되고, 성장 가능성이 좋은 회사는 어디야?”라는 질문이 들어왔다고 가정해 보겠습니다. 이 질문 하나로는 검색기가 어떤 정보를 찾아야 할지 모호합니다.

이를 분해하면:

1. “서울 백엔드 개발자 3년 경력 평균 연봉은?” → 검색 → 답변
2. “서울 백엔드 성장 가능성 좋은 회사는?” → 검색 → 답변
3. 1번과 2번 결과를 종합하여 최종 답변 생성

하위 질문 간에 의존 관계가 있을 수 있어 순차 실행이 필요한 경우도 있고, 최종적으로 여러 답변을 종합하는 단계가 추가됩니다. 그래서 Decomposition은 단순한 질의 전략보다는 앞서 소개한 Agentic RAG의 영역에 더 가깝습니다. 에이전트가 질문을 분해하고, 단계적으로 정보를 수집하여, 최종 답변을 조합하는 흐름이니까요.

👋 마지막으로

RAG는 처음 접하면 개념 자체가 어렵게 느껴질 수 있지만, 결국 핵심은 “에이전트가 필요한 정보를 필요한 순간에 찾을 수 있게 해주는 것”입니다. 청킹 전략, 검색 알고리즘, 질의 재작성 등 세부적인 결정 하나하나가 검색 품질에 직접적인 영향을 미치기 때문에, 시간을 들여 실험하고 최적의 조합을 찾는 과정이 중요합니다.

사실 이번 글에서 다룬 내용은 RAG라는 넓은 생태계의 극히 일부에 불과합니다. Neo4j 같은 그래프 데이터베이스를 활용해 엔티티 간 관계를 기반으로 검색하는 GraphRAG, 벡터 DB의 차원 수와 인덱싱 전략에 따른 성능 튜닝, 어떤 임베딩 모델을 선택하느냐에 따라 달라지는 검색 품질 등 고려할 수 있는 기술과 선택지가 정말 많습니다.

짧은 프로젝트 기간 안에서 이 모든 것을 깊이 있게 탐구하기는 어려웠지만, RAG의 개념을 이해하고 하이브리드 검색까지 구현해 볼 수 있었던 것만으로도 의미 있는 경험이었습니다. 앞으로 리랭킹도 적용해 보면서 검색 품질을 더욱 개선해 나갈 예정입니다.