01. 단건 결제에서 포인트제로 결제 시스템으로 변경! 요청 사항 기반으로 구조 정의하기

현재 우리 서비스에서 결제 지원을 하지만, 어디까지나 단건 결제이다. 특히 건별 결제가 특수 상황에만 발생하는 시나리오이기 때문에, 결제 정보를 담고 있는 테이블, 무엇을 결제하고 그것의 금액이 어떻게 되어있는지에 대해 들어있는 테이블 총 두 개의 테이블을 사용했다. 그리고 이번에 포인트 결제로 변경하고 싶다는 말을 시작으로, 첫 걸음을 내딛게 되었다. (살려줘ㅠ) 이제 결제 시스템을 처음부터 만들면서 그 기록을 포스팅해나가며 정리하려고 한다.

 

 

🎯 01. 포인트 결제로 전환을 위한 요구사항 수집하기

제일 중요하고 중요한 업무... 요구 사항 확인하기! 대표의 요구사항은 다음과 같다.

 

- 신규 회원일 경우에 무료 충전 포인트가 있어야 한다.

- 포인트를 충전, 사용을 할 수 있어야 한다.

- 쿠폰을 통하여 포인트를 충전할 수 있어야 한다.

- 무료 포인트의 경우에는 유효기간이 존재한다.

- 무료 포인트 + 유료 포인트가 존재할 경우 언제나 무료 포인트가 먼저 소진된다.

- 사용하지 않은 유료 포인트에 대한 환불이 가능해야 한다.

 

정리하자면 다음과 같다.

1. 유료 포인트는 충전 결제, 무료 포인트는 최초 가입 시 지급 혹은 쿠폰을 통하여 충전이 가능하다.

2. 무료 포인트는 유효기간이 존재한다.

3. 유료 포인트를 충전 후, 결제분을 전혀 사용하지 않았을 경우 환불이 가능하다.

 

이제 이것들을 조합해서 만들어보자.

 

 

 

 

 

🔧 02. 기초 테이블 설계하기

우선 첫번째로는 기초가 될 뼈대 테이블을 만들어야 한다. 우리는 기존에 단건 결제를 담고 있는 결제 테이블이 있다. 이것을 사용하면서, 추가로 필요한 것들을 하나씩 만들어나가도록 할 것이다. 제일 기초가 되는 부분은, 기존 테이블과 함께 새로 포인트를 활용하는 테이블을 만드는 것이다. 여기에서 payment_history와 data_product_amount는 기존에 있던 테이블이며, 신규로 포인트를 위한 user_point, point_history를 만들었다. 

자 이렇게 만든 테이블들은 다음과 같은 역할을 하고 있다.

 

1. 충전 시나리오

고객이 포인트 충전을 시도 -> user_point 테이블에서 사용자 id를 기반으로 하여 결제한 금액을 확인, 유료 혹은 무료 포인트 잔액에 플러스를 하여 updqte 됨 -> payment_history가 update 되면, user_point, payment_history, data_product_amount 의 insert 혹은 update 된 데이터를 토대로, point_history에 새로 Insert.

2. 사용 시나리오

고객이 포인트 사용 -> data_product에서 해당하는 것을 찾음 -> user_point에서 해당하는 금액만큼의 잔액을 차감. -> point_history에서 해당 내용들에 대한 변경사항 새로 insert.

 

 

 

 

 

🚀 03. 아니 근데 진짜 문제가 돼.

이제 아주 기초적인 틀을 잡았고, 문제점을 확인 후에 추가로 가지 뻗듯 계속해서 수정해나가면 된다. 여기에서 문제점은 무엇이 있을까? (당연히 꽤 많다) 

제일 중요한 점들을 집어보자.

첫번째. 유효기간에 대한 관리가 불가능하다

무료 포인트는 유효기간이 존재해야 하는데, 유효기간에 대한 관리가 없으므로 무료 포인트의 충전시점과 사용시점을 알 수 없다. 

두번째. FIFO 지원이 불가능하다.

무료 포인트의 충전 시점을 알 수 없기 때문에 당연히 먼저 쓸 포인트에 대해서도 알 수 없다. 거래 일시로 타고 들어가면 된다고? 그렇다면 거래 일시를 토대로 지금까지 했던 모든 거래를 뒤지면서 무엇을 썼는지 어떻게 되는지 알아야 하는데 너무~ 나도 비효율적이다.

세번째. 거래 추적 어려움.

위에서 언급한 것들과 이어지는데, 거래내용의 추적이 어렵다. 저렇게 하게 되면 user_point 에는 기록이 없고, point_history에만 히스토리에 대한 기록이 있는데, 저기에서 거래 추적을 하기 위해서는 최종수정시간과 거래일시 추적밖에는 답이 없다. 혹시 모르는 상황에 대한 대비가 불가능하다.

네번째. 상품 PK가 한글.

API를 호출하게 되면서 PK를 통해 유기적 움직임이 행해져야 하는데, 한글을 사용하게 되면 문제가 생길 수 있다. 또한, 지금 저기에서는 굉장히 상품에 대한 내용이 불분명하다. 이것이 충전용인지, 사용인지, 타입조차 명시가 안 되어 있어서 그냥 상품명으로 때려야 한다. 

 

 

 

 

---

 

 

 

 

✨ 오늘은 끝! 내일은 뭐 하지?

우선 요구사항들을 확인했고, 앞으로 해나가야 할 과제를 받아냈다. 첫번째로는 가장 기본이 되는 틀을 잡는 작업을 했으며, 다음번에는 그것을 기반으로 응용해 2차로 새로운 것을 만들려고 한다. (빠르면 구현까지 되겠지라는 생각으로....!) 이렇게 큰 것을 1인 개발자 겨우 내가 할 수 있을지 손발이 덜덜 떨리지만 어떻게든 해야 하지 않겠는가 싶고.. 이제 5주 남은 이 스프린트가 무사히 끝나고 나는 조금 더 성장을 제발 성장을!