• 경량 모델이나 저비용 모델에서는, 상세한 규칙, 기억 검색, 리뷰 강제, 절차화된 skill(기술)은 상당히 효과적이다. - 하지만 고성능 모델에서는, 그러한 보조 장치들이 고성능 모델 Fable의 「탐색·사고의 자유도」를 낮추고, 오래된 지식이나 과도한 절차에 끌려가게 만들 수 있다. - 이번에 사용자 레벨의 AI 설정을 정리해 본 결과, ~/.agents를 기점으로 Claude / Codex / Gemini에게 공통 규칙을 배포하는 구성으로 되어 있었다. - 유용했던 설계는 **「기억을 외부화하는 것」**이었지만, 문제가 될 수 있는 것은 **「항상 상기시키는 것」**이었다. - 고성능 모델을 위해서는 상시 주입이 아니라, 단계적 로드, 필요 시 recall(회상), 근거 우선, 설정의 경량 모드가 필요하다. - 2026년의 AGENTS.md 평가 연구에서도, 리포지토리 문맥 파일은 일반적으로 성공률을 개선하지 않으며, 추론 비용을 평균 20% 이상 증가시킨다고 보고되었다. - 즉, 문제는 「설정 파일이 나쁘다」가 아니라, **「always-on(항상 켜져 있는) 문맥을 너무 많이 늘리면, 똑똑한 모델일수록 너무 성실하게 따른다」**는 점에 있다. - 게다가 Fable과 같은 고성능 모델을 상시 사용하면 사용량이 먼저 고갈되기 때문에, Sonnet / Opus로 적절히 위임하는 **「모델 예산 설계」**도 필요하다.

그림의 이미지는 「모든 것이 들어있는 친절한 설정이, 지금 읽어야 할 코드를 보기 어렵게 만들고 있는」 상태다. 특정 애니메이션 작품이나 밈 그 자체가 아니라, 일본 애니메이션풍의 비유로서 생성했다.

AI 코딩 에이전트를 오래 사용하다 보면, 처음에는 「더 기억해 주었으면 좋겠다」, 「매번 같은 주의사항을 지켜주었으면 좋겠다」라고 느끼게 된다. 그래서 글로벌 규칙(global rule), memory(기억), skill(기술), hook(훅), 외부 DB, 리뷰용 wrapper(래퍼) 등을 정비하게 되고, 우선순위가 없는 정보가 늘어간다.

이는 경량 모델이나 저비용 모델에는 매우 효과적이다. 모델이 잊어버리기 쉬운 것, 판단이 흔들리기 쉬운 것, 절차를 생략하기 쉬운 것을 외부 설정을 통해 보완할 수 있기 때문이다.

반면, 고성능 모델을 사용하면 관점이 달라진다. 모델 스스로가 충분히 독해·탐색·설계 판단을 할 수 있는 경우, 과거에 만들었던 「보조 바퀴」가 오히려 판단을 좁히는 원인이 될 수 있다.

이 기사에서는 실제 사용자 레벨의 AI 설정을 정리하면서, 왜 「똑똑한 모델일수록 기존의 지식이나 superpower(초능력)적인 설정이 방해가 되는 경우가 있는지」를 정리한다.

이 기사에서 가장 하고 싶은 말: 설정을 버리자는 이야기가 아니다. 상시 전달하는 정보를 줄이고, 필요한 때에만 가져오게 하는 설계로 바꾸자는 '정리(棚卸し)'의 권고다.

여기서 말하는 고성능 모델에는 미래의 모델이나, 이 기사를 작성하는 시점에 일부 환경에서만 사용되고 있는 모델도 포함한다. 특정 모델의 벤치마크 비교가 아니라, 에이전트 설정 설계에 관한 이야기로 다룬다.

이 기사는 개인의 WSL 환경을 정리하는 것에서 출발하지만, 문제의식 자체는 상당히 일반화되어 가고 있다.

2026년 7월 시점에서, 주요 AI 코딩 에이전트는 「영구적인 규칙」, 「프로젝트 문맥(context)」, 「memory」, 「skill」, 「hook」을 갖는 방향으로 나아가고 있다.

• Claude Code는 CLAUDE.md와 auto memory를 세션 시작 시에 읽어들이는 메커니즘을 공식 docs에서 설명하고 있다. 다만 동일한 docs에서는, CLAUDE.md와 memory는 강제 설정이 아니라 context(문맥)로 취급된다는 점, 지시는 구체적이고 간결할수록 잘 따라진다는 점, 여러 단계의 절차나 일부 영역에만 관계하는 내용은 skill이나 path-scoped rule로 옮기는 것도 제시하고 있다.

참고: How Claude remembers your project - Claude Code의 skill docs에서는, CLAUDE.md와 달리 skill 본체는 사용할 때만 로드되기 때문에, 긴 참조 자료를 상시 context에 둘 필요가 없다고 설명되어 있다.

참고: Extend Claude with skills - Claude Code hooks는 세션 시작, turn(턴) 마다, tool call(도구 호출) 마다 등의 lifecycle(생명주기)에서 자동 실행할 수 있다. 이는 안전 제어에는 강력하지만, 사용 방식에 따라 매번 context에 개입하는 측면도 있다.

참고: Hooks reference - Codex는 ~/.codex/AGENTS.md에 글로벌한 작업 합의를 작성하고, 리포지토리나 서브 디렉토리의 AGENTS.md / AGENTS.override.md

공식 docs에서는 이를 AGENTS.md와 겹쳐서 설계하는 방식을 설명하고 있다. 기본적으로 합산 사이즈에도 상한이 존재한다.

참고: Custom instructions with AGENTS.md - Codex - AGENTS.md는 README와는 별개로 AI 코딩 에이전트 (AI coding agent)를 위한 지시사항을 작성하기 위한 오픈 포맷으로 확산되고 있으며, 공식 사이트에서는 60k를 초과하는 오픈 소스 프로젝트 (open-source project)에서 사용되고 있다고 설명한다.

참고: AGENTS.md - Anthropic은 컨텍스트 엔지니어링 (context engineering)을 시스템 인스트럭션 (system instructions), 도구 (tools), MCP, 외부 데이터, 이력 등 모델에 전달되는 토큰 (token) 전체를 관리하는 문제로 정리하고 있다.

참고: Effective context engineering for AI agents

그리고 단순히 "긴 컨텍스트 (context)는 비용이 높다"는 점뿐만 아니라, 품질에도 영향을 미친다.

Lost in the Middle

은 긴 컨텍스트 내 관련 정보의 위치에 따라 성능이 크게 저하된다는 것, 특히 중앙 부근의 정보를 안정적으로 사용할 수 없다는 것을 보여주었다.

참고: Lost in the Middle: How Language Models Use Long Contexts - Chroma의
Context Rot

은 입력 길이 자체를 늘리는 것만으로도 성능이 떨어진다는 것을 통제된 조건의 실험을 통해 보여주었다.

참고: Context Rot: How Increasing Input Tokens Impacts LLM Performance - 2026년 2월 제출, 6월 개정된
Evaluating AGENTS.md

는 AGENTS.md와 같은 리포지토리 레벨 컨텍스트 파일 (repository-level context file)을 여러 코딩 에이전트 (coding agent) / LLM으로 평가하였으며, "일반적으로 성공률을 개선하지 못하며, 추론 비용 (inference cost)을 평균 20% 이상 증가시킨다"고 보고했다. 중요한 점은 에이전트가 지시사항을 무시한 것이 아니라, 지시사항으로 인해 탐색이나 테스트가 확장되어 태스크 (task)가 무거워지는 경향이 관측되었다는 점이다.

참고: Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents? - Anthropic의 공개 정보에 따르면, Claude Fable 5는 claude-fable-5로서 API 이용이 가능하며, 가격은 입력 $10 / MTok, 출력 $50 / MTok으로 책정되어 있다. 또한 2026년 7월 1일 안내에 따르면, Pro / Max / Team / 일부 Enterprise에서는 2026년 7월 7일까지 주간 사용 한도의 50%까지 포함되며, 그 이후에는 사용 크레딧 (usage credits)으로 이용하는 방식이 된다고 설명되어 있다.

참고: Claude Fable 5 and Claude Mythos 5 - Anthropic / Redeploying Claude Fable 5 - Anthropic

이 외부 정보로부터 알 수 있는 것은, "설정 파일을 작성하지 마라"가 아니라는 점이다. 오히려 반대로 설정 파일, 메모리 (memory), 스킬 (skill), 훅 (hook)은 실무상 상당히 중요해지고 있다.

다만, 항상 켜져 있는 (always-on) 정보와 필요할 때만 호출하는 정보를 분리하지 않으면, 에이전트는 오래된 전제나 과도한 절차까지 성실하게 처리해 버린다. 마찬가지로, 상시 사용하는 모델과 필요할 때만 호출하는 모델도 분리하지 않으면, 고성능 모델의 이용 한도나 과금 한도를 먼저 다 써버리게 된다.

• 점검한 설정
• 현행 구성
• 왜 이 구성이 유용했는가
• 공개 정보에서 보는 동일한 문제 의식
• 고성능 모델에서 무엇이 역효과를 내는가
• 문제는 "지식"이 아니라 "주입 타이밍"
• 개선 방침
• 요약

이번에 확인한 것은 사용자 환경에 놓여 있는 AI 에이전트용 설정군이다.

대상	역할	기사 내 취급
~/.agents/	Claude / Codex / Gemini 공통 규칙 원본	구성만 설명
~/.agents/rules/*.md	core, memory, QA, account, Google Drive, 운영 규칙	내용을 추상화하여 소개
~/.agents/bin/*	공유 메모리, 리뷰, 동기화, Drive 조작용 helper	명령어 이름만 소개
~/.agents/generated/*	Claude / Gemini용 생성 파일	생성 방침만 소개
~/.codex/skills/*	Codex용 skill	종류만 소개
~/.claude/CLAUDE.md	Claude 고유의 강력한 글로벌 규약	공개 가능한 설계만 소개
~/.claude/settings.json	Claude의 모델, hook, plugin 설정	비밀 값을 포함하지 않는 범위에서 소개
~/.claude/hooks/*	session start / compact / stop / end 자동 주입	동작만 소개
~/workspace/.agents	workspace 측의 공유 설정	이번에는 해당 파일 없음

인증 정보, 계정명, 고객명, 내부 프로젝트 고유명사, 클라우드 계정 ID 등은 기사화하지 않는다. 공개 기사에서는 "무엇을 설정하고 있는가"가 아니라, "어떤 종류의 발판(scaffold)이 모델의 판단에 영향을 미치는가"에 집중한다.

현행 구성은 대략 다음과 같다.

~/.agents/
rules/
core.md
...

설계 사상은 명확하다. 각 AI 도구에 별도의 규칙을 쓰는 것이 아니라, ~/.agents/rules를 원본으로 하여 Claude, Codex, Gemini용으로 생성한다는 구성이다.

이는 상당히 합리적인 구성이었다. 여러 AI를 전환하더라도 최소한의 행동 규범, 기억 검색, 리뷰 방침, 계정 확인, Google Drive 조작 방침을 공유할 수 있다.

설정을 기능별로 보면 다음과 같은 것들이 들어 있었다.

분류	내용
기본 행동	기존 문맥 읽기, 검증 가능한 성과로 변환하기, 최소 검증 수행, 불필요한 되돌리기 하지 않기
...

Claude 측에는 더욱 강력한 규약이 있다. 예를 들어, 작업 전 SurrealDB recall, Gemini 합의, 명령을 검증 가능한 목표로 변환하는 규칙, 상위 모델을 PM, 하위 모델을 Worker로 사용하는 규칙 등이다.

이 구성은 "AI를 팀 멤버처럼 다루기" 위해 만들어졌다. 잊지 않기, 멋대로 위험한 조작 하지 않기, 같은 실수를 반복하지 않기, 과거의 판단을 참조하기. 실무상의 고충에서 탄생한 설정이다.

경량 모델이나 저비용 모델에서는 이러한 종류의 설정이 상당히 유용하다.

이유는 단순하다. 경량 모델은 다음과 같은 약점을 갖기 쉽기 때문이다.

• 작업 전에 과거 문맥을 찾지 않음
• 즉시 일반론으로 도피함
• 이전의 판단과 모순되는 제안을 함
• 실패 로그에서 배우지 않고, 같은 수정을 반복함
• 중요한 검증을 생략함
• issue나 PR에 모호한 문장을 쓰기 쉬움
• 도구나 계정 전환을 잊어버림

이러한 약점에 대해 설정 파일은 외골격(exoskeleton)으로서 작동한다.

예를 들어, SurrealDB recall은 "과거의 판단을 찾아라"라는 습관을 모델의 외부에 둔다. Gemini review는 "자신의 판단을 한 번 의심하라"라는 프로세스를 외부에 둔다. hook은 "긴 세션에서 중요한 규칙을 잊어버린다"라는 문제에 대해 정기적으로 규칙을 재주입한다.

즉, 저~중성능 모델에게 설정 파일은 **능력 부족을 보완하는 실무적인 scaffold (발판)**였다.

이 방향은 공개된 실천 지식과도 일치한다.

예를 들어 Claude Code 공식 docs는 같은 실수를 반복하거나, 코드 리뷰에서 지적받거나, 매번 같은 설명을 해야 하는 경우에 CLAUDE.md에 작성할 것을 권장하고 있다. Cursor rules의 해설 기사에서도 always, auto attached, agent requested, manual과 같이 규칙을 적용 타이밍에 따라 나누는 운용법이 소개되고 있다. X에서도 2026년에 들어서며 AGENTS.md 평가 논문에 대한 반응이나, 너무 긴 CLAUDE.md...

를 줄이는 이야기, user-level CLAUDE.md를 통해 조사나 코드베이스 탐색을 별도의 agent에게 넘기는 이야기가 지속적으로 흘러나오고 있다.

유사한 문제 의식을 담은 공개 게시물 및 기사:

• Sebastian Raschka의 AGENTS.md 평가 논문 언급
• DAIR.AI / Omar Sanseviero의 AGENTS.md 평가 논문 소개
• 긴 CLAUDE.md가 instruction following (지시 이행)을 악화시킨다는 X article
• Cursor rules를 always-on / auto-attached / agent-requested로 나누는 실전 게시물
• Cursor Rules의 Always / Auto Attached / Agent Requested / Manual을 설명하는 Trigger.dev 기사

이것들은 동료 검토(peer-reviewed)를 거친 연구가 아니므로, 이 글에서는 "증거"가 아닌 "현장의 관측 사례"로 다룬다. 강력한 근거로는 공식 docs와 논문을 사용하고, X나 Reddit은 실무자들의 고민이 어디에 모여 있는지를 확인하는 자료로만 제한한다.

그런데 고성능 모델에서는 동일한 설정이 다른 동작을 보인다.

모델 스스로가 충분히 읽고, 생각하고, 탐색하며, 과거 문맥과의 거리를 판단할 수 있는 경우, 외부의 규칙은 "조언"이 아니라 "선입견"이 된다.

AGENTS.md 평가 연구의 결과는 이러한 직관과 상당히 잘 맞아떨어진다. 실패의 형태는 "에이전트가 규칙을 무시한다"가 아니라, "규칙을 읽은 결과, 탐색·테스트·tool use (도구 사용)가 확장되어 태스크 해결까지의 경로가 무거워진다" 였다. 고성능 모델일수록 조잡한 규칙을 무시해준다는 보장은 없다. 오히려 강력한 instruction follower로서, 불필요한 제약까지 성실하게 충족하려 한다.

[요약]: 고성능 모델에서는 규칙이 "지켜지지 않는 것"보다, 불필요한 규칙까지 너무 잘 지켜지는 것이 문제가 된다.

이번 점검에서 특히 역효과를 낼 수 있다고 느낀 점은 다음과 같다.

과거의 지식을 검색하는 것 자체는 좋다. 하지만 매번 recall (회상)하게 되면, 모델은 현재의 코드나 사양보다 과거의 기록을 우선시하기 쉽다.

과거의 지식은 당시의 제약, 당시의 모델 성능, 당시의 구현 상태에 의존하고 있다. 고성능 모델이라면 현재의 소스를 읽어 더 나은 설계에 도달할 수 있는 상황에서도, 오래된 knowledge (지식)가 강력한 초기값이 되어버린다.

기억은 편리하지만, 기억은 현재의 증거가 아니다. 이 지점이 recall 설계의 분기점이 된다.

이 점은 긴 context (문맥) 연구와도 연결된다. 긴 context window가 있더라도 모델이 모든 정보를 동일한 가중치로 안정적으로 사용한다는 보장은 없다. 오래된 memory (기억)가 서두나 반복적으로 주입되는 위치에 놓이면, 현재의 파일보다 더 강한 신호로 취급될 가능성이 있다.

이 그림에서 말하는 사슬이 달린 오래된 카드가 과거의 knowledge나 실패 로그다. 유용하지만, 현재의 코드보다 강하게 보이면 판단을 왜곡하게 된다.

skill (기술)이나 superpower (초능력)는 특정 실패를 방지하기 위해 만들어진다. 예를 들어 "API와 프론트엔드의 정합성을 확인할 때는 이 순서로 읽는다"라거나 "Issue를 만들기 전에 리뷰한다"와 같은 절차다.

이는 초보자나 경량 모델에게는 강력한 힘을 발휘한다. 하지만 고성능 모델에서는 태스크의 형태에 따라 더 짧은 경로가 필요하거나, 반대로 더 넓은 조사가 필요할 때가 있다.

고정된 절차가 너무 강하면 모델은 **"이 태스크가 정말 그 절차대로 진행되는 것이 맞는가"**를 고민하기도 전에 절차를 그대로 따라간다.

공식 docs 관점에서도, 여러 단계의 절차는 상시 로드되는 memory가 아니라 필요할 때 로드되는 skill로 넘기는 것이 자연스럽다. 즉, "절차를 갖지 마라"가 아니라 "절차를 상시 prompt (프롬프트)에 섞지 마라"는 이야기다.

고정된 레일에 태우는 것이 아니라, 분기점에서 확인하는 관점 리스트로 사용하는 것. 고성능 모델에게는 이러한 거리감이 더 적합하다.

Gemini review는 실용적이었다. 특히 issue 문구, 설계 리뷰, 동일한 에러의 반복 상황에서는 효과가 있다.

다만 고성능 모델이 이미 충분한 근거를 수집하고 있는 경우, 매번 수행하는 제3자 리뷰는 마찰(friction)이 된다. 게다가 리뷰를 담당하는 모델이 대상 모델보다 성능이 낮을 경우, 리뷰는 품질 향상이 아니라 노이즈 추가가 될 수 있다.

"다른 모델에게 묻는 것"이 항상 좋은 것은 아니다. 리뷰 대상의 능력, 컨텍스트 양, 대상 영역에 대한 이해도가 낮다면 오히려 판단을 흐리게 만든다.

과거의 설정에서는 "상위 모델 = PM, 하위 모델 = Worker"라는 역할 분담이 정의되어 있었다.

그것은 당시에는 합리적이었다. 높은 성능의 모델에게 판단을 맡기고, 저렴한 모델에게 탐색이나 구현을 맡기는 방식 말이다.

하지만 더욱 고성능인 모델이 등장하면서 이 전제는 무너진다. 고성능 모델이 직접 탐색·구현·리뷰까지 일관되게 수행하는 것이 분업보다 품질이 더 높을 때가 있기 때문이다. 반대로 하위 모델에게 위임함으로써 중요한 뉘앙스가 누락될 수도 있다.

모델 운용 규칙은 모델 성능의 진화와 함께 진부화된다. 이 부분 또한 정기적인 점검(Inventory) 대상이 되어야 한다.

Claude 측에는 session start, pre-compact, stop, session end의 hook이 있다. 세션 시작 시에 최근의 지견을 제시하고, compact 전에는 중요 정보를 재주입하며, 일정 횟수마다 중요 규칙을 상기시킨다.

이는 '긴 대화에서 규칙을 잊어버리는' 문제에 대한 대책이었다.

다만 고성능 모델에서는 매번 동일한 행동 규범이 들어감으로써, 컨텍스트 내의 신호 대 잡음비(Signal-to-Noise Ratio)가 낮아진다. 모델은 본래 읽어야 할 현재의 파일, 사용자의 최신 의도, 실행 결과보다 반복적으로 주입되는 오래된 규칙에 주의를 빼앗길 가능성이 있다.

hook은 포맷, 테스트, 위험 작업 차단, 알림과 같은 결정적인 제어에는 적합하다. 반면, 판단을 동반하는 '상기'나 '조언'을 hook을 통해 매번 주입할 경우에는 모델의 작업 context를 오염시키고 있지는 않은지 관찰하는 것이 좋다.

리뷰도 hook도 나쁜 것은 아니다. 다만, 지금 봐야 할 증거 주변에 알림이 너무 많아지면 모델은 '무엇이 가장 중요한가'를 놓치기 쉬워진다.

이번 깨달음은 외부 지식이나 설정 파일이 불필요하다는 뜻이 아니다.

오히려 반대로, AI 에이전트에게는 외부 지식이 필요하다. 특히 다음 정보들은 모델 내부에만 가두어 두지 않는 것이 좋다.

• 과거의 설계 판단
• 실패와 재발 방지책
• 프로젝트 고유의 제약 사항
• 계정이나 환경 전환 절차
• 공개 전 기밀 체크
• 리뷰 이력
• 운용상의 약속

문제는 그것을 언제, 얼마나, 어느 정도의 강도로 모델에게 전달할 것인가이다.

저성능 모델에는 처음부터 넉넉히 전달하는 편이 안정적이다. 고성능 모델에는 처음에는 적게 전달하고, 필요할 때 스스로 가져가게 하는 편이 좋다.

즉, 설계(Setting Design)는 모델 성능에 따라 바꾸어야 한다.

이 밈(Meme)이 말하는 '적당한 정도'가 이 글의 결론에 가깝다. AI 에이전트 설정은 너무 적으면 매번 똑같은 실수를 반복한다. 너무 많으면 현재의 증거보다 과거의 규칙이 더 강해진다. 고성능 모델을 위해서는 모든 것을 다 담는 것이 아니라, 필요할 때 꺼내 쓸 수 있을 정도의 양이 적당하다.

고성능 모델을 위해서는 다음과 같은 설계가 좋아 보인다.

모든 규칙을 처음부터 읽게 하는 것이 아니라, 처음에 전달하는 것은 얇은 원칙(Thin principles)만으로 제한한다.

선반에 모든 것이 있는 것은 좋다. 문제는 작업 시작 시에 선반 전체를 책상 위에 올려놓는 것이다. 고성능 모델에게는 우선 얇게 시작하여 필요한 상자만 꺼내 쓰게 한다.

Level 0: 최소 원칙
- 기존 변경 사항을 망가뜨리지 않는다
- 비밀을 누설하지 않는다
...

고성능 모델에게는 처음부터 Level 2까지 쌓아두지 않는 것이 좋다. 우선 Level 0 / Level 1만으로 충분한지 확인한다.

현행 설정에서는 비자명한(Non-trivial) 작업 전에 recall(상기)하도록 설계되어 있다. 이는 안전하지만 무겁다.

고성능 모델을 위해서는 다음과 같이 바꾸고 싶다.

기존	신규
비자명한 작업 시 반드시 recall	과거 판단이 결과에 영향을 미칠 경우 recall
...

이것만으로도 오래된 지견에 대한 앵커(Anchor)를 상당히 줄일 수 있다.

제3자 리뷰는 유효하지만, 항상 호출해야 하는 것은 아니다.

기준으로는 다음 조건을 만족할 때 호출한다.

• 공개될 issue / PR / 기사 등, 되돌리는 비용(Rollback cost)이 높은 경우
• 보안, 과금, 데이터 파괴, 공개 동작과 관련된 경우
• 동일한 에러를 반복하고 있는 경우
• 자신보다 강력하거나, 혹은 다른 전문 영역을 가진 모델에게 물어볼 수 있는 경우
• 리뷰 대상을 충분히 짧고 자기 완결적(Self-contained)으로 만들 수 있는 경우

반대로 현재 모델이 충분히 강력하고 로컬 증거도 갖춰져 있다면, 리뷰보다 실기 검증(Real-device verification)을 우선한다.

skill이나 superpower는 실행 순서를 고정하기보다, 마지막에 누락을 확인하는 체크리스트로서 사용할 때 고성능 모델에 더 잘 맞는다.

예를 들어 API 정합성 체크라면, 처음부터 '이 순서로 읽어라'라고 제약을 거는 대신, 모델이 스스로 조사한 후에 다음과 같이 사용한다.

이 태스크에서 놓치기 쉬운 관점:
- API docs와 구현의 차이점
- generated type을 수동으로 편집하지 않았는지
...

고성능 모델에는 절차(Procedure)보다 관점(Perspective)을 전달하는 것이 더 효과적이다. 절차를 지나치게 구체화하면 탐색(Exploration)의 폭이 좁아진다.

모델과 태스크에 따라 설정의 강도를 전환한다.

모드	대상	규칙
lightweight	고성능 모델, 탐색계, 기사 구상	최소 원칙 + 필요 시 로드
...

모든 태스크에 strict를 적용하면 똑똑한 모델의 장점이 사라진다. strict는 불가역적 조작(Irreversible operation)이나 공개물(Public artifact)에 가깝게 설정한다.

이번 점검에서 또 하나 중요했던 점은 '설정의 강도'뿐만 아니라 '모델 사용량'도 설계 대상에 포함하는 것이었다.

고성능 모델 Fable은 탐색, 설계 판단, 장기 태스크, 모호한 요구사항 정리에서 강력하다. 반면, 항상 Fable을 사용하면 사용량이 먼저 고갈된다. 더욱이 Fable이 API 종량제(Pay-as-you-go)나 사용 크레딧(Usage credits)을 전제로 하는 모델이 되어간다면, 모든 것을 Fable로 처리하는 구성은 품질 이전에 운영 비용 측면에서 지속하기 어렵다.

따라서 모델 위임은 '하위 모델에게 잡무를 던진다'는 식의 오래된 고정 계층 구조가 아니라, 태스크의 리스크와 불확실성에 따라 전환한다.

모델	맡길 업무
Fable	중요한 설계 판단, 모호한 요구사항의 분해, 장기 태스크의 방침, 최종 판단
...

Fable은 중앙 결정 장치로 남겨두고, 탐색이나 구현은 별도의 모델로 흘려보낸다. 이는 단순한 절약이 아니라, 중요한 판단에 고성능 모델의 집중력을 남겨두기 위한 설계다.

이 방침은 Fable이 구독 내에서 항상 무료로 사용할 수 있다는 전제가 아니라, API 종량제나 사용 크레딧(Usage credits)을 고려한 구현이기도 하다.

즉, 고성능 모델을 위한 에이전트 기반(Agent foundation)은 다음 두 가지를 동시에 수행해야 한다.

• 컨텍스트(Context)를 항상 너무 많이 담지 말 것
• Fable을 항상 너무 많이 사용하지 말 것

고성능 모델의 가치는 **'모든 토큰(Token)을 최고급 모델로 처리하는 것'이 아니라, '판단이 필요한 국면에서 필요한 문맥(Context)만 전달하여 사용하는 것'**에 있다.

고성능 모델용 설정에서는 규칙 본문 그 자체보다 규칙의 '신선도(Freshness)'와 '적용 조건(Application condition)'이 중요해진다.

예를 들어, 각 규칙에 다음과 같은 메타데이터(Metadata)를 부여한다.

Rule: API error format
Why: 2026-05-18의 운영 장애로 인해 silent 200이 혼입되었기 때문
Applies when: API response / error handling / OpenAPI를 변경할 때
...

이를 통해 모델은 **'이것이 항상 지켜야 할 원칙인가', '과거 장애에 대한 일시적 대책인가', '현재 파일에서 재검증해야 할 가설인가'**를 구분하기 쉬워진다.

반대로, 다음과 같은 정보는 상시 규칙에서 제외할 후보가 된다.

• README, package.json, composer.json, Makefile, CI 설정에서 읽을 수 있는 정보
• lint / formatter / type checker가 기계적으로 검출할 수 있는 규약
• 이미 수정 완료된 일시적인 워크아라운드(Workaround)
• 특정 모델 세대의 약점만을 보완하기 위해 작성된 절차
• '꼼꼼하게 조사한다', '신중하게 작업한다'와 같이 행동을 무겁게 만들기만 하는 추상적 표현

남겨두어야 할 것은 코드에서 추측하기 어렵고, 틀렸을 때 대가가 큰 정보다. 그 외에는 상시 주입 대상에서 제외할 후보가 된다.

• 비표준 build / test / deploy 절차
• 파괴적 조작, 과금, 권한, 공개 범위와 관련된 제약
• 과거에 실제로 발생했던 사고의 재발 방지책
• 프로젝트 고유의 계약, API 호환성, 공개 사양
• 사용자나 조직의 명시적인 의사결정

이번 구성에서 가치가 높은 상태로 남기고 싶은 것은 다음과 같다.

• ~/.agents를 원본으로 하여 프로바이더(Provider)별 파일을 생성하는 설계
• SurrealDB에 지식, 성과물, 리뷰를 나누어 저장하는 설계
• 인증 정보를 설정 원본에 두지 않는 방침
• 계정 확인이나 기밀 체크와 같은 불가역적 조작 전의 안전 규칙
• Google Drive 등 외부 데이터 조작을 헬퍼(Helper)로 넘기는 방침

반면, 고성능 모델을 위해 약화시키고 싶은 것은 다음과 같다.

• 매 태스크마다의 자동 회상(Recall)
• 과거 지식을 강력한 전제로 하는 표현
• Gemini review의 과도한 강제
• hook을 통한 주기적인 규칙 재주입
• '상위 모델은 PM, 하위 모델은 Worker'라는 고정된 역할
• superpower를 실행 루트(Execution route)로 취급하는 것

여기서 중요한 것은, 설정을 버리는 것이 아니다. 설정을 「지능의 대체재」에서 「지능을 방해하지 않는 보조 도구」로 바꾸는 것이다.

• AI 에이전트 설정은 경량 모델(Lightweight model)에서는 능력 부족을 보완하는 scaffold (비계)로서 유효했다
• 고성능 모델(High-performance model)에서는 동일한 설정이 과거 지식에 대한 앵커(Anchor), 탐색 범위의 축소, 리뷰 마찰, 컨텍스트 오염(Context contamination)이 될 수 있다
• 문제는 외부 지식 그 자체가 아니라, 상시 주입 및 강제적인 절차화에 있다
• 고성능 모델을 위해서는 최소 원칙, 필요 시 recall (회상), 관점 체크리스트, 경량/엄격 모드 전환 방식이 좋다
• Fable은 판단이 필요한 장면에 남겨두고, Sonnet / Opus에 탐색·구현·리뷰를 위임함으로써 사용량 고갈과 종량제 과금 리스크를 억제할 수 있다
• AI 설정은 한 번 만들고 끝내는 것이 아니라, 모델 성능의 진화에 맞춰 재검토(Inventory)할 필요가 있다

공개 가능한 범위 내에서, 이번 재검토 대상은 다음과 같다.

~/.agents/rules/core.md

~/.agents/rules/memory.md

~/.agents/rules/qa.md

~/.agents/rules/account.md

~/.agents/rules/google-drive.md

~/.agents/rules/operations.md

~/.agents/bin/agents-sync

~/.claude/CLAUDE.md

~/.claude/settings.json

~/.claude/hooks/*.sh

~/.codex/config.toml

~/.codex/skills/*/SKILL.md