Next.js 16과 Edge Runtime — 왜 미들웨어를 Node.js로 되돌렸을까

모든 웹 애플리케이션을 에지 런타임에 올려 지연 시간 없이 실행하겠다는 흐름이 최근 한풀 꺾였습니다. 데이터베이스가 특정 리전에 고정되어 있는 한, 지리적으로 분산된 에지 환경은 오히려 네트워크 왕복 시간을 늘린다는 현실적인 한계가 드러났기 때문입니다. 이에 따라 2026년 현재 클라우드 생태계는 에지를 라우팅이나 토큰 검증처럼 가벼운 프런트라인 연산에만 제한적으로 사용하고, 메인 로직은 다시 리전 기반의 서버리스 환경으로 회귀시키고 있습니다. 에지 기반 미들웨어를 지원 중단하고 Node.js 환경의 프록시를 전면 도입한 Next.js 16의 결정은 이러한 인프라 교정기를 대표하는 상징적인 변화입니다.

Next.js 16의 결단 — middleware.ts의 감쇠와 proxy.ts의 등장

Next.js 16은 에지 기반으로 동작하던 기존 middleware.ts를 공식적으로 지원 중단하고, Node.js 환경에서 작동하는 proxy.ts를 전면 도입했습니다. 이 변화는 전 세계에 분산된 초경량 V8 격리 환경보다, 모든 라이브러리를 제약 없이 실행할 수 있는 안정적인 Node.js 환경이 실제 애플리케이션 개발에 훨씬 효율적이라는 업계의 현실적인 판단을 반영합니다.

기존 middleware.ts는 경량 에지 런타임 기반이라 성능은 뛰어났지만 기능적 제약이 컸습니다. 특히 암호화를 처리하는 crypto나 파일 시스템을 제어하는 fs 같은 핵심 네이티브 Node.js API를 쓸 수 없었고, 데이터베이스 풀링 연결도 지원하지 않아 미들웨어 단에서 직접 데이터를 검증하고 라우팅하기 무척 까다로웠습니다.

새롭게 등장한 proxy.ts는 오직 Node.js 런타임 위에서만 동작합니다. 덕분에 개발자는 어설픈 우회책을 찾느라 시간을 허비할 필요 없이, 풍부한 노드 패키지 생태계와 완벽한 네이티브 API를 활용해 트래픽을 정교하게 가로채고 다이내믹 프록싱 처리를 더욱 안정적으로 구현할 수 있게 되었습니다.

리전 서버리스의 반격 — Vercel Fluid Compute와 Active CPU 모델

리전 기반의 Node.js 서버리스 환경은 에지 런타임이 내세우던 비용과 속도 우위를 기술적으로 무력화하고 있습니다. 그 중심에는 Vercel의 플루이드 컴퓨팅(Fluid Compute) 기술이 확립한 '액티브 CPU' 과금 모델이 있습니다. 기존 서버리스 함수는 외부 데이터베이스나 거대언어모델(LLM)의 응답을 기다리는 I/O 대기 시간에도 무조건 비용이 발생했습니다. 반면 액티브 CPU 모델은 이 대기 시간 동안 과금을 일시 정지하고 실제 CPU가 작동하는 시간만 계산하여, 인프라 비용을 최대 85%까지 절감합니다.

여기에 함수 내부 동시성 지원이 더해져 비용 공식을 완전히 바꾸었습니다. 하나의 인스턴스가 여러 요청을 동시에 처리할 수 있게 되면서, 요청마다 새로운 인스턴스를 띄워야 했던 서버리스의 고질적인 콜드 스타트와 유휴 비용 문제를 극적으로 해결했습니다. AWS 람다 역시 스냅스타트 기술을 통해 초기 실행 지연을 낮추었습니다. 이제 개발자는 에지 런타임의 제약조건과 싸우지 않고도, 익숙한 Node.js 환경에서 성능과 비용을 모두 챙길 수 있게 되었습니다.

에지의 역습 — Cloudflare Workers의 V8 메모리 가비지 컬렉션 최적화

리전 서버리스의 매서운 추격에 맞서 에지 컴퓨팅 진영도 고질적인 기술적 한계를 돌파하며 반격에 나섰습니다. 대표적으로 Cloudflare Workers는 그동안 단점으로 지적받던 CPU 연산 성능 병목을 해결하기 위해 V8 엔진의 메모리 관리 아키텍처를 대폭 개편했습니다.

기존 V8 엔진 기반의 격리 환경은 메모리의 영세대(Young Generation) 경계가 128MB로 엄격하게 고정되어 있었습니다. 이로 인해 메모리 사용량이 조금만 늘어나도 메모리를 강제로 회수하려는 가비지 컬렉션이 과도하게 발생하는 스래싱 현상이 일어났습니다. Cloudflare 공식 블로그에 따르면, 이 병목 현상 때문에 일부 CPU 집약적인 작업에서 리전 기반 서버리스 대비 성능이 최대 3.5배까지 뒤처지는 원인이 되기도 했습니다.

Cloudflare는 가비지 컬렉션 타이밍을 유연하게 제어하는 동적 휴리스틱 알고리즘을 도입해 이 문제를 해결했습니다. 메모리 상태에 맞춰 가비지 컬렉션 주기를 지능적으로 조절하게 되면서, 전 세계 Workers의 CPU 실행 성능이 약 25% 향상되었습니다. 가벼운 라우팅을 넘어 에지 런타임에서도 더 무겁고 복잡한 연산을 안정적으로 처리할 수 있는 기술적 발판이 마련되었습니다.

런타임 상호운용성 보장 — ECMA-429 표준의 출범

서로 다르게 파편화되어 있던 서버 사이드 런타임 생태계가 마침내 하나의 공식 표준 아래 통합되었습니다.

WinterCG가 Ecma 기술 위원회 TC55(WinterTC)로 공식 전환된 이후, 런타임 간의 호환성을 보장하는 핵심 규격인 'ECMA-429'가 공식 발행되었습니다. 이 규격은 fetch, Web Crypto, Request, Response처럼 브라우저와 서버 환경 모두에서 호환되어야 하는 최소한의 공통 웹 API 세트를 명문화했습니다.

덕분에 개발자는 특정 인프라 벤더의 독자적인 API에 종속되지 않고, 로컬 개발 환경부터 에지와 리전 서버리스에 이르기까지 동일한 코드를 어디서나 안정적으로 실행할 수 있는 강력한 이식성을 확보하게 되었습니다.

2026년 풀스택 개발자가 취해야 할 서버리스 아키텍처 전략

이제는 애플리케이션 전체를 억지로 에지 런타임에 욱여넣을 필요가 없습니다. 메인 비즈니스 로직과 데이터베이스 중심의 연산은 풍부한 생태계를 갖춘 Node.js나 Bun 기반의 리전 서버리스 환경에 배치하고, 가벼운 헤더 가공이나 프록싱, 인가 같은 프런트라인 연산만 에지에 맡기는 하이브리드 설계가 2026년의 표준 공식으로 자리 잡았습니다.

이러한 하이브리드 아키텍처가 완벽히 기능할 수 있는 이유는 클라우드 인프라와 표준화 기구의 빠른 기술 진화 덕분입니다. 액티브 CPU 과금 모델과 리전 런타임의 최적화는 대기 시간 동안 발생하는 비용 낭비를 제거했고, 메모리 관리 구조를 개선한 에지 컴퓨팅은 고유의 가볍고 빠른 성능을 유지해 줍니다. 여기에 ECMA-429 표준까지 공식 발행되면서, 개발자는 런타임 간 코드 이식성 걱정 없이 각 인프라의 강점만 영리하게 조합해 사용할 수 있게 되었습니다.

결국 핵심은 기술적 제약에 타협하는 것이 아니라, 작업의 성격에 최적화된 도구를 제자리에 배치하는 것입니다. 인프라의 안정성과 개발 생산성은 무조건적인 최신 기술 전환이 아닌, 이처럼 명확한 역할 분담에서 나옵니다.

참고 링크