프론트엔드 아키텍처와 Feature-Sliced Design (1)

 

 

 

우선 아키텍처는 프론트엔드와 백엔드간 성격이 좀 다르다고 생각한다.

 

백엔드에서 클린아키텍처를 적용할 때는 DDD 방식을 많이 사용한다.

DDD 를 적용하는 방식이 조금 다를 수는 있어도, 내가 경험한 프로젝트들에서는 모두 DDD 방식을 사용했고 좀 잘 만들었다 싶은 프로젝트를 깃허브에서 찾아보면 진짜 웬만하면 다 DDD 방식으로 설계되어 있다.

 

프론트엔드에서는 화면 단위로 개발하게 되니 내가 바로 볼 수 있는 화면을 기준으로 아키텍처를 설계하는 경우가 많다. 

components / pages 이런식으로.. 화면을 기준으로 디렉토리를 네이밍하고 그 안에서 뻗어나가는 식인데

이게 DDD랑 비슷한거 같으면서도 좀 다르다. 

 

프로젝트 규모가 작을 때는 그냥 화면 기준으로 설계한 아키텍처를 사용해도 큰 문제가 없었는데, 규모가 큰 프론트엔드 프로젝트를 진행할 때는 몇 가지 불편한 점을 느꼈다. 

 

도메인 규칙 - 비즈니스 로직도 화면 단위로 작업하다 보니 공통화하기가 좀 힘들었다 

단위테스트 - e2e 테스트는 상관없는데 화면 단위로 작업하니 단위테스트 작성이 힘들다

협업 - 화면 단위로 작업을 분배하는데.. 공통되는 도메인을 작업하는 경우가 있다. ex) 투어 조회 화면과 등록 화면은 투어 도메인을 공유 

상태관리 - 서버 상태와 클라이언트 상태를 한 화면에서 관리하다 보니 관리가 어렵다. 리렌더링 등 성능 이슈도 있고..

 

반면 좋은 점도 있다.

 

협업 및 프로젝트 탐색 - 화면 단위로 개발하면 직관적이다. 프로젝트를 처음 받았을 때 어디에 뭐가 위치하는지 파악하기 쉽다.

빠른 개발 - UI가 계속해서 바뀔 때 유연하게 대처할 수 있다.

 

백엔드에서는 화면 단위로 작업하는게 아니다 보니, DDD 방식으로 깔끔하게 작업할 수 있는데

프론트엔드에서는 화면과 도메인을 함께 작업하다 보니 백엔드와 완전히 동일한 아키텍처는 적용할 수 없다. 

프론트엔드에서도 딱 맞는 깔끔한 아키텍처가 있지 않을까? 

 

클린아키텍처를 프론트엔드에 적용할 방법을 고민하던 중 Feature-Sliced Design 방법론을 접했다. 

(https://feature-sliced.design/)

 

 

 

 

공식 홈페이지에 있는 사진인데.. 그냥 저거만 제대로 이해하면 FSD 잘 쓸 수 있을듯..

 

처음 봤을 때 features와 entities 디렉토리가 어느 부분에서 다른지 헷갈렸다.

 

엔티티는 도메인의 핵심 객체 - User, Tour, Product, Guide

피쳐는 사용자의 행동 - order/create, auth/login, tour/search 

 

이렇게 생각하자. 엔티티는 DDD 에서의 도메인, 피쳐는 도메인으로부터 할 수 있는 행동.

 

이미지에서 app은 최상위에 있고, shared는 하단에 있는데 저건 계층 구조를 의미한다.

 

Layers 하위에는 subdirectory로 Slices가 들어간다. 

Layers 계층에서는 네이밍이 딱 정해져있고 그대로 쓰면 되는데, Slices 계층에서는 네이밍이 정해져 있지 않다. 

그냥 스프링에서 하던 DDD를 떠올리면 편하다. 딱 그거랑 비슷하게 작성됨 

 

 

도메인 규칙 공통화 - entities/*/domain 에 공통 규칙을 묶어두고, features에서 그 규칙을 호출하는 방식으로 해결 

단위테스트 작성 - 규칙은 entities 하위에 묶어뒀으니 이 부분에 대한 테스트만 Vitest로 진행 

협업 - Slices 단위로 업무 분배 -> 투어 도메인 내부의 투어 검색, 투어 등록 등..

상태관리 - 서버 상태는 features/*/app 클라이언트 상태는 features/*/model 에서 따로 관리 

 

 

 

---

 

 

 

FSD 말고도 UI를 더 이상 쪼갤 수 없는 원자 단위까지 분할해서 관리하는 Atomic Design System 방법론도 찾아봤는데

엔터프라이즈 앱을 개발할 때 적합한 아키텍처는 아니라고 생각했다. 

 

shadcn 같은 UI 라이브러리를 만들 때는 굉장히 유용할 것 같은데, 그게 아니라면 FSD 가 더 나을듯 

 

비즈니스 로직을 넣을 위치가 애매해진다. 

컴포넌트가 가지는 공통 속성을 Atom에 넣어야 하는것도 애매하고.. 그렇다고 하위 컴포넌트에 넣자니 중복 코드가 발생하고..

 

그러니 비즈니스 로직이 거의 없는 UI 라이브러리를 만들 때는 Atomic Design System이 좋다고 생각하지만, 일반 애플리케이션을 만들 때는 FSD가 더 좋은 선택이라고 생각함. 

 

 

---

 

 

 

사실 아키텍처라는거는 유지보수하기 좋고, 읽기 쉬운 코드를 작성하기 위한 규칙이기도 하지만 원활한 협업을 위한 규칙이기도 하다.

어떤 아키텍처가 됐든, 팀에서 그 구조를 선택하고 선택한 구조대로 팀원 모두가 개발한다면, 일관적인 프로젝트가 된다. 

 

일관성을 좀 중요하게 생각하는 편이다. 프로젝트의 어떤 곳에는 A처럼 작성하고 또 어떤 곳에는 B처럼 작성하고.. 이런 구조는 읽기 쉬운 코드가 될 수 없다고 생각한다. 

 

그런 의미에서.. 우선 아키텍처라는건 프로젝트를 일관적으로 유지할 수 있도록 도와주는 규칙이기도 하다. 

극단적으로 생각했을 때 공통화를 하나도 적용하지 않고, 서버 상태와 클라이언트 상태를 한 페이지에서 모두 관리하는 아키텍처가 있다고 해도, 팀원들 모두가 그 아키텍처대로 개발한다면 일단 일관된 프로젝트가 완성되기는 하니까.. 

 

우선 아키텍처를 선택하는 중요성은 이정도로 하고.. 이제 좋은 아키텍처를 선택해야 한다.

 

 

 

그동안 프론트엔드 개발을 진행할 때 웬만하면 저런 식으로 프로젝트를 설계했다. 

컴포넌트 / 도메인 / 페이지 / 유틸 

 

이런 식으로 아키텍처를 설계할 때의 단점은 앞에서 말했고.. 그 단점을 깔끔하게 보완할 수 있는 아키텍처가 FSD라고 생각한다. 

FSD는 DDD를 프론트엔드식으로 가장 깔끔하게 처리하는 아키텍처라고 생각한다. 

 

최근에는 플러터로 모바일 애플리케이션을 개발하고 있는데, 웹 애플리케이션과는 다르게 MVVM 아키텍처를 사용하지만 FSD를 플러터에 적합한 아키텍처로 살짝 변형해서 적용하면 좋겠다는 생각이 든다. 

 

새 프로젝트를 진행하거나 기존 프로젝트를 리팩토링 할 때 

모바일 애플리케이션에서 FSD 적용해보기

웹 애플리케이션에서 FSD 적용해보기 

 

둘 다 해 보고 다시 정리해보기로..