114. TOGAF ADM (Architecture Development Method)

⚠️ 이 문서는 조직의 비즈니스와 IT 시스템을 새롭게 뜯어고칠 때, 백지상태에서 출발하여 "어떤 순서로 비즈니스, 데이터, 애플리케이션, 인프라를 설계하고 어떻게 이사(Migration)할 것인가?"에 대한 실천적 행동 지침을 제시하는 **글로벌 EA(엔터프라이즈 아키텍처) 표준 프레임워크인 TOGAF의 심장부, 'ADM 9단계(피자 조각 사이클)'**를 다룹니다.

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

  1. 본질: 단순히 아키텍처 '문서'의 목록을 나열한 것이 아니라, 그 문서를 '만드는 순서와 방법(Step-by-step Process)'을 둥근 원형의 끊임없는 순환 사이클(Iterative Loop)로 정의한 절차적 매뉴얼이다.
  2. 가치: "서버부터 덜컥 사지 마라!" 항상 경영진의 비전과 비즈니스 프로세스를 먼저 정의하고(위에서 아래로, Top-down), 그에 맞는 데이터와 앱을 그린 뒤 마지막에 인프라(클라우드 등)를 결정하게 강제하여 비즈니스와 IT의 엇박자를 완벽하게 막아준다.
  3. 기술 체계: 준비(예비) 단계를 거쳐 **비전(A) $\rightarrow$ 비즈니스(B) $\rightarrow$ 정보시스템(C) $\rightarrow$ 기술(D)**의 설계 파트를 끝내면, 갭 분석을 통한 해결책 및 마이그레이션(E, F) 일정을 짜고, 구축 과정을 감독(G)하며, 완료 후 새로운 변화(H)를 맞이하는 생명주기를 가진다.

Ⅰ. 아키텍처 설계의 뼈대: BDAT 순차 도출 (Phase B, C, D)

집을 지을 때 땅부터 파지 말고 가족의 라이프스타일(비즈니스)부터 그려라.

  1. Phase A (아키텍처 비전, Architecture Vision):
    • 스폰서(임원)에게 프로젝트 승인을 받아내는 단계다. "우리의 목표는 3년 내 클라우드 전면 전환으로 운영비 30% 감축"이라는 명확한 핵심 목표와 범위(Scope)를 정의하고 착수(Kick-off)를 선언한다.
  2. Phase B (비즈니스 아키텍처, Business Architecture):
    • 기술 얘기는 꺼내지도 마라. 회사가 돈을 버는 과정(주문 $\rightarrow$ 생산 $\rightarrow$ 배송)과 조직도를 분석한다.
    • AS-IS(현재)의 병목을 찾아내고, TO-BE(미래)의 이상적인 비즈니스 프로세스(예: 모바일 주문 활성화)를 그린다.
  3. Phase C (정보 시스템 아키텍처, Information Systems Architecture):
    • 두 가지를 동시에 설계한다.
    • 데이터 (Data): 비즈니스를 굴리기 위해 어떤 정보(고객, 상품, 결제)가 필요한지 논리적/물리적 데이터 모델을 짠다.
    • 애플리케이션 (Application): 그 데이터를 처리하기 위해 어떤 소프트웨어(CRM 앱, ERP 앱)가 필요한지 시스템 연계도(인터페이스)를 그린다.
  4. Phase D (기술 아키텍처, Technology Architecture):
    • 앞서 그린 앱과 데이터를 구동하기 위해 필요한 하드웨어 및 인프라를 결정한다. "AWS 클라우드(IaaS)를 쓰고, 네트워크는 이렇게 쪼개고, 서버는 리눅스를 쓴다"를 최종 확정한다.

📢 섹션 요약 비유: 건물을 짓는 ADM 공법입니다. A(비전)에서 "아내와 아이 2명이 살 전원주택을 짓겠다"고 선언합니다. B(비즈니스)에서 "주말마다 거실에서 파티를 하겠다"는 생활 방식을 정합니다. C(정보 시스템)에서 그 생활을 위해 "거실 한가운데 커다란 싱크대와 100인치 TV를 달겠다"고 내부 도면을 그립니다. 마지막 D(기술) 단계에서 그 무거운 TV와 싱크대를 버틸 "튼튼한 H빔 철골과 220V 고전압 전선"을 뼈대로 심는, 철저한 위에서 아래로의 연쇄 설계법입니다.

Ⅱ. 이행과 마이그레이션 전략 (Phase E, F)

그린 도면(TO-BE)과 현재 집(AS-IS)의 차이를 메울 공사 일정을 짠다.

  1. Phase E (기회 및 솔루션, Opportunities & Solutions):
    • B, C, D 단계에서 그려진 TO-BE 아키텍처와 현재의 낡은 AS-IS 아키텍처를 겹쳐놓고 갭(Gap) 분석을 수행한다.
    • "낡은 서버 100대를 버리고 클라우드로 이관해야 하네? 이 갭을 메우기 위해 3개의 프로젝트(솔루션)를 띄워야겠다."
  2. Phase F (마이그레이션 계획, Migration Planning):
    • 도출된 여러 프로젝트를 한 번에 다 터뜨릴 수는 없으니 **우선순위(Priority)**와 전환 아키텍처(Transition Architecture) 로드맵을 짠다.
    • "올해 1분기에는 데이터 백업부터 옮기고, 2분기에 앱 서버 이관, 3분기에 낡은 서버 폐기" 식으로 비용과 리스크를 계산하여 완벽한 이사(Migration) 마스터플랜 스케줄을 확정한다.

📢 섹션 요약 비유: 도면을 완성한 후 현실적인 이사 계획을 세우는 단계입니다. E단계에서 현재 살고 있는 10평 낡은 빌라(AS-IS)와 새로 지을 50평 아파트(TO-BE) 사이의 격차(Gap)를 분석해 버릴 짐과 새로 살 가구(솔루션)를 파악합니다. F단계에서는 가구 배치와 이삿짐 트럭 부르는 날짜, 잠시 묵을 단기 월세방(전환 아키텍처) 일정까지 날짜별로 빼곡하게 적은 이사 마스터 스케줄(마이그레이션 계획)을 확정합니다.

Ⅲ. 구축 감시와 끝없는 순환 (Phase G, H)

설계자가 현장을 떠나면 엉뚱한 집이 지어진다. 끝은 또 다른 시작이다.

  1. Phase G (구현 거버넌스, Implementation Governance):
    • 외부 개발 업체(SI)가 코드를 짜기 시작했다. ADM은 여기서 손을 떼지 않는다.
    • 아키텍트(설계자)가 현장을 감시(거버넌스)하며 "야! 도면에는 MSA 통신망으로 그렸는데, 왜 데이터베이스를 직접 연결하는 스파게티 코드를 짜고 있어!"라며 규격 위반을 적발하고 강제로 바로잡는다.
  2. Phase H (아키텍처 변경 관리, Architecture Change Management):
    • 시스템이 성공적으로 오픈했다. 하지만 1년 뒤, 정부 규제가 바뀌어 "고객 인증 방식 전면 개편"이라는 엄청난 외부 충격이 떨어진다.
    • 이때 시스템을 주먹구구로 고치지 않고, 다시 처음(Phase A 비전 수립)으로 뱅글뱅글 돌아가(Iterative) 새로운 요구사항을 B, C, D 도면에 반영하고 시스템을 정교하게 진화시킨다.

📢 섹션 요약 비유: 도면과 스케줄이 나왔다고 끝이 아닙니다. G단계에서는 아키텍트가 안전모를 쓰고 매일 공사판에 출근해 시공사가 철근을 빼먹지 않는지 도면과 대조하며 호통을 칩니다(거버넌스). H단계에서는 완공 후 잘 살고 있다가 아이가 한 명 더 태어나는(환경 변화) 이벤트가 생기면, 즉시 처음 단계로 다시 돌아가 방을 하나 증축하는 도면을 새롭게 뽑아내는 영원한 수레바퀴의 순환입니다.