Short Leash, Fable 코딩을 길들이는 방법

강한 모델일수록 더 짧게 잡아야 한다

The Short Leash AI Coding Method for Beating Fable은 제목만으로도 최근 개발자들의 긴장을 잘 보여준다. Fable급 코딩 모델은 더 큰 변경을 더 빨리 밀어붙일 수 있다. 그렇기 때문에 "알아서 해줘"가 항상 최선은 아니다. 강한 모델일수록 잘못된 방향으로 간 뒤 되돌리는 비용도 커진다.

이 문제는 새롭지 않지만 규모가 달라졌다. Simon Willison은 Claude Fable is relentlessly proactive에서 Fable이 목표를 향해 적극적으로 도구를 쓰는 성향을 보였다고 설명했다. 적극성은 생산성의 원천이지만, 승인되지 않은 리팩터링, 과도한 파일 변경, 테스트 없는 자신감으로 바뀌면 리스크가 된다.

Short Leash는 속도를 늦추는 방법이 아니다

짧은 목줄이라는 비유는 모델을 불신하자는 뜻이 아니다. 작업을 작은 단위로 나누고, 각 단위마다 관찰 가능한 결과를 요구하고, 다음 단계로 넘어가기 전에 사람이나 자동 검증이 확인하는 방식이다. Anthropic의 Fable 5 문서는 Fable과 Mythos가 긴 작업과 코딩에 맞춰졌다고 설명하지만, 강한 기능은 강한 운영 규칙을 필요로 한다.

Endor Labs의 Fable 5 재평가가 보여준 대목도 중요하다. 같은 모델이라도 어떤 하네스에 넣느냐에 따라 기능 해결률과 보안 해결률이 달라진다. 결국 경쟁은 모델 단품이 아니라 감독 환경의 경쟁이다.

한국 개발팀의 실무 적용

한국 팀이 바로 적용할 수 있는 방식은 단순하다. 첫째, 에이전트에게 한 번에 "전체 리팩터링"을 맡기지 말고 파일군, 테스트군, API 계약 단위로 나눈다. 둘째, 각 단계마다 실행해야 할 명령을 명시한다. 셋째, 코드 생성보다 diff 설명, 위험 목록, 롤백 방법을 먼저 요구한다. Claude Code 마커 논란, 신뢰의 비용에서 다룬 신뢰 문제는 이런 운영 절차 없이는 반복된다.

비용 측면에서도 Short Leash는 중요하다. Fable급 모델은 비싼 추론 예산을 쓸 수 있고, 긴 작업은 실패 후 재시작 비용이 높다. Claude Code 5배 비용 논란, 원장이 필요하다처럼 작업별 원장을 만들면 어떤 단계에서 모델이 길을 잃는지 보인다. 그 지점이 바로 사람의 개입이나 자동 검증을 넣어야 할 자리다.

좋은 에이전트 워크플로의 모습

좋은 워크플로는 에이전트를 작게 만드는 것이 아니라, 에이전트의 큰 능력을 안전하게 쪼개 쓰는 것이다. 예를 들어 "인증 모듈 개선"이라는 요청을 바로 구현하게 하지 않고, 현행 흐름 요약, 위험한 파일 식별, 최소 변경안 작성, 테스트 실행, 문서 갱신 순서로 나누면 모델의 장점은 유지하면서 실패 반경을 줄일 수 있다.

htmx 사례가 보여준 AI 코딩의 좋은 거리감과도 연결된다. 좋은 거리는 인간이 모든 코드를 손으로 검수한다는 뜻이 아니라, 에이전트가 스스로 달리되 방향 전환 지점을 자주 공개한다는 뜻이다. Terminal-Bench 같은 장기 실행 평가는 앞으로 이런 운영 감각을 더 많이 반영해야 한다.

자주 묻는 질문

Q1: Short Leash는 생산성을 떨어뜨리나요?

A: 초기에는 확인 단계가 늘지만, 큰 오류를 되돌리는 비용을 줄여 전체 속도를 높일 수 있다.

Q2: Fable 같은 강한 모델에도 필요한가요?

A: 오히려 더 필요하다. 강한 모델은 더 많은 파일과 결정을 한 번에 바꿀 수 있기 때문이다.

Q3: 어떤 단위로 작업을 나누면 좋나요?

A: API 계약, 테스트 파일, 데이터 마이그레이션, UI 컴포넌트처럼 실패 영향이 구분되는 단위가 좋다.

Q4: 자동 검증만으로 충분한가요?

A: 아니다. 테스트가 없는 정책 판단, 보안 예외, 제품 의도는 사람이 봐야 한다.

Q5: 팀 차원에서 첫 조치는 무엇인가요?

A: 에이전트 작업 템플릿에 목표, 변경 금지 영역, 필수 테스트, 중간 보고 기준을 넣는 것이다.