---
title: "로컬 AI를 기본값으로 삼아야 하는 이유"
published: 2026-05-10T17:19:28.000Z
canonical: https://jeff.news/article/2333
---
# 로컬 AI를 기본값으로 삼아야 하는 이유

앱에 AI 기능을 붙일 때 무조건 OpenAI나 Anthropic API부터 호출하는 습관을 비판한 글이다. 글쓴이는 요약, 분류, 추출, 재작성 같은 작업은 기기 안의 로컬 모델로도 충분하고, 이 편이 프라이버시·비용·장애 대응 면에서 훨씬 낫다고 주장한다.

- 글쓴이의 출발점은 꽤 직설적임. 요즘 앱 개발자들이 AI 기능만 나오면 바로 OpenAI나 Anthropic API를 붙이는데, 이게 너무 쉽게 제품의 기본 구조를 망가뜨린다는 얘기임.
  - 원래는 그냥 UX 기능 하나였던 게 네트워크 상태, 외부 벤더 장애, 레이트 리밋, 계정 과금, 백엔드 헬스체크에 의존하는 분산 시스템이 돼버림.
  - 사용자의 데이터가 제3자 AI 서버로 흘러가는 순간, 데이터 보관, 동의, 감사, 침해 대응, 정부 요청, 학습 사용 여부 같은 질문이 줄줄이 따라옴.

- 핵심 주장은 “AI everywhere”가 아니라 “쓸모 있는 소프트웨어”가 목표여야 한다는 것임.
  - 스마트폰 안의 칩은 10년 전과 비교가 안 될 정도로 빨라졌고, Neural Engine 같은 전용 하드웨어도 있는데, 단순 변환 작업까지 미국 어딘가의 서버 응답을 기다리는 건 좀 웃긴 상황이라는 지적.
  - 특히 요약, 분류, 추출, 재작성, 정규화처럼 사용자가 이미 가진 데이터를 다듬는 작업은 로컬 모델이 잘 맞는 영역이라고 봄.

> [!IMPORTANT]
> 이 글의 요지는 “클라우드 모델 쓰지 마라”가 아니라, 로컬에서 충분히 되는 기능까지 서버 의존으로 만들지 말자는 쪽에 가까움.

- 글쓴이가 든 실제 예시는 The Brutalist Report라는 뉴스 애그리게이터의 iOS 앱임.
  - 1990년대 웹 스타일의 고밀도 뉴스 리더를 만들면서, 기사 본문을 읽기 좋게 정리하고 선택적으로 요약하는 “intelligence” 뷰를 붙였다고 함.
  - 중요한 건 이 요약이 서버를 거치지 않고 Apple의 로컬 모델 API로 온디바이스에서 생성된다는 점임.
  - 프롬프트 로그도 없고, 사용자 콘텐츠 로그도 없고, 벤더 계정도 없고, “우리가 콘텐츠를 30일 보관합니다” 같은 각주도 필요 없어짐.

- Apple 생태계에서는 FoundationModels를 써서 꽤 간단한 흐름으로 로컬 요약을 만들 수 있다고 설명함.
  - `SystemLanguageModel.default`로 모델을 가져오고, 사용 가능 여부를 확인한 뒤, `LanguageModelSession`에 지시문을 넣고 `respond`를 호출하는 식임.
  - 긴 글은 약 1만 자 단위로 청크를 나눠 각 청크에서 “facts only” 노트를 만들고, 2차 패스로 최종 요약을 합치는 방식도 가능하다고 함.
  - 이런 작업은 사용자가 지금 읽는 페이지를 정리하는 수준이라, 박사급 추론 능력보다 빠르고 사적인 데이터 변환 능력이 더 중요함.

- 더 흥미로운 대목은 Apple이 AI 출력을 그냥 텍스트 덩어리로 두지 않고 타입 있는 데이터로 밀고 있다는 점임.
  - 예전 방식은 “JSON으로 답해줘”라고 말한 뒤 모델이 스키마를 제대로 지켰는지 기도하는 쪽에 가까웠음.
  - 여기서는 Swift 구조체를 정의하고, 각 필드에 자연어 가이드를 붙인 뒤, 모델에게 그 타입의 인스턴스를 생성하게 함.
  - 예시에서는 `ArticleIntel` 구조체에 `tldr`, `bullets`, `keywords` 필드를 두고, 모델이 이 타입에 맞춰 결과를 채움.

```mermaid
sequenceDiagram
    participant 사용자
    participant iOS앱
    participant 로컬모델
    participant UI
    사용자->>iOS앱: 기사 본문 열기
    iOS앱->>로컬모델: 본문과 요약 지시 전달
    로컬모델-->>iOS앱: 타입 있는 결과 반환
    iOS앱->>UI: 요약, 불렛, 키워드 렌더링
    UI-->>사용자: 서버 전송 없는 요약 표시
```

- 이 구조의 장점은 단순히 개발자 경험이 좋아지는 정도가 아님.
  - UI가 마크다운 불렛을 다시 긁어오거나 JSON 파싱 실패를 걱정하지 않아도 됨.
  - 앱 입장에서는 AI 응답이 예측 가능한 필드로 들어오니, 기능이 “신기한 장난감”이 아니라 신뢰할 수 있는 서브시스템에 가까워짐.

- “로컬 모델은 클라우드 모델만큼 똑똑하지 않다”는 반론에 대해서는 글쓴이도 인정함. 근데 그래서 뭐냐는 태도임.
  - 대부분의 앱 기능은 셰익스피어를 쓰거나 양자역학을 설명하거나 변호사 시험을 통과하는 모델이 필요하지 않음.
  - 필요한 건 요약, 분류, 추출, 재작성, 정규화를 안정적으로 해내는 능력임.
  - 로컬 모델을 인터넷 전체의 대체재로 쓰면 실망하겠지만, 앱 안의 데이터 변환기로 쓰면 왜 굳이 서버에 보냈는지 되묻게 된다는 얘기.

- 결론은 꽤 실무적임. 클라우드 모델은 진짜 필요할 때만 쓰고, 사용자 데이터는 가능한 원래 있던 곳에 두자는 것임.
  - 이메일 요약, 노트에서 액션 아이템 추출, 문서 분류 같은 기능은 사용자가 원하지만 동시에 가장 못 믿는 기능이기도 함.
  - 긴 개인정보 처리방침으로 신뢰를 얻는 게 아니라, 애초에 데이터를 밖으로 안 보내는 설계로 신뢰를 만든다는 메시지가 강함.

---
## 기술 맥락
- 이 글에서 말하는 기술적 선택은 “AI 기능을 클라우드 API로 붙일지, 로컬 모델로 처리할지”예요. 왜 중요하냐면 같은 요약 기능이라도 서버 호출이 들어가는 순간 장애 지점과 개인정보 이슈가 확 늘어나거든요.

- Apple 쪽 구현은 FoundationModels를 통해 시스템 내장 모델을 호출하는 방식이에요. 사용자가 이미 기기에서 읽고 있는 기사 본문을 입력으로 쓰기 때문에, 굳이 백엔드로 보냈다가 다시 받는 왕복이 필요 없다는 게 핵심이에요.

- 긴 문서는 약 1만 자 단위로 나눠 먼저 청크별 사실 노트를 만들고, 다시 합치는 2단계 처리를 제안해요. 왜냐면 로컬 모델도 컨텍스트 한계가 있고, 한 번에 긴 글을 밀어 넣는 것보다 작은 단위로 안정적으로 처리하는 편이 앱 기능으로는 더 예측 가능하거든요.

- 또 하나 중요한 건 출력 형식이에요. 모델에게 JSON을 달라고 하고 파싱하는 대신 Swift 구조체를 정의해 타입 있는 결과를 받으면 UI가 훨씬 단단해져요. AI 응답을 그대로 화면에 뿌리는 게 아니라, 앱의 데이터 모델 안으로 끌어들이는 설계인 셈이에요.

## 핵심 포인트

- 클라우드 AI 의존은 단순 UX 기능을 네트워크, 과금, 벤더 장애에 묶인 분산 시스템으로 바꿔버린다.
- Apple 생태계에서는 FoundationModels로 온디바이스 요약과 타입 기반 구조화 출력을 구현할 수 있다.
- 로컬 모델은 세상 지식을 대신하는 검색 엔진보다 사용자 데이터 변환기에 가까운 작업에서 특히 잘 맞는다.

## 인사이트

AI 기능을 붙이는 게 목표가 아니라 쓸모 있는 소프트웨어를 만드는 게 목표라는 지적이 핵심이다. 특히 개인 문서, 메일, 노트처럼 민감한 데이터를 다루는 앱이라면 로컬 우선 설계가 그냥 취향이 아니라 제품 신뢰의 일부가 된다.