같은 AI 모델인데 왜 기능이 다를까? 모델·도구·권한·안전 계층으로 보는 배포 차이

같은 이름이나 같은 기반 모델을 선택해도 실제 기능과 결과는 제품이 허용한 도구, 계정 권한, 시스템 지시, 안전 장치와 fallback 정책에 따라 달라집니다. 2026년 9월 공개된 Claude Fable 5.1과 Mythos 5.1은 Anthropic이 직접 같은 기반 모델이라고 설명한 사례이고, GPT-6 Astra는 OpenAI가 같은 모델의 사이버 과제 완료율이 접근 프로그램에 따라 몇 배씩 달라진다는 것을 자사 시스템 카드에 표로 남긴 사례입니다. 따라서 AI를 평가할 때는 “무슨 모델인가”와 함께 “어떻게 배포된 모델인가”를 물어야 합니다.

이 글의 제품 정보와 접근 정책은 2026년 9월 5일에 각 회사의 공식 자료로 확인했습니다. 출시 직후의 정책은 바뀔 수 있으므로 실제 도입 전에는 연결된 최신 문서를 다시 확인해야 합니다.

사용자가 만나는 것은 모델보다 큰 시스템이다

대규모 언어 모델을 흔히 서비스 전체와 같은 뜻으로 부르지만, 실제 제품은 여러 계층이 결합한 시스템입니다. 기반 모델은 입력을 받아 다음 출력을 계산하는 핵심 엔진입니다. 그 위에 제품이 시스템 지시(system prompt)를 넣고, 검색·파일·코드 실행 같은 도구를 연결하고, 계정별 권한과 안전 장치(safeguard)를 적용합니다. 특정 요청은 다른 모델로 보내거나 중단할 수도 있습니다.

flowchart TD
    accTitle: 실제 기능을 구성하는 배포 계층
    accDescr: 기반 모델과 시스템 지시, 도구 및 권한, 안전 장치 및 라우팅이 제품의 기능과 평가 결과를 구성합니다. 데이터 보존은 업무 적용을 결정하는 별도 계약 조건입니다.
    M["기반 모델"] --> H["제품·API의 실행 환경"]
    P["시스템 지시"] --> H
    T["도구와 계정·조직 권한"] --> H
    S["안전 장치·모니터링·fallback"] --> H
    H --> O["기능·응답과 평가 결과"]
    H --> E["비용·지연시간"]
    D["데이터 보존 계약"] -.-> U["업무에 적용할 수 있는 범위"]
    O --> U

각 계층이 하는 일은 다릅니다. 시스템 지시는 모델이 따라야 할 우선순위와 행동 규칙을 정하고, 도구는 모델이 관찰하거나 실행할 수 있는 범위를 넓힙니다. 권한은 그 도구가 건드릴 수 있는 데이터와 행동을 제한합니다. 안전 장치와 모니터링은 위험한 요청이나 승인 범위를 벗어난 행동을 탐지하고, 라우팅은 요청을 다른 모델이나 처리 경로로 보냅니다.

데이터 보존 정책만 성격이 조금 다릅니다. 모델의 추론 능력을 직접 바꾸는 계층은 아니지만, 민감한 업무에 그 배포를 쓸 수 있는지를 결정하는 계약 조건이라 기업에게는 기능만큼 중요한 배포 사양입니다.

OpenAI도 이 구분을 공식 자료에 남겼습니다. GPT-6 Astra 발표문은 벤치마크 주석에서 연구 환경이나 API로 얻은 평가 결과가 시스템 지시와 사용 가능한 도구의 차이 때문에 프로덕션 ChatGPT의 출력과 조금 다를 수 있다고 밝힙니다. 모델 이름이 같다고 평가 조건까지 같아지지는 않는다는 뜻입니다.

Claude Fable 5.1과 Mythos 5.1: 같은 기반 모델, 다른 제품 경계

Anthropic은 2026년 9월 1일 Claude Fable 5.1과 Mythos 5.1을 공개했습니다. 공동 발표문은 두 제품이 “the same model”이며 안전 장치 수준만 다르다고 설명하고, 벤치마크 주석에서 “the same underlying model”이라고 다시 명시합니다. Mythos를 소개하는 절에서는 “Claude Mythos 5.1 is identical to Fable 5.1”이라는 표현까지 씁니다. 다만 이것을 두 제품의 가중치가 비트 단위까지 같다는 뜻으로 확대해서는 안 됩니다. 공개 자료로 확인되는 범위는 Anthropic이 같은 기반 모델이라고 설명했다는 데까지입니다. 두 제품의 시스템 카드가 한 문서로 함께 발행됐다는 것도 같은 방향의 근거입니다.

같은 기반 모델 위에서 Fable과 Mythos는 서로 다른 경계를 가집니다.

Fable 5.1 제품 페이지는 사이버 보안과 생물학 분야에서 안전 장치가 플래그한 많은 질의를 더 낮은 능력의 모델로 자동 전환한다고 설명합니다. Mythos 5.1 제품 페이지는 Mythos에서도 dual-use 생물학·화학 연구 질문을 Opus 계열로 보내며 침투 테스트, exploit 생성, 바이너리 기반 취약점 스캔은 막는다고 밝힙니다. 즉 Fable 5.1을 선택했더라도 모든 요청이 끝까지 Fable의 기반 모델로 처리된다고 가정할 수 없고, Mythos를 받았다고 제한이 사라지는 것도 아닙니다.

같은 fallback도 제품 표면에 따라 다르게 동작한다

이 전환이 어떻게 일어나는지도 제품마다 다릅니다. Fable 제품 페이지의 FAQ는 대부분의 Claude 애플리케이션에서 사이버 안전 장치가 플래그한 질의는 Opus 4.8로, 생물학 안전 장치가 플래그한 질의는 Opus 5로 자동 전환된다고 설명합니다. 그러나 API 고객은 새로 도입된 Fallback API로 설정을 직접 구성해야 한다고 안내합니다. 같은 모델, 같은 안전 정책이라도 채팅 제품에서는 자동으로 처리되는 일이 API에서는 개발자가 다루어야 할 코드가 됩니다.

과금 조건도 함께 공개돼 있습니다. Anthropic은 전환된 요청에 Fable 가격을 청구하지 않는다고 밝혔습니다. fallback을 관측하고 회계 처리하려는 팀이 실제로 확인해야 하는 종류의 사양입니다.

fallback은 벤치마크 해석도 바꾼다

이 차이는 제품 사용에만 영향을 주지 않습니다. Anthropic은 공동 발표문에서 Fable 5.1을 프로덕션 안전 장치가 켜진 상태로 평가했다고 밝혔습니다. 안전 장치가 개입한 사이버 과제는 Claude Opus 4.8이, 생물학 과제는 Claude Opus 5가 대신 수행했고, OSWorld 2.0에서는 개입한 과제가 0점으로 기록됐습니다. 회사는 이 처리가 해당 벤치마크에서 Fable의 성능을 낮췄을 것이라고 덧붙였습니다.

따라서 Fable 5.1과 Mythos 5.1의 점수 차이를 보고 “기반 모델의 지능이 서로 다르다”고 결론 내리면 안 됩니다. 반대로 같은 기반 모델이니 점수가 반드시 같아야 한다고 말할 수도 없습니다. Anthropic은 Terminal-Bench 4.0 주석에서 두 모델의 격차가 이전의 덜 정밀한 사이버 안전 장치가 개입한 과제를 반영한 것이며, 이번에 개선한 안전 장치로 그 격차가 훨씬 줄어들 것으로 예상한다고 설명했습니다. 평가 결과에는 기반 모델뿐 아니라 안전 장치가 언제 개입했는지, fallback이 있었는지, 개입한 요청을 어떻게 채점했는지가 함께 들어갑니다.

모델 평가에서 평균 점수만으로 결론 내리면 안 되는 이유와 평가 설계 원칙은 AI 모델 성능 평가 지표 글에서 더 자세히 설명했습니다. 에이전트나 안전 장치가 포함된 시스템은 여기에 도구와 라우팅 조건까지 추가해야 합니다.

접근 정책과 데이터 보존도 제품 사양이다

Fable과 Mythos의 차이를 “하나는 안전하고 하나는 안전하지 않다”로 요약하는 것도 부정확합니다. Mythos는 제한이 없는 공개 모델이 아닙니다. Anthropic은 Mythos 5.1을 검증된 조직에만 trusted access 프로그램으로 제공하는데, 프로그램마다 준비 상태가 다릅니다. 생명과학 쪽 Life Sciences Verification Program은 초대 기반 베타로 시작해 첫 참여자를 받았고, 사이버 쪽 Cyber Verification Program은 아직 Opus·Sonnet 계열에 완화된 사이버 안전 장치를 적용하는 단계이며 Mythos 계열은 가까운 시일에 포함할 예정이라고 밝혔습니다. 프로그램과 별개로, 코드베이스를 검사해 패치를 제안하는 Claude Security 제품이 Mythos 5.1로 구동됩니다. 접근 대상은 현재 미국 조직으로 한정돼 있고, 미국 정부와 협의해 범위를 넓히는 중이라고 설명합니다.

같은 모델에 이르는 경로가 프로그램 심사, 제품 구매, 지역 조건으로 갈린다는 뜻입니다. 접근 심사와 지역 조건 자체가 배포 통제의 한 부분입니다.

데이터 정책은 두 제품 모두 기본값이 안전 모니터링용 30일 보존입니다. 여기서 갈리는 것은 예외 경로입니다. Anthropic은 고객이 통제하는 클라우드 인프라에 데이터를 두고 사람이 검토할 때도 고객이 직접 수행하는 Enterprise Frontier Safeguards(EFS)를 올가을부터 단계적으로 제공하겠다고 밝혔고, EFS가 준비되기 전에는 조건을 충족한 고객이 Fable 5.1을 Zero Data Retention으로 쓸 수 있다고 안내합니다. Mythos 제품 페이지에는 이런 예외 안내가 없고, 사용하려면 30일 보존 정책에 동의해야 한다고만 적혀 있습니다.

이 사실을 “Claude는 데이터를 보존하지 않는다”거나 “Anthropic은 모두 30일 보존한다”로 일반화하면 안 됩니다. 실제 계약에서는 제품, 계정, 프로그램, 지역과 시점을 모두 확인해야 합니다.

flowchart TD
    accTitle: Anthropic이 설명한 같은 기반 모델의 제품 경계
    accDescr: 같은 기반 모델이라는 Anthropic 설명 아래 Fable과 Mythos는 접근 조건과 안전 장치가 다릅니다. Fable의 fallback은 제품 표면에 따라 처리 방식도 다릅니다. 가중치의 완전한 동일성을 검증한 도표가 아닙니다.
    B["같은 기반 모델이라는
Anthropic의 설명"] --> F["Fable 5.1"]
    B --> M["Mythos 5.1"]
    F --> A["일반 제공
안전 장치가 일부 질의를 전환"]
    A --> C["대부분의 Claude 앱
자동 fallback"]
    A --> I["API
Fallback API 직접 구성"]
    M --> V["검증 프로그램·Claude Security
현재 미국 조직에 한정"]
    V --> R["완화된 안전 장치
일부 전환·차단은 유지"]

GPT-6 Astra: 강한 역량과 배포 권한을 분리한 사례

OpenAI는 2026년 9월 3일 GPT-6 Astra를 공개했습니다. Astra 안전 개요에서 OpenAI는 Astra를 자사 Preparedness Framework상 사이버 보안 역량이 Critical 수준에 도달한 첫 모델이라고 밝혔습니다.

여기서 Critical은 독립기관이 모든 AI에 공통으로 부여한 등급이 아닙니다. OpenAI가 자체 프레임워크와 자체 평가에 따라 내린 판정입니다. OpenAI의 설명에 따르면 이 수준은 적절한 도구와 접근이 주어졌을 때 사람이 각 단계를 안내하지 않아도 잘 보호된 여러 시스템에서 알려지지 않은 보안 결함을 찾고 새로운 악용 방법을 개발할 수 있는 능력을 뜻합니다. 특정 환경에서 무제한으로 공격에 성공한다는 뜻으로 읽어서는 안 됩니다.

일반 Astra와 고급 사이버 접근은 같은 말이 아니다

Astra 발표문은 제한된 조직부터 롤아웃을 시작해 ChatGPT Plus·Pro·Business·Enterprise와 OpenAI API, Microsoft Azure, AWS Bedrock으로 확대한다고 설명했습니다. 같은 발표문은 기업 관리자가 워크스페이스에서 Astra를 켤 수 있으며 출시 시점의 기본값은 꺼짐이라고도 밝혔습니다. 조직 설정 하나가 “이 모델을 쓸 수 있는가”를 결정한다는 뜻입니다.

접근 수준은 여기서 한 단계 더 나뉩니다. 발표문은 출시 버전의 Astra로 보안 코드 리뷰나 패치 같은 작업은 할 수 있지만, 취약점의 개념 증명 exploit을 만드는 것과 같은 더 고급 사이버 작업은 거부한다고 명시했습니다. 출시 이틀 전 공개된 Path to Astra는 고급 사이버 워크플로를 처음에는 소수의 알파 테스터에게 제공하고 이후 Daybreak Blue로 방어적 사용을 확대한다고 설명했고, Astra 시스템 카드는 이 구조를 Trusted Access for Cyber, 다른 이름으로 Daybreak access라고 부릅니다.

이 차이가 실제로 얼마나 큰지는 OpenAI가 직접 수치로 공개했습니다. 시스템 카드의 Daybreak Blue 평가표(Table 21)에서 gpt-6-astra라는 하나의 모델을 trusted access 없이 쓸 때와 Daybreak Blue로 쓸 때의 과제 완료율은 다음과 같습니다.

이 표는 OpenAI가 안전 장치 때문에 정당한 방어 작업이 막히지 않는지 확인하려고 만든 자체 평가이며, 값이 클수록 과제를 더 많이 완료했다는 뜻입니다. 독립 기관의 성능 비교가 아닙니다. 그래도 이 글의 논지에는 직접적인 근거입니다. 모델 ID도 버전도 같은데 접근 프로그램 하나로 개념 증명 exploit 작성 완료율이 2.4%에서 92%로 바뀝니다. 동시에 마지막 행은 Daybreak Blue가 만능 해제 스위치가 아니라는 것도 보여줍니다. 임의의 고급 사이버 요청을 측정하는 항목은 3.5%로 그대로입니다.

그래서 “우리 둘 다 GPT-6 Astra를 썼다”만으로는 같은 기능을 썼다고 볼 수 없습니다. 어떤 제품에서 실행했는지, 계정에 어떤 접근 권한이 있었는지, 어떤 사이버 안전 구성이 적용됐는지까지 확인해야 합니다.

계정의 위험 판정이 모델의 거절 경계를 바꾼다

배포 조건은 조직 단위에서 끝나지 않습니다. OpenAI는 안전 개요에서 잠재적 고위험으로 플래그된 사용자에게는 모델의 거절 경계를 더 보수적으로 조정해 더 넓은 범위의 dual-use 위험을 포괄하도록 훈련했다고 밝혔습니다. 시스템 카드도 위험이 높다고 평가된 계정에는 더 보수적인 행동 경계를 적용하고 모니터링 시스템이 참고하는 맥락을 넓힌다고 설명합니다.

같은 제품에서 같은 모델 ID로 같은 질문을 해도 계정의 위험 판정에 따라 거절 범위가 달라질 수 있다는 뜻입니다. 개별 계정의 판정 기준과 임계값은 공개돼 있지 않으므로, 어떤 요청이 거절됐을 때 그것을 곧바로 모델의 능력 한계로 읽으면 안 됩니다.

정렬과 배포 모니터링은 서로 다른 계층이다

OpenAI는 Astra 자체가 승인된 범위를 더 잘 지키도록 정렬했다고 설명하면서, 모델 외부에도 추가 방어선을 둡니다. Astra 발표문은 정렬 훈련 위에 얹는 시스템 안전 장치로 Codex의 Auto-review와 에이전트의 추론·행동 모니터링을 제시하고, 분류기가 잠재적인 무단 행동을 검사해 자동으로 중단할 수 있다고 설명합니다. 시스템 카드에 따르면 Auto-review는 미리 지정한 샌드박스 밖에서 실행되는 명령을 두 번째 모델이 검사해 위험하다고 판단하면 실행을 막는, Codex에 내장된 프로토콜입니다. 같은 기반 모델을 쓰더라도 이런 계층은 제품 표면마다 다르게 붙습니다.

제품 표면에 따라 사용자 경험도 달라집니다. OpenAI는 추가 안전 검사 때문에 정상적인 방어 작업도 느려지거나 일시 정지되거나 중단될 수 있으며, ChatGPT나 Codex에서는 사용자에게 검토를 요청할 수 있지만 API에서는 작업이 그대로 멈춘다고 설명합니다. 기반 모델이 같아도 승인 UI와 실행 정책이 다르면 실제로 완료할 수 있는 작업 범위가 달라집니다.

모니터링의 범위도 구분해야 합니다. OpenAI 안전 개요는 내부 개발·배포 환경에서 chain of thought(사고 과정)를 포함한 전체 trajectory(작업 궤적)의 보편적 모니터링을 보호 조치로 설명합니다. 외부 배포에 대해서는 도구를 사용하는 Astra 추론 전체에 misalignment monitoring(정렬 이탈 모니터링)을 적용한다고 밝힙니다. 내부 통제 문구를 모든 외부 요청의 보존·검토 방식으로 그대로 옮겨 쓰면 안 됩니다.

flowchart TD
    accTitle: 같은 Astra 모델과 서로 다른 배포 조건
    accDescr: OpenAI 자체 평가에서 같은 Astra 모델도 trusted access 유무에 따라 과제 완료율이 달랐습니다. 계정 위험 판정과 제품별 실행 통제도 별도 조건이며 Daybreak Blue가 모든 제한을 해제하지는 않습니다.
    M["같은 model ID
gpt-6-astra"] --> A["trusted access 없음"]
    M --> B["Daybreak Blue"]
    A --> E["OpenAI 자체 평가에서
일부 사이버 과제 완료율 차이"]
    B --> E
    B --> L["모든 고급 사이버 요청의
제한 해제를 뜻하지 않음"]
    P["계정 위험 판정"] --> R["거절 범위"]
    S["제품별 승인·모니터링"] --> X["실행·검토 요청·중단"]
    R --> O["실제 완료 가능한 작업"]
    X --> O
    E -.-> O

모델 이름만 적은 벤치마크는 재현하기 어렵다

비교표에 GPT-6 Astra나 Claude Fable 5.1만 적어서는 다른 사람이 같은 조건을 재현할 수 없습니다. 앞의 두 사례가 그 이유를 보여줍니다. 접근 프로그램, 제품 표면, 계정 판정 중 하나만 달라도 같은 모델 ID가 다른 결과를 냅니다.

이 표를 실제 기록으로 옮기면 아래 정도의 분량이 됩니다. 실제로 수행한 평가의 기록이 아니라 양식을 보여주는 예시이고, 성능 결과도 아닙니다. 제공사 공식 문서에서 값이나 선택지를 그대로 확인할 수 있는 항목은 [문서]로, 각 팀이 자기 계정과 평가 환경에서 채워야 하는 항목은 [환경]으로 표시했습니다. [환경] 줄의 값은 형식을 보여주려고 지어낸 것이니 그대로 옮겨 쓰지 마세요.

# 배포 사양 기록 양식 (평가 결과 파일에 함께 저장)
run_id: 2026-09-05-agent-eval-a   # [환경]
recorded_at: '2026-09-05'         # [환경]
model:
  provider: openai
  model_id: gpt-6-astra           # [문서] 현재 별칭과 스냅샷이 같은 이름
  knowledge_cutoff: '2026-04-30'  # [문서]
  context_window: 1050000         # [문서]
surface: api                      # [환경] ChatGPT / Codex / api 중 무엇인지
endpoint: v1/responses            # [문서] 모델이 지원하는 엔드포인트 중 사용한 것
inference:
  reasoning_effort: high          # [환경] 선택지는 [문서] low | medium | high | xhigh | max
  processing_mode: standard       # [환경] 선택지는 [문서] standard | fast | batch | flex
tools:                            # [환경] 실제로 켠 것만 적는다. 이름은 [문서] 기준
  - web_search
  - code_interpreter
  - mcp
account:
  rate_limit_tier: 3              # [환경] 계정의 실제 tier
  trusted_access: none            # [환경] Astra의 경우 none | daybreak_blue
  region: KR                      # [환경]
data_policy:
  retention: zdr                  # [환경] 계정 계약에서 확인해 적는다
harness:                          # 아래는 전부 [환경]
  task_set: internal-support-v4
  timeout_s: 900
  retries: 1
  scoring: rubric-llm-judge-v2

gpt-6-astra의 공식 모델 문서만 봐도 model ID 외에 reasoning effort 다섯 단계, 지원 도구 목록, 처리 모드, 사용 tier별 한도가 별도 항목으로 나옵니다. 이 변수들이 결과를 바꾸는 방식은 서로 다릅니다. 예를 들어 rate limit은 안전 장치가 아니고 Fable과 Mythos의 차이를 만든 원인으로 공개된 것도 아니지만, 처리량과 재시도 행동을 바꾸므로 운영 평가에는 남겨야 합니다.

스냅샷이 따로 제공되는 모델은 재현이 중요한 평가에서 고정하는 쪽이 유리합니다. 최신 별칭을 그대로 써야 하는 서비스라면 평가 결과에 실행 날짜와 당시 문서 상태를 남깁니다. 별칭이 같은 채로 구현이나 정책이 갱신되면 과거 결과를 그대로 재현하지 못할 수 있기 때문입니다.

flowchart TD
    accTitle: 평가 결과와 함께 남길 배포 조건
    accDescr: 모델 식별과 확인일, 실행 및 계정 조건, 평가 하네스를 결과와 함께 기록해야 비교 조건을 확인할 수 있습니다. 공개 문서값과 실제 환경값은 구분합니다.
    M["모델 ID·스냅샷 또는 확인일"] --> R["평가 결과와 함께 저장"]
    S["제품 표면·추론 설정
도구·시스템 지시"] --> R
    A["안전 구성·계정 조건
데이터 정책"] --> R
    H["과제·채점기
재시도·타임아웃"] --> R
    R --> D["공식 문서값과
실제 환경값을 구분"]
    D --> C["조건 차이를 확인하며 비교"]

개발자가 관리해야 할 배포 조건

모델과 배포 설정을 분리한다

애플리케이션 설정에서 모델 이름 하나에 모든 정책을 묶으면 나중에 원인을 분리할 수 없습니다. 위 기록 예시처럼 모델, 표면, 추론 설정, 도구 권한, 시스템 지시, 승인 규칙, 안전 이벤트 처리, 데이터 조건을 각각 독립된 설정과 변경 이력으로 관리해야 모델만 교체했을 때와 권한 정책을 바꿨을 때의 영향을 구분할 수 있습니다.

같은 모델을 쓰더라도 읽기 전용 에이전트와 배포 권한을 가진 에이전트는 다른 배포로 취급합니다. Astra의 워크스페이스 기본값이 꺼짐이었던 것처럼, 조직 설정 한 줄이 기능 유무를 가르는 경우도 배포 사양에 들어갑니다.

도구 권한은 최소 범위로 설계한다

모델이 도구를 “지원한다”는 말은 그 도구에 모든 권한을 줘야 한다는 뜻이 아닙니다. 검색, 파일 읽기, 파일 쓰기, 명령 실행, 외부 메시지 전송은 위험과 되돌리기 가능성이 다릅니다. 도구마다 대상 리소스와 허용 행동을 나누고, 결과를 바깥으로 보내거나 삭제하는 행동에는 별도의 승인 규칙을 둡니다.

이 원칙은 성능 평가에도 중요합니다. 인터넷 검색이 가능한 에이전트와 모델 내부 지식만 쓰는 에이전트의 정답률을 같은 조건처럼 비교하면 모델과 도구의 기여를 분리할 수 없습니다.

fallback과 안전 개입을 실패 원인에서 분리한다

운영 로그에서 모든 비정상 결과를 model_error 하나로 합치면 원인을 찾을 수 없습니다. 제공사가 노출하는 범위 안에서 모델·서비스 오류, 정책에 따른 거절, 사람 승인 대기 중 중단, 안전 모니터의 중단, 다른 모델로의 fallback, 도구 호출 실패를 각각 다른 상태로 기록합니다. Anthropic이 전환된 요청에 Fable 가격을 청구하지 않는다고 밝힌 것처럼, 전환 경로에는 과금 조건이 따라붙는 경우도 있습니다.

fallback이 최종 답변을 성공적으로 만들었더라도 원래 모델의 성공으로만 집계하면 모델별 비용과 품질을 잘못 해석합니다. 반대로 안전 장치가 중단한 요청을 전부 모델의 추론 실패로 세면 실제 능력을 과소평가합니다. 제품 안전성과 원시 모델 능력은 별도의 지표로 봐야 합니다.

데이터 보존은 계정의 실제 계약으로 확인한다

공개 발표의 ZDR 문구만 보고 민감한 데이터를 보내서는 안 됩니다. Fable과 Mythos가 기본값은 같은 30일 보존인데 예외 경로만 다른 것처럼, 차이는 대개 기본값이 아니라 조건부 예외에 있습니다. 실제 배포 전에 계정에 적용되는 계약, 지역, 예외, 안전 모니터링 조건을 확인하고 그 근거 문서의 버전과 날짜를 남깁니다.

점수보다 조건 묶음을 비교한다

가능하다면 같은 과제, 같은 도구, 같은 권한, 같은 타임아웃, 같은 재시도 정책으로 모델을 평가합니다. 제공사별 안전 구성을 완전히 맞출 수 없다면 그 차이를 숨기지 말고 결과 옆에 적습니다.

최종 비교표에 정답률이나 선호도만 두면 판단이 어렵습니다. 작업 성공률, 정책 개입률, fallback률, 비용, p50·p95 지연시간을 분리해야 “더 높은 점수”가 실제 서비스에서도 더 나은 선택인지 알 수 있습니다. 제공사가 공개하지 않는 내부 라우팅 규칙은 추정으로 채우지 말고, 관찰 가능한 범위와 모르는 범위를 함께 남깁니다.

flowchart TD
    accTitle: 배포 설정과 관측 결과를 분리하는 운영 흐름
    accDescr: 모델과 배포 조건을 각각 관리하고 실제 처리 상태를 구분해 기록합니다. 성공률과 정책 개입, fallback, 비용과 지연을 분리해 비교하는 개념도이며 내부 처리 순서를 뜻하지 않습니다.
    A["모델과 배포 설정을
각각 관리"] --> B["최소 도구 권한·승인 규칙
계정의 실제 데이터 계약 확인"]
    B --> C["실행 결과와 처리 경로 기록"]
    C --> D["모델·서비스 오류
도구 호출 실패"]
    C --> E["정책 거절·승인 대기
안전 모니터 중단"]
    C --> F["원래 모델 처리
또는 fallback"]
    D --> G["성공률·정책 개입률·fallback률
비용·지연시간을 분리해 비교"]
    E --> G
    F --> G

공개 자료만으로는 알 수 없는 것

공식 발표가 있어도 모든 배포 세부 사항을 검증할 수 있는 것은 아닙니다.

• Anthropic이 Fable 5.1과 Mythos 5.1을 같은 기반 모델이라고 설명한 것은 확인되지만, 가중치의 완전한 동일성은 공개 자료로 검증할 수 없습니다.
• 비공개 시스템 지시, 안전 분류기의 임계값, 계정 위험 판정 기준과 전체 라우팅 규칙은 공개되지 않았습니다.
• 각 회사가 자사 정책 문서에서 정의한 Critical, safeguard, trusted access는 그 체계 안에서만 뜻이 정해집니다. 회사를 가로질러 같은 척도처럼 비교할 수 없습니다.
• 출시사의 시스템 카드와 벤치마크는 중요한 1차 자료이지만 회사 자체 평가입니다. 위에 인용한 Daybreak Blue 완료율도 마찬가지이며, 독립 검증과 같은 뜻으로 인용하면 안 됩니다.
• 안전 정책은 출시 후에도 바뀝니다. Anthropic은 안전 장치 개선으로 두 제품의 벤치마크 격차가 줄어들 것이라고 밝혔고, OpenAI는 몇 주 안에 Daybreak 접근을 넓히겠다고 밝혔습니다. 2026년 9월 5일의 제공 범위와 fallback 정책은 영구 사양이 아닙니다.

제품의 차이가 전부 안전 장치 때문인 것도 아닙니다. 컨텍스트 구성, 도구 구현, UI, 처리 모드, 지연시간 최적화와 계정별 한도도 결과에 영향을 줍니다. 공개 근거가 없는 원인을 특정하기보다, 재현 가능한 설정과 관찰 결과를 남기는 편이 안전합니다.

flowchart TD
    accTitle: 공개 자료에서 확인되는 것과 알 수 없는 것
    accDescr: 공식 설명과 제조사 자체 평가, 비공개 내부 구성을 구분합니다. 실제로 관찰한 설정과 결과를 별도로 기록하되 비공개 원인을 추정으로 확정하지 않습니다.
    P["공식 공개 자료"] --> D["확인 가능
회사 설명·공개 정책"]
    P --> E["제조사 자체 평가
독립 검증과 구분"]
    P --> U["공개 자료로 검증 불가
가중치 완전 동일성·내부 임계값"]
    D --> T["확인 시점과 적용 범위를 명시"]
    E --> T
    U --> N["모르는 원인을
추정으로 채우지 않음"]
    O["실제로 관찰한 설정·결과"] --> R["재현 가능한 근거로 기록"]
    T --> R
    N --> R

이제는 모델명 옆에 배포 조건을 적어야 한다

모델 이름은 여전히 중요하지만 실제 기능을 설명하는 충분한 사양은 아닙니다. Claude Fable 5.1과 Mythos 5.1은 같은 기반 모델이라는 회사의 설명에도 불구하고 안전 장치, trusted access, 지역, fallback 경로가 다릅니다. GPT-6 Astra는 같은 model ID로도 접근 프로그램에 따라 사이버 과제 완료율이 몇 배씩 갈린다는 것을 제조사 자신이 표로 남겼습니다.

“같은 모델인데 왜 다르지?”라는 물음을 제품 결함이나 막연한 성능 편차로 넘기기 전에, 배포 구조가 달랐는지부터 확인할 수 있습니다. 위의 두 사례는 그것만으로도 결과가 크게 갈릴 수 있다는 것을 보여줍니다. 위의 기록표와 예시를 평가 결과 옆에 함께 남기면 그 차이를 실제로 분석할 수 있습니다. 특히 조직·계정 조건과 fallback의 처리 경로·과금은 빠뜨리기 쉬우면서 결과를 크게 바꾸는 항목이니 먼저 확인해 두는 것이 좋습니다.

flowchart TD
    accTitle: 모델명에서 배포 조건까지 넓히는 비교
    accDescr: 같은 모델을 사용했다는 말에 모델명과 제품, 도구 및 권한, 계정과 fallback 조건을 함께 기록하고 실제 결과와 연결해 차이를 분석합니다.
    Q["같은 모델인데
결과가 다른 상황"] --> M["정확한 모델명 확인"]
    M --> D["제품·도구·권한
안전 장치 확인"]
    D --> A["조직·계정 조건 확인"]
    A --> F["fallback 처리 경로
과금 조건 확인"]
    F --> R["조건 기록을
평가 결과 옆에 보존"]
    R --> C["배포 조건과 결과의
차이를 함께 분석"]

공식 자료

• OpenAI: GPT-6 Astra 발표
• OpenAI: GPT-6 Astra 안전 개요
• OpenAI: Astra로 향하는 길
• OpenAI API: GPT-6 Astra 모델 문서
• OpenAI: GPT-6 Astra 시스템 카드
• Anthropic: Claude Fable 5.1과 Mythos 5.1 공동 발표
• Anthropic: Claude Fable 제품 페이지
• Anthropic: Claude Mythos 제품 페이지
• Anthropic: 모델 시스템 카드 목록