1. Jenkins란 무엇인가
1.1 Jenkins의 정의
Jenkins는 소프트웨어 개발 과정에서 반복적으로 수행되는 작업을 자동화하기 위한 오픈소스 자동화 서버다.
가장 대표적으로는 다음 작업을 자동화하는 데 사용됨.
- 소스코드 가져오기
- 빌드 수행
- 테스트 실행
- 아티팩트 생성
- 배포 스크립트 실행
- 파이프라인 상태 확인
- 결과 알림
즉, Jenkins는 단순히 코드를 컴파일하는 도구가 아니라,
소스 변경부터 배포 전후 작업까지 연결하는 자동화 플랫폼으로 이해하는 것이 맞음.
1.2 Jenkins가 필요한 이유
초기 개발 환경에서는 개발자가 직접 다음 작업을 수행하는 경우가 많았음.
- Git 저장소에서 코드 내려받기
- 빌드 명령 실행
- 테스트 실행
- 결과 파일 생성
- 서버에 복사해서 실행
이 방식은 규모가 작을 때는 가능하지만, 협업 인원이 늘고 변경이 많아질수록 한계가 분명해짐.
대표적인 문제는 다음과 같음.
- 누가 언제 어떤 버전을 빌드했는지 기록이 흐려짐
- 사람마다 다른 명령어를 실행할 수 있음
- 테스트를 누락할 수 있음
- 특정 PC에서만 되는 빌드가 생길 수 있음
- 반복 작업이 많아져 생산성이 떨어짐
Jenkins는 이런 문제를 해결하기 위해 정해진 절차를 서버에서 일관되게 자동 실행하도록 만들어줌.
2. Jenkins의 역할
Jenkins는 CI/CD 파이프라인 전체에서 여러 역할을 수행할 수 있음.
조직마다 활용 범위는 다르지만, 보통 다음 역할로 설명할 수 있음.
2.1 CI 실행 엔진
가장 기본적인 역할은 CI 자동화다.
예를 들면 다음과 같은 흐름이다.
- 개발자가 GitHub에 코드를 push함
- Jenkins가 변경을 감지함
- 저장소에서 코드를 가져옴
- 빌드 수행
- 테스트 수행
- 결과를 저장하고 성공/실패를 표시함
이 구조에서 Jenkins는 CI 파이프라인의 실행 주체가 된다.
2.2 CD 파이프라인 제어 도구
Jenkins는 빌드까지만 하는 것이 아니라, 배포 단계까지 연결할 수 있음.
예:
- Docker 이미지 생성
- 레지스트리 업로드
- 원격 서버에 배포 스크립트 실행
- Kubernetes 배포 명령 실행
- Helm 배포 수행
즉, Jenkins는 CI뿐 아니라 CD까지 이어지는 자동화 흐름을 제어하는 중심 도구가 될 수 있음.
2.3 오케스트레이션 서버
Jenkins는 하나의 명령만 실행하는 도구가 아니라, 여러 단계를 순서대로 실행하고 조건에 따라 분기하는 오케스트레이션 역할도 한다.
예를 들면 다음처럼 구성할 수 있음.
- Build 성공 시에만 Test 실행
- Test 성공 시에만 Docker Build 실행
- main 브랜치일 때만 Release Job 실행
- 운영 배포 전 승인 단계 대기
즉, Jenkins는 단순 명령 실행기가 아니라 절차를 정의하고 제어하는 엔진이다.
3. Jenkins의 주요 특징
Jenkins가 오랫동안 널리 사용된 이유는 몇 가지 특징 때문임.
3.1 오픈소스 기반
Jenkins는 오픈소스 프로젝트라서 자유롭게 설치하고 확장할 수 있음.
특정 벤더 종속성이 낮고, 자체 인프라 환경에서도 운영이 가능함.
이 특징 때문에 다음 환경에서 특히 많이 사용됐음.
- 사내망 중심 환경
- 인터넷 연결이 제한된 환경
- 자체 빌드 서버가 필요한 환경
- 복잡한 커스텀 파이프라인이 필요한 환경
3.2 Plugin 기반 확장성
Jenkins의 가장 큰 특징 중 하나는 Plugin 구조다.
기본 기능만으로도 파이프라인을 만들 수 있지만, 다양한 플러그인을 추가해서 기능을 넓힐 수 있음.
예를 들면 다음과 같은 확장이 가능함.
- GitHub 연동
- Docker 연동
- Kubernetes 연동
- Slack 알림
- Maven / Gradle 지원
- 테스트 리포트 표시
- 인증 연동
- 보안 스캔 연동
즉, Jenkins는 기본 엔진 위에 여러 기능을 붙여서 조직 환경에 맞게 확장하는 방식이 강함.
3.3 파이프라인 코드화(Pipeline as Code)
예전에는 Jenkins Job 설정을 웹 UI에서 일일이 입력하는 방식이 많았음.
하지만 현재는 Jenkinsfile을 저장소에 함께 두고, 파이프라인 자체를 코드처럼 관리하는 방식이 중요함.
이 접근 방식의 장점은 다음과 같음.
- 파이프라인 변경 이력이 Git에 남음
- 코드와 파이프라인 정의를 함께 관리할 수 있음
- 리뷰와 버전 관리가 쉬움
- 환경 재현성이 높아짐
즉, Jenkins는 단순 UI 설정형 도구를 넘어서 파이프라인 정의 자체를 코드로 다루는 방식으로 발전했음.
3.4 분산 실행 가능
Jenkins는 모든 작업을 한 서버에서만 수행해야 하는 구조가 아님.
필요하면 여러 노드에 작업을 분산해서 실행할 수 있음.
예:
- Linux 빌드는 Linux Agent에서 실행
- Windows 빌드는 Windows Agent에서 실행
- Docker 빌드는 별도 빌드 노드에서 실행
- 병렬 테스트를 여러 Agent에서 나눠 실행
이 구조 덕분에 빌드 부하를 분산하고, 다양한 실행 환경을 다룰 수 있음.
4. Jenkins 아키텍처 개요
Jenkins는 보통 Controller / Agent 구조로 설명함.
예전에는 Master / Slave 용어를 많이 썼지만, 현재는 보통 Controller / Agent라고 표현함.
4.1 Controller의 역할
Controller는 Jenkins의 중심 서버다.
주요 역할은 다음과 같음.
- Jenkins 웹 UI 제공
- Job / Pipeline 설정 저장
- 빌드 요청 수신
- 실행 스케줄 관리
- Agent에 작업 할당
- 플러그인 관리
- 사용자 및 권한 관리
- 빌드 결과 기록
즉, Controller는 Jenkins의 제어 두뇌 역할을 한다.
4.2 Agent의 역할
Agent는 실제 작업을 수행하는 실행 노드다.
예를 들어 다음과 같은 작업을 Agent가 수행할 수 있음.
- Git clone
- Maven build
- npm install
- Docker build
- Test 실행
- 스크립트 실행
Controller가 계획을 세우고 지시하면, Agent가 실제 명령을 실행하는 구조다.
4.3 왜 Controller와 Agent를 분리하는가
모든 작업을 Controller 한 대에서 수행할 수도 있음.
하지만 규모가 커질수록 분리가 필요해짐.
분리 이유는 다음과 같음.
1) 부하 분산
빌드와 테스트는 CPU, Memory, Disk I/O를 많이 사용할 수 있음.
이 작업을 전부 Controller에서 수행하면 Jenkins 자체가 느려질 수 있음.
2) 실행 환경 분리
어떤 프로젝트는 Linux에서 빌드하고, 어떤 프로젝트는 Windows에서 빌드해야 할 수 있음.
Controller와 별도 Agent를 두면 프로젝트 특성에 맞는 실행 환경을 사용할 수 있음.
3) 보안 분리
모든 권한과 실행을 한 서버에 몰아두면 리스크가 커짐.
빌드 실행 노드를 분리하면 격리 효과를 기대할 수 있음.
4) 확장성
빌드 양이 많아질수록 Agent를 늘려서 확장할 수 있음.
5. Controller / Agent 구조 상세 이해
5.1 동작 흐름
Jenkins 파이프라인 실행 흐름을 단순화하면 다음과 같음.
개발자 코드 변경
↓
Git 저장소 이벤트 발생
↓
Jenkins Controller가 Job 트리거
↓
Controller가 실행 가능한 Agent 선택
↓
Agent가 작업 디렉터리 생성 후 소스코드 다운로드
↓
빌드 / 테스트 / 배포 명령 수행
↓
실행 결과를 Controller에 전달
↓
Controller가 UI와 로그에 결과 표시5.2 Workspace 개념
Jenkins가 작업을 실행할 때는 보통 특정 디렉터리에서 작업을 수행함.
이 작업 디렉터리를 Workspace라고 부른다.
Workspace에서는 보통 다음 작업이 일어남.
- 소스코드 다운로드
- 의존성 설치
- 빌드 산출물 생성
- 테스트 결과 파일 생성
즉, Workspace는 파이프라인이 실제로 실행되는 작업 공간이다.
실무에서는 Workspace가 오염되지 않도록 관리하는 것이 중요함.
이전 빌드 결과가 남아 있으면 다음 빌드에 영향을 줄 수 있기 때문임.
5.3 Executor 개념
Jenkins Agent는 동시에 여러 작업을 수행할 수 있도록 설정할 수 있음.
이때 동시 실행 단위를 흔히 Executor라고 본다.
예를 들어 Agent 하나에 Executor가 2개면 동시에 두 개 Job을 돌릴 수 있음.
하지만 무조건 많이 주는 것이 좋은 것은 아님.
이유는 다음과 같음.
- CPU 부족
- 메모리 부족
- 디스크 I/O 경쟁
- Docker build 충돌
- 테스트 포트 충돌
즉, Jenkins는 병렬성이 중요하지만, 동시에 실행 가능한 범위는 인프라 자원과 작업 성격을 함께 고려해야 함.
6. Jenkins의 주요 구성요소
Jenkins를 제대로 이해하려면 자주 등장하는 용어를 먼저 정리해야 함.
6.1 Job
Job은 Jenkins에서 실행 가능한 작업 단위다.
가장 기본적인 자동화 단위라고 보면 됨.
예:
- 저장소 코드를 받아 빌드하는 Job
- 테스트만 수행하는 Job
- Docker 이미지를 생성하는 Job
- 배포 스크립트를 실행하는 Job
즉, Job은 Jenkins가 실행하는 "업무 단위"다.
6.2 Project
Jenkins UI에서는 Job을 프로젝트 형태로 관리하는 경우가 많음.
Freestyle Project, Pipeline Project, Multibranch Pipeline 등이 이에 해당함.
즉, "Project"는 UI 상의 관리 단위이고, 실제 자동화 관점에서는 Job 또는 Pipeline 실행 단위로 이해하면 됨.
6.3 Build
Build는 Job이 한 번 실행된 결과다.
보통 실행 기록이 순번으로 남음.
예:
- Build #15 성공
- Build #16 실패
- Build #17 중단
이 기록을 통해 다음을 확인할 수 있음.
- 언제 실행됐는가
- 누가 트리거했는가
- 어느 커밋 기준인가
- 어떤 로그가 출력됐는가
- 결과가 성공/실패/중단 중 무엇인가
즉, Build는 단순 컴파일 결과가 아니라 Job 실행 이력 단위다.
6.4 Node
Node는 Jenkins가 작업을 수행할 수 있는 실행 대상이다.
Controller 자체도 Node가 될 수 있고, 별도 Agent도 Node가 될 수 있음.
Pipeline 코드에서 특정 Node를 지정하면 그 환경에서 작업을 실행하게 됨.
6.5 Label
Label은 특정 Agent를 분류하는 태그 개념이다.
예를 들어 다음처럼 구분할 수 있음.
linuxwindowsdockermavengpu
파이프라인에서 특정 Label을 요구하면, 해당 Label을 가진 Agent에서 작업이 수행됨.
이 구조는 실무에서 매우 중요함.
프로젝트마다 필요한 실행 환경이 다르기 때문임.
7. Jenkins Job 유형
Jenkins에는 여러 Job 유형이 있지만, 강의 초반에는 대표 유형만 정확히 구분하면 충분함.
7.1 Freestyle Project
가장 전통적인 방식이다.
웹 UI에서 빌드 명령, 트리거, 후처리 작업을 설정할 수 있음.
특징
- 입문이 쉬움
- 간단한 작업 구성에 적합함
- UI 기반이라 빠르게 만들 수 있음
한계
- 설정 이력 관리가 어려움
- 복잡한 흐름 표현이 불편함
- 재사용성과 코드 리뷰가 약함
즉, Freestyle은 개념 학습용으로는 좋지만, 복잡한 실무 파이프라인에는 한계가 있음.
7.2 Pipeline
Pipeline은 Jenkinsfile을 사용해서 단계별 흐름을 코드로 정의하는 방식이다.
특징
- 버전 관리 가능
- 복잡한 절차 표현 가능
- 조건 분기, 병렬 처리 가능
- 코드 리뷰 가능
- 재현성 높음
즉, 현재 Jenkins를 이야기할 때 핵심은 대부분 Pipeline이다.
7.3 Multibranch Pipeline
멀티브랜치 파이프라인은 저장소의 여러 브랜치를 자동으로 인식하고, 각 브랜치의 Jenkinsfile을 기준으로 파이프라인을 실행하는 구조다.
장점
- 브랜치별 자동 파이프라인
- PR 기반 흐름과 잘 맞음
- Git 중심 운영에 유리함
즉, Git 기반 현대적 개발 방식과 잘 연결되는 Jenkins 구조라고 볼 수 있음.
8. Jenkins Pipeline의 중요성
Jenkins를 오래 사용한 조직도 요즘은 대부분 Pipeline 중심으로 운영함.
그 이유는 명확함.
8.1 UI 설정보다 코드 관리가 유리함
UI에서 클릭으로 구성한 Job은 다음 문제가 생기기 쉬움.
- 누가 무엇을 바꿨는지 추적이 어려움
- 환경 복제가 어려움
- 백업과 재구성이 번거로움
- 리뷰 없이 설정이 바뀔 수 있음
반면 Jenkinsfile은 Git에 저장되므로 다음이 가능함.
- 변경 이력 추적
- 코드 리뷰
- 브랜치별 분리
- 프로젝트와 함께 관리
즉, 파이프라인을 코드화하면 DevOps의 핵심 원칙 중 하나인 변경의 추적 가능성이 높아짐.
8.2 복잡한 흐름 표현이 쉬움
실무 파이프라인은 단순하지 않음.
예를 들면 다음 흐름이 필요할 수 있음.
- feature 브랜치는 테스트까지만
- main 브랜치는 릴리스까지
- 태그가 붙으면 운영 배포 후보 생성
- 보안 점검 실패 시 중단
- 테스트는 병렬 수행
- 운영 배포 전 승인 단계 추가
이런 구조는 Pipeline 코드 방식이 훨씬 잘 맞음.
9. Plugin 구조의 장점과 주의점
9.1 Plugin이 주는 장점
Jenkins는 플러그인을 통해 기능을 폭넓게 확장할 수 있음.
예:
- Git 플러그인
- Pipeline 플러그인
- Docker 플러그인
- Kubernetes 플러그인
- Slack Notification 플러그인
- Credentials Binding 플러그인
즉, Jenkins는 기본 엔진이 있고, 필요한 기능을 플러그인으로 추가하는 구조임.
9.2 Plugin 구조의 한계
플러그인이 많다는 것은 강점이지만 동시에 관리 포인트도 많다는 뜻임.
주의할 점은 다음과 같음.
- 플러그인 버전 충돌 가능성
- Jenkins 업그레이드 시 호환성 문제
- 보안 취약점 관리 필요
- 오래된 플러그인의 유지보수 중단 가능성
즉, Jenkins를 운영할 때는 단순 설치보다 플러그인 생태계 관리가 중요한 과제가 됨.
10. Jenkins가 잘 맞는 환경
Jenkins는 모든 조직에서 무조건 최선은 아니지만, 다음 환경에는 특히 잘 맞는 편임.
10.1 자체 인프라 중심 환경
사내망, 폐쇄망, 자체 서버 운영 환경에서는 Jenkins의 통제력이 강점이 됨.
10.2 복잡한 커스텀 파이프라인
단순 SaaS 워크플로우보다 복잡한 절차와 레거시 시스템 연동이 필요한 경우 Jenkins가 유리할 수 있음.
10.3 다양한 실행 환경이 필요한 경우
Linux, Windows, Docker, 특정 사내 도구 등 여러 환경을 혼합해야 할 때 Agent 구조가 유용함.
10.4 기존 레거시 자동화 자산이 많은 경우
이미 수많은 Jenkins Job과 Script가 있는 조직에서는 Jenkins가 여전히 핵심 플랫폼일 수 있음.
11. Jenkins의 한계와 운영상 고려사항
Jenkins는 강력하지만, 운영 난이도도 함께 고려해야 함.
11.1 직접 운영 부담
Jenkins는 설치형 도구라서 서버 운영, 백업, 업그레이드, 보안 패치 등을 직접 관리해야 함.
11.2 플러그인 의존성
확장성은 좋지만 관리 복잡도도 커짐.
11.3 UI 중심 운영의 위험
Pipeline as Code를 쓰지 않으면 설정이 산발적으로 흩어질 수 있음.
11.4 Controller 과부하 가능성
잘못 설계하면 모든 작업이 Controller에 몰려 성능 문제가 생길 수 있음.
11.5 보안 관리 중요
Credential 관리, 권한 분리, 에이전트 격리, 외부 연동 보안 등을 신경 써야 함.
즉, Jenkins는 강력한 만큼 "운영형 도구"라는 점을 반드시 기억해야 함.
12. 아키텍처 관점에서 본 Jenkins의 위치
CI/CD 전체 구조에서 Jenkins는 보통 다음 위치에 놓임.
Developer
↓
Git Repository
↓
Jenkins Controller
↓
Jenkins Agent
↓
Build / Test / Package
↓
Artifact Repository / Container Registry
↓
Deployment Target이 구조에서 Jenkins는 트리거를 받고 파이프라인을 실행하며 결과를 다음 단계로 넘기는 중심 허브 역할을 한다.
즉, Jenkins는 코드 저장소와 실행 환경 사이를 연결하는 자동화 오케스트레이터라고 볼 수 있음.
요약
- Jenkins는 CI/CD 자동화를 위한 오픈소스 자동화 서버임
- 단순 빌드 도구가 아니라 파이프라인 실행과 흐름 제어를 담당하는 플랫폼임
- 기본 구조는 Controller / Agent 아키텍처로 설명할 수 있음
- Job, Build, Node, Label, Workspace 같은 기본 개념을 이해해야 함
- 현대적인 Jenkins 활용의 핵심은 Pipeline as Code와 Jenkinsfile임
- 플러그인 확장성은 강점이지만 동시에 운영 관리 포인트이기도 함
- Jenkins는 특히 자체 인프라와 복잡한 자동화 흐름이 필요한 환경에서 강점을 가짐
