도입

화면 네 개가 동시에 돌아가고 있습니다. 하나는 오늘 일정을 짜주고, 다른 하나는 링크드인 포스트를 써주며, 세 번째는 팀의 프로젝트 진행 상황을 점검하고, 네 번째는 유튜브 영상용 시각 자료를 만들어냅니다. 미국의 한 AI 자동화 컨설턴트가 매일 아침 출근하면 마주하는 장면입니다. 네 개의 에이전트가 병렬로 돌아가는 데 걸리는 시간은 약 2분. 같은 작업을 손으로 처리하면 25분이 넘게 걸립니다.

이 컨설턴트의 프로젝트 폴더 왼쪽 패널에는 수십 개의 파일과 폴더가 빼곡하게 들어차 있습니다. 컨텍스트 파일, 의사결정 로그, 스킬 폴더, 에이전트 설정까지. 처음 보는 사람은 압도당하기 쉽습니다. 그러나 이 구조물은 하루아침에 만들어진 것이 아닙니다. 매일 조금씩, 네 개의 단계를 밟아 쌓아 올린 결과물입니다.

그 네 단계를 Home(집), Life(생명), Hands(손), Growth(성장)라고 부릅니다.

1단계 '집': 프로젝트 폴더 구조와 claude.md 설계

건물을 짓기 전에 터를 닦듯, AI 이그제큐티브 어시스턴트(Executive Assistant)를 만들려면 먼저 그것이 살아갈 공간을 마련해야 합니다. 여기서 '집'이란 프로젝트 폴더 하나를 의미합니다.

VS Code(Visual Studio Code)를 열고, 바탕화면이든 원하는 위치든 새 폴더를 하나 만듭니다. 이름은 자유롭게 정하되, 이 폴더가 곧 어시스턴트의 전체 작업 공간이 된다는 점을 기억해 두십시오. VS Code 왼쪽 탐색기에서 "Open Folder"를 클릭해 방금 만든 폴더를 여는 순간, 빈 캔버스가 펼쳐집니다. 아직 파일은 하나도 없습니다.

[그림 21-1] VS Code에서 빈 프로젝트 폴더를 열었을 때의 화면 구성]

이제 이 빈 공간에 첫 번째 파일을 놓아야 합니다. 왼쪽 패널에서 "New File"을 클릭하고 파일 이름을 CLAUDE.md로 입력합니다. 이 파일이 어시스턴트의 두뇌 역할을 합니다. 에이전트가 사용자의 메시지를 읽기 전에, 매번 이 파일부터 로드하기 때문입니다.

CLAUDE.md에 모든 정보를 욱여넣으면 어떻게 될까요? 매 대화마다 방대한 텍스트가 로드되어 모델이 세는 글 조각(Token)을 낭비하게 됩니다. 그래서 이 파일에는 핵심 규칙과 "어디에 무엇이 있는지"를 알려주는 경로 안내만 적어 둡니다. 실제 상세 정보는 별도 파일에 담고, CLAUDE.md는 라우터(Router) 역할을 하도록 설계하는 것입니다.

# CLAUDE.md 구조 예시



## 역할

이 폴더는 사용자의 이그제큐티브 어시스턴트 작업 공간입니다.



## 컨텍스트 위치

- 사용자 정보: context/me.md

- 업무 정보: context/work.md

- 팀 정보: context/team.md

- 현재 우선순위: context/priorities.md



## 스킬 위치

- .claude/skills/ 하위 폴더 참조



## 커뮤니케이션 스타일

- 간결하고 직접적인 어조

[그림 21-2] CLAUDE.md의 라우팅 구조 다이어그램]

시작 단계에서 CLAUDE.md는 10에서 20줄이면 충분합니다. 이 파일은 어시스턴트가 성장하면서 함께 진화할 것이므로, 완벽하게 채우려고 애쓸 필요가 없습니다. 87줄 정도가 적정선이며, 150줄, 넉넉잡아 200줄을 넘기지 않는 것이 좋습니다.

에이전트에게 "이 폴더는 네가 나의 이그제큐티브 어시스턴트로 활동할 공간이야. CLAUDE.md에 간단한 설명을 넣어 줘"라고 말하면, 에이전트가 알아서 초기 내용을 작성해 줍니다. 이렇게 집의 기초가 놓입니다.

폴더 구조는 에이전트가 자동으로 생성해 주기도 합니다. 일반적으로 다음과 같은 뼈대가 잡힙니다.

프로젝트 루트/

├── CLAUDE.md

├── .claude/

│   ├── skills/

│   ├── agents/

│   └── rules/

├── context/

│   ├── me.md

│   ├── work.md

│   ├── team.md

│   └── priorities.md

├── decisions/

├── projects/

├── references/

├── templates/

└── archives/

[그림 21-3] 이그제큐티브 어시스턴트 프로젝트의 표준 폴더 구조]

각 폴더의 역할은 이름에서 짐작할 수 있습니다. context에는 사용자와 업무에 관한 정보가, decisions에는 중요한 의사결정 기록이, projects에는 진행 중인 프로젝트별 하위 폴더가 들어갑니다. 이 구조를 외울 필요는 없습니다. 에이전트에게 "이 폴더가 뭘 하는 거야?"라고 물으면 설명해 줄 테니까요.

여기서 한 가지 실용적인 조언이 있습니다. 이 프로젝트를 깃허브(GitHub)에 올려 두면 어떤 기기에서든 리포지토리를 끌어와 어시스턴트를 바로 사용할 수 있습니다. 백업, 롤백, 버전 관리까지 자동으로 따라옵니다. 물론 내 컴퓨터 깃(Git) 커밋만으로 시작해도 괜찮습니다. 깃허브 연동은 나중에 해도 됩니다.

2단계 '생명': 인터뷰를 통한 컨텍스트 구축

빈 집에 가구를 들이고, 냉장고를 채우고, 벽에 사진을 거는 과정이 바로 2단계입니다. 에이전트가 사용자를 알아가는 시간입니다.

이 과정은 인터뷰 형식으로 진행됩니다. 미리 준비된 온보딩 프롬프트(Onboarding Prompt)를 에이전트에게 전달하면, 에이전트가 질문을 던지기 시작합니다. "이름이 무엇인가요?" "역할은요?" "시간대는 어디인가요?" 기본적인 질문부터 시작해서, 사업 내용, 팀 구성, 현재 목표, 소통 방식까지 차근차근 파고듭니다.

이때 핵심 원칙은 '솔직하게, 충분히'입니다. 에이전트가 물어보는 질문에 성의 있게 답할수록, 나중에 "아, 이것도 알려줬어야 했는데"라며 같은 맥락을 반복 설명하는 횟수가 줄어듭니다. 답을 모르는 항목은 "스킵"이라고 말해도 됩니다. 나중에 채워 넣을 수 있으니까요.

에이전트의 질문은 대략 여섯 개 영역을 다룹니다.

1. 개인 정보: 이름, 역할, 시간대, 업무 스타일
2. 사업과 업무: 회사명, 사업 분야, 주요 제품이나 서비스
3. 팀: 함께 일하는 핵심 인물, 역할 분담
4. 우선순위와 목표: 이번 분기 목표, 긴급 과제, 연간 방향
5. 소통 선호: 간결한 답변을 좋아하는지, 상세한 설명을 원하는지
6. 자동화 희망 업무: 반복되는 일, 위임하고 싶은 업무

인터뷰가 끝나면 에이전트는 답변을 바탕으로 네 개의 핵심 파일을 생성합니다.

• me.md: 사용자 개인에 관한 정보. 이름, 배경, 성향, 선호하는 소통 방식.
• work.md: 사업과 회사에 관한 정보. 업종, 제품, 비즈니스 모델.
• team.md: 팀원 정보. 이름, 역할, 담당 업무.
• priorities.md: 현재 집중하고 있는 과제. 분기 목표, 긴급 사안, 마일스톤.

[그림 21-4] 인터뷰 기반 컨텍스트 파일 생성 흐름도]

이 파일들은 context 폴더 안에 저장됩니다. 그리고 CLAUDE.md는 자동으로 업데이트되어, "사용자 정보가 필요하면 context/me.md를 읽어라"는 식으로 경로를 안내하게 됩니다.

여기에 추가적인 파일도 생성됩니다. decisions/log.md에는 주요 의사결정이 날짜, 결정 내용, 이유, 맥락과 함께 기록됩니다. 프로젝트별 폴더에는 각 프로젝트의 설명 파일이 들어갑니다. .claude/rules/ 폴더에는 소통 스타일 규칙이 저장됩니다. 엠 대시(em dash)를 쓰지 말 것, 내부 소통은 캐주얼하게 할 것 같은 세부 지침들입니다.

이 모든 과정이 끝나면 에이전트는 초기 깃 커밋을 수행합니다. 첫 번째 스냅샷이 저장되는 것입니다.

한 가지 기억해 둘 점이 있습니다. 이 파일들은 고정된 문서가 아닙니다. 사업 방향이 바뀌면 work.md를, 새 팀원이 합류하면 team.md를 업데이트하면 됩니다. 에이전트에게 "이거 기억해 둬"라고 말하면, 해당 정보가 적절한 파일에 반영됩니다.

3단계 '손': 첫 번째 스킬 만들기

집을 짓고 생명을 불어넣었으니, 이제 손을 달아 줄 차례입니다. 에이전트가 생각만 하는 것이 아니라 실제로 무언가를 수행할 수 있게 만드는 단계입니다.

스킬(Skill)은 재사용 가능한 지시문입니다. 한번 작성해 두면, 슬래시 명령이나 자연어로 언제든 호출할 수 있고, 매번 같은 프로세스를 따르기 때문에 결과의 일관성이 높아집니다. 앞서 워크플로(Workflow)라는 개념을 다뤘는데, 스킬은 워크플로의 또 다른 이름이라고 보면 됩니다. 워크플로에 도구(Tool)가 있었듯, 스킬에는 파이썬 스크립트가 있습니다. 본질은 같습니다.

첫 번째 스킬로 무엇을 만들면 좋을까요? 프로젝트 관리 도구와의 연동이 실용적인 선택입니다. 클릭업(ClickUp), 노션(Notion), 아사나(Asana) 등 자신이 쓰는 도구의 API 키를 .env 파일에 넣고, 에이전트가 해당 도구와 소통할 수 있도록 스킬을 구성하는 것입니다.

스킬을 만드는 과정을 리서치 스킬을 예로 살펴보겠습니다. 계획 모드(Plan Mode)에서 에이전트에게 이렇게 말합니다. "리서치 스킬을 만들어 줘. 퍼플렉시티(Perplexity) API를 쓸 거야. .env 파일을 먼저 만들어 주고, 스킬이 하는 일은 단순 웹 검색이 아니라 내 사업 맥락을 반영한 깊이 있는 조사야."

에이전트는 프로젝트 구조를 탐색하고, 필요하면 보조 에이전트(Subagent)를 띄워 구조를 분석한 뒤, 계획을 세워 돌아옵니다. 그 계획에는 다음이 포함됩니다.

• .env 파일 생성 (API 키 보관용)
• .claude/skills/research/skill.md 작성
• CLAUDE.md 업데이트 (새 스킬 등록)

[그림 21-5] 스킬의 기본 구조: YAML 프론트매터 + 단계별 지시문]

스킬 파일의 구조는 명쾌합니다. 상단에 YAML(YAML Ain't Markup Language) 프론트매터가 있고, 그 아래에 마크다운으로 작성된 단계별 지시문이 따릅니다. 프론트매터에는 스킬 이름과 설명이 들어가며, 에이전트는 이 부분만 읽고 어떤 스킬을 호출할지 판단합니다. 전체 지시문은 스킬이 선택된 뒤에야 로드됩니다.

이 방식을 점진적 컨텍스트 로딩(Progressive Context Loading)이라 하며, 모델이 세는 글 조각 낭비를 막는 핵심 메커니즘입니다.

스킬이 완성되면 검증해 봐야 합니다. "리서치 스킬을 써서 포틀랜드의 아이스크림 행사를 조사해 줘"라고 입력하면, 에이전트가 스킬을 읽고, 퍼플렉시티 API를 호출하고, 결과를 정리해서 research/ 폴더에 보고서로 저장합니다. 보고서에는 출처 링크까지 포함됩니다.

보조 에이전트를 활용하면 비용을 절감할 수 있습니다. 메인 에이전트는 Opus 모델을 쓰지만, 리서치를 보조 에이전트에 위임하면서 Haiku처럼 가벼운 모델을 지정할 수 있습니다. 리서치의 질은 퍼플렉시티 API가 보장하고, 정리와 요약만 가벼운 모델이 맡으니 품질 저하 없이 비용이 줄어드는 구조입니다.

보조 에이전트는 .claude/agents/ 폴더에 마크다운 파일로 저장됩니다. 자체 컨텍스트 윈도(Context Window)를 갖고 독립적으로 작동합니다.

4단계 '성장': 매일 사용하며 어시스턴트를 진화시키기

4단계는 따로 설정할 것이 없습니다. 매일 사용하는 것 자체가 4단계입니다.

앞서 언급한 AI 자동화 컨설턴트의 어시스턴트가 처음부터 수십 개의 스킬과 촘촘한 컨텍스트를 갖추고 있었던 것은 아닙니다. 첫날에는 빈 폴더 하나와 CLAUDE.md 한 줄이 전부였습니다. 한 달 뒤, 그 프로젝트는 완전히 다른 모습이 되었습니다. 문서가 늘었고, 의사결정 로그가 쌓였고, 스킬이 추가되었으며, 에이전트의 응답 정밀도가 눈에 띄게 올라갔습니다.

성장의 비결은 수정 의견 순환(Feedback Cycle)에 있습니다. 스킬을 호출하고, 에이전트가 작업하는 과정을 관찰하고, "이 부분은 좋았고, 저 부분은 고쳐야 해"라고 말하면, 에이전트가 스킬 파일을 수정합니다. 처음 두세 번은 결과물이 AI가 생성한 티가 날 수 있습니다. 하지만 열 번, 스무 번 반복하면, 사용자의 취향과 업무 맥락이 스킬에 깊이 각인됩니다.

구체적인 성장 전략은 다음과 같습니다.

기존 도구를 이주시키기. ChatGPT의 커스텀 GPT나 클로드 프로젝트에 저장해 둔 시스템 프롬프트가 있다면, 그 지시문을 가져와 스킬로 전환합니다. "이 프롬프트를 스킬로 만들어 줘"라고 에이전트에게 맡기면 됩니다.

반복 작업을 포착하기. 같은 지시를 두 번 이상 내리고 있다면, 그것은 스킬로 만들 후보입니다. 엠 대시를 쓰지 말라고 매번 말하고 있다면, 그 규칙은 스킬이나 규칙 파일에 한번 적어 두는 편이 낫습니다.

에이전트의 작업 과정을 관찰하기. 처음 몇 번은 에이전트가 스킬을 실행하는 과정을 지켜봐야 합니다. 불필요한 API 호출을 반복하고 있다면, 자주 쓰는 ID 값을 스킬 파일에 하드코딩해서 모델이 세는 글 조각과 시간을 아낄 수 있습니다. 이 관찰과 개선의 루프가 성장을 가속합니다.

새 폴더를 자유롭게 추가하기. 브랜드 에셋(Brand Asset) 폴더를 만들어 로고, 폰트, 브랜드 가이드라인을 넣어 두면, 콘텐츠 생성 스킬이 브랜드 일관성을 유지할 수 있습니다. 폴더를 추가한 뒤 에이전트에게 "brand-assets 폴더를 추가했어. CLAUDE.md를 업데이트해 줘"라고 말하면 됩니다.

[그림 21-6] 시간에 따른 어시스턴트의 진화 곡선: 1일차 vs 30일차]

자동 메모리 기능도 활용할 수 있습니다. "나는 항상 X를 선호한다는 걸 기억해 둬"라고 말하면, 에이전트가 해당 내용을 적절한 파일에 저장하고 이후 대화에서 자동으로 반영합니다.

기존 ChatGPT·커스텀 GPT와 차별화되는 지점

ChatGPT나 클로드 웹 인터페이스에서 메모리를 저장하고, 커스텀 프롬프트를 설정하는 것만으로도 생산성은 올라갑니다. 그러나 한계가 있습니다. "이 맥락도 알아줬으면 좋겠는데"라고 느끼는 순간, 결국 추가 설명을 타이핑하고 있습니다. 50%까지는 빠르게 도달하지만, 90%에 이르기가 어렵습니다.

차이가 발생하는 지점을 살펴보겠습니다.

파일 시스템 전체에 대한 접근. 커스텀 GPT는 대화 창 안에서만 작동합니다. 그러나 코드 기반 이그제큐티브 어시스턴트는 프로젝트 폴더 안의 모든 파일을 읽고 쓸 수 있습니다. me.md, work.md, priorities.md, 리서치 보고서, 의사결정 로그 — 에이전트가 필요한 순간에 필요한 파일을 직접 열어봅니다. 대화 창에 모든 맥락을 붙여 넣을 필요가 없습니다.

도구 실행 능력. 커스텀 GPT는 텍스트를 생성합니다. 이그제큐티브 어시스턴트는 파이썬 스크립트를 실행하고, API를 호출하고, 파일을 생성하며, 보조 에이전트를 띄웁니다. 캘린더를 확인하고 일정을 자동으로 블로킹하는 것, 클릭업에서 태스크 상태를 가져오는 것, 이 모든 동작이 대화 한 줄로 가능합니다.

컨텍스트의 영속성과 구조화. 대화가 길어지면 컨텍스트 윈도 한계에 부딪힙니다. 이그제큐티브 어시스턴트는 중요한 정보를 파일로 분리해 영구 저장합니다. 대화를 초기화해도 파일은 남아 있으므로, 다음 세션에서 곧바로 이전 맥락을 이어갈 수 있습니다. 기억을 잃지 않는 비서인 셈입니다.

성장 가능성. 커스텀 GPT의 시스템 프롬프트는 정적입니다. 수동으로 수정해야 합니다. 이그제큐티브 어시스턴트는 사용할수록 파일이 늘어나고, 스킬이 정교해지며, 의사결정 이력이 축적됩니다. 에이전트에게 "이 경험을 기록해 둬"라고 말하면, 다음에 비슷한 상황이 왔을 때 더 나은 판단을 내릴 수 있는 기반이 됩니다.

[그림 21-7] 기존 ChatGPT 방식과 이그제큐티브 어시스턴트 방식의 비교표]

마무리

네 개의 단계는 순서대로 밟되, 속도는 자유롭게 조절하면 됩니다. 집을 짓는 데 10분이면 충분하고, 생명을 불어넣는 인터뷰는 시간을 들여 정성껏 할수록 이후가 편해집니다. 첫 스킬은 작게 시작하되, 매일 한두 가지씩 수정 의견을 주면서 키워 나갑니다.

이 프레임워크의 진짜 힘은 3단계에서 만든 첫 번째 스킬이 매일 아침 실제로 작동하기 시작할 때 드러납니다. 캘린더를 읽고, 프로젝트 상태를 확인하고, 오늘 무엇을 해야 하는지 정리해 주는 그 스킬 — '모닝커피'라 불리는 루틴이 어떻게 하루를 바꿔 놓는지, 이어지는 이야기에서 확인해 볼 수 있습니다.