Hyun-Kim95/client-project-lifecycle

client-project-lifecycle

목적

프로젝트 폴더에 템플릿(서브에이전트·스킬·rules)을 붙여 넣은 뒤, 고객 요구사항을 붙여 넣고 끝까지 납품하기 위한 표준 라이프사이클을 제공한다.
사람 승인 구간과 되돌림(루프)을 명시한다.

사용 시점

• 고객사 신규 프로젝트를 처음부터 체계적으로 진행할 때
• PRD 확정 전에는 구현하지 않고, 이중 목업(자체 + Stitch) 후 디자인을 고르고 싶을 때
• 구현 후 PRD 재검증 → (선택) 다축 검증·BLOCKER 루프·리뷰어 GATE → 테스트 문서 → 기능/성능 테스트 → 성능 목표까지 리팩터까지 포함하고 싶을 때

전제

• .cursor/agents/, .cursor/skills/, .cursor/rules/, AGENTS.md 등 템플릿이 이미 워크스페이스에 있다.
• 고객 요구사항 원문이 채팅 또는 docs/requirements/ 등에 붙어 있다.

사람 승인(HUMAN) 규칙

아래 단계에서 HUMAN이 표시되면, 에이전트는 다음 단계로 넘어가지 않고 사용자의 명시적 응답(승인 / 수정 지시 / 선택)을 기다린다.
사용자가 채팅에 “진행해”, “A안 선택”, “PRD 수정: …”처럼 답한다.
단계 4D의 HUMAN은 팀이 리뷰어 GATE를 사람 승인으로 둘 때만 적용한다.

---

단계 0 — 요구사항 반입

1. 사용자가 고객 요구사항을 채팅에 붙여 넣거나, 파일로 두었으면 경로를 알린다.
2. plan-feature로 1차 구조화하고, 필요하면 prd-agent를 사용한다.
3. 산출: 요구 분석 메모, 미확정·가정 목록.

단계 1 — PRD 초안

1. prd-agent로 PRD 초안을 작성한다. 저장 위치는 docs/requirements/ 등 팀 규칙에 따른다.
2. Gate 1 항목(목표, 흐름, 범위, 정책·예외, 미확정)을 PRD에 반영한다.

HUMAN — PRD 승인

3. 구현·목업 코드 작업을 시작하지 않는다. PRD 초안을 사용자에게 제시하고 승인 또는 수정 요청을 받는다.
4. 수정 요청이 있으면 PRD를 갱신하고 다시 HUMAN으로 돌아간다.
5. 사용자가 진행 허가하면 단계 2로 진행한다.

단계 2 — 이중 목업 (자체 디자인 + Stitch)

PRD가 확정된 뒤에만 진행한다.

2A 자체 디자인 트랙

1. design-system-agent 및 prd-agent와 정합되는 자체 UI 방향(토큰·톤·다크모드)을 잡는다.
2. frontend-agent로 목업 수준의 사이트/페이지(정적·프로토타입 수준 가능)를 구현한다. 경로는 프로젝트 규칙에 따른다(예: /mock-internal).

2B Stitch 트랙

1. docs/design/stitch-sop.md 순서로 Stitch MCP를 사용해 프로젝트·디자인 시스템·화면을 생성한다.
2. Stitch 결과를 PRD·Gate 1 화면 스펙과 맞춘다.
3. 필요하면 Stitch 기반 목업 페이지/에셋 링크를 문서에 정리한다(별도 정적 사이트가 아니어도 되면 스펙+캡처로 대체 가능).

2C 정합 검증 (루프)

1. 원본 요구사항 + 확정 PRD 대비 두 트랙 산출물이 범위·상태(로딩·빈·오류·권한)·플랫폼(웹/앱)에 맞는지 점검한다.
2. 어긋나면 단계 2A/2B 또는 PRD로 되돌아가 수정한다. 맞을 때까지 반복한다.

HUMAN — 중간 컨펌

3. 두 트랙 결과를 사용자에게 요약해 보여주고, 추가 수정 없이 디자인 선택으로 넘어갈지 확인한다.

단계 3 — 디자인 선택 후 병렬 완성

HUMAN — 디자인 선택

1. 사용자가 자체 목업 또는 Stitch 기반 중 하나를 선택한다.

2. 선택된 기준으로 .cursor/rules/60-delivery-gates.mdc의 Gate 2를 충족하도록 API 계약·상태 UI를 확정한다.

3. UI+API가 모두 필요하면 parallel-delivery로 frontend-agent + backend-agent를 투입한다. 그 외는 start-feature에 맞게 조정한다.

4. 계약 변경 시 document-change로 동기화한다.

단계 4 — 구현 완료 후 PRD 재검증 (루프)

1. verify-change 및 필요 시 qa-agent로 확정 PRD와 구현·문서·API 계약의 일치를 검증한다 (Gate 3 / DoD).

2. 불일치면 구현 또는 문서를 수정하고 다시 단계 4로 돌아간다.

3. 일치하면 단계 5로 진행한다. 납품 품질을 더 촘촘히 맞추려면 단계 4B~4D를 순서대로 검토한다(모두 선택).

---

단계 4B — 다축 검증 (LERP 정렬, 선택)

단계 4 통과 직후, 사용자가 요청했거나 팀이 납품 기준으로 정한 경우에 수행한다. 기능·아키텍처·코드 품질을 한 번에 묶지 않고 축별로 점검해 리포트로 남긴다.

1. 기능·수용 기준 축 — 확정 PRD·수용 기준 대비 E2E/통합 관점 점검. qa-agent 주도.

2. 아키텍처·구조 축 — 합의된 구조·계층·패턴 준수, 의존 방향·경계. 프로젝트에 맞는 기준으로 qa-agent 또는 코드 리뷰 관점으로 정리.

3. 코드 품질 축 — 타입·린트·테스트 커버리지·보안 스캔 등 프로젝트에 있는 도구로 점검 가능한 항목만 수행하고 결과를 요약.

4. 산출: docs/qa/ 등에 축별 요약과 이슈 목록(BLOCKER / MAJOR / MINOR 구분 권장). 세 축은 병렬로 진행해도 된다.

5. 4B를 생략해도 단계 5로 진행할 수 있다(소규모·긴급 납품 등).

단계 4C — BLOCKER 수정 루프 (선택)

단계 4B에서 BLOCKER 또는 팀이 정한 출시 불가 수준이면 수행한다.

1. 이슈를 우선순위로 정리한 수정 계획을 짧게 남긴다.

2. FE·BE 모두 해당하면 frontend-agent·backend-agent로 병렬 수정을 검토한다.

3. 수정 후 단계 4B(해당 축만) 또는 단계 4부터 다시 점검한다. BLOCKER가 없을 때까지 루프한다.

4. 4B를 수행하지 않았다면 이 단계는 생략한다.

단계 4D — 리뷰어 GATE (선택)

최종 납품 전 한 번 더 품질을 잠글 때 사용한다. 루브릭은 docs/qa/reviewer-gate-rubric.md를 따른다.

1. qa-agent로 5항목 × 20점 = 100점 만점 채점표를 작성하고, 근거(파일·화면·로그)를 짧게 붙인다.

2. 합격: 총점 80점 이상이고 루브릭의 치명적 결함 규칙을 만족할 것.

3. 불합격이면 수정 후 같은 기준으로 재채점한다. 동일 릴리스 기준 최대 2회까지 권장하며, 초과 시 범위 축소·에스컬레이션을 검토한다.

HUMAN — 리뷰어 GATE (선택)

4. 팀 정책으로 사람이 최종 통과를 서명하는 경우, 채점 결과를 사용자에게 제시하고 승인 또는 “재수정 후 다시 GATE” 지시를 받는다. 자동 GATE만 쓰는 팀은 이 HUMAN을 생략한다.

5. 통과(또는 팀 정책상 완료) 후 단계 5로 진행한다.

---

단계 5 — 테스트 문서 및 실행

1. docs/qa/ 등에 기능 테스트 시나리오(화면·API·권한·상태)를 문서화한다. qa-agent·docs-agent 활용.

2. 테스트를 실행하고(수동 또는 프로젝트에 있는 자동화), 실패 항목은 수정 후 다시 실행한다.

3. 기능 테스트가 모두 통과할 때까지 루프한다.

단계 6 — 성능 테스트 및 리팩터 (루프)

1. 성능 기준(응답 시간, 리소스, 번들 크기 등)을 PRD·비기능 요구 또는 별도 합의로 정한다.

2. 성능 테스트를 수행한다. 목표 미달이면 리팩터·최적화를 하고 다시 측정한다.

3. 배포 가능 수준으로 합의되면 루프를 종료한다.

단계 7 — 작업 완료 처리

1. document-change 또는 docs-agent로 납품 요약·영향 범위·알려진 제한·운영 확인 포인트를 정리한다.

2. 필요 시 release-check를 수행한다.

3. 사용자에게 완료 보고를 한다.

---

연결 스킬·에이전트 (참고)

| 구간 | 스킬 / 에이전트 | |------|-----------------| | 요구·PRD | plan-feature, prd-agent | | Stitch | docs/design/stitch-sop.md, MCP user-stitch | | 목업·구현 | design-system-agent, frontend-agent, backend-agent | | 병렬 | parallel-delivery, start-feature | | 검증 | verify-change, qa-agent | | 다축 검증·GATE (선택) | 단계 4B~4D, docs/qa/reviewer-gate-rubric.md | | 문서 | document-change, docs-agent | | 배포 전 | release-check |

예외

• 긴급 핫픽스·아주 작은 변경은 AGENTS.md의 직접 처리 예외에 따라 이 스킬 전체를 생략할 수 있다.
• Stitch 미사용 시 단계 2B는 생략하고 자체 목업만으로 HUMAN 선택을 진행한다.
• 단계 4B~4D는 선택이다. 사용자가 “다축 검증·리뷰어 GATE 생략”을 명시하면 단계 4 직후 단계 5로 넘어간다.