AI도 게임도 웹도, 왜 다시 서버 중심으로 돌아가는 걸까

최근 AI를 다루면서 로컬 LLM에 대한 욕심이 생겨 내 컴퓨터에서 직접 모델을 돌려보려고 이것저것 시도를 많이 해봤습니다.

그런데 삽질을 거듭하다 결국 내린 결론은, “비용을 지불할 수만 있다면 역시 대기업의 거대 LLM API를 쓰는 게 압도적으로 편하고 좋구나”였습니다.

내 로컬 하드웨어의 한계에 부딪히며 문득 든 생각이 있었습니다. 비단 AI 시장뿐만 아니라, 요즘 IT 생태계 전반이 서버에 비용을 더 쓰더라도 기기의 부담을 덜고 성능과 품질을 끌어올리는 방향으로 흘러가고 있다는 점이었습니다.

1. 게임도 AI도, 서버의 힘을 빌리는 시대

게임 시장만 봐도 Xbox 클라우드 게이밍이나 GeForce Now 같은 서비스들이 이미 자리를 잡았습니다.

내 PC나 스마트폰 성능이 부족해도, 대기업의 거대한 서버에서 고사양 연산을 다 처리해주니 사양 걱정 없이 쾌적하게 최신 게임을 즐길 수 있게 되었죠. 예전에는 반응 속도나 인풋랙이 문제였지만, 지금은 인프라가 워낙 좋아져서 실제로 플레이해보면 이질감을 거의 느끼기 힘들 정도입니다.

생성형 AI 시장도 완전히 똑같습니다. 스마트폰이나 일반 노트북의 8GB, 16GB 램으로는 수천억 개 파라미터를 가진 거대 모델을 돌릴 엄두조차 내지 못합니다. 결국 수천억 원대 GPU 클러스터를 갖춘 대기업 서버가 복잡한 연산을 대신 끝내고, 우리 기기에는 완성된 텍스트 결과만 내려주는 구조입니다.

내 기기는 고화질 화면을 보여주는 모니터 역할만 하고, 실제 무거운 연산은 거대한 데이터센터가 도맡는 구조가 가장 첨단 기술들의 옷을 입고 자연스럽게 자리 잡은 셈입니다.

2. 그렇다면 웹 시장은?

웹 프론트엔드 시장도 정확히 이 흐름을 따라 진화해 왔습니다.

초기에는 브라우저가 모든 자바스크립트를 다운받아 실행하는 순수 CSR(Client-Side Rendering) 기반 SPA가 대세였지만, 곧이어 첫 화면 로딩 속도와 SEO를 위해 서버에서 HTML을 미리 만들어 내려주는 SSR(Server-Side Rendering)로 눈을 돌리기 시작했습니다.

하지만 초기 SSR 역시 불완전했습니다. 페이지 전체의 데이터가 서버에서 준비될 때까지 기다려야 했고(All-or-Nothing), 화면이 보여도 브라우저에서 무거운 자바스크립트가 결합(Hydration)되기 전까지는 유저가 인터랙션을 할 수 없는 병목이 존재했기 때문입니다.

이 한계를 넘어서기 위해 등장한 것이 바로 **‘서버 컴포넌트(Server Components)‘**입니다.

페이지 전체를 통째로 서버에서 굽는 대신, 무거운 연산이나 데이터 처리가 필요한 일부 컴포넌트만 서버에서 비동기로 연산합니다.
서버에서 준비된 컴포넌트 결과물부터 네트워크를 통해 점진적으로(Streaming) 내려받아, 브라우저가 병렬로 가져와 병렬로 렌더링합니다.
유저와의 즉각적인 상호작용이 필요한 부분만 가벼운 클라이언트 컴포넌트로 남겨둡니다.

결국 웹 역시 기기의 부담을 덜고 서버의 연산 능력을 적극적으로 끌어다 쓰는 방향으로 발전해 온 셈입니다.

3. 웹은 브라우저에서도 충분히 돌릴 수 있는데, 왜 서버로 갔을까?

그런데 여기서 한 가지 의문이 생깁니다.

AI나 클라우드 게이밍은 기기 성능의 한계 때문에 ‘물리적으로 클라이언트에서 못 돌려서’ 서버로 간 것이 맞습니다. 하지만 웹은 다릅니다. 웬만한 자바스크립트 연산과 UI 렌더링은 보급형 스마트폰에서도 충분히 돌아갑니다.

충분히 브라우저에서 돌릴 수 있는 웹이, 왜 굳이 서버로 무게중심을 옮겼을까요?

SPA 시절의 달콤함과 예상치 못한 변수들

돌이켜보면 SPA가 대세가 되었을 때, 서비스 운영자 입장에서는 정말 큰 이점이 있었습니다.

서버는 단순히 정적 파일(HTML, JS 번들)과 가벼운 JSON API만 내려주면 끝이었고, 렌더링과 비즈니스 로직 연산은 전부 유저의 브라우저가 알아서 돌려주었기 때문입니다. 서버 부하와 인프라 유지보수 비용을 획기적으로 아낄 수 있었던 시절이었습니다.

하지만 시간이 지나면서 **‘유저의 리소스를 사용한다는 것’**에 따르는 수많은 복병들이 드러났습니다.

7년 된 보급형 안드로이드 폰부터 최신 아이폰까지 천차만별인 기기 사양
브라우저 엔진마다 미묘하게 다른 자바스크립트 실행 속도와 메모리 누수
불안정한 모바일 네트워크 환경에서 발생하는 대용량 JS 번들 다운로드 지연

결국 프론트엔드가 겪은 문제는 기기 성능의 부족이 아니라, **“도무지 예측할 수 없는 유저 환경의 무수한 변수”**였습니다.

4. 돈(인프라 비용)을 쓰고 ‘통제권’을 산다

웹이 서버 컴포넌트를 적극적으로 품게 된 본질적인 이유는 바로 이 변수의 통제에 있습니다.

유저의 불안정한 기기 환경에 기도를 올리는 대신, 하드웨어 사양과 네트워크 상태를 완벽하게 통제할 수 있는 우리 서버에서 무거운 데이터 페칭과 컴포넌트 연산을 끝내버리는 것입니다. 그리고 브라우저에는 이미 완성된 최소한의 결과물만 전달합니다.

물론 공짜는 아닙니다. 과거 SPA 시절에는 유저 기기에 떠넘겼던 연산 비용을 이제는 고스란히 **서버 인프라 비용(Edge/Serverless 컴퓨팅, CPU 자원, 호스팅 비용)**으로 치러야 합니다.

확실히 요즘의 기술 트렌드는 클라우드 자본력을 투입해 안정적인 경험과 통제권을 사 오는 패러다임이라는 느낌을 강하게 받습니다.

5. 서버 컴포넌트의 본질과 현장에서의 함정

서버 컴포넌트의 핵심 철학은 “무조건 모든 걸 서버로 보내자”가 아니라, **“필요한 일부만 똑똑하게 서버에 의존하자”**는 하이브리드 선택지였습니다.

연산의 맥락과 라이프사이클을 깊이 이해하고 있는 개발자에게 서버 컴포넌트는 정말 강력한 무기가 됩니다. 유저 인터랙션이 필요한 부분은 클라이언트에 남겨두고, 무거운 데이터 가공이나 보안이 필요한 로직만 서버로 분리해 최적의 효율을 낼 수 있으니까요.

하지만 실제 현장에서는 우려스러운 모습도 자주 보입니다.

아키텍처의 배경과 트레이드오프를 충분히 고민하지 않은 상태에서 유행을 따르거나, AI 도구에 전체 구조 설계를 무비판적으로 맡겨버리는 경우입니다. 무엇을 왜 서버로 돌려야 하는지 명확한 기준 없이 남발하다 보면, 인프라 비용은 비용대로 폭증하고 정작 렌더링 지연과 복잡도로 인해 성능은 떨어지는 최악의 악순환에 빠지기 쉽습니다.

기술이 서버로 무게중심을 옮겼다고 해서 우리 생각까지 서버에 통째로 맡겨버려서는 안 되는 이유입니다.

6. 팽이처럼 도는 기술의 역사: 중앙집중과 분산

돌아보면 이런 흐름은 IT 역사에서 끊임없이 반복되어 온 사이클이기도 합니다.

[1970년대] 거대 메인프레임 + 터미널 (중앙집중)
   ↓
[1990년대] 개인용 PC 보급과 로컬 프로그램 (분산)
   ↓
[2000년대] 웹 1.0 초창기 서버 사이드 렌더링 (중앙집중)
   ↓
[2010년대] 스마트폰 앱과 React SPA (분산)
   ↓
[현재] 클라우드 게이밍, LLM API, 서버 컴포넌트 (다시 중앙집중)

클라이언트가 무거워져 감당하기 힘들어지면 서버로 짐을 넘기고, 서버 비용과 네트워크 지연이 한계에 부딪히면 다시 클라이언트로 연산을 털어내는 왕복 운동이 계속되어 왔습니다.

7. 또 언제 사이클이 바뀔지 모르지만

지금은 바야흐로 거대한 서버 인프라와 GPU 자본이 경험을 주도하는 시대입니다.

하지만 온디바이스 AI 칩셋(NPU)이 더 대중화되고, 경량화된 오픈소스 소형 모델(SLM)이 일상 기기에 자리 잡고, 클라우드 트래픽 비용이 감당하기 어려워지는 시점이 오면 언제든 패러다임은 다시 온디맨드/엣지 분산 연산으로 돌아설지도 모릅니다.

결국 중요한 것은 유행에 휩쓸려 무작정 서버에 모든 것을 던지는 것이 아니라, **“내 서비스에서 통제해야 할 변수가 무엇이고, 이를 위해 지불할 인프라 비용이 합당한가?”**라는 균형점을 찾는 일이라고 생각합니다.

거대한 인프라의 파도 속에서, 여러분의 서비스는 지금 어디에 무게중심을 두고 계신가요?