Android 개발/Gradle・빌드

Android Studio Rabbit 1 정식판, 업데이트 전 호환성 체크 5분

stackD 2026. 10. 6. 18:00
반응형

 

10월 1일 아침, Rabbit 1 정식판 배너를 보고 바로 누르려다 멈췄습니다. 커뮤니티 첫 글이 신기능 찬사가 아니라 플러그인 크래시 리포트였거든요.

 

Rabbit 1(2026.2.1) 정식 출시. AGP 7.1~9.4 상한, 플러그인 until-build 261 벽, 팀원·CI 전파 순서까지 실무 프로젝트에 적용하기 전에 점검한 항목을 정리했습니다.

 

 

Android Studio Rabbit 1 정식판, 배너를 바로 누르지 않은 이유

정식명은 안드로이드 스튜디오(Android Studio) Rabbit 1, 버전은 2026.2.1입니다. Stable 채널 출시는 2026년 10월 1일이고 RC1·RC2는 9월에 돌았어요. 빌드 번호는 2026.2.1.8 같은 형태로 붙더라고요.

 

코드네임은 Otter(2025.2.1) → Panda(2025.3.x) → Quail(2026.1.x) → Rabbit 순서예요. "Q가 언제 있었지?" 싶으면 본인이 몇 세대 뒤처져 있는지 알려주는 신호로 보는 쪽이 맞습니다.

 

진짜 변수는 플랫폼 베이스입니다. 인텔리J 아이디어(IntelliJ IDEA) 2026.2, 즉 빌드 262 기반이에요. 젯브레인즈 공식 집계로 버그 수정이 1,300건 이상, 그중 프리즈·성능 관련이 140건입니다. 반갑긴 한데 261에서 262로 넘어간 이 한 칸이 아래 모든 문제의 출발점입니다.

 

"다음 버전 기다릴까" 전략도 안 통합니다. Rabbit 2(2026.2.2)는 10월 현재 Canary 3(AGP 9.5.0-alpha08 동반)까지 공개된 상태인데, Canary는 구글도 "leading-edge, lightly tested"라고 못 박아두고 Stable과 나란히 깔라고 권하는 채널이에요. 기다림의 대상이 아닙니다. 다만 플러그인을 거의 안 쓰고 AGP가 9.x면, 제 경험상 체감 리스크는 매우 낮습니다. 그래서 이 체크리스트는 미루는 근거가 아니라, 5분 안에 결론을 내는 도구로 쓰시는 게 맞아요.

 

업데이트 전 호환성 체크 3가지: AGP·Gradle·JDK

1. AGP 상한선부터 확인

 

지원 범위가 AGP 7.1~9.4입니다. 보통 최소 버전만 보는데, 여기선 상한이 함정이에요. Canary에서 AGP 9.5 alpha 계열을 쓰고 있었다면 stable로 내려올 때 다운그레이드 대상이 됩니다.

 

2. Gradle·JDK 체인 맞추기

 

AGP 9.4.0(2026년 9월) 릴리스 노트 기준으로 Gradle 최소 9.6.0, JDK 최소 17이 요구됩니다. 확인 자체는 두 줄이면 끝납니다. gradle-wrapper.properties의 distributionUrl, 그리고 libs.versions.toml의 agp 항목입니다.

 

3. 번들 JBR과 AGP 요구 JDK 구분

 

Micronaut처럼 개별 프로젝트가 Java 25를 최소 기준으로 올리는 논의를 띄우는 사례가 보이는데요(micronaut-core discussions #12288), IDE에 번들된 런타임과 AGP가 요구하는 JDK는 별개 축입니다. 이걸 섞으면 2024년 Ladybug(2024.2.1) 때와 같은 꼴이 납니다. JDK 21 번들에 Gradle 8.5 미만 비호환이 겹쳐서 "IDE만 올렸는데 빌드가 깨졌다"는 글이 한참 돌았습니다.

 

개인적으로는 IDE 버전 올리는 것 자체는 비교적 안전하다고 봐요. Rabbit 1의 변화는 AI·거버넌스 쪽에 쏠려 있고, APK/AAB 산출물을 결정하는 건 결국 AGP·코틀린·Gradle이니까요. 진짜 긴장할 타이밍은 IDE가 아니라 AGP를 올릴 때입니다.

 

 

플러그인 설치 거부 에러 requires IDE build 261 or earlier

261에서 262로 점프하면서 until-build 상한을 261로 박아둔 플러그인들이 Incompatible: requires IDE build 261.* or earlier로 설치를 거부합니다. 이유를 알면 계산은 정말 5분이면 돼요.

 

보고된 사례가 패턴이 똑같습니다.

 

  1. CodeLocator — 시작 시 NoSuchMethodError: EditorEventMulticaster.addSelectionListener (이슈 #101)
  2. SQLDelight IDE 플러그인 v2.3.2 — 시작·VFS·저장 이벤트에서 NoClassDefFoundError (이슈 #6384)
  3. compose-nav-graph — Canary 5부터 재현, until-build 상한 제거 PR로 해결

 

그래서 업데이트 전에 할 일은 What's new 읽기가 아니라, Settings > Plugins 목록을 캡처하고 각 항목의 최신 업데이트 날짜가 2026년 910월 이후인지 보는 겁니다. 상한만 막힌 건 보통 수일수주 안에 패치되니까, 핵심 작업에 쓰는 플러그인이 아직 미대응이면 일주일 미루는 쪽이 합리적이라고 판단하시면 됩니다.

 

하나 더. 메이저 첫 실행 때 이전 설정 임포트를 권하는데, 그러면 깨진 플러그인 설정까지 그대로 따라옵니다. 저 같은 경우엔 메이저 올릴 때는 클린 시작을 고르고 필요한 플러그인만 다시 깔아요. 원인 분리가 훨씬 쉬워져요. 참고로 이 크래시들은 서드파티 쪽 문제이니, "Rabbit 1이 불안정하다"로 일반화하는 건 정확하지 않습니다.

 

 

팀원과 CI까지 번지지 않게 업데이트 순서 정하기

IDE가 권하는 대로 libs.versions.toml과 gradle-wrapper.properties를 고쳐서 커밋하면, 구버전 스튜디오를 쓰는 팀원 환경과 사내 CI가 동시에 멈춥니다. IDE는 권유만 하고, 팀원과 CI는 자동으로 따라오지 않아요.

 

  1. 한 명이 먼저 올려서 1~2일 실사용해봅니다.
  2. 이상 없으면 Plugins 캡처와 함께 팀 채널에 공유합니다.
  3. AGP·Gradle 버전 변경은 IDE 업데이트와 별도 PR로 분리합니다.
  4. CI 이미지의 JDK·Gradle은 머지 전에 먼저 맞춰둡니다.

 

조직 쪽 각도도 하나 생겼습니다. Rabbit 1부터 Gemini Enterprise 번들(Standard·Plus 플랜)에 안드로이드 스튜디오가 포함됐어요. 데이터 레지던시·중앙 관리·통합 과금은 원래 Gemini Enterprise 쪽 기능이고, 이제 그 울타리 안에 IDE가 들어온 겁니다. "AI 어시스턴트 전면 금지" 정책을 재협상할 명분은 되는데, 비용과 조달 절차가 따라붙는다는 점은 솔직히 감안하셔야 합니다.

 

신기능 체감은 어떨까요. 제미나이(Gemini) 대화 스레드 복수 관리로 작업을 병행하면서 히스토리를 검색할 수 있게 됐고, AI Actions의 Fix all UI check issues가 접근성 문제를 감사·수정해줍니다. Running Devices 창에 Layout Inspector 임베드가 기본 활성화되면서 렌더링 속도가 약 50% 개선됐고, Generate Signed App Bundle 종료 단계에서 Play Console 테스트 트랙으로 바로 올리는 Publish for Testing도 들어왔네요. 다만 제미나이를 끄고 쓰는 조직엔 체감 가치가 거의 없고, 그냥 "플랫폼 버전 올림" 수준으로 남습니다.

 

 

롤백보다 싼 보험, JetBrains Toolbox 병행 설치

가장 저렴한 안전장치는 백업이 아니라 젯브레인즈 툴박스(JetBrains Toolbox)로 Stable과 이전 버전을 같이 깔아두는 것입니다. 롤백 절차 자체가 사라져요. 이상하면 구버전 아이콘을 다시 누르면 되니까요. 한국어 자료에서 의외로 잘 안 보이는 선택지입니다.

 

수동 다운그레이드도 되지만 SDK 디렉터리 보존이 전제입니다. 병행 설치도 완전 격리는 아니라서 Gradle 캐시와 .idea를 공유할 수 있어요. 증상이 애매하면 .idea 삭제 후 Invalidate Caches를 먼저 돌려보시는 게 순서입니다.

 

되돌리기 어려운 건 IDE가 아니라 프로젝트 파일 커밋이에요. IDE는 10분이면 내려오지만, AGP·Gradle·libs.versions.toml 변경이 머지되고 팀원들이 pull까지 받은 뒤엔 비용이 확 뜁니다. 그래서 앞에서 말한 "버전 변경은 별도 PR" 원칙이 사실상 가장 강력한 롤백 전략이에요. 출시 1주차라 장기 안정성 데이터는 아직 없습니다. 한두 달 굴려본 뒤 후기는 따로 남길 생각이에요.

 


점검 항목은 다섯 줄로 줄어듭니다. AGP가 7.1~9.4 안에 있는지, Gradle·JDK가 AGP 요구치를 넘는지, Plugins 중 9월 이후 업데이트가 없는 항목이 핵심 작업에 끼어 있는지, 툴박스 병행 설치를 준비했는지, 그리고 버전 변경 커밋을 IDE 업데이트와 분리했는지.

 

Rabbit 1 자체는 대부분의 프로젝트에서 안전하게 올라갑니다. 위험한 건 업데이트 직후 반사적으로 손이 가는 그 버전 파일 한 줄이에요. 금요일 저녁에 배너 누르고 libs.versions.toml까지 건드려서 커밋하면, 월요일 아침 사내 CI 실패 알림 앞에서 커피를 식히고 있게 됩니다. 반대로 IDE만 올리고 버전 파일은 그대로 둔 채 퇴근하면, 월요일엔 플러그인 두 개 다시 깔면서 평소처럼 작업을 시작하는 장면이 기다리고 있을 거예요.

 

 

반응형
LIST