에이전틱 자율성 레벨

에이전틱 엔지니어링을 둘러싼 대부분의 논의에서, 핵심은 프롬프팅에서 운영으로 넘어왔다. 지평선 너머로 안개 속 미래가 펼쳐진다. 소프트웨어 팩토리, 목표 기반 실행, 루프, 백그라운드 세션, 서브에이전트, 훅, 샌드박스, 에이전트를 승인하는 에이전트. 앞으로 제품을 만드는 많은 이들에게 이런 방식은 처음부터 당연한 기본값이 될 것이다. Claude Code와 Codex는 이 전환을 이미 정면으로 보여주고 있다.

엔지니어 입장에서는 리스크를 줄이고 되돌리기 쉬운 상태를 유지하기 위해 낮은 자율성을 택하는 경우도 있고, 목적이 명확한 작업이나 대규모 코드베이스를 병렬 에이전트 팀으로 안전하게 리팩터링할 때는 높은 자율성을 택하기도 한다. 어떤 작업을 맡길 때든 핵심 질문은 항상 같다. 이 작업에 어울리는 자율성 레벨은 무엇이고, 그 레벨을 정당화할 수 있는 검증 방식은 무엇인가?

현재 기술의 최전선에는 매니저 에이전트가 있다. 트리거가 발생하면 깨어나 하위 에이전트들에게 작업을 위임하면서 결과물을 지속적으로 검증하고, 사람의 판단이 반드시 필요한 결정 사항만 추려서 돌아오는 구조다. 이런 방식을 이미 도입한 팀들은 상시 유지되는 코드베이스 위에서 수백, 수천 개의 에이전트를 동시에 운용하고 있을 수 있다. 자율성에 대한 인식은 누구에게나 그렇듯, 이 규모가 어느 정도인지에 대한 체감은 사람마다 여전히 다르다.

가장 많이 거론되는 척도는 "Welcome to Gas Town"과 The Pragmatic Engineer에서 소개된 Steve Yegge의 단일 축 사다리다. 자신이 AI를 얼마나 네이티브하게 활용하는지 숫자 하나로 파악하고 싶다면 유용한 기준이다. 단일 에이전트에 대한 신뢰 수준을 알면, 이 사다리가 하나의 숫자로 위치를 알려준다. 아래가 그 한 버전이다.

2026년 초, 업무의 무게중심이 위임에서 오케스트레이션으로 막 이동하던 시점에는 이 사다리가 리스크를 측정하는 꽤 괜찮은 기준이었다. 하지만 지금은 다르다. 여러 에이전트를 동시에 운용할 수 있게 되면서, 중요성과 레버리지가 커진 역량들이 많아졌다. 단일 사다리 한 칸으로는 멀티 에이전트 역량을 제대로 표현할 수 없다.

실제로 내가 접한 자율성 관련 논의 대부분은, 사실 따로 다뤄져야 할 두 가지 질문을 뒤섞고 있다. 단일 에이전트를 얼마나 멀리, 얼마나 독립적으로 보낼 것인가, 그리고 여러 에이전트를 조율하는 역량이 얼마나 되는가.

이 두 차원을 분리해서 포착하기 위해, 두 축을 사용한다. 에이전시(agency)와 오케스트레이션(orchestration)이다.

에이전시 축에서 낮은 단계는 후보 행동을 제안하고 결정을 기다리는 수준이다.

중간 단계는 에이전트가 특정 작업을 수행하되 작업 범위를 스스로 한정하고, 진행 내용과 근거를 지속적으로 보고하여 사람이 방향을 조정할 수 있게 하는 수준이다.

높은 에이전시 단계에서 에이전트는 목표를 향해 나아가며 실험하고, 학습하고, 테스트하고, 문제 해결 방법을 모색하고, 막히면 질문하고, 다양한 접근을 시도하며, 이 모든 과정을 근거로 정리해 돌아온다.

오케스트레이션 축에서 낮은 단계는 에이전트 하나, 스레드 하나다. 중간 단계는 각자의 워크트리에서 독립적으로 작업하는 에이전트 여러 개가 서로 다른 목표를 향해 격리된 채로 움직이는 구조다. 높은 단계에서는 오케스트레이터가 백로그, 이슈 트래커, 스케줄, 혹은 여타 큐를 받아 지속적인 작업 흐름으로 전환하고, 사람은 문제가 생겼을 때만 개입하면 된다. 이른바 "예외 기반 관리(management by exception)"다. 이 개념을 반영한 제품과 기능으로는 다음이 있다.

• Claude Code의 /plan, /goal, /loop, /background, /batch, /code-review, /security-review 모드, 서브에이전트, 훅, 체크포인팅, 에이전트 위임 및 관리 방식, 백그라운드 세션, 에이전트 팀 패턴, /schedule 인수
• Codex의 로컬/클라우드 스레드, Goal 모드, 워크트리, Automations, 서브에이전트, 리뷰 패널, GitHub 코드 리뷰, 훅, 샌드박싱, Auto-review, rerun

이런 기능들은 단일 사다리에 담을 수 없다.

올라가는 길: 세 시대와 하나의 스택

사다리를 아래에서 위로 읽으면, 에이전시와 오케스트레이션을 동시에 올라가는 그림이 그려진다. 실제로 이 여섯 레벨은 우리 모두가 거쳐 가는 세 개의 구분된 시대를 나타낸다.

첫 번째 시대에서는 사람이 운전대를 잡고, 에이전트는 옆에서 돕되 방향 지시를 기다린다.

두 번째 시대에서는 에이전트가 범위가 정해진 작업이나 목표를 주도하지만, 사람은 여전히 곁에서 방향을 잡아주고 결과를 검증한다.

세 번째, 오케스트레이션 시대에서는 시스템이 전체 흐름을 직접 운영하며 여러 에이전트에 작업을 분배한다. 사람은 대부분 문제가 생겼을 때만 개입하면 된다. 바로 "예외 기반 관리"다.

이렇게 보면 구조가 단순해진다. 사다리에서의 수직 위치가 두 축을 깔끔하게 포착하기 때문이다(오케스트레이션은 사다리 위쪽에서만 본격적으로 등장한다). 결국 하나의 사다리를 꾸준히 오르는 것으로 정리된다. 그럼에도 이 여정은 우리 모두가 함께 겪고 있는 더 큰 전환의 일부다.

좋은 엔지니어링 하루는 여러 단계를 오가는 일을 포함한다. 하나의 작업을 진행하는 동안 시대를 몇 번씩 넘나드는 것은 지극히 자연스러운 일이다.

여섯 레벨 상세 설명

레벨 0: 보조(Assist)

에이전트가 제안을 내놓는다. 대부분 괜찮고 때로는 완벽하지만, 실행 여부는 항상 사람이 판단한다. 자동완성, 인라인 편집 제안, 혹은 아직 누구도 소유권을 가져가지 않은 변경사항을 채팅으로 논의하는 상황이 여기에 해당한다. 실수의 비용이 크거나, 변경 규모가 작거나, 스스로 판단을 형성해가는 중일 때 적합하다. 검증은 대부분 로컬에서 이루어진다.

레벨 1: 감독하의 실행(Supervised action)

에이전트가 대신 파일을 편집하거나 명령을 실행하되, 결과에 영향이 있는 작업은 먼저 확인을 구한다. 대부분의 사람들이 기본으로 취하는 자세다. 변경사항 적용 전에 승인을 받는 로컬 샌드박스 방식으로 진행할 수도 있고, 인터랙티브 세션으로 진행할 수도 있다. 각 승인은 해당 변경이 적용되어도 괜찮은지 독립적으로 판단하는 행위다. 실패 패턴은 승인 피로다. 무엇을 승인하는지와 무관하게 모든 승인이 똑같이 느껴지기 시작한다. 이를 해결하는 방법은 다양하다. diff를 꼼꼼히 살피거나, 휴리스틱을 적용하거나, 승인 전에 다른 사람과 확인하거나, 아예 에이전트에게 책임을 넘기는 방식이 있다. Codex의 Auto-review는 경계 조건에 대한 최종 승인을 별도의 리뷰어 에이전트에게 위임함으로써 이 문제를 해결한다.

레벨 2: 범위 한정 작업 위임(Scoped task delegation)

범위가 명확한 작업을 에이전트에게 넘긴다. 명확한 목표, 제약 조건, 완료 기준이 있어야 한다. 사람은 언제든 개입할 수 있는 거리에 있되, 대부분은 관여하지 않는다. 소프트웨어 엔지니어링 세계에서 가장 보편적인 방식이다. 검증의 무게중심이 사람(자리를 비우거나 잠을 자야 할 수 있다)에서 에이전트가 생산할 수 있는 근거 자료로 이동하고 있다. 통과된 자동화 테스트, 올바른 타입, 린트 제안, 스크린샷, 재현 단계, 예시 기반 출처 등이 그 근거가 된다.

레벨 3: 목표 기반 자율 실행(Goal-driven autonomy)

에이전트는 목표를 달성하기 위해 필요한 모든 것을 하며, 특정 조건이 충족될 때만 멈춘다. 프롬프트 모드에서는 프롬프트 자체가 목표가 된다(예: "이 페이지의 TTI(Time to Interactive)를 1초 미만으로 줄여줄 수 있어?"). Codex에서는 Goal 모드에 해당하며, 에이전트가 성공 조건을 충족할 때까지 계획→실행→테스트→리뷰 사이클을 반복한다. Claude Code에서는 /goal, /loop, /schedule 명령이 이에 해당한다. 이 레벨이 실질적인 의미를 가지려면, 종료 조건이 자동화할 수 있는 방식으로 측정 가능해야 한다.

"전반적인 사용자 경험 개선"이나 "코드베이스 테스트 가능성 향상"처럼 모호하고 추상적인 목표를 에이전트에게 던지지 않는 것이 좋다. 구체적이고, 측정 가능하며, 자동화할 수 있는 목표를 골라야 한다. 정적 분석을 피해가는 프로덕션 버그 찾기, 로드 시간 단축, explicit any 없는 엄격한 TypeScript 빌드 확보, 파악 가능하고 테스트를 통과하는 의존성만 남기도록 전체 의존성 정리 등이 그 예다. 마지막으로, 에이전트가 프로덕션 버그를 찾으려면 프로덕션과 유사한 환경에서 실행되어야 한다.

레벨 4: 병렬 위임(Parallel delegation)

여러 에이전트를 병렬로 운용한다. 각 에이전트는 작업의 격리된 일부를 담당한다. 이 레벨에서 가장 큰 병목은 분해(decomposition), 즉 위임할 작업을 적절한 단위로 나누는 일이다. 서브에이전트, 백그라운드 세션, /batch, 워크트리, 에이전트 팀 등이 이를 지원한다. 실패 패턴은 가짜 병렬화다. 여러 에이전트가 겹치는 범위를 동시에 작업하면, 더 많은 성과 대신 머지 충돌과 중복 결정만 생긴다. 이를 제대로 운용하려면 에이전트들이 서로 격리되어야 하며, 각자 담당 파일과 상태를 소유해야 한다. 각 에이전트는 자체 리뷰 큐도 가져야 한다. 또한 에이전트 실행에는 동시 운용 수에 비례하는 토큰 비용이 발생한다. 사람 입장에서도 오케스트레이션 비용(orchestration tax)이 있어, 에이전트를 몇 개 넘어서면 한 명 추가할 때의 한계 비용이 올라간다.

레벨 5: 예외 기반 관리 오케스트레이션(Managed-by-exception orchestration)

성공의 기준과 적용할 정책을 정의한다. 매니저 에이전트가 트리거(신규 이슈, 새 작업, 클럭 등)에 반응해 깨어나고, 워커 에이전트들에게 작업을 배분하며, 진행 상황을 모니터링하고, 결과물을 검증하고, 실패 시 재시도하며, 조건에 따라 더 역량 있는 에이전트나 사람에게 에스컬레이션하고, 결과를 취합해 작업 산출물(예: PR)과 근거를 외부 시스템에 전달한다. 팩토리로 생각하면 된다. 이슈 트래커나 백로그가 입력이고, 처리된 이슈와 수정된 버그들이 출력이다. 에이전트는 충분히 격리된 환경(필요시 탈출구 포함)에서 작동하며, 팩토리가 무엇을 해야 하는지는 오직 매니저 에이전트가 정의하는 운영 체계가 결정한다.

이 운영 체계의 설계는 사람의 몫이다. OpenAI는 Symphony를 위한 스펙을 제안한 바 있는데, Linear 보드를 중심에 두는 구조다. 각 이슈에는 전용 에이전트 워크스페이스가 부여되고, 에이전트는 자신의 워크스페이스에 있는 스펙 파일에 정의된 목표를 향해 지속적으로 진행 상황을 확인하며 나아간다. 사람의 리뷰는 근거가 생성되는 지점에서 수행할 수 있지만, 오케스트레이션 세계에서 가장 강력한 형태는 수백, 수천 개의 에이전트가 돌아가는 지속적인 에이전트 팩토리를 구축하는 것이다. 이 단계에 오르면 독립적인 검증이 점점 더 중요해진다. 구현자와 리뷰어를 분리하고, 테스트 실행과 QA를 분리하고, 보안 검사를 별도로 두고, 인수(acceptance)를 위한 독립적인 프로세스 게이트를 마련해야 한다.

리스크와 되돌릴 수 있는 가능성이 자율성의 상한선을 결정한다.

이전에 읽은 Anthropic 연구가 기억난다. Claude Code로 처리하기 가장 까다로운 작업들을 분석한 연구였는데, 에이전트가 사용자가 작업을 중단한 횟수보다 두 배 이상 많이 명확화를 요청한다는 결과가 있었다. 경험이 많은 사용자(750회 이상 세션 vs. 50회 미만)일수록 자동 승인을 더 많이 활용하고, 진행 상황을 지켜보면서 직접 개입하는 경향이 더 높았다.

같은 연구에서는 사람들이 Claude Code를 활용하는 방식에 대해 더 폭넓은 분석도 수행했다. 2025년 10월부터 2026년 4월 사이에 약 235,000명이 남긴 약 400,000개 세션을 분석했다. 각 세션에서 프롬프트당 요청하는 행동 수, 자동 승인 여부, 중단 빈도 등 사람이 내리는 결정을 파악할 수 있었다. 계획 관련 결정의 약 70%는 사람이 내리고, 실행의 약 80%는 Claude가 담당한다. 높은 자율성이란 사람을 루프 밖으로 밀어내는 것이 아니라, 모든 단계를 직접 수행하던 사람이 다음 방향을 결정하는 역할로 이동하는 것이다.

대규모 AI 시스템이 높은 자율성으로 운용되고 있는지 판단하려면 세 가지 질문을 던져야 한다.

• 에이전트가 잘못된 방향으로 가고 있다는 것을 얼마나 빨리 알 수 있는가?
• 에이전트가 한 작업을 얼마나 깔끔하게 되돌릴 수 있는가?
• 에이전트가 제대로 하고 있다는 것을 무엇으로 증명할 수 있는가?

세 질문 모두에 대한 답이 "늦게", "되돌리기 어렵게", "요약을 믿는 것으로"라면, 그것은 높은 자율성이 아니다.

에이전트를 실행하기 전에는 반드시 해당 실행이 무엇을 하려는 것인지 정의하는 계약이 선행되어야 한다.

목표(Goal): 달성하려는 것이 무엇인가(활동이나 기법이 아닌, 결과물로).

범위(Scope): 어떤 영역에서 작업하며, 어떤 기법을 사용할 수 있는가.

비목표(Non-goals): 목표에 포함되지 않는 것이 무엇인가.

도구 및 권한: 에이전트가 외부 세계와 어떻게 상호작용할 수 있는가. 종료 조건: 언제 멈출 것인가. 이상적으로는 측정 가능한 변수여야 한다.

근거(Evidence): 작업 완료 여부를 (에이전트와 무관하게) 확인할 수 있는 구체적인 테스트, 스크린샷, 로그, 데이터베이스 레코드 또는 기타 지표.

에스컬레이션: 어떤 상황에서 누가 개입하는가(에이전트를 실행하는 사람 포함).

예산: 작업에 투입할 시간, 노력, 토큰의 상한선(토큰은 대규모 AI 모델의 예산이다. 작업 시도 횟수 제한과 병렬화 수준 제한도 포함할 수 있다).

지표가 자율성을 조금 더 믿을 수 있게 만든다

사후에 지표를 정하는 것으로는 부족하다. 지표는 간결한 문서로 사전에 세워두어야 한다. 그렇게 하면 자율성이 더 믿음직스럽게 느껴지고, 결정에 필요한 신뢰의 도약이 조금 더 쉬워진다.

성공을 측정하는 방법은 다양하지만, 자율성 레벨별로 아래 지표들을 어떤 형태로든 추적해볼 것을 권한다.

• 평균 개입 간격(Mean time between interventions)
• 수용된 결과물과 함께 완료된 최장 무감독 실행 시간
• 샌드박스에서 실행된 행동 대비 에스컬레이션된 행동의 비율
• 자동 승인된 행동 대비 거부된 행동의 비율
• 사람의 지시 한 건당 평균 에이전트 행동 수
• 명확화 요청 비율 및 중단 요청 비율
• 수용된 변경사항 건당 리뷰 소요 시간
• 신뢰 레벨별 재작업 비율
• 신뢰 레벨별 결함 누출 비율
• 수용된 변경사항 건당 토큰 비용

이 지표들은 하나의 이야기를 들려준다. 사람의 핸드오프로만 바쁘게 돌아가는 단일 에이전트는 대시보드를 달아놓은 레벨 4다. 자동화된 인테이크, 재시도, 충분한 근거 없이는 움직이지 않는 신중한 에이전트는 진짜 게이트를 갖춘 레벨 5다.

준비 상태를 점검하라

작업을 리스크와 되돌리기 용이성 기준으로 분류하라. 자율성은 보수적으로 적용하되, 더 높은 레벨을 뒷받침하는 근거가 쌓일수록 단계를 높여라. 강력한 테스트와 리뷰어 에이전트로 보호되고 깔끔한 롤백 경로가 있는 결제 엔진 리팩터링은, 정답이 없는 문서 자동화 작업보다 훨씬 높은 자율성을 허용할 수 있다. 자율성 레벨은 작업의 이름이 아니라 검증 프로세스를 따라야 한다.

네 가지 안티패턴

주의하지 않으면 어떤 시스템이든 아래 네 가지 자율성 안티패턴에 쉽게 빠진다.

자율성을 지위로 삼기(Autonomy as status) — 에이전트의 자율성 수치가 무의미한 지위의 상징이 된다. 높은 자율성이 안전의 증거가 아닌 역량의 증거로 취급되면서, 검증이 뒷받침하는 수준 이상으로 에이전트를 밀어붙이게 된다. 해결책: 적절한 자율성 레벨을 찾아내고 과도한 위임을 끊임없이 경계하는 사람을 칭찬하고 보상하라.

권한 세탁(Permission laundering) — 승인 피로의 압박 속에서 AI 에이전트와 도구에 필요 이상으로 광범위한 접근 권한을 부여하게 된다. 해결책: 더 명확한 경계가 항상 답이다. 샌드박스 프로파일, 범위를 한정한 쓰기 루트, 허용 목록 기반 명령어, 훅, Auto-review 등을 활용하라.

요약으로 리뷰 대체하기(Summary substitution) — 에이전트의 작업 요약이 리뷰를 대신하면서, 요약만으로 충분하다고 가정하게 된다. 해결책: diff, 테스트, 로그, 스크린샷, 리뷰어 소견, 리스크, 미비 사항 등 완전한 수동 리뷰와 동일한 근거 패키지를 묶어 제공하되, 인지적으로 항복하지 않도록 주의하라.

플릿 코스프레(Fleet cosplay) — 수십 개의 에이전트가 병렬로 돌아가지만, 사람이 여전히 모든 의존성을 수작업으로 오케스트레이션하고 있다. 해결책: 공유 상태, 소유권 규칙, 더 나은 의존성 추적을 통해 수동 조율의 필요성을 점진적으로 줄여나가라. WIP 한도를 낮추면 조율 단계를 코드와 문서로 녹여내는 데 집중하게 되고, 결국 오케스트레이션이 자동화된다.

자가 점검 연습

최근에 에이전트와 함께 수행한 작업 10개를 돌아보라. 각 작업별로 적용한 자율성 레벨, 관련 리스크, 되돌리기 용이성, 검증 요건을 충족하기 위해 생산된 근거, 리뷰 소요 시간, 재작업 발생 여부, 그리고 다음에도 같은 자율성 레벨을 적용하는 것이 적절한지를 기록하라.

안전하게 올라가는 법

한 번에 한 축씩 올려라. 먼저 감독하의 단일 에이전트로 범위가 명확한 작업 하나를 맡겨 방어 가능한 성공 근거를 만들어내는 것에서 시작하라(충분히 깔끔하다면 자율성 레벨 1). 이후 세 방향으로 점진적으로 확장하면 된다. 읽기 위주의 탐색 작업은 병렬화하라(레벨 4). 파일 소유권이 제한된 별도의 워크트리에서 작업하는 쓰기 에이전트를 추가하라(레벨 4). 그 다음 반복 자동화를 더하고, 이슈나 음성 등 트리거 기반의 에이전트 주도 오케스트레이션으로 나아가라. 레벨을 하나 높일 때마다 새로운 안전장치가 필요하다(새로운 실패 모드가 생기기 때문이다).

각 위험 요소에 이름을 붙여두라. 단일 에이전트의 장기 실행은 목표 이탈, 컨텍스트 부패, 소통 단절, 목적 표류로 이어질 수 있다. 백그라운드 작업은 낡은 가정과 허술한 인계로 이어질 수 있다. 과도한 병렬 작업은 머지 충돌이나 중복 결정을 낳는다. 지나치게 많은 반복 작업은 조용한 토큰 낭비나 낡은 프롬프트로 이어진다. 예외 기반 관리는 긴 리뷰 큐와 알림 피로로 이어질 수 있다. 해결책은 더 맹목적으로 신뢰하는 것이 아니다. 범위를 좁히고, 더 나은 근거를 확보하고, 더 저렴한 롤백 경로를 만들고, 게이트를 강화하며, 소유권 규칙을 더 명확히 정의하라.

자율성 레벨 활용 가이드:

• 레벨 0은 섬세한 작업이거나 아직 판단을 형성하고 있는 단계에 가장 적합하다.
• 레벨 1은 잘 이해된 영역의 경계 안에서 이루어지는 대부분의 탐색 작업에 가장 적합하다.
• 레벨 2는 예상치 못한 의존성이나 복병이 있을 수 있다는 점을 감안한 대부분의 범위 한정 작업에 가장 적합하다.
• 레벨 3은 성공 조건을 충분히 명확하게 정의할 수 있는 경우에 가장 적합하다.
• 레벨 4는 각 성공 조건별로 작업을 깔끔하게 분리할 수 있을 때 가장 적합하다.
• 레벨 5는 각 성공 조건 간의 조율과 소통에 필요한 모든 것이 완전히 코드화되었을 때 가장 적합하다.

검증은 언제나 병목이 된다.

지금의 호기로운 분위기와 현재 도구 수준을 감안하더라도, AI 에이전트와 함께 일하는 엔지니어링 팀의 성숙한 자세는 교정된 자율성(calibrated autonomy)이다.

가까운 미래에는 언제 작업하고, 언제 검증하며, 언제 물어봐야 하는지를 스스로 아는 루프를 설계하고 싶어질 것이다. 하지만 적절한 자율성 레벨을 선택하고, 자율성의 어두운 이면을 막아낼 패턴과 방어 가능한 근거를 구축하는 것은 여전히 엔지니어의 역량으로 남는다.

참고: Pangram은 이 글을 100% 사람이 쓴 글로 분류합니다: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26