요구 분석을 마쳤지만 기능은 구현하지 않았습니다
결과 자동발송은 이미 운영 중이었지만, Control 샘플의 실패 판정과 QC 검토 결과는 발송 조건에 들어 있지 않았습니다. 당시 자동발송은 주문 상태, 전체 반응의 분석 완료 여부와 성공 비율을 기준으로 판단했습니다. 따라서 Control이 실패해도 기존 조건만 충족하면 QC 담당자가 보기 전에 결과가 발송될 가능성이 있었습니다.
이 문제를 다룬 기록은 문의에 대한 분석과 후속 요구 정리 단계에서 끝났습니다. 업무 요청이 종료 상태라는 사실을 기능이 구현·배포됐다는 뜻으로 읽지 않았습니다. 그래서 이 글에도 실제 코드나 구현 성과를 넣지 않고, 어디까지 규칙을 확정해야 했는지를 남깁니다.
기존 자동발송 조건부터 확인했습니다
현행 흐름을 분석하면서 분석이 끝났다와 QC가 발송을 승인했다가 같은 판단이 아님을 확인했습니다.
| 판단 항목 | 기존 자동발송에서 사용 | 검토가 필요했던 지점 |
|---|---|---|
| 주문 상태 | 사용 | 발송 가능한 주문 상태인지 판단 |
| 전체 반응 분석 완료 | 사용 | 아직 분석 중인 결과 제외 |
| 성공 비율 | 사용 | 기존 성공 기준 충족 여부 판단 |
| Control 샘플 판정 | 사용하지 않음 | Fail이면 Sheet를 보류할지 결정 필요 |
| QC 검토 결과 | 사용하지 않음 | 누가 어떤 근거로 Release할지 결정 필요 |
결과 발송은 주문 단위로 처리되고 있었습니다. 반면 새 요구는 Control이 속한 Rxn Sheet 전체를 Hold하는 것이었습니다. 판단 단위가 주문에서 Sheet로 넓어지므로 조건문 하나를 추가하는 문제로 볼 수 없었습니다.
Hold의 단위는 Rxn Sheet였습니다
초기 요구를 상태 변화로 줄이면 다음과 같습니다. 실제 DB 상태코드나 구현 결과를 옮긴 도식은 아닙니다.
분석 완료
├─ Control 정상 ─▶ 기존 자동발송 판단
└─ Control Fail ─▶ Rxn Sheet HOLD
↓
QC 검토
↓
RELEASE여기서 Hold는 Control 주문 하나만 멈추는 상태가 아닙니다. 같은 Rxn Sheet에 포함된 주문들의 자동발송을 함께 막는 요구였습니다. 따라서 최소한 다음 관계가 필요했습니다.
- Control 판정과 영향받는 Rxn Sheet의 연결 기준
- Hold된 Sheet에 포함된 주문의 조회 범위
- 주문별 결과 준비 상태와 Sheet Hold 상태의 표시 방식
- QC 검토 뒤 발송 대상을 선택할 수 있는 역할
화면안을 보니 Release도 하나가 아니었습니다
후속 화면안은 Rxn Sheet를 선택하면 포함 주문 목록을 보여 주고, 일부 주문만 Release하거나 남은 주문은 Hold로 유지하며, 조건이 충족되면 전체 Release하는 흐름을 검토 대상으로 제시했습니다.
| 분석용 상태 | 화면에서 필요한 동작 | 아직 확정해야 했던 규칙 |
|---|---|---|
| Sheet Hold | 포함 주문과 보류 사유 확인 | Control 재판정 시 상태 변경 조건 |
| 일부 Release | 선택한 주문만 발송 대상으로 전환 | 선택 권한과 주문별 Release 가능 조건 |
| 잔여 Hold | 보내지 않은 주문을 계속 보류 | 재실험·재시퀀싱과의 충돌 처리 |
| 전체 Release | 남은 주문을 일괄 발송 | 전체 발송 가능 여부의 최종 판단 기준 |
Release 버튼을 둔다는 화면 설명만으로는 부족합니다. 부분 Release 뒤 Sheet 상태를 무엇으로 볼지, 이미 발송된 주문과 남은 주문을 어떻게 구분할지, 재검토 시 이전 선택을 누가 확인할 수 있을지까지 정책이 이어져야 합니다.
권한·이력·파일 처리는 별도 정책이 필요했습니다
화면 동작을 검토하면서 구현 전에 답해야 할 질문도 분리했습니다.
권한
Hold 상태를 조회하는 사람, 일부 또는 전체 Release를 실행하는 사람, 잘못된 Release를 정정할 수 있는 사람의 권한을 같게 둘지 확정되지 않았습니다. QC 역할 이름만 추가한다고 실제 승인 책임이 정해지는 것은 아닙니다.
이력
누가 언제 어떤 주문을 Release했는지, 당시 Sheet와 Control의 상태가 무엇이었는지 남기는 구조가 필요합니다. 다만 신규 이력 테이블이나 감사 모델을 구현·검증한 사실은 없습니다. 필요한 기록 항목을 확인한 단계입니다.
결과 파일과 발송 순서
재실험이나 재시퀀싱이 생기면 결과 압축 파일 생성, 주문별 Release와 실제 메일 발송 순서가 서로 충돌할 수 있습니다. 별도 서버의 파일 처리와 애플리케이션 트랜잭션을 어디까지 묶을지도 확정되지 않았습니다. 최신 결과 파일을 검증하거나 이 경계를 구현했다고 기록하지 않습니다.
분석 범위와 다음 단계를 나눴습니다
요구 분석 단계에서 다룬 내용과 구현 전에 더 정해야 할 내용을 나눴습니다.
| 작업 | 이 글에서 다루는 범위 |
|---|---|
| 기존 자동발송 조건 분석 | 현행 동작으로 확인 |
| Control Fail 시 Rxn Sheet Hold 요구 | 후속 요구로 확인 |
| 일부·잔여·전체 Release 화면안 | 화면안까지 검토 |
| 권한·감사이력 정책 | 다음 설계 단계에서 결정할 항목 |
| 파일 처리·트랜잭션 경계 | 다음 설계 단계에서 결정할 항목 |
| 구현·테스트·배포·운영 반영 | 이번 작업 범위에 포함되지 않음 |
이렇게 나누자 해외 현업이 요청한 Hold/Release 규칙과 화면 검토 항목이 분명해졌고, 아직 정해지지 않은 설계와 완료되지 않은 구현도 구분할 수 있었습니다.
다음 단계에서 필요한 검증
구현이 시작된다면 정상 자동발송뿐 아니라 Control Fail, 부분 Release, 잔여 Hold, 전체 Release, 재실험과 동시 조작을 각각 검증해야 합니다. 권한이 없는 사용자의 변경 차단과 Release 이력, 파일 생성 실패 뒤 재시도도 별도 시나리오가 필요합니다. 이것은 수행 완료 목록이 아니라, 현재 요구에서 도출한 후속 검증 범위입니다.
테스트할 수 없는 연계 구간을 완료로 처리하지 않은 사례는 구현과 검증 상태를 나누는 기준을 설명합니다. 재발급 문서의 이력을 상태로 관리한 사례는 변경 주체·시점·사유가 업무 데이터가 될 때의 모델을 보여 줍니다. Hold/Release도 구현 전에 상태와 이력의 의미를 먼저 확정해야 한다는 점에서 두 사례와 이어집니다.