AI 워크플로우로 Next.js 앱을 만드는 속도는 빨라졌다. v0.dev로 UI를 뽑고, Cursor로 API를 연결하고, Claude로 데이터 스키마를 설계한다. 프로토타입이 하루 만에 나오는 시대다. 그런데 속도가 빨라질수록 조용히 넓어지는 구멍이 있다. 바로 보안 설계다.
미들웨어를 믿었는데, 미들웨어가 뚫렸다
올해 3월, Next.js 생태계를 뒤흔든 취약점이 공개됐다. CVE-2025-29927, CVSS 9.1의 치명적 인증 우회 버그다. dev.to에 공개된 분석에 따르면, 공격 방식은 놀랍도록 단순하다. x-middleware-subrequest라는 내부 헤더 하나를 요청에 붙이면 Next.js는 미들웨어 실행을 통째로 건너뛴다. 인증 로직이 미들웨어에만 있다면, 보호받는 페이지가 사실상 열려 있던 셈이다.
이 버그가 특히 위험한 이유는, AI 워크플로우가 만들어내는 코드 패턴과 정확히 충돌하기 때문이다. "미들웨어에서 인증 체크"는 Next.js 튜토리얼에서 가장 흔히 등장하는 패턴이다. AI가 생성하는 보일러플레이트도 대부분 같은 구조를 따른다. 빠르게 만들어진 앱일수록, 미들웨어가 유일한 인증 게이트가 될 가능성이 높다. 취약 버전 범위는 11.1.4부터 15.2.3 미만으로, 수년치 Next.js 앱이 잠재적으로 노출됐다. Vercel·Netlify 배포는 영향을 받지 않지만, next start 혹은 output: 'standalone'으로 셀프 호스팅 중이라면 즉시 버전을 확인해야 한다.
패치 자체는 명확하다. 각 메이저 라인의 수정 버전(15.2.3, 14.2.25, 13.5.9, 12.3.5)으로 업그레이드하면 된다. 그러나 진짜 교훈은 버전 숫자 너머에 있다. Vercel 공식 포스트모템이 직접 말한다. "미들웨어를 경로 보호의 유일한 수단으로 사용하지 말 것." 미들웨어는 UX를 위한 조기 리다이렉트 레이어다. 실제 데이터를 돌려주는 Route Handler, Server Action, 그리고 데이터 액세스 레이어 각각에서 인증을 재검증해야 한다. 가장 강력한 안전망은 데이터베이스 Row-Level Security다. 애플리케이션 레이어를 모두 우회한 요청도 소유하지 않은 행을 읽을 수 없게 된다.
AI가 쓴 HTML 안에 숨은 아웃바운드 요청들
인증 우회와는 결이 다른 보안 구멍도 있다. AI가 생성한 HTML 자체가 열어놓는 아웃바운드 채널이다. dev.to의 한 글은 이 문제를 날카롭게 짚는다. AI에게 "이 데이터로 대시보드 만들어줘"라고 요청하면 동작하는 페이지가 나온다. 그런데 그 안에는 CDN에서 불러오는 폰트, 습관처럼 삽입된 애널리틱스 스니펫, unpkg에서 당겨오는 차트 라이브러리가 조용히 섞여 있을 수 있다. 악의가 없다. 모델이 학습한 가장 흔한 HTML 패턴을 그대로 재현했을 뿐이다.
문제는 이 페이지를 비공개 링크로 클라이언트에게 공유하는 순간 시작된다. 외부 리소스를 향한 모든 아웃바운드 요청은 제3자에게 "누군가가 이 페이지를 열었다"는 신호를 보낸다. 이미지 URL의 쿼리스트링 하나도 데이터 유출 채널이 될 수 있다. 인바운드 보안(누가 접근하는가)은 챙겼는데, 아웃바운드 보안(페이지가 어디에 접속하는가)은 손도 안 댄 구조다.
실용적인 해법은 CSP(Content Security Policy)를 기본 거부로 설정하고, 허용 출처를 명시적으로 승인하는 것이다. script-src, style-src, font-src, connect-src, frame-src를 모두 'self'로 잠그고, 필요한 외부 출처는 화이트리스트에 하나씩 추가한다. 와일드카드는 금지다. 다만 기본 거부는 사용자 경험을 조용히 망가뜨린다. 폰트가 안 뜨고, 차트가 깨지고, 왜 그런지 아무도 모른다. 그래서 이 글의 저자가 제안하는 방식이 현실적이다. 배포 시점에 파일을 스캔해 외부 출처 목록을 사용자에게 보여주고, 명시적으로 승인하게 한다. 보안 정책을 일회성 클릭이 아니라 페이지의 지속적인 속성으로 관리하는 구조다.
빠른 아키텍처 설계가 놓치는 것들
dev.to에 공개된 AI 친화적 SaaS 디스커버리 엔진 설계 가이드는, 역설적으로 보안 사각지대가 어디서 생기는지를 잘 보여준다. Next.js, PostgreSQL, MCP(Model Context Protocol)를 엮어 AI 클라이언트까지 서비스하는 이 아키텍처는 설계 원칙 자체는 탄탄하다. 단일 정보 소스에서 모든 공개 표현을 생성하고, Zod로 입력 경계를 명확히 하며, 엔티티 모델을 UI보다 먼저 설계하라는 가이드는 프로덕트 관점에서도 옳다.
그런데 이 아키텍처에서 Public API와 MCP 인터페이스가 등장하는 순간, 인증·인가 레이어 설계는 별도의 고민이 필요해진다. AI 클라이언트가 소비하는 엔드포인트는 인간 사용자보다 훨씬 빠르고 체계적으로 데이터를 수집할 수 있다. Rate limiting, 요청 출처 검증, 데이터 접근 범위 제어가 처음부터 설계되지 않으면, 빠르게 만든 아키텍처가 나중에 큰 비용을 요구한다.
속도의 대가를 설계 단계에서 치러야 한다
세 사례가 하나의 패턴을 가리킨다. AI 워크플로우는 동작하는 코드를 빠르게 만들어준다. 그런데 보안 설계는 "동작하는가"의 문제가 아니라 "어떤 경계를 신뢰하는가"의 문제다. AI는 경계를 설계하지 않는다. 가장 흔한 패턴을 재현할 뿐이다.
미들웨어 단일 인증 게이트는 흔한 패턴이다. CDN 폰트와 외부 스크립트를 포함한 HTML도 흔한 패턴이다. Public API를 무인증으로 열어두는 것도 초기 프로토타입에서 흔한 패턴이다. AI가 생성한 코드가 동작한다고 해서 보안 설계가 완료된 게 아니다. 오히려 빠르게 만들어진 구조일수록, 보안 레이어를 처음부터 의식적으로 겹쳐 쌓아야 한다.
실무에서 바로 적용할 수 있는 체크리스트는 단순하다. Route Handler와 Server Action 각각에서 인증을 재검증하고 있는가. CSP 헤더가 기본 거부로 설정되어 있는가. AI가 생성한 HTML 안에 의도하지 않은 외부 리소스 요청이 없는지 배포 전에 확인하는가. 그리고 현재 사용 중인 Next.js 버전이 CVE-2025-29927 패치를 포함하고 있는가. 네 가지 질문에 모두 "예스"라고 답할 수 있을 때, 그 앱은 빠르게 만들어졌으면서도 제대로 설계된 것이다.
프레임워크가 진화하고 AI 도구가 코드를 쏟아낼수록, 보안 경계를 어디에 그을지 판단하는 일은 점점 더 인간 개발자의 몫으로 수렴한다. 속도는 도구가 줘도 좋다. 경계 설계는 넘길 수 없다.