최근의 RAG 논의는 여전히 검색기의 종류, 임베딩 모델, reranker 성능에 집중되는 경우가 많다. 물론 검색 품질은 중요하다. 하지만 기업 내부 문서, 법령, 규정, 기술 매뉴얼처럼 실패 비용이 큰 도메인에서는 검색 품질 하나만으로 제품이 되지 않는다. 실제 현장에서 더 큰 문제는 검색 이후의 상태 전이, 근거 추적, 실패 감지, 그리고 사용자에게 설명 가능한 복구 흐름이다.
내가 엔터프라이즈 AI 지식 관리 시스템을 만들며 배운 가장 큰 교훈은 단순하다. Agentic RAG는 검색 파이프라인이 아니라 운영 시스템이다. 사용자는 답변을 구매하는 것이 아니라 반복 가능한 업무 흐름, 오류를 확인할 수 있는 증거, 그리고 조직 안에서 신뢰받을 수 있는 자동화 단위를 기대한다.
검색 모드는 제품의 언어가 되어야 한다
하이브리드 검색, 그래프 탐색, 다중 쿼리, rank fusion은 내부 구현 용어로 남겨둘 수도 있다. 하지만 제품에서는 이 선택이 사용자의 작업 방식과 연결되어야 한다. 규정을 찾는 사람, 사고 원인을 분석하는 사람, 조치 계획을 쓰는 사람은 서로 다른 검색 깊이와 근거 형태를 필요로 한다. 그래서 검색 모드는 모델 옵션이 아니라 업무 모드가 되어야 한다.
좋은 RAG 제품은 답을 빨리 내는 시스템이 아니라, 왜 그 답에 도달했는지 운영자가 다시 걸어갈 수 있는 시스템이다.
이 관점에서 멀티 에이전트는 화려한 자동화 장치가 아니다. 역할을 나누고, 각 단계의 입력과 출력을 저장하고, 어떤 노드에서 품질이 떨어졌는지 관찰하기 위한 구조다. 검색 에이전트, 분석 에이전트, 대책 수립 에이전트, 검증 에이전트를 나누는 이유도 에이전트가 많아 보여서가 아니라 장애 지점을 좁히기 위해서다.
관찰성은 나중에 붙이는 로그가 아니다
LLM 관찰성은 출시 직전에 붙이는 대시보드가 아니다. 검색 모드별 tracing, 에이전트 노드별 latency, LLM 호출 비용, retrieved context의 문서 출처, fallback 발생 횟수는 설계 초기에 데이터 모델로 들어가야 한다. 이 정보가 없으면 품질 이슈가 발생했을 때 운영자는 모델 문제인지, 검색 문제인지, 청킹 문제인지, 프롬프트 문제인지 판단할 수 없다.
제품화 단계에서 봐야 할 체크리스트
RAG가 데모에서 제품으로 이동할 때는 모델 정확도보다 운영 체크리스트가 먼저 필요하다. 특히 폐쇄망이나 산업 도메인에서는 다음 질문에 답하지 못하면 기능이 좋아도 도입이 막힌다.
- 검색 결과와 생성 답변 사이의 근거 연결을 저장하고 다시 보여줄 수 있는가.
- 에이전트 노드별 실패를 개별적으로 재실행하거나 우회할 수 있는가.
- 문서 갱신, 청킹 변경, 임베딩 재생성 시 기존 결과와 비교할 기준이 있는가.
- 사용자가 신뢰하지 않는 답변을 신고했을 때 원인 분석에 필요한 로그가 남는가.
현장형 AI 시스템에서 그럴듯함은 초기 데모를 통과시키지만, 추적 가능함이 장기 운영을 통과시킨다.
이 블로그의 역할
이 블로그는 경력 소개 페이지이면서 동시에 이런 운영 관점을 정리하는 개인 기술 저널이다. README의 수상과 프로젝트를 단순히 나열하는 대신, 어떤 문제를 어떤 구조로 풀었는지 기록한다. 트렌드 글도 뉴스 요약보다 한 단계 더 들어가서, 실제 제품과 연구 플랫폼에 적용할 때 무엇이 바뀌는지 설명하는 방식이 어울린다.
앞으로 업로드할 Markdown 글은 이러한 구조를 그대로 따르면 된다. frontmatter에는 제목, 날짜, 태그, 요약을 넣고, 본문에는 문제 정의, 아키텍처 관점, 구현상의 함정, 운영 체크리스트를 둔다. 그러면 블로그는 단순 아카이브가 아니라 AI 엔지니어로서의 판단 과정을 보여주는 공개 노트가 된다.