안드로이드 가속의 현실: NNAPI, NPU, 그리고 GPU 가속은 아직 연구 중

지난 장에서 우리는 왜 안드로이드 실전 구현이 보통 CPU 기준선에서 시작하는지 보았습니다. 이번 장에서는 그 이유를 한 걸음 더 깊게 파고들어 보겠습니다.

초보자 입장에서는 이런 생각이 자연스럽습니다.

"가속이 있다면 당연히 GPU부터 써야 하는 것 아닌가?"

이 질문은 아주 좋습니다. 다만 안드로이드에서는 답이 생각보다 단순하지 않습니다. 데스크톱의 CUDA처럼, 또는 애플 기기의 Metal처럼, 한 가지 경로로 쭉 밀어붙이기 어렵기 때문입니다. 안드로이드의 가속은 CPU, 추론 런타임, NNAPI, 제조사 드라이버, NPU/DSP, 때로는 GPU가 서로 얽혀 있는 구조입니다.¹²

이번 장의 목표는 딱 하나입니다.

왜 실전에서는 무작정 GPU부터 붙이기보다 CPU 중심 기준선을 먼저 만들고, 필요한 경우에만 기기별 가속을 검토하는 편이 더 안전한지 이해하는 것.

그리고 그 이해를 바탕으로, Whisper Tiny나 Base를 어디에 얹는 것이 현실적인지 감을 잡는 것입니다.

Step 1. 먼저, 안드로이드에서 "가속"이 무엇인지부터 정리하자

안드로이드에서 모델을 돌린다고 해서, 앱이 곧바로 NPU나 GPU와 직접 대화하는 것은 아닙니다. 보통은 중간에 런타임이 있고, 그 아래에 드라이버가 있고, 그 뒤에야 실제 하드웨어가 있습니다. Android 공식 문서도 NNAPI를 앱이 직접 모든 하드웨어 세부를 다루지 않게 해 주는 중간 계층으로 설명합니다.¹²

아주 단순하게 그리면 흐름은 이렇습니다.

앱 → 추론 런타임 → NNAPI 또는 다른 백엔드 → 제조사 드라이버 → NPU/DSP/GPU/CPU

여기서 중요한 포인트는 두 가지입니다.

첫째, NNAPI 자체가 곧 NPU는 아닙니다. NNAPI는 길을 안내하는 표준 통로에 가깝습니다.

둘째, 같은 모델이라도 어떤 기기에서는 전용 가속기로 잘 가고, 어떤 기기에서는 일부만 가고, 어떤 기기에서는 결국 CPU로 돌아올 수 있습니다.

이 차이 때문에 초보자가 "가속을 켰는데 왜 별로 안 빨라지지?"라는 당황스러운 순간을 자주 만나게 됩니다.

Step 2. CPU가 여전히 기준선인 이유

CPU는 화려하지 않습니다. 하지만 안드로이드에서는 여전히 가장 믿을 만한 출발점입니다.

Whisper Tiny와 Base를 떠올려 봅시다. 공식 공개 정보 기준으로 Tiny는 약 39M, Base는 약 74M 파라미터 규모입니다.³ 이 둘은 정확도와 속도의 균형을 보면서 모바일에서 실험을 시작하기 좋은 크기입니다.

왜 CPU부터 시작하느냐고 묻는다면, 답은 성능보다 예측 가능성에 있습니다.

CPU 경로의 장점은 분명합니다.

• 거의 모든 기기에서 동작 기준을 맞추기 쉽습니다.

• 디버깅이 상대적으로 쉽습니다.

• 기기마다 편차가 있어도 원인 파악이 비교적 단순합니다.

• 가속 드라이버 문제를 먼저 의심하지 않아도 됩니다.

쉽게 말하면 CPU는 느릴 수는 있어도, 적어도 "왜 안 되는지"를 이해하기 쉽습니다.

반면 가속 경로는 잘 되면 멋지지만, 안 되면 원인이 여러 층에 숨어 있습니다. 모델 변환 문제인지, 연산 지원 문제인지, 드라이버 문제인지, 기기별 펌웨어 차이인지 한 번에 파악하기 어렵습니다.

그래서 실전에서는 보통 이렇게 갑니다.

Whisper Tiny로 CPU 기준선을 만든다.

잘 되면 Whisper Base로 올려 본다.

그다음에야 기기별 가속 옵션을 붙인다.

이 순서가 지루해 보여도, 실제로는 가장 빠른 길인 경우가 많습니다.

Step 3. NNAPI는 "마법의 가속 버튼"이 아니라 "표준 통로"였다

NNAPI를 처음 접하면 버튼 하나로 성능이 확 좋아질 것처럼 느껴집니다. 하지만 현실의 NNAPI는 만능 부스터라기보다 표준화된 통로에 더 가깝습니다.¹

이 통로의 장점은 분명합니다. 앱이 칩셋마다 다른 가속기를 일일이 직접 다루지 않아도 된다는 점입니다. 하지만 초보자가 꼭 알아야 할 현실이 있습니다.

• 모델이 쓰는 연산이 해당 드라이버에서 잘 지원되는지

• 정밀도와 형식이 잘 맞는지

• 연산 일부만 가속되고 나머지는 CPU로 섞여 실행되는지

• 초기 컴파일 시간과 런타임 오버헤드가 얼마나 큰지

즉, NNAPI를 켰다고 해서 항상 빨라지는 것은 아닙니다.

그리고 2026년 시점에서 더 중요한 사실이 하나 있습니다. Android 공식 문서 기준으로 NNAPI는 Android 15에서 지원 중단(deprecated) 되었습니다.⁴ 문서도 앞으로는 많은 기기에서 CPU 백엔드 사용이 늘어날 수 있으므로, 성능에 민감한 워크로드는 다른 경로로 이전을 검토하라고 안내합니다.¹⁴

이 말은 NNAPI가 당장 완전히 사라진다는 뜻은 아닙니다. 기존 기기와 런타임, HAL 계층은 여전히 중요한 의미가 있습니다. 하지만 실무 관점에서는 예전보다 더더욱 이렇게 이해하는 편이 맞습니다.

NNAPI는 무조건 켜는 기본 옵션이 아니라, 기기별 검증을 전제로 한 선택지다.

Step 4. NPU는 하나가 아니다: 제조사별 가속 경로의 차이

초보자가 자주 놓치는 부분이 여기입니다. "NPU"라는 단어는 하나지만, 실제 안드로이드 생태계의 NPU는 하나가 아닙니다.

기기마다 칩셋도 다르고, 드라이버도 다르고, 잘 맞는 런타임도 다릅니다. 같은 모델, 같은 앱, 같은 코드라도 실제 실행 경로는 기기마다 달라질 수 있습니다.

이 말은 아주 중요합니다.

같은 앱이라도 기기가 바뀌면 성능과 안정성, 발열 특성이 달라질 수 있다는 뜻입니다.

그래서 안드로이드에서 가속을 이야기할 때는 단순히 "NPU 지원"이라고 쓰면 부족합니다. 더 현실적인 질문은 이렇습니다.

• 이 모델이 이 칩셋의 드라이버와 잘 맞는가?

• 이 기기에서 실제로 어느 연산이 가속되는가?

• 속도뿐 아니라 발열과 배터리도 안정적인가?

이 세 질문에 답하지 못하면, "가속 지원"이라는 문장은 설명이 아니라 구호에 가까워집니다.

Step 5. CPU, 표준 가속 통로, 제조사 경로를 한 번에 비교해 보자

아래 표는 초보자가 처음 감을 잡기에 좋은 요약입니다.

이 표에서 가장 중요한 줄은 사실 첫 번째 줄입니다.

실무에서는 대개 CPU를 기준선으로 잡고, 그 위에 선택적 가속을 얹는 방식이 가장 안전합니다. 제조사별 가속은 특정 단말군이 정해져 있을 때 강력해질 수 있지만, 범용 앱에서는 관리 비용이 빠르게 커집니다.

Step 6. 그럼 GPU는 왜 아직 "연구 중"이라고 말할까

이제 핵심 질문으로 가 봅시다.

안드로이드의 GPU 가속은 왜 아직 연구·실험 단계 성격이 강하다고 말할까요?

이유는 단순히 "느려서"가 아닙니다. 어떤 장면에서는 분명 인상적인 결과가 나올 수도 있습니다. 문제는 일관성입니다.

예를 들어 whisper.cpp는 Vulkan 백엔드를 지원합니다.⁵ 겉으로만 보면 "좋네, 그럼 GPU로 가면 되겠네"라고 생각하기 쉽습니다.

그런데 현실은 조금 다릅니다. AOSP 문서도 Vulkan 기능은 하드웨어와 드라이버 지원에 의존한다고 설명합니다.⁶ 즉, GPU 가속의 출발점부터 이미 기기 하드웨어와 드라이버 상태에 크게 좌우됩니다.

초보자 기준으로 풀어 말하면 이런 문제들이 생깁니다.

첫째, 기기마다 GPU 드라이버 성숙도가 다릅니다.

둘째, 딥러닝 추론에 필요한 연산이 그래픽용 API 위에서 항상 예쁘게 맞아떨어지지 않습니다.

셋째, 메모리 이동 비용이 무시되지 않습니다. 오디오 전처리, 텐서 복사, 커널 실행, 결과 회수 과정에서 생각보다 손실이 생길 수 있습니다.

넷째, 발열과 지속 성능 문제가 큽니다. 짧은 벤치마크에서는 빨라 보여도, 몇 분만 지나면 쓰로틀링으로 속도가 떨어질 수 있습니다.

다섯째, 런타임과 빌드 복잡도가 커집니다. CPU 앱은 잘 도는데 GPU 빌드에서만 깨지는 순간이 생기면, 초보자에게는 거의 다른 프로젝트처럼 느껴집니다.

그래서 지금 시점의 안드로이드 GPU 가속은 가능성은 분명 있지만, 범용 배포 앱의 기본 카드라기보다 연구실 카드, 실험 카드, 또는 특정 기기 타깃 카드에 더 가깝습니다.

한마디로 정리하면 이렇습니다.

GPU 가속은 "될 수도 있음"의 영역이지, 아직 "누구에게나 바로 권장"의 영역은 아닙니다.

Step 7. 왜 실전에서는 CPU 우선 전략이 더 안전할까

이쯤 되면 답이 보입니다. 실전 앱은 데모보다 훨씬 많은 것을 버텨야 합니다.

앱스토어 배포를 한다고 생각해 봅시다. 사용자의 휴대폰은 제각각입니다. 어떤 사람은 플래그십을 쓰고, 어떤 사람은 중급형 기기를 씁니다. 같은 안드로이드여도 실제 하드웨어 세계는 훨씬 다양합니다.

이때 개발자가 원하는 것은 최고 점수 하나가 아닙니다. 평균적으로 덜 망가지는 구조입니다.

그래서 보통의 우선순위는 이렇게 잡는 편이 좋습니다.

1. CPU로 반드시 동작하는 기준선을 만든다.

2. Whisper Tiny로 안정성을 먼저 확보한다.

3. 안정적이면 Whisper Base까지 올려 본다.

4. 그다음 기기별 가속 옵션을 붙여서 차이를 측정한다.

5. 특정 단말군에서 이득이 확인되면 그때 전용 가속 정책을 검토한다.

6. 마지막으로 정말 필요할 때만 GPU 실험에 들어간다.

이 순서가 좋은 이유는 실패했을 때 뒤로 물러날 발판이 있기 때문입니다.

CPU 기준선이 있으면, 가속이 흔들려도 서비스는 유지할 수 있습니다.

반대로 CPU 기준선 없이 바로 GPU로 가면, 실패했을 때 비교 대상조차 없습니다. 이건 등산화를 안 신고 암벽부터 붙는 것과 비슷합니다.

Step 8. 바로 써볼 수 있는 앱은 왜 도움이 될까

이론만 보면 감이 잘 안 올 수 있습니다. 다행히 바로 설치해서 흐름을 볼 수 있는 앱과 데모도 있습니다.

예를 들어 speech-android 같은 데모는 안드로이드에서 로컬 STT, TTS, VAD가 한 앱 안에서 어떻게 엮이는지 보여 줍니다.⁷ 이 데모가 좋은 이유는 두 가지입니다.

첫째, "온디바이스 음성 앱이 실제로 어떤 UX를 내는지"를 바로 체감할 수 있습니다.

둘째, "가속이 들어가는 앱이 실제로는 얼마나 복잡한 파이프라인 위에 서 있는지"를 눈으로 볼 수 있습니다. 음성 인식만 있는 것이 아니라 VAD, 상태 전환, 후처리, UI까지 함께 움직이기 때문입니다.

즉, 바로 써볼 수 있는 앱은 "완성품"이라기보다 현실 감각을 주는 실습장에 가깝습니다.

Step 9. 초보자를 위한 권장 전략: 이렇게 가면 덜 헤맨다

이제 실제 선택 기준을 아주 실무적으로 정리해 보겠습니다.

범용 안드로이드 앱을 만들 때

가장 추천하는 전략은 CPU 기본선 확보입니다. 그 위에 기기별 실험 옵션을 따로 두는 방식이 안전합니다.

처음에는 Whisper Tiny를 CPU로 안정화하고, 그다음 Base를 시험합니다. 이후 설정 메뉴나 내부 실험 플래그로 가속 옵션을 분리해 두면 좋습니다. 이렇게 하면 모든 기기에서 최소 기능은 유지하면서, 잘 맞는 기기에서는 추가 이득을 볼 수 있습니다.

특정 기업 단말이나 사내 전용 기기만 배포할 때

이 경우는 이야기가 달라집니다. 단말이 몇 종으로 고정되어 있다면 전용 가속 경로를 더 적극적으로 써 볼 만합니다. 검증 범위가 좁아지기 때문입니다.

즉, 불특정 다수의 시장에 내놓는 앱과 사내 키오스크 앱은 전략이 달라야 합니다.

연구용 프로토타입이나 성능 탐색을 할 때

이때는 GPU 실험도 충분히 가치가 있습니다. 다만 목표를 분명히 해야 합니다. "서비스 기본 경로"를 만드는 것이 아니라 "가능성 탐색"을 하는 것입니다.

이 차이를 구분하지 않으면 프로젝트가 자꾸 흔들립니다.

Step 10. 이 장에서 꼭 기억할 문장

안드로이드에서 가속은 단순히 "CPU보다 GPU가 빠르다"라는 한 줄 문제로 끝나지 않습니다. 추론 런타임과 드라이버, 기기별 가속기, 메모리 이동, 발열, 지속 성능이 함께 얽혀 있습니다.¹²

Whisper Tiny와 Base를 기준으로 온디바이스 ASR를 시작하는 초보자라면, 가장 안전한 순서는 다음과 같습니다.

CPU로 기준선을 만들고, 그다음 기기별 가속을 검토하고, GPU는 마지막 실험 카드로 남겨 두는 것.

이 전략이 보수적으로 들릴 수 있습니다. 하지만 모바일 실전에서는 화려함보다 안정성, 재현성, 배포 가능성이 훨씬 중요합니다.

안드로이드의 GPU 가속은 분명 매력적입니다. 그러나 지금 시점에서는 기기·드라이버·런타임 편차가 커서, 아직은 연구와 실험의 냄새가 더 진한 영역입니다.⁵⁶

그러니 오늘의 결론은 분명합니다.

실전 앱을 만든다면 CPU 우선, GPU는 신중하게.

이 원칙을 잡아 두면 다음 장의 실전 적용 사례와 운영 체크리스트가 훨씬 또렷하게 보이기 시작합니다.

참고

¹Neural Networks API | Android Developers

²NNAPI Runtime | Android Open Source Project

⁴NNAPI Migration Guide | Android Developers

⁶Implement Vulkan | Android Open Source Project