Se connecter

Claude Fable 5 - 잘 사용하기

조이
카테고리
  1. 개념정리
이번에 Anthropic에서 다시 fable5를 열어줘서 당장 사용하고 있답니다. 근데 사용하기에 앞서, 앤트로픽에서 정리해 준 문서가 있어서 찬찬히 읽고 어떤 내용들이 바뀌었는지 낋여왔어요.
결론을 한 문장으로 먼저 말하면,
👀
이제는 "한 번 좋은 답을 받는 법"보다 오래 일하게 만드는 법이 중요해지고 있어요.

Opus 4.8과 Fable 5는 뭐가 다를까

문서에서 비교 대상으로 나오는 모델은 Claude Opus 4.8이에요. Opus 4.8도 이미 장기 에이전트 작업, 지식 작업, 비전, 메모리에 강한 모델로 설명돼요. 실제로 Opus 4.8 문서에서는 effort를 조절하고, 도구 사용을 유도하고, 서브에이전트 생성을 제어하는 이야기가 많이 나와요.
Fable 5는 거기서 한 단계 더 가요.
•
더 오래 자율적으로 일한다.
•
복잡한 문제를 첫 시도에 더 잘 푼다.
•
비전과 스크린샷 이해가 좋아졌다.
•
코드 리뷰와 디버깅에서 버그를 더 잘 찾는다.
•
모호한 요청을 받고 다음 단계를 정하는 능력이 좋아졌다.
•
병렬 서브에이전트를 돌리고 유지하는 능력이 좋아졌다.
더 똑똑해졌대요. 근데 너무 똑똑해서, Fable 5는 못해서 문제가 생기지 않고, 너무 많이 하려고 해서 문제가 생길 수 있는 모델이에요.

1. 똑똑한 모델에게는 "하지 말아야 할 일"도 알려줘야 한다

충분한 정보가 있으면 실행해라. 이미 결정된 내용을 다시 논쟁하지 마라. 필요 이상으로 리팩토링하지 마라. 요청하지 않은 기능을 추가하지 마라.
AI에게 버그 하나 고쳐달라고 했는데 주변 코드까지 정리하는 경우가 있어요. 문서 하나 요약해달라고 했는데 갑자기 전략 보고서가 되는 경우도 있고요. 이미 우리가 "A로 하자"고 정했는데 다시 A/B/C 장단점을 길게 비교하는 경우도 있어요.
이건 모델이 멍청해서 생기는 문제가 아니에요. 오히려 모델이 더 많은 걸 할 수 있게 되면서 생기는 문제예요.
사람에게도 비슷한 일이 있잖아요. 일을 잘하는 사람에게 "이거 한번 봐주세요"라고만 말하면, 그 사람이 문제를 더 크게 보고 다른 부분까지 고치려 할 수 있어요. 그게 고마울 때도 있지만, 지금 필요한 건 그게 아닐 때도 있어요.
그래서 Fable 5에게는 이런 식의 경계가 필요해요.
이 작업의 목표는 여기까지다.
주변 정리나 리팩토링은 하지 마라.
되돌릴 수 있는 일은 진행하되, 삭제·재시작·설정 변경처럼 위험한 일은 멈추고 물어봐라.
완료했다고 말하려면 실제 도구 결과로 확인한 것만 말해라.

2. 프롬프트는 점점 운영 원칙이 된다

예전 프롬프트는 이런 느낌이었어요.
너는 이런 역할이야.
이 순서로 해.
이 형식으로 답해.
이 단어는 쓰지 마.
모르면 모른다고 해.
물론 여전히 필요해요. 특히 짧은 작업이나 형식이 중요한 작업에서는 이런 지시가 잘 먹혀요.
그런데 Fable 5처럼 장기 실행을 전제로 한 모델에서는 더 중요한 질문이 생겨요.
•
이 일이 왜 필요한가?
•
어디까지가 범위인가?
•
무엇을 기준으로 완료라고 볼 것인가?
•
언제 사람에게 물어봐야 하는가?
•
중간 결과를 어떻게 검증할 것인가?
•
최종 보고는 누가 읽는다고 가정해야 하는가?
이 질문들은 "답변을 예쁘게 받기 위한 프롬프트"가 아니에요. 일을 안전하게 맡기기 위한 운영 원칙이에요.
저는 이 지점이 꽤 중요하다고 느꼈어요. AI를 잘 쓰는 능력이 점점 "말을 잘 거는 능력"에서 "일을 잘 정의하는 능력"으로 옮겨가고 있으니까요.

3. "왜 하는지"를 말해야 더 잘한다

요청뿐만 아니라 이유도 제공하라.
예를 들어 "이 문서 요약해줘"라고 할 수도 있어요. 하지만 더 좋은 요청은 이런 쪽이에요.
이 문서는 팀 회의에서 의사결정용으로 쓸 거야. 참석자는 개발자가 아니라 기획자와 리더들이야. 기술 디테일보다는 선택지, 리스크, 결정해야 할 포인트가 보여야 해. 이 기준으로 요약해줘.
결과가 달라질 수밖에 없어요.
모델이 단순히 문장을 줄이는 도구라면 "요약해줘"로 충분해요. 하지만 모델이 무엇을 남기고 무엇을 버릴지 판단해야 한다면, 이유가 필요해요.
사람에게 일을 맡길 때도 그렇잖아요. "자료 정리해줘"보다 "내일 대표님께 보고해야 해서 의사결정에 필요한 쟁점만 정리해줘"가 훨씬 좋아요. AI도 점점 그쪽으로 가고 있어요.
그래서 앞으로 좋은 프롬프트는 이렇게 생겼을 가능성이 높아요.
나는 [큰 목표]를 위해 이 작업을 하고 있다.
대상은 [누구]이고, 결과물은 [무엇을 가능하게 해야 한다].
이 맥락에서 [요청]을 수행해라.
충분한 정보가 있으면 바로 실행해라.
범위를 벗어난 추가 작업은 하지 마라.
검증한 것만 완료로 보고해라.
조금 길지만, 이건 모델을 설득하는 문장이 아니에요. 일의 배경을 공유하는 문장이에요.

4. 장기 작업에서는 "진행 중"보다 "검증됨"이 중요하다

Fable 5 문서는 장기 실행 작업에서 진행 상황을 보고할 때도 기준을 세우라고 해요.
그냥 "진행했습니다", "완료했습니다"라고 말하지 말고, 실제 도구 결과를 기준으로 말하라는 거예요.
이 부분이 저는 특히 좋았어요. AI 에이전트를 쓰다 보면 "했다"는 말이 묘하게 위험해질 때가 있거든요. 파일을 만들었다고 했는데 실제로 없거나, 테스트를 통과했다고 했는데 안 돌렸거나, 배포했다고 했는데 URL 확인을 안 한 경우요.
Fable 5 문서의 권장 방향은 명확해요.
진행 상황을 보고하기 전에 이번 세션의 도구 결과로 각 주장을 확인해라.
증거로 가리킬 수 있는 일만 완료했다고 말해라.
테스트가 실패했으면 실패했다고 말해라.
건너뛴 단계가 있으면 건너뛰었다고 말해라.
이건 AI에게만 필요한 규칙이 아니에요. 일 자체에 필요한 규칙이에요.
장기 실행 에이전트가 많아질수록 "말로 된 진행률"은 점점 믿기 어려워져요. 중요한 건 진행률이 아니라 증거예요. 파일이 있는지, 테스트가 통과했는지, 배포 URL이 열리는지, 실제 사용자가 볼 수 있는 상태인지.
제가 OpenClaw나 Hermes를 쓰면서 계속 배우는 것도 이쪽이에요. AI가 "됐어요"라고 말하는 순간이 끝이 아니라, 그 말이 맞는지 확인하는 구조가 있어야 진짜 끝이에요.

5. 결국 좋은 질문보다 좋은 브리프가 중요해진다

Fable 5 문서를 읽고 나서 든 생각은 단순했어요.
이제 프롬프트는 점점 브리프가 되고 있어요.
좋은 브리프에는 목표가 있어요. 맥락이 있어요. 범위가 있어요. 하지 말아야 할 일이 있어요. 완료 기준이 있어요. 그리고 결과를 받는 사람이 누구인지가 있어요.
이걸 잘 쓰는 사람은 AI에게서 더 좋은 결과를 받을 가능성이 높아요. 반대로 "알아서 잘해줘"만 반복하면, 모델이 좋아질수록 결과가 더 커지고 더 멀리 갈 수도 있어요. 좋은 쪽으로도, 나쁜 쪽으로도요.
질문을 잘하는 시대에서, 일을 잘 맡기는 시대로.
그리고 일을 잘 맡긴다는 건 결국 이런 거예요.
왜 하는지 말하기.
어디까지 할지 정하기.
무엇으로 확인할지 정하기.
필요할 때만 멈추게 하기.
AI가 더 똑똑해질수록 사람의 역할이 사라지는 게 아니라, 앞단으로 이동하는 것 같아요. 직접 손으로 다 하는 사람에서, 일의 구조를 잡는 사람으로요. 결국 AI 시대에도 중요한 건 "명령어를 많이 아는 사람"이 아니라, 일을 이해하고 제대로 맡길 줄 아는 사람이네요. 일 잘 하는 사람 대하듯이 일 잘하는 AI를 대하면 될 것 같습니다.

참고자료

zoeylog
'zoeylog' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'zoeylog'을 구독하세요!
구독
👍
4
😍
1
Ouvrir le canal