작업 목록과 일관성 분석

/speckit-tasks가 사양과 계획을 63개 작업으로 나눕니다. - [ ] T017 [P] [US1] … 한 줄에 담긴 뜻, 사용자 이야기별 단계, 병렬 표시 [P]의 조건을 봅니다. 이어서 /speckit-analyze가 사양·계획·작업 세 문서를 대조해 찾아낸 문제와, 수정을 승인하는 과정까지 봅니다.

무엇을 · 왜#

작업 목록은 구현 에이전트가 그대로 따라갈 실행 계획입니다. 그래서 형식이 엄격합니다.

- [ ] T017 [P] [US1] 문장 해석 시험 `backend/src/test/java/kr/parking/query/QueryParserTest.java`: … (FR-001, FR-002)
  │     │    │    │    └ 할 일과 정확한 파일 경로
  │     │    │    └ 어느 사용자 이야기의 작업인가 (이야기 단계에만)
  │     │    └ 병렬 가능 (다른 파일이고, 끝나지 않은 작업에 기대지 않을 때만)
  │     └ 실행 순서대로 붙는 번호
  └ 체크박스. 구현이 끝나면 [X]

단계는 정해져 있습니다.

Spec Kit의 작업 목록 규칙에서 시험 작업은 선택입니다. 사양에서 요청하거나 TDD를 요청한 경우에만 넣습니다. 이 실습은 헌법 I 「시험 먼저」가 있어서 모든 이야기가 같은 순서를 갖습니다.

시험 작성 [P] 여러 개 → 실패 확인(T024) → 구현 → 통과 확인(T032)

따라 하기#

1. 작업 목록을 만듭니다. 인자 없이 /speckit-tasks를 실행합니다. 1분 14초 뒤 62개 작업(나중에 T033a가 더해져 63개)이 나왔고, 그중 [P]가 붙은 작업은 40개(T033a 뒤 41개)입니다. 맨 아래에는 단계 사이 의존 관계, 병렬 실행 예, MVP 우선 전략, FR ↔ 작업 추적표가 붙습니다.

   

2. 일관성 분석을 실행합니다. /speckit-analyze는 아무 파일도 고치지 않고 보고서만 냅니다. 이 실습의 결과는 FR 커버리지 18/18(100%), 모호함 3건, 중복 1건, CRITICAL 0건, HIGH 1건이었습니다.

   

3. 수정안을 제안받고 승인합니다. 보고서 끝에 "상위 항목의 수정안을 제안할까요? 승인하기 전에는 아무것도 고치지 않습니다"라고 묻습니다. 제안을 받아 보니 시작 시각의 기준을 「결제 승인 시점」으로 정하자는 권고(U2)가 있었고, 이를 승인했습니다.

   네, 상위 항목 수정안 제안해 줘
   네, 승인 시점으로 적용해 줘
   

일관성 분석이 보는 것#

/speckit-analyze는 세 문서와 헌법을 읽어 여섯 가지를 찾습니다.

심각도는 네 단계입니다. 헌법 MUST 위반은 무조건 CRITICAL입니다. 원칙을 바꿔야 한다면 분석 중에 임의로 해석을 바꾸지 말고, 헌법을 따로 고치라고 정해 두었습니다.

산출물과 바뀐 점#

① 분석 보고서(이 실습). 파일로 남지 않고 화면에만 나옵니다.

그 밖에 MEDIUM 2건(I2 추적표의 시험 이름 불일치, U4 오류 형식 시험의 위치)과 LOW 4건(A1 예약 번호 순번, A2 「한 번의 동작」 기준, D1 중복, F1 모의 결제 문구)이 있었습니다.

② 승인 뒤 바뀐 것. 일곱 개 문서가 함께 고쳐졌습니다.

• spec.md: 새 FR-019(결제 승인 시점에 이용 가능 여부 재확인), 인수 시나리오 3개 추가(US2-3 중복 요청, US2-4 면수 감소, US3-3 결제 중 만차)로 8개 → 11개, 가정 4줄 추가.
• tasks.md: 번호를 밀지 않으려고 T033a(재확인 시험)를 끼워 넣고, T044 설명을 고치고, 추적표에 FR-019 행을 더했습니다.
• contracts/api.md: 400 LOT_UNAVAILABLE 응답 추가. data-model.md의 startAt은 결제 승인 시점으로.

확인 문제#