IDEF0란 무엇인가

01오래 살아남았다는 것의 의미

소프트웨어 세계에서 50년은 이례적인 시간입니다. 그 사이 등장했다 사라진 방법론과 도구가 수없이 많습니다. 그런데 IDEF0는 1970년대에 정리되어 지금도 국제표준으로 살아 있습니다.

이유는 단순합니다. IDEF0가 풀려던 문제가 아직 그대로 남아 있기 때문입니다. 그 문제란 이것입니다 — 우리가 어떻게 일하는지를 몇 장의 그림으로 적을 수 있는가. 그리고 그 그림을, 경영진도 현장도 전산실도 같은 뜻으로 읽을 수 있는가.

02뿌리 — 기계공과 프로그래머 사이의 통역

이야기는 1950년대 후반 MIT에서 시작합니다. 더글러스 로스(Douglas T. Ross)의 연구실은 미 공군의 지원으로 수치제어 공작기계를 만들었습니다. 사람이 본을 대고 깎던 밀링 작업을 컴퓨터가 대신하게 한 기계였습니다. 문제는 그다음이었습니다 — 그 기계에 무엇을 시킬지 사람이 적어야 했는데, 그러려면 기계공이 컴퓨터의 말을 배워야 했습니다.

연구실은 다른 길을 택했습니다. 쓰는 사람의 언어로 지시를 적게 한 것입니다. “냉각수를 켜라”, “A 지점에서 B 지점까지 직선으로 이동하라”처럼 말입니다. 이것이 훗날 국제 표준이 된 APT(Automatically Programmed Tool)이고, 몇 주가 걸리던 작업이 몇 분으로 줄었습니다.

그런데 여기서 진짜 중요한 것은 속도가 아니었습니다. 서로 다른 두 기술 세계 — 프로그래머의 세계와 기계공의 세계 — 사이에 통역이 생겼다는 점입니다. 둘 다 자기 분야의 전문가였지만, 쓰는 말이 달라 서로를 이해하지 못하던 사람들이었습니다.

03공장을 자동화하려는데, 공장을 몰랐다

1970년대 미 공군은 항공우주 산업 전체의 제조 역량을 끌어올리려 했습니다. 한 회사만 지원할 수는 없으니 업계가 함께 쓸 공통 기반을 만들기로 하고, 이를 ICAM(Integrated Computer Aided Manufacturing) 프로그램으로 묶었습니다.

그런데 시작하자마자 벽에 부딪힙니다. 공통 기반을 만들려면 먼저 “지금 이 산업이 어떻게 일하고 있는가”를 적어야 하는데, 그것을 적을 언어가 없었습니다. 그때 공군이 요구한 언어의 조건은 지금 읽어도 그대로 유효합니다.

이 조건을 만족한 것이 1972년 더글러스 로스와 SofTech이 정리한 SADT(Structured Analysis and Design Technique)였습니다. 공군의 AFCAM 사업에서 채택되어 ICAM으로 이어졌고, 1978년 항공우주 업계 연합이 이 방법으로 산업 전체의 모델을 만들어 냅니다. 그리고 1981년, 공군이 이 방법 가운데 활동 분석 부분만 떼어 정식 규격으로 문서화하며 붙인 이름이 IDEF0입니다. 이름 자체가 그 출신을 말합니다 — IDEF = ICAM DEFinition.

04파리에서 있었던 일

ICAM으로 가기 전, 이 방법은 전혀 다른 분야에서 먼저 시험대에 올랐습니다. 1970년대 초 ITT는 유럽에서 ‘미래의 전화 시스템’ 명세를 만들고 있었습니다. 통화 대기, 착신 전환처럼 지금은 당연한 기능들을 처음 정의하는 작업이었습니다.

다섯 나라의 전문가가 참여했고, 프로젝트는 일정이 밀린 채 멈춰 있었습니다. 영어·독일어·스페인어·프랑스어·이탈리아어로 된 문서가 파리 본사 선반에 쌓여 있었지만, 누구도 그 문서들이 서로 맞는지, 빠진 곳은 없는지 판단할 수 없었습니다.

해법은 로스의 도해 언어로 전체를 다시 분석하는 것이었습니다. 명세의 오류와 누락이 드러났습니다 — 이를테면 한 팀이 “저건 저쪽 팀 몫”이라고 잘못 알고 있던 부분이 그림 위에서 빈칸으로 나타났습니다. 다섯 나라의 분석가들은 비로소 서로의 담당 경계를 맞출 수 있었습니다.

이 프로젝트의 책임자였던 돈 콤벨릭은 이 방법에 제대로 된 이름이 필요하다고 보고 SADT라는 이름을 붙였습니다. 분석뿐 아니라 설계에도 쓸 수 있다는 뜻을 담았고, 가장 중요한 특징으로 추적 가능성을 꼽았습니다 — 사용자의 요구 하나하나가 그것을 실현하는 요소까지 이어져야 하고, 사용자 관점에서 쓸모를 설명할 수 없는 요소는 만들지 않는다는 원칙입니다.

05공군 문서에서 국제표준까지

한 조직의 내부 규칙으로 출발한 표기법은 이후 세 번의 관문을 통과하며 공용 자산이 됩니다.

• 1972 SADT — 더글러스 로스 · SofTech

  복잡한 것을 이해할 수 있을 때까지 쪼개 나가는 ‘분할 정복’의 원리를 도해 언어로 정리합니다.

• 1978 ICAM — 항공우주 산업 공통 모델

  한 회사가 아니라 업계 연합이 함께, 산업 전체가 어떻게 일하는지를 하나의 모델로 그려냅니다.

• 1981 IDEF0 — 미 공군 정식 규격

  SADT 가운데 활동 분석 부분이 공군의 공식 매뉴얼로 문서화되며 IDEF0라는 이름을 얻습니다.

• 1993 미 연방표준 — FIPS PUB 183

  미국 연방정부의 공식 표준으로 공표됩니다. 특정 기관의 방식이 아니라 정부가 보증하는 표기법이 된 시점입니다.

• 1998 IEEE 1320.1 — 학계·산업계의 표준

  국제 전기전자기술자협회(IEEE)가 문법과 의미를 정식 규격으로 정의합니다. 이때 IDEF0는 ‘그리는 관습’에서 문법이 명시된 언어로 넘어갑니다.

• 2012 국제표준 — ISO/IEC/IEEE 31320-1

  ISO 국제표준으로 편입되어 오늘에 이릅니다. 국가와 산업을 가리지 않고 통용되는 공통 문법이 되었습니다.

06순서도와 무엇이 다른가

업무를 그린다고 하면 대개 순서도(flowchart)를 떠올립니다. 화살표를 따라 ‘다음에 무엇을 하는가’를 좇는 그림입니다. IDEF0는 질문이 다릅니다.

이 네 가지를 ICOM이라 부릅니다 — 입력(Input)·통제(Control)·산출(Output)·수단(Mechanism). 활동을 나타내는 상자의 왼쪽·위·오른쪽·아래에서 각각 화살표가 붙습니다. 네 방향이 어떻게 붙는지는 홈페이지 첫 화면의 접근법 절에 그림으로 있습니다.

차이의 핵심은 통제와 수단에 있습니다. 데이터가 오가는 것만 그리는 그림은 “무엇이 흘러가는가”까지만 보여 줍니다. IDEF0는 여기에 그 일을 무엇이 규율하고 누가 수행하는지를 더해 한 장에 담습니다. 회사를 실제로 바꾸려 할 때 발목을 잡는 것은 대개 데이터가 아니라 규정과 사람이기 때문에, 이 두 면이 그림에 없으면 무엇을 바꿔야 할지 보이지 않습니다.

예를 들어 “검사 기준서에 따라 검사한다”에서 검사 기준서는 입력이 아니라 통제입니다. 검사를 거쳐도 기준서 자체는 변하지 않으니까요. 변하는 것은 원자재이고, 나오는 것은 성적서입니다. 이 구분을 강제하는 순간, 평소 뭉뚱그려 말하던 것들이 제자리를 찾아 갑니다.

07왜 하필 지금인가 — 기계가 읽는 시대

오랫동안 IDEF0의 가치는 ‘사람끼리 정확히 소통하는 것’이었습니다. 여기에 최근 한 가지가 더해졌습니다. 문법이 있는 그림은 기계도 읽을 수 있다는 점입니다.

규칙이 명시되어 있으니 기계가 검증할 수 있습니다. 상위에 있던 화살표가 하위에서 사라지지 않았는지, 연결이 끊긴 곳은 없는지를 사람이 눈으로 훑는 대신 프로그램이 짚어 줍니다. 그리고 검증을 통과한 모델은 그 자체로 AI가 다룰 수 있는 재료가 됩니다.

50년 전 공군이 “업계가 어떻게 일하는지 적을 언어가 없다”는 벽 앞에 섰다면, 오늘의 기업들은 “AI를 얹으려는데 우리가 어떻게 일하는지가 적혀 있지 않다”는 같은 벽 앞에 서 있습니다. 자동화의 이름만 컴퓨터에서 AI로 바뀌었을 뿐입니다.

유명소프트가 IDEF0를 JSON 기반 언어로 옮겨 다루는 이유가 여기 있습니다. 자세한 이야기는 백서 IDEF0 기능 모델링 — 디지털 전환의 핵심 방법론에 정리해 두었습니다.

08자주 듣는 세 가지 오해

09결국, 일하는 방식의 악보

말은 문자로 남았고 음악은 악보로 남았습니다. 악보라는 약속이 생기고서야 수십 명이 저마다 다른 파트를 들고도 한 편의 교향곡을 이루었고, 그 곡은 세대를 넘었으며, 마침내 기계도 연주하게 되었습니다.

회사도 다르지 않습니다. 여러 사람과 부서가 맞물려 하나의 결과를 만드는데, 정작 누구의 산출이 누구의 입력이 되는지는 어디에도 적혀 있지 않은 경우가 대부분입니다. IDEF0는 그것을 적는 50년 된 오선지입니다.