# AI 자율 실행, 승인은 어디까지 걸어야 하는가

> AI 에이전트에게 실행 권한을 주면 승인 절차를 어디까지 남길지가 곧 설계 문제가 된다. 되돌릴 수 있는 일과 없는 일을 가르는 기준, 그리고 실행됐다는 보고를 믿어도 되는지 검증하는 방법을 실제 운영 경험으로 정리했다.

- URL: https://aiaxnote.com/posts/where-to-draw-the-approval-line
- 발행: 2026-08-13T23:30:00+00:00
- 저자: 이인규 (40년차 개발자 · 주식회사 웰니스허브 대표)
- 발행: 주식회사 웰니스허브
- 태그: AI 자율 실행, AI AX, AI 에이전트, 자율기업, 업무 자동화

## 핵심 요약

- AI 자율 실행이란 AI가 관찰·분석·판단·실행까지 사람의 개입 없이 수행하는 상태를 말하며, 이때 남겨 둘 승인 지점을 정하는 것이 도입 설계의 핵심이 된다.
- 승인을 모든 단계에 걸면 자동화가 사람의 응답 속도에 묶여 멈춘다. 자리를 비운 사이 확인 버튼을 누를 사람이 없어 작업이 대기 상태로 남기 때문이다.
- 실무 기준은 되돌릴 수 있는가이다. 파일 수정·설치·빌드처럼 다시 하면 되는 일은 미리 허용하고, 배포·삭제·결제처럼 되돌릴 수 없는 일만 승인 대상으로 남긴다.
- 두 번째 관문은 실행 여부 검증이다. 연결됐다는 표시나 완료했다는 보고가 아니라 실제로 다녀간 흔적을 판정 기준으로 삼아야 한다.
- 자동화가 조용히 멈추는 사고는 대부분 실패 알림 없이 일어난다. 예약 작업이 사라졌는데 화면에는 정상으로 보이는 경우가 대표적이다.

---
AI 에이전트를 업무에 붙이면 곧 한 가지 질문에 부딪힙니다. 어디까지 알아서 하게 두고 어디부터 물어보게 할 것인가.

이 질문은 기술 문제처럼 보이지만 실제로는 운영 설계 문제입니다. 그리고 답을 미루면 둘 중 하나가 됩니다. 모든 단계에 승인을 걸어 자동화가 멈추거나, 아무것도 걸지 않아 되돌릴 수 없는 일이 조용히 나가거나.

## 승인을 다 걸면 자동화가 멈춘다

AI AX 2.0은 자율기업을 이렇게 정의합니다.

> 기업 운영의 상당 부분이 AI에 의해 관찰·분석·판단·실행되는 기업

그리고 진화 단계를 여섯 개로 나눕니다. Level 0 수작업 기업에서 시작해 디지털 기업, 자동화 기업, AI 지원 기업, Self-Evolving Enterprise를 거쳐 Level 5 Autonomous Enterprise에 이릅니다. 같은 원고는 인간의 역할을 전략·비전·윤리·책임·**최종 승인**으로, AI의 역할을 관찰·분석·추천·실행·최적화로 나눕니다.

여기서 실무자가 걸려 넘어지는 지점이 최종 승인입니다. 문장만 보면 사람이 마지막에 확인하면 되는 것처럼 읽힙니다. 그런데 무엇을 최종으로 볼지 정하지 않으면 결국 모든 단계가 최종이 됩니다.

그렇게 만들어 두면 자동화의 속도는 AI의 속도가 아니라 **사람이 확인 버튼을 누르는 속도**가 됩니다. 자리를 비운 사이 작업은 승인 대기 상태로 멈춰 있습니다. 밖에서 원격으로 붙여 쓰는 경우에는 이 문제가 더 자주 드러납니다.

부작용은 하나 더 있습니다. 승인 항목이 많아지면 사람은 내용을 읽지 않고 누르게 됩니다. 그러면 정작 중요한 승인에서도 판단이 흐려집니다. 승인을 늘린 결과가 승인의 질을 떨어뜨리는 셈입니다.

## 기준은 위험도가 아니라 가역성이다

우리가 실제로 쓰는 기준은 하나입니다. **되돌릴 수 있는가.**

<figure>
<svg viewBox="0 0 640 260" xmlns="http://www.w3.org/2000/svg" role="img" aria-label="AI 자율 실행의 승인 경계를 나타낸 그림. 되돌릴 수 있는 작업인 파일 수정, 패키지 설치, 빌드, 커밋은 사전 허용 영역에 있고 되돌릴 수 없는 작업인 배포, 삭제, 결제, 외부 발송은 승인 대상 영역에 있다">
  <title>승인 경계 - 가역성 기준</title>
  <rect x="0" y="0" width="640" height="260" fill="#ffffff"/>
  <g fontFamily="sans-serif" fontSize="13">
    <rect x="20" y="20" width="290" height="220" rx="6" fill="#e8f5e9" stroke="#a5d6a7"/>
    <text x="40" y="50" fill="#2e7d32" fontWeight="bold" fontSize="15">되돌릴 수 있다 → 사전 허용</text>
    <text x="40" y="82" fill="#374151">파일 수정</text>
    <text x="40" y="108" fill="#374151">패키지 설치</text>
    <text x="40" y="134" fill="#374151">빌드·테스트 실행</text>
    <text x="40" y="160" fill="#374151">버전 관리 커밋</text>
    <text x="40" y="200" fill="#6b7280" fontSize="12">틀리면 다시 하면 된다</text>

    <rect x="330" y="20" width="290" height="220" rx="6" fill="#fdecea" stroke="#f5b1a9"/>
    <text x="350" y="50" fill="#b71c1c" fontWeight="bold" fontSize="15">되돌릴 수 없다 → 승인 대상</text>
    <text x="350" y="82" fill="#374151">외부 배포·게시</text>
    <text x="350" y="108" fill="#374151">데이터 영구 삭제</text>
    <text x="350" y="134" fill="#374151">결제·송금</text>
    <text x="350" y="160" fill="#374151">외부 발송</text>
    <text x="350" y="200" fill="#6b7280" fontSize="12">되돌리는 비용이 훨씬 크다</text>
  </g>
</svg>
<figcaption>승인 경계는 작업의 중요도가 아니라 되돌릴 수 있는지로 가른다</figcaption>
</figure>

파일을 고치는 일, 패키지를 설치하는 일, 빌드를 돌리는 일, 버전 관리에 기록을 남기는 일은 잘못되어도 다시 하면 됩니다. 그래서 미리 허용해 둡니다. 반대로 외부에 내보내는 일, 지우는 일, 돈이 나가는 일은 되돌리는 쪽이 훨씬 비쌉니다. 이 넷만 사람을 부르게 남겼습니다.

이 기준의 장점은 판단이 빠르다는 것입니다. 새로운 작업이 생겼을 때 위험한가를 놓고 논쟁할 필요 없이 되돌릴 수 있는가만 물으면 자리가 정해집니다.

주의할 점도 있습니다. 되돌릴 수 있어 보이는 일이 실제로는 아닌 경우가 있습니다. 예를 들어 외부로 한번 나간 글은 지워도 이미 읽힌 뒤입니다. 그래서 **외부에 나가는 것은 되돌릴 수 없는 쪽으로 분류**합니다.

## 두 번째 관문 — 실행됐는지 어떻게 아는가

승인 경계를 정하고 나면 다음 문제가 옵니다. 맡긴 일이 실제로 돌고 있는지 확인하는 방법입니다.

이 부분은 우리도 사고로 배웠습니다. 30분마다 도는 예약 작업을 걸어 두고 운영하던 중, **프로그램 세션이 바뀌면 예약이 통째로 사라진다**는 사실을 한동안 몰랐습니다. 화면에는 연결 상태가 정상으로 보였고, 그래서 돌고 있다고 알고 있었습니다. 실제로는 아무것도 실행되지 않는 상태로 방치돼 있었습니다.

문제의 성격이 중요합니다. 이것은 **실패 알림이 오지 않는 종류의 고장**입니다. 에러가 나면 로그가 남고 알림이 옵니다. 그런데 아예 실행되지 않으면 남는 것이 없습니다. 조용히 멈춘 자동화는 며칠 뒤에야 발견됩니다.

그 뒤로 판정 기준을 바꿨습니다.

<div>

| 바꾸기 전 | 바꾼 뒤 |
|---|---|
| 연결됐다는 표시를 본다 | 다녀간 흔적이 남았는지 본다 |
| 완료했다는 보고를 믿는다 | 결과 화면이나 기록으로 확인한다 |
| 문제가 생기면 알림이 올 것이다 | 매 실행마다 예약이 살아 있는지 먼저 확인한다 |

</div>

지금은 루프가 돌 때마다 예약 작업이 남아 있는지를 **가장 먼저 확인하고, 없으면 스스로 다시 등록**하도록 만들어 두었습니다. 자가 복구를 절차 안에 넣은 것입니다.

같은 원리가 완료 보고에도 적용됩니다. 오늘도 게시 작업에서 겪었습니다. 게시 버튼을 눌렀는데 화면이 그대로 남아 있어 실패한 줄 알고 다시 눌렀더니, 첫 번째가 이미 성사돼 있어 **같은 글이 두 번 나갔습니다**. 화면 상태만으로는 성공과 실패를 구분할 수 없었던 것입니다. 지금은 다시 누르기 전에 새로고침해서 결과 수를 확인합니다.

## 도입할 때 정해 두면 좋은 세 가지

지금까지의 내용을 실무 순서로 옮기면 이렇습니다.

1. **되돌릴 수 없는 작업 목록을 먼저 적는다.** 조직마다 다릅니다. 고객에게 나가는 메시지가 여기 들어가는 회사도 있고, 재고를 확정하는 순간이 여기 들어가는 회사도 있습니다. 목록이 짧을수록 좋습니다.
2. **나머지는 미리 허용한다.** 목록에 없는 것을 매번 물어보게 두면 첫 번째 문제로 되돌아갑니다.
3. **실행 확인 방법을 함께 정한다.** 무엇을 보면 그 일이 실제로 됐다고 판정할지를 도입 시점에 정해 둡니다. 나중에 정하면 이미 조용히 멈춘 뒤입니다.

자율기업 단계로 올라간다는 것은 사람이 확인을 그만둔다는 뜻이 아닙니다. **확인해야 할 지점을 줄이고 그 지점의 정확도를 올린다는 뜻**에 가깝습니다.

## 정리

승인을 모든 단계에 걸면 자동화는 사람의 응답 속도에 묶여 멈춥니다. 되돌릴 수 있는 일은 미리 허용하고 되돌릴 수 없는 일만 승인 대상으로 남기는 편이 위험과 속도를 함께 잡습니다.

그리고 승인 경계만큼 중요한 것이 실행 확인입니다. 연결 표시나 완료 보고가 아니라 다녀간 흔적으로 판정해야 합니다. 자동화가 조용히 멈추는 사고는 알림 없이 일어나기 때문입니다.

AI 도입을 검토하고 계시다면 오늘 할 수 있는 일이 하나 있습니다. **되돌릴 수 없는 작업 목록을 종이 한 장에 적어 보는 것**입니다. 대개 생각보다 짧습니다. 그 목록 밖의 일들이 지금 불필요하게 사람을 기다리고 있을 가능성이 큽니다.

관련 글: [소버린 AI는 국산 모델을 만드는 일이 아니다](/posts/sovereign-ai-is-not-just-a-domestic-model)

<p style={{ fontSize: '0.9rem', color: '#6b7280' }}>
본문의 자율기업 정의·진화 단계·역할 구분은 저자의 저서 <em>AI AX 2.0</em> PART4(Autonomous Enterprise) 원고를 인용했습니다. 운영 사례는 2026년 8월 14일 기준으로 자체 시스템을 운영하며 겪은 내용입니다.
</p>