[Jenkins] Timestamps: 눈먼 로그에 생명력을 불어넣는 시간의 마법

파이프라인이 실패하여 원인을 찾기 위해 젠킨스의 Console Output(콘솔 출력) 화면을 열었습니다. 까만 바탕에 흰 글씨로 찍힌 10만 줄의 로그를 스크롤 하다가 Error: Connection timeout 이라는 문구를 발견했습니다. 그런데 이 에러가 도대체 몇 시 몇 분에 발생한 것인지, 그리고 이 앞의 npm install 스텝에서 도대체 몇 분 동안이나 시간을 끌다가 에러가 난 것인지 알 턱이 없습니다. 기본 젠킨스 로그는 그저 명령어의 결과 텍스트만 차가운 콘솔에 주르륵 뱉어낼 뿐, 어떠한 시간 정보(Time Context)도 제공하지 않기 때문입니다.

이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 엔지니어의 디버깅 시간을 10배 단축시키고, 파이프라인의 병목(Bottleneck) 구간을 직관적으로 찾아내게 해 주는 'Timestamps 플러그인의 완벽한 적용과 빌드 로그 가독성 혁신 기법'에 대하여 다뤄보겠습니다.

盲 1. 시간 없는 로그의 치명적인 한계

파이프라인 전체 실행 시간이 평소 5분에서 오늘 갑자기 30분으로 늘어났다고 가정해 봅시다. 어디서 25분이 더 걸린 걸까요? 타임스탬프가 없다면 10단계로 이루어진 파이프라인 중 어느 구간이 범인인지 절대 알 수 없습니다.

또한, 새벽에 발생한 간헐적인 데이터베이스 커넥션 타임아웃 에러를 추적할 때도, 로그에 찍힌 에러가 "새벽 3시 정각(DB 백업이 도는 시간)"에 발생한 것인지, "새벽 3시 15분"에 발생한 것인지 시간을 정확히 매칭할 수 없다면 원인 분석(Root Cause Analysis) 자체가 불가능해집니다. 시간은 디버깅의 가장 중요한 단서입니다.

⏱️ 2. Timestamps 플러그인과 옵션 선언

이러한 답답함을 단 한 줄의 코드로 완벽하게 해결해 주는 것이 바로 Timestamps 플러그인입니다. 젠킨스 플러그인 관리에서 Timestamper를 설치하고 나면, 파이프라인의 options 블록에 마법의 주문을 적어 넣을 수 있습니다.

pipeline {
    agent any
    
    // 🌟 이 한 줄이 콘솔 로그의 가독성을 180도 바꿔놓습니다.
    options {
        timestamps() 
    }
    
    stages {
        stage('Install Dependencies') {
            steps {
                // 이전 로그: npm install 시작...
                // 변경 로그: [2024-03-15T04:22:10.123Z] npm install 시작...
                echo "npm install 시작..."
                sh 'npm install'
                
                // 이전 로그: npm install 완료!
                // 변경 로그: [2024-03-15T04:25:40.555Z] npm install 완료!
                // (관리자 생각: 아~ 여기서 정확히 3분 30초나 걸렸구나!)
                echo "npm install 완료!"
            }
        }
    }
}

💡 3. 실무 활용 노하우: 경과 시간(Elapsed Time) 분석

위와 같이 timestamps()를 선언하면 콘솔 화면 왼쪽 끝에 항상 날짜와 시간이 찍힙니다. 하지만 실무에서 우리가 진짜 궁금한 것은 "지금 몇 시인가?"보다 "앞의 명령어와 뒤의 명령어 사이의 '시간 차이(경과 시간)'가 얼마나 되나?"입니다.

젠킨스 클래식 UI의 콘솔 출력(Console Output) 화면 우측 상단을 자세히 보시면 [Timestamps 설정 톱니바퀴 아이콘]이 숨어있습니다. 이 아이콘을 클릭하여 'Elapsed time' (경과 시간) 모드로 변경해 보십시오. 그러면 로그 좌측의 텍스트가 절대 시간(시:분:초)에서, 빌드가 시작된 지 "00:03:15 소요", "00:08:42 소요" 같은 스톱워치(Stopwatch) 형태의 누적 시간으로 싹 바뀝니다. 이를 통해 "아, 특정 sh 스크립트 하나가 5분이나 잡아먹었네?" 하고 병목 구간(Bottleneck)을 1초 만에 시각적으로 찾아낼 수 있습니다.

🎯 4. 마무리 및 다음 단계

지금까지 그동안 까막눈처럼 바라보던 텍스트 덩어리 로그에 '시간'이라는 축을 부여하여 직관적인 프로파일링 도구로 변모시키는 'Timestamps()' 옵션의 위대함에 대해 다루어 보았습니다. 단 한 줄의 코드이지만, 이 옵션이 없는 파이프라인은 실무에서 디버깅이 불가능한 반쪽짜리 자동화일 뿐입니다.

시간을 찍어보니 어떤 명령어가 오래 걸리는지 알게 되었습니다. 그런데 로그를 분석하다 보니 억울한 실패가 너무 많습니다. 사내 프라이빗 레지스트리의 네트워크가 딱 1초 끊겨서 npm install이 타임아웃 났고 그 탓에 30분짜리 전체 빌드가 허무하게 실패(Failure) 처리된 것입니다. "아, 그냥 한번 껐다 켜면(다시 실행하면) 되는 건데 이걸 수동으로 다시 눌러야 해?" 이어지는 31단계 포스팅에서는 일시적인 네트워크 지연이나 외부 API 장애 앞에서 무너지지 않고 오뚝이처럼 스스로 다시 일어서는 극강의 회복 탄력성, 'Retry(재시도) 블록의 완벽한 통제 기법'에 대해 아주 치밀하게 파헤쳐 보겠습니다!