AI가 규칙을 읽고도 왜 안 지키는가 — 권장 문장을 종료 차단 게이트로 바꾸는 법

세 줄 요약

1. 규칙이 무시되는 건 모델이 반항해서가 아니라, 규칙이 명령이 아니라 판단 재료로 전달되기 때문이다. "반드시"를 굵게 써도 재료가 굵어질 뿐이다.
2. 지켜지는 규칙과 안 지켜지는 규칙을 가르는 건 강조어가 아니라 그것을 안 했을 때 「완료」라고 말할 수 있는가다. 말할 수 있으면 그 규칙은 권장 문장이다.
3. 게이트는 공짜가 아니다. 한 워크플로에 3~5개까지. 되돌리기 어려운 일과 위반이 2회 이상 실측된 일에만 걸고 나머지는 권장 문장으로 둔다.

강조어를 늘려서 해결되는 문제가 아니다. IMPORTANT를 YOU MUST로 바꾸고 파일을 200줄에서 80줄로 줄여도, 세션이 길어지면 같은 규칙이 같은 자리에서 또 빠진다. 규칙을 200줄까지 늘려 본 기록도 이미 공개돼 있다⁴. 바꿔야 하는 건 문장의 세기가 아니라 문장의 위치다 — 규칙을 작업 도중에 참고할 조언 자리에서 빼내, 작업을 끝냈다고 선언하는 조건 자리로 옮기는 것. 이 글은 그 전환을 어떤 기준으로 판단하고, 바꾼 뒤 재발이 실제로 사라졌는지 어떻게 세는지를 다룬다.

① 왜 "반드시"·"항상"이 결국 무시되는가

원인은 성격이 아니라 전달 구조다. 규칙 파일의 내용은 시스템 수준에서 강제되는 것이 아니라 프롬프트 컨텍스트의 일부로 들어가, 시스템 프롬프트·대화 이력·눈앞의 과제와 주의를 두고 경쟁한다. 한 영어권 분석은 이를 두고 "delivery mechanism, not a bug"라고 정리했고¹, 다른 글은 한 이용자의 반응을 인용해 규칙이 "probabilistic, not deterministic" 하다고 짚었다².

실무에서 규칙이 증발하는 경로는 셋이다.

지시 밀도. 규칙 40개 중 30개에 강조 표시가 붙어 있으면 강조는 신호가 아니라 서식이다. 전부가 최우선이면 최우선은 없다.

맥락 압축. 긴 세션에서 앞부분은 요약된다. 이때 살아남는 건 규칙의 취지고, 사라지는 건 집행 가능한 세부다. "로그를 남긴다"는 남고 "언제·어디에·어떤 형식으로"는 증발한다. 취지만 남은 규칙은 지켜졌는지 판정할 수가 없다.

과제 우선. 방금 받은 지시는 구체적이고 눈앞에 있으며 완료 신호가 명확하다. 규칙은 추상적이고 뒤에 있으며 안 지켜도 즉시 티가 안 난다. 이 경쟁에서 규칙이 이기는 경우는 드물다.

플랫폼이 대신 해결해 주기를 기다리는 선택지도 사실상 닫혀 있다. 규칙을 코드로 강제해 달라는 기능 요청이 공개 저장소에 올라왔지만 not planned로 닫혔다(2026-08-10 확인)³. 훅으로 도구 호출을 막는 방법이 남아 있으나 코드를 붙일 수 있는 환경에서만 쓴다. 코드 없이 지금 당장 쓸 수 있는 수단이 필요하다.

② Q. 내 규칙 파일의 어느 줄을 게이트로 올려야 하나?

한 문장으로 판정한다 — "이걸 안 했는데도 「완료」라고 말할 수 있는가?" 말할 수 있으면 그건 권장 문장이다. 앞에 무슨 단어를 붙였든 상관없다. 말할 수 없어야 게이트다.

게이트 문장에는 세 조각이 반드시 들어간다. 하나라도 빠지면 도로 권장 문장이 된다.

1. 완료 부정문 — "X를 하지 않았으면 이 작업은 끝난 것이 아니다. 「완료」라고 썼어도 미완성이다."
2. 관측 가능한 통과 증거 — "검토했다"는 증거가 아니다. "검토 로그에 한 줄이 늘었다"가 증거다. 사람이든 기계든 나중에 확인할 수 있는 흔적이어야 한다.
3. 실패 시 대체 경로 — 못 했을 때 무엇을 하는지. 이게 없으면 에이전트는 멈추거나, 더 흔하게는 조용히 우회한다.

가운데 행이 이 표의 핵심이다. 대체 경로가 있는 게이트라야 실제로 걸린다. "무조건 하나는 찾아라"만 있으면 못 찾은 회차에 억지 항목이 올라오고, 그러면 그 게이트는 두 번째 주에 무시되기 시작한다.

③ 게이트로 바꾼 뒤 재발이 사라졌는지 실측하는 법

바꿨다는 느낌은 증거가 아니다. 순서는 다섯 단계다.

1. 위반의 정의를 먼저 문장으로 적는다. 판정 기준이 흔들리면 뒤의 숫자가 전부 흔들린다.
2. 전환 전에 2주를 센다. 전환한 다음에 세기 시작하면 비교군이 없다. 가장 많이 건너뛰는 단계다.
3. 한 번에 규칙 하나만 바꾼다. 셋을 동시에 올리면 무엇이 효과였는지 영영 모른다.
4. 같은 기간·같은 회차 수로 비교한다. 회차 수가 다르면 건수가 아니라 비율로 본다.
5. 게이트를 통과했지만 내용이 빈 건수를 따로 센다. 여기가 진짜 관측 지점이다.

예를 들어 어떤 팀이 "매 회차 점검 로그를 남겨라"를 게이트로 올린 뒤 이런 표를 얻었다고 하자(설명용 가상 수치다).

11에서 0으로 떨어진 것이 눈에 띄지만, 읽어야 하는 숫자는 3이다. 로그 줄은 늘었는데 내용이 비어 있는 회차가 3건이면 게이트 문장의 「증거」 정의가 헐겁다는 뜻이다. 이 비율이 10%를 넘으면 규칙을 다시 손봐야 한다.

함정도 셋이다. 전환 직후 2~3일은 빼고 센다 — 새 규칙은 잠깐 잘 지켜지다가 원위치한다. 소요 시간을 반드시 같이 센다 — 회차당 1분 30초가 늘었다면 하루 8회 기준 매일 12분이고, 그 비용이 위반 11건보다 싼지 판단해야 한다. 그리고 "위반 0"이 규칙 준수가 아니라 그 작업 자체를 덜 하게 된 결과일 수 있다. 회차 수와 산출물 건수를 함께 보지 않으면 이 착시를 못 잡는다.

④ 전부 게이트로 만들면 무슨 일이 생기나

게이트는 한 번 효과를 보면 전부 게이트로 만들고 싶어진다. 그러면 세 가지가 순서대로 온다. 형식주의(통과 증거만 채우고 내용이 빈다) → 정지(대체 경로 없는 게이트가 작업을 세운다) → 자율성 상실(게이트 채우는 데 시간을 다 써서 정작 봐야 할 문제를 안 본다). 경험적 상한은 한 워크플로에 3~5개다. 넘어가면 우회가 시작된다.

게이트로 올릴 자격 — 다섯 중 둘 이상 해당할 때만 올린다.

• 안 했을 때 되돌리기 어렵다(발송·배포·삭제·과금)
• 같은 위반이 2회 이상 실측됐다(느낌이 아니라 기록으로)
• 통과 증거를 나중에 기계가 확인할 수 있다
• 지키는 비용이 회차당 1~2분 이내다
• 못 지켰을 때의 대체 경로를 한 줄로 쓸 수 있다

반대로 권장 문장으로 두는 편이 나은 것은 네 가지다. 취향에 가까운 것(문체·톤·표 정렬), 판단이 매번 달라지는 것(무엇을 우선할지), 위반 비용이 낮은 것, 그리고 월 1회도 안 쓰이는 것. 마지막이 특히 중요하다 — 쓰이지 않는 게이트는 매 세션 컨텍스트만 차지하면서 ①의 「지시 밀도」를 올려 다른 게이트까지 같이 묽게 만든다.

규칙 파일을 늘리는 것과 규칙이 지켜지는 것은 완전히 다른 일이다. 한 줄을 추가할 때마다 물어야 할 것은 하나뿐이다. 이건 조언인가, 끝의 조건인가. 조언이면 강조하지 말고, 끝의 조건이면 강조하는 대신 "이걸 안 하면 끝난 게 아니다"라고 쓴다. 본문의 사례·수치는 전부 설명용 가상값이다.