[4팀 오하늘] Chapter 2-3. 관심사 분리와 폴더구조🧦

by eveneul2025. 8. 11.

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

과제 체크포인트

기본과제

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

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

체크포인트

심화과제

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

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

체크포인트

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

최종과제

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

과제 셀프회고

테오.. 저 힘들었어요..... 🥺

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

FSD 폴더 아키텍처를 이번 과제하면서 처음 알게 되었어요. 실무에 있는 3년 동안 리액트 프로젝트 구조는 늘 /hooks, /component 식으로 나누었기에 클린 코드 주차 중 이번 주차가 제일 기대되었어요. 그런데 FSD에 대해 공부할수록, entities, features 구조를 처음 보는 저는 큰 멘탈 붕괴에 빠질 수밖에 없었어요. AI도 뚜드려보고, 테오가 공유해 주신 자료들을 보고, 또 구린내 클럽이라며 결성한 팀원분들의 의견을 모아 엔티티는 정보고, 피처는 행동이다라고 결론을 내렸어요. 그렇게 생각하니 어떠한 기능을 보고 이건 엔티티다! 이건 피처다! 구분할 수 있는 시선이 생겼어요. 물론 일주일 동안 FSD를 경험해 보고 몸과 마음이 탈탈 털린 제가 있다는 것도 알게 되었지만요.

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

비밀리에(?) 스카우트를 통해 가입이 가능한(?) 구린내 클럽에 가입했어요. 회장은 5팀 허정석 님, 부회장은 2팀 정도은 님이에요. 물론 우리 4, 7 페어팀끼리도 FSD에 대해 이야기를 하지만 우리 팀을 벗어나 다른 팀원분들이 생각하는 FSD를 듣고 싶었어요. 룰은 반조타이파(주스탠드 사랑해파), 5살 민준이에게 설명하듯 서로서로 쉽게 설명해 주기가 있는데요, 이런 룰 덕분에 팀원분들 상호간의 이야기가 편한 분위기로 이어진 것 같아요.

되도록 궁금한 점은 ~~AI에게도 물어봤지만~~ 구린내 클럽분들에게 공유 드리고, 다양한 생각을 들으려고 노력했어요. 다음 주차도 구린내클럽과 같이 할 생각입니다.

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

기능이 많으면 많아질수록 커지는 뎁스와 폴더들... 이게 맞나요? 저는 잘 모르겠어요. 하나의 기능에 대해 model, api, ui 등... 그리고 api 폴더 안에 api.ts는 하나밖에 없으니까 이 파일 하나를 위해 폴더를 생성하는 게 맞는지 모르겠어요. 지금은 관리자 대시보드 형식의 과제라서 구현한 기능이 그렇게까지 많은 것도 아닌데, 뎁스를 타야 하는 게 너무 많아요. 실무에서는 이걸 어떻게 적용하는지 궁금해요.

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

저는 항해에서 배운 걸 회사 개발팀에 공유를 하는데요....

저희 개발팀분들이 별다른 반응이 없는 걸 보아 하니 다 부정적인 생각이신 것 같아요....

위에서도 서술했듯이 프로젝트 볼륨이 작으면 괜찮겠지만 페이지도 많아지고 로직도 많아지면 복잡함만 더 늘어나는 것 같아서 FSD는 항해99에서만 배운 걸로 만족하려고 합니다.

챕터 셀프회고

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

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

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

제일 기대되는 주차였어요. 제 코드가 얼마나 더러운지 객관적인 시선으로 바라보고 싶었거든요. 그런데 클린 코드 챕터에 들어서자마자 내 코드는 나름 깨끗한 걸지도 모르겠구나.. 라는 생각이 들었어요. var부터 시작해서 for문 지옥까지.. 정말 울면서 리팩토링했다가 제 경험이자 기분입니다. 아마 다들 공감하실걸요..

에이전시 회사에 근무하고 있어요. 그래서 데드라인까지 빨리빨리 개발해서 넘겨야 하기 때문에 클린 코드에 대해 제대로 신경쓰지 못했어요. **기능만 돌아가면 된다!**라서, 일단 기능 구현 위주로만 작업을 했던 것 같아요. 그런데 나중에 되어서야 하자나 유지보수로 해당 코드를 수정해야 할 때 왜 이렇게 짰지? 라는 생각이 들더라고요. 과제처럼 for문이나 백틱 남발이 아니라 제가 읽기 힘든 코드를 짰더라고요.. (물론 제가)

그때부터 클린 코드는 고차함수를 쓰고 라인 수를 줄이는 게 아니라 미래의 내가? 남들이 보기에 단번에 이해되는 코드라고 결론을 내렸어요. 그 생각에서 파생돼서 유지보수 하기 좋은 코드는 한 가지 기능만 하는 함수들이 많은 거라고 생각돼요. 순수함수도 부트캠프 진행하면서 처음 들어 봤는데, 부트캠프를 진행하면서 처음 접했던 개념이 **순수 함수(Pure Function)**였는데, 이게 생각보다 굉장히 중요한 개념이더라고요. 순수 함수는 같은 입력값이 주어졌을 때 항상 같은 결과를 반환하고, 외부 상태를 변경하지 않는 함수고, 이 원칙이 지켜지면 코드의 동작을 예측하기 쉬워지고, 테스트나 디버깅이 훨씬 간단해져요. 또한 다른 코드에 미치는 영향이 최소화되기 때문에, 함수 내부를 수정하더라도 전체 시스템에 부작용을 일으킬 가능성이 낮아진다고 생각돼요.

결국 클린 코드와 유지보수성 높은 코드를 만드는 핵심에는 의도가 명확한 구조와 부작용 없는 함수가 있다고 생각합니다. 다음에는 공부나 실무 하면서 순수함수에 대해 더 많이 경험해 보고 싶어요.

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

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

props drilling을 경험해 보는 건 쉬웠던 것 같아요. 왜냐하면 지금도 경험하고 있으니까......

대신 조타이가 더 어려웠어요. Recoil을 쓰고 그 뒤로 Zustand를 사용해서, 조타이라는 라이브러리는 처음이었거든요. Zustand로 예를 들면 create와 get, set으로만 이루어졌다면 조타이는 지원하는 기능이 너무너무 많아서 뭘 써야 할지도 모르겠고 타임어택마냥 흘러가는 과제 마감 시간 전에 어떤 기능이 괜찮은지 물색하는 게 힘들었어요. 결국 잘해낸 것 같지만 조타이는 다음 번에도 쓰지 않는 걸로.. ^^;;

디자인 패턴도 역시 너무 궁금했던 챕터인데요, 저에게는 아직도 많이 많이 어려운 개념이에요. 그런데 테오가 말씀해 주셨듯, 일부러 디자인 패턴에 맞춘 코드를 작성하는 것보다는 클린 코드를 작성하게 되면 디자인 패턴에 맞는 코드를 작성하는 것이니 우선 클린 코드에 대해 심도 깊은 공부를 해야 할 것 같습니다.

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

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

사실 다 하지 못했어요. 다른 일정도 있었고 이번 주차에 특히 더 피로감이 몰려와서 막판 귀찮은 작업들은 다 AI에게 맡긴 것 같아요.

그래도 대부분은 제가 작성했는데요, 사실 저는 이 코드는 어디에 둬야 하지? 라는 생각이 든다면 FSD는 쓰지 않을 것 같아요. 오히려 더 저를 옥죄이는 느낌이 강했어요. 이거는 여기에 둬야 해! 저거는 저기에 둬야 해! 라는 솔루션이 정해진 것처럼 느껴져서, FSD에 대해 부정적인 생각만 남은 것 같아요.

시간이 없어서 제 마음대로 폴더 구조 변경하는 건 하지 못했지만, /hooks, /api 안에서 기능? 도메인? 별로 폴더를 나눌 것 같아요. 폴더를 잘게 쪼개는 게 과연 능사일까? 라는 생각이 강해요.

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

테오! 저 커밋이 너무 많아요. ㅋㅋㅋㅋ 다른 분들은 많아 봤자 20-30개 정도인데, 저는 기능 하나 구현하고 수정할 때마다 히스토리 관리를 더불어 디버깅 차원에서 커밋을 매번 하는데, 이게 맞을까요? 좋을까요? 궁금합니다.
위에서 말씀 드렸듯 파일을 한 개밖에 가지고 있지 않은 폴더 구조가 과연 맞는 걸까요? 폴더가 많으면 메타데이터 영역을 차지한다.. 라고 알고 있는데, 요즘 컴퓨터 사양이 많이 좋아졌으니 이런 말은 무시해도 되는 걸까요?
테오 덕분에 재미있는 과제 진행해 나갈 수 있었던 것 같아요. 3주 동안 감사 드렸습니다~

과제 피드백

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

"테오.. 저 힘들었어요..... 🥺"

"기능이 많으면 많아질수록 커지는 뎁스와 폴더들... 이게 맞나요? 저는 잘 모르겠어요. 하나의 기능에 대해 model, api, ui 등... 그리고 api 폴더 안에 api.ts는 하나밖에 없으니까 이 파일 하나를 위해 폴더를 생성하는 게 맞는지 모르겠어요. 지금은 관리자 대시보드 형식의 과제라서 구현한 기능이 그렇게까지 많은 것도 아닌데, 뎁스를 타야 하는 게 너무 많아요. 실무에서는 이걸 어떻게 적용하는지 궁금해요."

힘들었군요. ㅋㅋ 좋은 징조입니다. 그렇게 고생한만큼 훨씬 더 머리속에는 잘 각인이 되었을거라고 생각해요. 의미있는 고생은 추억이라는 행복으로 보상해주니 결과론적으로는 좋은거에요 ㅎㅎ

이게 맞나? 라는 고민 역시 좋은 포인트입니다. 사실상의 표준이 정립이 되기 전에는 다양한 관점과 제안이 나오기 마련이고 그 제안들을 실제로 내가 적용하면서 정말로 괜찮은지 안닌지를 판단할 수 있는 것은 매번 새로운게 만들어지고 바뀌는 개발자에게는 중요한 능력입니다. 본인에게 맞는것과 불편한 것들에 대해서 믿고 더 나은 방법은 뭐가 있을지를 항상 고민해보길 바래요. 잘했어요

실무에서는 좋은 것은 받아들이고 아니다 싶은 것들은 나름 자신의 해법등을 적용해보게 되어 있습니다. 그러면서 또 새로운 제안등이 만들어지기도 하구요. 본인의 느낌을 믿고 더 나아지는 형태를 계속해서 찾아보길 바래요.

Q) 테오! 저 커밋이 너무 많아요. ㅋㅋㅋㅋ 다른 분들은 많아 봤자 20-30개 정도인데, 저는 기능 하나 구현하고 수정할 때마다 히스토리 관리를 더불어 디버깅 차원에서 커밋을 매번 하는데, 이게 맞을까요? 좋을까요? 궁금합니다.

=> 커밋이 많은건 나쁜게 아녜요. 아주 좋은 습관입니다! 다만 완성이 되어 있지 않은 (테스트가 깨지거나 빌드가 안되는) 커밋을 자주 해버리는건 좋지 않죠. 그런게 아니라면 아주 좋은 습관이니 꾸준히 그렇게 하기를 바래요!

Q) * 위에서 말씀 드렸듯 파일을 한 개밖에 가지고 있지 않은 폴더 구조가 과연 맞는 걸까요? 폴더가 많으면 메타데이터 영역을 차지한다.. 라고 알고 있는데, 요즘 컴퓨터 사양이 많이 좋아졌으니 이런 말은 무시해도 되는 걸까요?

=> 네, 폴더가 많다고 한들 메타데이터 영역이 그렇게 커지지는 않아요. 폴더1개에 파일 1개뿐인 폴더는 안 좋을 수 있죠. 만약 프로젝트 규모가 아직 그정도라면 세부 폴더를 굳이 만들지 않아도 괜찮다고 생각해요. 그게 아니라 일부 폴더 1-2개만 그런거라면 일관성을 위해서 통일하는게 맞다고 생각해요.

=> 폴더구조는 결국 더 잘 이해하도록 하기 위해서 만드는 것이니 그게 도움이 안된다고 생각하면 도움이 되는 구조를 한번 고민해보면서 여러가지 변형을 만들어봐요. 그러나 일관성이 중요합니다.

"테오 덕분에 재미있는 과제 진행해 나갈 수 있었던 것 같아요. 3주 동안 감사 드렸습니다~" => 저도 고마워요 하늘!

항해플러스 프론트엔드

eveneul 님의 상세페이지 ＞ [4팀 오하늘] Chapter 2-3. 관심사 분리와 폴더구조🧦