에이전트형 AI는 행동하기 전에 대개 백업하지 않는다

매일 Arxiv와 다른 출처에서 훑어보는 자료 중 상당수는 괴짜의 취향으로도 꽤 건조하다. 그래서 나는 AI 사용자나 지지자, 또는 피해자의 입장에서 감정적으로 와닿는 글을 늘 찾고 있다.

오늘 그런 소름 돋는 순간을 선사한 것은 미국의 새로운 학계 공동 연구였다. 에이전트형 프런티어 AI 모델이 피해를 초래할 행동을 하기 전에 얼마나 자주 돌이킬 수 없는 상황을 만드는지, 그리고 ‘그만!’이라고 입력하기도 전에 얼마나 빨리 그렇게 하는지를 살펴본 연구다(힌트: 클립보드에 ‘그만!’을 넣어 두자).

새 논문에서 맥락을 떼어 낸 이 상황은 최근 나에게도 벌어졌다. ChatGPT의 지시를 맹목적으로 따른 탓이었고, 먼저 가상 환경 전체를 복제할 생각은 미처 하지 못했다.

새 논문을 바탕으로 재구성한 내용이다. 최첨단 프레임워크나, 자신이 설치될 환경이 기본 설정과 다를 수 있다는 점을 전혀 고려하지 않는 인기 배포판을 설치할 때 우리 중 많은 사람이 겪어 본 아찔한 순간이다. 출처

이 끔찍하면서도 너무나 익숙한 사례에서 로봇에게도 그럴듯한 변명의 여지는 있다. 취약하고 까다로운 프레임워크에 새 라이브러리를 설치할 때 발생할 수 있는 모든 결과를 살펴보는 것이 보통은 아니기 때문이다. 하지만 새 논문은 어쩌면 그래야 한다고 주장한다. 나 역시 자동 저장 환경에서도 CTRL+S를 자주 누르는 사람으로서(그 키 입력을 무시하도록 설정된 환경에서도 말이다. 1990년대식 데이터 손실 트라우마 탓이다), 이에 동의하지 않을 수 없다.

좀 더 신중하고 조심스럽게 행동했다면 좋았을 사람은 DataTalks.Club 교육 플랫폼의 창립자 Alexey Grigorev다. 지난 3월, 서버를 이전하던 중 그의 Claude Code 에이전트가 프로덕션 인프라와 백업을 삭제해 웹사이트 데이터 2년 반 치가 손실됐다.

이와 비슷한 에이전트의 무모한 행동은 최근에도 있었다. 4월에는 Cursor 에이전트가 자동차 렌털 소프트웨어 업체 PocketOS의 프로덕션 데이터베이스와 백업을 삭제해 고객 예약이 이틀 넘게 중단됐다. 또 2월에는 OpenClaw 이메일 에이전트가 중단하라는 지시를 거듭 받았는데도 Meta AI 연구원의 받은 편지함에서 메시지를 삭제했다.

에이전트형이든 아니든, 프런티어 LLM은 신중하고 조심스럽게 행동하는 데 큰 어려움을 겪는다. 이 문제를 바로잡는 일이 문헌에서 독립된 연구 주제로 자리 잡았을 정도다.

잠깐 백업하자

새 논문의 저자들은 에이전트형 하네스에서 사용할 수 있는 멀티 에이전트 플러그인을 개발했다. 게스트 AI와 함께 작동하면서 필요할 때 백업을 만들도록 하는 플러그인이다.

연구에서 다룬 백업 문제와 제안된 해결책을 개괄한다. 205개 시나리오에서 프런티어 AI 모델 6종은 작업의 15.2%에서만 핵심 상태 정보를 백업했다. 반면 연구진의 BackUpper 시스템은 모든 중요 작업을 포괄했으며, 복원된 데이터는 원본과 평균 92.2% 유사했다(100% 유사도를 달성하기 어려운 이유는 아래에서 설명한다).

새 연구에서 가장 놀라운 점 중 하나는 프런티어 모델이 잠재적으로 위험한 행동을 하기 전에 백업을 하지 않는 경우가 얼마나 많은가 하는 것이다. 연구진은 GPT-5.6-Terra가 4.4%의 경우에만 중요 데이터를 백업했고, GPT-5.6-Sol은 테스트한 경우 중 단 5.9%에서만 백업했으며, Gemini 3.7-Flash는 그 비율이 2.4%에 불과한 경우도 있었다고 밝혔다.

가장 성능이 좋았던 Claude Opus-5조차 테스트한 경우 중 3분의 1이 넘는 경우에 중요 데이터를 백업하지 못했다.

논문은^† 다음과 같이 밝힌다.

‘프런티어 모델 6종에서 에이전트는 평균적으로 작업의 86.1%를 완료하지만, 후회할 일을 하기 전에 상태를 백업하는 경우는 15.2%에 불과하다. Codex의 GPT 5.6-Sol은 작업의 5.9%에서만, Hermes의 DeepSeek V4-Pro는 단 2.9%에서만 백업한다.

‘이러한 결과는 현재 에이전트의 백업 인식이 여전히 제한적이며 전용 백업 지원이 필요하다는 점을 보여 준다.’

저자들이 BackUpper라고 이름 붙인 해결책은 하네스 안에서 에이전트와 함께 작동하는 일종의 그림자 프로세스다. 에이전트가 하려는 일을 확인하고, 유용한 무언가를 잃을 위험이 있으면 먼저 백업을 만든다.

소프트웨어 업그레이드처럼 일상적인 작업에는 간단한 규칙을 적용하고, 더 까다로운 상황에서는 더 작은 AI 모델을 불러 무엇을 저장해야 하는지 판단하게 한다.

테스트에서 BackUpper는 모든 핵심 작업을 처리했고, 복원된 데이터는 원본과 92.2% 유사했으며 작업당 0.014달러의 추가 비용이 들었다. 이 맥락에서는 큰 비용이 아니지만, 수십억 명의 고객에게 서비스를 제공하는 최첨단 LLM에는 상당한 지출이다. 이런 이유로 기술 대기업이 자체적으로 해결책을 내놓기를 기대하기보다는, 이런 성격의 외부 서비스나 하네스에 해당 기능을 기본으로 탑재하는 방식이 상황을 개선할 가능성이 더 높을 수 있다. 기술 대기업은 가격 인상이나 토큰 인플레이션을 통해 추가 비용을 소비자에게 전가할 것으로 합리적으로 예상할 수 있기 때문이다.

이 프레임워크는 실제로 사람들이 데이터를 잃은 뒤 저장해 둘 걸 그랬다고 후회한 사례를 바탕으로 구축된 205개 작업 벤치마크인 RegretBench를 기반으로 한다. 이 벤치마크는 AI 에이전트가 되돌릴 수 없을지도 모르는 변경을 하기 전에 해당 데이터를 보존할 만큼 앞을 내다볼 수 있는지 테스트한다. 사례에 포함된 사건은 X.com, GitHub, Stack Overflow 등의 플랫폼에 올라온 온라인 토론과 보고서에서 수집했다.

RegretBench가 실제 사건을 테스트 시나리오로 전환하는 방식의 개요. 기록된 각 사례는 데이터 손실을 일으킨 작업, 현실적인 작업 환경, 일련의 지시를 활용해 재구성한다. 이 예에서는 ipykernel을 업그레이드하면 기존 traitlets 버전이 아무런 알림 없이 교체된다. 에이전트는 작업을 마칠 수 있지만, 원래 설치를 복구할 방법은 사라진다.

완벽주의자에게 92%라는 수치는 실망스러울 수 있지만, 저자들은 특정 유형의 데이터를 복구하는 데 기술적 장애물이 있다고 지적한다.

‘완벽한 복구에 이르지 못하는 데에는 주로 두 가지 이유가 있습니다. 게시물 ID와 같은 일부 필드는 서비스가 데이터를 기록할 때 대개 새로 생성하므로, 원래 값을 재현하지 못하는 경우가 많습니다. 그 밖의 차이는 이메일 읽음 표시처럼 사소한 메타데이터에서 비롯되는데, 이런 항목은 후회의 계기가 되는 경우가 드뭅니다.’

테스트에서는 손상이 이미 발생한 뒤 원래 상태와 33.8% 유사한 수준으로 복구할 수 있었다. 복구를 하지 않았을 때는 14.3%에 그쳤다.

논문은 향후 훈련을 통해 백업에 대한 인식을 높일 수 있으며, 이후 버전의 BackUpper는 위험이 낮은 작업을 건너뛰고 웹 및 컴퓨터 사용 에이전트까지 보호 범위를 넓히도록 학습시킬 수 있다고 제안한다.

BackUpper는 Claude Code, Codex, Hermes, OpenHands, DeepSeek Harness, OpenClaw를 지원한다. 저자들은 관련 데이터세트와 함께 코드를 공개했지만, 데이터세트를 이용하려면 양식을 통해 허가를 요청해야 한다. 프로젝트의 웹사이트에는 추가 정보와 짧고 간단한 설명 동영상도 올라와 있다.

방법론

RegretBench를 구축할 때는 에이전트가 백업을 언제 해야 하는지 스스로 판단하는 능력을 평가할 수 있도록, 에이전트에 내장된 백업 시스템이 이미 보호한 데이터는 의도적으로 제외했다. 그런 다음 Claude Opus-5와 GPT-5.6-Sol의 도움을 받아 테스트 시나리오를 구성하고, 시나리오가 제대로 작동하며 원래 사건을 정확히 반영하는지 수동으로 확인했다.

RegretBench의 205개 테스트는 터미널 작업, 데이터베이스, 웹 애플리케이션, 이메일, DevOps의 다섯 분야를 다룬다. 사건은 주로 소프트웨어 개발 및 생산성 플랫폼(44.4%), 소셜 또는 커뮤니티 토론(39%), 아카이브 및 언론 보도(16.6%)에서 비롯됐다.

RegretBench의 실제 사건 출처를 세 가지 범주로 나눈 설명.

평가 대상인 최첨단 모델 6종은 Claude Code의 Claude Opus-5와 Claude Sonnet-5, Codex의 GPT-5.6-Sol과 GPT-5.6-Terra, Hermes의 Gemini 3.7-Flash와 DeepSeek V4-Pro였다.

모든 테스트에서 기본 추론 설정을 사용했으며, 자동 백업 보호는 작업 공간 스냅샷으로 제한했다. 이에 따라 그 밖의 백업은 모두 에이전트가 스스로 내린 결정에 따른 것으로 간주할 수 있었다.

성능 평가에는 Claude Sonnet-5 기반 AI 평가자 두 명을 사용했다. 작업 통과율(Task Pass Rate, PR)은 모든 사용자 요청을 충족한 작업의 비율로 계산했다. 백업 평가는 작업 공간 외부(OOW)에서 이루어진 각 변경 사항을 대상으로, 복구에 충분한 정보가 사전에 보존되었는지 확인했다.

사용한 백업 지표는 기록된 데이터 손실과 관련된 구체적인 작업을 반영하는 Regret Moment Backup Rate(RMBR)와 에이전트의 작업 디렉터리 외부에서 이루어진 모든 변경 사항을 반영하는 Out-of-Workspace Backup Rate(OWBR)였다.

백업 판정기의 평가 결과를 사람의 주석과 대조한 결과, 일치율은 95.3%였다.

결과

백업 인식 부족이 AI 모델 때문인지, 모델을 실행하는 프레임워크 때문인지 확인하기 위해 Claude Opus-5, GPT-5.6-Sol, DeepSeek V4-Pro를 각각 Claude Code, Codex, Hermes에서 RegretBench 작업 60개로 먼저 평가했다.

중요 데이터가 백업된 작업의 비율은 프레임워크에 따라 거의 달라지지 않아, 주된 원인은 모델 자체인 것으로 나타났다. GPT-5.4, GPT-5.5, GPT-5.6-Sol을 사용해 일반적인 AI 역량과 백업 인식 간의 관계도 조사했다.

일반적인 역량은 거듭 향상됐지만, 백업 인식은 이에 상응해 개선되지 않았다.

AI 모델 6종의 RegretBench 테스트 결과. 왼쪽은 작업 완료율과 사전에 백업된 중요 조치의 비율을 비교한 것으로, 대부분의 모델이 높은 성공률을 보였지만 백업 인식은 부족했음을 보여준다. 오른쪽은 작업당 평균 도구 호출 횟수이며, 백업 작업은 파란색으로 표시했다. Claude Opus-5의 백업률이 가장 높았지만, 도구 호출의 8.9%가 백업에 사용됐다.

GPT-5.4, GPT-5.5, GPT-5.6-Sol을 사용해 일반적인 AI 역량과 백업 인식 간의 관계도 조사했다. 일반적인 역량은 거듭 향상됐지만, 백업 인식은 이에 상응해 개선되지 않았다.

BackUpper

BackUpper는 자원 소모량이 서로 다른 4단계 보호 기능을 제공한다. 1단계에서는 파괴적인 명령을 파일을 휴지통으로 옮기는 것처럼 되돌릴 수 있는 방법으로 대체한다. 2단계에서는 작업과 백업 명령을 짝지어 업그레이드 전에 패키지 버전을 기록하는 등의 조치를 한다. 3단계에서는 영향을 받는 작업 공간 파일의 스냅샷을 생성한다. 4단계에서는 GPT-5.6-Luna 하위 에이전트를 사용해 더 복잡한 작업의 영향을 받는 데이터를 식별하고 보존한다.

BackUpper를 활성화하면 모델 6종 모두에서 상태를 변경하는 모든 조치가 백업 대상에 포함됐다. 반면 BackUpper를 사용하지 않았을 때 중요 조치의 평균 백업률은 15.2%, 기타 변경 사항의 평균 백업률은 17.4%였다.

BackUpper의 백업 범위와 복원 결과. 왼쪽의 파란색과 주황색 막대는 각 모델의 중요 조치 및 작업 공간 밖에서 발생한 기타 변경 사항의 백업률을 나타낸다. 짙은 녹색 점선 테두리는 복원 정확도를, 연한 녹색 점선 테두리는 BackUpper를 사용했을 때의 100% 백업 범위를 나타낸다. 오른쪽은 도구 범주 5개에서의 복원 정확도를 비교한다. BackUpper를 사용한 경우는 녹색, 이후 Claude Opus-5로 복구한 경우는 보라색, 복원하지 않은 경우는 회색으로 표시했다. 모든 범주에서 BackUpper의 정확도가 가장 높았다.

자동 평가기가 성공적인 것으로 판정한 백업 가운데 94%는 사람 검토자도 성공적인 것으로 확인했다.

원래 상태와의 평균 유사도는 92.2%로 복구됐으며, Claude Opus-5를 사용했을 때는 33.8%, 복구하지 않았을 때는 14.3%였다(위 이미지 참조). 앞서 언급했듯이, 나머지 차이는 대부분 새로 생성된 식별자와 이메일 읽음 표시를 포함한 사소한 메타데이터 때문이었다.

직접 해보기…?

에이전트에게 직접 백업을 만들도록 상세한 지침을 제공했을 때 중요 조치의 81.4%가 보호됐다. BackUpper를 사용했을 때는 100%였다. 실패 사례의 4분의 3은 복구에 필요한 정보가 백업에 충분히 담기지 않은 데서 비롯됐다.

AI 모델 6종을 사용해 작업 205개에서 다섯 가지 접근법의 백업률을 비교했다. 왼쪽 그래프는 나중에 후회하게 된 조치를 하기 전에 생성한 백업을, 오른쪽 그래프는 작업 공간 밖의 기타 변경 사항에 대한 보호를 보여준다. BackUpper는 두 범주 모두에서 완전한 백업 범위를 달성했다. 에이전트에게 상세한 백업 지침을 제공한 경우에는 각각 81.4%와 80.5%였다.

프롬프트 캐싱을 적용하자 작업당 백업 비용이 $0.344에서 $0.014로 줄었고, 지연 시간도 31.7% 감소했다. 필요한 토큰 수는 7배 적었는데, 이는 주로 반복적인 작업을 AI 지원 없이 처리했기 때문이다.

Terminal-Bench 4와 DeepSWE의 추가 작업 40개에서도 GPT-5.6-Sol과 Claude Opus-5를 사용해 작업 완료율을 낮추지 않으면서 백업 적용률 100%를 달성했다.

평가한 선택적 백업 정책은 세 가지였다. 중요한 변경 사항을 대상으로 하는 영향이 큰 변경, 사용자의 지시 범위를 벗어난 변경 사항을 대상으로 하는 요청 범위 밖의 변경, 사람이 작성한 자료를 대상으로 하는 사람의 작업물이다. 이 정책들의 평균 F1 점수는 사람의 판단을 기준으로 84.5%였다.

재사용 가능한 백업 규칙을 학습하는 BackUpper의 능력도 시험했다. 터미널 작업 30개를 추가로 수행한 뒤 규칙 기반 백업 적용률은 14.9%에서 31.2%로 높아졌고, GPT-5.6-Luna 서브에이전트에 대한 의존도는 낮아졌다.

결론

생업을 고려하면 에이전트형 실험을 시작했어야 할 때보다 한참 늦게 뛰어들었다. 하지만 에이전트형 자기 절제가 명백히 프리알파 단계라는 점이 두려워 몇 주 전까지는 망설였다. 그러다 마침내 Codex를 Windows VM에서 마음껏 실행해 보기로 했다.

VM 안에서 작업할 때조차 나는 Astra가 앞뒤 가리지 않고 서두르는 성향을 알고 있어 지시 범위를 매우 신중하게 설정한다. 데이터가 손실되거나 코드가 망가져 되돌릴 방법이 없어진 뒤에는 사과밖에 할 수 없기 때문이다. 그곳에서 개발 중인 파이썬 프레임워크에는 원클릭 증분 기능인 ‘네트워크 공유 폴더에 .7z 파일로 저장’ 도 포함되어 있다. 이 기능은 프레임워크 전체를 압축해 백업하며, 나는 이를 자주 실행한다.

에이전트형 AI는 아직 아주, 아주 초기 단계다. 지루할 정도로 꼼꼼하게 세부 사항에 주의를 기울이지 않으면 ‘사용하다가 잃어버리는’ 일이 생긴다. 에이전트형 백업 체계는 아직 공식화되지 않았을 뿐 아니라, 구상조차 되지 않았다.

* 제목은 후회하기 전에 백업하라: 코딩 에이전트의 백업 인식 측정과 백업 자동화.

^† 강조는 저자들이 한 것이지 내가 한 것이 아니다. 하이퍼링크는 저자들이 본문에 넣은 인용을 바탕으로 내가 추가했다.

최초 게재일: 2026년 10월 22일 목요일