폴더 구조 개선 : FSD 아키텍처 적용 검토

[chae-dahee]

📌 개요

현재 프로젝트는 레이어드 아키텍처 기반으로 구성되어 있으며, 기능 흐름 파악 및 유지보수 측면에서 다음과 같은 한계가 있습니다. 이를 개선하기 위해 기능 단위 구조(FSD: Feature-Sliced Design) 적용을 제안드립니다.

❗ 문제 인식

• 레이어 + 기능 분산: 하나의 기능이 components, pages, queries, mutations, types, constants 등 여러 위치에 흩어져 있음.
• 중복 구조: 동일한 기능명으로 폴더가 반복됨 → 구조적 중복 및 경로 탐색 비용 증가
• 탐색성 저하: 기능 관련 로직을 파악하기 위해 여러 디렉토리를 이동해야 함
• 범위 혼동: 특정 컴포넌트 내부에서만 사용하는 utils, constants 와 전역영역의 직관적인 구분이 필요함.

구조 개선을 통해 명확한 책임 경계 설정, 중복 제거, 탐색 비용 최소화가 필요한 상황입니다.

💡 FSD 적용

기능 단위로 디렉토리를 구성하고, 각 기능 내부에 UI, API, 상태, 타입, 유틸 등 관련 코드를 응집시킵니다.

• 기존 구조에서 반복되던 기능명 폴더 제거
• 각 기능이 독립적으로 유지·확장 가능
• 디렉토리 구조만으로도 기능 단위 로직 파악 가능

이미 기능별 책임이 나뉘어 있어, FSD로의 전환 시 진입 장벽이 낮고 구조 정리에 효과적입니다.

또한 현재 신규 기능 추가 및 핫픽스 빈도가 낮은 안정적 운영 환경이므로, 구조 전환에 따른 운영 리스크는 매우 낮습니다.

✅ FSD 아키텍처의 이점

• 기능 응집도 증가: 하나의 폴더에서 해당 기능의 UI, API, 타입, 상태 관리까지 확인 가능
• 로직 흐름 파악 용이: 기능 단위 변경/추적 시 필요한 경로가 줄어듦.
• 디렉토리 중복 제거: 폴더 경로의 명확성과 일관성 확보
• 협업 효율 상승: 코드 탐색 비용 감소, 기능별 책임 범위 뚜렷해짐
• 공통 컴포넌트 체계화: shared 폴더에 Atomic Design 패턴 적용을 통해 Button, Input 등 공통 UI를 명확히 계층화
• 디자인 시스템 문서화 용이: Storybook을 활용한 시각적 문서화 및 단일 진입점 제공 → 비개발자 협업 효율 증가

🛠️ 구조 비교 예시

기존 구조 (레이어 기반)

📦 src  
 ┣ 📂components/auth  
 ┣ 📂pages/auth  
 ┣ 📂api/auth
 ┣ 📂state/queries/auth  
 ┣ 📂state/mutations/auth  
 ┣ 📂types/auth  

개선 구조 (FSD 기반)

├── features/
│   └── AddTodo/
│       ├── ui/              # Form, Button 등
│       ├── model/           # createTodo mutation, state
│       ├── api/             # POST /todos
│       └── index.ts
│
│   └── UpdateTodo/
│       ├── ui/              # inline edit 컴포넌트
│       ├── model/           # updateTodo mutation
│       ├── api/             # PUT /todos/:id
│       └── index.ts
│
│   └── DeleteTodo/
│       ├── ui/              # 삭제 버튼
│       ├── model/           # deleteTodo mutation
│       ├── api/             # DELETE /todos/:id
│       └── index.ts
│
├── entities/
│   └── Todo/
│       ├── model/           # react-query useTodos()
│       ├── api/             # GET /todos
│       ├── types/           # Todo 타입 정의
│       └── index.ts

👉 같은 책임이 명확히 구분되어 있는 상태이므로 FSD 전환 시 진입 장벽이 낮고, 팀원 간 혼란도 적을 것으로 판단됩니다.

🔄 기존 구조 vs 개선 구조(FSD) 비교

항목	기존 구조 (레이어드)	개선 구조 (FSD)
구성 기준	레이어 중심 (관심사)	기능 중심
디렉토리 위치	기능별 로직이 여러 레이어에 분산	기능별 폴더에 관련 로직 응집
중복도	pages/onboarding, components/onboarding, state/queries/onboarding, state/mutation/onboarding 등 중복 경로	features/onboarding 내 모든 기능 포함
탐색성	기능 추적 시 경로 전환 다수 필요	기능 단위로 로직이 모여 있어 탐색 용이
유지보수	로직 추가/변경 시 여러 레이어 이동, 수정	기능 단위 폴더 내에서 명확히 작업 관리

⚠ 4. 예상 Trade-off 및 대응

항목	내용	대응 방안
초기 전환 비용	폴더 정리 및 이동에 시간 소요	일괄 구조 정비 후, 기능별 코드 점진 정비
러닝커브	낯선 구조로 인한 초반 혼란	네이밍, 구조 규칙 문서화, 예시 참고
코드 중복	공통 모듈 혼선	shared, common 등 별도 폴더에서 Atomic 구조 기반 명세화, 재사용성 강화

📝 결론

기능 단위 FSD 아키텍처는 현재 프로젝트의 기능 책임 분리 상태와 잘 부합하며, 도입 부담이 낮고 운영 안정성에 위협이 없어 도입부담이 낮고, 복잡한 탐색을 줄여 유지보수 생산성을 높일 수 있습니다.

따라서 FSD 구조로의 일괄 전환을 통해 유지보수성과 탐색성을 동시에 개선하는 방향을 제안드립니다.
@Cllaude99

🚧 적용 방식 제안

현재 코드 리팩토링이 중단된 상태이므로, 점진적 전환보다
✅ 전체적인 구조 정비 후 → 개별 기능 코드 개선 순서로 진행하는 것이 더 적합하다고 생각합니다

• 운영상 긴급 대응 항목 없음 → 구조 명확성 확보에 집중하기 좋은 환경
• 구조 재정비는 서비스 운영에 즉각적 영향을 주지 않음
• 리렌더링 및 성능 개선 작업은 구조 전환과 병렬 추진

참고문서

(번역) 기능 분할 설계 - 최고의 프런트엔드 아키텍처, Feature-Sliced Design 공식문서 FSD를 위한 ESLint 플러그인 개발 일지 Nike Sneaker and Footwear Store Github Search youtube zerocho

[Cllaude99]

• 중복 구조: 동일한 기능명으로 폴더가 반복됨 → 구조적 중복 및 경로 탐색 비용 증가

혹시 위의 동일한 기능명으로 폴더가 반복되는 것은 구체적으로 어떠한 것을 의미하는 걸까요? (현재 폴더내의 상황을 들어주시면 좋을 것 같아요! components, hooks 등의 폴더에 도메인별로 폴더를 하나 더 생성하시는 것을 의미하는걸까요? 만약 그렇다면 도메인별 폴더를 하나 더 생성하는 것의 단점이 경로 탐색 비용 증가인가요?)

• 범위 혼동: 특정 컴포넌트 내부에서만 사용하는 utils, constants 와 전역영역의 직관적인 구분이 필요함.

현재 src/utils 와 src/constants에는 전역적으로 사용되는 함수 및 상수들이 저장되어 있습니다. 따라서 특정 컴포넌트 내부에서만 사용하는 것과 어떠한 연관성이 있는지 궁금해요. (구체적인 상황도 알려주시면 감사하겠습니다!)

• 디자인 시스템 문서화 용이: Storybook을 활용한 시각적 문서화 및 단일 진입점 제공 → 비개발자 협업 효율 증가

이 부분의 이점에 대해서 잘 이해가 되지 않는 것 같아요! FSD로 바꾸면 디자인 시스템 문서화가 용이하다는게 기능별 폴더안에 ui 폴더를 두고 해당 폴더안에 관련 컴포넌트 파일을 두어 디자인 시스템을 한눈에 보기 편하다는 것을 의미하는 걸까요?

기존 구조 vs 개선 구조(FSD) 비교

구조를 비교해봤을때, 구현하고자 하는 하나의 기능에 대해 이전에는 components, hooks, apis 등의 여러 폴더에 구현하고자 하는 기능에 해당하는 폴더를 만들어 관련 로직을 넣었다면, 개선이후에는 구현하고자 하는 기능을 features 폴더내에 저장하고 해당 기능의 이름으로 폴더를 만든뒤 그 폴더안에 components, hooks, apis등의 로직을 모아두어 물리적으로 이동하는 범위를 줄였다고 봤는데 이해한게 맞을까요?

만약 위의 이해한 내용이 맞다면 앞서 말씀해주신 중복 구조: 동일한 기능명으로 폴더가 반복됨 에 대해서는 완벽하게 해결되었다고는 보기 어려운 것 아닐까요?
왜냐하면 기능하다 중복적으로 추가되어야하는 폴더가 있으니까요! (하나의 기능을 만들면 그 기능폴더 안에 또 components, ui, api 등의 폴더를 만들어야함)

또한 개선된 구조를 보아하니 feature폴더에 components, apis, queries, mutations등의 폴더가 모두 있더라구요!
features 폴더 내부에 api 함수, queries, mutations, 등 모든 로직을 한데 모으는 방식은 FSD를 적용하는 목적인 기능중심과 도메인 책임의 분리라는 목적과 일치하지 않는 것 같아요. FSD는 각 도메인(entities)이 자신의 데이터를 직접 관리하고, 각 기능(features)은 그 데이터를 어떻게 사용할지(UI와 상호작용 중심)에만 집중하도록 역할을 분리한다고 생각하는데 지금처럼 모든 로직을 feature 내부에 몰아넣으면, 도메인 간 중복이 발생하여 재사용성이 떨어지고, API가 변경될 때 관련된 feature 전부를 직접 수정해야 해서 결합도 높아지게 되어 문제가 발생할 것 같아요. 또한 이렇게 구성된 구조는 feature가 늘어날수록 오히려 유지보수가 어려워지고, 테스트나 문서화도 어려울 것 같습니다.
따라서 api 호출 및 query/mutation과 같이 도메인 중심의 데이터 처리 로직은 entities/<도메인>/api 또는 entities/<도메인>/model에 위치시키고, features 폴더는 오직 UI와 사용자 상호작용에 집중하도록 구성하는 것은 어떠신지 제안드려 봅니다.

[Cllaude99]

현재 전역 유틸과 기능 유틸은 디렉토리 상에서 잘 구분되어있습니다. (함수, 상수 등 포함)
다만 FSD 도입을 통해 구분을 명확한 책임 경계와 구조적 일관성 안에서 더욱 시각적으로 드러내고, 단방향 의존성 원칙을 통해 결합도와 확장성을 향상시킬 수 있다는 점에서 언급했습니다.

혹시 위의 말이 어떤 의미인가요? 현재 전역적으로 사용되는 함수, 상수등은 폴더로 잘 구분되어 있는데 이 구조를 그대로 가져가는건가요? 또 위에서 설명해주신 단방향 의존성 원칙을 통한 결합도와 확장성 향상은 구체적으로 어떠한 것을 의미하는 걸까요? 현재 프로젝트와 관련된 상황을 함께 알려주시면 좋을 것 같아요. (문제 발견 및 정의 -> 문제 해결 순으로요!)

위 예시처럼 features 와 entities 폴더는 각자 다른 역할(slice)를 가지기 때문에 제안주신 features api 사용 금지 방향은 어려울 것 같습니다.

• entities api :

  • 핵심 비즈니스 도메인 api (기본적인 데이터 조회 R)
  • 여러 feature 에서 공통으로 재사용하는 경우 (Layered Dependency Rule 공식문서의 사용법 기준)
  • 복잡한 사용자 인터랙션의 경우, entities 로 포장하기 어려운 경우가 많습니다..

• features api :

  • entites 로 조합되거나
  • 사용자 동작으로 인한 api 흐름 제어 중앙 관리
  • 동사로 표현되는 요청 CUD (ex. 게시물을 북마크한다, 메시지를 전송한다 등)

혹시 위의 내용과 관련해서 기존의 구조와 개선된 구조를 만들어 비교해주실 수 있을실까요? 설명해주신 내용을 봐서는 FSD 구조가 어떠한 점이 있어서 좋다! 정도로만 받아들여지는 것 같아요. 구체적으로 어떠한 기준으로 나눌 것인지에 대한 명확한 기준이 있었으면 좋겠어요. 예를 들어 feature폴더에는 어떠한 것이 들어가는지? 그리고 왜 그렇게 생각했는지 등등이요!

초기 단계에서 모든 예외 케이스를 정의하는 것은 현재 discussions 와는 적절하지 않다고 느껴집니다.

따라서 현시점에서는 "기능 중심 설계로 구조적 응집력을 높인다"는 FSD의 핵심 목적에 동의한다면, 우선 도입을 시도하고 실제 적용 중 발생하는 이슈를 PR을 통해 공유하며 점진적으로 팀 내부 컨벤션을 정립하는 방향이 더 생산적이라고 판단됩니다.

저도 이부분에 대해서는 동의합니다. 하지만 구조 개선에 앞서 명확한 목적과 설계가 필요하다고 생각해요.

또한 eslint와 같은 린트나 빌드 도구를 통해 FSD 의 규칙을 지정해 가이드할 수 있으므로 불일치의 경우 관리 가능할 것으로 예상됩니다.

eslint는 코드 품질을 위한 검사도구로 알고 있는데 폴더를 만들때에도 제한을 두실 생각인가요?

[chae-dahee]

현재 전역적으로 사용되는 함수, 상수등은 폴더로 잘 구분되어 있는데 이 구조를 그대로 가져가는건가요?

현재 구분되어있는 기준을 FSD 규칙에 맞게 설계하자는 이야기입니다. 이미 기능을 단위로 구분하고 있기때문에 기존 구분 기준에 대해 언급한 것입니다.

📂shared
 ┗ 📂lib
     ┗ 📄getErrorData.ts (공통 유틸)
📂entities/time/
 ┗ 📂lib
     ┗ 📄timeFormat.ts (시간유틸)

현재 timeFormat.ts 의 위치는 src/components/time/utils 폴더 내에 위치하고 있습니다. 해당 파일은 컴포넌트에 해당하는게 아니고, 유틸에 해당하는 동작을 수행하기 때문에 현재 컴포넌트 폴더 내에 위치하는 것은 적절하지 않다고 판단했습니다. time 뿐만 아니라, 다른 컴포넌트 내부에서 선언되는 constants, hooks. utils 등도 컴포넌트 폴더 내에 위치하고 있어 맞지 않다고 생각합니다. 명확히는 컴포넌트 폴더가 아닌 기능 단위로 구분되어서 사용되고 있습니다.
시간 feature 내에서 광범위하게 사용되기 때문에 entities/time/lib 로 설계하였습니다.

단방향 의존성 원칙을 통한 결합도와 확장성 향상은 구체적으로 어떠한 것을 의미하는 걸까요?

FSD의 Layer 에 따른 계층 규칙인 단방향 의존성 원칙에 따라 import 규칙이 지켜진다면, 계층 단위로 결합도가 높아지게 됩니다. - 공식문서 참고 하위 계층은 상위 계층을 모르게 되므로 계층 구조는 평탄화 됩니다. 즉, 전혀 관련 없는 도메인이 다방면에서 마구잡이로 호출되어 사용되는 것을 방지할 수 있습니다. -> 이를 통해 파일 구조에 대한 명확성을 가져 기능 추가 복잡도를 줄이는 확장성을 가져다 줄것 을 예상합니다. 외부 기능이 내부 도메인 로직을 함부로 참조하지 않도록 모듈화 및 캡슐화를 강화할 수 있습니다.

또한 기존 구조의 명확한 문제정의의 경우, 위 답변의 1️⃣ 을 참고해주시길 바랍니다.

구체적으로 어떠한 기준으로 나눌 것인지에 대한 명확한 기준이 있었으면 좋겠어요.

찾아보시면 아시겠지만 다른 구조는 모두 명확한 기준으로 구분할 수 있지만, feature와 entities 는 100% 명확한 기준을 구분하기 어렵습니다. 팀마다 다른 규칙을 따르기도 하고요.
따라서 이부분의 경우 componets를 모두 분석해보아야 어느정도 파악이 가능할 것 같습니다. 도입이 확정되면 싱크스팟 맞춤 고도화된 방식을 명확히 정리해 볼 예정 입니다.

📂feature
 ┗ 📂voteTime
     ┗ 📂ui
     ┗ 📂model
         ┗ 📄useLocationData.tsx (예시! 여러개의 query 조합으로 이루어진 커스텀hooks 의 경우, feuature 에 작성)
     ┗ 📂lib
📂entities/resultTime/ (비즈니스로직 R )
 ┗ 📂api
     ┗ 📄getTimeResult.tsx
 ┗ 📂model
     ┗ 📄useGetTimeResultQuery.tsx
 ┗ 📂ui
     ┗ 📄GridTime.tsx
     ┗ 📄voteResultGrid.tsx (해당파일에서 gridTime 호출해서 사용함)
     ┗ 📄VoteResultVyDate.tsx (투표 페이지에서 렌더링 되지만, 컴포넌트 역할은 결과 렌더링임)
 ┗ 📂lib
     ┗ 📄fillGridColors.tsx

제가 탐색하고, 고려한 기준은 위 답변 3️⃣ 에 있습니다. 이 기준에 대해 혹시 의문이 들거나 이해가 어려운 부분이 있으실까요? 정확한 사례 및 예시를 짚어주시면 그부분에 대해서 고민해보겠습니다.

eslint는 코드 품질을 위한 검사도구로 알고 있는데 폴더를 만들때에도 제한을 두실 생각인가요?

정확히는 코드에서 사용하는 폴더 import에 대한 규칙입니다. FSD 의 규칙을 eslint 로 지정할 수 있는 내용은 아래와 같습니다.

• 계층 간 방향 제어
• slice 간 참조 금지 (라이브러리 사용 필요한걸로 파악됩니다)
• UI → 로직 의존만 허용 (역방향 금지)
• import 순서 통일
• index 경유 import
• store 직접 접근 금지

적용 예시 코드 및 라이브러리 탐색은, 도입이 확정되면 고도화된 방법을 탐색해볼 예정입니다.

[chae-dahee]

저도 이부분에 대해서는 동의합니다. 하지만 구조 개선에 앞서 명확한 목적과 설계가 필요하다고 생각해요.

제가 이부분에 대한 이해가 늦었네요.. 초기 단계에서 모든 예외 케이스를 정의하는 것은 현재 discussions 와는 적절하지 않다고 느껴집니다. 이부분에 대한 동의인가요? FSD 의 도입목적에 대한 동의인가요?

많은 개발자 사용기를 찾아본 결과, 아무리 명확한 기준을 구분해도 하다보면 애매한 것이 종종 나오는게 FSD의 원칙이라는 이야기가 있습니다. 기준은 위처럼 하되(features CUD entities R) 애매한 것이 나올 경우, 팀내 의사결정으로 해결하는 방식을 제안드립니다. 코드리뷰와 적극적인 의견 공유를 통해서요~ 또한 FSD 의 모든 원칙을 강하게 구분하기보다는, FSD의 목적을 챙겨가며 변화에 유연하게 설계해보는게 어떨까요? 관심사 분리를 기능단위로 응집시키면서 다양한 방식을 고려한다는 콘셉트를 가져가도록이요!

위 제안에 따라 entities, features 의 구분을 다시한번 정리했습니다. 또는 의문이 들거나 필요하다고 생각되는 조건이 있다면 알려주세요!

아래 기준을 정할때, nukeapp 의 구분레이아웃을 참고했습니다. 현재 컴포넌트를 더 쪼개야 할 것 같아요 components/time/voteTime 의 timeSelect 흐름 참고

✅ Entities Layer 구분 기준

→ 아래 조건 중 하나라도 해당되면 entities에 배치

구분 기준	설명
핵심 비즈니스 도메인 API	프로젝트의 핵심 기능을 구성하는 도메인 단위 API (예: 투표 결과, 사용자 정보 등)
공통 재사용 가능성	여러 feature에서 공통으로 재사용되는 경우 (중복 방지를 위한 분리)
단순 조회(R) 중심의 API	기본적인 데이터 조회만을 담당하며, 복잡한 사용자 동작이나 흐름 제어 없음
복잡한 사용자 인터랙션이 아님	사용자 행위가 API 흐름을 제어하지 않고, 단순 렌더링이나 필터링 등 수동적 처리일 경우

✅ Features Layer 구분 기준

→ 아래 조건 중 하나라도 해당되면 features에 배치

구분 기준	설명
Entities 조합 및 흐름 제어	여러 entities를 조합해 비즈니스 로직을 수행하거나 흐름을 제어하는 경우
사용자 동작 중심	사용자 액션(클릭, 입력 등)에 따라 API 요청 흐름이 발생하는 경우
CUD 중심 동사 기반 API	데이터를 생성(Create), 수정(Update), 삭제(Delete)하는 행위 중심의 API 처리 (ex. 장소 등록, 투표 등)
인터랙션 제어 및 상태 변화 포함	비즈니스 로직에 따라 상태 변화 및 복잡한 UI 상호작용을 포함하는 경우

eslint 규칙

라이브러리를 탐색해보았는데, 모든 규칙을 지정하고 신뢰성과 안정성 있는 대표적인 FSD 플러그인은 찾지 못했습니다. Layer 계층의 단방향 import 규칙을 사용하는 eslint-plugin-import 을 사용할 수 있습니다.
직접 코드로 작성할 경우, 몇개의 규칙은 모든 레이어 간의 경우의 수를 차단하는 방법이 있습니다. 이 규칙의 경우에도, 기본적인 부분만 제한하고 유연하게 가져가는게 좋을 것 같다고 생각합니다.
예시로 작성해보았는데, 실제 프로젝트에 적용 시에는 변경이 있을 것 같습니다.

    // 1. 레이어 간 import 순서 강제
    'import/order': ['error', {
      groups: [['builtin', 'external'], 'internal', ['parent', 'sibling', 'index']],
      pathGroups: [
        { pattern: 'app/**', group: 'internal', position: 'before' },
        { pattern: 'pages/**', group: 'internal', position: 'before' },
        { pattern: 'widgets/**', group: 'internal' },
        { pattern: 'features/**', group: 'internal' },
        { pattern: 'entities/**', group: 'internal' },
        { pattern: 'shared/**', group: 'internal', position: 'after' },
      ],
      alphabetize: { order: 'asc', caseInsensitive: true },
      'newlines-between': 'always',
    }],

    // 2. import 시 절대경로 index.ts 통해서만 import 강제
    'no-restricted-imports': ['error', {
      patterns: [
        // 내부 구조 직접 import 금지
        {
          group: ['features/*/*/*', 'entities/*/*/*', 'shared/*/*/*'],
          message: '모듈 public API(index.ts) 를 통해 import 하세요',
        },
        {
          group: ['state/**', 'store/**'],
          message: '전역 상태는 직접 import 하지 마세요. features 또는 entities 단에서 사용하세요.',
        },
      ],
    }],
  },

    // 3. slice 간 import 금지 (features/<A> 에서 features/<B> 접근 방지)
    {
      files: ['src/features/**'],
      rules: {
        'no-restricted-imports': ['error', {
          patterns: ['features/*'],
        }],
      },
    },

[Cllaude99]

제가 이부분에 대한 이해가 늦었네요.. 초기 단계에서 모든 예외 케이스를 정의하는 것은 현재 discussions 와는 적절하지 않다고 느껴집니다. 이부분에 대한 동의인가요? FSD 의 도입목적에 대한 동의인가요?

두 말에 대한 동의입니다~ 저 또한 폴더구조의 경우 정해진 기준이 있다기 보다는 함께 개발하는 사람과 기준을 정해가며 맞추는 것이 좋다고 생각해요.
앞서 말씀드린 명확한 목적은 개선구조가 왜 필요한지 또 도입함으로써 얻을 수 있는 이점이 있는지에 대한 것이었습니다.

라이브러리를 탐색해보았는데, 모든 규칙을 지정하고 신뢰성과 안정성 있는 대표적인 FSD 플러그인은 찾지 못했습니다.

저도 이 부분은 폴더 구조에 대해 논의를 한 후 eslint를 통해 규칙을 정하는 방식으로 하는것이 더 자연스러울 것 같아요.

폴더구조에 대해서 관심을 가지고 개선하려고 노력하신 점 감사합니다. 사실 개발초기부터 리팩토링을 하는 지금까지 초기 폴더구조가 이어져오던터라 변경하는 것에 걱정이 있었어요. 바뀐 폴더구조에 대해 적응하는것도 하나의 비용이라고 생각했고, 지금 상황에 꼭 필요한가?라는 의문도 있었거든요. 또 리팩토링 과정도 파일에 대한 코드 리팩토링이 대부분이었고, 별다른 기능추가가 없었기 때문에 폴더 구조를 바꾸는 것에 대한 의구심이 있었어요.
하지만 말씀해주신 확장성을 고려한다면 폴더구조를 개선하는 것도 좋아보입니다.

또 이와 관련해서 리팩토링 과정에서 추가 기능을 도입하실 의향이 있으신건지도 궁금해요.

[chae-dahee]

감사합니다! issue 생성해서 단계별로 FSD 구분해보겠습니다.

또 이와 관련해서 리팩토링 과정에서 추가 기능을 도입하실 의향이 있으신건지도 궁금해요.

코드적인 변화로는, 컴포넌트(wedgets) 으로 구성되어있는 것을 features, entities 로 더 잘개 쪼개서 사용할 것 같습니다.
@yooooonshine 찬호님께서 장소입력만 소켓으로 관리하는 부분을 제안주셔서, 추후에 프+백+기획분들 모두와 함께 의견조정해볼것 같습니다. (여름방학쯤?)
혹시 도입이 필요하거나 공유하고싶은 기능이 있으시다면 알려주세요. 검토해보겠습니다!