Legitgoons 님의 상세페이지 ＞ [1팀 이의찬] Chapter 2-3. 관심사 분리와 폴더구조

[1팀 이의찬] Chapter 2-3. 관심사 분리와 폴더구조

by Legitgoons2025. 8. 14.

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

  • 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
  • Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
  • FSD(Feature-Sliced Design)에 대한 이해
  • FSD를 통한 관심사의 분리에 대한 이해
  • 단일책임과 역할이란 무엇인가?
  • 관심사를 하나만 가지고 있는가?
  • 어디에 무엇을 넣어야 하는가?

체크포인트

  • 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
  • Props Drilling을 최소화했나요?
  • shared 공통 컴포넌트를 분리했나요?
  • shared 공통 로직을 분리했나요?
  • entities를 중심으로 type을 정의하고 model을 분리했나요?
  • entities를 중심으로 ui를 분리했나요?
  • entities를 중심으로 api를 분리했나요?
  • feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
  • feature를 중심으로 ui를 분리했나요?
  • feature를 중심으로 api를 분리했나요?
  • widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?

심화과제

목표: 서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

  • TanstackQuery의 사용법에 대한 이해
  • TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
  • 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

  • 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
  • 쿼리 키가 적절히 설정되었는가?
  • fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
  • 캐싱과 리프레시 전략이 올바르게 구현되었는가?
  • 낙관적인 업데이트가 적용되었는가?
  • 에러 핸들링이 적절히 구현되었는가?
  • 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
  • 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
  • TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

  • 폴더구조와 나의 멘탈모데일이 일치하나요?
  • 다른 사람이 봐도 이해하기 쉬운 구조인가요?

배포 링크

https://legitgoons.github.io/front_6th_chapter2-3/

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

FSD는 도대체 왜 하는가

  • 회사의 시니어 개발자님이 흥미롭게 읽었다며 ‘소프트웨어 파괴의 미학’이라는 글을 추천해주셨었는데, 그 당시에는 그냥 니체랑 개발을 엮어두었어서 흥미롭게 읽었습니다. 방법론은 잘 이해 못했었구요.
  • 이번 과제를 진행하면서, FSD는 비즈니스의 복잡성으로 인해 요구사항의 변화에 따라서 코드가 계속 갈아엎어지는 부분을 해결하려고 레이어 사이를 분리해 두었던 게 아닐까? 라는 생각이 들었습니다.
    • 비즈니스와 엮인 정도가 곧 외부 요구사항에 대한 변화 가능성이니, 이에 따라서 계층을 나눠 둔 것이라고 생각합니다.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

스스로 FSD에 대해 정의내리기

  • shared
    • 비즈니스 & 도메인과 아무런 연관이 없는, 재사용이 가능한 코드들
  • entities
    • 순수한 데이터, 즉 서버에서 가져온 데이터가 위치해야 한다고 생각합니다. 이를 위해서 이것을 호출하는 api와 model 모두 이곳에 위치해야 한다고 생각합니다. 물론 저만의 원칙이고, FSD 공식문서와는 다르긴 합니다.
    • 원래는 비즈니스 로직도 이곳에 위치해야하지않나? 생각했지만, 데이터와 함께 두기보다는 사용자의 동작과 함께 위치하는게 더 적절해보여 features로 두는게 맞아보입니다.
  • features
    • 사용자의 동작에 따라 동작하는 기능들입니다. 비즈니스 로직과 그리고 tanstack query를 비롯한 hook등이 위치하는게 적절할 것입니다.
  • Widgets
    • UI 덩어리입니다. 도메인이 섞일 수 있는 최소 단위입니다.
  • pages
    • 페이지.
  • app
    • 앱에 대해서 접근하는 진입점이며, 세팅과 layout, provider 등이 위치할 것입니다.

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

이번에 배운 내용 중을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

챕터 셀프회고

클린코드와 아키텍처 챕터 함께 하느라 고생 많으셨습니다! 지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다. 아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

  • 더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

더티코드를 접했을 때

클린코드의 중요성

읽기 좋은 코드

유지보수하기 쉬운 코드

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

  • 거대한 단일 컴포넌트를 봤을때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

단일 컴포넌트를 봤을때의 느낌!

순수함수로 분리하면서 "아하!"했던 순간

컴포넌트가 독립적이 되어가는 과정에서의 깨달음

응집도 높이기: 서버상태관리, 폴더 구조

  • "이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

"이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간

FSD를 적용해보면서의 느낌

나만의 구조를 만들어가는 과정

TanStack Query로 서버 상태를 분리하면서 느낀 점

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

과제 피드백

수고했습니다. 지난 3주간 클린코드를 비롯한 소프트웨어 공학적으로 결합도 낮추기 응집도 높이기를 위한 이론과 프론트엔드에서의 적용등을 통해서 좋은 코드와 구조에 대한 다각도의 시야가 생겼기를 기대합니다.

"이번 과제를 진행하면서, FSD는 비즈니스의 복잡성으로 인해 요구사항의 변화에 따라서 코드가 계속 갈아엎어지는 부분을 해결하려고 레이어 사이를 분리해 두었던 게 아닐까? 라는 생각이 들었습니다."

"결국 어떤 상황에 어떤 구조를 선택해야할까?에 대해서는 아직 막연하게 느끼는 것 같아서 아쉽습니다."

프론트엔드는 그동안 빠르게 변화해왔습니다. 하나의 정답을 두지 않고 프레임워크를 제안하고 CSS 라이브러리를 제안하고 상태관리끼리 경쟁하며 발전해왔죠. 그리고 차츰 대부분이 사용하는 사실상 표준과 같은것들이 만들어졌습니다. prettier의 경우도 포맷터 논쟁은 예전에는 엄청나게 많았지만 사실상 표준이 생겨버렸죠. 폴더구조는 아직 표준 정립 전 뭐가 나은지를 탐색하고 있는 단계라고 생각해요. 그리고 아마 언젠가는 사실상 표준적인 구조가 만들어질 거에요.

모든 개발이 그렇습니다. AI도 마찬가지로 누가 더 어떤게 정답인지 모른채 저마다가 잘하고 있다고 믿는 쪽으로 찾다가 자연스레 Think mode, Agent, MCP 등으로 정립이 되는 것처럼요.

그렇지만 표준이 정립되기 전까지에는 가장 나은게 무엇일지 찾아야 합니다. 그리고 개발은 앞으로도 이러한 사이클이 반복이 되는 만큼 많이 고민을 해봐야겠지요

"테오가 FSD에 대한 내용은 개념만 남기고 잊으라고 했지만, 사실 이 구조가 썩 마음에 들어서 실제로 한번쯤 사용해보고 싶은 마음은 있습니다. 물론 적절하게 사용할 수 있는 기회가 온다면요!" 화이팅입니다!

Q) 이번 챕터에서 가장 어려운 것은 결국 어디까지 함수를 쪼갤 것인가와 폴더 구조를 무엇을 근거로 선택할 것인가 두 가지라고 생각해요. 제가 생각해도 굉장히 막연한 질문이긴 한데, 혹시 테오는 이 두 가지에 어떤 기준을 가지고 하시는지를 알려주시면 감사드리겠습니다!

=> 제가 솔루션으로 작성했던 엔티티, 순수함수, useQuery, useMutation, lib, util hooks, UI 컴포넌트, 도메인 컴포넌트, 컬렉션, 템플릿, 레이아웃 정도까지는 기계적으로 분리를 합니다. 검증이 된 계층이니끼요

=> 폴더 구조의 경우 가급적 기획서를 따르려고 합니다. 정확히는 실제로 어떻게 추상화해서 다루고 있는지요. 가령 이번 과제에서 포스트 검색기능이라고 부르고 있다면 포스트 검색 기능을 폴더로 만들고 포스트 관리라고 칭한다면 묶을거에요. 폴더구조는 멘탈모델이 되어 주어야 한다고 생각합니다.

=> 그 밖에 저는 interface가 가장 적게 만들어져야 한다고 생각해요. 그래서 인자나 리턴값에 별도로 타입들이 만들어지는게 많다면 좋은 구조는 아니라고 생각하고 있어요. 최대한 적은 코드로 적은 계층 적은 타입만 가지고도 가능한 코드가 되는 방향으로 만들고자 합니다.

도움이 되기를 바래요! 수고하셨습니다.