포인트 지급은 더하기가 아니라 상태 전이였다

콘텐츠를 공개하면 포인트를 주고, 비공개나 삭제 때는 조건에 따라 차감하는 기능을 다뤘다. 기능 이름만 보면 덧셈과 뺄셈이다. 하지만 실제로 어려웠던 것은 얼마를 더할지가 아니라 지금 이 변경이 지급 대상인지 판단하는 일이었다.

현재 상태만 보면 놓치는 것

콘텐츠가 공개 상태라는 사실만으로 새로 포인트를 줘도 되는지는 알 수 없다. 처음 공개된 것인지, 이미 공개된 콘텐츠를 수정한 것인지, 비공개 뒤 다시 공개한 것인지가 다르기 때문이다. 차감 역시 현재 비공개라는 이유만으로 실행하면 이전 지급 여부와 맞지 않을 수 있다.

당시에는 SQL 조건과 서비스 분기에서 이런 차이를 다뤘다. newAccumulatePoint와 newDeductPoint처럼 지급·차감의 진입점은 나눌 수 있어도, 두 메서드가 바라보는 정책은 서로 맞아야 했다. 한쪽만 고치면 반대 행동이 원래 상태로 돌아가지 않는다.

다시 설계한다면 먼저 만들 표

변화	먼저 확인할 질문
비공개 → 공개	이번 공개가 신규 지급 대상인가?
공개 → 공개	내용 수정인가, 새로운 지급 사건인가?
공개 → 비공개	취소할 지급 이력이 있는가?
비공개 → 삭제	이미 차감된 건을 다시 차감하는가?

이 표는 당시 회사의 상세 정책을 공개한 것이 아니라, 같은 유형의 기능을 검토하기 위한 질문이다. 정책마다 재공개 지급 규칙은 다를 수 있다. 그래서 코드를 쓰기 전에 결정해야 한다.

버튼을 막는 것만으로는 충분하지 않다

연속 클릭을 프론트에서 막아도 동일 요청이 다시 들어올 가능성은 남는다. 지금이라면 어떤 사건을 하나의 지급으로 볼지 식별자를 먼저 정하고, 저장 단계에서 중복을 어떻게 다룰지 검토하겠다. 실제 적용 여부와 별개로, 잔액만 보고는 같은 사건이 두 번 반영됐는지 설명하기 어렵다는 점은 분명하다.

당시의 모든 경로가 자동 검증됐다고 말할 수는 없다. 그래서 이 회고에서 남기고 싶은 것은 구현의 완벽함이 아니라 사고방식의 변화다. 포인트 기능을 다시 맡으면 “지급 함수를 어디서 호출할까?”보다 “어떤 상태 변화가 지급 한 건인가?”부터 적겠다. 금액은 그 사건에 붙는 값이었다.

관련 기록: 운영 프로젝트에서 풀스택으로 일한 경험