Velog
블로그 목록

FSD 폴더구조 체험기

0
FSD 폴더구조 체험기
next.js

적용하게 된 계기

개인 프로젝트이든, 협업 프로젝트이든 항상 내게는 폴더 구조에 대한 고민이 남아있었던 것 같다.

폴더 구조가 아무것도 아닌 것 같으면서도 막상 나중에 나를 가장 힘들게 하는 것 중 하나이기 때문이다.

문제

가장 큰 문제는 기준이 없다는 것이었다.

기준이 왜 없어?? components, hooks, ... 다 잘 나눠져 있잖아??

당연히 나누어져 있다. 충분히 프로젝트를 진행 할 수 있지만, 프로젝트가 커지면 말이 달라진다.

컴포넌트가 어떤 역할을 하는지, 어떤 기능에 종속되는지 등등 컴포넌트에는 수많은 케이스가 있기 때문에, 단순히 components라는 폴더 안에 이 수많은 케이스들을 넣어두기에는 적합하지 않다.

components안에서도 또 나누면 안되는건가??

당연히 된다. 그렇지만 선택사항이다 그말인 즉슨 얘도 기준이 따로 없다.

components안에 만들 폴더들은 기능으로 나눌지, 아니면 역할로 나눌지 결정하기 어렵다.

또한, 예외케이스도 모두 존재한다. 예를 들어 현재 프로젝트의 components 폴더의 하위 폴더들은 모두 기능별로 나누어져 있다고 가정하자. 그렇다면 components아래에는 auth/, writePost/ 등등의 폴더가 있을 것이다.

그런데, 여기서 내가 토스트 메시지를 띄워주는 ToastProvider를 components에 넣는다고 했을 때, 과연 어떤 디렉토리에 넣겠는가?

나의 경우에는 앞선 규칙을 무시하고 providers에 줄곧 넣어왔다. 잘못된 것이라는 걸 알면서도 어쩔 수 없이 그랬다. src아래에 providers를 넣는 것도 생각했지만, components아래에 만드는 것 보다 더 안좋아 보였다. 얘는 누가 뭐래도 컴포넌트니까.

FSD를 선택한 이유

FSD를 선택한 이유는 앞서 말한 문제들을 모두 속시원하게 해결하기 때문이다.

FSD에는 기준이 있다.

단순히 컴포넌트, 훅같은 큰 범위의 기준이 아닌 기능별로 어떻게 어떤 파일들을 묶어야 할지 상세히 정해져있다.

굉장히 감동이었던 부분은, 사용자가 웹사이트와 상호작용할 때에 사용되는 컴포넌트들과 게시글, 유저와 같이 데이터를 나타내는 컴포넌트를 구분해주는 점이었다.

애매하면 shared

앞서 말했던 상황들과 마찬가지로 FSD를 사용하면서도 조금 애매할 때가 있다. 그렇지만, shared에는 ui/, model/ 등등 기능이 아닌 역할로 폴더가 구분되어있기 때문에 provider라는 이름을 붙혀도 어색하지 않은 것이다.

대규모에 어울림

언제까지 소규모 개인 프로젝트에만 묶여있을 수는 없지 않은가.

좀더 큰 프로젝트를 개발하고, 유지보수에 초점을 두어 다른 사람들이 나의 코드를 이해하고 유지보수 할 수 있는 그런 프로젝트를 갈망해 왔었다.

전통적인 기능 중심 구조를 사용한 다른 프로젝트를 보았을 때, 내가 이걸 유지보수를 한다면?? 이라고 했을 때, 관련 파일들도 이리저리 흩어져있고, 어디에 종속되어있으며 내가 이 파일을 수정 했을때 영향이 가는 범위를 파악하는 것이 어려웠다.

옛날에 만든 내 프로젝트를 지금 가져오면 똑같이 그런 생각이 든다 이건 내가 그냥 못해서 그럴 수도

FSD는 관련 파일이 features/나 entities/에 거의 함께 들어있기 때문에 나의 코드 수정이 미칠 영향의 범위를 파악하기 쉬웠던 것 같다.

작은 프로젝트는 어떡해요?

오버엔지니어링

폴더구조 뿐만 아니라 라이브러리 하나, 프레임워크 하나 쓸 때에도 자주 드는 생각이다.

내가 이 조그만거 만드는데 여기저기 판을 키워야하나??

FSD도 사실 이런면이 있다. 태생이 대규모 프로젝트를 위한 폴더 구조여서 어쩔 수 없는 부분인 것 같다.

그렇지만 내가 FSD를 배웠다고 FSD만 써야하는 것은 아니지 않은가?

적당히 규모가 예상이 가능한 프로젝트면 기능 중심 구조를 사용할 수도 있는 것이고,

만약 확장성을 고려한다면, FSD를 축약하여 사용해도 되는 것 아닌가?

features/ 아래의 디렉토리들은 기능 디렉토리 일 것이다. 이 기능 디렉토리에는 ui/, model/, types/, api/ 등이 존재하는데, 이런 디렉토리 없이 그냥 기능 디렉토리 안에 관련 파일을 모두 만들어도 되는 것이다.

별 차이 없어 보일 수 있지만 실제로 해보니 프로젝트를 시작하고 몇 시간만 지나도 폴더 만드는게 귀찮은게 느껴졌다.

팀 컨벤션 아니면 딱히 지킬 필요 없는 것 같다.

FSD의 원칙만 잘 지킨다면 폴더 구조 자체도 확장성이 높은 것 같아 마음에 들었다.

후기

웹 개발에 질려오던 차 나에게 분 새로운 바람 같았다.

앞으로 자주 사용하면서 체감되는 차이를 더 느껴보아야 객관적인 판단이 가능할 것 같지만

내가 여태껏 고민해오던 것들을 한방에 해결해준 것 같았다.

훈수는 언제나 환영

새 글 알림 받기

글이 마음에 드셨다면 블로그를 구독하고 새로운 소식을 받아보세요.

On this page