항상 고민하는 파일 구조

프로젝트를 진행할 때, 항상 파일 구조를 어떻게 해야할까? 라는 고민을 했다.
기존에는 전통적인 파일 구조를 따라 Model, Service, View를 나누어 역할에 따른 관심사별로 분리하는 방식을 선택했었지만 프로젝트의 규모가 커질수록 애매모호한 파일들이 항상 발생했다.

가장 최근에 진행했던 프로젝트의 폴더 구조로 크게 pages == View, hooks == Service, types == Model로 여기고 관심사를 분리했었다.
다만 components 내부는 Atomic Component Design 패턴을 따라 atoms, molecules, organisms, templates로 구분했었고, 해당 컴포넌트를 pages에서 불러서 사용하는 방식을 채택했었다.

하지만 기능에 따라 하나의 폴더가 너무 비대해지거나, 아니면 너무 적은 양의 파일이 있는 폴더들이 존재했었고, 특히 공통 관심사를 가진 컴포넌트나 로직을 어떤 폴더에 넣어야할 지 어려움을 겪었다.

FSD 채택

이에 여러 FE 아키텍쳐를 검색했고, 비교적 최근 FSD를 채택하는 젊은 기업이 많다는 글과 함께 이 방식을 선택하여 새로운 프로젝트를 진행하기로 했다.

해당 이미지는 FSD 공식문서에서 제공하는 이미지로 FSD구조를 보여준다.
(이런 아키텍쳐의 설명을 위한 공식문서가 있다는 점에 놀라웠고, 실제로 한국 사용자들이 번역을 했는지 한글번역도 지원해서 굉장히 이해하기 편리하다.)

FSD의 핵심은 관심사를 기능 단위로 구분하는 것인데, 그 전에 책임에 따른 분류를 선행한 후에 기능 관심사별로 분리한다는 것이 특징이다.

FSD에 대한 설명은 공식문서와 여러 사람들의 블로그에 작성된 내용이 충분히 많으니
이번 포스팅에서는 개인적으로 느끼는 특징과 적용기에 대해서 이야기하고자 한다.

이전보다 찾기 쉬운 파일

실제로 이 구조를 사용해보면서 이전에 진행했던 프로젝트보다 굉장히 유용하다고 느끼는 점은 손쉽게 원하는 기능을 찾을 수 있다는 점이었다. 기존에는 특정 컴포넌트나 로직이 어디에 있는지 찾으려면 역할에 따른 책임과 쪼개진 단위를 머리 속으로 그려가면서 '이쯤 있겠지?' 하고 찾아야 했는데, 폴더의 사이즈가 비대하거나, 팀원들 마다 추상화에 대한 이해가 다르면 허탕을 치는 경우도 발생하곤 했다.
하지만 FSD를 적용해 놓으니 약속해 놓은 책임별 기능 폴더에서 비교적 수월하게 찾을 수 있었다.

코드 스플리팅 및 순수성 유지

책임별로 먼저 나누고(Layers 계층), 기능별 슬라이스(Slices 게층)를 유지한다는 것에서 자연스럽게 코드에 대한 스플리팅이 가능했다. 위의 그림에서 Layers 계층을 보면 app에서 부터 shared로 내려올 수록 추상화의 개념이 넓어지고, 하위 개념은 상위 개념을 호출하지 않는 것이 원칙이다. 이에 따라 가장 범용적으로 쓰이는 컴포넌트, 로직을 shared부터 정의하게 되고 하위에서 선언된 코드를 상위에서 더 좁고, 완성된 페이지나, 로직으로 만들어 갈 수 있기 때문에 함수의 순수성 유지나, 유지보수 관점에서 유리하다는 생각을 했다.
물론 기존에 진행하던 전통적인 방식의 폴더 구조 또한 계층 체계를 나름 내부에서 잡아서 비슷하게 유지했지만, 이 FSD라는 컨셉을 유지하기 위해 반 강제적으로 개발자의 코드 스플리팅을 실현해야하는 점에서 팀프로젝트에서 충분히 매력적인 아키텍쳐라는 생각이 들었다.

next.js 프로젝트를 위한 FSD 커스텀

FSD를 next.js 프로젝트에 적용을 하려면 타협을 봐야한다. FSD 내에서 app은 주로 route와 같은 진입점을 잡고 pages에서 해당 페이지의 view를 담당한다. 그러나 next.js(app router 기준)는 app 폴더 내부의 폴더가 route를 설정하는 기능을 가지고 그 안의 pages.tsx가 해당 라우트의 view를 만들기 때문에 FSD의 컨셉을 그대로 활용할 수 없다.
이에 따른 고민을 하던 중 공식문서를 찾아보았으나 아직은 page router 기준으로 작성되어 있어서 다른 사람들의 여러 케이스를 참고했다.

pages의 개념을 app에 통합하는 방식을 선택했고, processes는 공식문서 내에서도 철회되었으며, widgets 또한 선택적으로 적용할 수 있는 개념이라 최소한의 폴더를 유지하는 방향으로 기획했다.

비교적 작은 프로덕션 사이즈에는 너무 비대하다.

FSD는 컨셉의 분리가 명확한 만큼 프로젝트의 규모가 작다면 상대적으로 FSD를 유지하기 위한 노력이 매우 귀찮아진다. 다만 유지보수가 매우 간편하다는 것으로 작은 사이즈에서도 충분히 만족할 이유가 된다. 하위 계층부터 상위 계층까지 책임이 명확하기 때문에, 내가 추가하고 싶은 기능에 있어 해당 계층부터 순차적으로 올라가면서 변경사항을 적용할 수 있고, 쪼개진 만큼 책임을 분담하기 때문에 순수성을 유지하기 쉽다고 생각한다.

마무리

이렇게 FSD의 적용기에 대해 간단하게 정리해보았다. 아직은 프로젝트가 진행 중이라 마무리 될 때까지 FSD에 대한 나의 생각이 달라질지는 모르겠지만 이렇게 더 나은 프로젝트를 진행하는 방향으로의 경험은 언제나 성장을 촉진시키는 것 같아 좋은 경험이 될 것이다.