부스 배정 시스템 개발 시 상태값을 설계하는 기준과 절차를 정리했습니다. 전환 주체·조건·트리거 정의법, 사전 확정 사항, 상태 전이 테이블 작성 순서와 주의사항까지 실무 관점에서 설명합니다.
- 결론 요약: 상태값은 '누가 어떤 조건에서 다음 상태로 보내는지'를 정의하는 일
- 준비물·전제조건: 상태값 설계 전에 확정해야 할 것들
결론 요약: 상태값은 '누가 어떤 조건에서 다음 상태로 보내는지'를 정의하는 일
상태값 설계의 마지막 관문은 결국 이 질문 하나로 압축됩니다. "누가, 어떤 조건에서, 이 신청을 다음 상태로 보내는가?" 여기에 답이 없는 상태값은 화면에 걸어둔 라벨일 뿐, 운영에서는 아무 역할도 하지 못합니다.
기본 상태값, 이 목록에서 시작하세요
부스 배정에 꼭 필요한 최소한의 흐름은 다음과 같습니다.
- 신청접수 — 폼 제출 직후, 아무 판단도 내려지지 않은 상태
- 검토중 — 담당자가 서류·자격 조건을 확인하는 단계
- 대기 — 자격은 맞지만 위치·물리적 여건이 부족한 경우
- 임시배정 — 구역·부스 번호를 지정했으나 확정 통지 전
- 확정 — 참가자가 안내를 받았고 배치도에 반영된 상태
- 취소 — 신청자 철회 또는 운영측 반려
여기서 멈추지 말고, 상태마다 세 가지를 정의 붙이세요.
- 전환 주체 — 신청자가 바꾸는 상태인가, 관리자 권한인가
- 전환 조건 — 검토중 → 임시배정은 무엇이 충족되어야 하는가
- 전환 시 트리거 — 알림톡 발송, 배치도 반영, 정산 집계 등 무엇이 자동으로 따라오는가
엑셀과 시스템의 결정적 차이
준비물·전제조건: 상태값 설계 전에 확정해야 할 것들
# 준비물·전제조건: 상태값 설계 전에 확정해야 할 것들
상태값 설계에서 가장 많이 터지는 지점은 코드를 짜는 순간이 아니라 그 전에 정해두지 않은 것들입니다. "결제 완료된 신청자한테 부스를 먼저 잡아줄까, 배정 담당자 승인이 먼저일까" 같은 질문에 현장에서 즉답하지 못하면, 상태값은 어긋나기 시작하고 결국 엑셀과 시스템 데이터가 따로 놀게 됩니다.
설계 착수 전에 손에 들어야 할 네 가지
- 기존 프로세스 흐름도 — 신청서 접수부터 확정, 취소, 재배정까지 실제로 오가는 단계를 그대로 그린 것. "원래 이렇게 되어야 한다"가 아니라 "지금 실제로 이렇게 돈다"를 담아야 합니다.
- 운영자 권한표 — 누가 상태를 바꿀 수 있는지. 접수 담당자, 배정 담당자, 관리자별로 변경 가능한 상태를 구분해두지 않으면 "누가 확정으로 바꿨는지 모르겠다"는 상황이 생깁니다.
- 결제(참가비) 시점 정의 — 부스 상태가 참가비 입금과 연동되는 기준점. 결제가 상태 전환의 트리거인지, 단순 기록인지 먼저 정해야 합니다.
- 배정 담당자 승인 단계 정리 — 자동 확정인지, 사람이 승인해야 확정되는지, 승인 거절 시 어느 상태로 되돌아가는지.
단계별 절차: 상태값 정의 → 전이 테이블 → 구현 → 검증
단계별 절차: 상태값 정의 → 전이 테이블 → 구현 → 검증
상태값 설계에서 가장 흔한 실수는 "일단 만들고 나중에 고치자"로 시작하는 겁니다. 상태는 한번 붙이면 되돌리기 어렵고, 잘못 설계하면 정산·환불·감사 추적까지 전부 흔들립니다. 순서를 지켜서 진행해봅시다.
1단계: 신청~확정 상태 흐름도 먼저 그리기
코드를 짜기 전에 상태 흐름도를 종이에 그리세요. 참가자가 신청 폼을 누르는 순간부터 부스가 확정되는 순간까지, 상태가 몇 개 필요한지 나열하는 겁니다.
최소한 이 정도는 구분됩니다.
- 신청 접수 → 심사/검토 → 임시 배정 → 결제 대기 → 배정 확정
- 각 단계에서 빠질 수 있는 갈림길(취소, 반려, 기한 만료)까지 함께 표시
여기서 핵심은 "상태 개수를 줄이자"가 아니라, 운영자가 화면에서 내리는 판단 하나하나가 상태로 존재하는가입니다. 흐름도에 없는 판단이 실제 운영에서 발생하면, 그때부터 임의 메모와 엑셀로 상태를 관리하게 되고 시스템이 무너집니다.
2단계: 유효 전이 테이블 정의
흐름도가 완성됐다면, 어느 상태에서 어느 상태로만 이동 가능한지를 표로 못 박습니다. 이게 없으면 "반려된 신청이 somehow 확정되는" 사고가 벌어집니다.
흔한 실수 vs 권장 기준: 이중 배정·정산 오류를 막는 설계 비교
행사 이틀 전 배정표를 열었더니 같은 부스 번호에 업체가 두 곳 붙어 있습니다. 전날 "취소했으니 비워달라"는 연락을 받은 담당자가 DB의 상태 칸을 직접 '확정'에서 '취소'로 바꿨는데, 다른 담당자는 엑셀 배정표만 보고 그 자리를 새 신청사에 넣어버린 겁니다. 이중 배정과 정산 분쟁은 대부분 이 지점에서 시작됩니다.
실수와 권장 기준, 나란히 비교
| 항목 | 흔한 실수 | 권장 기준 |
|---|---|---|
| 취소 처리 | '취소' 하나로 통합 → 규정 위반과 자진 취소가 같은 환불 기준에 섞임 | 원인별 상태 + 사유 코드 분리 (신청자 취소 / 주최 취소 / 미입금 취소 등) |
| 확정 후 변경 | DB를 수기로 직접 수정 → 누가 언제 바꿨는지 흔적 소실 | 재배정 상태 전환 절차로 확정 → 해제 → 대기 경유 처리 |
| 상태 정의 | 화면마다 문자열 하드코딩 → 오탈자·표기 불일치로 전이 누락 | 유효 전이 테이블 기반 상태 머신으로 불가능한 전이 자체를 차단 |
| 이력 관리 | 엑셀 이력만 보관 → 분쟁 시 원본 입증 불가 | 감사 로그에 변경자·시각·이전값·사유까지 기록 |
왜 이 네 가지가 치명적인가
엑셀에서 시스템으로: 마이그레이션 전략과 체크리스트, 그리고 다음 단계
엑셀 파일을 열어보면 부스 상태가 셀 배경색과 메모, 담당자별 표기 습관으로 뒤섞여 있습니다. "통화함, 이번 주 안에 확정 예정" 같은 문장이 상태 칸을 대신하고 있죠. 이 파일을 통째로 옮기면 혼란도 함께 이사 갑니다. 마이그레이션은 데이터 이동이 아니라 상태 재정의입니다.
기존 구분 하나하나에 신규 상태값을 짝지는 매핑표를 먼저 만듭니다. 그러면 반드시 애매한 표기들이 걸리는데, 이걸 '기타'로 몰아넣으면 나중에 통계도, 사유 추적도 안 됩니다. 사유 코드를 새로 만들어 분리하는 게 정답입니다. | 항목 | 흔한 실수 | 권장 기준 |
| 애매한 기존 구분 | '기타' 하나로 묶기 | 사유 코드 신설(예: 예산 미확정, 위치 협의 중) |
|---|---|---|
| 상태 이전 | 최종 상태만 옮기기 | 전이 조건과 이력까지 이전 |
| 검증 | 총 건수만 세고 끝 | 상태별 분포를 엑셀과 대조 |
옮긴 뒤에는 분포로 검증한다
이관이 끝났다고 끝이 아닙니다. 엑셀 시점의 상태별 건수와 시스템의 상태 분포를 나란히 놓고 어느 상태에서 차이가 나는지 봅니다.