이름 그대로 통합(integration)을 계속하는 것이다. 빌드 서버를 세우는 일이 아니다.
무엇을 푸는 문제인가
각자 브랜치에서 2주씩 작업하다 한꺼번에 합치면, 그때 처음으로 서로의 변경이 부딪힌다. 충돌은 쌓인 만큼 커지고, 어느 변경이 원인인지도 흐려진다. 이것을 흔히 통합 지옥이라 부른다.
CI 의 답은 단순하다 — 자주 합쳐서 한 번에 터질 것을 잘게 나눈다. 하루에 여러 번 주 브랜치에 합치면 충돌은 매번 작고, 깨졌을 때 범인은 방금 들어온 변경뿐이다.
그래서 자동 빌드·테스트가 따라온다
자주 합치려면 합쳐도 안전한지 빨리 알아야 한다. 그 확인을 사람이 하면 자주 할 수 없으니 자동화한다. 순서가 이렇다 — 자주 합치고 싶어서 자동화한 것이지, 자동화했더니 CI 가 된 것이 아니다.
빌드 서버는 있는데 브랜치를 2주씩 들고 있다면 CI 를 하고 있는 것이 아니다. 도구가 아니라 합치는 주기가 CI 를 정의한다.
전제가 되는 것들
- 주 브랜치는 항상 배포 가능한 상태여야 한다 — 깨진 채로 두면 다른 사람이 그 위에서 작업하게 되고 원인이 섞인다
- 깨지면 그것부터 고친다 — 빨간 파이프라인을 방치하면 곧 아무도 안 본다. 신호가 무시되는 순간 파이프라인은 장식이 된다
- 빨라야 한다 — 결과가 30분 뒤에 오면 개발자는 기다리지 않고 다음 일을 시작한다. 그 사이에 또 커밋이 쌓여 원인이 섞인다
무엇을 검사하나 — 순서가 중요하다
jobs:
fast: # 1~2분 — 매 푸시
steps: [lint, 단위 테스트, 타입 검사]
slow: # 10분+ — 병합 전 또는 야간
steps: [통합 테스트, E2E, 보안 스캔]
빠른 것을 먼저 돌려 빨리 실패시킨다. 컴파일도 안 되는 코드에 E2E 를 30분 돌리는 것은 낭비다. 실패 확률이 높고 비용이 싼 검사부터 배치하는 것이 원칙이다.
빠르게 만드는 수단들
- uses: actions/cache@v4
with:
path: ~/.gradle/caches
key: gradle-${{ hashFiles('**/*.gradle*') }}
restore-keys: gradle-
- 캐시 — 의존성을 매번 받지 않는다.
key는 잠금 파일 해시로,restore-keys로 접두사 일치 시 부분 적중 - 병렬 — 서로 의존하지 않는 잡은 동시에 돌린다
- 영향 범위 한정 — 모노레포에서 바뀐 모듈만 검사한다
- 테스트 분할 — 긴 테스트를 여러 러너에 나눠 돌린다
목표 수치가 있다. 10분을 넘으면 사람이 기다리지 않는다. 기다리지 않으면 다음 작업을 시작하고, 그 사이 커밋이 쌓여 원인이 섞인다. 파이프라인 속도는 편의가 아니라 CI 가 성립하는 조건이다.
신뢰할 수 없는 테스트가 CI 를 죽인다
같은 코드인데 어떤 날은 통과하고 어떤 날은 실패하는 테스트(flaky)가 몇 개만 있어도 파이프라인 전체가 못 믿을 것이 된다. 사람들은 곧 "다시 돌려 보고 되면 넘어가는" 습관을 들이고, 그 순간 진짜 실패도 같은 취급을 받는다.
재시도로 덮지 말고 원인을 찾거나 격리한다. 빨간불이 의미를 가지려면 빨간불이 항상 진짜여야 한다.
미완성 기능은 어떻게 하나
"자주 합치라" 와 "완성되지 않은 것을 내보내지 마라" 는 충돌하는 것처럼 보인다. 실무의 해법은 코드는 합치되 동작은 끄는 것이다 — 기능 플래그로 감싸 두면 합쳐도 사용자에게 보이지 않는다. 브랜치를 오래 들고 있는 대신 꺼진 코드를 합친다.
면접 함정
- ❌ "CI 는 Jenkins·GitHub Actions 같은 도구" → 도구는 수단이다. 자주 합치지 않으면 CI 가 아니다.
- ❌ "테스트만 돌면 CI" → 주 브랜치에 자주 합치는 것이 본체다.
- ❌ "파이프라인이 빨간 건 나중에 고치면 된다" → 방치되는 순간 신호로서의 값어치를 잃는다.