GitLab CI에서 서명 작업이 동시에 실행되지 않게 하려면 어떻게 하나요?

서명이나 배포처럼 공유 자원을 쓰는 Job에 같은 resource_group을 지정하고, 실제로 서로 기다려야 하는 Job이 모두 그 그룹을 사용하는지 확인합니다. 이후 process mode가 배포 순서에 맞는지 살펴보고, Runner와 Keychain까지 잠기는 것은 아니라는 점을 별도로 검증합니다. 테스트 파이프라인에서 동시 실행과 재시도도 확인해야 합니다.

resource_group 하나로 다른 프로젝트의 서명 작업도 잠글 수 있나요?

그렇게 간주하면 안 됩니다. resource_group은 같은 프로젝트 안에서 해당 그룹을 지정한 Job의 실행을 조정하는 용도이지, 여러 프로젝트가 공유하는 Mac 호스트 전체를 잠그는 장치가 아닙니다. 프로젝트 사이에서 서명 자원을 함께 써야 한다면 중앙 조정 수단이나 전용 Runner 같은 별도 경계를 설계하고, 실제 실행 기록으로 충돌 여부를 확인합니다.

Mac Runner의 동시 실행이 빌드 디렉터리 덮어쓰기로 이어지는 이유는 무엇인가요?

Runner의 동시 작업이 같은 builds_dir 또는 같은 체크아웃 경로를 사용하면 소스 파일, 캐시, 아카이브가 서로 영향을 줄 수 있습니다. Runner 설정의 동시 실행 수와 고유 작업 경로 구성을 확인하고, 동시에 실행하는 시험 Job에서 실제 경로와 산출물 위치를 기록합니다. resource_group 설정만으로 디렉터리 충돌이 해결되지는 않습니다.

공유 Mac에서 다른 작업의 서명 인증서를 읽지 못하는지 어떻게 확인하나요?

비밀값을 로그에 출력하지 말고, CI 서비스 계정과 Keychain 접근 제어 목록, 인증서와 개인 키의 접근 범위를 각각 점검합니다. 서로 다른 시험용 자격 증명을 사용해 접근 허용과 거부 결과를 확인하고, 감사 기록에는 작업 식별 정보와 접근 결과만 남깁니다. 명령이 성공했다는 사실만으로 작업 간 격리가 입증되지는 않습니다.

GitLab CI에서 여러 iOS 서명 작업이 충돌하면 어떻게 해야 할까요? 2026 문제 해결 가이드

여러 iOS 서명 작업이 겹칠 때는 먼저 같은 서명 자원을 쓰는 작업을 직렬화하고, Runner 동시 실행과 작업 디렉터리, 인증서 접근 경계를 따로 확인해야 합니다. 이 글은 고장 증상별 점검 순서와 선택 기준을 제시하고, 운영 환경에서 검증할 항목을 설명합니다.

먼저 공유 서명 자원에 걸리는 Job을 직렬화하고, 이어서 Mac Runner 동시 실행, 작업 디렉터리, Keychain 접근을 각각 확인하세요. GitLab CI의 resource_group은 지정된 Job의 실행을 조정할 뿐, Mac 전체나 서로 다른 프로젝트를 잠그지는 않으므로 프로젝트 간 충돌이나 신뢰 경계 문제에는 별도 조정과 격리가 필요합니다.

기업 iOS 릴리스 담당자라면 서명이나 아카이브 작업이 서로 덮어쓰지 않도록 확인할 수 있습니다.
플랫폼 엔지니어라면 같은 Mac Runner에서 실행되는 작업의 스케줄과 파일 경로를 점검할 수 있습니다.
IT 및 보안 담당자라면 공유 Mac의 서명 자격 증명 접근 범위와 운영 전 검증 조건을 살펴볼 수 있습니다.

증상과 로그의 구분

같은 Mac에서 서명, 아카이브, 배포가 함께 돌 때 기다림이 길어지거나, 산출물이 예상과 다르거나, 재실행 때만 문제가 사라진다면 우선 원인을 단정하지 마세요. 동시 실행 충돌은 가능한 원인 중 하나입니다. 잘못된 인증서나 프로파일, 빌드 오류, 오래된 산출물도 비슷한 증상을 만들 수 있습니다.

장애가 난 파이프라인과 Job, 사용된 Runner, 서명 단계의 로그를 한 흐름으로 모으세요. 시간 순서와 각 Job의 체크아웃 경로, 산출물 경로, 사용 자격 증명의 식별 정보를 비교하면 실행이 겹쳤는지와 실패가 발생한 지점을 분리하기 쉬워집니다. 비밀값과 개인 키는 기록하지 않습니다.

팀에서 확인한 실패 기록을 기준으로 조사해야 합니다. 실제 발생 빈도를 측정하지 않았다면 충돌률이나 복구 시간 같은 수치를 추정해 원인으로 제시하지 마세요.

실행 제어 방식의 선택

GitLab CI에서 여러 iOS 서명 작업이 충돌할 때는 GitLab의 작업 조정, Runner의 작업 공간 설정, 서명 자격 증명 경계를 각각 다뤄야 합니다. 아래 비교는 어느 한 설정이 다른 경계까지 대신한다고 가정하지 않도록 구성했습니다.

선택지	제어하는 범위	평가	확인할 내용
resource_group	같은 프로젝트에서 그룹을 공유하는 Job의 실행	같은 서명 자원을 쓰는 작업을 조정할 때 적합합니다	필요한 모든 Job이 그룹을 지정했는지, 처리 순서가 배포 정책에 맞는지 확인합니다
Runner 동시 실행 제한과 고유 경로	Runner가 받는 작업과 작업 디렉터리 구성	호스트 부하와 파일 경로 문제를 점검할 때 유효합니다	동시 작업이 같은 체크아웃·캐시·산출물 경로를 쓰지 않는지 검사합니다
전용 서명 노드 또는 별도 조정	설계에 따라 호스트나 프로젝트 사이의 경계	공유 자원이나 신뢰 경계를 분리해야 할 때 검토합니다	운영 환경의 인증서 접근과 프로젝트 간 조정 방식을 직접 시험합니다

GitLab 문서는 resource_group이 같은 그룹을 사용하는 Job의 동시 실행을 제어하며, 처리 순서는 process mode에 따라 달라질 수 있다고 설명합니다. 따라서 배포 결과의 순서가 중요하다면 resource_group 설정과 처리 방식을 확인하고, 설정만 적용한 뒤 끝내지 말고 실제 대기열에서 순서를 검증하세요. 이는 호스트 수준의 잠금이나 프로젝트 사이의 전역 잠금과는 다릅니다.

Runner와 작업 디렉터리 충돌

resource_group을 추가했는데도 파일이나 아카이브가 뒤섞인다면 Runner의 동시 실행과 경로를 확인하세요. resource_group이 없는 일반 빌드 Job, 다른 경로를 쓰는 Job, 별도 프로젝트의 작업은 같은 시점에 계속 실행될 수 있습니다.

GitLab Runner 설정에서 동시 실행 수, builds_dir, 체크아웃 경로를 살펴보세요. Runner의 작업 디렉터리와 동시 실행 설정은 작업별 고유 경로 구성을 설명합니다. 같은 Mac에서 두 작업을 시험 실행하고, 각 Job이 실제로 사용하는 체크아웃·캐시·아카이브 위치를 기록하면 설정이 의도대로 분리됐는지 확인할 수 있습니다. Runner의 고급 설정 문서도 실행 설정을 점검할 때 참고할 수 있습니다.

캐시와 Job artifacts도 구분해야 합니다. 캐시를 공유하는 것과 서명에 필요한 산출물을 Job 간에 전달하는 것은 다른 목적입니다. 산출물을 전달해야 한다면 Job artifacts의 보관과 전달 방식에 맞춰 대상 Job과 경로를 명확히 하세요. 기존 파일이 남아 새 결과처럼 보이는 상황도 함께 점검해야 합니다.

서명 권한과 Keychain 경계

작업 실패가 서명 단계에서 발생한다고 해서 곧바로 동시 실행 문제라고 볼 수는 없습니다. 인증서가 만료됐거나 프로비저닝 프로파일이 맞지 않는 경우, CI 서비스 계정에 Keychain 접근 권한이 없는 경우도 확인해야 합니다.

인증서, 개인 키, Keychain 잠금 및 해제 상태, CI 서비스 계정의 접근 범위를 각각 점검하세요. Apple은 Keychain 항목에 적용되는 접근 제어 목록을 설명하고 있습니다. 실제 권한은 사용하는 macOS 계정과 Keychain 설정에서 시험해야 하며, 성공한 서명 명령만으로 다른 작업의 자격 증명을 읽지 못한다고 증명할 수는 없습니다.

비밀값을 CI 로그에 남기지 않도록 구성하고, 접근 기록에는 작업 식별 정보와 허용 여부만 남기세요. GitLab의 CI/CD 변수 보안 안내와 파이프라인 보안 가이드를 함께 확인하면 변수 노출 경로와 파이프라인 신뢰 조건을 검토하는 데 도움이 됩니다. 서명 결과 자체는 Apple의 코드 서명 및 검증 문서를 참고해 실제 환경에서 확인하세요.

프로젝트 간 대기와 배포 순서

resource_group을 설정했는데 이전 릴리스가 새 릴리스 결과를 덮어쓴다면, 먼저 같은 프로젝트 안에서 필요한 Job이 같은 그룹을 사용하고 있는지 확인하세요. 이어서 process mode와 대기 중인 Job의 상태를 살펴보고, 오래된 파이프라인이 뒤늦게 배포되지 않는지 시험합니다.

여러 프로젝트가 하나의 서명 Mac을 공유하는 경우에는 한 프로젝트의 resource_group만으로 다른 프로젝트의 작업까지 조정된다고 가정하면 안 됩니다. GitLab은 리소스 그룹을 프로젝트 범위에서 다루므로, 프로젝트 간 조정 방식은 별도로 설계해야 합니다. 리소스 그룹 API 문서를 참고해 해당 프로젝트의 그룹 설정을 확인하고, 실제 파이프라인 기록으로 다른 프로젝트 작업과 겹치는지 검증하세요.

Runner도 프로젝트 범위에 따라 사용 대상이 달라집니다. Runner 범위 설정을 확인해 어떤 프로젝트가 해당 Runner를 사용할 수 있는지 살펴보세요. Runner 접근 범위와 서명 자격 증명 권한은 서로 다른 통제 항목입니다.

운영 전 재현과 합격 기준

이번 주에는 비운영 파이프라인에서 다음 순서로 경계를 확인하세요.

서명 Job에 공통 resource_group을 적용하고, 대기열이 실제로 직렬화되는지 기록합니다.
서명과 무관한 일반 빌드 Job을 함께 실행해 필요한 병렬 처리가 유지되는지 확인합니다.
같은 서명 작업을 실패 후 재시도하고, 이전 Job의 산출물이 새 결과로 오인되지 않는지 점검합니다.
서로 다른 프로젝트에서 시험 작업을 실행해 프로젝트 간 조정이 실제로 작동하는지 확인합니다.
시험용 인증서와 계정을 사용해 허용된 Job만 키에 접근하는지, 비밀값 없이 감사 기록으로 확인합니다.

합격 기준은 단순히 Job이 성공하는 것이 아닙니다. 산출물의 프로젝트와 파이프라인 소유자가 예상과 일치해야 하며, 배포 순서가 정책에 맞고, 재시도 뒤에도 잘못된 아카이브가 남지 않아야 합니다. 시험 결과가 실패한다면 먼저 Runner 동시 실행을 제한하거나 작업 경로를 분리하세요. 그래도 프로젝트 간 자원 충돌이나 자격 증명 경계가 남는다면 전용 서명 노드 또는 별도 조정 방식을 검토합니다.

자주 묻는 운영 질문

별도 FAQ 항목에서 설명한 것처럼 resource_group은 실제로 필요한 서명 Job에 빠짐없이 적용해야 하며, 다른 프로젝트와 호스트 자체를 잠그는 기능으로 취급해서는 안 됩니다. 작업 경로와 Keychain 접근은 각각 별도 시험으로 확인하고, 운영 승인 전에는 직렬 서명, 일반 병렬 빌드, 실패 재시도, 프로젝트 간 작업을 포함해 검증하세요.

전용 서명 노드 검토

공유 Mac을 계속 쓰는 방식은 비용과 운영 자원을 함께 쓸 수 있지만, 자원 조정이 누락되면 작업 간 대기와 경로 충돌이 생기고, 여러 프로젝트가 같은 서명 자격 증명에 접근하는지 관리하기도 어려워집니다. 반대로 전용 노드는 경계를 분명히 설계하는 데 도움이 될 수 있지만, 실제 격리는 계정·Keychain·Runner 설정으로 검증해야 하며, 고정된 장비가 필요하거나 지속적인 고부하 작업을 운영한다면 직접 구매가 더 적합할 수도 있습니다.

먼저 비운영 서명 작업으로 현재 환경의 한계를 재현하세요. 노드의 위치와 운영 조건을 검토할 때는 서울 노드 안내를 비교 자료로 살펴보고, 전체 선택지는 팀용 Mac CI 노드 구성 안내에서 확인할 수 있습니다. 별도 노드가 필요하다고 판단한 경우에는 필요한 기간과 운영 방식을 기준으로 VPSMAC의 원격 Mac 임대를 검토할 수 있습니다.