당신이 사용하는 Angular에는 상태관리 라이브러리가 필요 없을지 모릅니다.

  얼마 전 Angular 한국 커뮤니티인 Angular Korean User Group 슬랙 그룹에서 Angular에 상태관리 라이브러리가 필요한지에 대해 이야기를 나눈 적이 있었다.

  그것을 발단으로 해서 개인적으로 구글링을 통해 여러 블로그 글을 읽었다. 결과적으로 나는 Angular를 사용하면서 아직까지 상태관리 라이브러리가 필요하다는 생각을 해보지 못했고, 앞으로도 상태관리 라이브러리가 필요 없을 것이라는 생각이 들었다.

  1_상태 관리 라이브러리

  상태 관리 라이브러리의 가장 코어 기능은 어플리케이션에 흩어져있는 데이터를 한 곳에서 관리하여, 데이터에 대한 변경이 발생하면, 변경된 데이터를 신속, 정확하게 전파 하여 일관된 데이터를 가지도록 하는 것이다.  이 개념은 React의 Flux에서 시작되었으며, React 진영에서는 Flux, Redux, Mobx가 대표적인 상태 관리 라이브러리이고, Angular 진영에서는 ngrx가 대표적인 상태 관리 라이브러리 이다. (Angular에서 Redux, Mobx를 쓰지 못하는 것은 아니다.)

  일반적인 상태 관리 라이브러리의 경우, Store라는 데이터 저장소를 만들고 Action, Reducer, Dispather 등을 이용해 데이터를 수정, 전파 한다. 전파된 데이터는 View를 관리하는 라이브러리에 의해 데이터에 맞게 수정된다.  따라서, 상태 관리 라이브러리는 Reactive Programming을 가능케 한 장본인인 것이다. 또한, 동작 방식을 보게 되면, 엄격하게 단방향으로 상태가 전파가 되기 때문에 동작 하는 모습을 그림으로 그려보면 마치 상태가 어플리케이션에서 흐르고있는 듯한 모습을 볼 수 있다.

2_ngrx

  Ngrx는 Redux에서 영감을 받아 Rxjs로 만들어진 Angular를 위한 상태 관리 라이브러리 이다. Redux의 영향을 받은 것이기 때문에 Redux의 Store, Dispather, Action, Reducer을 이용해 Angular의 상태를 관리 한다. 기본적으로 Angular에서 사용하기 위해 만들어졌기 때문에 Typescript를 이용하며, Angular의 특징 중 하나인 DI를 적극 활용하는 모습을 보인다. Redux의 모습을 잘 가지고 있으면서 Angular에서 사용했을 때 어색하지 않을 만큼 완성도 높게 만들어져있다.

  지금 당신이 React에서 Redux를 이용해 상태관리를 하면서 어플리케이션을 만들어봤고, 이번에는 Angular를 공부하면서 새로운 어플리케이션을 만들어보고 싶다면 ngrx를 적극 추천한다.

  하지만, 당신이 아직 어떤 프레임워크(라이브러리)로도 어플리케이션을 만들어보지 않았고, Angular를 이용해 어플리케이션을 만들기로 마음먹었다면, ngrx를 두꺼운 백과사전에 부록으로 생각하면 좋을 것 같다.

  3_Angular의 Input, Output, Serivce

  

  Angular의 공식 문서에서 Input, Output은 부모와 자식  컴포넌트 간의 상태 전달를 하기 위해 만들어졌다.라고 설명한다. 일반적인 경우에 부모 컴포넌트에서 Input을 통해 자식 컴포넌트로 데이터를 전달하고, 자식 컴포넌트에서 이벤트 등에 의해 데이터가 변경되었다면, Output을 통해 변경된 데이터를 부모 컴포넌트로 전달 할 수 있다.

  하지만, 직계 부모, 직계 자손이 아닌 사촌 컴포넌트나 조부모, 증조부모쯤 되는 컴포넌트와 Input, Output을 통해 데이터를 주고 받는 경우가 생기게 되면 여간 귀찮은 일이 아니게 된다. 그럴 때 공식 문서에서는 Service를 이용하라고한다.

  Service의 일반적인 사용은 HTTP Request를 통해 백엔드로 부터 데이터를 들고오는 작업을 하는데 사용한다. 하지만, Redux의 Store 처럼 만들 수도 있는 것이다. 하지만, Store와 차이점이 있다면, Service는 Store와 달리 1개로 강제 되지 않고 여러 Service를 만들 수 있다는 것이다. (이 방법은 차라리 Mobx와 비슷하다.)

  사용법은, Service에 상태 관리할 대상을 Rxjs의 Subject로 만들고, 상태 변경을 .next()로 전파하는 방식으로 하게 된다. 이렇게 되면 상태를 Observable하게 상태를 관리할 수 있게 되고, Observer Pattern을 가진 Rxjs가 상태 전파에 탁월하기 때문에 상태 관리를 용이하게 할 수 있다.

  이런 방법을 사용하게 되면 굳이 ngrx를 사용하지 않더라도, Angular에서 사용되는 Rxjs만 이용해 상태를 손쉽게 관리 할 수 있다는 것이다.

  4_Every state have to be under control?

  이 글을 준비하기전 나는 ngrx에 관심이 있었다. 상태를 많이 사용하는 프로젝트를 한번더 맡게 된다면 한번쯤은 사용해 볼 만하다고 생각했다. 하지만 지금은 생각이 조금 바뀌었다. 생태가 많은 프로젝트라도 컴포넌트 간의 상태 전파가 많지 않다면 ngrx도, Service도 굳이 필요 없다는 것이다. 모든 상태는 상태 관리 라이브러리 혹은 Service의 관리 하에 있지 않아도 된다고 생각한다. 왜냐하면 해당 컴포넌트에서만 사용하는 데이터의 경우라면 굳이 상태관리 라이브러리의 관리를 받지 않고 해당 컴포넌트 내에서 알아서 할 수 있기 때문이다.

  하지만, 여러 컴포넌트 사이에서 사용되는 상태라면, Input,Output이 되었던, Service가 되었던, ngrx가 되었던 상태 관리의 관리를 받고 있어야 한다고 생각한다. 그래야 일관적인 데이터를 유지 할 수 있고, 데이터 변경에 따른 정상적인 모습을 사용자에게 보여줄 수 있기 때문이다.

  5_끝으로

  여러 컴포넌트를 날뛰는 상태들은 야생마같은 친구들이기 때문에 언제나 고삐를 쥐고 있어야 한다. 그 고삐는 Service가 되어도 좋고, Input, Output이 되어도 좋고 ngrx가 되어도 좋다. 상태 관리는 모든 어플리케이션에서 필요하지만, 상태관리 라이브러리는 모든 어플리케이션이 필요하지 않다.

  혹, 저와 다른 생각을 가지고 계시거나, 제가 틀린 부분이 있으면 댓글로 알려주시길 바랍니다. 여러분의 댓글이 더 나은 저를 만듭니다. 감사합니다.