dev-goraebap/structure-planner

structure-planner

fsd-workshop 파이프라인의 2단계. 페이지 목록을 보고 사용자와 인터뷰하면서 FSD의 레이어 배치를 결정한다.

이 스킬이 결정하는 것:

1. 레이아웃 존 — 어떤 페이지가 어떤 레이아웃을 공유하는가
2. shared/ui 후보 — 도메인 무관, 여러 곳에서 재사용될 순수 UI 컴포넌트
3. widgets 후보 — 여러 페이지에서 재사용될 대형 도메인 블록
4. 인증 설계 — 로그인 방식, 토큰 관리 위치, 라우트 보호 방식

이 스킬이 결정하지 않는 것:

• features / entities 레이어 (구현하다 보면 자연히 나온다 — 억지로 설계하지 않는다)
• 폴더 트리의 실제 파일 경로 (이는 framework-adapter 역할)

---

대화 UX 규약

• 1문 1답 기본. 단순 Yes/No만 2~3개까지 번호로 묶기 허용.
• "모름" / "미정" / "나중에" 항상 허용 → ⚠️ 미정으로 기록.
• 각 섹션이 완성되면 사용자에게 보여주고 확인받은 뒤 다음으로 넘어간다.
• 결정 근거를 짧게 설명한다 ("이 컴포넌트가 3개 이상의 페이지에서 쓰이므로 shared/ui 후보입니다").

---

사전 조건

fsd-blueprint.md가 존재해야 한다. 파일을 먼저 읽고 페이지 목록과 사용자 역할을 파악한다.

파일이 없으면:

fsd-blueprint.md를 찾을 수 없습니다.
먼저 `fsd-workshop:requirements-analyzer`를 실행해 주세요.

---

1. 레이아웃 존 분류

페이지 목록을 보고 공통 레이아웃 패턴을 그룹화한다.

자동 인식 레이아웃 (페이지 목록에서 즉시 판단)

| 레이아웃명 | 해당 페이지 패턴 | 특징 | |-----------|----------------|------| | AuthLayout | 로그인, 회원가입, 비밀번호 재설정 | 헤더/사이드바 없음, 중앙 정렬 폼 | | ErrorLayout | 404, 500, 접근 거부 | 최소 레이아웃 | | MainLayout | 인증된 일반 사용자 페이지 | 상단 네비게이션 또는 사이드바 | | AdminLayout | 관리자 전용 페이지 | 별도 네비게이션 구조 |

위 4가지 외에 추가 레이아웃이 필요한지 사용자에게 확인한다.

페이지 목록을 분석한 결과, 아래 레이아웃이 필요해 보입니다.

[레이아웃 목록과 각 레이아웃에 속하는 페이지 목록 제시]

맞나요? 추가하거나 합칠 레이아웃이 있으면 알려주세요.

레이아웃 배치 원칙 (FSD 기준)

• 프레임워크가 레이아웃을 강제하는 경우 (Next.js layout.tsx, Nuxt layouts/, SvelteKit +layout.svelte) → app 레이어
• 재사용되는 대형 레이아웃 블록 (헤더, 사이드바 위젯 등) → widgets 레이어
• 프레임워크 미정이거나 판단 보류 → ⚠️ 미정으로 표시

---

2. shared/ui 후보 추출

shared/ui의 기준: 도메인 무관하고 여러 페이지에서 재사용되는 순수 UI 컴포넌트.

자동 추론 후보

요구사항에서 공통적으로 나타나는 패턴을 추론해 목록을 제안한다.

예시 추론 로직:

• "등록", "수정" 폼이 여러 페이지에 있음 → FormField, FormGroup
• 목록 페이지가 다수 있음 → DataTable, Pagination
• 승인/반려/상태 처리가 있음 → StatusBadge, ConfirmDialog
• 검색 기능이 반복됨 → SearchInput

아래 컴포넌트들이 shared/ui 후보로 보입니다.

[컴포넌트 목록과 이유 제시]

각 항목에 대해: 맞다 / 이건 도메인 결합이 있다 (→ widgets로 이동) / 불필요 중 선택해 주세요.

모달 vs 페이지 인터뷰

목록에서 등록/수정 기능이 있으면 반드시 확인한다.

[기능명] 등록은 어떻게 처리할까요?

1) 별도 페이지로 이동 (예: /employees/new)
2) 현재 페이지에서 모달/다이얼로그
3) 슬라이드 패널 (Drawer)
4) 아직 미정

모달/다이얼로그를 선택한 경우, 반응형 처리를 확인한다.

모바일에서도 같은 방식(모달)으로 보여야 하나요?
아니면 모바일에서는 전체 페이지처럼 보여야 하나요?

1) 모바일에서도 모달 유지
2) 모바일에서는 전체 페이지로 전환 (Bottom Sheet 또는 full-screen 스타일)
3) 아직 미정

반응형 처리가 필요한 경우: shared/ui에 반응형 래퍼 컴포넌트(예: ResponsiveDialog)를 두는 방향을 제안한다.

---

3. widgets 후보 추출

widgets의 기준: 여러 페이지에서 재사용되지만 도메인 결합이 있는 대형 UI 블록.

자동 추론 후보 예시:

• 모든 인증 페이지에서 공유되는 헤더/사이드바 → Header, Sidebar
• 여러 페이지에서 쓰이는 사용자 정보 카드 → UserCard
• 여러 페이지에서 쓰이는 알림 패널 → NotificationPanel

아래 항목들은 여러 페이지에서 재사용되지만 도메인 결합이 있어 widgets 후보입니다.

[위젯 목록과 이유 제시]

맞나요? 추가하거나 제거할 것이 있으면 알려주세요.

---

4. 인증 설계

인증 관련 페이지가 있으면 반드시 진행한다.

4-1. 로그인 진입 방식

로그인은 어떻게 진입하나요?

1) 전용 페이지 (/login 등) — 로그인하지 않으면 리다이렉트
2) 어느 페이지에서나 뜨는 모달/다이얼로그
3) OAuth 외부 링크만 (소셜 로그인만)
4) 아직 미정

4-2. 토큰 관리

토큰 관리 복잡도는 어떤가요?

1) 단순 — 쿠키 기반이거나 자동 처리 (별도 로직 거의 없음)
2) 중간 — 액세스 토큰 + 리프레시 토큰, 만료 시 재발급
3) 복잡 — 멀티 디바이스, 강제 로그아웃, 세션 관리 등
4) 아직 미정

결과에 따라 배치 결정:

• 단순 → shared/api 클라이언트에서 처리
• 중간 이상 → shared/auth 전용 세그먼트 권장

4-3. 라우트 보호

인증되지 않은 사용자가 보호된 페이지에 접근하면?

1) 로그인 페이지로 리다이렉트
2) 에러 페이지 표시
3) 아직 미정

라우트 보호 로직의 위치: app 레이어 (미들웨어 또는 라우터 가드).

---

5. 산출물 — fsd-blueprint.md 업데이트

기존 파일을 읽고 아래 섹션을 채운다. 기존 내용(페이지 & 라우트, 메타 등)은 그대로 유지한다.

## 레이아웃 구조

| 레이아웃명    | 해당 페이지                      | 배치           |
|------------|-------------------------------|---------------|
| AuthLayout | 로그인, 회원가입                  | app 레이어     |
| ErrorLayout | 404, 500                      | app 레이어     |
| MainLayout | 대시보드, 연차신청, ...            | app 레이어     |
| AdminLayout | 사원관리, 권한관리, ...            | app 레이어     |

---

## 공용 컴포넌트 후보

### shared/ui (도메인 무관, 순수 UI)

| 컴포넌트명          | 설명                     | 근거                        |
|------------------|------------------------|---------------------------|
| DataTable        | 정렬/필터 가능한 테이블    | 사원 목록, 연차 목록 등 다수 페이지 |
| Pagination       | 페이지네이션               | DataTable과 함께 사용         |
| StatusBadge      | 상태 표시 배지             | 연차 상태, 권한 상태 등          |
| ConfirmDialog    | 확인/취소 다이얼로그         | 삭제, 승인, 반려 등             |
| ResponsiveDialog | 모바일 full-screen 전환    | 연차 신청 폼 (모바일 대응)        |

### widgets (도메인 결합 있음, 재사용)

| 위젯명           | 설명                   | 근거              |
|----------------|----------------------|-----------------|
| AppHeader      | 상단 네비게이션 + 유저 메뉴 | MainLayout에서 사용 |
| AppSidebar     | 사이드 네비게이션           | MainLayout에서 사용 |

---

## 인증 설계

- **로그인 진입**: 전용 페이지 (/login) — 미인증 시 리다이렉트
- **토큰 관리**: `shared/auth` — 액세스 토큰 + 리프레시 토큰
- **라우트 보호**: `app` 레이어 미들웨어/가드 → 미인증 시 /login 리다이렉트
- **로그아웃**: AppHeader 위젯의 `model` 세그먼트에서 처리

업데이트 후 문서 하단의 진행 상태 표시를 변경한다:

> **현재 단계**: 2/3 — structure-planner 완료

---

6. 강제 체크리스트

□ fsd-blueprint.md 읽기 완료
□ 레이아웃 존 분류 사용자 확인 완료
□ shared/ui 후보 목록 사용자 확인 완료
□ 모달 vs 페이지 패턴 인터뷰 완료 (해당 기능 있는 경우)
□ 모바일 반응형 패턴 확인 완료 (모달 선택 시)
□ widgets 후보 목록 사용자 확인 완료
□ 인증 설계 3항목 (진입/토큰/라우트) 모두 결정됨 (또는 ⚠️ 미정)
□ 기존 fsd-blueprint.md 내용 보존됨 (덮어쓰지 않음)
□ 진행 단계 표시 2/3로 업데이트됨

---

7. 절대 하지 말 것

• features / entities 레이어를 설계하거나 목록화하기. 이들은 구현 중 자연히 등장한다.
• 폴더 트리 파일 경로 작성 — 이는 framework-adapter 역할.
• 공용 컴포넌트를 무조건 shared/ui에 배치하기. 도메인 결합이 있으면 widgets로.
• 사용자 확인 없이 섹션 완성.