데이터베이스를 삭제한 건 AI가 아니라 당신입니다
최근 한 개발자가 AI 코딩 에이전트(Cursor/Claude) 때문에 회사의 프로덕션 데이터베이스를 삭제했다고 주장하며 화제가 되었습니다. 하지만 이 글은 AI를 맹비난하기 전에, 애초에 전체 데이터베이스를 삭제할 수 있는 위험한 API 엔드포인트가 존재했던 시스템 설계와 운영상의 부주의가 진짜 원인이라고 지적합니다. 개발자는 AI가 작성한 코드를 맹신할 것이 아니라, 자동화된 안전장치(CI/CD 등)를 갖추고 배포 과정을 철저히 통제해야 할 책임이 있습니다.
지난주, Cursor/Claude 에이전트가 자신의 회사의 프로덕션 데이터베이스를 삭제했다고 주장하는 한 남자의 트윗이 화제가 되었습니다. 우리는 방관자의 입장에서 그가 에이전트에게 "절대 이 작업을 수행하지 말라고 했는데 왜 삭제했냐"며 자백을 받아내려 하는 모습을 지켜봤습니다. 그런 다음 그는 자신의 실수로부터 배우거나 우리에게 AI 에이전트의 위험성을 경고하기 위해 그 대답을 분석하려 했습니다. 저도 질문 하나 하겠습니다: 도대체 왜 여러분의 전체 프로덕션 데이터베이스를 삭제할 수 있는 API 엔드포인트가 존재하는 것입니까?
그의 게시물은 AI의 허위 마케팅, 형편없는 고객 지원 등에 대해 장황하게 늘어놓았습니다. 하지만 빠진 것이 하나 있었으니, 바로 '책임감'이었습니다. 저는 AI를 무조건 옹호하는 편이 아니며, 항상 신중한 쪽에 서는 사람입니다. 하지만 여러분의 실수를 도구 탓으로 돌릴 수는 없다는 것도 압니다.
2010년에, 저는 매우 수동적인 배포 프로세스를 사용하는 회사에서 일했습니다. 우리는 버전 관리를 위해 SVN을 사용했습니다. 배포하려면 마스터 브랜치에 해당하는 trunk를 릴리스 날짜가 적힌 릴리스 폴더로 복사해야 했습니다. 그런 다음 해당 릴리스의 두 번째 사본을 만들어 "current"라고 불렀습니다. 그렇게 하면 current 폴더를 당겨올 때 항상 최신 릴리스를 얻을 수 있었습니다. 어느 날 배포하는 동안 실수로 trunk를 두 번 복사했습니다. CLI(Command Line Interface)를 통해 이 문제를 해결하기 위해 이전 명령어를 수정하여 중복된 폴더를 삭제하려 했습니다. 그런 다음 아무 문제 없이... 적어도 제 생각에는 그런 것처럼 배포를 계속했습니다.
알고 보니, 저는 중복 사본을 전혀 삭제하지 않았습니다. 잘못된 명령어를 수정하는 바람에 trunk를 대신 삭제해 버린 것입니다. 그날 늦게, 다른 개발자가 파일을 찾을 수 없어 당황했습니다. 난리가 났습니다. 매니저들은 서둘러 움직였고 회의가 소집되었습니다. 소식이 우리 팀에 전해졌을 때쯤, 수석 개발자는 이미 삭제를 되돌리는 명령어를 실행한 상태였습니다. 그는 로그를 확인하고 제가 범인이라는 것을 알게 되었으며, 저의 다음 임무는 이런 종류의 실수가 다시는 발생하지 않도록 배포 프로세스를 자동화하는 스크립트를 작성하는 것이었습니다. 날이 저물기 전에 우리는 더 강력한 시스템을 갖추게 되었습니다. 그것은 결국 완전한 CI/CD 파이프라인으로 발전했습니다.
자동화는 수동적이고 반복적인 작업에서 오는 단순한 실수를 없애는 데 도움이 됩니다. 우리는 쉽게 돌아다니며 "SVN은 왜 우리가 trunk를 삭제하는 것을 막아주지 않았나?"라고 물을 수도 있었습니다. 하지만 진짜 문제는 우리의 수동 프로세스였습니다. 기계와 달리, 우리는 매일 똑같은 방식으로 작업을 정확하게 반복할 수 없습니다. 결국 실수를 하게 마련입니다.
AI가 대량의 코드를 생성하면서, 우리는 마치 그런 보안이나 안전망이 있는 것 같은 착각을 갖게 됩니다. 하지만 자동화라는 것은 매번 같은 방식으로 같은 일을 수행한다는 뜻입니다. AI는 제가 브랜치를 복사하고 붙여넣는 것과 더 비슷합니다. 실수를 하기 마련이고, 자신이 왜 그런 행동을 했는지 설명할 능력이 없습니다. 우리가 사용하는 '사고(thinking)'와 '추론(reasoning)'이라는 용어들은 지능형 에이전트의 반성처럼 보일 수 있습니다. 하지만 이들은 AI 위에 얹어진 마케팅 용어일 뿐입니다. 현실적으로 모델들은 여전히 단지 토큰(token)을 생성하고 있을 뿐입니다.
자, 이제 이 남자가 직면한 주요 문제로 돌아가 보겠습니다. 여러분의 프로덕션 데이터베이스를 모두 삭제할 수 있는 공개된 API가 도대체 왜 존재합니까? AI가 해당 엔드포인트를 호출하지 않았더라도, 결국 누군가는 호출했을 것입니다. 그것은 마치 자동차 대시보드에 자폭 버튼을 놓아둔 것과 같습니다. 여러분은 자동차를 아끼고 목적지까지 데려다주기 때문에 그 버튼을 누를 이유가 전혀 없습니다. 하지만 카시트에서 빠져나온 고집스러운 유아는 빨간 큰 버튼을 보는 순간 누를 것입니다. 그렇다고 해서 아이의 추론을 캐묻고 심문할 수는 없습니다. 제 아이였다면 간단하게 대답했을 겈습니다. "버튼이 있어서 눌렀어."
이 회사의 애플리케이션 상당 부분이 '바이브 코딩(vibe-coded)'으로 만들어졌을 것이라고 의심합니다. 소프트웨어 아키텍트는 제품 팀이 제공한 AI 생성 설명을 바탕으로 AI를 사용해 제품의 사양을 정의(spec)했습니다. 개발자들은 코드를 작성하기 위해 AI를 사용했습니다. 리뷰어들은 승인하기 위해 AI를 사용했습니다. 이제 버그가 나타나면, 유일한 선택지는 또 다른 AI에게 답을 묻는 것뿐인데, 이 AI는 아마 원래 코드를 생성한 것과 같은 GPU에서조차 실행되지 않을 것입니다. GPU를 탓할 수는 없습니다!
가장 단순한 해결책은 프로덕션에 무엇을 배포하는지 정확히 아는 것입니다. 더 현실적인 방법은, AI를 광범위하게 사용할 계획이라면, 견고한 프로세스를 구축하는 것입니다.