아키텍트-방법론자: TOGAF와 변경 관리

이 기사는 아키텍트-방법론자가 TOGAF Phase H(객체 관리), 조직 변경 관리(의미 작업) 및 CI/CD와 Jira의 자동화의 합성을 통해 전략 아키텍처와 구현 간 격차를 어떻게 좁히는지 설명합니다. 기술 예제와 구현 원칙이 제공됩니다.

By Sudonull Editorial Team • Published 2026-04-09 • Updated 2026-04-09

아키텍트-메소도로지스트: TOGAF, 변화 관리, 프로세스 자동화로 전략과 코드 사이의 간극을 메우다

기업 아키텍처는 종종 파워포인트 슬라이드 모음에 그치곤 합니다. 이는 설계가 부실해서가 아니라, 설계와 구현 사이에 관리되고 측정 가능하며 역할 기반으로 자동화된 연결 고리가 없기 때문입니다. 이러한 간극으로 인해 ArchiMate 타깃 다이어그램은 개발팀의 의사결정에 영향을 미치지 못하고, 원칙들이 기본적으로 위반되며, 매 릴리즈마다 기술 부채가 선형적으로 증가합니다. 해결책은 새로운 방법론이 아닙니다. 바로 세 가지 요소의 통합입니다: 엔지니어링 객체 관리(TOGAF ADM Phase H), 의미의 행동적 정렬(조직 변화 관리), 그리고 CI/CD, Jira, 저장소에서의 자동화를 통한 운영적 고착화입니다. 아키텍트-메소도로지스트는 조직도상의 직책이 아니라, 이들 계층을 통합하는 기능입니다.

왜 아키텍처가 ‘떠다니는’가: 발견과 제공 사이의 간극 진단

일반적인 IT 프로세스에서는 기업 아키텍트(EA)가 타깃 아키텍처, 원칙, 로드맵을 정의하지만, 작업 단위의 의사결정에는 참여하지 않습니다. 솔루션 아키텍트(SolA)는 특정 작업에 대한 솔루션을 설계하면서 마감일과 팀의 현재 역량에 집중하지만, 전략적 아티팩트로부터 직접적인 피드백을 받지 못합니다. 결과적으로 구현된 시스템은 전략적 모델에도, 전술적 모델에도 맞지 않게 됩니다.

이는 사람 문제라기보다 시스템 거버넌스의 결함입니다. 핵심 질문에 대한 명확한 답이 부족하다는 형태로 나타납니다:

아키텍처 백로그는 어떻게 Jira의 작업으로 변환되어 파이프라인에서 검증될까요?
누가, 어떤 기준으로 아키텍처 원칙을 벗어날지 결정하나요?
실제 아키텍처가 타깃과 얼마나 일치하는지 어떻게 측정하나요? 연 1회가 아니라 PR마다 말이죠?
각 아키텍처 아티팩트(예: ADR, 통합 설명, 암호화 선택)에 대한 책임은 어디에 문서화되나요?
한 서비스의 변경이 다른 서비스의 보안이나 데이터 원칙을 위반하지 않도록 어떻게 보장하나요?

EA, SolA, DevOps 팀 간의 공식화된 상호작용 프로세스가 없다면, 아키텍처는 도구가 아니라 은유가 되고 맙니다.

TOGAF Phase H: 객체 기반 아키텍처 관리를 위한 기초

TOGAF ADM의 마지막 단계인 Phase H(아키텍처 변화 관리)는 단순한 ‘문서 지원’이 아닙니다. 아키텍처 객체를 관리하기 위한 본격적인 엔지니어링 주기입니다. 여기서는 아티팩트가 어떻게 변경되는지, 누가 관여하는지, 어떤 변경은 승인이 필요한지, 어떤 변경은 저장소에 자동 반영될 수 있는지를 명확히 규정합니다.

Phase H의 실무 적용에서 중요한 요소들은 다음과 같습니다:

관리 객체: 아키텍처 원칙, 기술 선택 표준(예: “OLTP에는 PostgreSQL 15 이상만 사용”), 통합 스키마(OpenAPI, AsyncAPI), ADR 문서, 데이터 도메인 설명(DAMA-DMBOK 용어로).
분류 프로세스: 단순화(기존 아키텍처의 효율화), 점진적(새 구성 요소의 점진적 도입), 재아키텍처(전체 계층 교체)를 구분합니다. 각 유형마다 자체 승인 경로가 있으며, 자동 CI 체크부터 아키텍처 위원회 회의까지 다양합니다.
측정 지표: 완료된 ADR이 포함된 작업 비율, OpenAPI 사양에 자동으로 검증된 PR 비율, 승인되지 않은 기술 사용 요청의 거부 건수, SonarQube + 맞춤 규칙에 따른 아키텍처 부채 수준.

Phase H는 언어, 구조, 좌표를 제공합니다. 하지만 여전히 해결되지 않은 질문이 있습니다: 개발자가 워크플로우에 내장되지 않는다면 왜 ADR을 작성해야 할까요?

변화 관리: 인간 요인과 함께 일하기

조직 변화 관리(OCM)는 여기서 HR 교육이 아닙니다. 참가자들의 인식, 동기, 행동을 관리하는 기술적 분야입니다. 목표는 아키텍처 규칙 준수가 업무의 자연스러운 결과가 되도록 만드는 것입니다. 추가 부담이 아니라 말이죠.

이는 세 가지 수준으로 이루어집니다:

가치 중심의 커뮤니케이션: “ADR을 작성해야 해요” 대신 “ADR은 통합 충돌을 조기에 발견해 생산 환경에서 3일간의 디버깅을 피하게 해줍니다.”
작업 맥락에 맞는 교육: Jira 템플릿에 내장된 체크리스트, 새 서비스 생성 시 GitLab Wiki의 대화형 튜토리얼, 저장소에 있는 ADR 예시와 함께 “왜 이런 선택을 했는지” 설명.
책임을 통한 참여: 리뷰 워크플로우에 ‘아키텍트’ 역할을 명시적으로 배정하고, 작업이 ‘설계 검토’ 단계로 넘어갈 때 자동으로 담당자 목록에 추가하며, 각 역할의 아키텍처 의사결정 활동 보고서를 생성합니다.

OCM은 TOGAF를 대체하는 것이 아닙니다. 오히려 TOGAF를 적용 가능하게 만듭니다. OCM이 없으면 아키텍처 규칙은 권고에 그칩니다. OCM이 있으면 규칙은 운영 현실의 일부가 됩니다.

자동화: 객체와 의미 사이의 연결 고리

자동화는 단순한 편의가 아닙니다. 아키텍처 제약을 불가역적이고 측정 가능한 것으로 만드는 유일한 방법입니다. 핵심 원칙은 이렇습니다: CI/CD나 Jira에서 자동으로 검증할 수 없는 규칙은 작동하지 않습니다.

구현 사례:

# 파이프라인 시작 전 ADR 확인
if [ ! -f "docs/architecture/adr-$(echo $CI_COMMIT_TAG | cut -d'-' -f2).md" ]; then
  echo "ERROR: 태그 $CI_COMMIT_TAG에 대한 ADR이 없습니다"
  exit 1
fi

# Jira 워크플로우: 필드가 채워지기 전에는 ‘Dev 준비’ 단계로 넘어가지 않음:
# - ‘아키텍처 의사결정 기록 ID’
# - ‘데이터 도메인 소유자’
# - ‘보안 검토 상태’ = ‘승인됨’

# 자동 OpenAPI v3.1 검증: 내부 버전 관리 표준 준수 및 mandatory securitySchemes
import openapi_spec_validator
from openapi_spec_validator import validate_spec
spec = load_spec('openapi.yaml')
assert spec['info']['version'].startswith('v2.'), "API 버전은 반드시 v2.x여야 합니다"
assert 'securitySchemes' in spec.get('components', {}), "securitySchemes가 없습니다"

이런 자동화는 인지적 부담을 줄이고, 단일 진실의 원천을 만들며, 책임 문화를 조성합니다. 개발자는 ‘규칙을 어긴다’는 선택을 하지 않습니다. 그냥 검사를 무효화하고 그 이유를 명시적으로 설명하지 않는 한, 규칙을 어길 수 없게 되는 것이죠.

무엇이 중요한가

발견과 제공 사이의 간극은 능력 부족이 아니라 시스템적 문제입니다: EA, SolA, DevOps 간의 공식화된 상호작용 프로세스가 부족하기 때문입니다.
TOGAF Phase H는 아키텍처 객체를 관리하기 위한 엔지니어링 프레임워크를 제공합니다: 원칙, 표준, 아티팩트, 지표.
조직 변화 관리는 사람들이 가치 중심의 커뮤니케이션, 맥락에 맞는 교육, 역할 기반 참여를 통해 이러한 객체를 수용하도록 보장합니다.
CI/CD, Jira, 저장소에서의 자동화는 선택 사항이 아닙니다. IT 거버넌스의 필수 요소입니다: 오직 이렇게 해야만 일상 운영에서 규칙 준수를 보장할 수 있습니다.
아키텍트-메소도로지스트는 직책이 아니라 기능입니다: TOGAF, ArchiMate 같은 객체 모델과 OCM 같은 행동적 실천을 모두 숙달하고, 이를 기술적 구현을 통해 연결하는 방법을 알고 있습니다.

IT 거버넌스는 위원회를 꾸리는 것부터 시작하는 것이 아니라, 단 하나의 자동화된 규칙을 시행하는 것부터 시작합니다. 예를 들어, CI에서 ADR을 검증하는 것처럼 말이죠. 나머지는 그 실천을 확대하는 것입니다: 더 많은 검사 추가, 역할 확대, 품질과 보안 지표 통합. 핵심은 아키텍처를 단순한 발표 자료로 남겨두는 것이 아니라, 코드, 파이프라인, 워크플로우에 녹아들게 하는 것입니다. 그래야만 아키텍처가 슬라이드가 아니라 실제로 거버넌스를 수행하게 됩니다.

— Editorial Team