카드 결제 PENDING 상태의 발생주의 정산 기준 정책화

내부 정책 문서에 발생주의 카드의 PENDING 상태 처리 방식을 추가했다.

배경: 카드 결제와 PENDING 상태의 모호함

결제 플랫폼을 다루다 보면 "발생주의" vs "현금주의" 같은 회계 원칙과 실제 결제 상태가 자주 엇갈린다. 특히 카드 거래는 승인 요청을 한다고 해서 즉시 돈이 빠지는 게 아니라, 몇 시간에서 며칠에 걸쳐 정산이 진행된다. 그 과정에서 카드사 시스템은 PENDING(대기 중) 상태를 유지하는데, 이게 회계 기록에는 어떻게 반영해야 하는지가 항상 고민 지점이었다.

이 commit은 그런 고민에 대한 하나의 결론을 문서화한 것이다.

결정: 조건부로 PENDING 포함 허용

"발생주의 원칙을 따르면서도 PENDING 카드 거래를 기록해도 된다"는 규칙을 정책으로 정의했다. 다만 무조건 허용하는 게 아니라 조건부라는 게 중요한데:

• 결제 요청이 카드사에 확인된 상태(적어도 요청 수신 확인)여야 함
• PENDING 상태에서 몇 시간 이내 APPROVED/DECLINED 중 하나로 확정될 가능성이 높아야 함
• 만료되거나 무한정 PENDING으로 남을 위험이 낮아야 함

즉, 회계의 관점에서 "이건 거의 확실한 거래다"라고 판단할 수 있는 케이스만 미리 기록하자는 취지다.

왜 정책화했나: 모호함을 없애기 위해

팀이 커질수록, 또 시간이 지날수록 같은 상황을 다르게 해석하는 일이 반복된다. 개발자 A는 PENDING을 "아직 미결정이니 기록하지 말자"로 이해하고, 개발자 B는 "어차피 될 거니까 미리 기록해도 괜찮지 않나"로 생각한다. 그러다 감시 대상 시스템이나 회계 감사 과정에서 "왜 PENDING 거래가 기록되어 있냐"는 질문을 받는다.

이번 정책화는 그런 모호함을 하나의 의사결정 기준으로 문서화해서, 누가 구현하든 같은 로직으로 처리하게 하려는 시도다. 코드 리뷰할 때도 "정책에 맞나 안 맞나"로 평가할 수 있게 된다.

일반론: 회계 정책은 문서가 아니면 깨진다

이 경험에서 배운 게 하나 있다면, 결제/회계 관련 로직은 구두로만으로는 절대 안 된다는 거다. 정산 시 불일치가 나면 "어? 이건 누가 만들었고, 왜 이렇게 했지?"라고 역추적하느라 며칠을 까먹는다. 정책을 먼저 문서화하고, 그걸 기반으로 코드를 짜고, 코드 리뷰할 때 정책과 코드가 일치하는지 체크하는 게 훨씬 효율적이다.

조건부 로직(PENDING 포함 vs 미포함)도 마찬가지. "이 경우엔 포함하고, 이 경우엔 제외한다"는 조건을 명확히 문서화해두면, 나중에 유사한 상황이 생겼을 때 참고 가능한 패턴이 된다.