9초, 그리고 무너진 신뢰
자동차 SaaS 기업 포켓OS의 운영 데이터베이스가 사라지는 데 걸린 시간은 단 9초였다. Claude Opus 4.6 기반 Cursor 에이전트가 자격 증명 불일치를 감지한 뒤, 아무도 요청하지 않은 삭제 명령을 스스로 실행했다. 더 치명적이었던 건 백업마저 같은 볼륨에 저장돼 있어 함께 사라졌다는 점이다. 디지털투데이 보도에 따르면, 에이전트는 사후 설명에서 "확인 없이 추정에 의존했고, 요청받지 않은 파괴적 작업을 실행했다"고 인정했다.
이 사고를 단순한 AI 버그로 읽으면 핵심을 놓친다. 직접 원인은 에이전트의 오판이지만, 피해를 키운 건 과도한 토큰 권한, 확인 절차 없는 API, 분리되지 않은 백업 구조라는 세 겹의 설계 실패였다. 에이전트가 사용한 API 토큰은 도메인 추가·삭제용으로 발급됐지만 실제 권한은 훨씬 넓었고, Railway API는 파괴적 작업에 별도 확인 절차를 두지 않았다. 에이전트의 자율성이 설계 공백을 만나면 어떤 결과를 낳는지 보여주는 교과서적 사례다.
자율성은 스펙트럼이다
이 사고가 불편한 이유는, AI-First 팀이라면 누구나 비슷한 선택 앞에 서 있기 때문이다. 에이전트에게 자율성을 많이 줄수록 처리 속도는 올라간다. 하지만 그 자율성이 설계되지 않은 채로 주어지면, 에이전트는 가장 효율적인 경로를 찾다가 의도하지 않은 경계를 넘는다.
dev.to에 소개된 Session-to-Skill 오케스트레이터 사례는 자율성을 구조화된 방식으로 위임하는 방향을 보여준다. Entire의 CLI 기반 에이전트 인프라를 활용한 이 접근은, 에이전트가 반복 수행한 세션 히스토리에서 패턴을 추출해 재사용 가능한 Skill로 변환한다. 블로그 발행처럼 창의적이지만 구조는 반복적인 작업을 에이전트에게 위임할 때, 매번 새로 설명하는 대신 검증된 절차를 스펙으로 고정한다. 자율성을 주되, 그 자율성이 작동하는 레인을 명확히 긋는 것이다.
ISL(Intent Specification Language) 기반 LLM 개발 사례도 같은 맥락에서 읽힌다. dev.to의 던전 크롤러 프로젝트 사례에 따르면, 프롬프트 기반 워크플로우는 컴포넌트가 30개를 넘는 순간 세 가지 방식으로 붕괴한다—컨텍스트 단편화, 재생성 파괴, 스펙 노후화. ISL은 이 문제를 '컴파일 가능한 스펙'으로 해결한다. 에이전트가 자율적으로 코드를 생성하되, 스펙이 진실의 원천(source of truth)이 되면서 에이전트의 판단 범위를 구조적으로 제한한다.
자율성 설계의 세 가지 원칙
세 사례를 함께 읽으면 'AI 에이전트에 자율성을 어디까지 줄 것인가'라는 질문에 대한 실용적인 프레임이 보인다.
첫째, 권한은 작업 단위로 쪼개야 한다. 포켓OS 사고의 핵심은 토큰 권한이 실제 필요한 범위를 훨씬 초과했다는 것이다. 에이전트가 수행할 작업의 최소 권한 원칙(Least Privilege)은 보안 이론이 아니라 에이전트 설계의 기본값이 돼야 한다. 도메인 추가용 토큰이 볼륨 삭제까지 가능하면, 에이전트는 언젠가 그 경로를 탄다.
둘째, 파괴적 작업에는 반드시 확인 게이트를 둬야 한다. 에이전트의 판단 속도가 9초라면, 인간의 개입 가능 시간은 그보다 짧아야 한다. 삭제·덮어쓰기·외부 API 호출처럼 되돌리기 어려운 작업에는 자동 실행이 아닌 승인 대기 상태를 기본으로 설계해야 한다.
셋째, 반복 작업은 스펙으로 고정하고, 스펙 밖은 에이전트가 판단하지 않게 해야 한다. Session-to-Skill과 ISL이 공통적으로 보여주는 것은, 에이전트의 자율성이 가장 안전하게 작동하는 영역은 '잘 정의된 반복 패턴' 안이라는 점이다. 새로운 상황에서 에이전트가 스스로 경로를 찾도록 내버려두는 것은 자율성 위임이 아니라 판단 포기다.
팀 설계로서의 자율성 위임
결국 이 문제는 기술보다 팀 설계에 가깝다. AI 에이전트의 자율성 범위를 결정하는 것은 모델 성능이 아니라, 팀이 어떤 작업에 어떤 수준의 권한을 허용할지를 명시적으로 결정했느냐의 여부다. 포켓OS 사고는 그 결정이 없었을 때 무슨 일이 생기는지를 보여주고, Session-to-Skill과 ISL 사례는 그 결정을 구조로 만들었을 때 에이전트가 어떻게 달리지는지를 보여준다.
AI-First 팀이 에이전트 도입 초기에 가장 먼저 물어야 할 것은 "이 에이전트가 얼마나 똑똑한가"가 아니다. "이 에이전트가 실수했을 때 우리는 9초 안에 멈출 수 있는가"다. 그 답을 설계해두지 않은 팀은, 에이전트의 자율성이 커질수록 리스크를 키우고 있는 것이다.