프론트엔드 설계 고민 -1-

SPA 컴포넌트 방식의 프로젝트의 경우 기본적인 entry 포인트가 존재한다. 그게 vue든 앵귤러든, 스벨트든 말이다.

index로 명명하든 main으로 명명하든 기본적인 SPA의 entry가 존재하고 이를 통해서 다양한 번들러나 트랜스 파일러들이 프로젝트를 파싱 해서 빌드한다.

 

이때까지는 보일러플레이트들을 따라서 만들다 보니 리액트 기준으로 index 파일에 store연결 등과 App컴포넌트(웹 애플리케이션 entry)를 바인딩하고 있었는데 최근 모종의 기회로 해당 부분에 대해서 생각을 되짚어볼 기회가 생겼다.

 

내가 내린 index와 app 파일의 정의는 각각 index: "개발 entry", app: "웹어플리케이션 entry"인데

store를 바인딩하는 것을 index에 넣는게 맞는 것일까? 각자의 관심사에 충실하고 있는 것일까? 내 기준에서 볼 때는 아니었다. 그런데 나는 그걸 아무 생각 없이 보일러 플레이트를 따라서 app이 아닌 index파일에 넣고 있었더라. 그래서 해당 요소를 정확히 구분 짓기 위해서 고민해보았다. 

 

과연 개발 entry라는 것과 웹 어플리케이션 entry를 쪼개었는데 둘 사이의 어떤 차이가 존재하는 것일까?

솔직히 어렴풋이 다르다고 생각하고 두루뭉술하게 넘어갔던 부분이라 디테일을 고민해야 했다. App이 돌아가고자 한다면 react나 vue 등의 렌더러가 필요하다. 그에 맞는 방식으로 애플리케이션 소스를 작성했으니 그렇다. react 방식으로 작성한 소스를 react-dom(리액트 렌더러) 없이 브라우저 환경에서 작동시킬 수 있을까? 안되더라. 그렇다면 react-dom 등을 일종의 런타임의 슈퍼셋 정도로 생각해볼 수 있지 않을까?

 

그렇게 생각 할 수 있다는 생각이 들었다. 그렇다면 index에서 react-dom으로 기존 static html의 dom에 App을 연결하는 것은 웹 애플리케이션(App)에 특정 런타임을 제공하는 것이라는 생각이 들었다. 그것은 웹 애플리케이션에 속하지 않는다. 그보다는 index 즉 개발 환경에 속한다. 비슷한 예로는 모듈 핫 로딩이나 서비스 워커를 들 수 있을 거 같다. 즉 index(main) entry에는 애플리케이션이 구동하는데 필요한 부트스트랩(정확하진 않다.)을 제공하는 게 해당 네임스페이스에 맞는 관심사라는 생각이 들었다. 

 

그렇다면 store를 어째서 해당 부분에서 제공했을까? 기존의 store를 일종의 로컬스토리지와 비슷한 저장소로 본 게 아닐까 생각이 든다. 그러나 현재 개발 환경에서는 다양한 인터페이스를 가진 상태 관리 소스들이 많아졌으므로 특정 상태 관리에 대한 종속성은 웹앱이 가진다. 그러니 App부분에서 store를 프로 바인더 해주는 게 합리적이라는 생각이 들었다.

조금 더 간단히 생각해보면 index에 다른 리액트 웹앱을 넣었을때 문제가 생기면 관심사 분리가 적절하게 되지 않았다고 볼 수 있을 거 같다.

 

App의 경우 기본적인 라우팅과 해당 웹앱이 가진 상태(store) 글로벌 style 같은 요소들을 바인딩 하는게 가장 적절하다는 생각이 들었다. 다만 라우팅의 경우 csr이나 ssr에 관련 없이 pages나 router 등의 dir구조로 따로 구분하는 게 적절하니 pages dir가 라우팅에 대한 모든 것을 담당하는 게 도메인 측면에서도 합리적이라는 생각이 들었다. next.js 등의 따로 해당 부분을 파싱 해서 라우팅 해주는 부분이 없을 경우 따로 index나 routes 같은 이름을 가진  root 파일로 라우팅들을 모두 묶어서 내보내고 그것을  App에서 바인딩하는 구조를 취하는 게 적절하다는 생각이 들었다.

 

정리하자면 

 

index(main) : 부트스트랩(런타임 슈퍼셋) 만을 제공한다.

App : 웹어플리케이션 config, store 등

Pages(router) : 라우팅에 대한 dir