에이전트형 개발이 빠르게 확산되면서, 팀 리드들이 마주하는 진짜 질문이 달라졌다. 이제 '어떤 AI 도구를 쓸까'가 아니라 '에이전트에게 얼마나 맡길까'다. 그리고 이 질문에 답하는 방식이 팀의 코드 품질과 운영 안정성을 결정한다.
addyo의 에이전트 자율성 분석은 이 문제를 6단계 레벨 모델로 정리한다. Level 0(Assist)부터 Level 5(Managed-by-exception orchestration)까지, 단순한 코드 제안 보조에서 이슈 트래커를 읽고 스스로 작업을 배분하는 에이전트 팩토리까지다. 중요한 건 이 사다리를 '올라가는 것'이 목표가 아니라는 점이다. 높은 레벨이 곧 성숙한 활용이라는 착각이 가장 흔한 안티패턴이다.
두 축으로 봐야 한다: agency와 orchestration
단일 레벨 숫자로 에이전트 역량을 표현하는 건 한계가 있다. 단일 에이전트를 얼마나 자율적으로 보낼 수 있는가(agency)와, 여러 에이전트를 얼마나 잘 조율할 수 있는가(orchestration)는 별개의 축이다. Claude Code의 /goal, /loop, /batch나 Codex의 Goal mode, worktree, Automations 같은 기능들은 이 두 축을 각각 올릴 수 있는 레버다. 팀 리드는 지금 어느 축에서 병목이 생기는지를 먼저 진단해야 한다.
Anthropic 데이터가 드러낸 실제 분업 구조
약 23.5만 명, 40만 세션을 분석한 Anthropic 연구에서 나온 수치가 흥미롭다. 사람이 계획 결정의 약 70%를, Claude가 실행의 약 80%를 맡는 구조다. 높은 자율성이란 사람을 루프 밖으로 빼는 게 아니라, 사람이 '매 단계 실행'에서 '다음 방향 결정'으로 이동하는 것이다. 이 구분을 팀 내에서 명확히 공유하지 않으면, 에이전트에게 실행을 맡기면서도 계획까지 통째로 위임하는 혼란이 생긴다.
자율성의 상한을 정하는 건 위험과 가역성이다
자율성 레벨 선택의 핵심 기준은 두 가지다. '무언가 잘못됐을 때 얼마나 빨리 알 수 있는가'와 '얼마나 깔끔하게 되돌릴 수 있는가'. 강한 테스트, 리뷰어 에이전트, 깔끔한 롤백 경로가 갖춰진 결제 엔진 리팩터링은 정답 기준이 모호한 문서 자동화보다 더 높은 자율성을 감당할 수 있다. 작업 이름이 아니라 검증 프로세스가 자율성 레벨을 결정해야 한다.
Short Leash가 필요한 이유
okTurtles의 Short Leash 방식은 보안 중요 시스템에서 나온 실전 접근이다. YOLO 모드를 쓰지 않고, 권한 프롬프트에서 diff를 직접 검토하고, 하위 작업마다 커밋을 찍는다. 여러 병렬 에이전트가 코드를 쏟아내는 동안 개발자가 루프 밖에 있으면, 코드베이스에 대한 정신 모델이 무너진다는 것이 핵심 경고다. AI가 작성에 관여한 PR은 제출자가 라인 바이 라인으로 직접 검토하고, 사용 모델을 AI Disclosure로 명시하는 것도 팀 신뢰 구조의 일부다. 이건 AI를 불신해서가 아니라, 제출자가 자신이 올리는 코드를 이해하고 있다는 것을 팀에 증명하는 과정이다.
에이전트 실행 전 계약을 설계하라
모든 에이전트 실행 전에는 계약이 필요하다. 목표(활동이 아닌 달성할 결과), 범위, 비목표, 도구와 권한, 정지 조건, 증거(테스트·스크린샷·로그), 에스컬레이션 기준, 예산(시간·토큰). 이 여덟 항목이 빠진 채 에이전트를 돌리는 건, 요구사항 없이 주니어 개발자에게 PR을 열게 하는 것과 같다. Level 3 이상에서 정지 조건이 측정 가능하지 않으면 에이전트는 멈춰야 할 때를 모른다. '사용자 경험을 전반적으로 개선'은 목표가 아니다. 'time-to-interactive 1초 미만'이 목표다.
네 가지 안티패턴을 먼저 제거하라
팀에서 흔히 보이는 실패 패턴 네 가지가 있다. 첫째, Autonomy as status: 높은 레벨 에이전트 운영을 팀의 기술력 지표처럼 다루는 것. 검증이 뒷받침되지 않는 자율성은 능력이 아니라 리스크다. 둘째, Permission laundering: 승인 피로로 에이전트에게 필요 이상의 권한을 줘버리는 것. 샌드박스와 허용 명령 목록으로 경계를 강화해야 한다. 셋째, Summary substitution: 에이전트의 작업 요약이 리뷰를 대체하는 것. diff, 테스트, 로그가 함께 묶인 증거 패킷이 없으면 리뷰가 아니다. 넷째, Fleet cosplay: 수십 개 에이전트를 병렬 실행하면서 의존성 조율은 사람이 수동으로 하는 것. 이건 병렬화가 아니라 혼란의 병렬화다.
코드베이스 컨텍스트 설계도 자율성 결정의 일부다
에이전트에게 어느 수준을 맡길지 결정할 때 종종 빠뜨리는 요소가 있다. 에이전트가 코드베이스를 얼마나 잘 이해하고 있는가다. ctxpack 같은 도구가 다루는 문제—파일 번들링, 시크릿 마스킹, 토큰 예산 관리—는 단순한 편의 기능이 아니다. 에이전트에게 프로젝트 전체 구조를 일관된 형태로 제공하지 않으면, 높은 자율성을 부여해도 에이전트는 파편화된 컨텍스트 위에서 잘못된 가정을 쌓는다. 자율성 레벨은 에이전트가 가진 컨텍스트의 품질과 함께 결정돼야 한다.
한 번에 한 축씩, 보수적으로 올려라
실용적인 시작점은 단일 supervised 에이전트가 방어 가능한 성공 증거를 만드는 하나의 제한된 작업이다. 이후 읽기 중심 탐색 작업을 병렬화하고, 파일 소유권 규칙이 명확한 별도 worktree에서 쓰기 에이전트를 추가하고, 반복 자동화를 붙인다. 각 단계 상승은 새로운 실패 모드에 대응하는 새로운 안전장치를 요구한다. 단일 에이전트의 긴 실행은 컨텍스트 부패와 목표 이탈을, 병렬 에이전트는 merge conflict와 중복 결정을, managed-by-exception은 긴 리뷰 큐와 알림 피로를 만든다.
결국 에이전트 자율성 설계는 기술 선택이 아니라 운영 설계다. 팀 리드가 직접 각 작업의 위험도, 가역성, 검증 방식을 정의하지 않으면, 자율성 레벨은 벤더 기본값이나 팀원의 성향에 따라 제각각 운영된다. 내일 당장 팀에서 최근 에이전트를 활용한 작업 10개를 꺼내, 각각에 어떤 레벨을 부여했는지, 검증 증거는 무엇이었는지, 같은 레벨을 다시 적용하겠는지를 점검하는 것부터 시작하라. 그게 calibrated autonomy로 가는 첫 걸음이다.