CI의 개념과 CI 도구의 흐름: 깃허브 액션과 Travis CI

지속적 통합(CI, Continuous Integration)은 개발자들이 작성한 코드를 짧은 주기로 공유 저장소에 병합하고, 병합할 때마다 빌드와 테스트를 자동으로 실행해 문제를 조기에 발견하는 개발 방식이다. 이 자동화를 담당하는 도구로 과거에는 트래비스 CI(Travis CI)와 젠킨스(Jenkins)가 널리 쓰였고, 현재는 깃허브 액션(GitHub Actions)이 사실상의 표준으로 자리 잡았다. 도구는 바뀌어도 커밋마다 빌드와 테스트를 자동 검증한다는 핵심 흐름은 동일하다.

CI가 해결하는 문제

CI가 없던 시절에는 각자 오래 작업한 브랜치를 한꺼번에 합치다가 병합 충돌과 통합 버그가 터지는 이른바 통합 지옥(integration hell)이 흔했다. 문제는 발견이 늦을수록 원인 커밋을 찾기 어렵고 수정 비용도 커진다는 점이다. CI는 이를 뒤집어, 작은 단위로 자주 병합하고 병합 시점마다 전체 테스트를 돌려서 문제를 커밋 단위로 좁혀 준다.

CI가 제대로 동작하려면 두 가지 전제가 필요하다. 첫째, 빌드와 테스트가 사람 손을 타지 않고 명령 한 번으로 재현 가능해야 한다. 둘째, 실패를 걸러 줄 자동화된 테스트가 충분히 있어야 한다. 테스트가 없는 CI는 컴파일 확인기에 지나지 않는다.

CI 파이프라인의 기본 흐름

도구가 무엇이든 CI 파이프라인(pipeline)의 뼈대는 같다. 개발자가 코드를 푸시하거나 풀 리퀘스트(Pull Request)를 열면 저장소의 웹훅(webhook) 이벤트가 CI 서버를 깨운다. CI 서버는 깨끗한 가상 머신이나 컨테이너 환경을 새로 만들어 코드를 체크아웃하고, 의존성 설치, 빌드, 테스트, 정적 분석을 순서대로 실행한다. 결과는 풀 리퀘스트 화면에 성공과 실패로 표시되고, 실패한 코드는 병합이 차단된다.

매번 새 환경에서 실행하는 이유는 "내 컴퓨터에서는 되는데"라는 문제를 차단하기 위해서다. 로컬에 우연히 설치된 도구나 남아 있는 파일에 의존하는 코드는 깨끗한 환경에서 즉시 실패하므로, CI 통과 자체가 빌드 재현성의 증명이 된다.

깃허브 액션으로 보는 CI 설정

깃허브 액션은 저장소 안의 .github/workflows/ 디렉터리에 YAML 파일로 워크플로(workflow)를 정의한다. 워크플로는 트리거 이벤트, 실행 환경, 그리고 순차 실행되는 스텝(step)으로 구성된다.

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 21
          cache: gradle
      - run: ./gradlew build

여기서 on은 어떤 이벤트에 반응할지, runs-on은 어떤 러너(runner) 환경에서 실행할지를 정한다. uses는 체크아웃이나 자바 설치처럼 자주 쓰는 작업을 재사용 가능한 액션으로 가져오는 문법이고, run은 셸 명령을 직접 실행한다. 의존성 캐시를 활성화하면 매 실행마다 라이브러리를 새로 내려받지 않아 파이프라인 속도가 크게 빨라진다. 저장소와 CI가 한 플랫폼에 통합되어 별도 서버나 외부 서비스 연동 없이 설정 파일 하나로 시작할 수 있다는 점이 깃허브 액션이 표준이 된 이유다.