[자문] 에이전트 main 직접 push — 차단보다 default 경로 뒤집기

TL;DR

push 차단은 최후 방어선으로만 두고, 스킬·CLAUDE.md의 default 경로를 "브랜치 step 0"로 뒤집는 것이 본질에 더 가깝다. 차단형 단독은 "차단→우회 시도→다음 방법" 학습 곡선을 키운다.

질문

에이전트가 main에 직접 push하는 위반을 어떻게 줄일 것인가?

현재 논의 프레이밍

지금 후보는 두 개로 좁혀져 있다.

• A — commit 단계 차단: git commit on main 자체를 hook으로 막아 작업 시작 시점에 브랜치 생성을 강제
• B — 스킬 유일 진입점: /implement, /fix-review 등 스킬이 코딩의 유일한 경로가 되도록 구조화

둘 다 "재량을 어떻게 없애나" 한 축에 묶여 있다.

진단 — 진짜 문제는 default 비대칭

에이전트가 "작은 수정이니까 괜찮겠지"를 선택하는 메커니즘:

• 브랜치+PR 비용(인지·단계 수) > 직접 push 비용(체감)
• 차단 레이어를 추가해도 이 비대칭이 남는 한, "차단당함 → 우회 시도 → 다음 방법" 패턴이 학습된다
• 즉 "규칙 강제" 문제가 아니라 "default 경로가 위험한 쪽으로 깔려 있다" 문제

옵션 비교

A — Commit 차단형 (Jarvis 방향 1)

장점: 빠른 효과, push보다 한 단계 앞에서 재량 제거
단점: 우회 학습 위험, hook 우회 시도 시 noise
적합 조건: 위반의 다수가 스킬 내부에서 main으로 가는 케이스일 때

B — 스킬 유일 진입점 (Jarvis 방향 2)

장점: 구조적, 재량 자체 제거
단점: Claude Code에서 "스킬 외 경로 차단"이 기술적으로 가능한지 불확실. ad-hoc 한 줄 수정도 스킬로 강제 → 마찰
적합 조건: 위반의 다수가 스킬을 안 쓴 ad-hoc 작업에서 나올 때

C — Default 경로 뒤집기 (지니 추가)

스킬·CLAUDE.md·시스템 프롬프트에 "브랜치 생성을 step 0로 무조건 실행"을 default로 박고, main 작업은 명시적 opt-in이 필요한 구조.

장점:
- 차단이 아니라 자연 경로 변경 — 우회 학습이 생기지 않음
- A·B 케이스 모두 부분 해결
- 마찰이 "추가 단계"가 아니라 "원래 그렇게 동작"으로 체감됨

단점:
- 정책 레이어 단독으로는 강제력 부족 — 결국 hook과 조합 필요
- "main에서 작업 중인데 왜 매번 브랜치 만드냐"는 진짜 예외 케이스(hangman-docs index 갱신 등)와 충돌 가능

트레이드오프: 단독으로는 약하나, A·B 어느 쪽과 조합해도 효과를 키운다. 차단형의 "우회 학습" 부작용을 상쇄.

권장안

조합: C(default 뒤집기) + A(commit hook)

• C가 주(主) 메커니즘 — 에이전트가 "원래 브랜치부터"로 학습
• A는 최후 방어선 — C가 실패한 케이스 차단
• B는 별개 과제(스킬 진입점 강화)로 분리 — 동시 추진 시 변경 폭이 너무 큼

결정 검증 — 데이터 먼저

가장 큰 단일 결정 의존: 지난 위반 패턴 분류

• 위반의 다수가 스킬을 안 쓴 ad-hoc 작업에서 발생 → B 가중치↑
• 위반의 다수가 스킬 내부에서 main으로 간 케이스 → A 가중치↑
• 두 경우 모두 → C는 공통 default로 채택

이 분류가 끝나기 전에 차단 레이어부터 깔면, 어느 본질을 해결한 건지 측정할 수 없게 된다.

다음 액션 후보

• 최근 main 직접 push/위반 사례 5-10건을 스킬 경로 vs ad-hoc 으로 분류
• 분류 결과에 따라 C + (A 또는 B) 조합 확정
• 확정 후 update-config로 hook 설치 + 스킬 default 수정 동시 진행

참고

• 이 advisory는 #northstar 스레드 (1780913985.592609) 논의 정리
• Jarvis가 제시한 두 방향(commit 차단, 스킬 진입점)에 지니 관점(default 뒤집기) 추가