이번 4개월의 인턴십 중 막바지 한달 조금 넘게 남기고 정산프로세스 개발이라는 큰 임무를 맡게되었다. 많이 촉박한 시간이었지만 성장할 수 있는 큰 기회를 주심에 감사하며 기획부터 설계, 개발까지 어떻게 풀어나갔는지 기록해보고자 한다.
(너무 자세한 정책은 언급하지 않도록 하겠습니다.)

💵 정산

처음 정산을 기획하기 위해 가장 먼저 했던 것은 '정산'에 대한 도메인 이해였다.

민감한 문제라 정산 프로세스, 또는 관련 도메인 개발과 관련한 레퍼런스가 매우 부족했지만 아래와 같은 링크들을 통해 도메인 지식을 조금이라도 습득하고 시작했다.

🔗 정산 도메인 이해에 참고한 링크들

• 용어사전 - 정산 | 토스페이먼츠 개발자센터
• 중개플랫폼은 정산을 어떻게 해야할까요?
• 중개플랫폼 서비스_PG계약 및 연동 관련 안내

정산 프로세스는 여태까지 해온 프로젝트들과 결이 많이 달랐다. 회사의 돈, 회사의 근본적인 설립 이유와 관련된 문제다.
비즈니스가 단순히 무언가 파는 행위를 통해 수익을 얻는 형태였다면 구현이 조금 편할 수 있었겠지만, 내가 근무하고 있는 회사의 비즈니스는 '플랫폼'이었다.
엄격해야하고, 어느때보다 validation, 예외처리가 중요하고 사용자 편의만을 고려할 수 없었다. 다양한 예외처리 및 검증에 따른 userFlow도 더 세세하고 엄격해야했다. 과정을 거치며 오히려 더 정확한 정산을 위해 사용자가 불편한 방향으로 더 바꿔나가기도 했다.

그래서 초기 자료조사부터 기획까지 적어도 기본 정산 프로세스 및 수식에는 오류가 없도록 이사님과 소통을 통해 재차 확인하며 수정해나갔다.

돈과 관련된 로직이어서 백엔드도 걱정되었는데, 이렇게 복잡한 프로세스를 맨땅에서부터 프론트 작업을 한 적은 없었기에, 프론트가 많이 걱정되었다.

자료 조사 및 정리를 통한 Q&A

우선 관리자 정산 관리라는 업무가 주어지고 조사 및 문제 정의/파악을 먼저 하였다.
앞선 자료조사 및 초기 기획을 통해 발생한 궁금증 및 비즈니스적 문제를 정리해 여쭤보고 답변을 받아 다음 기획을 수정해나갔다.

대략적인 Questions는 다음과 같다.

1. 결제대금의 정산 방법
2. 월정산
   : 정산 매출일과 정산 지급일의 정의 및 처리 방식
3. 결제 취소건에 관한 처리
4. 수수료 및 환율 소수점 처리 방식
5. 환율 적용 기준
   : 환율 적용 시점 및 자동 / 수동 여부
6. 실운송료 반영 방식
   : 수동 / 자동 기입 여부
7. 운송료 차액 청구 및 처리 방식
8. 특수한 사례 여부
   : 특정 프로세스(자세한 언급 X)를 요구하는 경우 처리 방식
9. 전금법과 관련 유의사항

추가적으로 개인적으로 써드파티 수수료에 대해 자료 조사를 진행하고, 모든 수수료 차감 방식에 대한 정의 및 수식 정리 이후 최종 정산 수식에 반영될 수 있도록 요청하였다.

1. 페이팔 수수료
   페이팔의 정산 수수료는 4.4% + 0.3USD로 확인했다.

2. 포트원 수수료
   포트원 공식 문서를 통해 결제 대행 수수료 외에는 별도의 추가 수수료가 없음을 확인하였다.

참고로 포트원의 공식 문서가 직관적이고 깔끔하게 정리되어 있어 매우 감탄했다.

이러한 자료 조사를 바탕으로 최종 정산 프로세스에서의 수수료 차감 로직과 관련 요구사항을 구체화하였다.

✅ 요구사항

초기 요구사항은 단순히 ‘정산 기능’을 구축하는 것이었으나, 정산이라는 도메인은 상세 기획 없이 시작이 불가능했다. 소통 과정에서 점차 세부적인 요구사항이 도출되어 해당 내용을 정리하고 기획 및 설계 문서도 계속 수정했다.

자세한 요구사항과 프로세스는 생략하겠다.

주요 요구사항

정산에 필요한 값 수동 기입

• 관리자 페이지에서 각 결제건들에 대해 정산에 필요한 값을 수동 기입할 수 있어야 함.

정산 기능

• 플랫폼 수수료 차감 (정률 방식)
• 결제 대행사(페이팔 등)의 수수료 차감
• 환전 수수료 적용 (정률 + 정액)
• 운송료 확인 및 차액 처리
• 차액이 양수일 경우와 음수일 경우에 따른 분기 처리 및 상태 반영

정산 조회 기능

• 완료된 정산 데이터를 조회할 수 있는 기능 제공

예외 상황

• 수수료 및 운송료 차액을 반영한 최종 정산 금액이 음수인 경우
  : 정산 실패로 간주하며 별도의 액션 필요

특징 및 설계 방향

1. 수출기업 대상 플랫폼 정산 시스템

• 비즈니스가 해외와 국내를 연결하는 플랫폼으로, 정산 과정에서 환율 적용과 통화가 다른(USD, KWR) 수수료 처리 로직이 요구됐다.

2. 수수료 차감 구조

• 수수료는 정률(비율 기반)과 정액(고정 금액) 형태로 구분되며, 각각의 차감 시점과 적용 방식이 달랐다.

3. 환율 적용 필요성

• 고객이 해외에 위치하고 결제가 달러($)로 이루어지기 때문에, 정산 시 환율 적용이 필요하다.
• 달러 결제액을 원화로 환전하는 과정에서 환율 변동성을 고려한 로직이 필요하다.

4. 소수점 처리 방식 논의

• 달러 처리, 환율 계산 및 환전 특성상 소수점이 발생해 소수점 처리 방식에 대한 정의 필요하다.

5. 유사 사례

• 배달의민족과 같은 플랫폼 구조를 기반으로 하지만, 고객이 해외에 위치한다는 점에서 환율 및 국제 거래 수수료를 포함한 추가적인 특성 적용

이러한 특성을 고려하여 정산 시스템 설계는 국제 거래 특성을 반영하고, 수수료와 환율 적용 로직을 현재는 수동적이되, 자동으로 확장 가능하고 유연하게 처리할 수 있도록 고민했다.

설계 방향

이 과정에서 정산 프로세스는 명확히 구분되는 단계들과 각 단계마다 철저한 검증(Validation)이 필요했다.
병렬적으로 처리 가능한 작업은 효율성을 높이기 위해 병렬로 진행하는 방향으로 수정해 나갔다.

또한 우선 초기 스타트업이기 때문에 아직 명확하지 않은 프로세스들은 수동으로 관리할 수 있도록 설계했다. 소프트웨어 개발의 최종 목적은 자동화이지만, 그 전까지는 어느정도 운영을 하며 안정화가 되고 패턴을 찾고 비즈니스를 정리하기 전까지는 수동으로 관리해야 한다는 생각이 들었다.

1. 단계적 처리

• 정산 프로세스를 단계적으로 설계하여 각 단계마다 검증(Validation)을 적용
• 작업의 무결성을 보장하기 위한 로직 강화

2. 병렬 처리

• 각 단계 내에서 병렬로 처리할 수 있는 작업은 효율성을 극대화하기 위해 병렬로 진행

3. 수동 기입 및 자동화의 균형

• 수동 입력이 필요한 초기 단계에서 관리자 작업을 지원하면서, 장기적으로 자동화 가능성을 염두에 둔 설계

기획

위 내용을 토대로 최종 정산 기획 문서에는 아래와 같은 내용을 포함시켰다.

• 개요
• 정산 관련 용어 정의
• 정산 주기 정의
• 정산 상태 및 변경 시점 정의
• 정산 프로세스 기능 요구사항
• 정산 프로세스 다이어그램(정산이라는 프로세스 자체의 관점)
• 정산 과정 서술 및 프로세스 다이어그램
  • 수수료 및 환율 적용 방식 및 순서
  • 운송비 정산 처리
  • 정산 예외 처리 (배송비 차액으로 인해 최종 정산금액이 -인 경우)
  • 소수점 처리 방식
  • 특정 예외 상황
  • 전체 정산 프로세스 플로우
• UI/UX 요구사항

기획의 변화

1. Status의 종류 간소화.

• 초기에는 다양한 Status를 세분화하려 했으나, 관리와 유지보수의 복잡성을 줄이기 위해 Status 종류를 간소화했다.
• 기존에 정의한 정산 상태의 종류 및 네이밍이 ‘정산’이 아닌 ‘지급 관리’에 가깝다고 판단이 되어 핵심 정산 로직에 집중하는 방향으로 재설계하였다.
  (사실 아직도 정산이라는 도메인과 지급이라는 도메인을 같은 것으로 묶어야 하는지, 어느정도 분리되는 개념인지 확신이 서지 않는다. 서비스의 복잡성과 연관성에 따라 달라지겠지만.. 하지만 개인적인 생각으로는 분리하는 것이 확장성 측면에서 좋지 않을까 싶다.)

2. 스케줄링 적용

• 당장 적용 가능한 자동화는 최대한 도입하는 것이 효율적이라 판단하여 매월 결제 테이블로부터 정산 테이블로 데이터를 초기화하는 스케줄링을 적용하였다.
• 무거운 배치 프로세스 대신, @Scheduled 어노테이션과 cron 문법을 활용해 간단하고 가벼운 스케줄링으로 설계했다.

그러나, 수동 초기화도 남겨두었다. 스케줄링 기능이 있긴 하지만 아직 서버의 아키텍처가 Event Driven 형식이 아니기 때문에 스케줄링에 실패하면 다시 시도할 방법이 필요했다.

3. Monthly Summary 테이블 분리

• 기존에는 당월 정산 상태를 매번 정산 테이블에서 당월 기간에 해당하는 컬럼을 조회해야헸다. 하지만 당월 정산상태 조회를 위해 반복적으로 무수한 많은 테이블 사이에서 기간을 필터링하여 조회하는건 매우 비효율적이라는 생각이 들었다. 그래서 따로 당월 정산을 월별로 효율적으로 관리하기 위한 MonthlySettlementSummary라는 테이블로 구별하여 관리하도록 수정했다.

해당 테이블 분리로 얻은 이점은 성능적으로도, 데이터 관리면에서도 많은 이점이 따라왔다.

4. 로그 테이블
언제 초기화가 진행이 되었는지, 정산이 완료되었는지, 누가 정산을 진행 했는지, 스케줄링을 통해 자동으로 진행된 것인지, 수동으로 진행한 것인지 등등을 기록할 로그성 테이블을 두기로 하였다. 우선은 앞서 언급한 3. MonthlySummary 테이블에 해당 로그성 데이터 컬럼들을 두기로 했다. 테이블의 볼륨이 커지고, 정합성이 의심될 때 다시 돌아와서 정규화를 진행해보려 한다.

5. 필터링 적용
서비스 특성상 각 제조사별로 필터링하거나, 정산 상태별로 필터링하여 조회할 수 있어야 한다는 생각이 들었다.
우선은 1. 제조사 2. 정산 상태 필터링만을 두고 필터링 없이도, 필터링을 중복해서도 페이징 조회가 가능하도록 기획했다.

더 추가할 기능들

• 스케줄링 정산 초기화 실패 시 관리자에게 메일 발송

1. 당월 제조사별 건당 정산 합산 기능
   현재는 건당 정산에 그쳐있지만, 조금 더 시간적 여유가 있었다면 당월 제조사별 건당 정산 합산을 보여주는 형태도 추가했을 것이다. 결국 월정산이고, 해당 제조사에게 당월 정산액을 모두 지급해야하기 때문이다.
   하지만 회사의 도메인 특성상, 건당 정산은 필요하다고 판단했다.

또한 아직 환율 적용을 건당 다른 환율 적용인지 일괄 적용인지 결정내려진 것이 아니기도 했고, 환율 직접 입력이라는 요구사항이 있기도 했다.

2. 엑셀 업로드를 통한 필수 정보 업데이트

3. 완료된 정산 보고서 엑셀 다운로드

4. 정산 지급 관리 기능

5. 정산, 매출 대시보드

6. 운송비 정산표 자동 수신 및 반영

7. 자사 문의의 경우 다른 수수료 적용

8. 환율기준일 선택시 환율 자동 적용(?)