9개월이라는 기간동안 여러 프로젝트에 참여할 수 있는 기회가 생겼었다! 기존에 경험해보지 못했던 기술도 새로 다뤄볼 수 있었고, 이전 프로젝트에서는 맛보기로 경험했던 기술도 제대로 다루어보고 배워볼 수 있는 시간이었다.
이전 프로젝트 활동을 통해 공부한 내용을 하나씩 공유해보려고 한다. · ₊ ˚✿𓂃 ପ₍ᐢ๑• ֊ •๑ᐢ₎ଓ ⌒☆
여러 프로젝트를 진행하면서 가장 큰 고민은 어떤 아키텍처를 선택해야 할지와 그 중에서 어떤 부분을 중점적으로 고려해야할지 였다. 초기에는 전통적인 아키텍처를 사용하여 설계하고 있었지만, 컴포넌트 간의 강한 결합과 모듈의 복잡성으로 인해 프로젝트의 유지보수가 어려워지는 문제를 겪게 되었다. 특히, 프로젝트 규모가 커질수록 점차 구조가 엉망이 되어가고 있다는 걸 느끼게 되었다.
FSD는 기능 단위로 분할 설계하여 모듈간 결합을 느슨하게 응집력을 높이는 것을 목표로 한 아키텍처이다. 기존 OOP(객체 지향 프로그래밍)에서는 다형성, 캡슐화, 추상화, 상속과 같은 개념을 통해 위 문제를 해결해 왔는데 이와 같은 개념을 프론트엔드에 적용하여 재사용성, 유지보수등 다양한 결과를 보장한다.
FSD는 계층 구조라는 특징이 있다. 상위 레이어는 하위 레이어만 활용할 수 있는데 한 방향으로만 향하는 선형적인 흐름을 유지한다.
레이어(Layer)
→ 최상위 디렉토리를 의미
→ 최대 7개로 제한되어 있으며 일부는 선택사항
→ 코드 베이스를 조직화하고 모듈화되고 유지보수 용이한 확장 가능한 아키텍처를 촉진
슬라이스(Slice)
→ 코드를 값별로 그룹화하기 위해 사용
→ 슬리이스 명명은 프로젝트의 비즈니스 영역에 따라 결정
공개 API
→ 각 슬라이스와 세그먼트는 공개 API가 있음
→ index.js
또는 index.ts
파일이 진입점 역할을 함 (이 파일을 통해서만 외부로 내보내고 쓸 수 있음)
→ import
및 export
로 단순하게 작동하므로 애플리케이션을 변경할 때 코드의 모든 곳에서 import
를 변경할 필요가 없음
// index.js
export { default as Button } from './Button';
export { default as Input } from './Input';
// use
import { Button, Input } from './components';
FDS 아키텍처를 공부하면서 실제 프로젝트에 적용하는 역할을 담당했다. 기능을 독립적인 단위로 분리하고 그 경계를 명확히 하라는 원칙은 처음에는 이해하기 어려웠지만, 코드를 구조화하면서 점점 그 중요성을 깨달을 수 있었다. 또한, 이미 구조가 잡혀 있던 프로젝트였기 때문에 이를 준수하며 구조를 바꾼다는 것은 어려운 쉽지 않은 작업이었다.
FDS 아키텍처를 적용하면서 자원 관리에 대한 이야기가 많았는데, 어떤 자원이 공유되어야 하고 어떤 자원이 특정 기능 내에서만 관리되어야 하는지에 대한 구별이 필요했다.(예를 들어 공유되는 자원(타입이나 아톰 등)이니 당연히 shared
에서 관리되는게 맞다고 판단했는데, 하나의 feature
안에서만 필요한 자원인데 굳이 shared
에서 관리 될 필요가 있는지 이런 부분이 명확하지 않았다.) 이런 부분은 팀원들과 상의하며 좀 더 명확한 방법을 함께 정의하는 시간을 만들기도 했다.
아직까지도 부족한 부분은 많지만 꾸준히 공부해나가며, 전문성을 갖출 수 있게 노력해야겠다!