[Re|view] 7. FSD 구조 적용 실패기

📜서론

쌓여만 가는 컴포넌트들과 여러 파일들...

그동안 여러 프로젝트들을 진행하면서 기준 없이 무질서한 디렉토리 구조에 미묘한 불편함을 늘 느껴왔다. 그러던 중 최근 유튜브에서 제로초님의 영상을 보고 FSD 아키텍쳐란 것을 알게 되었다. 영상에서 소개한 FSD 소개 아티클의 번역본을 참고하면서 진행 중이던 올평 프로젝트에 이를 적용해보기로 했다.

🤔 FSD란?

FSD는 Feature-Sliced Design의 약자로, 직역하자면 기능 분할 설계다. 다음과 같은 구조로 이뤄져 있으며, 프론트엔드 애플리케이션의 구조를 체계적으로 설계하기 위한 방법론이다. 왠지는 모르겠지만 공식 문서도 있다.

📌레이어

이 사진을 유심히 살펴보면 FSD의 컨셉이 뭔지 감을 잡을 수 있다.

• app: 전역적으로 작동하는 것들
• processes: 여러 페이지에 걸쳐진 프로세스(현재는 사용되지 않음)
• pages: 페이지
• widgets: 독립적인 UI 컴포넌트
• features: 실질적인 기능이 존재하는 UI(댓글 조회 버튼, 알림 버튼, 리뷰 작성 버튼 등).
• entities: 데이터와 관련된 것들(사용자 리뷰, 댓글 등). 단순히 데이터를 보여주는 UI도 여기 해당된다.
• shared: 앱 전반에서 사용되는 재사용 가능한 컴포넌트와 유틸리티

레이어는 계층 구조이며, 높은 레이어는 낮은 레이어들의 것들을 사용할 수 있지만 낮은 레이어는 높은 레이어의 것들을 사용할 수 없다.

📌슬라이스

각 레이어는 여러 슬라이스로 구성된다. 슬라이스는 비즈니스 로직에 따라 레이어의 요소들을 나눈 것이다. react-toolkit의 슬라이스를 생각하면 이해가 편하다. 재량껏 슬라이스를 구분하면 될 듯하다.

📌세그먼트

각 슬라이스는 다시 프로그래밍적인 기능에 따라 여러 세그먼트는 나눠진다. "각 슬라이스는 다시 여러 세그먼트로 구성된다"라고 공식 문서에도 쓰여 있긴 한데, 실제로 적용하려고 하니 모든 슬라이스를 다시 세그먼트로 나눌 필요는 없다고 느꼈다. features, entities만 세그먼트로 나누는 것이 맞는 듯 하다. 일반적으로 다음과 같은 세그먼트들이 사용된다고 한다.

• api: 필요한 서버 요청.
• ui: 슬라이스의 UI 컴포넌트.
• model: 비즈니스 로직, 즉 상태와의 상호 작용. actions 및 selectors가 이에 해당
• lib: 슬라이스 내에서 사용되는 보조 기능.
• config: 슬라이스에 필요한 구성값이지만 구성 세그먼트는 거의 필요하지 않음.
• consts: 필요한 상수.

📌공개 API

각 슬라이스와 세그먼트에는 공개 API가 있으며, 이는 index.js 또는 index.ts 파일이다. 이 파일에 명시된 기능만 외부로 추출하고 명시되지 않은 기능은 격리된 것으로 간주한다. 즉 필요한 기능만 이 파일에 export 키워드로 명시하면 된다.

굳이 뭐하러 귀찮게 이런 걸 폴더마다 만들어야 하나 싶긴 하지만 각 계층에서 무엇을 격리시키고 무엇을 외부에서 사용 가능하게 할 것인지 명시한다는 것에 의미를 두는 듯 하다. 클래스의 public 메서드라 생각하면 이해하기 쉬울 듯 하다.

📌OOP의 개념들이 적용된 아키텍쳐

OOP에는 다형성, 캡슐화, 상속 및 추상화와 같은 개념들이 있다. FSD는 위에서 설명한 구조들을 통해 OOP의 개념들을 아키텍쳐 레벨에서 달성할 수 있도록 돕는다고 할 수 있다.

1. 추상화와 다형성: 레이어를 통해 달성
2. 캡슐화: 공개 API를 통해 달성
3. 상속: 레이어를 통해 달성

OOP의 단점 중 하나인 설계 소요 시간 -> 애초에 설계 똑바로 해놓으면 나중에 편하다

도움되는 자료: https://github.com/noveogroup-amorgunov/nukeapp

❌ 하지만 결국 적용하지 않기로 함

이걸 도입할 당시에 이틀동안 고심했는데 결국 안하는 게 맞다는 결론을 내렸다.

프로젝트 뎁스도 너무 깊고 규모 대비 너무 걸거치는게 많았다. 규칙을 지키려다 보니 아니 굳이 이렇게 까지 해야함?하는 부분들이 생겼는데 이게 너무 마음에 들지 않았다. 진짜 규모 있는 프로젝트라 유지 보수 용이하게 하려고 계층 명확하게 해야 하는 게 아니라면 이런 수고를 들이는 거 자체가 시간 낭비란 생각이 들었다.

대신 차선책으로 FSD의 개념들을 일부 차용해 내 입맛대로 좀 느슨하게 적용하면서 추후에 필요하다면 천천히 마이그레이션 해보는 방향으로 타협했다.