[Jenkins] Multibranch Pipeline: 무한 증식 브랜치 자동화의 끝판왕

우리는 지금까지 단일 파이프라인(Pipeline) Job을 생성하여 빌드하는 법을 배웠습니다. 하지만 현대 소프트웨어 개발은 Git Flow나 Github Flow를 기반으로, 기능(Feature) 하나를 개발할 때마다 새로운 브랜치를 수십 개씩 파고(Branching) 합치는(Merge) 과정을 밥 먹듯이 반복합니다. 만약 새로운 브랜치가 생성될 때마다 젠킨스 관리자가 웹 UI에 접속해서 "새 잡(Job) 만들기 -> 복사하기 -> 브랜치명 수정" 노가다를 하고 있다면, 그것은 파이프라인이 아니라 수동 라인입니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 관리자의 잡(Job) 복제 스트레스를 0으로 만들어버리는 Multibranch Pipeline(다중 브랜치 파이프라인)의 엄청난 자동 발견(Auto Discovery) 기능과 실무 설정 노하우를 3,000자 분량으로 깊이 있게 딥다이브 해보겠습니다.

🚫 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을 선택하여 생성합니다.

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은 본인이 어떤 브랜치에서 돌고 있는지 알아야 합니다. 이때 11단계에서 배운 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는 개발자들에게 거부감을 줍니다. "빌드가 어디서 터진 건지 로그 찾기가 너무 힘들어요"라는 피드백이 쏟아질 것입니다. 이어지는 18단계 포스팅에서는 칙칙한 90년대 젠킨스 화면을 2024년 최신 트렌드의 유려하고 아름다운 시각적 파이프라인 그래프로 탈바꿈시켜주는 마법, 'Blue Ocean 플러그인 UI 혁신 가이드'에 대해 아주 꼼꼼하게 파헤쳐 보겠습니다!