AI 에이전트를 위한 이식성 높은 비즈니스 온톨로지

‘온톨로지’라는 용어가 요즘 유행하고 있습니다. 왜일까요? 에이전트와 에이전트를 구동하는 LLM에는 관련 비즈니스 맥락이 필요하기 때문입니다.

온톨로지를 도입하기 전에 공급업체에 이렇게 물어보세요. “온톨로지가 우리 비즈니스를 잘못 반영하면 직원들이 어떻게 바로잡을 수 있나요? 그리고 그 과정에서 여전히 공급업체에 의존해야 하는 부분은 무엇인가요?” 답변을 들으면 누구의 비즈니스 모델을 도입하게 되는지 상당 부분 알 수 있습니다. 또한 더 큰 문제도 드러납니다. 비즈니스가 변할 때 그 모델을 개선할 수 있는지, 플랫폼을 바꾸더라도 그 투자를 계속 유용하게 활용할 수 있는지 하는 문제입니다.

온톨로지와 지식 그래프는 서로 겹치는 부분이 많지만, 둘을 구분해 두면 이해에 도움이 됩니다.

온톨로지: 어떤 종류의 사물이 존재하는지, 관계가 무엇을 의미하는지, 어떤 규칙이 적용되는지를 정의합니다. 장비, 구성 요소, 팀, 역할, 프로세스 등이 이에 해당합니다. 예를 들어 온톨로지는 ‘장비’ 유형과 ‘구성 요소’를 ‘포함하는’ 관계를 정의할 수 있습니다. 그러면 지식 그래프는 “펌프 P-101은 씰 S-7을 포함한다”라고 명시할 수 있습니다. 여기에는 두 개의 구체적인 엔터티와 그 관계가 담깁니다.

에이전트에게 이렇게 요청한다고 가정해 보세요. “기존 매장 매출 성장률을 계산하되, 전체 매장을 포함한 결과와 개점한 지 2년이 안 된 매장을 제외한 결과를 나란히 보여줘. 그런 다음 두 결과를 각각 국내, 해외, 전체 합산으로 나눠줘.”

이 요청에는 에이전트가 추측할 수 없는 다음과 같은 세부 정보가 필요합니다.

• 어떤 매장이 있는지, 각 매장이 언제 문을 열었는지
• 매장들이 어디에 있는지
• ‘기존 매장 매출’에 대한 내부 정의

정책상 매장이 개점 후 1년이 될 때까지 제외될 수 있으며, 요청된 2년 기준 그룹에는 여기에 필터가 하나 더 추가됩니다. 그렇더라도 매장이 기준을 충족하는 즉시 달력 기준 월별로 비교해야 할까요, 아니면 직전 회계연도를 온전히 마친 뒤에만 포함해야 할까요?

온톨로지는 해당 매장과 계산을 규정하는 정책을 연결해야 합니다. 관련 사실을 찾는 것도 도움이 되지만, 올바른 규칙을 적용해야 유용한 답을 얻을 수 있습니다.

에이전트는 질문에 답하기 전에 그래프의 관계를 활용해 관련 맥락을 검색할 수 있다. 지식 영역은 쉽게 매우 복잡해질 수 있으므로 에이전트가 유용한 것도 당연하다.

그림 1: 공개 SysML 모델을 결합한 그래프: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), 그리고 가상의 MDC 위성군 콘텐츠와 공개 사양(IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Kamiwaza Kaizen에서 렌더링.

하지만 정보를 추출하는 과정에서 오류가 생길 수도 있다. 팀마다 같은 개체를 서로 다른 이름으로 부르면 중복 항목이 만들어질 수 있다. 출처끼리 내용이 다르거나 오래된 정보가 담겨 있을 수도 있다. 출처가 정확하더라도 LLM이 잘못 해석할 수 있다. 이런 오류를 권위 있는 정보처럼 보이게 만든다고 해서 위험이 줄어드는 것은 아니다.

비즈니스 모델이 실제로 비즈니스에 영향을 미치는 시스템이 되면 이러한 위험은 더 커집니다. 관계 하나가 잘못 설정되면 잘못된 답변에 그치지 않고 잘못된 행동으로 이어질 수 있습니다.

온톨로지 제품의 위험

첫째, 유연성이 부족한 모델을 경계하세요. 공급업체는 ‘모든 기능이 기본 제공된다’는 명목으로 자사 엔터티는 일급 시민으로 취급하면서 고객 엔터티의 기능은 제한할 수 있습니다. 사용자 지정 유형에서 검색, 검증 또는 작업 실행 기능을 사용할 수 없다면, 사용자 지정이 가능하다는 것만으로는 충분하지 않습니다.

둘째, 탐색에서 거버넌스로 이어지는 경로가 있는지 살펴보세요. 도구를 사용하면 LLM이 파악한 내용을 바탕으로 그래프를 처음 구성한 뒤, 명시적인 제약 조건에 따라 검증할 수 있어야 합니다. 예외 사항을 담당자에게 전달하고, 탐색 과정에서 얻은 지식을 승인된 비즈니스 데이터로 취급하지 않으면서도 보존할 수 있어야 합니다.

가장 큰 위험은 떠날 수 없는 플랫폼에 비즈니스 프로세스를 묶어 두는 것입니다. 온톨로지는 지식, 프로세스, 관계를 포함한 비즈니스를 나타냅니다. 이를 정리하고 비즈니스 로직을 구축하는 데 들인 노력은 도구를 바꾸더라도 계속 쓸모가 있어야 합니다. 공급업체가 왜 그 자산을 잠가 두도록 허용해야 할까요?

그래프 임베딩이 유용한 경우

지식 그래프가 매우 커지면 그래프 임베딩을 지원하는 도구나 공급업체를 선택하는 편이 나을 수 있다. 그래프 임베딩은 여러 RAG 애플리케이션의 기반이 되는 의미 임베딩과 밀접한 관련이 있다. 고려할 만한 이점은 두 가지다.

첫째, 연결이 촘촘한 그래프에서 몇 단계만 따라가도 처리해야 할 엔터티가 지나치게 많아질 수 있습니다. 임베딩은 엔터티와 관계의 수치 표현을 학습해 그래프에서 관련 부분을 찾는 또 다른 방법을 제공합니다. 적절한 작업에서는 그래프를 직접 탐색하는 것보다 효율적일 수 있습니다.

둘째, 임베딩 모델은 누락되었을 가능성이 있는 관계 후보의 순위를 매길 수 있습니다. 같은 학습을 통해 특정 엔터티 유형에서 흔히 나타나는 속성과 관계의 패턴을 찾아낼 수 있어, 그래프를 더 완전하게 구축하는 데 도움이 됩니다.

점진적으로 개선해야 하는 이유

스스로 미래를 설계하고, 특정 업체에 종속되는 일을 피하며, 공급업체가 정한 틀에 맞춘 왜곡된 모습이 아니라 실제 비즈니스를 모델링하려면 대규모 현장 배치 엔지니어팀 없이 어떻게 시작해야 할까요? 도구가 탐색에서 검증으로 이어지는 경로를 지원한다면, 바로 이 지점에서 최신 AI가 강점을 발휘한다고 생각합니다.

먼저 자동화된 탐색과 추출을 활용하세요. 비즈니스 문서, 정책, 이메일 또는 Slack 메시지에서 특정 분야의 초기 모습을 구성할 수 있습니다. 중요한 점은 검증을 거치기 전까지 그 내용이 정확하다고 믿어서는 안 된다는 것입니다.

두 번째 단계는 검증입니다. 도구를 통해 추출된 후보 정보에서 출처에 근거한 주장으로, 그리고 책임 있는 담당자나 권위 있는 시스템이 검증한 지식으로 원활하게 나아갈 수 있어야 합니다. 각 주장의 출처를 보존하세요.

정보의 최신성을 유지하는 일은 계속 이어지는 작업이다. 문제 티켓을 처리하는 절차나 “뉴저지에는 매장이 몇 개 있나요?”라는 질문에 대한 답은 오늘과 3년 전이 다를 수 있다. 하지만 오늘의 지식을 업데이트한다고 해서 어제의 현실을 지워서는 안 된다. 사실이 기록된 시점과 그 사실이 적용된 시점은 서로 다를 수 있다. 유용한 온톨로지는 현재의 답변과 정확한 과거 기록을 모두 지원해야 한다. 누군가는 여전히 그 지식을 최신 상태로 유지해야 한다.

다뤄야 할 범위는 방대할 수 있습니다. 더 작은 자료 집합에서 시작해 유용한 분야를 정리하고, 그 과정에서 가치를 만들어 가며 포괄적인 그림을 완성해 나가세요.

고객 지원은 유용한 적용 분야 중 하나입니다. 여기에는 인바운드 전화, 이메일, 티켓 관리 시스템, 자동화된 문제 해결, 고객에게 응대할 수 있는 지원팀, 실제 버그를 엔지니어링 팀에 에스컬레이션하는 절차가 포함됩니다. 고객 지원은 지식과 실행을 연결하고, 관리하기 쉬운 범위 안에서 동일한 위험과 보상을 드러냅니다.

ServiceNow의 Common Service Data Model은 이러한 제약을 잘 보여 줍니다. CSDM 5 백서에는 “이 데이터를 지정된 테이블에 저장하지 않으면 ServiceNow AI Platform의 가치를 온전히 누리지 못할 수 있습니다.”라고 경고합니다. 이 경고 자체가 설계와 운영상의 제약을 만듭니다. 공급업체의 모델을 따르거나 위험을 감수해야 하는 것입니다. 그러다 보면 둥근 구멍에 네모난 말뚝을 억지로 끼워 넣는 상황이 되지 않을까요?

온톨로지 플랫폼이 데이터 수집, 변환, 작업, 비즈니스 규칙까지 제공한다고 가정해 봅시다. 엔터티, 속성, 관계는 내보낼 수 있을지도 모릅니다. 하지만 데이터베이스를 변경하고, 웹훅을 호출하고, 그 밖의 부수 효과를 일으키는 변환과 작업 파이프라인도 다른 곳으로 옮길 수 있을까요? 긴밀하게 결합된 통합 기능 때문에 비즈니스 자체가 특정 플랫폼에 종속될 수 있습니다.

지금 유연성이 중요한 이유

소프트웨어가 세상을 잠식하고, AI가 소프트웨어를 잠식하고 있습니다. 팀이 소프트웨어를 만들고 작동시키는 데 모두 AI를 활용하면서 더 많은 비즈니스 로직이 이러한 플랫폼에 종속될 수 있습니다. 유용한 자동화 하나하나가 마이그레이션을 가로막는 또 하나의 의존성이 될 수도 있습니다. 공급업체가 여러분의 민첩성을 가로막게 두는 것은 위험합니다.

결론

살아가기에 놀라운 시대입니다! 사람들이 에이전트에 맥락을 제공하기 위해 온톨로지를 살펴보는 것도 당연합니다. 그 맥락을 프로세스와 통합 기능으로 확장하면 실질적인 가치를 창출할 수 있습니다. 서두에서 던진 질문을 다시 떠올려 보세요. 구성원들의 수정 의견은 모델이 비즈니스를 더 정확히 반영하도록 해야 합니다. 그렇게 축적된 이해는 플랫폼을 바꿀 때 버려지기에는 너무나 소중합니다. 또한 한쪽으로 몰려 선택의 여지가 없어지기에도 최악의 시기입니다.