Activity Diagram이란 무엇이고, 언제 그릴까?

소프트웨어 모델링을 공부하다 보면
UML(Unified Modeling Language)이라는 말을 정말 자주 보게 된다.

그중에서도 이번에 정리할 것은 Activity Diagram이다.

처음 Activity Diagram을 봤을 때는

"그냥 순서도(Flowchart)랑 비슷한 거 아닌가?"

라는 생각이 들었다.

실제로 둘은 꽤 비슷하게 생겼다.

하지만 Activity Diagram은 단순히

A를 하고
↓
B를 하고
↓
C를 한다

정도의 실행 순서만 표현하는 것이 아니다.

조건에 따라 흐름이 나뉘거나,
여러 작업이 병렬적으로 진행되거나,
Action 사이에서 어떤 데이터가 전달되는지까지 표현할 수 있다.

이번 글에서는 Activity Diagram이 무엇인지부터
각 구성 요소가 어떤 역할을 하는지 하나씩 정리해보고자 한다.

---

Activity Diagram이란?

Activity Diagram은 UML에서

시스템이나 비즈니스 프로세스의 작업 흐름(Workflow)을 표현하는 Diagram

이라고 볼 수 있다.

쉽게 말하면

어떤 일이 시작되고
↓
어떤 작업들이 수행되고
↓
어떤 조건에서 흐름이 나뉘고
↓
어떤 작업들이 동시에 수행되고
↓
어디에서 끝나는가

를 시각적으로 표현하는 것이다.

예를 들어 쇼핑몰의 주문 과정을 생각해보자.

상품 선택
↓
주문서 작성
↓
결제
↓
주문 완료

단순하게 보면 이런 흐름이지만 실제 시스템에서는 조금 더 복잡하다.

상품 선택
↓
주문서 작성
↓
결제 성공?
├─ Yes → 주문 완료
└─ No  → 결제 재시도

주문이 완료된 뒤에는

고객에게 알림 전송
재고 감소
주문 기록 저장

같은 작업들이 동시에 또는 서로 다른 흐름으로 수행될 수도 있다.

Activity Diagram은 이런 전체적인 행동의 흐름을 표현하기 좋다.

---

Activity Diagram은 언제 그릴까?

Activity Diagram은 특히 다음과 같은 상황에서 유용하다.

1. 비즈니스 프로세스를 표현할 때

예를 들어 쇼핑몰 주문 프로세스가 있다.

상품 선택
↓
주문
↓
결제
↓
배송

이런 Workflow를 개발자뿐만 아니라
기획자나 비개발자와 함께 확인해야 할 때 Activity Diagram이 꽤 직관적이다.

2. Use Case의 내부 흐름을 자세히 표현할 때

Use Case Diagram에서

사용자 → 상품 주문

이라고만 표현하면
"상품 주문" 내부에서 실제로 어떤 일이 일어나는지는 알 수 없다.

Activity Diagram을 사용하면

상품 선택
↓
주문서 작성
↓
결제
↓
결제 성공 여부 확인
↓
주문 완료

처럼 내부 흐름까지 구체화할 수 있다.

3. 복잡한 조건 분기를 표현할 때

프로그램에서 if, else, switch 같은 조건 분기가 많아지면
코드만 보고 전체 흐름을 이해하기 어려울 수 있다.

Activity Diagram에서는 Decision Node를 이용해

결제 성공?
├─ Yes → 주문 완료
└─ No  → 재시도

처럼 표현할 수 있다.

4. 병렬적으로 진행되는 작업을 표현할 때

하나의 작업이 끝난 뒤 여러 일이 독립적으로 진행될 수도 있다.

예를 들어 주문 완료 후

알림 전송
재고 감소
포인트 적립

이 병렬적으로 진행될 수 있다.

이런 흐름은 Fork / Join Node를 이용해서 표현할 수 있다.

---

Activity Diagram의 구성 요소

Activity Diagram에서 자주 사용하는 구성 요소는 다음과 같다.

Action / Activity
Object Node
Control Flow
Object Flow
Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node

처음 보면 꽤 많아 보인다.

그래서 나는 다음과 같이 묶어서 이해하는 것이 편했다.

실제 작업
→ Action / Activity

흐름
→ Control Flow / Object Flow

데이터
→ Object Node

시작과 종료
→ Initial / Final

조건 분기
→ Decision / Merge

병렬 처리
→ Fork / Join

---

Action / Activity

가장 먼저 실제로 수행하는 작업을 표현하는
Action이 있다.

예를 들어 다음과 같은 것들이다.

상품을 선택한다.
주문서를 작성한다.
결제를 진행한다.
주문을 취소한다.

보통 Action의 이름은

동사 + 명사

형태로 작성하면 무엇을 수행하는지 이해하기 쉽다.

예를 들어

상품 선택
결제 진행
재고 확인
주문 저장

같은 식이다.

Action과 Activity는 같은 것일까?

처음에는 이 둘이 조금 헷갈렸다.

Diagram에서 비슷한 둥근 사각형 형태로 표현되는 경우가 많기 때문이다.

하지만 개념적으로는 차이가 있다.

Action

Action은 하나의 Activity 안에서 실행되는
더 이상 세분화하지 않고 하나의 실행 단위로 보는 작업이다.

예를 들어

상품 선택
결제 진행
주문 저장

같은 작업이다.

Activity

Activity는 여러 Action이나 다른 제어 흐름을 포함할 수 있는
전체적인 행동 또는 Workflow에 가깝다.

예를 들어

상품 주문

이라는 Activity 안에는

상품 선택
↓
주문서 작성
↓
결제
↓
주문 완료

라는 여러 Action이 포함될 수 있다.

즉,

Activity
→ 전체적인 행동 흐름

Action
→ 그 안에서 수행되는 하나의 실행 단위

정도로 이해하면 편하다.

다만 실제 UML 모델링에서는 Activity 안에 다른 Activity를 호출하는 Action이 존재할 수도 있기 때문에
단순히 "Activity는 큰 것, Action은 작은 것"이라고만 외우기보다

Action은 실행되는 하나의 Node이고, Activity는 전체 Behavior의 흐름을 정의한다

정도로 이해하는 것이 더 정확하다.

---

Object Node

Object Node는

Activity 안에서 Action이 사용하거나 만들어내는 데이터 또는 객체

를 표현한다.

예를 들어 주문 과정을 생각해보자.

[주문 생성]
      ↓
  주문 정보
      ↓
[결제 처리]

여기에서

주문 정보

가 Object Node다.

즉,

Action
↓
데이터 생성
↓
다른 Action에서 사용

되는 흐름에서
중간의 데이터 자체를 표현한다고 보면 된다.

코드로 생각하면 더 쉽다

예를 들어 Java 코드가 다음과 같다고 해보자.

Order order = createOrder();

pay(order);

createOrder()에서

Order 객체

가 만들어진다.

그리고 그 객체가

pay(order)

에 전달된다.

Activity Diagram에서는 이 order와 같은 객체를
Object Node로 표현할 수 있다.

---

Control Flow

Control Flow는

Action이 어떤 순서로 실행되는지를 나타내는 화살표

다.

예를 들어

[상품 선택]
      ↓
[주문서 작성]
      ↓
[결제 진행]
      ↓
[주문 완료]

가 있다면
각 Action 사이의 화살표가 Control Flow다.

쉽게 말하면

"다음에 무엇을 실행하지?"

를 표현한다.

---

Object Flow

Object Flow는 Control Flow와 비슷하게 화살표를 사용하지만
의미가 조금 다르다.

Object Flow는

Object나 Data가 Action 사이에서 어떻게 전달되는지를 나타낸다.

예를 들어

[주문 생성]
      │
      ▼
 ┌─────────┐
 │ 주문 정보 │
 └─────────┘
      │
      ▼
[결제 처리]

이 흐름에서

주문 정보 → 결제 처리

처럼 데이터가 전달되는 흐름이 Object Flow다.

앞에서 봤던 코드로 생각하면

Order order = createOrder();

pay(order);

에서 order 객체가 pay()로 전달되는 흐름이라고 볼 수 있다.

Control Flow와 Object Flow의 차이

구분	의미	핵심 질문
Control Flow	실행 순서	"다음에 무엇을 실행하지?"
Object Flow	데이터 전달	"어떤 데이터가 어디로 넘어가지?"

---

Control Node

Activity Diagram에는 작업 자체를 수행하지 않고
Flow를 제어하는 Node들이 있다.

대표적으로 다음 여섯 가지다.

Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node

처음에는 이름이 많아서 헷갈렸는데
세 쌍으로 묶어서 생각하면 상당히 편하다.

시작 / 종료
→ Initial ↔ Final

조건 분기
→ Decision ↔ Merge

병렬 처리
→ Fork ↔ Join

---

Initial Node

Initial Node는

Activity가 시작되는 지점

이다.

검은색 원으로 표현한다.

●
│
▼
[상품 선택]

즉,

여기서부터 Activity가 시작된다.

라는 의미다.

---

Final Node

Final Node는

Activity 전체가 종료되는 지점

을 의미한다.

보통 다음과 같이 표현한다.

[주문 완료]
     │
     ▼
     ◉

전체 흐름으로 보면

● 시작
↓
[상품 선택]
↓
[결제]
↓
[주문 완료]
↓
◉ 종료

가 된다.

즉,

Initial Node
→ 시작

Activity Final Node
→ Activity 전체 종료

라고 이해하면 된다.

Final Node에서 하나 주의할 점

UML에는 실제로 종료 Node가 하나만 있는 것은 아니다.

대표적으로

Activity Final Node
Flow Final Node

가 있다.

Activity Final Node

Activity 전체를 끝낸다.

◉

Flow Final Node

해당 Flow 하나만 종료한다.

다른 병렬 Flow는 계속 진행될 수 있다.

처음 Activity Diagram을 배울 때는
대부분 Activity Final을 기준으로 배우지만,

병렬 처리까지 복잡하게 다루게 되면
이 둘을 구분할 필요가 있다.

---

Decision Node

Decision Node는

조건에 따라 실행 경로를 나누는 Node

다.

마름모로 표현한다.

예를 들어

        ◇ 결제 성공?
       /              [성공]          [실패]
     ↓               ↓
[주문 완료]      [결제 재시도]

와 같이 표현할 수 있다.

프로그래밍에서 생각하면 if-else와 상당히 비슷하다.

Guard Condition

Decision Node에서 분기되는 각 경로에는
보통 Guard Condition을 작성한다.

UML에서는 일반적으로

[조건]

형태로 표시한다.

예를 들어

[결제 성공]
[결제 실패]

처럼 표현할 수 있다.

즉 Decision Node에서 중요한 것은

각 분기 조건이 명확하게 정의되어 있어야 한다

는 것이다.

---

Merge Node

Merge Node는

여러 개의 대체 경로를 다시 하나의 흐름으로 합치는 Node

다.

예를 들어 결제 방법에 따라 흐름이 나뉜다고 해보자.

           ◇ 결제 방법?
          /               [카드 결제]     [계좌 결제]
          \           /
           \         /
               ◇
               │
               ▼
          [주문 완료]

첫 번째 마름모는

Decision Node

이고,

두 번째 마름모는

Merge Node

다.

모양은 동일하지만 역할은 완전히 다르다.

Decision
→ 하나의 Flow를 여러 대안으로 나눈다.

Merge
→ 여러 대안 Flow를 하나로 합친다.

---

Fork Node

Fork Node는

하나의 Flow를 여러 개의 병렬적인 Flow로 나누는 Node

다.

굵은 막대로 표현한다.

예를 들어 주문이 완료된 뒤

고객에게 알림 전송
재고 감소

두 작업을 병렬적으로 진행한다고 해보자.

          [주문 완료]
               │
        ━━━━━━━━━━━━━
          │         │
          ▼         ▼
     [알림 전송]  [재고 감소]

가운데 굵은 막대가 Fork Node다.

Decision과 Fork의 차이

Decision

A 또는 B

Fork

A 그리고 B

따라서

Decision
→ OR

Fork
→ AND

라고 기억하면 상당히 편하다.

다만 Fork는 "CPU가 반드시 정확히 같은 순간에 두 작업을 실행한다"는 뜻이라기보다
UML 의미상 서로 독립적으로 진행될 수 있는 Concurrent Flow를 표현한다고 이해하는 것이 더 정확하다.

---

Join Node

Join Node는 Fork의 반대다.

Fork로 나뉜 여러 Flow가 모두 끝난 뒤 다시 하나의 Flow로 합쳐지는 Node

다.

          [주문 완료]
               │
        ━━━━━━━━━━━━━
          │         │
          ▼         ▼
     [알림 전송]  [재고 감소]
          │         │
          ▼         ▼
        ━━━━━━━━━━━━━
               │
               ▼
        [주문 기록 저장]

위쪽 막대가 Fork,
아래쪽 막대가 Join이다.

정리하면

Fork
→ 여러 Flow를 시작한다.

Join
→ 여러 Flow가 끝날 때까지 기다린 뒤 다음으로 진행한다.

---

Merge와 Join도 다르다

이 둘 역시

여러 Flow를 하나로 합친다.

라는 점 때문에 헷갈릴 수 있다.

하지만 의미가 다르다.

Merge

여러 경로 중 실제로 실행된 하나의 경로가 들어오면
다음 Flow로 진행한다.

A 또는 B
↓
Merge

Join

여러 병렬 Flow가 모두 끝날 때까지 기다린다.

A 그리고 B
↓
Join

즉,

Merge
→ OR를 다시 합친다.

Join
→ AND를 다시 합친다.

라고 생각하면 된다.

---

Control Node를 한 번에 정리하면

Node	역할
Initial	Activity 시작
Final	Activity 종료
Decision	조건에 따라 Flow 분기
Merge	대안 Flow를 다시 하나로 합침
Fork	하나의 Flow를 병렬 Flow로 분리
Join	병렬 Flow가 모두 끝난 뒤 하나로 합침

그리고 세 쌍으로 기억하면 된다.

Initial ↔ Final
시작 / 종료

Decision ↔ Merge
분기 / 병합

Fork ↔ Join
병렬 시작 / 병렬 종료

---

Activity Diagram을 볼 때 던질 질문

구성 요소를 전부 외우려고 하면
생각보다 헷갈린다.

그래서 나는 각 요소를 다음 질문과 연결해서 기억하려고 한다.

Action
→ "무엇을 하는가?"

Control Flow
→ "다음에 무엇을 하는가?"

Object Node
→ "어떤 데이터가 존재하는가?"

Object Flow
→ "그 데이터가 어디로 이동하는가?"

Decision / Merge
→ "조건에 따라 어디로 갈 것인가?"

Fork / Join
→ "어떤 작업들이 병렬적으로 진행되는가?"

Initial / Final
→ "어디서 시작하고 어디서 끝나는가?"

---

Activity Diagram과 Flowchart는 무엇이 다를까?

처음 Activity Diagram을 보면
Flowchart와 상당히 비슷해 보인다.

실제로 둘 다

작업
조건
분기
흐름

을 표현한다.

하지만 Activity Diagram은 UML의 일부이기 때문에
소프트웨어 시스템의 Behavior를 모델링하는 데 조금 더 초점이 맞춰져 있다.

특히 다음 요소들을 명확하게 표현할 수 있다.

Object Flow
Concurrent Flow
Fork / Join
Activity / Action
UML의 다른 Diagram과의 연계

그래서 단순한 알고리즘 순서만 표현한다면
Flowchart로도 충분할 수 있다.

하지만

비즈니스 Workflow
Use Case 내부 동작
데이터 전달
병렬 처리
복잡한 시스템 Behavior

를 모델링한다면 Activity Diagram이 더 적합할 수 있다.

---

언제 Activity Diagram을 그리면 좋을까?

모든 기능마다 Activity Diagram을 그릴 필요는 없다고 생각한다.

예를 들어

getUserName()

처럼 정말 단순한 메서드 하나를 설명하기 위해
Activity Diagram까지 만드는 것은 오히려 과할 수 있다.

Activity Diagram은 다음과 같은 상황에서 특히 가치가 있다.

조건 분기가 많다.

여러 시스템 또는 기능이 연결된다.

작업 순서가 중요하다.

병렬적으로 실행되는 작업이 있다.

데이터 전달 흐름까지 확인해야 한다.

비개발자와 Workflow를 공유해야 한다.

즉,

코드 한 줄 한 줄을 설명하는 Diagram이라기보다
시스템의 행동 흐름 전체를 이해하기 위해 그리는 Diagram

이라고 생각하면 될 것 같다.

---

정리하면서 느낀 점

처음 Activity Diagram의 구성 요소를 봤을 때는

Initial Node
Final Node
Decision Node
Merge Node
Fork Node
Join Node
Object Node
Object Flow
Control Flow
...

처럼 용어가 너무 많아서
정의를 하나씩 외워야 하나 싶었다.

그런데 실제 Workflow에 적용해서 생각해보니
생각보다 구조는 단순했다.

작업한다.

순서대로 이동한다.

데이터를 전달한다.

조건에 따라 나뉜다.

다시 합친다.

병렬적으로 실행한다.

모두 끝나면 다시 합친다.

종료한다.

결국 우리가 프로그램을 작성하면서
평소 코드로 표현하던 것을 그림으로 바꾼 것에 가깝다.

if
→ Decision

if 종료
→ Merge

병렬 처리
→ Fork

모두 완료될 때까지 대기
→ Join

메서드 실행
→ Action

객체 전달
→ Object Flow

이런 식으로 코드와 연결해서 생각하니
각 Node의 의미가 훨씬 쉽게 들어왔다.

---

결론

Activity Diagram은

시스템이나 비즈니스 프로세스에서 어떤 작업들이 어떤 순서와 조건으로 수행되는지를 표현하는 UML Behavior Diagram

이라고 정리할 수 있다.

핵심 구성 요소를 다시 압축하면 다음과 같다.

Action / Activity
→ 무엇을 하는가?

Control Flow
→ 다음에 무엇을 하는가?

Object Node / Object Flow
→ 어떤 데이터가 어디로 이동하는가?

Decision / Merge
→ 어떤 조건으로 흐름이 나뉘고 다시 합쳐지는가?

Fork / Join
→ 어떤 작업이 병렬적으로 진행되고 언제 다시 합쳐지는가?

Initial / Final
→ Activity가 어디서 시작하고 어디서 끝나는가?

정의를 달달 외우기보다는
실제 주문 Process 같은 예시를 하나 그려보면서

이건 Action인가?

이 화살표는 Control Flow인가 Object Flow인가?

여기서는 Decision인가 Fork인가?

다시 합칠 때 Merge인가 Join인가?

를 하나씩 판단해보는 것이 훨씬 이해하기 좋은 것 같다.

Activity Diagram을 그리는 목적도 결국 하나다.

코드로 들어가기 전에 시스템의 행동 흐름을 사람이 이해할 수 있는 형태로 만드는 것.

이 관점만 기억하면
각 구성 요소가 왜 필요한지도 자연스럽게 이해할 수 있을 것 같다.