원장 검증 자동화로 결제 흐름 신뢰성 확보
목차
결제 플랫폼의 내부 원장 관리 유틸리티에 대한 golden master 단위 테스트를 작성했다. jeju Step 4 진행 전 필수 선행 작업이었는데, 이게 단순한 테스트 추가가 아니라 팀이 품질을 어디까지 담보할지에 대한 의사결정 포인트였다.
왜 이 시점에 테스트가 필요했나
InternalLedgerUtil의 selfCheck 함수는 내부 원장의 무결성을 자체 검증하는 핵심 유틸리티다. 결제 시스템에서 "검증"은 단순한 기능이 아니다. 잔액 계산, 거래 기록 일관성, 이중 계산 방지 같은 것들이 정확하지 않으면 단순히 버그를 넘어 재정상 손실로 이어진다.
jeju Step 4는 아마도 원장 기반 정산이나 결산 로직이 들어가는 단계일 텐데, 그 단계로 진행하려면 기초 검증 로직부터 신뢰할 수 있어야 한다. 팀으로서 "우리 원장이 정말 안전한가"를 선행적으로 검증하는 게이트를 두는 거였다. 마일스톤 진행 전에 요구 사항을 명확히 하는 플로우를 만든 셈이다.
Golden Master 패턴으로 안정성 보장
golden master 단위 테스트는 "특정 입력에 대해 현재 구현이 내보내는 정확한 결과값을 기준값으로 저장하고, 그 이후로 같은 입력이 들어올 때마다 그 기준값과 일치하는지 검증하는" 패턴이다.
Given: 특정 원장 상태 (거래 기록, 잔액 등)
When: selfCheck() 호출
Then: 기대하는 검증 결과가 정확히 그대로 나와야 함
(이후 변경으로 인한 회귀 방지)
이 패턴이 좋은 이유는, 특히 결제 도메인에서 "현재 동작이 올바르다고 가정하고" 그것을 기준값으로 삼는다는 점이다. 별도의 외부 검증(예: 엑셀 스프레드시트로 손 계산)이 어려운 복잡한 로직 같은 경우, "우리가 합의한 이 출력값이 맞다"는 것을 팀이 한 번 검증하고 나면, 그 이후의 모든 변경은 이 golden master 값과 일치해야 한다는 게 자동 보증이 된다.
테스트 추가의 팀 임팩트
결제 관련 로직에 단위 테스트가 없다는 것 자체가 위험 신호다. 누군가 리팩토링이나 최적화를 하다가 실수로 검증 로직을 건드릴 수 있고, 그때 런타임에 터질 버그는 프로덕션에 영향을 미친다. 반대로 이 테스트가 자동으로 실행되면:
- PR 검토 시 "selfCheck 로직을 건드렸나?"를 명시적으로 확인 가능
- CI/CD 파이프라인에서 자동 보증—의존하는 다운스트림 단계(Step 5, 6...)로의 버그 파급 원천 차단
- 신규 팀원이 온라인 코드를 읽을 때, 테스트가 있으면 "이 함수의 동작"을 빠르게 파악
특히 jeju 프로젝트처럼 단계별로 기능이 누적되는 경우, 각 단계의 "선행 게이트"가 단단할수록 뒤의 단계들이 안정적이다. 팀장 입장에서는 "Step 4 들어가기 전에 Step 3의 기초 부품을 테스트로 검증했다"는 체크리스트 항목을 하나 더 만드는 의미다.
배운 점
이 작업을 하면서 느낀 건, 결제·금융 도메인은 "버그가 나중에 로그로 드러나는" 일반 기능과 다르다는 것이다. 잘못된 원장 검증이 프로덕션에서 한두 달을 조용히 누적되다가 정산 시점에 터질 수 있다. 그럼 그때 "어느 거래에서부터 문제였나"를 추적하는 데 며칠이 걸린다.
따라서 "이 유틸리티는 당연히 테스트가 있을 거겠지"라고 가정하면 안 된다. 팀이 중요하다고 판단한 로직일수록 사전에 명시적으로 테스트를 요구하고, golden master 같은 방식으로 기준값을 고정해서 회귀를 방지해야 한다. 그게 팀의 신뢰성과 직결된다.
다음 단계로 jeju Step 4 진행할 때는 이 테스트가 지속적으로 패스되는지 모니터링하고, 필요하면 selfCheck 로직 자체를 더 강화하는 작업으로 이어질 수 있을 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.