[Jenkins] When 조건문으로 스테이지 완벽 제어하기 (동적 파이프라인 구축)

파이프라인 매개변수(Parameters)를 통해 외부에서 동적인 값을 주입받는 방법을 익혔다면, 이제 그 값에 따라 파이프라인의 물줄기를 요리조리 바꾸는 방법을 알아야 합니다. 만약 매개변수 설정만 해두고 if-else 문 같은 로직 분기를 태우지 않는다면 매개변수는 그저 화면에 찍히는 의미 없는 문자에 불과합니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 Declarative Pipeline의 꽃이자, 하나의 파일로 수십 가지의 배포 시나리오를 감당하게 해주는 강력한 무기인 'when' 조건문의 완벽한 활용법과 다양한 실무 예제들을 3,000자 분량으로 깊이 있게 딥다이브 해보겠습니다. 이 글을 마스터하시면 더 이상 브랜치별로 수많은 잡(Job)을 복사/붙여넣기 하는 고통에서 영원히 해방될 수 있습니다.

🚫 1. 왜 if-else 문을 쓰지 않고 when을 쓰는가?

과거 Scripted Pipeline 시절에는 모든 로직을 if (env.BRANCH_NAME == 'main') { ... } else { ... } 형태로 작성했습니다. 언뜻 보면 익숙한 프로그래밍 방식이라 편해 보이지만, 이 방식은 파이프라인 코드가 길어질수록 가독성을 심각하게 훼손합니다. 스테이지 안에 로직이 파묻혀버려, 젠킨스 웹 대시보드의 시각적 UI(Stage View)에서 이 스테이지가 "실행 중 실패한 것인지" 아니면 "조건이 안 맞아서 건너뛴(Skipped) 것인지" 명확히 구분되지 않는 치명적인 단점이 존재했습니다.

Declarative Pipeline은 이러한 문제를 when { ... } 블록으로 우아하게 해결했습니다. stage 블록 내부, steps 블록이 시작되기 직전에 when을 선언하면 젠킨스는 해당 스테이지를 실행하기 전에 조건을 먼저 평가합니다. 조건이 true면 steps를 실행하고, false면 해당 스테이지를 완전히 건너뜁니다(Skip). 웹 대시보드에서도 해당 스테이지가 '건너뜀' 상태로 빗금 처리되어 아주 명확한 시각적 피드백을 제공합니다.

🧩 2. 실무에서 가장 많이 쓰이는 3대 핵심 조건

when 블록 안에는 다양한 조건식(Condition)을 넣을 수 있습니다. 그중 실무 파이프라인의 90% 이상을 차지하는 3가지 핵심 조건을 완벽하게 숙지해야 합니다.

1. branch 조건 (가장 많이 쓰임)

코드가 푸시된 브랜치 이름을 검사합니다. Multibranch Pipeline이나 Github Webhook과 연동할 때 완벽한 궁합을 자랑합니다. 정규표현식(Regex)이나 와일드카드 기호도 지원합니다.

stage('Production Deploy') {
    when {
        // 정확히 main 브랜치일 때만 통과
        branch 'main' 
        
        // 정규표현식: feature- 로 시작하는 브랜치일 때 통과
        // branch pattern: "feature-.*", comparator: "REGEXP"
    }
    steps { sh 'echo "운영 배포 시작!"' }
}

2. expression 조건 (가장 강력함)

Groovy 언어 기반의 어떠한 논리식이라도 넣을 수 있는 만능 조건문입니다. 주로 12단계에서 배운 파이프라인 매개변수(Parameters) 값이나 내장 환경변수를 비교할 때 사용합니다.

stage('E2E Test') {
    when {
        // RUN_E2E 파라미터가 true(체크됨)일 때만 통과. (Groovy 문법이므로 return 필수)
        expression { return params.RUN_E2E == true }
    }
    steps { sh 'npm run test:e2e' }
}

3. changeset 조건 (모노레포의 구세주)

프론트엔드와 백엔드가 하나의 레포지토리에 모여있는 모노레포(Monorepo) 구조에서 구세주 같은 역할을 합니다. 이번 깃 커밋(Git Commit)에서 특정 경로의 파일이 변경되었는지를 감지합니다. 즉, 프론트엔드 코드만 1줄 수정했는데 백엔드 서버까지 굳이 재빌드하는 낭비를 막아줍니다.

stage('Backend Build') {
    when {
        // server/ 폴더 안의 파일이 단 하나라도 수정된 커밋일 경우에만 통과
        changeset "server/**/*"
    }
    steps { sh 'cd server && ./gradlew build' }
}

⚙️ 3. 복합 조건문: allOf, anyOf, not 연산자 활용하기

하나의 조건만으로는 부족한 경우가 많습니다. "main 브랜치이면서, 동시에 배포 환경(TARGET_ENV)이 PROD일 때만"이라는 복잡한 비즈니스 로직을 구현해야 할 때는 논리 연산자 블록을 중첩해서 사용합니다.

• allOf (AND 연산): 내부의 모든 조건이 참(true)이어야만 통과합니다.
• anyOf (OR 연산): 내부의 조건 중 하나라도 참(true)이면 통과합니다.
• not (NOT 연산): 내부의 조건이 거짓(false)일 때 통과합니다.

💻 실무 적용 극강의 예제:

pipeline {
    agent any
    parameters { choice(name: 'ENV', choices: ['DEV', 'PROD']) }
    stages {
        stage('Deploy to Prod') {
            when {
                // main 브랜치 '이면서' ENV 파라미터가 PROD 일 때만 실행하라!
                allOf {
                    branch 'main'
                    expression { return params.ENV == 'PROD' }
                }
            }
            steps {
                echo "🚀 운영 환경 배포를 시작합니다!"
                // sh './deploy.sh prod'
            }
        }
        
        stage('Skip Sandbox') {
            when {
                // 현재 브랜치가 sandbox가 '아닐 때만' 실행하라!
                not { branch 'sandbox' }
            }
            steps {
                echo "샌드박스 브랜치가 아니므로 정상적인 테스트 프로세스를 진행합니다."
            }
        }
    }
}

🎯 4. 마무리 및 다음 단계

지금까지 파이프라인의 생명을 불어넣는 동적 흐름 제어의 마술사, `when` 조건문의 핵심 조건들과 복합 논리 연산자 구성 방법에 대해 3,000자 분량으로 밀도 있게 다루어 보았습니다. 이제 여러분은 개발, 스테이징, 운영 환경 배포를 단 하나의 Jenkinsfile에 우아하게 통합할 수 있는 능력을 갖추게 되었습니다. 불필요한 스테이지를 과감히 건너뛰게 만들면 전체 빌드 시간은 획기적으로 줄어들고 리소스 낭비는 사라집니다.

파이프라인이 when을 통해 역동적으로 흐르다 보면, 어느 스테이지는 통과하고 어느 스테이지는 실패하며 결국 파이프라인의 '최종 상태'가 결정됩니다. 그렇다면 이 최종 결과(성공/실패)에 따라 임시 파일을 청소하거나 담당자에게 슬랙 알림을 쏴주는 작업은 어디에 적어야 할까요? steps 맨 마지막 줄에 적으면 에러가 났을 때 그 줄에 도달하기도 전에 파이프라인이 멈춰버리게 됩니다. 이어지는 14단계 포스팅에서는 모든 결과에 완벽하게 대응하는 자동화의 화룡점정, 'post 섹션을 활용한 빌드 후처리(알림/청소) 기법'에 대해 아주 치밀하게 파헤쳐 보겠습니다!