이 기사의 요점 (2026년 5월): 나는 세션 이력(대화 로그)에서 개선점을 자동으로 추출하는 「dev-workflow」라는 스킬을 직접 제작하여 실전에 투입했다. 그런데 첫 테스트에서, 분석 역할로 위임한 researcher 에이전트가 승인 없이 scripts/util/dj.sh를 169행 추가, 21행 삭제하며 수정해 버렸다. 원인은 위임 프롬프트에 「분석만 할 것·수정 금지」라는 한 줄의 제약을 쓰는 것을 잊었기 때문이다. 실질적인 피해는 없었고 변경 내용 자체도 타당했기에 나중에 그대로 채택했지만, 이 사고 자체가 「자기 개선 루프가 가진 구조적인 허점」을 학습하는 최고의 교재가 되었다. 출처: logs/governance-incidents/2026-05-25_dev-workflow-researcher-unauthorized-edit.md.

Claude Code로 개선을 측정하려던 행위가 사고를 일으켰다

Claude Code로 멀티 에이전트 (Multi-agent) 운용을 하다 보면, 「세션의 회고를 자동화하고 싶다」는 욕심이 생긴다. 대화 로그에는 AI에 대한 수정 지시, 동일한 주의 사항의 반복, 규칙 위반 지적 등 다음 개선으로 이어질 힌트가 담겨 있다. 그것을 매번 직접 다시 읽는 것은 번거롭다. 그렇다면 에이전트에게 읽게 하고, 개선점을 GitHub Issue에 자동으로 등록하면 된다——그렇게 생각하여 만든 것이 「dev-workflow」라는 스킬이었다.

이 스킬을 실전에 투입한 첫 테스트에서 사고가 발생했다. 개선점을 찾기 위한 분석 작업 자체가 승인 없는 파일 변경이라는 별개의 문제를 일으킨 것이다. 「실질적 피해가 없으면 별일 아니다」라고 생각할지도 모르지만, 나는 이 사고를 자기 개선 메커니즘을 만든다면 한 번은 거쳐야 할 실패였다고 받아들이고 있다. 이유는 본문에서 설명하겠다.

dev-workflow 스킬이란 무엇인가

「자기 개선 루프 (Self-improvement loop)」라는 설계 사상은 나의 조어가 아니다. 참조처는 sonicgarden의 기사 「Claude Code의 자기 개선 루프」다. 이 기사에서는 개발 세션 후에 대화 이력을 분석하여 실패 시그널을 검출하고, GitHub Issue에 등록하는 메커니즘과, 그 Issue를 다른 에이전트가 리뷰하여 SKILL.md의 개선안을 Pull Request로 제출하는 메커니즘을 결합하여, Routines (정기 실행 메커니즘)를 통해 매일 자동으로 돌리고 있다. 대략 3주 동안 40건 이상의 자동 트리아지(Triage) 및 커밋을 만들어냈으며, 개발자 본인이 「잘 되었다」고 느낀 세션 중에서도 에이전트 간의 상호작용에 잠재된 문제를 발견할 수 있었다고 한다.

나는 이 발상을 나의 조직에도 도입하여, 「dev-workflow」라는 이름의 스킬(어디까지나 내 워크스페이스 내에서의 명칭이며 공식 용어는 아님)을 만들었다. 메커니즘은 간단하다.

• 최근의 세션 로그 (JSONL 파일)를 특정한다
• researcher 에이전트에게 분석을 위임한다
• 「수정 지시」, 「반복 패턴」, 「규칙 위반 지적」, 「좌절(Frustration)」, 「반복 에러」의 5가지 종류의 시그널을 JSON 형식으로 받는다
• 각 시그널을 /todo를 경유하여 GitHub Issue (inbox 라벨)로 등록한다

세션 로그는 MB 규모가 될 수 있기 때문에, 메인 COO 세션에서는 읽지 않고 반드시 서브 에이전트에게 위임하도록 설계했다. 여기까지는 흔히 있는 「AI에게 AI를 감사하게 하는」 메커니즘의 연장선상에 있다. 문제는 이 「위임한다」는 한 수에서 발생했다.

scripts/util/dj.sh가 190행 수정되었다

무슨 일이 일어났는가——위임 프롬프트 한 줄을 빠뜨리는 바람에 첫 실전 테스트에서 나는 researcher 에이전트에게 당시 세션 로그의 분석을 위임했다. 기록에 따르면 약 691KB로, 평소보다 큰 세션이었을 가능성이 있다.

위임 프롬프트에는 「개선 시그널을 추출하여 JSON 배열로 반환해 달라」는 지시만 적었다. 「분석만 해 달라. 파일은 일절 변경하지 말아 달라」는 제약은 쓰지 않았다.

그러자 researcher는 로그를 분석하는 과정에서 scripts/util/dj.sh (내가 취미로 만든 음악 재생 스크립트)의 재생 로직에 문제가 있다는 것을 깨닫고, 승인을 받지 않은 채 그대로 수정해 버렸다. 차분(Diff)을 git show로 실측해 보니 169행 추가, 21행 삭제로 총 190행의 변경이었다. 구체적으로는 연속 재생 시의 참조 플레이리스트를 「DJ Queue」에서 「Claude's Picks」로 전환하고, picks-update...

/ picks-list

라는 새로운 서브커맨드 (subcommand)를 추가하고, 랜덤 선곡의 샘플링 로직 (sampling logic)도 개선하고 있었다.

"분석해 주길" 바랐던 의도가 "분석하는 김에 고쳐 두었다"로 돌아왔다. 위임(delegation)하는 순간, 나는 제약 사항을 쓰는 것을 잊어버리는 빈틈을 만들었던 셈이다.

왜 일어났는가——"제약을 쓰면 그만"이라는 말로 끝나지 않는 이야기

"읽기 전용 (read-only) 제약을 쓰면 되는 것 아닌가?"라는 지적은 옳다. 실제로 사고 후에 내가 취한 대책도 바로 그것이다. dev-workflow 스킬의 위임 프롬프트 (delegation prompt)에 "중요: 파일의 읽기·분석만 수행할 것. 스크립트 수정·파일 생성·변경은 일절 하지 말 것."이라는 한 줄을 추가했다. 기술적인 해결책으로는 이것으로 충분히 기능한다.

다만, 내가 흥미롭다고 느낀 점은 그 이전의 구조다. researcher 에이전트 (agent)는 문제를 발견하면 자율적으로 수정까지 나아가는 성질을 가지고 있다. 그 자체는 평소의 개발 작업에서는 환영받아야 할 동작이며, 나 또한 "찾으면 고쳐 두라"는 운영을 다른 상황에서 흔히 수행하고 있다. 이번에 문제가 되었던 것은, "이번에는 분석만 해 주길 바란다"라는 나의 의도를 위임 프롬프트라는 하나의 텍스트로 녹여내는 데 실패했다는 점이다.

즉, 사고의 핵심은 "researcher가 폭주했다"는 것이 아니라, "자기 개선 루프 (self-improvement loop)를 구축하던 나 자신이 위임 설계 (delegation design)의 체크를 통과시켜 버렸다"는 데 있다. 개선 메커니즘을 만들려다가, 개선 메커니즘이 갖추어야 할 기본 규칙(위임 범위의 명시)을 스스로 건너뛰었다——여기에 구조적인 아이러니가 있다.

대책——coo-rules.md에 읽기 전용 제약 추가

사고 후에 취한 대책은 다음 두 가지다.

• 즉시 대응: dev-workflow 스킬의 위임 프롬프트에 읽기 전용 제약을 명시
• 영구 대응: COO의 행동 규칙 (.claude/rules/coo-rules.md)에 "분석·조사만을 의도한 위임에서는 반드시 '파일의 읽기·분석만 수행할 것. 스크립트 수정·파일 생성·변경은 일절 하지 말 것'을 명시한다"라는 체크포인트를 추가

나아가, 이 사고 자체를 logs/governance-incidents/2026-05-25_dev-workflow-researcher-unauthorized-edit.md라는 인시던트 기록 (incident record)으로 저장했다. 카테고리는 "규칙 미비", 심각도는 "낮음". 실질적인 피해가 없었기에 심각도는 낮지만, 기록으로 남김으로써 동일한 종류의 위임(조사 계열 태스크를 서브 에이전트에게 던지는 상황) 모두에 재발 방지 규칙을 파급시킬 수 있었다.

실질적 피해가 없었기에, 최상의 테스트 케이스가 되었다

"실질적 피해가 없다면 별일 아니다"라는 시각에 나는 감히 정면으로 동의하고 싶다. 만약 이것이 운영 환경의 결제 API나 고객 데이터를 다루는 스크립트였다면, 웃으며 넘길 수 있는 이야기가 아니었을 것이다. 이번 타겟이 dj.sh라는 나의 개인 음악 재생 스크립트였던 것은 단순한 우연이다.

하지만 우연이라 할지라도, 실질적 피해가 없고 변경 내용 자체는 타당하다는 조건이 갖춰진 덕분에, 나는 "위임 범위를 명시하지 않았을 때 어떤 일이 일어나는가"를 실제 피해를 입히지 않고 학습할 수 있었다. 게다가 변경 내용(플레이리스트 참조처 수정, 신규 커맨드 추가)은 나중에 리뷰하여 그대로 채택했다. 망가진 실험이 아니라, 부산물까지 얻은 실험이었던 셈이다. 자기 개선 메커니즘을 만든다면, 이런 경미한 사고를 허용할 수 있는 범위 내에서 한 번쯤 겪어두는 것이 나중에 운영 환경에 영향을 주는 곳에서 같은 실수를 반복하는 것보다 안전하다고 지금은 생각한다.

자기 개선 루프의 재귀성

개선을 탐지하는 메커니즘을 만들려다가, 그 메커니즘을 만드는 과정 자체가 새로운 문제를 낳았다——이것은 우연한 아이러니가 아니라, 자기 개선 루프가 구조적으로 안고 있는 성질이라고 나는 파악하고 있다. 탐지 역할 (researcher)이 탐지 대상(위임 프롬프트의 미비) 그 자체에 휘말릴 가능성은, 이런 종류의 메커니즘을 설계하는 측에서 처음부터 고려해 두어야 할 전제다.

실무적인 배움으로 요약하면 단순해진다. dev-workflow와 같은 "다른 세션·다른 에이전트의 동작을 분석하는 스킬"을 만들 때는, 그 위임 프롬프트 자체에 일반적인 태스크보다 더욱 엄격하게 제약을 작성할 필요가 있다. "조사 대상을 분석한다"라는 태스크의 성질상, 분석 역할 에이전트는 분석 중에 발견한 또 다른 문제에 그대로 손을 대기 쉽다고 나는 생각한다. 적어도 이번 사고는 그 경향이 표면화된 케이스였다.

다음에 dev-workflow 스킬을 실행할 때, 이번 인시던트(incident) 자체가 개선 시그널(improvement signal) 중 하나로서 로그에 남게 될 것이다. 시스템을 만드는 측이 처음부터 완벽할 필요는 없다. 사고가 발생했을 때, 그것을 포착하여 다음 규칙으로 변환할 수 있는 경로만 마련해 두면 된다.

이번 1줄의 누락은 내가 dev-workflow 스킬의 위임 프롬프트(delegation prompt)에 수동으로 추가하여 해결했다. 하지만 똑같은 구멍은 다른 스킬이나 다른 위임에도 숨어 있을 수 있다. 다음에 마주할 질문은 이러한 위임 규칙을 하나씩 손으로 고치는 것이 아니라, 조직의 설정으로서 어떻게 명문화하고 쌓아 올릴 것인가 하는 점이다. 이를 체계적으로 다루고 있는 것이 Zenn Book Vol.4 「코드를 작성할 수 없는 내가 Claude Code에 '시스템'을 전달하기까지」(서장 무료)이며, 권한 관리(permission management)·거버넌스(governance)·CLAUDE.md의 설계를 다루고 있다. 하나의 위임 실수로부터 영구적인 규칙으로 도출하기까지의 흐름을 조금 더 체계적으로 알고 싶은 분들은 그쪽도 참고해 주길 바란다.

참고 링크

• sonicgarden 「Claude Code의 자기 개선 루프」 — 본 기사의 dev-workflow 스킬의 착상 원천
• Claude Code의 에이전트 3체를 1체로 통합한 실록 — 멀티 에이전트(multi-agent) 조직 전체 소개
• 자기 개선하는 멀티 에이전트 조직을 만드는 방법 — 하네스(harness) 구조의 설계 해설

이 기사는 Hatena Blog로부터의 크로스 포스트입니다.

Discussion