Vercel과 Netlify 자동 배포 완벽 가이드

GitHub와 연동하여 코드를 푸시하면 자동으로 배포되는 마법 같은 경험을 선사합니다. Vercel과 Netlify의 CLI 도구부터 프리뷰 배포, 환경별 분리까지 실무에서 바로 적용할 수 있는 자동 배포 전략을 다룹니다.

---

목차

1. Vercel_CLI_배포
2. Vercel_GitHub_Integration
3. Netlify_CLI_배포
4. Preview_배포_설정
5. 환경별_배포_분리
6. Deploy_Hooks_활용

---

1. Vercel CLI 배포

김개발 씨는 처음으로 개인 프로젝트를 만들었습니다. 로컬에서는 완벽하게 돌아가는데, 이것을 어떻게 세상에 공개할 수 있을까요?

FTP로 파일을 하나하나 올리던 시절은 이미 지났습니다. 선배가 알려준 Vercel CLI 명령어 하나로, 김개발 씨의 프로젝트는 단 몇 초 만에 전 세계에 공개되었습니다.

Vercel CLI는 터미널에서 단 한 줄의 명령어로 프로젝트를 배포할 수 있게 해주는 도구입니다. 마치 택배 기사님이 문 앞에서 물건을 가져가듯, 여러분의 코드를 받아 전 세계 CDN에 배포해줍니다.

복잡한 서버 설정 없이도 HTTPS, 도메인, 최적화까지 모두 자동으로 처리됩니다.

다음 코드를 살펴봅시다.

# Vercel CLI 전역 설치
npm install -g vercel

# 프로젝트 디렉토리에서 배포 실행
vercel

# 프로덕션 배포 (실서비스용)
vercel --prod

# 특정 환경 변수와 함께 배포
vercel --env API_KEY=secret123

# 빌드 로그 실시간 확인
vercel logs your-project.vercel.app

김개발 씨는 입사 첫 주에 사이드 프로젝트를 완성했습니다. React로 만든 포트폴리오 사이트였습니다.

로컬호스트에서는 완벽하게 동작하는데, 이것을 친구들에게 보여주려면 어떻게 해야 할까요? 예전 같았으면 호스팅 업체를 찾아 가입하고, FTP 클라이언트를 설치하고, 빌드된 파일을 하나하나 업로드했을 것입니다.

서버 설정도 해야 하고, SSL 인증서도 직접 발급받아야 했습니다. 생각만 해도 머리가 아픕니다.

그때 옆자리 박시니어 씨가 다가와 말했습니다. "Vercel CLI 써봤어요?

터미널에서 명령어 하나면 끝나요." Vercel CLI란 무엇일까요? 쉽게 말해 여러분의 코드를 클라우드로 올려주는 택배 서비스와 같습니다.

택배 기사님이 문 앞에서 물건을 수거해 전국 어디든 배송해주듯, Vercel CLI는 여러분의 프로젝트를 받아 전 세계 어디서든 접속할 수 있게 배포해줍니다. 먼저 npm install -g vercel 명령어로 CLI를 설치합니다.

전역 설치이므로 어느 프로젝트에서든 사용할 수 있습니다. 설치가 완료되면 프로젝트 폴더로 이동합니다.

이제 터미널에 vercel 이라고만 입력하면 됩니다. 처음 실행하면 로그인을 요청하고, 프로젝트 설정을 몇 가지 물어봅니다.

프레임워크를 자동으로 감지하니 대부분 엔터만 누르면 됩니다. 잠깐의 빌드 과정이 지나면 고유한 URL이 생성됩니다.

something-abc123.vercel.app 같은 형태입니다. 이 URL을 친구에게 보내면, 친구는 즉시 여러분의 사이트를 볼 수 있습니다.

실서비스용으로 배포하고 싶다면 vercel --prod 옵션을 사용합니다. 프로덕션 배포는 고정된 도메인에 연결되고, 더 강력한 캐싱이 적용됩니다.

미리보기용 배포와 프로덕션 배포가 분리되어 있어 안전합니다. 환경 변수가 필요한 경우도 간단합니다.

vercel --env 옵션으로 배포 시점에 환경 변수를 주입할 수 있습니다. 또는 Vercel 대시보드에서 미리 설정해두면 매번 입력할 필요가 없습니다.

김개발 씨는 명령어를 실행하고 30초도 채 되지 않아 자신의 포트폴리오가 인터넷에 공개된 것을 확인했습니다. HTTPS도 자동으로 적용되어 있었습니다.

"이게 이렇게 쉬운 거였어요?" 박시니어 씨는 미소를 지으며 고개를 끄덕였습니다.

실전 팁

💡 - vercel 명령어만 입력하면 미리보기 URL이 생성되고, --prod 옵션을 붙여야 실서비스 URL에 반영됩니다

• vercel.json 파일로 빌드 설정, 리다이렉트, 헤더 등을 세밀하게 제어할 수 있습니다
• vercel env pull 명령어로 대시보드의 환경 변수를 로컬 .env 파일로 가져올 수 있습니다

---

2. Vercel GitHub Integration

김개발 씨는 Vercel CLI가 편하다고 느꼈지만, 매번 배포 명령어를 치는 것이 귀찮아졌습니다. 코드를 수정할 때마다 git push도 하고 vercel도 해야 하니 두 번 일하는 기분이었습니다.

그런데 GitHub에 푸시만 하면 자동으로 배포되는 방법이 있다고 합니다.

Vercel GitHub Integration은 GitHub 저장소와 Vercel 프로젝트를 연결하여, 코드가 푸시될 때마다 자동으로 배포하는 기능입니다. 마치 자동문처럼, 여러분이 다가가기만 하면(푸시하면) 문이 알아서 열립니다(배포됩니다).

브랜치별 미리보기 URL까지 자동 생성됩니다.

다음 코드를 살펴봅시다.

# 1. GitHub에 저장소 생성 후 코드 푸시
git init
git add .
git commit -m "Initial commit"
git remote add origin https://github.com/username/my-project.git
git push -u origin main

# 2. Vercel 대시보드에서 Import Project 클릭
# 3. GitHub 저장소 선택 및 연결

# 이후 자동 배포 - 코드 수정 후 푸시만 하면 끝
git add .
git commit -m "Update homepage design"
git push origin main
# Vercel이 자동으로 감지하여 새 버전 배포

어느 날 김개발 씨는 하루에도 수십 번씩 수정사항을 배포하고 있었습니다. 버튼 색상 변경, 오타 수정, 새 기능 추가...

그때마다 vercel --prod 명령어를 입력해야 했습니다. 팀원이 늘어나면서 문제는 더 심각해졌습니다.

누가 언제 배포했는지 추적하기도 어려웠습니다. 박시니어 씨가 물었습니다.

"혹시 GitHub Integration 설정 안 했어요?" 김개발 씨는 고개를 갸웃거렸습니다. "그게 뭔데요?" GitHub Integration은 Vercel과 GitHub를 연결하는 다리입니다.

이 다리를 한 번 놓아두면, 이후로는 GitHub에 코드를 올리기만 해도 Vercel이 자동으로 이를 감지하고 배포합니다. 마치 자동문이 사람을 감지하고 열리듯이 말입니다.

설정 방법은 간단합니다. Vercel 대시보드에서 New Project를 클릭하고, Import Git Repository를 선택합니다.

GitHub 계정을 연결하면 여러분의 저장소 목록이 나타납니다. 배포하고 싶은 저장소를 선택하면 끝입니다.

이제부터 마법이 시작됩니다. 코드를 수정하고 git push만 하면, Vercel이 자동으로 새 버전을 빌드하고 배포합니다.

배포 상태는 GitHub의 커밋 옆에 초록색 체크 표시로 확인할 수 있습니다. 더 놀라운 것은 브랜치별 미리보기 배포입니다.

feature/new-button 같은 브랜치를 만들어 푸시하면, 해당 브랜치만의 고유 URL이 생성됩니다. 팀원들은 이 URL로 변경사항을 미리 확인하고 피드백을 줄 수 있습니다.

Pull Request를 열면 더욱 유용합니다. PR 페이지에 자동으로 미리보기 링크가 댓글로 달립니다.

코드 리뷰어는 코드만 보는 게 아니라, 실제 동작하는 사이트에서 변경사항을 직접 확인할 수 있습니다. main 브랜치에 머지되는 순간, 프로덕션 배포가 자동으로 실행됩니다.

별도의 배포 명령어를 칠 필요가 없습니다. 모든 것이 Git 워크플로우 안에서 자연스럽게 흘러갑니다.

김개발 씨는 설정을 마치고 테스트해보았습니다. 코드를 수정하고, 커밋하고, 푸시했습니다.

1분도 채 되지 않아 새 버전이 배포되었습니다. "이제 배포 생각 안 하고 코딩에만 집중할 수 있겠네요!" 팀의 생산성은 눈에 띄게 향상되었습니다.

실전 팁

💡 - vercel.json의 git.deploymentEnabled 옵션으로 특정 브랜치의 자동 배포를 비활성화할 수 있습니다

• GitHub Checks API를 통해 배포 실패 시 머지를 막는 보호 규칙을 설정할 수 있습니다
• 여러 저장소를 하나의 Vercel 팀에 연결하여 중앙에서 관리할 수 있습니다

---

3. Netlify CLI 배포

김개발 씨의 친구 이코딩 씨는 다른 회사에서 일하고 있었습니다. 어느 날 둘이 카페에서 만나 이야기를 나누던 중, 이코딩 씨가 말했습니다.

"우리 회사는 Netlify 써요. Vercel만큼 좋아요!" 김개발 씨는 궁금해졌습니다.

Netlify는 어떻게 다를까요?

Netlify CLI는 Vercel CLI와 유사하게 터미널에서 배포를 수행하는 도구입니다. Netlify는 특히 정적 사이트와 서버리스 함수에 강점이 있으며, 로컬 개발 환경에서 프로덕션과 동일한 환경을 미리 테스트할 수 있는 netlify dev 명령어가 큰 장점입니다.

다음 코드를 살펴봅시다.

# Netlify CLI 전역 설치
npm install -g netlify-cli

# Netlify 계정 로그인
netlify login

# 새 사이트 생성 및 연결
netlify init

# 로컬에서 프로덕션 환경 미리 테스트
netlify dev

# 미리보기 배포 (Draft URL 생성)
netlify deploy

# 프로덕션 배포
netlify deploy --prod

# 배포 상태 확인
netlify status

이코딩 씨는 Jamstack 아키텍처로 블로그를 운영하고 있었습니다. 정적 사이트 생성기로 만든 블로그를 어디에 배포할까 고민하다가, 선배의 추천으로 Netlify를 선택했다고 합니다.

Netlify는 Vercel과 함께 프론트엔드 배포의 양대 산맥입니다. 둘 다 훌륭한 서비스이지만, 각자의 색깔이 있습니다.

Netlify는 특히 정적 사이트 호스팅과 폼 처리, 그리고 로컬 개발 환경 지원에서 강점을 보입니다. 설치는 npm install -g netlify-cli 명령어로 시작합니다.

설치 후 netlify login을 실행하면 브라우저가 열리고, Netlify 계정으로 로그인할 수 있습니다. 인증이 완료되면 터미널에서 모든 작업이 가능해집니다.

프로젝트 폴더에서 netlify init을 실행하면 대화형으로 설정을 진행합니다. 새 사이트를 만들지, 기존 사이트에 연결할지 선택할 수 있습니다.

빌드 명령어와 배포 디렉토리도 이때 설정합니다. Netlify CLI의 숨은 보석은 netlify dev 명령어입니다.

이 명령어는 로컬에서 프로덕션과 거의 동일한 환경을 구축합니다. 환경 변수, 리다이렉트 규칙, 서버리스 함수까지 모두 로컬에서 테스트할 수 있습니다.

기존에는 "로컬에서는 되는데 배포하면 안 돼요" 같은 문제가 빈번했습니다. netlify dev를 사용하면 이런 환경 차이로 인한 버그를 사전에 잡을 수 있습니다.

마치 드레스 리허설처럼, 본 무대에 올리기 전에 모든 것을 점검하는 셈입니다. 배포는 두 단계로 나뉩니다.

netlify deploy는 미리보기 URL을 생성합니다. 이 URL은 임시적이며, 최종 확인용으로 사용합니다.

모든 것이 정상이면 netlify deploy --prod로 프로덕션에 반영합니다. 이코딩 씨는 블로그에 새 글을 쓸 때마다 이 과정을 거칩니다.

글을 작성하고, 빌드하고, 미리보기로 확인하고, 프로덕션에 배포합니다. 모든 과정이 터미널에서 간단하게 이루어집니다.

김개발 씨는 이야기를 듣고 고개를 끄덕였습니다. "Vercel이랑 비슷한 것 같으면서도 다르네요.

프로젝트 성격에 따라 선택하면 되겠네요."

실전 팁

💡 - netlify.toml 파일로 빌드 설정, 리다이렉트, 헤더, 플러그인 등을 선언적으로 관리할 수 있습니다

• netlify functions:serve로 서버리스 함수만 따로 로컬 테스트할 수 있습니다
• netlify open 명령어로 Netlify 대시보드를 브라우저에서 바로 열 수 있습니다

---

4. Preview 배포 설정

프로젝트가 커지면서 김개발 씨 팀에는 새로운 고민이 생겼습니다. 새 기능을 개발할 때마다 "이거 한번 확인해주세요"라며 화면 캡처를 공유하는 게 번거로웠습니다.

실제로 클릭해보고 동작을 확인하고 싶은데, 매번 로컬 환경을 공유하기도 어렵습니다.

Preview 배포는 프로덕션에 반영하기 전에 변경사항을 별도의 URL에서 미리 확인할 수 있게 해주는 기능입니다. 마치 영화 개봉 전 시사회처럼, 선택된 사람들에게 먼저 보여주고 피드백을 받을 수 있습니다.

Vercel과 Netlify 모두 브랜치 또는 PR 단위로 자동 Preview 배포를 지원합니다.

다음 코드를 살펴봅시다.

// vercel.json - Preview 배포 설정
{
  "git": {
    "deploymentEnabled": {
      "main": true,
      "preview": true
    }
  },
  "github": {
    "autoAlias": true,
    "silent": true
  }
}

// netlify.toml - Preview 배포 설정
// [context.deploy-preview]
//   command = "npm run build"
//   publish = "dist"
//
// [context.branch-deploy]
//   command = "npm run build:staging"

# PR 생성 시 자동으로 Preview URL 생성됨
# 예: my-project-abc123-teamname.vercel.app

김개발 씨 팀의 코드 리뷰 방식이 달라졌습니다. 예전에는 PR을 열면 코드만 보며 리뷰했습니다.

"이 버튼이 어떻게 생겼지?"라는 질문이 나오면, 개발자가 스크린샷을 찍어 올려야 했습니다. 인터랙션이 있는 기능이라면 영상까지 녹화해야 했습니다.

이제는 다릅니다. PR을 열면 몇 분 뒤 댓글이 자동으로 달립니다.

"Preview: https://my-feature-abc123.vercel.app" 리뷰어는 이 링크를 클릭하면 변경사항이 적용된 실제 사이트를 볼 수 있습니다. Preview 배포는 마치 영화의 시사회와 같습니다.

정식 개봉(프로덕션 배포) 전에 선택된 관객(팀원)들에게 먼저 보여주고 반응을 확인합니다. 문제가 있으면 수정하고, 호평이라면 자신 있게 개봉합니다.

Vercel에서는 GitHub Integration을 설정하면 Preview 배포가 자동으로 활성화됩니다. main이 아닌 다른 브랜치에 푸시하면, 해당 커밋에 대한 고유 URL이 생성됩니다.

이 URL은 해당 브랜치가 살아있는 동안 유지됩니다. PR을 열면 더 특별한 일이 일어납니다.

Vercel 봇이 PR에 댓글을 달아 Preview URL을 알려줍니다. PR이 업데이트될 때마다 새로운 배포가 진행되고, 링크는 항상 최신 상태를 가리킵니다.

Netlify도 비슷한 기능을 제공합니다. netlify.toml 파일에서 context.deploy-preview 섹션을 설정하면, PR에 대해 다른 빌드 명령어나 환경 변수를 적용할 수 있습니다.

테스트 데이터를 사용하거나, 디버그 모드를 켜는 등의 설정이 가능합니다. Preview 배포의 진정한 가치는 협업의 질을 높인다는 점입니다.

디자이너는 Figma와 실제 구현을 나란히 놓고 비교할 수 있습니다. 기획자는 의도한 대로 동작하는지 직접 확인할 수 있습니다.

QA 팀은 프로덕션 배포 전에 버그를 잡을 수 있습니다. 김개발 씨 팀의 PR 리뷰 시간은 절반으로 줄었습니다.

"어떻게 생겼어요?"라는 질문 대신 "왼쪽 여백이 조금 넓은 것 같아요"라는 구체적인 피드백이 오가기 시작했습니다. 커뮤니케이션의 질이 높아지니 제품의 질도 함께 높아졌습니다.

실전 팁

💡 - Preview URL에 접근 제한을 걸어 외부 유출을 방지할 수 있습니다 (Vercel Password Protection, Netlify Identity)

• PR 댓글에 자동으로 Lighthouse 점수를 표시하는 기능도 있습니다
• Preview 환경에서만 동작하는 디버그 도구를 환경 변수로 제어할 수 있습니다

---

5. 환경별 배포 분리

"개발 서버에서는 잘 되는데 운영 서버에서 안 돼요!" 김개발 씨가 다급하게 외쳤습니다. API 엔드포인트가 달라서 생긴 문제였습니다.

개발 환경과 운영 환경이 뒤섞이면서 혼란이 생겼습니다. 환경별로 설정을 분리하는 체계적인 방법이 필요했습니다.

환경별 배포 분리는 개발(development), 스테이징(staging), 운영(production) 환경을 명확히 구분하여 각각 다른 설정으로 배포하는 전략입니다. 마치 요리사가 레시피를 테스트할 때 집에서 먼저 만들어보고, 소수 손님에게 맛보게 한 뒤, 최종적으로 메뉴에 올리는 것과 같습니다.

다음 코드를 살펴봅시다.

// Vercel 환경 변수 설정 (vercel.json)
{
  "env": {
    "API_URL": "@api-url"
  }
}

// Vercel 대시보드에서 환경별 값 설정
// Production: https://api.myapp.com
// Preview: https://staging-api.myapp.com
// Development: http://localhost:3001

// netlify.toml - 환경별 빌드 설정
// [context.production]
//   environment = { API_URL = "https://api.myapp.com" }
//
// [context.deploy-preview]
//   environment = { API_URL = "https://staging-api.myapp.com" }
//
// [context.branch-deploy.staging]
//   environment = { API_URL = "https://staging-api.myapp.com" }

사고는 예고 없이 찾아왔습니다. 김개발 씨가 새 기능을 배포한 직후, 고객 문의가 폭주했습니다.

결제 시스템이 작동하지 않는다는 것이었습니다. 원인은 간단했습니다.

개발용 결제 API 주소가 운영 서버에 배포된 것입니다. "환경 변수를 잘못 설정했어요..." 김개발 씨는 고개를 떨궜습니다.

박시니어 씨가 말했습니다. "이참에 환경 분리를 제대로 해봐요.

다시는 이런 일이 없도록요." 환경 분리란 무엇일까요? 마치 요리사가 새 메뉴를 개발할 때의 과정과 같습니다.

먼저 집 주방에서 레시피를 실험합니다. 괜찮으면 단골손님 몇 명에게 맛보게 합니다.

반응이 좋으면 정식 메뉴로 등록합니다. 개발, 스테이징, 운영 환경이 바로 이 세 단계에 해당합니다.

Vercel에서는 환경 변수를 세 가지 범위로 설정할 수 있습니다. Production은 main 브랜치가 배포되는 실서비스 환경입니다.

Preview는 PR이나 다른 브랜치의 미리보기 환경입니다. Development는 로컬 개발 환경입니다.

같은 변수 이름이라도 환경에 따라 다른 값을 가질 수 있습니다. API_URL 변수를 예로 들면, 운영에서는 실제 API 서버를, 미리보기에서는 스테이징 서버를, 로컬에서는 목 서버를 가리킬 수 있습니다.

Netlify는 netlify.toml 파일에서 환경별 설정을 선언적으로 관리합니다. context.production, context.deploy-preview, context.branch-deploy 등으로 상황별 빌드 명령어와 환경 변수를 분리할 수 있습니다.

특정 브랜치에 대해 더 세밀한 제어도 가능합니다. staging 브랜치만 따로 설정하여, QA 팀이 테스트하는 전용 환경을 구축할 수 있습니다.

이 환경에는 테스트 데이터와 디버그 도구가 활성화되어 있습니다. 환경 분리의 또 다른 이점은 비밀 정보 보호입니다.

API 키나 데이터베이스 비밀번호 같은 민감한 정보는 각 환경에 맞게 다른 값을 사용합니다. Preview 환경에서 실제 결제가 일어나거나, 실제 사용자 데이터에 접근하는 일을 방지할 수 있습니다.

김개발 씨 팀은 환경 분리를 도입한 뒤, 비슷한 사고가 사라졌습니다. 개발자들은 안심하고 새 기능을 실험할 수 있게 되었습니다.

실수하더라도 Preview 환경에서 걸러지니까요.

실전 팁

💡 - 중요한 시크릿은 환경 변수 UI에서만 설정하고, 절대 코드에 하드코딩하지 마세요

• 환경별로 다른 서드파티 서비스 계정(Stripe 테스트 모드 등)을 사용하는 것이 안전합니다
• vercel env pull 또는 netlify env:import로 로컬 개발 환경의 환경 변수를 동기화할 수 있습니다

---

6. Deploy Hooks 활용

김개발 씨는 헤드리스 CMS를 사용하는 프로젝트를 맡았습니다. 콘텐츠 담당자가 새 글을 발행할 때마다 사이트를 재빌드해야 했습니다.

그런데 콘텐츠 담당자는 개발 지식이 없어서 git push를 할 수 없습니다. 어떻게 하면 좋을까요?

Deploy Hooks는 특정 URL을 호출하면 자동으로 배포를 트리거하는 웹훅입니다. 마치 초인종을 누르면 문이 열리듯, 이 URL에 요청을 보내면 새 배포가 시작됩니다.

외부 시스템(CMS, 스케줄러, 다른 서비스)에서 배포를 자동화할 때 유용합니다.

다음 코드를 살펴봅시다.

# Vercel Deploy Hook 생성 (대시보드에서)
# Settings > Git > Deploy Hooks > Create Hook
# 생성된 URL 예시: https://api.vercel.com/v1/integrations/deploy/prj_xxx/xxx

# curl로 배포 트리거
curl -X POST https://api.vercel.com/v1/integrations/deploy/prj_xxx/xxx

# Netlify Build Hook 생성 (대시보드에서)
# Site settings > Build & deploy > Build hooks > Add build hook
# 생성된 URL 예시: https://api.netlify.com/build_hooks/xxx

# GitHub Actions에서 Deploy Hook 호출
# name: Trigger Deploy
# on:
#   schedule:
#     - cron: '0 0 * * *'
# jobs:
#   deploy:
#     runs-on: ubuntu-latest
#     steps:
#       - run: curl -X POST ${{ secrets.DEPLOY_HOOK_URL }}

콘텐츠 마케팅 팀의 박마케팅 씨가 김개발 씨를 찾아왔습니다. "블로그에 새 글을 올렸는데, 사이트에 안 나타나요.

개발팀에 매번 부탁해야 하나요?" 정적 사이트 생성 방식이라 콘텐츠가 변경되면 사이트를 다시 빌드해야 했습니다. 김개발 씨는 고민에 빠졌습니다.

박마케팅 씨에게 git 사용법을 알려줄 수도 있지만, 그건 너무 번거롭습니다. 더 쉬운 방법이 없을까요?

Deploy Hook이 바로 그 해답입니다. Deploy Hook은 특별한 URL입니다.

이 URL에 HTTP 요청을 보내면, 마치 git push를 한 것처럼 새 배포가 시작됩니다. 초인종에 비유할 수 있습니다.

초인종을 누르면 문이 열리듯, 이 URL을 호출하면 배포가 시작됩니다. Vercel 대시보드에서 Deploy Hook을 생성하면 고유한 URL이 주어집니다.

이 URL은 비밀로 관리해야 합니다. 누구나 이 URL을 알면 배포를 트리거할 수 있으니까요.

환경 변수나 시크릿 매니저에 저장하는 것이 좋습니다. 가장 흔한 활용 사례는 헤드리스 CMS 연동입니다.

Contentful, Sanity, Strapi 같은 CMS에서 콘텐츠가 발행되면, 웹훅 설정을 통해 Deploy Hook을 호출합니다. 콘텐츠 담당자는 CMS에서 '발행' 버튼만 누르면, 몇 분 뒤 사이트에 새 콘텐츠가 반영됩니다.

스케줄 배포도 가능합니다. GitHub Actions의 schedule 트리거나 cron 서비스를 이용해, 매일 자정에 Deploy Hook을 호출할 수 있습니다.

주기적으로 외부 데이터를 가져와야 하는 사이트에 유용합니다. 여러 서비스가 연결된 복잡한 시스템에서도 Deploy Hook은 빛을 발합니다.

백엔드 API가 업데이트되면 프론트엔드도 재배포해야 하는 경우, 백엔드 CI/CD 파이프라인 마지막에 프론트엔드 Deploy Hook을 호출하면 됩니다. Netlify에서는 이를 Build Hook이라고 부릅니다.

동작 방식은 동일합니다. Site settings에서 생성하면 URL이 주어지고, 이 URL을 호출하면 빌드가 시작됩니다.

김개발 씨는 CMS에 Deploy Hook을 연결했습니다. 박마케팅 씨는 이제 글을 발행하기만 하면 됩니다.

5분 뒤면 블로그에 새 글이 나타납니다. "개발팀 도움 없이 바로 반영되다니, 정말 편해졌어요!" 박마케팅 씨의 얼굴에 미소가 번졌습니다.

실전 팁

💡 - Deploy Hook URL은 절대로 공개 저장소에 커밋하지 마세요. 누구나 배포를 트리거할 수 있습니다

• 같은 시간에 여러 번 호출해도 Vercel/Netlify가 중복 빌드를 방지해줍니다
• Hook별로 다른 브랜치를 지정하여, 특정 이벤트에 특정 브랜치만 배포하도록 설정할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!