오늘의상상

FSD 아키텍처 - 기능 분할 설계

o-osang — Sat, 24 Jan 2026 17:30:02 +0900

FSD 공식 문서 이미지

개요
1. 정의: 대규모 프론트엔드 애플리케이션의 구조를 잡기 위한 아키텍처 방법론
2. 목적: 애플리케이션을 기능 단위로 분할하여 프로젝트를 더 이해하기 쉽고 구조적으로 만들어, 프로젝트의 규모가 커져도 유지보수에 유리하도록 함
구조
- 레이어의 이름은 제한적, 슬라이스와 세그먼트의 이름은 자유
- 슬라이스는 보통 비즈니스 도메인별로 분리하며 세그먼트는 보통 관례적인 이름 사용
- Layers
  - Slices
    - Segments
Layer
- 프로젝트를 최상위부터 가장 기본적인 요소까지 단계적으로 나눈 폴더로 첫 번째 수준의 계층 구조
- app, processes, pages, widgets, features, entities, shared의 7개로 구성
- 현재는 processes 제외 6개의 레이어만 사용됨
1. app: 애플리케이션 전체의 전역 설정만 담당하며 슬라이스가 없고 세그먼트만 가짐
  - 라우팅, 전역 스타일, 테마 설정 등
2. progesses: 페이지 간 복잡한 시나리오나 워크플로 관리
  - 현재는 복잡성, 중복성의 문제로 사용하지 않음
3. pages: 앱 내 개별 페이지 정의, 사용자 인터페이스와 관련된 로직 처리
4. widgets: 페이지 내 독립적으로 작동하는 큰 기능 단위. 검색 바, 대시보드, 사이드바 메뉴 등이 해당함
5. Features: 재사용 가능한 비즈니스 기능을 위함, 독립적으로 동작할 수 있는 하나의 특정 동작을 정의함
  - 다양한 페이지와 위젯에서 사용할 수 있도록 기능을 추상화하는 레이어
6. Entities: 프로젝트에서 다루는 비즈니스의 핵심 데이터를 나타내는 레이어
  - 주로 데이터 모델과 해당 데이터에 대한 로직이 포함됨
7. Shared: 프로젝트 전반에서 재사용할 수 있는 유틸리티, 기본적인 컴포넌트, 스타일 등의 전반적인 리소스를 포함하는 레이어, 슬라이스가 없고 세그먼트만 가짐
  - Button 컴포넌트 등
레이어 참조 규칙
- 단방향 의존성: 상위 레이어는 하위 레이어만 참조하며, 레이어 간 수직적 위계와 독립성을 엄격히 보장함
- 하위 레이어 참조 제한으로 규칙 확산을 방지하며 계층 간 결합도를 낮추고 모듈의 응집도를 강화함
Slice
- 애플리케이션을 비즈니스 도메인별로 코드를 분리하는 두 번째 수준의 계층 구조
- 특정 비즈니스 엔티티에 대한 코드를 묶음
- 사진 갤러리 프로젝트는 사진, 앨범, 갤러리
- 소셜 네트워크 프로젝트는 게시물, 사용자, 뉴스피드
슬라이스의 독립성 유지
- 같은 레이어 안에서 다른 슬라이스를 참조할 수 없고 필요 시 하위 레이어의 공통 요소들만 참조 가능
- 높은 응집도와 낮은 결합도를 갖기 위함
  - 슬라이스는 독립적으로 관리될 수 있으며 도메인에 집중
  - 슬라이스 간 종속성 최소화
Segment
- 기능별로 분리된 세그먼트들이 존재하여 각각의 세부 기능을 담당하는 세 번째 수준의 계층 구조
- 이름을 제한하지 않지만, 관례적인 이름 사용, 아래는 User 슬라이스의 세그먼트 예시
- model
  - 상태 관리 및 비즈니스 로직을 포함하여, 사용자 정보나 팔로우 상태와 같은 데이터 저장 및 관리
- ui
  - 사용자 인터페이스를 구성하는 컴포넌트를 포함하여, 사용자 정보 조회 화면 등의 UI 요소 제공
- api
  - 서버와의 데이터 교환을 위한 API 요청 코드를 포함하여 백엔드와 데이터를 주고받는 역할
- lib
  - 유틸리티 함수나 헬퍼 함수와 같이 해당 도메인에서 반복적으로 사용되는 기능 제공
공개 API 정의 규칙
- 각 모듈이 외부에서 사용할 수 있는 것을 명확하게 선언하는 역할
- index.js 파일을 만들어 외부에 공개할 파일이나 함수를 다시 내보냄
- 외부에서는 index.js만 사용하므로 슬라이스 안의 코드를 직접 알 필요가 없음
- 슬라이스가 없다면 세그먼트별 공개 API 정의, 슬라이스가 있다면 해당 슬라이스의 공개 API 정의

참고

https://feature-sliced.design/docs/get-started/overview

https://velog.io/@clydehan/FSDFeature-Sliced-Design-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C

React 내장 Hooks

o-osang — Mon, 25 Aug 2025 20:50:52 +0900

Hooks의 종류

- useState

- useEffect

- useCallback

- useMemo, useContext, useRef, useLayoutEffect...

useState

컴포넌트의 state를 생성하는 훅

배열을 리턴하며, 첫 번째 요소는 state 값, 두 번째 요소는 해당 state를 set해주는 setter 함수

인자로 넘겨주는 값은 state의 초기값

useEffect

컴포넌트가 렌더링 될 때 현재 상태 변화에 따라 조건적으로 특정 작업을 실행하는 훅

클린업 함수: 컴포넌트가 언마운트 될 때 및 의존성 배열에 포함된 값이 변화할 때 실행되는 함수,

컴포넌트가 사용했던 자원을 제거 ex) 타이머, 인터벌, 이벤트, 객체 등

useCallback

성능 최적화를 위한 훅

이전 렌더링에 생성한 함수를 기억해서 기존 함수를 재활용 > 메모이제이션

useCallback 예제

const increaseValue = () => {
	setValue(value + 1);
};

const resetValue = useCallback(() => {
	setValue(0);
}, []);

1. increaseValue는 useCallback을 사용 시 value 값이 0인 상태로 고정되기에 사용하지 않음

2. resetValue는 현재 value의 값과 상관없이 0으로 만들기 때문에 렌더링마다 함수를 생성할 필요가 없어 useCallback을 사용함

주의사항

1. Hooks는 조건적으로 사용하지 말 것, Hooks는 배열로 관리되기 때문에 건너뛰면 서로 충돌

2. 함수형 컴포넌트나 커스텀 훅의 최상위에서만 호출해야 함

개발 블로그 플랫폼 정하기

o-osang — Sat, 22 Jun 2024 14:22:52 +0900

무슨 플랫폼이 있나 찾아보기

개발 블로그를 시작해야지 하고 여러 블로그들을 돌아다니며 정보를 얻었다.

대부분 개발자 분들은 github, velog, 티스토리를 많이 쓰는 것 같았다. 나머진 마이너하거나 내 취향이 아니라 패스

각각의 장단점은 다음과 같았다.

github

장점이자 단점

높은 자유도: HTML/CSS/JavaScript 지식으로 처음부터 끝까지 구현해야 한다.

단점

수익화 어려움: 수익화를 직접 구현해야 한다.

불편한 이미지 업로드: 이미지를 레포지토리에 업로드 후 가져오거나 경로를 업로드해야 한다.

깃허브 페이지는 애초에 생각하고 있던 플랫폼이 아니었기에 설명이 적다.

그 외의 장점으로 정적 사이트 생성기 (Jekyll 등) 를 지원한다거나 Git을 통한 버전 관리가 있는데 크게 와닿는 장점이 아니었다.

velog

장점

간편한 사용: Markdown 기반으로 글 작성이 쉬워 초보자도 사용하기 좋다.

개발자 친화적: 개발 관련 글을 쓰기에 최적화되어 있다.

단점

커스터마이징 제한: 디자인 커스터마이징 제한으로 글이 다들 비슷해 보인다.(내 생각이다)

부실한 통계 기능: 통계 기능이 부실하다. 유입 경로 제공 x

수익화 어려움: 플랫폼 자체적으로 수익화를 지원하지 않는다.

티스토리

장점

편리한 관리: 블로그 관리 기능을 제공한다. 티스토리로 정하고 써보니까 편한 것 같다.

디자인 커스터미이징: 스킨과 플러그인을 통해 맞춤 설정 가능하다.

수익화 가능: 수익화도 쉽게 지원한다.

단점

초기 설정: 스킨을 적용해도 초기에 설정할 게 많은 것 같다.

마크다운 에디터: 마크다운 에디터가 있기는 한데 별도의 에디터로 구분되어 있고,

미리보기를 지원하지 않는다.*

* 미리보기가 없는 줄 알았는데 왼쪽 아래에 있었다. 에디터 전환 시 자꾸 기본 서식으로 돌아가는데 이거 불편하다.

결론

티스토리를 통해 개발 블로그를 시작하기로 결정했다.

가장 큰 이유는 통계 기능이 잘 되어 있기 때문이다. 유입 경로 및 상세 통계를 알 수 있으면 사람들이 더 많이 찾는 블로그를 만들 수 있을 것이라고 생각한다.

블로그를 시작하는 김에 스킨도 적용했다. 정상우 개발자님의 hELLO라는 스킨인데 왼쪽 사이드바 스킨을 찾다가 발견했다. 커스터마이징은 추후에 하는 것으로 하고 프로젝트에 관한 포스팅을 올릴 예정이다.