UML 행위 다이어그램으로 업무 흐름과 예외를 설계하는 법

흐름 자체를 설계 대상으로 다루는 UML 모델

업무 프로세스나 서비스 로직은 정상 경로만으로 설명되지 않는다. 조건에 따른 분기, 여러 작업의 병행, 실패 뒤의 보상 처리, 주체가 바뀌는 핸드오프까지 함께 검토해야 한다.

UML 행위 다이어그램(Activity Diagram)은 UML의 동작(Behavior) 다이어그램 계열에 속하며, 활동(Activity) 사이의 제어 흐름과 데이터 흐름을 표현한다. 시작과 종료, 분기와 병합, 포크와 조인, 예외, 스윔레인 같은 표기법을 사용한다.

상태 다이어그램이 객체의 상태 전이에 집중한다면, 행위 다이어그램은 작업이 어떤 순서와 조건으로 진행되고 어디서 병행되는지를 다룬다. 단순 플로우차트보다 동시성·예외·책임 구분을 표현하기 좋다.

사용자 시나리오, 비즈니스 프로세스, 서비스 내부 로직, 배치와 파이프라인처럼 절차가 있는 대상을 모델링할 수 있다. 단일 시스템 안의 흐름뿐 아니라 여러 주체가 나눠 맡는 책임도 레인으로 분리해 보여준다.

제어 흐름과 데이터 흐름을 함께 읽기

행위 다이어그램은 활동 노드(Activity), 액션(Action), 시작·종료 노드, 객체 노드(Object Node)로 구성한다. 노드는 제어 흐름(Control Flow)과 객체 흐름(Object Flow) 엣지로 연결된다. 입력·출력 핀(Pin)을 두면 어떤 데이터가 어떤 작업에 의존하는지, 데이터 전달과 순서가 어떻게 이어지는지를 명시할 수 있다.

조건 분기와 병합에는 다이아몬드 노드를 사용한다. 가드 조건 [condition]은 특정 경로가 활성화되는 조건을 드러낸다. 조건은 상호 배타적으로 두고 else 경로까지 정의해야 누락된 흐름을 줄일 수 있다.

병렬 처리는 포크(Fork)로 갈라지고 조인(Join)에서 다시 동기화된다. JoinSpec으로 동기화 조건을 기술할 수도 있다. 이 구간에서 공유 자원에 접근한다면 보호구간(Critical Region) 같은 표현으로 경합을 드러내야 한다.

스윔레인은 액터, 시스템, 팀 단위의 책임과 경계를 나누는 데 쓴다. 내부와 외부 시스템 사이의 핸드오프를 파악하기 쉬워지며, 교차 레인 흐름을 줄이는 과정은 결합도를 낮추는 설계 검토로 이어진다. 인터럽트 가능 영역, 예외 핸들러, 신호·타이머 이벤트는 비정상 흐름을 표현한다. 트랜잭션적 구간은 롤백이나 보상(Compensation) 설계의 근거가 된다.

요구사항에서 테스트 시나리오까지 연결하는 과정

다이어그램을 시작할 때는 요구사항과 유스케이스, 비즈니스 규칙, API·이벤트 스키마 같은 인터페이스 계약을 모은다. 성능 SLO, 트랜잭션 경계, 보안과 감사 요구도 제약조건으로 함께 확인한다.

그다음 활동을 식별하고 레인을 정한 뒤, 행위 단위로 나눠 제어·데이터 흐름을 연결한다. 분기 가드, 예외, 타임아웃을 빠뜨리지 않고 적는다. 병렬 작업은 포크와 조인으로 표현하며, 공유 자원에는 보호구간과 락 정책 어노테이션을 둔다.

완성된 모델은 경로 완전성을 검토하는 아티팩트가 된다. 모든 분기에 종료 경로가 있는지, 가드가 실제로 충족될 수 있는지, 데드락과 라이브락 위험은 없는지를 확인한다. 정상·경계·예외 경로에서 테스트 시나리오를 도출하고, 각 경로가 요구하는 데이터 조건도 정리할 수 있다.

주문 처리에서 병렬 작업과 실패 경로 표현하기

고객, 시스템, 결제·배송 작업이 얽힌 주문 처리 흐름은 행위 다이어그램으로 표현하기 적합하다. 재고가 부족하면 취소로 이어지고, 결제 승인과 배송 준비는 병렬로 진행되며, 결제 실패에는 보상 트랜잭션 또는 재시도 경로가 필요하다. 결제와 배송이 끝난 뒤 송장을 발행하는 지점은 조인 효과를 구현한다.

⤢✕

설계·운영에서 쓰이는 장면

마이크로서비스 환경에서는 사가(Saga)의 보상 흐름을 설계하고, 타임아웃과 재시도 규칙을 합의하는 데 활용할 수 있다. 프런트엔드와 백엔드 사이에서는 UX 흐름과 API 계약을 맞추는 공통 문서가 된다.

데이터·배치 파이프라인에서는 ETL 단계, 실패 분기, 재처리 정책을 모델링하고 SLA 기반 동시성 및 리소스 경합을 표시할 수 있다. 테스트와 운영에서는 정상·예외 경로 기반의 테스트 케이스 세트를 만들고, 릴리스 런북과 장애 대응 플레이북을 시각화하는 기반으로 쓴다.

요구-설계 정합성은 결함 유입률 2040% 감소와 변경 영향 분석 시간 30% 단축으로 이어질 수 있다(내부 사례치 기준). 이해관계자 합의 리드타임은 25% 이상 단축되고, 온보딩 기간은 1530% 단축될 수 있다. 예외와 보상 경로를 미리 정의하면 장애 대응 MTTR도 20% 개선될 수 있다.

플로우차트와 BPMN 사이에서의 선택

구분	성능	확장성	일관성	안정성	운영 편의
UML Activity Diagram	의사소통 효율 높음(개발·설계 중심)	동시성/스윔레인으로 대규모 모델 확장 가능	UML 표준/검토 체크리스트로 일관 유지	도구/검증 룰 성숙, 모델 오류 탐지 용이	개발자 친화, 비즈니스에겐 약간 난이도
Flowchart	단순 업무엔 빠름, 복잡도 증가 시 급격히 저하	병렬/예외 표현 한계로 대형화 취약	표준 미약, 작성자 편차 큼	단순성 장점이나 누락 위험 상존	보편 도구, 교육 부담 낮음
BPMN 2.0	비즈니스 합의 성능 우수, 이벤트 표현 강력	풀/레인/이벤트로 엔터프라이즈급 적합	표준 엄격, 실행 가능 모델과 연계	시뮬레이션/엔진 연계로 견고	러닝커브 높음, 도구 종속성 가능

비즈니스 주도의 합의가 핵심이라면 BPMN 채택을 검토할 수 있다. 반대로 개발 중심의 내부 로직을 다룬다면 행위 다이어그램이 맞는다. 플로우차트는 프로토타이핑이나 교육용으로 가볍게 사용할 수 있다.

모델을 과도하게 키우지 않는 규칙

액션을 지나치게 잘게 나누기보다 한 다이어그램에 20~40 노드를 권장하고, 세부 내용은 하위 다이어그램으로 분리한다. 가드 조건과 else 경로를 빠짐없이 두는 것도 기본 규칙이다.

포크와 조인 경계에는 트랜잭션 범위를 주석으로 남기고, 보상·재시도 정책을 함께 적는다. 공유 자원에는 보호구간이나 락 정책을 표시한다. 병렬 처리 표기가 많아질수록 병목과 교착 가능성을 함께 검토해야 한다.

조직 차원에서는 표기 규칙과 검토 체크리스트를 먼저 마련한 뒤 점진적으로 적용하는 편이 좋다. 행위 다이어그램은 요구, 설계, 테스트를 하나의 흐름 모델로 연결하면서 변경 대응력과 운영 안정성을 높이는 도구다.