고민보단 실천을

React·Next.js FSD 폴더 구조 템플릿: app/pages/widgets/features/entities/sharedFSD는 폴더를 예쁘게 나누는 기법이 아니라 의존성 흐름을 제어하는 방식이다. React와 Next.js 프로젝트에서 공통으로 쓰기 좋은 기본 템플릿을 먼저 고정하면 팀 생산성이 안정된다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)ap..

FSD 상태관리 배치 전략: 전역 상태를 어디에 두고 어디까지 분리할 것인가상태관리 복잡도는 기능 확장 속도를 직접 좌우한다. FSD에서는 상태를 레이어 책임에 맞춰 배치해 전역 오염과 과도한 결합을 방지한다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)app state전역 테마/세션/초기 설정앱 전반에 공통으로 필요한 상태를 관리할 때feature state특..

FSD 패턴 입문: Layer·Slice·Segment 구조를 실무에서 적용하는 방법FSD(Feature-Sliced Design)는 프론트엔드 코드를 비즈니스 책임 기준으로 분할하는 아키텍처 패턴이다. 규모가 커진 React 프로젝트에서 파일 위치 기준이 흔들릴 때 특히 효과가 크다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)Layer애플리케이션의 큰 책임 ..

FSD 마이그레이션 가이드: 기존 프론트엔드 구조를 단계적으로 전환하는 순서기존 프로젝트를 한 번에 FSD로 재구성하면 리스크가 크다. 기능 단위로 경계를 만들고 import 규칙을 강화하는 점진 전환이 현실적이다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)Step 1현재 구조 의존성 진단순환 참조와 공통 모듈 과밀 구간을 식별할 때Step 2shared/ui..

FSD 안티패턴 정리: shared 비대화·순환 의존·feature 경계 붕괴 해결법FSD를 도입해도 규칙을 지키지 않으면 shared 쓰레기통화, 레이어 역참조, 기능 경계 붕괴가 발생한다. 안티패턴을 조기 탐지하는 운영 규칙이 중요하다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)Shared 비대화모든 코드를 shared로 몰아넣는 현상빠른 개발 명목으로 경..

Atomic Design vs FSD 비교: UI 계층과 도메인 계층을 함께 설계하는 기준Atomic Design은 UI 재사용성 중심, FSD는 비즈니스 책임 분리 중심이라는 차이가 있다. 실무에서는 둘 중 하나를 버리기보다 서로 다른 축으로 결합하는 방식이 효과적이다. 검색 유입이 많은 키워드(폴더 구조, 마이그레이션, 안티패턴, 상태관리)를 기준으로 실무 적용 포인트를 정리했다.FSD 공식 사이트 참조 이미지 (출처: feature-sliced.design)핵심 개념실무에서 먼저 결정할 기준이 주제는 코드 배치 기준을 먼저 정하고, 이후 네이밍과 import 경계를 린트로 고정하는 순서가 가장 안정적이다.핵심 요소 3~6개항목의미언제 쓰는지(실무 상황)Atomic DesignUI 조합 규칙(Atom..

들어가기 앞서 mock API는 꼭 테스트를 위해서만 사용하는 건 아닙니다. API 명세서가 작성되어 있다면 서버가 완성되기 이전 프론트 단에서 개발을 진행할 때 유용하게 사용할 수 있습니다. 이점은 인지하고 넘어가도록 하겠습니다. mock API를 사용하여 리액트 테스트코드 작성하기 이번에는 mock API를 이용하여 테스트하는 방법에 대해 정리해보도록 하겠습니다. 사실 실제 서비스에 연결된 API를 사용하여 테스트 할 수 있습니다. 그렇게 된다면 API 통신까지 테스트를 할 수 있으니 안정성은 더 올라갈 것으로 생각되지만, API 통신 즉 서버가 정상 동작하는건 서버단에서 테스트를 해야할 사항이지 프론트단에서 꼭 테스트할 필요는 없다고 생각됩니다. 그리고 mock API를 사용할 경우 여러 장점이 있..

아래 포스트를 읽기 전 Jest와 React Testing Library에 대해 이해가 없다면 이전 글을 보고 오시는 것을 추천드립니다. 비동기 작업을 고려하여 테스트 코드를 작성해야 하는 이유 개발을 하다 보면 비동기 작업을 하는 경우가 많습니다. Click, 렌더링 등에 이벤트가 발생했을 때 특정 로직을 수행하도록 코드를 작성한 경험이 많을 겁니다. 또 로직을 즉시 실행할 수도 있지만 의도적으로 특정 시간 이후 실행되도록 한 경험도 있을 것이라 생각합니다. 간단한 예로 렌더링 된 후 2초가 지났을 때 화면에 title이 “Load”에서 “Finish”로 변경되는 화면이 있다고 합시다. 이 화면에 테스트 코드를 단순히 render후 Finish text를 찾는다면 에러가 발생합니다. 당연하죠. 변경하기..

이 글은 벨로퍼트와 함께하는 리액트 테스팅을 참고하여 작성했습니다. 혹시 Jest나 React Testing Library가 처음이라면 이전 포스트를 한번 읽고 보시는 것도 이해에 도움이 됩니다. 물론 보지 않으셔도 이해할 수 있습니다. React Testing Library를 이용하여 Todo List 만들기 들어가기 앞서 기반이 되는 벨로퍼트와 함께하는 리액트 테스팅에서는 yarn add react-testing-library jest-dom @types/jest를 사용하고 있습니다. 현재는 라이브러리 이름이 변경되어 react-testing-library가 아닌 @testing-library/react를 사용하고 있습니다. 제가 이 글에서 사용한 라이브러리는 @testing-library/react..