업체별로 지출을 분류하는 화면을 만들고 얼마 안 됐을 때다. 그 자료를 올리는 화면의 마지막 단계에 안내문을 하나 붙여뒀었다.
결과가 달라졌는지 자동으로 검증합니다 (사고 예방)
읽으면 검증이 알아서 도는 걸로 읽힌다. 나도 그렇게 읽었다.
코드는 그렇지 않았다. 사람이 목록 화면에 들어가서 버튼을 눌러야 검증이 돌았다. 안 누르면 0건이다. 하루를 안 누르면 하루치가 밀리는 게 아니라, 그냥 아무것도 검증되지 않은 채로 지나간다.
그 문장을 쓴 것도 나고, 그렇게 안 만든 것도 나다. 거짓말을 하려던 게 아니라 만들려던 것을 이미 만든 것처럼 써놓은 것에 가깝다. 결과는 같다. 화면을 보는 사람은 문장을 믿는다.
발견한 날 바로 자동화를 붙였다. 빌드할 때마다 검증이 같이 돌게 만드는 방식이다. 검증 표본을 코드 저장소 안에 파일로 넣어두고, 테스트가 그걸 읽어서 지금 규칙으로 다시 계산해 답이 달라졌는지 보게 했다.
이러면 문장이 사실이 된다. 사람이 버튼을 안 눌러도 검증이 돌고, 답이 달라졌으면 빌드가 막힌다. 잘못된 규칙이 배포까지 가지 못한다.
만들고 나서 같은 날 되돌렸다.
문제는 표본이 어디에 있느냐였다.
이 검증의 표본은 실무자가 자료를 올릴 때마다 늘어난다. 어떤 가맹점을 어떤 장부 항목으로 봐야 하는지, 실제로 처리된 결과가 그대로 쌓이는 것이라 계속 두꺼워진다. 그런데 그 표본을 코드 저장소 안에 두면, 표본이 하나 늘 때마다 이 사이클을 돌아야 한다.
한 번은 한다. 열 번도 할 수 있다. 그런데 이건 혼자 굴리는 시스템이다. 급한 일이 있는 날엔 건너뛴다. 건너뛰면 표본이 안 늘고, 표본이 안 늘면 그 자동 검증은 살아 있는 채로 아무것도 못 잡는 상태가 된다. 빌드는 계속 초록불이고, 그래서 아무도 이상하다고 생각하지 않는다.
돌아가는 걸 확인하고 되돌렸다. 안 돌아가서가 아니라, 몇 주 뒤에 죽어 있을 게 보여서 되돌렸다.
지속 가능성 문제라고 하면 거창한데, 실제로는 훨씬 단순한 이야기다. 사람이 매번 해야 하는 절차를 전제로 하는 자동화는, 그 사람이 안 하면 그날로 끝난다. 그리고 1인 운영에서 그 사람은 항상 나 하나다.
되돌리고 나서 검증을 두 종류로 갈랐다. 기준은 하나였다 — 표본이 늘어나는가.
안 늘어나는 표본은 자동으로 둔다. 규칙 엔진 자체가 망가졌는지 보는 표본이 여기 해당한다. 커피 체인에서 결제한 건이 어떤 항목으로 분류돼야 하는지 같은, 답이 변하지 않는 케이스들이다. 이런 건 한 번 적어두면 늘릴 일이 없으니 코드 저장소 안에 둬도 아무 비용이 없다. 그래서 이쪽은 지금도 빌드할 때마다 자동으로 돈다.
계속 늘어나는 표본은 사람 손에 맡긴다. 운영에서 쌓이는 실제 처리 결과가 여기다. 이건 저장소가 아니라 데이터베이스에 넣었다. 자료를 올리는 순간 표본도 같이 쌓이니 사람이 옮길 일이 없고, 검증은 화면의 버튼으로 아무 때나 돌린다. 배포 사이클이 아예 안 붙는다.
정리하면 이렇다. 자동화의 비용은 자동화를 만드는 데 드는 게 아니라 자동화에 재료를 대는 데 든다. 재료가 계속 들어와야 하는 자동화는, 재료 대는 일이 수동이면 결국 멈춘다. 그래서 자동으로 만들지 말지를 정하기 전에 재료가 어디서 오는지를 먼저 본다.
문장은 이렇게 바꿨다.
자동으로 검증합니다 → 버튼을 누르면 검증합니다
코드를 문장에 맞추는 대신 문장을 코드에 맞춘 것이다. 후퇴처럼 보이고, 실제로 후퇴가 맞다. 대가도 명확하다. 규칙을 잘못 고쳐도 빌드가 안 막히고, 아무도 버튼을 안 누르면 영원히 안 걸린다.
그걸 알면서 골랐다. 못 지킬 문장을 화면에 걸어두는 쪽이 더 위험하기 때문이다. 화면의 문장은 그걸 읽는 사람의 행동을 바꾼다. "자동으로 검증합니다"를 읽은 사람은 검증을 확인하지 않는다. 확인할 필요가 없다고 적혀 있으니까.
기능이 부족한 것보다 부족한 기능을 충분한 것처럼 적어놓는 쪽이 사고에 가깝다. 앞의 것은 불편하고, 뒤의 것은 사람을 방심시킨다.