Claude Fable 5 프롬프팅 실무 가이드

1-1열거 대신 짧은 원칙 하나로 지시

지시 따르기 능력이 향상되어, 원하는 동작을 이름별로 나열하는 대신 짧은 원칙 하나로 대부분의 행동을 조종할 수 있습니다. 무지시 상태의 Fable 5는 높은 effort에서 필요 이상으로 부연할 수 있는데 (선택하지 않을 옵션 나열, 장황한 근본 원인 설명, 과도하게 구조화된 PR 설명 등), 아래 한 단락이 금지 패턴 목록 전체만큼 효과적입니다.

결과부터 말하라. 작업을 마친 뒤 첫 문장은 "무슨 일이 있었는지" 또는 "무엇을 발견했는지"에 답해야 한다. 사용자가 "요점만 알려줘"라고 했을 때 듣고 싶어 할 바로 그 내용이다. 뒷받침하는 세부 사항과 근거는 그다음에 온다. 읽기 쉬운 것과 짧은 것은 다른 문제이며, 읽기 쉬움이 더 중요하다.

출력을 짧게 만드는 방법은 담을 내용을 선별하는 것이다(독자의 다음 행동을 바꾸지 않는 세부는 뺀다). 문장을 조각내거나, 축약어를 쓰거나, "A → B → 실패" 같은 화살표 연쇄나 전문용어로 압축하는 것이 아니다.

장시간 워크플로우의 체크포인트(멈춤) 행동도 케이스 열거 없이 원칙 하나로 조종합니다.

작업이 진짜로 사용자를 필요로 할 때만 멈춰라: 파괴적이거나 되돌릴 수 없는 행동, 실제 범위 변경, 사용자만 줄 수 있는 입력. 이 중 하나에 부딪히면 질문하고 턴을 끝내라. 약속만 남기고 끝내지 마라.

1-2effort를 핵심 조절 손잡이로

effortFable 5의 사고 강도 설정값 (low / medium / high / xhigh). 높일수록 더 깊이 생각하지만 느려지고 비용이 늘어납니다.는 지능, 지연, 비용의 트레이드오프를 조절하는 주 컨트롤입니다.

• 대부분 작업: high 기본
• 역량이 가장 중요한 작업: xhigh
• 일상 작업: medium / low

낮은 effort도 이전 모델의 xhigh를 넘는 경우가 많습니다. 작업이 필요 이상으로 오래 걸리거나 더 인터랙티브하게 일하고 싶으면 effort를 낮춥니다. 높은 effort는 뛰어난 검증 행동과 가장 엄밀한 산출물을 주는 대신, 루틴 작업에서 과도한 맥락 수집과 숙고가 생길 수 있습니다.

1-3경계를 명시: 과잉 작업과 비요청 행동 방지

높은 effort에서 요청하지 않은 정리, 리팩터링, 추상화, 불필요한 방어 코드를 스스로 추가할 수 있습니다. 경계를 명시합니다.

작업에 필요한 것 이상으로 기능을 추가하거나, 리팩터링하거나, 추상화를 도입하지 마라. 버그 수정에 주변 정리가 따라붙을 필요는 없고, 일회성 작업에는 대개 헬퍼가 필요 없다. 가상의 미래 요구사항을 위해 설계하지 마라: 잘 동작하는 가장 단순한 방법을 택하라. 성급한 추상화와 어중간한 구현을 피하라. 일어날 수 없는 시나리오를 위한 에러 처리, 폴백, 검증을 넣지 마라. 내부 코드와 프레임워크의 보장을 신뢰하라. 검증은 시스템 경계(사용자 입력, 외부 API)에서만 하라. 코드를 그냥 고치면 되는 상황에서 기능 플래그나 하위호환 장치를 쓰지 마라.

비요청 행동 (요청 없는 이메일 초안, 방어용 git 브랜치 백업 등)에는 해야 할 것과 하지 말아야 할 것의 경계를 정의합니다.

사용자가 변경을 요청하는 것이 아니라 문제를 설명하거나, 질문하거나, 생각을 정리하는 중이라면, 결과물은 너의 평가다. 발견한 것을 보고하고 멈춰라. 요청받기 전에는 고치지 마라. 시스템 상태를 바꾸는 명령(재시작, 삭제, 설정 변경)을 실행하기 전에는 증거가 정말 그 행동을 뒷받침하는지 확인하라. 알려진 장애와 비슷해 보이는 신호라도 원인은 다를 수 있다.

1-4과잉 계획(overplanning) 방지

모호한 작업에서 계획만 반복하지 않도록 아래 지시를 둡니다. 마지막 문장이 중요합니다: thinking 블록모델이 답을 내기 전에 수행하는 내부 사고의 기록. Fable 5에서는 요약본만 제공됩니다.에는 적용하지 않아 내부 추론은 자유롭게 유지합니다.

행동할 정보가 충분하면 행동하라. 대화에서 이미 확인된 사실을 다시 도출하지 말고, 사용자가 이미 내린 결정을 다시 따지지 말고, 선택하지 않을 옵션을 사용자 대면 메시지에서 나열하지 마라. 선택지를 저울질하는 중이라면 전수 조사가 아니라 추천안을 제시하라. 이 지시는 thinking 블록에는 적용되지 않는다.

1-5진행 보고를 증거에 근거시키기

긴 자율 실행에서 진행 상황을 실제 도구 결과에 대조해 감사하도록 지시합니다. Anthropic 테스트에서 이 지시는 허위 진행 보고를 유도하도록 설계된 태스크에서조차 허위 보고를 거의 없앴습니다.

진행 상황을 보고하기 전에, 각 주장을 이번 세션의 도구 실행 결과와 대조해 점검하라. 증거를 가리킬 수 있는 작업만 보고하고, 아직 검증되지 않은 것은 그렇다고 명시하라. 결과를 있는 그대로 보고하라: 테스트가 실패하면 출력과 함께 실패했다고 말하고, 건너뛴 단계가 있으면 그렇다고 말하고, 완료되고 검증된 것은 얼버무리지 말고 명확하게 말하라.

1-6추론을 응답 텍스트로 재현시키지 말 것

내부 추론을 응답 텍스트로 옮기거나 설명하게 하는 지시 ("show your thinking", "네 사고 과정을 설명해줘" 류)는 reasoning_extraction refusal모델이 안전상 이유로 요청 처리를 거절하는 응답. API에서는 stop_reason: "refusal"로 표시됩니다. 범주를 촉발해 Opus 4.8로의 폴백fallback. 주 모델이 처리를 거부하거나 실패할 때 자동으로 다른 모델로 넘겨 처리하는 예비 경로.을 늘릴 수 있습니다.

• 마이그레이션 시 기존 스킬과 시스템 프롬프트에서 reflection / show-your-thinking 류 지시를 감사해서 제거
• 추론 가시성이 필요하면 adaptive thinking의 구조화된 thinking 블록을 읽을 것
• 긴 실행 중 진행 노출이 필요하면 send-to-user 도구 사용 (Part 2-7)

1-7요청만 주지 말고 이유(의도)를 함께

Fable 5는 요청 뒤의 의도를 이해할 때 더 잘 수행합니다. 스스로 의도를 추측하는 대신 관련 정보에 연결하게 됩니다. 여러 워크스트림을 다루는 장시간 에이전트에 특히 유효합니다.

저는 [누구]를 위한 [더 큰 작업]을 진행하고 있습니다. 그들에게는 [산출물이 가능하게 하는 것]이 필요합니다. 이 맥락에서: [요청].

1-8최종 요약은 재정향(re-grounding)으로

도구 호출이 많은 긴 에이전트 대화에서 화살표 축약, 과도한 구현 세부, 사용자가 못 본 사고에 대한 참조가 나올 수 있습니다. 최종 요약은 작업 스레드의 연속이 아니라, 그 내용을 처음 보는 독자를 위한 재정향으로 쓰게 합니다.

도구 호출 사이의 간결한 축약은 괜찮다(그건 네가 소리 내어 생각하는 것이고, 거기서는 짧은 게 좋다). 최종 요약은 다르다: 그 과정을 하나도 보지 못한 독자를 위한 글이다.

사용자가 지켜보지 않는 동안 오래 일했다면(밤새, 수많은 도구 호출에 걸쳐, 마지막 대화 이후), 최종 메시지는 사용자가 그 전부를 처음 접하는 순간이다. 작업 흐름의 연속이 아니라 처음 보는 독자를 위한 재정리로 써라: 결과부터, 그다음 사용자에게 필요한 한두 가지를 각각 새로 설명하라. 일하면서 쌓아 온 어휘는 네 것이지 독자의 것이 아니다. 다시 소개하지 않을 거라면 버려라.

마지막 요약을 쓸 때는 작업용 축약을 버려라. 완전한 문장으로 써라. 용어를 풀어 써라. 화살표 연쇄, 하이픈으로 이어붙인 조어, 네가 만들어 낸 라벨을 쓰지 마라. 파일, 커밋, 플래그 같은 식별자를 언급할 때는 각각 평이한 설명을 붙여라. 결과로 시작하라: 무슨 일이 있었는지 한 문장. 그다음 세부. 짧은 것과 명확한 것 중 골라야 한다면 명확한 것을 골라라.

1-9기존 프롬프트와 스킬은 걷어내며 리팩터링

이전 모델용 스킬과 지시는 Fable 5에게 너무 규범적(prescriptive)이어서 출력 품질을 오히려 떨어뜨릴 수 있습니다. 기본 성능이 더 나으면 오래된 지시의 제거를 검토합니다. 역량 향상은 어떤 지시, 도구, 가드레일이 아직 정말 필요한지 재평가할 좋은 계기입니다. Fable 5는 작업 중 배운 것을 바탕으로 스킬을 즉석에서 업데이트하는 것도 잘합니다.

Part 1 체크리스트

• 1
  "하지 마라" 목록을 길게 나열하는 대신, 원하는 방향을 짧은 원칙 한두 문장으로 말했는가

  예시 보기
• 2
  effort는 high를 기본으로 쓰고, 일상 작업은 낮추고 가장 중요한 작업만 xhigh로 올렸는가

  예시 보기
• 3
  시키지 않은 코드 정리, 리팩터링, 부가 기능을 하지 않도록 "해도 되는 일과 안 되는 일"의 경계를 적어 줬는가

  예시 보기
• 4
  진행 상황을 보고할 때 실제 실행 결과(도구 출력)를 근거로만 말하게 했는가

  예시 보기
• 5
  "생각 과정을 보여줘" 같은 옛날 지시를 프롬프트와 스킬에서 찾아 지웠는가 (Fable 5에서는 거부 응답을 유발할 수 있음)

  예시 보기
• 6
  요청만 던지지 않고 "누구를 위한 일이고 결과물이 무엇을 가능하게 하는지"를 한 줄이라도 함께 줬는가

  예시 보기
• 7
  긴 작업의 마지막 보고는 과정을 지켜보지 않은 사람도 바로 이해할 수 있게, "처음 보는 독자" 기준으로 쓰라고 지시했는가

  예시 보기
• 8
  예전 모델 시절 만든 세세한 지시와 스킬이 아직도 필요한지 다시 살펴봤는가 (과한 지시는 오히려 품질을 떨어뜨림)

  예시 보기

2-1긴 턴을 전제로 인프라 조정

높은 effort에서 단일 요청이 수 분, 자율 실행은 수 시간까지 갈 수 있습니다. 팀들이 마주치는 가장 큰 변화 중 하나입니다.

• 클라이언트 타임아웃, 스트리밍, 사용자 대면 진행 표시기를 마이그레이션 전에 조정
• 실행을 블로킹으로 기다리지 말고 비동기로 확인하도록 하네스 재구성 (예: 스케줄 잡)
• 모호한 태스크의 과잉 계획 방지 지시 병행 (Part 1-4)

2-2안전 분류기와 refusal/fallback 운영

Fable 5는 다음을 겨냥한 안전 분류기를 실행합니다.

• 공격적 사이버보안 기법 (익스플로잇, 멀웨어, 공격 도구 제작)
• 생물학/생명과학 콘텐츠 (실험 방법, 분자 메커니즘)
• 모델의 summarized thinking 추출

2-3API 파라미터 변경 확인

모델 소개 문서에 상세가 있으며, 마이그레이션 시 확인할 항목:

• adaptive thinking모델이 문제 난이도에 따라 내부 사고(thinking)의 양을 스스로 조절하는 방식. 전용 (extended thinking budget 없음)
• thinking 출력은 summarized-only
• refusal stop reason과 fallback 처리

2-4메모리 시스템 구축

Fable 5는 이전 실행의 교훈을 기록하고 참조할 수 있을 때 특히 잘합니다. Markdown 파일 하나 수준의 단순한 노트 공간이면 충분합니다.

파일 하나에 교훈 하나를 저장하고, 맨 위에 한 줄 요약을 붙여라. 지적받아 고친 것과 확인된 접근법을 똑같이 기록하되, 왜 중요했는지도 포함하라. 레포나 대화 기록이 이미 담고 있는 것은 저장하지 마라. 중복 노트를 만들지 말고 기존 노트를 갱신하고, 틀린 것으로 판명된 노트는 삭제하라.

기존 히스토리에서 부트스트랩하려면:

우리가 함께한 이전 세션들을 돌아보라. 서브에이전트를 활용해 핵심 주제와 교훈을 추려서 [X]에 저장하라. 앞으로 [X]를 참조해야 한다는 것을 잊지 마라.

2-5병렬 서브에이전트를 전제로 설계

Fable 5는 이전 모델보다 병렬 서브에이전트subagent. 메인 에이전트가 일부 작업을 떼어 맡기는 보조 AI 인스턴스. 독립된 맥락에서 병렬로 일합니다.를 더 적극적으로, 더 신뢰성 있게 파견하고 관리합니다.

• 서브에이전트를 자주 쓰게 하고, 위임이 적절한 시점에 대한 명시적 가이드를 제공
• 오케스트레이터orchestrator. 여러 서브에이전트에게 일을 나눠주고 결과를 취합하는 지휘 역할의 메인 에이전트.와 서브에이전트 간에는 블로킹보다 비동기 통신 선호
• 컨텍스트를 유지하는 long-lived 서브에이전트는 캐시 읽기로 시간과 비용을 아끼고, 가장 느린 서브에이전트에 병목 걸리는 것도 피함

독립적인 하위 작업은 서브에이전트에게 위임하고, 그들이 도는 동안 네 일을 계속하라. 서브에이전트가 궤도를 벗어나거나 필요한 맥락을 놓치고 있으면 개입하라.

2-6명시적 자기 검증: fresh-context 검증 서브에이전트

자기 비판(self-critique)보다 신선한 컨텍스트를 가진 별도 검증 서브에이전트가 더 낫습니다. 장시간 작업에는 다음과 같이 지시합니다.

작업을 진행하면서 [X] 간격으로 스스로의 결과물을 점검하는 방법을 마련하라. 매 [X 간격]마다 이를 실행해, 서브에이전트로 명세와 대조하며 작업을 검증하라.

2-7send-to-user 도구 만들기

길고 비동기적인 에이전트에는, 턴을 끝내지 않고 사용자가 반드시 그대로 봐야 할 메시지를 전달하는 클라이언트 도구를 만듭니다. 대상: 부분 산출물 (생성된 코드 스니펫, 초안 메시지), 구체 수치가 있는 진행 업데이트, 실행 중 들어온 질문에 대한 직접 답변. 도구 입력은 요약되지 않으므로 내용이 온전히 도달합니다.

{
  "name": "send_to_user",
  "description": "사용자에게 메시지를 직접 표시한다. 진행 상황 업데이트, 부분 결과물, 또는 작업이 끝나기 전에 사용자가 원문 그대로 봐야 하는 콘텐츠에 사용하라.",
  "input_schema": {
    "type": "object",
    "properties": {
      "message": {
        "type": "string",
        "description": "사용자에게 표시할 내용."
      }
    },
    "required": ["message"]
  }
}

• 도구 정의만으로는 부족: 시스템 프롬프트에 호출을 유도하는 문구가 없으면 거의 호출하지 않음
• 내레이션이나 내부 추론을 이 도구로 흘리면 목적이 무너짐 (사용자 대면 콘텐츠 전용)
• 루틴 진행만 서술하는 에이전트라면 모델 자체 요약으로 충분 (도구 불필요)

도구 호출 사이에, 사용자가 원문 그대로 읽어야 하는 콘텐츠(부분 산출물, 질문에 대한 직접 답변)가 생기면 send_to_user 도구를 그 내용과 함께 호출하라. send_to_user는 사용자 대면 콘텐츠 전용이다. 내레이션이나 추론에 쓰지 마라.

2-8엣지 케이스 대응: 조기 종료와 컨텍스트 걱정

긴 세션 후반부에 드물게 나타나는 패턴과 대응:

자율 파이프라인용 시스템 리마인더:

너는 자율적으로 작동하고 있다. 사용자는 실시간으로 지켜보고 있지 않고 작업 중간에 질문에 답할 수 없으므로, "할까요?", "진행할까요?"라고 묻는 것은 작업을 멈춰 세운다. 원래 요청에서 따라 나오는 되돌릴 수 있는 행동은 묻지 말고 진행하라. 작업이 끝난 뒤 후속 작업을 제안하는 것은 좋다. 이미 사용자와 논의한 일을 시작하기 전에 다시 허락을 구하는 것은 아니다. 턴을 끝내기 전에 마지막 문단을 점검하라. 그것이 계획, 분석, 질문, 다음 단계 목록, 또는 하지 않은 일에 대한 약속("이제 ~하겠습니다", "~하면 알려주세요")이라면, 지금 도구 호출로 그 일을 하라. 작업이 완료됐거나 사용자만 줄 수 있는 입력에 막혔을 때만 턴을 끝내라.

컨텍스트 안심 문구:

컨텍스트는 충분히 남아 있다. 컨텍스트 한계를 이유로 멈추거나, 요약하거나, 새 세션을 제안하지 마라. 작업을 계속하라.

2-9난이도 범위의 상단에서 시작

이전 모델에게 맡길 것보다 어려운 태스크를 골라, Fable 5가 스스로 스코프를 잡고, 명확화 질문을 하고, 실행하게 합니다. 쉬운 작업으로만 평가하면 역량 범위를 과소평가하게 됩니다.

Part 2 체크리스트

• 1
  요청 하나가 몇 분씩 걸려도 끊기지 않도록 타임아웃, 스트리밍, 진행 표시를 손봤는가

  예시 보기
• 2
  모델이 요청을 거부(refusal)하면 자동으로 Opus 4.8로 넘겨 처리하는 예비 경로를 만들었는가

  예시 보기
• 3
  달라진 API 옵션(adaptive thinking 전용, thinking은 요약본만 제공, thinking budget 없음)을 코드에 반영했는가

  예시 보기
• 4
  모델이 일하며 배운 교훈을 적어 둘 노트 공간(마크다운 파일이면 충분)과 기록 규칙을 마련해 줬는가

  예시 보기
• 5
  일을 나눠 맡길 서브에이전트의 사용 기준을 정하고, 끝날 때까지 멈춰서 기다리지 않는 구조로 만들었는가

  예시 보기
• 6
  작업 결과를 본인 스스로가 아니라, 맥락이 깨끗한 별도 검증 에이전트가 주기적으로 검사하게 했는가

  예시 보기
• 7
  긴 작업 중에도 사용자에게 중간 결과를 원문 그대로 전달할 통로(send_to_user 도구)를 만들고, "이럴 때 써라"는 지시문도 함께 넣었는가

  예시 보기
• 8
  남은 토큰 수를 모델에게 보여주지 않는가? 보여줘야 한다면 "컨텍스트는 충분하니 계속하라"는 안심 문구를 넣었는가

  예시 보기
• 9
  사람이 지켜보지 않는 자동 실행 파이프라인에는 "묻지 말고 끝까지 진행하라"는 리마인더를 넣었는가

  예시 보기