01 / 15
SESSION 36 · Part 7 클라우드/배포

CI / CD

push 한 번으로 테스트 · 빌드 · 배포까지 자동

02 / 15
🎯

이 세션에서
배우는 것

🔁
CI vs CD
지속적 통합과 지속적 배포의 차이를 안다
⚙️
워크플로 구조
GitHub Actions의 YAML 구조를 이해한다
🚚
파이프라인 단계
Build → Test → Deploy 순서를 말할 수 있다
03 / 15
💭

CI/CD인가?

배포를 사람이 매번 하면 실수가 생긴다.
"나는 로컬에선 잘 됐는데"라는 말은 보통 테스트를 건너뛴 흔적이다.

CI/CD는 코드를 push하면 자동으로
테스트 → 빌드 → 배포까지 실행한다. 사람은 코드 리뷰에만 집중.

04 / 15

CI vs CD

이름이 비슷하지만 역할이 다르다.

🔧
CI · Continuous Integration
코드를 push할 때마다 자동 테스트와 빌드 실행.
통합 오류를 빠르게 발견.
팀원의 변경과 충돌하지 않는지 확인.
🚀
CD · Continuous Deployment
CI를 통과한 코드를 자동으로 프로덕션에 배포.
main 브랜치에 merge되면 수 분 내 서비스 반영.
수동 승인을 두는 Continuous Delivery 변형도 있음.
05 / 15
🔧

CI(지속적 통합) —
더 깊게 이해하기

CI는 단순히 테스트 실행이 아니다. 여러 개발자가 동시에 작업할 때 코드 충돌을 막아주는 안전망이다.

1
코드 push
개발자가 작업한 코드를 원격 저장소에 올린다. 이 순간 CI 서버가 자동 실행된다.
2
자동 빌드
의존성을 설치하고, 코드를 컴파일·번들링해 실행 가능한 상태로 만든다.
3
자동 테스트
단위·통합 테스트가 자동 실행된다. 팀원 코드와 충돌하는지도 함께 확인한다.
4
결과 리포트
성공/실패 결과를 슬랙, 이메일, PR 코멘트로 즉시 알려준다. 실패 시 merge가 막힌다.
06 / 15

파이프라인 단계

코드가 push되고 나서 일어나는 일.

1
Checkout · 소스 가져오기
CI 서버가 최신 커밋을 clone하고 의존성 설치 (npm install, pip install)
2
Build · 빌드
컴파일 · 번들링 · 도커 이미지 생성. 결과물을 아티팩트로 저장
3
Test · 테스트
단위 · 통합 · E2E 테스트 실행. 하나라도 실패하면 중단
4
Deploy · 배포
통과한 아티팩트를 서버 · Vercel · AWS 등에 자동 배포
07 / 15
🚀

CD(지속적 배포) —
실제로는 어떻게?

CI를 통과한 코드는 사람 손 없이 자동으로 실제 서비스에 배포된다. 안전을 위해 스테이징 단계를 거친다.

✅ 테스트 통과
🧪 스테이징 배포
👤 팀 검수·승인
🌐 프로덕션 반영

핵심: CD는 "코드가 검증되면 자동으로 사용자에게 전달된다"는 신뢰의 파이프라인이다.

08 / 15

주요 CI/CD 도구

어디서 실행되는지와 무엇과 통합되는지가 선택 기준.

🐙
GitHub Actions
GitHub 기본 내장
YAML 하나로 시작
🔵
CircleCI
빠른 빌드
병렬 실행 강점
🦊
GitLab CI
GitLab 통합
셀프호스팅 용이
Vercel · Netlify
프론트엔드 자동 배포
git push만으로

예: .github/workflows/deploy.yml 파일 하나로 GitHub Actions 파이프라인 완성.

09 / 15
📱

실생활에서
이렇게 쓰여요

우리가 매일 사용하는 앱과 서비스 속에 CI/CD가 녹아 있다.

💬
카카오톡
새 기능이 추가될 때마다 CI/CD로 자동 빌드·테스트·배포되어 앱스토어에 업로드된다.
🐙
GitHub Actions
오픈소스 프로젝트들이 PR을 올릴 때마다 자동으로 테스트를 돌려 코드 품질을 지킨다.
📱
앱스토어 배포
앱스토어 심사 전 자동 빌드·서명 과정이 CI로 처리되어 실수 없이 제출된다.

💡 CI/CD가 없다면 개발자가 매 배포마다 수동으로 빌드·테스트·업로드를 반복해야 한다.

10 / 15
💡

자주 하는
오해 바로잡기

이렇게 생각하기 쉽지만, 실제로는 조금 다릅니다.

❌ 흔한 오해
  • CI/CD = 배포 자동화다
  • 자동화하면 개발자 실수가 없다
  • CI/CD는 대기업만 필요하다
✓ 실제로는
  • CI는 통합(테스트), CD가 배포 — 역할이 다르다
  • 테스트가 완벽해야 자동화도 완벽하다
  • 1인 프로젝트도 GitHub Actions 무료로 사용한다
11 / 15
🏭

CI/CD는 공장 자동화 라인이다

원자재가 들어오면 완성품이 나올 때까지 사람 손을 탈 필요가 없다.

🏭 공장 비유
원자재 투입
=
git push — 새 코드를 저장소에 올림
품질 검사
=
자동 테스트 — 불량품을 걸러냄
포장 · 조립
=
빌드 — 실행 가능한 형태로 가공
출하 · 배송
=
배포 — 완성품이 사용자에게 전달
12 / 15
🤖

이걸 알면
AI와 이렇게 대화해요

CI/CD 개념을 이해하면 Claude나 ChatGPT를 훨씬 잘 활용할 수 있다.

👤
GitHub Actions 설정하고 싶어요.
🤖
GitHub Actions는 .github/workflows 폴더에 YAML 파일을 만들어 시작합니다. 어떤 작업을 자동화하고 싶으신가요?
👤
Node.js 앱에서 main 브랜치에 push할 때마다 자동으로 테스트 실행하고 Vercel에 배포하는 워크플로 YAML 작성해줘.
🤖
완성된 YAML을 드릴게요. on: push, branches: [main], jobs: test(npm test), deploy(vercel action) 순서로 구성했습니다.
13 / 15

이렇게
이해하셨나요?

맞게 이해하셨어요
CI는 코드를 push할 때마다 자동 빌드·테스트한다
이렇게는 아니에요
CI = 배포 자동화다 (CI는 통합, CD가 배포)
맞게 이해하셨어요
CD는 테스트 통과한 코드를 자동으로 배포한다
이렇게는 아니에요
CI/CD를 도입하면 버그가 없어진다

💪 CI/CD는 "사람이 실수를 줄이는 파이프라인"입니다. 완벽함이 아니라 빠른 피드백이 목표예요!

14 / 15
📌

핵심 정리

🔧
CI
push마다 자동
테스트 · 빌드
🚀
CD
통과한 코드를
자동 배포
📜
YAML 파이프라인
코드로 관리되는
배포 설정
🐙
GitHub Actions
저장소에 바로
내장된 CI/CD
빠른 피드백
오류를 분 단위로
감지
🕊️
사람은 리뷰만
단순 반복은
기계가
15 / 15
🚀

다음 세션
Session 37 · Vercel·Netlify 실전 배포

배포가 끝나면 서비스는 살아 있다. 새벽에 장애가 나도 알아야 한다.
CPU · 응답 시간 · 에러율을 실시간으로 추적하는 방법 — 모니터링의 세계로.

💡 기억할 것: 테스트 없이 배포하는 건 눈 감고 운전하는 것이다.

슬라이드 목록