[Jenkins] Master-Slave 분산 빌드: 단일 서버의 한계를 돌파하라

처음 젠킨스를 도입했을 때, 우리는 AWS EC2 t3.medium 서버 한 대에 젠킨스를 설치하고 모든 것을 거기서 해결했습니다. 소스코드를 다운받고, 무거운 자바(Java) 컴파일을 돌리고, 도커 이미지를 구워서 압축하고 푸시하는 이 모든 '막노동'을 젠킨스 서버 혼자서 처리했죠. 파이프라인이 5~10개일 때는 괜찮았습니다. 하지만 회사가 폭풍 성장하여 개발자가 100명이 넘어가고, 출근 직후인 오전 10시에 50개의 빌드가 동시에 트리거(Trigger)되는 순간 재앙이 시작됩니다. CPU 사용률 100%, 메모리(RAM) 풀, 디스크 I/O 병목으로 인해 젠킨스 웹 브라우저 UI 자체가 접속 불가 상태로 하얗게 뻗어버립니다. 서버 한 대로는 더 이상 버틸 수 없는 물리적 한계점(Bottleneck)에 도달한 것입니다.

이번 [Jenkins 실무 완벽 가이드] 시리즈에서는 "젠킨스 본체는 우아하게 지휘(Orchestration)만 하고, 실제 무거운 노동은 수십 대의 워커(Worker) 서버들에게 분산시켜 병렬로 처리하는" 엔터프라이즈 확장의 궁극기, 'Jenkins Master-Slave (Controller-Agent) 분산 아키텍처'에 대하여 다뤄보겠습니다.

🧠 1. Master(Controller)와 Slave(Agent)의 역할 분담

요즘은 정치적 올바름(PC) 이슈로 Master-Slave 대신 Controller-Agent 라는 명칭을 주로 사용합니다. 이 둘의 역할은 완벽하게 쪼개져야 합니다.

• Master (Controller): 두뇌입니다. 개발자의 브라우저 접속(UI)을 처리하고, Github 웹훅을 받아 파이프라인 스케줄을 짜며, 파이프라인이 잘 도는지 모니터링합니다. 절대로 자기 자신의 디스크에서 npm install이나 mvn package 같은 무거운 노동을 해서는 안 됩니다!
• Slave (Agent): 근육입니다. 마스터의 명령을 받아 실제로 땀을 흘리며 소스코드를 받고 빌드하는 일개미 워커 노드들입니다. CPU와 RAM이 무지막지하게 큰 머신 여러 대를 준비합니다. 윈도우 앱을 빌드하기 위한 Windows Agent, iOS 앱을 굽기 위한 Mac Agent 등 운영체제별로 다양하게 붙일 수 있습니다.

🔌 2. 두 가지 연결 방식: SSH vs JNLP (Inbound)

마스터가 에이전트를 부려먹으려면 네트워크 통신 채널이 필요합니다. 실무에서 쓰이는 두 가지 대표적인 프로토콜이 있습니다.

1. SSH 방식 (가장 흔하고 쉬움): 마스터가 에이전트 리눅스 서버의 22번 포트(SSH)로 접속해 들어가서 agent.jar를 몰래 실행시키고 노예 계약을 맺는 방식입니다. 사내망에서 에이전트 서버로 접속이 자유롭게 뚫려있을 때 씁니다.

2. JNLP / Inbound 방식 (방화벽 우회용): 마스터는 AWS 클라우드에 있고, 에이전트 서버는 꽉 막힌 회사 내부망 PC인 경우 마스터가 먼저 뚫고 들어올 수 없습니다. 이럴 때는 내부망 PC(에이전트)가 마스터의 50000번 포트로 "저 일하러 왔습니다!" 하고 먼저 연결(Outbound)을 시도하여 맺어지는 방식입니다.

🏷️ 3. agent { label } 매칭 시스템의 마법

에이전트 10대를 젠킨스 마스터에 연결해 두었다고 가정해 봅시다. 3대는 프론트엔드용(Node.js 설치됨), 3대는 백엔드용(Java 설치됨), 4대는 인공지능용(GPU 탑재됨)입니다. 특정 파이프라인이 아무 에이전트에나 가서 빌드되면 안 되겠죠? 이때 라벨(Label)이라는 개념이 등장합니다.

// [프론트엔드 프로젝트의 Jenkinsfile]
pipeline {
    // 🌟 젠킨스 마스터에게 외칩니다: "내 빌드는 'frontend-node' 라벨이 붙은 에이전트 머신들 중에서 지금 노는 놈 아무한테나 던져주세요!"
    agent { 
        label 'frontend-node' 
    }
    stages {
        stage('Build UI') {
            steps {
                echo "프론트엔드 전용 고성능 에이전트에서 빌드가 쾌적하게 실행됩니다."
                sh 'npm ci && npm run build'
            }
        }
    }
}

이렇게 agent { label '...' }을 지정하면, 젠킨스 마스터는 수십 대의 워커 노드 팜(Farm) 중에서 해당 라벨을 가진 유휴(Idle) 장비를 기가 막히게 찾아내서 빌드 작업을 던져줍니다. 에이전트를 수평(Scale-out)으로 계속 늘려나가기만 하면 파이프라인 1,000개가 동시에 돌아도 마스터는 끄떡없습니다.

🎯 4. 마무리 및 다음 단계

지금까지 젠킨스 단일 서버의 비명을 멈추게 하고, 무한한 스케일아웃 확장이 가능한 진정한 의미의 '엔터프라이즈 빌드 공장', Master-Agent 분산 아키텍처에 대해 다루어 보았습니다. 이제 여러분의 CI/CD 인프라는 넷플릭스나 구글 부럽지 않은 대규모 처리 능력을 갖추었습니다.

자, 길고 길었던 젠킨스 완벽 가이드 대장정의 마지막 장이 눈앞에 왔습니다. 인프라도 탄탄하고 파이프라인도 완벽한데... 어느 날 새벽 갑자기 젠킨스가 알 수 없는 이유로 죽어버리거나 디스크가 터지는 등 "인프라 엔지니어의 심장을 철렁하게 만드는 3대장 최악의 장애"가 터지곤 합니다. 젠킨스 가이드의 최종화, 이어지는 40단계 대망의 피날레 포스팅에서는 "겪어보지 않으면 절대 모른다! 데브옵스 실무에서 피눈물 흘리며 깨달은 Jenkins 최악의 장애 대처 Best 3와 응급 복구(Troubleshooting) 비법"에 대해 모든 것을 쏟아부어 파헤쳐 보겠습니다!