Jenkins 동적 Mac Agent 가치가 있을까? 2026 기업 CI 방안

Jenkins 공식 문서는 라벨을 이용해 작업을 특정 Agent로 보낼 수 있고, 클라우드 자원 확장 구조도 지원한다고 설명합니다. 이 기능만으로 모든 Mac Agent를 동적으로 바꾸는 것은 권장되지 않습니다. 승자는 혼합 노드 풀입니다. PR 검증과 반복 테스트는 동적 격리 노드로 보내고, 서명과 정식 배포는 전용 고정 Mac에 남겨야 합니다. 준비 시간이 중요한 팀만 작은 온풀을 추가하는 방식이 안전합니다. Jenkins Agent 관리 문서와 확장 구조 문서가 이 판단의 기능적 근거입니다.

이 글은 Jenkins 큐가 배포 피크마다 늘어나는 IT 책임자를 위한 글입니다. 신뢰할 수 없는 PR과 잔류 작업 공간을 분리해야 하는 보안·플랫폼 담당자, 서명 Mac과 Xcode 환경을 관리하는 연구개발 효율 책임자도 대상입니다.

작업 성격으로 나누는 고정 풀과 동적 풀

노드 선택은 장비 사양보다 작업의 신뢰도와 복구 방식으로 결정해야 합니다. 다음 표에서 네 가지 질문에 모두 답한 뒤 라벨을 설계하는 편이 좋습니다.

환경을 자동으로 재현할 수 있고 민감한 자격 증명을 쓰지 않으며 대기 시간을 허용할 수 있다면 동적 노드가 적합합니다. 반대로 환경 복제가 불안정하거나 키체인과 배포 권한이 필요하면 고정 노드가 우선입니다.

Jenkins의 라벨은 작업을 올바른 노드로 보내는 장치입니다. 보안 경계를 대신하지는 않습니다. 파이프라인 문법의 Agent와 라벨 설명처럼 작업 단계에서 라벨을 명시하고, 권한은 별도로 최소화해야 합니다.

가장 작은 라우팅 설정

pipeline {
    agent none

    stages {
        stage('PR 검증') {
            agent { label 'mac-pr-dynamic' }
            steps {
                sh 'xcodebuild test'
            }
            post {
                always {
                    deleteDir()
                }
            }
        }

        stage('서명 아카이브') {
            agent { label 'mac-sign-fixed' }
            steps {
                sh 'xcodebuild archive'
            }
        }
    }
}

deleteDir()는 작업 공간을 지우지만, 실제 Mac 호스트의 로그·캐시·키체인까지 자동으로 없애지는 않습니다. 따라서 Jenkins Agent의 종료, 실제 Mac의 반납 또는 초기화, 작업 공간 청소, 서명 자격 증명 폐기를 서로 다른 통제 항목으로 기록해야 합니다.

PR 검증은 장기 Mac과 분리해야 하는가

공개 PR과 교차 팀 코드는 동적 Mac Agent로 보내야 합니다. Jenkins 공식 보안 문서는 신뢰하지 않는 변경 코드가 빌드 환경과 자격 증명을 악용할 수 있다고 설명합니다. 빌드 보안 지침에 따라 PR 작업에는 배포용 비밀값을 제공하지 않아야 합니다.

동적 노드가 회수된다고 해서 자격 증명 최소 권한 원칙이 사라지는 것은 아닙니다. 다음 조건을 동시에 적용해야 합니다.

• PR 작업에는 배포 인증서와 App Store Connect 자격 증명을 주입하지 않습니다.
• 작업마다 새 작업 공간을 만들고, 종료 단계에서 파일 목록을 검사합니다.
• 한 Agent에서 서로 다른 신뢰 수준의 작업을 재사용하지 않습니다.
• Jenkinsfile을 수정할 수 있는 작업은 신뢰된 배포 라벨에 접근하지 못하게 합니다.
• Agent 회수 실패가 발생하면 해당 호스트를 즉시 격리하고 자동 재사용하지 않습니다.

Jenkins Controller와 빌드 노드의 분리는 별도 통제입니다. Controller 격리 문서처럼 Controller의 비밀 정보와 실행 권한을 빌드 환경에 불필요하게 노출하지 않아야 합니다.

Jenkins macOS Agent는 큐에 따라 자동 확장할 수 있습니까?
가능 여부는 Jenkins 자체보다 선택한 클라우드 자원 플러그인, 자원 제어면, 실제 Mac 제공 방식에 달려 있습니다. Jenkins는 확장 구조와 Agent 연결을 위한 일반 기능을 제공하지만, 특정 macOS 동적 공급 경로가 모든 환경에서 같은 방식으로 동작한다고 단정할 수는 없습니다. 도입 전에는 플러그인의 공식 문서, 유지 상태, 지원하는 Mac 연결 방식을 확인해야 합니다.

검증 증거는 다음과 같이 남겨야 합니다.

작업 요청
→ 동적 Mac 할당
→ Agent 연결
→ 라벨 일치 확인
→ 작업 실행
→ 작업 공간 삭제
→ Agent 종료 또는 호스트 격리

각 단계에 시각 기록과 실패 원인을 남기면, 단순한 큐 지연과 실제 Mac 공급 실패를 구분할 수 있습니다.

시뮬레이터 테스트는 완전한 냉시작과 온풀 중 무엇이 나은가

반복 테스트는 보안만으로 결정하기 어렵습니다. Xcode 구성 요소, Simulator Runtime, 의존성 캐시가 준비되어야 하기 때문입니다. Apple의 Xcode 시스템 요구 사항은 Xcode 버전과 지원 운영 체제의 관계를 보여주므로, Xcode 27을 도입할 때도 먼저 공식 요구 사항을 다시 확인해야 합니다. 공식 확인 전에는 Xcode 27의 지원 범위나 성능을 확정된 사실처럼 사용해서는 안 됩니다.

세 운영 방식을 같은 프로젝트로 비교해야 합니다.

하드웨어 이름만 보고 처리량을 계산하면 안 됩니다. 같은 프로젝트와 같은 테스트 집합으로 다음 항목을 기업 기록에 남겨야 합니다.

• Mac 호스트가 할당된 뒤 Agent가 연결될 때까지 걸린 시간
• Agent 연결 뒤 첫 작업이 끝날 때까지 걸린 시간
• 연속 작업에서 캐시가 재사용되는 조건과 실패율
• Simulator Runtime이 없거나 손상되었을 때의 복구 경로
• 작업 종료 뒤 남은 프로세스, 파일, 키체인 항목

동적 Mac Agent 시작이 너무 느리면 온풀이 필요한가요?
준비 시간이 실제 대기열의 주요 원인일 때만 온풀을 검토해야 합니다. 먼저 냉시작과 사전 준비 이미지를 같은 조건에서 측정합니다. 환경이 안정적으로 재현되지 않는다면 온풀을 추가하기보다 이미지와 초기화 절차를 먼저 고쳐야 합니다. 온풀은 속도를 보완하지만, 오래 살아 있는 작업 공간과 캐시가 격리 문제를 만들 수 있습니다.

서명과 정식 배포는 전용 고정 Mac으로 고정해야 합니다

서명 작업은 동적 노드에 임시로 인증서와 키체인을 넣는 순간 운영 범위가 커집니다. 회수 실패, 로그 누락, 복구 중 자격 증명 잔류를 모두 관리해야 하기 때문입니다. Apple은 인증서 종류와 관리 절차를 안내하고, Keychain Services는 키체인 데이터 접근 방식을 설명합니다.

권장 흐름은 단방향입니다.

일반 테스트 풀
→ 검증된 빌드 산출물
→ 전용 서명 풀
→ 정식 배포

일반 테스트 노드가 서명 노드로 직접 작업을 넘기지 않도록 합니다. Jenkins 작업에는 mac-sign-fixed 같은 전용 라벨을 붙이고, 해당 라벨을 사용할 수 있는 폴더와 자격 증명 범위를 제한합니다.

Jenkins에서 서명 작업을 전용 Mac Agent에 고정하려면 어떻게 해야 하나요?
서명용 고정 Mac에 전용 라벨을 부여하고 파이프라인의 서명 단계에서 그 라벨만 호출해야 합니다. 동시에 해당 단계에 접근할 수 있는 Jenkins 권한, 자격 증명 아이디, 작업 폴더를 제한해야 합니다. 라벨만 지정하고 권한을 열어 두면 고정 효과가 보안 통제로 이어지지 않습니다.

운영 승인 전에는 다음 증거가 필요합니다.

• 작업이 실제로 전용 라벨에 도착했다는 라우팅 기록
• 자격 증명 주입과 폐기 기록
• 서명 Mac 접근 허용 목록
• 일반 테스트 라벨에서 서명 단계가 거부되는 결과
• 고정 서명 노드가 중단됐을 때의 실패와 수동 회복 결과

사설망과 대형 캐시는 동적화의 경계를 만든다

내부 저장소, 사설 패키지 저장소, 기업 프록시, 대형 의존성 캐시는 동적 노드의 준비 시간을 늘릴 수 있습니다. 이때 모든 캐시를 장기 볼륨으로 연결하는 방식은 편해 보여도 프로젝트 간 오염과 정보 잔류를 키울 수 있습니다.

데이터는 세 종류로 나누는 편이 안전합니다.

1. 신뢰된 원본에서 다시 만들 수 있는 의존성 캐시
2. 재생성할 수 없거나 보존이 필요한 서명 관련 자료
3. 프로젝트 간 공유가 금지된 소스, 로그, 비밀값

첫 번째는 동적 노드에서 다시 만들 수 있습니다. 두 번째는 전용 고정 노드 또는 제한된 보안 저장소가 적합합니다. 세 번째는 작업 종료 때 반드시 폐기하고, 다른 프로젝트의 온풀로 넘기지 않아야 합니다.

실제 판단은 다음 자료로 합니다.

• Jenkins에서 사설망까지 연결되는 경로
• 의존성 캐시를 새로 만드는 데 걸리는 시간
• 캐시가 없을 때 작업 실패율
• 프록시나 인증서가 준비되지 않았을 때의 복구 시간
• 프로젝트 간 캐시 공유로 발생한 오염 기록

이 결과에 따라 고정 노드, 온풀, 완전 동적 노드 중 하나를 고릅니다. 캐시가 크다는 이유만으로 모든 Mac을 고정할 필요는 없습니다. 반대로 내부망 연결이 불안정한데 동적화를 강행하면 큐 확장이 아니라 준비 실패가 늘어납니다.

피크 용량은 장비 수가 아니라 회복 가능성으로 결정합니다

배포 피크에는 네 가지 값을 함께 봐야 합니다. 피크 큐 길이, 노드 준비 지연, 노드 한 대의 유효 처리량, 장애 후 대체 가능성입니다. 여기에 운영자가 수동으로 복구하는 데 드는 시간도 포함해야 합니다.

Mac 용량이 짧은 기간에만 부족하다면, 장비를 영구 구매하기 전에 SFTPMAC의 Mac 임대 요금 안내를 비교 대상으로 넣을 수 있습니다. 이 선택은 정식 서명 Mac을 즉시 대체하는 방식이 아닙니다. 비서명 테스트 라벨을 분리한 뒤, 단기 임대 Mac을 동적 용량으로 연결해 실제 큐 변화와 준비 시간을 측정하는 방식입니다.

장기간 사용할 Mac 환경의 제공 방식과 지역별 선택지를 함께 검토해야 한다면 SFTPMAC의 원격 Mac 제공 안내에서 현재 제공 범위와 접속 방식을 확인할 수 있습니다. 실제 Jenkins 연결 전에는 네트워크 경로, Agent 실행 방식, 사설 저장소 접근 정책을 별도로 검증해야 합니다.

최종 승인용 실행 목록

• [ ] PR, 테스트, 서명, 배포 작업에 서로 다른 Jenkins 라벨을 지정합니다.
• [ ] PR 동적 노드에서 인증서와 배포 자격 증명이 보이지 않는지 확인합니다.
• [ ] 작업 공간, Agent 프로세스, 실제 Mac 호스트, 키체인 폐기를 각각 기록합니다.
• [ ] 냉시작, 사전 준비 이미지, 온풀을 같은 프로젝트로 비교합니다.
• [ ] 노드 준비 시간과 첫 작업 완료 시간을 기업 기록으로 남깁니다.
• [ ] 동적 노드 회수 실패 뒤 해당 호스트가 자동 재사용되지 않는지 시험합니다.
• [ ] 고정 서명 노드가 오프라인일 때 작업이 일반 테스트 노드로 잘못 가지 않는지 확인합니다.
• [ ] 큐가 급증하는 상황에서 동적 용량을 추가하고 회복 결과를 기록합니다.
• [ ] Jenkins 플러그인의 공식 문서와 유지 상태를 검토한 뒤 공급 방식을 승인합니다.
• [ ] 위 증거를 바탕으로 고정 기준 풀과 탄력 풀의 규모를 다시 결정합니다.

현재 장비만으로 운영하면 배포 피크 때 큐가 길어지고, 개발자별 Mac을 추가 구매하면 유휴 자원과 교체·관리 부담이 커집니다. 단일 장기 Mac을 여러 프로젝트가 공유하는 방식은 작업 공간 잔류와 서명 권한 분리를 어렵게 만들 수 있습니다. 이런 상황에서 SFTPMAC의 원격 Mac 임대는 비서명 테스트와 단기 피크 용량을 별도 풀로 시험하는 선택지가 됩니다. 다만 장기간의 안정적인 고부하, 물리 포트 접근, 전용 보안 장비가 필요한 팀이라면 자체 Mac 인프라가 더 적합합니다.

실행 순서는 간단합니다. 기존 Jenkins에서 비서명 작업을 별도 라벨로 분리하고, 단기 원격 Mac으로 A/B 시험을 진행합니다. 준비 지연, 큐 변화, 회수 증거가 기준을 통과할 때만 탄력 풀을 확대해야 합니다. 생산 서명 Mac을 곧바로 동적 Agent로 바꾸는 결정은 마지막 단계로 미루는 편이 안전합니다.