[Jenkins] Input Step: 상용 배포 전 수동 승인(결재) 결계 치기

"CI/CD 자동화가 너무 완벽하게 구축된 나머지, 누군가 실수로 main 브랜치에 올린 불량 코드가 5분 만에 전 세계 고객이 접속 중인 운영 서버(Production)에 꽂혀버렸다." 이는 구글, 아마존 같은 빅테크에서도 종종 벌어지는 악몽 같은 장애 시나리오입니다. 개발(Dev) 서버나 스테이징(Staging) 환경까지는 코드가 푸시되는 즉시 100% 논스톱 자동 배포가 이루어지는 것이 맞습니다. 하지만 회사의 명운이 달린 운영 상용 배포 앞에는 반드시 '책임자의 눈과 버튼 승인'이라는 휴먼 브레이크 장치가 필요합니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 질주하는 파이프라인을 잠시 일시 정지(Pause)시키고, 권한을 가진 자만이 문을 열어줄 수 있게 만드는 강력한 'Input Step 수동 승인 제어 기법'에 대하여 3,000자 분량으로 아주 치밀하게 딥다이브 해보겠습니다.

🛑 1. Input Step 이란 무엇인가?

파이프라인의 특정 steps 안에 input이라는 명령어를 선언해두면, 젠킨스는 코드를 한 줄씩 실행하며 내려오다가 input을 만나는 순간 마법처럼 파이프라인의 시간을 멈춥니다(Suspend).

그리고 젠킨스 웹 UI나 Blue Ocean 대시보드 화면 한가운데에 팝업창을 띄워놓고 "배포할까요?"라고 묻습니다. 이때 관리자가 Proceed(진행) 버튼을 누르면 멈춰있던 파이프라인이 다시 숨을 쉬며 다음 줄의 코드(배포 스크립트)를 실행하고, Abort(중단) 버튼을 누르면 그 즉시 파이프라인을 실패 처리하고 종료시킵니다.

⚠️ 2. 무한 대기의 늪: Timeout과의 영혼의 단짝 결합

초보자들이 input을 쓸 때 저지르는 가장 흔하고 치명적인 실수가 있습니다. 승인 팝업만 띄워놓고 그대로 퇴근해 버리는 것입니다. 팀장님도 휴가를 가서 아무도 버튼을 눌러주지 않는다면 어떻게 될까요?

그 젠킨스 Job은 서버의 프로세스와 메모리를 점유한 채 영원히, 10년이 지나도 멈춰서 기다리게 됩니다. 이런 좀비 빌드들이 수십 개 쌓이면 결국 젠킨스는 리소스 고갈로 뻗어버립니다. 따라서 input 스텝은 반드시 timeout(타임아웃) 블록으로 감싸주어, "1시간 안에 응답이 없으면 자동 취소(Abort)하라"는 방어 로직을 필수로 구성해야 합니다.

🔐 3. 권한 제어: 아무나 승인 버튼을 누를 수 없게 만들기

승인 버튼을 띄웠는데, 방금 입사한 신입 사원이 "이 버튼은 뭐지?" 하고 눌러서 운영에 배포돼버린다면 승인 창을 만든 의미가 없습니다. input 명령어는 submitter라는 강력한 옵션을 제공하여, 젠킨스 시스템에 등록된 특정 유저(예: admin) 혹은 특정 그룹(예: dev-leaders)에 속한 사람만 버튼을 클릭할 수 있도록 완벽하게 접근 제어(RBAC)를 설정할 수 있습니다.

💻 4. 실무 적용 극한의 예제 파헤치기

Timeout과 권한 제어, 그리고 심지어 승인 시 추가적인 런타임 매개변수(Parameter)까지 동적으로 입력받아 분기 처리하는 최고 수준의 실무 예제 코드를 분석해 봅시다.

pipeline {
    agent any
    stages {
        stage('Build & Test') {
            steps { echo '코드를 빌드하고 Staging 서버 테스트까지 모두 마쳤습니다!' }
        }
        
        stage('Approval for Production Deploy') {
            steps {
                // 1. 무한 멈춤을 방지하기 위해 1시간의 제한 시간을 둡니다.
                timeout(time: 1, unit: 'HOURS') {
                    script {
                        // 2. input을 변수(userInput)에 담으면, 팝업에서 선택한 값을 받아올 수 있습니다.
                        def userInput = input(
                            message: '🚨 운영 서버(Production)에 배포를 진행할까요?', // 팝업창 제목
                            ok: '네, 배포를 승인합니다!', // 진행 버튼 텍스트 변경
                            submitter: 'admin, dev_team_lead', // 특정 권한을 가진 자만 클릭 가능
                            parameters: [
                                // 승인 버튼을 누를 때 추가 옵션을 물어봅니다.
                                choice(name: 'DEPLOY_MODE', choices: ['CANARY', 'BLUE_GREEN'], description: '배포 전략을 선택하세요')
                            ]
                        )
                        
                        // 사용자가 선택한 값을 환경변수로 등록하여 다음 스테이지에서 쓰게 만듭니다.
                        env.CHOSEN_MODE = userInput
                    }
                }
            }
        }
        
        stage('Deploy to Production') {
            steps {
                echo "✅ 승인이 완료되었습니다. 선택하신 전략(${env.CHOSEN_MODE})으로 상용 배포를 가동합니다!"
                // sh "./deploy-prod.sh --mode=${env.CHOSEN_MODE}"
            }
        }
    }
}

🎯 5. 마무리 및 다음 단계

지금까지 폭주하는 자동화의 굴레에 안전장치를 채우고, 책임 소재를 명확히 하며 서버 리소스를 보호하는 가장 우아한 승인 결계, 'Input Step'의 완벽 활용법에 대해 3,000자 분량으로 밀도 높게 다루어 보았습니다. 이 기법 하나로 여러분의 파이프라인은 신뢰할 수 없는 자동화 기계에서 신중하고 든든한 동료로 격상되었습니다.

파이프라인을 이토록 완벽하게 깎아놓았는데, 만약 내일 아침 출근했더니 AWS 장애로 젠킨스 서버의 하드디스크가 통째로 날아갔다면 어떻게 될까요? 수백 개의 Job 설정 파일과 파이프라인 히스토리, 암호화된 Credentials까지 모두 영원히 사라져 버리는 대참사가 일어납니다. 복구에만 꼬박 일주일이 걸릴지도 모릅니다. 이어지는 25단계 포스팅에서는 서버가 불타 없어져도 3분 만에 어제 상태 그대로 젠킨스를 살려내는 궁극의 방어구, 'Jenkins 백업 스크립트 작성 및 자동화 노하우'에 대해 아주 뼈 때리는 생생한 경험담과 함께 파헤쳐 보겠습니다!