Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
에이전트형 엔지니어링이 단순 프롬프트 작성을 넘어 운영 설계 단계로 진화하고 있습니다. 자율성을 단일 축이 아닌 개별 에이전트의 역량(agency)과 다중 에이전트 조율(orchestration)이라는 두 축으로 분석해야 함을 강조합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 GeekNews의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Steve Yegge의 “Welcome to Gas Town”에서 언급된 단일 축 사다리는 한 에이전트에 대한 신뢰를 숫자로 표현하는 데 유용함
2026년 초에는 작업이 위임에서 오케스트레이션으로 이동하는 상황에서도 단일 축이 위험 측정의 대략적 대리 지표로 작동했음
여러 에이전트를 동시에 실행할 수 있게 되면, 단일 단계만으로는
다중 에이전트 역량을 설명하기 어려움
자율성 논의는 서로 다른 두 질문을 자주 섞음
단일 에이전트를 사람에게서 얼마나 멀리 보낼 수 있는가
여러 에이전트를 얼마나 잘 조율할 수 있는가
이를 분리하려면 두 축이 필요함
agency: 한 에이전트가 제안, 제한된 작업, 목표 달성을 얼마나 자율적으로 수행하는가
orchestration: 하나의 스레드부터 여러 작업 트리, 백로그·이슈 트래커·스케줄 기반의 지속적 작업까지 얼마나 조율하는가
/plan, /goal
, /loop
, /background
, /batch
, /code-review
, /security-review
, 서브에이전트, 훅, 체크포인트, 에이전트 위임과 관리 방식, 백그라운드 세션, 에이전트 팀 패턴, /schedule
인자
사다리를 아래에서 위로 읽으면 agency와 orchestration을 동시에 올리는 것처럼 보임
여섯 단계는 세 개의 시대로 나뉨
사람이 운전석에 있고 에이전트는 보조하며 사람의 조작을 기다리는 시대
에이전트가 제한된 작업이나 목표를 맡지만 사람이 조정하고 검증하는 시대
시스템이 여러 에이전트에 작업을 배분하고, 사람은 문제가 생길 때 주로 개입하는 오케스트레이션 시대
실제 엔지니어링에서는 하루 동안 여러 단계를 오가며 작업하는 것이 자연스러움
에이전트가 대신 편집하거나 명령을 실행하지만, 중요한 실행 전에는 사람에게 허가를 요청함
대부분의 사람이 쓰는 기본 자세에 가까움
로컬 샌드박스에서 변경 적용 전 승인을 받거나, 대화형 세션에서 수행할 수 있음
각 승인은 해당 변경을 적용해도 괜찮은지 확인하는 독립 검증으로 작동함
주요 실패 모드는
승인 피로임
무엇을 승인하든 모든 승인이 비슷하게 느껴질 수 있음
diff를 대충 훑거나, 휴리스틱을 따르거나, 다른 사람에게 확인하거나, 에이전트가 책임지도록 허용하는 방식으로 대응할 수 있음
Codex Auto-review는 경계 조건의 최종 승인을 별도 리뷰어 에이전트에 위임해 이 문제를 다룸
에이전트가 특정 조건이 충족될 때까지 목표 달성을 위해 필요한 일을 수행함
프롬프트 모드에서는 프롬프트 자체가 목표가 됨
예: “이 페이지의 time-to-interactive를 1초 미만으로 줄일 수 있는가?”
Codex에서는 Goal mode가 이에 해당하며, 에이전트가
plan -> act -> test -> review
단계를 반복하다가 성공 기준을 더 이상 만족하지 못하면 멈춤
/goal, /loop
, /schedule
명령이 이에 해당함
any가 없는 엄격한 TypeScript 빌드 보장
이해 가능하고 테스트를 통과하는 의존성만 남기도록 전체 의존성 분류
프로덕션 버그를 찾으려면 에이전트가
프로덕션과 유사한 환경에 있어야 함
/batch, worktree, 에이전트 팀 등이 있음
주요 실패 모드는 거짓 병렬성임
여러 에이전트가 겹치는 조각을 동시에 다루면 더 많은 작업 대신 merge conflict와 중복 결정을 만들 수 있음
잘 운영하려면 에이전트가 서로 격리되어야 함
각자 소유한 파일과 상태가 있어야 함
각자 리뷰 큐도 가져야 함
에이전트마다 토큰 비용이 발생하며, 동시에 실행되는 에이전트 수에 비례함
사람 쪽에서는 몇 개 이후부터 에이전트를 추가할 때의 한계 비용이
오케스트레이션 세금 때문에 증가함
성공의 정의와 적용할 정책을 사람이 정하고, 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에 가까움
에이전트의 자율성 등급이 의미 없는 지위 배지처럼 작동함
높은 자율성이 안전성이 아니라 능력의 증거처럼 취급되고, 검증이 뒷받침하지 못하는 수준으로 에이전트가 실행됨
올바른 자율성 수준을 선택하고 선을 넘지 않는 사람을 칭찬하고 보상해야 함
승인 피로 때문에 AI 에이전트와 도구에 필요 이상으로 넓은 접근 권한을 부여함
샌드박스 프로필, 범위가 제한된 쓰기 루트, 허용 명령 목록, 훅, Auto-review 같은 경계를 강화해야 함
에이전트의 작업 요약이 리뷰를 대체함
수동 리뷰와 같은 증거 패킷을 함께 묶어야 함
diff, 테스트, 로그, 스크린샷, 리뷰어 발견 사항, 위험, 빈틈이 포함될 수 있음
최근 에이전트 도움을 받은 작업 10개를 검토하는 보정 연습이 제안됨
각 작업의 자율성 수준
위험
되돌리기 쉬운 정도
검증 요건을 만족하기 위해 생성된 증거
리뷰 시간
재작업 여부
다음에도 같은 자율성 수준이 적합한지
한 번에 한 축씩 올라가야 함
시작점은 단일 supervised agent가 방어 가능한 성공 증거를 만드는 하나의 제한된 작업을 수행하는 형태임
이후 세 방향으로 점진적으로 확장함
읽기 중심 탐색 작업을 병렬화함
제한된 파일 소유권 규칙을 가진 별도 worktree에서 쓰기 에이전트를 추가함
반복 자동화를 추가한 뒤 이슈나 음성 등에 기반한 에이전트 주도 오케스트레이션을 추가함
각 단계 상승은 새로운 실패 모드에 대응하는 새로운 안전장치를 요구함
실패 모드는 다음과 같음
긴 단일 에이전트 실행: 드리프트, 컨텍스트 부패, 누락된 커뮤니케이션, 목표 이탈
백그라운드 작업: 오래된 가정, 약한 인수인계
과도한 병렬 작업: merge conflict, 중복 결정
과도한 반복 작업: 조용한 토큰 지출, 오래된 프롬프트
managed-by-exception: 긴 리뷰 큐, 알림 피로
더 세게 신뢰하는 방식이 아니라 범위를 좁히고, 더 나은 증거를 확보하고, 더 싼 롤백 경로를 만들고, 게이트를 강화하고, 소유권 규칙을 더 명확히 해야 함