AI가 도구를 사용하기 직전에 반드시 거치는 '문지기(gatekeeper)'를 두어 위험한 작업을 막고 있습니다. 지난 9월 11일부터 약 6주 동안, 이 문지기가 대화 중에 작업을 중단시킨 횟수는 283회였습니다. 그중 282회는 AI가 제가 발언을 기다리지 않고 스스로 다음 작업으로 진행하고 있었기 때문이었습니다.
작업이 중단된 AI가 다음 수를 생각할 때 읽게 되는 것은 문지기가 반환한 문구입니다. 단순히 '안 돼'라고만 응답하면, AI는 스스로 다른 방법을 찾아 나설 수도 있습니다. 그래서 이 문지기는 작업을 멈출 때, 가능한 한 '대체 방법'도 AI에게 전달하고 있습니다.
작업이 중단된 AI가 다음으로 진행하는 것 자체는 Claude Code의 일반적인 움직임이며, 안내가 효과를 발휘했다는 증거는 아닙니다. 다만, 멈춘 후에 AI가 사람에게 질문하는 도구를 사용해 작업을 멈춘 경우는 단 한 번도 없었습니다.
작업이 중단된 그 자리에서는 작업이 실행되지 않았습니다(외부로 내보내는 등의 작업은 나중에 제가 직접 실행합니다). 하지만 그 다음 수순이 안전했는지, 다른 우회로를 찾고 있지는 않았는지는 확인하지 못했습니다. 계산 방식은 4절에서 설명하겠습니다.
Claude Code의 훅이 위험한 작업을 만났을 때 응답하는 방법에는 사람에게 확인을 요청하는 ask와, 작업을 중단시키고 이유를 AI에게 반환하는 deny가 있습니다. 저의 문지기는 deny에 가깝습니다. 사람에게 확인을 요청하는 방식은 읽히지 않거나 전달되지 않는 경우가 있었습니다(1절). 반면, 작업이 중단될 때의 문구는 AI에게 반드시 도달합니다.
저는 프로그램을 작성할 수 없습니다. 그럼에도 지금은 이 문지기의 보호를 받으며 매일 작업을 하고 있습니다. 문지기 내부 내용은 무엇이 위험한지 AI가 분석하게 하고, 그것을 제가 말로 규칙화하여 Claude Code에 프로그램으로 작성하도록 시킨 것입니다.
이번 글에서 다룰 것은 문지기의 '형식'이며, 코드는 담고 있지 않습니다. 가져가실 수 있는 내용은 다음 3가지입니다.
- 중단할지 통과시킬지를 결정하는 판정 흐름도(2절)
- 작업이 중단될 때 AI에게 반환하는 문구의 형식(3절)
- 자신의 환경에서 문지기를 만들 때의 순서(7절)
예상 독자는 Claude Code에 작업을 맡기면서, AI의 어떤 지점에서 작업을 멈출지 고민하고 있는 사람입니다. 전제는 Claude Code의 PreToolUse 훅이며, 내용은 2026년 10월 시점의 것입니다.
1. 확인 다이얼로그에 안전을 맡기고, 성공하지 못했다
첫 번째 문지기는 위험해 보이는 작업을 발견하면 확인 다이얼로그를 표시하도록 만들어졌습니다. 사용하고 있는 것은 Claude Code의 PreToolUse 훅입니다. AI가 도구를 사용하기 직전에 스스로 정한 검사를 끼워 넣을 수 있는 장치입니다.
파일이 한꺼번에 사라졌다
문지기를 만들던 도중에, 제가 가지고 있던 파일들이 한꺼번에 사라진 적이 있습니다. AI가 Git의 이력을 수정하면서, 로컬 폴더가 그 새로운 이력에 맞춰 재정렬되었기 때문입니다. 당시 문지기에는 이 작업을 중단시킬 규정이 없었습니다.
사라진 것은 원본 데이터가 다른 곳에 남아있는 복사본뿐이었습니다. 저는 신경 쓰지 않았지만, AI는 지나치게 초조해했습니다. 그 당황스러움 때문에 이야기가 다소 과장되었습니다.
그 이후로도 규정을 추가하며 위험해 보이는 작업에는 계속 확인을 요청했습니다. 이것으로 안전해질 것이라 생각했습니다. 하지만 잘 되지 않았습니다. 이유는 두 가지입니다. 둘 다 '사람이 확인 문구를 읽지 않거나, 읽을 수 없다'는 같은 지점으로 귀결되었습니다.
첫 번째는 승인 피로도(Approval Fatigue)
확인이 매번 나오다 보니, 저는 점차 내용을 읽지 않고 '예'를 누르게 되었습니다. 이는 저만의 이야기는 아닌 것 같습니다. Anthropic은 Claude Code 이용자가 확인의 97%를 승인하고 있다고 공개했습니다. 같은 기사에 있는 실험에서는, 위험한 명령을 사람이 막아낼 수 있었던 비율이 작업 초반에는 약 17%였습니다. 그러나 50회 이상의 확인을 거치자 약 5%까지 떨어졌다고 합니다(출처: claude.com/blog/auto-mode-default-in-claude-code).
두 번째는, 확인이 도달하지 않았다는 점
더 근본적인 문제가 있었습니다. 2026년 9월, 문지기가 내보냈어야 할 확인이 제 화면에 도착하지 않은 것을 알게 된 것입니다. AI에게 맡겨 진행하는 자동 모드뿐만이 아닙니다. PC나 버전에 따라 평소 모드에서도 같은 일이 발생했습니다. 반면, 앱 자체의 확인은 나왔습니다. 원인은 확실히 밝혀내지 못했습니다.
기록에는 '확인을 했다'고 남아있지만, 사람은 아무것도 보지 못한 상황입니다. 이대로는 확인을 하지 않은 것과 같습니다.
'중단시키는 쪽'이 효과가 있었다
반대로 '멈추는' 쪽은 어떤 모드에서도 제대로 작동한다는 것을 실제로 확인했습니다. 멈췄을 때의 이유 문구는 AI에게 전달되는 구조로 되어 있습니다 (제3절).
수신처를 사람에서 AI로
이에 따라 방침을 변경했습니다. 안전에 관한 문구의 수신처를 읽지 않는 사람이 아닌, 반드시 도달하는 AI로 옮긴 것입니다.
문지기의 답변은 두 가지로 압축했습니다. '통과'시키거나, '멈추고 대안적인 방법을 AI에게 반환'하는 것입니다. 되돌릴 수 있는 형태의 작업(제2절 구분 C)은, 먼저 되돌릴 수 있는 상태를 만든 후에 통과시킵니다.
현재의 문지기는 확인 다이얼로그를 전혀 출력하지 않습니다. 대부분의 작업은 문지기가 멈출지 통과시킬지를 결정합니다. 멈췄을 때는 AI가 안내문을 읽고 스스로 다음 단계로 진행합니다.
문지기가 저를 호출하는 경우는 외부로 내보내는 작업이나, 문지기 자체(설정이나 규칙을 포함)를 수정하는 작업일 때뿐입니다. 그 경우에도 다이얼로그는 출력하지 않고 작업을 일시적으로 멈춥니다. 그 후 AI가 준비한 명령어를 제가 제 터미널에서 실행하도록 안내합니다 (제2절 구분 A).
2. 멈추거나, 기록하여 통과시키기: 네 가지 구분
멈췄을 때의 문구를 AI에게 읽게 하려면, 그 전에 어떤 작업을 멈출지, 그리고 어떤 작업을 통과시킬지를 결정해 두어야 합니다.
문지기가 감시하는 것은 쓰기(write), 삭제(delete), 외부 전송(send out), Git 작업 등의 유형입니다. 이 유형에 해당한 작업을 다음 네 가지 구분으로 나눕니다. 구분은 위에서부터 순서대로 적용하며, 가장 먼저 해당하는 것으로 결정합니다. A와 B는 멈추고, C와 D는 통과시킵니다 (C는 임시 저장소(draft)가 확보되었을 때만. 사람이 보고 있지 않은 작업에서는 C와 D도 멈춥니다).
읽기 전용 작업처럼 어떤 유형에도 해당하지 않는 것은 기록 없이 그대로 통과시킵니다.
| 구분 | 질문 (위에서부터 순서대로 적용) | 처리 방식 |
|---|
| A 사람의 의지가 필요할 때 | 외부로 내보내면 취소할 수 있는가 (로컬 데이터를 외부로 전송/공개). 문지기 자체(설정·규칙·사용하는 부품)나, 문지기보다 먼저 작동하는 메커니즘(플러그인 등)의 위치를 건드리는가 | 멈춘다. AI가 준비한 명령어를 사람이 자신의 터미널에서 실행하도록 안내한다 |
| ... | | |
| A는 내가 직접 | | |
외부로 전송된 것은 취소할 수 없습니다. 문지기를 AI에게 수정하게 하면, 문지기를 둘 의미가 없어집니다. 그래서 이 두 가지는 제가 제 손으로 누르는 형태로 했습니다. 다만, 조사 검색처럼 로컬 데이터를 외부로 가져가지 않는 경우는 통과시킵니다.
A에서 저의 판단을 요청할 때는 AI에게 3줄로 작성하게 합니다. 무엇을 할 것인지, 실패하면 무슨 일이 일어날지, 나중에 되돌릴 수 있는지입니다. 여기에 권장 사항과 그 이유도 함께 적게 합니다.
그렇다고 해도, 권장 사항이 적혀 있으면 저는 내용을 읽지 않고 그대로 눌러버리는 경우가 있습니다. 우리 시스템이 추천하는 것이니까 틀리지 않을 거라는 마음으로요. 그래서, 읽지 않아도 고장 나지 않는 것을 권장 사항으로 삼고 있습니다.
B가 가장 효과적이다
B는 단순히 멈추기만 하는 것이 아닙니다. '이렇게 하면 같은 일을 안전하게 할 수 있습니다'라고 답변합니다. AI는 멈춘 후, 그 안내문을 읽고 다른 방법을 시도합니다.
안내하는 것은 문지기를 빠져나가는 방법이 아닙니다. 같은 용무를 안전하게 처리할 수 있는 다른 방식입니다. 안내에 따른 작업 역시 다시 한번 문지기를 통과합니다.
C는 '현재 되돌릴 수 있음'이 조건이다
C는, '되돌릴 수 있을 것 같다'로는 통과시키지 않습니다. '지금 되돌릴 수 있는 상태로 만들었다'는 것을 통과시키는 조건으로 삼습니다.
임시 저장소(draft)라고 해도 과장된 것은 아닙니다. 수정하기 전에 원본 파일을 임시 보관 폴더에 복사해 두는 정도입니다. Git으로 관리하는 파일이라면, 아직 기록하지 않은 변경 사항이 없다는 것만 확인되면, 이력이 그대로 임시 저장소가 됩니다.
사람이 보고 있지 않는 작업은, 멈추는 쪽으로
AI가 사람이 보지 않는 곳에서 작동하는 작업도 있습니다. 백그라운드에서 작동하는 서브 에이전트(sub-agent) 등입니다. 이런 작업에서는, 대화 중에라면 기록을 남겨 통과시키는 것 같은 작업이라도 멈추는 쪽으로 처리합니다. 구별에는 훅에 전달되는 정보에 포함된 agent_id라는 항목을 사용합니다.
그만큼 안전한데도 멈춰버리는 오탐지(誤検知)가 늘어납니다. 멈췄을 때는, 우선 AI에게 문지기 입장에서 봐도 안전하다고 알 수 있는 방식으로 수정하게 합니다. 기준을 완화하는 것은 최후의 수단입니다.
3. 멈춘 문구를 AI 안내로 만들기
멈췄을 때 AI에게 반환되는 문구는 형식이 정해져 있습니다.
- 무엇을 멈추었는지 (1줄)
- 왜 멈추었는지 (1~2줄)
- 대안적인 방법 (그대로 입력할 수 있는 형태)
예를 들어, 이런 작업을 멈춥니다
아래는 실제로 멈춘 기록 그 자체는 아닙니다. 문지기의 규칙을 이해하기 쉬운 예시로 대체한 것입니다.
⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.
파일을 일괄 등록하려 했을 때 (예: git add -A)
→ "직접 만든 파일을 지정하여 등록해 주세요"라고 안내합니다(B).
Git으로 관리하지 않는 파일을 삭제하려 했을 때
→ "삭제하는 대신, 임시 보관용 폴더로 옮기는 도구를 사용하세요"라고 안내합니다(B). 단순히 옮기는 것이라면 나중에 되돌릴 수 있습니다.
내용물을 확인할 수 없는 코드를 그 자리에서 파이프라인으로 실행하려 했을 때 (예: curl … | bash 형태)
→ "일단 파일에 작성한 후 실행해 주세요"라고 안내합니다(B). 파일로 작성하면, 입력 시 검사가 작동합니다.
로컬 데이터를 외부로 전송하려 했을 때
→ 제가 제 터미널에서 실행하는 형태로 안내합니다(A). 실행하기 전에 개인 정보가 포함되어 있지 않은지 검사도 거칩니다.
첫 번째 작업을 중단했을 때는 다음과 같은 문구가 반환됩니다. 이 문구는 설명 목적으로 재작성된 것입니다.
중지됨: 파일을 일괄 등록하는 작업.
이유: 다른 작업의 중간 변경 내용까지 함께 기록하기 때문입니다.
대신: 만든 파일을 지정하여 등록해 주세요 (예:
git add 記事.md
).
AI에 전달되는 메커니즘
이 문구가 AI에 전달되는 메커니즘은 공식 문서에 나와 있습니다.
같은 이유의 문구라도, ask로 반환하면 사람의 확인 화면으로 가고, deny로 반환하면 AI에게 전달됩니다. 저희는 그 확인 화면 자체가 도착하지 않는 경우가 있었습니다(1절).
문지기에게 전달되는 JSON에서 주요 항목만 추출하면 다음과 같은 형태가 됩니다. 공식 문서 예시와 동일한 형태로, 내용은 설명용입니다.
{"hook_event_name": "PreToolUse", "tool_name": "Bash", "tool_input": {"command": "git add -A"}}
중지할 때 반환되는 JSON은 공식 문서에 있는 다음 형태입니다. 문지기의 코드가 아니라, 이유의 문구도 설명용입니다.
{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
...
Claude Code는 이를 받아 작업을 중단하고, 이유의 문구를 AI에게 보여줍니다. 구분 B와 같이 중지 메시지가 안내 역할을 하고 있다면, AI는 그것을 읽고 사람을 부르지 않고 다음 단계를 진행할 수 있습니다. 그동안 저는 아무것도 누르지 않아도 됩니다.
4. 숫자로 보기
문지기와 대화 기록을 바탕으로 AI에게 계산을 요청했습니다.
대화 중에 문지기가 중단한 283회 중, AI는 제 발언을 기다리지 않고 스스로 다음 작업으로 진행하는 경우가 282회였습니다. 기간은 9월 11일부터 10월 24일까지의 약 6주간입니다.
또한, 10월 17일 밤부터 24일 밤까지의 약 1주일 동안 문지기가 중단한 것은 162회였습니다. 그중 절반에 가까운 78회가 대체 방법을 반환하는 구분 B였습니다.
두 숫자는 기간과 범위가 다릅니다. 283회는 대화 중에만 발생한 약 6주간의 기록이고, 162회는 비공개 작업까지 포함된 약 1주일간의 기록입니다. 기간이 다른 것은 기록 방식 때문이며, 범위가 다른 것은 세고 싶은 대상이 다르기 때문입니다(접었다 펼치기 안에 기재). 표에는 기간도 함께 적었습니다.
| 수치화한 내용 | 수 | 기간 |
|---|---|
| 대화 중에 중지된 직후, 제 발언을 거치지 않고 AI가 다음 작업으로 진행한 횟수 | 283회 중 282회 (구분 B는 227회 중 226회) | 2026년 9월 11일 ~ 10월 24일 (약 6주간) |
| ... | |
남은 1회
남은 1회는 AI가 다음 작업을 하기 전에 제 입력이 들어간 경우입니다. 중단된 직후, 완전히 동일한 작업을 반복한 경우는 단 한 번도 없었습니다.
다만, 세어낸 것은 '다음 단계로 진행'하는 시점까지입니다. 진행된 곳이 안내대로였는지, 다른 우회로를 찾고 있었는지, 잘 되었는지는 확인하지 못했습니다.
그렇다고 해도, 다음 작업 역시 다시 문지기를 거칩니다. 구분 A에 해당한 작업은 몇 번을 시도해도 중단됩니다(AI에게 실행시키지 않기로 결정).
오탐지는 셀 수 없습니다
오탐지의 횟수는 셀 수 없습니다. 기록에 남는 것은 '중단'과 '그 다음 작업'뿐이며, '중단한 것이 실수였는지'는 남아있지 않기 때문입니다.
게다가 B는 방법을 바꿔서 통과하도록 하는 구분입니다. 오탐지가 발생하더라도, 기록상으로는 '안내대로 수정하여 통과한' 경우와 구별할 수 없습니다.
- 진행 횟수: Claude Code의 대화 기록에서, 멈춘 직후에 'AI의 다음 조작'이었는지 '저의 발언'이었는지를 확인했습니다. 구분은 멈춘 문구에 포함된 구분의 이름으로 나누어 분류했습니다. 세부 내역은 B가 227회 중 226회, A가 20회 중 20회, 구분 이름이 들어가지 않은 멈춤 방식이 36회 중 36회입니다. 다음 조작이 사람에게 질문하는 도구(AskUserQuestion)였던 경우는 단 한 번도 없었습니다. 사람이 화면을 보고 있었는지 여부는 구별하지 않았습니다. 기간은 현재의 4개 구분으로 작동하기 시작한 9월 11일부터입니다. 서브 에이전트의 171회는 제가 개입할 수 없어 제외했습니다.
- 멈춘 횟수: 문지기가 멈춘 경우만 기록하는 것에서 계산했습니다. 이 기록은 10월 17일 밤부터 남아있기 때문에 약 일주일 분량입니다. 문지기의 테스트를 실행할 때마다 늘어나는 부분(31행)은 제외했습니다. 같은 기간을 대화 기록으로 세면 170회로, 거의 일치합니다.
- 통과한 횟수: 조작 후에 문지기에게 다시 판정을 받도록 하고, 한 줄씩 기록하는 것에서 같은 시간대의 분량을 세었습니다. 어느 유형에도 해당하지 않는 조작은 두 기록 어디에도 포함되지 않습니다. 따라서 '전체 조작 중 몇 퍼센트를 멈췄는지'는 산출할 수 없습니다.
- 멈춘 162회의 내역: B가 78회, A가 17회, 기타가 2회입니다. 나머지 65회는 사람이 보고 있지 않은 작업이었기 때문에 멈춘 것입니다(대화 중이라면 기록을 남기고 통과시키는 유형). A 중에서 12회는 기록에 구분의 이름이 들어가지 않는 멈춤 방식이었지만, 멈춘 대상에서 A로 계산했습니다. 대상은 제5절의 명부에 올라온 파일에 대한 쓰기 작업(규칙 본체나, 쓰기 대상을 특정할 수 없는 경우 포함)과, 문지기보다 먼저 작동하는 메커니즘을 배치하는 곳입니다.
- B의 비율: B 78회에는 백그라운드 작업 분량도 포함되어 있습니다. 같은 일주일 동안 대화 기록으로 대화 중인 것만 계산하면, 멈춘 81회 중 66회가 B였으며, 약 8할입니다. 6주간의 283회 중 227회(약 8할)와 거의 같습니다.
5. 잘되지 않은 점: 문지기의 명부에 구멍이 있었다
확인에 의존하는 대신, 문지기에게 맡긴다. 그렇게 되면, 문지기 자체를 믿어도 좋다는 근거가 필요합니다. 저희는 명부, 테스트, 실물 확인의 세 가지로 지탱하고 있습니다. 여기서는 그 근거에 구멍이 있었던 이야기를 씁니다.
문지기는 AI에게 재작성되면 끝입니다. 그래서, 재작성되면 곤란한 것을 'AI에 의한 재작성을 막는 명부'에 올리고, 구분 A로 멈추게 합니다. 올려놓은 것은 문지기의 파일이나 설정, 규칙 본체, 문지기가 내부에서 사용하는 작은 프로그램, 문지기보다 먼저 작동하는 메커니즘(플러그인 등)을 추가할 수 있는 공간입니다.
발생한 일
문지기가 내부에서 사용하는 프로그램 중 2개가 명부에 올라있지 않았습니다. 문지기는 이러한 부품들이 반환하는 답을 그대로 믿고 작동합니다. 즉, 그 부분을 재작성당하면, 문지기의 판정이 안에서 바뀌어 버리는 상태였습니다.
첫 번째는 2026년 10월에, 문지기를 만든 AI와는 다른 회사의 AI에게 감사를 시켰을 때 발견되었습니다. 같은 형태의 두 번째는 그 지적을 받고 재검토했을 때 발견되었습니다.
왜 발생했나
첫 번째는, 2026년 9월에 문지기를 현재 형태로 다시 만들 때 '명부 외로 괜찮다'고 AI가 수정 가능한 곳에 배치한 부품이었습니다. 명부에 올리려면, 수정할 때마다 제가 직접 작업해야 합니다. 그 수고를 줄이고 싶었기 때문입니다.
두 번째는, 그 후에 문지기가 새로 사용하기 시작한 부품이라 명부에 추가하는 것을 잊었습니다.
수고를 줄이기 위해, 문지기가 의존하는 부품을 명부 밖에 두면, 그곳이 구멍이 됩니다.
어떻게 고쳤나
두 가지를 명부에 추가했습니다. 명부를 수정하는 작업도 구분 A에 해당하므로, 교체는 제가 제 터미널에서 진행했습니다. 더불어, 문지기를 시작할 때, 다른 곳에 놓인 같은 이름의 부품을 불러오지 않도록 변경했습니다.
다만, 이 감사에서 가장 컸던 지적 사항에 대한 대응은 아직 진행 중입니다. 제6절에 쓸 '막히지 않은 경로' 중 하나입니다.
테스트와 실물 확인
명부 외에도, 문지기에는 테스트도 붙어있습니다. AI가 입력할 법한 조작을 JSON 형태로 문지기에 흘려보내, 멈출지 통과시킬지가 결정된 대로 되는지를 확인하는 것입니다. 실제 위험한 조작은 실행하지 않습니다.
테스트에는 다음 세 종류를 넣었습니다.
- 멈춰야 할 조작을 멈추는지
- 멈추면 안 될 일반적인 조작을 멈추지 않는지
- JSON 형태가 아닌, 깨진 입력을 멈추는지
건수는 2026년 10월 기준으로 1,179건입니다.
문지기를 수정할 때마다, 테스트를 모두 통과한 후에 교체합니다. 다만, 테스트를 통과했다고 해서 실제 환경에서 작동하는 것은 아닙니다. 그래서 교체한 후에 실제로 멈추는지, 기록이 남는지를 실물로 확인하고 있습니다.
6. 한계점과 유사 메커니즘과의 차이점
코드를 포함하지 않는 이유
게이트키퍼(門番) 중에는 제 환경에서만 의미가 있는 이름들이 많이 들어 있습니다. 이대로는 다른 사람의 환경에서는 작동하지 않습니다. 손을 대면 시험 전체를 다시 만들어야 합니다. 게이트키퍼는 각각 자신의 환경에 맞춰 만드는 것이라고 생각합니다.
완벽하지 않다
오탐지(誤検知)는 있습니다. 알고 있음에도 아직 막지 못한 경로도 몇 가지 남아있습니다 (내용은 적지 않습니다). 제가 생각해내지 못한 우회로도 분명 있을 것입니다.
게이트키퍼는 방어의 한 측면에 불과합니다. 그래서 백업도 따로 준비했습니다.
게다가 이것은 저 혼자만의 환경에서 돌려본 결과입니다. 어디서든 통용되는 정답으로 작성하고 있는 것은 아닙니다.
격리 상자는 사용하지 않았다
AI를 격리 상자(샌드박스, Sandbox) 안에서 구동하는 방법도 있습니다. 다만, Claude Code를 Windows 환경에서 그대로 사용할 경우 공식적인 상자는 작동하지 않고, 상자 없이 작동합니다. WSL2 내부에서는 사용할 수 있습니다 (공식 문서).
저희 게이트키퍼는 상자를 사용하지 않고 규칙만으로 막고 있습니다. 현재로서는 그것으로 곤란을 겪지 않습니다.
자동 모드 판별기와 결합하여 사용하기
Claude Code의 자동 모드에는 조작의 위험성을 AI가 판단하는 메커니즘(판별기, Detector)이 있습니다. 이 판별기가 보는 것은 일반적으로 위험하다고 여겨지는 조작입니다. 게이트키퍼가 담당하는 것은 저의 환경만의 규칙입니다. 개인정보를 외부로 유출하지 않도록 하거나, 게이트키퍼 자체를 수정당하지 않도록 하는 등의 것입니다.
유사 메커니즘과의 차이점
훅(Hook)을 이용해 위험한 명령어를 막는 글은 이미 여러 개 있습니다 (예: yamazaki 님의 글, kiyokuro 님의 글, ERENOA 님의 글). 중지시킨 이유를 AI에게 안내하는 방식 자체도 다른 글에 쓰여 있습니다.
2026년 10월, AI에게 검색을 요청하여 찾은 일본어 실습 기사 14개와 비교해 보았습니다. 그 위에서 이 글이 추가할 수 있다고 생각하는 것은 다음 세 가지입니다.
- 되돌릴 수 있는지 기계적으로 확인한 후에, 확인 절차 없이 통과시키는 구분(C)
- 막힌 이후에 AI가 스스로 다음 단계로 진행한 횟수를 기간을 정해 계산한 것 (283회 중 282회)
- 아예 확인 화면 자체가 도착하지 않았다는 것을 실제로 확인한 것
저는 엔지니어가 아니기 때문에, 무엇이 위험한지 저 자신은 잘 모릅니다. 그렇기에 무엇이 위험한지를 AI에게 생각하게 하는 방향으로 완전히 기울였다고 생각합니다.
이 글은 AI와 함께 작성했으며, 수치는 다른 AI에게 검산을 맡겼습니다.
7. 자신의 환경에서 게이트키퍼를 만들 경우, 이 순서로
이 게이트키퍼에서는 사람의 승인을 버튼을 누르는 순간부터 규칙을 정하는 단계까지 이동시켰습니다.
무엇이 위험한지는 AI에게 제시하게 하고, 막을지 말지에 대한 결정은 저(사람)가 내립니다. 그리고 그것을 코드로 만드는 것은 AI입니다. 점검은 다른 AI로 하고, 평소에는 다른 세션의 AI, 때로는 다른 회사의 AI에 의존합니다. 외부로 나갈 때 버튼을 누르는 것은 사람입니다.
저 자신은 코드를 작성하지 않았습니다. 정한 단어들을 Claude Code에게 작성하게 했습니다. 다시 만든다면, 저는 다음 순서대로 결정할 것입니다.
1~4는 대략 2절의 구분 A→B→C→D 순서입니다. 5와 6은 5절의 시험과 실물 확인에 해당합니다. '하지 않을 것'은 대부분 이 글에 적었던 실패 사례나 규칙에서 비롯되었습니다.
차단 명단을 결정하기 (A)
외부로 나가는 조작과 게이트키퍼 자체(2절 표의 A)를 넣습니다. 개인정보가 외부로 나갈 수 있는 길을 가장 먼저 막습니다. - 하지 않을 것: 수고를 덜기 위해, 게이트키퍼가 의존하는 부품을 명단 외부에 두는 것. 5절의 구멍은 여기서 생겼습니다.
차단했을 때 반환할 문구 규칙 만들기 (B)
무엇을 차단했는지, 왜 차단했는지, 대체 방법의 세 가지입니다. 대체 방법은 AI가 그대로 입력할 수 있는 형태로 작성합니다 (3절 예시). - 하지 않을 것: 차단 이유를 사람에게 읽힐 목적으로 쓰는 것. 읽는 것은 AI입니다.
'되돌릴 수 있음'을 기계로 확인하는 방법을 결정하기 (C)
임시 사본이 복사되었는지, Git에 아직 기록되지 않은 변경 사항이 없는지 여부입니다. 복사되지 않았다면 통과시키지 않고 B로 돌립니다. - 하지 않을 것: '되돌릴 수 있을 것이다'라는 가정으로 통과시키는 것. 망설일 때 확인 다이얼로그로 빠져나가는 것. 1절에서와 같이, 도착하지 않는 경우가 있습니다.
차단한 횟수와 통과시킨 횟수를 각각 한 줄씩 기록하기 (D)
4절의 차단 횟수와 통과 횟수는 이 두 가지 기록으로부터 도출됩니다. - 하지 않을 것: 차단했다고 생각하고 끝내는 것. 기록이 없으면, 지나쳤던 곳을 나중에 찾을 수 없습니다.
AI가 수행할 법한 작업을 테스트하기
하나의 작업을 JSON 하나로 만들고, 멈출지 통과시킬지에 대한 답과 조합합니다. 막아야 할 작업, 막으면 안 되는 일반적인 작업, 손상된 입력의 세 종류를 넣습니다.
- 하지 말 것: 테스트를 위해 실제 위험한 작업을 실행하는 것. JSON을 흘려보내는 것만으로 판정은 시도할 수 있습니다.
교체 후, 실물로 확인하기
실제로 멈추는지, 기록이 한 줄 늘어나는지 확인합니다.
- 하지 말 것: “배선을 했다 = 작동한다”라고 생각하는 것. 테스트를 통과했더라도 실제 환경에서 작동하고 있는 것은 아닐 수 있습니다. 마지막으로, 사람이 화면을 보고 있지 않은 작업(서브 에이전트 등)에서도 동일하게 진행해도 괜찮은지 다시 한번 생각합니다.
앞으로 만들 사람들에게
개인정보 유출을 막는 것을 무엇보다 먼저 해주세요.
문지기(Gatekeeper)를 단단하게 구축했기 때문에, 저는 AI에게 안심하고 작업을 맡길 수 있습니다.
Discussion
