Junie 안드로이드 모드와 Junie CLI, 클로드 코드·커서 사이에 끼운 자리

 

지난 봄, 릴리즈 빌드만 KSP 충돌로 죽길래 주니(Junie) 안드로이드 모드에 던졌더니 libs.versions.toml 까지 까서 PR 초안을 뽑아주더라고요. 클로드 코드(Claude Code)도 커서(Cursor)도 못 한 일이었습니다. (미리 짚어두면, '안드로이드 모드'는 공식 토글이나 제품명이 아니라, 주니가 코틀린·안드로이드 프로젝트 컨텍스트를 잘 잡는 동작을 제가 편의상 부르는 표현이에요.)

 

이게 그냥 자동완성 채팅이랑 다르다는 걸 그날 처음 체감했어요. 주니는 안드로이드 스튜디오(Android Studio) 의 시맨틱 인덱스를 직접 읽어가면서 멀티모듈 그래프를 따라 다닙니다. 클로드 코드는 파일 시스템 수준에서 grep 으로 훑고, 커서는 자체 임베딩으로 따로 색인을 만들지요. 같은 BYOK 모델을 물려도 결과가 다르게 나오는 이유가 여기 있습니다.

 

Junie 안드로이드 모드와 Junie CLI, 3월 베타 이후 KotlinConf '26 까지 정리된 지점

JetBrains 의 AI 에이전트 주니는 단순 채팅(AI Assistant) 과 달리 Task → Plan → Execute 흐름으로 움직입니다. 파일을 직접 고치고 터미널까지 굴립니다. 앞서 말한 '안드로이드 모드'는 거듭 짚지만 공식 제품명이 아니라, 코틀린·안드로이드 프로젝트 컨텍스트를 더 잘 잡도록 동작하는 모습을 가리키는 제 표현이에요.

 

주니 CLI(Junie CLI) 는 2026-03-11 베타로 풀렸고, KotlinConf '26(5/20~22, 뮌헨) 자리에서 진행 상황이 다시 정리됐는데요. 이게 LLM-agnostic 구조라 BYOK(Bring Your Own Key) 로 앤트로픽(Anthropic)·OpenAI·구글 키를 그대로 꽂아 쓸 수 있다고 합니다. 회사가 이미 클로드 키를 굴리고 있다면 추가 구독 없이 에이전트가 붙는 셈이에요.

 

다만 CLI 가 IDE 인덱스를 빌려 쓰는 기능은 안드로이드 스튜디오에 대해서는 "coming soon" 으로 남아 있는 것으로 보입니다. 다른 인텔리J(IntelliJ) 계열 IDE 보다 한 발 늦는 대목입니다.

 

 

KSP 충돌 libs.versions.toml, 주니가 PR 초안까지 뽑은 흐름

후킹에 적은 그 사건을 좀 풀어보면, 디버그는 멀쩡한데 릴리즈만 KSP-Hilt 버전 매칭이 안 맞아 빌드가 깨지는 상황이었어요. 클로드 코드한테 먼저 던졌더니 build.gradle.kts 만 보고 "KSP 버전을 올리세요" 정도의 답이 돌아왔습니다. 정답은 맞는데 어디를 올려야 하는지가 빠져 있었지요.

 

주니는 달랐어요. Version Catalog 인 libs.versions.toml 까지 펼쳐서 KSP·Hilt·Kotlin 세 라인의 정합성을 같이 잡고, 모듈별 plugin 블록까지 한 번에 다듬은 패치 후보를 PR 초안으로 내놨거든요. 안드로이드 스튜디오의 그래들(Gradle) 동기화 결과를 직접 읽기 때문에 가능한 흐름입니다.

 

Compose 의 @Preview 가 Hilt ViewModel 때문에 안 뜨던 지점에서도 주니가 PreviewParameterProvider 패턴을 먼저 제안하더라고요. 이 쪽 권장 방식을 정확히 짚어줘서, 같은 자리에서 커서가 가짜 fake ViewModel 을 어색하게 만들어내던 것과 차이가 났습니다.

 

물론 만능은 아닙니다. 멀티모듈 의존성 그래프를 잘못 읽고 :feature:home 이 :core:network 를 직접 참조하는 양 코드를 짜놓는 경우가 있었어요. 빌드가 통째로 깨졌고, 그건 사람이 봐야 하는 대목이었습니다. HITL(Human-in-the-loop) 이 빠지면 안 되는 구간이지요.

 

 

클로드 코드·커서·주니, 6년차 안드러의 분업 자리

세 도구를 한 달쯤 같이 굴리면서 정리한 분업은 이렇습니다.

1. 주니: 안드로이드 스튜디오 안에서 그래들·KSP·리팩토링처럼 IDE 시맨틱이 필요한 주력 작업.
2. 커서: 신규 화면 PoC, UI 스케치처럼 본 프로젝트와 격리해서 굴려보는 실험. 별도 창에서 따로.
3. 클로드 코드: 라이브러리 리서치, CHANGELOG 요약, CI 스크립트 손보기 같은 터미널 중심 작업.

JetBrains Research 2026-04 리포트에 따르면 Cursor 인지도 69% 로 여전히 2위, Claude Code 18%·Junie 5% 가 직장 내 사용률로 잡혔습니다. 한 사람이 여러 도구를 동시에 쓰는 패턴은 통계로도 잡힌다는 얘기입니다.

 

개인적으로는 세 개를 동시에 띄우는 게 답은 아니라고 봅니다. 메모리 사용량이 16GB 머신에선 금방 한계에 닿고, 도구 전환 비용도 무시 못 합니다. 그래서 주력 한 개, 보조 한 개 정도로 두 개만 동시에 띄우는 게 제 실무 기준이에요.

 

 

안드로이드 스튜디오 지원 시차와 BYOK, 주의할 지점

주니는 안드로이드 스튜디오 신규 버전(Canary/RC) 지원이 늦어지는 일이 반복되는 것 같습니다. AS Otter RC 가 한동안 미지원으로 남아 있었던 이슈도 있었지요. 참고로 저는 안정 버전과 카나리 버전 안드로이드 스튜디오를 분리해 깔아두고, 주니는 안정 버전에서만 굴리고 있어요.

 

BYOK 도 무조건 좋은 건 아닙니다. 회사 보안 정책상 API 키 직접 사용을 막아둔 곳이 있을 수 있고, 회사 클로드 키를 개인 IDE 에 꽂아 쓰는 게 데이터 거버넌스에 걸리기도 합니다. 도입 전에 사내 보안팀과 한 번은 정리하고 들어가시는 게 안전해요.

 

깃허브 액션(GitHub Actions) 에서 junie run --headless 로 PR diff 리뷰를 돌릴 수도 있는데요. CI 환경에서는 로컬 IDE 인덱스를 못 쓰니까 컨텍스트가 얕아집니다. ktlint 같은 정적 분석과 중복 지적은 줄어들지만, 멀티모듈 의존성에 닿는 리뷰는 사람이 보는 게 맞아 보입니다. 보조 리뷰어 역할로만 두는 게 안전한 포인트입니다.

 

세 도구가 같은 클로드 키를 물고 있어도, IDE 인덱스를 직접 읽느냐 파일 트리를 grep 하느냐 자체 임베딩을 만드느냐에 따라 PR 초안의 깊이가 갈립니다. 안드로이드 스튜디오 안에서 시맨틱 인덱스를 쓰는 자리는, 지금 시점에서는 주니가 유일한 셈입니다.