JetBrains Air와 ACP, 안드로이드 IDE에 멀티 에이전트가 붙는 시대

 

코드를 더 빨리 짜주는 IDE가 아닙니다. 오히려 개발자가 코드를 직접 안 짜도록 설계된 IDE가 젯브레인즈 에어(JetBrains Air)의 정체예요.

 

KotlinConf 2026 무대에서 ACP(Agent Client Protocol)와 에어가 같은 흐름으로 묶여 발표됐을 때, 옆자리 동료한테 "이거 안드로이드 스튜디오는 어떡하지" 라는 말이 먼저 나왔어요. 6년차 안드러로서, 윈도우 위에서 클로드 코드(Claude Code)와 주니(Junie)를 따로따로 굴리고 있는 입장에서는 이 그림이 한 번에 정리되지 않더라고요.

 

Agent Client Protocol(ACP), 에디터와 에이전트를 분리하는 표준

ACP는 한 줄로 정리하면 LSP(Language Server Protocol)의 AI 에이전트 버전이에요. 에디터와 코딩 에이전트 사이의 통신 규격을 표준화하는 위치라고 보시면 돼요. Zed가 주도하고 JetBrains를 비롯한 커뮤니티가 메인테이너로 참여하는 오픈 거버넌스로 운영되고 있어요. 시작은 2025년 8월 Zed Industries 쪽이었다고 합니다.

 

기술적으로는 JSON-RPC 2.0을 stdio 위에 올린 양방향 호출 구조예요. 클라이언트와 에이전트 양쪽 다 요청을 보낼 수 있어서, 단순한 채팅창 하나 띄우는 수준이 아니라 에이전트가 IDE의 파일 시스템과 UI에 1급 시민으로 붙는 그림이 가능해집니다.

 

여기서 진짜 중요한 건 종속성을 풀어주는 효과예요. 지금까지는 클로드 코드는 자기 환경, 커서(Cursor)는 자기 환경, 주니는 주로 인텔리J 계열 안에서만 — 이런 식으로 에이전트와 IDE가 1:1로 묶여 있었거든요. ACP가 정착하면 안드로이드 스튜디오(Android Studio) 한 곳에서 주니, 클로드 코드, 제미나이(Gemini)를 플러그인처럼 동시에 꽂아 쓸 수 있다는 얘기가 됩니다.

 

다만 마이크로소프트 쪽은 결이 좀 갈려요. GitHub 코파일럿(Copilot) CLI 는 2026년 1월 ACP 지원을 공개 프리뷰로 추가했지만, 정작 VS 코드(VS Code) 에디터 자체는 에이전트 모드를 ACP 가 아니라 MCP 로 표준화해 둔 상태라, 에디터(클라이언트) 차원의 네이티브 ACP 지원은 아직 들어오지 않았어요. 시장 점유율이 가장 큰 에디터가 클라이언트 쪽에서 빠져 있는 표준은, 범용 표준으로 굳어지기까지 시간이 필요한 편입니다.

 

 

젯브레인즈 에어, IDE가 아니라 에이전트 오케스트레이터

에어는 젯브레인즈가 새로 낸 macOS 전용 무료 앱입니다. 폐기한 Fleet IDE 코드베이스를 재활용했다는 얘기입니다. 이 한 줄에서 두 가지가 동시에 보여요. 처음부터 가벼운 구조라는 점, 그리고 한 번 접은 적이 있는 라인이라는 점이지요.

 

에어의 포지셔닝이 흥미로운데요. 안드로이드 스튜디오나 인텔리J를 대체하려고 만든 게 아니라, 에이전트들에게 일감을 던지고 결과만 감독하는 콘솔 역할을 노렸어요. 코드를 짜는 도구가 아니라 코드를 짜게 시키는 도구라는 역할 설정이에요. 클로드·코덱스(Codex)·제미나이·주니를 한 화면에서 동시에 굴릴 수 있는 구조입니다.

 

핵심 기술 한 가지만 짚자면 Git worktree와 컨테이너를 묶어 에이전트별 작업 환경을 격리한다는 점입니다. 에이전트 셋이 같은 저장소를 동시에 만지면 머지 충돌이 폭발할 텐데, worktree로 작업 디렉터리 자체를 분리하고 Docker 컨테이너로 런타임까지 가두는 방식이지요. (로컬·worktree·컨테이너 세 가지 격리 모드를 제공해요.) 안드로이드 개발 기준으로 보면 Gradle 빌드 캐시 충돌을 피할 길이 열린다는 의미가 큽니다.

 

에어 자체는 무료지만 에이전트 사용은 젯브레인즈 AI 구독 또는 본인 API 키(BYOK)가 필요한 것으로 알려져 있어요. 에이전트 세 개를 동시에 돌리면 토큰 비용도 단순 계산으로 세 배라고 보시는 게 안전합니다.

 

 

안드로이드 스튜디오에서 에어와 ACP를 쓸 때 제약

안드로이드 개발자 입장에서 이 그림은 아직 반쪽입니다. 제약을 솔직히 정리하면 이런데요.

1. macOS 전용입니다. 윈도우 환경에서 안드로이드 작업을 하는 개발자에게는 에어 자체가 그림의 떡이지요. (윈도우·리눅스 버전은 2026년 내 출시 예정으로 알려져 있어요.)
2. 안드로이드 스튜디오 정식 통합은 아직 진행 중인 단계입니다. 구글이 인텔리J 플랫폼을 기반으로 안드로이드 스튜디오를 별도 빌드해서 가져가는 구조라, 주니 CLI 같은 에이전트들이 안드로이드 스튜디오에 완전히 붙으려면 캐너리(Canary) 채널을 비롯해 구글 쪽 머지 일정을 함께 지켜봐야 하는 상황으로 보입니다.
3. 에이전트가 Gradle 빌드 시스템, AGP, KSP 같은 안드로이드 특유의 빌드 구성을 완전히 이해하지 못하는 경우가 많습니다. build.gradle.kts 와 버전 카탈로그를 입력에 함께 떠먹여줘야 그나마 쓸만한 결과가 나올 때가 많아요.

저는 윈도우 환경에서 굴리고 있어서, 에어가 풀린다 한들 한동안은 안드로이드 스튜디오 + ACP 호환 CLI 에이전트 조합이 현실적인 대안이 될 것 같습니다. 회사 장비가 맥이라면 에어를 백오피스용으로 따로 띄우고, worktree에 만들어진 코드 결과만 안드로이드 스튜디오로 끌어와 리뷰·빌드·디버깅하는 흐름이 그나마 안정적으로 보이지요.

 

주니와 클로드 코드, 멀티 에이전트 역할 분담 시나리오

여러 에이전트를 동시에 굴린다는 그림이 손에 잡히려면 역할 분담 시나리오가 있어야 합니다. 발표 자료 기반으로 제가 그려본 가설은 두 갈래예요.

 

1. 도메인 분리

주니는 코틀린·컴포즈(Compose) UI 작업, 클로드 코드는 리팩토링과 테스트 작성. 같은 PR 안에서 두 에이전트가 만진 영역이 겹치지 않게 자르고, 개발자가 최종 병합만 책임지는 구조입니다. 두 에이전트의 강점이 다르다는 가정 위에서 가르는 거예요. 주니는 인텔리J 인덱스를 직접 읽으니까 코틀린·컴포즈 쪽에서 더 안정적이고, 클로드 코드는 파일 트리를 grep으로 훑는 방식이라 리팩토링 범위가 넓은 작업에 강점이 있다고 보고 있어요.

 

2. 단계 분리

에이전트 A가 초안을 짜고, 에이전트 B가 그 결과를 리뷰·개선합니다. 모델 다양성으로 코드 품질의 분산을 줄여보자는 발상인데, 토큰 비용은 그만큼 늘어나니까 핵심 모듈에만 한정해서 적용하는 게 맞아 보입니다.

 

개인적으로는 처음부터 둘 다 무리하게 굴리기보다, 핵심 비즈니스 로직은 직접 손으로 짜고 테스트 코드·문서화·반복적인 리팩토링만 에어의 에이전트에게 위임하는 게 현실적인 출발점이라고 봅니다. 멀티 에이전트의 진짜 병목은 토큰 비용보다 "사람이 코드 리뷰를 처리하는 속도" 라는 점, 이게 의외로 잘 안 보이는 지점이거든요.

 

 

다음 글에서 다뤄볼 것

에어의 worktree 격리 구조를 윈도우 환경에서 흉내 낼 수 있는지, 그리고 안드로이드 스튜디오에 ACP 클라이언트를 직접 붙이는 절차가 어디까지 가능한지는 다음 글에서 정리해보려고 합니다. WSL2 위에 worktree를 두고 안드로이드 스튜디오는 호스트에서 인덱싱만 돌리는 분리 구성이 실제로 빌드까지 매끄럽게 이어지는지, 이 부분이 가장 궁금한 지점이에요.