Next.js Edge Functions 운영 가이드: App Router에서 랜딩·SaaS·관리자 API 나누는 기준
결론부터 말하면, Next.js Edge Functions는 “모든 API를 Edge로 보내면 빨라진다”는 기능이 아닙니다. App Router 프로젝트에서는 공개 랜딩, 지역·언어 리다이렉트, 짧은 공개 GET 응답, 가벼운 개인화처럼 요청 앞단에서 빠르게 끝나는 로직만 Edge 후보로 보는 편이 안전합니다. 반대로 관리자 화면의 복잡한 권한 처리, ORM 기반 DB 트랜잭션, 파일 업로드·변환, 엑셀·PDF 생성, 장기 실행 작업은 Node.js Runtime 또는 별도 백엔드로 남겨야 합니다.
이 글의 핵심은 “Edge를 쓸까 말까”가 아니라 “어떤 경로를 Edge에 두고, 어떤 경로는 Node에 남길까”입니다. Next.js 공식 문서는 Edge Runtime이 Node.js API 전체를 지원하지 않고, ISR도 지원하지 않으며, 일부 패키지가 예상대로 동작하지 않을 수 있다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/pages/api-reference/edge?utm_source=openai)) 따라서 대표·PM·마케터가 기대하는 성능 개선과 개발팀이 감당해야 할 운영 제약을 한 장의 의사결정표로 맞춰보는 것이 먼저입니다.

1. Edge Runtime은 “가까운 서버”가 아니라 “제약이 있는 실행 계약”입니다
Edge Runtime을 이해할 때 가장 흔한 오해는 “사용자와 가까운 곳에서 실행되니 무조건 빠르다”는 생각입니다. 실제 운영에서는 사용자의 위치뿐 아니라 데이터가 있는 위치, 인증 서버 위치, 외부 API 위치, 함수 번들 크기, 캐시 가능성, 로그 수집 방식이 함께 영향을 줍니다. 사용자는 서울에 있는데 DB는 미국 동부에 있고 Edge 함수가 매 요청마다 DB를 왕복한다면, Edge에서 시작한 요청이 긴 국제 왕복을 만들 수 있습니다.
Next.js App Router에서 기본 서버 런타임은 Node.js이며, 특정 page, layout, route segment에서 export const runtime = 'edge'처럼 Edge Runtime을 지정할 수 있습니다. Route Segment Config 문서는 runtime 옵션이 'nodejs' | 'edge' 형태이며 기본값은 'nodejs'라고 설명합니다. ([nextjs.org](https://nextjs.org/docs/15/app/api-reference/file-conventions/route-segment-config?utm_source=openai)) Vercel 배포 환경에서는 app/api/my-function/route.ts 같은 Route Handler에 export const runtime = 'edge'를 추가하는 방식으로 edge runtime을 지정할 수 있습니다. ([vercel.com](https://vercel.com/docs/functions/runtimes/edge?utm_source=openai))
다만 2026년 기준 공식 문서 흐름을 보면 Edge를 기본값처럼 쓰라는 방향은 아닙니다. Vercel Edge Runtime 문서는 현재 edge에서 Node.js로의 마이그레이션을 성능과 안정성 측면에서 권장한다고 안내하고, 두 런타임 모두 Fluid Compute와 Active CPU pricing 모델에서 동작한다고 설명합니다. ([vercel.com](https://vercel.com/docs/functions/runtimes/edge?utm_source=openai)) 이 문구는 “Edge가 항상 더 빠르다”가 아니라 “라우트별로 측정하고 선택하라”는 신호로 읽어야 합니다.
2. 화면 유형별 1차 판단: 랜딩은 후보, 관리자 API는 보수적으로
초기 SaaS나 정부지원사업 MVP에서 Next.js를 쓰는 팀은 하나의 App Router 프로젝트 안에 SEO 랜딩, 로그인 후 대시보드, 관리자 화면, 내부 운영 API를 모두 넣는 경우가 많습니다. 이때 모든 Route Handler에 Edge를 붙이면 구조가 단순해 보이지만, 운영 리스크는 커질 수 있습니다. 다음 표처럼 화면 성격별로 먼저 나눠보는 것이 좋습니다.
| 구분 | Edge 후보 | Node.js에 남길 가능성이 큰 로직 | 실무 판단 기준 |
|---|---|---|---|
| SEO 랜딩·캠페인 페이지 | 국가·언어 리다이렉트, A/B 테스트 분기, 짧은 공개 JSON | CMS 원본 조회, 복잡한 미리보기 권한, 온디맨드 재검증 | 정적 생성·CDN 캐시로 해결 가능한지 먼저 확인 |
| SaaS 첫 화면 | 로그인 쿠키 존재 여부 기반의 가벼운 분기, feature flag 조회 | 계정별 대시보드 집계, 다중 테넌트 권한 확인, 과금 상태 계산 | 개인화 데이터가 캐시 가능한지와 DB 위치를 함께 봄 |
| 관리자 화면 | 거의 제한적. 비로그인 사용자의 빠른 차단 정도 | 역할 기반 권한, 감사 로그, 데이터 수정, 파일 관리, 승인 워크플로 | 최종 권한 검증은 서버 액션·Route Handler·백엔드에서 반복 |
| 외부 Webhook·배치성 API | 서명 검증이 Web API만으로 가능하고 응답이 매우 짧은 경우 | 결제 후처리, 메일 발송, DB 트랜잭션, 장기 작업 큐 등록 | 재시도, 멱등성, 장애 복구가 더 중요 |
랜딩 페이지도 “Edge를 쓰면 빠르다”가 아니라 “Edge에서 실행할 요청 시점 로직이 있는가”를 먼저 물어야 합니다. 단순 회사소개, 서비스 소개, 가격표처럼 대부분 사용자에게 같은 콘텐츠라면 정적 생성, CDN 캐시, 이미지 최적화, 폰트 최적화가 먼저입니다. Next.js의 ISR과 재검증 전략은 Next.js ISR·온디맨드 재검증 전략에서 더 자세히 다뤘듯이, Edge Runtime 자체보다 콘텐츠 최신성·캐시 무효화 정책의 문제에 가깝습니다.

3. App Router에서 런타임을 나누는 기본 구조
실무에서는 URL 구조부터 Edge와 Node를 구분하는 것이 유지보수에 유리합니다. 예를 들어 공개 API는 /api/public/*, 인증된 사용자 API는 /api/app/*, 운영자 API는 /api/admin/*처럼 나누고, 각 폴더의 route.ts 또는 상위 segment에서 런타임을 명시합니다. 단, layout 단위로 Edge를 지정하면 하위 경로 전체에 영향이 갈 수 있으므로 관리자 화면이 섞인 segment에서는 특히 조심해야 합니다.
권장 출발점: 기본은 Node.js로 두고, “Edge가 필요한 이유가 문서화된 경로”에만 Edge를 켭니다. 이유가 “빠를 것 같아서”라면 아직 적용 근거가 부족합니다.
Route Handler는 App Router의 app 디렉터리 안에서 route.js|ts 파일로 정의하며, GET, POST, PUT, PATCH, DELETE 등 HTTP 메서드를 처리할 수 있습니다. Next.js 문서는 Route Handlers가 기본적으로 캐시되지 않으며, GET 메서드에 한해 route config로 캐싱을 opt-in할 수 있다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/getting-started/route-handlers?utm_source=openai))
// app/api/public/geo/route.ts export const runtime = 'edge' export async function GET(request: Request) { const country = request.headers.get('x-country') ?? 'KR' return Response.json({ country }) }// app/api/admin/users/route.ts export const runtime = 'nodejs' export async function GET() { // 세션 검증, 역할 확인, DB 조회, 감사 로그 기록 return Response.json({ users: [] }) }이런 식의 분리는 코드 리뷰에서도 유리합니다. Edge 경로에 fs, Node 전용 crypto 사용, ORM client, native module이 들어오면 리뷰 단계에서 바로 잡아낼 수 있습니다. Next.js Edge Runtime 문서는 native Node.js API를 지원하지 않고, 파일 시스템을 읽거나 쓸 수 없으며, require 대신 ES Modules를 사용해야 한다고 안내합니다. ([nextjs.org](https://nextjs.org/docs/pages/api-reference/edge?utm_source=openai))
4. Middleware·Proxy는 “전체 인증 서버”가 아닙니다
Next.js에서 Middleware 또는 Proxy는 요청이 완료되기 전에 헤더 수정, rewrite, redirect, 실험 분기 같은 처리를 할 수 있는 앞단 로직입니다. 그러나 공식 문서는 Proxy가 느린 데이터 fetching에 적합하지 않고, 권한 기반 리다이렉트 같은 낙관적 검사는 가능하지만 전체 세션 관리나 권한 부여 솔루션으로 쓰면 안 된다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/getting-started/proxy?utm_source=openai))
Next.js 16 이후 문서에서는 Middleware가 Proxy로 이름이 바뀌는 전환도 진행되고 있습니다. 업그레이드 문서는 middleware 파일명이 deprecated 되었고 proxy로 변경되었다고 안내하면서, edge runtime 지원과 관련해 별도 주의가 필요하다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/guides/upgrading/version-16?utm_source=openai)) 그래서 현재 운영 중인 팀은 “우리 프로젝트의 Next.js 버전, 배포 플랫폼, 파일명, 런타임이 실제로 무엇인지”를 빌드 결과와 로그로 확인해야 합니다.
관리자 화면 인증은 특히 단순화하면 안 됩니다. Next.js 인증 가이드는 Route Handlers와 Server Actions를 public-facing API endpoint와 같은 보안 고려로 다루고, 사용자가 해당 작업을 수행할 권한이 있는지 검증해야 한다고 설명합니다. ([nextjs.org](https://nextjs.org/docs/app/guides/authentication?utm_source=openai)) 자세한 권한 모델은 Next.js App Router 인증 권한 설계 가이드를 참고하면 좋습니다.
5. 캐시 설계: Edge 실행, CDN 캐시, Route Handler 캐시는 다릅니다
Edge Runtime으로 실행한다고 해서 자동으로 안전한 캐시가 생기는 것은 아닙니다. 캐시는 “누구에게 같은 응답을 보여줘도 되는가”의 문제입니다. 공개 랜딩의 가격표는 캐시하기 쉽지만, 고객사별 사용량, 결제 상태, 관리자 승인 목록은 캐시 키와 무효화 정책을 잘못 잡으면 개인정보·영업정보 노출로 이어질 수 있습니다.
| 캐시 계층 | 적합한 데이터 | 주의할 데이터 | 운영 포인트 |
|---|---|---|---|
| 정적 파일·CDN | 이미지, JS/CSS, 공개 랜딩 HTML | 사용자별 화면 | 빌드 해시, Cache-Control, purge 정책 확인 |
| Route Handler GET 캐시 | 공개 설정, 공개 카탈로그, 변경 빈도 낮은 데이터 | 로그인 사용자별 API | 기본은 dynamic임을 전제로 opt-in |
| Cache Components | 컴포넌트·함수 단위로 재사용 가능한 서버 데이터 | 쿠키·헤더 등 요청 컨텍스트에 직접 의존하는 값 | use cache, cacheLife, tag 기반 무효화 검토 |
| Edge Runtime | 짧은 요청 시점 분기, 지역·언어·실험 처리 | 긴 DB 왕복, 권한 결정의 단일 근거 | 실행 위치와 데이터 위치를 함께 측정 |
Cache Components를 켜는 프로젝트는 더 주의해야 합니다. Next.js 문서는 Cache Components가 활성화되면 dynamic, revalidate, fetchCache 같은 route segment config를 use cache와 cacheLife로 대체한다고 설명하며, runtime = 'edge'는 지원되지 않고 Node.js runtime으로 전환해야 한다고 안내합니다. ([nextjs.org](https://nextjs.org/docs/app/guides/migrating-to-cache-components?utm_source=openai)) 또한 Cache Components 사용 시 GET Route Handlers는 일반 UI route와 같은 모델을 따르며, use cache는 Route Handler 본문이 아니라 helper 함수로 분리해야 합니다. ([nextjs.org](https://nextjs.org/docs/app/getting-started/route-handlers?utm_source=openai))
CDN을 앞에 두는 경우에는 Next.js가 렌더링 전략에 따라 표준 Cache-Control 헤더를 설정할 수 있지만, App Router 응답은 커스텀 요청 헤더에 따라 달라질 수 있습니다. ([nextjs.org](https://nextjs.org/docs/app/guides/cdn-caching?utm_source=openai)) 따라서 Edge 적용 회의에서는 “이 경로가 Edge인가”보다 “이 응답이 shared cache에 들어가도 되는가”를 먼저 물어야 합니다.

6. DB·ORM·파일 처리는 Edge보다 Node가 안전한 경우가 많습니다
Edge Runtime에서 가장 자주 터지는 문제는 로컬 개발에서는 괜찮아 보였던 패키지가 배포 후 런타임에서 실패하는 경우입니다. 원인은 대체로 세 가지입니다. 첫째, 패키지가 Node.js native API나 파일 시스템에 의존합니다. 둘째, CommonJS require 또는 동적 코드 실행을 사용합니다. 셋째, DB 드라이버가 TCP 연결, connection pooling, native binding을 전제로 합니다.
공식 문서는 Edge Runtime에서 일부 Web API와 제한된 Node.js 호환 API만 사용할 수 있고, 지원 목록에 없는 Node.js API는 사용할 수 없다고 설명합니다. Vercel Edge Runtime 문서도 eval, new Function, 일부 WebAssembly 동적 컴파일 같은 기능이 비활성화되어 있으며, edge function bundle size에도 플랜별 제한이 있다고 안내합니다. ([vercel.com](https://vercel.com/docs/functions/runtimes/edge?utm_source=openai))
따라서 관리자 화면에서 흔한 다음 기능은 Node.js Runtime 또는 별도 백엔드로 두는 것을 기본값으로 잡는 편이 좋습니다.
- ORM 기반 데이터 조회·수정: Prisma, TypeORM, Sequelize 등은 Edge 호환 여부와 DB 연결 방식을 별도로 검증해야 합니다. 단순 조회라면 HTTP Data API를 검토할 수 있지만, 트랜잭션과 감사 로그가 얽히면 Node가 낫습니다.
- 파일 업로드: Edge에서 파일을 받아 처리하기보다 Node API가 서명 URL을 발급하고, 브라우저가 object storage로 직접 업로드하도록 설계하는 편이 안정적입니다.
- 엑셀·PDF·이미지 변환: 폰트, 바이너리, 메모리, 처리 시간이 얽히므로 Edge에 올릴 이유가 거의 없습니다.
- 외부 API 후처리: 결제 webhook, 메일 발송, CRM 동기화는 멱등성 키와 재시도 큐가 더 중요합니다.
- 관리자 감사 로그: 누가 어떤 데이터를 언제 바꿨는지 남기는 로직은 최종 mutation 경로와 같은 트랜잭션 경계에서 처리해야 합니다.
7. 인증·환경변수·보안: Edge에서는 “가볍게 보고”, 서버에서 “확정”합니다
Edge에서 할 수 있는 인증의 좋은 예는 “세션 쿠키가 없으면 로그인 페이지로 보낸다”, “JWT 서명을 Web Crypto로 검증해 명백히 잘못된 요청을 빠르게 차단한다”, “특정 국가에서 공개 캠페인 접근을 다른 랜딩으로 보낸다” 정도입니다. 나쁜 예는 “Edge에서 DB session table을 조회해 관리자 권한을 최종 판정한다”, “권한 체크를 Proxy에만 두고 Route Handler에서는 생략한다”, “개인별 응답을 shared cache에 넣는다”입니다.
환경변수도 운영 방식이 중요합니다. Next.js Edge Runtime 문서는 process.env로 환경변수에 접근할 수 있다고 설명하지만, 브라우저에 노출되는 NEXT_PUBLIC_ 접두어와 서버 전용 비밀값은 분명히 구분해야 합니다. ([nextjs.org](https://nextjs.org/docs/pages/api-reference/edge?utm_source=openai)) 플랫폼에 따라 Edge Runtime에서 사용할 수 있는 환경변수 주입 방식과 preview·production 값이 다를 수 있으므로, 관리자 토큰·DB 비밀번호·서드파티 API 키는 배포 환경의 secret 관리 정책으로 통일해야 합니다.
실무 권장 패턴은 이렇습니다. Edge에서는 “요청을 더 진행할 가치가 있는지”를 판단하고, Node.js Route Handler 또는 백엔드에서는 “이 사용자가 이 데이터에 이 작업을 해도 되는지”를 다시 확인합니다. 이렇게 중복 검증을 하면 약간의 코드가 늘지만, 관리자 화면과 SaaS 과금 기능에서는 그 비용이 장애·정보노출 비용보다 훨씬 작습니다.
8. 로그와 비용: Edge 적용 후에는 route별로 따로 봐야 합니다
Edge 적용의 성공 여부는 Lighthouse 점수 하나로 판단하기 어렵습니다. 운영에서는 최소한 route별 호출 수, p50·p95 응답시간, 에러율, 외부 API 호출 시간, 캐시 hit 여부, runtime, region을 함께 봐야 합니다. Vercel 문서는 Functions의 runtime logs를 대시보드에서 실시간으로 확인할 수 있고, Pro·Enterprise 플랜에서는 Log Drains로 로그를 외부 분석 도구에 보낼 수 있다고 설명합니다. ([vercel.com](https://vercel.com/docs/functions/logs?utm_source=openai)) Runtime Logs 문서는 requestId, traceId, invocationId, region, function runtime, duration, memory usage 같은 세부 정보를 확인할 수 있다고 안내합니다. ([vercel.com](https://vercel.com/docs/logs/runtime?utm_source=openai))
Next.js의 instrumentation.js는 Node.js와 Edge runtime 모두에서 동작할 수 있고, process.env.NEXT_RUNTIME으로 런타임별 등록 로직을 나눌 수 있습니다. ([nextjs.org](https://nextjs.org/docs/pages/api-reference/file-conventions/instrumentation?utm_source=openai)) 작은 팀이라면 처음부터 복잡한 APM을 붙이기보다 구조화 로그를 먼저 정리하는 것이 현실적입니다. 예를 들어 모든 API 로그에 requestId, route, runtime, tenantId_hash, userRole, db_ms, external_ms, cache, status를 남기면 장애 회고가 훨씬 쉬워집니다.
비용 측면에서는 “짧으니 싸다”가 아니라 “얼마나 자주 호출되는가”가 중요합니다. Vercel 문서는 Edge Runtime 함수가 응답을 25초 안에 시작해야 하며 스트리밍은 더 지속될 수 있다고 설명하고, 함수 사용량은 CPU time 같은 기준으로 측정된다고 안내합니다. ([vercel.com](https://vercel.com/docs/functions/limitations?utm_source=openai)) 모든 요청이 지나가는 Middleware·Proxy에 외부 API 호출이나 로그 과다 출력을 넣으면, 응답시간과 비용이 동시에 늘어날 수 있습니다.
9. 적용 전 체크리스트: Edge 후보인지 확인하는 15문항

Edge에 올려도 되는지 확인할 질문
- 이 경로의 응답은 보통 50~200ms 안에 끝나야 의미가 있는가?
- DB, 파일 시스템, native module,
require에 의존하지 않는가? - 사용자와 가까운 위치에서 실행했을 때 실제 데이터 소스 왕복이 줄어드는가?
- 응답이 공개 데이터이거나, 개인화되더라도 캐시 키가 명확한가?
- 인증은 빠른 차단 수준이고, 최종 권한 검증은 다른 서버 경로에서 반복되는가?
- 번들 크기와 의존성 트리가 Edge 제한에 들어오는가?
- 장애 시
runtime = 'nodejs'로 되돌리는 롤백 계획이 있는가?
Node.js에 남겨야 하는 신호
- ORM client, DB transaction, connection pooling이 핵심이다.
- 관리자 권한, 감사 로그, 결제 상태, 테넌트 격리가 얽혀 있다.
- 파일 업로드, 이미지 변환, 엑셀·PDF 생성, 압축 해제 같은 작업이 있다.
- 응답보다 후처리의 정확성, 재시도, 멱등성이 중요하다.
- 외부 API가 느리거나 rate limit이 있어 queue·retry가 필요하다.
- 개발팀이 Edge 호환 패키지를 지속적으로 검증할 여력이 부족하다.
- 로그·트레이스·보안 감사가 Node 서버 기준으로 이미 안정화되어 있다.
- Cache Components를 적극 사용하고 있으며 edge runtime 제약과 충돌한다.
10. 단계적 도입 로드맵: 한 번에 바꾸지 말고 경로 단위로 검증합니다
첫 번째 단계는 라우트 인벤토리입니다. app 디렉터리의 page, layout, route.ts, Server Actions, Middleware·Proxy를 나열하고 각 경로의 데이터 소스, 인증 방식, 캐시 정책, 외부 API, 파일 처리 여부를 표로 만듭니다. 이 표가 없으면 Edge 적용은 감으로 흘러갑니다.
두 번째 단계는 후보 경로 1~2개만 선택하는 것입니다. 예를 들어 /api/public/geo, /api/public/feature-flags, /campaign/[slug]처럼 실패해도 핵심 데이터가 손상되지 않고, 응답이 짧으며, DB 왕복이 적은 경로가 좋습니다. preview 환경에서 p50·p95·에러율·로그량을 비교한 뒤 production traffic의 일부에만 적용합니다.
세 번째 단계는 관리자 화면과 운영 API를 명확히 분리하는 것입니다. /admin 하위 layout에 Edge runtime을 무심코 지정하지 말고, 관리자 Route Handler는 runtime = 'nodejs'를 명시해 의도를 드러내는 것도 방법입니다. 이 구조는 외주개발 인수인계나 정부지원사업 MVP 이후 유지보수에서도 도움이 됩니다. 나중에 담당 개발자가 바뀌어도 “왜 이 API는 Edge가 아닌가”가 코드에 남기 때문입니다.
네 번째 단계는 운영 문서화입니다. Edge 후보 경로마다 적용 이유, 금지 의존성, 캐시 정책, 인증 책임, 로그 필드, 롤백 방법을 남겨야 합니다. AgentMit는 Next.js 기반 SaaS, 관리자 대시보드, 업무 자동화, 정부지원사업 MVP를 설계할 때 Edge를 성능 만능 옵션이 아니라 이런 역할 분리 설계의 일부로 봅니다. BizMit형 프로젝트에서도 공개 랜딩과 관리자 API를 같은 방식으로 배포하지 않고, 운영자가 실제로 장애를 추적할 수 있는 구조를 우선합니다.
FAQ
Q1. Next.js Edge Functions를 쓰면 무조건 빨라지나요?
아닙니다. 사용자가 전 세계에 있고 응답이 짧으며 DB 왕복이 적을 때는 지연시간 개선 가능성이 있지만, Edge에서 다시 먼 리전의 DB를 호출하면 오히려 느려질 수 있습니다. 랜딩 리다이렉트, 짧은 공개 GET, 가벼운 개인화부터 측정하는 것이 안전합니다.
Q2. App Router에서 runtime = 'edge'는 어디에 설정하나요?
page, layout, route.ts 같은 route segment에서 export const runtime = 'edge'를 설정하는 방식이 일반적입니다. 기본값은 Node.js입니다. 다만 Cache Components를 켜면 edge runtime과 일부 route segment 설정이 제약될 수 있으므로 프로젝트의 Next.js 버전과 배포 플랫폼 문서를 함께 확인해야 합니다.
Q3. 관리자 화면 인증을 Edge 또는 Middleware/Proxy에서 처리해도 되나요?
Edge 또는 Middleware/Proxy는 로그인 여부에 따른 빠른 리다이렉트, 지역·언어 분기, 단순 차단에는 적합합니다. 하지만 최종 권한 검증은 Route Handler, Server Action, 별도 백엔드에서 다시 해야 합니다. 관련 구조는 Next.js Middleware·Proxy 설계 가이드와 함께 보면 좋습니다.
Q4. Edge Runtime에서 Prisma, 파일 업로드, 엑셀 생성 같은 기능을 돌릴 수 있나요?
대부분은 Node.js 런타임에 남기는 편이 안전합니다. Edge Runtime은 Node.js 전체 API를 지원하지 않고 파일 시스템, 일부 native 의존성, require, 동적 코드 실행에 제약이 있습니다. ORM, DB 트랜잭션, 파일 처리, PDF·엑셀 생성, 대용량 업로드는 Node.js API 또는 별도 백엔드 작업 큐로 분리하는 것이 좋습니다.
Q5. Edge 적용 후 비용과 로그는 어떻게 관리해야 하나요?
Edge 적용 전후로 route별 p50·p95 응답시간, 호출 수, 에러율, 외부 API 시간, 캐시 hit 여부를 나눠 봐야 합니다. 모든 요청을 Edge 로직에 태우지 말고 matcher를 좁히며, 구조화 로그에 requestId, runtime, region, route, cache 상태를 남겨야 비용과 장애 원인을 추적할 수 있습니다.
참고한 공식 문서
- Next.js Edge Runtime API Reference: Edge Runtime의 Node.js API 제약, ISR 미지원, 환경변수 접근 방식 확인
- Next.js Route Segment Config: App Router의 route segment별 runtime 설정과 기본값 확인
- Next.js Route Handlers: Route Handler의 HTTP 메서드, 캐시 기본 동작, Cache Components 연동 확인
- Next.js Authentication Guide: Route Handler와 Server Actions의 권한 검증 책임 확인
- Vercel Edge Runtime 및 Function Logs: 배포 플랫폼의 edge runtime 제한, 로그, 비용 관점 확인
Next.js Edge Functions를 도입할 때 가장 좋은 첫 결정은 “어디에 쓸지”보다 “어디에는 쓰지 않을지”를 먼저 정하는 것입니다. 랜딩은 빠르게, 관리자 API는 안전하게 나누는 기준이 있으면 성능 개선과 운영 안정성을 동시에 얻을 가능성이 높아집니다.

