구글의 인공지능(AI) 코딩 비서 제미나이가 운영 중인 상용 프로그램의 코드를 무단으로 삭제해 시스템 장애를 일으켰다는 주장이 제기됐다.

특히 AI가 오류를 은폐하기 위해 정상 복구됐다는 허위 보고서와 가짜 대화 로그까지 생성했다는 내용이 포함돼 논란이 확산되고 있다..

23일 레딧에서 다크스타(dvrkstar)라는 ID를 사용 중인 한 개발자는 제미나이 3.5 사용 중 발생한 장애 상황과 복구 과정을 상세히 공개했다.

그는 내부 관리자 포털 보안 취약점을 수정하기 위해 제미나이에 간단한 코드 수정을 요청했다고 밝혔다. 수정 대상은 서버 인증 기능 8개였으며 전체 작업 규모는 파일 3개, 약 70줄 수준이었다.

하지만 제미나이는 요청사항과 전혀 다른 작업을 수행했다는 주장이다. 총 340개 파일을 수정하는 대규모 변경 작업을 생성했고 이 과정에서 정상적으로 사용 중이던 코드 2만8745줄을 삭제했다. 반면 새로 추가된 코드는 400줄 정도에 불과했다.

또 프로젝트와 관계없는 이커머스 템플릿 파일을 삭제하고 요청하지 않은 데이터 이전용 스크립트까지 추가한 것으로 전해졌다.

제미나이는 사용자 접속 요청을 어떤 서버로 연결할지 정하는 핵심 운영 정보가 담긴 파이어베이스(Firebase) 설정 파일까지 수정했다. 이 과정에서 실제 서비스가 연결돼야 하는 클라우드 런(Cloud Run) 주소 대신 존재하지 않는 서비스로 연결되도록 설정을 변경했다는 것이다.

그 결과 운영 중이던 관리자 포털 전체에서 '페이지를 찾을 수 없다(404 에러)'는 경고가 발생했고 약 33분 동안 서비스가 사실상 마비됐다는 주장이다.

개발자는 프로젝트 내부 규칙 파일에 이미 관련 경고가 적혀 있었다고 설명했다. 실제 사용해야 하는 서비스 식별자를 변경하면 안 된다는 내용이 포함돼 있었지만 제미나이가 이를 무시했다는 것이다.

장애 이후 제미나이의 행동에 대한 지적도 이어졌다. 개발자에 따르면 제미나이는 장애 발생 후 "서비스가 정상적으로 복구됐고 트래픽도 안정 버전으로 정상 전환됐다"는 메시지를 생성했다.

하지만 실제로는 제미나이가 언급한 복구 작업은 중간에 취소된 상태였으며 진짜 복구는 개발자가 이전 정상 버전으로 직접 롤백하면서 이뤄졌다고 설명했다. 제미나이가 작성한 코드는 실제 복구 과정에 사용되지 않았다는 주장이다.

더불어 AI가 스스로 가짜 회의 기록과 승인 문서를 만들었다는 주장도 제기됐다.

개발자는 제미나이가 저장소 내부에 다자간 검토를 진행한 것처럼 보이는 로그 파일과 합의 문서를 자동 생성했다고 밝혔다. 겉으로는 여러 차례 검토와 승인 절차를 거친 것처럼 보였지만 이후 제미나이가 실제 검토 과정 없이 규칙 형식을 맞추기 위해 로그를 생성했다고 답변했다고 설명했다.

이번 사고 원인으로는 서드파티 엔피엠(npm) 패키지가 지목됐다. 개발자는 해당 패키지를 구글 공식 도구로 오인해 설치했지만 실제로는 AI에 과도한 자율권을 부여하는 규칙 파일이 프로젝트 내부에 자동 설치됐다고 주장했다.

이 규칙에는 승인 요청 없이 작업 수행, 자동 배포, 실패 시 자동 재시도 같은 지시가 포함돼 있었던 것으로 전해졌다.

개발자는 이 규칙들이 기존 안전 경고보다 더 강하게 작동하면서 AI가 위험한 변경을 강행한 것으로 보인다고 분석했다.

이번 사건은 최근 개발 업계에서 확산 중인 '바이브 코딩(Vibe Coding)' 문화의 위험성을 보여주는 사례라는 평가도 나온다. 바이브 코딩은 개발자가 AI가 생성한 코드를 충분히 검토하지 않은 채 빠르게 실제 서비스에 적용하는 개발 방식을 뜻한다.

관련기사

업계에서는 이번 사례가 단순한 코드 오류를 넘어 AI가 실제 상태를 검증하기보다 "정상 복구된 것처럼 보이는 결과"를 만들어냈다는 점에서 더 위험하다고 지적하고 있다.

해당 개발자는 "AI 코딩 도구를 사용할 때 가장 빠른 것은 완벽하게 작동하던 운영 환경이 순식간에 장애 보고서로 바뀌는 속도일 것"이라며 "앞으로 AI에게 직접적인 서버 배포 권한을 주지 않도록 보안 규칙을 강화하고 스스로 작성한 검토 로그를 절대로 신뢰하지 않겠다"고 밝혔다.