파일 맨 위에서 번호 하나를 읽어오는 일
작업 기록을 이어 쓰는 문서가 있다. 한 작업이 끝나면 다음 작업이 그 문서를 읽고 이어받는 식이다. 맨 위에 일련번호가 적혀 있고, 다음 작업은 그 번호에 1을 더해 쓴다.
이 더하기를 손으로 하고 있었다. 그래서 자동으로 읽어오게 만들기로 했다.
문서 맨 위는 이렇게 생겼다.
# 작업 기록 (269 - 게이트 정비)
- 날짜: 2026-09-10
- 번호: 269
- 브랜치: main
번호: 꼴의 줄을 찾아 뒤의 숫자를 집으면 된다. 나는 "'번호'라는 낱말이 들어간 줄"을 고르게 했다. 당연해 보였다.
하필 그날의 주제가 번호 규칙이었다
그 작업의 주제가 "번호를 매기는 규칙을 바꾸는 일"이었다.
그래서 같은 문서 본문에 이런 문장들이 쌓였다.
번호 규칙 문서가 191/200줄이라 여유가 3줄뿐이다
낱말로 고르는 필터에게 이 줄은 합격이다. '번호'가 들어 있으니까. 파서는 이 줄을 번호 필드로 인정하고 거기서 숫자를 집었다. 191이었다.
진짜 번호인 269는 그 아래에 멀쩡히 적혀 있었다. 위에서부터 훑다가 먼저 걸린 쪽이 이겼을 뿐이다.
결과가 너무 그럴듯했다
여기서부터가 고약한 부분이다.
번호는 앞자리와 뒷자리로 나뉘는데, 앞자리는 이 문서가 아니라 폴더 이름에서 따로 뽑는다. 그러니 앞자리는 항상 맞는다. 뒤에 붙은 숫자만 엉뚱했다.
출력은 이런 모양이 됐다.
이번 작업 = T1-192
형식이 완벽하다. 자릿수도, 구분자도, 앞자리도 전부 정상이다. 틀린 것은 숫자 하나뿐이고, 그 숫자가 맞는지는 원본 문서를 열어 대조해야만 안다. 눈으로 훑는 검토로는 걸리지 않는다.
💡 값이 그럴듯한 형식으로 나오는 결함은 값이 비어 있거나 깨지는 결함보다 오래 산다. 형식이 검토자의 확인을 대신 받아주기 때문이다. 형식을 보고 값을 믿는 순간이 있다.
무엇을 해석하는 코드는 자기 설명을 입력으로 받는다
원인을 한 줄로 적으면 이렇다. 무언가를 해석하는 코드를 만드는 동안, 그 코드에 대한 서술이 같은 파일에 쌓인다.
번호를 읽는 기능을 만들면 번호 이야기를 쓰게 되고, 그 글이 번호를 읽는 기능의 입력이 된다. 이건 드문 우연이 아니다. 작업 기록이라는 문서의 성질상 기본값에 가깝다. 로그 파서를 만들면서 로그 형식을 설명하고, 설정 파일을 읽는 코드를 만들면서 설정 예시를 적는 것도 같은 구조다.
고친 방향은 낱말을 버리는 것이었다. 줄의 맨 앞에서 시작하고, 낱말 바로 뒤에 콜론이 오고, 그다음이 숫자여야 한다. 형식으로 거르면 서술문은 통과하지 못한다. 문장 한가운데에 낱말이 있거나, 낱말 뒤에 콜론이 없기 때문이다.
이미 다른 데도 있었다
고치고 나서 궁금해졌다. 이게 이번에만 생긴 상황인가.
저장소 전체를 훑었다. 옛 필터였다면 걸렸을 문장이 다른 파일들에 이미 있었다. 그 파일들이 이 파서의 입력이 될 차례가 아직 안 왔을 뿐이었다.
같은 파일 안에서 신뢰 모델이 갈려 있었다
리뷰에서 하나가 더 나왔다.
앞자리를 정하는 함수는 "문서 안의 글자를 믿지 않는다"는 태도로 짜여 있었다. 폴더 이름에서 뽑으니 본문이 뭐라고 쓰여 있든 영향을 안 받는다.
그런데 뒷자리를 정하는 함수는 정반대였다. "본문에 번호처럼 생긴 게 있으면 믿는다." 문서 본문에 다른 작업의 번호가 인용돼 있으면 그걸 집어 온다. 재현해보니 실제로 그렇게 동작했다.
한 파일 안에서 두 함수의 신뢰 모델이 갈리면, 그 틈이 결함이 된다. 한쪽은 외부 사실을 믿고 한쪽은 본문을 믿는데, 둘이 합쳐져 하나의 값을 만들고 있었다.
검사를 일부러 망가뜨려 봤다
마지막으로 검사 자체를 확인했다. 코드를 일부러 틀리게 고쳐놓고 테스트가 실패하는지 보는 방식이다. 실패하지 않으면 그 테스트는 아무것도 안 지키고 있다는 뜻이다.
두 번 돌렸고 두 번 다 테스트가 전부 통과했다. 망가뜨렸는데 통과했다는 것이 문제였다.
이유는 두 가지였다. 하나는 조건 두 개를 독립으로 적어둔 탓에 한쪽만 느슨해지면 다른 쪽에 가려지는 구조였다는 것. 둘을 하나에서 파생시키자 같은 조작이 곧바로 잡혔다.
다른 하나는 내 확인 문장 자체가 헐거웠다는 것이다. 출력에 정답 문자열이 들어 있는지만 봤는데, 출력 형식이 "이번 = 새 번호 (직전 = 이전 번호)"라 직전 번호가 늘 함께 찍힌다. 그러니 새 번호를 틀리게 만들어도 내 확인은 통과한다. 틀린 답에도 참인 문장으로 검사하고 있었다.
남은 것
낱말로 고르면 그 낱말을 설명한 문장이 딸려온다. 형식으로 골라야 한다. 줄의 시작 위치, 구분자, 값의 자리까지 못 박으면 산문은 통과하지 못한다.
형식이 맞는 오답은 눈으로 안 걸린다. 자릿수와 구분자가 정상인 값은 검토자의 시선을 통과한다. 원본과 대조하지 않는 확인은 형식만 확인한 것이다.
한 파일 안의 함수들이 같은 것을 다르게 믿고 있지 않은지 본다. 하나는 외부를 믿고 하나는 본문을 믿는데 그 둘이 한 값을 만들면, 신뢰의 경계가 그 값 한가운데를 지나간다.