App Intents를 이미 사용하는 독립 개발자와 소규모 팀을 위한 배포 안내입니다. UI Testing Target 구성부터 Entity Query, 연속 인텐트, Spotlight, 코드 서명, 재시작 복구까지 원격 맥에서 반복 검증하는 기준을 설명합니다.
App Intents를 이미 사용하는 독립 개발자와 소규모 팀을 위한 배포 안내입니다. UI Testing Target 구성부터 Entity Query, 연속 인텐트, Spotlight, 코드 서명, 재시작 복구까지 원격 맥에서 반복 검증하는 기준을 설명합니다.
AppIntentsTesting 자동 테스트는 UI Testing Target에 넣고 실제 앱 프로세스를 통해 Intent, Entity, Query와 시스템 연동을 검증해야 합니다. 핵심 회귀 검사를 계속 돌려야 한다면 도구 버전과 서명 상태를 고정할 수 있고 무인 실행이 가능한 원격 맥을 전용 테스트 노드로 배치하는 편이 적합합니다.
이미 App Intents를 연결했고 Siri, Shortcuts 또는 Spotlight 기능의 조용한 회귀가 걱정되는 독립 개발자에게 맞는 글입니다. 제출마다 Intent와 Entity Query를 검사하려는 소규모 팀, 상시 Apple Silicon 맥이 없는 윈도우 및 리눅스 개발자도 대상입니다.
마지막 업데이트: 2026년 9월 1일. Xcode와 iOS 공개 시험판 정보는 애플의 공식 출시 기록에서 확인했습니다.
Shortcuts에서 수동 실행은 정상인데 Entity Query 하나가 바뀌어 사용자 신고로 처음 발견되는 경우가 있습니다. 이 문제는 일반 단위 테스트만으로 잡기 어렵습니다. 단위 테스트가 앱 내부의 순수 로직을 확인한다면, AppIntentsTesting은 실제 앱의 인텐트 경로와 시스템 연결을 검사하는 별도 층에 가깝습니다.
구분해야 할 실패는 다음과 같습니다.
따라서 XCUITest와도 역할이 다릅니다. XCUITest는 화면 동작을 중심으로 검사하고, AppIntentsTesting은 인텐트 호출과 Entity 반환, 시스템 통합 코드를 중심으로 검사합니다. Siri와 실제 Shortcuts 사용성은 여전히 사람이 확인해야 합니다.
AppIntentsTesting을 UI Testing Target에 넣는 이유는 무엇인가요?
애플의 공식 테스트 문서는 앱 인텐트 코드를 독립 테스트 프로세스에서 실행하고 실제 앱과 연결하는 구성을 설명합니다. UI Testing Target은 앱 Bundle Identifier, 테스트 대상, 서명 팀 사이의 관계를 관리할 수 있는 경로입니다. 일반 단위 테스트에 Mock 객체만 넣으면 시스템이 인텐트를 발견하는 과정이나 실제 매개변수 변환을 재현하기 어렵습니다. 자세한 구성은 애플의 App Intents 테스트 문서와 App Intents Testing 공식 문서를 함께 확인해야 합니다.
처음부터 모든 기능을 넣지 말고 외부 계정이나 네트워크에 의존하지 않는 Intent 하나로 통과 기준을 만듭니다. 이 기준에서 발견 실패, 매개변수 변환 실패, 실행 실패를 서로 다른 결과로 기록해야 이후 로그만 보고 원인을 좁힐 수 있습니다.
Bundle ID와 Team 값은 실제 공개 값으로 문서에 남기지 않는 편이 좋습니다. 본문이나 저장소에는 <앱 번들 식별자>, <서명 팀>, <테스트 경로> 같은 자리표시자를 사용하고, 실행 환경에서만 비밀 저장소의 값으로 치환합니다.
App Intents의 Entity는 화면에 보이는 이름만 검사해서는 부족합니다. 문자열로 검색했을 때 올바른 항목을 반환하는지, 식별자로 다시 조회할 수 있는지, 결과의 표시 이름과 필요한 필드가 일관적인지 확인해야 합니다. 이 검사가 빠지면 Shortcuts에서 선택 항목이 사라지거나 비슷한 이름의 다른 항목이 선택될 수 있습니다.
테스트 데이터는 개발자 개인 계정의 기존 자료를 사용하지 않아야 합니다. 실행 전 고정된 샘플 데이터를 만들고, 실행 뒤 같은 식별자로 정리합니다. 데이터 생성과 삭제가 멱등적이어야 재시도 뒤에도 결과가 달라지지 않습니다.
App Intent 사이의 매개변수 전달은 어떻게 검사하나요?
서로 연결되는 Intent를 준비합니다. 첫 번째 Intent가 반환한 Entity 또는 식별자를 두 번째 Intent의 입력으로 넘기고, 두 번째 작업이 같은 항목을 처리했는지 확인합니다. 여기서 이름 문자열만 비교하지 말고 안정적인 식별자와 최종 반환 필드를 함께 비교해야 합니다.
한 테스트가 이전 실행의 자료를 우연히 재사용하지 않도록 고유 접두사를 붙인 테스트 자료를 만들고 종료 시 정리합니다. 병렬 실행이 있다면 테스트별 저장 공간을 나누고, 공유 시뮬레이터 상태를 전제로 하지 않습니다.
Spotlight 검사는 Query 검사와 별개로 다뤄야 합니다. 알려진 Entity가 검색되지 않았을 때 다음 상태를 나누어 기록해야 합니다.
App Entity를 Spotlight에 노출하는 공식 방식은 애플의 App Entity 연동 문서에 설명되어 있습니다. 색인 자체의 동작 범위는 Core Spotlight 공식 문서도 함께 확인해야 합니다.
화면 주석 검사는 테스트 전용 Intent로 확실한 화면으로 이동한 뒤, 해당 화면이 올바른 Entity를 노출하는지 확인하는 방식으로 구성합니다. 단, 자동화가 통과했다고 해서 Siri의 음성 인식이나 실제 Spotlight 사용 경험까지 보장되는 것은 아닙니다. 시스템 경험을 함께 검증하는 애플의 세션처럼 최종 사용 흐름은 별도로 수동 점검해야 합니다.
테스트 전용 Intent는 공개 기능으로 만들지 않아야 합니다. 디버그 빌드에서만 발견되도록 제한하고, 데이터 초기화와 화면 이동, 테스트 후 정리를 이 경로에 모읍니다. 릴리스 빌드에서는 해당 진입점이 포함되지 않았는지 확인합니다.
각 테스트는 자체적으로 실행되어야 합니다. 이전 테스트가 남긴 Entity, 로그인 세션, 시뮬레이터 상태를 재사용하면 병렬 작업이나 재시작 뒤에 간헐적인 실패가 생깁니다. 테스트 결과에는 다음 정보를 함께 남기는 편이 좋습니다.
xcresult 위치와 콘솔 로그실제 계정 토큰, 개인 경로, 인증서 파일은 로그에서 제거합니다. 테스트 계정이 필요하다면 계정 정보 자체가 아니라 환경 변수 이름만 기록합니다.
AppIntentsTesting은 지속적 통합 환경에서 실행할 수 있나요?
공식 Beta 문서와 WWDC26 예시는 App Intents 테스트를 자동 실행 흐름에 연결하는 방법을 보여줍니다. 다만 현재 문서와 도구가 Beta 상태라면 장기적인 API 안정성을 전제로 삼아서는 안 됩니다. 2026년 8월 24일 기준 애플의 공개 기록에는 Xcode 27 Beta 6과 iOS 27 Beta 7이 표시되어 있으므로, 이 버전 정보는 공식 출시 기록으로 고정 확인해야 합니다.
원격 Mac에서는 다음 작업을 서로 분리합니다.
이렇게 나누면 실패 의미가 분명해집니다. 단위 테스트 실패는 앱 내부 로직 문제일 가능성이 높고, AppIntentsTesting 발견 실패는 Target 또는 서명 연결 문제일 수 있습니다. Spotlight 실패는 색인 상태와 Query 로직을 따로 확인해야 합니다.
원격 맥에 필요한 조건은 Xcode, SDK, 시뮬레이터 런타임, 앱 테스트 Target, 서명 팀, 로그인 세션이 재시작 뒤에도 복구되는지입니다. Xcode 27의 시스템 요구 사항은 애플의 Xcode 시스템 요구 사항에서 확인합니다. 코드 서명 정체성을 여러 실행 노드에 배치할 때는 팀 서명 인증서 동기화 안내를 기준으로 접근 권한과 보관 방식을 정해야 합니다.
원격 맥에서 코드 서명은 어떻게 처리하나요?
개발용 서명과 배포용 서명을 같은 작업에 섞지 않습니다. 테스트 노드에는 필요한 테스트 인증서와 프로비저닝 정보만 넣고, 배포 인증서는 별도 작업에서 제한적으로 사용합니다. 키체인 잠금 해제 상태를 로그에 출력하지 말고, 재시작 후 인증서가 실제로 선택되는지 작은 서명 검사를 먼저 실행합니다.
원격 데스크톱을 계속 지켜보는 방식도 피해야 합니다. 명령줄 실행 결과, xcresult, 콘솔 로그, 환경 정보를 자동 저장해야 네트워크 연결이 끊겨도 실패 원인을 확인할 수 있습니다. 원격 맥의 접근 방식과 연결 조건을 비교하려면 VNCMac의 원격 맥 이용 안내를 참고할 수 있습니다.
아래 점수는 외부 성능 측정값이 아니라, App Intents 유지 관리 관점에서 정리한 우리 판단입니다. 실제 선택에서는 프로젝트의 서명 방식과 Beta 도입 범위를 먼저 확인해야 합니다.
| 선택지 | Intent 통합 검증 | 상시 실행 | 환경 고정 | 초기 부담 | 우리 판단 |
|---|---|---|---|---|---|
| 개발자 로컬 맥 | 높음 | 낮음 | 중간 | 낮음 | 3점 |
| Xcode Cloud | 프로젝트 설정에 따라 다름 | 높음 | 서비스 정책 의존 | 중간 | 3점 |
| 자체 보유 맥 미니 | 높음 | 높음 | 높음 | 높음 | 4점 |
| 전용 원격 맥 | 높음 | 높음 | 구성에 따라 높음 | 중간 | 4점 |
Xcode Cloud는 관리 부담을 줄일 수 있지만, 테스트 노드의 상태와 접근 방식을 세밀하게 통제해야 하는 팀에는 제약이 될 수 있습니다. 자체 맥 미니는 물리 장비를 직접 관리해야 하고, 장기간 무거운 작업을 계속 맡길 때 비용 구조를 따로 계산해야 합니다.
전용 원격 맥은 로컬 장비를 구매하지 않고도 Xcode와 시뮬레이터를 유지할 수 있는 선택지입니다. VNCMac은 VNC, SSH 또는 웹 콘솔로 실제 호스팅 맥에 접근하는 방식이므로, 무인 테스트 노드의 접근 경로를 팀의 보안 정책에 맞춰 점검해야 합니다. 한국에서 접속하는 팀은 한국 원격 맥 이용 안내에서 연결 방식과 제공 조건을 확인한 뒤 판단하는 편이 안전합니다.
Beta 단계에서는 모든 Intent를 한 번에 자동화하지 않습니다. 다음 흐름을 핵심 회귀 묶음으로 먼저 고정합니다.
xcresult, 콘솔 로그, 환경 정보를 보관하고 실패 종류를 분류합니다.이 흐름을 통과한 뒤에도 Siri와 Shortcuts의 실제 사용자 검증은 남습니다. AppIntentsTesting은 시스템 통합 코드의 회귀를 줄이는 도구이지, 음성 인식과 자연어 표현, 사용자가 보는 선택 화면 전체를 대신하는 도구가 아닙니다.
프로젝트가 App Intents를 실험적으로만 사용한다면 로컬 실행으로 시작해도 됩니다. 매 제출마다 같은 검사를 해야 한다면 지속적 통합에 연결합니다. 인텐트가 앱의 핵심 탐색과 작업 흐름을 담당한다면, 재시작 복구까지 확인하는 상시 원격 맥 테스트 노드를 고려할 수 있습니다.
Xcode 27과 iOS 27은 2026년 9월 1일 현재 Beta 경계에 있으므로, 정식 버전이나 출시 후보가 나온 뒤 API, 도구 연결, 시스템 요구 사항, 테스트 결과를 다시 검증해야 합니다. Beta 동작을 장기 계약처럼 취급하지 말고, 기존 수동 검증과 되돌릴 수 있는 실행 경로를 남겨 두어야 합니다.
개발자 개인 맥에서만 실행하면 장비가 꺼졌을 때 회귀 검사가 멈춥니다. 팀원이 직접 로그인해야 하고, Xcode나 시뮬레이터 상태가 사람마다 달라지며, 서명 키와 테스트 데이터가 개인 환경에 남는 문제도 있습니다. 윈도우나 리눅스만 보유한 경우에는 애초에 macOS 전용 도구 체인을 상시 유지하기 어렵습니다.
반대로 원격 맥은 테스트 전용 환경을 분리하고, SSH나 VNC로 필요할 때 점검하며, 재시작 복구와 로그 보관을 기준으로 운영할 수 있습니다. 장기간 고정된 고부하 작업이나 물리 포트가 필요한 개발에는 직접 구매가 더 적합할 수 있지만, 제출마다 AppIntentsTesting을 실행할 임시 노드나 지속적 통합 환경이 필요한 경우에는 VNCMac의 맥 렌탈을 먼저 시험해 보는 편이 합리적입니다.
먼저 이 글의 최소 통과 항목을 실제 App Intents 테스트 집합에 적용하고, 원격 실행과 재시작 뒤에도 같은 결과와 xcresult가 남는지 확인하십시오. 상시 Apple Silicon 맥을 직접 보유하고 있지 않다면 그 검증 결과를 바탕으로 전용 원격 맥을 일정 기간 운영할지 결정하면 됩니다.