<div id="readability-page-1" class="page"><div id="skip-nav"><h2>풀스택 장고 프로젝트에서 부분적으로 리액트를 도입한 이야기</h2><p><time>22.12.2019</time> — <a href="/tags/일">일</a>, <a href="/tags/개발">개발</a>, <a href="/tags/react">React</a>, <a href="/tags/django">Django</a> — <span>2 min read</span></p><section><p>약 1년 전에  풀스택 장고 프로젝트에서 부분적으로 리액트 도입을 결정했던 이야기를 남깁니다.</p><h4>배경</h4><p>기존에 제공하던 웹 서비스를 유지하면서 동시에 안드로이드 앱의 개발을 진행하게 되었습니다. 당연하게도, 안드로이드 앱을 위한 API를 구현하게 되었습니다. 또 당연하게도, 장고 프로젝트를 유지하면서 기존에 설계된 모델을 재사용하여 API를 구현할 수 있는 DRF(Django Rest Framework)를 도입하게 되었습니다. DRF는 개인적으로도 친숙한 프레임워크이고, 함께 웹 서비스를 개발하던 동료도 장고에 익숙한 상황이라 아주 적은 비용으로 도입할수 있었습니다. </p><p>우여곡절이 없는 것은 아니었지만, 그렇게 거의 모든 비즈니스 로직을 API로 구현하는데 성공했습니다.</p><h4>좋은 사용자 경험과 좋은 개발 경험</h4><p>안드로이드 앱이 서비스 그 자체에 있어서 최고의 사용자 경험을 추구하는 것과 마찬가지로, 웹은 결제 과정에서 최고의 사용자 경험을 추구하기로 했습니다.</p><p>원래 제공하던 웹 서비스는 풀스택 장고로 구현되어 있었습니다. 즉 완전한 서버 사이드 렌더링을 하고 있었던 것입니다. 서버 사이드 렌더링이 나쁜 것만은 아니지만 좋은 사용자 경험을 위해서는 클라이언트 사이드 렌더링이 필연적으로 필요할 수 밖에 없었습니다.</p><p>사실 장고 풀스택으로 이루어진 기존 서비스도 일부 핵심적인 서비스, 즉 최고의 사용자 경험을 추구해야 하는 곳에는 이미 어느정도 클라이언트 사이드 렌더링이 구현되어 있었습니다. 다만 문제는 그것이 바닐라 JS와 jQuery를 이용해서 구현되어 있다는 점이었죠. (물론) 바닐라 JS와 jQuery가 나쁜것만은 아닙니다. 다만 아무래도 원래 jQuery가 클라이언트사이드 렌더러, 혹은 클라이언트 상태관리 컨테이너로 설계되지는 않았기 때문에, 코드의 유지관리가 점점 어려워졌습니다.</p><p>기획팀에 의해 새롭게 설계된 결제 퍼널은 클라이언트 사이드 렌더링에 크게 의존적이었습니다. 그 모든 렌더링과 상태 관리를 바닐라 JS와 jQuery를 이용해서 구현한다는 것은, 마치 우리만의 독자적인 라이브러리를 구현하겠다는 것과 비슷한 의미로 느껴질 정도였죠. 참 다행히도 세상에는 훌륭한 분들이 뛰어난 라이브러리를 만들어 놓았으니, 우리는 그것 중 하나를 선택하기로 했습니다.</p><h4>리액트</h4><p>라이브러리 선택의 기준은 두가지였습니다.</p><ol><li>라이브러리를 빠르게 도입할 수 있어야 한다. (도입비용과 학습비용)</li><li>서비스를 빠르게 구현할 수 있어야 한다. (생산성)</li></ol><p>처음 생각했던 것은 Vue.js였습니다. 일단 저는 리액트에 익숙하지만, 뷰 역시 리액트와 비슷하다는 증언을 수차례 접했으므로 학습비용이 크진 않을것 같았습니다. 같이 프로젝트를 진행할 동료 개발자는 이미 뷰를 어느정도 학습하고 있는 상황이기도 했고요. 무엇보다 리액트는 웹팩 등과 같은 개발환경을 세팅해야 한다는 도입비용이 있는 반면에, 뷰는 그런 과정없이 바로 도입할 수 있다는 것이 (하루하루가 소중한 우리들에게는) 굉장히 매력적이었습니다. 낮은 도입비용으로 뷰가 낚시를 한다는 이야기도 들었지만, 어쨌거나 우리는 정말로 급했으니까요.</p><p>하지만 이 결정은 곧 뒤집혔습니다. 먼저 뷰의 길을 개척하러 나선 동료 개발자가 결국 뷰를 제대로 사용하기 위해서는 웹팩을 사용해야 한다는 의견을 제시하면서 부터였습니다. 우리가 뷰를 사용하고자 했던 이유는 어떻게 보면 웹팩을 안써도 되기 때문이었는데, 결국 웹팩을 세팅해야하는 오버헤드가 동일하게 있다면 굳이 팀에서 그나마  가장 익숙한 리액트를 버리고 모두에게 새로운 뷰를 쓰는 것이 오히려 속도를 내는데 불리할 것이기 때문이었습니다.</p><h4>타입스크립트</h4><p>라이브러리는 가장 익숙한 리액트를 골랐지만, 언어는 아무도 써보지 않은 타입스크립트를 쓰기로 했습니다. 왜 이런 상반된 결정을 하게 되었냐면, 우리가 너무 많은 실수를 한다는것을 우리가 잘 알기 때문이었습니다. 빨리 달리고 싶지만, 안전하게 달리고 싶었습니다. </p><h4>리액트 한 입만 주세요!</h4><p>이번 프로젝트에서 가장 큰 기술적인 고민은 리액트를 딱 한 입만 먹고 싶다는 것이었습니다. 많은 리액트 부트스트래핑툴과 예제들은 리액트를 이용해서 SPA를 만드는 것을 상정하고 있었습니다. 하지만 우리는 여러 페이지로 구성된 웹 어플리케이션에서 딱 한 페이지의 한 부분만 리액트로 렌더링하고 싶었습니다.</p><p>아이디어는 <code>react-router</code>를 이용하는 것이었습니다. <code>react-router</code>는 브라우저의 URL에 따라 알맞는 리액트 컴포넌트를 렌더링하는 일을 담당합니다. 일반적인 SPA라면 앱의 모든 URL 경로를 라우팅할 것이지만, 우리는 우리가 원하는 특정 경로에만 라우터를 설정하고, 리액트 컴포넌트가 렌더링 될 루트 HTML DOM을 다른 경로에선 노출시키지 않는 것입니다.</p><p>실제로 이 전략으로 조금씩 리액트가 담당하는 영역을 늘려나가서 지금은 모든 웹 페이지가 리액트 컴포넌트로 렌더링되고 있습니다. 최초 도입부터 완전한 전환까지 약 1년정도 걸린것 같네요. 빨리 하려고 했으면 더 빨리 할 수도 있었겠지만, 급하게 전환할 이유가 딱히 없어서 전환은 천천히 진행되었습니다. </p><p>리액트를 필요한 부분에서만 쓰는 것이 생각보다 쉽고, 부분적으로 썼을 때 아무런 문제가 없다는 사실을 알 수 있었습니다.</p></section></div></div>

Minimal Blog - @lekoarts/gatsby-theme-minimal-blog

Minsik Kim

약 1년 전에  풀스택 장고 프로젝트에서 부분적으로 리액트 도입을 결정했던 이야기를 남깁니다.
배경
기존에 제공하던 웹 서비스를 유지하면서 동시에 안드로이드 앱의 개발을 진행하게 되었습니다. 당연하게도, 안드로이드 앱을 위한 API를 구현하게 되었습니다. 또 당연하게도, 장고 프로젝트를 유지하면서 기존에 설계된 모델을 재사용하여 API를 구현할 수 있는 DRF(Django Rest Framework)를 도입하게 되었습니다. DRF는 개인적으로도 친숙한 프레임워크이고, 함께 웹 서비스를 개발하던 동료도 장고에 익숙한 상황이라 아주 적은 비용으로 도입할수 있었습니다. 
우여곡절이 없는 것은 아니었지만, 그렇게 거의 모든 비즈니스 로직을 API로 구현하는데 성공했습니다.
좋은 사용자 경험과 좋은 개발 경험
안드로이드 앱이 서비스 그 자체에 있어서 최고의 사용자 경험을 추구하는 것과 마찬가지로, 웹은 결제 과정에서 최고의 사용자 경험을 추구하기로 했습니다.
원래 제공하던 웹 서비스는 풀스택 장고로 구현되어 있었습니다. 즉 완전한 서버 사이드 렌더링을 하고 있었던 것입니다. 서버 사이드 렌더링이 나쁜 것만은 아니지만 좋은 사용자 경험을 위해서는 클라이언트 사이드 렌더링이 필연적으로 필요할 수 밖에 없었습니다.
사실 장고 풀스택으로 이루어진 기존 서비스도 일부 핵심적인 서비스, 즉 최고의 사용자 경험을 추구해야 하는 곳에는 이미 어느정도 클라이언트 사이드 렌더링이 구현되어 있었습니다. 다만 문제는 그것이 바닐라 JS와 jQuery를 이용해서 구현되어 있다는 점이었죠. (물론) 바닐라 JS와 jQuery가 나쁜것만은 아닙니다. 다만 아무래도 원래 jQuery가 클라이언트사이드 렌더러, 혹은 클라이언트 상태관리 컨테이너로 설계되지는 않았기 때문에, 코드의 유지관리가 점점 어려워졌습니다.
기획팀에 의해 새롭게 설계된 결제 퍼널은 클라이언트 사이드 렌더링에 크게 의존적이었습니다. 그 모든 렌더링과 상태 관리를 바닐라 JS와 jQuery를 이용해서 구현한다는 것은, 마치 우리만의 독자적인 라이브러리를 구현하겠다는 것과 비슷한 의미로 느껴질 정도였죠. 참 다행히도 세상에는 훌륭한 분들이 뛰어난 라이브러리를 만들어 놓았으니, 우리는 그것 중 하나를 선택하기로 했습니다.
리액트
라이브러리 선택의 기준은 두가지였습니다.
라이브러리를 빠르게 도입할 수 있어야 한다. (도입비용과 학습비용)
서비스를 빠르게 구현할 수 있어야 한다. (생산성)
처음 생각했던 것은 Vue.js였습니다. 일단 저는 리액트에 익숙하지만, 뷰 역시 리액트와 비슷하다는 증언을 수차례 접했으므로 학습비용이 크진 않을것 같았습니다. 같이 프로젝트를 진행할 동료 개발자는 이미 뷰를 어느정도 학습하고 있는 상황이기도 했고요. 무엇보다 리액트는 웹팩 등과 같은 개발환경을 세팅해야 한다는 도입비용이 있는 반면에, 뷰는 그런 과정없이 바로 도입할 수 있다는 것이 (하루하루가 소중한 우리들에게는) 굉장히 매력적이었습니다. 낮은 도입비용으로 뷰가 낚시를 한다는 이야기도 들었지만, 어쨌거나 우리는 정말로 급했으니까요.
하지만 이 결정은 곧 뒤집혔습니다. 먼저 뷰의 길을 개척하러 나선 동료 개발자가 결국 뷰를 제대로 사용하기 위해서는 웹팩을 사용해야 한다는 의견을 제시하면서 부터였습니다. 우리가 뷰를 사용하고자 했던 이유는 어떻게 보면 웹팩을 안써도 되기 때문이었는데, 결국 웹팩을 세팅해야하는 오버헤드가 동일하게 있다면 굳이 팀에서 그나마  가장 익숙한 리액트를 버리고 모두에게 새로운 뷰를 쓰는 것이 오히려 속도를 내는데 불리할 것이기 때문이었습니다.
타입스크립트
라이브러리는 가장 익숙한 리액트를 골랐지만, 언어는 아무도 써보지 않은 타입스크립트를 쓰기로 했습니다. 왜 이런 상반된 결정을 하게 되었냐면, 우리가 너무 많은 실수를 한다는것을 우리가 잘 알기 때문이었습니다. 빨리 달리고 싶지만, 안전하게 달리고 싶었습니다. 
리액트 한 입만 주세요!
이번 프로젝트에서 가장 큰 기술적인 고민은 리액트를 딱 한 입만 먹고 싶다는 것이었습니다. 많은 리액트 부트스트래핑툴과 예제들은 리액트를 이용해서 SPA를 만드는 것을 상정하고 있었습니다. 하지만 우리는 여러 페이지로 구성된 웹 어플리케이션에서 딱 한 페이지의 한 부분만 리액트로 렌더링하고 싶었습니다.
아이디어는 react-router를 이용하는 것이었습니다. react-router는 브라우저의 URL에 따라 알맞는 리액트 컴포넌트를 렌더링하는 일을 담당합니다. 일반적인 SPA라면 앱의 모든 URL 경로를 라우팅할 것이지만, 우리는 우리가 원하는 특정 경로에만 라우터를 설정하고, 리액트 컴포넌트가 렌더링 될 루트 HTML DOM을 다른 경로에선 노출시키지 않는 것입니다.
실제로 이 전략으로 조금씩 리액트가 담당하는 영역을 늘려나가서 지금은 모든 웹 페이지가 리액트 컴포넌트로 렌더링되고 있습니다. 최초 도입부터 완전한 전환까지 약 1년정도 걸린것 같네요. 빨리 하려고 했으면 더 빨리 할 수도 있었겠지만, 급하게 전환할 이유가 딱히 없어서 전환은 천천히 진행되었습니다. 
리액트를 필요한 부분에서만 쓰는 것이 생각보다 쉽고, 부분적으로 썼을 때 아무런 문제가 없다는 사실을 알 수 있었습니다.

풀스택 장고 프로젝트에서 부분적으로 리액트를 도입한 이야기

댓글