프롬프트가 모델에 닿기 전에, 회사 서버가 먼저 읽는다

장면 하나부터 그려보자. 어느 금요일 오후, 결제팀 백엔드 개발자가 클로드 코드 터미널을 열어놓고 프로덕션 장애를 쫓고 있어. 로그만 봐서는 원인이 안 잡히니까 결국 하던 짓을 한다. DB에서 실패한 트랜잭션 몇 건을 그대로 긁어서 붙여넣는 거야. 그 안에는 고객 이름, 이메일, 카드 BIN 앞자리, 그리고 사내 결제 게이트웨이의 내부 오류 코드가 섞여 있다. 엔터를 친다.

작년까지 이 순간은 그냥 끝이었다. 데이터는 회사 네트워크를 떠났고, 보안팀이 그 사실을 알게 되는 건 빨라야 다음 주 로그 감사 때였다. 그때 할 수 있는 일이라곤 사후 보고서를 쓰고 교육 자료를 한 장 더 만드는 것뿐이었지.

이제는 그 요청이 앤트로픽 서버에 도착한 다음, 모델로 가지 않는다. 대신 회사가 직접 운영하는 HTTPS 엔드포인트로 서명된 POST 하나가 날아간다. 대화 전문이 통째로 실려서. 그 서버가 기본 5초 안에 {"action": "deny", "deny_reason": "이 프롬프트에 카드 결제 데이터가 포함된 것으로 보입니다"} 같은 JSON을 돌려주면, 클로드는 그 문장을 영영 보지 못한다. 개발자 화면에는 차단 사유와 담당자 연락처가 뜨고, 그 거부 기록은 조직의 활동 피드에 inference_hooks_request_denied라는 이름으로 남는다.

앤트로픽이 2026년 8월 5일 발표한 기능이고, 이름은 인퍼런스 훅(Inference hooks)이야. 클로드 엔터프라이즈 조직 대상 베타다. 공식 문서 표현을 그대로 옮기면 "각 통제 대상 프롬프트를 조직의 AI 보안 서버로 보내 추론이 진행되기 전에 허용 또는 거부 판정을 받는" 기능이다.

숫자로 보면 왜 지금인지가 선명해진다. 체크포인트가 낸 「AI Security Report 2026」에 따르면 조직의 87~93%가 매달 최소 한 건 이상의 고위험 생성형 AI 상호작용을 겪고 있고, 기업·개인·규제 데이터를 담은 프롬프트의 비율은 1년 만에 두 배로 뛰어 스물다섯 개 중 한 개꼴이 됐다. 프롬프트 25개 중 하나. 팀 하나가 하루에 프롬프트 200개를 던진다면 그중 여덟 개는 나가면 안 되는 게 섞여 있다는 소리야. 그리고 그걸 막을 자리가 지금까지는 애매했다.

앤트로픽이 왜 이 자리를 직접 만들었나

먼저 주인공 소개. 앤트로픽은 2021년에 오픈AI 출신들이 세운 회사고, 2026년 현재 매출 성장 곡선이 업계에서 가장 가파른 축에 든다. 보도에 따르면 연환산 매출 런레이트가 2025년 말 90억 달러 수준에서 2026년 5월 470억 달러대까지 올라왔고, 비즈니스 고객이 30만 곳을 넘으며 연 100만 달러 이상 지출하는 고객이 1000곳을 돌파했다고 전해진다. 이 수치들은 회사가 감사받은 재무제표로 공개한 값이 아니니 자릿수 감각으로만 읽는 게 맞아. 다만 방향은 분명하다. 앤트로픽 매출의 압도적 다수가 기업에서 나온다는 것.

그 기업 매출이 흘러나오는 접점이 지금 세 갈래로 벌어져 있다. 첫째는 claude.ai 웹·데스크톱 채팅. 둘째는 터미널에서 도는 클로드 코드. 셋째가 클로드 코워크(Claude Cowork)인데, 1월 말 리서치 프리뷰로 나왔다가 4월 초 정식 출시되면서 역할 기반 접근 제어, 그룹 지출 한도, 사용량 분석, 오픈텔레메트리 확장, 커넥터별 통제 같은 엔터프라이즈 기능이 붙었다. 같은 날 매니지드 에이전트도 함께 나왔고. 즉 앤트로픽은 지난 반년 동안 "직원이 클로드를 만지는 창구"를 계속 늘려온 거야.

창구가 늘어나면 보안팀 입장에서는 구멍도 같이 늘어난다. 브라우저 확장으로 채팅창을 감시하던 방식은 CLI에서 안 통하고, 엔드포인트 에이전트를 깐 노트북에서만 통하는 통제는 개인 기기나 원격 세션에서 뚫린다. 그래서 이번 발표에서 가장 중요한 문장은 기능 설명이 아니라 위치 설명이다. 문서는 이렇게 쓴다. "훅이 앤트로픽 서버에서, 요청이 클라이언트를 떠난 뒤 모델이 돌기 전에 실행되기 때문에, 모든 통제 대상 요청에 균일하게 적용되며 사용자 기기에 설치하거나 배포할 것이 아무것도 없다."

이건 사실상 통제 지점을 통째로 옮기겠다는 선언이야. 지금까지 기업 AI 보안 제품은 두 자리 중 하나에 서 있었다. 하나는 클라이언트 쪽 — 브라우저 확장, 엔드포인트 DLP 에이전트, TLS를 까서 보는 네트워크 프록시. 다른 하나는 사후 쪽 — 로그를 긁어와 감사하는 컴플라이언스 API. 앤트로픽은 세 번째 자리를 새로 열었다. 자기 인프라 안, 클라이언트와 모델 사이. 여기는 지금까지 어떤 서드파티도 발을 들일 수 없던 구간이었다.

발표문에 인용된 고객사도 이 지점을 정확히 짚는다. 클라우드 통신 회사 밴드위스(Bandwidth)의 정보보안 담당 부사장 앤드루 그리멧은 이렇게 말했다. "인퍼런스 훅은 클로드로 흘러가는 것을 실시간으로 검사할 수 있는 체크포인트를 더해준다. 민감한 것이 우리 환경을 떠나기 전에 말이다." 여기서 "우리 환경을 떠나기 전"이라는 표현은 엄밀히는 조금 느슨하다. 데이터는 이미 앤트로픽 서버에 도착해 있고, 다만 모델에 입력되기 전에 회사가 되돌릴 수 있는 것뿐이거든. 하지만 CISO가 이사회에 설명할 때 필요한 건 정확한 네트워크 다이어그램이 아니라 "우리가 마지막에 스위치를 쥐고 있다"는 문장이다.

그리고 앤트로픽은 이 기능을 혼자 팔지 않는다. 발표문은 넷스코프, 팔로알토 네트웍스, 프루프포인트, Z스케일러를 호환 대상으로 명시했다. 이 네 곳은 이미 대기업 안에 DLP 정책 엔진을 깔아둔 회사들이야. 즉 "새 보안 제품을 사라"가 아니라 "이미 산 그 스캐너를 클로드 앞에 그대로 갖다 붙여라"는 제안이다. 자체 서버를 직접 짜도 되고. 이 유통 전략이 이 발표의 절반이다.

5초 안에 allow냐 deny냐, 그 5초의 설계

기술 구조는 놀랍도록 단순하다. 그래서 오히려 뜯어볼 게 많아.

흐름은 이렇다. ① 사용자가 통제 대상 화면에서 프롬프트를 제출한다. ② 앤트로픽이 조직이 설정한 엔드포인트로 HTTPS POST를 보낸다. 본문에는 대화 전문이 담기고, 조직이 서명 시크릿을 생성한 뒤로는 모든 요청이 Standard Webhooks 규격에 따라 서명된다. ③ 조직의 서버가 내용을 평가해 설정된 판정 타임아웃 안에 응답한다. ④ allow면 추론이 그대로 진행되고, deny면 요청이 거부되며 사용자에게는 서버가 준 deny_reason과 관리자가 설정해둔 안내 문구가 이어 붙은 메시지가 뜬다.

서명 방식은 웹훅 좀 다뤄본 사람에게는 익숙하다. webhook-id, webhook-timestamp, webhook-signature 세 헤더가 오고, 서명은 {webhook-id}.{webhook-timestamp}.{원본 바디 바이트}에 대한 HMAC-SHA256을 base64로 인코딩한 값이다. 문서는 검증 버그의 대부분이 두 가지에서 난다고 친절하게 경고한다. 첫째, JSON 파싱이나 재인코딩 전의 원본 바이트로 HMAC을 계산할 것. 둘째, 시크릿의 whsec_ 접두어를 뗀 뒤 URL-safe가 아니라 표준 base64 알파벳으로 디코딩할 것. 시크릿에 +나 /가 들어 있으면 URL-safe 디코더는 엉뚱한 키 바이트를 만들어내는데, 그게 대부분의 경우거든. 타임스탬프는 서버 시계 기준 앞뒤 5분을 넘으면 거부하라고 권한다.

운영 규약이 이 기능의 진짜 성격을 드러낸다. 판정 타임아웃은 관리자가 1밀리초에서 1만 밀리초 사이로 정하고 기본값이 5000밀리초야. 이 예산에는 커넥션, TLS 핸드셰이크, 요청, 응답이 전부 포함된다. 재시도는 딱 한 번, 100밀리초 뒤에, 그것도 커넥션 시도 자체가 실패했을 때만 한다. 서버가 이미 응답한 교환은 절대 재시도하지 않고. 그리고 타임아웃·비200 응답·파싱 불가 응답·도달 불가는 전부 "웹훅 실패"로 분류되는데, 여기가 핵심이다. 웹훅 실패는 절대로 거부(deny)로 변환되지 않는다. 대신 조직이 미리 정해둔 실패 처리 설정 — 요청을 막을 것인가, 검사 없이 통과시킬 것인가 — 이 대신 결정한다.

그리고 실패가 지속되면 서킷 브레이커가 열린다. 앤트로픽이 그 조직의 서버 호출을 아예 중단하고, 모든 요청에 실패 처리 설정이 적용된다. 복구는 자동이 아니야. 관리자가 서버를 고친 다음 콘솔에서 "판정 강제"를 다시 켜야 한다. 인라인 동기 검사를 프로덕션에 넣어본 사람이라면 이 설계에서 익숙한 냄새를 맡을 거야. 쿠버네티스의 어드미션 웹훅과 판박이거든. failurePolicy를 Fail로 두면 웹훅이 죽는 순간 클러스터가 멈추고, Ignore로 두면 통제가 조용히 사라진다. 인퍼런스 훅도 정확히 같은 딜레마를 관리자에게 넘긴다. 다만 여기서 멈추는 건 클러스터가 아니라 전사 직원의 클로드다.

보내는 것과 안 보내는 것의 경계도 꽤 신경 써서 그었다. 보안 서버가 받는 건 "사용자가 보는 것"이다. 대화 텍스트, 툴 호출과 그 결과, 첨부에서 추출된 텍스트, 이전 턴들. 반대로 절대 안 가는 건 시스템 프롬프트, 툴 정의, 앤트로픽 내부 컨텍스트, 클로드의 숨은 추론, 그리고 파일·이미지 원본 바이트다. 콘텐츠 블록은 공개 메시지 API와 같은 모델을 쓴다. text, tool_use(툴 이름과 인자), tool_result(툴 출력 텍스트, 에러 여부, 툴 이름, 매칭되는 tool_use_id), attachment(파일명, 미디어 타입, 바이트 크기, 추출된 텍스트).

여기서 크롤 요약과 실제 문서가 미묘하게 어긋나는 지점이 하나 있어서 짚고 간다. 발표문은 "프롬프트와 툴 호출 응답을 검사한다"고 쓰지만, 문서는 "오늘 존재하는 훅 이벤트는 prompt 하나뿐이며 응답 측 시행은 이후 이벤트로 계획돼 있다"고 명시한다. 둘 다 맞는 말이야. 에이전트 루프에서는 툴 결과가 돌아올 때마다 다음 추론 요청이 발생하고, 그 요청의 전문에는 방금 받은 tool_result가 이미 들어 있거든. 그러니까 툴 결과는 "모델이 그걸 읽고 다음 판단을 내리기 전"에 검사되는 게 맞다. 다만 클로드가 만들어낸 최종 출력 자체를 막는 기능은 아직 없다. MCP 커넥터가 사내 위키에서 긁어온 대외비 문서가 모델로 흘러드는 건 막을 수 있지만, 모델이 뱉은 답변이 나가는 건 아직 이 훅의 소관이 아니라는 뜻이야.

한계는 문서가 스스로 네 개를 나열한다. 첫째, 첨부는 메타데이터와 추출 텍스트로만 표현되고 원본 바이트는 안 가므로 이미지 전용 콘텐츠 — 예를 들어 문서를 찍은 스크린샷 — 는 검사되지 않는다. 이건 꽤 큰 구멍이야. 대외비 문서를 캡처해서 붙여넣으면 통과한다는 뜻이거든. 둘째, 판정은 허용 아니면 거부뿐이고 프롬프트를 다시 쓰거나 마스킹하는 건 지원하지 않는다. 기존 DLP가 흔히 쓰는 "주민번호만 ●●●로 가리고 나머지는 통과" 같은 부분 처리가 안 된다. 셋째, 클로드 플랫폼을 통한 API 접근 조직은 대상 밖이다. 넷째, 아마존 베드록과 구글 클라우드 경유는 지원하지 않는다. 여기에 음성 모드 미지원, 대화 제목 생성 같은 부수 요청 미전송이 덧붙는다.

개발자가 실제로 걸려 넘어질 함정도 문서에 대놓고 적혀 있다. 대화 전문은 잘리지 않고 통째로 전송되며 상한이 10MB다. 그런데 nginx의 client_max_body_size 기본값은 1MB이고 Express의 express.json()은 100KB다. 바디가 거부되면 그건 웹훅 실패로 집계되고, 실패 처리가 "요청 허용"으로 돼 있으면 — 하필 가장 위험한 초대형 프롬프트가 — 검사 없이 모델에 도달한다. 보안 통제가 가장 필요한 순간에 정확히 무력화되는 구조야. 앤트로픽이 읽는 응답 바디는 최대 64KiB이고, 요청은 160.79.106.0/24 대역에서 나온다. 문서는 이 대역 허용 목록이 서명 검증을 대체하지 못한다고 못 박는다. 같은 대역으로 인퍼런스 훅 말고 다른 아웃바운드 트래픽도 나가니까.

항목 내용
발표 2026년 8월 5일, 클로드 엔터프라이즈 베타
통제 범위 claude.ai, 클로드 코워크, 클로드 코드 (웹·데스크톱·CLI) / 훅 하나로 전부
미지원 클로드 플랫폼(API) 조직, 아마존 베드록, 구글 클라우드, 음성 모드
전송 방식 HTTPS POST, User-Agent: anthropic-dlp/1, Standard Webhooks 서명 (HMAC-SHA256)
훅 이벤트 오늘은 prompt 하나. 응답 측 시행은 향후 이벤트로 예정
판정 {"action":"allow"} 또는 {"action":"deny","deny_reason":…,"reference_id":…}
사용자 노출 deny_reason 최대 500자, 초과분은 잘림
감사 기록 거부 시 활동 피드에 inference_hooks_request_denied + reference_id
타임아웃 1~10,000ms, 기본 5,000ms (커넥션·TLS·요청·응답 전부 포함)
재시도 커넥션 실패 시에만 100ms 뒤 1회, 동일 webhook-id·동일 서명
실패 처리 조직이 선택: 요청 차단 / 검사 없이 통과
서킷 브레이커 지속 실패 시 호출 중단, 복구는 관리자가 수동으로 강제 재활성화
페이로드 상한 요청 최대 10MB(전문 미절삭) / 응답은 최대 64KiB만 읽음
전송되는 것 대화 텍스트, 툴 호출·결과, 첨부 추출 텍스트, 이전 턴
전송 안 되는 것 시스템 프롬프트, 툴 정의, 앤트로픽 내부 컨텍스트, 클로드의 숨은 추론, 원본 바이트
롤아웃 섀도 모드, 롤아웃 비율, 역할 기반 제외
권한 organization:manage (Admin·Owner·Primary owner)
출처 IP 160.79.106.0/24

표에서 가장 눈여겨볼 줄은 맨 아래쪽 "롤아웃"이야. 섀도 모드는 실제 트래픽에 대해 판정을 관찰하되 아무것도 막지 않는다. 롤아웃 비율은 요청의 일부만 검사한다. 역할 기반 제외는 특정 역할 구성원을 통째로 면제한다. 이 셋이 있다는 건 앤트로픽이 이 기능의 진짜 위험을 정확히 알고 있다는 뜻이다. 잘못 켜면 회사 전체가 AI를 못 쓰게 된다는 위험 말이야. 그래서 "첫날부터 아무도 막히지 않아도 되게" 설계했다고 문서가 직접 쓴다.

그리고 앤트로픽은 자기 문서에 인퍼런스 훅과 컴플라이언스 API를 나란히 놓은 비교표를 실었다. 이건 마케팅이 아니라 포지셔닝 선언에 가까워. 정리하면 이렇게 갈린다.

인퍼런스 훅 컴플라이언스 API 네트워크·엔드포인트 DLP
작동 시점 추론 실행 직전, 인라인 사후 요청이 회사망을 나갈 때
하는 일 요청별 실시간 허용/거부 활동·대화·파일·프로젝트·사용자 조회 트래픽 검사·차단·마스킹
호출 방향 앤트로픽이 우리 서버를 호출 우리가 앤트로픽 API를 호출 우리 인프라 안에서 완결
CLI·개인기기 커버 조직 단위로 균일 적용 로그로 사후 확인 에이전트·프록시 설치 범위까지만
지연 영향 매 요청에 왕복 시간 추가 없음 프록시 구간에 추가

이 기능으로 누가 뭘 얻나

가장 크게 얻는 쪽은 당연히 보안·컴플라이언스 팀이다. 다만 얻는 게 "차단 능력"이라고 요약하면 절반만 맞아. 진짜로 얻는 건 증거와 일관성이야. 지금까지 CISO가 감사인이나 규제기관 앞에서 AI 사용에 대해 할 수 있는 말은 "정책이 있고 교육을 했으며 로그를 보관합니다" 수준이었다. 이제는 "모든 통제 대상 요청이 우리 정책 엔진을 통과했고, 거부 건은 각각 참조 ID와 함께 활동 피드에 남아 있습니다"라고 말할 수 있다. 금융·의료·공공처럼 통제의 존재 자체를 증명해야 하는 산업에서 이 차이는 크다.

두 번째로 얻는 건 앤트로픽 자신이다. 이건 노골적으로 영업 마찰을 없애는 기능이야. 대기업 AI 도입 심사에서 가장 자주 막히는 질문이 "우리 데이터가 저쪽 모델에 들어가는 걸 우리가 통제할 수 있느냐"인데, 지금까지 모든 벤더의 답은 "약관과 데이터 보존 정책을 보세요"였다. 앤트로픽의 새 답은 "정책 판단권을 아예 당신 서버로 넘기겠다"다. 보안 심사에서 이 답을 이길 문장이 별로 없어. 그리고 부수 효과가 하나 더 있다. 한 번 회사 DLP 정책 엔진을 인퍼런스 훅에 붙여 프로덕션에서 돌리기 시작하면, 그 조직이 다른 모델 벤더로 옮기는 비용이 조용히 올라간다. 락인은 성능이 아니라 이런 배관에서 생긴다.

세 번째는 DLP 벤더 네 곳이다. 넷스코프·팔로알토·프루프포인트·Z스케일러 입장에서 생성형 AI는 원래 위협이었어. 트래픽이 점점 암호화되고, SaaS가 아니라 CLI와 IDE 안으로 들어가고, 결국 프록시로 볼 수 있는 게 줄어드는 흐름이었으니까. 그런데 이제 모델 제공자가 직접 "우리 서버 안에서 판정할 테니 당신 엔진에 물어보겠다"고 초대장을 보냈다. 자기 제품을 새로 만들지 않고도 가장 보기 어려웠던 구간의 가시성을 얻은 셈이다. 물론 이건 프레너미 관계이기도 하다. 그 초대장의 조건은 "판정 로직은 당신이, 통제 지점은 우리가 갖는다"거든.

네 번째는 개발자다. 여기서 재미있는 건 앤트로픽이 이 기능을 만들면서 사실상 새 직무 하나를 정의했다는 점이야. 문서는 "보안·컴플라이언스 팀이 정책을 인라인으로 시행하고, 개발자가 각 요청을 평가하는 AI 보안 서버를 만든다"고 역할을 나눠 적는다. 그리고 파이썬·타입스크립트·C#·Go·자바·PHP·루비 일곱 개 언어로 표준 라이브러리만 쓴 최소 서버 예제를 실었다. 전부 "바디를 비우고 {"action": "allow"}를 돌려주는" 스무 줄짜리 코드야. 진입 장벽을 일부러 바닥까지 낮췄다. 다만 예제 옆에 붙은 경고가 본질이다. "이 서버들은 서명되지 않은 요청을 포함해 모든 요청을 수락한다. 시행에 들어가기 전에 서명 검증을 추가하라."

반대로 애매해지거나 손해를 보는 쪽도 분명히 있다. 첫째는 직원 개인이다. 이 기능이 켜지면 내가 클로드에 쓴 문장 전부가 회사 서버로 전송된다. 정책 위반 여부와 무관하게 전문이 통째로 간다. 문서가 소개하는 활용 사례 중에는 아예 "실시간 대화 아카이빙 — 항상 allow를 돌려주면서 도착하는 전문을 그대로 보관"과 "프롬프트 텔레메트리 — 조직이 클로드를 어떻게 쓰는지 사용 시점에 측정"이 대놓고 들어 있다. 회사가 원하면 전 직원의 AI 대화를 실시간으로 통째 적재할 수 있는 파이프가 생긴 거야. 나쁘다는 게 아니라, 이건 DLP인 동시에 감시 인프라라는 사실을 양쪽 다 알고 있어야 한다는 뜻이다.

둘째 손해는 지연 시간이다. 문서가 담백하게 인정한다. "시행은 조직의 모든 통제 대상 요청 지연 시간에 AI 보안 서버의 왕복 시간을 더한다." 대규모 조직에 굴리기 전에 부하 테스트를 하라는 권고도 붙는다. 채팅 한 번에 200밀리초 더 붙는 건 아무도 눈치 못 채겠지만, 클로드 코드가 에이전트 루프를 돌면서 툴을 스무 번 호출하는 작업이라면 그 왕복이 스무 번 곱해진다. 게다가 보안 서버가 전문을 실제로 스캔한다면 — 대화가 길어질수록 전문은 커지고 스캔은 느려진다. 대화 후반부로 갈수록 느려지는 형태의 지연이야. 이건 벤치마크로는 잘 안 잡히고 사용자 체감으로만 드러난다.

삼성이 금지해서 배운 것, 마이크로소프트가 내장해서 얻은 것

이 영화는 이미 한 번 상영됐다. 2023년 4월, 삼성전자 디바이스솔루션 부문에서 20일 사이에 세 건의 유출이 연달아 터졌다. 엔지니어들이 반도체 설비 계측 관련 소스코드, 수율·불량 관련 프로그램, 그리고 사내 회의 녹취를 챗GPT에 그대로 붙여넣은 사건이야. 회사의 대응은 5월에 나왔다. 사내 기기와 네트워크에서 챗GPT를 포함한 외부 생성형 AI 사용 금지.

이 사례에서 진짜 배울 건 금지 자체가 아니라 금지의 수명이다. 금지는 유출을 멈추는 게 아니라 유출을 안 보이는 곳으로 옮긴다. 회사 노트북에서 막으면 개인 폰으로 옮겨가고, 그 순간 보안팀은 로그조차 못 본다. 업계가 "셰도우 AI"라는 말을 쓰기 시작한 게 그 무렵이야. 그리고 몇 년 뒤 대부분의 대기업이 도달한 결론은 같았다. 막는 게 아니라 통제된 창구를 열어주는 쪽이 낫다는 것. 인퍼런스 훅은 그 결론의 가장 최신 버전이다.

두 번째 사례는 CASB와 네트워크 DLP의 궤적이다. 2010년대 중반 클라우드 도입기에 이 카테고리가 폭발했다. TLS를 인터셉트하는 프록시를 세우고, 직원이 드롭박스나 세일즈포스로 뭘 올리는지 다 보겠다는 접근이었지. 상당히 성공했고, 넷스코프와 Z스케일러 같은 회사가 그 위에서 컸다. 그런데 이 모델은 구조적 취약점이 있었다. 인증서 핀닝, 개인 기기, 그리고 무엇보다 "앱이 아니라 API로 흐르는 트래픽"에는 힘을 잃는다는 점이야. 클로드 코드가 터미널에서 자기 세션으로 나가는 트래픽은 전형적으로 그 사각지대에 있다. 프록시 시대의 성공 공식이 AI 시대에 그대로 안 통한다는 게 확인됐고, 그래서 그 벤더들이 지금 앤트로픽의 초대장을 마다할 이유가 없는 거야.

세 번째는 성공 사례 쪽이다. 마이크로소프트가 퍼뷰(Purview) DLP를 마이크로소프트 365 코파일럿 안에 직접 넣은 경로. 2025년 11월 프리뷰로 시작해 2026년 4월 말 정식 출시됐고, 프롬프트에 민감 정보 유형이 포함되면 코파일럿이 아예 응답을 생성하지 않게 만드는 실시간 통제다. 이후에도 확장이 이어져서 민감 프롬프트에 대한 웹 검색 차단이 2026년 7월 정식 출시 궤도에 올랐고, 외부에서 온 메일을 코파일럿이 처리하지 못하게 막는 통제가 6월 프리뷰를 거쳐 2027년 1월 정식 출시로 예고돼 있다. 여기서 나온 교훈은 명확하다. AI 통제는 외부에서 덧대는 것보다 벤더가 내장하는 쪽이 이긴다는 것. 프롬프트가 모델에 들어가기 직전이라는 자리는 벤더만 소유할 수 있는 자리니까.

다만 실패 패턴도 이 사례에서 같이 배워야 한다. 퍼뷰 방식의 반복되는 불만은 "정확도"였어. 민감 정보 유형 매칭이 과하게 걸리면 멀쩡한 업무가 막히고, 느슨하게 걸면 통제가 형식이 된다. 인퍼런스 훅에서는 이 문제가 더 날카롭다. 마스킹이 없기 때문이야. 부분 처리 옵션이 없는 이진 판정에서 오탐 한 번은 곧바로 "일을 못 하게 됨"이다. 그래서 섀도 모드가 형식적인 기능이 아니라 사실상 필수 단계다. 이 기능을 처음부터 강제 모드로 켜는 조직은 첫 주에 헬프데스크가 마비될 가능성이 높아.

체크포인트는 방화벽에, 제니티는 에이전트에

같은 주에 같은 문제를 다르게 푼 발표가 최소 둘 더 있었다. 이건 우연이 아니라 카테고리 형성기의 전형적인 풍경이야.

첫 번째는 체크포인트다. 8월 초 R82.20 소프트웨어 릴리스와 함께 AI 네트워크 방화벽을 내놨어. 회사가 "업계 최초"라고 부르는 이 제품은 프롬프트, 자율 에이전트 동작, LLM 트래픽을 기존 방화벽에서 그대로 검사하겠다는 접근이다. 프롬프트 인젝션과 적대적 입력을 LLM에 닿기 전에 인라인으로 막고, 사내에서 어떤 AI 앱·에이전트·툴이 쓰이는지 발견해내고, 프롬프트의 용도에 따라 민감 데이터의 반출을 막는다. 새 인프라 없이 이미 돌리는 물리·가상 방화벽에 얹는다는 게 핵심 세일즈 포인트고. 논리는 명확해. "모델 벤더마다 훅을 붙일 게 아니라, 어차피 다 지나가는 네트워크에서 한 번에 보자."

앤트로픽 방식과 체크포인트 방식은 정확히 반대 방향의 트레이드오프를 갖는다. 네트워크 계층은 벤더 중립적이라 클로드든 챗GPT든 제미나이든 사내에서 만든 에이전트든 한 정책으로 덮는다. 대신 암호화·개인 기기·회사망 밖 접속이라는 오래된 구멍이 그대로 남는다. 인퍼런스 훅은 그 구멍이 없는 대신 클로드 엔터프라이즈 밖으로는 한 발짝도 못 나간다. 베드록도 안 되고 API 조직도 안 된다. 현실의 대기업은 결국 둘 다 사게 될 가능성이 높다.

두 번째는 제니티(Zenity)다. 8월 3일 노웨스트가 주도한 1억2500만 달러 시리즈C를 발표했고, 소프트뱅크 비전 펀드 2, 쿰라 캐피털, 히타치 벤처스, LG 테크놀로지 벤처스가 새로 들어왔으며 버텍스 벤처스·서드포인트·DTCP·인텔 캐피털이 재참여했다. 누적 조달액은 약 1억8500만 달러. 이 회사의 접근은 또 달라서, 프롬프트가 아니라 에이전트를 본다. 기업 환경에 박혀 있는 AI 에이전트를 찾아내고, 그 에이전트의 의도를 실행 전에 분석해 승인·수정·차단한다는 구조야. 그리고 결정적으로 제미나이, 챗GPT 엔터프라이즈, 코파일럿, 클로드, 사내 자체 에이전트를 모두 지원한다고 밝힌다. 앤트로픽이 자기 표면 안에서 완결하려 할수록, 여러 벤더를 한 화면에서 보려는 수요는 오히려 커진다.

세 번째 축은 마이크로소프트와 오픈AI다. 마이크로소프트는 앞서 본 대로 퍼뷰를 코파일럿 안에 넣어 사실상 같은 전략을 먼저 실행했다. 다만 차이가 하나 있는데, 퍼뷰는 마이크로소프트가 정책 엔진까지 소유한다는 점이야. 앤트로픽은 정책 엔진을 고객에게 넘겼다. 자기 제품 라인이 없어서 넘긴 것이기도 하고, 그래서 넷스코프·Z스케일러 같은 회사를 적이 아니라 유통 채널로 만들 수 있었던 것이기도 하다. 약점이 전략이 된 케이스야. 오픈AI 쪽은 챗GPT 엔터프라이즈에 컴플라이언스 플랫폼을 제공하는데, 공개된 범위로는 로그와 메타데이터를 eDiscovery·DLP·SIEM에 연결하는 사후·조회형 구조에 가깝다. 서드파티 통합 파트너들이 "실시간에 가깝게" 위험을 표면화하지만, 앤트로픽처럼 추론 직전에 벤더가 고객 서버의 판정을 기다리는 인라인 게이트를 공식 문서로 규격화한 사례는 아직 눈에 띄지 않는다.

마지막 축은 이 기능이 만들어낸 새로운 공격면 자체다. 생각해봐. 이제 전 직원의 클로드 대화 전문이 회사가 운영하는 인터넷 노출 HTTPS 엔드포인트 하나로 실시간 집결한다. 그 서버가 뚫리면 유출되는 건 DLP 정책이 아니라 회사가 AI에게 물어본 모든 것이다. 앤트로픽 문서가 서명 검증을 그토록 집요하게 설명하고, IP 허용 목록이 서명 검증을 대체할 수 없다고 못 박고, 시크릿 로테이션 시 약 1분간 이전 시크릿 서명 요청이 도착할 수 있으니 전환 기간 동안 두 시크릿을 모두 수용하라고 안내하는 이유가 여기 있다. 통제 지점을 만든다는 건 새 단일 실패 지점을 만든다는 뜻이기도 하다.

그래서 뭐가 달라지는데

개발자 입장에서 당장 달라지는 건 두 가지다. 첫째, 회사가 이 기능을 켜면 클로드 코드의 체감 속도가 바뀔 수 있다. 특히 긴 세션에서. 대화 전문이 통째로 매 요청 전송되는 구조라 컨텍스트가 쌓일수록 페이로드가 커지고, 회사 보안 서버의 스캔 시간도 같이 늘어난다. 어느 날 갑자기 클로드 코드가 느려졌는데 원인을 못 찾겠다면, 인프라 팀에 "우리 조직에 인퍼런스 훅 켜져 있냐"고 한 번 물어볼 만해. 둘째, 만약 네가 그 보안 서버를 만드는 쪽이라면 문서의 함정 목록을 그대로 체크리스트로 써라. 원본 바이트 HMAC, 표준 base64 디코딩, webhook-id 기반 멱등 처리, 10MB 바디 상한 설정, 그리고 모르는 type 값이 오면 에러가 아니라 allow를 돌려줄 것. 마지막 항목이 특히 중요한데, 앤트로픽이 새 이벤트 타입을 추가했을 때 네 서버가 에러를 뱉으면 그게 웹훅 실패로 쌓여 서킷 브레이커를 열어버리거든. 즉 미래의 기능 추가가 오늘 짠 코드 때문에 전사 장애가 될 수 있다.

기업 의사결정자한테는 이게 조달 조건표를 바꾸는 사건이다. 지금까지 AI 벤더 비교표의 보안 항목은 대부분 정책 문서 대조였다. 데이터 학습 사용 여부, 보존 기간, 인증 보유 현황. 이제 여기에 기술적으로 검증 가능한 항목이 하나 생겼다. "추론 직전 인라인 통제를 우리 정책 엔진으로 할 수 있는가." 다음 갱신 협상 때 이 질문을 넣어보면 벤더들의 답이 꽤 갈릴 거야. 다만 도입 순서는 냉정하게 잡는 게 좋다. 섀도 모드로 최소 몇 주 돌려서 실제 거부율을 재고, 역할 제외 목록을 먼저 정리하고, 실패 처리를 "차단"으로 둘지 "통과"로 둘지 경영진 결재를 받아둬라. 그 스위치 하나가 사고 시 회사가 멈추느냐 통제가 사라지느냐를 가른다. 그리고 이건 컴플라이언스 팀만의 결정이 아니야.

투자자 관점에서는 신호가 둘이다. 하나는 AI 보안이 지금 확실히 자본이 몰리는 구간이라는 것. 같은 주에 제니티가 1억2500만 달러를 받았고, 업계 집계에 따르면 RSAC 2026 전후 2주 동안에만 에이전트 AI 보안 분야에서 3억9200만 달러 이상의 신규 조달이 발표됐다. 다른 하나는 방향이 훨씬 미묘하다는 것. 모델 벤더가 통제 지점을 자기 인프라 안으로 흡수하는 흐름은, 그 자리를 노리던 스타트업에게 좋은 소식이 아니야. 앤트로픽이 "판정 로직은 파트너에게"라고 했지만, 판정 로직은 결국 기존 DLP 대기업이 이미 갖고 있는 자산이다. 신생 업체가 팔 수 있는 건 그 위의 무언가 — 여러 벤더를 가로지르는 통합, 에이전트 행위 분석, 오탐을 줄이는 맥락 이해 — 여야 한다. 실제로 제니티가 멀티 벤더 지원을 전면에 내건 이유가 그거고.

일반 사용자한테 직접 오는 변화는 거의 없다. 다만 회사에서 클로드를 쓴다면 하나는 알아둘 만해. 이 기능이 켜진 조직에서는 네가 클로드에 쓴 문장이 — 위반이든 아니든 — 회사 서버로 전송된다. 사내 AI 사용 정책을 한 번 읽어보는 게 손해는 아닐 거야. 그리고 회사 바깥에서는 아무것도 안 바뀐다. 개인 요금제 클로드에는 해당 없고, 앤트로픽이 개인 대화를 이런 식으로 검사하는 것도 아니다.

마지막으로 이 발표 전체를 한 문장으로 압축하면 이렇다. 기업 AI 보안의 무게중심이 "네트워크에서 막기"와 "나중에 감사하기" 사이에서, "모델 벤더가 열어준 인라인 게이트"로 이동하기 시작했다. 커뮤니티에서 최근 화제가 된 연구 — 4만 건의 시뮬레이션에서 사람이 AI 에이전트의 위험한 명령 세 건 중 한 건을 승인해버렸다는 — 를 같이 놓고 보면 이 방향이 왜 필연인지 더 분명해진다. 사람이 매번 승인 버튼을 누르는 방식은 규모를 감당 못 한다. 결국 기계가 기계를 검사하게 되는 거고, 인퍼런스 훅은 그 검사 지점을 어디에 둘 것인가에 대한 앤트로픽의 답이다. 베타라는 딱지가 붙어 있고 필드명과 헤더가 정식 출시 전에 바뀔 수 있다고 문서가 미리 경고하고 있지만, 자리 자체는 이미 잡혔다.

🥄 남은 궁금증 세 가지

— 그래서 나랑 무슨 상관이야? 개인 계정으로 클로드 쓰는 사람한테는 직접적인 영향이 없어. 다만 회사 클로드 엔터프라이즈를 쓰고 있다면, 어느 날부터 네 프롬프트 전문이 회사 보안 서버를 거쳐 갈 수 있고 특정 요청은 사유와 함께 막힐 수 있어. 사내 AI 정책 공지가 오면 그냥 넘기지 말고 읽어보는 게 좋아.

— 이게 왜 하필 지금이야? 클로드가 채팅창 하나가 아니게 됐거든. 1월 말 코워크 프리뷰, 4월 정식 출시와 매니지드 에이전트까지 붙으면서 직원이 클로드를 만지는 창구가 웹·데스크톱·CLI로 벌어졌고, MCP 커넥터와 플러그인이 사내 데이터를 그 안으로 끌어오기 시작했어. 창구마다 따로 통제하는 방식이 한계에 온 시점에, 체크포인트의 AI Security Report 2026이 집계한 것처럼 민감 데이터를 담은 프롬프트 비율이 1년 만에 두 배가 됐다. 조직 단위로 한 번에 거는 통제가 필요해진 거야.

— 오픈AI나 마이크로소프트보다 앞선 거야? 부분적으로만. 마이크로소프트는 퍼뷰 DLP를 코파일럿에 넣어 2026년 4월에 이미 정식 출시했으니 "벤더 내장 실시간 통제"라는 아이디어 자체는 앤트로픽이 먼저가 아니야. 다른 건 소유권이다. 퍼뷰는 마이크로소프트가 정책 엔진까지 갖고, 앤트로픽은 판정을 고객 서버로 넘겼거든. 그게 더 유연하다는 건 맞는데, 그만큼 고객이 서버를 잘 만들어야 작동한다는 뜻이기도 해. 오픈AI 쪽은 공개된 범위로는 사후 조회형 컴플라이언스 플랫폼에 가까워서 결이 다르고. 어느 쪽이 결국 표준이 될지는 아직 단정하긴 일러.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.