S4 · 적대 리뷰

코드가 먼저 후보를 뽑는다 — 완전 중복, 원문에 근거 없는 케이스, 아이템 실명 미병기. 그 위에서 세 렌즈가 병렬로 리뷰한다(구조 · 품질 · 원문 대조). 판정자가 셋의 지적을 서로 반박시켜 수정 계획을 낸다.

1차와 2차가 서로를 안 본다

리뷰 차수마다 담당 항목이 명시적으로 갈려 있다.

	묻는 것	보는 것
1차	빠진 게 없는가	커버리지, 분류 정합, 검증 단계 배분
2차	내용이 맞는가	문장 품질, 중복, 한 케이스 한 검증점

그리고 상대 영역은 명시적으로 안 본다. 2차는 구조를 다시 안 보고, 1차는 문장 품질을 안 본다. 2차가 하는 구조 관련 일은 1차 지적이 반영됐는지 1:1로 대조하는 것뿐이다.

이렇게 나눈 이유는 단순하다. 한 번에 다 보라고 하면 둘 다 대충 본다. 특히 긴 시트에서는 앞쪽만 꼼꼼하고 뒤로 갈수록 흐려지는데, 축을 좁히면 그게 덜하다.

1차에는 비율 기준도 걸어 뒀다. 위험도가 높은 소분류는 부정·예외 케이스가 60% 아래면 지적이 뜬다. 사람이 정상 케이스만 쓰는 쪽으로 쏠리기 때문이다.

지적에는 처방이 따라야 한다

수정 단계는 판단하지 않는 코더로 설계돼 있다. 처방을 그대로 실행할 뿐이다.

그래서 리뷰어는 이슈마다 수정자가 그대로 실행할 수 있는 처방을 반드시 쓴다. “이 부분이 모호합니다”로 끝내면 안 되고, 어느 행의 어느 열을 무엇으로 바꾸라고 적어야 한다.

이 규칙이 없으면 판단이 두 번 일어난다. 리뷰어가 “이게 문제다”까지 판단하고, 수정자가 “그럼 어떻게 고치지”를 다시 판단한다. 두 판단이 어긋나면 고친 결과가 지적과 상관없어지고, 그걸 확인하는 건 또 사람이다.

작업을 끝내고 죽는 실패

여기서 커버리지 원장도 만든다 — 기획서 규칙과 케이스를 의미로 이어 붙이는 일이다.

규칙 전량을 한 번에 뱉게 했더니 출력 토큰 상한에 걸렸다. 매핑은 다 끝내 놓고 출력만 못 하고 죽는다. 세 건에서 났고, 재시도까지 겹쳐 한 건은 88.3분이 통째로 날아갔다.

작업 도중에 죽는 실패보다 작업을 끝내고 죽는 실패가 비싸다. 앞의 것은 부분 결과라도 남는데, 뒤의 것은 100%가 사라지고 그 사실조차 늦게 안다. 지금은 규칙을 50개씩 끊어 셋씩 병렬로 돌리고, 청크 결과를 코드가 병합한다. 청크끼리 겹치거나 빠지는 건 검증기가 막는다.

형식을 안 정하면 다음 단계가 죽는다

제외 사유를 자유 문장으로 쓰게 뒀더니 에이전트마다 래퍼를 씌우거나 서술형으로 적었고, 다음 단계가 타입 오류로 멈췄다. 명세를 안 쓴 대가다.

지금은 제외 사유가 정확히 세 값 중 하나다. 근거 문장은 따로 담는 자리를 뒀다.

그리고 “추후 구현”은 제외 사유가 될 수 없다. 그건 케이스로 만들어 두고 판정만 유보하는 것이지, 안 만드는 이유가 아니다. 안 만들면 다음 버전에서 아무도 그게 있었다는 걸 모른다.

같은 지적이 몇 번째인지 센다

리뷰가 끝나면 발견 패턴을 큐에 적는다. 그리고 그 큐가 승격 절차를 가진다.

1. 한 번 발견되면 관찰 목록에 한 줄
2. 같은 유형이 두 번 이상 재발하면 활성 패턴으로 승격
3. 석 달마다 활성 패턴을 규칙서에 정식 반영하고 큐에서 뺀다
4. 규칙에 반영했는데 또 터지면 재발 감시로 되돌린다

4번이 핵심이다. 규칙을 고쳤는데도 같은 게 나오면 그건 규칙이 안 읽히거나 애매하다는 뜻이고, 다음 조치는 문장을 강화하는 게 아니라 기계 검사로 격상하는 것이다.

지금 큐에는 재발 10회, 13회짜리가 앉아 있다. 그 숫자 자체가 정보다 — 열 번 넘게 같은 지적이 나왔으면 그건 쓰는 사람 문제가 아니라 규칙 문제다.