Claude Code의 세컨드 브레인: 한 시간 만에 구조를 만드는 방법

Ailoot 참고 문서: ailoot.ai/docs/.

Claude Code에 세컨드 브레인이 필요한 이유는 무엇이며, 무엇이 핵심일까요?#

화요일에 Claude Code를 엽니다. 이게 프로젝트고, 이게 대상 고객이고, 이건 하지 말라고 설명합니다. 함께 작업합니다. 목요일에는 새 채팅을 열게 되고, 모든 것을 다시 설명해야 합니다.

CLAUDE.md가 있다면 첫 번째 좌절은 해결한 셈입니다. 기본 규칙과 프로젝트 설명을 파일 하나에 담아 매 세션마다 불러옵니다. 이 파일의 작동 방식은 CLAUDE.md 가이드에서 설명했습니다. 먼저 읽고 기초를 마련해도 좋습니다.

하지만 CLAUDE.md는 신입 직원용 업무 매뉴얼과 같습니다. 옷차림, 고객과 대화할 때의 어조, 게시할 때 사용할 명령어 등을 알려 줍니다. 그것만으로는 프로젝트에 관한 좋은 결정을 내리기에 부족합니다. 결정을 내리려면 제품이 무엇인지, 대상 고객은 누구인지, 수익 구조는 어떤지, 무엇을 시도했고 무엇이 효과가 없었는지에 관한 지식이 필요합니다.

여기서 설명하는 저자의 경험에 따르면, 이런 지식은 예전에는 머릿속, Telegram 채팅, Google 문서, 직원들의 머릿속이라는 네 곳에 있었습니다. 결정을 내린 지 한 달이 지나면 아무도 왜 그런 결정을 내렸는지 기억하지 못했습니다. 새로 온 사람은 업무를 파악하려고 팀에 질문하는 데 한 시간을 썼습니다. Claude는 그 맥락을 전혀 알지 못했습니다.

저자가 설명하는 경험에서 세컨드 브레인이 없을 때는 매 세션마다 고객이 누구인지, 제안이 어떻게 구성되어 있는지, 어떤 업체가 결제를 처리하는지 다시 설명해야 했습니다. business/가 있으면 채팅을 열고 “새 요금제에 맞춰 제안을 업데이트해”라고 말합니다. 그러면 Claude가 알아서 business/company/legal.md로 가서 요구 사항을 읽고, 이어 business/products/pricing.md로 가서 새 요금제를 확인한 다음 한 번에 수정안을 제안합니다. 준비 설명이 사라지고 맥락이 자동으로 불러와집니다.

Anthropic은 엔지니어링 블로그에서 이 문제를 컨텍스트 로트(context rot)라고 부릅니다.

다시 말해 창에 더 많은 내용을 욱여넣을수록 에이전트는 구체적인 정보를 다루는 능력이 떨어집니다. 해결책은 Claude가 특정 요청에 따라 스스로 찾아볼 수 있는 외부 파일 구조를 유지하는 것입니다. 이것이 세컨드 브레인입니다.

세컨드 브레인이란 무엇이며, Claude에 어떻게 적용될까요?#

일반적으로 세컨드 브레인은 생산성 전반에 관한 것입니다. 사람들은 Obsidian vault를 만들고 책 발췌문, 통화 메모, 프로젝트 아이디어를 추가합니다.

저자가 이 아이디어를 Claude Code 작업에 적용하자, 생산성에 관한 방법에서 에이전트 아키텍처로 바뀌었습니다.

전통적인 접근법에서 세컨드 브레인은 사용자의 것이며 사용자가 직접 접근합니다. Claude Code와 함께 사용하면 세컨드 브레인은 양방향이 됩니다. 사용자와 에이전트 모두 접근합니다. 이로 인해 형식에 요구되는 조건도 달라집니다.

에이전트가 스스로 접근하므로 별도 통합 없이 이해할 수 있는 형식으로 파일을 만들어야 합니다. Markdown이 이상적입니다. 텍스트, 제목 계층, 파일 간 링크를 지원하기 때문입니다. Notion과 Google Docs는 적합하지 않습니다. MCP로 연결할 수 있지만, 그러면 계층이 하나 더 생기고 요청마다 토큰이 더 들며 오류 지점도 하나 늘어납니다.

파일이 프로젝트 옆의 파일 시스템에 있으므로 자동으로 Claude Code가 접근할 수 있는 범위에 들어갑니다. 별도의 설정은 필요 없습니다. 프로젝트 폴더에서 에이전트를 시작하면 그 안의 모든 파일을 볼 수 있습니다. 무료이며 별도 설정 없이 작동합니다.

Claude Code에 기본으로 제공되는 메모리 계층은 무엇일까요?#

무엇을 추가하기 전에 Claude가 도움 없이 무엇을 기억할 수 있는지 살펴보겠습니다. Anthropic은 공식 문서에서 두 가지 메커니즘을 설명합니다. 직접 작성하는 규칙인 CLAUDE.md와 Claude가 직접 작성하는 교훈인 자동 메모리입니다. 둘 다 매 세션이 시작될 때 불러옵니다.

CLAUDE.md는 한 번에 네 곳에서 검색됩니다.

네 파일 모두 컨텍스트에 불러옵니다. 수준이 구체적일수록 우선순위가 높습니다. 로컬 파일은 마지막에 읽히므로 그 규칙이 다른 모든 규칙보다 우선합니다.

프로젝트 내 어떤 폴더에도 CLAUDE.md 파일을 둘 수 있습니다. Claude가 하위 폴더의 파일을 읽으면 해당 하위 폴더의 CLAUDE.md를 필요할 때 불러옵니다. 모노레포에서 유용합니다. 프런트엔드 규칙은 frontend/CLAUDE.md에, 백엔드 규칙은 backend/CLAUDE.md에 두며, 에이전트가 해당 부분을 작업할 때만 불러옵니다.

자동 메모리는 Claude Code 2.1.59에서 도입되었습니다. Claude가 사용자에 관해 작성하는 파일입니다.

~/.claude/projects/<project-name>/memory/
├── MEMORY.md          # 색인, 매 세션 불러옴 (200줄 또는 25KB)
├── debugging.md       # 자세한 메모 (필요할 때 불러옴)
├── api-conventions.md
└── ...

Anthropic은 공식 문서에서 이를 다음과 같이 설명합니다.

자동 메모리는 ~/.claude/settings.json의 autoMemoryEnabled 플래그로 활성화됩니다. 무엇을 쓸지는 Claude가 결정합니다. MEMORY.md를 읽고 직접 편집할 수도 있습니다. 일반 Markdown 파일입니다.

CLAUDE.md와 세컨드 브레인, 경계는 어디에 둘까요?#

강연에서 제가 사용하는 비유를 소개하겠습니다. 신입 직원을 채용했다고 상상해 보세요. 첫날에 무엇을 주겠습니까?

업무 매뉴얼입니다. 옷차림, 출근 시간, 고객과 대화할 때의 어조, 게시에 사용할 시스템을 알려 줍니다. 짧은 문서입니다. 무엇을 하는지, 왜 하는지는 설명하지 않습니다. 어떻게 행동할지만 알려 줍니다.

그리고 별도로 회사 위키에 접근할 수 있게 합니다. 제품이 무엇인지, 누구를 위한 것인지, 대상 고객은 누구인지, 가격은 얼마이고 왜 그런지, 경쟁사는 누구인지, 어떤 실수를 했는지 설명합니다. 방대한 아카이브입니다. 아무도 전부 읽지 않습니다. 특정 질문이 있을 때 찾아갑니다.

CLAUDE.md = 업무 매뉴얼. 세컨드 브레인 = 위키. 둘 다 필요합니다.

구분은 간단합니다. 모든 작업에 관련된 내용은 CLAUDE.md에 넣습니다.

• 이 프로젝트에서 에이전트의 역할(도우미, 리드, 어시스턴트)
• 답변에 사용할 언어
• 도구 스택
• 게시 명령어
• 금지 사항(긴 대시 사용 금지, git push --force 실행 금지)
• 업무 맥락은 어디서 찾고 원칙은 어디서 확인하는지에 관한 경로 안내

필요할 때만 필요한 내용은 세컨드 브레인에 넣습니다.

• 제품, 대상 고객, 수익 구조, 목표
• 경쟁사와 시장
• 과거 결정과 그 이유
• 고객 사례와 후기
• 원칙과 방법론

Anthropic도 문서에서 같은 구분을 합니다.

Skills는 에피소드성 지식을 저장하는 한 가지 방법입니다. 프로젝트 옆의 business/ 폴더도 또 다른 방법입니다. 저는 둘 다 사용하며 아래에서 더 자세히 설명하겠습니다.

프로젝트 브레인은 무엇으로 이루어질까요? 5개 부분과 타임머신#

저자가 설명한 경험에서 가져온 아키텍처 예시입니다.

방법론에서 핵심은 ai-clone/과 business/를 분리하는 것입니다.

business/는 “우리는 무엇을 하는가?”라는 질문에 답합니다. 제품, 대상 고객, 가격, 경쟁사에 관한 내용입니다. 프로젝트에 관한 폴더입니다. 내일 프로젝트를 파트너에게 넘긴다면 이 폴더도 프로젝트와 함께 갑니다.

ai-clone/은 “나는 어떻게 결정하는가?”라는 질문에 답합니다. 나의 원칙, 어조, 전문성, 피해야 할 표현에 관한 내용입니다. 나에 관한 폴더입니다. 내일 새 프로젝트를 시작한다면 이 폴더도 나와 함께 갑니다.

두 번째 폴더를 설정하는 데서 그치지 않고 Claude가 일관되게 답하도록 하는 시스템도 만들고 싶으신가요? 그것만으로는 충분하지 않습니다. ai-clone/이 없으면 에이전트는 당신이 아니라 모두를 위해 답합니다. 컨텍스트 엔지니어링이 없으면 전체 폴더를 돌아다니며 토큰을 소모합니다. 세 가지를 모두 연결하면 유용합니다. 세컨드 브레인 + AI 클론 + 컨텍스트 엔지니어링. AI가 환각을 일으키지 않도록 하는 세 가지 기둥입니다.

business/에는 무엇을 넣고, 무엇을 넣지 말아야 할까요?#

저자가 설명한 프로젝트의 business/ 최상위 구조입니다.

business/
├── INDEX.md              ← 폴더 지도, 먼저 읽기
├── company/              ← 사명, 법인, 가치, 법률 정책
├── products/             ← 제품, 프로그램, 가격
├── audience/              ← 고객 프로필, 세그먼트, 반대 의견
├── goals/                ← 연간·분기·월간 목표, 지표
├── economics/            ← 단위 경제성, 수입, 지출, 예측
├── marketing/             ← 채널, 퍼널, 자료, 경쟁사
├── execution/            ← 주간 계획, 백로그
└── assets/               ← 디자인 시스템, 후기, 카피 모음

이는 저자가 설명한 프로젝트의 예시이지, 절대적인 규칙은 아닙니다. 필요할 때 폴더를 만듭니다. 처음에는 세 개(products/, audience/, goals/)로 시작했고, 새로운 항목을 어디에 넣어야 할지 불분명해진 2-3개월 후 다른 폴더를 추가했습니다.

폴더의 주요 파일은 INDEX.md입니다. 지도 역할을 합니다. Claude가 어디로 가야 할지 파악할 수 있도록 “질문 → 파일” 표를 포함합니다. 이 파일이 없으면 에이전트는 모든 파일을 차례로 읽느라 토큰을 소모합니다.

INDEX.md의 예시 발췌:

### 필요한 정보를 찾는 곳

| 필요한 내용 | 찾아볼 위치 |
|---|---|
| 고객은 누구이고 어떤 문제를 겪는가 | `business/audience/avatar.md` |
| 제품, 요금제, 가격 | `business/products/` |
| 목표와 지표 | `business/goals/` |
| 수익 구조(수입, 지출, 단위 경제성) | `business/economics/` |
| 홍보 채널과 자료 | `business/marketing/` |

그러면 CLAUDE.md에 “업무 관련 질문에는 business/INDEX.md를 읽고 지도를 따라가세요”라고 한 줄만 추가하면 됩니다. 에이전트는 폴더 전체를 컨텍스트에 불러오지 않습니다. 지도를 불러와 맞는 파일을 고르고 그 파일만 읽습니다.

business/에 넣지 말아야 할 항목 체크리스트:

• 처리하지 않은 원본 채팅 대화. 통찰이 있다면 핵심을 추려 기록하세요. 없다면 제외하세요.
• 코드에 이미 있는 정보. “결제는 CloudPayments를 통해 처리한다”는 정보는 필요하지 않습니다. 에이전트가 코드에서 확인할 수 있습니다.
• 스크린샷과 이미지. 폴더 크기를 키우고, 별도 단계가 없으면 텍스트 모델이 분석할 수 없습니다.
• 동적 수치. “오늘 이 제품의 결제가 423건이다”라는 정보는 일주일이면 오래된 정보가 됩니다. LIVE 표시와 데이터베이스 쿼리 링크를 사용하세요.
• 민감하거나 공개하기 꺼려지는 정보. 내일 저장소가 YouTube에 공개되어 낯선 사람 10만 명 앞에 놓인다면, 기꺼이 보여 줄 내용만 남기세요. 직원, 에이전트, 때로는 외부 계약자가 이 폴더를 읽습니다.

ai-clone 폴더를 따로 두는 이유는 무엇이며, business와 섞으면 안 되는 이유는 무엇일까요?#

아이디어는 간단합니다. 업무 폴더는 우리가 하는 일을 알고, 클론은 내가 결정을 내리는 방식을 압니다.

저자가 설명한 프로젝트의 ai-clone/ 구조입니다.

ai-clone/
├── INDEX.md           ← 폴더 지도
├── role.md            ← 내가 누구인지, 배경, 중요한 것
├── identity/          ← 가치, 비전, 사명
├── thinking/          ← 강연에서 얻은 사고 모델
├── voice/             ← 어조, 어휘, 스타일
├── principles/        ← 제품, 코드, 업무에 대한 신념
├── feedback/          ← 실수에서 배운 규칙 ← 핵심 폴더
├── style/             ← 피해야 할 표현, Telegram 형식
└── reference/         ← 도구, 환경

가장 유용한 폴더는 feedback/입니다. 에이전트가 저지른 실수에서 배운 구체적인 규칙을 담습니다. 각 규칙은 다음 형식으로 별도 파일에 작성합니다.

---
name: short-name
description: one line - what’s in the file and when to apply it
type: feedback
---

한 문장으로 된 짧은 규칙.

**이유:** 이 규칙이 존재하는 이유. 맥락, 사고, 관찰.

**적용 방법:** 규칙을 적용해야 할 구체적인 조건.

“이유”가 없으면 규칙은 쓸모가 없습니다. 에이전트가 비슷한 상황에 적용하지 못합니다. “적용 방법”이 없으면 언제 규칙을 사용해야 하는지 분명하지 않습니다.

제 폴더에 있는 예시는 “하이픈, 긴 대시는 쓰지 않기”라는 규칙입니다. 긴 대시 —가 생성된 텍스트를 나타내는 주요 시각적 표식이기 때문에 생긴 규칙입니다. 대중에게 공개되는 모든 텍스트에 적용됩니다. 파일은 ai-clone/feedback/no-em-dashes.md에 있습니다.

저는 조금 다르게 합니다. 규칙을 CLAUDE.md가 아니라 ai-clone/feedback/에 씁니다. CLAUDE.md는 프로젝트 파일이지만, 어조와 스타일에 관한 규칙은 개인적인 것입니다. 다음 프로젝트로 가져갑니다. CLAUDE.md는 프로젝트에 남습니다.

Live Metrics란 무엇이며, 파일에 수치를 직접 넣으면 안 되는 이유는 무엇일까요?#

세컨드 브레인을 시작할 때 가장 흔한 함정 중 하나는 오래된 수치를 채워 넣는 것입니다. “고객이 320명이다”라고 적었는데 2주 후에는 이미 410명입니다. “월 매출은 4.7 million이다”라고 적었는데 한 달 뒤에는 이 수치가 목표인지, 실제 실적인지, 예측인지 맥락을 알 수 없습니다.

저자의 예에서는 다음과 같이 작동합니다. business/products/practicum.md 파일에서 수치 대신 표시를 넣습니다.

## 코호트

> **LIVE** - 현재 코호트별 결제를 보려면 `live-metrics.md`의
> “Sales” 섹션에 있는 쿼리를 실행하세요.

| 코호트 | 날짜 | 결제 고객 |
|-------|------|------------|
| 1 | March 10-12, 2026 | LIVE |
| 2 | March 24-26, 2026 | LIVE |

별도 live-metrics.md 파일에는 실행 가능한 SQL 쿼리와 쿼리 결과에 관한 설명이 들어 있습니다.

## Sales (코호트별 결제)

```sql
SELECT c.name, COUNT(p.id) AS paid, SUM(p.amount) AS revenue
FROM purchases p
JOIN cohorts c ON c.id = p.cohort_id
WHERE p.status = 'paid'
GROUP BY c.name
ORDER BY c.starts_at DESC;
```

에이전트에게 “두 번째 코호트의 결제 건수가 몇 건이지?”라고 물으면 다음과 같이 처리합니다.

1. business/products/practicum.md를 읽습니다.
2. 수치 옆의 LIVE 표시를 확인합니다.
3. live-metrics.md를 엽니다.
4. “Sales” 섹션을 찾습니다.
5. 프로덕션 데이터베이스에서 쿼리를 실행합니다.
6. 최신 데이터로 답합니다.

이렇게 하면 두 가지 문제를 한꺼번에 해결합니다. 수치가 오래되지 않습니다. 그리고 의사 결정은 작년이 아니라 현재 상황을 바탕으로 이루어집니다.

단일 요청에서 AI는 세컨드 브레인을 어떻게 탐색할까요?#

구체적인 요청의 예: “새 코호트에 관한 이메일을 참가자들에게 작성해 줘.”

1. Claude는 비어 있는 창에서 시작합니다. CLAUDE.md(규칙, 스택, 경로 안내)를 불러옵니다.
2. CLAUDE.md의 경로 안내에서 “ai-clone/INDEX.md - 세션을 시작할 때 항상 읽기”를 확인합니다. 파일을 열어 내가 누구인지, 어조가 어떤지, 어떤 표현을 피하는지 알아냅니다.
3. 경로 안내에서 “이메일 템플릿 - src/lib/email/layout.ts”를 확인합니다. 파일을 열어 형식을 파악합니다.
4. “제품 맥락 - business/products/practicum.md”를 확인합니다. 파일을 열어 제품에 관한 내용을 읽습니다.
5. 파일에서 LIVE 표시와 live-metrics.md 참조를 확인합니다. 파일을 열고 실행 가능한 SQL을 찾습니다. 최신 수치가 필요하면 쿼리를 실행합니다. 그렇지 않으면 “발송 시점에 이 수치를 가져올 것”이라고 표시합니다.
6. ai-clone/style/telegram-format.md의 어조 규칙, ai-clone/feedback/no-em-dashes.md의 긴 대시 금지 규칙, business/marketing/funnel.md의 퍼널 전환율을 확인합니다.

내 어조에 맞고 최신 수치를 반영하며 긴 대시나 AI 생성 표식이 없는 이메일을 작성합니다.

Anthropic은 엔지니어링 블로그에서 이 방식을 just-in-time 컨텍스트라고 부릅니다.

다시 말해 Claude는 데이터 자체가 아니라 데이터로 연결되는 포인터를 가지고 다닙니다. 관련된 정보만 컨텍스트에 들어가므로 토큰을 훨씬 효율적으로 사용하고 정확도도 높아집니다. 창은 추론을 위해 비워 둡니다.

세컨드 브레인에서 피해야 할 안티패턴 5가지#

안티패턴 1. 비대한 CLAUDE.md. 모든 것을 한곳에 넣는 대신 지침을 500줄 작성하는 것입니다. Anthropic은 분명히 말합니다.

목표 분량은 80-120줄입니다. 나머지는 별도 파일에 넣고 그 파일로 연결하세요.

안티패턴 2. 잡동사니 폴더. 원본 채팅 대화, 쓸모없는 스크린샷, 아무도 읽지 않을 보고서를 세컨드 브레인에 모두 넣습니다. 한 달 후 폴더는 비대해지고, 에이전트는 쓸모없는 내용을 읽느라 토큰을 낭비하며, 무엇이 어디 있는지도 기억할 수 없습니다. 규칙은 간단합니다. 세컨드 브레인의 각 파일은 구체적인 질문 하나에 답해야 합니다. 6개월 동안 아무도 열어 보지 않았다면 삭제하거나 아카이브로 옮기세요.

안티패턴 3. 중복. “결제는 CloudPayments로 처리되며, src/lib/payment/cloudpayments.ts에 있습니다. 공급자는 .env에 설정되어 있습니다.” 에이전트는 이 내용을 코드에서 확인할 수 있습니다. business/에 중복해서 넣지 마세요. 중복 정보는 오래됩니다. 코드는 바뀌었는데 business/가 업데이트되지 않으면 에이전트는 오래된 정보를 바탕으로 작업합니다.

안티패턴 4. 수치를 직접 입력. “고객이 1,247명이고 전환율이 6.3%다.” 추상적인 핀테크 스타트업의 수치라고 가정해 보세요. 이런 수치는 모두 일주일이면 오래된 정보가 됩니다. LIVE 표시와 live-metrics.md를 사용하세요. 관련 섹션은 위에 있습니다.

안티패턴 5. 접근 경로가 없는 맥락. 세컨드 브레인이 다른 곳에 있고 에이전트에게 권한이나 참조가 없다면 코드 폴더에서 시작하는 것만으로는 부족합니다. 민감하지 않은 공유 메모에는 저장소 안의 business/와 ai-clone/ 배치가 편리합니다. 비공개 맥락은 별도로 통제하는 위치에 두고 허용된 접근과 경로를 명시적으로 설정하세요. 폴더의 편리함이 기밀성을 우선하지는 않습니다.

한 시간 만에 세컨드 브레인 만들기: 단계별 방법#

1. 루트 폴더 두 개 만들기

   src/ 옆의 프로젝트 루트에서 실행합니다.

   mkdir -p business/{products,audience,goals,economics,marketing}
   mkdir -p ai-clone/{identity,voice,principles,feedback,style}
   

2. 폴더 지도 역할을 하는 INDEX.md 만들기

   business/INDEX.md는 “질문 → 파일” 표입니다. 최소 5개 행으로 시작하고 필요에 따라 더 추가하세요. ai-clone/INDEX.md에도 똑같이 만드세요.

3. 제품과 고객에 대한 간단한 설명 추가하기

   business/products/main.md에는 제품이 무엇인지, 누구를 위한 것인지, 가격은 얼마인지, 어떤 점이 다른지 적습니다. 30-50줄이면 됩니다. business/audience/avatar.md에는 고객이 누구인지, 어떤 문제를 겪는지, 무엇을 구매하는지 적습니다. 30-50줄이면 됩니다. 이상적인 고객을 묘사하지 말고 실제 고객을 설명하세요. 모르는 내용은 “확인 필요”로 표시하고 넘어가세요.

4. ai-clone/role.md에서 자신을 설명하기

   자신이 누구인지, 무엇을 하는지, 무엇이 중요한지 적습니다. 20-30줄이면 됩니다. 시작하기에는 충분합니다. 에이전트가 자신의 스타일과 다른 방식으로 글을 쓴다는 것을 발견하면 어조, 원칙, 피해야 할 표현을 추가하세요.

5. CLAUDE.md에 경로 안내 추가하기

   CLAUDE.md를 열고 다음 섹션을 추가합니다.

   ## 프로젝트 지도
   
   - 업무 맥락 → `business/INDEX.md`
   - 나에 관한 맥락 → `ai-clone/INDEX.md`
   - 기술 계획 → `plans/YYYY-MM-DD-*.md`
   - 이전 세션 회고 → `retrospectives/`
   
   세션을 시작할 때 항상 `ai-clone/INDEX.md`와 `business/INDEX.md`를 읽으세요.
   

6. Claude Code를 시작하고 확인하기

   에이전트를 엽니다. “내 제품과 대상 고객에 대해 말해 줘”라고 요청합니다. 폴더의 맥락을 바탕으로 답하면 작동하는 것입니다. 내용을 지어내면 폴더가 프로젝트 옆에 있는지, 파일 이름이 정확한지, CLAUDE.md의 경로 안내가 명확하게 작성되었는지 확인하세요.

이후 세컨드 브레인은 두 가지 원칙에 따라 성장합니다.

첫째, 에이전트가 실수할 때마다 규칙을 추가합니다. 3-4주 후면 ai-clone/feedback/에 15-20개의 규칙 파일이 쌓이고, 에이전트는 흔한 실수 대부분을 반복하지 않게 됩니다.

둘째, 업무상 결정을 내릴 때마다 business/에 기록합니다. 가격을 올리면 날짜와 이유를 business/products/pricing.md에 추가합니다. 포지셔닝을 바꾸면 business/company/about.md에 메모를 추가합니다. 6개월이 지나면 “왜”를 기억하는 아카이브가 생깁니다.

이번 주에 함께 상당히 많은 작업을 했습니다.

이번 주에 변경한 모든 코드와 모든 커밋을 분석하세요.
이 작업에서 얻은 유용한 정보 중 business/에 들어가야 할 내용을 찾아 적절한 파일에 작성하고,
맥락이 사라지지 않도록 인접 파일에 위키 링크를 추가하세요.

제가 설명하지 않은 코드상의 결정이 있다면 이유를 물어보고,
그 이유를 날짜와 함께 적절한 파일에 기록하세요.

코드만 봐도 분명한 내용을 중복하지 마세요. business/가 없으면 에이전트가
다음 세션에 알지 못할 내용만 포함하세요.

다음 단계: Skills, Subagents, 컨텍스트 엔지니어링#

세컨드 브레인을 마련한 뒤에는 Anthropic이 컨텍스트 최적화의 세 가지 수준으로 설명하는 도구를 세 가지 더 활용할 수 있습니다.

Skills는 절차 지식입니다. 반복하는 워크플로(학습 가이드 작성, Telegram 게시물 만들기, 웹사이트 감사)가 있다면 작업 설명을 담은 SKILL.md 파일에 인코딩할 수 있습니다. 세션을 시작할 때 Claude는 skill 이름과 설명을 살펴보고 현재 작업에 맞는 것만 불러옵니다. 토큰을 절약하고 집중력을 유지할 수 있습니다.

Subagents는 자체 컨텍스트 창이 있는 독립적인 Claude 인스턴스입니다. 까다로운 작업(파일 30개를 읽고 요약하기)에 subagent를 시작하면 자체 창에서 작업하고 결과만 반환합니다. 기본 창은 비워 둘 수 있습니다. Anthropic은 다음과 같이 씁니다.

컨텍스트 엔지니어링은 창에 무엇을 넣을지 관리하는 것입니다. Anthropic은 2025년에 이를 에이전트 작업을 위한 기초 기술이자 프롬프트 엔지니어링보다 한 단계 위의 기술이라고 불렀습니다. 프롬프트 엔지니어링은 표현을 고르는 일입니다. 컨텍스트 엔지니어링은 파일, 경로, skills, subagents를 고르는 일입니다.

세컨드 브레인은 컨텍스트 엔지니어링의 첫 번째 구성 요소입니다. 이것이 없으면 Skills는 빈 공간을 읽고, Subagents는 갈 곳이 없으며, 에이전트의 창은 무작위 정보로 가득 찹니다. 세컨드 브레인이 있으면 세 도구가 모두 작동하기 시작합니다.

다음 단계. 프로젝트 옆에 business/와 ai-clone/ 폴더를 만드세요. 각 폴더에 지도 역할을 하는 5줄짜리 INDEX.md를 추가하세요. CLAUDE.md에 경로 안내 네 줄을 추가하세요. 한 시간 안에 작동하는 세컨드 브레인 기반을 마련할 수 있습니다. 그런 다음 “에이전트가 실수할 때마다 ai-clone/feedback/에 한 줄을 추가한다”는 규칙에 따라 확장하세요. 세컨드 브레인으로 연결할 때 사용할 전체 CLAUDE.md 템플릿은 CLAUDE.md를 올바르게 설정하는 방법 가이드에서 설명합니다.

ailoot.ai에서 Ailoot를 더 살펴보세요.