한동안 실무를 하면서 시간이 없다가, 일에 적응도 되고 새로운 기술을 배우면서 다시 블로그를 써야겠다고 생각해서 #실무 라는 태그를 만들면서 글을 쓰기 시작하려고 한다.
비즈니스 모델이 없던 첫번째 회사에서 결제 시스템을 도입하게 되었다.
사업팀에서 여러 PG사 중에 나이스페이를 채택하였다.
나이스페이에서 제공하는 API 만을 이용하지 않고, 아임포트라는 PG사 연동 서비스를 같이 이용하였다.
전반적인 결제 시스템을 도입하기에는 두가지 서비스를 이용하면 충분했다.
결제 환불 같이 단순한 기능을 구현하기에는 아임포트를 이용하면 좋았고, 정산 여부 및 잔액 조회 와 같이 세세한 기능을 구현하기에는 나이스페이를 사용했다. (아임포트에서 다음과 같은 서비스를 PG사 제한적으로 제공을 한다. 모든 PG 사를 대상으로 제공하지 않는다는 뜻.)
하지만, 한가지 API로 제공하지 않는 기능이 있었다.
무통장입금 확인 방법
고객이 가상계좌로 언제 입금을 하는지 직접 api 를 쏴서 아는 방법도 있는데, 이것을 구현하려면 cron job 을 돌려야 하는데, 이건 너무 자원적인 측면이나, 시간적인 측면에서 봐도 비효율적이다.
그래서 이것을 아임포트에서 웹훅을 제공하는데. 이 웹훅을 쐈을때, 우리서버가 이를 수신하는 방법이 있다.
하지만 만약에 우리 서버가 배포중이거나 혹은 잠깐 죽었다 라면?
아임포트에서는 정상적으로 웹훅을 쐈기 때문에, 정상 처리라고 생각하겠지만, 우리 서버가 정상적으로 돌아오면 해당 이벤트를 처리할 수 없는 상황이 되어버린다.
그래서 생각해낸 방법이 바로, 아임포트 웹훅을 람다가 수신하는 것이다.
람다가 웹훅을 수신하면 AWS MQ 에 다시 발송한다. 그렇게 되면 우리 서버가 죽은 상태였어도, 다시 살아나면 이를 처리할 수 있기 때문이다.
자 여기서 만약에 우리 서버가 메세지 큐에서 메세지를 꺼내와서 처리하다가 정상적으로 처리 되지 않았다면? 다시 메세지를 처리해야 하는데, 이미 소비를 했기 때문에, 해당 이벤트는 사라지게 된다.
그래서 생각해낸 방법이, 서버에서 메세지를 정상적으로 처리를 하면, acknowledge 를 MQ로 보내는 것이다. 이를 consumer acknowledge 라고 한다.
이를 보내서 MQ가 이를 받으면 "아 ~ 정상적으로 처리 되었구나~" 라고 인식하고 보내지 않으면, "어? 뭔가 문제가 발생했구나, 조금 있다가 다시 보내야겠다" 라고 인식을 하게 된다.
@MessagePattern('')
async webhook(@Ctx() context: RmqContext): Promise<Output> {
const mqChannel = context.getChannelRef();
try {
mqChannel.ack(context.getMessage());
} catch (error) {
}
}이런 방법으로 무통장입금확인 기능을 구현할 수 있었다.
처음부터 아임포트와 나이스페이의 API 를 구현하면서 직접 테스트 하면서 그들의 정책을 확인하느라, 시간도 많이 걸리고 어려운 부분도 있었지만, 누구나 쉽게 겪을 수 없는 경험이라고 생각한다. 이를 통해 많이 배웠고, 그만틈 3rd party 를 이용하려면, 그들의 정책을 정확하게 알아야 하고, docs 를 수도 없이 정독해야 한다는 것을 배웠다.
하지만, 생각보다 아임포트가 그렇게 친절하지는 않았다.
물론, 각 회사마다 운용하는 비즈니스 모델이 다르고, 결제 프로세스를 다르게 가져갈 수 있지만, 뭔가 개발을 하는데 있어, 즉각적인 피드백을 받기 힘들었고, 필요한 정보를 스스로 찾아가면서 요구를 해야 확인할 수 있는 그런 불편함을 느낄 수 있었다. 다음에 다른 결제 BM을 붙혀야 할 상황이라면, 다른 PG사를 사용할듯...
