Vercel 배포 검사 기능 공부 정리 | 린트가 배포 흐름 안으로 들어오다

Vercel changelog를 보다가 “Native Deployment Checks” 출시 소식을 접했다. 처음엔 제목만 보고 넘기려 했는데, “빌드와 병렬로 린트·타입체크가 돌아간다”는 문구에서 잠깐 멈췄다.

기존에도 GitHub Actions로 린트를 돌리는 방식은 있었는데, 이게 뭐가 다른 건지 궁금해져서 좀 읽어봤다.

1️⃣ 이게 뭐냐?

기존 방식에서 Vercel 자체 배포 파이프라인에 린트·타입체크 같은 검사를 직접 추가하는 방법은 제한적이었다. GitHub나 마켓플레이스 통합을 거치거나, 별도 CI 워크플로우를 따로 세팅해야 했다.

이번 기능은 프로젝트의 Build and Deployment 설정에서 체크를 추가하면, 배포가 트리거될 때마다 package.json에 있는 스크립트가 빌드와 병렬로 실행되는 방식이다. lint나 type-check 같은 스크립트가 이미 있으면 그걸 그냥 연결해주는 개념이라, 새로 뭔가를 만들 필요가 없다.

각 체크는 “필수”로 지정할 수 있어서, 실패하면 프로덕션 배포 자체를 막아둘 수 있다. 환경별로도 설정이 가능해서 프리뷰에만 돌리거나 프로덕션에만 걸어두는 방식도 된다.

추가로, PR에 달린 배포에서 체크가 실패하면 Vercel Agent가 원인을 조사하고 수정안을 제시한다고 한다. 제안된 수정을 리뷰하고 머지하는 흐름이다.

2️⃣ 내가 든 생각

“GitHub Actions 대체인가?” 싶었는데, 읽다 보니 그 방향은 아닌 것 같다. 외부 CI를 없애는 게 목적이라기보다, Vercel 배포 흐름 안에서 이미 쓰던 스크립트를 연결할 수 있다는 쪽에 가까운 것 같다.

👉🏻 핵심은 “YAML 파일 새로 안 만들어도 된다”는 부분이었다. package.json에 이미 린트 스크립트가 있으면 그게 그대로 배포 파이프라인에 붙는 방식이라, 진입 장벽이 꽤 낮아 보였다.

디자이너 출신으로 개발을 배우는 입장에서 CI 설정은 항상 좀 까다롭게 느껴졌다. 작은 사이드 프로젝트에 GitHub Actions까지 붙이기엔 손이 많이 가고, 그렇다고 아무 검사 없이 배포하다 보면 나중에 타입 에러가 터지는 경우가 있었다. 이 기능이 그 사이를 채워줄 수 있는 건지 궁금해졌다.

💡 여기서 드는 질문? Vercel Agent가 체크 실패를 분석하고 수정안을 제시한다는 게, 실제로 어떤 수준일까? 타입 에러 원인을 정확히 짚어주는 건지, 아니면 로그를 요약해주는 수준인지 써봐야 알 것 같다.

3️⃣ 앞으로 어떻게 쓸까?

개인 프로젝트 기준으로는 한번 붙여볼 것 같다. tsc --noEmit 스크립트를 package.json에 이미 넣어두는 편이라, 추가 설정이 크지 않을 것 같아서다.

필수 체크로 지정해두면 타입 에러가 있을 때 프로덕션 배포가 막히니까, 실수로 배포 버튼을 눌렀을 때 안전망이 생기는 셈이다. 써봐야 알겠지만, 작은 프로젝트라면 별도 CI 없이 이걸로 충분할 수 있겠다는 생각이 든다.

⭐️ 마지막으로, 프론트엔드 학습자 입장에서 공부하며 느낀 점

정리해보니 중요한 건 새로운 개념이 아니라 “어디에서 하냐”의 문제였다. 린트·타입체크는 원래 하던 거고, 배포 전에 돌려야 한다는 것도 알고 있었다. 공부 끝에 남은 건 “그냥 안 하게 되는 것”을 막아주는 장치가 어디에 있냐는 한 줄이었다.

---

참고 원문: Native Deployment Checks are now available