**AI 에이전트 자율성 수준 (AI agent autonomy levels)**은 인간이 개입하기 전까지 에이전트가 스스로 수행할 수 있는 범위를 설명합니다. 이는 기록 없이 조용히 행동하는 것부터, 행동 후 사용자에게 알리는 것, 모든 단계에서 허가를 요청하는 것, 그리고 마지막으로 의사결정권을 완전히 넘기는 단계까지 다양합니다. 이는 단일 스위치가 아니라 제어 다이얼과 같습니다. 대부분의 팀은 에이전트 전체에 대해 하나의 수준을 설정하는데, 이는 실수입니다. 해당 행동이 얼마나 치명적일 수 있는지, 그리고 인간이 실수할 틈을 제때 잡아낼 수 있는지에 따라 행동별로 (per action) 자율성 수준을 설정하십시오. 이 글은 L0부터 L6까지 7단계로 구성된 LoopRails 자율성 사다리 (autonomy ladder)를 기록하고, 에이전트가 수행할 수 있는 각 작업에 대해 어떻게 적절한 단계를 선택하는지 보여줍니다.

이 사다리는 AI 에이전트에 대한 인간 참여형 감독 (human-in-the-loop oversight)을 위한 무료 실무 프레임워크인 LoopRails의 일부입니다. 그 방법론은 등급 지정 · 보호 · 표시 · 증명 (Grade · Guard · Show · Prove) 입니다 (프레임워크 참조): 각 행동을 그 결과에 따라 등급을 매기고, 해당 등급에 맞는 제어 장치로 보호하며, 인간에게 실제 행동과 그 효과를 보여주고, 감독이 실제로 실수를 잡아내는지 증명하여 신뢰를 구축하는 방식입니다.

LoopRails 자율성 사다리: L0부터 L6까지

각 단계는 자율성을 대가로 통제권을 교환합니다. 낮은 단계는 빠르고 저렴하며 행동이 안전하거나 복구 가능하다고 가정합니다. 높은 단계는 느리고 비용이 많이 들며 행동이 해를 끼칠 수 있다고 가정합니다. 전체 사다리는 다음과 같습니다.

사람들이 사다리를 잘못 이해하는 몇 가지 차이점이 있습니다.

L0와 L1의 차이는 보이지 않는 것(invisible)과 감사 가능한 것(auditable)의 차이입니다. L0는 아무런 흔적을 남기지 않습니다. 기록 자체가 노이즈가 될 정도로 사소한 행동에만 사용하십시오. L1은 그 외 거의 모든 것의 기본 단계입니다. 왜냐하면 로깅 (logging)이야말로 사후에 모든 다른 제어 장치가 검증 가능하게 만드는 핵심이기 때문입니다. 에이전트가 무엇을 했는지 알 수 없다면, 어떤 감독 체계가 제대로 작동했는지도 알 수 없습니다.

L2는 알림이 아니라 '실행 취소(undo)'를 통해 안전을 확보합니다. '사후 알림(Notify-after)' 방식은 해당 작업이 진정으로 되돌릴 수 있을 때만 안전합니다. 핵심은 인간에게 공포를 유발하기 위해 정보를 전달하는 것이 아니라, 저렴하고 빠르게 되돌릴 수 있는 경로를 제공하는 것입니다. 실행 취소(undo) 기능이 없다면 L2는 성립할 수 없습니다.

L3와 L4는 모두 서로 다른 세밀함(grain)을 가진 "사전 승인(ask first)" 방식입니다. L3는 단일 작업을 제어합니다. L4는 하나의 '계획(plan)'과 단계 사이의 체크포인트를 제어하여, 인간이 세 단계 뒤에 일어날 일에 대해 뒤통수를 맞는 일이 없도록 합니다. L4는 각 단계가 개별적으로는 무해해 보일지라도, 전체적으로는 다단계이며 중대한 결과를 초래하는 작업에 적합합니다.

L5는 대부분의 사람들이 건너뛰는 단계이자, 자동화 편향(automation bias)에 맞서는 단계입니다. 자동화 편향은 시스템의 제안을 과도하게 신뢰하고 실질적인 검토 없이 승인해 버리는, 이미 잘 알려진 경향을 말합니다. 단계가 높아질수록 이 현상은 악화되는데, 이는 이전의 모든 올바른 작업이 인간에게 '다음 작업도 괜찮을 것'이라는 학습을 시키기 때문입니다. L5의 해법은 강제 함수(forcing function)입니다. 인간이 에이전트의 권장 사항을 보기 전에 결정에 참여하도록 만들어, 단순히 권장 사항에 의존하는 것을 방지합니다.

L6는 인간이 제때 실수를 잡아낼 수 없을 때의 정답입니다. 어떤 작업들은 되돌릴 수 없으며, 비행 중 검토(in-flight review)로는 도움이 되지 않을 만큼 심각합니다. 이러한 경우, 에이전트는 인간 의사결정권자에게 에스컬레이션(escalate)하거나 아예 행동이 금지됩니다.

등급(Grade)에 따른 자율성 수준 선택

작업의 가치를 알기 전까지는 단계를 선택할 수 없습니다. LoopRails는 에이전트가 수행할 수 있는 모든 작업을 세 가지 축(가역성(reversibility) × 영향 범위(blast radius) × 이해관계(stakes))을 기준으로 등급을 매기며, 이 중 가장 높은 축이 등급을 결정합니다. 이를 통해 네 가지 등급이 생성되며, 각 등급은 자율성 사다리의 특정 구간(band)에 매핑됩니다.

등급과 수준(level)의 매핑은 전체 프레임워크의 중추이므로, 구체적인 예시와 함께 정리하면 다음과 같습니다.

G0에서 L0/L1까지. 읽기 전용 쿼리(read-only query), 파일 목록 나열, 주석 재구성 등이 이에 해당합니다. 이는 읽기 작업이거나 사소하며, 완전히 복구 가능한 편집입니다. 프롬프트 없이 실행하고 기록(log)만 합니다. 이 단계에서 승인을 요청하는 것은 사람들이 내용을 확인하지 않고 단순히 "예"를 클릭하도록 훈련시키는 것이며, 이는 실제로 중요한 프롬프트에 대한 판단력을 흐리게 만듭니다. G0 가이드를 참조하세요.

G1에서 L1/L2까지. 파일 전체에 걸친 로컬 변수 이름 변경, 초안 PR(draft PR) 생성, 이슈(issue)에 라벨 추가, 넉넉한 한도 내에서의 소액 환불 등이 포함됩니다. 에이전트가 작업을 수행한 후, 클릭 한 번으로 실행 취소(undo)할 수 있도록 수행한 내용을 보여줍니다. 안전성은 프롬프트가 아니라 실행 취소 기능에서 나옵니다. G1 가이드를 참조하세요.

G2에서 L3/L4까지. '실행 전 확인(confirm-before)' 방식이 제 가치를 발휘하는 단계입니다. 공유 브랜치에 대한 git push, main 브랜치로의 머지(merge), 고객에게 이메일 발송, 스테이징(staging) 환경 배포 등이 이에 해당합니다. 이러한 작업들은 되돌리기 어렵고 공유 영향 범위(blast radius)가 크지만, 실제 변경 사항을 확인한 인간은 현실적으로 실수를 잡아낼 수 있습니다. 단일 푸시(push)는 L3 단계의 '실행 전 확인(confirm-before-acting)' 프롬프트입니다. 다단계 마이그레이션(migration)이나 릴리스(release) 시퀀스는 L4 단계의 '계획 승인(plan-approve)' 방식입니다. 인간이 전체 흐름을 파악해야 하고 단계 사이에 체크포인트(checkpoint)가 필요하기 때문입니다. G2 가이드를 참조하세요.

G3에서 L4/L5, 예방(prevention), 또는 L6 단계로의 전환. 운영 데이터 삭제, 계좌 이체, 모든 고객에게 대량 이메일 발송, 공유 브랜치에 대한 강제 푸시(force-pushing) 등이 이에 해당합니다. 이 단계에서는 기본 설정이 단 한 번의 승인 클릭이 되어서는 안 됩니다. 왜냐하면 단 한 번의 클릭은 되돌릴 수 없고 심각한 조치에 대해 충분한 감독(oversight)을 제공하지 못하기 때문입니다. 설계 단계에서의 예방(prevention by design)을 선호하세요: 폭발 반경(blast radius)을 제한하고, 가역성(reversibility)을 강제하며, 위험한 버전이 실행되지 않도록 샌드박스(sandbox)화 하십시오. 인간이 결정 과정에 머물러야 하며 여전히 실수를 잡아낼 수 있는 경우에는, 에이전트의 답변을 보기 전에 인간이 먼저 커밋(commit)하는 L5 공동 실행(co-execute) 방식을 사용하십시오. 그리고 주어진 시간 내에 인간이 진정으로 실수를 잡아낼 수 없는 경우(diff가 너무 커서 읽을 수 없거나, 결과가 나중에 나타나 보이지 않거나, 대응할 시간이 없는 경우)에는 L6로 전환하십시오: 의사결정권자(decision-owner)인 인간에게 에스컬레이션(escalate)하거나 해당 동작을 금지하십시오. G3 가이드를 참조하세요.

마지막 분기점이 바로 LoopRails의 핵심입니다. 핵심 질문은 결코 "인간이 이것을 검토해야 하는가?"가 아닙니다. 핵심은 **"인간이 현실적으로 제시간에 이 실수를 잡아낼 수 있는가?"**입니다. 만약 정직한 답변이 '아니오'라면, 확인 전 프롬프트(confirm-before prompt)는 감독이 아니라 서명만 더해진 지연일 뿐입니다. 게이트(gating)를 만드는 대신 결과를 예방하거나 에스컬레이션하십시오.

증거가 이를 뒷받침합니다. AI 코딩 에이전트에 대한 연구(LoopRails codex 참조)에 따르면, 동작 전 계획 승인(plan-approval)을 요구했을 때 공격 발생률이 약 90%에서 6074%로 감소했으나, 이는 실질적이지만 부분적인 감소에 불과했습니다. 게다가 문제가 인간 앞에 나타났을 때, 테스트된 모든 감독 전략에서 개입 성공률은 단 926%에 머물렀습니다. 사다리를 타고 L4로 올라가는 것은 잘못된 _동작(actions)_을 줄여주었지만, 인간을 그 동작들의 신뢰할 수 있는 _탐지기(detectors)_로 만들지는 못했습니다. 그 격차야말로 높은 등급(high grades)을 받기 위해 단순히 승인 프롬프트를 하나 더 추가하는 대신, 예방(prevention)과 강제 기능(forcing functions)이 필요한 정확한 이유입니다.

대화형 채점기나 한 페이지짜리 치트 시트(cheatsheet)를 사용하여 자신의 동작을 등급 매겨보세요. 그러면 적절한 단계가 자연스럽게 도출될 것입니다.

자율성은 시간에 따라, 그리고 세션 내에서 변화해야 합니다

동작당 고정된 자율성 수준을 설정하는 것은 목적지가 아닌 시작점입니다. 두 가지 요소가 이를 변화시켜야 합니다.

자율성은 신뢰를 얻음에 따라 단계적으로 상승해야 하며, 여기서 '얻은(earned)'이라는 점이 강조되어야 합니다. 새로운 에이전트, 새로운 도구, 또는 새로운 작업 유형은 사다리의 낮은 단계에서 시작해야 합니다. 특정 유형의 동작들에 대해 올바르게 동작한다는 기록된 증거(logged evidence)가 축적되면, 해당 유형의 단계를 한 단계 높일 수 있습니다. 이는 실제로 증거를 보유하고 있을 때만 가능하며, 이것이 L1 단계에서의 로깅 (logging)이 최저 기준인 이유입니다. 단계 승격은 "지금까지는 괜찮았던 것 같다"는 막연한 느낌이 아니라, 감사(audit) 가능한 흔적에 의해 주도되어야 합니다. 단일 사례가 아닌 유형(class)을 승격시키고, 데이터에 기반하여 승격시키십시오.

상황이 더 위험해지면 세션 내에서 자율성은 단계적으로 하락해야 합니다. 맥락(Context)이 등급을 바꿉니다. 동일한 git push라도 기능 브랜치(feature branch)에서는 G2이지만, 변경 동결(change freeze)이 적용된 메이저 릴리스 전날 밤에는 사실상 G3입니다. 이상하게 행동하기 시작하거나, 루프 내에서 재시도하거나, 작업 범위를 벗어난 파일을 건드리거나, 스스로 권한을 격상(escalating)하는 에이전트는 승격된 수준에 그대로 두지 말고 사다리 아래로 내려야 합니다. 세션 상태(Session state)가 중요합니다. 시작 시점에 L2였던 동작이라도, 영향 범위(blast radius)가 커지면 L4가 필요할 수 있습니다.

사다리 바닥으로 서서히 표류하는 것을 경계하십시오. 가장 흔한 실제 실패 사례는 단 한 번 잘못된 단계를 선택하는 것이 아니라, 에이전트가 신뢰할 만하고 프롬프트가 마찰(friction)처럼 느껴지기 때문에 모든 것이 조용히 L0/L1을 향해 미끄러지는 것입니다. 이것이 바로 인간 참여형 모니터링(human-on-the-loop monitoring)이 인간 이탈형(out-of-the-loop disengagement)으로 퇴보하는 방식입니다 (human-in-the-loop vs on-the-loop 참조). 이에 대한 방어책은 인간이 알아차리고 개입하기를 기다리는 대신, 위험 신호가 포착되면 자동으로 등급을 강등(demotion)시키는 것입니다.

어떤 단계에 행동이 위치하든, 그것은 RAIL을 충족해야 합니다. 즉, 행동은 가능한 경우 Reversible(가역적)이어야 하고, 행위자는 해당 행동에 대해 Authorized(권한 부여됨)되어야 하며, 작업은 **Interruptible(중단 가능)**하여 누구나 에이전트를 빠르고 책임 소재 없이 멈출 수 있어야 하며, 결정 사항은 **Logged(기록됨)**되어야 합니다. 중단 가능성(Interruptibility)이야말로 낮은 단계의 자율적 단계들을 안전하게 만드는 핵심입니다. 만약 에이전트를 저렴한 비용으로 멈출 수 없다면, "인간이 개입할 수 있다"라는 주장은 실현 불가능한 주장입니다.

핵심 요약 (Key takeaways)

• **AI 에이전트 자율성 수준 (AI agent autonomy levels)**은 L0(자율적, 무음)에서 L1(기록됨) $\rightarrow$ L2(실행 후 통지 및 되돌리기 가능) $\rightarrow$ L3(실행 전 확인) $\rightarrow$ L4(계획 승인) $\rightarrow$ L5(공동 실행, 강제 기능 포함) $\rightarrow$ L6(에스컬레이션 / 금지)까지 이어집니다.
• 수준을 설정할 때는 에이전트 단위가 아닌 행동(action) 단위로 설정하십시오. 각 행동을 가역성(reversibility) $\times$ 영향 범위(blast radius) $\times$ 이해관계(stakes)에 따라 등급을 매긴 후 다음과 같이 매핑합니다: G0는 L0/L1으로, G1은 L1/L2로, G2는 L3/L4로, G3는 L4/L5 및 방지 조치로, 그리고 인간이 제때 실수를 포착할 수 없는 경우 L6로 매핑합니다.
• 읽기 및 사소한 편집은 L1에서 L2 사이에 위치하며, git push는 일반적으로 L3입니다. 운영 환경(prod)을 건드리거나 되돌릴 수 없는 행동은 방지 조치가 포함된 L4/L6입니다.
• L5는 자동화 편향 (automation bias)에 대응하기 위해 존재합니다: 에이전트의 답변을 보기 전에 인간이 먼저 확정(commit)하도록 만드십시오. 높은 자율성에는 단순히 더 많은 프롬프트가 아니라 강제 기능(forcing functions)이 필요합니다.
• 자율성은 획득되고 기록된 신뢰에 따라 단계적으로 상승(ratchet up)해야 하며, 위험 신호에 따라 단계적으로 하락(ratchet down)해야 합니다. 단계의 최하단으로 서서히 표류하는 것을 경계하십시오.
• 모든 단계에 대한 테스트 기준은 동일합니다: 인간이 현실적으로 이 실수를 제때 잡아낼 수 있는가? 만약 그렇지 않다면, 게이트(gate)를 두기보다 방지(prevent)하거나 에스컬레이션(escalate)하십시오.

다음 단계 (Where to go next)

특정 작업이 어느 단계(rung)에 해당하는지 추측하지 말고 등급을 매기십시오. 실제 작업들을 LoopRails grader를 통해 실행하여 G0에서 G3까지의 등급과 그에 맞는 통제 수단(controls)을 확인한 후, framework에서 전체 방법론을 읽고 playbook을 통해 실무에 적용해 보십시오. 이 사다리(ladder)의 결정 근거에 대해 더 자세히 알고 싶다면, AI 에이전트가 언제 승인을 요청해야 하는가 및 인간 참여형(human-in-the-loop) 방식이 실제로 AI 안전성을 향상시키는가를 참조하십시오. 에이전트가 작업의 결과가 허용하는 가장 낮은 단계의 가이드라인(rails)을 벗어나지 않도록 유지하십시오.

원문은 looprails.dev/article-ai-agent-autonomy-levels.html에 게시되었습니다. LoopRails는 AI 에이전트에 대한 인간 참여형(human-in-the-loop) 감독을 설계하기 위한 무료 오픈 소스 프레임워크입니다.