틀린 문장은 얼마나 오래 살아남는가

8월 14일에 소개 페이지에 문장 하나가 올라갔습니다. 우리는 이탈률과 페이지 체류 시간을 일부러 재지 않는다는 것, 둘 다 페이지 조회에 걸쳐 따라가는 세션이 필요하고 그러려면 삽입한 사이트에 동의 배너가 필요하기 때문이라는 내용이었습니다.

8월 27일에 페이지 체류 시간을 내보냈습니다. 문장은 그대로 있었습니다.

열사흘 참, 스물여덟 시간 거짓

날짜가 정확한 것은 저장소가 알고 있기 때문입니다. 문장은 8월 14일 22시 41분에 도착합니다. 여섯 구간으로 나뉜 체류 시간은 8월 27일 17시 53분에 도착하고 — 그 분부터 문장의 뒤 절반이 거짓입니다. 8월 28일 21시 57분에 고쳐집니다.

그러니 열사흘 옳았고 스물여덟 시간 틀렸습니다. 좋은 비율처럼 들리는데, 다음 관찰이 나오기 전까지만 그렇습니다. 그 스물여덟 시간 안에 그것을 끝낼 것은 아무것도 없었습니다. 실패한 시험도, 울린 확인도 없었습니다. 페이지는 그려졌고, 기능은 작동했고, 둘은 열한 개 언어로 조용히 서로 모순되었습니다.

왜 어떤 확인도 잡을 수 없었는가

이 프로젝트의 모든 자동 확인은 시스템 안에 있는 두 가지를 견줍니다. 줄 수를 열하나에, 이름표 너비를 주어진 자리에, 표 목록을 스키마에 맞대는 식입니다. 페이지의 주장은 무엇과도 견줄 수 없습니다. 세상에 관한 산문이고, 이 경우 그 세상은 코드의 전혀 다른 부분에서 만들어진 표였습니다.

소개 글에서 기능 이름을 grep해 찾아보는 확인은 상상할 수 있습니다. 길고 부서지기 쉬울 테고, 그러고도 흥미로운 경우는 놓칠 것입니다. 그 문장은 표를 이름 붙이지 않았기 때문입니다. 까닭을 이름 붙였습니다. 그러려면 동의 배너가 필요하다고 말입니다. 그 까닭이 조용히 적용되기를 그쳤습니다.

무엇이 그것을 끝냈는가

물음 하나입니다. 누군가 이탈률을 보여 주느냐고 물었고, 정직한 답을 하려니 그 옆의 문장을 읽어야 했으며, 그때 그것이 무너졌습니다.

이달 초에 이 페이지에서 다른 주장 넷을 내린 것과 같은 방식이고, 그것은 방식이 아니라 운입니다. 확률을 높이는 유일한 것은 주장을 확인할 수 있을 만큼 좁게 쓰는 일입니다. «우리는 X를 재지 않는다, 왜냐하면 Y»가 아니라 «X는 이 페이지에 없다»라고 말입니다 — 그 뒤의 까닭이 아니라 자기가 놓인 페이지를 설명하는 문장입니다.

무엇이 일반화되는가

코드는 시끄럽게 삭습니다. 코드에 관한 산문은 조용히 삭고, 대개 코드가 나아지는 바로 그 순간에 삽니다.

문장 하나를 고치는 데 열세 곳을 고쳐야 했습니다. 인터페이스 문자열 하나의 열한 개 언어판과, 손으로 쓴 HTML 두 문단입니다. 다음 설명을 쓰기 전에 알아 둘 값어치가 있는 숫자입니다. 자기가 인쇄된 페이지 너머로 손을 뻗는 모든 주장의 값이니까요.