[Jenkins] Shared Library: 전사 파이프라인 중복 제거의 마법

우리는 지금까지 하나의 프로젝트를 위한 완벽한 Jenkinsfile을 작성하는 법을 배웠습니다. 환경변수를 세팅하고, Slack 알림을 붙이고, 병렬 빌드까지 최적화했습니다. 그런데 만약 회사가 성장하여 마이크로서비스 아키텍처(MSA)를 도입하게 되고, 관리해야 할 서버가 50개로 늘어난다면 어떻게 될까요? 50개의 프로젝트 레포지토리에 똑같이 생긴 수백 줄짜리 Jenkinsfile을 복사해서 붙여넣기(Copy & Paste) 하실 건가요? 만약 보안팀에서 "내일부터 배포 알림 메시지 포맷을 변경하세요"라고 지시한다면, 50개의 레포지토리를 돌며 일일이 코드를 수정하고 50번의 커밋을 해야 하는 유지보수 지옥이 열립니다. 이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 인프라 관리자를 이 끔찍한 복붙 지옥에서 구원해 줄 '공유 라이브러리(Shared Library)'를 통한 전사 표준 파이프라인 공통화 기법에 대해 3,000자 분량으로 아주 치밀하게 딥다이브 해보겠습니다.

🧩 1. Shared Library(공유 라이브러리)란 무엇인가?

개발자들이 중복되는 코드(API 호출, 날짜 포맷 변환 등)를 하나의 함수로 빼서 utils.js 같은 공통 파일로 관리하는 것(DRY 원칙)처럼, 데브옵스 엔지니어도 파이프라인의 중복되는 로직(Slack 알림 보내기, 도커 빌드하기, 빌드 후 청소하기 등)을 하나의 모듈로 묶어 중앙 집중적으로 관리할 수 있습니다.

젠킨스는 이를 위해 별도의 Git 레포지토리를 파서 거기에 공통 로직(Groovy 스크립트)을 뭉쳐놓고, 각 프로젝트의 Jenkinsfile에서는 그 레포지토리를 import하여 딱 한 줄짜리 함수만 호출해서 쓰게 해주는 Global Shared Library 기능을 제공합니다.

📂 2. Shared Library 디렉토리 구조의 이해

공유 라이브러리로 사용할 새로운 Git 레포지토리(예: my-company-jenkins-lib)를 파고, 아래와 같이 정해진 폴더 구조를 지켜야 합니다.

my-company-jenkins-lib/
├── src/            # (고급) 복잡한 객체지향 Groovy 클래스들이 들어가는 곳
├── vars/           # 🌟 (핵심) 전역 함수(Global Variable)들이 위치하는 곳
│   ├── notifySlack.groovy
│   └── standardPipeline.groovy
└── resources/      # 파이프라인에서 읽어 들일 공통 설정 파일 (예: 빌드 스크립트 템플릿 등)

가장 많이 쓰이는 곳은 vars/ 디렉토리입니다. 이곳에 notifySlack.groovy라는 파일을 만들고 안에 def call() { ... } 함수를 선언하면, 전사 모든 파이프라인에서 notifySlack()이라는 이름의 함수를 글로벌 변수처럼 호출할 수 있게 됩니다.

⚙️ 3. 글로벌 설정과 파이프라인 연동 기법

이 라이브러리를 젠킨스에 등록해 봅시다.

1. [Jenkins 관리] -> [시스템 설정(Configure System)]으로 들어가 Global Pipeline Libraries 섹션을 찾습니다.
2. Name에 my-shared-lib 같은 직관적인 이름을 줍니다. (나중에 Jenkinsfile에서 호출할 식별자입니다.)
3. Default version에 main 브랜치를 입력합니다.
4. Retrieval method에 Git을 선택하고, 방금 만든 공유 라이브러리의 Git 주소를 넣고 저장합니다.

이제 개별 프로젝트의 Jenkinsfile 최상단에 @Library('my-shared-lib') _ 라는 주술 같은 어노테이션(Annotation) 딱 한 줄만 선언하면, 이 젠킨스가 빌드를 시작하기 전에 공유 라이브러리 저장소를 먼저 클론받아 메모리에 싹 올려버립니다. (맨 뒤의 언더스코어 _는 "라이브러리 전체를 즉시 임포트하라"는 그루비 문법입니다.)

💻 4. 실무 적용 극한의 예제 (통합 파이프라인 함수화)

실무에서는 알림 함수 하나만 빼는 것을 넘어서, 아예 파이프라인 전체의 껍데기를 라이브러리에 선언해 버립니다.

1. 공유 라이브러리 (vars/standardNodePipeline.groovy)

// Map 형태로 인자(config)를 받습니다.
def call(Map config) {
    pipeline {
        agent any
        stages {
            stage('Build') {
                steps {
                    echo "${config.projectName} 빌드 중..."
                    sh "npm install && npm run build"
                }
            }
        }
        post {
            always {
                echo "${config.slackChannel} 로 완료 알림 전송!"
            }
        }
    }
}

2. 각 MSA 서비스들의 실제 Jenkinsfile (혁신적인 변화!)

@Library('my-shared-lib') _

// 복잡한 pipeline { ... } 블록은 싹 다 지워버리고, 딱 이거 하나만 남깁니다!
standardNodePipeline(
    projectName: 'payment-api-service',
    slackChannel: '#team-billing'
)

이것이 바로 MSA 환경 데브옵스의 궁극적인 모습입니다. 50개의 서비스가 각자 위처럼 단 5줄짜리 Jenkinsfile만 가지고 있게 됩니다. 만약 새로운 보안 스캔 툴을 도입해서 전사 파이프라인에 적용해야 한다면? 데브옵스 담당자가 중앙의 standardNodePipeline.groovy 파일 딱 한 곳만 수정하면, 50개의 모든 서비스가 다음 빌드부터 자동으로 새로운 보안 스캔을 타게 됩니다. 소름 돋는 유지보수성의 향상입니다.

🎯 5. 마무리 및 다음 단계

지금까지 수십수백 개의 파이프라인 파편화를 방지하고, 단 한 곳에서 전사 배포 정책을 중앙 통제할 수 있게 만들어주는 'Shared Library(공유 라이브러리)'의 막강한 구조와 활용법에 대해 3,000자 분량으로 밀도 높게 다루어 보았습니다. 이 기법을 도입하는 순간 여러분은 일반 젠킨스 사용자를 넘어 전사 인프라 아키텍트의 반열에 오르게 될 것입니다.

자, 파이프라인의 구조도 완벽해졌고 속도도 빨라졌습니다. 하지만 개발자가 짠 코드가 "버그 투성이" 거나 "해킹에 뚫리는 보안 취약점"을 가지고 있다면 아무리 배포를 자동화해 봐야 쓸모가 없습니다. 오히려 쓰레기(Bad Code)를 운영 서버에 아주 빠르게 자동 발사하는 기계로 전락할 뿐입니다. 이어지는 21단계 포스팅에서는 "너 코드 똑바로 안 짰지? 빌드 중단시킬게!"라고 젠킨스가 스스로 코드를 검열하고 빠꾸를 먹이는 정적 코드 분석의 신, 'SonarQube(소나큐브) 품질 게이트 연동법'에 대해 아주 치밀하게 파헤쳐 보겠습니다!