#1. Next.js 애플리케이션에 HTTP 엔드포인트가 필요할 때
Next.js 애플리케이션이 외부 요청을 직접 받아야 하는 경우라면:
- 결제 서비스 Webhook 수신
- OAuth callback 처리
- 파일 업로드 또는 다운로드
- Next.js 서비스에서만 사용하는 간단한 API
이 경우 다음의 아키텍쳐를 갖는다:
외부 서비스 또는 브라우저
│
▼
Next.js Route Handler
│
▼
데이터베이스 또는 외부 서비스
만약, API 서버가 이미 존재한다면 굳이 Route handler를 필요하지 않을 수 있다. 하지만 그럼에도 필요한 경우는:
- Webhook 주소가 Next.js 서비스의 주소여야 하는 경우
- OAuth callback을 Next.js에서 직접 처리해야 하는 경우
- 해당 엔드포인트가 Next.js 화면에만 필요한 경우
- Next.js가 외부에 공개되는 유일한 서버인 경우
요약하면, 간단한 CRUD 애플리케이션이라면 API 서버를 만드는 것 자체가 오버 엔지니어링이 될 수 있기 때문에 route handler를 작은 서버로서 운영하는데 적절하다.
#2. 브라우저와 서버 사이에서 서버 전용 작업을 처리하기 위해
예를 들어 외부 API가 시크릿 키를 요구한다고 하자. 이때 브라우저가 외부 API를 직접 호출하면 키가 노출되어 사용자가 개발자 도구나 Network 탭에서 키를 확인할 수 있다. 반면, route handler를 사용하면 키는 서버에만 남기 때문에 안전하게 관리할 수 있다.
하지만 API 서버가 이미 존재한다면, API 서버가 외부 API를 호출하기 때문에 시크릿 키가 노출되지 않아서 굳이 route handler가 필요하지 않다.
브라우저 → 기존 API 서버 → 외부 API
└─ secret-key
#3. CORS 정책 우회
브라우저와 서버 사이 요청에서는 CORS 설정이 존재하지 않는다면 CORS 에러가 발생한다. 하지만, 서버와 서버 사이에서는 CORS 에러가 발생하지 않는다. 그렇기 때문에 route handler를 일종의 프록시 서버로 활용하여 CORS 정책을 우회할 수 있다.
하지만 이 또한 API 서버가 이미 존재한다면 서버에서 CORS 설정을 하면 해결되기 때문에 굳이 route handler가 필요하지 않다.
#4. BFF로 활용
한 화면을 조립하기 위해 여러 API를 호출해야 하는 경우가 종종 있을 수 있다. 이때, 브라우저에서 모든 API를 호출하여 UI를 조립하는 것도 하나의 방법이 될 수 있지만, Route Handler를 BFF로 사용하면 여러 API 호출과 데이터 조합 책임을 서버로 옮길 수 있다. 브라우저는 화면에 필요한 형태의 데이터만 받아 UI 렌더링에 집중할 수 있다. 즉, BFF를 사용하면 브라우저는 여러 API의 호출 순서와 응답 데이터 조합을 직접 관리하지 않고, 화면에 필요한 데이터를 받아 UI 렌더링에 집중할 수 있게 된다.
브라우저가 직접 조립하는 경우:
브라우저
├─ 사용자 API 호출
├─ 주문 API 호출
├─ 알림 API 호출
└─ 응답 데이터 조합 후 UI 렌더링
Route Handler를 BFF로 사용하는 경우:
브라우저
│ 화면용 데이터 요청
▼
Route Handler
├─ 사용자 API 호출
├─ 주문 API 호출
├─ 알림 API 호출
└─ 데이터 조합
│
▼
브라우저 → 조합된 데이터로 UI 렌더링
하지만, 이 또한 API 서버에서 통합 API를 제공할 수 있다면 필요하지는 않게 된다.
내가 내린 결론은, API 서버가 이미 존재하고, 브라우저 요청부터 인증·조합·외부 연동까지 처리할 수 있다면 Route Handler는 굳이 필요하지 않다.