지난 글에서 다음 글로 미뤘던 다른 하나는 IDEF0로 불리는 Functional Modeling이다. IDEF는 Integration Definition의 약자로 시스템과 소프트웨어 엔지니어링에서 사용되는 여러 모델링 언어/포멀리즘을 표준화한 것이다. IDEF0에서 0가 있듯이 IDEF1, IDEF2 등 IDEF14까지 총 16개 (IDEF1X도 있음)로 정리된다. 데이터 베이스에서 많이 사용되는 ERD는 IDEF1X Data Modeling에 정의돼있고, 그 외에도 프로세스나 온톨로지, OOD 등의 우리가 알고 있는 대부분의 다이어그램이 정의돼있다. 미국표준기술원 (NIST, National Institute of Standards and Technology)을 중심으로 정의된 것이지만 우리의 실생활에서의 실제 사용은 다소 다를 수 있다. 일부는 항목만 있을 뿐 실제 구현/정의되지도 않았다. 사람들이 이를 많이 사용하든 아니든 시스템의 기능을 정의하고 세분화한 IDEF0의 개념과 노테이션은 시스템을 분석하거나 정의할 때 (나는) 많이 활용하고 있다. (https://www.idef.com/ / https://en.wikipedia.org/wiki/IDEF)
ICOM.
IDEF0는 Function, 즉 시스템의 기능/Activity를 정의한다. 즉, 어떤 인풋을 받아서 어떤 과정을 거쳐서 아웃풋을 도출하는지를 도식화한다. 아래의 그림과 같이 중간에 Activity가 있고, 왼쪽에는 Input이 들어오고, 오른쪽으로 Output이 나가고, 위에는 Control, 아래에서는 Mechanism을 표시한다. Input, Control, Output & Mechanism의 첫글자를 따와서 ICOM이라 부른다. 제조, 생산 시스템에서는 좀 더 명확한데, 정보시스템에 활용할 때는 조금 모호한 부분도 있다.
-
Activity: 시스템의 기능을 표시한 것으로 보통 동사로 기술한다. 아래에 적었듯이 하나의 Activity는 여러 개의 sub-activities로 decompose될 수 있다.
-
Input: 시스템에 들어가는 입력값을 표시한다. 시스템의 Activity를 통해서 Input이 Output으로 바뀐다.
-
Control: Input처럼 시스템에 투입되지만 Input과 달리 Output으로 변환되지 않는다. 정보시스템에서는 인풋과 콘트롤을 구분하는 게 다소 모호한 경우가 많은데, 구분하기 어려우면 일단 컨트롤로 취급한다.
-
Output: Activity 공정을 거친 후에 만들어지는 산출물이다.
-
Mechanism: 인풋에서 아웃풋으로 변환되는 과정이 이뤄지는 환경/시스템이다.
막대형 재료를 돌려서 깎는 선반 작업을 예로 들어 설명하겠다. (예, https://www.youtube.com/watch?v=i672qeFXm5M 가끔 이런 영상을 생각없이 계속 보고 있으면 재미있다.) 이 공정은 '선반 Lathe’이라는 기계에서 이뤄지므로 선반이 이 공정의 Mechanism이다. 통나무를 재료로 해서 항아리를 만들기 때문에 통나무가 Input이고 항아리가 Output이다. 선반의 모터를 돌리는 데 사용되는 전기나 금속 가공 시에 냉각과 절삭에 도움을 주는 절삭유 등이 Control에 해당한다. 데이터 과학을 예로 들면, 기계학습 알고리즘이나 라이브러리가 Mechanism이 되고, 분석/학습할 데이터가 Input, 분석 결과나 학습된 모델이 Output, 그리고 학습에 필요한 여러 하이퍼 파라미터나 부가 정보가 Control이 된다. 인풋과 컨트롤의 구분이 모호한 경우도 많지만, Mechanism을 특정하기 어려운 경우가 정보 시스템에는 잦다. 그래서 Mechanism이 생략된 다이어그램이 많다.
Decomposition
하나의 Activity는 세부 sub-activity로 분해될 수 있다. 최상위의 Activity를 A0라고 하고, A0를 decompose한 sub-activity들은 A1, A2, … 로 표시되고, A1도 다시 A1-1, A1-2, … 등으로 더 세분화될 수 있다. 귀찮아서 위키에서 아래 그림을 가져왔다. 하나의 Activity가 4개의 sub-activity로 분해된 것을 도식화했고, 각 sub-activity 사이의 재료/데이터 흐름을 보여준다. 최상위 Activity에서 ICOM을 정의했지만, sub-activity는 상위 ICOM을 그대로 받아서 사용하기도 하고 별도의 ICOM을 추가할 수도 있다. Sub-activity에서 나온 output이 다른 sub-activity의 input이나 control로 사용될 수도 있다. 그리고 이 decomposition은 기능을 세분화한 것이므로 A1, A2, … 등의 sub-activity의 넘버링이 실제 프로세스와 다를 수도 있다. 즉, 데이터의 이동 관계를 표시한 것이지 액티브티의 순서를 도식화한 것이 아니다.
IDEF0 모델을 여전히 (많이) 사용하고 있는지 나는 알지 못한다. 그러나 나는 이 노테이션을 사용해서 새로운 시스템을 설계하거나 기존 시스템을 분석, 정리할 때 종종 활용한다. 시스템 전체를 크게 볼 수도 있고 데이터 흐름을 포함해서 구체적/세부적으로도 파악할 수 있기 때문이다. 데이터 과학자의 일과는 다소 동떨어져보일 수도 있지만, 때로는 시스템 전체를 이해해야지 데이터와 분석을 제대로 파악할 수도 있고 또 분석 내에서의 여러 모듈들 간의 관계를 이해함으로써 깔끔한 분석 시스템/흐름을 만들 수 있다. 그리고 발표나 보고를 위해서도 이렇게 activity를 정의하고, 인풋과 아웃풋을 명확히 그림으로 그리는 게 도움될 때도 많다. 물론 청자나 독자가 이 포멀리즘을 이해하고 있어야 하지만…
광고의 CTR을 예측하는 태스크를 간략히 A0 모델로 그렸다 (실제와 많이 다름). 이렇게 그림을 그려봄으로써 어떤 데이터를 사용하는지 또는 빠진 데이터 (인풋)이 없는지를 미리 점검할 수 있다. 어떤 라이브러리를 이용해서 어떤 모델로 구축했는지도 파악할 수 있고, 여러 모델링 요소 (하이퍼파라메터)를 나열해서 빠진 부분이 없는지 또는 추후에 실험 설계는 어떻게 할지 계획할 수 있다. 내외부 공유를 위해서 이 그림을 그렸다면 웬만큼 지성이 있다면 현황을 바로 파악할 수 있을 거다. A0를 다시 데이터 준비, 모델 구축, 모델 검증, 그리고 CTR 추론 등의 세부 sub-activity로 쪼개서 표현할 수 있다. 그런 그림만 봐도 ‘CTR 예측’을 위해서 세부적으로 어떤 기능이 필요하고 어떤 모듈로 쪼개서 개발하면 될지를 쉽게/바로 파악할 수 있다.
이 짧은 글로 IDEF0 Functional Modeling을 완벽히 이해시키려는 것은 아니다. 혹시 이런 포멀리즘이 필요한 분이라면 — 내겐 큰 도움이 된 프랙티스였기에 — IDEF0를 자세히 찾아보고 익혀서 하는 일에 적용했으면 하는 바람에서 적었다.
