지속적 통합(CI)

지속적 통합(Continuous Integration, CI)이란 개발자가 작은 변경을 메인 브랜치에 자주 병합하고, 푸시나 풀 리퀘스트가 있을 때마다 서버가 코드를 빌드하고 자동화 테스트를 실행하는 것을 말합니다. 핵심은 빠른 피드백입니다. 변경이 무언가를 망가뜨리면, 며칠 뒤 대규모 병합 중이 아니라 변경 내용이 아직 기억에 생생할 때 작성자가 알게 됩니다.

예시 (GitHub Actions)

모든 풀 리퀘스트와 main 푸시에서 테스트 스위트를 실행하는 최소한의 파이프라인:

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

npm test가 0이 아닌 종료 코드로 끝나면 잡(job)이 실패하고 풀 리퀘스트에 빨간 체크가 표시됩니다. 이 체크를 필수로 요구하는 브랜치 보호 규칙과 함께 쓰면 망가진 코드는 병합될 수 없습니다.

CI에서 테스터가 책임지는 것

• 어떤 테스트를 어디서 실행할지. 빠른 단위 테스트와 API 테스트는 모든 풀 리퀘스트에서, 느린 E2E 스위트는 병합 시점이나 정해진 스케줄에 실행합니다. 40분 걸리는 풀 리퀘스트 파이프라인은 결국 아무도 쓰지 않게 됩니다.
• 신호의 품질. 차단(blocking) 잡에 있는 플래키 테스트는 사람들에게 “재실행” 버튼을 누르는 습관을 들입니다. 플래키 테스트를 격리(quarantine)해서 빨간 빌드가 항상 의미 있게 만드세요.
• 아티팩트. 실패한 실행의 리포트, 트레이스, 스크린샷을 게시해서 실패 내용을 보려고 로컬에서 재현할 필요가 없게 합니다.
• 병렬화. 긴 스위트를 여러 머신에 샤딩하면 스위트가 커져도 피드백 시간이 늘지 않습니다.

CD와의 차이

지속적 전달(Continuous Delivery)은 CI를 확장한 것입니다. 통과한 모든 빌드를 패키징해 언제든 릴리스할 수 있는 상태로 유지하며, 보통 스테이징 환경을 거칩니다. 지속적 배포(Continuous Deployment)는 한 걸음 더 나아가 통과한 모든 변경을 프로덕션에 자동으로 릴리스합니다. CI는 두 가지 모두의 토대이며, 모든 커밋에서 신뢰할 수 있는 테스트 스위트가 돌지 않으면 둘 다 안전하지 않습니다.

흔한 실수

CI를 야간에만 실행하는 것, 메인 브랜치가 며칠씩 빨간 상태로 방치되는 것, 파이프라인을 테스트를 실행하는 곳이 아니라 테스트를 작성하는 곳으로 취급하는 것입니다. CI는 도구인 동시에 팀의 습관입니다. 작게 병합하고, 빌드가 깨지면 고치거나 되돌리세요.