지속적 통합
더 많은 작업
지속적 통합(Continuous Integration, CI)은 개발자들이 자기 변경분을 공유 저장소의 주 브랜치(mainline)에 자주, 적어도 하루에 한 번 이상 커밋해 합치고, 커밋이 들어올 때마다 자동 빌드와 자동 테스트로 통합 결과를 바로 검증하는 소프트웨어 개발 실천법이다.
지속적 통합은 익스트림 프로그래밍의 실천법에서 출발했다. 여러 사람이 각자 오래 작업한 뒤 기능이 다 끝났을 때 한꺼번에 합치면 충돌과 결함이 몰려 통합에 시간이 오래 걸리고 언제 끝날지 예측하기 어렵다. 지속적 통합은 반대로 작은 변경을 자주 합쳐 통합 문제를 작고 빨리 드러나게 한다.[1] AWS 는 지속적 통합을 개발자가 코드 변경을 중앙 저장소에 정기적으로 병합하고 병합 뒤에 자동 빌드와 테스트가 실행되는 방식으로 설명하며, 자동화 요소(CI 서비스)와 문화 요소(자주 통합하는 습관)를 함께 갖춰야 한다고 본다.[2]
마틴 파울러는 지속적 통합의 실천을 다음과 같이 정리한다.[1]
- 모든 것을 버전 관리되는 주 브랜치에 둔다 - 소스, 테스트, 빌드 스크립트, 설정을 Git·SVN 같은 버전 관리 시스템에 둔다
- 빌드를 자동화한다 - 명령 하나로 컴파일·링크·패키징까지 끝나야 한다
- 빌드가 스스로 테스트하게 한다 - 자동 테스트가 빌드의 일부로 돈다
- 모두가 매일 주 브랜치에 커밋한다 - 기능이 완성될 때까지 기다리지 않는다. 일을 몇 시간 단위로 쪼개 그때그때 합친다
- 주 브랜치에 들어간 모든 커밋이 빌드를 일으킨다 - CI 서비스가 저장소를 지켜보다가 커밋마다 기준 환경에서 빌드와 테스트를 돌린다
- 깨진 빌드는 즉시 고친다 - 통합 빌드가 실패하면 그것을 고치는 일이 가장 우선이다
- 빌드를 빠르게 유지한다 - 피드백이 늦으면 개발자가 자주 커밋하지 않게 된다
- 누구나 상태를 볼 수 있게 한다 - 빌드 결과를 팀 전체에 알린다
지속적 통합의 테스트는 두 번 일어난다. 개발자는 푸시하기 전에 자기 작업 공간에서 최신 주 브랜치를 받아 빌드를 돌려 본다(로컬 빌드). 그러나 작업 공간마다 환경이 다르고 사람이 이 절차를 빠뜨리기도 하므로, 통합 결과를 판정하는 것은 커밋이 들어온 뒤 CI 서비스가 기준 환경에서 자동으로 수행하는 빌드와 테스트이다.[1] 테스트를 사람이 손으로 모두 끝낸 뒤에야 커밋하는 방식은 커밋 간격을 길게 만들어 지속적 통합의 취지와 어긋난다. 테스트 실행은 자동화되어 커밋마다 저절로 돌아야 한다.
- "지속적 통합은 특정 기능의 개발이 완료되었을 때 진행한다" - 틀렸다. 기능 완료와 무관하게 커밋할 때마다 진행한다. 기능 완료 시점에 몰아서 합치는 것이 지속적 통합이 없애려는 방식이다
- "개발자가 테스트를 모두 마친 뒤에 커밋한다" - 지속적 통합의 검증 주체는 사람이 아니라 커밋을 계기로 도는 자동 빌드·테스트이다
- "빌드 서버만 있으면 지속적 통합이다" - 자주 통합하는 습관이 없으면 자동 빌드가 있어도 지속적 통합이 아니다
| 구분 | 지속적 통합(CI) | 지속적 전달(Continuous Delivery) | 지속적 배포(Continuous Deployment) |
|---|---|---|---|
| 범위 | 커밋 → 자동 빌드 → 자동 테스트 | CI + 언제든 배포 가능한 상태 유지 | CI + 테스트 통과 시 운영 환경까지 자동 배포 |
| 운영 배포 | 다루지 않음 | 사람이 승인해 배포 | 사람의 승인 없이 자동 |
자세한 비교는 지속적 통합과 지속적 배포 문서에 있다.
- ↑ 1.0 1.1 1.2 Martin Fowler, 「Continuous Integration」, martinfowler.com, 2024-01-18, https://martinfowler.com/articles/continuousIntegration.html, 확인일: 2026-11-04.
- ↑ 「What is Continuous Integration?」, Amazon Web Services, https://aws.amazon.com/devops/continuous-integration/, 확인일: 2026-11-04.