[DevOps] CI/CD가 대체 뭔데? 자동화 배포의 첫걸음

컨테이너 계열을 마치고, 이제 DevOps의 꽃이라고 할 수 있는 CI/CD로 넘어온다. 근데 그 전에 이런 상황을 한번 떠올려보자.

코드를 수정했다. 이제 배포해야 한다. 그 과정이 이렇다.

1. 로컬에서 테스트를 돌린다. (가끔 깜빡한다.)
2. 빌드한다.
3. 서버에 SSH로 접속한다.
4. git pull 하고, 다시 빌드하고, 서버를 재시작한다.
5. 잘 떴나 확인한다.

이걸 코드 고칠 때마다, 하루에도 몇 번씩 손으로 반복한다. 실수도 나온다. 테스트를 깜빡하고 배포했다가 서비스가 터지기도 한다. 이 지겹고 위험한 반복을 자동화하는 게 바로 CI/CD다.

---

CI/CD, 이름부터 풀어보자

CI/CD는 두 개가 붙은 말이다. CI와 CD.

CI = Continuous Integration (지속적 통합)
코드를 합칠 때마다 자동으로 테스트하고 빌드해서, 문제가 있는지 바로 확인하는 것.

CD = Continuous Delivery / Deployment (지속적 배포)
테스트를 통과한 코드를 자동으로 배포까지 이어가는 것.

한 문장으로 합치면 이렇다. "코드를 푸시하면, 자동으로 테스트하고 빌드해서 배포까지 알아서 해준다." 사람이 손으로 하던 그 반복 작업을 기계가 대신하는 거다.

---

CI: 코드를 합칠 때마다 자동 검사

CI의 핵심 질문은 이거다. "이 코드, 합쳐도 괜찮아?"

여러 명이 개발하면 각자 코드를 짜서 합친다(merge). 근데 합쳤더니 남의 코드랑 충돌하거나, 테스트가 깨지거나, 빌드가 안 되는 일이 생긴다. 이걸 나중에 발견하면 원인 찾기가 지옥이다.

그래서 CI는 코드가 올라올 때마다(push/PR) 자동으로 이런 걸 돌린다.

• 코드가 빌드되는지 확인
• 테스트가 다 통과하는지 확인
• 코드 스타일(린트)에 문제 없는지 확인

문제가 있으면 바로 "여기서 실패했어요"라고 알려준다. 그래서 버그가 작을 때, 일찍 잡힌다. 이게 CI의 가장 큰 가치다. "합치기 전에 자동으로 검사받는다"고 생각하면 된다.

---

CD: 통과했으면 자동으로 배포

CI를 통과한 코드는 "믿을 만하다"고 검증된 상태다. CD는 그걸 실제 환경에 배포하는 것까지 자동화한다.

여기서 용어가 두 개로 갈린다. 헷갈리기 쉬운데 딱 이 차이다.

• Continuous Delivery(지속적 전달): 배포 직전까지 다 자동으로 준비해두고, 마지막 배포 버튼만 사람이 누른다. "언제든 배포 가능한 상태"를 유지하는 것.
• Continuous Deployment(지속적 배포): 그 마지막 버튼까지 없애고 완전 자동으로 배포한다. 테스트 통과하면 사람 손 안 거치고 바로 운영에 나간다.

처음엔 Delivery(사람이 마지막 확인)로 시작해서, 파이프라인이 믿음직해지면 Deployment(완전 자동)로 가는 게 보통이다.

---

파이프라인: 이 과정을 이어붙인 것

CI/CD에서 계속 나오는 말이 파이프라인(pipeline)이다. 별거 아니다. 방금 말한 단계들을 순서대로 이어붙인 자동화 흐름이 파이프라인이다.

[코드 push]
     │
     ▼
[빌드] → [테스트] → [이미지 생성] → [배포]
     └─ 하나라도 실패하면 여기서 멈추고 알려줌

물이 파이프를 따라 흐르듯, 코드가 이 단계들을 통과해 배포까지 흘러간다. 중간에 하나라도 실패하면 거기서 멈추고, 그 뒤 단계는 진행하지 않는다. 덕분에 깨진 코드가 운영에 나가는 걸 막아준다.

---

이걸 뭘로 하는데? (도구들)

이 파이프라인을 실제로 돌려주는 도구들이 있다. 대표적으로,

도구	특징
GitHub Actions	GitHub에 내장. 설정 간단, 입문 최적
GitLab CI/CD	GitLab에 내장
Jenkins	오래된 강자, 자유도 높지만 무겁고 설정 복잡
CircleCI	클라우드 기반, 빠름

이 중에서 입문자에게는 GitHub Actions를 추천한다. 이미 GitHub을 쓰고 있다면 별도 설치 없이 저장소 안에 설정 파일 하나만 넣으면 바로 돌아간다. 다음 글에서 이걸로 직접 첫 파이프라인을 만들어볼 거다.

---

왜 이렇게까지 자동화할까?

정리하면서 "그래서 좋은 게 뭔데?"를 짚어보자.

• 실수가 준다. 사람이 하던 반복 작업(테스트 깜빡, 배포 순서 실수)을 기계가 하니 실수가 없다.
• 빠르다. 푸시하고 커피 한 잔 하면 배포가 끝나 있다.
• 버그를 일찍 잡는다. 합칠 때마다 자동 테스트라 문제가 작을 때 발견된다.
• 자주 배포할 수 있다. 배포가 쉬우니 조금씩 자주 내보낸다. 한 번에 크게 배포하는 것보다 훨씬 안전하다.

---

정리

• CI(지속적 통합): 코드를 합칠 때마다 자동으로 빌드·테스트해서 문제를 일찍 잡는다.
• CD(지속적 배포): 통과한 코드를 자동으로 배포한다. (사람이 마지막 버튼을 누르면 Delivery, 완전 자동이면 Deployment)
• 파이프라인: 빌드 → 테스트 → 배포를 순서대로 이어붙인 자동화 흐름. 중간에 실패하면 멈춘다.
• 입문 도구로는 GitHub Actions가 제일 만만하다.

"코드 고칠 때마다 손으로 배포하던" 삶에서 "푸시하면 알아서 되는" 삶으로 넘어가는 게 CI/CD다. 다음 글에서는 GitHub Actions로 진짜 첫 워크플로우를 만들어서, 코드를 푸시하면 자동으로 테스트가 돌아가는 것까지 직접 해보자.