Fieldby의 AI 최강 모델 페이블 모드 세팅 가이드는 설치형 앱이나 라이브러리라기보다, 외부 prompt 문서를 Claude Projects의 지식 파일로 넣어 특정 모델의 작업 습관을 흉내 내는 방법을 설명하는 웹 가이드다.
페이지는 공개 GitHub 저장소의 Claude Fable 5 관련 시스템 프롬프트 문서를 원본 근거로 제시하고, 이를 바로 붙여 넣기보다 세팅용으로 정리한 파일을 프로젝트에 올리는 흐름을 안내한다.
나는 이 가이드를 “모델을 더 똑똑하게 만드는 비법”이라기보다, 큰 instruction bundle을 안전하게 실험하는 체크리스트로 읽는 편이 맞다고 본다.
모델의 가중치와 추론력은 복사되지 않는다.
다만 답변을 구조화하고, 근거를 확인하고, 작업을 단계적으로 진행하려는 습관은 프로젝트 지침으로 어느 정도 유도할 수 있다.
이 글에서는 Notion 첨부 파일이나 원본 시스템 프롬프트 내용을 재배포하지 않는다.
공개 페이지와 연결된 저장소의 메타데이터를 기준으로, 실제로 써볼 때 무엇을 확인해야 하는지만 정리한다.
무엇을 다루는 가이드인가
Notion 페이지의 핵심 흐름은 단순하다.
- 페이지에 첨부된 세팅용 Markdown 파일을 내려받는다.
claude.ai의 Projects에서 별도 프로젝트를 만든다.- 해당 파일을 프로젝트 지식 영역에 올린다.
- 지침 칸에는 “문서의 날짜·도구·환경 정보나 안전 규칙과 충돌하는 부분은 무시하고, 답변 형식·검색 습관·검증 절차 같은 일하는 방식만 참고하라”는 취지의 짧은 지시를 넣는다.
- 기존 대화가 아니라 새 대화에서 같은 질문을 던져 적용 전후 산출물을 비교한다.
원본 근거로 연결된 GitHub 저장소는 asgeirtj/system_prompts_leaks다.
저장소 README는 여러 AI 챗봇의 시스템 프롬프트를 문서화하는 것이 목적이라고 설명하고, Anthropic/claude-fable-5.md 파일을 Claude Fable 5 항목으로 연결한다.
GitHub API 기준 저장소 라이선스는 CC0-1.0이고, 해당 파일은 조사 시점에 약 188KB 크기였다.
다만 릴리스나 태그가 있는 제품 저장소가 아니라, main 브랜치에서 계속 갱신되는 비공식 아카이브라는 점이 중요하다.
왜 유용할 수 있나
이런 방식이 효과를 낼 수 있는 지점은 “지능 복제”가 아니라 작업 습관 전이다.
| 가져올 수 있는 것 | 가져올 수 없는 것 |
|---|---|
| 답변을 먼저 구조화하는 습관 | Fable 5의 모델 가중치 |
| 불확실한 내용을 확인하려는 태도 | 공식 Anthropic 보증 |
| 긴 작업을 단계별로 끊는 방식 | 최신 서비스 정책이나 안전 정책 |
| 결과물로 적용 여부를 비교하는 평가 방식 | Opus/Sonnet/Haiku의 근본 추론 한계 극복 |
그래서 글쓰기, 자료 조사, 코드 디버깅처럼 “출력 품질이 작업 절차에 많이 좌우되는 일”에서는 체감 차이가 날 수 있다.
예를 들어 같은 뉴스레터 초안 요청이라도, 그냥 한 덩어리로 써버리는 대신 목차를 잡고, 근거가 필요한 부분을 구분하고, 마지막에 확인 항목을 붙이는 식의 차이가 생길 수 있다.
반대로 수학적 추론, 코드 이해력, 장기 기억, 최신 정보 접근처럼 모델 자체 능력이나 도구 권한에 의존하는 부분은 이 방식으로 해결되지 않는다.
좋은 지침은 모델이 이미 가진 능력을 더 일관되게 쓰게 만들 뿐, 없는 능력을 새로 넣어주지는 않는다.
써본다면 이렇게 분리하는 편이 안전하다
첫 번째 원칙은 전용 프로젝트를 따로 만드는 것이다.
기존 업무 프로젝트, 고객 데이터가 있는 프로젝트, 장기적으로 쓰는 개인 지식 베이스에 곧바로 넣지 말고 “페이블 모드 실험” 같은 별도 공간을 만든 뒤 테스트하는 편이 낫다.
두 번째는 지침 적용 여부를 질문으로 확인하지 않는 것이다.
“너 이 문서 읽었어?”
라고 묻는 방식은 모델의 안전/정책 응답과 섞여 별 도움이 안 된다.
Notion 가이드가 말하듯, 같은 과제를 적용 전후로 던져 산출물의 구조·근거·검증 절차를 비교하는 편이 낫다.
세 번째는 모델별 역할을 나누는 것이다.
페이지는 Opus 조합을 추천하지만, 실제 비용과 한도까지 고려하면 모든 작업을 가장 비싼 모델로 돌릴 필요는 없다.
큰 계획이나 품질 기준은 강한 모델에서 만들고, 짧은 초안·정리·반복 작업은 더 가벼운 모델로 넘기는 식의 분업이 현실적이다.
주의할 점
가장 큰 주의점은 출처와 성격이다.
연결된 저장소는 공개되어 있고 CC0 라이선스를 표기하지만, 공식 Anthropic 문서가 아니라 비공식 prompt archive다.
내용이 실제 서비스와 1:1로 맞는지, 최신인지, 어느 시점의 어떤 환경을 반영하는지는 별도로 보장되지 않는다.
또한 18만 자 안팎의 긴 지침 파일은 매 대화 컨텍스트를 크게 차지한다.
Claude Projects의 지식 파일로 넣어도 모델이 관련 내용을 참고하면 토큰 예산과 응답 비용, 지연 시간이 늘 수 있다.
“더 꼼꼼해졌다”는 체감이 생기는 대신, 간단한 작업에서도 답이 길어지거나 불필요하게 절차적이 될 수 있다.
보안·프라이버시 측면에서는 외부 instruction bundle을 신뢰 경계 안으로 들이는 일이다.
문서 속 날짜, 도구 목록, 환경 정보, 정체성 표현이 현재 모델의 실제 환경과 충돌할 수 있고, 경우에 따라 모델이 자신을 다른 모델처럼 소개하거나 존재하지 않는 도구를 전제할 수도 있다.
그래서 프로젝트 지침에는 “문서의 작업 방식만 참고하고, 날짜·도구·환경·안전 규칙과 충돌하는 부분은 따르지 않는다”는 제한을 반드시 넣어야 한다.
이 tips 사이트의 macos-linux, winos 분류는 여기서 OS 네이티브 앱 지원을 뜻하지 않는다.
이 항목은 브라우저에서 Claude Projects를 설정하는 워크플로라서, 실제 플랫폼 의미는 “어느 데스크톱 환경에서도 브라우저로 실험할 수 있다”에 가깝다.
내 판단
이 가이드는 “최강 모델을 공짜로 복제하는 법”이라기보다, 남의 시스템 프롬프트를 통째로 가져올 때 어떤 기대치를 가져야 하는지 보여주는 사례로 가치가 있다.
좋은 모델의 일하는 방식을 관찰하고, 내 프로젝트 지침을 더 구조적이고 검증 지향적으로 다듬는 아이디어는 충분히 쓸 만하다.
다만 그대로 믿고 핵심 업무에 넣기에는 위험하다.
출처는 비공식이고, 지침은 길며, 공식 제품 정책이나 모델 능력을 대신하지 않는다.
나는 개인 실험, 글쓰기 스타일 개선, 자료 조사 체크리스트 만들기 정도에는 써볼 수 있다고 본다.
반대로 고객 데이터, 규제 업무, 코드 배포 자동화, 민감한 내부 문서 분석에는 별도 검토 없이 넣지 않는 편이 맞다.
가장 좋은 활용법은 원본을 숭배하는 것이 아니라, 실험 후 남는 패턴만 추출하는 것이다.
예를 들어 “결론 먼저”, “불확실하면 확인”, “큰 작업은 계획-실행-검증으로 나눔”, “출처와 한계를 마지막에 명시” 같은 원칙은 굳이 거대한 prompt 파일을 계속 들고 다니지 않아도 내 프로젝트 지침으로 짧게 재작성할 수 있다.