「막아 둔」 규칙은 정말 막고 있었습니까

회사가 AI 도구에 규칙을 적어 둡니다.
「이 폴더는 고치지 마라」, 「이 명령은 안 된다」 같은 줄입니다.

적어 둔 뒤에는 그 줄이 적힌 대로 작동한다고 믿기 쉽습니다. 그런데 규칙을 읽는 것은 사람이 아니라 검사기이고, 검사기는 적힌 문장과 다른 것을 봅니다.

9월 12일 새벽에 나온 Claude Code 2.1.269 와 전날 2.1.268 은 그 믿음이 어긋나던 자리 셋을 고쳤습니다. 대표가 가져갈 것은 고쳐진 내용보다, 그런 자리가 있었다는 사실입니다.

변경 기록에 이런 줄이 있습니다.
예외 규칙이 자기 파일 밖까지 번지던 자리입니다.

"Fixed a deny or ask permission rule starting with `!` applying beyond the settings source that wrote it; such a rule now applies only within its own source, and a bare `!` negation is ignored"

풀어 쓰면 이렇습니다. 느낌표로 시작하는 줄은 「이건 예외로 풀어 준다」는 뜻입니다.

그 줄이 회사 설정 파일에 있든 개인 설정 파일에 있든, 예전에는 다른 층의 금지까지 풀고 있었습니다. 이제는 자기 파일 안에서만 풉니다.

두 번째 줄은 다른 명령으로 쓰면 안 걸리던 자리입니다.

"Fixed `Edit()` deny rules and the write-path check not applying to the file a Bash `tee` command writes; a `Bash(tee:*)` allow rule no longer covers destinations outside the working directories"

「이 파일은 수정 금지」라고 적어 두면 편집 도구는 막혔습니다. 그런데 터미널 명령 하나로 같은 파일에 쓰는 길은 검사에서 빠져 있었습니다. 이제는 그 명령이 어디에 쓰는지까지 봅니다.

세 번째 자리는 전날 판에 있습니다. 다른 이름으로 부르면 안 걸리던 자리입니다.

"Fixed deny and ask permission rules on symlinked directories (`/etc`, `/tmp`, `/var` on macOS; `/bin` on Linux) not applying when a path was given by its real location, and Bash commands ignoring deny rules written on a symlinked path spelling"

맥에서 어떤 폴더는 이름이 둘입니다. 겉으로 부르는 이름과 실제 위치의 이름입니다. 겉 이름으로 금지를 적어 두면, 실제 위치의 이름으로 부를 때는 안 걸렸습니다.

같은 판에 한 줄이 더 있습니다. 검사기가 읽지 못하는 명령이 같은 줄에 섞여 있으면, 읽기·수정 금지가 통째로 빠지던 것도 고쳤습니다.

셋 다 「적혀 있었다」는 점은 같습니다. 그리고 셋 다 실제로는 열려 있었습니다.

규칙을 적는 사람은 뜻을 적습니다.
검사기는 글자를 읽습니다.

「/tmp 는 건드리지 마라」를 적은 사람은 그 폴더 전체를 뜻했습니다. 검사기는 그 글자와 똑같은 경로만 봤습니다. 실제 위치의 이름으로 온 요청은 다른 글자였고, 그래서 통과했습니다.

저희 상담 기록에 같은 결의 장면이 있습니다. 화상회의 도구의 연결 열쇠를 등록하던 날, 담당자가 열쇠가 잘 되는지 한 번 확인 호출을 했습니다.

담당자가 읽은 정책은 「열쇠는 90일 동안 유효하다」였습니다. 실제 정책은 「확인 호출 한 번이면 그 열쇠는 죽는다」였습니다. 문서에 적힌 뜻과 시스템이 읽는 뜻이 달랐고, 대표님이 다시 클릭하셔야 했습니다.

AI 도구의 금지 규칙도 같은 자리에 있습니다. 규칙 문장이 틀린 게 아닙니다. 그 문장을 읽는 검사기가 어디까지 보는지를 아무도 시험하지 않았을 뿐입니다.

9월 10일 판을 다룬 지난 글은 「규칙 파일을 못 읽는 날」을 다뤘습니다. 이번 판은 「규칙 파일을 잘 읽는 날에도」 열려 있던 자리입니다. 파일이 멀쩡해도 검사기의 해석이 좁으면 문은 열려 있습니다.

규칙의 실효는 문장에 있지 않습니다. 검사기의 해석에 있습니다.

세 자리 중 대표가 가장 먼저 볼 것은 예외입니다.
금지는 좁게 새고, 예외는 넓게 샙니다.

느낌표 예외의 원래 뜻은 「이 파일 안의 금지 중 이것만 풀어 준다」였습니다. 실제로는 회사 설정이 걸어 둔 금지까지 개인 설정의 예외 한 줄이 풀고 있었습니다. 직원이 자기 편하자고 적은 한 줄이 회사 규칙 위에 올라간 셈입니다.

터미널 명령 허용도 같습니다. 「이 명령은 써도 된다」는 허용이 작업 폴더 밖의 파일에 쓰는 것까지 덮고 있었습니다. 이제는 작업 폴더 안에서만 허용됩니다.

저희가 연동 준비물을 요청할 때 권한을 적는 방식이 있습니다.

「읽기 권한만」이 예외를 적는 방식입니다. 무엇이 되는지 대신 어디까지만 되는지를 적습니다. 폭이 적혀 있지 않은 허용은 검사기가 넓게 읽습니다.

예외 한 줄이 어디까지 번지는지 모르면 예외를 두지 않습니다.

같은 판에 밤새 도는 자동화의 줄이 둘 있습니다.
하나는 멈춤의 자리, 하나는 보고의 자리입니다.

"Fixed `/goal` runs silently stalling after API errors, network drops, or token limits: the goal now retries with backoff, or pauses and says why, including until a usage limit resets"

밤새 목표를 주고 돌리는 기능이 API 오류, 네트워크 끊김, 사용량 한도에서 조용히 멈추고 있었습니다. 이제는 간격을 늘려 다시 시도하거나, 멈추되 왜 멈췄는지를 말합니다. 한도가 풀릴 때까지 기다린다는 것까지 말합니다.

"Fixed remote and headless sessions reporting "waiting for your input" while background agents were still running"

사람 없이 도는 세션이 뒤에서 작업을 돌리는 중에도 「입력 대기 중」이라고 보고하고 있었습니다. 대기 중이라는 표시를 끝났다고 읽으면, 돌고 있는 일을 끊게 됩니다.

저희 상담에서 이 자리는 견적을 물으실 때 나옵니다. 시세 수집 자동화를 의뢰하신 대표님의 질문입니다.

대표님은 「멈출 수 있다」를 먼저 짚으셨습니다. 맞는 순서입니다. 밤새 도는 것은 언젠가 멈추고, 문제는 멈춘 것을 언제 아느냐입니다.

저희 실측이 있습니다. 이 블로그를 밤에 쓰는 러너는 사람 없이 도는 세션입니다. 8월 3일 새벽, 뒤에서 돌린 작업이 600초 상한에 걸려 초안 0편으로 끝났고, 그날 아침까지 아무도 몰랐습니다.

그 뒤로 러너는 편당 세션을 따로 띄우고, 끝난 뒤 산출물이 실제로 있는지를 다시 셉니다. 세션이 「끝났다」고 말한 것과 글이 있는 것은 다른 사실이기 때문입니다. 이 글도 그 러너가 썼습니다.

멈춘 자동화가 결과보다 먼저 남길 것은 멈춘 사유입니다.

도구가 세 자리를 고쳤다고 회사 규칙이 시험된 것은 아닙니다.
시험하는 자리는 회사 쪽에 있어야 합니다.

AI가 만든 코드를 믿어도 되느냐는 질문에 저희가 드리는 기준이 있습니다. 규칙에도 그대로 적용됩니다.

금지 규칙을 적은 날, 같은 자리에서 뚫어 봅니다. 우회 명령으로 써 보고, 다른 이름으로 불러 보고, 다른 도구로 열어 봅니다. 막히면 규칙이고, 통과하면 문장입니다.

저희 블로그 발행기가 그렇게 돼 있습니다. 세션이 다 됐다고 말해도 등록되지 않습니다. 발행기가 파일과 구조를 다시 검사해 통과한 초안만 등록합니다.

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

금지 규칙은 적은 뒤 우회 명령·다른 이름·다른 도구로 한 번 뚫어 본다.
예외는 금지보다 좁게 적고, 폭을 못 적겠으면 두지 않는다.
밤새 도는 자동화는 멈췄을 때 사유를 남기게 하고, 「대기 중」을 「끝남」으로 읽지 않는다.

규칙을 적는 자리는 담당자에게 있어도 됩니다. 뚫어 보는 자리는 대표가 만듭니다.

정리

경고 신호

• 금지 규칙을 적은 뒤 한 번도 뚫어 본 적이 없다

• 직원의 개인 설정에 있는 예외 한 줄이 어디까지 미치는지 아무도 모른다

• 허용 규칙에 「어디까지만」이 적혀 있지 않다

• 밤새 도는 자동화가 멈추면 다음 날 아침에야 안다

좋은 신호

• 규칙을 적은 날 우회 명령·다른 이름·다른 도구로 뚫어 본 기록이 있다

• 예외가 금지보다 좁게 적혀 있고, 폭을 못 적는 예외는 없다

• 자동화가 멈추면 사유를 남기고, 「대기 중」과 「끝남」이 다른 표시다

• 세션이 끝났다고 말한 것과 산출물이 있는 것을 따로 센다

규칙 파일을 열기 전에 정할 네 가지

1. 이 금지 규칙을 마지막으로 뚫어 본 게 언제입니까?
   적은 날 한 번도 시험하지 않았다면 그 줄은 아직 문장입니다.

2. 예외 한 줄이 어느 파일까지 번집니까?
   개인 설정의 예외가 회사 금지를 풀고 있었다면 규칙의 층이 뒤집힌 것입니다.

3. 허용에 「어디까지만」이 적혀 있습니까?
   폭이 없는 허용은 검사기가 넓게 읽습니다.

4. 밤새 도는 자동화가 멈추면 누가 언제 압니까?
   사유를 남기지 않는 멈춤은 아침에야 발견됩니다.

자주 묻는 질문

Q. 이번 판에서 고쳐진 금지 규칙의 자리는 정확히 무엇입니까?

2.1.269 는 두 자리입니다. 느낌표로 시작하는 예외 규칙이 자기 설정 파일 밖까지 적용되던 것과, 편집 금지 규칙이 터미널의 tee 명령으로 쓰는 파일에는 적용되지 않던 것입니다. 2.1.268 은 심링크 폴더의 금지 규칙이 실제 경로로 부르면 안 걸리던 것과, 검사기가 읽지 못하는 명령이 같은 줄에 있으면 읽기·수정 금지가 빠지던 것을 고쳤습니다.

Q. 느낌표 예외 규칙은 이제 어떻게 동작합니까?

변경 기록은 그 규칙이 자기 소스 안에서만 적용된다고 적습니다. 회사 설정의 예외는 회사 설정 안에서만, 개인 설정의 예외는 개인 설정 안에서만 풉니다. 느낌표만 있고 뒤에 아무것도 없는 줄은 무시됩니다.

Q. tee 허용 규칙은 어디까지 허용됩니까?

변경 기록은 그 허용이 작업 폴더 밖의 목적지는 더 이상 덮지 않는다고 적습니다. 작업 폴더 안에서만 허용되고, 밖으로 쓰는 것은 별도의 규칙이 필요합니다.

Q. 밤새 목표를 돌리는 기능은 이제 멈추면 어떻게 됩니까?

변경 기록은 API 오류·네트워크 끊김·토큰 한도 뒤에 간격을 늘려 다시 시도하거나, 멈추고 그 이유를 말한다고 적습니다. 사용량 한도가 풀릴 때까지 기다리는 경우도 포함됩니다.

Q. 2.1.268 과 2.1.269 는 언제 나왔습니까?

npm 게시 시각 기준 2.1.268 은 2026년 9월 10일 18:41 UTC, 한국 시각 9월 11일 새벽 3시 41분입니다. 2.1.269 는 9월 11일 18:12 UTC, 한국 시각 9월 12일 새벽 3시 12분입니다. 확인 시점의 최신 버전이 2.1.269 였습니다.