BPMN 배타적·병렬 게이트웨이 차이: 주문 확인 예시

배타적 게이트웨이는 하나의 경로를 선택합니다. 병렬 게이트웨이는 모든 출력 경로를 시작합니다. 이 차이는 경로가 다시 만나는 지점에서 특히 중요합니다. 배타적 병합은 동시에 진행되는 다른 작업을 기다리지 않지만, 병렬 합류는 기다립니다.

공유 플로우차트 작업 공간에서 프로세스를 그릴 때는 마름모를 고르기 전에 업무 규칙을 적으세요. 주문 확인 예시를 통해 ‘방문 수령 또는 배송’과 ‘결제 및 재고 확인’이 같은 두 갈래로 보이더라도 왜 다른 동작이 필요한지 살펴봅니다.

게이트웨이 동작 비교하기

BPMN은 Business Process Model and Notation의 약자입니다. 게이트웨이 기호는 단순한 도형이 아니라 프로세스의 동작을 설명합니다. OMG BPMN 명세는 관련 분기와 병합의 의미를 정의합니다.

토큰은 프로세스 인스턴스의 진행 상태를 이해하기 위한 개념입니다. 아래 예시에서는 활성 경로를 따라 작은 표시를 옮긴다고 생각하면 됩니다. 고객 레코드나 재고 품목을 뜻하는 것은 아닙니다.

Camunda의 배타적 게이트웨이 문서는 경로 선택과 도착한 토큰을 그대로 통과시키는 병합을 설명합니다. 병렬 게이트웨이 문서는 모든 출력 경로를 시작하고 합류점에서 입력 경로들을 기다리는 동작을 설명합니다. 논리적인 동시 진행이 두 직원이나 기계가 정확히 같은 순간에 작업한다는 뜻은 아닙니다.

방문 수령과 배송 선택에는 배타적 게이트웨이 사용하기

수령 방법이 방문 수령 또는 배송으로 이미 기록된 주문을 생각해 봅시다. 주문을 받은 뒤 프로세스는 ‘수령 방법은?’을 판단합니다. 한 경로에서는 방문 수령 안내를 준비하고, 다른 경로에서는 배송 정보를 준비합니다.

이 주문에서는 두 경로 중 하나만 실행되어야 합니다. 경로에 ‘방문 수령’과 ‘배송’을 표시하고 배타적 게이트웨이를 사용하세요. 다음 단계로 넘어가기 전에 배타적 병합으로 경로를 합칠 수 있습니다.

방문 수령 주문 하나를 따라가 봅시다. 표시 하나가 방문 수령 경로를 지나 병합 지점에 도착하고 계속 진행합니다. 배송 경로는 선택되지 않았으므로 그쪽에서 도착할 토큰을 기다리지 않습니다.

누락되거나 예상하지 못한 데이터의 처리 방식도 정하세요. 수령 방법을 고르지 않았는데 우연히 ‘배송’으로 처리되어서는 안 됩니다. 명시적인 확인 경로를 추가하거나 이 판단 전에 유효한 사전 조건을 마련합니다. 실행 가능한 모델에서는 조건과 기본 흐름을 의도적으로 설정해야 합니다. 라벨만으로 실행 규칙이 만들어지지는 않습니다.

결제와 재고 확인에는 병렬 게이트웨이 사용하기

이번에는 주문을 준비하기 전에 결제 상태와 재고를 모두 확인해야 한다고 가정해 봅시다. 이 예시에서는 한 확인을 시작하는 데 다른 확인의 결과가 필요하지 않습니다. 병렬 분기는 ‘결제 확인’과 ‘재고 확인’ 경로를 모두 활성화합니다.

병렬 합류점에서는 두 확인이 완료될 때까지 주문이 기다립니다. 결제 확인이 먼저 끝나면 해당 토큰이 합류점에서 대기합니다. 재고 확인도 끝나면 합류점은 도착한 두 토큰을 소비하고 하나의 토큰을 다음으로 보낼 수 있습니다.

완료와 승인은 다릅니다. 재고 확인이 완료되어도 결과는 ‘재고 없음’일 수 있고, 결제 확인의 결과는 ‘미확인’일 수 있습니다. 합류 뒤에 별도의 판단을 두어 기록한 결과를 검토하세요. 합류점은 완료 시점을 맞출 뿐, 주문을 준비해도 된다고 결정하지 않습니다.

이 단계를 간단히 정리하면 두 확인 시작 → 두 결과 대기 → 주문을 진행할 수 있는지 판단입니다. 두 결과가 모두 조건을 충족하면 주문을 준비합니다. 그렇지 않으면 필요한 해결 작업으로 보냅니다.

잘못된 합류 패턴 두 가지 찾기

활동은 맞지만 합치는 방식이 틀린 그림은 쉽게 오해를 만듭니다. 그림의 대칭성으로 판단하지 말고 주문 하나를 추적하세요.

이것은 꾸밈의 문제가 아니라 동작의 문제입니다. 마름모 안의 기호를 바꾸면 프로세스가 무한히 기다리거나, 너무 일찍 진행하거나, 같은 작업을 여러 번 시작할 수 있습니다.

그렇다고 ‘항상 같은 게이트웨이끼리 짝지어야 한다’로 단순화하지 마세요. 실제 프로세스에는 중첩된 판단, 반복, 별도로 끝나는 경로가 있을 수 있습니다. 어느 경로에서 실제로 토큰이 도착할 수 있는지, 계속 진행하기 전에 무엇이 필요한지를 기준으로 합치는 방식을 정해야 합니다. 기호를 맞추는 것만으로 이 판단을 대신할 수는 없습니다.

확인이 정상적으로 끝나지 못하는 경우 고려하기

재고 서비스를 사용할 수 없다면 어떻게 될까요? 그림에서 그 경로를 없애기만 하면 결제 토큰이 합류점에서 기다리게 됩니다. 결과를 얻을 수 없을 때 ‘확인 완료’가 무엇을 의미하는지 정해야 합니다.

상위 수준의 업무 흐름도에서는 재고 작업이 ‘알 수 없음 — 검토 필요’라는 명시적인 결과로 끝날 수 있습니다. 합류 뒤의 판단은 이를 재고 있음으로 처리하지 않고 해결 작업으로 보냅니다. 실행 가능한 BPMN 모델에는 엔진과 업무 요구에 맞는 오류, 시간 초과, 취소, 재시도 처리가 필요합니다.

주문 전체를 기다리게 할지, 수동 검토로 넘길지, 중단할지라는 업무 질문이 먼저입니다. 실제로 승인된 프로세스가 아니라면 실패한 확인을 합류점 밖으로 우회시켜 곧바로 ‘주문 준비’에 연결하지 마세요. 동기화를 건너뛰면 두 확인을 둔 이유가 무너질 수 있습니다.

Boardmix에서 함께 프로세스 추적하기

Boardmix 캔버스에 두 영역을 명확히 나누어 만듭니다. 첫 번째에는 방문 수령과 배송의 배타적 선택 및 병합을 놓습니다. 두 번째에는 결제와 재고의 병렬 확인 및 합류, 그리고 결과에 대한 판단을 놓습니다.

무엇을 하는지 드러나는 짧은 작업 이름, 잘 보이는 게이트웨이 표시, 대안 경로 옆의 라벨을 사용하세요. 그림 아래에는 수동으로 경로를 추적할 공간을 남깁니다. 작은 도형 하나를 방문 수령 경로로 옮긴 뒤, 병렬 확인에는 두 도형을 사용합니다. 보드에서는 논리를 논의하고, 실행 가능한 프로세스는 BPMN 엔진에서 실행하세요.

Boardmix에서 보드를 열고 실제 확인 업무를 하는 사람들과 함께 예시를 따라가 보세요. 어디에서 결과가 누락될 수 있는지, 어떤 작업이 독립적으로 시작될 수 있는지, 다음 작업 전에 무엇을 알아야 하는지 살펴봅니다.

업무 규칙이 ‘해당하는 확인을 하나 이상 실행한다’라면 단순한 배타적 선택이나 무조건적인 병렬 분기만으로는 충분히 표현할 수 없습니다. 그 규칙을 명시하고 적절한 조건부 분기 모델을 검토하세요. 화살표 두 개를 그린다고 하나, 둘 다, 또는 조건에 따라 달라지는 일부 경로 중 무엇을 실행할지가 결정되지는 않습니다.