사내 AI 요청 검사 관문 — 막으려다 오히려 통과시킵니다

직원이 AI에 무엇을 붙여 넣는지 회사가 통제하고 싶을 때가 있습니다. 고객 카드번호가 프롬프트에 섞여 나가는 것 같은 일이요. 이걸 위해 사내 AI 요청 검사 관문을 세울 수 있습니다 — 요청이 모델에 닿기 전에 우리 회사 서버가 대화록을 먼저 받아 「허용」이나 「차단」을 돌려주는 구조입니다. 공식 문서에 규약이 통째로 나와 있습니다.

그런데 이 문서를 끝까지 읽으면 막으려고 만든 장치가 오히려 통과시키는 경로가 셋이나 보입니다. 셋 다 「우리 서버가 잘못 만들어졌을 때」 벌어지는 일이고, 그중 둘은 기본 설정 그대로 두면 걸립니다.

📌 30초 요약

• 오류 응답은 차단이 아닙니다. 500을 던지면 「실패」로 처리되고, 실패 처리 설정에 따라 통과할 수 있습니다.
• 대화록이 최대 10MB로 옵니다. 웹서버 기본값은 1MB(nginx)·100kB(Express)라 그냥 두면 큰 요청이 검사 없이 지나갑니다.
• 실패가 이어지면 회로가 끊깁니다. 아예 안 물어보고 전부 실패 처리로 넘어갑니다.
• 지연이 전사에 붙습니다. 판정 제한시간은 1~10,000밀리초, 기본 5,000밀리초입니다.
• 서명 검증은 두 곳에서 대부분 틀립니다. 원본 바이트로 계산해야 하고, base64 해독기를 잘못 고르면 키가 틀어집니다.

① 무엇이 오고, 무엇은 안 오나

우리 서버가 받는 건 대화록입니다. 요청이 모델로 가기 직전에 한 번, 서명된 형태로 옵니다. 안에는 누가 보냈는지(계정 식별자·이메일), 어느 앱에서 왔는지, 어떤 모델을 쓸 건지, 그리고 지금까지의 대화 전문이 담깁니다.

중요한 건 안 오는 것입니다. 문서가 명확히 선을 긋습니다.

오는 것	안 오는 것
사용자가 쓴 글, 이전 차례들	기본 지시문
도구를 부른 내역과 그 결과	도구 정의
첨부에서 뽑아낸 글자	원본 파일 바이트
파일 이름·형식·크기	모델의 숨은 사고 과정

즉 이 관문은 「사용자가 눈으로 보는 대화」만 검사합니다. 이미지 같은 이진 데이터는 자리표시자로 바뀌어 오고, 실제 바이트는 절대 전달되지 않습니다. 파일 안에 뭐가 들었는지는 뽑아낸 글자로만 판단해야 한다는 뜻입니다.

놓치기 쉬운 설계 조언 하나 — 문서는 어느 앱에서 왔는지를 신뢰 경계로 삼지 말라고 못박습니다. 「출처가 사내 앱이니 통과」 같은 규칙을 세우면 안 된다는 겁니다. 그 값은 참고용 안내 정보일 뿐이고, 보안 판단의 근거로 쓰기엔 약합니다.

② 막으려다 오히려 통과시키는 세 갈래

여기가 이 글의 핵심입니다. 세 경우 모두 「차단」이 아니라 「실패」로 분류되고, 실패는 조직이 미리 정해 둔 실패 처리 설정을 따릅니다. 그 설정이 「통과시킴」이라면 검사 없이 모델에 도달합니다.

⚠️ 가. 오류 응답으로 차단을 알리면 안 됩니다

문서의 표현은 이렇습니다 — 「오류 상태로 차단을 알리지 마라. 200이 아닌 응답은 차단이 아니라 실패다.」

차단하려면 반드시 200으로 응답하고 본문에 「차단」이라고 적어야 합니다. 위험한 걸 발견하고 403을 던지는 건 자연스러운 습관인데, 여기서는 정반대로 작동합니다. 판정값이 「허용」도 「차단」도 아닌 값이어도 마찬가지로 실패입니다.

⚠️ 나. 본문 크기 기본값 — 이게 가장 조용히 뚫립니다

대화록은 잘리지 않고 통째로 오고, 상한이 10MB입니다. 그런데 흔한 웹서버 기본값은 훨씬 작습니다 — nginx는 1MB, Express는 100kB.

본문이 거부되면 그건 실패로 집계됩니다. 문서가 직접 짚은 결과는 이렇습니다 — 실패 처리가 「통과시킴」이면 큰 프롬프트는 검사 없이 모델에 도달합니다. 하필 긴 대화와 큰 첨부일수록 위험한데, 바로 그것들이 먼저 빠져나갑니다.

다. 회로 차단기가 세 번째입니다. 우리 서버 탓의 실패가 계속되면 아예 연락을 끊습니다. 그 뒤로는 모든 요청이 실패 처리로 넘어갑니다.

복구 방식이 흥미롭습니다. 끊긴 지 10분 뒤부터 분당 한 건꼴로, 실제 사용자 트래픽 하나를 우리 서버에 보내 살아났는지 봅니다. 여기서 알아 둘 대목이 있습니다 — 그 시험 요청의 판정은 집행되지 않습니다. 우리가 「차단」이라고 답해도 그 사용자의 요청은 그대로 진행됩니다. 조직 설정이 「막음」이어도 마찬가지입니다.

우리 서버가 이렇게 하면	결과
200 + 「차단」	차단됨 (유일하게 확실한 길)
500·403 등 오류	실패 → 설정에 따라 통과 가능
본문이 커서 거부	실패 → 설정에 따라 통과 가능
제한시간 초과·연결 불가	실패 → 설정에 따라
실패가 지속	회로 끊김 → 전부 실패 처리

결론은 하나입니다. 「우리 서버가 죽으면 어떻게 되는가」를 먼저 정하고 시작하세요. 막는 쪽으로 두면 서버 장애가 곧 전사 AI 중단이고, 통과 쪽으로 두면 장애 시간이 곧 무검사 시간입니다. 사내 관문을 세울 때 늘 나오는 딜레마인데(사내 LLM 게이트웨이 도입), 여기서는 기본값이 조용히 결정해 버립니다.

③ 지연은 전사에 붙습니다

이 관문을 켜는 순간, 조직의 모든 요청에 우리 서버 왕복 시간이 더해집니다. 문서도 이 점을 따로 경고하며 대규모로 펼치기 전에 부하 시험을 하라고 적습니다.

판정 제한시간은 관리자가 1밀리초에서 10,000밀리초 사이로 정하고 기본값은 5,000밀리초입니다. 이 예산에는 연결과 보안 협상까지 전부 포함됩니다 — 순수 처리 시간만 재면 안 됩니다.

재시도는 딱 한 번, 100밀리초 뒤에, 연결 자체가 실패했을 때만 일어납니다. 우리 서버가 한 번이라도 응답했다면 다시 오지 않습니다. 그러니 「일단 오류 냈다가 다음 시도에 제대로 답하자」는 전략은 성립하지 않습니다.

# 판정 응답 — 이 두 가지 형태만 유효하다

허용:
{ "action": "allow" }

차단:
{
  "action": "deny",
  "deny_reason": "카드번호로 보이는 내용이 있어 정책상 보낼 수 없습니다",
  "reference_id": "scan_01HXPT4R9V"
}

# 차단 사유 = 사용자 화면에 그대로 뜬다 (500자, 넘으면 잘림)
# 참조 번호 = 사용자에겐 안 보이고 감사 기록에만 남는다 (50자)
#   → 개인정보나 요청 내용을 넣지 말 것

차단 사유는 사용자가 실제로 읽는 문장입니다. 문서는 스캐너 코드를 뱉지 말고 무엇을 고쳐야 하는지 쓰라고 권합니다. 「정책 위반(E-4021)」 대신 「카드번호로 보이는 내용을 빼고 다시 시도하세요」 쪽이 맞습니다.

참고로 차단 판정은 형식이 좀 틀려도 살아남습니다. 사유가 길면 잘리고 참조 번호가 규격에 안 맞으면 조용히 버려지지만, 차단 자체는 그대로 집행됩니다. 반대 방향은 관대하지 않다는 게 앞서 본 대목이고요.

④ 서명 검증에서 대부분 틀리는 두 곳

우리 서버는 공개된 주소에 떠 있으니, 진짜 앤트로픽이 보낸 요청인지 확인해야 합니다. 표준 웹훅 규격을 따르고 머리글 셋을 씁니다 — 전달 식별자, 서명 시각, 서명값. 시각이 5분 이상 어긋나면 거부하라는 것도 규격입니다.

문서가 「검증 버그의 대부분은 이 둘에서 나온다」고 콕 집어 둔 게 있습니다.

• 원본 바이트로 계산할 것. 받은 본문을 해석하거나 다시 쓰기 전에 그대로 서명값을 구해야 합니다. 파싱했다가 다시 문자열로 만들면 공백 하나 차이로 어긋납니다.
• base64 해독기를 제대로 고를 것. 비밀값은 표준 알파벳(+와 / 사용)으로 인코딩돼 있습니다. 주소용 안전 해독기를 쓰면 키 바이트가 틀려집니다 — 그리고 문서 표현대로 비밀값에 그 두 글자가 들어 있는 경우가 대부분입니다.

운영에서 걸리는 것 둘도 있습니다. 비밀값을 교체하면 즉시 전환되지만, 이전 값으로 서명된 요청이 1분쯤 더 들어옵니다. 전환 중엔 두 값을 모두 받아들이게 해 두어야 그것들이 안 튕깁니다. 그리고 터널 서비스는 못 씁니다 — 개발할 때 흔히 쓰는 그 방식이 네트워크 정책에서 차단됩니다. 공인 주소·443 포트·공개 CA 인증서가 요구 조건입니다.

⑤ 자주 묻는 질문 (FAQ)

Q. 모델이 알아서 걸러 주는 것과 뭐가 다른가요?

거는 위치가 다릅니다. 모델 안의 안전 동작은 우리가 끄지도 늘리지도 못하는 고정된 바닥입니다. 이 관문은 모델에 닿기 전, 우리 회사 규칙으로 거릅니다. 카드번호·주민번호·사내 기밀처럼 우리만 아는 기준을 걸 수 있는 자리입니다.

Q. 차단은 안 하고 기록만 남기고 싶은데요?

문서가 그 용법을 직접 소개합니다. 무조건 「허용」을 돌려주는 서버를 두고 대화록을 저장하면 됩니다. 감사 기록을 주기적으로 긁어 오는 대신 밀어 넣어 주는 방식이 되는 셈입니다. 이때 저장하기 전에 먼저 응답하세요 — 그래야 우리 저장 시간이 사용자 대기 시간에 안 들어갑니다.

Q. 모르는 형식의 요청이 오면 어떻게 하나요?

문서의 지침은 분명합니다 — 「허용」을 돌려주라는 것입니다. 오류를 내면 실패로 집계되고, 실패가 쌓이면 회로가 끊겨 아는 요청까지 검사를 못 하게 됩니다. 모르는 항목이나 모르는 조각 유형 때문에 요청을 거부해서도 안 됩니다. 아는 것만 읽고 나머지는 건너뛰라는 게 규칙입니다.

Q. 붙인다면 순서를 어떻게 잡을까요?

① 무조건 허용하는 서버부터 띄워 왕복이 도는지 확인하세요. ② 본문 크기 상한을 10MB로 먼저 올리고 서명 검증을 붙이세요. ③ 한동안 기록만 남기며 실제 트래픽을 봅니다 — 여기서 우리 회사 대화가 얼마나 큰지, 지연이 얼마나 붙는지가 나옵니다. ④ 그다음에 규칙을 켜되 실패 처리 설정을 의식적으로 고르세요. ⑤ 전달 식별자로 중복을 걸러내고, 참조 번호로 우리 기록과 감사 기록을 이어 두세요.

✨ 정리

이 관문의 어려운 점은 규약이 아니라 「우리 서버가 잘못됐을 때 어느 쪽으로 넘어지는가」입니다. 오류를 던지면 차단이 아니라 실패고, 본문 크기 기본값을 안 고치면 가장 위험한 요청부터 빠져나갑니다. 실패가 이어지면 회로가 끊겨 검사 자체가 멈추고요. 그러니 규칙을 정교하게 짜기 전에 실패했을 때의 기본 동작부터 결정하세요 — 그게 이 장치의 실제 보안 수준입니다.

함께 보기: AI가 답을 거절할 때 — 오류가 아니라 정상 응답으로 옵니다 · AI 개발 비용·도구 총정리 허브

출처: Anthropic 공식 문서 「Develop an Inference hooks integration」(platform.claude.com, 2026년 9월 확인). 대화록 구성과 제외 항목, 「200이 아닌 응답은 차단이 아니라 실패다」, 10MB 상한과 nginx·Express 기본값 경고, 회로 차단기 동작(10분 후 분당 1건 시험, 시험 요청의 판정은 미집행), 제한시간 1~10,000밀리초·기본 5,000밀리초, 재시도 1회·100밀리초·연결 실패 시에만, 차단 사유 500자·참조 번호 50자, 서명 검증의 두 함정, 터널 서비스 미지원은 모두 해당 문서에 명시된 내용입니다. 이 기능은 베타이며 기업 조직에만 제공됩니다 — 문서가 「필드 이름과 요청 형태, 머리글이 베타 기간 중 바뀔 수 있다」고 직접 밝히고 있으니 적용 전 원문을 확인하세요. 필자가 직접 구축해 운영한 결과가 아니라 문서 기준의 정리입니다.