FSD란?
Features Slided Design (이하 FSD)는 애플리케이션을 기능 단위로 나누어서 개발하는 방식입니다.
주로 서버에서 많이 쓰이고 있는 구조입니다.
이걸 왜 써야 할까?
보통 일반적으로 프론트엔드를 개발할때는 components, hooks, libs 등의 Atomic 구조로 많이 개발합니다.
하지만 이 Atomic 구조의 근본적인 문제가 존재합니다. 기능이 많아질수록 폴더 구조가 굉장히 더러워진다는것이죠.
Atomic 구조를 쓰니까..
실제로 회사 입사 당시, 회사 공식 홈페이지를 Atomic 구조를 통해 짰습니다.
결론은 굉장히 더러워진 구조가 되어 에러가 나면 그걸 디버깅 하기가 굉장히 어려웠습니다.
(당시에 썻던 구조입니다.)
물론 제가 부족했던 탓도 물론 있었겠죠. 하지만 그럼에도 불구하고 폴더가 진짜 너무 많아져서 관리가 지옥이었습니다.
그러던 중 이분의 글을 보게 되었습니다.
프론트엔드에서 코드는 어떻게 잘 짜는 것일까? (Feat. FSD) - 타락한스벨트전도사
https://velog.io/@k-svelte-master/frontend-domain-architecture
머리를 한대 맞은 기분이었습니다. 왜 폴더를 도메인 단위로 나눌 생각을 하지 않았을까?
그렇게 FSD를 도입하게 되었습니다.
FSD 이거 왜 진작에 안썼지
우선 폴더 구조를 도메인 단위로 나누게 되면서 초반에 많은 시간이 소요됐습니다.
FSD를 잘 알지 못하여 계속 공부하며 gpt의 도움도 받으면서 구조를 리팩토링하는데 약 1주일의 시간이 소요되었습니다.
그렇게 FSD를 도입하고 난 뒤, 디버깅 속도가 눈에 띄게 향상되었습니다.
기존에 블로그 등록이 안되면
components/blog 열기 -> queries/blog 열기 -> hooks/blog 열기 -> types/blog 열기
이런식으로 굉장히 복잡하고 더러운 방식이었습니다. 하지만 FSD를 도입하고 난 뒤에는
entities/blog 열기 -> features/blog 열기
이렇게 걍 두개만 열어서 안에서 손쉽게 찾으면 되서 디버깅 속도가 굉장히 빨라졌습니다.
여러분도 FSD 쓰세요
제 디버깅 효율은 FSD 구조를 쓰기 전과 쓰기 후로 나뉠 정도로 굉장히 좋은 구조를 가지고 있습니다.
물론 기능이 적은 프로젝트의 경우엔 오히려 FSD 구조가 비효율적일 수 있습니다.
하지만 기능이 많은 프로젝트인 경우는 FSD 구조를 한번 써보시는걸 추천합니다.
