Rihpig

Posted on Jun 12 • Originally published at apidog.com

클로드 페이블 5 및 미소스 API 변경점: 여전히 유효한 기능과 테스트 방법

Anthropic은 Fable 및 Mythos 모델 라인을 출시하면서 기존 Claude API 사용자에게 영향을 줄 수 있는 정책과 동작 변경을 함께 적용했습니다. 개발자가 확인해야 할 핵심은 두 가지입니다. Fable 및 Mythos 트래픽에 대한 30일 데이터 보존 요구 사항, 그리고 일부 프롬프트에서 응답이 거부되거나 재구성될 수 있는 가드레일 동작 변화입니다.

지금 Apidog를 사용해 보세요

이 글은 Claude API 통합을 유지하는 개발자가 바로 확인해야 할 항목만 정리합니다. 무엇이 바뀌었고, 무엇은 그대로이며, Apidog로 실제 요청을 검증하는 방법을 단계별로 다룹니다. 지금 필요한 것은 추측이 아니라, 여러분의 프로덕션 프롬프트와 클라이언트 코드가 여전히 기대대로 동작하는지 테스트하는 것입니다.

실제로 변경된 사항

논의에서 섞여 있는 내용을 분리하면 확인해야 할 범위가 명확해집니다.

1. 데이터 보존

Fable 및 Mythos 요청에는 30일 보존 기간이 적용되는 것으로 보고되었습니다. 즉, 해당 모델로 전송한 요청 및 응답 데이터가 즉시 삭제되지 않고 일정 기간 보존될 수 있습니다.

개발팀이 확인해야 할 항목은 다음과 같습니다.

사용자 프롬프트에 개인정보 또는 민감 정보가 포함되는가?
시스템 프롬프트에 내부 정책, 고객 데이터, 토큰, 식별자가 포함되는가?
개인정보 처리방침에서 “프롬프트를 저장하지 않는다”와 같은 문구를 사용하고 있는가?
상위 공급자의 보존 정책이 자체 데이터 처리 약속과 충돌하지 않는가?

정책 자체를 코드로 해결할 수는 없지만, 어떤 데이터를 외부 API로 보내는지는 통제할 수 있습니다.

2. 가드레일 동작

일부 보안 연구자들은 Fable의 가드레일 동작 변경에 반발했습니다. 핵심 문제는 가드레일의 존재가 아니라, 이전에 통과하던 요청이 별도 공지 없이 거부되거나 다른 형식으로 재구성될 수 있다는 점입니다.

이 변화는 다음 유형의 애플리케이션에 직접적인 영향을 줍니다.

고정된 JSON 형식 응답을 파싱하는 백엔드
분류, 라벨링, 요약 결과를 자동 처리하는 워크플로
스트리밍 응답을 UI에 실시간 표시하는 앱
모델 응답을 다시 도구 호출 또는 에이전트 단계로 넘기는 시스템

따라서 “API 호출이 성공하는가”만 확인하면 부족합니다. “응답 구조와 의미가 여전히 앱의 가정과 일치하는가”를 테스트해야 합니다.

3. 프로그래밍 방식 접근

API 표면 자체가 교체된 것은 아닙니다. 기존 인증 방식, messages 호출, 도구 사용 스키마는 계속 작동합니다.

변경 가능성이 있는 것은 계약이 아니라 동작입니다.

어떤 프롬프트가 거부되는가
응답 시간이 부하 상황에서 어떻게 변하는가
스트리밍 중 가드레일이 개입하면 어떤 이벤트가 오는가
이전과 동일한 프롬프트가 동일한 구조로 반환되는가

요약하면, API 계약은 안정적이지만 모델 동작은 고정되어 있다고 가정하면 안 됩니다. 그래서 기준선 테스트가 필요합니다.

여전히 작동하는 것

코드를 다시 작성하기 전에, 변경되지 않은 부분을 먼저 확인하세요. 불필요한 마이그레이션을 피할 수 있습니다.

인증: API 키와 x-api-key 헤더는 기존과 동일하게 작동합니다. 이 변경 때문에 키를 강제로 교체할 필요는 없습니다. 다만 정기적인 키 로테이션은 여전히 권장됩니다. 현재 헤더 계약은 Anthropic의 API 레퍼런스를 확인하세요.
Messages API 형태: model, max_tokens, system, messages 배열 등 기본 요청 본문 구조는 유지됩니다.
도구 사용: 도구 정의, tool_use, tool_result 왕복 흐름은 계속 사용할 수 있습니다.
스트리밍: 서버 전송 이벤트 방식은 유지됩니다. 다만 가드레일이 중간에 개입할 때 스트림 내용은 달라질 수 있습니다.
모델 ID 지정: 부동 별칭 대신 전체 모델 ID를 고정하면 어떤 모델을 호출하는지 더 명확하게 제어할 수 있습니다.

즉, 현재 해야 할 작업은 대규모 재작성보다 검증입니다. 앱이 의존하는 동작을 테스트로 고정하고, 변경이 발생하면 빠르게 감지해야 합니다.

Apidog로 Claude 통합을 테스트하는 방법

변경 로그만 읽어서는 실제 영향을 알 수 없습니다. 여러분의 프롬프트, 헤더, 클라이언트 타임아웃, 파서가 함께 동작하는 실제 요청을 보내고 결과를 확인해야 합니다.

Apidog를 사용하면 Claude API 요청을 저장하고, 환경 변수를 관리하고, 응답에 단언(assertion)을 추가하고, 모의 서버로 CI 테스트를 분리할 수 있습니다. Postman 없이 API 테스트 환경을 구성하려면 Postman 없이 API 테스트를 수행하는 방법도 참고할 수 있습니다.

1. 프로덕션에 가까운 기준 요청 만들기

먼저 장난감 프롬프트가 아니라 실제 앱이 사용하는 대표 프롬프트를 선택하세요.

예를 들어 고객 지원 티켓을 요약하고 우선순위를 분류하는 기능이라면, Apidog에서 다음과 같은 요청을 저장합니다.

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "claude-fable-5",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "Summarize this support ticket and label its priority: ..."
    }
  ]
}

구성 시 확인할 점은 다음과 같습니다.

model에는 가능한 한 전체 모델 ID를 사용합니다.
ANTHROPIC_API_KEY는 Apidog 환경 변수로 저장합니다.
스테이징, 프로덕션 환경을 분리합니다.
기준 응답을 저장해 나중에 비교할 수 있게 합니다.

API 키를 요청 본문이나 문서에 직접 하드코딩하지 마세요. 환경 변수로 관리하면 Claude, Claude Code의 SDK, 다른 모델 테스트에서도 동일한 패턴을 재사용할 수 있습니다.

2. 응답을 눈으로 보지 말고 단언으로 검증하기

기준 응답을 저장하는 것만으로는 부족합니다. 자동으로 실패를 감지할 수 있어야 합니다.

Apidog에서 다음 항목에 대한 assertion을 추가하세요.

HTTP 상태 코드가 200인지
stop_reason이 end_turn인지
stop_reason이 예상치 못한 거부 또는 max_tokens 잘림이 아닌지
응답 본문에 앱이 파싱하는 필드가 존재하는지
응답 시간이 클라이언트 타임아웃 예산 안에 들어오는지

예를 들어 앱이 모델 응답에서 priority 값을 추출한다면, 단순히 “문장이 자연스러운가”가 아니라 “파서가 기대하는 필드가 존재하는가”를 테스트해야 합니다.

{
  "priority": "high",
  "summary": "..."
}

이 접근은 API 계약 테스트와 같은 원칙입니다. 다운스트림 코드가 의존하는 응답 형태를 테스트로 고정하는 것입니다.

3. 거부 및 가드레일 경로를 의도적으로 테스트하기

대부분의 팀은 정상 경로만 테스트합니다. 하지만 이번 변경에서 중요한 부분은 거부 동작입니다.

다음과 같은 프롬프트 세트를 별도로 만드세요.

콘텐츠 정책 경계에 가까운 요청
이전에 허용되던 보안 연구 또는 분석 요청
사용자 입력에 위험하거나 애매한 문구가 포함된 요청
앱이 반드시 안전하게 실패해야 하는 요청

각 요청에 대해 다음을 확인합니다.

상태 코드
stop_reason
응답 메시지 형식
사용자에게 표시할 수 있는 오류 메시지인지
파서가 예외 없이 처리하는지

이전에는 정상 응답이던 프롬프트가 갑자기 거부되거나 재구성되면 assertion이 실패해야 합니다. 거부 동작을 “예외 상황”이 아니라 테스트 대상 계약으로 다루세요.

4. Anthropic API를 모의하여 CI를 안정화하기

CI에서 매번 실시간 Claude API를 호출하면 다음 문제가 생깁니다.

토큰 비용 발생
속도 제한
네트워크 변동
모델 동작 변화로 인한 비결정적 테스트
외부 장애가 내부 빌드 실패로 전파

Apidog의 모의 서버를 사용하면 저장된 응답을 기반으로 가짜 Messages API 엔드포인트를 만들 수 있습니다.

권장 흐름은 다음과 같습니다.

실제 Claude API로 대표 요청을 실행합니다.
정상 응답, 거부 응답, 오류 응답을 캡처합니다.
Apidog 모의 서버에 응답 예시를 등록합니다.
개발 및 CI 환경의 base URL을 모의 서버로 바꿉니다.
실제 API 검증은 별도의 스케줄 테스트에서만 실행합니다.

이렇게 하면 앱 코드는 실제 응답 구조를 기준으로 테스트되지만, 매번 토큰을 소비하거나 실시간 모델 동작에 의존하지 않습니다. 에이전트를 구축하는 경우에도 같은 방식이 유용합니다. 자세한 패턴은 AI 에이전트 테스트 설정에서 확인할 수 있습니다.

5. 30일 보존에 민감한 페이로드 감사하기

30일 보존 기간이 규정 준수에 영향을 준다면, 코드 레벨에서 아웃바운드 페이로드를 점검해야 합니다.

확인할 항목은 다음과 같습니다.

프롬프트에 원본 사용자 데이터 전체를 보내고 있는가?
요약 또는 마스킹된 데이터로 충분한가?
시스템 프롬프트에 내부 정책이나 민감한 식별자가 포함되어 있는가?
로그, 요청 기록, 테스트 케이스에 실제 고객 데이터가 남아 있는가?
모델 호출 전에 PII 제거 단계를 둘 수 있는가?

Apidog의 요청 기록을 확인하면 통합이 실제로 어떤 JSON 페이로드를 보내는지 감사할 수 있습니다. Anthropic의 보존 정책을 직접 바꿀 수는 없지만, 외부로 보내는 데이터의 양과 민감도는 줄일 수 있습니다.

6. 부하, 지연 시간, 타임아웃을 반복 테스트하기

모델 동작 변화는 부하 상황에서 더 잘 드러납니다. 단일 요청이 성공해도 프로덕션에서 안전하다고 볼 수 없습니다.

Apidog에서 동일 요청을 반복 실행하며 다음을 확인하세요.

평균 응답 시간
p95 또는 p99 지연 시간
간헐적인 타임아웃
부분 스트림 발생 여부
재시도 시 중복 처리 문제
가드레일 개입 빈도 변화

클라이언트 코드에서는 현실적인 타임아웃과 재시도 정책을 설정해야 합니다.

예를 들어 다음과 같은 의사 코드를 기준으로 동작을 점검할 수 있습니다.

async function callClaudeWithRetry(payload, retries = 2) {
  for (let attempt = 0; attempt <= retries; attempt++) {
    try {
      const res = await fetch("https://api.anthropic.com/v1/messages", {
        method: "POST",
        headers: {
          "x-api-key": process.env.ANTHROPIC_API_KEY,
          "anthropic-version": "2023-06-01",
          "content-type": "application/json"
        },
        body: JSON.stringify(payload),
        signal: AbortSignal.timeout(30000)
      });

      if (!res.ok) {
        throw new Error(`Claude API failed: ${res.status}`);
      }

      return await res.json();
    } catch (err) {
      if (attempt === retries) throw err;
      await new Promise(resolve => setTimeout(resolve, 500 * (attempt + 1)));
    }
  }
}

재시도는 장애를 숨기는 장치가 아닙니다. 느린 응답, 잘린 응답, 거부 응답을 실제로 처리하는지 테스트해야 합니다. 상위 시스템 타임아웃을 디버깅해야 한다면 상위 요청 시간 초과 수정 접근 방식도 참고할 수 있습니다.

실용적인 체크리스트

Claude API 통합을 유지한다면 다음 항목을 바로 점검하세요.

[ ] 프로덕션 경로에서 부동 모델 별칭 대신 전체 모델 ID를 사용한다.
[ ] 대표 프로덕션 프롬프트에 대한 기준 응답을 저장한다.
[ ] 상태 코드, stop_reason, 응답 필드에 assertion을 추가한다.
[ ] 거부 응답과 오류 응답을 별도 테스트 케이스로 관리한다.
[ ] 스트리밍 응답이 중간에 변경될 때 클라이언트가 안전하게 처리하는지 확인한다.
[ ] Apidog 모의 서버로 CI가 실시간 API에 의존하지 않도록 분리한다.
[ ] 외부로 전송되는 프롬프트에서 불필요한 민감 정보를 제거한다.
[ ] 30일 보존 정책이 자체 개인정보 처리방침과 충돌하지 않는지 확인한다.
[ ] 부하 상황에서 타임아웃과 재시도 정책을 반복 테스트한다.

이 작업은 Anthropic의 추가 발표를 기다리지 않아도 됩니다. 여러분의 통합이 실제로 어떤 요청을 보내고 어떤 응답에 의존하는지 지금 검증할 수 있습니다.

자주 묻는 질문

Fable 및 Mythos 변경 때문에 API 키를 바꿔야 하나요?

아니요. 인증 방식은 변경되지 않았습니다. x-api-key 기반 인증은 계속 작동합니다. 다만 정기적인 키 로테이션은 보안 관점에서 계속 권장됩니다.

기존 Messages API 코드가 깨지나요?

요청 및 응답 계약 자체는 유지됩니다. 기존 messages 호출과 도구 사용 코드는 계속 실행됩니다. 다만 거부 동작, 지연 시간, 스트리밍 내용, 응답 구조가 바뀔 수 있으므로 테스트가 필요합니다.

30일 보존 변경은 무엇을 의미하나요?

보고에 따르면 Fable 및 Mythos 트래픽에 30일 보존 기간이 적용됩니다. 자체 개인정보 보호 약속이 상위 공급자의 데이터 처리 방식에 의존한다면, 실제로 어떤 데이터를 전송하는지 감사해야 합니다. 공식 조건은 항상 Anthropic의 최신 데이터 사용 문서를 확인하세요.

사용자보다 먼저 가드레일 변경을 감지하려면 어떻게 해야 하나요?

콘텐츠 경계에 가까운 프롬프트를 테스트 케이스로 만들고, 기준 응답과 assertion을 저장하세요. Apidog에서 정기적으로 실행하면 이전에 통과하던 요청이 거부되거나 형식이 바뀌는 시점을 빠르게 알 수 있습니다.

토큰 비용 없이 테스트할 수 있나요?

예. Apidog의 모의 서버를 사용해 정상 응답, 거부 응답, 오류 응답을 재생하면 개발 및 CI 환경에서 실시간 Claude API를 호출하지 않아도 됩니다.

마무리

Fable 및 Mythos 변경은 API가 완전히 깨졌다는 의미가 아닙니다. 대부분의 개발자에게 핵심은 계약 변경이 아니라 동작과 정책 변경입니다. 키는 그대로 작동하고, Messages API도 계속 호출되며, 도구 사용 흐름도 유지됩니다.

문제는 조용히 바뀔 수 있는 부분입니다.

어떤 프롬프트가 거부되는가
응답 시간이 늘어나는가
스트리밍 중 어떤 이벤트가 오는가
데이터가 외부 시스템에서 얼마나 보존되는가

모델 ID를 고정하고, 기준 응답을 저장하고, assertion으로 검증하고, 모의 서버로 CI를 안정화하세요. Apidog를 다운로드하면 “아마 계속 작동할 것”을 “테스트했고 증거가 있다”로 바꿀 수 있습니다.

DEV Community