WATCHA - Medium

왓챠 웹은 2016년부터 react + node(express)기반으로 운영되었지만, 최근 대중적인 프레임워크의 발전으로 인해 우리의 기존 구조를 유지하는 것이 점점 부담되고 있었습니다. 이에 따라 Remix로 마이그레이션을 결정한 과정과 경험을 공유하려 합니다.
왓챠 웹 구조 소개 & 마이그레이션을 고려한 이유
왓챠는 오랜 역사를 가진 서비스입니다. 초기에는 Rails의 ERB 템플릿을 사용했고, 그때부터 React도 함께 사용하고 있었습니다.
그러다가 react-router 와 express를 이용해 SSR이 가능한 구조로 레일즈에서 독립했습니다.
처음 이 구조를 선택할 땐(2016년) Next.js나 Remix처럼 성숙한 React 프레임워크가 존재하지 않아서 스스로 구조를 만들어 운영했습니다.
기존 구조는 처음부터 우리 팀의 요구에 맞춰 설계되었기 때문에 익숙해지면 개발이 훨씬 수월했습니다. 해당 구조가 익숙해지면 다른 프레임워크들과 동일하게 쉽고 빠르게 개발을 할 수 있는 장점이 있습니다.
또한 자유도가 상당히 높기 때문에 여러 필요한 기능들을 추가로 붙일 수 있었습니다.
기존 구조의 문제점과 프레임워크의 장점
그렇게 사용하던 와중에 Next.js 처럼 잘 구조화된 프레임워크들이 인기를 끌기 시작했습니다.
그 결과, 새로운 동료들은 Next.js 같은 프레임워크에 익숙한 경우가 많았으며, 이들에게 왓챠 내부 구조를 온보딩하는 추가적인 노력이 필요했습니다.
물론 현재 Next.js 나 Remix 등 SSR을 지원하는 프레임워크와 자체적으로 사용 중인 구조는 큰 틀에서 볼 때는 비슷한 부분이 많았지만 그럼에도 온보딩에서 약간의 불편함이 존재했습니다.
또한 중요한 라이브러리의 대규모 업데이트가 있을 때 직접 대응해야 합니다. 물론 이것을 하는 과정에서 많이 배우기도 합니다.
프레임워크는 여러 장점이 있지만, 첫째로 대중적인 프레임워크를 사용하면 새로운 동료가 들어왔을 때 온보딩에 큰 이점이 있습니다. 물론 React 내부적으로 어떤 state management 방법을 쓰는지, 또 기존에 어떤 도메인에서 개발했는지에 따라서도 달라지지만, 대중적인 React 프레임워크에 대한 익숙함은 새로운 코드를 받아들이는데 훨씬 큰 장점이 있습니다.
둘째로는 다수의 힘으로 이뤄지는 코드 개선입니다. 대중적인 프레임워크는 많은 개발자가 사용하기 때문에, 꾸준한 버그 수정과 성능 개선이 이루어져 더 안정적이고 유지보수가 쉬운 코드가 됩니다.
또한 요즘 프레임워크들은 IDE와 결합하여 쉬운 디버그 툴을 제공하기 때문에 개발 편의성이 높습니다.
프레임워크를 사용하지 않는다면 이러한 부분들을 자체적으로 해결해야 합니다.
그것이 주는 장점 또한 크지만, 팀 내에서 논의한 결과 ‘이제는 프레임워크에 올라타 보고 싶다’ 라는 의견이 강해 특정 프레임워크로의 이사를 결심하게 되었습니다.
Remix vs. Next.js 비교 후 Remix 선택 이유
Remix or Next.js
현재 왓챠는 크게 3가지 서비스를 하고 있습니다. 왓챠(OTT), 왓챠피디아(콘텐츠 평가 사이트), 숏차(숏드라마 플랫폼).
해당 서비스들은 웹, 웹뷰, 프로모션(이벤트)페이지 같은 스탠드얼론 페이지들로 이루어져 있습니다. 각각 필요한 개발 스택으로 운영되고 있고 내부적으로 특정 부분에서 사용해 익숙한 프레임워크는 next.js 와 remix 였습니다.
또 이 두 프레임워크는 대중적으로 잘 알려진 프레임워크였고 그래서 후보는 next.js,remix 두 개로 좁혀졌습니다.
다만 왓챠 웹 서비스같이 큰 트래픽이 몰리는 곳에서의 프레임워크 마이그레이션은 꽤 큰일이기 때문에 어떤 프레임워크를 선택할지 충분한 고민이 필요했습니다.
선택은 Remix
팀 내 논의 결과 Remix를 선택하기로 했습니다.
그 이유는 첫째로 기존 구조와의 적합성입니다. 기존 구조가 react-router + express로 이뤄져 있기 때문에 ssr이나 i18n을 적용하는 방식이 remix와 비슷했고 express middleware 들을 거의 동일하게 사용할 수 있는 장점 또한 있었습니다.
둘째론 Next.js에서 겪은 불편함입니다. https://www.epicweb.dev/why-i-wont-use-nextjs 해당 글에 Next.js에 대한 내용이 있는데 그 중
Next.js 와 vercel 과의 강한 연결성. 이는 vercel 을 사용하지 않을 시 특정 영역에서 Next.js 의 이점을 쉽게 활용할 수 없음.
글로벌 fetch의 자동캐싱 기능같은 과도한 추상화. 이런 마법같은 기능은 개발자로 하여금 디버깅을 어렵게 할 수 있음.
이 두 가지에 강한 공감이 있었습니다.
따라서 Remix를 사용하기로 마음을 먹고 마이그레이션 준비를 시작했습니다.
마이그레이션 방법론 (점진적 방식 vs. 빅뱅 방식)
이제는 마이그레이션을 어떤 방식으로 진행할 것인지 선택해야 했습니다. 점진적으로 현재 구조를 잠식(?)하면서 진행할지, 현재 구조를 유지하면서 새로운 레포지토리에서 새로이 쌓아 올린 후 트래픽을 한 번에 옮기는 방식으로 진행할지 고민했습니다.
두 방식의 이해를 돕기 위한 GIF를 첨부합니다. 파란색이 현재 구조고 초록색이 새로운 구조입니다.
점진적 방식
빅뱅 방식
점진적 방식의 장단점
점진적 방식은 지속적으로 새로운 부분을 반영할 수 있어 테스트와 피드백이 용이합니다. 따라서 한 번에 변경되는 것이 아니기 때문에 큰 장애가 일어날 가능성이 줄어듭니다.
단점은 초기 설정이 꽤 복잡하고, 새로운 부분의 적용이 느려지면 마이그레이션이 끝나지 않을 가능성이 존재합니다.
빅뱅 방식의 장단점
빅뱅 방식의 장점은 완전히 새로운 베이스에서 시작할 수 있기 때문에 환경 설정이 쉽고, 기존의 부채들을 정리하면서 진행할 수 있습니다.
단점은 기존 서비스를 계속 유지하면서 진행하기 때문에 새로운 기능 추가 시 두 군데에 모두(현재, 새로운) 추가해 줘야 하는 등, 이 방식 또한 마이그레이션이 길어질 확률이 있습니다.
또한 대규모 변경이 한 번에 이루어지기 때문에 테스트 기간이 길어질 수 있으며, 새로운 버전이 배포될 시 크리티컬한 장애가 발생할 확률도 큽니다.
결론
저희 팀은 두 가지 방식 중 점진적 방식을 선택해 진행했습니다.
이유는 위의 장점과 더불어 왓챠는 새로운 기능의 업데이트가 꽤 빠른 편이기 때문에 업데이트를 중단하고 한 번에 마이그레이션 하는 것은 서비스 운영상에 있어서 문제가 될 수 있습니다. react-router + express의 구조가 Remix와 함께 존재하는 것이 그리 어렵지 않았고 디자인 컴포넌트 등 공유 & 재사용이 가능한 컴포넌트가 대다수였습니다. 또한 e2e 테스를 비롯한 컴포넌트 테스트, page 단위의 테스트들이 충분히 되어있어 자신감을 가지고 진행했습니다.
점진적 변경 방법
점진적 변경을 진행하면서 고려해야 할 사항이 많았습니다.
서버를 어떻게 운영할 것인지, 컴포넌트를 어떻게 분리할 것인지 등 다양한 문제를 해결해야 했습니다.
기존 렌더링 서버와 Remix 서버같이 띄우기
기존에는 react-router-config와 Express를 이용해 SSR을 자체적으로 구현하고 있었습니다.
 따라서 Remix와 기존 구조가 공존하려면, 기존 방식으로 렌더링 되는 페이지와 Remix를 통해 렌더링 되는 페이지를 구분할 필요가 있었습니다.
먼저 기존 렌더링 서버와 Remix 서버를 동시에 운영하기로 했으며, 프록시 미들웨어를 추가하여 라우트에 따라 어느 서버로 보낼지 구별하는 방식을 적용했습니다.
Remix 서버를 메인으로 설정하고, http-proxy를 이용해 기존 서버를 다른 포트에서 실행한 후, 특정 경로로 들어오는 요청을 기존 서버로 전달하는 방식으로 라우트를 구분했습니다.
서버를 같이 띄우는 방식에는 여러 가지 방법이 있습니다. 상황에 맞춰 적합한 선택을 하면 됩니다.
컴포넌트 분리
react-router-dom을 사용하는 컴포넌트는 Remix와의 차이점 때문에 별도의 Remix 버전을 만들어야 했습니다.
하지만 그 외 대부분의 컴포넌트는 기존 구조를 최대한 공유하는 방식으로 진행했습니다. (해당 내용은 아래 자세히 설명합니다)
다행히 기존에 디자인 시스템(공통 UI 컴포넌트) 기반으로 구조가 잘 정리되어 있었기 때문에 컴포넌트 중복을 최소화할 수 있었으며, 마이그레이션 속도도 훨씬 빨라졌습니다.
실제 진행 중에 발생한 이슈들 & 해결 방법
쉽게 옮길 수 있던 예상과는 조금(?) 다르게 몇 가지 문제가 있었습니다.
두 가지 버전의 react-router
Remix는 react-router v6(현재는 v7)을 사용 중이고, 저희의 코드는 v5 를 사용 중이였습니다. v5, v6 는 큰 차이가 있었고, 그 결과 발생하는 문제가 있었습니다.
첫째로<Redirect/>컴포넌트가 사라졌습니다. 따라서 return <Redirect /> 이런 식으로 컴포넌트 위상에서 redirect를 구현해 놓은 곳은 Remix에선 loader 단에서 redirect를 구현하거나 클라이언트 사이드에서 navigate로 redirect 를 대응했습니다.
둘째로 history 가 navigate 로 변경되었습니다. 이에 따라서 history 함수를 사용하는 곳에서 navigate로 알맞게 변경해야 했습니다.
/* before */
function Page() {
  if (!session) {
    return <Redirect to="/sign_in"/>;
  }
  
  return <SessionPage/>;
}
/* after */
export const loader = () => {
  if (!session) {
    return redirect("/sign_in");
  }
}
function RemixPage() {
  return <SessionPage/>;
}
Remix와 기존 구조가 동시에 공유하는 컴포넌트
처음엔 이런 컴포넌트에 대하여 큰 문제가 없을 거 같았지만 위에 react-router 를 사용하는 경우에 Remix 에선 v6(v7), 기존 구조는 v5 를 사용하도록 변경해야 했습니다.
이를 위해서 react-router를 사용하는 부분을 props로 받도록 변경해 해당 컴포넌트를 공유하는 방식을 사용하려 했으나 이 작업이 생각보다 손이 많이 가는 작업이고, 코드가 복잡해지는 문제가 있었습니다.
따라서 코드의 중복이 조금 발생하더라도 Remix 버전 컴포넌트를 따로 만드는 방법으로 문제를 해결하려 했습니다. 기존 컴포넌트에 .remix.tsx 를 붙여 기존 파일 옆에 Remix 버전의 컴포넌트와 기존 컴포넌트를 구분하였고 해당 컴포넌트들이 같은 파일 트리에 잘 보이도록 하여 기존 컴포넌트 업데이트시 Remix 컴포넌트 또한 업데이트를 잊지 않도록 하였습니다.
src
 -- components
   -- UserProfile.tsx
   -- UserProfile.remix.tsx
   -- UserProfile.module.css
(무엇보다 이 상태가 오래가지 않도록 빠르게 전환하는 것이 가장 중요하다고 생각합니다.)
Link 컴포넌트 이동
Remix와 기존 렌더링 서버는 다른 서버에서 렌더링 된 다른 페이지기 때문에 react-router의 <Link/>컴포넌트론 서로 접근이 불가합니다. history, navigate 함수 또한 마찬가지입니다.
따라서 a tag의 href를 이용한 이동을 해야 했으며 그렇기 때문에 어떤 페이지가 Remix 렌더링 되는 페이지인지, 아닌지에 대한 정보가 필요했습니다.
Remix 전환이 완료된 라우트가 정의된 상수를 공유하고, 기존 렌더링은 react-router-config 를 이용하여 정의되어 있기 때문에 이에 대한 테스트를 통해 Remix 전환된 페이지를 구별하는데 안정성을 보강했습니다.
Fog of war 문제
Remix는 Fog of war라고 불리는 기능을 새로이 선보였습니다. 해당 내용은 Remix에 대한 사전 지식이 조금 필요하지만 요약하면 기존에는 초기 manifest 에 모든 라우트를 다 가져왔다면 이 기능은 초기에 필요한 manifest 만 가져오고 다른 라우트는 접근 시 가져오는 방식입니다. (많은 내용이 생략되었으니 자세한 정보는 해당 링크를 참조하시길 바랍니다)
manifest를 동적으로 가져오기 때문에 새로운 버전을 배포할 때 기존 배포 버전에서 클라이언트 로딩을 마친 경우가 그대로 남아있을 때 새로운 버전의 manifest를 가져오거나 가져오지 못하는 경우에 오류가 발생했습니다.
해당 이슈는 Remix issue 에도 올라가 있으며 아마도 이런 경우 링크 이동을 document reload 로 하는 방식으로 해결하려 하는 것 같습니다.
Document Hydrate 문제
기존 구조에선 hydrate 는 id 가 root 인 element 를 기준으로 실행되었습니다. html 내에 head 부분과 body 내에 id 가 root 가 아닌 부분은 서버에서 고정되어 그려지고, 나머지 부분을 hydrate 하면 되기 때문이었습니다. Remix에선 document 기준으로 hydrate가 이뤄지는데 이는 html 전체를 hydrate 할 필요가 있기 때문입니다.
/* before */
hydrateRoot(document.getElementId("root"), <Root/>);
/* after */
hydrateRoot(document, <Root/>);
저희 서비스는 gtag.js를 이용하여 데이터를 모으고 있는데 해당 스크립트를 삽입하고 그 스크립트가 실행될 때 html이 변경이 일어나기 때문에 hydrate가 이뤄지는 과정에서 불일치가 발생하는 경우가 있었습니다. 이는 hydrate속도와 gtag스크립트 실행 시점에 따라 간헐적으로 발생하는 문제였습니다.
따라서 이를 해결하기 위해 스크립트 삽입을 hydrate이후로 옮겨서 해결했습니다.
마이그레이션 이후
Remix로의 마이그레이션 이후, 팀 내 개발자들의 디버깅과 코드 유지보수 편의성이 크게 향상되었습니다.
또한, Remix가 제공하는 성능 최적화 덕분에 페이지 로딩 속도가 개선되고, 유저들에게 더 쾌적한 경험을 제공할 수 있었습니다.
이후의 이후(?)
현재는 Remix v3가 ReactRouter v7로 넘어가면서 ReactRouter v7 으로의 업그레이드를 준비중입니다.
결론
결국, 어떤 프레임워크가 가장 좋은가의 문제가 아니라, 우리 팀과 프로젝트에 가장 적합한 선택이 무엇인가가 중요하다고 생각합니다.
글을 쓴 이유는 특정 프레임워크가 뛰어나다는 말을 하기 위함이 아닙니다. 개발에 있어 은탄환은 없으며, 프레임워크마다 장점이 다릅니다. 따라서 팀의 구성원과 기존의 기술적 배경을 고려해 가장 적합한 프레임워크를 선택하는 것이 중요합니다.
때로는 특정 프레임워크를 사용하지 않는 것도 좋은 선택이 될 수 있습니다.
선택에 정답은 없습니다. 중요한 것은 팀의 요구와 프로젝트의 특성을 고려해 최적의 기술을 선택하는 것입니다. 우리의 경험이 비슷한 고민을 하는 분들에게 도움이 되었길 바랍니다!
읽어주셔서 감사합니다.
왜 왓챠 웹은 Remix로 마이그레이션했을까? was originally published in WATCHA on Medium, where people are continuing the conversation by highlighting and responding to this story.

왜 왓챠 웹은 Remix로 마이그레이션했을까?

댓글