Claude Fable 5와 Opus 4.8, 프롬프트는 어떻게 달라져야 할까요?

클로드 공식 문서 기반 재구성해 작성한 글입니다.

클로드 모델이 좋아지면 프롬프트는 더 길어져야 할까요, 짧아져야 할까요?

저는 요즘 오히려 반대에 가깝다고 느낍니다. 모델이 좋아질수록 프롬프트를 더 많이 쓰는 것이 아니라, 무엇을 맡길지와 어디서 멈추게 할지를 더 정확히 정해야 해요.

Anthropic이 공개한 Claude Fable 5와 Claude Opus 4.8 프롬프트 가이드를 보면 이 차이가 꽤 선명합니다.

두 모델 모두 강력합니다. 하지만 일하는 방식은 다릅니다.

Fable 5는 더 오래, 더 자율적으로, 더 넓은 범위를 밀고 가는 쪽에 가깝습니다. Opus 4.8은 복잡도에 맞춰 답변을 조절하고, 도구보다 자체 추론을 먼저 쓰는 쪽에 가깝습니다.

그래서 같은 프롬프트를 그대로 쓰면 모델의 장점을 제대로 못 살릴 수 있어요.

핵심 요약

먼저 짧게 정리하면 이렇습니다.

이 표만 보면 단순한 모델 비교처럼 보이지만, 실제로는 AI를 업무에 붙이는 방식의 차이에 가깝습니다.

Fable 5는 “오래 맡기는 일”에 맞춰야 합니다!

Claude Fable 5 문서에서 가장 크게 느껴지는 키워드는 장기 자율성입니다.

예전에는 AI에게 한 번에 맡기기 어려웠던 일들이 있었어요. 여러 파일을 읽고, 맥락을 파악하고, 실행하고, 검증하고, 다시 고치는 작업입니다. 사람으로 치면 몇 시간, 며칠, 때로는 몇 주짜리 일에 가까운 것들이죠.

Fable 5는 이런 종류의 일에 더 적합하게 설명됩니다.

단순히 “답변을 잘하는 모델”이라기보다, 목표를 오래 붙잡고 실행하는 모델에 가깝습니다.

그래서 Fable 5를 쓸 때는 프롬프트도 달라져야 합니다. 한 문장으로 요약하면 이렇습니다.

“끝까지 해줘”보다 “어떻게 검증하면서 끝까지 갈지”를 정해줘야 합니다.

예를 들어 장기 작업을 맡길 때는 이런 기준이 중요해집니다.

• 진행 상황을 말하기 전에 실제 도구 결과와 대조하기
• 테스트가 실패했으면 실패했다고 말하기
• 확인하지 않은 것은 확인하지 않았다고 말하기
• 사용자 허락이 필요한 순간과 그냥 진행해도 되는 순간을 구분하기
• 요청 범위를 넘어선 리팩토링이나 정리를 하지 않기

모델이 똑똑해질수록 “알아서 잘하겠지”가 아니라, 알아서 어디까지 해야 하는지를 정해야 하는 셈입니다.

Fable 5에서는 effort가 작업 성격을 바꿉니다

Fable 5 문서에서는 대부분의 작업에 high effort를 기본으로 추천합니다. 더 어려운 작업이나 역량이 중요한 작업에는 xhigh를 권장하고요.

여기서 effort는 단순히 “더 똑똑하게 생각해줘” 버튼이 아닙니다.

비용, 지연 시간, 추론 깊이, 검증 행동까지 함께 바뀌는 조절 장치에 가깝습니다.

문제는 effort가 높을수록 모델이 필요 이상으로 열심히 일할 수도 있다는 점이에요.

버그 하나만 고치면 되는데 주변 코드를 정리하려고 하거나, 한 번만 처리하면 되는 일인데 헬퍼 함수를 만들거나, 아직 필요 없는 추상화를 만들 수 있습니다.

그래서 Fable 5에는 이런 식의 경계가 필요합니다.

요청된 작업을 해결하는 가장 단순한 방법을 선택하세요. 필요 없는 기능 추가, 리팩토링, 추상화, 호환성 레이어를 만들지 마세요.

이 문장이 중요한 이유는 모델의 능력을 낮추기 위해서가 아닙니다.

능력이 좋아졌기 때문에, 오히려 범위를 좁혀줘야 합니다.

Opus 4.8은 정확한 조정이 중요합니다

Claude Opus 4.8은 Fable 5처럼 극단적으로 장기 자율성을 강조하기보다는, 다양한 작업에서 안정적으로 강한 모델로 설명됩니다.

특히 지식 작업, 코드 리뷰, 비전, 메모리 작업, 장기 에이전트 작업에서 강점이 있습니다.

Opus 4.8에서 중요한 점은 두 가지예요.

첫째, 응답 길이를 작업 복잡도에 따라 자동으로 조절합니다.

간단한 질문에는 짧게 답하고, 열린 분석에는 길게 답하는 식입니다. 그래서 제품이나 업무 플로우에서 특정한 답변 길이가 필요하다면 명시해주는 게 좋습니다.

예를 들어 이렇게요.

간결하고 집중된 답변을 제공하세요. 필수적이지 않은 맥락은 생략하고, 예시는 최소한으로 유지하세요.

둘째, effort 설정을 꽤 문자 그대로 따릅니다.

low나 medium에서는 요청 범위를 넘어서지 않는 장점이 있지만, 복잡한 문제에서는 생각이 부족할 수 있습니다. 이때 프롬프트를 길게 덧붙이는 것보다 effort를 high나 xhigh로 올리는 편이 더 낫다고 문서는 설명합니다.

Opus 4.8은 도구보다 추론을 먼저 쓰려는 경향이 있습니다

Opus 4.8 문서에서 흥미로운 부분은 도구 사용에 대한 설명입니다.

Opus 4.8은 기본적으로 도구 호출보다 자체 추론을 선호하는 경향이 있다고 합니다. 대부분의 경우에는 좋은 특성이에요. 불필요한 검색이나 파일 조회를 줄이고, 이미 충분한 정보가 있으면 바로 답할 수 있으니까요.

하지만 AI 에이전트나 업무 자동화에서는 문제가 될 수 있습니다.

실제 파일을 봐야 하는데 추론으로 답하거나, 최신 정보를 확인해야 하는데 기억으로 답하면 위험해집니다.

그래서 Opus 4.8을 에이전트로 쓸 때는 도구 사용 조건을 더 명확히 써주는 게 좋습니다.

예를 들면 이런 식입니다.

• 최신 정보는 반드시 웹에서 확인하기
• 파일 내용은 추측하지 말고 실제 파일을 읽기
• 테스트 결과는 실행 로그를 기준으로 보고하기
• API 동작은 공식 문서를 확인한 뒤 말하기

두 모델의 서브에이전트 사용법은 다릅니다

Fable 5와 Opus 4.8의 차이가 가장 잘 보이는 부분 중 하나가 서브에이전트입니다.

Fable 5는 병렬 서브에이전트를 디스패치하고 유지하는 능력이 더 좋아졌다고 설명됩니다. 여러 하위 작업을 나눠 맡기고, 장기 실행 중에도 협업을 이어가는 방식에 강한 모델로 볼 수 있어요.

반면 Opus 4.8은 기본적으로 더 적은 서브에이전트를 생성하는 경향이 있습니다. 필요하면 프롬프트에서 명시해야 합니다.

예를 들어 코드베이스 여러 부분을 동시에 조사해야 한다면 이렇게 말할 수 있습니다.

여러 파일이나 독립된 항목을 동시에 조사해야 할 때는 같은 턴에서 여러 서브에이전트를 생성하세요. 단, 한 번에 직접 처리할 수 있는 작은 수정에는 서브에이전트를 만들지 마세요.

이 차이는 작은 팀의 AI 운영에도 그대로 적용됩니다.

모든 일에 에이전트를 여러 개 붙이는 것이 좋은 게 아닙니다. 반대로 모든 일을 하나의 AI에게만 맡기는 것도 비효율적일 수 있습니다.

중요한 건 작업의 성격입니다.

• 여러 출처를 동시에 조사해야 하는가?
• 파일이나 데이터가 여러 곳에 흩어져 있는가?
• 검증자 역할이 따로 필요한가?
• 한 번의 답변보다 장기 실행이 중요한가?

이 질문에 “예”가 많아질수록 서브에이전트 구조가 유리해집니다.

프론트엔드 작업에서 조심해야 할 것은?

Opus 4.8 문서에는 재미있는 내용도 있습니다.

프론트엔드나 디자인 작업에서 Opus 4.8은 기본적으로 따뜻한 크림색 배경, 세리프 계열 폰트, 테라코타나 앰버 계열 강조색을 선호하는 경향이 있다고 합니다.

이 스타일은 에디토리얼, 포트폴리오, 호스피탈리티 계열에는 잘 맞을 수 있습니다.

하지만 대시보드, 개발자 도구, 핀테크, 헬스케어, 엔터프라이즈 앱에는 어울리지 않을 수 있어요.

그래서 “깔끔하고 미니멀하게 만들어줘” 정도로는 부족합니다. 모델이 또 다른 익숙한 기본값으로 이동할 수 있기 때문입니다.

더 좋은 방식은 구체적인 시각 방향을 지정하는 것입니다.

• 색상 팔레트
• 폰트 성격
• 모서리 반경
• 여백감
• 레이아웃 구조
• 피해야 할 미학적 요소

또는 만들기 전에 4가지 시각 방향을 먼저 제안하게 하고, 그중 하나를 선택한 뒤 구현하게 할 수도 있습니다.

AI로 웹페이지나 랜딩페이지를 만드는 분들은 꼭 참고해야 할 부분입니다.

예전 프롬프트와 스킬을 그대로 두면 오히려 방해가 될 수 있습니다

Fable 5 문서에서 특히 눈에 들어온 문장이 있습니다.

이전 모델용으로 만든 스킬이나 프롬프트는 Fable 5에는 너무 규범적일 수 있다는 내용입니다.

저도 이 부분은 공감합니다.

AI 모델 성능이 지금처럼 높지 않던 시기에는 프롬프트가 일종의 보조 바퀴 역할을 했습니다. 하나하나 알려주고, 예외를 많이 쓰고, 실수하지 않게 울타리를 촘촘하게 세웠습니다.

그런데 모델이 좋아지면 그 울타리가 오히려 움직임을 방해할 수 있습니다.

이제는 “모든 행동을 지시하는 프롬프트”보다 “좋은 판단을 하게 만드는 기준”이 더 중요해지고 있습니다.

예를 들어 이런 변화입니다.

• 모든 진행 상황을 정해진 횟수마다 보고하게 하기보다, 필요한 순간에 근거 있는 업데이트를 하게 하기
• 긴 생각 과정을 사용자에게 보여주게 하기보다, 결과와 검증 근거를 분리해서 보여주기
• 모든 예외를 프롬프트에 쓰기보다, 멈춰야 할 기준과 진행해도 되는 기준을 정하기
• 작업 후 배운 점은 메모리나 스킬로 남기되, 중복되거나 틀린 것은 수정하기

AI를 오래 쓰는 팀일수록 프롬프트는 계속 쌓입니다.

하지만 쌓인 프롬프트가 전부 자산은 아닙니다. 어떤 지시는 더 이상 필요 없고, 어떤 지시는 모델의 장점을 막습니다.

내부 추론을 보여달라는 지시는 줄여야 합니다

Fable 5 문서에서는 모델에게 내부 추론을 응답 텍스트로 반복하거나 전사하게 하지 말라고 설명합니다.

예전에는 “단계별로 생각해줘” 같은 프롬프트가 자주 쓰였습니다. 하지만 최신 모델과 API 환경에서는 내부 추론을 그대로 노출시키려는 지시가 안전 장치나 거부 동작과 충돌할 수 있습니다.

업무 관점에서도 굳이 내부 추론 전체를 볼 필요는 없습니다.

우리가 필요한 것은 보통 세 가지입니다.

• 최종 판단
• 그 판단의 근거
• 실제로 확인한 자료나 실행 결과

생각의 모든 과정을 보여주는 것보다, 검증 가능한 결과를 보여주는 것이 더 중요합니다.

이건 에이전트 운영에서도 마찬가지입니다.

“무슨 생각을 했는지”보다 “무엇을 확인했고, 무엇이 아직 미확인인지”가 더 중요합니다.

프롬프트 설계에서 운영 설계로

이번 두 문서를 보면서 가장 크게 느낀 건, 프롬프트 엔지니어링이 점점 “운영 설계”로 이동하고 있다는 점입니다.

예전에는 좋은 답변을 얻기 위해 어떤 문장을 넣을지가 중요했습니다.

이제는 조금 다릅니다.

• 어떤 작업을 어떤 모델에 맡길지
• effort를 어디까지 줄지
• 언제 도구를 쓰게 할지
• 언제 서브에이전트를 나눌지
• 어디서 사용자에게 물어봐야 할지
• 무엇을 메모리나 스킬로 남길지
• 오래된 지시를 언제 제거할지

이런 운영 기준이 더 중요해지고 있습니다.

작은 팀이나 1인 대표에게도 이 변화는 꽤 큽니다.

AI를 잘 쓰는 사람과 그렇지 않은 사람의 차이가 “프롬프트를 예쁘게 쓰는 능력”이 아니라, 일을 AI가 실행하고 검증할 수 있는 구조로 바꾸는 능력으로 이동하고 있기 때문입니다.

바로 적용해볼 체크리스트

Claude를 업무에 쓰고 있다면 아래 질문부터 점검해보면 좋습니다.

• 이 작업은 한 번 답하면 끝나는 일인가요, 오래 실행해야 하는 일인가요?
• 최신 정보나 실제 파일 확인이 필요한데 모델이 추론으로만 답하고 있지는 않나요?
• effort를 낮게 둔 상태에서 복잡한 일을 시키고 있지는 않나요?
• 오래된 프롬프트가 모델의 자율성을 막고 있지는 않나요?
• 진행 보고가 실제 도구 결과에 근거하고 있나요?
• 서브에이전트를 써야 할 일을 하나의 모델에게만 몰아주고 있지는 않나요?
• 내부 추론을 보여달라고 하기보다 검증 결과를 요구하고 있나요?

이 질문에 답하다 보면 프롬프트를 더 길게 쓰는 것보다 먼저 바꿔야 할 것이 보입니다.

앞으로도 이런 관점에서 클로드, AI 에이전트, 노션 기반 업무 시스템을 계속 실험하고 정리해보겠습니다. AI를 단순한 답변 도구가 아니라, 실제 업무를 함께 굴리는 실행 시스템으로 만들고 싶다면 이 기준부터 점검해보세요.