인수·마무리 제안 · 동작 데모 포함

결제·정산 기능
인수 및 마무리 제안서

돈이 오가는 기능에서 중요한 것은 빨리 만드는 것이 아니라 틀리지 않는 것입니다

신영진 | 풀스택 개발 · 시스템 운영

운영에서 실제로 필요한 화면을 만들어 봤습니다

결제·정산은 기능이 동작하는 것보다, 문제가 생겼을 때 어디서 틀어졌는지 보이는 것이 중요합니다

결제 원장

요청부터 승인·취소까지 한 줄로 추적합니다. 웹훅 미수신 건을 따로 표시해 이중 결제로 번지기 전에 잡습니다

정산 대사

집계와 지급 사이에 확인 단계를 둡니다. 차이가 있으면 지급 전에 멈춥니다. 송금은 되돌리기 어렵기 때문입니다

이중 송금을 막는 구조

정산에서 가장 큰 사고는 이중 송금이며, 이를 막는 장치가 없으면 재시도 자체가 위험해집니다

1요청마다 고유 키네트워크가 끊겨 응답을 못 받으면 서버는 다시 요청합니다. 고유 키가 있으면 두 번째 요청은 기존 결과만 반환하고 실제 송금은 하지 않습니다

2실패는 사유별로통신 오류는 재시도, 예금주 불일치는 자동 재시도 중단 후 담당자 확인으로. 구분 없이 반복하면 로그만 쌓입니다

3기록이 남는 것언제 무엇을 왜 보냈는지 남아야 파트너 문의에 답할 수 있습니다

3주 안에 무엇을 먼저 할지

기간이 짧아 순서가 결과를 좌우합니다. 인수 후 바로 개발에 들어가지 않는 것을 제안드립니다

11주차 — 경계 확인넘겨받은 코드에서 어디까지가 실제 동작이고 어디부터가 mock인지 먼저 구분합니다. 대표님도 이 부분이 불확실하다고 하셨으므로, 목록으로 만들어 함께 확인한 뒤 범위를 확정합니다

21주차 — 테스트 결제 완주토스 테스트 환경에서 결제 한 건을 요청부터 승인·웹훅 수신까지 실제로 통과시켜 봅니다. 여기서 막히면 그것이 첫 번째 과업입니다

32주차 — 결제 안정화웹훅 중복·누락 처리, 승인과 원장 불일치 대사, 취소·부분취소 흐름

43주차 — 정산·지급정산 집계와 대사, 지급대행 연동, 멱등키 적용, 실패 처리. 마지막에 테스트 환경에서 전 구간 1건 완주

왜 코드 파악에 1주를 쓰는가 — 결제·정산은 잘못 건드리면 금액이 틀어지는 영역입니다. 구조를 모르는 상태에서 고치면 겉으로는 동작해도 특정 상황에서만 어긋나며, 그런 오류는 운영 중에 발견됩니다. 3주 중 1주를 파악에 쓰는 편이 결과적으로 안전합니다.

결제·정산에서 실제로 걸리는 것들

기능 목록에는 한 줄이지만 운영에서 문제가 되는 지점은 대체로 정해져 있습니다

웹훅 중복 수신	PG는 응답을 못 받으면 같은 알림을 여러 번 보냅니다. 처리 기록을 남겨 이미 처리한 건은 무시해야 하며, 그렇지 않으면 주문이 두 번 잡히거나 정산이 중복됩니다
웹훅 누락	PG에서는 승인됐는데 서버 기록이 없으면 고객은 결제했는데 주문이 없는 상태가 됩니다. 웹훅만 믿지 않고 주기적으로 조회 API로 대사하는 구조가 필요합니다
결제와 주문의 시점 차이	결제 승인과 주문 확정 사이에 오류가 나면 돈은 빠졌는데 주문이 없습니다. 어느 쪽을 먼저 확정하고 실패 시 어떻게 되돌릴지 규칙이 필요합니다
부분 취소	전체 취소보다 부분 취소에서 정산이 어긋나기 쉽습니다. 취소 금액이 어느 정산 주기에 반영되는지 정해두지 않으면 지난 정산과 맞지 않게 됩니다
지급 실패 복구	실패 건을 어떻게 재처리할지 규칙이 없으면 담당자가 수동으로 처리하게 되고, 그 과정에서 이중 송금이 발생합니다

성공적인 마무리의 기준

3주 뒤 무엇이 되어 있으면 끝인지를 먼저 맞추고 싶습니다

1전 구간 1건 완주테스트 환경에서 결제 → 승인 → 정산 집계 → 대사 → 지급까지 끊기지 않고 한 번 통과하는 것. 각 기능이 개별로 되는 것과 이어지는 것은 다릅니다

2같은 요청을 두 번 보내도 안전한 것결제 웹훅과 지급 요청을 의도적으로 중복 발생시켜도 결과가 한 번만 반영되는 것. 검수 항목으로 넣으시길 권합니다

3금액을 설명할 수 있는 것정산 금액이 어떤 결제에서 나왔는지 화면에서 추적되는 것. 파트너 문의에 답할 수 없는 정산은 쓸 수 없습니다

4mock이 남아있지 않은 것인수 시점에 임시로 만들어진 부분이 실제 연동으로 모두 교체되었고, 남은 것이 있다면 목록으로 명시되는 것

확인이 필요한 부분 — ① 토스 계약 상태와 테스트 키 발급 여부 ② 지급대행 계약 진행 상황(심사에 시간이 걸립니다) ③ 정산 주기와 수수료 산정 규칙이 확정되었는지 ④ 현재 코드에서 대표님이 파악하고 계신 미완성 부분 ⑤ 운영 배포 일정과 실거래 개시 시점

틀리지 않는 것을
먼저 보겠습니다

금융권에서 금액이 맞아야 하는 시스템을 다뤄온 관점으로 접근하겠습니다.
데모는 직접 눌러보실 수 있습니다.