0to1
문서가 스스로 낡았다고 말하는 기록 사이트.
지금 보고 있는 사이트다.
0to1은?
만든 것을 기록하고 공개하는 사이트다. 프로젝트 위키, 매일 밤 굽는 개발일지, 매일 아침 굽는 기술 동향, 그리고 자동화가 실제로 돌고 있는지 보여주는 관제판으로 되어 있다.
포트폴리오 사이트인데 한 가지가 다르다. 사이트를 사람이 채우지 않는다. 무엇이 낡았는지·무엇이 어젯밤 돌았는지·지표가 얼마인지는 매일 밤 기계가 계산해서 넣는다. 개발일지 탭도 그렇다. 거기 서 있는 본문은 사람이 쓴 글이 아니라 밤 자동화가 그날 커밋을 긁어 만든 일별 보고서다. 사람이 쓰는 건 이 문서처럼 "왜 그렇게 했는가"를 적는 쪽이다.
문서가 스스로 낡았다고 말한다
위키의 가장 흔한 실패는 문서가 조용히 썩는 것이다. 코드는 계속 바뀌는데 문서는 그대로고, 읽는 사람은 그게 언제 적 얘긴지 모른다. 최신인 척하는 문서가 아예 없는 문서보다 나쁘다.
그래서 각 문서에 감시할 코드 경로를 붙였다. 문서가 코드를 마지막으로 확인한 지점 이후, 그 경로에 커밋이 몇 개 쌓였는지를 센다. 그게 드리프트다.

커밋 20개가 쌓이면 50점으로 떨어지는 곡선이다. 처음엔 천천히, 뒤로 갈수록 급하게 깎인다.
위 배지는 지어낸 예시가 아니라 이 사이트의 실제 문서다. 자동화를 계속 고치면서 그 문서를 안 고쳤으니 저렇게 뜬다. 부끄럽지만 이게 이 장치가 제대로 도는 증거다. 그 문서는 이후 54커밋까지 밀렸다가 다 갚아 100%로 돌아온 적도 있다. 코드를 계속 만지는 한 또 밀리고, 배지는 그때마다 다시 떨어진다.
기준점을 잘못 잡아서 배지가 거짓말을 했다
한동안 이 계산의 기준점이 **"위키 파일을 마지막으로 고친 커밋"**이었다. 그러면 본문을 검증하지 않고 오타 하나만 고쳐도 점수가 100%로 되돌아간다. 실제로 제목에서 긴 줄표를 걷어낸 커밋 하나가 전 문서의 배지를 한꺼번에 FRESH로 만들었다. 검증하지 않았는데 신선하다고 말하는 배지는, 없는 것보다 나쁘다.
기준을 문서가 코드를 실제로 확인한 지점으로 옮겨서 고쳤다. 각 문서의 근거가 되는 사실 기록에 "여기까지 봤다"는 커밋 해시를 박아두고, 배지는 그 지점 이후 쌓인 커밋을 센다. 오타를 고치든 문장을 다듬든 점수는 안 움직인다. 코드를 다시 확인해야만 움직인다.
같은 김에 계산기를 하나로 합쳤다. 그전엔 배지를 내는 쪽과 썩음을 알리는 쪽이 각자 커밋을 세고 각자 매핑을 들고 있어서, 같은 질문에 서로 다른 답을 내놓고 있었다. 지금은 계산이 한 곳, 문서와 코드의 대응이 한 곳이고 나머지는 그 결과를 읽기만 한다.
밀린 문서를 매일 조금씩 갚는다
원래는 하나 정한 게 있었다. 낡은 문서를 자동으로 고쳐 쓰지 않는다. 낡았다고 표시만 한다. 자동으로 다시 쓰게 하면 문서가 코드 요약본이 되어버리고, 그러면 애초에 사람이 쓸 이유가 없다고 봤다. 문서의 값은 "왜 그렇게 했는가"에 있는데 그건 커밋 로그에 없으니까.
그런데 표시만 하니까 아무도 안 갚았다. 자동화 문서는 54커밋이 밀려 27%까지 떨어졌다. 낡았다고 정확하게 말해주는 배지가 있어도, 갚는 사람이 없으면 그냥 정확한 부고다.
그래서 갚는 것도 넘겼다. 대신 통째로 다시 쓰게 두지 않았다. 작업 단위를 문서 전체가 아니라 커밋 묶음으로 잘랐다. 매일 밤 확인 지점 이후 정해진 개수만큼만 읽고, 그만큼만 반영하고, 확인 지점을 그 자리로 옮긴다.

이 한 번의 변경으로 세 가지가 같이 풀렸다. 한 번에 처리하는 양이 고정이라 "너무 크면 건너뛴다"는 상한이 필요 없어졌고(전에는 가장 썩은 문서가 그 상한 때문에 정확히 제외됐다), 매일 조금씩 갚으니 빚이 쌓이지 않고, 무엇보다 성공 여부를 따로 기록할 필요가 없어졌다. 확인 지점이 앞으로 갔으면 성공이고 그대로면 실패다. 중간에 죽으면 지점이 안 움직이니 다음 밤이 같은 자리에서 이어받는다.
마지막 게 제일 크다. 전에는 자동화가 죽어도 현황판에 성공 도장이 찍혔다. 날짜만으로는 "어디까지 했는지"를 표현할 수 없어서 성공 여부를 따로 적어야 했고, 그 기록이 거짓말을 했다. 커밋 해시는 그 자체가 진도라서 적을 것이 없다. 관측 장치를 고치는 것보다, 관측할 필요가 없는 구조로 바꾸는 쪽이 낫다.
그 이어받기가 실제로 돌았다. 한 묶음이 세 밤에 걸쳐 닫힌 적이 있다. 첫 밤은 본문을 고치는 중에 연결이 끊겨 죽었고, 둘째 밤은 기록만 고치고 위키를 빼먹은 걸 잡아내 그쪽만 맞췄고, 셋째 밤에야 확인 지점이 앞으로 갔다. 설계한 대로 같은 자리에서 이어받았으니 묶음 내용이 틀어진 곳은 없었다.
다만 공짜는 아니었다. 지점이 두 밤 더 멈춰 있는 동안에도 기계는 매일 커밋했으니, 그 넷이 그대로 빚에 얹혔다. 갚을 양은 그대로인데 점수는 더 내려가 있었다. 죽어도 틀리지는 않게 만들었지만, 죽은 값은 점수에 찍힌다.
그리고 처음의 걱정은 규칙으로 남겼다. 자동 갱신은 사실만 고치고 서사는 건드리지 않는다. 바뀐 곳만 고치고, 확인 못 한 건 원문을 그대로 둔다. "왜 그렇게 했는가"는 여전히 사람이 쓴다.
자동화 문서(ai-harness)는 0to1 코드 전체를 감시하는데, 여기서 posts/와 content/는 뺐다.
글을 하나 발행할 때마다 커밋이 쌓이는데, 그게 자동화 문서를 썩게 만들면 안 된다. 글은 기계의 산출물이지 기계의 변경이 아니다. 감시 대상은 기계여야 한다.
다만 이 제외 목록에 구멍이 있는 걸 나중에 알았다. 뺀 것은 글이 사는 두 디렉터리뿐인데, 기계가 매일 쓰는 파일은 거기 밖에도 있다. 아침 평가가 한 점씩 쌓는 결과 파일과, 밤마다 갱신되는 사실 기록들이다. 둘 다 산출물인데 감시 경로 안에 있어서 드리프트로 잡힌다. 규칙이 틀린 게 아니라 적용 범위가 좁았다.
구멍의 제일 고약한 모양은 나중에 드러났다. 밤마다 갱신되는 그 사실 기록에는 이 문서 자신의 기록도 들어 있다. 밀린 걸 갚으려고 기록을 고치면 그 커밋이 다음 날 이 문서의 드리프트로 잡힌다. 갚는 행위가 곧 다음 빚이 되니 점수가 0으로 내려갈 수가 없다. 감시 경로가 자기 기록을 품은 문서에서만 생기는 고리라서, 여기와 자동화 문서 둘한테만 해당된다.
그 고리가 이제 네 바퀴 연속으로 돌아왔다. 네 번 다 되돌아온 것이 정확히 두 개씩이다. 한 묶음을 갚으면 그 기록이 두 라운드쯤 뒤에 두 개의 빚으로 다시 들어오는 것이, 적어도 이 문서한테는 평상시 상태인 셈이다.
세 번째는 모양이 더 얄궂었다. 되돌아온 두 개가 하필 확인 지점을 앞으로 못 보낸 두 밤의 기록이었다. 위에서 말한 세 밤에 걸쳐 닫힌 그 묶음, 죽은 밤과 위키만 맞춘 밤이다. 지점이 멈춰 있는 동안 점수가 더 깎인 것으로 한 번 값을 치렀는데, 그 두 밤이 남긴 기록이 다음 묶음의 빚으로 또 들어왔다. 못 끝낸 밤은 두 번 청구된다.
네 번째에 그 둘이 갈렸다. 이번에 돌아온 두 개는 정상적으로 지점을 앞으로 보낸 두 밤의 기록이다. 그러니까 두 개씩 돌아오는 건 사고의 흔적이 아니라 이 고리의 기본 주기다. 못 끝낸 밤이 두 번 청구되는 것은 그 위에 따로 얹히는 몫이었다.
LLM이 출처를 지어내지 못하게 하는 법
매일 아침 기술 동향을 카드로 굽는다. 여기서 제일 신경 쓴 건 큐레이션 품질이 아니라 거짓말을 구조적으로 막는 것이다.
한 번 사고가 났다. 카드에 붙은 Hacker News 링크의 글 번호를 모델이 지어낸 것이다. 그럴듯한 형식이라 눈으로는 안 걸린다. 링크를 눌러야 없는 글이라는 걸 안다.
그래서 파이프라인을 수집과 큐레이션으로 쪼갰다.
핵심은 두 번째다. 모델에게 웹 접근을 주지 않으면 출처를 지어낼 능력 자체가 사라진다. 프롬프트로 "지어내지 마"라고 부탁하는 것과, 지어낼 재료를 안 주는 것은 다르다. 앞은 지켜지길 바라는 것이고 뒤는 구조다.
같은 이유로 조용한 날은 0장짜리 파일을 쓴다. 빈 브리핑도 정직한 신호이고, 억지로 채운 카드보다 낫다.

걸러낸 양도 같이 보여준다. 76건을 훑어 6장을 남겼다면 70건은 버린 것이고, 그 비율이 보여야 카드 6장을 믿을 수 있다.
읽고 끝나지 않게 한다
동향의 진짜 문제는 정확도가 아니라 휘발이다. 아침에 읽고 "이거 써먹을 만한데" 하고는 그날 카드 안에 묻힌다.
그래서 카드에 apply 필드를 뒀다. 그 기술이 내 프로젝트에 연결될 때만 한 줄, 그리고 어느 프로젝트로 향하는지 대상 키를 함께 적는다. 나중에 그 프로젝트를 만질 때 쌓인 아이디어를 대상별로 다시 꺼내고, 실제로 반영했으면 반영 표시를 남긴다.
그런데 필드를 두는 것만으로는 부족했다. 아이디어는 쌓이는데 꺼내 보는 자리가 명령 하나뿐이어서, 결국 그날 카드 안에 묻히는 건 똑같았다. 그래서 전체 목록을 화면으로 뺐다. 지금까지 남긴 아이디어를 월별로 펼치고, 왼쪽에서 프로젝트를 골라 거른다. 거르기를 쿼리 파라미터가 아니라 주소로 만든 건 링크를 공유했을 때 그 화면이 그대로 열리게 하려는 것이다.
수집과 재사용을 다른 도구로 나눈 셈이다. 이 필드는 원문 사실이 아니라 제안이라, 화면에서도 사실과 구분해서 보여준다.
밤에 혼자 돌아간다
매일 밤 23시에 다섯 가지가 무인으로 돈다. 개발일지 생성, 위키 신선도 재계산, 원장 드리프트 감지, 밀린 원장의 배치 반영, 배포한 것들의 공개 지표 스냅샷이다. 아침에는 두 가지가 더 돈다. 9시에 기술 동향을 네 개 소스에서 긁어 카드로 굽고, 10시에 RAG 평가를 한 번 돌려 그날 한 점을 시계열에 쌓는다.
평가만 다른 스크립트에 있다. 밤 작업은 이 저장소 밖에 사는 셸 스크립트 하나가 순서대로 부르는데, 평가는 대상 프로젝트 안에 스크립트가 있고 자기 결과를 이 사이트 파일로 직접 써넣은 다음 그 파일만 골라 커밋한다. 저장소를 다른 작업과 같이 쓰기 때문에, 무인으로 도는 것이 git add 로 전체를 긁으면 남의 미커밋 작업이 딸려 나간다.
각 자동화는 돌 때마다 매니페스트에 마지막 실행 시각과 결과를 남긴다. 관제판은 그 파일을 읽어서 보여준다.

실패도 그대로 보여준다. 어느 날 아침 동향 큐레이션이 연결 끊김으로 죽었을 때, 관제판에는 "실패 · 네트워크"가 그대로 떴다. 실패를 감추면 관제판이 아니라 장식이 된다. 초록불만 뜨는 대시보드는 아무도 안 본다.
다만 그 말에는 조건이 하나 붙는다. 실패를 남기는 줄까지 가야 남는다. 아침 평가 크론이 사흘째 죽어 있는 걸 나중에 알았다. 외부 API 키가 만료되고 크레딧이 비어서 매일 10시에 돌다 중간에 꺼졌는데, 그 스크립트는 한 단계라도 실패하면 거기서 끝나도록 돼 있어서 매니페스트에 찍는 줄까지 도달하지 못했다. 그래서 그 칸은 마지막으로 성공한 날에 그대로 얼어붙어 있었다. 실행 이력 쪽도 똑같이 조용했다. 이력을 따로 둔 건 어제 장애가 오늘 성공으로 덮이는 걸 막으려던 것이었는데, 아무것도 안 쓰고 죽는 경우는 그 이중화로 안 걸린다. 덮어쓰기만 막아 뒀기 때문이다. 밤 작업 쪽은 종료 코드와 산출물 존재를 같이 확인해서 이 구멍을 막아 뒀는데, 그 층이 모든 크론에 있지는 않았다.
넘어지면 스스로 일어난다
무인으로 도는 이상, 실패했을 때 사람을 부르는 것으로 끝나면 안 된다. 그래서 복구를 두 층으로 뒀다.
즉시 재시도. 실패하면 종류부터 가른다. 연결이 끊긴 종류면 잠깐 뒤 한 번 더 부르고, 사용량 한도에 걸린 거면 재시도하지 않는다. 한도는 곧바로 다시 불러도 같은 이유로 죽고, 창이 열릴 때까지 기다리는 건 크론이 할 일이 아니다. 재시도할 값이 있는 실패와 없는 실패를 구분하는 것이 이 층의 전부다.
다음 날 보충. 재시도로도 못 살리면 그날 브리핑이 빈다. 그런데 수집 결과는 날짜별 캐시로 남아 있어서, 다음 날 아침에 빈 날을 찾아 다시 구울 수 있다. 큐레이션은 이미 카드가 있으면 그냥 끝나므로 매일 돌아도 안전하다. 실패가 하루로 끝나고 구멍으로 남지 않게 하는 장치다.
복구된 날은 관제판에도 "재시도 후 복구"라고 적는다. 조용히 살아나면 이 시스템이 얼마나 자주 넘어지는지 아무도 모르게 된다.
Reddit 수집이 매일 실패하고 있었다. 로그에는 "자격증명 미설정"이라고 찍혀서, 값을 안 넣은 문제로 보였다.
실제 원인은 달랐다. 스크립트가 .env 파일을 아예 읽지 않고 있었다. 값을 채워 넣어도 안 됐을 것이고, 인증 코드는 한 번도 실행된 적이 없었다.
메시지가 틀린 말은 아니었다. 환경변수에 값이 없는 건 사실이니까. 그런데 그게 "안 넣었다"로 읽히면서 원인을 엉뚱한 데서 찾게 만들었다. 지금은 파일이 없는 경우와 값이 비어 있는 경우를 나눠서 말한다.
자동화의 경계는 계속 밀었지만 전부 밀지는 않았다.
개발일지는 결국 발행까지 무인으로 넘겼다. 그날 무슨 커밋이 있었는지는 기계가 더 정확하니까. 그런데 일지를 보고서 형식으로 개편하고 나서야, 정작 개발일지 탭이 렌더하던 것이 그 일지가 아니라 주제별 블로그 글이라는 게 드러났다. 탭을 일지로 갈아끼우면서 글은 파일을 그대로 두고 목록에서만 내렸다. 글 주소는 살아 있고, 위키 문서와 태그에서 들어간다.
화면 틀은 그대로 쓰되 일지에 없는 값은 걷어냈다. 글에는 있던 번호, 새 글 뱃지, 읽는 시간, 카테고리 색이 일지에는 없다. 자리를 비워두기 아까워 채우면 그 자리가 곧 거짓말이 된다.
반면 블로그 글은 초안까지만 자동이고 발행은 사람이 누른다. 무엇을 쓸 값이 있는지는 기계가 모른다.
원장을 코드에 맞춰 다시 쓰는 자동화(refresh)는 만들어두고 한동안 꺼둔 채 수동으로 검증했다. 만들었다고 바로 켜야 하는 건 아니다. 지금은 검증을 거쳐 켜져 있는데, 켤 때도 전부 넘기진 않았다. 고치는 건 사실까지고, 서사는 여전히 사람 자리다.
발행은 push 하나
배포는 git push 하나다. Vercel이 물려 있어서 약 50초 뒤 반영된다. 관리 화면도, 배포 버튼도 없다.
대신 규칙이 하나 붙는다. 커밋이 곧 발행이다. 밤 자동화가 계산 결과를 커밋하고 스스로 push하기 때문에, 실험을 커밋해두면 그날 밤 같이 나간다. 그래서 확정되지 않은 것은 커밋하지 않는다. 편한 만큼 대가가 있는 구조다.
위키는 파일이 곧 목차다
content/ 아래 마크다운을 두면 그게 문서가 된다. 네비 순서만 배열로 적어두고, 나머지는 파일 존재 여부로 굴러간다.
문서 안에서는 흐름도, 지표 타일, 결정 블록, 스크린샷 같은 조각을 컴포넌트로 쓴다. 글로 길게 설명할 것을 구조로 보여주기 위해서다. 이 문서에도 위에 다 쓰였다.
문서는 원래 플레이북(겪은 것)과 노트(개념)의 두 갈래였다. 그런데 같은 주제가 두 그룹에 흩어져서, 함수콜링은 노트에 있고 MCP는 플레이북에 있는 식이 됐다. 어디를 봐야 할지 알 수 없어서 기준을 하나로 합쳤다. 실전에서 꺼내 쓸 만한가. 지금은 전부 플레이북이고, 갈래는 주제(도구 · AI · 기본기 · 프론트 · 백엔드 · 인프라)로만 나눈다.
기술 스택
- Next.js (App Router) · TypeScript · Tailwind · MDX
- 콘텐츠: 파일 기반 (
content/**.md,posts/**.md) · 프론트매터 + MDX 컴포넌트 - 자동화: Node 스크립트 12개 · 야간 무인 실행 · 결과는 JSON으로 커밋
- 배포: Vercel (git 연동) · RSS는 빌드 전 생성
정직한 한계
신선도 점수는 커밋 수를 센다. 코드가 실제로 얼마나 달라졌는지가 아니라 몇 번 손댔는지다. 오타 수정 20개와 구조 변경 1개가 같은 무게로 잡힌다. 그래도 쓰는 이유는, 완벽한 지표가 아니어도 "이 문서 오래됐다"는 신호로는 충분히 작동하기 때문이다.
이 거칠기가 제일 크게 드러난 건 이 문서 자신이었다. 배지가 43%까지 떨어져서 확인해 보니 쌓인 27커밋이 전부 기계가 쓴 파일이었다. 소스 코드는 한 줄도 안 바뀌어 있었고, 실제로 고칠 서술은 낡은 숫자 몇 개뿐이었다. 배지는 낡았다고 말했지만 그 말의 근거는 "누군가 코드를 고쳤다"가 아니라 "커밋이 쌓였다"였다.
그래서 이 점수는 "문서가 틀렸을 확률"이 아니라 **"확인할 때가 됐다"**로 읽는 게 맞다. 둘은 자주 겹치지만 같은 말은 아니다.
그리고 같은 일이 두 번 더 반복됐다. 49%일 때 열어 본 21커밋도, 54%일 때 열어 본 17커밋도 전부 기계가 쓴 파일이었다. 세 번 다 소스는 한 줄도 안 바뀌어 있었다. 세 번 연속 낡았다고 하고 세 번 다 고칠 게 숫자 몇 개뿐이었다면, 적어도 이 문서한테는 배지가 "확인할 때가 됐다"는 신호로도 잘 안 맞고 있다. 위의 자기 참조 고리 때문이다.
점수가 움직인 방향은 더 얄궂다. 43에서 49, 54로 올랐는데 오른 이유가 무엇을 확인해서가 아니다. 그 사이에 기계가 커밋을 덜 했을 뿐이다. 점수를 만드는 식에는 검증이 들어갈 자리가 아예 없어서, 자기 참조 고리에 걸린 문서에서는 점수가 오르는 것도 좋은 신호가 아니다. 고치려면 기계가 쓰는 두 갈래를 감시 경로에서 빼야 하는데, 그건 이 문서가 아니라 코드가 할 일이라 아직 그대로 두고 있다.
네 번째로 열어 봤을 때는 반대로 45까지 내려가 있었다. 이번에 갚은 묶음 열 개도 전부 기계가 쓴 파일이었고, 그 안에는 지난 두 라운드가 갚으면서 남긴 기록 자체가 들어 있었다. 고리가 한 바퀴 돌아온 셈이다. 다만 대기열 뒤쪽에는 오랜만에 사람이 만진 커밋들이 보이기 시작했고, 그건 다음 묶음이 소화한다.
다섯 번째에 그 묶음이 들어왔고, 거기서는 배지가 맞았다. 열 개 중 넷이 실제 코드 변경이었다. 화면이 둘 늘고, 공통 푸터가 사라지고, 위키에 프로젝트 여섯 개가 붙고, 본문 글꼴이 바뀌어 있었다. 고칠 게 숫자 몇 개가 아니었다.
그러니 앞의 네 번을 근거로 "이 문서한테는 배지가 안 맞는다"고 적은 건 절반만 맞는 말이었다. 그 네 번이 하필 코드를 안 만진 구간이었던 것이고, 다시 만지기 시작하자 같은 지표가 바로 제 몫을 했다. 지표가 고장 난 게 아니라, 기계가 매일 깔아 두는 바닥값 때문에 신호가 잡음에 묻히는 것이다. 바닥을 걷어내는 건 여전히 코드가 할 일로 남아 있다.
여섯 번째는 다시 기계 쪽이었다. 열 개 중 아홉이 기계가 쓴 파일이고 소스는 하나였다. 그 하나도 도식 한 장의 단계 이름을 바꾼 커밋인데, 그 도식을 띄우는 건 이 문서가 아니라 다른 문서 둘이다. 이 문서에서 그 커밋 때문에 고칠 서술은 하나도 없었다. 여섯 라운드가 갚은 커밋 예순 개를 통으로 보면 소스는 다섯이다. 다섯 번째의 반등은 추세가 아니라 한 라운드짜리 사건이었다.
여기서 잡음원이 하나 더 드러났다. 감시 경로가 사이트 통째라서 다른 문서가 주인인 변경까지 이 문서 몫으로 잡힌다. 도식 이름을 바꾼 그 커밋이 정확히 그 모양이다. 이 문서가 설명하는 것은 한 줄도 안 바뀌었는데 점수는 깎였다. 기계가 깔아 두는 바닥값과는 별개의 문제이고, 경로를 좁히는 것 역시 코드가 할 일이다.
일곱 번째는 소스가 아예 없었다. 열 개 중 아홉이 기계가 쓴 파일이고, 나머지 하나는 코드가 아니라 저장소 전체의 프로젝트 색인과 썩은 링크를 정리한 커밋이었다. 감시 경로에 걸린 것은 이 프로젝트 README 에서 한 줄을 지운 것뿐이다. 그것도 없어진 푸터 컴포넌트를 가리키던 줄인데, 푸터가 사라진 사실은 이 문서가 이미 두 라운드 전에 적어 둔 것이다. 이 문서보다 낡은 문서를 고친 커밋이 이 문서의 배지를 깎은 셈이다. 그래서 잡음원은 "다른 문서가 주인인 코드 변경" 보다 넓다. 사이트 디렉터리 아래에서 일어나는 모든 변경이 이 문서 몫이고, 거기에는 코드가 아닌 것도 섞인다. 일곱 번 갚은 커밋 일흔 개를 통으로 보면 소스는 다섯이다.
여덟 번째는 묶음 아홉 개가 통째로 기계가 쓴 파일이었다. 코드도 아니고 다른 문서를 고친 커밋도 아니다. 전부 아침 평가가 쌓은 점과 밤마다 갱신되는 사실 기록뿐이었다. 그런데 이번엔 이 라운드가 여덟 번 중 제일 많은 것을 알려줬다. 여덟 라운드 동안 "기계가 매일 깔아 두는 바닥값 때문에 신호가 잡음에 묻힌다"고 적어 왔는데, 그 바닥값의 절반이 이 구간에 고장으로 빠졌다. 아침 평가 크론이 사흘째 죽어 있어서 쌓이던 점이 끊겼다. 그러자 확인 지점을 묶음 끝으로 옮긴 뒤 남는 드리프트가 처음으로 0이 됐다. 지난 일곱 번은 같은 자리에서 열, 여섯이 남았다. 가설이 맞았다는 걸 설계를 고쳐서가 아니라 고장이 보여준 셈이다.
그리고 더 중요한 걸 하나 알려줬다. 이 점수는 커밋이 쌓이는 것만 센다. 끊긴 것은 안 센다. 이 구간에서 실제로 중요한 사건은 쌓인 아홉 개가 아니라 멈춘 크론 하나였는데, 그쪽은 드리프트를 내려서 점수를 올린다. 장애가 신선함으로 읽힌다. 관제판도 같은 사각을 공유한다. 스탬프를 찍기 전에 죽는 크론은 매니페스트에도 실행 이력에도 아무것도 안 남기니까, 두 장부가 똑같이 "마지막 성공"만 들고 평온해 보인다. 쌓이는 걸 보는 장치는 둘이나 있고, 안 쌓이는 걸 보는 장치는 없다.
그리고 아직 감시 경로를 안 붙인 문서는 100%로 표시된다. 이건 고른 게 아니라 안 걸러진 것이다. 계산기는 감시 경로가 없는 문서의 그 빈자리를 경로인 척 git 에 그대로 넘기고, git 은 오류 없이 "커밋 0개"라고 답한다. 실패로 걸리지 않고 성공 경로를 통과하니 어디에도 경고가 안 남는다. 결과는 "안 쟀다"와 "안 낡았다"가 화면에서 같아 보이는 것이다. 지금 그런 문서가 둘 있다. 둘 다 이 저장소가 추적하는 코드가 아니어서 셀 커밋이 없다. 감시 경로를 붙이는 순간 실측값으로 바뀌긴 하지만, 붙이기 전까지는 이 배지가 최신을 보증하지 않는다.
그리고 이 사이트는 결국 나 혼자 쓰고 나 혼자 읽는다. 협업 위키가 겪는 문제들은 아직 안 겪어봤다.