「次からは気をつけて」が、いちばん弱い

AI에 일을 맡기고 있으면, 같은 장소에서 같은 실수를 하는 경우가 있다.

예전의 저는 규칙을 추가하고 있었다. “작업 전에 이 파일을 읽기”, “임의로 삭제하지 않기”, “확인한 후에 진행하기”. 설정 파일 안에 주의사항이 점점 늘어났다.

얼마 지나지 않아 깨달았다. 주의사항이 많아질수록, 지켜지는 비율은 떨어진다. 10개라면 읽을 수도 있지만, 50개가 있다면 매번 전부를 기억해내는 것은 무리다.

이는 체감상의 이야기만 아니다. 문맥으로 주어진 규칙을 LLM(대규모 언어 모델)이 얼마나 잘 지킬 수 있는지 측정한 SafePyramid라는 벤치마크(2026년 6월, 10모델 평가)에서는, **가장 성적이 좋았던 모델조차도, 깨진 규칙을 정확하게 지적할 수 있었던 것은 가장 쉬운 레벨에서 54.0%**에 그쳤다. 규칙 간의 의존 관계를 읽어야 하는 레벨에서는 35.3%, 새로운 방침의 틀에 적응해야 하는 레벨에서는 **12.9%**까지 떨어진다.

즉, 규칙이 늘어나고 복잡하게 얽힐수록, 문자로 작성한 제약은 효력을 잃는다. 제가 느꼈던 것은 착각이 아니었다.

그럼 어떻게 해야 할까. 여기서 저는 상당히 돌아가는 과정을 거쳤다. 결론부터 말하자면, 이 문제는 제조업이 50년 전에 해결했던 것이다.

工場の人たちは、とっくに答えを出していた

**포카요케(Poka-Yoke)**라는 말을 들어본 적이 있는가. 도요타 생산 방식(Toyota Production System) 안에서 확립된 품질 관리의 개념이다. “포카”(실수)를 “예방한다”는 의미다.

내용은 한마디로 말할 수 있다.

실수를 주의력에 의존하는 것이 아니라, 시스템으로 막는다.

주변에는 실제 사례가 얼마든지 있다.

USB Type-C 커넥터에는 상하 구분이 없다. 거꾸로 꽂으려고 할 수 없기 때문에 “방향을 확인하고 삽입해 주세요”라는 주의사항이 필요하지 않다 -
전자레인지는 문을 닫지 않으면 작동하지 않는다. “문을 닫고 운전해 주세요”라고 붙이는 대신, 닫혀 있지 않으면 전기가 통하지 않는 구조로 만들었다 -
ATM은 현금보다 카드를 먼저 반환한다. 현금을 받는 순간 사람은 목적을 달성했다고 생각하여 카드를 잊어버린다. 그래서 순서 자체를 바꾼 것

모두 공통적인 것은, 아무도 “조심해 주세요”라고 말하지 않았다는 점이다. 조심하지 않아도 틀릴 수 없는 형태로 만들어 놓은 것이다.

그리고 포카요케는 크게 2가지로 나뉜다. 이 부분이 나중에 중요하게 작용한다.

AIとの作業は、工場より「ポカヨケ寄り」にせざるを得ない

여기부터가 본론이다. 포카요케를 AI에 적용하면, 전제가 하나 틀어지게 된다.

포카요케가 상정했던 것은 인간 작업자였다. 사람은 지치고, 익숙해지고, 정신이 산만해진다. 그래서 주의력에 의존하지 않는 시스템이 필요하다는 이야기였다.

AI는 지치지 않는다. 그런데 더 골치 아픈 속성을 가지고 있다.

AI는 이전의 반성을 기억하지 못한다.

인간 직장이라면, 실패한 본인이 “저건 아팠다”라고 기억한다. 그래서 다음부터 조심하게 된다. 교육이 효과를 발휘한다. 실수 방지 교과서에 “작업자 교육/지도”라는 항목이 있는 것은 그것이 실제로 효과가 있기 때문이다.

AI와의 작업에서는, 대부분의 경우 대화가 끝나면 기억이 리셋된다. 다음에 같은 작업을 하는 AI는 그 실패를 경험하지 않은 타인이다. “조심해”라고 적어 놓아도, 그것을 읽는 사람은 아픈 일을 겪어본 사람이 아니다.

게다가, 기억할 수 있는 범위 자체에도 한계가 있다. Chroma가 2025년 7월에 공개한 Context Rot이라는 조사(18모델 평가)는, 입력이 길어질수록 모델의 신뢰성이 떨어진다는 것을 실측으로 보여주고 있다. 대화가 길어질수록 초반에 작성했던 규칙은 효력이 떨어져 간다.

요약하자면, 이렇게 된다.

인간 현장에서는 ‘교육’이라는 수단을 사용할 수 있다. AI와의 작업에서는 그것이 구조적으로 존재하지 않는다.

그러므로, 공장보다 한 단계 더 강하게 포카요케에 의존해야 한다.

強さを4段階で捉える

포카요케의 2가지 분류(경고형/제어형)는 그 자체로는 AI에게 다소 거칠다. 저는 4단계로 재분류하여 사용하고 있다.

아래로 갈수록 강력해진다. 그리고 아래로 갈수록 만들기 번거롭고, 유연성이 떨어진다.

AI를 대상으로 구체화하면 다음과 같다.

• 1단계 (종이): 설정 파일에 "~할 것"이라고 적는다. 읽히지 않으면 끝이다. -
• 2단계 (검사): 나중에 체크한다. 테스트를 실행하거나 로그를 본다. 위반되었다는 사실은 알 수 있지만, 위반하는 것 자체를 막을 수는 없다. -
• 3단계 (구조): 절차를 건너뛰려 하면 에러가 발생하며 멈춘다. 기계가 순서를 가지고 있다. -
• 4단계 (배제): 망가뜨릴 수 있는 경로가 존재하지 않는다. 읽기 전용(Read-only)으로만 열 수 있는 방식 등. -

USB Type-C는 4단계다. "방향을 확인하세요"라고 적는 것이 1단계, 잘못 끼웠을 때 램프가 켜지는 것이 2단계, 반대 방향으로는 들어가지 않는 형상으로 만드는 것이 3단계, 애초에 방향이라는 개념 자체를 없앤 것이 4단계이다.

4단계까지 끌어올린 실례 (사전 항목 27건이 사라진 이야기)

나는 Mac의 일본어 입력에 자주 사용하는 변환 패턴을 등록해 두고 있다. 음성 입력 시 매번 같은 오타가 발생하기 때문에, 그 조합을 사전에 넣어두는 작업이다.

이 작업을 AI에게 맡겼다. 사전의 내용은 TextReplacements.db라는 SQLite 파일이므로, 그곳에 직접 INSERT 하면 빠르다. 실제로도 빨랐다. 첫 번째 항목이 깔끔하게 등록되는 것을 보고 방식이 확립되었다고 판단하여, 나머지 27개 단어를 같은 방식으로 밀어 넣었다.

그리고 사전을 관리하는 상주 프로그램이 재시작되는 타이밍에, 27건이 통째로 사라졌다.

iCloud로 동기화되는 구조였기 때문에, 클라우드 측이 알지 못하는 행은 "출처를 알 수 없는 데이터"로서 일괄 삭제되는 방식이었던 것이다. 에러는 발생하지 않는다. 사라지기 전까지는 아무도 눈치챌 수 없다.

27건이 사라진 후, 내가 가장 먼저 취한 조치는 당연하게도 1단계——종이 주의사항이었다. Claude Code의 설정 파일에 다음과 같이 적었다.

데이터베이스에 직접 쓰지 말 것. 등록은 정규 절차(설정 화면으로 드래그 앤 드롭)만 사용할 것.

이것으로 안심해도 될까? 아니다. 이 문장이 읽히지 않는다면, 아무 일도 일어나지 않은 것과 마찬가지이기 때문이다. 게다가 다음에 이 작업을 수행할 AI는 27건이 사라졌을 때의 고통을 알지 못한다.

그래서 4단계로 올렸다. AI가 사전을 건드릴 때의 입구를, 내가 직접 작성한 등록용 프로그램 하나로 제한했다. 그 프로그램은 사전 파일을 "읽는(Read)" 것만 할 수 있다.

# 읽기 전용으로 연다. 쓰는 기능 자체가 존재하지 않는 상태로 만든다
conn = sqlite3.connect("file:%s?mode=ro" % db_path, uri=True)

mode=ro를 붙여서 연 연결은 INSERT를 던져도 SQLite에서 거부당한다. AI가 센수를 발휘해 쓰려고 시도해도, 쓸 수 있는 길이 그곳에 없다.

"읽기만 해서 어떻게 사전에 등록한다는 거지?"라고 생각할지도 모른다. 읽는 것은 이미 등록되어 있는지 확인하기 위한 용도일 뿐이다. 등록 자체는 프로그램이 만든 등록용 파일을 내가 설정 화면으로 드래그 앤 드롭하여 수행한다. 즉, Apple이 마련한 정규 입구이다. 손을 움직이는 것은 인간이지만, 그만큼 사라질 일은 없다.

단 한 줄이다. 하지만 이로써 "실수로 쓰는 일"은 일어날 수 없게 되었다. 금지한 것이 아니라, 할 수 없게 만든 것이다. 이 차이가 1단계와 4단계의 차이다.

그럼 전부 4단계로 만들면 되는가 (여기가 함정)

……는 아니다. 이 부분이 이번에 가장 고민했던 지점이다.

전부를 4단계로 만들면, 작업을 할 수 없게 된다.

AI를 이용한 태스크 수행에는 탐색하며 진행해야 하는 종류가 있다. "이 방향으로 써봐", "음, 이 말투가 더 나을지도 몰라"와 같은 상호작용이다. 여기에 "순서대로 하지 않으면 거부"를 넣어버리면 대화가 성립되지 않는다. 막다른 길투성이인 미로 속에서 대화하는 꼴이 된다.

비용 문제도 있다. 4단계 메커니즘을 하나 만드는 것은 주의사항 한 줄을 추가하는 것에 비해 수십 배의 수고가 든다. 모든 곳에 적용하다 보면 본래 하고 싶은 일을 할 시간이 없어진다.

즉 필요한 것은 "강력한 울타리를 만드는 기술"이 아니라, 어디에 울타리를 세울지 선택하는 판단이었다.

두 가지 질문

내가 사용하는 것은 이것뿐이다.

① 이 실수는 되돌릴 수 없는가? (사라짐·파손·외부 유출)

② 같은 작업을 앞으로도 반복할 것인가?

사용하는 상황은 두 가지다. 실패가 일어난 직후(교훈을 기록할 때)와, 같은 절차를 반복하는 메커니즘을 새로 만들 때. 둘 다 "울타리를 세울 것인가, 주의사항으로 끝낼 것인가"의 갈림길에 해당한다. 후반부에서는 이 질문을 전자의 작업에 강제적으로 매립하는 단계까지 진행한다.

그리고 중요한 점은, 둘 다 YES일 때만 울타리를 강화할지 고민한다는 것이다. 하나만 해당한다면 주의사항만으로 충분하다.

왜 "둘 다"인가?

• ①만 YES(되돌릴 수 없지만, 다시는 하지 않을 작업)라면, 메커니즘을 만드는 비용이 맞지 않는다. 만든 다음 날이면 불필요해진다.
• ②만 YES(매일 하지만, 실수해도 바로 고칠 수 있음)라면, 틀렸을 때 고치면 된다. 울타리가 오히려 방해가 된다.

되돌릴 수 없는 일을 앞으로도 반복해서 한다. 이 교차점만이 정말 위험한 곳이다.

기억하는 방식은 다음과 같다.

아픈 곳에만 울타리를 세운다. 울타리를 세운다면, 게시판이 아니라 열쇠(Lock)로 만들 수 없는지 한 번은 자문한다.

여기서부터가 본론: 질문을 "잊지 않게 만드는" 메커니즘

자, 여기까지가 사고방식에 대한 이야기다. 문제는 사고방식을 떠올릴 수 있느냐이다.

나는 실패의 교훈을 하나의 파일에 한 줄씩 쌓아두고 있다. 표 형태로 되어 있으며, 다음과 같은 모양이다.

| 날짜 | 사고·착오 | 규칙 | 상세 설명 | 재발 기록 |
|---|---|---|---|---|
| 2026-07-11 | 사전 DB에 직접 INSERT한 27건이 상주 프로세스 재시작 시 사라짐 | 시스템 DB에 직접 쓰지 않는다. 공식 수집 경로를 사용한다 | 메모리의 해당 항목 | -

벌써 20건 이상 쌓였다. 그런데 이 운용에는 조용한 결함이 있었다.

실패가 발생한다 → 교훈을 한 줄 적는다 → 만족하며 끝낸다.

이것은 자세히 보면 1단계(종이)를 한 장 늘리고 있을 뿐이다. 게다가 실패가 일어난 직후라는 시점은 "이것을 애초에 일어나지 않게 만들 수 없을까?"를 고민하기에 가장 적절한 순간이다. 재료가 모두 갖춰져 있고 고통도 생생하다. 그 최고의 타이밍을 매번 한 줄 적고 그냥 지나쳐 버리고 있었다.

그렇다면 설정 파일에 "교훈을 적을 때는 울타리를 높일 수 없는지 고민할 것"이라고 덧붙이면 될까? ……알다시피, 그것 또한 1단계일 뿐이다. 똑같은 함정에 빠지는 것이다.

그래서, 교훈을 적는 작업 그 자체를 질문을 거치지 않으면 끝낼 수 없는 구조로 만들었다.

이하, 실제 화면을 첨부한다 (사내 고유명사는 일반적인 단어로 대체했다).

만드는 법 그 첫 번째: 절차를 프로그램에 담기

"한 줄 덧붙이기"였던 작업을 6개의 단계로 분해했다.

1. start … 무엇이 일어났는지 전달
2. judge … ★2가지 질문에 답하기★
3. escalate … 둘 다 YES라면, 울타리를 높이는 안을 제시
...

포인트는 이 순서를 AI에게 가르쳐주지 않았다는 점이다. AI가 가진 것은 "먼저 start를 실행한다"뿐이다. 다음에 무엇을 할지는 프로그램이 실행될 때마다 알려준다.

먼저 현재 위치를 물으면 다음과 같이 답한다.

$ report_incident.py status
진행 상황: STEP0 / 6 까지 완료
다음에 실행 가능한 것은 STEP1 (start)입니다.

여기서 갑자기 5번째(덧붙이기)를 실행하려고 하면 다음과 같이 된다.

$ report_incident.py append
✗ STEP5 (append)는 지금 실행할 수 없습니다. 완료된 것은 STEP0 까지입니다.
다음에 실행 가능한 것은 STEP1 (start)입니다.

진행 상황은 작은 JSON 파일에 기록되어 있으며, 건너뛰기를 거부하는 판정은 다음과 같다.

def allow_transition(state_step, requested_step):
    """허용하는 것은 '다음 단계'와 '현재 단계의 재실행'뿐.
    과거 단계의 직접적인 덮어쓰기는 후속 전제가 조용히 무너지기 때문에 허용하지 않는다.
    ..."""

그럼 순서대로 시작해 보자. 실패 내용을 JSON 파일에 적어서 전달한다 (인자로 긴 문장을 전달하면 기호 처리 문제로 사고가 날 수 있어 피하고 있다).

$ report_incident.py start --section file --from-file incident.json
✓ STEP1（start）완료
섹션: file（파일 조작·진행 전에）
...

프로그램 쪽에서 질문이 날아온다. 이것이 내가 만들고 싶었던 것이다. AI는 스스로 순서를 정하지 않으며, 정할 수도 없다. 지휘자가 악보를 가지고 있고, 연주자는 다음 마디만을 알고 있는 형태가 된다.

두 가지 질문에 답하면 판정이 돌아온다.

$ report_incident.py judge --irreversible yes --repeated yes --from-file judge.json
✓ STEP2（judge）완료
→ 둘 다 YES. **제약(fence)의 승격을 검토할 대상**입니다.
...

여기서 "귀찮으니까 건너뛰자"라고 하면 멈춘다.

$ report_incident.py escalate --skip
✗ 2개 질문 판정이 모두 YES이므로 `--skip`을 할 수 없습니다.
승격안(current/target/means) 또는 `cannot`(올릴 수 없는 이유)를
...

이 화면 하나가 이 메커니즘의 전부라고 해도 과언이 아니다. "실패하면 교훈을 한 줄 적는다"로 끝났던 작업에, "그래서, 한 단계 더 강하게 만들 수 없어?"라는 질문이 물리적으로 끼어든다.

또한, "올릴 수 없다"도 정답으로 수용하도록 했다. 다만 이유 기입은 필수 사항으로 만들었다.

MIN_CANNOT = 20 # 「올릴 수 없다」는 정답이지만, 이유 없이는 통과시키지 않음

억지로 대책을 짜내게 만들면 의미 없는 시스템이 양산된다. "이번에는 올릴 수 없다, 왜냐하면 ~"라고 쓸 수 있다면, 그것은 고민했다는 증거이므로 통과시켜도 좋다.

승격안을 작성하여 전달하면 다음으로 진행된다.

$ report_incident.py escalate --from-file escalation.json
✓ STEP3（escalate）완료
승격안: 1단계 → 3단계／수단: 생성물의 파일에는 편집을 거부하는 파수꾼을 배치하고,
...

그리고 네 번째 단계는, 인간에게 물어보기 전까지 진행할 수 없다. 승인 신호 없이 실행하면 거부됨과 동시에 "무엇을 물어봐야 하는지"가 전부 나타난다.

$ report_incident.py approve
✗ `--yes`가 필요합니다 (승인을 얻은 후 실행해 주세요).
--- 제시 내용 ---
...

판단에 필요한 재료가 한 화면에 모여 있다. 인간의 일은 "이대로 괜찮은가"를 답하는 것뿐이 된다.

만드는 법 그 두 번째: 우회로를 막기

여기서 큰 문제가 있다.

이렇게 번거로운 6단계를 준비해도, 파일을 직접 열어 한 줄 적으면 끝나버린다. 내가 만든 문 옆에 담장 없는 빈터가 펼쳐져 있는 상태다. 급할 때, AI는 (그리고 나도) 확실히 그쪽으로 통한다.

3단계의 제약은 우회로를 막아야 비로소 3단계가 된다. 막지 않는다면 번거로운 1단계에 불과하다.

그래서 직접 편집하는 경로 쪽을 막았다.

Claude Code에는 hook이라는 메커니즘이 있다. 파일을 편집하기 직전 등, 정해진 타이밍에 자신의 스크립트를 끼워 넣을 수 있는 것이다. 끼워 넣은 스크립트가 "안 됨"이라고 반환하면, 그 편집은 실행되지 않는다.

판정은 이것뿐이다.

def decide_hook(stdin_text, now=None):
    payload = json.loads(stdin_text)
    # 파일 편집 이외에는 그대로 통과
    ...

대상이 아닌 파일이라면, 다음과 같이 반환되어 아무 일 없이 통과한다.

{"hookSpecificOutput": {"hookEventName": "PreToolUse", "permissionDecision": "allow"}}

대상 파일을 직접 편집하려고 하면, 다음과 같이 반환되어 편집이 실행되지 않는다.

{
"hookSpecificOutput": {
"hookEventName": "PreToolUse",
...

거부할 때 중요한 것은, 이유와 대안을 세트로 반환하는 것이다. "안 됩니다"라고만 반환하면, AI는 다른 우회로를 찾기 시작한다 (악의가 아니라, 부탁받은 일을 완수하려다 보니 그렇게 되는 것이다). 목적지를 적어두면, 그쪽으로 걸어가 줄 것이다.

그리고 구현 과정에서 한 번 막혔던 점이 있습니다. 거절 이유를 AI에게 읽히고 싶다면, 반환되는 JSON 내의 AI에게 전달되는 필드에 작성해야 합니다. 인간의 화면에만 보이는 필드에 작성하면, AI는 이유를 모른 채 똑같은 행동을 반복합니다.

또 하나는 성능 문제입니다. 이 판정은 모든 파일 편집 시 실행되므로, 무거운 처리를 매번 돌리면 체감 속도가 느려집니다. 저는 이전에 비슷한 메커니즘을 이 문제 때문에 한 번 버린 적이 있습니다. 이번에는 대상 외 파일은 셸(Shell)의 표준 기능만으로 즉시 걸러내고, 대상일 때만 Python을 실행하도록 했습니다. 대상이 아니라면 1자리 밀리초(ms) 내에 종료됩니다.

만드는 법 그 세 번째: 탈출구를 만든다 (이것이 없으면 운영이 망한다)

완전히 막아버리면 사실 곤란한 상황이 생깁니다.

저는 한 달에 한 번, 이 교훈(Lesson) 파일을 정리합니다. 오래된 행을 지우거나, 비슷한 내용을 합치기도 합니다. 이 작업에는 대량의 편집이 필요합니다. 한 줄씩 6단계를 거치고 있다면 해가 저물 것입니다.

그래서 시간 제한이 있는 열쇠를 준비했습니다.

# 15분 동안만 열기 (이유 기록 필수)
$ report_incident.py unlock --yes --reason "월간 정리"
# 끝나면 닫기
...

15분이 지나면, 닫는 것을 잊더라도 자동으로 닫힙니다. 열었던 이유는 파일에 남습니다.

이것은 '보안 구멍'이 아니라, 설계의 필수 부품이라고 생각합니다. 탈출구가 없는 메커니즘은 결국 통째로 무효화됩니다. 실제 운영에서 방해가 되는 메커니즘은 제거되거나 우회되는 것 중 하나입니다. 탈착 가능하게 만들어 두는 것이 살아남는 조건이 됩니다.

그리고 탈출구가 있기 때문에, 감시자(Gatekeeper) 쪽은 엄격한 쪽으로 기울 수 있습니다.

판정 스크립트 자체가 고장 났을 때, 통과시킬 것인가 거절할 것인가. 일반적으로는 '망설여지면 통과시킨다'가 안전하다고 여겨집니다 (메커니즘의 버그로 작업 전체가 멈추는 것은 본말전도이기 때문입니다). 하지만 여기서는 거절하는 쪽으로 기울였습니다. 이유는, 말없이 사라지는 문은 문이 아니기 때문입니다. 고장 난 것을 인지하지 못한 채 몇 달간 운영하는 것이 더 무섭습니다. 열고 싶을 때는 위의 열쇠를 사용하면 된다는 탈출구가 먼저 마련되어 있기에, 이런 판단을 내릴 수 있습니다.

실제로 한 건 통과시켜 보았다

만든 당일에 딱 적절한 실패를 경험했습니다.

설정 파일 중에 특수한 방식으로 작성된 부분이 있습니다. 편집 도구를 통해 수정했더니, 그 특수한 방식이 일반 문자로 변환되어 버렸습니다. 게다가 에러는 발생하지 않았습니다. 겉보기에는 성공한 것처럼 보였습니다. 메커니즘의 일부가 조용히 무효화될 뻔한 것입니다.

이를 소재로, 방금 만든 6단계를 적용해 보았습니다. 두 가지 질문에 대한 답은 다음과 같았습니다.

• ① 되돌릴 수 없는가 → NO (알아차리고 고칠 수 있었다. 사라진 것은 없다)
• ② 반복되는가 → YES (이런 종류의 파일은 앞으로도 계속 만질 것이다)

한쪽이 NO이므로, 울타리(Fence) 승격은 검토하지 않고 통과했습니다.

솔직히 이 부분이 가장 안심되는 지점입니다. 만약 무엇이든 간에

모든 곳에 울타리를 세울 필요는 없다. 오히려, 세워서는 안 된다.

공장의 포카요케 (Poka-yoke, 실수 방지)가 가르쳐 주는 것은, 모든 공정에 지그 (Jig, 보조 도구)를 설치한 공장은 돌아가지 않는다는 사실이다. 설치해야 할 곳은, 실수를 했을 때 제품이 파손되는 공정에만 있으면 된다.

AI와의 작업도 마찬가지였다. 빠르게 달려야 할 상대에게, 달릴 수 없을 정도로 고삐를 죄는 것은 의미가 없다. 죄어야 할 곳은, 절벽 근처만 있으면 된다.

참고

• SafePyramid: A Hierarchical Benchmark for In-context Policy Guardrailing (2026년 6월) — 문맥(Context)으로 제공된 방침을 LLM이 얼마나 잘 준수하는지를 측정하는 벤치마크
• Context Rot: How Increasing Input Tokens Impacts LLM Performance (Chroma · 2025년 7월) — 입력 토큰이 길어질수록 신뢰성이 저하되는 현상에 대한 실측

Discussion