[Jenkins] 공유 라이브러리 심화: 글로벌 vs 폴더 라이브러리 완벽 분리 전략

20단계에서 우리는 slackNotify(), buildDocker()와 같은 공통 함수들을 뽑아내어 재사용하는 '공유 라이브러리(Shared Library)'의 마법을 맛보았습니다. 이 신세계를 접한 여러분의 회사는 젠킨스 [관리 설정] 메뉴에 'Global Pipeline Libraries'를 떡하니 등록하고, 모든 부서(결제팀, 회원팀, 정산팀)가 이 공용 라이브러리 하나를 끌어다 쓰기 시작했습니다. 그런데 어느 날, 회원팀의 신입 데브옵스 엔지니어가 도커 빌드 함수 로직을 살짝 수정하고 커밋(Commit)했습니다. 그 순간, 회원팀뿐만 아니라 결제팀, 정산팀 등 회사 내의 모든 200개 파이프라인이 동시에 줄줄이 빨간불을 뿜으며 빌드 실패로 폭발해버렸습니다! 글로벌(전역) 변수의 무서움을 뼈저리게 깨닫는 순간입니다.

이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 "하나의 거대한 도구함(Global)을 쓰다 터지는 대형 사고를 막고, 팀별로 프라이빗한 도구함(Folder)을 지급하는" 공유 라이브러리 격리 설계 아키텍처에 대하여 다뤄보겠습니다.

🌍 1. Global Library의 명암(Light and Shadow)

[Jenkins 관리] -> [System Configuration] 메뉴에서 등록하는 Global Pipeline Libraries는 가장 직관적이고 강력합니다. 전사의 모든 Jenkinsfile 최상단에 @Library('my-global-lib') _ 한 줄만 적으면 누구나 공통 함수를 쓸 수 있습니다.

하지만 영향 범위(Blast Radius)가 전사적이라는 것이 치명적인 단점입니다. 공용 함수의 파라미터 하나만 잘못 바꿔도 회사의 모든 배포가 마비됩니다. 또한 젠킨스 마스터 권한을 가진 시스템 관리자만이 이 글로벌 라이브러리 세팅을 만질 수 있기 때문에, 일개 개발팀이 "우리 팀만 쓸 커스텀 함수 좀 라이브러리에 추가해 주세요"라고 할 때마다 관리자에게 티켓을 끊고 결재를 받아야 하는 엄청난 병목(Bottleneck)이 발생합니다.

📁 2. 구원자: Folder-level Shared Library

이러한 권한 문제와 폭발 위험을 막기 위해 젠킨스 Folder 플러그인이 등장합니다. 젠킨스 메인 화면에서 New Item을 누르고 Folder 타입으로 'Payment-Team' 이라는 폴더를 만듭니다. 결제팀의 모든 Job(A-api, B-web 등)은 이 폴더 안으로 이사시킵니다.

그리고 놀랍게도, 이 'Payment-Team' 폴더를 클릭하고 좌측의 [Configure(구성)] 메뉴에 들어가 보면 저 아래에 Folder Properties -> Pipeline Libraries 설정 칸이 숨어있습니다!

결제팀 전용 Github 레포지토리(예: payment-shared-lib.git)를 이곳에 등록하고 payment-lib이라는 이름을 붙여줍니다. 이제 이 폴더 안에 있는 Job들만 해당 라이브러리를 쓸 수 있습니다. 회원팀 폴더에 있는 Job이 @Library('payment-lib') _을 적어봤자 젠킨스는 "그런 라이브러리 모름" 하고 에러를 뱉어냅니다. 완벽한 격리(Isolation)가 달성된 것입니다.

💻 3. 실무 하이브리드 아키텍처 코드 예제

가장 이상적인 대기업 실무 세팅은 '글로벌'과 '폴더'를 동시에 섞어 쓰는 하이브리드(Hybrid) 방식입니다. 전사 공통 로직(슬랙 알림 템플릿, 사내망 방화벽 우회 로직 등)은 Global Library에 두고 관리자가 꽉 잡습니다. 반면 팀별 커스텀 배포 로직(결제팀만의 독특한 DB 마이그레이션 함수 등)은 Folder Library에 두고 각 팀장에게 권한을 위임합니다.

// 1. 관리자가 등록해 둔 전사 공용 라이브러리 임포트 (Slack, SonarQube 등)
@Library('corp-global-lib') _

// 2. 결제팀 폴더에만 등록된 결제팀 전용 프라이빗 라이브러리 임포트
@Library('payment-team-lib') _

pipeline {
    agent any
    stages {
        stage('Database Migration') {
            steps {
                // 결제팀 라이브러리에 정의된 팀 전용 커스텀 함수 실행!
                // 이 함수 코드를 수정해도 회원팀 파이프라인에는 1도 영향을 주지 않습니다.
                paymentDbMigrate(target: 'PROD', fallback: true)
            }
        }
        stage('Notify') {
            steps {
                // 전사 공통 라이브러리 함수를 사용하여 사내 표준 양식으로 슬랙 발송
                corpStandardSlackNotify(status: 'SUCCESS')
            }
        }
    }
}

🎯 4. 마무리 및 다음 단계

지금까지 글로벌 라이브러리가 가진 "수정 한 번에 전사 마비"라는 시한폭탄의 스위치를 제거하고, 폴더 단위 라이브러리 할당을 통해 각 개발팀에게 자율성(Autonomy)과 안전성(Safety)을 동시에 부여하는 'Shared Library Scope 아키텍처'에 대해 다루어 보았습니다. 이 셋업을 마친 당신은 진정한 사내 플랫폼 엔지니어(Platform Engineer)입니다.

파이프라인 로직도 완벽하고, 권한 분리도 끝났고, 라이브러리도 깔끔합니다. 그런데 회사가 더 성장해서 하루에 파이프라인이 500개씩 동시에 돕니다. 젠킨스 서버 한 대가 메모리 100%, CPU 100%를 치면서 비명을 지르다가 장렬하게 서버가 다운(Down)되어 버렸습니다. 단일 서버의 물리적 한계에 부딪힌 것입니다! 이어지는 39단계 포스팅에서는 "마스터는 지시만 하고, 뼈 빠지는 노동은 수백 대의 노예(Agent) 머신들이 나누어서 병렬 처리한다!" 엔터프라이즈 확장의 꽃, 'Jenkins Master-Slave(Agent) 분산 빌드 아키텍처 완벽 이해'에 대해 아주 뼈 때리는 실무 노하우와 함께 파헤쳐 보겠습니다!