로디 복지 상담 에이전트 · RAG 1 · 법령과 생활 정보 사이

이 프로젝트의 출발점은 RAG가 아니었습니다. 노인과 고령층이 기초연금, 긴급복지, 노인 일자리, 고령자 고용과 근로 문제를 알아보려면 여러 기관의 법령과 안내 문서를 직접 오가야 한다는 문제에서 시작했습니다.

노인복지법과 기초연금법처럼 자격을 정하는 법령이 있고, 지역마다 달라지는 조례와 사업 공고가 있으며, 실제 신청은 주민센터나 복지관 같은 기관에서 이어집니다. 문서는 흩어져 있고 행정 용어는 어렵습니다. 지원 기준과 금액은 바뀔 수 있고, 잘못된 안내는 사용자의 실제 불이익으로 이어질 수 있습니다.

가족이나 복지 상담 실무자도 상황은 비슷합니다. 부모님의 나이, 소득, 거주 지역과 건강 상태를 하나씩 대입하며 여러 문서를 다시 찾아야 했습니다. 저희는 사용자가 어려운 법률 용어를 먼저 알지 않아도 자신의 상황을 말하면, 확인해야 할 기준과 다음 행동을 한 흐름 안에서 볼 수 있는 상담 서비스를 만들고 싶었습니다.

저는 할머니와 함께 살면서 어르신들이 주변 사람의 경험에 큰 영향을 받는 모습을 자주 보았습니다. “옆집 할머니네는 이게 됐다더라”, “이건 신청만 하면 된다더라”와 같은 이야기가 제도에 관심을 갖고 행동하는 계기가 되곤 했습니다. 왜 주변 사례가 그렇게 중요할까 생각해 보니, 법령의 문장보다 자신과 가까운 사람의 경험이 제도를 훨씬 구체적으로 상상하게 해주기 때문이었습니다.

그런 사용자에게 “이 법률 때문에 됩니다” 또는 “이 법률 때문에 안 됩니다”라고만 답하면 와닿지 않을 것 같다고 생각했습니다. 법적 기준을 정확히 제시하는 것과 함께, 비슷한 조건의 사람에게 제도가 어떻게 적용되었는지, 지역에서는 어떤 형태로 안내되고 있는지, 실제 신청 단계에서는 무엇을 준비했는지를 같이 보여줄 필요가 있었습니다.

그래서 답변과 함께 근거 문서, 신청 절차, 가까운 기관과 연락 방법을 이어서 보여주는 상담 흐름을 목표로 삼았습니다. RAG는 그 목표를 이루기 위해 선택한 검색 기반이었지, 프로젝트의 출발점 자체는 아니었습니다.

법령과 조례는 권리와 자격을 판단하는 기준이 됩니다. 하지만 사용자가 알고 싶은 것은 기준만이 아닙니다. 내가 사는 지역에서 실제로 신청할 수 있는지, 어느 기관으로 가야 하는지, 오늘도 운영하는지, 최근에는 어떤 사업에 집중하고 있는지, 나와 비슷한 사람이 지원받은 사례가 있는지까지 함께 알고 싶어 합니다.

웹 검색만으로 답하면 현재 안내는 찾을 수 있어도 그 정보가 어떤 법적 기준 위에 놓이는지 확인하기 어렵습니다. 반대로 수집한 법령만 검색하면 자격의 근거는 설명할 수 있어도 현재의 사업과 실제 신청 맥락이 빠집니다.

범위가 좁고 질문 유형이 고정되어 있다면 Vanilla RAG에 reranking을 적용하는 방식도 충분히 의미가 있습니다. 질문과 가까운 chunk를 찾고, 관련도가 높은 문서를 다시 정렬해 일정한 개수만 context로 전달하면 구조가 단순하고 동작도 예측하기 쉽습니다.

하지만 이 프로젝트에서는 관련 chunk를 몇 개 더 잘 고르는 문제만 다루고 싶지 않았습니다. 예를 들어 top-k를 20으로 늘려 재현율을 확보하려 하면 답변에 직접 필요하지 않은 조문까지 context에 들어갑니다. Context가 불어나면 token과 compute가 늘어나고, 모델이 중요한 조건과 예외를 끝까지 유지하지 못할 가능성도 커집니다. 반대로 k를 줄이면 상위법, 시행령, 지역 조례처럼 서로 떨어져 있지만 함께 읽어야 하는 근거를 놓칠 수 있습니다.

따라서 모든 질문에 같은 retrieval chain과 같은 k를 적용하기보다, 질문에 필요한 근거가 법령인지, 현재 지역 정보인지, 두 가지를 함께 확인해야 하는지에 따라 검색 경로를 나누었습니다.

Agentic RAG가 항상 더 정확하다는 뜻은 아닙니다. 도구가 늘어나면 routing 오류, latency와 비용도 늘어납니다. 여기서 Agent의 역할은 답을 자유롭게 만들어내는 것이 아니라, 필요한 근거의 종류를 판단하고 서로 다른 정보원을 연결하는 것입니다.

RAG를 Main Agent의 backend module로 넣으면 문서 수집과 검색 구조, 상담 runtime의 변경과 배포 주기가 함께 묶입니다. 법령 지식을 만드는 일과 그 지식을 사용해 상담하는 일은 변경 이유가 달랐기 때문에 하나의 application 안에 넣지 않았습니다.

별도 FastAPI·Memgraph 서비스와 MCP endpoint로 분리하면서 RAG 팀은 문서 ingest와 검색 경계를, backend 팀은 Main Agent와 외부 도구 orchestration을 병렬로 개발할 수 있었습니다. RAG가 완성될 때까지 Main Agent 개발을 멈출 필요가 없었고, backend가 바뀔 때마다 ingest code를 함께 수정할 필요도 줄었습니다.

이 경계는 재사용을 위한 선택이기도 했습니다. 다른 Agent가 같은 법령 지식이 필요할 때 Memgraph 연결과 ingest pipeline을 복사하지 않고 MCP server를 연결하면 됩니다. RAG 내부의 chunking이나 graph schema가 바뀌더라도 consumer는 공개된 tool contract만 유지하면 됩니다.

서비스를 분리하면 network failure, timeout, health check와 contract versioning을 별도로 관리해야 합니다. RAG endpoint가 느리거나 사용할 수 없을 때 Main Agent가 어떤 정보를 확인하지 못했는지도 사용자에게 구분해서 알려야 합니다.

또한 Web Search는 RAG snapshot의 최신성 문제를 보강할 수 있지만 법령 데이터 자체를 최신화하지는 않습니다. 원본 법령의 변경을 확인하고 다시 ingest하는 운영 정책은 별도로 필요합니다. 이 한계를 감수하면서도 개발 병렬성, 재사용성과 권한 분리가 더 중요한 구조적 이점이라고 판단했습니다.

이 작업은 다섯 명이 함께 만든 팀 프로젝트입니다. 저는 팀장으로 일정과 작업 방향을 정리하고, RAG와 External MCP가 Main Agent에서 조합되는 전체 경계와 파트 간 통합 흐름을 확인했습니다. RAG 데이터와 세부 구현, frontend와 backend 기여는 팀원별 책임을 구분해 소개합니다.