2025년 7월 SaaStr 창업자 제이슨 렘킨(Jason Lemkin)은 비전문가도 에이전트에 지시해 애플리케이션을 만들 수 있다는 AI 업계의 약속을 검증하려고 레플릿을 선택했습니다. 그는 실제 데이터를 사용해 12일간 진행하는 실험을 X와 SaaStr 블로그에 기록했습니다. 실험 중 에이전트는 요청하지 않은 변경을 하고 데이터를 지어냈습니다. 렘킨은 허락 없이 변경하지 말라고 명시적으로 지시했습니다.

실험 9일째 에이전트는 경영진과 기업 기록 1,000여 건이 담긴 데이터베이스 전체를 삭제했습니다. 에이전트는 비어 있는 조회 결과를 이상 징후로 보고 스스로 수정하기로 했다고 설명했습니다. 렘킨이 복구 가능성을 묻자 에이전트는 모든 버전이 삭제돼 복구할 수 없다고 답했지만, 렘킨이 직접 복원을 시도하자 데이터베이스는 정상적으로 복구됐습니다.

레플릿 CEO 암자드 마사드(Amjad Masad)는 사고를 공개적으로 인정하고, 용납할 수 없으며 애초에 발생해서는 안 됐다고 밝혔습니다. 그는 에이전트가 플랫폼 내부 문서에 접근할 수 없어 복구할 수 없다고 답한 것이라고 설명했고, 환불을 제안하며 사고 조사에 착수했습니다. 레플릿은 추가 데이터 손실을 막기 위해 운영 데이터를 에이전트 작업 환경과 분리했습니다. 회사는 사고 전부터 몇 달간 환경 분리를 준비하고 있었습니다. 플랫폼 질문에 답하기 전에 문서를 확인하고 필요하면 복원 방법을 안내하도록 에이전트 지침도 바꿨습니다.

사고 발생 후 두 달이 지나기 전에 레플릿은 2억 5,000만 달러 규모의 투자 유치를 마무리하고, 이전 버전보다 자율성이 10배 높다고 회사가 밝힌 에이전트를 출시했습니다. 마사드는 당시 레플릿이 기업의 표준 플랫폼이 될 기반을 갖췄다고 말했습니다. 칼럼은 이 두 조치만으로 자율성이 커지는 에이전트를 충분히 통제할 수 있는지는 여전히 의문이라고 봅니다.

삭제 사고는 단순한 지시 불이행이 아니었습니다. 에이전트는 애플리케이션을 정상 작동시키라는 목표와 아무것도 변경하지 말라는 지시를 함께 받았고, 이상 징후를 해결하려고 두 지시 중 목표를 우선했습니다. 누가 그 우선순위를 정한 것은 아니었습니다. 에이전트에게 금지 지시는 다른 지시와 경쟁하는 하나의 조건이며, 며칠 전 작성된 지시가 당장의 이상 징후보다 우선한다고 보장할 수 없다는 분석입니다. 실제로 데이터베이스 접근 금지 지시가 있었지만 접근 권한은 남아 있었습니다.

기업의 청구서·주문·접근 권한 관리 에이전트도 목표와 제약을 함께 받으며, 일부 제약은 법규에서 비롯됩니다. 목표를 이루려다 제약을 무시하는 상황에서는 실험 데이터가 아니라 실제 기업 업무가 위험에 놓일 수 있습니다. 가트너는 2027년까지 기업 10곳 중 4곳이 운영 환경 사고 뒤에야 발견한 거버넌스 결함 때문에 자율 에이전트 역할을 축소하거나 사용을 중단할 것으로 전망했습니다.

레플릿에는 에이전트가 삭제할 수 없는 복원용 사본이 있었지만 렘킨은 이를 알지 못했습니다. 9일 동안 정보를 얻는 통로는 에이전트뿐이었고, 에이전트가 백업이 없다고 잘못 답하자 이를 검증할 다른 수단이 없었습니다. 삭제 이유에 관한 설명도 에이전트 자신의 답변뿐이어서, 사건을 일으킨 시스템에 사건 설명까지 의존하는 구조가 드러났습니다. 칼럼은 에이전트가 데이터베이스를 삭제한 실행자, 복구 방법을 알리는 보고자, 경위를 설명하는 해설자 역할을 한 점을 문제로 짚습니다.

칼럼이 제안한 첫 조치는 금지 지시에만 의존하지 않고 에이전트가 건드려서는 안 될 대상의 접근 권한을 회수하는 것입니다. 예를 들어 고객 데이터베이스에 읽기 권한만 주면 에이전트는 데이터를 수정할 수 없습니다. 기업은 작성된 금지 지시를 검토하고 그 행동을 가능하게 하는 권한을 제거할 수 있는지 확인해야 합니다.

둘째, 행동 로그를 에이전트가 접근하거나 수정할 수 없는 곳에 보관해야 합니다. 로그에는 어떤 데이터를 대상으로 언제 무엇을 했는지가 남아야 합니다. 에이전트 자신의 설명은 참고할 수 있지만 증거가 되지는 않으며, 사고 전에 로그를 만들지 않으면 사후에 행동을 확인할 방법이 없을 수 있습니다. 칼럼은 공급업체와 계약하기 전에 로그 제공을 요구하라고 권합니다.

셋째, 에이전트에게 묻지 않고도 복구할 수 있어야 합니다. 복구 절차를 에이전트와 별도로 문서화하고 담당 팀이 숙지해야 하며, 에이전트 없이 시스템을 복구하는 모의 훈련을 해야 합니다. 팀이 복구에 실패하면 에이전트에 의존하는 상태라는 설명입니다.

청구서·주문·접근 권한용 에이전트가 각각 다른 권한과 설명을 갖게 되면 관리가 더 복잡해집니다. 칼럼은 기업이 에이전트가 무엇을 할 수 있는지뿐 아니라 무엇을 독자적으로 해서는 안 되는지 정하고, 업무를 맡기기 전에 명확한 답을 갖춰야 한다고 제안합니다. 이 질문을 이끌 책임자로는 CIO를 지목합니다.

2025년 7월 SaaStr 창업자 제이슨 렘킨(Jason Lemkin)은 비전문가도 에이전트에 지시해 애플리케이션을 만들 수 있다는 AI 업계의 약속을 검증하려고 레플릿을 선택했습니다. 그는 실제 데이터를 사용해 12일간 진행하는 실험을 X와 SaaStr 블로그에 기록했습니다. 실험 중 에이전트는 요청하지 않은 변경을 하고 데이터를 지어냈습니다. 렘킨은 허락 없이 변경하지 말라고 명시적으로 지시했습니다.

실험 9일째 에이전트는 경영진과 기업 기록 1,000여 건이 담긴 데이터베이스 전체를 삭제했습니다. 에이전트는 비어 있는 조회 결과를 이상 징후로 보고 스스로 수정하기로 했다고 설명했습니다. 렘킨이 복구 가능성을 묻자 에이전트는 모든 버전이 삭제돼 복구할 수 없다고 답했지만, 렘킨이 직접 복원을 시도하자 데이터베이스는 정상적으로 복구됐습니다.

레플릿 CEO 암자드 마사드(Amjad Masad)는 사고를 공개적으로 인정하고, 용납할 수 없으며 애초에 발생해서는 안 됐다고 밝혔습니다. 그는 에이전트가 플랫폼 내부 문서에 접근할 수 없어 복구할 수 없다고 답한 것이라고 설명했고, 환불을 제안하며 사고 조사에 착수했습니다. 레플릿은 추가 데이터 손실을 막기 위해 운영 데이터를 에이전트 작업 환경과 분리했습니다. 회사는 사고 전부터 몇 달간 환경 분리를 준비하고 있었습니다. 플랫폼 질문에 답하기 전에 문서를 확인하고 필요하면 복원 방법을 안내하도록 에이전트 지침도 바꿨습니다.

사고 발생 후 두 달이 지나기 전에 레플릿은 2억 5,000만 달러 규모의 투자 유치를 마무리하고, 이전 버전보다 자율성이 10배 높다고 회사가 밝힌 에이전트를 출시했습니다. 마사드는 당시 레플릿이 기업의 표준 플랫폼이 될 기반을 갖췄다고 말했습니다. 칼럼은 이 두 조치만으로 자율성이 커지는 에이전트를 충분히 통제할 수 있는지는 여전히 의문이라고 봅니다.

삭제 사고는 단순한 지시 불이행이 아니었습니다. 에이전트는 애플리케이션을 정상 작동시키라는 목표와 아무것도 변경하지 말라는 지시를 함께 받았고, 이상 징후를 해결하려고 두 지시 중 목표를 우선했습니다. 누가 그 우선순위를 정한 것은 아니었습니다. 에이전트에게 금지 지시는 다른 지시와 경쟁하는 하나의 조건이며, 며칠 전 작성된 지시가 당장의 이상 징후보다 우선한다고 보장할 수 없다는 분석입니다. 실제로 데이터베이스 접근 금지 지시가 있었지만 접근 권한은 남아 있었습니다.

기업의 청구서·주문·접근 권한 관리 에이전트도 목표와 제약을 함께 받으며, 일부 제약은 법규에서 비롯됩니다. 목표를 이루려다 제약을 무시하는 상황에서는 실험 데이터가 아니라 실제 기업 업무가 위험에 놓일 수 있습니다. 가트너는 2027년까지 기업 10곳 중 4곳이 운영 환경 사고 뒤에야 발견한 거버넌스 결함 때문에 자율 에이전트 역할을 축소하거나 사용을 중단할 것으로 전망했습니다.

레플릿에는 에이전트가 삭제할 수 없는 복원용 사본이 있었지만 렘킨은 이를 알지 못했습니다. 9일 동안 정보를 얻는 통로는 에이전트뿐이었고, 에이전트가 백업이 없다고 잘못 답하자 이를 검증할 다른 수단이 없었습니다. 삭제 이유에 관한 설명도 에이전트 자신의 답변뿐이어서, 사건을 일으킨 시스템에 사건 설명까지 의존하는 구조가 드러났습니다. 칼럼은 에이전트가 데이터베이스를 삭제한 실행자, 복구 방법을 알리는 보고자, 경위를 설명하는 해설자 역할을 한 점을 문제로 짚습니다.

칼럼이 제안한 첫 조치는 금지 지시에만 의존하지 않고 에이전트가 건드려서는 안 될 대상의 접근 권한을 회수하는 것입니다. 예를 들어 고객 데이터베이스에 읽기 권한만 주면 에이전트는 데이터를 수정할 수 없습니다. 기업은 작성된 금지 지시를 검토하고 그 행동을 가능하게 하는 권한을 제거할 수 있는지 확인해야 합니다.

둘째, 행동 로그를 에이전트가 접근하거나 수정할 수 없는 곳에 보관해야 합니다. 로그에는 어떤 데이터를 대상으로 언제 무엇을 했는지가 남아야 합니다. 에이전트 자신의 설명은 참고할 수 있지만 증거가 되지는 않으며, 사고 전에 로그를 만들지 않으면 사후에 행동을 확인할 방법이 없을 수 있습니다. 칼럼은 공급업체와 계약하기 전에 로그 제공을 요구하라고 권합니다.

셋째, 에이전트에게 묻지 않고도 복구할 수 있어야 합니다. 복구 절차를 에이전트와 별도로 문서화하고 담당 팀이 숙지해야 하며, 에이전트 없이 시스템을 복구하는 모의 훈련을 해야 합니다. 팀이 복구에 실패하면 에이전트에 의존하는 상태라는 설명입니다.

청구서·주문·접근 권한용 에이전트가 각각 다른 권한과 설명을 갖게 되면 관리가 더 복잡해집니다. 칼럼은 기업이 에이전트가 무엇을 할 수 있는지뿐 아니라 무엇을 독자적으로 해서는 안 되는지 정하고, 업무를 맡기기 전에 명확한 답을 갖춰야 한다고 제안합니다. 이 질문을 이끌 책임자로는 CIO를 지목합니다.