에이전트 자율성 수준

 (addyo.substack.com)
1P by GN⁺ | ★ favorite | 댓글과 토론
  • 에이전트형 엔지니어링은 프롬프트 작성보다 운영 설계에 가까워지고 있으며, 작업별로 허용할 자율성과 이를 뒷받침할 검증 방식을 함께 정해야 함
  • 단일 사다리형 모델은 한 에이전트에 대한 신뢰를 숫자로 표현하는 데는 유용하지만, 여러 에이전트를 동시에 다루는 역량은 agency와 orchestration 두 축으로 나눠 봐야 함
  • 0~5단계 모델은 제안만 하는 Assist부터 예외 상황에서만 사람이 개입하는 Managed-by-exception orchestration까지 이어지며, 상위 단계일수록 목표·범위·증거·권한·예산이 선명해야 함
  • Anthropic의 Claude Code 분석에서는 약 40만 세션과 약 23.5만 명의 사용 데이터를 통해 사람이 계획 결정의 약 70%를, Claude가 실행의 약 80%를 맡는 양상이 나타남
  • 성숙한 에이전트 활용은 높은 자율성을 과시하는 일이 아니라, 위험과 되돌릴 수 있는 정도에 맞춰 calibrated autonomy를 적용하고 검증 병목을 관리하는 데 달려 있음

프롬프트 작성에서 운영 설계로 이동하는 에이전트형 엔지니어링

  • 에이전트형 엔지니어링의 중심은 프롬프트 작성에서 운영 설계로 이동하고 있음
  • 소프트웨어 팩토리, 목표, 루프, 백그라운드 세션, 서브에이전트, 훅, 샌드박스, 에이전트가 에이전트를 승인하는 방식이 전면에 등장함
  • Claude Code와 Codex는 이런 변화를 보여주는 대표 제품으로 다뤄짐
  • 엔지니어는 위험을 줄이고 되돌리기 쉽게 만들기 위해 낮은 자율성을 쓰고, 명확한 활동이나 대규모 코드베이스 리팩터링에는 더 높은 자율성과 병렬 에이전트 플릿을 사용할 수 있음
  • 핵심 질문은 각 작업에 어떤 수준의 자율성을 허용할지, 그리고 어떤 검증이 그 수준을 방어할 수 있는지임

단일 사다리 대신 두 축으로 보는 자율성

  • Steve Yegge의 “Welcome to Gas Town”에서 언급된 단일 축 사다리는 한 에이전트에 대한 신뢰를 숫자로 표현하는 데 유용함
  • 2026년 초에는 작업이 위임에서 오케스트레이션으로 이동하는 상황에서도 단일 축이 위험 측정의 대략적 대리 지표로 작동했음
  • 여러 에이전트를 동시에 실행할 수 있게 되면, 단일 단계만으로는 다중 에이전트 역량을 설명하기 어려움
  • 자율성 논의는 서로 다른 두 질문을 자주 섞음
    • 단일 에이전트를 사람에게서 얼마나 멀리 보낼 수 있는가
    • 여러 에이전트를 얼마나 잘 조율할 수 있는가
  • 이를 분리하려면 두 축이 필요함
    • agency: 한 에이전트가 제안, 제한된 작업, 목표 달성을 얼마나 자율적으로 수행하는가
    • orchestration: 하나의 스레드부터 여러 작업 트리, 백로그·이슈 트래커·스케줄 기반의 지속적 작업까지 얼마나 조율하는가

agency와 orchestration의 의미

  • agency 축의 낮은 수준에서는 에이전트가 후보 행동을 제안하고 사람의 결정을 기다림
  • 중간 수준에서는 에이전트가 특정 작업을 수행하되 범위를 제한하고, 수행한 일을 증거와 함께 계속 보고해 사람이 조정할 수 있음
  • 높은 agency에서는 에이전트가 목표를 향해 실험, 학습, 테스트, 차단 상황 처리, 질문, 다른 접근 시도까지 수행하고 이를 증거로 되돌려줌
  • orchestration 축의 낮은 수준은 하나의 에이전트와 하나의 스레드임
  • 중간 수준에서는 여러 에이전트가 각자 분리된 worktree에서 서로 다른 목표를 수행함
  • 높은 수준에서는 오케스트레이터가 백로그, 이슈 트래커, 스케줄, 큐를 지속적인 작업으로 바꾸고, 사람은 실패 시에만 개입하는 management by exception 형태가 됨
  • 관련 기능과 제품 예시는 다음과 같음
    • Claude Code: /plan, /goal, /loop, /background, /batch, /code-review, /security-review, 서브에이전트, 훅, 체크포인트, 에이전트 위임과 관리 방식, 백그라운드 세션, 에이전트 팀 패턴, /schedule 인자
    • Codex: 로컬·클라우드 스레드, Goal mode, worktree, Automations, 서브에이전트, 리뷰 패널, GitHub 코드 리뷰, 훅, 샌드박스, Auto-review, rerun

세 시대와 여섯 단계

  • 사다리를 아래에서 위로 읽으면 agency와 orchestration을 동시에 올리는 것처럼 보임
  • 여섯 단계는 세 개의 시대로 나뉨
    • 사람이 운전석에 있고 에이전트는 보조하며 사람의 조작을 기다리는 시대
    • 에이전트가 제한된 작업이나 목표를 맡지만 사람이 조정하고 검증하는 시대
    • 시스템이 여러 에이전트에 작업을 배분하고, 사람은 문제가 생길 때 주로 개입하는 오케스트레이션 시대
  • 실제 엔지니어링에서는 하루 동안 여러 단계를 오가며 작업하는 것이 자연스러움

Level 0: Assist

  • 에이전트는 대체로 좋고 때로는 완벽한 제안을 하지만, 실행 여부는 항상 사람이 결정함
  • 예시는 자동완성, 인라인 편집 제안, 아직 누구도 소유하지 않은 변경을 채팅에서 논의하는 상황임
  • 비용이 큰 오류, 아주 작은 변경, 판단을 형성하는 중인 작업에 적합함
  • 검증은 대부분 로컬에서 이루어짐

Level 1: Supervised action

  • 에이전트가 대신 편집하거나 명령을 실행하지만, 중요한 실행 전에는 사람에게 허가를 요청함
  • 대부분의 사람이 쓰는 기본 자세에 가까움
  • 로컬 샌드박스에서 변경 적용 전 승인을 받거나, 대화형 세션에서 수행할 수 있음
  • 각 승인은 해당 변경을 적용해도 괜찮은지 확인하는 독립 검증으로 작동함
  • 주요 실패 모드는 승인 피로임
    • 무엇을 승인하든 모든 승인이 비슷하게 느껴질 수 있음
    • diff를 대충 훑거나, 휴리스틱을 따르거나, 다른 사람에게 확인하거나, 에이전트가 책임지도록 허용하는 방식으로 대응할 수 있음
  • Codex Auto-review는 경계 조건의 최종 승인을 별도 리뷰어 에이전트에 위임해 이 문제를 다룸

Level 2: Scoped task delegation

  • 제한된 작업을 에이전트에 넘기는 단계임
  • 작업에는 명확한 목표, 제약, 완료 상태의 작업 정의가 있어야 함
  • 사람은 가까이 머물며 중단할 수 있지만, 대부분 직접 관여하지 않음
  • 소프트웨어 엔지니어링에서 중심에 가까운 단계로 다뤄짐
  • 검증은 사람의 직접 확인에서 에이전트가 생성할 수 있는 증거로 이동함
    • 통과한 자동화 테스트
    • 적절한 타입
    • 린트 제안
    • 스크린샷
    • 재현 절차
    • 예시 기반 출처

Level 3: Goal-driven autonomy

  • 에이전트가 특정 조건이 충족될 때까지 목표 달성을 위해 필요한 일을 수행함
  • 프롬프트 모드에서는 프롬프트 자체가 목표가 됨
    • 예: “이 페이지의 time-to-interactive를 1초 미만으로 줄일 수 있는가?”
  • Codex에서는 Goal mode가 이에 해당하며, 에이전트가 plan -> act -> test -> review 단계를 반복하다가 성공 기준을 더 이상 만족하지 못하면 멈춤
  • Claude Code에서는 /goal, /loop, /schedule 명령이 이에 해당함
  • 이 수준이 유용하려면 정지 조건이 자동화 가능한 방식으로 측정 가능해야 함
  • “사용자 경험을 전반적으로 개선”하거나 “코드베이스를 더 테스트 가능하게 만들기” 같은 모호한 목표는 적합하지 않음
  • 더 적합한 목표는 구체적이고 측정 가능하며 자동화 가능해야 함
    • 정적 분석을 피해가는 프로덕션 버그 찾기
    • 로드 시간 줄이기
    • 명시적 any가 없는 엄격한 TypeScript 빌드 보장
    • 이해 가능하고 테스트를 통과하는 의존성만 남기도록 전체 의존성 분류
  • 프로덕션 버그를 찾으려면 에이전트가 프로덕션과 유사한 환경에 있어야 함

Level 4: Parallel delegation

  • 여러 에이전트가 병렬로 작업하는 단계임
  • 각 에이전트는 작업의 분리된 조각을 맡음
  • 가장 큰 병목은 어떤 조각을 위임할지 정하는 분해임
  • 지원 기능으로 서브에이전트, 백그라운드 세션, /batch, worktree, 에이전트 팀 등이 있음
  • 주요 실패 모드는 거짓 병렬성임
    • 여러 에이전트가 겹치는 조각을 동시에 다루면 더 많은 작업 대신 merge conflict와 중복 결정을 만들 수 있음
  • 잘 운영하려면 에이전트가 서로 격리되어야 함
    • 각자 소유한 파일과 상태가 있어야 함
    • 각자 리뷰 큐도 가져야 함
  • 에이전트마다 토큰 비용이 발생하며, 동시에 실행되는 에이전트 수에 비례함
  • 사람 쪽에서는 몇 개 이후부터 에이전트를 추가할 때의 한계 비용이 오케스트레이션 세금 때문에 증가함

Level 5: Managed-by-exception orchestration

  • 성공의 정의와 적용할 정책을 사람이 정하고, manager agent가 트리거에 따라 깨어나 작업을 분배함
  • 트리거 예시는 새 이슈, 새 작업, 시계임
  • manager agent는 작업자 에이전트를 배치하고, 진행 상황을 모니터링하고, 산출물을 검증하고, 실패 시 재시도함
  • 조건이 충족되면 더 유능한 에이전트나 사람에게 에스컬레이션하고, 결과를 집계해 PR 같은 작업 산출물과 증거를 외부 시스템에 반환함
  • 이 단계는 팩토리에 비유됨
    • 입력은 이슈 트래커나 백로그
    • 출력은 여러 해결된 이슈나 버그
  • 에이전트는 충분한 경계와 필요 시 탈출구가 있는 격리 환경에서 작업함
  • 이 팩토리가 무엇을 해야 하는지는 manager agent가 정의한 운영체제가 정함
  • OpenAI는 Symphony를 위한 spec을 제안했으며, Linear 보드를 중심에 둠
    • 각 이슈는 자체 에이전트 workspace를 가짐
    • 에이전트는 자기 workspace의 spec 파일에 정의된 목표를 향해 계속 진전하고 있는지 확인함
  • 오케스트레이션의 최전선은 수백 또는 수천 개 에이전트가 동작하는 지속적 에이전트 팩토리를 만드는 것임
  • 이 단계에서는 독립 검증이 더 중요해짐
    • 구현자와 리뷰어 분리
    • 테스트 실행자와 QA 분리
    • 보안 검사 분리
    • 수락을 위한 프로세스 게이트 분리

위험과 되돌릴 수 있는 정도가 자율성의 상한을 정함

  • Anthropic의 Claude Code 관련 연구에서는 가장 어려운 작업 일부에서 Claude Code가 사용자의 중단보다 두 배 이상 자주 명확화 질문을 했음
  • 경험 많은 사용자는 약 750개 세션을 가진 사용자로, 50개 미만 세션 사용자보다 자동 승인과 중단을 더 자주 활용하며 진행 상황을 지켜보는 경향이 있었음
  • Anthropic의 더 넓은 분석은 2025년 10월부터 2026년 4월까지 약 23.5만 명의 약 40만 세션을 다룸
  • 각 세션에서 사용자가 프롬프트마다 요청한 행동 수, 자동 승인한 항목, 중단 빈도 같은 결정을 파악할 수 있었음
  • 사람은 계획 결정의 약 70% 를 내리고, Claude는 실행의 약 80% 를 수행함
  • 높은 자율성은 사람을 루프 밖으로 빼는 것이 아니라, 사람이 매 단계를 수행하는 방식에서 다음 방향을 정하는 방식으로 이동하는 것임
  • 큰 AI 시스템이 높은 자율성으로 작동하는지 판단하려면 세 가지 질문이 필요함
    • 무엇을 잘못하고 있는지 얼마나 빨리 알 수 있는가
    • 하고 있는 일을 얼마나 깔끔하게 되돌릴 수 있는가
    • 하고 있는 일이 옳다는 것을 무엇이 증명하는가
  • 답이 “빠르게 알 수 없고, 되돌리기 어렵고, 요약을 믿어야 한다”라면 높은 자율성이 아님

에이전트 실행 전 계약에 들어가야 할 항목

  • 모든 에이전트 실행 전에는 무엇을 하려는지 정의하는 계약이 필요함
  • 계약에는 다음 항목이 포함되어야 함
    • 목표: 활동이나 기법이 아니라 달성하려는 결과
    • 범위: 작업할 도메인과 허용된 기법
    • 비목표: 목적에 포함되지 않는 것
    • 도구와 권한: 에이전트가 외부 세계와 상호작용하는 방식
    • 정지 조건: 언제 멈출지, 가능하면 측정 가능한 변수
    • 증거: 완료를 독립적으로 확인할 수 있는 테스트, 스크린샷, 로그, 데이터베이스 레코드 등
    • 에스컬레이션: 어떤 상황에서 누가 개입하는지, 누가 에이전트를 실행하는지
    • 예산: 시간, 노력, 토큰 한도
  • 토큰은 대형 AI 모델의 예산이며, 시도 횟수와 병렬성 정도에 대한 제한도 포함할 수 있음

지표는 자율성을 조금 더 신뢰 가능하게 만듦

  • 지표를 사후에 정하는 것만으로는 충분하지 않을 수 있음
  • 지표는 간결한 문서로 사전에 배치할 수 있고, 자율성을 더 신뢰 가능하게 만듦
  • 자율성 수준별로 추적할 수 있는 지표 예시는 다음과 같음
    • 개입 간 평균 시간
    • 수락된 작업 기준 최장 무인 실행 시간
    • 샌드박스에서 실행된 행동과 에스컬레이션된 행동의 비율
    • 자동 승인된 행동과 거절된 행동의 비율
    • 사람 지시 하나당 에이전트 행동의 평균 수
    • 명확화 요청률
    • 중단 요청률
    • 수락된 변경당 리뷰 시간
    • 신뢰 수준별 재작업률
    • 신뢰 수준별 결함 유출률
    • 수락된 변경당 토큰 비용
  • 사람이 넘겨주는 작업으로 계속 바쁜 단일 에이전트는 대시보드가 붙은 Level 4에 가깝고, 자동화된 접수·재시도·충분한 증거 없이는 진행하지 않는 보수적 에이전트는 실제 게이트가 있는 Level 5에 가까움

준비도와 자율성 수준 선택

  • 작업은 위험과 되돌릴 수 있는 정도에 따라 분류해야 함
  • 자율성은 보수적으로 적용하고, 더 높은 수준을 지지하는 증거가 쌓일 때만 올려야 함
  • 강한 테스트, 리뷰어 에이전트, 깔끔한 롤백 경로가 있는 결제 엔진 리팩터링은 정답 기준이 없는 문서 자동화 작업보다 더 높은 자율성을 지원할 수 있음
  • 자율성 수준은 작업 이름이 아니라 검증 프로세스를 따라야 함

네 가지 자율성 안티패턴

  • Autonomy as status

    • 에이전트의 자율성 등급이 의미 없는 지위 배지처럼 작동함
    • 높은 자율성이 안전성이 아니라 능력의 증거처럼 취급되고, 검증이 뒷받침하지 못하는 수준으로 에이전트가 실행됨
    • 올바른 자율성 수준을 선택하고 선을 넘지 않는 사람을 칭찬하고 보상해야 함

  • Permission laundering

    • 승인 피로 때문에 AI 에이전트와 도구에 필요 이상으로 넓은 접근 권한을 부여함
    • 샌드박스 프로필, 범위가 제한된 쓰기 루트, 허용 명령 목록, 훅, Auto-review 같은 경계를 강화해야 함

  • Summary substitution

    • 에이전트의 작업 요약이 리뷰를 대체함
    • 수동 리뷰와 같은 증거 패킷을 함께 묶어야 함
    • diff, 테스트, 로그, 스크린샷, 리뷰어 발견 사항, 위험, 빈틈이 포함될 수 있음

  • Fleet cosplay

    • 수십 개 에이전트를 병렬 실행하지만 사람이 모든 의존성을 계속 수동으로 조율함
    • 공유 상태, 소유권 규칙, 더 나은 의존성 추적이 수동 조율 필요를 줄임
    • 더 작은 WIP 제한은 조율 단계를 인코딩하고 문서화하는 데 집중하게 만들어 오케스트레이션 자동화로 이어질 수 있음

안전하게 올라가는 방법

  • 최근 에이전트 도움을 받은 작업 10개를 검토하는 보정 연습이 제안됨
    • 각 작업의 자율성 수준
    • 위험
    • 되돌리기 쉬운 정도
    • 검증 요건을 만족하기 위해 생성된 증거
    • 리뷰 시간
    • 재작업 여부
    • 다음에도 같은 자율성 수준이 적합한지
  • 한 번에 한 축씩 올라가야 함
  • 시작점은 단일 supervised agent가 방어 가능한 성공 증거를 만드는 하나의 제한된 작업을 수행하는 형태임
  • 이후 세 방향으로 점진적으로 확장함
    • 읽기 중심 탐색 작업을 병렬화함
    • 제한된 파일 소유권 규칙을 가진 별도 worktree에서 쓰기 에이전트를 추가함
    • 반복 자동화를 추가한 뒤 이슈나 음성 등에 기반한 에이전트 주도 오케스트레이션을 추가함
  • 각 단계 상승은 새로운 실패 모드에 대응하는 새로운 안전장치를 요구함
  • 실패 모드는 다음과 같음
    • 긴 단일 에이전트 실행: 드리프트, 컨텍스트 부패, 누락된 커뮤니케이션, 목표 이탈
    • 백그라운드 작업: 오래된 가정, 약한 인수인계
    • 과도한 병렬 작업: merge conflict, 중복 결정
    • 과도한 반복 작업: 조용한 토큰 지출, 오래된 프롬프트
    • managed-by-exception: 긴 리뷰 큐, 알림 피로
  • 더 세게 신뢰하는 방식이 아니라 범위를 좁히고, 더 나은 증거를 확보하고, 더 싼 롤백 경로를 만들고, 게이트를 강화하고, 소유권 규칙을 더 명확히 해야 함

단계별 적합한 사용처

  • Level 0은 섬세한 작업과 판단을 형성하는 중인 상황에 가장 적합함
  • Level 1은 잘 이해된 경계에 가까운 대부분의 탐색에 적합함
  • Level 2는 알려지지 않은 의존성과 예상 못 한 문제가 있을 수 있는 대부분의 제한된 작업에 적합함
  • Level 3은 성공 조건을 충분히 명확하게 말할 수 있는 경우에 적합함
  • Level 4는 작업을 성공 조건에 따라 깔끔하게 나눌 수 있을 때 적합함
  • Level 5는 여러 성공 조건 사이에 필요한 조율과 커뮤니케이션이 완전히 인코딩된 뒤에 적합함

검증은 계속 병목으로 남음

  • 현재의 자신감과 도구 수준에도 불구하고, AI 에이전트와 일하는 성숙한 엔지니어링 팀의 자세는 calibrated autonomy임
  • 가까운 미래에는 언제 작업하고, 언제 검증하고, 언제 질문할지 아는 루프를 설계해야 함
  • 엔지니어의 역량은 적절한 자율성 수준을 고르고, 그 어두운 면을 막는 패턴과 방어 가능한 증거를 만드는 데 계속 놓임

함께 보면 좋은 글 β