블로그 • AI / Agent

Siri AI는 AI Agent가 될까? Apple Intelligence, App Actions, API와 JSON의 동작 원리

Siri AI를 들으면 ChatGPT처럼 도구를 고르고 API를 조립하는 Agent로 상상하기 쉽다. Apple이 WWDC 2026에서 낸 것은 그 종류가 아니다.

Siri AI는 시스템 Agent가 되고 있다. 개인 컨텍스트를 이해하고, 화면의 내용을 보며, 크로스 App으로 App Actions를 실행한다. 개방 Agent가 아니다. 모델은 REST 경로를 발명하지 못하고, 서버에 JSON을 마음대로 쓰지도 못한다.

이 글에서는:

• Apple Intelligence와 Siri AI가 각각 맡는 층
• App Actions가 개발자 쪽에서 대응하는 것 (App Intents + App Schemas)
• 한 번의 크로스 App 작업에서 데이터가 흐르는 방식
• JSON이 나오는 홉, 나오지 않는 홉
• Function Calling / MCP Agent와의 대조, JSONNote에서 동작 인수를 검증하는 법

먼저 답: 시스템 Agent이지 개방 Agent가 아니다

Agent라는 말은 이미 남용된다. 어떤 사람은 「대화하는 도우미」, 어떤 사람은 「일이 끝날 때까지 도구를 반복 호출하는 런타임」으로 쓴다. Siri AI는 후자에 가깝지만, 도구가 어디서 오는지는 개방 Agent와 전혀 다르다.

개방 Agent(ChatGPT, Claude, 자체 Runtime)는 보통 이렇게 돈다. 모델이 대화를 보고 tools 목록에서 name과 arguments를 고르고, Runtime이 실행한 뒤 결과를 대화에 넣는다. 도구 카탈로그는 당신이 쓰고, JSON Schema가 입력 계약이며, MCP가 발견과 실행을 맡는 경우가 많다. 이 네 층을 나눈 다른 글:

2026 AI Agent 스택: LLM, MCP, Function Calling, JSON Schema를 어떻게 조합할까?

Siri AI의 루프는 시스템 안에 있다. 사용자가 Siri에게 말하거나 화면의 「이것」을 가리킨다. 시스템 쪽 모델(기기 또는 Private Cloud Compute)이 의도를 이해한 뒤, 설치된 App이 노출한 동작 카탈로그에서 고른다. App은 세션 주인이 아니고, 라우팅된 기능 제공자일 뿐이다.

그래서 답은 「예」 또는 「아니오」가 아니다. Siri AI는 계획을 세우고, 슬롯을 채우고, 크로스 App으로 연속 작업을 한다. 이미 Agent 행동이다. 그렇다고 MCP Server를 마음대로 거는 개방 런타임이 되지는 않는다. 두 체인 모두 App, API, JSON을 만나지만, 세션 소유자와 인수 생성 주체는 다르다.

Apple Intelligence와 Siri AI는 각각 무엇인가

먼저 제품명을 가른다. 섞이면 뒤의 App Actions와 JSON이 착지할 곳이 없다.

Apple Intelligence는 플랫폼이다. 생성 모델을 iPhone, iPad, Mac의 시스템 능력에 넣는다. 쓰기, 이미지, 알림 요약, Visual Intelligence, 그리고 기기를 나가야 하는 일부 추론이 이 층에 걸린다. 기기 밖 요청은 일반 퍼블릭 클라우드 로그가 아니라 Private Cloud Compute를 탄다. 공식 입구는

Apple Intelligence。

Siri AI는 2026년 6월 WWDC에서 발표한 차세대 Siri로, 다음 세대 Apple Intelligence가 구동한다. Apple 표현은 이렇다. 대화에 더 능하고, 개인 컨텍스트가 있으며, 세계 지식이 있고, 화면을 인지하며, 시스템 전역에서 더 많은 App Actions를 호출한다. 기기를 넘어 대화를 다시 보는 독립 Siri 앱도 생겼다. 보도자료는

Apple, Siri AI 소개。

개발자 테스트는 WWDC 당일부터 iOS 27, iPadOS 27, macOS 27, visionOS 27을 덮는다. 2026년 9월 초 기준으로 아직 가을 시스템 테스트 주기 안이다(8월 말 iOS 27 developer beta 8). 이 글을 쓰는 시점에, 모든 사용자 기기에서 기본으로 켜진 완제품으로 보지 말 것.

세 번째 체인이 있다. Siri와 섞지 말 것. App 안에서 Foundation Models로 세션을 직접 연다. 그때 모델은 프로세스 안에서 돌고, 도구는 당신이 주입하며, 시스템은 「어느 App을 열지」 대신 고르지 않는다. 프레임워크 설명은

Foundation Models。

WWDC 2026은 Gemini를 선택 가능한 외부 기반 모델로 넣었고, 기존의 ChatGPT와 나란히 둔다. 사용자에게는 「세계 지식을 물을 출구가 하나 더」일 뿐이다. 개발자에게 App Actions 계약은 거의 바뀌지 않는다. 외부 모델도 선언하지 않은 Intent에는 닿지 못한다.

App Actions: Siri가 App을 호출하는 방식

사용자가 듣는 말은 App Actions다. Siri가 이 App에 무엇을 할 수 있는가. 개발자가 내는 것은 App Intents다. Siri AI가 동작을 오케스트레이션하게 하려면 App Schema(assistant schema)에 맞춰야, 시스템 사전학습 모델이 「어느 종류의 동작인지」 알아본다.

Apple의 WWDC26 표현은 단호하다. Siri가 세진 것은 Apple Intelligence 덕이고, 개발자가 Apple Intelligence에 참여하는 방식은 App Intents다. 세션

Build intelligent Siri experiences with App Schemas

Siri의 능력을 세 가지로 접는다. 엔터티에 접근하고, Intent로 동작을 실행하며, 화면 컨텍스트를 이해한다.

App Intents는 기능 카탈로그다

시스템 Agent에게 App은 「열어 구경」이 아니라 발견 가능한 기능 카탈로그다. AppIntent로 동작 이름, 자연어 설명, 인수 타입, 결과를 선언한다. Spotlight, Shortcuts, Siri, Apple Intelligence가 이 카탈로그를 공유한다. 사용자가 「이 송장을 지급 완료로 표시」라고 하면 시스템은 MarkInvoicePaidIntent로 매핑해야 한다. 모델이 UI를 마음대로 탭하게 두면 안 된다.

문서:

App Intents

및

Siri와 Apple Intelligence에 actions 연결하기。

App Schemas가 Siri에게 종류를 알려 준다

평범한 App Intent는 이미 Shortcuts에 나타난다. Siri AI가 자연어로 호출하게 하려면 Intent, Entity, Enum을 assistant schema로 표시해야 한다. 예: photos.openAsset, notes.createNote. Schema에는 고정된 인수 형태가 있다. Xcode가 컴파일 시점에 맞았는지 검사한다.

이것이 개방 Agent와의 가장 큰 차이다. 개방 Agent의 도구 이름은 당신이 짓는다. Siri AI의 도구 이름은 Apple이 미리 학습한 도메인 어휘에 떨어져야 한다. 더 「창의적인」 동작 이름을 쓰면 시스템이 아예 고르지 못할 수 있다.

@AppIntent(schema: .finance.markInvoicePaid)
struct MarkInvoicePaidIntent: AppIntent {
    @Parameter var invoice: InvoiceEntity
    @Parameter var paidAt: Date

    func perform() async throws -> some IntentResult {
        try await InvoiceService.markPaid(
            id: invoice.id,
            paidAt: paidAt
        )
        return .result()
    }
}

위 조각에는 JSON이 없다. Siri가 넘기는 것은 타입화된 인수다. 업무는 perform()에서 한다. 네트워크가 필요하면 도메인 서비스가 JSON을 인코딩한다.

테스트는 Siri부터 시작하지 말 것. Apple은 AppIntentsTesting을 제공해, 격리 환경에서 Intent를 호출하고 인수를 넣고 결과를 단언하게 한다. 그다음 Shortcuts에서 형태를 보고, 마지막에 Siri로 엔드투엔드를 넘긴다. 순서를 뒤집으면 「모델이 막 한다」고 느끼지만, 실제로는 schema가 안 맞은 것이다.

한 번 크로스 App 작업의 데이터 흐름

구체 요청으로 층을 잇는다. 사용자가 Messages에서 「금요일 모임, 네가 샐러드 가져와」를 보고, 이 문장을 가리키며 Siri에게 말한다. Notes에 적고, 쇼핑 목록에 상추와 올리브유를 더해 줘.

1. 1
   화면 컨텍스트가 시스템으로 들어간다

   Siri는 onscreen awareness로 「이것」이 메시지 한 줄임을 안다. 뷰가 App Entity에 연결되어야 시스템이 지칭을 해석한다. 모델이 픽셀을 추측하게 두면 안 된다.

2. 2
   모델은 계획과 선택만 한다

   시스템 모델은 말을 두 단계로 나눈다. Notes의 생성 동작, Shopping의 항목 추가 동작. URL을 조립하지 않고 SQL도 쓰지 않는다.

3. 3
   Schema에 맞춰 인수를 채운다

   제목, 날짜, 항목 이름이 타입 값이 된다. 슬롯이 비면 Siri가 한 번 더 묻는다. 이 단계의 계약은 assistant schema이지 OpenAPI 문서가 아니다.

4. 4
   각 App이 perform()을 실행한다

   Notes와 Shopping이 각자 Intent를 돌린다. 서버 동기화가 필요할 때 여기서 HTTP JSON이 나타난다.

5. 5
   결과가 시스템 세션으로 돌아온다

   Siri는 Intent 결과로 답을 짠다. 크로스 App 엔터티 전달은 대화에 JSON 전체를 쏟는 대신 Transferable을 탈 수 있다.

이 체인에서 개발자가 자주 밟는 함정: Intent를 「뭐든 하는」 만능 함수로 쓰기. description이 너무 넓어 모델이 매사에 호출하기. perform()에서 주문 JSON 전체를 돌려 시스템 컨텍스트를 터뜨리기. 나은 방법은 요약을 반환하고, 세부는 두 번째 동작으로 id를 다시 가져오는 것이다.

이 체인에서 JSON의 세 역할

Swift 타입은 컴파일 시점 계약, JSON은 런타임 계약이다. Siri 홉에는 JSON이 없을 수 있다. 동작이 현재 프로세스를 넘는 순간——백엔드, 파일, 테스트 픽스처 재생, 다른 Agent 재사용——형태는 언어 중립 텍스트가 되어야 한다.

JSON은 최소 세 역할을 한다. 두 층을 섞으면 「parse는 되는데 필드가 전부 틀림」이 된다.

첫 층이 가장 잘 빠진다. Xcode App Intents Console은 호출과 인수를 찍는다. 같은 호출을 JSON 객체로 쓸 수 있어야 디버그에 재생이 있다. 둘째 층이 청구와 인증이 실제로 일어나는 곳이다. 셋째 층은 2026년에 이미 많은 팀이 하는 일이다. 같은 markPaid를 Siri에도, 사내 Claude Agent에도 준다.

JSON Schema는 App Schema를 대체하지 않는다. App Schema는 시스템 모델이 보는 도메인 계약이다. JSON Schema는 백엔드, 테스트, 외부 모델이 보는 데이터 계약이다. 필드는 맞춰야 한다. Siri가 OpenAPI 파일을 읽는다고 상상하지 말 것. AI 쪽이 이 계약을 흔히 필요로 하는 이유는

AI에 JSON Schema가 필요한 이유?

Function Calling / MCP와 무엇을 비교하는가

대조는 한 가지만 본다. 결정이 무엇으로 직렬화되는가.

개방 Agent에서 모델 API가 반환하는 것은 JSON이다. 고른 도구 이름과 parameters에 맞는 arguments. Runtime이 검증한 뒤 실행한다. MCP는 같은 형태를 inputSchema / structuredContent에 둔다. 세부는

AI Agent에 JSON Schema가 필요한 이유: Tool Calling부터 Structured Output까지。

{
  "type": "function",
  "function": {
    "name": "mark_invoice_paid",
    "description": "Mark one invoice as paid.",
    "parameters": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string" },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  }
}

Siri AI 쪽에는 이 JSON이 없다. 등가물은 @AppIntent(schema:)에 @Parameter다. 모델은 여전히 「동작을 고르고 슬롯을 채운다」. 직렬화 형식만 시스템 내부의 타입화 호출로 바뀌었다.

그래서 App Intent를 「Siri가 JSON을 내게」 한 겹 더 감싸지 말 것. 프롬프트를 더 넣어도 시스템이 더 안정되지 않고, 디버그만 타입 검사를 잃는다. 원하는 안정은 perform() 이후에 온다. 도메인 서비스가 받은 객체를 위 arguments로 손실 없이 인코딩할 수 있는가.

선택도 구체적이다. 사용자가 이미 Apple 기기에 있고 동작을 시스템 카탈로그로 묶을 수 있으면 Siri AI. Android, Web, 사내 Slack 봇이 재사용하면 Function Calling에 MCP. 「우리도 Agent가 있다」고 두 체인을 만능 그림 한 장으로 그리지 말 것.

HTTP API에 닿을 때 JSON 모양

Intent가 네트워크를 직접 쳐야 하나? 짧은 동작은 perform()에서 끝낼 수 있다. 인증, 페이지네이션, 멱등이 끼면 perform()은 「인수 검증 + 도메인 서비스 호출」만 하고, 도메인 서비스가 JSON 요청을 보낸다.

아래는 「송장을 지급 완료로 표시」가 백엔드에 닿을 때의 페이로드다. 필드명은 내부 청구 시스템의 전형이고, 숫자는 예이지 어떤 은행의 실제 인터페이스가 아니다.

{
  "action": "invoices.markPaid",
  "source": "siri-ai",
  "idempotency_key": "inv_1842:paid:2026-09-09",
  "arguments": {
    "invoice_id": "inv_1842",
    "paid_at": "2026-09-09T02:14:00Z",
    "currency": "USD",
    "amount_cents": 12800
  }
}

이 객체가 있으면 세 질문에 답할 수 있다. 누가 트리거했는지, 재현할 수 있는지, 금액이 맞는지. idempotency_key가 없으면 Siri가 한 번 재시도할 때 지급 완료가 두 번 찍힌다. amount_cents가 문자열이 되면 뒤 장부가 모두 떠다닌다.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["action", "source", "idempotency_key", "arguments"],
  "properties": {
    "action": { "const": "invoices.markPaid" },
    "source": { "type": "string", "enum": ["siri-ai", "shortcuts", "app"] },
    "idempotency_key": { "type": "string", "minLength": 8 },
    "arguments": {
      "type": "object",
      "required": ["invoice_id", "paid_at"],
      "properties": {
        "invoice_id": { "type": "string", "minLength": 1 },
        "paid_at": { "type": "string", "format": "date-time" },
        "amount_cents": { "type": "integer", "minimum": 0 },
        "currency": { "type": "string", "enum": ["USD", "CNY", "EUR"] }
      },
      "additionalProperties": false
    }
  },
  "additionalProperties": false
}

시스템 Agent는 REST 경로를 알 필요가 없다. Intent의 성공 또는 실패만 있으면 된다. 경로는 당신이 알아야 한다. 감사와 재시도가 API 층에 있기 때문이다. Intent 인수를 「JSON 객체로 쓸 수 있는」 필드 집합으로 설계하면, 뒤에 개방 Agent를 붙일 때 어댑터 한 층을 덜 만든다.

JSONNote로 Action 인수 검증

느린 부분은 Swift 매크로가 거의 아니다. 느린 것은 두 호출의 JSON이 안 맞는 일이다. Siri 재시도에 필드가 하나 늘고, Shortcuts가 enum을 하나 빼고, 내부 Agent가 amount_cents를 128.00으로 쓴다. JSONNote는 브라우저 로컬에서 처리한다:

1. 1
   먼저 한 호출을 포맷한다

   App Intents Console이나 백엔드 로그의 객체를 JSON 포맷에 붙여 들여쓰기와 구문 노이즈를 걷어낸다.

2. 2
   Schema로 필수 필드를 고정한다

   위 초안을 JSON Schema 페이지에 붙여 action, idempotency_key, invoice_id가 남아 있는지 확인한다.

3. 3
   Siri와 개방 Agent 두 호출을 비교한다

   JSON Diff로 source가 siri-ai에서 mcp로 바뀌었는지, arguments가 떠다녔는지 본다.

4. 4
   동료가 필요할 때만 공유한다

   Hash 공유로 샘플(비밀은 넣지 말 것)을 URL fragment에 넣는다. 서버는 이 데이터를 받지 못한다.

자주 묻는 질문

Siri AI는 AI Agent인가요?

시스템 Agent이지 개방 Agent가 아닙니다. 크로스 App으로 동작을 고르고, 인수를 채우고, 흐름을 이을 수 있습니다. 다만 도구 카탈로그는 App Intents와 App Schemas가 고정하므로 모델이 API를 발명하지 못합니다.

App Actions와 App Intents는 같은 것인가요?

하나의 제품명이 아닙니다. App Actions는 사용자·시스템 쪽 말입니다: Siri가 App에 무엇을 할 수 있는가. 개발자가 내는 것은 App Intents이고, App Schema에 맞춰야 Siri가 그 종류를 알아봅니다.

Siri가 내 REST API를 직접 치나요?

아닙니다. Siri는 선언한 Intent만 호출합니다. perform() 안에서 직접 HTTP를 칩니다. 시스템 Agent가 원하는 것은 성공/실패 의미이고, 청구·인증·재시도는 API 층에 있습니다.

Apple은 Swift 타입을 쓰는데, 왜 JSON Schema가 필요한가요?

Swift 타입은 컴파일 시점을 담당합니다. 동작이 프로세스를 떠나면——백엔드, 로그, 테스트 재생, 외부 Agent 재사용——형태는 언어 중립 JSON이 되어야 합니다. Schema가 검증하는 것은 이 홉이지 Siri 홉이 아닙니다.

Siri AI를 써야 하나요, Function Calling Agent를 직접 짜야 하나요?

사용자가 이미 iPhone에 있고 동작을 시스템 카탈로그로 묶을 수 있으면 Siri AI. 클라우드·플랫폼을 넘거나 모델을 직접 고르려면 Function Calling에 MCP. 같은 도메인 함수가 두 체인을 같이 받을 수 있고, 바꾸는 것은 어댑터뿐입니다.

정리

Siri AI는 Agent가 된다. 다만 운영체제 안의 Agent이지, 도구를 마음대로 거는 개방 Runtime이 아니다.

Apple Intelligence가 모델을 주고, App Actions(App Intents + App Schemas)가 오케스트레이션 가능한 동작을 주며, JSON은 그 동작이 기기를 떠난 뒤의 계약이다.

먼저 Intent 인수를 JSON 객체로 쓸 수 있는 필드로 설계하고, Siri 체인과 Function Calling 체인에 같은 Schema를 건다. 모델과 시스템 입구는 계속 바뀐다. 검증 층이 데모에서 운영으로 가는 해자다. 이 JSON은 JSONNote에서 로컬로 포맷, 검증, 비교할 수 있고 올릴 필요는 없다.

← 블로그로