로컬 AI를 기본값으로 삼아야 하는 이유

• 글쓴이의 출발점은 꽤 직설적임. 요즘 앱 개발자들이 AI 기능만 나오면 바로 OpenAI나 Anthropic API를 붙이는데, 이게 너무 쉽게 제품의 기본 구조를 망가뜨린다는 얘기임.

  • 원래는 그냥 UX 기능 하나였던 게 네트워크 상태, 외부 벤더 장애, 레이트 리밋, 계정 과금, 백엔드 헬스체크에 의존하는 분산 시스템이 돼버림.
  • 사용자의 데이터가 제3자 AI 서버로 흘러가는 순간, 데이터 보관, 동의, 감사, 침해 대응, 정부 요청, 학습 사용 여부 같은 질문이 줄줄이 따라옴.

• 핵심 주장은 “AI everywhere”가 아니라 “쓸모 있는 소프트웨어”가 목표여야 한다는 것임.

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

• 글쓴이가 든 실제 예시는 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 필드를 두고, 모델이 이 타입에 맞춰 결과를 채움.

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 응답을 그대로 화면에 뿌리는 게 아니라, 앱의 데이터 모델 안으로 끌어들이는 설계인 셈이에요.