파트너 정산 계좌 다건 등록과 승인 플로우 구축
목차
파트너 계좌 다건 관리 작업 회고
기존엔 파트너 1명당 정산 계좌가 1개만 등록 가능한 구조였음. 그런데 운영 들어가보니 사업자 명의 분리, 분점 정산, 세무 분리 등 사유로 계좌를 여러 개 굴리고 싶어하는 파트너가 적지 않았음. 그래서 다건 등록 + 관리자 승인 플로우를 한 사이클에 묶어서 작업함.
데이터 모델 정리
기존 단일 컬럼 구조를 그대로 두고 분리만 하면 레거시 정산 로직이 다 깨짐. 그래서 원칙부터 박아놓고 시작했음.
- 기존 계좌 = 대표 계좌(
is_primary)로 자동 마이그레이션 - 신규 추가 = 무조건
PENDING상태로 시작 - 승인을 통과해야
ACTIVE, 그 이후로만 정산 대상에 포함 - 대표 계좌는 파트너당 정확히 1개 (부분 UNIQUE 인덱스로 강제)
| 상태 | 의미 | 정산 포함 |
|---|---|---|
| PENDING | 승인 대기 | X |
| ACTIVE | 승인 완료 | O |
| REJECTED | 반려 | X |
| ARCHIVED | 사용 중지 | X |
승인 플로우의 함정
처음엔 단순하게 "관리자가 승인 누르면 ACTIVE"로 짰음. QA 돌리다가 두 군데서 터짐.
Case 1: PENDING 상태에서 파트너가 같은 계좌를 또 신청
Case 2: 관리자가 승인 누르기 직전, 파트너가 본인이 신청 취소
1번은 (파트너ID, 계좌번호, 상태≠REJECTED) 조건의 부분 UNIQUE 로 막음. 2번은 승인 처리 시점에 상태를 다시 읽어서 트랜잭션 안에서만 전이가 일어나도록 가드를 추가. 낙관적 락 한 줄 안 박았으면 동시성에서 무조건 깨졌을 케이스였음.
화면 분리에서 얻은 것
관리자 영역과 파트너 포털 영역을 별도 진입점으로 쪼갠 게 결과적으로 옳았음. 권한 체크와 필터링 로직이 완전히 달라서, 한쪽에 if-else 로 욱여넣었으면 분기마다 보안 빵꾸 났을 듯. 상세 화면도 관리자용은 승인·반려 액션과 신청 이력 노출, 파트너용은 상태와 반려 사유만 read-only 로 분기.
회고
- 도메인 상태머신을 표로 먼저 그려놓고 시작한 게 디버깅 시간을 절반으로 줄여줌
- "기존 데이터 = 대표 계좌" 마이그레이션은 단순해 보여도, 정산 배치 영향 분석이 사실상 본 작업의 60%였음
- 승인 워크플로우는 단순 boolean 이 아니라 처음부터 상태머신으로 짜야 한다는 걸 또 한 번 체감
- 컨트롤러는 뷰 권한 단위로 쪼개는 게, 길게 보면 분명히 싸게 먹힘
다음
댓글 0
첫 댓글 달아줘.