기획자를 위한 깃허브 실전 ④CI/CD
브랜치부터 자동배포까지 — Jenkins 없이도 GitHub로 충분한 CI/CD 대기업에서는 여전히 Jenkins 같은 전문 자동배포 도구를 사용합니다.하지만 개인 프로젝트나 소규모 팀이라면,비용과 관리 부담이 큰 Jenkins 대신 GitHub 하나로도 충분히 CI/CD 환경을 구현할 수 있습니다.이 글은 기획자 시선에서 “깃허브 브랜치가 어떻게 자동 배포로 이어지는지”를 설명합니다. CI/CD가 뭔지, 그리고 왜 필요한지 CI/CD는 영어로 Continuous Integration / Continuous Deployment를 … 더 읽기
브랜치부터 자동배포까지 — Jenkins 없이도 GitHub로 충분한 CI/CD
대기업에서는 여전히 Jenkins 같은 전문 자동배포 도구를 사용합니다. 하지만 개인 프로젝트나 소규모 팀이라면, 비용과 관리 부담이 큰 Jenkins 대신 GitHub 하나로도 충분히 CI/CD 환경을 구현할 수 있습니다. 이 글은 기획자 시선에서 “깃허브 브랜치가 어떻게 자동 배포로 이어지는지”를 설명합니다.
CI/CD가 뭔지, 그리고 왜 필요한지
CI/CD는 영어로 Continuous Integration / Continuous Deployment를 줄인 말입니다. 말이 복잡할 뿐, 실제 의미는 단순합니다. 코드를 수정하고 저장하면, 테스트를 거쳐 자동으로 배포되게 만드는 과정입니다.
CI는 여러 개발자가 만든 코드를 하나로 모으는 “자동 통합”이고, CD는 그 코드가 수정될 때마다 자동으로 웹사이트나 앱에 반영되게 하는 “자동 배포”입니다. 결국 기획자 입장에서는 “새 버전이 올라갔을 때, 테스트 서버나 운영 사이트에 언제 자동 반영되는가”를 결정하는 흐름이 바로 CI/CD입니다.
| 구분 | 의미 | 쉽게 말하면 |
|---|---|---|
| CI (Continuous Integration) | 개발자들이 수정한 코드가 깃허브에 통합되는 과정 | 여러 버전을 하나로 합치기 |
| CD (Continuous Deployment) | 통합된 코드를 자동으로 웹에 반영하는 과정 | 수정하면 자동 배포되게 하기 |
즉,
깃허브에 코드를 올리는 순간 → 자동으로 웹페이지가 갱신되는 구조가 CI/CD입니다.
Jenkins는 왜 여전히 쓰이지만, GitHub로 충분한가
Jenkins는 지금도 많은 기업에서 사용됩니다. 보안이 중요한 사내 시스템이나, 내부망 환경에서는 여전히 표준이죠. 서버를 직접 운영하면서 세밀한 제어가 필요한 경우 Jenkins만큼 강력한 도구는 없습니다.
하지만 개인이나 소규모 프로젝트에서는 이야기가 다릅니다. 서버 유지비, 보안 설정, 관리 인력 등의 부담이 크기 때문에 “코드 한 줄 수정할 때마다 Jenkins로 배포하기”는 오히려 비효율적입니다. 이럴 땐 GitHub이 자체 제공하는 GitHub Actions 기능을 활용할 수 있습니다. 깃허브 안에서 브랜치를 푸시하면 자동으로 사이트가 빌드되고 배포되므로, 서버를 따로 세팅할 필요가 없습니다.
GitHub에서 CI/CD가 돌아가는 흐름
GitHub의 CI/CD는 브랜치와 함께 작동합니다. 기획자에게 익숙한 ‘버전관리’ 개념과 비슷하게 생각하면 됩니다. main 브랜치는 운영 버전이고, dev나 feature 브랜치는 테스트용입니다.
작업자가 수정한 내용을 브랜치에 커밋하고 푸시하면, GitHub Actions가 그 변화를 감지합니다. 이후 자동으로 코드를 빌드하고, GitHub Pages나 Netlify, Vercel 같은 플랫폼으로 배포합니다.
즉, 사람이 서버에 접속해서 파일을 올릴 필요가 전혀 없습니다. 커밋 한 번으로 배포가 끝나죠.
| 단계 | 설명 | 기획자 관점 |
|---|---|---|
| ① 브랜치 생성 | 수정용 작업 공간 만들기 | 실험본 제작 |
| ② 커밋 & 푸시 | 수정 내용 깃허브에 올리기 | “저장 및 업로드” 단계 |
| ③ GitHub Actions 작동 | 푸시 시 자동 실행 | 자동 검수 & 배포 시작 |
| ④ 자동 배포 완료 | dev/test 서버 혹은 개인 사이트 반영 | 수정본 즉시 확인 가능 |
개인도 가능한 GitHub CI/CD 세팅 예시
기획자나 디자이너도 정적 페이지(HTML, React, Next.js 등) 기반이라면 아래 도구만으로 완전한 CI/CD를 경험할 수 있습니다.
| 플랫폼 | 역할 | 특징 |
|---|---|---|
| GitHub Pages | 깃허브가 직접 호스팅하는 무료 웹공간 | HTML·React 사이트 자동 반영 가능 |
| Netlify / Vercel | 깃허브와 연동되는 자동배포 플랫폼 | 브랜치별 URL 생성 가능 (main, dev) |
| GitHub Actions | 배포 자동화 워크플로우 | 무료 플랜에서도 사용 가능 |
예를 들어,
main 브랜치는 운영용 주소
dev 브랜치는 테스트용 주소로 설정할 수 있습니다.
- main 브랜치 → https://yourname.github.io
- dev 브랜치 → https://dev–yourname.vercel.app
실제 동작 예시로 이해하기
- VS Code에서 웹페이지 문구를 수정한다.
- 터미널에서
git commit과git push명령을 입력한다. (!! 꼭 터미널을 이용~) - GitHub가 자동으로 코드를 감지하고 배포를 시작한다.
- 몇 분 뒤 dev 브랜치용 테스트 페이지가 새로 고쳐진다.
이 모든 과정은 사람이 서버에 접속하거나 FTP로 파일을 전송하지 않아도 됩니다. 기획자 입장에서 보면 “디자인 수정이 반영된 테스트 페이지를 기다리는 시간”이 훨씬 짧아지는 셈입니다.
GitHub CI/CD의 장점 요약
- 별도 서버 설치나 유지비용이 없다.
- 브랜치별로 배포 버전을 구분할 수 있다. (main, dev, feature 등)
- Netlify나 Vercel과 연동해 URL 자동생성 가능.
- Jenkins 대비 설정이 단순하고 직관적이다.
- 기획자나 디자이너도 GitHub Actions 설정 파일만 있으면 직접 테스트 가능하다.
기획자가 알아두면 좋은 포인트
- CI/CD는 개발만의 영역이 아니다. 수정이 반영되는 시점과 테스트 경로를 이해하는 건 기획에도 중요하다.
- Jenkins는 여전히 대규모 시스템에서 쓰이지만, 개인 프로젝트 수준에서는 GitHub만으로 충분하다.
- 브랜치 관리와 자동배포 개념을 알면 “어떤 버전이 어느 환경에 반영되는지”를 스스로 판단할 수 있다.
CI/CD는 결국 “코드가 수정될 때마다 자동으로 반영되게 하는 문화”입니다.
대기업은 여전히 Jenkins를 통해 이 과정을 세밀히 제어하지만, 개인이나 소규모 팀이라면 GitHub Actions로도 충분히 유사한 경험을 할 수 있습니다. (보안승인절차 등은 대체 어렵습니다만..) 기획자가 이 개념을 이해하면, 디자인 변경이나 정책 수정이 언제 어디에 반영되는지를 스스로 추적할 수 있게 됩니다. 이건 단순히 기술을 아는 걸 넘어서, 기획과 개발의 언어가 통하는 첫걸음이기도 합니다.