기업 CI의 생산 배포에는 작업별로 나눈 최소 권한 Team API Key를 우선 적용해야 합니다. Individual API Key는 특정 사용자 권한에 묶인 제한적 자동화에만 사용하고, 서명 자산과 공증 작업은 별도의 신뢰할 수 있는 배포 환경에서 관리해야 합니다.
기업 CI의 생산 배포에는 작업별로 나눈 최소 권한 Team API Key를 우선 적용해야 합니다. Individual API Key는 특정 사용자 권한에 묶인 제한적 자동화에만 사용하고, 서명 자산과 공증 작업은 별도의 신뢰할 수 있는 배포 환경에서 관리해야 합니다.
생산 CI에는 작업별 최소 권한을 부여한 Team API Key를 기본으로 사용해야 합니다. Individual API Key는 특정 사용자 권한에 묶인 제한적 자동화에만 남기고, 배포와 서명 자산은 격리된 신뢰 배포 맥 노드에서 처리하는 방식이 안전합니다.
이 글은 애플 계정, 이중 인증 또는 직원 개인 자격 증명에 의존하는 연구개발 효율 책임자를 위한 내용입니다. 여러 앱의 배포 파이프라인에 최소 권한, 폐기, 감사 기준을 세우려는 기업 IT·보안 책임자와 fastlane, TestFlight, 공증 작업을 원격 맥으로 옮기려는 기술 책임자도 대상입니다.
App Store Connect API Key 기업 CI의 선택은 “어느 키가 더 편한가”가 아니라 “어떤 API를 호출하는가”에서 시작해야 합니다. 저희는 다음 조건으로 1차 결론을 나누는 방식을 권장합니다.
notarytool을 사용하는 공증 작업이라면 Individual API Key를 기본 전제로 삼지 않습니다. 개인 키에는 일부 기능 제한이 있으므로, 현재 API와 도구의 공식 지원 범위를 배포 전에 다시 확인해야 합니다. Apple의 API 키 생성 및 사용 범위와 fastlane의 API 인증 문서를 함께 확인해야 합니다.따라서 메타데이터, TestFlight, 서명, 공증을 하나의 키와 하나의 공유 맥에서 처리하는 구조는 처음부터 재검토해야 합니다.
Team API Key는 팀 역할을 기준으로 권한을 받으며 팀의 여러 앱에 적용될 수 있습니다. 역할을 낮춘다고 해서 자동으로 단일 앱 격리가 만들어지는 것은 아닙니다. 반대로 Individual API Key는 연결된 사용자의 앱 접근 권한과 역할을 상속하지만, 일부 API 기능을 사용할 수 없습니다. 앱 접근 권한과 팀 역할은 Apple의 앱 접근 제어 안내와 Apple의 역할 설명에서 현재 기준을 확인해야 합니다.
실무에서는 아래와 같이 승인 조건을 정합니다.
notarytool의 인증 방식과 키 제한을 따로 검토합니다. App Store Connect용 키를 공증용 만능 자격 증명처럼 재사용하지 않습니다.주의: CI 변수 이름을 앱별로 나누거나 키 파일 이름에 앱 이름을 붙이는 것은 운영상 구분일 뿐입니다. 서버가 Team API Key의 앱 범위를 제한하지 않는다면, 유출 시 영향 범위도 줄어들지 않습니다.
단일 앱 팀은 전용 Team API Key 하나로 시작할 수 있지만, 제품군이 늘어나면 같은 키를 계속 공유하는 방식의 위험이 커집니다. 여러 앱을 운영하는 기업에서는 기능보다 앱 격리의 강도를 기준으로 배포 구조를 다시 나눠야 합니다.
이 구조에서 원격 맥은 단순한 접속 장비가 아니라 배포 경계의 일부가 됩니다. 저희의 한국 원격 맥 환경을 검토하더라도, 먼저 CI가 어떤 브랜치에서 어떤 비밀 키를 읽을 수 있는지부터 설계해야 합니다.
개인 키는 사용자의 앱 접근과 역할에 따라 동작하므로, 책임 주체가 명확한 제한적 자동화에는 유용할 수 있습니다. 그러나 생산 기반 시설의 장기 자격 증명을 직원 계정에 의존하면 인사 변동과 권한 변경이 장애 요인이 됩니다.
직원 이동이나 퇴사 때에는 계정 비활성화만으로 충분하다고 가정하면 안 됩니다. 개인 키가 즉시 사라지는지 여부를 운영 추정으로 처리하지 말고, 계정 접근 차단, 키 폐기, CI 비밀 삭제, 실패 로그 확인을 하나의 퇴사 절차로 묶어야 합니다. Apple은 API 키를 별도로 폐기하는 절차를 제공하므로 공식 폐기 문서를 기준으로 검증해야 합니다.
키 자산 장부에는 최소한 다음 항목을 기록합니다.
키를 만든 사람의 이름만 적는 것은 부족합니다. 업무 소유자와 기술적 비밀 소유자를 분리해야 직원이 바뀌어도 파이프라인을 인수할 수 있습니다.
App Store Connect API Key의 개인 키 파일인 p8은 생성 뒤 다시 내려받을 수 없으므로 Apple의 생성 안내에 따라 생성 직후 안전한 비밀 저장소로 옮겨야 합니다. 저장소에 보관했다는 사실보다, 빌드 작업이 끝난 뒤 어디에 남는지가 더 중요합니다.
fastlane을 사용하는 경우에는 공식 app_store_connect_api_key 동작이 지원하는 인증 입력과 현재 도구 버전을 확인합니다. fastlane 인증 동작 문서를 기준으로 다음 경계를 지킵니다.
프로비저닝 프로파일은 서명 결과물과 함께 관리되지만 API 키와 동일하지 않습니다. 프로파일 갱신과 기기 등록 조건은 Apple의 프로비저닝 프로파일 안내에서 별도로 확인해야 합니다.
아래 점검표를 실제 파이프라인별로 작성하면 Team API Key와 Individual API Key를 빠르게 구분할 수 있습니다. 해당 항목에 체크한 뒤, 오른쪽 결론을 적용합니다.
생산 배포가 필요하고 직원 계정과 무관하게 실행되어야 합니다.
→ 작업별 Team API Key를 선택합니다.
여러 앱 또는 여러 제품팀이 같은 CI 조직에 속해 있습니다.
→ 앱과 작업을 나눈 Team API Key를 선택합니다.
자동화가 특정 사용자의 제한된 앱 접근 안에서만 실행됩니다.
→ Individual API Key를 제한적 보조 자동화로 검토합니다.
Provisioning 관련 API를 호출합니다.
→ Individual API Key를 기본값으로 사용하지 말고 공식 지원 범위를 확인합니다. 지원되지 않으면 전용 Team API Key 또는 별도 서명 흐름으로 되돌립니다.
notarytool 공증이 포함됩니다.
→ App Store Connect용 개인 키를 재사용하지 말고 공증용 인증 경계를 따로 설계합니다.
여러 고객사의 앱을 하나의 파이프라인에서 처리합니다.
→ 고객별 팀 경계와 배포 노드를 분리합니다. 하나의 Team API Key로 묶지 않습니다.
퇴사나 권한 변경 때 키 폐기와 대체 키 전환을 증명할 수 없습니다.
→ Individual API Key를 생산 기반 시설에서 제외합니다.
p8 파일이 공유 작업 공간에 오래 남아 있습니다.
→ 파이프라인 승인을 보류하고 임시 주입과 작업 후 삭제를 먼저 구현합니다.
비신뢰 브랜치와 신뢰 배포 브랜치가 같은 맥 노드에서 실행됩니다.
→ 배포 Secret을 제공하지 말고 일반 빌드 노드와 신뢰 배포 노드를 분리합니다.
다음 네 가지 조건을 모두 충족할 때만 Individual API Key를 생산 외 자동화에 제한적으로 사용할 수 있습니다.
첫 번째 묶음의 항목이 생산 환경에 하나라도 해당하면, 개인 키를 장기 기반 시설 자격 증명으로 사용하지 않는 것이 원칙입니다. 두 번째 묶음 중 하나라도 빠지면 Individual API Key 대신 작업 전용 Team API Key와 별도 승인 흐름을 선택해야 합니다.
저희가 기업 CI를 평가할 때는 기능 지원만 보지 않습니다. Team API Key는 팀 단위 자동화와 직원 독립성에서 유리하지만, 앱 단위 격리는 별도 설계가 필요합니다. Individual API Key는 사용자 권한에 맞춘 범위 축소가 가능하지만, 기능 제한과 인사 이벤트 의존성이 있습니다.
최종 승인 전에는 다음 증거를 남겨야 합니다.
기존 구조가 직원 개인 키를 사용하거나 공유 빌드 맥에 p8 파일을 오래 남긴다면, 현재 방식은 계정 변경에 취약하고 유출 범위가 넓으며 감사 증거도 부족합니다. 일반 빌드와 신뢰 배포를 한 노드에서 처리하면 비신뢰 브랜치가 생산 비밀에 접근할 가능성도 커집니다. 이런 경우에는 전용 원격 맥 노드, 통제된 Secret 주입, 작업 후 정리, 교체 시 복구 증거를 갖춘 임대 환경이 직접 장비를 공유하는 방식보다 관리 경계를 명확히 만들 수 있습니다. 필요하다면 VNCMac의 원격 맥 서비스를 검토하되, 장기 고정 부하나 물리 장비 접근이 필요한 조직에는 직접 구매가 더 적합할 수 있습니다.
생산 CI의 기본값은 작업별 최소 권한 Team API Key입니다. Individual API Key는 제한된 사용자 자동화로 범위를 좁히고, 서명 자산과 공증은 별도의 신뢰 배포 체계로 분리해야 합니다. 이 기준으로 현재 파이프라인의 키 장부, Secret 접근 정책, 폐기 연습, 원격 맥 작업 공간 정리 기록을 차례로 검증하면 됩니다.