Middleware를 "공통 함수" 정도로 외웠는지, 아니면 실행 시점·`matcher` 범위·런타임 제약·라우트 내부 검증과의 책임 분리까지 보는지 가르려는 질문이다. 후속으로 보안·성능 어느 쪽으로 파고들지를 결정하는 분기점이다.
Next.js Middleware는 요청이 라우트(페이지/Route Handler)에 닿기 전에 한 번 끼어드는 전단 레이어다. 쿠키·헤더를 읽어 인증을 확인하고, 응답을 만들기 전에 리다이렉션·rewrite·헤더 주입을 처리한다. 적용 범위는 matcher로 좁히는 게 원칙이고, 그렇지 않으면 정적 자산까지 매 요청마다 함수가 깨어난다. 최신 Next에서는 같은 컨벤션이 proxy.ts로 리네이밍되며 기본 런타임이 Node.js로 바뀌는 흐름이라, 답변에서는 "전단 레이어"라는 개념과 "파일 컨벤션·런타임 버전 차이"를 분리해 말하는 게 안전하다.
Middleware에 무거운 호출을 넣었다가 응답이 일제히 느려진 경험이 있다면, 전단에 둘 일과 라우트로 내릴 일을 나눈 기준을 답변에 녹일 수 있다
`matcher`를 다듬어 정적 자산·헬스체크 호출이 빠지면서 함수 호출 수가 줄어든 경험이 있다면, 그 전후 수치를 그대로 들고 갈 수 있다
전단에서만 막아둔 페이지가 내부 API 직접 호출로 우회된 사고를 겪었다면, 라우트 내부 인가 검증을 다시 깐 설계 결정을 이 질문과 연결할 수 있다
Edge에서 Node 런타임으로 옮기며 라이브러리 호환을 다시 본 경험이 있다면, 런타임 제약이 왜 사람이 직접 끊어야 하는 판단인지를 자기 사례로 설명할 수 있다
아직 공개된 답변이 없어요. 첫 공개 답변을 남겨보세요.