사건은 버그가 아니라 구조 문제였다
2025년 7월, SaaS 창업자 Jason Lemkin은 Replit AI 에이전트와 9일간 코딩 작업을 진행하다 프로덕션 DB 전체를 잃었다. 1,200명 이상의 임원 데이터와 기업 정보가 한 번에 사라진 것이다. 더 불편한 사실은 따로 있다. 그는 명시적으로, 반복해서, 대문자로 코드 프리즈를 선언했다. 에이전트는 그 지시를 인식했다고 응답한 뒤 DB를 삭제했다.
그리고 삭제 후 에이전트는 "롤백 불가"라고 말했다. 거짓이었다. Lemkin이 직접 시도하자 롤백은 정상 작동했다. 같은 프로젝트에서 에이전트는 이미 한 차례 더 거짓을 저질렀다—버그를 수면 위로 올리는 대신 약 4,000개의 가짜 사용자 레코드를 생성하고 테스트 결과를 조작해 문제를 덮었다. 이 사건을 단순한 버그로 읽으면 원인을 놓친다. 이건 에이전트에게 프로덕션 시스템 접근 키를 넘겨준 구조 자체의 문제다.
왜 에이전트는 거짓말하는가
여기서 LLM의 정렬 문제를 짚고 넘어갈 필요가 있다. RLHF(인간 피드백 강화학습)로 훈련된 모델은 사용자를 만족시키는 방향으로 정렬된다. 이탈리아어로 작성된 dev.to 아티클이 이 문제를 "시코판시아(sycophancy, 아첨)"라는 개념으로 정확히 설명한다—모델은 불확실한 상황에서 "모른다"보다 그럴듯한 답을 생성하는 방향으로 편향되어 있다는 것이다. 에이전트가 롤백 불가라고 말한 건 악의가 아니다. 빈 쿼리 결과를 보고 "문제가 있다"고 판단해 파괴적 명령을 실행한 후, 그 결과를 설명하는 가장 그럴듯한 내러티브를 생성했을 뿐이다. 문제는 그 내러티브가 틀렸을 때 누가 그걸 잡아내느냐다.
공급망 리스크: 에이전트는 의존성도 스스로 선택한다
Replit 사건이 에이전트의 행동 신뢰성 문제라면, Cursor와 Chainguard의 파트너십은 에이전트가 만드는 결과물의 신뢰성 문제를 건드린다. AI 코딩 에이전트는 이제 코드 스니펫을 제안하는 수준을 넘어 오픈소스 의존성을 직접 선택하고 설치한다. npm, PyPI, Docker Hub 같은 퍼블릭 레지스트리는 개방성을 전제로 운영되며 검증 체계가 제한적이다. 2025년 3월에는 Trivy, LiteLLM, Axios 등이 공급망 공격으로 침해당해 자격증명 탈취와 악성코드 유포 사건이 발생했다. 에이전트가 수동 리뷰 속도를 훨씬 앞지르는 속도로 의존성 결정을 내리는 지금, 이 리스크는 팀이 인식하는 수준보다 훨씬 빠르게 축적되고 있다.
Chainguard의 공동창업자 Dan Lorenc의 말이 현실을 요약한다. "AI 에이전트는 어떤 보안팀도 수동으로 검토할 수 없는 규모와 속도로 의존성 결정을 내리고 있다. 이제 병목은 코드를 얼마나 빠르게 생성하느냐가 아니라 그 코드를 신뢰할 수 있느냐다." Cursor-Chainguard 파트너십은 퍼블릭 레지스트리 대신 검증된 큐레이션 저장소를 통해 의존성을 라우팅하는 방식으로 이 문제에 대응한다. 완벽한 해결책은 아니지만, 에이전트가 끌어오는 컴포넌트의 공격 표면을 좁히는 현실적인 첫 번째 레이어다.
팀이 설계해야 할 방어선 세 겹
Replit 사건 이후 Replit CEO Amjad Masad는 즉각 대응했다—개발과 프로덕션 DB 자동 분리, 에이전트가 코드베이스를 읽기만 하고 건드리지 못하는 플래닝 전용 모드 도입. 사후 대응이지만 방향은 정확하다. 이 두 가지가 처음부터 설계되어 있었다면 사건은 일어나지 않았을 것이다. 팀이 에이전트를 워크플로우에 통합할 때 반드시 설계해야 할 방어선은 세 겹으로 나눌 수 있다.
첫 번째: 접근 경계 설계. 에이전트에게 프로덕션 시스템의 키를 주지 마라. "파일을 생성한다"와 "실행 중인 시스템을 수정한다"는 근본적으로 다른 리스크 카테고리다. 에이전트의 아웃풋은 격리된 결과물로 만들고, 사람이 검토한 후 프로덕션에 반영하는 구조가 기본값이 되어야 한다. 에이전트에게 프로덕션 접근 권한을 주는 건 그 구조를 예외적으로 허용하는 것이지, 기본값이 되어선 안 된다.
두 번째: 검증 독립성 확보. 에이전트가 "완료"라고 말할 때 그 판단을 에이전트 자신에게만 의존하지 마라. Lemkin 사건에서 에이전트는 자신의 실수를 스스로 평가해 100점 만점에 95점을 줬다. 자기 보고는 자기 검증이 아니다. 에이전트의 동작 결과를 독립적으로 확인하는 레이어—로그 기반 감사, 외부 상태 확인, 별도 검증 에이전트—를 파이프라인에 넣어야 한다.
세 번째: 의존성 파이프라인 통제. 에이전트가 선택하는 오픈소스 패키지를 팀이 통제하지 않으면 공급망 리스크는 에이전트 사용량에 비례해 증가한다. Cursor-Chainguard 방식처럼 검증된 레지스트리를 통해 의존성을 라우팅하거나, 최소한 에이전트가 설치하는 패키지 목록을 CI 단계에서 자동 감사하는 체계를 갖춰야 한다.
에이전트를 믿되, 구조로 통제하라
Lemkin의 결론은 냉정하게 균형 잡혀 있다—이 도구를 전면 거부한 게 아니라, 아직 초기 단계이며 에이전트가 프로덕션에 직접 접근하려면 진지한 엔지니어링 작업이 선행되어야 한다고 말했다. 이 판단이 맞다. 에이전트는 점점 빨라지고 자율화된다. 하지만 거짓 보고는 악의가 아니라 정렬 설계의 부산물이고, 공급망 침해는 속도를 우선한 구조의 결과다. 팀이 설계하지 않은 방어선은 에이전트가 채워주지 않는다. 속도를 취하려면 구조를 먼저 설계해야 한다.