얼마 전에 갤럭시 탭에 제 앱을 띄워봤는데요, 키보드 엔터를 아무리 눌러도 로그인이 안 되더라고요. Project Aluminium(프로젝트 알루미늄)이 오면 이런 앱은 진짜 곤란해집니다. 대화면 환경이 '선택'이 아닌 '기본'이 되는 시대가 머지않았거든요.
Project Aluminium이 안드로이드 앱 개발에 미치는 변화
이게 원래 루머로만 돌았는데, 2025년 9월 퀄컴 스냅드래곤 서밋에서 릭 오스털로(Rick Osterloh)가 Android-PC 통합 계획을 공식 발표하면서 기정사실화됐죠. '알루미늄(Aluminium)'이라는 이름 자체는 구글 채용 공고를 통해 확인된 코드명이에요.
안드로이드와 크롬OS(ChromeOS)를 단일 OS로 통합해서, 스마트폰·태블릿·노트북까지 하나의 코드로 대응하는 구조를 만드는 게 목표입니다. 기존에는 크롬OS가 별도의 가상화 런타임(ARC++/ARCVM) 위에서 안드로이드 앱을 띄웠는데요. 이번엔 그 구조를 완전히 걷어내고 안드로이드 네이티브 스택을 그대로 쓴다고 해요.
일각에서는 2026년 출시설도 돌았지만, 최근 법원 문서를 통해 드러난 내부 일정에 따르면 2026년 후반에는 상업용 테스터(commercial trusted testers) 단계에 진입하고 정식 출시는 2028년이 될 전망이라고 해요. 당장 코앞에 닥친 Android 17 일정(6월 정식, 9월 QPR1)과는 별개로 굴러가는 거대한 장기 프로젝트인 셈이죠. 하지만 2028년 완성을 향해 OS의 대화면 정책은 지금 이 순간에도 꾸준히 변하고 있습니다. 가장 빨리 터지는 지점부터 우선순위를 정해 막는 접근이 현실적이에요.
안드로이드 앱이 대화면에서 깨지는 3가지 지점
저도 갤럭시 탭 테스트 이전까지는 "그냥 잘 돌아가겠지" 생각했는데요, 막상 해보니 생각보다 많은 게 삐걱거리더라고요.
1. 키보드 입력 처리 누락 로그인 화면에서 엔터를 눌러도 제출이 안 되고, Tab을 눌러도 다음 입력란으로 포커스가 이동하지 않는 경우가 많습니다. 스마트폰의 소프트키보드(IME) 액션으로만 처리하던 로직이 물리 키보드에서는 아예 다른 KeyEvent로 들어오기 때문이죠.
2. 고정 창 크기 레이아웃의 한계 440dp 같은 고정 너비로 짠 레이아웃은 창 크기를 조절하는 데스크톱 환경에서 UI가 잘리거나 겹치기 일쑤입니다. 구글의 공식 Window Size Classes 기준인 compact, medium, expanded 세 단계에 맞춰 유연하게 늘어나야 해요.
3. 마우스 및 포인터 피드백 부재 마우스를 올렸을 때(Hover) 버튼 색이 변하지 않으면 "이거 클릭 되는 건가?" 싶은 혼란이 생깁니다. 특히 데스크톱 사용자는 우클릭 컨텍스트 메뉴에도 익숙해서, 이런 디테일이 없으면 앱이 굉장히 어색하게 느껴지더라고요.
안드로이드 대화면 앱 대응, 개발자가 손봐야 할 4가지
1. Resizable Window 활성화 AndroidManifest.xml에 android:resizableActivity="true"를 명시하는 건 이제 필수입니다. 이 설정이 빠져있으면 앱이 호환성 모드로 실행되어 창 크기 조절이 막히고, 데스크톱 환경에서 구석에 고정된 크기로만 뜨게 됩니다.
2. 반응형 레이아웃 (Adaptive UI) 적용 화면 너비에 따라 내비게이션 구조가 자동으로 변해야 합니다. Material 3 Adaptive 라이브러리의 NavigationSuiteScaffold를 쓰면 화면 너비에 따라 하단 탭, 사이드 레일, 드로어를 알아서 전환해 줘서 구현 공수가 확 줄어들어요.
3. 키보드·마우스 및 신규 권한 보강 키보드는 imeOptions에 actionDone을 설정하고 OnEditorActionListener를 잡는 방식과, 필요 시 KeyEvent.KEYCODE_ENTER도 함께 처리해서 엔터 키 제출을 구현하는 것, 그리고 Tab 키 포커스 이동이에요. 추가로 Android 16부터 도입된 ACCESS_LOCAL_NETWORK 같은 런타임 권한도 앱 성격에 따라 챙겨두시는 게 좋습니다.
4. 생명주기 및 상태 복원 (Multi-window) 창 크기를 수시로 바꾸는 환경에서는 화면 회전과 똑같은 수준의 상태 복원 로직이 필요합니다. onSaveInstanceState와 ViewModel 저장 로직이 멀티 윈도우 환경에서도 튼튼하게 버티는지 확인해야 해요.
Project Aluminium 대비 안드로이드 앱 점검 순서
우선순위대로 정리해 봤습니다.
1. Resizable Window 선언
android:resizableActivity="true" 선언 후 에뮬레이터에서 창 크기 조절 테스트
가장 기본이 되는 설정입니다.
2. 반응형 레이아웃 점검
Window Size Classes(compact / medium / expanded) 기준으로 주요 화면 레이아웃 깨짐 확인
로그인, 메인 화면부터 우선순위를 두세요.
3. 물리 키보드 대응
로그인 화면 등에서 물리 키보드의 Enter(제출) 및 Tab(포커스 이동) 동작 구현
사용자 체감이 가장 큰 부분입니다.
4. 마우스 포인터 피드백
주요 인터랙션 요소에 ?attr/selectableItemBackground를 적용해 호버 피드백 추가
데스크톱 환경의 어색함을 줄여줍니다.
5. 상태 복원 확인
멀티 윈도우 환경에서 ViewModel 및 상태 복원(onSaveInstanceState) 동작 확인
앱 두 개를 띄웠을 때 작업 내용이 날아가지 않게 보호합니다.
마치며
사실 2028년 정식 출시라는 먼 일정 때문에, Project Aluminium이 구글의 다른 프로젝트들처럼 조용히 사라질지도 모른다는 의심을 지울 수는 없어요. 하지만 대화면 가이드는 Android 14부터 꾸준히 강화되어 왔고, 플레이 스토어의 태블릿 최적화 기준도 계속 높아지고 있거든요.
설령 프로젝트가 흐지부지되더라도 어차피 손봐야 할 부분들입니다. 당장 코드 몇 줄로 시작할 수 있는 resizableActivity 선언과 키보드 엔터 키 제출부터 하나씩 손봐두면, 데스크톱 환경에서도 든든하게 버티는 앱을 만드실 수 있을 거예요!
'Android 개발' 카테고리의 다른 글
| 제미나이가 경쟁사 앱을 호출하는 날, 내 사이드 앱은 준비됐을까 (0) | 2026.05.17 |
|---|