112. 자크만 프레임워크 (Zachman Framework)

⚠️ 이 문서는 "회사의 전산 시스템을 지을 때, 도대체 무슨 문서를 그려서 관리해야 하는가?"라는 인류의 오랜 질문에 대해, 1987년 존 자크만(John Zachman)이 건축과 비행기 제조 공학의 설계도를 본떠 제안한 **엔터프라이즈 아키텍처(EA)의 시초이자, 6가지 관점(행)과 6가지 질문(열)을 교차하여 36개의 매트릭스 빈칸을 채우도록 강제하는 '가장 완벽한 분류 체계'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 집을 지을 때 집주인(조감도), 건축가(도면), 시공업자(자재 목록)가 필요한 문서가 각각 다르듯, IT 시스템도 바라보는 사람의 '역할(행)'과 다루는 대상의 '주제(열, 5W1H)'에 따라 각기 다른 산출물을 체계적으로 매핑한 거대한 엑셀 표(Matrix)다.
  2. 가치: 특정 벤더(IBM, Oracle)나 방법론에 치우치지 않고, "우리 회사의 아키텍처 문서 목록에 구멍(누락)이 없는가?"를 점검할 수 있는 완벽한 주기율표이자 나침반 역할을 한다.
  3. 한계 체계: 36개의 칸을 모두 다른 산출물로 빈틈없이 채우는 것은 현실적으로 엄청난 돈과 시간이 드는 비현실적 작업이므로, 현대에는 이 표를 뼈대로만 삼고 구체적인 구축 방법론은 TOGAF(토가프) 등을 차용하는 것이 대세다.

Ⅰ. 건축학 개론을 IT로 가져오다

복잡한 비행기를 도면 없이 말로만 설명해서 지을 수는 없다.

  1. 존 자크만의 통찰:
    • 1980년대 메인프레임 시절, 컴퓨터 시스템이 점점 거대해지자 개발자들은 스파게티처럼 엉킨 시스템을 통제할 방법을 잃었다.
    • IBM에서 일하던 존 자크만은 건축이나 항공기 제조 산업이 그 복잡한 구조물을 '설계도 뭉치'로 완벽하게 관리하는 것을 보고, 이를 컴퓨터 시스템(엔터프라이즈) 설계에 그대로 베껴온다.
  2. 분류의 미학 (Taxonomy):
    • 자크만 프레임워크는 시스템을 만드는 '순서'나 '과정'을 설명하는 방법론(Methodology)이 아니다. 오직 "이러이러한 문서들이 반드시 있어야 한다"고 짚어주는 순수한 **분류 체계(Ontology)**다.

📢 섹션 요약 비유: 자크만 프레임워크는 요리를 직접 만드는 '레시피 순서(방법론)'가 아니라, 고급 레스토랑 주방에 벽면 전체를 차지하고 있는 '초대형 양념통 분류함(분류 체계)'입니다. 가로칸에는 소금/설탕 종류를, 세로칸에는 고운 가루/굵은 가루를 매핑해 놓고 "모든 빈칸에 해당하는 조미료를 100% 구비해 놓아라"라고 강제하는 절대적인 수납장입니다.

Ⅱ. 36개 매트릭스의 해부: 행(관점)과 열(질문)

아키텍처는 누가, 무엇을 묻느냐에 따라 대답(산출물)이 달라진다.

  1. 6개의 가로행 (관점, Perspectives):
    • 기획자 (Planner): 전체적인 스코프와 비전. (예: 사업 영역 목록)
    • 소유자 (Owner): 비즈니스 개념 모델. (예: 프로세스 모델, ERD 개념 모델)
    • 설계자 (Designer): 정보 시스템 모델. (예: 논리적 DB 스키마, 시스템 구성도)
    • 구축자 (Builder): 기술 물리 모델. (예: 물리적 DDL 쿼리, 하드웨어 사양서)
    • 구현자 (Implementer): 컴포넌트의 상세 구성. (예: 실제 소스 코드 파일)
    • 운영자 (Worker): 실제 돌아가는 시스템의 인스턴스.
  2. 6개의 세로열 (질문, Interrogatives - 5W1H):
    • What (데이터): 무엇을 처리하는가? (Data Architecture)
    • How (기능): 어떻게 일하는가? (Application/Process Architecture)
    • Where (네트워크): 어디서 하는가? (Technology/Infra Architecture)
    • Who (사람): 누가 하는가? (조직도, 역할 매핑)
    • When (시간): 언제 하는가? (배치 스케줄, 라이프사이클)
    • Why (동기): 왜 하는가? (비즈니스 목표, 전략)
  3. 매트릭스의 결합 (교차점의 산출물):
    • "설계자(행) × 데이터(열)"의 교차점에는 [논리적 ERD 다이어그램]이라는 산출물이 들어간다.
    • "소유자(행) × 사람(열)"의 교차점에는 [전사 부서 업무 분장표]가 들어간다.

📢 섹션 요약 비유: 집을 지을 때, '집주인(소유자)'이 궁금한 건 '어디(Where)'에 방이 있냐는 [평면도]이지, 그 방벽을 '어떻게(How)' 지탱하냐는 [철근 배근도]가 아닙니다. 반대로 '목수(구축자)'에게는 예쁜 조감도(소유자 관점)보다 센티미터가 적힌 도면(구축자 관점)이 필요합니다. 자크만은 이처럼 사람(행)마다 듣고 싶은 대답(열)이 다르니, 그 모든 36가지 대답 문서를 몽땅 준비하라고 뼈대를 잡아준 것입니다.

Ⅲ. 자크만 프레임워크의 한계와 위상

너무 완벽해서 오히려 독이 된 케이스다.

  1. 완벽주의의 함정:
    • 36개의 칸을 모두 다른 포맷의 문서로 완벽하게 꽉 채우는 것은 엄청난 시간(수개월~수년)과 돈을 요구한다.
    • 문서를 다 만들고 났더니 이미 비즈니스 트렌드가 바뀌어 문서가 무용지물이 되는(Time-to-Market 실패) 한계를 겪었다.
  2. 실행 방법의 부재:
    • 자크만 프레임워크는 "이 표를 채워라"라고만 했지, "이 표를 1번 칸부터 채울지 3번 칸부터 채울지(프로세스)"에 대한 방법론을 제공하지 않는다.
  3. 현대적 계승 (TOGAF 등):
    • 그래서 최근의 엔터프라이즈들은 자크만의 표를 36칸 100% 다 채우지 않고, 뼈대(개념)만 빌려온다.
    • 대신 "어떤 순서로 그릴 것인가"에 대한 훌륭한 방법론(ADM)을 탑재한 TOGAF 프레임워크를 주력으로 차용하여, 꼭 필요한 산출물(칸)만 선택적으로 그려 나가는 실용적인 하이브리드 노선을 취한다.

📢 섹션 요약 비유: 자크만의 36칸 양념장은 완벽하지만, 그걸 다 사서 채워 넣으려면 파산합니다. 그리고 이 수납장은 "이 양념들로 어떻게 김치찌개를 끓이는지(프로세스)" 레시피는 절대 안 알려줍니다. 그래서 사람들은 이 양념장 뼈대의 사상만 존경하고, 실제 요리는 백종원 레시피(TOGAF)를 참고하여 꼭 필요한 양념 10개만 사서 빠르게 끓여 먹는 현실적인 방식을 택하게 되었습니다.