컨트롤러는 작업을 조정하고, Mac Agent는 Xcode가 필요한 단계를 실행하도록 구성하세요. Jenkins는 노드 라벨로 실행 환경의 특성을 표현하고, Pipeline은 라벨을 기준으로 실행할 Agent를 선택할 수 있습니다. Jenkins Agent 문서와 Pipeline 문법 안내에서 해당 기능을 확인할 수 있습니다.

이 구분은 모든 기업에 강제되는 단일 설계가 아니라, 컨트롤러의 자원 경합을 줄이고 Apple 플랫폼 작업을 필요한 환경에 배치하기 위한 운영 권장안입니다. 다음처럼 라벨을 용도에 맞게 정하세요.

• macos-xcode: Xcode를 사용하는 빌드와 테스트
• macos-simulator: 시뮬레이터 실행이 필요한 작업
• macos-signing: 신뢰된 배포 작업

라벨 이름은 팀이 정할 수 있습니다. 중요한 점은 이름이 아니라 해당 라벨을 가진 Agent의 환경과 접근 권한이 실제 작업에 맞는지입니다. 컨트롤러에서 일반 검사까지 실행할 필요가 있는지 따져 보고, Apple 도구가 필요하지 않은 단계는 기존의 범용 실행 환경에 남겨도 됩니다.

모든 파이프라인 단계를 맥에서 돌릴 필요는 없습니다. 소스 형식 검사나 Xcode에 의존하지 않는 검사는 범용 실행 환경에서 처리하고, xcodebuild가 필요한 빌드 단계만 Mac Agent로 보내면 작업 범위를 명확하게 유지할 수 있습니다.

Pipeline에서 특정 Agent 라벨을 선택하는 예시는 다음과 같습니다.

pipeline {
    agent none

    stages {
        stage('검사') {
            agent any
            steps {
                sh '프로젝트의 일반 검사 명령'
            }
        }

        stage('맥 빌드') {
            agent { label 'macos-xcode' }
            steps {
                sh 'xcodebuild -scheme 앱스킴 build'
            }
        }
    }
}

예시의 앱스킴과 검사 명령은 팀 저장소에 맞게 바꿔야 합니다. 설정을 적용한 뒤에는 다음을 확인하세요.

• 작업 디렉터리가 예상한 저장소와 경로를 가리키는지
• 실제 빌드에 사용하는 Xcode가 선택되어 있는지
• Jenkins 서비스 계정으로 빌드가 완료되고 결과물이 생성되는지

콘솔 터미널에서 성공한 명령을 그대로 Jenkins 작업에서도 실행할 수 있다고 가정하지 마세요. 실행 계정과 환경 변수가 다르면 결과가 달라질 수 있습니다.

Jenkins Agent의 연결은 시뮬레이터 테스트 준비 상태를 보장하지 않습니다. Apple 문서에 따르면 xcodebuild 등 Xcode 명령줄 도구는 Xcode와 함께 제공되며, 적절한 개발자 디렉터리를 사용해야 합니다. 명령줄 도구 설치 안내와 Xcode 명령줄 도구 참고 문서를 확인하고, 팀이 사용하는 Xcode 설치와 활성 개발자 디렉터리를 맞추세요.

대상 Mac Agent에서 Jenkins 서비스 계정으로 다음을 검사할 수 있습니다.

xcode-select -p
xcodebuild -version
xcodebuild -scheme 앱스킴 -destination '팀에서 사용하는 대상' test

첫 번째와 두 번째 명령은 활성 개발자 경로와 Xcode 버전을 확인하는 데 사용합니다. 마지막 명령의 스킴과 대상은 실제 프로젝트 설정에 맞춰야 합니다. 시뮬레이터가 시작됐다는 로그만으로 성공 처리하지 말고, 테스트 명령의 종료 상태와 결과 보고서를 확인하세요. 테스트 단계가 끝난 뒤에도 전체 파이프라인이 산출물 생성과 후속 전달을 완료하는지 따로 검증해야 합니다.

Agent가 온라인인데 xcodebuild가 실패한다면 Jenkins 서비스 계정, Xcode 설치, 활성 개발자 디렉터리를 먼저 확인하세요. 관리자 계정의 대화형 터미널에서 성공했다는 사실만으로 Agent 환경을 승인하지 마세요.

서명 및 배포 작업은 일반 커밋 빌드와 같은 권한으로 취급하지 마세요. 신뢰할 수 있는 변경만 생산 서명 노드에 도달하도록 작업 권한과 Agent 라벨을 함께 검토하세요. Jenkins의 자격 증명 보안 안내는 비밀 정보가 로그에서 가려져도 악의적이거나 신뢰할 수 없는 Pipeline이 이를 읽는 위험까지 막아 주지는 않는다고 설명합니다.

따라서 라벨은 작업을 올바른 노드로 보내는 수단이지, 그 자체로 완전한 격리 경계가 아닙니다. 배포 권한이 필요한 작업의 작성·실행 권한, 자격 증명 사용 범위, 노드에 접근할 수 있는 주체를 별도로 점검하세요. 다중 브랜치 작업을 운영한다면 Jenkins의 조직 폴더와 다중 브랜치 Pipeline 보안 설명도 함께 살펴보세요.

사설 코드 저장소, 의존성 공급원, Apple 서비스에 필요한 접속 대상은 보안·네트워크 담당자와 함께 정리하세요. 확인하지 않은 도메인이나 포트를 미리 열어 두는 대신, 팀의 실제 구성에 필요한 접근 목록을 승인받아야 합니다.

이후 Jenkins Agent가 사용하는 계정으로 저장소 접근, 프록시 설정, 인증서 신뢰 여부를 시험하세요. 관리자 계정의 셸에서 저장소를 내려받을 수 있어도 Jenkins 계정에는 같은 인증 정보나 네트워크 환경이 없을 수 있습니다. 의존성 오류를 Xcode 문제로 오판하지 않도록, 코드 체크아웃과 의존성 해석을 각각 실행해 실패 지점을 구분하세요.

구성 방식을 고를 때는 처리 대상과 신뢰 수준을 기준으로 삼으세요. 다음 조건 분기로 시작하면 불필요하게 모든 작업을 맥에 몰아주지 않을 수 있습니다.

• Xcode나 Apple 플랫폼 도구가 필요하면 해당 라벨을 가진 Mac Agent로 보내고, 필요하지 않으면 범용 실행 환경에 둡니다.
• 시뮬레이터가 필요한 테스트라면 대상 Agent에서 프로젝트의 테스트 명령을 실행하고 결과 보고서까지 확인합니다. 시뮬레이터 실행만 확인했다면 테스트 통과로 승인하지 않습니다.
• 생산 서명 자격 증명이 필요하다면 신뢰된 배포 작업만 허용하는 노드와 권한 정책을 검토합니다. 작업 출처와 권한을 제한할 수 없다면 자동 서명 배포를 보류합니다.
• 사설 의존성이 있다면 Jenkins 서비스 계정으로 접속을 검증합니다. 관리자 계정에서만 성공한다면 네트워크·인증·인증서 조건을 다시 확인합니다.

아래 표는 이 조건을 작업별로 정리한 것입니다. 노드를 무조건 늘리기보다 필요한 도구와 권한을 분리하는 기준으로 사용하세요.

원격 맥 노드를 검토한다면 한국 주문 안내에서 공개된 주문 조건을 확인하고, Jenkins Agent 연결은 실제 인수 검증으로 별도 확인하세요.

운영 투입 전에는 실제 저장소를 기준으로 작업 디렉터리, 도구 선택, 빌드, 시뮬레이터 테스트, 서명·배포, 사설 의존성 접속을 차례로 확인하세요. 단순한 Agent 연결 확인이나 빈 Pipeline의 성공은 이 검증을 대신할 수 없습니다.

Jenkins에서 iOS 빌드를 맥 Agent로 보내려면 어떻게 해야 하나요?

맥 Agent에 작업 특성을 나타내는 라벨을 지정하고, Pipeline에서 해당 라벨을 실행 대상으로 선택합니다. Xcode 빌드용 라벨을 별도로 두면 일반 검사와 Apple 도구가 필요한 작업을 구분하기 쉽습니다. 라벨이 맞는지만 보지 말고 실제 저장소의 작업 디렉터리, 도구 체인, 빌드 결과까지 확인해야 합니다.

Agent가 온라인인데 xcodebuild가 실패하면 무엇을 확인해야 하나요?

Agent 연결 상태와 Xcode 작업 준비 상태는 별개입니다. Jenkins 서비스 계정으로 실행되는지, Xcode가 설치되어 있는지, 활성 개발자 디렉터리가 올바른지 확인한 뒤 프로젝트의 빌드 명령을 실행하세요. 관리자 계정의 터미널에서만 성공한다면 권한이나 환경 변수 차이가 남아 있을 수 있습니다.

시뮬레이터 테스트와 배포 서명에 같은 노드를 써도 되나요?

노드를 나눌지는 작업량뿐 아니라 신뢰 경계와 자격 증명 접근 범위로 판단해야 합니다. 신뢰되지 않는 변경이 실행될 수 있는 테스트 작업과 생산 서명 작업은 별도 라벨과 권한으로 분리하는 편이 안전합니다. 라벨만으로는 보안 격리가 완성되지 않으므로 자격 증명과 노드 접근 정책도 확인해야 합니다.

운영 전에 어떤 작업을 검증해야 하나요?

팀의 실제 저장소로 일반 빌드, 시뮬레이터 테스트, 서명 및 배포 절차를 각각 실행해 결과를 확인하세요. 사설 저장소와 의존성 공급원 접속도 Jenkins 서비스 계정으로 검사해야 합니다. Agent 온라인 표시나 빈 테스트 작업의 성공만으로는 도구 체인, 서명 권한, 산출물 전달이 검증되지 않습니다.

기존 맥 구매 방식은 초기 장비 확보와 교체, 유지 관리 부담이 따르고, 범용 클라우드 실행 환경은 macOS와 Xcode가 필요한 작업을 그대로 맡기기 어렵습니다. 자체 맥을 이미 보유했다면 계속 활용하는 편이 맞을 수 있지만, 팀의 실제 Jenkins 작업을 시험할 임시 노드가 필요하다면 원격 맥 임대도 비교 대상입니다. KVMNODE의 맥 미니 대여 가격 안내에서 현재 공개된 조건을 살펴보고, 계약 전 Agent 접속 방식과 환경, 권한, 실제 파이프라인 검수 조건을 확인하세요. 맥 빌드 머신 구축은 공급 방식보다 팀의 작업으로 검증했는지가 운영 가능성을 결정합니다.