에이전트 규칙, Memory는 인덱스·Skill은 규칙 저장으로 분리

핵심 결론: 많은 사람이 규칙, SOP, 워크플로를 전부 Memory(메모리)에 적어 넣지만, Claude와 Codex의 Memory에는 모두 하드 리밋이 있다. CLAUDE.md는 200줄 이내로 유지할 것을 권장하며, 200K 컨텍스트 윈도우에서 이것은 매번 약 40000자 분량의 공간을 차지한다. 규칙이 많아지면 AI가 작업을 수행할 때 수많은 규칙을 한 번에 다 읽게 되어, 컨텍스트를 잠식할 뿐 아니라 서로 간섭한다. 올바른 방법은 한 문장으로 정리된다. Memory는 인덱스 역할을 하고, Skill에 규칙을 저장하라. Memory는 AI에게 '이 작업은 어느 Skill을 읽어야 하는지'만 알려주고, 구체적인 규칙, SOP, 운영 매뉴얼은 전부 Skill에 적고 Memory에는 적지 않는다. 이렇게 하면 규칙이 밀려나기 어렵고, 워크플로 간에도 서로 간섭하지 않는다.

목차

- Memory에 정말 상한이 있는가: 숫자를 제시해 보자

- 모든 규칙을 Memory에 몰아넣을 때의 두 가지 대가

- 핵심 해법: Memory는 인덱스, Skill은 규칙 저장

- Skill의 로딩 메커니즘: 왜 규칙이 밀려나지 않는가

- 실행 가능한 판단 함수: 이 규칙은 Memory로 가야 하나 Skill로 가야 하나

- 대조표: 증상 → 원인 → 해법

- 결론: 써야 할 때 / 쓰지 말아야 할 때의 판별 기준

1. Memory에 정말 상한이 있는가: 숫자를 제시해 보자

먼저 'Memory에 상한이 있는가'라는 철학적 문제로 논쟁하지 말고, 공식적으로 제시된 제약 숫자를 그대로 꺼내 보자.

CLAUDE.md의 권장 줄 수: Anthropic 공식은 각 CLAUDE.md 파일을 200줄 이내로 유지할 것을 분명히 권장한다. 이 길이를 넘으면 공식 표현 그대로 'consume more context and reduce adherence'——더 많은 컨텍스트를 차지하고 준수도를 떨어뜨린다. 이것은 미적 권고가 아니라 실측 후의 엔지니어링 제약이다.

200K 컨텍스트 윈도우가 몇 글자에 해당하는가: 기본 200K 컨텍스트 윈도우에서 CLAUDE.md의 사용 가능 공간은 약 40000자이다(1M 컨텍스트 윈도우 모델은 200000/150000자). 이는 규칙을 길고 빽빽하게 쓰면 파일 하나만으로도 전체 윈도우의 몇 분의 일에 가까운 분량을 잡아먹을 수 있다는 뜻이다.

MEMORY.md의 로딩 제한: 자동 메모리(auto memory)의 인덱스 파일인 MEMORY.md는 매 세션 시작 시 앞 200줄 또는 앞 25KB 중 먼저 도달하는 것만 로드한다. 초과 부분은 이번 세션에서 아예 읽을 수 없다——당신은 썼지만, AI는 볼 수 없다.

Skill의 로딩 비용: 실제로 필요에 따라 로드되는 것은 Skill(스킬)이다. Skill은 시작 시 그 name + description(약 100 token)만 로드하고, 전체 SKILL.md 본문(<5k token)은 스킬이 트리거될 때만 컨텍스트에 들어간다.

네 가지 숫자를 함께 놓으면 결론은 분명해진다. Memory는 '상주 메모리', Skill은 '온디맨드 읽기'다. 상주하는 것이 많아지면 매 턴의 작업이 무관한 규칙에 대해 비용을 치러야 한다.

참고 자료:

- How Claude remembers your project -- Claude Code Docs ⭐읽어볼 만함

- Extend Claude Code -- Claude Code Docs ⭐읽어볼 만함

- Give Claude context: CLAUDE.md and better prompts -- Claude Help Center

- Agent Skills -- Claude API Docs

2. 모든 규칙을 Memory에 몰아넣을 때의 두 가지 대가

규칙이 많아지고 전부 Memory에 몰아넣으면 두 가지 실질적인 대가를 치르게 된다. 이 두 가지 대가는 '성능이 조금 나쁘다'는 수준이 아니라, AI가 일을 제대로 못 하게 만든다.

대가 하나: 규칙이 밀려남(잘림). Memory에는 200줄 / 25KB의 로딩 문턱이 있어, 규칙을 많이 쓰면 뒤쪽 규칙은 세션에서 아예 로드되지 않는다. 당신은 '반드시 코드를 먼저 리뷰한 뒤 커밋해야 한다'고 썼다고 생각하지만, 너무 길어서 뒤에 배치된 탓에 AI는 이번 턴에 그것을 보지 못했을 수 있다. 규칙이 사라진 것이 아니라 '창밖 구석에 누워 있을' 뿐이고, AI는 그것을 뒤지지 않는다.

대가 둘: 워크플로 간 간섭. 수십 개의 서로 다른 주제 규칙(데이터베이스 마이그레이션, 릴리스 체크리스트, 코드 리뷰 규범)이 모두 같은 Memory에 몰아넣이면, AI는 매번 작업을 수행할 때 그것들을 처음부터 끝까지 다 읽어야 한다. 이는 두 종류의 간섭을 낳는다. 첫째, 무관한 규칙이 attention(주의)을 선점해 실행해야 할 규칙이 희석된다. 둘째, 규칙끼리 서로 모순될 수 있어 AI가 모순 속에서 왔다 갔다 한다.

비유하자면 🎭: Memory는 컴퓨터의 상주 메모리와 같아서 부팅하자마자 자리를 차지하고, Skill은 온디맨드 로딩 소프트웨어와 같아서 클릭해야 로드된다. 모든 소프트웨어를 부팅 시 자동 실행으로 만들면 메모리는 금세 터지고 자원을 서로 뺏는다——규칙을 전부 Memory에 몰아넣는 것과 같은 이치다.

- Claude Code usage limits and token optimization -- TechRounder

- Your CLAUDE.md Is Too Long: What to Cut So Claude Code Follows It -- DEV Community

3. 핵심 해법: Memory는 인덱스, Skill은 규칙 저장

Memory가 희소한 상주 자원이라면, 해결 사고는 한 문장이다. Memory는 인덱스만 하고, 구체적인 규칙과 SOP는 전부 Skill에 맡긴다.

Memory가 담당하는 것: '이 프로젝트에 어떤 Skill이 있는지, 각 Skill이 무엇을 하는지, 언제 어떤 Skill을 호출해야 하는지'만 기록한다. 즉 AI에게 '이 작업은 어느 Skill을 읽어야 하는지'를 알려주는 인덱스 카드다. 핵심은 signal-dense(신호 밀집)이다——모든 줄이 자기가 차지한 컨텍스트만큼의 가치를 해야 한다.

Skill이 담당하는 것: 구체적인 규칙, SOP, 운영 매뉴얼, 체크리스트. 예를 들어 데이터베이스 마이그레이션 절차, 릴리스 checklist, 코드 리뷰 규범, 특정 프레임워크의 API 사용법 같은 것이다. 이런 내용은 트리거될 때만 로드되어 상주 컨텍스트를 잠식하지 않는다.

이렇게 나누는 것이 성립하는 이유: Skill은 progressive disclosure(점진적 공개)를 자연스럽게 지원하기 때문이다. Skill의 name과 description은 상주하고(약 100 token), 본문은 필요에 따라 로드된다. 규칙을 Skill에 넣는다는 것은 '읽어야 할 규칙'이 필요할 때만 컨텍스트에 들어오고 평소에는 공간을 차지하지 않게 한다는 뜻이다.

판단 공식: 어떤 내용이 'AI가 매 라운드 반드시 알아야 하는 것'이라면 → Memory에 넣는다. '특정 작업에서만 필요한 것'이라면 → Skill에 넣는다. '다단계 프로세스 / 조작 매뉴얼'이라면 → 반드시 Skill에 넣는다.

- Steering Claude Code: skills, hooks, rules, subagents and more -- Claude ⭐읽을 만함

- Equipping agents for the real world with Agent Skills -- Anthropic ⭐읽을 만함

- How to remember: CLAUDE.md vs skills -- Claude Docs

4. Skill의 로딩 메커니즘: 왜 규칙이 밀려나지 않는가

누군가는 이렇게 물을 수 있다. "규칙을 Skill로 옮기면, 만약 AI가 떠올리지 못하고 읽지 않으면 어쩌지?" 답은 이렇다. Skill에는 자동 트리거와 온디맨드 로딩 메커니즘이 있어서 '밀려나지' 않는다. 세션에서 차지하는 자리가 극히 작기 때문이다.

Skill의 3단계 로딩(progressive disclosure):

계층 | 로딩 시점 | token 비용 | 내용 Level 1: 메타데이터 | 시작 시 | 개당 약 100 token | name + description Level 2: 지시문 | Skill이 트리거될 때 | <5k token | SKILL.md 본문 Level 3: 리소스 | 실행에 필요할 때 | 제한 없음 | references / scripts 등

왜 이것이 '규칙이 밀려나는' 문제를 해결하는가: Skill의 본문은 평소에는 전혀 로딩되지 않으므로 '너무 많이 써서 잘리는' 문제가 존재하지 않는다. 실제로 컨텍스트를 차지하는 것은 Level 1의 name + description(각각 약 100 token)이며, 이 부분이 바로 가장 간결한 인덱스다. 이것은 '이 스킬이 있다, 언제 쓰는지'만 알려준다.

어떻게 트리거되는가: Skill은 경로 명령으로 명시적으로 호출할 수 있고(예: /code-review), 작업에 의해 자동으로 매칭될 수도 있다. 일단 트리거되면 AI는 완전한 SKILL.md를 컨텍스트로 읽어 들여 일시적으로 모든 규칙을 획득한다.

- Agent Skills -- Claude API Docs ⭐읽을 만함

- Skill authoring best practices -- Claude Platform Docs

- How Claude Code works -- Claude Code Docs

5. 실행 가능한 판단 함수: 이 규칙은 Memory에 넣어야 하나, Skill에 넣어야 하나

아래 코드는 'Memory에 넣어야 하나, Skill에 넣어야 하나'의 판단을 4개의 질문으로 정규화한다. 실행에는 어떤 외부 의존성도 필요 없고, 복사하면 바로 실행된다:

def classify_rule_entry ( always_needed: bool , # 이 내용을 AI가 매 라운드 반드시 알아야 하는가 is_workflow: bool , # 다단계 프로세스 / 조작 매뉴얼에 속하는가 task_specific: bool , # 특정 작업에서만 필요한가 ) -> str : """규칙 하나를 Memory(인덱스)에 둘지 Skill(본문)에 둘지 판단한다. 매개변수: always_needed: 내용이 매 세션 반드시 상주해야 하는지(예: 프로젝트 규약, 명명 규칙) is_workflow: 다단계 프로세스, SOP, 조작 매뉴얼에 속하는지 task_specific: 특정 작업 시나리오에서만 필요한지 반환: 권장 저장 위치: memory / skill """ # 1) 다단계 프로세스 / 조작 매뉴얼 -> 반드시 Skill에, 상주 컨텍스트 잠식을 방지 if is_workflow: return "skill（Skill）: 프로세스/매뉴얼은 온디맨드 로딩, 상주 컨텍스트 잠식 안 함" # 2) 매 라운드 반드시 알아야 함 -> Memory에, 상주 인덱스로 if always_needed: return "memory（Memory）: 상주 인덱스, 매 세션 로딩 보장" # 3) 특정 작업에서만 필요 -> Skill에, description으로 자동 트리거 if task_specific: return "skill（Skill）: 작업 트리거 시 로딩, description으로 매칭" # 4) 모두 충족 안 함 -> 기본적으로 Skill에, 가장 보수적 return "skill（Skill）: 기본 온디맨드 로딩, 중복 방지" # 예시: '데이터베이스 마이그레이션 프로세스'를 어디에 둘지 판단 if __name__ == "__main__" : print (classify_rule_entry( always_needed= False , # 마이그레이션 프로세스는 매 라운드 필요하지 않음 is_workflow= True , # 다단계 조작 매뉴얼임 task_specific= False , )) # 출력: skill（Skill）: 프로세스/매뉴얼은 온디맨드 로딩, 상주 컨텍스트 잠식 안 함

이 코드는 판단 로직을 하나의 실행 가능한 의사결정 경로로 압축한다. 핵심 원칙: Skill에 넣을 수 있는 것은 최대한 Skill로, Memory에는 반드시 상주해야 하는 인덱스만 남긴다.

6. 대조표: 증상 → 원인 → 해법

증상 | 원인 | 해법 규칙을 많이 썼는데 AI가 작업을 실행할 때 특정 한 조항을 늘 빠뜨림 | 규칙이 Memory 200줄 / 25KB 밖에 위치해 세션에서 아예 로딩되지 않음 | 비핵심 규칙을 Skill로 옮기고 Memory에는 인덱스만 남긴다 AI가 작업을 실행할 때마다 느리고 token 소비가 높음 | 대량의 무관한 규칙을 매번 읽어 들여 상주 컨텍스트를 가득 채움 | Memory를 200줄 이내로 간소화하고 규칙은 Skill이 온디맨드 로딩하도록 변경 몇 개의 워크플로 규칙이 서로 모순되어 AI가 갈팡질팡함 | 서로 다른 주제의 규칙을 모두 같은 Memory 한 벌에 밀어 넣어 서로 간섭 | 주제별로 다른 Skill로 분리하여 각자 트리거되고 서로 간섭하지 않게 함 새 규칙을 추가하고 싶지만 어디에 둘지 모름 | '인덱스 vs 본문'의 구분 기준이 없음 | 위의 판단 함수 사용: 다단계 프로세스는 Skill로, 상주 약속은 Memory로 프로젝트에 Skill이 잔뜩 있는데 AI가 떠올려 쓰지 못함 | Skill의 description이 너무 두루뭉술하게 쓰여 자동 트리거가 불가능 | Skill의 description을 'when to use' 트리거 시나리오로 강화

7. 결론: 써야 할 때 / 쓰지 말아야 할 때의 판단 기준

언제 써야 하는가: 규칙이 「매 라운드 반드시 알아야 하는 약속」(명명 규칙, 빌드 명령, 기본 프로젝트 구조)이라면 → Memory(CLAUDE.md)에 넣는다. 규칙이 「다단계 프로세스, SOP, 운영 매뉴얼」이라면 → Skill에 넣는다(필요할 때 로딩). 판단 기준은 단 하나 — 이 규칙을 AI가 매 라운드 봐야 하는가. 그렇다면 Memory로, 아니라면 Skill로 간다.

언제 쓰지 말아야 하는가: 모든 규칙을 Memory에 밀어 넣지 말 것, 특히 다단계 프로세스와 긴 매뉴얼을 넣지 말 것. Memory가 200행 / 25KB를 넘지 않게 할 것. 대량의 내용으로 컨텍스트 윈도우를 채우지 말 것, 그것은 규칙 준수도만 떨어뜨릴 뿐이다. 규칙이 많아지면 해야 할 일은 Skill로 분할하는 것이지, 계속 Memory에 쌓는 것이 아니다.

이 칼럼 《AI Agent 도구 칼럼》은 도구 호출, 메모리 관리, Skill 라우팅에서부터 규칙 거버넌스와 컨텍스트 상한까지 다루며, 매 편마다 실행 가능한 코드와 대조표 한 장을 곁들여 프로덕션 적용의 실제적 취사선택에 초점을 맞추고, 매주 한 편씩 업데이트한다. Agent 엔지니어링에서 시행착오를 줄이고 싶다면 칼럼 페이지에서 구독할 수 있다.

ENCI

吃手手

259

글

93k

조회수

82

팬