| name | team-adoption-plan |
| description | CI/CD·품질 도구의 팀 도입 계획을 수립한다. 합의 형성·역할 분담·PR 워크플로·예외 규정·단계적 적용 절차를 포함한다. |
| argument-hint | [project-dir|tool-name] (선택: 팀 규모 또는 도입 대상) |
| user-invocable | true |
| disable-model-invocation | true |
| allowed-tools | Read, Grep, Glob |
당신은 신중한 시니어 엔지니어다. $ARGUMENTS 를 대상으로 아래 작업을 수행하라.
실행 모드
- 간단 모드(기본값): 절차 2(합의 형성), 3(역할 분담), 6(단계적 적용 계획)만 수행하여 도입 계획의 핵심 구조만 반환
- 상세 모드:
--detailed 옵션이 포함된 경우, 6단계를 모두 수행하여 PR 워크플로·예외 규정까지 포함한 전체 도입 계획을 반환
$ARGUMENTS의 --detailed 옵션이 없으면 간단 모드로 실행한다.
간단 모드에서는 출력 형식 중 해당 섹션만 출력한다.
목적
새로운 CI/CD 파이프라인·품질 도구·개발 방식 등을 팀에 도입하기 위한 계획을 수립한다.
기술 설정뿐 아니라, 팀 내 합의 형성·역할 분담·워크플로 변경·예외 규정·단계적 확산 전략까지 포함한 조직 차원의 도입 계획을 작성한다.
입력
- 프로젝트 디렉터리 또는 도입 대상 도구·방식 (필수)
- 선택: 팀 규모(인원 수) 및 구성(프론트엔드/백엔드/풀스택 등)
- 선택: 현재 개발 프로세스 및 도구 구성
- 선택: 도입 배경(품질 문제, 확장성, 규정 준수 등)
- 선택: 예상되는 반대 의견 또는 우려 사항
- 정보가 부족하면 사용자에게 질문한다
절차
1. 현재 개발 방식 분석
- Glob으로 현재 설정 파일 검색:
- CI/CD 설정 (
.github/workflows/, Jenkinsfile, .gitlab-ci.yml)
- 린터·포매터 설정
- 테스트 및 커버리지 설정
- Git Hook 설정 (
.husky/, .pre-commit-config.yaml)
- Grep으로
CONTRIBUTING.md, 개발 가이드, 코딩 규칙 검색
- 기존 PR 템플릿 및 리뷰 기준 확인
- 현재 문제점 정리 (도구 부족, 규칙 부재, 개인 의존 등)
2. 합의 형성 계획 수립
도입 목적과 기대 효과 명확화
- 해결하려는 문제:
- 버그 유입 빈도
- 릴리스 불안정성
- 리뷰 기준의 개인 편차
- 기대 효과:
- CI 기반 자동 품질 검증
- 반복 작업 자동화로 시간 절감
- 리뷰 기준의 표준화
합의 형성 단계 설계
- 문제 공유 세션 진행 (회고·기술 공유 시간 활용)
- 도입 제안서 작성 (Before/After 비교, 타 팀 사례)
- 파일럿 기간 설정 및 평가 기준 합의
- 피드백 수집 및 개선 반영
3. 역할 분담 설계
| 역할 | 책임 | 권장 인원 | 적용 기간 |
|---|
| 추진자 | 도입 주도·질의 대응 | 1명 이상 | 도입기~정착기 |
| 설정 담당 | CI/CD·도구 설정 구축 | 1~2명 | 도입기 |
| 문서 담당 | 가이드 작성·업데이트 | 1명 | 전 기간 |
| 리뷰 담당 | 신규 기준 기반 선행 리뷰 | 1~2명 | 초기 1~2 스프린트 |
- 지식 공유 세션 정기 운영
- 설정 변경 이력 문서화
- 담당자 교체 주기 설정
4. PR 워크플로 설계 (상세 모드 전용)
기본 흐름
- 브랜치 생성
- 코드 수정 + 로컬 검증
- PR 생성 (템플릿 작성)
- CI 자동 검사
- 리뷰어 수동 검토
- 머지
머지 조건
병목 대응
- 리뷰 SLA 설정 (예: 24시간 내 1차 응답)
- CODEOWNERS 기반 자동 리뷰어 지정
- 리뷰 로테이션 운영
5. 예외 규정 수립 (상세 모드 전용)
| 예외 유형 | 조건 | 승인자 | 사후 조치 |
|---|
| 긴급 수정 | 서비스 장애 대응 | 팀 리드 | 사후 테스트 보완 |
| 실험 기능 | 실험 브랜치 한정 | 담당자 | 2주 후 재검토 |
| 레거시 코드 | 기존 코드 범위 | 팀 합의 | 점진적 개선 |
예외 관리 원칙
- 모든 예외는 문서화
- 정기 점검 (월 1회)
- 만료 기한 설정
6. 단계적 적용 계획
| 단계 | 기간 | 주요 활동 | 완료 조건 | 중단 기준 |
|---|
| Phase 0 | 1~2주 | 도구 선정·환경 구성 | 내부 테스트 완료 | - |
| Phase 1 | 2~4주 | 일부 팀 시범 적용 | 파일럿 피드백 수집 | 만족도 50% 미만 |
| Phase 2 | 1~2스프린트 | 전체 확산 | CI 안정화 | 오류율 증가 |
| Phase 3 | 1스프린트 | 운영 기준 확정 | 문서화 완료 | - |
| Phase 4 | 지속 | 자동화 고도화 | KPI 달성 | - |
출력 형식
``markdown
현황 분석
- 팀 구성: [추정 또는 입력된 팀 정보]
- 현재 도구 구성: [확인된 CI/CD·품질 도구 목록]
- 현재의 문제점: [정리된 문제 목록]
- 도입 대상: [도입하려는 도구·개발 방식 개요]
합의 형성 계획
도입 목적 및 기대 효과
| 문제 | 현재 상태 | 도입 후 기대 효과 |
|---|
| [문제1] | [현재 상태] | [기대되는 개선] |
| [문제2] | [현재 상태] | [기대되는 개선] |
합의 형성 단계
- [1단계: 문제 공유]
- [2단계: 제안 및 논의]
- [3단계: 시범 운영 합의]
- [4단계: 결과 평가 및 정식 도입 결정]
역할 분담
| 역할 | 책임 | 권장 인원 | 기간 |
|---|
| 추진 담당 | [책임 범위] | [N명] | [도입기~정착기] |
| 설정 담당 | [책임 범위] | [N명] | [도입기] |
| 문서 담당 | [책임 범위] | [N명] | [전 기간] |
PR 워크플로우
전체 흐름
- [브랜치 생성]
- [코드 수정 + 로컬 점검]
- [PR 생성(템플릿 작성)]
- [CI 자동 점검]
- [리뷰어의 수동 검토]
- [병합]
병합 조건
예외 규정
| 예외 상황 | 조건 | 승인자 | 사후 조치 |
|---|
| 긴급 수정 | [조건] | [승인자] | [사후 조치] |
| 실험적 변경 | [조건] | [승인자] | [사후 조치] |
| 레거시 코드 | [조건] | [승인자] | [사후 조치] |
예외 관리 원칙
- [예외 기록 방법]
- [정기 점검 주기]
- [예외 유효 기간 및 연장 조건]
단계별 적용 계획
| 단계 | 기간 | 내용 | 완료 조건 | 중단 기준 |
|---|
| Phase 0 | [기간] | 준비 | [조건] | - |
| Phase 1 | [기간] | 시범 운영 | [조건] | [기준] |
| Phase 2 | [기간] | 확대 적용 | [조건] | [기준] |
| Phase 3 | [기간] | 정착 | [조건] | - |
| Phase 4 | [기간] | 고도화 | [조건] | - |
성공 지표(KPI)
| 지표 | 현재 값 | 목표 값 | 측정 방법 |
|---|
| [지표1] | [현재] | [목표] | [방법] |
| [지표2] | [현재] | [목표] | [방법] |
리스크 및 대응 방안
| 리스크 | 발생 가능성 | 영향도 | 대응 방안 |
|---|
| [리스크1] | 높음/보통/낮음 | 높음/보통/낮음 | [대응 방안] |
## 유의사항
- 프로젝트 설정 파일은 변경하지 않고, 계획서만 작성한다.
- 팀의 기존 문화나 개발 방식을 부정적으로 표현하지 않는다.
- 도입 계획은 강제가 아닌 제안 형태로 작성하며, 최종 결정은 팀의 합의를 따른다.
- 개인 이름이나 내부 평가 정보는 포함하지 않는다.
- 인증 정보나 접근 권한의 구체 값 등 보안 설정 세부 내용은 포함하지 않는다.
## 종료 조건
위 형식에 맞춘 팀 도입 계획서를 작성하면 종료한다.
현황 분석, 합의 형성 계획, 역할 분담, PR 워크플로우, 예외 규정, 단계별 적용 계획, 성공 지표가 모두 포함되어 있어야 한다.
실제 적용은 팀의 합의를 얻은 뒤 진행한다.