돌려놓고 검수하기

자동화가 잘 돌아가는 것처럼 보이는 상태가 제일 위험합니다. 손이 안 가니까 결과를 안 보게 되고, 어긋난 것이 다음 단계로 그대로 흘러갑니다.

기준을 먼저 정합니다

무엇을 통과로 볼지부터 정합니다. 이 순서를 뒤집으면 결과를 보고 “이 정도면 됐다”고 판단하게 되는데, 그건 기준이 아닙니다.

기준은 확인할 수 있는 형태로 적습니다.

• 확인 안 되는 쪽: 결과가 자연스러운가
• 확인 되는 쪽: 표에 빈 칸이 없는가, 출처 링크가 전부 열리는가

기계와 사람을 가릅니다

정한 기준을 둘로 나눕니다.

기계가 확인할 수 있는 것 — 빈 칸 여부, 형식, 링크가 열리는지, 정해 둔 문구가 들어갔는지. 이런 건 훅으로 걸어 둡니다. 동작 전에 반드시 막아야 하면 PreToolUse를, 동작 뒤에 검사 결과를 알려 주면 되면 PostToolUse를 고릅니다.

사람이 봐야 아는 것 — 어조가 맞는지, 이 표현을 써도 되는지, 지금 이걸 내보내도 되는지. 이건 자동으로 바꾸려 하지 말고 그 지점에서 나에게 묻게 남깁니다.

기계 검사로 바꾸려다 기준이 헐거워지면 안 하느니만 못합니다.

막는지 확인합니다

검사를 걸어 두는 것과 그게 막는 것은 다릅니다. PostToolUse는 이미 끝난 파일 수정을 되돌리지 못하며, 명령형·HTTP형 Hook이 제한 시간을 넘기면 기본 흐름이 계속될 수 있습니다. 다음 단계까지 멈춰야 한다면 빌드나 배포 경로에도 같은 기준을 연결합니다.

확인하는 방법은 하나입니다. 일부러 어겨 보는 것. 기준을 어기는 입력을 하나 만들어 돌려 보고, 정말 멈추는지 봅니다. 안 멈추면 아직 게이트가 아닙니다.

위임한 결과도 검수 대상입니다

서브에이전트가 돌려준 요약은 이미 정리된 형태라 그대로 믿기 쉽습니다. 그런데 정리 과정에서 빠진 것은 요약만 봐서는 안 보입니다.

받은 요약 중 하나를 골라 실제 파일과 대조해 보는 습관이 필요합니다. 매번 전부 대조할 수는 없어도, 한 번은 확인합니다. 그 요약이 다음 단계의 입력으로 들어갈 때는 특히 그렇습니다.

특히 조심할 것은 읽은 내용은 맞는데 판정이 틀린 경우입니다. 위임한 워커가 파일을 정확히 읽고도, 어느 기준을 적용할지 헷갈려서 통과할 것을 위반으로 뒤집을 수 있습니다. 이때 돌아오는 보고는 근거까지 붙어 있어서 더 그럴듯해 보입니다.

그래서 위임할 때 기준을 정의 안에 못박아 둡니다. “문체를 검사해 줘”가 아니라 “어떤 어미를 통과로 볼지”까지 적어 두는 식입니다. 기준이 비어 있으면 워커가 그 자리를 스스로 채웁니다.

내 흐름에서 사람이 봐야만 아는 기준이 남아 있어. [여기에 그 기준]. 이걸 매번 놓치지 않으려면 어느 지점에서 나한테 물어보게 만드는 게 좋을지 제안해 줘.

지금 걸어 둔 검사들을 나열하고, 그중 실패해도 흐름이 그냥 지나가는 게 있는지 짚어 줘.