본문으로 건너뛰기
중급약 20분

CI/CD란 무엇인가: 지속적 통합과 지속적 배포

코드를 합칠 때마다, 배포할 때마다 사람이 수동으로 테스트를 돌리지 않아도 되는 이유가 CI/CD다. QA에게 이게 왜 중요한지부터 이해한다.

  • #CICD
  • #지속적통합
  • #지속적배포

개념

지속적 통합(Continuous Integration, CI)

모듈 9(레슨 7)에서 배운 PR을 떠올려보자. 여러 사람이 각자 브랜치에서 작업하다가 main에 합치는 과정에서, 매번 코드를 합칠 때마다 자동으로 빌드하고 테스트를 실행하는 것이 지속적 통합이다.

개발자가 PR을 올린다
  → CI가 자동으로 빌드 + 테스트 스위트 전체 실행
    → 통과하면 병합 가능, 실패하면 병합 차단

사람이 "이 PR 테스트 다 돌려봤어요?"라고 매번 확인할 필요 없이, 기계가 자동으로 확인해준다.

지속적 배포(Continuous Deployment, CD)

CI를 통과한 코드를 자동으로 운영 환경까지 배포하는 것이 지속적 배포다. (배포는 자동이지만 마지막 승인은 사람이 하는 경우는 "지속적 전달(Continuous Delivery)"이라 구분해서 부르기도 한다.)

CI 통과
  → 스테이징 환경에 자동 배포 + 추가 테스트
    → (승인 또는 자동으로) 운영 환경에 배포

왜 QA에게 중요한가

CI/CD 파이프라인은 모듈 11~13에서 짠 자동화 테스트가 실제로 쓰이는 무대다. 아무리 좋은 자동화 테스트를 짜도, 사람이 매번 손으로 실행해야 한다면 반복성(모듈 11 레슨 2)의 이점을 절반도 못 살린다. CI에 통합되어야 비로소 "코드가 바뀔 때마다 자동으로, 빠짐없이 검증된다"는 자동화 본연의 가치가 실현된다.

파이프라인의 단계들

일반적인 CI/CD 파이프라인은 여러 단계(Stage)로 구성된다.

1. 코드 체크아웃 — 저장소에서 최신 코드를 가져온다
2. 의존성 설치 — 필요한 라이브러리를 설치한다
3. 빌드 — 코드를 실행 가능한 형태로 만든다
4. 단위·통합 테스트 실행 (모듈 10)
5. API 테스트 실행 (모듈 12)
6. UI 자동화 테스트 실행 (모듈 13)
7. 배포 (조건을 통과했을 때만)

이 단계들은 모듈 11(레슨 1)에서 배운 자동화 피라미드 순서와 정확히 일치한다 — 빠르고 저렴한 단위 테스트를 먼저 돌려서 빨리 실패를 알아내고, 느리고 비싼 UI 테스트는 나중에, 필요할 때만 돌린다.

실패하면 무슨 일이 일어나는가

파이프라인의 어느 단계에서든 실패하면, 보통 그 이후 단계는 진행되지 않고 병합이나 배포가 차단된다. 이건 모듈 8(레슨 4)에서 배운 "테스트 완료 기준(종료 기준)"을 자동화된 형태로 강제하는 것이다 — 사람이 깜빡하고 기준을 못 지키는 실수를 원천적으로 막는다.

실무에서 왜 필요한가

"배포 전에 QA가 수동으로 전체 회귀 테스트를 하루 종일 돌린다"는 방식은, 배포 주기가 빨라질수록 지속 불가능해진다. CI/CD가 갖춰진 팀은 코드가 합쳐질 때마다 몇 분 안에 자동 검증이 끝나서, QA는 그 결과를 신뢰하고 더 가치 있는 일(탐색적 테스팅, 모듈 5)에 시간을 쓸 수 있다. CI/CD 경험이 있는 QA는 이 시스템을 설계하고 개선하는 역할까지 맡을 수 있다.

실습 과제

과제 1 — 파이프라인 순서 설계하기 (10분)

이 레슨에서 배운 7단계를 참고해, 가상의 프로젝트(백엔드 API + 프런트엔드 웹앱)를 위한 CI 파이프라인 단계를 순서대로 나열하고, 어느 단계에서 어떤 테스트(모듈 10·12·13)를 실행할지 배정한다.

과제 2 — CI 없는 팀의 문제 진단하기 (10분)

"우리 팀은 자동화 테스트가 있지만, 배포 전에 담당자가 로컬에서 수동으로 한 번씩 돌려본다"는 팀이 있다고 하자. 이 방식이 CI로 전환됐을 때와 비교해 어떤 위험이 있는지 2가지 이상 설명한다.

자가 체크리스트

  • 지속적 통합과 지속적 배포의 차이를 설명할 수 있다
  • CI/CD가 왜 자동화 테스트의 가치를 완성시키는 마지막 단계인지 설명할 수 있다
  • 일반적인 파이프라인 단계 순서와 그 순서가 자동화 피라미드와 일치하는 이유를 설명할 수 있다
  • 파이프라인 실패 시 병합·배포가 차단되는 것이 왜 중요한지 설명할 수 있다

흔한 실수

  • CI/CD를 개발팀만의 인프라 영역이라고 생각하고 QA는 관여하지 않는다. 어떤 테스트를, 어느 순서로, 어떤 기준으로 실행할지는 QA의 판단이 핵심적으로 관여해야 하는 부분이다.
  • 지속적 통합과 지속적 배포를 같은 것으로 혼동한다. 통합(테스트 자동 실행)과 배포(운영 환경 반영)는 별개의 단계다.
  • 모든 테스트를 파이프라인 맨 앞에 몰아넣는다. 느린 테스트가 앞에 있으면 빠른 실패 신호를 늦게 받는다 — 피라미드 순서를 지켜야 한다.

참고 자료