결제 테이블 재설계

Jae Min·2023년 10월 1일
0

작년 겨울에 처음으로 결제 모델을 붙였다.
결제 라는 기능을 처음 만들다 보니, 편협한 사고와 시야로 결제 테이블 스키마를 설계 했었다.
그때 당시 나이스페이라는 pg 사를 사용했기 때문에, 사실상 나이스페이에만 국한되는 테이블을 설계했었다.

이번에는 기존에 존재하는 결제 기능에 대출서비스, 마켓 기능을 추가로 붙이다 보니 추가해야 할 결제 관련 테이블들이 늘어났다.
ex) 세금계산서, 거래명세서, 주문이력, 대출이력...

물론 현재 있는 결제 테이블에 계속 더하거나 비정규화를 통해서 만들 수 있었지만, 이렇게 계속 개발하면 발전도 없고, 점점 시간이 지나서 다른 pg 사를 사용하던가 다른 방법으로 결제를 하게 되는 기능이 생긴다면 무결성은 위배될 것이고, 스키마 확장성은 줄어들 것으로 보였다.

그래서 이번에 기존에 있던 결제 관련 스키마를 재설계 하면서 대출 기능을 추가하기로 하였다. 대출 기능 배포 기간도 맞춰야 하는 문제가 있고, 재설계를 한다면 기존에 구현되어 있던 기능들 테스트도 물론 해야하는 문제도 있다.


🔥어떻게 진행했나🔥

두번째 문제를 잘 해결하기 위해 우리는 이런 방법으로 진행했다.

1) 기존 테이블에 insert 하는 로직은 그대로 두고, 새롭게 설계된 테이블에도 insert 를 한다.
기존 테이블이 payment 라는 테이블이라면 우리는 payment_rootpayment_rfq, payment_strategy_nicepay 와 같이 분할했다.
insert into payment 하는 로직에서 insert into payment_root, insert into payment_rfq, insert into payment_strategy_nicepay 를 같이 하는거다.

2) 조회하는 로직에서는 대출 관련 데이터는 새롭게 설계된 테이블을 대상으로 새롭게 로직을 짜고, 대출 아닌 데이터에 대해서는 기존에 사용하던 로직 그대로 이용
대신 추후에 데이터를 이관했을 때에도 정상적으로 조회가 될 수 있게끔 쿼리를 짠다.
👉 이 부분이 쿼리를 짜는데 까다로웠다.

3) 수정하는 로직은 다행히도 대출관련 결제 기능에서는 수정하는 부분이 많지 않아서 2번과 비슷하게 기존에 사용하던 수정 로직은 사용하고, 대출관련 데이터들은 새롭게 만들었다. 수정하는 로직은 배포하고 나서 천천히 같이 바꿔줘도 되기 때문에 급하지 않았다.

물론 회사가 운영하고 있는 서비스의 상황이나 디비의 상황에 따라 방법은 다르겠지만, 기존에 잘 쓰고 있는 로직을 한꺼번에 다 바꾸는 것은 리스크가 따른다. 그렇기 때문에 우리는 조회부터 바꿀꺼야 우리는 삽입부터 바꿀꺼야 이런것들을 결정하는 건 회사 상황에 따라 결정하면 되지만, 이거 하나는 확실한 것 같다.
새로 설계된 테이블에 삽입할때는 새로 설계한 테이블에도 같이 넣어주는 것이다.

그리고 나중에 배포하기 전에 데이터 마이그레이션 했을 경우 새로 만든 조회 로직으로도 잘 나오면 땡큐고 아니면 일단 마이그레이션 롤백하고 배포 후에 다시 조회 로직 수정하면 되는 것이다.


📦 new schema

현재는 단건결제만 있지만, 대출이 들어오면서 분할결제도 생기고 추후에 있을 복합결제까지 고려해서 설계 하였다.

<단건 결제>
👉🏻 APP : 통합결제 : 결제서비스 : 수단 = 1 : 1 : 1 : 1
ex) 발주서 1 : 통합결제 1 : RFQ 결제 1 : 나이스페이 1

<분할 결제>
👉🏻 APP : 통합결제 : 결제 서비스 : 수단 = 1 : N : N : N
ex) 대출 결제 (선결제 10%, 대출 90%)
발주서 1 : 통합결제 2 : 결제서비스 2 : 수단 2 (나이스페이 1 + 대출 1)

<복합 결제>
👉🏻 APP : 통합결제 : 결제서비스 : 수단 = 1 : 1 : N : N
ex) 포인트로 일부 결제
발주서 1 : 통합결제 1 : 결제서비스 2 : 수단 2 (나이스페이 1 + 포인트 1)


☠️ 이거 생각보다 할일이 많은데...?

개발하면서 잘못 건들였다는 생각이 한두 번이 아니였다. 기존에 구현되어 있는 로직 수정하는 것도 일이었고, 기존에 비정규화되어 있던 테이블에 있던 칼럼들이 뿔뿔이 흩어지는 것 이기 때문에 체크할 것들도 너무 많았다.

괜히 뭐 하나 빠트리거나 중복되는 로직이 생긴다면 이대로 또 골치였다.

그래도 이렇게 기존에 잘 쓰고 있는 테이블을 재설계 하는 경험은 어디서도 할 수 없는 값진 경험이었다.

아직 대출 기능 개발중이지만, 이미 엎질러진 물이다. 문제가 생기더라도 어떻게 해서든지 반드시 해결해야 한다.
2023.10.01

profile
자유로워지고 싶다면 기록하라.

0개의 댓글