arc42 vs C4 모델: 차이점과 함께 쓰는 방법

팀의 누군가가 아키텍처 문서에 arc42를 쓰자고 제안합니다. 다른 누군가는 우리 팀은 이미 C4를 쓰고 있다고 말합니다. 그 뒤에 이어지는 논의는 대개 둘 중 하나를 골라야 한다고 가정하는데, 가장 먼저 버려야 할 것이 바로 그 가정입니다.

arc42와 C4를 비교하는 것은 보고서의 목차와 그 안에 들어가는 차트를 비교하는 것과 비슷합니다. arc42는 템플릿입니다. 품질 목표부터 리스크까지, 아키텍처에 대해 무엇을 문서화해야 하는지 알려 주는 열두 개의 섹션입니다. C4는 모델이자 표기법입니다. 소프트웨어 시스템의 구조를 어떻게 그릴지 알려 주는 네 단계의 다이어그램입니다. 둘은 몇 군데에서 겹치고, 함께 쓰기에 잘 맞습니다. 이 가이드는 각각이 무엇을 다루는지, C4는 그리지 않지만 arc42가 요구하는 것은 무엇인지, C4가 arc42에 더해 주는 것은 무엇인지, 그리고 어떤 C4 다이어그램이 어디에 들어가는지 섹션별로 매핑한 표를 다룹니다.

한 줄 답변

arc42는 아키텍처 문서화를 위한 템플릿입니다. C4 모델은 소프트웨어 아키텍처 다이어그램을 그리는 방법입니다. 둘 다 쓰는 팀 대부분은 C4 다이어그램을 arc42 섹션 안에 넣습니다.

arc42 자체의 FAQ도 둘의 관계를 이렇게 설명합니다. "arc42와 C4는 어떤가요?"라는 질문에, C4 모델은 "arc42의 몇몇 섹션과 많은 유사점이 있지만, 특정 부분(예: 품질 요구사항, 횡단 관심사 개념, 리스크 및 그 밖의 몇 가지)은 빠져 있다"고 답합니다(arc42 FAQ, B-17). 같은 FAQ는 Simon Brown의 C4 모델을 arc42의 대안 중 하나로 꼽습니다(A-6). 다이어그램만 필요하다면 맞는 말이지만, 문서가 담는 나머지 모든 것이 필요하다면 오해를 부릅니다.

arc42의 열두 섹션

무언가를 매핑하기 전에, 섹션을 정확한 번호와 함께 눈앞에 두면 도움이 됩니다. 다음은 arc42 문서에 있는 것으로, 템플릿 버전 9.0입니다(다운로드 페이지에 따르면 2025년 7월).

arc42가 분명히 밝히는 것이 하나 더 있습니다. 모든 것을 채우지 않아도 된다는 것입니다. FAQ는 "어떤 부분이 필수인가?"에 "모든 것을 채우려 하지 마세요. 이해관계자에게 필요한 것만 문서화하세요"라고 답합니다. 여러분이 쓰는 모든 것은 "앞으로 유지보수 노력을 필요로 할 수 있기" 때문입니다(B-1). 이 조언은 아래에서 다룰 조합에서 중요합니다. 세 섹션에 좋은 C4 다이어그램이 들어간 간결한 arc42 문서가, 아무도 업데이트하지 않는 완전한 문서보다 낫습니다.

arc42는 다루지만 C4는 다루지 않는 것

C4는 구조를, 그리고 보조 다이어그램을 통해 런타임과 배포를 다룹니다. 아키텍처 중 상자가 아닌 부분에 대해서는 아무것도 말하지 않습니다. arc42의 용어로 보면, 다음 섹션들은 C4에 대응하는 것이 전혀 없습니다:

• 섹션 1, Introduction and Goals (소개와 목표). 시스템이 왜 존재하는지, 누가 관심을 갖는지, 그리고 이후의 모든 결정을 좌우하는 세 개에서 다섯 개의 품질 목표. C4 컨텍스트 다이어그램은 누가 시스템을 쓰는지 보여 줍니다. 하지만 "체크아웃은 2초 안에 완료되어야 한다"가 "관리자 UI가 예쁘다"보다 중요하다고 말해 주지는 못합니다.
• 섹션 2, Constraints (제약). "회사의 Kubernetes 플랫폼에서 실행해야 한다", "Java로 작성해야 한다", "데이터는 EU 밖으로 나갈 수 없다". 제약은 다이어그램이 보여 주기만 하는 선택의 이유를 설명합니다.
• 섹션 4, Solution Strategy (솔루션 전략). 몇 가지 근본적인 선택(모놀리스부터 시작, 원장에는 이벤트 소싱, 검색 엔진은 구매)을 한곳에 요약한 것.
• 섹션 8, Crosscutting Concepts (횡단 개념). 인증, 오류 처리, 로깅, 영속성 패턴, 국제화. 이것들은 모든 상자를 관통하므로, 어느 한 상자로는 보여 줄 수 없습니다.
• 섹션 10, Quality Requirements (품질 요구사항). 구체적인 품질 시나리오: 자극, 응답, 측정 기준.
• 섹션 11, Risks and Technical Debt (리스크와 기술 부채). 취약하다고 알고 있는 것, 그리고 미뤄 둔 것.
• 섹션 12, Glossary (용어집). 비즈니스에서 쓰는 단어를 한 번 정의해 둔 것.

이것들이 바로 arc42 FAQ가 C4에서 "특정 부분이 빠져 있다"고 할 때 가리키는 섹션입니다. 여러분의 아키텍처 문서가 C4 다이어그램뿐이라면, 새로 합류한 아키텍트나 감사인은 그것을 다 읽고 나서도 이런 질문을 품고 있을 것입니다.

C4가 arc42에 더해 주는 것

arc42는 의도적으로 표기법을 정하지 않습니다. 섹션 5는 "블랙박스와 화이트박스의 계층적 모음"을 요구하고, 섹션 3은 "시스템을 블랙박스로 보여 주는 모든 종류의 다이어그램"을 제안하며, 섹션 6은 번호 붙인 단계 목록부터 시퀀스 다이어그램, BPMN, 상태 머신까지 무엇이든 받아들입니다(섹션 5, 섹션 3, 섹션 6). 이런 유연성은 템플릿의 강점이지만, arc42 문서가 가장 제각각이 되는 지점이기도 합니다. 작성자마다 그리는 방식이 다르니까요.

C4는 그 빈틈을 두 가지로 채웁니다:

1. 일관된 확대 단계. arc42의 빌딩 블록 뷰에는 이미 레벨이 있습니다. 레벨 1은 "전체 시스템의 화이트박스 설명과 그 안에 포함된 모든 빌딩 블록의 블랙박스 설명"이고, 레벨 2는 "레벨 1의 일부 빌딩 블록을 확대"합니다(섹션 5). C4의 레벨은 그 확대 단계에 고정된 의미(시스템, 컨테이너, 컴포넌트, 코드)를 부여하므로, C4를 아는 독자는 레이블을 읽기 전에 무엇을 보고 있는지 압니다.
2. 작은 공통 어휘. 사람, 소프트웨어 시스템, 컨테이너, 컴포넌트, 관계. 각각 이름, 설명, 그리고 보통 기술을 가집니다. 팀 간에 다이어그램을 비교할 수 있게 하기에 충분한 표기법이면서, 아무도 교육받을 필요가 없을 만큼 작습니다.

실용적인 이점도 있습니다. C4 다이어그램을 드로잉 도구가 아니라 모델에서 만들면, 같은 요소가 섹션 3, 5, 6, 7에 같은 이름으로 나타납니다. arc42는 그것을 어떻게 달성할지에 대해 아무 의견이 없지만, 그것이야말로 섹션들이 서로 일치하게 만드는 요인입니다.

매핑 표: 어떤 C4 다이어그램이 arc42의 어느 섹션에 들어가는가

이 매핑은 저희가 arc42의 섹션 정의와 C4의 다이어그램 정의로부터 도출한 것입니다. arc42 FAQ는 조합 방식을 규정하기보다 커뮤니티 사례를 안내하며(예: bitsmuggler의 arc42 + C4 예제 리포지토리), 팀마다 마지막 열에 적은 세부 사항에서 방식이 다릅니다.

표에 없는 섹션(1, 2, 4, 8, 10, 11, 12)은 C4 다이어그램이 아니라 텍스트와 표입니다. 어느 방법의 공백도 아니며, 역할 분담일 뿐입니다.

실습 예제

다음은 저희 C4 모델 완벽 가이드의 이커머스 시스템에 둘을 조합했을 때의 모습입니다. React 싱글 페이지 앱, API 게이트웨이, 주문·상품·사용자를 위한 Go 서비스, PostgreSQL 데이터베이스, Kafka, 알림 서비스로 이루어져 있습니다. 완전한 문서가 아니라, C4 다이어그램을 배치한 간결한 arc42 골격입니다.

1. Introduction and Goals (소개와 목표)
   - 목적: 고객은 상품을 둘러보고 주문하며, 창고 직원은 재고를 관리한다
   - 품질 목표: (1) 결제가 p95 기준 2초 안에 완료된다
               (2) 결제 승인이 성공하지 않으면 어떤 주문도 확정되지 않는다
               (3) 기존 서비스를 바꾸지 않고 새 서비스를 추가할 수 있다

2. Constraints (제약)
   - 회사 Kubernetes 플랫폼에서 실행한다. 백엔드 서비스는 Go

3. Context and Scope (컨텍스트와 범위)
   - 비즈니스 컨텍스트: C4 System Context 다이어그램
     [Customer], [Warehouse Staff] -> [E-Commerce Platform]
     -> [Stripe], [FedEx API], [SendGrid]
   - 기술 컨텍스트: 상대 / 프로토콜 / 주고받는 데이터 표

4. Solution Strategy (솔루션 전략)
   - 서비스마다 데이터베이스. 알림은 Kafka를 통한 비동기 처리

5. Building Block View (빌딩 블록 뷰)
   - 레벨 1: C4 Container 다이어그램 (SPA, API Gateway, Order/Product/User
     서비스, PostgreSQL 데이터베이스 3개, Kafka, Notification Service)
   - 레벨 2: Order Service만의 C4 Component 다이어그램
     (Order Handler, Order Service, Order Repository, Payment Client,
     Inventory Client)

6. Runtime View (런타임 뷰)
   - "고객이 주문한다": C4 동적 다이어그램, 번호 붙은 10단계

7. Deployment View (배포 뷰)
   - 프로덕션: C4 배포 다이어그램
   - 스테이징: 프로덕션과의 차이점만

8. Crosscutting Concepts (횡단 개념)
   - 게이트웨이에서 인증. POST /orders에 멱등성 키.
     요청 ID가 포함된 구조화 로깅

9. Architecture Decisions (아키텍처 결정)
   - ADR-001 서비스마다 데이터베이스
   - ADR-002 동기 호출 대신 주문 이벤트에 Kafka 사용
   - ADR-003 주문을 기록하기 전에 결제 승인

10. Quality Requirements (품질 요구사항)
   - 시나리오: 세일 중 분당 결제 500건, p95 2초 미만

11. Risks and Technical Debt (리스크와 기술 부채)
   - 재고가 결제 전에 예약된다. 결제 실패 시 보상 처리는 아직 없다

12. Glossary (용어집)
   - 주문, 예약, 승인, 풀필먼트

다이어그램이 어디에 있는지 보세요. 섹션 3, 5, 6, 7입니다. 나머지는 모두 몇 줄의 텍스트입니다. 또 섹션 11의 리스크와 섹션 9의 ADR-003이 섹션 6의 동적 다이어그램이 보여 주는 것과 같은 것을 가리킨다는 점도 눈여겨보세요. 이런 상호 참조야말로 arc42와 C4를 결합한 문서가 제 몫을 하는 지점입니다. 다이어그램은 단계의 순서를 보여 주고, ADR은 그 이유를 말하며, 리스크는 아직 무엇이 잘못되어 있는지 말합니다.

동적 다이어그램 자체에 대해서는 C4 Dynamic 다이어그램 가이드가 바로 이 시나리오를 단계별로 살펴봅니다. 섹션 9에 대해서는 아키텍처 결정 기록 완벽 가이드가 arc42가 권장하는 형식과 색인을 유지하는 방법을 다룹니다.

arc42의 열두 섹션이 여러분 팀에 과하다고 느껴진다면, 저희의 소프트웨어 아키텍처 문서 템플릿이 같은 아이디어로 만든 더 짧은 Markdown 개요이며, arc42와 어떻게 대응되는지 설명하는 섹션도 들어 있습니다.

둘 다 최신으로 유지하기

arc42와 C4는 같은 실패 방식을 공유합니다. 둘 다 작성된 그날에는 훌륭합니다. arc42 자체의 FAQ도 여러분이 채우는 모든 섹션은 여러분이 떠안은 유지보수라고 경고합니다(B-1). 오래가는 습관 몇 가지:

• 가능하면 다이어그램을 문서 본문 밖에 두세요. 스크린샷을 붙여 넣는 대신 모델에서 생성한 다이어그램을 참조하거나 임베드하세요. 컨테이너 다이어그램 스크린샷은 컨테이너 이름이 바뀌는 날 낡아 버립니다. 모델에서 렌더링한 다이어그램은 모델이 낡은 만큼만 낡습니다.
• 빠르게 바뀌는 섹션은 코드 옆에 두세요. 섹션 5, 6, 9는 코드와 함께 바뀝니다. 섹션 1, 2, 10은 비즈니스와 함께 바뀝니다. 앞의 그룹을 리포지토리에 두면(arc42는 이를 위해 Markdown과 AsciiDoc 템플릿을 제공합니다) 풀 리퀘스트로 업데이트할 수 있습니다.
• ADR은 앞으로 써 나가고, 절대 수정하지 마세요. 대체된 결정에는 새 ADR을 씁니다. 섹션 9는 다시 쓴 이야기가 아니라 역사가 됩니다.
• 모든 섹션에 소유자와 검토 날짜를 정하세요. 소유자가 없는 문서는 아무도 업데이트하지 않는 문서입니다.
• 구조에 관한 섹션을 코드와 대조하세요. 섹션 3과 5는 코드에 존재하는 것을 기술하므로 자동으로 검사할 수 있습니다. 섹션 1, 8, 10은 그럴 수 없으며, 정해진 일정에 따라 사람이 검토해야 합니다.

마지막 항목이 archyl이 들어맞는 지점이며, 그것도 문제의 일부에 대해서만입니다. archyl이 보관하는 것은 C4 모델이지 arc42 문서가 아닙니다. AI 발견이 리포지토리에서 시스템, 컨테이너, 컴포넌트, 관계를 제안하면 여러분이 승인하고, ADR은 영향을 미치는 C4 요소에 연결되며, 드리프트 점수가 문서화된 요소가 여전히 코드에 존재하는지 검사합니다. 이것으로 다이어그램 중심의 섹션(3, 5, 6, 9)을 다룰 수 있습니다. 품질 목표, 횡단 개념, 리스크 목록은 써 주지 않으며, arc42 내보내기도 없습니다. 텍스트 섹션은 여러분의 arc42 문서에 남아 모델로 링크됩니다.

자주 묻는 질문

arc42가 C4보다 나은가요?

둘은 같은 일을 하지 않으므로 어느 쪽이 더 낫다고 할 수 없습니다. arc42는 목표, 제약, 구조, 런타임, 배포, 결정, 품질, 리스크를 다루는 문서화 템플릿입니다. C4는 구조를 일관되게 그리는 방법입니다. 완전한 아키텍처 문서가 필요하다면 arc42(또는 그와 비슷한 형태의 것)를 쓰세요. 일관된 다이어그램이 필요하다면 C4를 쓰세요. 둘 다 필요한 팀 대부분은 arc42 안에서 C4 다이어그램을 사용합니다.

arc42와 C4를 함께 쓸 수 있나요?

네, 흔한 방식입니다. arc42는 표기법을 정하지 않으므로 C4 다이어그램이 섹션에 바로 들어갑니다. 컨텍스트 다이어그램은 섹션 3에, 컨테이너와 컴포넌트 다이어그램은 섹션 5에, 동적 다이어그램은 섹션 6에, 배포 다이어그램은 섹션 7에 둡니다.

C4 컨테이너 다이어그램은 arc42의 어디에 들어가나요?

섹션 5, Building Block View의 레벨 1, 즉 전체 시스템의 화이트박스 뷰입니다. 컴포넌트 다이어그램은 필요한 컨테이너에 대해 레벨 2에 둡니다. 시스템이 모듈러 모놀리스라면 레벨 1 빌딩 블록이 컨테이너가 아니라 모듈일 수 있어 대응이 느슨해집니다.

arc42는 UML을 요구하나요?

아니요. arc42는 여러 섹션에서 표기법을 제안하지만(예를 들어 섹션 3은 기술 컨텍스트에 UML 배포 다이어그램을 언급합니다) 선택은 여러분에게 맡깁니다. C4, UML, 그리고 단순한 상자와 화살표 모두 arc42와 함께 쓰입니다.

arc42에서 ADR은 어디에 두나요?

섹션 9, Architecture Decisions입니다. arc42 자체가 중요한 결정마다 Michael Nygard의 구조로 ADR을 쓰라고 권장하며, 그 편이 더 읽기 좋다면 결정을 영향을 미치는 빌딩 블록 안에서 로컬로 문서화하는 것도 허용합니다.

arc42는 무료인가요?

네. 템플릿은 무료 오픈소스이며 CC BY-SA 4.0 라이선스이고, 열두 개 언어와 AsciiDoc, Markdown, Word, Confluence 등의 형식으로 제공됩니다(다운로드 페이지).

arc42 문서의 C4 부분을 코드와 일치하게 유지하고 싶으신가요? archyl을 무료로 사용해 보고 리포지토리에서 모델을 생성하세요. 더 읽어 보기: C4 모델이란? 완벽 가이드 | Architecture Decision Records: 완벽 가이드 | C4 Dynamic 다이어그램 가이드 | 소프트웨어 아키텍처 문서 템플릿.