Mabataki Developer

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ Core Spotlight로 LLM 검색 보기
✅ 로컬 RAG 느낌 이해하기

이번 세션은 Core Spotlight를 사용한 LLM 검색입니다.

제목만 보면 Spotlight 세션인가? 싶었는데, 보고나니 Foundation Models랑 연결되는 내용이었습니다.

앱 안의 데이터를 Core Spotlight에 인덱싱해두고, 모델이 SpotlightSearchTool을 통해 그 데이터를 찾아서 답변에 활용하는 구조입니다.

이거 꽤 재밌습니다.

배운점

왜 검색이 필요한가

LLM은 말을 잘하지만, 앱 안의 최신 데이터나 사용자 개인 데이터는 기본적으로 모릅니다.

그러면 모델이 답을 만들 때 앱의 데이터를 가져올 방법이 필요합니다.

서버에서는 RAG라고 해서 검색 시스템을 붙이는데, Apple 플랫폼에서는 Core Spotlight를 활용해서 로컬 데이터 기반 검색 경험을 만들 수 있습니다.

사용자 데이터가 기기 안에 머물 수 있다는 점이 장점입니다.

Core Spotlight 인덱싱

핵심은 앱 데이터를 Core Spotlight에 잘 넣어두는 것입니다.

제목, 설명, 식별자, 메타데이터를 잘 구성해야 모델이 검색했을 때 쓸만한 결과를 가져옵니다.

검색 인덱스를 대충 만들면 모델이 아무리 좋아도 이상한 답을 할 수 있습니다.

결국 AI 검색 품질은 모델만의 문제가 아니라 데이터 정리의 문제이기도 합니다.

SpotlightSearchTool

세션에서는 SpotlightSearchTool을 LanguageModelSession과 함께 사용하는 흐름을 보여줍니다.

사용자가 자연어로 질문하면 모델이 필요한 정보를 판단하고, Spotlight 검색 도구를 호출해서 앱 콘텐츠를 가져온 뒤 답변합니다.

예를 들어 노트 앱에서 “지난주 회의에서 결제 얘기한거 찾아줘” 같은 요청을 처리할 수 있는 느낌입니다.

이런건 진짜 앱에 넣으면 유용할 것 같습니다.

생각과 감정

저는 이 세션이 꽤 마음에 들었습니다.

AI 검색을 만들고 싶은데 사용자 데이터를 외부 서버로 보내긴 싫을 때, Core Spotlight 기반 접근이 꽤 좋은 선택지처럼 보입니다.

물론 인덱싱을 잘 해야합니다.

결국 또 데이터 정리입니다. 하하.. 데이터 모델 대충 만들면 미래의 내가 웁니다.

Foundation Models랑 Core Spotlight가 연결되는 지점이라 iOS 앱 개발자라면 챙겨볼만한 세션이라고 생각합니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/246

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ AppIntentsTesting 보기
✅ Siri 연동 테스트 방법 이해하기

이번 세션은 AppIntentsTesting으로 앱 인텐트 도입을 검증하는 방법입니다.

Siri, Shortcuts, Spotlight에서 쓰는 App Intents를 테스트하는 프레임워크라고 보면 됩니다.

처음엔 “이것도 테스트해야하나?” 싶었는데요.

해야합니다 ㅋㅋ

왜냐면 사용자는 Siri로 말하고, Spotlight로 찾고, Shortcuts에서 실행하는데 개발자가 그냥 함수만 호출해보고 끝내면 실제 경험이 깨질 수 있기 때문입니다.

배운점

UI 자동화 없이 테스트하기

좋았던 점은 UI 자동화 없이도 인텐트를 테스트할 수 있다는 부분입니다.

Siri 연동을 테스트한다고 매번 음성으로 말해보고, 화면 눌러보고, Shortcuts 열어보고 하면 너무 힘듭니다.

AppIntentsTesting은 실제 시스템 경로에 가까운 방식으로 인텐트를 실행하고 결과를 검증할 수 있게 해줍니다.

이건 테스트 안정성 면에서 좋아보였습니다.

무엇을 검증하나

단순히 Intent가 실행되는지만 보는게 아닙니다.

- 결과 값이 맞는지
- 파라미터가 잘 처리되는지
- EntityQuery가 원하는 항목을 찾는지
- 없는 데이터 요청을 어떻게 처리하는지

이런걸 확인할 수 있습니다.

특히 Siri가 앱 콘텐츠를 찾는 경우에는 EntityQuery 테스트가 중요할 것 같습니다.

사용자가 자연어로 말했을 때 엉뚱한 데이터를 찾으면 경험이 바로 깨지니까요.

실제 적용한다면

저라면 자주 쓰는 Intent부터 테스트를 만들 것 같습니다.

예를 들어 할 일 앱이면,

- 오늘 할 일 보여주기
- 특정 프로젝트의 작업 찾기
- 없는 작업 요청하기
- 이름이 비슷한 작업 여러개 처리하기

이런 케이스부터요.

처음부터 모든걸 테스트하려고 하면 또 안하게 됩니다 ㅋㅋ

생각과 감정

이 세션은 꽤 현실적이었습니다.

App Intents가 시스템 깊숙이 들어갈수록 테스트가 없으면 무섭습니다.

앱 안에서는 잘 되는데 Siri에서는 안된다? 사용자는 그냥 앱이 구리다고 느낄겁니다.. 흑

그래서 App Intents를 실제 기능으로 쓸거면 AppIntentsTesting도 같이 봐야할 것 같습니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/295

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ App Intents 새 기능 보기
✅ RelevantEntities 이해하기

이번 세션은 App Intents 프레임워크의 새로운 기능을 훑는 세션입니다.

App Intents 관련 세션이 여러개라 헷갈릴 수 있는데, 이 세션은 업데이트 목록을 정리하는 느낌으로 보면 좋습니다.

Siri, Spotlight, Shortcuts, Apple Intelligence가 앱을 더 잘 사용할 수 있게 만드는 API들이 추가됐습니다.

배운점

ValueRepresentation

ValueRepresentation은 앱의 값이나 엔티티를 사용자에게 어떻게 보여줄지 표현하는 기능으로 이해했습니다.

시스템이 앱 데이터를 보여줄 때 개발자가 의도한 이름이나 표현이 중요하니까요.

예를 들어 내부 값은 코드상으로 복잡하게 되어 있어도, 사용자에게는 자연스러운 이름으로 보여줘야 합니다.

RelevantEntities

RelevantEntities는 현재 맥락에서 관련 있는 엔티티를 시스템에 알려주는 기능입니다.

모든 데이터를 다 똑같이 보여주기보다, 지금 사용자에게 의미 있는 항목을 더 잘 노출하는 방식입니다.

이건 실제 앱에서 중요할 것 같습니다.

데이터가 많아질수록 “관련 있는 것”을 잘 보여주는게 사용자 경험을 크게 좌우하니까요.

EntityCollection

EntityCollection은 앱 안의 엔티티들을 묶어서 탐색 가능한 구조로 제공하는 기능으로 보입니다.

앱 내부 데이터가 시스템 입장에서도 의미 있는 컬렉션으로 보이게 만드는 느낌입니다.

결국 App Intents를 잘 쓰려면 앱의 데이터 모델이 깔끔해야 합니다.

내부 구조가 엉망이면 시스템에 설명하기도 힘들겠죠.

생각과 감정

이 세션을 보면서 App Intents가 생각보다 깊은 프레임워크라는걸 다시 느꼈습니다.

처음엔 그냥 Siri 명령어 만드는 느낌이었는데, 이제는 앱의 도메인 모델을 시스템에 전달하는 역할을 합니다.

이건 꽤 큰 변화입니다.

앞으로 iOS 앱 만들 때 App Intents를 나중에 붙이는게 아니라, 처음 설계할 때부터 염두에 두는게 좋을 것 같습니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/345

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ 고급 App Intents 보기
✅ Siri와 화면 연결 이해하기

이번 세션은 Siri 및 Apple Intelligence를 위한 고급 App Intents 기능을 다룹니다.

기본 App Intent를 만들 수 있다면, 그 다음 단계로 봐야 할 세션 같습니다.

처음에는 App Intents가 단축어 같은 느낌이었는데, 이제는 앱과 시스템을 연결하는 핵심 인터페이스가 되는 것 같습니다.

후.. 점점 커집니다 이 친구.

배운점

View Annotations

이번 세션에서 눈에 들어온건 View Annotations입니다.

사용자가 화면에서 보고 있는 내용을 Siri가 이해할 수 있게 도와주는 API입니다.

예를 들어 사용자가 앱 화면을 보면서 “이거 저장해줘” 라고 말했을 때, Siri는 “이거”가 뭔지 알아야 합니다.

그냥 음성만 듣는게 아니라 현재 화면의 뷰와 앱 엔티티가 연결되어 있어야 가능한 경험입니다.

이 부분이 꽤 중요해보였습니다.

앱 콘텐츠 검색

Apple Intelligence가 앱의 콘텐츠를 찾으려면 앱이 데이터를 잘 설명해줘야 합니다.

App Entity, 앱 스키마, Spotlight 인덱싱이 다 연결됩니다.

사용자는 정확한 메뉴 이름을 모르더라도 자연어로 요청하고, Siri는 앱의 콘텐츠를 찾아서 적절한 화면이나 동작으로 이어줄 수 있습니다.

이건 앱 입장에서 발견 가능성이 늘어나는 일이기도 합니다.

사용자가 앱 안에서 메뉴를 찾지 못해도 Siri나 Spotlight를 통해 기능에 접근할 수 있으니까요.

주의할 점

근데 시스템이 앱을 더 깊게 사용할 수 있게 되는 만큼, 개발자는 뭘 열어줄지 잘 정해야 할 것 같습니다.

민감한 데이터나 위험한 동작은 확인 과정이 필요할 수 있고, 어떤 엔티티를 노출할지도 고민해야 합니다.

편리함만 보고 다 열면 언젠가 사고날 것 같은 느낌.. ㅋㅋ

생각과 감정

이 세션은 App Intents가 이제 선택 기능이 아니라 기본 설계에 가까워지고 있다는 느낌을 줬습니다.

앞으로 앱을 만들 때 “이 화면을 어떻게 보여줄까?” 뿐만 아니라 “이 화면과 데이터는 Siri가 어떻게 이해할까?” 도 같이 생각해야 할 것 같습니다.

조금 귀찮지만, 잘 해두면 앱 사용성이 확 좋아질 것 같네요.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/343

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ 앱 스키마 이해하기
✅ Siri 경험 흐름 잡기

이번 세션은 앱 스키마로 지능형 Siri 경험을 만드는 내용입니다.

앞의 코딩 실습이 “어떻게 붙이는지”에 가까웠다면, 이 세션은 “왜 앱 스키마가 중요한지”에 더 가까운 것 같습니다.

요즘 Apple이 계속 말하는 방향은 앱이 자기 기능과 데이터를 시스템에 잘 설명해야 한다는 것입니다.

그래야 Siri도 쓰고, Spotlight도 쓰고, Apple Intelligence도 쓸 수 있겠죠.

배운점

앱 콘텐츠를 시스템에 설명하기

앱 안에는 여러 데이터가 있습니다.

메모 앱이면 노트, 폴더, 태그가 있고 일정 앱이면 이벤트, 날짜, 장소 같은게 있습니다.

앱 내부에서는 당연한 데이터지만, 시스템 입장에서는 그냥 앱 안에 갇힌 정보입니다.

App Entity와 앱 스키마는 이 데이터를 시스템이 이해할 수 있는 형태로 설명하는 역할을 합니다.

그러면 Siri가 자연어 요청을 받았을 때 앱 안의 콘텐츠를 찾고, 필요한 동작으로 연결할 수 있습니다.

자연어 요청

사람은 같은 의미를 다 다르게 말합니다.

“내일 일정 보여줘”
“내일 뭐 있어?”
“내일 회의 있나?”

다 비슷한 요청인데 문장은 다릅니다.

앱 스키마가 잘 정의되어 있으면 Siri가 이런 표현을 앱의 엔티티와 동작으로 연결할 수 있습니다.

예전처럼 정확한 명령어를 외우는 방식이 아니라, 앱의 의미 구조를 기반으로 이해하는 방향입니다.

Core Spotlight와 연결

세션에서는 Spotlight 시맨틱 인덱스 이야기도 나옵니다.

앱 콘텐츠를 잘 인덱싱해두면 Siri나 Apple Intelligence가 사용자의 요청에 맞는 콘텐츠를 더 잘 찾을 수 있습니다.

이건 앱 검색성과도 연결됩니다. 사용자가 앱 안에서 직접 찾지 않아도 시스템 경로를 통해 콘텐츠에 접근할 수 있으니까요.

생각과 감정

이 세션을 보고 나니까 앱 개발에서 데이터 모델이 더 중요해질 것 같다는 생각이 들었습니다.

그냥 화면에 보여주기 위한 데이터가 아니라, 시스템이 이해할 수 있는 데이터로 만들어야 합니다.

이게 처음엔 귀찮을 수 있지만, Siri나 Spotlight에서 앱이 잘 동작하게 하려면 결국 필요한 작업인 것 같습니다.

결론은.. 앱이 자기소개를 잘해야 합니다 ㅋㅋ

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/240

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ Siri가 앱을 사용하게 만들기
✅ App Intents 코딩 실습 보기

이번 세션은 Siri가 앱을 사용할 수 있도록 설정하는 코딩 실습입니다.

App Intents 관련 세션들이 조금 추상적으로 느껴질 수 있는데, 이 세션은 Xcode 프로젝트를 따라가면서 설명해줘서 좀 더 보기 편했습니다.

Siri 연동이라고 하면 예전에는 “특정 명령어를 등록한다” 정도로 생각했는데, 이제는 앱의 데이터와 동작을 시스템에 설명하는 느낌이 더 강해졌습니다.

배운점

Siri가 앱을 이해하려면

Siri가 앱을 제대로 사용하려면 앱 안에 어떤 데이터가 있고, 어떤 행동을 할 수 있는지 알아야 합니다.

예를 들어 캘린더 앱이라면 이벤트가 있고, 이벤트를 만들거나 찾거나 수정할 수 있겠죠.

이런 정보를 App Entity와 App Intent, 앱 스키마로 제공해야 Siri가 자연어 요청을 앱 동작으로 연결할 수 있습니다.

그냥 “Siri야 이 함수 실행해줘”가 아니라, 앱의 의미를 시스템에 알려주는 작업에 가깝습니다.

앱 스키마

세션에서는 앱 스키마를 도입해서 Siri가 더 자연스럽게 앱을 사용할 수 있게 만드는 흐름을 보여줍니다.

사용자가 “내일 일정 뭐 있어?” 라고 말했을 때 앱의 이벤트 데이터를 찾아서 보여주는 식입니다.

여기서 중요한건 사용자가 정확한 문구를 말하지 않아도 된다는 점입니다. 자연어는 사람마다 다르게 말하니까요.

실제 적용할 때

앱에 적용하려면 먼저 앱의 핵심 엔티티를 정해야 할 것 같습니다.

메모 앱이면 메모, 폴더, 태그.
할 일 앱이면 작업, 프로젝트, 마감일.
음악 앱이면 곡, 플레이리스트, 아티스트.

이런식으로 시스템에 설명할 수 있는 단위가 필요합니다.

그리고 자주 쓰는 행동부터 Intent로 만드는게 좋아보입니다. 처음부터 모든 기능을 Siri에 열려고 하면 지옥문 열릴듯요 ㅋㅋ

생각과 감정

이 세션을 보면서 App Intents가 진짜 중요해지고 있다는걸 느꼈습니다.

Siri와 Apple Intelligence가 앱을 사용하려면 결국 앱이 자기 자신을 시스템에 잘 설명해야 합니다.

화면만 예쁘게 만드는게 아니라, 앱의 데이터 구조와 의미까지 설계해야 하는 시대가 오는 것 같습니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/344

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ 에이전틱 앱 평가 보기
✅ 도구 호출 평가 이해하기

이번 세션은 에이전틱 앱에 대한 강력한 평가 기능을 구현하는 내용입니다.

기본 Evaluations 세션이 “AI 기능도 평가해야 한다” 라는 내용이었다면, 이 세션은 한 단계 더 들어갑니다.

모델이 답변만 하는게 아니라 도구를 호출하고, 중간 결과를 보고, 다시 판단하는 경우에는 어떻게 평가할 것인가? 를 다룹니다.

후.. 점점 복잡해집니다.

배운점

최종 답변만 보면 안된다

에이전틱 앱에서는 최종 답변이 그럴듯해도 중간 과정이 틀릴 수 있습니다.

예를 들어 모델이 잘못된 도구를 호출했는데 우연히 괜찮은 답변을 만들었다면, 그건 좋은 동작이라고 보기 어렵습니다.

그래서 평가할 때는 최종 결과뿐 아니라 도구 호출 과정도 봐야 합니다.

- 어떤 도구를 호출했는지
- 호출 순서가 맞는지
- 도구 결과를 제대로 해석했는지
- 불필요한 호출이 없었는지

이런 부분이 중요해집니다.

합성 데이터

세션에서는 평가 데이터를 만드는 이야기도 나옵니다.

실제 사용자 데이터만 기다릴 수 없으니, 합성 데이터를 만들어 다양한 상황을 테스트하는 방식입니다.

특히 애매한 요청, 데이터가 없는 경우, 비슷한 항목이 여러개 있는 경우 같은 엣지 케이스가 중요합니다.

이런걸 준비해두면 프롬프트나 도구 구성을 바꿨을 때 망가진 부분을 빨리 찾을 수 있습니다.

실제 앱에 넣는다면

저라면 핵심 기능부터 평가할 것 같습니다.

모든 AI 응답을 다 평가하려고 하면 시작도 못할 것 같고, 사용자가 자주 쓰는 기능이나 실패하면 곤란한 기능부터 테스트 데이터를 만들 것 같습니다.

예를 들어 일정 앱이면 “내일 회의 찾아줘”, “다음주 일정 요약해줘”, “없는 일정 요청” 같은 케이스를 먼저 넣는 식입니다.

생각과 감정

이 세션은 꽤 실무적인 느낌이었습니다.

AI 기능이 커질수록 “잘 되는 것 같음”으로는 안됩니다. 특히 모델이 도구를 호출하기 시작하면 중간 과정까지 확인해야 합니다.

이걸 보면서 에이전틱 앱은 멋있지만 관리할 것도 많구나 싶었습니다.

그래도 이런 평가 도구가 있다는건 좋습니다. 없으면 진짜 감으로만 해야하니까요 ㅋㅋ

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/299

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ Evaluations 프레임워크 개념 잡기
✅ AI 기능 평가 방식 이해하기

이번 세션은 Evaluations 프레임워크 소개입니다.

앞에서 프롬프트 개선 세션을 봤다면, 이 세션은 Evaluations 자체가 뭔지 보는 느낌입니다.

AI 기능을 만들다보면 항상 애매합니다. 결과가 맞는건지, 좋은건지, 그냥 그럴듯한건지 판단하기가 어렵습니다.

사람이 몇 번 눌러보고 “음 괜찮은듯?” 하는건 프로토타입에서는 괜찮지만, 앱에 실제로 넣으려면 부족하겠죠.

배운점

AI 결과는 테스트하기 어렵다

일반적인 함수는 입력과 출력이 명확합니다.

1 넣으면 2 나와야 하고, A 넣으면 B 나와야 하고.. 이런식으로 테스트할 수 있습니다.

근데 AI 결과는 그렇지 않습니다.

같은 입력이어도 표현이 조금씩 달라질 수 있고, 정답이 하나가 아닐 수도 있습니다. 그래서 단순 문자열 비교 같은 테스트로는 부족합니다.

Evaluations는 이런 AI 기능의 품질을 측정하기 위한 프레임워크입니다.

무엇을 평가할까

세션을 보면서 느낀건 평가 기준을 잘 만드는게 정말 중요하다는 점입니다.

예를 들어,

- 답변이 필요한 정보를 포함했는지
- 불필요한 내용을 만들지 않았는지
- 올바른 형식을 지켰는지
- 도구 호출이 적절했는지
- 안전하지 않은 답변을 피했는지

이런 것들이 평가 대상이 될 수 있습니다.

모델 답변이 그냥 예쁘게 보이는지보다, 앱이 원하는 목적을 달성했는지를 봐야 합니다.

개발 흐름에 넣기

Evaluations는 프롬프트나 모델 설정을 바꿀 때 특히 유용할 것 같습니다.

변경 전후를 비교해서 실제로 개선됐는지 확인할 수 있으니까요.

이걸 CI까지 연결할 수 있다면 AI 기능도 회귀 테스트처럼 관리할 수 있을 것 같습니다.

물론 평가 데이터 관리가 귀찮을 것 같긴 합니다.

하지만 귀찮은건 보통 중요한 일입니다.. 하하

생각과 감정

WWDC26 AI 세션들을 보면 Apple이 모델 API만 던져주는게 아니라, 개발자가 실제로 앱에 넣고 운영할 수 있는 도구들을 같이 만들고 있다는 느낌이 듭니다.

Evaluations는 그중에서도 품질 관리 쪽입니다.

AI 기능을 앱의 핵심 기능으로 넣으려면 이 부분을 피할 수 없을 것 같습니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/298

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ Evaluations로 프롬프트 개선하기
✅ 감으로 수정하지 않기

이번 세션은 Evaluations를 사용해서 프롬프트를 점진적으로 개선하는 방법입니다.

AI 기능 만들 때 제일 위험한게 뭔지 아십니까.

“오 이번엔 답변 괜찮은데?” 하고 넘어가는 것입니다 ㅋㅋ

한두개 예제에서는 좋아보이는데, 다른 입력에서는 갑자기 이상해지는 경우가 많습니다. 프롬프트 한 줄 바꿨을 뿐인데 어느 부분이 좋아지고 어느 부분이 망가졌는지 알기 어렵습니다.

그래서 Evaluations가 필요하다고 합니다.

배운점

프롬프트도 테스트 대상이다

세션에서 제일 크게 느낀건 프롬프트도 코드처럼 다뤄야 한다는 점입니다.

앱 로직을 바꾸면 테스트를 돌리듯이, 프롬프트를 바꾸면 평가를 돌려야 합니다.

왜냐하면 프롬프트는 사실상 AI 기능의 로직이기 때문입니다.

“조금 더 친절하게 답해줘” 같은 문장 하나만 바꿔도 결과의 길이, 어투, 정확도, 도구 호출 방식이 달라질 수 있습니다.

Progressive Improvement

세션 제목에 있는 점진적 개선이라는 말이 좋았습니다.

AI 기능은 한 번에 완성하기 어렵습니다. 실제 사용자가 어떤 말을 할지도 모르고, 모델이 어떤 부분에서 실수할지도 처음엔 잘 모릅니다.

그래서 평가 데이터를 준비하고, 프롬프트를 조금씩 바꾸면서 결과가 실제로 좋아지는지 확인해야 합니다.

감으로 수정하지 말자.. 라는 느낌입니다.

평가 기준

평가를 하려면 기준이 필요합니다.

예를 들어 요약 기능이라면 핵심 정보를 빠뜨리지 않아야 하고, 추천 기능이라면 사용자의 조건을 어기면 안됩니다.

도구 호출이 들어가는 기능이라면 올바른 도구를 호출했는지도 봐야 합니다.

즉 “답변이 자연스럽다”만으로는 부족합니다.

생각과 감정

이 세션을 보면서 AI 기능도 결국 테스트 코드가 필요하구나 싶었습니다.

처음엔 모델이 알아서 잘해주겠지? 라고 생각할 수 있는데, 제품에 넣으려면 그렇게 못합니다.

특히 사용자가 많아질수록 엣지 케이스가 늘어나고, 그때마다 프롬프트를 감으로 만지면 언젠가 터질 것 같습니다.

Evaluations는 아직 낯설지만, AI 기능을 진지하게 넣으려면 꼭 봐야하는 흐름인 것 같습니다.

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/335

짧은인사, 하루의 사건, 나의 행동

ToDo
✅ fm CLI 보기
✅ Python SDK 맛보기

이번 세션은 fm CLI와 Python SDK로 AI 기반 스크립트를 만드는 내용입니다.

처음엔 iOS 세션 목록에 있어서 봤는데, 막상 내용은 앱 안에서만 쓰는 이야기가 아니라 개발자 도구 쪽에 더 가까웠습니다.

근데 저는 오히려 좋았습니다. 앱에 넣기 전에 터미널에서 먼저 모델을 써볼 수 있다는게 꽤 현실적이거든요.

후.. 요즘 개발도구들이 점점 똑똑해지고 있습니다. 이제 터미널도 AI를 먹는군요.

배운점

fm CLI

macOS 27에서 fm CLI를 통해 Apple Foundation Models를 터미널에서 사용할 수 있다고 합니다.

fm chat처럼 대화형으로 쓸 수도 있고, 셸 스크립트에 붙여서 문서 요약, 정보 추출, 콘텐츠 생성 같은 작업도 할 수 있습니다.

예를 들면 이미지 파일 이름이 IMG_1234 이런식으로 되어 있을 때, 이미지 내용을 보고 더 적절한 파일 이름을 만들어주는 예시가 나왔습니다.

이건 진짜 실생활 개발 자동화에 쓸 수 있을 것 같습니다.

저도 프로젝트 하다보면 파일 이름 정리, 로그 요약, README 초안 같은거 귀찮을 때 많은데 이런걸 로컬 모델로 처리할 수 있으면 꽤 편할듯요.

Python SDK

Python SDK도 나옵니다.

Swift 프레임워크에서 쓰는 온디바이스 모델을 Python에서도 사용할 수 있게 하는 방식입니다.

이건 데이터 작업이나 실험할 때 좋을 것 같습니다. Swift 앱에 바로 넣기 전에 Python으로 프롬프트를 테스트하거나, 간단한 스크립트를 돌려보는 식으로요.

모델 가용성을 확인하고, 몇 줄의 코드로 응답을 생성할 수 있다고 합니다.

앱 개발자 입장에서는?

저는 이 세션이 앱 개발과도 연결된다고 봅니다.

AI 기능을 앱에 넣기 전에 프롬프트를 먼저 실험해야 하는데, 매번 앱 빌드해서 확인하면 귀찮습니다.

fm CLI나 Python SDK를 쓰면 먼저 가볍게 실험하고, 어느정도 괜찮아졌을 때 Swift 코드로 옮길 수 있습니다.

이런 흐름이면 개발 속도가 꽤 빨라질 것 같습니다.

생각과 감정

이 세션은 화려한 앱 기능 소개는 아니지만, 개발자 입장에서 은근히 유용한 세션이었습니다.

저는 이런 도구 좋아합니다. 막 거창한 기능보다 매일 반복하는 귀찮은 일을 줄여주는게 진짜 체감이 크거든요.

아직 직접 써본건 아니지만, macOS에서 fm CLI가 안정적으로 동작하면 개인 프로젝트나 블로그 정리에도 써보고 싶습니다.

아 블로그 정리요? 지금 하고 있네요 ㅋㅋ

원문 세션
https://developer.apple.com/kr/videos/play/wwdc2026/334