trd-generatorlisted

# TRD 작성 (Layer 1) ## 이 스킬의 목적 TRD는 **"어떤 기술로 만들 것인가"**에 대한 합의문이다. PRD가 사용자에게 한 약속이라면, TRD는 그 약속을 지키기 위해 고른 수단과 그 근거다. 여기서 내린 결정 하나하나가 뒤에서 이렇게 흘러간다. ``` TRD의 결정 TD-004 (관계형 DB를 쓴다) → 아키텍처에서 database.md 의 전제가 된다 (Layer 2) → 태스크의 Files·Acceptance Criteria가 이 위에 쓰인다 (Layer 3) → 테스트 도구·배포 형태 결정이 품질 게이트와 local-dev 스크립트의 재료가 된다 (Layer 4) ``` 그래서 이 문서의 품질은 "최신 기술을 잘 골랐는가"가 아니라 **"각 결정이 어느 요구사항 때문인지, 틀렸을 때 무엇을 되돌려야 하는지가 적혀 있는가"**로 판정된다. 근거 없이 적힌 기술 이름은 뒤 레이어에서 **검토 대상이 아니라 기정사실로 읽힌다.** 아무도 왜 그걸 쓰는지 모르는 채로 태스크 수십 개가 그 위에 쌓인다. ### 여기서 하는 일과 하지 않는 일 | 하지 않는 것 | 어디서 하는가 | |---|---| | 요구사항을 새로 만들거나 바꾸는 것 | PRD (`prd-generator`) — 돌아가서 고친다 | | 테이블 컬럼·인덱스 설계, API 엔드포인트 명세, 모듈·컴포넌트 구조 | Layer 2 아키텍처 (`architecture-generator`) | | 개발 순서, 태스크 분할, 일정 | Layer 3 마스터 플랜 | | 품질 게이트 4단계 구성, E2E가 덮을 흐름 목록, task validation 방식 | Layer 4 하네스 (`harness-setup`) | | lint 설정 파일, 테스트 코드, 실행 스크립트 작성 | Layer 4 하네스 | **테스트에서 TRD가 정하는 것은 도구와 범위까지다.** 하네스는 PRD를 직접 읽으므로, 어느 사용자 흐름이 핵심인지는 그쪽이 원본을 보고 판단하는 편이 정확하다. 여기서 흐름 목록까지 확정하면 TRD가 하네스 설계를 떠안게 되고, 요구사항이 바뀔 때 고쳐야 할 문서가 하나 늘어난다. **TRD와 아키텍처를 나누는 기준은 하나다** — 이 문장이 **후보 중 하나를 고르는가, 고른 것 안에서 모양을 정하는가?** | TRD (고른다) | 아키텍처 (모양을 정한다) | |---|---| | 관계형 DB를 쓴다. 후보 중 X를 고른다 | `invoices` 테이블에 status 컬럼과 부분 인덱스를 ��다 | | REST + JSON, 오류 응답은 한 가지 형식으로 통일한다 | `GET /invoices?status=overdue` 의 요청·응답 스키마 | | 세션 기반 인증, 권한은 소유자 단일 역할 | 미들웨어가 어느 계층에서 소유권을 검사하는가 | | 브라우저 자동화 도구로 X를 쓴다 | 그 도구로 어떤 흐름을 어떤 순서로 검증하는가 | 이 경계를 지키는 이유는 형식이 아니다. **기술 선택은 프로젝트당