C4 모델

C4 모델은 소프트웨어 시스템의 정적 구조를 여러 추상화 수준에서 표현하기 위한 소프트웨어 아키텍처 시각화 접근법이다. 이름은 핵심 다이어그램인 시스템 컨텍스트(System Context), 컨테이너(Container), 컴포넌트(Component), 코드(Code)의 머리글자에서 유래한다. 각 다이어그램은 동일한 시스템을 서로 다른 확대 수준에서 보여 주며, 독자는 전체 환경에서 시작해 실행 단위, 내부 구성 요소, 구현 세부사항으로 이동할 수 있다.

C4 모델은 특정 그래픽 표기법이나 도구를 규정하지 않는다. 대신 소프트웨어 시스템, 컨테이너, 컴포넌트, 코드 요소라는 공통 추상화와 이들 사이의 계층 관계를 정의한다. 이에 따라 UML, 일반적인 상자와 화살표 표기, 모델링 도구, 코드 기반 다이어그램 도구 등을 사용해 C4 관점을 표현할 수 있다.

C4 모델은 아키텍처 스타일이나 개발 프로세스를 규정하는 방법론이 아니다. 모놀리식 시스템과 분산 시스템을 비롯한 여러 구조를 기술할 수 있으며, 다이어그램의 네 수준을 설계 단계의 순서나 팀별 책임으로 해석할 필요도 없다. 핵심 목적은 계획 중이거나 이미 구현된 소프트웨어 구조를 이해관계자에게 적절한 상세도로 전달하는 데 있다.

역사

C4 모델은 영국의 소프트웨어 아키텍트 사이먼 브라운(Simon Brown)이 개발하였다. 브라운의 설명에 따르면, 그 기원은 2000년대 중반 소프트웨어 아키텍처 교육 과정에서 참가자들이 작성한 다이어그램의 의미와 추상화 수준이 서로 달라 의사소통이 어려웠던 경험에 있다. 그는 UML 대신 여러 확대 수준의 블록 다이어그램을 사용해 시스템과 외부 환경, 애플리케이션과 데이터 저장소, 애플리케이션 내부 구조를 차례로 표현하는 방식을 교육에 도입하였다.

공식 역사 자료는 C4 모델의 뿌리를 대략 2006년부터 2009년 사이로 설명한다. 시스템, 컨테이너, 컴포넌트, 클래스라는 네 수준은 2010년 무렵 명명되었으며, C4라는 이름은 2011년 자료에서 확인된다. 초기의 네 번째 C는 클래스(Classes)를 뜻했으나, 객체 지향 언어 이외의 구현 방식도 포괄하기 위해 2015년부터 2018년 사이에 코드(Code)로 바뀌었다.

C4 모델은 UML과 필립 크루첸(Philippe Kruchten)의 4+1 아키텍처 뷰 모델에서 영향을 받았으나, UML의 축약판이나 4+1 모델의 직접적인 구현으로 정의되지는 않는다. 브라운은 C4 모델을 소프트웨어 개발자가 구조를 설명하고 코드와 아키텍처 설명 사이의 간격을 줄이기 위한 단순화된 접근법으로 설명한다.

핵심 추상화

C4 모델은 표기법보다 추상화를 먼저 정한다. 기본 구조는 하나의 소프트웨어 시스템이 하나 이상의 컨테이너로 구성되고, 각 컨테이너가 하나 이상의 컴포넌트를 포함하며, 각 컴포넌트가 코드 요소로 구현되는 계층이다. 사람은 이 계층의 구성 요소는 아니지만 소프트웨어 시스템을 사용하거나 상호작용하는 행위자로 모델링된다.

flowchart TD
    P[사람]
    S[소프트웨어 시스템]
    C[컨테이너]
    M[컴포넌트]
    K[코드 요소]

    P -->|사용하거나 상호작용함| S
    S -->|하나 이상으로 구성됨| C
    C -->|하나 이상을 포함함| M
    M -->|하나 이상으로 구현됨| K

소프트웨어 시스템

소프트웨어 시스템은 C4 모델에서 가장 높은 추상화 수준이다. 사람이 직접 사용하거나 다른 시스템이 이용하는 방식으로 가치를 제공하는 소프트웨어를 가리킨다. 모델링 대상 자체뿐 아니라 대상이 의존하거나 대상에 의존하는 외부 소프트웨어 시스템도 이 추상화로 표현할 수 있다.

소프트웨어 시스템의 경계는 조직마다 다르게 정해질 수 있다. 공식 문서는 하나의 개발 팀이 구축하고 소유하며 내부 구현을 변경할 수 있는 범위를 실용적인 판단 기준으로 제시한다. 다만 제품 도메인, 바운디드 컨텍스트, 비즈니스 역량, 팀 조직 단위가 자동으로 소프트웨어 시스템에 해당하는 것은 아니다. 이러한 개념이 실제 배포·소유·변경 경계와 어떻게 대응하는지를 별도로 판단해야 한다.

컨테이너

C4 모델의 컨테이너는 Docker나 Kubernetes의 컨테이너만을 뜻하지 않는다. 애플리케이션이 실행되거나 데이터가 저장되는 런타임 경계를 뜻하며, 서버 측 웹 애플리케이션, 브라우저에서 실행되는 단일 페이지 애플리케이션, 모바일 앱, 배치 프로세스, 서버리스 함수, 데이터베이스 스키마, 객체 저장소 등이 컨테이너가 될 수 있다.

컨테이너는 물리적 배포 위치와 구분된다. 하나의 애플리케이션이 개발 환경에서는 다른 애플리케이션과 같은 서버에서 실행되고 운영 환경에서는 독립 서버에 배포되더라도 C4 컨테이너로서의 정체성은 유지될 수 있다. 실제 서버, 가상 머신, 클라우드 실행 환경, Docker 컨테이너 등은 배포 다이어그램에서 별도의 배포 노드로 표현한다.

하나의 웹 제품도 실행 경계에 따라 여러 컨테이너로 나뉠 수 있다. 서버가 주로 HTML을 생성하는 전통적인 서버 렌더링 애플리케이션은 하나의 컨테이너로 표현할 수 있다. 반면 브라우저에서 독립적으로 실행되는 대규모 단일 페이지 애플리케이션과 원격 API 서버는 서로 다른 프로세스 공간에서 통신하므로 별도 컨테이너로 표현할 수 있다.

컴포넌트

컴포넌트는 명확한 인터페이스 뒤에 캡슐화된 관련 기능의 묶음이다. 객체 지향 언어에서는 여러 클래스와 인터페이스의 집합, 절차적 언어에서는 관련 소스 파일의 집합, 함수형 언어에서는 함수와 타입을 묶은 모듈 등이 컴포넌트에 대응할 수 있다.

C4 모델에서 컴포넌트는 원칙적으로 독립 배포 단위가 아니다. 같은 컨테이너에 속한 컴포넌트는 동일한 프로세스 공간에서 실행되며, 컨테이너가 배포 단위가 된다. 패키지, 네임스페이스, JAR 파일, DLL, 디렉터리 같은 코드 조직 단위가 컴포넌트와 일대일로 대응할 수는 있지만 반드시 그래야 하는 것은 아니다.

코드

코드 수준은 컴포넌트가 실제로 어떻게 구현되는지를 나타낸다. 클래스, 인터페이스, 함수, 객체, 모듈, 데이터베이스 테이블 등의 관계를 UML 클래스 다이어그램, 개체-관계 다이어그램 또는 이에 준하는 표기법으로 표현할 수 있다.

코드 다이어그램은 네 수준 가운데 가장 선택적인 관점이다. 구현 변경에 따라 빠르게 낡을 수 있고 IDE나 정적 분석 도구에서 필요할 때 생성할 수 있으므로, 공식 자료는 중요하거나 복잡한 컴포넌트에 한해 사용하고 가능하면 자동 생성할 것을 권고한다.

핵심 다이어그램

C4 모델의 네 핵심 다이어그램은 동일한 구조 모델을 서로 다른 범위와 상세도로 보여 준다. 이 계층은 지도 서비스에서 넓은 지역에서 개별 건물로 확대하는 방식에 비유된다. 상위 수준은 기술에 익숙하지 않은 독자도 이해할 수 있는 환경과 경계를 보여 주고, 하위 수준으로 갈수록 구현 책임과 기술 선택을 자세히 나타낸다.

네 수준을 모두 작성해야 하는 것은 아니다. 공식 문서는 대부분의 개발 팀에서 시스템 컨텍스트 다이어그램과 컨테이너 다이어그램만으로도 핵심 구조를 전달할 수 있다고 설명한다. 컴포넌트와 코드 다이어그램은 추가 정보가 실제로 의사소통에 기여할 때 선택적으로 사용한다.

시스템 컨텍스트 다이어그램

시스템 컨텍스트 다이어그램은 모델링 대상 소프트웨어 시스템을 중심에 두고, 이를 사용하는 사람과 직접 상호작용하는 외부 소프트웨어 시스템을 나타낸다. 시스템의 세부 기술이나 내부 구조보다 책임 범위, 사용자, 외부 의존 관계를 보여 주는 데 초점을 둔다.

이 다이어그램의 범위는 하나의 소프트웨어 시스템이다. 대상 시스템의 내부 컨테이너는 나타내지 않으며, 외부 시스템도 대상과 직접 관계가 있는 경우를 중심으로 포함한다. 기술 및 비기술 이해관계자가 함께 볼 수 있는 가장 넓은 관점으로 사용된다.

컨테이너 다이어그램

컨테이너 다이어그램은 대상 소프트웨어 시스템의 경계 안으로 확대하여 내부 애플리케이션과 데이터 저장소를 나타낸다. 각 컨테이너의 책임, 주요 기술 선택, 컨테이너 사이의 통신 방식, 외부 사람 및 시스템과의 연결을 표현한다.

이 다이어그램은 소프트웨어의 고수준 실행 구조와 책임 분배를 보여 준다. 다만 서버 수, 복제, 장애 조치, 로드 밸런서와 같은 환경별 배포 토폴로지는 일반적으로 포함하지 않는다. 이러한 정보는 배포 환경마다 별도의 배포 다이어그램으로 표현한다.

컴포넌트 다이어그램

컴포넌트 다이어그램은 하나의 컨테이너를 확대해 그 내부의 주요 컴포넌트와 책임, 기술 또는 구현 세부사항, 상호작용을 나타낸다. 같은 소프트웨어 시스템의 다른 컨테이너나 외부 사람·시스템이 해당 컴포넌트와 직접 연결되는 경우 보조 요소로 포함할 수 있다.

컴포넌트 경계는 코드베이스의 실제 구조와 대응해야 한다. 그러나 모든 클래스나 패키지를 그대로 표시하면 코드 수준의 세부사항이 섞여 다이어그램의 추상화가 무너질 수 있다. 장기간 유지되는 문서에서는 코드 분석을 통해 자동으로 생성하거나, 구조적으로 중요한 일부 컨테이너에만 작성하는 방식이 사용된다.

코드 다이어그램

코드 다이어그램은 하나의 컴포넌트를 확대해 구현 요소와 관계를 나타낸다. UML 클래스 다이어그램이나 개체-관계 다이어그램처럼 기존 표기법을 사용할 수 있다. 모든 속성과 메서드를 표시하기보다 설명하려는 구조에 필요한 정보만 남길 수 있다.

코드 다이어그램은 C4 모델이 독자적인 코드 표기법을 제공한다는 뜻이 아니다. C4는 이 수준에서 사용할 수 있는 기존 코드·데이터 모델링 표기법을 하나의 확대 단계로 배치한다.

보조 다이어그램

C4 모델은 네 핵심 정적 구조 다이어그램 외에 시스템 랜드스케이프, 동적, 배포 다이어그램을 보조 관점으로 정의한다.

시스템 랜드스케이프 다이어그램

시스템 랜드스케이프 다이어그램은 특정 소프트웨어 시스템 하나에 초점을 맞추지 않고, 선택한 조직 범위 안의 사람과 여러 소프트웨어 시스템 및 그 관계를 나타낸다. 시스템 컨텍스트 다이어그램에서 중심 시스템을 제거하고 범위를 조직이나 포트폴리오로 확대한 관점에 가깝다.

이 다이어그램은 개별 시스템의 C4 다이어그램 집합으로 진입하는 상위 지도 역할을 할 수 있다. 시스템 수가 많은 조직에서는 시스템 소유권과 주요 의존 관계를 조망하는 데 사용된다.

동적 다이어그램

동적 다이어그램은 정적 모델에 정의된 소프트웨어 시스템, 컨테이너 또는 컴포넌트가 런타임에 어떻게 협력하는지를 나타낸다. UML 커뮤니케이션 다이어그램과 유사하게 자유로운 배치와 번호가 붙은 상호작용을 사용할 수 있으며, 시퀀스 다이어그램 형태로 표현할 수도 있다.

동적 다이어그램은 모든 실행 흐름을 기록하는 용도가 아니라, 여러 요소가 복잡하게 상호작용하는 중요 기능이나 반복 패턴을 설명하는 데 사용된다. 하나의 다이어그램 안에서 서로 다른 추상화 수준을 무분별하게 섞으면 관계의 의미가 불명확해질 수 있으므로 범위를 명시해야 한다.

배포 다이어그램

배포 다이어그램은 정적 모델의 소프트웨어 시스템 또는 컨테이너 인스턴스가 특정 환경의 인프라에 배치되는 방식을 나타낸다. 물리 서버, 가상 머신, IaaS·PaaS 서비스, Docker 컨테이너, 애플리케이션 서버, 데이터베이스 서버 등은 배포 노드로 표현할 수 있으며, 배포 노드는 중첩될 수 있다.

DNS, 로드 밸런서, 방화벽처럼 소프트웨어 실행과 통신을 지원하지만 C4 컨테이너에 해당하지 않는 요소는 인프라 노드로 나타낼 수 있다. 개발, 시험, 스테이징, 운영 환경의 토폴로지가 다르면 환경별로 별도의 배포 다이어그램을 작성한다.

표기 원칙

C4 모델은 표기법 독립적이지만, 표기법을 사용하지 않는 것은 아니다. 도형, 색상, 선, 화살표가 어떤 의미인지 독자가 알 수 있도록 각 다이어그램이 독립적으로 이해 가능한 수준의 설명을 포함해야 한다.

공식 표기 지침은 다음 정보를 명시하도록 제안한다.

• 다이어그램의 종류와 범위를 나타내는 제목
• 도형, 색상, 테두리, 선, 화살표 등의 의미를 설명하는 범례
• 각 요소의 이름, 요소 유형, 간단한 책임 설명
• 컨테이너와 컴포넌트의 주요 기술
• 관계의 방향과 의도를 나타내는 구체적인 라벨
• 컨테이너 간 관계에 사용되는 프로토콜이나 통신 기술
• 독자가 모를 수 있는 약어와 코드명의 설명

관계선은 일반적으로 단방향으로 표현한다. 화살표는 의존 방향이나 데이터 흐름 중 하나를 나타낼 수 있으며, 어느 방식을 선택하더라도 라벨의 문장과 화살표 방향이 일치해야 한다. 사용한다와 같은 포괄적인 표현보다 HTTPS로 주문 정보를 조회한다, 고객 변경 이벤트를 발행한다처럼 관계의 목적과 수단을 구체화하는 방식이 권장된다.

색상과 도형에는 C4가 정한 고정 의미가 없다. 예제에서 흔히 사용되는 파란색과 회색도 표준 색상이 아니다. 색상만으로 의미를 구분하면 흑백 출력이나 색각 이상 환경에서 정보가 손실될 수 있으므로, 텍스트와 범례를 함께 사용해야 한다.

모델 경계와 분류

C4 모델을 적용할 때는 요소의 제품명이나 기술명보다 실행, 소유, 배포, 변경 경계를 기준으로 추상화를 판단한다. 같은 기술도 상황에 따라 서로 다른 수준에 놓일 수 있다.

예를 들어 관리형 데이터베이스 서비스 전체를 외부 소프트웨어 시스템으로 볼 수도 있지만, 팀이 소유하고 변경하는 특정 데이터베이스 스키마는 대상 시스템 내부의 컨테이너로 표현할 수 있다. 실제 데이터베이스 서버나 클라우드 서비스 인스턴스는 배포 다이어그램의 배포 노드가 될 수 있다. 이 구분은 논리적 구조와 물리적 배치를 분리한다.

마이크로서비스 역시 이름만으로 추상화 수준이 정해지지 않는다. 하나의 팀이 하나의 소프트웨어 시스템 안에서 여러 서비스를 운영한다면 각 서비스는 하나 이상의 컨테이너로 모델링할 수 있다. 서비스별로 독립된 팀이 소유하고 별도의 시스템 경계를 가진다면 각 서비스를 소프트웨어 시스템으로 승격해 표현할 수 있다. 공식 자료는 서비스의 크기보다 소유권과 시스템 경계를 판단 기준으로 제시한다.

메시지 기반 구조에서는 메시지 브로커 제품 전체보다 실제 결합 지점인 큐와 토픽을 컨테이너로 나타낼 수 있다. 단순한 점대점 메시징에서는 큐를 별도 요소로 표시하지 않고 관계 라벨에 경유지를 기록하는 방식도 가능하다. 어떤 표현을 택하든 생산자, 소비자, 메시지 채널과 소유권의 관계가 드러나야 한다.

도구와 문서화 방식

C4 모델은 도구 독립적이다. 초기 설계나 협업 세션에서는 화이트보드와 종이를 사용할 수 있으며, 장기간 유지할 문서에서는 범용 다이어그램 도구, 모델링 도구, 코드 기반 다이어그램 도구를 사용할 수 있다.

범용 다이어그램 도구는 개별 그림을 직접 편집한다. 진입 장벽이 낮지만, 같은 요소를 여러 그림에 복사하면 이름과 관계를 일관되게 갱신하기 어렵고 구조적 검증이나 질의가 제한될 수 있다. 모델링 도구는 요소와 관계를 하나의 비시각적 모델로 정의한 뒤, 필요한 부분 집합을 여러 다이어그램으로 렌더링한다. 이 방식에서는 하나의 요소를 여러 관점에서 재사용하고 모델을 검색하거나 다른 형식으로 내보낼 수 있다.

Structurizr는 C4 모델의 창시자가 만든 모델링 도구와 관련 도구 집합으로, 공식 문서는 이를 C4 모델의 참조 구현으로 설명한다. Structurizr DSL을 사용하면 요소, 관계, 관점을 텍스트로 정의하고 버전 관리 시스템에서 변경 내역을 관리할 수 있다. 다만 C4 모델이 Structurizr 사용을 요구하는 것은 아니며, 모델의 추상화와 관계를 보존할 수 있다면 다른 도구나 표기법을 사용할 수 있다.

다이어그램의 최신성은 추상화 수준에 따라 다르다. 시스템 컨텍스트와 컨테이너 구조는 비교적 천천히 변하는 경우가 많지만, 컴포넌트와 코드 구조는 구현 변경에 따라 빠르게 달라질 수 있다. 공식 FAQ는 시스템 카탈로그, 원격 측정 데이터, 정적 코드 분석, 인프라 코드 등을 활용해 각 관점을 자동 생성하는 방법을 예로 든다.

다른 아키텍처 표현 체계와의 관계

UML

C4 모델은 UML과 배타적인 관계가 아니다. C4의 예제는 주로 단순한 상자와 선을 사용하지만, UML 패키지, 컴포넌트, 스테레오타입 등을 이용해 시스템 컨텍스트, 컨테이너, 컴포넌트 관점을 표현할 수 있다. 코드 수준에서는 UML 클래스 다이어그램이 직접 사용될 수 있다.

두 접근법의 초점은 다르다. UML은 다양한 구조와 행위 모델을 위한 광범위한 표기 체계를 제공하며, C4는 소프트웨어 구조를 전달하기 위한 소수의 계층적 추상화와 관점에 초점을 맞춘다. 상태, 타이밍, 상세 상호작용처럼 C4 핵심 관점이 다루지 않는 내용은 UML 다이어그램으로 보완할 수 있다.

4+1 아키텍처 뷰 모델

C4 모델은 4+1 아키텍처 뷰 모델의 영향을 받았다. 그러나 C4의 네 C와 4+1의 네 관점을 일대일로 대응시키는 체계는 아니다. C4의 네 수준은 주로 정적 구조를 서로 다른 확대 수준에서 표현하며, 동적 다이어그램과 배포 다이어그램이 실행 및 물리 관점을 보완한다.

arc42

arc42는 아키텍처 문서의 전체 구성을 제공하는 템플릿이며, C4는 주로 구조 다이어그램을 제공한다. 두 체계는 함께 사용할 수 있다. C4 공식 FAQ는 arc42의 컨텍스트와 범위에 시스템 컨텍스트 다이어그램을, 빌딩 블록 뷰의 여러 수준에 컨테이너·컴포넌트·코드 다이어그램을 대응시키는 예를 제시한다.

arc42 유지관리자들은 C4가 구조 전달에는 유용하지만 품질 요구사항, 횡단 관심사, 위험 등 arc42 문서의 일부 항목을 포함하지 않는다고 설명한다. 따라서 C4 다이어그램 집합만으로 모든 아키텍처 지식이 기록된다고 간주하기보다는, 필요한 경우 품질 속성, 제약, 결정 근거, 운영 정보 등의 문서와 결합한다.

적용 범위

C4 모델은 새 시스템의 사전 설계와 기존 코드베이스의 사후 문서화에 모두 사용할 수 있다. 아키텍처 검토, 신규 구성원 온보딩, 시스템 경계 설명, 위협 모델링의 기초 자료, 운영 및 지원 조직과의 의사소통에도 활용될 수 있다.

C4 모델은 특정 아키텍처 스타일을 전제하지 않는다. 모놀리스, 마이크로서비스, 계층형 아키텍처, 포트와 어댑터, 서버리스, 온프레미스 및 클라우드 배포 등 서로 다른 구조에 적용할 수 있다. 다만 표현 대상은 주로 조직이 직접 구축하고 내부 구조를 통제하는 소프트웨어 시스템이다.

공식 FAQ는 임베디드 시스템과 펌웨어, 또는 SAP·Salesforce처럼 제품 자체를 개발하기보다 설정과 확장에 크게 의존하는 솔루션은 C4의 전체 추상화 계층에 상대적으로 덜 맞을 수 있다고 설명한다. 이 경우에도 시스템 컨텍스트와 컨테이너 수준은 환경과 주요 실행 단위를 설명하는 데 사용할 수 있다.

한계와 주의점

C4 모델의 중심은 소프트웨어 시스템의 정적 구조다. 동적 및 배포 다이어그램을 보조 관점으로 제공하지만, 비즈니스 프로세스, 워크플로, 상태 머신, 도메인 모델, 상세 데이터 모델, 품질 요구사항, 아키텍처 결정의 근거를 포괄하는 완전한 문서 체계는 아니다. 이러한 정보는 UML, BPMN, 개체-관계 모델, 아키텍처 결정 기록, arc42 등의 별도 기법으로 보완할 수 있다.

네 수준은 설계 절차가 아니다. 시스템 컨텍스트를 비즈니스 분석가가, 컨테이너를 아키텍트가, 컴포넌트와 코드를 개발자가 각각 소유해야 한다는 역할 분담도 내포하지 않는다. 다이어그램은 이해관계자의 질문과 시스템의 복잡도에 따라 필요한 수준만 선택한다.

규모가 큰 시스템에서 모든 요소를 한 다이어그램에 배치하면 선이 겹치고 인지 부하가 증가한다. 공식 FAQ는 하나의 거대한 그림 대신 업무 영역, 기능 집합, 바운디드 컨텍스트, 사용 사례 등 명확한 초점을 가진 여러 다이어그램으로 나누되, 각 그림이 같은 추상화 수준의 서로 다른 부분을 설명하도록 제안한다.

C4의 용어는 의도적으로 작고 고정된 추상화 집합을 제공하지만, 실제 조직의 용어 및 기술 구조와 정확히 맞지 않을 수 있다. 공식 문서는 팀이 용어를 바꾸거나 필요한 추상화 수준을 추가할 수 있다고 인정하면서도, 각 용어를 명확히 정의하지 않으면 임의적인 상자와 선으로 되돌아갈 수 있다고 지적한다.

컴포넌트와 코드 관점은 유지 비용이 높을 수 있다. 코드 구조와 다이어그램의 불일치를 줄이려면 중요한 부분만 문서화하거나 코드 분석을 통한 자동 생성을 사용할 수 있다. 자동 생성만으로는 요소의 책임, 시스템 경계, 사용자 관점과 같은 의미 정보가 충분히 도출되지 않을 수 있으므로 생성 결과의 범위와 목적을 명시해야 한다.

같이 보기

• 소프트웨어 아키텍처
• 소프트웨어 아키텍처 문서화
• UML
• 4+1 아키텍처 뷰 모델
• arc42
• 아키텍처 결정 기록
• 다이어그램 코드화
• Structurizr
• 시스템 컨텍스트 다이어그램
• 배포 다이어그램

참고 자료

• Brown, Simon (2026), The C4 Model: Visualizing Software Architecture, O’Reilly Media.
• Brown, Simon (2018), “The C4 Model for Software Architecture”, InfoQ, 25 June 2018.
• Brown, Simon, “The C4 model for visualising software architecture”, C4 model 공식 웹사이트: Introduction, History, Abstractions, Diagrams, Notation, Tooling 및 FAQ.
• Structurizr Documentation, “Structurizr”, “Why as code?”, “Structurizr DSL”.
• arc42, “Question B-17: What about arc42 and C4?”.
• Rowse, Poppy; Shepherd, Chris (2022), “Building Infrastructure Platforms”, MartinFowler.com.