앤스로픽이 숨기고 싶어 하는 페이블의 5가지 규칙

AAI LABS
컴퓨터/소프트웨어경영/리더십AI/미래기술

스크립트

00:00:00Fable 5가 곧 플랜에서 제외될 거라는 건 이미 아시겠지만,
00:00:04걱정하실 필요는 없습니다. Anthropic에서 이미 다시 도입할 계획이라고 밝혔으니까요.
00:00:09영원히 사라지는 건 절대 아닙니다. Fable이 출시되었을 때 Anthropic은 프롬프팅 가이드를 공개했는데요,
00:00:13그게 이 모델을 사용하는 유일한 규칙이라고 생각하실 수도 있겠지만, 그렇지 않습니다.
00:00:17그 가이드는 단순히 앱 내에서 모델을 사용하는 방법일 뿐, 실제 워크플로에 적용하는 방법은 알려주지 않죠.
00:00:22저희는 소프트웨어 회사로서 며칠 동안 저희 제품과 고객을 위해 개발 중인 제품 모두에
00:00:27이 모델을 실행해 보았고, 그 과정에서 여러분이 적용할 수 있는 몇 가지 규칙을 찾아냈습니다.
00:00:32예를 들어, 모델을 최대한 활용하려면 어떤 설정을 사용해야 할까요?
00:00:36Fable 사용량을 줄이는 데 사용할 수 있는 무료 도구도 있는데, 그걸 사용하려면
00:00:41코딩 프로젝트가 올바르게 설정되어 있는지 확인해야 합니다. 저희가 조금 늦은 감이 있지만,
00:00:46이 영상이 끝날 때쯤이면 여러분도 이 모델을 어떻게 사용하기 시작해야 할지 확실히 이해하게 될 겁니다.
00:00:51가장 먼저 바꿔야 할 설정은 '노력(effort)' 설정입니다. 이것 하나만으로도
00:00:56품질 저하 없이 사용량을 절반으로 줄일 수 있습니다. 아시다시피 '노력'은 모델이 답변하기 전에
00:01:02얼마나 깊이 고민하는지를 나타내지만, 아마 미처 생각지 못한 사실이 하나 있습니다.
00:01:06Fable 5에서 이 설정을 높이는 건 사실 엄청난 함정이라는 점이죠. 아마 다들 이렇게 하시겠죠?
00:01:11메뉴에서 '최대(max)'를 보고 가장 똑똑한 모델이니 최대한 열심히 일해야 한다고 생각해서
00:01:16설정을 끝까지 올리시겠지만, 이건 모델의 출력 결과에 아무런 차이를 만들지 않습니다.
00:01:20설정을 '고(High)'로 하나 '최대(Max)'로 하나 결과물은 똑같습니다. 저희도 솔직히 놀랐고,
00:01:25다른 분들도 똑같이 경험하셨죠. 설정을 더 높게 잡으면 사용량만 무지막지하게 늘어날 뿐입니다.
00:01:30그리고 '울트라 코드(Ultra code)'는 그냥 노력 수준 위에 덧붙여진 Claude 코드 스킬일 뿐인데,
00:01:35솔직히 별로 가치 있는 결과물을 만들어낸 적이 없습니다. Anthropic이 제품 비용을 더 쓰게 만드는
00:01:40방법 중 하나일 뿐이죠. 그러니 노력 설정은 '낮음(Low)'에서 '높음(High)' 사이로 유지하고,
00:01:45절대 그 이상은 올리지 마세요. 낮은 단계와 중간 단계의 노력 설정만으로도 Fable이 얼마나
00:01:50잘 작동하는지 확인하시면 아마 깜짝 놀라실 겁니다. 이제 거대 모델과 작지만 더 똑똑한 모델이
00:01:55동시에 나오면 무슨 일이 벌어질까요? AI 업계에서 흔히 볼 수 있는 패턴 중 하나는,
00:01:59사람들이 더 큰 모델은 기획용으로, 더 작은 모델은 실제 작업을 수행하는 용도로 쓰라고 말하기 시작한다는 거죠.
00:02:04항상 이런 식입니다. Sonnet 5가 나왔을 때 새로운 트렌드는 Opus 모델을 쓰기엔 아까운
00:02:10모든 작은 작업에 Sonnet 5를 사용하라는 것이었죠. 그땐 아직 Fable이 나오기 전이었지만요.
00:02:15그래도 이건 여전히 좋은 조언입니다. 예를 들어 '제2의 두뇌(second brain)'를 만드셨다면,
00:02:20문서를 읽거나 방대한 PDF를 분석할 때 거대 모델을 써선 안 된다는 걸 잘 아실 겁니다.
00:02:25저희도 AI 랩의 '제2의 두뇌'에서 경쟁사의 콘텐츠를 연구용으로 가져올 때 바로 그렇게 합니다.
00:02:30이미 많이 들어보셨을 수도 있겠지만, 워크플로에 여러 모델을 효과적으로 사용하는 몇 가지 도구를 찾았습니다.
00:02:35사용 가능한 워크플로에 대해 이야기하자면, 가장 간단한 건 더 큰 모델로 계획을 세우고,
00:02:40더 작은 모델에게 구현을 맡기는 방식입니다. 예를 들어 저희 커뮤니티 프로젝트를 보시면,
00:02:44docs 폴더 안에 새로운 기능을 구현할 때 항상 사용하는 하위 폴더가 있습니다.
00:02:49새로운 기능이 나올 때마다 항상 PRD(제품 요구사항 문서)를 작성하는데,
00:02:54이 PRD는 저희 템플릿을 기반으로 합니다. 새로운 PRD를 만들 때는 Fable이나 다른 거대 모델을 사용하고,
00:03:00기능이 너무 크지 않다면 더 작은 모델로 구현하죠. 저희 템플릿을 그대로 따라 할 수 있냐고요?
00:03:05그건 이 프로젝트에 맞춰져 있어서 그대로 쓰긴 어렵습니다. 새로운 기능을 만들 때마다,
00:03:11이 기능이 프로젝트의 다른 부분에 어떤 영향을 줄지 항상 묻거든요. 예를 들어,
00:03:16프로젝트에 새로운 사용자가 생성되는지, 데이터 모델과 마이그레이션은 어떤지,
00:03:21즉, 앱 뒤의 데이터베이스를 실제로 변경해야 하는지 말이죠. 또 이 커스텀 커뮤니티에서는
00:03:26저희가 영상에서 보여드리는 모든 기술, 디자인 시스템, 작업물을 찾으실 수 있습니다.
00:03:31저희 영상이 유익해서 채널을 후원하고 싶으시다면, 이 방법이 가장 좋습니다.
00:03:37링크는 설명란에 있습니다. 에이전트 작업에서 또 하나 중요한 건,
00:03:42여러 하위 에이전트를 돌리는 겁니다. Theo가 자신의 claude.md에서 공유한 관련 섹션이
00:03:47이 하위 에이전트들에 아주 잘 맞습니다. 하위 에이전트로 작업을 실행할 때,
00:03:53세션을 조율하는 메인 모델은 이런 모델 그래프를 가져야 한다고 하더군요.
00:03:58비용, 지능, 취향에 따라 모델을 평가하고 분류하는 방식이죠. 저희는
00:04:03claude.md를 사용해 워크플로에 이걸 구현하진 않았지만, 수동으로 모델을 다르게 연결하며 쓰고 있고,
00:04:07Theo가 정리한 순위도 꽤 정확합니다. 그래서 메인 세션에서 Claude 모델을 쓰고 싶으면,
00:04:12당연히 그 모델을 사용하는 하위 에이전트를 생성하면 되는데, Codex 모델은 어떻게 사용할까요?
00:04:18Theo는 Codex 모델은 CLI를 통해서만 접근 가능하다고 적었지만, 이 특수한 목적을 위해
00:04:24OpenAI가 Claude Code를 위한 플러그인을 만들었습니다. 이 명령어로 설치할 수 있고요.
00:04:28Claude Code 슬래시 명령어를 사용하면 됩니다. Codex CLI가 필요하긴 하지만,
00:04:33Codex 모델을 좋아하신다면 활용할 수 있는 몇 가지 명령어를 제공합니다. 저희도
00:04:39Codex를 많이 쓰기 시작했는데, 다른 모델이 작성한 코드를 검토할 때 훨씬 뛰어나다고 생각해서
00:04:44리뷰 작업용으로 사용합니다. 하지만 아직 Fable 5와 직접 비교해 보지는 않았습니다.
00:04:49거대 모델을 기획용으로 쓰라고 말씀드렸지만, Fable 5로 작업하면서 발견한 독특한 점이 하나 있습니다.
00:04:54이 모델은 어려운 문제에 창의적인 해결책을 찾는 데 정말 탁월합니다.
00:04:59그래서 가끔 코딩 작업에도 직접 사용하곤 하죠. 하지만 비용이 너무 많이 든다는 문제는 여전합니다.
00:05:04이를 해결하기 위해 'Ponytail'을 사용할 수 있습니다. AI 코딩 에이전트가 코드를
00:05:09더 적게 작성하게 만드는 일련의 규칙이죠. 새로운 건 아니고, 모델이 코드를
00:05:14적게 쓰게 하는 기존 코딩 규칙의 목록일 뿐입니다. 하지만 이걸 그냥 사용하면
00:05:20이미 사용자가 있는 앱이 고장 날 수도 있습니다. 그래서 이 도구를 쓰려면 앱 내에
00:05:25특정한 구조가 필요합니다. 테스트 주도 개발(TDD) 개념을 잘 아실 텐데,
00:05:30테스트를 먼저 작성하고 에이전트가 코드를 작성하는 방식이죠. 저희는 매번 기능을 만들 때마다
00:05:35PRD를 작성하고 그 PRD를 기반으로 테스트를 씁니다. 본격적으로 사용법을 다루기 전에
00:05:40저희 스폰서인 VEED를 소개합니다. AI로 영상을 만들려다 보면 매 모델이 다른 플랫폼에
00:05:46있어서 구독료만 다섯 개씩 내느라 애먹은 경험 다들 있으실 겁니다. VEED는 모든 주요 AI 영상 생성기를
00:05:51한곳에 모은 올인원 AI 영상 플랫폼입니다. 'Gen AI 스튜디오'에 프롬프트를 입력하면
00:05:56대본, 시각 자료, 더빙, 자막까지 포함된 소셜 미디어 영상을 즉시 만들어줍니다.
00:06:01사진 한 장으로 최대 5분짜리 실감 나는 대화 영상을 만드는 'VEED Fabric 1.0' 모델도 있죠.
00:06:07여러 AI 영상 생성기를 비교해 보고 싶다면 플랫폼을 나갈 필요 없이 'AI 플레이그라운드'에서
00:06:13Google VEO, Kling, C-Dance 등을 바로 써볼 수 있습니다. 그 외에도 영상 편집 기능,
00:06:18자동 자막, 배경 제거, 오디오 정리 등 모든 게 내장되어 있습니다. 설명란의 코드를 사용해
00:06:25첫 달 30% 할인 혜택을 받아보세요. 여기 저희 커뮤니티 대시보드를 보시면,
00:06:30대시보드 코드 파일뿐만 아니라 테스트 파일도 같이 있습니다. 앱에 뭔가가 바뀌면
00:06:35항상 이 테스트들을 실행해서 기능이 제대로 작동하는지 확인하죠. 예를 들어 설정 아이콘을 클릭해서
00:06:42메뉴가 열려야 하는데, 에이전트가 짠 코드가 버튼을 망가뜨려 메뉴가 안 뜨게 된다면?
00:06:47원본 코드가 깨진 겁니다. 그래서 '단위 테스트(unit tests)'가 필요합니다.
00:06:52여기서는 대시보드라는 단일 단위를 테스트하는 거죠. 전체 앱이 이런 테스트로 덮여있어서,
00:06:57새 기능을 만들 때마다 TDD 테스트 작성자가 새로운 테스트를 먼저 작성합니다.
00:07:02기존 에이전트가 코드를 짜고 그 코드에 맞는 테스트를 본인이 작성하게 하면
00:07:08자기 잘못된 코드를 통과시키려 할 테니, 다른 하위 에이전트가 테스트를 쓰는 게 중요합니다.
00:07:13저희는 저장소를 이렇게 구조화해 두고 항상 테스트를 먼저 작성하니까, 모델이 코드를
00:07:18어떻게 짜든 결과가 잘 작동할 거란 확신이 있죠. 이 TDD 테스트 작성 에이전트를
00:07:24사용하고 싶으시다면 저희 AI Labs 프로 커뮤니티에서 구하실 수 있습니다.
00:07:29Ponytail은 Claude Code의 플러그인이라 다른 스킬들도 함께 오는데요. 스킬의 prompt만
00:07:35skill.md에서 복사해서 메인 claude.md에 넣거나, Fable 5 코딩을 시작하기 전에
00:07:40프롬프트로 붙여 넣으시면 됩니다. Fable 5와 Ponytail이 어떻게 함께 쓰이냐고요?
00:07:45리팩토링이라는 개념을 아실 텐데, 코드를 더 간결하게 수정하는 작업입니다.
00:07:50Ponytail은 리팩토링에 정말 능숙하죠. 테스트가 다 작성되어 있으니
00:07:56Ponytail이 뭘 짜든 테스트를 통과하니까 믿고 맡길 수 있고, 이렇게 계속해서
00:08:02코드를 변경하며 앱을 빌드할 수 있습니다. 다음 규칙으로 넘어가기 전에 꼭 짚고 넘어갈 게 있습니다.
00:08:08Fable이 더 멍청해졌고 코딩을 못 하게 되었다는 벤치마크가 돌아다니는데요,
00:08:13코딩을 시키면 Opus로 우회하기 때문이라는 내용인데, 솔직히 사실이 아닙니다.
00:08:18그 벤치마크 하나만 그런 거고 저희는 신뢰하지 않습니다. Sonnet 5를 추론 1위 모델로
00:08:23평가하는데, 말이 안 되거든요. 저희는 내내 이 모델을 쓰고 있는데 코딩 작업에서
00:08:29추론 과정을 설명하라고 할 때 말고는 Opus로 우회하는 걸 본 적이 없습니다.
00:08:34그러니 너무 걱정하지 마세요. 다른 사람들이 이 모델을 어떻게 쓰고 있는지 봤는데,
00:08:38Anthropic이 이걸 처음 내놓은 목적을 잊고 있더군요. Mythos가 너무 강력해서
00:08:44다른 모델은 찾지 못하는 보안 취약점을 찾아내고, 탈옥까지 시킬 수 있다고 경고했었죠.
00:08:49그러니 코드 리뷰 에이전트와 보안 리뷰 에이전트를 꺼내서 보안에 집중하세요.
00:08:54예를 들어 저희는 지금 커뮤니티에 새 기능을 추가하고 전체적인 리디자인을 진행 중인데,
00:08:59플랫폼을 구축하는 과정에서 검증 루프의 일환으로 몇몇 하위 에이전트를 사용합니다.
00:09:04그중 하나가 코드 리뷰 전문가인데, Cursor의 'Thermonuclear 코드 품질 리뷰' 스킬을
00:09:10기반으로 한 하위 에이전트입니다. 코드베이스의 아키텍처를 확인하고
00:09:15방향이 맞는지 확인해 주는 아주 훌륭한 스킬이죠. 에이전트로 새 기능을 추가하다 보면,
00:09:20얼마 안 가 작은 수정 사항들과 두 가지 사소한 문제를 찾아내서 알려줍니다.
00:09:25다 보여드리진 않겠지만 다 패치했습니다. 또 하나 실행하는 건 보안 리뷰어 하위 에이전트인데,
00:09:31이건 'Claude Code 보안 리뷰'라는 GitHub 액션을 기반으로 합니다.
00:09:36이 GitHub 액션은 코드를 GitHub에 올릴 때 자동으로 실행되는 자율 리뷰 도구입니다.
00:09:41저장소 링크를 Claude Code에 주고 에이전트로 만들어달라고 하면 그대로 해줍니다.
00:09:46새 기능에 대한 보안 리뷰였는데 이번엔 깨끗하다고 나왔지만,
00:09:51전체 플랫폼에 실행해 보니 Fable 5 기반의 보안 리뷰어 에이전트 6개를
00:09:56여러 부분으로 나뉜 플랫폼 전체에 병렬로 돌렸고, 이게 훨씬 성과가 좋았습니다.
00:10:01많은 버그를 찾아냈고 전부 패치했습니다. Anthropic이 경고하고 강조했던 대로
00:10:06보안과 코드베이스 리뷰에 집중하셔야 합니다. 최근 Anthropic의 Tarik이
00:10:10Fable 5 사용 경험과 생각을 담은 가이드를 발행했는데요, 몇 가지만 보시면 충분합니다.
00:10:16직접 만든 예시 아티팩트들이 기사보다 설명을 훨씬 잘 해줍니다.
00:10:22과정을 여러 단계로 나누었는데, 기존 모델로도 이미 다들 하고 계실 테니
00:10:27굳이 깊이 파고들 필요는 없습니다. 하지만 꼭 시작해야 할 게 하나 있다면,
00:10:32구현할 기능의 모형(mockup)을 먼저 만드는 것입니다. 저장소를 보시면,
00:10:37design 폴더 안에 mocks 폴더가 있습니다. 기능을 새로 만들 때마다
00:10:42가장 먼저 이 HTML 모형에 추가합니다. 사이트를 1:1로 복제한 프로토타입인데,
00:10:47본격적인 개발 전에 시각화해서 확인하는 게 중요하기 때문입니다. 그리고
00:10:52그 기사에서 좋았던 점은 머지(merge)하기 전에 퀴즈를 낸다는 겁니다.
00:10:57다들 아시겠지만 코딩할 때 Git 브랜치를 만들고 변경 후 머지하죠.
00:11:03에이전트가 뭘 구현했는지 제대로 확인 안 하는 분들도 계신데,
00:11:09코드를 다 읽으라는 게 아니라 최소한 에이전트가 어떻게 했는지 요약이라도 꼭 읽어야 합니다.
00:11:14그 기사의 프롬프트를 보면 머지하기 전에 Fable이 직접 변경 사항에 대해 퀴즈를 냅니다.
00:11:19이 과정은 프로젝트 내에서 무슨 일이 벌어지는지 확실히 알게 해주니 강력 추천합니다.
00:11:25저희도 많은 프로젝트를 겪어봤지만, 코드베이스에 무슨 일이 일어나는지 모르면
00:11:29무슨 수를 써도 에이전트를 통제할 수 없습니다. 목표를 설정하든 루프를 돌리든,
00:11:34결국 에이전트는 멈추게 될 거고, 새로운 기능을 추가해야 할 겁니다.
00:11:39프로젝트 내용을 모르면 나중에 반드시 화를 입게 됩니다. 영상 마무리할게요.
00:11:44채널을 후원하고 이런 영상을 계속 만드는 데 도움을 주시고 싶다면,
00:11:50아래의 '슈퍼 땡스(Super Thanks)' 버튼을 눌러주세요. 늘 시청해 주셔서 감사드리고,
00:11:55다음 영상에서 뵙겠습니다.
00:12:00...
00:12:05...
00:12:10...
00:12:15...
00:12:20...
00:12:25...
00:12:30...
00:12:35...
00:12:40...
00:12:45...
00:12:50...
00:12:56...
00:13:00...
00:13:05...
00:13:11...

핵심 요약

Fable 5 활용 시 '노력' 설정을 낮춤으로써 비용을 최적화하고, 거대 모델과 소형 모델의 역할 분담 및 TDD 기반의 에이전트 검증 루프를 구축해야 효율적인 개발이 가능하다.

하이라이트

  • Fable 5의 '노력(effort)' 설정을 '최대(Max)'로 높이는 것은 출력 품질 개선 없이 사용량만 증가시키는 비효율적인 방식이다.

  • 모델 사용량 절반 절감 및 효율화를 위해 노력 설정을 '낮음(Low)'에서 '높음(High)' 범위로 유지하는 것이 권장된다.

  • 복잡한 기획은 거대 모델로 수행하고, 실제 코드 구현은 더 작고 비용 효율적인 모델에 맡기는 워크플로가 효과적이다.

  • 코딩 에이전트 작업 시 테스트 주도 개발(TDD) 방식을 적용하고, 코드를 작성한 에이전트와 별도의 하위 에이전트가 테스트를 담당해야 코드 품질이 확보된다.

  • 코드 머지 전 에이전트가 직접 구현 내용을 요약하고 변경 사항에 대해 스스로 퀴즈를 내게 하면 통제력을 유지할 수 있다.

  • 보안 취약점 탐색 및 코드 품질 리뷰를 위해 전용 하위 에이전트를 생성하여 병렬로 실행하는 것이 자율 검증에 유리하다.

타임라인

모델 설정 최적화 및 비용 절감

  • Fable 5의 '노력' 설정을 최대로 높여도 결과물에는 변화가 없다.
  • 설정을 높게 고정하는 것은 출력 품질과 무관하게 사용량만 무제한으로 증가시킨다.
  • 노력 설정을 '낮음'에서 '높음' 사이로 조정하는 것만으로도 품질 저하 없이 사용량을 절반으로 줄일 수 있다.

사용자는 모델이 더 똑똑해질 것이라 기대하며 설정을 끝까지 올리는 실수를 범하지만, 실제 성능은 '높음'과 '최대' 설정 간 차이가 없다. '울트라 코드'와 같은 추가 기능 역시 비용 대비 가치가 불분명하다. 따라서 모델의 깊은 고민이 반드시 필요한 상황이 아니라면 중간 단계의 설정을 유지하는 것이 경제적이다.

모델 효율적 배분 및 워크플로 전략

  • 기획과 설계는 거대 모델이 수행하고, 실제 기능 구현은 더 작은 모델에 할당한다.
  • 워크플로의 각 단계에 맞는 모델을 하위 에이전트로 배치하여 조율한다.
  • Codex 모델은 직접 구현보다는 작성된 코드를 검토하거나 리뷰하는 작업에 탁월하다.

거대 모델과 소형 모델을 동시에 운영하는 최적의 패턴은 역할 분리이다. 기획용 문서(PRD) 작성에는 고성능 모델을 사용하고, 반복적인 구현 작업에는 비용이 낮은 모델을 배치한다. 하위 에이전트들을 활용해 작업 세션을 세분화하면 전체 프로젝트의 효율성을 높일 수 있다.

테스트 주도 개발(TDD)과 자동화된 검증

  • Ponytail 규칙을 적용하여 에이전트가 작성하는 코드의 양을 최적화한다.
  • 기능 구현 전 단위 테스트를 작성하여 코드가 의도대로 작동하는지 검증한다.
  • 코드 작성 에이전트와 테스트 작성 에이전트를 분리하여 자기 검증 오류를 방지한다.

코딩 에이전트의 효율성을 극대화하기 위해 테스트를 먼저 작성하는 TDD 개념을 도입한다. 기존 코드를 수정할 때는 Ponytail과 같은 리팩토링 전용 스킬을 결합하여 코드를 간결하게 유지한다. 테스트가 저장소에 미리 준비되어 있으면, 에이전트가 코드를 수정하더라도 즉각적으로 기능 이상 여부를 확인할 수 있다.

보안 리뷰 및 프로젝트 제어 루프

  • 코드베이스의 보안 및 아키텍처 결함 탐지를 위해 전용 리뷰 에이전트를 병렬로 실행한다.
  • 기능 개발 전 반드시 HTML 모형(mockup)을 생성하여 시각적 프로토타입을 확인한다.
  • 코드 머지 전 에이전트가 수행한 작업을 스스로 퀴즈를 내어 요약하게 함으로써 통제력을 유지한다.

Fable 5의 강력한 추론 능력은 보안 취약점을 찾는 데 효과적이다. 전체 플랫폼에 다수의 보안 리뷰 에이전트를 병렬로 돌리면 버그 탐지율이 급격히 상승한다. 또한 개발 과정에서 프로토타입을 먼저 확인하고, 마지막 머지 단계에서 에이전트의 설명을 퀴즈 형식으로 검증하는 과정을 거치면 프로젝트 통제력을 잃지 않을 수 있다.

커뮤니티 글

모든 글 보기