서론

「인간 1명 + AI 에이전트 9개 부서」로 회사를 운영하는 메커니즘을 만들었습니다.

사용하고 있는 것은 Claude Code(Anthropic사의 CLI형 AI 에이전트)와 Git 리포지토리뿐입니다. 특별한 프레임워크나 플랫폼은 사용하지 않습니다.

이 기사에서는 디렉터리 구조, CLAUDE.md의 설계, 에이전트 간의 연계 방법 등 기술적인 구현을 해설합니다.

기술 스택

- AI 에이전트: Claude Code (claude-opus-4)
- 리포지토리: Git (GitHub)
- 병렬 실행: cmux (1태스크 = 1 worktree = 1페인)
...

특기할 점은, 프로덕트의 코드뿐만 아니라 경영 판단·리서치·기획·마케팅 정보도 모두 동일한 Git 리포지토리에 집약하고 있다는 점입니다.

디렉터리 구조

shinyu-company/
├── CLAUDE.md # 회사 헌법 (전사 공통 규칙)
├── departments/
...

설계상의 포인트

**1. 부서 번호 프리픽스 (10, 15, 20...)

파일 시스템의 정렬 순서가 업무 흐름의 순서와 일치하도록 하고 있습니다. 전략(10) → 리서치(15) → 기획(20) → 개발(30) → 마케팅(40) → 수익화(50) → 세일즈(60) → 코퍼레이트(70) → 운영(80)이라는 흐름입니다.

번호를 10 단위로 설정한 이유는 나중에 부서를 추가할 수 있도록 하기 위해서입니다. 실제로 리서치부(15)는 나중에 추가했습니다.

**2. 상태 파일의 집약 (docs/)

docs/ 하위에 「회사의 현재 상태」를 나타내는 파일을 집약하고 있습니다. 에이전트는 작업 시작 시 이를 읽고, 작업 종료 시 업데이트합니다. 말하자면 **싱글 소스 오브 트루스 (Single Source of Truth)**입니다.

**3. LP는 별도 리포지토리

프로덕트의 LP(랜딩 페이지)는 <프로덕트명>-lp라는 별도 리포지토리로 분리하여 Vercel과 연계하고 있습니다. 모노레포(Monorepo) 내에 LP를 두면 배포의 독립성이 상실되기 때문입니다.

CLAUDE.md의 설계

Claude Code는 현재 디렉터리와 그 상위 디렉터리의 CLAUDE.md를 자동으로 읽어들입니다. 이 메커니즘을 사용하여, 계층적인 지시서를 구성하고 있습니다.

루트의 CLAUDE.md (회사 헌법)

루트의 CLAUDE.md에는 모든 부서가 따라야 할 공통 규칙을 적고 있습니다.

# 회사 헌법
## 0. 전제
- 종업원은 CEO 1명 (인간). 실무는 각 부서의 Claude Code 에이전트가 담당한다.
...

여기에 적는 내용은 200행 이내로 제한하고 있습니다. 너무 길면 컨텍스트(Context)를 압박하여, 각 부서의 지시서와 합쳤을 때 퍼포먼스가 저하되기 때문입니다.

부서의 CLAUDE.md (부서 매뉴얼)

각 부서의 CLAUDE.md는 다음과 같은 통일된 포맷으로 작성합니다.

# 부서명
> 역할: 한 문장으로 정의
## 판단 기준
...

포맷을 통일하는 이유는, 부서를 넘나드는 태스크 라우팅 (Routing)을 가능하게 하기 위해서입니다. 루트의 CLAUDE.md에 「태스크를 받으면 먼저 어느 부서의 일인지 선언한 다음, 해당 부서의 CLAUDE.md를 읽고 작업한다」라는 규칙을 적어두었습니다.

계층 구조의 장점

CLAUDE.md (회사 헌법) ← 모든 에이전트가 읽음
└── departments/40-marketing/CLAUDE.md ← 마케팅부 에이전트가 추가로 읽음

이 2층 구조를 통해 공통 규칙(숫자 조작 금지, 되돌릴 수 없는 결정은 인간에게 보고 등)은 한 곳에서 관리하면서, 부서 고유의 규칙(채널은 하나로 압축 등)은 각 부서에 분산할 수 있습니다.

에이전트 간의 연계

cmux를 통한 병렬 실행

1태스크 = 1 git worktree = 1페인

동일한 파일을 두 개의 에이전트가 동시에 편집하는 것을 방지하기 위해, 태스크마다 git worktree를 생성하고 있습니다. 병렬 상한은 3으로 설정했습니다. 그 이상은 리뷰(인간의 눈)가 따라가지 못하기 때문입니다.

부서 간 의뢰 프로토콜

각 작업이 완료될 때, 에이전트는 「다음 액션」을 선언합니다.

## 다음 액션
- 수신: CEO / 부서명
- 의뢰 내용: 구체적인 의뢰
...

가역적인(Reversible) 의뢰는 에이전트 간에 직접 연계할 수 있지만, 불가역적인 의뢰(가격 변경, 공개물, 운영 환경 조작)는 CEO를 거쳐 승인을 받습니다.

상태 관리 메커니즘

가설 시트 (docs/ideas/)

사업 아이디어마다 Markdown 파일을 생성하여, 상태(Status)를 프론트매터(Frontmatter)로 관리하고 있습니다.

# 가설: ○○하면 △△가 해결된다
- status: seed
- win_rate: 69

상태 전이는 다음과 같습니다.

seed → drafting → validating → validated → approved / rejected

이는 Git으로 관리하기 때문에, 상태 변경 이력이 모두 커밋 로그(Commit log)에 남습니다. "언제, 누가, 왜 이 판단을 내렸는가"를 추적할 수 있습니다.

워크플로우 정의 (docs/workflow.md)

파이프라인 전체를 정의하는 파일입니다.

[씨앗] → [가설 설계] → [검증] → ★CEO Gate 1 → [PRD] → [설계] → ★CEO Gate 2 → [구현] → [릴리스]

CEO 판단 게이트가 2곳 있으며, 검증 완료 시점과 설계 완료 시점에 Go/No-Go 판단을 수행합니다.

실제로 실행해 본 결과

이 메커니즘을 통해 다음과 같은 것들을 실현하고 있습니다.

• 리서치 부서가 매일 트렌드 리포트를 자동 생성
• 기획 입안 부서가 38건의 가설 시트를 작성하고, 5축 스코어링(Scoring)으로 평가
• 마케팅 부서가 note/Zenn 기사 초안을 생성
• 프로덕트 개발 부서가 LP를 작성하고 Vercel에 배포

이제 막 시작한 단계라 매출은 0입니다. 하지만, 혼자서는 도저히 처리할 수 없는 양의 병렬 작업이 돌아가고 있는 것은 사실입니다.

요약

• AI 에이전트의 조직 설계는 디렉터리 구조 + CLAUDE.md만으로 실현할 수 있습니다.
  • CLAUDE.md는 계층 구조로 구성하여, 공통 규칙(Root)과 부서 고유 규칙(각 부서)을 분리합니다.
• 중요한 것은 "해야 할 일"보다 "하지 말아야 할 일"(가드레일, Guardrail)의 정의입니다.
• 상태 파일을 Git으로 관리함으로써 판단 이력이 자동으로 남습니다.

다음 회차에서는 가설 시트의 스코어링 기법과 검증 파이프라인 설계에 대해 자세히 설명하겠습니다.

Discussion