요즘 RAG(Retrieval-Augmented Generation) 기반 AI Agent를 구축하는 프로젝트가 정말 많습니다. 사내 문서를 검색해 답하는 어시스턴트, 고객 문의를 처리하는 봇, 방대한 기술 문서에서 근거를 찾아주는 에이전트까지. 그런데 이런 프로젝트를 지원하다 보면 거의 같은 질문을 드리게 됩니다. “검색 품질은 어떻게 측정하고 계신가요?” 돌아오는 답은 대개 비슷합니다. “체감상 좋아진 것 같아요.” “몇 개 돌려봤는데 괜찮던데요.” 정작 “검색이 얼마나 […] ||
요즘 RAG(Retrieval-Augmented Generation) 기반 AI Agent를 구축하는 프로젝트가 정말 많습니다. 사내 문서를 검색해 답하는 어시스턴트, 고객 문의를 처리하는 봇, 방대한 기술 문서에서 근거를 찾아주는 에이전트까지. 그런데 이런 프로젝트를 지원하다 보면 거의 같은 질문을 드리게 됩니다. “검색 품질은 어떻게 측정하고 계신가요?”
돌아오는 답은 대개 비슷합니다. “체감상 좋아진 것 같아요.” “몇 개 돌려봤는데 괜찮던데요.” 정작 “검색이 얼마나 좋아졌는지”를 숫자로 확인하는 경우는 드뭅니다. Agent가 이상한 답을 내놓으면 우리는 보통 프롬프트를 손보고, 그래도 안 되면 모델을 바꾸고, 여전히 안 되면 검색 방식을 바꿉니다. 하지만 이 모든 시도가 정말 검색을 개선했는지 판단할 기준이 없습니다.
이 글에서는 Amazon OpenSearch Service와 Amazon Bedrock을 활용해 검색 품질을 정량적으로 측정하는 시스템을 구축한 경험을 공유합니다. 단순히 “이 방식이 좋다”가 아니라, 어떤 지표로 무엇을 측정하고, 그 측정값을 얼마나 믿을 수 있는지 검증하는 과정까지 다룹니다. 그리고 그 과정에서 확인된 함정들도 함께 이야기합니다.
참고로 이 글에서 다루는 실험들은 AI 코딩 어시스턴트를 활용해 진행했습니다. 요즘 Kiro, Codex, Cursor, Claude Code 같은 도구들이 많이 나와 있는데, 인프라 배포부터 평가 스크립트 작성, 실행, 결과 정리까지 이런 도구와 함께 작업하면 훨씬 빠르게 진행할 수 있습니다. 2부에서는 이 AI 도구를 활용한 검색 최적화 자동화와, 운영 환경에서의 지속적인 평가 루프를 본격적으로 다룹니다.
왜 검색 평가가 필요한가
RAG 시스템에서 검색은 전체 품질의 기반입니다. 아무리 뛰어난 LLM을 붙여도, 검색된 문서가 엉뚱하면 답변도 엉뚱해집니다. “쓰레기가 들어가면 쓰레기가 나온다(garbage in, garbage out)”는 격언은 RAG에서 동일하게 적용됩니다. LLM은 주어진 문서를 바탕으로 그럴듯한 문장을 만들어낼 뿐, 검색 단계에서 놓친 정답을 마법처럼 생성하지는 못합니다.
그래서 Agent 답변이 틀렸을 때 우리가 가장 먼저 의심해야 할 것은 모델이 아니라 검색(retrieval)입니다. 그런데 여기서 문제가 생깁니다. 검색 품질을 개선하려면 먼저 측정할 수 있어야 하는데, 대부분의 팀에는 그 측정 도구가 없습니다.
이 질문들에 답하려면 결국 같은 기준으로 여러 방식을 비교할 수 있는 숫자가 필요합니다. 정량적 평가가 없으면 검색 개선은 “느낌으로 운전하기”가 되고, 그 느낌은 대개 마지막으로 확인한 몇 개의 샘플에 좌우됩니다.
Agent의 검색은 사람의 검색과 다르다
한 가지 짚고 넘어갈 게 있습니다. 우리가 평가하려는 건 사람이 직접 쓰는 검색창이 아니라, AI Agent가 내부에서 돌리는 검색입니다. 이 둘은 성격이 꽤 다릅니다.
쿼리를 Agent가 만든다. 사람은 키워드 몇 개를 던지지만, Agent는 사용자 발화를 나름대로 해석해 검색 쿼리를 생성합니다. 때로는 장황하게, 때로는 한 질문을 여러 번 쪼개서 검색합니다. 즉 우리가 통제하지 못하는 쿼리로 검색이 일어납니다.
결과를 사람이 아니라 LLM이 읽는다. 사람은 검색 결과 10개 중 관련 있는 걸 눈으로 골라내지만, Agent는 검색이 데려온 문서를 그대로 LLM 컨텍스트에 넣습니다. 검색이 엉뚱한 문서를 가져오면 LLM이 그걸 근거로 그럴듯한 오답을