모듈 사이클링 문제
이전에 1차적으로 관심사의 분리라는 주제로 리팩토링을 진행할 때 나름의 규칙을 정하고 관심사를 분리했다. 하지만 React-query와 zustand로 전환하는 과정에서 관심사 분리 기준에 대한 문제점을 인지했다.
문제 인지
무엇보다 ESLint를 적용하는 과정에서 모듈 간의 사이클 문제가 발생했다. 이는 export하는 모듈과 import하는 모듈 간의 서로를 참조하는 상황이 발생하여 오류가 발생한 것이다. 이런 경우 서로를 참조할 뿐만 아니라, 그 import하는 모듈이 다른 곳에서 사용되는 경우가 있어 하나를 수정하면 또 다른 문제가 발생하고, 마치 의존성이 거미줄처럼 엮여있는 현상을 겪게 된다.
임시 차단
임시적으로 lint 규칙에 import/no-cycle: off를 설정하여 문제를 차단했다. 이는 어디까지나 임시 방편이다.
원인 분석
주로 타입을 참조하는 과정에서 위의 문제가 발생했다. 나름 도메인별로 분리하기 위해 디렉토리 규칙을 만들었지만, 그 규칙이 체계적이지 못했다. 해당 도메인에서만 사용하는 타입의 경우 필요한 경우 코드의 상단에 선언하고 돌려쓰는 형태로 사용한 것이 문제였다.
본격적인 해결
해당 문제를 근본적으로 해결하기 위해 많은 코드 점검이 필요하다고 판단했다. 이에 따라 RootLayout부터 시작해 하나씩 점검하면서 디자인도 조금씩 수정할 계획을 세웠다. Layout을 리팩토링하는 과정에서 또 하나의 문제가 발생했다. Sidebar를 Navbar로 전환하는 과정에서 RootLayout에 Navbar를 두는 게 맞는지 의문이 들었다. 그래서 Header로 변경했다. 이렇게 하니 더 명확했다. Header 내부에 Navbar를 두고 브랜드 로고와 유저 메뉴를 분리하면 더 명확할 것이라 생각했다. 하지만 여기서 또 문제가 발생했다. 과연 Header와 Navbar를 같은 components 폴더에 두는 게 맞는지, 아니면 common 폴더를 만들어 나눠야 하는지 경계가 너무 혼잡했다. 일단 우선적으로 분리하고 다음을 생각하기로 했다.
Components/Domain
현재 구조는 컴포넌트 안에 도메인을 기준으로 분리하는 형태를 취했다. 그리고 도메인 폴더 안에는 해당 도메인에 필요한 hooks가 있고, 각 기능별로 폴더를 한 번 더 나눴다. 과연 이게 컴포넌트 안에 포함되어도 되는걸까? 하나의 문제는 마치 도미노처럼 연쇄적인 문제로 이어졌다. 확실한 기준을 정하고 싶었다. 프로젝트 구조에 대해 검색을 해보았다. 대부분이 모놀리식 구조를 이야기한다. 모놀리식 구조는 작은 프로젝트에서는 잘 분리되고 파일 관리에 문제가 없지만, 파일이 많아지고 컴포넌트가 많아질수록 무엇을 어디에 두어야 할지 경계가 애매하다는 것을 느꼈다. 그러던 과정에서 단테님의 FSD 강의를 시작으로 해외 포럼에서 유명한 FSD 글을 접하게 되었다. 현재의 나름 세운 기준에 근접한 아키텍처였지만, 좀 더 명확하고 이 구조를 사용하면 모듈 사이클 문제를 방지할 수 있다고 생각했다.
