정산 최종 보고서를 저장소에 기록한 이유

결제 플랫폼과의 정산 완료 보고서를 깃 저장소에 PDF로 보관하기 시작했다. 한 줄 커밋이지만, 이 뒤에는 우리 팀이 결제 도메인에서 배운 작은 실수들이 담겨 있다.

정산이라는 일이 "한 번 끝"이 아닌 이유

우리 서비스가 어느 규모에 도달하면, 매월/분기별로 외부 결제 플랫폼과 정산을 진행한다. 발생한 거래액, 수수료, 환급액 등을 맞춰보고, 최종 확정된 보고서를 받는다. 이 보고서는 단순한 '거래 내역 목록'이 아니다:

• 법적 근거: 재무감시, 세무 신고, 감사 기록의 기초
• 문제 추적: 거래 오류가 발생했을 때, 언제 어떤 정산에 포함됐는지 확인
• 팀 협력: 재무팀, 경영진, 때론 외부감시자까지 같은 보고서를 본다

초기에는 이 PDF를 슬랙에 올리고, 누군가의 로컬 폴더에 저장했다. 특별히 문제없어 보였다. 3개월 후, 누군가가 "6월 정산보고서 다시 달라"고 물었고, 그 파일이 어디 있는지 찾는 데 30분이 걸렸다.

"아, 이건 코드처럼 관리해야 하네"

그 경험 이후 깨달은 게 있다. 정산보고서같이 일회성이지만 장기 참조되는 산출물은, 깃 같은 버전관리 시스템에 아카이브해야 한다는 것. 왜인가:

이 경우 파일 경로는 다음처럼 구성했다:

reports/
├── financial/
│   └── payments/
│       ├── report_20260611_1220_웰컴페이-정산종결보고.pdf
│       ├── report_20260512_1100_웰컴페이-정산종결보고.pdf
│       └── ...

날짜+시간+서비스명을 파일명에 넣음으로써, 그 자체로 생성 시점과 어느 결제 플랫폼인지 한눈에 알 수 있다. 커밋 메시지에 "docs(report): ..."라고 기록하면, 나중에 git log -- reports/ 한 줄로 정산 이력을 추적할 수 있다.

타이밍 문제와 책임 분산

혼자였다면 안 했을 것이다. 하지만 팀이 커지면서 생긴 변화가 있다. 초기에는 내가 정산 완료 이메일을 받으면, 직접 파일을 열어보고 "아, 이번 달은 이렇구나" 하고 넘어갔다. 지금은:

• 재무팀이 보고서를 먼저 본다
• 나는 기술적 오류(중복 거래, 취소 오류 등)가 없는지 검토한다
• 팀 리드는 매출 추이를 보고, 경영진께 리포팅한다

이 과정에서 "어라, 저번 달 정산 보고서가 또 필요한데?"라는 요청이 생긴다. 누군가 메일을 찾아야 하고, 첨부 파일을 다시 요청해야 하고—이미 비효율이다. 저장소에 있으면 누구든 git checkout 한 번으로 접근한다. 책임을 분산하되, 정보는 중앙화하는 셈이다.

작은 습관의 힘

이건 fancy한 기술이 아니다. 자동화도, 복잡한 아키텍처도 없다. 다만:

• 정산 완료될 때마다 자동으로 PDF를 저장소에 올리는 스크립트
• 그에 맞춘 일관된 파일 명명 규칙
• 팀원들이 알아둘 그 경로의 위치

이 세 가지가 생기면, 나중에 "재정 감시가 필요하다", "예전 거래를 증명해야 한다" 같은 상황에서 얼마나 빠르게 대응할 수 있는지가 달라진다. 결제 시스템에서 "한 번 끝"이라는 생각이 가장 위험한 이유가 여기다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.