낫징은 원래 의심하는 역할이었습니다. Hermes가 코드를 고치면 낫징이 한 번 더 보고, 오케이징은 그 결과를 받아 진규에게 전달하는 흐름을 생각했습니다. 구현자와 리뷰어를 분리하면 안전해질 것 같았습니다.
이 생각 자체는 아직도 맞습니다. 자동 작업에는 의심하는 단계가 필요합니다. 다만 낫징을 항상 별도 인격이나 별도 agent처럼 유지하는 방식은 무거웠습니다. 작은 수정에도 리뷰 라우팅이 붙고, 보고 채널이 늘고, 최종 책임이 흐려졌습니다.
실제로 필요한 것은 "낫징이라는 누군가"가 아니라, 원격 반영 전에 반드시 통과해야 하는 검문이었습니다. diff를 봤는지, 테스트를 돌렸는지, secret이 섞이지 않았는지, main branch에 위험한 작업을 하지 않았는지 확인하는 절차입니다.
그래서 낫징은 notjing-final-gate skill로 재정의됐습니다. 이름은 남아 있지만,
역할은 final review gate입니다. 오케이징이 작업을 소유하고, push나 PR 같은
원격 handoff 직전에 낫징식 검문을 통과합니다.
final gate는 단순히 "괜찮아 보인다"고 말하는 단계가 아닙니다. 확인해야 할 목록이 있습니다.
| 항목 | 확인 이유 |
|---|---|
| git diff | 의도하지 않은 파일 변경 확인 |
| tests/build/lint/typecheck | 실제로 깨지지 않았는지 확인 |
| secret scan | 토큰이나 개인 정보 유출 방지 |
| destructive change | 삭제/force push 등 위험 작업 차단 |
| report completeness | 진규가 다음 결정을 할 수 있게 정리 |
| no commit/no push | 명시 승인 없는 원격 반영 방지 |
이 중 하나라도 빠지면 final gate가 아닙니다. 특히 commit/push/PR은 진규가 명시하기 전까지 하지 않는다는 규칙이 중요합니다. 오케이징은 파일을 고칠 수 있지만, 원격에 반영하는 마지막 문은 사람이 열어야 합니다.
모든 답변에 final gate를 붙이면 시스템이 둔해집니다. 블로그 주제 리스트업이나 단순 설명에는 낫징이 필요 없습니다. final gate는 원격 handoff 직전, 혹은 위험도가 큰 변경을 마무리할 때 쓰는 게 맞습니다.
이 기준은 오케이징의 전체 방향과도 맞습니다. 인격을 늘리는 게 아니라 절차를 필요한 곳에 붙입니다. 리뷰라는 절차가 항상 중요하긴 하지만, 모든 순간에 같은 무게로 필요한 것은 아닙니다.
낫징을 skill로 낮췄다고 해서 의심이 사라진 건 아닙니다. 오히려 더 선명해졌습니다. 이제 낫징은 "누가 리뷰했는가"가 아니라 "어떤 검문을 통과했는가"로 남습니다.
자동화에서 중요한 건 가끔 똑똑한 리뷰어가 등장하는 게 아니라, 위험한 순간마다 같은 기준이 반복되는 것입니다. 낫징은 그 반복 기준입니다. 오케이징이 스스로를 의심하는 방식이라고 볼 수 있습니다.