한 줄 정의
도식화(diagramming)는 아키텍트가 다양한 관점에서 본 시스템의 뷰를 시각적으로 전달하는 의사소통 기술이며, 표현 일관성과 표준 표기법을 통해 오해를 줄이는 작업입니다.
쉽게 말하면
아무리 뛰어난 아키텍처를 머릿속에 가지고 있어도 관리자에게 예산을, 개발자에게 동기를 끌어내지 못하면 무용지물입니다.
다이어그램은 그 설득의 핵심 도구입니다. 동시에 “지도가 영토는 아니다”라는 명제도 잊으면 안 됩니다. 다이어그램은 시스템 자체가 아니라 시스템을 특정 관점에서 본 뷰일 뿐입니다.
따라서 좋은 도식화는 두 가지를 동시에 요구합니다.
- 부분과 전체의 관계 를 잃지 않을 것 (표현 일관성)
- 표기법의 의미 를 청중과 합의할 것 (표준 또는 범례)
왜 중요한가?
- 해결하는 문제: 아키텍트의 기술적 아이디어를 비기술 이해관계자(관리자, 비즈니스)와 기술 이해관계자(개발자, 운영자) 모두에게 정확히 전달해야 하는 문제입니다.
- 이게 없다면: 부분만 보여주는 다이어그램은 보는 이가 전체에서 어느 위치에 있는지 모르게 만듭니다. 표기 규칙이 모호하면 같은 그림을 보고도 사람마다 다른 시스템을 떠올립니다.
핵심 내용
표현 일관성 (Representational Consistency)
표현 일관성이란 한 부분을 보여주는 뷰에서 다른 부분을 보여주는 뷰로 넘어갈 때, 그 부분들이 어떤 관계인지를 먼저 보여주는 관행 입니다.
예를 들어 마이크로커널 아키텍처의 플러그인 내부 구조를 설명하려면, 먼저 시스템 전체 토폴로지를 보여준 뒤 토폴로지와 플러그인의 관계를 드러내고 그다음에 플러그인 내부로 들어가야 합니다.
flowchart LR subgraph Local R[Recipes] I[Inventory] P[Promotion] L[Location] end R -.확대.-> Recipes_Detail subgraph Recipes_Detail[Recipes 내부] C1[코드] C2[코드] C3[코드] C4[코드] end Local --> DB[(데이터베이스)]
이 패턴을 지키면 다이어그램에 표현된 요소들의 범위가 명확해지고 흔히 발생하는 오해를 미연에 방지할 수 있습니다.
도구
비합리적 산출물 집착 (Irrational Artifact Attachment)
산출물을 만드는 데 시간을 많이 투자할수록 그 산출물에 비합리적으로 집착하게 되는 현상을 말합니다. Visio 같은 도구로 네 시간 동안 멋진 다이어그램을 만들었다면 두 시간 들였을 때보다 훨씬 더 집착하기 쉽습니다.
이 안티패턴이 무서운 이유는 객관성을 잃게 만들기 때문입니다. 설계 초기에는 가설을 빠르게 만들고 폐기하는 능력이 핵심인데, 산출물에 집착하면 잘못된 설계를 끌고 가게 됩니다.
해독제는 로테크(low-tech) 도구 입니다. 인덱스카드, 포스트잇, 화이트보드, 태블릿처럼 부담 없이 폐기할 수 있는 도구로 시작합니다. 애자일 실천가들이 적시(just-in-time) 산출물을 선호하는 이유도 같은 맥락입니다.
임시 산출물의 진화
대표적인 임시 산출물은 화이트보드 사진이지만, 요즘은 태블릿이 대세입니다.
| 매체 | 장점 | 한계 |
|---|---|---|
| 화이트보드 | 즉각적, 협업 용이 | 캔버스 유한, 반사광, 원격 협업 불가 |
| 태블릿 | 무한 캔버스, what-if 시나리오 복사 가능, 디지털 원본, 원격 협업 자연스러움 | 도구 비용 |
태블릿의 진짜 가치는 what-if 시나리오 입니다. 화이트보드라면 원본 위에 가상 시나리오를 지저분하게 덮어 그려야 했지만, 태블릿은 원본을 보존한 채 복사본에서 실험할 수 있습니다.
그리기 도구의 필수 기능
고급 도구로 넘어갈 때는 다음 세 기능이 필수입니다.
레이어 (Layer)
여러 항목을 논리적으로 묶거나 필요에 따라 보이거나 숨길 수 있게 해줍니다. 장식이 아니라 의미를 위해 사용해야 합니다.
기반 레이어(base layer)는 아키텍처의 토폴로지(컨테이너, 데이터베이스, 의존성, 브로커)를 나타내고 구현 세부 사항(프로토콜 이름 등)은 상위 레이어에 두는 것이 좋습니다. 추상적인 이름(“동기적 통신”)을 기반에 쓰고 구체적인 이름(“REST/HTTP”)을 위에 얹으면 다이어그램이 확장 가능해집니다.
스텐실/템플릿 (Stencil)
자주 쓰는 시각적 구성요소들을 라이브러리로 모아둡니다. 조직에서 표준 스텐실을 만들어두면 다이어그램의 일관성이 높아지고 작성 시간도 크게 줄어듭니다.
자석 (Magnet/Snap)
선의 끝을 연결 지점 근처로 가져가면 자동으로 붙는 기능입니다. 정렬을 깔끔하게 만들고 시각적 노이즈를 줄입니다.
다이어그램 표준: UML, C4, ArchiMate
세 가지 주요 표기법을 비교합니다.
| 표준 | 등장 | 만든 사람 | 위치 | 한계 |
|---|---|---|---|---|
| UML | 1980년대 | Booch, Jacobson, Rumbaugh | 클래스/시퀀스 다이어그램은 여전히 사용 | ”designed by committee”의 부작용. 일부 의무 조직 외 영향력 미미 |
| C4 | 2006~2011 | Simon Brown | 광범위한 사용층, 활발한 생태계 | UML보다 후발이라 모르는 조직도 많음 |
| ArchiMate | The Open Group | 엔터프라이즈 모델링 | 비즈니스 도메인 내외부 통합 표현 | 모든 edge case를 포괄하지 않음 |
UML이 살아남은 부분
UML은 모든 설계 철학의 장점을 아우르려 했지만 위원회 산출물의 함정에 빠졌습니다. 그럼에도 클래스 다이어그램 과 시퀀스 다이어그램 은 지금도 구조와 작업흐름을 전달하는 표준으로 살아남았습니다. 다른 UML 다이어그램들은 거의 쓰이지 않습니다.
C4의 4가지 뷰
C4의 이름은 네 개의 C로 시작하는 뷰에서 옵니다.
- Context: 시스템 전체 컨텍스트. 사용자 역할과 외부 의존성 포함
- Container: 물리적/논리적 배포 경계와 컨테이너. 운영 팀과의 소통 지점
- Component: 컴포넌트 관점의 시스템 뷰. 아키텍트의 시각과 가장 일치
- Class: UML 클래스 다이어그램과 동일
C4가 흥미로운 이유는 줌 레벨 의 개념을 명시적으로 도입했기 때문입니다. Context → Container → Component → Class 순서로 들어가면 표현 일관성을 자연스럽게 지킬 수 있습니다.
Context (시스템 + 외부 액터)
↓
Container (배포 단위)
↓
Component (코드 컴포넌트)
↓
Class (구현 디테일)
ArchiMate가 자리잡은 영역
ArchiMate는 “가능한 한 작은” 기술 표준을 목표로 한 경량 모델링 언어입니다. 비즈니스 레이어와 기술 레이어를 함께 표현해야 하는 엔터프라이즈 환경에서 강세를 보입니다.
다이어그램 작성 지침
표준을 쓰든 자신만의 스타일을 쓰든 다음 일반 지침은 공통됩니다.
제목
모든 요소에 제목을 붙여야 합니다. 청중이 익숙한 항목은 예외지만, 회전 등의 효과를 활용해 제목이 대상 요소에 잘 붙어 있고 공간 낭비가 없도록 합니다.
선
- 충분히 두껍게 그려 잘 보이게 합니다.
- 정보 흐름은 화살표로 한쪽 또는 양방향을 명확히 표시합니다.
- 다양한 화살표 머리 모양으로 다른 의미를 전달할 수 있습니다(일관성 유지 전제).
- 실선은 동기적 통신, 점선은 비동기 통신 을 나타냅니다. 이는 아키텍처 다이어그램에서 몇 안 되는 공통 표준 중 하나입니다.
이 마지막 규칙은 외울 가치가 있습니다. 백엔드 관점에서 동기/비동기는 시스템의 결합도, 응답 지연, 장애 격리 특성을 결정하는 핵심 차원이기 때문입니다.
도형
업계 전반에 통용되는 표준 도형 모음은 없습니다. 다만 일반적인 컨벤션은 있습니다.
- 3차원 상자: 배포 가능한 요소
- 사각형: 컨테이너
- 원통: 데이터베이스
조직 내 표준을 만들어두면 그 자체가 조직의 언어가 됩니다.
레이블
모든 요소에 레이블을 붙여야 합니다. 의미가 둘 이상으로 해석될 수 있는 요소라면 특히 중요합니다.
색상
흑백 인쇄에 익숙해진 관성 때문에 아키텍트들은 색상을 잘 활용하지 않습니다. 그러나 색상은 요소를 구분하는 강력한 도구입니다. 흑백이 강제되는 환경이라면 회색조(gray scale)도 좋습니다.
다만 두 가지 함정을 조심해야 합니다.
- 색각 이상자/시각 장애인 은 색 차이를 인식하지 못할 수 있습니다.
- 색상만으로 의미를 전달 하지 말고 고유한 아이콘이나 모양을 함께 써야 합니다.
좋은 예시가 횡단보도 신호등입니다. 초록색과 빨간색뿐만 아니라 사람 모양 아이콘으로 횡단과 정지를 구분합니다. 이중화된 시각 신호가 핵심입니다.
범례
도형의 의미가 모호할 수 있다면 각 도형이 무엇을 의미하는지 설명하는 범례를 반드시 함께 제공해야 합니다. 의미를 오해할 수 있는 다이어그램은 없으니만 못합니다.
비교 / 트레이드오프
무거운 CASE 도구 vs 가벼운 도구
과거 무거운 CASE(Computer-Aided Software Engineering) 도구가 보편적이던 시절에는 단순한 것도 복잡하게 모델링해야 했고, 필요 없는 세부사항이 다이어그램에 들어가 오히려 혼란을 초래했습니다.
요즘은 가벼운 도구와 빠르고 간략한 산출물이 선호됩니다. 특히 설계 초기 단계일수록 그렇습니다.
| 축 | 무거운 도구 | 가벼운 도구 |
|---|---|---|
| 산출물 품질 | 정밀, 완전 | 빠름, 폐기 가능 |
| 객관성 | 집착 위험 | 실험 자유 |
| 적합 시점 | 후기, 공식 문서화 | 초기, 설계 탐색 |
핵심은 단계에 맞는 도구 입니다. 초기에 Visio로 픽셀 단위 정렬을 하고 있다면 본질에서 벗어난 것입니다.
표준 vs 자기 스타일
표준은 조직의 일관된 의사소통에 도움이 되지만, 표준이 설계 의도를 명확히 표현하지 못하는 경우가 많습니다. 조직은 표준을 제정하되 합리적인 예외는 허용해야 합니다.
내 생각
백엔드 관점에서 가장 중요한 표준은 “실선=동기, 점선=비동기”
마이크로서비스 환경에서 서비스 간 통신을 그릴 때, 이 한 가지 표준만 지켜도 다이어그램의 정보량이 두 배가 됩니다. REST와 메시지 큐가 섞인 시스템에서 어느 경로가 동기인지 한눈에 보이지 않으면, 장애 시나리오 분석이 거의 불가능합니다.
레이어를 의미로 쓰라는 조언은 IaC 다이어그램에도 적용됨
쿠버네티스 클러스터 다이어그램을 그릴 때 “네트워크/스토리지/워크로드/서비스 메시”를 별도 레이어로 두면, 청중에 따라 보여줄 레이어를 선택할 수 있습니다. 운영 팀에는 네트워크 레이어, 개발 팀에는 워크로드 레이어를 강조하는 식입니다.
C4 모델은 실무에서 도입 비용이 가장 낮음
C4는 표기법이 단순하고 줌 레벨이 명확합니다. 새 팀원이 들어왔을 때 Context → Container → Component 순으로 보여주면, 아키텍처 입문 시간이 크게 줄어듭니다. UML 클래스 다이어그램은 코드 수준 합의에서, ArchiMate는 비즈니스 이해관계자와의 합의에서 보조적으로 사용하는 조합이 현실적입니다.
비합리적 산출물 집착은 PR 리뷰에도 적용됨
다이어그램만의 문제가 아닙니다. 코드도 시간을 많이 들일수록 폐기하기 어려워집니다. “프로토타입은 던지기 위해 만든다”는 원칙이 다이어그램에도 그대로 적용된다는 점을 기억해두면 좋습니다.
더 알아볼 것
- C4 모델 공식 사이트(c4model.com)에서 표준 표기법 익히기
- PlantUML, Mermaid, Structurizr 같은 텍스트 기반 다이어그램 도구 비교
- ArchiMate가 엔터프라이즈 환경에서 어떻게 쓰이는지 사례 조사
- 스텐실 라이브러리 구축: AWS/GCP 아이콘, K8s 컴포넌트, 자체 마이크로서비스 모음
- 색각 이상자를 고려한 색상 팔레트(예: ColorBrewer) 학습
관련 개념
- Ch08 컴포넌트 기반 사고
- Ch09 아키텍처 스타일의 기초
- Ch13 마이크로커널 아키텍처
- Ch18 마이크로서비스 아키텍처
- Ch19 적절한 아키텍처 스타일의 선택
- Ch21 아키텍처적 결정
출처
- 소프트웨어 아키텍처 The Basics, Ch23 아키텍처 도식화