프론트엔드 아키텍처와 Feature-Sliced Design (2)
예전에 회사에서 프론트엔드 프로젝트를 진행할 때는 components, hooks, pages 이렇게 파일의 기술적 역할에 따라 구분하는 Layered-Architecture 방식만 사용했음.
왜 이런 방식을 사용했냐고 하면..
새로 만드는 프로젝트에 참여하기보다는 기존에 작성된 프로젝트를 유지보수하거나 기능을 추가하는 업무를 했기 때문..
이미 잘 동작하는 프로젝트를 다른 아키텍처를 적용해 새로 만드는 것도 장기적으로는 좋을 수 있지만, 회사에서는 내가 하고 싶은 일만 할 수 있는게 아니니까.. 회사 입장에서는 프로젝트 이관도 다 돈이다. 돈이 되는 일을 해야 했음.
개인 프로젝트나 팀 프로젝트에서는 회사 프로젝트랑은 느낌이 좀 다름.
사용해 보고 싶은 기술을 모두 사용해 볼 수 있고, 기존에 관심가지던 개발 방식이나 아키텍처도 시도해 볼 수 있다.
이번에 프로젝트를 진행할 때는 Feature-Sliced Design 아키텍처를 적용해봤다.
이전에 Layered-Architecture를 사용할 때는 프로젝트 규모가 커지고 작업할 내용이 많아질수록 코드 작성 및 파일 배치가 힘들었음.
비즈니스 로직을 어떤 식으로 작성할지는 알겠는데, 작성한 로직을 어디에 배치해야 할지가 애매한 경우가 많았다.
Feature-Sliced Design은 코드의 구성을 기술적 종류가 아니라 비즈니스 도메인을 기준으로 설계한다.
스프링 할 때 Domain Driven Development를 사용하는데.. 이 컨셉을 프론트엔드 생태계의 특징에 맞춰서 적용한 아키텍처라고 생각함.
FSD 찾으면 항상 나오는 그림인데, 진짜 이게 전부긴 함.
각 Layer 내부는 Slice로 나뉘고, 이 Slice들은 철저하게 격리된다. user와 product는 서로 import가 불가능함.
Features와 Entities의 경계가 모호하다고 느꼈는데, Features는 동사로 처리할 수 있는 부분을, Entities 명사로 처리할 수 있는 부분을 각 Layer에 배치한다고 이해했다.
프로젝트 시작 전 FSD에 대해 좀 많이 찾아봤는데, 프로젝트마다 사용하는 방식이 다 조금씩 달랐다.
https://feature-sliced.design/examples 에서도 여러 예시를 제공하는데, 깃허브 들어가서 소스 까보면 사용하는 방식이 다 다름;
FSD 자체가 자유도가 높은 아키텍처가 아니긴 하다.
그냥 FSD를 interface 정도로 생각하고, 저 규약에 맞춰서 내 프로젝트를 FSD의 구현체 정도로 생각하는게 좋을듯.
그러기 위해 초기 도입 시 팀원들간의 명확한 합의가 필요하다.
여러 차례 회의를 진행하고 FSD 관련 Team Rule을 만드는게 매우 중요함.
예를 들면.. 어떤 프로젝트에서는 나처럼 Features와 Entities를 구분하는게 혼란스러웠는지 Domain이라는 통합 계층으로 운영하는 경우도 있었음.
우리 팀이 만든 로컬 룰을 위키에 정리했다.
https://github.com/kakao-tech-campus-3rd-step3/Team21_FE/wiki/UniScope-FSD-Guideline-(Team-Rule)
각자 개발하다 보면 팀 규칙이 있더라도 본인의 코드 스타일대로 짜게 되는 영역이 있을 수 밖에 없는데..
일관된 코드를 위해서 강력한 로컬 룰, PR 병합 전 코드리뷰, CI/CD 파이프라인에 관련 Task 추가 등 코드 품질을 빡세게 잡아야 함.
프로젝트를 진행하면서도 문서화의 중요성을 굉장히~ 많이 느꼈다.
AI로 코드짜는 경우는 더더욱.. 요즘은 Cursor, Kiro 같은 AI IDE를 사용하는 사람도 많고, 다들 최소한 GPT나 학생 무료인 Gemini는 사용하니까.
특히 AI IDE를 사용할 때, 프로젝트 표준 문서를 project-standards.md 에 정의해두면 AI IDE가 코드 생성 전 저 지침을 따르기에 AI가 작성한 코드를 검사하기도 훨씬 편하다.
FSD같이 자유도가 높지 않은 아키텍처에 프로젝트 표준 문서를 함께 작성해두면 그때부터는 AI의 놀이터가 됨..
구조가 깔끔하게 떨어지는 아키텍처일수록 AI가 코드를 더 잘 뽑는다. (지침을 영어로 작성하면 더 잘하는 듯..)
FSD가 항상 정답인건 당연히 아니다. 프로젝트의 규모, 팀의 크기에 따라 FSD가 독이 되는 경우도 있음.
일단 FSD를 제대로 쓰려면 팀원들 모두가 FSD에 대해 잘 알고 있어야 함.
팀원 중 한 명이라도 FSD에 익숙하지 않다면 따로 스터디를 해야 한다.
Boilerplate가 좀 있는 편이다.
단순한 Form 하나를 만드려고 features/contact-form 만들고 ui | model | api | index.ts 를 설정하는건....
예전에 만든 별장 홍보 사이트인데.. 이거 만드려고 FSD를 적용하는건 그닥 좋은 선택은 아닌듯.
이것도 마찬가지. 그냥 페이지 하나짜리 WebShell 인데 이거 만드려고 FSD를 쓰나? 굳이? (근데 저건 FSD로 만들긴함ㅎㅎ)
도메인 객체가 5개를 넘어가고, 여러 개발자가 붙어서 작업해야 하는 경우 FSD를 도입을 고려해 보는게 좋다고 생각함.
협업할 때 좋은 아키텍처라고 생각한다. 슬라이스간 격리 원칙 덕분에 Merge Conflict가 적음.
FSD를 왜 쓰는건지? -> 읽기 쉬운 코드를 만들기 위해.
읽기 쉬운 코드를 만드는거지, AI나 개발자가 작성하기 쉬운 코드를 만들기 위해 FSD를 쓰는게 아니다.
유지보수하기 편한 아키텍처는 UI 구조와 코드 구조를 1:1로 매핑할 수 있는 아키텍처라고 생각함.
FSD를 사용하든 Layered-Architecture를 사용하든 그냥 어떤 아키텍처를 사용하든 사용 목적은 똑같다.
이 아키텍처대로 분리했을 때 유지보수가 편할까? 다른 사람도 이걸 봤을 때 쉽게 이해할 수 있을까? 나중에 유지보수하기 편할까? ...
아키텍처를 도입하는 이유를 잊지 말고.. 주객전도되지 않도록 주의하자.
당연한 말이지만 프로젝트를 관통하는 아키텍처를 하나 정의하고 그 아키텍처대로 개발하는건 필요하다.
코드 리뷰의 가이드라인이 될 수 있고, 모두가 해당 아키텍처를 알고 있다면 생산성도 높일 수 있음.
'💬 기록' 카테고리의 다른 글
| PACK-UP v2.0 온보딩 - 세미나 발표 (0) | 2026.01.02 |
|---|---|
| HOBBIT을 사용한 최적화 - 세미나 발표 (0) | 2025.12.31 |
| [eziwiki] Static Site Genearator with Markdown (0) | 2025.11.28 |
| Kakao Tech Campus 최종발표 - UniScope (0) | 2025.11.11 |
| 프론트엔드 아키텍처와 Feature-Sliced Design (1) (1) | 2025.08.31 |