Claude Fable 5.5 vs Fable 5.1: 업그레이드 전 테스트 방법
업그레이드 경로에서 알려진 내용은 무엇인가요?
| 마이그레이션 질문 | 지금 할 수 있는 일 | 근거를 기다려야 하는 부분 |
|---|---|---|
| 모델 ID를 바로 바꿀 수 있나요? | 현재 경로의 설정 위치 확인 | 정확한 후보 ID와 지원 요청 규약 확인 |
| 도구와 구조화 출력이 똑같이 동작하나요? | 스키마, 테스트 데이터, 합격 검사를 보관 | 검증된 후보 경로에서 재실행 |
| 기존 대화를 올바르게 이어갈 수 있나요? | 민감 정보를 제거한 대표 기록 저장 | 기록 수용과 이어쓰기 동작 테스트 |
| 캐시와 비용을 그대로 이어갈 수 있나요? | 현재 사용량과 실제 비용 기록 | 후보 규칙과 과금 검증. 캐시 이전은 가정하지 않음 |
| 전체 대체가 필요한가요? | 실제로 개선이 필요한 워크로드 파악 | 결과를 비교하고 마이그레이션 자체가 필요한지 판단 |
이후 내용은 제안하는 마이그레이션 절차입니다. Fable 5.5가 특정 기능을 지원하거나 출시 일정이 정해졌다는 뜻은 아닙니다.
Fable 5.1에 실제로 존재하는 연동 제약부터 확인하세요
tool_choice의 any, tool 모드가 오류를 반환한다고 설명합니다. 이전 모델로 돌아가거나 앞선 대화 내용을 바꿀 때 thinking block 유지에도 제한이 있습니다. 이는 5.1의 기존 규칙이지 새로 발견한 5.5의 변경점이 아닙니다. 정확한 게이트웨이 경로에 적용되는지는 별도로 검증하세요.| 기존 의존성 | 현재 앱에서 보존할 자료 | 향후 이전에서 확인할 질문 |
|---|---|---|
| 도구 선택 | 스키마, 필수 업무 동작, 앱이 실제 수행 여부를 검증하는 방법 | 후보가 해당 제어를 지원하며 비지원 강제 선택 없이 동작을 완료하는가? |
| thinking을 포함한 이력 | 원래 순서의 메시지, 받은 그대로의 불투명 블록, 이력 변환 버전 | 후보와 폴백 모델에서 어떤 블록이 유효한가? |
| 클라이언트 압축 | 변환 전후 이력, 요약된 턴, 남겨 둔 후속 블록 | 변환 이력이 수용되며 사용자의 결정을 보존하는가? |
| 스트리밍과 파싱 | 원시 이벤트, 도구 호출 조립, 종료·오류 분기, 파서 버전 | 기존 파서가 출력을 재구성하고 완료와 중단을 구별하는가? |
| 사용량과 캐시 | 겹치지 않는 사용량 분류, 실제 청구, 콜드·웜 실행 | 기대하는 캐시 동작을 보존하며 새 세션 총비용은 얼마인가? |
진단에서 중요한 구분이 있습니다. 앱이 앞선 턴을 수정한 뒤 5.1 요청부터 거절된다면, 이는 기존 연동의 문제입니다. 아직 시험하지 않은 후속 모델의 회귀로 집계하면 안 됩니다. 각 테스트를 현재 작동하는 경로에서 먼저 실행하고 기존 실패를 기록한 뒤 후보를 추가하세요.
업무 상태와 모델 추론 상태도 복구 경로가 달라야 합니다. 티켓 ID와 사용자가 승인한 담당자는 애플리케이션의 영속 상태에 저장할 정보입니다. thinking block은 모델별 이력 요소이므로 보관했다고 다른 모델이 읽을 수 있는 것은 아닙니다. 폴백에서 승인된 업무 사실은 유지하되, 문서로 지원되는 다른 이력 표현이 필요할 수 있습니다.
모델, 시스템 프롬프트, 도구, 압축 방식을 한 실험에서 동시에 바꾸지 마세요. 프롬프트 템플릿, 도구 정의와 대표 응답, 파서 버전을 저장하고 소프트웨어가 소비하는 출력과 사람이 검토하는 출력을 구분합니다. 처음에는 샌드박스나 기록된 도구 응답으로 재생하세요. 메시지 전송, 레코드 생성, 결제가 두 번 실행되는 것은 비교 과정에서 허용할 부작용이 아닙니다.
회귀를 찾을 수 있는 재실행 세트를 만드세요
성공한 Fable 5.1 세션과 미해결 실패를 모두 포함하세요. 후보가 어려운 작업 하나를 고쳐도 흔한 워크플로우를 망가뜨리면 애플리케이션에는 업그레이드가 아닐 수 있습니다. 후보 출력을 보기 전에 기대 결과를 정의하세요.
| 재실행 사례 | 확인할 것 | 실패 조건 예시 |
|---|---|---|
| 새 요청 | 필수 지시와 출력 필드 준수 | 필수 필드 누락 또는 제약 무시 |
| 긴 기존 대화 기록 | 중요한 상태와 사용자 결정 유지 | 이어지는 내용이 이전 승인된 결정과 모순 |
| 도구 호출과 도구 결과 | 인자, 순서, 최종 응답의 유효성 | 도구 중복 실행 또는 결과 오해 |
| 구조화 출력 | 스키마 검증과 필드 의미 모두 통과 | 유효한 JSON에 잘못된 식별자나 값 포함 |
| 중단되거나 실패한 요청 | 재시도와 대체 경로 후 일관된 상태 | 부작용 중복 또는 일부 상태 방치 |
| 일상적인 성공 작업 | 현재 품질과 지연 유지 | 흔히 성공하던 작업의 실패나 시간 초과 |
후보 경로에 문서화된 기능만 사용하세요. 지원되지 않거나 검증되지 않은 기능은 해당 워크플로우의 마이그레이션 차단 요인으로 표시하고, 사례를 결과에서 몰래 빼지 마세요.
기존 Fable 5.1 에이전트의 구체적인 재실행 예제
TEST-17을 반환한 도구 응답, 새 티켓을 만들지 말고 그 티켓을 수정하라는 사용자 지시가 들어 있습니다. 이는 설명용 애플리케이션 사례이지 모델 동작을 측정한 보고가 아닙니다.필요 상태를 담은 새 요청, 원래 대화 기록, 모의 시간 초과 후 재개된 세션의 세 형태로 재실행하세요. 첫 실행에서는 도구 응답을 고정하세요. 그다음 현실적인 도구 오류를 넣은 별도 샌드박스 테스트를 실행하세요.
| 합격 항목 | 보관할 근거 | 실패 대응 |
|---|---|---|
| 올바른 티켓을 수정함 | 도구 이름, 인자, 최종 샌드박스 레코드 | 잘못된 ID나 의도치 않은 생성 작업은 불합격 |
| 사용자가 승인한 필드가 유지됨 | 수정 전후 레코드 차이 | 승인하지 않은 필드 변경은 불합격 |
| 재시도가 이미 확정된 작업을 반복하지 않음 | 애플리케이션 작업 ID와 도구 실행 로그 | 사례를 중단하고 재시도·상태 처리 점검 |
| 최종 답변이 실제 결과와 일치함 | 답변과 기록된 도구 결과 비교 | 수정 실패 후 성공을 주장하면 불합격 |
| 대체 경로가 안전하게 이어서 실행함 | 복구 상태와 유지한 경로의 재실행 | 복구가 작동할 때까지 트래픽 확대 금지 |
각 시도마다 사례 ID, 모델 경로, 클라이언트·프롬프트 버전, 기록 변환, 도구 로그, 합격·실패 이유, 비용, 검토 시간을 간결하게 기록하세요. 미테스트 결과는 비워 두고 합격으로 표시하지 마세요. 새 요청은 통과하지만 기존 기록 세션이 실패하면 모든 프롬프트를 바꾸기 전에 기록 전달 경계를 조사하세요. 두 형태가 같은 기대 상태 검사에서 실패하면 요청과 도구 규약을 먼저 살펴보세요.
이 테스트 데이터는 “업그레이드가 좋다”는 주장을 반증 가능하게 만듭니다. 유창한 답변도 중복 티켓이나 손상된 상태를 숨길 수 없습니다. 실제 영향을 일으키는 자체 애플리케이션 작업에도 같은 방식을 적용하세요.
{
"case_id": "ticket-update-17",
"before": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "normal", "status": "open"}
},
"instruction": "Set TEST-17 priority to high. Keep its owner and status. Do not create another ticket.",
"expected_after": {
"ticket_count": 1,
"ticket": {"id": "TEST-17", "owner": "Mina", "priority": "high", "status": "open"}
},
"allowed_changed_fields": ["ticket.priority"],
"forbidden_operations": ["create_ticket", "close_ticket"]
}지시는 TEST-17의 우선순위만 high로 높이고 담당자와 상태는 유지하며 다른 티켓은 만들지 말라는 뜻입니다. 새 상태 사례에는 현재 티켓과 지시를 제공합니다. 이력 사례에는 앞선 승인, 생성 응답, 갱신 지시를 유지합니다. 복구 사례에서는 샌드박스가 갱신을 적용한 다음 응답을 숨겨, 쓰기는 커밋됐지만 클라이언트는 타임아웃된 상황을 만듭니다. 앱은 작업을 반복하기 전에 기존 레코드를 대조해야 합니다. 멱등 키는 도구의 문서화된 계약이 실제로 이를 지원할 때만 도움이 됩니다.
normal이면 실패이고, 우선순위가 맞아도 담당자를 바꾸면 실패입니다. 원래 티켓을 올바르게 갱신했더라도 두 번째 티켓을 만들면 실패입니다. 최종 상태와 실행 로그를 함께 확인하세요. 불필요한 쓰기 뒤에 보정 작업이 있었다면 올바른 최종 스냅샷만으로는 이를 놓칠 수 있습니다. 도구 응답이 사라졌을 때는 미검증 갱신을 확인된 결과로 안내하면 안 됩니다.시작 상태, 보낸 이력, 도구 인수, 결과 상태, 최종 응답을 함께 저장합니다. 두 모델 모두 이미 커밋된 쓰기에서 복구하지 못한다면 모델 품질 탓으로 돌리기 전에 앱 복구 장치를 고치세요. 이 재사용 가능한 검수 사례는 지금 Fable 5.1 연동에 적용할 수 있습니다. 검증된 경로가 생기기 전까지 5.5 결과는 미시험으로 남겨 둡니다.
대화 기록 이어쓰기 실패를 진단하세요
새 요청은 통과하지만 대응하는 기존 기록 요청은 실패한다면 모델에 전달된 메시지를 비교하세요. 도구 호출·결과 쌍, 유지된 사용자 결정, 이전 생성 내용을 확인하세요. 원래 기록을 보관하고 변환마다 버전을 붙여야 어떤 변경이 결과에 영향을 줬는지 찾을 수 있습니다.
캐시 항목, 대화 참조, 공급업체 전용 필드를 다른 모델로 옮길 수 있다고 가정하지 마세요. 문서화된 범위를 먼저 확인하세요. 기록 변환이 필요한 워크플로우라면 변환한 기록을 같은 기대 상태로 테스트하고, 제거하거나 요약한 정보를 기록하세요.
새 세션과 이어지는 세션의 합격, 실패, 미테스트 수를 이유와 함께 따로 보고하세요. 새 세션 그룹이 통과했다고 기존 대화의 마이그레이션도 승인되는 것은 아닙니다.
재실행에서 되돌릴 수 있는 배포로 진행하세요
EvoLink는 모델 선택에 공통 게이트웨이를 제공할 수 있지만 모델별 동작은 여전히 검증해야 합니다. 현재 모델, 후보, 대체 경로 구성을 명시하고, 추측한 Fable 5.5 ID를 후보에 넣지 마세요.
재실행 결과를 진행·중단 결정으로 바꾸세요
배포 전에 누가 중단할 수 있고 어떤 상태를 보존해야 하는지 포함한 판단 규칙을 적으세요. 평균 합격률이 높아져도 새로운 치명적 실패가 생긴다면 충분하지 않습니다.
| 가상의 재실행 결과 | 결정 | 다음 조치 |
|---|---|---|
| 후보가 더 많은 작업을 통과하지만 외부 작업을 한 번 중복함 | 운영에 승격하지 않음 | 작업 경계를 수정하거나 격리한 뒤 두 구성을 다시 실행 |
| 새 요청은 통과하고 기존 기록 세션은 실패함 | 기존 대화는 이전하지 않음 | 기록 변환을 진단하고 새 세션 트래픽은 별도 평가 |
| 품질은 통과하지만 미리 정한 지연 한도를 초과함 | 모든 작업의 기본값으로 삼지 않음 | 명확히 분류할 수 있는 느린 작업 큐에서 허용 가능한지 테스트 |
| 한 작업 유형만 예산 안에서 개선됨 | 해당 유형에 한정한 제한 배포 고려 | 그 유형의 분류 오류와 대체 경로 검증 |
| 결과는 통과하지만 유지한 경로가 상태를 재개하지 못함 | 확대 보류 | 실행 가능한 복구 경로를 확보하고 테스트 |
이는 판단 예시이지 관측된 Fable 5.5 결과가 아닙니다. 임의의 성공률을 복사하지 말고 애플리케이션 요구에 따라 수치 한도를 정하세요. 계획한 배포 범위에 충분한 정상·실패 트래픽 유형을 검토하세요. 작은 표본에는 여전히 불확실성이 있습니다.
롤백할 때는 이전 경로와 구성 버전을 명시하고, 후보에 새 작업 배정을 멈추고, 진행 중인 작업을 파악하고, 이미 실행된 부작용을 대조한 뒤 알려진 상태에서만 재개하세요. 발동 원인과 복구 결과를 기록하세요. 설정에만 존재하는 대체 경로는 복구 가능성을 입증한 것이 아닙니다.
어떤 개선이 있어야 업그레이드할 가치가 있나요?
후보에 실질적 이점이 없다면 경로가 계속 사용 가능하고 적합한 동안 Fable 5.1을 유지하는 것도 타당합니다. 한 워크플로우만 개선된다면 모든 기본값을 바꾸는 것보다 그 워크플로우만 이전하는 편이 근거가 있습니다. 어느 쪽도 미검증 출시를 마감일처럼 취급할 필요는 없습니다.
자주 묻는 질문
Fable 5.1 모델 ID를 추측한 Fable 5.5 ID로 바꿔도 되나요?
아닙니다. 정확한 후보 식별자와 지원 요청 규약을 확인해야 합니다. 페이지 슬러그는 사용 가능한 API 모델 ID가 아닙니다.
Fable 5.5는 Fable 5.1과 하위 호환되나요?
확인한 자료에서는 하위 호환성이 확정되지 않았습니다. 사용할 정확한 경로의 요청 필드, 응답, 도구, 상태 유지 동작을 검증하세요.
기존 대화 기록을 재사용할 수 있나요?
테스트용으로 준비할 수 있지만 호환성을 가정하지 마세요. 새 세션과 기록 이어쓰기를 별도로 테스트하고 중요한 상태와 결정이 살아 있는지 확인하세요.
프롬프트 캐시가 후보로 이전되나요?
캐시 이전을 가정하지 마세요. 후보 경로의 적용 범위와 과금 규칙을 확인하고 캐시 관련 비용을 평가에 포함하세요.
모델 전환과 함께 프롬프트도 바꿔야 하나요?
고정된 기준선으로 시작하세요. 후보 전용 조정이 필요하면 별도 구성으로 버전을 관리하고 조정에 쓰지 않은 작업으로 평가하세요.
도구를 쓰는 에이전트의 섀도 테스트는 안전한가요?
의도치 않은 외부 작업 반복이 없고 전송 데이터에도 적절한 경우에만 그렇습니다. 초기 재실행은 기록된 응답이나 샌드박스를 사용하고 중복 요청 비용도 계산하세요.
롤백은 모델 설정을 되돌리면 충분한가요?
항상 그렇지는 않습니다. 대체 경로를 검증하고 진행 중인 작업, 대화 상태, 외부 부작용을 처리해야 합니다. 구성 롤백은 이미 실행된 작업을 취소하지 않습니다.
공식 발표 전에 마이그레이션해야 하나요?
출처와 적용 범위
- Anthropic 모델 개요: 모델 식별 정보와 문서 확인.
- Anthropic 뉴스: 출시 근거 확인.
- EvoLink Fable 5.1: 현재 모델의 기준 자료.
