회사 규칙 파일이 안 읽히면 문은 열려야 합니까, 닫혀야 합니까

회사가 AI 도구에 규칙을 내려보냅니다.
「이 주소로만 연결해라」, 「이 플러그인만 써라」 같은 줄이 관리 설정 파일 한 장에 들어 있습니다.

그 파일이 어느 날 깨집니다. 배포 실수, 권한 꼬임, 형식 오류. 그날 도구는 어느 쪽으로 넘어져야 합니까.

9월 10일 새벽에 나온 Claude Code 2.1.267 은 이 자리를 「닫힘」으로 고쳤습니다. 대표가 가져갈 것은 그 방향과, 그 방향을 정하는 자리입니다.

변경 기록에 이런 줄이 있습니다.
짧지만 회사 규칙의 성격을 바꾸는 줄입니다.

"Fixed managed `allowedHttpHookUrls`, `httpHookAllowedEnvVars` and `allowedChannelPlugins` to admit nothing, not everything, when unreadable"

풀어 쓰면 이렇습니다. 조직이 내려보낸 관리 설정 세 항목이 읽히지 않을 때, 예전에는 전부 허용됐고 이제는 아무것도 허용되지 않습니다.

세 항목은 전부 「이것만 된다」는 목록입니다. 도구가 자동으로 밖에 연결할 수 있는 주소 목록, 그 연결에 실어 보낼 수 있는 환경변수 목록, 조직이 허락한 채널 플러그인 목록입니다.

목록을 못 읽으면 예전에는 목록이 없는 것과 같았습니다. 목록이 없으면 제한도 없었습니다. 깨진 날 하루, 도구는 어디로든 연결되고 무엇이든 실렸습니다.

저희 상담 기록에 같은 모양의 목록이 있습니다. 화상회의 도구를 봇에 연결하던 자리입니다.

두 번째 말풍선은 대표님이 봇의 답장을 그대로 붙여 보내 주신 것입니다. 허용 목록에 없는 주소, 검증값이 없는 요청은 전부 거부됐습니다.

저희가 주소를 두 번 잘못 안내해 대표님이 세 번 클릭하셨습니다. 그건 저희 실수입니다. 그래도 연결이 하루 막힌 것이지, 그 하루 동안 열린 문은 없었습니다.

파일이 깨지면 전부 허용되는 구조는 규칙이 아니라 장식입니다.

열림과 닫힘 중 어느 쪽이 기본인지는 누군가 정합니다.
문제는 그 결정이 어디서 내려지느냐입니다.

저희 상담 기록에 그 장면이 있습니다. 봇이 도구를 못 쓰던 날, 담당자가 정책을 바꿨습니다.

「매번 승인」에서 「자동 허용」으로. 그날은 옳은 조치였을 수 있습니다. 그런데 이 결정은 채팅 한 줄로 내려졌고, 대표님은 결과만 받으셨습니다.

혼자 쓰는 작업기에서는 반대 방향의 요청이 훨씬 흔합니다. 열어 달라는 쪽입니다.

혼자 쓰는 실습 환경에서는 그렇게 열어도 됩니다. 물어볼 때마다 멈추면 일이 안 되니까요.

회사는 다릅니다. 직원 열 명이 각자 「안 물어보게」 열어 두면, 회사 규칙은 열 개의 개인 설정 아래에 깔립니다. 관리 설정은 그 위에 얹는 층이고, 이번 판은 그 층이 깨졌을 때의 값을 닫힘으로 못박았습니다.

9월 4일 판이 「사람 없이 돌 때 물을 일은 거절한다」로 질문의 기본값을 닫았다면, 이번 판은 「규칙 파일을 못 읽으면 거절한다」로 규칙의 기본값을 닫았습니다. 같은 방향, 다른 자리입니다.

기본값을 정하는 자리는 담당자의 채팅창에 있지 않습니다. 대표의 문서에 있어야 합니다.

같은 판의 두 번째 줄은 비용의 자리입니다.
돈이 아니라 생각 깊이에 상한을 겁니다.

"Added `maxEffortLevel` setting (top-level or per model under `modelSettings`): caps the effort level on every provider, including Bedrock, Vertex and Foundry; users can still pick a lower level"

풀어 쓰면 이렇습니다. 조직이 모든 사용자의 「생각 깊이」에 상한을 둡니다. 어느 경로로 쓰든 같이 걸리고, 사용자는 그보다 낮게만 고를 수 있습니다.

생각 깊이는 같은 질문에 도구가 얼마나 오래, 얼마나 넓게 따져보느냐입니다. 깊을수록 결과가 나아질 때가 있고, 값은 항상 더 나옵니다.

저희 상담에서 비용 이야기는 거의 늘 이 자리에서 나옵니다. 에이전트를 여럿 두려는 대표님과 나눈 대화입니다.

「토큰만 태운다」는 말이 핵심입니다. 같은 결과를 내는 데 더 많이 읽고 더 오래 생각하면 값만 오릅니다.

저희 실측도 있습니다. 블로그를 밤에 자동으로 쓰는 러너가 한 세션에 네 편을 이어 쓰던 8월, 대화가 6만 9천에서 30만 9천 토큰으로 부풀었습니다.

API 호출 174번이 매번 그 전량을 다시 읽어 하룻밤 3,290만 토큰이 나갔습니다. 그중 실제로 쓴 글은 18만 3천 토큰, 0.6%였습니다. 네 번째 글이 앞 세 편의 집필 이력을 174번 다시 산 구조였습니다.

계정별 돈 한도는 이런 일을 다음 달 청구서에서 잡습니다. 깊이 상한은 그날 잡습니다. 조직 기본을 중간에 두고, 꼭 필요한 자리만 올립니다.

같은 일을 매번 최고 깊이로 시키면 값이 몇 배로나옵니다.

세 번째 줄은 결과를 알 수 없던 자리입니다.
올리다 통신이 끊긴 게시 작업입니다.

"Fixed artifact publishes cut off by a dropped connection mid-upload: they now retry once when Claude Code can tell the upload never completed, instead of reporting an unknown outcome"

끊긴 게시가 「결과 알 수 없음」으로 끝나는 대신, 도구가 「끝까지 안 갔다」를 확인할 수 있을 때만 한 번 다시 시도합니다. 확인이 먼저고 재시도가 뒤입니다.

끊긴 채 끝난 발송·게시·저장은 「됐다」도 「안 됐다」도 아닌 「모른다」입니다. 그 칸은 중복을 막는 확인이 먼저, 재시도는 한 번만입니다. 이 자리를 안 정하면 같은 손님이 같은 문자를 두 번 받습니다.

이 발송이 끊긴 채 끝나면 「보냈다」로 적을지 「모른다」로 적을지가 먼저입니다. 「모른다」 칸이 있는 시스템만 한 번 더 보낼 자격이 있습니다.

같은 판에 부기할 줄이 둘 더 있습니다. 만료된 AWS·Google Cloud 자격증명이 「요청 실패」로 열 번 재시도한 뒤에야 재로그인 오류를 보이던 것, 사용량 한도 경고가 세션 중에 깜빡이던 것도 고쳤습니다.

전부 「깨졌을 때 무엇을 보여 주느냐」의 줄입니다. 열 번 재시도보다 한 번의 정확한 오류가 먼저입니다.

기본값은 닫힘 쪽으로, 상한은 조직 쪽으로. 세 줄이 같은 방향을 가리킵니다.

도구가 기본값을 닫힘으로 바꿨다고 회사 규칙이 저절로 생기지는 않습니다.
회사 쪽 문서에 칸이 있어야 합니다.

저희 블로그 발행기가 그렇게 돼 있습니다. 초안이 검증을 통과하지 못하면 등록되지 않고, 발행 뒤 라이브 검증에 실패하면 자동으로 내립니다. 승인 없는 글, 승인 뒤 바뀐 글은 빈 슬롯이 있어도 발행하지 않습니다.

「못 읽으면 닫힘」이 그 문서에 적혀 있어서 그렇게 돕니다. 적혀 있지 않았을 때는 죽은 세션이 「완료」로 보고된 밤이 있었습니다.

연동을 붙일 때 권한을 적는 방식도 같은 결입니다. 저희가 준비물을 요청할 때 쓰는 표현입니다.

「읽기 권한만」이라고 적습니다. 무엇이 되는지가 아니라 무엇까지만 되는지를 적어야, 키가 새거나 설정이 깨진 날에도 넘어지는 방향이 정해져 있습니다.

대표님이 가져갈 칸은 셋입니다.

직원 계정·연동·자동화마다 「설정을 못 읽으면 어느 쪽으로 넘어지나」를 적는다.
생각 깊이의 조직 기본을 중간으로 두고, 올리는 자리를 따로 적는다.
「모른다」로 끝난 발송·게시·저장은 확인 뒤 한 번만 다시 시도한다고 적는다.

규칙의 값은 정상인 날에는 보이지 않습니다. 깨진 날에 드러납니다.

정리

경고 신호

• 회사 규칙 파일이 깨졌을 때 무엇이 되는지 아무도 모른다

• 직원마다 「안 물어보게」 열어 둔 개인 설정이 회사 규칙 위에 있다

• AI 비용 관리가 계정별 돈 한도 하나뿐이다

• 끊긴 발송·게시가 「됐다/안 됐다」 둘 중 하나로만 기록된다

좋은 신호

• 계정·연동·자동화마다 「못 읽으면 닫힘」이 문서에 적혀 있다

• 생각 깊이의 조직 기본이 중간이고 올리는 자리가 따로 적혀 있다

• 기본값을 바꾼 결정이 채팅이 아니라 대표 문서에 남는다

• 「모른다」 칸이 있고, 재시도는 중복 확인 뒤 한 번만이다

규칙 문서를 열기 전에 정할 네 가지

1. 규칙 파일을 못 읽는 날 도구는 어느 쪽으로 넘어집니까?
   전부 허용으로 넘어지는 구조라면 그 규칙은 장식입니다.

2. 열림과 닫힘의 기본값을 누가 정했습니까?
   담당자의 채팅 한 줄로 바뀐 기본값은 대표가 모르는 규칙입니다.

3. 비용 상한이 돈 하나뿐입니까?
   생각 깊이의 조직 기본을 중간에 두는 것이 계정별 한도보다 먼저입니다.

4. 「모른다」로 끝난 작업을 어떻게 적습니까?
   됐다도 안 됐다도 아닌 칸이 있어야 중복 없이 한 번 더 시도할 수 있습니다.

자주 묻는 질문

Q. 이번 판에서 「못 읽으면 닫힘」으로 바뀐 항목은 정확히 무엇입니까?

관리 설정의 allowedHttpHookUrls, httpHookAllowedEnvVars, allowedChannelPlugins 세 항목입니다. 변경 기록은 이 세 항목이 unreadable 일 때 everything 이 아니라 nothing 을 admit 한다고 적습니다. 자동 연결 주소, 그 연결에 실을 환경변수, 허용 채널 플러그인의 목록입니다.

Q. 이전 버전에서는 어떻게 동작했습니까?

변경 기록의 표현을 그대로 옮기면 「전부 허용(everything)」이었습니다. 목록을 못 읽으면 목록이 없는 것과 같았고, 그날은 제한 없이 동작했습니다.

Q. maxEffortLevel 은 사용자가 무시할 수 있습니까?

없습니다. 변경 기록은 사용자가 더 낮은 수준만 고를 수 있다고 적습니다. 상한은 Bedrock, Vertex, Foundry 를 포함한 모든 제공 경로에 걸리고, 최상위 또는 modelSettings 아래 모델별로 둘 수 있습니다.

Q. 2.1.267 은 언제 나왔습니까?

npm 게시 시각 기준 2026년 9월 9일 18:25 UTC, 한국 시각 9월 10일 새벽 3시 25분입니다. 변경 기록 커밋은 같은 날 4시 58분입니다. 확인 시점의 최신 버전이 2.1.267 이었습니다.

Q. 저희 회사 문서에는 무엇을 추가해야 합니까?

직원 계정·연동·자동화마다 「설정을 못 읽으면 어느 쪽으로 넘어지나」 한 줄, 생각 깊이의 조직 기본과 올리는 자리, 그리고 「모른다」로 끝난 발송·게시·저장을 확인 뒤 한 번만 재시도한다는 줄입니다.