Claude Opus 5와 Fable 5의 컨텍스트 예산 설계

2026년 7월 Anthropic은 Claude Opus 5와 Claude Fable 5용 Claude Code 시스템 프롬프트에서 80% 이상을 제거했지만, 코딩 평가에서 측정 가능한 성능 저하는 관찰하지 못했다고 밝혔다. 메모리 기능을 끈 기준으로 약 2,686단어였던 프롬프트는 약 514단어까지 줄었다. 신뢰성을 위해 덧붙여 온 지시 가운데 상당수가 판단을 돕기보다 방해했을 가능성을 보여주는 변화다.

이제 컨텍스트 설계의 출발점은 문장 다듬기가 아니라 모델 세대 선택과 예산 배분에 가까워지고 있다.

긴 규칙 대신 모델이 판단할 수 있는 여지를 남긴다

프롬프트가 5분의 1 수준으로 줄어도 성능이 유지된다는 결과는 두 방향으로 읽을 수 있다. 삭제된 문장이 원래 성능에 기여하지 않았을 수 있고, 모델이 지시와 정보를 통합하는 방식이 달라져 외부 안내 자체가 덜 필요해졌을 수도 있다. Anthropic이 공개한 전환은 후자에 무게를 둔다.

금지 규칙은 맥락을 해석할 수 있는 지시로 바뀌었다. 여러 문단짜리 docstring을 쓰지 말라는 조항 대신, 주변 코드와 자연스럽게 읽히도록 주석 밀도·이름·관용구를 맞추라는 식이다. 툴 사용 예시를 길게 나열하는 대신 pending, in_progress, completed 같은 상태값을 인터페이스에 정의해 의도를 드러내는 방식도 같은 흐름이다. Thariq Shihipar는 예시를 제거한 일이 오히려 도움이 됐으며, 모델이 제공된 예시보다 더 창의적이었다고 설명했다.

컨텍스트를 한꺼번에 밀어 넣는 방식도 줄어든다. 검증 절차, 코드 리뷰 안내, 엣지 케이스 처리를 시스템 프롬프트 앞부분에 고정하기보다 스킬과 지연 로딩 툴(ToolSearch)로 필요한 순간에 가져온다. 중복된 문장은 툴 설명으로 흡수하고, 수동 메모리는 자동 메모리로 넘긴다. 평문 마크다운 계획서보다 HTML 파일, 테스트 스위트, 코드베이스, 루브릭처럼 실제 작업물이 더 좋은 참조가 될 수 있다는 판단도 여기에 속한다.

컨텍스트 윈도우보다 실제로 쓰이는 구간을 본다

컨텍스트 윈도우의 크기만으로 모델을 비교하기는 어려워졌다. Claude Opus 5는 100만 토큰 컨텍스트를 기본값이자 최댓값으로 제공하며 작은 컨텍스트 변형을 두지 않는다. Claude Fable 5도 100만 토큰 윈도우를 제공한다.

차이는 창의 명목 크기가 아니라 그 안의 정보를 끝까지 활용하는지에 있다. Opus 5는 Needle in a Haystack 벤치마크에서 100%를 기록해 100만 토큰 문서 어느 위치에 있는 사실도 열화 없이 검색한다고 보고된다. 같은 1M 컨텍스트라도 중간 지시가 사실상 무시되는 모델과는 실효 용량이 다르다.

조직의 평가 지표도 다음처럼 바뀐다.

유효 컨텍스트 비율: 전체 창 대비 지시 준수가 유지되는 구간의 비율
지시당 토큰: 동일한 동작을 이끌어 내는 시스템 프롬프트 토큰 수. Claude Code 사례에서는 80% 줄었다.
과제당 총 토큰: 사고 토큰을 포함한 end-to-end 소비량
유효 비용: 캐시 적중률을 반영한 실질 단가

과거 모델에서는 중복 규칙과 예시가 누락을 막는 보험 역할을 했다. Claude 5 세대에서는 그 보험료가 토큰 비용과 지연 시간을 늘리고, 모델이 더 나은 선택을 할 수 있는 영역까지 제한하는 순손실이 될 수 있다. Anthropic 문서도 Opus 5가 별도 지시 없이 결과물을 검증할 수 있으므로, 이전 모델에서 사용하던 마지막 검증 단계나 서브에이전트 검증 지시가 과잉 검증을 유발할 수 있다고 안내한다.

⤢✕

줄어든 프롬프트 공간을 어디에 쓸 것인가

시스템 프롬프트에서 확보한 공간은 빈자리로 남지 않는다. 더 많은 사용자 입력, 더 많은 툴 정의, 더 많은 사고 토큰 중 어디에 배분할지를 정해야 한다.

사용자 입력에 배정하면 RAG 청크를 잘게 쪼개는 대신 원문 파일 전체를 넣는 선택이 가능해진다. 툴에 배정하면 Opus 5의 대화 중 툴 변경(mid-conversation tool changes, 베타) 기능을 활용할 수 있다. 세션마다 고정된 툴 목록을 재전송하지 않고도 턴 사이에서 툴을 추가하거나 제거하면서 프롬프트 캐시를 유지할 수 있다. 큰 툴 카탈로그를 다루는 에이전트에서는 이 차이가 크다.

사고 토큰은 effort 다이얼로 조절한다. Opus 5는 low, medium, high, xhigh, max의 5단계를 제공하며 기본값은 high다. 사고는 기본 활성 상태이며, thinking: {"type": "disabled"}는 effort가 high 이하일 때만 허용된다. xhigh 또는 max에서 사고를 끄면 400 오류가 반환된다.

사고 토큰은 출력 토큰으로 과금되고 max_tokens에도 포함된다. Opus 4.8에서 사고 없이 실행하던 워크로드라면 Opus 5 전환 시 비용 기준선을 새로 세워야 한다.

모델 선택은 표면 단가만으로 결정되지 않는다

Fable 5는 SWE-bench Verified 95%, SWE-bench Pro 80%를 기록하며 Anthropic이 공개한 최고 점수대를 차지한다. 가격은 100만 토큰 입력당 10달러, 출력당 50달러로 Opus 5의 두 배다. Opus 5는 입력 5달러, 출력 25달러이며 Opus 4.8과 같은 단가를 유지하면서 Fable 5의 절반 비용에 프런티어급 지능을 제공하는 위치를 취한다.

후속 버전인 Fable 5.1은 캐시 읽기 비용을 100만 토큰당 0.25달러로 낮췄다. Fable 5 대비 75% 절감이며, 일반 워크로드에서는 약 25%, 고도로 에이전트적인 워크로드에서는 최대 약 45% 비용 감소가 발생한다고 발표됐다. 캐시 재사용이 지배적인 에이전트 루프에서는 표면 단가보다 캐시 읽기 단가가 총비용에 더 큰 영향을 줄 수 있다.

전환이 필요한 상태도 프롬프트 품질만으로 판단하지 않는다. 다음 신호 가운데 둘 이상이 나타나면 프롬프트 개선보다 모델 교체가 더 효과적일 수 있다.

시스템 프롬프트가 유지보수 부담이 되어 각 문장의 존재 이유를 설명하기 어려운 경우
컨텍스트 중반부의 지시 누락으로 생기는 결함이 반복되는 경우
캐시 적중률이 높은데도 비용이 예산을 초과하는 경우

비용과 버전은 하나의 구성 단위로 관리한다

비용은 다음 항으로 나눠 계산한다.

입력 단가 × 입력 토큰 + 출력 단가 × (응답 토큰 + 사고 토큰) + 캐시 읽기 단가 × 캐시 히트 토큰

사고 토큰 항을 제외하면 Opus 5 전환 뒤 예산 산정이 어긋난다. 캐시 관점에서는 Opus 5의 최소 캐시 가능 프롬프트 길이가 1,024토큰에서 512토큰으로 내려갔다. 이전에는 짧아서 캐시되지 않던 프롬프트도 코드 변경 없이 캐시 대상이 될 수 있다. 프롬프트를 축소하면 캐시가 깨질 수 있다는 우려를 상당 부분 줄이는 변화다.

모델 ID, 프롬프트 리비전, effort 설정, 베타 헤더는 함께 태깅하는 편이 안전하다. mid-conversation-tool-changes-2026-07-01, server-side-fallback-2026-07-01처럼 날짜가 포함된 베타 헤더는 자체로 버전 좌표가 된다.

롤백 역시 모델 ID만 이전 값으로 되돌리는 작업이 아니다. 프롬프트를 80% 줄인 상태에서 이전 세대 모델로 되돌리면 삭제된 규칙 없이 실행될 수 있다. 모델과 프롬프트는 짝으로 관리해야 한다.

평가셋, 배포, 거버넌스를 같이 바꾼다

공개 벤치마크는 모델 순위를 참고하는 자료일 뿐, 조직 도메인에서의 유효 컨텍스트 비율을 알려주지는 않는다. Fable 계열은 민감한 사이버보안·생물학 질의를 능력이 낮은 모델로 라우팅하는 안전장치를 포함하므로, 해당 도메인의 벤치마크 결과가 실제 능력과 어긋날 수 있다.

자체 평가셋에는 최소한 장문 컨텍스트 검색, 다단계 툴 호출, 지시 준수, 회귀 방지의 네 범주가 필요하다. 비용 분석도 단가표에서 시작하지 않는다. 캐시 비중이 높은 에이전트 루프와 일회성 장문 요약은 같은 모델을 사용해도 실질 단가가 크게 다르다. 워크로드별 입력·출력·사고·캐시 토큰 비율을 실측한 뒤 모델을 대입해야 비교가 가능하다.

성능 목표는 정확도 향상처럼 추상적으로 두기보다, 동일 과제 성공률을 유지하면서 과제당 총 토큰 30% 감축처럼 교환 조건을 명확히 적는 편이 낫다.

프롬프트 감축은 한 번에 하지 않는다. 검증 지시, 스타일 규칙, 예시, 반복 문장처럼 삭제 후보를 범주로 묶고 범주 단위로 제거하며 평가한다. 성능이 흔들릴 때 원인이 된 범주를 분리하기 위해서다.

배포는 카나리에서 시작해 트래픽 비중을 단계적으로 높인다. Opus 5의 응답 길이 증가나 서브에이전트 위임 빈도 증가가 다운스트림 시스템을 깨뜨리지 않는지 먼저 확인해야 한다. 응답이 thinking 블록으로 시작할 수 있으므로, content[0].text처럼 첫 블록을 텍스트라고 가정한 구현은 타입 기반 선택으로 바꿔야 한다.

품질과 비용은 같은 대시보드에서 봐야 한다. 과제당 총 토큰, 사고 토큰 비율, 캐시 적중률, 평가셋 통과율, 툴 호출 실패율을 모델 버전별로 분리해 관찰한다. 프롬프트 토큰은 줄었지만 사고 토큰이 늘어 총비용이 상승하는 경우가 실제로 발생하므로, 지표 하나만으로 전환을 판단할 수 없다.

거버넌스에는 다음 원칙을 명시할 수 있다.

시스템 프롬프트에 규칙을 추가하려면, 해당 규칙이 없을 때 실패하는 평가 케이스를 함께 제출한다.
모델 버전 상향은 평가셋 통과와 비용 기준선 재수립 뒤에만 승인한다.
삭제한 지시문은 폐기하지 않고 이력으로 보관해 롤백 때 복원할 수 있게 한다.

전면 전환과 점진 전환의 선택

관점	신 모델 채택	기존 모델 유지
초기 투자	평가셋 재구축·프롬프트 재작성·코드 수정 필요	없음
기술 부채	프롬프트 축소로 유지보수 표면 감소	누적된 지시문이 계속 불어남
성능 향상	장문 컨텍스트·에이전틱 과제에서 뚜렷	정체
안정성	사고 기본 활성 등 파괴적 변경 흡수 필요	검증된 동작 유지
비용	사고 토큰 증가 vs 프롬프트 토큰 감소의 상쇄	예측 가능

기존 모델을 유지하는 결정은 단기적으로 안정적일 수 있다. 하지만 이유를 알 수 없는 문장이 수백 줄 쌓이는 구조라면, 그 프롬프트는 결국 장애 원인이 된다. 안정성도 시간이 흐르며 약해진다.

전체 마이그레이션은 이중 운영 비용이 없고 전환 기간이 짧다. 프롬프트를 두 벌 관리할 필요가 없으며 평가 파이프라인도 하나로 운영할 수 있다. 반면 사고 기본 활성, effort와 사고 비활성화의 제약, 응답 길이 증가 같은 파괴적 변경이 한꺼번에 드러나 원인 분리가 어려워진다.

점진 전환은 워크로드 프로파일별로 옮긴다. 캐시 비중이 높고 위험이 낮은 배치 작업부터 시작하고, 실시간 사용자 대면 경로는 마지막에 전환한다. 다만 두 세대의 프롬프트를 병행 관리해야 하며, 임시 분기가 영구화될 위험이 있다. 점진 전환을 선택한다면 종료 기한도 함께 정하는 편이 안전하다.

시스템 프롬프트의 역할은 실행 환경으로 이동한다

이 흐름은 모델 선택을 단순 벤더 제품 선정이 아니라 아키텍처의 기본 파라미터로 만든다. 비기능 요구사항에서도 컨텍스트 윈도우 크기라는 스펙보다 유효 컨텍스트 비율이라는 실측 지표를 다뤄야 한다.

SLI와 SLO도 응답 시간·정확도만으로는 부족하다. 과제당 총 토큰과 사고 토큰 비율처럼 자원 소비를 나타내는 값이 품질 지표와 같은 수준에서 관리돼야 한다. 사고 토큰이 출력 토큰으로 과금되는 구조는 성능과 비용을 별개로 다루던 방식에 변화를 요구한다.

TCO 산정은 캐시 계층까지 내려가야 한다. Fable 5.1의 캐시 읽기 75% 인하가 고에이전트 워크로드에서 최대 약 45% 총비용 감소로 이어진다는 발표는 표면 단가만 비교해서는 다른 결론에 도달할 수 있음을 보여준다.

긴 지시문의 소유권은 시스템 프롬프트에서 인터페이스와 산출물로 옮겨가고 있다. 툴 스키마, 열거형 상태값, 테스트 스위트, 루브릭이 행동 지시의 역할을 맡는다. 시스템 프롬프트는 정체성과 제약을 선언하는 짧은 문서에 가까워지고, 실제 행동 규정은 실행 환경의 설계로 이동한다.

지연 로딩 툴과 스킬은 필요한 순간에만 컨텍스트에 들어온다. 컨텍스트 예산은 정적으로 나눠 두는 자원이 아니라 작업 중 재배치하는 자원이 된다. 그때 중요한 질문은 컨텍스트 윈도우가 몇 토큰인지보다 필요한 정보를 얼마나 빠르게 가져올 수 있는지가 된다.