핵심 요약
최근 공공기관에서 AI 시스템 도입이 활발해지면서 Agentic RAG 구축에 대한 관심이 높아지고 있습니다. 기존 RAG 시스템과 달리 에이전트가 자율적으로 판단하고 검색하는 Agentic RAG는 청크 단위 임베딩 시 메타데이터를 체계적으로 설계하는 것이 핵심입니다. 문서 출처, 생성일자, 부서정보, 보안등급 같은 메타데이터를 적절히 구조화하면 에이전트가 더욱 정확한 질의 검색을 수행할 수 있습니다. 특히 공공기관 특성상 문서 관리와 보안이 중요하기 때문에 메타데이터 설계부터 신중하게 접근해야 합니다.
요즘 공공기관 담당자분들과 이야기하다 보면 가장 많이 듣는 질문이 있습니다. “RAG 시스템은 구축했는데, 왜 우리가 원하는 답변이 안 나올까요?” 이 질문 뒤에는 단순히 문서를 벡터화해서 저장하면 끝이라고 생각했던 초기 설계의 아쉬움이 숨어있습니다.
사실 RAG 시스템 구축은 생각보다 훨씬 섬세한 작업입니다. 특히 공공기관처럼 방대한 문서를 다루고, 정확성이 생명인 환경에서는 더욱 그렇습니다. 그냥 문서를 쪼개서 넣는 것과 제대로 설계해서 넣는 것의 차이는 실제 사용 단계에서 극명하게 드러납니다.
오늘은 그중에서도 가장 진화된 형태인 Agentic RAG를 어떻게 설계하고 구축하는지, 특히 청크별 임베딩할 때 메타데이터를 어떻게 관리하고 에이전트가 어떻게 질의 검색을 수행하는지 실전 경험을 바탕으로 상세히 풀어보겠습니다.
Agentic RAG가 뭔가요
일반 RAG와 Agentic RAG의 차이를 이해하는 것부터 시작해야 합니다. 기존 RAG는 사용자가 질문을 던지면 그 질문과 유사한 문서 조각을 찾아서 답변을 생성하는 단순한 구조였습니다. 마치 도서관에서 키워드로 책을 찾는 것과 비슷하죠.
하지만 Agentic RAG는 완전히 다릅니다. 에이전트가 스스로 판단하고, 필요한 정보를 찾기 위해 여러 단계의 검색을 수행하며, 때로는 검색 전략을 바꾸기도 합니다. 마치 숙련된 사서가 질문자의 의도를 파악하고 여러 자료를 종합해서 최적의 답을 찾아주는 것과 같습니다.
공공기관에서 이런 시스템이 중요한 이유는 명확합니다. 민원인이나 내부 직원이 던지는 질문은 단순하지 않습니다. “지난달에 개정된 조례 중에서 우리 부서 업무와 관련된 내용이 뭐예요?”처럼 시간, 문서 종류, 담당 부서가 모두 얽혀있는 복잡한 질의가 대부분입니다.
청크 임베딩 설계의 시작점
본격적인 구축에 앞서 가장 먼저 고민해야 할 부분이 바로 청크 크기입니다. 많은 분들이 “512토큰이 좋다더라”, “1024토큰으로 해야 한다더라” 하며 정답을 찾으려 하는데, 사실 정답은 여러분이 다루는 문서의 특성에 있습니다.
공공기관 문서는 대체로 두 가지 패턴으로 나뉩니다. 법령이나 조례처럼 조문 단위로 명확하게 구분되는 구조적 문서가 있고, 회의록이나 보고서처럼 자유로운 형식의 비구조적 문서가 있습니다. 구조적 문서는 의미 단위로 청크를 나누는 것이 효과적입니다. 예를 들어 조례라면 각 조항이 하나의 청크가 되는 식이죠. 반면 비구조적 문서는 문맥을 유지하면서 적절한 크기로 나누는 것이 중요합니다.
실제 프로젝트에서 경험한 바로는 공공기관의 경우 평균 800토큰 정도의 청크 크기가 적절했습니다. 너무 작으면 문맥이 끊기고, 너무 크면 검색 정확도가 떨어집니다. 다만 이건 평균일 뿐이고, 문서 종류에 따라 유연하게 조정해야 합니다.
여기서 중요한 건 청크를 나눌 때 오버랩을 두는 것입니다. 앞 청크의 마지막 100토큰과 다음 청크의 처음 100토큰이 겹치게 하면 문맥 단절을 막을 수 있습니다. 특히 법령 해석이나 정책 설명처럼 앞뒤 맥락이 중요한 경우 이 오버랩 설정이 답변 품질을 크게 좌우합니다.
메타데이터 설계가 성패를 가른다
이제 가장 핵심적인 부분입니다. 청크별 임베딩을 할 때 메타데이터를 어떻게 설계하느냐가 Agentic RAG의 성능을 결정합니다. 많은 프로젝트가 실패하는 이유도 바로 이 메타데이터 설계를 소홀히 했기 때문입니다.
공공기관에서 반드시 포함해야 할 메타데이터 항목들을 살펴보겠습니다. 먼저 문서 식별 정보입니다. 문서번호, 문서명, 문서 종류는 기본이고, 원본 문서의 파일 경로나 URL도 함께 저장해야 합니다. 나중에 출처를 추적하거나 원문을 확인해야 할 때 필수적입니다.
시간 정보도 매우 중요합니다. 문서 생성일, 최종 수정일, 시행일을 모두 별도로 저장해야 합니다. 예를 들어 조례의 경우 공포일과 시행일이 다를 수 있는데, 사용자가 “현재 시행 중인 조례”를 물었을 때 시행일 기준으로 필터링할 수 있어야 합니다.
조직 정보는 공공기관 특성상 특히 중요합니다. 작성 부서, 담당 부서, 협조 부서를 구분해서 저장하면 에이전트가 “우리 부서 관련 문서만” 검색할 수 있습니다. 실제로 직원들은 자기 부서 업무와 관련된 정보를 주로 찾기 때문에 이 메타데이터가 검색 효율을 크게 높입니다.
보안등급과 열람권한 정보는 공공기관에서 절대 빠뜨릴 수 없습니다. 일반, 대외비, 비밀 같은 보안등급뿐만 아니라 열람 가능한 직급이나 부서 정보도 함께 저장해야 합니다. 에이전트가 검색할 때 사용자의 권한을 자동으로 체크하도록 설계하면 보안 사고를 예방할 수 있습니다.
문서 위치 정보도 세밀하게 저장해야 합니다. 원본 문서에서 해당 청크가 몇 페이지의 몇 번째 단락인지, 제목이나 소제목이 무엇인지 기록하면 답변의 정확성이 올라갑니다. 특히 긴 보고서에서 특정 부분을 찾을 때 이런 위치 정보가 결정적입니다.
실제 메타데이터 구조를 보면 이런 식입니다. 각 청크마다 문서ID, 청크ID, 원본제목, 문서종류, 생성일자, 시행일자, 작성부서, 담당부서, 보안등급, 페이지번호, 단락번호, 소제목, 파일경로 같은 필드가 JSON 형태로 저장됩니다. 처음에는 번거로워 보이지만 이렇게 세밀하게 설계해 놓으면 나중에 에이전트가 훨씬 똑똑하게 검색할 수 있습니다.
벡터 데이터베이스 선택과 인덱싱
메타데이터 설계가 끝났다면 이제 이걸 어디에 저장할지 결정해야 합니다. 벡터 데이터베이스 선택은 프로젝트 규모와 예산에 따라 달라지는데, 공공기관의 경우 온프레미스 구축이 가능한지가 중요한 판단 기준입니다.
보안이 최우선인 공공기관이라면 자체 서버에 구축할 수 있는 벡터DB를 선택해야 합니다. 이런 경우 Milvus나 Weaviate 같은 오픈소스 솔루션이 적합합니다. 반면 클라우드 사용이 허용되는 기관이라면 Pinecone이나 Qdrant 같은 매니지드 서비스도 고려할 수 있습니다.
중요한 건 단순히 벡터 검색만 지원하는 게 아니라 메타데이터 필터링이 강력한 제품을 선택하는 것입니다. Agentic RAG에서는 벡터 유사도 검색과 메타데이터 필터링을 조합해서 사용하기 때문에 두 기능이 모두 빨라야 합니다.
인덱싱 전략도 신중하게 결정해야 합니다. 메타데이터 필드 중에서 자주 검색되는 항목은 별도 인덱스를 생성해야 합니다. 날짜 필드, 부서 코드, 문서 종류 같은 건 거의 모든 검색에서 사용되니까 인덱싱 필수입니다. 반면 파일 경로처럼 결과 표시용으로만 쓰이는 필드는 굳이 인덱싱할 필요가 없습니다.
에이전트 설계의 핵심 원리
이제 본격적으로 에이전트를 설계할 차례입니다. Agentic RAG의 에이전트는 크게 세 가지 역할을 수행합니다. 질의 이해, 검색 전략 수립, 검색 실행 및 결과 종합입니다.
질의 이해 단계에서 에이전트는 사용자 질문을 분석해서 핵심 의도를 파악합니다. “지난달 시행된 조례 중에서 복지과 업무 관련된 거 알려줘”라는 질문이 들어오면 에이전트는 시간조건이 있고, 문서종류는 조례이며, 특정 부서로 필터링해야 한다는 걸 인식합니다.
검색 전략 수립 단계가 Agentic RAG의 진짜 강점입니다. 에이전트는 질의 복잡도에 따라 검색 전략을 달리 가져갑니다. 단순 질문이면 한 번의 벡터 검색으로 끝내고, 복잡한 질문이면 여러 단계로 나눠서 검색합니다.
예를 들어 “작년 우리 부서 예산 대비 올해 증감 현황과 내년 계획을 비교해줘”라는 복잡한 질문이 들어오면 에이전트는 세 번의 검색을 계획합니다. 먼저 작년 예산 문서 검색, 다음으로 올해 예산 문서 검색, 마지막으로 내년 계획 문서 검색입니다. 각 검색마다 시간 메타데이터를 다르게 설정하고 결과를 종합합니다.
질의 검색 실행 메커니즘
에이전트가 실제로 검색을 수행하는 과정을 상세히 들여다보겠습니다. 일반적인 검색 흐름은 이렇습니다. 먼저 사용자 질문을 임베딩 벡터로 변환합니다. 이때 질문 텍스트뿐만 아니라 에이전트가 파악한 의도도 함께 고려해서 더 정확한 벡터를 만듭니다.
다음으로 메타데이터 필터 조건을 구성합니다. 시간, 부서, 문서종류, 보안등급 같은 조건을 AND 조건으로 연결해서 쿼리를 만듭니다. 이 단계에서 사용자의 권한 체크도 자동으로 이뤄집니다. 만약 사용자가 대외비 문서를 볼 권한이 없다면 보안등급 필터에 일반 문서만 포함되도록 설정합니다.
벡터 검색과 메타데이터 필터링을 동시에 실행합니다. 최신 벡터DB들은 이 두 작업을 하나의 쿼리로 처리할 수 있어서 성능이 좋습니다. 유사도 점수가 높은 상위 결과를 가져오되, 메타데이터 조건을 만족하는 것만 필터링됩니다.
검색 결과의 품질을 에이전트가 스스로 평가합니다. 만약 결과가 부족하거나 품질이 낮다고 판단되면 검색 전략을 수정합니다. 예를 들어 메타데이터 필터 조건을 완화하거나, 검색어를 바꾸거나, 검색 범위를 확대하는 식입니다.
여러 번의 검색 결과를 종합할 때도 에이전트의 역할이 중요합니다. 단순히 결과를 나열하는 게 아니라 각 결과의 신뢰도, 최신성, 관련성을 종합적으로 고려해서 최종 답변을 구성합니다. 상충되는 정보가 있으면 더 최신 문서나 공식 문서를 우선합니다.
하이브리드 검색 전략
Agentic RAG를 더욱 강력하게 만드는 비법은 하이브리드 검색입니다. 벡터 검색만으로는 한계가 있습니다. 예를 들어 “2024-0123″처럼 정확한 문서번호나 “제3조의2″처럼 특정 조항을 찾을 때는 키워드 검색이 훨씬 효과적입니다.
그래서 실전에서는 벡터 검색과 키워드 검색을 함께 사용합니다. 에이전트가 질의를 분석해서 정확한 용어나 번호가 포함되어 있으면 키워드 검색 비중을 높이고, 의미적 이해가 필요한 질문이면 벡터 검색 비중을 높입니다.
두 검색 결과를 합칠 때는 RRF나 가중치 기반 방식을 사용합니다. 각 방식마다 장단점이 있는데, 공공기관처럼 정확성이 중요한 환경에서는 정확히 일치하는 키워드 검색 결과에 더 높은 가중치를 주는 게 안전합니다.
리랭킹으로 정확도 높이기
검색 결과를 그대로 사용하지 않고 한 번 더 정제하는 리랭킹 단계를 추가하면 답변 품질이 확실히 달라집니다. 초기 검색에서 후보를 넓게 가져온 다음, 더 정교한 모델로 재평가해서 순위를 조정하는 방식입니다.
리랭킹 모델은 원래 질문과 각 검색 결과 간의 관련성을 더 깊이 있게 평가합니다. 단순 벡터 유사도가 아니라 의미적 연관성, 질문에 대한 답변 가능성, 정보의 완전성 같은 복합적 요소를 고려합니다.
공공기관 환경에서는 리랭킹 시 메타데이터도 함께 고려하면 좋습니다. 예를 들어 비슷한 유사도라면 더 최신 문서를, 같은 날짜라면 더 공식적인 문서를 우선하는 식입니다. 이런 규칙을 리랭킹 로직에 포함시키면 현업에서 실제로 필요한 결과가 상위에 오게 됩니다.
에이전트의 자율 판단 능력
Agentic RAG에서 에이전트가 단순 검색 도구가 아닌 진짜 에이전트가 되려면 자율 판단 능력이 필요합니다. 첫 검색 결과가 만족스럽지 않으면 스스로 전략을 바꿔서 재검색하고, 필요하면 질문을 분해해서 여러 차례 검색하며, 때로는 검색보다 LLM의 일반 지식이 더 적합하다고 판단하기도 합니다.
이런 판단 로직을 구현하려면 각 단계마다 품질 평가 기준이 명확해야 합니다. 검색 결과 개수, 평균 유사도 점수, 메타데이터 일치도 같은 지표로 검색 품질을 수치화하고, 임계값을 넘지 못하면 자동으로 대안 전략을 실행하도록 설계합니다.
실무에서는 보통 3단계 폴백 전략을 사용합니다. 첫 번째 검색이 실패하면 필터 조건을 완화해서 재검색하고, 그래도 안 되면 검색 범위를 확대하며, 최종적으로도 결과가 없으면 일반 LLM 응답으로 전환합니다. 각 단계마다 로그를 남겨서 나중에 검색 전략을 개선하는 데 활용합니다.
답변 생성과 출처 표기
검색이 끝나면 마지막으로 답변을 생성합니다. 검색된 청크들을 LLM에게 컨텍스트로 제공하고, 원래 질문에 대한 답변을 만들도록 합니다. 이때 중요한 건 환각을 방지하는 것입니다. 검색 결과에 없는 내용을 지어내지 않도록 명확히 지시해야 합니다.
공공기관에서는 출처 표기가 특히 중요합니다. 답변과 함께 어느 문서의 어느 부분에서 정보를 가져왔는지 명확히 표시해야 합니다. 메타데이터에 저장해둔 문서번호, 제목, 페이지 정보를 활용하면 쉽게 구현할 수 있습니다.
답변 형식도 사용자 친화적으로 디자인해야 합니다. 핵심 답변을 먼저 제시하고, 필요하면 상세 설명을 추가하며, 관련 문서 링크를 함께 제공하는 식입니다. 사용자가 더 깊이 알고 싶으면 원문을 바로 확인할 수 있게 하는 거죠.
지속적 개선 체계
Agentic RAG 시스템은 구축하고 끝이 아닙니다. 실제 사용 데이터를 모으고 분석해서 지속적으로 개선해야 합니다. 어떤 질문이 많이 들어오는지, 검색 실패율은 어떤지, 사용자 만족도는 어떤지 추적해야 합니다.
특히 검색 실패 케이스를 분석하는 게 중요합니다. 왜 원하는 답을 찾지 못했는지 원인을 파악하면 메타데이터 설계를 개선하거나, 청크 전략을 수정하거나, 에이전트 로직을 보완할 수 있습니다. 실패 사례야말로 시스템을 진화시키는 가장 좋은 자료입니다.
사용자 피드백을 적극 수집하는 것도 잊지 마세요. 답변이 도움이 되었는지 간단히 평가하게 하고, 문제가 있으면 어떤 부분이 아쉬웠는지 구체적으로 받아야 합니다. 이런 피드백이 쌓이면 시스템이 점점 똑똑해집니다.
공공기관을 위한 Agentic RAG 구축은 단순히 기술을 도입하는 것이 아니라 업무 방식을 혁신하는 과정입니다. 메타데이터를 체계적으로 설계하고, 에이전트가 똑똑하게 검색하도록 만들면 직원들은 방대한 문서 더미에서 필요한 정보를 순식간에 찾을 수 있습니다.
처음에는 복잡해 보이지만 하나씩 단계를 밟아가면 충분히 구축할 수 있습니다. 무엇보다 중요한 건 여러분 기관의 문서 특성을 정확히 이해하고, 실제 사용자 니즈에 맞춰 설계하는 것입니다. 기술은 도구일 뿐, 진짜 해답은 현장에 있습니다.