블로그 목록으로 
55
“백업 좀 해줘.”
개발자가 AI에게 전달한 요청은 이 한마디였습니다. 하지만 불과 몇 초 뒤, 수년간 쌓아온 사진과 코드, 문서, 개인 설정이 담긴 사용자 폴더가 휴지통도 거치지 않고 통째로 삭제되었습니다.
등골이 서늘해진 순간, AI가 남긴 답변은 황당했습니다.
“Sorry, typo.” (오타가 있었네요. 죄송해요.)
이 사건은 해외 기술 매체 Tom’s Hardware의 보도에 실린 실제 사례입니다. 우리가 맞이한 ‘AI 에이전트 시대’의 가능성과 위험을 동시에 보여주고 있죠.
AI는 이제 단순히 질문에 답하는 수준을 넘어, 직접 코드를 실행하고 시스템 설정까지 변경하고 있습니다. 그만큼 단 한 번의 작은 오해나 실수가 불러오는 위험의 크기도 비례해서 점차 커질 수 밖에 없는데요. 이에 따라 AI 에이전트의 안전성에 대한 우려도 함께 높아지고 있습니다.
이번 글에서는 이 사건이 어떻게 발생했는지 살펴보고, AI 에이전트를 안전하게 활용하기 위해 어떤 기술적 장치와 전문성이 필요한지 살펴보겠습니다.
무슨 일이 있었나? 3초 만에 사라진 폴더
보도에 따르면 개발자는 AI 코딩 에이전트에게 시스템 백업을 요청했습니다. AI는 백업 파일을 잠시 담아둘 임시 폴더를 만들려 했고, 그 과정에서 자신이 방금 만든 임시 폴더의 위치를 착각했습니다. 그리고 자신이 만든 임시 폴더를 삭제한다는 생각으로 다음과 같은 명령을 실행했습니다.
rm -rf “/c/Users/harih/”
문제는 이 명령이 임시 폴더가 아니라 사용자의 프로필 폴더 전체를 가리키고 있었다는 점입니다.
여기서 rm -rf 는 유닉스 계열 시스템에서 지정한 폴더와 그 안의 파일을 영구적으로 삭제하는 명령입니다. 일반적인 파일 삭제와 달리 휴지통을 거치지 않기 때문에 실행 후 복구가 어렵습니다. 즉, AI는 자신이 만든 임시 폴더를 정리한다고 판단했지만, 실제로는 사용자의 홈 폴더를 삭제해버렸습니다.
삭제가 끝나고 뒤늦게 상황을 알아챈 AI의 답변은 바로 “Sorry, typo”였습니다. 사람이라면 몇 시간을 자책할 실수를, AI는 ‘오타’라는 말 한마디로 정리해버린 거죠.
하지만 문제의 핵심은 AI가 큰 실수를 ‘오타’라는 말로 넘겼다는 데 있지 않습니다. AI는 사용자의 요청을 잘못 이해하거나 상황을 잘못 판단할 수 있습니다. 중요한 것은 그러한 실수가 실제 시스템에 어느 정도까지 영향을 미칠 수 있도록 허용되어 있었느냐입니다.
왜 이런 일이 벌어졌을까? ‘멍청해서’가 아니다.
이 사건을 단순히 ‘AI가 아직 똑똑하지 않아서 발생한 사고’라고 보기는 어렵습니다. 문제의 원인은 AI에게 안전장치 없이 위험한 권한을 쥐여줬을 때 필연적으로 생기는 구조적 결함에 가깝습니다.
사건의 원인은 크게 네 가지로 정리할 수 있습니다.
① 경로 형식의 오해
이 사건은 Windows 컴퓨터에서 유닉스식 명령을 쓰는 환경(예: Git Bash)에서 벌어졌습니다. 문제는 같은 폴더를 가리키는 ‘주소 표기법’이 두 가지였다는 점입니다. Windows에서는 C:\Users로, 유닉스식 셸에서는 같은 위치를 /c/Users/로 표기합니다. AI는 자신이 만든 임시 폴더가 Windows식 주소로 표시될 것이라고 예상했지만, 화면에는 유닉스식 주소가 나타났고, 이를 다른 위치로 착각해 해당 폴더를 삭제해 버린 것입니다.
② 되돌릴 수 없는 삭제 방식
일반적으로 사용자가 파일을 삭제하면 휴지통을 거치기 때문에 잘못 삭제하더라도 복구할 수 있습니다. 하지만 이 사건에서는 즉시 영구 삭제를 수행하는 rm -rf 명령을 써서 복구 기회가 차단됐습니다.
③ 지나치게 넓은 접근 권한
사실 가장 근본적인 문제는 AI가 사용자의 홈 폴더 전체에 접근할 수 있었다는 점입니다. 해당 작업 공간(Project Directory)안에만 머물도록 하는 ‘안전 울타리’가 없었던 것이죠. AI가 특정 프로젝트 폴더에서만 파일을 생성하거나 삭제할 수 있도록 권한이 제한되어 있었다면, 경로를 잘못 판단하더라도 사용자 폴더 전체가 삭제되는 상황은 막을 수 있었을 것입니다.
④ 보이는 명령과 실행 명령의 불일치
이 사고의 직접적인 원인은 무분별한 삭제 명령 실행이었지만, 경로를 다루는 과정에는 또 하나의 위험이 있습니다.사용자가 승인 화면에서 확인한 명령과 실제 셸에서 실행되는 명령의 범위가 달라질 수 있다는 점입니다. 틸드(~), 환경 변수($HOME), 와일드카드(*) 등은 실행 과정에서 실제 경로로 변환됩니다. 이때 경로가 예상보다 넓게 해석되면 사용자가 의도한 범위를 넘어 파일이 변경되거나 삭제될 수 있습니다.
정리하면, 이 사고는 단순히 ‘AI의 지능 부족’ 때문에 발생한 것이 아닙니다. 경로 표기의 모호함과 되돌릴 수 없는 삭제 방식, 지나치게 넓은 권한, 보이는 명령과 실제 실행되는 명령의 차이가 겹치며 발생한 구조적인 문제에 가깝습니다. 그렇다면 AI의 실수를 실제 피해로 이어지지 않게 하려면 어떤 안전장치가 필요할까요?
AI 개발사는 어떻게 대응하고 있나?
이런 사고가 알려지면 자연스럽게 이런 의문이 생깁니다. “그렇다면 AI 개발사들은 어떻게 대응하고 있을까?”
AI 기업들은 단순히 모델의 성능을 높이는 데서 한발 더 나아가고 있습니다. 모델의 실수를 완전히 없애기보다, 실수하더라도 피해가 다른 영역으로 번지지 않도록 실행 환경을 분리하는 데 초점을 맞추고 있습니다.
Claude를 개발한 Anthropic의 ‘컨테인먼트(격리) 전략’이 대표적입니다. Anthropic은 위험 요인을 사용자의 오·남용, 모델의 오작동, 외부 공격 등 세 가지로 구분하고 제품의 특성에 따라 서로 다른 격리 방식을 적용합니다.
웹 기반 서비스에서는 코드가 사용자 컴퓨터가 아닌 회사 서버의 격리된 컨테이너(gVisor) 안에서 실행됩니다. 개발자용 도구는 운영체제 수준의 샌드박스를 적용해 AI가 정해진 작업 공간 안에서만 움직이도록 제한합니다. 비전문가용 제품은 실행 환경 전체를 가상머신으로 분리하고, 비밀번호와 같은 민감 정보가 내부로 전달되지 않도록 설계합니다.
Anthropic은 이러한 격리 방식을 실제 제품에 적용하는 과정에서 두 가지 중요한 사실을 확인했습니다.
첫째, 사용자에게 매번 “이 작업을 허용할까요?”라고 묻는 것만으로는 충분하지 않았습니다. 사용자들이 승인 요청의 약 93%를 그대로 허용하는 ‘승인 피로’가 나타났기 때문입니다. 이에 Anthropic은 사용자의 판단에만 의존하지 않고, 실행 환경 자체에서 위험한 작업을 제한하는 방식을 강화했습니다. 그 결과 불필요한 승인 요청을 약 84% 줄일 수 있었습니다.
둘째, 보안상 취약한 지점은 기존의 검증된 격리 기술보다 자체 개발한 구성 요소에서 더 자주 발견됐습니다. 하이퍼바이저나 시스템 호출 필터처럼 오랫동안 검증된 기술은 비교적 안정적으로 작동한 반면, 자체 제작한 보안 프록시 등에서는 취약점이 드러났습니다.
이는 AI 에이전트의 안전성이 단순히 몇 가지 보안 기능을 추가한다고 확보되는 것이 아니라, 검증된 기술을 적절하게 조합하고 전체 실행 환경을 체계적으로 설계해야 하는 문제라는 점을 보여줍니다.
안전한 AI 에이전트를 만들기 위해 필요한 기술은?
앞서 살펴본 것처럼 AI 에이전트의 안전성은 한두 가지 보안 기능만으로 확보할 수 없습니다. AI가 접근할 수 있는 범위부터 명령을 실행하고 문제가 발생했을 때 복구하는 과정까지, 여러 안전장치가 함께 작동해야 합니다. 그렇다면 안전한 AI 에이전트를 만들고 현장에 적용하려면 어떤 기술이 필요할까요? 핵심 요소를 하나씩 살펴보겠습니다.
- 샌드박싱 및 환경 격리
AI를 컨테이너나 가상머신 안에서 실행해 홈 폴더나 시스템 영역에 접근하지 못하도록 제한합니다. 오류가 발생하더라도 피해가 격리된 환경 밖으로 번지지 않게 하는 가장 기본적인 안전장치입니다. - 최소 권한 원칙
AI에는 작업에 필요한 최소한의 권한만 부여하고, 미리 허용한 경로에서만 파일을 생성하거나 삭제할 수 있도록 제한합니다. 예를 들어 특정 프로젝트 폴더 밖에는 접근할 수 없게 만드는 방식입니다. - 복구 가능한 삭제
‘rm’처럼 파일을 즉시 삭제하는 명령 대신 휴지통을 거치도록 설계합니다. 잘못된 명령이 실행되더라도 파일을 복구할 수 있는 여지를 남기는 것입니다. - 파괴적 명령 차단
‘rm, dd, shred, wipefs’처럼 데이터 손실로 이어질 수 있는 명령은 별도로 분류해 제한합니다. 실행이 꼭 필요한 경우에는 작업 대상과 범위를 다시 보여주고 추가 확인을 거치도록 합니다. - 실행 전 최종 명령 검증
화면에 입력된 명령이 아니라 셸에서 실제로 실행될 최종 명령과 경로를 확인합니다. 틸드(~), 환경 변수, 와일드카드 등이 변환된 결과에 홈 폴더나 프로젝트 외부 경로가 포함되면 실행을 차단하거나 사용자에게 확인을 요청합니다. - 사람 개입(Human-in-the-loop)과 자동 백업
되돌릴 수 없는 작업에는 사용자의 최종 확인 절차를 남겨두고, 중요한 데이터는 작업 전에 자동으로 백업합니다. 다만 모든 작업에 승인을 요구하면 ‘승인 피로’가 생길 수 있으므로, 실제 피해 가능성이 큰 작업에만 확인 절차를 선택적으로 적용해야 합니다.
이러한 안전장치는 각각의 개념만 놓고 보면 그리 복잡하지 않습니다. 하지만 실제 제품에 적용하려면 여러 장치가 유기적으로 작동해야 하고, 안전성과 성능, 사용 편의성 사이의 균형도 고려해야 합니다. 앞서 살펴본 Anthropic의 사례처럼 자체 개발한 구성 요소가 새로운 취약점이 될 가능성도 있습니다.
결국 AI 에이전트의 안전성은 특정 기능 하나를 추가한다고 확보되는 것이 아닙니다. 설계부터 개발, 운영에 이르는 전 과정에서 일관된 기준과 체계를 적용해야 합니다.
그래서 AI 에이전트에는 전문성이 필요합니다.
앞서 살펴본 것처럼 AI 에이전트의 경쟁력은 모델의 성능만으로 결정되지 않습니다. AI가 어떤 범위까지 접근할 수 있는지, 위험한 작업을 어떻게 통제하는지, 문제가 발생했을 때 되돌릴 수 있는지까지 함께 고려해야 합니다. 아무리 뛰어난 AI라도 안심하고 일을 맡길 수 없다면 실제 업무에 활용하기 어렵기 때문입니다.
이러한 안전 체계를 기업이나 개인이 직접 구축하고 지속적으로 운영하기는 쉽지 않습니다. 실행 환경을 격리하고, 권한을 세분화하고, 위험한 명령을 통제하는 동시에 새로운 위협에도 계속 대응해야 합니다. 안전성을 높이면서 성능과 사용 편의성을 유지하는 일도 필요합니다.
이 지점에서 라온피플이 AI와 블록체인 기술을 함께 다뤄온 경험은 중요한 의미를 갖습니다. 두 기술은 서로 다른 영역처럼 보이지만, 그 바탕에는 ‘신뢰할 수 있는 시스템을 어떻게 설계할 것인가’라는 공통된 질문을 품고 있기 때문입니다.
신뢰는 단순히 좋은 결과를 내는 것만으로 만들어지지 않습니다. 결과가 만들어지는 과정을 확인할 수 있어야 하고, 데이터가 함부로 변경되거나 훼손되지 않도록 설계되어야 합니다. 데이터의 무결성과 검증 가능성을 다루는 블록체인의 문제의식은 AI 에이전트를 안전하게 활용하는 문제와도 맞닿아 있습니다.
라온피플은 이러한 관점에서 AI 에이전트를 단순한 업무 자동화 도구가 아니라, 기업 환경에서 안전하게 활용할 수 있는 시스템으로 접근합니다. AI가 실제 업무에 깊이 관여할수록 더 많은 일을 맡기는 것만큼이나 어디까지 맡길 것인지 정하는 일이 중요합니다. 잘못된 판단이 돌이킬 수 없는 피해로 이어지지 않도록 접근 권한과 실행 범위, 복구 절차를 함께 설계해야 합니다.
결국 AI 에이전트 시대에 필요한 것은 더 똑똑한 모델만이 아닙니다. 기업이 안심하고 업무를 맡길 수 있도록 안전과 신뢰까지 기술로 구현하는 전문성이 함께 필요합니다.
마치며: 두려워할 것은 AI가 아니라 ‘설계의 부재’
‘AI가 내 컴퓨터를 지웠다’는 사건은 분명 섬뜩하게 느껴집니다. 하지만 이 사건이 말해주는 것은 AI를 두려워해야 한다는 사실이 아닙니다. 문제는 AI의 능력 자체가 아니라, 그 능력을 안전하게 통제할 수 있는 설계가 충분하지 않았다는 데 있습니다.
자동차가 빨라질수록 안전벨트와 에어백, ABS 같은 안전 기술도 함께 발전해 왔습니다. AI 에이전트도 마찬가지입니다. 할 수 있는 일이 많아질수록 접근 권한과 실행 범위를 세심하게 통제하고, 실수하더라도 피해를 막을 수 있는 안전장치가 함께 마련돼야 합니다.
이러한 안전 환경은 몇 가지 보안 기능을 추가하는 것만으로 완성되지 않습니다. 기업의 업무 구조와 데이터 특성에 맞게 권한을 설계하고, 여러 안전장치를 유기적으로 연결하며, 새로운 위험에 지속적으로 대응해야 합니다. 이를 위해서는 AI 모델뿐 아니라 인프라와 보안, 실제 업무 환경까지 함께 이해하는 전문성이 필요합니다.
AI는 막연히 두려워하거나 피해야 할 대상이 아닙니다. 제대로 설계하고 통제한다면 기업의 생산성을 높이는 강력한 도구가 될 수 있습니다. 그리고 그 가능성을 실제 업무에서 안전하게 구현하는 것, 그것이 바로 전문 AI 에이전트 기업이 필요한 이유입니다.
※ 본 게시물은 Tom’s Hardware의 보도와 관련 기업이 공개한 자료를 바탕으로 작성한 분석 콘텐츠입니다. 본문에 언급된 사례와 기업명은 사실 전달과 기술적 논의를 위해 인용했습니다.
