작아 보였던 작업이 전체 구조를 바꾸기까지

가상계좌가 바꿔놓은 예약과 결제의 흐름

연말 임베딩 프로젝트로 한창 바쁘던 시절, 자연스럽게 다음 프로젝트까지 확정됐다.

새 프로젝트의 배경은 꽤 명확했다. 현재 내가 담당하고 있는 도메인은 고액 결제가 잦은 편인데, 금융 정책 변경으로 기존 결제 수단만으로는 예약 건당 평균 금액조차 결제할 수 없는 상황이 된 것이다. 이 문제를 해결하려면 새로운 결제 수단이 필요했다.

그렇게 논의가 시작된 것이 가상계좌 결제 수단 추가였다.

처음 이 프로젝트를 접했을 때의 인상은 단순했다. ‘결제 수단 하나 추가하는 작업’ 정도로 보였다. 다른 프로젝트의 오픈을 앞두고 있던 시점이라 깊게 고민할 여유도 많지 않았다. 전반적인 개요만 정리된 상태에서, 상세 정책이나 프로세스를 충분히 검토하기도 전에 백엔드 개발자가 투입되며 프로젝트는 빠르게 시작됐다.

하지만 막상 프로젝트가 본격화되자, 핵심은 ‘결제 수단 추가’가 아니라 ‘가상계좌’ 그 자체라는 점이 분명해졌다. 기존 결제 수단과는 성격이 완전히 달랐다.

가장 큰 차이는 두 가지였다.

첫째, 가상계좌는 비동기 결제라는 점이다. 예약은 생성되지만, 결제가 언제 완료될지는 알 수 없다. 기존에는 결제가 완료되어야 예약이 생성됐기 때문에, 이 차이는 생각보다 큰 영향을 미쳤다.

둘째, 환불 처리 방식이다. 입금 계좌 정보를 시스템에서 알 수 없기 때문에, 환불 시에는 고객에게 별도로 환불 계좌를 받아야 했다.

이 두 가지 차이로 인해 결제 완료·취소 프로세스는 기존 결제 수단과 전혀 다른 흐름을 갖게 되었고, 자연스럽게 예약 프로세스 역시 달라질 수밖에 없었다.

문제는 여기서 끝이 아니었다. 현 도메인은 특성상 예약과 결제 구조 자체가 이미 복잡한 편이다.

예약 생성

잔금 결제

취소 / 페널티 취소

금액 감액

쿠폰·포인트가 포함된 복합 결제 케이스

이 모든 흐름을 가상계좌 기준으로 다시 검토해야 했다. 여기에 더해, 연동사 상품은 예약·취소 프로세스가 또 다르다 보니 같은 케이스를 사실상 한 번 더 고민해야 하는 상황이 되었다.

다행히 이 과정에서 백엔드·프론트 개발자들과 매일 진행 상황을 공유하며 긴밀하게 소통할 수 있었다. 현 시점에서 꼭 필요한 기능은 추가 개발로 가져가고, 복잡도 대비 효과가 낮은 부분은 과감하게 스펙 아웃하는 식으로 빠른 의사결정을 이어갔다.

이 프로젝트를 겪으며, 다음에 유사한 작업을 할 때 내가 가장 먼저 확인해야 할 포인트도 분명해졌다.

기능 추가나 변경으로 인해 기존과 본질적으로 달라지는 지점은 무엇인가?
그리고 그 차이로 인해 어떤 프로세스들이 연쇄적으로 영향을 받는가?

현재는 QA를 진행 중이고, 개발도 막바지를 향해 가고 있다. 개발 속도가 아주 빠르다고 할 수는 없지만, 잦은 소통 덕분에 큰 방향성은 흔들리지 않고 있다.

이번 프로젝트에서는 예약부터 추가 결제, 취소와 환불까지 모든 구간에서 한 번쯤은 이슈를 마주했다. 마무리를 향해 가는 지금 시점에서 되돌아보면, 시작 단계에서 더 넓은 관점으로 고민하지 못했던 점들이 아쉬움으로 남는다.(마무리 중인 프로젝트와 동시에 보고 있다는 어려움이 있던 것도 있지만...) 프로젝트 초반의 판단들이 이후 구조 전반에 어떤 영향을 미치는지, 그 무게를 다시 한번 실감하게 되었다.

그렇지만 이번 경험은 다음 프로젝트를 더 단단하게 만들어 줄 것이라 믿는다. 적어도 이제는, 작아 보이는 추가와 변경 건을 작업할 때에도 먼저 구조부터 떠올려보게 될 것 같다.