7월 1일 이후라는 조건: 정책 시행일을 코드에 넣으며 배운 것

포인트 지급·차감 메서드를 정리할 때 2025년 7월 1일 이후에만 새 처리를 수행하도록 하는 조건이 있었다. LOGIN, CNTNTS, GOOD, GET, SUBSCRIBE처럼 행동 유형도 여러 개였다. 날짜 비교 한 번으로 시작한 일이지만, 돌아보면 정책을 코드로 번역하는 작업이었다.

무엇의 날짜인지부터 필요했다

시행일이 있다는 것만으로 규칙이 완성되지는 않는다. 사용자가 행동한 시간인지 서버가 요청을 받은 시간인지, 저장된 콘텐츠의 생성일인지가 다르다. 재처리하는 요청이라면 실행 시점만으로 판단해도 되는지도 따져야 한다. 당시 조건을 다루며 이런 기준이 함수 이름만으로 드러나지 않는다는 점을 느꼈다.

지금이라면 정책 문장에 기준 시간을 명시하겠다. “시행일 이후 요청”과 “시행일 이후 발생한 사건”을 같은 표현으로 쓰지 않겠다. 시간대와 경계 포함 여부도 함께 정해야 한다. 날짜 문자열이 눈에 익숙하다는 이유로 비교 기준까지 명확해지는 것은 아니다.

환경 분기가 정책을 가리지 않도록

서버 환경에 따라 serverType으로 조건을 나누는 작업도 있었다. 환경 차이가 필요한 경우는 있지만, 업무 규칙과 배포 환경 규칙이 같은 조건문에 섞이면 검토가 어려워진다. “테스트 환경이라 실행하지 않는가”와 “정책상 지급 대상이 아닌가”는 결과가 같아도 원인이 다르다.

다시 한다면 지급 대상 판단과 실제 반영 가능 여부를 나눠 설명하겠다. 예를 들어 판단 결과에 대상 여부와 제외 이유를 남기면, 운영자가 결과를 물었을 때 조건문 전체를 다시 읽는 부담이 줄어든다. 단, 이 구조를 당시 완성했다는 뜻은 아니다. 지금 돌아보며 보완하고 싶은 지점이다.

검증해야 할 것은 평범한 하루가 아니다

시행일 전날, 시행 시각, 직후를 나란히 확인해야 한다. 같은 시점에서 지급과 차감이 동일한 정책을 보는지도 필요하다. 행동 유형마다 적용 여부가 다르다면 날짜와 유형을 조합한 표가 테스트 목록이 된다. 정상적인 날짜 한 건으로는 경계 오류를 발견하기 어렵다.

이 경험을 통해 정책 변경은 숫자나 날짜를 바꾸는 패치가 아니라는 것을 배웠다. 이전 규칙과 새 규칙이 만나는 지점을 설명해야 한다. 다음에는 시행일을 코드에 넣기 전에 “언제 발생한 어떤 행동에 적용하는가”를 한 문장으로 먼저 쓰겠다.

관련 기록: 포인트와 상태 전이