파트너 잔액 정산 감사 내부 정책 문서화

문서 작업을 진행했음. tb_partner_balance_audit 가이드 추가 (내부 정책).
변경 파일: 설정/문서 2개

작성 목적

코드에서 바로 읽기 어려운 정책, 설계 결정, 운영 규칙을 문서로 남겼음. "왜 이렇게 구현했는가"에 대한 배경을 기록해두지 않으면 나중에 다시 처음부터 고민하게 됨.

정책 문서화

비즈니스 규칙은 코드에만 있으면 안 됨. 특히 수수료 계산, 상태 전환 조건 같은 핵심 규칙은 문서로 따로 정리해야 새로 합류한 사람이 코드를 역으로 읽어서 규칙을 추론하는 상황을 막을 수 있음.

규칙이 바뀔 때 문서와 코드를 동시에 갱신하는 프로세스가 중요함. 코드만 바꾸고 문서를 안 고치면 다음 번에 문서를 보고 작업하다 실수할 수 있음.

문서 작성 원칙

• Why 중심: What보다 Why가 더 중요함
• 예시 포함: 추상적 설명보다 구체적인 케이스로 설명
• 업데이트 책임: 코드 바뀌면 문서도 같이 업데이트
• 버전 관리: 문서도 코드처럼 git으로 이력 관리

내부 정책 문서는 코드와 마찬가지로 버전 관리 대상임. 나중에 "이 규칙은 어디서 왔지?"라는 질문에 답할 수 있어야 함. 정책이 바뀌었다면 변경 이유와 날짜도 함께 기록하는 것이 좋음.

다음

작업 후기

사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.

특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.

개발 방식

• 변경 전 현재 동작 스크린샷이나 수치 메모
• 수정 후 같은 케이스로 확인
• 관련 화면이 있으면 숫자 cross-check
• 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력

작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.

다음