71. 젠킨스 (Jenkins) CI/CD 서버

⚠️ 이 문서는 개발자가 소스코드를 커밋하면, 백그라운드에서 24시간 깨어 있다가 코드를 낚아채어 컴파일하고, 단위 테스트를 수천 번 돌리며, 서버에 배포까지 원클릭으로 이어주는 **전 세계 소프트웨어 공장의 가장 대중적인 오픈소스 자동화 컨베이어 벨트(CI/CD) 심장부인 '젠킨스(Jenkins)'**를 다룹니다.

핵심 인사이트 (3줄 요약)

본질: 자바(Java)로 만들어진 지속적 통합 및 지속적 배포(CI/CD) 자동화 서버다. 밤새워 사람이 마우스로 클릭하던 '빌드 $\rightarrow$ 테스트 $\rightarrow$ 패키징 $\rightarrow$ 배포'의 수작업 과정을 기계적으로 이어주는 파이프라인 엔진이다.

가치: 1,800개가 넘는 압도적인 플러그인(Plugin) 생태계를 가져, Git, Docker, AWS, Slack 등 세상에 존재하는 거의 모든 IT 도구와 레고 블록처럼 연결되어 어떤 괴상한 회사의 배포 환경에도 100% 맞춤형으로 튜닝할 수 있다.

기술 체계: 전통적인 클릭 방식(UI)을 넘어, Jenkinsfile이라는 문서에 파이프라인의 모든 순서를 코드(Groovy 언어)로 짜서 깃허브에 저장하는 Pipeline as Code (PaC) 사상이 현재 젠킨스 운영의 абсолют(절대적) 표준이다.

Ⅰ. 수동 배포의 고통과 젠킨스 할아버지의 등장

젠킨스가 없던 시절, 배포 날은 무조건 야근하는 날이었다.

과거의 수동 배포 지옥:
- 금요일 저녁, 이 대리는 자기 PC에서 Eclipse를 열고 10명의 개발자가 모아놓은 코드를 빌드한다. 버그가 터지면 "누구 코드 때문에 에러 났어?"라며 범인 찾기를 한다.
- 빌드가 완료되면 FTP 프로그램(FileZilla)을 열어 운영 서버에 .war 파일을 복사하고, 톰캣(Tomcat) 서버를 껐다 킨다. 중간에 실수 하나라도 하면 서비스가 폭파된다.
지속적 통합 (CI)의 로봇, 젠킨스:
- 누군가 깃허브에 코드를 푸시(Push)하는 순간(웹훅 발동), 젠킨스 서버가 부르르 떨며 깨어난다.
- 젠킨스는 즉시 코드를 다운받아 아무도 없는 빈 방(워크스페이스)에서 스스로 빌드(maven build)를 돌리고, 테스트 100개를 수행한다.
- 만약 철수가 올린 코드 때문에 테스트가 깨지면, 즉시 철수에게 슬랙(Slack) 알람을 보내어 "네 코드 때문에 빌드 깨졌으니 당장 고쳐(빨간불 ❌)!"라고 호통을 친다. 불량품이 운영 서버로 넘어가는 것을 완벽히 봉쇄한다.

📢 섹션 요약 비유: 옛날엔 자동차(앱)를 조립할 때 사람들이 망치를 들고 모여 수작업으로 뚝딱거렸다면, 젠킨스는 공장 한가운데 서 있는 거대한 '중앙 통제 로봇 팔'입니다. 부품(코드)이 컨베이어 벨트에 올라오자마자 로봇이 알아서 조이고, 용접하고, 불량품을 튕겨낸 뒤 예쁘게 박스에 포장까지 완벽하게 끝내주는 혁신적인 공장 자동화입니다.

Ⅱ. 젠킨스의 무기: 1800개의 플러그인 생태계

왜 세상의 수많은 CI/CD 툴 중 젠킨스가 아직도 압도적 1위일까?

미친듯한 확장성 (Plugins):
- 젠킨스 그 자체는 아무것도 할 줄 모르는 텅 빈 깡통 스케줄러에 불과하다. 젠킨스의 진짜 힘은 '플러그인'에서 나온다.
- "코드를 GitHub에서 가져와야 해" $\rightarrow$ Git 플러그인 설치.
- "빌드 끝나면 도커 이미지로 구워줘" $\rightarrow$ Docker 플러그인 설치.
- "AWS S3에 백업 올려줘" $\rightarrow$ AWS 플러그인 설치.
- "성공하면 텔레그램으로 알려줘" $\rightarrow$ Telegram 플러그인 설치.
온프레미스(On-premise)의 제왕:
- GitHub Actions나 CircleCI 같은 최신 클라우드 기반 도구들이 편하긴 하지만, 외부 인터넷 연결을 끊어버린 금융권이나 깐깐한 대기업의 폐쇄망(사내 전산실) 환경에서는 설치형인 젠킨스만이 유일한 해답이 된다.

📢 섹션 요약 비유: 젠킨스는 '스마트폰 공기계(깡통)'와 같습니다. 그 자체로는 전화만 되지만, 앱 스토어(플러그인 생태계)에 들어가서 카카오톡, 넷플릭스, 배달의민족 앱을 깔기만 하면 무궁무진한 만능 비서로 변신합니다. 세상에 존재하는 모든 회사들의 기상천외한 배포 요구사항을 이 앱(플러그인)들로 100% 맞춰줄 수 있는 점이 젠킨스의 무서움입니다.

Ⅲ. Pipeline as Code (PaC): `Jenkinsfile`의 철학

과거처럼 화면을 클릭해서 파이프라인을 만들면 초보자다.

UI 설정의 붕괴 (Freestyle Project의 몰락):
- 옛날 젠킨스는 관리자 화면에 들어가서 "1단계는 빌드, 2단계는 테스트..." 이렇게 마우스로 클릭해서 설정했다.
- 이렇게 하면 서버가 날아가면 설정도 다 날아가고, 파이프라인이 여러 개로 늘어나면 유지보수가 불가능해졌다.

선언적 파이프라인 (Declarative Pipeline)과 Jenkinsfile:

이제는 프로젝트 소스코드 맨 최상단 폴더에 Jenkinsfile 이라는 텍스트 문서를 만든다.

pipeline {
    agent any
    stages {
        stage('Build') { steps { sh 'npm run build' } }
        stage('Test') { steps { sh 'npm test' } }
        stage('Deploy') { steps { sh './deploy.sh' } }
    }
}

코드로서의 파이프라인 가치:
- 이 파일을 깃허브에 코드와 함께 올려두면(Push), 젠킨스는 이 문서를 스르륵 읽어 들이고 그대로 컨베이어 벨트를 세팅하여 돌려버린다.
- 배포 과정(파이프라인) 자체가 소스코드처럼 이력이 남고(버전 관리), 젠킨스 서버가 불에 타서 날아가도 깃허브에 있는 Jenkinsfile만 다시 먹이면 1초 만에 배포 라인이 100% 복구된다.

📢 섹션 요약 비유: 공장의 기계 세팅값을 매번 공장장이 스위치를 수동으로 조작해서 맞추는 것(UI 세팅)은 너무 불안합니다. 대신 '기계 세팅 매뉴얼(Jenkinsfile)'을 코드로 꼼꼼히 적어서 금고(Git)에 넣어둡니다. 언제든 기계를 새로 사 오더라도 그 매뉴얼 종이만 기계에 쓱 밀어 넣으면, 기계가 매뉴얼을 읽고 똑같이 세팅을 쫙 완료해 버리는 초현대적 팩토리 공법입니다.

71. 젠킨스 (Jenkins) CI/CD 서버

핵심 인사이트 (3줄 요약)

Ⅰ. 수동 배포의 고통과 젠킨스 할아버지의 등장

Ⅱ. 젠킨스의 무기: 1800개의 플러그인 생태계

Ⅲ. Pipeline as Code (PaC): Jenkinsfile의 철학

Ⅲ. Pipeline as Code (PaC): `Jenkinsfile`의 철학