Zachman Framework

무엇인가

John Zachman 은 IBM 에서 대형 고객의 정보 시스템 기획을 오래 다룬 사람이다. 그가 1987년 IBM Systems Journal 에 발표한 "A Framework for Information Systems Architecture" 는 흔히 엔터프라이즈 아키텍처(EA)의 출발점으로 꼽힌다. 문제의식은 단순했다 — 기업의 정보 시스템은 너무 복잡해서 한 장의 그림으로 기술할 수 없고, 건축·항공기 제조가 그렇듯 여러 관점의 여러 표현물이 필요하다. 그렇다면 그 표현물들을 빠짐없이·겹침 없이 정리하는 분류틀이 먼저 있어야 한다.

답이 된 틀이 의문사 6열 × 관점 6행의 매트릭스다. 열은 영어의 기본 의문사, 곧 6하원칙이다. 1987년 원 논문은 What/How/Where 3열로 출발했고, 1992년 John Sowa 와의 공저 논문에서 Who/When/Why 가 더해져 지금의 6열이 완성됐다.

행은 같은 기업을 바라보는 서로 다른 이해관계자의 관점이다. 계획자(범위) → 소유자(비즈니스 모델) → 설계자(시스템 모델) → 구축자(기술 모델) → 구현자(상세 표현) → 실제 가동되는 기업. 위 행에서 아래 행으로 갈수록 상세해지는 것이 아니라, 관점 자체가 바뀐다는 것이 Zachman 의 강조점이다 — 건축주의 조감도와 배관공의 배관도는 상세도가 다른 같은 그림이 아니라 다른 그림이다.

틀에는 규율이 붙어 있다. 열 사이에 순서·우선순위가 없다는 것, 각 열은 자기만의 단순한 기본 모델(예: What 열은 개체–관계)을 갖는다는 것, 6×6 = 36개 셀은 각각 고유하며 한 행의 셀들을 합치면 그 관점에서의 완전한 기술이 된다는 것. Zachman 자신은 이 틀을 방법론이 아니라 온톨로지(분류 스키마)라고 못 박는다 — 무엇을 어떤 순서로 만들라는 절차는 없고, 만들어질 수 있는 기술물의 자리만 정의한다. 채우는 절차는 TOGAF 같은 별도 방법론의 몫으로 남았고, 이후 미국 연방·국방 EA 프레임워크(FEAF·DoDAF)가 이 틀의 영향 아래 만들어졌다.

우리 모델과의 접점

지도의 접점 문구 — 6하가 개인 기록만 아니라 시스템 기술 전반의 분류축으로 쓰인 선례이자, "성분마다 자리가 있다"는 설계의 타당성 방증 — 을 펴 보면 이렇다. 우리의 개념 모델 제2장은 사건을 "인생의 한 문장"으로 두고 6하 성분을 부여했는데, 이 선택이 서사·문법의 전통에만 기댄 것이 아니라는 뜻이다. 열 대응은 거의 1:1 이다:

구조적 유사는 하나 더 있다. Zachman 매트릭스 전체는 기업 하나의 기술이다 — 기업이 어느 셀에 등장하는 것이 아니라 매트릭스의 암묵적 주어다. 우리 모델에서 주어(나)가 성분 표에 있으면서도 "암묵 — 모든 기록은 한 사람에게 귀속"인 것과 같은 자리다.

대응보다 유익한 어긋남은 셋이다:

• 열의 평등 vs 시간의 특권. Zachman 은 열 사이에 순서가 없다고 규정한다. 우리는 반대로 '언제'를 특권화했다 — 여정이 1차 렌즈이고, 시제를 '지금' 선에서 파생하며(원칙 2), 날짜 유무가 렌즈 노출을 가른다. 기업은 시간 밖에서도 기술될 수 있지만 삶은 시간 그 자체이기 때문이다. 이 어긋남은 우리 모델이 정적 기술이 아니라 서사 로그라는 정체성을 보여 준다.
• 완전 기술 vs 빈 성분 1급. Zachman 의 이상은 셀이 채워진 완전한 기술이다. 우리는 날짜 미정도 1급 기록이고(원칙 4), 빈 성분은 결핍이 아니라 인터뷰를 부르는 진입점(제8장)이다.
• 행 = 별도 모델 vs 렌즈 = 투영. Zachman 의 행마다 별도의 표현물이 만들어진다. 우리 렌즈는 데이터를 소유하지 않는 필터+투영이고(원칙 1·7), 어디서 편집하든 같은 객체다. 관점의 수만큼 산출물이 늘어나는 구조를 우리는 의도적으로 피했다.

생각할 거리

1. 우리에게 '행'이 필요한가. 렌즈(제5장)는 열(성분) 축을 따라 열리는 문이고, Zachman 의 행 — 청중별 표현 — 에 해당하는 축은 우리 다섯 문법(제9장)에 없다. 그런데 같은 사건이 사건 시트·인터뷰 카드·책자 원고에서 다르게 표현되는 것은 사실상 행이다. 책자(산출)와 Publication(원칙 9)을 "청중 관점의 행"으로 재해석하면 무엇이 정리되고 무엇이 무너지는가.
2. 온톨로지와 방법론의 결합도. Zachman 은 틀과 절차를 분리했고, 그 공백에서 별도 방법론들이 자랐다. 우리는 개념 모델(온톨로지)과 인터뷰 엔진(방법론, 제8장)을 처음부터 짝으로 설계했다 — 빈 구간이 질문을 부른다는 결합. 이 결합이 강점인지, 아니면 질문 풀이 커질수록(액션1 Question 풀 확장) 엔진을 모델에서 떼어 내야 할 속박인지.
3. 열마다 기본 모델 하나. Zachman 의 규율 — 각 열은 자기만의 단순한 기본 모델을 갖는다 — 을 우리 승격 계획에 적용해 볼 것. 어떻게(how)→task 분해, 왜(why)→목표 연계가 예고돼 있는데, 승격 시 각 성분의 "기본 모델"이 하나로 단순하게 유지되는지가 확장 가드레일 일곱 질문(원칙 10)에 추가할 만한 여덟째 물음이다.
4. 36셀의 늪. Zachman 을 문자 그대로 좇은 EA 프로젝트들은 셀 채우기 자체가 목적이 되는 문서화의 늪으로 악명이 높았다 — 굿하트의 법칙이 말하는 측정의 함정과 같은 구조다. 우리도 "성분 충전율" 같은 지표를 만들고 싶은 유혹이 올 것이다. 빈 성분을 채움의 대상이 아니라 인터뷰 진입점으로만 다루는 절제가 지켜지는지, 겹 검토 UX(액션3)류의 기능 추가 때마다 재확인할 것.
5. 재귀 적용. Zachman 틀은 기업 전체에도, 사업부 하나에도 재귀적으로 적용된다. 우리의 시대(index)·프로젝트·사건 위계에서 6하는 사건에만 붙는다 — 프로젝트에 자기 6하를 주지 않은 결정(성분은 문장 안, 참조는 문장 사이 — 원칙 3)이 재귀 대신 위계를 택한 것임을 의식하고, 프로젝트 롤업(등장인물 목록 등 파생)이 그 공백을 충분히 메우는지 지켜볼 것.

더 찾아보기

• J. A. Zachman, "A Framework for Information Systems Architecture", IBM Systems Journal, vol. 26, no. 3, 1987 — 원전. 3열 시절이지만 문제의식(복잡한 시스템 = 여러 관점의 여러 표현물)이 가장 선명하다.
• J. F. Sowa & J. A. Zachman, "Extending and Formalizing the Framework for Information Systems Architecture", IBM Systems Journal, vol. 31, 1992 — 6열 완성판.
• 공식 사이트: zachman.com — 현행 판의 매트릭스 도판과 "ontology, not a methodology" 논지.
• 검색: Zachman Framework ontology · "Zachman Framework" rules · Zachman FEAF DoDAF 영향
• 같은 장의 이웃: 드라마티즘 펜타드(수사학판) · 격문법 / 의미역(언어학판) · 사건 중심 온톨로지(사건을 1급으로 두는 지식표현판). 분류축이라는 관점에서는 파셋 분류가 도서관학의 사촌이다.