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

일반적인 웹 애플리케이션을 구성하는 부분은 어떤 게 있을까? 해당 웹의 라우팅, 해당 웹의 UI, 해당 웹의 상태

사용자 액션에 따른 요청 처리 등을 생각해 볼 수 있다.

 

간단하게 정의 내리면 라우팅은 두 가지 측면을 가진다. 해당 애플리케이션의 절차라는 측면과 해당 애플리케이션이 제공하는 서로 다른 도메인을 가진 기능이라는 측면으로 말이다.

즉 동일 도메인 내의 플로우나 서로 다른 도메인을 라우팅으로 구분지어서 제공 할 수 있다.

 

도메인의 경우 보통 루트에 가까운 라우팅으로 나뉘는 경우가 대부분이지만 특정 액션이 복잡하거나 반드시 특정 절차를 따라서 지켜져야 한다면 복잡도가 증가함에 따라서 동일한 도메인에 속하더라도 서로 다른 도메인으로 분리해서 취급 하는게 좋을 것이다. 라우팅을 통해서 코드스플릿까지 염두에 둔다면 사용자 ux측면에서 각 액션의 절차를 동일한 라우팅 내에서 조건부 렌더링으로 처리하지 않고 라우팅을 쪼갠다거나 하는 부분도 고려 할 만한 점이다.(이건 경우에 따라 다를 것이지만)

 

라우팅의 경우 router나 pages 같은 특정 dir에서 해당 도메인을 담당하고 그것을 App에 바인딩 하는 정도 겠지만

해당 라우팅의 UI나 사용자 액션등을 처리하는 부분(프레젠테이션 레이어와 컨테이너 레이어)을 등은 또 따로 도메인으로 구분지어주는게 좋다.

예시 : App -> 라우팅 -> 해당 도메인에 맞는 컴포넌트 집합.

라우팅 자체에서는 순수하게 라우팅에 대해서만 신경쓰는게 책임과 관심사에 적합하기에 그렇다. 

구조로 따지면 pages dir : index(root), home(메인페이지), sub1,sub2로 되어 있고 root는 각 라우팅을 묶어서 웹 어플리케이션에 내보내는 역할을 맡고 각 home이나 sub1등의 페이지는 도메인에 맞는 라우팅 구조를 보여주고 그 라우팅(도메인)이 제공해야 할 모든 서브 라우팅과 그에 적합한 컴포넌트를 바인딩해서 보여주는 구조다.

 

단순한 렌딩 페이지 정도가 아닌 이상은 모든 웹애플리케이션은 각자 애플리케이션에 맞는 상태를 가진다. 각 렌더링에 적합한 상태의 경우 해당 컴포넌트가 상태를 가지겠지만 웹어플리케이션 전역 상태의 경우 웹어플리케이션 root부터 프로바인딩 해줘야한다. 그렇기에 App 컴포넌트에서 store를 프로바인딩 해준다. 그리고 store 상태에 대한 1차적인 정의나 액션 등을 store dir 구조로 store 구조를 정의해준다. 보통 웹 어플리케이션 상태를 store라고 네이밍하기에 store라고 네이밍 했으므로 각 상태관리 오픈소스에 따라서 store 내부 구조는 달라진다. 중요한 것은 결국 store에 대한 정의나 모델링을 담당한다는 것이다.

 

개인적으로 웹애플케이션 규모가 비대해짐에 따라서 웹어플리케이션을 MSA 방식으로 여러 컨테이너(서버보다는 이게 더 적합한 개념일듯)에서 서비스하는 것이 적절할지 아니면 그 웹어플리케이션의 각 도메인에 맞게 분리된 store 구조를 짜는게 적합할지 트레이드 오프가 어떻게 되는지 고민중이다. 이부분은 엔터프라이즈 규모의 프론트엔드 설계를 실제 실무에서 해본적이 없기 때문에 여러가지 가설만 가지고 있다. 실제로 해당 가설들을 검증 해볼려면 유의미 할 정도로 규모가 되는 서비스가 아니라면 검증 해볼 수 없기 때문에 이런 점은 벡엔드에서 대용량 트래픽을 체험 할 수 있는 환경이 제한 되는 것과 유사한 측면이다.

 

각 도메인에 대한 설계나 store에 대한 설계를 고민해보았으니 이제 웹어플리케이션의 사용자 액션이나 비즈니스 로직 즉 view model 측면에서 고려해볼 차례다. 리액트의 경우 고전적으로 프레젠테이션 레이어와 컨테이너 레이어를 각 컴포넌트로 나누어서 처리를 했었고 함수 방식으로 넘어온 이후에는 커스텀 훅이라는 수단으로 컨테이너 레이어를 분리하기 시작했다. 이런 점은 리액트의 컨셉과 관련이 있기도 하지만 fp을 지향하지 않더라도 oop 측면에서 보아도 SOLID 룰이나 MVC기반 디자인 패턴을 생각 해보았을때 딱히 리액트와 큰 차이를 보이지 않는다. 설사 그게 벡엔드라 할지라도 말이다.

즉 단순한 UI 즉 view와 해당 UI를 구성하는 data model을 구분짓고 또 그 model을 서비스 레이어등을 통해서 나누듯이 사용자 액션이나 각 세부적인 레이어 컨셉에 적합한 수준의 격리를 진행 해야 한다는 것이다.

 

이부분의 경우 나는 최소한도의 레이어로 view model을 담당하는 custom hooks와 view를 담당하는 UI컴포넌트로 나누고 그 사이에 provider나 controller 등 각 구조가 비대해짐에 따라서 레이어를 분리하는 방식을 지향하는게 적합하다고 판단을 하고 있고 실제로 도메인 복잡성을 고려해서 레이어를 적절하게 쪼개는 것을 선호한다.

 

UI의 경우 components라는 dir에 아토믹이나 기타 디자인 패턴을 적용해서 구조를 짜고 관리 해준다. 단순하게 UI 컴포넌트들을 가지고 있다. 일종의 디자인 시스템이라고 봐도 상관 없을듯 하다.

hooks의 경우 hooks dir로 관리해준다.각 page의 view의 경우 dir가 각각 도메인에 따라서 따로 존재한다. 해당 page에 적합한 UI와 view model과의 바인딩의 경우 프로젝트 구조에 적합하게 가져간다. 다만 개인적으로 그에 적합한 구조로 검토 중인게 몇가지 있긴하다. 

이들 간의 사이와 구조를 고민하는데 있어서 엔터프라이즈 레벨의 아키텍쳐 적인 측면과 그 정도 규모가 되지 않는 일반적인 웹어플케이션 사이의 적절한 절충안(유연성)을 가지는 구조를 고민해보는게 상당히 중요한 측면을 가지는데 프로그램이란 결국 코드를 어떻게 적절하게 관리하냐에 따라서 유지보수나 확장성적인 측면이 상당히 많은 영향을 받기 때문이다. 그렇기에 이 부분은 다음 글에서 추가적으로 자세히 풀어보겠다. 사실 지속적으로 고민 중인 부분이다.

 

정리하면

App은 전역 상태를 가진다.(store) 그리고 각 도메인에 맞는 플로우(라우팅)을 가지고 그 도메인은 적합한 ui와 data를 가진다.