Next.js 16 부터 middleware.ts 가 proxy.ts 로 이름이 바뀌었습니다. 단순 리네이밍이 아니라 의도적으로 명칭을 바꾼 것으로 보이는데, 실제로 어떤 차이가 있는지 알고 계신 분 계실까요?
특히 신경 쓰이는 부분은:
1. matcher 의 동작 방식
2. cookies()/headers() 의 async 변경 영향
3. revalidateTag 의 cacheLife 강제
비슷하게 마이그레이션 진행해 보신 분 경험 공유 부탁드립니다.
김지훈
@jihoon · Frontend
주요 차이점은 다음과 같습니다.
1. proxy.ts 는 의도적으로 '얇게 동작' 하도록 설계되었습니다. 전 세계에 분산 배포되는 특성상 매 요청 비용이 중요한데, 무거운 인증 검증을 강제하지 않도록 가이드를 전환했습니다.
2. cookies()/headers() 가 모두 async 가 되었기 때문에 proxy 안에서 await 없이 동기 호출하면 런타임 에러가 발생합니다. 마이그레이션 시 가장 많이 놓치는 부분입니다.
3. revalidateTag 의 cacheLife 강제는 캐시 폭주를 막기 위한 안전장치입니다. 기본값은 'days' 입니다.
실제 마이그레이션 PR 예시는 https://github.com/example/migration 에 정리해 두었습니다.
이수아
@suah · Backend · Gold
정하늘 정확한 답변 감사합니다! cacheLife 부분이 특히 도움됐어요. · 10분 전
최서연 matcher 변경은 저도 한 번 당했네요 ㅎㅎ · 5분 전
추가로 한 가지 더, matcher 의 정규식이 조금 더 엄격해졌습니다. 기존에 부분 매칭으로 동작하던 패턴이 v16 에서는 명시적인 부정 lookahead 가 필요해진 케이스가 있었어요. 자세한 건 공식 마이그레이션 가이드 참고하시면 좋겠습니다.
박민우
@minwoo · DevOps · Silver
마크다운, 코드 블록, 이미지 첨부를 지원합니다.