Jenkins 이주가 7개월 걸린 이유 — 그리고 다른 3개사는 왜 안 그랬나

지난 18개월 동안 4 고객사를 Jenkins 에서 우리 시스템으로 옮겼다. 3개는 예상대로 끝났다 — 6주, 9주, 11주. 4번째는 7개월 걸렸다.

그 차이는 파이프라인의 복잡도 가 아니었다. 4번째 고객의 파이프라인은 오히려 가장 단순했다. 차이는 Jenkins 가 외부에 안 보이게 보관해 온 5가지 였다.

1. 공유 라이브러리 (Shared Library)

Jenkins 의 Shared Library 는 내부 Groovy DSL 이다. vars/ 폴더에 deployToK8s.groovy 같은 파일이 들어가면, 모든 파이프라인에서 deployToK8s(env: 'prod') 로 호출된다.

문제는 이게 코드가 아니라 매크로 라는 점이다. 정적 분석이 안 된다. 어떤 파이프라인이 어떤 매크로를 쓰는지가 런타임에만 드러난다.

4번째 고객사는 47 개의 shared library 함수가 있었다. 이주 첫 달에 우리가 발견한 건 23 개. 7개월 후 발견한 건 41 개. 마지막 6 개는 분기 1회 도는 야간 배포 잡에서만 호출됐고, 그래서 우리도, 고객도, 그것의 존재를 몰랐다.

2. 플러그인 DAG

Jenkins 의 진짜 형태는 파이프라인이 아니라 플러그인 의존 그래프 다. 평균적인 엔터프라이즈 Jenkins 인스턴스는 40~80 개 플러그인을 갖고 있다. 그중:

• 절반은 누가 왜 깔았는지 모름
• 1/3 은 1년 이상 업데이트 X
• 1/4 는 무료 라이선스가 만료 됐거나 원본 메인테이너가 사라짐

4번째 고객사는 73 개 플러그인. 중 11 개가 deprecated, 4 개가 문서가 없는 사내 fork. 이주 = 73 개 각각이 어떤 행동을 만드는지 분석해서 새 시스템에 어떤 매핑 으로 들고 갈지 결정. 이건 파이프라인 변환 이 아니라 역공학 이다.

3. 자격 증명 (Credentials)

Jenkins 의 credentials store 는 암호화된 XML 트리 다. 사람이 직접 읽을 수도, 자동으로 export 할 수도 있다 — 다만 암호화 키가 그 인스턴스에만 있다.

이주를 결심한 시점에서 시계가 시작된다 — 고객사가 각 자격을 어디서 발급받은 정확한 날짜 를 기억하지 못하면, 모든 자격을 다시 발급 받아야 한다. 4번째 고객사는 119 개 자격이 있었고, 원본 발급자 를 기억하는 사람이 7 개에 대해서만 있었다. 나머지 112 개는 보안팀이 전수 회전 을 결정했다. 그게 2 개월.

4. 파이프라인 그 자체보다, 파이프라인이 가정한 환경

Jenkins 의 declarative pipeline 은 얼핏 코드처럼 생겼다. Jenkinsfile 안에 들어 있고, git 에 있다.

pipeline {
    agent { label 'linux-arm64-fast' }   // ← 어디서 정의됐는가?
    environment {
        REGISTRY = "${REGISTRY_PROD}"     // ← global 환경변수, 어디서?
    }
    ...
}

저 두 줄은 Jenkins 인스턴스의 외부 상태에 의존 한다. 에이전트 라벨은 어디서 정의됐고, 어떤 머신에 매핑되어 있는가. REGISTRY_PROD 는 시스템 환경변수인가, Jenkins UI 에서 설정한 변수인가, plugin 이 주입한 변수인가.

이걸 재현하지 않으면 빌드는 단 한 번도 같은 결과를 내지 않는다. 4번째 고객사는 에이전트가 수동으로 패치된 상태였고, 그 패치가 어떤 빌드를 동작시키는 데 결정적이었다. 그 패치를 찾는 데 3주.

5. 사람의 습관

이게 가장 비싸다. Jenkins UI 의 재실행 버튼, 빌드 히스토리 페이지의 콘솔 출력 무한 스크롤, 수동 트리거 의 빨간 버튼. 이 습관들이 조직 운영의 일부 가 되어 있다.

새 시스템으로 옮기면, 운영자는 같은 동작을 다른 위치 에서 해야 한다. 이건 트레이닝이 아니라 근육 기억의 재학습 이다. 4번째 고객사는 운영팀이 12명이었고, 6명이 3개월 안에 새 UI 에 적응했다. 나머지 6명은 6개월 걸렸다. 그 6개월 동안 두 시스템을 병행 해야 했다.

4 고객사의 차이

순조로웠던 3 고객사의 공통점 — 모두 Jenkins 를 1년 이내 에 도입했고, 같은 사람이 도입과 이주를 모두 책임졌다. 외부에 안 보이게 보관된 가정들이 그 사람의 머릿속 에 있었다.

4번째 고객사는 Jenkins 를 7년 운영했고, 3번의 운영팀 교체 를 거쳤다. 머릿속의 가정이 문서가 아니라 사람과 함께 사라진 상태였다.

어떻게 7개월짜리를 피하나

이주 결정 전에 다음 다섯을 점검:

1. shared library 함수 사용 빈도 그래프 — 1년에 1회 도는 함수까지 모두
2. 플러그인 DAG 의 deprecated / unmaintained 플래그
3. 자격 발급자의 기록 가능성
4. 에이전트 노드의 재현 가능성 — 불변 이미지에서 부팅되는가
5. 운영팀의 근속 연수 — 평균 < 2년이면 가정의 절반은 사라진 상태

이 다섯이 모두 깨끗 하면 6~12 주. 하나라도 검은 박스면 분기 단위 일감.

그래서 Jenkins 이주는 언제 하는 게 맞나

Jenkins 이주의 맞는 타이밍은 위 다섯 가지 점검 (shared library 사용 빈도, 플러그인 DAG, 자격 발급 기록, 에이전트 재현 가능성, 운영팀 근속) 을 돌린 다음이지, 그 전이 아니다. 지금 검토 단계에 있는 엔지니어링 리드라면, 이 점검이 7개월짜리를 6주짜리로 줄여주지는 않는다. 하지만 어느 쪽에 서명하는지 미리 알 수는 있다. 가장 비싼 건 모르는 채로 시작하는 것이다.