Continuous Integration (CI)

지속적 통합(CI)은 모든 개발자의 변경사항을 공유 메인 브랜치에 자주, 최소 하루에 한 번 병합하고 각 변경사항을 자동으로 빌드 및 테스트하는 관행입니다. 이를 통해 릴리스 시점이 아니라 몇 분 이내에 통합 문제를 발견할 수 있습니다. Grady Booch가 1991년에 이 용어를 제안했고, Kent Beck은 1990년대 후반 익스트림 프로그래밍의 핵심 실천법으로 자리 잡게 했습니다. Martin Fowler의 글 지속적 통합은 오늘날에도 대부분의 팀이 따르는 워크플로를 설명합니다. 머신러닝(ML)에서는 변경사항으로 인해 모든 단위 테스트가 통과해도 모델 정확도가 낮아질 수 있으므로 데이터, 학습 코드, 모델 동작도 CI에서 확인합니다.

CI 파이프라인 작동 방식#

개발자가 브랜치에 푸시하거나 풀 리퀘스트를 열면 GitHub Actions, GitLab CI/CD, Jenkins와 같은 CI 서비스가 새 러너를 시작하고 코드를 체크아웃한 뒤 종속성을 설치하고 여러 작업으로 이루어진 파이프라인을 실행합니다. 작업에는 린터와 타입 검사기, 단위 테스트, 통합 테스트, 패키지 또는 컨테이너 이미지 빌드가 포함됩니다. 각 작업의 상태는 풀 리퀘스트에 보고되며, 브랜치 보호 규칙을 통해 필수 검사가 모두 통과해야 병합할 수 있도록 설정할 수 있습니다. 파이프라인은 다양한 운영체제와 Python 버전의 조합으로 동일한 테스트를 반복하는 경우가 많으며, 병합 후에는 메인 브랜치에서 전체 테스트를 다시 실행합니다. 속도도 중요한 실천 요소입니다. Beck의 익스트림 프로그래밍은 전체 시스템을 빌드하고 모든 테스트를 실행하는 데 10분이 걸리도록 목표를 설정했습니다. 빌드가 느릴수록 실행 횟수가 줄어들기 때문입니다.

머신러닝을 위한 CI#

ML 프로젝트에는 자체 검사가 추가됩니다. 데이터 테스트는 새 학습 데이터가 예상 스키마에 맞는지, 모든 라벨 파일을 파싱할 수 있는지, 이미지가 학습 분할과 검증 분할에 중복으로 포함되지 않았는지를 확인합니다. 이미지가 양쪽에 있으면 데이터 누수가 발생합니다. 스모크 테스트에서는 작은 데이터세트로 에포크 하나를 학습해 형태 오류와 충돌을 몇 분 안에 찾아냅니다. 모델 출력을 비교하는 테스트는 GPU 커널과 데이터 로딩 순서에 따라 부동소수점 결과가 실행마다 달라질 수 있으므로 난수 시드를 고정하고 작은 수치 오차를 허용합니다. 품질 게이트는 고정된 검증 세트에서 모델을 평가하고 평균 정밀도(mAP)와 같은 지표가 기준값 아래로 떨어지면 빌드에 실패하도록 합니다. 내보내기 테스트는 ONNX 또는 TensorRT 버전의 모델이 원본처럼 로드되고 점수를 산출하는지 확인합니다. 전체 학습은 느리고 GPU 러너 비용은 높으므로, 팀은 보통 모든 풀 리퀘스트에서 빠른 검사를 실행하고 전체 재학습과 모델 배포는 예약 실행이나 메인 브랜치 실행에 맡깁니다. DVC와 같은 버전 관리 도구를 사용하면 각 작업이 필요한 정확한 데이터세트 버전을 가져올 수 있습니다.

Ultralytics YOLO의 벤치마크 모드는 이러한 품질 게이트 역할을 합니다. verbose을 0.216과 같은 실수로 설정하면 내보내기에 실패하거나 내보낸 형식 중 하나라도 mAP_50-95가 해당 기준값을 초과하지 못할 때 오류가 발생합니다. Ultralytics 저장소 자체 CI는 이 기능을 사용해 Linux, macOS, ARM 러너에서 YOLO26 내보내기를 테스트합니다. 다음은 단위 테스트와 품질 게이트를 결합한 최소한의 GitHub Actions 워크플로입니다:

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

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-python@v6
        with:
          python-version: "3.13"
      - run: pip install ultralytics pytest
      - run: pytest tests/
      # Fail if the ONNX export breaks or its mAP50-95 is not above the 0.216 floor
      - run: yolo benchmark model=yolo26n.pt format=onnx imgsz=160 verbose=0.216

모든 풀 리퀘스트와 main에 대한 모든 푸시는 새 Ubuntu 러너에서 작업을 실행합니다. 단위 테스트가 실패하거나 작은 COCO8 데이터세트에서 ONNX 모델 점수가 기준값 이하이면 변경사항을 병합하기 전에 검사가 실패 상태로 표시됩니다.

CI와 CD, MLOps 및 지속적 학습 비교#

• 지속적 전달(CD): CI를 통과한 빌드를 릴리스 가능한 상태로 유지하며, 스테이징 환경에 자동으로 배포하는 경우가 많습니다. 지속적 배포는 한 단계 더 나아가 통과한 모든 변경사항을 프로덕션에 배포합니다.
• MLOps: ML 수명 주기 전반에 걸쳐 CI와 CD를 데이터 버전 관리, 모델 배포, 모니터링, 재학습과 결합하는 더 넓은 분야입니다.
• 지속적 학습(CT): 새 데이터가 들어오거나 모니터링에서 드리프트가 감지될 때 모델을 자동으로 재학습하고 재배포합니다. Google의 MLOps 성숙도 단계에서는 자동 재학습을 1단계, 학습 파이프라인 자체의 자동 CI/CD를 2단계로 구분합니다.