맥은 재시작되어 에스에이치 접속도 되지만 서명 파이프라인만 오프라인입니다.
가장 빠른 해법은 키체인, 코드 서명 또는 시뮬레이터가 필요한 씨아이 에이전트를 전용 서비스 계정의 런치 에이전트로 실행하고, 런치 데몬은 호스트 점검과 복구 보조에만 배치하는 것입니다. 즉, 맥 빌드 머신 launchd는 둘 중 하나를 고르는 문제가 아니라 시스템 복구 계층 + 사용자 빌드 계층으로 설계해야 합니다.
이 글은 맥 빌드 노드를 무인으로 운영하는 IT 책임자, 아이오에스 서명과 시뮬레이터 테스트를 담당하는 플랫폼 책임자, 원격 맥 자원을 구매하고 검수하는 기술 책임자를 위한 내용입니다. 단순히 프로세스가 살아 있는지 확인하는 방법이 아니라 실제 빌드가 성공하는지까지 검수합니다.
상태를 시간표가 아니라 운영 지표로 나누기
맥오에스에서 다음 상태는 서로 다릅니다.
| 운영 지표 | 의미 | 생산 빌드에 필요한 판단 |
|---|---|---|
| 시스템 시작 | 운영체제가 부팅된 상태 | 호스트 점검만 가능 |
| 디스크 잠금 해제 | 저장 장치에 접근할 수 있는 상태 | 파일 접근 조건 확인 |
| 사용자 로그인 | 사용자 세션과 사용자 키체인이 열린 상태 | 사용자 빌드 준비 |
| 에이전트 온라인 | 씨아이 에이전트가 제어기에 등록된 상태 | 작업 수신 가능성 확인 |
| 실제 빌드 성공 | 서명, 테스트, 산출물 업로드 완료 | 생산 복구 완료 |
애플은 런치 데몬을 시스템 문맥의 서비스로, 런치 에이전트를 사용자 로그인 문맥의 프로세스로 설명합니다. 따라서 “부팅 뒤 자동 시작”과 “사용자 로그인 뒤 시작”은 같은 조건이 아닙니다. 애플의 런치 작업 설명도 이 실행 문맥을 기준으로 구분합니다.
세 가지 실행 모드의 차이
| 모드 | 실행 문맥 | 적합한 역할 | 주요 제한 |
|---|---|---|---|
| 런치 데몬 | 시스템 | 호스트 상태 점검, 네트워크 확인, 복구 신호 | 사용자 키체인과 윈도 서비스 의존 작업에 부적합 |
| 전역 런치 에이전트 | 로그인한 사용자 세션 | 조직 전체에 배포하는 사용자 작업 | 로그인하지 않으면 실행 조건이 성립하지 않음 |
| 사용자 런치 에이전트 | 특정 서비스 계정 세션 | 서명, 시뮬레이터, 씨아이 빌드 | 계정 세션과 권한을 별도로 관리해야 함 |
맥 빌드 머신을 재시작한 뒤 씨아이 에이전트를 자동으로 올리려면 어떻게 해야 합니까?
먼저 해당 에이전트가 공식적으로 지원하는 맥오에스 서비스 모드를 확인해야 합니다. 예를 들어 깃랩의 맥 실행기 문서는 사용자 모드 런치 에이전트 설치를 지원 방식으로 안내합니다. 이를 모든 씨아이 도구의 공통 규칙으로 확대하면 안 되지만, 사용자 세션이 필요한 에이전트를 런치 데몬으로 옮기지 말아야 한다는 검증 사례가 됩니다. 깃랩의 맥 실행기 설치 문서를 설치 전에 확인해야 합니다.
키체인과 시뮬레이터가 결정하는 빌드 계층
아이오에스 빌드는 단순한 명령 실행이 아닙니다. 다음 의존성이 어느 계정과 세션에 연결되어 있는지가 핵심입니다.
- 서명 인증서와 프로비저닝 자산을 읽는 키체인
- 임시 키체인을 만들고 잠금 상태를 제어하는 작업
- 아이오에스 시뮬레이터와 그래픽 세션
- 서비스 계정의 홈 디렉터리와 작업 공간
- 네트워크 권한, 소스 저장소, 비밀 저장소 접근 정책
런치 데몬은 시스템 계정으로 시작될 수 있지만, 사용자 로그인 세션에 속한 키체인이나 그래픽 서비스가 같은 방식으로 준비된다고 가정할 수 없습니다. 애플의 키체인 기술 문서는 키체인의 유형과 사용 범위를 구분하므로, 인증서를 설치했다는 사실만으로 무인 서명이 보장되지는 않습니다. 맥 키체인 기술 문서를 기준으로 인증서 저장 위치와 잠금 해제 정책을 기록해야 합니다.
| 의존성 | 시스템 계층에서 확인할 항목 | 사용자 빌드 계층에서 확인할 항목 |
|---|---|---|
| 코드 서명 | 호스트가 접근 가능한지 | 전용 계정의 키체인과 서명 권한 |
| 시뮬레이터 | 관련 서비스가 설치되었는지 | 사용자 세션에서 장치 생성과 테스트 실행 |
| 작업 디렉터리 | 디스크와 파일 시스템 상태 | 홈 경로, 소유권, 잔여 작업 정리 |
| 네트워크 | 호스트 연결과 이름 해석 | 저장소와 씨아이 제어기 인증 |
| 비밀 정보 | 비밀을 읽지 않는 점검 | 필요한 작업에서만 제한적으로 사용 |
코드 서명 결과는 애플의 배포용 서명 코드 안내와 조직의 인증서 관리 정책을 함께 대조해야 합니다. 비밀 정보를 읽는 프로세스를 시스템 복구 계층에 넣으면 장애 복구 편의보다 노출 범위가 커질 수 있습니다.
주의: 런치 데몬이 에이전트 프로세스를 다시 실행했다는 로그만으로 키체인 사용 가능성을 판정하면 안 됩니다. 서명된 테스트 산출물과 시뮬레이터 테스트 결과가 남아 있어야 빌드 복구로 인정할 수 있습니다.
재시작 복구는 네 가지 증거로 판정하기
파일볼트가 켜진 맥은 전원 복구와 디스크 잠금 해제가 분리될 수 있습니다. 애플은 파일볼트가 시동 디스크의 데이터를 보호하며 인증 없이는 디스크 접근이 제한된다고 설명합니다. 파일볼트 보안 안내를 기준으로 조직의 재시작 정책과 원격 접근 방식을 확인해야 합니다.
파일볼트가 켜진 원격 맥에서 무인 빌드를 복구하려면 무엇을 검증해야 합니까?
최소한 다음 네 가지 상황을 각각 기록해야 합니다.
- 정상적인 재시작 뒤 호스트가 다시 연결되는지 확인합니다.
- 계획된 재시작 뒤 사용자 세션과 에이전트 등록이 회복되는지 확인합니다.
- 예기치 않은 전원 차단 뒤 같은 복구 경로가 작동하는지 확인합니다.
- 사용자가 로그아웃한 뒤 빌드 계층이 중단되고, 승인된 로그인 절차 뒤 다시 등록되는지 확인합니다.
애플의 맥 시작 문제 해결 안내도 전원과 시동 과정의 상태를 나누어 점검하도록 안내합니다. 애플의 맥 시동 문제 해결 문서를 운영 기록의 기준 자료로 연결해 두면, “콘솔에 보인다”와 “생산 작업을 완료했다”를 구분하기 쉽습니다.
복구 검증 기록의 최소 형식
| 검증 단계 | 합격 증거 | 불합격으로 보는 경우 |
|---|---|---|
| 호스트 접근 | 에스에이치 또는 관리 채널 연결 | 호스트만 온라인으로 보이고 접속 불가 |
| 사용자 세션 | 전용 계정의 세션과 홈 경로 확인 | 시스템 계정만 살아 있음 |
| 에이전트 등록 | 씨아이 제어기에 새 작업을 받을 수 있음 | 프로세스는 있으나 등록되지 않음 |
| 키체인 | 서명에 필요한 자산을 읽음 | 인증서 오류 또는 잠금 오류 |
| 실제 빌드 | 서명, 테스트, 산출물 업로드 완료 | 빈 작업 또는 단순 상태 확인만 성공 |
최소 권한은 실행 계정으로 결정하기
단일 관리자 계정으로 모든 계층을 실행하면 설정은 단순해 보이지만, 소스 코드와 서명 자산, 네트워크 자격 증명이 같은 경계에 놓입니다. 반대로 시스템 계층을 별도 점검 계정이나 제한된 시스템 작업으로 두고, 실제 빌드는 전용 서비스 계정으로 분리하면 장애 원인과 접근 범위를 함께 줄일 수 있습니다.
런치 에이전트와 런치 데몬 중 어느 쪽이 아이오에스 씨아이에 적합합니까?
키체인, 코드 서명, 시뮬레이터 또는 사용자 홈 디렉터리가 필요한 아이오에스 씨아이에는 전용 서비스 계정의 런치 에이전트가 일반적으로 적합합니다. 런치 데몬은 호스트 접근성, 디스크 상태, 에이전트 등록 보조와 같은 시스템 점검에 배치하는 편이 안전합니다. 단, 특정 에이전트의 공식 설치 문서가 다른 방식을 명시하면 그 문서와 기업 보안 정책을 우선해야 합니다.
id ci-service
launchctl print "user/$(id -u ci-service)"
launchctl print system
위 명령은 계정과 실행 영역을 확인하는 최소 점검 예시입니다. 출력에 에이전트의 실제 등록 상태가 나타나는지, 홈 경로가 기대한 전용 계정으로 연결되는지 기록해야 합니다. 단순히 프로세스 이름만 찾는 방식은 잘못된 계정으로 실행된 작업을 놓칠 수 있습니다.
- [ ] 빌드 전용 계정과 관리자 계정을 분리했습니다.
- [ ] 시스템 계층은 서명 인증서와 배포 비밀에 접근하지 않습니다.
- [ ] 사용자 계정의 홈 경로와 작업 공간 소유권을 확인했습니다.
- [ ] 임시 키체인의 생성, 잠금, 삭제 절차를 기록했습니다.
- [ ] 저장소와 산출물 저장소에 필요한 네트워크 권한만 허용했습니다.
- [ ] 원격 재시작 권한을 승인된 운영자에게만 부여했습니다.
- [ ] 실패한 작업의 로그와 비밀 정보가 함께 노출되지 않는지 확인했습니다.
로그와 업그레이드로 지속 장애를 구분하기
런치 설정에 항상 재시작 옵션을 넣는다고 안정성이 생기는 것은 아닙니다. KeepAlive가 지속적인 설정 오류나 잘못된 계정 문제를 가리면 프로세스가 반복해서 죽고 다시 시작하는 상태가 오래 이어질 수 있습니다.
각 노드에는 다음 항목을 남겨야 합니다.
- 실행 영역: 시스템인지 특정 사용자 영역인지
- 작업 식별자와 설정 파일 버전
- 표준 출력 및 오류 로그 위치
- 마지막 종료 상태와 재시작 횟수
- 운영체제, 개발 도구, 씨아이 에이전트 변경 기록
- 실제 빌드 식별자와 서명 결과
애플은 시스템 서비스 설계에서 데몬의 실행 조건과 관리 영역을 분리해 설명합니다. 시스템 데몬 설계 안내를 참고해, 사용자 빌드 작업을 시스템 복구 작업처럼 취급하지 않도록 구성해야 합니다.
업데이트는 기존 생산 노드에서 바로 진행하지 않습니다. 격리 노드에서 운영체제 업데이트, 씨아이 에이전트 업데이트, 런치 설정 변경을 각각 시험하고, 변경 전후에 동일한 서명과 시뮬레이터 작업을 실행합니다. 프로세스가 온라인으로 표시되더라도 사용자 세션이 사라졌거나 키체인이 잠긴 경우에는 승인하지 않아야 합니다.
생산 투입을 결정하는 세 가지 구성
| 구성 | 선택 조건 | 거부 조건 |
|---|---|---|
| 사용자 런치 에이전트 단일 계층 | 단일 사용자 세션이 항상 보장되고 운영 규모가 작음 | 파일볼트 복구, 원격 로그인, 별도 호스트 점검이 필요함 |
| 런치 데몬 단일 계층 | 호스트 감시와 시스템 복구만 수행함 | 서명, 시뮬레이터, 사용자 키체인을 직접 실행함 |
| 이중 계층 | 시스템 복구와 사용자 빌드를 분리함 | 두 계층의 로그와 권한을 관리할 운영 체계가 없음 |
기본 선택은 이중 계층입니다. 시스템 계층은 호스트 상태, 연결, 디스크와 에이전트 복구 신호를 담당하고, 사용자 계층은 전용 계정으로 실제 빌드와 서명을 수행합니다. 두 계층 사이에는 비밀 정보를 직접 전달하지 않고, 제한된 상태 확인과 승인된 재시작 신호만 교환하는 방식이 바람직합니다.
두 번째 단계: 운영 승인 전 실행할 절차
- 씨아이 에이전트의 공식 맥오에스 서비스 모드를 확인합니다.
- 전용 서비스 계정과 홈 디렉터리를 만듭니다.
- 사용자 계정의 런치 에이전트로 빈 테스트 작업을 실행합니다.
- 임시 키체인과 서명 인증서를 정책에 맞게 연결합니다.
- 시뮬레이터 생성, 테스트, 서명 산출물 생성을 각각 실행합니다.
- 런치 데몬 계층에서 호스트 접근성과 디스크 상태만 확인합니다.
- 정상 재시작, 계획된 재시작, 전원 차단, 로그아웃 조건을 분리해 시험합니다.
- 에스에이치, 사용자 세션, 에이전트 등록, 키체인, 실제 빌드의 증거를 저장합니다.
- 원격 재시작 뒤 예비 노드로 작업을 넘길 수 있는지 확인합니다.
- 설정과 에이전트 버전을 고정하고 변경 승인 기록을 남깁니다.
현재 맥 노드에 독립적인 사용자 세션, 원격 재시작, 예비 용량이 모두 없다면 런치 설정만 고쳐 생산 수준의 복구성을 만들기 어렵습니다. 이 경우 원격 맥 자원 구성 확인을 통해 필요한 권한과 운영 절차를 먼저 대조하고, 서울 맥 미니 주문 안내처럼 실제 배치 위치와 접근 방식을 검토할 수 있습니다.
현재 방식이 개인 장비나 단일 사내 맥 미니에 의존한다면 재시작 뒤 사용자 세션을 보장하기 어렵고, 원격 전원 제어와 예비 노드가 부족하며, 장비 장애 때 복구 증거를 남기기 어렵다는 문제가 있습니다. 반면 NodeMini의 원격 맥 임대는 독립된 맥 자원과 원격 운영 절차를 기준으로 검토할 수 있으므로, 기존 노드가 무인 복구 조건을 충족하지 못할 때 대체 후보가 될 수 있습니다. 장기적으로 고정된 대규모 부하나 물리 장치 연결이 필요하면 직접 구매가 더 적합할 수 있지만, 임시 씨아이 용량과 복구 검증용 노드가 필요하다면 원격 맥 임대 구성을 비교하는 편이 현실적입니다.
이번 주에는 기존 노드에서 다섯 가지 증거, 즉 호스트 접근, 사용자 세션, 에이전트 등록, 키체인 사용, 실제 서명 빌드를 차례로 기록해야 합니다. 하나라도 빠지면 “재시작 복구 완료”가 아니라 “부분적으로 온라인”으로 분류하고, 이중 계층 구성 또는 독립 복구가 가능한 새 원격 맥 노드를 검토해야 합니다.