프로젝트의 기술 스택을 선택하는 것은 중요하고 중대한 결정입니다. 특히 기업 환경에서는 프로젝트의 로드맵, 개발 속도, 결과물의 품질, 나아가 행복한 팀을 구성하고 유지하는 능력에까지 장기적인 영향을 미치는 다년간의 노력을 수반하곤 합니다.
오픈소스 소프트웨어 모델은 이에 대한 근본적인 해답입니다. 오픈소스로 개발된 소프트웨어를 사용함으로써 누구든지 자신의 사용 사례에 맞게 확장하거나 수정할 수 있습니다. 더 중요한 것은, 오픈소스 소프트웨어의 이식성 덕분에 개발자와 조직은 특정 공급자에 종속될까 두려워하지 않고도 다양한 공급자 간에 인프라를 자유롭게 옮길 수 있는 자유를 얻는다는 점입니다.
Next.js는 이러한 기대를 가진 오픈소스 웹 개발 프레임워크입니다. Next.js의 관리형 호스팅 서비스를 제공하는 클라우드 공급자인 Vercel에 의해 만들어지고 관리됩니다.
회사가 직접 만든 오픈소스 소프트웨어를 통해 수익을 창출하는 데에는 아무 문제가 없습니다. 특히 그것이 프로젝트 개발 자금 조달에 도움이 된다면 더욱 그렇습니다. 실제로 우리 업계에는 이런 모델이 성공적으로 작동하는 많은 사례가 있습니다.
그러나 이 모델이 지속 가능하려면, 회사와 오픈소스 프로젝트 간의 경계가 명확해야 한다고 생각합니다. 프레임워크의 유지관리자, 호스팅 제공업체, 사용자 간에 각 기능이 어디서 어떻게 사용될 수 있는지에 대한 명확한 기대치가 존재해야 합니다.
저는 오늘날 이러한 투명성이 존재하지 않는다고 생각하는 이유를 설명하고자 합니다.
저의 목적은 누구든 Next.js 사용을 막는 것이 아니라, 가능한 많은 정보를 제공하여 개발자와 기업이 기술 스택에 대한 정보에 입각한 결정을 내릴 수 있도록 하는 것입니다.
이해관계 고지
먼저 이해관계에 대한 고지를 드리겠습니다.
- 저는 Netlify에서 일하고 있으며, 4년 넘게 근무 중입니다.
- Netlify는 Next.js 및 다른 웹 프레임워크들을 제품의 일부로 지원하는 프론트엔드 클라우드 플랫폼입니다.
- Netlify와 Vercel은 직접적인 경쟁 관계에 있습니다.
제가 이 사실을 명확히 해야 하는 데에는 몇 가지 이유가 있습니다.
저의 업무는 Netlify에서 Next.js의 전체 기능을 지원하는 데 필요한 인프라와 도구를 구축하는 일입니다. 이러한 일은 대부분의 사람들이 접하기 어려운 프레임워크의 내부를 들여다볼 기회를 제공합니다. 저는 수년 동안 오픈소스 프레임워크와 이를 개발한 회사의 인프라가 긴밀하게 얽혀 있는 문제점들을 목격해 왔습니다.
또한 저의 고용 관계는 이런 우려를 공개적으로 말하는 데 항상 조심스러웠던 이유이기도 합니다. Netlify의 직원으로서 Next.js에 대한 객관적인 문제를 제기하면, 많은 분들이 이를 경쟁사를 겨냥한 FUD라고 오해할 가능성이 있기 때문입니다.
저는 개인적으로나 회사적으로 그런 논란에 휘말리고 싶지 않았습니다. 그래서 지금까지는 조용히 Netlify에 사이트를 배포하기로 한 개발자분들을 적극 지원하고 그분들을 복잡한 내부 구조로부터 보호하는 데 집중해 왔습니다.
그러던 중, 중요한 사건이 발생했습니다.
지난 주말, Vercel은 Next.js에서 치명적인 보안 취약점이 발견되었다고 공개했습니다. 이러한 유형의 문제는 드물지 않지만, Vercel의 대응 방식은 매우 미흡하고 무모했으며, 커뮤니티에 대한 배려가 부족했다고 느꼈습니다. 이 일은 저에게 프로젝트의 거버넌스에 대한 오랜 우려를 더욱 심화시키는 계기가 되었습니다.
저는 타인의 안전을 위협하는 결정이 내려진 시점부터는 상황이 달라진다고 생각합니다. 그렇기에 이제는 목소리를 내야겠다고 결심했습니다.
개방성과 거버넌스
이 사건에 대한 자세한 이야기는 잠시 후 다시 말씀드리겠습니다. 그에 앞서 약간 뒤로 물러나 커튼 뒤를 들춰보고 싶습니다. Next.js의 개방성과 거버넌스에 대해 오랫동안 가지고 있던 저의 우려는 Vercel이 지난 수년간 내려온 일련의 결정들로부터 비롯되었으며, 이러한 결정들은 다른 호스팅 제공자들이 프레임워크의 전체 기능을 지원하기 어렵게 만들었습니다.
Next.js가 어떻게 구축되는지에 대한 일련의 사실을 나열하며 설명하겠습니다. 그런 다음 이러한 사실이 개방적이고 상호 운용 가능한 엔터프라이즈 등급의 소프트웨어 제품에 대한 기대에 얼마나 부합하는지에 대한 제 관점을 공유하겠습니다.
사실 1: 어댑터의 부재
대부분의 최신 웹 개발 프레임워크는 어댑터(adapter) 개념을 사용하여 프레임워크의 결과물을 특정 배포 대상에 맞춰 구성합니다. 예를 들어 Remix, Astro, Nuxt, SvelteKit, Gatsby 등이 있습니다. 이 패턴을 사용하면 개발자가 애플리케이션의 핵심을 그대로 유지하면서도, 어댑터만 교체하면 간단히 배포 대상을 바꿀 수 있습니다.
이러한 어댑터는 프레임워크 작성자, 호스팅 제공자, 커뮤니티, 또는 그 이상의 모든 사람이 유지 관리할 수 있습니다. 대부분의 프레임워크는 특정 공급자용 어댑터가 없더라도 누군가가 직접 구현할 수 있도록 구조가 설계되어 있습니다.
하지만 Next.js는 어댑터라는 개념이 없으며 과거에 어댑터를 지원하지 않겠다고 명확히 밝힌 바 있습니다. Next.js 빌드의 결과물은 Vercel에서의 배포를 위해 사용되는 독자적이며 문서화되지 않은 형식을 따릅니다.
Vercel은 이에 대한 대안으로 “Build Output API”를 제시했습니다. 이는 Vercel로 배포하려는 프레임워크를 위한 출력 형식에 대한 문서화된 명세입니다.
하지만 이건 Next.js의 어댑터 인터페이스가 아니며, 사실 Next.js와 아무런 관련이 없습니다. 발표 블로그 게시물에서는 Next.js가 이 형식을 지원한다고 했지만, 현재로서는 사실이 아닙니다.
2023년 11월, Next.js 공식 문서에는 다음 주요 버전(15버전)에서 Build Output API를 채택하겠다는 내용이 업데이트 되었습니다.
Next.js는 관리형 환경과 자체 호스팅 환경 모두에서 모든 기능을 지원하는 표준 배포 출력을 생성합니다. 다음 주요 버전에서는 이 출력을 Build Output API 명세로 전환할 것입니다.
하지만 2024년 10월에 릴리스된 Next.js 15.0.0에는 Build Output API 지원이 포함되지 않았습니다.
Vercel은 고객이 해당 분야의 풍부한 프레임워크 생태계를 활용하기를 원했기 때문에 Build Output API를 구축했지만, 그들의 프레임워크에서는 아직까지 이를 지원하지 않습니다.
이는 Next.js의 API가 발표 없이도 마이너 및 패치 배포에 중대한 변경 사항이 포함될 수 있음을 의미합니다. 즉, Vercel 외의 모든 호스팅 제공자는 이런 위험을 감수하며 구축해야 합니다. (실제로 그렇게 해왔습니다.)
작년 말, Cloudflare 와 Netlify는 Next.js용 오픈소스 어댑터에 협력하는 다양한 클라우드 공급자의 움직임 인 OpenNext에 가입했습니다 . 얼마 지나지 않아 Vercel은 이 움직임에 참여하여 어댑터에 대한 지원을 구축하기로 약속했습니다. 아직 구체적인 일정은 발표되지 않았지만, 최근 적극적으로 개발 중이라고 밝혔습니다.
Build Output API가 출시된 지 거의 3년이 지났음에도, 아직까지도 이 프레임워크에 이식성이 없다는 점을 기억하는 것이 중요합니다. 그래도 이번에는 실제로 변화가 있을 것이라고 조심스럽게 낙관하고 있습니다.
사실 2: 공식 서버리스 지원 없음
Next.js를 자체 호스팅하려면 애플리케이션을 상태를 유지한 채로 실행하는, 장기 실행 서버 방식으로 운영해야 합니다. 이론적으로는 가능한 방식이지만, 실제 운영 환경에서는 단일 인스턴스로는 충분하지 않은 경우가 많아 매우 까다로운 작업입니다.
이런 설정은 갑작스러운 트래픽 폭주를 처리할 수 있도록 매우 빠르게 동적으로 확장 가능해야 하며, 동시에 비용 효율을 위해 필요 없을 땐 0으로 축소할 수도 있어야 합니다. 이 마지막 부분은 서버 컴포넌트를 작업할 때 특히 중요합니다. 예를 들어, 클라이언트와 서버 코드가 복잡하게 얽혀 있는 경우, 이전에 배포된 모든 버전의 서버 코드가 무기한 유지되지 않으면 오래된 클라이언트가 중단될 수 있기 때문입니다.
이런 요구사항에 대한 확실한 해답 중 하나는 서버리스 컴퓨팅입니다. Next.js 공식 문서에서도 서버리스 컴퓨팅의 장점을 언급하고 있습니다.
서버리스는 분산된 장애 지점과 무한한 확장성을 제공하며, “사용한 만큼만 지불”하는 모델로 매우 경제적입니다.
이처럼 명확하게 장점이 있는 컴퓨팅 패러다임은, Vercel이 자체 인프라에서 수년간 Next.js 사이트를 운영해온 방식이기도 합니다. Next.js가 오픈 프레임워크라는 점을 감안하면, 모든 서버리스 제공자에서 동일한 모델을 사용할 수 있으리라 기대하는 것은 합리적입니다. 하지만 현실은 그렇게 단순하지 않습니다.
과거에는 Next.js에 서버리스 모드가 존재했고, 설정 속성 하나로 이를 활성화할 수 있었습니다. 그러나 2022년 10월, 별다른 설명 없이 이 기능은 제거되었습니다. 그리고 이에 상응하는 대체 모드는 도입되지 않았습니다.
Next.js 팀이 유지 관리에 참여하고 있는 공식 React 문서에는 Next.js가 “어떤 서버리스 호스팅 환경”에도 배포될 수 있다고 나와 있지만, 이를 위한 공식 문서는 전혀 존재하지 않습니다.
즉, 다른 클라우드 공급자들이 Next.js가 장려하고 있는 서버리스 모델을 지원하고 싶다면, 독자적으로 프레임워크를 리버스 엔지니어링하여 커스텀 구현을 개발해야 한다는 뜻입니다.
사실 3: Vercel 전용 코드 경로
Next.js에는 오직 Vercel에 배포된 사이트에서만 실행되는 코드 경로가 있습니다. 그 예시 중 하나는 minimal mode라는 비공개 플래그입니다. 이 플래그는 Vercel이 프레임워크에서 일부 작업을 분리하여 자사 엣지 인프라에서 처리할 수 있도록 합니다.
왜 이것이 중요한지 예를 들어보겠습니다. Next 12는 미들웨어(middleware) 기능을 도입했는데 이는 기능 플래그, A/B 테스트, 고급 라우팅 같은 사례를 지원하기 위한 방식입니다. 이들 사용 사례는 공통적으로 캐시 뒤의 핫 경로에서 매우 낮은 지연 시간으로 로직을 실행해야 합니다.
당시 공지에는 다음과 같은 내용이 포함되어 있었습니다.
이는
next start명령어를 사용하여 바로 작동하며, Vercel과 같은 엣지 플랫폼에서 엣지 미들웨어를 통해 실행됩니다.
하지만 실제로는 두 가지 선택지밖에 없었습니다. next start를 사용하고 애플리케이션의 나머지 부분과 함께 오리진 서버에서 미들웨어를 실행하거나 (이는 일반적으로 단일 지역에서 실행되며 캐시 이후에서 처리됨), “Vercel과 같은 엣지 플랫폼”을 사용하여 미들웨어를 캐시 전에 엣지에서 실행하여 Vercel이 발표에 링크된 리소스에서 자랑했던 모든 놀라운 기능들을 활용하는 것입니다.
“Vercel과 같은 엣지 플랫폼”이라는 문구는, 마치 다른 공급자들도 미들웨어를 엣지에서 실행할 수 있도록 기능이 공개되어 있다는 의미처럼 들리지만 그렇지 않습니다.
이 비밀스러운 minimal mode 덕분에 Vercel은 미들웨어를 애플리케이션의 나머지 부분과 분리하여 엣지에서 실행할 수 있었지만, 이 기능에 접근할 수 있는 것은 오직 Vercel 뿐입니다.
Netlify도 미들웨어를 엣지에서 실행하는 기능을 지원합니다. 하지만 이는 우리 엔지니어 팀이 프레임워크를 리버스 엔지니어링하고, 문서화되지 않은 API 위에 자체 엣지 미들웨어 구현을 구축하는데 전념한 결과입니다. 이는 소규모 기업이라면 절대 감당할 수 없는 규모의 노력이며 대부분의 기업은 이런 싸움을 포기합니다.
제가 아는 한, Vercel 외에 Next.js의 전체 기능을 지원하는 클라우드 제공자는 Netlify가 유일한데, 제게 이건 말도 안 되는 일입니다. Next.js가 시장에서 이렇게 큰 점유율을 가지고 있다면, 더 많은 호스팅 옵션이 있어야 하며, 이는 전반적으로 경쟁과 혁신을 촉진하여 궁극적으로 사용자와 웹에 이익이 될 것입니다.
그렇다면 Next.js에 Vercel만이 열쇠를 가지고 있는 숨겨진 문이 있는 이유는 무엇일까요? 프레임워크 유지 관리자가 출시 전에 기능을 정기적으로 실험하는 것은 예상할 수 있는 일이지만, minimal mode는 그런 실험이 아닙니다. 우리는 수년 동안 코드베이스에 존재해온 완전히 별개의 운영 모드에 대해 이야기하고 있으며, 이는 프레임워크를 소유한 영리 기업만 사용할 수 있는 기능을 잠금 해제합니다.
만약 WordPress에 Automattic에서 호스팅된 사이트에서만 접근 가능한 특권 코드 경로가 있었다면, WordPress가 진정한 오픈소스로 신뢰받고 오늘날과 같은 지배력을 유지할 수 있었을까요?
보안 관점
이제 다시 보안 사고로 돌아가 봅시다. 3월 21일 금요일 오전 10시 17분(UTC), Vercel은 심각한 보안 사고에 대해 CVE를 발표했으며, 그 심각도는 10점 만점에 9.1점으로 평가되었습니다.
간단히 말하면, 특정 헤더를 요청에 포함시키는 것으로 누구든지 Next.js 미들웨어를 완전히 우회할 수 있었습니다. 이것은 매우 중요했는데 왜냐하면 인증은 미들웨어의 대표적인 사용 사례 중 하나이며, 이 취약점을 이용하면 누구나 인증 레이어를 통과하여 보호된 리소스에 접근할 수 있게 되기 때문입니다.
사건이 전개되면서 몇 가지 사실이 드러났습니다. 우선, 이 취약점은 2월 27일에 Next.js 팀에 보고되었지만, 3월 14일이 되어서야 팀이 이를 조사하기 시작했습니다. 일단 조사에 착수하자, 몇 시간 안에 Next 14와 Next 15에 대한 수정이 배포되었습니다.
즉, 최소한 3월 14일에는 Vercel이 심각한 사고가 있다는 것을 인지하고 있었다는 뜻입니다. 그 시점에서 해야할 책임감 있는 행동은 다른 공급자에 취약점을 즉시 공개하여 그들이 자체 고객에게 미치는 영향을 평가하고 가능한 한 빨리 고객을 보호하기 위해 필요한 조치를 취하는 것입니다. 이런 시기에 사용자를 보호해야 하는 의무는 회사 간의 경쟁보다 우선해야 합니다.
하지만 그런 일은 일어나지 않았습니다. Vercel이 Netlify에 연락하기까지는 8일이 걸렸습니다. 그동안 그들은 Next.js에 패치를 푸시하고, 두 번 배포했으며, 심지어 Vercel의 방화벽이 고객을 *“사전 예방적으로 보호”*한 사례로 포장한 블로그 포스트도 작성했습니다. (나중에 CTO가 방화벽은 이 일과 아무 관련이 없다고 말했음에도 불구하고 말이죠).
오픈소스 프로젝트의 중대한 보안 취약성을 제품의 장점으로 돌리는 것은 엄청나게 부정직하다고 생각합니다. 게다가 다른 공급자의 사용자들이 영향을 받았는지, 어떤 대응이 필요한지도 전혀 고려하지 않았습니다. 실은 그들은 이 사실을 알지도 못할 겁니다. 왜냐하면 그들은 아직 우리에게 연락조차 하지 않았기 때문입니다.
소셜 미디어에서 비판이 일자, Vercel은 블로그 게시물을 다시 작성하여 방화벽에 대한 언급을 삭제하고 어떤 공급자가 영향을 받았는지, 고객이 어떤 조치를 취해야 하는지 명확히 밝혔습니다.
이후 Vercel은 사고 후속 보고서를 발표하며, 처음으로 3월 21일에 “Netlify와 Cloudflare Workers는 영향을 받지 않았음을 확인했다” 고 밝혔습니다. 그러나 이것은 그들의 직원이 3월 22일에 Netlify에 연락해 “패치를 적용하는 것을 도와주겠다”고 했던 내용과 정면으로 모순됩니다. 영향이 없었다면, 패치할 것이 무엇이 있었겠습니까?
Vercel이 자사 외의 사용자들에 대해 보여준 이 무관심은 불필요한 불안과 혼란을 야기했습니다. 어떤 공급자는 해결책을 찾기 위해 애쓰다가 부분적으로 롤백해야 했고, 다른 공급자는 실제로는 취약 했는데 취약하지 않다고 발표하는 등의 일이 발생했습니다.
지금 이 글을 읽고 있는 시점에도, 여전히 얼마나 많은 사이트들이 이 취약점에 노출되어 있는지 아무도 알 수 없습니다. 상황이 다르게 처리되었다면 안전했을 사이트도 많습니다.
그리고 이 모든 혼란이 한창일 때, Vercel의 리더십은… 다른 것에 집중하고 있었습니다.
하지만 Vercel이 Next.js를 소유하고 있잖아요
맞습니다. 그리고 그들은 그들이 수년간 노력과 재능, 시간, 에너지를 들여 만든 프레임워크로 사업을 할 권리가 있습니다. 저는 그것을 부정하지 않습니다.
하지만 그 성장에는 엄격한 기준이 함께 따라야 합니다. 제 생각에, Vercel은 그 기준을 계속 충족하지 못했습니다.
가끔 이런 질문을 보게되는데, 흥미롭게 생각합니다.
“Vercel이 Next.js를 소유하고 있다면, 왜 다른 공급자에게 열어줘야 하지?”
그렇다면 Redis는 왜 자신들의 Redis Cloud가 있음에도 소프트웨어를 개방했을까요? Grafana Cloud가 있는 상태에서 Grafana를 왜 공개할까요? 또는 WordPress, ClickHouse, 그리고 다른 많은 회사들은 왜 그럴까요?
그들이 소프트웨어를 폐쇄적이고 독점적인 솔루션이 아닌 오픈 소스로 공개하기로 선택했다면 그러한 일을 해야 한다는 것이 그 이유입니다. 그들의 성공은 본질적으로 사용자들이 언제든지 자신의 필요를 충족하는 서비스를 제공하는 공급자를 자유롭게 선택할 수 있다는 보장과 관련이 있습니다.
맺으며
제게 어떤 프레임워크를 사용해야 하는지 말할 자격은 없습니다. Next.js가 마음에 들고, 당신의 문제를 해결하기 위한 최선의 도구라고 생각한다면, 당연히 써야 합니다. 하지만 이 정보가 어느 쪽을 선택하든 당신이 더 확신을 가지고 결정하는 데 도움이 되기를 바랍니다.
저는 개발자들이 어떤 프레임워크를 선택하든 Netlify에 사이트를 배포하기로 선택한 개발자들을 지원하기 위해 제 일을 계속할 것입니다. 그리고 경쟁은 제쳐두고, 저는 Vercel이 OpenNext 운동을 통해 Next.js를 더 개방적이고 상호 운용 가능하게 만드는 데 도움을 줄 수 있기를 진심으로 기대하고 있습니다.
업데이트 (3월 26일): Vercel의 최신 사후 분석에 대한 언급이 추가되었습니다.
업데이트 (3월 28일): Vercel의 대표가 다음과 같은 약속을 했습니다. “앞으로 어떤 새로운 특권 코드 경로도 도입하지 않을 것이며, 현재 존재하는 것들(예: minimal mode)은 제거하거나 완전히 문서화할 것입니다.” 일정에 대해서는, 올해 안에 완료되기를 희망한다고 밝혔습니다.
🚀 한국어로 된 프런트엔드 아티클을 빠르게 받아보고 싶다면 Korean FE Article을 구독해주세요!