반환금 실제 확정치로 정정

웰컴 관련 반환금 산정 기록을 팀 공유 문서에 정정하는 커밋을 올렸다. 기준 금액 6,995,000에서 실제 반환액 5,031,225로 조정하고, 위약금과 상품권 조정 내역을 함께 문서화했다. 숫자 두 개 바꾸는 작업이지만, 이게 발생하는 배경과 어떻게 다뤄야 하는지, 팀 차원에서 무슨 의미인지를 짚어두고 싶었다.

정산 수치가 중간에 바뀌는 건 거의 피하기 어렵다. 계약이나 합의 단계에서 산정하는 금액은 당시의 조건과 예측을 기반으로 한 잠정치에 가깝다. 실제 지급 단계로 넘어오면 그사이에 발생한 항목들이 붙는다. 위약금 공제가 생기거나, 상품권 사용 내역이 반영되거나, 실제 청구 금액이 예상치와 어긋나거나. 이 변수들이 누적되면서 최종 반환액이 확정된다.

기준 금액 6,995,000은 시작점이고, 실제 반환액 5,031,225는 그 이후 여러 조정을 거친 끝점이다. 약 1,963,775의 차이가 생겼는데, 이게 계산 실수가 아니라 위약금과 상품권 조정을 포함한 공제 항목들의 합산 결과라는 점이 중요하다. 그 경위를 문서에 남기는 게 이번 커밋의 핵심이다.

수치를 문서화할 때 빠지기 쉬운 함정

정산 관련 수치를 팀 공유 문서에 관리할 때 단순히 숫자만 갱신하고 끝내는 경우가 많다. 그렇게 하면 나중에 반드시 구멍이 생긴다. 숫자가 다르다는 사실보다 왜 다른가가 문서에 있어야 한다. 나중에 누군가 이 수치를 보고 의문을 제기했을 때, 그 답이 이미 커밋 메시지나 문서 코멘트에 있으면 사람이 확인하는 과정을 거치지 않아도 된다.

이번처럼 기준 금액에서 실제 반환액으로 바뀌는 흐름을 정리하면:

계약 기준 금액  : 6,995,000
  위약금 공제   : (해당 금액)
  상품권 조정   : (해당 금액)
────────────────────────────
실제 반환액     : 5,031,225

이 구조를 문서에 담아두면 차이의 경위가 명확해진다. 커밋에도 이 맥락을 메시지로 남기면 git log나 blame으로 변경 이력을 추적할 수 있다. 숫자만 바꾸면 "누가 언제 바꿨는지"는 알아도 "왜 바꿨는지"는 모른다. 이 차이가 나중에 감사 대응이나 문의 처리할 때 크게 체감된다.

수치 관리에서 흔히 빠지는 실수들을 정리하면 이렇다:

같은 수치가 예상/잠정/확정 중 어느 단계인지를 표시하지 않으면, 읽는 쪽에서는 그게 확정된 줄 안다. 이 수치를 근거로 보고하거나 결정을 내렸다가 나중에 "그건 잠정치였어요"라는 말이 나오면 곤란해진다.

단일 원본 문제는 팀이 조금만 커져도 심해진다. 같은 정산 수치가 메신저 핀 메시지에도 있고, 팀 위키에도 있고, 공유 문서에도 있으면, 어느 순간 셋이 다 다른 값을 가리키게 된다. 어느 게 맞는지 확인하는 데 들어가는 시간이 조용히 쌓인다. 최악은 회의 중에 두 숫자가 나란히 등장할 때다. "어디에 있는 게 맞아요?"라고 묻는 순간, 이미 그 자리의 신뢰도가 흔들린다.

갱신 타이밍을 습관으로 만들어야 하는 이유

이번 정정에서 주목하고 싶은 건 수치 자체보다 갱신한 타이밍이다. 실제 반환액이 확정된 시점에 바로 공유 문서를 따라갔다.

이 타이밍을 놓치는 패턴이 있다. 정산 담당자가 최종 수치를 확인하고 거래는 완료하는데, 공유 문서 갱신은 "급하지 않으니까 나중에"로 넘어간다. 그러면 문서가 stale한 상태로 며칠, 길면 몇 주가 간다. 그사이에 다른 팀원이 그 문서를 열고, 잘못된 수치를 근거로 보고하거나 결정을 내린다. 이게 드러나면 "저도 그 문서 봤는데 다른 숫자 있어서 헷갈렸다"는 말이 나오고, 문서 신뢰도 자체에 의문이 붙는다.

.claude/CLAUDE.md 같은 팀 공유 문서는 다양한 컨텍스트에서 참조되는 구조다. 거기 적힌 수치가 맞다는 전제로 판단이 이뤄지는 문서이기 때문에, stale 값이 하나라도 있으면 그 전제가 흔들린다. 적힌 값이 틀리면 그걸 기반으로 내린 판단도 같이 틀려지는데, 이게 드러나는 시점이 항상 나쁠 때다. 조용한 내부 검토 자리가 아니라, 외부와의 커뮤니케이션이나 중요한 의사결정 자리에서 발견된다.

이런 상황을 막는 방법은 복잡하지 않다. 정산이 확정되는 순간 관련 공유 문서도 따라가는 걸 별도의 태스크로 보지 않고, 정산 프로세스의 마지막 단계로 보는 것이다. "정산 완료 - 공유 문서 반영 - 커밋" 이 세 단계를 하나의 흐름으로 처리하면 갱신이 밀릴 일이 없다.

팀장 입장에서 이런 정정 커밋이 반가운 건 이 루프가 팀 안에서 작동하고 있다는 신호이기 때문이다. 누군가 보고서를 검토하다 공유 문서가 오래됐다는 걸 발견하고, 확인하고, 반영했다. 이 루프가 습관으로 자리 잡은 팀은 회의에서 문서를 열었을 때 거기 있는 숫자를 믿을 수 있다. "이게 최신이에요?" 라고 확인하는 시간이 필요 없다. 그 신뢰가 쌓이면 공유 문서가 실제 의사결정에 쓰이는 도구가 된다. 반대로 신뢰가 없으면 문서를 열람만 하고 판단은 별도로 확인하게 되고, 결국 문서가 유지보수 부담만 있고 쓸모는 없는 상태가 된다.

작은 정정 커밋 하나지만, 이 방향이 쌓이면 팀 전체의 정보 신뢰도가 달라진다.