관리형 macOS 에이전트를 먼저 검증하고, 고정된 Xcode 도구 모음·지속 캐시·내부망 접근·통제 가능한 서명 키체인이 필요할 때만 독립 계정으로 실행하는 원격 맥 자체 호스팅 에이전트를 배포해야 합니다. 에이전트가 Online으로 표시되는 것은 등록 완료일 뿐이며, 실제 빌드와 재시작 복구, 서명 파일 격리까지 통과해야 운영 투입이 가능합니다.
이 글은 Azure Pipelines로 iOS 또는 macOS 앱을 빌드하고 테스트하는 개발자를 위한 안내서입니다. 원격 맥을 팀의 Agent Pool에 장기간 연결하려는 DevOps 엔지니어, 인증서와 배포 권한을 분리해야 하는 모바일 플랫폼 관리자에게도 적합합니다.
배포 여부를 조건으로 먼저 나눕니다
Microsoft는 관리형 에이전트와 자체 호스팅 에이전트의 사용 목적을 구분합니다. 관리형 환경은 실행 뒤 깨끗한 작업 환경을 제공하므로 외부 기여 코드나 신뢰하지 않는 스크립트를 실행할 때 우선 검토해야 합니다. 반대로 특정 도구 버전, 사내망 의존성, 장기 캐시처럼 실행 환경을 직접 유지해야 하는 경우에는 자체 호스팅 방식이 맞을 수 있습니다. Azure Pipelines 에이전트 유형과 선택 기준에서 역할 차이를 먼저 확인합니다.
| 조건 | 우선 선택 | 배포 판단 |
|---|---|---|
| 외부 코드가 자주 유입되고 매 실행 격리가 중요함 | 관리형 macOS 에이전트 | 원격 맥을 보류합니다 |
| 고정 Xcode 버전과 사내 의존성이 필요함 | 원격 맥 자체 호스팅 에이전트 | 전용 계정과 풀을 준비합니다 |
| 캐시를 지속 보존해야 하지만 보안 파일은 없음 | 자체 호스팅 또는 캐시 설계 재검토 | 작업 공간 오염을 먼저 시험합니다 |
| 인증서와 키체인을 제한된 노드에서만 사용해야 함 | 분리된 원격 맥 풀 | 서명 단계와 권한을 나눕니다 |
자체 호스팅 노드는 관리형 환경보다 편리하다는 이유만으로 선택하면 안 됩니다. 다음 조건 중 하나라도 충족하지 못하면 관리형 macOS 에이전트로 되돌리는 편이 안전합니다.
- 고정된 Xcode와 명령줄 도구가 실제로 필요하지 않으면 관리형 에이전트를 선택합니다.
- 내부 저장소나 테스트 장비에 접근해야 하면 원격 맥을 검토합니다.
- 빌드 캐시가 이득을 주더라도 프로젝트 간 작업 공간을 분리할 수 없으면 도입하지 않습니다.
- 서명 키체인을 전용 계정과 전용 풀로 제한할 수 없으면 배포 서명을 노드에 두지 않습니다.
전용 계정과 Agent Pool을 분리해 등록합니다
Azure DevOps에 자체 호스팅 macOS Agent를 추가할 때 무엇을 준비해야 합니까?
먼저 조직 관리자 권한을 남용하지 않도록 에이전트 전용 시스템 계정을 만듭니다. 이 계정은 개발자의 개인 계정과 분리하고, 작업 디렉터리도 전용 경로로 지정합니다. 이후 Azure DevOps에서 별도의 Agent Pool을 만들고 필요한 프로젝트만 연결합니다. 에이전트 인증 방식은 환경에 따라 달라질 수 있으므로 공식 인증 방식 안내를 확인해야 합니다.
등록 명령은 문서 예시를 그대로 고정하지 말고, 해당 시점의 Azure DevOps 관리 화면이 생성한 내용을 복사합니다. 조직명, 풀 이름, 에이전트 이름, 계정, 경로와 토큰은 다음처럼 자리 표시자로 남겨야 합니다.
mkdir -p <전용_작업_경로>
cd <에이전트_설치_경로>
./config.sh --url <조직_주소> --pool <전용_풀_이름> --agent <에이전트_이름>
인증 인자와 토큰은 콘솔이 제시한 방식으로만 추가합니다. 토큰을 저장소, 셸 기록, 일반 변수에 기록하지 않습니다. 등록 직후에는 다음 세 가지를 확인합니다.
| 확인 항목 | 통과 기준 | 통과하지 못할 때 |
|---|---|---|
| Agent Pool 연결 | 지정한 풀에서 해당 에이전트가 보임 | 조직 주소와 풀 권한을 재검토합니다 |
| 상태 | Online으로 표시됨 |
서비스 또는 네트워크 로그를 확인합니다 |
| 기본 능력 | 운영체제, 아키텍처, 도구 관련 능력이 표시됨 | 도구 설치 뒤 에이전트를 다시 시작합니다 |
Online은 연결 신호일 뿐입니다. Azure Pipelines는 작업의 요구 조건과 에이전트 capabilities를 대조해 실행 노드를 고르므로, 실행 및 에이전트 매칭 방식을 기준으로 확인해야 합니다.
백그라운드 빌드와 그래픽 테스트의 상주 조건을 나눕니다
순수 명령줄 빌드는 로그인 화면과 독립적으로 설계할 수 있지만, Simulator 또는 UI 테스트는 그래픽 세션과 권한 상태에 영향을 받을 수 있습니다. 따라서 SSH 연결이 끊겨도 빌드가 계속되는지, 로그아웃 뒤에도 필요한 테스트가 실행되는지를 별도로 검증해야 합니다.
macOS에서는 제공된 서비스 스크립트와 launchd 기반 방식을 사용해 에이전트를 상주시키는 구성이 일반적입니다. Microsoft의 macOS 에이전트 서비스 설정 문서에 따라 서비스 상태를 확인하고, 임의의 백그라운드 실행 방식으로 대체하지 않는 것이 좋습니다.
./svc.sh status
./svc.sh start
위 명령의 실제 옵션과 실행 결과는 설치된 에이전트 패키지의 안내를 따릅니다. 다음 순서로 세션 의존성을 제거합니다.
- SSH로 접속한 상태에서 작은 명령줄 빌드를 실행합니다.
- SSH 연결을 끊고 같은 종류의 작업을 다시 실행합니다.
- macOS 로그인 세션을 종료한 뒤 명령줄 테스트를 확인합니다.
- 그래픽 테스트가 있다면 필요한 로그인 세션 조건을 문서화합니다.
- 시스템을 재시작한 뒤 Agent Pool 상태와 실제 작업 수신 여부를 확인합니다.
주의: 재시작 뒤
Online으로 돌아와도 작업 디렉터리 권한, 키체인 잠금 상태, Simulator 초기화 여부가 정상이라는 뜻은 아닙니다. 반드시 실제 파이프라인을 다시 실행해야 합니다.
Azure DevOps macOS Agent의 Xcode 능력과 경로를 검증합니다
Azure Pipelines가 Xcode 능력을 가진 에이전트를 찾지 못할 때는 어떻게 합니까?
에이전트에 Xcode가 설치되어 있다는 사실만으로는 충분하지 않습니다. 파이프라인이 요구하는 capability 이름과 실제 노드에 노출된 값이 일치해야 합니다. 새 Xcode를 설치하거나 기본 개발자 경로를 바꾼 뒤에는 에이전트를 다시 시작하고 capabilities를 재확인합니다.
파이프라인에는 필요한 풀과 demands를 명시합니다. 실제 capability 이름과 작업 입력은 사용 중인 콘솔과 공식 작업 문서에 맞춰 조정해야 합니다.
pool:
name: <전용_풀_이름>
demands:
- <필요한_Xcode_능력>
steps:
- script: |
xcode-select -p
xcodebuild -version
xcodebuild -list -workspace <워크스페이스_경로>
displayName: <도구_검증>
Apple의 Xcode 명령줄 도구 참고 문서를 기준으로 xcode-select와 xcodebuild의 경로 및 동작을 확인합니다. 최소 테스트 프로젝트에는 공유 Scheme, 테스트 결과 저장, 빌드 산출물 보관을 포함합니다.
| 검증 단계 | 확인할 증거 | 실패 시 선택 |
|---|---|---|
| 도구 경로 | xcode-select가 의도한 개발자 디렉터리를 가리킴 |
기본 경로를 수정하고 에이전트를 재시작합니다 |
| 프로젝트 발견 | 공유 Scheme과 워크스페이스가 명령줄에서 열림 | 저장소 설정과 계정 권한을 수정합니다 |
| 테스트 실행 | 테스트 결과가 파이프라인 산출물로 남음 | Simulator와 세션 조건을 분리 점검합니다 |
| 경로 라우팅 | demands에 맞는 노드가 작업을 수신함 | capability 이름과 풀 연결을 재검토합니다 |
원격 맥에서 Azure Pipelines의 iOS 작업을 실행하려면 무엇을 확인해야 합니까?
먼저 서명 없는 빌드와 테스트를 통과시킨 뒤, 서명과 아카이브를 별도 단계로 추가합니다. Xcode 작업의 입력값은 Microsoft의 Xcode 작업 문서와 현재 작업 정의를 대조합니다. 이 순서를 지키면 도구 경로 문제와 인증서 문제를 한 번에 조사하는 일을 피할 수 있습니다.
서명 파일은 빌드 노드와 권한을 함께 격리합니다
Azure Pipelines에서 iOS 서명 인증서를 안전하게 사용하는 방법은 무엇입니까?
인증서, 프로비저닝 프로파일과 배포 권한을 저장소에 넣지 않습니다. Azure Pipelines Secure Files에 민감한 파일을 보관하고, 해당 파일을 사용할 수 있는 파이프라인과 승인 범위를 제한합니다. Secure Files 권한과 사용 방식을 기준으로 접근 주체를 확인합니다.
서명 단계는 다음처럼 세 층으로 나누는 편이 좋습니다.
- 서명 없는 빌드: 일반 Agent Pool에서 실행합니다.
- 통제된 아카이브: 제한된 계정과 전용 서명 풀에서 실행합니다.
- 배포: 필요한 권한만 일시적으로 사용하고 작업 뒤 파일과 임시 키체인을 정리합니다.
Azure Pipelines의 보안 권장 사항은 저장소와 변수, 서비스 연결을 같은 신뢰 수준으로 취급하지 않도록 안내합니다. 여러 프로젝트가 한 원격 맥을 공유한다면 비서명 작업과 민감한 서명 작업을 서로 다른 Agent Pool로 나누고, 작업 종료 뒤 프로파일과 임시 파일이 남지 않는지 확인합니다.
복구와 작업 공간 위생을 통과한 뒤 운영에 넣습니다
자체 호스팅 원격 맥의 숨은 비용은 설치보다 운영에서 발생합니다. 캐시가 계속 쌓이면 디스크 관리가 필요하고, 이전 작업의 산출물이 다음 작업에 섞일 수 있습니다. 동시 작업을 허용하면 키체인과 Simulator 상태가 충돌할 수 있으며, 에이전트 업데이트와 Xcode 업데이트의 책임 주체도 미리 정해야 합니다.
최종 승인 전에는 아래 조건을 모두 체크합니다.
- [ ] 연속된 성공 작업에서 저장소 checkout과 캐시 동작을 확인했습니다.
- [ ] 실패한 작업 뒤 재시도해 이전 산출물이 재사용되지 않았습니다.
- [ ] 작업 디렉터리와 임시 서명 파일의 정리 결과를 확인했습니다.
- [ ] SSH 연결 종료와 시스템 재시작 뒤 에이전트가 작업을 다시 받았습니다.
- [ ] 에이전트 업데이트 뒤 capability와 Xcode 경로를 재확인했습니다.
- [ ] 서명 없는 빌드와 제한된 서명 아카이브를 각각 성공시켰습니다.
- [ ] 디스크 증가, 동시 실행 정책, 업데이트 담당자를 운영 문서에 기록했습니다.
| 최종 결과 | 의미 | 다음 조치 |
|---|---|---|
| 모든 검증 통과 | 운영용 자체 호스팅 노드로 사용 가능 | 변경 관리와 정기 재검증을 시작합니다 |
| 빌드는 되지만 서명 격리 실패 | 개발용으로만 제한 가능 | 서명 전용 풀을 별도로 만듭니다 |
| 재시작 또는 그래픽 테스트 실패 | 운영 투입 불가 | 세션 조건을 수정하거나 관리형 환경으로 돌아갑니다 |
| 캐시와 작업 공간 오염 반복 | 공유 노드 구조가 부적합함 | 노드를 분리하거나 캐시를 포기합니다 |
예산을 비교할 때는 하드웨어 구매액만 보지 말고, 고정 Xcode 유지, 원격 접속 관리, 디스크 정리, 인증서 사고 대응과 유휴 시간까지 함께 계산해야 합니다. 장기간 고정 부하이고 물리 장비나 특수 주변기기가 필요하면 자체 구매가 더 맞을 수 있습니다. 반대로 테스트 기간이 제한적이거나 팀이 전용 Mac을 유지할 운영 인력이 없다면 RUVCLOUD의 원격 맥 구성과 이용 기간을 확인한 뒤 작은 검증 환경부터 시작하는 편이 합리적입니다. 요금 선택 기준도 관리형 에이전트와 비교할 때의 비용 항목을 정리하는 데 활용할 수 있습니다.
기존 Windows 또는 Linux 서버만으로 Apple 플랫폼 빌드를 처리하면 Xcode 도구 모음, macOS 전용 테스트, 키체인 제어를 별도로 우회해야 하고, 가상 환경은 그래픽 세션과 도구 호환성 검증 부담이 남습니다. Mac mini를 직접 운영하면 장비 구매와 장애 대응, 상시 전원 및 네트워크 관리가 따라옵니다. 고정된 Xcode와 독립 권한 계정이 필요한 기간에만 실제 원격 맥을 임대하면 이런 운영 부담을 줄이면서 전용 Agent Pool을 구성할 수 있으므로, 최소 파이프라인 검증을 마친 뒤 RUVCLOUD의 노드 조건과 임대 기간을 대조해 결정하는 것이 안전합니다.