[Refactor] FSD 구조에 맞게 디렉토리 및 코드 파일 재배치 #66

♻️ 리팩토링 목적

현재 프로젝트 구조에서 FSD 원칙과 살짝 다르거나, 역할에 비해 위치가 모호한 디렉토리 및 코드 파일들이 일부 존재한다고 생각합니다.
각 코드의 책임이 잘 드러나고, FSD 구조에 더 잘 어울리도록 디렉토리 및 파일 배치를 정비할 필요가 있다고 판단합니다.

✅ 개선 방향

• 현재 프로젝트 구조를 시각화 하여 FSD 기준에 따라 다시 정리 및 재배치
• 기존 동작에는 영향을 주지 않도록 구조 개선 위주의 리팩토링 진행

⚠️ 영향 범위/고려사항 (선택사항)

• 디렉토리 및 파일 이동으로 인해 import 경로가 변경될 수 있음
• 한 번에 해결하지 않고, 단계적으로 진행하여도 괜찮으니 확실히 체크하면 좋겠습니다.

🛠️ 아래는 FSD 구조 개선 방법에 대한 GPT 답변

“현재 프로젝트가 FSD에 맞게 잘 굴러가고 있는지” 점검할 때는 (1) 아키텍처 린터로 구조 위반을 잡고, (2) ESLint로 레이어 의존성/퍼블릭 API 규칙을 강제하고, (3) 의존성 그래프로 순환/침범을 시각화하는 3단 조합이 제일 효율적이야.

1) FSD 전용 아키텍처 린터: Steiger

FSD 공식 쪽에서 “프로젝트 아키텍처를 체크하는 린터”로 Steiger를 안내하고 있어. ([feature-sliced.design]1)

• 장점: “폴더 구조/아키텍처” 관점으로 FSD 위반을 잡는 데 집중(레이어, 슬라이스 등).
• 보통 CI에 붙이면 “리뷰에서 구조 얘기”가 확 줄어듦.

FSD 공식 문서 FAQ에 “Steiger라는 린터가 있다”라고 명시돼 있어. ([feature-sliced.design]1)

2) ESLint로 FSD 규칙 강제 (레이어 침범 / public API / slices)

A) 공식 계열: feature-sliced/eslint-config

FSD 컨셉을 기존 ESLint 플러그인들로 강제하는 설정이 있고, 대표 규칙이 public-api, layers-slices, import-order 쪽이야. ([GitHub]2)

• public-api: 슬라이스 내부 파일로 “직접 import” 못하게 막고, index.ts 같은 공개 진입점만 허용
• layers-slices: 상위 레이어가 하위 레이어만 참조하도록(레이어 규칙) 강제

글에서도 “FSD가 제공하는 eslint-config가 3개 규칙을 제공하며, 내부적으로 eslint-plugin-boundaries, eslint-plugin-import 등을 활용한다”는 식으로 정리돼 있어. ([DEV Community]3)

B) 커뮤니티 플러그인: @conarti/eslint-plugin-feature-sliced

FSD 방법론을 위한 ESLint 플러그인(베타/활발 개발)을 따로 두고 규칙을 더 직접적으로 적용할 수도 있어. ([GitHub]4)

너는 이미 import 정렬을 ESLint로 강제하고 있으니까, 여기에 “레이어/퍼블릭API” 규칙까지 얹으면 FSD 점검이 자동화돼.

3) 의존성 그래프 툴로 “순환/침범” 한 방에 찾기

FSD에서 실제로 문제를 만드는 건 보통:

• 순환 의존성 (A→B→A)
• 상위 레이어가 상위/동급 레이어를 참조하는 레이어 침범
• public API 무시(슬라이스 내부 파일 direct import)

이건 린터로 잡히기도 하지만, 그래프 툴로 보면 훨씬 빨리 이해돼.

• dependency-cruiser / madge 같은 걸로 “순환 의존성”과 “폴더 경계 위반”을 시각화/리포팅
• (툴 자체는 FSD 전용은 아니지만, FSD 규칙을 폴더 기준으로 작성하기 좋아)

4) 실무 점검 루틴(추천)

툴만 붙이고 끝내면 “잘못된 구조가 왜 생겼는지”가 계속 반복돼서, 아래 루틴 같이 가면 좋아.

1. 레이어 경계 규칙 먼저 고정: app/pages/widgets/features/entities/shared 간 import 방향 규칙
2. public API 강제: 각 slice는 index.ts만 외부 노출
3. 리팩토링 기준 마련: “이 코드는 어디로 가야 하는가?”를 짧게 문서화
4. CI에서 강제: Steiger + ESLint를 PR에서 실패하도록

5) 이미 ESLint/Husky/정렬까지 넣은 상태)에서 “가장 쉬운 추가”

• Steiger를 CI에 붙여서 구조 위반을 먼저 잡고 ([feature-sliced.design]1)
• ESLint에는 feature-sliced/eslint-config 계열(또는 boundaries/import 기반 룰)을 추가해서 레이어/퍼블릭 API 규칙을 강제 ([GitHub]2)

이렇게 하면 “현재 구조 점검”이 사람이 보는 리뷰가 아니라 자동 검사 결과로 바뀌어서 훨씬 편해져.