architecture-generatorlisted

# 아키텍처 작성 (Layer 2) ## 이 스킬의 목적 아키텍처는 **"고른 기술 안에서 어떤 모양으로 만들 것인가"**에 대한 합의문이다. PRD가 사용자에게 한 약속이고 TRD가 그 약속을 지키려고 고른 수단이라면, 아키텍처는 그 수단을 실제 구조로 배치한 것이다. 여기서 정한 구조가 뒤에서 이렇게 흘러간다. ``` 아키텍처의 설계 단위 (database.md §3.2 인보이스 번호 채번) → 태스크의 Files·Architecture 항목이 이걸 가리킨다 (Layer 3) → 품질 게이트가 검증할 대상이 여기서 나온다 (Layer 4) → 루프의 한 태스크가 "무엇을 건드려도 되는가"의 경계가 된다 (Layer 5) ``` 그래서 이 문서의 품질은 "구조가 세련됐는가"가 아니라 두 가지로 판정된다. 1. **각 설계가 어느 요구사항·기술 결정 때문인지 적혀 있는가** 2. **PRD·TRD와 어긋나는 지점을 조용히 봉합하지 않고 드러냈는가** 두 번째가 이 레이어의 핵심이다. 요구사항과 기술 결정이 처음 **동시에** 한 사람 앞에 놓이는 곳이 여기다. PRD를 쓸 때는 기술이 없었고 TRD를 쓸 때는 구조가 없었으므로, 둘이 못 만나는 지점은 **아키텍처를 그려 봐야 비로소 보인다.** 그리고 그 지점을 여기서 못 보면, 다음에 보이는 곳은 Layer 5에서 태스크가 세 번 실패하고 멈추는 순간이다. ### 여기서 하는 일과 하지 않는 일 | 하지 않는 것 | 어디서 하는가 | |---|---| | 요구사항을 새로 만들거나 우선순위를 바꾸는 것 | PRD (`prd-generator`) — 돌아가서 고친다 | | 기술을 새로 고르거나 바꾸는 것 (라이브러리 교체 포함) | TRD (`trd-generator`) — 돌아가서 고친다 | | 개발 순서, 태스크 분할, phase 구성, 일정 | Layer 3 마스터 플랜 (`plan-generator`) | | 품질 게이트 4단계 구성, E2E가 덮을 흐름 목록, task validation 절차 | Layer 4 하네스 (`harness-setup`) | | 실제 코드, 마이그레이션 파일, 설정 파일 작성 | Layer 5 개발 루프 | **아키텍처는 요구사항도 기술도 만들지 않는다.** 설계하다 보면 둘 다 만들고 싶어진다 — "여기 관리자 화면이 있어야겠는데"(요구사항), "이건 큐가 있어야 되겠는데"(기술). 그렇게 문서에 슬쩍 들어간 것은 추적표에 근거가 없고, PRD·TRD 어느 쪽에서도 검토받지 않은 채 Layer 3에서 태스크가 된다. **둘 다 충돌로 처리해 되돌려 보낸다.** 2단계가 그 방법이다. ### TRD와 아키텍처의 경계 TRD가 이미 정해 둔 기준이 있다 — **후보 중 하나를 고르는가, 고른 것 안에서 모양을 정하는가?** | TRD (고른다) | 아키텍처 (모양을 정한다) | |---|---| | 관계형 DB를 쓴다. 후보 중 X를 고른다 | `invoices` 테이블에 어떤 컬럼