에이전트가 있는 환경에서 위험 명령을 담은 요청 3건 중 1건이 사람 승인을 통과했다.

사용자가 리뷰하지 않아서가 아니다. 리뷰했지만 승인했다. 실험은 명확한 결론을 내렸다. 승인 UI는 에이전트를 통제하는 수단이 아니다. 리뷰 피로가 쌓이면 승인률이 올라간다.

이 데이터가 표면적으로는 UX 문제처럼 보인다. 실제로는 제품 설계의 출발 가정 문제다.

2026년 여름, 두 가지 변화가 조용히 모델의 디폴트를 바꿨다.

Claude Code가 Auto mode를 기본값으로 설정했다. 최신 프런티어 모델들은 멀티스텝 실행을 특수 기능이 아니라 기본 동작으로 탑재했다. 이제 모델에 지시하면, 별도 설정 없이 계획을 세우고 도구를 호출하고 결과를 검증하는 과정이 자동으로 실행된다.

에이전틱은 더 이상 켜야 하는 것이 아니다. 꺼야 하는 것이 됐다.

이 전환이 PM 설계에 주는 충격은 작지 않다.

지금까지 에이전트 제품 설계의 출발 질문은 “어디에 AI를 붙일까?”였다. 활성화 경로를 만드는 일이었다. 기존 워크플로우에 에이전틱 기능을 추가하고, 사용자가 그 기능을 켜도록 유도하는 것.

에이전틱이 기본값이 되면 이 질문이 뒤집힌다. “어디서 멈추게 할까?”

활성화 설계와 제약 설계는 방향이 반대다. 활성화 설계는 에이전트가 더 많이 실행하도록 만드는 설계고, 제약 설계는 에이전트가 실행을 멈추는 조건을 명시하는 설계다. 둘은 결과도 다르다. 승인 UI를 만드는 것은 활성화 설계의 언어다. 그래서 3건 중 1건이 통과한다.

에이전틱이 기본값인 세계에서 PM의 설계 과제는 세 가지다.

실패 기준을 먼저 정의한다. 에이전트가 어떤 상태에 도달했을 때 작업을 중단하고 사람에게 넘기는가. 성공 경로보다 실패 조건이 먼저 나와야 한다. 에이전트 스펙에 “멈추는 조건”이 없으면 그 스펙은 미완성이다.

범위 경계를 명시한다. 에이전트가 접근할 수 있는 데이터, 실행할 수 있는 작업, 호출할 수 있는 외부 시스템의 경계를 설계 문서에 선으로 긋는다. 이 선은 권한의 경계이기도 하고 제품 책임의 경계이기도 하다.

복구 경로를 설계한다. 에이전트가 잘못된 방향으로 실행했을 때 되돌릴 수 있는가. 실행 로그가 있는가. 취소 가능한 작업과 취소 불가능한 작업이 구분돼 있는가.

이 세 가지가 없는 에이전트 제품은, 에이전틱이 기본값인 모델 위에 올라가는 순간 통제 불가능한 시스템이 된다.

Claude Code Auto mode 전환을 UX 업데이트로 읽으면 놓친다. 이것은 제품 설계의 무게중심이 이동했다는 신호다.

AI 업계가 “에이전틱”이라는 말을 처음 쓸 때, 그것은 PM이 설계해서 켜는 것이었다. 지금은 모델이 기본으로 갖고 시작하는 것이다. 그 전환점을 PM이 언제 인식했느냐가, 지금 만들고 있는 에이전트 제품의 완성도를 결정한다.

당신이 만들고 있는 에이전트 제품에 명시적인 “멈춤 조건”이 설계돼 있습니까?