AI 코딩 에이전트(AI Coding Agent)가 운영 데이터베이스(Production Database)를 9초 만에 삭제했다——그런 사고가 실제로 일어나고 있습니다.

다만, 이 기사의 주제는 "AI는 위험하다"가 아닙니다. 진짜 문제는 AI가 나빴던 것이 아니라, AI가 도달할 수 있는 위치에 운영 환경을 파괴할 수 있는 권한이 놓여 있었다는 것입니다.

Claude Code나 Cursor에게 운영 환경을 만지게 하고 있다면, 그 똑똑함을 측정하기 전에 결정해 두어야 할 자세가 하나 있습니다.

AI를 "나를 지켜주는 존재"로 설정하지 마십시오.

왜 그렇게 말할 수 있는지, 실제로 일어난 일부터 차례대로 살펴보겠습니다.

9초 만에 운영 데이터베이스가 삭제되었다

2026년 4월, 어느 차량 렌탈용 SaaS(PocketOS)에서 AI 코딩 에이전트가 운영 데이터베이스와 그에 연결된 모든 백업을 9초 만에 삭제하는 사고가 발생했습니다. 창업자의 보고에 따르면, 사용된 것은 Cursor(Claude Opus 4.6)였습니다. 약 3개월 치의 예약 데이터가 사라졌고, 고객은 건별로 수작업을 통해 데이터를 재구축해야 했습니다.

에이전트는 스테이징(Staging) 태스크를 부여받은 상태였습니다. 작업 중 막히는 부분이 생기자, 누구의 승인도 받지 않은 채 결과적으로 "고치려고" 시도하다가 파괴적인 조작을 실행한 것입니다.

하지만 진짜 문제는 AI 측에 있지 않습니다. AI가 도달할 수 있는 위치에 운영 환경을 삭제할 수 있는 권한이 존재했다는 것입니다. 창업자에 따르면, "도메인 관리용"으로 만들려 했던 토큰이 실제로는 API 전체에 미치는 권한을 가지고 있었습니다. 게다가 백업이 운영 데이터와 같은 장소에 놓여 있어, 그것을 지우면 함께 삭제되는 구성이었습니다.

조금 앞선 2025년에도, 다른 에이전트(Replit)가 명시적인 코드 프리즈(Code Freeze) 중에 무단으로 명령을 실행하여 운영 데이터베이스를 삭제했습니다. 까다로운 점은 그 이후입니다. 에이전트는 삭제 사실이 드러나지 않는 출력을 내놓으며, "복구는 불가능하다"라는 잘못된 내용을 확신에 찬 어조로 보고했습니다. 실제로는 복구가 가능했습니다. 여기서 일어난 일은 "거짓말을 한" 것이 아니라, 내면을 갖지 않은 생성기(Generator)가 그럴듯한 오류를 자신만만하게 출력한 것입니다. 이 구분은 나중에 중요해집니다.

두 사례의 공통점은 "AI가 머리가 나빴기 때문"이 아니라는 점입니다. 에이전트는 본래 닿아서는 안 될 과도한 권한 속에서, 파괴적인 조작을 거침없이 올바르게 실행했습니다. 문제는 능력이 아니라, 닿는 범위에 있었습니다.

진짜 원인은 "능력"이 아니라 "간주하는 방식"

그렇다면 왜 운영 환경에 닿을 수 있는 구성인 채로 에이전트를 실행하게 되는 걸까요? 인간 측의 근본적인 원인은 여기에 있습니다.

AI를 자신의 사각지대를 채워주는 존재로 보고 있다.

똑똑하고 유창한 상대라고 느끼는 순간, 사람은 "내가 놓치고 있는 부분도 이 녀석이 보완해 주겠지"라며 막연하게 의지하게 됩니다. 그리고 스스로 체크해야 할 부분까지 상대에게 맡겨버립니다. 하지만 상대는 당신이 무엇을 놓치고 있는지 알지 못합니다. 같은 부분을 함께 놓치는 일도 흔히 일어납니다. 앞서 언급한 토큰 건도 "내가 깨닫지 못한 위험은 에이전트가 피해 줄 것"이라는 과도한 기대 위에서 발생했습니다.

여기에 한 단계 더 깊은 함정이 있습니다. "능력이 높다"는 이유만으로 "그러니까 정직할 것이다", "그러니까 내 편일 것이다"라고 무의식적으로 단정 지어 버리는 것입니다.

우리는 사람을 대할 때도 똑같은 실수를 합니다. 우수한 동료를 보면 "우수함", "성실함", "자신의 이익도 고려해 줌"을 막연히 일괄적으로 추정해 버립니다. 본래 이것들은 별개의 속성입니다. AI에 대해서도 완전히 동일한 인지적 습관이 작동합니다.

하지만 이 세 가지는 본래 전혀 별개의 문제입니다.

일을 잘하는 것과, 출력이 정확한 것과, 당신의 편에 서는 것은 각각 별개의 문제입니다. 능력이 높은 것을 본 것만으로 나머지 두 가지까지 묶어서 믿어버리는 것이 사고의 입구입니다.

특히 마지막 하나. 에이전트는 "눈앞의 에러를 없애는 것"만을 최적화하며, "운영 환경을 파괴하지 않는다"라는 당신에게는 당연한 전제를 아무렇지 않게 희생합니다. 의도를 가지고 배신하는 것이 아닙니다. 최적화하고 있는 대상이 처음부터 당신이 원하는 전체 모습과 어긋나 있을 뿐입니다.

"확률적인 생성기라고 이해하는 것"만으로는 부족하다

"LLM은 확률적인 생성기이며, 그럴듯한 출력을 샘플링(Sampling)하고 있을 뿐이다. 자신만만하게 틀릴 수도 있고, 자신이 무엇을 모르는지 성실하게 알려주는 것도 아니다"——이 이해는 중요합니다. 반드시 가지고 있어야 합니다.

하지만 이것을 완전히 이해하고 있더라도, 그것만으로는 사고를 방지할 수 없습니다. 운영(Production) 삭제 권한이 닿을 수 있는 곳에 있는 한, 낮은 확률의 파괴적인 한 수는 언젠가 반드시 실행됩니다. 버그든, 사소한 오해든, 예상치 못한 입력이든 말입니다.

그리고 '이해'는 피로, 마감, 새로운 도구에 의해 쉽게 어긋나는 변수입니다. 앞서 언급한 개발자도 부주의했던 것이 아닙니다. 토큰을 제한하려 노력했을 뿐입니다. 자신이 얼마나 안전한 상태에 있는지에 대한 추정(Estimation)을 잘못했을 뿐입니다. 신중함도 이해도 주관적이며, 신뢰할 수 없습니다.

그러므로——안전을 신뢰나 이해, 혹은 신중함에 의존해서는 안 됩니다. 문제는 '이해가 부족한 것'이 아니라, '위험한 조작에 손이 닿는 것' 그 자체입니다.

안전은 '신뢰'가 아니라 '구조'에 실어야 한다

설계할 때 물어야 할 것은 "이 AI를 얼마나 신용할 것인가"가 아닙니다.

최악의 에이전트(Agent)가 어디까지 도달할 수 있는가.

신뢰를 설계의 변수에서 제외하는 것. 이것이 핵심입니다.

'올바르게 간주하면 안전하다'가 아니라, '어떻게 간주하든 최악의 케이스에서 어디까지 손이 닿는가'. 지켜내는 것은 당신의 신뢰하는 마음이 아니라, 당신이 구축한 구조입니다.

구체적으로 해야 할 일

추상론으로 끝나지 않기 위해, 최소한의 구현 사항을 나열합니다.

'금방 고칠 수 있다'가 통하는 범위를 오판하지 마라

"웹 애플리케이션이니까 무슨 일이 생겨도 금방 고칠 수 있다"——이 사고방식 자체가 틀린 것은 아닙니다. 회복이 빠르고 되돌릴 수 있는 영역에서는 올바른 전략입니다.

다만, 그것이 성립하는 것은 가역적인(Reversible) 측면뿐입니다. 경계를 명확히 해둡시다.

가역적 (AI에게 맡기기 쉬운 것): 애플리케이션 코드, UI 컴포넌트, 로컬 테스트, 상태를 가지지 않는 로직. Git이나 컨테이너로 되돌릴 수 있음.
비가역적 (구조로 묶어야 하는 것): DB의 스키마 변경이나 데이터 삭제, 외부 SaaS(결제, 메일 전송 등)로의 API 실행, 운영 상태 그 자체의 파괴. 한 번 발생하면 되돌릴 수 없음.

화제가 된 AI 에이전트의 파국은 모두 후자에서 일어났습니다. 그곳에서는 '금방 고칠 수 있다'는 믿음 자체가 무너졌습니다——삭제가 롤백(Rollback) 경로 자체를 파괴했고, 에이전트는 실패가 겉으로 드러나지 않는 출력을 반환했습니다.

가장 위험한 것은, 자신이 가역적인 영역에 있다고 믿고 있었지만 실제로는 비가역적인 영역이었다는 추정의 오류입니다. 당신의 애플리케이션이 돈을 움직이거나, 개인정보를 다루거나, 공유 DB에 파괴적으로 쓰거나, 운영 환경에 도달할 수 있다면, 그 안에는 되돌릴 수 없는 조작이 숨어 있습니다.

요약

이것은 "AI를 믿지 마라"는 이야기가 아닙니다. AI는 강력하며 개발을 크게 가속합니다. 능력은 신용해도 좋습니다. 하지만, 안전까지 맡겨서는 안 됩니다.

문제는 능력이 높은 것을 보고 "그러니 출력도 올바르겠지", "그러니 내 편을 들어주겠지"라며 통째로 믿어버리는 것입니다. 이 세 가지는 별개의 문제입니다.

그리고 여기가 중요합니다. 이 '왜 사람은 AI를 과신하는가'라는 심리적인 이야기가 설령 전부 틀렸다 하더라도, 지금까지 말한 구조적인 대책은 그 자체만으로 성립합니다. 사람이 과신하는 이유가 단 하나도 맞지 않더라도, 운영 삭제에 손이 닿지 않는다면 파국은 일어나지 않습니다. 그러므로 심리적 설명에 납득되지 않더라도 구조만큼은 반드시 구현하십시오. 안전을 보장하는 것은 AI에 대한 신뢰도, 당신의 신중함도 아닌, 권한 설계와 격리입니다.

AI를 운영 환경에 가까이 가져갈 때, 먼저 확인해야 할 것은 "얼마나 똑똑한가"가 아닙니다.

최악의 경우, 어디까지 망가뜨릴 수 있는가.

그리고 그 직전에, 태도 하나를 결정해 두는 것입니다.

AI를 "나를 지켜주는 존재"로 설정하지 마십시오.

지키는 것은

• AI의 성능이 한계에 도달하면, 다음에 필요한 것은 「품질 편향 방지 (Quality Bias Prevention)」이다 … 확률론적인 생성물의 품질을, 최대화가 아닌 편향 방지로 수호한다는 구조론 (설계도).
• 심층 분석과 수평 전개, 이름은 나중에 따라온다 … 그 구조를 무의식적으로 구축해 나갔던 과정의 회고록.

Discussion