에이전트 중심의 AX가 본격화되고 있습니다. 이런 흐름 속에서 데이터의 중요성이 부각되고 있는데요. 더불어 가치를 새롭게 조명받는 것이 있습니다.
바로 검색입니다. 에이전트는 사용자의 질문에 답하기 위해서만 정보를 찾지 않습니다. 검색 결과를 근거로 다음 작업을 계획하고 필요한 정보를 확인해 가며 업무를 이어 갑니다. 이 과정에서 검색 결과가 부정확하거나 오래된 정보를 담고 있다면 에이전트의 판단과 행동에 영향을 줄 수 있습니다.
그렇다면 기업은 에이전트 운영을 위해 검색 정확도와 데이터 최신성을 어떻게 함께 보장할 수 있을까요?
오랜 기간 사용해 온 엔터프라이즈 검색 엔진만으로는 부족합니다. 에이전트의 특성에 맞는 수단이 필요합니다.
이번 포스팅에서는 에이전트 시대에 검색이 다시 중요해진 배경과 기존 검색 엔진의 한계를 짚어 보고 이를 AlloyDB와 Cloud SQL의 하이브리드 검색으로 어떻게 극복할 수 있는지 알아보겠습니다.
답을 잘 만드는 에이전트보다 근거를 잘 찾는 에이전트
생성형 AI가 등장한 뒤 기업의 관심은 한동안 RAG에 쏠려 있었습니다. 질문을 벡터로 바꾸고 관련 문서 내용을 참조할 수 있으면 충분하다고 보던 시절이 있었습니다.
2026년은 상황이 완전히 다릅니다. AX 전략의 핵심으로 에이전트가 떠오르면서 검색의 중요성이 커졌습니다. 이유는 단순합니다. 에이전트는 질문에 답하는 데서 멈추지 않고 작업을 이어 가기 위한 행동까지 결정합니다. 이때 중요한 것은 필요한 근거를 정확히 찾아오는 능력입니다.
에이전트가 찾는 대상도 다양합니다. 에이전트는 문서 외에도 상품 코드, 오류 번호, 계약 조항, 고객명, 날짜, 수량처럼 한 글자만 달라도 의미가 바뀌는 정보를 작업 과정에서 다룹니다. 벡터 검색은 표현이 달라도 의미가 비슷한 정보를 찾는 데 강하지만, 정확한 키워드나 낯선 용어를 반드시 찾아야 하는 상황에서는 부족할 수 있습니다. 반대로 키워드 검색만 사용하면 사용자의 의도와 문맥을 놓치기 쉽습니다. 에이전트가 신뢰할 만한 답을 만들려면 의미와 단어를 함께 봐야 합니다. 하이브리드 검색이 주목받는 이유입니다.
별도의 검색 엔진이 에이전틱 AI에서 부담이 되는 이유
그동안 많은 조직이 Elasticsearch나 OpenSearch 같은 엔터프라이즈 검색 엔진을 운영 데이터베이스 옆에 따로 구축하는 방식을 택했습니다. 이 방식은 대규모 로그 분석이나 검색 전용 워크로드에서 여전히 유용합니다. 하지만 에이전트를 기준으로 보면 몇 가지 한계가 있습니다.
먼저 데이터 동기화입니다. 데이터베이스의 변경 사항을 검색 엔진에 옮기려면 CDC나 ETL 파이프라인으로 데이터를 복제해야 합니다. 이때 복제 지연이나 파이프라인 오류가 생기면 에이전트는 최신 상태가 아닌 데이터를 근거로 판단을 내릴 수 있습니다. 방금 바뀐 데이터가 아니라 오래된 결과를 믿고 다음 행동으로 넘어갈 수 있는 것이죠.
운영 대상도 늘어납니다. 데이터베이스와 검색 클러스터의 용량, 장애, 백업, 접근 권한, 스키마와 인덱스를 각각 관리해야 합니다. 같은 데이터가 두 시스템에 존재하면 보안 정책과 감사 범위도 넓어집니다. 벡터 저장소까지 따로 두면 데이터 흐름은 더 복잡해집니다.
물론 기존 엔터프라이즈 검색 엔진이 필요 없다는 것은 아닙니다. 로그 분석, 대규모 검색 포털, 복잡한 검색 분석처럼 검색 엔진 자체가 중심인 워크로드에는 엔터프라이즈 검색 엔진이 잘 맞습니다. 다만 트랜잭션 데이터와 검색 결과 사이의 최신성이 중요하고, 에이전트가 검색으로 찾은 최신 정보로 업무를 실행해야 한다면 데이터 이동을 최소화하는 구조를 갖춰야 합니다. 관리형 데이터베이스 안에서 검색을 함께 처리하면 이런 구조를 한결 쉽게 갖출 수 있습니다.
AlloyDB와 Cloud SQL 안에서 만나는 BM25와 벡터 검색
구글 클라우드는 AlloyDB와 Cloud SQL for PostgreSQL 안에서 벡터 검색과 BM25 기반 전문 검색을 함께 활용하는 방향을 제시합니다. 본론에 들어가기에 앞서 BM25를 간단히 소개하겠습니다. BM25는 주요 전문 검색 엔진이 널리 사용하는 업계 표준 순위 알고리즘입니다.
BM25는 단어가 문서에 얼마나 자주 등장하는지, 전체 문서에서 그 단어가 얼마나 희귀한지, 문서 길이는 어느 정도인지를 함께 계산해 관련도를 매깁니다. 긴 문서가 같은 단어를 반복했다는 이유만으로 짧고 정확한 문서보다 높은 순위를 차지하는 문제를 줄입니다.
구글 클라우드는 Tiger Data가 만든 pg_textsearch 확장으로 AlloyDB와 Cloud SQL for PostgreSQL에서 BM25를 지원합니다. 참고로 Cloud SQL for PostgreSQL에서는 정식 출시(GA) 기능으로 AlloyDB에서는 프리뷰(Preview) 기능으로 제공하며 두 서비스 모두 PostgreSQL 17 이상이 필요합니다.
BM25 기반 전문 검색에 벡터 검색을 결합하면 키워드의 정확성과 문맥의 유사성을 함께 반영할 수 있습니다. 특히 AlloyDB는 ScaNN 인덱스로 대규모 벡터 검색을 빠르게 처리하고, 컬럼형 엔진으로 HNSW 벡터 검색도 가속합니다. 개발자는 하나의 PostgreSQL 환경에서 구조화된 조건 검색과 의미 기반 벡터 검색, BM25 전문 검색을 목적에 맞게 조합할 수 있습니다.
두 검색 방식의 장점을 함께 활용하려면 각각의 검색 결과를 하나의 순위로 통합해야 합니다. 벡터 검색과 BM25 전문 검색에서 각각 상위 결과를 추출한 뒤 상호 순위 결합(Reciprocal Rank Fusion, RRF)을 적용하면 서로 다른 점수 체계를 따로 보정하지 않고도 결과의 순위를 통합할 수 있습니다. 여기에 SQL의 권한과 트랜잭션 조건을 더하면 “의미가 비슷한 문서 가운데 현재 판매 중이며 해당 지역에 배송할 수 있는 상품만 제시하라”와 같은 요구도 하나의 작업 흐름에서 처리할 수 있습니다.
이 구조의 가치는 검색 기능을 하나 더 추가했다는 데 그치지 않습니다. 에이전트가 답변의 근거로 활용하는 정보와 실제 업무 데이터 사이의 거리를 줄였다는 데 있습니다. 최신 데이터와 검색 기능, 접근 권한, 트랜잭션을 한곳에서 관리하면 에이전트가 어떤 근거로 결과를 제시했는지 추적하기 쉬워집니다. 별도의 검색 시스템과 데이터 동기화 구조를 줄일 수 있어 애플리케이션 구성도 단순해집니다.
하이브리드 검색 도입 팁
하이브리드 검색 적용을 고려할 때는 기술부터 고르기보다 질문의 유형부터 나눠야 합니다. 상품 코드와 법률 조항처럼 정확한 일치가 중요한 질문, 표현은 달라도 의미를 찾아야 하는 질문, 최신 재고와 권한 조건을 함께 확인해야 하는 질문을 구분해야 합니다. 그다음 BM25와 벡터 검색의 비중, 후보 문서 수, RRF 방식, 재정렬 모델 적용 여부를 평가 데이터로 조정해야 합니다.
한국어 검색에서는 형태소와 복합 명사, 띄어쓰기 변형도 함께 살펴야 합니다. PostgreSQL 기본 텍스트 검색 설정에는 한국어 형태소 분석 설정이 없으므로 토큰화 방식을 따로 검증해야 합니다. 기본 설정만으로 품질을 판단하지 말고 실제 고객 질문과 정답 문서를 묶은 평가 세트를 만들어 검색 누락률과 상위 결과의 정확도를 확인하는 것이 좋습니다. 에이전트의 답변 평가와 검색 평가를 분리하면 모델 문제와 검색 문제도 빠르게 가려낼 수 있습니다.
모든 검색 워크로드를 데이터베이스 안으로 옮길 필요는 없습니다. 먼저 검색 결과가 트랜잭션 데이터와 얼마나 가까워야 하는지, 별도 인덱스의 운영 부담이 어느 정도인지, 정확한 키워드와 의미 검색을 어떤 비중으로 결합할지 확인해야 합니다.
AX를 위한 검색 아키텍처 개선을 원한다면?
에이전트의 답변이나 작업 결과물의 품질은 모델이 아니라 근거에서 갈립니다. 근거를 만드는 일이 검색입니다. 지금 물어야 할 질문은 분명합니다. 우리 에이전트는 어떤 데이터를 근거로 삼는가, 그 데이터는 조회 시점에 최신인가, 의미 검색과 키워드 검색을 한 번에 다루고 있는가입니다. 기존 PostgreSQL 데이터를 기반으로 검색 구조를 단순화하고 에이전트가 더 정확한 근거를 찾게 하고 싶다면 메가존소프트 문의 포털을 통해 상담을 신청해 주세요.
