흐름을 그리다: Flowchart와 Sequence 다이어그램의 차이

이 글은 '다이어그램으로 생각하기' 시리즈의 2편입니다. 1편에서 다이어그램이 결국 하나의 관점이라는 이야기를 했는데, 이번에는 그 관점 중 가장 자주 쓰게 되는 '흐름'을 다뤄보려 합니다.

흐름을 그린다고 하면 보통 화살표가 줄지어 있는 그림을 떠올립니다. 그런데 같은 흐름이라도 무엇을 묻느냐에 따라 그림이 전혀 달라진다는 생각이 들었습니다. Flowchart는 '무엇을 어떤 순서로'를 답하고, Sequence 다이어그램은 '누가 누구에게 언제'를 답합니다. 둘은 닮은 듯 보이지만, 드러내는 것이 서로 다릅니다.

Flowchart — 절차와 분기를 그리다

Flowchart는 가장 범용적인 흐름 다이어그램입니다. 노드는 하나의 단계를 뜻하고, 화살표는 흐름의 방향을, 다이아몬드는 분기를 나타냅니다. 프로세스나 알고리즘, 의사결정 과정을 그릴 때 가장 먼저 손이 가는 도구입니다.

구조가 단순한 만큼 진입 장벽이 낮습니다. 무엇을 먼저 하고 그다음 무엇을 하는지, 어떤 조건에서 길이 갈라지는지를 차례대로 그리기만 하면 됩니다. 아래는 요청을 받아 인증 여부에 따라 처리가 갈라지는 간단한 예시입니다.

flowchart TD
    A[요청 수신] --> B{인증?}
    B -->|성공| C[처리]
    B -->|실패| D[401 반환]
    C --> E[응답]

다만 Flowchart에는 제가 여러 번 빠졌던 함정이 있습니다. 한 노드에 너무 많은 내용을 담으면 그림이 금세 빽빽해진다는 점입니다. 노드 안의 설명은 두 줄을 넘기지 않는 편이 좋다는 생각이 들었습니다. 한 노드가 길어진다는 것은 대개 그 단계를 더 쪼개야 한다는 신호이기도 합니다.

또 하나의 한계는 분기입니다. 조건이 늘어나 다이아몬드가 폭발하듯 번지기 시작하면, 그때는 Flowchart가 맞지 않을 수 있습니다. 상태가 많다면 다음 편에서 다룰 State 다이어그램이, 상호작용이 복잡하다면 Sequence 다이어그램이 더 어울립니다.

Sequence — 시간순 상호작용을 그리다

Sequence 다이어그램은 참여자(actor 또는 서비스)를 세로선으로 세워두고, 시간 위에서 메시지가 오가는 순서를 그립니다. 위에서 아래로 시간이 흐르고, 그 사이를 화살표가 가로지릅니다. 화살표의 종류에는 의미가 담겨 있습니다.

• 실선 화살표는 동기 호출입니다. 응답을 기다리는 호출이라는 뜻입니다.

• 점선 화살표는 응답 또는 반환을 나타냅니다.

• 열린 화살표(-))는 비동기 호출입니다. 응답을 기다리지 않고 다음으로 넘어갑니다.

여기에 Note로 특정 구간에 설명을 덧붙일 수 있습니다. 이 작은 표기 차이들이 모이면, Flowchart에서는 잘 보이지 않던 것이 드러납니다.

실제로 블로그 글 발행 파이프라인을 Sequence 다이어그램으로 그려본 적이 있습니다. 그러자 동기와 비동기의 경계가 한눈에 보였습니다. 임베딩 생성(Gemini 호출)은 발행을 블로킹합니다. 벡터가 돌아와야 다음으로 넘어갈 수 있기 때문입니다. 반면 ISR 재검증은 fire-and-forget입니다. 응답을 기다리지 않고 던져둔 채 사용자에게 먼저 200을 돌려줍니다.

sequenceDiagram
    autonumber
    participant U as Admin
    participant API as Backend
    participant G as Gemini
    participant DB as MongoDB
    participant WEB as Next.js
    U->>API: 발행 요청
    API->>G: 임베딩 생성(동기)
    G-->>API: 벡터
    API->>DB: 저장
    Note over API,WEB: 비동기 — fire-and-forget
    API-)WEB: ISR 재검증
    API-->>U: 200 OK

돌이켜 보면, 같은 발행 과정을 Flowchart로 그렸을 때는 '임베딩 생성 → 저장 → 재검증'이라는 순서만 보였습니다. '무엇이 무엇을 기다리는가'는 보이지 않았습니다. Sequence로 옮기고 나서야 비로소 그 경계가 또렷해졌다는 생각이 들었습니다.

둘 중 무엇을 고를 것인가

결국 두 다이어그램은 경쟁 관계가 아니라 서로 다른 질문에 답하는 도구입니다. 무엇을 보고 싶은지가 정해지면, 어느 쪽을 그릴지도 자연스럽게 따라옵니다.

단순한 절차나 조건 분기를 정리할 때는 Flowchart가 빠르고 분명합니다. 반대로 여러 서비스가 서로 호출을 주고받고, 그중 무엇이 무엇을 기다리는지가 중요할 때는 Sequence 다이어그램이 진가를 발휘합니다.

흐름을 보는 두 방식을 살펴봤으니, 다음 편에서는 시선을 옮겨보려 합니다. 흐름이 아니라 상태와 구조를 그리는 다이어그램, 즉 State·ER·Class 다이어그램에 대한 이야기로 이어가겠습니다.

※ 이 글의 다이어그램은 Mermaid 소스로 보여드렸습니다. 블로그가 아직 Mermaid를 직접 렌더하지 않기 때문인데, 렌더된 이미지는 이후 보강할 예정입니다.