에이전트 엔지니어링에 대한 대부분의 논의에서, 핵심은 프롬프트에서 운영으로 바뀌었습니다. 다음은 안개 속을 들여다보는 프런티어입니다: 소프트웨어 팩토리, 목표, 루프, 백그라운드 세션, 서브에이전트, 훅, 샌드박스, 에이전트 승인 에이전트. 미래의 많은 창작자들에게 이러한 동작은 제품 출시 첫날부터 내장될 것입니다: Claude Code와 Codex는 이러한 변화를 직접적으로 보여줍니다.
엔지니어 관점에서, 위험을 제한하고 되돌리기 쉽게 하려면 낮은 자율성을 사용하지만, 명확한 활동에는 더 높은 자율성을 사용하고, 대규모 코드베이스를 안전하게 리팩터링하는 병렬 에이전트 그룹을 사용할 것입니다. 작업에 대한 핵심 질문은 항상: 이 작업에는 어떤 수준이 적합하며, 그 수준을 방어 가능하게 만드는 검증은 무엇인가? 입니다.
프런티어의 최전선은 트리거에 의해 깨어나서 출력을 지속적으로 검증하면서 도우미에게 위임하고, 인간이 결정해야 하는 사항만을 반환하는 매니저 에이전트입니다. 이러한 종류의 설정을 사용하는 사람들은 이미 수백 또는 수천 개의 에이전트를 운영하고 있을 수 있으며, 주로 상시 업데이트되는 코드베이스에서 작동합니다. 자율성에 대한 대부분의 사고와 마찬가지로, 규모를 인식하는 방식은 여전히 사람마다 다릅니다.
가장 자주 언급되는 척도는 Steve Yegge의 단일 축 사다리로, "Welcome to Gas Town"과 Pragmatic Engineer에서 언급되었습니다. 이는 자신이 얼마나 AI 네이티브인지 알려주는 숫자를 원한다면 좋은 참고 자료입니다. 이 사다리는 단일 에이전트에 대한 신뢰도를 측정하는 단일 숫자를 제공합니다. 다음은 그 버전 중 하나입니다:
2026년 초, 위임이 오케스트레이션으로 이동하기 시작했을 때에도 이는 위험을 측정하는 상당히 좋은 지표였습니다. 그러나 오늘날, 한 번에 여러 에이전트를 실행할 수 있을 때 많은 기술 세트가 더 큰 중요성과 영향력을 가질 수 있습니다. 단일 단계로는 멀티 에이전트 기술을 배치할 수 없습니다.
대신, 제가 본 거의 모든 자율성 논쟁은 분리되어야 할 두 가지 질문을 혼동합니다: 이 단일 에이전트를 우리로부터 얼마나 멀리 보낼 것인가, 그리고 많은 에이전트를 조정하는 우리의 능력은 무엇인가?
이 두 가지 차원을 별도로 포착하기 위해 두 가지 축을 사용하겠습니다: 에이전시와 오케스트레이션.
에이전시 축에서 낮음은 후보 작업을 제안하고 결정을 기다리는 것을 포함합니다.
중간은 에이전트가 특정 작업을 수행하지만 범위를 제한하고, 수행한 작업을 증거와 함께 지속적으로 보고하여 계속 조정할 수 있도록 하는 것을 의미합니다.
높은 에이전시 끝에서 에이전트는 목표를 향해 작업하고, 실험하고, 학습하고, 테스트하고, 문제 해결 방법을 찾고, 막히고, 질문하고, 다른 접근 방식을 시도하며, 이 모든 작업을 증거로 반환합니다.
오케스트레이션 축에서 낮음은 하나의 에이전트, 하나의 스레드를 의미합니다. 중간에서는 여러 에이전트가 각자 자신의 작업 트리에서 작업하며, 아마도 다른 목표를 향해 작업하지만 격리되어 있습니다. 높은 끝에서는 백로그, 이슈 트래커, 일정 또는 기타 큐를 가져와 지속적인 작업으로 전환할 수 있는 오케스트레이터가 있으며, 실패할 때만 개입하면 됩니다: "예외에 의한 관리". 이러한 아이디어를 통합한 제품 및 기능은 다음과 같습니다:
- Claude Code의 /plan, /goal, /loop, /background, /batch, /code-review, /security-review 모드, 서브에이전트, 훅, 체크포인팅, 에이전트 위임 및 관리 관행, 백그라운드 세션, 에이전트 팀 패턴, /schedule 인수
- Codex의 로컬/클라우드 스레드, Goal 모드, 작업 트리, Automations, 서브에이전트, 검토 창, GitHub 코드 리뷰, 훅, 샌드박싱, Auto-review 및 재실행
이러한 기능은 단일 사다리에 맞지 않습니다.
등반: 세 시대와 단일 스택
사다리를 아래에서 위로 읽는다면, 에이전시와 오케스트레이션을 동시에 오르는 것을 상상하는 것입니다. 실제로 여섯 단계는 우리 모두가 거치는 세 개의 별도 시대를 나타냅니다:
첫째, 당신이 운전석에 있고 에이전트는 대부분 도움만 주며, 당신이 조종할 때까지 기다립니다.
둘째, 에이전트가 제한된 작업이나 목표를 책임지지만, 당신은 여전히 주변에서 조종하고 검증합니다.
셋째, 오케스트레이션 시대에는 시스템이 쇼를 운영하고, 많은 에이전트에게 작업을 분배할 수 있으며, 당신은 대부분 문제가 발생할 때만 개입하면 됩니다: "예외에 의한 관리".
이렇게 하면 사다리의 수직 위치가 두 축을 깔끔하게 포착하기 때문에(오케스트레이션은 상단 근처에서만 시작됨) 단계를 통한 단일 꾸준한 등반으로 남게 되어 더 간단해집니다. 그럼에도 불구하고, 이 등반은 여전히 우리 모두가 겪고 있는 변화의 일부입니다.
좋은 엔지니어링 하루는 여러 단계를 건드리는 것을 포함하며, 때로는 그 이상입니다. 작업 과정에서 시대를 몇 번 전환하는 것은 정상입니다.
여섯 단계 상세 설명
레벨 0: 지원
에이전트는 대부분 좋고 종종 완벽한 제안을 하지만, 당신은 항상 그것들이 실행하기에 충분히 좋은지 결정합니다. 자동 완성, 인라인 편집 제안, 또는 아직 누구도 소유권을 주장하지 않은 변경 사항에 대해 채팅 세션에서 논의하는 것을 생각해보세요. 비용이 많이 드는 오류, 사소한 변경, 또는 당신의 판단을 형성할 때 사용하세요. 검증은 대부분 로컬에서 이루어집니다.
레벨 1: 감독된 작업
에이전트가 당신을 대신하여 편집하거나 명령을 실행하며, 중요한 작업을 실행하기 전에 당신에게 묻습니다. 이것은 대부분의 사람들에게 기본적인 자세입니다. 변경 사항을 적용하기 전에 승인이 필요한 로컬 샌드박스에서 수행할 수 있습니다. 각 승인은 변경 사항을 적용해도 괜찮다는 독립적인 검증입니다. 또는 대화형 세션에서 수행할 수 있습니다. 실패 모드는 승인 피로입니다. 모든 승인은 승인하는 대상에 관계없이 동일하게 느껴집니다. diff를 자세히 살펴보거나, 몇 가지 휴리스틱을 따르거나, 승인 전에 다른 사람과 확인하거나, 에이전트가 책임을 지도록 동의함으로써 해결할 수 있습니다. Codex Auto-review는 경계 조건의 최종 승인을 별도의 검토자 에이전트에 위임하여 이 문제를 해결합니다.
레벨 2: 범위가 지정된 작업 위임
제한된 작업을 에이전트에 넘깁니다. 해당 작업은 명확한 목표, 제약 조건, 그리고 완료된 상태에 대한 작업 정의를 가집니다. 당신은 근처에 머물며 중단할 수 있지만, 대부분 관여하지 않습니다. 이것은 소프트웨어 엔지니어링 세계의 중심입니다. 검증은 당신(휴식과 수면이 필요할 수 있음)에서 에이전트가 생성할 수 있는 증거(자동화된 테스트 통과, 적절한 타입, 린트 제안, 스크린샷, 재현 단계, 예시를 통한 출처 등)로 이동하고 있습니다.
레벨 3: 목표 기반 자율성
에이전트는 목표를 달성하기 위해 필요한 모든 것을 하며, 어떤 조건이 충족될 때만 멈춥니다. 프롬프트 모드에서는 프롬프트 자체가 목표가 됩니다(예: "이 페이지의 time-to-interactive를 1초 미만으로 줄일 수 있나요?"). Codex에서는 Goal 모드입니다. 에이전트는 성공 기준을 충족할 때까지 plan->act->test->review 단계를 반복합니다. Claude Code에서는 /goal, /loop, /schedule 명령어입니다. 이 레벨이 유용하려면 중지 조건이 자동화 가능한 방식으로 측정 가능해야 합니다.
에이전트에게 "일반적으로 사용자 경험 개선" 또는 "코드베이스를 더 테스트 가능하게 만들기"와 같은 모호하고 막연한 목표를 요청하지 마세요. 구체적이고 측정 가능하며 자동화된 것을 선택하세요: 정적 분석을 피해가는 프로덕션 버그 찾기, 로드 시간 줄이기, 명시적인 any가 없는 엄격한 TypeScript 빌드 보장, 이해하고 테스트를 통과하는 것만 유지하도록 모든 종속성 분류 등. 그리고 마지막으로, 프로덕션 버그를 찾으려면 에이전트가 프로덕션과 유사한 환경에 있어야 합니다.
레벨 4: 병렬 위임
많은 에이전트에서 병렬로 작업합니다. 각 에이전트는 작업의 격리된 조각에서 작업합니다. 이 레벨에서 가장 큰 병목 현상은 분해입니다. 즉, 위임할 올바른 조각을 정의하는 것입니다. 지원 도구는 다음과 같습니다: 서브에이전트, 백그라운드 세션, /batch, 작업 트리, 에이전트 팀 등. 실패 모드는 거짓 병렬 처리입니다. 한 번에 겹치는 조각에 대해 많은 에이전트를 실행하면 더 많은 작업 대신 병합 충돌과 중복 결정이 발생합니다. 이를 잘 수행하려면 에이전트가 서로 격리되어야 하며, 각자 자신의 파일과 상태를 소유해야 합니다. 각 에이전트는 자체 검토 큐도 가지고 있어야 합니다. 마지막으로, 각 에이전트는 동시에 실행되는 에이전트 수에 비례하여 비용(소비된 토큰 측면에서)을 발생시킵니다. 인간 측면에서는 오케스트레이션 비용으로 인해 몇 개 이후에는 에이전트를 추가하는 한계 비용이 증가합니다.
레벨 5: 예외에 의한 관리 오케스트레이션
성공의 모습과 적용해야 할 정책을 정의합니다. 매니저 에이전트는 트리거(예: 새 이슈, 새 작업, 시계)에 따라 깨어나고, 작업자 에이전트를 파견하고, 진행 상황을 모니터링하고, 출력을 검증하고, 실패 시 재시도하고, 조건이 충족되면 더 유능한 에이전트나 인간에게 에스컬레이션하고, 결과를 집계하고, 궁극적으로 작업 결과물(예: PR)과 증거를 외부 시스템에 반환합니다. 공장을 생각해보세요. 이슈 트래커 또는 백로그가 입력이고, 공장의 제품이 출력입니다(즉, 많은 수정된 이슈, 버그). 에이전트는 많은 벽(필요한 경우 탈출구)이 있는 적절히 격리된 환경에서 작업하며, 매니저 에이전트가 정의한 운영 체제만이 공장이 수행해야 할 작업을 정의합니다.
이 운영 체제의 설계는 인간에게 맡겨집니다; OpenAI는 중심에 Linear 보드가 있는 Symphony에 대한 사양을 제안했습니다. 각 이슈는 자체 에이전트 작업 공간을 얻고, 에이전트는 자체 작업 공간의 사양 파일에 정의된 목표를 향해 진행하고 있는지 지속적으로 확인합니다. 인간 검토는 증거가 생성되는 고도에서 수행될 수 있지만, 프런티어(즉, 오케스트레이션 세계에서 가장 강력한 것)는 수백 또는 수천 개의 에이전트로 지속적인 에이전트 공장을 구축하는 것입니다. 등반의 이 시점에서는 독립적인 검증이 점점 더 중요해집니다. 별도의 구현자와 검토자, 별도의 테스트 실행자와 QA, 별도의 보안 검사, 승인을 위한 별도의 프로세스 게이트.
위험과 되돌리기 가능성이 한계를 설정합니다.
Claude Code의 가장 어려운 작업 중 일부에 대한 초기 Anthropic 연구를 읽은 기억이 납니다. 이 연구에서 에이전트는 사용자가 중단한 것보다 두 배 이상 자주 설명을 요청했습니다. 경험이 풍부한 사용자(~750 세션 대 50 미만)는 진행 상황을 주시하면서 자동 승인 및 중단할 가능성이 더 높았습니다.
또한 사람들이 Claude Code를 사용하는 방식에 대한 광범위한 분석을 수행했습니다. 2025년 10월에서 2026년 4월 사이에 약 235,000명의 사람들로부터 약 400,000개의 세션을 살펴보았습니다. 각 세션에서 프롬프트당 요청하는 작업 수, 자동 승인하도록 선택한 작업, 중단 빈도 등 사람이 내리는 결정을 파악할 수 있었습니다. 사람들은 계획 결정의 약 70%를 하지만, Claude는 실행의 약 80%를 수행합니다. 높은 자율성은 사람들을 루프에서 배제하는 것이 아니라, 모든 단계를 직접 수행하는 것에서 다음에 어느 방향으로 갈지 결정하는 것으로 이동하는 것입니다.
대규모 AI 시스템이 높은 자율성으로 운영되고 있는지 확인하려면 세 가지 질문을 해야 합니다:
- 그것이 무엇을 하고 있는지에 대해 우리가 틀렸다는 것을 얼마나 빨리 알 수 있을까요?
- 그것이 하는 일을 얼마나 깔끔하게 취소할 수 있을까요?
- 그것이 하는 일에 대해 우리가 옳았다는 것을 증명할 수 있는 것은 무엇일까요?
세 가지에 대한 답변이 모두: 빠르지 않음, 매우 어려움, 요약을 신뢰함이라면, 그것은 높은 자율성이 아닙니다.
에이전트의 모든 실행은 그것이 수행하려는 작업을 정의하는 계약이 선행되어야 합니다.
목표: 달성하려는 것(활동이나 기술이 아닌 결과).
범위: 운영하는 도메인과 허용되는 기술.
비목표: 목표의 일부가 아닌 것.
도구 및 권한: 에이전트가 세상과 상호 운용할 수 있는 방법. 중지 조건: 중지 시점; 이상적으로는 측정 가능한 변수.
증거: 특정 테스트, 스크린샷, 로그, 데이터베이스 레코드 또는 무언가가 완료되었음을 확인하는 데 사용할 수 있는 기타 지표(에이전트와 독립적).
에스컬레이션: 어떤 상황에서 누가 관여하는지(에이전트를 실행하는 사람 포함).
예산: 작업에 투입할 시간, 노력 및 토큰의 한도(토큰은 대규모 AI 모델의 예산입니다. 작업을 시도할 수 있는 횟수 제한과 병렬 처리 정도 제한을 포함할 수도 있습니다).
메트릭은 자율성을 조금 더 안정적으로 만듭니다.
사후에 메트릭을 결정하는 것만으로는 충분하지 않을 수 있습니다. 메트릭은 간결한 문서에 미리 마련될 수 있습니다. 그리고 그것은 자율성을 더 안정적으로 느끼게 하고 신뢰의 도약을 조금 더 쉽게 만듭니다.
성공을 측정하는 방법은 많지만, 각 자율성 수준에 대해 이러한 메트릭의 일부 버전을 추적하는 것을 고려하십시오:
- 중재 간 평균 시간
- 승인된 작업으로 가장 긴 성공적인 무인 실행
- 샌드박스에서 실행된 작업 대 에스컬레이션된 작업의 비율
- 자동 승인된 작업 대 거부된 작업의 비율
- 인간 명령당 평균 에이전트 작업 수
- 설명 요청률 / 중단 요청률
- 승인된 변경당 검토 시간
- 각 신뢰 수준에서의 재작업률
- 각 신뢰 수준에서의 결함 누출률
- 승인된 변경당 토큰 비용
이러한 메트릭은 이야기를 들려줄 수 있습니다. 인간의 인계로 바쁜 단일 에이전트는 대시보드가 있는 레벨 4입니다. 자동화된 접수, 재시도 및 적절한 증거 없이는 진행을 꺼리는 보수적인 에이전트는 실제 게이트가 있는 레벨 5입니다.
준비 상태에 대해 생각하세요
위험과 얼마나 쉽게 취소할 수 있는지에 따라 작업을 분류하세요. 자율성을 보수적으로 적용하고, 더 높은 수준을 지원하는 증거가 축적됨에 따라 상승시키세요. 강력한 테스트와 검토자 에이전트로 보호되고 깨끗한 롤백 경로가 있는 결제 엔진 리팩터링은 표준적인 진실이 부족한 문서화 자동화 작업보다 훨씬 더 높은 자율성을 지원할 수 있습니다. 자율성 수준은 작업 이름이 아닌 검증 프로세스를 따라야 합니다.
네 가지 안티패턴
모든 시스템은 경계하지 않으면 이러한 네 가지 자율성 안티패턴에 쉽게 빠질 수 있습니다.
자율성 지위 - 에이전트의 자율성 등급이 의미 없는 지위 배지가 됩니다. 더 높은 자율성은 안전의 증거가 아닌 능력의 증거로 취급되며, 에이전트는 검증이 지원하는 것보다 더 높은 수준으로 실행됩니다. 수정: 올바른 자율성 수준에 정착하고 한계를 초과하지 않도록 끊임없이 노력하는 사람들을 칭찬하고 보상하세요.
허가 세탁 - 승인 피로의 폭정으로 인해 AI 에이전트와 도구에 필요한 것보다 훨씬 더 광범위한 액세스 권한을 부여하게 됩니다. 수정: 더 나은 경계는 항상 해결책입니다. 예를 들어 샌드박스 프로필, 범위가 지정된 쓰기 가능한 루트, 허용된 명령어 목록, 훅 및 Auto-review가 있습니다.
요약 대체 - 에이전트의 작업 요약이 검토를 대체하여 요약이 충분하다고 가정합니다. 수정: 인지적 항복을 피하면서 완전한 수동 검토와 동일한 증거 패키지(diff, 테스트, 로그, 스크린샷, 검토자 결과, 위험, 격차 등)를 함께 제공하세요.
플릿 코스프레 - 수십 개의 에이전트가 병렬로 실행되지만, 인간은 모든 종속성을 수동으로 오케스트레이션합니다. 수정: 공유 상태, 소유권 규칙 및 더 나은 종속성 추적을 통해 수동 조정의 필요성을 점차 줄입니다. 더 작은 WIP 제한은 오케스트레이션이 자동화될 때까지 조정된 단계를 인코딩하고 문서화하는 데 집중하도록 강제합니다.
교정 연습
에이전트 지원으로 수행한 마지막 10개 작업을 검토하세요. 각 작업에 대해 실행된 자율성 수준, 관련된 위험, 작업을 얼마나 쉽게 취소할 수 있는지, 검증 요구 사항을 충족하기 위해 생성된 증거, 검토 시간, 필요한 재작업 여부, 그리고 선택한 자율성 수준이 다음에도 여전히 적합할지 여부를 기록하세요.
안전하게 등반하는 방법
한 번에 한 축씩 이동하세요. 방어 가능한 성공 증거를 생성하는 단일 범위 작업을 수행하는 단일 감독 에이전트로 시작하세요(충분히 깔끔하다면 자율성 레벨 1). 그런 다음 세 가지 직교 방향으로 점차 확장하세요. 읽기 집약적인 탐색 작업을 병렬화하세요(자율성 레벨 4). 제한된 파일 소유권 규칙으로 별도의 작업 트리에서 작동하는 쓰기 에이전트를 추가하세요(자율성 레벨 4). 반복 자동화를 추가한 다음 이슈, 음성 등을 기반으로 한 에이전트 주도 오케스트레이션을 추가하세요. 레버의 모든 단계에는 새로운 안전 메커니즘(예: 새로운 실패 모드)이 필요합니다.
이름을 지정하세요: 더 긴 단일 에이전트 실행은 표류, 컨텍스트 부패, 통신 중단 또는 목표 이탈로 이어질 수 있습니다. 백그라운드 작업은 오래된 가정과 약한 인계로 이어질 수 있습니다. 너무 많은 병렬 작업은 병합 충돌이나 중복 결정으로 이어질 수 있습니다. 너무 많은 반복 작업은 조용한 토큰 소비나 오래된 프롬프트로 이어질 수 있습니다. 예외에 의한 관리는 긴 검토 큐와 알림 피로로 이어질 수 있습니다. 더 열심히 신뢰하는 것으로 수정하지 마세요. 대신, 범위를 좁히고, 더 나은 증거를 보장하고, 더 저렴한 롤백 경로를 활성화하고, 게이트를 강화하고, 더 명확한 소유권 규칙을 정의하세요.
자율성 수준 사용:
- 레벨 0은 섬세한 작업과 판단이 아직 형성되고 있을 때 가장 좋습니다.
- 레벨 1은 작업이 잘 이해된 경계 근처에서 수행되는 경우 대부분의 탐색에 가장 좋습니다.
- 레벨 2는 알 수 없는 종속성과 예상치 못한 문제가 있을 수 있음을 알고 있는 대부분의 범위가 지정된 작업에 가장 좋습니다.
- 레벨 3은 성공 조건을 충분히 명확하게 기술할 수 있는 경우 가장 좋습니다.
- 레벨 4는 작업을 이러한 성공 조건에 따라 깔끔하게 분할할 수 있을 때 가장 좋습니다.
- 레벨 5는 다양한 성공 조건 전반에 걸쳐 필요한 조정 및 통신이 완전히 인코딩된 후에 가장 좋습니다.
검증은 항상 병목 현상이 될 것입니다.
현재의 허세와 현재의 도구에도 불구하고, AI 에이전트와 협력하는 엔지니어링 팀의 성숙한 자세는 조정된 자율성입니다.
병목 현상은 조정, 검증, 유지 관리, 제품 판단 및 인시던트 학습입니다.
가까운 미래에는, 언제 작업하고, 언제 검증하고, 언제 질문할지 아는 루프를 설계하고 싶을 것입니다. 하지만 엔지니어의 기술은 여전히 올바른 자율성 수준을 선택하고, 더 어두운 측면으로부터 보호하는 패턴과 방어 가능한 증거를 구축하는 데 있을 것입니다.
참고: Pangram은 이 기사를 100% 인간이 작성한 것으로 표시합니다: https://www.pangram.com/history/87531e13-cd12-4cb0-9e02-9579719ddc26
