---
type: checklist
domain: product
role: Tech Lead·아키텍처
status: active
last-reviewed: 2026-07-27
---

# Tech Lead·아키텍처 완료 체크리스트

## 경계·결정

- [ ] C1·C2에 사용자·발주사 기존 시스템·배포 단위·데이터 흐름이 있다 — 시스템구성도 납품본으로 제출 가능하다.
- [ ] 도메인·데이터 Owner와 금지된 직접 접근(발주사 DB 직접 조회 등)이 명시됐다.
- [ ] 신뢰 경계마다 검증·인가·민감도·로그 정책이 있고 발주사 보안 정책 근거가 연결됐다.
- [ ] one-way 결정에 ADR, 발주사 제약 입력, 대안, 결과, 재검토 트리거가 있다.
- [ ] 계약 범위·우선순위를 기술 판단으로 임의 변경하지 않았고, 범위 밖 기술 요청은 CR로 회부됐다.

## 계약·실패

- [ ] API에 요청·응답·오류·권한·timeout·idempotency가 있다 — API정의서 납품본으로 제출 가능하다.
- [ ] 데이터 필드 의미·제약·민감도·보존·마이그레이션·롤백이 있다 — ERD·테이블정의서·코드정의서로 제출 가능하다.
- [ ] 발주사 기존 시스템 인터페이스는 발주사 측 사양 원본·합의 근거가 기록됐다.
- [ ] 데이터 이관의 포함/제외가 계약 기준으로 확정됐다.
- [ ] 생산자·소비자(발주사 연동 담당 포함)가 같은 계약 버전을 확인했다.
- [ ] 관련 NFR에 임계값·표본·측정법·계약 근거·Owner가 있고 착수 전 발주사와 합의됐다.
- [ ] 외부 실패·중복·순서·부분 실패·재기동 경로가 설계됐다.
- [ ] 비가역 행동은 사람 승인(운영 반영은 발주사 절차)과 감사 증거 뒤에 있다.

## 작업·통합

- [ ] 필요한 specialist만 활성화했다 — 계약에 없는 작업이 섞이지 않았다.
- [ ] 작업이 수직 슬라이스로 나뉘고 WBS 마일스톤·중간 데모와 연결된다.
- [ ] 각 카드에 요구·입력·출력·검증·파일 소유권이 있다.
- [ ] 병렬 역할의 수정 경로가 겹치지 않거나 격리·병합 계획이 있다.
- [ ] Database→Backend→Frontend 등 실제 의존 순서가 반영됐다.
- [ ] 발주사 의존(사양·계정·데이터 제공)이 시작 조건으로 명시되고 지연 기록 규칙이 있다.
- [ ] Result Card 고정 3섹션과 저장 경로가 전달됐다.

## 리뷰·이관·복구

- [ ] 계약·요구 누락·범위 일탈·과설계 통합 검토(RTM 대조)가 계획됐다.
- [ ] Security cross-review는 항상, Design 리뷰는 Frontend 참여 시 활성화된다.
- [ ] 고위험 변경의 독립 렌즈·표결·결함 실재 확인 규칙이 있다.
- [ ] QA가 원본 요구와 실제 변경물을 직접 볼 수 있다 — 테스트결과서의 근거.
- [ ] 이관·마이그레이션·안정화·롤백 절차와 중단 임계값이 있고 발주사 승인 절차와 정합한다.
- [ ] 검수본 버전이 형상관리로 고정된다.
- [ ] 재디스패치 최대 2회와 사람 에스컬레이션이 정의됐다.

## 판정

- 판정: `READY / NOT READY / CONDITIONAL`
- 차단 설계·계약: `{없음 또는 ID}`
- 납품 문서 상태: `{시스템구성도·API정의서·ERD 제출 가능 여부}`
- 미수행 리뷰·검증: `{없음 또는 이유·위험}`
- 보완 Owner·기한: `{값}`
- Reviewer·Approver·일시: `{값}`