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

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

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 준수 확인
- 테스트 커버리지 확인