저희는 둘 다 사용하는 쪽으로 정착했습니다.
슬래시 커맨드 흐름 안에 Codex 교차 리뷰 페이즈를 넣어두고(/ship 안에 기획 → 구현 → 검증 → Codex 리뷰 → 보고 식으로), 동시에 pre-push hook에도 같은 리뷰를 걸어둡니다. 슬래시 커맨드만 두면 급할 때 그냥 push해서 리뷰가 빠지고, hook만 두면 push 직전에야 결과가 나와 늦습니다.
두 경로 모두 Codex CLI를 직접 부르지 않고, 한 번 감싼 bash 스크립트(codex-review.sh) 한 개를 양쪽에서 똑같이 호출합니다. 그 스크립트가 타임아웃, 인증 체크, 시크릿 체크, 출력 포맷을 한 곳에서 처리해줘서 슬래시 커맨드든 hook이든 호출 측이 깔끔해집니다.
핵심은 Codex 리뷰 결과로는 절대 차단하지 않는다는 점입니다. CLI가 죽었거나 CRITICAL이 나와도 push는 그대로 통과시키고 결과만 출력해요. 한 번이라도 차단으로 만들면, Codex가 실제로는 문제없는 코드를 잘못 잡았을 때 사용자가 push를 하려고 hook을 우회하는 옵션(git push --no-verify)을 쓰게 되고, 이게 습관이 되면 hook이 걸려 있어도 안 도는 것과 똑같은 상태가 됩니다. 그래서 차단이 필요한 검사(린트·타입·테스트, 시크릿 파일 push)는 별도 게이트로 분리하고, 모델 의견은 참고용으로만 둡니다.
스크립트·슬래시 커맨드·hook 본문은 트랙 4~6챕터에 그대로 들어 있으니 참고하셔도 좋을 것 같습니다.
이렇게 하시는 분들 있다고 하는데, 어떤 방식일지가 궁금하네요.
두 도구를 별도의 에이전트로 묶지 않고, 개발자가 직접 필요할 때마다 각각 호출하는 건지,
Git Hook 할 때 자동으로 Codex가 리뷰를 하게 만드는 설정으로 조치하는 지 궁금하네요.