오늘만 무료

6개 서비스를 혼자 유지보수하는 CTO 부문 설계

CI/CD 자동 구축·PR 자동 리뷰·테스트 자동 생성

6시간전 brunch_membership's

CTO 부문을 가장 먼저 자동화해야 하는 이유

AI-CEO Framework의 6개 부문 중에서 가장 먼저 본격적으로 가동시킨 것은 CTO 부문이다. 여기에는 명확한 이유가 있다.

개발 부문은 다른 모든 부문의 기반이 된다.

마케팅 부문이 LP 개선 시책을 세워도, 구현하는 것은 개발 부문이다. 영업 부문이 제안서를 만들어도, 프로덕트 데모 환경을 정비하는 것은 개발 부문이다. CS 부문이 버그 리포트를 받아도, 수정하는 것은 개발 부문이다.

즉, 개발 부문의 처리량이 올라가면 모든 부문의 생산성이 올라간다. 반대로 개발 부문이 병목이 되면 다른 모든 것이 멈춘다. 한국의 1인 개발 창업자라면 이 감각은 더 뼈저리게 와닿을 것이다. 클라이언트 긴급 요청이 들어오는 순간, 자사 서비스 개발은 전부 멈춘다. 버그 하나가 발견되면 오늘 계획된 기능 개발은 사라진다. 개발이 병목인 한 다른 어떤 전략도 실행되지 않는다.

더불어, 필자는 6개의 서비스를 동시에 유지보수·개선해야 한다. 각 프로덕트에 CI/CD 환경을 정비하고, 코드 리뷰의 품질을 담보하며, 테스트 커버리지를 유지하는 것만으로도 수작업으로는 도저히 따라갈 수 없다.

CTO 부문 에이전트의 도입으로 이 상황이 극적으로 개선되었다.

CTO 부문 에이전트의 역할 정의

먼저 CTO 부문 에이전트(ai-ceo-cto.md)의 정의를 다시 살펴보자.

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

# CTO / 개발 부장 에이전트

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

## 페르소나

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

## 담당 영역

- 프로덕트 개발 전반（설계, 구현, 테스트, 배포）
- 기술적 의사결정
- 스프린트 관리
- 코드 리뷰·보안

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

포인트는 다음 세 가지다.

1. 도구 선택: Bash 도구가 포함되어 있다. 이를 통해 에이전트는 Git 커맨드, npm/yarn 커맨드, 테스트 실행 커맨드 등을 터미널에서 직접 실행할 수 있다. CI/CD 설정이나 테스트 실행에 필수적이다. 다른 부문 에이전트(예: CMO)에는 Bash를 부여하지 않는다. 이 최소 권한 원칙이 보안의 기본이다.

2. 페르소나의 "실용성 중시": 이것이 의외로 중요하다. 페르소나를 지정하지 않으면 에이전트는 과도하게 복잡한 솔루션을 제안하는 경향이 있다. "오버 엔지니어링을 피한다"고 명기함으로써 심플하고 유지보수하기 쉬운 구현을 우선한다. 실무에서도 "지금 당장 동작하는 코드"가 "언젠가 완벽한 코드"보다 훨씬 가치 있다.

3. 권한의 draft/execute 분리: 버그 수정이나 테스트 추가는 자동 실행(execute)이지만, 프로덕션 배포나 신규 라이브러리 도입은 승인 필요(draft)다. 이 경계가 안전성과 효율의 균형을 잡는다.

GitHub Actions 연계로 CI/CD 자동 구축

6개 서비스의 CI/CD 통일화

필자가 안고 있던 과제 중 하나가, 프로덕트마다 CI/CD 환경이 제각각이었다는 것이다.

AService: CI/CD 없음

BService: CI/CD 없음

CApp: CI/CD 없음

DService: 수동배포

EApp: 없음

스킬관리 서비스: 수동배포

6개 서비스 중 제대로 된 CI/CD가 동작하고 있던 것은 0개였다. 배포는 매번 수동으로, 테스트도 수동으로 실행하고 있었다(애초에 테스트가 작성되어 있지 않은 프로덕트도 있었다).

한국의 소규모 개발팀이라면 이 상황은 매우 일반적이다. "일단 만들어서 배포하고 보자"는 속도 우선의 개발 방식은, 초기에는 합리적이다. 문제는 프로덕트 수가 늘어날수록 이 방식의 기술 부채가 기하급수적으로 쌓인다는 것이다.

CTO 부문 에이전트에 /ai-ceo:dev:sprint를 실행하자, 다음 태스크가 자동으로 계획·실행되었다.

실천 예: CApp의 CI/CD 추가

CApp에 대한 CI/CD 추가는 AI-CEO Framework로 자동화한 최초의 실제 안건이다. 그 과정을 시계열로 따라가 보자.

1단계: 스프린트 계획

CEO가 다음 커맨드를 실행한다.

/ai-ceo:dev:sprint

Orchestrator가 ai-ceo-cto 에이전트를 호출하고, CTO 에이전트가 다음 플로우를 실행한다.

.company/products/CApp/STATE.md를 읽어들여 현재 서비스 상태를 파악
.company/departments/dev/STATE.md를 읽어들여 개발 부문의 백로그를 확인
우선도에 따라 태스크를 선정

CTO 에이전트의 판단:

선정 태스크:
1. [높음] CApp 리포지토리에 CI/CD 추가
- GitHub Actions 워크플로우 작성
- 자동 테스트 실행
- 코드 품질 체크

2단계: 사양 책정

CTO 에이전트가 태스크의 사양을 CC-SDD(Claude Code Software Design Document)형식으로 작성한다.

# CC-SDD: cserviceapp CI/CD 추가

## Requirements
- PR이 작성될 때 자동으로 CI/CD가 실행된다
- 테스트（flutter test）가 자동 실행된다
- 정적 분석（flutter analyze）이 자동 실행된다
- CI가 실패한 경우 PR에 상태가 표시된다

## Design
- GitHub Actions의 워크플로우 파일을 작성
- 트리거: pull_request 이벤트（main, develop 브랜치）
- 잡: Flutter 환경 셋업 → analyze → test

## Tasks
1. .github/workflows/ci.yml 을 작성
2. 워크플로우 동작 확인
3. PR 작성

3단계: 구현

CTO 에이전트가 다음 GitHub Actions 워크플로우 파일을 생성한다.

# .github/workflows/ci.yml
name: CI

on:
pull_request:
branches: [main, develop]
push:
branches: [main]

jobs:
analyze-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- name: Setup Flutter
uses: subosito/flutter-action@v2
with:
flutter-version: '3.x'
channel: 'stable'

- name: Install dependencies
run: flutter pub get

- name: Analyze
run: flutter analyze

- name: Test
run: flutter test

심플하지만 실용적인 워크플로우다. "오버 엔지니어링을 피한다"는 페르소나가 효과를 발휘하고 있다. 처음부터 복잡한 매트릭스 빌드나 캐시 설정을 넣는 것이 아니라, 우선 동작하는 것을 만들고 필요에 따라 개선하는 접근 방식이다. 한국의 린 스타트업 방법론과 같은 맥락이다.

4단계: PR 작성

CTO 에이전트가 Git으로 브랜치를 만들고, 커밋하고, PR을 작성한다.

git checkout -b feature/add-ci-cd
git add .github/workflows/ci.yml
git commit -m "feat: add CI/CD pipeline with Flutter analyze and test"
git push origin feature/add-ci-cd
gh pr create --title "feat: CI/CD 추가" --body "..."

실제로 작성된 것이 cserviceapp 리포지토리의 PR #1이다. 이것이 AI-CEO Framework를 통해 자동 작성된 최초의 PR이 되었다.

5단계: 승인과 상태 업데이트

PR이 작성되면 CTO 에이전트는 승인 큐에 아이템을 추가한다.

# approval-queue.md
- [AQ-001] 개발: EService CI/CD 추가 PR #1 | github.com/xxx/EService/pull/1

CEO가 PR 내용을 확인하고 /ai-ceo:approve AQ-001로 승인한다. 그 후 CTO 에이전트가 PR을 머지하고

.company/departments/dev/STATE.md를 업데이트한다.

## 최근 성과물
| 날짜 | 성과물 | 비고 |
|------|--------|------|
| 2026-02-15 | CI/CD 추가 |CApp PR #1 머지 완료 |

이 일련의 플로우에서 CEO가 직접 한 것은 PR 확인과 승인 버튼을 누르는 것뿐이다. 소요 시간은 약 15분. 수동으로 같은 작업을 했다면 반나절은 걸렸을 것이다.

PR 자동 리뷰

과제: 혼자 리뷰하는 한계

1인 개발에서는 코드 리뷰가 형식적으로 흐르기 쉽다. 자신이 작성한 코드를 자신이 리뷰해도 버그나 설계상의 문제를 놓치기 쉽다. "뭐, 동작하니까 괜찮겠지"로 통과시켜버린다.

하지만 6개 서비스를 유지보수하는 데 있어 코드의 품질을 유지하는 것은 사활이 걸린 문제다. 하나의 서비스에서의 품질 저하가 기술 부채로서 미래의 개발 속도를 현저히 떨어트리게 된다.

소규모 팀이나 1인 개발자의 경우, 코드 리뷰를 외부 동료에게 부탁하는 것도 현실적으로 어렵다. 깃허브 코파일럿(GitHub Copilot)의 코드 제안과 달리, 리뷰는 맥락을 이해한 관점이 필요하기 때문이다.

Claude Code에 의한 리뷰 위임

CTO 에이전트에는 코드 리뷰 워크플로우가 내장되어 있다.

## 스프린트 플로우
...
5. dev-reviewer 로 코드 리뷰
- 코드의 품질 체크
- 보안 체크
- tech-stack.md 준수 확인
- 테스트 커버리지 확인

실제 리뷰에서는 다음 관점을 체크한다.

리뷰 관점
1. 코드 품질
- 불필요한 복잡함이 없는가
- 함수의 책무가 적절하게 분리되어 있는가
- 에러 핸들링이 적절한가
- 명명이 명확한가

2. 보안
- API 키나 시크릿이 하드코딩되어 있지 않은가
- SQL 인젝션, XSS 취약점이 없는가
- 입력 유효성 검사가 적절한가

3. tech-stack.md 준수
- 승인된 라이브러리만 사용하고 있는가
- 코딩 규약에 따르고 있는가
- 디렉토리 구조가 규약에 맞는가

4. 테스트
- 새 코드에 테스트가 추가되어 있는가
- 엣지 케이스가 커버되어 있는가
- 테스트가 의미 있는 어서션을 하고 있는가

GitHub Actions 연계에 의한 자동 리뷰

더 나아간 단계로서, GitHub Actions와 연계하여 PR 작성 시에 자동으로 리뷰를 실행하는 구조도 구축했다.

# .github/workflows/ai-review.yml
name: AI Code Review

on:
pull_request:
types: [opened, synchronize]

permissions:
contents: read
pull-requests: write

jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0

- name: Get diff
id: diff
run: |
echo "diff<<EOF" >> $GITHUB_OUTPUT
git diff origin/main...HEAD >> $GITHUB_OUTPUT
echo "EOF" >> $GITHUB_OUTPUT

- name: AI Review
uses: anthropics/claude-code-action@v1
with:
model: claude-sonnet-4-20250514
prompt: |
다음의 diff를 리뷰해주세요.
관점: 코드 품질, 보안, 테스트 커버리지
문제가 없으면 「LGTM」이라고 기재해주세요.
문제가 있으면 구체적인 개선안을 제시해주세요.

이 워크플로우로 PR이 작성될 때마다 AI 리뷰가 자동으로 실행된다. 리뷰 결과는 PR의 코멘트로 게시되고, CEO는 리뷰 결과를 확인한 후 머지 여부를 판단한다.

리뷰의 실제 효과

cservice 앱 리포지토리에 이 구조를 도입한 결과, 다음과 같은 변화가 있었다.

놓쳤던 버그 감지: null 안전성 문제, 에러 핸들링 누락 등 스스로는 알아채기 어려운 버그가 감지되었다

코딩 규약 자동 체크: 명명 규칙의 흔들림, 불필요한 import, unused 변수 등이 자동으로 지적되었다

보안상의 문제: API 키의 하드코딩을 1건 감지. 환경 변수로 이행하는 계기가 되었다

중요한 것은 리뷰의 품질이 안정된다는 점이다. 사람의 리뷰는 피곤하거나 태스크가 쌓여 있을 때 품질이 떨어진다. AI 리뷰는 항상 같은 수준으로 체크를 한다.

특히 보안 항목은 사람이 놓치기 쉬운 부분이다. 스타트업이나 1인 개발자는 OWASP Top 10이나 개인정보보호법상의 보안 요건을 매번 체크하기 어렵다. AI 리뷰를 체크리스트의 1차 관문으로 두는 것으로 최소한의 보안 수준을 담보할 수 있다.

테스트 자동 생성

테스트가 없는 현실

솔직하게 말하자. 필자의 6개 서비스 중 제대로 된 테스트가 작성되어 있던 것은 2개 서비스뿐이었다. 나머지 4개 서비스의 테스트 커버리지는 거의 0%다.

"테스트를 써야 한다"는 것은 알고 있다. 하지만 기능 개발과 버그 수정으로 손이 꽉 찬 상태에서는 테스트를 작성할 시간을 확보하기 어렵다. 테스트 없는 코드가 늘어나고, 리팩토링이 두려워지고, 기술 부채가 쌓인다. 전형적인 악순환이다.

한국 스타트업 현장에서도 이 고민은 매우 일반적이다. "TDD를 하고 싶다" → "그런데 MVP를 먼저 내야 한다" → "기술 부채가 쌓였다" → "리팩토링할 여유가 없다" — 이 사이클에서 빠져나오지 못하는 팀이 대부분이다.

CTO 에이전트에 의한 테스트 일괄 생성

CTO 에이전트에는 기존 코드에 대해 테스트를 자동 생성하는 워크플로우가 포함되어 있다.

CEO의 지시:
/ai-ceo:dev:sprint
→ 태스크: CA의 테스트 커버리지 개선

CTO 에이전트의 플로우:
1. 기존 코드를 읽어들인다
2. 테스트가 부족한 모듈을 특정한다
3. 각 모듈에 대해 유닛 테스트를 생성한다
4. 테스트를 실행하여 전체 패스를 확인한다
5. PR을 작성한다

실제로 생성되는 테스트의 예를 살펴보자.

예: Firebase Cloud Functions의 테스트

원본 코드（테스트 없음）:

// functions/src/quiz.ts
export async function generateQuiz(
userId: string,
topicId: string
): Promise<Quiz> {
const topic = await getTopicById(topicId);
if (!topic) {
throw new Error(`Topic not found: ${topicId}`);
}

const userHistory = await getUserQuizHistory(userId, topicId);
const difficulty = calculateDifficulty(userHistory);

const questions = await generateQuestions(topic, difficulty, 5);

return {
id: generateId(),
userId,
topicId,
questions,
difficulty,
createdAt: new Date(),
};
}

CTO 에이전트가 생성한 테스트:

// functions/src/__tests__/quiz.test.ts

import { generateQuiz } from '../quiz';

import { getTopicById } from '../topics';

import { getUserQuizHistory } from '../history';

jest.mock('../topics');

jest.mock('../history');

const mockGetTopicById = getTopicById as jest.MockedFunction<

typeof getTopicById

const mockGetUserQuizHistory = getUserQuizHistory as jest.MockedFunction<

typeof getUserQuizHistory

describe('generateQuiz', () => {

const userId = 'user-001';

const topicId = 'topic-001';

beforeEach(() => {

jest.clearAllMocks();

});

it('should generate a quiz with correct structure', async () => {

mockGetTopicById.mockResolvedValue({

id: topicId,

name: 'JavaScript Basics',

content: '...',

});

mockGetUserQuizHistory.mockResolvedValue([]);

const quiz = await generateQuiz(userId, topicId);

expect(quiz).toMatchObject({

userId,

topicId,

questions: expect.any(Array),

difficulty: expect.any(Number),

});

expect(quiz.questions).toHaveLength(5);

expect(quiz.id).toBeDefined();

expect(quiz.createdAt).toBeInstanceOf(Date);

});

it('should throw error when topic not found', async () => {

mockGetTopicById.mockResolvedValue(null);

await expect(generateQuiz(userId, topicId)).rejects.toThrow(

'Topic not found: topic-001'

);

});

it('should adjust difficulty based on user history', async () => {

mockGetTopicById.mockResolvedValue({

id: topicId,

name: 'JavaScript Basics',

content: '...',

});

mockGetUserQuizHistory.mockResolvedValue([

{ score: 90, difficulty: 3 },

{ score: 85, difficulty: 3 },

{ score: 95, difficulty: 4 },

]);

const quiz = await generateQuiz(userId, topicId);

// High scores should increase difficulty

expect(quiz.difficulty).toBeGreaterThan(3);

});

에이전트가 생성하는 테스트의 특징은 다음과 같다.

목의 적절한 사용: 외부 의존（데이터베이스, API）을 적절하게 목 처리한다

정상 계열과 이상 계열 모두: 정상 케이스뿐만 아니라 에러 케이스（Topic not found）도 커버한다

엣지 케이스 고려: 유저 이력에 기반한 난이도 조정 테스트 등 비즈니스 로직의 엣지 케이스도 포함한다

테스트 생성의 품질과 한계

솔직히 말하면, 에이전트가 생성하는 테스트의 100%가 그대로 사용 가능한 것은 아니다. 체감상 다음과 같은 비율이다.

그래도, "테스트 커버리지 0%"에서 "60~70%"로의 개선이 에이전트에 지시하는 것만으로 실현된다. 나머지 조정은 인간이 하지만, 0부터 테스트를 작성하는 것보다 훨씬 빠르다.

인프런·패스트캠퍼스 등 개발 교육 플랫폼에서 테스트 코드 강의를 수강하고도 실제 프로젝트에 적용하지 못하는 이유는 "어디서부터 시작해야 하는가"를 모르기 때문이기도 하다. AI가 생성한 테스트를 수정하면서 학습하는 것도 하나의 접근 방법이다.

핫픽스 자동화 워크플로우

/ai-ceo:dev:hotfix 의 플로우

프로덕션 환경에서 버그가 발견된 경우의 플로우도 자동화하고 있다.

CEO의 지시:
/ai-ceo:dev:hotfix "DApp의 대시보드에서 데이터가 표시되지 않는다"

CTO 에이전트의 플로우（GSD Quick Mode）:
1. 문제 특정
- 에러 로그 확인
- 관련 코드 조사
- 원인 특정

2. 수정
- 최소한의 코드 변경
- 수정에 대한 테스트 추가

3. 테스트
- 기존 테스트 전체 실행
- 추가 테스트 실행

4. PR 작성
- hotfix/xxxx 브랜치
- 수정 내용 설명
- → approval-queue.md 에 추가（프로덕션 배포는 draft）

"GSD Quick Mode"란 통상의 스프린트 플로우를 간략화한 긴급 대응 모드다. 문제 특정부터 수정, 테스트, PR 작성까지를 한번에 실행한다.

실제 핫픽스의 흐름

어느 날 DApp의 유저 대시보드에서 데이터가 올바르게 표시되지 않는 버그가 보고되었다.

CEO의 조작은 다음 커맨드를 입력하는 것뿐이다.

/ai-ceo:dev:hotfix "DApp의 대시보드에서
유저의 포커스 세션 데이터가 표시되지 않는다.
Firestore의 쿼리가 빈 결과를 반환하고 있을 가능성이 있다"

CTO 에이전트가 다음 플로우를 자동 실행한다.

[자동] DApp 리포지토리의 코드를 조사
[자동] 대시보드 컴포넌트의 Firestore 쿼리를 특정
[자동] 쿼리의 조건식에 버그를 발견
（날짜 필터의 타임존 처리가 부정확）
[자동] 수정 코드를 작성
[자동] 테스트를 추가하여 실행（전체 패스）
[자동] hotfix/fix-dashboard-query 브랜치로 PR 작성
[자동] approval-queue.md 에 아이템 추가

CEO는 approval-queue.md에 추가된 아이템을 확인하고, PR 내용을 보고 승인한다.

/ai-ceo:approve AQ-005

승인 후, CTO 에이전트가 PR을 머지하고 서비스 배포 절차를 실행한다(배포 자체도 draft 모드로 확인을 거치는 경우가 있다).

버그 보고부터 수정 PR 완성까지, CEO의 실작업 시간은 약 10분이다. 종래라면 버그 원인 조사만으로 30분, 수정과 테스트에 1~2시간은 걸렸을 것이다.

타임존 관련 버그는 한국 서비스에서 특히 자주 발생한다. 서버가 UTC 기준으로 동작하더라도 한국 시간(KST, UTC+9)에 맞춘 날짜 필터를 적용해야 하는 경우가 많다. 이런 유형의 버그도 에이전트에게 "Firestore 쿼리가 빈 결과를 반환"이라는 단서만 주면 타임존 처리까지 포함해 조사하고 수정한다.

복수 서비스의 CI/CD 관리 패턴

6개의 서비스에 CI/CD를 도입한 결과, 관리상의 패턴이 보이게 되었다.

기술 스택별 워크플로우 템플릿

서비스마다 CI/CD 설정을 처음부터 작성하는 것이 아니라, 기술 스택별로 템플릿을 준비하고 있다.

템플릿1: Next.js 프로덕트（AService, DService, 스킬 관리 Service）
→ lint + type-check + test + build

템플릿2: Flutter 앱（CApp, EApp）
→ analyze + test

템플릿3: 정적 사이트（랜딩 페이지 계열）
→ lint + build + Lighthouse CI

CTO 에이전트는 새로운 서비스에 CI/CD를 추가할 때 .company/steering/tech-stack.md를 참조하여 적절한 템플릿을 선택한다.

한국 환경에서 Next.js 프로젝트는 주로 Vercel 배포, Flutter 앱은 Google Play·App Store 배포가 많다. 각 배포 채널에 맞는 CD(Continuous Deployment)설정도 템플릿에 포함해두면 새 프로덕트 추가 시 적용이 더 빠르다.

PR 상태 체크 통일

모든 서비스에서 다음 상태 체크를 통일하고 있다.

# 필수 체크（전 프로덕트 공통）
required_checks:
- lint # 코드 품질
- type-check # 타입 체크（TypeScript）
- test # 테스트
- build # 빌드 성공

# 권장 체크（대응 프로덕트만）
optional_checks:
- ai-review # AI 코드 리뷰
- lighthouse # 퍼포먼스
- security # 의존 패키지 취약성

개발 부문 상태의 자동 업데이트

CI/CD의 실행 결과는 .company/departments/dev/STATE.md에 자동으로 반영된다.

## CI/CD 상황

| 프로덕트 | 최종 빌드 | 상태 | 테스트 커버리지 |
|---------|---------|------|--------------|
| AService | 2026-02-16 | 성공 | 45% |
| CApp | 2026-02-19 | 성공 | 32% |
| DSercice | 2026-02-20 | 성공 | 28% |
| EApp | 2026-02-15 | 성공 | 15% |
| 스킬 관리 Service | 2026-02-20 | 성공 | 22% |

CEO는 /ai-ceo:morning 커맨드로 이 정보를 포함한 다이제스트를 받고, 모든 서비스의 CI/CD 상태를 한눈에 파악할 수 있다. 어느 서비스의 빌드가 깨졌는지, 어느 서비스의 테스트 커버리지가 낮아졌는지를 아침에 2분만에 파악할 수 있다.

실천에서 얻은 교훈

CTO 부문 자동화를 1개월 이상 운용하여 몇 가지 중요한 교훈을 얻었다.

교훈1: 처음 에이전트 정의는 불완전해도 된다

처음 CTO 에이전트 정의는 현재의 절반 이하의 내용이었다. 사용하면서 "여기가 부족하다" "여기는 더 구체적으로 써야 한다"고 깨닫고 점차 개선해왔다.

완벽한 에이전트 정의를 처음부터 만들려고 하면 언제까지도 시작할 수 없다. "동작하는 것을 최대한 빠르게 내놓고, 피드백을 받아 개선한다" - 이것은 CTO 에이전트의 페르소나이지만, 에이전트 정의의 만드는 방법에도 그대로 적용된다. 린 스타트업의 MVP 철학과 같다.

교훈2: 권한의 입도는 운용하면서 조정한다

처음에는 모든 액션을 draft로 했다. 안전하지만 승인 큐가 쌓여 비효율적이었다. 반대로 execute로 너무 많이 이행하면 의도하지 않은 변경이 자동 실행되는 리스크가 있다.

현재의 세분화 수준(버그 수정은 execute, 서비스 배포는 draft)에 안착하기까지 2~3주의 시행착오가 있었다. "이 정도면 괜찮겠지"가 아니라, 실제로 돌려보고 "이건 너무 위험하다" "이건 매번 승인하는 게 귀찮다"를 체감하면서 조정해가는 것이 현실적이다.

교훈3: 상태 파일 업데이트를 잊지 않는다

에이전트에게 태스크를 실행시킨 후 .company/departments/dev/STATE.md의 업데이트를 잊으면,

/ai-ceo:morning의 다이제스트가 실태와 괴리된다.

CTO 에이전트의 워크플로우에 "마지막에 STATE.md를 업데이트한다"는 스텝을 명시적으로 넣음으로써 이 문제는 해소되었다. 사람 직원이 업무 완료 후 진행 보고를 하는 것과 같은 구조다.

교훈4: 에이전트 간 연계가 가치를 만든다

CTO 에이전트 단독으로도 충분히 가치가 있지만, 다른 부문의 에이전트와 연계했을 때 그 가치는 배가된다.

예를 들어, CMO 에이전트가 "DService의 LP 개선으로 CVR이 낮다"고 분석하고 개선안을 낸다. CTO 에이전트가 그 개선안을 구현하고 PR을 작성한다. CSO 부문의 에이전트가 개선된 LP를 사용하여 제안 자료를 업데이트한다. 이렇게 여러 부문이 연결되는 게, 다음 장에서 설명할 AI 에이전트 경영의 핵심이다.