# GraphQL이 Redux를 대체할 수 있다?
# 서두
일단 자극적일 수 있는 제목에 반응하여 들어오셨다면 사과드린다. 본 글에서 다루려는 원문의 제목이 그러하다. 원문은 링크를 참고하시길... How GraphQL Replaces Redux | Mark Johnson (opens new window)
이 글을 쓰게 된 이유는, 위의 글을 보고 나서 나의 많은 의문들이 해소되었기 때문이다. 그에 대한 내용은 따로 다른 글(Redux 회의론이란 글로 다룰 예정이다)에서 다루기로 하고, 이 글에서는 해당 주제만 다루도록 하자.
이 글은 번역문은 아니고, 해당 글의 중요한 부분을 요약해보고 나의 의견을 달아보는 목적으로 쓴다.
# 원문의 요약
한 문장으로 적어보면,
RESTful 대신 GraphQL을 도입함으로써 자연스럽게 Redux가 필요없게 되었다.
정도로 요약할 수 있다.
조금 더 자세히 적어보면...
- 저자가 속한 개발팀은 2016년 경에 Backbone & Marionette 스택을 사용중이었다.
- (필요성에 대한 언급은 없이) React로 개발 스택을 전환하였다.
- React에 매우 만족하였으나 곧 상태관리의 필요성이 부각되었다.
- Flux를 적용하고 만족하였다. (Redux 언급은 없으나 아마도 적용한 듯)
- 개선되었다고 느꼈으나, 금세 상태관리가 방대하고 복잡해져 갔다.
- 대시보드 기능을 만들면서 RESTful 대신 GraphQL을 도입하기로 했다.
- GraphQL에 매우 만족했고, 수많은 상태관리들이 필요없게 되었다.
- 결국은 모든 상태관리가 제거되고, 순수 React만 남게 되었다.
- 서버 통신이 1번이라면 Redux가 불필요할 수 있다.
- GraphQL 찬양...
# 나의 의견
저자가 극단적으로 쓴 경향이 있어서 댓글 토론이 조금 있긴 한데, 대체적으로 동의하는 모양이다. 나 역시도 꽤나 동의하는 편이다.
Redux, Redux-thunk, Redux-saga... 등등 이러한 툴들을 사용하는 이유는, 웹 애플리케이션의 상태관리가 복잡하기 때문이다. 복잡한 상태관리를 해결하려 들기 전에, 한발짝 물러서서 근본 원인을 생각해보자.
상태관리가 복잡한 이유는 비동기 프로그래밍이 불가피한 브라우저 환경에서 비동기 작업이 너무 연속으로 이어져 있는 것은 아닐까? 그리고 비동기 작업의 대부분은 서버와의 통신이고 말이다.
만약 사이트가 단순해서, RESTful API 호출 한번의 결과로 UI가 변경되는 수준이라면 콜백 함수 한두겹으로 충분할지도 모른다. 그렇다면 많은 부분에서 굳이 상태관리까지는 필요하지 않을 수도 있을 것이다.
물론 Redux가 완전히 사라져야 한다는 것은 아니다. 분명히 상태관리는 필요한 부분이고, Redux 같은 도구들이 그 역할을 훌륭히 해낼 것이다. 다만 설계에서부터 비동기 작업 횟수 자체를 줄일 수 있도록 하고 덜 중요한 상태들은 다른 대체제(Context API, RxJs 등)를 활용한다면, 상태관리가 방대해지거나 복잡해지는 정도를 크게 낮출 수 있을것이다.
나의 의견을 요약해보자.
- 서버와의 통신 횟수를 줄일수록 유리하다. GraphQL이 해결책이 될 수 있다.
- Redux가 상태관리를 잘 해낼 수 있지만 그렇다고 모두 집어넣지는 말자.
- 앱을 망가뜨릴 정도의 크리티컬한 상태값이 아니라면 Redux에 포함시키지 않는 것도 방법이다.
- State Machine Diagram으로 그려야만 이해할 수 있는 상태관리라면 Redux를 사용하는게 맞다.
정리해보니 Redux 원작자가 말하는 의도와 크게 다르지 않은 것 같다. 원문과 번역문도 참고하시길.
You Might Not Need Redux | Dan Abramov (opens new window)
당신에게 Redux는 필요 없을지도 모릅니다. | Sangyeop Bono Yu (opens new window)
동의하지 않는 분들도 계실 것이다. 이런 생각도 있다는 것을 참고만 하시길...