주식회사 MBK Digital 집행임원 CTO인 이와오입니다.

Google Cloud Next Tokyo 2026에서 「AI에게 업무의 의미를 가르치는 온톨로지 (Ontology) 입문」이라는 주제로 발표했습니다. 본 세션에서는 대화형 데이터 분석에서 AI가 다루는 업무 판단의 전제를 모호하게 만들지 않기 위해 무엇을 정리해야 하는지, 그리고 Google Cloud 상에서 어떻게 구현할 수 있는지를 소개했습니다.

발표 자료는 이곳입니다.

본 기사에서는 자료의 포인트를 캡처와 함께 소개하면서, 슬라이드에서 다 미처 이야기하지 못한 설계 의도——특히 「왜 업무 판단의 조건을 검증된 쿼리 (Verified Query)로 고정했는가」——를 보충합니다.

왜 「업무의 의미」를 AI에게 가르칠 필요가 있는가

자연어로 데이터를 다룰 수 있게 되면서, AI가 데이터에 직접 접근하는 사례가 급격히 늘어나고 있습니다. 하지만 AI가 아무리 똑똑해지더라도, 「지금 바로」, 「중요 고객」과 같이 그 회사 고유의 용어나 판단 기준까지 자동으로 이해할 수는 없습니다.

같은 데이터라도 전제가 다르면 답이 달라진다

「P1 장애 INC-2048에서, 지금 바로 연락해야 할 고객은?」이라는 언뜻 단순해 보이는 질문이라도, 영향을 받는 고객을 넓게 볼 것인지, 법인 고객으로만 한정할 것인지, 우선 연락 순서까지 고정할 것인지에 따라 돌아오는 답은 달라집니다.

데이터는 같더라도 전제와 우선순위가 다르면 답이 달라집니다. 그렇기 때문에 데이터를 AI에게 전달하기 전에 업무상의 용어와 판단 기준을 정리해 둘 필요가 있습니다.

경량 온톨로지로서 무엇을 정리하는가

본 세션에서 다루는 온톨로지는 학술적인 정의나 전사의 지식 체계를 망라적으로 구축하는 것이 아닙니다. 업무 판단의 전제를 맞추기 위한 경량 지식 모델로 정의하며, 다음의 3가지로 나누어 정리합니다.

온톨로지 (Ontology) = 업무 판단의 전제를 맞추기 위한 경량 지식 모델

AI가 답하게 하고 싶은 하나의 업무 질문에 대해,

• 그 질문에 포함된 업무 용어(용어)는 무엇을 의미하는가
• 어떤 데이터를 어떤 순서로 따라가는가(데이터의 연결)
• 최종적인 대상 조건이나 우선순위를 어떻게 결정하는가(판단 규칙)

를 정리한, 구현을 위한 지식 모델입니다. 지표(Metric), 디멘션(Dimension), 관계(Relationship)를 정의하는 시맨틱 레이어 (Semantic Layer)에 용어와 판단 규칙까지 포함한 것이라고 이해하시면 비슷할 것 같습니다.

「그것은 용어집과 규칙집 아닌가?」라고 생각하실 수도 있습니다. 고객, 계약, 서비스, 컴포넌트, 장애를 업무상의 실체(Entity)로 정의하고, 이들의 관계와 판단 규칙을 명시적으로 모델화하고 있기 때문에, 본고에서는 이를 경량 온톨로지라고 부르고 있습니다.

앞서 든 예시에서는 「지금 바로 연락해야 할 고객」이라는 모호한 말을 「장애 대응 우선 고객」이라는 정식 업무 용어로 정의하고, 「B2B 고객이다」, 「유효한 계약을 보유하고 있다」, 「계약 갱신까지 60일 이내」, 「대상 장애가 P1이면서 OPEN 상태이다」, 「계약 서비스가 장애 영향 컴포넌트에 의존하고 있다」라는 5가지 조건으로 고정했습니다.

Google Cloud 상에서 어떻게 구현했는가

정리한 3요소는 역할에 따라 Google Cloud의 각 기능에 대응시킵니다. 다음은 이번 데모에서의 구현 예시입니다.

정리한 의미를 역할별로 Google Cloud에 구현한다

또한, 「데이터의 연결」은 일반적인 JOIN이나 뷰 (View)로도 구현할 수 있습니다. 이번에는 장애로부터 컴포넌트, 서비스, 계약을 거쳐 고객에 이르는 다단계 영향 경로를 다루기 때문에, 경로 탐색을 선언적으로 기술하고 유지보수할 수 있는 BigQuery Graph를 선택했습니다.

중요한 것은 에이전트의 프롬프트 (Prompt)만으로 모든 것을 해결하려고 하지 않는 것입니다. 용어의 정의, 데이터 간의 관계, 대상 조건을 별개의 구성 요소로 관리함으로써, 업무 규칙이 변경되었을 때도 영향 범위를 한정하여 업데이트할 수 있습니다. 또한 「왜 그런 답변이 나왔는가」를 프롬프트의 동작이 아닌 정의나 쿼리로부터 설명하기 쉬워집니다.

BigQuery의 데이터 에이전트 (Conversational Analytics)에는 지식 소스 (Knowledge Source), 지시 (Instruction/Procedure), 검증된 쿼리 (Verified Query), 용어집을 설정할 수 있으며, Knowledge Catalog로부터 비즈니스 용어집을 가져오는 것도 가능합니다 (공식 문서).

에이전트에게 무엇을 시킬 것인가

에이전트가 답변하기까지의 흐름은 다음과 같습니다.

에이전트가 답변하기까지의 흐름

• 자연어 질문을 받음
• 용어집과 절차를 참조하여 질문의 의미를 일치시킴
• 대응하는 검증된 쿼리 (Verified Query)를 선택
• 질문에서 파라미터(@incident_id, @as_of_date 등)를 추출하여 쿼리에 전달

포인트는, 판단 조건은 에이전트가 그 자리에서 생각하는 것이 아니라, 검증된 쿼리에 고정되어 있다는 점입니다.

참고로, 판단 조건을 고정한 검증된 쿼리의 핵심 부분을 보여드립니다 (데모의 실제 쿼리에서 발췌하였으며, 반환 열의 일부를 생략했습니다).

-- 파라미터: @incident_id STRING, @as_of_date DATE
WITH candidates AS (
SELECT *
...

"장애 대응 우선 고객"의 5가지 조건이 모두 이 하나의 쿼리 안에 명시되어 있음을 알 수 있습니다. 고객 속성이나 계약 상태는 SQL 조건으로 필터링하고, 서비스와 컴포넌트의 의존 관계는 그래프 경로({1,3} 홉)를 통해 추적합니다. 또한, 여러 계약이나 영향 경로가 발견된 고객에 대해서는 QUALIFY 절을 사용하여 "계약 갱신이 가까운 순 → 의존 경로가 짧은 순 → 계약 ID · 서비스 ID" 순으로 대표 근거를 하나 선택하며, 이 규칙 자체에도 evidence_selection_policy라는 이름과 버전을 부여했습니다. 참고로 ANY SHORTEST는 동일한 길이의 최단 경로가 여러 개 있을 경우 그중 하나를 반환하므로, 표시되는 영향 경로는 "최단 경로 중 하나"가 됩니다. 공식 용어와 규칙 버전을 쿼리의 반환 열에 포함하는 이유는, 후술할 "근거와 재현 방법을 답변에 남기기" 위해서입니다.

왜 SQL을 자유롭게 생성하게 하지 않는가

자연어로부터 SQL을 생성하게 하는 접근 방식은 간편하지만, 업무 판단을 동반하는 질문에서는 두 가지 문제가 있습니다.

첫 번째는 재현성입니다. 같은 질문이라도 생성되는 SQL이 흔들리면 답변도 흔들립니다. "계약 갱신까지 60일 이내"를 <= 60으로 해석할지 < 60으로 해석할지와 같은 미세한 차이라도, 장애 대응 연락처 리스트와 같은 업무에서는 허용될 수 없습니다.

두 번째는 설명 책임입니다. 생성된 SQL이 올바른지 매번 리뷰하는 것은 현실적이지 않으며, "왜 이 고객이 대상인가"라는 질문을 받았을 때 프롬프트와 생성 과정으로부터 설명하는 것은 어렵습니다.

검증된 쿼리로 고정하면, 판단 조건은 인간이 리뷰한 하나의 쿼리로 집약됩니다. 에이전트의 역할은 "어떤 쿼리를 사용할지 선택하고, 질문에서 입력값을 추출하여, 결과를 답변 문장으로 정리하는 것"으로 한정되기 때문에, AI의 변동성이 대상 조건이나 우선순위 그 자체를 변경할 여지를 줄일 수 있습니다.

물론, 쿼리의 선택 · 파라미터 추출 · 답변 문장으로의 반영은 여전히 에이전트의 자연어 이해에 의존합니다 (파라미터가 포함된 검증된 쿼리의 사양). 이러한 잔여 리스크에 대해서는 입력값의 형식 검증 (장애 ID나 날짜의 포맷 체크), 사용한 쿼리 이름과 파라미터의 답변 표시, 부적합한 질문의 거부와 같은 제어를 조합함으로써 대처할 수 있습니다.

답변 가능한 질문의 범위는 좁아지지만, 그 범위는 검증된 쿼리를 추가함으로써 계획적으로 키워나갈 수 있습니다.

답변에는 근거와 재현 방법을 포함한다

데모에서는 답변에 대상 고객 목록뿐만 아니라, 판정 근거 (계약 · 갱신일 · 서비스 · 장애 상태), 영향 경로 (어떤 서비스가 어떤 장애와 관련되었는지), 그리고 재현 방법 (규칙 버전 rule_version, 판정 기준일 as_of_date, 증거 선택 정책)까지 포함하고 있습니다. 증거 선택 정책이란, 여러 영향 경로와 계약이 발견되었을 경우 어떤 근거를 대표로 표시할지 정한 규칙을 말합니다.

답변에는 대상 고객뿐만 아니라 근거와 재현 방법도 포함한다

나중에 "이 판단은 어떤 규칙에 근거한 것인가"를 추적할 수 있다는 점이 단순한 자연어 SQL과의 큰 차이점입니다 (여기서의 "재현"은 당시의 판단 조건을 추적할 수 있다는 의미이며, 완전한 재실행을 위해서는 데이터의 스냅샷이나 실행 작업 ID의 저장도 필요합니다).

AI에게 맡기는 것과 고정하는 것

지금까지의 설계를 정리하면 다음과 같습니다.

AI에게 맡기는 것은 업무 판단이 아니라, 가교 역할

이번 설계에서 AI에게 맡기는 것은 업무 판단 그 자체가 아닙니다. 질문의 재표현(Paraphrasing)을 흡수하고, 필요한 입력값을 추출하며, 정의된 규칙과 쿼리(Query)로 가교 역할을 하는 것입니다. 업무상의 대상 조건이나 우선순위는 인간이 확인한 규칙으로서 고정합니다. 또한, 정의된 범위 밖에서는 추측하여 답하지 않도록 에이전트(Agent)에게 지시하며(이는 제품의 표준 동작이 아니라 이번 설계 방침입니다), 검증된 쿼리를 추가하면서 답변할 수 있는 범위를 키워나갑니다.

우선은 하나의 업무 질문부터 시작하기

"전사 온톨로지(Ontology)를 만들자"라고 하면 순식간에 거대 프로젝트가 됩니다. AI에게 업무의 의미를 가르치는 첫걸음은, 하나의 업무 질문을 재현할 수 있는 형태로 만드는 것입니다.

우선은 하나의 업무 질문을 재현할 수 있는 판단으로 만들기

• AI가 답하게 하고 싶은 업무 질문을 하나 결정한다
• 그 질문에서 사용할 정식 용어를 결정한다
• 필요한 데이터의 연결 관계를 정리한다
• 대상 조건과 우선순위를 쿼리에 고정한다
• 에이전트가 해당 쿼리를 호출할 수 있도록 한다
• 근거와 재현 방법을 답변에 남긴다

마치며

대화형 데이터 분석을 업무에서 성립시키는 열쇠는 AI의 성능이 아니라, 업무의 의미를 어떻게 정리해서 전달하느냐에 있습니다. 이 글이 여러분의 환경에서 '우선 한 가지 질문'을 재현 가능하게 만드는 데 도움이 되기를 바랍니다.

다시 한번, 발표 자료는 이쪽입니다.

MBK Digital에서는 데이터 활용 전략 수립부터 생성 AI / AI 에이전트 구현까지 일괄적으로 지원하고 있습니다. 대화형 데이터 분석의 업무 적용에 관심이 있으신 분은 언제든 편하게 문의해 주시기 바랍니다.

Discussion