Siri가 내 앱을 호출한다면, 어떤 기능부터 열어야 할까?

택배가 늦습니다. 고객은 퇴근하기 전에 사무실에 도착할지 알고 싶은데, 답을 찾으려면 로그인 화면과 주문 목록, 배송 추적 페이지를 차례로 열어야 합니다. 앱이 비서에게 해당 배송 건을 조회할 명확한 방법을 제공한다면 자연어 요청으로 이 과정을 줄일 수 있습니다.

Apple은 11월 3일 iOS 27.3 등 베타 소프트웨어에서 App Intents용 Siri AI 개발자 프리뷰를 열었습니다. 개발자는 개인 맥락과 화면 정보, 관련 동작을 활용할 수 있는 요청에 앱을 연결할 수 있습니다. Apple은 나중에 이 연동을 고객에게 제공할 계획이며, App Store 제출은 봄으로 예상됩니다. 사람들이 기능에 의존하기 전에 각각의 동작이 어떻게 작동해야 할지 다듬을 기회입니다.

2014년의 Siri. Kārlis Dambrāns 촬영. 자르기 및 크기 조정, CC BY 2.0. 이미지 출처 · 라이선스.

결과를 알아볼 수 있는 일 하나부터 비서에게 맡긴다

App Intent 조회. Telli.sh 자체 제작.

App Intent는 앱이 실행할 준비가 된 동작을 나타냅니다. 배송 상태 조회를 내놓는 앱을 생각해 보죠. 앱이 식별할 수 있는 배송 엔터티를 입력으로 받고, 해당 배송 건과 최신 상태, 갱신 시각을 결과로 돌려줄 수 있습니다. 데이터는 앱이 소유하며 로그인 계정이 볼 수 있는 범위도 앱이 정합니다.

이렇게 설계하면 짧은 대화로 답을 줄 수 있습니다. 계정 하나에 진행 중인 배송 건이 세 개라면 비서가 이를 구분할 정보가 필요합니다. 운송장 번호, 짧은 이름, 사용자가 알아볼 목적지로 선택 대상을 명확히 할 수 있습니다. ‘내 택배’처럼 여러 건에 해당하는 말이 들어오면 어느 건인지 다시 물어야 합니다.

첫 두 요청은 출발점으로 좋습니다. 대체로 거래를 일으키지 않고 유용한 답을 줄 수 있습니다. 예약을 변경할 때는 지켜야 할 조건이 다릅니다. 요청 시간이 비어 있지 않을 수도 있고, 업체가 수수료를 부과하거나 시간대를 변환하면서 날짜가 달라질 수도 있습니다. 앱의 동작과 응답에 이런 조건을 반영해야 합니다.

실행 시점에 앱이 권한을 확인한다

App Intent 변경. Telli.sh 자체 제작.

비서는 문장의 뜻을 파악하고 실행할 만한 동작을 찾을 수 있습니다. 누가 요청했는지, 어떤 항목에 접근할 수 있는지, 실제로 실행해도 되는지는 여전히 앱에서 확인해야 합니다. 기존 앱 화면에서 수행하던 점검을 해당 동작 경로에도 적용하세요. 다른 계정으로 로그인했거나 기기가 잠겼거나 세션이 만료된 상태에서도 자연어 요청은 들어올 수 있습니다.

금액이 발생하는 약속이라면 얼마를 누가 지불하는지 마지막에 보여줘야 합니다. 배송지를 바꿀 때는 확인 전에 목적지를 표시하세요. 백엔드가 요청 성공 여부를 알 수 없다면, 똑같은 요청을 다시 보내도록 유도하기보다 사용자가 확인하고 처리할 수 있는 상태를 반환하세요. 결제 화면을 만들어 봤다면 익숙한 규칙입니다. 음성이나 채팅에서는 같은 내용을 훨씬 짧은 공간에서 명확히 전해야 할 수 있습니다.

예를 들어 커피 한 봉지를 다시 주문한다고 해보죠. 첫 주문에는 한시 할인 가격이 적용됐을 수 있고, 당시 배송지가 현재 주소가 아닐 수도 있으며, 상품의 용량이 여러 가지일 수도 있습니다. 주문하기 전에 현재 상품과 용량, 가격, 주소를 알려주면 안전합니다. 처리한 뒤 영수증도 쉽게 찾을 수 있게 할 수 있습니다.

사용자의 상황은 알맞은 출발점을 찾는 데 도움이 됩니다. 실제로 그중 어떤 정보를 앱이 사용했는지 분명해야 합니다. 화면에 주문이 하나만 보인다면 ‘지금 보고 있는 주문’이라는 확인 문구로 충분할 수 있습니다. 항목이 여러 개라면 선택한 주문을 구체적으로 다시 말하세요. 실행하기 전에 사용자가 해석을 바로잡을 기회를 주세요.

여러 동작을 엮을 때는 최종 상태를 정확히 알려야 한다

Apple은 여러 동작을 조합하는 스킬과 Spotlight 시맨틱 색인에서의 엔터티 지원도 설명합니다. 이를 함께 쓰면 요청을 하고 답을 받기까지 거치는 화면 수를 줄일 수 있습니다. 한 동작의 출력이 다음 동작의 입력이 될 수 있어, 작은 오류도 흐름 전체에서 더 중요해집니다.

예정된 예약을 찾아 시간을 바꾸는 요청을 생각해 보죠. 조회는 성공하고 변경은 실패할 수 있습니다. 두 상태를 모두 알려주세요. 예약은 찾았지만 원래 시각 그대로라고 알리면 사용자가 현재 상태와 다음 행동을 파악할 수 있습니다. 막연한 성공 메시지는 변경 실패를 가리고, 막연한 오류는 조회 성공을 가립니다.

실용적인 동작 흐름은 여러 종류의 결과를 필요로 합니다. 한 단계는 후보를 돌려주고, 다음 단계는 선택이나 확인을 요청하며, 마지막은 처리 내역이나 대기 상태를 돌려줄 수 있습니다. 동작을 조합할 때는 사용자가 도중에 마음을 바꾸는 경우와 네트워크 호출이 대화에서 기다릴 만한 시간보다 길어지는 경우를 시험하세요.

내부에서는 바뀌지 않는 레코드 식별자를 쓰세요. 자연어 이름은 바뀌고 비슷한 이름을 가진 항목도 여러 개일 수 있습니다. 고정 ID를 사용하면 앱은 맞는 대상을 처리했는지 확인하면서도 사람에게는 알아보기 쉬운 설명을 줄 수 있습니다. 맥락이 더 필요한 사용자가 해당 화면을 바로 열도록 원본 항목 링크를 남겨 두세요.

결과를 손으로 대조할 수 있는 동작으로 프리뷰를 시험한다

1. Apple 개발자 발표에서 지원하는 베타 운영체제와 기기, 언어를 확인하세요. 시험 계정과 시험 데이터를 쓰세요. Apple은 지원 언어에 한국어를 포함하고 기기와 지역별 제한도 설명합니다.
2. 사용자가 이미 자주 실행하는 조회 동작 하나를 고르세요. 평소 화면에서 어디를 거치는지, 동작이 성공하면 정확히 어떤 답을 줘야 하는지 기록하세요.
3. Apple의 App Intents 문서를 바탕으로 동작과 대상 엔터티를 모델링하세요. 요청에 맞는 레코드가 없거나 하나이거나 여러 개일 때 각각 어떻게 처리할지 정하세요.
4. 정상 요청과 모호한 요청을 모두 실행해 보세요. 계정 없음, 세션 만료, 중복 이름, 네트워크 사용 불가를 포함하세요. 결과마다 앱의 현재 화면과 대조하세요.
5. 이후 변경 동작을 추가할 때는 사용자가 대상과 조건, 결과를 어디서 보는지 기록하세요. 시간 초과 뒤 같은 요청을 다시 보내도 앱이 올바르게 처리하는지 확인하는 시험도 넣으세요.
6. 고객 출시 시점과 개발자 프리뷰를 별개의 이정표로 보세요. App Store 출시를 계획할 때 Apple의 최신 제출 및 정책 안내를 다시 확인하세요.

여러 가지 표현도 이 단계에서 시험할 만합니다. 배송 앱이라면 고객지원 요청에 실제로 들어오는 말부터 써 보세요. 날짜를 말하는 사람도 있고, 판매점 이름을 대거나 택배가 가는 곳으로 설명하는 사람도 있습니다. 발화에 정보가 빠졌을 때 동작이 어떤 방식으로 다시 묻는지 확인하세요. 좋은 확인 질문은 사용자를 답에 한 걸음 더 가깝게 데려갑니다.

결과에 맞는 화면을 고른다

Apple은 Spotlight의 앱 엔터티, 앱 전용 동작, 스니펫, 여러 동작을 묶은 스킬을 구분합니다. 배송 앱은 사용자의 구체적인 질문 하나에 어떤 방식이 맞는지 정할 수 있습니다. 검색에 뜬 엔터티는 주문을 알아보게 합니다. 동작은 현재 계정에서 요청을 처리합니다. 카드는 결과를 한눈에 읽기 좋게 보여줍니다. 주문 찾기가 첫 단계에 불과할 때는 여러 동작을 잇는 방식이 유용합니다.

상태 조회 카드에는 도착 도시, 현재 상태, 배송사의 마지막 갱신 시각을 담을 수 있습니다. 얼마나 자세히 보여줄지는 카드가 어디에 나타나는지, 기기가 잠겨 있는지에 따라 다릅니다. 화면을 점검할 때는 사용자가 음성 안내를 들었다고 가정하지 마세요. 음성을 시험할 때도 중요한 경고가 화면에만 표시된다고 생각하지 마세요. 같은 원본 데이터가 두 환경에서 모두 이해돼야 합니다.

Apple 프리뷰 가이드는 비서가 앱을 지정하는 방법도 설명합니다. 앱이 백그라운드에 있을 때 사용자 정의 동작을 실행하려면, 아래의 예외에 해당하지 않는 한 앱 이름이 필요합니다. 포그라운드에 열린 앱, 진행 중인 Live Activity, 이미 앱 이름을 언급한 대화가 맥락을 제공할 수 있습니다. 먼저 앱을 명시해 동작 자체가 작동하는지 확인하세요. 그런 뒤 홈 화면, 다른 앱이 보이는 상태, 진행 중인 대화에서 같은 요청을 해 보세요. 맥락별 결과를 기록하세요.

배포 경로는 따로 시험한다

프리뷰 가이드는 개발용으로 서명한 빌드를 기기에서 시험하거나 내부 TestFlight를 사용하는 방법을 설명합니다. 외부 TestFlight와 App Store로 배포한 빌드에서는 이 프리뷰 연동을 시험할 수 없다고 안내합니다. 제품 담당자가 고객 대상 시험을 제안할 때 중요한 차이입니다. 개발 빌드에서 제대로 시연됐더라도 고객이 스토어 버전에서 같은 기능을 켤 수 있다는 뜻은 아닙니다.

Apple은 호환되는 Apple Intelligence 하드웨어와 한국어를 포함한 여섯 가지 언어를 지원한다고 밝혔습니다. 지역과 연령, 서버 측 제한도 적용됩니다. Apple은 Siri AI용으로 iOS, iPadOS, macOS, watchOS, visionOS 27.3 베타를 안내하지만, 초기 타사 개발자 프리뷰에는 iOS, iPadOS, macOS, visionOS를 명시합니다. 시험 인원을 배정할 때 이 두 범위를 나누세요. 범위를 명확히 적은 시험 기록이 있으면 다음 개발자가 동작과 테스트 채널, 기기 중 어디에서 문제가 생겼는지 찾기 쉽습니다.

요청과 기기, 언어, 배포 경로, 결과를 시험 표에 한 줄씩 남기면 좋습니다. 검증된 한 줄부터 채우세요. 한국어 상태 조회라면 짧은 구어체 표현과 판매점 또는 배송 추적 날짜를 넣은 요청을 비교하세요. 둘 다 같은 레코드를 가리키면 유용한 표현 차이를 견딘 것입니다. 다른 사람의 주문이 노출된다면 시험을 멈추고 권한 검증이 일어나는 경로부터 고치세요.

마지막 인수 시험에는 사용자가 직접 이어서 처리하는 경로를 넣으세요. 예약을 찾을 수는 있지만 옮길 수 없다면 가능한 시간을 보여주고 맞는 화면을 여세요. 변경까지 할 수 있다면 완료 결과를 보여주고 나중에 앱에서 처리 내역을 찾을 수 있게 하세요. 두 경우 모두 앱은 사용자가 다음에 무엇을 할 수 있는지 구체적으로 안내합니다.

동작 하나가 분명할 때 바로가기에 신뢰가 쌓인다

Siri AI 연동의 매력은 앱에서 가장 유용한 기능을 필요한 사람 가까이에 둘 수 있다는 점입니다. 범위가 좁고 결과를 검증할 수 있는 동작 하나만으로도 많은 연동 없이 실제 가치를 줄 수 있습니다. 알맞은 배송 상태를 정확히 보여줄 수 있는 사업자라면 그 기능부터 시작할 만합니다.

동작을 추가할 때는 모두 같은 기준을 적용하세요. 앱이 무엇을 찾았고 무엇을 하기 위해 허락을 구했으며 결과가 어땠는지 사용자가 이해해야 합니다. 여러 서비스를 거치는 요청이나 사용자가 원래 앱 화면을 열지 않는 경우에는 이런 명확성이 더 중요합니다.

출처

• Apple Developer의 11월 3일 Siri AI 프리뷰 발표
• Apple App Intents 문서
• Apple 개발자 프리뷰 설정 및 시험 가이드
• Apple Spotlight 및 App Intents 문서

---

업무의 배경이 된 대화와 결정 사항을 검색 가능한 기록으로 남기려면 Telli.sh 계정을 만드세요.