에이전트마다 빌드하면 같은 문서를 에이전트 수만큼 다시 읽어야 했습니다

은행 플랫폼의 에이전트는 개발 환경에서만 300개를 넘겼고 앞으로도 늘어날 참이었습니다. 누가 무엇을 만들어 어떻게 쓰고 있는지 관리자가 한눈에 보기 어려운 상태였습니다. 이 관계를 온톨로지로 보여 주되 에이전트마다 그래프를 빌드하지 않고 이미 있는 설정 테이블에서 구성한 이유와, LLM 없이 규칙으로 인사이트를 낸 방식을 정리합니다.

관리자가 묻는 것은 관계였습니다

은행의 외부망 개발 환경을 조사했을 때 에이전트는 307개, 사용자는 76명이었습니다. 이름이 복사본인 것이 65개, 테스트인 것이 46개였고, 60일 넘게 수정이 없는 것이 196개, 한 번도 실행되지 않은 것이 100개였습니다. 지워진 자산을 가리키는 끊어진 참조도 14건 있었습니다.

관리자에게 필요한 답은 대부분 이미 테이블에 있었습니다. 캔버스 설정에는 어떤 모델, 컬렉션, 도구, DB 연결을 쓰는지가, 배포 테이블에는 단계와 승인이, 실행 로그에는 누가 얼마나 실행했는지가 남아 있었습니다. 다만 흩어져 있어서 "이 컬렉션이 바뀌면 어떤 에이전트가 영향을 받나" 같은 질문에 한 번에 답할 수 없었습니다.

은행과의 후속 협의에서 방향도 정해졌습니다. 이 대시보드는 관계를 시각화하는 뷰어가 아니라 관리자용 인사이트 도구여야 했습니다.

에이전트마다 빌드하면 같은 문서를 다시 읽습니다

그때까지 온톨로지는 컬렉션 단위였습니다. 에이전트마다 그래프를 갖게 하는 방법은 세 가지를 비교했습니다.

개발 환경에서 에이전트가 참조하는 컬렉션은 약 40개였습니다. "에이전트 307개 × 문서 재추출"이 아니라 "컬렉션 약 40개 빌드와 에이전트 307개 그래프 구성"이 맞는 규모였습니다. 컬렉션을 다시 빌드하면 그 컬렉션을 쓰는 에이전트는 재구성 없이 새 그래프를 조회합니다.

에이전트 범위로 문서를 검색하는 실행 기능도 기획했지만 관리 목적과 맞지 않아 범위에서 제외했습니다. 그 자리는 자원 검색과 미사용 자산 찾기로 채웠습니다.

저장 단위를 컬렉션에서 스코프로 넓혔습니다

새 테이블은 만들지 않았습니다. 그래프 테이블의 collection_id를 스코프 키로 일반화했고, 에이전트 그래프는 접두어가 다른 키로 같은 테이블에 저장합니다.

<컬렉션 ID>          문서 빌드 결과
agent:<에이전트 ID>   L0 구조층: 소유·부서·자산 참조·배포·승인·실행 실적 (설정 테이블, LLM 0회)
                     L1 정렬층: 멤버 컬렉션 사이 같은 라벨을 sameAs로
assets:platform      참조되지 않은 자산까지 원본 테이블에서 구성
topics:platform      L2 업무 주제 (LLM, 텍스트가 바뀐 에이전트만)

조회는 에이전트 스코프와 그 멤버 자산 스코프의 합집합으로 합니다. 에이전트 그래프에는 얇은 구조만 두고, 문서에서 나온 지식은 컬렉션 쪽을 그대로 읽습니다.

갱신도 LLM 없이 수행됩니다. 아직 구성되지 않았거나, 저장 뒤 수정됐거나, 멤버가 바뀌었거나, 상태 서명이 바뀐 에이전트를 stale로 판정합니다. 상태 서명은 배포 단계, 승인, 실행 실적, 공유, 소유자를 묶은 값입니다. 처음에는 캔버스 저장에만 반응해서 승인이 나거나 실행이 쌓여도 그래프가 그대로였기 때문에 추가했습니다. 1분 주기 스윕이 stale 에이전트만 재구성하고, 대시보드를 열 때는 최대 30개를 온디맨드로 갱신합니다. 에이전트 상세 페이지를 열면 그 에이전트 하나만 즉시 갱신하고, 지워진 에이전트의 스코프는 스윕이 정리합니다.

빌드 상태 표시와 구성 실행 버튼은 UI에서 제거했습니다. 관리자가 볼 것은 온톨로지가 있는지가 아니라 에이전트 하나하나가 무엇을 쓰고 누가 갖고 있는지였습니다.

인사이트는 규칙으로, 기준은 그 환경의 분포로

인사이트는 구성된 그래프 위에서 규칙 7종으로 계산합니다. LLM은 호출하지 않고 결과는 60초 동안 캐시합니다.

나머지 셋은 현황판 후보, 같은 업무, 정리입니다. 기준을 고정 숫자가 아니라 백분위와 중앙값으로 잡은 데는 이유가 있었습니다. 외부망 개발 DB에는 부서 값이 든 사용자가 3명뿐이었고, 폐쇄망은 분포가 다릅니다. 숫자를 하드코딩하면 한쪽 환경에서만 성립합니다.

LLM은 덧붙이는 역할만 맡습니다. 에이전트마다 업무 주제를 붙이고, 카드에 두 문장 설명을 쓰고, 자연어 질문에 답합니다. LLM이 없어도 그래프, 카드, 검색은 동작합니다. 다만 "같은 업무" 카드는 업무 주제가 있어야 나옵니다.

자연어 질문도 같은 그래프를 씁니다. 항목 하나를 이름, 종류, 속성, 1홉 관계로 된 근거 한 줄로 만들어 어휘(lexical) 인덱스에 넣고, 이름 일치와 종류 전체 목록, 1홉 관계로 근거를 고른 뒤 LLM이 답합니다. 처음에는 "컬렉션을 가장 많이 쓰는 에이전트" 같은 집계 질문에서 시드가 0개였습니다. 질문에 특정 항목의 이름이 없었기 때문입니다. 집계 질문이면 질문에 맞는 값으로 정렬한 상위 항목을 시드로 넣도록 바꿨습니다.

확인한 것과 남은 것

외부망 개발 DB를 읽기 전용으로 읽고 쓰기는 인메모리로 모킹한 드라이런에서, 에이전트 306개가 노드 3,373개와 엣지 3,867개의 그래프로 구성됐습니다. 대시보드 진입 시 첫 온디맨드 갱신(stale 에이전트 30개와 자산 목록)은 0.96초, 인사이트 계산은 0.3초였습니다. Qwen3.8-27B 엔드포인트로는 실행 이력이 있는 에이전트 40개 중 38개에 업무 주제가 붙었고, 집계형 관리 질문 7개에 모두 맞게 답했습니다.

아직 못 본 것도 분명합니다. 개발 환경에는 부서 값이 거의 없어 현황판 후보와 부서 공백 카드는 0건이었고, 이 규칙이 실제로 성립하는지는 폐쇄망 배포 뒤에야 알 수 있습니다. 에이전트 300개 규모에서 UI 렌더링 체감 성능도 확인 전입니다.

관리용 온톨로지는 새 지식을 뽑는 일보다 이미 있는 설정을 같은 어휘로 엮는 일에 가깝다고 봅니다. 그렇게 엮어 두니 관리자의 질문 상당수는 LLM 없이 그래프 위의 규칙으로 답할 수 있었습니다.