핵심 요약
- NobodyWho는 클라우드 API 대신 사용자 기기에서 AI 모델을 직접 실행하는 온디바이스 추론 엔진으로, 대화·이미지 이해·음성 등 기능을 앱과 게임에 탑재할 수 있도록 설계된 오픈소스 프로젝트임
- 모델을 한 번 내려받으면 이후 실행 시 인터넷 연결이나 API 키가 필요 없으며, 사용자 입력이 외부 서버로 전송되지 않고 기기 내에서 처리됨
- Python 등 다양한 개발 환경에서 손쉽게 통합할 수 있어, 클라우드 기반 LLM API에 의존하지 않는 로컬 AI 워크플로를 구성할 수 있음
개발자가 클라우드 API 의존도를 낮추고, 비용·프라이버시·지연 시간 문제를 동시에 해결할 수 있는 로컬 AI 통합 옵션으로 NobodyWho를 소개하는 실무 중심 분석
온디바이스 AI가 화제에서 실제로 쓸 만한 옵션으로 내려왔다. API 호출 비용이 매출을 잠식하는 일이 잦아진 요즘, 한 번 내려받고 나면 인터넷 없이도 돌아가는 로컬 AI 추론 엔진에 개발자 시선이 모인다. 그 흐름 한가운데 NobodyWho가 있다.
NobodyWho는 사용자 기기에서 직접 AI 모델을 실행하는 오픈소스 AI 엔진이다. 모델 파일을 한 번 내려받으면 이후로는 네트워크 연결도, API 키도 필요 없다. 대화·이미지 이해·음성 같은 기능을 앱이나 게임에 그대로 이식하는 게 목표다. Python을 포함한 여러 개발 환경에서 통합이 쉽도록 만들어졌고, 입력 데이터는 기기 밖으로 빠져나가지 않는다.
필자가 이 프로젝트에서 가장 의미 있다고 본 지점은 ‘요금 정책 리스크 회피’다. OpenAI·Anthropic 같은 클라우드 API는 가격이 자주 바뀌고 사용량 한도가 걸린다. 서비스가 자라는 동안 토큰비가 매출을 갉아먹는 사례는 이미 한두 번이 아니다. NobodyWho처럼 모델을 로컬에서 굴리는 방식은 다운로드 비용만 들고, 그 뒤엔 변동비가 거의 없다.
온디바이스 AI 작동 방식 — 한 번 받으면 끝
NobodyWho의 실행 흐름은 단순하다. 첫 실행 시점에서 모델 파일을 디바이스에 내려받고, 이후 모든 추론은 그 기기의 CPU·GPU·NPU에서 처리된다. 사용자가 입력한 텍스트와 이미지는 외부 서버로 전송되지 않고, 응답도 로컬에서 생성된다. 네트워크 지연이 사실상 0에 가까워지는 효과까지 따라온다.
이 구조가 특히 힘을 쓰는 케이스가 있다. 의료·법률처럼 데이터가 외부로 나가면 안 되는 워크로드, 그리고 인터넷이 불안정한 현장에서 돌아가는 산업용 도구다. 사용자가 입력한 내용이 어디에도 기록되지 않는다는 점은 GDPR·HIPAA 같은 규제 환경에서 결정적 이점으로 작동한다.
개발자 관점 비교 5축
온디바이스 AI를 도입할지 판단할 때 가장 자주 비교되는 축은 비용·지연·프라이버시다. 이 셋을 한 표에 정리했다.
| 항목 | 클라우드 API | 온디바이스 AI (NobodyWho) | 하이브리드 |
|---|---|---|---|
| 초기 비용 | 낮음 | 모델 파일 다운로드 | 중간 |
| 운영비 | 토큰당 과금 | 거의 0 | 워크로드별 변동 |
| 네트워크 지연 | 200ms~수 초 | 사실상 없음 | 케이스별 상이 |
| 데이터 주권 | 서버 전송 | 기기 내 처리 | 민감 데이터만 로컬 |
| 오프라인 작동 | 불가 | 가능 | 부분 가능 |
표에서 보듯 온디바이스 AI는 비용·프라이버시·지연 세 축에서 우위에 있다. 대신 기기 하드웨어 요구사항이 생기고, 모델 크기만큼 저장 공간을 잡아먹는다. 7B 파라미터 모델은 대략 4~5GB, 더 큰 모델은 그 이상이다. 호환 모델과 디바이스 목록은 NobodyWho 원문 기사에서 확인할 수 있다.
온디바이스 AI 도입 전 반드시 봐야 할 한계
솔직히 모든 워크로드에 로컬 추론이 답은 아니다. 모델 품질 자체는 같은 파라미터 수 기준으로도 클라우드 최상위 모델에 못 미치는 경우가 많다. 추론 능력이 중요한 작업이나 다국어 처리에서는 격차가 뚜렷하다.
배터리와 발열도 봐야 한다. 모바일 기기에서 7B 모델을 계속 돌리면 배터리가 빠르게 소모되고, 기기가 눈에 띄게 뜨거워진다. 사용자 경험 설계 단계에서 ‘언제 로컬로, 언제 클라우드로’ 라우팅할지 미리 정해두는 게 좋다. NVIDIA가 2026년 9월 28일 공개한 에이전트 안전 플랫폼 보고서에서도 에이전트가 스스로를 완전히 통제하지 못하는 드리프트(drift) 실패 모드를 짚은 만큼, 온디바이스 AI 통제도 샌드박스와 권한 분리 설계와 함께 가야 한다.
실무 적용 포인트
- PoC 단계에서 데이터 주권이 중요한 워크로드(메모·의료·법률)부터 로컬 추론 후보로 분리한다.
- 모델 크기별 다운로드 시간·저장 공간·배터리 소모량을 디바이스 매트릭스로 사전 측정한다.
- 민감하지 않은 작업은 클라우드, 민감 입력은 온디바이스 AI로 자동 라우팅하는 하이브리드를 처음부터 가정한다.
- 에이전트형 기능을 추가할 경우 샌드박스와 툴 호출 권한 범위를 별도 명세로 분리한다.
- 모델 업데이트 채널을 운영 환경과 분리하고, 롤백 가능한 버전 관리 체계를 마련한다.
하이브리드 설계가 현실적 답
순수 로컬과 순수 클라우드 사이에는 늘 회색 지대가 있다. NobodyWho 같은 엔진은 그 회색 지대를 채우는 도구로 가장 빛난다. 사용자의 텍스트 입력은 로컬에서 1차 분류하고, 분류가 모호한 경우에만 클라우드의 큰 모델로 보내는 식이다.
이 설계의 핵심은 ‘민감도 기반 라우팅’이다. 개인정보가 포함된 프롬프트는 무조건 로컬에서만 처리하고, 일반 질의응답은 클라우드로 보내도 된다. 비용과 프라이버시를 동시에 잡는 가장 현실적인 패턴이다. 로컬 추론 라우팅 자체는 엔비디아 PAIR 출시 분석에서도 다른 방식으로 다뤄진 바 있다.
지금 바로 해볼 것
- NobodyWho GitHub 저장소에서 릴리즈 노트와 호환 디바이스 목록을 확인한다.
- 현재 서비스에서 API 호출 비용이 가장 큰 1개 워크로드를 골라 로컬 전환 후보로 지정한다.
- 해당 워크로드의 평균 입력·출력 토큰 수와 응답 시간 SLO를 표로 정리한다.
- 동일 파라미터급 오픈소스 모델 2~3개를 후보로 올리고 디바이스별 벤치를 돌린다.
- 내부 PoC 환경에 샌드박스와 권한 분리 가이드를 먼저 작성한 뒤 모델을 통합한다.
누가 써야 하고, 누가 기다려야 하나
지금 당장 온디바이스 AI를 도입할 가치가 있는 팀은 크게 두 부류다. API 비용이 매출을 잠식하는 구조이거나, 데이터가 외부로 나가는 것 자체가 비즈니스 리스크인 팀. 여기에 더해 오프라인 환경에서도 작동해야 하는 제품을 만드는 팀은 우선순위가 더 높다.
반대로 대규모 컨텍스트나 복잡한 추론이 핵심인 서비스는 아직 클라우드 최상위 모델을 쓰는 게 낫다. 13B 이하의 온디바이스 모델로 대체할 수 있는 워크로드는 한정적이다. 로컬 추론은 ‘전부 대체’가 아니라 ‘일부 대체’ 전략으로 접근해야 효과를 본다.
자주 묻는 질문
NobodyWho는 어떤 모델을 지원하나요?
주류 오픈소스 LLM 포맷과 이미지·음성 모델을 폭넓게 지원하도록 설계됐다. 구체적인 호환 목록은 저장소 릴리즈 노트에서 확인하는 게 빠르다. 모델 파일 형식에 따라 디바이스 요구사항이 달라질 수 있다.
온디바이스 AI로 API 비용을 완전히 없앨 수 있나요?
모든 워크로드를 로컬로 옮기기는 어렵다. 민감도와 복잡도가 낮은 작업부터 단계적으로 전환하는 방식이 현실적이다. 하이브리드 구성을 전제로 비용 구조를 다시 그려야 의미 있는 절감이 나온다.
데이터가 정말 외부로 전송되지 않나요?
NobodyWho 자체는 사용자 입력을 외부로 보내지 않는다. 다만 앱 통합 과정에서 텔레메트리나 분석 모듈이 추가될 수 있으므로, 배포 전 코드 경로를 직접 확인하는 편이 안전하다.
모바일에서도 온디바이스 AI가 작동하나요?
모델 크기와 기기 사양에 따라 다르다. 1~2B 파라미터급 모델은 중상급 모바일 칩셋에서 동작하지만, 7B 이상은 발열과 배터리 소모가 커진다. 디바이스 매트릭스 기반 사전 검증이 필수다.
NobodyWho 같은 오픈소스 AI 엔진이 늘고 있다는 건, ‘언제 로컬, 언제 클라우드’를 선택지가 아니라 설계 문제로 만들어 준다는 뜻이다. 필자가 보기에 지금 가장 중요한 건 모델을 고르는 게 아니라, 온디바이스 AI와 클라우드를 가르는 기준을 팀 안에서 합의하는 일이다. 그 기준이 잡히면 NobodyWho는 그 기준을 코드로 옮기는 도구가 된다.
참고 원문
이 기사는 다음 원문을 확인해 작성했습니다: geeknews — NobodyWho – 앱과 게임에 로컬 AI를 넣는 온디바이스 추론 엔진
전문가 코멘트(AI)
ML시스템엔지니어
온디바이스 추론은 비용·프라이버시·지연의 삼각형을 실제로 푸는 접근이지만, 하드웨어 파편화와 모델 품질 격차라는 산이 남아 있다
모델 가중치를 한 번 배포한 뒤 변동비가 거의 없이 실행하는 구조는 토큰 과금 모델이 맞지 않는 워크로드(채팅, 요약, 분류, 오프라인 도구)에서 명확한 유닛 이코노미를 제공하며, 설계 방향 자체는 타당하다. llama.cpp 계열 양자화 생태계가 검증된 만큼 1B~8B급 모델을 중상급 모바일 SoC와 데스크톱에서 구동하는 것은 기술적으로 현실적인 범위에 들어왔다. 다만 약점이 분명하다: 디바이스 파편화된 NPU 가속 지원, 메모리 대역폭 병목에서 오는 prefill·decode 속도 격차, 장문 컨텍스트에서의 성능 급락, 지속 추론 시 발열 스로틀링이 도입의 주된 제약이다. 동일 파라미터 수 기준으로도 클라우드 최상위 모델과의 품질 격차, 특히 복잡한 추론과 저자원 언어에서의 열세는 단기간에 좁혀지기 어렵다. 결국 이 기술의 성패는 NPU 가속 표준화, 안정적인 양자화·배포 체계, 디바이스별 성능 보증 방식의 정착에 달려 있고, 그 전까지는 하이브리드 라우팅이 기본값일 수밖에 없다.
정보보안전문가
데이터 주권 강화는 확실하지만, 위험이 사라지는 것이 아니라 모델 아티팩트와 툴 호출 권한으로 공격 표면이 이동한다
사용자 입력이 기기 밖으로 나가지 않는 구조는 GDPR·HIPAA 환경에서 실질적인 컴플라이언스 자산이 되고, 네트워크 전송 경로가 제거되면서 데이터 유출 계면이 줄어든다는 점은 의료·법률 워크로드 도입의 정당한 근거다. 다만 데이터가 로컬에 머문다는 것이 위험이 없다는 뜻은 아니다. 모델 가중치 파일의 다운로드·업데이트 채널, 통합 SDK, 텔레메트리 모듈이 새로운 공격 표면이 되며, 변조된 모델 체크포인트나 배포 단계에서 삽입된 코드 경로는 서버 로그보다 탐지가 훨씬 어렵다. 특히 에이전트형 기능이 로컬에서 툴을 호출하는 설계는 프롬프트 인젝션에 의한 권한 상승이 클라우드보다 조용히, 그리고 사용자 눈에 띄지 않게 발생할 수 있어 샌드박스, 최소 권한, 모델 아티팩트 서명 검증이 사실상 필수 요건이 된다. 요컨대 프라이버시 보증은 강화되지만 보안 책임 자체가 클라우드 공급자에서 개발자와 기기로 이전되며, 그 이관을 감당할 조직 역량 없이 도입하면 규제 준수 지연은 그대로 조직의 책임으로 남는다.
비판적 분석가
API 비용 탈출 내러티브의 진짜 수혜자는 결국 새 칩을 산 사람들과, 모호한 입력을 다시 받아 가는 클라우드다
표면적으로는 개발자의 해방 서사지만 누가 이득을 보는지 따져보면 그림이 달라진다. 7B급 모델을 쾌적하게 돌리려면 대용량 메모리, NPU, 최신 칩셋이 요구되고, ‘온디바이스 AI가 가능하다’는 문구는 기기 업그레이드 수요를 만드는 훌륭한 구매 동기로 읽힌다. 클라우드 대형 업체가 오픈소스 로컬 엔진 붐를 막지 않는 이면에도 이유가 있을 가능성이 크다. 하이브리드 라우팅은 결국 분류가 모호한 입력을 다시 자사 대형 모델 API로 보내는 파이프라인이 되기 쉽고, 그 시점에 로컬 엔진은 경쟁자가 아니라 사실상 필터이자 탑 오브 퍼널 역할을 한다. ‘언제 로컬, 언제 클라우드’라는 질문 틀 자체가 대형 클라우드에 유리한 프레임이라는 점도 주목할 만하다. 우리가 진짜 길게 봐야 할 것은 기술 우위가 아니라 라우팅 로직과 표준을 누가 소유하느냐, 즉 로컬 추론 생태계가 칩 밴더 로드맵에 얼마나 깊이 종속되느냐다.
물밑 시나리오
- 칩 제조사와 기기 OEM이 온디바이스 AI 붐을 조성해 기기 교체 수요를 만들었을 가능성이 있다. 7B급 모델의 실사용 요구 사양이 최신 칩셋과 대용량 메모리와 정확히 겹치고, 온디바이스 실험 게시와 하드웨어 출시 주기가 맞물리는 것이 근거.
- 클라우드 대형 업체들이 오픈소스 소형 모델 채택을 묵묵히 허용하는 이유는 하이브리드 라우팅이 결국 모호한 케이스를 자사 대형 모델 API로 회귀시키기 때문일 가능성이 있다. 실무에서는 분류 불확실 입력의 상당수가 최종적으로 클라우드로 넘어가는 경향이 근거.
- 온디바이스 전환 후보로 ‘비용 1순위 워크로드’가 반복적으로 지목되는 것은 개발자 편의가 아니라, API 요금 인상 이후의 시장 압력을 우회하는 신호일 수 있다. 요금 정책 변경 시점과 온디바이스 도구 화두의 타이밍이 반복적으로 겹치는 것이 근거.
답글 남기기