화산엔진, 지식엔진 VeKnow로 에이전트 판단 오류 문제 짚어

이해와 활용의 주체가 Agent로 바뀌었을 때, 기업 온톨로지(기업 본체)는 어떻게 업무 이해와 행동을 뒷받침해야 하는가? 먼저 기업이 매일 마주하는 문제부터 살펴보자.

이 글은 화산엔진 지식엔진 VeKnow의 업무 실천 고민에서 비롯되었다. 화산엔진 지식엔진 VeKnow는 기업급 AI 지식 기반으로서, 대형 모델과 빅데이터 기술을 바탕으로 지식 접속, 가공 처리, 지식 모델링부터 지능형 질의응답까지의 전链路(전 과정) 지식 관리와 응용 역량을 제공하여 기업 지식이 진정으로 흐르게 하고, 업무 속에서 지속적으로 가치를 창출하도록 한다.

一、기업 온톨로지가 표현하는 것은 어떤 업무 세계인가?

2000여 년 전 아리스토텔레스는 《형이상학》에서 "존재하는 것으로서의 존재"라는 물음을 던졌다. 철학자들은 이러한 물음을 '존재론'(Ontology)이라 불렀다. 즉, 세계에는 도대체 무엇이 있으며, 어떤 방식으로 존재하고, 서로 어떤 관계를 맺고 있는가 하는 것이다.

같은 물음을 기업은 매일 던진다. 애프터서비스는 한 건의 수리 접수 작업지시가 어느 설비와 관련되고, 어떤 부품이 장착되어 있으며, 어떤 구성이 변경되었고, 이전에 몇 번 수리했는지, 이번 부품 교체가 다른 부품에 영향을 줄지를 파악해야 한다. 리스크 관리 부서는 '고객' 뒤에 어떤 계좌들이 연결되어 있고, 이 계좌들 간의 이체에 이상한 연관 관계가 있는지를 알아야 한다. 각 직무, 각 시스템의 이면에서 모두 같은 질문군에 답하고 있다. 즉, 업무 세계에는 어떤 객체들이 있으며, 그것들이 어떻게 연결되고, 어떤 규칙에 제약받는가 하는 것이다.

업무 세계에 대한 이러한 표현이 바로 '기업 온톨로지'이다.

예를 들어 이커머스 주문 번호, 상품, 금액, 수취인 등의 데이터와 주문과 상품의 연관 관계는 업무 시스템에 모두 저장할 수 있다. 그러나 Agent가 진정으로 이를 이해하고 업무에 활용하게 하려면 다음을 알아야 한다. 몇 개의 상품이 같은 매장에서 묶여 발송되는지, 환불이 전체 주문 환불에 해당하는지 단일 상품 환불에 해당하는지, 주문에 적용되는 할인 혜택 규칙은 무엇인지 등이다. 이러한 시스템 간 업무적 의미, 규칙 적용 범위와 버전 정보는 데이터, 코드, 문서에 흩어져 있는 경우가 많다.

기업 온톨로지가 해야 하는 일은 바로 이러한 객체, 관계와 제약을 통일적으로 표현하여 사람과 Agent가 모두 일관된 업무 의미 아래에서 이들을 활용할 수 있게 하는 것이다.

과거에 기업이 업무 세계의 관계망을 구축하려면 업무 전문가와 엔지니어가 반복적으로 조율하며 자료를 읽고, 객체를 정의하고, 관계를 보완하고, 변경에 뒤따라야 하는 경우가 많았다. 구축도 어렵고 지속적으로 운영하기는 더 어려워서, 많은 기업이 남긴 것은 제각각인 데이터 테이블과 PPT에 적힌 방법론뿐이었다.

Agent Native 시대의 도래는 처음으로 이 일에 새로운 해법을 열어주었다. 대형 모델이 이끄는 Agent가 대량의 읽기, 정리, 단계 구성을 담당하면서 지식 공학이 항목별로 인력에 의존하던 비용 구조가 흔들리기 시작했고, 사람의 역량은 목표, 표준과 핵심 판단에 더 많이 쏟을 수 있게 되었다.

업무 세계는 표현되어야 한다는 명제는 변하지 않았다. 다만 이 표현을 구축하고 유지하는 방식이 새롭게 다시 쓰이고 있다.

二、규칙 하나를 찾았다고 해서 현재 업무에 적용된다는 뜻은 아니다

그렇다면 범용 Agent를 연결하면 기업 온톨로지가 자동으로 구축되고 지속적으로 활용될 수 있을까?

예를 들어 리테일 고객 서비스 시나리오에서 사용자가 "이 주문을 반품할 수 있나요?"라고 물으면, 범용 Agent는 도구를 호출하고 문서를 읽은 뒤 "7일 무조건 반품에 부합하므로 환불을 신청할 수 있습니다"라고 답한다. 하지만 실제로 이 주문은 라이브 방송 특별전의 한정 기간 이벤트에서 발생한 것으로, 제3자 채널을 통해 이루어졌고, 상품은 맞춤형 카테고리에 속하며, 반품·교환 규칙은 이벤트 시작 직전에 한 차례 개정된 상태였다. Agent는 분명 '반품·교환 규칙' 하나를 찾았지만, 판매 채널, 상품 카테고리, 이벤트 회차와 규칙 효력 발생 시점을 동시에 식별하지 못한 채, 결국 관련은 있지만 현재 주문에는 적용되지 않는 규정을 인용한 것이다.

잘못한 것은 모델이 아니라, 그 배후에 '규칙—채널—카테고리—이벤트—효력 시점'의 실제 관계를 표현할 수 있는 온톨로지를 사용할 수 없었다는 점이다. 조항은 보이지만 적용 경계는 보이지 않고, 답변을 생성할 수는 있지만 검증할 수는 없다.

기업이 매일 Agent 위에서 내리는 결정이 많아질수록, 온톨로지 부재가 초래하는 잠재적 오류는 더 크게 증폭되고 대가도 더 커진다.

화산엔진 지식엔진 VeKnow 제품은 Agent가 지속적으로 사용할 수 있는 방식으로 기업이 온톨로지를 구축하도록 돕고, 납품 가능하고 협업 가능하며 지속적으로 최적화 가능한 지식 컴파일 역량을 제공하여, 업무 목표와 Agent 실행, 인간-기계 협업이 동일한 링크에 들어가게 하고, 기업 온톨로지가 '구축된 결과물'에서 점차 '지속적으로 운영되는 시스템'으로 변하게 한다. 구체적으로 이 제품화 역량은 세 가지 핵심점에 구현된다.

첫 번째 역량은 제품 역량을 Agent가 조합할 수 있는 도구로 만드는 것이다. 지식 컴파일은 고정된 페이지 흐름이 아니며, 서로 다른 업무 목표에 직면하여 Agent는 자료 읽기, Schema 생성, 인스턴스 추출, 자산 조회, 버전 갱신과 평갗 등 역량을 서로 다른 순서로 조합해야 할 수 있다. VeKnow는 CLI를 통해 이러한 역량을 호출 가능하고 조합 가능한 도구로 캡슐화하여, Agent가 목표, 현재 상태와 피드백에 따라 다음 단계를 자율적으로 계획할 수 있게 하며, 각 시나리오마다 고정된 흐름을 다시 개발할 필요가 없도록 한다.

CLI는 동시에 실행 과정에 통제 가능한 경계를 제공한다. 핵심 동작은 명시적으로 확인할 수 있고, 작업 상태와 중간 결과는 보존할 수 있으며, 실패한 단계는 부분적으로 재시도할 수 있고, 중단된 작업은 기존 컨텍스트를 기반으로 이어서 수행할 수 있다. 개발자는 역량을 안정적으로 공급하는 것을, Agent는 작업을 조직하는 것을, 사람은 목표와 핵심 판단을 맡으며, 이 셋이 함께 실제 납품을 지향하는 Agent Harness를 구성한다.

두 번째 역량은 온톨로지의 자동 구축이다. 전통적인 프로젝트에서 업무 전문가와 온톨로지 모델링 엔지니어는 반복적으로 소통하며 자료 해석, 객체 정의, 관계 설계, 인스턴스 채우기와 규칙 구성을 항목별로 완료해야 했고, 이 과정 전체는 느리고 무거웠다. VeKnow는 이러한 작업을 Agent가 실행할 수 있는 지식 컴파일 작업으로 재구성한다. 시스템은 권한 범위 내의 기업 지식을 읽고, 업무 객체, 속성, 관계와 제약을 식별하며, Schema 제안을 생성하고, 나아가 인스턴스 추출과 온톨로지 구축을 완료한다.

자동화라고 해서 업무 판단을 건너뛰는 것은 아니다. 업무 전문가는 목표와 경계를 정의하고, Schema, 핵심 관계와 충돌 항목 등의 지점에서 심사한다. Agent는 수정 의견에 따라 컨텍스트를 갱신하고 계속 실행한다. 기술적 모델링은 시스템이 담당하고, 사람은 업무 의미와 예외 문제를 집중적으로 처리하므로, 역할 간 협업 비용을 낮추는 동시에 모든 결과가 원자료와의 대응 관계를 유지하여 검토와 추적이 용이하도록 한다.

세 번째 역량은 모든 최적화가 평갗으로 검증될 수 있게 하는 것이다. 온톨로지 버전이 바뀌었다고 해서 그것이 자연히 품질 향상을 의미하지는 않는다. VeKnow는 평갗을 지식 컴파일 폐루프에 내장한다. 먼저 업무 목표를 중심으로 평가 범위, 평갗 세트, 표준 답안과 평가 차원을 정하고, 현재 산출물을 표준과 대조하여 객체, 관계, 용어 또는 인스턴스 차원의 격차를 찾아내고, 원자료와 결합하여 원인을 분석하고 최적화 제안을 생성한다.

수정이 완료되면 새 버전은 동일한 기준으로 다시 측정되며, 예상한 문제가 해결되었는지 확인하는 동시에 다른 부분에서 퇴보가 발생했는지도 관찰한다. 평갗 세트, 표준 답안, 산출물 버전과 결과는 자산과 함께 축적되어, 품질 변화를 측정할 수 있고, 문제 위치를 추적할 수 있으며, 최적화 경험을 재사용할 수 있게 하므로, 기업 온톨로지는 실제 업무 피드백 속에서 지속적으로 진화할 수 있다.

三、Action을 Agent의 행동 언어로 만들기

업무를 이해한 뒤, Agent는 이제 직접 행동을 시작해야 한다.

단지 온톨로지 객체에 함수를 잔뜩 붙여 놓고 Agent가 그것을 보고 호출하게만 하면, 해결되는 것은 "입구가 어디인가"뿐이다. 기업이 진짜 관심을 두는 것은 또 다른 문제군이다. Agent가 지금 무엇을 할 수 있는지, 왜 할 수 있는지, 하고 나면 어떻게 되는지를 이해하고, 그 판단을 바탕으로 행동을 조직할 수 있는가 하는 것이다.

"주문 취소"를 예로 들면, 미발송 상태에서는 바로 취소하고 환불할 수 있다. 이미 발송된 경우에는 먼저 물류를 차단하거나 반품 절차로 들어가야 할 수 있다. 환불에 실패하면 주문은 "환불 완료"로 표시될 수 없고, 차단에 실패하면 이후 경로도 그에 따라 바뀌어야 한다. 같은 "주문 취소" 하나에도 그 배후에는 상태에 따라 달라지는 의사결정 그래프가 실제로 존재한다.

앞으로 Action이 하려는 것은 한 번의 비즈니스 상태 변화를 하나의 실행 가능한 계약으로 캡슐화하는 것이다. 사전 조건은 할 수 있는지 여부를 결정하고, 권한 경계는 누가 할 수 있는지를 결정하며, 예상 영향은 무엇이 바뀌는지를 정의하고, 실패 처리는 예외 상황을 어떻게 수습할지를 제약한다. Agent는 목표를 이해하고 경로를 계획하며 동작을 조합하는 일을 맡고, 시스템은 조건을 검증하고 작업을 실행하며 결과를 확인하고 상태를 다시 기록하는 일을 맡는다.

이 둘이 합쳐져야 비로소 Agent는 기업의 비즈니스 프로세스 안으로真正 들어갈 수 있고, 규칙 안에서 더 정확하게, 복잡한 상황에서 더 안정적으로 나아갈 수 있다.