--force는 대개 검증을 건너뛰거나 캐시를 무시하는 옵션이다. 그래서 이름부터 위험하다. 그런데 이 옵션이 미승인 작업까지 통과시키는 순간, 편의 기능은 정책 우회로 바뀐다.
최근 살펴본 한 작업 가드에는 흥미로운 회귀 테스트가 있었다. 승인 대기 상태인 같은 작업을 한 번은 옵션 없이, 한 번은 --force를 붙여 실행한다. 결과는 둘 다 차단이다. 옵션은 예전 호출과의 호환성을 위해 받아들이되, 승인 상태까지 바꾸지는 않는다.
이 구분은 사소하지 않다. 실패한 검증은 다시 시도할 수 있고, 오래된 캐시는 버릴 수 있다. 하지만 승인이 없다는 사실은 명령을 더 세게 실행한다고 해결되지 않는다. 권한은 실행 강도의 문제가 아니다.
준비 상태도 마찬가지다. 분석 도구가 준비됐다는 판단에는 허용된 범위, 네트워크 사용 여부, 명시적으로 제공된 오프라인 샘플 같은 근거가 필요하다. ready=true나 --ready라는 문자열은 그 근거를 대신할 수 없다. 스위치는 재시도 흐름을 바꿀 수 있어도 실행 경계를 새로 만들 권한은 없다.
라우팅 정보를 읽는 방식에도 같은 문제가 숨어 있다. 자유 형식 메모나 예시 문장에 primary 같은 단어가 들어갔다고 그것을 제어 필드로 해석하면, 설명문이 설정값 행세를 하기 시작한다. 그래서 제어 결정은 정해진 필드나 이름이 붙은 구역에서만 읽고, 중복되거나 충돌하는 값은 차단해야 한다.
강력한 도구에서 능력, 준비, 승인은 서로 다른 축이다. 실행 파일이 있고 서비스가 응답해도 허용 범위가 없으면 멈춰야 한다. 반대로 범위가 승인됐어도 필요한 입력이나 연결이 준비되지 않았다면 역시 멈춰야 한다. 셋을 하나의 불리언으로 뭉치면 편해 보이지만, 사고가 났을 때 무엇이 통과했는지 설명할 수 없게 된다.
--force는 명령을 강제로 다시 시도하게 만들 수 있다. 자기 자신에게 승인까지 내릴 수는 없다. 그 한 줄을 지키지 못하는 가드는 승인 장치가 아니라 이름만 거창한 체크박스다.