CLAUDE.md로 AI 에이전트 조직 만드는 법

Orchestrator 패턴과 권한 설정 완전 해설

Claude Code란 무엇인가

이 책을 읽고 있는 분들 대부분은 GitHub Copilot이나 Cursor 같은 AI 코딩 도구를 사용해본 경험이 있을 것이다. Claude Code는 그것들과 근본적으로 다른 도구다.

GitHub Copilot이나 Cursor는 에디터에 통합된 "코드 자동완성 도구"의 연장선상에 있다. 코드를 작성하는 도중에 다음 줄을 제안해준다. 편리하지만, 어디까지나 에디터 안에서 완결된다.

Claude Code는 다르다. 터미널에서 동작하며, 파일 읽기·쓰기, 커맨드 실행, Git 조작 등 개발자가 터미널에서 하는 일의 거의 모든 것을 대신할 수 있다. 코드 자동완성이 아니라, 개발 프로세스 전체를 위임할 수 있는 도구다.

그리고 이 책의 맥락에서 가장 중요한 것은, CLAUDE.md라는 파일을 통해 AI의 행동·역할·제약을 세밀하게 정의할 수 있다는 점이다. 이를 통해 Claude Code는 "똑똑한 코드 자동완성"에서 "설정 가능한 AI 에이전트"로 변한다.

플랜 선택 — 왜 Max 플랜인가

Claude Code를 사용하려면 Anthropic의 플랜에 가입해야 한다. 2026년 3월 시점의 선택지는 다음과 같다.

필자는 Max 5x（$100/월）에서 시작해서, 이용량에 따라 Max 20x（$200/월）로 전환하고 있다.

AI 에이전트 경영을 하려면 Max 플랜은 필수다. 이유는 세 가지다.

장시간 세션: 에이전트에게 스프린트 전체를 위임하면 1세션이 수십 분에 이르는 경우가 있다. Pro 플랜에서는 이용 제한에 걸린다

큰 컨텍스트: 6개 프로덕트의 상태 관리 파일, 에이전트 정의 파일, 코드베이스를 동시에 다루려면 충분한 컨텍스트 윈도우가 필요하다

빈번한 이용: 하루에 복수의 부문 에이전트를 가동하기 때문에 사용량이 많다

월 $100~200은 저렴하지 않다. 하지만 1장에서 언급했듯, "6개 부문의 부하를 월 15만~30만 원에 고용할 수 있다"고 생각하면 투자 대비 효과는 매우 높다.

셋업 순서

1. Claude Code 설치

# npm으로 글로벌 설치
npm install -g @anthropic-ai/claude-code

# 설치 확인
claude --version

2. 인증

# 초회 실행 시 인증 플로우가 시작된다
claude

# 브라우저가 열리고 Anthropic 계정으로 로그인
# Max 플랜에 가입된 계정으로 로그인한다

3. 프로젝트 디렉토리 초기화

# 프로젝트의 루트 디렉토리로 이동
cd ~/workspace/your-project

# Claude Code 실행
claude

# 초회 실행 시, CLAUDE.md가 존재하지 않으면
# 기본 설정으로 동작한다

여기까지는 일반적인 Claude Code 셋업이다. 여기서부터 AI 에이전트 경영을 위한 설정에 들어간다.

CLAUDE.md 작성법 — Orchestrator로서 정의하기

CLAUDE.md는 Claude Code가 프로젝트에서 실행될 때마다 가장 먼저 읽어들이는 설정 파일이다. 프로젝트 루트에 배치한다.

일반적인 사용법에서는 코딩 규약이나 프로젝트 고유의 지시를 쓰는 정도다. 하지만 AI 에이전트 경영에서는, CLAUDE.md에 Orchestrator(총괄자)로서의 역할을 정의한다. 이것이 단순한 도구 활용과 조직 설계의 갈림길이 된다.

CLAUDE.md의 기본 구조

필자가 실제로 사용하고 있는 CLAUDE.md의 구조를, 핵심을 추려 해설한다.

# AI-CEO Framework -- CEO-Suite Orchestrator

> 당신은 AI-CEO Framework의 「CEO-Suite Orchestrator」입니다.
> CEO의 경영 판단을 지원하고, 6개 부문의 AI 에이전트를 통괄합니다.

## 당신의 역할

당신은 CEO와 직접 대화하는 유일한 인터페이스입니다.
다음을 담당합니다:

1. CEO 커맨드 접수와 실행
2. 부문 간 조정
3. 승인 관리
4. 프로덕트 횡단 관리

## Thin Orchestrator의 원칙
- 컨텍스트 사용률을 10~15%로 유지한다
- 파일 내용을 자신의 컨텍스트에 읽어들이지 않고, 파일 경로만 전달한다
- 복잡한 태스크는 반드시 서브 에이전트에 위임한다
- 자신이 실작업을 수행하지 않는다

도입부 선언이 중요하다. "당신은 CEO-Suite Orchestrator입니다"라고 명시함으로써, Claude Code는 "자신은 도구가 아니라 조직의 총괄자로서 행동해야 한다"고 이해한다. 이 한 줄이 일반적인 AI 코딩 보조와 AI 에이전트 조직의 분기점이다.

회사 정보 참조처를 정의한다

## 회사 정보 참조처

- 비전·미션: `.company/VISION.md`
- 현재 경영 상태: `.company/STATE.md`
- 분기 로드맵: `.company/ROADMAP.md`
- CEO 의사결정 로그: `.company/decisions/` (해당 월 파일)
- 권한·임계값 설정: `.company/steering/permissions.md`
- 승인 대기 큐: `.company/approval-queue.md`
- 브랜드·기술 규약: `.company/steering/`
- 프로덕트별 상태: `.company/products/`
- 부문별 상태: `.company/departments/`

여기서 "파일 경로"만 열거하는 것이 핵심이다. 파일 내용은 여기에 쓰지 않는다. Thin Orchestrator 원칙에 따라, 필요할 때 에이전트가 스스로 읽으러 간다. 노션(Notion) 링크나 구글 드라이브(Google Drive) URL 대신 로컬 파일 경로를 사용하는 이유도 여기에 있다 — 에이전트가 직접 파일을 읽고 쓸 수 있어야 하기 때문이다.

커맨드 체계를 정의한다

## CEO 커맨드 일람

### 일상 운용
- `/ai-ceo:morning` -- 아침 다이제스트 생성
- `/ai-ceo:status` -- 현재 전체 상태

### 승인 조작
- `/ai-ceo:approve <id>` -- 승인
- `/ai-ceo:reject <id> "이유"` -- 반려

### 부문 커맨드
- `/ai-ceo:dev:sprint` -- 스프린트 계획·실행
- `/ai-ceo:dev:hotfix "설명"` -- 긴급 버그 수정
- `/ai-ceo:mkt:campaign "개요"` -- 마케팅 캠페인
- `/ai-ceo:mkt:content-plan` -- 월간 콘텐츠 캘린더
...

커맨드를 정의해두면 CEO는 장황하게 자연어로 지시를 쓸 필요가 없어진다.

/ai-ceo:dev:sprint라고 입력하는 것만으로 Orchestrator는 "CTO 에이전트에게 스프린트 계획을 위임한다"고 이해한다. 슬랙 봇의 슬래시 커맨드와 유사한 개념이라고 생각하면 직관적으로 이해하기 쉽다.

커맨드 실행 플로우를 정의한다

커맨드 이름만으로는 충분하지 않다. 각 커맨드가 "무엇을 하는가"를 구체적인 단계로 정의한다.

### /ai-ceo:morning 의 실행 플로우
1. 각 부문의 `.company/departments/{dept}/STATE.md`를 읽어들인다
2. `.company/approval-queue.md`의 승인 대기 아이템을 읽어들인다
3. 각 프로덕트의 `.company/products/{name}/STATE.md`를 읽어들인다
4. 다음 포맷으로 다이제스트를 생성한다:

## 승인 대기 ({n}건)
- [AQ-xxx] {부문}: {내용} | {파일 경로}

## 부문 상태 요약
| 부문 | 상태 | 진행 중 태스크 | 주의 사항 |
...

이처럼 입력(무엇을 읽는가), 처리(무엇을 하는가), 출력(무엇을 생성하는가)을 명확히 정의한다. 모호함을 없앨수록 에이전트의 출력 품질이 안정된다. "요약해줘"라는 지시보다 "이 파일들을 읽고, 이 포맷으로 생성해줘"가 훨씬 일관된 결과를 낸다.

권한 제어 룰을 넣는다

## 권한 제어 룰

모든 액션은 `.company/steering/permissions.md`의 임계값에 따른다.

- **read-only:** 분석·리포트 계열은 승인 불필요, 자동 실행
- **draft:** 대외 액션（이메일 발송, 청구서 발행, SNS 게시, 배포 등）은 반드시 draft 모드로 생성하고, approval-queue.md에 추가
- **execute:** 임계값 이내의 내부 액션（버그 수정, 테스트 실행 등）은 자동 실행

**중요:** 대외에 영향이 있는 액션을 직접 실행해서는 안 된다.
반드시 draft → 승인 → 실행 파이프라인을 통한다.

이 선언이 승인 파이프라인의 진입점이다. CLAUDE.md에 명기함으로써, Orchestrator가 호출하는 모든 서브 에이전트에도 이 제약이 적용된다. 이 한 줄이 "AI가 멋대로 고객에게 이메일을 보내는" 사태를 막는다.

에러 핸들링

## 에러 시의 행동

- 서브 에이전트가 실패한 경우: 에러 내용을 피드백하여 최대 3회 리트라이
- 3회 실패: `.company/approval-queue.md`에 에스컬레이션으로 추가하고 CEO에게 보고
- 에러 로그: `.company/departments/{dept}/error-log.md`에 추기

AI 에이전트는 실패한다. 코드 생성에 실패하기도 하고, 파일 읽기에 실패하기도 한다. 에러가 발생했을 때의 행동을 정의해두지 않으면, 에이전트는 에러를 묻어버리거나 끝없이 리트라이를 반복한다. 3회 리트라이해도 안 되면 CEO에게 보고한다는 룰이, 운용상 가장 균형이 좋다. 사람 직원도 막히면 상사에게 보고하는 것과 같은 이치다.

.claude/agents/ 에서의 서브 에이전트 정의

CLAUDE.md가 Orchestrator라면, .claude/agents/ 하위의 파일은 각 부문의 "에이전트 정의서"다.

파일 구성

.claude/agents/
├── ai-ceo-cto.md # CTO 부문
├── ai-ceo-cmo.md # CMO 부문
├── ai-ceo-content-engine.md # 콘텐츠 대량 생산
├── ai-ceo-cfo.md # CFO 부문
├── ai-ceo-cso.md # CSO 부문
├── ai-ceo-biz-dev.md # 사업 개발
├── ai-ceo-cs-lead.md # CS 부문
├── ai-ceo-legal.md # 법무 부문
├── ai-ceo-hr.md # 인사 부문
├── ai-ceo-growth.md # 그로스
├── ai-ceo-consulting-vp.md # 컨설팅 총괄
├── ai-ceo-init.md # 초기 셋업
├── ai-ceo-morning.md # 아침 다이제스트
└── ai-ceo-openclaw-ops.md # 자동화 기반

주목해야 할 것은, "부문 에이전트"뿐만 아니라 "기능 에이전트"도 정의하고 있다는 점이다.

ai-ceo-init.md는 초기 셋업 전용, ai-ceo-morning.md는 아침 다이제스트 전용 에이전트다. 자주 사용하는 워크플로우를 전용 에이전트로 분리함으로써 품질과 속도가 안정된다.

에이전트 정의 파일 작성법

CTO 부문의 에이전트 정의를 예로, 작성 패턴을 해설한다.

---
name: ai-ceo-cto
description: CTO/개발 부장 에이전트. 프로덕트 개발 전반을 통괄한다.
tools:
- Read
- Write
- Edit
- Bash
- Grep
---

# CTO / 개발 부장 에이전트

당신은 AI-CEO Framework의 CTO（최고 기술 책임자）입니다.

frontmatter(메타데이터)

---
name: ai-ceo-cto
description: CTO/개발 부장 에이전트.
tools:
- Read
- Write
- Edit
- Bash
- Grep
---

name: 에이전트 식별자. Orchestrator가 에이전트를 호출할 때 사용한다

description: 1행 설명. 어떤 것을 담당하는 에이전트인지 간결하게 기술한다

tools: 이 에이전트가 사용할 수 있는 도구. Bash를 포함하면 터미널 커맨드 실행이 가능해진다. 권한을 최소한으로 좁히는 것이 보안상 중요하다. 예를 들어 CMO 에이전트에게는 Bash를 부여하지 않는다

페르소나 정의

## 페르소나

경험 풍부한 테크 리드. 실용성을 중시하고 오버 엔지니어링을 피한다.
「동작하는 것을 최대한 빠르게 내놓고, 피드백을 받아 개선한다」가 모토.

페르소나를 정의하는 것은 출력의 일관성을 유지하기 위해서다. "실용성 중시"라고 써두면, 에이전트는 과도하게 복잡한 설계를 제안하기 어려워진다. 인간 엔지니어를 채용할 때 "어떤 타입의 사람인가"가 중요한 것과 같다. 페르소나가 없으면 같은 커맨드를 실행해도 매번 다른 성격의 결과물이 나온다.

권한 레벨

## 권한 레벨

- **execute:** 코딩, 테스트 실행, 스테이징 배포, 내부 문서
- **draft:** 프로덕션 배포, 아키텍처 대폭 변경, 신규 라이브러리 도입

각 에이전트에 허용되는 액션의 범위를 execute와 draft로 나눠 명기한다. 이를 통해 에이전트는 "자신의 판단으로 자동 실행해도 되는 것"과 "CEO의 승인을 받아야 하는 것"을 스스로 구별할 수 있다.

참조 파일 지정

## 참조 파일

- 기술 스택: `.company/steering/tech-stack.md`
- 프로덕트 상태: `.company/products/{name}/STATE.md`
- 개발 부문 상태: `.company/departments/dev/STATE.md`
- 권한 설정: `.company/steering/permissions.md`

에이전트가 참조해야 할 파일을 열거한다. 이것이 없으면 에이전트는 필요한 정보를 찾는 데 쓸데없이 컨텍스트를 소비한다. "당신에게 필요한 정보는 여기 있다"고 처음부터 알려주는 것으로 효율과 품질 모두 올라간다.

워크플로우 정의

## 워크플로우

### /ai-ceo:dev:sprint
1. `.company/products/{name}/STATE.md`에서 백로그를 확인한다
2. 우선도가 높은 태스크를 선정한다（최대 3태스크）
3. 각 태스크의 사양을 작성한다:
- Requirements (무엇을 만드는가)
- Design (어떻게 만드는가)
- Tasks (구현 태스크 리스트)
4. 구현
5. 코드 리뷰
6. 테스트 실행·확인
7. `.company/departments/dev/STATE.md`를 업데이트한다

워크플로우는 가능한 한 구체적인 단계로 분해한다. 모호한 스텝이 있으면 에이전트의 출력이 흔들린다. "백로그를 확인"이 아니라 ".company/products/{name}/STATE.md에서 백로그를 확인"이라고 씀으로써, 무엇을 읽어야 하는지가 명확해진다.

품질 검증 정의

## 품질 검증

모든 성과물에 다음의 검증을 적용한다:

1. 골 역산 검증: 「이 구현이 옳다면, {테스트}가 패스되어야 한다」→ 테스트 실행
2. tech-stack.md 준수 체크: 사용 기술이 규약에 맞는지
3. 보안 체크: 기본적인 보안 베스트 프랙티스

품질 검증 룰을 넣음으로써, 에이전트는 자신의 출력을 자기 검증한다. "구현 → 테스트 → 확인"의 사이클이 에이전트 내에서 완결되기 때문에, CEO가 코드를 하나하나 확인할 필요가 없어진다. 코드 리뷰의 1차 관문을 AI가 담당하는 구조다.

Permission 설정 — 안전하게 사용하기 위한 권한 관리

권한 관리는 AI 에이전트 경영의 안전성을 담보하는 가장 중요한 구조다.

permissions.md 의 전체 모습

# 권한·임계값 설정

## 비용 임계값

| 액션 | 임계값 | 모드 |
|------|--------|------|
| 자동 승인 상한 | 5만 원/건 | execute |
| CEO 승인 필요 | 5만 원 초과/건 | draft |
| 월간 AI 운용 예산 상한 | $200/월 | monitor |

금액의 임계값은 사업 규모에 맞춰 조정한다. 필자의 경우, 5만 원 미만의 액션(예: 도메인 갱신, 플러그인 구매)은 자동 승인, 5만 원 이상은 CEO 승인으로 하고 있다. 처음 도입할 때는 임계값을 낮게 설정하고 운용하면서 점차 높여가는 것을 권장한다.

개발 권한의 상세

# 자동 실행 가능（execute）
auto_execute:
- bugfix # 버그 수정
- minor_feature # 마이너 기능 추가
- test # 테스트 추가·수정
- refactor # 리팩토링
- docs # 문서 업데이트
- dependency_patch # 패치/마이너 업데이트

# CEO 승인 필요（draft）
ceo_approval:
- new_feature # 신기능 개발
- architecture_change # 아키텍처 변경
- deploy_production # 프로덕션 배포
- major_update # 메이저 업데이트
- new_dependency # 신규 라이브러리 도입
- schema_change # DB 스키마 변경

이 분류는 실제 운용을 거치며 조정해왔다. 처음에는 모든 것을 draft로 했지만, 버그 수정이나 테스트 추가까지 승인을 기다리는 것은 비효율적이었다. 반대로, 신기능 개발을 execute로 했더니 의도하지 않은 기능이 구현된 적도 있었다. 이 해상도에 안착하기까지 2~3주의 시행착오가 있었다. 처음부터 완벽한 설정은 없다고 생각하고 조금씩 조정해나가는 것이 현실적이다.

대외 커뮤니케이션의 권한

# 항상 draft（CEO 확인 필수）
always_draft:
- press_release # 보도자료
- pricing_change # 가격 변경 공지
- claim_response # 클레임·불만 대응
- proposal # 클라이언트 제안서
- contract # 계약서·NDA
- invoice # 청구서

# CEO 승인 후 자동 실행 가능
auto_after_approval:
- scheduled_sns # 승인된 템플릿에 기반한 SNS 게시
- faq_response # 승인된 템플릿에 기반한 FAQ 답변
- tech_article # 리뷰 완료 기술 아티클 게시

# 자동 실행 가능（read-only 계열）
auto_execute_readonly:
- analytics_report # 분석 리포트 생성
- kpi_update # KPI 대시보드 업데이트
- competitor_analysis # 경쟁 조사 리포트
- internal_docs # 사내 문서 업데이트

대외 커뮤니케이션은 가장 신중하게 관리하는 영역이다. 클라이언트에게 보내는 제안서나 청구서를 AI가 멋대로 발송하는 것은 허용되지 않는다. 반면, 사내용 분석 리포트나 문서 업데이트는 자동 실행으로 문제없다. 특히 한국에서는 세금계산서 발행이나 전자계약서와 같이 법적 효력이 발생하는 문서는 반드시 CEO가 최종 확인해야 한다.

반면, 사내용 분석 리포트나 KPI 업데이트는 자동 실행으로 문제없다. "대외 = draft, 대내 = execute"라는 기본 원칙만 기억해도 초기 설정의 80%는 커버된다.

배포 권한

deploy:
local: execute # 로컬 개발: 자유롭게 실행 가능
staging: execute # 스테이징: 자동 배포 가능
production: draft # 프로덕션: CEO 승인 후 배포

개발 환경과 스테이징 환경은 자동 배포를 허용하고, 프로덕션 환경만 CEO 승인을 필수로 한다. 스테이징 환경에서 에이전트가 자유롭게 배포·테스트할 수 있음으로써 개발 이터레이션 속도가 올라간다. Vercel, Firebase Hosting, AWS Amplify 등 CI/CD 파이프라인을 갖춘 환경이라면 이 구조를 그대로 적용할 수 있다.

Thin Orchestrator의 원칙 — 컨텍스트 관리의 실천

왜 컨텍스트 관리가 중요한가

Claude Code에는 한 번에 처리할 수 있는 정보량의 상한(컨텍스트 윈도우)이 있다. 6개 프로덕트의 상태, 8개 부문의 에이전트 정의, 수십 개의 파일 — 이것들을 모두 컨텍스트에 넣으면 순식간에 상한에 도달한다.

컨텍스트가 넘치면, 에이전트는 지시의 일부를 "잊거나" 품질이 저하된다. 이를 방지하는 것이 Thin Orchestrator의 원칙이다.

실천 패턴

패턴1: 파일 경로만 전달한다

# 나쁜 예 (컨텍스트를 압박한다)
## 현재 경영 상태
유한회사 MD룰는 6개의 프로덕트를 운영하고 있으며...
(STATE.md의 전체 내용을 CLAUDE.md에 복사)

# 좋은 예 (경로만 지정한다)
## 회사 정보 참조처
- 현재 경영 상태: `.company/STATE.md`

CLAUDE.md에는 파일 경로만 쓰고, 실제 파일 내용은 서브 에이전트가 필요할 때 읽어들인다. Orchestrator 자신의 컨텍스트 소비를 최소한으로 억제한다.

패턴2: 서브 에이전트에 위임한다

# 나쁜 예 (Orchestrator가 실작업을 한다)
/ai-ceo:dev:sprint 라고 입력되면, 코드를 작성하고, 테스트하고,
PR을 작성하세요.

# 좋은 예 (서브 에이전트에 위임한다)
/ai-ceo:dev:sprint 라고 입력되면, ai-ceo-cto 에이전트에
다음 정보를 전달하고 위임하세요:
1. 태스크의 목적
2. 참조 파일 경로
3. 성과물의 출력처
4. 권한 레벨
5. 품질 기준

Orchestrator는 작업을 직접 하지 않는다. 태스크의 목적과 컨텍스트(파일 경로)를 서브 에이전트에 전달할 뿐이다.

패턴3: 필요 최소한의 정보만 돌려받는다

/ai-ceo:morning으로 아침 다이제스트를 생성할 때도, Orchestrator는 각 부문의 STATE.md를 모두 읽어들일 필요가 없다.

ai-ceo-morning 에이전트에 위임하고, 요약된 다이제스트만 돌려받는다.

컨텍스트 사용률의 기준

Orchestrator 자신의 컨텍스트: 10~15%
└── CLAUDE.md 의 내용
└── 커맨드의 해석
└── 서브 에이전트에 대한 위임 지시

서브 에이전트의 컨텍스트: 60~80%
└── 에이전트 정의
└── 참조 파일 읽기
└── 실작업（코딩, 분석, 문서 작성）

버퍼: 10~20%
└── 에러 핸들링
└── 추가 주고받기

이 배분을 의식함으로써, 장시간 세션에서도 컨텍스트가 넘치기 어려워진다. 처음에는 감이 잡히지 않겠지만, 운용하면서 "어디서 컨텍스트를 쓰고 있는가"를 파악해나가면 된다.

실제 CLAUDE.md의 구조 (전체 모습)

여기까지의 요소를 정리하면, 필자가 실제로 사용하고 있는 CLAUDE.md는 다음 구조가 된다.

# AI-CEO Framework -- CEO-Suite Orchestrator

> 당신은 AI-CEO Framework의 「CEO-Suite Orchestrator」입니다.

## 당신의 역할
（4가지 책무를 열거）

## Thin Orchestrator의 원칙
（컨텍스트 관리의 룰）

## 회사 정보 참조처
（파일 경로 일람）

## CEO 커맨드 일람
（커맨드의 네임스페이스와 설명）

## 커맨드 실행 룰
（각 커맨드의 실행 플로우）
### /ai-ceo:init 의 실행 플로우
### /ai-ceo:morning 의 실행 플로우
### /ai-ceo:status 의 실행 플로우
### 승인 조작의 룰

## 권한 제어 룰
（read-only / draft / execute 의 정의）

## 에러 시의 행동
（리트라이, 에스컬레이션）

## 서브 에이전트에 대한 위임 방법
（위임 시에 전달하는 5가지 정보）

전체 약 150행의 Markdown 파일이다. 이것만으로 Claude Code는 "6개 부문을 통괄하는 Orchestrator"로서 행동한다. 처음에는 이 150행을 채우는 것 자체가 벅차게 느껴질 수 있다. 그래도 괜찮다. 다음 절의 /ai-ceo:init이 대화 형식으로 초안을 생성해준다.

초기 셋업 — /ai-ceo:init

모든 설정이 완료되면, 초기 셋업을 실행한다.

# Claude Code 내에서 실행
/ai-ceo:init

이 커맨드를 실행하면, Orchestrator가 인터뷰 형식으로 CEO에게 질문한다.

Orchestrator: 회사명과 사업 내용을 알려주세요.

CEO: 1인 법인입니다. AI 에듀테크 기업으로,
6개의 서비스와 외주 개발, AI 기업교육을 운영하고 있습니다.

Orchestrator: 미션·비전을 알려주세요.

CEO: 「개인의 개발을 촉진하고 사회의 발전에 기여한다」입니다.

Orchestrator: 현재 프로덕트 목록과 각 프로덕트의 상태를 알려주세요.

CEO: A서비스(운용 중), B서비스(운용 중), C서비스(운용 중)...

질문은 1문씩, 대화 형식으로 진행된다. 7가지 질문에 답하면 Orchestrator가 다음 파일들을 자동 생성한다.

자동 생성되는 파일:
- .company/VISION.md
- .company/STATE.md
- .company/ROADMAP.md
- .company/steering/brand.md
- .company/steering/tech-stack.md
- .company/steering/policies.md
- .company/steering/permissions.md
- .company/approval-queue.md
- .company/decisions/2026-02.md
- .company/products/{product-name}/STATE.md （각 프로덕트 분）
- .company/departments/{dept}/STATE.md （6개 부문 분）

총 20개 이상의 파일이 한꺼번에 생성된다. 이것이 AI 에이전트 조직의 "초기 상태"다.

생성 완료 후, 자동으로 /ai-ceo:status가 실행되어 초기 상태가 표시된다. 여기서부터, AI 에이전트 경영이 시작된다.

막히기 쉬운 포인트와 대책

마지막으로, 필자가 실제로 막혔던 포인트와 그 대책을 공유한다.

1. CLAUDE.md가 너무 길어서 컨텍스트를 압박한다

최초 버전의 CLAUDE.md는 300행 이상이었다. 모든 커맨드의 상세 플로우, 모든 부문의 설명, 모든 룰을 1파일에 꽉 채웠다. 결과적으로 Orchestrator 자신의 컨텍스트 소비가 커지고, 서브 에이전트에 충분한 컨텍스트를 전달할 수 없게 되었다.

대책: CLAUDE.md는 150행 이내로 억제하고, 상세는 서브 에이전트 정의 파일에 분리한다. Orchestrator에는 "무엇을 어디에 위임하는가"만 쓰고, "어떻게 하는가"는 서브 에이전트에 쓴다.

2. 에이전트의 출력 품질이 들쭉날쭉하다

같은 커맨드를 실행해도, 날에 따라 출력의 품질이나 포맷이 다를 때가 있다. 특히 콘텐츠 계열(아티클, 제안서)에서 두드러졌다.

대책: 에이전트 정의에 "성과물 템플릿"과 "품질 검증 룰"을 추가한다. 템플릿으로 출력 포맷을 고정하고, 품질 검증 룰로 셀프 체크를 하게 함으로써 품질이 안정되었다.

3. 승인 큐가 너무 쌓인다

에이전트가 활발하게 움직이면, 승인 큐에 10건 이상의 아이템이 쌓이는 경우가 있다. 전건을 확인하는 데 시간이 걸려 병목이 되었다.

대책: permissions.md의 임계값을 조정하고, 저리스크 액션(테스트 추가, 리팩토링, 내부 문서 업데이트 등)을 더 많이 execute로 이행했다. 승인 큐에는 정말로 CEO의 판단이 필요한 아이템만 들어가도록 했다.

4. 서브 에이전트 기동에 시간이 걸린다

서브 에이전트가 기동할 때 에이전트 정의 파일과 참조 파일을 읽어들이기 때문에, 첫 응답에 10~20초 걸리는 경우가 있다.

대책: 이것은 Claude Code의 사양상 피하기 어렵다. 다만, 에이전트 정의 파일을 컴팩트하게 유지하는 것, 참조 파일의 경로를 최소한으로 하는 것으로 기동 시간을 어느 정도 단축할 수 있다.

다음 장에서는 이 기반 위에 구축한 CTO 부문의 자동화에 대해, 실제 CI/CD 설정, 코드 리뷰, 테스트 자동 생성의 구체적인 예를 들어 해설한다.

---

©2024-2026 MDRules dev., Hand-crafted & made with Jaewoo Kim.

이메일문의: jaewoo@mdrules.dev

AI강의/개발/기술자문, Claude Code 전문강의, AI 업무 자동화 컨설팅 문의: https://talk.naver.com/ct/w5umt5

MDRules Dev - 네이버톡톡

AI 업무 자동화/에이전트/워크플로우설계 컨설팅/AI교육: https://mdrules.dev

MDRules Dev — AI 에이전트 경영과 AI 교육으로 차세대 경영 모델을 구축합니다