모델을 바꿨는데 예전 프롬프트를 그대로 쓰는 경우가 많다. 이전 모델이 자꾸 놓치던 항목을 몇 번씩 강조하고, 필요 이상으로 잘게 나눈 절차도 남겨 둔다. 새 모델에 맞춰 지시를 정리할 이유는 있다. 다만 무엇을 없애도 되는지 확인하지 않고 짧게 만드는 것은 다른 문제다.
Claude Fable 5의 공식 프롬프트 가이드는 이전 모델과 다른 행동, effort 조절, 긴 작업의 보고와 기억 관리를 다룬다. 이 글은 2026년 9월 8일 확인한 Fable 5 문서를 바탕으로 만든 평가 설계다. Fable 5.1 안내와 섞지 않으며, 모델을 직접 비교해 속도나 정확도 개선을 측정한 후기는 아니다. Prompting Claude Fable 5
모델 이름과 실행 환경을 먼저 기록한다
첫 확인 대상은 정확한 모델이다. Fable 5와 Mythos 5는 공식 모델 소개에서 함께 설명되지만 접근 조건은 다르다. 소개 문서는 Fable 5의 일반 제공 경로와 Mythos 5의 승인된 고객 접근을 구분한다. 비슷한 설명을 가진 모델이라고 계정 권한이나 데이터 취급 조건까지 같다고 추측하지 않는다. Fable 5와 Mythos 5 공식 소개
실험 기록에는 모델 식별자, 사용 앱 또는 API, 도구 목록, 추론 설정, 입력 자료 버전과 날짜를 적는다. 화면의 이름만 메모하면 나중에 같은 조건을 재현하기 어렵다. 모델 별칭이나 제공 경로가 바뀔 가능성이 있으므로, 당시 확인한 문서 링크도 함께 둔다.
API 기능과 앱 기능도 구별해야 한다. 공식 API에 설정이 있다고 해서 내가 사용하는 에이전트 앱이 그 설정을 노출하거나 동일한 기본값을 쓰는 것은 아니다. 앱이 자동으로 메모리를 넣거나 도구 결과를 요약하면 모델만 바꾼 비교가 아닐 수 있다. 실행 기록에서 확인할 수 없는 설정은 ‘미확인’으로 남긴다.
이 구분은 오류를 추적할 때 도움이 된다. 응답이 늦어진 원인이 추론 설정인지, 외부 사이트의 지연인지, 도구 호출이 반복된 것인지 나눠 봐야 한다. 가격이나 공급사의 평가 점수만으로 우리 작업의 비용을 계산할 수 없다. 완성된 결과를 얻을 때까지의 재시도와 사람의 검토 시간도 포함해야 한다.
프롬프트를 세 종류로 나누면 지울 문장이 보인다
기존 지시를 모두 한꺼번에 줄이지 않겠다. 먼저 업무의 사실, 결과의 요구조건, 모델 행동을 보정하는 문장으로 나눈다. ‘원본 스크랩은 수정하지 않는다’는 요구조건이다. ‘같은 말을 반복해서 확인하라’는 과거 실패 때문에 넣은 행동 보정일 수 있다. 두 문장을 같은 기준으로 삭제하면 안 된다.
업무의 사실에는 대상 독자, 사용하는 자료, 현재 시스템의 상태가 들어간다. 결과의 요구조건에는 출처 보존, 승인된 수정 범위, 요약 형식과 완료 검사가 들어간다. 마지막으로 반복 경고, 불필요한 절차 지정, 과거 모델의 습관을 억제하는 문장을 별도 묶음으로 둔다.
예를 들어 글 보강 작업이라면 문장을 짧게 쓰라는 지시보다 기존 근거와 실질 분량을 유지하라는 조건이 중요할 수 있다. 반복된 수사를 걷어내면서 절차와 예외를 추가하는 편집과, 내용을 요약해 축소하는 작업은 다르다. 독자가 요청한 작업이 어느 쪽인지 프롬프트에서 분명해야 한다.
첫 비교에서는 행동 보정 묶음 중 하나만 바꾼다. 나머지 입력과 요구조건은 그대로 둔다. 결과가 좋아졌다면 어떤 반복을 줄였을 때였는지 알 수 있다. 여러 지시와 모델, 도구 설정을 동시에 바꾸면 원인을 찾기 어렵다. 개선이 확인되지 않았다면 이전 구성을 유지할 이유도 있다.
effort와 출력 길이는 별도의 요구로 다룬다
Fable 5 문서는 대부분의 작업에서 high를 출발점으로 보고, 작업의 난도와 응답 시간에 따라 다른 effort를 비교하도록 안내한다. effort는 엄격한 토큰 예산이 아니라 행동을 조절하는 신호다. 출력 상한이나 전체 비용 제한을 대신하지 않는다. Claude effort 안내
높은 설정이 언제나 필요한 것은 아니다. 링크 형식을 확인하는 짧은 작업과 여러 파일의 모순을 찾는 작업은 필요한 검토량이 다르다. 반대로 쉬워 보인다는 이유만으로 설정을 낮췄다가 필수 출처 확인을 건너뛰면 비용 절감으로 보기 어렵다. 결과의 품질 조건을 통과한 실행끼리 시간과 비용을 비교해야 한다.
시험용으로 세 종류의 입력을 준비할 수 있다. 명세가 분명한 짧은 수정, 자료가 서로 충돌하는 비교 글, 여러 파일을 읽고 갱신해야 하는 긴 작업이다. 각 입력에서 현재 설정과 조정한 설정을 비교하고, 우연히 좋은 한 번을 고르지 않도록 반복 실행 기록을 남긴다. 몇 번의 작은 실험을 통계적으로 확정된 성능 차이라고 발표하지 않는다.
출력 길이는 별도로 지정한다. 긴 보고서가 필요한데 effort를 높였다고 충분한 설명이 보장되는 것은 아니다. 앞부분에는 독자가 판단할 짧은 요약을 두고, 본문에는 근거와 절차, 한계를 충분히 남긴다고 요청할 수 있다. 간결한 보고와 내용이 빈약한 보고를 구분하는 기준은 독자가 다음 행동을 결정할 정보가 있는지다.
버전별 API 차이도 확인해야 한다. 현재 effort 문서는 Fable 5.1의 메시지별 변경과 Fable 5의 지원 범위를 구분한다. 5.1의 예제를 Fable 5에 복사해 지원된다고 가정하지 않는다. 이 글은 실행용 API 예제를 제공하는 글이 아니므로, 실제 코드를 바꿀 때에는 해당 모델의 최신 파라미터 표를 다시 확인해야 한다.
긴 작업의 진행 보고에는 도구 결과가 붙어야 한다
‘검증 중입니다’라는 문장이 이어지면 작업이 잘 진행되는 것처럼 보인다. 하지만 어떤 파일을 읽었고 어떤 검사가 실제로 끝났는지는 알 수 없다. 공식 Fable 5 가이드도 긴 실행의 진행 주장을 도구 결과에 근거하도록 지시하는 방법을 설명한다. 여기서 가져올 조건은 보고를 자주 하는 것만이 아니라 보고와 증거가 연결되는 것이다. Fable 5 진행 보고 지침
예시 보고 양식은 ‘완료한 항목, 확인한 결과, 아직 확인하지 않은 것, 다음 작업’ 정도면 된다. 파일을 수정했다는 보고에는 경로와 변경 목적이 있어야 한다. 검사가 통과했다면 어떤 검사를 어느 결과물에 실행했는지 남긴다. 실패한 검사를 다른 성공한 검사와 묶어 ‘전부 통과’라고 요약하지 않는다.
도구가 시간 초과됐는데 출처를 확인했다고 쓰는 것도 막아야 한다. 검색 결과의 제목을 본 것과 문서 본문을 읽은 것은 다르다. 웹 페이지가 열리더라도 로그인 화면이나 다른 글로 이동했다면 근거를 검증한 것으로 표시하지 않는다. 이런 구분이 보고에 남아야 사람이 보완할 대상을 찾을 수 있다.
실행 시간이 길면 UI의 대기 처리도 필요하다. 무응답처럼 보이지 않게 진행 상태를 표시할 수 있지만, 화면에 글자를 계속 쓰는 것만으로 실제 작업을 대신해서는 안 된다. 외부 시스템에서 대기해야 하는 상태와 에이전트가 계속할 수 있는 독립 작업을 구분한다. 불필요한 질문 때문에 작업이 멈추는 문제와 필요한 승인을 생략하는 문제는 따로 다룬다.
자율성에는 읽기·수정·발행의 서로 다른 범위가 있다
모델이 더 오래 일할 수 있어도 사용자의 요청 범위가 넓어지는 것은 아니다. ‘왜 안 보이는지 확인해 줘’는 진단 요청이다. 원인을 찾았다고 운영 설정을 바꾸거나 새 글을 공개할 권한까지 생기는 것은 아니다. 반면 사용자가 범위를 정해 수정과 검증을 승인했다면 그 안의 안전한 작업을 매번 다시 물을 필요는 없다.
예시로 원고 12편의 보강을 승인했다고 하자. 에이전트는 지정한 원고를 읽고 수정하며 검사를 할 수 있다. 무관한 자료를 삭제하거나 개인정보가 있는 폴더를 외부 서비스로 보내는 행동은 포함되지 않는다. 공개 발행이 승인 범위에 있는지도 처음에 구분해야 한다. 이미 승인한 작업과 새로 결정해야 할 작업이 섞이면 질문도 실행도 불안정해진다.
프롬프트만으로 모든 통제가 해결되지는 않는다. 원본 폴더를 읽기 전용으로 두거나 출력 경로를 제한하고, 외부 게시 권한을 별도 단계에 제공하는 방식이 필요할 수 있다. 중요한 결과는 실행 뒤 원본 해시, 변경 파일 목록과 발행 기록으로 확인한다. 모델이 경계를 지켰다고 말하는 것만으로 보존을 증명할 수 없다.
백업도 범위를 정해야 한다. 승인된 편집 전에 복구 가능한 사본을 남기는 일과, 무관한 저장소에 임의로 브랜치를 만들거나 전체 개인 폴더를 복제하는 일은 다르다. 어떤 원본을 어디에 보관하고 어떻게 복구할지 정한 뒤 실행하도록 설계한다.
외부 기억에는 교훈뿐 아니라 적용 조건을 남긴다
긴 작업에서 배운 내용을 다음 세션에 넘기는 것은 유용하다. 문제는 추측이 기억 파일에 들어가 사실처럼 재사용되는 경우다. ‘이 프로젝트는 항상 특정 도구를 쓴다’는 메모가 오래되면 다음 에이전트가 현재 코드를 읽기 전에 잘못된 전제를 갖게 된다.
내가 설계할 기억 항목에는 확인한 사실, 근거 위치, 적용 범위, 확인 날짜를 넣겠다. 예를 들어 어떤 명령으로 검사를 수행했다면 명령과 적용한 버전을 적는다. 한 번 실패한 방법은 실패 조건을 붙여 기록한다. 모든 환경에서 작동하지 않는다는 일반 법칙으로 확대하지 않는다.
사용자의 선호와 프로젝트 정책도 나눈다. 긴 설명을 선호한다는 말과 비밀키를 공개하지 말라는 규칙은 같은 종류의 메모가 아니다. 바뀔 수 있는 취향, 코드에서 확인할 설정, 반드시 지킬 권한 조건을 구분하면 충돌을 처리하기 쉽다. 계정 정보나 비밀값은 일반 교훈 파일에 저장하지 않는다.
기억의 수가 늘어날 때에는 중복과 모순을 검사한다. 새 메모를 무조건 추가하면 서로 다른 날짜의 지시가 함께 읽힐 수 있다. 기존 항목을 갱신하고 변경 이유를 남기거나, 더 이상 유효하지 않은 항목을 구분하는 방법이 필요하다. 문서를 많이 만든 것이 학습의 증거는 아니다. 다음 작업에서 잘못된 가정을 줄였는지가 중요하다.
모델 교체의 성공 조건을 결과표로 정한다
최종 비교표에는 완성 여부뿐 아니라 사실 오류, 누락한 검사, 범위 밖 수정, 응답 시간과 수동 수정량을 적는다. 시간은 줄었지만 출처를 안 읽었다면 성공이 아니다. 결과가 훌륭해도 허용하지 않은 파일을 수정했다면 해당 구성은 채택하지 않는다. 품질과 권한 조건을 먼저 통과시킨 뒤 운영 효율을 비교하겠다.
실험을 마친 뒤 남길 문서는 길 필요가 없다. 어떤 지시를 없앴는지, 어떤 요구조건은 유지했는지, 어떤 입력에서 실패했는지와 다음 비교 항목을 적으면 된다. 측정하지 않은 부분은 그대로 빈칸이나 미확인으로 둔다. ‘새 모델이라 더 낫다’는 결론을 먼저 정해 놓고 결과를 맞추지 않는다.
Fable 5 가이드는 이런 점검을 시작하는 자료다. 실제 내 작업에서 어떤 프롬프트가 맞는지는 입력과 검증 결과로 판단해야 한다. 모델별 지시를 조정하더라도 원본, 출처, 승인 범위와 완료 증거는 계속 남겨 둘 생각이다.
참고자료
- Anthropic — Prompting Claude Fable 5: Fable 5의 행동과 긴 실행에 대한 공식 지침.
- Anthropic — Introducing Claude Fable 5 and Claude Mythos 5: 모델 구분, 제공 경로와 API 차이.
- Anthropic — Effort: 모델별 설정 범위와 비용·지연 조절의 한계.