OpenAI(ChatGPT)가 Next.js에서 Remix로 전환한 이유

1. 들어가며

2024년 9월 초 즈음에 OpenAI에서 기술 스택 전환에 대한 내용이 화두가 된 적이 있습니다.

 

https://x.com/youyuxi/status/1831933737636073782

 

생태계가 꾸준히 RSC(React Server Component), SSR(Server Side Rendering)으로 발전하고 있으며, 머지 않아 SPA(Single Page Application)이 없는 것처럼 동작하는 react 생태계를 보게될 것이라는 예측이 항간에 나오고 있습니다.

 

Vercel은 Next.js와 자사의 플랫폼 사용을 증가시키고, 이를 통해 수익을 창출하기 위해 노력해왔습니다. 이런 행보는 매우 자연스러운 일이죠. 하지만 여기서 문제가 되는 것은 많은 React Core 팀 멤버들이 Next.js 팀으로 이동하면서, React의 방향을 Next.js의 우선순위에 맞추는 데 있었습니다.

 

이러한 움직임은 Vercel의 이해관계가 React의 주요 우선순위가 되는 결과를 낳고 있습니다.

 

React가 단순한 라이브러리가 아닌 프레임워크로 변모하는 과정에는 Meta 팀뿐만 아니라 Vercel,  Netlify, Expo, Shopify 등 여러 회사가 관련되어 있는데요. 이러한 프레임워크들의 구조에 있어서 발전은 생태계에 큰 이익을 가져오겠지만, 이에 대한 잘못된 인식도 동시에 형성되고 있습니다.

 

과거에 SPA에 대한 관심이 높았던 시절이 있었지만, 이제는 그 관심이 크게 줄어들었습니다. 마치 React Hooks가 등장하면서 Class 컴포넌트가 점차 사라졌듯이, React Server Components(RSC)의 도입과 함께 SPA 방식도 점차 사라질 것으로 보입니다.

 

최근 React 생태계에서는 몇 가지 중요한 변화가 있었습니다. 예를 들어, "React 클래스 컴포넌트 -> React 함수형 컴포넌트 + Hooks"로의 전환이 이루어진 것이고, 많은 개발자들이 오픈 소스 라이브러리를 이러한 구조로 전환하게 되면서 Hooks의 편리함을 굉장히 빠른 속도로 받아들였습니다. 이 전환은 React 개발자 경험에 직접적으로 영향을 미치기 때문에 생태계 내에서 순조롭게 적응할 수 있었던 것이기도 합니다.

 

반면, 현재의 RSC(React Server Component)는 보다 매우 복잡한 개념이라고 할 수 있습니다. RSC는 기존에 사용해 오던 네트워크 계층의 통신 방식에 변화가 필요하게 하며, 우리가 서버와 소통하는 방식에도 영향을 미칩니다. 예를 들어, 번들링(Bundling), 데이터 페칭(Data Fetching), 라우팅(Routing)과 같은 여러 요소들이 한데 어우러져 기존의 네트워크 레이어와는 다른 방식으로 서버와 상호작용하게 만듭니다. 이로 인해 Fetch, GraphQL, OpenAPI와 같은 서버측 기술들이 달라질 가능성도 커지고 있으며, 결국 서버와 클라우드에 대한 접근 방식에 근본적인 변화를 목표로 하고 있습니다.

 

요약컨데, RSC는 기존의 아키텍처와 기술 스택에 상당한 변화를 요구하고 있습니다. 그 예로, 전통적인 SPA에서는 .NET, Python, Java, Ruby 등의 API를 직접 호출하는 방식으로 서버와 통신했다면, RSC에서는 React가 Node.js 위에서 작동하면서, 백엔드에서 이러한 API를 호출하는 계층을 두도록 설계하는 것이 일반적이라고 합니다.

 

이는 기존 방식과 비교할 때 아주 큰 아키텍처적 변화인 것이죠.

 

이와 같이 근본적이라고 할 수 있는 것들에 대한 변화를 요구하기 때문에 기업들이 단기간에 이를 도입하는 것은 조금 무리라고 볼 수 있는 것입니다. 이로 인해 Remix 팀은 "SPA 모드"를 도입하여 기존의 SPA 방식을 유지할 수 있도록 선택지를 제공하고 있습니다.

 

2. Open AI에서 Next.js Remix로 잠수함 패치를 진행하다.

https://x.com/ryanflorence/status/1831379475654947233

 

ChatGPT는 모든 렌더링이 클라이언트 측에서 이루어집니다. JavaScript는 서버 부하가 많은 반면, Remix는 균형을 잘 맞추고 있으며, React 라우터를 사용하면 클라이언트 측 라우팅과 렌더링이 더 잘 구현됩니다.

 

이에 대해 생각해보면 알곘지만 ChatGPT는 초기 로드 할 때 모든 데이터를 JS로 가져와서 링크를 클릭하면 클라이언트 측 렌더링을 통해 브라우저에서 렌더링되는 JSON 데이터를 가져오기 때문에 매우 빠르게 작동합니다.

• 앞부분에서는 EnvoyProxy를 사용합니다.
• 서버 특에서는 Remix Server가 Express로 실행 중입니다.
• CDN 측에서는 Azure를 사용합니다.

 

ChatGPT 웹 페이지는 백그라운드에서 Server Action을 실행하고 있지 않습니다. 바로 여기서 OpenAI는 웹사이트가 아니라 애플리케이션이라는 것을 알 수 있습니다. 웹, 데스크톱, 모바일 기기 모두에서 API를 통해 집중적인 서비스와 상호작용을 제공하는 구조에는 SPA와 클라이언트측 렌더링 모델이 필요합니다. 마찬가지로 서버와의 통신에서 서버 캐싱 관리 시 React/Tanstack Query를 활용하는 것을 알 수 있습니다.

https://x.com/tannerlinsley/status/1831869220835225965

 

전통적인 서버 렌더링 방식에서는 서버가 완전한 HTML을 브라우저로 전달하지만, OpenAI의 접근 방식은 클라이언트 측에서 대부분 작업을 처리하는 클라이언트 렌더링에 초점을 맞추고 있습니다.

 

사이트를 방문하면 최소한의 HTML만 제공되며, 메타 태그와 함께 몇 가지 미리 로드된(pre-loaded)이미지 및 JavaScript 파일이 포함되어 클라이언트 측 작업에 필수적인 요소들이 준비됩니다. Next.js가 강력한 서버 사이트 렌더링(SSR) 기능으로 유명하지만 Remix는 클라이언트에서 대부분의 상호작용이 이루어지는 SPA를 구현하는 데 탁월합니다. 이는 ChatGPT와 같은 애플리케이션이 클라이언트 중심의 렌더링을 통해 더 빠르고 직관적으로 동작할 수 있게 만드는 데에는 적합한 선택이라고 할 수 있습니다.

 

 3. Remix vs. Next.js: Routing

OpenAI가 Remix를 선택한 주요 이유 중 하나는 Remix의 강력한 라우팅 시스템에 있다고 볼 수 있습니다. Remix는 React Router의 개발자들이 만든 프레임워크로, 라우팅이 핵심 기능 중 하나입니다. OpenAI 애플리케이션은 약 60개의 라우트를 사용하며, Remix는 클라이언트 렌더링을 최적화하면서 각 라우트에 필요한 데이터를 효율적으로 관리합니다.

 

특히 Remix의 Loaders 기능이 돋보이는데, 이 loader라는 것은 각 라우트가 렌더링되기 전, 서버에서 필요한 모든 데이터를 미리 가져오는 역할을 합니다. 이는 Next.js와 차별되는 부분으로, Next.js에서는 JavaScript가 먼저 로드되고 나서 추가적인 데이터가 필요한 경우 API를 통해 데이터를 가져와야 하므로 초기 로딩 시간이 느려질 수 있습니다. Remix의 loader를 활용하면 OpenAI는 초기 페이지 로딩 시 모든 필요한 데이터를 한 번에 가져와 더 빠르고 매끄러운 사용자 경험을 제공하는 것이죠.

 

 

4. 몇 가지 추가적인 이유

OpenAI가 Remix를 선택한 이유를 정리하면 다음과 같습니다.

1. 클라이언트 렌더링 최적화

OpenAI의 애플리케이션은 SSR에 크게 의존하지 않습니다. 렌더링이 클라이언트 측에서 대부분 이루어지며, 서버는 주로 데이터를 제공하는 역할을 할 뿐 그 이상을 하지는 않습니다. 이러한 접근은 OpenAI의 아키텍처와도 잘 맞아 떨어진다고 합니다.

 

주요 작업(model과의 인터랙션, API 호출 등)은 결구 별도의 백엔드 시스템에서 이루어지기 때문에, 클라이언트 렌더링에 집중할 수 있는 Remix는 가벼운 프론트엔드 프레임워크로 적합한 것입니다.

 

2. 로더 효율성

Remix의 "loader(로더)" 기능은 첫 번째 렌더링 시 필요한 데이터를 효율적으로 로드합니다. 이를 통해 페이지가 로드될 때 사용자 데이터나 세션 토큰 등의 필수 정보가 즉시 제공되기 때문에, 초기 지연이 주러들고 사용자 경험이 향상됩니다.

 

3. API 호출에 대한 유연성

OpenAI의 Remix 애플리케이션은 대부분의 백엔드 로직을 처리하는 외부 API와 상호작용합니다. Remix는 프론트엔드에서 데이터를 APi로부터 가져오는 역할을 수행하며, 백엔드 로직을 프론트엔드와 분리할 수 있게 해주어 확장성과 유지보수를 향상시킬 수 있습니다.

 

4. 가벼운 프레임워크

Remix는 Vite로 구동되어 빠르고 가벼운 개발 환경을 제공합니다. Vite는 Next.js의 내장 Webpack에 비해서 속도와 유연성에서 장점을 가지며(물론 시시비비가 있는 주제입니다.) OpenAI가 보다 원활한 개발 경험을 얻도록 돕습니ㅏㄷ.

 

5. 왜 SSR과 SEO는 고려되지 않았을까?

일반적으로 SEO와 성능을 위해 SSR을 고려하는 기업들이 많지만, ChatGPT의 특성상 "도구"에 지나치지 않기 때문에 SEO가 큰 순위가 아닙니다. 따라서 OpenAI는 빠르고 매끄러운 클라이언트 상호작용에 집중하여 사용자 경험에 포커스를 두었고, 이는 오히려 Remix가 더 효율적으로 처리할 수 있는 것입니다.

 

6. 백엔드와 인프라 아키텍처

OpenAI의 백엔드 API는 커스텀 인프라에 호스팅 중이며, Envoy 및 CDN(Azure)의 프록시 서버를 통해 지원되고 있습니다. Remix는 이러한 API와 통신하여 필요한 데이터들을 가져오지만, 서버 측 로직을 직접 관리하지는 않습니다.

 

Remix가 Express 서버에서 실행된다는 점은 OpenAI가 경량 서버 측 작업을 선호한다는 것을 보여주기도 합니다. 이전에는 vercel과 Next.js를 사용했지만, 현재는 Cloudflare가 트래픽 분산과 로드 밸런싱을 지원하는 맞춤형 인프라 설정으로 발전시킨 것으로 알려져 있습니다.

 

7. CSS 스타일링

OpenAI는 여전히 Tailwind CSS를 사용하여 스타일을 설정하며, 이 부분은 Next.js에서 Remix로의 전환에서도 변함이 없는 부분 중에 하나입니다. Remix의 폼 처리와 서버 측 기능을 제공하는 "actions" 기능은 사용하고 있지 않으며, 데이터 로딩과 클라이언트 측 상호작용 최적화에 주력하고 있는 것으로 보입니다.

 

8. 결론

결론적으로 OpenAI의 Remix 전환은 ChatGPT의 사용 맥락과 기술적 요구 사항을 따져 봤을 때 적합한 선택으로 볼 수 있습니다. Remix는 특히 클라이언트 렌더링과 데이터 로딩을 효율화하는 데 장점을 가지고 있어, 빠르고 반응성 높은 사용자 경험을 제공할 수 있습니다. 이러한 특성은 ChatGPT와 같은 애플리케이션에서 중요한 요소이며, SEO에 대한 부담이 적은 상황에서는 Remix가 오히려 Next.js보다 더 가볍고 유연하게 활용될 수 있는 것입니다.

 

하지만 Remix와 Next.js 간의 비교에서 주의해야 할 점은 다음과 같습니다.

1. SSR vs. CSR: SSR은 SEO 외에도 초기 로딩 성능을 극대화하고, JS 해석 이전에 브라우저에서 콘텐츠를 사용할 수 있도록 하는 등의 장점이 있습니다. Remix가 클라이언트 렌더링에 집중하여 이를 잘 수행하지만, 여전히 콘텐츠 중심의 웹사이트나 SEO가 필요한 경우에는 Next.js가 더 유리할 수 있습니다.
2. 로드 밸런싱과 클라우드 설정: OpenAI가 Remix로 전환하면서 Cloudflare, Envoy 등을 통한 트래픽 분산 및 로드 밸런싱을 사용한 것은 성능 최적화와 사용자 경험 측면에서 중요한 시사점을 줍니다. 이는 특히 API 중심의 애플리케이션을 설계할 때 매우 유용한 접근법으로, 현대적인 웹 앱이 다양한 백엔드 서비스와 통합되어야 하는 경우에 좋은 레퍼런스가 됩니다.