Jenkins라는 말은 자주 듣지만, 지금까지 이용해 본 적이 없어 Jenkins를 이용한 CI/CD, 파이프라인 구축에 대해 이미지가 그려지지 않았기 때문에 독자적으로 조사하여 본 기사를 작성했습니다. 또한 자율주행(어느 쪽인가 하면 ADAS에 가깝습니다)과 연관 지어 핸즈온 형식으로 구성하였으므로, 자율주행 개발이나 CI/CD에 관심이 있는 분들은 꼭 읽어주시기 바랍니다.

자율주행 시스템 개발에서는 카메라나 LiDAR와 같은 센서의 입력 데이터 처리나, 차량의 거동을 결정하는 제어 로직 등 다방면에 걸친 코드가 조합되어 있습니다. 이러한 복잡한 시스템에서는 미세한 코드 수정이 의도하지 않은 거동(예를 들어 브레이크가 작동하지 않음, 급브레이크를 밟음 등)을 일으킬 위험이 있습니다.

안전이 제일인 자율주행 개발에서 코드를 변경할 때마다 수동으로 빌드나 테스트를 수행하는 것은 시간이 걸릴 뿐만 아니라, 휴먼 에러(Human Error)의 원인이 되기도 합니다. 그래서 변경된 코드를 자동으로 검증하는 CI/CD(Continuous Integration/Continuous Delivery: 지속적 통합/지속적 제공)가 매우 중요한 역할을 합니다.

CI/CD란 소프트웨어 개발에서의 빌드, 테스트, 배포를 자동화하기 위한 메커니즘입니다.

크게 CI(Continuous Integration: 지속적 통합)와 CD(Continuous Delivery/Deployment: 지속적 제공/배포)로 나뉩니다. CI는 소스 코드의 변경을 통합하고, 빌드·테스트를 자동 실행하며, 결함을 조기에 발견하는 역할을 합니다. CD는 테스트를 통과한 결과물을 자동으로 배포 가능한 상태로 만들고, 운영 환경으로의 릴리스를 자동화하는 역할을 합니다.

본 기사에서는 특별한 시뮬레이터나 하드웨어를 필요로 하지 않고, Docker 환경이 동작하는 로컬 PC(Windows/Mac/Linux)만으로 간편하게 실행할 수 있는 환경을 만듭니다.

주제로 Python으로 구현한 간이 충돌 피해 경감 브레이크(AEB: Autonomous Emergency Braking) 제어 코드를 사용합니다. ※ECU 구현 단계에서는 실시간성, 메모리 관리의 관점에서 C/C++ 등의 언어가 이용될 것으로 생각됩니다만, 이번에는 어디까지나 간이 버전이라는 점에서 Python을 채택했습니다.

본 핸즈온의 전제 조건으로서 다음과 같은 기초 지식이 있다고 가정합니다.

Python의 기본 문법: 제어 로직 및 테스트 코드 이해에 사용합니다. -
Git의 기본 조작: 리포지토리 초기화, 커밋(Commit), GitHub로의 푸시(Push) 등의 조작을 수행합니다. -
Docker의 기초 지식: Jenkins 서버의 기동, 그리고 정적 분석이나 테스트를 실행하기 위한 커스텀 이미지 생성 시 Docker를 사용합니다.

이 코드에 대해 Docker 상의 Jenkins를 이용하여 다음과 같은 처리를 자동으로 실행하는 파이프라인을 구축합니다.

정적 분석: 코드의 기술 스타일(Coding Style)에 문제가 없는지 자동으로 체크합니다. -
단위 테스트: 서로 다른 주행 조건(전방 차량과의 거리나 상대 속도)에서 브레이크가 설계대로 작동하는지 테스트합니다. -
빌드 결과물의 패키징: 테스트를 통과한 제어 모듈을 릴리스용 zip 형식으로 패키징하여, Jenkins의 빌드 결과로부터 다운로드할 수 있도록 합니다.

본 기사를 통해 Docker를 이용한 Jenkins의 기본적인 사용법과, 자동화 파이프라인이 개발 프로세스를 얼마나 효율화하는지 체험할 수 있을 것입니다.

이 장에서는 이번 핸즈온에서 사용할 4가지 개발 도구에 대해 자세히 해설합니다. 각각의 도구의 역할과, 왜 자율주행 개발 등의 현장에서 널리 사용되고 있는지 이해해 두시기 바랍니다.

Git은 소스 코드의 변경 이력을 기록·관리하는 분산형 버전 관리 시스템입니다.

자율주행 개발에서는 AI 모델의 개선, 제어 로직의 수정, 시뮬레이터와의 연동 등 매일 무수한 프로그램 업데이트가 발생합니다. 또한 여러 명의 개발자가 동시에 서로 다른 기능의 개발을 진행하는 것도 일상적인 일입니다.

Git을 사용함으로써 누가 언제 어떤 변경을 가했는지 이력을 완전히 남길 수 있습니다. 만일 자동 브레이크의 거동에 결함이 발생하더라도, 과거에 정상적으로 동작하던 버전으로 즉시 되돌리는 것이 가능합니다.

Jenkins는 소프트웨어 개발의 빌드, 테스트 및 배포를 자동화하기 위한 오픈 소스 CI/CD 엔진입니다.

자율주행 시스템처럼 구성 요소가 많은 개발 프로세스에서는 코드를 변경할 때마다 수동으로 빌드하고, 테스트를 실행하며, 결과물을 패키징하는 것은 매우 힘든 작업입니다.

Jenkins는 Git 커밋 등을 감지하여 이러한 정형화된 작업들을 미리 정의된 절차(Pipeline)에 따라 전자동으로 실행합니다. 이를 통해 개발자는 "코드를 작성하는 것"에 집중할 수 있으며, 검증 누락도 방지할 수 있습니다.

Jenkins의 상세한 내용은 다음 장에서 살펴보겠습니다.

flake8은 Python 코드가 표준 코딩 규약인 PEP 8을 준수하는지 체크하는 정적 분석 도구(Linter)입니다.

프로그램을 실행하지 않고 코드를 스캔하여 문법 오류나 사용되지 않는 변수 정의, 스타일상의 미비점(불필요한 공백이나 줄바꿈 등)을 검출합니다.

차량용 소프트웨어 개발 현장에서는 코드의 품질과 가독성을 유지하기 위해 엄격한 코딩 표준이 정해져 있습니다. flake8을 사용함으로써 팀 전체의 소스 코드 작성 방식을 통일하고, 한눈에 이해하기 쉬운 깨끗한 상태로 유지할 수 있습니다.

pytest는 Python으로 작성된 프로그램의 동작 검증을 간편하게 수행하기 위한 단위 테스트 프레임워크(Unit Test Framework)입니다.

테스트용 코드를 매우 심플하게 기술할 수 있으며, 검증 결과의 성패를 알기 쉽게 출력합니다.

자율주행 제어 로직 개발에 있어서는 실제 차량을 움직이기 전에 PC 상에서 다양한 주행 시나리오를 상정한 테스트를 수행해야 합니다. pytest를 사용하면 다양한 입력 데이터(장애물과의 거리나 차속 등)를 상정한 테스트 케이스를 정의하고, 기대한 대로의 출력(브레이크 강도 등)을 얻을 수 있는지 자동으로 반복하여 검증할 수 있습니다.

간단하게 Jenkins의 특징 및 다른 CI/CD 엔진과의 비교, 기본 개념을 나타냅니다.

플러그인이 매우 풍부함: 이용 가능한 플러그인이 1,000종류 이상이며, GitHub, GitLab, Docker, AWS, Azure 등 다양한 도구와 연동 가능.

모든 환경에서 동작 가능: Jenkins 자체는 Java 애플리케이션이며, Windows, Linux 등 다양한 환경에서 동작함.

Pipeline as Code: 빌드 절차 등 파이프라인을 코드로 작성하여 Git으로 관리할 수 있으므로 리뷰 가능, 이력 관리 가능, 재현성이 높음.

Jenkins 전체를 관리하는 서버입니다. Job 관리, 스케줄링, UI 제공, Agent 관리를 담당합니다.

실제로 빌드나 테스트를 실행하는 머신입니다. 한쪽 Agent를 Linux, 다른 쪽 Agent를 Windows로 설정하면 OS별 빌드도 가능해집니다.

Jenkins 관점에서의 실행 환경 총칭입니다. Controller와 Agent를 모두 포함합니다.

Jenkins에 등록되는 Pipeline의 실행 단위입니다. 예를 들어 AEB 빌드, 테스트, Docker 이미지 생성 등이 각각 Job이 됩니다.

Job 내의 처리 절차를 정의한 것입니다. 코드 취득 ⇒ Lint ⇒ 테스트 ⇒ 패키징과 같은 절차를 의미하며, Jenkinsfile로 기술합니다.

Jenkins를 이용한 파이프라인의 아래 예시를 보여줍니다.

아래 예시는 개발자가 GitHub 등에 push한 코드를 트리거로 CI/CD 파이프라인을 실행하고, 결과물을 DB에 배포하는 것까지 자동화하는 것입니다.

Pipeline 아래에는 더욱 'Stage'라는 개념이 있습니다.

Pipeline을 구성하는 작업 그 자체입니다. 코드 취득, Lint, 테스트, 패키징이 각각 Stage에 해당합니다.

다음과 같은 이미지입니다.

GitHub 공식 CI/CD 도구입니다. GitHub 리포지토리와 통합할 수 있고, 설정이 간편하며 SaaS로 이용 가능하다는 점이 강점입니다.

GitLab에 표준 탑재된 CI/CD 기능입니다. DevOps 기능이 통합되어 있으며, 보안 스캔 기능이 풍부합니다.

클라우드 네이티브(Cloud-native) CI/CD 서비스입니다. 셋업이 용이하고 실행 속도가 빠릅니다.

이 외에도 다양한 도구가 있으며, 유스케이스와 실행 환경에 따라 구분하여 사용하거나 조합하여 이용해야 합니다.

본 핸즈온에서의 실행 환경에 대하여

일반적인 대규모 개발에서는 관리를 수행하는 "Controller"와 빌드를 실행하는 복수의 "Agent"를 별도의 서버(Windows나 Linux 등)로 나누어 운용합니다. 하지만 본 핸즈온에서는 간략화를 위해 Docker 컨테이너(Linux 환경) 내에 Jenkins Controller를 띄우고, 해당 컨테이너 내에서 직접 모든 처리(Lint, 테스트, 패키징)를 실행하는 심플한 구성을 취합니다.

설명은 여기까지로 하고, 드디어 다음 장부터 핸즈온에 들어갑니다.

이 장에서는 필요한 도구가 미리 설치된 Jenkins 환경을 Docker를 사용하여 구축합니다.

이번에는 정적 분석 도구인 flake8, 테스트 프레임워크인 pytest, 그리고 결과물을 하나로 묶기 위한 zip 명령어가 미리 설치된 커스텀 Docker 이미지를 생성하여 사용합니다.

Jenkins 공식 이미지 (LTS 버전)를 베이스로 하여, 필요한 패키지를 설치한 커스텀 이미지를 만듭니다.

적당한 작업용 폴더(예: jenkins-setup)를 생성하고, 그 안에 Dockerfile이라는 이름의 파일을 새로 만들어 다음 내용을 작성합니다.

FROM jenkins/jenkins:lts
USER root
# Python, pip, zip 설치
...

터미널(Windows에서는 PowerShell 등)을 열고, Dockerfile이 위치한 폴더로 이동하여 다음 명령어를 실행해 이미지를 빌드합니다. 빌드에는 몇 분 정도 소요될 수 있으니 느긋하게 기다려 주세요.

docker build -t jenkins-python .

"Successfully tagged jenkins-custom:latest"와 같은 로그가 출력되면 커스텀 이미지 빌드에 성공한 것입니다.

빌드한 커스텀 이미지 jenkins-custom을 사용하여 Jenkins 컨테이너를 실행합니다.

다음 명령어를 실행합니다.

docker run -d -p 8080:8080 -p 50000:50000 --name jenkins-local -v jenkins_home:/var/jenkins_home jenkins-python

각 옵션의 역할은 다음과 같습니다.

• -d: 백그라운드에서 컨테이너를 실행합니다.
• -p 8080:8080: 브라우저에서 접속하기 위한 포트(8080번)를 호스트 PC와 매핑합니다.
• -p 50000:50000: Jenkins 에이전트(Agent) 접속용 포트를 지정합니다.
• --name jenkins-local: 실행할 컨테이너에 jenkins-local이라는 이름을 부여합니다.
• -v jenkins_home:/var/jenkins_home: 잡(Job) 설정이나 실행 이력 등의 데이터를 호스트 측 볼륨(Volume)에 저장하여 영속화합니다. 이를 통해 컨테이너를 재시작하거나 삭제해도 설정이 유지됩니다.

명령어를 실행하고 잠시 기다리면 컨테이너가 시작됩니다.

※ 컨테이너를 중지하려면 docker stop jenkins-local을, 다시 시작하려면 docker start jenkins-local을 실행합니다.

Jenkins가 시작되면 웹 브라우저를 열고 http://localhost:8080에 접속합니다. 아래와 같은 화면이 나타나면 Jenkins 실행에 성공한 것입니다.

최초 접속 시, 앞서 보았던 Unlock Jenkins 화면이 나타나며 관리자 비밀번호 입력을 요구합니다.

터미널에서 docker logs jenkins-local 명령어를 실행하고, 출력된 시작 로그 중에서 수십 자리의 영문·숫자 조합으로 된 비밀번호를 찾아 복사합니다. 비밀번호는 다음과 같이 표시되며, <This is password> 부분에 해당 비밀번호가 나타납니다.

*************************************************************
*************************************************************
*************************************************************
...

비밀번호를 브라우저 입력란에 붙여넣고 Continue를 클릭합니다.

플러그인 선택 화면이 나타납니다. 여기서는 "Install suggested plugins"를 선택해 주세요. 자율주행 빌드 및 이번 파이프라인 생성에 필요한 기본 플러그인(Git 연동 및 파이프라인 기능 등)이 자동으로 설치됩니다. 완료될 때까지 몇 분간 기다립니다.

플러그인 설치가 완료되면 첫 번째 관리자 사용자(Create First Admin User)를 생성하는 화면이 나타납니다.

사용자 이름(Username), 비밀번호(Password), 성함(Full Name), 이메일 주소(Email Address)를 입력하고 Save and Continue를 클릭합니다.

마지막으로 Jenkins의 접속 URL을 확인하는 화면이 나타납니다. 그대로 http://localhost:8080/를 사용해도 괜찮다면 Save and Finish를 클릭합니다.

「Jenkins is ready!」라고 표시되면 Start using Jenkins를 클릭합니다. 대시보드(Dashboard) 화면이 나타나면 초기 설정이 모두 완료된 것입니다.

이 장에서는 자율주행의 제어 로직으로서 간이적인 자동 긴급 제동 (AEB, Autonomous Emergency Braking) 프로그램을 작성하고, 이를 검증하기 위한 단위 테스트 (Unit Test) 코드를 준비합니다.

먼저, 차량의 센서로부터 얻은 전방 차량과의 거리와 상대 속도를 바탕으로 브레이크 강도를 계산하는 프로그램을 작성합니다.

aeb_control.py라는 이름으로 다음 코드를 작성해 주세요.

def calculate_brake_level(distance: float, relative_speed: float) -> float:
    """자동 긴급 제동 (AEB)의 브레이크 강도를 계산합니다.
    Args:
    ...

• calculate_brake_level 함수는 장애물까지의 거리와 접근 속도를 받아 브레이크의 강도를 결정합니다.
• 충돌 예측 시간인 TTC (Time-To-Collision)를 거리 / 상대 속도로 계산하고, 정지하기 위해 필요한 감속도 (Required Deceleration)를 상대 속도² / (2 × 거리)로 계산합니다.
• 필요 감속도가 클수록 위험도를 높게 평가하여, 고속으로 접근하는 경우에도 적절하게 브레이크를 강화할 수 있도록 했습니다.
• TTC로부터 산출한 위험도와 필요 감속도로부터 산출한 위험도 모두를 평가하여, 더 위험한 쪽을 채택함으로써 안전 측면의 제어를 수행합니다.
• 브레이크 강도는 단순한 선형 계산이 아니라 Smoothstep 함수를 사용하여 산출하며, 위험도 변화에 대해 부드럽게 상승하도록 했습니다. 이 처리를 통해 임계값(Threshold) 부근에서 브레이크 강도가 급격하게 변화하는 것을 억제하고, 더욱 자연스러운 감속 특성을 실현합니다.

※ 실제 차량에서는 여기에 더해 저크 (Jerk, 가속도의 변화율) 제한을 추가함으로써 승객이 불쾌감을 느끼지 않도록 부드러운 브레이크 제어를 수행하는 것이 일반적이지만, 코드가 더욱 복잡해지므로 여기서는 생략합니다.

다음으로, 작성한 제어 로직이 안전 요구 사항을 충족하는지 검증하기 위한 테스트 코드를 작성합니다.

test_aeb_control.py라는 이름으로 다음 코드를 작성해 주세요.

import pytest
from aeb_control import calculate_brake_level

def test_safe_distance():
    ...

• pytest는 test_로 시작하는 함수를 자동으로 테스트 케이스로 인식하여 실행합니다.
• assert 문을 사용하여 실제 계산 결과가 기대되는 브레이크 강도와 일치하는지 평가합니다.
• 경고나 긴급 제동과 같은 일반적인 제어 패턴뿐만 아니라, 거리나 속도에 이상한 값이 들어왔을 경우의 이상계 (Exception case) 동작도 검증합니다.
• 부동 소수점 연산에 의한 미세한 오차를 고려하기 위해, 일부 테스트에서는 pytest.approx()를 사용하여 허용 오차 범위 내에 있음을 검증합니다.

Jenkins 파이프라인에 올리기 전에, 우선 로컬 터미널에서 동작 확인을 수행합니다.

다음 명령어를 터미널에서 실행하여 flake8과 pytest를 설치합니다.

pip install flake8 pytest

코드의 스타일 체크를 수행합니다.

flake8 aeb_control.py test_aeb_control.py

이 명령어를 실행했을 때 아무런 에러 메시지가 표시되지 않는다면, 코드가 PEP 8 규약을 올바르게 준수하고 있음을 나타냅니다.

이어서 제어 로직의 동작 검증을 수행합니다.

pytest

테스트를 실행하면 「5 passed」라고 출력되며, 작성한 모든 시나리오에서 테스트가 성공했음을 확인할 수 있습니다.

수동 테스트와 정적 분석이 성공한 것을 확인했다면, 드디어 이러한 절차들을 Jenkins에서 자동화해 보겠습니다.

이 장에서는 정적 분석 (Static Analysis), 단위 테스트 (Unit Test), 패키징 (Packaging)의 일련의 흐름을 자동으로 실행하는 파이프라인 스크립트 (Jenkinsfile)를 작성하고, Jenkins에서 실행하는 방법을 설명합니다.

Jenkins가 빌드나 테스트를 실행하기 위해서는 대상이 되는 소스 코드를 가져와야 합니다. 이번에는 로컬 PC에서 작성한 코드를 GitHub 리포지토리 (Repository)에 등록하고, Jenkins에서 가져오는 구성으로 진행합니다.

먼저 GitHub 리포지토리에서 새로운 리포지토리 (예: aeb-jenkins-handson)를 생성해 주세요.

이어서 aeb_control.py, test_aeb_control.py, Jenkinsfile을 동일한 디렉토리에 배치하여 다음과 같은 구성으로 만듭니다.

aeb-jenkins-handson/
├── Jenkinsfile
├── aeb_control.py
...

Jenkinsfile은 Jenkins가 어떤 절차로 자동 처리를 수행할지를 기술하는 파일입니다. 아래 내용으로 작성해 주세요.

pipeline {
agent any
stages {
...

• pipeline 블록으로 감싸줌으로써, Jenkins의 선언적 파이프라인 (Declarative Pipeline)이라는 권장되는 형식으로 파이프라인을 기술하고 있습니다.
• agent any는 사용 가능한 임의의 실행 환경 (Agent)에서 이 파이프라인을 실행하도록 지정합니다. 이번에는 Docker 컨테이너 (Linux) 환경의 Jenkins 자체에서 실행됩니다.
• Docker 컨테이너 (Linux 환경)에서 실행하기 때문에, 셸 (Shell) 실행 명령에 sh 단계를 사용하고 있습니다. 이를 통해 표준 Linux 셸 명령어가 호출됩니다.
• Test 스테이지 내의 post 블록에서는 테스트 성공 여부와 관계없이 always (항상) JUnit 형식의 테스트 결과 XML을 수집하여, Jenkins 화면 상에 깔끔한 그래프나 리포트로 표시하도록 지시하고 있습니다.
• Package 스테이지에서는 테스트가 성공했을 경우에만 archiveArtifacts를 사용하여 생성된 release.zip을 빌드 결과물 (Artifact)로서 Jenkins 서버에 저장합니다. Linux 환경에 프리인스톨 (Pre-installed)되어 있는 zip 명령어를 사용하여 압축을 수행합니다.

마지막으로 아래 명령어를 실행하여 GitHub 리포지토리로 push 합니다.

git init
git add .
git commit -m "Initial commit"
...

이로써 Jenkins가 GitHub 상의 소스 코드를 가져올 준비가 완료되었습니다.

Jenkins 관리 화면에서 파이프라인을 실행하기 위한 설정을 진행합니다.

• Job 이름 및 종류 지정:
  Job 입력란에 aeb-pipeline을 입력하고, 목록에서 「Pipeline」을 선택한 뒤 화면 하단의 OK를 클릭합니다.

• 파이프라인 스크립트 등록:
  설정 화면이 나타나면 가장 아래에 있는 「Pipeline」 섹션까지 스크롤합니다.
  • Definition (정의)에서 **「Pipeline script from SCM」**을 선택합니다.
  • SCM에서 **「Git」**을 선택합니다.
  • Repository URL에 GitHub 리포지토리 URL을 입력합니다.
    예: https://github.com/<사용자명>/aeb-jenkins-handson.git
  • Branch Specifier에는 */main을 입력합니다.
  • Script Path는 Jenkinsfile 그대로 둡니다. (리포지토리 루트 직하에 배치했기 때문)
  • 리포지토리가 프라이빗 (Private)인 경우, Credentials에서 GitHub 인증 정보를 설정해 주세요.

※ 파이프라인을 실행하면, Jenkins는 먼저 GitHub에서 리포지토리를 가져온 뒤 그 안에 있는 Jenkinsfile을 읽어 파이프라인을 시작합니다. 그 후 Lint, Test, Package 각 스테이지를 순차적으로 실행합니다.

• 저장:
  화면 하단의 저장 (Save)을 클릭합니다.

드디어 파이프라인을 실행합니다.

• 실행:

작업(Job)의 메인 화면에서 왼쪽 메뉴에 있는 "빌드 실행 (Build Now)"을 클릭합니다.

• 진행 상황 확인:

실행이 시작되면 화면 중앙에 Stage View라는 표가 표시되며, Lint -> Test -> Package 순으로 각 스테이지가 녹색으로 변해갑니다. 모든 스테이지가 녹색이 되면 성공입니다.

• 테스트 결과 확인:

작업 실행 결과 화면(Build #1 등)을 열면 "테스트 결과"라는 링크가 나타납니다. 여기를 클릭하면 pytest에 의해 실행된 5개의 테스트 케이스가 모두 정상적으로 통과했는지에 대한 상세 리포트를 브라우저 상에서 시각적으로 확인할 수 있습니다.

• 빌드 결과물 다운로드:

빌드가 성공하면 빌드 결과물 (Build Artifacts)로서 release.zip이 화면에 표시됩니다. 링크를 클릭하여 테스트가 완료된 결과물을 로컬 PC로 다운로드할 수 있습니다.

CI/CD의 진가는 결함이 있는 코드가 커밋되었을 때 즉시 감지할 수 있다는 점에 있습니다.

시험 삼아 aeb_control.py의 긴급 제동 조건을 변경하여, TTC(Time To Collision)가 0.5초일 때 긴급 제동이 작동하지 않도록 로직을 수정해 보세요.

그 상태에서 다시 "빌드 실행"을 수행하면, Test 스테이지가 빨간색으로 변하며 파이프라인이 자동으로 중단됩니다. 테스트 결과 화면에는 "어떤 테스트가 몇 번째 줄에서 기대값과 달랐는지"가 명시되므로, 자율주행 로직에 잠재된 디그레션 (Degradation, 퇴보/결함 혼입)을 개발의 초기에 방지할 수 있음을 실감할 수 있습니다.

본 기사에서는 자율주행 개발에서의 충돌 피해 완화 제동 (AEB) 제어 로직을 주제로, Docker 상에서 Jenkins를 이용한 자동화 파이프라인을 구축하는 절차를 해설했습니다.

수동으로 정적 분석이나 테스트를 실행하는 것은 개발자에게 번거로운 작업입니다. 하지만 Jenkins를 통한 파이프라인을 도입함으로써 코드 가져오기, 구문 체크, 제어 로직 동작 검증, 나아가 배포 패키지 생성까지 항상 동일한 품질로 자동 실행되도록 할 수 있습니다.

이러한 지속적 통합 (CI) 환경을 갖춰둠으로써 결함을 빠르게 발견하고, 안전성이 높은 소프트웨어를 지속적으로 출시할 수 있습니다. 특히 안전성이 무엇보다 중시되는 자율주행 및 차량용 소프트웨어 개발 현장에서 CI/CD는 빼놓을 수 없는 필수 기술이 되고 있습니다.