프로젝트 Vercel 배포 시 이슈 해결 과정
배경
리팩토링 사항을 모두 적용한 후, 성공적으로 Vercel 빌드 액션을 통과하여 배포를 완료했다. 로컬 환경에서 별다른 문제 없이 잘 동작했기 때문에 배포에도 문제가 없을 것이라 생각했다. 그러나 배포 사이트를 확인한 결과, API 요청이 이루어지지 않는 것을 확인했다.
Mixed Content 문제 발생
오류 문구에 "mixed content"라는 내용이 포함되어 있었다. Mixed content 문제는 HTTPS와 HTTP 간의 통신에서 발생하는 문제다. 백엔드는 AWS를 통해 배포되어 HTTP 프로토콜을 이용하는 반면, 프론트엔드는 Vercel을 통해 배포되어 HTTPS 프로토콜을 사용한다. 이로 인해 보안상의 문제로 차단되어 mixed content 오류가 발생하게 되었다.
프록시 사용으로 문제 해결
배포 툴을 교체하거나 백엔드를 HTTPS로 전환하는 방법도 고려했으나, 이는 현실적으로 어렵거나 다른 사람에게 책임을 전가하는 것 같아 불편했다. 해결책을 모색한 결과, 프록시를 사용하면 문제가 해결된다는 사실을 알게 되었다. Next.js의 rewrite 기능을 사용하여 mixed content 문제를 해결했다.
ENV 환경변수 설정 문제
처음에 rewrite를 적용하여 배포했을 때 mixed content 문제는 해결되었지만, 백엔드 경로 설정에 이상이 있었다. 이는 ENV 환경변수 설정에 문제가 있었기 때문이었다. 클라이언트 사이드에서 ENV 환경변수에 접근하려면 NEXT_PUBLIC 키워드를 사용해야 하지만, 이를 누락하여 발생한 문제였다.
개발자 모드에서는 ENV의 접근의 편의성을 위해 NEXT_PUBLIC 키워드 없이도 클라이언트 사이드에서 접근이 가능하다. 그러나 프로덕션 모드에서는 반드시 NEXT_PUBLIC 키워드를 사용해야 한다. 이로 인해 발생한 문제를 수정하고 다시 배포하였다.
403 Forbidden 오류 발생
환경변수를 수정하여 다시 배포한 결과, 이번에는 배포된 사이트에 접근 시 403 Forbidden이라는 오류가 발생하였다.
해당 요청의 경우 클라이언트 요청이 서버에 도달하였지만 권한 등의 문제로 거부당했다. 주로 VPN을 우회하거나 TorBrowser를 사용할 때 발생하는 오류였다.
웹 서칭 결과, 루트 디렉토리에 vercel.json이라는 파일을 생성하고 rewrite를 똑같이 설정해줘야 한다고 하여 설정해주고 배포했지만 문제는 여전하였다.
알고 보니 vercel.json의 rewrite 설정은 프로젝트가 프록시를 지원하지 않는 경우 Vercel에서 대신 프록시를 지원해주는 기능이었다.
프록시 설정 문제와 Vercel 차단
해당 문제를 좀 더 세밀하게 파악하기 위해 다른 외부에서 프록시가 동작하는지 확인이 필요하여 nslookup을 통해 Vercel 도메인 IP를 확인하고 Postman으로 요청을 보내보았다. 예상과 달리 Postman을 통한 요청에는 정상적인 값을 반환해주었다. 그러나 배포된 사이트에서 보내는 통신은 차단되는 원인을 알 수 없었다.
WireShark를 통한 패킷 분석
이 문제를 정확히 파악하기 위해 WireShark를 통해 패킷을 분석해보았다. 문제에서 제일 골치 아팠던 부분이 403 오류만 출력되고, 프록시 요청이라 네트워크 탭에서는 referer와 도착지가 Vercel로 표시되었다. 로컬 프로덕션 빌드 상태에서 WireShark를 테스트한 결과, 원본 요청을 확인할 수 있었다. 그러나 Vercel에 적용하여 필터링한 결과 어떤 요청도 잡히지 않았다. Vercel의 경우 HTTPS 통신으로 암호화되어 request를 필터링해도 감지할 수 없었다.
백엔드 로그 확인과 CORS 문제
Vercel의 도메인 IP를 이용해 필터링해본 결과, 분명히 요청은 보내지만 그 요청이 HTTPS라 확인이 불가했다. 문제를 확인하기 위해 백엔드 로그를 확인한 결과, GET 요청은 잘 통신하지만 POST 요청은 로그가 남지 않았다. 로컬 환경에서는 GET, POST 로그가 잘 찍히지만, Vercel 배포와 동일한 문제를 localhost:8008에서 확인할 수 있었다.
알고 보니 백엔드에서 CORS 제한을 풀어주기로 했는데, AWS에 배포된 빌드 파일에서는 적용되지 않은 문제였다. 프록시 요청이라 그런지 이상하게 CORS 오류 문구는 나타나지 않았다. 이런 경우의 오류가 발생할 수 있다는 사실을 알게 되었다. 오랜만에 WireShark 분석을 해봤는데, 네트워크 공부의 필요성을 다시금 느꼈다.
느낀점
대학 시절 와이어샤크를 통한 패킷 분석을 참 많이 했는데 프론트엔드를 하면서 사용하게 될 줄은 몰랐다. 비록 2년 만에 사용해보아 기억이 가물하여 사용하는데 애를 좀 먹었지만, 간단한 필터만 활용해도 정확하게 네트워크 요청을 분석할 수 있어 너무 편리하다는 생각이 들었다.
