AI 팀원과 일하는 법 — Skills로 가상 소프트웨어 회사 만들기
1인 개발의 한계, 그리고 발상의 전환
혼자서 서비스를 만들다 보면 반복적으로 부딪히는 문제가 있다.
기획하다가 코딩하고, 코딩하다가 디자인 고민하고, 결국 리뷰 없이 머지한다. 역할 전환의 비용이 크고, 자기 코드를 자기가 리뷰하면 놓치는 게 생긴다. "이게 사용자한테 정말 가치가 있는 기능인가?"라는 질문은 코드를 다 짠 뒤에야 떠오른다. 그때는 이미 되돌리기엔 너무 늦다.
AI 코딩 도구들이 좋아지면서 "코드 생성"은 빨라졌지만, 근본적인 문제는 여전했다. Copilot이 자동완성을 아무리 잘 해줘도, 기획-디자인-개발-리뷰라는 과정 자체가 1인에게는 벅찬 것이다. 코드를 빠르게 짜는 것과 좋은 제품을 만드는 것은 다른 문제다.
그래서 생각했다. AI에게 코드가 아니라 '역할'을 줄 수 있다면 어떨까?
"이 함수를 짜줘"가 아니라 "너는 CPO야. 이 기획서가 사용자에게 가치가 있는지 리뷰해줘"라고 하면 어떨까. 기획자, 디자이너, 개발자, 리뷰어를 각각 다른 AI 역할로 분리하면, 혼자서도 팀처럼 일할 수 있지 않을까.
Claude Code의 Skills 시스템이 딱 그 해답이었다. 마크다운 파일 하나로 AI에게 페르소나, 책임 범위, 행동 원칙, 보고 체계를 부여할 수 있다. 이걸 확장해서 CPO, CTO, CXO부터 서비스별 기획자, 디자이너, 개발자까지 28개 역할을 세팅했다.
결과적으로 나는 CEO로서 "/develop 블로그에 뉴스레터 기능 추가해줘"라고 한 마디 하면, 기획서 작성부터 C-Level 리뷰, 피드백 반영, 실제 구현까지 자동으로 진행되는 가상 소프트웨어 회사를 만들었다.
우리가 만들고 있는 서비스
시스템 설명에 앞서, 이 가상 회사가 실제로 만들고 있는 서비스부터 소개한다.
| 서비스 | 설명 | 주요 기능 |
|---|---|---|
| Blog | 팀 블로그 | 마크다운 에디터, 댓글/대댓글, 좋아요, 뉴스레터 구독, 인기글 |
| DFC | 디지털 고정비용 계산기 | 구독 서비스 카탈로그, 내 구독 관리, 월/연 비용 자동 환산 |
| Quiver | 퀴즈 테스트 | 성격/유형 테스트, MBTI/점수 모드, 결과 공유, Admin 패널 |
기술 스택은 프론트엔드가 Next.js(App Router) + TypeScript + Tailwind CSS + React Query + Zustand, 백엔드가 Kotlin + Spring Boot + JPA + PostgreSQL이다. 하나의 모노레포에서 세 개 서비스를 함께 개발한다.
세 개 서비스가 동시에 돌아가다 보니, 1인 개발의 한계가 더 뚜렷해졌다. 블로그 댓글 기능을 만들다가 Quiver 퀴즈 데이터 형식이 안 맞아서 수정하고, DFC 계산 로직 버그를 잡다가 하루가 끝난다. 컨텍스트 스위칭만으로도 하루의 에너지를 소진할 수 있다.
조직 구조 설계
실제 스타트업의 조직도를 참고해서 계층 구조를 설계했다. 핵심 원칙은 세 가지다.
- 관심사 분리: 각 역할은 자기 영역에만 집중한다
- 보고 라인: 모든 산출물은 상위 의사결정자의 리뷰를 거친다
- 서비스 전담: 도메인 지식이 필요한 역할은 서비스별로 분리한다
전체 조직도
┌─────────────────┐
│ CEO (사람, 나) │
└────────┬────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
┌────────▼────────┐ ┌────────▼────────┐ ┌────────▼────────┐
│ CPO (Claude) │ │ CTO (Claude) │ │ CXO (Claude) │
│ 제품 총괄 │ │ 기술 총괄 │ │ 경험 총괄 │
└────────┬────────┘ └────────┬────────┘ └────────┬────────┘
│ │ │
┌──────┴──────┐ ┌──────┴──────┐ ┌──────┴──────┐
│ │ │ │ │ │
┌───▼───┐ ┌────▼──┐ ┌▼─────┐ ┌─────▼┐ ┌─▼──────┐ │
│Planner│ │Content│ │Back- │ │Front-│ │Designer│ │
│(Gemini│ │Creator│ │end │ │end │ │(Gemini)│ │
│ x3) │ │(Gemini│ │(Codex│ │(Codex│ │ x3 │ │
│ │ │+Codex)│ │ ) │ │ ) │ │ │ │
└───────┘ │ │ └──────┘ └──────┘ └────────┘ │
└───────┘ ┌───────┴───────┐
│ │
┌───▼───┐ ┌────▼────┐
│ DB │ │ SEO │
│ Admin │ │ Admin │
│(Codex)│ │(Codex) │
└───────┘ └─────────┘
서비스별 전담 인력 배치
┌─────────────────────────────────────────────────────────┐
│ 서비스별 전담 팀 구성 │
├──────────┬──────────────┬──────────────┬────────────────┤
│ 역할 │ Blog │ DFC │ Quiver │
├──────────┼──────────────┼──────────────┼────────────────┤
│ 기획자 │ blog-planner │ dfc-planner │ quiver-planner│
│ 디자이너 │ blog-designer│ dfc-designer │quiver-designer│
│ 콘텐츠 │ blog-content │ dfc-content │ quiver-content│
│ 프론트엔드│blog-frontend │ dfc-frontend │quiver-frontend│
│ 백엔드 │ blog-backend │ dfc-backend │ quiver-backend│
├──────────┼──────────────┴──────────────┴────────────────┤
│ 공통 │ CPO, CTO, CXO, DB Admin, SEO Admin │
│ │ + 워크플로우: /develop, /create-content │
└──────────┴──────────────────────────────────────────────┘
각 서비스별 기획자는 해당 서비스의 도메인 지식을 프롬프트에 내장하고 있다. 예를 들어 quiver-planner는 MBTI/점수 모드 스코어링 시스템, 질문 7~15개 권장, 결과 태그 매칭 규칙 등을 이미 알고 있다. 매번 "Quiver는 이런 서비스인데..."라고 설명할 필요가 없다.
C-Level의 역할 분담
세 명의 C-Level은 각각 다른 관점에서 품질을 보장한다.
CPO (Chief Product Officer) — "무엇을 만들 것인가?"
- 기획서의 사용자 가치를 검증한다
- "이 기능이 정말 사용자에게 필요한가?"를 묻는다
- MVP 범위가 적절한지, 유저 스토리가 구체적인지 판단한다
- 콘텐츠의 재미, 공유 가능성, 톤앤매너를 리뷰한다
CTO (Chief Technology Officer) — "어떻게 만들 것인가?"
- 개발 설계의 기술적 타당성을 검증한다
- "아키텍처와 일관성이 있는가? 과도한 엔지니어링은 없는가?"를 묻는다
- 보안 취약점, 성능 영향을 체크한다
- 콘텐츠 데이터의 스키마 적합성을 검증한다 (API 호환 여부)
CXO (Chief Experience Officer) — "사용자가 어떻게 느끼는가?"
- 디자인 계획의 일관성과 접근성을 검증한다
- WCAG 기준(4.5:1 대비율, 키보드 내비게이션, ARIA)을 체크한다
- 반응형 대응(375px/768px/1024px/1440px)을 확인한다
- 다크/라이트 모드 지원 여부를 점검한다
Skills 시스템 기술 구현
스킬 파일의 구조
각 팀원은 .claude/skills/[역할명]/SKILL.md 파일 하나로 정의된다.
.claude/skills/
├── cpo/SKILL.md # CPO (제품 총괄)
├── cto/SKILL.md # CTO (기술 총괄)
├── cxo/SKILL.md # CXO (경험 총괄)
├── blog-planner/SKILL.md # 블로그 기획자
├── blog-designer/SKILL.md # 블로그 디자이너
├── blog-content/SKILL.md # 블로그 콘텐츠 제작자
├── blog-frontend/SKILL.md # 블로그 프론트엔드 개발자
├── blog-backend/SKILL.md # 블로그 백엔드 개발자
├── dfc-planner/SKILL.md # DFC 기획자
├── ... # (DFC, Quiver 동일 구조)
├── develop/SKILL.md # 기능 개발 워크플로우
├── create-content/SKILL.md # 콘텐츠 제작 워크플로우
├── db-admin/SKILL.md # DB 관리자
├── seo-admin/SKILL.md # SEO 관리자
└── skill-manager/SKILL.md # 스킬 파일 관리자 (메타 역할)
YAML 프론트매터
파일 상단의 YAML이 역할의 메타데이터를 정의한다.
---
name: cto
description: CTO(기술 총괄 책임자) 역할을 수행합니다.
user-invocable: true
allowed-tools: Read, Grep, Glob, Bash, Task
---
각 필드의 역할은 이렇다.
name: 슬래시 커맨드 이름./cto로 호출한다.description: AI가 자동으로 적절한 역할을 선택할 때 참고하는 설명이다.user-invocable:false로 설정하면 직접 호출할 수 없는 베이스 템플릿이 된다. 기획자, 디자이너, 콘텐츠 제작자의 공통 패턴을 여기에 정의하고, 서비스별 역할이 이를 참조한다.allowed-tools: 역할별 권한 제어. CPO는Read, Grep, Glob, WebSearch만 쓸 수 있고(검토 역할이니까), 프론트엔드 개발자는Bash, Edit, Write까지 쓸 수 있다(코드를 짜야 하니까). 디자이너는 Figma MCP 도구(mcp__figma__get_screenshot등)까지 접근할 수 있다.
마크다운 본문 = 시스템 프롬프트
YAML 아래의 마크다운 본문이 AI의 행동을 정의하는 시스템 프롬프트가 된다. 실제 CPO 스킬 파일의 일부를 보면 이렇다.
# CPO (Chief Product Officer) - 제품 총괄 책임자
> **담당 AI**: Claude / Copilot
> **관리 대상**: Planner (Gemini)
당신은 이 프로젝트의 CPO입니다.
제품의 방향성과 사용자 가치에 대한 최종 책임자로서,
무엇을 만들 것인지를 결정합니다.
## 행동 원칙
1. **사용자 중심**: 모든 결정의 기준은 "사용자에게 어떤 가치를 주는가?"
2. **MVP 사고**: 가장 작은 범위로 가장 큰 가치를 검증
3. **데이터 기반**: 가설 → 실험 → 검증 사이클을 선호
## 리뷰 기준
### 기획서 리뷰 시
- [ ] 사용자 문제가 명확히 정의되었는가?
- [ ] 유저 스토리가 구체적인가?
- [ ] MVP 범위가 적절한가?
- [ ] 인수 조건이 검증 가능한가?
### 보고 형식
## CPO 제품 리뷰
### 판정: ✅ 승인 / ⚠️ 수정 필요 / ❌ 반려
### 피드백: ...
역할, 원칙, 체크리스트, 출력 형식까지 마크다운 하나에 담긴다. AI는 이 프롬프트대로 행동하며, 결과물도 정해진 형식으로 출력한다.
스킬 파일 작성의 핵심 원칙
가장 중요한 원칙이 하나 있다. 코드 경로를 절대 넣지 않는다.
# 잘못된 예
"src/app/blog/components/CommentList.tsx를 수정하세요"
# 올바른 예
"블로그 서비스의 댓글 목록 컴포넌트를 수정하세요"
코드 구조는 리팩토링할 때마다 바뀌지만, "댓글 목록 컴포넌트"라는 개념은 바뀌지 않는다. 스킬 파일에 경로를 넣으면 폴더를 하나 옮길 때마다 스킬도 수정해야 한다. 원칙은 추상적으로, 실제 경로는 AI가 코드베이스를 탐색해서 스스로 찾게 하는 게 맞다.
이 원칙을 강제하기 위해 /skill-manager라는 메타 역할도 만들었다. 스킬 파일을 생성하거나 수정할 때 코드 경로가 포함되면 자동으로 걸러낸다.
AI 모델별 역할 배정 전략
모든 역할에 같은 AI를 쓰지 않았다. 각 모델의 강점에 맞게 배정했다.
┌──────────────────────────────────────────────────────────┐
│ AI 모델별 역할 배정 │
├─────────────┬─────────────────────┬──────────────────────┤
│ Claude │ Gemini │ Codex │
│ (전략/리뷰) │ (기획/디자인/창작) │ (코드/구현) │
├─────────────┼─────────────────────┼──────────────────────┤
│ CPO │ blog-planner │ blog-frontend │
│ CTO │ dfc-planner │ blog-backend │
│ CXO │ quiver-planner │ dfc-frontend │
│ │ blog-designer │ dfc-backend │
│ │ dfc-designer │ quiver-frontend │
│ │ quiver-designer │ quiver-backend │
│ │ │ db-admin │
│ │ │ seo-admin │
├─────────────┴─────────────────────┴──────────────────────┤
│ 콘텐츠 제작자: Gemini + Codex (듀얼 생성) │
│ blog-content, dfc-content, quiver-content │
└──────────────────────────────────────────────────────────┘
Claude는 전략과 리뷰를 맡는다. 복합적인 판단이 필요한 C-Level 역할에 적합하다. "이 기획서의 MVP 범위가 적절한가?"처럼 여러 기준을 동시에 고려해야 하는 의사결정에 강하다.
Gemini는 기획과 디자인을 맡는다. 유저 스토리를 풀어쓰거나, 화면 레이아웃을 구상하거나, 창의적인 퀴즈 질문을 만드는 등 열린 사고가 필요한 역할에 배정했다.
Codex는 코드 구현을 맡는다. API 엔드포인트, 컴포넌트, 상태 관리 훅 등 구체적인 코드를 생성하는 데 특화되어 있다. 정해진 패턴을 정확하게 따르는 것이 중요한 개발자 역할에 적합하다.
듀얼 생성 방식 — 콘텐츠 제작의 비밀 무기
특히 콘텐츠 제작에서 듀얼 생성 방식이 효과적이었다. 하나의 주제로 두 가지 접근을 동시에 시도한다.
┌────────────────────┐
│ 콘텐츠 주제 입력 │
│ "직장인 번아웃 테스트"│
└─────────┬──────────┘
│
┌──────────┴──────────┐
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ 버전 A │ │ 버전 B │
│ Gemini 스타일 │ │ Codex 스타일 │
│ 유머/감성 중심 │ │ 논리/정보 중심 │
└──────┬──────┘ └──────┬──────┘
│ │
└──────────┬──────────┘
│
┌─────────▼─────────┐
│ 25점 비교 채점 │
│ │
│ 재미/흥미도 /5 │
│ 질문 명확성 /5 │
│ 결과 매력도 /5 │
│ 스코어링 균형 /5 │
│ 한국어 자연스러움 /5 │
└─────────┬─────────┘
│
┌─────────▼─────────┐
│ 최선 선택 또는 │
│ 하이브리드 조합 │
└───────────────────┘
같은 주제인데 접근 방식이 다르면 결과물의 성격이 꽤 달라진다. "직장인 번아웃 테스트"를 예로 들면, 감성 버전은 "월요일 아침, 알람이 울립니다. 당신의 첫 반응은?"처럼 공감형 질문을 만들고, 논리 버전은 "최근 1개월간 야근 빈도는?"처럼 측정형 질문을 만든다. 둘 다 쓸 만하지만 톤이 다르다. 비교하고 장점만 골라서 조합하면 한쪽만 쓸 때보다 더 좋은 결과물이 나온다.
워크플로우 자동화
개별 역할보다 중요한 건 이들이 함께 작동하는 워크플로우다. 역할이 아무리 잘 정의되어 있어도, 실행 순서와 리뷰 게이트가 없으면 혼란스러운 결과물만 나온다. 두 가지 핵심 워크플로우를 만들었다.
/develop — 기능 개발 파이프라인
터미널에서 /develop 블로그에 뉴스레터 구독 기능 추가라고 입력하면 5단계가 자동으로 진행된다.
CEO: "/develop 블로그에 뉴스레터 구독 기능 추가"
│
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 1: 설계 ┃
┃ ┃
┃ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┃
┃ │ Planner │ │ Designer │ │ Backend │ │ Frontend │ ┃
┃ │ │ │ │ │ Developer│ │ Developer│ ┃
┃ ├──────────┤ ├──────────┤ ├──────────┤ ├──────────┤ ┃
┃ │유저스토리 │ │레이아웃 │ │API 설계 │ │컴포넌트 │ ┃
┃ │인수 조건 │ │컴포넌트 │ │데이터 │ │상태 관리 │ ┃
┃ │예외 상황 │ │반응형 │ │스키마 │ │라우팅 │ ┃
┃ └──────────┘ └──────────┘ └──────────┘ └──────────┘ ┃
┃ ┃
┃ 📄 Output: 기획서 + 개발 설계서 (문서만, 코드 없음) ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 2: C-Level 리뷰 ┃
┃ ┃
┃ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┃
┃ │ CPO │ │ CXO │ │ CTO │ ┃
┃ ├──────────────┤ ├──────────────┤ ├──────────────┤ ┃
┃ │ 기획서 리뷰 │ │ 디자인 리뷰 │ │ 설계 리뷰 │ ┃
┃ │"사용자 가치가 │ │"접근성 기준을 │ │"아키텍처와 │ ┃
┃ │ 있는가?" │ │ 충족하는가?" │ │ 일관성 있는가?"│ ┃
┃ ├──────────────┤ ├──────────────┤ ├──────────────┤ ┃
┃ │ ✅ / ⚠️ / ❌ │ │ ✅ / ⚠️ / ❌ │ │ ✅ / ⚠️ / ❌ │ ┃
┃ └──────────────┘ └──────────────┘ └──────────────┘ ┃
┃ ┃
┃ ❌ 반려 → Phase 1부터 재시작 ┃
┃ ✅ 전원 승인 → Phase 3 건너뛰고 Phase 4로 ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 3: 피드백 반영 (⚠️ 수정 필요 시에만) ┃
┃ ┃
┃ 수정 필요 판정을 받은 영역만 해당 담당자가 수정 ┃
┃ Planner → CPO 피드백 반영 ┃
┃ Designer → CXO 피드백 반영 ┃
┃ Developer → CTO 피드백 반영 ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 4: 구현 (이 단계에서만 코드 작성) ┃
┃ ┃
┃ ┌────────────────────┐ ┌────────────────────┐ ┃
┃ │ Backend Developer │ │ Frontend Developer │ ┃
┃ ├────────────────────┤ ├────────────────────┤ ┃
┃ │ API 엔드포인트 구현 │ │ 페이지/컴포넌트 구현 │ ┃
┃ │ 타입 정의 │ │ React Query 훅 │ ┃
┃ │ 보안 체크 │ │ Tailwind 스타일링 │ ┃
┃ └────────────────────┘ └────────────────────┘ ┃
┃ ┃
┃ ┌────────────────────┐ ┃
┃ │ Designer (QA) │ ┃
┃ ├────────────────────┤ ┃
┃ │ 비주얼 QA 수행 │ ┃
┃ │ 디자인 체크리스트 │ ┃
┃ └────────────────────┘ ┃
┗━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 5: CEO 최종 보고 ┃
┃ ┃
┃ - 생성/수정된 파일 목록 ┃
┃ - 인수 조건 체크리스트 결과 ┃
┃ - 남은 작업 (있는 경우) ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
핵심 규칙은 Phase 1~3은 문서만, 코드는 Phase 4에서만 이라는 것이다. 설계가 승인되기 전에 코드를 쓰면 수정 비용이 기하급수적으로 늘어난다. 이건 실제 회사에서도 마찬가지다.
기획서는 all-service-plan/ 디렉토리에, 개발 설계서는 all-service-development-plan/ 디렉토리에 자동으로 저장된다. 나중에 "이 기능 왜 이렇게 설계했지?"라는 질문이 생기면 해당 문서를 열면 된다.
/create-content — 콘텐츠 제작 파이프라인
퀴즈 테스트 콘텐츠처럼 비개발 산출물도 파이프라인이 있다.
CEO: "/create-content 직장인 번아웃 테스트"
│
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 1: 콘텐츠 듀얼 생성 ┃
┃ ┃
┃ 기존 데이터 스키마 확인 → 2개 버전 동시 생성 ┃
┃ 버전 A (유머/감성) vs 버전 B (논리/정보) ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 2: 비교 선별 (25점 채점) ┃
┃ ┃
┃ 5개 기준 x 5점 = 25점 만점 ┃
┃ → 최선 선택 또는 하이브리드 조합 ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 3: CPO 리뷰 (콘텐츠 품질) ┃
┃ ┃
┃ "흥미로운가? 공유하고 싶은가? 톤앤매너가 맞는가?" ┃
┃ ✅ 승인 / ⚠️ 수정 필요 / ❌ 반려 ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 4: CTO 리뷰 (기술 검증) ┃
┃ ┃
┃ slug 형식, 결과 태그 매칭, JSON 스키마 적합성 ┃
┃ "POST /api/v1/admin/tests로 바로 전송 가능한가?" ┃
┃ ✅ 승인 / ⚠️ 수정 필요 / ❌ 반려 ┃
┗━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
▼
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Phase 5: 최종 JSON 출력 ┃
┃ ┃
┃ API에 바로 삽입 가능한 최종 데이터 ┃
┃ → Admin 페이지 직접 입력 또는 API 호출 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
CTO가 콘텐츠를 리뷰한다는 게 의아할 수 있다. 핵심은 데이터 스키마 적합성이다. 퀴즈 콘텐츠의 결과 태그가 선택지와 매칭되는지, ID가 고유한지, JSON이 API 스키마와 호환되는지를 검증한다. 콘텐츠지만 결국 코드에 들어가는 데이터이기 때문이다. "재미있는 퀴즈"를 만들었는데 결과 태그가 안 맞아서 앱이 터지면 아무 의미 없다.
실제 스킬 파일은 어떻게 생겼나
말로만 설명하면 추상적이니, 실제 스킬 파일 하나를 통째로 보자. Quiver 기획자의 스킬 파일이다.
---
name: quiver-planner
description: Quiver(퀴즈 테스트) 전담 기획자입니다.
user-invocable: true
allowed-tools: Read, Grep, Glob, WebSearch
---
# Quiver Planner - Quiver 전담 기획자
> **담당 AI**: Gemini
> **보고 라인**: CPO (Claude/Copilot)
## 담당 서비스
Quiver 퀴즈 테스트 서비스를 담당합니다.
사용자가 질문에 답하면 결과를 제공하고
공유할 수 있는 퀴즈 기반 성격/유형 테스트 서비스입니다.
## 핵심 사용자 플로우
테스트 목록 → 테스트 선택 → 설명 확인 → 시작
→ 질문 1 → 선택 → 질문 2 → ... → 결과 표시 → 공유
## 스코어링 시스템
### MBTI 모드
- 결과 태그가 4글자 MBTI (E/I, S/N, T/F, J/P 축별 집계)
### 점수 모드
- resultTag별 score 누적, 최고 점수 결과 표시
## 기획 시 주의사항
- 질문 7-15개, 선택지 질문당 2-5개, 결과 3-8개 권장
- 모든 결과 태그가 최소 1개 선택지에서 참조되어야 함
- slug는 영문 소문자+하이픈
- 결과가 긍정적이고 공유욕구를 자극하도록 설계
이 파일 하나가 Quiver 기획자의 전부다. 스코어링 시스템, 질문/결과 개수 제한, slug 규칙 등 도메인 지식이 내장되어 있다. /quiver-planner로 호출하면 이 맥락이 자동으로 로드된다.
문서 관리 체계
워크플로우가 만드는 산출물은 체계적으로 저장된다.
team-weggle-plus/
├── all-service-plan/ # 기획서
│ ├── blog-newsletter-plan.md
│ ├── quiver-share-feature-plan.md
│ └── ...
├── all-service-development-plan/ # 개발 설계서
│ ├── blog-newsletter-dev-plan.md
│ └── ...
├── all-service-blog-content/ # 블로그 콘텐츠
├── all-service-web/ # 프론트엔드 (Next.js)
└── all-service-be/ # 백엔드 (Spring Boot)
기획서에는 유저 스토리, 화면 흐름, 예외 상황, 인수 조건(Given/When/Then)이 담긴다. 개발 설계서에는 디자이너의 레이아웃 계획, 백엔드의 API 스키마, 프론트엔드의 컴포넌트 구조가 한 문서에 함께 담긴다. Phase 2에서 C-Level이 리뷰할 때 이 문서들을 기준으로 판단한다.
이 문서들이 쌓이면 프로젝트의 의사결정 히스토리가 된다. 3개월 뒤에 "뉴스레터 기능은 왜 이메일 발송을 별도 서비스로 분리했지?"라는 질문이 생기면, blog-newsletter-email-sending-plan.md를 열면 CTO가 왜 그런 판단을 내렸는지 기록이 남아 있다.
운영하며 느낀 점
좋았던 점
사고의 관성에서 벗어난다. 개발자 모드일 때는 "이게 구현 가능한가?"만 생각한다. 그런데 CPO 리뷰 단계가 끼면 "사용자에게 가치가 있는가?"라는 질문이 자동으로 들어온다. CXO 리뷰에서 "이거 375px에서 터치 타겟이 너무 작다"는 피드백이 나올 때도 있다. 혼자 개발하면서도 다각도 검토가 가능해진다.
의사결정이 문서로 남는다. all-service-plan/에 기획서가, all-service-development-plan/에 설계서가 자동으로 축적된다. "왜 이렇게 만들었지?"에 대한 답이 항상 존재한다. 미래의 나에게 보내는 편지 같은 것이다.
컨텍스트 스위칭 비용이 줄어든다. "블로그 댓글 기능 만들어줘"라고 하면 blog-planner, blog-designer, blog-frontend, blog-backend가 알아서 움직인다. 나는 최종 결과만 확인하면 된다. 서비스 간 전환도 슬래시 커맨드 하나로 끝난다.
주의할 점
스킬 파일은 추상적으로 쓴다. "Tailwind CSS만 사용한다"는 맞지만, "className에 반드시 flex gap-4를 쓴다"는 과하다. 원칙은 추상적으로, 실행은 AI가 현재 코드베이스를 보고 판단하게 해야 한다.
리뷰 단계를 절대 생략하지 마라. 급하면 Phase 2를 건너뛰고 싶어진다. 하지만 그때 나온 코드가 나중에 가장 많은 수정을 필요로 했다. 설계에 쓰는 5분이 디버깅에 쓸 1시간을 아껴준다.
역할 간 경계를 명확히 한다. CPO가 갑자기 코드 리뷰를 하거나, 프론트엔드 개발자가 기획까지 하면 역할 분리의 의미가 없어진다. allowed-tools로 권한을 제한하는 것이 이 경계를 강제하는 기술적 장치다.
마무리
결국 이 시스템의 본질은 AI에게 "코드를 짜라"가 아니라 "역할을 수행하라" 는 것이다.
프롬프트 하나에 모든 걸 때려넣는 대신, 역할별로 관심사를 분리하고, 체계적인 워크플로우로 연결했다. 소프트웨어 공학에서 말하는 "관심사의 분리(Separation of Concerns)"를 AI 에이전트 레벨에서 적용한 셈이다.
마크다운 파일 28개로 가상의 소프트웨어 회사를 만들었다. CEO로서 하는 일은 방향을 정하고, 결과를 확인하고, 최종 판단을 내리는 것이다. 나머지는 팀이 알아서 한다 — 다만 그 팀이 .claude/skills/ 디렉토리 안의 마크다운 파일일 뿐이다.
이 시스템이 완벽하다는 건 아니다. AI가 실수할 때도 있고, 리뷰가 너무 보수적이라 같은 설계서를 세 번 고칠 때도 있다. 하지만 혼자서 모든 걸 머릿속에서 처리하던 때보다는 확실히 낫다. 역할을 나누고, 프로세스를 만들고, 리뷰 게이트를 두는 것. 좋은 소프트웨어를 만드는 원칙은 사람이 하든 AI가 하든 같다.
함께 읽으면 좋은 글
댓글
2의견을 남겨보세요. 로그인하면 닉네임이 자동으로 입력됩니다.
댓글을 불러오는 중...