[Jenkins] Discard Old Builds: 디스크 용량 폭발을 막는 자동 청소부

CI/CD 자동화를 성공적으로 안착시키고 나면 하루에도 수십, 수백 번의 빌드가 젠킨스 서버에서 수행됩니다. 팀원들은 클릭 한 번으로 배포되는 쾌감에 취해 끊임없이 파이프라인을 돌려댑니다. 그렇게 6개월 평화로운 시간이 흐른 어느 날, 젠킨스 웹 접속이 갑자기 튕기며 HTTP ERROR 500을 뿜어냅니다. 다급하게 서버 터미널에 접속해 df -h 명령어로 용량을 조회해 보는 순간 눈을 의심하게 됩니다. "사용량(Use%) 100% - No space left on device". 젠킨스의 /var/jenkins_home/jobs 디렉토리 아래에 지난 6개월간 쌓인 수만 개의 텍스트 빌드 로그와 거대한 .jar 아티팩트 파일들이 테라바이트(TB) 단위로 하드디스크를 가득 채워 서버가 질식사해 버린 것입니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 "과거의 쓰레기를 영원히 품고 사는 젠킨스의 나쁜 버릇"을 강제로 교정하여, 서버 용량 폭주를 원천 차단하는 'Discard Old Builds (로그 로테이션) 영구 설정법'에 대하여 다뤄보겠습니다.

🗑️ 1. 왜 젠킨스는 스스로 청소하지 않는가?

젠킨스의 기본 사상은 '보존(Preservation)'입니다. 당신이 별도의 설정을 명시하지 않는 한, 젠킨스는 #1번 빌드부터 방금 끝난 #5000번 빌드까지의 모든 콘솔 로그 텍스트, 플러그인 결과, 심지어 archiveArtifacts로 보관한 수십 MB짜리 압축 파일들을 영원히 디스크에 저장합니다.

하지만 냉정하게 생각해 봅시다. 1년 전 #42번 빌드가 성공했는지 실패했는지 로그를 다시 열어볼 일이 실무에서 단 한 번이라도 있을까요? 전혀 없습니다. 기껏해야 최근 일주일 내의 빌드 로그, 혹은 가장 최근에 성공한 10~20개 정도의 빌드 이력만이 디버깅을 위해 유의미한 가치를 가질 뿐입니다. 나머지는 그저 값비싼 클라우드 스토리지 비용을 낭비하는 거대한 디지털 쓰레기통에 불과합니다.

⚙️ 2. buildDiscarder 블록의 강력한 문법

이 재앙을 막기 위해 젠킨스는 Declarative Pipeline의 options 블록 안에 buildDiscarder (빌드 폐기)라는 아주 직관적이고 강력한 지시어를 제공합니다. 이를 통해 '개수 기준(Count-based)' 또는 '날짜 기준(Time-based)'으로 자동 청소 룰을 세팅할 수 있습니다.

pipeline {
    agent any
    
    // 🌟 실무 파이프라인의 숨겨진 필수 방어막 (로그 로테이션)
    options {
        // 방법 1: "최근 30개의 빌드 이력만 남기고, 31번째 과거 빌드는 영구 삭제해라!" (가장 추천)
        buildDiscarder(logRotator(numToKeepStr: '30'))
        
        // 방법 2: "몇 개가 쌓이든 상관없고, 무조건 14일(2주)이 지난 낡은 빌드 이력은 삭제해라!"
        // buildDiscarder(logRotator(daysToKeepStr: '14'))
        
        // 방법 3 (고급 실무 조합): "최대 30일치를 보관하되, 개수가 100개를 넘어가면 30일이 안 지났어도 오래된 순으로 삭제해라!"
        // buildDiscarder(logRotator(daysToKeepStr: '30', numToKeepStr: '100'))
    }
    
    stages {
        stage('Build') {
            steps { echo "이 빌드 로그도 30번 뒤에는 깔끔하게 지워집니다." }
        }
    }
}

💾 3. 아티팩트(Artifact) 분리 폐기 전략

텍스트로 된 콘솔 로그 용량은 사실 애교 수준입니다. 진짜 디스크를 박살 내는 주범은 빌드 산출물(.war, .zip, 도커 tar 파일)을 보관하는 아티팩트(Artifact)입니다. 텍스트 로그는 100개를 남겨서 히스토리를 보고 싶지만, 500MB짜리 거대한 파일은 가장 최근 5개만 남기고 다 지워버리고 싶을 수 있습니다. 이때 artifactNumToKeepStr 옵션을 추가로 사용합니다.

options {
    // 텍스트 빌드 로그와 히스토리는 최근 100개를 보존하되, 
    // 디스크를 많이 먹는 거대한 아티팩트(첨부파일)는 최근 5개 빌드분만 남기고 싹 삭제해라!
    buildDiscarder(logRotator(numToKeepStr: '100', artifactNumToKeepStr: '5'))
}

이 한 줄의 코드가 여러분 회사의 연간 클라우드 EBS 스토리지 비용 수백만 원을 절약해 줄 것입니다.

🎯 4. 마무리 및 다음 단계

지금까지 과거에 집착하는 젠킨스의 기본 습성을 교정하여, 수 기가바이트의 낡은 로그와 아티팩트를 쿨하게 폐기하고 디스크 용량을 영구적으로 클린하게 유지하는 'buildDiscarder' 옵션의 극한 활용법에 대해 다루어 보았습니다. 내가 만든 파이프라인 최상단에 이 options 블록이 빠져있지 않은지 당장 내일 출근해서 확인해 보시기 바랍니다.

이제 인프라의 안정성과 용량 관리는 무적에 가까워졌습니다. 하지만 최근 데브옵스 트렌드는 '속도'와 '안정성'을 넘어 '보안(Security)'으로 진화하고 있습니다. 이른바 DevSecOps의 시대입니다. 우리가 구워낸 예쁜 도커 이미지 안에 만약 해커들이 뚫어놓은 치명적인 리눅스 커널 백도어가 숨어있다면 어떨까요? 이어지는 33단계 포스팅에서는 "보안 스캔에 걸리면 배포를 그 자리에서 폭파시켜 버린다!" 컨테이너 보안 스캐너의 절대 강자 'Trivy(트리비) 연동 및 취약점 방어 자동화'에 대해 아주 치밀하게 파헤쳐 보겠습니다!