C4 시스템 컨텍스트 다이어그램: 예약 플랫폼 예시

C4 시스템 컨텍스트 다이어그램은 이 소프트웨어 시스템이 무엇인지, 누가 사용하는지, 어떤 외부 시스템에 의존하는지를 설명합니다. 구현 방식을 이해하기 전에 시스템의 경계부터 파악할 수 있도록 돕는 그림입니다.

팀이 아키텍처 다이어그램을 함께 그릴 때도 가장 먼저 정할 것은 이 경계입니다. 여기서는 고객과 서비스 일정 담당자가 사용하는 예약 플랫폼을 예로 듭니다. 화면, 데이터베이스, 배포 인프라는 이 그림에서 제외합니다.

예약 플랫폼의 책임 범위 정하기

C4 모델의 시스템 컨텍스트 안내는 하나의 소프트웨어 시스템과 여기에 직접 연결된 사람 및 외부 소프트웨어 시스템을 중심으로 설명합니다. 전체를 보는 관점이므로 프로토콜이나 내부 구성 요소보다 이용자와 책임이 중요합니다.

고객은 서비스 이용 시간을 예약하고, 일정 담당자는 예약 가능 시간을 관리하는 플랫폼을 생각해 봅시다. 이 플랫폼은 외부 결제 서비스에 결제 처리를 요청하고, 이메일 서비스에 예약 메시지 발송을 요청하며, 외부 캘린더 시스템에 예약 변경 정보를 전달합니다.

가운데 상자 안에는 예약 플랫폼 — 예약 가능 시간, 예약, 예약 변경을 관리한다처럼 한 문장으로 설명을 적습니다. 시스템의 목적 없이 기술적인 위치만 나타내는 ‘백엔드’라는 이름보다 유용합니다.

고객용 애플리케이션과 일정 담당자용 애플리케이션은 같은 시스템의 일부로 경계 안에 포함합니다. 독립적으로 운영되는 결제, 이메일, 캘린더 서비스는 포함하지 않습니다. 연동 코드를 관리하는 주체가 연결 상대인 서비스까지 관리하는 것은 아닐 수 있으므로 서로 다른 책임으로 표시합니다.

상자를 배치하기 전에 관계 목록 만들기

짧은 목록부터 만드세요. 그래야 보기 좋은 배치를 만들다가 중요한 역할이나 의존 대상을 빠뜨리지 않을 수 있습니다. 대상 시스템과 어떻게 관계되는지 설명할 수 있는 요소만 추가합니다.

앞의 두 관계는 사람에서 예약 플랫폼으로 향합니다. 나머지 세 관계는 플랫폼에서 외부 시스템으로 향합니다. 라벨은 해당 방향의 상호작용을 설명하며, 모든 요청과 응답을 나타내려는 것은 아닙니다.

예를 들어 ‘결제 처리를 요청한다’는 관계 하나로 플랫폼이 결제 서비스를 이용한다는 사실을 표현할 수 있습니다. 응답마다 선을 하나씩 추가할 필요는 없습니다. 별도의 비동기 결제 알림이 아키텍처 논의에 중요하다면 해당 관계를 따로 그리고 라벨을 붙이세요. 연결의 의미를 정하지 않은 채 ‘데이터’라고 적힌 양방향 화살표로 넘기지 않도록 합니다.

이 관점에 포함하지 않을 요소 정하기

이제 추가하고 싶어지는 요소를 검토합니다. 데이터베이스는 애플리케이션에 중요하지만, 그렇다고 자동으로 외부 시스템이 되는 것은 아닙니다. 이 예시의 예약 데이터베이스는 예약 플랫폼 내부에 있으므로 더 상세한 다이어그램에서 다룹니다.

회계 플랫폼 예시가 중요한 이유는 화살표가 아직 구축하지 않은 연결을 암시할 수 있기 때문입니다. 담당자가 정보를 내보내 다른 곳에 직접 입력하는 것은 예약 플랫폼이 정보를 전송하는 것과 다릅니다. 현재 상황을 정확하게 설명하고, 계획한 연동과 기존 연동을 구분하세요.

미래 상태를 그리는 것은 괜찮지만 제목에 그 사실을 표시해야 합니다. 운영 중인 결제 연결과 제안 단계의 캘린더 연결을 설명 없이 하나의 그림에 섞어 넣지 마세요.

회의가 끝난 뒤에도 이해되는 라벨 쓰기

C4의 표기 안내는 이해하기 쉬운 요소 설명, 관계 라벨, 범례를 강조합니다. 시각적 스타일은 선택할 수 있지만 회색 상자가 외부 시스템인지, 선택 사항인지, 단지 선택되지 않은 상태인지 독자가 추측하게 해서는 안 됩니다.

‘예약 플랫폼 — 시스템 컨텍스트 — 시범 도입안’처럼 구체적인 제목을 붙이세요. 사람, 대상 시스템, 외부 시스템을 구분하는 작은 범례도 넣습니다. 주변 문서와 같은 용어를 사용하세요. 제품팀에서 ‘서비스 일정 담당자’라고 부르는 역할을 ‘관리자’로 바꾸면 다른 책임을 가진 사람으로 해석될 수 있습니다.

설명은 다른 문서를 열지 않고도 읽을 수 있을 만큼 짧게 유지합니다. ‘이메일 서비스 — 예약 확인 및 변경 알림을 전달한다’는 설명은 공급업체 로고만 있는 것보다 많은 의미를 전달합니다. 로고로 현재 공급업체는 알 수 있어도, 그 의존 관계가 왜 필요한지는 알 수 없습니다.

모든 선을 시간순 단계로 해석하지 않도록 주의하세요. 시스템 컨텍스트 다이어그램은 관계를 보여 주지, 예약 처리의 정확한 순서를 보여 주지는 않습니다. ‘결제가 예약 확정보다 먼저인가?’ 같은 질문에는 이 그림의 설명을 길게 늘리기보다 동작을 다루는 별도의 관점이 필요합니다.

Boardmix에서 예약 시스템 컨텍스트 그리기

Boardmix 캔버스 가운데 예약 플랫폼을 놓습니다. 한쪽에는 두 사용자 역할을, 반대편에는 세 외부 시스템을 배치하고 관계 라벨을 위한 공간을 남기세요. 간단한 도형과 연결선이면 됩니다. 의미를 만드는 것은 특별한 서버 아이콘이 아니라 이름, 설명, 경계입니다.

목록에 있는 다섯 관계를 하나씩 추가합니다. ‘고객이 예약 플랫폼에서 예약을 만들고 변경한다’처럼 출발점에서 도착점 순서로 읽어 보세요. 문장이 명확하지 않다면 다음 화살표를 추가하기 전에 라벨을 고칩니다.

그림 옆에는 범위에 관해 아직 결정하지 않은 질문을 적을 작은 영역을 두세요. 예를 들어 ‘담당자가 캘린더를 직접 업데이트하는가, 플랫폼이 변경 정보를 전달하는가?’라고 적을 수 있습니다. 두 경로가 모두 확인된 것처럼 그려서 불확실성을 덮어 두지 마세요.

Boardmix에서 보드를 열고 팀의 시스템이 주변과 맺는 관계를 그려 보세요. 사용자 업무를 이해하는 사람과 시스템 의존 관계를 이해하는 사람이 함께하면, 같은 그림에서도 서로 다른 누락을 발견할 수 있습니다.

첫 그림의 의미를 유지하면서 상세화하기

컨텍스트에 합의했다면 C4 컨테이너 다이어그램에서 예약 플랫폼 내부의 애플리케이션과 데이터 저장소를 보여 줄 수 있습니다. 여기서 ‘컨테이너’는 C4의 추상화 개념이며, Docker나 다른 컨테이너 런타임을 반드시 사용해야 한다는 뜻이 아닙니다.

다음 그림에서는 하나였던 플랫폼 상자가 고객용 애플리케이션, 담당자용 애플리케이션, 애플리케이션 서비스, 예약 데이터 저장소로 펼쳐질 수 있습니다. 외부 결제, 이메일, 캘린더 시스템의 이름은 그대로 유지하세요. 두 번째 그림은 첫 번째 그림에 세부 사항을 더하는 것이지, 갑자기 다른 제품 경계를 도입하는 것이 아닙니다.

캘린더가 플랫폼 안에 속하는지 밖에 속하는지 합의하지 못했다면 그 질문부터 해결해야 합니다. 더 자세한 그림이 미해결된 책임 문제를 정리해 주지는 않습니다. 경계를 명확히 한 뒤, 다음 질문을 설명할 관점을 선택하세요.