애플 Gemini AI 도구 이야기는 처음엔 WWDC 뉴스 중 하나처럼 보였다. 새 OS, 새 API, 새 프레임워크가 한꺼번에 쏟아지는 시즌이라 그냥 “애플도 AI 개발자 기능을 더 붙였구나” 정도로 넘기기 쉽다. 그런데 이번 흐름은 조금 다르게 봐야 한다.
핵심은 모델 성능 자랑보다 비용 구조다. Apple Newsroom 발표는 개발자가 Foundation Models 프레임워크로 앱 안에 지능형 기능을 더 쉽게 넣을 수 있다고 설명했고, Apple Developer 문서는 이 기능을 앱 개발자가 직접 호출할 수 있는 개발 표면으로 다룬다. 여기에 MacRumors와 TechCrunch는 애플의 새 AI 아키텍처가 Gemini 계열 모델과 개발자 비용 절감 논리까지 엮인다고 봤다.
그래서 나는 이번 뉴스를 “애플이 Gemini를 썼다”보다 “작은 앱 팀이 AI 기능을 실험하는 단가가 내려간다”는 쪽으로 읽었다. 이게 맞다면, 영향은 Siri 뉴스보다 개발팀 백로그에서 먼저 보일 가능성이 크다.
이전에 Google AI Studio로 안드로이드 앱을 만드는 흐름을 보면서도 비슷한 생각을 했다. AI 기능이 어려워서 못 넣는 시대에서, 넣은 뒤의 비용과 운영을 계산해야 하는 시대로 넘어가고 있다. 이번 애플 발표는 그 계산식에 iOS 생태계라는 큰 변수를 추가했다.
이번 발표에서 중요한 건 모델 이름이 아니다
개발자에게 열린 표면이 넓어졌다
애플 발표를 보면 App Intents, Foundation Models, Visual Intelligence, Xcode 쪽 개발 도구가 같이 움직인다. 이런 발표는 보통 마케팅 문장으로 읽히기 쉬운데, 개발자 입장에서는 “어디까지 제품 코드에서 호출 가능한가”가 더 중요하다. 데모 영상에서만 멋진 AI와, 실제 앱 기능으로 묶을 수 있는 AI는 완전히 다르다.
Foundation Models 프레임워크가 의미 있는 이유도 여기 있다. 앱 안에서 요약, 분류, 간단한 생성, 사용자 맥락 기반 보조 기능을 만들 때 매번 외부 API 서버를 붙이지 않아도 되는 구간이 생긴다. 물론 모든 작업을 온디바이스 모델로 처리할 수 있다는 뜻은 아니다. 하지만 “이 정도 기능은 기기 안에서 먼저 해보자”는 선택지가 공식 개발 표면으로 들어오면 실험 속도가 달라진다.
작은 팀은 보통 AI 기능을 넣기 전에 세 가지를 동시에 걱정한다. API 비용, 개인정보 처리, 응답 지연이다. 모델 품질도 중요하지만, 실제로는 이 세 가지 때문에 기능이 미뤄지는 경우가 많다. 프로토타입은 금방 나오는데 운영 단가가 감당 안 되거나, 사용자 데이터를 외부로 보내는 설계가 찝찝하거나, 모바일 앱에서 네트워크 왕복이 UX를 망치는 식이다.
Gemini 보도는 클라우드 경로를 보여준다
MacRumors와 TechCrunch가 Gemini 이야기를 붙인 지점은 그래서 흥미롭다. 애플이 모든 AI를 자체 온디바이스 모델로만 해결하려는 게 아니라, 필요할 때 외부 대형 모델 경로를 섞는 구조로 가고 있다는 해석이 가능하기 때문이다. 사용자는 그냥 “AI 기능”을 보지만, 개발자 입장에서는 로컬 모델, 애플 프레임워크, 외부 모델, 자체 서버가 역할을 나눠 갖는 구조가 된다.
이건 꽤 현실적인 방향이다. 모든 기능에 최고급 모델을 쓰면 비용이 터진다. 반대로 모든 기능을 작은 온디바이스 모델로만 처리하면 품질 한계가 온다. 결국 제품은 라우팅 문제가 된다. 이 요청은 기기 안에서 처리할지, 우리 서버에서 처리할지, 외부 모델로 보낼지, 아예 AI를 쓰지 않을지 정해야 한다.
나는 이 지점이 이번 발표의 진짜 개발자 포인트라고 본다. AI 기능을 붙이는 일이 “모델 하나 고르기”에서 “비용과 개인정보와 품질을 나눠 배치하기”로 바뀌고 있다.
작은 팀에게 제일 큰 변화는 실험 비용이다
기능 하나를 만들 때 들어가는 고정비가 줄어든다
작은 앱 팀에서 AI 기능을 붙이려면 생각보다 잡일이 많다. API 키를 발급하고, 서버를 하나 만들고, rate limit을 잡고, 프롬프트 버전을 관리하고, 실패했을 때 fallback을 만들고, 로그에 개인정보가 남지 않게 막아야 한다. 이건 기능 자체보다 주변 운영이 더 무거운 경우가 많다.
만약 Foundation Models 프레임워크로 일부 기능을 앱 안에서 바로 실험할 수 있다면, 최소 실험 단위가 작아진다. 예를 들어 노트 앱의 태그 추천, 사진 정리 앱의 간단한 분류, 생산성 앱의 일정 문장 정리, 쇼핑 앱의 리뷰 요약 같은 기능은 처음부터 거대한 AI 백엔드를 만들 필요가 줄어든다.
이게 중요한 이유는 성공 확률 때문이다. AI 기능은 만들어 보기 전에는 사용자가 진짜 좋아할지 모른다. 내부 데모는 멋져도 실제 사용자 행동은 차갑다. 작은 팀은 여기서 큰 돈을 태우면 안 된다. 싸게 만들고, 빨리 붙이고, 로그를 보고, 안 먹히면 빼야 한다. 애플 쪽 개발 표면이 넓어지면 이 실험 루프가 조금 가벼워질 수 있다.
비용은 API 가격만이 아니다
AI 비용을 말할 때 대부분 토큰 가격만 본다. 근데 제품 팀에서 더 아픈 비용은 운영 복잡도다. 외부 모델 API를 쓰면 결제, 장애 대응, 데이터 보관, 모델 변경, 지역별 규정, SLA, 고객 문의까지 따라온다. 토큰 단가가 싸져도 이 운영 비용은 남는다.
온디바이스 처리가 들어오면 일부 기능은 이 비용을 피해갈 수 있다. 네트워크 호출이 줄고, 민감한 입력을 외부로 보내지 않아도 되고, 서버 장애와 분리할 수 있다. 반대로 모델 업데이트, 품질 편차, 기기 성능 차이는 새로 봐야 한다. 공짜 점심은 아니다. 다만 선택지가 늘어난다.
이 선택지가 작은 팀에게는 꽤 크다. 대기업은 자체 AI 플랫폼을 만들 수 있다. 작은 팀은 그럴 시간이 없다. 그래서 플랫폼이 제공하는 기본 AI 경로가 좋아질수록, 작은 팀은 “AI 플랫폼 만들기” 대신 “사용자 문제 고르기”에 더 집중할 수 있다.
이제 설계 질문이 바뀐다
먼저 로컬에서 가능한지 본다
앞으로 iOS 앱에서 AI 기능을 설계할 때 첫 질문은 “어떤 모델을 쓸까”가 아니라 “이 기능은 로컬에서 충분한가”가 될 가능성이 크다. 사용자가 입력한 짧은 문장을 정리하거나, 앱 내부 데이터를 분류하거나, UI에서 다음 행동을 추천하는 정도라면 온디바이스 경로부터 보는 게 자연스럽다.
로컬 처리가 충분하면 좋은 점이 많다. 빠르고, 비용 예측이 쉽고, 개인정보 설명도 단순해진다. 물론 품질이 부족하면 바로 티가 난다. 그래서 나는 로컬 모델을 만능으로 보는 것보다, 제품의 첫 번째 필터로 보는 쪽이 맞다고 생각한다.
부족한 부분만 외부 모델로 보낸다
반대로 긴 문서 분석, 복잡한 추론, 멀티모달 입력, 도메인 지식이 필요한 작업은 외부 모델이 여전히 필요할 수 있다. 여기서 Gemini 같은 대형 모델 경로가 의미를 갖는다. 전부 외부로 보내는 게 아니라, 정말 필요한 요청만 보내는 구조가 된다.
이 구조를 잘 짜면 비용과 품질을 동시에 잡을 수 있다. 대충 이런 감각이다.
- 빠르고 민감한 작업은 온디바이스로 둔다.
- 품질이 중요한 생성 작업은 외부 모델로 보낸다.
- 반복 작업은 캐시하거나 템플릿화한다.
- 실패해도 제품 핵심 흐름이 멈추지 않게 fallback을 둔다.
- 사용자가 AI 결과를 수정할 수 있는 UI를 남긴다.
이건 거창한 AI 아키텍처라기보다 제품 운영 감각에 가깝다. AI가 들어갔다고 해서 모든 화면을 마법처럼 만들 필요는 없다. 오히려 작은 기능을 정확히 골라서, 비용이 작고 실패해도 안전한 곳부터 넣는 게 낫다.
개발자가 확인해야 할 체크포인트
API보다 사용자 흐름을 먼저 본다
새 프레임워크가 나오면 문서부터 파고 싶은 마음이 든다. 나도 그렇다. 근데 이번 건 API 목록보다 사용자 흐름을 먼저 보는 게 좋다. 어떤 입력이 들어오고, 어떤 출력을 보여주고, 틀렸을 때 사용자가 어떻게 고칠 수 있는지를 먼저 정해야 한다.
AI 기능이 실패하는 가장 흔한 패턴은 “가능한 것”을 먼저 붙이는 것이다. 요약이 가능하니까 요약 버튼을 넣고, 추천이 가능하니까 추천 영역을 만든다. 그런데 사용자는 그 기능이 왜 필요한지 모른다. 작은 팀은 특히 이 함정에 빠지면 안 된다. 개발 비용이 내려가면 기능을 더 쉽게 넣게 되는데, 그만큼 빼는 기준도 필요하다.
개인정보 설명이 제품 문구가 된다
온디바이스 AI가 늘어나면 개인정보 설명도 바뀐다. “이 기능은 기기 안에서 처리됩니다”라는 문장은 단순한 법무 문구가 아니라 제품 신뢰 문구가 된다. 반대로 외부 모델을 쓰는 기능은 어떤 데이터가 나가는지 더 명확히 설명해야 한다.
여기서 애플 생태계의 장점이 나온다. 사용자들은 이미 애플의 프라이버시 메시지에 익숙하다. 개발자가 이 흐름을 잘 타면 AI 기능을 더 부담 없이 소개할 수 있다. 하지만 그만큼 실제 구현도 정직해야 한다. 로컬 처리라고 말해놓고 서버로 보내면 신뢰가 한 번에 깨진다.
측정 지표를 미리 정한다
AI 기능은 배포하고 끝이 아니다. 최소한 세 가지는 봐야 한다. 사용자가 기능을 실제로 누르는지, 결과를 수정하는지, 기능 때문에 핵심 행동이 빨라지는지. 이 지표가 없으면 그냥 멋진 데모가 된다.
작은 팀은 특히 “AI 기능 사용률”만 보면 안 된다. 사용자가 호기심에 한 번 누른 건 성공이 아니다. 반복 사용, 수정률 감소, 작업 완료 시간 감소, 문의 감소처럼 제품에 연결되는 지표를 봐야 한다. 그래야 이 기능을 계속 키울지, 로컬 모델로 충분한지, 외부 모델 비용을 더 써도 되는지 판단할 수 있다.
내가 보는 실제 의미
이번 애플 Gemini AI 도구 흐름은 거대한 AI 전쟁 뉴스이기도 하지만, 작은 개발팀에게는 더 실용적인 신호다. AI 기능을 넣기 위한 초기 비용이 내려가고, 온디바이스와 클라우드 모델을 나눠 쓰는 설계가 점점 기본값이 된다.
그래서 나는 당장 모든 iOS 앱이 AI 앱으로 바뀐다고 보지는 않는다. 오히려 반대다. 티 나지 않는 작은 AI 기능이 늘어날 것이다. 입력을 줄이고, 분류를 돕고, 요약을 붙이고, 다음 행동을 추천하는 식이다. 사용자는 AI라는 말을 의식하지 않을 수도 있다. 그냥 앱이 조금 덜 귀찮아지는 쪽이다.
개발자 입장에서는 이게 더 중요하다. AI가 눈에 띄는 기능일수록 실패도 눈에 띈다. 반대로 사용자의 반복 작업을 조용히 줄이는 기능은 오래 간다. 애플이 개발자에게 더 낮은 비용의 AI 표면을 열어준다면, 좋은 팀은 거기서 화려한 데모보다 덜 귀찮은 제품 경험을 만들 것이다.
결국 이번 뉴스의 질문은 하나로 줄어든다. “우리 앱에서 서버까지 보내지 않아도 되는 AI 작업은 무엇인가.” 이 질문에 답할 수 있는 팀이 먼저 비용을 줄이고, 더 자주 실험하고, 실패해도 덜 다치는 방식으로 AI 기능을 쌓아갈 것 같다.