[LG CNS AM Inspire Camp] 19. Jenkins 기반 CI/CD 파이프라인 구축

1. CI/CD: 현대 소프트웨어 개발의 기반

1.1. 정의

CI/CD는 지속적 통합(Continuous Integration)과 지속적 배포(Continuous Delivery 또는 Deployment)의 약자로, 빈번하고 신뢰할 수 있는 소프트웨어 제공을 가능하게 하는 자동화된 개발 접근 방식이다.

이 방식은 변경 사항을 보다 빠르고 안정적으로 릴리즈할 수 있게 하며, 반복적이고 수동적인 작업을 제거함으로써 개발 생산성과 품질을 향상시킨다.

1.2. CI/CD 도입의 목적

• 변경 사항의 빠른 통합 및 배포
• 자동화된 테스트와 검증을 통한 품질 확보
• 개발 및 운영 간의 경계 최소화
• 짧은 피드백 루프를 통한 빠른 개선 사이클

1.3. 기존 배포 방식과의 차이점

기존의 배포 프로세스는 종종 수동적이고 오류가 발생하기 쉬웠다. 반면 CI/CD는 코드 커밋부터 운영 배포까지의 전 과정을 자동화함으로써 예측 가능하고 안정적인 결과를 제공한다.

개발 프로세스	단계별로 순차 진행(워터폴 등)	반복적·점진적(애자일, 데브옵스)
코드 통합	주기적으로 대량 통합(수동)	자주(하루에도 여러 번) 자동 통합(CI)
빌드/테스트	수동 빌드 및 테스트, 주로 릴리스 직전	자동화된 빌드/테스트(파이프라인)
배포 방식	수동 배포(명령어 입력, 직접 서버 작업 등)	자동화된 배포(CD), 클릭 한 번 또는 자동 트리거
배포 주기	길고 불규칙(수주~수개월)	짧고 빈번(수시, 하루에도 여러 번)
피드백 속도	느림(릴리스 후에야 사용자 피드백 수집)	빠름(릴리스 직후 즉시 피드백 수집·반영)
휴먼 에러	수동 작업 많아 휴먼 에러 발생 가능성 높음	자동화로 휴먼 에러 최소화
릴리즈 리스크	변경사항이 많아 리스크 큼	변경사항을 작게 나눠 릴리즈, 리스크 분산

 

2. Jenkins: 자동화된 소프트웨어 전달의 핵심 도구

2.1. 개요

Jenkins는 Java 기반의 오픈 소스 자동화 서버로, 소프트웨어의 빌드, 테스트, 배포 등 전체 수명 주기를 자동화하는 데 널리 사용된다.

수천 개의 플러그인을 기반으로 유연하고 확장 가능한 CI/CD 파이프라인 구성을 지원한다.

2.2. 핵심 기능

• 다양한 버전 관리 시스템(Git, SVN 등)과 통합
• 선언형 파이프라인 DSL을 통한 코드 기반 자동화
• 수많은 플러그인을 통한 기능 확장
• 커스터마이징 가능한 UI 및 트리거 옵션

2.3. 한계점

• 자체 서버 관리가 필요하며, 유지보수 비용이 발생함
• 플러그인 의존도가 높고, 구성의 복잡성이 증가할 수 있음
• 초보자에게 다소 높은 학습 곡선

 

3. GitHub Actions vs Jenkins: 두 CI/CD 도구의 비교

3.1. 비교 표

항목	Jenkins	GitHub Actions
설치 방식	자체 호스팅 필요	GitHub에 내장
실행 환경	온프레미스 또는 클라우드	GitHub 제공 클라우드 실행 환경
커스터마이징	자유도 높음	제한적이나 직관적인 구성
러닝 커브	중간 이상	낮음
생태계	풍부한 플러그인 중심	GitHub 중심의 통합 환경
확장성	유연하지만 복잡할 수 있음	간단하고 제한적인 구조

3.2. 선택 기준

• Jenkins는 복잡한 배포 시나리오나 자체 인프라를 보유한 조직에서 높은 유연성과 커스터마이징을 요구할 때 적합하다.
• GitHub Actions는 간단한 CI/CD 구성이나 GitHub 기반 개발 흐름과의 높은 통합성이 필요한 프로젝트에 유리하다.

 

4. Jenkins 설치 및 초기 구성

4.1. 설치 방법 (Docker 기반)

Docker를 활용하면 Jenkins 설치를 간단하고 일관되게 할 수 있다. 다음은 가장 많이 사용되는 LTS 버전의 설치 예시다.

docker network create jenkins

docker volume create jenkins_home

docker run -d \
  --name jenkins \
  --restart=unless-stopped \
  --network jenkins \
  -p 8080:8080 -p 50000:50000 \
  -v jenkins_home:/var/jenkins_home \
  jenkins/jenkins:lts

설치 후 접속

브라우저에서 http://localhost:8080 으로 접속하면 Jenkins 초기 화면이 나타난다.

 

 

4.2. 필수 플러그인 설치 (명령어)

Jenkins CLI를 이용해 플러그인을 설치할 수 있다.

java -jar jenkins-cli.jar -s http://localhost:8080 install-plugin \
  git pipeline blueocean credentials-binding docker-workflow

 

이후 Jenkins를 재시작:

java -jar jenkins-cli.jar -s http://localhost:8080 restart

 

5. Jenkins 파이프라인 구성 방식

5.1. Freestyle vs Pipeline

• Freestyle: UI 기반 구성으로 간단한 작업에 적합
• Pipeline: Jenkinsfile 기반의 코드 중심 자동화로 복잡한 작업에 적합

5.2. 선언형 vs 스크립트형 파이프라인

5.2.1. 선언형 파이프라인

pipeline {
  agent any
  stages {
    stage('Build') {
      steps {
        echo 'Building...'
      }
    }
    stage('Test') {
      steps {
        echo 'Testing...'
      }
    }
  }
}

• 구조가 명확하고 가독성이 높으며, 에러 핸들링과 병렬 처리 등 고급 기능을 내장하고 있다.

5.2.2. 스크립트형 파이프라인

node {
  stage('Build') {
    echo 'Building...'
  }
  stage('Test') {
    echo 'Testing...'
  }
}

• 유연성과 자유도가 높은 방식으로, 복잡한 조건 분기와 반복 구조에 적합하다.

 

6. Jenkins 기반의 CI/CD 파이프라인 예시

6.1. 일반적인 파이프라인 흐름

GitHub 저장소의 Java 프로젝트 기준으로 예시 작성

1. 코드 Push → GitHub Webhook으로 Jenkins 트리거
2. 코드 checkout
3. Gradle로 빌드 및 테스트 수행
4. JUnit 결과 출력 및 아카이브
5. JAR 파일 아카이브 또는 배포

6.2. Jenkinsfile 예제 (선언형 파이프라인)

pipeline {
  agent any

  environment {
    GRADLE_OPTS = "-Dorg.gradle.jvmargs='-Xmx1024m'"
  }

  tools {
    jdk 'jdk17'
  }

  stages {
    stage('Checkout') {
      steps {
        checkout scm
      }
    }

    stage('Build') {
      steps {
        sh './gradlew clean build'
      }
    }

    stage('Test Report') {
      steps {
        junit 'build/test-results/test/*.xml'
      }
    }

    stage('Archive Artifacts') {
      steps {
        archiveArtifacts artifacts: 'build/libs/*.jar', fingerprint: true
      }
    }
  }

  post {
    failure {
      mail to: 'dev-team@example.com',
           subject: "Build Failed in Jenkins: ${env.JOB_NAME}",
           body: "Check Jenkins console for details."
    }
  }
}

 

 

6.3. GitHub Webhook 설정 예시

GitHub 저장소에서 다음 위치로 이동:

Settings > Webhooks > Add webhook

• Payload URL: http://<jenkins-server>:8080/github-webhook/
• Content type: application/json
• Events: Just the push event

Webhook이 제대로 연결되면 Jenkins가 push 이벤트를 감지해 자동으로 빌드를 시작한다.

 

7. 결론

Jenkins는 신뢰성 있는 소프트웨어 제공을 위한 강력한 CI/CD 자동화 도구로, 유연성과 확장성이 뛰어나 복잡한 엔터프라이즈 환경에 적합하다.

반면 GitHub Actions는 보다 직관적이고 간편한 구성을 제공하며, 클라우드 네이티브한 환경에서 빠르게 CI/CD를 구현하고자 하는 팀에게 유리하다.

조직은 요구사항에 따라 적절한 도구를 선택함으로써, 더 자주 그리고 예측 가능한 방식으로 소프트웨어 변경을 배포할 수 있다. 이러한 선택은 곧 개발 속도와 안정성, 그리고 제품 품질로 이어진다.