개발자 1,900명이 "기본값은 기기 안"이라고 찍은 글 — 앱마다 AI를 구름에 빌리는 버릇

발행 2026-09-20 · 분류 AI 실전편 · 난이도 중급 · 읽는 시간 6분

기능 하나를 추가하려고 앱에 외부 AI API 호출을 한 줄 박아 넣은 적 있으신가요. 그 한 줄이 서버 다운과 카드 만료에 앱이 함께 죽는 순간을 예약하는 행위라면요.

해외 개발자 커뮤니티 HackerNews에 올해 5월 올라와 1,900표 넘게 밀려 올라간 글이 있습니다. 요지는 단순합니다 — 기기에 이미 있는 칩을 놀리면서, 수천 킬로미터 밖 서버의 답변을 기다리는 건 구조가 아니라 습관의 문제라는 겁니다.

오늘은 이 주장의 뼈대만 떼어내고, 아이폰·맥에서 실제로 공짜로 쓸 수 있는 온디바이스 모델과 그 한계, 그리고 커뮤니티에서 가장 뜨겁게 붙었던 반론까지 한 잔에 따라드립니다.

30초 요약

1. 무엇이 터졌나

글의 출발점은 요즘 앱 개발의 습관입니다. AI 기능이 유행하니 검증도 없이 OpenAI든 Anthropic든 호출부터 붙이는 경우를 저자는 문제의 근원으로 지목합니다. 기능이 쓸모 있느냐 없느냐를 다투기 전에, 앱이 남의 서버에 목을 매는 구조 자체가 됐다는 지적이 핵심입니다.

저자는 이걸 " UX 기능을 하나 만들었는데 배포 시스템 하나를 추가로 소유하게 된 격"이라고 쏘아붙입니다. 네트워크가 느리면 기능이 느리고, 공급사 속도 제한에 걸리고, 결제 수단이 만료되면 기능이 죽고, 내 계정 상태까지 스택에 얽힙니다.

두 번째 칼날은 개인정보입니다. 의도가 아무리 좋아도 사용자 텍스트가 제3자 서버로 스트리밍되는 순간 보관 기간, 동의 절차, 감사, 유출 대응, 정부 요구, 학습 활용 여부를 문서로 답해야 하는 신세가 됩니다. 글의 예시는 자체 뉴스 리더 앱의 요약 기능을 애플의 기기 내장 모델 API로만 구현한 사례입니다. 서버 경유도, 프롬프트 로그도, 공급사 계정 등록도 필요 없는 구조를 실제로 굴리고 있다는 이야기입니다.

참고로 이 글은 2025년 12월 말에 처음 게시됐고, 2026년 5월 10일 HackerNews 앞쪽에 다시 올라 1,903표와 댓글 749개를 모았습니다. 1차 글은 1,100자 남짓한 짧은 에세이고, 폭발한 쪽은 댓글쪽이었습니다.

2. 왜 대단한 얘기인가 — "로컬은 멍청하다"의 반전

온디바이스 AI 반대 논리는 늘 하나로 수렴합니다. 구름 모델보다 똑똑하지 않다는 것. 그런데 댓글창에서 가장 많은 공감을 받은 반박은 이 논리의 논점을 비눕니다. 대부분의 앱 기능은 셰익스피어를 쓰거나 변호사 시험을 통과하는 지능을 요구하지 않습니다. 요약, 분류, 추출, 다시 쓰기, 정규화 — 이 다섯 개만 안정적으로 하면 기능은 완성됩니다.

그리고 이 영역은 기기 내장 모델의 설계 목표와 정확히 겹칩니다. 애플이 공개한 기술 문서를 직접 열어보면, 기기에 올라가는 언어 모델은 약 30억 파라미터에 4비트 미만 양자화를 얹어 평균 약 3.7비트/가중치로 압축돼 동작합니다. 요약처럼 형식이 까다로운 작업에는 수백 MB 이하의 어댑터를 별도로 물려 품질을 보완합니다. 애플은 이 모델의 용도를 "세계 지식을 자랑하는 챗봇이 아니라 요약·추출·텍스트 이해 같은 앱 기능"으로 못 박아 설명하고 있습니다.

즉 "로컬 모델은 뭘 못 해"라는 반론은 1,750억 파라급 두뇌를 기대할 때만 성립하고, 글이 말한 기능 집합에는 애초에 닿지 않습니다.

3. 바로 써먹기 — 내 앱에서부터 나누기

① 작업 크기부터 재는 게 1단계

댓글창에 실제 사례가 나왔습니다. 사용자 자유 문장에서 가격·날짜·통화 같은 필드를 뽑아내는 iOS 앱을 만드는 개발자가, 구름 모델·단순 파서·기기 내장 모델 세 갈래를 견준 끝에 10억 파라미터짜리 공개 모델로 오타 교정까지 해결한 뒤, "첫 반사는 구름 모델이었다"고 스스로 인정했습니다. 기능 설계 후 "이 작업은 요약급인가, 추론급인가"를 먼저 자르면 의존성 절반은 저절로 사라집니다.

② 개발자가 곧바로 쓸 수 있는 창구

아이폰·아이패드·맥 개발자라면 별도 구독 없이 시스템 내장 모델에 접근하는 프레임워크가 열려 있습니다. 요약·추출·구조화된 출력까지 몇 줄의 Swift로 부를 수 있고, 기기 안에서만 돈이 씁니다. 애플 개발자 문서와 기술 리포트는 아래 '바로 가기'에 붙였습니다.

③ 작업 분배 기준표

4. 해외 반응 쟁점

장비 문턱 논쟁. 가장 매서운 반론은 "실사용급 지능은 로컬로 살 수 없다"는 쪽에서 나왔습니다. 한 개발자는 최상급 개인용 장비 구성이 1만 달러에서 3만 달러이고 팬 소음과 전력까지 감수해야 한다고 실측을 들이밀었습니다. 반박은 간단했습니다 — 그건 1,750억급을 집에 올리겠다는 얘기이고, 글의 주장은 30억급으로 되는 일 얘기를 하고 있다는 것. 같은 댓글창에서 "요약·분류엔 로컬이 충분히 훌륭하다"는 재반박이 가장 많은 공감을 받았습니다.

사용자 심리 논쟁. 또 다른 쟁점은 기기 점유율입니다. 브라우저가 사용자 동의 없이 4GB짜리 모델을 까는 사건이 한동안 화제였다는 지적과 함께, "차라리 유틸 하나가 남의 API를 빌리는 게 낫지 내 폰에 모델을 내려받긴 싫다"는 사용자 반응이 대변됐습니다. 여기서 저자 편을 드는 쪽도 "결국 OS 수준 기능이어야 산다"는 전제를 달았습니다.

배터리·저장공간 논쟁. 전담 칩 없이 일반 연산 자원으로 돌리면 배터리가 급격히 닳는다는 지적, 기기 내장 모델이 작게 쪼개진 데다 짧은 컨텍스트 창에 묶여 있다는 한계론도 계속됐습니다. 애플 기술 문서가 밝힌 압축 수치(4비트 미만, 평균 약 3.7비트/가중치)는 이 한계를 정면으로 인정한 다음 그 안에서 성능 품질을 되찾는 방법론이었습니다.

5. 마시기 전 주의

• 글은 에세이지 성능 데이터 시트가 아닙니다. "다 로컬로"가 아니라 "기본값을 로컬로 두고 예외만 빌리자"는 방향 제시로 읽어야 합니다.
• 댓글의 장비 금액(1만~3만 달러)은 특정 모델·특정 구성의 개인 실측입니다. 모든 작업에 일반화하지 마세요.
• 기기 내장 모델은 영어 기준 성능 평가가 중심이고, 한국어 품질은 직접 테스트해 봐야 합니다. 컨텍스트 창도 구름 대비 짧습니다.
• 개인정보 규정이 사라지는 건 아닙니다. 다만 서버 보관·공급사 약정 관련 항목 자체가 사라져 문서 부담이 줄어드는 데 이점이 있습니다.

바로 가기

• 1차 글 — 로컬 AI가 표준이어야 한다
• 기기 내장 모델 기술 리포트 (약 30억 파라미터·양자화 수치)
• 개발자용 온디바이스 모델 API 문서