초반 컴포넌트 설계가 특히 중요한 이유

컴포넌트 설계는 개발 과정에서 매우 중요합니다. 그렇기에 초반에 잘못된 설계를 하게되면 이후 여러가지 어려움을 겪게 되는 것 같아요. 예를 들어 새로운 custom hook을 추가할 때 위치를 결정하는 문제나, 특정 컴포넌트의 로직을 수정할 때 import된 파일들이 얽혀 있어 영향 범위를 파악하기 어려운 경우들 처럼요.


이러한 어려움을 해결하기 위해, 나름대로 찾은 방식은 페이지 단위로 컴포넌트 폴더를 구성하고, component, hooks, 관련 type 등의 코드를 해당 폴더에 모아두는 것입니다.


그러나, 이역시도 완전한 해결책은 아니었어요. 애플리케이션이 복잡해질수록 폴더 구조도 깊어지고 복잡해지는 문제가 발생합니다. 팀에 신규 인원이 합류 했을 때, 코드를 빠르게 이해하고 수정하는 데 있어 이 문제는 큰 장애물이 되더라구요..


이 문제를 해결할 수 있는 방법을 찾아보다가, 최근 Feature Sliced Design(FSD) 방법론에 대해 알게 되었습니다. FSD는 애플리케이션을 기능별로 분리하여 각 기능을 독립적인 모듈로 관리하는 방식입니다. 이는 컴포넌트, 훅, API 로직 등을 기능 단위로 묶어 관리함으로써, 애플리케이션의 복잡성을 줄이고, 개발자가 필요한 코드를 빠르게 찾아 수정할 수 있도록 돕습니다.


FSD 방법론을 적용함으로써, 컴포넌트 설계와 관리의 어려움을 줄이는 것이 일차적인 목표입니다. 특히, 코드의 재사용성이 높아지고, 팀 내에서의 코드 이해도를 향상하여 프로젝트의 전반적인 개발 속도와 품질을 개선하고 싶습니다.


여러분은 컴포넌트 설계와 관리에 있어 어떤 어려움을 겪고 계신가요? 혹은 FSD 방법론을 적용 해보셨거나, 그 외에 다른 해결책을 발견하셨다면, 그 경험을 공유해 주세요. 🚀

다음 내용이 궁금하다면?

또는

이미 회원이신가요?

2024년 4월 17일 오전 10:29

댓글 1

  • 같은 고민을 하면서 FSD로 정말 작은 토이프로젝트를 진행해봤는데 저는 조금 어색했던 경험이 있습니다. 이해도가 쌓이고 구조가 손에 익으면 좀 괜찮아 질 것 같기도 한데 모놀로식에 익숙하니 좀 어색했네요. 저는 FSD의 계층 구조에서 아래 계층에서의 참조를 제한하는 식의 접근이 좋았었고 이해도 높게 잘 구축하면 정말 레고 조립하듯이 어플리케이션을 구축할 수 있을 것 같아서 좋았어요. 우려점은 잘 모르고 쓰면 예전에 제가 아토믹이 마음에 들어서 갖다가 써본적이 있는데 애매한 꼭지가 나타났을때 어느 계층에 넣어야 할지 어려워지고 그렇게 하나씩 어중간해지다 보면 각 컴포넌트가 역할의 경계가 모호해지곤 했는데 그런 일이 여기서도 일어날 순 있겠다 싶어서 유의해야 할 것 같았습니다