iOS CI 서명 노드는 기본적으로 일반 빌드와 분리해야 합니다. 하나의 앱을 낮은 빈도로 출시하는 소규모 팀만 독립 계정, 임시 키체인, 엄격한 작업 경로, 재시작 검증을 모두 적용할 수 있을 때 한 대의 맥에서 논리적으로 나눌 수 있습니다.
이 글은 다음 담당자를 위한 판단 기준입니다.
- 기업 정보기술 책임자: 서명 노드의 격리, 원격 복구, 감사 기준을 정해야 하는 담당자입니다.
- 개발 생산성 책임자: 일반 빌드, 아카이브, 서명, 업로드 작업을 올바른 노드로 보내야 하는 담당자입니다.
- 기술 총괄과 구매 책임자: 공유 맥, 전용 원격 맥, 혼합 노드 풀의 위험과 총소유비용을 비교해야 하는 담당자입니다.
먼저 작업과 민감 자산을 서로 다른 경로로 나눕니다
iOS CI의 작업은 모두 같은 신뢰 수준을 갖지 않습니다.
소스 코드 → 컴파일·테스트 → 아카이브 → 서명 → 업로드
소스 코드와 테스트 작업은 외부 기여나 임시 스크립트의 영향을 받을 수 있습니다. 반면 서명 단계에는 배포 인증서의 개인 키, 프로비저닝 프로필, 앱 배포 연결용 API 키, CI 플랫폼 토큰, 내부 네트워크 권한이 연결될 수 있습니다. Apple은 인증서 종류와 역할을 구분하고 있으며, 인증서 회수는 해당 인증서를 사용하는 배포 흐름에 영향을 줄 수 있다고 설명합니다. Apple 인증서 개요와 인증서 회수 안내를 함께 검토해야 합니다.
환경 변수에 비밀값을 숨기는 것만으로는 이 경계를 만들 수 없습니다. 작업 프로세스가 같은 사용자 계정과 같은 macOS 키체인에 접근하거나 이전 작업의 파일과 로그를 읽을 수 있다면 서명 자산의 실제 신뢰 범위는 넓어집니다. 키체인 항목의 접근 조건도 별도로 설계해야 하며, 키체인 접근 제어 문서는 항목별 접근 통제를 설명합니다.
| 작업 구간 | 주로 사용하는 자산 | 권장 실행 영역 | 실패 시 영향 |
|---|---|---|---|
| 컴파일과 단위 테스트 | 소스 코드, 캐시, 테스트 데이터 | 일반 빌드 풀 | 코드 노출과 빌드 지연 |
| 아카이브 생성 | 소스 코드, 빌드 설정, 아카이브 | 통제된 아카이브 풀 | 잘못된 산출물 |
| 생산 서명 | 개인 키, 인증서, 프로비저닝 프로필 | 전용 신뢰 노드 | 배포 자산 오용 |
| 업로드 | 앱 배포 연결용 API 키, 출시 권한 | 승인된 출시 경로 | 잘못된 앱 출시 또는 권한 오용 |
앱 배포 연결용 API 키는 계정 전체 권한과 같은 의미가 아닙니다. 개발자 계정 역할, 맥 로컬 관리자, CI 플랫폼 권한, 앱 출시 권한은 서로 다른 층위로 기록해야 합니다. 개발자 역할과 권한 안내와 앱 배포 연결용 API 안내를 기준으로 책임을 나누는 편이 안전합니다.
팀의 운영 성숙도에 따라 노드 경계를 결정합니다
단일 앱을 관리하는 소규모 팀
코드 공급원이 하나이고 담당자가 제한적이며 출시 빈도가 낮다면 같은 맥에서 논리적 분리를 검토할 수 있습니다. 이때 일반 CI 계정은 컴파일과 테스트만 실행하고 출시 계정은 보호된 작업에서만 호출해야 합니다.
필수 조건은 다음과 같습니다.
- 일반 CI 계정과 출시 계정을 분리합니다.
- 서명 자산은 일반 로그인 키체인이 아니라 임시 키체인에 넣습니다.
- 코드 검토 요청, 외부 브랜치, 임시 스크립트가 출시 작업을 호출하지 못하게 합니다.
- 인증서와 개인 키의 접근 주체를 기록합니다.
- 한 번 서명 명령이 성공했다는 사실만으로 승인하지 않습니다.
- 사용자 세션 손실과 시스템 재시작 뒤에도 출시 절차가 재현되는지 확인합니다.
Apple의 키체인 서비스는 애플리케이션이 보안 자산을 저장하고 사용하는 방식을 정의합니다. 키체인 서비스 문서와 키체인 항목의 접근 가능성 문서를 기준으로 잠금 상태와 세션 변화까지 시험해야 합니다.
여러 저장소와 여러 제품 팀
저장소가 늘어나면 같은 실행기에 작업을 몰아넣는 방식의 영향 범위가 커집니다. 작업 디렉터리에 남은 파일, 잘못된 작업 경로, 다른 프로젝트의 높은 권한 토큰이 결합될 수 있기 때문입니다.
이 경우 다음과 같이 세 영역을 나누는 편이 좋습니다.
| 노드 풀 | 허용 대상 | 서명 자산 | 운영 기준 |
|---|---|---|---|
| 일반 빌드 풀 | 내부 제품 팀과 검증 작업 | 없음 또는 비생산 자산 | 작업 뒤 디렉터리와 캐시 정리 |
| 통제된 아카이브 풀 | 승인된 저장소와 출시 후보 | 제한된 프로필 | 저장소와 브랜치별 허용 규칙 |
| 생산 서명 풀 | 지정된 출시 주체 | 생산 인증서와 개인 키 | 별도 관리자, 로그, 회수 절차 |
자체 호스팅 실행기는 작업 실행 위치와 네트워크 접근을 조직이 직접 관리한다는 장점이 있지만, 신뢰할 수 없는 작업을 실행하면 호스트와 그 자산이 영향을 받을 수 있습니다. 자체 호스팅 실행기 보안 안내는 신뢰하지 않는 코드와 실행기의 관계를 확인하는 출발점입니다. 실행기를 추가하고 제거하는 절차도 실행기 관리 안내에 따라 기록해야 합니다.
제품 팀, 플랫폼 팀, 외부 협력자마다 서명 작업을 호출할 수 있는 범위를 구분합니다. 승인 목록에는 저장소, 브랜치, 작업 주체, 대상 앱, 업로드 권한을 함께 적습니다. 작업 뒤 정리 기록과 프로젝트 간 접근 시험 결과가 없으면 “분리했다”고 판단하지 않는 편이 좋습니다.
금융·의료·공공 분야와 감사 대상 조직
규제 수준이 높은 조직에서는 서명 노드를 단순한 빌드 서버가 아니라 독립된 출시 영역으로 취급해야 합니다. 전용 노드를 두는 것만으로 감사 요건이 충족되지는 않습니다.
다음 책임을 서로 구분해 기록합니다.
- 누가 인증서와 개인 키 발급을 신청하는가
- 누가 노드에 자산을 가져오는가
- 어떤 작업이 자산을 호출할 수 있는가
- 누가 회수와 교체를 승인하는가
- 장애 뒤 누가 복구하고 증거를 남기는가
- 앱 배포 업로드 권한은 누가 보유하는가
맥 로컬 관리자는 개발자 계정 역할과 같지 않습니다. CI 플랫폼 관리자는 앱 출시 승인자와 같지 않습니다. 한 사람이 여러 역할을 맡더라도 승인과 실행 기록은 분리해야 합니다.
주의: 인증서, 개인 키, 프로비저닝 프로필, 키체인, 연결용 API 키, CI 토큰, 로컬 계정을 “서명 자격 증명”이라는 한 항목으로 묶어 관리하면 회수 범위와 복구 책임을 잘못 판단하기 쉽습니다.
조건에 따라 공유·전용·혼합 구조를 선택합니다
아래 조건 분기는 구매나 구축 전에 사용할 수 있는 결정 도구입니다.
- 하나의 앱이며 출시 빈도가 낮고 담당자와 코드 공급원이 안정적이면, 같은 맥의 논리적 격리를 선택할 수 있습니다. 단, 임시 키체인과 재시작 검증을 통과해야 합니다.
- 여러 저장소가 하나의 실행기를 공유하거나 외부 코드가 실행되면, 일반 빌드와 생산 서명을 분리합니다.
- 여러 제품 팀이 서로 다른 출시 권한을 가지면, 통제된 아카이브 풀과 생산 서명 풀을 나눕니다.
- 감사 증거, 네트워크 출구, 독립 관리자, 자격 증명 교체 책임이 요구되면, 전용 신뢰 노드로 전환합니다.
- 생산 출시는 안정적이지만 검증과 일반 빌드 수요가 변동하면, 전용 서명 노드와 탄력적인 원격 맥 빌드 풀을 결합합니다.
- 재시작, 사용자 제거, 인증서 회수 중 하나라도 복구되지 않으면, 해당 노드를 생산 서명에 사용하지 않습니다.
| 선택지 | 고정 용량과 비용 구조 | 장애 영향 | 적합한 조직 |
|---|---|---|---|
| 공유 맥 | 유휴 자원을 줄일 수 있으나 권한 설계와 정리 비용이 큼 | 일반 작업 문제가 서명 영역으로 번질 수 있음 | 단일 앱의 소규모 팀 |
| 전용 원격 맥 | 서명 영역을 고정할 수 있으나 유휴 시간과 운영 책임이 생김 | 해당 출시 노드 장애에 집중됨 | 안정적인 생산 출시와 감사 대상 조직 |
| 혼합 노드 풀 | 일반 작업은 탄력적으로 늘리고 서명 영역은 고정함 | 노드 간 작업 경계와 경로 지정 검증이 필요함 | 여러 팀과 변동성 있는 출시 조직 |
여기서 비교해야 할 총소유비용은 임대료나 장비 구매가만이 아닙니다. 예비 노드, 관리자 작업 시간, 인증서 교체, 장애 복구, 감사 증거 수집, 사용하지 않는 용량, 퇴역 시 데이터 삭제 절차를 포함해야 합니다. 금액 자료가 확보되지 않은 상태에서 특정 절감률을 가정하면 구매 결정을 왜곡할 수 있습니다.
복구 시험으로 실제 격리를 확인합니다
iOS CI 서명 노드의 검수는 정상 출시 한 번으로 끝내면 안 됩니다. 다음 순서로 별도 실행 기록을 남깁니다.
- 생산 자산이 없는 깨끗한 환경에서 Xcode와 프로젝트 설정을 준비합니다.
- 일반 CI 계정으로 컴파일과 테스트만 실행하고 서명 자산 접근이 거부되는지 확인합니다.
- 승인된 출시 계정으로 임시 키체인을 만들고 인증서, 개인 키, 프로비저닝 프로필을 제한된 방식으로 가져옵니다.
- 보호된 작업 경로에서 아카이브, 서명, 업로드를 수행하고 호출 주체와 대상 앱을 기록합니다.
- 시스템 재시작 뒤 사용자 세션이 사라진 상태에서 키체인 잠금과 작업 복구를 시험합니다.
- 인증서 회수, 담당자 제거, 연결용 API 키 교체를 가정하고 이전 계정과 이전 노드의 접근이 차단되는지 확인합니다.
- 호스트 장애를 가정해 깨끗한 원격 맥에서 필요한 입력만으로 출시 흐름을 다시 만들고, 실패 시 일반 빌드나 수동 출시로 돌아갈 방법을 기록합니다.
복구 문서에는 입력 자산, 실행 책임자, 승인자, 로그 위치, 실패 기준, 되돌림 방법을 함께 적습니다. Apple의 인증서 회수 절차를 기준으로 회수 뒤 어떤 작업이 중단되는지도 사전에 확인해야 합니다.
자주 확인하는 기업 결정 질문
iOS CI 빌드와 서명을 같은 맥에 둘 수 있습니까?
가능하지만 같은 사용자 계정과 같은 키체인을 공유하는 방식은 피해야 합니다. 일반 빌드와 출시 계정, 작업 경로, 자산 접근 조건을 분리하고 재시작과 세션 손실 시험을 통과해야 합니다. 조건 하나라도 충족하지 못하면 전용 서명 노드로 전환하는 편이 안전합니다.
기업 출시에는 전용 맥이 꼭 필요합니까?
낮은 복잡도의 단일 앱 조직에는 항상 필요한 것은 아닙니다. 그러나 다중 저장소, 외부 협력자, 높은 출시 빈도, 감사 증거, 별도 회수 책임이 함께 존재하면 전용 노드가 합리적인 기본값입니다. 전용 장비 여부보다 신뢰 영역과 복구 책임을 독립적으로 운영하는지가 핵심입니다.
공유 맥에서 인증서와 키체인을 어떻게 나눕니까?
계정 분리, 임시 키체인, 저장소별 작업 허용, 실행 뒤 파일과 로그 정리, 프로젝트 간 접근 시험을 함께 적용합니다. 환경 변수만 숨기거나 디렉터리 이름만 바꾸는 것은 격리로 보지 않습니다. 키체인 접근 제어와 항목의 잠금 상태까지 기록해야 합니다.
원격 맥 서명 노드는 어떻게 검수합니까?
깨끗한 환경에서 비생산 자산으로 먼저 흐름을 만들고, 이후 인증서와 프로필을 넣어 아카이브·서명·업로드를 시험합니다. 재시작, 세션 손실, 키체인 잠금, 인증서 회수, 담당자 제거, 호스트 장애를 차례로 검증합니다. 이전 계정과 노드가 생산 자산을 재사용하지 못한다는 증거가 있어야 승인합니다.
마지막으로 임시 시험과 장기 운영을 나눕니다
현재 공유 맥 방식은 장비 수를 줄일 수 있지만 작업 잔여물과 권한 범위가 섞이기 쉽고, 서명 장애가 일반 빌드 장애와 함께 발생하며, 회수와 감사 책임을 나누기 어렵습니다. 반대로 전용 장비를 직접 구매하면 초기 자산과 유휴 용량, 교체 및 복구 작업을 조직이 계속 부담해야 합니다.
따라서 바로 장기 구매를 확정하기보다, RUVCLOUD의 원격 맥 환경에서 비생산 인증서를 사용하는 격리 시험을 먼저 진행하는 접근이 적합합니다. 계정, 키체인, 작업 경로 지정, 재시작 복구, 권한 회수를 확인한 뒤 안정적인 생산 출시에는 전용 원격 맥을 남기고, 일반 빌드와 출시 수요가 몰리는 시기에는 혼합 노드 풀을 검토할 수 있습니다. 임대 조건과 운영 범위는 기업용 맥 이용 안내와 요금 정보에서 확인하되, 최종 선택은 가격보다 서명 신뢰 경계와 복구 증거를 먼저 기준으로 삼아야 합니다.