[Next.js] Next.js 프로젝트를 Vercel에 배포하기: 커스텀 도메인 설정부터 Production 배포까지

 
오늘은 Vercel에 Next.js를 배포한 경험에서 알게 된 것들 적어보려한다. Vercel 배포를 검색했을 때 많은 자료들이 있어서 금방 끝낼 줄 알았는데 시간이 꽤 걸렸다.
 
그래도 깔끔하게 해결하고 잠들어서 좋다. (현재시각 오전 2시 54분..)
 
 

Hobby에서 Pro로 변경

---

지금 참여하는 프로젝트는 Oraganization인데, Vercel에서 Github Organization에서 프로젝트를 운영할 경우 Pro로 전환해야 한다. Pro 버전은 2주 간 무료로 이용할 수 있고, 이후에는 월마다 $20 씩 지불해야 한다.
 
우회해서 사용하는 방법도 있긴 한데 별로 내키지 않아서 유료 버전을 사용했다.
 
 

 
 
 

도메인 등록

---

도메인 구입 후, vercel에 등록된 도메인을 구매한 도메인으로 변경했다.
 
방법을 간략하게 적어보자면,
1. 도메인 설정 페이지에서 등록한 도메인을 입력하고 Add 버튼을 클릭해서 도메인을 등록하면 된다.
 

 
 
 
2. 이후에 추천 항목을 클릭 후 Add 버튼을 누른다.

모자이크로 가린 것은 도메인 주소이다.

 
 
3. 그럼 이렇게 CNAME과 A Record가 나타난다.

 
 
 
이후 도메인을 구입하신 백엔드 분께 A Record와 CNAME을 등록해달라고 말씀드렸다.
 
그럼 아래처럼 AWS에 등록을 해주신다! 모자이크가 덕지덕지지만.. 첫번째와 마지막 라인에 A레코드와 CNAME이 등록된 것을 확인할 수 있다.

 
 
 
AWS에 등록 후, Vercel에서도 이렇게 2개의 레코드가 생성된 것을 확인할 수 있다.

 
이번에 백엔드 분 께서 서브 도메인을 구매하기 위해 고대디, Router 53 등 다양한 사이트를 이용하시는 것을 간접적으로 알게되었다.
 
음.. 한 가지 느꼈던 점은, 다른 FE 개발자 분께서 서버 쪽 관련해서 중간에서 BE 개발자 분을 도와드리고 의견내시는 모습을 보면서 BE 개발자 분들과 더 원활하게 소통하려면 BE 지식들도 어느정도 아는 것이 중요하다고 느꼈다.
 
그래서 앞으로 회의에 참여할 때는 BE 분들께서 말씀하시는 것들을 주의 깊게 듣고 (지금까지 흘려들었다는 것은 아닙니다❤️) 관련 지식을 조금씩 알아가야 겠다고 생각했다.
 
일단 내 영역과 BE 영역이 맞닿아 있는 부분들을 하나씩 알아가면 좋을 것 같다는 생각에, 오늘은 커스텀 도메인을 연동하고자 알게 된 CNAME과 A 레코드에 대해 알아보려 한다.
 
 
 

CNAME과 A 레코드

---

앞서 말했듯이 도메인 연동을 위해서는 CNAME과 A Record를 등록해야 한다.
그렇다면 CNAME과 A Record는 무엇일까?
 
찾아보니 A Record와 CNAME은 DNS Record type 중 하나라고 한다.  A Record와 CNAME를 이해하기 전에 DNS Record type부터 알아야 하나보다. 그렇다면 DNS Record type은 또 뭘까?
 

DNS(Domain Name System)

인터넷을 구성하고 있는 IP 주소는 192.168.0.1 같이 숫자로 구성된다. 이런 숫자는 아무런 의미도 없기 때문에 외우기 힘들다는 단점이 있다.
 
따라서 naver.com 같은 문자열로 서버 주소를 표현하게 되었는데, 실제 컴퓨터 통신에서는 naver.com이라는 문자열 주소를 192.168.0.1 같은 IPv4 주소로 변환해주는 서비스가 필요하다. 이런 서비스를 DNS 서비스라고 한다. 
 
요약하자면 DNS는 naver.com과 같은 문자열 주소를 IP 주소로 해석해주는 네트워크 서비스를 말한다.
DNS 서버에는 아래와 같이 도메인 주소와 IP 주소의 쌍(Pair)이 저장된다.

naver.com	192.168.0.1
google.com	172,17.0.1
plusblog.co.kr	10.234.34.12

 
위 테이블에서 하나의 행을 'Record'라고 하며, 저장되는 타입에 따라 A Record와 CNAME으로 구분할 수 있다.
 
DNS에 대해 이해했으니 이제 정말로 궁금했던 A Record와 CNAME에 대해 알아보자.
 
 

A Record

간단하게 도메인 주소와 서버의 IP 주소를 직접 매핑시키는 방법이다. 사용자가 A Record에 해당하는 도메인 주소에 대한 해석을 요청하면 DNS 서버는 IP 주소를 리턴해준다.
 
 

CNAME(Canonical Name)

도메인 주소를 또 다른 도메인 주소로 매핑하는 방법이다.

naver.com	192.168.0.1
codingtoddlerr.tistory.com	172.17.0.1
coding.toddlerr.tistory.com	codingtoddlerr.tistory.com

위와 같은 정보가 DNS 서버에 저장되어 있다고하자. 사용자가 codingtoddlerr.tistory.com 주소를 요청하면 서버는 172.17.0.1 를 응답한다. A 레코드 정보의 해석이다. 
 
만약 coding.toddlerr.tistory.com을 요청하면 DNS 서버는 codingtoddlerr.tisory.com을 리턴하고, 사용자는 다시 codingtoddlerr.tistory.com 정보를 DNS 서버에 요청한다. DNS 서버는 이제 172.17.0.1 을 리턴하고 사용자는 IP 주소를 사용하게 된다. 
 
 

A Record vs CNAME

둘의 장단점은 뭘까?
 
A Record는 IP 주소가 변경되는 경우, 매핑되어 있는 모든 A 레코드를 찾아서 변경해야 하는 단점이 있다. 하지만 한 번의 요청으로 서버의 IP 주소를 알 수 있는 장점이 있다.
 
CNAME은 IP 주소가 자주 변경되는 환경에서 유연하게 대응할 수 있다. 하지만 실제 IP 주소를 얻을 때 까지 여러번 DNS 정보를 요청해야해서 상황에 따라서는 성능 저하를 유발 할 수 있다.
 

공부할 때 제일 재밌다고 느껴지는 것 중 하나는 무언가 하나를 알기 위해서는 또 다른 하나를 알아야 하는 과정이 필요한데, 공부를 끝내고 보면 결국 A 뿐 만 아니라 A에 연관된 B, C, D까지 알게되어서 줄줄이 소세지처럼 딸려나오는 것 이다.

왜 좋냐면.. 또 다른 영역을 공부할 때 A에서 배웠던 B가 등장하기도 하고 C가 등장하는 경우가 종종 있는데, 이럴때 이전에 공부해서 이미 아는 지식이니까, 이 영역을 더 잘 이해할 수 있게 된다는 자체가 즐겁다.

그래서 갑자기 든 생각은, 어쩌면 이 연결고리(?)들이 이어지는 순간을 경험하기 위해서 공부하는 것일지도 모르는 것 같다는 생각이 들었다.

 
 
 

Production 자동 배포

---

이제 Production 레벨에서 자동으로 배포가 되게 해보자!
 
Git 탭으로 접속하면 Connected Git Repository 섹션이 바로 보인다. 여기서 Github 프로젝트를 연동해주면 된다.

 
여기서 Pull Request Comments 버튼을 선택하면 Vercel bot이 Pull Request에 대한 자동 코멘트를 생성한다.
 
PR 이 생성되거나 업데이트 될 때 마다 아래 사진 처럼 Vercel이 자동으로 Preview 배포 URL를 코멘트로 달아주는데 나는 Github Actions로 이미 똑같은 기능을 구현했기 때문에 불필요하다고 생각되어 버튼을 Disabled 했다.
 
시간적 여유가 되지 않는다면 Github Actions로 번거롭게 workflow를 짜기보다는, 이런 기능들을 적극적으로 이용해보면 좋을 것 같다.

 
 
 
그리고 최하단으로 내려와서 Automatic으로 설정되어 있는지 확인하면 된다. 만약 Github Actions로 production.yaml 파일을 생성했다면(=Github Actions로 배포하는 것을 선택한 경우) Automatic이 아닌 Don't build anything로 설정해야 한다.

 
 
 
그리고 혹시 Vite에서 Next.js에서 마이그레이션을 했다면.. General 탭에서 Framework가 Next.js로 설정되어있는지 꼭 확인을 해주시길... 나는 빌드 에러가 계속 뜨길래 동태눈으로 스크롤만 계속 하다가 갑자기 눈에 띈 Vite에 정신을 잃을 뻔 했다..
 
당신만은 정신을 잃지 않길..

 
 
 
대환장 moment를 하나 더 말해보자면 코드 push 마다 자동 배포가 되도록 하기 위해 Github Repository를 연동하려고 했는데, Organization Repository는 hobby가 아닌 team으로 등록해야 하기 때문에 새 team을 생성했다.
 
(참고로 team으로 등록하기 위해서는 아래 화면에서 Create Team을 눌러서 새로운 팀을 등록해야 한다.)
 

 
 
 
 
그리고 생성된 team에 도메인 다시 연결하고, 이것저것 설정을 마쳤는데(위에서 진행했던 순서 그대로) 계속 빌드 에러가 떴다.

아진짜 쫌

 
Github 에서 환경변수를 다시 등록해야 하나 싶어서 Token도 다시 받아와서 등록하고 다른 환경변수들도 다시 등록했는데 계속 에러가 발생했다.
 
근데 에러를 잘 읽어보니까 Project not found..?
음? 프로젝트를 찾을 수 없다는 말이 이해가 안되었다.
 
그래서 vercel 계정에 다시 로그인하고

vercel login

 
 
vercel 프로젝트를 다시 생성해보았는데

vercel link

 
 
아까 Organization Repository를 등록하기 위해 생성한 team 프로젝트가 보였다....

맨 아래 줄에 모자이크 처리된 게 pro 버전으로 생성했던 프로젝트이다.

 
부연설명을 덧붙이자면 vercel link 명령어로 프로젝트를 생성하면 .vercel 폴더가 생성되고 하위에 프로젝트 고유의 projectId와 orgId가 생성된다.
 
그런데 나는 team으로 변경하기 전에 hobby에서 프로젝트를 생성하고 이 프로젝트의 projectId와 orgId를 환경변수로 등록했었는데, 이 경우에는 당연히 team에 등록한 프로젝트와 다르기 때문에 Project not found 에러가 떴던 것이었다.
 
그래서 hobby의 .vercel 폴더를 삭제하고 다시 설치했다. 설치 이후 생성된 projectId와 orgId를 환경변수로 등록해주니 배포가 성공적으로 되었다🥹
 
오늘은 Vercel에 커스텀 도메인을 등록하고 자동 배포를 하기 위한 여러 설정들을 하면서 새로운 것들을 알게되었다. Github Actions로 Vercel 자동배포를 구현했을 때 느꼈던 것 처럼, 에러를 해결해 나가는 과정에서 실력이 향상되는 것 같다.
 
코드 작성를 짜는게 아닌, 도메인 등록과 배포 과정은 상대적으로 생소한 영역이었기에, 이번 경험은 도전적이었다고 생각한다. 중간에 삽질도 했지만 잘 마무리 지어서 뿌듯하다 ㅎㅎ
 
글 다 쓰니까 너무 허기지다 뭐라도 먹어야겠따
 

---

 
 
참고
https://coding-start.tistory.com/348
https://dev.plusblog.co.kr/30

https://velog.io/@jangsebari/route53-%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-vercel-%EB%8F%84%EB%A9%94%EC%9D%B8-%EB%B3%80%EA%B2%BD