1년 실험 끝에 시니어가 도달한 결론 — AI에게 짧은 목줄을 채우세요

핵심 요약 (TL;DR)

okTurtles의 Greg Slepak이 1년간 실험 끝에 발행한 'Short Leash AI Coding Method'는 병렬 에이전트 문화에 정면으로 반박합니다. 6원칙의 핵심은 diff 승인 전 반드시 리뷰, 서브태스크마다 커밋, PR에 AI Disclosure 필수. 시니어 개발자라면 이 방법론을 그대로 옮겨 붙일 만한 가치가 있습니다.

Fable 5가 만든 코드는 '돌아가긴 하는데 못생겼습니다'

7월 2일, 분산 거버넌스 앱 Group Income의 유지관리자 Greg Slepak이 okTurtles 블로그에 긴 글을 하나 올렸습니다. 제목은 'Short Leash AI Coding Method'. Hacker News에서 182점·231 댓글로 상위 스레드에 올랐고, 그 논쟁의 절반이 '이 방법이 프론티어 모델을 낭비한다'와 '시니어에겐 이게 유일한 안전 경로다' 사이에서 반씩 갈렸어요.

Slepak이 방법론을 만든 계기는 단순합니다. Anthropic의 최신 프론티어 모델 Fable 5로 코드를 시켜본 결론이 이거였어요.

"The code works, but it is horribly inefficient and ugly."
코드는 돌아간다. 그런데 끔찍하게 비효율적이고 못생겼다.

1년 동안 오픈소스 CLI 에이전트 Crush의 자체 포크를 유지하며 실제 프로덕션 코드에 AI를 붙여본 사람의 관찰이니 무게가 다릅니다. 시니어 개발자가 '그냥 병렬로 에이전트 다섯 개 돌려놓고 밥 먹으러 가는' 소셜 미디어 흐름에 정색하고 반박하기 시작한 첫 실명 사례이기도 하죠.

6원칙, 그대로 옮겨 봅시다

Slepak이 정리한 원칙은 요약하면 이렇게 여섯 가지입니다.

1. 모든 diff는 승인 전 리뷰합니다. 자동 승인 옵션은 꺼둡니다. 한 줄씩 눈으로 훑고, 이해 안 가는 라인이 있으면 승인하지 않아요.

2. 원치 않는 변경은 즉시 permission deny로 막습니다. 에이전트가 '이참에 여기도 좀 손볼까요'라고 다가올 때 부드럽게 거절하지 마세요. 명시적으로 거부해서 학습 컨텍스트를 정리해 둡니다.

3. 서브태스크마다 커밋합니다. 한 세션에 태스크를 여러 개 쌓지 마세요. '인풋 파싱 리팩터'가 끝나면 커밋, '에러 처리 추가'가 끝나면 커밋. 되돌리기 쉬운 상태를 항상 옆에 둡니다.

4. AI를 병렬 리뷰어로 씁니다. 코드를 짜게 하는 것과 리뷰하게 하는 걸 다른 세션으로 분리하세요. 자기가 짠 코드를 자기가 검토하면 놓치는 실수가 있습니다.

5. PR 작성자는 AI 코드를 한 줄씩 self-review 합니다. 이건 팀 규칙으로 명시하는 게 좋아요. 'AI가 짜준 걸 그대로 밀어넣지 않는다'는 문화 없이는 다음 원칙도 소용이 없습니다.

6. PR 본문에 AI Disclosure 섹션을 필수로 둡니다. 어느 부분을 AI가 짰고 어떤 모델을 썼는지, 리뷰 강도가 어땠는지 명시합니다. 미래의 코드 감사를 위한 흔적이자, 팀 안에서 신뢰를 쌓는 최소 장치입니다.

원문의 표현과 세부 뉘앙스는 다를 수 있어 위 6개는 요약해 옮겼습니다. 정확한 문구가 필요하면 okTurtles 블로그 원문을 참고하세요.

왜 병렬 에이전트가 오히려 위험한가

Slepak의 반박에는 구체적 근거가 있습니다. 에이전트 다섯 개를 동시에 굴리면 각각의 세션이 코드베이스 표면을 각기 다른 각도로 만지게 되고, 리뷰어가 그걸 한 번에 이해하려면 인지 부하가 폭발합니다. 결국 사람이 놓치는 지점이 늘고, 리뷰가 사실상 자동 승인으로 무너지죠.

또 다른 문제는 스타일 일관성이에요. 병렬 세션들은 각자의 로컬 컨텍스트로 판단하기 때문에, 같은 유틸리티를 여기서는 A 스타일로, 저기서는 B 스타일로 짜놓기 십상입니다. 한 달 뒤 코드베이스를 열면 '이거 누가 짰지?'가 파일마다 다른 답이 됩니다.

PR 본문에 붙일 AI Disclosure 템플릿

원칙 6번을 실제로 굴리려면 팀 규칙에 템플릿을 박아 두는 게 편합니다. 아래 예시가 최소 골자입니다.

## AI Disclosure
- 사용 모델: Claude Sonnet 4.6
- AI 작성 범위: src/parser/*.ts, tests/parser.spec.ts
- 사람 리뷰 강도: 라인별 리뷰 완료, 변경 없이 승인
- 교차 리뷰: 별도 세션에서 GPT-5.4로 1회

네 줄이면 충분합니다. 한 달 뒤 이슈가 터졌을 때 이 네 줄이 있고 없고가 원인 추적 속도를 크게 갈라놓습니다.

FAQ

Q. 그럼 병렬 에이전트는 아예 안 되나요?
A. 리서치 스파이크나 프로토타입에는 유용합니다. 단, 프로덕션에 들어가는 코드는 짧은 목줄로 잡는 게 안전해요. Slepak이 반박하는 건 '프로덕션 코드에도 병렬을 던져놓아라'는 흐름입니다.

Q. AI Disclosure 섹션에 뭘 써야 하나요?
A. 최소 세 가지 — 어떤 모델, 어떤 범위, 리뷰 강도. 위 템플릿 그대로 팀 규칙에 넣어도 됩니다.

Q. 이 방법이 생산성을 떨어뜨리진 않나요?
A. 단기 속도는 줄어들 수 있어요. 대신 리팩터링·버그 추적·온보딩 비용이 절감됩니다. Slepak의 서브텍스트는 '속도를 파는 대신 유지보수 가능성을 사는 거래'입니다.

마무리

바이브코딩의 지금 흐름은 'AI에게 뭘 시킬 수 있는가'에 무게가 실려 있습니다. Slepak의 방법론은 반대 방향의 질문을 던져요 — 'AI가 만든 코드가 6개월 뒤 우리 팀에게 무엇을 남기는가.' 짧은 목줄이 답답해 보일 수 있지만, 시니어 개발자에게는 그것이 유일하게 지속 가능한 협업 방식일 수 있습니다. 오늘 저녁 팀 슬랙에 이 원칙 6개를 한 번 던져 보시는 것도 좋습니다.

참고 소스
- 원문: https://blog.okturtles.org/2026/07/short-leash-ai-method/
- Hacker News 스레드: https://news.ycombinator.com/item?id=48766026