Squashed '.vendor/stage-pilot/' changes from 7ab085e..551777b
551777b feat: add interface contract and data model baseline support to bootstrap-baseline f17e086 feat: add bootstrap seed file support to bootstrap-baseline skill be85338 feat: introduce lightweight change path, change-req skill, and release feedback loop 949bb40 docs(skill): new-discovery 병렬 Discovery 및 active-cycle 처리 규칙 강화 7f96130 docs: fix draft-req skill template paths 94b1445 diff --git a/.github/skills/draft-batch-design/SKILL.md b/.github/skills/draft-batch-design/SKILL.md index 5f87d00..944e075 100644 --- a/.github/skills/draft-batch-design/SKILL.md +++ b/.github/skills/draft-batch-design/SKILL.md @@ -1,6 +1,6 @@ --- name: draft-batch-design -description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, or recording architecture and interface decisions before implementation." +description: "Use when: drafting the design document for an existing batch, running /draft-batch-design with a BAT ID, filling docs/batches/<BAT_ID>/design.md, recording architecture and interface decisions before implementation, or planning updates to docs/project-structure.md and docs/runtime-flows.md." argument-hint: "예: bat-001 또는 docs/batches/bat-001_20260424_scaffold" user-invocable: true --- @@ -9,27 +9,43 @@ user-invocable: true d1ce3ce 프로세스 완전 변경 git-subtree-dir: .vendor/stage-pilot git-subtree-split: 551777bc7009ee133fbaab1267ca324f1dc3c6bb
This commit is contained in:
@@ -0,0 +1,25 @@
|
||||
# {{BAT_ID}}: <배치 제목>
|
||||
|
||||
- Status: draft | in-delivery | release-candidate | released | archived
|
||||
- Profile: standard | batch-lite
|
||||
- Source Discovery: <dcy-id 또는 없음>
|
||||
- Included REQ: <REQ-ID 목록>
|
||||
- Excluded REQ: <REQ-ID 목록 또는 없음>
|
||||
|
||||
## Summary
|
||||
- <이 batch를 왜 묶었는지>
|
||||
|
||||
## Scope
|
||||
- In Scope:
|
||||
- <포함 범위>
|
||||
- Out of Scope:
|
||||
- <제외 범위>
|
||||
|
||||
## Documents
|
||||
- Planning: [planning.md](./planning.md)
|
||||
- Design: <`[design.md](./design.md)` 또는 `none (batch-lite with no architecture impact)`>
|
||||
- Implementation: <`[implementation.md](./implementation.md)` 또는 `create at implementation stage`>
|
||||
- Verification: <`[verification.md](./verification.md)` 또는 `create at verification stage`>
|
||||
|
||||
## Notes
|
||||
- <공통 리스크, 공통 결정 사항>
|
||||
@@ -0,0 +1,26 @@
|
||||
# {{BAT_ID}} Design
|
||||
|
||||
- Status: draft | confirmed
|
||||
- Batch: {{BAT_ID}}
|
||||
|
||||
## Architecture Summary
|
||||
- <배치 수준 설계 요약>
|
||||
|
||||
## Changed Areas
|
||||
- Docs: <문서 경로>
|
||||
- Modules: <모듈/컴포넌트>
|
||||
- Interfaces: <인터페이스>
|
||||
|
||||
## Key Decisions
|
||||
1. <결정 1>
|
||||
2. <결정 2>
|
||||
|
||||
## Edge Cases
|
||||
- <예외 처리 및 설계 경계>
|
||||
|
||||
## Architecture Impact
|
||||
- <none | project-structure | runtime-flows | both>
|
||||
|
||||
## Reference Doc Update Plan
|
||||
- project-structure.md: <갱신 계획 또는 none>
|
||||
- runtime-flows.md: <갱신 계획 또는 none>
|
||||
@@ -0,0 +1,20 @@
|
||||
# {{BAT_ID}} Implementation
|
||||
|
||||
- Status: draft | in-progress | completed
|
||||
- Batch: {{BAT_ID}}
|
||||
|
||||
## Plan Summary
|
||||
- <이번 구현에서 실제 변경할 범위>
|
||||
|
||||
## Changed Files
|
||||
- <파일 목록>
|
||||
|
||||
## Execution Log
|
||||
1. <실행 항목>
|
||||
2. <실행 항목>
|
||||
|
||||
## Validation
|
||||
- <실행한 테스트, lint, typecheck, 수동 점검>
|
||||
|
||||
## Remaining Risks
|
||||
- <잔여 이슈>
|
||||
@@ -0,0 +1,10 @@
|
||||
# Batch Index
|
||||
|
||||
## 목적
|
||||
- 이 문서는 batch delivery 단위의 전역 인덱스다.
|
||||
- 각 batch는 `docs/batches/<BAT_ID>/` 아래에서 profile(`standard` | `batch-lite`)에 맞는 산출물을 관리한다.
|
||||
|
||||
## Batch Register
|
||||
|
||||
| BAT ID | Profile | Status | Included REQ | Discovery | Folder |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
@@ -0,0 +1,28 @@
|
||||
# {{BAT_ID}} Planning
|
||||
|
||||
- Status: draft | confirmed
|
||||
- Batch: {{BAT_ID}}
|
||||
- Profile: standard | batch-lite
|
||||
|
||||
## Included REQ
|
||||
- <REQ-ID 목록>
|
||||
|
||||
## Delivery Plan
|
||||
- <구현 범위, 순서, 선행 조건>
|
||||
|
||||
## Dependencies
|
||||
- Internal:
|
||||
- <내부 의존성>
|
||||
- External:
|
||||
- <외부 의존성>
|
||||
|
||||
## Design Gate
|
||||
- Design Required Before Implementation: yes | no
|
||||
- Reason: <왜 즉시 design이 필요한지 또는 왜 생략 가능한지>
|
||||
|
||||
## Milestones
|
||||
1. <마일스톤>
|
||||
2. <마일스톤>
|
||||
|
||||
## Risks
|
||||
- <리스크와 대응>
|
||||
@@ -0,0 +1,21 @@
|
||||
# {{BAT_ID}} Verification
|
||||
|
||||
- Status: draft | confirmed
|
||||
- Batch: {{BAT_ID}}
|
||||
|
||||
## Acceptance Mapping
|
||||
- <REQ-ID>:
|
||||
- <AC와 evidence 연결>
|
||||
|
||||
## Evidence
|
||||
- Test:
|
||||
- <테스트 결과>
|
||||
- Manual:
|
||||
- <수동 검증 결과>
|
||||
- Logs:
|
||||
- <로그 또는 스크린샷 경로>
|
||||
|
||||
## Result
|
||||
- Ready for Release: false
|
||||
- Blocking Issues:
|
||||
- <차단 이슈 또는 없음>
|
||||
@@ -0,0 +1,95 @@
|
||||
schema_version: 1
|
||||
capture_mode: declared # declared | observed | mixed
|
||||
|
||||
project:
|
||||
repository_name: {{REPOSITORY_NAME:repo-folder-name}}
|
||||
display_name: {{PROJECT_NAME:display name or repo name}}
|
||||
summary: {{PROJECT_SUMMARY:one-sentence project summary}}
|
||||
primary_domain: {{PRIMARY_DOMAIN:short domain phrase or undecided}}
|
||||
|
||||
stack:
|
||||
tech_stack:
|
||||
- {{TECH_STACK_ITEM_1:primary language or framework}}
|
||||
|
||||
runtime:
|
||||
primary_runtime: {{PRIMARY_RUNTIME:cli|api-service|web-app|worker|library|mixed|other}}
|
||||
primary_entrypoints:
|
||||
- name: {{ENTRYPOINT_NAME_1:command or interface name}}
|
||||
purpose: {{ENTRYPOINT_PURPOSE_1:brief purpose}}
|
||||
|
||||
interfaces:
|
||||
contracts:
|
||||
- name: {{INTERFACE_NAME_1:primary interface name}}
|
||||
type: {{INTERFACE_TYPE_1:http-api|cli|event|file|internal-service|other}}
|
||||
actors: {{INTERFACE_ACTORS_1:who calls or receives it}}
|
||||
purpose: {{INTERFACE_PURPOSE_1:what this interface exists to do}}
|
||||
stability: {{INTERFACE_STABILITY_1:experimental|internal|stable}}
|
||||
inputs:
|
||||
- {{INTERFACE_INPUT_1_1:input contract or invocation note}}
|
||||
outputs:
|
||||
- {{INTERFACE_OUTPUT_1_1:output contract or artifact}}
|
||||
errors:
|
||||
- {{INTERFACE_ERROR_1_1:error code or failure behavior}}
|
||||
compatibility_rules:
|
||||
- {{INTERFACE_COMPATIBILITY_1_1:compatibility or versioning rule}}
|
||||
- name: {{INTERFACE_NAME_2:secondary interface name}}
|
||||
type: {{INTERFACE_TYPE_2:http-api|cli|event|file|internal-service|other}}
|
||||
actors: {{INTERFACE_ACTORS_2:who calls or receives it}}
|
||||
purpose: {{INTERFACE_PURPOSE_2:what this interface exists to do}}
|
||||
stability: {{INTERFACE_STABILITY_2:experimental|internal|stable}}
|
||||
inputs:
|
||||
- {{INTERFACE_INPUT_2_1:input contract or invocation note}}
|
||||
outputs:
|
||||
- {{INTERFACE_OUTPUT_2_1:output contract or artifact}}
|
||||
errors:
|
||||
- {{INTERFACE_ERROR_2_1:error code or failure behavior}}
|
||||
compatibility_rules:
|
||||
- {{INTERFACE_COMPATIBILITY_2_1:compatibility or versioning rule}}
|
||||
shared_constraints:
|
||||
- {{INTERFACE_SHARED_CONSTRAINT_1:cross-cutting interface constraint}}
|
||||
current_gaps:
|
||||
- {{INTERFACE_GAP_1:known contract gap or planned change}}
|
||||
|
||||
structure:
|
||||
planned_top_level_areas:
|
||||
- path: {{TOP_LEVEL_PATH_1:path such as src/ or app/}}
|
||||
responsibility: {{TOP_LEVEL_RESPONSIBILITY_1:brief responsibility}}
|
||||
|
||||
data_model:
|
||||
persistence_backend: {{PERSISTENCE_BACKEND:primary persistence backend or storage system}}
|
||||
entities:
|
||||
- name: {{ENTITY_NAME_1:primary entity}}
|
||||
purpose: {{ENTITY_PURPOSE_1:what this entity represents}}
|
||||
source_of_truth: {{ENTITY_SOURCE_1:table, collection, file, or service}}
|
||||
lifecycle: {{ENTITY_LIFECYCLE_1:created -> updated -> archived}}
|
||||
key_fields:
|
||||
- {{ENTITY_FIELD_1_1:field :: type :: meaning}}
|
||||
relationships:
|
||||
- {{ENTITY_RELATIONSHIP_1_1:related entity :: relationship meaning}}
|
||||
state_rules:
|
||||
- {{ENTITY_STATE_RULE_1_1:state or invariant rule}}
|
||||
- name: {{ENTITY_NAME_2:secondary entity}}
|
||||
purpose: {{ENTITY_PURPOSE_2:what this entity represents}}
|
||||
source_of_truth: {{ENTITY_SOURCE_2:table, collection, file, or service}}
|
||||
lifecycle: {{ENTITY_LIFECYCLE_2:created -> updated -> archived}}
|
||||
key_fields:
|
||||
- {{ENTITY_FIELD_2_1:field :: type :: meaning}}
|
||||
relationships:
|
||||
- {{ENTITY_RELATIONSHIP_2_1:related entity :: relationship meaning}}
|
||||
state_rules:
|
||||
- {{ENTITY_STATE_RULE_2_1:state or invariant rule}}
|
||||
consistency_rules:
|
||||
- {{CONSISTENCY_RULE_1:consistency or referential rule}}
|
||||
persistence_notes:
|
||||
- {{PERSISTENCE_NOTE_1:mapping, storage, or migration note}}
|
||||
current_gaps:
|
||||
- {{MODEL_GAP_1:known model gap or planned schema change}}
|
||||
|
||||
notes:
|
||||
known_unknowns:
|
||||
- {{KNOWN_UNKNOWN_1:optional unresolved bootstrap item or none}}
|
||||
|
||||
metadata:
|
||||
captured_at_kst: {{CAPTURED_AT_KST:YYYY-MM-DD HH:MM}}
|
||||
source: bootstrap-baseline-questionnaire
|
||||
updated_from: {{UPDATED_FROM:user-answer|repo-observation|mixed}}
|
||||
@@ -0,0 +1,88 @@
|
||||
# {{PROJECT_NAME}} Data Model
|
||||
|
||||
- Baseline Mode: {{BASELINE_MODE:declared|observed|mixed}}
|
||||
- Baseline Seed: {{BASELINE_SEED_PATH:.stagepilot/bootstrap/baseline.yaml}}
|
||||
- Status: draft | confirmed
|
||||
- Owner: {{OWNER_OR_TEAM}}
|
||||
- Last Updated (KST): {{UPDATED_AT_KST}}
|
||||
- Source Discovery / Batch: {{SOURCE_REF}}
|
||||
|
||||
## Project Summary
|
||||
- {{PROJECT_SUMMARY:one-sentence summary of the project}}
|
||||
|
||||
## Primary Domain
|
||||
- {{PRIMARY_DOMAIN:short domain phrase or undecided}}
|
||||
|
||||
## Primary Persistence Backend
|
||||
- {{PERSISTENCE_BACKEND:primary persistence backend or storage system}}
|
||||
|
||||
## Purpose
|
||||
- This document captures the approved cross-cutting data model baseline for the project.
|
||||
- It is a shared reference for REQ drafting, batch design, implementation, verification, migration planning, and handoff.
|
||||
|
||||
## Scope
|
||||
- Covers core entities, relationships, states, persistence mappings, and shared consistency rules.
|
||||
- Does not duplicate full functional acceptance criteria already owned by REQ documents.
|
||||
- Does not replace ORM definitions, migration files, or generated schema artifacts.
|
||||
|
||||
## Model Summary
|
||||
|
||||
{{MODEL_SUMMARY_BULLETS:- - <entity name> :: <role in the system>}}
|
||||
|
||||
## Entity: `{{ENTITY_NAME_1:primary entity}}`
|
||||
|
||||
- Purpose: {{ENTITY_PURPOSE_1:what this entity represents}}
|
||||
- Source of Truth: {{ENTITY_SOURCE_1:table, collection, file, or service}}
|
||||
- Lifecycle: {{ENTITY_LIFECYCLE_1:created -> updated -> archived}}
|
||||
|
||||
### Key Fields
|
||||
|
||||
{{ENTITY_FIELDS_1:- <field name> :: <type or shape> :: <meaning>}}
|
||||
|
||||
### Relationships
|
||||
|
||||
{{ENTITY_RELATIONSHIPS_1:- <related entity> :: <relationship meaning>}}
|
||||
|
||||
### State Rules
|
||||
|
||||
{{ENTITY_STATE_RULES_1:- <state or invariant rule>}}
|
||||
|
||||
## Entity: `{{ENTITY_NAME_2:secondary entity}}`
|
||||
|
||||
- Purpose: {{ENTITY_PURPOSE_2:what this entity represents}}
|
||||
- Source of Truth: {{ENTITY_SOURCE_2:table, collection, file, or service}}
|
||||
- Lifecycle: {{ENTITY_LIFECYCLE_2:created -> updated -> archived}}
|
||||
|
||||
### Key Fields
|
||||
|
||||
{{ENTITY_FIELDS_2:- <field name> :: <type or shape> :: <meaning>}}
|
||||
|
||||
### Relationships
|
||||
|
||||
{{ENTITY_RELATIONSHIPS_2:- <related entity> :: <relationship meaning>}}
|
||||
|
||||
### State Rules
|
||||
|
||||
{{ENTITY_STATE_RULES_2:- <state or invariant rule>}}
|
||||
|
||||
## Shared Consistency Rules
|
||||
|
||||
{{CONSISTENCY_RULE_BULLETS:- - <uniqueness, referential, or retention rule>}}
|
||||
|
||||
## Persistence / Integration Notes
|
||||
|
||||
{{PERSISTENCE_NOTES_BULLETS:- - <mapping, indexing, migration, or synchronization note>}}
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
{{MODEL_CURRENT_GAPS_BULLETS:- - <known model gap or planned schema change>}}
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when a core entity, key field, or relationship changes.
|
||||
- Update this document when lifecycle or persistence behavior changes.
|
||||
- Update this document when a batch introduces a migration, backfill, or breaking data assumption.
|
||||
|
||||
## Change Log
|
||||
|
||||
{{CHANGE_LOG_BULLETS:- - <change log entry>}}
|
||||
@@ -2,16 +2,19 @@
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 문서 ID: {{DISCOVERY_ID:dcy-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
- 대체됨: {{SUPERSEDED_BY_DISCOVERY:없음 또는 docs/discovery/<DISCOVERY_ID>.md}}
|
||||
- 후속 Discovery 참조: {{FOLLOW_UP_DISCOVERY_REF:없음 또는 docs/discovery/<DISCOVERY_ID>.md}}
|
||||
- 생성된 REQ 참조: 없음
|
||||
|
||||
# 1. 계획 상태 요약
|
||||
현재 Discovery가 어떤 배경에서 작성되고 있는지, 연계 문서가 있는지, 지금 시점의 해석이 무엇인지 짧게 요약한다.
|
||||
|
||||
- 연계 문서 현황:
|
||||
- Planning 점수 파일: {{PLANNING_SCORE_FILE:미생성 또는 경로}}
|
||||
- 관련 점수 파일: {{RELATED_SCORE_FILE:미생성 또는 경로}}
|
||||
- 관련 TODO/메모: {{TODO_FILE:경로 또는 없음}}
|
||||
- 해석:
|
||||
- {{SUMMARY_LINE_1:현재 검토/작성 배경 요약}}
|
||||
@@ -25,7 +28,7 @@
|
||||
- {{CLASSIFICATION_REASON_1}}
|
||||
- {{CLASSIFICATION_REASON_2}}
|
||||
|
||||
> **판정이 `완전 중복`인 경우**: 이하 섹션 작성을 중단하고 `# 9. 파일 처리 결과`에 중복 판정 사유와 참조 문서 경로를 기록한 뒤 문서를 닫는다. Planning으로 넘기지 않는다.
|
||||
> **판정이 `완전 중복`인 경우**: 이하 섹션 작성을 중단하고 `# 9. 파일 처리 결과`에 중복 판정 사유와 참조 문서 경로를 기록한 뒤 문서를 닫는다. REQ 초안 작성으로 넘기지 않는다.
|
||||
|
||||
# 3. 문제점의 요약
|
||||
문제의 현재 상태, 기대 상태, 관련 이해관계자, 제약사항을 정리한다. Discovery의 핵심 맥락을 가장 먼저 이해할 수 있어야 한다.
|
||||
@@ -59,10 +62,10 @@
|
||||
- {{CHANGE_ITEM_3:필요 없으면 삭제}}
|
||||
|
||||
## 영향 범위
|
||||
변경이 미칠 코드/문서/운영 범위를 명시해 Planning에서 추정 누락을 줄인다.
|
||||
변경이 미칠 코드/문서/운영 범위를 명시해 REQ 정제와 batch planning에서 추정 누락을 줄인다.
|
||||
|
||||
- 코드 영향:
|
||||
- {{CODE_IMPACT_1:예. docs/sdlc/index.md 갱신 로직}}
|
||||
- {{CODE_IMPACT_1:예. docs/discovery/index.md 갱신 로직}}
|
||||
- {{CODE_IMPACT_2:필요 없으면 삭제}}
|
||||
- 문서 영향:
|
||||
- {{DOC_IMPACT_1}}
|
||||
@@ -116,7 +119,7 @@
|
||||
- A-3: {{ASSUMPTION_3:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 Planning 이전에 확인할 질문으로 남긴다.
|
||||
답을 아직 모르는 항목을 적는다. 추정으로 덮지 말고 REQ 초안 작성 이전에 확인할 질문으로 남긴다.
|
||||
|
||||
- OQ-1: {{OPEN_QUESTION_1}}
|
||||
- 상태: {{OPEN_QUESTION_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
@@ -138,7 +141,7 @@
|
||||
- `Dropped`: 더 이상 유효하지 않은 질문이다. 삭제 사유를 짧게 남기고 목록에서 제거한다.
|
||||
- 처리 원칙 1: 질문만 남기지 말고 반드시 `상태`, `처리 방안`, `종료 조건`을 함께 적는다.
|
||||
- 처리 원칙 2: 답이 나온 질문은 본문 반영 없이 단순 삭제하지 않는다. 반영 위치를 먼저 갱신한다.
|
||||
- 처리 원칙 3: High 영향 질문은 `Deferred` 처리 후 처리 방안에 Planning 인계 추적 방식을 명시한다.
|
||||
- 처리 원칙 3: High 영향 질문은 `Deferred` 처리 후 처리 방안에 REQ 인계 추적 방식을 명시한다.
|
||||
|
||||
# 7. 초기 성공 기준
|
||||
이 변경이 성공했다고 판단할 기준을 측정 가능하게 정의한다. 가능하면 데이터 출처까지 연결한다.
|
||||
@@ -154,8 +157,8 @@
|
||||
- S-2 측정 방식: {{MEASURE_METHOD_2}} / 데이터 출처: {{MEASURE_SOURCE_2}}
|
||||
- S-3 측정 방식: {{MEASURE_METHOD_3:필요 없으면 삭제}} / 데이터 출처: {{MEASURE_SOURCE_3:필요 없으면 삭제}}
|
||||
|
||||
# 8. Planning으로 넘기기 전 확인 체크
|
||||
Planning 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.
|
||||
# 8. REQ로 넘기기 전 확인 체크
|
||||
REQ 초안 작성 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다. 미완료 항목은 후속 결정이 필요함을 뜻한다.
|
||||
|
||||
- [ ] 범위(In Scope/Out of Scope) 확정
|
||||
- 기준: {{CHECK_SCOPE_CRITERIA}}
|
||||
@@ -194,19 +197,19 @@ Planning 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 11. Discovery Freeze
|
||||
Planning 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
REQ 초안 작성 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 범위: [# 5. 요구사항 목록 > 범위 경계](#5-요구사항-목록)
|
||||
- 리스크/오픈 질문: [# 6. 리스크/가정 목록](#6-리스크가정-목록)
|
||||
- 성공 기준: [# 7. 초기 성공 기준](#7-초기-성공-기준)
|
||||
- 인계 전 확인: [# 8. Planning으로 넘기기 전 확인 체크](#8-planning으로-넘기기-전-확인-체크)
|
||||
- 인계 전 확인: [# 8. REQ로 넘기기 전 확인 체크](#8-req로-넘기기-전-확인-체크)
|
||||
- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약)
|
||||
|
||||
## Freeze 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Planning 진행 가능|보류}}
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:REQ Drafting 진행 가능|보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}}
|
||||
- Ready for Planning: {{READY_FOR_PLANNING:false}}
|
||||
- Ready for REQ Drafting: {{READY_FOR_REQ_DRAFTING:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
@@ -216,4 +219,6 @@ Planning 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내
|
||||
- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다.
|
||||
- 필요 없는 항목은 삭제하고, 부족한 항목은 같은 형식으로 추가한다.
|
||||
- Open Questions는 가정으로 대체하지 말고 그대로 유지한다.
|
||||
- Discovery Freeze는 문서 하단에 반드시 유지한다.
|
||||
- `대체됨`은 현재 Discovery가 더 이상 기준 문서가 아닐 때 대체 Discovery 경로를 기록하고, 해당 사항이 없으면 `없음`으로 둔다.
|
||||
- `후속 Discovery 참조`는 범위를 이어받는 별도 Discovery가 생성된 경우 그 Discovery 경로를 기록하고, 없으면 `없음`으로 둔다.
|
||||
- Discovery Freeze는 문서 하단에 반드시 유지한다.
|
||||
@@ -0,0 +1,8 @@
|
||||
# Discovery 전체 인덱스
|
||||
|
||||
<!-- 아래 테이블은 /new-discovery 실행 시 자동 갱신된다. 수동 편집 금지. -->
|
||||
|
||||
## Discovery 목록
|
||||
|
||||
| ID | 날짜 | 이슈명 | 문서 | 상태 |
|
||||
|---|---|---|---|---|
|
||||
@@ -0,0 +1,92 @@
|
||||
# {{PROJECT_NAME}} Interface Contract
|
||||
|
||||
- Baseline Mode: {{BASELINE_MODE:declared|observed|mixed}}
|
||||
- Baseline Seed: {{BASELINE_SEED_PATH:.stagepilot/bootstrap/baseline.yaml}}
|
||||
- Status: draft | confirmed
|
||||
- Owner: {{OWNER_OR_TEAM}}
|
||||
- Last Updated (KST): {{UPDATED_AT_KST}}
|
||||
- Source Discovery / Batch: {{SOURCE_REF}}
|
||||
- Primary Runtime: {{PRIMARY_RUNTIME:cli|api-service|web-app|worker|library|mixed|other}}
|
||||
|
||||
## Project Summary
|
||||
- {{PROJECT_SUMMARY:one-sentence summary of the project}}
|
||||
|
||||
## Primary Domain
|
||||
- {{PRIMARY_DOMAIN:short domain phrase or undecided}}
|
||||
|
||||
## Purpose
|
||||
- This document captures the approved external and cross-boundary interface contracts for the project.
|
||||
- It is a cross-cutting reference for REQ drafting, batch design, implementation, verification, and handoff.
|
||||
|
||||
## Scope
|
||||
- Covers externally visible APIs, CLI surfaces, events, files, or batch I/O contracts.
|
||||
- Does not duplicate full business requirements already owned by REQ documents.
|
||||
- Does not replace low-level code references or generated API artifacts.
|
||||
|
||||
## Interface Summary
|
||||
|
||||
{{INTERFACE_SUMMARY_BULLETS:- - <interface name> :: <purpose>}}
|
||||
|
||||
## Interface: `{{INTERFACE_NAME_1:primary interface name}}`
|
||||
|
||||
- Type: {{INTERFACE_TYPE_1:http-api|cli|event|file|internal-service|other}}
|
||||
- Consumers / Producers: {{INTERFACE_ACTORS_1:who calls or receives it}}
|
||||
- Purpose: {{INTERFACE_PURPOSE_1:what this interface exists to do}}
|
||||
- Stability: {{INTERFACE_STABILITY_1:experimental|internal|stable}}
|
||||
|
||||
### Inputs
|
||||
|
||||
{{INTERFACE_INPUTS_1:- <input field or argument> :: <meaning>}}
|
||||
|
||||
### Outputs
|
||||
|
||||
{{INTERFACE_OUTPUTS_1:- <output field or artifact> :: <meaning>}}
|
||||
|
||||
### Error Contract
|
||||
|
||||
{{INTERFACE_ERRORS_1:- <error code or condition> :: <behavior>}}
|
||||
|
||||
### Compatibility Rules
|
||||
|
||||
{{INTERFACE_COMPATIBILITY_1:- <versioning or compatibility rule>}}
|
||||
|
||||
## Interface: `{{INTERFACE_NAME_2:secondary interface name}}`
|
||||
|
||||
- Type: {{INTERFACE_TYPE_2:http-api|cli|event|file|internal-service|other}}
|
||||
- Consumers / Producers: {{INTERFACE_ACTORS_2:who calls or receives it}}
|
||||
- Purpose: {{INTERFACE_PURPOSE_2:what this interface exists to do}}
|
||||
- Stability: {{INTERFACE_STABILITY_2:experimental|internal|stable}}
|
||||
|
||||
### Inputs
|
||||
|
||||
{{INTERFACE_INPUTS_2:- <input field or argument> :: <meaning>}}
|
||||
|
||||
### Outputs
|
||||
|
||||
{{INTERFACE_OUTPUTS_2:- <output field or artifact> :: <meaning>}}
|
||||
|
||||
### Error Contract
|
||||
|
||||
{{INTERFACE_ERRORS_2:- <error code or condition> :: <behavior>}}
|
||||
|
||||
### Compatibility Rules
|
||||
|
||||
{{INTERFACE_COMPATIBILITY_2:- <versioning or compatibility rule>}}
|
||||
|
||||
## Shared Constraints
|
||||
|
||||
{{INTERFACE_SHARED_CONSTRAINTS_BULLETS:- - <authentication, timeout, idempotency, or size constraint>}}
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
{{INTERFACE_CURRENT_GAPS_BULLETS:- - <known contract gap or planned interface change>}}
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when an externally visible API, event, CLI, or file contract changes.
|
||||
- Update this document when a batch changes compatibility, validation, or error behavior.
|
||||
- Update this document when a new external consumer or producer is introduced.
|
||||
|
||||
## Change Log
|
||||
|
||||
{{CHANGE_LOG_BULLETS:- - <change log entry>}}
|
||||
@@ -0,0 +1,64 @@
|
||||
# {{PROJECT_NAME}} Project Structure
|
||||
|
||||
- Baseline Mode: {{BASELINE_MODE:declared|observed|mixed}}
|
||||
- Baseline Seed: {{BASELINE_SEED_PATH:.stagepilot/bootstrap/baseline.yaml}}
|
||||
- Status: draft | confirmed
|
||||
- Owner: {{OWNER_OR_TEAM}}
|
||||
- Last Updated (KST): {{UPDATED_AT_KST}}
|
||||
- Source Discovery / Batch: {{SOURCE_REF}}
|
||||
|
||||
## Project Summary
|
||||
- {{PROJECT_SUMMARY:one-sentence summary of the project}}
|
||||
|
||||
## Primary Domain
|
||||
- {{PRIMARY_DOMAIN:short domain phrase or undecided}}
|
||||
|
||||
## Tech Stack
|
||||
{{TECH_STACK_BULLETS:- <planned stack item 1>
|
||||
- <planned stack item 2>}}
|
||||
|
||||
## Primary Runtime
|
||||
- Type: {{PRIMARY_RUNTIME:cli|api-service|web-app|worker|library|mixed|other}}
|
||||
- Planned Entry Points:
|
||||
{{PRIMARY_ENTRYPOINT_BULLETS:- <entrypoint> :: <purpose>}}
|
||||
|
||||
## Purpose
|
||||
- This document is the current approved repository and package structure baseline.
|
||||
- It is a cross-cutting reference document for Discovery, REQ, Batch Design, Batch Verification, and implementation updates.
|
||||
|
||||
## Scope
|
||||
- Covers the top-level repository layout and package/module boundaries.
|
||||
- Does not duplicate detailed business rules, acceptance criteria, or implementation-only function signatures.
|
||||
|
||||
## Top-Level Structure
|
||||
|
||||
```text
|
||||
{{TOP_LEVEL_STRUCTURE_TREE:<text tree baseline>}}
|
||||
```
|
||||
|
||||
## Package / Module Responsibilities
|
||||
|
||||
{{MODULE_RESPONSIBILITY_BULLETS:- `<path-or-package-1>`
|
||||
- <responsibility summary>}}
|
||||
|
||||
## Dependency Rules
|
||||
|
||||
{{DEPENDENCY_RULE_BULLETS:- <dependency rule 1>}}
|
||||
|
||||
## Shared Boundaries
|
||||
|
||||
{{SHARED_BOUNDARY_BULLETS:- <shared boundary 1>}}
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
{{CURRENT_GAPS_BULLETS:- <gap or planned structural change 1>}}
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when package boundaries change.
|
||||
- Update this document when new top-level runtime or domain modules are added.
|
||||
- Update this document when a batch changes the approved structure baseline.
|
||||
|
||||
## Change Log
|
||||
|
||||
{{CHANGE_LOG_BULLETS:- - <change log entry>}}
|
||||
@@ -0,0 +1,10 @@
|
||||
# Release Index
|
||||
|
||||
## 목적
|
||||
- 이 문서는 release 단위의 전역 인덱스다.
|
||||
- 각 release는 하나 이상의 release-candidate batch를 묶고, profile(`docs-only` | `tooling` | `app-service`)에 맞는 배포와 후속 환류를 추적한다.
|
||||
|
||||
## Release Register
|
||||
|
||||
| REL ID | Profile | Status | Included Batch | Discovery/REQ Input | Link |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
@@ -0,0 +1,92 @@
|
||||
# {{REL_ID}}: <릴리즈 제목>
|
||||
|
||||
- Status: draft | confirmed | released | feedback-captured
|
||||
- Profile: docs-only | tooling | app-service
|
||||
- Included Batch: <BAT-ID 목록>
|
||||
|
||||
## Scope
|
||||
- Included:
|
||||
- <포함 batch 또는 REQ>
|
||||
- Excluded:
|
||||
- <제외 범위>
|
||||
|
||||
## Rollout Plan
|
||||
1. <배포 순서>
|
||||
2. <배포 순서>
|
||||
|
||||
## Rollback Plan
|
||||
- <롤백 조건과 절차>
|
||||
|
||||
## Verification Checklist
|
||||
- <배포 전 확인>
|
||||
- <배포 후 확인>
|
||||
|
||||
## Release Execution Evidence
|
||||
- Release Status Transition Target: released
|
||||
|
||||
### Deployment Facts
|
||||
- Executed At:
|
||||
- <배포 시작 시각>
|
||||
- Completed At:
|
||||
- <배포 완료 시각>
|
||||
- Environment:
|
||||
- <배포 대상 환경>
|
||||
- Operator:
|
||||
- <배포 수행자>
|
||||
- Revision or Artifact:
|
||||
- <커밋 SHA 또는 배포 artifact 식별자>
|
||||
- Commands or Procedure:
|
||||
- <실행 명령 또는 배포 절차 요약>
|
||||
|
||||
### Profile-Specific Checks
|
||||
- docs-only:
|
||||
- Published or Packaged Targets:
|
||||
- <문서 경로, 배포 산출물 또는 none>
|
||||
- Link or Rendering Check:
|
||||
- <링크 점검, 렌더링 확인 또는 none>
|
||||
- Navigation or Consumer Update:
|
||||
- <목차/가이드/릴리즈 노트 반영 결과 또는 none>
|
||||
- tooling:
|
||||
- Install or Upgrade Smoke:
|
||||
- <설치/업데이트/부트스트랩 결과 또는 none>
|
||||
- CLI or Script Execution:
|
||||
- <명령 실행 결과 또는 none>
|
||||
- Compatibility Note:
|
||||
- <하위 호환성/운영자 영향 또는 none>
|
||||
- app-service:
|
||||
- Health Endpoint:
|
||||
- <호출 결과와 확인 시각>
|
||||
- Startup Log Fields:
|
||||
- <app, event, command, run_id 확인 결과>
|
||||
- Request Log Fields:
|
||||
- <request_id 포함 여부와 확인 결과>
|
||||
- Smoke or Manual Verification:
|
||||
- <배포 후 재실행한 검증과 결과>
|
||||
|
||||
### Rollback Outcome
|
||||
- Rollback Required:
|
||||
- <yes 또는 no>
|
||||
- Rollback Trigger:
|
||||
- <발생 시 원인, 없으면 none>
|
||||
- Rollback Action:
|
||||
- <수행한 조치, 없으면 none>
|
||||
|
||||
### Release Decision Evidence
|
||||
- Released Decision:
|
||||
- <released 전환 여부>
|
||||
- Rationale:
|
||||
- <released 전환 판단 근거>
|
||||
- Recorded By:
|
||||
- <기록자>
|
||||
- Recorded At:
|
||||
- <기록 시각>
|
||||
|
||||
## Feedback Handoff
|
||||
- Observation Summary:
|
||||
- <운영 관찰 사실 요약 또는 없음>
|
||||
- Discovery Input:
|
||||
- <후속 discovery 후보>
|
||||
- REQ Input:
|
||||
- <후속 req 후보>
|
||||
- Change Request Input:
|
||||
- <기존 req 변경 후보>
|
||||
@@ -0,0 +1,58 @@
|
||||
# {{PROJECT_NAME}} Runtime Flows
|
||||
|
||||
- Baseline Mode: {{BASELINE_MODE:declared|observed|mixed}}
|
||||
- Baseline Seed: {{BASELINE_SEED_PATH:.stagepilot/bootstrap/baseline.yaml}}
|
||||
- Status: draft | confirmed
|
||||
- Owner: {{OWNER_OR_TEAM}}
|
||||
- Last Updated (KST): {{UPDATED_AT_KST}}
|
||||
- Source Discovery / Batch: {{SOURCE_REF}}
|
||||
- Primary Runtime: {{PRIMARY_RUNTIME:cli|api-service|web-app|worker|library|mixed|other}}
|
||||
|
||||
## Project Summary
|
||||
- {{PROJECT_SUMMARY:one-sentence summary of the project}}
|
||||
|
||||
## Purpose
|
||||
- This document is the current approved execution-flow baseline for the project.
|
||||
- It is a cross-cutting reference document for Discovery, REQ, Batch Design, Batch Verification, and implementation updates.
|
||||
|
||||
## Scope
|
||||
- Covers representative command and runtime flows.
|
||||
- Does not duplicate full acceptance criteria or low-level implementation details.
|
||||
|
||||
## Covered Entry Points
|
||||
|
||||
{{PRIMARY_ENTRYPOINT_BULLETS:- <entry-point-1> :: <purpose>}}
|
||||
|
||||
## Shared Components
|
||||
|
||||
{{SHARED_COMPONENT_BULLETS:- <shared component or service 1>}}
|
||||
|
||||
## Flow: `{{FLOW_NAME_1:bootstrap or first runtime flow}}`
|
||||
|
||||
{{FLOW_STEPS_1:1. <step 1>
|
||||
2. <step 2>
|
||||
3. <step 3>}}
|
||||
|
||||
## Flow: `{{FLOW_NAME_2:secondary runtime flow or operation}}`
|
||||
|
||||
{{FLOW_STEPS_2:1. <step 1>
|
||||
2. <step 2>
|
||||
3. <step 3>}}
|
||||
|
||||
## Flow Constraints
|
||||
|
||||
{{FLOW_CONSTRAINT_BULLETS:- <flow constraint 1>}}
|
||||
|
||||
## Current Gaps / Planned Changes
|
||||
|
||||
{{CURRENT_GAPS_BULLETS:- <gap or planned flow change 1>}}
|
||||
|
||||
## Update Triggers
|
||||
|
||||
- Update this document when a command entry point changes.
|
||||
- Update this document when a runtime orchestration path changes.
|
||||
- Update this document when a batch changes the approved flow baseline.
|
||||
|
||||
## Change Log
|
||||
|
||||
{{CHANGE_LOG_BULLETS:- - <change log entry>}}
|
||||
@@ -1,205 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Discovery: {{DISCOVERY_PATH:docs/sdlc/<CYCLE_ID>/1_discovery.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Discovery 인계 요약
|
||||
Discovery에서 확정된 핵심 내용을 요약한다. 원본은 1_discovery.md를 참조하며, 이 섹션은 Planning 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{PLANNING_ISSUE_PURPOSE:Discovery 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 확정 범위
|
||||
- In Scope
|
||||
- {{PLANNING_IN_SCOPE_1}}
|
||||
- {{PLANNING_IN_SCOPE_2}}
|
||||
- Out of Scope
|
||||
- {{PLANNING_OUT_OF_SCOPE_1}}
|
||||
- {{PLANNING_OUT_OF_SCOPE_2}}
|
||||
|
||||
## 기능 요구사항 (FR) 요약
|
||||
- FR-1: {{PLANNING_FR_1}}
|
||||
- FR-2: {{PLANNING_FR_2}}
|
||||
- FR-3: {{PLANNING_FR_3:필요 없으면 삭제}}
|
||||
- FR-4: {{PLANNING_FR_4:필요 없으면 삭제}}
|
||||
|
||||
## 비기능 요구사항 (NFR) 요약
|
||||
- NFR-1: {{PLANNING_NFR_1}}
|
||||
- NFR-2: {{PLANNING_NFR_2:필요 없으면 삭제}}
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Discovery에서 `Deferred` 처리되어 Planning 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 작업 분해 (Task Breakdown)
|
||||
FR/NFR 각각을 실행 가능한 단위 태스크로 분해한다. 각 태스크는 하나의 완료 조건을 가져야 한다.
|
||||
|
||||
| ID | 태스크 제목 | 유형 | 참조 요구사항 | 의존 태스크 | 담당자 |
|
||||
|-----|-----------|------|--------------|------------|--------|
|
||||
| T-1 | {{TASK_TITLE_1}} | {{TASK_TYPE_1:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_1:FR-1}} | - | {{TASK_OWNER_1:TBD}} |
|
||||
| T-2 | {{TASK_TITLE_2}} | {{TASK_TYPE_2:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_2:FR-2}} | {{TASK_DEP_2:-}} | {{TASK_OWNER_2:TBD}} |
|
||||
| T-3 | {{TASK_TITLE_3:필요 없으면 삭제}} | {{TASK_TYPE_3:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_3}} | {{TASK_DEP_3:-}} | {{TASK_OWNER_3:TBD}} |
|
||||
| T-4 | {{TASK_TITLE_4:필요 없으면 삭제}} | {{TASK_TYPE_4:개발\|문서\|검토\|설계\|운영}} | {{TASK_REF_4}} | {{TASK_DEP_4:-}} | {{TASK_OWNER_4:TBD}} |
|
||||
|
||||
## 태스크 완료 조건 (DoD)
|
||||
각 태스크의 완료 기준을 명시한다.
|
||||
|
||||
- T-1: {{TASK_DOD_1}}
|
||||
- T-2: {{TASK_DOD_2}}
|
||||
- T-3: {{TASK_DOD_3:필요 없으면 삭제}}
|
||||
- T-4: {{TASK_DOD_4:필요 없으면 삭제}}
|
||||
|
||||
# 3. 공수 추정
|
||||
각 태스크의 예상 공수를 적는다. 단위는 팀 기준에 맞게 선택한다(SP 또는 시간).
|
||||
|
||||
| ID | 태스크 제목 | 추정 공수 | 추정 단위 | 비고 |
|
||||
|-----|-----------|---------|---------|------|
|
||||
| T-1 | {{TASK_TITLE_1}} | {{EFFORT_1}} | {{EFFORT_UNIT:SP\|시간\|일}} | {{EFFORT_NOTE_1:필요 없으면 삭제}} |
|
||||
| T-2 | {{TASK_TITLE_2}} | {{EFFORT_2}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_2:필요 없으면 삭제}} |
|
||||
| T-3 | {{TASK_TITLE_3:필요 없으면 삭제}} | {{EFFORT_3}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_3:필요 없으면 삭제}} |
|
||||
| T-4 | {{TASK_TITLE_4:필요 없으면 삭제}} | {{EFFORT_4}} | {{EFFORT_UNIT}} | {{EFFORT_NOTE_4:필요 없으면 삭제}} |
|
||||
|
||||
- 총 추정 공수: {{TOTAL_EFFORT}}
|
||||
- 추정 신뢰도: {{EFFORT_CONFIDENCE:High|Medium|Low}}
|
||||
- 추정 근거: {{EFFORT_BASIS:추정에 사용한 방법 또는 유사 사례}}
|
||||
|
||||
# 4. 일정 계획
|
||||
이터레이션 또는 스프린트 단위로 태스크 배분 계획을 적는다.
|
||||
|
||||
## 마일스톤
|
||||
| 마일스톤 | 목표 날짜 | 포함 태스크 | 완료 조건 |
|
||||
|---------|---------|-----------|---------|
|
||||
| M-1: {{MILESTONE_1_NAME}} | {{MILESTONE_1_DATE:TBD}} | {{MILESTONE_1_TASKS:T-1, T-2}} | {{MILESTONE_1_DONE}} |
|
||||
| M-2: {{MILESTONE_2_NAME:필요 없으면 삭제}} | {{MILESTONE_2_DATE:TBD}} | {{MILESTONE_2_TASKS}} | {{MILESTONE_2_DONE}} |
|
||||
|
||||
## 이터레이션 계획
|
||||
- 이터레이션 단위: {{ITERATION_UNIT:스프린트|주|없음(단일 배포)}}
|
||||
- 이터레이션 1 ({{ITERATION_1_PERIOD:날짜 범위 또는 TBD}}): {{ITERATION_1_TASKS:T-1, T-2}}
|
||||
- 이터레이션 2 ({{ITERATION_2_PERIOD:날짜 범위 또는 TBD}}): {{ITERATION_2_TASKS:T-3, T-4}}
|
||||
|
||||
# 5. 의존성 및 제약
|
||||
태스크 간 의존 관계와 외부 의존성을 기록한다.
|
||||
|
||||
## 태스크 간 의존성
|
||||
- {{TASK_DEPENDENCY_1:예. T-2는 T-1 완료 후 시작 가능}}
|
||||
- {{TASK_DEPENDENCY_2:필요 없으면 삭제}}
|
||||
|
||||
## 외부 의존성
|
||||
다른 팀, 시스템, 도구에 의존하는 항목을 적는다.
|
||||
|
||||
- {{EXTERNAL_DEP_1:예. CI/CD 파이프라인 설정 필요}}
|
||||
- {{EXTERNAL_DEP_2:필요 없으면 삭제}}
|
||||
|
||||
## 기술/환경 제약
|
||||
- {{TECH_CONSTRAINT_1}}
|
||||
- {{TECH_CONSTRAINT_2:필요 없으면 삭제}}
|
||||
|
||||
# 6. 검증 계획 개요
|
||||
Discovery의 성공 기준과 연결해 어떻게 검증할지 초안을 적는다. 상세 검증은 Verification 단계에서 정의한다.
|
||||
|
||||
| 성공 기준 | 검증 방법 초안 | 담당자 |
|
||||
|---------|-------------|--------|
|
||||
| {{VERIFY_CRITERIA_1:S-1 요약}} | {{VERIFY_METHOD_1}} | {{VERIFY_OWNER_1:TBD}} |
|
||||
| {{VERIFY_CRITERIA_2:S-2 요약}} | {{VERIFY_METHOD_2}} | {{VERIFY_OWNER_2:TBD}} |
|
||||
| {{VERIFY_CRITERIA_3:S-3 요약 또는 삭제}} | {{VERIFY_METHOD_3}} | {{VERIFY_OWNER_3:TBD}} |
|
||||
|
||||
# 7. 리스크
|
||||
Planning 단계에서 새로 식별된 리스크를 기록한다. Discovery에서 이월된 리스크는 `# 1` 이월 항목에서 확인한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{PLAN_RISK_LEVEL_1:High|Medium|Low}}): {{PLAN_RISK_1}}
|
||||
- 완화 방안: {{PLAN_MITIGATION_1}}
|
||||
- R-2 ({{PLAN_RISK_LEVEL_2:High|Medium|Low}}): {{PLAN_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{PLAN_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 가정
|
||||
Planning 수행의 전제가 되는 가정을 적는다.
|
||||
|
||||
- PA-1: {{PLAN_ASSUMPTION_1}}
|
||||
- PA-2: {{PLAN_ASSUMPTION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
Planning 진행 중 확인이 필요한 질문을 적는다.
|
||||
|
||||
- OQ-1: {{PLAN_OPEN_QUESTION_1}}
|
||||
- 상태: {{PLAN_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{PLAN_OQ_ACTION_1}}
|
||||
- 종료 조건: {{PLAN_OQ_EXIT_1}}
|
||||
- OQ-2: {{PLAN_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{PLAN_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{PLAN_OQ_ACTION_2}}
|
||||
- 종료 조건: {{PLAN_OQ_EXIT_2}}
|
||||
|
||||
# 8. Design으로 넘기기 전 확인 체크
|
||||
Design 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다.
|
||||
|
||||
- [ ] 전체 태스크 목록 확정 및 담당자 지정
|
||||
- 기준: {{CHECK_TASKS_CRITERIA:모든 태스크에 담당자가 지정되어야 한다}}
|
||||
- [ ] 공수 추정 완료 및 총 공수 확인
|
||||
- 기준: {{CHECK_EFFORT_CRITERIA:모든 태스크의 추정 공수가 채워져야 한다}}
|
||||
- [ ] 마일스톤 및 이터레이션 계획 확정
|
||||
- 기준: {{CHECK_SCHEDULE_CRITERIA:M-1 이상의 마일스톤과 이터레이션 경계가 정의되어야 한다}}
|
||||
- [ ] 외부 의존성 해소 계획 확인
|
||||
- 기준: {{CHECK_DEP_CRITERIA:외부 의존성 각 항목에 담당자 또는 해소 방안이 있어야 한다}}
|
||||
- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}}
|
||||
|
||||
# 9. 파일 처리 결과
|
||||
이 Planning 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{DISCOVERY_PATH:docs/sdlc/<CYCLE_ID>/1_discovery.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 10. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 11. Planning Freeze
|
||||
Design 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 작업 분해: [# 2. 작업 분해](#2-작업-분해-task-breakdown)
|
||||
- 공수/일정: [# 3. 공수 추정](#3-공수-추정), [# 4. 일정 계획](#4-일정-계획)
|
||||
- 의존성: [# 5. 의존성 및 제약](#5-의존성-및-제약)
|
||||
- 검증 계획: [# 6. 검증 계획 개요](#6-검증-계획-개요)
|
||||
- 리스크/오픈 질문: [# 7. 리스크](#7-리스크)
|
||||
- 인계 전 확인: [# 8. Design으로 넘기기 전 확인 체크](#8-design으로-넘기기-전-확인-체크)
|
||||
- 사용자 결정 필요: [# 10. 사용자 결정 필요 항목 요약](#10-사용자-결정-필요-항목-요약)
|
||||
|
||||
## Freeze 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Design 진행 가능|보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}}
|
||||
- Ready for Design: {{READY_FOR_DESIGN:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
# 12. 작성 가이드
|
||||
템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다.
|
||||
|
||||
- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다.
|
||||
- 필요 없는 태스크/마일스톤 행은 삭제하고, 부족한 항목은 같은 형식으로 추가한다.
|
||||
- 공수 추정은 팀 기준 단위(SP/시간/일)를 통일해서 사용한다.
|
||||
- Planning Freeze는 문서 하단에 반드시 유지한다.
|
||||
@@ -1,187 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Planning: {{PLANNING_PATH:docs/sdlc/<CYCLE_ID>/2_planning.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Planning 인계 요약
|
||||
Planning에서 확정된 핵심 내용을 요약한다. 원본은 2_planning.md를 참조하며, 이 섹션은 Design 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{DESIGN_ISSUE_PURPOSE:Planning 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 확정 태스크 목록
|
||||
| ID | 태스크 제목 | 참조 요구사항 | 담당자 |
|
||||
|----|-----------|------------|--------|
|
||||
| T-1 | {{DESIGN_TASK_TITLE_1}} | {{DESIGN_TASK_REF_1}} | {{DESIGN_TASK_OWNER_1:TBD}} |
|
||||
| T-2 | {{DESIGN_TASK_TITLE_2}} | {{DESIGN_TASK_REF_2}} | {{DESIGN_TASK_OWNER_2:TBD}} |
|
||||
| T-3 | {{DESIGN_TASK_TITLE_3:필요 없으면 삭제}} | {{DESIGN_TASK_REF_3}} | {{DESIGN_TASK_OWNER_3:TBD}} |
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Planning에서 `Deferred` 처리되어 Design 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{DESIGN_DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{DESIGN_DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 아키텍처 및 구조 설계
|
||||
변경이 미치는 전체 구조와 주요 컴포넌트 관계를 설명한다.
|
||||
|
||||
## 전체 구조 개요
|
||||
{{ARCH_OVERVIEW:시스템/모듈/파일 구조를 개요 수준으로 설명. 다이어그램 또는 목록 형태 모두 가능}}
|
||||
|
||||
## 주요 컴포넌트
|
||||
| 컴포넌트 | 역할 | 영향 범위 |
|
||||
|---------|------|---------|
|
||||
| {{COMPONENT_1_NAME}} | {{COMPONENT_1_ROLE}} | {{COMPONENT_1_SCOPE}} |
|
||||
| {{COMPONENT_2_NAME}} | {{COMPONENT_2_ROLE}} | {{COMPONENT_2_SCOPE}} |
|
||||
| {{COMPONENT_3_NAME:필요 없으면 삭제}} | {{COMPONENT_3_ROLE}} | {{COMPONENT_3_SCOPE}} |
|
||||
|
||||
## 데이터 흐름
|
||||
변경과 관련된 주요 데이터 흐름 또는 처리 순서를 적는다. 복잡하면 단계별 목록으로 표현한다.
|
||||
|
||||
- {{DATA_FLOW_1}}
|
||||
- {{DATA_FLOW_2}}
|
||||
- {{DATA_FLOW_3:필요 없으면 삭제}}
|
||||
|
||||
# 3. 상세 설계
|
||||
태스크(T-N)별로 구체적인 구현/변경 방법을 기술한다.
|
||||
|
||||
## T-1: {{DESIGN_TASK_TITLE_1}}
|
||||
- 설계 방향: {{DESIGN_DETAIL_1}}
|
||||
- 변경 대상: {{DESIGN_TARGET_1:파일 경로, 함수명, 설정 키 등}}
|
||||
- 입력/출력: {{DESIGN_IO_1:입력값과 출력값 또는 사이드이펙트}}
|
||||
- 예외/엣지 케이스: {{DESIGN_EDGE_1:필요 없으면 삭제}}
|
||||
|
||||
## T-2: {{DESIGN_TASK_TITLE_2}}
|
||||
- 설계 방향: {{DESIGN_DETAIL_2}}
|
||||
- 변경 대상: {{DESIGN_TARGET_2}}
|
||||
- 입력/출력: {{DESIGN_IO_2}}
|
||||
- 예외/엣지 케이스: {{DESIGN_EDGE_2:필요 없으면 삭제}}
|
||||
|
||||
## T-3: {{DESIGN_TASK_TITLE_3:필요 없으면 삭제}}
|
||||
- 설계 방향: {{DESIGN_DETAIL_3}}
|
||||
- 변경 대상: {{DESIGN_TARGET_3}}
|
||||
- 입력/출력: {{DESIGN_IO_3}}
|
||||
- 예외/엣지 케이스: {{DESIGN_EDGE_3:필요 없으면 삭제}}
|
||||
|
||||
# 4. 인터페이스 정의
|
||||
외부 시스템, 모듈 간 계약(API, 이벤트, 파일 포맷 등)을 명시한다. 해당 없으면 "해당 없음"으로 기재한다.
|
||||
|
||||
## API / 함수 시그니처
|
||||
- {{INTERFACE_1:예. function foo(bar: string): boolean — 설명}}
|
||||
- {{INTERFACE_2:필요 없으면 삭제}}
|
||||
|
||||
## 데이터 스키마 / 포맷
|
||||
- {{SCHEMA_1:예. { id: string, status: "draft"|"confirmed" } — 설명}}
|
||||
- {{SCHEMA_2:필요 없으면 삭제}}
|
||||
|
||||
## 이벤트 / 메시지
|
||||
- {{EVENT_1:필요 없으면 삭제}}
|
||||
- {{EVENT_2:필요 없으면 삭제}}
|
||||
|
||||
# 5. 보안 고려사항
|
||||
OWASP Top 10 기준으로 이번 변경에서 주의해야 할 보안 항목을 점검한다.
|
||||
|
||||
| 항목 | 해당 여부 | 대응 방안 |
|
||||
|------|---------|---------|
|
||||
| 입력값 검증 (Injection) | {{SEC_INJECTION:해당|비해당}} | {{SEC_INJECTION_ACTION:비해당이면 삭제}} |
|
||||
| 인증/인가 | {{SEC_AUTH:해당|비해당}} | {{SEC_AUTH_ACTION:비해당이면 삭제}} |
|
||||
| 민감 데이터 노출 | {{SEC_DATA:해당|비해당}} | {{SEC_DATA_ACTION:비해당이면 삭제}} |
|
||||
| 의존성 취약점 | {{SEC_DEP:해당|비해당}} | {{SEC_DEP_ACTION:비해당이면 삭제}} |
|
||||
| 기타 | {{SEC_OTHER:필요 없으면 삭제}} | {{SEC_OTHER_ACTION:필요 없으면 삭제}} |
|
||||
|
||||
# 6. 리스크
|
||||
Design 단계에서 새로 식별된 리스크를 기록한다. Planning에서 이월된 리스크는 `# 1` 이월 항목에서 확인한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{DESIGN_RISK_LEVEL_1:High|Medium|Low}}): {{DESIGN_RISK_1}}
|
||||
- 완화 방안: {{DESIGN_MITIGATION_1}}
|
||||
- R-2 ({{DESIGN_RISK_LEVEL_2:High|Medium|Low}}): {{DESIGN_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{DESIGN_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 가정
|
||||
Design 수행의 전제가 되는 가정을 적는다.
|
||||
|
||||
- DA-1: {{DESIGN_ASSUMPTION_1}}
|
||||
- DA-2: {{DESIGN_ASSUMPTION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
Design 진행 중 확인이 필요한 질문을 적는다.
|
||||
|
||||
- OQ-1: {{DESIGN_OPEN_QUESTION_1}}
|
||||
- 상태: {{DESIGN_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{DESIGN_OQ_ACTION_1}}
|
||||
- 종료 조건: {{DESIGN_OQ_EXIT_1}}
|
||||
- OQ-2: {{DESIGN_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{DESIGN_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{DESIGN_OQ_ACTION_2}}
|
||||
- 종료 조건: {{DESIGN_OQ_EXIT_2}}
|
||||
|
||||
# 7. Implementation으로 넘기기 전 확인 체크
|
||||
Implementation 단계로 넘기기 전에 무엇이 확정되어야 하는지 확인한다.
|
||||
|
||||
- [ ] 전체 컴포넌트 및 태스크별 설계 완성
|
||||
- 기준: {{CHECK_DESIGN_COMPLETE:모든 T-N 태스크에 설계 방향과 변경 대상이 채워져야 한다}}
|
||||
- [ ] 인터페이스 계약 확정
|
||||
- 기준: {{CHECK_INTERFACE:외부 의존 컴포넌트와의 계약이 명시되어야 한다}}
|
||||
- [ ] 보안 점검 완료
|
||||
- 기준: {{CHECK_SECURITY:OWASP 점검 항목 중 해당 항목은 대응 방안이 있어야 한다}}
|
||||
- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}}
|
||||
|
||||
# 8. 파일 처리 결과
|
||||
이 Design 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{PLANNING_PATH:docs/sdlc/<CYCLE_ID>/2_planning.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 9. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 10. Design Freeze
|
||||
Implementation 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 아키텍처/구조: [# 2. 아키텍처 및 구조 설계](#2-아키텍처-및-구조-설계)
|
||||
- 상세 설계: [# 3. 상세 설계](#3-상세-설계)
|
||||
- 인터페이스: [# 4. 인터페이스 정의](#4-인터페이스-정의)
|
||||
- 보안: [# 5. 보안 고려사항](#5-보안-고려사항)
|
||||
- 리스크/오픈 질문: [# 6. 리스크](#6-리스크)
|
||||
- 인계 전 확인: [# 7. Implementation으로 넘기기 전 확인 체크](#7-implementation으로-넘기기-전-확인-체크)
|
||||
- 사용자 결정 필요: [# 9. 사용자 결정 필요 항목 요약](#9-사용자-결정-필요-항목-요약)
|
||||
|
||||
## Freeze 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:Implementation 진행 가능|보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:진행 가능 또는 보류 판단 근거 1-2줄}}
|
||||
- Ready for Implementation: {{READY_FOR_IMPLEMENTATION:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
# 11. 작성 가이드
|
||||
템플릿 사용 시의 기본 규칙을 적는다. 실제 문서를 만들 때는 이 가이드를 기준으로 플레이스홀더를 치환한다.
|
||||
|
||||
- 이 파일은 템플릿이다. 실제 문서 작성 시 `{{...}}` 플레이스홀더를 구체 값으로 교체한다.
|
||||
- 필요 없는 컴포넌트/태스크 항목은 삭제하고, 부족한 항목은 같은 형식으로 추가한다.
|
||||
- 보안 고려사항은 "비해당"이라도 근거를 남긴다.
|
||||
- Design Freeze는 문서 하단에 반드시 유지한다.
|
||||
@@ -1,155 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Design: {{DESIGN_PATH:docs/sdlc/<CYCLE_ID>/3_design.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Design 인계 요약
|
||||
Design에서 확정된 핵심 내용을 요약한다. 원본은 3_design.md를 참조하며, 이 섹션은 Implementation 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{IMP_ISSUE_PURPOSE:Design 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 확정 태스크 및 변경 대상
|
||||
| ID | 태스크 제목 | 변경 대상 파일/함수 | 담당자 |
|
||||
|----|-----------|-------------------|--------|
|
||||
| T-1 | {{IMP_TASK_TITLE_1}} | {{IMP_TASK_TARGET_1}} | {{IMP_TASK_OWNER_1:TBD}} |
|
||||
| T-2 | {{IMP_TASK_TITLE_2}} | {{IMP_TASK_TARGET_2}} | {{IMP_TASK_OWNER_2:TBD}} |
|
||||
| T-3 | {{IMP_TASK_TITLE_3:필요 없으면 삭제}} | {{IMP_TASK_TARGET_3}} | {{IMP_TASK_OWNER_3:TBD}} |
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Design에서 `Deferred` 처리되어 Implementation 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{IMP_DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{IMP_DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 구현 계획
|
||||
태스크(T-N)별 구현 순서와 접근 방법을 기술한다.
|
||||
|
||||
## 구현 순서
|
||||
태스크 간 의존 관계와 우선순위를 고려한 구현 순서를 정의한다.
|
||||
|
||||
1. {{IMP_ORDER_1:예. T-1 — 기반 구조 구현 (다른 태스크의 의존 대상)}}
|
||||
2. {{IMP_ORDER_2:예. T-2 — 핵심 기능 구현}}
|
||||
3. {{IMP_ORDER_3:필요 없으면 삭제}}
|
||||
|
||||
## T-1: {{IMP_TASK_TITLE_1}}
|
||||
- 구현 방법: {{IMP_METHOD_1:설계 방향을 실제 코드/설정으로 구현하는 접근}}
|
||||
- 변경 대상: {{IMP_TARGET_1:실제 파일 경로, 함수명, 설정 키}}
|
||||
- 완료 조건: {{IMP_DOD_1:이 태스크가 완료된 것으로 간주하는 기준}}
|
||||
- 주의사항: {{IMP_NOTE_1:구현 중 주의해야 할 사항. 필요 없으면 삭제}}
|
||||
|
||||
## T-2: {{IMP_TASK_TITLE_2}}
|
||||
- 구현 방법: {{IMP_METHOD_2}}
|
||||
- 변경 대상: {{IMP_TARGET_2}}
|
||||
- 완료 조건: {{IMP_DOD_2}}
|
||||
- 주의사항: {{IMP_NOTE_2:필요 없으면 삭제}}
|
||||
|
||||
## T-3: {{IMP_TASK_TITLE_3:필요 없으면 삭제}}
|
||||
- 구현 방법: {{IMP_METHOD_3}}
|
||||
- 변경 대상: {{IMP_TARGET_3}}
|
||||
- 완료 조건: {{IMP_DOD_3}}
|
||||
- 주의사항: {{IMP_NOTE_3:필요 없으면 삭제}}
|
||||
|
||||
# 3. 변경 파일 목록
|
||||
이번 Implementation에서 생성/수정/삭제되는 파일을 미리 나열한다. 구현 완료 후 실제 결과를 반영해 갱신한다.
|
||||
|
||||
| 파일 경로 | 변경 유형 | 관련 태스크 | 비고 |
|
||||
|---------|---------|-----------|------|
|
||||
| {{IMP_FILE_1}} | {{IMP_FILE_TYPE_1:생성\|수정\|삭제}} | {{IMP_FILE_TASK_1:T-1}} | {{IMP_FILE_NOTE_1:필요 없으면 삭제}} |
|
||||
| {{IMP_FILE_2}} | {{IMP_FILE_TYPE_2:생성\|수정\|삭제}} | {{IMP_FILE_TASK_2}} | {{IMP_FILE_NOTE_2:필요 없으면 삭제}} |
|
||||
| {{IMP_FILE_3:필요 없으면 삭제}} | {{IMP_FILE_TYPE_3:생성\|수정\|삭제}} | {{IMP_FILE_TASK_3}} | {{IMP_FILE_NOTE_3:필요 없으면 삭제}} |
|
||||
|
||||
# 4. 리스크 및 제약
|
||||
Implementation 단계에서 새로 식별된 리스크와 제약사항을 기록한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{IMP_RISK_LEVEL_1:High|Medium|Low}}): {{IMP_RISK_1}}
|
||||
- 완화 방안: {{IMP_MITIGATION_1}}
|
||||
- R-2 ({{IMP_RISK_LEVEL_2:High|Medium|Low}}): {{IMP_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{IMP_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 가정
|
||||
Implementation 수행의 전제가 되는 가정을 적는다.
|
||||
|
||||
- IA-1: {{IMP_ASSUMPTION_1}}
|
||||
- IA-2: {{IMP_ASSUMPTION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
Implementation 진행 중 확인이 필요한 질문을 적는다.
|
||||
|
||||
- OQ-1: {{IMP_OPEN_QUESTION_1}}
|
||||
- 상태: {{IMP_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{IMP_OQ_ACTION_1}}
|
||||
- 종료 조건: {{IMP_OQ_EXIT_1}}
|
||||
- OQ-2: {{IMP_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{IMP_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{IMP_OQ_ACTION_2}}
|
||||
- 종료 조건: {{IMP_OQ_EXIT_2}}
|
||||
|
||||
# 5. Verification으로 넘기기 전 확인 체크
|
||||
Verification 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다.
|
||||
|
||||
- [ ] 모든 T-N 태스크 구현 완료
|
||||
- 기준: {{CHECK_ALL_TASKS:각 태스크의 완료 조건(DoD)을 충족해야 한다}}
|
||||
- [ ] 변경 파일 목록과 실제 변경 일치
|
||||
- 기준: {{CHECK_FILE_LIST:3_design.md의 변경 대상과 실제 변경된 파일이 일치해야 한다}}
|
||||
- [ ] 단위 테스트 또는 로컬 검증 완료
|
||||
- 기준: {{CHECK_LOCAL_VERIFY:변경 사항이 로컬 환경에서 의도대로 동작하는지 확인해야 한다}}
|
||||
- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}}
|
||||
|
||||
# 6. 파일 처리 결과
|
||||
이 Implementation 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{DESIGN_PATH:docs/sdlc/<CYCLE_ID>/3_design.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 7. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 8. Implementation Freeze
|
||||
Verification 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 구현 계획: [# 2. 구현 계획](#2-구현-계획)
|
||||
- 변경 파일 목록: [# 3. 변경 파일 목록](#3-변경-파일-목록)
|
||||
- 리스크/오픈 질문: [# 4. 리스크 및 제약](#4-리스크-및-제약)
|
||||
|
||||
## 확정 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:구현 완료 및 로컬 검증 후 Verification으로 인계}}
|
||||
- Ready for Verification: {{READY_FOR_VERIFICATION:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
---
|
||||
|
||||
# 12. 작성 가이드
|
||||
*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.*
|
||||
|
||||
- **변경 대상 파일 경로**: 실제 저장소 파일 경로를 명시한다. 추정이나 가상 경로를 쓰지 않는다.
|
||||
- **완료 조건(DoD)**: "구현 완료"처럼 모호한 표현 대신 "파일 X에 함수 Y가 추가되고 입력 Z에 대해 올바른 결과를 반환한다"처럼 측정 가능하게 작성한다.
|
||||
- **오픈 질문**: 구현 중 발생한 기술적 판단 사항, 외부 확인 필요 항목 등을 기록한다.
|
||||
- **Freeze 섹션**: 모든 태스크 완료 및 로컬 검증 후 담당자가 직접 갱신한다.
|
||||
@@ -1,160 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Implementation: {{IMP_PATH:docs/sdlc/<CYCLE_ID>/4_implementation.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Implementation 인계 요약
|
||||
Implementation에서 완료된 핵심 내용을 요약한다. 원본은 4_implementation.md를 참조하며, 이 섹션은 Verification 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{VER_ISSUE_PURPOSE:Implementation 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 구현 완료 태스크
|
||||
| ID | 태스크 제목 | 변경 파일/함수 | 완료 조건(DoD) |
|
||||
|----|-----------|--------------|--------------|
|
||||
| T-1 | {{VER_TASK_TITLE_1}} | {{VER_TASK_TARGET_1}} | {{VER_TASK_DOD_1}} |
|
||||
| T-2 | {{VER_TASK_TITLE_2}} | {{VER_TASK_TARGET_2}} | {{VER_TASK_DOD_2}} |
|
||||
| T-3 | {{VER_TASK_TITLE_3:필요 없으면 삭제}} | {{VER_TASK_TARGET_3}} | {{VER_TASK_DOD_3}} |
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Implementation에서 `Deferred` 처리되어 Verification 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{VER_DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{VER_DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 검증 계획
|
||||
Discovery `# 7` 성공 기준(S-N)을 기반으로 Verification 항목을 정의한다.
|
||||
|
||||
## 검증 범위
|
||||
- {{VER_SCOPE_1:예. 기능 요구사항(FR) 전체 충족 여부}}
|
||||
- {{VER_SCOPE_2:예. 비기능 요구사항(NFR) 성능 기준 충족 여부}}
|
||||
- {{VER_SCOPE_3:필요 없으면 삭제}}
|
||||
|
||||
## 검증 항목
|
||||
| ID | 검증 항목 | 검증 방법 | 성공 기준 | 담당자 |
|
||||
|----|---------|---------|---------|--------|
|
||||
| VC-1 | {{VER_ITEM_1}} | {{VER_METHOD_1:수동\|자동\|혼합}} | {{VER_CRITERIA_1}} | {{VER_OWNER_1:TBD}} |
|
||||
| VC-2 | {{VER_ITEM_2}} | {{VER_METHOD_2:수동\|자동\|혼합}} | {{VER_CRITERIA_2}} | {{VER_OWNER_2:TBD}} |
|
||||
| VC-3 | {{VER_ITEM_3:필요 없으면 삭제}} | {{VER_METHOD_3:수동\|자동\|혼합}} | {{VER_CRITERIA_3}} | {{VER_OWNER_3:TBD}} |
|
||||
| VC-4 | {{VER_ITEM_4:필요 없으면 삭제}} | {{VER_METHOD_4:수동\|자동\|혼합}} | {{VER_CRITERIA_4}} | {{VER_OWNER_4:TBD}} |
|
||||
|
||||
## 성공 기준 연결
|
||||
Discovery의 성공 기준(S-N)과 검증 항목(VC-N)의 연결을 명시한다.
|
||||
|
||||
- S-1 → {{VER_S1_LINK:VC-1, VC-2 등}}
|
||||
- S-2 → {{VER_S2_LINK:VC-3 등}}
|
||||
- S-3 → {{VER_S3_LINK:필요 없으면 삭제}}
|
||||
|
||||
# 3. 검증 결과
|
||||
검증 수행 후 각 항목의 결과를 기록한다. 초안 생성 시 모두 `미완료`로 초기화한다.
|
||||
|
||||
| ID | 검증 항목 | 결과 | 비고 |
|
||||
|----|---------|------|------|
|
||||
| VC-1 | {{VER_ITEM_1}} | {{VER_RESULT_1:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_1:필요 없으면 삭제}} |
|
||||
| VC-2 | {{VER_ITEM_2}} | {{VER_RESULT_2:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_2:필요 없으면 삭제}} |
|
||||
| VC-3 | {{VER_ITEM_3:필요 없으면 삭제}} | {{VER_RESULT_3:미완료\|통과\|실패\|블로킹}} | {{VER_RESULT_NOTE_3:필요 없으면 삭제}} |
|
||||
|
||||
## 전체 검증 결과
|
||||
- 통과: {{VER_PASS_COUNT:0}} / {{VER_TOTAL_COUNT:0}}
|
||||
- 실패/블로킹: {{VER_FAIL_COUNT:0}}
|
||||
- 검증 완료 여부: {{VER_COMPLETE:false}}
|
||||
|
||||
# 4. 결함 및 재작업 사항
|
||||
검증 중 발견된 결함과 재작업이 필요한 항목을 기록한다.
|
||||
|
||||
- BUG-1: {{BUG_1:없으면 "없음"}}
|
||||
- 심각도: {{BUG_SEVERITY_1:Critical|High|Medium|Low}}
|
||||
- 재작업 내용: {{BUG_FIX_1}}
|
||||
- 상태: {{BUG_STATUS_1:Open|Fixed|Deferred}}
|
||||
- BUG-2: {{BUG_2:필요 없으면 삭제}}
|
||||
- 심각도: {{BUG_SEVERITY_2:Critical|High|Medium|Low}}
|
||||
- 재작업 내용: {{BUG_FIX_2}}
|
||||
- 상태: {{BUG_STATUS_2:Open|Fixed|Deferred}}
|
||||
|
||||
# 5. 리스크 및 오픈 질문
|
||||
Verification 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{VER_RISK_LEVEL_1:High|Medium|Low}}): {{VER_RISK_1}}
|
||||
- 완화 방안: {{VER_MITIGATION_1}}
|
||||
- R-2 ({{VER_RISK_LEVEL_2:High|Medium|Low}}): {{VER_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{VER_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
- OQ-1: {{VER_OPEN_QUESTION_1}}
|
||||
- 상태: {{VER_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{VER_OQ_ACTION_1}}
|
||||
- 종료 조건: {{VER_OQ_EXIT_1}}
|
||||
- OQ-2: {{VER_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{VER_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{VER_OQ_ACTION_2}}
|
||||
- 종료 조건: {{VER_OQ_EXIT_2}}
|
||||
|
||||
# 6. Release로 넘기기 전 확인 체크
|
||||
Release 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다.
|
||||
|
||||
- [ ] 모든 검증 항목(VC-N) 통과
|
||||
- 기준: {{CHECK_ALL_VC:VC 목록의 모든 항목이 "통과" 상태여야 한다}}
|
||||
- [ ] 결함(BUG) `Open` 상태 없음
|
||||
- 기준: {{CHECK_BUGS:BUG 목록에 `Open` 상태 항목이 0개여야 한다. `Deferred`는 근거와 함께 허용}}
|
||||
- [ ] 성공 기준(S-N) 전체 충족
|
||||
- 기준: {{CHECK_SUCCESS_CRITERIA:Discovery에서 정의된 S-N 기준이 모두 VC 항목과 연결되어 통과되었는가}}
|
||||
- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}}
|
||||
|
||||
# 7. 파일 처리 결과
|
||||
이 Verification 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{IMP_PATH:docs/sdlc/<CYCLE_ID>/4_implementation.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 8. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 9. Verification Freeze
|
||||
Release 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 검증 계획: [# 2. 검증 계획](#2-검증-계획)
|
||||
- 검증 결과: [# 3. 검증 결과](#3-검증-결과)
|
||||
- 결함/재작업: [# 4. 결함 및 재작업 사항](#4-결함-및-재작업-사항)
|
||||
|
||||
## 확정 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:검증 완료 및 결함 없음 확인 후 Release로 인계}}
|
||||
- Ready for Release: {{READY_FOR_RELEASE:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
---
|
||||
|
||||
# 10. 작성 가이드
|
||||
*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.*
|
||||
|
||||
- **검증 항목(VC-N)**: Discovery 성공 기준(S-N)과 반드시 연결한다. FR/NFR 각 항목이 하나 이상의 VC와 연결되어야 한다.
|
||||
- **검증 방법**: 수동(테스터가 직접 실행), 자동(CI/테스트 코드), 혼합(일부 자동 + 수동 확인) 중 선택한다.
|
||||
- **성공 기준**: "정상 동작"처럼 모호한 표현 대신 "입력 X에 대해 결과 Y를 반환한다"처럼 측정 가능하게 작성한다.
|
||||
- **결함(BUG)**: 검증 중 발견된 모든 문제를 기록한다. `Deferred` 처리 시 근거와 후속 처리 계획을 명시한다.
|
||||
- **Freeze 섹션**: 모든 VC 통과 및 BUG `Open` 없음 확인 후 담당자가 직접 갱신한다.
|
||||
@@ -1,162 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Verification: {{VER_PATH:docs/sdlc/<CYCLE_ID>/5_verification.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Verification 인계 요약
|
||||
Verification에서 완료된 핵심 내용을 요약한다. 원본은 5_verification.md를 참조하며, 이 섹션은 Release 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{REL_ISSUE_PURPOSE:Verification 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 검증 결과 요약
|
||||
- 검증 항목 수: {{REL_VC_TOTAL}}개
|
||||
- 전체 통과 여부: {{REL_VC_ALL_PASS:true|false}}
|
||||
- 결함(BUG) 잔여: {{REL_BUG_REMAIN:0}}건
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Verification에서 `Deferred` 처리되어 Release 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{REL_DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{REL_DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 배포 준비
|
||||
배포 환경, 배포 전 체크리스트, 배포 순서를 정의한다.
|
||||
|
||||
## 배포 환경
|
||||
- 대상 환경: {{REL_TARGET_ENV:예. production, staging}}
|
||||
- 배포 방식: {{REL_DEPLOY_METHOD:예. git push, CI/CD 파이프라인, 수동 복사}}
|
||||
- 배포 도구/채널: {{REL_DEPLOY_TOOL:예. GitHub Actions, 수동 SSH, 없음}}
|
||||
|
||||
## 배포 전 체크리스트
|
||||
배포 실행 전에 확인해야 할 항목을 나열한다.
|
||||
|
||||
- [ ] {{REL_PRE_CHECK_1:예. 대상 환경 설정 파일 백업 완료}}
|
||||
- [ ] {{REL_PRE_CHECK_2:예. 롤백 계획 확인 완료}}
|
||||
- [ ] {{REL_PRE_CHECK_3:필요 없으면 삭제}}
|
||||
|
||||
## 배포 순서
|
||||
변경 사항의 배포 순서를 적는다. 의존 관계가 있는 경우 순서를 명확히 기술한다.
|
||||
|
||||
1. {{REL_STEP_1:예. 설정 파일 배포}}
|
||||
2. {{REL_STEP_2:예. 코드 변경 배포}}
|
||||
3. {{REL_STEP_3:필요 없으면 삭제}}
|
||||
|
||||
# 3. 롤백 계획
|
||||
배포 후 문제가 발생했을 때 이전 상태로 되돌리는 방법을 기술한다.
|
||||
|
||||
## 롤백 조건
|
||||
아래 조건 중 하나라도 충족되면 롤백을 즉시 실행한다.
|
||||
|
||||
- {{REL_ROLLBACK_TRIGGER_1:예. 배포 후 핵심 기능 오류 발생}}
|
||||
- {{REL_ROLLBACK_TRIGGER_2:예. 성능 지표가 임계값 이하로 하락}}
|
||||
- {{REL_ROLLBACK_TRIGGER_3:필요 없으면 삭제}}
|
||||
|
||||
## 롤백 절차
|
||||
1. {{REL_ROLLBACK_STEP_1:예. 이전 버전 파일/설정 복원}}
|
||||
2. {{REL_ROLLBACK_STEP_2:예. 배포 채널에서 롤백 실행}}
|
||||
3. {{REL_ROLLBACK_STEP_3:필요 없으면 삭제}}
|
||||
|
||||
## 롤백 담당자
|
||||
- {{REL_ROLLBACK_OWNER:TBD}}
|
||||
|
||||
# 4. 배포 후 확인
|
||||
배포 완료 후 정상 동작을 확인하는 방법을 기술한다.
|
||||
|
||||
## 스모크 테스트 항목
|
||||
| 항목 | 확인 방법 | 성공 기준 |
|
||||
|------|---------|---------|
|
||||
| {{REL_SMOKE_ITEM_1}} | {{REL_SMOKE_METHOD_1}} | {{REL_SMOKE_CRITERIA_1}} |
|
||||
| {{REL_SMOKE_ITEM_2}} | {{REL_SMOKE_METHOD_2}} | {{REL_SMOKE_CRITERIA_2}} |
|
||||
| {{REL_SMOKE_ITEM_3:필요 없으면 삭제}} | {{REL_SMOKE_METHOD_3}} | {{REL_SMOKE_CRITERIA_3}} |
|
||||
|
||||
## 모니터링 확인 항목
|
||||
배포 후 일정 시간 동안 모니터링해야 하는 지표나 로그를 기록한다.
|
||||
|
||||
- {{REL_MONITOR_1:예. 오류 로그 발생 여부 확인 (1시간)}}
|
||||
- {{REL_MONITOR_2:필요 없으면 삭제}}
|
||||
|
||||
# 5. 리스크 및 오픈 질문
|
||||
Release 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{REL_RISK_LEVEL_1:High|Medium|Low}}): {{REL_RISK_1}}
|
||||
- 완화 방안: {{REL_MITIGATION_1}}
|
||||
- R-2 ({{REL_RISK_LEVEL_2:High|Medium|Low}}): {{REL_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{REL_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
- OQ-1: {{REL_OPEN_QUESTION_1}}
|
||||
- 상태: {{REL_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{REL_OQ_ACTION_1}}
|
||||
- 종료 조건: {{REL_OQ_EXIT_1}}
|
||||
- OQ-2: {{REL_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{REL_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{REL_OQ_ACTION_2}}
|
||||
- 종료 조건: {{REL_OQ_EXIT_2}}
|
||||
|
||||
# 6. Operations로 넘기기 전 확인 체크
|
||||
Operations 단계로 넘기기 전에 무엇이 완료되어야 하는지 확인한다.
|
||||
|
||||
- [ ] 배포 완료 및 스모크 테스트 통과
|
||||
- 기준: {{CHECK_DEPLOY:배포 절차대로 실행되었고 스모크 테스트 전 항목이 통과되었는가}}
|
||||
- [ ] 롤백 계획 확정
|
||||
- 기준: {{CHECK_ROLLBACK:롤백 조건, 절차, 담당자가 모두 명시되었는가}}
|
||||
- [ ] 모든 오픈 질문(OQ) `Open` 상태 없음 확인
|
||||
- 기준: OQ 목록에 `Open` 상태 항목이 0개이거나, 잔여 항목 전부 `Deferred` 처리 완료
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 또는 인계 결정을 내릴 담당자가 명시되어야 한다}}
|
||||
|
||||
# 7. 파일 처리 결과
|
||||
이 Release 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{VER_PATH:docs/sdlc/<CYCLE_ID>/5_verification.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 8. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 9. Release Freeze
|
||||
Operations 인계 시점의 확정 플래그와 섹션 참조만 기록한다. 내용 재작성 없이 원본 섹션을 링크로 대신한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 배포 준비: [# 2. 배포 준비](#2-배포-준비)
|
||||
- 롤백 계획: [# 3. 롤백 계획](#3-롤백-계획)
|
||||
- 배포 후 확인: [# 4. 배포 후 확인](#4-배포-후-확인)
|
||||
|
||||
## 확정 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:배포 완료 및 스모크 테스트 통과 후 Operations로 인계}}
|
||||
- Ready for Operations: {{READY_FOR_OPERATIONS:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
---
|
||||
|
||||
# 10. 작성 가이드
|
||||
*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.*
|
||||
|
||||
- **배포 방식**: git 기반 프로젝트는 커밋 해시, 브랜치, 태그를 명시하면 롤백이 쉽다.
|
||||
- **롤백 계획**: "문제가 생기면 롤백한다"가 아니라 구체적인 조건, 절차, 담당자를 미리 정의한다.
|
||||
- **스모크 테스트**: 배포 직후 서비스가 최소한 동작하는지 확인하는 핵심 시나리오만 포함한다. 전체 기능 검증은 Verification 단계에서 완료한 것을 전제로 한다.
|
||||
- **모니터링**: 배포 후 지켜봐야 하는 지표(오류율, 응답 시간, 로그 패턴 등)를 구체적으로 기록한다.
|
||||
@@ -1,154 +0,0 @@
|
||||
# 0. 문서 상태
|
||||
이 문서의 현재 상태와 식별 정보를 기록한다. 문서 추적과 승인 흐름에 필요한 최소 메타데이터를 적는다.
|
||||
|
||||
- 상태: {{DOC_STATUS:draft|review|confirmed}}
|
||||
- 문서 ID: {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 참조 Release: {{REL_PATH:docs/sdlc/<CYCLE_ID>/6_release.md}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
# 1. Release 인계 요약
|
||||
Release에서 완료된 핵심 내용을 요약한다. 원본은 6_release.md를 참조하며, 이 섹션은 Operations 작업의 입력 기준선이 된다.
|
||||
|
||||
## 이슈 목적
|
||||
- {{OPS_ISSUE_PURPOSE:Release 이슈명과 핵심 목적 1-2줄}}
|
||||
|
||||
## 배포 결과 요약
|
||||
- 배포 환경: {{OPS_DEPLOY_ENV:예. production}}
|
||||
- 배포 완료 시각(KST): {{OPS_DEPLOYED_AT:TBD}}
|
||||
- 스모크 테스트 결과: {{OPS_SMOKE_RESULT:통과|일부 실패|미완료}}
|
||||
|
||||
## 이월된 오픈 질문 / 리스크
|
||||
Release에서 `Deferred` 처리되어 Operations 단계에서 해소해야 하는 항목을 기록한다.
|
||||
|
||||
- {{OPS_DEFERRED_ITEM_1:없으면 "없음"}}
|
||||
- {{OPS_DEFERRED_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 2. 운영 모니터링
|
||||
배포 후 지속적으로 모니터링해야 하는 항목과 기준을 정의한다.
|
||||
|
||||
## 모니터링 항목
|
||||
| 항목 | 확인 방법 | 임계값 / 이상 기준 | 대응 방안 |
|
||||
|------|---------|----------------|---------|
|
||||
| {{OPS_MONITOR_ITEM_1}} | {{OPS_MONITOR_METHOD_1}} | {{OPS_MONITOR_THRESHOLD_1}} | {{OPS_MONITOR_ACTION_1}} |
|
||||
| {{OPS_MONITOR_ITEM_2}} | {{OPS_MONITOR_METHOD_2}} | {{OPS_MONITOR_THRESHOLD_2}} | {{OPS_MONITOR_ACTION_2}} |
|
||||
| {{OPS_MONITOR_ITEM_3:필요 없으면 삭제}} | {{OPS_MONITOR_METHOD_3}} | {{OPS_MONITOR_THRESHOLD_3}} | {{OPS_MONITOR_ACTION_3}} |
|
||||
|
||||
## 모니터링 담당자
|
||||
- {{OPS_MONITOR_OWNER:TBD}}
|
||||
|
||||
# 3. 운영 절차 (런북)
|
||||
이 변경 사항과 관련된 운영 중 발생할 수 있는 상황별 대응 절차를 정의한다.
|
||||
|
||||
## 정상 운영 확인 절차
|
||||
배포 후 일정 주기로 정상 동작을 확인하는 절차를 기술한다.
|
||||
|
||||
1. {{OPS_ROUTINE_STEP_1:예. 오류 로그 확인 (일 1회)}}
|
||||
2. {{OPS_ROUTINE_STEP_2:필요 없으면 삭제}}
|
||||
|
||||
## 장애 대응 절차
|
||||
이 변경과 관련된 장애가 발생했을 때의 초기 대응 절차를 기술한다.
|
||||
|
||||
1. {{OPS_INCIDENT_STEP_1:예. 오류 로그에서 관련 스택 트레이스 확인}}
|
||||
2. {{OPS_INCIDENT_STEP_2:예. 롤백 판단 기준 확인 후 롤백 또는 핫픽스 결정}}
|
||||
3. {{OPS_INCIDENT_STEP_3:필요 없으면 삭제}}
|
||||
|
||||
## 에스컬레이션 경로
|
||||
장애 대응 중 에스컬레이션이 필요한 경우 연락 대상을 기록한다.
|
||||
|
||||
- {{OPS_ESCALATION_1:TBD}}
|
||||
|
||||
# 4. 운영 중 발생한 이슈
|
||||
운영 중 발견된 이슈를 기록한다. 초안 생성 시 비워 두고 운영 중 갱신한다.
|
||||
|
||||
- {{OPS_ISSUE_1:없음 (운영 중 발견 시 기록)}}
|
||||
|
||||
# 5. 리스크 및 오픈 질문
|
||||
Operations 단계에서 새로 식별된 리스크와 오픈 질문을 기록한다.
|
||||
|
||||
## 리스크
|
||||
- R-1 ({{OPS_RISK_LEVEL_1:High|Medium|Low}}): {{OPS_RISK_1}}
|
||||
- 완화 방안: {{OPS_MITIGATION_1}}
|
||||
- R-2 ({{OPS_RISK_LEVEL_2:High|Medium|Low}}): {{OPS_RISK_2:필요 없으면 삭제}}
|
||||
- 완화 방안: {{OPS_MITIGATION_2:필요 없으면 삭제}}
|
||||
|
||||
## 오픈 질문
|
||||
- OQ-1: {{OPS_OPEN_QUESTION_1}}
|
||||
- 상태: {{OPS_OQ_STATUS_1:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{OPS_OQ_ACTION_1}}
|
||||
- 종료 조건: {{OPS_OQ_EXIT_1}}
|
||||
- OQ-2: {{OPS_OPEN_QUESTION_2:필요 없으면 삭제}}
|
||||
- 상태: {{OPS_OQ_STATUS_2:Open|Answered|Deferred|Dropped}}
|
||||
- 처리 방안: {{OPS_OQ_ACTION_2}}
|
||||
- 종료 조건: {{OPS_OQ_EXIT_2}}
|
||||
|
||||
# 6. 다음 Discovery 환류
|
||||
운영 중 발견된 인사이트와 개선 사항을 다음 SDLC Discovery의 입력으로 기록한다.
|
||||
|
||||
- {{OPS_FEEDBACK_1:없으면 "없음"}}
|
||||
- {{OPS_FEEDBACK_2:필요 없으면 삭제}}
|
||||
- {{OPS_FEEDBACK_3:필요 없으면 삭제}}
|
||||
|
||||
# 7. 확인 체크
|
||||
Operations 문서가 완성되었는지 확인한다.
|
||||
|
||||
- [ ] 모니터링 항목 및 임계값 정의 완료
|
||||
- 기준: {{CHECK_MONITORING:모니터링 항목에 임계값과 대응 방안이 명시되어야 한다}}
|
||||
- [ ] 런북(정상 운영/장애 대응 절차) 정의 완료
|
||||
- 기준: {{CHECK_RUNBOOK:운영 중 발생 가능한 상황에 대한 절차가 1단계 이상 있어야 한다}}
|
||||
- [ ] 에스컬레이션 경로 정의 완료
|
||||
- 기준: {{CHECK_ESCALATION:장애 시 연락할 담당자가 명시되어야 한다}}
|
||||
- [ ] 다음 Discovery 환류 항목 작성 (없으면 "없음" 기재)
|
||||
- 기준: OPS_FEEDBACK 항목이 "없음"이 아닐 경우 구체적으로 기술되었는가
|
||||
- [ ] Freeze 확정 담당자(CONFIRMED_BY) 지정
|
||||
- 기준: {{CHECK_CONFIRMEDBY_CRITERIA:문서 승인 담당자가 명시되어야 한다}}
|
||||
|
||||
# 8. 파일 처리 결과
|
||||
이 Operations 문서 생성/갱신 결과와 참조 문서를 기록한다.
|
||||
|
||||
- 처리 결과: {{FILE_RESULT:생성|갱신|미생성}}
|
||||
- 생성 경로: {{OUTPUT_PATH}}
|
||||
- 참조 문서:
|
||||
- {{REL_PATH:docs/sdlc/<CYCLE_ID>/6_release.md}}
|
||||
- {{REFERENCE_1:필요 없으면 삭제}}
|
||||
|
||||
# 9. 사용자 결정 필요 항목 요약
|
||||
사용자나 승인자가 결정해야 하는 항목만 모아 정리한다.
|
||||
|
||||
## DECIDE
|
||||
- {{DECIDE_ITEM_1}}
|
||||
- {{DECIDE_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## CONFIRM
|
||||
- {{CONFIRM_ITEM_1}}
|
||||
- {{CONFIRM_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
## DATA
|
||||
- {{DATA_ITEM_1}}
|
||||
- {{DATA_ITEM_2:필요 없으면 삭제}}
|
||||
|
||||
# 10. Operations Freeze
|
||||
이 SDLC 주기의 최종 확정 플래그를 기록한다.
|
||||
|
||||
## 섹션 참조
|
||||
- 운영 모니터링: [# 2. 운영 모니터링](#2-운영-모니터링)
|
||||
- 런북: [# 3. 운영 절차 런북](#3-운영-절차-런북)
|
||||
- 다음 Discovery 환류: [# 6. 다음 Discovery 환류](#6-다음-discovery-환류)
|
||||
|
||||
## 확정 플래그
|
||||
- Handoff Decision: {{FREEZE_HANDOFF_DECISION:보류}}
|
||||
- Handoff Rationale: {{FREEZE_HANDOFF_RATIONALE:모니터링 안정화 및 런북 완비 후 주기 완료}}
|
||||
- SDLC 주기 완료: {{SDLC_CYCLE_COMPLETE:false}}
|
||||
- Confirmed By: {{CONFIRMED_BY:TBD}}
|
||||
- Confirmed At (KST): {{CONFIRMED_AT_KST:TBD}}
|
||||
|
||||
---
|
||||
|
||||
# 11. 작성 가이드
|
||||
*이 섹션은 작성 참고용이다. 문서 완성 후 삭제해도 된다.*
|
||||
|
||||
- **모니터링 항목**: "오류가 없는지 확인"처럼 모호한 기준 대신 "5xx 오류율 1% 이상 시 알림" 같이 수치화된 임계값을 명시한다.
|
||||
- **런북**: 실제 운영자가 참고할 수 있도록 구체적인 명령, 경로, 연락처를 기록한다.
|
||||
- **다음 Discovery 환류**: 이 주기에서 발견된 기술 부채, 개선 아이디어, 범위에서 제외된 요구사항 등을 기록한다. 이 항목이 다음 `/new-sdlc` 의 입력이 된다.
|
||||
- **SDLC 주기 완료**: 모니터링 안정화 기간(배포 후 일정 시간 경과, 이상 없음) 확인 후 `true`로 변경한다.
|
||||
@@ -1,12 +0,0 @@
|
||||
# {{CYCLE_ID}}
|
||||
|
||||
| 단계 | 문서 | 상태 |
|
||||
|------|------|------|
|
||||
| 1. Discovery | [1_discovery.md](./1_discovery.md) | `draft` |
|
||||
| 2. Planning | [2_planning.md](./2_planning.md) | `-` |
|
||||
| 3. Design | [3_design.md](./3_design.md) | `-` |
|
||||
| 4. Implementation | [4_implementation.md](./4_implementation.md) | `-` |
|
||||
| 5. Verification | [5_verification.md](./5_verification.md) | `-` |
|
||||
| 6. Release | [6_release.md](./6_release.md) | `-` |
|
||||
| 7. Operations | [7_operations.md](./7_operations.md) | `-` |
|
||||
| Summary | [summary.md](./summary.md) | `-` |
|
||||
@@ -1,16 +0,0 @@
|
||||
# Summary - {{CYCLE_ID:sdlc-<3자리>_<YYYYMMDD>_<topic-slug>}}
|
||||
|
||||
- 이슈명: {{ISSUE_NAME:짧은 한글 또는 영문 이슈명}}
|
||||
- 상태: {{SUMMARY_STATUS:draft|review|confirmed}}
|
||||
- 작성 시각(KST): {{CREATED_AT_KST:TBD}}
|
||||
- 마지막 갱신 시각(KST): {{UPDATED_AT_KST:TBD}}
|
||||
|
||||
## 핵심 요약
|
||||
|
||||
- {{SUMMARY_POINT_1}}
|
||||
- {{SUMMARY_POINT_2:필요 없으면 삭제}}
|
||||
|
||||
## 단계별 문서
|
||||
|
||||
- [Discovery](./1_discovery.md)
|
||||
- [Index](./index.md)
|
||||
@@ -0,0 +1,87 @@
|
||||
# Software Requirement Specification Index
|
||||
|
||||
## 목적
|
||||
- 이 문서는 프로젝트의 SRS 운영 기준과 requirement 목록을 관리하는 entry point이다.
|
||||
- 개별 requirement의 상세 내용은 타입별 폴더 하위 `req-XXX_*.md` 파일에서 관리한다.
|
||||
|
||||
## 사용 방법
|
||||
1. 새로운 requirement가 필요하면 `Next Requirement ID`를 확인하고 `docs/srs/req-template.md`를 복사해 `docs/srs/<Type>/req-XXX_<slug>.md` 파일을 생성한다.
|
||||
2. 초안 작성은 `draft-req`, 승인 전환은 `confirm-req`, 변경 대응은 `change-req`, 구현 완료 전환은 `confirm-req-implemented` skill을 기준으로 수행한다.
|
||||
3. 작성 또는 수정 후 누락과 모호성을 점검한다.
|
||||
4. requirement 추가 또는 변경 후 `Next Requirement ID`, `Requirement Register`, `Recent Change Log Summary`를 함께 갱신한다.
|
||||
5. `Proposed` requirement를 승인하려면 승인 준비 상태와 blocker를 점검한다.
|
||||
6. `Approved` requirement는 구현 이슈나 작업 항목으로 연결한다.
|
||||
7. 구현과 검증이 끝난 requirement는 `confirm-req-implemented` skill로 완료 전환 가능 여부를 점검한다.
|
||||
8. requirement 변경 시 `change-req` skill을 기준으로 해당 REQ 파일의 `Change Log`를 먼저 갱신한 뒤 본문을 수정한다.
|
||||
9. 구현 전에는 관련 REQ 파일과 최근 `Change Log`를 기준으로 변경 범위를 판단한다.
|
||||
|
||||
## 상태 정의
|
||||
- Proposed: 초안 상태이며 구현 기준으로 확정되지 않음
|
||||
- Approved: 구현 기준으로 승인됨
|
||||
- Implemented: 구현과 검증이 완료됨
|
||||
- Deprecated: 더 이상 유지하지 않음
|
||||
|
||||
## Status Transition Evidence
|
||||
|
||||
### Proposed -> Approved
|
||||
- `Status`, `Type`, `Priority`, `Owner`, `Intent`, `Requirement`, `Acceptance Criteria`, `Impacted Area`, `Change Log`가 모두 존재해야 한다.
|
||||
- `Type`은 아래 분류 도표에서 정확하게 하나로 지정되어야 한다.
|
||||
- `Acceptance Criteria`는 구현 판단에 사용할 수 있을 정도로 구체적이어야 한다.
|
||||
- 미해결 assumption 또는 open question이 있으면 `Notes`에 명시하고, 승인 blocker 여부를 판단해야 한다.
|
||||
- 승인 전환 시 해당 REQ 파일의 `Change Log`에 status 변경 사유를 기록해야 한다.
|
||||
|
||||
### Approved -> Implemented
|
||||
- 각 `Acceptance Criteria`에 대해 test, manual verification, 또는 구현 결과 중 최소 1개의 evidence가 있어야 한다.
|
||||
- evidence는 requirement 문서 자체 또는 연결된 구현/검증 결과에서 추적 가능해야 한다.
|
||||
- 미충족 `Acceptance Criteria`가 있으면 `Implemented`로 전환하지 않는다.
|
||||
- 구현 완료 전환 시 잔여 리스크와 미검증 영역이 있으면 `Change Log`에 기록해야 한다.
|
||||
- 상태 전환은 `confirm-req-implemented` skill을 기준으로 수행한다.
|
||||
|
||||
### Requirement Change Handling
|
||||
- 기존 REQ 본문(`Requirement`, `Acceptance Criteria`, `Impacted Area`)을 수정하기 전에는 새 `Change Log` 항목을 만든다.
|
||||
- `Change Log`에는 최소한 `Acceptance Criteria Delta`, `Impacted Area Delta`, `Delivery Trace Delta`, `Revalidation Impact`, `Validation Plan`이 포함되어야 한다.
|
||||
- 변경이 기존 구현 또는 verification evidence를 무효화하면 `Implemented` requirement는 `Approved`로 되돌린다.
|
||||
- 변경이 승인 전제 자체를 다시 검토하게 만들면 `Approved` 또는 `Implemented` requirement를 `Proposed`로 되돌릴 수 있다.
|
||||
- 상태 되돌림이 발생하면 `Requirement Register`와 `Recent Change Log Summary`도 함께 갱신한다.
|
||||
|
||||
## Requirement 타입 분류 도표
|
||||
|
||||
| 타입 | 정의 | 예시 |
|
||||
|------|------|------|
|
||||
| **Configuration** | 설정 옵션, 커스터마이징 포인트 | 설정 파라미터, 환경 변수, 옵션 항목 |
|
||||
| **Data** | 데이터 구조, 저장/로드, 파일 형식, 스키마 | 설정 파일 형식, DB 스키마, API 구조 |
|
||||
| **Deployment** | 배포 방식, 운영 절차, 배포 환경 | 컨테이너 배포, 스택 관리, 운영 가이드 |
|
||||
| **Documentation** | 문서 작성, 가이드, 매뉴얼, 안내서 | 사용자 가이드, API 문서, 튜토리얼 |
|
||||
| **Exception** | 오류 처리, 예외 복구, 재시도 전략 | 오류 복구, 검증 실패 처리, 폴백 전략 |
|
||||
| **Installation** | 시스템 설치, 환경 구성, 초기화 절차 | Docker 이미지 빌드, DB 마이그레이션, 사전 조건 설정 |
|
||||
| **Integration** | 외부 시스템 연동, 플러그인, 확장 | 3rd party 연동, 플러그인 인터페이스 |
|
||||
| **Interface** | 사용자 상호작용 방식 (UI, API, CLI, 제어방식) | CLI 명령어, API 엔드포인트, 웹 UI 기능 |
|
||||
| **Migration** | 데이터 이전, 버전 업그레이드 | 데이터 마이그레이션, 버전 호환성 |
|
||||
| **Non-Functional** | 성능, 보안, 확장성, 호환성, 신뢰성 | 성능 목표, 보안 정책, 확장성 |
|
||||
| **Testing** | 테스트 전략, QA 요구사항, 검증 방식 | 테스트 커버리지, 회귀 테스트, 수락 기준 |
|
||||
|
||||
## Requirement 작성 규칙
|
||||
- 각 requirement는 고유 ID를 가진다. 예: `REQ-001`
|
||||
- 다음 신규 requirement 번호의 source of truth는 이 문서의 `Next Requirement ID` 섹션이다.
|
||||
- 새 requirement를 추가하거나 ID 충돌이 발생할 수 있는 변경을 했으면 `Next Requirement ID`를 함께 갱신한다.
|
||||
- 각 requirement는 `Type`을 명시해야 한다. 위 분류 도표 중 정확하게 하나로 선택하며, `docs/srs/<Type>/` 폴더명도 같은 문자열을 사용한다.
|
||||
- 각 requirement는 `Intent`, `Requirement`, `Acceptance Criteria`, `Impacted Area`를 반드시 포함한다.
|
||||
- 모호한 표현("개선한다", "적절히 처리한다") 대신 관찰 가능하고 test 가능한 문장을 사용한다.
|
||||
- requirement 변경 사항은 해당 REQ 파일의 `Change Log`에 기록한다.
|
||||
- requirement 변경 시 영향 받는 batch/release와 재검증 필요 여부를 `Change Log`에 남긴다.
|
||||
- `Recent Change Log Summary`는 최신 5건만 유지한다.
|
||||
- status 전환은 `Status Transition Evidence` 기준을 따른다.
|
||||
|
||||
## Next Requirement ID
|
||||
|
||||
- Current: `REQ-001`
|
||||
- Rule: `Requirement Register`에 있는 가장 큰 REQ 번호보다 정확히 1 커야 한다.
|
||||
|
||||
## Requirement Register
|
||||
|
||||
| ID | Title | Type | Status | Priority | Owner | Link |
|
||||
| --- | --- | --- | --- | --- | --- | --- |
|
||||
|
||||
## Recent Change Log Summary
|
||||
|
||||
- 없음
|
||||
@@ -0,0 +1,67 @@
|
||||
# req-XXX: <요구사항 제목>
|
||||
|
||||
- Status: Proposed | Approved | Implemented | Deprecated
|
||||
- Type: Configuration | Data | Deployment | Documentation | Exception | Installation | Integration | Interface | Migration | Non-Functional | Testing
|
||||
- Priority: High | Medium | Low
|
||||
- Owner: <담당자 또는 팀>
|
||||
|
||||
## Intent
|
||||
- <이 요구사항이 필요한 이유와 달성하려는 목표를 1~3문장으로 작성>
|
||||
|
||||
## Requirement
|
||||
- <시스템이 반드시 수행해야 하는 동작을 단정형 문장으로 작성>
|
||||
|
||||
## Acceptance Criteria
|
||||
1. Given <선행 조건>, When <행동>, Then <기대 결과>
|
||||
2. Given <선행 조건>, When <행동>, Then <기대 결과>
|
||||
|
||||
## Impacted Area
|
||||
- Docs: <영향 받는 문서 경로>
|
||||
- Modules: <영향 받는 모듈/컴포넌트>
|
||||
- Tests: <추가/수정해야 하는 테스트>
|
||||
|
||||
## Notes
|
||||
- <가정, 제약, 미해결 이슈>
|
||||
|
||||
## Change Log
|
||||
|
||||
### CHG-YYYYMMDD-01
|
||||
- Date: YYYY-MM-DD
|
||||
- Author: <작성자>
|
||||
|
||||
#### Change Summary
|
||||
- <무엇이 변경되었는지>
|
||||
|
||||
#### Intent
|
||||
- <왜 변경했는지>
|
||||
|
||||
#### Acceptance Criteria Delta
|
||||
- Added:
|
||||
- <추가된 기준>
|
||||
- Updated:
|
||||
- <변경된 기준>
|
||||
- Removed:
|
||||
- <삭제된 기준>
|
||||
|
||||
#### Impacted Area Delta
|
||||
- Docs:
|
||||
- <문서 영향>
|
||||
- Modules:
|
||||
- <코드 영향>
|
||||
- Tests:
|
||||
- <테스트 영향>
|
||||
|
||||
#### Delivery Trace Delta
|
||||
- Batches:
|
||||
- <영향 받는 batch 또는 none>
|
||||
- Releases:
|
||||
- <영향 받는 release 또는 none>
|
||||
|
||||
#### Revalidation Impact
|
||||
- Reverification Needed: yes | no
|
||||
- Existing Implementation Invalidated: yes | no
|
||||
- Status Recommendation: keep-current | revert-to-approved | revert-to-proposed
|
||||
- Follow-up Action: <필요한 재검증, 재배치, 후속 작업>
|
||||
|
||||
#### Validation Plan
|
||||
- <검증 방법과 완료 조건>
|
||||
Reference in New Issue
Block a user