ArchiMate(엔터프라이즈 아키텍처 모델링 언어)

1. 개요

가. 정의

ArchiMate는 The Open Group이 관리하는 개방형 표준으로, 엔터프라이즈 아키텍처(EA)의 비즈니스·응용·기술 영역과 그 사이의 관계를 단일한 시각 언어(visual modeling language)로 일관되게 표현·분석·소통하기 위한 모델링 표기법이다. 특정 조직의 전략·업무·시스템·인프라를 한 벌의 공통 어휘(요소와 관계)로 그려, 서로 다른 이해관계자가 같은 그림을 보고 같은 의미를 읽도록 하는 것을 목표로 한다.

ArchiMate의 성격을 정확히 이해하려면 "방법론이 아니라 언어"라는 점을 먼저 분명히 해야 한다. TOGAF의 ADM이 "아키텍처를 어떤 절차로 만들 것인가"를 규정하는 방법론이라면, ArchiMate는 그 절차가 만들어 내는 산출물을 "어떤 기호로 그릴 것인가"를 규정하는 표기법이다. 즉 TOGAF가 설계 과정이라면 ArchiMate는 그 결과를 담는 도면 규약이며, 두 표준이 모두 The Open Group 소관이라는 점에서 상호 보완을 전제로 설계되었다.

핵심 특징은 세 가지다. 첫째, 계층(layer)과 측면(aspect)이라는 두 축으로 엔터프라이즈를 분해하여, 어떤 아키텍처 요소든 "어느 계층에 속하는가 × 능동 구조·행위·수동 구조 중 무엇인가"로 분류한다. 둘째, 서비스 지향(service orientation) 사상을 언어 자체에 내장하여 상위 계층이 하위 계층의 '서비스'를 소비하는 관계로 전 계층을 일관되게 연결한다. 셋째, 뷰포인트(viewpoint) 메커니즘으로 동일한 모델에서 이해관계자별 관심사만 추려 보여주는 선택적 가시화를 지원한다.

ArchiMate는 UML·BPMN 같은 특정 영역 전용 언어와 달리 "계층을 가로질러(cross-layer) 전사를 한 장에 잇는다"는 데 고유한 가치가 있다. UML은 소프트웨어 내부를, BPMN은 업무 프로세스를 정밀하게 그리지만, "이 업무 서비스가 어떤 응용 컴포넌트로 실현되고 그 컴포넌트가 어떤 서버·네트워크 위에서 동작하는가"를 하나의 연결된 모델로 보여주지는 못한다. ArchiMate는 바로 이 '계층 간 추적성'을 핵심 역량으로 삼는다.

나. 등장 배경과 필요성

ArchiMate는 2002~2004년 네덜란드의 Telematica Instituut 주도 연구 프로젝트에서 출발하여 2008년 The Open Group에 이관되었고, 이후 2.0(2012)·3.0(2016)·3.1(2019)·3.2(2022)로 발전해 왔다. 이 표준이 필요했던 근본 이유는 EA 실무가 오랫동안 "계층마다 서로 다른 그림 언어"로 쪼개져 있었다는 데 있다.

첫째 동인은 표기법의 파편화로 인한 소통 단절이다. 과거 EA 산출물은 업무는 플로차트, 응용은 UML, 데이터는 ERD, 인프라는 네트워크 다이어그램으로 제각기 그려졌다. 각 그림은 정밀했지만 서로 연결되지 않아, "이 업무가 바뀌면 어떤 시스템과 서버가 영향받는가"라는 전사 수준 질문에 답할 수 없었다. ArchiMate는 모든 계층을 하나의 표기 체계로 묶어 이 단절을 메우려 했다.

둘째 동인은 비즈니스–IT 정합(alignment)의 가시화다. 경영진은 전략·역량·가치흐름을 말하고 엔지니어는 서버·미들웨어를 말하는데, 그 사이를 잇는 '응용 서비스·업무 서비스'라는 중간 다리가 명시되지 않으면 둘은 서로 다른 세계를 상상한다. ArchiMate의 서비스 계층화는 "전략→업무→응용→기술"이 서비스 소비 관계로 수직 연결되도록 강제하여 정합을 구조적으로 드러낸다.

셋째 동인은 변화 영향 분석(impact analysis)과 의사결정 근거의 확보다. 디지털 전환으로 시스템 상호의존이 폭증하면서, 특정 애플리케이션을 교체하거나 규제가 바뀔 때 그 파급을 수작업으로 추적하기가 사실상 불가능해졌다. 요소 간 관계가 형식 규칙으로 정의된 ArchiMate 모델은 도구를 통해 "이 노드에 연결된 상·하류 요소"를 질의할 수 있어, 영향 분석과 투자 의사결정의 근거 자료가 된다.

넷째 동인은 국제 표준으로서의 상호운용성이다. 조직마다 사내 방언으로 아키텍처를 그리면 기업 간·부서 간 산출물 교환과 도구 호환이 어렵다. ArchiMate는 공개 표준·교환 포맷(ArchiMate Model Exchange File Format)을 제공하여 특정 벤더 도구에 종속되지 않고 모델을 이동·통합할 수 있게 한다. 실제로 국내외 공공·금융기관의 EA 사업에서 TOGAF ADM과 ArchiMate를 함께 채택해 절차와 표기를 동시에 표준화하는 사례가 늘고 있다.

2. ArchiMate의 핵심 구조 — 계층과 측면

ArchiMate의 뼈대는 "계층(layer) × 측면(aspect)"의 2차원 프레임워크다. 세로축인 계층은 추상화의 높이(전략·업무·응용·기술)를, 가로축인 측면은 요소의 본성(무엇이 행동하는가·무엇이 일어나는가·무엇이 다뤄지는가)을 나타낸다. 이 직교 분해 덕분에 어떤 아키텍처 요소든 단 하나의 칸으로 분류되며, 중복과 누락이 억제된다.

graph TD
    AM["ArchiMate 프레임워크(계층 x 측면)"]
    AM --> L["세로축: 계층(추상화 높이)"]
    AM --> A["가로축: 측면(요소의 본성)"]
    L --> L0["전략(Strategy): 자원·역량·가치흐름"]
    L --> L1["비즈니스(Business): 업무 행위자·서비스·프로세스"]
    L --> L2["응용(Application): 컴포넌트·응용 서비스·데이터"]
    L --> L3["기술(Technology): 노드·시스템SW·인프라 서비스"]
    L --> L4["물리(Physical): 설비·장비·자재"]
    L --> L5["구현·이행(Implementation & Migration): 작업패키지·플래토"]
    A --> A1["능동 구조(Active Structure): 행동 주체"]
    A --> A2["행위(Behavior): 수행되는 활동·서비스"]
    A --> A3["수동 구조(Passive Structure): 다뤄지는 객체"]
    A --> A4["동기(Motivation): 이해관계자·목표·요구·원칙"]

가. 계층(Layer) — 전략부터 기술까지의 수직 분해

ArchiMate 3.x의 핵심 계층은 비즈니스·응용·기술의 세 층이며, 여기에 상위의 전략(Strategy) 계층과, 전 계층을 가로지르는 동기(Motivation)·구현 및 이행(Implementation & Migration) 확장이 더해진다. 비즈니스 계층은 조직이 고객에게 제공하는 가치와 업무 서비스·프로세스·역할을 다루고, 응용 계층은 그 업무를 지원하는 소프트웨어 컴포넌트와 응용 서비스를 다루며, 기술 계층은 응용을 구동하는 하드웨어·시스템 소프트웨어·통신 인프라를 다룬다.

계층을 나누는 근본 이유는 "추상화 수준이 다른 관심사를 섞지 않기 위함"이다. 가령 '보험금 청구 처리'라는 업무 서비스(비즈니스)와 그것을 실현하는 '청구관리시스템'(응용), 다시 그 시스템이 올라가는 '컨테이너 오케스트레이션 클러스터'(기술)는 변하는 속도와 책임 주체가 전혀 다르다. 계층을 분리하면 한 계층의 변화를 다른 계층과 독립적으로 관리할 수 있고, 계층 사이는 오직 '서비스' 인터페이스로만 느슨하게 결합된다. 이것이 ArchiMate가 선언하는 서비스 지향의 실천적 함의다.

3.0에서 추가된 전략 계층은 EA가 단순한 시스템 지도에서 벗어나 경영 전략과 직접 연결되도록 돕는다. 자원(Resource)·역량(Capability)·가치흐름(Course of Action, Value Stream) 같은 요소로 "우리는 어떤 역량을 확보해 어떤 경로로 가치를 전달할 것인가"를 그리고, 그 역량이 어떤 업무·응용·기술로 실현되는지를 하위 계층과 잇는다. 예컨대 한 통신사가 '초개인화 마케팅 역량'을 전략 요소로 두면, 그것이 'CDP 구축'이라는 업무 기능과 '고객데이터플랫폼'이라는 응용 컴포넌트, 'GPU 분석 클러스터'라는 기술 노드로 실현되는 흐름을 한 장에 담을 수 있다.

나. 측면(Aspect) — 능동 구조·행위·수동 구조

가로축인 측면은 문법의 품사에 비유할 수 있다. 능동 구조(active structure)는 행동의 '주어'에 해당하는 요소(업무 역할, 응용 컴포넌트, 기술 노드)이고, 행위(behavior)는 '동사'에 해당하는 요소(업무 프로세스, 응용 기능, 서비스)이며, 수동 구조(passive structure)는 '목적어'에 해당하는 요소(업무 객체, 데이터 객체, 아티팩트)다. 여기에 전 계층을 관통하는 동기(motivation) 측면이 더해져 이해관계자·동인·목표·요구·제약·원칙을 다룬다.

이 품사적 분해가 유용한 이유는 "누가(능동) 무엇을(수동) 어떻게 다루는가(행위)"라는 서술 구조를 모든 계층에서 동일하게 반복하기 때문이다. 비즈니스 계층의 '청구심사자(능동)가 청구서(수동)를 심사한다(행위)'는 구조는 응용 계층의 '청구심사컴포넌트(능동)가 청구데이터(수동)를 검증한다(행위)'로 그대로 대응되어, 계층 간 매핑과 추적이 자연스럽게 이뤄진다. 동기 측면은 "왜 이 구조가 존재하는가"를 별도 차원으로 명시하여, 규제·목표·원칙이 특정 업무·응용 요소로 어떻게 실현되는지를 연결한다.

측면 구분이 실무에서 특히 가치를 갖는 지점은 규제·컴플라이언스 추적이다. 예컨대 「개인정보보호법」이나 금융권 전자금융감독규정 같은 외부 제약을 동기 측면의 '드라이버(driver)'와 '요구(requirement)'로 모델링하면, 그 요구가 어떤 업무 프로세스(행위)와 응용 컴포넌트(능동 구조), 어떤 데이터 객체(수동 구조)로 실현되는지를 관계로 추적할 수 있다. 규제가 개정될 때 영향받는 시스템을 모델 질의로 식별할 수 있으므로, 측면 축은 단순한 분류를 넘어 거버넌스·감사 대응의 실질적 근거가 된다.

3. 요소와 관계 — 서비스 지향과 계층 연결

ArchiMate 모델은 결국 요소(element)를 관계(relationship)로 잇는 그래프다. 요소가 어휘라면 관계는 문법이며, 관계의 종류와 허용 규칙이 엄격히 정의되어 있다는 점이 자유로운 '네모와 화살표' 그림과 결정적으로 다르다.

graph TB
    subgraph BIZ["비즈니스 계층"]
        BS["업무 서비스: 보험금 청구 처리"]
        BP["업무 프로세스: 청구 접수-심사-지급"]
        BR["업무 역할: 청구심사자"]
    end
    subgraph APP["응용 계층"]
        AS["응용 서비스: 청구 심사 API"]
        AC["응용 컴포넌트: 청구관리시스템"]
        DO["데이터 객체: 청구 데이터"]
    end
    subgraph TECH["기술 계층"]
        TS["기술 서비스: 컨테이너 런타임"]
        NODE["노드: K8s 클러스터"]
    end
    BR -->|"assignment: 수행"| BP
    BP -->|"realization: 실현"| BS
    AS -->|"serving: 지원"| BP
    AC -->|"realization: 실현"| AS
    AC -->|"access: 읽기쓰기"| DO
    TS -->|"serving: 구동"| AC
    NODE -->|"realization: 제공"| TS

가. 관계의 유형 — 구조적·의존·동적·기타

ArchiMate의 관계는 성격에 따라 네 묶음으로 나뉜다. 구조적 관계(structural)는 요소의 정적 구성을 나타내며 합성(composition)·집합(aggregation)·할당(assignment)·실현(realization)이 여기에 든다. 의존 관계(dependency)는 요소가 서로에게 기대는 방식을 나타내며 제공(serving)·접근(access)·영향(influence)·연관(association)이 든다. 동적 관계(dynamic)는 시간 흐름을 나타내는 트리거(triggering)·흐름(flow)이고, 기타로 특수화(specialization)와 교차점(junction)이 있다.

관계가 형식적으로 정의되어 있다는 점은 실무에서 큰 함의를 가진다. 예컨대 '실현(realization)'은 "보다 추상적인 요소를 보다 구체적인 요소가 구현한다"는 의미로만 쓰이도록 규정되어 있어, 업무 서비스를 업무 프로세스가 실현하고 응용 서비스를 응용 컴포넌트가 실현하는 식의 일관된 수직 추적이 가능하다. 반대로 '제공(serving)'은 한 요소가 다른 요소에게 기능을 제공하는 수평·수직 의존을 뜻하여, 응용 서비스가 업무 프로세스를 '지원'하는 계층 간 연결의 주된 통로가 된다. 이렇게 관계의 의미가 고정되어 있어야 도구가 모델을 질의·검증할 수 있다.

나. 서비스 지향과 계층 연결의 논리

ArchiMate의 설계 사상 중 가장 중요한 것이 "각 계층은 하위 계층이 노출하는 서비스를 통해서만 결합된다"는 원칙이다. 응용 계층의 내부 컴포넌트가 아무리 복잡해도 비즈니스 계층은 그것이 노출하는 '응용 서비스'만 소비하며, 기술 계층 역시 '기술 서비스'로만 응용을 떠받친다. 이 서비스 경계가 계층 간 결합도를 낮추고, 한 계층 내부를 교체해도 노출 서비스만 동일하면 상위 계층이 영향받지 않게 한다.

이 원리는 마이크로서비스·API 경제 시대에 특히 잘 들어맞는다. 가령 한 은행이 레거시 메인프레임 여신 시스템을 클라우드 네이티브로 재구축할 때, 노출하는 '여신 심사 서비스'의 계약(인터페이스)만 유지하면 그 서비스를 소비하는 업무 프로세스와 채널 애플리케이션은 변경 없이 유지된다. ArchiMate 모델은 이 '유지되어야 할 서비스 경계'를 명시적으로 드러내어, 현대화 범위와 영향 범위를 시각적으로 구획해 준다.

4. 뷰포인트(Viewpoint) — 이해관계자별 선택적 가시화

전사 모델은 요소가 수백~수천 개에 이르러 그대로 보여주면 누구도 읽지 못한다. ArchiMate는 이를 뷰포인트 메커니즘으로 해결한다. 뷰포인트란 "특정 이해관계자의 특정 관심사에 맞춰 전체 모델에서 보여줄 요소·관계의 종류를 규정한 렌즈"이고, 그 렌즈로 실제 그려낸 그림이 뷰(view)다. 이는 아키텍처 기술의 국제표준인 ISO/IEC/IEEE 42010의 '이해관계자–관심사–뷰포인트–뷰' 개념과 정합한다.

예를 들어 경영진에게는 전략·역량과 그것을 실현하는 핵심 업무 서비스만 담은 '역량 맵 뷰'를, 애플리케이션 아키텍트에게는 응용 컴포넌트와 그 사이 협력만 담은 '응용 협력 뷰'를, 인프라 담당자에게는 노드·네트워크·시스템 소프트웨어 중심의 '인프라 뷰'를 제공한다. 동일한 단일 모델에서 서로 다른 렌즈로 추출되므로, 경영진의 역량 요소와 인프라의 서버가 같은 모델 안에서 추적 가능하게 연결되어 있다는 점이 수작업 파워포인트 그림과 근본적으로 다르다.

표준은 기본(standard) 뷰포인트들을 예시로 제공하지만, 조직은 자신의 관심사에 맞춰 커스텀 뷰포인트를 정의할 수 있다. 중요한 실무 원칙은 "뷰는 많아도 모델은 하나"라는 것이다. 뷰를 늘려도 그 밑에 깔린 요소·관계의 단일 저장소(repository)가 하나로 유지되어야 정합성과 영향 분석 능력이 보존된다. 뷰마다 별도의 요소를 중복 생성하면 ArchiMate의 핵심 가치가 무너진다.

5. 비교 — 인접 표기·프레임워크와의 관계

ArchiMate의 위치는 인접한 언어·프레임워크와의 비교로 분명해진다. 핵심은 "ArchiMate는 계층을 가로지르는 전사 수준 표기이고, UML·BPMN·ERD는 특정 계층 내부를 정밀하게 그리는 전용 표기이며, TOGAF·Zachman은 표기가 아니라 절차·분류 체계"라는 역할 분담이다.

구분	성격	주 대상 범위	ArchiMate와의 관계
ArchiMate	모델링 언어(표기)	전략·업무·응용·기술 전 계층	본 주제 — 계층 간 연결에 특화
TOGAF ADM	방법론(절차)	EA 개발 전 과정	상호 보완(절차↔표기), 동일 소관
Zachman	분류 체계(온톨로지)	산출물 분류 좌표	보완 — '무엇을' 분류 vs '어떻게 그릴지'
UML	모델링 언어	소프트웨어 내부 설계	응용 계층 상세는 UML로 보완
BPMN	모델링 언어	업무 프로세스 상세	비즈니스 프로세스 상세는 BPMN로 보완

이 비교에서 차이가 생기는 근본 이유는 "해결하려는 문제의 높이"가 다르기 때문이다. UML·BPMN은 한 계층 내부의 정밀성을 추구하므로 표현력이 깊은 대신 전사 조망이 어렵고, ArchiMate는 전 계층 조망을 추구하므로 계층 내부의 세부 묘사는 상대적으로 얕다. 실무적 함의는 명확하다. 둘은 경쟁이 아니라 역할 분담이며, ArchiMate로 전사 지형을 그린 뒤 특정 응용의 내부는 UML 클래스·시퀀스로, 특정 업무의 상세 흐름은 BPMN으로 '확대'하는 계층적 문서화가 권장된다. 마찬가지로 ArchiMate(표기)·TOGAF(절차)·Zachman(분류)은 서로 다른 질문("어떻게 그릴까·어떤 절차로 만들까·무엇을 분류할까")에 답하므로 함께 쓸 때 시너지가 난다.

6. 심화 — 최신 동향과 실무 적용

ArchiMate의 최신 버전은 2022년 발표된 3.2다. 3.2는 가치흐름(value stream)·역량 요소를 전략 계층에서 더 정교하게 다루도록 개선하고, 방향성 있는 연관(directed association) 표기를 명확히 하는 등 표현력을 보완했다. 그 이전 3.0(2016)이 전략·물리 요소를 도입한 것이 가장 큰 구조적 확장이었고, 3.1(2019)·3.2(2022)는 이를 다듬는 성격이 강하다. 버전 세부는 The Open Group 명세를 근거로 확인하는 것이 정확하며, 세부 표기 규칙은 개정될 수 있으므로 단정보다는 "현행 명세 확인"을 전제로 다루는 것이 안전하다.

도구 생태계도 성숙해 있다. 오픈소스 Archi를 비롯해 상용 EA 도구들이 ArchiMate를 지원하며, 표준 교환 포맷(Model Exchange File Format)으로 도구 간 모델 이동이 가능하다. 최근에는 아키텍처 모델을 코드처럼 관리(Architecture-as-Code)하려는 흐름 속에서, 텍스트 기반 DSL로 ArchiMate 모델을 기술하고 형상관리(Git)와 CI에 연동해 변경 이력을 추적하는 방식이 실무에서 확산되고 있다. 이는 아키텍처 산출물을 '정적인 보고 문서'가 아니라 '살아 있는 저장소'로 운영하려는 지향과 맞닿는다.

실무 적용 관점에서 ArchiMate는 특히 디지털 전환·클라우드 마이그레이션·레거시 현대화 사업에서 영향 분석 도구로 유용하다. 예컨대 어떤 공공기관이 온프레미스 시스템 30여 종을 클라우드로 이전할 때, ArchiMate 모델에서 각 응용 컴포넌트가 실현하는 업무 서비스와 소비하는 기술 서비스를 추적하면 "먼저 옮겨도 되는 독립 시스템"과 "강하게 결합되어 함께 옮겨야 하는 묶음"을 식별할 수 있다. 또한 구현·이행 계층의 플래토(plateau)·작업패키지 요소로 현재(As-Is)에서 목표(To-Be)로 가는 전환 단계를 모델링하여 로드맵과 아키텍처를 하나로 연결할 수 있다. 다만 모든 조직이 전 계층을 정밀하게 모델링할 필요는 없으며, 과도한 모델링은 비용만 키우므로 목적(영향 분석·소통·로드맵)에 맞는 범위로 적정화하는 것이 현실적이다.

7. 고려사항 및 시사점 (기술사 관점)

적용 전략 — 목적 주도의 적정 모델링: ArchiMate는 "전사를 빠짐없이 그린다"는 완전성보다 "어떤 의사결정을 지원할 것인가"라는 목적에서 출발해야 한다. 영향 분석·현대화 범위 식별·비즈니스-IT 정합 등 목적을 먼저 정하고 그에 필요한 계층·뷰포인트만 선택적으로 모델링하는 것이 과투자를 막는 핵심이다.
트레이드오프 — 전사 조망 대 계층 내 정밀성: 계층을 가로지르는 조망을 얻는 대가로 각 계층 내부 묘사는 얕아진다. 따라서 ArchiMate 단독으로 완결하려 하기보다 UML·BPMN·ERD 등 전용 표기로 상세를 보완하는 계층적 문서화 전략이 바람직하다.
연계 기술 — 방법론·분류·거버넌스와의 결합: 표기법인 ArchiMate는 TOGAF ADM(절차), Zachman(분류), EA 거버넌스(원칙·심의), 형상관리·모델 저장소(단일 진실 원천)와 결합해야 실효가 있다. 특히 단일 모델 저장소를 유지해야 뷰 증가에도 정합성과 영향 분석 능력이 보존된다.
전망 — Architecture-as-Code와 지식그래프로의 확장: 모델을 텍스트·코드로 다루어 CI/형상관리에 연동하고, 요소-관계 그래프를 조직 지식그래프·데이터 카탈로그와 연계하려는 흐름이 관찰된다. 이는 아키텍처를 살아 있는 자산으로 운영하려는 방향이나, 표준화되지 않은 시도이므로 방향성 수준으로 이해하는 것이 적절하다.
리스크 — 보고용 그림으로의 형식화 경계: ArchiMate 모델이 현실과 유리된 사문서가 되면 가치가 사라진다. 운영 실체와의 정합을 주기적으로 검증하고, 아키텍처를 실제 의사결정(투자·현대화·규제 대응)에 사용하는 거버넌스 루프를 확보해야 한다.
조직 역량 — 표기 숙련과 이해관계자 참여: 관계의 의미를 정확히 지키지 않으면 모델이 '예쁜 네모 그림'으로 전락한다. 아키텍트의 표기 숙련, 이해관계자별 뷰포인트 합의, 그리고 모델을 읽고 의사결정에 쓰는 조직 문화가 갖춰져야 ArchiMate가 비로소 작동한다.

참고자료

The Open Group, "ArchiMate 3.2 Specification" — https://pubs.opengroup.org/architecture/archimate3-doc/
The Open Group, ArchiMate Overview — https://www.opengroup.org/archimate-forum/archimate-overview
Archi (오픈소스 ArchiMate 모델링 도구) — https://www.archimatetool.com/

한 줄 요약: ArchiMate는 The Open Group의 개방형 표준으로, 전략·업무·응용·기술 전 계층을 '계층 × 측면'과 형식 정의된 요소·관계로 일관되게 그려 계층 간 추적과 영향 분석을 가능케 하는 EA 모델링 언어이며, 절차(TOGAF)·분류(Zachman)·전용 표기(UML·BPMN)와 결합해 쓰일 때 진가를 발휘한다.