Android HTTP 클라이언트 선택 기준
2026년 기준 Android REST/JSON 통신에서는 OkHttp가 여전히 기본값이고, HTTP/3·QUIC·대용량 전송 최적화가 필요할 때 Cronet이나 HttpEngine을 검토하는 선택 기준.
Android HTTP 클라이언트 선택 기준
한 줄 요약
일반 Android REST/JSON 통신이면 2026년에도 OkHttp가 가장 무난한 기본값이다. HTTP/3, QUIC, 대용량 전송, 나쁜 네트워크 품질 최적화가 중요할 때만 Cronet이나 HttpEngine을 우선 검토하면 된다.
먼저 읽을 결론
OkHttp를 대체할 가볍고 빠른 HTTP 클라이언트를 찾을 때는 "가벼움"과 "성능"을 나눠 봐야 한다. APK 크기를 줄이는 것이 목표라면 Android 14/API 34 이상에서 HttpEngine이 가장 깔끔하다. 지연시간, HTTP/3, QUIC, connection migration 같은 전송 성능이 목표라면 Cronet이 더 직접적인 후보가 된다. 그래도 대부분의 REST/JSON 앱에서는 OkHttp가 안정성, 디버깅, 라이브러리 호환성 면에서 아직 기본값이다.
| 상황 | 추천 |
|---|---|
| 일반 REST/JSON API | OkHttp |
| Retrofit 기반 앱 | OkHttp + Retrofit 유지 |
| HTTP/3/QUIC, 대용량, 스트리밍, 불안정한 네트워크 | Cronet |
| Android 14/API 34+ 중심, APK 증가 없이 최신 내장 스택 사용 | HttpEngine |
| Kotlin Multiplatform, coroutine-first 구조 | Ktor Client |
| 단순 UI용 JSON/image 요청 queue/cache/cancel | Volley |
| 외부 의존성 0, 매우 단순한 요청 몇 개 | HttpURLConnection |
한 줄로 정리하면 이렇다. OkHttp는 기본값, 성능과 HTTP/3는 Cronet·HttpEngine, 구조와 KMP는 Ktor, 단순 UI 요청은 Volley다.
왜 저장했나
Android 네트워크 스택 선택은 "OkHttp가 낡았나?"처럼 단순한 문제가 아니다. OkHttp, Retrofit, Ktor, Cronet, HttpEngine은 같은 층의 도구가 아니고, 각각 해결하는 문제가 다르다. 특히 Retrofit은 OkHttp의 대체재가 아니라 API 선언 레이어이고, Ktor는 전송 엔진을 감싸는 HTTP 클라이언트 추상화에 가깝다.
이 노트는 새 Android 프로젝트에서 HTTP 클라이언트를 고르거나, 기존 OkHttp 기반 앱에서 HTTP/3·QUIC 도입을 검토할 때 빠르게 기준을 잡기 위해 저장했다.
정리한 질문
2026년 기준 Android에서 REST/JSON 통신을 구현할 때 OkHttp를 계속 기본값으로 써도 되는가? 더 가볍거나 성능이 좋은 대체재가 있다면 어떤 상황에서 Cronet, HttpEngine, Ktor, Volley, HttpURLConnection을 골라야 하는가?
핵심 답변
일반 앱에서는 OkHttp를 유지하는 편이 가장 안전하다. OkHttp는 Android 생태계 호환성이 좋고, HTTP/2, connection pooling, GZIP, cache 같은 기본 성능 기능이 잘 갖춰져 있다. Android 5.0/API 21 이상을 지원하고, Okio와 Kotlin standard library에 의존한다는 점도 부담이 크지 않다.
다만 HTTP/3/QUIC이 핵심 요구라면 이야기가 달라진다. OkHttp 자체는 HTTP/3를 네이티브로 지원하지 않는다. 이 요구가 명확하면 Cronet이나 HttpEngine 쪽을 봐야 한다.
Cronet은 Chromium 네트워크 스택을 Android 앱에서 쓰게 해주는 선택지다. Android 문서 기준 HTTP, HTTP/2, HTTP/3 over QUIC을 지원하고, 비동기 요청, 캐시, Brotli 압축도 제공한다. Google Play Services provider를 쓰면 앱 크기 영향이 작지만 GMS가 필요하다. Embedded Cronet은 버전 통제가 쉬운 대신 앱 크기가 커진다.
HttpEngine은 Android 14/API 34 또는 S Extensions 7 이상에서 권장되는 내장 네트워크 스택이다. APK 증가가 없고 HTTP/3 over QUIC까지 기대할 수 있지만, 적용 가능한 기기 범위와 저수준 API라는 점을 확인해야 한다.
후보별 비교
| 후보 | 언제 추천? | 장점 | 단점 |
|---|---|---|---|
| OkHttp | 대부분의 Android REST/JSON 앱 | 안정적이고 생태계 호환성이 좋다. HTTP/2, connection pooling, GZIP, cache가 기본적으로 잘 갖춰져 있다. | HTTP/3/QUIC은 자체 강점이 아니다. |
| HttpEngine | Android 14/API 34+ 위주 앱, 최신 내장 스택을 쓰고 싶을 때 | Android 내장이라 APK 증가가 없다. HTTP/3 over QUIC을 기대할 수 있다. | API 34 또는 S Extensions 7 이상이 필요하고 API가 저수준이다. |
| Cronet | 지연시간, HTTP/3/QUIC, 대용량 전송, 스트리밍이 중요할 때 | Chromium 네트워크 스택, HTTP/2·HTTP/3·QUIC, Brotli, 비동기 요청을 지원한다. | 직접 쓰기 번거롭다. Embedded는 앱 크기를 키운다. |
| Ktor Client | KMP, Kotlin-only, coroutine-first 구조가 중요할 때 | Kotlin스럽고 멀티플랫폼에 맞다. 엔진 교체가 가능하다. | 엔진에 따라 성능과 프로토콜 지원이 크게 달라진다. Android에서 OkHttp 엔진을 쓰면 결국 전송은 OkHttp다. |
| Volley | 단순 UI용 RPC, JSON/image 요청, request queue가 필요할 때 | queue, cache, cancel, priority가 편하다. | 신규 Kotlin 앱의 주류 기본값은 아니다. |
| HttpURLConnection | 외부 의존성 없이 아주 단순한 요청만 필요할 때 | 의존성 0에 가깝다. | API가 불편하고 기능, 디버깅, 프로토콜 측면에서 한계가 많다. |
선택 가이드
- 일반적인 CRUD, 로그인, 목록 조회, JSON API라면 OkHttp를 기본값으로 둔다.
- API 선언과 타입 안정성이 필요하면 Retrofit을 얹는다. Retrofit은 OkHttp 대체재가 아니다.
- KMP나 coroutine-first 구조가 더 중요하면 Ktor Client를 검토한다. 이때 Android 엔진을 무엇으로 쓸지 따로 결정해야 한다.
- HTTP/3, QUIC, 네트워크 전환, 스트리밍, 대용량 전송이 제품 요구라면 Cronet 또는 HttpEngine을 검토한다.
- Android 14/API 34+ 중심 앱이면 HttpEngine을 먼저 살펴볼 만하다.
- 넓은 기기 지원과 Retrofit/OkHttp 생태계가 중요하면 OkHttp를 유지하고, 필요한 경우 Cronet Transport for OkHttp/Retrofit을 실험한다. 단, 이 방식은 OkHttp 설정 일부가 우회될 수 있다.
주의할 점
Ktor Client를 "OkHttp보다 가벼운 대체재"로만 보면 판단이 흐려진다. Ktor는 HTTP 클라이언트 추상화이고, 실제 성능과 프로토콜은 선택한 엔진에 달려 있다. Ktor의 CIO 엔진은 Android에서도 쓸 수 있지만 HTTP/1.x만 지원한다. Ktor의 OkHttp 엔진을 쓰면 전송 계층은 OkHttp다.
Retrofit도 비교군에서 빼야 한다. Retrofit은 HTTP API를 Java/Kotlin 인터페이스로 바꿔주는 레이어다. 보통 OkHttp 위에서 동작하므로 "OkHttp 말고 Retrofit"이 아니라 "OkHttp + Retrofit" 조합으로 보는 게 맞다.
Cronet은 성능 면에서 매력적이지만 운영 선택지가 갈린다. Google Play Services 기반은 앱 크기 영향이 작고 자동 업데이트 장점이 있지만 GMS가 필요하다. Embedded Cronet은 버전 통제가 가능하지만 앱 크기가 커진다. 대상 국가, GMS 의존 가능성, 업데이트 정책을 같이 봐야 한다.
검증이 필요한 주장
- 실제 앱의 latency, CPU, memory, battery 영향은 API 서버, TLS 설정, CDN, payload 크기, 캐시 정책, 네트워크 품질에 따라 달라진다. 제품 코드에서는 자체 benchmark가 필요하다.
- HttpEngine 사용 가능 범위는 대상 기기의 Android 버전과 S Extensions 수준을 확인해야 한다.
- Cronet provider 선택에 따른 APK 크기와 실제 성능 차이는 현재 dependency와 배포 채널 기준으로 다시 측정해야 한다.
- Ktor 엔진별 HTTP/2, HTTP/3, WebSocket 지원 상태는 사용하는 Ktor 버전에서 다시 확인해야 한다.
Source Fidelity Notes
- 원문의 핵심 결론을 유지했다: 일반 REST/JSON은 OkHttp 기본값, HTTP/3/QUIC 성능 최적화는 Cronet/HttpEngine, KMP 구조는 Ktor, 단순 UI 요청은 Volley.
- 후보별 장단점과 선택 기준 표를 보존하되, 공개 노트에서는 중복 설명을 줄였다.
- 원문 링크는 보존했고, 추적성 query parameter는 제거했다.
- 별도 성능 benchmark나 수치를 새로 invent하지 않았다. 앱 크기, 프로토콜 지원, API 조건처럼 원문에 있던 범위만 유지했다.