Claude Code의 trigger 리스트를 11일간 육성한 기록——8건의 사고와 AI 거버넌스 (AI Governance) 실증

22일간・19건의 인시던트 (Incident)를 기록하며 알게 된 것은, "AI는 자신의 독단을 실시간으로 자기 인식할 수 없다"라는 한 점으로 집약된다. 외부 체크리스트 (trigger 리스트)를 8건의 사고로부터 육성하여, "설계한 규칙이 다음 날 기능했다"라는 첫 순간을 실증한 22일간의 기록.

인시던트 기록 시작으로부터 22일이 지났다

전작 기사(CLAUDE.md에 「헌법」과 「trigger 리스트」를 쓴 이유, 2026-05-02 공개)에서는, AUTO_SYNC_ZENN=true의 독단적인 디폴트(Default)화로 인해 Zenn 기사 5개가 일시적으로 unpublish 상태가 된 사고를 바탕으로, 5개 항목의 trigger 리스트를 설계했음을 기술했다.

제1 인시던트(2026-04-23)로부터의 기록 기간은 22일간(2026-04-23~2026-05-15, 실측: 22일간)이 지났다. trigger 리스트는 5개 항목에서 8개 항목으로 늘어났다. 인시던트는 19건을 기록했다. 그리고 "육성한 규칙이 다음 날 기능했다"라는, 처음으로 보람을 느낀 순간을 기록할 수 있었다.

이 기사에서는 전반부 8건(2026-04-23~2026-05-03)을 상세히 다루고, 후반부 11건을 효과 검증으로서 일괄 분석하는 구성을 취한다. 후반부 11건은 "8건으로 육성한 trigger 리스트가 어디를 포착하고, 어디를 놓쳤는가"를 실증하는 데이터로서 기능한다.

자주 묻는 질문에 대한 선제적 답변: "전작과 무엇이 다른가?" 전작은 "5개 항목의 trigger 리스트를 설계한 이야기"였다. 본 기사는 "설계 후 8건의 사고를 거치며 trigger 리스트가 어떻게 개정되었는가"에 대한 지속적인 기록이며, 후반부 11건에 대해 어디서 기능했고 어디서 포착하지 못했는지에 대한 실증 분석이다.

Claude Code 8건의 인시던트를 시계열로 심층 분석하기

2026-04-23부터 2026-05-03까지는 11일간(양 끝 포함 실일수, 단순 차이는 10일)이다. 이 11일간이 현재 trigger 리스트의 골격을 형성했다.

#1(04-23): AUTO_SYNC_ZENN의 독단적인 디폴트화——"승인권은 사용자에게 있다"가 기능하지 않았다

첫 번째 사고가 전작에서 상세히 다룬 내용이다 (출처: logs/governance-incidents/2026-04-23_auto-sync-zenn-default.md). AUTO_SYNC_ZENN=true를 에이전트(Agent)가 사전 승인 없이 디폴트로 활성화하여, Zenn 기사 5개가 일시적으로 unpublish 상태가 되었다.

당시 CLAUDE.md에는 "승인권은 사용자에게 있다"라는 기술이 있었다. 하지만 "무엇을 사전 확인해야 하는가"는 명문화되어 있지 않았다. trigger 조건이 없다면, 에이전트는 자신의 판단으로 "이것은 승인이 불필요하다"라고 평가한다. "이것은 괜찮겠지"라고 치우칠 때 독단이 발동한다. 8건 중 "독단 판단" 카테고리로 분류되는 것은 2건(25%)이며, 나머지는 플레이북 (Playbook) 미정비, 사실 확인 프로세스의 결여, 규칙 망각, AI가 추측으로 공백을 메운 것이라는 구조적 요인이 원인이었다.

이 사고로부터 첫 번째 trigger 리스트가 탄생했다. "디폴트 값 변경으로 동작의 on/off를 전환한다"——사용자가 "OK"라고 응답할 때까지 실행하지 않는다, 라는 첫 번째 항목이다.

#2(04-24): 리뷰어(Reviewer)의 지적을 사실 확인 없이 전달——테스트가 우연히 불일치를 포착했다

GTD 도구의 코드 리뷰(Code Review)에서, 리뷰어가 라벨 상수의 불일치를 지적했다. COO는 1차 소스를 확인하지 않고, 지적 내용대로 skill-dev에게 수정을 위임했다 (출처: logs/governance-incidents/2026-04-24_reviewer-factcheck-miss.md).

리뷰어의 지적이 사실과 반대였다. 수정 전의 소스는 처음부터 일치하고 있었다. skill-dev가 지적 내용대로 변경함으로써 진정한 불일치가 발생했다.

이 사고의 구원은 같은 날 정비한 직후의 유닛 테스트 (Unit Test, T-1)가 기능했다는 점이다. T-1은 engine과 web의 상수 일치를 감시하기 위해 정비된 테스트로, 이번에는 "리뷰어의 오지적으로 인한 불일치"라는 예상치 못한 발생원을 검지했다. 상수의 이중 관리를 감시하기 위해 설계된 테스트가 의도대로 불일치를 포착했다. 발견자: AI (유닛 테스트 T-1).

이 사고로부터 coo-rules.md 체크포인트 3이 탄생했다. "상수·문자열 리터럴 등의 불일치 지적은 반드시 grep/Read로 소스를 직접 확인한 후 대응한다"——리뷰어의 지적을 검증 없이 전달하는 것을 금지하는 규칙이다.

#3（05-02）: 크로스포스트 (Crosspost) Playbook 미참조——현재 디렉토리가 발상을 봉쇄했다

2026-05-02, Hatena 기사의 Zenn 크로스포스트를 의뢰받았을 때, ops/playbooks/article/crosspost.md를 참조하지 않고 수동으로 Zenn 파일을 생성했다 (출처: logs/governance-incidents/2026-05-02_crosspost-playbook-skip.md). 크로스포스트 푸터(Footer) 미추가, crosspost_at 기입 누락, article-state.sh를 통한 상태 업데이트 미실시라는 3단계 과정이 누락되었다.

인시던트 파일에는 "현재 디렉토리가 zenn-content였기 때문에, 000.파트너 하위에 Playbook이 존재한다는 발상이 떠오르지 않았다"라고 기록되어 있다. 에이전트의 시야는 현재의 컨텍스트 (Context)에 끌려간다. 이 사고 유형은 CLAUDE.md에 Playbook 참조 규정을 제정한 후에도 동일한 패턴으로 반복된다——절차서가 있어도, 현재 디렉토리가 다른 리포지토리에 있는 상태에서는 떠올리기 어렵다. 발견자: 사용자 (결과물 확인 시). "모든 공정을 매번 검수"하는 것이 아니라 "공개 직전의 원터치 확인"이 최종 안전밸브로서 기능하는 패턴이다.

#4（05-02）: Fact-check가 과거 버전을 인용——수정을 위해 Read한 순간 깨달았다

같은 날 (2026-05-02). 공개된 기사의 Fact-check 리뷰 결과물이 "🔴필수 수정 1건 잔존"이라고 지적했다. COO는 현재 기사와 대조하지 않고, 인수인계 자료에 "공개된 기사에 필수 수정 사항이 남아 있음"이라고 적어 사용자에게 상신했다 (출처: logs/governance-incidents/2026-05-02_factcheck-stale-version-miss.md).

사용자가 대응 방안 A를 선택한 후, 수정 사항을 특정하기 위해 기사를 Read한 순간, 이미 올바른 기술로 수정되어 있다는 것을 깨달았다. Fact-check가 과거 버전을 인용하고 있었던 것이다. 발견자: AI (COO 자신)——"수정을 실시하기 위해 기사를 열었다"라는 별도의 목적을 가진 행동이 사실 오인을 우연히 발견하게 했다. 이 사고를 통해 coo-rules.md 체크포인트 3의 적용 범위가 "위임하기 직전"에서 "위임 또는 사용자 상신 직전"으로 확대되었다——다음 날 #8에서 기능하게 될 복선이다.

#5（05-02）: /todo subcommand 오용——"list" 타이틀의 쓰레기 Issue가 생성됨

같은 날 세 번째 사고 (출처: logs/governance-incidents/2026-05-02_todo-subcommand-misuse.md). COO가 bash ~/.claude/todo.sh project list를 실행했다. /todo의 인자 (Argument) 구조는 "제1인자=GTD 라벨, 제2인자 이후=타이틀"이며, list가 타이틀로 해석되어 Issue #1314가 잘못 생성되었다. 실질적인 피해는 없었으나, #3, #4, #5는 하루에 집중되었다. 공통된 구조는 "익숙하다고 생각하여 확인을 생략했다"——이러한 "작은 요령 피우기"는 자신의 운용 환경에서도 일어나고 있을 것이다. "알고 있을 것"이라는 전제가 확인 단계를 건너뛰게 만드는 유형이다.

#6（05-03）: Bash 내에 Grep/Read를 작성——에러가 즉시 알려주었다

다음 날 아침 (2026-05-03), COO가 인수인계 자료의 커밋 실패를 조사하던 중, Bash 도구의 command 파라미터 내에 Grep -n "handoff" ...와 Read ...를 포함하여 실행했다 (출처: logs/governance-incidents/2026-05-03_ceo-bash-internal-tool-misuse.md). Bash 내에서는 Read: command not found 에러가 반환되어 즉시 발각되었으며, 실질적인 피해는 없었다. 발견자: AI (에러에 의한 즉시 감지)——에러가 발생하지 않았다면 규칙 위반은 계속되었을 것이다. "여러 조작을 &&로 묶으려 한 순간, 수단 선택의 판단이 느슨해졌다"라고 인시던트 파일에 기록되어 있다.

#7（05-03）: Hatena 신규 기사에서 타이틀이 "■"로 글자 깨짐——Playbook에 절차가 없었다

같은 날, Zenn Book 회고 기사를 Hatena Blog에 신규 공개했을 때, 제목이 「■」로 글자가 깨진 채(mojibake) 공개되었다 (출처: logs/governance-incidents/2026-05-03_hatena-publish-encoding.md).

근본 원인은 「Playbook에 신규 기사 공개 플로우가 존재하지 않았다」는 것이다. 즉흥적으로 Python3를 사용하여 임시 파일을 생성했으나, Windows 환경의 기본 인코딩(cp932)으로 파일이 작성되어 제목이 「■」로 글자가 깨졌다. 발견자: 사용자 (공개 후 기사 확인). #3과 구조가 동일하며 「Playbook에 절차가 없음 → 즉흥적으로 대처 → 환경 특유의 함정에 빠짐」의 3단계 구조다. 대책으로 Playbook에 「신규 기사의 경우」 섹션을 신설하고, Write 도구 사용을 명기했다.

#8（05-03）: researcher가 GA4 데이터를 착오함——다음 날의 규칙이 기능한 첫 실증

본 기사의 결론이 되는 사례다 (출처: logs/governance-incidents/2026-05-03_researcher-url-mismatch.md).

COO가 researcher에게 「Hatena Blog의 PV가 늘지 않는다」는 상담에 대한 단일 PV 분석을 위임했다. researcher는 GA4에서 /entry/claude-todo-gtd-guide를 쿼리하여 row_count=0을 확인한 후, 「날짜가 일치하므로 /entry/2026/04/27/215349 (PV=18)가 해당 기사의 실제 URL일 가능성이 높다」고 추측하여 리포트에 기재했다.

COO가 사용자에게 보고할 자료를 준비하기 직전, coo-rules.md 체크포인트 3 「사용자 보고 직전의 1차 확인」에 따라 WebFetch로 직접 검증했다. 결과: /entry/2026/04/27/215349는 **별개의 기사 「9마리의 AI 에이전트와 전자책을 2일 만에 만든 이야기」**였다. 잘못된 정보의 보고는 미연에 방지되었다.

발견자: AI (COO 자신) —— **「우연」이 아니라 「의도적으로 설계한 규칙이 기능했다」**는 첫 사례다. 체크포인트 3은 전날(2026-05-02)의 #4에서 배워 coo-rules.md에 기록한 규칙이다. 규칙 작성으로부터 불과 하루 만에, 또 다른 사고 유형으로 실효성이 증명되었다.

사고를 기록한다 → 사고 유형을 규칙으로 변환한다 → 그 규칙이 다음의 동일 유형 리스크를 감지한다 —— 이 변환 사이클이 실제로 돌아간 것은 8건 중 이 1건뿐이다.

AI 거버넌스 (AI Governance)의 본질: 8건의 발견자 분석을 통해 알 수 있는 것

8건의 발견자를 정리한다 (출처: 각 인시던트 파일 본문).

#	인시던트	발견자
1	AUTO_SYNC_ZENN 독단	불명 (소급 기록이므로)
...
집계: AI 발견 4건 (#2·#4·#6·#8) / 사용자 발견 2건 (#3·#7) / 불명 2건 (#1·#5)

AI 발견 4건을 구조로 분류하면:

의도적 설계가 기능: #8 (1건뿐)
우연한 부차적 감지: #2 (T-1), #4 (별도 작업 중 인지), #6 (에러 자동 감지)

「의도적으로 설계한 메커니즘이 기능했다」고 말할 수 있는 것은 8건 중 1건이다. 그리고 「자신이 지금 독단을 범하고 있다」고 AI가 실시간으로 자기 인식한 사례는 제로다 (출처: 각 인시던트 파일의 「원인」 섹션).

trigger 리스트를 「육성하는」 것의 본질은 여기에 있다. AI가 자기 인식할 수 없는 사각지대를 외부 체크리스트로 계속 채워 나가는 작업이다. 사고 유형을 1건 추가할 때마다 그물망이 하나씩 넓어진다. #8은 「넓힌 그물이 실제로 기능했다」는 첫 실증이었다.

효과 검증: Claude Code 8건 이후의 11건은 무엇을 포착하고 무엇을 놓쳤는가

2026-05-03 이후의 11건 (#9~#19)을 목록으로 보여주기 전에, 이 11건에서 보인 두 가지 발견을 먼저 제시한다.

발견 1: blogsync가 3회 반복되었다 (#11·#15·#19) —— 1회차만으로는 적용 범위를 정확하게 정할 수 없었다.

발견 2: 2026-05-14에 4건이 집중 발생했다 —— 주의 비용이 높은 작업 이후에 다른 확인 작업이 저하될 가능성이 있다.

#	날짜	사고 개요	발견자	trigger 리스트에 미치는 영향
9	05-03	COO가 Playbook을 참조하지 않고 직접 소재 노트(ネタ帳) 작성	사용자	위임표에 소재 노트 작성을 명시
...

발견 1: blogsync가 3회 반복되었다

#11(05-04), #15(05-14), #19(05-15)는 동일한 근본 원인에서 발생한 3연발이다.

#11에서는 blogsync push를 직접 실행하여 4개 기사의 커스텀 URL이 이중 경로(double path) 형식으로 변경되어 404 오류가 발생했다. 대책으로 '외부 CLI 직접 실행' trigger를 추가했다. #15에서는 COO가 cd를 사용한 blogsync pull이 원인이 되어 저녁 시간대 기사 URL 변경이 일어났다. "pull은 읽기 작업이며 부작용(side effect)이 없다"는 인식이 잘못된 것이었다. #19에서는 기존 래퍼 스크립트(wrapper script)를 통해서도 동일한 유형의 사고가 재발했다.

3번 반복하고 나서야 trigger 리스트의 기술 내용이 "래퍼를 경유한 실행도 사전 승인 대상에서 제외하지 않는다"로 격상되었다. 첫 번째 사고만으로는 적용 범위를 정확하게 정할 수 없었다.

자주 묻는 질문에 대한 사전 답변: "trigger 리스트를 늘리면 AI가 멈추지 않을까?" blogsync의 사례가 답이 된다. 처음부터 "래퍼 경유도 금지"라고 적었다면 과잉 규제가 되었을 가능성이 있다. 3번의 재발을 통해 적용 범위가 단계적으로 넓어졌다. "동일 유형의 사고가 반복될 때, 적용 범위를 한 단계 넓힌다"는 운용 방식이 과잉 규제와 과소 규제의 균형을 유지한다.

발견 2: 2026-05-14에 4건이 집중 발생했다

#15, #16, #17, #18의 4가지 서로 다른 유형이 같은 날에 일어났다. COO의 cd 위반, handoff 미확인, 집계 뷰 근거의 잘못된 draft 작성, 품질 게이트(quality gate) Playbook 미확인이다. 각 인시던트(incident) 파일에 연쇄 작용에 대한 기술은 없으나, "주의 비용이 높은 작업 후에 다른 확인 작업이 저하되는" 패턴일 가능성이 있다(필자의 의견).

8건에서 8개 항목으로——AI 거버넌스 (AI Governance) trigger 리스트의 변천

전작 시점의 5개 항목에서, 19건을 거쳐 8개 항목이 된 현재의 trigger 리스트 증가분을 보여준다. 증가분 3건은 CLAUDE.md §가치관 거버넌스(value governance)에 추가되었고, 1건은 coo-rules.md §체크포인트 1에 추가되었다 (출처: 두 파일의 현재 버전).

추가 시기	추가 내용	반영처	기점 사고
05-04 이후	기존 스크립트를 경유하지 않는 외부 CLI 직접 실행 (blogsync / gh 등)	CLAUDE.md §가치관 거버넌스	#11 (blogsync push URL 변경)
...	coo-rules.md §체크포인트 1		#17 (crosspost stale status overwrite)
05-15 이후	hatena-publish.sh 등의 blogsync를 호출하는 래퍼 실행도 사전 승인 대상	CLAUDE.md §가치관 거버넌스	#19 (래퍼 경유 시에도 재발)

전작 시점의 5개 항목(기본값 변경, 불특정 다수 일괄 조작, 자동 실행 등록, 안전장치 바이패스, 연속 5개 커밋 초과)은 골격으로 남고, 실제 사고로부터 귀납된 3건이 CLAUDE.md에, 1건이 coo-rules.md에 추가된 구조다.

trigger 리스트를 늘리면 AI가 움직이지 못하게 될까? —— 단계적 확장을 통해 과잉 규제를 방지하다

"AI의 확인 대기 시간이 너무 늘어나서 운용이 멈추지 않을까"라는 우려는 현실적이다. blogsync의 3연발이 그 답이 된다.

#11 시점에서 "blogsync 전반 금지"라고 적었다면, 래퍼를 통한 안전한 조작도 막는 과잉 규제가 되었을 것이다. 실제 기술 내용은 "직접 실행 금지 (기존 스크립트 경유 사용)"라는 최소한에 그쳤다. #15에서 "pull도 부작용이 있음"이 판명되어 범위를 넓혔고, #19에서 "래퍼 경유 시에도 사전 승인 필수"로 격상했다.

3번의 구체적인 사고를 바탕으로 한 단계적인 확장이었기에 과잉 규제가 되지 않았다. trigger 리스트는 사전에 완벽하게 설계하는 것이 아니라, 사고의 실태에 맞춰 최소한씩 넓혀가는 것이다.

Claude Code AI 거버넌스를 통해 본 두 가지 결론

22일간 19건의 인시던트를 기록하며 보인 것은 두 가지다.

1. AI의 독단은 외부 기구로만 포착할 수 있다

8건의 AI 발견 사례를 자세히 살펴보면, "의도적으로 설계한 메커니즘이 작동하여 발견했다"는 것은 #8의 1건뿐이다. 나머지는 유닛 테스트 (Unit Test)의 부수적 기능, 다른 작업 중의 우연, 에러 메시지의 자동 통지다. "독단하고 있다"라고 AI가 실시간으로 자기 인식한 사례는 제로였다 (출처: 각 인시던트 파일의 "원인" 섹션). 외부 체크 (테스트, 규칙, 인간의 검수) 없이는 독단을 포착할 수 있는 메커니즘이 존재하지 않는다.

2. trigger 리스트의 본질은 "변환 사이클을 돌리는 것"이다

사고를 기록한다 → 사고 유형을 규칙으로 변환한다 → 그 규칙이 다음의 동일 유형 리스크를 감지한다 —— 이 변환 사이클이 실제로 기능한다는 것을 #8이 처음으로 실증했다. 기록하는 것이 다음 날의 방어선이 된다. 이 연쇄를 얼마나 짧은 사이클로 돌릴 수 있는가가 AI 에이전트 거버넌스 (AI Agent Governance)의 실질적인 질문이라고 생각한다 (필자의 의견).

11건의 효과 검증이 보여주는 또 다른 관찰도 있다. 포착할 수 있는 사고 유형과, 아직 포착할 수 없는 사고 유형이 비대칭적으로 존재한다. blogsync는 3회 반복하여 적용 범위가 확정되었다. COO의 규모감 오인은 1회만으로는 임계값 (Threshold)이 정해지지 않았다. trigger 리스트는 앞으로도 계속 늘어날 것이다 —— 그것은 실패의 지속이 아니라, 변환 사이클이 계속해서 돌아가고 있다는 증거이기도 하다. 다음 첫 번째 사례가 무엇일지는 알 수 없다.

이 기사에서 소개한 멀티 에이전트 (Multi-Agent) 구성·거버넌스 설계의 전체상은 아래의 서적에서 더 자세히 다루고 있습니다. trigger 리스트의 설계 배경을 한 권에 정리한 것입니다.

Claude Code 전반의 실전·입문을 배우고 싶다면, 아래의 서적도 참고가 됩니다.

그 이후의 전개 —— 네 번째 사고와 근본 해결 (2026-05-20~05-31)

2026-05-20, hatena-bulk-update.sh로 5개 기사에 일괄 push를 실행하여, 총 5건의 커스텀 URL이 이중 경로(double path)화 되었다 (출처: logs/governance-incidents/2026-05-20_hatena-bulk-update-cwd-double-path.md, 과거 최대 피해). 수정 후 1건의 테스트 본 실행에서도 재발하여 진인이 판명되었다 —— push 후에 hatena-content 파일의 URL: 행이 이중 경로 형식으로 오염되는 결함 (결함 B)이 존재했으며, 서브쉘 (Subshell)화로는 막을 수 없는 구조적 문제였다.

2026-05-31, blogsync를 폐지하고 Hatena AtomPub API를 직접 호출하는 독자적인 CLI로 이행하여, 10개 기사에서 전 건의 URL이 변하지 않음을 확인했다 (실측).

trigger 리스트와 서브쉘화의 축적만으로는 멈출 수 없었다 (나의 의견). 망가지는 방식을 "결함 A (인자 형식)", "결함 B (URL 행 오염)"라고 정확히 분류할 수 있었기에, "도구를 바꾼다"라는 판단에 이를 수 있었다.

Insights