시험은 끝났다. 정적 검사도 통과했고, 격리된 실행과 서버 데모도 정상이었다. 마지막에 남은 건 AI 검토자의 의견 하나였다. 그런데 검토자는 반대 의견을 낸 게 아니라 아예 접속하지 못했다.
시스템은 이 둘을 구분하지 않았다. AI가 위험하다고 판단한 경우도, AI 서버의 문이 닫힌 경우도 똑같이 전체 검증 실패가 됐다. 승인 버튼도 함께 잠겼다. 참고용 조언자는 출근했을 때보다 결석했을 때 더 강한 거부권을 행사했다.
문제는 네트워크 장애 자체가 아니다. 검토 정책이 서로 다른 상태를 한 단어로 눌러 담은 데 있다. 코드 검사가 실패한 것, AI가 반대한 것, AI와 통신하지 못한 것은 원인도 책임자도 복구 방법도 다르다.
검증 결과는 적어도 세 층으로 나눠야 한다. 결정적 검사의 합격 여부, AI 의견의 내용, AI 서비스의 가용성이다. 화면도 “검증 실패” 한 줄 대신 무엇이 통과했고 무엇이 실행되지 않았으며 어떤 정책 때문에 릴리스가 막혔는지 보여줘야 한다.
AI 검토가 정말 필수라면 그렇게 선언하면 된다. 이 경우에는 이중화와 재시도, 장애 기준까지 릴리스 시스템의 일부로 운영해야 한다. 반대로 AI 의견이 참고용이라면 통신 장애는 경고로 남기고, 관리자가 사유와 함께 진행할 수 있는 별도 경로가 필요하다. 위험도가 높은 변경만 차단하는 방식도 가능하다.
어느 쪽이든 괜찮다. 곤란한 건 “의견은 참고”라고 써놓고 접속 실패에는 절대 거부권을 주는 구조다. 보수적인 정책처럼 보이지만 실제로는 누가 릴리스를 막았는지 설명하지 못한다.
접속 실패가 정책 결정을 대신하는 순간, 가장 강한 심사위원은 AI가 아니라 빈 포트가 된다.