하나의 젠킨스에 609개 잡과 알파·리얼·베타 환경, 크론·배치까지 몰려 늘 '아픈' 상태였던 NHN의 CI 운영 고민에서 출발한다. 쿠버네티스 이전을 앞두고 새 CI 도구를 탐색하다 결국 다시 젠킨스로 돌아온 여정을, 시행착오와 개선 효과 중심으로 정리한다.
핵심 포인트- 후보로 **Jenkins X**, **Tekton**, **Jenkins on Kubernetes**를 검토했는데, Jenkins X는 온프레미스 로드밸런서 직접 구현 부담으로 보류, Tekton은 젠킨스보다 빌드가 8~10분으로 느리고 리소스 사용이 많아 배제했다.
- 기존 Groovy 파이프라인 코드베이스를 그대로 재사용할 수 있어 **젠킨스 온 쿠버네티스**로 회귀했고, CD는 **Argo CD**의 매니페스트 기반 GitOps로 전환했다.
- 빌드 시에만 에이전트 파드가 동적 생성·삭제되어 24시간 유휴 서버 대비 리소스를 크게 절약했고, 환경별로 젠킨스를 분리하고 배치를 크론잡으로 대체했다.
- **Configuration as Code**(Helm, JCasC, Job DSL)로 플러그인·JDK·에이전트 템플릿·잡 설정을 코드로 강제화해, 재시작 두려움을 없애고 LTS 업데이트를 손쉽게 따라갈 수 있게 됐다.
왜 읽나유행하는 새 CI 도구가 항상 답은 아니며, 익숙한 도구를 쿠버네티스 친화적으로 재구성하는 현실적 선택의 근거를 데이터로 보여준다.