하이브리드·에이전트·그래프, 3단 검색 구조는 왜 표준이 됐나

하이브리드 검색이란 키워드 매칭 기반 검색과 벡터 임베딩 기반 의미 검색을 하나의 파이프라인에서 함께 쓰는 검색 방식을 말합니다. 여기에 복합 질의를 여러 하위 질의로 쪼개 처리하는 에이전트 검색, 그리고 개체 간 관계를 다루는 온톨로지·그래프 기반 검색을 얹은 3단 구조가, 최근 KMS(지식관리시스템) 프로젝트에서 벤더를 가리지 않고 공통적으로 제안되는 표준 패턴으로 자리잡고 있습니다. 이 글에 담은 시나리오는 실제 고객 미팅을 익명화·재구성한 것이라, 2026년 9월 시점 기준으로 특정 회사·고객사의 정보나 계약 수치는 등장하지 않습니다.

[시리즈] S2S·LLM 음성 에이전트 엔지니어링 63편 · 현재 11-3편

← 이전: 11-2 비정형 이력 데이터 지식화의 함정 / 다음 → 11-4 버전관리와 온톨로지의 역할 분담

전체 목차 펼치기 (63편)

Part 1 — 음성 AI가 느린 이유: 레이턴시 진단 (4편)

Part 2 — 텍스트를 넘어: End-to-End S2S의 원리 (4편)

Part 3 — 실시간 대화와 에이전트화: 인터럽트·MCP·도구 (5편)

Part 4 — 인프라·세션·보안: 프로덕션 백엔드 (5편)

Part 5 — 운영·품질·평가: 에이전틱 워크플로우와 신뢰성 (7편)

Part 6 — 음성 경험 고도화·실전 통합: 한국어·UX·전화망·엣지 (5편)

Part 7 — S2S 도입 전략·구매 의사결정 (4편)

Part 8 — LLM 콜봇 PoC 현장 (6편)

Part 9 — 상담어시스트: 상담사 화면을 바꾸는 실시간 AI (7편)

Part 10 — 직접 만든 롤플레이 챗봇: RAG 에이전트 구축기 (8편)

Part 11 — KMS 실무 — 지식관리시스템의 설계와 운영 현실 (8편)

하이브리드 검색 — 일반 문서 검색의 기본값

키워드 검색은 질의어와 문서에 등장하는 단어를 직접 대조해 정확히 일치하거나 유사한 표현을 찾는 방식입니다. 제품 코드나 오류 코드처럼 정확한 용어 매칭이 중요한 질의에 강합니다. 반면 벡터 검색은 질의와 문서를 임베딩으로 변환해 의미상 가까운 문서를 찾는 방식이라, 표현은 달라도 뜻이 비슷한 질문에 강합니다. 두 방식은 서로의 약점을 메워 주는 관계라서, 실제로는 둘을 함께 쓰는 하이브리드 검색이 표준으로 굳어졌습니다. 하이브리드 검색은 전체 질의 중 상당 부분을 차지하는 일반 문서 검색을 담당하는 기본 계층 역할을 합니다. 이 계층을 튜닝할 때 자주 손대는 지점은 키워드 점수와 의미 유사도 점수를 합칠 때의 가중치 비율입니다. 이 비율은 문서 성격이나 질의 패턴에 따라 프로젝트마다 다르게 조정됩니다.

에이전트 검색 — 복합 질의를 쪼개는 지휘관

하이브리드 검색은 한 번의 조회로 답이 나오는 단일 의도 질의에는 잘 맞지만, 여러 조건이 얽힌 복합 질의 앞에서는 한계를 드러냅니다. 이때 등장하는 것이 에이전트 검색입니다. 에이전트 검색은 LLM이 복합 질의를 여러 하위 질의로 분해하고, 각 하위 질의를 개별적으로 조회한 뒤 그 결과를 다시 하나의 답으로 통합하는 방식입니다. 즉 검색엔진 자체가 아니라, 질의를 어떻게 쪼개고 어떤 순서로 풀지를 판단하는 지휘관 역할을 LLM이 맡는 구조입니다. 하이브리드 검색이 "정확한 문서를 찾는" 계층이라면, 에이전트 검색은 "무엇을 어떻게 찾을지 계획하는" 계층에 가깝습니다.

관계형(온톨로지·그래프) 검색 — 하이브리드가 못 푸는 질문

키워드·벡터 검색은 특정 개체를 설명하는 문서를 찾는 데는 강하지만, 개체와 개체 사이의 관계나 차이를 안정적으로 짚어내는 데는 약합니다. 예를 들어 특정 상품의 여러 버전 사이에 무엇이 달라졌는지를 비교하는 질의는, 문서 하나를 찾아서 될 일이 아니라 여러 개체와 속성 사이의 관계를 추적해야 하는 일입니다. 온톨로지·그래프 기반 검색은 개체와 관계를 명시적으로 모델링해 두기 때문에, 이런 비교·관계형 질의를 하이브리드 검색보다 훨씬 정확하게 처리합니다. 그래서 3단 구조에서 그래프 검색은 일반 문서 검색이 아니라, 개체 간 비교·관계를 묻는 질의를 전담하는 계층으로 자리매김합니다.

왜 3단 조합이 표준으로 자리잡았나

그림 1. 세 검색 방식이 각자 독립적으로 결과를 내고, 통합 랭킹 단계에서 하나의 결과 목록으로 합쳐진다.

세 계층을 따로 두는 이유는 각 계층이 잘하는 일과 못하는 일이 뚜렷이 갈리기 때문입니다. 하나의 검색엔진으로 모든 질의를 다 처리하려 하기보다, LLM이 들어온 질의의 성격을 먼저 판단해 어느 계층으로 보낼지 라우팅하는 구조가 반복적으로 제안됩니다. 일반적인 정보 조회 질의는 하이브리드 검색으로, 개체 간 비교나 관계를 묻는 질의는 그래프 검색으로 보내고, 여러 조건이 얽힌 복합 질의는 에이전트 검색이 하위 질의로 쪼개 각 계층에 나눠 보냅니다. 결과적으로 에이전트 계층이 다른 두 계층을 지휘하는 구조가 되며, 이 라우팅 방식이 여러 벤더의 제안서에서 형태만 조금씩 다를 뿐 골격은 동일하게 반복됩니다. 한 엔진이 모든 질의 유형을 떠맡을 때 발생하던 정확도 저하 문제를, 역할을 나누는 방식으로 풀어낸 결과라고 볼 수 있습니다.

청킹과 튜닝의 현실적 감각

구조를 설계하는 것과 별개로, 실제 검색 품질은 문서를 어떻게 쪼개느냐에서 크게 갈립니다. 문서-섹션-문단이라는 원래 구조를 유지한 채 나누는 계층적 청킹은, 조회된 조각이 문맥을 잃지 않도록 하는 데 자주 쓰이는 방식입니다. 문서를 단순히 글자 수 기준으로 자르면 문단 중간이 잘려 의미가 끊기지만, 구조를 유지한 채 자르면 검색 결과가 원문의 맥락을 그대로 담고 나옵니다. 이 밖에도 키워드와 의미 검색 사이의 가중치 비율, GPU 한 장당 동시 처리 가능한 사용자 수 같은 구체적인 벤치마크가 프로젝트마다 언급되지만, 이런 수치는 문서 성격과 하드웨어 구성에 따라 크게 달라지는 참고치일 뿐입니다. 결국 프로젝트마다 실제 데이터와 실제 트래픽으로 다시 검증하는 과정이 필요하다는 점은 어느 사례에서나 공통적으로 확인됩니다.

조직 규모가 커질 때 — 단계적 오픈 전략

이 3단 구조가 소규모 조직에서는 큰 무리 없이 돌아가더라도, 사용자가 수천에서 수만 명 규모로 늘어나면 이야기가 달라집니다. 동시에 접속해 질의를 던지는 인원이 늘어날수록 앞서 언급한 동시 처리 한계에 부딪히기 쉽고, 이 한계는 설계 단계보다 실제 오픈 이후에 체감되는 경우가 많습니다. 그래서 규모가 큰 조직일수록 전체 사용자를 한 번에 오픈하기보다, 일부 조직을 먼저 오픈해 실제 트래픽에서 성능과 품질을 검증한 뒤 나머지 조직으로 단계적으로 확대하는 전략이 거의 필수적으로 따라붙습니다. 이는 선택 사항이 아니라, 조직 규모가 일정 수준을 넘어서는 순간 구조 자체에 내장돼야 하는 전제에 가깝습니다.

3단 검색 구조를 살펴보며 남는 교훈은 다음과 같습니다.

한 엔진이 모든 질의를 떠맡지 않는다. 질의 성격별로 계층을 나누고 LLM이 라우팅하는 구조가, 정확도와 유지보수성 양쪽에서 더 안정적입니다.
청킹은 구조를 지켜야 한다. 문서-섹션-문단 구조를 유지한 계층적 청킹이 검색 결과의 맥락 손실을 줄여 줍니다.
벤치마크 수치는 참고치일 뿐이다. 가중치 비율이나 동시 처리 인원 같은 수치는 프로젝트마다 다시 검증해야 하며, 규모가 커질수록 단계적 오픈이 사실상 필수입니다.

STT 인식률 93%의 함정 — 왜 그 숫자는 콜봇 목표가 될 수 없는가

7월 05, 2026

자세한 내용 보기

이 블로그 검색

AI에이전트엔지니어링