[SSAFYcial] 더욱 유연한 프론트엔드 프로젝트를 위한 아키텍처, FSD.

[SSAFYcial] 더욱 유연한 프론트엔드 프로젝트를 위한 아키텍처, FSD.

안녕하세요. SSAFYcial 수료생 기자단 전인혁입니다.

 

저는 SSAFY 9기 교육을 수료하고, 현재는 SSAFY 채용박람회를 통해 취업에 성공하여 프론트엔드 개발자로서의 커리어를 쌓고 있습니다! 현업에 들어와보니 새로 배우는 것도 정말 많고 SSAFY 교육과 프로젝트 과정 속에서 갈고 닦았던 내용들이 자주 등장하기도 합니다.

 

특히나, 프론트엔드의 기술들은 더 빠른 속도로 진화하거나 새로 등장하는 경우가 많은데요. 그렇기에 우리는 개발 트렌드에 맞춰 더더욱 발빠르게 따라갈 수 있어야 합니다! 저의 경우, SSAFY 교육 과정중에 다양한 주제의 프로젝트를 수행하면서, 열정적인 팀원들과 함께할 수 있어 자연스레 새로운 기술들을 찾아볼 기회가 많아졌었고, 그 습관이 자리잡아 지금의 개발 공부 방향에도 큰 영감을 얻고 있답니다 😀 

이번 기사에서는 요즘 제가 큰 관심을 가지고 알아보고 있는 것을 공유드리고자 합니다. 최근 프론트엔드 개발자 사이에서 크게 유행하고 있는 프론트엔드 아키텍처인 FSD(Feature-Sliced Design)를 소개합니다.

프론트엔드 아키텍처란?

단순히 정적인 요소를 보여주던 과거 웹 프론트엔드와는 달리, 현대의 프론트엔드에서는 동적 데이터 처리, 상태 관리, 성능 최적화와 같은 다양한 역할을 수행하며 점점 복잡해지고 있습니다.

프로젝트가 복잡하다는 것이 무슨 뜻일까요?

단순히 코드의 크기가 커지는 것이라고 생각할 수도 있고, 이러한 코드들이 서로 유기적으로 얽혀 서로 의존하게 되어 유지보수와 확장이 어려워짐을 의미하기도 합니다. 따라서 우리는 프론트엔드 프로젝트에서, 단순히 폴더 구조부터 UI(컴포넌트), 비즈니스 로직 등을 체계적으로 설계할 수 있어야합니다.

이를 일련의 원칙 또는 규칙으로 정리한 것이 바로 아키텍처이며, 프론트엔드에서 사용되는 아키텍처를 흔히 프론트엔드 아키텍처라고 표현합니다.

관심사의 분리 (Separation of Concerns, SoC)

프론트엔드 아키텍처를 온전히 이해하려면, 소프트웨어 개발/설계에서의 기본 원칙 중 하나인 관심사의 분리라는 개념을 먼저 이해해야합니다.

관심사의 분리란, 하나의 컴포넌트나 모듈이 단일한 목적에 집중할 수 있도록 역할을 분리하는 설계 원칙을 뜻합니다. 이때, 관심사란 시스템 내에서 특정한 목적을 수행하는 기능 또는 역할을 뜻하는데요, UI 렌더링(컴포넌트), 상태관리, API 호출, 비즈니스 로직 등이 관심사의 예시가 될 수 있습니다.

이러한 관심사를 적절히 분리하여 설계한다면, 코드 간 결합도를 줄여 각 요소가 독립적으로 동작할 수 있게 도울 수 있습니다.

FSD (Feature-Sliced Design)

본격적으로 FSD에 대해 살펴보겠습니다.

이름이 의미하듯, FSD란 기능(Feature) 단위로 프로젝트를 구조화하는 아키텍처 또는 디자인 패턴을 뜻합니다.

일반적인 프론트엔드 프로젝트에서는 화면(페이지) 단위로 프로젝트 구조를 설계하곤 했습니다. 저 또한 대학교와 SSAFY 과정 중 진행한 프로젝트에서도 대부분 페이지 단위로 설계하고 개발을 해왔었는데요,

FSD는 페이지 단위 설계 대신에, 코드들의 규모나 역할에 따라 계층을 나누고, 기능을 의미하는 도메인(주제) 별로 분류하고, 분류된 주제의 코드들을 한데 모아서 관리함으로써 모듈화와 관심사 분리를 달성하는 목표를 가집니다.

FSD 공식 문서에서는 프로젝트 규모에 관계없이 모든 프로젝트에 적용 가능하다고 소개하고 있으며, 규모가 큰 팀이나 프로젝트일수록 FSD 도입으로 얻을 효과는 클 것으로 예상됩니다.

저 또한 SSAFY 때 새로운 디자인 패턴을 적용했던 경험을 살려, 현재 다니고 있는 회사의 신규 프로젝트에서 실제로 FSD를 도입하고 있습니다.

FSD 기본 개념

FSD에서 사용되는 기본 개념을 소개합니다.

이미지 출처 : FSD 공식 문서

레이어

레이어란, 모듈 간 레벨을 정해놓은 것이라고 이해하면 편합니다. 상위 레이어(app)일 수록 레벨이 높다고 생각하면 되고, 상위 레이어에서는 하위 레이어의 요소들을 사용할 수 있습니다. (그 반대는 불가능합니다)

• App Layer : 애플리케이션의 기본 요소들. 라우팅, 진입점, provider와 같은 글로벌 설정.
• Pages : 전체 페이지 또는 실제 페이지를 이루는 주요 부분 (중첩 라우팅일 경우)
• Widgets : 독립적으로 작동하는 재사용 가능한 모듈이나 UI 컴포넌트
• Features : 프로젝트 전반에 걸쳐 사용되는 기능 구현체. 비즈니스 로직이 주가 됨.
• Entities : 프로젝트 전반에 걸쳐 정의된 엔티티 또는 도메인.
• Shared : 공통 유틸리티와 같이 재사용 가능한 기능이나 코드. (단, 비즈니스의 특성과 분리되어 있을 것을 권장)

슬라이스

슬라이스란, 한 레이어 안에서 도메인이나 기능 단위로 코드를 분리하기 위한 하위 디렉토리라고 이해하면 편합니다. 이때 중요한 점은, 특정 슬라이스에서는 다른 슬라이스를 참조할 수 있다는 것입니다. (즉, 각각 다른 슬라이스들은 오직 상위 레이어에서만 합쳐질 수 있습니다.)

세그먼트

세그먼트는 각 레이어 또는 슬라이스 안에서 관심사 별로 코드를 분류한 것입니다. 네이밍을 자유롭게 할 수 있지만, 가급적 다음 이름들 내에서 사용하길 권장하고 있습니다.

• ui : 시각적으로 보여지는 컴포넌트들의 모임
• api : API 통신 모듈(함수)들의 모임
• model : 데이터와 관련된 코드들의 모임 (스키마, 전역스토어, 비즈니스 로직 등)
• lib : 슬라이스 내 다른 모듈이 필요로 하는 라이브러리나 외부 모듈의 모임
• config : 설정 파일들의 모임

실제 적용 예시

프로젝트에 적용 가능한 예시입니다.

영화 카탈로그를 보여주는 서비스를 만든다고 가정했으며, 기존 페이지 기반의 React 프로젝트에서 FSD로 마이그레이션을 한다면 다음과 같이 할 수 있습니다.

기존

src/
├── components/
│   ├── MovieCard.jsx
│   ├── CatalogList.jsx
│   └── ...
│
├── pages/
│   ├── MoviePage.jsx
│   └── ...
│
├── api/
│   └── favoritesApi.js
│
├── utils/
│   └── apiUtils.js
│
├── App.js
├── index.js
└── globalStyles.js

FSD

상기 언급한 레이어, 슬라이스, 세그먼트에 대한 개념을 한번 더 떠올려보면 이해가 더욱 편해집니다.

src/
├── app/
│   ├── Provider.js
│   ├── GlobalStyle.js
│   └── ...
│
├── pages/
│   └── movie/
│       ├── api / index.js
│       ├── model / index.js
│       ├── ui / MoviePage.jsx
│       └── ...
│
├── widgets/
│   └── catalog/
│       ├── api / index.js
│       ├── model / index.js
│       ├── ui / CatalogList.jsx
│       └── ...
│
├── features/
│   ├── favorites/
│   │   ├── api / index.js
│   │   ├── store / index.js
│   │   └── ...
│   └── ...
│
├── entities/
│   ├── movie/
│       ├── ui / MovieItem.jsx
│       └── model / index.js
│
├── shared/
│   └── utils/
│       └── apiUtils.js
│
├── App.js
├── index.js
└── globalStyles.js

아니, 더 복잡해 지는거 같은데...?

FSD를 적용하는 구조가 기존의 페이지 기반 설계에 비해 복잡해 보일 수 있으며, 실제로 작은 프로젝트에서는 Page 기반의 구조만으로도 충분할 수도 있스빈다. 하지만, 프로젝트가 커질수록, 그리고 유지보수를 오래 해야하는 입장이라면 그 효과는 더욱 확실하게 나타납니다.

프로젝트 규모가 커지고 도메인이 많아져 복잡해지거나, 여러 명의 개발자가 동시에 작업을 해야 할때 FSD를 적용한다면 각자의 작업 영역을 명확히 분리하고 코드 및 모듈 간 의존성을 줄이는 데 크게 도움이 될 수 있습니다. 기능 단위로 코드가 체계적으로 나누어져 있기 때문에, 새로운 기능을 추가하거나 기존 기능을 수정하더라도 다른 부분에 미치는 영향을 최소화 할 수 있습니다.

마무리

FSD 뿐만 아니라 무언가 새로운 기술이나 방법론을 적용하는 일은 누군가에게는 흥미롭고 효율적인 작업이 될 수 있지만, 프로젝트 구성원들 모두가 동의하고 호의롭게 받아들여, 온전히 녹아들 수 있어야 더윽 효과적일 수 있다고 생각합니다. 이러한 부분만 잘 설득이 되어 함께 효용을 따져본다면, 새로운 기술과 아키텍처 도움은 실보다는 득이 더 클 가능성이 높을 것입니다.

SSAFY 교육 과정 중, 컴포넌트를 원자 단위로 쪼개는 방식의 디자인 패턴인 아토믹 패턴을 적용해본적이 있었습니다. 디자인 패턴을 도입하여 디버깅과 유지보수에 용이한 프로젝트를 만들자는 목표가 팀원들과 일치해서 수월하게 프로젝트를 수행했었습니다. 제가 제안했었지만, 저 또한 아토믹 패턴에 금시초문이었기에 사례에 대한 학습이 많이 필요했던 찰나, SSAFY에서 마음 맞는 교육생들과 스터디했던 기억이 납니다.

SSAFY라는 좋은 프로젝트의 장에서 했던 경험들은 취업하여 프론트엔드 개발자로 일하고 있는 지금까지도 긍정적인 영향을 미쳐서, 현재 회사의 신규 프로젝트에 FSD를 도입할 때에도 어떤식으로 팀원들과 함께 합을 맞춰나갈지 결정하는데에 도움이 되고 있답니다!

읽어주셔서 감사합니다 🙏

이번 기사가 현재 SSAFY 교육생 이거나, SSAFY에 관심이 있으신 분들에게 많은 도움이 되었으면 좋겠습니다.

궁금하신 점이 있다면, 댓글로 꼭! 꼭! 남겨주세요 🙏🏻

---

" 유용한 정보만을 전하겠습니다 :) "

 

SSAFY 공식 홈페이지

SSAFYcial 기자단 공식 SNS