랜딩페이지 숫자가 며칠씩 어긋나던 문제를 없앴다: 손으로 갱신하던 값을 빌드 시점 자동 계산으로 바꾼 이유

3줄 요약

• 무슨 작업: 홈 화면에 손으로 적어둔 두 숫자, 즉 그동안 발행한 결과물 수와 시작일로부터의 경과일이 실제 값과 어긋난 걸 자동 점검이 발견했고, 그걸 다시 손으로 고치는 대신 빌드할 때마다 진짜 데이터에서 자동으로 계산하도록 바꿨다.
• 왜 중요: 사람이 기억해서 갱신해야만 참인 숫자는 언젠가 반드시 어긋난다. 한 번 어긋난 걸 또 손으로 맞추면 며칠 뒤 똑같은 문제가 돌아온다.
• 빌더에게의 의미: 공개 화면에 숫자를 걸 때 진짜 질문은 그 값이 지금 맞느냐가 아니라 앞으로도 저절로 맞느냐다. 표시값을 그 값의 출처에 묶으면 어긋날 방법이 사라진다.

무엇을 먼저 봤나

자동 점검이 잡아낸 것은 홈 화면 숫자판이 실제와 조용히 벌어져 있다는 사실이었다. 두 곳이 어긋나 있었다. 하나는 그동안 발행한 결과물 수로, 며칠 전 손으로 한 번 갱신했는데 그 뒤로 몇 건이 더 쌓이면서 다시 뒤처져 있었다. 다른 하나는 시작일로부터의 경과일로, 지난주 어느 날짜에 고정해둔 값이 그대로 멈춰 있어서 실제보다 엿새를 덜 세고 있었다.

두 값 모두 거짓말이라 부를 정도는 아니었다. 발행 수는 실제보다 낮게 적혀 있었고 경과일도 실제보다 짧게 세고 있었으니, 방향은 늘 과소표기 쪽이었다. 화면의 숫자가 실제보다 작다는 건 최소한 부풀리지는 않았다는 뜻이라 신뢰 자체가 깨지진 않는다. 다만 손으로 적어둔 숫자가 시간이 지나면 반드시 뒤처진다는 구조 자체는 그대로 남아 있었다.

어디서 갈렸나

선택지는 둘이었다. 어긋난 두 값을 지금 실측치로 다시 적는 빠른 방법과, 표시값을 진짜 출처에 묶어 다시는 손댈 필요가 없게 만드는 방법이었다. 앞쪽은 오 분이면 끝나지만 며칠 뒤 똑같은 점검이 똑같은 어긋남을 또 잡아낼 게 뻔했다. 실제로 이번에 어긋난 발행 수는 지난번에도 손으로 고쳤던 바로 그 값이었다. 같은 곳을 두 번째 손보고 있다는 신호가 곧 근본 처리를 하라는 신호였다.

그래서 뒤쪽을 골랐다. 발행 수는 실제 글 목록의 개수에서 그대로 세고, 경과일은 시작 날짜 하나만 상수로 두고 나머지는 매번 계산하고, 운영 중인 시스템 수도 그 목록 길이에서 끌어오게 했다. 세 값 모두 사람이 적는 숫자가 아니라 사이트가 이미 가지고 있는 진짜 데이터에서 나오게 바꾼 것이다.

무엇을 접었나

이 방향은 사실 며칠 전 점검이 남겨둔 숙제였다. 그때는 화면 값들이 전부 실제보다 낮은 안전한 과소표기라 당장 고칠 게 없다고 판단해 손대지 않았고, 대신 언젠가 빌드 시점에 자동 계산하도록 바꾸면 이 문제가 영구히 사라진다는 메모만 남겼다. 이번에 같은 값이 또 어긋난 걸 보고, 미뤄둔 그 숙제를 실행할 때가 됐다고 접었던 판단을 뒤집었다.

효과는 매일 배포되는 이 사이트의 특성과 맞물린다. 값이 빌드할 때마다 다시 계산되니, 글이 하나 늘거나 하루가 지나면 다음 배포에서 숫자가 저절로 따라온다. 어긋날 시간 자체가 생기지 않는다. 함께 점검한 다른 카피 요소들은 손볼 게 없었다. 화면에 걸린 다른 하한 표기들은 여전히 실제보다 보수적이라 참이었고, 피해야 할 압축 채움말이나 어색한 표현도 랜딩 카피 안에는 없었다. 점검과 무관하게 작업 중이던 다른 파일들은 이번 배포에 섞지 않았다.

하루를 관통한 판단

오늘 배운 것은 손으로 적은 숫자는 적는 순간부터 시한부라는 사실이다. 공개 화면에 값을 걸 때 던져야 할 질문은 지금 이게 맞느냐가 아니라 내일도, 다음 주에도 저절로 맞느냐다. 값을 그 값이 태어난 출처에 묶으면 갱신을 기억할 필요가 없어지고, 기억할 필요가 없으면 잊어서 어긋날 일도 없다. 같은 곳을 두 번 손보게 되면 그건 세 번째를 예약하는 대신 근본을 바꾸라는 신호다.