사전 컨텍스트 다이어그램
개념

컨텍스트 다이어그램

gabury1고친 사람 github-actions[bot]

컨텍스트 다이어그램은 우리 시스템이 바깥과 무엇을 주고받는지 한 장으로 보여 줍니다. 시스템 안쪽은 상자 하나로 접어 둡니다. 그 바깥에 시스템을 쓰는 사람과 연결된 다른 시스템을 놓습니다. 무엇이 우리 몫이고 무엇이 남의 몫인지 선을 긋는 데 씁니다.

쉽고 빠른 이해

컨텍스트 다이어그램은 시스템을 가장 멀리서 본 그림입니다. 사내 휴가 관리 시스템이라면 가운데에 그 시스템 상자 하나를 둡니다. 주변에 직원과 팀장, 사내 로그인 시스템, 메일 발송 서비스, 급여 시스템을 그립니다.

이 그림이 없으면 「이 시스템은 어디까지 만들고 무엇에 기대나」를 사람마다 다르게 압니다. 급여 시스템이 우리가 고칠 대상인지, 데이터만 넘기는 상대인지가 회의 중에야 드러납니다.

그리는 순서는 이렇습니다.

  1. 우리 시스템을 상자 하나로 그립니다. 안은 그리지 않습니다
  2. 시스템을 쓰는 사람과 연결된 다른 시스템을 상자 바깥에 놓습니다
  3. 그 사이에 화살표를 긋고 무엇이 오가는지 적습니다

대가는 안쪽에 대해서는 아무것도 알려 주지 않는다는 것입니다. 서버를 몇 대 두고 데이터를 어디에 담는지는 상자 안을 열어 그리는 다음 그림이 맡습니다.

상세

이 절은 컨텍스트 다이어그램에 무엇이 오르고 무엇이 빠지는지를 봅니다. 예로는 사내 휴가 관리 시스템 하나를 끝까지 씁니다. 그림 한 장을 그려 놓고, 그 그림이 무엇을 알려 주고 무엇을 안 알려 주는지를 차례로 짚습니다.

이사 갈 집을 친구에게 설명하는 장면을 떠올려 보면 됩니다. 방이 몇 개인지보다 먼저 역이 어디고 마트와 학교가 어느 방향인지를 그려 줍니다. 집은 네모 하나로 두고 주변만 자세히 그립니다.

그림에 오르는 세 요소

컨텍스트 다이어그램에는 세 가지만 오릅니다. 가운데의 시스템 상자, 그 상자를 둘러싼 외부 요소들, 그리고 둘을 잇는 화살표입니다.

요소 무엇인가 휴가 관리 시스템에서
시스템 우리가 만들고 책임지는 소프트웨어 하나. 상자 하나로 그린다 휴가 관리 시스템
외부 요소 시스템 밖에서 시스템과 무언가를 주고받는 사람이나 다른 시스템 직원 · 팀장 · 사내 로그인 시스템 · 메일 발송 서비스 · 급여 시스템
화살표 둘 사이에 오가는 것. 무엇이 오가는지를 글로 적는다 휴가 신청 · 승인 결과 · 쓴 휴가 일수

표의 둘째 줄은 사람과 다른 시스템을 함께 담습니다. 이 편에서는 둘을 묶어 「외부 요소」라고 부릅니다. 분야마다 따로 쓰는 이름이 있는데, 그 이름들은 뒤의 「같은 이름을 쓰는 두 전통」에서 봅니다.

휴가 관리 시스템의 컨텍스트 다이어그램

이 그림은 휴가 관리 시스템이 누구에게 쓰이고 무엇에 기대는지를 보입니다. 위쪽 둘은 시스템을 쓰는 사람입니다. 아래쪽 셋은 시스템이 부르는 외부 시스템입니다. 이 그림에서 화살표 방향은 누가 먼저 말을 거는지를 뜻합니다.

flowchart TD
    직원["직원 · 사람"]
    팀장["팀장 · 사람"]
    시스템["휴가 관리 시스템"]
    로그인["사내 로그인 시스템 · 외부 시스템"]
    메일["메일 발송 서비스 · 외부 시스템"]
    급여["급여 시스템 · 외부 시스템"]
    직원 -->|"휴가를 신청한다"| 시스템
    팀장 -->|"신청을 승인하거나 반려한다"| 시스템
    시스템 -->|"로그인한 사람이 누구인지 묻는다"| 로그인
    시스템 -->|"승인 결과 메일을 보낸다"| 메일
    시스템 -->|"쓴 휴가 일수를 넘긴다"| 급여

직원은 휴가를 신청합니다. 팀장은 그 신청을 승인하거나 반려합니다. 휴가 관리 시스템은 누가 접속했는지 사내 로그인 시스템에 묻습니다. 결과가 나오면 메일 발송 서비스로 알림을 보냅니다. 쓴 휴가 일수는 급여 시스템에 넘깁니다.

사내 로그인 시스템은 SSO(Single Sign-On, 한 번 로그인하면 여러 사내 시스템을 쓰게 해 주는 방식)를 맡는 시스템입니다. 휴가 관리 시스템은 로그인 화면을 따로 만들지 않고 이 시스템에 맡깁니다.

시스템 경계

가운데 상자의 테두리를 시스템 경계라고 부릅니다. 테두리 안은 우리 팀이 만들고 고치는 것입니다. 밖은 우리가 바꿀 수 없는 것입니다. 이 선 하나가 프로젝트의 범위를 정합니다.

휴가 관리 시스템의 그림에서 급여 시스템은 테두리 밖에 있습니다. 우리는 급여 시스템에 쓴 휴가 일수를 넘기기만 합니다. 급여를 계산하는 코드는 건드리지 않습니다. 반대로 급여 시스템을 상자 안에 그렸다면 그 계산 로직도 우리 일이 됩니다.

경계를 그리면 바깥에 기대는 것이 한눈에 보입니다. 그림의 아래쪽 화살표 셋은 전부 의존성입니다. 사내 로그인 시스템이 멈추면 아무도 휴가를 신청하지 못합니다. 그래서 장애가 어디서 번져 올 수 있는지, 어느 팀과 연동 약속을 맺어야 하는지 정할 때도 이 그림을 열어 봅니다.

안쪽을 그리지 않는 까닭

컨텍스트 다이어그램에는 서버, 데이터베이스, 프로그래밍 언어 같은 기술 낱말이 나오지 않습니다. 이 그림을 읽는 사람이 개발자만이 아니기 때문입니다. 기획자, 운영 담당자, 연동할 상대 팀이 같은 그림을 보고 같은 범위를 떠올려야 합니다.

안쪽을 그리기 시작하면 그림이 커지고 범위를 정하는 대화가 구현 이야기로 흘러갑니다. 휴가 관리 시스템이 웹 서버 하나인지 둘인지는 범위와 상관이 없습니다. 그런 결정은 상자를 한 단계 열어 그리는 다음 그림이 맡습니다.

같은 이름을 쓰는 두 전통

이 그림은 두 갈래의 방법에서 거의 같은 뜻으로 쓰입니다. 하나는 구조적 분석이고, 다른 하나는 C4 모델입니다. 두 쪽 모두 「안은 접고 바깥만 그린다」는 생각은 같습니다. 다만 외부 요소를 부르는 이름이 다릅니다.

구조적 분석은 시스템을 데이터가 흘러가는 길로 보고 분석하는 방법입니다. 이 방법은 데이터 흐름도(DFD, Data Flow Diagram)를 여러 층으로 나눠 그립니다. 컨텍스트 다이어그램은 그 맨 위 층의 그림입니다. 한 층 아래 그림에서는 시스템 도형을 데이터를 다루는 처리 여러 개로 쪼갭니다.

구조적 분석에서는 외부 요소를 외부 엔티티라고 부릅니다. 시스템 밖에서 데이터를 보내거나 받는 쪽이면 사람이든 다른 시스템이든 외부 엔티티입니다.

C4 모델은 소프트웨어 구조를 네 단계로 확대해 가며 그리는 방법입니다. 단계마다 C 로 시작하는 영어 이름이 붙어 C4 라고 부릅니다. 차례는 시스템과 그 주변(Context) → 시스템 안에서 따로 실행되는 단위(Container) → 그 안의 부품(Component) → 코드(Code)입니다.

그 첫 단계가 「시스템 컨텍스트 다이어그램」입니다. 이 편의 컨텍스트 다이어그램과 같은 그림입니다. 다음 단계인 컨테이너 다이어그램이 상자 안을 엽니다. 웹 애플리케이션과 데이터베이스처럼 따로 띄우는 것들이 그때 드러납니다.

두 전통 밖에서도 비슷한 이름이 쓰입니다. 설계 그림의 표기법인 UML(Unified Modeling Language, 통합 모델링 언어)에서는 시스템 밖에서 시스템을 쓰는 쪽을 행위자라고 부릅니다. 대개 사람이지만 다른 시스템일 때도 있습니다.

화살표에 적는 글

화살표 위의 글은 둘 사이에 무엇이 오가는지를 알려 줍니다. 적는 방식은 두 가지로 갈립니다. 오가는 데이터의 이름을 적는 방식과, 상대가 하는 일을 동사로 적는 방식입니다.

적는 방식 휴가 신청 화살표에 적는 글 주로 쓰는 분야
데이터 이름 휴가 신청서 구조적 분석
하는 일 휴가를 신청한다 C4 모델

어느 쪽이든 화살표에 글이 없으면 그림이 쓸모를 크게 잃습니다. 선만 그어 두면 「연결되어 있다」는 것만 알 뿐 무엇 때문에 연결됐는지를 모릅니다.

쓰는 때와 안 쓰는 때

컨텍스트 다이어그램이 쓸모 있는 때는 대개 범위를 맞춰야 할 때입니다. 새 프로젝트를 시작하며 무엇까지 만들지 정할 때, 새로 온 사람에게 시스템을 처음 소개할 때, 외부 연동 목록을 점검할 때 이 그림을 꺼냅니다. 요구사항 공학에서도 무엇을 만들지 정하는 초기 단계에 범위를 합의하려고 그립니다.

보안 검토에서도 씁니다. 데이터가 시스템 밖으로 나가는 화살표가 곧 살펴볼 지점이기 때문입니다.

반대로 시스템 안의 구조를 정하는 일에는 이 그림이 답을 주지 않습니다. 모듈을 어떻게 나눌지, 어느 서버에 무엇을 올릴지는 다른 그림의 몫입니다.

이 그림을 쓰는 대가는 관리입니다. 연동 상대가 바뀐 뒤 그림을 안 고치면 그림이 없는 것보다 더 큰 오해를 낳습니다. 외부 요소가 수십 개로 늘어나면 한 장에 담기 어려워집니다. 이럴 때는 성격이 비슷한 외부 시스템을 하나로 묶어 그리거나, 회사 전체의 시스템을 한 장에 담는 시스템 랜드스케이프 다이어그램으로 넘어갑니다.

헷갈리는 이웃 그림

이름이나 모양이 비슷해서 자주 섞이는 그림이 셋 있습니다. 가르는 기준은 「무엇을 주로 그리나」입니다.

그림 주로 그리는 것 컨텍스트 다이어그램과 다른 점
유스케이스 다이어그램 시스템이 제공하는 기능 목록 시스템 상자 안에 기능을 하나씩 늘어놓는다
시스템 랜드스케이프 다이어그램 회사 안의 여러 시스템 가운데 시스템 하나가 아니라 여럿을 함께 그린다
배포 다이어그램 소프트웨어가 올라가는 서버와 네트워크 기술 낱말과 장비가 주인공이다

유스케이스 다이어그램은 겉모습이 가장 비슷합니다. 상자 밖에 사람이 서 있고 가운데에 시스템 상자가 있습니다. 차이는 상자 안입니다. 유스케이스 다이어그램은 「휴가 신청」 「휴가 승인」 같은 기능을 상자 안에 늘어놓습니다. 컨텍스트 다이어그램은 상자 안을 비워 둡니다.

관련 항목

컨텍스트 다이어그램이 속하는 상위 분류

소프트웨어 아키텍처 · 아키텍처 기술 · 구조적 분석 · 요구사항 공학 · 설계 문서

컨텍스트 다이어그램을 이루는 구성 요소

시스템 경계 · 외부 엔티티 · 행위자 · 외부 시스템 · 데이터 흐름 · 이해관계자

컨텍스트 다이어그램을 확대해 그리는 다이어그램

데이터 흐름도 · C4 모델 · 컨테이너 다이어그램 · 컴포넌트 다이어그램 · 시스템 랜드스케이프 다이어그램

컨텍스트 다이어그램과 헷갈리는 다이어그램

유스케이스 다이어그램 · 배포 다이어그램 · 시퀀스 다이어그램 · UML · 4+1 뷰

컨텍스트 다이어그램이 드러내는 설계 관심사

의존성 · 외부 연동 · 신뢰 경계 · 관심사 분리 · SSO · API

다른 이름: context diagram · system context diagram · 시스템 컨텍스트 다이어그램 · 시스템 문맥도 · 문맥 다이어그램