코딩 실습: Foundation Models 프레임워크를 사용하여 앱에 온디바이스 AI 가져오기

안녕하세요, 저는 Naomy입니다 SwiftUI 및 온디바이스 인텔리전스에 대해 알아보겠습니다 이 코딩 실습에서는 파운데이션 모델 프레임워크로 앱에 흥미로운 새 기능을 추가하는 방법을 살펴봅니다 다음 여행을 계획할 앱을 만들며 단계별 예시를 안내하겠습니다 파운데이션 모델 프레임워크를 사용하면 Apple의 온디바이스 대규모 언어 모델을 직접 이용할 수 있어 콘텐츠 제작 가능성이 무한합니다 온디바이스 실행이므로 사용자의 데이터를 비공개로 유지할 수 있죠 모델은 오프라인 상태이며 운영 체제에 이미 내장되어 있고요 앱 크기를 늘리지 않습니다 이 프레임워크로 macOS, iPadOS, iOS, visionOS에서 우수한 성능으로 강력한 기능을 비공개 빌드할 수 있습니다 친구들과 저는 여행을 떠나고 싶지만 장소와 활동에 아이디어가 필요합니다 계획은 어려울지 몰라도 파운데이션 모델 프레임워크 사용은 쉬운데, 모든 계획을 알아서 해 주는 앱을 만들어 보죠 오늘 빌드할 내용은 이러합니다 앱의 랜딩 페이지는 둘러볼 수 있는 몇몇 주요 명소를 표시합니다 재미있게 생긴 나무네요 Joshua Tree를 선택하겠습니다 생성 버튼을 탭하면 모델이 대신 작업해 줍니다 여정을 만들고 그 과정에서 도구 호출도 사용해 명소에 가장 적합한 관심 지점을 자동으로 선택합니다 친구들이 이 앱을 좋아하겠죠? 그럼 본격적으로 빌드해 볼까요 프레임워크를 사용하는 데는 몇 가지 단계가 있습니다 먼저 프롬프트 엔지니어링입니다 Xcode의 Playground로 프롬프트를 완성하는 방법을 보여 드리죠 도구 호출이 외부 소스에 도달해 명소의 관심 지점을 가져오도록 하여 모델을 보완합니다 출력을 스트리밍해 모델이 내용을 생성하는 대로 여정을 표시합니다 정돈을 위해 앱을 프로파일링하고 최적화를 적용합니다 파운데이션 모델 프레임워크로 최고의 성능을 내도록요 좋은 프롬프트는 좋은 결과를 위한 열쇠입니다 프롬프트 작성은 흔히 반복이 잦은 지루한 작업이 되기도 합니다 앱을 실행하고 출력을 검토한 후 프롬프트를 바꾸고 다시 실행하는 작업을 계속 반복하는 거죠 그러면 하루 종일 걸리고 여행을 떠날 시간이 없을 것입니다 다행히 Xcode의 업데이트된 Playground 기능이 도움이 됩니다 먼저 캔버스가 활성화되어 있는지 확인합니다

SwiftUI의 미리보기와 비슷한데 Swift 코드에 대한 실시간 피드백 창구 역할을 합니다 이제 프로젝트의 파일에서 Playground를 가져와

#Playground라고 적어 코드를 반복합니다

기본 사항부터 다루겠습니다 FoundationModels를 가져오고

세션을 생성하고

요청을 만듭니다

프롬프트에 “Create an itinerary (여정 만들어 줘)”라고 작성합니다 입력하기 시작하면 자동으로 실행되어 결과가 캔버스에 표시됩니다

내용이 좀 막연했죠? 위치를 추가하겠습니다

훨씬 나은 프롬프트네요 이번에는 일정이 나왔습니다 현재로서는 만족스럽고 나중에 언제든 프롬프트를 손볼 수 있죠 파운데이션 모델 프레임워크 시작이 매우 쉬움을 확인했고요 프롬프트를 제공하면 문자열이 출력으로 수신됩니다 하지만 일정이 더 구조화된 출력이었으면 좋겠습니다 자체 데이터 구조로 결과를 나타내고 싶습니다 모델의 출력을 직접 파싱할 필요 없이요 유도 생성을 사용하면 모델이 사용자가 원하는 데이터 구조를 자동으로 생성할 수 있습니다 Generable로 주석 처리한다면요 실제로 해 보겠습니다 이것이 모델에서 생성해 주었으면 하는 일정 구조입니다 먼저 FoundationModels을 가져오고

Generable 주석을 추가합니다

Generable의 유일한 요구 사항은 속성의 유형도 Generable이어야 한다는 것입니다 다행히 문자열 같은 일반적인 유형은 즉시 Generable입니다 여기의 DayPlan 같은 중첩된 유형이면 그것도 Generable로 만들면 됩니다 완전 Generable 유형 계층 구조가 마련되었으니 모델이 응답으로 Itinerary 구조를 생성할 수 있죠 출력을 더 세밀하게 제어하려면 Guide 매크로로 속성의 값에 제약 조건을 적용할 수 있습니다 설명이 포함된 가이드도 추가할 수 있습니다 지금 작성한 제목처럼요

속성을 알려진 값의 하위 집합으로 제한할 수도 있습니다

count를 추가해

일정 배열의 요소가 항상 세 개가 되게 할 수 있고 속성에 가이드를 여러 개 사용할 수도 있습니다 속성에 가이드를 더 추가하겠습니다

가이드 설명은 모델에 프롬프트를 작성하는 또 다른 방법입니다 “자세히 알아보기” 비디오를 꼭 보시기 바랍니다 유도 생성에 대해 Louis가 자세히 설명해 드립니다 프롬프트와 Generable 유형이 준비되었으니 한데 합쳐 볼까요

모든 Foundation Models 논리가 이 Itinerary Planner에 저장되죠

이제 세션을 만들어 보겠습니다

지침을 제공하고요 여기서 빌더 API를 사용해 지침을 쉽게 만들 수 있습니다 이 클로저에서 여러 문자열을 전달할 수 있습니다 Generable 유형 인스턴스도요 지침은 상위 프롬프트 작성 형태입니다 여기서는 모델이 하는 일을 정의합니다

여정을 원하므로 선택한 명소에 대한 정보를 모델에 제공합니다

예시를 포함하면 사용자가 원하는 응답 유형을 모델이 더 잘 파악할 수 있어 좋습니다

또 Itinerary 구조체의 인스턴스를 전달할 수 있습니다 아래에서 일본 여행으로 정의했죠

Itinerary 구조체가 Generable이라 Foundation Models가 자동으로 이를 모델이 이해하는 텍스트로 변환합니다 이제 Generable 유형을 출력으로 하여 요청할 준비가 되었습니다

프롬프트에서 모델에 명시적으로 여정을 요청합니다

이 모두를 하나로 결합하기 위해 여정을 모델의 응답으로 설정합니다

마지막 단계는 이 내용을 UI에 표시하는 것입니다 ItineraryPlanner를 Observable로 만들어 여정이 생성되었을 때 UI에서 알도록 합니다

그리고 LandmarkTlipView에 상태 속성으로 추가합니다 그러면 플래너 콘텐츠가 변경될 때 보기가 업데이트됩니다

여기서 초기화하면 보기가 화면에 나타나지 않아도 불필요하게 다시 생성되어 원치 않는 성능 비용이 발생합니다 작업 수정자를 사용해 객체 생성을 연기하는 편이 좋습니다 여기서 작업을 추가하고 플래너를 초기화하겠습니다

보기가 나타났을 때 한 번만 호출되죠 모델에서 여정을 받으면 이를 표시할 수 있습니다

ItineraryView라는 다른 보기를 사용하겠습니다 이 안에 제목을 표시하고

스타일을 추가합니다

설명과 근거도

동일하게 처리합니다

다른 보기를 사용해 남은 일정 속성을 비슷한 방식으로 표시하고요 시작이 좋은데요 모델이 지침에 제공된 설명을 사용해 기본적인 일정을 생성합니다 한 단계 더 나아가 볼까요 프레임워크는 모델이 응답에 외부 정보를 포함할 수 있게 하는 유연한 도구 프로토콜을 제공합니다 휴대폰 연락처의 사람들 달력의 일정, 온라인 콘텐츠 등을 창의적으로 활용할 수 있습니다 타당한 도구 호출 시점과 빈도는 모델이 자동으로 결정합니다 플래너 앱의 전문성을 높이고자 MapKit을 호출해 명소의 가장 적합한 관심 지점을 가져오는 도구를 만들겠습니다 도구를 만들려면 도구 프로토콜을 준수해야 합니다

여기에는 도구를 식별하기 위한 고유 이름 도구를 호출하는 시점에 대한 Natural Language 설명 모델이 도구를 호출하는 방식인 call 함수와 직접 정의된 인수가 포함됩니다 이제 도구를 구성해 볼까요 FoundationModels와

MapKit을 가져옵니다

도구 프로토콜을 준수하는 데이터 구조가 있고

이름과

설명도 있습니다

프레임워크는 이러한 문자열을 지침에 자동으로 배치해 모델이 도구의 기능을 이해하고 호출 시점을 결정하도록 합니다 도구는 선택된 명소 등 사용자의 입력을 받을 수도 있습니다

도구가 다양한 관심 지점을 가져왔으면 하므로 열거형을 추가해 보겠습니다

모델은 세상에 대한 지식을 사용해 특정 명소에 가장 적합한 카테고리를 결정합니다 예를 들어 그레이트 배리어 리프에서는 항구를 찾을 겁니다 건조한 지역이나 조슈아 트리 같은 사막과 달리요 모델이 이 열거형을 생성하므로 Generable이 되어야 합니다

그런 다음 열거형과 Natural Language 쿼리를 함께 사용하는 Arguments 구조체를 정의합니다

구현에서는 모델이 도구 호출을 결정했을 때 호출하는 방법에

해당하는 call 메서드가 있습니다 앞서 작성한 MapKit 논리를 보면

모델에서 생성된

Natural Language 쿼리를 입력으로 사용하고 모델에서 선택한 카테고리도 사용해 MapKit에 요청하여 명소 좌표에서 반경 20km 내의 관심 지점을 가져옵니다

요청된 제약 조건을 사용해 검색하고

결과를 반환합니다

그런 다음 call 메서드를 구현할 수 있습니다 MapKit에 접근해

결과를 필터링하고

출력을 반환하는 겁니다

이것이 MapKit의 정보를 가져오는 도구를 정의하는 방법입니다 정리하고자 ItineraryPlanner로 돌아가겠습니다

앞서 생성한 세션이 있고요 사용자가 입력으로 선택한 명소로 도구의 인스턴스를 만들겠습니다

그런 다음 도구를 세션 이니셜라이저에 전달할 수 있죠

이렇게 모델이 도구를 호출하도록 할 수 있으며 더 자주 호출하게 하려면 추가 프롬프트를 만들 수 있습니다 도구와 카테고리를 사용하도록 모델에 명시적으로 요청할 수 있죠

어느 정도 마무리되었으니 이제 테스트할 시간입니다 테스트 기기가 없더라도 괜찮습니다 개발 머신이 최신 macOS로 실행되고 Apple Intelligence를 활성화해 사용 가능한 상태라면 iPhone 및 visionPro 시뮬레이터에서 편리하게 실행할 수 있습니다 Joshua Tree를 선택하고 여정을 요청해 보죠

작업에 시간이 좀 걸리는데요 모델이 모든 출력을 한 번에 반환하기 때문입니다 그래서 각 활동이 생성되어야 결과를 받을 수 있습니다 속도를 높이는 방법을 나중에 보여 드리겠습니다 이렇게 흥미진진한 여정이 나왔습니다

그런데 매우 중요한 것을 잊고 있었군요 온디바이스 Foundation Model을 항상 사용 가능하다고 가정했는데 아닐 경우도 있죠 모델의 가용성은 Apple Intelligence의 가용성에 따라 결정되며 Apple Intelligence가 기기에서 지원, 활성화, 준비 상태가 아닐 수도 있습니다 따라서 모델의 상태를 확인하고 UI에서 적절하게 처리하는 것이 중요합니다 이제 테스트를 위해 물리적 기기로 테스트하거나 불가피하게 AppleIntelligence를 비활성화하는 대신 Xcode의 유용한 체계 옵션을 사용할 수 있습니다

체계를 보면 Foundation Models Availability 재정의가 있습니다 현재는 꺼져 있고요 여기 첫 세 가지 옵션이 기기에 모델이 없는 이유에 해당합니다 하나를 선택한 후 앱에서 여정 생성을 요청하고 어떻게 되는지 보겠습니다

문제가 생기는군요 오류 내용만 표시되고 실행 가능한 조치가 없습니다 다시 돌아가서 가용성을 앱에 통합할 방법을 모색해야 합니다 앞서 보여 드린 세 가지 사례를 생각해 보죠 Apple Intelligence 사용 요건을 충족하지 않는 기기라면 여정 생성 버튼을 표시하는 의미가 없습니다 명소를 선택했을 때 앱의 오프라인 데이터를 사용해 사용자에게 짧은 설명만 표시하도록 하겠습니다 두 번째 사례는 기기에서 Apple Intelligence를 사용할 수 있지만 활성화하지 않은 경우죠 이것이 여정 플래너를 사용할 수 없는 이유임을 알려야 사용자가 옵트인해 이 기능에 접근할지 여부를 결정 가능합니다 마지막으로 Model Not Ready는 모델이 다운로드를 완료하는 데 시간이 더 필요함을 의미합니다 기능을 곧 사용할 수 있으며 나중에 다시 시도할 것을 사용자에게 안내하면 됩니다

앱 동작을 디자인했으니 가용성 API를 활용해 기기의 가용성 상태를 결정할 수 있습니다 이 보기에서 사용 중인 모델에 대한 새 변수를 추가하겠습니다 여기서는 시스템 언어 모델이죠

그런 다음 가용성 상태를 켭니다

모델을 사용할 수 있으면 원래 동작을 계속 이용하면 됩니다

Apple Intelligence가 활성화되지 않았으면 사용자에게 알립니다

모델이 준비되지 않았으면 나중에 다시 시도하게 안내합니다

이외에는 여정 버튼을 숨기고 재미있는 사실만 표시합니다

체계에서 Foundation Models 재정의가 이미 Device Not Eligible로 설정되어 있는데요 이 사례를 다시 시도해 보죠

훨씬 낫네요 이제 재미있는 사실만 표시되고 여정 생성 버튼이 제거되어 사용자가 기기에서 지원하지 않는 경로로 진행할 수 없습니다 돌아보면 앱은 전체 여정이 생성되기를 기다렸다가 UI에 표시합니다 다행히도 모델이 여정을 생성하는 대로 스트리밍하면 추천 내용을 바로 읽기 시작할 수 있습니다 스트리밍을 사용하려면 호출하는 respond 메서드를 변경합니다

전체 여정 대신 부분적 버전을 받는 겁니다 자동으로 생성된 PartiallyGenerated 데이터 구조를 사용할 수 있습니다 Generable 구조에서 모든 속성이 선택 사항인 상태인데요 예상되는 여정 유형을 변경하겠습니다

이제 결과가 PartiallyGenerated 유형을 출력으로 하는 새 비동기 시퀀스가 되었습니다

스트림의 각 요소는 점진적으로 업데이트되는 여정 버전입니다 예를 들어 첫 번째 요소에는 제목이 있지만 다른 일정 속성은 nil일 수 있습니다 그러다 두 번째 요소에 제목 및 설명이 생기고 이 방식이 이어져 여정 전체가 완성됩니다 이제 보기에서 이러한 속성의 래핑을 해제해야 합니다 이때 다른 속성 없이 표시해도 되는 속성을 생각해 보면 좋습니다 여기서는 여정에 제목, 설명, 일일 계획이 있고 현재 순서가 알맞습니다 따라서 여정을 부분적으로 생성하고

제목, 설명, 근거 순서로

래핑을

해제합니다

일정 목록을 보면

여기서도 부분적으로 생성된 일일 계획을 표시해야 합니다 PartiallyGenerable 구조는 자동으로 식별 가능하기 때문에 ID를 직접 관리할 필요가 없습니다 부분적으로 생성된 구조에 Swift UI의 forEach를 사용하면 됩니다

아주 쉽죠 여정에 따라 애니메이션을 추가해 볼까요

그리고 속성에 콘텐츠 전환을 추가해

결과가 보기에 매끄럽게 스트리밍되도록 합니다

다른 모든 속성의 래핑을 해제하고요 그러면 앱이 거의 완성됩니다 휴대폰에서 테스트해 보겠습니다 아까와 동일한 요청으로요

이번에는 UI에서 출력이 바로 스트리밍됩니다 콘텐츠가 생성되는 동안 사용자는 첫날 일정부터 읽어 나갈 수 있습니다

그런데 첫 번째 필드가 화면에 표시되기까지 약간 지연이 있군요 이 문제를 해결하려면 화면 뒤 속사정을 이해해야 합니다

이 대목에서 새로운 Foundation Models Instrument를 사용해 성능에 영향을 미치는 요인을 더 깊이 이해하면 좋습니다 앱 프로파일링으로 이유를 알아보죠 앞서 시뮬레이터에서 앱을 실행하는 것을 이야기했습니다 기능 테스트에는 유용하지만 성능 결과가 정확하지 않을 수 있는데 예를 들어 M4 Mac의 시뮬레이터는 이전 iPhone보다 더 빠른 결과를 표시할 수 있습니다 성능을 살펴볼 때는 이러한 차이점에 유의하는 것이 중요합니다 실물 iPhone으로 프로파일링을 해 보겠습니다

시작하려면 Mac에서 Instruments 앱을 열고 휴대폰을 연결합니다

새로운 Foundation Models instrument를 추가하고

기록을 시작한 후 여정을 생성합니다

Asset Loading 트랙은 모델 로드 소요 시간을 살펴봅니다 기본 시스템 언어 모델과 안전 가드레일이 로드되었습니다 Inference 트랙도 파란색으로 표시되고요

마지막으로 보라색 막대는 도구 호출에 소요된 시간 부분입니다 여정을 생성하는 데 걸린 총 시간과 입력 토큰 수를 추적할 수 있으며 후자는 지침과 프롬프트 크기에 비례합니다 시작 부분의 이 지연은 시스템 언어 모델을 로드하는 데 걸리는 시간 부분이었습니다 속도를 높이는 방법은 몇 가지가 있습니다 초기 지연 시간의 일부가 Asset Loading 트랙에서 포착되었는데요 온디바이스 언어 모델은 운영 체제에서 관리하며 시스템에서 다른 중요한 기능을 제공하는 경우 또는 한동안 사용되지 않은 경우 메모리에 보관되지 않을 수 있죠 session.respond를 호출했을 때 모델이 이미 메모리에 있지 않다면 운영 체제에서 이를 로드합니다 요청이 있기 전에 모델을 로드하는 사전 준비를 통해 세션을 더 빨리 시작할 수 있습니다 앱이 비교적 유휴 상태이고 사용자가 세션을 사용하겠다는 강한 힌트가 있은 후에 이 작업을 수행하는 것이 좋습니다 사전 준비가 필요한 시점의 좋은 예는 사용자가 텍스트 필드에 프롬프트를 발생시킬 입력을 시작한 직후입니다 우리 앱에서는 사용자가 명소를 탭하면 곧 요청이 발생할 가능성이 매우 높습니다 사용자가 여정 생성 버튼을 누르기 전에 사전 준비를 해서 모델을 미리 로드할 수 있습니다 사용자가 설명을 다 읽을 때쯤이면 모델 사용 준비가 완료됩니다

요청 시점에 두 번째 최적화를 추가할 수 있는데요 response 함수의 생성 인수를 기억하시나요? 여기에 Itinerary를 사용했죠 프레임워크는 자동으로 데이터 구조의 생성 스키마를 프롬프트에 삽입합니다 이 때문에 토큰, 지연 시간 컨텍스트 크기가 늘어나죠 모델이 요청 전에 이미 응답 형식을 완전히 이해하고 있다면 IncludeSchemaInPrompt를 false로 설정해 성능을 다소 향상할 수 있습니다

이 최적화를 언제 적용할 수 있을까요? 첫 번째 경우는 멀티턴 대화에서 유형이 같은 후속 요청을 할 때입니다 세션의 첫 번째 요청에서 이미 프롬프트에 스키마가 포함되어 유도 생성에 컨텍스트가 제공되었습니다 따라서 세션의 후속 요청에는 이 작업이 필요 없습니다 두 번째 경우는 지침에 스키마의 전체 예가 포함되어 있을 때입니다 Instructions에 예시 여행 일정을 전달한 것을 기억하시나요? 여기서는 이것으로 충분합니다 Itinerary 구조에 선택적 속성이 없기 때문입니다

스키마에 선택적 속성이 있다면 모든 선택적 속성에 채워진 예시와 nil인 예시를 제공해야 합니다 마지막 고려 사항은 IncludeSchemaInPrompt를 false로 설정하면 가이드에 추가한 설명이 사라진다는 점인데 예시가 철저하다면 문제가 되지 않을 것입니다 그러면 최적화를 테스트해 보죠 요청에서 IncludeSchemaInPrompt 옵션을 false로 설정합니다 사용자가 명소 설명 페이지에 있을 때 세션을 사전 준비하고요 간단한 래퍼를 만든 후

세션에서 호출합니다

이제 결과를 볼까요 똑같은 설정으로 미리 기록한 결과를 보겠습니다 생성 버튼을 탭하기 전에 Asset Loading 트랙에 이미 활동이 약간 있었습니다 입력 토큰 수가 상당히 줄어들었고 전체 응답 시간이 단축되었습니다 이러한 최적화로 몇 초가 절약된 것을 보니 제때 여행을 떠날 수 있겠네요 이제 여행 준비가 끝났습니다

하지만 그 전에 관련 세션 몇 가지를 알려 드리겠습니다 아직 시청하지 않으셨다면 “만나 보기” 세션에서 프레임워크에 대해 알아보세요 “자세히 알아보기” 비디오에서는 심화 내용을 다루며 프롬프트 작성 모범 사례는 “프롬프트 디자인 및 안전성”을 확인하세요 시청해 주셔서 감사합니다