AI 기능을 만든다고 하면 보통 카메라 이미지나 문서를 클라우드 API로 보내고 결과를 받는 구조부터 떠올립니다. 개발이 빠르고 최신 모델을 바로 사용할 수 있다는 장점이 있습니다. 그러나 생산라인, 물류센터, 연구소와 공공기관에서는 네트워크가 느리거나 끊기고, 데이터 반출이 금지되며, 수십 밀리초 안에 판단해야 하는 상황이 흔합니다.
이때 AI가 현장의 PC, 모바일 기기, 카메라 옆 엣지 컴퓨터에서 직접 동작하는 온디바이스·엣지 AI가 대안이 됩니다. 2026년에는 소형 모델의 멀티모달·도구 호출 능력이 개선되고, Windows·Apple·Google 생태계가 로컬 추론을 운영체제와 개발 도구 수준에서 지원하면서 적용 범위가 넓어지고 있습니다.
하지만 “클라우드를 없애면 보안과 비용 문제가 모두 해결된다”는 접근도 위험합니다. 현장 하드웨어 제약, 모델 업데이트, 장치별 성능 편차와 물리적 탈취 같은 새로운 문제가 생깁니다. 핵심은 로컬과 클라우드 중 하나를 고집하는 것이 아니라, 업무의 지연·보안·정확도·운영 조건에 맞게 추론 위치를 설계하는 것입니다.
2026년에 다시 온디바이스 AI가 주목받는 이유
작은 모델은 단순 분류기를 넘어 텍스트, 이미지, 음성 같은 여러 입력을 다루고 제한된 도구 호출까지 수행하는 방향으로 발전하고 있습니다. Google은 2026년 Gemma 4를 모바일·데스크톱·엣지 하드웨어에서 에이전트형 작업과 시청각 처리를 지원하는 모델군으로 소개했습니다.
Microsoft는 Windows AI를 통해 Foundry Local 기반 로컬 언어 모델, Windows ML과 ONNX 모델의 CPU·GPU·NPU 가속 경로를 제공합니다. Apple Foundation Models도 기기 내 요약, 추출, 구조화 출력과 도구 호출을 지원하며, 더 큰 추론 능력이 필요할 때 서버 모델로 확장하는 구조를 제공합니다.
중요한 변화는 최고 성능 모델 하나가 모든 일을 처리하는 구조에서 벗어나고 있다는 점입니다. 작고 빠른 모델은 기기에서 반복 업무를 처리하고, 복잡한 판단만 큰 서버 모델에 맡기는 계층형 AI가 현실적인 선택지가 됐습니다.
온디바이스, 엣지, 온프레미스는 어떻게 다를까
온디바이스 AI는 사용자의 스마트폰, 태블릿, 노트북이나 장비 내부 컴퓨터에서 모델을 실행합니다. 개인 데이터가 기기를 벗어나지 않고 네트워크 없이도 기능을 제공하기 좋습니다.
엣지 AI는 데이터가 생성되는 현장 가까운 컴퓨터에서 추론합니다. 한 대의 산업용 PC가 여러 카메라를 처리하거나 공장 내부 엣지 서버가 설비 데이터를 분석할 수 있습니다. 센서에 완전히 내장될 필요는 없지만 중앙 클라우드보다 현장에 가깝습니다.
온프레미스 AI는 조직 내부 데이터센터나 폐쇄망 서버에서 실행합니다. 외부 전송은 막으면서 엣지 장치보다 큰 GPU와 중앙 운영 기능을 사용할 수 있습니다. 현장 장치와 네트워크 거리가 있으므로 엄격한 실시간 제어에는 별도 엣지 계층이 필요할 수 있습니다.
한 프로젝트 안에서도 세 방식을 섞을 수 있습니다. 카메라 프레임은 장비 옆에서 즉시 판정하고, 하루치 통계는 사내 서버에서 분석하며, 민감정보를 제거한 복잡한 질의만 승인된 클라우드 모델로 보냅니다.
로컬 실행이 유리한 다섯 가지 조건
- 낮은 지연: 검사 결과가 액추에이터나 라인 정지 판단으로 이어져 왕복 지연을 허용하기 어려운 경우
- 불안정한 네트워크: 지하, 이동 장비, 원격 시설이나 폐쇄망처럼 연결을 전제로 할 수 없는 경우
- 데이터 보호: 얼굴, 음성, 설계도, 생산 조건과 고객 문서를 외부로 보내기 어려운 경우
- 대량 원시 데이터: 고해상도 영상처럼 전송 비용과 대역폭이 큰 데이터를 현장에서 요약할 수 있는 경우
- 예측 가능한 비용: 동일 장치에서 반복 추론이 많아 호출량 기반 비용보다 고정 하드웨어가 유리한 경우
반대로 드물게 사용하는 복잡한 추론, 최신 지식이 계속 필요한 업무, 작은 장치로는 감당할 수 없는 긴 문맥과 고성능 생성은 클라우드가 유리할 수 있습니다. 개인정보가 없고 안정적인 네트워크가 이미 있다면 로컬 운영 복잡도를 추가할 필요가 없습니다.
현장 업무를 먼저 나누고 모델은 나중에 고른다
“로컬 LLM을 설치하고 무엇을 할지 찾자”는 순서는 실패하기 쉽습니다. 먼저 현장 업무를 입력, 기대 출력, 허용 지연, 정확도, 실패 영향과 데이터 민감도로 나눕니다.
예를 들어 제조 검사에는 서로 다른 과제가 섞여 있습니다. 표면 결함 위치를 찾는 비전 모델, 알람 코드를 설명하는 언어 모델, 작업표준서에서 점검 절차를 검색하는 로컬 RAG, 결과를 MES에 기록하는 규칙 기반 프로그램입니다. 하나의 거대 모델에 모두 맡길 이유가 없습니다.
결함 검출은 검증된 전용 CNN이나 비전 모델이 더 빠르고 예측 가능할 수 있습니다. 언어 모델은 검사 결과와 설비 이력을 사람이 이해하기 쉬운 보고서로 정리하는 역할을 맡습니다. 정지 신호처럼 안전과 직결된 동작은 결정적 제어 로직이 최종 판단합니다.
로컬과 클라우드를 나누는 하이브리드 라우터
하이브리드 구조에서는 요청마다 실행 위치를 결정합니다. 민감도, 지연 한도, 네트워크 상태, 로컬 모델의 신뢰도와 필요한 추론 능력을 기준으로 라우팅합니다.
예를 들어 작업자의 음성을 텍스트로 바꾸고 명령 종류를 분류하는 과정은 로컬에서 처리합니다. 일반 점검 질문은 사내 문서 검색과 소형 모델로 답합니다. 여러 설비의 장기 데이터를 비교하는 복잡한 분석은 익명화와 승인을 거쳐 서버로 보냅니다.
라우팅 실패 시 동작도 정해야 합니다. 네트워크가 없으면 로컬 축약 기능으로 전환할지, 요청을 보관했다가 재전송할지, 안전을 위해 기능을 중단할지를 업무 위험에 따라 결정합니다. 사용자는 지금 로컬 결과인지 서버 결과인지와 기능 제한을 이해할 수 있어야 합니다.
소형 모델은 큰 모델의 축소판이 아니다
소형 언어 모델은 메모리와 연산량이 적지만 문맥 길이, 복잡한 추론, 세계 지식과 지시 준수에서 한계가 있습니다. 큰 모델에 사용한 긴 프롬프트를 그대로 옮기면 품질이 급격히 떨어질 수 있습니다.
Apple의 온디바이스 모델 프롬프트 가이드도 간결하고 구체적인 지시, 복잡한 작업의 단계 분리, 조건 로직을 프로그램 코드로 이동하는 방식을 권합니다. 모델이 생각해야 할 범위를 줄이고 구조화된 출력을 사용하면 작은 모델도 좁은 업무에서 안정적으로 동작할 수 있습니다.
모델에 모든 사내 규칙을 외우게 하기보다 현재 작업에 필요한 몇 개의 문서 조각만 로컬 검색으로 제공합니다. 날짜 계산, 임계값 판단과 권한 확인은 코드로 처리하고, 모델은 분류·추출·요약처럼 잘하는 부분에 집중시킵니다.
하드웨어 예산은 모델 크기만 보면 안 된다
모델 파일이 저장장치에 들어간다고 실행 가능한 것은 아닙니다. 가중치 메모리 외에도 런타임, KV cache, 입력 이미지와 중간 텐서가 메모리를 사용합니다. 긴 문맥과 동시 요청이 늘면 사용량이 크게 증가합니다.
산업용 PC에서는 CPU 세대, RAM, 내장·외장 GPU, NPU, 발열과 전원, 운영체제 버전을 함께 봅니다. 팬이 없는 장비는 짧은 벤치마크에서는 빨라도 지속 부하에서 열 제한으로 느려질 수 있습니다. 카메라 캡처와 UI 렌더링이 같은 GPU를 사용하면 추론만 측정한 결과와 실제 성능이 다릅니다.
현장 장치의 최저 사양에서 p50뿐 아니라 p95·p99 지연, 메모리 최고치, 전력과 온도를 측정합니다. 한 번의 요청보다 8시간 연속 운전, 동시에 여러 카메라가 들어오는 상황과 모델 재로딩 시나리오를 시험해야 합니다.
양자화는 작아지는 만큼 다시 검증해야 한다
양자화는 32비트 부동소수점 가중치를 8비트나 4비트 같은 더 작은 표현으로 바꿔 모델 크기와 연산 부담을 줄입니다. ONNX Runtime 문서는 32비트에서 8비트로 바꾸면 가중치 크기가 대략 4분의 1로 줄 수 있다고 설명합니다.
하지만 크기가 줄었다고 항상 빨라지거나 정확도가 유지되는 것은 아닙니다. 하드웨어가 해당 정수 연산을 효율적으로 지원해야 하며, 연산자와 실행 공급자 조합에 따라 오히려 변환 비용이 생길 수 있습니다. 비전 모델의 작은 정확도 하락도 희귀 불량을 놓치는 결과로 이어질 수 있습니다.
대표성 있는 현장 데이터로 원본 모델과 양자화 모델의 정확도, 클래스별 재현율, 지연과 자원 사용량을 비교합니다. 특히 조명 변화, 오염, 진동, 카메라 교체와 계절별 조건처럼 실제 분포의 끝부분을 평가 세트에 포함합니다.
배포 파이프라인은 모델과 하드웨어를 하나의 제품으로 본다
엣지 모델은 학습 서버에서 좋은 점수만 얻는다고 끝나지 않습니다. 변환, 양자화, 장치별 가속, 성능 검증, 서명, 배포와 롤백이 연결돼야 합니다.
- 서버 환경에서 기준 모델과 업무 품질 지표를 확정합니다.
- 현장 분포를 반영한 보정·평가 데이터를 고정합니다.
- 목표 런타임 형식으로 변환하고 양자화합니다.
- CPU·GPU·NPU별 실행 공급자와 지원 연산자를 확인합니다.
- 실제 최저 사양 장치에서 정확도·지연·메모리·발열을 측정합니다.
- 모델 파일과 설정을 서명하고 단계적으로 배포합니다.
- 운영 지표가 기준을 벗어나면 이전 버전으로 롤백합니다.
Windows 산업용 앱에서의 현실적인 선택
네이처프랙탈이 다루는 계측기 연동, 머신비전 카메라 제어와 실시간 수집 파이프라인은 Windows 산업용 PC에서 장시간 실행되는 경우가 많습니다. 이 환경에서는 AI 모델뿐 아니라 드라이버, 시리얼 통신, UI 응답성과 장애 복구가 하나의 프로그램 안에서 맞물립니다.
Microsoft의 Windows AI 경로는 Windows ML을 통한 ONNX 모델 배포와 DirectML 기반 하드웨어 가속, Foundry Local을 통한 로컬 언어 모델 실행을 지원합니다. C#·C++·Python 등 기존 앱 기술과 조합할 수 있어 전체 시스템을 새로 만들지 않고 필요한 기능부터 추가하기 좋습니다.
다만 최신 Copilot+ PC 전용 API와 일반 산업용 PC에서 사용할 수 있는 런타임을 구분해야 합니다. 고객 장비의 OS 버전과 GPU·NPU 유무가 제각각이라면 기능 감지, CPU fallback과 지원 하드웨어 표가 필요합니다.
카메라 AI는 평균 FPS보다 전체 지연을 측정한다
비전 검사에서 모델 추론 20ms만 보고 초당 50프레임이 가능하다고 계산하면 실제 라인에서 맞지 않을 수 있습니다. 이미지 캡처, 디코딩, 전처리, 메모리 복사, 추론, 후처리, PLC 통신과 화면 표시까지 end-to-end 지연을 측정해야 합니다.
모든 프레임을 처리할 필요가 있는지, 트리거 시점의 한 장만 검사할지, 여러 프레임을 누적할지도 정합니다. 입력이 처리 속도보다 빠르면 큐가 계속 쌓이지 않도록 최신 프레임 우선, 유실 허용 범위와 backpressure 정책을 둡니다.
라인 정지 판단은 모델 점수 하나에 직접 연결하지 않습니다. 신뢰도, 센서 조건, 연속 검출 횟수와 안전 규칙을 결합하고 불확실한 경우 사람 검수나 보수적인 제어로 전환합니다.
로컬 RAG는 인터넷 없이도 근거를 제공한다
작업표준서, 설비 매뉴얼, 오류 코드와 유지보수 기록을 현장에 색인하면 네트워크 없이도 검색 기반 답변을 만들 수 있습니다. 모델이 문서를 외워서 답하는 것이 아니라 관련 구절을 찾아 컨텍스트로 제공하고 출처 페이지를 함께 보여줍니다.
문서 버전과 설비 모델을 메타데이터로 관리해 다른 장비의 절차가 섞이지 않게 합니다. 승인되지 않은 임시 문서와 폐기된 표준서는 색인에서 제외하고, 중앙에서 검증된 인덱스 패키지를 서명해 배포합니다.
로컬 저장소도 접근 통제가 필요합니다. 장비를 사용하는 모든 사람이 모든 설계 문서에 접근할 수 있는 것은 아닙니다. 사용자 역할과 작업 위치에 따라 검색 범위를 제한하고 감사 로그를 남깁니다.
폐쇄망이라고 자동으로 안전한 것은 아니다
외부 인터넷이 없으면 원격 공격 표면은 줄지만 USB, 유지보수 노트북, 공급망 파일과 내부 계정 위험은 남습니다. 모델 파일은 회사의 지식과 성능을 담은 자산이며 변조되면 잘못된 판정을 만들 수 있습니다.
모델·런타임·설정 패키지에 전자서명을 적용하고 애플리케이션이 실행 전에 검증합니다. 업데이트 매체와 담당자를 통제하고, 버전·해시·배포 장치·시각을 중앙 또는 반출 가능한 감사 로그로 기록합니다.
입력 데이터와 생성 결과의 보존 기간도 정합니다. 개인정보를 클라우드로 보내지 않는다는 이유로 현장 디스크에 원본 영상과 음성을 무기한 저장하면 다른 위험이 생깁니다. 암호화, 계정 분리와 자동 삭제 정책이 필요합니다.
모델 업데이트는 앱 업데이트와 분리한다
AI 모델은 데이터 변화와 품질 개선 때문에 앱 코드보다 자주 바뀔 수 있습니다. 실행 파일과 모델을 하나의 거대한 설치 파일로 묶으면 작은 모델 교체에도 전체 프로그램을 재배포해야 합니다.
앱이 지원하는 모델 계약을 버전화하고, 호환되는 모델 패키지를 별도로 배포합니다. 패키지에는 모델 파일, 전처리·후처리 설정, 클래스 목록, 기준 지표, 하드웨어 요구사항과 서명이 포함됩니다.
일부 장치에 먼저 배포해 지연과 오류를 확인한 뒤 확대합니다. 새 모델 로딩이 실패하거나 품질 경보가 발생하면 마지막 정상 버전을 즉시 활성화합니다. 폐쇄망은 실시간 업데이트가 어려우므로 현장 방문 없이 복구할 수 있는 이중 슬롯 구조가 유용합니다.
운영에서 무엇을 관찰해야 할까
클라우드 API는 서버에서 전체 요청을 관찰하기 쉽지만 엣지 장치는 각 현장에 흩어져 있습니다. 개인정보와 원본 데이터를 수집하지 않으면서 상태를 확인할 원격 관측 설계가 필요합니다.
- 모델·앱·드라이버와 하드웨어 버전
- 추론 횟수, p50/p95/p99 지연과 timeout
- 메모리·CPU·GPU/NPU 사용률, 온도와 디스크 여유
- 신뢰도 분포, 불확실 판정과 사람 재검 비율
- 입력 품질 이상, 카메라 끊김과 센서 누락
- 업데이트 성공률, 서명 오류와 롤백 횟수
현장 네트워크가 없으면 지표를 로컬 순환 저장하고 허용된 연결 시 요약만 동기화합니다. 로그가 디스크를 가득 채우지 않도록 크기와 보존 기간을 제한합니다.
비용은 API 요금과 PC 가격만 비교하지 않는다
클라우드는 초기 하드웨어 없이 시작하기 쉽고 사용량에 따라 비용이 늘어납니다. 엣지는 장비 구매 비용이 있지만 반복 추론의 네트워크·호출 비용을 줄일 수 있습니다. 실제 비교에는 개발과 운영 비용을 함께 넣어야 합니다.
엣지 비용에는 장치 수, GPU/NPU, 설치, 예비 장비, 원격 관리, 모델 최적화, 현장 지원과 전력 비용이 포함됩니다. 클라우드 비용에는 API·GPU, 데이터 전송, 저장, 연결 장애 대비와 보안 통제가 포함됩니다.
장치 한 대의 월 추론량, 예상 수명과 유지보수 시간을 기준으로 3년 TCO를 계산합니다. 하이브리드 구조라면 로컬에서 몇 퍼센트를 처리하고 어떤 요청만 서버로 보내는지 시나리오별로 비교합니다.
2~4주 PoC에서 반드시 확인할 것
- 현장 조건 수집: 장치 사양, 네트워크, 카메라·센서, 처리 주기와 보안 정책을 확인합니다.
- 업무 기준값: 현재 처리 시간, 오류율, 사람이 개입하는 조건과 실패 비용을 측정합니다.
- 기준 모델: 가장 단순한 전용 모델과 소형 생성 모델을 비교해 최소 구성을 찾습니다.
- 실장 벤치마크: 실제 장치에서 end-to-end 지연, 정확도, 메모리와 발열을 측정합니다.
- 오프라인 시험: 네트워크 단절, 입력 누락과 장치 재부팅 후 복구를 검증합니다.
- 운영 설계: 서명 배포, 관측, 업데이트와 롤백 경로를 프로토타입에 포함합니다.
- 의사결정: 클라우드·엣지·하이브리드의 품질과 3년 비용을 같은 기준으로 비교합니다.
PoC는 개발자 노트북이 아니라 고객이 실제 사용할 최저 사양 장치에서 수행해야 합니다. 샘플 데이터의 성공 화면보다 장시간 안정성, 예외 데이터와 복구 능력이 운영 가능성을 더 잘 보여줍니다.
도입 체크리스트
- 로컬 실행이 필요한 이유가 지연·보안·연결·비용 중 무엇인지 명확한가?
- 업무를 전용 모델, 언어 모델과 결정적 코드로 적절히 나눴는가?
- 클라우드로 보낼 수 있는 데이터와 금지된 데이터를 분류했는가?
- 최저 사양 장치에서 장시간 end-to-end 성능을 측정했는가?
- 양자화 전후의 전체 정확도와 희귀 사례 재현율을 비교했는가?
- 네트워크 단절, 모델 오류와 장치 재부팅 시 안전하게 복구되는가?
- 모델 패키지 서명, 접근 통제와 로그 보존 정책이 있는가?
- 장치별 모델 버전과 품질·성능을 원격으로 확인할 수 있는가?
- 새 모델을 단계적으로 배포하고 즉시 롤백할 수 있는가?
- 3년 TCO에 현장 지원과 모델 운영 비용까지 포함했는가?
마무리: 현장 AI는 작은 모델이 아니라 전체 시스템이다
온디바이스·엣지 AI의 발전은 생산라인과 폐쇄망에서도 생성형 AI와 멀티모달 기능을 사용할 수 있는 선택지를 넓혔습니다. 하지만 모델 파일을 산업용 PC에 복사하는 것만으로 운영 시스템이 완성되지는 않습니다.
카메라와 센서의 입력 품질, 실시간 파이프라인, 하드웨어 가속, 양자화 검증, 로컬 RAG, 보안 업데이트와 장애 복구가 함께 설계돼야 합니다. 복잡한 요청은 서버로 보내고 민감하거나 긴급한 작업은 현장에서 처리하는 하이브리드 구조가 많은 기업에 현실적입니다.
네이처프랙탈의 강점은 AI 모델뿐 아니라 산업용 Windows 앱, 장비 통신, 머신비전과 운영 소프트웨어를 한 시스템으로 연결하는 데 있습니다. 현장 조건을 먼저 측정하고 2~4주 프로토타입으로 실제 장치에서 가능성을 확인한 뒤, 효과가 증명된 범위만 운영으로 확장하는 것이 안전한 출발점입니다.
