AI가 폴더를 정리한 뒤 파일명이 바뀌고, 초안 문서를 다듬은 뒤 원래 문장이 덮어써졌다면 AI 작업 되돌리기가 필요해집니다. “다시 만들어”라고 요청할 수는 있지만, 그것은 방금 전 상태를 되찾는 명령이 아닙니다. AI는 새 결과를 만들 뿐, 사라진 파일명과 문장, 작업 맥락을 정확히 복원해 주지는 못합니다.
문서·파일·일정을 다루는 AI를 쓰기 시작하면 이 차이가 금방 커집니다. 결과가 마음에 들지 않을 때 필요한 것은 더 좋은 답변이 아니라, 무엇이 바뀌었고 어디로 돌아갈 수 있는지 아는 일입니다. 원래 상태가 남아 있지 않다면 재생성은 복구가 아니라 또 한 번의 변경입니다.
그래서 AI의 행동 범위가 넓어질수록 생성 기능보다 변경 이력·되돌리기 경로·사람 승인 지점을 먼저 설계해야 합니다. AI가 잘못할 수 있다는 가정에서 출발해야 작업을 맡긴 뒤에도 사람이 흐름을 이해하고 멈출 수 있습니다.
재생성은 왜 실행 취소가 아닌가
실행 취소는 방금 행동하기 전 상태로 돌아가는 기능입니다. 반면 재생성은 같은 요청에 대해 다른 결과를 하나 더 만드는 동작입니다. 이전 프롬프트를 고쳐 다시 답을 받는 일도 기존 결과를 보존한 채 새로운 갈래를 만드는 것이지, 그 사이에 일어난 변경을 되감는 일은 아닙니다.
이 차이는 채팅 안에서는 덜 눈에 띌 수 있습니다. 답변 한 문단이 달라진 경우에는 이전 대화를 찾아 비교하면 되기 때문입니다. 하지만 AI가 작업공간의 파일을 이름 변경·이동·수정하고, 캘린더에 일정을 넣고, 여러 문서에 같은 내용을 반영하기 시작하면 비교할 대상 자체가 사라질 수 있습니다.
여기서 필요한 개념이 가역성, 즉 되돌릴 수 있는 작업입니다. 초안 생성이나 분류 제안처럼 원본을 건드리지 않는 일은 대체로 가역적으로 설계하기 쉽습니다. 반대로 기존 파일을 덮어쓰거나 삭제하고, 외부에 내용을 보내고, 결제를 확정하는 행동은 되돌리는 비용과 영향이 커질 수 있습니다. 같은 AI 작업이라도 무엇을 바꾸는지에 따라 복구 기준을 달리 잡아야 합니다.
작업을 맡기기 전에 남겨야 할 것
AI가 원본을 바꾸기 전에는 사본·백업·버전이 남는지, 그리고 이전 상태를 확인할 기록이 남는지부터 살펴봐야 합니다. 특정 도구가 실행 취소를 제공한다고 가정할 필요는 없습니다. 어떤 방식이든 이전 상태를 확인할 수 있는 기록이 복구의 기준이 됩니다.
다음은 변경 이력입니다. 변경 이력은 결과물만 모아 두는 목록보다 구체적입니다. AI가 언제 어떤 대상에 무엇을 했는지, 변경 전후를 비교할 수 있는지, 실패하거나 멈춘 이유가 무엇인지가 남아야 합니다. 그래야 문제가 생겼을 때 “결과가 이상하다”에서 멈추지 않고, 어느 단계의 어떤 변경을 되돌리거나 검토할지 결정할 수 있습니다.
작업 범위도 작게 시작하는 편이 좋습니다. 처음부터 폴더 전체를 정리하게 하기보다 복사본이나 제한된 하위 폴더에서 한 번의 변경 유형만 맡기는 방식입니다. 한 번에 건드리는 대상이 줄어들면 변경 이력을 읽고 복구 경로를 시험하기도 쉬워집니다. AI가 더 많은 일을 할 수 있다는 사실과, 지금 그만큼 맡겨도 된다는 판단은 별개입니다.
사람 승인은 AI를 멈추게 하는 장치가 아니라 책임을 남기는 자리다
복구 경로가 있어도 실행하면 안 되는 변경이 있습니다. 파일 삭제, 외부 전송, 결제처럼 되돌리기 어렵거나 영향을 가늠하기 어려운 행동에는 사람이 마지막에 확인하는 지점을 남겨야 합니다. AI는 실행안을 준비하고, 사람은 대상·내용·수신자·금액처럼 실제 영향이 생기는 항목을 확인한 뒤 결정하는 방식입니다.
이때 사람 승인은 매 단계에 억지로 끼워 넣는 절차가 아닙니다. 어디까지는 AI가 초안과 제안을 만들고, 어디부터는 실제 변경이 발생하는지를 나누는 경계입니다. 승인 전에 AI가 바꿀 대상과 예상 결과를 보여 주고, 승인 뒤에는 그 결정과 실행 결과가 이력에 남아야 합니다. 그래야 나중에 누가 무엇을 판단했는지 다시 확인할 수 있습니다.
행동하는 AI를 검증하려면 실패를 감지하고 필요한 지점에서 멈춘 뒤, 이전 상태와 판단 근거를 다시 확인할 수 있어야 합니다. 하네스 엔지니어링이 말하는 검증 단계와 실패 감지도 이 과정을 뒷받침합니다. 사람이 이 흐름을 이해하고 멈출 수 있을 때 신뢰를 판단할 근거가 남습니다.
오늘 맡길 일에 먼저 붙일 세 질문
새 AI 기능을 연결하거나 자동화를 넓히기 전에는 아래 세 질문만 먼저 적어 보세요.
- 되돌릴 수 있는가? 잘못 실행됐을 때 원래 상태를 확인하고 복구할 경로가 있는가?
- 무엇이 바뀌었는가? 대상, 변경 내용, 실행 시점, 중단·실패 이유를 나중에 확인할 수 있는가?
- 누가 마지막에 승인하는가? 삭제·외부 전송·결제처럼 영향이 큰 행동을 사람이 확인하는 지점이 있는가?
셋 중 하나라도 답하기 어렵다면, AI가 할 수 있는 일을 더 늘리기보다 변경 범위를 줄이는 편이 낫습니다. 초안과 제안부터 맡기고, 변경 이력과 복구 경로가 실제로 작동하는 것을 확인한 뒤 다음 행동을 열어도 늦지 않습니다.
AI에게 일을 맡기는 기준은 “얼마나 많이 자동화할 수 있는가”가 아닙니다. 잘못된 결과가 나왔을 때 사람이 어디에서 상황을 파악하고, 무엇을 되돌리고, 어떤 행동을 멈출 수 있는가입니다. 다음 작업을 맡기기 전, 프롬프트 한 줄을 더 쓰기보다 먼저 그 길을 남겨 두세요.
