안녕하세요, 카카오뱅크 AI모바일 팀에서 iOS를 개발하고 있는 Nick입니다. 매년 전 세계 개발자들의 관심이 집중되는 WWDC! 그 현장에 다녀왔는데요, 올해 WWDC25에서는 Liquid Glass UI와 Foundation Models framework라는 키워드가 특히 주목받았습니다.
이번 글에서는 WWDC25 현장에서 발표된 내용을 중심으로, 새롭게 공개된 Liquid Glass UI가 보여주는 UX 패러다임의 변화와 Foundation Models framework를 통한 온디바이스 AI 전략, 이 두 가지 핵심 주제를 중심으로 애플이 만들어가고 있는 기술적 전환의 방향을 함께 살펴보려 합니다.
WWDC25의 뜨거웠던 Keynote 발표 현장
6월 9일, 애플의 연례 개발자 컨퍼런스 WWDC(Worldwide Developers Conference)가 캘리포니아 쿠퍼티노의 애플파크에서 성대하게 열렸습니다. 전 세계 개발자들과 인플루언서로 가득 찬 현장에서는 새로운 OS 버전과 Liquid Glass UI(User Interface), 그리고 Apple Intelligence 등 애플의 다음 세대를 이끌 핵심 기술들이 공개되었습니다.
첫날 Keynote는 그야말로 축제 분위기였습니다. 애플 본사 인피니티 루프 내에서 진행된 키노트를 보기 위해 수많은 개발자들이 새벽부터 줄을 섰고, 저 역시 좋은 자리를 차지하기 위해 이른 시간부터 입장을 기다렸습니다. 행사는 애플 CEO 팀 쿡의 개회사로 시작됐습니다. 이후에는 미리 준비된 영상을 함께 시청하는 형식으로 이어졌는데요, 온﹒오프라인이 동시에 진행되는 만큼 전 세계 개발자들이 같은 순간을 함께 경험할 수 있도록 설계된 구성이라는 인상을 받았습니다. 형식은 다소 정제되어 있었지만, 각 발표가 나올 때마다 현장 곳곳에서 환호가 터져 나왔습니다. 특히 Swift Student Challenge에 참가한 학생들과 인플루언서들의 반응이 뜨거워 그 에너지가 행사장 전체로 퍼져나가는 것이 느껴졌습니다.
점심시간과 휴식 시간에는 WWDC25 현장에서 만난 한국 개발자분들과 인피니티 루프를 둘러보거나 현장을 찾은 유명 유튜버들과 함께 사진을 찍는 즐거움도 있었습니다. 또, 인피니티 루프에는 Download Station이 마련되어 이번 WWDC25에서 공개된 iOS 26 및 Xcode를 가장 먼저 체험해볼 수 있었습니다.
iOS 버전의 변화
이번 iOS 버전은 19가 아닌 26으로 껑충 뛰었습니다. 키노트에서는 왜 모든 플랫폼의 버전이 26으로 통일되었는지 구체적인 이유를 설명하지 않았지만, 이는 단순한 OS 업데이트를 넘어 애플 플랫폼 철학의 변화와 통합을 상징하는 결정으로 보입니다. WWDC25 키노트를 통해 애플이 어떤 변화를 꾀하고 있으며 무엇을 통합하고자 하는지 살펴볼 수 있었는데요, 이 가운데 흥미로운 점들도 발견할 수 있었습니다.
바로 AI(Apple Intelligence)와 긴밀히 통합된 Native App 기능들, 그리고 Liquid Glass UI의 도입입니다. 먼저 Apple Intelligence를 중심으로 한 다양한 기능 개선으로는 아이폰의 Message나 FaceTime에서의 실시간 번역, 카메라와 스크린샷에서의 정보 인식 및 분석, 그리고 Shortcuts 자동화 기능 강화 등이 대표적입니다. 해당 업데이트를 통해 애플은 ‘AI 기능이 일상에 자연스럽게 스며드는 경험’을 구체적으로 구현하고 있음을 확인할 수 있었습니다.
또한, Liquid Glass UI는 visionOS를 포함한 모든 OS를 아우르는 새로운 인터페이스로, 애플이 추구하는 통합의 상징적인 특징이라 할 수 있습니다. 실제로 키노트 내 OS 버전 발표 배경으로도 이 Liquid Glass UI가 활용된 점이 인상적이었는데요, 아래에서 좀 더 자세히 설명해보겠습니다.
Liquid Glass UI의 등장
이번 키노트의 핵심 주제 중 하나였던 Liquid Glass UI는 iOS 7 이후 가장 큰 UI/UX 변화로 평가됩니다. 단순히 시각적 형태가 바뀐 것이 아니라, 사용 맥락과 입력 반응성까지 통합한 완전히 새로운 인터랙션 패러다임이라 할 수 있습니다. 시각적인 효과로는 유리로 표현될 수 있는 빛의 반사와 굴절 등을 표현하고, 사용자의 입력 형태에 따라 물방울 형태처럼 움직이기도 하고 합쳐지기도 합니다. Liquid Glass UI 데모 영상을 보면 일상에서 볼 수 있는 빛의 현상들을 얼마나 공들여서 UI 요소로 표현하고 있는지 알 수 있습니다.
특히 visionOS 발표에서 엿볼 수 있었던 점으로는 자연적 현상을 그대로 Liquid Glass UI에 투영해 반영해 좀 더 현실적인 가상 현실을 표현하고, 사용자가 직접 만지는 듯한 경험을 제공한 것이었습니다. 이로써 애플이 현실과 가상의 현실을 허무는 데에 Liquid Glass UI를 적극적으로 활용할 것임을 느낄 수 있었습니다.
또 다른 흥미로운 점은 디자인 협업 도구인 Figma에도 Liquid Glass 효과를 구현하기 위한 기능이 새롭게 추가되었다는 것입니다. 특정 OS UI를 표현하기 위한 기능이 추가된 것은 상당히 이례적인 일로, 그만큼 Liquid Glass UI가 생태계 전반에서 주목받고 있음을 보여줍니다.
서비스 관점에서의 변화
그동안 대부분의 모바일 서비스들은 통일된 플랫폼 UI 위에서 비교적 비슷한 사용자 경험을 제공해 왔습니다. 하지만 이번 Liquid Glass UI의 등장은 획일화된 모바일 UI에서 벗어나 각 플랫폼만의 개성을 살릴 수 있는 전환점이 될 것으로 보입니다. 앞으로 어떤 서비스들이 새롭게 변화를 꾀하고, 획일화된 모바일 플랫폼 UI에서 벗어나 iOS만의 새로운 UI를 표현할지 지켜보면 재미있을 것 같습니다. 물론, UI/UX 디자이너와 개발자분들에게는 또 다른 도전 과제가 될 테지만 말이죠. 😅
현재 Xcode 26으로 빌드된 애플리케이션들은 기본 UI 컴포넌트에 Liquid Glass가 자동 적용됩니다. 향후 새롭게 발표될 디바이스에 대한 대응과 최신 Swift 버전 적용을 위해 언젠가 필수적으로 Xcode 26 이상으로 업데이트해야 하는 상황이 온다면, 필연적으로 Liquid Glass를 적용해야 할 것 같습니다.
현재 한시적으로 기존 UI를 유지할 수 있도록 옵션을 제공하고 있지만, 애석하게도 현재 Xcode 26 Beta 4에서는 iOS 빌드 시 기존 UI가 적용되지 않는 것으로 확인되었습니다. 아직까지 정식 버전에는 기존 UI가 작동할 것으로 기대합니다만, 멀지 않은 미래에 대응할 수 있도록 서비스를 운영 중인 애플리케이션들은 Liquid Glass UI에 대한 대응 방안이 필요해 보입니다. (관련 문서 link)
WWDC25 이후 Liquid Glass UI에 대한 설명과 활용, 운영되고 있는 서비스에 어떻게 적용할 수 있을지에 대한 주제로 애플의 Evangelist와 함께 기술 교류 세션을 진행했습니다. 카카오뱅크에서도 Liquid Glass UI를 포함하여 이번 WWDC25와 관련하여 내부 개발자들과 함께 의견을 나눌 수 있는 기술 공유 세션을 진행하였는데요, 당시 내부 iOS 개발자분들에게 반응이 매우 뜨거웠습니다.
Apple Foundation Models
작년 WWDC24에서 발표된 Apple Intelligence는 일상 업무를 돕는 다양한 생성형 모델로 구성되어 있습니다. 텍스트 작성﹒요약﹒이미지 생성﹒알림 관리 등, 사용자 중심의 기능들을 통합적으로 제공하죠. 무엇보다 애플이 강조하는 개인정보 보호 중심 설계를 바탕으로 구축된 점이 특징입니다.
1. Empower users with intelligent tools: We identify areas where AI can be used responsibly to create tools for addressing specific user needs. We respect how our users choose to use these tools to accomplish their goals.
2. Represent our users: We build deeply personal products with the goal of representing users around the globe authentically. We work continuously to avoid perpetuating stereotypes and systemic biases across our AI tools and models.
3. Design with care: We take precautions at every stage of our process, including design, model training, feature development, and quality evaluation to identify how our AI tools may be misused or lead to potential harm. We will continuously and proactively improve our AI tools with the help of user feedback.
4. Protect privacy: We protect our users' privacy with powerful on-device processing and groundbreaking infrastructure like Private Cloud Compute. We do not use our users' private personal data or user interactions when training our foundation models.
1. Foundation Models framework의 등장
이번 WWDC25에서는 Apple Intelligence의 핵심을 구성하는 Foundation Model에 직접 접근할 수 있는 새로운 개발자용 API, Foundation Models framework가 공개되었습니다. 이를 통해 개발자는 애플 생태계 안에서 온디바이스 AI 모델을 직접 호출하고 활용할 수 있게 되었습니다.
WWDC25 Introducing the foundation models framework라는 영상을 참고하면, 3가지 개념이 등장합니다. 바로 1) Private On-Device, 2) Readily available, 3) Built-in 입니다.
- Private On-Device: 사용자의 데이터가 기기 내에서만 처리되어, 외부 서버로 전송되지 않아 개인정보 보호를 극대화하는 방식을 의미합니다.
- Readily available: 해당 기능이나 서비스가 별도의 설치나 복잡한 설정 없이 바로 사용할 수 있도록 제공된다는 점을 강조합니다.
- Built-in: 애플 기기와 운영체제에 기본적으로 내장되어 있어, 추가 앱이나 서비스 없이도 즉시 활용할 수 있다는 것을 뜻합니다.
즉, 애플은 사용자의 개인정보를 안전하게 보호하면서도 누구나 쉽게 접근하고 사용할 수 있는 기능을 모든 기기에 기본적으로 탑재함으로써, 사용자 경험과 보안 모두를 강화하고 있습니다.
이때 Foundation Models framework로 접근할 수 있는 모델은 Apple Foundation Model로, 애플이 강조하는 핵심 가치 중 하나인 프라이버시 보호를 위해 제공되는 온디바이스(On-Device) AI 모델입니다. Apple Foundation Model은 약 30억 개의 파라미터를 가지고 있으며, 별도의 네트워크 통신 없이 모든 처리가 로컬 디바이스 내에서 수행된다는 점이 가장 큰 특징입니다. 물론, 다른 LLM과 비교했을 때 파라미터 수가 현저히 적다는 점에서 경쟁력은 떨어질 수 있지만, 비슷한 규모의 모델과 비교했을 때는 충분히 경쟁력 있는 모델로 보여집니다.
애플이 집중하고 있는 분야는 사용자들이 다양한 제품에서 소통, 업무, 자기 표현, 실질적인 작업을 할 수 있도록 지원하는 생성형 모델이었습니다. 이 과정에서 모델의 성능을 평가할 때 실제 사용자 경험과 밀접한 사람에 의한 평가 방법(Human Evaluation)에 중점을 두고 있음을 알 수 있었습니다. 예를 들어, 요약 기능 어댑터의 평가 방식을 살펴보면, 이메일, 메시지, 알림 등 각 서비스별 요구 사항이 미묘하게 다르기 때문에, 정확성과 정보 복원력을 높인 LoRA 어댑터를 기존 모델 위에 추가해 세밀하게 맞췄다고 합니다.
또한 출력 유해성 평가에서 다양한 온디바이스 및 서버 기반 AI 모델들의 유해 응답 위반율(유해 콘텐츠, 민감한 주제, 사실성에 대한 위반 응답 비율)을 비교했을 때, 온디바이스 모델 중 Apple On-Device는 7.5%로 가장 낮은 위반률을 보였으며, 서버 기반 모델에서는 Apple Server가 6.3%로 가장 우수한 결과를 기록했습니다. 반면, 다른 주요 모델들은 대부분 20%~50% 수준이었습니다. 이는 애플의 자체 모델이 민감한 주제, 허위 정보, 유해 콘텐츠 대응에서 경쟁 모델들보다 안전성과 신뢰성 면에서 우수함을 보여줍니다.
관련하여 더 자세한 내용은 Apple Machine Learning Research 사이트의 글을 참고 부탁드립니다.
2. 주요 기능: Structured Output & Tool Calling
Foundation Models framework가 제공하는 기능 중 가장 큰 특징은 Structured Output(구조화된 출력)과 Tool Calling(툴 호출) 기능을 기본 제공한다는 것입니다. 이는 OpenAI의 Structured Outputs, Function Calling 기능과 상당히 유사한 개념으로, 개발자가 원하는 형식(JSON 등)으로 결과를 받아 앱 내 자동화나 파이프라인 연결이 쉬워집니다.
또한, 입력/출력 단계에서는 Guardrails가 자동 적용되어 유해한 내용이나 부적절한 요청을 탐지﹒차단합니다. 해당 Guardrails은 커스텀하는 것이 불가한데, 이는 애플의 기본 핵심 원칙(프라이버시 보호)을 지키기 위한 것으로 보입니다. Guardrails에 의해 탐지된 내용은 에러 코드 형태로 반환되므로, 서비스별로 이에 대한 에러 핸들링 로직을 준비해야 합니다.
3. iOS 개발자 입장에서 본 활용 흐름
Apple Foundation Model은 공식 문서를 참고하면 비교적 간단하게 활용할 수 있습니다.
- 세션 초기화:
LanguageModelSession초기화로 input/output을 준비합니다.
- 응답 생성 옵션에서는
sampling과temperature옵션을 제공합니다.
- 시스템 구성요소: Guardrails 및 기본 Language Model 내장하고 있습니다.
- 커스텀 불가하며, input/output 건전성을 판단합니다.
- 어댑터 구성:
SystemLanguageModel.Adapter를 통해 특정 사용성에 맞게 구성 가능합니다.
- 질의 및 응답 처리: 동기 방식과 스트리밍 형식의 비동기 방식 모두 지원합니다.
- 구조화된 출력 또한 스트리밍 형식으로 수신 가능합니다.
import Playgrounds
import FoundationModels
final class MenuRecommendation {
let session: LanguageModelSession
init() {
let instructions = Instructions {
"""
너의 역할은 균형있는 식단을 추천해주는 거야.
응답은 항상 친절하게 대답해줘.
균형적인 식단을 고려해줘.
한문장으로 간단하게 요리 제목과 칼로리 정보를 요약해서 알려줘.
"""
}
session = LanguageModelSession(model: .default,
guardrails: .default,
tools: [],
instructions: instructions)
session.prewarm()
}
func generate(for prompt: String) async throws -> String {
let modelPrompt = Prompt {
"""
\(prompt)
"""
}
do {
let response = try await session.respond(to: modelPrompt)
return response.content
} catch {
print(error)
}
return ""
}
}
#Playground {
let test = MenuRecommendation()
let response = try await test.generate(for: "저녁 메뉴 추천해줘")
}
Fondation Models framework의 주요 특징
1. Foundation Models의 구조화된 출력
아래의 코드에서처럼 Foundation Models framework는 구조화된 출력을 지원합니다.
@Generable
struct Menu {
@Guide(description: "메뉴 이름")
var name: String
@Guide(description: "메뉴 칼로리")
var calorie: String
@Guide(description: "메뉴 조리법")
var recipe: String
}
final class MenuRecommendation {
let session: LanguageModelSession
init() {
....
}
func generate(for prompt: String) async throws -> Menu? {
let modelPrompt = Prompt {
"""
\(prompt)
"""
}
do {
let response = try await session.respond(to: modelPrompt,
generating: Menu.self,
includeSchemaInPrompt: false,
options: .init())
return response.content
} catch {
print(error)
}
return nil
}
}
@Generable 매크로를 통해 GenerationSchema, GeneratedContent, PartiallyGenerated를 자동으로 정의하는데요, 각각의 정의는 다음과 같습니다.
GenerationSchema: 객체의 속성과 설명을 정의GeneratedContent: 생성된 콘텐츠를 구조화할 수 있도록 정의PartiallyGenerated: 스트리밍 방식의 응답을 지원하기 위해 구조화된 콘텐츠를 정의
이와 같이 매크로를 통해 손쉽게 구조화된 출력을 쉽게 정의할 수도 있습니다.
2. Generable을 활용한 구조화된 Prompt 생성
@Generable 매크로는 구조체나 클래스를 Generable 프로토콜에 자동으로 적합(conform) 시켜주는 Swift 매크로입니다. 즉, @Generable을 선언하면 해당 타입은 별도의 수동 구현 없이 Prompt 생성에 필요한 구조화된 데이터 표현을 지원하게 됩니다.
흥미로운 점은, Generable 프로토콜의 상위 프로토콜 중 하나가 PromptRepresentable 이라는 것입니다.
PromptRepresentable은 Foundation Models framework에서 텍스트 프롬프트로 변환 가능한 객체를 정의하는 핵심 인터페이스로, 모델에 전달할 입력 데이터를 Swift 타입으로 안전하게 구성할 수 있게 해줍니다.
Foundation Models framework에서는 Swift의 기본형(Primitive) 타입(Bool, String, Int, Float 등)들이 이미 Generable 프로토콜을 따르도록 확장되어 있습니다. 따라서 이러한 타입들은 바로 Prompt 입력값으로 사용할 수 있습니다.
그렇다면 아래와 같은 의문이 생깁니다.
Prompt는 오직 Primitive 타입으로만 생성할 수 있을까? 🤔
즉, 서버 API에서 받아온 복잡한 구조체 형태의 데이터를 그대로 Prompt로 전달할 수는 없을까요?
아직 공식 문서에서는 @Generable을 활용한 구조화된 Prompt 생성 예제가 공개되지 않았지만, 이론적으로는 @Generable 매크로가 선언된 구조체는 내부적으로 PromptRepresentable을 준수하기 때문에 해당 구조체 전체를 하나의 Prompt 객체로 활용할 수 있습니다.
@Generable
struct Transactions: Codable {
let transactions: [Transaction]
}
@Generable
struct Transaction: Codable {
@Guide(description: "거래날짜")
let date: String
@Guide(description: "거래 종류")
let category: String
@Guide(description: "거래 설명")
let description: String
@Guide(description: "거래 금액")
let amount: Double
@Guide(description: "수입/지출 구분")
let type: TransactionType
}
@Generable
enum TransactionType: String, Codable {
case income
case expense
}
let transactions = Transactions(transactions: [
.init(date: "2025.01.01", category: "카드 결제", description: "라이언카드", amount: 10000, type: .expense),
.init(date: "2025.01.01", category: "입금", description: "ATM", amount: 230000, type: .income),
.init(date: "2025.01.01", category: "이체", description: "카카오뱅크", amount: 10000, type: .expense)
])
final class TransactionSummarizer {
let session: LanguageModelSession
init() {
....
}
func generate(for prompt: Transactions) async throws -> String? {
let modelPrompt = Prompt {
"""
\(prompt)
"""
}
do {
let response = try await session.respond(to: modelPrompt)
return response.content
} catch {
print(error)
}
return nil
}
}
▿ Prompt
▿ components : 1 element
▿ 0 : Component
▿ text : Text
- value : "Transactions(transactions: [FoundationModelPlaygound.Transaction(date: \"2025.01.01\", category: \"카드 결제\", description: \"xx카드\", amount: 10000.0, type: FoundationModelPlaygound.TransactionType.income), FoundationModelPlaygound.Transaction(date: \"2025.01.01\", category: \"입금\", description: \"ATM\", amount: 230000.0, type: FoundationModelPlaygound.TransactionType.income), FoundationModelPlaygound.Transaction(date: \"2025.01.01\", category: \"이체\", description: \"카카오뱅크\", amount: 10000.0, type: FoundationModelPlaygound.TransactionType.expense)])"
Prompt는 @Generable 매크로를 통해 정의한 구조체로도 생성할 수 있습니다. 다만, 이때 Generable이 가진 GenerationSchema 정보가 실제 모델 입력(Prompt Representation)에까지 전달되는지는 공식 문서에서 명확히 확인되지 않았습니다. 그럼에도 구조체의 프로퍼티 이름이 그 값의 의미를 충분히 설명할 수 있다면 Generable로 정의된 타입 역시 Prompt 생성에 활용 가능할 것으로 보입니다.
3. Tool Calling의 활용
Tool Calling은 모델이 외부 함수나 시스템 리소스에 접근해 실제 동작을 수행할 수 있도록 하는 기능입니다.
모델은 Prompt를 분석해 어떤 Tool을 사용할지 판단하고, 그에 맞는 Arguments를 자동으로 생성합니다. 이후 해당 Tool을 호출해 결과를 얻고, 이를 바탕으로 최종 응답을 구성하거나 다음 Tool 호출을 이어갑니다.
다만 복잡한 추론 과정을 거치거나 여러 Tool을 순차적으로 호출해야 하는 경우, Prompt를 단계별로 분리해 설계하는 것이 더 효과적입니다.
struct ContactsTool: Tool {
let name = "getContact"
let description = "Find contacts by name"
@Generable
struct Arguments {
var name: String
}
@Generable()
struct Contact {
var name: String
var mobile: String
}
func call(arguments: Arguments) async throws -> [Contact] {
return searchContacts(with: arguments.name)
}
func searchContacts(with name: String) -> [Contact] {
let contacts: [Contact] = [
Contact(name: "rhino", mobile: "010-333-4321"),
Contact(name: "nick", mobile: "010-1234-1234"),
Contact(name: "kevin", mobile: "010-2222-3333"),
Contact(name: "sally", mobile: "010-3333-4444"),
Contact(name: "alex", mobile: "010-1234-5678"),
Contact(name: "bason", mobile: "010-7777-8888"),
]
let result = contacts.filter { $0.name == name }
print("찾은 연락처: \(result)")
return result
}
}
struct CallingTool: Tool {
let name = "call"
let description = "Call the mobile number"
@Generable
struct Arguments {
@Guide(description: "이름")
var name: String
@Guide(description: "전화번호")
var mobile: String
}
func call(arguments: Arguments) async throws -> String {
print("전화 거는 중 \(arguments)")
return "\(arguments.name) \(arguments.mobile)로 전화 거는 중."
}
}
final class CallingTest {
let session: LanguageModelSession
init() {
let instructions = Instructions {
"""
"""
}
session = LanguageModelSession(model: .default,
guardrails: .default,
tools: [ContactsTool(),
CallingTool()],
instructions: instructions)
session.prewarm()
}
func generate(for prompt: String) async throws -> String? {
let modelPrompt = Prompt {
"""
\(prompt)
전화 연결중일때는 이름과 모바일 번호도 같이 출력해.
"""
}
do {
let response = try await session.respond(to: modelPrompt)
return response.content
} catch {
print(error)
}
return nil
}
}
#Playground {
let test = CallingTest()
let response = try await test.generate(for: "alex 연락처로 전화해줘")
}
4. Transcript로 입출력 기록 관리
LanguageModelSession 은 모델과의 모든 입출력 기록을 Transcript 형태로 관리합니다. 이때 Transcript에는 Instructions, Prompt, 모델의 응답, 그리고 Tool Calling으로 인한 실행 결과까지 모두 포함됩니다.
이렇게 축적된 Transcript는 세션 간 Context 유지의 핵심 역할을 합니다. 새로운 LanguageModelSession을 생성할 때 이전 세션의 Transcript를 함께 전달하면 모델은 이전 대화의 흐름을 그대로 이어받을 수 있습니다. 반대로 Context Window Size(4,096 토큰) 를 초과할 가능성이 있다면, 일부 Transcript만 선택적으로 전달해 효율적으로 관리할 수도 있습니다.
Context 크기를 초과하면 LanguageModelError.exceededContextWindowSize 오류가 발생합니다. 따라서 Transcript는 단순한 기록을 넘어 한정된 컨텍스트 자원을 효과적으로 운용하기 위한 매커니즘으로 볼 수 있습니다.
마치며
이번 WWDC25를 통해 애플은 ‘AI’와 ‘UX’ 두 영역에서 다시 한번 새로운 기준점을 제시했습니다. 앞으로 Apple이 제시하는 기술 철학이 모바일 플랫폼 시장과 개발 생태계 전반에 어떤 변화를 만들어갈지 그 흐름이 무척 기대됩니다.
이번 WWDC25는 단순히 새로운 OS와 기술, 툴을 공개하는 자리를 넘어, 애플이 앞으로 그리고자 하는 기술 철학과 비전을 더욱 선명하게 드러낸 행사였습니다.
Liquid Glass UI는 자연현상인 ‘빛의 굴절’을 UI에 적용해, 기기와 사용자 사이의 경계를 허무는 전혀 새로운 인터랙션을 선보였습니다. 사용자는 화면 속 정보를 마치 실제로 만지고 움직이는 듯한 몰입감을 경험할 수 있었고, 이는 단순한 시각적 효과를 넘어 ‘사용자 중심 기술’이라는 애플의 철학이 진화한 결과로 볼 수 있습니다.
또한, Foundation Models framework의 공개는 애플이 지향하는 AI의 방향성을 명확히 보여주었습니다. 구글이나 OpenAI가 대규모 데이터와 클라우드 기반 AI에 주력하는 것과 달리, 애플은 온디바이스 기반의 프라이버시 보호형 AI, 그리고 iOS 앱 생태계와의 자연스러운 통합에 초점을 맞추고 있습니다. 개발자는 별도의 외부 도구 없이도 AI 기능을 앱에 직접 임베딩할 수 있고, Tool Calling 기능을 통해 네이티브 앱과 유기적으로 연결된 AI 경험을 구현할 수 있게 되었습니다.
이번 WWDC25를 통해 애플은 ‘AI’와 ‘UX’ 두 영역에서 다시 한번 새로운 기준점을 제시했다고 생각합니다. 카카오뱅크 iOS 개발자로서, 이번 컨퍼런스에서 직접 보고 경험한 Liquid Glass UI와 Foundation Models는 앞으로 카카오뱅크 앱의 새로운 UI와 AI 기능 구현에 많은 영감을 주었고, 실제 현업에 적용해보기 위해 여러 시행착오와 학습을 거치면서 흥미로운 도전의 시간을 보낼 수 있었습니다. 지난 5월에 있었던 WWDC25지만, 이후에도 꾸준히 공부하며 얻은 인사이트를 최대한 iOS 개발자 시각에서 글에 담아보았습니다.
앞으로도 애플이 출시하는 다양한 기술에 많은 관심을 가지고, 개발자로서 카카오뱅크 앱에 어떻게 적용할 수 있을지 계속 고민해보고 싶습니다. 읽어주셔서 감사합니다.
