카운터 번호를 이제 두 표에 맞대어 확인합니다

여기 카운터에는 저마다 번호가 있습니다. 삽입 코드에도, 통계 주소에도, 주인이 넣어 둔 모든 페이지에도 나옵니다. 번호는 100과 9,999,999,999 사이에서 무작위로 하나를 골라 이미 쓰이는지 확인해 내줍니다.

표 하나를 확인합니다.

다른 표

오랫동안 조회를 기록하지 않은 카운터는 보관 표로 옮겨집니다. 평범한 살림입니다 — 작업 표를 작게 유지하고 그에 대한 조회를 빠르게 합니다. 2026년 8월 24일에 보관 표에는 212,771개의 번호가 있었고, 그 가운데 하나도 생성기가 확인하는 표에 없었습니다.

그러니 그 하나하나가 다시 내줄 수 있는 상태였습니다.

가능한 번호 백억에 맞대면 충돌 확률은 대략 0.002퍼센트입니다. 새 카운터 47,000개 가운데 하나쯤이 남의 것이었던 번호를 받게 됩니다. 그러니 드물기는 하지만, 추상적인 이야기는 아닙니다. 보관된 카운터가 보관된 것은 바로 그 페이지가 조용해졌기 때문이지만 — 조용한 페이지가 반드시 지워진 페이지는 아닙니다. 옛 삽입이 잊힌 옆칸 어딘가에 아직 있고 그 페이지에 방문자가 온다면, 그 조회는 몇 해 뒤에 만들어진 카운터 위에서 낯선 사람의 통계에 떨어집니다.

그런 일이 실제로 있었는지는 데이터로 확인할 수 없습니다. 그렇게 들어온 조회를 다른 조회와 구별할 것이 없습니다. 확인할 수 있는 것은 이제 더는 일어날 수 없다는 사실입니다.

두 가지 변경

생성기는 이제 두 표를 다 확인합니다. 그리고 카운터를 지우면 — 같은 날부터 주인이 직접 할 수 있습니다 — 묘비가 남습니다. 번호만으로 이루어진 줄이며, 그래서 다시 발급될 수 없습니다. 삭제는 스무 개 표의 데이터를 한 트랜잭션에서 없애고 사본을 남기지 않으며, 그것이 삭제의 요점 전부입니다. 번호는 태워 둔 채로 있어야 하는 유일한 것입니다.

왜 눈에 띄지 않았는가

생성기는 표가 하나이던 때에 쓰였습니다. 보관 표는 나중에, 다른 까닭으로, 다른 문제를 풀려고 왔고, 그 두 생각을 이어 준 것은 없었습니다. 두 조각 다 그 자체로는 옳았습니다.

이런 일은 대개 그 모양입니다. 누가 한자리에서 저지른 실수가 아니라, 볼 수 있는 자리에 아무도 서 있지 않았던 결과입니다. 유일한 방어는 일부러 찾아 나서는 것이고, 이것을 찾아낸 물음은 평범했습니다. 삭제를 만들기 전에, 카운터 번호는 그 밖에 어디에 사는가?