데이터 에이전트(사람 대신 데이터베이스·문서를 뒤져 질문에 답하는 AI)가 자주 헤매는 큰 이유 하나는 모델의 추론력 부족이 아니다. 정작 다뤄야 할 데이터가 에이전트 바깥에 흩어져 있고, 그 구조와 내용을 미리 알 수 없다는 데 있다. 논문은 이 어긋남을 agent–data gap, 에이전트와 데이터 사이의 간극이라 부른다.
EvoOntology는 이 간극을 메우려는 시도다. 사람이 손으로 써 두는 정적 데이터 사전 대신, 에이전트가 일하는 도중에 직접 물어보고 스스로 고쳐가며 키우는 온톨로지 층(데이터의 의미를 적어 둔 일종의 안내 지도)을 두자는 것이다. 결론부터 말하면, 온톨로지 없이 같은 모델을 돌린 기준선보다는 확실히 나아졌다. 다만 "시맨틱 레이어 기준선을 일관되게 앞선다"는 초록의 표현은 실험표와 조금 다른데, 그 대목은 뒤에서 표를 함께 본다.
현실의 데이터는 에이전트 바깥에 흩어져 있다. 관계형 DB부터 반정형 문서, 비정형 파일까지 형태도 제각각이다. 에이전트는 SQL 인터페이스나 파일 리더 같은 일반 도구로만 이 데이터에 겨우 닿을 뿐이다. 문제는 이 데이터들의 구조도 내용도 미리 알려져 있지 않다는 점이다. 그래서 에이전트는 탐침 질의(데이터 일부를 찔러보는 시험용 질의)를 반복해 던지고, 원하는 개념이 어디 있을지 추측하고, 관련 없는 내용을 들춰보며 눈먼 탐색을 한다.
에이전트가 이렇게 눈먼 탐색을 하는 agent–data gap을 풀기 위한 기존 접근은 크게 둘이다.
하나는 raw querying, 에이전트가 스키마(데이터 구조 설계도)를 직접 읽고 탐색 질의를 날리는 방식이다. 작고 단순한 데이터엔 잘 통하지만, 넓고 이질적인 데이터에선 비효율적 탐색에 갇히기 쉽다.
다른 하나는 semantic layer(시맨틱 레이어), 스키마·엔티티·지표 같은 도메인 의미 정보를 미리 만들어 에이전트에게 통째로 쥐여 주는 방식이다. 그러나 데이터가 크면 이 설명 전체를 프롬프트에 넣기가 길이 한계상 불가능하다. 게다가 대개 사람이 수작업으로 관리해, 만들기도 비싸고 갱신하기도 어렵다.
논문은 여기서 "정적 설명"을 넘어, 에이전트가 도구로 유연하게 접근하는 상호작용형 온톨로지 층이 필요하다고 본다.
새 분석가가 출근했는데, 자료가 부서마다 제각각 캐비닛·엑셀·DB로 흩어져 있다고 하자. 정적 시맨틱 레이어는 누군가 예전에 써 둔 두꺼운 사내 편람과 비슷하다. 통째로 읽기엔 너무 길고, 이미 낡았고, 이 분석가가 실제로 어떻게 일하는지는 모른다.
EvoOntology는 편람 대신 "질문을 받는 자료실 안내 창구"를 두는 쪽이다. 필요할 때 물어보면 관련된 카드만 꺼내 주고, 그 카드 자체를 실제 서랍을 열어 확인해 가며 짓고, 분석가들이 어디서 막히는지 지켜보며 고쳐 키운다.
그렇다면 이 '안내 창구'는 구체적으로 어떻게 설계됐을까. 논문은 이를 세 가지 층으로 나눠 구현한다.
이 세 층을 하나의 MCP 서버(모델이 외부 도구를 불러 쓰는 표준 연결 방식)로 감싼 것이 핵심이다. 에이전트가 메타데이터를 수동적으로 받아먹는 대신, 능동적으로 물어보고 꺼내 쓰게 만든 것이다.
"고객 데이터에서 지난달 매출을 뽑아라"는 일을 맡은 에이전트를 떠올려 보자.
첫 단계는 '초기 지도 그리기'다. 빌더 에이전트는 정답지 없이, 학습용 작업 기록과 원본 데이터만 보고 자주 나오는 개념 — '매출' '고객' '기간' 같은 것 — 을 후보로 추린다. 그런 다음 직접 탐침 질의를 날려 '매출이 정말 이 테이블 이 컬럼에 있는지', 값과 타입이 말이 되는지 하나씩 확인하는 일종의 실사 작업을 거친다. 탐침이 뒷받침하는 후보만 카드로 남기고, 그 근거가 된 실제 레코드를 증거로 붙인다. 짐작이 아니라 확인된 것만 지도에 올리는 것이다.
두 번째 단계는 '지도 고쳐 그리기'다. 진화 에이전트는 에이전트가 실제로 일한 기록(궤적)을 증거 삼아 지도를 손본다. 잘 풀린 기록은 어떤 카드와 경로가 통했는지 알려 주고, 막힌 기록은 무엇이 빠졌거나 헷갈리게 적혔는지 드러낸다. 예컨대 '매출' 카드에 환불 처리 규칙이 빠져 에이전트가 반복해서 틀렸다면, 그 패턴을 뽑아 해당 카드를 고친다.
이때 중요한 설계 원칙이 하나 있다. 수정은 한 번에 한 층만 건드린다. 내용·도구·스키마 중 어디를 고칠지 정해 한 곳만 바꾼다. 이는 변화의 원인을 분명히 추적하고, 한 곳을 고치다 엉뚱한 데서 부작용이 터지는 일을 막기 위한 안전장치다.
고친 결과가 진짜 나아졌는지는 오직 측정으로 판정한다. 백본(에이전트의 두뇌가 되는 LLM)마다, 수정안과 수정 전 상태를 같은 검증셋·같은 조건에서 맞붙여 정해 둔 차이 이상 좋아질 때만 채택한다. 떨어지면 버리고, 버린 기록도 로그로 남겨 같은 헛수고를 되풀이하지 않는다. 백본마다 독립적으로 자라므로, 채택된 수정은 그 백본의 버릇을 반영한다.
본론에 들어가기 전에 용어 두 개만 풀어 두자. 이 논문의 모든 실험은 같은 추론 구조(ReAct, 모델이 '생각하고 → 도구를 쓰고 → 결과를 보고' 다시 생각하기를 번갈아 하는 방식)와 같은 연산량 한도(디코딩·상호작용 예산) 아래에서 이뤄진다. 비교 대상끼리 조건을 엄격히 통제했다는 뜻이다. 그래야 점수 차이가 "온톨로지를 붙여서 생긴 차이"임을 말할 수 있다.
평가는 세 벤치마크에서 이뤄졌다. 성격만 짚으면 이렇다.
핵심은 이것이다. 초록은 EvoOntology가 강한 기준선과 시맨틱 레이어 기준선(Baseline + SL)을 "일관되고 상당하게 능가"한다고 적었다. 그런데 표를 보면 늘 그렇지는 않다. InsightBench에서 두 모델은 EvoOntology와 Baseline + SL(시맨틱 레이어)이 모든 지표에서 같았다.
| InsightBench (Overall) | EvoOntology | Baseline + SL |
|---|---|---|
| GPT-5.5 | 51.0 | 51.0 |
| Claude-Opus-4.8 | 53.2 | 53.2 |
이 조건에선 압도가 아니라 동률이다. 따라서 결과를 종합하면 이렇게 규정하는 편이 정확하다. 온톨로지를 붙이지 않은 같은 백본보다는 확실히 낫지만, 빌더 에이전트가 생성한 시맨틱 레이어를 정적 프롬프트로 넣은 조건(Baseline + SL)과는 상황에 따라 비기는 '조건부 우위'다. 한 가지 덧붙일 주의. 벤치마크마다 점수 체계가 달라서(정확도·인사이트 점수·EX/VES), 서로 다른 실험의 숫자를 하나로 합쳐 읽어서는 안 된다.
실험 설정 주석. 여기서 Baseline + SL은 사람이 구축한 기존 시맨틱 레이어가 아니라, 빌더 에이전트가 생성한 시맨틱 레이어를 정적 프롬프트로 주입한 조건이다. 따라서 이 동률을 "사람이 비싸게 만든 기존 시맨틱 레이어 전반에 대한 우위/열위"로 넓혀 읽으면 비교 범위를 왜곡한다. BIRD는 공식 Oracle Knowledge 설정(질문에 필요한 배경지식을 함께 주는 공식 모드)에서 실행 정확도(EX)를 주지표, 유효 효율 점수(VES)를 보조지표로 쓴다. 백본은 초록에선 넷이라 했으나 실험 설정에는 여섯이 적혀 있다(GPT-5.5, GPT-5.6-sol, Claude-Sonnet-5, Claude-Opus-4.8, DeepSeek-V4-Flash, Qwen3.5-Flash). 위 표의 수치는 논문 InsightBench 표에서 직접 확인되는 동률 값만 인용했다.
동률이 나온다는 사실 자체가 질문을 던진다. 이 진화 장치가 실제로 값을 하는 지점은 정확히 어디인가. 논문의 논리대로라면 데이터가 넓고 이질적일수록 이득이 커야 하는데, 그 경계가 표만으로는 또렷하지 않다.
게다가 초기화·진화·검증은 모두 공짜가 아니다 — 추가 연산이 든다(부록에서 온톨로지 층의 비용을 따로 다룬다). 백본마다 따로 자라다 보니 수정은 그 백본에 맞춰진다. 논문은 한 백본에서 키운 온톨로지를 다른 백본에 옮겨 써 봤는데(그림 5b), 옮기는 것 자체는 되지만 성능은 다소 떨어졌다. 즉 백본별로 키우는 편이 유리하다는 뜻이지, "모델을 바꾸면 반드시 처음부터 다시 키워야 한다"가 증명된 것은 아니다.
또 빌더는 학습용 작업 기록을, 진화 에이전트는 과거 궤적을 필요로 한다. 실행 이력이 전혀 없는 새 데이터에는 콜드 스타트(쌓인 기록이 없어 시작이 막막한) 문제가 남는다. 평가도 특정 시나리오(예: DDR의 10-K)에 걸쳐 있어, 일반화 여부는 열린 질문이다.
이는 저희 온틀이 매일 현장에서 부딪히는 문제이기도 합니다. 저희는 고객 프로젝트마다 데이터를 격리해 다루고, 고객사의 ERP·쇼핑몰·사내 엑셀 같은 외부 시스템을 그때그때 붙여 씁니다. 새 고객을 받을 때마다 "이 회사의 '매출'은 어느 테이블 어느 컬럼에 있고, 환불은 어떻게 빠지는가"를 사람이 다시 캐묻는 일이 반복됩니다. 이 논문이 말하는 agent–data gap이 바로 그 장면입니다.
끌리는 지점은 둘이다. 하나는 근거 기반 초기화 — 사람이 고객마다 데이터 사전을 손으로 쓰는 대신, 실제 데이터를 찔러 확인하고 그 증거와 함께 짓는 방식이다. 다른 하나는 궤적 기반 진화 — 쓰면 쓸수록 그 고객 데이터에 대한 이해가 작업 기록에서 저절로 나아지는 그림이다. 특히 "측정으로 좋아질 때만 수정을 채택하고, 버린 것도 기록에 남긴다"는 게이트는 눈여겨볼 만하다. 에이전트가 제 지식을 아무도 모르게 바꿔 버리는 일을 막아 주기 때문이다.
다만 그대로 들이기 전에 비용과 효용을 저울질해야 한다. 데이터가 작고 단순한 고객이라면 잘 정리한 데이터 사전 한 장으로 충분할 수 있다. 진화 장치가 제값을 하는 건 넓고 이질적인 스택일 때로 보이는데, 앞서 봤듯 그 경계는 아직 또렷하지 않다. 작업에 따라 여러 모델을 바꿔 쓰는 제품이라면, 온톨로지를 백본 사이에 옮길 때의 성능 손실과 백본별로 키울 때의 이점 사이 절충도 실전에선 함께 따져야 한다. 결론을 서두르기보다, 데이터가 넓은 한두 곳에서 근거 기반 초기화만 먼저 시험해 보는 편이 현실적이다.