[번역] 플랫폼 전반의 Next.js: 어댑터, OpenNext, 그리고 우리의 약속

라이브러리, 프레임워크•2026.04.04

원문: https://nextjs.org/blog/nextjs-across-platforms

Jimmy Lai, JJ Kasper - 2026-03-25

Next.js 16.2에서는 OpenNext, Netlify, Cloudflare, AWS Amplify, Google Cloud와의 협업을 통해 구축된 안정적인 Adapter API를 도입했습니다. 이 포스트에서는 이 API가 어떻게 탄생하게 되었는지, 그리고 Next.js가 모든 플랫폼에서 원활하게 작동하도록 보장하기 위해 우리가 실천하고 있는 약속들을 다룹니다.

Adapter API (stable): 모든 플랫폼이 타겟팅할 수 있는, 애플리케이션에 대한 타입화되고 버전이 관리되는 명세입니다.

테스트 스위트(Test suite): Vercel을 포함한 모든 어댑터에 공유되는 정확성 테스트입니다.

검증된 어댑터(Verified adapters): Next.js 조직 하에 호스팅되는 오픈 소스 기반의 커뮤니티 소유 어댑터입니다.

에코시스템 워킹 그룹(Ecosystem Working Group): 여러 제공업체 간의 변경 사항을 조율하기 위한 상설 포럼입니다.

여기까지 오게 된 과정

많은 Next.js 앱은 next start를 실행하는 단일 Node.js 서버로 배포됩니다. 현재 수십만 개의 팀이 수많은 플랫폼에서 제한 없이 이 방식을 사용하고 있습니다.

하지만 앱을 확장하려면 대개 여러 서버 인스턴스를 실행해야 합니다. 이 경우, 캐시된 콘텐츠가 인스턴스 간에 동기화되어야 하고, 온디맨드 재검증(On-demand revalidation)이 전파되어야 하며, 스트리밍이 안정적으로 작동해야 하는 등 몇 가지 사항이 기본적으로 올바르게 작동해야 합니다. 이것들은 최적화의 문제가 아니라 기능적 요구 사항입니다.

그다음으로는 선택적으로 적용하는 성능 옵션들이 있습니다. 글로벌 CDN에서 캐시된 콘텐츠를 서빙하거나, 에지(Edge)에서 컴퓨팅을 실행하거나, 서버리스 함수로 콜드 스타트(Cold start)를 최적화하는 것 등입니다. 이러한 각 요소는 이미 올바르게 작동해야 하는 기반 위에 아키텍처적 복잡성을 더합니다.

플랫폼과 아키텍처에 따라 스트리밍, 서버 컴포넌트(Server Components), 부분 사전 렌더링(Partial Prerendering, PPR), 미들웨어, 캐시 컴포넌트, 온디맨드 재검증 등 전체 영역이 늘어납니다. 각 기능과 이들이 서로 상호작용하는 방식은 그동안 공식적으로 문서화된 적이 없었습니다. 진화하는 릴리스에 맞춰 멀티 테넌트 환경에서 Next.js를 완벽하게 지원하려는 플랫폼 제공업체들에게 이러한 과제들은 더욱 가중되었습니다.

Next.js 팀이 Netlify의 고충을 논의하자고 연락해 왔을 때, 우리는 공유할 구체적인 문제 목록을 작성하기 시작했습니다. 하지만 이 문제들의 90%를 관통하는 공통된 원인은 단순히 빌드 출력을 구성하고 읽기 위한 문서화되고 안정적인 메커니즘이 부족하다는 점이었습니다. 그것이 우리에게 무엇보다 필요했던 것이었습니다. 그래서 우리는 Jimmy에게 그렇게 전달했고, 그러길 잘했다고 생각합니다. — Philippe Serhal, Netlify 엔지니어

부족했던 조각은 제공업체들이 참고하여 구축할 수 있는 **상위 수준의 안정적이고 공개된 규약(Contract)**이었습니다.

OpenNext가 가교 역할을 했습니다

OpenNext가 그 공백을 메웠습니다. OpenNext는 Next.js 빌드 출력을 제공업체가 소비할 수 있는 형태로 변환하여, 프레임워크의 의미론(Semantics)을 각 제공업체의 기본 요소(Primitives)에 매핑했습니다. 호환성 레이어로 시작된 것이 특히 AWS에서 초기 프로덕션급 어댑터가 되었고, 이후 Cloudflare와 Netlify도 이 노력에 동참했습니다. OpenNext는 Next.js 빌드 출력이 어댑터가 직접 타겟팅할 수 있는 안정적이고 정의된 인터페이스 역할을 할 수 있음을 보여주었습니다.

이러한 통찰은 Next.js 팀과 OpenNext 유지 관리자들, 그리고 Netlify, Cloudflare, AWS Amplify, Google Cloud의 엔지니어들 간의 폭넓은 협업으로 이어졌습니다. 우리는 2025년 4월에 Build Adapters RFC를 발표하고 워킹 그룹을 구성했으며, 이후 이 파트너들과 함께 API를 설계, 테스트 및 검증해 왔습니다.

Adapter API

Next.js 16.2는 안정적이고 공개된 Adapter API와 함께 출시됩니다.

이제 빌드 시 Next.js는 애플리케이션에 대한 타입화되고 버전이 관리되는 명세를 생성합니다. 여기에는 라우트, 사전 렌더링, 정적 자산, 런타임 타겟, 의존성, 캐싱 규칙 및 라우팅 결정이 포함됩니다. 어댑터는 이 출력을 소비하여 제공업체의 인프라에 매핑합니다.

어댑터는 modifyConfig(설정이 로드될 때)와 onBuildComplete(전체 출력을 사용할 수 있을 때)라는 두 가지 훅(Hook)을 구현합니다. 하위 호환성이 깨지는 변경 사항(Breaking changes)이 발생할 경우 Next.js의 새로운 메이저 버전이 필요합니다.

Vercel의 어댑터도 비공개 훅이나 특별한 통합 경로 없이 이와 동일한 공개 규약을 사용합니다. 이는 오픈 소스로 공개되어 있습니다.

워킹 그룹의 피드백의 일환으로, 우리는 플랫폼 통합 영역을 더 잘 설명하기 위해 문서의 많은 부분을 개편했습니다. 새로운 가이드에는 렌더링 철학(Rendering Philosophy), 플랫폼 배포(Deploying to Platforms) 기능 매트릭스, PPR 플랫폼 가이드, 재검증 작동 방식(How Revalidation Works), 그리고 CDN 캐싱(CDN Caching)이 포함됩니다.

테스트 스위트

우리는 Next.js 테스트 스위트를 어댑터 작성자들이 사용할 수 있도록 공개했습니다. 이 테스트 스위트는 스트리밍 동작, 캐싱 상호작용, 클라이언트 네비게이션 및 실제 환경의 에지 케이스를 다룹니다. 새로운 기능이 출시되면 그 동작은 이 테스트에 기록됩니다.

자세한 내용은 어댑터 테스트 문서에서 확인할 수 있습니다.

어댑터 작성자는 어떤 어댑터를 사용하든 이 스위트를 실행하여 각 기능에 대한 통과/실패 결과를 얻을 수 있습니다. 이는 Vercel이 자체 어댑터에 사용하는 것과 동일한 테스트 스위트이므로, 모든 제공업체에 걸쳐 동일한 정확성 기준이 공유됩니다.

검증된 어댑터

검증된 어댑터(Next.js GitHub 조직 하에 호스팅되고 플랫폼 배포 문서에 나열됨)가 되기 위해서는 두 가지가 필요합니다. 오픈 소스여야 하며, 전체 테스트 스위트를 통과해야 합니다. 어댑터를 오픈 소스로 만듦으로써 어댑터 유지 관리를 위한 공간을 확보하고, 문제를 보고하고 분류할 수 있도록 보장합니다. 테스트 스위트는 어댑터의 Next.js 호환성을 측정할 수 있게 해줍니다.

각 검증된 어댑터는 이를 구축한 팀이 소유합니다. 플랫폼마다 환경이 매우 다를 수 있고 우리가 특정 구현을 강제할 수 없기 때문에, 게시 권한, 릴리스 주기 및 구현 결정은 해당 팀의 권한입니다.

제공업체는 동일한 공개 API를 사용하여 소스 비공개(Closed-source) 어댑터를 구축하고 출시할 수도 있습니다.

공개 Adapter API는 현재 다음 어댑터들과 함께 제공됩니다:

Vercel 어댑터: 오픈 소스이며, Next.js 출력을 Vercel의 서버리스 및 CDN 인프라에 매핑합니다.

Bun 어댑터: 대체 런타임에서 완전한 Next.js 배포 타겟을 구축하는 방법을 보여주는 레퍼런스 어댑터입니다.

OpenNext를 통한 Netlify, Cloudflare, AWS용 어댑터는 활발히 개발 중이며, 올해 말 출시될 예정입니다.

Cloudflare는 개발자들이 어디에나 Next.js 앱을 배포할 수 있는 안정적이고 열린 규약을 가질 자격이 있다고 믿었기에 처음부터 OpenNext의 일원이었습니다. 공식 Next.js Adapter API는 그 비전을 현실로 만듭니다. Cloudflare의 글로벌 개발자 플랫폼에서 Next.js를 실행하는 개발자들은 이제 프레임워크의 진화에 발맞춰 Next.js 팀과 협력하여 설계된 공통의 기반 위에서 개발할 수 있게 될 것입니다. 이 공동의 노력에 파트너로 참여하게 되어 기쁩니다. — Fred K Schott, Cloudflare 엔지니어

에코시스템 워킹 그룹

우리는 Next.js 팀, 호스팅 제공업체, 어댑터 유지 관리자 간의 상설 포럼인 Next.js 에코시스템 워킹 그룹(Next.js Ecosystem Working Group)을 설립합니다. 회의록은 공개될 예정입니다. 그룹에 참여하고 싶으시다면 Jimmy에게 연락해 주세요.

우리는 제공업체들이 변경 사항을 출시 후에 알게 되는 것이 아니라, 다가올 변경 사항을 조기에 파악하기를 원합니다. 하위 호환성이 깨지는 변경 사항은 그 범위에 비례하는 준비 기간과 함께 제공될 것입니다. 새로운 기능은 출시 전 다양한 환경에서 테스트됩니다. 전체 거버넌스 문서에서 이러한 약속들을 자세히 다루고 있습니다.

파트너들의 더 많은 소식을 확인해 보세요:

Next.js Adapter API 출시: 다음 단계는 무엇인가 (Netlify)

OpenNext의 3년 (OpenNext)

Next.js 배포 어댑터: Google Cloud에서 Next.js의 밝은 미래 (Google Cloud / Firebase)

OpenNext와 Next.js 팀의 협업은 커뮤니티 중심의 우회책을 공식 표준으로 변화시켰으며, 웹 프레임워크의 미래가 개방성과 공유된 혁신 위에 구축된다는 것을 증명했습니다. — Dorseuil Nicolas, OpenNext

이 API를 공동 설계하고 각자의 플랫폼에 대해 검증하는 데 시간을 투자해 주신 Build Adapters 워킹 그룹 멤버들(Netlify, Cloudflare, Google Cloud, AWS Amplify, OpenNext의 엔지니어들)에게 감사드립니다. 또한 어댑터를 구축하고, 버그를 제보하며, 우회책을 마련해 주신 모든 기여자분께도 감사드립니다.

Next.js는 수백만 명의 개발자가 사용하며, 그중 상당수는 Vercel이 아닌 인프라에서 운영됩니다. 그들도 동일한 수준의 안정성과 새로운 기능에 대한 접근권을 누릴 자격이 있습니다. Adapter API는 이를 제공합니다. 즉, 우리를 포함한 모두에게 동일한 기준을 적용하는 공개 테스트 스위트와 함께, 모든 플랫폼이 구축할 수 있는 공유된 규약을 제공합니다.

우리가 개발하는 모든 새로운 기능은 어댑터 규약에 문서화될 것입니다. RFC 프로세스는 계속 열려 있을 것이며, API가 진화함에 따라 어댑터 작성자들과 조율해 나갈 것입니다.