검색에 AI 에이전트를 붙였는데, 대부분의 질문은 에이전트로 안 보냅니다

사내 제안서 지식검색 도구의 검색은 고정 파이프라인으로 만들어 두었습니다. 벡터 검색과 그래프 탐색을 함께 돌리는 하이브리드 구조이고, 질문이 들어오면 정해진 순서로 검색해 정해진 형식으로 답을 만듭니다. 같은 질문을 열 번 던지면 열 번 같은 답이 나옵니다. 빠르고, 비용이 일정하고, 결과가 재현됩니다.

이 구조로 대부분의 질문이 처리됐습니다. 남은 것은 소수의 복합 질문이었습니다. 「한 공공 발주처가 최근에 낸 사업들과 우리가 제출한 제안서의 공통 주제를 정리해 달라」 같은 요청은 검색을 한 번 돌려서는 답이 안 나옵니다. 사업을 먼저 찾고, 그 사업에 걸린 문서를 찾고, 그 문서들의 주제를 묶어야 답이 나옵니다.

검색 한 번으로 끝나지 않는 질문이 있었습니다

고정 파이프라인은 검색 한 번을 아주 잘합니다. 대신 「먼저 A를 찾고, 그 결과를 보고 B를 정한다」를 못 합니다. 순서가 미리 박혀 있어서 중간 결과에 따라 다음 행동이 달라지는 질문에는 손을 못 댑니다. 이런 질문에도 결과는 나옵니다. 다만 질문의 절반만 답한 상태로 나옵니다.

그래서 고정 파이프라인 옆에 에이전트 검색을 하나 더 붙였습니다. 함수 호출을 지원하는 LLM에 툴 세 개를 물리고, 어떤 툴을 어떤 순서로 부를지는 모델이 직접 정하게 했습니다.

본문 검색 — 문서 본문에서 질문과 맞닿은 구절을 찾아옵니다

관련 사업 조회 — 특정 사업에 걸린 문서와 이력을 함께 가져옵니다

주제 묶음 요약 — 여러 문서에 흩어진 주제를 묶어 정리합니다

툴이 세 개뿐인데도 조합은 충분히 넓습니다. 사업을 먼저 조회한 뒤 본문 검색으로 내려가고 마지막에 주제를 묶는 경로가 나오고, 본문에서 시작해 사업으로 거슬러 올라가는 경로도 나옵니다. 앞에서 절반만 답하던 질문이 여기서 풀렸습니다.

그렇다고 전부 에이전트로 보내지는 않았습니다

에이전트가 동작하고 나서 자연스럽게 떠오른 선택지는 검색을 전부 에이전트로 통일하는 것이었습니다. 경로가 하나면 코드도 하나고 손볼 곳도 하나입니다. 그런데 그렇게 하면 검색 한 번이면 끝나던 흔한 질문까지 다단계 LLM 호출을 거칩니다.

두 경로를 나란히 놓고 무엇이 달라지는지 적어 봤습니다.

가장 걸린 것은 세 번째 줄이었습니다. 자주 들어오는 질문이 물어볼 때마다 다른 답을 내면 사용자는 그 도구를 믿지 못합니다. 드물게 오는 복합 질문이라면 답의 결이 조금 달라도 넘어갑니다. 흔한 경로일수록 재현성이 무겁게 걸립니다.

요청 플래그 하나로 두 경로를 갈랐습니다

결론은 합치지 않는 쪽이었습니다. 검색 요청에 플래그를 하나 두고, 꺼져 있으면 기존 고정 하이브리드 파이프라인으로, 켜져 있으면 에이전트로 보냅니다. 웹 화면에서는 「다단계 분석」 토글로 노출했습니다. 사용자가 보는 것은 스위치 하나지만 그 뒤로 검색이 통째로 갈립니다.

분기를 자동 판정으로 만들 수도 있었습니다. 질문을 먼저 읽고 복잡도를 매겨 경로를 고르는 방식입니다. 그 판정에 LLM을 한 번 더 태우면 단순 질문이 다시 느려집니다. 판정이 틀리면 고정 경로가 복합 질문을 절반만 답한 채로 내보냅니다. 그래서 첫 버전은 사용자가 직접 켜는 명시적 토글로 갔습니다.

이 방식에도 마찰은 있습니다. 사용자가 자기 질문의 난이도를 스스로 판단해야 합니다. 토글을 안 켠 채 복합 질문을 던지면 반쪽짜리 답을 받습니다. 지금은 그 마찰을 감수하는 대신, 어떤 질문이 어느 경로로 갔는지를 기록으로 쌓고 있습니다.

에이전트가 무엇을 왜 부르는지 화면에 흘렸습니다

에이전트 경로에는 문제가 하나 더 있었습니다. 응답이 늦게 옵니다. 툴을 세 번 부르는 동안 화면은 비어 있습니다. 답이 나온 뒤에도 어떤 근거를 거쳐 그 답이 나왔는지 사용자가 알 방법이 없습니다.

그래서 툴 호출 하나하나를 단계 이벤트로 만들어 큐에 넣고, 별도 스레드에서 화면으로 흘려보냈습니다. 「관련 사업을 조회하는 중」, 「문서 본문에서 근거를 찾는 중」이 순서대로 뜹니다. 기다리는 시간이 같아도 빈 화면을 보는 것과는 다릅니다.

같은 이벤트를 로그로도 남겼습니다. 이쪽이 나중에 더 쓸모가 있었습니다. 에이전트는 같은 질문에도 다른 경로를 탈 수 있어서, 답만 저장하면 왜 그 답이 나왔는지 되짚을 수 없습니다. 툴 선택과 순서를 남겨 두면 「이 질문에서 모델이 사업 조회를 건너뛰었다」까지 확인됩니다.

비결정적인 시스템에 평가와 회귀 테스트를 붙일 자리가 여기입니다. 최종 답변만 비교하면 매번 달라서 테스트가 성립하지 않습니다. 툴 선택 경로를 비교하면 「같은 질문에 예전과 다른 툴을 골랐다」를 잡아낼 수 있습니다.

에이전트는 기본값이 아니라 에스컬레이션입니다

정리하면 이 작업의 핵심은 에이전트를 만든 것이 아니라 언제 켤지를 정한 것이었습니다. 다단계 자율 호출은 유연한 대신 느리고 비싸고 비결정적입니다. 이 셋은 튜닝으로 없앨 수 있는 부작용이 아니라 그 구조에 딸려 오는 성질입니다. 그렇다면 모든 질문에 그 값을 물릴 이유가 없습니다.

도구와 에이전트의 차이를 처음 정리했을 때는 개념 구분에 가까웠습니다. 실제로 붙여 보니 구분보다 어느 쪽을 언제 쓸지가 훨씬 오래 남는 질문이었습니다.

고정 RAG 파이프라인을 지우지 않고 남겨 둔 것도 같은 판단이었습니다. 새 구조를 들일 때 기존 경로를 걷어내면 잘 돌던 흔한 길까지 같이 흔들립니다.

에이전트를 붙이기 전에 확인할 것

지금 안 풀리는 질문이 전체에서 얼마나 되는지 셌는지 — 소수면 분기, 다수면 전면 전환이 답입니다

자주 들어오는 질문에 같은 답이 나와야 하는지 — 그렇다면 그 경로는 고정으로 남깁니다

툴 호출이 늘어날 때 지연과 비용이 어디까지 올라가는지 상한을 정했는지

분기 판정 자체의 비용을 계산했는지 — 자동 판정은 공짜가 아닙니다

에이전트가 어떤 툴을 어떤 순서로 불렀는지 남기고 있는지 — 없으면 회귀 테스트를 붙일 곳이 없습니다

경로가 둘이면 관리할 것도 둘입니다

이 선택에 공짜는 없습니다. 경로가 둘이면 검색 코드도 둘이고, 고칠 일이 생기면 두 군데를 봅니다. 장애가 나면 어느 경로에서 났는지 가리는 단계가 하나 더 붙습니다.

그래도 합치지 않은 이유는 두 경로가 잘하는 것이 다르기 때문입니다. 하나로 합치면 흔한 질문이 비싸지거나, 드문 질문이 안 풀리거나 둘 중 하나로 끝납니다. 지금 감수하는 비용은 코드 두 벌이고, 대신 흔한 경로의 속도와 재현성을 지켰습니다.

다음으로 가능한 것은 자동 라우팅입니다. 다만 순서가 있습니다. 어떤 질문이 어느 경로로 갔고 결과가 어땠는지가 쌓인 뒤에 판정기를 붙입니다. 데이터 없이 판정기를 먼저 만들면 블랙박스가 하나 더 늘어납니다.