들어가며
프론트엔드 개발을 진행하면서 아키텍처를 설계하는데에 있어서 많은 관심을 가져본 적이 없었습니다. 때문에 매번 새로운 폴더구조를 시도를 해보았고 명확한 구분이 없다는 것을 느꼈습니다. 이는 프로젝트를 진행하는데에 있어서 의도와 달리 잘못 설계한 것이 아닐까? 라는 생각이 들었습니다.
해당 글은 폴더 아키텍처가 무엇인지에 대해 설명하고 FSD 아키텍처가 무엇인지 기존에 아키텍처들과는 무엇이 다른지에 대해 설명합니다.
🗂️폴더 아키텍처 (Folder-Architecture)
폴더 아키텍처는 소프트웨어 프로젝트에서 파일과 폴더의 구성을 조직화하는 방법을 말합니다. 이는 개발자들이 프로젝트의 파일을 효율적으로 관리하고, 코드의 가독성과 유지보수성을 높이는 데 도움을 줍니다.
폴더 아키텍처의 기본 원리
모듈화: 각 기능별로 모듈화를 하여, 애플리케이션을 더 작은 부분(모듈)으로 세분화 합니다. 이 때, 각 모듈은 다른 부분들로부터 독립적으로 유지될 수 있어야 합니다.
계층화: 다양한 계층을 정의하여 파일과 폴더를 그룹화 합니다.
폴더 아키텍처를 이용하는 것은 많은 장점들을 만들어냅니다. 이러한 장점들은 프로젝트의 규모가 커지고 함께 작업을 하는 사람들이 많아지면서 해당 프로젝트를 조직화 하는동안 경험할 수 있습니다.
폴더 아키텍처로 인해 얻을 수 있는 장점
가독성 향상: 폴더 및 파일 구조화를 통해 프로젝트의 가독성이 향상됩니다. 구조를 쉽게 이해하고, 필요한 부분을 빠르게 찾아낼 수 있습니다.
재사용성 증가: 모듈화 된 컴포넌트를 통해 재사용성이 높은 코드를 구현할 수 있습니다.
유지보수성 개선: 체계화 된 폴더구조는 프로젝트의 유지보수성을 크게 개선합니다. 이는 코드 변경에 따른 영향을 최소화하며, 오류 수정과 기능 추가등을 용이하게 합니다.
폴더 아키텍처로 인해 생길 수 있는 문제점
그렇다고 해서 폴더 아키텍처를 사용하는 것이 꼭 좋은 것만은 아닙니다. 여러가지를 생각해보아야 합니다.
과도한 세분화: 프로젝트의 규모가 작다면 폴더 구조를 유연하게 잡아가는 것도 좋습니다. 과도하게 세분화를 할 경우 구조가 복잡해져 이해를 하는데에 있어서 어려울 수 있습니다.
협업 문제: 폴더 구조에 대한 이해도나 선호도가 다를 경우, 협업 중에 의사소통 문제나 혼란이 발생할 수도 있습니다.
범용성의 부재: 특정 프로젝트나 개발 환경에 맞춰진 폴더 구조가 다른 상황이나 요구사항에 적합하지 않을 수도 있습니다.
FSD (Feature-Sliced Design)
FSD 아키텍처란?
FSD( Feature-Sliced Design)는 프런트엔드 애플리케이션을 위한 아키텍처 방법론입니다. 간단히 말해 코드 구성에 대한 규칙과 규칙을 모아놓은 것입니다. 이 방법론의 주요 목적은 끊임없이 변화하는 비즈니스 요구 사항에 직면하여 프로젝트를 보다 이해하기 쉽고 구조화하는 것입니다. FSD 문서
Feature-Sliced Design (FSD)은 프론트엔드 애플리케이션의 구조를 설계할 때 사용되는 방법론입니다. 비즈니스 로직의 명확한 분리, 적응성, 기술 부채 및 리팩토링 용이성 그리고 코드 재사용의 명확성을 강조합니다.
FSD는 DRY(Don't Repeat Yourself) 원칙과 로컬 커스터마이징 사이의 균형을 유지하는 것에 중점을 둡니다.
DRY 원칙: 같은 코드를 반복하지 않고 재사용을 극대화하는 것
로컬 커스터마이징: 각 특정 기능이나 컴포넌트의 요구사항에 따라 코드를 맞춤 설정하는 것
각각의 규칙은 각각 장단점을 가지고 있기 때문에 너무 재사용 신경을 쓸 경우 유연성이 저하될 수 있으며 과도한 로컬 커스터 마이징은 코드의 중복을 증가시킬 수 있고, 유지보수를 어렵게 만들 수 있습니다.
FSD 아키텍처를 적용하기 위해서는 해당 아키텍처만의 룰(rules)을 지켜야만 합니다.
첫번째 룰
애플리케이션 레이어(layers), 슬라이스(slices), 세그먼트(segments)의 세가지 개념을 구분해주어야 합니다.
레이어 (Layers)
레이어는 최상위 디렉토리이자 애플리케이션 분해의 첫 번째 단계를 말합니다. 수는 7개로 되어있습니다.
또한 각각의 레이어들은 feature-sliced 이름에 걸맞게 각각의 기능을 가지고 있습니다.
각 레이어들은 다음의 기능들을 담당합니다.
app: 애플리케이션의 최상위 로직이 초기화되는 곳을 말합니다. provider. router, global styles, global types 선언등이 여기에서 정의됩니다.
process: 여러 단계 플로우(예: 회원가입 절차)를 관리하는 복수의 페이지로 구성되어 있습니다.
pages: 사용자에게 제공되는 전체 뷰를 나타내는 실제 페이지들을 정의합니다
widgets: 페이지 내 사용되는 독립적인 컴포넌트입니다. 기능(features)과 연결되거나 데이터 객체(entities)를 다룹니다.
features: 애플리케이션의 핵심 비즈니스 로직을 담당합니다. ex: 로그인, 로그아웃, 버튼을 눌렀을 때의 동
entities: 애플리케이션의 비즈니스 객체나 도메인 모델(사용자, 리뷰 등)을 정의합니다.
shared: 전반적으로 재사용되는 컴포넌트, 유틸리티, UI 컴포넌트 등을 포함합니다.
이러한 레이어들은 코드베이스를 모듈화, 캡슐화하여 유지보수 용이한 확장 가능한 아키텍처를 설계하는데에 있어서 도움을 줍니다.
FSD 아키텍처에는 기능 분할 설계의 주요 특징 중 하나로 계층 구조도 있습니다.
아래 단계에서는 윗 단계를 참조할 수 없다는 특징이 있습니다. 이는 한방향으로만 향하는 선형적인 흐름을 유지하기 위함입니다.
계층 구조에서 레이어의 위치가 낮을수록 코드의 더 많은 곳에서 사용될 가능성이 높기 때문에, 레이어를 변경하는 것이 더 위험합니다. 예를 들어 shared 레이어의 UI 키트는 features, widgets, 심지어 pages 레이어에서도 사용됩니다.
슬라이스 (Slices)
각 레이어별로 애플리케이션의 두번째 분해요소인 슬라이스를 하위 폴더로 가지고 있습니다. 슬라이스의 주요 목표는 코드를 값별로 그룹화하는 것을 말합니다.
레이어와 달리 슬라이스의 이름은 프로젝트의 비즈니스 영역에 따라 직접 결정이 되므로 표준화되어 있지는 않습니다.
예를 들어 youtube의 경우 동영상, 숏츠, 실시간 영상 등과 같은 섹션으로 분리할 수 있습니다.
각 폴더의 파일들은 직접적으로 공유되지는 말아야하는 규칙도 있습니다.
세그먼트 (Segments)
마지막 분해요소인 세그먼트는 목적에 따라 슬라이스 내의 코드를 나누는데 도움이 됩니다. 이또한 슬라이스와 마찬가지로 이름이 변경될 수 있으며 구성또한 변경이 될 수 이습니다.
일반적으로 사용되는 세그먼트들을 다음과 같습니다.
api - 필요한 서버 요청.
UI - 슬라이스의 UI 컴포넌트.
model - 비즈니스 로직, 즉 상태와의 상호 작용. actions 및 selectors가 이에 해당
lib - 슬라이스 내에서 사용되는 보조 기능.
config - 슬라이스에 필요한 구성값이지만 구성 세그먼트는 거의 필요하지 않음.
const - 필요한 상수.
두 번째 룰
공개 API
각 슬라이스와 세그먼트에는 공개 API가 있습니다. 공개 API는 index.js 또는 index.ts 파일이며, 이 파일을 통해 슬라이스 또는 세그먼트에서 필요한 기능만 외부로 추출하고 불필요한 기능은 격리할 수 있습니다. 인덱스 파일은 진입점 역할을 합니다.
공개 API는 import 및 export로 단순하게 작동하므로 애플리케이션을 변경할 때 코드의 모든 곳에서 import를 변경할 필요가 없습니다.
배럴 파일은 특정 디렉토리 내에 있는 여러 모듈이나 파일을 하나의 진입점을 통하여 외부로 내보내는 파일을 얘기합니다. 이를 통하여 코드의 재사용성을 높이고 개별적으로 import를 하는 것이 아닌 필요한 모듈을 편리하게 불러올 수 있습니다.
이를 각각의 슬라이스와 세그먼트에서 사용함으로서 각각의 필요한 기능만 외부로 추출하고 불필요한 기능은 격리할 수 있습니다.
이처럼 FSD 아키텍처를 사용하기 위해서는 Layer, Slice, Segment 단위로 분류를 하고 배럴파일과 비슷한 공개 API 파일을 사용하는 것을 알았습니다.
아키텍처에 대해 자세히 알아보기
추상화 및 비즈니스 로직
계층이 높은 레이어일수록 특정 비즈니스 노드에 더 많이 종속되고 더 많은 비즈니스 로직이 포함됩니다. 계층이 낮은 레이어일수록 추상화 수준이 높고 재사용성이 높으며 레이어 자체의 자율성이 적습니다.
추상화 및 비즈니스 로직
해당 특징은 FSD가 문제를 해결하는 방식에서 볼 수 있습니다.
기능 분할 설계의 과제 중 하나는 결합을 느슨하게 하고 응집력을 높이는데에 있습니다.
객체지향관점에서는 다형성, 캡슐화, 상속 및 추상화와 같은 개념을 통해 이러한 문제들을 오랜 시간 동안 해결 해왔습니다. 이러한 개념들은 코드의 격리, 재사용성, 그리고 다양한 결과를 보장합니다.
FSD(기능 분할 설계)는 이러한 문제를 프론트엔드에서 적용하는데에 도움을 줍니다.
- 추상화 다형성의 문제: 레이어를 통해 풀이를 하였습니다. 낮은 레이어의 경우 더 추상화가 되어있기 때문에 높은 레이어에서 재사용할 수 있으며, 특정한 매개변수나 속성에 따라 컴포넌트나 기능이 다르게 작동할 수 있습니다.
- 캡슐화: 슬라이스와 세그먼트 외부에서 필요하지 않을 것을 격리시키는 공개 API를 통해 달성됩니다. 슬라이스 내부 세그먼트에 대한 접근은 제외됩니다. 공개 API를 통하여 슬라이스 또는 세그먼트의 기능 및 컴포넌트에 접근할 수 있는 유일한 방법입니다.
- 상속: 레이어를 통해 해결합니다. 더 높은 레이어는 낮은 레이어를 재사용 할 수 있습니다.
고전적인 아키텍처 특징
고전적인 아키텍처들은 사용했다면 다음과 같은 구조들을 많이 사용했을 것입니다.
커스텀 훅(custom hook) 구조
/src
/components (모든 페이지에서 공용으로 사용되는 컴포넌트)
/ utils (모듈화한 함수들)
/ consts (상수 *문자)
/ styles (전역 스타일링)
/ pages (모든 컴포넌트들이 합쳐져서 하나의 페이지를 이룬다. *종착점)
/ routes
/ hooks
/ store
app.js아토믹(atomic) 구조
/src
/ ui
/ atoms (원자)
Button.js
Input.js
/ molecules (분자)
Searchbar.js
/ organisms (유기체)
menu.js
/ templates (템플릿)
header.js
/ pages (페이지)
이글은 고전적인 아키텍처들이 잘못되었다는 것이 아닙니다. 여기서 말하고 싶은 것은 FSD 아키텍처를 왜 사용하는지에 대해 작성하는 글입니다.
고전적인 아키텍처(클래식 아키텍처)와 Feature-Sliced Design (FSD)은 각각의 장단점을 가지고 있습니다. 점점 복잡해지는 프로젝트의 요구사항을 수용하기 위해, 개발 프로세스에서 아키텍처의 역할은 매우 중요합니다.
고전적인 아키텍처의 한계
새로운 아키텍처들이 나오는데에는 고전적인 아키텍처들의 한계점과 개선 방향이 느껴지기 때문에 여러 개발자들이 생각했다고 여겨집니다.
-
유지 관리의 어려움: 프로젝트가 발전함에 따라, 구성 요소와 모듈 사이의 암묵적인 연결 때문에 유지 관리가 점점 더 어려워집니다.
-
복잡성 증가: 시간이 지남에 따라 애플리케이션 아키텍처는 점점 더 복잡해지며, 해결하기 어려운 혼란의 정도가 증가합니다.
이러한 단점들 때문에 규모가 작고 유지보수가 필요하지 않은 경우 고전적인 아키텍처가 더 효율적입니다. 하지만 유지보수를 해야하는 복잡한 프로젝트의 경우 FSD 아키텍처가 더 효과적일 수 있습니다.
FSD 아키텍처 경험해보기
해당 사이트를 들어가면 어떤식으로 폴더를 분리하여 진행하였는지 더욱 자세히 볼 수 있습니다.
Nuke App 🦄⚛️
프로젝트 사용예시
결론
기능 분할 설계를 사용해도되고 고전적인 아키텍처 방식을 선택해도 됩니다. 하지만 이후에 있을 유지보수와 확장가능성을 고려하여 기능 분할 설계로 개발을 진행해보는 것은 어떨까요?
자료 출처
