CI/CD 기초 (1) - Why CI/CD
CI/CD가 필요한 이유를 정리합니다.
CI/CD 기초 시리즈의 1편입니다. 도구를 만지기 전에, 이 도구가 어떤 문제를 풀려고 나왔는지를 먼저 정리합니다.
수동 배포 과정
CI/CD가 없는 팀의 배포는 대략 이렇게 진행됩니다.
- 코드를 고친다
- 로컬에서 실행해 보고, 되는 것 같으면 커밋한다
- 서버에 SSH로 접속한다
- 새 코드를 서버로 가져온다 (git pull, 또는 파일을 직접 복사)
- 의존성을 다시 설치한다
- 서비스를 재시작한다
- 브라우저를 열어 잘 뜨는지 확인한다
일곱 단계 전부를 사람이 손으로 합니다. 처음 몇 번은 괜찮습니다. 문제는 이걸 매주, 나중에는 매일 반복할 때 생깁니다.
무엇이 문제인가?
사람은 단계를 빼먹습니다. 급하게 배포하다가 5번(의존성 설치)을 건너뛰면, 새 코드가 새 라이브러리를 쓰는 순간 서버가 죽습니다. 어제는 했던 단계를 오늘 안 했다는 사실을, 서버가 죽고 나서야 알게 됩니다.
“로컬에서는 됐는데”가 반복됩니다. 2번의 확인은 내 컴퓨터에서의 확인입니다. 내 컴퓨터에는 우연히 깔려 있던 프로그램이 서버에는 없을 수 있고, 파이썬 버전이 다를 수 있습니다. 로컬에서의 성공이 서버에서의 성공을 보장하지 않습니다.
확인이 손에 달려 있습니다. 테스트를 돌리는 것도 사람 몫이라, 바쁘면 생략됩니다. 깨진 코드가 커밋되어도 아무도 모르다가, 며칠 뒤 다른 사람이 그 코드를 받아서야 발견됩니다. 원인을 찾는 비용은 시간이 지날수록 커집니다.
그래서 배포가 무서워집니다. 배포할 때마다 무언가 깨질 수 있으니 배포를 미루게 됩니다. 미루면 다음 배포에 쌓이는 변경이 많아지고, 변경이 많을수록 무엇이 문제를 일으켰는지 찾기 어려워집니다. 무서워서 미루고, 미뤄서 더 무서워지는 악순환입니다.
정리하면 문제의 뿌리는 하나입니다. 반복 작업의 품질이 사람의 성실함에 달려 있다는 것입니다.
Pipeline이란 무엇인가?
답은 단계를 사람 머릿속이 아니라 파일에 적어두고, 기계가 매번 같은 순서로 실행하게 만드는 것입니다. 이 자동화된 단계의 연결을 파이프라인(pipeline)이라고 부릅니다.
flowchart LR
A[코드 push] --> B[자동 검사<br>빌드, 린트, 테스트]
B -->|통과| C[자동 배포]
B -->|실패| D[여기서 멈춤<br>배포 안 됨]
파이프라인이 생기면 위의 문제가 이렇게 바뀝니다.
- 단계를 빼먹는 일이 없습니다. 파일에 적힌 순서대로 매번 전부 실행됩니다.
- 검사는 내 컴퓨터가 아니라 매번 새로 만들어지는 깨끗한 서버에서 돕니다. “로컬에서는 됐는데”가 검사 단계에서 걸러집니다.
- 테스트는 push할 때마다 자동으로 돕니다. 깨진 코드는 커밋 직후에 발견됩니다.
- 배포가 무섭지 않아지니 자주 하게 됩니다. 배포 한 번에 실리는 변경이 작아지고, 문제가 생겨도 범인 후보가 적습니다.
용어 정리: CI, Continuous Delivery, Continuous Deployment
CI/CD라는 약자를 풀면 세 가지 개념이 나옵니다.
CI (Continuous Integration, 지속적 통합)는 파이프라인의 앞부분입니다. 코드가 push되거나 합쳐질 때마다 자동으로 빌드하고 테스트해서, “이 코드를 합쳐도 깨지지 않는다”를 매번 확인하는 것입니다.
CD는 두 가지로 풀립니다. 둘 다 검증을 통과한 코드를 내보내는 뒷부분을 가리키지만, 마지막 한 발이 다릅니다.
- Continuous Delivery (지속적 전달): 배포 직전 상태까지 자동으로 만들어 두되, 실제 배포는 사람이 버튼을 눌러 결정합니다.
- Continuous Deployment (지속적 배포): 버튼도 없습니다. 검증을 통과하면 사람 손 없이 그대로 배포됩니다.
| 용어 | 자동화 범위 | 마지막 배포 결정 |
|---|---|---|
| Continuous Integration | 빌드와 테스트까지 | 해당 없음 |
| Continuous Delivery | 배포 준비까지 | 사람 |
| Continuous Deployment | 배포까지 전부 | 기계 |
실무에서 “CD”라고 말할 때 둘 중 무엇인지는 문맥에 따라 다르고, 구분 없이 쓰는 경우도 많습니다. 이 시리즈에서는 둘을 묶어 “검증을 통과한 코드를 자동으로 내보내는 단계”로 다루고, 구분이 필요한 곳에서만 풀네임을 쓰겠습니다.
CI/CD 도구들
파이프라인을 실행해 주는 도구는 여러 가지입니다. Jenkins는 직접 서버에 설치해 쓰는 오래된 표준이고, GitLab CI는 GitLab에, GitHub Actions는 GitHub에 내장되어 있습니다. 어떤 도구든 “저장소에 파일로 적어둔 단계를, 정해진 사건이 일어날 때 실행한다”는 뼈대는 같습니다.
이 시리즈의 실습은 GitHub Actions로 시작합니다. GitHub에 저장소가 있다면 설정 파일 하나만 추가하면 바로 동작하기 때문입니다. 2편에서 그 파일을 처음부터 만들어 봅니다.
정리
| 개념 | 한 줄 요약 |
|---|---|
| 수동 배포의 문제 | 반복 작업의 품질이 사람의 성실함에 달려 있다 |
| 파이프라인 | 단계를 파일에 적어두고 기계가 매번 같은 순서로 실행 |
| CI | push마다 자동 빌드와 테스트, “합쳐도 안 깨진다”를 확인 |
| Continuous Delivery | 배포 준비까지 자동, 마지막 결정은 사람 |
| Continuous Deployment | 마지막 결정까지 기계, push가 곧 배포 |