온디바이스 AI는 기능이 아니라 작업으로 골라요

애플이 판단 순서를 개발자 문서에 적어놨어요

애플 개발자 문서에는 온디바이스 모델과 서버 모델 중 무엇을 쓸지 정하는 순서가 적혀 있어요. 기기 안에서 도는 모델로 먼저 만들어 평가 도구로 품질을 확인하고, 추론 능력이나 컨텍스트 윈도¹가 모자란다고 판단됐을 때만 서버로 보내라는 순서예요.

이 문장이 놓인 자리를 보면, 기기에서 처리할지 말지를 제품 전체를 두고 한 번에 정하라는 게 아니에요. 기능 하나를 실제로 만들어 재본 결과로 정하라고 벤더가 먼저 말하고 있어요. 판단 단위가 서비스가 아니라 작업이라는 뜻이에요.

---

같은 코드, 다른 한도

애플이 같은 문서에 붙여둔 비교표는 다섯 줄이에요. 두 모델 다 개인정보를 지키고, 오프라인 동작은 기기 쪽만 되고, 사용량은 기기 쪽이 무제한·서버 쪽이 하루 한도예요. 여러 단계로 생각하는 추론 모드는 서버에서만 돌아가고, 한 번에 넣을 수 있는 입력은 4K와 32K 토큰으로 8배 차이가 나요.

항목	기기 내 모델	서버 모델(Private Cloud Compute)
오프라인 동작	가능	불가능
사용량 제한	없음	사용자당 하루 한도
추론 모드	없음	3단계 지원
컨텍스트	4K 토큰	32K 토큰

세션을 만들 때 모델 객체 한 줄만 바꾸면 같은 프롬프트가 서버로 가요. 도구도 지시문도 그대로 넘어가고요. 그래서 개발팀이 실제로 답해야 하는 질문은 “온디바이스를 쓸까”가 아니라 “이 작업이 4K 안에서 끝나는가, 여러 단계로 따져야 하는가, 비행기 안에서도 돌아가야 하는가”로 내려와요.

안드로이드도 구조가 비슷해요. 구글은 ML Kit GenAI라는 묶음으로 요약, 맞춤법 교정, 문체 변환, 이미지 설명, 음성 인식, 자유 프롬프트를 제공하고, 이 기능들은 AICore²가 관리하는 공유 Gemini Nano 위에서 돌아가요. 구글이 문서에 적은 이점은 셋이에요. 입력과 추론과 출력이 기기 안에서 처리되고, 인터넷이 불안정해도 기능이 그대로 돌아가고, 호출마다 붙는 서버 비용이 없어요.

문서 아래쪽에는 한도가 적혀 있어요

같은 구글 문서를 끝까지 내려가면 이야기가 달라져요.

GenAI API 추론은 앱이 화면 맨 앞에 있을 때만 허용돼요. 포그라운드 서비스를 써도 막히고 BACKGROUND_USE_BLOCKED 오류가 돌아와요. 밤새 쌓인 알림을 백그라운드에서 요약해두는 설계는 이 한 줄에서 끝나요.

앱마다 추론 쿼터도 걸려 있어요. 짧은 시간에 요청을 몰아넣으면 ErrorCode.BUSY가 나고, 하루 단위 장시간 사용 한도를 넘기면 배터리 사용량 초과 오류가 따로 나와요. 기기에서 돌린다고 무제한인 건 아니고, 요금 청구서가 배터리와 쿼터로 바뀌는 거예요.

기기 목록도 확인이 필요해요. 2026년 9월 10일 기준 문서에 적힌 지원 기기는 픽셀 9~11 계열, 갤럭시 S25·S26과 폴더블, 그 밖의 제조사 플래그십이에요. 중저가 모델은 목록에 없어요. 게다가 기기마다 올라간 Gemini Nano 버전이 nano-v2, v3, v4로 갈리고, 구글은 같은 프롬프트가 버전에 따라 다른 출력을 낼 수 있으니 미리 평가하라고 안내해요. 한국어를 포함한 언어 지원도 기기 설정과 내려받은 모델에 따라 달라질 수 있다고 적혀 있어요.

브라우저는 문턱이 더 분명해요. 크롬 내장 AI를 쓰려면 크롬 프로필이 있는 볼륨에 22GB 이상 여유 공간이 있어야 하고, VRAM 4GB 초과 GPU이거나 RAM 16GB에 4코어 이상 CPU여야 해요. 최초 모델 다운로드에는 종량제가 아닌 연결이 필요하고, 내려받은 뒤 남은 공간이 10GB 아래로 떨어지면 모델이 지워져요. 안드로이드와 iOS의 크롬은 아직 지원되지 않고, Chrome 149 기준 문서가 입출력 언어로 밝힌 건 영어, 스페인어, 일본어, 독일어, 프랑스어예요. 한국어는 그 목록에 없어요.

한국 서비스라면 이 대목에서 계산이 한 번 꺾여요. 웹에서 기기 내 처리를 기본 경로로 잡는 순간, 기능을 켜볼 수 있는 사용자가 몇 퍼센트인지부터 세야 하거든요.

피크가 아니라 평평해진 뒤를 재야 해요

성능 비교는 조건이 더 까다로워요. 2026년 3월 공개되고 6월에 개정된 실측 논문이 참고가 돼요. 4비트로 압축한 Qwen 2.5 1.5B 하나를 네 종류 기기에 올리고, 258토큰짜리 같은 프롬프트를 1초 간격으로 20번 연속 던지면서 속도와 온도를 기록한 연구예요.

아이폰 16 Pro는 처음 두 번에서 초당 40.49토큰까지 나왔다가, 세 번째 반복부터 온도 상태가 올라가고, 17번째부터는 초당 23.67토큰에서 평평해졌어요. 피크 대비 41.5% 낮은 값이에요. 갤럭시 S24 울트라는 초당 12.21토큰에서 10.38토큰으로 15% 떨어졌는데, 이 완만한 곡선은 화면을 끄고 컨텍스트를 2,048토큰으로 묶고 프리필³ 조각을 128토큰으로 줄인 상태에서만 나왔어요. 논문 저자들은 이 수치가 앱 개발자의 기본 설정에서 나오는 동작이 아니라고 직접 못 박아뒀어요.

여기서 제품팀이 가져갈 기준이 하나 나와요. 연속으로 요청이 들어오는 기능이라면 계산에 넣을 값은 피크가 아니라 평평해진 뒤의 속도예요. 벤치마크 영상이나 발표 자료의 숫자는 대개 처음 몇 번의 값이거든요.

칩 사양에서 곧장 속도를 유추하는 것도 어긋나요. 같은 연구에서 40 TOPS⁴짜리 전용 NPU를 붙인 보드는 초당 6.914토큰을 냈어요. 답을 한 글자씩 만들어내는 디코드 구간이 연산이 아니라 메모리 대역폭에 묶이기 때문이에요. 대신 이 보드는 2W 아래에서 20번 내내 속도 편차가 거의 없었고 발열로 인한 성능 저하가 관측되지 않았어요. 500토큰 답변에 72초가 걸리니 대화형에는 못 쓰지만, 사용자가 기다리지 않는 야간 요약에는 오히려 맞는 성질이에요.

전력 수치를 다룰 때는 한 번 더 조심해야 해요. 이 논문도 토큰당 에너지 값을 플랫폼마다 다른 방식으로 쟀다고 밝히면서, 세 수치를 직접 비교하지 말라고 적어뒀어요. GPU 단위로 잰 값과 기기 전체로 잰 값과 화면을 끈 배터리 게이지로 추정한 값을 나란히 놓으면 비교가 성립하지 않아요.

안 쓰기로 정하는 것도 결론이에요

지금까지 확인한 조건을 작업 단위로 정리하면 이렇게 갈려요.

작업의 성격	기기에서 처리	서버로 보내기
입력 길이	짧은 메시지, 한 화면 분량	긴 문서, 누적된 대화
판단의 깊이	분류, 추출, 다듬기	여러 단계로 따지는 문제
연결 상태	오프라인이 요구사항일 때	상시 연결을 전제할 수 있을 때
실행 시점	사용자가 화면을 보고 있을 때	백그라운드, 예약 실행
빈도	간헐적 요청	연속·대량 처리

이 표에서 오른쪽으로 갈수록 기기 내 처리의 이점이 줄어요. 왼쪽에 해당하는 작업이 우리 서비스에 하나도 없다면, 결론은 “아직 도입하지 않는다”예요.

도입하는 쪽을 고르더라도 비용은 사라지지 않고 자리를 옮겨요. 모델 버전이 기기마다 다르니 버전별로 출력 품질을 평가해야 하고, 지원 기기가 아닌 사용자를 위한 서버 경로를 어차피 한 벌 더 만들어야 하고, 쿼터를 넘겼을 때 사용자에게 뭐라고 보여줄지도 설계해야 해요. 애플은 하루 한도에 가까워졌을 때 앱이 상태를 표시하도록 아예 API를 열어뒀을 정도예요.

개인정보와 비용에 대한 약속도 확인한 범위 안에서만 해야 해요. 기기에서 처리한다는 말은 그 작업의 입력이 밖으로 나가지 않는다는 뜻이지, 제품의 다른 경로가 함께 안전해진다는 뜻은 아니거든요. 삼성이 갤럭시 AI 설정에서 데이터를 기기에서 처리할지 클라우드에서 처리할지 사용자가 고르게 해둔 것도, 두 경로가 같은 제품 안에 나란히 있다는 걸 전제한 설계예요.

오스왈드의 시선

저는 온디바이스 AI에 매우 긍정적인 편이에요. 그 낙관의 근거를 이번에 자료로 다시 확인해보니, 기대할 만한 대목과 지금 당장 제품에 쓸 수 있는 대목이 같은 자리에 있지는 않았어요.

기대할 만한 건 방향이에요. 벤더가 기기와 서버를 같은 API 뒤에 놓고 한 줄로 갈아 끼우게 만들었다는 건, 앞으로 이 선택이 아키텍처 결정이 아니라 기능별 설정값에 가까워진다는 신호로 읽혀요. 전용 NPU가 2W 아래에서 스무 번 내내 흔들리지 않았다는 기록도, 지금 느린 게 원리의 한계라기보다 구성의 한계라는 쪽을 가리키고요.

반면 지금 제품 판단에 쓸 수 있는 건 훨씬 좁아요. 문서에 적힌 지원 기기 목록, 포그라운드 제약, 22GB 조건, 지원 언어 목록은 오늘 당장의 활성화율을 결정하는 숫자예요. 기술에 대한 낙관과 이번 분기 로드맵에 넣을지에 대한 판단은 분리해서 세우는 게 맞다고 봐요. 저 역시 이 글을 정리하면서 그 두 가지를 붙여놓고 있었다는 걸 알게 됐어요.

마치며

온디바이스 AI를 도입할지는 기술의 미래를 어떻게 보느냐로 정해지지 않아요. 우리 서비스의 어떤 작업이 4K 안에서 끝나는지, 사용자가 화면을 보고 있을 때 벌어지는 일인지, 지원 기기를 쓰는 사용자가 몇 퍼센트인지로 정해져요. 이 세 가지는 지금 벤더 문서와 공개된 실측 자료만으로도 확인할 수 있고요.

다만 여기 적은 숫자들은 특정 시점의 문서와 한 편의 실측에서 나온 값이에요. 지원 기기와 언어 목록은 업데이트마다 바뀌고, 실측은 모델 한 개와 프롬프트 한 개를 쓴 결과예요. 우리 서비스의 실제 작업으로 다시 재보는 단계는 어차피 남아 있어요.

---

💬 구독자님 서비스에서 기기 안으로 옮겨볼 만한 작업은 뭐가 있을까요? 입력 길이와 실행 시점만 적어주셔도 같이 따져볼게요.

📨 AI 기능 도입을 검토 중인 동료가 있다면, 이 글의 작업별 비교표만이라도 보내주세요.

---

참고자료 & 더 읽기

핵심 출처

• Apple Developer, “Adding server-side intelligence with Private Cloud Compute”, 2026. ··· 기기 모델과 서버 모델의 다섯 가지 차이와 전환 순서를 벤더가 직접 정리한 문서예요.
• Google for Developers, “Overview of the ML Kit GenAI APIs”, 2026년 9월 10일 갱신. ··· 지원 기능, 기기 목록, 앱별 쿼터, 포그라운드 제약이 한 페이지에 있어요.
• Chrome for Developers, “Get started with built-in AI”. ··· 저장공간, GPU, 연결, 지원 언어처럼 웹에서의 활성화율을 좌우하는 조건이 적혀 있어요.
• Tummalapalli, P. 외, “LLM Inference at the Edge: Mobile, NPU, and GPU Performance Efficiency Trade-offs Under Sustained Load”, arXiv:2603.23640, 2026. ··· 피크와 지속 성능이 얼마나 벌어지는지, 측정 조건을 어디까지 밝혀야 하는지를 함께 보여줘요.

배경 지식

• Apple Security Research, “Private Cloud Compute: A new frontier for AI privacy in the cloud”. ··· 서버로 보낸 요청을 어떻게 처리하고 지우는지 설계 근거가 정리돼 있어요.
• 삼성전자, “갤럭시 AI”. ··· 기기 처리와 클라우드 처리를 사용자가 고르게 한 제어 방식을 확인할 수 있어요.

관련 지난 호

• AI 반도체의 다음 전장은 메모리예요

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.

📝 용어 설명

각주

1. 컨텍스트 윈도: 모델이 한 번에 받아 처리할 수 있는 입력과 출력의 총량이에요. 4K는 약 4,000토큰을 뜻하고, 긴 문서를 통째로 넣으려면 이 값이 커야 해요. ↩

2. AICore: 안드로이드가 기기 안에서 생성형 모델을 실행하고 배포·업데이트를 관리하는 시스템 서비스예요. 앱마다 모델을 따로 내려받지 않고 하나를 나눠 쓰게 해줘요. ↩

3. 프리필과 디코드: 프리필은 입력 프롬프트를 한꺼번에 읽는 구간이고, 디코드는 답을 한 토큰씩 만들어내는 구간이에요. 프리필은 연산량에, 디코드는 메모리 대역폭에 주로 묶여요. ↩

4. TOPS: 초당 처리할 수 있는 연산 횟수를 조 단위로 나타낸 칩 사양이에요. 이상적인 조건의 최대치라서 실제 응답 속도를 그대로 예측하지는 못해요. ↩