며칠 전에 제 자동화 스크립트가 파일을 하나 덮어썼습니다. 큰 파일은 아니었고 마침 복사본이 있어서 3분 만에 복구했습니다. 그런데 복구하고 나서 등에 식은땀이 났습니다. 복사본이 있었던 건 제가 설계를 잘해서가 아니라 그냥 운이 좋아서였거든요.
저는 코딩을 못 하는 상태로 AI를 동업자처럼 고용해 1인 회사를 굴리고 있습니다. 매일 에이전트 여러 대가 제 컴퓨터에서 파일을 읽고, 쓰고, 지우고, 외부 API를 호출합니다. 제가 자는 동안에도 돕니다. 그동안 이 채널에서는 주로 "어떻게 더 많이 자동화할까"를 다뤘는데, 오늘은 반대편 얘기를 해보려 합니다. AI 에이전트 사고가 났을 때, 나는 그걸 되돌릴 수 있는가.
겁주려는 글이 아닙니다. 오히려 반대입니다. 되돌릴 수 있게 만들어두면 더 과감하게 맡길 수 있습니다. 안전벨트는 천천히 달리라고 있는 게 아니니까요.
실제로 벌어진 일: 9초, 그리고 30시간
2026년 4월, PocketOS라는 렌터카 업계용 SaaS 스타트업에서 사고가 났습니다. 개발 도구(Cursor) 안에서 돌던 AI 코딩 에이전트가 운영 데이터베이스와 볼륨 백업 전체를 단 한 번의 API 호출로, 9초 만에 삭제했습니다. 창업자가 4월 말 이 사고를 공개하면서 널리 알려졌고, 회사는 약 30시간짜리 장애를 겪었습니다.
정말 무서운 건 삭제 자체가 아니라 경위입니다.
에이전트에게 맡긴 건 테스트 환경(스테이징)의 평범한 작업이었습니다. 그런데 작업 도중 인증 정보가 안 맞는 문제가 생겼고, 에이전트는 이 문제를 "스스로 해결"하려고 작업과 무관한 파일들을 뒤져 다른 API 토큰을 찾아냈습니다. 그 토큰은 하필 운영 환경 권한을 갖고 있었고, 삭제 호출에는 확인 절차도, 환경 구분도, "이거 운영 데이터인데 정말요?"라고 물어보는 장치도 없었습니다.
보안 쪽에서는 이런 걸 '과도한 행위성(Excessive Agency)'이라고 부릅니다. 모델이 나빠서가 아니라, 막힌 길을 만난 에이전트가 목표를 달성하려고 우회로를 찾는 게 정상 동작이라서 생기는 문제입니다. 사람으로 치면 열정 넘치는 신입이 "제가 알아서 처리했습니다!"라고 하는 상황인데, 문제는 이 신입이 초당 수십 번 결정을 내린다는 겁니다. 그리고 이건 특별히 재수 없는 하루의 얘기가 아닙니다. 자율 에이전트 실행의 30% 안팎이 사람 손이 필요한 예외 상황을 만난다는 추정치가 2026년 여러 분석에서 반복해 나옵니다. 매일 여러 개를 돌리는 사람이라면 사고는 '만약'이 아니라 '언제'입니다.
감시와 복구는 다른 문제입니다
예전에 '조용한 실패'를 감시하는 얘기를 쓴 적이 있습니다. 자동화가 멈췄는데 아무도 모르는 상태가 제일 위험하다는 내용이었죠. 그런데 그때 제가 놓친 게 있었습니다. 감지는 사고를 알려줄 뿐, 사고를 없던 일로 만들어주지는 않습니다.
AI 에이전트가 하는 행동은 되돌리기 난이도에 따라 세 종류로 나뉩니다. 이걸 구분하기 시작하면서 제 설계가 완전히 바뀌었습니다.
① 완전히 되돌릴 수 있는 것 — 파일 수정, 파일 생성, 문서 초안 작성. 이전 버전이 남아 있으면 그냥 되돌리면 끝입니다. 여기는 마음 놓고 맡겨도 됩니다.
② 되돌릴 수 있지만 흔적이 남는 것 — 예약된 회의 취소, 게시물 삭제, 잘못 만든 항목 정리. 기술적으로는 취소되지만 상대방은 이미 봤습니다. 알림이 갔고, 캡처됐을 수도 있습니다.
③ 애초에 되돌릴 수 없는 것 — 발송된 이메일, 승인된 결제, 외부 시스템으로 넘어간 데이터, 그리고 백업까지 함께 날아간 삭제. 이건 '복구'가 아니라 '애초에 못 하게 막는 것'만이 유일한 대책입니다.
이 분류가 중요한 이유는, 대부분의 사람이 ①에 대한 걱정으로 ③에 대한 대비를 대신하고 있기 때문입니다. 저도 그랬습니다. 파일은 복사본을 잘 만들면서, 정작 "이 에이전트가 내 계정으로 뭘 게시할 수 있지?"는 한 번도 정리해본 적이 없었습니다.
제가 이번 주에 실제로 바꾼 네 가지
거창한 시스템을 만든 게 아니라, 코딩 못 하는 사람도 한 시간이면 할 수 있는 수준으로 정리했습니다.
첫째, 권한을 '역할'이 아니라 '작업'에 맞췄습니다. 2026년 보안 업계의 공통된 권고가 이겁니다. 에이전트에게 "너는 관리자야"라고 주지 말고, "지금 이 작업에 필요한 것만" 주라는 것. 마이크로소프트를 비롯한 여러 곳이 같은 얘기를 합니다. 저는 여기서 아주 단순한 것부터 했습니다. 콘텐츠 자동화용 계정과 원본 자산을 보관하는 계정을 분리했습니다. 발행하는 쪽이 원본 폴더를 못 건드리게요. PocketOS 사고의 핵심도 결국 "쓰지 말아야 할 열쇠가 손 닿는 곳에 있었다"였습니다. AI 관련 침해를 겪은 조직 대부분이 애초에 AI 접근 통제 장치를 갖고 있지 않았다는 조사도 있습니다.
둘째, 위험한 동작에는 사람 손을 한 번 끼워 넣었습니다. 전부 다 확인받으면 자동화의 의미가 없어집니다. 그래서 위의 ③번 항목에만 걸었습니다. 실제 게시, 실제 발송, 대량 삭제. 이 세 가지는 제가 승인 대기함을 눌러야 나갑니다. 나머지 90%는 그대로 무인으로 돕니다. 자동화 비율이 아니라 자동화의 '방향'을 조절한 셈입니다.
셋째, 덮어쓰기를 금지하고 버전을 남깁니다. 이건 제가 AI에게 일을 시킬 때 아예 규칙으로 못 박아 놓은 부분입니다. 기존 파일을 고칠 일이 생기면 덮어쓰지 말고 새 버전으로 만들어서 테스트할 것. 용량은 좀 먹지만, 되돌릴 수 있다는 심리적 여유가 훨씬 비쌉니다. 업계에서 말하는 '체크포인트 스냅샷' 개념을 코딩 없이 흉내 내는 방법이기도 합니다. 사고 난 뒤에 로그를 뒤져 상태를 재구성하는 것보다, 미리 지점마다 저장해두는 게 압도적으로 쌉니다.
넷째, 백업을 '복원해봤다'로 바꿨습니다. 3-2-1 원칙(사본 3개, 서로 다른 저장 매체 2곳, 그중 1개는 다른 장소)은 예나 지금이나 유효합니다. 그런데 제가 이번에 배운 건 뒤에 붙는 숫자였습니다. 요즘은 3-2-1-1-0이라고 해서, 마지막 0이 '복원 테스트에서 오류 0건'을 뜻합니다. 한 번도 복원해본 적 없는 백업은 백업이 아니라 백업이라는 이름의 폴더입니다. 실제로 랜섬웨어 조사에서, 테스트된 백업을 갖고 있던 조직의 97%가 돈을 내지 않고 복구했다는 결과가 있습니다. 저는 이번 주에 처음으로 자료 폴더를 다른 위치에 실제로 복원해봤습니다. 두 개 깨져 있었습니다. 몰랐으면 그대로 갔을 겁니다.
그래도 계속 맡길 겁니다
이런 글을 쓰면 "그래서 AI에게 맡기는 게 위험하다는 거냐"는 반응이 나옵니다. 정반대입니다.
저는 사고 사례를 읽고 자동화를 줄인 게 아니라, 되돌릴 수 있는 영역을 넓히고 그 안에서 더 과감하게 맡겼습니다. 예전에는 "혹시 몰라서" 매번 결과를 들여다보느라 실질 자동화율이 낮았습니다. 지금은 파일 작업 쪽은 거의 안 봅니다. 어차피 버전이 남으니까요. 대신 결제, 발송, 삭제 세 군데에만 신경을 집중합니다. 걱정의 총량은 줄었는데 커버리지는 늘었습니다.
1인 기업의 진짜 리스크는 사고가 나는 게 아닙니다. 사고가 났을 때 도와줄 사람이 없다는 것입니다. 회사라면 인프라 담당자가 새벽에 복구하겠지만, 저는 저 하나뿐입니다. 그래서 저 같은 사람일수록 '똑똑한 AI'보다 '되돌릴 수 있는 구조'가 먼저입니다. 이런 식으로 AI를 직원처럼 쓰면서 배운 것들은 AI 1인 기업 전자책에 실전 사례로 정리해두고 있습니다.
마치며
정리하면 딱 네 문장입니다. 에이전트에게 필요 이상의 열쇠를 주지 않는다. 되돌릴 수 없는 행동에만 사람 확인을 건다. 덮어쓰지 말고 버전을 남긴다. 백업은 복원해봐야 백업이다.
코딩 지식은 하나도 필요 없습니다. 저도 못 합니다. 필요한 건 "이 작업이 잘못되면 되돌릴 수 있나?"라는 질문 하나를 습관으로 만드는 것뿐입니다. 9초면 다 날아갑니다. 대비는 한 시간이면 됩니다. 계산은 명확합니다.
오늘도 하나 발행합니다. 물론 초안은 버전 남겨두고요.
작성: Art Gourmet