출처: https://hpbn.co/optimizing-for-mobile-networks/
Performance of Wireless Networks: Optimizing for Mobile Networks - High Performance Browser Networking (O'Reilly)
What every web developer must know about mobile networks, protocols, and APIs provided by browser to deliver the best user experience.
hpbn.co
[8장 모바일 네트워크 최적화]
1. 배터리 전력 절약
2. 주기적/비효율적인 데이터 전송 제거
- 불필요한 애플리케이션 Keepalive 제거
3. 네트워크 지연 오버헤드 예상
- RRC 상태 전이 고려하기
- 사용자 상호작용과 네트워크 통신의 분리
4. 다양한 네트워크 인터페이스 가용성을 고려한 설계
5. 데이터를 한번에 전송하고 유휴 상태로 돌아가기
6. WiFi 네트워크로 오프로드
7. 프로토콜 및 애플리케이션 최적화
8장 모바일 네트워크 최적화
- 모바일 네트워크
- 모바일 네트워크의 성능 전략 핵심
=> 지연 최소화와 처리량 최적화는 모바일에서 더욱 중요
=> 웹에서의 성능 최적화 기법 대부분이 모바일에도 유효
- 모바일 네트워크의 고유 제약
=> 아래 1번은 플랫폼별로 다양하고 관련 참고자료도 많으므로 이 챕터에서는 다루지 않음
1) 반응형 디자인 등 디바이스의 형태적 제약
2) 무선 네트워크 특성
3) 배터리 수명에 미치는 영향
1. 배터리 전력 절약
- 설계 방안
* [사용 용어] Radio: 무선 네트워크를 통해 통신할 때 사용하는 물리적인 무선 통신 계층
- 무선통신 물리계층에서의 배터리 수명 최적화를 위해 고려할 제약조건
1) 무선 신호를 최대 전력으로 사용할 경우 몇 시간 만에 배터리를 모두 소모할 수 있음
2) 무선 기술 세대가 거듭될수록 전력 요구량 증가
3) 무선은 화면 다음으로 전력 소모가 큼
4) 데이터 전송량에 전력 소비가 비례하지는 않음
- 설계 방안
=> 무선통신 물리계층이 켜진 동안 데이터를 최대한 전송하고, 추가 전송 횟수는 줄이는 것이 핵심
- WiFi도 무선통신 물리계층을 사용하지만
=> 2G, 3G, 4G와는 기본적인 작동원리/성능특성 (지연시간, 처리량, 전력 소비 패턴 등)이 다름
=> 설계 시 유의점? WiFi와 모바일 네트워크는 네트워크 동작 방식이 달라야 할 수도 있음
* 상황에 따라 각 네트워크 환경에 맞는 최적화 전략이 필요함
- 최적화 위한 측정도구
- ARO (Application Resource Optimizer)
=> AT&T에서 개발한 도구 (2025년 기준으로는 현재 거의 사용되고 있지 않음)
=> Collector 기능: 실제 기기 또는 에뮬레이터에서 작동
* 데이터 전송, 라디오 상태, 사용자 상호작용 등을 기록
=> Analyzer 기능: trace를 분석하여 라디오 상태, 에너지 사용, 트래픽 패턴 파악
* 압축 누락, 중복 전송 등 성능 문제에 대한 권장 사항 제공
* 측정치는 실제 수치가 아닌 기기/네트워크 모델 기반 시뮬레이션 결과
<더 알아보기>
| 도구 이름 | 분석 범위 | 플랫폼 | 장점 |
| Android Studio Profiler | 실시간 네트워크 + 전력 분석 | Android | IDE 내장, 편리 |
| Battery Historian | 전력 사용 기록 전체 분석 | Android | wakelock 분석에 강함 |
| Firebase Performance | 사용자 기반 성능 분석 | Android / iOS | 배포 후 실제 데이터 확인 가능 |
| Xcode Instruments | 에너지, CPU, GPS, 네트워크 | iOS | 애플 공식 도구, 정확함 |
| Charles Proxy + Wireshark + Power Profiler(전력 측정 도구) 조합 | 트래픽 + 수동 전력 측정 | 전체 | 다양한 프로토콜 분석 가능 |
2. 주기적/비효율적인 데이터 전송 제거
- 주기적인 네트워크 접근을 최소화하기
1) 폴링(Polling)은 모바일 네트워크에서 매우 비효율적이므로 최소화해야 함
2) 가능한 푸시 전달/알림을 사용해야 함
* 일반적으로 푸시 방식은 폴링보다 효율적이나 고빈도 푸시 스트림도 그만큼 전력을 소모
3) 송/수신 요청은 묶어서 처리하거나 집계해야 함
4) 중요하지 않은 요청은 무선통신 물리계층이 활성화 상태이기 전까지는 나중으로 지연시키기
- 상황별 최적화 방법
1) 실시간 업데이트가 필요한 경우 고려사항
=> 업데이트 주기가 사용자 기대와 부합하는가?
=> 고정된 주기 대신 상황에 따라 동작하도록 할 수 있는가? (적응형 전략, Adaptive Strategy)
=> 수신 또는 송신 요청을 더 적은 네트워크 호출로 묶을 수 있는가?
=> 수신 또는 송신 요청을 나중으로 지연시킬 수 있는가?
2) 푸시알림 집계전략
=> 여러 알림을 하나의 푸시 이벤트로 묶으면 전력 효율이 크게 향상됨
=> 간격, 사용자 설정, 배터리 수준 등에 따라 유동적으로 조정 가능
=> 백그라운드 앱에서 특히 유용함
3) 비콘(Beacon) 요청의 전송 최적화
* 비콘 요청: 웹 브라우저에서 백그라운드로 데이터를 전송할 수 있게 해주는 경량 요청 방식
=> 간헐적인 측정 및 분석용 핑 요청은 배터리 소모를 증가시킴
=> 즉시 전송하는 것 대신 로컬에 저장한 뒤 무선통신 물리계층의 활성화 시 묶어서 전송하는 방식 권장
=> 자신이 직접 작성하지 않은 코드인 서드파티 라이브러리나 스니펫을 사용할 때에 숨겨진 네트워크 요청이 있을 수 있으므로 확인하기
4) 간헐적인 네트워크 접근의 최소화
=> 간헐적인 네트워크 접근은 점진적 향상/로딩 등의 기술이 필요
* 점진적 향상 (Progressive Enhancement)?
가장 기본적인 기능부터 먼저 제공하고, 네트워크나 환경이 괜찮으면 추가 기능을 점차적으로 활성화하는 방식
* 점진적 로딩 (Progressive Loading)?
전체 데이터를 한 번에 불러오는 게 아니라, 필요한 만큼 조금씩 로딩하는 전략
-> 무한 스크롤, 이미지가 화면에 보여질 때만 불러오는 lazy loading, 앱 첫 화면에서 꼭 필요한 정보만 먼저 로드하고 나머지는 백그라운드에서 천천히 로드하는 방식 등
=> RRC 상태 전이가 발생하며 지연시간 급증 (수백~수천 밀리초)
* RRC 상태 전이(RRC State Transition)?
모바일 기기의 무선 통신 모뎀이 사용하는 전력 상태를 바꾸는 과정
-> 모바일 네트워크(3G, 4G, 5G 등)에서는 배터리를 절약하기 위해 기기가 항상 고성능 상태로 데이터를 보내거나 받는 게 아니라, 필요할 때만 무선 자원을 활성화
=> 사용자와 상호작용하는 트래픽에는 특히 주의 필요
- 푸시 전달 방식의 활용
=> 네이티브 앱은 플랫폼별 푸시 서비스(Firebase Cloud Messaging, APNs 등)를 사용하는 것이 이상적
=> 웹 앱은 SSE(Server-Sent Events) 또는 WebSocket을 통해 지속적인 연결을 유지하고 지연을 줄이는 것이 효과적
=> 폴링 및 XHR 방식은 반복 호출로 인해 전력 소모 및 네트워크 자원 낭비가 크므로 지양해야 함
* 폴링 (Polling): 클라이언트가 주기적으로 서버에 데이터를 요청하는 방식
* XHR (XMLHttpRequest): 브라우저에서 서버와 데이터를 주고받기 위한 API로 과거 AJAX 통신의 중심 기술
=> XHR는 현재 fetch, Axios가 대체하고 있음
- [참고] 백그라운드 업데이트의 에너지 비용 계산
- 주기적인 폴링이 배터리 수명에 미치는 영향 계산
=> 일반적인 3G/4G 모바일 기기의 범위 내에 있는 값
- 배터리 용량: 5Wh (와트시) 또는 18,000줄(J)
- 라디오가 대기 상태에서 연결 상태로 전환 후 다시 돌아오는 데 필요한 에너지: 10줄
- 1분마다 폴링할 경우, 시간당 약 600줄의 에너지 소비
- 600줄은 전체 배터리 용량의 약 3%에 해당
- 즉, 하나의 애플리케이션만으로도 1시간에 전체 배터리의 약 3%를 소모할 수 있음
=> 여기에 서로 다른 간격으로 폴링하는 앱이 몇 개만 있어도 오전 중에 배터리가 모두 소모될 수 있음.
=> 빈번하고 버퍼링되지 않은 푸시 업데이트가 더 높은 에너지 소비를 유발할 수도 있음
- 불필요한 애플리케이션 Keepalive 제거하기
* Keepalive: 클라이언트와 서버 사이의 네트워크 연결(TCP, HTTP 등)이 끊어지지 않도록 주기적으로 신호를 보내는 것
- 불필요한 Keepalive의 문제
=> TCP/UDP 연결은 무선통신 물리계층의 상태와 무관하게 유지 가능
* OSI 7계층에서 보면 TCP/UDP는 전송 계층, 무선통신은 물리/데이터링크 계층임
* 무관하게 유지가 가능하다? 잠깐 신호가 약해져도, TCP/UDP는 자체적으로 회복을 시도하고 사용자는 끊어진 줄도 모르게 연결이 이어지는 경우가 많다는 것을 의미함
=> 무선통신 물리계층이 저전력 상태여도 연결은 통신사 네트워크에서 유지됨
=> 외부에서 패킷이 오면 통신사가 기기에 알려 무선통신 물리계층을 활성화하고 데이터 전송을 재개함
* 통신사의 코어 네트워크에 도달하면 기기의 상태를 확인한 후 무선통신 물리계층이 비활성화 상태라면 활성화 시킴
- Keepalive가 왜 문제인가?
=> 잘못된 이해로 인해 불필요한 Keepalive를 설정하는 경우가 많음
=> 무선통신 물리계층을 자주 활성화시키면 배터리 소모가 크게 증가함
- 단, 대부분의 모바일 통신사는 5~30분의 NAT 연결 타임아웃을 설정
=> 유휴 상태의 연결이 끊어지지 않도록 하려면 5분 간격으로 주기적인 Keepalive가 필요할 수 있음
=> 하지만 더 짧은 간격으로 Keepalive를 보내야 하는 상황이라면, 우선 서버/프록시/로드밸런서 설정을 점검하는 것이 좋음
3. 네트워크 지연 오버헤드 예상
- 네트워크 지연 오버헤드
=> 모바일 네트워크에서 하나의 HTTP 요청만으로도 수백~수천 밀리초의 네트워크 지연(latency) 오버헤드가 발생할 수 있음
=> 원인은 높은 RTT, DNS 조회, TCP 연결, TLS 핸드셰이크, 제어평면 설정 등의 오버헤드 때문임
* 왕복시간 (RTT, round-trip time)? 클라이언트가 서버에 요청을 보내고, 서버가 응답을 보내기까지의 총 시간
* TLS 핸드셰이크? 클라이언트와 서버 간에 보안 연결을 설정하는 과정 (암호화 알고리즘, 세션 키, 인증서 등이 교환 등)
* 제어 평면(Control-Plane)? 모바일 네트워크에서 데이터를 전송하는 데 필요한 제어 정보(연결설정/상태정보/라우팅 정보 등)를 전송하는 채널
1) 가장 이상적인 경우? 아래와 같이 새로운 연결을 설정하지 않아도 되므로 오버헤드가 줄어듦
=> 무선통신 물리계층이 이미 고성능 상태에 있고 (모바일 네트워크에서 무선통신 물리계층이 활성화되어 있어 데이터를 빠르게 주고받을 수 있는 상태)
=> DNS가 미리 조회되었으며 (사용자가 이전에 방문한 사이트로 DNS 데이터가 캐시 등에 저장되어 있는 경우)
=> 재사용 가능한 TCP 연결이 존재하는 경우 (Keep-Alive 또는 HTTP/2를 이용해서 기존 연결을 재사용할 수 있는 경우)
2) 하지만 연결이 없거나 이미 사용 중인 경우? 데이터 전송 전 추가적인 여러 RTT가 필요
=> 3G 환경에서는 수 초의 지연, 4G 환경에서도 약 0.5초 이상의 오버헤드가 발생할 수 있음
- RRC 상태 전이 고려하기
- 모바일 기기가 몇 초 이상 유휴 상태였다면
=> 첫 번째 패킷 전송 시 수백~수천 밀리초의 RRC(Radio Resource Control) 지연이 발생할 수 있다고 가정하고 대비해야 합
=> 4G에서는 약 100ms, 3.5G+에서는 150~500ms, 3G에서는 500~2,500ms
- RRC를 고려하지 않는다면
=> 네트워크는 항상 연결되어 있는 것처럼 보이지만, 실제 무선(RF) 계층에서는 RRC가 계속 연결과 해제를 반복함
=> RRC를 고려하지 않고 설계하는 경우, 사용자 입장에서는 지연을 분명하게 느낄 수 있음
- RRC를 고려한 설계
=> RRC 상태 머신은 각 무선 표준마다 다르게 구성됨
* RRC 상태 머신? 무선 네트워크에서 기기의 연결 상태를 관리하는 시스템
=> RRC 상태 머신은 각 기기의 라디오 네트워크에 의해 제어됨
=> 데이터 전송이 필요할 때 고전력 상태로 승격
=> 네트워크 설정에 따라 타임아웃 시 저전력 상태로 강등
=> LTE의 상태 전이는 10~100ms 소요
=> HSPA+는 LTE와 유사한 성능
* HSPA+? 3G 네트워크의 개선된 버전
=> HSPA 및 CDMA(3G)의 상태 전이는 수 초 소요
=> 모든 네트워크 전송은 데이터 크기와 무관하게 에너지 테일을 동반
* 에너지 테일(energy tail)? 네트워크 전송 후에도 일정 시간 동안 전력 소모가 지속되는 현상
- 사용자 상호작용과 네트워크 통신의 분리
- 실제 연결이 느리거나 요청 처리에 시간이 걸리더라도?
=> 즉각적인 피드백을 제공함으로써 빠르게 느껴질 수 있음
=> UI/UX 설계 시 디자이너와 협업하여 네트워크 지연을 고려한 사용자 흐름을 반영해야 함
4. 다양한 네트워크 인터페이스 가용성을 고려한 설계
1. 모바일 애플리케이션은 일반적인 네트워크 오류 상황에 견딜 수 있을 만큼 견고해야 함
* 일반적인 네트워크 오류 상황? 접속 불가, 급격한 처리량 저하, 지연 시간 증가, 연결 끊김 등
2. 최신 세대 모바일 네트워크만을 전제로 애플리케이션을 설계해서도 안 됨
3. 대역폭이나 지연 시간을 추정하여 최적화를 시도하더라도, 그 결과는 일시적인 데이터에 불과하다는 점을 명심해야 함
=> 모바일 네트워크의 세대나 유형을 알면 엔드 투 엔드 성능에 대한 보장을 할 수는 없지만, 첫 번째 무선 홉의 지연 시간과 이동통신사의 엔드 투 엔드 성능에 대한 중요한 정보를 제공해 줌
4. 네트워크 연결이 끊어질 수 있다는 점을 대비해야 함
=> 네트워크가 없거나 일시적인 실패가 발생할 때, 애플리케이션은 가능한 한 계속 작동할 수 있어야 하며, 요청 유형과 특정 오류에 따라 적응해야 함
- 네트워크 상태를 캐시하거나 추측하지 마십시오
- 요청을 발송하고 실패를 감지하여 발생한 문제를 진단하십시오
- 일시적인 오류는 발생할 수 있으므로 이에 대비하고, 재시도 전략을 사용하십시오
- 연결 상태를 모니터링하여 최적의 요청 전략을 예상하십시오
- 요청 재시도를 위해 백오프 알고리즘을 사용하십시오; 무한 루프에 빠지지 마십시오
- 오프라인 상태라면, 로그를 기록하고 가능하면 요청을 나중에 발송하십시오
- 오프라인 모드에서는 HTML5 AppCache와 localStorage를 활용하십시오
5. 데이터를 한번에 전송하고 유휴 상태로 돌아가기
- 모바일 무선통신 물리계층은 burst 전송에 최적화되어 있음
=> 여러 요청을 그룹화하고 가능한 한 빠르게 데이터를 다운로드해 무선통신 물리계층을 유휴 상태로 되돌려 놓는 것이 가장 좋음
- 자원의 점진적 로딩은 오히려 더 큰 문제를 일으킬 수 있음
=> 필요한 콘텐츠를 미리 다운로드하고, 불필요한 간헐적 전송을 제거
* 대용량 파일을 미리 다운로드하고, 광고 같은 제3자 콘텐츠도 미리 가져와 애플리케이션 로직을 추가하여 상태를 관리
6. WiFi 네트워크로 오프로드
* WiFi 네트워크로 오프로드? 모바일 네트워크를 통해 전송되던 데이터를 WiFi 네트워크로 전환하여 전송하게 함
- WiFi 네트워크 활용 전략
=> 전 세계 무선 트래픽의 90%가 실내에서 발생하며, WiFi 연결이 가능한 경우가 많음
=> WiFi 연결은 대규모 전송에 배터리를 효율적으로 사용하며, RRC를 필요로 하지 않음
=> 데이터 집약적인 애플리케이션에서는 가능한 WiFi를 활용하고, 없으면 사용자가 WiFi를 활성화하도록 유도하여 경험을 개선하고 비용을 최소화
7. 프로토콜 및 애플리케이션 최적화
- 최적화 전략은 물리계층만이 아니라
=> 전송 및 세션 프로토콜과 더불어 HTTP/1.0, 1.1, 2와 같은 다양한 애플리케이션 프로토콜의 성능에 대한 영향을 고려해야 함
=> 일반적인 웹 애플리케이션 최적화 작업도 계속해서 진행해야 함