온톨로지가 진짜 가드레일: AI 에이전트의 비즈니스 오해 방지

왜 에이전트는 비즈니스를 ‘이해’하지 못하는가

기업들은 비즈니스 프로세스 혁신을 위해 AI 에이전트와 인프라에 막대한 자금을 투입하고 있지만, 실제 현장에서는 데이터의 의미, 사내 정책, 업무 절차를 에이전트가 제대로 파악하지 못해 성과가 제한되는 경우가 잦다. API 관리나 MCP 같은 통합 기술은 성숙해졌지만, 각 조직 문맥에서 데이터가 ‘무엇을 뜻하는지’를 이해시키는 일은 별개의 과제다. 엔터프라이즈 데이터는 구조화·비구조화 형태로 서로 다른 시스템에 흩어져 있으며, 도메인 관점에서 해석되어야 한다. 예컨대 ‘customer’는 영업 CRM에서는 잠재/기존 고객을, 재무 시스템에서는 비용을 지불하는 거래처를 가리킬 수 있다. 한 부서는 ‘product’를 SKU로, 다른 부서는 제품군으로, 또 다른 부서는 마케팅 번들로 정의한다. 이처럼 공통 정의와 관계 합의가 없으면 ‘product sales’의 의미도 시스템마다 달라진다. 또한 스키마 변경과 수집 단계의 데이터 품질 문제는 모호성을 키워 에이전트가 어떻게 행동해야 할지 판단을 흐리게 만든다. 더 나아가 PII 분류 등 GDPR·CCPA 준수 요건을 지키려면 데이터 라벨링이 정확해야 하고, 에이전트는 해당 분류를 이해하고 준수해야 한다. 멋진 데모를 만드는 건 쉽지만, 실제 업무 데이터로 운영에 투입하는 일은 전혀 다른 난이도의 문제다.

온톨로지 기반 단일 진실 공급원

온톨로지는 비즈니스 개념, 위계, 관계를 정의하는 체계로, 도메인 관점에서 용어를 표준화하고 필드 명칭을 일관되게 수립하며 분류 체계를 적용해 데이터의 단일 진실 공급원(SSOT)을 마련하도록 돕는다. 이 체계는 의료·금융 등 도메인별 혹은 조직 구조에 맞춘 사내 표준으로 설계할 수 있고, 초기에 시간이 들지만 프로세스 표준화와 에이전트형 AI의 토대를 제공한다. 구현 방식으로는 질의가 쉬운 트리플스토어를 사용할 수 있고, 다단계 관계와 복잡한 규칙은 Neo4j 같은 라벨드 프로퍼티 그래프가 유리하다. 그래프는 신규 관계 발견과 복잡 질의에 강하며, 공개 표준인 FIBO(금융)·UMLS(의료)는 좋은 출발점이지만 기업 맥락에 맞춘 커스터마이징이 필요하다.

그래프와 쿼리 모델 선택

트리플스토어는 표준화된 서술·추론에, 라벨드 프로퍼티 그래프는 경로 탐색과 다중 홉 관계 규칙에 강점을 가진다. 어떤 모델을 선택하든 핵심은 비즈니스 용어의 충돌을 제거하고, 필드 명과 분류를 일원화하여 이후 분석·거버넌스·감사를 일관되게 수행하는 것이다.

온톨로지로 에이전트를 그라운딩하는 방법

정의된 체계를 기준으로 에이전트를 프롬프트해 데이터와 관계를 탐색하게 하고, 필요하면 에이전트 계층이 해당 체계의 핵심 메타데이터를 서비스하도록 구성할 수 있다. 업무 규칙과 정책을 이 구조에 구현하면 에이전트는 현실의 비즈니스 맥락에 기반한 가드레일을 따르게 되고, 이를 통해 LLM이 유발하는 환각을 줄일 수 있다. 예를 들어 ‘대출 관련 모든 문서의 검증 플래그가 true가 아니면 대출 상태를 보류로 유지한다’라는 정책을 정의하고, 에이전트가 필요한 문서를 스스로 식별해 지식베이스를 조회하도록 만들 수 있다.

예시 아키텍처와 프로토콜

구조화·비구조화 데이터를 문서 인텔리전스(DocIntel) 에이전트가 수집·정규화하여, 도메인 정의에 따라 Neo4j 지식 그래프를 채운다. 데이터 디스커버리 에이전트는 이 그래프에서 적합한 데이터를 찾아 질의하고, 결과를 업무 프로세스 실행 에이전트에 전달한다. 에이전트 간 통신은 A2A(agent-to-agent) 같은 표준 프로토콜을 사용하고, AG-UI(Agent User Interaction)는 에이전트의 동작과 응답을 수집·표시하는 범용 UI를 구성하는 데 도움이 된다.

실제 적용 예시

대출 심사 정책 체크리스트

대출 신청서는 필요한 문서 목록과 검증 플래그 기준을 명시하고, 관련 개체(신청인, 계정, 담보, 거래) 간 추적 가능성을 확보해야 한다. PII는 수집 시점에 라벨링하고 GDPR·CCPA 기준에 맞춰 접근·보존·마스킹 규칙을 적용한다. 용어 매핑(예: customer/account/borrower)과 스키마 변경 시 하위 호환 규칙, 메타데이터 누락 시의 보류·재요청 절차를 함께 정의한다.

에이전트 오케스트레이션 단계별 흐름

1) 문서 수집·추출 → 2) 품질·일치성 점검 → 3) 그래프 반영·정합성 검사 → 4) 데이터 디스커버리 질의 → 5) 정책 규칙 평가 → 6) 상태 업데이트·사후 감사. 만약 에이전트가 ‘가상의 고객’을 추론해도, 연결 데이터가 검증 단계에서 확인되지 않으면 이상으로 감지되어 차단·수정·에스컬레이션된다.

확장성과 거버넌스 이점

이 온톨로지 접근법은 개별 에이전트가 아닌 시스템 전반의 규칙으로 환각을 제어하고, 자산·관계·정책을 추가해도 자동 준수를 보장하므로 확장에 유리하다. 그래프 기반 발견 과정은 조작·오탐을 조기에 드러내며, 데이터 디스커버리와 그래프 운영의 오버헤드가 있더라도 대규모 기업에는 복잡한 프로세스를 조율할 가드레일과 방향성을 제공한다.