다이어그램 고르는 법: C4·아키텍처·Journey·Gantt와 Mermaid 선택 기준

이 글은 "다이어그램으로 생각하기" 시리즈의 마지막 네 번째 글입니다. 앞선 글에서는 상태와 데이터, 구조를 다루었습니다. 이번에는 그 바깥의 보조 관점들을 짧게 훑고, 결국 어떻게 다이어그램을 고를지로 시리즈를 닫으려 합니다.

그동안 흐름과 상태, 구조라는 큰 줄기를 따라왔습니다. 다만 실무에서 마주치는 관점은 그보다 조금 더 넓다는 생각이 들었습니다. 시스템을 어떻게 배치할지, 사용자가 어떤 경험을 거치는지, 일이 시간 위에서 어떻게 흘러가는지 같은 것들입니다. 하나하나가 별도의 시리즈가 될 만큼 깊지만, 여기서는 "이런 관점도 있다" 정도로 가볍게 소개하고 넘어가려 합니다.

C4 / Architecture — 시스템을 어디에 둘 것인가

가장 먼저 떠올린 것은 시스템 배치였습니다. 코드 한 줄이 아니라, 웹 서버와 API, 데이터베이스, 외부 서비스 같은 덩어리들이 어떻게 연결되어 있는지를 보는 관점입니다. C4 모델은 이 배치를 Context에서 Container, Component로 차츰 줌인하며 그리는 방법론입니다. 멀리서 전체 맥락을 보고, 점점 안으로 들어가며 컨테이너와 컴포넌트로 해상도를 높이는 방식입니다.

다만 솔직히 말하면, Mermaid의 C4나 architecture-beta 문법은 아직 실험적이라는 인상을 받았습니다. 문법이 바뀌기도 하고, 렌더 결과가 기대만큼 안정적이지 않은 경우가 있었습니다. 그래서 돌이켜 보면 실무에서는 그냥 Flowchart로 컨테이너 다이어그램을 그리는 편이 더 마음이 편했습니다. 거창한 표기법을 따르기보다, 박스와 화살표로 "사용자가 웹을 거쳐 API로, 다시 DB와 외부 API로 이어진다"는 배치를 또렷하게 보여주는 것으로 충분했습니다.

flowchart LR
    U[사용자] --> WEB[Web]
    WEB --> API[API]
    API --> DB[(DB)]
    API --> EXT[외부 API]

물론 C4 도구가 성숙한 환경이라면 그 방법론을 따르는 것이 더 나을 수 있습니다. 다만 Mermaid라는 제약 안에서는, 안정적으로 그릴 수 있는 도구로 의도를 전달하는 쪽을 택했습니다. 결국 중요한 것은 표기법의 이름이 아니라 배치가 한눈에 읽히는지였습니다.

User Journey — 사람의 경험을 따라가다

다음은 조금 결이 다른 관점입니다. 지금까지의 다이어그램이 시스템 내부를 들여다보는 것이었다면, User Journey는 시스템을 쓰는 사람의 경험을 따라갑니다. 각 단계마다 사용자가 어떤 일을 겪는지, 그리고 그 순간이 얼마나 만족스러운지를 점수로 함께 적습니다. 기술이 아니라 경험을 그리는 다이어그램이라는 점에서 결이 다릅니다.

이 다이어그램이 유용했던 순간은 온보딩의 마찰을 찾을 때였습니다. 랜딩 페이지에서는 기대가 높았다가 가입 폼에서 점수가 뚝 떨어지는 것을 그림으로 보면, 어디서 사용자가 힘들어하는지가 숫자로 드러납니다. 코드를 들여다봐서는 잘 보이지 않던 지점이었습니다.

journey
    title 가입 여정
    section 진입
      랜딩: 4: 사용자
      가입폼: 2: 사용자
    section 활성화
      온보딩: 5: 사용자

점수가 절대적인 진실은 아닙니다. 다만 "여기서 만족도가 떨어진다"는 가설을 눈에 보이게 만든다는 것만으로도 대화의 출발점이 되었습니다.

Gantt / Timeline — 시간 위에 일을 올려놓다

시간이라는 축을 다루는 다이어그램도 있습니다. Gantt 차트는 각 작업의 기간과 의존 관계를 막대로 보여줍니다. 설계가 끝나야 구현을 시작할 수 있다는 식의 순서를 시각적으로 드러내기에 적합했습니다. 반면 Timeline은 의존 관계보다는 사건의 연대기, 즉 무엇이 언제 있었는지를 나열하는 데 가깝습니다.

gantt
    title 일정
    dateFormat YYYY-MM-DD
    section 개발
    설계 :a1, 2026-01-01, 7d
    구현 :after a1, 14d

두 다이어그램 모두 코드와는 거리가 있지만, 일정 공유나 회고를 할 때 한 장의 그림이 긴 설명을 대신해 주었습니다. 시간이라는 축 하나를 더했을 뿐인데 같은 정보가 전혀 다르게 읽힌다는 생각이 들었습니다.

Mindmap과 Gitgraph — 발산과 흐름

마지막으로 짧게 둘을 덧붙입니다. Mindmap은 하나의 중심에서 가지를 뻗어 나가며 생각을 발산하고 분류할 때 쓰는 다이어그램입니다. 기획 초기에 떠오르는 것들을 일단 펼쳐 놓고 묶어 보는 브레인스토밍에 잘 맞았습니다.

mindmap
  root((서비스))
    프론트
    백엔드

Gitgraph는 브랜치가 갈라지고 다시 합쳐지는 흐름을 그립니다. 협업 전략을 설명하거나 머지 흐름을 정리할 때, 말로 설명하기 번거로운 분기 구조를 한눈에 보여줄 수 있었습니다.

gitGraph
    commit
    branch feature
    commit
    checkout main
    merge feature

그래서 무엇을 고를 것인가

여기까지 오고 보니, 결국 남는 질문은 하나였습니다. 이 많은 다이어그램 중에서 무엇을 고를 것인가 하는 점입니다. 곰곰이 생각해보니 답은 다이어그램의 종류가 아니라 지금 답하려는 질문에 있었습니다. 무엇이 궁금한지가 정해지면 도구는 자연스럽게 따라왔습니다.

답하려는 질문	고를 다이어그램
일이 어떤 순서로 흘러가는가	Flowchart
시간 위에서 누가 누구를 호출하는가	Sequence
무엇이 어떤 상태를 거치는가	State
데이터가 어떻게 묶이는가 (코드 구조는)	ER (구조는 Class)
시스템이 어떻게 배치되는가	C4 (Mermaid에선 Flowchart로 대용)
사람·시간·생각은 어떻게 흐르는가	Journey · Gantt · Timeline · Mindmap

그리고 여기서 첫 글의 이야기로 돌아오게 됩니다. 한 시스템을 여러 종류의 다이어그램으로 그려 보는 것은 분명 도움이 됩니다. 다만 같은 것을 다른 모양으로 반복해서 그리는 것은 의미가 없다는 생각이 들었습니다. 중요한 것은 각각이 서로 다른 질문에 답하도록 조합하는 일입니다. 흐름을 보는 그림과 상태를 보는 그림, 사람의 경험을 보는 그림이 한자리에 모일 때 비로소 시스템이 입체적으로 보였습니다.

시리즈를 닫으며

네 편에 걸쳐 다이어그램을 하나의 관점으로 다뤄 보았습니다. 돌이켜 보면 다이어그램은 그림을 그리는 일이라기보다, 무엇을 묻고 싶은지를 먼저 정하는 일에 가까웠습니다. 도구는 그 질문을 또렷하게 만들어 주는 보조 장치였을 뿐이라는 생각이 듭니다.

다만 막상 Mermaid로 직접 그리다 보면, 생각만큼 매끄럽지 않은 순간들을 만나게 됩니다. 한글 라벨이 잘리고, 다크모드에서 글자가 묻히고, gantt의 의존 관계가 어긋나는 자잘한 함정들이 있었습니다. 이런 실전의 마찰과, 그것을 어떻게 자동으로 검수했는지에 대해서는 후속 글 "Mermaid 실전 — 직접 쓰며 만난 렌더 함정"에서 따로 풀어 보려 합니다. 아직은 정리 중이라 여기서는 예고만 남겨 둡니다. 긴 시리즈를 함께 읽어 주셔서 감사합니다.