㈜유비씨 DX사업팀 조예창 파트장 / jyc@uvc.co.kr

Ontology, 꼭 있어야 할까?

데이터를 연결하는 것을 넘어, AI Agent가 공장을 이해하는 방법

“실례지만, 어데 최씹니까?”

영화 〈범죄와의 전쟁〉에서 최민식은 처음 만난 상대에게 이렇게 묻습니다. "실례지만, 어데 최씹니까?" 우스갯소리 같지만, 그 한 마디에는 상대의 뿌리와 관계, 즉 족보를 확인하려는 본능이 담겨 있습니다.

1장. AI Agent는 이미 데이터를 잘 찾아옵니다

그림 1. AI Agent가 다수의 시스템에서 정해진 범위의 데이터를 조회하는 단계.

요즘의 AI Agent는 이미 상당히 똑똑합니다. "오늘 생산 현황을 보여줘"라고 물으면, 여러 시스템에 흩어진 생산·설비·품질·물류 데이터를 자동으로 조회해 대시보드 한 장을 뚝딱 만들어 줍니다. 저장된 정보를 정해진 규칙에 따라 빠르게 꺼내오는 일은, 이제 사람이 굳이 손을 대지 않아도 되는 영역이 되었습니다.

하지만 이 능력은 아직 "찾아오는 일"에 머물러 있습니다. AI Agent는 값을 가져올 수는 있어도, 그 값이 왜 그렇게 나왔는지, 다른 값과 어떤 관계에 있는지까지는 스스로 이해하지 못합니다.

2장. 문제는 데이터의 양이 아니라, 관계입니다

그림 2. 같은 대상을 시스템마다 다른 이름·태그·스키마로 기록해 흐름이 끊기는 구조.

공장에는 이미 데이터가 넘칩니다. 생산 실적, 설비 로그, 품질 검사, 물류 이력. 그런데 이 데이터들이 한 공장에서 나온 값임에도, 시스템 안에서는 서로 따로 놉니다. 출처와 담당 부서가 다를 뿐, 의미상 같은 개념을 각자의 방식으로 기록하기 때문입니다.

예를 들어, MES에서는 "Lot", 품질 시스템에서는 "Batch", 물류 시스템에서는 "Shipment Unit"이라는 이름으로 저장되는 값이, 사실은 같은 생산 단위를 가리키는 경우가 많습니다. 설비 태그도 마찬가지입니다. 어떤 시스템은 "EQ-101-Temp", 다른 시스템은 "Furnace1_TC1", 또 다른 시스템은 "설비1 온도센서"로 부릅니다. 의미와 맥락은 같은데, 이름·태그·스키마가 서로 다른 것입니다.

이 상태에서는 데이터가 부족한 게 아니라, 같은 대상을 서로 다른 언어로 부르는 상태가 문제입니다. 사람은 경험으로 이 매칭을 채우지만, AI Agent에게는 이 "같음"을 알려 주는 기준이 없기 때문에, 아무리 데이터가 많아도 하나의 공장으로 이어서 보지 못합니다. 진짜 문제는 데이터 사이의 관계와 맥락이 언어 수준에서 끊겨 있다는 점입니다.

3장. Ontology는 데이터의 족보를 그려 줍니다

그림 3. Ontology가 흩어진 데이터를 객체·관계·맥락으로 연결하는 구조.

Ontology는 어렵게 말하면 "개념과 관계를 정의하는 체계"이지만, 쉽게 말하면 공장 안의 데이터에 족보를 그려 주는 일입니다. 어떤 배치가 어느 설비에서, 어떤 공정 조건으로, 어떤 자재를 써서 생산되었고, 그 결과가 어떤 품질 결과와 물류 이력으로 이어졌는지 — 이 흐름을 객체 · 관계 · 맥락으로 정리해 두는 것입니다.

Ontology가 자리 잡으면, 흩어져 있던 데이터가 하나의 공장 이야기로 모입니다. "이 값은 무엇에 대한 값이고, 어떤 것과 연결되어 있으며, 어떤 맥락에서 나온 값인지"를 시스템이 스스로 설명할 수 있게 됩니다. 데이터의 양을 늘리는 것이 아니라, 데이터의 의미를 이어 붙이는 작업입니다.

4장. 관계가 연결되면, AI Agent는 협업할 수 있습니다

그림 4. 공통 Ontology 위에서 도메인별 Agent가 협업하고 Orchestrator가 조율하는 구조.

Ontology 위에서는 하나의 거대한 AI가 모든 일을 다 하지 않습니다. 대신, 각 도메인에 특화된 AI Agent들이 역할을 나눠 협업합니다. 생산 Agent는 생산 계획과 실적을, 설비·공정 Agent는 설비 상태와 공정 조건을, 품질 Agent는 검사 결과와 이상 징후를, 물류 Agent는 재고와 출하 이력을 각각 담당합니다.

이들이 서로의 결과를 이해할 수 있는 이유는, 같은 Ontology 위에서 같은 언어로 데이터를 바라보기 때문입니다. Orchestrator는 이 Agent들의 결과를 조율해, 사용자에게 맥락 있는 답변을 만들어 줍니다. 단순 조회가 아니라, "왜 그런지"와 "무엇을 봐야 하는지"를 함께 설명해 주는 답변입니다.

5장. 사람 검토를 거쳐, 근거 있는 행동으로 이어집니다

그림 5. 질문→추적→분석→사람 검토→검증 행동→설비·로봇 실행의 Human-in-the-Loop 흐름.

맥락을 이해한 AI Agent는 여기서 한 걸음 더 나아갑니다. 질문 → 관계 추적 → AI Agent 분석 → 사람 검토 → 검증된 행동 → 설비·로봇 실행의 흐름을 따라, 분석 결과를 곧바로 실행에 넘기지 않고 사람의 검토와 승인을 반드시 거칩니다.

이것이 Human-in-the-Loop 정책입니다. AI는 근거와 시나리오를 제시하고, 사람은 이를 검토해 최종 결정을 내립니다. 그 결과, 공장에서 실행되는 행동은 누구도 설명하지 못하는 자동화가 아니라, 근거와 책임이 분명한 자율화가 됩니다.

에필로그  —  관계가 곧 지능입니다

지능의 크기는 파라미터의 숫자가 아니라, 얼마나 많은 관계를 이해하고 있느냐로 결정됩니다. 공장의 AI도 마찬가지입니다. 더 큰 모델이 아니라, 더 잘 정리된 관계 위에 서 있는 AI가 공장을 이해합니다.

Ontology는 그 관계의 지도이고, 그 지도가 있어야 AI Agent들은 각자의 자리에서 협업할 수 있으며, 사람은 그 협업의 마지막을 검토할 수 있습니다. 결국 우리가 만들고 있는 것은 더 빠른 조회 도구도, 더 큰 모델도 아닙니다. 관계 위에서 사고하고, 사람과 함께 판단하는 공장의 지능입니다.