Web beyond the edge
웹 개발에서 대두되고 있는 엣지 컴퓨팅에 대해 간단하게 이야기해볼까합니다. 제가 참여하고 있는 스터디에서 발표한 내용을 기반으로 글을 써보았는데요. 엣지에 대해 알아보고 조사하면서 자료를 정리한다는 느낌으로 작성해보았습니다. 엣지 컴퓨팅에 대한 깊은 내용보다는, 프론트엔드 웹 인프라에서 어떻게 엣지와 만나게 되었고 어떤 미래를 그려나갈 지에 대해 간략하게 알아본다 생각하시고 봐주시면 좋을 것 같습니다.
프론트엔드의 발전을 되짚어보기
우선 엣지 컴퓨팅이라는 개념이 어떻게 해서 나오게 되었는 지 알아보도록 하겠습니다. 엣지 컴퓨팅은 웹 환경을 더 빠르고 단순하게 만들고픈 이들의 열망에서부터 출발했습니다.
엣지와 엣지 컴퓨팅은 의미가 조금 다른데, 엣지는 사용자와 가까운 기기 / 환경 / 데이터베이스를 의미해요. 보통은 사용자와 가까운 정적 asset을 내려주는, CDN을 의미하기도 합니다.
웹에서 엣지는 정적인 파일들을 이용하기 위해 오래전부터 사용되어왔는데요. 그 중에서도 가장 주목해볼만한 지점은 JamStack의 유행에서부터가 아닐까 싶어요.
JamStack
JamStack은 JavaScript와 Markup, API로 이루어진 기술 스택을 얘기하는데요. JamStack이 대두되기 이전의 방식과 달리, 웹 페이지를 렌더링하는 서버를 두는 것이 아니라 브라우저(JavaScript)에서 온전히 웹 페이지를 렌더링하고(Markup), 필요한 데이터는 서버(API)에서 받아오는 방식이죠. 초기의 Angular, React, Vue와 같은 SPA 라이브러리, 프레임워크가 발달하고, 브라우저에서 온전히 웹 어플리케이션을 만들기 용이하게 되면서 발전된 개념이에요.
SPA 방식의 JamStack 렌더링 구조
JamStack은 정말 단순한 개발 방식과 아주 단순한 배포방식을 갖고 있어요. SPA로 웹 어플리케이션을 만들고, 빌드된 파일을 CDN에 배포하기만 하면 되죠. 거기다가 인프라 관리에 대한 비용을 줄여주었어요. 런타임이 돌아가는 웹 어플리케이션 서버와 다르게 CDN, 혹은 정적 에셋 서버만 관리해주면 되기 때문에 훨씬 간단했죠. 별도로 API를 만들어주는, headless CMS 같은 서비스를 이용하면, 진정 백엔드 코드 하나 안짜고 홈페이지를 만들 수 있었어요.
하지만 SPA에서 SSR로 패러다임이 점점 넘어가게 됩니다. SPA는 개발하기에 편한 방식이지만, 유저 경험이 좋지 않았어요. 특히 데이터 로드가 많은 콘텐츠 중심의 웹 어플리케이션에서는 긴 콘텐츠 렌더링 시간을 넘겨야했습니다. JavaScript가 파싱되고 실행한 이 후 렌더링 되는 시점에 브라우저에서 데이터 요청을 보내게 되고, 큰 용량의 콘텐츠들은 느리게 그려질 수 밖에 없었어요.
하지만 JamStack으로 에셋의 편리함을 맛봤던 웹 개발자들은 그 경험을 놓지 않으려고 했어요. Next.js을 앞세운 Vercel, 그리고 Netlify 등의 회사는 SSR에서도 이와 유사한 배포, 관리 경험을 주려고 노력했어요. 그리고 다양한 사전 빌드 렌더링 방식들(SSG, ISR)도 지원하고 발전시키면서 CDN 배포의 장점도 계속 가져가려고 했죠. 기존의 SPA 방식의 웹 어플리케이션 라이브러리들을 이용해 빌드 타임에 미리 HTML을 그려, 빠른 콘텐츠 렌더링 시간을 가져가게 한 것이죠.
SSR은 하이드레이션과 그로 인한 웹 페이지의 반응 시간이 문제가 되었어요. 하이드레이션이라는 과정이 가장 큰 걸림돌인데, 서버에서 그린 웹 렌더링 구조와 브라우저의 렌더링 구조를 맞춰 JavaScript(Event Handler)를 주입시키는 과정이죠. 이 과정이 JavaScript의 파싱 및 실행 후에 진행되기 때문에 버튼이 온전히 클릭 이벤트에 반응할 수 있도록 하기 위해서 이런 시간을 기다려야 해요.
Streaming SSR
Streaming SSR
엣지를 설명하기 위해 다음으로 알아보면 좋을 키워드는 Streaming SSR이에요. SSR이 점차 진화하면서, 하이드레이션 과정이 부분적으로 가져가려는 시도들이 늘어나게 되었죠.
그 중 가장 떠오르는 방식 중 하나가 Streaming SSR입니다. SSR은 SSR인데, 결과물을 Stream을 이용해 보내준다는 뜻이죠. 서버에서 만들어진 렌더링 결과물을 스트림으로 전송하는 방식으로 렌더링하는 방식입니다. Streaming SSR에 대해 알아보는 글은 아니므로 간단하게 이야기하자면, 기존의 SSR의 단점이었던 첫 렌더링 시점과, 웹 어플리케이션의 반응 시간과 SPA의 문제였던 콘텐츠 렌더링 시간을 잡아줄 수 있었어요.
Streaming SSR의 빠른 속도의 핵심은 스트림에 있어요. 스트리밍의 효율적인 장점으로 더 높은 성능의 웹 어플리케이션을 구축할 수 있게 되죠. 그러면서 사람들은 더 빠른 스트리밍과 네트워크 환경을 요구하게 됩니다.
웹 개발의 미래, 엣지 컴퓨팅
엣지 컴퓨팅은 사용자와 가까운 장소에서 코드를 실행하는 것을 의미해요. Lambda와 같은 서버리스와 비슷한 개념이죠. 다만 서버리스는 기존의 AWS와 같은 클라우드들이 제공하는 서버 위치에 고정됩니다. 따라서 코드를 실행하는 위치도 한 곳으로 고정되어있고, 실행된 결과는 먼 거리를 날아 사용자에게 도착하게 되죠.
엣지 컴퓨팅을 실현하는 여러 예시가 있지만, 대표적으로는 CDN이 있어요. CDN은 원래 코드를 실행하지 않고 저장된 정적 데이터를 반환하는 용도로 쓰였는데요. CDN에서 코드를 실행할 수 있게 해서, 더 빠른 속도를 가지는 서버를 구성할 수 있게 되었고 이것이 발전해 엣지 컴퓨팅이 될 수 있었습니다.
어떻게 CDN에서 코드를 실행할 수 있었던 걸까요? 관련해서 Cloudflare 개발팀의 발표에서 해답을 찾을 수 있었는데요. V8의 isolates를 이용해 격리된 안전한 환경을 빠르게 만들 수 있었다고 합니다. 뒤에서 얘기하겠지만 다른 엣지 컴퓨팅도 이와 같은 방식을 쓰고 있어요. 도커와 같은 컨테이너와 비슷하지만 다른 방식의 격리 기술입니다. 덕분에 웹 개발자들에게 친숙한 JavaScript를 서버에서 편안하게 실행할 수 있게 되었습니다.
관련 발표: https://www.youtube.com/watch?v=HK04UxENH10
엣지는 웹을 빠르게 제공할 수 있는 수단으로 떠오르고 있어요. 특히 해외에 서비스하는 경우 전 세계 어디서나 빠른 속도로 웹 사이트를 제공해줄 수 있어요. 그리고 사실 서버이기 때문에 더 많은 것을 해줄 수도 있어요. API 서버는 물론이고 직접 캐싱을 구현할 수도 있고, 다양한 보조 도구로 활용할 수도 있어요.
엣지 런타임과 Web Standard
엣지 컴퓨팅이 가능해지면서, 엣지에서 실행될 수 있는 전용 JavaScript 런타임들이 나오게 되었어요.
앞에서 말한 엣지 컴퓨팅과 그리고 런타임을 구분하자면, CDN에서 코드를 실행하는 것을 엣지 컴퓨팅, 그리고 코드가 실행되면서 구성되는 JavaScript 환경을 엣지 런타임으로 이해해주시면 됩니다.
기존의 Node.js 런타임의 경우, 제한적인 엣지 컴퓨팅 환경에서 구성되기에는 무거운 런타임이기 때문에, 그에 맞춰서 각 엣지 네트워크를 공급하는 회사들은 저마다 런타임을 하나씩 만들어 운용하고 있습니다. Cloudflare(Cloudflare Workers)과 Vercel(Vercel Edge Runtime)은 각각 Cloudflare Workers와 Vercel Edge Runtime이라는 Runtime을 갖고 있습니다. Deno도 Edge 런타임으로 동작할 수 있어요.
Hono 공식 홈페이지
hono와 같은 작은 사이즈를 가진 서버 프레임워크들도 주목을 받고 있습니다. 런타임의 특성 상 제한된 크기를 갖고있기 때문인데요. 그리고 다양한 JavaScript 런타임이 등장하고 있기 때문에, 각 런타임에 의존적이지 않으면서 다양한 JavaScript 런타임을 지원하는 것도 중요하죠.
Vite6 Evironment API
Vite는 Vite6에 다양한 런타임(Browser, Worked, Node, JSDOM..)들을 지원할 수 있도록 Environment API(옛 Runtime API)를 담을 예정이에요. 위에서 다양한 환경의 런타임을 지원할 수 있다고 했는데 그와 비슷한 아이디어라 볼 수 있어요. 웹을 구성하는 환경이 점차 다양화되다보니 꼭 필요하게된 기능인 셈이죠. 그 중에는 엣지 런타임도 꼽을 수 있고요.
여담이지만 최근의 이런 엣지 런타임들과 Hono, Vite와 같은 프레임워크를 살펴보면, 모두 Web API을 중심으로 발전하고 있다는 것이 보여요. 저도 이런 공통된 행보에 관심을 갖고 찾아보니, Edge Runtime을 만드는 주요 회사와 그룹들이 모여 Web 표준을 기반으로 웹 상호운용성(web-interoperability)을 위한 WinterCG라는 커뮤니티 그룹에 대해 찾을 수 있었어요. 각 회사들이 모여 표준화 된 API를 구성하고, 또 그에 맞게 사용될 수 있는 Web API라는 좋은 표준이 있어 다행이라고 생각합니다.
엣지 컴퓨팅의 한계
엣지 컴퓨팅의 특성상 그 한계도 있습니다. 우선 올릴 수 있는 서버의 크기나 가동 시작 시간에 제한이 있어요. 위의 표에서 Worker size는 1MB의 제한이 있어요. 물론 gzip 혹은 brotil로 압축한 후의 사이즈라 조금은 더 여유가 있습니다. 다만 일반적인 origin 서버에 비해 턱없이 부족한 사이즈는 최적화된 어플리케이션을 작성해야하는 부담으로 다가올 수도 있어요. 사용자들은 이런 단점들을 상쇄하기 위해서 나중에는 기존의 거대한 서버를, 하나의 온전한 기능을 수행하는 여러 조각의 서버들로 구성되도록 할 수도 있을 것 같아요.
엣지 서버가 데이터베이스 서버와의 위치가 먼 경우
엣지 서버가 데이터베이스 서버와 가까운 경우
다른 단점은 엣지의 위치인데요. 엣지 자체는 사용자에게 빠른 응답속도를 내려줄 수 있지만, 다른 서버가 일반적인 Origin 서버의 위치에 있다면 마찬가지로 네트워크 시간이 오래 걸린다는 점이에요. 위의 그림과 같이 시드니에서 독일의 프랑크푸르트까지의 네트워크가 엣지(Worker)를 통해 짧아졌어도, DB 서버의 위치가 멀 경우 똑같이 먼 거리를 날아가 요청을 받을 수 있게 돼요. 그래서 Cloudflare는 이러한 단점을 해소하고자, Worker를 최적의 위치에 있도록 하는 옵션을 소개하기도 해요.
엣지 런타임과 웹
위에서도 이야기했듯이 더 높은 성능의 웹 어플리케이션을 렌더링하는 데에도 엣지가 사용될 수 있어요. JamStack과 유사하게, 똑같이 CDN에 배포하기만 하면 전세계 대부분의 나라에서 적은 레이턴시를 가지는 서버를 둘 수 있는 거죠. 렌더링 구조는 SSR과 유사해요. 근데 실제로는 엣지의 지리적 차이점, 그리고 런타임 환경에 있어서 차이가 있죠.
네트워크 환경이 점차 발전하고 있는 만큼 렌더링 모델도 점점 발전해왔어요. 처음 SPA 프레임워크들이 생긴 이 후, 점점 더 복잡한 렌더링 개념을 적용할 수 있는 많은 지원들이 이루어졌어요. SSR에 대한 지원은 물론, 자체적인 동시성 모델을 제공해 효율적인 웹 어플리케이션을 만들 수 있기도 하죠. 대표적으로 React는 발전된 프로그래밍 모델을 구현할 수 있는 RSC를 제안했어요. 그간 Concurrent Mode와 Suspense 등의 렌더링 개념들이 기반이 되어 Streaming SSR과 엣지 런타임에서도 활약해줄 수 있게 되었습니다.
엣지와 관련해서는 Vercel, 그리고 Next.js에 대해서도 빼놓을 수 없을 것 같아요. Netlify가 부흥시킨 JamStack의 경험을 잘 발전시켜오고 있는 회사인 것 같아요. Next.js는 이전부터 엣지에서 미리 빌드가 이루어진 페이지를 가져올 수 있는 렌더링하는 방식들을 제안해왔어요. 실제로 가이드에서도 가급적 SSG와 같은 정적 페이지 생성을 쓰고, 동적 데이터가 많아질 수록 ISR을 그 다음에는 SSR을 추천해주고 있어요.
Next.js의 Partial Prerendering
그리고 Next.js 14에서 처음 소개된 PPR은 Next.js가 꿈꾸는 엣지의 미래를 엿볼 수 있을 것 같아요. PPR은 엣지의 단점을 상쇄하면서 높은 성능의 웹 어플리케이션을 만들 수 있는 방식이에요. Static한 부분은 미리 빌드해서 CDN(Edge)로 빠르게 제공하고 Dynamic한 부분은 Server에서 생성해 Streaming 할 수 있는 방식이죠.
위에서 엣지 런타임의 단점으로 데이터 베이스의 위치를 얘기했는데, Next.js는 엣지 런타임에서 웹 어플리케이션을 실행하는 것보다, 필요한 부분은 캐싱하고 + Origin 서버에서 스트리밍으로 렌더링해주는 방식이 더 효과적이었다고 해요. 엣지를 이용하는 방식은 저마다 조금씩의 차이는 있는 것 같습니다.
관련 트윗: https://x.com/leeerob/status/1780705942734331983
엣지는 빠르고 안전한 웹을 만들 수 있도록 계속해서 발전 중이고, 점차 우리 곁에 다가오고 있어요. 엣지 네트워크와 엣지 컴퓨팅은 어려운 문제들을 간단하게 해결해줄 수 있는 좋은 도구가 될 수도 있고, 직접 뛰어난 웹 어플리케이션을 만들어낼 수도 있어요. 저도 간단하게 엣지를 이용해보면서 재미있는 것들을 많이 만들고싶어지네요.