Writing Tools API: 앱이 Apple Intelligence의 글쓰기 레이어와 연결되는 방법

Apple Intelligence의 글쓰기 레이어인 Writing Tools는 Apple Intelligence가 활성화된 모든 iOS 18+ 기기에 탑재됩니다. 사용자가 텍스트를 선택하고 Writing Tools 메뉴를 누르면 교정, 다시쓰기(친근하게, 전문적으로, 간결하게), 요약, 목록 및 표 생성, 그리고 (iOS 18.2부터는) 생성형 작성 기능을 사용할 수 있습니다¹. 이 기능은 특정 앱이 아닌 시스템 레이어에 존재하며, 사용자는 모든 텍스트 입력에서 이 기능이 작동할 것이라고 기대합니다.

UITextView, NSTextView, 또는 WKWebView를 사용하는 앱은 텍스트 뷰가 TextKit 2에서 실행되기만 하면 코드를 작성하지 않고도 통합 기능을 얻습니다². 커스텀 텍스트 엔진을 가진 앱은 자체 텍스트 저장소와 렌더링을 Writing Tools 경험에 연결하기 위해 UIWritingToolsCoordinator API가 필요합니다. 이 글에서는 Apple 문서에 따라 API 표면을 살펴보고, 세 가지 채택 단계의 이름을 정하며, 언제 옵트아웃해야 하는지(모든 텍스트 입력이 생성형 다시쓰기를 받아들여서는 안 되기 때문에)를 다룹니다.

TL;DR

• TextKit 2를 사용하는 표준 텍스트 뷰(UITextView, NSTextView, WKWebView)는 무료로 Writing Tools를 받으며, 애니메이션을 동반한 완전한 인라인 다시쓰기 경험을 제공합니다².
• 커스텀 텍스트 뷰는 UITextInteraction을 채택하여 추가 코드 없이 콜아웃/컨텍스트 메뉴 통합을 받을 수 있습니다. 완전한 인라인 통합은 UIWritingToolsCoordinator API가 필요합니다³.
• UIWritingToolsBehavior는 경험 단계를 제어하는 단일 enum 속성입니다: .complete, .limited, 또는 .none⁴. .default 값은 시스템이 런타임에 이 세 가지 중 하나로 해결하는 요청이며, 네 번째 단계가 아닙니다. 민감한 텍스트(비밀번호, 소스 코드 편집기, 사용자가 다시 쓰이지 않기를 원하는 채팅 필드)에는 .none으로 설정하세요.
• allowedWritingToolsResultOptions를 사용하면 앱이 받아들이는 출력 형식(일반 텍스트, 서식 있는 텍스트, 목록, 표, 또는 iOS 26의 .presentationIntent)을 선언할 수 있어 Writing Tools가 앱이 렌더링할 수 없는 콘텐츠를 반환하지 않습니다⁵.
• 에이전트 워크플로 연결: Writing Tools는 App Intents 및 Foundation Models와 같은 Apple Intelligence 표면이지만, 액션 레이어가 아닌 텍스트 입력 레이어에서 작동합니다.

Writing Tools가 실제로 하는 일

iOS 18+의 Writing Tools 메뉴는 선택된 텍스트에 대한 작업 세트를 노출합니다. Apple의 개발자 문서와 WWDC 2024 소개에 따른 현재 공개 세트는 다음과 같습니다⁶:

교정(Proofread). 문법, 철자, 구두점, 단어 선택을 수정합니다. 사용자가 수락, 거부 또는 단계별로 검토할 수 있는 diff를 반환합니다.

다시쓰기(Rewrite). 세 가지 사전 설정 톤(친근하게, 전문적으로, 간결하게)과 “변경 사항 설명” 사용자 지정 프롬프트가 있습니다. 모델은 선택한 텍스트를 선택된 톤으로 다시 작성합니다.

요약(Summarize). 긴 텍스트를 짧게 만듭니다. 변형으로는 “요약”, “핵심 포인트”, “목록”, “표”가 있습니다. 사용자가 형식을 선택합니다.

작성(Compose). 프롬프트에서 생성형 글쓰기(iOS 18.2+). 사용자가 원하는 것을 설명하면 모델이 기존 텍스트를 다시 쓰는 대신 새 텍스트를 생성합니다.

Writing Tools를 실행하는 모델은 지원되는 하드웨어의 Apple 온디바이스 파운데이션 모델이며, 더 큰 요청을 위한 프라이빗 클라우드 폴백이 있습니다¹. 사용자의 텍스트는 절대로 제3자에게 전달되지 않습니다. 프라이버시 스토리는 가치 제안의 일부입니다.

세 가지 채택 단계

앱은 필요한 Writing Tools 통합 정도에 따라 세 가지 카테고리 중 하나에 속합니다.

단계 1: 표준 텍스트 뷰(코드 0줄)

UITextView, NSTextView, 또는 WKWebView를 텍스트 입력으로 사용하는 앱은 텍스트 뷰가 TextKit 2를 사용한다면 코드를 작성하지 않고도 Writing Tools를 받습니다². 시스템이 메뉴, 인라인 다시쓰기 UI, 애니메이션, 교정 인라인 하이라이트를 처리합니다. 앱의 역할은 표준 텍스트 뷰를 사용하는 것입니다.

let textView = UITextView()
textView.text = "Original content."
textView.isEditable = true
// Writing Tools just works.

TextKit 2 요구사항이 중요한 이유는 TextKit 1이 인라인 다시쓰기 애니메이션을 지원하지 않는 다른 레이아웃 아키텍처와 함께 제공되기 때문입니다. iOS 18+를 타겟으로 하는 새 앱은 기본적으로 TextKit 2를 사용해야 하며, 레거시 앱은 마이그레이션 단계가 필요할 수 있습니다. UITextView는 Interface Builder 또는 최신 이니셜라이저를 통해 초기화될 때 iOS 16+에서 기본적으로 TextKit 2를 사용합니다.

단계 2: UITextInteraction을 사용한 커스텀 텍스트 뷰(콜아웃만)

커스텀 텍스트 뷰가 있는 앱은 UITextInteraction을 채택하여 추가 코드 없이 콜아웃 바와 컨텍스트 메뉴에서 Writing Tools를 받을 수 있습니다⁷. 사용자는 Writing Tools를 호출하고, 교정/다시쓰기/요약을 위한 패널 스타일 인터페이스를 보고, 결과를 수락하거나 거부할 수 있습니다. 결과는 표준 붙여넣기/교체 흐름을 통해 앱에 전달됩니다.

통합은 부분적입니다: 앱은 인라인 애니메이션이나 교정 인라인 하이라이트를 받지 않습니다. 그것들은 전체 코디네이터가 필요합니다. 커스텀 텍스트 뷰가 있는 대부분의 앱에는 UITextInteraction 채택으로 충분합니다.

단계 3: UIWritingToolsCoordinator(완전한 인라인 경험)

커스텀 텍스트 저장소로 완전한 Writing Tools 경험을 원하는 앱은 UIWritingToolsCoordinator(또는 macOS의 NSWritingToolsCoordinator)를 채택합니다³. 코디네이터는 Writing Tools와 앱 간의 양방향 대화를 관리합니다:

• 앱은 텍스트 컨텍스트(현재 선택과 선택적 주변 단락을 나타내는 NSAttributedString)를 코디네이터에 제공합니다.
• 코디네이터는 패널 UI와 인라인 애니메이션을 관리합니다.
• 코디네이터는 델리게이트를 통해 콜백하여 앱의 텍스트 저장소에서 텍스트 변경 사항을 삽입, 교체 또는 애니메이션화합니다.

iOS 26 SDK 헤더에 대해 검증된 UIWritingToolsCoordinator.Delegate의 주요 델리게이트 메서드³:

• writingToolsCoordinator(_:requestsContextsForScope:completion:). 인테이크 메서드. Writing Tools는 앱에 주어진 범위 내의 관련 텍스트 컨텍스트(각각 NSAttributedString + 선택 범위)를 요청합니다. 앱은 텍스트 저장소에서 컨텍스트를 빌드하여 반환합니다.
• writingToolsCoordinator(_:replaceRange:inContext:proposedText:reason:animationParameters:completion:). 텍스트 변경의 핵심 메서드. Writing Tools는 컨텍스트 내의 범위에 대해 새 텍스트를 제안하고, 앱은 변경 사항을 저장소에 적용한 후 확인합니다.
• writingToolsCoordinator(_:finishTextAnimation:forRange:inContext:completion:). 범위에 대한 텍스트 애니메이션(원본과 다시 쓰인 텍스트 사이의 모핑)이 완료될 때 호출됩니다. 세션 종료 신호가 아닙니다.
• writingToolsCoordinator(_:willChangeToState:completion:). 세션 라이프사이클 신호. 코디네이터는 상태(idle, interactive, noninteractive 등) 사이를 전환하고 각 전환 전에 델리게이트에 알립니다. 여기에서 앱이 “세션 시작” 및 “세션 종료”에 응답합니다.

코디네이터 API는 직렬화된 텍스트 엔진(TextKit 스타일), 문서 형태의 편집기, 부분 통합을 원하는 코드 편집기를 위해 설계되었습니다. WWDC 2025의 Apple 세션 “Dive deeper into Writing Tools”⁸는 다중 단락, 다중 스타일 사례를 다룹니다. UIWritingToolsCoordinator는 iOS 18.2에서 공개 API로 처음 출시되었으며, iOS 26은 이를 도입하기보다는 심화시킨다는 점에 유의하세요.

Behavior 속성: UIWritingToolsBehavior

가장 중요한 단일 옵트인/옵트아웃 컨트롤은 UITextView, UITextField, 그리고 UITextInputTraits를 준수하는 모든 뷰의 writingToolsBehavior 속성입니다⁴:

textView.writingToolsBehavior = .complete   // full inline experience
textView.writingToolsBehavior = .limited    // panel-only (no inline rewrite)
textView.writingToolsBehavior = .none       // disabled entirely
textView.writingToolsBehavior = .default    // request system default

세 가지 값은 실제 경험 단계입니다. .default는 시스템이 텍스트 입력의 특성에 따라 다른 세 가지 중 하나로 해결하는 요청입니다:

• .complete. 인라인 다시쓰기 애니메이션, 인라인 교정 하이라이트, 패널을 포함한 완전한 Writing Tools 경험. 장문 텍스트 편집기(Mail 작성기, 메모, 문서 편집기)에 가장 적합합니다.
• .limited. 패널 전용 경험. 사용자는 메뉴에서 Writing Tools를 받지만, 다시쓰기는 인라인이 아닌 패널에서 발생합니다. 인라인 애니메이션이 부적절하다고 느껴지는 짧은 텍스트 필드에 가장 적합합니다.
• .none. 이 텍스트 입력에 대해 Writing Tools가 비활성화됩니다. 민감한 콘텐츠에 사용하세요.
• .default. 단계가 아닌 요청. 헤더는 해결된 값이 항상 .none, .limited, 또는 .complete 중 하나라고 문서화합니다. 읽기 전용 behavior 속성은 절대로 .default를 반환하지 않습니다. 대부분의 앱은 재정의할 특정 이유가 없는 한 속성을 .default로 두어야 합니다.

언제 옵트아웃해야 하는가

.none이 올바른 선택인 텍스트 입력의 세 가지 카테고리:

비밀번호 및 민감한 자격 증명. 비밀번호 필드는 절대로 “친근한 톤으로 다시쓰기”를 옵션으로 제공해서는 안 됩니다. 사용자는 변환되어서는 안 되는 리터럴 텍스트를 입력하고 있습니다. Apple의 isSecureTextEntry = true인 UITextField는 이미 기본적으로 Writing Tools를 비활성화합니다. 명시적인 .none은 이중 안전장치입니다.

소스 코드 편집기. SwiftUI 코드 편집기 또는 기술 콘텐츠를 위한 Markdown 편집기는 선택된 코드를 “전문적인” 톤으로 다시 쓰도록 요청받음으로써 개선되지 않습니다. Writing Tools의 다시쓰기 경로는 자연어에 맞춰져 있으며 구문 구조에는 맞지 않습니다. 자연어가 아닌 콘텐츠를 가진 텍스트 뷰에는 .none을 설정하세요.

다시쓰기가 의도를 변경하는 채팅 필드. 사용자의 정확한 단어가 중요한(톤, 목소리, 책임을 위해) 메시징 앱이나 댓글 필드는 교정은 유지하면서 다시쓰기는 생략하고 싶을 수 있습니다. Writing Tools의 현재 API는 액션별 게이팅을 허용하지 않습니다. .none 값은 전체 경험을 비활성화합니다. 실용적인 선택은 다시쓰기가 가끔 적절하지만 인라인 기본값이 되어서는 안 되는 필드에 대해 .limited(패널 전용, 사용자가 의도적으로 호출해야 함)입니다.

allowedWritingToolsResultOptions는 앱이 렌더링할 수 있는 것을 선언합니다

더 미묘한 컨트롤은 UITextInputTraits.allowedWritingToolsResultOptions(또한 UITextView.allowedWritingToolsResultOptions로 노출)에 있습니다⁵. 이 속성은 앱의 텍스트 뷰가 렌더링할 수 있는 콘텐츠 형식을 선언하는 UIWritingToolsResultOptions 옵션 세트입니다:

• .plainText. 텍스트 뷰가 일반 텍스트(서식 속성 없음)를 지원합니다.
• .richText. 서식 있는 텍스트(굵게, 기울임꼴 등)를 지원합니다.
• .list. 목록 렌더링(글머리 기호, 번호 매김)을 지원합니다.
• .table. 표 렌더링을 지원합니다.
• .presentationIntent (iOS 26+). Foundation 프레임워크의 PresentationIntent 타입을 사용하여 풍부한 의미론적 의도 마크업(제목, 인용 블록, 코드 블록)을 지원하며, 이는 일반 서식 있는 텍스트보다 더 풍부한 표면입니다.

설정되면 Writing Tools는 출력을 앱이 받아들이는 형식으로 제한합니다. .plainText만 선언하는 일반 텍스트 편집기는 “이것을 표로 만들기” 제안을 받지 않습니다. .richText와 .list를 선언하지만 .table은 선언하지 않는 서식 있는 텍스트 편집기는 목록 출력은 받지만 표 출력은 받지 않습니다.

기본값은 .default이며, 시스템이 텍스트 뷰의 특성에 따라 선택하도록 합니다. 자동 감지가 잘못된 형식을 생성할 때(서식 있는 텍스트를 렌더링할 수 있지만 앱의 데이터 모델이 일반 텍스트만 저장하는 텍스트 뷰) 속성을 명시적으로 설정하세요.

출력이 도착하는 곳

단계 1 앱(표준 텍스트 뷰)의 경우, 출력은 표준 텍스트 뷰 메커니즘을 통해 인라인으로 선택을 대체합니다. 앱 코드는 관여하지 않습니다.

단계 2 앱(UITextInteraction이 있는 커스텀 뷰)의 경우, 출력은 표준 붙여넣기 흐름을 통해 도착합니다. 텍스트 뷰의 UITextInput 프로토콜 구현이 변경 사항을 처리합니다. UITextInput을 올바르게 구현한 앱은 UITextInteraction이 추가되면 “무료로” 통합을 받습니다.

단계 3 앱(완전한 코디네이터)의 경우, 출력은 델리게이트의 replaceRange: 메서드를 통해 들어옵니다. 앱은 변경 사항을 텍스트 저장소에 적용하고, 완료 핸들러에서 새 텍스트 경계를 반환하며, 코디네이터는 시각적 전환을 처리합니다. 앱은 텍스트 저장소의 단일 진실 공급원으로 남아 있습니다.

WWDC 2025의 심화 세션이 추가한 것

WWDC 2025의 “Dive deeper into Writing Tools” 세션⁸은 iOS 18 API를 명명할 가치가 있는 세 가지 축을 따라 확장했습니다:

다중 단락 컨텍스트. 앱은 이제 코디네이터에 더 많은 주변 컨텍스트를 제공할 수 있어, Writing Tools가 주변 단락에 의존하는 선택(예를 들어, 그 의미가 위 단락에 의존하는 문장)에서 작동할 수 있도록 합니다.

커스텀 다시쓰기 프롬프트. iOS 18.2 베타였던 “변경 사항 설명” 경로는 완전히 공개되었으며, 모델에 전달하기 전에 사용자의 프롬프트를 검사하거나 변환하려는 앱을 위한 델리게이트 훅을 제공합니다.

혼합 콘텐츠의 더 나은 처리. 여러 스타일에 걸쳐 있거나 임베디드 이미지를 포함하는 텍스트 선택은 이제 임베디드 콘텐츠가 불투명한 범위로 보존된 상태로 코디네이터를 통해 흐릅니다. 코디네이터는 인라인 이미지를 다시 쓰려고 시도하지 않습니다. 그것을 보존하고 주변 텍스트를 다시 씁니다.

델타는 교체가 아닌 iOS 18 모델의 확장입니다. iOS 18 Writing Tools API를 채택한 앱은 계속 작동합니다. iOS 26은 더 깊은 통합이 필요한 앱을 위해 더 깊은 통합을 잠금 해제합니다.

에이전트 워크플로 연결

Writing Tools는 제3자 앱이 통합할 수 있는 세 가지 Apple Intelligence 표면 중 하나입니다:

Writing Tools. 텍스트 입력 레이어. 사용자가 텍스트를 선택하고 시스템에 변환을 요청하면 결과를 인라인으로 받습니다. 앱은 잘 형성된 텍스트 뷰를 노출하고 (선택적으로) 코디네이터를 구현하여 참여합니다. 사용자가 호출하고 앱이 결과를 받습니다.

App Intents. 액션 레이어. 사용자(또는 에이전트)가 Apple Intelligence에 액션을 수행하도록 요청하면 시스템이 요청을 앱에 등록된 인텐트로 라우팅합니다. 앱은 AppIntent 타입, 매개변수 스키마, 결과 타입을 선언하여 참여합니다. App Intents Are Apple’s New API to Your App에서 다룹니다.

Foundation Models. 런타임 LLM 레이어. 앱은 인앱 생성을 위해 Foundation Models 프레임워크를 통해 온디바이스 LLM를 직접 호출합니다. Foundation Models on-device LLM에서 다룹니다.

세 가지 표면이 결합됩니다. 노트 앱은 Writing Tools(사용자의 선택 기반 다시쓰기), App Intents(“어제 내 노트 요약하기”), Foundation Models(자동 태깅과 같은 인앱 생성형 기능)를 사용할 수 있습니다. 각 레이어는 별개의 사용자 정신 모델을 가진 별개의 통합입니다.

App Intents vs MCP Tools 글은 App Intents(Apple Intelligence)를 통해 액션을 노출할지 MCP 서버(일반 에이전트)를 통해 노출할지 다룹니다. Writing Tools는 그 질문 밖에 있습니다. 그것은 클러스터의 범위에서 제3자 에이전트 등가물이 없는 시스템 수준 표면입니다.

이 패턴이 iOS 26+ 앱에 의미하는 것

세 가지 핵심 사항.

1. 표준 텍스트 뷰와 TextKit 2를 기본값으로 하세요. 대부분의 앱은 코디네이터 API가 필요하지 않습니다. 앱의 텍스트 입력이 UITextView 또는 WKWebView라면, Writing Tools는 코드 없이 작동합니다. 작업은 앱이 여전히 TextKit 1을 실행하는 경우 TextKit 2 마이그레이션에 있습니다.

2. 민감한 입력에 대해 의도적으로 writingToolsBehavior = .none을 설정하세요. 비밀번호, 코드 편집기, 정확한 텍스트 필드. 기본값은 옳은 일을 하려고 시도하지만, 명시적인 설정은 팀이 명확히 표현할 수 있는 방어 가능한 제품 결정입니다.

3. 앱의 텍스트 엔진이 진정으로 커스텀일 때만 UIWritingToolsCoordinator에 손을 뻗으세요. Markdown 편집기, 코드 편집기, 커스텀 렌더링이 있는 문서 앱, 터미널 스타일 텍스트 뷰. 코디네이터는 실제 엔지니어링 투자입니다. 단계 2(UITextInteraction)는 대부분의 커스텀 뷰에 충분합니다.

전체 Apple Ecosystem 클러스터: 타입이 지정된 App Intents; MCP 서버; 라우팅 질문; Foundation Models; 런타임 vs 도구화 LLM 구분; 세 가지 표면; 단일 진실 공급원 패턴; Two MCP Servers; Apple 개발을 위한 hooks; Live Activities; watchOS 런타임; SwiftUI 내부; RealityKit의 공간 정신 모델; SwiftData 스키마 규율; Liquid Glass 패턴; 멀티플랫폼 출시; 플랫폼 매트릭스; Vision 프레임워크; Symbol Effects; Core ML 추론; 내가 쓰기를 거부하는 것. 허브는 Apple Ecosystem Series에 있습니다. 더 광범위한 iOS와 AI 에이전트 컨텍스트는 iOS Agent Development guide를 참조하세요.

FAQ

내 앱에서 Writing Tools를 테스트하려면 Apple Intelligence가 필요한가요?

전체 사용자 경험을 테스트하려면 그렇습니다. 사용자 대면 Writing Tools 메뉴는 Apple Intelligence가 활성화된 기기(iPhone 15 Pro 이상, M1 Mac 이상, iOS 18+ / macOS 15+ 포함)에서만 나타납니다. 개발 목적으로는, 텍스트 뷰가 isWritingToolsActive를 노출하고 델리게이트 메서드가 올바르게 연결되어 있는지 확인하여 모든 iOS 18+ 시뮬레이터 또는 기기에서 API 통합을 테스트할 수 있습니다. 시스템 메뉴는 Apple Intelligence를 사용할 수 없으면 표시되지 않습니다.

iOS 18+ 앱에서 Writing Tools에 대해 아무것도 하지 않으면 어떻게 되나요?

표준 텍스트 뷰(UITextView, WKWebView)의 경우 Writing Tools가 자동으로 표시됩니다. UITextInteraction이 없는 커스텀 텍스트 뷰의 경우 Writing Tools가 메뉴에 나타나지 않으며 사용자는 앱의 텍스트에서 호출할 수 없습니다. 아무것도 하지 않는 것은 Writing Tools가 부적절한 뷰(비밀번호 필드, 코드 편집기)에 대한 방어 가능한 기본값입니다. 일반 텍스트 입력의 경우 아무것도 하지 않는 것은 사용자가 찾을 시스템 기능을 놓치는 것을 의미합니다.

.complete와 .limited의 차이점은 무엇인가요?

.complete는 원본 텍스트를 다시 쓴 텍스트로 모핑하는 애니메이션과 함께 인라인으로 Writing Tools 다시쓰기를 실행하며, 인라인 교정 하이라이트도 포함합니다. .limited는 패널 UI를 통해 Writing Tools를 실행합니다. 사용자는 별도의 표면에서 다시쓰기를 보고 적용 여부를 결정합니다. 인라인 애니메이션이 편집 흐름을 강화하는 장문 텍스트 편집기에는 .complete를 사용하고, 패널이 더 적합하게 느껴지는 짧은 텍스트 필드에는 .limited를 사용하세요.

Writing Tools 프롬프트 또는 모델 동작을 사용자 지정할 수 있나요?

모델과 프롬프트는 시스템이 제어합니다. 앱은 Writing Tools 메뉴에 커스텀 다시쓰기 동작을 주입할 수 없습니다. 앱별 생성형 글쓰기 기능의 경우 Foundation Models 프레임워크를 직접 사용하고(Foundation Models on-device LLM에서 다룸) 자체 UI를 통해 기능을 제공하세요.

Writing Tools는 혼합 선택(텍스트 + 이미지)을 어떻게 처리하나요?

WWDC 2025의 “Dive deeper into Writing Tools”⁸에 따르면, 임베디드 콘텐츠(이미지, 첨부 파일)를 포함하는 혼합 선택은 임베디드 콘텐츠가 불투명한 범위로 보존된 상태로 코디네이터를 통해 흐릅니다. Writing Tools는 주변 텍스트를 다시 쓰지만 임베디드 콘텐츠를 변환하려고 시도하지 않습니다. 코디네이터를 사용하는 앱의 경우, 델리게이트는 임베디드 콘텐츠의 범위가 변경되지 않은 것으로 표시된 제안된 텍스트 페이로드를 받습니다.

References