「We released Fable 5 and Mythos 5 on Tuesday, June 9.」

Anthropic의 Redeploying Claude Fable 5에서 가장 먼저 봐야 할 것은 부활 그 자체보다 시계열이라고 생각한다. 6월 9일에 Fable 5 / Mythos 5를 공개. 6월 12일에 미국 상무부의 수출 관리로 인해 중단. Amazon의 연구자가 Fable 5의 안전책을 우회할 수 있는 사례를 보고했고, 취약점 특정과 일부 실증 코드 생성(code generation)이 문제가 되었다. 7월 1일에 재제공 상태로 돌아오기까지 약 2주간 중단되었다.

이것이 의미하는 바는, 강력한 모델의 출시가 단순히 "모델을 내놓는 것"만으로 끝나지 않게 되었다는 것이다. 이번 주인공은 Fable 5 본체보다, 그 전후에 배치된 라우팅(routing) 계층이다.

공식 블로그에서는 Amazon의 보고에서 나타난 동작을 겨냥해 차단하는 improved safety classifier를 훈련했다고 설명하고 있다. Fable 5로의 요청이 해당 classifier에 걸리면, 사용자에게는 차단 통지가 나타나고 요청은 Opus 4.8로 보내진다. Anthropic은 이 새로운 classifier가 보고된 구체적인 수법을 99% 이상 차단한다고 밝혔다.

Fable 5의 부활은 모델 본체보다 "출구 제어"가 주인공이 되었다.

classifier는 SLO의 일부가 된다

많은 사람은 "위험한 질문을 거부하는 모델"을 상상하지만, 이번 설계는 조금 다르다. 강력한 모델 앞에 별도의 판정 계층을 두고, 입력마다 출구를 바꾼다. 통과시킨다. 약한 모델로 돌린다. 차단한다.

type Route = "fable_5" | "opus_4_8" | "blocked";
function routeRequest(input: UserRequest): Route {
const risk = safetyClassifier(input);
...

물론 실제 구현은 이렇게 단순한 if 문은 아니다. 다만, 이 분기가 프로덕트의 동작이 된다는 점은 변함이 없다. Fable 5에 던지려 했던 요청이 Opus 4.8로 돌아간다면, 사용자에게는 "같은 입력인데 어제보다 약한 답변이 돌아온다"라고 보인다. 안전책인 동시에, 성공 응답률이나 완료율을 좌우하는 SLO(Service Level Objective), 즉 서비스 품질 목표의 일부가 된다.

나도 오늘 이 블로그를 읽으면서, 수중에 있는 프롬프트 분류 메모를 조금 다시 쓰고 있었다. "security request라면 저능력 모델로"라고 하는 것은 너무 막연하다. 판정 이유, 대체 모델, 사용자에게 반환할 설명, 재시도 동선. 이 4가지는 최소한 로그로 남기고 싶다.

안전하게 처리할수록 현장에는 성능 저하로 보인다

까다로운 점은, 안전한 쪽으로 기울어진 결과가 개발자에게는 성능 저하로 보인다는 것이다.

예를 들어 의존성 라이브러리의 취약점을 고치고 싶은 개발자가 있다. 입력은 "이 코드의 문제를 고쳐줘"일 수 있다. 악용하려는 사람의 입력도 겉보기에는 비슷한 말투로 할 수 있다. WIRED는 특정 제한 능력에 접근하려는 요구를 Opus 4.8로 처리하게 하는 안전책이 추가되었다고 보도했다.

따라서 로그는 입력과 출력만으로는 부족하다.

항목	남겨야 하는 이유
classifier의 판정 카테고리	오탐(false positive)과 실제 위험을 나중에 구분하기 위해
...

단순히 "안전상의 이유로 할 수 없습니다"라고 하면, 정당한 방어 작업까지 중단된 것처럼 보인다. 왜 중단되었는지, 대신 무엇을 할 수 있는지. 이 두 가지를 반환하지 못하는 classifier는 올바르게 차단하더라도 운영 단계에서 마찰을 빚는다.

수출 관리는 인프라 장애의 얼굴을 하고 온다

AP는 Fable 5는 널리 이용 가능해진 반면, Mythos 5는 미국 정부가 승인한 일부 미국 조직에 한해서만 돌아온다고 보도하고 있다. 즉, 동일한 기반 모델 계열이라도 누구에게 어떤 능력을 보여줄지는 단일하지 않다.

앱 측면에서 보면, 이것은 "상류 API가 갑자기 403이 되는 것"에 가깝다. 원인은 네트워크나 결제가 아니라 정책 판단과 안전 심사다. 따라서 모델명을 직접 쓰지 않는 것만으로는 부족하다. 기능별로 필요 능력과 허용 가능한 저하를 갖추고, 리스크가 높은 기능만 차단하며, 저리스크 기능은 다른 모델로 우회시킨다.

다음은 모델 평가가 아니라 루트 평가다

Fable 5의 부활로, 나는 벤치마크를 보는 관점도 조금 바뀌었다. 사용자의 모든 요청이 Fable 5에 도달하는 것이 아니라면, 평가 대상은 단일 모델이 아니라 classifier와 fallback을 포함한 루트(route) 전체가 된다.

주시해야 할 지표는 정당한 요청의 통과율, 위험한 요청의 차단율, Opus 4.8로 넘긴 후의 완료율 정도이다. classifier의 임계값(threshold)을 조금만 바꿔도 이 수치들은 크게 변한다. 그래서 나라면 Fable 5 급의 모델을 사내 도구에 도입하기 전에 route eval을 만들 것이다. 답변의 품질뿐만 아니라, 어떤 모델에 도달했는지를 평가 대상으로 삼는다.

Claude Fable 5의 부활은 강력한 모델이 돌아왔다는 뉴스로 읽는다면 절반만 이해한 것이다. 이번에 드러난 핵심은 모델 본체 앞에 classifier를 배치하고, 위험할 가능성이 있는 요청을 Opus 4.8로 우회시키며, 제공 범위도 사용자나 조직에 따라 다르게 설정하는 운영 설계다. 앞으로의 LLM 애플리케이션은 "어떤 모델을 사용할 것인가"뿐만 아니라, "어떤 입력을 어느 능력 대역으로 통과시킬 것인가"를 설계하지 않으면 운영 환경(production)에서의 동작을 설명할 수 없게 된다. 다음에 주목해야 할 점은 각 기업이 classifier의 오탐률(false positive rate)이나 대체 모델 사용 시의 완료율을 어디까지 공개할 것인가 하는 점이다. 이 정보가 공개되지 않은 채 고성능 모델만 늘어난다면, 개발자들은 다시 로그가 없는 분기점에서 난관에 봉착하게 될 것이다.

Sources

Discussion