오늘만 무료

AI 에이전트를 조직으로 설계하는 법

1인 창업자를 위한 6부문 프레임워크 완전 가이드

11시간전 brunch_membership's

왜 "조직 구조"가 필요한가

AI 에이전트를 업무에 도입할 때, 대부분의 사람이 처음에 하는 것은 "태스크 단위 자동화"다. 코드 리뷰를 자동화한다. 회의록을 요약시킨다. 이메일 초안을 작성하게 한다.

이것이 잘못된 방향은 아니지만, 스케일되지 않는다.

태스크가 10개, 20개로 늘어나면 프롬프트 관리가 복잡해지고, 에이전트에 대한 지시가 일관성을 잃으며, 산출물의 품질이 들쭉날쭉해진다. 무엇보다 "전체적으로 무엇이 진행되고 있고, 무엇이 막혀 있는지"를 파악할 수 없게 된다.

필자가 찾은 해답은, 기존 기업 조직 구조를 AI 에이전트로 재현하는 접근 방식이었다.

기업 조직에는 오랜 세월의 지혜가 담겨 있다. 부문 분리, 권한 위임, 보고 라인, 승인 순서라든지 체계가 잡혀 있다. 이것들은 "복수의 사람이 협력하여 일하기 위해" 최적화된 구조이다. AI 에이전트의 협조에도 같은 구조가 유효하다고 판단했다.

결과적으로, 이 판단은 옳았다. "조직"이라는 구조가 있기 때문에 각 에이전트의 책임 범위가 명확해지고, 산출물의 품질이 안정되며, 전체 진행 상황을 일원 관리할 수 있게 되었다.

6부문 설계

부문 구성의 전체 모습

CEO（인간）
│
├── CEO-Suite Orchestrator（CLAUDE.md）
│
├── CTO 부문（개발）
│ └── ai-ceo-cto.md
│
├── CMO 부문（마케팅）
│ ├── ai-ceo-cmo.md
│ └── ai-ceo-content-engine.md
│
├── CFO 부문（경리·재무）
│ └── ai-ceo-cfo.md
│
├── CSO 부문（영업）
│ ├── ai-ceo-cso.md
│ └── ai-ceo-biz-dev.md
│
├── CS 부문（고객지원）
│ └── ai-ceo-cs-lead.md
│
└── Legal 부문（법무）
└── ai-ceo-legal.md

이것을 LangGraph DAG로 정리해보면,

더불어, 부문 횡단 지원 에이전트도 배치하고 있다.

├── ai-ceo-hr.md ← 인사（에이전트 관리·육성）
├── ai-ceo-growth.md ← 그로스（부문 횡단 성장 시책）
├── ai-ceo-consulting-vp.md ← 컨설팅 사업 총괄
└── ai-ceo-openclaw-ops.md ← 자동화 기반 운용

왜 이 6부문인가

부문 구성은 "1인 사장이 실제로 겸임하고 있는 역할"에서 역산했다.

필자가 매일 하는 일을 분류하면 다음 6개의 영역으로 정리된다.

개발 (CTO): 코드를 작성하고, 리뷰하고, 테스트하고, 배포한다

마케팅 (CMO): 아티클을 쓰고, SEO를 개선하고, SNS로 발신하고, 광고를 운용한다

경리 (CFO): 청구서를 처리하고, 경비를 분류하고, 월차 결산을 한다

영업 (CSO): 리드를 확보하고, 제안서를 만들고, 견적서를 발행한다

CS: 문의에 대응하고, 버그 리포트를 접수하고, FAQ를 정비한다

법무: 계약서를 리뷰하고, 이용 약관을 업데이트하고, NDA를 확인한다

혼자서 전부 하고 있었기 때문에 오히려 "여기는 AI에게 맡길 수 있다" "여기는 인간의 판단이 필요하다"는 경계가 명확하게 보였다. 이 경계를 기준으로 각 부문 에이전트의 책임 범위와 권한 레벨을 설계했다.

각 부문의 역할 정의

CTO 부문 — 개발의 핵심

담당: 프로덕트 개발 전반（설계, 구현, 테스트, 배포）
권한:
execute: 코딩, 테스트 실행, 스테이징 배포, 내부 문서
draft: 프로덕션 배포, 아키텍처 대폭 변경, 신규 라이브러리 도입
페르소나: 실용성 중시의 테크 리드. 오버 엔지니어링을 피한다.

CTO 부문은 가장 가동 빈도가 높은 부문이다. 6개의 프로덕트 전체의 유지보수·개선을 담당한다. 일상적으로는 버그 수정, 테스트 추가, 리팩토링을 자동 실행하고, 신기능 개발이나 서비스 배포는 draft 모드로 CEO의 승인을 기다린다.

CMO 부문 — 인지도와 집객

담당: 콘텐츠 전략, SEO, SNS 운용, 광고 분석, 기술 서적 관리
권한:
execute: 분석 리포트, 콘텐츠 캘린더, SEO 감사
draft: 아티클 게시, SNS 게시, 광고 캠페인 변경, LP 변경 배포
페르소나: 데이터 드리븐 그로스 마케터. 측정할 수 없는 것은 개선할 수 없다.

CMO 부문은 2개의 에이전트로 구성한다.

ai-ceo-cmo.md가 전략 수립과 분석을 담당하고, ai-ceo-content-engine.md가 아티클·책·SNS 게시물의 실제 제작을 담당한다. 전략과 실행을 분리함으로써, 대량 생산하면서도 품질을 담보하는 설계다.

CFO 부문 — 숫자 관리

담당: 경리 처리, 월차 결산, 예산 관리, KPI 대시보드
권한:
execute: 분석 리포트, KPI 업데이트
draft: 청구서 발행, 경비 정산, 예산 변경
페르소나: 착실한 관리 회계 전문가. 숫자에 기반한 의사결정을 지원한다.

CFO 부문은 홈택스·더존 등 국내 세무·회계 소프트웨어와의 연계를 전제로 설계하고 있다. 현시점에서 직접 API 연계는 구현되어 있지 않지만, 월차 경리 처리 플로우의 표준화와 KPI 집계·가시화를 담당하고 있다.

CSO 부문 — 매출을 만든다

담당: 리드 확보, 제안서 작성, 견적서 작성, 클라이언트 대응
권한:
execute: 시장 조사, 경쟁 분석, 리드 후보 리스트 작성
draft: 제안서, 견적서, 클라이언트에게 보내는 이메일
페르소나: 솔루션 영업 전문가. 기술과 비즈니스의 가교 역할.

CSO 부문에도 ai-ceo-biz-dev.md라는 서브 에이전트를 배치하고 있다. BizDev 에이전트는 신규 사업 개발, 파트너십 구축, 시장 조사를 전문으로 담당한다.

CS 부문 — 고객의 목소리를 듣는다

담당: 문의 대응, FAQ 정비, 피드백 수집, 에스컬레이션 관리
권한:
execute: FAQ 업데이트, 피드백 분석
draft: 유저에게 보내는 답변, 서비스 변경 공지
페르소나: 공감 능력이 높은 지원 담당. 기술적인 문의에도 대응 가능.

솔직히 말하면, CS 부문은 현시점에서는 아직 본격적으로 가동되고 있지 않다. 프로덕트의 유저 수가 늘어난 후 본격화할 예정이다. 하지만 조직 구조로서는 처음부터 정의해두는 것이 중요하다. 유저가 늘고 나서 서둘러 설계하면 이미 늦다.

Legal 부문 — 리스크를 지킨다

담당: 계약서 리뷰, 이용 약관 업데이트, NDA 확인, 컴플라이언스
권한:
execute: 계약서 독해와 분석
draft: 계약서 수정안, 이용 약관 개정
페르소나: 리스크 감도가 높은 법무 담당. 비즈니스 추진과 리스크 회피의 균형을 잡는다.

Legal 부문도 필요에 따라 외부 전문가와 연계하는 것을 전제로 한다. AI 에이전트가 하는 것은 어디까지나 1차적인 리뷰와 논점 정리이며, 최종적인 법적 판단은 인간(경우에 따라서는 변호사)이 수행한다.

Orchestrator（총괄자）패턴의 설계

왜 Orchestrator가 필요한가

6개의 부문 에이전트가 제각각 움직여서는 조직으로 기능하지 않는다. 부문 간의 의존 관계를 해결하고, 우선순위를 조정하고, CEO에 대한 보고를 통합하는 역할이 필요하다.

이를 담당하는 것이 "CEO-Suite Orchestrator"이며, CLAUDE.md 파일에 정의된다.

Orchestrator의 책무

1. CEO 커맨드 접수와 실행
└── /ai-ceo:* 커맨드를 해석하고 적절한 부문 에이전트에 위임

2. 부문 간 조정
└── 의존 관계 해결, Wave 실행 계획 생성

3. 승인 관리
└── draft 산출물의 승인 큐 관리, CEO에 보고

4. 프로덕트 횡단 관리
└── 복수 프로덕트 간 리소스 배분·우선도 판단

Thin Orchestrator의 원칙

Orchestrator 설계에서 가장 중요한 원칙이 있다. Orchestrator는 가능한 한 "얇게" 유지한다는 것이다.

Claude Code에는 컨텍스트 윈도우의 제약이 있다. Orchestrator가 전 부문의 정보를 읽어들이면 순식간에 컨텍스트를 다 써버리고 만다.

그래서 채택한 것이 "Thin Orchestrator" 패턴이다.

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

Orchestrator는 "교통 정리 역할"에 철저하다. 실제 작업은 각 부문 에이전트가 수행하고, Orchestrator는 어떤 에이전트에 어떤 태스크를 할당할지만 판단한다.

커맨드 체계

# 일상 운용
/ai-ceo:morning ← 아침 다이제스트（전 부문 STATE + 승인 대기 + KPI）
/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 ← 월간 콘텐츠 캘린더
/ai-ceo:sales:proposal "대상" ← 제안서 자동 생성
/ai-ceo:fin:monthly-report ← 월차 결산 리포트

# 전략 지시
/ai-ceo:new-product "개요" ← 신규 프로덕트 개발 시작
/ai-ceo:pivot "방침" ← 전략 변경

커맨드는 네임스페이스로 분류되어 있다.

dev:는 개발 부문,

mkt:는 마케팅 부문,

sales:는 영업 부문,

fin:은 경리 부문.

CEO는 커맨드를 입력하기만 하면 적절한 부문 에이전트에 태스크가 위임된다.

.company 디렉토리의 구조

AI 에이전트 조직이 기능하기 위해서는 "회사의 상태"를 일원 관리하는 구조가 필요하다. 인간 조직이라면 슬랙, 노션, 지라, 구글 드라이브 등 복수의 도구에 정보가 분산되지만, AI 에이전트 조직에서는 모든 것을 파일 시스템 위의 Markdown 파일로 관리한다.

디렉토리 구조 전체 모습

.company/
├── VISION.md # 미션·비전·코어 밸류
├── STATE.md # 현재 경영 상태（전사 요약）
├── ROADMAP.md # 분기 로드맵
├── approval-queue.md # 승인 대기 큐
│
├── steering/ # 경영 방침·규약
│ ├── brand.md # 브랜드 가이드라인
│ ├── tech-stack.md # 기술 스택 규약
│ ├── permissions.md # 권한·임계값 설정
│ └── policies.md # 각종 정책
│
├── products/ # 프로덕트별 상태
│ ├── sharetoku/STATE.md
│ ├── mochiq/STATE.md
│ ├── focalize/STATE.md
│ ├── genki-button/STATE.md
│ ├── skill-management-saas/STATE.md
│ └── dx-consulting/STATE.md
│
├── departments/ # 부문별 상태
│ ├── dev/STATE.md
│ ├── marketing/STATE.md
│ ├── finance/STATE.md
│ ├── sales/STATE.md
│ ├── cs/STATE.md
│ └── legal/STATE.md│
└── decisions/ # 의사결정 로그
└── 2026-02.md

각 파일의 역할

VISION.md — 조직의 미션 및 비전, 코어 밸류

# 유한회사 MD룰 - 비전 & 미션

## 미션
「개인의 개발을 촉진하고 사회의 발전에 기여한다」

## 비전
테크놀로지와 교육의 힘으로, 기업과 개인이 가진 가능성을 최대한 발휘하고,
지속적인 성장을 실현하는 사회를 만든다.

## 코어 밸류
1. 기술로 과제를 해결하는 실행력
2. 개인의 성장이 사회를 바꾼다는 신념
3. 작아도 고품질의 프로덕트를 전달한다
4. 지속적인 학습과 진화
5. 테크놀로지의 민주화

VISION은 좀처럼 바뀌지 않는다. 하지만 에이전트가 "판단에 막혔을 때의 기준"으로 참조할 수 있도록 명문화해두는 것이 중요하다. 예를 들어 CMO 에이전트가 콘텐츠의 방향성에 막혔을 때, "개인의 개발을 촉진한다"는 미션으로 되돌아감으로써 일관된 브랜드 메시지를 유지할 수 있다.

STATE.md — 경영의 현재 위치

STATE.md는 가장 빈번하게 업데이트되는 파일이다. 전 프로덕트의 상태, 각 부문의 가동 상황, KPI의 현재 값이 모두 기록되어 있다.

이 파일이 있기 때문에, /ai-ceo:morning 커맨드를 실행하는 것만으로 CEO는 아침 가장 먼저 전사의 상태를 파악할 수 있다.

## 프로덕트 상태

| 프로덕트 | 페이즈 | 상태 | 다음 마일스톤 |
|---------|-------|------|-------------|
| A서비스 | 운용·성장 | 운용 중 | SEO 최적화 |
| B앱 | 운용·개선 | 운용 중 | AI 학습 기능 개선 |
| C사이트 | 운용·성장 | LP CVR 개선 중 | CVR 3~7% 달성 |
| D앱 | 운용 | 구글 플레이 공개 완료 | 앱스토어 승인 대기 |
| ...

## 부문 상태
| 부문 | 상태 | 주요 태스크 |
|------|------|-----------|
| 개발 | 가동 | CI/CD 완료, 유지보수·개선 |
| 마케팅 | 가동 | 아티클 6편 승인, 책 4권 기획 승인 |
| 영업 | 준비 중 | 리드 확보 전략 수립 완료 |
| ...

ROADMAP.md — 분기의 항로도

ROADMAP은 "이번 분기에 무엇을 달성할 것인가"를 정의한다. 마일스톤마다 담당 부문과 상태가 기록되어 있다.

에이전트는 ROADMAP을 참조함으로써, "지금 해야 할 태스크"와 "나중으로 미뤄도 되는 태스크"를 판단할 수 있다. 이것이 없으면, 에이전트가 우선순위를 잘못 판단하여 중요하지 않은 태스크에 시간을 쓰는 경우가 있다.

permissions.md — 안전장치

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

## 개발 임계값
### 자동 실행 가능（execute）
- 버그 수정, 마이너 기능 추가, 테스트 추가, 리팩토링

### CEO 승인 필요（draft）
- 신기능 개발, 아키텍처 변경, 프로덕션 배포

permissions.md는 조직 전체의 안전장치다. 금액의 임계값, 개발의 권한 레벨, 대외 커뮤니케이션의 승인 플로우. 모든 것이 여기에 정의되어 있다. 에이전트는 액션을 실행하기 전에 이 파일을 참조하고, 권한 레벨에 따라 자동 실행할지, 승인 큐에 추가할지를 판단한다.

approval-queue.md — CEO의 판단을 기다리는 줄

# 승인 대기 큐

## 대기 중

- [AQ-001] 개발: Focalize 프로덕션 배포 | .company/departments/dev/deploy-focalize.md
- [AQ-002] 마케팅: Zenn 아티클 3편 게시 | .company/departments/marketing/articles/
- [AQ-003] 영업: DX 지원 제안서 | .company/departments/sales/proposals/dx-proposal-001.md

승인 큐는 CEO가 아침 가장 먼저 확인하는 파일이다. 여기에 나열된 아이템을 1건씩 확인하고, /ai-ceo:approve AQ-001로 승인하거나, /ai-ceo:reject AQ-001 "이유"로 반려한다.

이 플로우로 CEO는 "무엇을 판단해야 하는가"를 한 곳에서 파악할 수 있고, 판단에 집중할 수 있다.

승인 파이프라인 — draft → 승인 → 실행

파이프라인의 전체 플로우

에이전트가 태스크를 수신한다
↓
permissions.md 를 참조
↓
┌──────────────────────┐
│ 권한 체크 │
│ │
│ execute? → 자동 실행 │
│ draft? → ↓ │
│ read-only? → 자동 실행 │
└──────────────────────┘
↓ (draft의 경우)
산출물을 draft 파일로 생성
↓
approval-queue.md 에 아이템 추가
↓
CEO에게 통지（/ai-ceo:morning 으로 확인）
↓
CEO가 approve / reject
↓
┌─────────────────────────────┐
│ approve → 실행（배포 등） │
│ reject → 반려·수정 │
└─────────────────────────────┘
↓
decisions/{month}.md 에 기록

왜 이 구조가 필요한가

AI 에이전트에게 일을 맡기는 데 있어 가장 무서운 것은 "의도하지 않은 액션이 대외적으로 실행되는 것"이다.

버그가 있는 코드가 프로덕션에 배포된다

부적절한 내용의 SNS 게시물이 공개된다

잘못된 금액의 청구서가 클라이언트에게 발송된다

이런 리스크를 방지하는 것이 승인 파이프라인이다. 대외적인 영향이 있는 액션은 반드시 CEO의 눈을 거친다. 한편, 내부적인 액션(테스트 실행, 분석 리포트 생성, 문서 업데이트 등)은 자동 실행을 허용한다.

이 "판단의 해상도"가 중요하다. 모든 것을 승인 필수로 하면, CEO가 병목이 되어 자동화의 의미가 없어진다. 모든 것을 자동 실행으로 하면 리스크를 관리할 수 없다. permissions.md에서 임계값을 명문화함으로써, 이 균형을 최적으로 유지하고 있다.

1인 사장이 CEO로서 의사결정에 집중할 수 있는 구조

AI-CEO Framework가 목표로 하는 목표는, 1인 사장을 "전 태스크의 실행자"에서 "의사결정자"로 바꾸는 것이다.

프레임워크 도입 전 CEO의 하루

실행 : ████████████████████████░░ 92%

판단 : ██░░░░░░░░░░░░░░░░░░░░░░░░ 8%

프레임워크 도입 후 CEO의 하루

실행 : ████░░░░░░░░░░░░░░░░░░░░░░ 15%

판단 : ██████████████░░░░░░░░░░░░ 55%

전략 : ████████░░░░░░░░░░░░░░░░░░ 30%

"실행"이 15%로 줄어든 것은, 대부분의 태스크가 에이전트에 위임되었기 때문이다. CEO가 직접 실행하는 것은, 최종적인 콘텐츠의 편집, 클라이언트와의 직접 미팅, 에이전트로는 대응하기 어려운 창의적인 작업에 한정된다.

"판단"이 55%로 늘어난 것은, 승인 파이프라인을 통해 의사결정이 구조화되었기 때문이다. 매일 아침의

/ai-ceo:morning으로 전사 상태를 파악하고, 승인 큐의 각 아이템에 대해 approve/reject 판단을 내린다.

"전략"이 30%를 차지하게 된 것이 가장 큰 변화다. 이전에는 태스크 소화에 쫓겨 "애초에 무엇을 해야 하는가"를 생각할 시간이 없었다. 지금은, 프로덕트 간의 우선순위, 신규 사업의 가능성, 중장기 기술 선정에 대해, 차분하게 생각하는 시간이 있다.

실제 아침 루틴

필자의 현재 아침 루틴을 소개한다.

06:00 기상
06:15 /ai-ceo:morning 실행（2분으로 전체 상태 파악）
06:20 승인 큐 확인（3~5건, 각 1~3분으로 판단）
06:40 오늘의 전략적 의사결정（무엇에 집중할 것인가）
07:00 에이전트에 지시 내리기
예: /ai-ceo:dev:sprint
예: /ai-ceo:content:article "Claude Code CLAUDE.md 설계 패턴"
07:30 외주 안건 개발 작업（직접 손을 움직이는 시간）
08:30 아이 등교

아침 30분으로 "CEO의 일"이 끝난다. 그 후에는, 외주 안건의 개발이나 자사 프로덕트의 창의적인 설계 작업 등, 인간에게만 가능한 일에 집중할 수 있다.

에이전트들은 병렬로 일을 진행하고, 산출물이 완성되면 approval-queue.md에 추가된다. 점심시간이나 일하는 틈틈이 승인 큐를 확인하여 approve/reject하기만 하면 된다.

설계상의 중요한 판단

마지막으로, 이 프레임워크를 설계하면서 내린 중요한 판단을 몇 가지 공유한다.

1. Markdown 파일을 선택한 이유

회사의 상태 관리에 데이터베이스나 SaaS가 아닌 Markdown 파일을 사용하는 이유는 세 가지다.

Git으로 버전 관리할 수 있다: 언제, 누가(어느 에이전트가), 무엇을 변경했는지 추적할 수 있다

AI 에이전트가 직접 읽고 쓸 수 있다: API 연계나 데이터베이스 쿼리가 불필요하다

인간도 읽기 쉽다: 특별한 도구 없이 텍스트 에디터로 확인·편집할 수 있다

2. 에이전트 정의를 파일로 분리한 이유

모든 에이전트 정의를 CLAUDE.md에 쓰는 것도 가능하지만, 파일을 분리했다. 이유는 Thin Orchestrator의 원칙에 따른 것이다. CLAUDE.md에 모든 것을 쓰면 컨텍스트 윈도우를 압박한다. .claude/agents/

에 파일을 분리하여, Orchestrator는 필요할 때 필요한 에이전트만 호출하는 설계로 했다.

3. 부문의 해상도

6부문은 "너무 많지 않나"라는 의문이 있을 수도 있다. 실제로 CS 부문과 Legal 부문은 현시점에서는 거의 가동되지 않고 있다. 하지만, 처음부터 조직 구조를 완성형으로 정의해두면 사업이 성장했을 때 원활하게 스케일할 수 있다. 반대로, 나중에 부문을 추가하면 기존의 권한 설정이나 커맨드 체계와의 정합성을 맞추는 것이 번거로워진다.