[칼럼] 온톨로지, 제조 데이터에 '의미'를 설계하다

온톨로지, 제조 데이터에 '의미'를 설계하다

컨셉맵에서 지식그래프까지, 그리고 바이브코딩

류용효 | 디원 상무 · 류용효컨셉맵연구소

지난 7월, 필자는 '데이터공작소' 온톨로지 스터디그룹에서 「지식그래프: AI와 온톨로지로 여는 지식혁명」(이강배 저)의 3장을 주제로 발표를 진행했다. 발표 제목은 '온톨로지의 개념, 그리고 컨셉맵'. 이 글은 그날의 발표를 제조기업의 경영자와 실무자를 위해 다시 정리한 것이다. 그리고 글의 끝에서, 8월에 출간되는 필자의 새 책 이야기를 잠시 나누려 한다. 두 이야기는 겉보기엔 다르지만, 결국 하나의 질문으로 만난다. “AI 시대, 우리의 경험과 지식은 어떻게 시스템 위에서 다시 움직이는가.”

“좋습니다. 그런데 실제로 되는 겁니까?”

 

제조기업의 회의실 풍경이 달라지고 있다. 예전에는 잘 정리된 문서와 유창한 설명이 설득의 무기였다. 지금은 다르다. AI 도입 보고가 끝나면 경영진은 이렇게 묻는다. “좋습니다. 그런데 실제로 되는 겁니까?” 방향이 아니라 증거를, 설명이 아니라 결과를 요구하는 시대가 된 것이다.

그런데 막상 '실제로 되게' 하려고 하면, 대부분의 제조기업은 같은 벽에 부딪힌다. 데이터는 많은데 연결이 안 된다. ERP, MES, PLM, CRM에 수십 년 치 데이터가 쌓여 있지만, 같은 부품이 부서마다 다른 코드로 등록되어 있고, 같은 고객이 시스템마다 다른 이름으로 존재한다. AI에게 “이번 달 출하 지연 리스크를 요약해 달라”고 묻고 싶어도, AI는 우리 회사의 '출하'가 무엇이고 '지연'이 어떤 기준인지 알지 못한다. 데이터는 있지만 '의미'가 없기 때문이다.

이 문제를 정면으로 겨냥한 개념이 바로 온톨로지(Ontology)다. 미 국방부와 BMW, 에어버스 같은 기업들이 팔란티어(Palantir) 플랫폼에 주목하는 이유도, 그 중심에 온톨로지가 있기 때문이다.

온톨로지, 어렵지 않다 — 출석부와 우리 반 지도

온톨로지라는 단어는 철학의 존재론에서 왔다. 낯설게 들리지만, 개념 자체는 초등학생도 이해할 수 있다. 전학 온 친구에게 우리 반을 소개하는 상황을 떠올려 보자. 이름만 쭉 적힌 출석부를 건네는 방법이 있고, “민수는 축구를 좋아하고, 지우와 짝꿍이다”처럼 관계를 그린 지도를 건네는 방법이 있다. 출석부는 데이터의 나열이고, 지도는 지식의 구조다. 어느 쪽이 우리 반을 더 잘 설명하는지는 물을 필요도 없다.

이 지도에는 온톨로지의 재료 네 가지가 모두 들어 있다. '3반 친구'라는 범주가 클래스(Class), 민수와 지우라는 실제 인물이 인스턴스(Instance), 키 145cm 같은 특징이 속성(Attribute), '짝꿍이다'라는 연결이 관계(Relationship)다. 책은 이를 노트북으로 설명한다. '컴퓨터'와 '노트북'은 클래스, 'LG gram'은 인스턴스, '사양과 가격'은 속성, “노트북은 컴퓨터에 포함된다”는 관계다. 회사 버전으로 바꾸면 이렇게 된다. '고객·제품·설비'가 클래스, 'A조선소와 스크러버 1호기'가 인스턴스, '소재지·등급·가동상태'가 속성, “A조선소는 스크러버를 발주했다”가 관계다.

스탠포드대 토마스 그루버 교수는 온톨로지를 “공유된 개념화의 정형화되고 명시적인 명세”라고 정의했다. 어렵게 들리지만 세 조각으로 나누면 명료하다. '공유된 개념화'란 부서마다 다르게 부르던 용어를 하나로 합의한 회사 공용어 사전이고, '정형화·명시적'이란 베테랑의 머릿속 암묵지를 규정집처럼 명문화하는 것이며, '명세'란 그것을 사람만이 아니라 시스템도 읽을 수 있는 업무 문법으로 만드는 것이다. 한 줄로 줄이면, 책 76쪽의 표현 그대로 “특정 분야의 지식을 구조화하여 컴퓨터가 이해하고 처리할 수 있도록 표현한 것”이다.

스키마가 이미 있는데, 왜 온톨로지인가

실무자들이 가장 많이 던지는 질문이 있다. “우리 DB에도 이미 테이블 설계, 즉 스키마가 있는데 뭐가 다릅니까?” 책 3.1.1이 정확히 이 질문에 답한다. 스키마는 데이터의 구조를 정의한다. 고객 테이블에 이름과 나이 컬럼이 있다는 식이다. 반면 온톨로지는 “고객은 사람의 하위 클래스이고, 구매 행동을 수행할 수 있다”는 지식 자체를 모델링한다. 스키마의 모델링 대상이 '데이터'라면, 온톨로지의 대상은 '개념과 개념 간 관계'이며, 결정적 차이는 추론 가능 여부다.

제조 현장의 언어로 옮기면 차이가 더 선명해진다. '선박 코드 SHIP-001, 블록 ID BLK-A-017, 작업 ID WLD-0342'라고 코드를 나열하는 것이 기존 데이터 모델이라면, 온톨로지는 “선박은 블록으로 구성된다, 블록은 용접작업을 필요로 한다, 용접은 특정 자격을 가진 작업자만 수행한다, 모든 작업은 규정된 품질 기준을 따라야 한다”는 업무의 문법을 시스템에 심는다. 이 문법이 있어야 설계변경이 발생했을 때 시스템이 영향받는 블록을 스스로 추적하고, 작업을 재계획하고, 지연 리스크를 예측할 수 있다. 사람이 엑셀로 하루 걸리던 영향 분석이 관계를 따라 실시간으로 이루어지는 것이다. 팔란티어가 조선·자동차 산업에서 보여주는 시나리오가 정확히 이것이며, 그 구동 방식은 다섯 단계다. 레거시 데이터를 옮기지 않고 연결하고, 그 위에 온톨로지 계층을 얹어 의미를 부여하고, 현장이 쓰는 업무 앱을 제공하고, 조치의 비용과 리스크를 시뮬레이션하고, 마지막으로 AI(AIP)가 실행까지 연결한다.

스키마가 '데이터를 담는 그릇의 규격'이라면, 온톨로지는 '지식의 의미와 규칙까지 담는 모델'이다. 그리고 이 온톨로지라는 설계도에 실제 데이터를 채워 넣은 결과물이 지식그래프(Knowledge Graph)다. 구글의 의미 검색과 아마존의 추천이 이미 그 위에서 돌아가고 있다.

회의실의 컨셉맵이 시스템의 온톨로지가 되기까지

여기서 필자가 오래 다뤄 온 주제인 컨셉맵(Concept Map)이 등장한다. 1970년대 코넬대 조셉 노박이 개발한 컨셉맵은 개념(상자)과 연결어(화살표 위의 단어)로 명제를 그리는 생각의 지도다. “온톨로지는 지식그래프의 청사진이다”처럼, 개념-연결어-개념이 한 문장을 이룬다. 흥미로운 것은 이 명제 구조가 지식그래프의 기본 단위인 트리플(주어-술어-목적어)과 정확히 같다는 점이다. 컨셉맵과 온톨로지는 같은 뿌리에서 나온, 독자가 다른 두 표현이다. 컨셉맵은 사람이 읽는 지식의 스케치이고, 온톨로지는 기계까지 읽는 지식의 도면이다.

그래서 필자는 두 가지를 경쟁 관계가 아니라 '한 정의의 앞뒤 반쪽'이라고 부른다. 그루버 정의로 돌아가 보면, 전문가들이 모여 컨셉맵을 그리고 용어를 표준화하는 과정이 '공유된 개념화'이고, 그 합의를 클래스·관계·규칙으로 변환해 시스템에 싣는 과정이 '정형화되고 명시적인 명세'다. 컨셉맵 없이 온톨로지를 만들면 합의 없는 표준이 되고, 온톨로지 없이 컨셉맵만 있으면 그림으로 끝난다. 실무 적용법은 단순하다. 업무 인터뷰와 워크숍의 대화를 실시간 컨셉맵으로 기록해 암묵지를 형식지로 바꾸고, 부서 간 용어 합의의 회의 도구로 쓰고, 합의된 맵을 개념은 클래스로, 연결어는 관계로 변환해 온톨로지 설계의 초안으로 삼는 것이다. 도구는 Cmap이든 화이트보드든 상관없다.

경영자에게 강조하고 싶은 지점이 있다. 온톨로지 프로젝트의 성패는 기술이 아니라 합의에서 갈린다. 그리고 품목 명칭조차 통일되지 않은 상태라면 어떤 온톨로지도 그 위에 설 수 없다. 그래서 현실적인 로드맵은 전사 빅뱅이 아니라, 효과가 분명한 핵심 도메인 하나(예컨대 품목·BOM·변경관리)를 골라 컨셉맵으로 합의를 만들고, 온톨로지로 정형화하고, 데이터를 채워 인접 도메인으로 확장하는 것이다. 책도 균형 있게 짚는다. 도메인이 복잡할수록 설계와 유지보수가 어렵고 주기적 갱신 부담이 있다. 그러니 작게 시작해야 한다.

그리고, 바이브코딩 — 8월의 새 책 이야기

온톨로지가 '조직의 지식'을 시스템이 이해하게 만드는 일이라면, 개인 차원에서 같은 전환을 다룬 이야기가 있다. 오는 8월 출간 예정인 필자의 새 책, 「베테랑 기획자의 바이브코딩 도전기」다.

“나는 아직 유효한 사람인가.” — 회의실에서 젊은 동료들이 빠르게 도구를 다루는 모습을 볼 때, 은퇴라는 단어가 더 이상 먼 일이 아니게 느껴질 때, 조용히 계산하곤 했다. 내가 가진 경험이 앞으로도 통할까.

책은 이 질문에서 출발한다. 바이브코딩(Vibe Coding)이란 프로그래밍 문법을 외워 코드를 치는 것이 아니라, Cursor나 Gemini 같은 AI 도구에게 자신의 의도와 맥락을 전달해 프로그램을 만들도록 지휘하는 일하는 방식이다. 필자는 데이터공작소 스터디에서 8개월간 개발자들과 함께 배우며, 하루 30분씩 눈으로 70%를 이해하고 손으로 30%를 부딪히는 자신만의 학습 공식을 찾았다. 거창한 프로젝트가 아니라 매주 나를 지치게 하던 엑셀 정리 하나, 파일 정리 하나부터 고쳐 나가는 '하루 한 프로그램'의 기록이다. 책의 부록에서는 노코드·로코드·바이브코딩을 비교하며 언제 무엇을 써야 하는지도 다룬다. 요구사항이 표준적이면 노코드, 예외처리와 연동이 필요하면 로코드, 요구사항이 계속 바뀌고 기획자가 직접 프로토타입을 쥐어야 한다면 바이브코딩이다.

눈 밝은 독자라면 이미 알아챘을 것이다. 온톨로지 도입 로드맵과 바이브코딩 학습법은 같은 철학 위에 서 있다. 작게 시작하고, 합의(같은 방향)를 먼저 만들고, 증거로 말하는 것. 조직은 온톨로지로 지식을 시스템에 싣고, 개인은 바이브코딩으로 의도를 실행에 싣는다. 제조기업의 디지털 전환이란 결국 이 두 층위가 만나는 지점에서 완성된다.

맺으며 — 같은 방향을 본다는 것

생텍쥐페리는 “사랑이란 서로 바라보는 것이 아니라, 서로 같은 방향을 보는 것”이라고 했다. 필자가 이 문장을 좋아하는 이유는, 프로젝트와 조직의 성패도 결국 같은 방향을 보는 능력에서 갈리기 때문이다. 온톨로지는 사람과 시스템이, 현장과 경영진이, 그리고 사람과 AI가 같은 방향을 보게 만드는 언어다. LLM은 유창하지만 사실에 약하고, 지식그래프는 사실에 강하다. 둘의 결합이 신뢰할 수 있는 기업 AI의 핵심이라는 책의 통찰(6.3장)은, 앞으로 제조기업의 AI 전략이 어디로 가야 하는지를 가리키고 있다.

이번 여름, 회의실 화이트보드에 우리 회사의 컨셉맵 한 장을 그려 보시기를 권한다. 우리 회사의 '고객'이란 무엇인가, '품목'과 '설비'는 어떻게 연결되는가. 그 한 장의 합의가 온톨로지의 시작이고, 지식그래프의 청사진이며, AI가 우리 회사를 이해하는 첫 문장이 된다.

 

■ 필자 소개  류용효 | ㈜디원 상무(PLM기술본부)로 재직 중이며, 페이스북 '류용효컨셉맵연구소' 리더, CNGTV 지식방송 전문위원으로 활동하고 있다. PTC코리아, 오라클, 지멘스 PLM 등을 거치며 PLM과 프로세스 컨설팅 분야에서 일해 왔다. 저서로 「베테랑 기획자의 바이브코딩 도전기」(2026년 8월 출간 예정)가 있다. (yonghyo.ryu@gmail.com)