남겨둔 기준이 일주일 만에 도구 세 개가 됐다

앞선 글에서 버그를 고친 과정을 다음 리뷰의 도구로 남겼다. 그 글은 “기준은 도구보다 오래 남는다”로 끝났다. 반쯤은 다짐이었다 — 한 번 해본 일이었으니까.

그 뒤 일주일 사이에 같은 모양의 회전이 세 번 돌았다. 이번 글은 그 세 번의 기록이고, 결론을 먼저 적으면 이렇다. 반복을 만든 것은 자동화가 아니라, 판정에 쓰는 어휘 하나와 “세는 단위를 밝힌다”는 규칙 하나였다.

첫 번째 회전 — 회고가 교차 검증을 거쳐 규칙이 됐다

리뷰가 백 건 넘게 달린 큰 변경 하나와, 3개 파일짜리 작은 버그 수정 하나를 연달아 끝냈다. 두 건의 리뷰 과정을 각각 회고로 정리하면서, 같은 원본 데이터를 두 개의 모델에 따로 분석시키고 서로 반박하게 했다. 문서를 번갈아 고치며 열한 번을 오갔다.

정정이 네 번 나왔는데, 최종 방향이 뒤집힌 적은 한 번도 없었다. 네 번 전부 무엇을 한 건으로 세느냐가 어긋나 있었다.

첫 번째가 전형적이다. 리뷰 본문에서 빨간 원 이모지를 세었더니 0건이라 “치명 없음”이라 적었는데, 실제로는 리뷰어마다 표기 체계가 달랐고 빨간 원은 아무도 쓰지 않는 기호였다. 0이 나왔다는 사실 자체가 세는 방식이 틀렸다는 신호였는데, 그걸 결론으로 읽었다.

네 번째는 반례를 제시한 쪽이 그 반례의 숫자를 틀린 경우다. 방향이 옳다고 근거 수치까지 옳은 것은 아니다. 그래서 교차 검증에 대한 기대가 바뀌었다 — 값어치는 다른 의견이 아니라 동일 대상을 두 번 계산해 검증하는 데 있었다. 그건 혼자서도 할 수 있다. 수치에 단위와 재현 명령을 붙여 두면, 나중에 다시 돌리는 순간 위의 네 가지가 저절로 걸린다.

이 왕복에서 확정된 것들을 리뷰 대응 도구의 문구로 옮겼다. 하나는 지적을 “무엇인가 / 무엇을 할 것인가 / 제안을 받을 것인가”로 갈라 적는 판정 축이고, 다른 하나는 지적이 딛고 선 증거 등급이다.

근거는 작은 쪽 회고의 실측이다. 고유 지적 20건(리뷰 스레드 루트 기준, 같은 내용 재게시 제외) 중 증명됨 13건은 오탐 0건, 가정됨 3건이 오탐과 왕복의 전부였다. 좋은 지적과 나쁜 지적을 가른 것은 사람이냐 봇이냐도, 심각도 표기도 아니고 증거 등급이었다.

이 글의 수치는 전부 회고 문서의 재측정값이고, 각 수치에는 단위와 재현 명령이 함께 적혀 있다. 원문이 사내 문서라 링크하지 못하는 대신, 본문의 수치마다 세는 단위를 병기했다 — 이 글이 주장하는 규칙을 이 글에도 적용한 것이다.

두 번째 회전 — 규칙이 자기 리뷰를 받았다

옮긴 규칙은 곧장 저장소에 반영하지 않고 PR 로 올려 다른 모델에게 리뷰를 시켰다. 세 라운드가 돌았고, 세 번 다 지적이 유효했다.

재미있는 건 그 지적들을 방금 옮긴 규칙으로 판정하게 됐다는 점이다. 한 지적은 “이런 환경에서 깨진다”는 가정됨 등급이었고, 실재부터 확인하니 결함은 실재하되 제시된 재현 경로는 성립하지 않았다. 결함은 고치고, 근거는 정정해 답했다 — 회고가 어휘까지 만들어 둔 바로 그 상태다.

더 아픈 쪽은 자기 적발이다. 내가 넣은 검증 명령이 “예시 하나를 통과했으니 됐다”는 상태로 들어가 있었는데, 리뷰가 오탐과 누락을 짚었고 다시 재보니 사실이었다 — 통과는 그 저장소 규칙 모양의 우연이었다. 내 기준으로 내 스니펫이 가정됨 등급이었던 셈이다. 두 방향의 실측을 붙여 교체했다.

규칙이 자신에게 적용되면서 들어갔다는 것 — 이게 첫 번째 회전과 두 번째 회전이 연결되는 지점이다. 문서에 적힌 규칙은 어겨도 아무 일도 안 일어나지만, 리뷰 루프에 놓인 규칙은 어기면 지적으로 돌아온다.

세 번째 회전 — 버그 문의가 그날 진단 절차가 됐다

같은 주에, 앞 글의 발단이었던 여백 버그의 후일담이 왔다. 웹 쪽 수정을 끝냈는데 한 플랫폼 앱에서만 재현이 남았다.

웹 코드는 플랫폼 공통이다. 그렇다면 남은 원인 후보는 그 앱이 웹에 보내는 계약이다. 앱 저장소를 읽기 전용으로 열어 확인하니 모양이 나왔다 — 앱이 “웹은 이만큼 비워라”는 신호를 보내면서, 같은 일을 자기도 하고 있었다. 신호와 동작의 이중화. 웹은 계약대로 비웠고, 여백이 두 번 들어간 것이다.

이 갈래는 웹이 고칠 수 없다. 신호를 받고도 안 비우도록 고치면, 같은 신호를 계약대로 쓰고 있는 다른 화면이 깨진다. 계약을 어긴 쪽이 고쳐야 한다. 그래서 산출물은 코드가 아니라 문의 문서였다 — 증상 한 줄, 앱 코드 두 지점의 고정 링크, 웹이 그 신호를 어떻게 읽는지 한 문단, 웹 쪽 조치 상태.

그리고 그날 저녁, 이 경험을 버그 진단 도구의 새 갈래로 접어 넣었다. “특정 앱에서만 재현되면 → 그 앱 저장소를 읽기 전용으로 대조 → 신호와 동작의 이중화를 찾고 → 판정과 문의 문서로 산출”까지. 검색 명령은 전부 실제로 돌려 보고 넣었다. 앞 글이 버그 하나에서 도구를 뽑는 데 이틀이 걸렸다면, 이번엔 몇 시간이었다.

세 번을 관통하는 형태

돌아보면 세 회전의 모양이 같다.

1. 경험 직후에 적는다 — 기억이 아니라 로그·diff·스레드가 남아 있을 때
2. 판정 어휘를 공유한다 — 회고와 리뷰 대응과 버그 진단이 같은 축(증거 등급, 세는 단위)을 쓴다. 어휘가 갈라져 있으면 한쪽의 교훈이 다른 쪽으로 못 건너간다
3. 산출을 다음 작업 경로에 놓는다 — 문서로 끝내지 않고, 다음에 같은 판단이 일어나는 자리(리뷰 대응 절차, 버그 진단 분기)에 끼워 넣는다

셋 중 하나라도 빠지면 회전이 멈춘다. 특히 2번 — 기준이 서로 다른 작업에서 재사용되려면 같은 말로 적혀 있어야 한다. 이번 주에 어휘를 통일하는 데 쓴 시간이 규칙을 만드는 시간보다 길었고, 그게 남는 투자였다.

기준은 오래 남는 게 아니라 증식한다

앞 글의 마지막 문장을 정정할 때가 됐다. “기준은 도구보다 오래 남는다”고 적었는데, 일주일을 지나 보니 부족한 표현이다. 남는 데서 끝나지 않는다 — 다음 도구를 만들기 시작한다. 회고의 기준이 리뷰 도구를 고쳤고, 리뷰 도구의 기준이 자기 PR 을 판정했고, 버그 하나의 판정이 진단 절차가 됐다.

물론 이건 한 주짜리 표본이다. 세 번의 회전이 우연히 좋은 주간이었을 수 있고, 어휘가 늘어나다 보면 유지 비용이 회전 수익을 넘는 지점이 올 수도 있다. 그 지점이 오는지, 온다면 어디인지 — 그게 다음에 셀 것이다. 단위를 밝혀서.