예시 답변 1
약 90초
커머스 플랫폼에서 상태 전이 설계 실패와 상태 머신 패턴으로 개선한 경험을 정리한 결
사이드 프로젝트로 소규모 중고 거래 플랫폼을 만들며 커머스 도메인을 처음 경험했습니다. 주문 상태를 단순 completed/pending으로만 설계했다가 상태 전이 엣지 케이스가 계속 터지는 문제를 겪었습니다. '결제 완료 후 배송 전 취소' 같은 중간 상태를 처음부터 설계에 넣지 않은 게 원인이었고, 상태 머신 패턴으로 9개 상태·12개 전이를 명시적으로 정의하는 방식으로 리팩터링했습니다. 이후 환불 관련 버그가 0건이 됐고, 새 상태 추가도 기존 로직을 건드리지 않고 가능해졌습니다. 이 경험으로 커머스 도메인의 복잡성은 기능 수가 아니라 상태 관리와 예외 흐름에 집중돼 있다는 것을 직접 배웠습니다.
이 결의 특징
이 결은 상태 관리의 복잡성을 인한 피할 수 없는 좌절에서 출발합니다. 사이드 프로젝트 중고 거래 플랫폼에서 주문 상태를 단순 completed/pending으로 설계했다가 '상태 전이 엣지 케이스'가 계속 터지는 구체적 경험, 특히 '결제 완료 후 배송 전 취소' 같은 중간 상태가 빠진 설계의 결함이 명확합니다. 9개 상태·12개 전이를 명시적으로 정의하는 상태 머신 패턴으로의 전환이 구체적인 리팩터링 방식입니다.
이 결이 통하는 자리
설계 단계에서 모든 사용자 흐름을 예상할 수 없다는 현실을 아는 조직에서 통합니다. 고객 환불과 부분 취소가 실제로 벌어지는 전자상거래 서비스, 상태 전이의 정합성을 엄격히 관리하는 결제 시스템, 사후 리팩터링으로 인한 기술 부채를 피하려는 팀에서 이 학습의 증거가 공명합니다.