LAN·외부 기기에서 채팅 연결 안 되던 개발 환경 cross-origin

로컬이나 LAN을 통해 개발 서버에 접속할 때 채팅 기능이 연결되지 않는 문제가 발생했다. Next.js의 HMR 설정에서 cross-origin 차단이 원인이었는데, allowedDevOrigins 설정을 추가해서 해결했다.

개발 환경의 보안과 편의성 사이의 균형

처음 보면 이상한 문제다. 로컬 개발 환경에서 보안 정책이 뭐 하는 짓인가 싶을 수 있다. 그런데 생각해보면 Next.js는 localhost에서 HMR 서버를 띄우는데, 브라우저의 same-origin policy 때문에 다른 origin에서의 요청이 자동으로 차단되는 것이다.

프로덕션에서는 한 도메인으로 통일되니까 문제가 없지만, 개발할 때는 상황이 다르다:
- 로컬에서 localhost:3000으로 접속
- 같은 팀원이 LAN IP로 192.168.x.x:3000로 접속
- 스마트폰이나 다른 기기에서 테스트하려고 외부 IP로 접속

이런 여러 접근 방식이 모두 "다른 origin"으로 취급되어 채팅 같은 실시간 통신이 차단된다.

HMR과 cross-origin의 만남

HMR(Hot Module Replacement)은 파일을 수정했을 때 전체 리로드 없이 변경된 부분만 빠르게 업데이트하는 개발 경험의 핵심이다. 브라우저가 개발 서버와 통신해서 "어떤 파일이 바뀌었으니 리로드해라"는 메시지를 받는 방식이다.

그런데 채팅 같은 기능이 WebSocket이나 다른 API로 같은 origin 외의 곳으로 요청을 보내려고 하면, 브라우저의 CORS 정책이 "안 돼"라고 차단해버린다. 특히 개발 환경에서 여러 origin에서 접근할 수 있도록 해야 할 때 이 문제가 두드러진다.

next.config.ts에서 개발 origin 화이트리스트

이런 문제의 일반적인 해결책은 개발 환경에서만 특정 origin들을 허용하는 것이다. 프로덕션에서는 당연히 한 도메인으로 통일되니까 이런 설정이 필요 없고, 개발할 때만 유연하게 대응하면 된다.

// next.config.ts의 핵심 개념
allowedDevOrigins: [
  'localhost:3000',
  '127.0.0.1:3000',
  '192.168.0.0/16',  // LAN 대역
  // ... 팀의 필요에 맞게
]

이렇게 설정하면 개발 서버가 "이 origin들한테는 HMR과 채팅 연결을 허용하겠다"는 뜻이다. 프로덕션 배포 때는 이 설정이 비활성화되거나 무시되므로 보안에 영향을 주지 않는다.

로컬 개발과 네트워크 테스트의 현실

이 수정을 하고 깨달은 게, 요즘 개발 환경은 더 이상 "내 노트북의 localhost만"이 아니라는 것이다:

• 팀원끼리 LAN을 통해 서로의 개발 서버에 접속해서 테스트
• 모바일 기기를 연결해서 반응형 디자인 확인
• 원격으로 개발 서버를 띄워두고 외부에서 접속

이런 상황들이 점점 흔해지는데, 기본 설정에서는 다 차단된다. 그래서 개발 환경 설정에서 이런 유연성을 처음부터 고려하는 게 중요하다.

배운 점과 팀 온보딩

이런 작은 설정 하나가 신입이나 팀에 합류한 개발자에게는 "왜 내 환경에서는 채팅이 안 되지?" 같은 답답함을 줄 수 있다. 프로젝트 문서에 "LAN 또는 외부에서 접속할 때는 이렇게 설정하세요"라고 명확하게 남겨두는 게 좋겠다는 생각이 들었다.

또 하나는, 초기 설정 때부터 가능한 접근 방식들을 미리 고려하는 것이다. 혼자 개발할 때와 팀 협업할 때, 모바일 테스트할 때를 구분해서 설정하는 습관. 이게 개발 생산성과 직결된다.

🛒 이 글과 어울리는 추천 상품

• 외장SSD 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• USB허브 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.