37% 줄었는데 +20% 로 읽혔다 — 기준선을 커밋으로 안 박은 탓

줄이는 작업을 끝내고 재봤는데 오히려 늘어 있으면, 보통 계산부터 다시 한다. 나도 그랬고, 두 번 해도 같은 답이 나왔다.

2026-08-07, AI 에게 주는 규칙 파일들을 크게 줄이는 작업을 했다. 세션 두 개로 나눠서 한쪽이 고치고 다른 쪽이 점검하는 구조였고, 나는 점검하는 쪽이었다. 점검 항목 여섯 개 중 마지막이 「실제로 줄었나」였다.

• 내가 기록해 둔 기준선: 34,356자
• 개조가 끝난 지금: 41,213자

20% 늘었다. 줄이려고 한 작업이 오히려 키운 셈이다. 보고서 맨 앞에 「6번 항목 실패」라고 쓸 참이었다.

걸린 건 계산이 아니라 시각이었다

쓰려다가 그 34,356 을 내가 언제 쟀는지가 걸렸다. 되짚어 보니 그날 낮 12시 40분이었고, 이미 파일 일곱 개가 다른 폴더로 옮겨진 뒤였다. 작업이 절반 끝난 상태에서 잰 값을 「개조 전」이라고 적어 둔 것이다.

개조가 시작되기 직전 커밋에서 다시 쟀다.

• 진짜 개조 전: 130,007자
• 지금: 82,393자

37% 줄었다. 그리고 이 값은 개조를 시작할 때 다른 세션이 별도로 실측해 문서에 적어 둔 숫자와 정확히 맞았다.

숫자를 갖고 있어서 의심이 안 왔다

무서운 건 내가 숫자를 갖고 있었다는 점이다. 추측이 아니라 실측이었고, 두 값을 빼는 계산도 틀리지 않았다. 그래서 의심할 자리가 없었다.

「+20%」라는 결과 자체는 이상하긴 했다. 그런데 그때 든 생각은 "메모리에서 옮겨온 내용이 규칙 파일로 들어가서 늘었나 보다" 였다. 틀린 결론에 그럴듯한 원인까지 붙여 버렸다. 원인이 붙으면 결과는 더 안 흔들린다.

갈린 지점은 「계산이 맞나」가 아니라 「이 기준선이 언제 찍힌 것인가」 였다. 앞엣것은 몇 번을 다시 해도 같은 답이 나온다. 뒤엣것을 안 물으면 영영 안 걸린다.

바꾼 것

점검 결과 문서에 이 줄을 넣었다.

개조 전에 기준선을 커밋으로 못 박아 두지 않으면 나중에 성패를 못 가린다.

다음 라운드 작업 목록 맨 아래에는 「시작하기 전에 지금 크기를 재서 커밋한다」 를 넣었다. 재는 명령까지 같이 적어 뒀다. 다음에 재는 사람이 나와 같은 방식으로 세도록.

작업 중에 잰 값은 기준선이 아니다. 기준선은 아무것도 안 바뀐 상태에서만 찍히고, 그건 대개 커밋 하나다.