Android Views가 유지보수 모드에 진입 — 안드로이드 개발자에게 실제 의미는.
Source: Dev.to
이 글은 Google I/O 2026 챌린지: Explore Google I/O 2026에 제출된 작품입니다.
Google I/O 2026에서 구글은 공식적으로 선언했습니다. Jetpack Compose가 이제 Android UI 개발의 표준이 되었다는 것, 그리고 Views는 유지보수 모드에 들어갔다는 것입니다.
폐기(deprecated)된 것도, 사라진(dead) 것도 아닙니다. 유지보수 모드일 뿐이죠. 하지만 이 구분이 메시지를 부드럽게 만든다고 생각하지 마세요. 구글은 기존 시스템에 새로운 기능을 더하는 일을 끝냈습니다. 새로운 레이아웃 원시 요소, 성능 개선, 접근성 기능 등 모든 새로운 것이 Compose에만 들어갑니다.
수년간 Android UI를 만들어 온 저의 솔직한 반응을 적어봅니다.
앞으로도 계속될 일
- 중요한 버그 수정
- 보안 패치
- 기존 Views API는 안정성을 유지합니다 — RecyclerView와 ConstraintLayout 코드는 깨지지 않을 것입니다
더 이상 일어나지 않을 일
- 새로운 레이아웃 원시 요소
- 중요한 회귀가 아닌 성능 개선
- 새로운 Jetpack API와의 통합
- 새로운 Material Design 컴포넌트
I/O 2026에서 공개된 새로운 기능들은 이미 그 격차를 보여줍니다. 화면 수준 아키텍처를 위한 강력한 2D 레이아웃 원시 요소인 Grid API는 Compose 전용입니다. CameraXViewfinder Composable, Media3 AI Effects 라이브러리, Android Studio의 Gemini 통합 등도 모두 Compose‑first입니다.
Views로 개발하고 있다면 여전히 빌드할 수 있지만, 플랫폼이 더 이상 여러분을 위해 구축해 주지는 않습니다.
I/O 2026에서 발표된 Compose 업데이트
- Grid API — 스크롤 가능한 리스트의 오버헤드 없이 화면 수준 구성을 처리하는 2D 레이아웃 API. 개발자들이 오랫동안 원해 온 복잡한 ConstraintLayout 중첩을 대체합니다. Compose 전용입니다.
- Shared element debug tools — 공유 요소 전환 디버깅이 큰 고통이었는데, 2026년 4월 릴리스(core modules v1.11)에서 새로운 도구가 이를 검사하고 테스트할 수 있게 해줍니다.
- Jetpack Glance 통합 — Glance가 이제 모바일, Wear OS, 자동차 위젯을 하나의 API 표면으로 커버합니다. 플랫폼별 위젯 코드를 별도로 유지하던 개발자에게 큰 의미가 있습니다.
- Trackpad events — 태블릿과 ChromeOS 개발에 작지만 중요한 기능. Compose는 지원하지만 Views는 지원하지 않습니다.
영향을 받는 팀
- 영향이 적은 경우: 이미 Compose를 도입한 팀. 구글 자체 데이터에 따르면, 지난 2년간 출시된 새로운 Android 앱의 대부분이 Compose‑first라고 합니다. 이 그룹에 속한다면 I/O 2026은 좋은 소식이며, 플랫폼이 여러분의 기반에 크게 투자하고 있다는 뜻입니다.
- 가장 큰 타격을 받는 경우: Views에 깊게 투자한 대규모 앱(은행 앱, 엔터프라이즈 앱, 5년 이상 fragment 기반 아키텍처 등). 이 팀들은 “점진적으로 마이그레이션할까, 아니면 스택을 떠나는 플랫폼이 늘어남에 따라 기술 부채를 감수할까”라는 진짜 고민에 직면합니다.
마이그레이션 이야기는 현실입니다. Compose와 Views 간의 상호 운용성(프래그먼트 안의 ComposeView, Compose 안의 AndroidView)을 활용하면 화면 단위로 점진적으로 옮길 수 있습니다. Android Studio에 새로 추가된 Migration Assistant는 Views에서 Compose로 앱을 포팅할 수 있게 해 주며, 구글이 이 경로를 실현 가능하도록 노력하고 있다는 가장 명확한 신호입니다. 하지만 “실현 가능함”과 “쉽다”는 같은 의미는 아닙니다.
Compose 1.0 당시에는 정말 거칠었습니다. Lazy 레이아웃은 성능 절벽이 있었고, 커스텀 드로잉은 문서가 부족했으며, 기존 라이브러리와의 인터옵도 복잡했습니다.
2026년 현재, 초기의 대부분의 고통 포인트가 해결되었습니다. Lazy 성능은 견고하고, 드로잉 API는 잘 문서화되었습니다. 라이브러리 생태계