C4 모델 예제: Stripe, Netflix, Uber, Revolut

찾아볼 수 있는 C4 모델 예제는 대부분 장난감 같은 시스템 하나입니다. 은행, 웹숍, 상자 세 개와 데이터베이스 하나로 이루어진 인터넷 뱅킹 앱. 표기법은 보여 줍니다. 하지만 정말 어려운 부분은 보여 주지 않습니다. 실제 시스템에 서비스가 수백 개 있을 때 무엇을 빼야 할지 결정하는 일 말입니다.

이 페이지는 더 큰 규모의 C4 모델 예제 네 개를 모았습니다. 모두 컨텍스트부터 컴포넌트까지 모델링했습니다. Stripe의 카드 결제, Netflix의 재생 요청, Uber의 배차 요청, Revolut의 해외 송금입니다. 각각 레벨 1 다이어그램, 레벨 2와 3으로 어떻게 확대되는지에 대한 짧은 요약, 그리고 전체 글로 가는 링크가 있습니다. 마지막에는 그대로 복사해 쓸 수 있는 작은 예제와, 네 예제의 공통점을 정리했습니다.

출처에 관하여. 네 예제는 모두 저희의 "Anatomy of" 시리즈에서 가져왔으며, 각각 해당 기업의 공개 자료에만 근거합니다. 엔지니어링 블로그, 컨퍼런스 발표, 오픈소스 리포지토리, 채용 공고, 외부 사례 연구입니다. 어느 것도 해당 기업의 공식 아키텍처 문서가 아닙니다. 각 전체 글에는 기업이 밝힌 내용이 아니라 추론한 세부 사항이 어디인지 표시되어 있습니다.

C4 모델 자체가 처음이라면 C4 모델이란 무엇인가부터 읽어 보세요. 네 가지 레벨별 가이드는 각 다이어그램 유형을 더 깊이 다룹니다: System Context, Container, Component, Code.

좋은 C4 예제의 조건

C4 다이어그램 예제는 모양이 아니라 결정을 배울 수 있을 때 유용합니다. 아래 네 예제는 같은 규칙에 따라 작성되었고, 예제를 보기 전에 그 규칙부터 가져갈 만합니다.

사용자 행동 하나를 따라간다. 어느 예제도 회사 전체를 문서화하려 하지 않습니다. 각각 사용자가 하는 일 하나(결제, 재생, 배차, 송금)를 골라, 그 행동이 닿는 것만 그립니다. 그래서 서비스가 천 개인 환경도 읽을 수 있는 한 페이지로 줄어듭니다.

레벨 1은 상자 열 개 정도로. System Context 레벨에서 Netflix 같은 회사는 마이크로서비스 천 개가 아닙니다. 몇 개의 제품 시스템과 그 주변의 외부 액터입니다. 레벨 1 다이어그램에 상자가 마흔 개 필요하다면, 경계를 잘못된 높이에 그은 것입니다.

레벨 2에서는 경로 하나로 확대한다. 컨테이너 다이어그램은 그 한 가지 행동이 지나가는 경로 위의 컨테이너를 기술과 프로토콜과 함께 보여 줍니다. 회사가 운영하는 모든 컨테이너를 보여 주지는 않습니다.

레벨 3 확대에는 이유가 있어야 한다. 컴포넌트 다이어그램은 컨테이너 하나에만 그립니다. 흥미로운 엔지니어링이 있는 곳, 또는 회사가 정직하게 모델링할 수 있을 만큼 공개적으로 자세히 문서화한 곳입니다.

상자를 결정으로 설명한다. 각 예제는 레벨 사이에 짧은 아키텍처 결정 기록(ADR) 세 개를 둡니다. 다이어그램은 무엇이 있는지 보여 줍니다. ADR은 왜 그런 모습인지 말해 줍니다. 새로 합류한 사람이 가장 먼저 묻는 질문이 바로 그것입니다.

네 예제를 한눈에 비교하면 다음과 같습니다:

예제 1: Stripe, 카드 결제

Stripe의 공개 자료를 바탕으로 했습니다. Stripe의 공식 아키텍처 문서가 아닙니다.

레벨 1. System Context에서 Stripe는 "결제 API"가 아닙니다. 저희 모델에서는 하나의 기반을 공유하는 제품 시스템 열다섯 개가 드러납니다: Payments, Connect, Billing, Radar, Issuing, Treasury 등입니다. 그 주위에는 가맹점, 카드 소지자, 카드 네트워크, 대체 결제 수단, 매입사와 발급사 은행, 은행 파트너, 그리고 AWS가 있습니다.

레벨 2. 컨테이너 다이어그램은 Payments 상자를 열고 PaymentIntents.create() 호출 하나를 따라갑니다: API 게이트웨이, 상태를 변경하는 모든 엔드포인트 앞에 놓인 멱등성 레이어, PaymentIntent 상태 머신, 카드 데이터 볼트, 병렬로 실행되는 Radar 스코어링, 네트워크 커넥터, 원장, 그리고 Webhook 전송입니다.

레벨 3. 컴포넌트 확대는 멱등성 레이어 안으로 들어갑니다. 스택에서 가장 많이 공개적으로 문서화된 부분이기 때문입니다: 요청 해셔, PostgreSQL의 키 저장소, 단계 실행기, 그리고 재시도된 요청이 멈춘 지점부터 이어서 실행되게 해 주는 복구 지점 추적기입니다.

여기서 배울 점. 컴포넌트 다이어그램을 공부하려면 이 예제를 보세요. 레벨 3 뷰는 클래스 목록이 아니라, 읽는 사람이 추론할 수 있는 단계의 연쇄입니다("모든 외부 부작용은 두 복구 지점 사이에 놓인다").

전체 글: Anatomy of a Charge: Stripe를 C4로 모델링하기.

예제 2: Netflix, 재생 요청

Netflix의 공개 자료를 바탕으로 했습니다. Netflix의 공식 아키텍처 문서가 아닙니다.

레벨 1. Netflix의 공개 자료에서는 시스템 열 개가 일관되게 나타납니다: Member Experience, Content Discovery, Streaming Platform, Open Connect, Studio Engineering, Content Engineering, Data Platform, Cloud Platform, Security, Ads Platform입니다. 외부 액터로는 회원 기기, Open Connect 어플라이언스를 호스팅하는 ISP, AWS, DRM 제공업체, 결제 파트너, 콘텐츠 스튜디오가 있습니다.

레벨 2. 컨테이너 확대는 Streaming Platform을 열고 재생 요청을 따라갑니다: Playback API, 매니페스트 서비스, DRM용 라이선스 서비스, 메시지 보안 레이어, EVCache 계층, 그리고 그 뒤의 Cassandra 클러스터입니다. 매니페스트는 기기를 Open Connect 어플라이언스로 안내하는데, 여기서 CDN을 직접 구축하기로 한 레벨 1의 결정이 다시 나타납니다.

레벨 3. 컴포넌트 뷰는 비디오 인코딩 파이프라인인 Cosmos로 들어갑니다. Cosmos는 요청 시점의 재생 경로 위에 있지 않으며(인코딩은 작품이 수집될 때 일어납니다), 글에서도 그렇게 밝힙니다. 그럼에도 선택한 이유는 Netflix가 각 단계에 이름을 붙일 수 있을 만큼 충분히 공개했기 때문입니다: 검사, 복잡도 분석, 래더 생성, 인코딩, 검증, 품질 점수 산정입니다.

여기서 배울 점. 레벨 1에서 "천 개가 아니라 열 개"를 가장 분명하게 보여 주는 예제이며, 레벨 3 확대가 추적 경로를 벗어날 때 이를 인정하는 좋은 예이기도 합니다.

전체 글: Anatomy of a Play: Netflix를 C4로 모델링하기.

예제 3: Uber, 배차 요청

Uber의 공개 자료를 바탕으로 했습니다. Uber의 공식 아키텍처 문서가 아닙니다.

레벨 1. System Context에서 Uber는 공유된 Marketplace 하나 위에 놓인 제품 플랫폼 세 개(Mobility, Delivery, Freight)와 그 아래의 Foundation 플랫폼 계층입니다: Maps, Payments, 아이덴티티와 리스크, 커뮤니케이션, ML 플랫폼, 워크플로 엔진, 스토리지, 스트리밍, 옵저버빌리티, 컴퓨트입니다. 외부 액터로는 승객, 기사, 주문자, 배달원, 가맹점, 결제 네트워크, 통신사, 도시 규제 기관이 있습니다.

레벨 2. 컨테이너 확대는 Marketplace의 디스패치 경로를 통해 배차 요청을 따라갑니다: 엣지 게이트웨이, 각 트립을 워크플로 인스턴스로 실행하는 트립 오케스트레이터, 매칭 엔진, 동적 가격 책정, ETA 서비스, 기사 상태, 스토리지 레이어, 그리고 Kafka입니다.

레벨 3. 컴포넌트 뷰는 매칭 엔진을 엽니다: 좌표를 H3 육각형 인덱스로 바꾸는 요청 정규화기, 공급 스캐너, 링 확장기, 후보 순위 결정기, 배정 솔버, 알림 디스패처, 그리고 폴백 경로입니다.

여기서 배울 점. 모든 제품을 그리지 않고 레벨 1에서 플랫폼 기업을 그리는 방법을 보여 주는 예제입니다. 가운데 있는 공유 Marketplace가 어떤 서비스 목록보다도 Uber의 아키텍처에 대해 많은 것을 알려 줍니다.

전체 글: Anatomy of a Ride: Uber를 C4로 모델링하기.

예제 4: Revolut, 해외 송금

Revolut의 공개 자료를 바탕으로 했습니다. Revolut의 공식 아키텍처 문서가 아닙니다.

레벨 1. 공개 자료에는 최소 여덟 개의 제품 시스템이 나옵니다: Retail Banking, Business Banking, FX, Wealth and Trading, Credit, FinCrime, Onboarding and KYC, 그리고 이벤트 백본을 갖춘 코어 원장입니다. 그 주위에는 카드 네트워크, 결제 레일(Faster Payments, SEPA, SWIFT), 제휴 은행, 규제 기관, Google Cloud가 있습니다. 이 다이어그램은 조직도로는 알 수 없는 한 가지를 분명히 보여 줍니다. FinCrime에는 모든 제품에서 화살표가 들어오므로, 모든 제품의 크리티컬 패스 위에 있다는 것입니다.

레벨 2. 컨테이너 확대는 Retail Banking을 거치는 EUR에서 GBP로의 송금을 따라갑니다: 모바일 앱, API 엣지, 명시적인 상태 머신을 가진 송금 오케스트레이터, PostgreSQL 기반의 복식부기 원장, FX 엔진, FinCrime 파이프라인, 결제 레일마다 하나씩 있는 커넥터, 이벤트 저장소, 그리고 알림입니다.

레벨 3. 컴포넌트 뷰는 사기 탐지 엔진인 Sherlock을 엽니다: 피처 조립, 인메모리 프로필 저장소, 모델 서버, 판정 정책, 야간 재학습, 그리고 분석가 피드백 루프입니다.

여기서 배울 점. 네 예제 중 가장 완성도가 높은 예제입니다. 레벨 1과 2 사이에 단계별 타임라인을 추가했고(지연 시간은 공개된 값이 아니라 예시용이라고 명확히 표시했습니다), "따라 할 것, 건너뛸 것" 섹션에서 서비스 열 개 규모의 팀이 어떤 결정을 따라 하고 어떤 결정은 따라 하지 말아야 하는지 알려 줍니다.

전체 글: Anatomy of a Transfer: Revolut을 C4로 모델링하기.

복사해서 쓸 수 있는 작은 예제

위의 네 예제는 일부러 큰 것을 골랐습니다. 대부분의 시스템은 그렇지 않으니, 유용한 세 레벨을 모두 갖춘 작은 C4 모델 예제를 준비했습니다. 저희 C4 모델 완벽 가이드 전반에서 사용하는 이커머스 플랫폼입니다. 형태를 복사하고 상자 이름만 바꾸세요.

레벨 1: System Context

[Customer] --> [E-Commerce Platform] : Browses products, places orders
[Warehouse Staff] --> [E-Commerce Platform] : Manages inventory
[E-Commerce Platform] --> [Payment Gateway (Stripe)] : Processes payments
[E-Commerce Platform] --> [Shipping Provider (FedEx API)] : Creates shipments
[E-Commerce Platform] --> [Email Service (SendGrid)] : Sends notifications

사용자 두 종류, 외부 시스템 세 개, 그리고 여러분이 소유한 모든 것을 나타내는 상자 하나입니다.

레벨 2: Container

[Single-Page Application (React)] --> [API Gateway (Kong)] : Makes API calls (HTTPS/JSON)
[API Gateway] --> [Order Service (Go)] : Routes requests
[API Gateway] --> [Product Service (Go)] : Routes requests
[API Gateway] --> [User Service (Go)] : Routes requests
[Order Service] --> [Order Database (PostgreSQL)] : Reads/writes orders
[Product Service] --> [Product Database (PostgreSQL)] : Reads/writes products
[User Service] --> [User Database (PostgreSQL)] : Reads/writes users
[Order Service] --> [Message Queue (Kafka)] : Publishes order events
[Notification Service (Go)] --> [Message Queue] : Consumes order events

모든 상자에 기술을, 모든 화살표에 프로토콜이나 목적을 적었고, 데이터 저장소도 컨테이너로 그렸습니다.

레벨 3: Component (Order Service 내부)

[Order Handler] --> [Order Service] : Delegates business logic
[Order Service] --> [Order Repository] : Persists orders
[Order Service] --> [Payment Client] : Validates payment
[Order Service] --> [Inventory Client] : Checks stock availability
[Order Repository] --> [Order Database (PostgreSQL)] : SQL queries
[Payment Client] --> [Payment Gateway (Stripe)] : HTTPS/REST
[Inventory Client] --> [Product Service] : gRPC

컴포넌트 다이어그램은 컨테이너 하나에만 그립니다. 네 개의 큰 예제와 같은 규칙입니다. Product 서비스와 User 서비스는 단순한 CRUD라서, 내부를 그려 봐야 폴더 목록이 이미 보여 주는 것 이상을 알려 주지 못합니다.

각 선택의 이유는 레벨별 가이드를 참고하세요: System Context 다이어그램에 무엇이 들어가야 하는가, Container 다이어그램에 무엇이 들어가야 하는가, Component 다이어그램은 언제 그릴 가치가 있는가. 여기서는 레벨 4를 생략했는데, 대부분의 팀이 생략하는 것과 같은 이유입니다. 레벨 4가 언제 제 몫을 하는지는 Code 다이어그램 가이드에서 설명합니다.

네 예제의 공통점

나란히 놓고 보면 네 예제는 같은 몇 가지 습관을 따릅니다. 어느 것도 C4 모델 자체의 규칙은 아닙니다. 이 모델들을 읽기 쉽게 만든 것이 바로 이 습관들입니다.

레벨 1은 대략 상자 열 개. Stripe는 열다섯, Netflix는 열, Revolut는 여덟, Uber는 Marketplace 하나 위의 제품 플랫폼 세 개와 그 아래의 Foundation 플랫폼입니다. 어느 회사도 작지 않습니다. 레벨 1 다이어그램이 작게 유지되는 이유는 서비스가 아니라 제품 시스템 단위로 묶기 때문입니다.

레벨 2는 경로 하나. 각 컨테이너 다이어그램은 하나의 행동이 지나가는 컨테이너만 보여 줍니다. Stripe의 컨테이너 뷰에는 Billing이나 Atlas 컨테이너가 없습니다. Netflix의 뷰에는 Studio Engineering의 것이 하나도 없습니다. 이것은 누락이 아닙니다. 그 컨테이너들은 다른 행동을 위한 다른 다이어그램에 속합니다.

레벨 3는 컨테이너 하나를, 정직하게 고른다. 컴포넌트 확대는 항상 실제 컴포넌트를 그릴 수 있을 만큼 공개 문서가 충분한 곳으로 갑니다. Netflix 글은 Cosmos가 요청 시점의 재생 경로에서 벗어나 있다고 대놓고 밝힙니다. 이런 선택을 숨기는 예제는 잘못된 교훈을 가르칩니다.

외부 시스템도 내부 시스템만큼 중요하다. 카드 네트워크, ISP, 결제 레일, 통신사. 네 예제 모두에서 가장 중요한 상자 몇 개는 그 회사가 소유하지 않은 것들입니다. Revolut의 결제 레일 커넥터는 장애를 엔지니어링으로 없앨 수 없는 컨테이너이고, 그것을 눈에 보이게 만드는 것이 다이어그램입니다.

결정은 상자 바로 옆에 둔다. 각 예제에는 ADR이 세 개 있고, 각 ADR은 새로 온 사람이 의아해할 만한 상자를 설명합니다. 다른 스트리밍 서비스가 상용 CDN을 쓰는 곳에 Netflix는 왜 Open Connect를 두는지, Revolut에는 왜 Kafka가 없는지, Stripe는 왜 MongoDB에서 옮겨 가지 않고 그 위에 구축했는지. 이런 ADR을 쓰는 방법이 궁금하다면 아키텍처 결정 기록 완벽 가이드에서 다룹니다.

모든 상자에는 소유자가 있다. 각 글은 모델의 마지막에 소유권 맵을 둡니다. 어느 팀이 어느 시스템이나 컨테이너를 소유하는지입니다. 다이어그램을 누군가 정확하게 유지할 책임을 지는 것으로 바꾸는 단계입니다.

여러분의 시스템 모델링하기

이 모든 것을 적용하는 데 Stripe만 한 거래량이나 Uber만 한 서비스 수가 필요하지는 않습니다. 서비스가 열 개인 시스템에도 같은 단계가 통합니다:

1. 중요한 사용자 행동 하나를 고릅니다. 결제, 회원 가입, 새벽 3시에 누군가를 호출하게 만드는 그것.
2. 레벨 1을 그립니다. 여러분의 시스템을 상자 하나로, 모든 종류의 사용자와 그 행동이 닿는 모든 외부 시스템을 함께 그립니다. 상자는 열다섯 개 미만을 목표로 하세요.
3. 그 행동 하나에 대해 레벨 2를 그립니다. 지나가는 컨테이너만 그리고, 각각에 기술을, 각 화살표에 동사와 프로토콜을 적습니다.
4. 레벨 3를 그릴 컨테이너 하나를 고릅니다. 새로 합류한 사람이 어려워할 만한 것을 골라 주요 컴포넌트를 그립니다.
5. ADR 세 개를 씁니다. 누군가 "이건 왜 이렇게 되어 있어요?"라고 물을 만한 상자 세 개에 대해서입니다.
6. 모든 컨테이너에 팀 이름을 붙입니다.

그런 다음 다음 행동으로 반복합니다. 행동 서너 개를 마치면 레벨 2 다이어그램들이 겹치기 시작하는데, 그 겹치는 부분이 여러분의 진짜 컨테이너 다이어그램입니다.

네 예제가 보여 줄 수 없는 부분은 여섯 달 뒤에 일어나는 일입니다. 코드는 바뀌었는데 다이어그램은 그대로인 상황이죠. archyl은 바로 그 문제를 중심으로 만들어졌습니다. 리포지토리를 연결하면 AI 발견이 시스템, 컨테이너, 컴포넌트, 관계를 제안하고, 여러분은 처음부터 그리는 대신 승인만 하면 됩니다. 이후에는 드리프트 점수가 모델을 코드와 대조하므로, 모델이 낡았을 때 알 수 있습니다.

자주 묻는 질문

좋은 C4 모델 예제란 무엇인가요?

좋은 C4 모델 예제는 실제 사용자 행동 하나를 레벨 1부터 3까지 따라가고, 의외로 보이는 상자를 설명합니다. 이 페이지의 네 예제(Stripe, Netflix, Uber, Revolut)는 모두 그렇게 하며, 시스템 열 개 안팎의 레벨 1 다이어그램, 경로 하나로 제한한 컨테이너 다이어그램, 그리고 하나의 컴포넌트 확대를 갖추고 있습니다. 작은 시스템이라면 위의 이커머스 예제가 무난한 템플릿입니다.

C4 컨테이너 다이어그램 예제는 어디서 볼 수 있나요?

네 개의 전체 글에는 각각 레벨 2 컨테이너 다이어그램이 있습니다: Stripe의 Payments core, Netflix의 Streaming Platform, Uber의 디스패치 경로, Revolut의 송금 경로입니다. 컨테이너와 관계 표가 포함된 더 작은 실습 예제는 C4 Container 다이어그램 가이드를 참고하세요.

이것들은 Stripe, Netflix, Uber, Revolut의 공식 아키텍처 다이어그램인가요?

아닙니다. 각 모델은 해당 기업의 공개 자료에만 근거하며, 각 전체 글에는 밝혀진 내용이 아니라 추론한 세부 사항이 어디인지 표시되어 있습니다. 이 예제들은 C4 모델이 복잡한 스택을 어떻게 읽기 쉽게 만드는지 보여 주기 위한 것이지, 이 회사들이 현재 어떻게 운영되는지 문서화하려는 것이 아닙니다.

C4 예제에 네 레벨이 모두 필요한가요?

거의 필요하지 않습니다. 여기 있는 네 예제는 모두 레벨 1, 2, 3을 그리고 멈춥니다. 코드 레벨 다이어그램은 리팩터링할 때마다 바뀌기 때문에 보통 직접 그리기보다 코드에서 생성하는 편이 낫습니다. 실제 C4 모델 대부분이 컴포넌트에서 멈추는 이유입니다.

C4 System Context 다이어그램에는 요소가 몇 개 있어야 하나요?

공식적인 제한은 없습니다. 이 예제들에서 레벨 1은 서비스가 수백, 수천 개인 회사에 대해 시스템 여덟 개에서 열다섯 개와 그 외부 액터로 구성됩니다. 여러분의 다이어그램에 훨씬 더 많이 필요하다면, 아마 잘못된 레벨에서 컨테이너를 그리고 있거나 여러 시스템을 아우르는 시스템 랜드스케이프 뷰가 필요한 것입니다.

여러분의 시스템을 C4로 모델링해 보고 싶으신가요? Developer 플랜으로 archyl을 무료로 사용해 보세요. 신용카드는 필요 없습니다. 더 읽어 보기: C4 모델이란? 완벽 가이드 | C4 System Context 다이어그램 가이드 | C4 Container 다이어그램 가이드 | C4 Component 다이어그램 가이드 | C4 Code 다이어그램 가이드.