이 기사의 실시 기록 (2026-05-11): 「Skills에 정의하는 것이 좋은 작업 후보를 올려줘」라는 한마디로부터, Claude Code가 설계·구현·테스트·git push까지 자율적으로 완수했다. 완성물은 스킬 12개 + hooks 3개 + BSD grep 수정 (6개 파일 13곳). 테스트 328건 전건 PASS (인수인계 로그 기재: 254건 + hooks 74건). 선행 4개 스킬의 첫 커밋 (19:03 JST)부터 세션 종료 (19:50 JST)까지 47분 (제목에서는 「50분」으로 표기). 나의 발언은 「해줘」, 「진행해」 등의 짧은 승인이 중심이었다.

2026년 5월 11일 밤, 나는 이렇게 입력했다.

「이 프로젝트에서 다양한 작업을 하고 있는데, Skills에 정의하는 것이 좋은 작업 후보를 올려줘」

구현 의뢰가 아니다. 「후보를 올려줘」다.

그 후에 일어난 일을 먼저 적어둔다. 47분 후 (제목에서는 「약 50분」으로 표기), 다음과 같이 완성되어 있었다.

• 스킬 12개 (설계·구현·배포·테스트까지)
• hooks 3개 (SessionEnd / UserPromptSubmit / PreToolUse)
• BSD grep의 호환성 버그 수정 (6개 파일 13곳)
• 테스트 328건 전건 PASS
• git push까지 완료

내가 「구현해줘」라고 말한 적은 단 한 번도 없다.

「AI가 자율적으로 움직였다」라고 쓰면 오해를 부를 수 있으므로, 먼저 정확하게 정의해 둔다.

이번 움직임은 「완전 자율」이 아니다. 「승인 기반의 자율」이다.

플로우의 실태는 다음과 같았다.

사용자: 「후보를 올려줘」 (추상적 지시)
↓
COO: 프로젝트 전수 조사 → 17개 후보를 우선순위별로 리스트업
...

곳곳에 사용자의 승인 게이트(Approval Gate)가 있다. 이 구조를 「AI가 무엇이든 마음대로 했다」라고 읽지 말아 주길 바란다. 정확하게는 「인간이 승인 게이트를 갖고, AI가 실행 경로를 설계·실행한다」는 분업이다.

이 「승인 기반의 자율」이야말로 이번의 핵심이며, 「완전 방임」도 「일일이 지시」도 아닌 제3의 형태라고 생각한다.

출처는 세션 인수인계 로그 (logs/session/2026-05-11_session-handover.md)와 대화 아카이브 (knowledge/dialogue/claude-code-self-driven-improvement.md).

「후보를 올려줘」에 대해, COO는 프로젝트 전체를 조사하여 17개의 스킬화 후보를 우선순위별로 분류하여 리스트업했다. 최우선 4개 · 고우선 5개 · 중우선 5개 · 저우선 3개라는 구성이다.

나는 「우선 최우선인 4개를 구현해」라고 답했다. 이것이 첫 번째 승인이었다.

Playbook의 위임 규칙 (architect → skill-dev 순서)에 따라, 페이즈별로 설계서 (workspaces/architect/skills-{4,phase1,medium,low}-design.md 및 hooks-3-design.md)가 작성되었고, skill-dev로 구현이 위임되었다.

여기서 병렬 가동이 활용되었다. architect 2개의 인스턴스가 중우선 설계와 저우선 설계를 동시에 진행하고, skill-dev와 devops가 구현과 배포 스크립트 정비를 병렬로 실행했다. 이는 Claude Code의 서브 에이전트 기능 (Task tool)으로 실현할 수 있다. 하나의 메시지 내에서 여러 개의 Task tool 호출을 나열하는 것만으로, 터미널 창 2개를 동시에 띄워 실행하는 것과 같은 감각으로 병렬 실행이 시작된다. 추가 과금도 특별한 설정도 필요 없다.

참고로 settings.local.json에 대한 쓰기는 Claude Code의 시스템 보호로 인해 에이전트로부터 차단된다. 이 벽에 부딪힌 시점에서 COO가 수동 편집으로 전환했다. 「이 벽은 인간이 넘는다」라는 경로 변경의 예시다.

Claude Code의 서브 에이전트 활용을 더욱 깊게 파고들고 싶은 분들에게는 현장 개발자에 의한 실천서가 참고가 된다. → 실전 Claude Code 입문——현장에서 활용하기 위한 AI 코딩 사고법 (Kindle)

Phase 1의 구현 페이즈 중, skill-dev가 macOS의 BSD grep에 관한 호환성 버그를 발견했다. --xxx로 시작하는 패턴 문자열을 옵션 인수로 오인하는 문제로, 기존 테스트 스크립트 55개를 devops가 점검하여 6개 파일 13곳을 수정했다 (커밋 5365ce1).

나는 이 수정을 의뢰하지 않았다. 구현 중 스캔 과정에서 자율적으로 발견하였고, COO를 통해 승인·수정이 이루어졌다.

완성된 스킬과 hooks의 테스트 결과는 다음과 같다 (출처: logs/session/2026-05-11_session-handover.md).

"push 해줘"라는 한마디로 커밋된 변경 사항이 origin/master로 푸시되었다 (9338e2c..6203aa1, 총 10개 커밋).

macOS BSD grep의 -- 패턴 오인식에 대응. 6개 파일 13곳을 grep -qF -- "$needle" 형식으로 통일 (Commit 5365ce1).

커밋 이력에서 실측한 시계열 (출처: git log).

세션 끝부분에 이런 일이 일어났다.

내가 "끝냅니다"라고 입력했을 때, COO는 "세션 종료 전 확인입니다. 인수인계 자료를 작성할까요?"라고 응답했다. 내가 "/handoff로 작성"이라고 답하고, handoff가 완성된 직후——

UserPromptSubmit hook success: 사용자가 대화 저장 패턴을 발언했습니다.
`ops/playbooks/dialogue-archive.md`의 플로우 B-2에 따라 저장을 실행해 주세요.

방금 구현한 detect-dialogue-archive.sh가 이 세션의 인수인계 완료를 알리는 대화에 즉각 반응했다. "끝냅니다" → "대화 저장해줘"라는 흐름이 대화 저장 패턴으로 검출된 것이다.

이 순간, 나는 이렇게 적었다 (대화 아카이브에서 인용):

"나는 구체적인 것을 아무것도 의뢰하지 않았는데, Claude Code가 스스로 개선을 제안하고 구현했다"

스킬화가 검토되었으나 명시적으로 보류된 항목이 있다 (출처: logs/session/2026-05-11_session-handover.md §보류 판단).

"무엇을 만들 것인가"뿐만 아니라 "무엇을 만들지 않을 것인가"도 COO가 판단하였고, 사용자는 최종 확인만 수행했다. 보류는 실패가 아니라, 기술적 제약 또는 대체 수단이 존재하기에 내린 합리적인 판단이다.

그렇다. "승인 기반의 자율(Approval-based Autonomy)"임을 서두에 명시했다. 후보 제시, 페이즈 구분, 보류 판단 등 곳곳에서 사용자의 승인을 거쳤다. "완전 자율"을 주장하는 글이 아니다.

이번의 핵심은 "지시의 추상도가 성과 스케일을 결정했다"는 점이다. "후보를 올려줘"라는 추상적인 한마디가 설계, 구현, 테스트, push의 전 연쇄를 가동했다.

본 세션의 신규 12개 스킬 + 세션 전부터 존재했던 기존 3개 스킬(/todo, /health, /dream) = 총 15개 (인계 로그의 스킬 목록에서 추산). 테스트 328건 전건 PASS는 인계 로그와 구현 보고서 양쪽에서 확인 완료했다.

보류는 "만들 수 없었던" 것이 아니라, 기술적 제약(MCP 실시간 게시 불가, ProseMirror 제약) 또는 대체 수단의 존재(/cowork, /handoff 포함)에 따른 합리적인 판단이다. 사용자에게 이유를 설명하고 승인을 얻는 과정도 기록되어 있다.

선행 4개 스킬의 첫 커밋(19:03 JST)부터 세션 종료(19:50 JST)까지 47분이다 (커밋 51517c5 ~ 6203aa1). "아무것도 없는 상태에서 50분"이 아니다. Playbook, 위임 규칙, 테스트 기반이 선제적으로 정비된 상태에서의 세션이다.

잘 되지 않는 사례가 더 많다. 나의 프로젝트에는 logs/governance-incidents/에 19건의 실패 기록이 있다 (2026-05-19 실측). awk의 줄바꿈 버그로 26개 파일이 빈 파일이 된 사고, blogsync 직접 실행으로 기사 URL 4개가 바뀐 사고, writer가 존재하지 않는 정보를 3건 창작한 사고——모두 실제로 일어난 일들이다.

이번 세션이 기능했던 조건을 한마디로 말하면 "규칙과 테스트 기반이 먼저 성장해 있었다"이다.

"후보를 올려줘"라는 추상적인 지시가 대규모 구현을 가동할 수 있었던 이유는 세 가지가 있다.

1. 위임 규칙이 명문화되어 있었다

COO에게는 "무엇을 스스로 하고, 무엇을 위임할 것인가"에 대한 명문 규칙(coo-rules.md)이 있다. 설계는 architect에게, 구현은 skill-dev에게라는 경로가 확립되어 있었기에, "해줘"라는 한마디로 위임이 실행되었다. 이 경로가 없다면 "후보를 올려줘"는 후보 리스트를 내놓는 것으로 끝난다.

2. 테스트 기반이 작동하고 있었다

테스트를 통과하는 것(PASS)이 "완성의 증명"으로서 기능했다. 328건의 테스트가 없다면 "무엇이 완성되었는지"를 인간이 일일이 확인해야 하며, 50분 안에는 끝나지 않는다.

3. 가치관 거버넌스가 승인을 구조화했다

CLAUDE.md의 "trigger 리스트"를 통해 "승인이 필요한 상황"이 명문화되어 있었다. AI가 폭주하지 않고, 인간의 승인 게이트가 유효하게 기능했다.

이러한 전제는 "나의 Claude Code 환경에서는"이라고 한정해 둔다. 정비에는 수개월이 걸렸다. 다만, 위임 규칙의 명문화와 테스트 기반이라는 원칙 자체는 에이전트 수에 의존하지 않는다. 4~5개 에이전트의 소규모 체제에서도 "누가 무엇을 결정하는가"가 문서화되어 있다면, "후보를 올려줘"라는 추상적 지시가 설계·구현의 연쇄를 가동할 수 있다.

"후보를 올려줘"라는 한마디로부터 47분 만에 12개 스킬 + 3개 hook이 완성되었다 (제목에서는 "50분"으로 표기했다).

지시의 추상도가 성과 스케일을 결정한다——이것이 이번의 핵심이다. "구체적으로 구현해"라고 말하지 않아도, AI가 스스로 경로를 설계하고, 위임하며, 완수한다. 단, 그 전제로서 "달려도 좋은 경로의 명문화"와 "승인 게이트의 구조화"가 필요하다.

완전한 방임도, 일일이 지시하는 것도 아닌, 이 「승인 기반의 자율 (Approval-based autonomy)」이야말로 현시점에서 내가 가장 생산성을 느끼는 인간과 AI의 협업 형태다. '1건의 실패 → 1건의 규칙 추가'라는 사이클을 반복함으로써 기능하기 시작한다.

「승인 기반의 자율 (Approval-based autonomy)」이 어떤 설계 사상에 기반하는지, AI 주도 개발 (AI-driven development)의 이론적 배경을 알고 싶은 분은 이쪽을 참고하시길. → Claude Code를 통한 AI 주도 개발 입문 (Kindle)

이 기사에서 다 담지 못한 설계 및 운용의 전체 모습은 Zenn Books에 정리해 두었다. 서장과 제1부는 무료로 읽을 수 있다.

• 코드를 쓸 줄 모르는 내가 Claude Code로 「AI 팀」을 만들기까지 (¥900 / 서장·제1부 무료)

• 코드를 쓸 줄 모르는 내가 Claude Code로 「AI 팀」을 운영하기까지 (¥900 / 서장 무료)

• Claude Code 실용 TIPS 모음 — 알고 있으면 5초, 모르면 1시간 - 코드를 쓰지 않는 SE 일지

• 자기 개선하는 멀티 에이전트 (Multi-agent) 조직을 만드는 법 — Claude Code로 구축한 9개 에이전트 체제의 하네스 (Harness) 설계 - 코드를 쓰지 않는 SE 일지

• Claude Code로 작업을 기록했더니 그대로 기사가 되었다 —— 메타 피드백 루프 (Meta-feedback loop)의 실록 - 코드를 쓰지 않는 SE 일지

이 기사는 はてなブログ (Hatena Blog) 에서의 크로스 포스트입니다.