[P.E.C 졸업생 인터뷰 최동희] 리팩토링은 미래의 나를 위한 선물?!(FSD 를 사용한 리팩토링 경험)

FSD를 처음 접한 계기와 왜 리팩토링을 결심했나

최동희 님은 올해 두 개의 프로젝트를 동시에 진행하면서 프론트엔드 개발을 주로 맡았어요. 한 프로젝트는 문서 기반 검색 기능을, 다른 하나는 LLM 모델을 활용해 문서 작성을 도와주는 도구였죠. 특히 후자 프로젝트는 혼자서 프론트엔드를 전담하다 보니 비즈니스 로직이 점점 한 곳에 몰리면서 코드가 복잡해졌습니다.

기존에는 폴더를 대충 나누고 컴포넌트 안에 모든 로직을 넣는 방식으로 개발했어요. 그러다 보니 나중에 코드를 볼 때 “이게 어디에 쓰이는 거지?” 하는 상황이 자주 발생했죠. FSD(Feature-Sliced Design)를 알게 된 후, “이대로 두면 나중에 내가 더 힘들겠다”는 생각이 들었다고 해요.

리팩토링을 결심한 이유는 간단해요. 유지보수를 편하게 하기 위해서였죠. 한 달 동안 코드를 완전히 갈아엎는 작업을 하면서 스트레스를 많이 받았지만, 지금은 만족도가 매우 높다고 합니다. 처음 접하시는 분들을 위해 설명드리면 FSD는 기능을 중심으로 폴더를 나누는 구조예요. 공통 UI는 shared 폴더에, 특정 기능은 features 폴더에 넣어서 찾기 쉽고 수정하기 편하게 만드는 거죠.

실제로 FSD로 갈아엎은 과정과 느낀 장점

리팩토링은 한 번에 다 하지 않고 중요도가 높은 부분부터 차근차근 진행했어요. 예를 들어 로그인 관련 화면이나 문서 요약 기능을 먼저 FSD 구조로 바꾼 뒤, 나머지 부분을 순차적으로 손봤습니다. 컴포넌트 단위로 나누어 작업했기 때문에 전체를 멈추지 않고도 진행할 수 있었죠.

FSD를 적용하면서 가장 크게 느낀 장점은 두 가지예요. 첫째, 공통 UI와 비즈니스 로직의 위치가 명확해졌다는 점입니다. 예전에는 버튼 스타일이나 유틸 함수가 여기저기 흩어져 있었는데, 이제는 shared 폴더만 보면 한눈에 파악돼요. 둘째, 컴포넌트가 자연스럽게 작아지면서 한 페이지에 모든 코드가 몰려 있던 문제가 해결됐습니다.

비교해 보면 기존 모놀리식 구조에서는 수정 한 번 할 때마다 여러 파일을 뒤져야 했지만, FSD 적용 후에는 해당 기능 폴더만 열면 끝났어요. 실제로 유지보수 시간이 줄었다고 느끼는 부분이 바로 이 지점입니다. 다만 Zustand 같은 상태 관리 라이브러리를 쓸 때 스토어 설계를 잘 해야 한다는 점은 주의해야 해요. 스토어가 너무 커지면 의존성이 복잡해질 수 있거든요.

리팩토링을 하면서 배운 실전 팁과 앞으로의 고민

리팩토링 시간을 확보하는 것도 쉽지 않았어요. 일정이 촉박한 상황에서 “이걸 왜 지금 하느냐”는 질문이 나올 수 있는데, 최동희 님은 중요도가 높은 이슈부터 먼저 리팩토링하면서 자연스럽게 시간을 끌었다고 해요. 이렇게 점진적으로 진행하면 팀원들도 거부감이 적어요.

또한 Cursor 같은 AI 에디터를 적극 활용했어요. 함수나 변수 이름을 지을 때 추천을 받아서 시간을 많이 절약했다고 합니다. 특히 이름 짓는 데 고민이 많았던 분이라면 AI 도구가 큰 도움이 될 거예요. 다만 AI가 제안한 코드를 그대로 쓰지 않고 꼭 검토하는 습관이 중요합니다.

앞으로 최동희 님은 B2C 프로젝트를 준비하면서 모노레포 도입을 고민 중이에요. Turborepo나 Nx 같은 도구를 살펴보고 있는데, 아직 프로젝트 규모가 크지 않아서 당장은 쉽게 가는 방향을 고려하고 있다고 해요. 여러분도 비슷한 고민이 있다면, 먼저 작은 프로젝트에 FSD부터 적용해 보는 걸 추천드려요.