RUDA DIRECTOR · AI 깊이 이해하기 — 자율 시스템 설계까지 · CHAPTER 11
AI Agent의 자율성은 어디까지 허용해야 할까?
30초 답: 자율성은 제한 없이 오래 실행하는 능력이 아니다. 정해진 Goal을 위해, 허용된 Environment와 Tool 안에서, Permission·Budget·Evidence·Stop Condition을 지키며 다음 행동을 선택하는 권한이다. 먼저 읽기 전용 자료와 로컬 결과물처럼 되돌리기 쉬운 범위만 맡기고, 근거 부족·범위 이탈·실행 한도 초과·허가되지 않은 외부 변경이 필요하면 완료가 아니라 보류나 차단으로 끝내야 한다.
OpenAI는 Agent를 사용자를 대신해 높은 독립성으로 Workflow를 수행하는 시스템으로 설명하면서도, 명확한 Guardrail 안에서 Tool을 고르고 실패 시 실행을 멈춰 사용자에게 제어를 돌려줄 수 있어야 한다고 설명한다. Anthropic도 Agent를 Model이 과정과 Tool 사용을 동적으로 지휘하는 시스템으로 구분하며, 환경의 실제 결과를 확인하고 blocker나 stopping condition에서 멈추는 구조를 강조한다. 두 설명의 공통점은 ‘독립성’보다 관찰 가능한 경계와 종료에 있다.
정확한 경계: Automation·Capability·Permission·Autonomy는 다르다
| 개념 | 묻는 질문 | 설계상 의미 |
|---|---|---|
| Automation | 미리 정한 순서를 자동 실행하는가? | 경로는 코드가 결정할 수 있다 |
| Capability | 어떤 일을 해낼 수 있는가? | Model·Tool의 가능 범위다 |
| Permission | 어떤 상태를 읽거나 바꿔도 되는가? | 가능하더라도 허용되지 않을 수 있다 |
| Autonomy | 허용 범위 안에서 다음 행동을 스스로 고르는가? | 선택권과 중단 책임을 함께 준다 |
| Reliability | 같은 조건에서 의도한 결과를 얼마나 안정적으로 내는가? | 자율성이 높다는 사실만으로 보장되지 않는다 |
정해진 세 단계만 순서대로 실행하는 문서 변환기는 Automation일 수 있지만 Agent일 필요는 없다. 반대로 여러 Tool 중 하나를 고를 수 있어도 외부 게시 권한이 없으면 ‘게시 가능한 Agent’가 아니다. Capability를 Permission으로 착각하면 실패 표면이 커진다. 자율성은 Model의 성질 하나가 아니라 Model이 선택할 수 있는 행동과 시스템이 허용하는 행동의 교집합이다.
Task Contract는 자율성의 울타리를 실행 가능한 상태로 바꾼다
System Prompt에 “안전하게 작업하라”고 쓰는 것만으로는 부족하다. 실행기는 요청을 받은 뒤 첫 Tool 실행 전에 Task Contract(작업 계약)를 구조화하고, 각 Tool 호출과 종료 상태를 그 계약에 대조해야 한다. 최소 계약은 다음 일곱 부분으로 나눌 수 있다.
- Goal: 무엇을 산출해야 하는가. 예: 지정된 두 문서 revision의 변경 보고서.
- Environment: 어떤 자료와 저장 위치가 이번 실행의 세계인가. 문서 ID·revision·읽기 시점을 고정한다.
- Allowed actions: 읽기, 필드 추출, 비교, 로컬 보고서 저장처럼 허용된 행동을 열거한다.
- Forbidden actions: 원문 수정, 외부 게시, 메시지 발송, 다른 경로 탐색처럼 제외한 행동을 명시한다.
- Evidence: 완료를 주장할 때 필요한 source ID, 근거 위치, 입력 hash와 필수 필드를 정의한다.
- Budget: Step·Retry·시간·Token·Cost 상한을 둔다. 숫자는 위험과 측정 결과에 맞춰 정하며, 무한 반복을 허용하지 않는다.
- Terminal states: COMPLETED뿐 아니라 NEEDS_REVIEW, BLOCKED, STOPPED, ERROR를 정상적인 종료로 설계한다.
이 계약은 Agent가 더 똑똑하다고 가정하지 않는다. 오히려 틀릴 수 있다는 전제에서, 틀렸을 때 외부 상태까지 얼마나 멀리 번질지를 제한한다. OpenAI의 Agent 안전 가이드도 Structured Output으로 노드 사이의 데이터 흐름을 제한하고 Tool Approval을 유지하라고 권한다. 문서 안의 자유 텍스트가 다음 행동을 직접 결정하지 않게 만드는 이유다.
메커니즘: 입력에서 종료까지 무엇을 검사하는가
Request → Contract check → Observe → Decide → Act → Validate → Terminal state
첫째, 요청을 Goal과 scope로 정규화한다. 둘째, Environment에서 실제 입력 revision을 읽고 관찰값을 저장한다. 셋째, 다음 행동 후보가 allowed action인지 확인한다. 넷째, Tool 결과를 계획의 성공으로 간주하지 않고 source ID와 필수 필드로 검증한다. 다섯째, 완료 조건을 만족하면 COMPLETED로 끝내고, 부족하면 추측하지 않은 채 NEEDS_REVIEW로 끝낸다. 금지된 행동은 BLOCKED, 한도를 넘긴 반복은 STOPPED다.
여기서 Human Approval은 Autonomy와 같은 축이 아니다. Agent가 외부 게시를 선택했다고 해서 그 행동이 허용되는 것은 아니다. 게시가 필요하다면 별도의 Approval gate가 실행을 pause하고 사람이 승인한 경우에만 해당 행동을 재개하고, 거부하면 차단하거나 허용된 대안으로 전환해야 한다. 읽기 전용 분석과 되돌리기 어려운 변경을 같은 Permission으로 묶지 않는다.
합성 계약 판정 예시: 완료·보류·차단·중단을 구분하는 법
아래 표는 결정론적 Task Contract를 설명하기 위해 만든 합성 사례와 기대 판정이다. 실제 LLM이나 문서 서비스의 실행 결과가 아니며, Model의 판단 성능을 측정한 자료도 아니다. 허용 행동은 read_revision, extract_fields, write_local_report 세 가지이고, 완료에는 대상·시행일·source ID가 모두 필요하다. 설명용 Step Budget은 5다.
| 합성 trace | 기대 사유 | 계약 판정 |
|---|---|---|
| 필수 근거와 허용 행동 충족 | contract_satisfied | COMPLETED |
| 시행일 근거 누락 | missing_evidence:effective_date | NEEDS_REVIEW |
| 외부 게시 시도 | forbidden_action:publish_web | BLOCKED |
| 읽기 6번째 시도, 실행 한도 5회 | step_budget:6/5 | STOPPED |
이 예시는 Model의 판단 성능을 증명하지 않는다. 설계하려는 것은 더 좁다. 실행기가 ‘완료하지 못함’을 하나의 실패 문자열로 뭉개지 않고, 운영자가 다음 결정을 내릴 수 있는 상태로 분리하게 한다. 시행일을 찾지 못하면 COMPLETED를 반환하지 않아야 하고, 외부 게시 시도는 보고서 생성 성공과 무관하게 차단해야 한다. Step Budget은 다음 행동을 실행하기 전에 검사해 여섯 번째 읽기가 실행되지 않도록 한다. 실제 구현에서는 이 기대 판정을 테스트하고, 실행 로그로 확인해야 한다.
Worked example: 문서 변경 보고 Agent의 가장 작은 유효 경계
합성 정책 문서의 이전 revision은 적용 대상을 ‘모든 계정’, 시행일을 ‘10월 1일’로 적었다. 현재 revision은 적용 대상을 ‘신규 계정’으로 바꿨지만 시행일 문장이 빠져 있다. Agent의 Goal은 두 revision을 비교해 로컬 보고서를 만드는 것이다.
- 관찰: 두 source ID와 hash를 저장하고 대상 변경을 찾는다.
- 결정: 현재 revision에 시행일 근거가 없으므로 이전 날짜를 복사하지 않는다.
- 행동: 로컬 초안에 ‘대상: 신규 계정’, ‘시행일: 확인 필요’, 근거 위치를 기록한다.
- 검증: 필수 evidence 중 시행일이 비어 있음을 확인한다.
- 종료: NEEDS_REVIEW로 끝낸다. 문서 수정·웹 게시·메시지 전송은 실행하지 않는다.
일을 많이 했으므로 성공한 것이 아니다. 계약이 요구한 근거가 없으므로 미완료를 정확히 보고한 것이 성공이다. 반대로 현재 revision에 대상과 시행일이 모두 있고 source pointer가 검증됐다면 로컬 보고서 생성까지는 COMPLETED가 될 수 있다. 그 보고서를 공개하는 일은 별도의 작업과 Permission이다.
자율성 설계가 자주 실패하는 여섯 가지 이유
- Goal을 “알아서 처리”로 쓴다. 산출물·대상·완료 조건이 없으므로 Agent가 멈출 기준도 없다.
- Tool 보유를 Permission으로 본다. 호출 가능한 API가 곧 이번 작업에서 허용된 API라는 뜻은 아니다.
- Tool success를 Task success로 본다. 파일을 읽었다는 응답은 올바른 revision과 근거를 읽었다는 증거가 아니다.
- 추측을 계속 진행으로 보상한다. 필수 정보가 없는데도 다음 Step으로 보내면 오류가 보고서·게시·메시지로 확산된다.
- 완료만 정상 종료로 둔다. 보류와 차단이 예외 처리로 밀려나면 실패를 숨기거나 무한 Retry하기 쉽다.
- 자율성을 한 번에 넓힌다. Context·Latency·Cost·권한·공격 표면·복구 경로가 동시에 늘어 어느 변화가 품질을 만들었는지 알기 어렵다.
Trade-off: 자율성 확대는 편의와 실패 반경을 함께 키운다
| 경계 | 얻는 것 | 추가되는 비용·위험 |
|---|---|---|
| 읽기 전용 + 로컬 보고서 | 낮은 권한, 쉬운 rollback | 사람이 최종 전달해야 함 |
| 여러 자료·Tool 선택 | 유연한 탐색과 계획 | Context·Latency·관측 지점 증가 |
| 외부 시스템 쓰기 | Workflow 완결 | 오작동·Prompt Injection·권한 오용의 실패 반경 증가 |
| 장시간 반복 실행 | 복잡한 문제의 탐색 여지 | Cost, 누적 오류, stale state, 중복 실행 위험 |
Anthropic은 Agent가 open-ended 문제에서 유용하지만 더 높은 Cost와 오류 누적 가능성을 갖고, sandbox와 Guardrail이 필요하다고 설명한다. 따라서 작은 아키텍처가 출발점이다. 고정된 비교 규칙으로 충분하다면 Agent Loop를 추가하지 않는다. Model이 경로를 골라야 하는 모호성이 실제로 관찰될 때만 선택권을 늘린다.
언제 Agent 자율성을 사용하지 말아야 하나
정해진 두 필드의 차이를 계산하는 일처럼 입력과 경로가 안정적이면 deterministic Workflow가 더 싸고 재현하기 쉽다. 정확한 산술·Schema 검증·권한 확인도 코드가 먼저다. 외부 결제·삭제·공개 게시처럼 되돌리기 어렵고 영향이 큰 행동은 충분한 Evaluation과 독립 검증 없이 자동 승인하지 않는다. 성공 조건을 쓸 수 없거나 실제 결과를 관찰할 Tool이 없다면, 자율성보다 먼저 업무 계약과 관측 경로를 설계해야 한다.
실무 적용 원칙: 자율성을 넓히기 전 확인할 아홉 질문
- 이번 run의 Goal과 산출물을 한 문장으로 검증 가능하게 썼는가?
- Environment에 포함되는 문서·revision·계정·경로가 고정됐는가?
- Capability와 Permission을 별도 목록으로 관리하는가?
- 각 Tool 결과를 실제 환경의 evidence로 다시 확인하는가?
- COMPLETED에 필요한 필드·근거·검증 규칙이 있는가?
- NEEDS_REVIEW·BLOCKED·STOPPED를 정상 종료로 기록하는가?
- Step·Retry·시간·Token·Cost 한도가 있는가?
- 외부 변경은 Approval과 rollback 경로를 따로 갖는가?
- 고정 Workflow보다 Agent가 나은 이유를 같은 Evaluation으로 확인했는가?
학습 결론: 자율성은 자유의 크기가 아니라 책임 있게 닫힌 실행 범위의 선명도다. 무엇을 읽고, 무엇을 바꾸며, 어떤 증거로 끝내고, 언제 사람에게 제어를 돌려주는지 정하지 않았다면 아직 자율 시스템을 설계한 것이 아니다. 다음 장에서는 이 계약을 실행하려면 시스템이 현재 상태를 얼마나 정확히 관찰해야 하는지, partial observability와 stale snapshot 문제를 다룬다.
공식 참고 자료
- OpenAI — A practical guide to building agents (확인: 2026-10-03)
- OpenAI — Safety in building agents (확인: 2026-10-03)
- Anthropic — Building effective agents (확인: 2026-10-03)
시리즈 탐색
Previous: Chapter 10 — AI 평가 설계: 정답 예시를 보고 만든 평가는 왜 믿기 어려운가
Next: Chapter 12 — 시스템이 현재 상태를 제대로 보고 있는가
Related: Chapter 09 — RAG와 Fine-tuning의 차이
Series start: Chapter 01 — LLM의 학습과 추론