[Refactor] FSD 아키텍처로 마이그레이션

[zero0205]

#️⃣ 연관된 이슈

• ♻️ [Refactor] FSD 구조 적용 #3

✨ 구현 기능 명세

• FSD 구조로 마이그레이션

🎁 PR Point

개선한 이유

1. src/components의 평면적인 구조

• 페이지 종속 컴포넌트는 src/pages 하위에 잘 분리되어 있으나, src/components 내부 구조에 문제가 있음
  • 성격이 다른 컴포넌트들이 구분 없이 한 폴더에 섞여있음
    • 실제 재사용 컴포넌트 (ChatContainer, Header 등)
    • SVG 아이콘 컴포넌트 (Icons)
• 컴포넌트의 역할과 책임이 불명확함

2. src/hooks의 평면적인 구조

• 각기 다른 기능을 담당하는 훅들이 동일 레벨에 위치
  • 스트리밍 관련: useConsumer, useProducer, useMedia, useTransport
  • 인증 관련: useAuth,
  • api 관련: useAPI
  • 공통 기능: useSocket, useTheme, useToast, useIntersect
• 관련 기능의 훅들이 분산되어 있어 코드 파악이 어려움
• 훅 간의 의존성 관리가 복잡함

3. 기능 확장의 어려움

• 평면적인 구조로 인해 새로운 기능 추가 시 적절한 위치 선정이 어려움
• 기존 코드와의 관계를 파악하기 어려워 리팩토링이나 기능 추가가 복잡해짐
• 특히 인공지능 리팩토링 과정에서 기능을 추가하며 이러한 문제점들이 더욱 부각될 것으로 예상

이런 문제점들로 인해 디렉토리 구조를 개선하기로 결정했다.

개선 과정

1. 코드를 pages 단위로 분할
2. 모든 것을 페이지에서부터 분리하기
3. 페이지 간의 상호 import 해결
4. shared 레이어 풀어헤치기
5. Technical Purpose에 따라 코드 구성하기
6. 슬라이스를 entities/features로 분리하기
7. widgets 레이어로 분리하기

자세한 내용은 => 🔗 코드 품질 개선3: FSD로 마이그레이션

😭 어려웠던 점

1. features, entitties, widgets 레이어는 어떤 것을 여기로 빼야할지 기준을 잡는 것이 어려웠다. 그래서 FSD에 대해 분석한 글과 예시 등을 보고 아래와 같이 정의 내리고 레이어를 분리했다.

• features: 사용자가 수행하는 액션을 중심으로 분리(ex. 로그인, 방송 송출/시청, 프로필 수정)
• entities: 핵심 비즈니스 도메인 모델(ex. 모델 타입 정의, 관련 api 로직, 상태 관)
• widgets: 작은 컴포넌트들을 모아서 하나의 독립적인 기능을 하는 레이아웃/컴포넌트

2. 생각보다 코드들이 강하게 결합되어 있어서 분리가 쉽지 않았다. 하나의 컴포넌트가 하나의 기능 또는 UI만 담당하도록 만드는 것이 좋겠다는 생각이 들었다.