Siri AI는 AI Agent가 될까? Apple Intelligence, JSON, API, Tool Calling과 App Actions

먼저 답한다: 일은 한다. 개방 Agent는 아니다

키노트 형용사가 아니라 공학 정의로 묶는다. Agent에는 목표, 지각, 행동이 필요하다. 모델이 다음 도구와 인자를 고르고, 런타임이 실행한 뒤 관찰을 되돌린다. 옛 Siri는 대개 「한 문장을 듣고 단축어나 시스템 기능을 연다」였고, 「결과를 보고 다시 결정」하는 순환은 거의 없었다. 2026년 Siri AI는 그 고리를 닫기 시작한다. App Intents 목록에서 동작을 고르고, 화면 맥락으로 「이것을 메모에 저장」을 해석하며, App을 건너 다음 Intent에 엔티티를 넘긴다. 행동만 보면 시스템급 Agent가 되어 간다.

그래도 IDE나 고객 지원 데스크에서 세우는 개방 Agent는 아니다. 차이는 모델의 똑똑함이 아니라 도구 경계를 누가 긋느냐다. 개방 Agent의 목록은 당신이 주입한다. OpenAI tools[], Anthropic tool_use, MCP tools/list. arguments는 거의 항상 JSON이다. 시스템 Siri의 목록은 기기에 이미 선언된, 가급적 App Schema에 맞춘 Intent다. 파라미터는 Swift 타입이지, 직접 parse하는 자유 텍스트가 아니다. 프라이버시 울타리도 다르다. 기기와 Private Cloud Compute가 어떤 맥락이 나갈 수 있는지 정한다. 시스템 프롬프트에 「연락처를 읽어도 된다」고 쓰는 문제가 아니다. Siri를 「함수를 걸 수 있는 또 하나의 ChatGPT」로 읽으면 잘못된 이전을 한다. App Intents를 지우거나, iOS에서 Gemini API를 불러 「본사에 맞춘다」는 식이다.

한 문장. Siri AI는 시스템 안의 Agent가 된다. 당신이 소유한 Agent 런타임은 되지 않는다. 통제할 수 있는 것은 시스템에 내놓는 동작의 모양과, 동작이 HTTP에 떨어진 뒤의 JSON이다. 다음 두 절에서 제품 층과 계약 층을 나눠 「일을 한다」를 「개방 도구 루프」로 읽지 않게 한다.

2026년 Siri AI가 실제로 얻은 세 가지

Apple 개발자 문서와 WWDC26 표현은 Siri의 App Intents 능력을 세 가지로 접는다. Agent처럼 보이는 이유와, JSON Schema를 붙여 끝낼 수 없는 이유를 함께 설명한다.

1. 내용에 닿는다. 업무 객체를 App Entity로 만들고 Entity Schema에 맞춘 뒤 Spotlight 의미 색인에 넣는다. 그래야 Siri가 개인 맥락에서 「그 결제된 주문」을 찾지, 홈 화면만 열지 않는다.
2. 동작을 실행한다. Intent가 Intent Schema(커머스, 사진, 통신 등 사전학습 영역)에 맞으면 자연어가 perform()에 닿는다. 말마다 트리거 문구를 쓰지 않는다. 공식 페이지가 반복하는 app actions가 이것이다.
3. 화면을 이해한다. View Annotations나 NSUserActivity로 눈앞 뷰를 엔티티로 표시해야 「이것」「저것」이 된다. 크로스 App 요청은 대개 여기서 시작한다. 직접 짠 다단계 planner에서 시작하지 않는다.

셋이 겹치면 사용자는 「Siri가 일을 한다」고 느낀다. 개발자는 자기 App이 시스템 Agent의 도구 상자가 되었다고 느낀다. WWDC26의 Build intelligent Siri experiences with App Schemas는 테스트 순서도 고정한다. 먼저 Intent 업무 논리, 다음 단축어에서 인자 모양, 다음 Spotlight 색인, 마지막에 Siri 종단. 앞 셋을 건너뛰고 음성만으로 때리면 디버그 비용이 커진다.

모델 층도 움직인다. 제품 교체로 읽지 마라. 2026년 1월 공동 성명은 차세대 AFM 기반을 Gemini 기술에 걸었다. 6월 Private Cloud Compute는 더 무거운 agentic tool-use를 위해 Google Cloud로 넓어졌다. 사용자가 보는 것은 여전히 Siri / Apple Intelligence이지 Gemini 브랜드도, Google Assistant도 아니다. 전략 분해는 Apple이 Gemini에 기대는 이유, ChatGPT 확장과의 층 나눔은 세 제품 비교. 당신에게 바뀌는 것은 클라우드 모델이 얼마나 대담하게 다단계 동작을 짜느냐이지, 파라미터 표의 성이 아니다.

세 층: Apple Intelligence, 모델, 개발자 표면

「Siri가 Agent가 됐다」를 한 층으로 누르면 이후 결정이 모두 기울다. 적어도 셋을 가른다. 사람이 보는 제품, 추론이 도는 곳, 코드가 구현하는 계약.

Foundation Models는 다른 선이다. App은 기기(그리고 문서가 쓰는 PCC 경로)에서 LanguageModelSession을 돌리고, Tool로 앱 안 tool calling을 하며, 구조화 생성으로 출력을 묶는다. 「내 App이 Agent 런타임」이지 「시스템 Siri가 Agent로 Intent에 들어온다」가 아니다. 많은 App은 둘 다 낸다. Siri / Spotlight / 단축어에 발견되려면 App Intents. 기기 모델이 재고를 조회하거나 폼을 채우려면 Tool. HTTP 연결은 Apple AI Agent가 App과 API에 닿는 방법.

단축어가 층을 붙인다. Apple Intelligence는 자연어로 다단계 자동화를 조립한다. App Intents를 채택하면 동작이 Use Model 같은 능력과 나란히 그 생태계에 들어간다. 사용자는 「결제된 주문을 찾아 메모에 적어」라고 말할 수 있다. 편성자는 여전히 시스템이지 서버의 planner가 아니다. 각 Intent 파라미터는 홀로 성립해야 한다. 시스템이 한 홉만 돌리거나 순서를 바꿀 수 있다.

App Intents, App Schemas, App Actions

App Intents는 「Siri에 음성을 더한다」가 아니다. 서드파티 App과 Apple Intelligence의 계약이다. 제공할 내용과 실행할 동작을 선언하고, 언제 호출할지는 시스템이 정한다. iOS 18부터 깔렸고 2026년에는 Siri, Spotlight, Widget, 단축어, 시스템 Agent에 동시에 공급한다. App Intents를 선택 사항으로 보는 팀은 시스템 AI의 정문을 오독한다.

App Schema는 그 계약의 사전학습된 모양이다. Entity Schema는 주문, 사진, 대화임을 알려 의미 색인에 넣는다. Intent Schema는 찾기, 열기, 공유임을 알려 유지할 트리거 말뭉치 없이 자연어가 맞게 한다. Xcode 매크로가 적합 스텁을 만들고 컴파일 때 확인한다. 영역이 어긋나면 Siri는 동작을 평범한 단축어로 취급하고, 시스템 Agent가 우선하는 도구로 두지 않는다. WWDC26은 더 긴 Intent, 취소, 기기 간 동기 엔티티도 더했다. 루프처럼 보이지만 스케줄은 시스템 것이다.

App Actions라는 말이 가장 잘 날아간다. Apple 개발자 페이지의 app actions는 App Intents로 노출되어 Siri AI와 시스템 표면이 실행하는 능력이다. Google Assistant의 역사적 App Actions 프로토콜도, Android intent filter도 아니다. 둘 다 「도우미가 App을 부른다」지만 필드, 목록, 프라이버시 모델은 다르다. 설계 문서에는 「App Intents / App Schema」를 쓰고 「App Actions」는 사용자용 표현으로 남겨라. 섞으면 백엔드가 없는 Google식 JSON-RPC를 찾는다.

Tool Calling: 시스템 Agent와 앱 안 Tool

업계 Tool Calling / Function Calling은 한 메커니즘이다. 모델은 데이터베이스에 손대지 않고 「이 함수를 이 인자로 호출해」라고 내며 런타임이 실행한다. 2026년 껍질은 다르다. arguments는 여전히 JSON object다. Siri 쪽에서는 같은 일이 타입 Intent가 된다. 시스템 모델이 findOrders를 고르고 email / status / limit를 채운 뒤 perform()에 들어온다. perform()이 자체 HTTP API를 치면 그때 JSON으로 엮는다. 두 홉에 「그냥 parse」 경로를 공유하지 마라.

골든 페이로드는 의도 층에 둔다. 모델 상표 아래가 아니다. 아래 JSON은 누가 시작했는지, 어떤 schema, 어떤 동작, 어떤 인자만 적는다. runtime.onDevice는 로그에 좋다. 업무 검증에는 넣지 마라. 기기 폴백과 클라우드 전량은 같은 arguments를 받아야 한다.

{
  "source": "siri-ai",
  "schema": "commerce.findOrders",
  "intent": "findOrders",
  "arguments": {
    "email": "ada@example.com",
    "status": "paid",
    "limit": 5
  },
  "runtime": {
    "surface": "siri",
    "onDevice": false
  }
}

같은 업무 필드가 직접 짠 개방 Agent에 나오면 각사 tool_calls 껍질을 입는다. arguments는 종종 문자열이다. 먼저 JSON.parse, 같은 Schema로 검증. Siri가 들어올 때는 그 껍질이 없고 타입 파라미터만 있다. 자체 API로 나갈 때 다시 JSON이 보인다.

{
  "id": "call_8f3a",
  "type": "function",
  "function": {
    "name": "findOrders",
    "arguments": "{\"email\":\"ada@example.com\",\"status\":\"paid\",\"limit\":5}"
  }
}

대조는 분명하다. 이름은 둘 다 findOrders. 키는 같은 Schema에서 와야 한다. 시스템 경로에는 tool_call id가 없고, 개방 경로에는 App Schema 도메인이 없다. Gemini generateContent, OpenAI tools[], App Intent 파라미터 표를 서로의 기본값으로 쓰지 마라. Structured Output은 최종 답 모양이지 이 홉의 입력 인자가 아니다. 파일을 나누는 이유는 AI Structured Output.

JSON, API, 로컬 검증

Siri가 Agent에 가까워지면 실패도 Agent에 가까워진다. 홉이 늘고, 선택 필드가 채워지고, 열거가 날아가고, 기기 폴백에서 키가 둘 빠진다. 강한 모델은 검증을 없애지 않는다. 놓친 비용을 키울 뿐이다. 밖으로 나가는 hop은 여전히 parse → Schema → 업무 규칙이다.

1. Intent 파라미터를 JSON으로 만든 뒤 바로 parse한다. 실패하면 intent 이름과 원본 필드를 남기고 재시도 가능한 오류를 반환한다. Swift 예외 원문을 사용자에게 던지지 마라.
2. 같은 Draft 2020-12 Schema로 타입, 열거, required를 고정한다. additionalProperties는 false가 낫다. 클라우드 단이 더한 키가 하류로 새지 않게.
3. 업무 게이트: 권한, 외래 키, 날짜 범위. 통과한 뒤에 주문 서비스를 친다. 시스템 Agent가 재시도하면 API는 멱등이어야 한다.

세 JSON을 나란히 둔다. Siri / 단축어가 보낸 파라미터, HTTP로 내는 body, 서버가 실제로 쓴 객체. 모양이 다르면 거의 어댑터 층이다. 브라우저에서는 JSON 포맷터로 필드를 보고, JSON Schema 검증으로 타입을 고정하고, JSON Diff로 기기 폴백과 클라우드 전량의 빠진 키를 본다. valid / missing-field / wrong-enum을 CI와 Siri 실기기에서 공유한다.

더 읽기: Apple AI Agent와 JSON, AI Agent란, AI JSON 오류 가이드, MCP와 JSON Schema.

자주 묻는 질문

요약과 다음 단계

Siri AI는 AI Agent가 된다. 시스템 울타리 안에서. Apple Intelligence가 개인 맥락, app actions, 화면 인식을 주고, 모델 층은 Gemini 기술과 더 무거운 PCC를 빌릴 수 있으며, 개발자는 여전히 App Intents로 동작을 넘기고 Foundation Models Tool로 앱 안 루프를 돈다. 개방 Tool Calling JSON 껍질은 시스템 요청에 나타나지 않는다. 자체 API에는 나타난다.

다음은 구체적이다. 맞출 App Schema를 나열하고, Intent 파라미터와 HTTP body를 한 Schema로 쓰며, JSONVue에서 valid / 빠진 필드 / 잘못된 열거를 재생한다. 모델 상표는 바뀐다. 동작 모양은 따라 바뀌면 안 된다.