오픈 직전, 자동 취소에서 발견한 정책의 빈틈과 PM의 의사결정
프로젝트 막바지에 가까워질수록, 일은 오히려 더 촘촘해진다.
초기 기획 단계에서 세웠던 정책은 개발 과정에서 한 번씩 재검토되고, 개발 방향은 실제 구현과 운영 맥락을 반영하며 미세하게 조정된다. QA 단계에 들어서면 운영팀과의 싱크를 맞추며, 놓친 부분은 추가 개발로 보완한다.
그렇게 여러 번의 조정을 거쳐, 어느덧 프로젝트는 오픈을 앞두고 있었다. 과정이 순탄하지만은 않았지만, 적어도 지금 시점에서 필요한 준비는 모두 마쳤다고 판단했다. 그래서 오픈 일정도 확정하고, 유관 부서에도 공유를 시작했다.
그러던 중, 코드 리뷰(Code Review)를 다녀온 백엔드 개발자가 말을 걸어왔다.
잠깐 할 얘기가 있어요.
예약에는 마감일이 존재하고, 그 시점까지 결제와 필수 정보 입력이 완료되지 않으면 자동 취소된다.
이때 가상계좌로 결제한 예약이라면 환불 계좌 정보가 필요한데, 자동 취소 로직에서는 환불 계좌를 수취하지 않은 상태이고 정상적으로 취소될 수 없다.
기존 설계 단계에서는 고려하지 못했던 상황이었다.
문제를 인지한 후, 빠르게 다음 액션 아이템을 도출해야 했다.
1. 현상 파악
마감일 도래 시 취소 로직이 돌지만, 환불 계좌 정보 부재로 결제 취소 API가 에러를 뱉는다.
2. 예방 가능성 검토
고객에게 안내 메시지를 발송하지만, 입금과 필수 정보 입력은 고객의 선택 영역이기에 시스템적으로 강제할 수 없다.
3. 가시성 확보
에러가 발생했을 때 슬랙 채널에는 알림이 발생한다.
4. 해결 대안 수립
환불 계좌를 사후에 입력받아 처리할 수 있는 어드민(Admin) 기능을 추가한다.
5. 리소스 및 일정 조율
런칭 직후 발생 확률과 수기 대응 가능 여부를 판단했다. 결론적으로 오픈은 예정대로 진행하되, 해당 기능은 별도로 배포하기로 한다.
이번 경험을 통해 다시 한번 깨달은 사실이 있다.
개발자들의 코드 리뷰는 단순히 버그를 잡는 시간이 아니라는 점이다. 비즈니스 로직의 논리적 허점을 찾아내는 최후의 방어선이자, 팀 전체가 도메인 지식을 이해하는 과정이다.
정책을 설계하는 단계에서 이 케이스들을 미리 잡아냈다면 좋았을 것이다. 하지만 오픈 전, 팀 내 소통을 통해 이를 발견하고 대응책을 마련할 수 있었던 것만으로도 다행이다.
결국 기획의 끝은 '기능의 구현'이 아니라 '예외의 완결'에 있다. 99%의 사용자가 경험하지 못할 1%의 에러 상황도 고민하는 것. 그것이 사용자가 우리 서비스를 신뢰하게 만드는 가장 확실한 방법이다.