같은 앱을 모든 기기에서 똑같이 돌리려다 보면 둘 중 하나가 됩니다. 낮은 기기에 맞추면 좋은 기기가 아깝고, 좋은 기기에 맞추면 낮은 기기에서 아예 안 돌아갑니다. 저는 이 문제를 동작 단계를 넷으로 나누는 방식으로 풀었습니다. 이 글은 왜 넷인지, 그리고 단계를 정하는 기준을 어떻게 바꿨는지에 대한 기록입니다.
기능을 끄는 대신 표현을 낮췄다
처음 떠올린 방법은 “낮은 기기에서는 그 기능을 끈다”였습니다. 하지만 그러면 낮은 기기 사용자는 핵심 가치를 아예 못 씁니다.
그래서 방향을 바꿨습니다. 낮은 단계에서는 긴 문장을 만들어 내는 대신 필요한 항목만 뽑아내는 방식으로 내렸습니다. 표현은 단순해지지만 “무엇을 해야 하는지”는 여전히 나옵니다. 가장 낮은 단계는 큰 모델 없이도 동작하도록 설계했습니다.
처음 기준은 보수적이었다
단계를 정하는 기준으로 처음에는 메모리, 저장공간, 프로세서 같은 하드웨어 정보를 봤습니다. 여기에 발열과 배터리 상태를 얹었습니다.
문제는 이 값들이 실제 속도를 정확히 예측하지 못한다는 점이었습니다. 사양이 비슷해도 실제로 돌려 보면 차이가 컸습니다. 그래서 기준을 보수적으로 잡을 수밖에 없었고, 결과적으로 충분히 돌릴 수 있는 기기가 낮은 단계로 내려가는 일이 생겼습니다.
실제로 측정한 값으로 바꿨다
그래서 실행 중에 나오는 실제 수치를 기록하도록 바꿨습니다. 음성을 글로 바꾸는 데 걸린 시간과 원본 길이의 비율, 그리고 초당 처리량을 단계별로 저장합니다.
여기서 규칙을 하나 정했습니다. 실측값으로는 단계를 내리기만 하고 올리지는 않습니다. 하드웨어 기준에서 시작해, 실제로 느린 기록이 쌓였을 때만 한 단계 내려갑니다. 반대로 한 번 빨랐다고 바로 올리지는 않습니다.
이렇게 한 이유는 단계가 왔다 갔다 하는 것을 막기 위해서입니다. 올리고 내리기를 반복하면 사용자는 같은 작업이 어떤 날은 되고 어떤 날은 안 되는 경험을 하게 됩니다. 실제로 빠른 기록과 느린 기록을 섞어 넣어도 단계가 흔들리지 않는지 확인하는 검사를 따로 넣었습니다.
아직 남은 것
지금 기준값은 잠정치입니다. 실제 수치는 기기에서 첫 작업을 돌려야 쌓이기 시작합니다. 메모리 용량대별로 자료가 모이면 그때 다시 조정할 계획이고, 그 전까지는 보수적으로 두었습니다. 사용자가 직접 측정값을 초기화할 수 있는 항목도 넣어 두었습니다. 기기 상태가 바뀌었을 때 과거 기록에 계속 묶이지 않게 하기 위해서입니다.
공식 문서가 말하는 기기 상태와 성능 제한
기기 등급을 하드웨어 사양만으로 정하기 어려운 이유는 제조사 문서에서도 확인됩니다. Apple 지원 문서는 기기가 따뜻해지는 일이 설정, 백업 복원, 큰 소프트웨어 업데이트, 무선 충전, 그래픽이나 프로세서를 많이 쓰는 앱(카메라 앱 포함), 고화질 영상 스트리밍 중에 정상적으로 생길 수 있다고 설명합니다. 온도가 너무 높아지면 기기가 내부 부품을 보호하려고 충전을 늦추거나 멈추고, 화면을 어둡게 하거나, 일부 앱에서 프레임 속도를 낮추거나 처리 시간을 늘릴 수 있다고도 적혀 있습니다. 같은 기기도 온도에 따라 성능이 달라진다는 뜻이므로, 한 번 잰 값을 영구적인 등급으로 쓰기 어렵습니다.
Android의 열 관리 문서(ADPF)는 이 문제를 더 구체적으로 다룹니다. 열 상태를 NONE부터 SHUTDOWN까지 일곱 단계로 나누고, 앱은 작업량이 감당할 수준보다 빨리 제한(throttling)에 닿을 것 같으면 프레임 속도나 그래픽 품질, 네트워크 작업을 줄이라고 안내합니다. 눈여겨볼 대목은 주의 사항입니다. 일부 기기는 실제로 제한이 걸려 있는데도 NONE을 돌려줄 수 있고, 같은 여유 수치(headroom)가 기기마다 다른 상태로 대응될 수 있다고 합니다. 표시된 값 하나만 믿지 말고 다른 값과 맞춰 보라는 것이 문서의 입장입니다.
| 구분 | 공식 문서의 설명 | 이 글의 단계 설계와 닿는 점 |
|---|---|---|
| Apple 지원 문서 | 과열 시 충전 지연, 화면 어두워짐, 일부 앱의 프레임 속도 저하나 처리 시간 증가 가능 | 같은 기기도 상태에 따라 속도가 달라지므로 단계는 내릴 수 있어야 합니다. |
| Android 열 관리 문서 | 상태값이 NONE이어도 제한 중일 수 있고, 같은 수치가 기기마다 다른 상태로 대응될 수 있음 | 사양표나 상태 표시만으로 단정하지 않고 실제 처리 기록을 함께 봅니다. |
| Android 열 관리 문서 | 제한에 닿기 전에 작업량을 줄이고, 여유가 회복되면 조심스럽게 다시 올리라고 안내 | 내릴 때는 빠르게, 올릴 때는 신중하게 하는 규칙과 같은 방향입니다. |
음성 인식 모델의 크기별 자원 기준
음성을 글로 바꾸는 모델의 크기가 단계 설계에 직접 영향을 줍니다. 오픈소스 whisper.cpp의 README는 모델별 디스크와 메모리 사용량을 표로 보여 줍니다. tiny는 디스크 75MiB에 메모리 약 273MB, base는 142MiB에 약 388MB, small은 466MiB에 약 852MB, medium은 1.5GiB에 약 2.1GB, large는 2.9GiB에 약 3.9GB입니다. 또 정수 양자화를 지원해 같은 모델을 더 적은 메모리와 디스크로 돌릴 수 있고, 하드웨어에 따라 처리도 더 효율적일 수 있다고 설명합니다.
| 모델 | 디스크 | 메모리 |
|---|---|---|
| tiny | 75 MiB | 약 273 MB |
| base | 142 MiB | 약 388 MB |
| small | 466 MiB | 약 852 MB |
| medium | 1.5 GiB | 약 2.1 GB |
| large | 2.9 GiB | 약 3.9 GB |
이 수치는 필요한 자원의 하한을 가늠하는 용도이지 속도를 보장하는 값이 아닙니다. 위의 열 관리 문서가 보여 주듯 같은 사양에서도 실제 속도는 달라질 수 있으므로, 사양으로 시작 단계를 잡고 실제 처리 시간으로 조정하는 구조가 설득력을 갖습니다.
참고한 공식 문서 (2026년 10월 18일 기준)
- Apple 지원: iPhone이나 iPad가 너무 뜨겁거나 차가울 때
- whisper.cpp README: 플랫폼, 메모리 사용량, 양자화
- Android 개발자 문서: 열 관리(Thermal API)
영어 원문의 내용을 한국어로 풀어 쓴 것이며, 정책과 문서는 바뀔 수 있으니 실제 적용 전에는 원문을 다시 확인하시기 바랍니다.