결제 취소 기능명세서 수정 : 서비스 분리의 중요성

오늘은 '결제 취소 기능'의 개발 과정에 대한 글을 쓰러 왔습니다.

초기 설계의 오류 : 결제 서비스의 역할 혼동

초기에 결제 취소 기능을 설계할 때, 사용자가 직접 결제를 취소할 수 있는 시나리오를 고려했습니다.

기존의 모놀리식 방식에서는 이러한 방식이 틀리지 않다고 할 수 있습니다.

왜냐하면 모든 서비스에 대한 코드가 다 하나의 시스템 안에 같이 있기 때문이죠.

 

그러나 이는 결제 서비스의 본질적인 역할에 대한 오해에서 비롯된 것이었습니다.

결제 서비스는 말 그대로 '결제'라는 행위를 관리하는 것이지,

사용자가 직접 취소를 요청하는 것은 아닙니다.

수정된 프로세스

팀원들과의 논의를 통해 실제 배달의 민족에서 결제 취소를 하기 위해서는

고객센터가 이를 수작업으로 고객한테서 취소 요청을 받고 전달하거나,

사장님께서 직접 취소 요청을 하는 경우가 많다는 사실을 알게 되었습니다.

 

하지만 저희 V1 에서는 고객 센터가 없기 때문에 이를 대체하는 프로세스로 다음과 같이 짰습니다.

수정된 프로세스

1. 결제 취소에 대한 요청을 주문중계 시스템이 받아
2. 가게(사장) 서비스에게 전달, 사장님이 취소를 받아들이면
3. 가게(사장) 서비스가 결제 서비스에 취소 요청

개발자로서의 성찰

이번 경험은 저에게 서비스 설계 시 각 컴포넌트의 역할과 책임을 명확히 이해하고,

서비스 간의 올바른 상호작용을 설계하는 것의 중요성을 일깨워주었습니다.