온디바이스 AI는 정말 안전하고 빠를까?

온디바이스 AI는 정말 안전하고 빠를까?

— 도입·활용 전 반드시 짚어야 할 다섯 가지 유의사항

 

데이터를 클라우드로 보내지 않고 기기 안에서 직접 처리하는 ‘온디바이스 AI’는 프라이버시 보호, 빠른 반응 속도, 오프라인 활용이라는 매력적인 이유로 스마트폰과 웨어러블, 각종 사물인터넷 기기로 빠르게 번지고 있다. 그런데 여기에는 흔한 착각이 하나 숨어 있다. “기기 안에서 처리하니 무조건 더 안전하고 더 빠르다”는 믿음이다. 결론부터 말하면 이 말은 절반만 맞다. 온디바이스 AI를 실제로 도입하거나 활용할 때는 클라우드 AI와는 결이 전혀 다른 함정들이 곳곳에 도사리고 있기 때문이다.

 

첫째, ‘로컬 처리=완벽한 프라이버시’라는 오해다. 데이터를 기기 밖으로 내보내지 않으면 유출 위험이 사라진다는 생각이 가장 널리 퍼진 오해다. 로컬 처리가 전송 과정의 노출을 줄이는 것은 사실이지만, 기기는 분실되고 도난당하며 통제되지 않은 물리적 환경에 놓인다. 엣지·사물인터넷 기기는 처리 성능이 제한적이라 강력한 암호화나 잦은 보안 업데이트를 적용하기 어렵고, 제조사의 보안 지원이 끝난 뒤에도 오랫동안 쓰이는 경우가 많다. 더 근본적인 위험도 있다. AI 모델 자체가 학습한 데이터를 ‘기억’해 되뱉거나, 수집한 적 없는 민감한 속성을 추론해 드러낼 수 있다는 점이다. 그래서 신뢰실행환경(TEE), 데이터 익명화 같은 보호 장치를 개발 첫 단계부터 설계에 녹이는 ‘프라이버시 우선(privacy-by-design)’ 접근이 권고된다. 로컬에서 돈다는 사실 하나만으로 안전이 자동 보장되지는 않는다는 뜻이다.

 

둘째, 모델을 줄이는 데에는 대가가 따른다. 제한된 기기에서 큰 모델을 돌리려면 압축이 필수다. 대표적인 기법인 양자화는 32비트 부동소수점(FP32)을 8비트나 4비트 정수(INT8·INT4)로 낮춰 메모리 사용을 4~8배 줄이면서도 정확도의 95% 이상을 유지한다고 알려져 있다. 그러나 정밀도를 버리는 만큼 정확도 손실은 원리적으로 불가피하다. 모바일 추론 성능을 재는 대표 벤치마크인 MLPerf Mobile은 스마트폰이 안전에 직결된 작업을 거의 수행하지 않기 때문에 이 정도 손실은 ‘용인 가능’하다고 평가한다. 뒤집어 읽으면, 의료 진단이나 자율주행처럼 작은 오차가 사람의 안전으로 이어지는 영역에서는 같은 손실을 그대로 받아들여선 안 된다는 경고이기도 하다. 압축률과 정확도, 그리고 작업의 위험도를 함께 저울에 올려야 한다.

AI활용

반응형

셋째, 벤치마크 성능과 실사용 성능은 다르다. 배터리로 구동되는 기기는 전력 예산이 빠듯하고, 과도한 연산은 발열을 부르며, 발열은 다시 성능을 강제로 끌어내리는 ‘스로틀링’을 일으킨다. 삼성도 지속적인 추론이 어려워지는 이 열·전력 한계를 온디바이스 생성 AI의 핵심 제약으로 꼽는다. 짧은 시연에서 인상적이던 속도가 오래 쓰면 무너지는 이유가 여기에 있다. 한 실측 연구에서 아이폰 16 프로는 연속 추론 세 번 만에 최고 처리량의 약 40%를 잃고 낮은 상태로 주저앉았고, 갤럭시 S24 울트라도 스무 번에 걸쳐 약 15% 저하됐다. 연구진의 결론은 분명하다. 모바일에서 진짜 병목은 ‘최고 연산 성능’이 아니라 ‘열 관리’라는 것이다. 그래서 실제 제품은 발열 임계점에서 더 작은 모델로 갈아타거나 생성 길이를 줄이는 열 인식(thermal-aware) 제어를 갖추도록 권고된다.

 

넷째, 기기마다 결과가 다르다. 온디바이스 AI의 성능은 ‘로컬에서 처리한다’는 사실 하나로 정해지지 않는다. 같은 모델이라도 기기의 NPU 성능, 메모리 대역폭, 냉각 구조에 따라 전혀 다르게 동작한다. 실제 병목은 연산량이 아니라 메모리 대역폭인 경우가 많다는 분석도 있다. 수억 대에 이르는 다양한 기기가 저마다 다른 조건을 갖고 있으니, 하나의 최신 기기에서 잘 돌아간다고 모두에게서 잘 돌아가리라 장담할 수 없다. 여러 기기에서 검증하고, 성능이 부족한 기기를 위한 대비책(폴백)을 미리 마련하는 일이 선택이 아니라 필수인 이유다.

 

다섯째, 흩어진 모델은 고치기 어렵고, 규제 책임은 사라지지 않는다. 클라우드 모델은 문제가 발견되면 서버에서 한 번에 수정해 모든 사용자에게 즉시 반영할 수 있다. 반면 수많은 기기에 흩어진 로컬 모델은 취약점이나 편향이 드러나도 회수와 수정이 느리다. 배포 이후의 유지·관리 전략을 처음부터 세워 두어야 한다. 또한 로컬에서 처리한다고 규제 의무가 면제되는 것도 아니다. 유럽의 GDPR, 미국 캘리포니아의 CCPA/CPRA, 의료정보를 다루는 HIPAA는 물론, 새로 등장하는 EU AI Act 같은 AI 전용 규제의 준수 책임은 여전히 개발자에게 있다. 사용자에게 데이터가 어디서 어떻게 처리되는지 투명하게 알리고 동의를 관리하는 절차 역시 온디바이스라고 해서 예외가 아니다.

 

결국 온디바이스 AI는 ‘만능’이 아니라 ‘설계’의 문제다. 성능·프라이버시·비용이라는 이점은 로컬 처리라는 사실만으로 보장되지 않으며, 모델과 기기, 구현 방식, 그리고 작업의 성격에 따라 크게 달라진다. 그래서 성숙한 제품일수록 순수 온디바이스를 고집하기보다, 가벼운 작업은 기기 안에서 처리하고 무거운 작업은 클라우드로 넘기는 ‘하이브리드’ 구조를 택한다. 온디바이스 AI를 잘 쓰는 길은 무조건 기기 안에 가두는 데 있지 않다. 프라이버시의 허점, 압축의 대가, 발열의 벽, 기기 파편화, 유지·규제라는 다섯 가지 함정을 먼저 인지하고, 그에 맞게 설계하고 검증하는 데 있다. 편리함의 이면을 아는 사람만이 이 기술을 제대로 다룰 수 있다.