검색 기술은 화려합니다. 새 임베딩 모델, 새 리랭커, 새 RAG 아키텍처가 매주 쏟아집니다. 그런데 정작 고객이 우리에게 묻는 건 “그래서 뭐가 좋아지나요?”입니다. 이 간극을 좁히는 게 우리 팀의 일입니다.
1. 기술이 아니라 문제에서 시작한다
새 프로젝트를 시작할 때 우리는 “어떤 모델을 쓸까”를 먼저 묻지 않습니다. 대신 고객의 어떤 업무가 가장 불편한지, 올해 그 조직의 KPI가 무엇인지부터 확인합니다. 기술 선택은 그 다음입니다.
이 순서를 지키면 자연스럽게 답이 좁혀집니다. 상담사가 약관 문서를 뒤지느라 통화가 길어진다면 검색 품질 문제이고, 여러 문서를 교차 확인해야 답이 나온다면 Agentic RAG의 영역이며, 도면과 사진을 봐야 한다면 Multimodal RAG가 필요합니다.
2. 작게 검증하고, 빠르게 버린다
PoC는 “되는 걸 보여주는 자리”가 아니라 “안 되는 걸 빨리 확인하는 자리”라고 생각합니다. 그래서 2~4주 안에 끝나도록 범위를 자릅니다. 문서 100만 건이 아니라 대표 문서 3천 건, 전체 기능이 아니라 질의 유형 한 가지로 시작합니다.
- 실패 질의부터 모읍니다. 잘 되는 케이스는 데모에 쓰고, 안 되는 케이스에서 배웁니다.
- 기준선을 먼저 만듭니다. 개선 전 숫자가 없으면 개선을 증명할 수 없습니다.
- 한 번에 하나만 바꿉니다. 청킹과 리랭커를 동시에 바꾸면 무엇이 효과였는지 알 수 없습니다.
PoC에서 가장 값진 산출물은 데모 영상이 아니라, 왜 실패했는지 설명할 수 있는 실패 목록입니다. — 팀 회고 중에서
3. 평가 없이 배포하지 않는다
RAG는 한 번 구축하고 끝나는 시스템이 아닙니다. 데이터도, 정책도, 사용자의 질문도 계속 바뀝니다. 그래서 우리는 배포보다 평가 체계를 먼저 만듭니다.
검색 단계는 근거를 제대로 찾았는지(Context Precision·Recall)로, 생성 단계는 답변이 근거에 충실한지(Groundedness)로 나눠 봅니다. 두 단계를 섞어서 보면 “답이 이상하다”는 말만 남고 어디를 고쳐야 할지 알 수 없습니다.
4. 마지막에 기술을 이야기한다
고객 미팅 자료의 순서는 언제나 같습니다. 고객 문제 → 해결 방안 → 실제 사례 → 기술 적용. Hybrid Search나 GraphRAG라는 단어는 마지막 장에서야 등장합니다.
기술을 숨기려는 게 아닙니다. 문제와 성과를 먼저 합의해야, 그 기술이 왜 필요한지 설명할 언어가 생기기 때문입니다. 순서를 뒤집으면 좋은 기술도 “그래서 뭐가 좋아지나요?”라는 질문 앞에서 무너집니다.
정리하며
네 가지 원칙은 결국 하나로 모입니다. 우리는 검색 결과를 보여주는 팀이 아니라, 고객의 결정을 완성하는 팀입니다. 모델의 점수를 0.5점 올리는 일보다, 상담사가 한 통화를 30초 빨리 끝내는 일이 더 어렵고 더 중요합니다.