App Intents란 무엇인가: Apple Intelligence 시대에 iOS 앱이 호출되는 방식

App Intents란 무엇인가: Apple Intelligence 시대에 iOS 앱이 호출되는 방식

앱은 더 이상 “열리는 것”만으로 충분하지 않다

iOS 앱을 설계한다는 말은 오랫동안 화면을 설계한다는 뜻에 가까웠다. 사용자는 홈 화면에서 앱 아이콘을 누르고, 앱은 첫 화면을 보여주며, 제품팀은 그 안에서 탐색 구조와 전환율을 최적화했다. 검색, 추천, 알림, 위젯, 딥링크가 이 흐름을 조금씩 바꾸기는 했지만, 여전히 중심은 “사용자가 앱을 연 뒤 무엇을 하는가”였다.

Apple Intelligence와 App Intents가 확산되면 이 전제는 점차 약해질 수 있다. 일부 작업에서는 사용자가 앱을 직접 열지 않고도 기능을 실행하거나 결과를 확인할 수 있다. Siri에 자연어로 요청하거나, Spotlight에서 맥락에 맞는 작업을 찾거나, Shortcuts에서 여러 앱의 작업을 묶거나, 시스템이 추천하는 액션을 탭해 앱 기능을 실행할 수 있다. 이때 중요한 것은 앱의 전체 화면이 아니라 앱 안의 특정 기능과 콘텐츠가 시스템이 이해할 수 있는 형태로 표현되어 있는가다. Apple이 App Intents를 “앱의 기능을 시스템에 표현하는” 프레임워크로 설명하는 이유가 여기에 있다. 출처: App Intents | Apple Developer Documentation, App intents | Apple Developer Documentation

App Intents를 단순히 “Siri 명령어 붙이는 기능”으로 이해하면 핵심을 놓친다. 더 정확히 말하면 App Intents는 앱 내부의 기능, 데이터, 객체, 작업 흐름을 iOS 시스템 경험에 연결하는 인터페이스다. Siri, Shortcuts, Spotlight, 위젯, Action button, Apple Intelligence 같은 시스템 표면이 앱을 호출하려면 “이 앱은 어떤 일을 할 수 있는지”, “그 일을 실행하려면 어떤 입력이 필요한지”, “결과는 무엇인지”, “사용자 확인이 필요한지”를 알아야 한다. App Intents는 이 정보를 앱 바깥으로 드러내는 표준화된 연결 계층이다. 출처: App Shortcuts | Apple Developer Documentation, Integrating actions with Siri and Apple Intelligence | Apple Developer Documentation

따라서 이 글의 핵심 질문은 “App Intents를 어떻게 코딩하는가”가 아니다. 더 중요한 질문은 이것이다. Apple Intelligence 시대에 우리 앱의 어떤 기능을 시스템이 호출할 수 있게 만들 것인가. 어떤 콘텐츠를 Siri와 Spotlight가 이해할 수 있게 할 것인가. 어떤 작업은 자동 실행해도 되고, 어떤 작업은 반드시 확인을 받아야 하는가. 그리고 앱의 경쟁력은 더 이상 앱스토어 검색 순위와 첫 화면 UX만으로 설명될 수 있는가.

App Intents의 본질: 앱 기능을 시스템 언어로 번역하는 계층

App Intents는 앱 안의 특정 기능을 하나의 “의도” 또는 “작업”으로 정의한다. Apple 문서의 표현을 빌리면, App Intent는 앱 코드와 시스템 경험 및 서비스 사이의 브리지 역할을 하는 자기완결적 타입이며, 하나의 액션을 캡슐화한다. 즉 사용자가 “오늘 할 일 추가해줘”, “지난주 운동 기록 보여줘”, “이 사진을 업무 채널에 공유해줘”라고 요청했을 때, 시스템이 앱 내부 기능을 호출할 수 있도록 만드는 단위다. 출처: Creating your first app intent | Apple Developer Documentation

제품 관점에서 보면 App Intents는 앱을 다음 세 가지 요소로 다시 분해하게 만든다.

요소 기존 앱 설계 관점 App Intents 관점
기능 화면 안의 버튼, 메뉴, 플로우 시스템이 호출 가능한 작업 단위
콘텐츠 앱 내부 DB와 화면 목록 Siri, Shortcuts 등이 이해할 수 있는 App Entity
사용자 입력 폼, 필터, 탭, 검색창 자연어 요청, 파라미터, 선택지
실행 맥락 앱 실행 후 사용자 조작 Spotlight, Siri, Shortcuts, Apple Intelligence
안전장치 화면 내 확인 버튼과 약관 intent 단계의 확인, 권한, 고위험 액션 분리

이 변화의 의미는 작지 않다. 앱의 기능은 더 이상 앱 내부 네비게이션 구조에만 갇혀 있지 않다. “항공권 검색”, “장바구니에 추가”, “회의록 요약”, “구독 일시정지”, “최근 주문 배송 조회”처럼 명확한 작업 단위로 정의될 수 있다면, 시스템은 사용자의 요청과 앱 기능을 연결할 여지가 생긴다. App Intents가 앱의 capabilities를 시스템에 표현한다고 설명되는 이유다. 출처: App intents | Apple Developer Documentation

여기서 중요한 것은 “앱을 얼마나 많이 노출할 것인가”가 아니라 “어떤 작업을 노출할 가치가 있는가”다. 모든 버튼을 App Intent로 만들 필요는 없다. 오히려 그렇게 하면 제품의 작업 모델이 흐려진다. 좋은 App Intent 후보는 사용자가 자연어로 요청할 만큼 의미가 분명하고, 실행 결과가 명확하며, 앱을 열지 않고도 일부 또는 전체 처리가 가능한 작업이다. 예를 들어 “메모 앱 열기”보다 “회의 메모 새로 만들기”가 낫고, “쇼핑 앱 열기”보다 “지난 주문 배송 상태 확인”이 낫다.

Apple Intelligence가 바꾸는 호출 구조

Apple Intelligence는 단순히 더 똑똑한 자동완성 기능이 아니다. Apple은 개발자가 Apple Intelligence의 기반이 되는 온디바이스 foundation model에 접근해 앱 안의 지능형 경험을 만들 수 있다고 설명한다. 동시에 Apple은 Siri와 Apple Intelligence가 사용자의 맥락, 자연어 요청, 앱의 기능 노출 구조를 바탕으로 더 많은 작업을 시스템 경험 안에서 처리할 수 있도록 확장하는 방향을 제시하고 있다. 출처: Apple Intelligence – Apple Developer, Integrating actions with Siri and Apple Intelligence | Apple Developer Documentation

여기서 App Intents는 Apple Intelligence와 Siri가 앱의 기능을 이해하고 호출할 수 있게 만드는 중요한 연결점이 될 수 있다. AI가 사용자의 말을 이해하더라도, 앱이 어떤 기능을 제공하는지 시스템이 모르면 실행할 수 없다. 반대로 앱이 기능을 명확한 intent로 노출하면, 시스템은 사용자의 요청을 해당 작업과 연결할 수 있다. 이는 AI 에이전트 시대의 공통 구조와 닮아 있다. 자연어 인터페이스가 앞단에 있고, 뒤에는 호출 가능한 도구와 액션 목록이 있으며, 각 액션은 입력, 출력, 권한, 확인 절차를 가진다.

다만 Apple의 접근은 일반적인 외부 AI 에이전트 플랫폼과 다르다. Apple Intelligence는 iPhone, iPad, Mac, Apple Watch 같은 기기 경험 안에서 작동한다. Apple Intelligence는 Apple 기기와 OS 경험 안에서 작동하기 때문에, 앱, 알림, 캘린더, 사진, 파일, 위치, 기기 상태 등 다양한 사용자 맥락과 결합될 여지가 있다. 그래서 App Intents의 전략적 의미는 단순한 API 공개가 아니라 “iOS 시스템이 앱 기능을 이해하고 추천하고 실행할 수 있는 표준 표면에 들어가는 것”에 가깝다.

이때 앱 사업자가 봐야 할 질문은 세 가지다.

  • 우리 앱에서 사용자가 반복적으로 수행하는 핵심 작업은 무엇인가.
  • 그 작업은 자연어 요청으로 표현될 수 있는가.
  • 그 작업을 앱 전체 화면이 아니라 기능 단위로 실행해도 제품 가치가 유지되는가.

예를 들어 금융 앱이라면 “앱 열기”보다 “이번 달 카드 사용액 확인”, “정기이체 예정 내역 보기”, “해외결제 차단 설정”이 더 중요할 수 있다. 여행 앱이라면 “예약 앱 열기”보다 “다음 항공편 체크인 상태 확인”, “호텔 예약 주소 공유”, “공항까지 이동 시간 확인”이 더 실용적이다. 생산성 앱이라면 “프로젝트 화면 열기”보다 “오늘 마감 태스크 보여줘”, “회의록에서 액션 아이템 추출”, “새 작업을 특정 프로젝트에 추가”가 호출 단위가 된다.

Siri, Shortcuts, Spotlight, Action button은 같은 문제를 다른 표면에서 푼다

App Intents를 이해할 때 자주 생기는 오해는 “이건 Siri 기능인가?”라는 질문이다. Siri와 깊게 연결되는 것은 맞지만, App Intents의 범위는 Siri에 그치지 않는다. Apple 문서는 App Shortcuts가 앱의 intents와 entities를 Shortcuts 앱, Siri, Spotlight, 지원되는 iPhone 및 Apple Watch 모델의 Action button과 통합한다고 설명한다. 출처: App Shortcuts | Apple Developer Documentation

이 네 가지 표면은 사용 맥락이 다르다.

시스템 표면 사용 맥락 제품 전략상 의미
Siri 음성·자연어 요청 손이 바쁘거나 화면 전환이 번거로운 순간의 작업 실행
Shortcuts 자동화·멀티앱 워크플로우 파워유저, 업무 자동화, 반복 작업 연결
Spotlight 검색·발견 앱 실행 전 단계에서 기능과 콘텐츠 발견
Action button 물리 버튼 기반 즉시 실행 특정 고빈도 액션의 빠른 호출
Apple Intelligence 맥락 이해·자연어 중개 사용자 요청을 앱 기능과 연결하는 AI 계층

Siri는 사용자의 문장을 받아 앱 작업을 실행하는 입구다. Shortcuts는 여러 앱의 App Intent를 조합해 자동화 흐름을 만드는 공간이다. Spotlight는 앱 이름이 아니라 앱의 콘텐츠나 기능이 검색 결과로 떠오를 수 있는 발견 표면이다. Action button은 고빈도 작업을 물리적 인터랙션으로 끌어올린다. Apple Intelligence는 이 표면들을 더 자연어 중심, 맥락 중심으로 엮을 가능성이 크다.

이 관점에서 App Intents는 “음성 명령 지원”이 아니라 “시스템 전체에서 호출 가능한 기능 계약”이다. 앱이 어떤 일을 할 수 있는지 명확히 말해주지 않으면, Siri도, Spotlight도, Shortcuts도, Apple Intelligence도 그 기능을 안정적으로 다루기 어렵다. 반대로 잘 정의된 intent는 여러 표면에서 재사용될 수 있다. 하나의 “운동 기록 추가” intent가 Siri 요청, Shortcuts 자동화, Spotlight 제안, Action button 실행 후보가 될 수 있는 식이다.

App Entities: 앱 안의 객체가 발견 가능한 단위가 된다

App Intents에서 액션만큼 중요한 개념이 App Entity다. Apple 문서는 AppEntity를 앱 고유의 커스텀 타입이나 개념을 Siri와 Shortcuts 같은 시스템 경험에 노출하기 위한 인터페이스로 설명한다. 쉽게 말해 App Entity는 앱 내부의 “무언가”를 시스템이 이해 가능한 객체로 표현하는 방식이다. 출처: AppEntity | Apple Developer Documentation

예를 들어 할 일 앱에는 프로젝트, 태스크, 태그가 있다. 음악 앱에는 플레이리스트, 앨범, 아티스트가 있다. 커머스 앱에는 상품, 주문, 배송, 쿠폰이 있다. 호텔 앱에는 예약, 객실, 투숙객, 결제수단이 있다. 이런 객체가 앱 내부 DB에만 머물면 시스템은 알 수 없다. 하지만 App Entity로 표현되면 “내 출장 프로젝트의 오늘 할 일”, “최근 주문한 노트북 배송”, “가족 여행 예약”처럼 사용자의 자연어 요청과 연결될 가능성이 생긴다.

이것은 앱 발견성의 단위를 바꾼다. 과거에는 앱이 발견됐다. 앱스토어에서 앱 이름이나 카테고리를 검색하고, 설치하고, 실행했다. 이후에는 콘텐츠가 발견됐다. Spotlight가 메일, 메시지, 파일, 사진 같은 항목을 검색 결과로 보여줬다. Apple Intelligence와 App Intents가 충분히 채택된다면, 작업과 객체의 조합이 발견성의 단위가 될 수 있다. “A 앱의 B 기능”이 아니라 “내가 지금 하려는 일에 필요한 앱의 특정 객체와 액션”이 호출될 수 있다.

제품팀은 여기서 중요한 설계 결정을 해야 한다. 어떤 객체를 App Entity로 볼 것인가. 어떤 필드를 시스템에 설명할 것인가. 사용자가 자연어로 부를 수 있는 이름과 동의어는 무엇인가. 검색 가능한 속성과 개인정보 보호가 필요한 속성은 어떻게 구분할 것인가. “예약” 하나를 노출하더라도 예약 번호, 장소, 날짜, 참석자, 결제 상태, 취소 가능 여부는 민감도와 사용성이 다르다.

App Entity 설계가 부실하면 intent도 약해진다. “주문 조회”라는 액션이 있어도 시스템이 어떤 주문을 말하는지 식별하지 못하면 매번 앱을 열어 사용자가 직접 선택해야 한다. 반대로 주문, 배송지, 상품, 날짜 같은 엔티티 모델이 잘 잡혀 있으면 “지난주에 산 충전기 배송 어디쯤이야?” 같은 요청을 처리할 여지가 생긴다.

앱 기능의 작업 단위 설계: 화면이 아니라 동사로 쪼개라

App Intents 전략의 출발점은 “우리 앱의 화면 목록”이 아니다. “사용자가 달성하려는 작업 목록”이다. 화면은 내부 구현과 UX 구조의 결과물이다. intent는 사용자 목적을 실행 가능한 동사로 표현한 것이다. 좋은 작업 단위는 보통 다음 조건을 만족한다.

  • 사용자가 자연어로 말할 수 있다.
  • 실행 전 필요한 입력이 명확하다.
  • 실행 후 결과가 분명하다.
  • 앱을 열지 않아도 의미 있는 가치가 있다.
  • 권한과 확인 절차를 제품적으로 정의할 수 있다.

작업 단위를 나눌 때는 CRUD라는 개발자식 분류만으로는 부족하다. 실무적으로는 다음처럼 사용자 목적 중심으로 분류하는 편이 낫다.

작업 유형 예시 노출 가치 주의점
조회 잔액 확인, 배송 조회, 일정 확인 앱을 열지 않아도 즉시 가치 제공 개인정보 노출 범위
검색 상품 검색, 문서 찾기, 장소 찾기 Spotlight·Siri와 궁합 좋음 결과 랭킹과 모호성 처리
생성 메모 작성, 태스크 추가, 예약 초안 생성 자연어 입력을 구조화 가능 중복 생성·오입력 방지
수정 일정 변경, 알림 시간 변경 고빈도 업무 자동화 변경 전후 확인 필요
공유 파일 전송, 링크 공유 멀티앱 워크플로우에 적합 수신자·권한 확인
예약·결제 택시 호출, 상품 구매, 좌석 예약 높은 사업 가치 강한 확인·취소 UX 필요
삭제·취소 구독 해지, 예약 취소, 파일 삭제 사용자 요청은 명확할 수 있음 복구 가능성·재확인 필수

여기서 제품팀이 저지르기 쉬운 실수는 “가장 중요한 비즈니스 액션”부터 노출하려는 것이다. 결제, 예약, 구매, 취소 같은 액션은 비즈니스 임팩트가 크지만 위험도도 크다. 초기 App Intents 전략에서는 읽기 작업, 검색 작업, 초안 생성, 앱 내부 특정 화면으로 이어지는 저위험 작업부터 시작하는 것이 현실적이다. 사용자가 신뢰를 쌓고, 시스템 호출의 모호성을 줄이며, 확인 UX를 충분히 검증한 뒤 고위험 액션을 넓히는 편이 낫다.

예를 들어 배달 앱이라면 “가장 최근 주문 다시 주문”은 매력적인 intent지만, 주소, 결제수단, 품절, 가격 변동, 배달 가능 시간 같은 변수가 많다. 반면 “최근 주문 내역 보여줘”, “즐겨찾는 가게 검색”, “장바구니 열기”는 안전하고 유용하다. 금융 앱도 “송금 실행”보다 “송금 초안 만들기”나 “최근 이체 내역 확인”이 먼저다. 의료 앱도 “진료 예약 취소”보다 “예약 시간 확인”과 “병원 위치 안내”가 더 낮은 위험으로 시작할 수 있다.

자연어 요청은 UI가 아니다: 모호성, 확인, 실패 흐름을 설계해야 한다

Apple Intelligence와 Siri가 자연어를 이해한다고 해서 제품 설계가 쉬워지는 것은 아니다. 오히려 화면 UI보다 더 까다로운 문제가 생긴다. 사용자의 말은 불완전하고, 모호하고, 맥락 의존적이다. “내일 회의 준비해줘”라는 요청은 캘린더 확인, 관련 문서 검색, 참석자 파악, 이전 회의록 요약, 리마인더 생성 등 여러 작업으로 해석될 수 있다. 앱이 노출한 intent가 명확하지 않으면 시스템은 안전하게 실행하기 어렵다.

따라서 App Intents 설계에서는 성공 흐름보다 실패 흐름이 중요하다.

  • 입력이 부족하면 무엇을 되물을 것인가.
  • 후보가 여러 개면 어떤 선택지를 보여줄 것인가.
  • 사용자가 말한 객체를 찾지 못하면 어떻게 복구할 것인가.
  • 실행이 실패하면 앱을 열게 할 것인가, 대체 작업을 제안할 것인가.
  • 결과를 어느 정도까지 시스템 표면에서 보여줄 것인가.

예를 들어 “팀 회의 메모 공유해줘”라는 요청에서 “팀 회의”가 여러 개라면 바로 공유하면 안 된다. 어떤 회의인지 선택하게 해야 한다. “지난 주문 취소해줘”라는 요청도 마찬가지다. 최근 주문이 하나뿐이더라도 취소 수수료, 배송 상태, 환불 조건이 얽혀 있다면 확인 단계가 필요하다. App Intents는 시스템이 앱 기능을 실행하게 만드는 기술이지만, 제품적으로는 자연어 기반 UX의 모호성과 책임을 다루는 설계 문제다.

이 지점에서 IntentDialog 같은 요소도 중요해진다. Apple의 Siri 및 Apple Intelligence 통합 문서는 App Intents가 단순 실행뿐 아니라 사용자와의 상호작용, 파라미터 입력, 확인 흐름과도 연결될 수 있음을 보여준다. 구현 세부 코드를 이 글에서 다루지는 않지만, 제품팀은 “AI가 사용자에게 어떤 말로 되물을 것인가”, “결과를 어떤 문장으로 설명할 것인가”를 화면 문구만큼 신중하게 봐야 한다. 출처: Integrating actions with Siri and Apple Intelligence | Apple Developer Documentation

권한과 안전: 읽기, 쓰기, 고위험 액션을 분리하라

AI가 앱 기능을 호출하는 시대의 핵심 리스크는 “너무 많은 일을 너무 쉽게 실행하는 것”이다. 사용자는 편리함을 원하지만, 결제·예약·삭제·공유·외부 전송 같은 작업은 실수 비용이 크다. 그래서 App Intents 전략에는 권한과 확인 UX가 처음부터 포함되어야 한다.

제품 관점에서는 액션을 최소 네 단계로 분류하는 것이 좋다.

위험도 작업 성격 예시 권장 설계
낮음 읽기·조회 배송 상태, 일정, 잔액 범위 조회 시스템 표면에서 결과 제공 가능
중간 초안·준비 메시지 초안, 예약 후보, 장바구니 구성 실행 전 앱 또는 시스템 확인
높음 외부 영향 있는 쓰기 공유, 전송, 일정 변경 대상·내용·변경점 명시 후 확인
매우 높음 금전·계약·삭제 결제, 송금, 예약 확정, 계정 삭제 강한 인증, 명시적 최종 확인, 취소 경로

이 분류는 보안팀만의 일이 아니다. PM과 PO가 App Intent 목록을 작성할 때부터 각 액션의 위험도를 붙여야 한다. “사용자가 이 작업을 Siri로 요청했을 때 바로 실행해도 되는가?”라는 질문에 답하지 못하면 intent로 노출할 준비가 안 된 것이다.

특히 Apple Intelligence가 맥락을 이해한다고 해도, 맥락 이해와 실행 권한은 별개다. AI가 “사용자가 아마 이걸 원한다”고 추론할 수 있는 것과 “앱이 실제 결제나 삭제를 수행해도 된다”는 것은 다르다. 좋은 설계는 AI에게 필요한 정보를 제공하되, 되돌리기 어렵거나 외부 효과가 큰 작업에는 명시적 사용자 확인을 요구한다. 고위험 액션일수록 실행 전 요약이 필요하다. “무엇을, 누구에게, 얼마에, 언제, 어떤 조건으로 실행하는지”를 사용자가 확인해야 한다.

또 하나의 현실적인 문제는 개인정보 노출이다. App Entity와 intent 결과가 Spotlight, Siri 응답, Shortcuts 실행 로그, 잠금 화면, Apple Watch 같은 표면에 나타날 수 있다면 민감도 판단이 필요하다. 건강, 금융, 위치, 업무 문서, 가족 정보, 미성년자 관련 데이터는 같은 “조회”라도 다른 정책을 적용해야 한다. 시스템 표면에서 보여줄 수 있는 요약과 앱 내부 인증 후 보여줄 상세를 분리하는 것이 안전하다.

App Intents는 ASO의 대체재가 아니라 발견성의 새 층이다

AI 에이전트 시대가 오면 앱스토어가 사라진다는 식의 전망은 과하다. 사용자는 여전히 앱을 설치하고, 브랜드를 신뢰하고, 화면에서 복잡한 일을 처리한다. 하지만 발견성의 층이 늘어날 가능성은 크다. 과거의 앱 발견은 주로 앱스토어 검색, 광고, 추천, 링크, 웹 검색을 통해 일어났다. 이제는 “사용자가 어떤 앱을 찾는가”보다 “사용자가 어떤 일을 하려는가”가 더 중요해질 수 있다.

예를 들어 사용자가 “다음 주 부산 출장 준비해줘”라고 말했을 때, 시스템은 캘린더, 지도, 항공권, 호텔, 문서, 메모, 메신저 앱의 여러 기능을 조합해야 할 수 있다. 이때 특정 앱이 호출되려면 앱 이름이 유명한 것만으로는 부족하다. 그 앱이 출장 준비와 관련된 작업을 intent와 entity로 잘 표현하고 있어야 한다. App Intents는 앱스토어 최적화의 대체재가 아니라, 설치 이후 시스템 차원에서 앱 기능이 재발견될 수 있는 새로운 표면을 만든다.

이 변화는 특히 다음 유형의 앱에 중요하다.

  • 반복 작업이 많은 생산성 앱
  • 예약, 주문, 배송, 일정처럼 상태 조회가 중요한 서비스 앱
  • 앱 내부 콘텐츠가 많은 미디어·커머스·교육 앱
  • 업무 자동화와 멀티앱 연결이 중요한 B2B 앱
  • 위치, 시간, 기기 상태 등 맥락 기반 호출 가치가 큰 앱

반대로 모든 앱에 같은 수준의 App Intents 투자가 필요한 것은 아니다. 일회성 사용이 많고, 복잡한 시각적 탐색이 핵심이며, 시스템 표면에서 의미 있는 작업 단위로 쪼개기 어려운 앱은 우선순위가 낮을 수 있다. 그러나 앱 안에 반복 가능한 핵심 액션이 있고, 사용자가 “말로 요청할 법한 일”이 있다면 App Intents는 중요한 제품 표면으로 커질 가능성이 있다.

ChatGPT Apps SDK, MCP와 비교하면 무엇이 다른가

App Intents를 더 넓은 AI 에이전트 생태계에서 보면 Apple 생태계 안에서 앱 기능을 호출 가능하게 만드는 인터페이스라고 볼 수 있다. ChatGPT Apps SDK나 MCP 같은 접근은 외부 AI 플랫폼이 앱, 서비스, 데이터 소스, 도구를 호출할 수 있도록 연결하는 방식이다. 반면 App Intents는 Apple 생태계 안에서 iOS, iPadOS, macOS, watchOS의 시스템 경험이 앱 기능을 호출할 수 있도록 만드는 방식에 가깝다.

구분 App Intents ChatGPT Apps SDK·MCP 계열
호출 주체 Siri, Shortcuts, Spotlight, Apple Intelligence 등 Apple 시스템 경험 외부 AI 앱·에이전트·클라이언트
실행 환경 Apple 기기와 앱 생태계 중심 클라우드·데스크톱·웹·엔터프라이즈 환경까지 확장
핵심 가치 설치된 앱 기능과 콘텐츠를 시스템에 노출 서비스·도구·데이터를 AI 플랫폼에 연결
제품 질문 iOS에서 어떤 앱 기능을 호출 가능하게 만들 것인가 AI 에이전트가 어떤 업무 도구를 사용할 수 있게 할 것인가
위험 관리 기기 권한, 앱 권한, 사용자 확인, 시스템 UX API 권한, OAuth, 서버 정책, 조직 보안

둘 중 하나가 다른 하나를 대체한다고 보기는 어렵다. App Intents는 Apple 생태계 내부에서 강하다. 사용자의 기기 맥락, 설치된 앱, 시스템 표면, Siri, Spotlight와 결합한다. MCP나 ChatGPT Apps SDK 계열은 플랫폼 외부의 도구 연결, 조직 시스템 통합, 웹 서비스 호출, 에이전트 워크플로우 구성에서 강하다.

실무적으로 중요한 것은 같은 앱이라도 두 종류의 “호출 가능성”을 따로 설계해야 한다는 점이다. iOS 앱 사업자는 Apple 생태계 안에서는 App Intents로 기능과 콘텐츠를 노출하고, 외부 AI 플랫폼이나 업무 자동화 환경에서는 API, MCP 서버, 앱 SDK, 웹훅 등으로 도구화할 수 있다. 앞으로 앱 전략은 “앱 화면 UX”와 “AI 호출 인터페이스”를 함께 관리하는 방향으로 확장될 가능성이 크다.

실무 시나리오: 어떤 앱이 어떻게 바뀌는가

1. 커머스 앱: 검색과 재구매가 앱 밖으로 나온다

상황: 사용자가 “지난번에 산 충전기 다시 찾아줘”라고 말한다.

입력: 자연어 요청, 과거 주문 App Entity, 상품 App Entity, 재고·가격 정보.

실행 흐름: 지원되는 환경에서는 Siri 또는 Apple Intelligence가 사용자의 요청을 상품 검색이나 주문 조회 intent와 연결할 수 있다. 앱은 최근 주문 중 충전기 관련 상품을 찾아 후보를 반환한다. 사용자는 시스템 표면에서 상품을 확인하거나 앱으로 이동해 구매를 완료한다.

출력: 상품 후보, 가격, 배송 가능 여부, 앱 내 구매 화면 또는 장바구니.

주의점: 바로 결제까지 이어가면 위험하다. 가격 변동, 배송지, 결제수단, 재고 상태를 확인해야 한다. 초기에는 “찾기”, “장바구니 담기”, “구매 화면 열기” 정도가 적절하다.

2. 생산성 앱: 태스크와 문서가 자연어 작업 단위가 된다

상황: 사용자가 “오늘 회의에서 나온 액션 아이템을 프로젝트 Alpha에 추가해줘”라고 요청한다.

입력: 회의록, 프로젝트 App Entity, 태스크 생성 intent, 담당자·마감일 후보.

실행 흐름: 지원되는 환경에서는 시스템이 회의록 또는 최근 문서 맥락을 바탕으로 액션 아이템 후보를 찾고, 앱의 태스크 생성 intent와 연결할 수 있다. 앱은 프로젝트 Alpha를 식별하고, 추가될 태스크 목록을 확인시킨 뒤 저장한다.

출력: 생성 예정 태스크 목록, 담당자·마감일, 저장 결과.

주의점: AI가 추출한 항목은 틀릴 수 있다. 생성 전 확인이 필요하다. 자동 저장보다 “초안 생성 후 확인”이 안전하다.

3. 금융 앱: 조회는 빠르게, 실행은 강하게 확인한다

상황: 사용자가 “이번 달 카드값 얼마나 나왔어?”라고 묻는다.

입력: 카드 청구 App Entity, 월 기준 파라미터, 사용자 인증 상태.

실행 흐름: 앱은 청구 금액 조회 intent를 통해 요약 정보를 반환한다. 민감 정보가 포함되면 앱 내부 인증 또는 제한된 요약만 제공한다.

출력: 이번 달 청구 예정액, 결제일, 상세 보기 링크.

주의점: “송금해줘”, “카드 해지해줘”, “대출 상환해줘” 같은 요청은 조회와 다르게 강한 인증과 명시적 최종 확인이 필요하다. App Intents 전략에서 금융 액션은 위험도 분류가 특히 중요하다.

4. 여행 앱: 예약 객체가 맥락형 도우미의 재료가 된다

상황: 사용자가 “내일 호텔 체크인 정보 보여줘”라고 말한다.

입력: 예약 App Entity, 날짜, 위치, 사용자 계정.

실행 흐름: 시스템은 내일 날짜와 관련된 예약을 찾고, 호텔 예약 조회 intent를 호출한다. 앱은 체크인 시간, 주소, 예약자명, 주의사항을 반환한다.

출력: 체크인 정보 요약, 지도 열기, 호텔에 전화하기, 예약 상세 보기.

주의점: 동행자 정보, 결제 정보, 예약 번호 전체는 민감할 수 있다. 잠금 화면이나 음성 응답에서 어느 수준까지 노출할지 정책이 필요하다.

도입 우선순위: App Intents 목록부터 만들지 말고 작업 지도를 만들어라

App Intents 도입을 개발 과제로만 시작하면 목록이 기술 중심으로 흐르기 쉽다. “이 화면의 이 버튼을 intent로 만들자”가 아니라 “사용자가 앱 밖에서 요청할 가치가 있는 작업은 무엇인가”부터 정리해야 한다. 추천하는 절차는 다음과 같다.

  1. 핵심 사용자 여정에서 반복 작업을 추출한다.
  2. 각 작업을 조회, 검색, 생성, 수정, 공유, 결제·예약, 삭제·취소로 분류한다.
  3. 자연어로 표현 가능한 요청 문장을 5개 이상 작성한다.
  4. 필요한 App Entity와 파라미터를 정의한다.
  5. 위험도를 낮음·중간·높음·매우 높음으로 분류한다.
  6. 시스템 표면에서 완료할지, 앱으로 이동시킬지 결정한다.
  7. 실패·모호성·확인 UX를 설계한다.
  8. Siri, Shortcuts, Spotlight, Action button 중 우선 표면을 정한다.

이 과정에서 가장 중요한 산출물은 코드가 아니라 “작업 지도”다. 어떤 사용자 목적이 있고, 어떤 앱 객체가 필요하며, 어떤 intent가 호출되고, 어디까지 자동화할 수 있는지 정리한 문서다. iOS 개발자는 그다음에 App Intent, App Entity, App Shortcuts를 구현하면 된다. 출처: App Intents | Apple Developer Documentation, App Shortcuts | Apple Developer Documentation

실무에서는 처음부터 거대한 intent 카탈로그를 만들 필요가 없다. 오히려 상위 5개 작업으로 시작하는 편이 낫다. 사용자가 자주 요청하고, 실패 비용이 낮으며, 앱 밖에서 실행할 가치가 큰 작업을 고른다. 예를 들어 “최근 상태 조회”, “새 항목 추가”, “특정 콘텐츠 검색”, “즐겨찾기 실행”, “앱의 핵심 화면으로 이동” 정도다. 이후 사용 패턴과 실패 로그를 보며 확장한다.

제품팀이 지금 던져야 할 질문

App Intents는 개발 프레임워크지만, 결정의 상당 부분은 제품 전략이다. PM, PO, 서비스기획자, 개발 리더는 다음 질문에 답해야 한다.

  • 우리 앱의 핵심 기능을 사용자가 앱 이름 없이 말할 수 있는가.
  • 앱 내부 콘텐츠 중 시스템이 이해하면 가치가 커지는 객체는 무엇인가.
  • Siri나 Spotlight에서 발견되면 전환율보다 사용 편의가 커지는 작업은 무엇인가.
  • 앱 밖에서 완료해도 되는 작업과 반드시 앱 안에서 처리해야 하는 작업은 무엇인가.
  • 자연어 요청이 틀렸을 때 사용자 피해가 생기는 액션은 무엇인가.
  • Shortcuts 자동화에 들어가면 파워유저가 좋아할 작업은 무엇인가.
  • Action button에 연결할 만큼 빈도가 높은 작업은 무엇인가.
  • Apple Intelligence가 사용자 맥락을 이해하더라도 우리가 절대 자동 실행하면 안 되는 작업은 무엇인가.

이 질문들은 앱의 정보구조를 새로 보게 만든다. 지금까지 메뉴 구조는 화면 중심이었다. 앞으로는 작업 중심 구조가 더 중요해진다. 사용자가 직접 앱을 열어 탐색할 때의 IA와, 시스템이 intent를 호출할 때의 작업 모델은 다르다. 좋은 앱은 두 모델을 모두 가진다. 화면 안에서는 풍부한 탐색과 제어를 제공하고, 앱 밖에서는 명확하고 안전한 작업 단위를 제공한다.

과장하지 말아야 할 것들

App Intents의 중요성을 인정하더라도, 몇 가지 과장은 피해야 한다.

첫째, Apple Intelligence가 앱 화면을 곧 대체한다는 전망은 성급하다. 복잡한 비교, 감성적 탐색, 시각적 편집, 학습, 커뮤니티, 게임, 크리에이티브 작업은 여전히 화면 경험이 중요하다. AI와 Siri가 호출하기 좋은 것은 명확한 작업 단위이지, 모든 사용자 경험이 아니다.

둘째, App Intents를 구현한다고 자동으로 앱이 많이 발견되는 것은 아니다. intent와 entity를 노출해도 사용자가 실제로 요청할 만한 가치가 있어야 하고, 명칭과 파라미터가 자연스러워야 하며, 실패 흐름이 좋아야 한다. 시스템 표면에 연결되는 것과 제품 가치가 생기는 것은 별개다.

셋째, 모든 기능을 자동화하는 것이 좋은 전략은 아니다. 고위험 액션을 무리하게 노출하면 신뢰를 잃는다. AI 호출 인터페이스의 성공은 “얼마나 많은 일을 자동으로 하느냐”가 아니라 “사용자가 안심하고 맡길 수 있는 경계가 얼마나 명확하냐”에 달려 있다.

넷째, App Intents는 Apple 생태계 안의 전략이다. Android, 웹, 외부 AI 플랫폼, 엔터프라이즈 자동화까지 포함한 전체 제품 전략에서는 별도 인터페이스가 필요하다. Apple 사용자 경험에 깊게 들어가는 축으로 App Intents를 보고, 외부 에이전트 생태계와는 보완 관계로 봐야 한다.

결론: iOS 앱 전략의 단위가 화면에서 기능 계약으로 확장된다

App Intents는 기술적으로는 프레임워크다. 하지만 제품 전략 관점에서는 iOS 앱이 시스템과 맺는 새로운 계약에 가깝다. 앱은 더 이상 “아이콘을 누르면 열리는 화면 묶음”으로만 존재하지 않는다. Siri, Shortcuts, Spotlight, Action button, Apple Intelligence가 이해하고 호출할 수 있는 기능과 콘텐츠의 집합으로도 존재한다.

이 변화는 앱 사업자에게 새로운 숙제를 준다. 첫 화면을 어떻게 꾸밀 것인가만큼, 앱 밖에서 어떤 작업을 호출 가능하게 만들 것인가가 중요해진다. 검색 가능한 콘텐츠, 실행 가능한 액션, 안전한 확인 흐름, 자연어로 설명 가능한 작업 모델이 제품 경쟁력의 일부가 된다.

Apple Intelligence 시대의 좋은 iOS 앱은 사용자가 직접 열었을 때의 화면 경험뿐 아니라, 사용자가 앱을 열지 않았을 때도 필요한 기능을 안전하고 예측 가능한 방식으로 제공할 수 있어야 한다. App Intents는 그 전환의 기술적 입구다. 그리고 지금 제품팀이 해야 할 일은 Swift 코드부터 쓰는 것이 아니라, 우리 앱이 시스템과 AI에게 어떤 기능 단위로 이해되어야 하는지 다시 그리는 것이다.

참고 출처