기업 AI 도입 회의는 아직도 "어떤 모델을 쓸까"에서 시작한다. 그런데 지난 2주 동안 주요 벤더가 실제로 출시한 것은 모델이 아니라 요청을 가로막는 관문이다.
8월 5일 Anthropic은 Claude Enterprise에 인퍼런스 훅을 베타로 열었다. 조직이 기능을 켜면 사용자가 보낸 프롬프트가 모델에 닿기 전에 그 회사가 직접 운영하는 HTTPS 보안 서버로 전송되고, 서버가 allow 또는 deny를 돌려줘야 추론이 시작된다. deny면 요청은 모델을 보지 못하고, 사용자는 차단 사유와 담당자 안내를 함께 받는다. 훅 하나가 claude.ai, Cowork, Claude Code를 웹·데스크톱·CLI 구분 없이 덮고, 도구 호출 결과가 모델로 돌아가는 지점도 같은 검사를 거친다.
주목할 점은 검사 로직이 벤더 쪽에 없다는 것이다. 허용과 거부를 판정하는 코드는 고객사가 짜거나 기존 DLP 벤더에 연결한다. 통제의 단위가 '모델 선택'이나 '기능 on/off'에서 '요청 한 건'으로 내려왔다.
관문은 자기가 서 있는 자리까지만 막는다
이 구조의 성능은 관문의 위치가 결정한다. 문서에 적힌 한계가 그대로 증거다. 판정은 allow와 deny 두 가지뿐이고 프롬프트를 다시 쓰거나 일부를 가리는 기능은 없다. 사내 규정이 "고객 이름만 지우고 보내라"라면 그 규정은 구현할 방법이 없고, 전부 막거나 전부 통과시키는 선택만 남는다.
원본 파일과 이미지 바이트는 애초에 전송되지 않는다. 추출된 텍스트와 메타데이터만 간다. 즉 계약서를 캡처한 스크린샷은 검사되지 않는다. 사람들이 실제로 가장 많이 붙여넣는 형태가 사각지대에 있다. Amazon Bedrock과 Google Cloud 경로에는 적용되지 않고, Claude Platform API 조직과 음성 모드도 범위 밖이다.
운영 파라미터도 정책의 일부다. 판정 타임아웃 기본값은 5초이고, 서버가 응답하지 않을 때 차단할지 통과시킬지는 조직이 미리 고른다. 통과를 고르면 우리 서버가 죽는 순간 정책도 함께 사라지고, 차단을 고르면 보안 서버의 가용성이 곧 사내 AI의 가용성이 된다. 5초 안에 답하지 못하는 규칙은 문서상으로만 존재한다.
같은 제약이 다른 벤더에서도 같은 모양으로 나온다. GitHub는 7월 1일 Copilot CLI와 SDK에 세션당 크레딧 한도를 넣으면서, 이것이 소프트 캡이라고 명시했다. 사용량은 응답이 끝나야 알 수 있으므로 이미 시작된 응답은 끝까지 간 뒤에 멈춘다. 관문은 자기가 앉은 경계에서만 정확하다.
| 통제 지점 | 작동 시점 | 멈출 수 있는 것 |
|---|---|---|
| 인퍼런스 훅 | 추론 시작 전 | 프롬프트·도구 결과 한 건 |
| 세션 크레딧 한도 | 응답 완료 후 | 다음 요청 |
| Compliance API | 사후 | 아무것도 (감사·수출용) |
다음 관문은 도구 경로에 선다
7월 28일 확정된 MCP 개정판은 프로토콜 코어를 무상태로 바꾸면서 인가 규격을 여섯 건의 SEP로 강화했다. 클라이언트가 인가 응답의 iss 파라미터를 RFC 9207대로 검증하도록 요구한 항목이 대표적이다. 서버 하나에 클라이언트 여럿이 붙는 MCP 배치에서 흔한 mix-up 공격을 막기 위한 조치다.
프롬프트 앞과 도구 앞, 두 관문이 동시에 서고 있는데 소유 팀은 대개 다르다. 앞쪽은 보안·컴플라이언스 조직이, 뒤쪽은 플랫폼 엔지니어링이 잡는다. 여기에 OpenAI가 7월 말 GPT-5.6 저가 모델의 API 단가를 대폭 내리면서 통과 트래픽 자체가 늘어난다. 요청 한 건당 비용이 떨어질수록 관문의 지연과 실패 처리 설정이 사용자 체감을 지배한다.
도입 검토서에 적을 질문이 바뀐다. "어떤 모델이 더 정확한가"가 아니라 "우리 판정 서버는 몇 밀리초에 답하고, 죽으면 무엇이 열리는가"다.
조녁컴퍼니가 AX 전환 교육과 컨설팅에서 확인하는 것도 같다. 도구를 켜는 일보다 통제 지점을 정하고 그 지점의 실패를 설계하는 일이 조직의 실제 도입 속도를 정한다. 사업영역 →