검증 게이트와 배포 규율
에이전트에게 자율을 주는 순간 필요한 것은 신뢰를 자동화하는 장치입니다. "됐다"는 말을 믿지 말고 게이트로 확인하세요.
완료 전 통과해야 하는 게이트
자율 작업은 "완료" 선언 전에 검증 게이트를 통과해야 합니다. 권장 순서: 타입체크 → i18n/규칙 검증 → 테스트 → 빌드. 하나라도 실패하면 게이트가 막고, 결과를 리포트에 기록합니다.
비용은 계층화로
- quick 모드 — 타입체크·감사만. 수시로, 빠르게(빌드 생략).
- full 모드 — 전체 빌드 + SEO/링크 감사. 야간·배포 전에만.
큰 사이트의 full 빌드는 수 분이 걸립니다. 모든 커밋마다 돌리면 비용이 폭발하죠. 수시 루프는 quick, 배포 게이트만 full로 두면 신뢰와 속도를 동시에 잡습니다. "마지막 full 게이트를 언제 돌렸는지"를 로그나 상태 파일로 기록해두고, 오래되면 stale로 경고하세요(FAIL이 아니라 stale — 상태를 정직하게).
배포는 사람이, 커밋은 배치로
OIYO의 철칙: 제품 배포는 사람이 승인합니다. 에이전트는 검증을 마친 산출물을 배치로 모아 승인을 요청합니다. 과도한 푸시는 CI 비용을 태우고 리뷰를 어렵게 만듭니다. 승인 후에는 모아서 일괄 커밋·푸시가 원칙입니다.
완료 보고를 되돌리는 장치를 둔다
에이전트가 "완료"라고 표시했는데 게이트는 FAIL이라면? 완료 보고와 게이트 결과를 주기적으로 대조하는 스크립트를 야간에 돌려, 게이트를 통과하지 못한 채 완료된 작업을 되돌리세요(사람에게 보고만 하는 report-only가 안전한 기본값, 자동 되돌리기는 신중하게 켤 옵션). 자기 보고를 자기 검증으로 교차 확인하는 것 — 이것이 자율 작업의 신뢰를 지탱합니다.
레이트리밋을 가시화하라
다중 모델을 쓰면 각 모델의 사용 한도·리셋 시간을 놓치기 쉽습니다. 한도에 걸린 줄 모르고 재시도를 반복하면 시간과 비용을 낭비합니다. 모델별 한도·리셋 시각을 상태 파일이나 로그로 상시 기록해두고, 번역 파이프라인처럼 한도에 자주 걸리는 작업은 자동 중단하고 플래그를 세운 뒤, 리셋 후 재개하게 만드세요.