에이전트 자율성, 단일 등급이 아닌 agency와 orchestration 두 축으로 다시 설계하기

2026년 7월 GeekNews에 공유된 에이전트 자율성 수준 주제는, AI 에이전트를 도입한 조직이 흔히 빠지는 함정을 정면으로 다룬다. 많은 팀이 자사 에이전트에 단 하나의 자율성 점수를 매기고 그 숫자만으로 위험을 판단하려 든다는 점이다. 그러나 실제 운영 데이터는 자율성을 다축으로 봐야만 의미 있는 통제가 가능해진다는 점을 보여준다.

에이전트 자율성, 왜 숫자 하나로 보면 안 되는가

단일 자율성 등급 모델은 직관적이지만, 현실의 에이전트 운영을 왜곡하는 경향이 있다. 한 에이전트가 스스로 결정을 잘 내리는지(agency)와, 여러 에이전트가 협업할 때 어떻게 조율되는지(orchestration)는 본질적으로 다른 문제이기 때문이다. 이 두 축을 합쳐 평균 점수 하나로 환원하면 실제 위험은 낮은데 점수만 높게 나오거나, 반대로 개별 판단은 안전하지만 협업 단계에서 사고가 나는 경우를 모두 가려버릴 수 있다.

agency와 orchestration 두 축으로 다시 정의하기

agency는 개별 에이전트가 한 작업 안에서 얼마나 독립적으로 목표를 설정하고, 도구를 선택하고, 결과를 결정할 수 있는지를 뜻한다. orchestration은 여러 에이전트 또는 에이전트와 사람이 결합된 시스템에서 누가 어떤 순서로 작업에 개입하고, 누가 승인과 예외 처리에 대한 권한을 가지고 있는지를 뜻한다. agency가 높아도 orchestration 설계가 비어 있으면 시스템 전체는 통제 불능 상태가 될 수 있으며, 반대로 orchestration이 정교해도 개별 에이전트의 agency가 낮으면 실질적으로는 자동화의 이점을 누리지 못한다. 두 축을 분리해 평가해야만, 조직은 각 작업 단위에서 어느 쪽을 강화하고 어느 쪽을 제약할지 정교하게 결정할 수 있는 것으로 분석된다.

0에서 5단계 자율성 등급 체계 해부

원문에서 제시하는 자율성 0에서 5단계 모델은 Assist에서 시작해 Managed-by-exception orchestration까지 이어진다. 이 모델의 핵심은 단계가 높을수록 에이전트가 더 많은 결정을 스스로 내린다는 사실만 있는 것이 아니라, 운영자가 더 엄격한 통제 정보를 사전에 제공해야 한다는 점이다. 단계가 오를수록 목표, 범위, 증거, 권한, 예산이라는 다섯 가지 요소가 함께 명확해져야 한다.

상위 단계로 올라갈수록 강해지는 통제 요구

아래 표는 단계별 핵심 통제 요구를 정리한 것이다. 원문에 명시된 0에서 5단계 분류 체계를 그대로 유지하되, 운영자가 반드시 사전에 정의해야 할 요소를 함께 표기했다.

단계 3을 넘어가면 단순히 에이전트의 능력만 보는 시각으로는 부족하다. 단계 4 이상에서는 여러 에이전트 간의 역할 분담과 책임 소재가 모호해지기 쉽기 때문에, 원문은 Managed-by-exception orchestration 단계에서 전사 차원의 거버넌스 체계를 요구한다. 즉 자율성 단계 상승은 곧 운영 부담 상승과 등가 관계에 있다고 해석된다.

Claude Code 데이터가 보여준 실제 역할 분담

Anthropic이 Claude Code를 통해 공개한 사용 패턴 데이터를 원문이 인용한다. 약 40만 세션, 약 23.5만 명 규모에서 나타난 분담 비율은 매우 구체적이다. 계획 결정의 약 70퍼센트는 사람이, 실행의 약 80퍼센트는 Claude가 담당한 것으로 나타난다는 점이다. 이 수치는 단일 세션이 아닌 누적 사용 데이터에서 도출된 것이므로 일반화는 신중해야 하지만 방향성은 분명하다.

계획 70퍼센트 사람 vs 실행 80퍼센트 Claude의 함의

이 분담 비율은 두 가지를 동시에 시사한다. 첫째, 사용자는 에이전트에게 작업의 방향과 종료 조건을 정의하는 역할을 적극 유지하고 있다는 점이다. 둘째, 실제 코드 작성, 명령 실행, 검색, 파일 조작과 같은 반복적이고 경계가 명확한 작업은 에이전트가 대부분을 떠맡고 있다는 점이다. 조직이 이 패턴을 모르고 에이전트에게 계획 단계까지 일임하면 agency는 인위적으로 높아지고 orchestration은 사실상 무너질 수 있는 결과로 낳게 된다. 반대로 실행 단계마저 사람이 매번 승인하면, 단계 3 이상으로 갈 수 있는 구조적 이점을 잃는다. 따라서 자율성 단계는 사람의 계획 통제력과 에이전트의 실행 능력이 균형을 이루는 지점에서 단계적으로 올려야 하는 것으로 보인다.

작업별 자율성 운영 설계 체크리스트

에이전트형 엔지니어링의 본질은 프롬프트 작성 그 자체가 아니라, 작업 단위로 자율성의 범위와 검증 방식, 예외 처리 경로를 함께 정의하는 운영 설계에 있다. 다음 체크리스트는 원문이 강조한 작업별 자율성 설계 원칙을 실무 언어로 정리한 것이다.

• 작업 분류: 읽기 전용, 쓰기 있음, 외부 시스템 호출, 비용 발생 작업 등으로 분리한다.
• 자율성 단계 매핑: 각 분류에 0에서 5단계 중 어디에 해당하는지 명시적으로 부여한다.
• 승인 경로 정의: 단계 2 이상은 사람 승인 지점, 단계 4 이상은 에스컬레이션 라인을 문서화한다.
• 증거 수집: 도구 호출 로그, 입력값, 출력값, 영향 범위를 사후 검증 가능하도록 보존한다.
• 롤백 절차: 단계 3 이상은 실행 전 롤백 절차를 미리 정의하고, 실제 롤백이 가능한지 주기적으로 검증한다.
• 예산 한도: API 비용, 호출 횟수, 외부 서비스 사용량에 상한을 두고 초과 시 자동 중단한다.

검증 하니스 설계 포인트

검증 하니스는 단순한 단위 테스트가 아니라, 에이전트의 의사결정 경로 전체를 감싸는 안전망이다. 핵심은 평가 기준이 결과물 품질만이 아니라 의사결정 과정의 적절성까지 포함해야 한다는 점이다. 예를 들어, 코드를 작성한 에이전트가 단계 3 이상에서 자율적으로 동작했다면, 작성된 코드가 사양을 만족하는지뿐 아니라, 코드를 생성하기 위해 어떤 도구를 어떤 순서로 호출했는지, 권한 범위 밖의 시도는 없었는지를 함께 기록해야 한다. 이 정보가 있어야만 사후에 자율성 단계 조정의 근거가 만들어진다. 추가적인 설계 패턴과 예시는 addyo 서브스택 원문에서 더 깊이 다루고 있다.

실무 적용 가이드와 리스크 관리

자율성 단계를 한 단계라도 올리면, 그에 비례하는 안전장치가 반드시 함께 강화되어야 한다. 단계 상승의 이점을 누리면서 리스크를 통제 가능한 수준으로 유지하는 가장 현실적인 방식은 단계적 롤아웃이다. 먼저 샌드박스 환경에서 단계 2까지 검증한 뒤, 제한된 프로덕션 트래픽에서 단계 3을 시험하고, 그 결과를 근거로 단계 4 이상의 다중 에이전트 조정을 도입한다. 이때 사람과 AI의 역할 분담을 Claude Code 사용 데이터의 패턴처럼 계획은 사람, 실행은 에이전트가 맡는 구조에서 시작하면, 운영 부담을 최소화하면서도 통제력을 유지할 수 있다.

자율성 단계 상승 시 반드시 같이 강화해야 할 안전장치

• 관측 가능성: 에이전트의 모든 도구 호출과 결정 사유를 로그로 남기고 검색 가능하게 보관한다.
• 최소 권한 원칙: 단계가 오를수록 권한을 늘리기보다, 작업별로 필요한 최소 권한만 부여하고 만료 시점을 둔다.
• 정기 재검토: 자율성 단계는 한 번 정해지면 끝이 아니라, 사고 사례와 지표 변화에 따라 강등하는 방향의 재검토도 포함한다.
• 에스컬레이션 채널: Managed-by-exception orchestration 단계에서는 예외가 발생했을 때 사람에게 즉시 도달하는 경로가 항상 살아 있어야 한다.

결국 AI 에이전트의 자율성은 높으면 좋다는 단선적 사고에서 벗어나, 작업 단위에서 agency와 orchestration을 분리해 평가하고, 그에 맞는 검증 하니스를 붙이는 것이 운영의 핵심이다. 이 프레임 위에 0에서 5단계 자율성 등급과 Claude Code의 실제 사용 데이터에서 나타난 역할 분담을 함께 얹으면, 조직은 에이전트 도입의 속도와 안전성 사이에서 균형 잡힌 결정을 내릴 수 있을 것으로 보인다.

참고 출처: GeekNews – 에이전트 자율성 수준, addyo.substack.com 원문