---
type: knowledge
domain: ai-dev
status: active
last-reviewed: 2026-07-26
---

# 개발 파이프라인 분업

> 한 줄 정의
> 개발을 역할 분리된 AI 단계(기획→구현→리뷰→판정)로 나눠 돌리는 운용 구조. 프로덕션 검증 구현체는 [[S-skills-하네스-패턴]], 일반 이론은 [[Orchestrator-Workers]] · [[Supervisor Pattern]].

## 해결하는 문제

- 한 컨텍스트가 기획·구현·검증을 다 하면: 자기가 이해한 대로 만들고 자기 기준으로 합격시킨다 — 오류가 단계를 그대로 통과한다.
- 분업은 사람 조직처럼 **독립성**을 만든다: 단계 사이의 계약(산출물 파일)이 검증 지점이 된다.

## 핵심 원리

### 1. 역할과 산출물 계약

| 역할 | 입력 | 산출물 (파일) | 하지 않는 것 |
|------|------|--------------|-------------|
| PM | 사용자 요구 | 요구 브리핑 (완료 조건 포함) | 기술 결정 |
| Tech Lead | 브리핑 | 분해·디스패치 카드 | 전부 직접 구현 |
| 전문 구현자 ×N | 카드 (파일 소유권 명시) | 코드 + 자기 보고 | 소유권 밖 파일 수정 |
| 리뷰어 (렌즈별) | diff + 카드 | 심각도별 지적 | 취향으로 차단 |
| QA/Judge | **원본 브리핑 + 실제 변경물** | PASS/FAIL 판정 | 구현자 보고 참조 (독립성) |

- 단계 간 전달은 **대화가 아니라 파일**로 — 추적 가능하고, 세션이 죽어도 이어지고, 판정 근거가 남는다.
- 실행 단위마다 ID(RUN_ID)를 발급해 모든 산출물에 박으면 파이프라인 전체가 추적된다.

### 2. 병렬 구현의 충돌 방지
- 기본: **파일 소유권 분할** — 같은 단계의 병렬 에이전트는 서로 다른 파일을 소유한다.
- 불가피한 동시 수정만 worktree 격리(각자 사본에서 작업 후 병합).
- 소유권을 카드에 명시하지 않은 병렬 실행은 도박이다.

### 3. 리뷰어는 복제하지 말고 렌즈를 나눈다
- 같은 프롬프트 3번 = 같은 맹점 3번. **정확성 / 보안 / 재현성** 등 다른 렌즈 N개 + 다수결이 맞다.
- 심각도 보정을 강제한다: 차단은 실제 결함(버그·보안·데이터 손실)만, 취향은 Nit. AI 리뷰어는 사소한 지적을 과잉 생산하는 경향이 있다 — 보정 없으면 파이프라인이 잡음에 막힌다.
- 교차 모델 리뷰(다른 벤더 모델 1개)는 값싼 다양성 추가다 — 단, 실패해도 진행되는 비차단(best-effort) 경로로.

### 4. 파이프라인 자체의 개선에도 게이트를 건다 (Self-Harness)
- 프로세스·프롬프트 개선은 ① 기록된 마찰(반복 실패·혼란)에서 출발 ② 약점 1:1 최소 변경 ③ **회귀 검증 통과 시에만 채택 후보** ④ 채택은 사람 승인.
- 마찰은 발생 즉시 로그(append-only)에 남기고 주기 회고에서 모아 개선 후보로 — 인상이 아니라 기록이 개선을 정한다.

### 5. 확장은 필요가 증명된 뒤에
- 시작은 역할 2개(구현/판정)로 충분하다. PM·리뷰 렌즈·병렬은 **그 단계의 오류가 실제로 새는 것을 본 뒤** 추가한다.
- 단계 추가 비용 = 지연 + 비용 + 디버깅 표면. [[TECHNOLOGY-DECISION-GUIDE]] 2축(멀티 승격)과 같은 논리다.

## 안티패턴

- **구현자 자기 QA** — 가장 흔한 독립성 붕괴. 판정 입력에서 자기 보고를 뺀다.
- **대화로 전달되는 파이프라인** — 산출물 파일 없음 = 추적 불가 + 재현 불가.
- **전 단계 최고 모델** — 분류·정리 단계까지 최고가 모델 (12축 모델 계층화 위반).
- **리뷰 통과율 100%** — 리뷰가 죽었다는 신호지 품질의 증거가 아니다.
- **하네스 무한 수선** — 회귀 검증 없는 프로세스 변경이 마찰을 재생산한다.

## 관련 문서

- [[역할별 개발 산출물]] · [[S-skills-하네스-패턴]] · [[AI 페어 개발 원리]] · [[Orchestrator-Workers]] · [[Supervisor Pattern]] · [[Evaluator-Optimizer]] · [[LLM-as-a-Judge]]