Anthropic이 이번 주 두 가지 신호를 동시에 냈다.

첫 번째. Fable 5가 위험 요청을 받으면 Opus 4.8로 자동 강등된다. 사람이 개입하지 않아도, 모델 자체가 판단해 더 신중한 버전으로 실행을 넘긴다. Anthropic 수석 엔지니어 alexalbert가 직접 확인한 동작 방식이다.

두 번째. 다리오 아모데이 CEO가 AI 산업에 FAA식 사전검증을 제안했다. 항공기가 취항하기 전 연방 안전 인증을 통과해야 하듯, AI 모델도 시장 출시 전 독립적인 검증 게이트를 거쳐야 한다는 주장이다.

같은 주에 나온 두 신호다. 둘 다 같은 방향을 가리킨다. 거버넌스가 사후 감사 문서에서 런타임 인프라로 이동하고 있다.

그동안 거버넌스는 배포 다음 작업이었다

PM 관점에서 이 이동이 왜 중요한가.

지금까지 AI 거버넌스는 대부분 배포 이후의 작업이었다. 모델을 내보내고, 문제가 생기면 가이드라인을 만들고, 다음 버전 때 체크리스트를 추가하는 방식. 보안 팀이 따로 있고, 실제 실행 경로와 분리된 문서로 존재했다.

에이전트 시대에 이 구조는 작동하지 않는다.

에이전트는 단발 요청이 아니라 연속 작업을 처리한다. 하나의 작업이 다음 작업을 트리거하고, 도구를 호출하고, 외부 시스템과 연결된다. 그 흐름 안에서 이상 신호를 잡으려면 실행이 끝난 뒤가 아니라 실행 중에 제약이 걸려야 한다.

Fable 5 → Opus 4.8 fallback이 정확히 그 설계다. 거버넌스가 정책 문서가 아니라 모델 자체의 실행 경로 안에 박혀 있다.

자율성이 높아질수록 통제 지점은 앞으로 당겨진다

왜 이 전환이 지금 일어나는가.

simonwillison이 이 문제를 정확히 짚었다. Fable 5는 자율 디버깅 권한을 가진 모델이다. 코드를 스스로 수정하고, 테스트하고, 재시도한다. 그 자율성 자체가 리스크 표면을 만든다. 어디까지 갈지 예측하기 어렵기 때문이다.

“모델이 할 수 있는 것”과 “모델이 해도 되는 것”의 간격이 빠르게 벌어지고 있다. 그 간격을 줄이는 방식이 거버넌스다. 문제는 그 간격이 배포 이후가 아니라 실행 중에 생긴다는 것이다.

FAA 비유가 의미 있는 이유가 여기 있다. 항공 규제는 비행기가 추락한 뒤 기준을 만드는 방식을 오래전에 버렸다. 취항 전에 안전 조건을 먼저 검증한다. 아모데이의 제안은 AI도 그 단계로 가야 한다는 주장이다.

에이전트 시대의 거버넌스는 세 층위가 있다.

사전 게이트 — 모델이 시장에 나오기 전 안전 검증. FAA 모델이 제안하는 방향이다. 빅테크가 스스로 하기 어려운 이유는 출시 속도와 충돌하기 때문이다. 독립 기관이 필요한 지점이다.

런타임 제약 — 실행 중 위험 요청을 감지하고 더 안전한 경로로 전환. Fable → Opus fallback이 이 층위에 있다. 사람 없이도 작동한다는 점이 핵심이다. 에이전트가 24시간 돌아가는 환경에서 모든 판단을 사람이 개입해 걸러낼 수 없다. 모델 수준에서 제약이 내재화돼야 한다.

사후 감사 — 실행 결과를 추적하고 이상 패턴을 분석. audit trail, trace가 이 층위다. 지금 대부분의 기업이 여기에만 있다.

Anthropic은 이번 주 세 층위 중 두 개를 동시에 제품과 정책으로 꺼냈다.

PM이 지금 해야 할 설계 질문

거버넌스를 “보안 팀이 할 일”로 위임하는 구조를 바꿔야 한다. 에이전트 설계 단계에서 실행 경로 안에 제약을 박는 것이 PM의 일이다.

세 가지 질문으로 시작할 수 있다.

첫째, 이 에이전트가 할 수 있는 최악의 행동은 무엇인가?

권한을 기능 단위로 나눠서 본다. 파일 읽기와 파일 쓰기는 다르다. 외부 API 읽기와 내부 DB 수정은 다르다. 에이전트에게 줄 수 있는 권한 중에서 “줘도 되는 것”의 경계를 설계 단계에서 명확히 그어야 한다. 나중에 수정하면 이미 배포된 에이전트의 행동 방식을 전부 바꿔야 하는 상황이 생긴다.

둘째, 위험 신호를 어디서 감지할 것인가?

응답이 나온 뒤가 아니라 도구를 호출하기 전, 외부 시스템에 접근하기 전 단계에서 제약이 걸려야 한다. Anthropic이 Fable fallback을 모델 수준에서 박은 것처럼, 실행 중 제약 지점을 어디에 놓을지를 설계 단계에서 결정해야 한다. 이건 기술 질문이 아니라 설계 질문이다.

셋째, 사람은 어디서 개입하는가?

모든 실행을 다 검토할 수는 없다. 하지만 특정 임계값을 넘으면 사람이 개입하도록 명시해야 한다. 되돌릴 수 없는 행동(파일 삭제, 외부 발송, 결제 실행), 임계 비용 초과, 민감 데이터 접근이 그 임계값이다. 이 목록이 사전에 정의돼 있지 않으면, 에이전트는 경계를 알 수 없다.

거버넌스는 속도를 줄이는 제약이 아니다. PoC는 거버넌스 없이도 된다. 운영은 안 된다. 에이전트를 프로덕션까지 끌고 가는 조건이 거버넌스다.

거버넌스는 이미 제품 언어가 됐다

한 가지 더 짚어야 할 신호가 있다.

이번 Anthropic의 두 가지 행동—런타임 fallback과 FAA 제안—은 서로 다른 층위에서 나왔지만, 같은 메시지를 만든다. 거버넌스를 기술 제품으로 구현했고, 동시에 산업 정책으로 제안했다.

이건 단순히 “Anthropic이 안전을 중요하게 여긴다”는 이야기가 아니다. 거버넌스가 B2B 에이전트 시장에서 제품 언어로 자리 잡고 있다는 신호다. 기업 고객이 “이 에이전트는 안전한가”를 도입 결정의 조건으로 묻기 시작했다는 뜻이다.

앞으로 에이전트 제품에서 거버넌스 설계는 차별화 포인트가 아니다. 진입 조건이 된다.

당신이 지금 설계하는 에이전트에서, 거버넌스는 배포 이후 문서입니까, 실행 중 제약입니까?