
#7에서 "1인 = 1팀"이라고 했다. Skills, MCP, 서브에이전트를 쓰면 혼자서도 팀처럼 일할 수 있다고.
그래서 실제로 해봤다. 워크스페이스를 3개로 나눠서 "팀"을 만들어봤다.
결론부터 말하면, 다시 합쳤다.
역할별로 이름을 붙여서 워크스페이스 3개를 만들었다:
planner/ ← 기획·조언 담당
brand/ ← 브랜딩·콘텐츠 담당
dev/ ← 개발 담당
각 워크스페이스에서 Claude Code를 따로 실행한다. 역할별로 CLAUDE.md가 다르고, 컨텍스트가 분리된다. 개발 담당이 코드를 수정하는 동안 브랜딩 담당이 콘텐츠를 쓰는, 그런 구조를 상상했다.
문제는 이 "팀원들"이 서로 대화를 못한다는 거다.
Claude Code 세션은 서로 독립적이다. A 워크스페이스의 Claude가 B 워크스페이스의 Claude에게 직접 말을 걸 수 없다.
해결책으로 shared/inbox 폴더를 만들었다:
shared/
inbox/
to-dev.md ← brand가 dev한테 보내는 메모
to-brand.md ← dev가 brand한테 보내는 메모
to-planner.md ← 둘 다 planner한테 보내는 메모
to-all.md ← 전체 공유
한 워크스페이스에서 작업이 끝나면, 다른 쪽에 전달할 내용을 inbox 파일에 적는다. 받는 쪽은 다음 세션을 시작할 때 inbox를 읽고 이어서 작업한다.
이론은 깔끔했다.
| 문제 | 내용 |
|---|---|
| 전환 비용 | 창 3개를 왔다 갔다, 맥락이 끊긴다 |
| 라우터 = 나 | 메모가 자동 전달되지 않는다. 내가 직접 확인하고 옮겨야 한다 |
| 맥락 재로딩 | 워크스페이스를 바꿀 때마다 "이전 내용 파악해줘"부터 시작 |
| inbox 관리 | 메모가 쌓이면 어디까지 읽었는지 추적이 안 된다 |
"팀을 구성한다"고 생각했는데, 실제로는 내가 팀의 메신저가 된 거다.
에이전트 3명이 있어도, 그 사이에서 메모를 전달하는 건 나 혼자다. 회사라면 슬랙이 있고, 회의가 있고, 사람이 여러 명이다. 여기선 전부 내 몫이다.
brand + dev를 "builder"로 합쳤다.
| Before | After | |
|---|---|---|
| 워크스페이스 | 3개 | 2개 (planner, builder) |
| inbox | 4개 | 2개 |
| CLAUDE.md | 역할별 3개 | 통합 2개 |
브랜딩과 개발이 같은 프로젝트를 다루고 있었기 때문에, 하나의 CLAUDE.md에 두 역할의 컨텍스트를 넣는 게 오히려 자연스러웠다. Claude가 맥락을 유지한 채로 역할을 전환할 수 있으니까.
워크스페이스를 합치면서 겪은 실수도 있다:
.claude/ 폴더는 자동 생성되지만, 내용은 아니다. 새 워크스페이스에서 Claude Code를 시작하면 .claude/ 폴더는 자동으로 만들어진다. 하지만 이전 워크스페이스에 쌓아둔 메모리 내용(CLAUDE.md, 메모리 파일 등)은 수동으로 옮겨야 한다.완전히 독립적인 프로젝트일 때만 나누는 게 효과적이다.
나눠야 할 때:
→ 웹사이트와 영상 제작처럼 서로 참조할 일이 거의 없는 경우
합쳐야 할 때:
→ 같은 프로젝트 안에서 역할만 다른 경우
→ CLAUDE.md 하나에 역할을 정리하는 게 낫다
역할 분리가 필요하면 워크스페이스를 나누는 게 아니라, CLAUDE.md 안에서 역할을 구분하면 된다. Claude는 하나의 세션에서도 "지금은 브랜딩 작업이야"라고 하면 그에 맞게 동작한다.
| 시도 | 결과 |
|---|---|
| 워크스페이스 3개 분리 | 역할 격리는 됐지만 전환 비용이 너무 컸다 |
| inbox 파일 전달 | 자동화 없음 → 내가 메신저가 됨 |
| 2개로 통합 | 전환 비용 절반, 맥락 유지 향상 |
#7에서 "1인 = 1팀"이라고 했다. 맞다. 하지만 팀원 수를 늘리는 것보다, 한 팀원이 잘하게 만드는 게 먼저다.
워크스페이스를 3개로 나누는 건 "팀원 3명을 뽑는 것"이 아니라, "1명한테 이름표 3개 붙이고 자리를 3번 옮기게 하는 것"이었다.
이 글은 Claude Code 플레이북을 만들면서 배운 것을 비개발자 시점으로 정리한 시리즈입니다.