IDEF0 기능 모델은 기업 온톨로지의 뼈대가 될 수 있습니다. 온톨로지가 「회사가 다루는 것들과 그 관계」를 정의하는 일이라면, IDEF0는 이미 「어떤 일이 무엇을 받아 무엇을 내놓는지」를 정의하고 있기 때문입니다. 다만 IDEF0가 주는 것은 완성된 온톨로지가 아니라 무엇을 정의해야 하는지 알려 주는 설계도입니다.
01기업 온톨로지란 무엇인가?
기업 온톨로지는 회사가 다루는 「것」들과 그것들 사이의 관계를, 사람과 기계가 같은 뜻으로 읽도록 정의해 둔 사전입니다. 「주문」이 무엇인지, 「주문」과 「출하지시」는 어떻게 이어지는지, 누가 「주문」을 바꿀 수 있는지를 한곳에 적어 둔 것입니다.
영업팀의 「수주」와 생산팀의 「오더」가 같은 것인지 다른 것인지 — 이런 질문에 답이 정해져 있는 회사가 온톨로지를 가진 회사입니다. 사람끼리는 눈치로 메워 온 빈칸이지만, AI는 눈치가 없습니다. AI는 데이터를 읽을 수는 있어도, 그 데이터가 회사에서 무슨 뜻인지는 누군가 알려 주어야 압니다. 온톨로지가 AI 시대에 다시 불려 나온 이유입니다.
02팔란티어는 온톨로지를 어떻게 정의하는가?
팔란티어 Foundry의 온톨로지는 회사의 데이터를 그 데이터가 가리키는 현실의 대상 — 공장·설비·제품·주문·거래 — 과 연결하는 운영 계층입니다 [1]. 팔란티어는 이것을 두 부분으로 나눕니다.
| 구분 | 팔란티어의 이름 | 무엇을 담나 |
|---|---|---|
| 의미 부분 semantic | 객체 유형 · 속성 · 링크 유형 | 회사에 무엇이 있고, 서로 어떻게 이어지나 — 명사 |
| 움직임 부분 kinetic | 액션 유형 · 함수 · 권한 | 그것들을 누가, 어떤 규칙으로 바꾸나 — 동사 |
눈여겨볼 대목은 두 번째 줄입니다. 팔란티어의 온톨로지는 데이터 사전에서 멈추지 않습니다. 「액션 유형」은 객체·속성·관계를 한 번에 바꾸는, 통제된 거래로 정의됩니다 [2]. 회사의 데이터뿐 아니라 회사가 일하는 방식까지 온톨로지에 넣겠다는 것입니다.
명사만 있는 온톨로지는 창고 목록입니다. 동사가 들어가야 비로소 회사가 돌아가는 모습이 됩니다.
03IDEF0는 무엇을 그리는가?
IDEF0는 일(활동)을 상자로, 그 일이 주고받는 것을 화살표로 그려, 「어떤 일이 무엇을 받아 무엇을 내놓는지」를 정의하는 국제표준 기능 모델링 언어입니다 [3]. 상자 하나에 화살표가 네 방향으로 붙습니다.
| 화살표 | 뜻 | 예 — 「주문을 확정한다」 |
|---|---|---|
| I입력 Input | 일이 받아서 바꾸는 것 | 고객 발주서 |
| C통제 Control | 일을 묶는 규칙·기준 | 여신 한도 규정, 단가표 |
| O산출 Output | 일이 내놓는 것 | 확정 주문, 출하지시 |
| M수단 Mechanism | 일을 하는 사람·시스템 | 영업관리 담당, ERP |
그리고 상자 하나는 다시 3~6개의 상자로 쪼개집니다. 「주문을 처리한다」는 「접수한다 → 확인한다 → 확정한다」로 내려가고, 위아래 그림의 화살표는 빠짐없이 서로 맞아야 합니다. 계보와 표기 원칙은 「IDEF0란 무엇인가」에 정리했습니다.
04IDEF0와 온톨로지는 어디서 맞물리는가?
IDEF0의 화살표는 온톨로지의 객체가 되고, 활동 상자는 액션이 되며, 한 활동의 산출이 다른 활동의 입력으로 들어가는 자리는 객체 사이의 관계가 됩니다. 한 칸씩 대 보면 이렇습니다.
| IDEF0에서 | 온톨로지에서 (팔란티어 이름) | 예 |
|---|---|---|
| IO입력·산출 화살표 | 객체 유형 | 발주서, 확정 주문, 출하지시 |
| 활동 상자 | 액션 유형 | 「주문을 확정한다」 = 주문의 상태를 바꾸는 거래 |
| C통제 화살표 | 함수 · 검증 규칙 | 여신 한도를 넘으면 확정할 수 없다 |
| M수단 화살표 | 권한 · 실행 주체 | 영업관리 담당만 확정할 수 있다 |
| 산출 → 다른 활동의 입력 | 링크 유형 | 확정 주문 하나가 출하지시 여럿을 낳는다 |
| 상자의 분해 계층 (A-0 → A0 → A1…) | 온톨로지의 범위 · 영역 구분 | 영업 영역 / 생산 영역 |
표를 위에서 아래로 읽으면 한 가지가 보입니다. 팔란티어가 명사(의미 부분)와 동사(움직임 부분)로 나눈 두 층을, IDEF0는 상자와 화살표라는 한 장의 그림에 함께 담고 있습니다.
IDEF0에서는 화살표가 홀로 떠 있을 수 없습니다. 모든 화살표는 어떤 일에서 나와 어떤 일로 들어갑니다. 그래서 IDEF0로 그린 회사에는 쓰이지 않는 데이터도, 이유 없는 데이터도 없습니다. 데이터 하나하나에 「어느 일이 이것을 만들고, 어느 일이 이것을 쓰는가」라는 내력이 붙어 있는 것입니다.
05데이터에서 출발하는 것과 일에서 출발하는 것은 무엇이 다른가?
데이터에서 출발하면 무엇이 중요한지 모른 채 테이블 수천 개를 정리하게 되고, 일에서 출발하면 목적에 필요한 객체만 남습니다.
DATA-FIRST데이터에서 출발
ERP·MES·엑셀의 테이블을 모아 놓고 「이건 무엇이고 저건 무엇과 이어지나」를 하나씩 묻습니다. 성실하지만 끝이 없습니다. 어느 테이블이 회사의 결정에 쓰이는지는 테이블이 말해 주지 않습니다.
WORK-FIRST일에서 출발
먼저 회사가 하는 일을 정의하고, 그 일에 드나드는 것만 객체로 삼습니다. IDEF0는 그리기 전에 목적과 관점을 정하므로, 「누구의 눈으로, 무엇을 위해」가 객체를 고르는 기준이 됩니다.
위성사진과 지도의 차이와 같습니다. 데이터에서 출발하는 온톨로지는 위성사진에 이름표를 붙이는 일입니다. 모든 것이 다 찍혀 있지만 길을 찾기는 어렵습니다. 일에서 출발하는 온톨로지는 지도를 그리는 일입니다. 목적에 필요한 것만 남기고, 그것들이 어떻게 이어지는지를 먼저 보여 줍니다.
팔란티어가 고객 현장에 엔지니어(FDE)를 보내는 것도 같은 이유로 읽을 수 있습니다. 데이터만 봐서는 회사의 뜻을 알 수 없으니, 일하는 사람 곁에서 일을 보고 그것을 온톨로지로 옮기는 것입니다. IDEF0는 그 「일을 보는 눈」을 표준 언어로 적어 남기는 방법입니다. 이 이야기는 「FDE에게 필요한 「업무를 읽는 눈」」에서 더 다뤘습니다.
06IDEF0만으로 온톨로지가 완성되는가?
아닙니다. IDEF0는 온톨로지의 뼈대와 동사 목록을 주지만, 객체의 속성·식별 기준·실제 데이터와의 연결은 따로 채워야 합니다. 선을 정직하게 그어 두면 이렇습니다.
| IDEF0가 주는 것 | 따로 채워야 하는 것 |
|---|---|
| 어떤 객체가 있어야 하나 (화살표 이름) | 객체의 속성 — 주문에는 어떤 항목이 있나 |
| 객체가 어떤 일을 거쳐 이어지나 | 객체 하나를 무엇으로 가려내나 — 주문번호인가, 고객+일자인가 |
| 누가, 어떤 규칙으로 바꾸나 | 그 객체가 실제로 어느 시스템의 어느 테이블에 있나 |
| 회사 전체에서 어디까지가 한 영역인가 | 일이 어떤 순서·조건으로 흐르나 — 분기, 반복, 시간 |
흥미로운 것은 이 빈칸을 채우는 방법도 IDEF 집안에 이미 있다는 점입니다. 데이터 구조는 IDEF1X, 일의 순서와 흐름은 IDEF3, 그리고 개념 사이의 관계를 정의하는 일은 이름부터 IDEF5 — 온톨로지 개발 방법입니다 [4]. 미 공군의 ICAM 사업은 이미 「기능 → 데이터 → 흐름 → 온톨로지」를 한 줄로 이어 보려 했던 셈입니다.
그 집안의 첫 번째 번호가 IDEF0인 것은 우연이 아닙니다. 속성도, 흐름도, 관계도 「무엇을 위한 일인가」가 정해진 뒤에야 어디까지 정의할지가 정해집니다. 무엇을 정의할지는 일이 정합니다.
07기업 온톨로지는 무엇부터 시작하면 되는가?
회사나 사업부의 일을 IDEF0로 한 장 그리고, 그 화살표 이름을 회사의 첫 번째 객체 사전으로 삼으면 됩니다. 순서는 다섯 걸음입니다.
1단계 — 일을 한 장 그린다
목적과 관점을 한 줄씩 정하고, 회사 또는 사업부 전체를 상자 하나(A-0)로 놓은 뒤 큰 활동 3~6개(A0)로 나눕니다. 활동 사이를 오가는 것을 모두 화살표로 적습니다.
2단계 — 화살표 이름을 명사 사전으로 옮긴다
부서마다 다르게 부르던 것을 한 이름으로 정합니다. 「수주」와 「오더」가 같은 것이면 하나로, 다르면 둘로. 이것이 객체 유형의 후보입니다.
3단계 — 「산출 → 입력」 자리를 관계로 옮긴다
어느 객체가 어느 객체를 낳는지, 하나가 여럿을 낳는지를 적습니다. 이것이 링크 유형의 후보입니다.
4단계 — 통제와 수단을 규칙과 권한으로 옮긴다
누가, 어떤 기준으로 객체를 바꾸는지가 액션 유형과 권한의 후보입니다. 통제 칸이 문서가 아니라 사람 머릿속에 있다면, 그 자리가 온톨로지보다 먼저 정리해야 할 곳입니다.
5단계 — 그다음에 데이터를 붙인다
이제야 「이 객체는 어느 시스템의 어느 테이블에 있나」를 묻습니다. 묻는 범위가 처음부터 좁혀져 있어 데이터 작업이 끝이 납니다.
이 순서로 가면 온톨로지는 데이터 정리 사업이 아니라 일하는 방식을 정의하는 사업이 됩니다. 그리고 그렇게 만든 온톨로지는, 팔란티어가 말하는 의미 부분과 움직임 부분을 처음부터 함께 갖고 태어납니다. 실제로 일을 한 장으로 그린 예는 모델링 사례에서 볼 수 있습니다. 같은 그림을 회사 전체의 기능 체계로 넓혀 세우는 길은 백서 전략적 엔터프라이즈 아키텍처 수립에서 다룹니다.
데이터는 일의 흔적입니다. 흔적을 모아 일을 거꾸로 짐작하기보다, 일을 먼저 그리고 그 일이 남기는 것을 정의하는 편이 빠르고 정확합니다.
일에서 출발하는 온톨로지 — 유명소프트는 그 출발점을 국제표준 IDEF0로 그립니다.참고 문헌
-
Ontology overview Palantir Foundry Documentation. palantir.com/docs/foundry/ontology/overview 이 글에서 — 2절의 온톨로지 정의(데이터를 현실의 대상과 연결하는 운영 계층)와 의미 부분·움직임 부분의 구분.
-
Ontology core concepts Palantir Foundry Documentation. palantir.com/docs/foundry/ontology/core-concepts 이 글에서 — 객체 유형·링크 유형·액션 유형의 정의, 액션을 「통제된 거래」로 보는 관점.
-
Integration Definition for Function Modeling (IDEF0) Federal Information Processing Standards Publication 183 (FIPS PUB 183). National Institute of Standards and Technology, 1993년 12월 21일. 국제표준은 ISO/IEC/IEEE 31320-1:2012. 이 글에서 — 3절의 입력·통제·산출·수단 정의와 활동 분해 규칙.
-
IDEF5 Method Report Knowledge Based Systems, Inc. 미 공군 Armstrong Laboratory 위탁, 1994년. 이 글에서 — 6절의 IDEF 집안 안에 온톨로지 개발 방법(IDEF5)이 따로 있다는 근거.
팔란티어 관련 내용은 해당 회사의 공개 문서에 근거하며, IDEF0와의 대응 관계와 해석은 유명소프트의 것입니다. 팔란티어와 유명소프트 사이에는 어떤 제휴 관계도 없습니다.