• Aiden's Lab 뉴스레터
  • Posts
  • 🔭빌드 오류에 질려버린 개발자가 만든 Jenkins, 차세대 Jenkins X로 거듭나기까지

🔭빌드 오류에 질려버린 개발자가 만든 Jenkins, 차세대 Jenkins X로 거듭나기까지

Jenkins의 탄생부터 Jenkins X까지의 변천사를 알아봅니다.

Author

Aiden Kim
August 25, 2025

안녕하세요, Aiden’s Lab 뉴스레터입니다.

Jenkins는 현재 2000개가 넘는 플러그인이 개발될 정도로 많이 사용되는 오픈소스 CI(지속적 통합) 플랫폼입니다. 지금의 DevOps와 CI/CD 개념을 탄생시킨 주역 중 하나라고 봐도 무방한데요.

그런 Jenkins가 빌드 에러에 질려버린 어느 한 개발자에 의해 우연히 탄생했다는 사실, 알고 계신가요?

등장 배경부터 변천사, 그리고 차세대 버전인 Jenkins X까지 Jenkins와 관련된 흥미로운 이야기를 가져왔습니다.

Jenkins는 어떻게 탄생했을까?

2004년 Sun Microsystems에 Kohsuke Kawaguchi라는 개발자가 근무하고 있었습니다. 그는 자신이 참여한 개발 프로젝트에서 커밋을 올릴 때마다 빌드가 깨지곤 했었는데요.

계속되는 빌드 오류에 완전히 질려버린 Kohsuke는 Hudson이라는 자동 빌드 서버 프로그램을 만들게 됩니다. 그리고 아마 눈치채셨을 수도 있지만, 이 Hudson이 바로 Jenkins의 전신입니다.

Kohsuke는 자신이 작성한 코드가 실제 레파지토리에 저장되기 전에 문제가 없는지 Hudson을 통해 자동으로 테스트하기 시작했습니다. 이윽고 같이 일하던 팀원들도 Hudson에 관심을 가지게 되었고, Kohsuke는 Hudson을 오픈소스로 공유합니다. 여러 개발자들이 Hudson 개발에 참여하면서 전세계에 알려지기 시작한 것이죠.

사실 Kohsuke는 평소에도 무언가 만드는 것을 좋아해서 아이디어만 있다면 바로 코드로 구현하곤 했다고 합니다. Hudson도 그가 만든 수많은 오픈소스 프로젝트 중 하나였기에, CI 툴에 대해 미리 기획해서 만들었다기 보다는 우연에 가까웠다고 하네요.

Jenkins의 초기 버전인 Hudson의 Web UI

세계에서 가장 유명한 오픈소스 CI/CD 툴이 되기까지

이후 Hudson은 계속 발전하고, 커뮤니티 규모 역시 꾸준히 커져갔습니다. 하지만 시간이 흘러 2010년이 되자 프로젝트 운영에 막대한 영향을 끼친 사건이 일어났는데요. Kohsuke가 재직 중이던 Sun Microsystems가 대기업 Oracle에 인수된 것입니다.

Kohsuke를 포함한 주요 Hudson 개발자들은 Hudson이 기존처럼 계속 오픈소스로 운영될 수 있도록 Oracle에 요구했습니다. 하지만 Oracle은 이에 거절했는데요. 이미 Hudson의 상표권을 등록해서 상업 버전을 개발해 수익화를 준비하고 있던 것입니다.

이에 반발한 Hudson 주요 개발자들은 2011년에 기존의 Hudson을 Jenkins라는 이름으로 바꿨고, Oracle을 나와 Jenkins 프로젝트에 참여하게 됩니다. 지금 우리가 알고있는 오픈소스 Jenkins가 등장한 것이죠.

이후 Jenkins는 커뮤니티에 의해 지금까지 꾸준히 성장해가는데요. 여담으로, Oracle의 Hudson은 비교적 큰 관심은 받지 못한 채 2016년을 기점으로 업데이트가 끊겼고 2020년 운영을 종료하게 됩니다.

반면, 지속해서 발전하던 Jenkins는 2016년 공개한 2.0 버전을 기점으로 커다란 변화를 맞이합니다. 아마 알고계실 수 있지만, Jenkins는 커뮤니티에서 개발한 다양한 플러그인을 설치해서 원하는 기능을 활용할 수 있습니다. 2.0 버전부터 Pipeline이라는 플러그인이 처음 등장하게 된 것인데요.

Pipeline 플러그인이 왜 커다란 변화라는 걸까요? 바로 이 플러그인 덕분에 Jenkins의 자동화 파이프라인을 코드로 구현해서 동작할 수 있게 되었기 때문입니다. 이전까지 Jenkins 파이프라인은 웹 UI에서 구성해야 했는데, 해당 버전부터는 Jenkinsfile이라는 소스코드 파일 안에 프로그래밍 언어(Domain-specific Language, 또는 DSL이라 불리는 언어)로 파이프라인을 구성할 수 있게 된 것이죠.

당시 Jenkinsfile을 처음 소개한 아티클의 Jenkinsfile 코드. 출처: https://www.jenkins.io/2.0

당시 Jenkins 2.0 소개 아티클에서는 복잡한 로직의 파이프라인도 소스코드로 작성하고 실행 및 관리할 수 있는, 이른바 Pipeline as Code를 실현했다고 언급했습니다.

파이프라인을 하나의 프로그래밍 언어로 개발하기 때문에 조직 내에서 공유와 논의가 더욱 쉬워지고, 파이프라인 로직이 코드 형태로 저장되기 때문에 버전 관리도 수월해졌다는 것이 당시 블로그에서 언급한 장점이었는데요.

사실, Pipeline as Code이 가져온 변화는 여기서 끝이 아니었습니다. 이후 Kubernetes와 같은 Cloud Native 환경에서 Jenkins 파이프라인이 동작할 수 있게 된 것도 바로 이 Pipeline as Code 덕분입니다.

소스코드 파일(Jenkinsfile)로 실행 가능한 파이프라인은 Docker 컨테이너 내에서도 실행 가능하단 뜻이므로, 자연스럽게 Kubernetes Pod 내의 컨테이너로 실행하는 Kubernetes 플러그인이 등장할 수 있게 된 초석이 된 것이죠.

Jenkins의 차세대 프로젝트 - Jenkins X

Jenkins가 플러그인을 통해 Kubernetes 환경에서 파이프라인을 구동할 수 있게 되었지만, 클라우드 환경에 좀 더 친화적이고 효율적으로 동작하는 Jenkins를 구현하고자 2018년에 차세대 버전이 공개되었습니다. 바로 Jenkins X가 등장한 것입니다.

Jenkins X는 Kubernetes 환경에 친화적인 구동을 위해 아래 오픈소스 Cloud Native 툴들과 연동하여 동작합니다.

  • Kubernetes: Jenkins X가 설치되는 플랫폼. Jenkins X로 빌드되는 애플리케이션이 배포/실행됨

  • Tekton: Cloud Native 파이프라인 오케스트레이션

  • Kuberhealthy: 시스템의 주기적인 상태 점검(Health Check)을 담당

이렇게 구성요소만 봐도, Jenkins X는 Cloud Native 환경에 특화된 CI/CD 툴이 기본 컨셉임을 알 수 있습니다.

Jenkins X의 아키텍처 소개 이미지. 출처: https://jenkins-x.io/about

Jenkins X 구동에 필요한 Kubernetes 리소스는 Helm으로 구성하고 배포합니다. 이렇게 Helm으로 정의한 리소스 구성 파일은 Git에 저장되며, Jenkins X의 jx-git-operator 컴포넌트가 Git에 저장된 리소스 구성 파일들을 참조해서 자신이 속한 Kubernetes 클러스터에 배포하죠.

즉, 사용자는 Jenkins X 관련 리소스를 수정해야 할 때 Kubernetes 클러스터 내에서 바로 작업하지 않고 Git 레파지토리에 원하는 상태(Desired State)의 리소스 구성 파일을 업로드하기만 하면 되는 것입니다.

이로써 사용자는 Kubernetes 클러스터를 직접 조작해야 하는 부담을 줄일 수 있고, Jenkins X 관련 리소스들의 변경 사항은 Git 레파지토리에서 추적 및 관리가 가능하여 GitOps 방법론에 부합하는 운영이 이루어집니다.

Jenkins를 처음 만든 개발자는?

이렇게 Jenkins의 탄생부터 변천사, 차세대 버전까지 훑어봤는데요. 그렇다면 Jenkins를 처음 만든 Kohsuke는 이후 어떻게 되었을까요?

Kohsuke는 Jenkins 개발 이후 DevOps 솔루션 전문 업체인 CloudBees와 꾸준히 협업해왔습니다. CloudBees는 Jenkins 등의 CI/CD 툴을 이용해 자동화 솔루션을 제공하는 것으로 유명한데요.

2010년 4월에 Kohsuke는 InfraDNA라는 CI 지원 및 서비스 제공 업체를 설립했고, 같은 해 11월에 Cloudbees가 InfraDNA를 인수했습니다. 그리고 2014년에는 Cloudbee에서 CTO로 활동하게 되죠.

이후 2020년 1월에 CTO에서 물러난 다음, Launchable이란 스타트업을 설립해 AI 기반 소프트웨어 테스트 솔루션을 서비스했습니다. 그리고 2024년 8월, Cloudbees가 Launchable을 인수한다는 소식을 발표했죠. Cloudbees가 Kawaguchi의 회사를 또다시 인수한 점이 흥미롭습니다.

마무리

커뮤니티에서 개발된 플러그인만 2000개가 넘고, 세계에서 가장 많이 사용되고 있는 Jenkins는 '자꾸 발생하는 빌드 오류'라는 하나의 문제점(Pain Point)을 해결하기 위해 만들어졌습니다.

Jenkins를 개발한 Kohsuke도 평소에 자신이 만들던 사이드 프로젝트 중 하나가 이렇게 전세계에서 사랑받는 플랫폼이 될 줄은 몰랐다는데요.

  1. 하나의 문제점에 집중하고,

  2. 다양하게 시도하는 것

어떤 분야에서든 제품을 만드는 우리가 잊지 말아야 할 2가지를 이번 Jenkins의 변천사를 통해 되짚어볼 수 있었습니다. 여러분은 지금 어떤 문제점을 해결하기 위해 어떤 시도를 하고 있나요?

그럼 다음 아티클에서 더 흥미로운 주제로 찾아오겠습니다.

감사합니다.

참고 자료

✨이번 뉴스레터는 어떠셨나요?

이번 글에서 다룬 주제에 대해 어떻게 생각하는지 알려주세요! 뉴스레터를 더 나은 방향으로 개선하기 위해 아래 폼에서 짧은 피드백을 받고 있어요.

👉 피드백 보내기 (1~2분 소요)

여러분들의 소중한 의견은 Aiden’s Lab 뉴스레터에게 큰 힘이 됩니다!

🔭Aiden’s Lab에서 더 많은 아티클을 만나보세요

발행된 뉴스레터를 아카이빙하고 다양한 정보를 공유하는 기술 블로그를 운영 중입니다.