권한과 책임 범위

AI 엔지니어링에서 권한과 책임 범위를 설계하는 방법

AI가 단순히 답변을 생성하는 수준을 넘어 직접 Tool을 호출하고, 코드를 수정하고, 외부 시스템의 상태를 변경하는 Agent 형태로 발전하면서 권한과 책임 범위(Governance / Autonomy Boundary)를 어떻게 설정할 것인지가 중요한 문제가 되고 있다.

AI Agent에게 더 많은 권한을 부여할수록 사람이 직접 처리해야 하는 작업은 줄어들고 자동화 수준은 높아진다.

하지만 동시에 잘못된 판단 하나가 실제 시스템에 영향을 미칠 가능성도 커진다.

답변 생성
    ↓
문서 수정
    ↓
코드 수정
    ↓
PR 생성
    ↓
Merge
    ↓
DB 변경
    ↓
Production 배포

위 작업들은 모두 AI가 기술적으로 수행할 수 있을 수 있다.

하지만

"AI가 할 수 있는가?"

와

"AI에게 맡겨도 되는가?"

는 서로 다른 문제다.

따라서 AI 엔지니어링에서는 AI의 능력만 높이는 것이 아니라 어떤 작업까지 AI에게 자율적으로 맡길 것인지 경계를 정의하는 것이 중요하다.

---

왜 자율성의 경계가 필요할까?

기존의 소프트웨어는 대부분 개발자가 미리 작성한 코드 경로 안에서 움직였다.

하지만 Agent는 현재 상황에 따라 스스로 다음 행동을 결정할 수 있다.

사용자 요청
    ↓
Agent 판단
    ↓
Tool 선택
    ↓
결과 분석
    ↓
다음 행동 결정

예를 들어 사용자가

"배포 과정에서 발생한 오류를 해결해줘."

라고 요청했다고 하자.

Agent는 다음과 같은 작업을 수행할 수 있다.

로그 조회
→ 코드 수정
→ 테스트
→ 설정 변경
→ 배포

여기서 코드 수정까지는 자동으로 허용할 수 있지만 실제 Production 배포까지 Agent가 직접 수행하도록 할 것인지는 별도의 문제다.

특히 작업의 영향 범위가 커질수록 잘못된 판단의 비용도 증가한다.

README 수정
→ 실패 비용 낮음

코드 수정
→ 중간

PR Merge
→ 높음

DB Migration
→ 매우 높음

Production 데이터 삭제
→ 매우 높음

따라서 모든 작업에 동일한 수준의 자율성을 부여하기보다 위험도에 따라 AI의 행동 범위를 조절해야 한다.

---

1. 작업의 위험도를 분류한다

가장 먼저 할 수 있는 것은 Agent가 수행할 수 있는 작업을 위험도에 따라 분류하는 것이다.

예를 들어 다음과 같이 나눌 수 있다.

낮은 위험

문서 검색
코드 검색
로그 조회
테스트 실행
문서 작성

→ 자동 수행

중간 위험

코드 수정
파일 생성
PR 생성

→ 자동 수행
→ 실행 기록 필요

높은 위험

PR Merge
DB Schema 변경
외부 고객에게 Email 발송
결제 처리

→ 사람 승인 필요

매우 높은 위험

Production 데이터 삭제
사용자 권한 변경
대량 결제 / 환불
Infrastructure 삭제

→ 강한 승인 절차
또는 Agent 수행 금지

즉 자율성은

AI 사용 / AI 사용 안 함

처럼 이분법적으로 결정하는 것이 아니라 작업별로 서로 다른 수준을 적용하는 것이 좋다.

---

2. AI의 자율성 수준을 단계적으로 정의한다

팀 차원에서는 AI가 어디까지 작업할 수 있는지를 Level 형태로 정의할 수도 있다.

예를 들어 다음과 같이 나눌 수 있다.

Level 0

AI가 방법만 제안
실제 작업은 사람이 수행

Level 1

AI가 결과물 생성
사람이 검토 후 적용

Level 2

AI가 작업 + 테스트 수행
사람이 승인 후 Merge

Level 3

AI가 작업 + 테스트 + PR 생성
기준을 충족하면 자동 Merge

Level 4

AI가 작업
→ 검증
→ 배포
→ 운영 확인

사람은 예외 상황만 처리

그리고 모든 업무를 같은 Level로 운영할 필요는 없다.

문서 수정
→ Level 4

간단한 테스트 추가
→ Level 3

비즈니스 로직 변경
→ Level 2

DB Migration
→ Level 1

Production 권한 변경
→ Level 0

이런 방식으로 업무의 위험도와 AI의 자율성을 연결할 수 있다.

---

3. Human Gate를 적절한 위치에 둔다

AI Agent 시스템에서 Human Gate는 사람이 개입해야 하는 지점을 의미한다.

하지만 모든 단계마다 사람이 승인하도록 만들면 Agent를 사용하는 의미가 크게 줄어든다.

Agent 작업
 ↓
사람 승인
 ↓
다음 작업
 ↓
사람 승인
 ↓
Tool 호출
 ↓
사람 승인

이렇게 되면 결국 사람이 다시 병목이 된다.

따라서 Human Gate는 실패 비용이 높은 작업에 집중적으로 배치하는 것이 좋다.

예를 들어

코드 검색
→ 자동

코드 수정
→ 자동

Test
→ 자동

PR 생성
→ 자동

Merge
→ 사람 승인

Production Deploy
→ 사람 승인

형태로 구성할 수 있다.

AI가 안전하게 자동화할 수 있는 영역은 최대한 자동화하고, 돌이키기 어렵거나 영향 범위가 큰 작업만 사람에게 넘기는 방식이다.

---

4. 승인 기준을 명확하게 정의한다

단순히

"중요한 작업은 사람에게 물어본다."

라고 정의하면 Agent가 무엇을 중요한 작업이라고 판단해야 하는지가 다시 모호해진다.

따라서 승인 조건도 가능한 한 시스템적으로 정의하는 것이 좋다.

Production 환경 변경
→ 승인 필요

DB Schema 변경
→ 승인 필요

사용자 데이터 삭제
→ 승인 필요

외부 메시지 전송
→ 조건부 승인

테스트 실행
→ 자동 허용

또는 Tool 자체에 Risk Level을 정의할 수 있다.

read_file
risk = LOW

write_file
risk = MEDIUM

merge_pull_request
risk = HIGH

delete_production_data
risk = CRITICAL

그리고 정책에 따라 자동으로 처리한다.

LOW
→ 자동 실행

MEDIUM
→ 실행 + 로그 기록

HIGH
→ 사람 승인

CRITICAL
→ 실행 금지 또는 다중 승인

이렇게 하면 Agent가 스스로 위험도를 해석하는 것보다 훨씬 안정적이다.

---

5. 역할별로 자율성 범위를 다르게 한다

Multi-Agent 시스템에서는 Agent마다 역할이 다르기 때문에 동일한 권한과 자율성을 부여할 필요가 없다.

예를 들어

Planner Agent
Worker Agent
Reviewer Agent
Deploy Agent

가 있다고 하자.

Planner는

Task 분석
계획 수립
Sub Task 분리

→ 실제 시스템 변경 권한 없음

Worker는

코드 조회
코드 수정
Test 실행

→ Merge 권한 없음

Reviewer는

Diff 조회
Architecture 검증
Test 결과 확인

→ 코드 수정 제한

Deploy Agent는

검증된 Artifact만 배포

→ Production 접근 가능
→ 별도의 승인 필요

처럼 역할을 나눌 수 있다.

하나의 Agent에게

계획
코드 수정
검증
승인
Merge
배포

를 모두 맡기는 것보다 역할을 분리하면 하나의 잘못된 판단이 전체 시스템에 영향을 미치는 것을 줄일 수 있다.

---

6. Agent가 자신의 작업을 스스로 승인하지 않도록 한다

AI가 코드를 작성하고

"잘 작성되었습니다."

라고 판단한 뒤 직접 Merge까지 한다면 검증과 실행 주체가 동일해진다.

가능하다면 역할을 분리하는 것이 좋다.

Worker Agent

코드 작성

Reviewer Agent

변경 검토

Test / Eval

기계적 검증

Human 또는 Policy

최종 승인

즉

작성자
=
검증자
=
승인자

가 되지 않도록 한다.

이는 사람 조직에서 개발자가 자신의 코드를 작성하고 별도의 코드 리뷰를 받는 구조와 유사하다.

---

7. 책임 주체를 명확하게 만든다

Agent가 자동으로 작업한다고 해서 책임까지 AI에게 넘어가는 것은 아니다.

예를 들어 Production에서 문제가 발생했을 때

AI가 알아서 배포했습니다.

는 책임 체계가 될 수 없다.

따라서 AI가 수행하는 작업에 대해서도 최종적으로 누가 책임을 가지는지 정의할 필요가 있다.

예를 들어

Code Agent
→ 개발팀 책임

Customer Agent
→ 고객지원팀 책임

Financial Agent
→ 재무팀 책임

Infrastructure Agent
→ DevOps / SRE 책임

처럼 운영할 수 있다.

특히 높은 위험의 작업은

Agent가 제안

       ↓

책임자가 승인

       ↓

실행

구조로 만드는 것이 좋다.

---

8. 예외 상황에서 누구에게 넘길지 정의한다

Agent는 모든 상황을 처리할 수 없다.

따라서

판단 불가능

정책 충돌

정보 부족

보안 위험

검증 반복 실패

같은 상황에서 어떻게 행동할지도 미리 정해야 한다.

예를 들어

정상 상황
→ Agent 자동 처리

Test 3회 실패
→ 개발자에게 전달

정책 충돌
→ 업무 담당자에게 전달

보안 위험 탐지
→ Security Team으로 전달

처럼 Escalation 경로를 정의할 수 있다.

좋은 Agent 시스템은 모든 문제를 AI가 해결하는 시스템이 아니라 AI가 해결하지 못하는 문제를 적절한 사람에게 넘길 수 있는 시스템이다.

---

9. 자동화 실패 시 중단할 수 있어야 한다

Agent가 실패했을 때 무조건 계속 시도하도록 만드는 것도 위험하다.

실패
 ↓
Retry
 ↓
실패
 ↓
Retry
 ↓
실패
 ↓
계속 진행

보다 일정 조건을 넘으면 멈추게 해야 한다.

Retry 3회 초과
→ 중단

Cost Limit 초과
→ 중단

Security Policy 위반
→ 즉시 중단

예상하지 못한 Tool 호출
→ 승인 요청

즉 Agent의 자율성에는 반드시 Stop Condition이 필요하다.

자율성이 높다는 것은 무제한으로 행동할 수 있다는 의미가 아니다.

---

10. 중요한 작업은 되돌릴 수 있도록 한다

AI에게 더 높은 자율성을 부여하려면 작업을 되돌릴 수 있는 구조가 중요하다.

예를 들어 코드 변경의 경우

Agent 수정
 ↓
Commit
 ↓
문제 발생
 ↓
Revert

가 가능하다.

DB 작업에서도 상황에 따라

Transaction
Backup
Soft Delete
Rollback

같은 방식을 사용할 수 있다.

즉

자율성 증가

를 위해서는

복구 가능성 증가

도 함께 필요하다.

실패하더라도 쉽게 복구할 수 있는 작업은 Agent에게 더 높은 자율성을 줄 수 있다.

---

11. 실행 기록을 남긴다

Agent에게 자율적인 실행 권한을 줄수록 누가 무엇을 했는지 추적할 수 있어야 한다.

예를 들어

Task ID
Agent
사용자 요청
실행한 Tool
승인자
변경 대상
실행 결과
시간

같은 정보를 남길 수 있다.

Agent

deploy-agent

Action

production_deploy

Approval

user_182

Result

SUCCESS

이러한 기록은 문제 발생 시

누가 요청했는가?

Agent가 무엇을 했는가?

어떤 승인을 받았는가?

실제로 무엇이 변경되었는가?

를 확인할 수 있게 한다.

따라서 Governance와 Observability도 서로 밀접하게 연결된다.

---

12. 자동 승인 조건도 관리한다

모든 작업을 항상 사람이 승인할 필요는 없다.

일정 조건을 만족하면 자동으로 승인할 수도 있다.

예를 들어 Coding Agent가

Unit Test PASS
Integration Test PASS
Regression PASS
Security Scan PASS
Architecture Test PASS

를 모두 만족했다고 하자.

그리고 변경 범위도

3 Files 이하
DB 변경 없음
Public API 변경 없음

이라면 자동 Merge를 허용할 수 있다.

Agent 작업
   ↓
Harness 검증
   ↓
Policy 확인
   ↓
조건 만족
   ↓
자동 승인

반대로 하나라도 기준을 벗어나면

Human Review

로 전환한다.

이런 방식으로 검증 결과에 따라 AI의 자율성을 동적으로 조절할 수도 있다.

---

13. 자율성은 Agent의 성능에 따라 점진적으로 확대한다

처음부터 Agent에게 Production 권한을 주는 것은 위험하다.

초기에는 낮은 단계에서 운영한다.

AI 제안
→ 사람 실행

성능이 검증되면

AI 실행
→ 사람 검토

그리고 충분히 안정화되면

AI 실행
→ 자동 검증
→ 예외만 사람 확인

으로 확대할 수 있다.

즉

신뢰
=
모델이 똑똑해 보이는 정도

가 아니라

실제 Eval 결과
운영 실패율
회귀 발생률
보안 사고
Human Intervention 비율

같은 데이터를 기반으로 자율성을 확대해야 한다.

---

14. 업무별로 서로 다른 정책을 적용한다

AI Agent 하나에 전체 회사 정책을 동일하게 적용하는 것보다 업무별로 다른 정책을 사용할 수 있다.

예를 들어

문서 Agent

높은 자율성

Coding Agent

중간 자율성

Payment Agent

낮은 자율성

Security Agent

조회 중심
실제 정책 변경은 사람 승인

처럼 구성한다.

같은 Agent에서도 작업에 따라 정책을 다르게 적용할 수 있다.

Customer 조회

자동

Customer 정보 수정

조건부 자동

Customer 삭제

사람 승인

즉 자율성은 Agent 단위뿐 아니라 행동(Action) 단위로 설계하는 것이 좋다.

---

15. 온톨로지를 이용해 업무 행동과 책임을 연결할 수도 있다

복잡한 업무 시스템에서는 업무 객체와 행동의 관계를 온톨로지로 관리할 수도 있다.

예를 들어

Customer
 ├─ View
 ├─ Update
 └─ Delete

Reservation
 ├─ View
 ├─ Cancel
 └─ Refund

각 행동에 정책을 연결할 수 있다.

Reservation.Cancel
→ Agent 자동 허용

Reservation.Refund
→ 일정 금액 이하 자동

Reservation.Refund > 1,000,000
→ 관리자 승인

이렇게 하면 기술적인 API 단위가 아니라 업무 의미를 기준으로 AI의 행동 범위를 정의할 수 있다.

---

보안과는 어떤 차이가 있을까?

권한과 책임 범위는 보안과 상당 부분 겹친다.

하지만 초점은 조금 다르다.

보안 (Security)

"AI가 무엇에 접근하고
무엇을 실행할 수 있는가?"

에 초점을 둔다.

반면

권한과 책임 범위
(Governance / Autonomy Boundary)

"AI에게 어디까지 스스로 결정하게 할 것인가?"

"어디에서 사람이 개입해야 하는가?"

"최종 책임은 누구에게 있는가?"

를 다룬다.

예를 들어

AI의 Production DB Write 권한 차단

→ 보안

이라면

AI가 DB 변경안을 만들 수 있지만
DBA 승인 후 실행

→ 권한과 책임 범위

라고 볼 수 있다.

즉 보안이 시스템의 접근과 실행을 제한하는 문제라면, 권한과 책임 범위는 AI의 자율성을 어디까지 허용하고 그 결과를 누가 책임질 것인가를 결정하는 문제에 가깝다.

---

권한과 책임 범위의 전체 구조

전체적인 구조를 정리하면 다음과 같다.

                    사용자 요청

                         ↓

                    Agent 판단

                         ↓

                    Action 선택

                         ↓

                  위험도 / 정책 확인

                         ↓

          ┌──────────────┼──────────────┐
          │              │              │

        LOW           MEDIUM          HIGH

          │              │              │

       자동 실행      자동 실행       Human Gate
                      + 기록

          └──────────────┼──────────────┘

                         ↓

                      실행

                         ↓

                Test / Eval / 검증

                         ↓

                      기록

                         ↓

               문제 발생 시 Escalation

실제로 활용할 수 있는 방법을 정리하면 다음과 같다.

• 위험도 기반 Action 분류
• AI 자율성 Level
• Human Gate
• Approval Policy
• Role Separation
• Multi-Agent 역할 분리
• Stop Condition
• Retry Limit
• 책임 주체 정의
• Escalation Rule
• Rollback
• Audit Log
• 자동 승인 조건
• Eval 기반 자율성 확대
• 업무별 Governance Policy
• Action 기반 정책
• Ontology 기반 업무 권한 정의

결국 AI 엔지니어링에서 권한과 책임 범위를 설계한다는 것은 AI에게 얼마나 많은 일을 시킬 것인가를 결정하는 문제가 아니다.

중요한 것은

어떤 일은 AI가 혼자 처리해도 되는가?

어떤 일은 검증 후 처리해야 하는가?

어떤 일은 반드시 사람이 승인해야 하는가?

문제가 발생하면 누가 책임지고 개입하는가?

를 명확하게 만드는 것이다.

AI의 능력이 좋아질수록 더 많은 작업을 자동화할 수 있게 되겠지만, 모든 작업을 자동화할 수 있다는 것과 모든 작업을 자동화해야 한다는 것은 다르다.

결국 좋은 AI Governance는 AI를 최대한 자유롭게 만드는 것이 아니라

안전하게 맡길 수 있는 영역에서는 최대한 자율적으로 움직이게 하고, 중요한 경계에서는 사람과 시스템이 통제권을 유지하게 만드는 것

이라고 볼 수 있다.

이렇게 하면 기존의 **보안 글과 중복은 최소화하면서**, `Governance` 쪽에서는 **자율성 수준·Human Gate·책임 주체·Escalation·자동 승인 기준**에 집중할 수 있습니다.