시스템 분석에서 상태와 API 결합

시스템 분석 산출물 통합: 상태 모델, 사용 사례, API를 하나의 일관된 모델로

시스템 분석에서 사용자 스토리(US)는 요구사항의 핵심 기반이다. 이를 바탕으로 팀은 상태 모델, API, 사용 사례를 도출한다. 기존 방식은 산출물을 분절적으로 생성한다: 비즈니스 이해관계자는 시나리오에 집중하고, 개발자는 엔드포인트에 주목하며, QA 엔지니어는 테스트 케이스에 초점을 맞춘다. 본 문서에서 제안하는 접근법은 명시적인 API 매핑을 갖춘 단일 상태 기반 모델로 이들을 통합해, 모든 역할에 걸쳐 프로세스에 대한 하나의 일관된 관점을 제공한다.

실제 사례를 살펴보자: 클라우드 인프라 임대 시스템이다. 고객은 비용을 산정하고, 요청을 제출하며, 리스크 평가를 거친 후 결제하고, 최종적으로 자원을 할당받는다.

핵심 사용자 스토리

이해관계자들이 제공한 주요 사용자 스토리는 다음과 같다:

| # | 제목 | 설명 |

|---|------|------|

| US-1 | 인프라 비용 산정 | 잠재 고객으로서, 내 워크로드에 맞춘 클라우드 인프라 비용을 산정해 예산과 기술적 요구사항에 부합하는지 판단하고 싶다. |

| US-2 | 산정 결과 기반 요청 제출 | 등록 및 인증 완료된 고객으로서, 이전에 생성한 비용 산정 결과를 활용해 인프라 배포 요청을 신속하게 제출하고 싶다. 중복 입력 없이 결제 단계로 바로 이동할 수 있어야 한다. |

| US-3 | 자동 리스크 평가 및 승인 워크플로우 | 청구 시스템으로서, 새 요청에 대한 리스크를 자동 평가하고 수동 승인이 필요한지 여부를 판단하고 싶다. 신뢰도 높은 고객은 빠르게 처리되고, 결제 미이행 위험은 최소화되어야 한다. |

| US-4 | 청구서 발행 및 결제 | 승인된 요청을 보유한 고객으로서, 선호하는 결제 수단으로 청구서를 발행받고 결제하고 싶다. 그러면 주문한 인프라를 즉시 활성화해 실시간으로 사용할 수 있다. |

| US-5 | 자동 인프라 프로비저닝 | 클라우드 인프라 공급자 시스템으로서, 결제 확인 후 자원을 자동으로 배포하고 싶다. 고객은 지연이나 수작업 없이 즉각적으로 접근 권한을 얻어야 한다. |

이 스토리들은 관련 액터와 목표를 정의하며, 상태 모델의 출발점이 된다.

프로세스 상태 모델

사용자 스토리를 기반으로 요청 수명주기의 다음 상태들을 도출했다:

• QUOTE_CREATED — 견적 저장 완료; 상업적 견적서 생성됨.
• ORDER_SUBMITTED — 요청 제출 완료; 자동 리스크 평가 대기 중.
• UNDER_REVIEW — 영업 매니저의 수동 검토를 위해 요청이 표시됨.
• APPROVED — 요청 승인 완료(자동 또는 수동).
• REJECTED — 요청 거부됨(거부 사유 명시 필수).
• INVOICE_ISSUED — 청구서 생성 및 고객에게 전송됨.
• PAID — 결제 성공적으로 완료됨.
• EXPIRED — 청구서 만료일 경과로 미납 처리됨; 요청 자동 취소.
• PROVISIONING — 인프라 배포 작업 진행 중.
• ACTIVE — 인프라 가동 완료; 접근 자격 증명 발급 완료.
• FAILED — 배포 실패; 지원 티켓 자동 생성.

이 상태들은 산출물의 구조적 골격을 이루며, 관련 시나리오를 논리적으로 그룹화한다.

사용 사례 및 확장 방식

사용 사례는 청구 시스템의 기능적 역량을 포착한다. 이를 확장하면 상태 전이와 API 엔드포인트에 직접 연계된다. 산출물 구조는 다음과 같은 요소를 포함한다:

• 비즈니스 로직: 시나리오 단계를 상태 변경에 매핑.
• 시스템 상태: 중심 상태 프레임워크로서의 상태 모델.
• 기술 구현: 각 사용 사례에 대응하는 엔드포인트 바인딩.

예시 매핑: ORDER_SUBMITTED → APPROVED 전이 시 POST /score-order 호출 후 PUT /approve-order 실행.

통합 산출물의 장점

이 산출물은 다양한 역할 간 추상화 격차를 해소한다:

• 비즈니스 이해관계자에게: 상태 기반 시각적 시나리오 흐름 — 워크숍 및 데모 세션에 최적.
• 개발자에게: 전체 수명주기 내 명확한 API 맥락 — 사용 사례, 상태 전이, 인터페이스 사양 간 직접 연결.
• QA 엔지니어에게: 준비된 테스트 케이스 기반 — 상태 전이, 엔드포인트 동작, 예외 흐름 전반을 커버.
• 프로젝트 매니저에게: 실시간 구현 체크리스트 — 완료된 API 및 해결된 상태를 추적 가능.

주요 고려 사항

• 상태/사용 사례/API를 통합한 산출물은 다학제적 이해를 자연스럽게 정렬시킨다 — 별도 도구나 번역 계층이 필요 없다.
• 상태 모델은 핵심 뼈대로 작동하며, 비즈니스 워크플로우와 기술 엔드포인트를 일관되게 통합한다.
• 이 산출물은 테스트 설계, 개발, UAT를 가속화해 문서 분절화와 재작업을 줄인다.
• 특히 복잡한 비즈니스 로직을 가진 프로젝트에서 효과적이며, 기존 산출물을 대체하지 않고 서로를 연결한다.
• 실제 현장 적용 사례는 이해관계자 및 팀 간 조율 세션에서 이 방법의 효율성을 입증했다.

실무 적용 방법

Draw.io, Confluence 또는 마크다운 등 도구를 활용해 구조화된 표 또는 흐름도 형태로 산출물을 작성한다. 시작은 사용자 스토리이며, 이후 상태를 추가하고, 사용 사례 및 대응 API 엔드포인트를 매핑한다. 한 실제 프로젝트에서는 이 산출물을 이해관계자 조율에 활용했다: 문서를 열고 상태 체인을 함께 순회하며 구현 완료 항목을 실시간으로 체크했다. 주관적 평가에 따르면, 이 방식은 전달 팀 내 오해 발생률을 30–40% 감소시켰다.

— Editorial Team