새 Siri는 어떻게 앱을 '도구'로 부리나 — Apple 시스템 에이전트 루프
WWDC 2026에서 Apple이 공식 발표한 '시스템 레벨 에이전트'(새 Siri / System Orchestrator)는 실재한다 — App Intents를 도구로 앱을 가로질러 행동한다. 확실한 건 거기까지고, 그 내부 루프가 정확히 어떻게 도는지는 추측인 곳만 표시한다.
지난 글에서 Apple Intelligence 전체 구조를 한 장으로 잡았습니다. 거기서 한 줄로만 지나간 게 있습니다 — “System Orchestrator가 앱을 가로질러 행동한다.” 이번 글은 그 시스템 레벨 에이전트 루프 하나만 확대합니다. 새 Siri가 “저녁 예약하고, 교통 확인하고, 도착시간 문자해” 같은 명령을 받아 여러 앱을 도구처럼 부려서 실제로 해내는, 그 안쪽 루프입니다.
시스템 레벨 에이전트는 진짜 있나? — 있다
가장 궁금한 것부터 답하면, 이건 우리가 만들어낸 개념이 아니라 WWDC 2026에서 Apple이 공식 발표·시연한 것입니다. Apple은 무대에서 이걸 “새 Siri”라고 부르며, “저녁 예약 → 교통 확인 → 도착시간 문자”를 한 번의 명령으로 이어서 해내는 모습을 보여 줬습니다. 목표를 받아 App Intents를 도구로 골라 부르고, 여러 앱을 가로질러 다단계로 행동하는 에이전트가 거기 있는 건 분명합니다 — 키노트와 개발자 세션(App Intents·orchestrator)에 on-record로 박혀 있습니다.
단, 확실한 건 “있다 = 무엇을 한다”까지입니다. 그 에이전트가 안에서 정확히 어떻게 도는지(루프 코드·도는 프로세스·스텝별 모델)는 Apple이 공개하지 않았습니다. 그래서 이 글은 “시스템 레벨 에이전트가 있다”는 사실 위에서, 그 내부 루프를 공식 단서로 최대한 그리고, 추측인 곳만 표시합니다.
용어 주의 — 발표자는 ‘Siri’라 했지만, Siri ≠ 오케스트레이터. Apple이 무대에서 “새 Siri가 ~한다”고 말한 건 편의상 둘을 묶어 부른 것입니다. 실제로 맥락을 모아 도구를 부르는 루프(= 에이전트)를 도는 건 그 아래의 System Orchestrator(조정 엔진)이고, Siri는 그 엔진에 말 거는 얼굴(표면)일 뿐입니다. 게다가 이 엔진은 Siri 전용이 아니라 Writing Tools·Spotlight·Visual Intelligence도 함께 씁니다. 그래서 이 글에서 “오케스트레이터”는 엔진을, “Siri”는 그 표면을 가리킵니다.
추측은 이 세 곳뿐
| 지점 | 상태 | 왜 추측인가 |
|---|---|---|
루프의 정확한 모양 (.onToolCall·authenticationPolicy·historyTransform 같은 보안 훅 포함) | 역추론 | 이 모양은 개발자용 Foundation Models 프레임워크(WWDC26 347)에 공개된 것. “시스템 오케스트레이터도 똑같은 루프를 돈다”는 직접 진술은 없어 빌려 온 추론 |
| 오케스트레이터의 내부 코드 / 도는 프로세스(데몬) | 미공개 · 블랙박스 | 공개 API가 아님. 개발자에게 열린 건 “App Intents로 도구를 등록하는 쪽”뿐, 엔진을 들여다보는 쪽이 아님 |
| 루프 스텝마다 어떤 모델이 도는지 (라우팅용 온디바이스 vs 에이전트 추론용 Cloud Pro) | 추론 | ”Cloud Pro가 에이전트형 도구 사용 담당”까지만 공식. 스텝별 모델 배정은 미공개 |
나머지(재료가 뭔지, 도구가 App Intents라는 것, 크로스앱 체이닝, 그리고 그 루프를 누가 돌리는지)는 공식 문서에 그대로 나옵니다. 아래는 그걸 설명하면서 위 세 지점에만 “추측” 표시를 답니다.
위에서 아래로 읽습니다. 사용자 요청이 Siri 같은 표면으로 들어오면, 오케스트레이터가 세 가지 맥락(Semantic Index·화면 인식·웹)을 모아 App Intents를 도구로 부르는 루프를 돌려 답하거나 행동을 끝냅니다. 점선 박스(가운데 루프)가 추측 지점입니다.
1. 루프에 들어가는 재료
오케스트레이터가 조정하는 네 가지 재료부터 봅니다.
- 개인 맥락 — Semantic Index. 기기 안의 파일·사진·메일·메시지·앱 콘텐츠를 의미 단위로 색인한 온디바이스 DB. 앱이 entity 스키마로 자기 콘텐츠를 여기에 기여합니다.
- 화면 인식 — View Annotations API. 화면의 뷰를 엔티티로 매핑해, “이거”라고 말하면 지금 보는 걸 가리킬 수 있게.
- 세계 지식 — 웹. 최신·외부 정보 보강.
- App Actions — App Intents. 이게 루프의 “도구” — 다음 절의 주인공입니다.
추측: 이 넷을 매 턴 어떤 순서로 조립해 프롬프트에 넣는지의 디테일은 공개돼 있지 않습니다.
2. 도구 = App Intents
루프가 부르는 도구는 앱이 만든 임의의 함수가 아니라, App Intents로 OS에 등록된 타입 지정 동작입니다.
- 앱이 intent 스키마로 “나는 이런 걸 할 수 있다”(예약하기, 사진 삭제, 메시지 보내기…)를 선언하면, 그게 오케스트레이터의 App toolbox에 올라갑니다.
- 그래서 앱 경계를 넘는 작업이 됩니다. 뒤에 보겠지만 개발자 앱 안의 세션은 자기 앱 도구만 보는 반면, 시스템 루프는 기기 전체의 App Intents를 도구 풀로 쥡니다. 도식의
OpenTable → Maps → Messages체이닝이 그 그림입니다. - (App Intents는 로컬·온디바이스 도구 호출입니다. 외부 시스템까지 가려면 MCP 같은 별도 통로가 거론되는데, 이건 보조 출처 기반이라 강하게 단정하지 않습니다.)
3. 그 루프, 누가 돌리나 — 에이전트는 프레임워크 안에 있다
여기서 우리가 계속 헷갈렸던 질문 하나를 못 박고 갑니다. Foundation Models framework는 “LLM에 한 번 묻고 답 받는” 일회성 API가 아닙니다. 도구(Tool)와 지시문을 쥐여 준 세션(LanguageModelSession / Profile)에 respond(to:)를 부르면, 프레임워크가 직접 에이전트 루프를 돌립니다 — 모델이 tool call을 내면 도구를 실행하고, 결과를 되먹이고, 끝날 때까지 반복합니다. 개발자가 while 루프를 손으로 짜지 않습니다.
그 한 바퀴는 이렇게 생겼습니다(세션 347 기준):
맥락 조립(요청 + 추가 컨텍스트)
→ 모델 추론: 다음에 부를 도구 결정 (tool call)
→ [보안 게이트: 인증 / 사용자 확인]
→ 도구 실행: Tool.call() / App Intent의 perform()
→ 결과를 맥락에 반영
→ (더 부를 게 있으면) 반복, 없으면 최종 답역할이 셋으로 나뉩니다:
- 프레임워크 = 루프(엔진). 세션이 반복을 돌립니다. 게다가
.onToolCall(실행 전 가로채 사용자 확인)·authenticationPolicy(고위험 인텐트 인증)·historyTransform(친구 피드·웹 같은 신뢰 못 할 맥락을<<UNTRUSTED>>로 구분·redaction)으로 간접 프롬프트 인젝션까지 막습니다. - 개발자 = 도구 + 지시문. 무엇을 할 수 있고, 어떤 규칙으로 움직일지.
- 모델 = 추론. 어떤 도구를 부를지, 결과를 보고 다음에 뭘 할지.
이 셋을 합친 게 에이전트입니다. 그러니 “프레임워크가 에이전트(루프)를 포함하느냐”의 답은 그렇다 — 루프는 프레임워크 것이고, 개발자는 거기에 도구·지시문만 끼웁니다. 비유하면 프레임워크가 엔진+변속기라면, OpenClaw 같은 자율 에이전트는 그 위에 플래닝·권한·장기 실행까지 얹은 완성차입니다. 핵심 구동 루프는 같은 부류고요.
4. 그럼 시스템 오케스트레이터는? — 여기가 추측
3절까지는 개발자용 프레임워크의 이야기로, 문서로 확인되는 사실입니다. 추측이 시작되는 건 이 루프를 시스템 오케스트레이터(새 Siri의 엔진) 에 그대로 옮겨 붙일 때입니다. 추측 셋은 이렇게 갈립니다.
- 추측 ① — 같은 루프 모양. Apple은 “오케스트레이터도 정확히 이 루프·이 훅으로 돈다”고 명시한 적이 없습니다. 다만 같은 회사가 같은 시기에 같은 에이전트 보안 모델을 설계했고, App Intents가 그 도구로 들어가니 — 시스템 루프도 같은 모양일 것이라 보는 합리적 역추론입니다. 모양은 빌려 온 것이지 확인된 코드가 아닙니다.
- 추측 ② — 내부 코드·도는 프로세스(블랙박스). 오케스트레이터의 실제 루프 코드와 그게 도는 시스템 프로세스(데몬)는 공개 API가 아닙니다. “앱 샌드박스 밖, OS 영역에서 돈다”까지는 구조상 분명하지만(앱 안이면 크로스앱이 불가능하니까) 그 안의 구현은 블랙박스로 남습니다.
- 추측 ③ — 스텝별 모델. 루프 스텝마다 어떤 모델이 도는지 — “Cloud Pro가 에이전트를 맡는다”까지만 공식입니다.
즉 “프레임워크가 에이전트 루프를 돌린다”는 확인된 사실이고, “시스템 오케스트레이터도 같은 식으로 돈다”는 그 사실에서 끌어온 추측입니다. 둘을 섞지 않는 게 이 글의 핵심입니다.
정리
- 시스템 루프 = OS의 오케스트레이터가, Semantic Index·화면·웹을 맥락으로 깔고, 기기 전체의 App Intents를 도구로 부르는 에이전트 루프. 그리고 그 에이전트 루프는 프레임워크가 직접 돌린다 — 개발자는 도구·지시문만 끼운다.
- 추측은 셋뿐 — 루프의 정확한 모양(역추론), 내부 코드·도는 프로세스(블랙박스), 스텝별 모델 배정(추론). 나머지는 Apple 문서 그대로입니다.
출처
확실(공식) — Apple 1차 자료:
- Secure your app: mitigate risks to agentic features — WWDC26 세션 347 — 프레임워크가 루프를 돌린다는 점·tool call·
.onToolCall/historyTransform·보안 위협 모델의 가장 구체적 출처 - Explore advanced App Intents features for Siri and Apple Intelligence — WWDC26 세션 343
- Build intelligent Siri experiences with App Schemas — WWDC26 세션 240
- WWDC26 Apple Intelligence 가이드 · Apple Intelligence for Developers
배경·해설 — 2차 자료(능력/예시 확인용, 내부 구현 근거 아님):
- Everything AI Apple announced at WWDC 2026 — The Neuron — 오케스트레이터 4재료 요약
- WWDC26: Siri becomes the OS gateway to invoke apps — note.com/shugo — OS 게이트웨이 프레이밍
- WWDC 2026: Apple Just Turned Every App Into an AI Agent — FourWeekMBA — 크로스앱 체이닝 예시
- Apple’s WWDC AI Strategy: Siri, App Intents, and MCP — MindStudio — App Intents vs MCP 구분
정직성 노트: 347 세션은 개발자용 프레임워크가 에이전트 루프를 돌린다는 걸 보여주는 문서입니다. 이 글이 그 루프를 시스템 오케스트레이터에 옮겨 적용한 부분이 곧 위에서 표시한 “추측 ①”입니다.