엔터프라이즈 AI를 위한 지식 계층

이 글은 Neo4j 공식 블로그의 “The knowledge layer for enterprise AI”(2026년 7월 20일) 게시물을 한국어로 번역한 것입니다.

풍부한 맥락을 갖춘 엔터프라이즈 AI를 위한 선언문

엔터프라이즈 AI가 실패하는 이유는 모델 때문이 아닙니다. 최첨단 LLM은 몇 달에 한 번씩 더 저렴하고 더 우수한 모습으로 등장하며, 이제 누구나 이용할 수 있습니다.

엔터프라이즈 AI가 실패하는 이유는 스캐폴딩 때문도 아닙니다. 도구, 오케스트레이션, 평가, 가드레일을 아우르는 하네스는 이미 성숙했습니다. 이제 팀들은 에이전트를 구축하는 방법을 알고 있습니다.

그런데도 같은 모델과 같은 하네스를 사용한 회사들이 전혀 다른 결과를 얻습니다. 차이는 다른 곳에 있습니다. 실패하는 AI는 자신이 작동하는 비즈니스 환경을 이해하지 못하는 AI입니다. 우리는 수년 동안 여러 조직의 에이전트 도입을 지원하면서, 이 문제를 해결하는 유일한 방법은 기업 지식이 존재하는, 공유되고 거버넌스가 적용되는 기반을 마련하는 것임을 깨달았습니다. 우리는 이 기반을 엔터프라이즈 AI를 위한 지식 계층이라고 부릅니다.

AI가 비즈니스를 이해하지 못하는 이유는 무엇일까요? 의미와 조직 내 축적된 지식이 명시적으로 기록된 적이 없기 때문입니다. 엔터프라이즈 데이터는 애플리케이션과 사람을 위해 구축되었고, 애플리케이션과 사람이 그 의미를 스스로 보완해 왔습니다. 애플리케이션은 status = 2가 ‘검토 대기 중 일시 중지’를 뜻한다는 것을 압니다. 분석가도 알고 있습니다. 그 의미는 애플리케이션 코드와 분석가의 머릿속에는 있지만, 에이전트가 읽을 수 있는 곳에는 존재하지 않습니다.

에이전트가 최고의 LLM 지능을 이용할 수 있더라도, 엔터프라이즈 데이터의 의미는 빠져 있습니다. 여기에는 조직의 관계, 역사, 의사결정 등 다른 조직과 구별되는 고유한 요소가 포함됩니다. 이것이 바로 암묵적 시맨틱이며, 모든 엔터프라이즈 AI 실패가 시작되는 지점입니다.

이에 대한 자연스러운 대응이자 현재 대부분의 팀이 택하는 방식은 각 에이전트에 필요한 지식을 에이전트 자체에 직접 내장하는 것입니다. 프롬프트에 정의를 넣고, 상태 값의 의미를 담은 맞춤형 도구를 MCP 서버에 만들고, 적절한 맥락을 가져오는 검색 파이프라인을 구축합니다. 실제로 잘 작동하며 데모도 훌륭합니다. 하지만 그 과정에서 무슨 일이 일어났는지 살펴봐야 합니다. 이제 의미의 일부가 각 에이전트 내부에 존재하게 되었습니다.

이 방식을 에이전트 10개에 적용하면 기업은 자신에 대한 독립된 복제본 10개를 만드는 셈입니다. 이것이 시맨틱 중복이며, 중복된 내용은 필연적으로 서로 달라집니다. ‘활성 고객’을 이번 분기에는 한 팀의 MCP 서버에서 다시 정의하고, 다음 분기에는 다른 팀의 에이전트 프롬프트에서 다르게 정의할 수 있습니다. 세 번째 팀에서는 아예 갱신하지 않을 수도 있습니다. 무언가가 요란하게 고장 나거나 경보가 울리지는 않습니다. 기업이 스스로에 대한 일관된 이해를 잃게 될 뿐입니다.

그래서 에이전트는 만들기는 저렴하지만, 일관된 가치를 제공하는 수준으로 끌어올리려면 많은 비용이 듭니다. 또한 에이전트마다 더 많은 로직과 맥락을 추가해 문제를 해결하려는 본능적인 접근은 방향이 완전히 잘못되었습니다. 무언가를 하나 추가할 때마다 동기화 상태를 유지해야 할 복제본도 하나 더 늘어나기 때문입니다.

해결책은 그 반대입니다. 더 스마트한 공유 기반 위에 더 가벼운 에이전트를 구축해야 합니다. 의미를 에이전트에서 꺼내 모든 에이전트가 참조하는 하나의 거버넌스 적용 공간에 배치합니다. 한 번 정의하고, 여러 팀이 합의하며, 버전을 관리하고, 어디에서든 가져다 쓰도록 하는 것입니다. 그러면 에이전트는 자신이 잘하는 일, 즉 의도를 해석하고 계획하며 행동하는 데 집중할 수 있습니다. 에이전트가 더 가벼워지고 기반이 더 스마트해질 때 엔터프라이즈 AI는 확장됩니다.

지식 계층이란?

지식 계층(KL)은 기업 지식이 존재하는, 공유되고 거버넌스가 적용되는 기반입니다. 에이전트, 도구, 애플리케이션이 이용할 수 있으며, 모든 소비자가 필요로 하는 요소에 각각 대응하는 세 가지 주요 구성 요소로 작동합니다. KL 온톨로지는 원시 데이터 자산부터 그 데이터가 나타내는 비즈니스 개념과 이를 기반으로 구축된 프로세스까지, 기업 전체를 보여주는 실시간 지도를 제공합니다. 엔터프라이즈 데이터는 근거를 제공하고, 메모리는 학습과 추적 가능성을 제공합니다. 이 세 요소는 KL에서 서로 연결되고 실행 가능한 형태가 되어, 조직 지식을 데이터처럼 쿼리하고 코드처럼 실행할 수 있게 합니다.

KL은 하나의 거버넌스 적용 비즈니스 모델, 즉 KL 온톨로지를 바탕으로 에이전트가 요청의 의미를 해석하고, 신뢰할 수 있는 데이터를 찾고, 필요한 순간에 적절한 지식을 적용하며, 정책 범위 안에서 행동하도록 지원하는 서비스라고 볼 수 있습니다. 각 에이전트가 이러한 이해를 처음부터 다시 구축할 필요가 없습니다.

여기서 더 나아가기 전에 비슷하게 들리는 용어가 많은 이 분야에서 한 가지를 분명히 하겠습니다. 지식 계층은 비즈니스 인텔리전스(BI) 시맨틱 계층도 아니고, 검색 기능에 덧붙인 범용 맥락 계층도 아닙니다. 이들이 KL과 어떤 관계가 있고 왜 둘 다 가치가 있는지는 뒤에서 다시 설명하겠지만, 어느 쪽도 엔터프라이즈 규모의 에이전트에 필요한 기능을 충분히 제공하지 못합니다.

KL 온톨로지는 기업이 스스로를 바라보는 모델을 담습니다. 즉, 비즈니스가 실제로 운영되는 방식을 공식적으로 정의하고 연결한 실시간 지도입니다. 여기에는 비즈니스 사용자가 쓰는 용어와 그 배후의 도메인 모델, 업무를 수행하는 사람들(역할, 책임, 인계), 업무가 거치는 프로세스(은행의 신용 검토나 자금세탁방지(AML) 심사, 통신사의 서비스 프로비저닝, 거의 모든 업종에서 볼 수 있는 월말 결산이나 지원 에스컬레이션), 그리고 이를 지원하는 시스템과 데이터 자산이 포함됩니다. 또한 이 모든 것을 설명하고 제약하는 로직(환불액은 최초 결제액을 초과할 수 없음, 구독은 특정 계정에 속함, 데이터 제품은 접근 가능한 데이터 자산으로 뒷받침되어야 함)과 비즈니스 요소를 기술 자산에 연결하는 매핑도 포함합니다.

엔터프라이즈 데이터는 온톨로지에 기술된 도메인 모델을 실제 사례로 구현하는 근거입니다. KL은 전통적인 세 가지 데이터 범주인 참조 데이터, 마스터 데이터, 트랜잭션 데이터를 서로 다른 방식으로 다룹니다.

참조 데이터는 온톨로지의 확장으로 관리되는 경우가 많으며, 특정 개념이 가질 수 있는 값을 통제된 집합으로 나타냅니다. 비즈니스 온톨로지가 ‘국가’라는 범주를 정의한다면, 그 인스턴스는 열에 우연히 입력된 임의의 문자열이 아니라 거버넌스가 적용된 명확한 국가 목록으로 제한되어야 합니다.

마스터 데이터와 트랜잭션 데이터는 외부에 그대로 둘 수도 있고, 원래 위치에서 쿼리할 수도 있으며, 구체화 또는 가상화된 도메인 그래프 형태로 KL에 가져올 수도 있습니다. 이 두 방식 가운데 어느 것을 적용할지, 언제 한 방식을 다른 방식보다 선택할지는 별도로 깊이 다룰 가치가 있는 설계 문제입니다.

마지막으로 메모리는 사용할수록 가치가 누적되는 요소입니다. 에이전트가 KL과 상호작용할 때마다 의사결정 추적 기록이 남습니다. 계좌 개설 에이전트의 ‘컴플라이언스 확인’ 작업을 예로 들어보겠습니다. 이 작업에서는 정부 발급 신분증을 확인해야 합니다. 온톨로지는 자동차 등록 기록과 여권 확인이라는 두 시스템이 이 요건을 충족할 수 있음을 알고 있습니다.

하지만 어느 시스템을 사용해야 하는지는 메모리가 알고 있습니다. 과거의 모든 실행에서 이 고객 세그먼트는 자동차 등록 기록을 사용했을 때 더 빠르고 깔끔하게 처리되었지만, 해외 출생 신청자의 경우에는 여권 확인이 효과적이었다는 사실을 기억하기 때문입니다. 온톨로지는 가능한 선택지를 보유하고, 메모리는 검증된 선택지를 보유합니다. 과거에는 이러한 ‘이유’가 분석가의 머릿속이나 종료된 티켓에만 남아 매번 처음부터 다시 도출해야 했습니다.

메모리를 활용하면 업무 수행 과정의 부산물로 그 이유를 포착할 수 있습니다. 다음번 계좌 개설 에이전트 실행은 이전의 천 번에 걸친 실행이 학습한 모든 것을 바탕으로 시작할 수 있습니다.

지식 계층은 어떻게 작동하는가?

KL은 데이터 카탈로그처럼 정의에만 머무르지 않고 실행할 수 있습니다. 아키텍처 관점에서 KL은 데이터 자산과 해당 자산에 접근하는 에이전트 및 애플리케이션 사이에 위치하는 소프트웨어입니다. 에이전트가 KL을 한 번 읽고 그 내용을 계속 가지고 다닐 수는 없습니다. 우선 그 규모가 어떤 컨텍스트 윈도보다도 훨씬 크며, 더 중요한 점은 엔터프라이즈 지식이 동적이라는 것입니다. 정의는 바뀌고, 소스는 이동하며, 메모리는 계속 쌓입니다. 따라서 정적인 버전이나 캐시된 복사본은 불완전할 뿐만 아니라 최신 상태도 아닐 수밖에 없습니다. 에이전트는 작업하는 동안 KL에 지속적으로 쿼리하여 각 요청에 필요한 의미, 데이터, 정책만 정확히 가져옵니다.

구체적으로 살펴보겠습니다. 에이전트가 “이 고객에 대한 우리의 익스포저는 어느 정도인가?”라는 요청을 받았다고 가정해 보겠습니다. 에이전트가 혼자 처리한다면 각 단어가 무엇을 뜻하는지, 어떤 시스템을 조회해야 하는지, 어떤 정보를 볼 권한이 있는지, 반환된 수치를 신뢰할 수 있는지 모두 추측해야 합니다. KL은 이 작업을 에이전트 대신 처리합니다. 요청이 들어오면 KL은 다음과 같이 작동합니다.

• 의도를 해석합니다: 비즈니스 모델을 기준으로 ‘익스포저’와 ‘이 고객’이 실제로 무엇을 가리키는지 파악합니다.
• 맥락을 구성하고 소스를 선택합니다: 요청에 필요한 맥락을 구성하고, 신뢰할 수 있는 답을 제공할 수 있는 기준 소스를 선택합니다.
• 데이터가 KL 외부에 있으면 쿼리를 생성하고 도구를 라우팅하여 비즈니스 개념을 실제 시스템에 대한 구체적인 호출로 변환합니다. 데이터가 KL에서 접근 가능하면 해당 데이터를 쿼리하고 호출한 에이전트에 결과를 반환합니다.
• 요청 처리의 부가 단계가 아니라 요청을 해석하는 과정 자체에서 정책과 접근 제어를 적용하여, 에이전트가 허용된 정보만 보도록 합니다.
• 결과에 도달한 과정을 설명하고 추적 기록으로 남기며, 다음 요청이 더 축적된 지점에서 시작할 수 있도록 메모리를 업데이트합니다.

실행 자체는 여전히 에이전트가 담당합니다. KL은 근거를 제공하며, 의도를 거버넌스가 적용되고 소스가 명확하며 신뢰할 수 있는 실행 계획으로 전환합니다.

지식 계층은 구매하는 것이 아니라 엔지니어링하는 것, 주로 아래에서 위로

지식 계층에는 각 기업의 고유한 비즈니스가 인코딩되므로, 이를 실행하는 인프라와 달리 완제품으로 구매할 수 있는 형태가 존재하지 않습니다. 공급업체가 그래프 플랫폼, 카탈로그, 정책 엔진 등 모든 재료를 판매할 수는 있지만, 그 안에는 여전히 고객의 비즈니스가 전혀 담겨 있지 않습니다. 지식 계층의 내용은 바로 고객 기업의 의미입니다. 매출에 대한 정의, 데이터 자산 환경, 거버넌스 모델, 에이전트에 허용되는 행동 방식이 모두 포함됩니다. 인코딩하려는 대상은 본질적으로 서로 연결되어 있으므로 그래프가 자연스러운 기반이 됩니다. 개념은 다른 개념과 연결되고, 시스템에 매핑되며, 정책으로 둘러싸이고, 데이터 계보와 메모리로 이어집니다. 그래서 Neo4j와 같은 플랫폼은 지식 계층을 구축하고 그 위에서 추론할 수 있는 토대와 프레임워크를 제공하지만, 지식을 획득하는 노력은 여전히 고객의 몫입니다. 이를 현실적으로 가능하게 하는 것은 방법론입니다. 수많은 고객 프로젝트를 통해 다듬어진 반복 가능한 모범 사례와 전체 과정을 가속하는 LLM을 결합하면, 마침내 엔터프라이즈 규모에서도 지식 획득이 가능해집니다.

과거에는 이 지식 획득이 가장 어려운 부분이었습니다. 기존 방식에서는 위원회가 정의를 작성하고, 분석가가 직접 매핑을 그리며, 에이전트가 데이터를 사용하기도 전에 비즈니스를 문서화하는 데 수년이 걸렸습니다. 개념은 프로세스에서 찾아내 시스템에 매핑하고, 서로 모순되는 부분을 조정해야 합니다. 사람이 직접 하면 끝나지 않는 작업이지만, 바로 이런 일이 LLM이 잘하는 분야입니다. LLM은 실제 근거에서 출발해 아래에서 위로 작업합니다. 실제 스키마를 읽고, 각 테이블이 의미하는 바를 제안하며, 매핑을 추천하고, 두 팀이 같은 단어를 서로 다르게 정의하는 지점을 표시합니다.

하지만 LLM은 제안하고, 사람은 승인합니다. LLM은 어떤 매출 열을 기준으로 삼아야 할지 제안할 수 있지만, 그 결정의 책임자는 사람입니다. 영업팀과 지원팀이 ‘활성 고객’을 서로 다르게 정의한다는 사실을 드러낼 수는 있지만, 어느 정의를 표준으로 삼을지는 비즈니스 차원의 결정입니다. 따라서 이 접근 방식은 사실상 하이브리드입니다. LLM으로 지식 획득을 가속하는 아래에서 위로의 탐색과, 조직이 무엇을 기준으로 삼을지 정의하는 위에서 아래로의 거버넌스가 결합됩니다. 재사용은 이 하이브리드 모델을 더욱 강화합니다. 산업별 모델, 공식 표준, 수백 건의 구축 사례에서 학습한 패턴을 활용하면 백지에서 시작하지 않고 탄탄한 출발점을 확보할 수 있습니다. 모든 조직은 고유하지만, 특정 도메인의 개념적 뼈대 중 많은 부분은 공통적입니다. 이러한 핵심 요소를 재사용하면 KL을 채우는 속도를 크게 높이면서도, 각 조직이 자사 비즈니스에 중요한 차이를 정의할 여지를 남길 수 있습니다.

지식 계층은 사용할 때마다 스스로 개선됩니다. 해결된 모든 쿼리, 모호함이 드러난 모든 정의, 예상 밖의 결과를 반환한 모든 매핑은 지식 계층이 부족하거나 잘못된 지점을 알려주는 신호입니다. 모든 의사결정을 추적하고 다시 반영하므로, 배포한 날부터 낡아가는 대신 이미 수행 중인 업무의 부산물로 계속 개선됩니다. KL은 지식을 데이터처럼 쿼리하고 코드처럼 실행할 수 있게 하며, 그 결과 지식에 소프트웨어 개발 방식을 적용할 수 있습니다. 과거처럼 모든 것을 한꺼번에 해결하려는 느린 거버넌스가 아닙니다. 아래에서 위로 진행하고, 고도로 자동화하며, 지속적으로 거버넌스를 적용하되, 전문가가 항상 과정에 참여합니다.

온톨로지 기반 시맨틱 계층

고객은 KL을 구현할 때 흔히 온톨로지 기반 시맨틱 계층(Ontology-Based Semantic Layer, OBSL)부터 시작합니다. OBSL은 지식 계층의 핵심으로, 온톨로지와 참조 데이터, 그리고 이를 활용하는 도구로 구성됩니다. 데이터는 외부에 유지하고 원래 위치에서 쿼리합니다. 요청이 들어오면 OBSL은 비즈니스 모델을 기준으로 의도를 해석하고, 어떤 데이터 자산에 관련 정보가 있으며 어떤 플랫폼(Snowflake, Oracle, Salesforce, S3)이 이를 호스팅하는지 판단하고, 정책을 적용한 뒤, 에이전트가 그 위치에서 직접 쿼리하도록 안내합니다. 어떤 데이터도 이동하거나 복사하지 않습니다. 지식은 계층에 있고 데이터는 원래 위치에 그대로 남습니다. OBSL은 지도이자 나침반입니다. 어떤 맥락이 중요한지, 어디에서 가져와야 하는지, 어떻게 사용할 수 있는지를 판단하고 나머지 작업은 에이전트가 수행합니다.

지식 계층 온톨로지에는 무엇이 포함되는가?

온톨로지는 여러 계층에 걸쳐 기업을 연결된 형태로 표현합니다.

• 기술 온톨로지는 시스템, 데이터 소스, 데이터 자산에 관한 모든 세부 정보를 담습니다. 메타데이터 카탈로그, 데이터 소스 직접 검사, 쿼리 로그 분석을 통해 구축합니다.
• 도메인(또는 비즈니스) 온톨로지는 비즈니스의 핵심 엔터티와 그 관계를 담습니다. 고객은 금융 서비스의 FIBO나 생명과학의 SNOMED 같은 산업 표준에 맞추는 경우가 많지만, 대부분은 자체 온톨로지를 사용하며 때로는 일부만 해당 표준과 정렬합니다. 고객이 TopQuadrant나 Protégé 같은 전문 도구에서 OWL, RDFS, SKOS 등의 W3C 표준을 기반으로 도메인 온톨로지를 이미 관리하고 있다면 직접 가져와 KL을 채웁니다. 이러한 체계가 없다면 LLM 지원 도구를 사용해 기업이 보유한 자료에서 초기 온톨로지를 구축할 수 있습니다. 여기에는 비즈니스가 답해야 하는 역량 질문, 기술 온톨로지 내 시스템의 샘플 데이터 및 스키마 정보, 기존 용어집과 모델이 포함되며, 온톨로지 엔지니어링 모범 사례를 토대로 작업합니다.

기술 온톨로지와 비즈니스 온톨로지는 데이터 제품 정의를 통해 연결됩니다. 데이터 제품 정의가 이미 MS Purview, Databricks Unity Catalog 또는 DPROD 설명 등으로 관리되고 있다면 매핑을 직접 가져옵니다. 그렇지 않다면 LLM이 지원하고 사람이 선별하는 동일한 방식을 적용합니다. 연결 관계를 제안하고 사람이 이를 승인합니다.

• 비즈니스 프로세스 온톨로지는 기업의 핵심 프로세스, 즉 작업, 활동, 의사결정 지점과 그 사이의 흐름을 상세하게 설명합니다. 조직이 Celonis, Camunda, SAP Signavio 또는 자체 개발한 프로세스 플랫폼을 사용한다면 해당 플랫폼에서 정보를 가져와 이 계층을 구축합니다. 그렇지 않은 경우에는 프로세스 공식화 기법과 지식 획득 방법론을 적용해 흐름을 재구성합니다.
• 마지막으로 정책 온톨로지와 조직 온톨로지가 전체 그림을 완성합니다. 정책 온톨로지는 접근과 사용을 통제하는 규칙, 즉 누가 어떤 조건에서 무엇을 볼 수 있고 에이전트가 그 정보로 어떤 작업을 수행할 수 있는지를 담습니다. 이를 통해 거버넌스를 나중에 덧붙이는 대신 모델 자체에 표현합니다. 조직 온톨로지는 조직 단위, 역할, 소유권, 책임 등 기업의 구조를 담아 모든 개념, 자산, 정책에 조직 내 위치와 책임 주체를 부여합니다.

이 접근 방식은 모듈식이므로 조직은 첫 번째 계층만으로도 가치를 얻고, 나머지 계층이 준비되는 대로 추가할 수 있습니다. 어떤 계층부터 도입할지는 조직의 데이터 성숙도에 따라 결정되는 경우가 많습니다. 온톨로지를 구성하는 계층 구조와 각 요소의 연결 방식으로 이루어진 프레임워크 자체는 여러 산업과 수많은 고객을 대상으로 수년간 수행한 경험에서 정제되었습니다. 이것이 구축 속도를 높이는 핵심입니다. 지식의 구조를 처음부터 설계하는 것이 아니라 검증된 구조에 내용을 채우기 때문입니다.

완전한 KL은 OBSL을 두 방향으로 확장합니다. 첫째, 데이터를 계층 내부로 가져와 단순히 데이터 위치를 안내하는 데 그치지 않고 직접 답변을 제공할 수 있습니다. 대출, 담보, 거래 상대방 데이터 전반의 익스포저와 그 결과에 대한 그래프 분석을 반복적으로 필요로 하는 신용 위험 에이전트가 호출할 때마다 세 시스템을 다시 페더레이션해서는 안 됩니다. 해당 데이터 일부를 계층 안에서 도메인 데이터 제품으로 구체화하면, 여러 소스를 조회하는 느린 쿼리를 빠른 로컬 쿼리로 전환할 수 있습니다.

둘째, 메모리를 추가할 수 있습니다. 추론 추적 기록, 이력, 축적된 맥락을 활용하면 각 요청이 이전 요청보다 더 진전된 지점에서 시작됩니다. 에이전트가 자금세탁방지(AML) 에스컬레이션을 처음 처리할 때는 단계별로 경로를 추론합니다. 그 추적 기록을 포착하고 KL이 반복되는 패턴을 재사용 가능한 프로세스로 정제하면, 다음 에스컬레이션은 처음부터 원리를 다시 따지는 대신 이미 확립된 플레이북에서 시작합니다. 의미, 근거, 경험이 시간이 지남에 따라 축적되는 것입니다.

KL 온톨로지는 거버넌스가 적용되고 동기화 상태가 유지되며 버전이 관리됩니다. 구체적인 작동 방식과 주요 접근 패턴 등은 향후 게시물에서 다룰 예정입니다.

지식 계층이 아닌 것

지식 계층과 매우 유사해 혼동하기 쉬운 두 가지가 있습니다. 첫 번째는 Looker, dbt, Power BI 같은 도구의 메트릭 계층인 BI 시맨틱 계층입니다. 이 계층은 메트릭 계산 방식을 명확하게 고정하여 재무 대시보드와 이사회 자료에서 ‘매출’이 같은 수치로 표시되도록 합니다. 유용하지만 메트릭은 하나의 원자, 즉 홀로 존재하는 단일 값입니다.

에이전트가 메트릭만으로 답할 수 없는 질문을 받는 상황을 생각해 보겠습니다. “위험 상태인 엔터프라이즈 고객 중 다음 분기에 갱신 예정인 고객은 누구이며, 각 고객의 담당자는 누구인가?” BI 시맨틱 계층은 ‘위험 상태’와 ‘갱신 금액’을 명확하고 합의된 메트릭으로 정의할 수 있습니다. 하지만 고객이 구독과 연결되고, 구독에 갱신일과 계정 담당자가 있으며, ‘엔터프라이즈’라는 세그먼트를 영업과 재무가 서로 다르게 정의하고, 이탈했다가 다시 활성화된 계정을 ‘위험 상태’로 볼지 여부가 거버넌스 적용 비즈니스 규칙이라는 사실은 알지 못합니다. 메트릭은 설명 대상인 엔터티에서 분리된 채 떠다니는 숫자일 뿐입니다. 온톨로지는 이러한 원자가 존재하는 모델입니다. 고객이 무엇인지, 구독과 어떻게 연결되는지, 어떤 프로세스가 고객을 만들어 내는지, 어떤 규칙이 환불을 제한하는지, 각 정의의 책임자가 누구인지를 설명합니다. 메트릭 계층은 숫자를 제공하고, 온톨로지는 그 숫자가 주변 비즈니스 맥락에서 무엇을 의미하는지 알려줍니다. 이 질문에 제대로 답하려면 둘 다 필요합니다. BI는 에이전트가 아니라 보고서를 위해 만들어졌습니다.

두 번째는 맥락 계층입니다. 이는 시맨틱 계층을 비정형 데이터까지 확장하여 에이전트가 메트릭과 함께 문서를 가져올 수 있도록 합니다. 지식 계층에 더 가깝고 한 단계 개선된 방식이지만 여전히 목표가 잘못되어 있습니다. 모델이 보는 정보를 더 풍부하게 할 뿐, 기업에서 사용하는 의미를 거버넌스하지는 않습니다.

두 계층 모두 동일한 요소가 부족합니다. 기준이 되는 신뢰할 수 있는 소스, 데이터 계보, 실행 시점에 적용되는 정책, 실제 시스템과의 매핑입니다. 어느 계층에서도 이러한 요소를 찾을 수 없습니다. 맥락 계층은 모델에 더 나은 자료를 제공하고, BI 시맨틱 계층은 보고를 위해 메트릭을 통일합니다. 지식 계층은 그 자료가 무엇을 의미하며 어떻게 사용할 수 있는지를 결정하고 보증합니다.

지식 계층을 공유 인프라로 운영하기

지식 계층은 어느 한 팀의 프로젝트가 되는 순간 실패합니다. 데이터팀만 구축하면 그들의 관점만 인코딩되어 다른 팀이 신뢰하지 않게 됩니다. 중앙 모델링 조직이 소유하면, 그 조직이 직접 경험하지 못하는 도메인의 변화 속도를 따라갈 수 없습니다. 지식 계층은 공유 인프라로 운영할 때만 작동합니다. 데이터 메시가 데이터에 관해 얻은 교훈을 이제 의미 자체에 적용해야 합니다. 소유권은 중앙의 병목 지점이 아니라 해당 의미를 가장 가까이에서 다루는 사람들에게 있어야 합니다.

따라서 역할 분담은 데이터 메시 원칙과 명확하게 연결됩니다. 도메인 팀은 자신의 영역을 처음부터 끝까지 소유합니다. 각자의 환경에서 ‘활성 고객’이 무엇을 의미하는지 판단하고, 잘못 정의했을 때의 결과를 감당할 수 있는 주체는 도메인 팀뿐이므로, 의미와 이를 구현하는 데이터 제품 및 매핑을 모두 소유합니다. 플랫폼 팀은 공유 기반을 소유하며 안정성, 쿼리 가능성, 버전 관리 상태를 유지합니다. 거버넌스는 중앙 집중식이 아니라 연합형입니다. 도메인 간 조직이 계층의 일관성을 유지하는 전사 규칙, 즉 기준 소스, 접근 권한, 위험 경계를 정하고, 각 도메인은 자체 정의를 로컬에서 통제합니다. 이러한 정책은 계산 가능한 형태로 구현되어 월간 검토 회의에서가 아니라 쿼리 시점에 계층에서 적용됩니다. 에이전트를 구축하는 AI 엔지니어는 이 모든 것을 활용하며, 각 애플리케이션에서 다시 만들지 않습니다.

지식 계층이 데이터 메시를 넘어서는 지점은 연합되는 대상입니다. 데이터 제품이 아니라 그 제품이 무엇을 의미하고 어떻게 사용할 수 있는지를 설명하는 의미, 매핑, 정책을 연합합니다. 같은 구상을 한 계층 위에서 적용하는 셈입니다. 그 결과 지식 계층은 서로 다른 언어를 써 온 비즈니스, 데이터, AI 조직 간의 계약이 됩니다. 의미가 하나의 거버넌스 적용 공간에 존재하면 각 조직은 자신의 몫을 소유하며, 그 공간 자체가 명시적이고 버전이 관리되며 공유되는 합의가 됩니다. 프로젝트마다 다시 협상할 필요가 없습니다. 한 번 구축하면 이후의 모든 에이전트가 정렬 상태를 처음부터 재구성하는 대신 그대로 이어받습니다.

지능은 범용재다

지능은 범용재입니다. 지식은 경쟁 우위의 해자입니다. 모든 기업이 동일한 최첨단 모델을 토큰 단위로 빌릴 수 있게 되면, 지속 가능한 우위로 남는 것은 원래부터 기업의 것이었고 결코 판매 대상이 아니었던 단 하나, 바로 자사 비즈니스에 대한 충실하고 거버넌스가 적용된 이해입니다.

향후 10년의 AI 경쟁에서 승리하는 조직은 에이전트가 자신이 작동하는 비즈니스를 실제로 이해하는 조직입니다. 모든 에이전트가 의지할 수 있는 하나의 공간에 기업 지식을 한 번 공식화하는, 화려하지 않지만 꼭 필요한 작업을 수행한 기업이기 때문입니다.

따라서 질문은 지식 계층을 구축할지 여부가 아닙니다. 아직 경쟁 우위가 될 수 있는 지금 시작할 것인지, 아니면 시장에 남기 위한 기본 비용이 된 이후에 시작할 것인지가 질문입니다.