DEV Community

Cover image for 최적의 프롬프트로 클로드 페이블 5 활용 극대화 방법
Rihpig
Rihpig

Posted on • Originally published at apidog.com

최적의 프롬프트로 클로드 페이블 5 활용 극대화 방법

클로드 페이블 5는 이전 모델보다 더 유능하지만, 그 유능함은 양날의 검입니다. 일상적인 작업에 높은 노력 수준을 사용하면 모델이 불필요하게 컨텍스트를 더 모으고, 오래 숙고하고, 요청하지 않은 코드까지 정리하면서 토큰과 시간을 소비합니다. 프롬프트를 명확히 작성하면 같은 모델도 더 빠르게 작업을 끝내고, 필요한 결과만 반환하며, 실제로 오래 실행해야 하는 어려운 문제에 예산을 남길 수 있습니다.

지금 Apidog를 사용해 보세요

이 글은 Anthropic의 공식 Fable 5 프롬프트 안내를 실무용 플레이북으로 정리합니다. 또한 Apidog에서 프롬프트를 테스트하고, 토큰 수와 지연 시간을 비교해 감이 아닌 숫자로 개선 여부를 확인하는 방법을 다룹니다.

“사용량 확장”이 실제로 의미하는 것

Fable 5 사용량을 확장한다는 것은 제한을 우회하는 것이 아닙니다. 각 요청에서 다음 세 가지를 작업 난이도에 맞게 제어하는 것입니다.

  • 노력(Effort): 지능, 지연 시간, 비용 사이의 핵심 레버입니다. Anthropic은 기본값으로 high, 가장 어려운 작업에는 xhigh, 일반 작업에는 medium 또는 low를 권장합니다.
  • 출력 토큰(Output tokens): 지침이 없으면 Fable 5는 서문, 대안 검토, 장황한 설명을 많이 생성할 수 있습니다. 짧은 간결성 지침만으로도 출력 토큰을 줄일 수 있습니다.
  • 실행 시간(Run length): 어려운 작업에서는 긴 실행이 장점입니다. 반대로 쉬운 작업에서 오래 실행되면 낭비입니다.

Fable 5 usage controls

프롬프트의 목표는 간단합니다.

  1. 쉬운 작업에는 덜 쓰기
  2. 어려운 작업에는 충분히 쓰기
  3. 모든 호출에서 결과를 더 빨리 확인하기

모든 호출에 적용할 프롬프트 패턴

아래 패턴은 시스템 프롬프트에 넣기 좋은 짧은 지침입니다. 한 번에 모두 넣기보다, 작업 유형별로 조합해서 사용하세요.

1. 작업 난이도에 맞게 노력 수준을 조정하세요

모든 요청에 high 또는 xhigh를 쓰지 마세요.

권장 기준은 다음과 같습니다.

작업 유형 권장 노력
포맷 변경, 요약, 간단한 분류 low 또는 medium
일반 코드 수정, API 응답 분석 medium
복잡한 디버깅, 설계 검토 high
장시간 추론이 필요한 어려운 문제 xhigh

작업이 정확히 완료되지만 너무 느리다면 먼저 노력 수준을 낮춰보세요. 비용을 관리하고 있다면 Claude API 비용과 Claude API 속도 제한을 함께 확인하면 대량 호출에서 왜 노력 수준 관리가 중요한지 이해하기 쉽습니다.

2. 충분한 정보가 있으면 바로 행동하게 하세요

Fable 5는 모호한 요청에서 과도하게 계획하거나 대안을 조사할 수 있습니다. 작업형 프롬프트에는 다음 지침을 추가하세요.

행동하기에 충분한 정보가 있을 때, 행동하세요.
대화에서 이미 확립된 사실을 재추론하지 마세요.
사용자가 이미 내린 결정을 다시 논의하지 마세요.
추구하지 않을 옵션을 길게 설명하지 마세요.
선택지가 있다면 포괄적인 조사 대신 권고안을 제시하세요.
이는 사고 블록에는 적용되지 않습니다.
Enter fullscreen mode Exit fullscreen mode

사용 예시는 다음과 같습니다.

저는 기존 Express API의 인증 미들웨어를 정리하고 있습니다.
이미 JWT 방식을 사용하기로 결정했습니다.

행동하기에 충분한 정보가 있을 때, 행동하세요.
대안 인증 방식은 설명하지 말고 현재 코드에서 수정해야 할 부분만 제안하세요.
Enter fullscreen mode Exit fullscreen mode

3. 결과부터 시작하게 하세요

긴 서문은 출력 토큰을 빠르게 늘립니다. 응답의 첫 문장을 결과로 고정하세요.

결과부터 시작하세요.
작업 완료 후 첫 문장은 "무슨 일이 일어났는지" 또는 "무엇을 발견했는지"에 답해야 합니다.
즉, 사용자가 "결론만 말해줘"라고 했을 때 요구할 내용입니다.
뒷받침하는 세부 정보와 추론은 그 뒤에 작성하세요.
가독성과 간결함은 다르며, 가독성이 더 중요합니다.
Enter fullscreen mode Exit fullscreen mode

예를 들어 코드 리뷰 요청에는 이렇게 붙일 수 있습니다.

결과부터 시작하세요.
첫 줄에는 가장 중요한 문제 1개와 수정 방향을 말하세요.
그 다음에 필요한 경우 근거와 패치를 제시하세요.
Enter fullscreen mode Exit fullscreen mode

4. 범위를 제한하세요

높은 노력 수준에서는 모델이 요청 범위를 넘어 리팩토링하거나 추상화를 추가할 수 있습니다. 버그 수정, 작은 패치, 테스트 보강에는 범위 제한이 필수입니다.

작업이 요구하는 것 이상으로 기능을 추가하거나, 리팩토링하거나, 추상화를 도입하지 마세요.
버그 수정에는 주변 정리 작업이 필요하지 않습니다.
발생할 수 없는 시나리오에 대한 오류 처리, 대체(fallback), 또는 유효성 검사를 추가하지 마세요.
시스템 경계, 예를 들어 사용자 입력 또는 외부 API에서만 유효성 검사를 수행하세요.
가장 간단하고 잘 작동하는 것을 수행하세요.
Enter fullscreen mode Exit fullscreen mode

코드 작업에서는 요청을 더 구체화하세요.

목표: 이 테스트 실패만 수정하세요.
제약:
- 공개 API 시그니처를 바꾸지 마세요.
- 관련 없는 파일을 수정하지 마세요.
- 리팩토링하지 마세요.
- 실패 원인과 최소 패치만 제시하세요.
Enter fullscreen mode Exit fullscreen mode

5. 긴 실행에서는 진행 상황을 증거 기반으로 보고하게 하세요

긴 자율 실행에서는 모델이 실제 도구 결과와 상태 보고를 일치시켜야 합니다.

진행 상황을 보고하기 전에, 이 세션의 도구 결과와 각 주장을 감사하세요.
증거를 제시할 수 있는 작업만 보고하세요.
아직 검증되지 않은 것이 있다면 명시적으로 밝히세요.
Enter fullscreen mode Exit fullscreen mode

이 지침은 다음과 같은 작업에 유용합니다.

  • 여러 파일을 수정하는 코드 마이그레이션
  • API 테스트 자동화
  • 긴 로그 분석
  • 여러 단계의 디버깅

6. 요청뿐 아니라 이유도 알려주세요

Fable 5는 작업의 목적을 알 때 더 정확하게 범위를 잡습니다.

저는 [누구를 위한] [더 큰 작업]을 하고 있습니다.
그들은 [출력이 가능하게 하는 것]이 필요합니다.
이를 염두에 두고: [요청].
Enter fullscreen mode Exit fullscreen mode

예시:

저는 백엔드 팀을 위한 결제 API 변경 리뷰를 준비하고 있습니다.
그들은 배포 전에 깨질 수 있는 계약 변경을 빠르게 확인해야 합니다.
이를 염두에 두고: 아래 OpenAPI diff에서 호환성 위험만 찾아주세요.
Enter fullscreen mode Exit fullscreen mode

7. 반복 작업에는 메모리 파일을 사용하세요

반복되는 작업에서는 모델이 이전 실수를 다시 반복하지 않도록 간단한 마크다운 파일을 유지하세요.

예시:

# prompt-memory.md

## 요약
이 프로젝트의 API 테스트는 응답 스키마와 stop_reason을 항상 검증한다.

## 교훈
- 인증 실패 테스트에서는 401 응답 본문도 검증해야 한다.
- Claude 응답은 stop_reason이 end_turn인지 확인한다.
- 프롬프트 비교 시 output_tokens와 latency를 함께 기록한다.
Enter fullscreen mode Exit fullscreen mode

운영 규칙은 단순하게 유지하세요.

  • 항목 하나에 교훈 하나만 작성
  • 중복 항목을 추가하지 말고 기존 항목을 업데이트
  • 파일 상단에 한 줄 요약 유지
  • 반복 실행 시 프롬프트에 이 파일을 참조하도록 지시

Apidog에서 프롬프트를 테스트하고 조정하세요

공식 가이드는 프롬프트 패턴을 제공합니다. 하지만 실제로 효과가 있는지는 측정해야 합니다.

예를 들어 다음 질문에 답할 수 있어야 합니다.

  • 새 프롬프트가 output_tokens를 줄였는가?
  • 노력 수준을 낮춰도 품질이 유지되는가?
  • 지연 시간이 줄었는가?
  • stop_reason: "refusal"이 늘어나지는 않았는가?

Apidog를 사용하면 요청을 저장하고, 환경 변수를 바꾸고, 응답을 검증하고, mock 서버로 반복 비용을 줄일 수 있습니다. 채팅 UI가 아니라 API 요청 단위로 프롬프트를 테스트하는 방식입니다. 이는 Messages 엔드포인트를 대상으로 Postman 없이 API 테스트를 수행하는 것과 같습니다.

Apidog API testing workflow

1. 프롬프트와 설정을 환경 변수로 분리하세요

Apidog에서 Anthropic Messages API 요청을 만들고 변동되는 값을 환경 변수로 빼세요.

예시 변수:

ANTHROPIC_API_KEY
SYSTEM_PROMPT
TASK
MAX_TOKENS
Enter fullscreen mode Exit fullscreen mode

요청 예시:

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": {{MAX_TOKENS}},
  "system": "{{SYSTEM_PROMPT}}",
  "messages": [
    {
      "role": "user",
      "content": "{{TASK}}"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

이렇게 구성하면 요청 본문을 매번 수정하지 않고도 다음을 바꿀 수 있습니다.

  • 시스템 프롬프트
  • 작업 입력
  • 최대 출력 토큰
  • 테스트 환경
  • API 키

2. 프롬프트 변형을 A/B 테스트하세요

같은 작업에 대해 두 요청을 저장하세요.

  • A 버전: 기존 프롬프트
  • B 버전: 간결성, 범위 제한, 결과 우선 지침을 추가한 프롬프트

비교할 값은 다음 세 가지입니다.

항목 확인 위치 판단 기준
출력 토큰 usage.output_tokens 더 적은 토큰으로 같은 결과를 내는가
지연 시간 Apidog 응답 타이밍 더 빨라졌는가
품질 직접 검토 작업 요구사항을 여전히 만족하는가

응답 예시에서 확인할 수 있는 값:

{
  "usage": {
    "input_tokens": 842,
    "output_tokens": 391
  },
  "stop_reason": "end_turn"
}
Enter fullscreen mode Exit fullscreen mode

좋은 프롬프트는 보통 다음 조건을 만족합니다.

  • output_tokens가 감소
  • 결과 품질 유지
  • 불필요한 설명 감소
  • 요청 범위 밖 수정 감소

3. stop_reason에 어설션을 추가하세요

Fable 5는 안전 분류기를 실행하며 stop_reason: "refusal"을 반환할 수 있습니다. 일부 설정에서는 이것이 Opus 4.8 대체(fallback)로 이어질 수 있습니다. 자동 대체는 비용과 동작을 바꿀 수 있으므로 테스트에서 감지해야 합니다.

Apidog에서 다음 조건을 검증하세요.

stop_reason == "end_turn"
Enter fullscreen mode Exit fullscreen mode

프롬프트 테스트에서 이 어설션을 실패 조건으로 두면 거부율 증가를 빠르게 확인할 수 있습니다. 이 검증은 프롬프트의 계약으로 취급하는 것이 좋습니다.

4. 긴 실행에 맞게 시간 제한을 설정하세요

Fable 5는 어려운 작업에서 이전 모델보다 더 오래 실행될 수 있습니다. 높은 노력 수준에서는 요청 하나가 몇 분 걸릴 수 있습니다.

배포 전에 다음을 확인하세요.

  • 클라이언트 타임아웃이 충분한가
  • 스트리밍 응답을 처리할 수 있는가
  • 프록시 또는 게이트웨이에서 먼저 끊기지 않는가
  • 재시도 정책이 중복 비용을 만들지 않는가

시간 초과가 발생한다면 업스트림 요청 시간 초과 수정의 디버깅 흐름을 적용할 수 있습니다.

작업이 정확히 완료되지만 너무 느리다면, 프롬프트를 바꾸기 전에 노력 수준을 낮춰 테스트하세요.

5. mock 서버로 반복 비용을 줄이세요

프롬프트와 클라이언트 로직을 조정할 때 실제 API를 계속 호출하면 비용이 빠르게 늘어납니다. Apidog의 mock 서버를 사용하면 Messages 엔드포인트의 응답 형태를 저장해두고 무료로 반복 테스트할 수 있습니다.

mock으로 먼저 테스트할 항목:

  • 정상 응답 처리
  • stop_reason: "refusal" 처리
  • 오류 응답 처리
  • 시간 초과 처리
  • 응답 스키마 검증
  • UI 또는 파이프라인 후속 처리

실제 API 호출은 다음 단계에서만 수행하세요.

  1. 프롬프트 후보가 정리된 후
  2. 토큰 수를 측정할 때
  3. 지연 시간을 비교할 때
  4. 최종 품질을 검토할 때

자동화 파이프라인에 포함하려면 Apidog CLI 및 Claude 스킬 가이드를 참고하세요.

실무용 시스템 프롬프트 템플릿

아래 템플릿을 기본값으로 두고, 작업 유형에 맞게 줄이거나 확장하세요.

당신은 API와 백엔드 개발 작업을 돕는 기술 어시스턴트입니다.

규칙:
1. 결과부터 시작하세요.
2. 행동하기에 충분한 정보가 있으면 바로 행동하세요.
3. 이미 확립된 사실을 재추론하지 마세요.
4. 요청 범위를 넘는 리팩토링, 기능 추가, 추상화를 하지 마세요.
5. 필요한 경우에만 근거를 설명하세요.
6. 검증되지 않은 내용은 검증되지 않았다고 명시하세요.
7. 진행 상황을 보고할 때는 실제 도구 결과로 뒷받침되는 내용만 보고하세요.

출력 형식:
- 먼저 결론 또는 변경 사항을 요약하세요.
- 그 다음 필요한 세부 사항을 bullet로 작성하세요.
- 코드가 필요하면 최소 패치만 제시하세요.
Enter fullscreen mode Exit fullscreen mode

작업 프롬프트 예시:

저는 결제 API의 회귀 테스트를 준비하고 있습니다.
팀은 배포 전에 깨질 수 있는 응답 계약 변경을 확인해야 합니다.

아래 응답 예시와 기대 스키마를 비교하세요.
결과부터 시작하고, 호환성 위험만 보고하세요.
관련 없는 스타일 의견은 제외하세요.
Enter fullscreen mode Exit fullscreen mode

자주 묻는 질문

더 나은 프롬프트는 Fable 5에서 항상 더 적은 토큰을 의미하나요?

항상은 아닙니다. 하지만 결과 우선, 간결성, 범위 제한 지침은 Fable 5가 생성하는 서문과 불필요한 설명을 줄이는 데 도움이 됩니다. 추측하지 말고 Apidog에서 usage.output_tokens를 비교하세요.

Fable 5 비용을 가장 빠르게 줄이는 방법은 무엇인가요?

일상적인 작업의 노력 수준을 낮추는 것입니다. high와 xhigh는 복잡한 디버깅, 설계 검토, 장시간 추론이 필요한 작업에 남겨두세요. 일반 작업은 medium 또는 low부터 테스트하세요.

Opus에서 작동하던 프롬프트가 Fable 5에서 시간 초과되는 이유는 무엇인가요?

Fable 5는 어려운 작업에서 더 오래 실행될 수 있습니다. 높은 노력 수준에서는 요청당 몇 분이 걸릴 수 있습니다. 클라이언트 시간 초과를 늘리거나, 스트리밍을 처리하거나, 작업이 너무 느리다면 노력 수준을 낮춰보세요.

Fable 5를 요청했는데 왜 Opus 응답을 받나요?

stop_reason: "refusal"이 대체(fallback)를 유발했을 수 있습니다. 모델에게 추론을 재현하도록 요청하거나 안전 분류기에 걸릴 수 있는 프롬프트는 거부율을 높일 수 있습니다. Apidog에서 stop_reason에 어설션을 걸어 감지하세요.

비용 없이 프롬프트 변경을 테스트할 수 있나요?

가능합니다. Apidog에서 Messages 엔드포인트를 mock으로 구성해 클라이언트 처리, 어설션, 오류 처리를 먼저 테스트하세요. 실제 토큰 수와 지연 시간 측정이 필요할 때만 라이브 API를 호출하면 됩니다.

마무리

Fable 5 사용량을 확장하는 핵심은 더 많은 호출을 억지로 밀어 넣는 것이 아니라, 각 호출의 노력, 범위, 출력량을 작업에 맞추는 것입니다.

실무에서는 다음 순서로 적용하세요.

  1. 작업 난이도별 노력 수준을 정한다.
  2. 시스템 프롬프트에 결과 우선, 행동 우선, 범위 제한 지침을 넣는다.
  3. Apidog에서 프롬프트 변형을 저장한다.
  4. 같은 작업으로 A/B 테스트한다.
  5. output_tokens, 지연 시간, 품질, stop_reason을 비교한다.
  6. mock 서버로 반복 테스트 비용을 줄인다.

이 과정을 거치면 “이 프롬프트가 더 간결한 것 같다”는 감각을 실제 토큰 수와 지연 시간으로 검증할 수 있습니다.

Top comments (0)