72. 선언적 파이프라인 (Declarative Pipeline) - Jenkinsfile

⚠️ 이 문서는 기존 젠킨스(Jenkins) 화면에서 마우스를 뚝딱거려 클릭으로 배포 스크립트를 짜던 무식하고 위험한 방식을 전면 폐기하고, 소스코드를 짜듯 배포의 모든 단계(Build $\rightarrow$ Test $\rightarrow$ Deploy)를 하나의 텍스트 문서(Jenkinsfile)로 코딩하여 깃허브(Git)에 버저닝(Versioning)하는 'Pipeline as Code(PaC)'의 핵심 문법인 선언적 파이프라인을 다룹니다.

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

  1. 본질: "어떻게(How) 빌드해라"라고 복잡한 스크립트 로직(if, for 문)을 짜는 프로그래머식 방식(Scripted Pipeline)을 버리고, "1단계 빌드, 2단계 테스트, 3단계 배포를 해라!"라고 무엇(What)을 할지만 명확한 구조로 선언(Declarative)하는 젠킨스의 최신 표준 문법이다.
  2. 가치: 배포 설정 자체가 파일 하나(Jenkinsfile)로 코딩되어 소스코드와 함께 Git에 저장되므로, 젠킨스 서버가 불에 타서 날아가도 1초 만에 배포 라인을 100% 복원할 수 있으며, 개발자가 배포 파이프라인의 변경 이력을 완벽히 추적할 수 있다.
  3. 기술 체계: pipeline { agent any ... } 이라는 엄격하고 딱딱한 블록(Block) 구조를 강제하여, 누구나 코드를 읽기 쉽고 에러 검증(Syntax Check)이 배포 전에 자동으로 이루어진다.

Ⅰ. UI 기반 설정의 몰락과 Pipeline as Code (PaC)

마우스 클릭으로 만든 시스템은 재앙을 부른다.

  1. Freestyle Project (화면 설정)의 한계:
    • 과거 젠킨스의 '새 작업 만들기' 화면에서, 개발자는 "Git URL 입력 창"에 주소를 붙여넣고 "빌드 쉘 입력 창"에 쉘 스크립트를 수동으로 쳐 넣었다.
    • 프로젝트가 100개가 넘어가면, 이 화면의 설정을 관리자가 일일이 다 기억할 수 없다. 누군가 화면에서 실수로 체크박스 하나를 풀면 배포가 터지는데, "누가 언제 설정을 바꿨는지" 추적할 로그(History)가 전혀 남지 않는 끔찍한 사각지대였다.
  2. Pipeline as Code (PaC)의 혁명:
    • "서버를 띄우는 인프라도 코드(IaC, Terraform)로 짜는 마당에, 배포 파이프라인 세팅도 코드로 짜서 Git에 올리자!"
    • 프로젝트 폴더 맨 위에 Jenkinsfile (확장자 없음) 이라는 텍스트 파일 딱 하나를 던져놓고 여기에 배포 단계를 쫙 적어둔다. 젠킨스는 코드를 Pull 받을 때 이 파일부터 읽고 그대로 공장 벨트를 세팅하여 돌린다.

📢 섹션 요약 비유: 공장의 로봇 팔 세팅을 매일 아침 공장장이 리모컨 버튼을 일일이 눌러서(UI 세팅) 맞추면, 공장장이 결근한 날 공장이 멈춥니다. 대신 '로봇 작동 매뉴얼(Jenkinsfile)'을 종이에 꼼꼼히 코드로 적어 금고(Git)에 보관해 두면(PaC), 어떤 바보가 와서 그 종이만 로봇 입에 물려줘도 로봇이 알아서 완벽하게 세팅값을 맞추고 척척 돌아가는 완벽한 자동화 문서 시스템입니다.

Ⅱ. Scripted vs Declarative Pipeline의 결투

프로그래밍 언어의 자유도냐, 규격화된 레고 블록이냐.

  1. 초기 스크립트 파이프라인 (Scripted Pipeline):
    • 초기 Jenkinsfile은 그루비(Groovy)라는 프로그래밍 언어를 그대로 썼다.
    • 개발자가 node { if (isProduction) { deploy() } } 처럼 맘대로 for 문과 if 문을 섞어 아주 복잡한 묘기를 부릴 수 있었다.
    • 단점: 코드가 너무 복잡해져서 데브옵스 엔지니어가 아니면 읽을 수 없는 스파게티 괴물이 되어버렸다.
  2. 구원자: 선언적 파이프라인 (Declarative Pipeline):
    • 젠킨스 측에서 "너무 어렵게 짜지 마! 우리가 정해준 네모난 템플릿 블록 안에 글자만 채워 넣어!"라며 만든 강제 규격이다.
    • 반드시 최상단에 pipeline { ... } 껍데기로 감싸야 하고, 변칙적인 프로그래밍 꼼수가 엄격하게 제한된다.
    • 장점: 문법이 너무 쉽고 구조적(블록 형태)이라 비개발자도 직관적으로 단계를 읽을 수 있고, 젠킨스가 코드를 돌리기 전에 문법 에러를 사전에 완벽히 튕겨내어 안정성이 극도로 높다. 현대 젠킨스의 절대 표준이다.

📢 섹션 요약 비유: 스크립트 방식(Scripted)은 백지 도화지와 크레파스를 주고 "네 마음대로 배포 절차를 자유롭게 그려봐"라고 하는 자유방임주의라 그림이 난해해집니다. 선언적 방식(Declarative)은 '다이어리 속지 세트'를 주고 "무조건 오전, 오후, 저녁 칸에 맞춰서 할 일(Stage)을 또박또박 적어!"라고 틀을 강제하여, 누가 봐도 1초 만에 일정을 알아볼 수 있게 만든 완벽한 규격화 시스템입니다.

Ⅲ. 선언적 파이프라인의 해부학 (블록 구조)

5가지 핵심 키워드만 알면 모든 파이프라인을 짤 수 있다.

  1. pipeline 및 agent:
    • pipeline은 선언적 파이프라인이 시작됨을 알리는 대문이다.
    • agent any: "젠킨스 워커 노드 10대 중에 지금 놀고 있는 빈 서버 아무 데서나 이 배포 작업을 실행해라!"라는 뜻이다. (도커 컨테이너 안에서 실행하라고 지정할 수도 있다.)
  2. stages 와 stage (단위 작업):
    • 공장의 거대한 컨베이어 벨트 구간이다. 화면(Blue Ocean UI)에 보이는 그 막대기들이다.
    • stage('Build'), stage('Test'), stage('Deploy') 처럼 큰 덩어리를 선언한다.
  3. steps (실제 행동):
    • 각 stage 안에서 로봇이 실제로 망치질할 행동 대본이다.
    • steps { sh 'npm install' } 이라 적으면, 리눅스 쉘(sh)에서 ওই 명령어를 냅다 타건한다.
  4. post (사후 처리/알람):
    • 모든 빌드가 끝난 뒤 마무리 청소나 연락을 돌리는 단계다.
    • success { slackSend '빌드 성공!' } 이나 failure { slackSend '빌드 터짐!' } 처럼 결과에 따라 슬랙으로 톡을 쏘아주는 국룰 알람 블록이다.

📢 섹션 요약 비유: pipeline이라는 거대한 '공장 건물' 안에 들어서면, agent라는 '노동자'를 배정받습니다. 이 노동자는 stages라는 '3개의 작업대(빌드, 테스트, 배포)'를 차례대로 걷게 되며, 각 작업대 위에는 steps라는 '망치질 3번, 나사 조이기 2번'의 구체적 지시서가 붙어있습니다. 퇴근할 때 post라는 '보고용 전화기'를 들어 반장님께 "성공했습니다/망했습니다"라고 전화를 걸면 하루 일과가 완벽하게 끝나는 레고 조립 설명서입니다.