EvoOntology, 컬럼명만 보고 헤매는 데이터 에이전트를 어떻게 멈추나
데이터 에이전트가 amt와 final_amount를 같은 값으로 보거나, monthly/ 폴더를 월별 매출 원장으로 오해한다면 모델의 추론만 더 길게 시키는 방식은 근본 처방이 되기 어렵습니다. EvoOntology는 데이터의 의미를 별도 온톨로지 계층으로 꺼내고, 작업 기록을 바탕으로 제한된 수정안을 평가한 뒤에만 다음 버전으로 채택하자는 연구·오픈소스 프로젝트입니다.
핵심은 모델 가중치가 아니라, 조회 가능한 의미 지도를 버전 관리하는 데 있습니다.
30초 요약
- 컬럼명·파일 경로는 의미를 충분히 말해 주지 않아 에이전트가 지표 정의와 관계를 반복 추측할 수 있습니다.
- EvoOntology는 Content·Schema·Tool의 세 계층을 MCP(Model Context Protocol) 도구로 제공합니다.
- 실행 궤적에서 반복 오류를 찾되, 수정안은 부모 버전과 같은 조건의 쌍 비교를 통과해야 채택합니다.
- 논문은 2026년 9월 14일 arXiv에 제출된 연구입니다. 운영 환경의 보편적 성능이나 안정성을 뜻하지는 않습니다.
왜 컬럼명과 파일명만으로는 자꾸 틀릴까?
amount라는 컬럼 하나에는 주문 금액, 환불 후 금액, 세전 금액처럼 서로 다른 뜻이 들어갈 수 있습니다. customer_id도 고객 마스터의 키인지, 익명화된 분석 키인지 이름만으로는 판별하기 어렵습니다.
파일 경로도 마찬가지입니다. finance/2026/Q2라는 이름은 사람에게 힌트를 주지만, 어떤 통화인지·취소 건을 포함하는지·집계 기준이 무엇인지는 알려 주지 않습니다. 이 빈칸을 매 작업마다 모델이 추측하면, 같은 탐색과 같은 오류가 되풀이됩니다.
생활 비유로 보면 서랍에 ‘영수증’, ‘중요’, ‘최종’이라고만 붙여 둔 사무실입니다. 새로 온 사람이 물건을 찾을 수는 있어도, ‘최종’이 결재 완료본인지 임시 합계인지까지 알아내려면 매번 서랍을 열어 확인해야 합니다.
EvoOntology는 의미를 어떤 층으로 나눌까?
EvoOntology 저장소는 온톨로지 계층을 Content Layer, Schema Layer, Tool Layer의 세 부분으로 설명합니다. 이 계층은 데이터 원본을 대체하는 복제본이 아니라, 에이전트가 필요한 의미를 찾아갈 수 있게 하는 별도 지도입니다.
| 계층 | 하는 일 | 데이터 에이전트가 얻는 것 |
|---|---|---|
| Content Layer | 용어, 데이터 매핑, 제약, 근거와 관계를 담는 타입 그래프 | ‘순매출’이 어느 필드와 규칙으로 연결되는지 |
| Schema Layer | 허용된 객체 필드·관계·참조 패턴을 정함 | 의미 정보를 어떤 형태로 기록할지의 경계 |
| Tool Layer | browse_semantics, resolve_semantics와 세션 매니페스트를 노출 |
전체 지도를 프롬프트에 넣지 않고 필요한 기록만 조회 |
전체 의미 사전을 한꺼번에 주입하는 대신, 현재 작업에 필요한 기록만 MCP로 꺼내는 것이 설계의 출발점입니다.
다음은 저장소와 논문 설명을 바탕으로 단순화한 문서 기반 예시입니다. 실제 도구 출력이나 실행 결과가 아닙니다.
입력 질문: “2분기 순매출을 지역별로 보여줘”
원본 단서: orders.amount, refunds.refund_amount, region_code
resolve_semantics("순매출")
→ 용어: 순매출
→ 매핑: orders.amount - refunds.refund_amount
→ 제약: 취소 완료 건 제외, region_code는 지역 코드표와 조인
→ 근거: 지표 정의 문서와 검증된 원본 참조
출력 행동: 매핑·제약을 반영한 쿼리/분석 계획을 구성
이 구조에서 중요한 점은 ‘정답 SQL을 저장한다’가 아닙니다. 용어와 원본 데이터의 연결, 적용 조건, 근거를 함께 다뤄 다음 작업에서도 다시 찾을 수 있게 하는 것에 가깝습니다.
‘스스로 고친다’는 말은 무엇을 뜻할까?
자기 진화는 대화 중 즉흥적으로 지식을 덮어쓰는 기능과 다릅니다. 저장소가 설명하는 흐름은 Build → Use → Evolve → Evaluate → Publish or reject입니다.
처음에는 builder가 작업 요구와 원본 데이터를 토대로 후보 의미 객체를 만들고 검증해 ontology_v0를 구성합니다. 이후 데이터 에이전트가 실제 작업을 수행하면 도구 호출과 결과가 궤적으로 남고, evolution 단계는 반복된 실패나 비효율을 Content·Tool·Schema 중 어디에 귀속할지 살핍니다.
수정은 넓은 재작성보다 연결된 계층의 국소 패치로 제안하고, 통과하지 못하면 부모 버전을 그대로 유지합니다.
예를 들어 에이전트가 계속 gross_sales를 순매출로 가져온다면, 후보 수정은 Content Layer의 매핑 또는 제약을 보강하는 쪽일 수 있습니다. 반대로 필요한 개념을 찾는 도구 호출 자체가 불편했다면 Tool Layer의 접근 방식이 후보가 될 수 있습니다. 새 객체 유형이 필요할 때만 Schema Layer까지 영향을 검토하는 식입니다.
왜 수정안을 바로 반영하지 않고 비교할까?
의미 지도는 편리하지만 잘못 고치면 이후의 모든 작업에 틀린 전제가 퍼질 수 있습니다. 그래서 EvoOntology는 후보(Candidate)를 부모(Parent)와 같은 데이터, 에이전트, 디코딩 설정, 상호작용 예산에서 쌍으로 평가해 재현 가능한 개선이 보일 때만 발행하는 방식을 제시합니다.
이 장치는 ‘좋아 보이는 설명’을 정답으로 바꾸는 일을 막기 위한 브레이크입니다. 에이전트가 그럴듯하게 말했는지보다, 같은 조건에서 후보가 실제 과제를 더 잘 처리하는지를 확인해야 합니다.
논문 저자들은 BIRD, DDR-10K, InsightBench의 세 벤치마크와 여러 LLM 백본에서 결과를 보고했습니다. 다만 이는 연구 평가 결과입니다. 사내 데이터의 권한 모델, 지표 정의 변경, 데이터 품질, 비용 제한까지 자동으로 해결된다는 뜻으로 읽으면 안 됩니다.
설치 전에 먼저 정할 것: 의미 변경의 승인선
공개 저장소 README에는 Claude Code와 Codex용 플러그인 설치 흐름이 안내돼 있습니다. Codex 예시는 마켓플레이스 추가 뒤 플러그인을 추가하고, 새 스레드에서 $build-ontology, $evolve-ontology, $explore-ontology를 사용하도록 적고 있습니다.
# 공식 README에 제시된 Codex 플러그인 흐름
codex plugin marketplace add MeiduoChong/EvoOntology
codex plugin add evoontology-codex@evoontology
codex plugin list
하지만 설치보다 앞설 일은 변경 권한을 나누는 것입니다. 자동 제안과 운영 반영을 같은 권한으로 두지 말고, 원본 근거·변경 범위·평가 결과를 사람이 추적할 수 있게 남겨야 합니다.
시작 범위는 한 개 업무 질문과 읽기 전용 데이터셋이 적당합니다. 예를 들어 ‘주별 활성 고객’처럼 정의 문서, 원본 테이블, 제외 조건을 이미 확인할 수 있는 지표를 고르고, 어떤 오류를 성공/실패로 볼지 먼저 적어 두면 후보 수정의 품질을 판단하기 쉬워집니다.
어떤 팀에 맞고, 언제 아직 이른가?
같은 데이터 환경을 여러 분석 질문에서 반복 탐색하고, 지표 정의·조인 관계·제약을 매번 다시 설명하는 팀에는 검토할 가치가 있습니다. 특히 테이블, 파일, 데이터베이스가 섞여 있고 에이전트가 여러 도구를 오가는 환경이라면 ‘의미를 어디에 기록하고 어떻게 꺼낼지’가 작업 품질에 직접 영향을 줍니다.
반대로 데이터셋이 작고 질문도 단발성이거나, 용어 정의가 아직 합의되지 않았다면 먼저 문서와 데이터 계약을 정비하는 편이 낫습니다. 온톨로지는 합의되지 않은 업무 규칙을 마법처럼 만들어 주지 않습니다.
또한 저장소의 Releases 페이지에는 확인 시점에 정식 릴리스가 표시되지 않았습니다. 연구 제출본과 빠르게 변할 수 있는 공개 저장소라는 성격을 감안해, 민감 데이터에는 읽기 전용·작은 범위·재현 가능한 평가부터 적용하는 편이 안전합니다.
다음 행동: ‘틀린 답’보다 ‘틀린 의미’를 기록하기
EvoOntology가 던지는 실용적인 질문은 “에이전트가 왜 틀렸나?”에서 한 단계 더 나아갑니다. “그 답을 만들게 한 용어·매핑·제약 중 무엇이 비어 있었나?”를 기록하면 다음 작업의 출발점이 바뀝니다.
처음부터 모든 데이터를 온톨로지화할 필요는 없습니다. 반복 빈도가 높은 질문 하나를 골라, 원본 근거가 있는 용어·매핑·제약만 작은 지도로 만들고, 후보 수정은 동일 조건 비교를 통과할 때만 반영해 보세요.
작업 환경을 함께 정리한다면
반복되는 의미 오류를 확인할 때는 분석 결과, 정의 문서, 변경 기록을 한 화면에서 대조하기 쉬운 작업 환경이 도움이 될 수 있습니다. 아래 카드의 실제 제품 조건과 호환성은 구매 전에 카드에서 확인하세요.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- arXiv, EvoOntology: A Self-Evolving Ontology Layer for Data Agents (2026-09-14 제출): https://arxiv.org/abs/2609.15779
- 공식 GitHub 저장소 README: https://github.com/ruc-datalab/EvoOntology
- 공식 GitHub Releases: https://github.com/ruc-datalab/EvoOntology/releases
핵심 정리: 다섯 가지 질문과 답
Q. EvoOntology는 데이터 자체를 새로 저장하나요?
아닙니다. 원본을 대체하기보다, 용어·매핑·제약·근거를 조회 가능한 의미 계층으로 다루는 설계입니다.
Q. 왜 컬럼명만으로 부족한가요?
컬럼명과 파일 경로에는 지표 정의, 관계, 제외 조건이 충분히 담기지 않는 경우가 많기 때문입니다.
Q. 세 계층은 무엇인가요?
의미 객체를 담는 Content, 표현 규칙을 정하는 Schema, 런타임 접근을 여는 Tool Layer입니다.
Q. 진화한 수정안은 자동으로 적용되나요?
제안된 흐름에서는 부모 버전과 동일 조건의 쌍 비교를 통과한 후보만 다음 버전으로 채택합니다.
Q. 바로 운영 데이터에 연결해도 되나요?
정식 릴리스 부재와 연구 단계 특성을 고려해, 읽기 전용의 작은 범위와 재현 가능한 평가부터 시작하는 편이 낫습니다.
'AI > AI 최신 기술' 카테고리의 다른 글
| GameHorizon 장기 행동 평가, 짧은 점수로 에이전트를 믿으면 놓치는 것 (0) | 2026.09.22 |
|---|---|
| RecreationWorld, 화면만 닮은 AI 앱을 멈추게 하는 동작 검증 (0) | 2026.09.21 |
| EvoSkill-GUI, 화면 에이전트가 같은 실패를 반복할 때 고치는 곳 (0) | 2026.09.20 |
| When2Think, 쉬운 질문까지 길게 답하는 AI를 어떻게 멈출까 (0) | 2026.09.20 |
| WeVisDoc 평가, 표 점수만 보면 놓치는 것 (1) | 2026.09.19 |
댓글