Ontology for Multi-Agent: 벤더마다 다른 에이전트가 같은 업무 용어를 쓰게 하는 설계
ERP·CRM 벤더가 저마다 에이전트를 내놓으면서 같은 업무 용어가 시스템마다 다른 뜻을 갖는 문제가 다시 커졌습니다. Druid AI 공동창업자 Andreea Pleșea와 CEO Joe Kim은 공통 온톨로지, 한곳의 오케스트레이션과 평가, 쓰기는 결정적 시스템으로 보내는 원칙을 답으로 듭니다. 용어 카드와 6주 시범안을 붙였습니다.
에이전트가 여럿이 되면 어려운 일은 모델 성능보다 같은 단어를 같은 뜻으로 맞추는 일입니다. Druid AI는 업무 개념을 공식 지도로 정리한 온톨로지 위에서 여러 벤더의 에이전트를 한곳에서 지휘하고, 일이 끝났는지 평가하고, 시스템에 쓰는 동작은 기존 결정적 시스템으로 보내자고 말합니다. 따라 하려면 핵심 업무 용어 20~30개를 시스템별 표현과 함께 정의한 용어 카드부터 만들어야 합니다.
요약
diginomica의 George Lawton이 2026년 11월 2일 대화형 AI 에이전트 플랫폼 기업 Druid AI의 공동창업자이자 COO인 Andreea Pleșea, 그리고 2025년 9월 합류한 CEO Joe Kim을 인터뷰했습니다. 출발점은 Pleșea의 2011년 박사 논문입니다. 그는 business ontology(기업 안팎에서 쓰는 업무 개념과 그 관계를 공식적으로 정리한 지도)를 연구했고, 같은 벽돌을 서로 다르게 묘사하는 구매자와 판매자 사이에서 소프트웨어 에이전트가 협상하게 했습니다. 15년이 지나 ERP·CRM 벤더마다 자체 에이전트 플랫폼을 내놓자 같은 문제가 기업 안에서 다시 생겼다는 것이 기사의 문제의식입니다. Pleșea는 이를 두 프로그램이 한 단어의 뜻에 합의하는 일이라고 요약합니다.
해법으로 두 사람은 세 가지를 듭니다. 하나는 벤더별 에이전트를 한곳에서 지휘하는 거버넌스 체계와, 일이 실제로 끝났는지 확인하는 평가 계층입니다. 다음은 프로세스 지도대로 움직이는 자동화 대신 실제 목표를 기준으로 에이전트를 설계하는 것입니다. 마지막은 LLM에는 의미 해석과 추론을 맡기고, 업무 시스템에 쓰는 동작은 로그와 세밀한 통제가 있는 기존 결정적 시스템으로 보내는 것입니다. Kim은 요청을 결정적 경로와 LLM 경로로 나누는 router 방식이 지금 가장 흔하다고 보면서, 두 경로를 섞어 쓸 수 없다는 점과 LLM 쪽 에이전트를 가두기 어렵다는 점을 문제로 짚습니다. 아래에서는 이 주장을 다섯 개념으로 풀고 용어 카드와 시범 계획을 덧붙입니다.
핵심 메커니즘
Business Ontology: 업무 개념과 관계의 공식 지도
무엇인가. 기업 안과 기업 사이에서 쓰는 업무 개념(제품, 고객, 주문, 계약 등)과 그 관계를 공식적으로 정의해 둔 지도입니다. 사람이 읽는 용어집과 달리 프로그램이 읽고 대조할 수 있게 만듭니다.
어떻게 작동하나. 입력은 서로 다른 시스템이나 사람이 쓰는 표현입니다. 온톨로지는 각 표현을 하나의 개념에 연결하고, 동의어와 속성, 다른 개념과의 관계를 함께 적어 둡니다. 에이전트는 상대가 쓴 단어를 이 지도에서 찾아 같은 개념인지 확인한 뒤 대화를 이어 갑니다. 출력은 양쪽이 합의한 개념과 값입니다.
원문의 예. Pleșea의 박사 논문에서는 판매자는 동의어를 섞어 벽돌을 소개하고 구매자는 자기 방식으로 구체적인 요구를 냈습니다. 에이전트가 협상하려면 먼저 공통 기반을 찾아야 했습니다. 그는 이것이 지금 사용자 의도를 실제로 일하는 에이전트에 연결하는 문제와 같다고 봅니다. 원문은 논문의 매칭 방식 자체는 자세히 설명하지 않습니다.
언제 쓰나. 둘 이상의 시스템이나 에이전트가 같은 대상을 다르게 부를 때 씁니다. 에이전트 하나가 시스템 하나만 다루면 우선순위가 낮습니다.
작은 예시(가상). 구매 에이전트는 ‘공급사’, SCM 에이전트는 ‘벤더’, ERP는 LIFNR라고 부르는 대상을 온톨로지에서 Supplier 한 개념으로 묶어 두면, 세 에이전트가 같은 공급사를 두고 대화할 수 있습니다.
Vocabulary Problem: 벤더 에이전트가 되살린 조각난 정보
무엇인가. ERP·CRM마다 자체 에이전트가 생기면서, 직원이 질문 하나에 답을 얻으려고 여러 에이전트를 돌아다녀야 하는 상태입니다. Pleșea는 이를 single point of truth(믿고 기댈 단일 기준점)가 없는 상태로 봅니다.
어떻게 작동하나. 사용자는 Salesforce 정보를 얻으려 그 에이전트에 묻고, 다른 CRM 정보는 그 CRM의 에이전트에 다시 묻습니다. 에이전트마다 자기 시스템의 용어와 범위만 알기 때문에 답을 잇는 일은 사람에게 남습니다. 직원 PC에서 돌아가는 데스크톱 에이전트가 늘면 무엇을 하는지 통제하고 측정하고 감사하기가 더 어려워집니다.
원문의 예. Pleșea는 박사 과정 뒤 루마니아 업무 소프트웨어 기업 TotalSoft에서 ERP 위에 셀프서비스 앱을 만드는 일을 이끌었습니다. 직원들이 여러 시스템에 흩어진 정보를 찾기 어려웠기 때문입니다. 그는 지금 벤더 에이전트가 그때의 단편화를 되풀이한다고 봅니다.
언제 문제가 되나. 업무 하나가 두 시스템 이상에 걸칠 때, 그리고 부서마다 다른 벤더 에이전트를 따로 도입할 때 커집니다.
Orchestration and Evaluation Layer: 여러 벤더 에이전트를 지휘하고 결과를 확인하는 층
무엇인가. 자사 플랫폼의 에이전트와 다른 벤더 플랫폼의 에이전트를 함께 지휘하고, 그 위에서 맡긴 일이 실제로 끝났는지 평가하는 계층입니다. Druid가 지향하는 구조로 소개됩니다.
어떻게 작동하나. 사용자 요청을 받으면 오케스트레이터가 어느 에이전트에 맡길지 정하고 결과를 모읍니다. 평가 계층은 응답이 그럴듯한지보다 업무가 완료됐는지를 봅니다. 모든 호출이 한곳을 지나므로 통제와 측정, 감사도 한곳에서 할 수 있습니다. 원문은 평가가 완료 여부를 어떻게 판단하는지 구체적인 방식은 밝히지 않습니다. 아래 기술 디테일에서 실행안을 덧붙입니다.
언제 쓰나. 벤더 에이전트가 셋 이상이거나 데스크톱 에이전트를 허용할 때, 감사 대응이 필요한 업무를 에이전트에 맡길 때 필요합니다.
Work as Designed vs Work as Done: 지도대로가 아니라 목표대로
무엇인가. Joe Kim이 쓰는 대비입니다. work as designed는 문서에 그려진 업무 절차, work as done은 사람들이 목표를 이루려고 실제로 하는 일입니다.
어떻게 작동하나. RPA는 정해진 클릭과 입력을 흉내 내 시스템 사이로 데이터를 옮깁니다. 지도를 그대로 따르는 방식입니다. Kim은 영업 담당자의 목표는 거래를 닫는 것이지 절차를 지키는 것이 아니라는 예를 듭니다. 그래서 에이전트를 단계별로 매핑하지 말고, 처음부터 행동과 신뢰를 기준으로 설계하고 전 과정을 모니터링해야 한다고 말합니다.
원문의 예. 2018년 Druid는 자사 챗봇을 UiPath 로봇에 연결해, 대화로 오래 걸리는 백오피스 작업을 시작시키고 결과나 예외를 다시 대화로 알려 주게 했습니다. Pleșea는 RPA가 백오피스를 맡았지만 정작 고객은 그 자동화에 직접 닿지 못했다고 봅니다. 두 회사는 몇 년간 협력했고 지금은 경쟁 관계입니다.
Deterministic Write Path와 Router: 해석은 LLM, 쓰기는 기존 시스템
무엇인가. 초기 대화형 플랫폼은 사용자의 말을 미리 정한 intent(의도)에 맞추고 slot(필요한 값 칸)을 채웠습니다. Kim은 LLM 덕분에 의미를 훨씬 유연하게 해석할 수 있게 되어, Pleșea가 논문에서 다룬 일을 이제는 규모 있게 할 수 있다고 봅니다. 다만 정확도 요구는 쓰임새에 따라 다릅니다.
어떻게 작동하나. 아는 사람이 읽는 요약은 정확도가 조금 낮아도 됩니다. 의사결정, 업무 시스템에서 일어나는 동작, 고객·직원 개인정보 처리는 100%에 가까운 정확도가 필요합니다. 그래서 LLM은 추론을 맡고, 업무 시스템에 쓰는 일은 기업이 이미 운영하는 결정적 시스템을 거쳐 로그와 세밀한 통제 아래 이뤄져야 한다는 것이 Kim의 입장입니다. 그는 LLM이 알아서 처리하게 두는 방식을 피해야 할 예로 듭니다.
원문의 예. Kim에 따르면 지금 가장 흔한 방식은 router가 요청을 결정적 워크플로 경로나 LLM 경로 중 한쪽으로 보내는 구조입니다. 문제는 둘입니다. 요청이 한쪽 경로에만 들어가 둘을 섞어 쓰는 처리가 안 되고, 통제가 약한 LLM 쪽 에이전트가 containment(행동 범위를 가두는 일) 문제를 일으킵니다.
통념과 다른 주장
흔히 이렇게 봅니다쓰고 있는 ERP·CRM 벤더가 제공하는 에이전트를 붙이면 그 시스템의 AI 도입은 해결된다.
Pleșea는 이렇게 봅니다벤더별 에이전트는 2011년의 정보 단편화를 다시 만든다. 에이전트를 한곳에서 지휘하는 거버넌스 체계가 필요하다.
근거Salesforce 정보는 그 에이전트에, 다른 CRM 정보는 또 다른 에이전트에 물어야 하는 상황을 예로 듭니다. TotalSoft에서 ERP 위에 셀프서비스 앱을 만든 이유도 흩어진 정보였습니다.
흔히 이렇게 봅니다LLM이 의미를 잘 이해하니 업무 시스템 처리까지 에이전트에 맡기면 된다.
Kim은 이렇게 봅니다LLM은 추론을 맡고, 업무 시스템에 쓰는 일은 로그와 통제가 있는 기존 결정적 시스템으로 보내야 한다.
근거의사결정, 시스템 동작, 개인정보 처리는 100%에 가까운 정확도가 필요하다고 봅니다. 흔한 router 구조에서는 통제가 약한 LLM 쪽이 containment 문제를 일으킨다고 짚습니다.
저자가 든 사례
벽돌 협상 에이전트 (2011년 박사 논문)
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 구매자와 판매자가 같은 벽돌을 다른 말과 동의어로 묘사 | 업무 개념과 관계를 정리한 business ontology로 에이전트가 협상하게 함 | 매칭 방식과 수치는 원문에서 밝히지 않음 | Business Ontology. 지금은 사용자 의도와 일하는 에이전트를 잇는 문제로 이어짐 |
TotalSoft의 ERP 셀프서비스 앱
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| 직원들이 여러 시스템에 흩어진 정보를 찾기 어려움 | Pleșea가 ERP 위에 셀프서비스 앱 개발을 이끎 | 성과 수치는 원문에서 밝히지 않음 | Vocabulary Problem. 벤더 에이전트가 같은 단편화를 되풀이한다는 주장의 출발점 |
Druid 챗봇과 UiPath 로봇 연동 (2018년)
| 상황 | 한 일 | 결과 | 연결 |
|---|---|---|---|
| RPA는 백오피스를 자동화했지만 고객은 그 자동화에 직접 닿지 못함 | 챗봇 대화로 오래 걸리는 백오피스 작업을 시작하고 결과·예외를 대화로 알림 | 두 회사가 몇 년간 협력, 지금은 경쟁 관계 | Work as Done. 대화 앞단과 실행 뒷단을 잇는 구조 |
기술 디테일: 용어 카드에서 쓰기 경로까지
Business Ontology를 실제로 돌리려면 처음부터 완전한 온톨로지를 만들지 말고, 에이전트가 자주 부딪히는 업무 용어 20~30개로 용어 카드를 만듭니다. 카드 하나가 개념 하나이고, 시스템마다 다른 이름과 필드를 함께 적습니다. LLM에게는 이 카드 목록을 검색 근거로 주고, 사용자 표현을 개념 ID로 바꾸는 일만 구조화 출력으로 시킵니다. 아래 필드명은 가상 예시입니다.
{
"concept_id": "Supplier",
"definition": "구매 계약을 맺고 자재를 공급하는 외부 기업",
"synonyms": ["공급사", "벤더", "협력사"],
"system_mappings": [
{"system": "ERP", "field": "LIFNR", "agent": "erp_agent"},
{"system": "CRM_B", "field": "account.vendor_code", "agent": "crm_b_agent"}
],
"relations": [{"type": "supplies", "target": "Material"}],
"owner": "구매팀",
"version": "2026-11-05"
}Vocabulary Problem을 줄이려면 사용자 질문을 받는 첫 단계에서 LLM이 {"concept_id", "confidence", "matched_synonym", "candidates"}를 JSON으로 내게 합니다. temperature는 0으로 두고 같은 질문을 3회 돌려 개념 ID가 갈리면 사람에게 되묻습니다. confidence가 0.8 아래이거나 후보가 둘 이상이면 “공급사 기준인가요, 협력사 전체인가요?”처럼 확인 질문을 냅니다. 카드에 없는 표현이 나오면 unmapped_terms 로그에 쌓아 주 1회 카드 소유자가 동의어로 추가할지 정합니다.
Orchestration and Evaluation Layer의 완료 평가를 만들려면 업무 유형마다 “끝났다”를 시스템 상태로 정의합니다. 예를 들어 “발주 변경 요청”은 ERP 발주 문서의 변경 이력이 생기고 상태가 released인지 조회해 확인합니다. 평가는 에이전트의 답변이 아니라 기록 시스템을 다시 읽어 판정합니다. 호출마다 request_id, agent, concept_ids, action, system_of_record_check, result(done|partial|failed)를 남기면 감사와 벤더 에이전트 비교에 그대로 씁니다.
Deterministic Write Path를 지키려면 LLM이 직접 API를 부르지 않게 합니다. LLM은 proposed_action JSON만 내고, 검증 단계가 온톨로지(개념·필드 존재), 스키마(값 형식), 권한(요청자 역할)을 확인한 뒤 기존 워크플로나 API가 실행합니다. 정확도 요구는 아래처럼 세 등급으로 나눕니다(가상 예시).
| 등급 | 예 | 처리 |
|---|---|---|
| 요약·조회 | 거래처 현황 요약 | LLM 응답 그대로, 출처 표시 |
| 의사결정 보조 | 발주 우선순위 제안 | LLM 제안 + 사람 승인 |
| 쓰기·개인정보 | 발주 변경, 고객 정보 수정 | 결정적 시스템만 실행, 전 건 로그 |
Router의 두 문제를 피하려면 요청을 한 경로로만 보내지 말고 한 요청 안에서 단계를 나눕니다. 해석과 계획은 LLM, 조회와 쓰기는 결정적 도구로 처리하는 하이브리드 순서입니다. containment는 에이전트별 허용 도구 목록, 쓰기 가능한 개념 ID 목록, 호출 횟수 상한(요청당 10회 등)으로 가둡니다.
| 막히는 경우 | 대응 |
|---|---|
| 같은 질문에 개념 ID가 회차마다 다름 | 3회 실행 결과가 갈리면 확인 질문, 해당 동의어를 카드에 보강 |
| 벤더 에이전트가 자기 용어로만 답함 | 오케스트레이터가 응답을 개념 ID로 다시 매핑한 뒤 합침 |
| 데스크톱 에이전트 호출이 로그에 안 잡힘 | 오케스트레이터 경유가 아닌 쓰기 권한 회수 |
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 맡는 일 |
|---|---|
| AX 추진 리더 | 시범 업무 선정, 벤더 에이전트 현황 취합, 확대 판정 |
| 도메인 오너(구매·영업 등 1개 부서) | 용어 카드 정의 승인, 동의어 추가 결정 |
| 엔터프라이즈 아키텍트 | 시스템별 필드 매핑, 오케스트레이터와 쓰기 경로 설계 |
| 데이터·AI 엔지니어 | 개념 매핑 프롬프트, 검증 단계, 완료 평가 쿼리 구현 |
| 보안·감사 담당 | 에이전트별 권한 목록, 로그 보존 기준 |
준비물. 지금 쓰거나 도입 예정인 벤더 에이전트 목록(ERP·CRM·데스크톱 포함), 시범 업무에서 자주 나오는 질문 50개, 그 업무가 걸친 시스템과 필드 목록, 부서별로 이름이 같은데 뜻이 다른 용어 목록이 필요합니다.
| 기간 | 할 일 | 산출물 |
|---|---|---|
| 1~2주 | 에이전트 현황 조사, 질문 50개에서 용어 추출 | 에이전트 지도, 용어 카드 초안 20~30개 |
| 3~4주 | 개념 매핑과 확인 질문 구현, 쓰기 경로 검증 단계 연결 | 매핑 정확도, unmapped_terms 목록 |
| 5~6주 | 업무 유형별 완료 평가 쿼리 운영, 로그로 벤더 에이전트 비교 | 완료율 보고서, 확대 여부 판정 |
현업에 물을 것.
- 한 질문에 답하려고 지금 몇 개 시스템이나 에이전트를 거치나요?
- 부서마다 같은 말인데 뜻이 다른 용어는 무엇인가요(예: 고객, 매출, 공급사)?
- 에이전트가 시스템에 직접 쓰면 안 되는 업무는 무엇인가요?
- 이 업무가 “끝났다”는 것을 시스템에서 무엇으로 확인하나요?
- 직원 PC에서 쓰는 에이전트는 누가 승인했고 어디에 기록이 남나요?
진행 판정 기준(예시). 6주 차에 질문 50개 중 개념 매핑 정확도가 90% 이상, 완료 평가로 확인한 완료율이 80% 이상이고, 쓰기 동작이 전부 결정적 경로와 로그를 거쳤다면 다음 부서로 넓힙니다. 매핑 정확도가 낮으면 카드의 동의어와 정의를 보강하고 2주를 더 봅니다.
AX 적용 제언. 벤더 에이전트 도입 결정이 부서별로 나는 조직일수록 먼저 할 일은 새 플랫폼 구매가 아니라 용어 카드의 소유권을 정하는 일입니다. 구매·영업처럼 시스템을 셋 이상 오가는 업무 하나를 골라 카드와 완료 평가를 먼저 만들고, 이후 벤더 에이전트 계약에 “개념 ID로 입출력할 수 있는가, 호출 로그를 넘겨주는가”를 평가 항목으로 넣으면 지식 그래프·온톨로지 투자와 에이전트 도입을 한 줄로 묶을 수 있습니다. 이미 데이터 거버넌스 조직이 있다면 용어 카드는 그 조직의 업무 용어집을 확장하는 방식으로 맡기는 편이 빠릅니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 기사 | diginomica, George Lawton, 2026.11.02 |
| 인터뷰 대상 | Andreea Pleșea(Druid AI 공동창업자·COO), Joe Kim(Druid AI CEO·President, 2025년 9월 합류, 전 Sumo Logic) |
| 핵심 주장 | 벤더별 에이전트가 용어 정의를 갈라 놓으므로 온톨로지와 한곳의 지휘·평가가 필요 |
| 언급 사례 | 2011년 벽돌 협상 에이전트 논문, TotalSoft ERP 셀프서비스 앱, 2018년 Druid와 UiPath 연동 |
| 언급 기업 | Druid AI, TotalSoft, UiPath, Salesforce, Sumo Logic, Automation Anywhere, Blue Prism |
| 기술 원칙 | LLM은 추론, 쓰기는 결정적 시스템과 로그, router의 두 문제(혼합 불가, containment) |
| 기자의 시각 | RPA 벤더(UiPath, Automation Anywhere, Blue Prism)가 agent-to-agent 소통으로 옮겨 가고 ERP·CRM·통합·모델 기업도 각자 에이전트 계층에 접근 중, 아직 진행 중인 영역 |
핵심 개념
- RPA
- 사람의 클릭과 입력을 흉내 내 API가 부족한 시스템 사이로 데이터를 옮기는 소프트웨어 로봇입니다.
- intent / slot
- 초기 챗봇 방식입니다. 사용자의 말을 미리 정한 의도로 분류하고 처리에 필요한 값 칸을 채웁니다.
- single point of truth
- 여러 시스템과 에이전트가 함께 기대는 단일 기준점입니다.
- containment
- 에이전트가 허용된 범위 밖으로 행동하지 않게 가두는 일입니다.
- agent-to-agent
- 에이전트끼리 직접 요청과 결과를 주고받는 방식입니다. 기자는 RPA 벤더들이 이쪽으로 옮겨 간다고 봅니다.
- 용어 카드
- 이 노트의 실행 제안입니다. 개념 하나의 정의, 동의어, 시스템별 필드, 소유자를 한 장에 적습니다.
내 메모
TODO: 내 생각 추가
원문은 diginomica에 실린 George Lawton의 「How ontology is re-shaping the future of multi-agent systems. Druid AI’s founder explains what’s happening」(2026.11.02)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 기사에 나온 Andreea Pleșea와 Joe Kim의 발언과 기자의 해설을 AX Review가 다시 정리했습니다. 용어 카드와 JSON 예시, 정확도 등급표, 처리 흐름, 막히는 경우 표, 역할·일정·질문·판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 인터뷰는 원문에서 볼 수 있습니다.