동적 모델링

정지 화면에서 동영상으로

7장의 자료흐름도는 정지 화면에 가까웠다. 손님의 주문 정보가 어떤 프로세스를 거쳐 어떤 데이터로 바뀌는지는 보여주지만, "그 주문이 지금 어떤 상태에 놓여 있는가", "그 상태가 언제 다음 상태로 넘어가는가"는 자료흐름도만으로는 알 수 없다. 이번 장에서 다루는 동적 관점이 바로 이 빈틈을 채운다. 시간이 흐르면서 시스템이 어떻게 변화하는지, 그 변화를 무엇이 일으키는지를 다루는 관점이다.

책마루 온라인 주문 시스템에서 주문 하나를 떠올려보자. 손님이 주문을 넣는 순간부터 실제로 물건을 받기까지, 이 주문은 가만히 있지 않는다. "접수됨"에서 시작해 "재고 확인 중"을 거쳐 "포장 중", "배달 중", 마침내 "배달 완료"에 이른다. 재고가 부족하면 중간에 "품절 취소"로 빠질 수도 있다. 이렇게 어떤 대상이 시간에 따라 거치는 국면들과, 그 국면 사이를 오가게 만드는 계기를 정리하는 일이 동적 모델링이다.

실시간 시스템에서 동적 모델링이 특히 중요한 이유

시스템 중에는 외부 환경과 실시간으로 상호작용해야 하는 것들이 있다. 정해진 시간 안에 외부에서 온 자극에 반응해야 하는 시스템을 실시간 시스템이라 부른다. 통신 시스템, 항공기 운항 관리 시스템, 원자력 발전소 제어 장치처럼 반응이 늦으면 곧바로 문제가 되는 시스템들이 대표적이다.

책마루 시스템이 원자력 발전소만큼 긴박하지는 않지만, 실시간성이 아예 없는 것도 아니다. 손님이 결제 버튼을 눌렀는데 시스템이 몇 초 안에 "주문 접수됨" 화면을 보여주지 못하면 손님은 중복 결제를 시도하거나 이탈한다. 매장 태블릿에 새 주문 알림이 늦게 뜨면 배달이 늦어져 신선식품이라면 품질 문제까지 생길 수 있다. 이런 시스템을 안정적으로 만들려면 "지금 무슨 상태인가"와 "무엇이 다음 상태로 넘어가게 만드는가"를 미리 촘촘하게 따져봐야 한다 — 동적 모델링이 필요한 이유다.

상태, 사건, 동작 — 세 가지 핵심 개념

동적 모델링에서 반드시 짚고 가야 할 세 개념이 있다.

• 상태(state): 어떤 시점에 시스템(또는 그 일부)이 놓여 있는 국면. 책마루 주문의 "포장 중"이 하나의 상태다. 상태는 시스템이 가진 속성값에 의해 결정된다.
• 사건(event): 외부에서 주어지는 자극으로, 시스템을 한 상태에서 다른 상태로 옮기는 계기가 된다. "직원이 포장 완료 버튼을 누른다"가 사건이다.
• 동작(action): 사건에 대한 반응으로 시스템이 수행하는 일. 순식간에 끝나는 동작(action)과, 시간이 걸리는 활동(activity)으로 다시 나뉜다. "포장 완료 알림을 손님에게 보낸다"는 순간적인 동작이고, "배송 중 위치를 계속 추적한다"는 시간이 걸리는 활동이다.

이 세 개념을 도식으로 표현한 것이 **상태변화도(State Transition Diagram, STD)**다. 상태변화도는 컴퓨터 과학의 유한 오토마타 개념을 확장해, 상태를 사각형(또는 둥근 사각형)으로, 사건에 의한 상태 전이를 화살표로 그린다.

시나리오에서 사건추적도로, 사건추적도에서 상태변화도로

상태변화도를 처음부터 한 번에 완성하려고 하면 놓치는 흐름이 생기기 쉽다. 실무에서는 보통 세 단계를 거쳐 상태변화도를 완성한다.

1단계 — 시나리오 작성

시나리오란 시스템이 작동하며 일어나는 사건들의 순서를 글로 풀어쓴 것이다. 보통 일반적인 경우와 예외적인 경우를 나눠서 쓴다. 책마루의 "손님이 배달 주문을 넣는다" 시나리오를 정상적인 경우로 적어보면 이렇다.

손님이 상품을 장바구니에 담는다. 손님이 배송지 우편번호를 입력한다. 시스템이 배달 가능 지역인지 확인한다. 배달 가능하면 결제 화면으로 넘어간다. 손님이 결제를 완료한다. 시스템이 재고를 확인한다. 재고가 있으면 주문이 "접수됨" 상태가 되고 매장 태블릿에 알림이 뜬다. 직원이 포장을 완료하고 "포장 완료" 버튼을 누른다. 배달원이 배달을 시작하면 주문이 "배달 중" 상태가 된다. 손님이 물건을 받으면 주문이 "배달 완료" 상태가 된다.

예외적인 경우도 별도 시나리오로 적어둔다.

손님이 상품을 장바구니에 담는다. 손님이 배송지 우편번호를 입력한다. 시스템이 배달 불가 지역이라고 안내한다. 손님이 매장 방문 수령으로 배송 방식을 변경하거나 주문을 포기한다.

2단계 — 사건추적도 그리기

시나리오를 작성했으면, 그 안에서 사건을 주고받는 객체들을 뽑아낸다. 위 시나리오에서는 "손님", "책마루 시스템", "매장 직원", "배달원"을 객체로 뽑을 수 있다. 사건추적도는 이 객체들을 세로선으로, 사건을 가로 화살표로 그려서 사건이 오가는 순서를 한눈에 보여준다.

손님          책마루 시스템        매장 직원        배달원
 |                 |                  |               |
 |--우편번호 입력-->|                  |               |
 |<--배달 가능 응답-|                  |               |
 |----결제 완료---->|                  |               |
 |                 |--재고 확인-->     |               |
 |                 |--신규 주문 알림-->|               |
 |                 |                  |--포장 완료-->  |
 |                 |                  |               |--배달 시작-->
 |<-----------------배달 완료 알림------------------------|

사건추적도가 유용한 이유는, 시나리오라는 문장 나열보다 "누가 누구에게 무엇을 보내는가"가 시각적으로 훨씬 잘 드러나기 때문이다. 사건 흐름을 놓치는 일도 줄어든다.

3단계 — 상태변화도 완성

사건추적을 끝냈으면 상태들과 사건들을 종합해 상태변화도를 그린다. 사건추적도에 나타난 사건 흐름이 그대로 상태변화도의 전이 사건으로 쓰이는 경우가 많다. 객체가 주고받는 사건과 사건 사이의 구간이 바로 그 객체의 상태가 된다.

책마루 주문의 상태변화도를 정리하면 다음과 같은 흐름이 나온다.

전이에서 나타나는 동작은 사건 뒤에 빗금(/)을 긋고 표시하는 게 관례다. 예를 들어 "재고 있음 / 매장 태블릿에 알림 전송"처럼 적으면, "재고 있음"이라는 사건이 일어날 때 "매장 태블릿에 알림 전송"이라는 동작이 함께 일어난다는 뜻이다.

표를 완성하고 나면 "빠진 상태는 없는가"를 점검하는 게 다음 순서다. 위 표만 보면 "손님이 배달 전에 주문을 취소하는 경우"가 빠져 있다는 게 눈에 띈다. 실제로 이런 예외는 시나리오 작성 단계보다 상태변화도를 그리는 이 단계에서 더 잘 드러난다 — "접수됨" 상태에서 "포장 완료" 말고 다른 사건(손님의 취소 요청)이 일어날 수 있는지를 점검하다 보면 자연스럽게 발견되기 때문이다. 이렇게 찾아낸 예외는 "접수됨 → (취소 요청) → 주문 취소됨"이라는 전이로 표에 추가하고, 다시 1단계 시나리오로 돌아가 "예외적인 경우" 항목에도 반영해준다. 시나리오·사건추적도·상태변화도 세 단계를 한 번에 끝내지 않고 서로 오가며 다듬는 것도 이 때문이다.

상태변화도의 확장 표기법

기본적인 상태-사건 표기만으로는 부족한 상황들이 있다. 몇 가지 확장 표기법을 알아두면 좀 더 정교한 모델을 그릴 수 있다.

• 상태 추상화: 여러 개의 세부 상태를 하나의 큰 상태로 묶어 표현하는 것. 책마루라면 "배송 처리 중"이라는 큰 상태 안에 "포장 완료(배달 대기)"와 "배달 중"이라는 세부 상태를 넣어 계층적으로 표현할 수 있다.
• 동시 수행: 한 상태 안에서 여러 활동이 동시에 일어나는 경우를 점선으로 나눠 표시한다. 배달 중인 주문이 "위치를 추적하는 활동"과 "예상 도착 시간을 갱신하는 활동"을 동시에 수행하는 경우가 그 예다.
• 조건 표시: 같은 사건이라도 조건에 따라 다른 전이가 일어나는 경우 대괄호로 조건을 표시한다. "재고 확인 [수량 > 0]"과 "재고 확인 [수량 = 0]"을 구분하는 식이다.
• entry/exit 동작: 어떤 상태에 들어갈 때(entry)와 나갈 때(exit) 항상 수행되는 동작을 상태 박스 안에 표기한다. "포장 완료 상태" 진입 시 항상 "직원 알림 해제" 동작이 실행되는 경우가 여기 해당한다.

구조적 분석기법의 확장 — 기능과 동적 관점을 한 그림에

7장의 자료흐름도는 데이터의 흐름만 다뤘지, 그 데이터 처리가 언제 활성화되는지는 다루지 않았다. 실시간성이 중요한 시스템에서는 데이터 흐름과 제어 흐름을 한 모델에 같이 담아야 할 때가 있는데, 이를 위해 자료흐름도에 제어 흐름과 **제어 명세서(C-Spec)**를 추가한 확장 모델을 쓴다.

제어 흐름은 점선 화살표로 표시하며, 프로세스를 활성화하거나 비활성화하는 신호를 나타낸다. 이 제어 신호가 각 프로세스를 언제 켜고 끄는지는 별도의 표로 정리하는데, 대표적인 도구가 세 가지다.

• 프로세스 활성표(PAT): 어떤 제어 신호가 주어졌을 때 어떤 프로세스가 활성화되는지 표로 정리한다.
• 결정표(DT): 여러 조건의 조합에 따라 어떤 결과가 나오는지 표로 정리한다. 조건들의 순서는 따지지 않는다.
• 상태변화도(STD): 이 장에서 다룬 상태변화도 자체를 제어 명세로 그대로 활용할 수도 있다.

책마루라면 "재고 확인 프로세스"를 활성화할지 말지를 결정표로 정리해볼 수 있다.

이렇게 기능 모델(무엇을 하는가)과 동적 모델(언제 하는가)을 한 모델 안에 결합하면, 두 관점이 따로 떨어져 있을 때보다 설계 단계에서 통합하기가 훨씬 쉬워진다. 데이터로 볼지 제어로 볼지 애매한 신호(예: 재고가 임계치 아래로 떨어졌다는 플래그)가 있다면, 일단 데이터로 가정하고 모델링을 진행하면서 필요에 따라 다시 판단해도 된다.

동적 모델을 건너뛰면 생기는 일

책마루 시스템에서 동적 모델링을 대충 하고 넘어가면 어떤 문제가 생길까? 가장 흔한 사례가 7장에서 잠깐 언급했던 재고 동시성 문제다. 매장에서 손님이 책을 집어 계산대로 가져가는 순간과, 온라인 손님이 같은 책을 장바구니에 담고 결제하는 순간이 겹칠 수 있다. 자료흐름도만 보면 "재고를 확인하고 차감한다"는 프로세스 하나로 깔끔해 보이지만, 실제로 이 프로세스가 정확히 어떤 상태를 거치는지 동적 모델로 짚어보지 않으면 문제가 숨어 있다는 사실 자체를 알아채기 어렵다.

이 지점을 상태변화도로 들여다보면 "재고 확인 중"이라는 상태가 얼마나 위태로운 구간인지 드러난다. 매장 POS가 재고를 "확인"하고 "차감"하는 사이에 온라인 시스템도 같은 상품의 재고를 "확인"할 수 있다면, 두 경로 모두 "재고 있음"으로 판정한 뒤 동시에 차감을 시도해 실제로는 하나밖에 없는 책이 두 명에게 팔리는 사고가 날 수 있다. 이 위험은 자료흐름도의 정지된 그림에서는 보이지 않고, "언제 상태가 바뀌는가"를 따지는 동적 관점에서만 드러난다. 이 문제를 실제로 어떻게 막을지(예: 재고 차감을 하나의 원자적 동작으로 묶는 것)는 설계 단계의 일이지만, "여기가 위험 구간이다"라고 미리 표시해두는 일은 분석 단계, 즉 지금 이 장에서 이미 할 수 있다.

핵심 정리

• 동적 관점은 시스템이 시간에 따라 어떤 상태를 거치고, 무엇이 그 상태 변화를 일으키는지를 다룬다. 실시간성이 중요한 시스템일수록 이 관점의 비중이 커진다.
• 상태, 사건, 동작(action)/활동(activity)이 동적 모델링의 핵심 개념이며, 이를 도식화한 것이 상태변화도(STD)다.
• 상태변화도는 보통 시나리오 작성 → 사건추적도 → 상태변화도의 세 단계를 거쳐 완성한다.
• 상태 추상화, 동시 수행, 조건 표시, entry/exit 동작 같은 확장 표기법을 쓰면 더 정교한 상태변화도를 그릴 수 있다.
• 자료흐름도에 제어 흐름과 제어 명세서(프로세스 활성표, 결정표, 상태변화도)를 추가하면 기능 모델과 동적 모델을 하나의 통합된 그림으로 표현할 수 있다.

다음 장(9장 정보 모델링)에서는 세 관점 중 마지막인 정보 관점을 다룬다. 책마루의 상품, 주문, 손님, 재고가 어떤 객체와 속성으로 이루어져 있고 서로 어떻게 연결되는지를 개체-관계도(ERD)로 정리해본다.