로디 복지 상담 에이전트 · RAG 2 · 사람이 만들던 RAG를 Agent와 함께 만들기

이 고민을 시작할 무렵에는 Obsidian을 MCP나 graph database에 연결하고, 문서를 넣을 때마다 node가 생기는 장면을 보여주는 Agentic RAG 데모가 주목받고 있었습니다. 개인의 note를 graph로 바꾸는 시각적 경험은 인상적이었지만, 실제 조직의 문서를 운영 가능한 RAG로 만드는 일은 여전히 별개의 구축 프로젝트처럼 다뤄지고 있었습니다.

AI Expo에서 여러 database·RAG solution 팀에 “문서를 올리면 지식 기반으로 만들어주는 SaaS 형태가 있습니까?”라고 물었을 때 돌아온 답은 먼저 문서 규모를 보고 견적을 산정해야 한다는 것이었습니다. 문서 수와 형태를 확인하고, 사람이 정제하고 chunking·embedding·연결 작업을 해야 비용과 기간을 계산할 수 있다는 의미로 받아들였습니다.

그 설명이 틀렸다고 생각하지는 않았습니다. 조직의 데이터는 같은 개념을 서로 다른 이름으로 부르거나, 문서마다 구조와 품질이 다르고, 관계를 판단할 ontology조차 없는 경우가 많습니다. 다만 법률과 조례처럼 문서의 위계와 연결 기준이 비교적 명확한 영역이라면, construction work의 더 많은 부분을 Agent에게 위임할 수 있지 않을까라는 질문이 남았습니다.

당시 제가 떠올린 연구자는 중앙대학교 문헌정보학과의 김학래 교수였습니다. 김학래 교수는 온톨로지와 지식그래프를 통해 흩어진 데이터를 색인하고 연결해 AI가 맥락을 읽을 수 있는 지식으로 바꾸는 문제를 연구해 왔습니다. 관련 인터뷰에서도 온톨로지와 지식그래프를 Agentic AI를 실제 조직에 적용하기 위한 기반으로 설명합니다.

이 관점에서 보면 RAG construction의 비용은 embedding API 비용만으로 설명되지 않습니다. 문서의 개념과 관계를 어떻게 통일할지, 어떤 연결을 graph fact로 인정할지, 이후 들어오는 문서를 같은 policy로 처리할지를 정하는 일이 함께 필요합니다.

저희가 자동화하려고 한 것도 이 판단을 없애는 일이 아니었습니다. Agent가 반복적인 문서 분석과 관계 후보 생성을 맡고, 사람은 후보가 실제로 맞는지 approve 또는 deny하며, 그 판단 기록이 다음 construction에 다시 사용되는 framework를 만드는 일이었습니다.

문서를 업로드하면 먼저 Chunking Agent가 원문을 의미 단위로 나눕니다. 만들어진 chunk마다 worker가 기존 graph와 관련 문서를 탐색하고, 연결할 수 있는 node와 relationship candidate를 제안합니다. Agent가 저장하는 것은 확정된 관계가 아니라 사람이 검토할 후보입니다.

검토자는 후보의 원문 근거와 rationale을 보고 approve 또는 deny합니다. 두 결정에는 note를 남길 수 있고, review log와 note는 graph에 저장됩니다. 다음 construction run에서는 이 기록을 memory context로 제공해 과거에 어떤 관계를 승인했고 어떤 기준으로 거절했는지를 참고하도록 했습니다.

Write access도 모든 Agent에게 열지 않았습니다. read_document_tool, write_chunk_tool, write_relationship_candidate_tool과 edge materialization은 RAG 내부 construction surface에만 둡니다. 사용자와 대화하는 Main Agent에는 외부 MCP의 read-only 도구만 제공합니다.

자동화하려는 대상은 단순한 파일 업로드가 아니었습니다. 원문을 추적할 수 있는 문서로 등록하고, 의미 단위의 chunk를 만들고, embedding을 저장하고, 기존 법령 graph와 연결할 관계 후보를 제안하는 과정까지 하나의 construction flow로 묶었습니다.

다만 LLM이 제안한 관계를 자동으로 사실로 확정하지는 않았습니다. 문서 처리 과정은 자동화하되, 법령 사이의 의미 관계가 실제 graph edge가 되는 마지막 결정에는 사람의 검토를 남겼습니다.

public text document
  → deterministic document registration
  → source-faithful chunking agent
  → embedding dispatch and storage
  → graph relationship candidate agent
  → pending human review
  → approved edge materialization
  → read-only MCP tools

문서 등록은 Agent에게 맡기지 않았습니다. DocumentRegistry가 파일 형식을 확인하고, 정규화한 원문의 SHA-256 content_hash와 원문 전체, 파일명과 source metadata를 저장합니다. 이후 단계는 이때 만들어진 document_id를 기준으로 같은 문서를 읽습니다.

이 경계를 둔 이유는 provenance 때문입니다. Chunk와 관계 후보가 그럴듯하더라도 어느 원문에서 만들어졌는지 다시 확인할 수 없다면 법령 근거로 사용하기 어렵습니다. 생성 모델이 내용을 해석하기 전에 문서 identity와 원문을 먼저 고정했습니다.

LLM이 문서를 매끄럽게 요약하면 검색용 문장처럼 보일 수 있지만, 조건과 예외가 사라지거나 원문의 위치를 다시 찾기 어려워질 수 있습니다. 법령 데이터에서는 읽기 좋은 요약보다 근거를 되짚을 수 있는 chunk가 더 중요했습니다.

ChunkingAgent는 문서의 의미 경계를 판단하지만 chunk 본문은 원문에서 그대로 복사하도록 제한했습니다. 각 chunk에는 start_unique_string과 end_unique_string을 두고, 해당 문자열이 원문에 정확히 한 번 등장하는지 도구로 확인합니다. Marker가 중복되면 범위를 넓혀 다시 검사합니다.

Chunk의 본문과 함께 사람이 빠르게 확인할 수 있는 이름, 설명, tag, summary와 경계 선택 이유도 저장합니다. 생성된 chunk는 write_chunk_tool을 통해 원본 Document와 연결됩니다.

LLM이 높은 confidence를 반환하더라도 잘못된 법령 위계나 적용 범위가 graph에 고정될 수 있습니다. 그래서 DocumentConstructionGraph는 관계 후보를 만든 뒤 pending_review 상태에서 종료합니다.

검토자는 후보의 evidence와 rationale을 읽고 yes 또는 no를 선택합니다. 승인된 후보만 ActualEdgeMaterializationNodeService를 거쳐 실제 semantic edge가 됩니다. 거절된 후보는 상태와 reviewer note를 남기며, review 기록은 이후 판단 기준을 정리하는 memory update에 사용됩니다.

사람의 응답을 기다리는 동안 하나의 LangGraph 실행을 계속 유지하지도 않습니다. 문서 construction과 candidate review를 서로 다른 graph execution으로 분리해 pending 상태를 저장하고, 검토 action이 들어왔을 때 별도 review graph를 실행합니다.

내부 비교에서는 데이터 수집과 문서 확인을 담당하던 작업자에게 같은 종류의 RAG construction을 수작업으로 진행해 달라고 요청했습니다. 당시 들은 작업량은 약 4~5시간에 문서 3~4개였고, 비교 기준으로는 대략 문서 하나에 한 시간 정도가 필요했습니다.

같은 범주의 비교 문서를 Agent-assisted pipeline으로 처리했을 때는 문서 하나가 약 10분 이내에 candidate review 단계까지 도달했습니다. OpenRouter에 기록된 실제 사용 비용과 당시 최저시급을 기준으로 문서당 비용을 비교하면, 사람의 검토 시간을 포함하더라도 약 10분의 1 수준까지 줄어드는 구간을 확인했습니다.

Chunk 단위의 품질과 승인된 connection에서는 눈에 띄는 차이를 발견하지 못했습니다. Agent 결과를 그대로 확정한 것이 아니라 사람이 같은 기준으로 후보를 검토했기 때문에, 반복 작업의 속도를 줄이면서 최종 판단 layer는 유지할 수 있었습니다.

RAG 내부의 construction Agent는 chunk와 relationship candidate를 쓰는 도구가 필요합니다. 하지만 사용자와 대화하는 Main Agent가 문서나 graph 관계를 수정할 이유는 없습니다. 그래서 외부 MCP surface에는 다음 read-only 도구만 등록했습니다.

memgraph.text_index_search
memgraph.vector_search
memgraph.graph_traverse
memgraph.read_query
memgraph.schema_read

도구 결과는 embedding vector와 지나치게 긴 text를 그대로 노출하지 않도록 sanitize합니다. Main Agent는 필요한 근거를 읽을 수 있지만 graph를 만드는 규칙과 승인 결과를 바꿀 수 없습니다.

이 권한 분리는 RAG를 독립 서비스로 만든 이유와 직접 연결됩니다. 내부 구현을 감추기 위한 분리가 아니라, 자동으로 지식을 구축하는 surface와 제품이 그 지식을 소비하는 surface를 서로 다른 계약으로 운영하기 위한 분리였습니다.

현재 pipeline은 text 계열 입력을 중심으로 동작합니다. PDF, OCR과 VLM을 거쳐야 하는 문서는 별도의 전처리 layer가 필요합니다. 신규 문서의 등록과 construction은 구현되어 있지만, 같은 source의 변경을 자동 감지해 version을 증가시키는 re-ingest와 원본 polling도 다음 운영 범위로 남아 있습니다.

관계 후보 생성은 LLM과 외부 provider에 의존하므로 latency, quota와 부분 실패가 발생할 수 있습니다. Chunk별 candidate generation은 가능한 결과를 보존하지만, 후보가 만들어졌다는 사실만으로 graph 품질이 보장되지는 않습니다. 사람이 검토한 edge와 원문 provenance를 유지하는 이유가 여기에 있습니다.

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