직원 없이 6개 서비스를 동시 운영하는 AI 에이전트

1인 스타트업 실전기

Mar 23. 2026

이 책은 "해봤습니다 후기"가 아니다

이 책을 손에 든 분께 처음부터 명확하게 전하고 싶은 것이 있다.

이것은 "Claude Code로 OO AI 에이전트를 만들어봤습니다"라는 기술 검증 기록이 아니다.

실제로 회사를 경영하기 위해 AI 에이전트 군을 조직으로 설계하고, 매일의 업무에서 운용하고 있는 사람이 쓴, 경영 실전 기록이다.

필자는 혼자 해외 어딘가에 작은 스타트업 CEO이다. 직원은 자신 1명뿐이다. 하지만 사내에는 6개의 부서가 존재하고, CTO, CMO, CFO, CSO, 고객 지원, 법무 각각에 AI 에이전트가 배치되어 있다. 그들은 매일 코드 리뷰를 하고, SEO/LLMO 콘텐츠를 쓰고, 경리 처리를 보조하고, 영업 제안서 초안을 작성한다.

"AI로 업무를 자동화한다"는 이야기는 이제 새롭지 않다. 하지만 AI 에이전트를 조직 구조로 설계하고, 승인 파이프라인을 통해 경영 판단에 통합하고, 복수의 프로덕트를 크로스 관리하는등의 내용은 거의 찾아보기 힘들다.

이 책에서는 그 경험담을 정리하여 공개한다. 성공이나 실패, 설계사상부터 실제 운용하고 있는 현실 상황까지 모두 숨김없이 숨김없이 공개한다.

1명이 9개 사업을 돌리는 하루 — AI 에이전트 도입 전

AI 에이전트 경영을 도입하기 전, 필자의 하루가 어땠는지 돌아보겠다.

전형적인 하루 (도입 전)

이런 생활을 계속하다 보면 반드시 어떤 일이 벌어진다. 모든 것이 어중간해진다.

6개의 서비스가 있어도, 하루에 손을 댈 수 있는 것은 2~3개가 한계다. 나머지 서비스는 방치된다. 자사 A서비스의 SEO 개선을 진행하고 싶은 주에 고객사 에이전트에서 긴급 버그가 발생하면, 자사 A서비스는 뒤로 밀린다. 뒤로 밀린 SEO 개선은 다음 주도 다음 달도 착수되지 않은 채 백로그 깊은 곳에 잠겨버린다.

외주 안건은 납기가 있으니 최우선으로 대응하지만, 그만큼 자사 프로덕트 개발 시간이 깎인다. 자사 프로덕트가 성장하지 않으니 수익이 늘지 않고, 외주 의존도가 낮아지지 않는다. 전형적인 악순환이다.

경리 처리는 월말에 몰아서 하지만, 영수증 분류와 계정 과목 확인에만 하루가 꼬박 걸린다. 기술 아티클은 "이번 달에야말로 쓰겠어"라고 매달 다짐하지만, 월 2편 페이스조차 유지하지 못한다. SNS는 생각날 때만 게시하는 수준으로, 전략적인 발신과는 거리가 멀다.

물리적으로, 1명의 사람이 하루 24시간에 처리할 수 있는 태스크 양을 완전히 초과하고 있었다.

전환점 — Claude Code와의 만남

2025년 하반기, Claude Code Max 플랜(월 $100~200)을 사용하기 시작한 것이 전환점이 되었다.

처음에는 일반적인 바이브코딩 개발용으로 사용했다. 코드 틀 생성, 버그 원인 조사, 테스트 코드 작성만으로도 개발 효율은 크게 향상되었다.

하지만 사용하다 보니 깨달은 것이 있다. Claude Code는 단순한 코드 생성 툴이 아니다. CLAUDE.md라는 설정 파일을 통해 AI의 행동 자체를 정의할 수 있다. 즉, "이런 역할로, 이런 규칙에 따라, 이런 품질 기준으로 일하라"고 지시할 수 있는 것이다.

이 순간, 머릿속에서 퍼즐 조각이 맞아떨어졌다.

"이거, 조직을 만들 수 있지 않을까."

CTO 역할의 에이전트에게 코드 리뷰를 맡기고, CMO 역할의 에이전트에게 콘텐츠 전략을 맡기고, CFO 역할의 에이전트에게 경리 처리를 맡긴다. 각 에이전트에게는 전문 지식과 권한을 정의하고, 결과물은 승인 파이프라인을 통해 CEO(자신)가 최종 확인한다.

1명의 사람이 모든 것을 처리하는 것이 아니라, 1명의 CEO가 복수의 AI 에이전트를 통솔한다. 이렇게 하면 6개 서비스의 동시 병행 관리가 물리적으로 가능해진다.

이렇게 AI-CEO Framework의 구상이 시작되었다.

AI 에이전트 경영의 전체 모습

구상을 구체화하는 데는 그리 많은 시간이 걸리지 않았다. 조직 설계 지식과 Claude Code의 구조를 결합하면, 필요한 설계는 자연스럽게 보인다.

최종적으로 구축한 시스템의 전체 모습은 다음과 같다.

CEO（인간）
│
├── CLAUDE.md（CEO-Suite Orchestrator）
│ └── AI와의 유일한 인터페이스
│
├── .claude/agents/（서브 에이전트 군）
│ ├── ai-ceo-cto.md ← 개발 부문
│ ├── ai-ceo-cmo.md ← 마케팅 부문
│ ├── ai-ceo-cfo.md ← 경리 부문
│ ├── ai-ceo-cso.md ← 영업 부문
│ ├── ai-ceo-cs-lead.md ← CS 부문
│ └── ai-ceo-legal.md ← 법무 부문
│
└── .company/（회사 상태 관리）
├── VISION.md ← 미션·비전
├── STATE.md ← 현재 경영 상태
├── ROADMAP.md ← 분기 로드맵
├── approval-queue.md ← 승인 대기 큐
├── steering/ ← 경영 방침·규약
├── products/ ← 프로덕트별 상태
├── departments/ ← 부문별 상태
└── decisions/ ← 의사결정 로그

포인트는 세 가지다.

1. Orchestrator 패턴

CLAUDE.md에 정의한 "CEO-Suite Orchestrator"가 CEO와 AI 에이전트 군 사이에 선다. CEO는 Orchestrator에게 지시를 내리고, Orchestrator가 적절한 부문 에이전트에게 태스크를 위임한다. CEO가 개별 에이전트와 직접 주고받을 필요는 없다.

2. 파일 기반 상태 관리

회사의 상태는 모두 .company/ 디렉토리 내의 Markdown 파일로 관리된다. 데이터베이스는 불필요하다. Git으로 버전 관리가 가능하고, 변경 이력도 추적할 수 있다. 에이전트는 파일을 읽고 씀으로써 "일"을 한다.

3. 승인 파이프라인

대외적인 영향이 있는 액션(배포, 이메일 발송, SNS 게시 등)은 반드시 draft 모드로 생성되어 approval-queue.md에 추가된다. CEO가 승인할 때까지 실행되지 않는다. 이를 통해 AI의 폭주를 방지하면서, CEO는 "판단"에 집중할 수 있다.

Before/After — 구체적으로 무엇이 바뀌었는가

개발 효율

실례를 하나 들어보겠다. 원기버튼 앱에 CI/CD를 추가하는 작업이 있었다. 도입 전이라면 GitHub Actions 워크플로우 작성, 테스트 환경 설정, 배포 스크립트 작성, 동작 확인까지 최소 반나절은 걸렸을 것이다.

AI-CEO Framework 도입 후에는 /ai-ceo:dev:sprint 커맨드 하나로 CTO 에이전트가 태스크를 받아 워크플로우 파일 작성부터 PR 생성까지 자동으로 실행했다. 필자가 한 것은 PR의 내용을 확인하고 승인 버튼을 누르는 것뿐이다. 소요 시간은 15분정도이다.

마케팅

특히 큰 것은 기술 아티클이다. "써야 하는데"라고 생각하면서 못 쓰던 아티클이 콘텐츠 엔진 에이전트와의 협업으로 양산할 수 있게 되었다. 에이전트가 구성안과 초안을 작성하고, 필자가 자신의 실제 체험을 가필하여 마무리한다. 이 진행순서라면 아티클 1편당 30분~1시간으로 게시할 수 있다.

AI 에이전트 경영의 현실적인 제약

여기까지 쓰면, 꿈 같은 이야기처럼 들릴 수도 있다. 하지만 솔직하게 제약도 써두겠다.

비용

Claude Code Max 플랜은 월 $100~200이다. 원화로 15만~30만 원정도이다. 프리랜서나 1인 사장에게는 적은 금액이 아니다. 다만 "월 20만 원으로 6개 부문의 부하 직원을 고용할 수 있다"고 생각하면, 파격적인 투자 효율이라고 필자는 판단하고 있다. 사람을 아르바이트로 1명 고용하는 것만으로도 최소 최저시급 기준으로 월 216만 원은 든다.

판단력의 한계

AI 에이전트는 지시받은 업무를 높은 품질로 수행하지만, "무엇을 해야 하는가"의 판단은 서툴다. 어느 프로덕트에 주력해야 할지, 어떤 기능을 우선해야 할지, 언제 피벗해야 할지. 이런 경영 판단은 여전히 인간 CEO가 해야 한다.

AI-CEO Framework에서는 이 제약을 전제로 설계하고 있다. 에이전트는 "실행"을 담당하고, CEO는 "판단"을 담당한다. 승인 파이프라인은 이 역할 분담을 구조로 보장하는 것이다.

컨텍스트 제약

Claude Code에는 한 번에 처리할 수 있는 정보량(컨텍스트 윈도우)의 제약이 있다. 6개 프로덕트의 전 정보를 에이전트에게 전달할 수는 없다. 그래서 "Thin Orchestrator 원칙"을 채택했다. Orchestrator는 파일 내용을 읽어들이지 않고 파일 경로만 관리한다. 필요한 정보는 태스크를 실행하는 서브 에이전트가 그때그때 필요한 파일만 읽어들인다.

보안

AI 에이전트에게 회사 정보를 다루게 하는 이상, 보안은 무시할 수 없다. 본 프레임워크에서는 권한 레벨(read-only / draft / execute)을 엄격하게 정의하고, 대외 액션(이메일 발송, 배포, SNS 게시 등)은 반드시 CEO의 승인을 경유하도록 하고 있다. API 키나 인증 정보에 대한 접근도 제한하고 있다.