[Jenkins] Artifact(아티팩트) 보관: 롤백을 위한 최후의 구명조끼

파이프라인이 성공적으로 동작하여 수백 메가바이트짜리 .jar 파일이나 프론트엔드 build.zip 파일이 완성되었습니다. 이 결과물을 운영 서버에 쏘아 보내 배포(Deploy)까지 무사히 마쳤습니다. "아싸, 퇴근이다!" 하고 젠킨스를 닫는 순간, 청천벽력 같은 전화가 걸려옵니다.

"방금 배포한 버전에 치명적인 결제 버그가 있습니다! 당장 1시간 전에 배포했던 어제 버전 파일로 롤백(Rollback)해 주세요!!"

만약 여러분이 파이프라인 최하단에 cleanWs()로 워크스페이스를 싹 비워버렸고, 어제 빌드된 .jar 파일을 그 어디에도 백업해두지 않았다면 어떻게 될까요? 옛날 소스코드를 다시 Git에서 Checkout 받아 10분 동안 땀을 뻘뻘 흘리며 재빌드해야 합니다. 그 10분 동안 회사는 수백만 원의 매출 손실을 입게 됩니다.

이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어의 수명과 직결되는 빌드 산출물(Artifact)의 영구 보존 및 다운로드 아카이빙(Archiving) 기법에 대하여 3,000자 분량으로 아주 치밀하게 딥다이브 해보겠습니다.

📦 1. 아티팩트(Artifact) 란 무엇인가?

아티팩트는 '인공물', '가공품'이라는 뜻으로, CI/CD 세계에서는 "소스코드를 컴파일하고 패키징하여 탄생한 최종 실행 가능한 결과물 파일"을 의미합니다. 자바의 .war, .jar, 안드로이드의 .apk, iOS의 .ipa, C++의 .exe 등이 모두 아티팩트입니다.

젠킨스는 빌드를 수행할 때 임시 작업 공간(Workspace)을 사용합니다. 파이프라인이 끝나면 다음 빌드를 위해 이 공간을 깨끗하게 청소(Clean)하는 것이 정석입니다. 따라서 이 공간에 생성된 전리품(아티팩트)을 안전한 별도의 금고 창고에 차곡차곡 쌓아두는 명령어가 반드시 필요합니다.

📥 2. archiveArtifacts 지시어의 위력

Declarative Pipeline에서는 파이프라인이 모든 작업을 끝마친 직후인 post 블록에서 아티팩트를 보관하는 것이 원칙입니다. 성공(Success)했을 때만 유의미한 결과물이 나오므로 success 블록 안에 archiveArtifacts 스텝을 선언합니다.

pipeline {
    agent any
    stages {
        stage('Build Spring Boot') {
            steps {
                echo "메이븐(Maven)으로 컴파일을 시작합니다..."
                sh 'mvn clean package -DskipTests'
            }
        }
    }
    
    post {
        // 빌드가 무사히 성공했을 때만 실행됩니다.
        success {
            // target/ 폴더 밑에 생성된 모든 .jar 파일을 젠킨스 내부 스토리지로 복사(아카이브)합니다.
            archiveArtifacts artifacts: 'target/**/*.jar', 
                             allowEmptyArchive: false, // 파일이 없으면 에러 발생!
                             onlyIfSuccessful: true    // 성공한 빌드에서만 보관
        }
        always {
            // 아카이브(복사)가 끝났으므로 안심하고 워크스페이스의 찌꺼기들을 싹 지워버립니다.
            cleanWs()
        }
    }
}

💡 3. 보관된 아티팩트의 활용과 롤백(Rollback) 시나리오

위 스크립트를 통해 보관된 파일들은 젠킨스 웹 대시보드의 해당 빌드 번호 페이지(예: #42) 중앙에 [Artifacts]라는 예쁜 폴더 아이콘과 함께 노출됩니다. 누구나 브라우저에서 클릭 한 번으로 이 .jar 파일을 다운로드(Download) 받을 수 있습니다.

실무 롤백 시나리오:
운영 서버에 V2 버전 배포가 실패했습니다. 인프라 관리자는 젠킨스에 접속해 어제 성공했던 V1 버전 빌드(예: #41) 페이지로 들어갑니다. 화면에 고스란히 남아있는 V1 아티팩트(.jar)를 수동으로 다운받아 서버에 밀어 넣거나, 별도의 롤백 전용 파이프라인을 만들어 "가장 마지막으로 성공한 빌드(Last Successful Build)의 아티팩트를 끌어와서 덮어씌워라"라고 자동화할 수 있습니다. 이것이 진정한 장애 대응(MTTR 최소화)의 정석입니다.

⚠️ 4. 주의사항: 디스크 폭발 방어 (아티팩트 로테이션)

아티팩트는 보통 수십~수백 MB의 덩치를 자랑합니다. 이를 무한정 보관하면 32단계에서 경고했듯 서버 하드디스크가 터져버립니다. 반드시 파이프라인 상단 options 블록에 artifactNumToKeepStr 설정을 주어, "최근 5개의 아티팩트만 보관하고 오래된 것은 쿨하게 지워라"라는 명령을 병행해야 합니다.

🎯 5. 마무리 및 다음 단계

지금까지 휘발성 작업 공간에서 만들어진 황금 같은 결과물을 영구히 보존하고, 최악의 장애 상황에서 버튼 클릭 하나로 이전 버전의 무기를 꺼내 올 수 있게 해주는 'Artifact 아카이빙 기술'에 대해 3,000자 분량으로 아주 치밀하게 다루어 보았습니다. 이제 여러분은 장애가 터져도 식은땀을 흘리지 않고 커피를 마시며 여유롭게 롤백 버튼을 누를 수 있습니다.

지금까지 우리는 '단일 파이프라인' 안에서 모든 것을 해결해 왔습니다. 하지만 회사가 커져서 "A 앱이 빌드된 후에, 그 결과물을 받아서 B 앱과 C 앱이 동시에 빌드되고, 둘 다 성공하면 통합 배포 파이프라인을 실행하라"는 거대한 오케스트레이션 요구사항이 생기면 어떻게 해야 할까요? 파일 하나에 수천 줄을 짜야 할까요? 이어지는 37단계 포스팅에서는 거대한 파이프라인을 레고 블록처럼 작게 쪼개어 연쇄적으로 호출하는 폭포수 아키텍처, 'Upstream / Downstream Job 연결 마스터 가이드'에 대해 아주 뼈 때리는 실무 노하우와 함께 파헤쳐 보겠습니다!