내 랜딩페이지 숫자를 스스로 감사한 날: 공개 수치가 절대 부풀지 않게 설계하는 법

3줄 요약

오늘 한 일은 홈에 뜨는 공개 수치(누적 편수, 프로젝트 수, 운영 일수)가 실제 데이터와 어긋나지 않는지 자동으로 감사하고, 어긋나더라도 거짓말은 안 되게 설계돼 있는지 확인한 것이다.
이게 중요한 이유는 "Receipts not promises"를 내건 사이트에서 숫자 하나가 실제보다 부풀면 정체성 전체가 흔들리기 때문이다.
여러 시스템을 혼자 굴리는 운영자에게, 숫자가 틀릴 수 있다는 전제를 인정하고 항상 안전한 방향으로만 틀리게 설계하는 것이 곧 신뢰의 기술이다.

공개 숫자는 반드시 실제와 벌어진다

오늘 감사의 출발점은 하나의 사실을 인정하는 것이었다. 홈 화면에 손으로 적어둔 숫자는 시간이 지나면 실제 데이터와 반드시 벌어진다. 글은 매일 늘고 프로젝트는 생겼다 접혔다 하는데, 화면의 숫자는 그날 적어둔 값에 멈춰 있기 때문이다. 문제는 벌어진다는 사실 자체가 아니라, 어느 방향으로 벌어지느냐다.

그래서 확인한 항목은 여섯 가지였다. 홈에 뜬 누적 편수가 실제 글 수보다 큰지 작은지, 프로젝트 카운트가 실제로 살아 있는 시스템 수를 넘어서지 않는지, 화면에 이름을 올린 시스템이 전부 실재하는 유령 없는 목록인지, 그리고 금지어나 오타가 섞여 있지 않은지를 하나씩 대조했다.

부풀리지 않으려면 항상 과소표기하도록 만든다

핵심 설계 원칙은 이것이었다. 손으로 적는 숫자에는 반드시 플러스 기호를 붙여서, 실제 값이 그보다 크거나 같다는 뜻으로만 읽히게 한다. 누적 편수를 "백열하나 이상"이라고 적어두면, 실제 편수가 백열여섯으로 늘어도 그 표기는 여전히 참이다. 실제가 표기보다 크기만 하면 거짓말이 아니기 때문이다.

이게 왜 중요하냐면, 숫자가 드리프트하는 걸 완전히 막는 건 불가능하기 때문이다. 매일 손으로 갱신하지 않는 한 화면의 값은 낡는다. 그렇다면 낡는 방향을 미리 정해두면 된다. 표기를 항상 실제보다 작게 잡아두면, 시간이 흐를수록 격차는 벌어지되 언제나 안전한 쪽으로만 벌어진다. 감사 결과도 그랬다. 화면의 모든 숫자가 실제 값 이하의 보수적인 하한이었다. 과장은 한 건도 없었고, 화면에 오른 시스템은 전부 실제로 돌아가는 것들이었다.

감사는 자동으로 돌되 결과는 사람이 읽는다

이번 점검에서 확인한 또 하나는, 자동 감사가 "고칠 게 없음"이라는 결론도 하나의 유효한 산출물이라는 점이다. 매일 도는 점검이 여섯 항목을 대조하고, 모두 정합하면 아무것도 커밋하지 않고 조용히 끝난다. 억지로 글을 만들거나 불필요한 수정을 밀어넣지 않는다. 문제가 없을 때 침묵하는 것도 시스템의 정직함이다.

다만 한 가지는 다음 숙제로 남겼다. 지금은 숫자를 손으로 적고 자동 감사가 뒤에서 검증하는 구조인데, 더 나은 방향은 빌드 시점에 실제 데이터에서 숫자를 자동으로 뽑아 화면에 꽂는 것이다. 그러면 손으로 적는 값 자체가 사라지고, 드리프트도 원천적으로 없어진다. 오늘은 그 전 단계로, 현재의 하한 표기 방식이 최소한 거짓말은 안 한다는 걸 확인해둔 셈이다.

오늘 관통한 판단

오늘 하루를 관통한 생각은 하나다. 완벽하게 정확한 숫자를 유지하는 것보다, 틀리더라도 항상 안전한 방향으로만 틀리게 설계하는 것이 현실적이고 더 정직하다. 사람이 손으로 적는 값은 언젠가 낡는다는 걸 부정하지 않고, 대신 낡는 방향을 미리 정해 과소표기로 고정한다. 그리고 그게 지켜지는지 매일 자동으로 되짚는다. 약속이 아니라 확인된 결과를 남긴다는 원칙은, 남에게 보이는 숫자를 나 자신부터 의심하는 데서 시작한다.