k-fable-opus-claude-md

2026-08-15
Fable 5 모델 제공 중단 전에 미리 야물딱지게 뽑아서 우리기 시작했고 지금도 우리고 있습니다.

시작하기 앞서 사실을 말합니다.

Fable 5 은 똑부러지게 작업합니다. 토큰과 비용을 먹으며 작업은 나누고 제대로 똑부러지게 하는 편입니다. 무엇보다 재미로도, 미학적으로도 깔끔합니다.
Opus 5 은 효과가 가장 좋습니다. 토큰 덜 먹고, 작업은 천천히 나눠서 합니다. 가끔 버그와 문제를 못 찾습니다.

GPT 5.6 Sol 은 확실하게 만들지만 토큰을 많이 먹고 작업은 천천히 합니다. 사용량이 먼저 오링납니다. 보통 Opus5 에서 못 고친걸 Sol 에게 외주주면 됩니다.
GPT 5.6 Terra 은 적당히 만들지만 토큰도 적당히 쓰고 작업은 느리게 오랫동안 합니다. 수십시간이 걸릴수도 있습니다. 어느 순간 삼천포에 빠지거나, 장기 작업에서 끝없는 블랙홀에 빨려들어갈수도 있습니다. 이도저도 아닌거죠.
GPT 5.6 Luna 은 조각조각 만들고, 토큰을 적게 먹고 천천히 이어 붙이고 오류를 수정해서 20% 확률로 작동합니다. 확률형 뽑기라고 생각하면 됩니다. 아무리 저렴하다고 하지만, 이걸 쓸 일은 별로 없을겁니다.

Gemini 3.7 Flash / 3.1 Pro 에서는 덜 멍청해집니다. 모델 성능은 어쩔수 없는거니까요. 멍청한 바보에게 아무리 좋은 교육과 선생님이 있어도 똑똑해질수는 없습니다. 이래도 Gemini를 사용하시겠나요?

Deepseek V4 Pro / Flash 그리고 GLM 5.1/5.2/5.3 등 중국산 LLM 에서는 사용을 추천하지 않습니다. 벤치맥싱으로 이루어진 SLOP 이니까요. 프로젝트를 철저히 복구 불가능하게 망치고 공든 탑을 무너트리고 싶으시면 사용하시면 됩니다.

위 구간은 2026-08-15 시점 작성자의 사용 경험담입니다. 이 저장소의 문서들은 이 의견을 근거로 쓰지 않았고, 모델별 사실은 아래 "근거 수준" 규칙에 따라 출처를 확인해서 썼습니다.

프로젝트 소개 (2026-11-03 개편)

기존에는 CLAUDE.md, AGENTS.md, GEMINI.md 3개만 있었습니다.
이제는 제공자 → 모델 → 분야 3단계 폴더로 나눠서, 모델마다 그 모델에 맞춘 지침 문서를 둡니다.

<제공자>/<모델>/<분야>.md      예) claude/opus-5.5/firmware.md

한국어로 대답하고, 복명복창으로 시작하고, 비판적으로 따지고, 작게 고치고, 검증하고,
검증 못 한 건 솔직히 말하고, 라이선스·저작권·특허·출처를 침해하지 않게 만드는 세팅입니다.

오래 보고, 깊게 보고, 한국어로 일하게 만들기 위한 모델별 지침 문서 모음

미리 말씀드리지만 기대하지 마십쇼.
마법의 요술봉 그런 것 아닙니다.
뭐든지 다 되는 그런 것도 아닙니다.
사용했다가 프로젝트가 박살나도 모릅니다.

폴더 구조

.
├── _shared/
│   ├── contract.md          # 모든 문서 공통 계약 (정본)
│   └── domains/             # 분야 규칙 정본 9종
├── scripts/docs_tool.py     # 공통 블록 주입(sync) / 구조 검사(check)
├── gpt/        gpt-6-astra · gpt-6.1-sol · gpt-6.1-terra · gpt-6-luna
├── claude/     fable-5.1 · fable-5.5(미출시) · opus-5.5 · sonnet-5.5 · haiku-5.5
├── gemini/     gemini-4-argon · gemini-4-carbon(미출시) · gemini-3.8-flash
├── gemma/      gemma-4-e2b · gemma-4-e4b · gemma-4-12b · gemma-4-26b-a4b · gemma-4-31b   (로컬용)
├── deepseek/   v4.1-flash-1017
├── glm/        glm-5.3 · glm-5.3-flash · glm-5.5(미출시)
├── muse/       muse-spark · muse-wonder
├── grok/       grok-4.7 · grok-4.8(미출시) · grok-5(미출시)
├── kimi/       kimi-k3.1
├── qwen/       qwen3.8-max · qwen3.8-2.4t-a95b · qwen3.8-27b · qwen3.7-max · qwen3.6-27b · qwen3.6-35b-a3b
└── minimax/    minimax-m3 · minimax-m3.1-flash

제공자 11곳, 모델 폴더 35개, 모델 폴더마다 분야 문서 9개이므로 문서는 모두 315개입니다.
gemma/와 qwen3.8-27b·qwen3.6-*처럼 로컬로 돌리는 모델은 메모리, 양자화, 런타임, 가중치 라이선스 확인 규칙이 문서에 따로 들어 있습니다.

모델 폴더마다 분야 문서 9개가 있습니다.

파일	분야
`general.md`	범용 (모델 특성 전체 + 일반 개발 규칙)
`web.md`	웹 프런트엔드·백엔드
`app.md`	모바일 앱 (iOS·Android·크로스플랫폼)
`native.md`	네이티브 프로그램 (데스크톱·CLI·시스템 SW)
`hardware.md`	회로·PCB·HDL
`firmware.md`	MCU·RTOS·부트로더·OTA
`web-research.md`	웹 리서치 (사실 확인·출처 수집)
`research.md`	학술·과학 연구
`tech-research.md`	기술 선정·타당성·라이선스·특허 조사

미출시(미출시 표기) 폴더는 공식 발표 전이라 스펙을 쓰지 않았습니다. 직전 세대 규칙을 잠정 적용하고, 출시 당일 확인할 항목만 담았습니다.

문서 한 개의 구성

절	내용	작성 방식
0, 1	응답 계약 (복명복창 → 5항목 보고 → 한국어), 작업 원칙 (비판적 검토, 재귀 개선 루프, 정직성, God-object 방지, 라이선스·저작권·특허·출처, 범위·안전)	`_shared/contract.md`에서 주입
2	이 모델의 특성 또는 이 모델의 해당 분야 운용	모델마다 직접 작성
3	분야 규칙, 시점에 민감한 사실 표, 검증 순서, 금지	`_shared/domains/<분야>.md`에서 주입
4	근거와 한계 (출처 URL, 확인 수준)	모델마다 직접 작성

공통 블록은 정본 한 곳에서 고치고 sync로 퍼뜨립니다. 문서 315개에서 같은 규칙이 조금씩 달라지는 걸 막기 위해서입니다. 모델별 내용(2, 4절)은 전부 따로 씁니다.

근거 수준

문서의 모든 사실에는 근거 수준을 붙였습니다.

[확인] 공식 1차 출처(공식 문서, 벤더가 운영하는 저장소)를 이 작업에서 직접 읽음
[부분] 공식 도메인 검색 스니펫이나 2차 출처(뉴스, 집계, 블로그)로만 확인
[미확인] 출처가 충돌하거나 루머, 또는 확인 못 함

작성 환경에서 openai.com, ai.google.dev, huggingface.co 같은 호스트는 열리지 않았습니다.
그래서 해당 제공자의 모델 사양은 [부분]인 경우가 많습니다. ID, 가격, 날짜는 쓰기 전에 공식 문서로 다시 확인하세요.

이게 뭔가요?

각 문서는 AI가 다음처럼 행동하도록 유도합니다.

첫 마디부터 복명복창
프롬프트 던지자마자 첫 출력을 사용자가 시킨 일 요약·확인부터 하고 시작합니다. 군대처럼 확실하게 알아먹었는지 확인하고 일 시키는 주인장의 군인 시절 습관이 들어갔습니다.
LLM에게 복명복창을 시키는 진짜 이유는 요구사항을 컨텍스트에 확실하게 주입해서, 모델이 혼자만의 헛된 추론이나 망상, 자의적인 추측과 가설을 펼치지 못하게 꽉 틀어쥐기 위함입니다.
끝은 5항목 보고
변경 요약 / 수정 파일 / 실행한 명령 / 검증 결과 / 남은 리스크. 실행 안 한 검증은 "미실행"이라고 써야 합니다.
비판적으로 작업
요청도, 기존 코드도, 자기 계획도, 검색 결과도 의심합니다. 벤더 벤치마크는 주장으로만 취급합니다.
한국어 존댓말로 답변
(한국인은 예의가 최우선이니까요.)
작게 고치고 검증하는 재귀 루프
읽고, 가설 하나, 최소 변경, 최소 검증, 실패하면 원인부터 다시. 무거운 전체 검증은 마지막에 한 번.
검증 안 한 건 성공이라고 안 하고, 불확실한 건 단정 안 함
[확인] / [부분] / [미확인]으로 구분해서 말하게 합니다.
God Object 방지 및 500줄 룰
특별한 이유 없으면 파일 하나 500줄 넘기지 말 것.
그냥 줄 수만 쪼개는 꼼수 쓰지 말고, 폴더랑 파일 딱딱 나눠서 인간이 유지보수 가능하게 만들 것.
라이선스·저작권·특허·출처 침해 금지
가져오기 전에 라이선스 확인, 출처 표기, 특허는 존속 여부 확인(법률 자문은 아님), 출처·인용 날조 금지.
필요한 곳만 손대는 정밀 수정, 시크릿·위험 명령 보호
(+ 컴퓨터를 개작살내면 안 되니까요.)

사용법

쓰는 모델의 폴더에서 분야에 맞는 문서를 고릅니다. 모르겠으면 general.md입니다.
프로젝트 루트에 쓰는 도구가 읽는 이름으로 복사합니다.

도구	복사할 이름	근거
Claude Code	`CLAUDE.md` (또는 `AGENTS.md`)	[확인] Claude Code 메모리 문서: `AGENTS.md`도 대체로 읽음
Codex	`AGENTS.md`	[부분]
Antigravity CLI	`AGENTS.md`	[부분] `GEMINI.md`는 하위 호환이며 `AGENTS.md`로 개명 권장이라는 안내가 있음
Gemini CLI	`GEMINI.md`	[확인] 다만 README에서 Gemini 4 이후는 최적화 대상이 아니라고 밝힘
Kimi Code, Qwen Code, Grok Build, DeepSeek Harness	`AGENTS.md`	[미확인] 도구별 로딩 규칙을 각자 확인

cp claude/opus-5.5/general.md /path/to/your/project/CLAUDE.md
cp gpt/gpt-6-astra/firmware.md /path/to/your/project/AGENTS.md

혹시나 노파심에 말씀드리지만 /path/to/your/project/이란 경로는 없습니다.
여러분의 실제 프로젝트 경로에 넣길 바랍니다.

여러 분야에 걸치면 general.md를 기본으로 두고, 해당 분야 문서의 ## 3. 분야 규칙 부분만 이어 붙이세요.

이 문서들은 AI에게 주는 컨텍스트이지 강제 설정이 아닙니다. 반드시 막아야 하는 동작(예: rm -rf, 강제 푸시, 비밀 파일 읽기)은 도구의 권한·훅 설정으로도 막으세요.

Claude Code에서 메모리 로드 상태를 확인합니다.

/memory

정상이라면 대략 이런 식으로 보입니다.

Project memory           Saved in ./CLAUDE.md
User memory              Saved in ~/.claude/CLAUDE.md

문서를 고칠 때

공통 규칙은 _shared/만 고치고 반영합니다. 개별 문서의 공통 블록을 직접 고치지 마세요.

python3 -I scripts/docs_tool.py sync              # 정본 → 각 문서 주입
python3 -I scripts/docs_tool.py check --complete  # 구조·한도·누락 검사

check가 보는 것: 공통 블록이 정본과 같은지, 파일당 500줄 이하인지, 필수 절과 출처 URL이 있는지, 모델 폴더마다 분야 문서 9개가 다 있는지.
이 검사는 형식만 봅니다. 내용이 사실인지는 사람이 출처로 확인해야 합니다.

참고한 공개 프로젝트

문장을 가져오지 않고 구조와 패턴만 참고했습니다.

google-gemini/gemini-cli GEMINI.md: 무거운 검증은 마지막에, 조건부 규칙, 규칙에 이유 병기
langchain-ai/langchain AGENTS.md: 공개 API 보존, 모델 ID는 공식 문서로 확인, 코드가 소스 오브 트루스
vercel/next.js AGENTS.md: 단계적 공개, 출력 1회 캡처 후 분석, 비밀 취급
microsoft/vscode .github/copilot-instructions.md: 비례 검증, 계층 규칙
MoonshotAI/kimi-code AGENTS.md: 루트에는 핵심 규칙만, 심각도 구분
agentsmd/agents.md: AGENTS.md 형식
Claude Code 메모리 문서: 지침은 컨텍스트, 강제는 훅

핵심 철학

이 파일들의 목적은 LLM을 “똑똑한 척하는 말 많은 도구”가 아니라
정확히 복명복창하고, 코드 먼저 읽고, 비판적으로 따지고, 작게 고치고, 검증하고, 정직하게 보고하는 작업자처럼 굴리게 만드는 것입니다.

원칙은 단순합니다.

복명복창 → 읽고 → 작게 고치고 → 검증(실패 시 재수정) → 솔직히 보고한다

주의사항

이 문서들은 만능 부적이 아닙니다.

프로젝트 구조, 권한 설정, 모델 상태, 사용자의 지시 방식에 따라 결과는 달라질 수 있습니다.

사용했다가 프로젝트가 박살나도 모릅니다.
그건 당연히 어쩔 수 없는 설정 파일 탓도, 신 탓도 아닌
99% 확률로 어쩔 수 없는 모델의 멍청함과
이상한 AI 관련 덕지덕지 붙은 플러그인의 영향입니다.
아니면 1%의 사용자 입력 프롬프트 탓입니다.

하네스 엔지니어링
프롬프트 엔지니어링
멀티 에이전트
루프 에이전트

등... 여러 기반으로 제대로 만들어지지 않은 AI Slop, AI 쓰레기와
Tokenmaxxing, 토큰 낭비 문화 속에서 만들어진 이상한 것들을 사용하는 것보다는

**인간 중심 판단(Human-in-the-loop)**을 생각합시다.
사람이 판단하면 무엇보다 판단 비용은 0원 이니까요.

각각의 기술론에 대해서는 당연히 AI 발전 속에서 생겨난 방향성을 가진 기술이자 한 가지의 방법론이라고 생각합니다.

덮어놓고 쓰다 보면 거지꼴을 못 면합니다.
AI는 신도 아니며 완벽하지도 않습니다.

당연한 이야기로,
중요한 프로젝트에서는 반드시 Git 상태를 확인하고, 백업하거나 브랜치를 나눈 뒤 사용하십시오.

git status --short
git switch -c 내-플젝명

단, 오래된 Git 환경이라면(거의 없겠지만) checkout -b가 호환성은 더 좋습니다.

라이선스

MIT 라이선스 (MIT License).

가져다 쓰고, 고치고, 자기 프로젝트에 박아도 됩니다.
다시 한번 말씀드리지만 기대하지 마십쇼.
마법의 요술봉 그런 것 아닙니다.
뭐든지 다 되는 그런 것도 아닙니다.
사용했다가 프로젝트가 박살나도 모릅니다.