TL;DR

세 개의 개인 리포지토리(팟캐스트 운영 / 개인 사이트 운영 / 수익화 도구 개발)를 실험장으로 삼아, 기획부터 병합 및 운영까지의 개발 프로세스를 AI가 자율적으로 실행하도록 하는 시스템을 1개월 반에 걸쳐 구축했습니다.

• 권한은 처음부터 부여하지 않고,
  **Can(도달 가능한 범위) / May(실행 시 승인) / Act(게이트를 통과해야 효력이 발생)**의 3단계로 점진적으로 '획득'하도록 설계했습니다.
• 병합 조건을 기계가 읽을 수 있는 형태로 만든 결과, AI 리뷰어의 점수가 0/5 → 3/5 → 5/5로 수렴했으며,
  사람이 단 한 줄도 작성하지 않은 PR(Pull Request)이 봇에 의해 자동으로 병합되는 단계까지 도달했습니다.
• 성공 사례뿐만 아니라, macOS 권한 문제로 cron 작업이 모두 실패했던 경험이나, 리뷰용 스킬 자체가 '자신이 다른 PR에서 지적했던 것과 같은 위반'을 저질렀던 경험까지 포함하여, 실패를 통해 얻은 가드레일 원칙들을 부품 목록 형태로 정리합니다.
• 결과적으로, 개발 도구 측 리포지토리의 최근 80개 커밋 중 73개 커밋(91%)이 Claude와 공동 작업한 내용입니다.

배경 — 세 개의 개인 리포지토리를 'AI 기반 조직'의 실험장으로 삼다

저는 평소 PM을 하며 AI 에이전트를 개발 프로세스에 통합하는 일을 하고 있습니다. 이전 글에서, 리포지토리를 AI가 작업하기 쉬운 형태로 정리하는 방법(SSOT화와 Claude Skills)에 대해 작성한 적이 있습니다.

이번 내용은 그 연장선상입니다. 기반을 다진 후, '실제로 어디까지 맡길 수 있는지'를 확인하기 위해 성격이 다른 세 개의 개인 리포지토리에서 몇 달에 걸쳐 자율 실행 시스템을 구축해 왔습니다.

제가 전하고 싶은 것은 개별 도구의 사용법이 아닙니다. AI에게 자율 실행시키는 조직을 만들 때, 권한을 어떻게 제어하고, 병합 조건을 어떻게 정의하며, 어디에 가드레일을 둘 것인가입니다. 이 세 가지 포인트를 자신의 환경에 가져다 쓸 수 있는 구체적인 수준으로 정리하는 것이 이 글의 목적입니다.

권한 설계 — Can / May / Act 3단계 모델

올해 UC Berkeley Agentic AI Summit에 참가했을 때, 인상 깊었던 말이 있습니다.

멘션에 반응하는 workflow는 OWNER / MEMBER / COLLABORATOR의 댓글에만 반응합니다. 포크(fork)에서 온 PR은 신뢰도를 떨어뜨립니다. 후술할 자율 리뷰는 fork PR을 감지하면 수정 푸시를 포기하고 리뷰 코멘트만으로 자동 하향 조정됩니다.

Act — 결과물은 게이트를 통과해야 효력을 갖는다

AI가 만든 결과물을 그대로 '효력 있는 상태'로 만들지 않는 계층입니다. 이곳이 가장 설계하기 재미있었습니다.

• 팟캐스트 음성 업로드는 전자동으로 진행되지만, 배포 플랫폼 상에서는 Draft로 저장됩니다. 공개 버튼은 사람만 누릅니다. - 라이브 사이트에 쓰기 권한을 가진 CLI는 dry-run이 기본값이며, --apply를 명시했을 때만 실제 쓰기가 이루어집니다. 게다가 POST하기 전에 반드시 편집 전 스냅샷을 백업으로 남깁니다. - 그리고 머지(merge). 이것은 다음 절에서 자세히 설명하겠지만, 기계가 읽을 수 있는 조건을 충족한 경우에만 bot이 머지합니다.

3개 계층으로 나누어 보면, 'AI에게 자유롭게 맡긴다'와 '모두 사람이 확인한다'의 이분법적 선택지가 아니라는 것이 명확해집니다. 각 계층별로 느슨하게 하거나 조일 수 있는 다이얼이 3개 있다는 느낌입니다.

개발 프로세스별 자율도 맵

3개의 리포지토리를 개발 프로세스의 단계별로 'AI가 할 일 / 사람에게 남긴 것 / 경계를 지키는 장치'로 정리한 것이 이 표입니다.

단계에 따라 맡기는 정도가 상당히 다릅니다. 생성 계열은 거의 전부 맡기고 Draft 상태로 받아들입니다. 구현과 리뷰는 게이트를 두어 맡깁니다. 머지는 조건을 기계화한 후 bot에게 넘깁니다. 공개・결제・환경 변수와 같이 비가역적이거나 고위험의 작업은 끝까지 사람이라는 분포에 수렴했습니다.

머지 조건 설계 — '만점이면 통과'를 기계가 읽을 수 있게 만들기

자율 실행 시스템에서 가장 흥미로웠던 부분이 바로 여기입니다. 머지는 Git 히스토리에 영구적으로 남는 비가역적인 작업이므로, 끝까지 사람에게 남길지 고민했습니다. 최종적으로 '조건을 기계가 읽을 수 있도록 작성할 수 있다면 bot에게 넘긴다'라는 정리를 했습니다.

2가지 구현

yukamiya.me에서는 3가지 조건의 AND를 취하고 있습니다.

• Greptile (서드파티 AI 리뷰어)의 Confidence Score가 5/5
• GitHub의 required checks가 모두 green
• 자체 자동 리뷰 workflow가 기계가 읽을 수 있는 마커 AUTO_REVIEW_STATUS: pass를 출력하고 있음

hub.momit.fm에서는 GitHub Actions의 workflow (greptile-gate)로 구현했습니다. PR에 대한 push가 있을 때마다 실행되어, Greptile의 점수 게시를 기다린 후, Confidence Score: X/5를 파싱하여 만점일 경우 gh pr merge를 실행합니다.

포인트는 3가지가 있습니다.

• 판정 자료를 커밋 본문이라는 자연어에서 정규식으로 추출되는 형태로 고정한 것입니다. AI 리뷰어의 출력에 '기계가 읽을 수 있는 한 줄'을 요구하는 것은, AI 기반 프로세스 설계에서 매우 효과적인 노하우입니다.
• same-repo PR로만 제한한 것입니다. fork PR은 GITHUB_TOKEN이 read-only가 되는 사양 덕분에 게이트 자체가 대상에서 제외됩니다.
• 봇 병합(bot merge)도 감사 가능합니다. GitHub 상에 mergedBy가 app/github-actions으로 기록되기 때문에, 나중에 '누가 통과시켰는지'를 전혀 모호하게 만들지 않습니다.

병합 조건은 개선 압력이다 — 스코어 수렴의 실전 사례

이 게이트가 처음으로 프로덕션에서 처리한 것은, 아이러니하게도 '자율 리뷰 역량 자체를 추가하는 PR'였습니다. 경과 과정을 그대로 나열합니다.

가드레일 원칙 모음 (하네스의 부품 목록)

3개의 리포지토리를 가로질러 작동했던 가드레일을 부품 목록으로 나열합니다. 모두 단독으로는 미미하지만, 조합하여야 비로소 '안심하고 맡길 수 있는' 상태가 되었습니다.

실패로부터 배운 것

잘된 이야기보다 실패 사례가 설계 원칙을 주었습니다. 4가지를 나열합니다.

macOS 권한으로 매주 크론 작업이 18일 동안 조용히 전멸했다. launchd에 등록한 주간 작업이 Operation not permitted로 계속 실패하고 있었습니다. 원인은 TCC(macOS의 개인 정보 보호) 때문이었고, 수동 실행으로는 정상이라 알아차릴 수 없었습니다. 로그를 볼 시스템만 만들고, 로그를 보는 습관을 들이지 않았던 것입니다. 자동화의 생사 감시는 그 자체를 자동화하지 않으면 의미가 없다는 교훈입니다.

외부 서비스의 미문서화된 동작으로 게이트가 타임아웃했다. Greptile은 문서 추가만 하는 푸시(push)에 대해서도 새로운 리뷰 객체를 만들지 않고 요약 코멘트를 in-place로 업데이트하여 채점할 때가 있습니다. 리뷰 객체의 출현만을 기다리던 게이트는, 만점이 나왔음에도 영원히 알아차리지 못했습니다. 대처법은 감지의 2개 시스템화(리뷰 객체 또는 코멘트 업데이트 시간)였습니다. 외부 서비스의 동작은 반드시 예상치 못한 상황을 전제로, 판정 자료를 단일선으로 만들지 않기로 했습니다.

리뷰용 스킬 자체가 자신이 다른 PR에서 지적했던 것과 같은 위반을 저질렀다. 자율 리뷰는 다른 PR에서 '사용자 고유의 절대 경로를 하드코딩하지 말라'고 지적하고 수정까지 했음에도, 그 스킬 자체의 매뉴얼에 절대 경로가 직접 적혀 있었습니다. 발견한 것은 자신이나 외부 AI 리뷰어가 아니었습니다. 자기 검증에는 구조적인 사각지대가 있습니다. 병합 판정을 자신과 독립된 평가자에게 둔 설계는 여기서 효과를 발휘했습니다.

셸 주입 및 fork 오(誤) 푸시 지적을 외부에서 받았다. 'PR의 브랜치명은 공격자가 자유롭게 붙일 수 있는 입력'이라는 시각이 개인 리포지토리의 관점에서는 빠져 있었습니다. public 리포지토리에서 자율 실행시키려면, PR 메타데이터는 모두 신뢰할 수 없는 입력으로 취급해야 합니다. 브랜치명의 형식 검증과 따옴표 필수화, fork PR의 권한 자동 하향 조정(downgrade)을 여기서 적용했습니다.

조직에 도입한다면 무엇부터 시작할까

개인 리포지토리에서 검증한 것이기 때문에, 단독 개발자나 소규모 팀이라는 한계는 미리 말씀드립니다. 합의 형성이나 컴플라이언스(compliance) 레이어는 이번 범위 외입니다. 그럼에도 불구하고, 도입 순서로는 다음 3단계가 재현하기 쉽다고 느낍니다.

• Can과 Act부터 시작한다. 허용 목록(allowlist)으로 범위를 좁히고, 결과물의 수신처를 Draft/dry-run으로 합니다. 여기까지는 기존의 리뷰 체계를 전혀 바꾸지 않고 도입할 수 있으며, 문제가 생겨도 되돌릴 수 있습니다.
• 병합 조건(Merge condition)을 기계가 읽을 수 있게 만든다. 당장 자동 병합까지 가지 않아도, 'AI 리뷰 결과를 1줄 마커로 출력'하는 것만으로 프로세스를 감사(audit)할 수 있게 됩니다. 임계값(threshold)을 올리거나 내릴 수 있는 다이얼을 먼저 만드는 발상입니다.
• 학습의 위치를 정한다. 실행 기록, 오탐지 메모, 배운 규칙 등을 리포지토리에 커밋하는 운영 방식을 취하면, 세션이나 담당자가 바뀌어도 지식이 쌓입니다. 규칙에 증거 인용(evidence citation)을 필수화하면, 나중에 '왜 이 규칙이 존재하는가'를 추적할 수 있습니다.

요약

최종적인 분담은 다음과 같았습니다.

AI에게 맡길 범위를 넓히는 작업은 결국 '신뢰의 조건을 언어화하여 코드로 만드는' 작업이었습니다. 모호하게 신뢰하거나, 모호하게 경계하는 것이 아니라, 조건을 적습니다. 쓸 수 있는 만큼만 맡길 수 있습니다. 3개 리포지토리 분량의 로그를 되돌아보면서 그것이 가장 큰 수확이었다고 생각합니다.

참고

• 전제 기반 다지기 이야기: https://zenn.dev/yukamiya/articles/pm-ssot-claude-skills
• Human-in-the-loop 설계 이야기: https://zenn.dev/yukamiya/articles/ai-evidence-judgment
• Greptile: https://www.greptile.com/
• Claude Code GitHub Actions: https://github.com/anthropics/claude-code-action

토론