custom project를 Vercel에 배포하는 과정에서 새롭게 배운점

이전에 Vercel에 app을 배포하는 경우의 대다수는 Create-react-app 또는 Create-next-app을 사용한 프로젝트들을 배포하였었다.

위 라이브러리들을 통해 구현된 프로젝트의 경우 Vercel에 배포할 때 별다른 설정없이 배포 페이지에 화면이 정상적으로 렌더링되는 개발경험이 많았다.

하지만 현재 ladder-game의 프로젝트는 react를 webpack을 통해 직접 custom 하여 개발되어진 상태였고 Vercel의 배포는 정상적으로 동작하지만 빌드 결과를 제대로 import 해오지 못하여 빈 화면의 페이지가 배포된 문제를 직면하게 되었다.

이에 따라 Vercel의 배포 원리 과정과 Vercel 사이트의 배포 설정과 관련된 UI들에 대해 새롭게 배운점들이 많아 글을 작성하게 되었다.

Vercel의 기본 동작 원리를 알아보자

위 이미지의 기본 배포 설정은 Framework Preset 설정에 따라 기본적으로 조금씩 달라진다. 그렇다 대표적으로 Create-React-app, Next.js 등이 존재한다. 하지만 위에 말했듯 나의 경우 Create-react-app이 아닌 react의 필요 요소만을 설치하고 webpack을 통해 dev, production 서버를 커스텀하니 Other로 자동 분류되어진 상황이다.

예시로 Create-react-app의 기본 설정은 아래와 같다.

즉, build, output, install 등 기본적으로 cli를 통해 다루는 명령어들을 Vercel이 수행하고 그 결과물에 대한 로직을 Default 값에 따라 자체적인 구조를 형성하는 것이다. 이는 흔히 볼 수 있는 클라우드 서비스에 대한 예시라고 할 수 있다.

그러니 나의 프로젝트의 경우 webpack의 빌드 결과물을 /dist 폴더에 형성되는데 Other Preset의 경우 Default 값이 다르고 내가 명시를 하지 않았으니 react build 결과물인 bundle.js를 불러오지 못해 빈 html 껍데기만 렌더링 되는 것이였다.

문제의 원인을 파악하였으니 Output Directory를 직접 설정하여 빌드 결과물 경로를 명시하자 문제는 해결되었다.

vercel.json

Vercel 배포과정에서 개발자가 웹 사이트가 아니라 vercel.json에 속성들을 나열하여 직접 커스텀할 수 있는 방법에 대해서도 새롭게 알게 되었다.

처음에 위의 과정에 대한 vercel 웹 사이트 설정을 직접적으로 발견하기 전에는 json 파일을 통해 먼저 문제를 해결하였으나 설정 페이지에 들어가니 경고문들이 많았고 추가로 빌드과정에서도 json 설정 파일에 명시된 속성들에대해 경고문이 많았다.

설정파일을 통해 기본적으로 배포되지만 사용자가 직접 설정까지 반영해줘야 일관성이 유지되는 상태를 확인하였고 웹 사이트가 보다 직관적이기에 큰 틀에 문제와 관련된 속성은 웹에서 컨트롤하고 찾기 힘든 경우 json 파일 설정을 통해 제어를 하는 방식으로 진행하면 좋을 것 같다고 생각하게 되었다.

Preview와 Production mode Domain의 분리

나의 프로젝트의 경우 main, develop, feature... 의 형태로 main은 프로덕션, develop은 개발모드의 큰 틀의 메인 브랜치를 형성하여 개발을 진행중 에 있다.

이러한 브랜치 구조에서 개발할 때 당장의 프로덕션으로 배포하기는 애매하지만 개발단계에서는 꼭 커밋을 반영해야하는 사소한 상황 속에서 결국 개발된 사항을 배포 사이트에 정확히 반영되는지 확인하기위해 별도의 최종 배포 이전의 배포 단계 사이트를 확립하거나, 아니면 무조건적으로 배포를 진행하여 배포상태를 확인하는 경우가 많았다.

하지만 아래와 같이 Preview 모드 브랜치와 도메인을 추가하여 최종 main 브랜치에 배포하기 이전에 실제 배포 사이트와 동일한 상태를 검수할 수 있는 편리한 기능을 알게되었다.

이를 통해 최종 배포 도메인과, 개발단계에서의 QA 배포 사이트를 보다 쉽게 구성할 수 있다는 점에서 너무 만족스러웠다.

회고

되돌아보면 이미 내가 알고 있는 일련의 배포과정인데 배포사이트의 명확한 사용방법에 대해 고민한적이 없었기에 이러한 문제를 파악하는데도 시간이 다소 걸렸다고 생각한다.

이러한 내용들도 내가 이번 프로젝트를 처음부터 시작한 취지인 기술이 사용되는 이유를 몸소 경험하기 위해 모든 불편함을 즐겨보자에서 시작하여 겪게된 내용이라고 생각한다.

결국 간단하게 프로젝트를 구성해주는 Create-react-app, Create-next-app이 아닌 간소화 상태로 최신 프론트 기술들을 커스텀하고 빌드하는 방법들을 통해 개발 및 배포의 과정에서 편리함 속에 가려진 기술의 원리에 보다 집중할 수 있었던 좋은 시간을 가졌다고 생각한다.