[Jenkins] 멀티브랜치 파이프라인 무한 증식 브랜치 자동화

우리는 지금까지 단일 파이프라인(Pipeline) Job을 생성하여 빌드하는 법을 배웠습니다. 하지만 현대 소프트웨어 개발은 GIT Flow나 Github Flow를 기반으로, 기능(Feature) 하나를 개발할 때마다 새로운 브랜치를 수십 개씩 파고(Branching) 합치는(Merge) 과정을 밥 먹듯이 반복합니다. 만약 새로운 브랜치가 생성될 때마다 젠킨스 관리자가 웹 UI에 접속해서 "새 잡(Job) 만들기 -> 복사하기 -> 브랜치명 수정" 노가다를 하고 있다면, 그것은 파이프라인이 아니라 수동 라인입니다.

 

이 포스트에서는 인프라 관리자의 잡(Job) 복제 스트레스를 0으로 만들어버리는 Multibranch Pipeline(다중 브랜치 파이프라인)의 엄청난 자동 발견(Auto Discovery) 기능과 실무 설정 노하우를 다뤄보겠습니다.

1. 레거시(Legacy) 잡 복제의 끔찍한 한계

기존 단일 파이프라인 환경에서는 main 브랜치용 빌드 잡 하나, develop 브랜치용 빌드 잡 하나를 수동으로 띄워두고 관리했습니다. 개발팀에서 feature/login-page 브랜치를 새로 파고 "이 브랜치도 테스트 서버에 자동 배포되게 젠킨스 세팅 좀 해주세요"라고 요청하면, 데브옵스 담당자는 기존 잡을 복사해서 설정에 들어가 브랜치 이름을 수정한 뒤 저장 버튼을 눌러야 했습니다.

만약 프로젝트 규모가 커져 브랜치가 50개라면? 잡(Job)도 50개가 됩니다. 그러다 갑자기 공통 파이프라인 로직 하나가 바뀌면, 50개의 잡 설정에 일일이 들어가서 수정해야 하는 최악의 상황을 맞이하게 됩니다. 이 문제를 완벽하게 해결하기 위해 탄생한 플러그인이 바로 Multibranch Pipeline입니다.

 

2. Multibranch Pipeline의 혁신적인 동작 원리

Multibranch Pipeline을 생성하고 Github 레포지토리를 연결해두면, 젠킨스는 마법처럼 똑똑하게 동작합니다.

1. 자동 스캔(Auto Scan): 젠킨스가 주기적으로(혹은 Webhook을 받을 때마다) Github 레포지토리를 전체 스캔합니다.
2. Jenkinsfile 탐색: 수많은 브랜치들을 하나하나 뒤져보면서, 소스코드 최상단 루트 경로에 Jenkinsfile이 존재하는 브랜치들만 쏙쏙 찾아냅니다.
3. 하위 폴더 자동 생성: Jenkinsfile을 품고 있는 브랜치를 발견하면, Multibranch 폴더 안에 해당 브랜치 이름과 똑같은 하위 파이프라인 잡(Sub-Job)을 스스로 만들어내고 즉시 1회 빌드를 돌려버립니다.
4. 자동 소멸(Auto Delete): 개발이 끝나고 PR(Pull Request)이 통과되어 해당 브랜치가 Github에서 삭제(Delete)되면, 젠킨스도 이를 감지하고 스스로 자신이 만들었던 하위 파이프라인 잡을 깔끔하게 지워버립니다. (이를 고아(Orphaned) 아이템 정리라고 부릅니다.)

즉, 인프라 관리자는 처음에 Multibranch Job 딱 하나만 만들어두면, 그 이후 브랜치가 수백 개 생겨나든 말든 젠킨스가 알아서 복제하고 알아서 지워줍니다! 완벽한 'Zero Touch' 자동화의 실현입니다.

 

3. 실무 필수 셋업 가이드 및 트러블슈팅

젠킨스 대시보드에서 새로운 Item -> Multibranch Pipeline을 선택하여 생성합니다.</p

1. Branch Sources (브랜치 소스 등록)
GIT을 선택하고 저장소 주소와 Credentials를 넣어줍니다. 여기서 Discover branches(브랜치 탐색) 동작이 기본으로 추가되어 있는지 확인합니다.

2. 치명적 설정: Filter by name (브랜치 필터링)
초보자들이 가장 많이 빼먹는 설정입니다. 만약 레포지토리에 개발자들의 개인 백업용 브랜치가 1,000개 있다면, 젠킨스는 바보처럼 1,000개의 하위 잡을 전부 만들고 동시에 1,000번의 빌드를 돌려버리며 서버를 터뜨려버립니다(DDoS 자폭).
반드시 Behavior -> Add -> Filter by name (with wildcards)를 추가해야 합니다. - Include: main release-* feature/* (스페이스바 단위로 입력) - Exclude: feature/wip-* (작업 중인 브랜치는 제외) 이렇게 명시해두면 딱 필요한 규칙을 가진 브랜치만 탐색하여 빌드합니다.

3. Orphaned Item Strategy (찌꺼기 정리 전략)
Github에서 지워진 브랜치의 잡을 젠킨스에서도 즉시 날릴 것인지 묻는 옵션입니다. Discard old items를 체크하고 Days to keep old items를 7일 정도로 맞춰두는 것이 실무 정석입니다. (만약 0일로 두면 깃허브에서 브랜치가 삭제되는 즉시 빌드 로그까지 싹 다 날아가버려 추후 증적 자료를 찾을 수 없습니다.)

 

4. Multibranch 환경의 Jenkinsfile 작성법

Multibranch 안에서 도는 Jenkinsfile은 본인이 어떤 브랜치에서 돌고 있는지 알아야 합니다. 이때 에서 배운 env.BRANCH_NAME 환경변수가 빛을 발합니다.

pipeline {
    agent any
    stages {
        stage('Build & Test') {
            steps {
                echo "[${env.BRANCH_NAME}] 브랜치 빌드를 시작합니다!"
                sh 'npm run build && npm run test'
            }
        }
        stage('Deploy') {
            // 브랜치 이름에 따라 배포 로직을 동적으로 라우팅!
            steps {
                script {
                    if (env.BRANCH_NAME == 'main') {
                        echo " Production 서버 배포"
                        // sh 'deploy prod'
                    } else if (env.BRANCH_NAME == 'develop') {
                        echo " Test 서버 배포"
                        // sh 'deploy dev'
                    } else if (env.BRANCH_NAME.startsWith('feature/')) {
                        echo " 배포 스킵 (Feature 브랜치는 빌드와 테스트만 검증합니다)"
                    }
                }
            }
        }
    }
}

 

5. 마무리 및 주요 발전 방향

지금까지 수십 개의 브랜치가 생성되고 소멸하는 현대 개발 프로세스에 완벽하게 대응하는 'Multibranch Pipeline'의 위대한 자동화 개념과 실무 필터링 설정 기법에 대해 3,000자에 걸쳐 아주 치밀하게 다루어 보았습니다. 이제 데브옵스 엔지니어는 브랜치가 추가되든 말든 신경 쓰지 않아도 되며, 젠킨스는 살아 숨 쉬는 유기체처럼 브랜치들을 자동 관리합니다.

이렇게 훌륭한 파이프라인을 구축했지만, 젠킨스 특유의 투박하고 올드한 텍스트 덩어리 UI는 개발자들에게 거부감을 줍니다. "빌드가 어디서 터진 건지 로그 찾기가 너무 힘들어요"라는 피드백이 쏟아질 것입니다. 본 설명에서는 칙칙한 90년대 젠킨스 화면을 2024년 최신 트렌드의 유려하고 아름다운 시각적 파이프라인 그래프로 탈바꿈시켜주는 마법, 'Blue Ocean 플러그인 UI 혁신 가이드'에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다!

---

강력하고 견고한 CI/CD 파이프라인 로직을 완벽하게 짰다 하더라도, 그것을 사용하는 주체는 결국 '사람(개발자)'입니다. 기존 젠킨스(Jenkins)의 클래식 인터페이스를 처음 접하는 주니어 개발자들은 90년대 감성의 회색 텍스트와 파란색 동그라미(성공), 빨간색 동그라미(실패) 덩어리를 보며 큰 진입 장벽과 거부감을 느낍니다. 특히 빌드가 실패했을 때, 까만 터미널 화면에 찍힌 수만 줄짜리 콘솔 로그(Console Output)를 눈알이 빠지도록 스크롤을 내리며 에러 원인을 찾는 과정은 크나큰 고통입니다.

본 글에서는 이 모든 칙칙한 UI를 현대적이고 세련된 시각적 대시보드로 180도 뒤집어주는 'Blue Ocean(블루 오션) 플러그인'의 혁신적인 기능과 100% 활용 노하우를 다뤄보겠습니다.

1. Blue Ocean 이란 무엇인가? (클래식 UI의 종말)

Blue Ocean은 젠킨스 개발진이 "우리 UI가 너무 못생기고 쓰기 불편하다는 것을 인정한다"며 작정하고 내놓은 차세대 사용자 경험(UX) 프로젝트입니다. 기존 클래식 테마를 덮어씌우는 완전히 새로운 스킨이자 엔진이라고 생각하시면 됩니다.

설치 방법은 너무나도 간단합니다. [Jenkins 관리] -> [플러그인 관리]에서 Blue Ocean을 검색하고 체크한 뒤 설치(Install without restart)만 누르면 끝입니다. (의존성 패키지들이 꽤 많아서 설치에 수 분 정도 소요될 수 있습니다.) 설치가 완료되면 기존 젠킨스 대시보드 좌측 상단 메뉴바에 반가운 [ Open Blue Ocean] 버튼이 활성화됩니다. 이 버튼을 누르는 순간 젠킨스의 완전 새로운 세계가 열립니다.

2. 실무 개발자들이 환호하는 3가지 파워풀 기능

단순히 예뻐진 것만이 아닙니다. 실무 운영 관점에서 문제 해결 속도(MTTR)를 혁신적으로 줄여주는 킬러 기능들이 탑재되어 있습니다.

1. 직관적인 노드 그래프 시각화 (Pipeline Visualization)
클래식 UI의 Stage View는 파이프라인이 직렬로만 흐르는 것처럼 보여주지만, Blue Ocean은 분기 처리나 병렬 처리(Parallel) 작업들을 예쁜 노드(Node) 연결망 그래프로 시각화해줍니다. 10개의 스테이지가 있다면 어디서 병목(Bottleneck)이 생겨서 시간이 오래 걸리고 있는지 게이지 바(Gauge bar) 형태로 실시간 진행률을 완벽하게 보여줍니다.

2. 핀포인트 에러 추적 (Pinpoint Error Tracking) 가장 강력한 기능
만약 1시간짜리 빌드 중 55분째에 특정 단위 테스트 하나가 실패해서 전체가 붉게 물들었다고 칩시다. 옛날 같으면 10만 줄의 텍스트 로그를 내리며 Exception 단어를 검색해야 했습니다. 하지만 Blue Ocean에서는 파이프라인 그래프 중 에러가 발생한 바로 그 Stage 노드에 빨간 엑스(X) 마크가 찍힙니다. 그 노드를 마우스로 클릭하면, 수만 줄의 로그 대신 오직 실패한 그 쉘 스크립트(Step) 부분의 로그 딱 10줄만 화면 가운데로 하이라이트(Highlight)하여 팝업시켜 줍니다. 개발자는 클릭 단 한 번으로 원인을 찾고 즉시 코드를 수정하러 갈 수 있습니다.

3. 브랜치와 PR(Pull Request) 중심의 대시보드
앞선 기술 개요에서 구축한 Multibranch Pipeline과 완벽한 궁합을 자랑합니다. 메인 대시보드에서 각 레포지토리의 브랜치별 건강 상태(성공률)와, 누군가 올린 PR들이 빌드를 통과했는지를 탭(Tab) 하나로 깔끔하게 분류하여 한눈에 모니터링할 수 있습니다.

3. Visual Pipeline Editor: 코딩 없이 인프라 짜기

Blue Ocean의 또 다른 미친 혁신은 바로 비주얼 파이프라인 에디터(Visual Pipeline Editor)입니다. 데브옵스 엔지니어가 아닌 일반 프론트엔드/백엔드 개발자에게 Jenkinsfile의 Groovy 문법(Declarative Syntax)을 백지상태에서 짜라고 하면 멘붕에 빠집니다.

Blue Ocean 화면 우측 상단의 연필 모양 아이콘(Edit)을 누르면 거대한 빈 캔버스가 나타납니다. 여기서 + 버튼을 눌러 Stage 박스를 시각적으로 그리고, 우측 패널에서 "쉘 스크립트 실행(sh)" 메뉴를 선택해 npm run build를 입력하기만 하면 됩니다. 그림을 그리듯 로직을 구성한 뒤 Save 버튼을 누르면? Blue Ocean 엔진이 내가 그린 그래프를 완벽한 문법의 Jenkinsfile 코드로 자동 변환하여 Github 레포지토리에 커밋(Commit)까지 다이렉트로 박아줍니다! (이 기능 때문에 Scripted가 아닌 Declarative 문법이 완전히 천하통일을 이루게 되었습니다.)

4. 한계점 및 하이브리드 운영 전략

이처럼 훌륭한 Blue Ocean이지만 단점도 존재합니다. 플러그인 관리, 노드 서버 추가, Credential 관리 등 '젠킨스 관리자용 딥(Deep) 설정' 화면은 Blue Ocean에서 아예 지원하지 않습니다. 오직 파이프라인을 실행하고 모니터링하는 '사용자(개발자)' 관점에만 특화되어 있기 때문입니다.

따라서 데브옵스 엔지니어는 시스템 설정을 바꿀 때는 상단의 탈출 버튼을 눌러 클래식 UI로 돌아가서 작업하고, 빌드를 모니터링하거나 에러를 잡을 때, 혹은 일반 개발자들에게 권한을 줄 때는 Blue Ocean 링크를 공유하는 식의 '하이브리드(Hybrid) 운영' 방식을 채택하는 것이 실무의 정석입니다.

5. 마무리 및 주요 발전 방향

지금까지 투박한 젠킨스를 트렌디한 SaaS 서비스처럼 우아하게 탈바꿈시켜 주는 파이프라인 시각화의 꽃, 'Blue Ocean' 플러그인의 압도적 기능과 에디터 활용법에 대해 다루어 보았습니다. 이제 여러분의 개발팀은 에러 로그를 찾기 위해 방황하지 않으며, CI/CD 모니터링 화면을 커다란 사무실 모니터에 예쁘게 띄워놓고 자랑스럽게 구경할 수 있게 되었습니다.

 

파이프라인을 빠르고 직관적으로 볼 수 있게 되었으니, 이제 그 파이프라인 내부에서 "여러 가지 작업을 동시에 진행하여 전체 빌드 시간을 반의반으로 줄여버리는 마법"이 필요해질 타이밍입니다. 배포 시간이 10분에서 2분으로 단축되는 짜릿함!
다음 설명에서는 Declarative Pipeline의 극한 최적화 기법이자 코어 엔진을 100% 쥐어짜는 'Parallel(병렬) 처리로 파이프라인 속도 혁신하기'에 대해 다루어보겠습니다.