2026 팀 미국 애플 계정 1인 1계정인가 공유인가? 권한 방안

공유 계정으로 로그인할 때마다 누가 인증 코드를 받는지 몰라 배포가 멈추고, 퇴사자의 계정 흔적이 남는다면 권한 설계가 잘못된 상태입니다.

가장 빠른 해법은 구성원마다 자신의 Apple Account를 쓰게 하고, 개발·테스트·등록 권한은 App Store Connect 역할로 나누는 것입니다. 비밀번호와 이중 인증 코드는 공유하지 마십시오. 미국 지역 설정은 팀 권한을 늘려 주지 않습니다.

이 글을 읽어야 하는 관리자

팀의 Apple Account 운영 규칙을 정하는 기술 관리자에게 적합합니다. 외주 인력이나 단기 프로젝트 구성원의 접근 범위를 정해야 하는 프로젝트 책임자도 대상입니다. 여러 사람이 원격 맥을 함께 쓰면서 계정 잔류와 인수인계 문제를 걱정하는 운영 담당자에게도 필요한 내용입니다.

먼저 분리해야 할 세 가지 계정 층위

팀 계정 문제는 하나의 로그인 문제처럼 보이지만 실제로는 3개 층위가 섞여 있습니다.

• Apple Account 소유권: 이메일 주소, 비밀번호, 신뢰 기기와 이중 인증을 관리하는 개인 계정입니다. Apple은 계정 보안 안내에서 인증 정보와 보안 수단을 다른 사람과 공유하지 않도록 안내합니다. Apple의 계정 보안 요구사항을 기준으로 내부 규칙을 정하십시오.
• 개발자 로그인과 서명 자료: Xcode 로그인, 인증서, 프로비저닝 관련 작업입니다. 개발자 계정에 접근한다고 해서 App Store Connect의 모든 업무를 수행할 수 있는 것은 아닙니다. 개발자 계정 로그인 안내와 개발자 역할 권한표를 따로 확인해야 합니다.
• App Store Connect 팀 권한: 앱의 빌드, 메타데이터, 사용자, 재무 정보에 접근하는 업무 영역입니다. 계정과 역할 개요에 따라 앱 단위 접근 범위까지 구분해야 합니다.

따라서 “미국 애플 계정 하나를 만들고 모두가 사용한다”는 방식은 이 세 층위를 한곳에 몰아넣습니다. 인증 실패의 책임 소재가 흐려지고, 업무 종료 후 회수할 권한도 명확하지 않습니다.

개발자와 상주 구성원의 권한 설계

개발자는 자신의 Apple Account로 팀 초대를 받아야 합니다. Account Holder의 비밀번호를 전달받는 방식은 사용하지 않습니다. Apple의 역할 문서에서 현재 가능한 권한을 확인한 뒤, 실제 업무에 필요한 범위만 부여하십시오.

개발 업무는 다음처럼 나누면 관리가 쉽습니다.

• 코드와 빌드 담당자: Xcode 작업과 빌드 업로드에 필요한 접근을 부여합니다. 인증서나 서명 자료를 다루는 사람은 별도 승인 절차를 둡니다.
• 배포 담당자: 빌드 선택, 테스트 배포, 출시 준비에 필요한 App Store Connect 권한만 부여합니다.
• 메타데이터 담당자: 설명, 스크린샷, 지역별 정보 수정이 주 업무라면 재무나 사용자 관리 권한을 함께 열지 않습니다.
• 관리자: 팀 구성원과 앱 접근을 관리하지만, 법적 계약과 계정 책임이 필요한 Account Holder 역할과 동일하게 취급하지 않습니다.

App Store Connect 역할 권한 참고표와 앱 접근 수정 규칙을 승인 문서에 함께 저장하면, 오래된 화면 기억으로 권한을 판단하는 실수를 줄일 수 있습니다.

테스트 유형별 계정 분리

테스트 담당자는 테스트 목적에 따라 계정을 달리 써야 합니다.

• 일반 스토어 다운로드: 테스트 기기의 Media & Purchases 로그인은 업무용 계정과 분리합니다. 이 계정을 iCloud 전체 로그인에 사용하지 마십시오.
• TestFlight 테스트: 외부 테스터는 초대 방식으로 참여할 수 있습니다. 외부 테스터 초대 절차에 따라 테스터를 추가하고, 테스트 종료 후 초대 상태와 접근 범위를 정리합니다.
• 샌드박스 결제 테스트: 인앱 결제 검증에는 샌드박스용 테스트 계정을 사용합니다. 이 계정은 팀 구성원이 일상적으로 쓰는 생산용 Apple Account가 아닙니다. 샌드박스 테스트 개요와 StoreKit 결제 테스트 문서를 기준으로 테스트 계정을 관리하십시오.

하나의 미국 계정을 모든 테스트 기기에 무제한으로 넣으면 구매 기록, 알림, 인증 요청이 섞입니다. 특히 공유 맥에서는 다음 사용자가 이전 계정의 세션을 이어받을 수 있습니다.

외주와 단기 구성원의 회수 절차

외주 개발자가 앱을 올리기 위해 주 계정에 로그인해야 하는 것은 아닙니다. 외주 인력의 Apple Account를 초대하고 앱 접근과 역할을 제한하면 됩니다. 권한은 다음 순서로 운영하십시오.

1. 계약서에 맡은 앱, 작업 범위, 종료일을 적습니다.
2. 외주 구성원의 Apple Account를 팀에 초대합니다.
3. 필요한 앱만 선택하고 빌드, 테스트, 메타데이터 중 해당 업무만 허용합니다.
4. 첫 업로드 전 실제로 가능한 작업을 확인하고 불필요한 권한을 낮춥니다.
5. 작업 종료일에는 앱 접근을 제거한 뒤 팀 구성원에서 삭제합니다.
6. 원격 맥에서 Apple Account, App Store Connect, Xcode, 브라우저 세션과 키체인을 점검합니다.

원격 맥은 업무 환경을 제공할 뿐 계정 소유권을 바꾸지 않습니다. 기기를 빌려준다고 해서 외주 인력이 주 계정의 인증 수단을 받아야 하는 것도 아닙니다.

관리자용 결정 기준

아래 목록에서 하나라도 답하지 못하면 계정을 공유하지 않는 편이 낫습니다.

이 기준의 핵심은 계정 수가 아닙니다. 누구의 계정인지, 누가 인증할 수 있는지, 무엇을 할 수 있는지, 떠날 때 어떻게 닫는지를 기록하는 것입니다.

계정 인수인계 점검 목록

구성원 초대 전

• [ ] 개인 Apple Account의 소유자를 확인했습니다.
• [ ] 업무에 필요한 앱과 역할을 정했습니다.
• [ ] 이중 인증 코드를 전달하지 않는 규칙을 승인받았습니다.
• [ ] 외주 종료일과 권한 회수 담당자를 기록했습니다.

작업 중

• [ ] Xcode 로그인과 App Store Connect 권한을 따로 확인했습니다.
• [ ] 샌드박스 계정과 생산용 계정을 구분했습니다.
• [ ] 공유 맥의 브라우저와 키체인에 다른 구성원의 로그인 정보가 남아 있지 않은지 확인했습니다.
• [ ] 권한 변경 기록을 남겼습니다.

퇴사 또는 프로젝트 종료 시

• [ ] 앱 접근 권한을 먼저 제거했습니다.
• [ ] 팀 역할과 개발자 접근을 함께 회수했습니다.
• [ ] 원격 맥에서 Media & Purchases와 iCloud 로그인을 정리했습니다.
• [ ] Xcode, 브라우저 세션, 키체인 항목을 확인했습니다.
• [ ] Account Holder 변경이 필요하다면 공식 역할 이전 절차를 따랐습니다.

공용 비밀번호 방식은 처음에는 빠르게 보이지만, 배포 실패 원인을 찾을 때 담당자를 특정하기 어렵습니다. 퇴사자가 인증 기기를 계속 보유하거나, 외주 작업자의 세션이 공유 맥에 남는 문제도 생깁니다. 현재 방식이 공용 계정과 수동 로그아웃에 의존한다면, 개인 계정과 역할 권한으로 바꾸는 것이 장기적으로 관리 비용이 낮습니다.

다만 팀원이 잠깐 사용할 격리된 개발 환경이 필요하다면 계정 정책만 바꾸는 것으로 끝나지 않습니다. vmzig의 원격 맥 환경을 활용하면 구성원별 작업 공간을 분리하고, 프로젝트 종료 뒤 계정과 세션을 정리하는 절차를 별도로 운영할 수 있습니다. 장기 고정 부하나 물리 기기 연결이 필요한 팀에는 자체 장비가 더 적합하지만, 단기 개발·테스트·외주 검수처럼 환경을 빠르게 배정하고 회수해야 하는 경우에는 원격 맥 대여가 공용 맥보다 계정 잔류 위험을 줄이는 방향으로 설계하기 쉽습니다.