팀에서 쓰던 모델을 Claude Fable 5.1로 바꿨다. 같은 프롬프트를 보냈고 답의 품질도 괜찮았다. 그런데 긴 작업에서는 몇 분 동안 아무 설명이 없었다. 서로 상관없는 도구도 하나씩 불렀다. 대화 기록을 줄인 뒤에는 이전 사고 블록 때문에 요청이 실패했다.
이럴 때는 프롬프트 문장만 계속 고치기 쉽다. 문제의 일부는 모델에게 전달한 지시가 아니라 모델을 둘러싼 실행 프로그램에 있다. 진행 업데이트를 화면에 보여 주는 방식, 도구 결과를 다시 넣는 순서, 과거 대화를 저장하는 방식이 모두 답에 영향을 준다.
Anthropic의 Claude Fable 5.1 프롬프팅 가이드에 따르면 기존 Fable 5 프롬프트는 대체로 그대로 작동한다. 다만 모델의 행동 차이를 확인하지 않고 이름만 교체하면 비용과 대기 시간, 안정성이 달라질 수 있다. 새 모델 도입은 프롬프트 교체보다 작은 시스템 마이그레이션에 가깝다.
effort 이름보다 실제 결과를 본다
effort는 모델이 답을 만들 때 얼마나 많은 계산을 쓸지 조절하는 값이다. Fable 5.1의 기본값은 high다. 가이드는 여기서 시작한 뒤 low, medium, xhigh, max를 자기 평가 문제로 비교하라고 권한다. 같은 이름도 Fable 5와 Fable 5.1에서 같은 사고량을 뜻하지 않는다.
공식 문서에 따르면 Fable 5.1의 medium은 더 낮은 비용으로 Fable 5와 대략 비슷한 결과를 낸다. 그렇다고 모든 작업을 곧바로 medium으로 낮출 근거는 아니다. 코드 수정, 자료 검색, 긴 보고서처럼 실제로 맡길 일을 표본으로 만들고 품질이 유지되는 구간을 찾아야 한다.
수준마다 행동도 달라진다. low에서는 검색과 검색형 도구를 덜 부를 수 있다. xhigh와 max에서는 긴 결과를 쓰기 전에 더 오래 생각할 수 있다. 정확도 점수만 보면 첫 결과까지 걸린 시간과 전체 비용, 필요한 검색을 했는지를 놓친다. 이 항목도 같은 평가표에 넣어야 한다.
모델 버전이 바뀌면 effort 평가도 처음부터 다시 돌린다. 예전 모델에서 찾은 최적값은 새 모델의 출발점일 뿐이다. 이름이 같다는 이유로 운영 설정까지 그대로 옮기면 비용을 더 쓰거나 필요한 검색을 빼먹을 수 있다.
프롬프트보다 실행 루프에서 시간이 샌다
Fable 5.1은 긴 도구 작업 중 사용자에게 진행 상황을 Fable 5보다 적게 말하는 경향이 있다. effort가 높고 도구 호출이 길수록 이 차이가 커진다. 모델은 일하고 있어도 화면은 멈춘 듯 보이고, 마지막 답이 전체 작업보다 마지막 단계만 설명할 수도 있다.
우선 진행 정보가 실제 화면까지 오는지 확인해야 한다. 짧은 상태 메모는 progress-update thinking 블록으로 돌아온다. 기본 thinking.display: "omitted"에서는 이 블록이 비어 있다. display: "updates"와 thinking-display-updates-2026-08-18 베타 헤더를 쓰면 내용을 상태 줄로 보여 줄 수 있다. "summarized"는 진행 업데이트와 요약된 추론을 함께 반환한다.
프롬프트에 중간 설명을 막는 옛 지침이 남았는지도 살핀다. “모든 결과를 마지막까지 보류하라”는 문장은 진행 상황을 더 말하라는 새 지침과 충돌한다. 도구 출력이 사용자 화면에서 접히는 제품이라면 그 사실도 모델에 알려야 한다. 그래야 명령 출력만 남겨 두고 설명을 생략하지 않는다.
호출 순서도 대기 시간을 바꾼다. 다음 작업이 프롬프트에 직접 적히지 않고 상황에 암시되어 있으면 Fable 5.1이 독립적인 도구를 한 턴에 하나씩 부를 수 있다. 품질은 같아도 호출마다 통신 시간과 토큰이 든다. 다음에 필요한 항목을 먼저 정한 뒤, 다른 결과에 기대지 않는 호출은 한 응답에서 모두 요청하라고 지시하면 왕복을 줄일 수 있다.
대화 이력은 기록장처럼 덧붙인다
에이전트는 여러 번 도구를 부르며 대화를 길게 이어 간다. 각 assistant 응답은 thinking 블록까지 API가 돌려준 모습 그대로 기록해야 한다. 다음 user 턴에는 도구 결과를 붙인다. 이미 지나간 시스템 프롬프트나 메시지를 중간에서 고치면 안 된다. 이를 추가 전용(append-only) 이력이라고 한다.
2026년 8월 31일 이후 만들어진 신규 계정에서는 Fable 5.1의 thinking 블록이 생성 당시의 정확한 대화에 묶인다. 앞쪽 시스템 프롬프트, 도구 목록, 메시지 중 하나를 바꾼 뒤 그 블록을 다시 보내면 HTTP 400이 날 수 있다. thinking.block_binding.prefix_mismatch_behavior: "drop_block"과 thinking-binding-controls-2026-08-01 베타 헤더를 쓰면 영향을 받은 블록을 버리도록 할 수 있다.
과거를 고치면 프롬프트 캐시도 그 지점부터 다시 시작한다. 매 턴 넣는 알림을 예전 메시지 안에 끼워 넣거나 지난 대화를 그 자리에서 요약하는 방식이 대표적이다. 비용을 아끼려던 편집이 오히려 캐시를 깨고 요청까지 실패하게 만든다.
매번 달라지는 알림과 새 지침은 턴 범위 시스템 메시지로 뒤에 붙인다. 오래된 대화를 줄여야 한다면 서버의 compaction이나 context editing이 안전하다. 클라이언트에서 직접 압축할 때는 전체 이력을 하나의 요약과 새 user 턴으로 바꾸고 예전 thinking 블록은 다시 보내지 않는 방식이 단순하다.
완료와 범위를 문장으로 고정한다
Fable 5.1은 긴 작업을 스스로 이어 갈 수 있지만 비동기 작업에서는 다음 계획만 말하고 멈추기도 한다. 이미 요청받은 일을 다시 해도 되는지 묻는 경우도 있다. 사용자가 실시간으로 지켜보지 않는다고 밝히고, 원래 요청에서 이어지는 되돌릴 수 있는 작업은 묻지 말고 수행하라고 적으면 이런 중단을 줄일 수 있다.
멈춰야 할 경계도 함께 둔다. 파괴적인 작업이나 실제 범위 변경에는 사용자 결정이 필요하다. 사용자가 문제를 설명하거나 질문만 했다면 결과물은 평가다. 수정을 요청하지 않았는데 코드까지 바꾸면 안 된다. 자율성은 합의된 일을 끝까지 수행하는 태도이지, 아무 일이나 하는 권한이 아니다.
요청 범위를 결과물의 범위로 정의하는 문장도 유용하다. 주변에서 발견한 버그나 성능 문제는 요청한 기능에 꼭 필요하지 않다면 고치지 않는다. 테스트 역시 저장소 관례와 요청한 동작에 맞는 크기로 제한한다. 작은 수정에서 파일 전체를 다시 쓰는 행동이 보이면 필요한 부분만 고치라고 직접 지시한다.
검색과 글쓰기에도 관찰한 행동에 맞춘 규칙을 둔다. low에서 최신 개발 도구를 기억만으로 답한다면 이름을 그대로 넣어 검색하라고 요청한다. 검색 자료를 원문 표시 없이 길게 옮긴다면 좋은 답과 그 이유가 포함된 완전한 예시를 준다. 문장이 지나치게 꾸며졌다면 공식 문서가 제안한 짧은 지시도 쓸 수 있다.
Please remove all mannered prose.
모델 교체를 운영 점검으로 바꾼다
가이드의 항목을 모두 시스템 프롬프트에 복사할 필요는 없다. 먼저 실제 서비스에서 나타난 문제를 찾는다. 비용이 높으면 effort를 비교하고, 화면이 조용하면 진행 블록의 전달 경로를 확인한다. 도구 호출이 느리면 독립 호출을 묶고, 긴 대화가 실패하면 이력을 수정하는 코드를 찾는다.
작은 평가도 만든다. 평소 요청 몇 개를 정해 모델 버전과 effort만 바꿔 반복한다. 결과 품질뿐 아니라 첫 응답 시간, 전체 호출 수, 검색 여부, 비용, 작업 완료 여부를 함께 기록한다. 한 번의 인상보다 같은 조건에서 모은 결과가 설정을 고르는 기준이 된다.
프롬프트는 그 뒤에 고친다. 관찰된 문제 하나에 짧은 지침 하나를 대응시킨다. 바뀐 결과를 다시 평가하고 효과가 없으면 지침을 뺀다. 규칙을 계속 덧붙이면 서로 충돌해 원인을 찾기 어려워진다.
좋은 프롬프팅은 멋진 문장을 찾는 일이 아니라 모델의 행동을 측정하고 실행 환경을 맞추는 일이다. Fable 5.1로 옮길 때 확인할 대상은 프롬프트만이 아니다. effort 설정, 진행 표시, 도구 루프, 대화 저장 방식까지 한 시스템으로 보고 함께 검증해야 한다.
원문: Prompting Claude Fable 5.1 (Anthropic, 2026) / GeekNews 소개