FSD 도입기
FSD(Folder Structure Design) 구조에 대해 학습하는 과정에서 현재 프로젝트와 겪고 있는 문제를 해결하기에 적합하다는 것을 알게 되었다. FSD는 기존의 모듈 아키텍처와 달리 명확한 기준이 있으며, 크게 Layer, Slice, Segments라는 개념으로 나뉜다.
Layer는 7개의 계층으로 분리되는데, 그 기준이 처음에는 헷갈렸다. 다행히 FSD의 공식 페이지에서는 여러 가지 예시를 제공하고 있다. 각각의 예시는 각기 다른 개발자들이 제공하는 것이라 FSD를 처음 접하는 입장에서 혼란스러울 수 있었다. 그러나 많은 블로그 글을 읽고 코드와 비교해본 결과, 핵심은 다음과 같았다.
- Slice와 Segments라는 두 가지 주요 개념이 있다.
- 모든 Layer는 Segments를 가질 수 있지만, 특정 Layer는 추상 레벨이 높아야 하기 때문에 Slice를 가질 수 없다.
- Layer는 선형 구조를 이루며, 상위 Layer는 하위 Layer를 참조할 수 있지만, 하위 Layer는 상위 Layer를 참조할 수 없다. 이러한 구조적 특성이 모듈 사이클 문제를 방지한다.
- 각 Segment안에서 모듈은 서로 연결 할 수 있지만, Slice끼리의 참조는 불가능하다.
도메인을 연결하는 API로직은 어디에?
이 부분이 가장 고민이 많았다. API를 어떻게 보면 프로젝트의 전역에서 사용할 수 있기 때문에 Shared 폴더에서 관리하는 게 맞다는 생각이 들었다. 그런데 Shared 폴더는 추상 레벨이 높아 Slice를 가지지 않는다는 특징이 있다. 하지만 각 API의 경로를 연결하는 로직은 엄연히 각 도메인의 관심사이다. 또한 그 API 로직은 다른 프로젝트 내에서 활용하기에는 애매하다.
Entities의 경우 데이터 모델과 관련된 작업을 다루는 Layer 계층이다. API 로직을 데이터로 간주할 수 있을까? 뭔가 애매하다는 생각이 들었다. 하지만 Shared에 API 폴더를 두고 다수의 API 로직을 한 폴더 내에 둔다고 생각하니 끔찍했다. 거기에 auth, template 폴더를 만드는 것은 Shared 폴더의 첫 번째 규칙인 추상 레벨이 높아 Slice가 없다는 룰을 어기게 된다.
이런 이유에서 각 도메인의 API는 Entities에서 Slice를 나눠 API 파일에서 관리하기로 했다. 그리고 Shared의 기준은 당장 다른 프로젝트에 적용해도 수정 없이 사용 가능한 수준의 추상 레벨의 코드를 정의하기로 했다.
느낀점
아직 FSD 아키텍처를 도입하는 초기 단계이지만, 확실한 것은 각 Layer마다 기준이 명확하여 규칙만 잘 지키면 모듈은 서로 연결될 수 없다는 점이다. 또한 index를 통해서만 모듈에 접근할 수 있어, Layer 내부에서 폴더를 움직이거나 약간의 로직을 수정하는 것이 외부에 영향을 미치지 않을 만큼 서로의 관심사가 잘 분리되는 구조라는 점이 좋았다.
불편한 점은 단순한 모놀리스 아키텍처와 달리 기준이 명확해야 하고, 생각을 많이 해야 한다는 점과 구조에 대한 개념을 명확하게 파악해야 한다는 점에서 학습 곡선이 높다는 것이다. 아직 초반 도입부인데도 얼마나 많은 생각을 하고 학습을 했는지 모를 정도로 많은 시간을 들였다.
FSD의 구조적 장점을 이해하고 적용하기 위해서는 많은 학습과 고민이 필요하지만, 이를 통해 얻는 이점은 분명히 크다. 프로젝트의 확장성과 유지보수성을 고려했을 때, FSD 아키텍처는 장기적으로 매우 유용할 것이라는 확신이 들었다.
