JetBrains Air, IDE에서 EAP 공개… 진짜 승부는 오케스트레이션

JetBrains가 병렬 작업을 위해 설계된 작업 공간에 지원되는 5개의 코딩 에이전트를 통합한 JetBrains Air in IDEs의 얼리 액세스를 시작했다. 이번 조치는 또 하나의 챗봇을 추가하는 것보다, 개발자가 AI가 생성한 코드를 어디에서 감독할지를 결정하는 데 더 가깝다.

Air는 Codex, Gemini, GitHub Copilot, Claude Agent, 그리고 JetBrains 자체 Junie를 기본 지원한다. 또한 코딩 에이전트와 개발 환경 사이의 공통 인터페이스인 Agent Client Protocol, 즉 ACP를 통해 호환 가능한 다른 도구도 연결할 수 있다.

이는 JetBrains를 소프트웨어 개발의 모델 중심 관점과 맞서게 한다. 이 관점에서는 개발자가 현재 가장 좋은 결과를 내는 에이전트를 따라간다. JetBrains는 맥락을 제공하고, 동시 작업을 추적하며, 사람이 모든 변경 사항을 검토하도록 돕는 환경이 지속 가능한 제품이 될 것이라 본다.

초기 발표에서는 5개 IDE에 도달한 EAP가 강조됐다. 그러나 JetBrains의 현재 문서는 Android Studio를 제외한 자사 IDE 라인업에서 플러그인을 지원한다고 밝히며, 최종 범위가 초기 설명보다 넓음을 보여준다. 더 중요한 숫자는 여전히 5개의 에이전트다. Air는 이들을 하나의 제어 화면 안에서 교체 가능한 작업자로 다룬다.

JetBrains는 개발자에게 Codex, Claude, Gemini, Copilot 또는 Cursor를 포기하라고 요구하지 않는다. 이 시스템들이 JetBrains 제품 안에서 작동하기를 원한다. 이 차이는 에이전트가 구현 작업을 더 많이 수행하는 환경에서도 IDE가 소프트웨어 개발의 중심으로 남을 수 있는지를 시험하는 JetBrains Air EAP를 만든다.

JetBrains Air in IDEs는 작업 공간과 모델을 분리한다

JetBrains Air in IDEs는 새로운 모델이나 AI Assistant의 대체 명칭이 아니라 오케스트레이션 계층이다.

JetBrains는 Marketplace와 자사 IDE의 2026.3 EAP 빌드를 통해 10월 초 EAP를 출시했다. 회사의 Air EAP 발표에 따르면, 플러그인은 에이전트가 설치되지 않은 상태로 제공되며 AI 제공업체 역할을 하지 않는다.

이 설계는 사용자가 종종 하나의 묶음 경험으로 접하는 세 가지 제품을 분리한다는 점에서 중요하다. 모델은 텍스트를 생성하거나 해석한다. 코딩 에이전트는 작업을 계획하고, 도구를 조작하고, 파일을 편집하며, 명령을 실행한다. Air는 이러한 에이전트와 작업을 IDE 안에서 정리한다.

개발자는 각 제공업체의 인증 규칙에 따라 이미 사용하는 에이전트를 연결할 수 있다. 호환되는 서드파티 에이전트를 실행하기 위해 JetBrains AI 구독이 반드시 필요한 것은 아니다. Air는 로컬 에이전트 설치를 감지하고, 레지스트리를 통해 에이전트를 제안하며, 지원되는 인증 방식을 재사용할 수 있다.

Codex, Gemini, GitHub Copilot, Claude Agent, Junie 등 5개 에이전트에는 명시적인 일급 지원이 제공된다. Cursor와 다른 도구는 ACP 호환성을 통해 연결할 수 있지만, 정확한 인터페이스와 인증 경로는 에이전트마다 다를 수 있다.

이 제품은 하나의 지속적인 채팅이 아니라 세션을 중심으로 작업을 구성한다. 각 세션은 작업, 해당 에이전트, 맥락, 진행 상황, 그리고 생성한 변경 사항을 나타낸다. 개발자는 프로젝트 전반의 활성 작업을 보고, 입력을 기다리는 세션을 식별하며, 완료된 변경 사항을 열어 검토할 수 있다.

Air는 프리셋도 지원한다. 프리셋은 에이전트, 모델 선택, 추론 노력 수준, 접근 권한 및 기타 시작 설정을 저장한다. 이를 통해 팀은 일상적인 수정, 대규모 리팩터링, 검토 또는 실험에 맞는 서로 다른 구성을 만들 수 있다.

이 구조는 IDE를 디스패처로 바꾼다. 개발자는 실패한 테스트를 Codex에 보내고, 문서 변경을 Gemini에 할당하며, Junie에게 성능 문제를 조사하게 할 수 있다. Air는 이 에이전트들이 하나의 집단 지능으로 협력한다고 주장하지 않는다. 대신 각 작업에 눈에 보이는 위치를 부여하고, 결과물을 검토 워크플로 안에 유지한다.

이 구분은 “AI 에이전트 5개를 실행한다”는 표현에 관한 중요한 오해를 막는다. Air는 기본으로 이름이 지정된 5개 에이전트를 지원하지만, 이들 모두를 함께 실행해야 하는 것은 아니다. 또한 동시에 실행되는 에이전트가 호환되는 코드를 생성한다고 보장하지도 않는다.

JetBrains의 현재 Air 문서는 로컬 에이전트가 개발자의 머신에서 실행된다고 설명한다. Air는 ACP 호환 에이전트와 프로토콜을 통해 통신하며, 명령줄 에이전트는 IDE 안에서 자체 터미널 인터페이스를 유지할 수 있다.

이 플러그인은 2026.2 버전에 설치할 수 있으며 2026.3 EAP 빌드에는 기본 포함된다. JetBrains는 이제 Android Studio를 제외한 자사 IDE 전반을 지원한다고 문서화하고 있다. 가용성, 에이전트 인증, 클라우드 실행은 여전히 사용자의 제품 버전과 조직 설정에 따라 달라질 수 있다.

이러한 세부 사항은 단순한 배포 업데이트를 넘어선다. JetBrains는 위임된 작업을 중심으로 AI 인터페이스를 재구성하는 한편, 기존 편집기, 디버거, 검사, 탐색, 버전 관리 도구를 결과물 가까이에 유지하고 있다.

JetBrains가 AI 채팅 패널을 넘어서는 이유

JetBrains에 가해지는 압력은 단지 더 강력해진 언어 모델이 아니라 개발자 행동의 변화에서 비롯된다.

IDE 기반 AI 기능의 1세대는 자동 완성과 채팅에 초점을 맞췄다. 개발자는 코드를 선택하고, 질문하고, 답변을 받은 뒤 무엇을 붙여 넣거나 적용할지 결정했다. 이 상호작용은 사이드 패널 안에 무리 없이 들어맞았다.

코딩 에이전트는 다른 관리 문제를 만든다. 여러 파일을 읽고, 계획을 세우고, 명령을 실행하고, 리포지터리를 수정하며, 제어권을 돌려주기 전에 테스트를 실행할 수 있다. 개발자는 첫 번째 에이전트가 활성 상태인 동안 다른 작업도 시작할 수 있다.

JetBrains는 기존 AI Assistant 채팅 안에 더 많은 에이전트를 배치해 보았다고 말한다. 회사는 동시 작업을 감독하려면 대화 기록이 아니라 작업 상태를 중심으로 구성된 제품이 필요하다는 결론에 도달했다.

이 결론은 EAP 동안 Air와 AI Assistant가 별도로 유지되는 이유를 설명한다. AI Assistant는 기존 IDE 경험 안에서 채팅, 코드 완성, 코드 인사이트, 다음 편집 제안, 에이전트 접근을 계속 제공한다. Air는 에이전트와 세션을 작업의 주요 단위로 다룬다.

JetBrains는 시간이 지나면서 Air가 주요 에이전틱 인터페이스가 될 것으로 예상하지만, AI Assistant 제거를 발표하지는 않았다. 사용자는 AI Assistant를 계속 설치해 둘 수 있다. 다만 AI Assistant 알림을 통해 Air를 설치하면 두 인터페이스가 동시에 실행되는 것을 막기 위해 기존 플러그인이 비활성화된다. 플러그인 설정에서 다시 활성화할 수 있다.

더 깊은 경쟁 이슈는 개발자의 관심을 누가 차지하느냐다. 에이전트 우선 에디터와 명령줄 도구는 기존 IDE에서 작업을 빼앗아 갈 수 있다. 개발자가 대부분의 시간을 다른 곳에서 프롬프트를 입력하고 패치를 검토하는 데 쓴다면, IDE는 어려운 디버깅에만 사용하는 보조 공간이 될 위험이 있다.

Air는 이 흐름을 뒤집으려 한다. 개발자에게 JetBrains와 외부 에이전트 중 하나를 선택하도록 강요하는 대신, 외부 에이전트를 JetBrains 환경으로 끌어들인다. 에이전트는 계획과 생성을 제공하고, IDE는 리포지터리 맥락과 검증 도구를 제공한다.

이 접근 방식은 모델 교체 주기도 다룬다. 선도적인 코딩 모델은 조직이 개발 환경을 바꾸는 속도보다 더 빠르게 바뀔 수 있다. 기업은 Java 마이그레이션에는 한 에이전트를, 인터페이스 작업에는 다른 에이전트를, 제한된 코드가 포함된 리포지터리에는 내부 에이전트를 선호할 수 있다.

Air가 이러한 시스템을 관리하는 장소로 남는다면, JetBrains는 Junie가 모든 비교에서 이길 필요가 없다. 더 강력한 서드파티 에이전트는 공유 작업 공간을 더 유용하게 만들기 때문에 회사에도 이익이 될 수 있다.

이 때문에 ACP가 중심적인 역할을 한다. ACP 계약은 IDE 같은 클라이언트와 에이전트 사이의 공통 연결을 정의한다. 에이전트는 자체 모델 선택, 도구, 인증, 계획 동작을 유지한다.

JetBrains는 이 경계를 Language Server Protocol의 역할에 비유한다. 에디터는 호환되는 모든 언어 서버마다 별도의 비공개 통합을 필요로 하지 않는다. ACP는 모든 에이전트와 모든 개발 환경 사이에 맞춤형 플러그인이 필요한 일을 줄이는 것을 목표로 한다.

이 비유에는 한계가 있다. 코딩 에이전트는 명령을 실행하고 리포지터리의 많은 부분을 변경할 수 있으므로, 권한과 부수 효과에 더 큰 위험이 따른다. 그럼에도 공통 연결 계층은 통합 작업을 줄이고 에이전트 전환에 따른 혼란을 완화한다.

JetBrains에는 이것이 전략적 기회를 만든다. Cursor, Codex, Claude, Copilot, Gemini를 모델 계층에서 반드시 이길 필요는 없다. 이들은 JetBrains 멀티 에이전트 IDE 안의 선택지가 될 수 있다.

IDE는 에이전트 작업의 제어 평면이 된다

Air의 핵심 베팅은 코드 생성이 쉬워질수록 검증의 가치가 더 커진다는 것이다.

패치를 생성하는 일은 소프트웨어 개발의 한 부분일 뿐이다. 누군가는 해당 패치가 요구 사항에 부합하는지, 아키텍처를 보존하는지, 테스트를 통과하는지, 보안 경계를 준수하는지, 실제 조건에서 올바르게 작동하는지를 판단해야 한다.

JetBrains는 이미 이 작업에 사용되는 많은 도구를 보유하고 있다. 자사 IDE는 심볼, 타입, 참조, 프로젝트 구조, 테스트 실행기, 버전 관리, 데이터베이스, 디버거, 성능 프로필을 이해한다. Air는 에이전트 활동을 이러한 기존 작업 화면에 연결한다.

에이전트는 파일, 커밋, 스크린샷, 재사용 가능한 지침을 맥락으로 전달받을 수 있다. 개발자는 변경된 파일을 검사하고, diff를 비교하고, 관련 코드를 탐색하며, 결과물을 다른 애플리케이션으로 옮기지 않고 프로젝트를 실행할 수 있다.

이 연결은 중복 탐색을 줄일 수 있다. 코딩 에이전트는 디렉터리를 나열하고, 구성 파일을 열고, 관련 심볼을 찾는 데 토큰을 자주 사용한다. IDE가 제공하는 맥락은 에이전트를 더 일찍 올바른 코드로 안내할 수 있지만, 절감 효과는 에이전트와 작업에 따라 달라질 것이다.

Air는 지원되는 에이전트에 디버깅, 프로파일링, 데이터베이스 탐색, 의미 기반 코드 검색 같은 활동을 위한 IDE 스킬도 제공한다. JetBrains는 이러한 도구가 일부 작업의 결과를 개선할 수 있다고 말하지만, 이 주장은 여전히 다양한 리포지터리와 언어에서 폭넓은 검증이 필요하다.

에이전트 세션은 이 워크플로의 컨테이너가 된다. 선택한 에이전트, 대화, 활동, 변경 파일, 커밋, 보고된 비용을 기록한다. 세션은 여러 프로젝트에 걸쳐 계속 표시될 수 있어, 개발자가 완료됐거나 개입이 필요한 작업을 파악하는 데 도움이 된다.

이 모델은 채팅 탭 5개를 여는 것과 다르다. 채팅 탭은 주로 대화를 보존한다. Air 세션은 대화를 리포지터리 상태와 검토 작업에 연결한다.

통합 테스트가 실패한 서비스를 맡은 개발자를 생각해 보자. 하나의 세션은 실패 원인을 조사할 수 있다. 두 번째 세션은 격리된 브랜치에서 관련 의존성을 업데이트할 수 있다. 세 번째 세션은 변경의 영향을 받는 문서를 점검할 수 있다.

이 세션들이 진행되는 동안 개발자는 메인 체크아웃에서 계속 작업할 수 있다. 하나가 완료되면 IDE는 diff를 검토하고, 검사를 실행하고, 테스트를 확인하며, 결과물이 대상 브랜치에 포함되어야 하는지 결정하는 장소가 된다.

이 과정은 엔지니어링 작업의 더 넓은 변화와 맞닿아 있다. 개발자들은 모든 구현을 직접 입력하는 대신 생성된 변경 사항을 점점 더 조율하게 된다. 그들의 책임이 사라지는 것은 아니다. 작업을 명세하고, 맥락을 제공하고, 증거를 검토하며, 충돌을 해결하는 쪽으로 이동한다.

JetBrains는 IDE를 이러한 책임을 위한 제어 평면으로 자리매김하고 있다. 이 용어는 작업자 자체가 되지 않으면서 작업자와 상태를 조율하는 화면을 뜻한다. Air는 여러 에이전트를 더 쉽게 감독하게 만든다면 최고의 패치를 생성하지 않아도 가치를 가질 수 있다.

모델은 또한 사용자의 선택권을 보장한다. 제공업체가 허용하는 경우 개발자는 기존 구독을 연결하거나 JetBrains AI를 선택하거나 로컬에서 구성한 ACP agent를 사용할 수 있다. Air 자체는 독점 모델을 제공하지 않는다.

이러한 유연성은 전략적으로 중요하다. 하나의 모델에 묶인 폐쇄형 워크스페이스는 해당 모델의 약점과 상업적 변화까지 함께 물려받는다. 멀티 에이전트 워크스페이스는 프로젝트 관행과 검토 도구를 유지하면서도 개발자가 agent를 교체할 수 있게 해 준다.

검색 가능한 엔지니어링 컨텍스트를 이미 구축하는 팀이라면 같은 패턴을 알아볼 수 있다. 지속적인 자산은 하나의 답변이 아니라 코드, 의사결정, 문서, 검토를 연결하는 구조다. 기술 지식 베이스는 하나의 코딩 작업을 넘어 보존되어야 할 정보를 유지함으로써 agent 세션을 보완할 수 있다.

Air만으로는 이처럼 더 광범위한 지식 문제를 해결하지 못한다. 세션에는 유용한 작업 컨텍스트가 담기지만, 팀에는 아키텍처 결정, 장애, 요구사항을 위한 지속적인 기록도 필요하다. IDE는 구현을 조율할 수 있고, 공유 지식 시스템은 그 구현이 존재하는 이유를 보존한다.

병렬 Agent는 병합과 주의력 문제를 만든다

더 많은 agent를 실행한다고 해서 개발자가 그 결과를 검토하고, 조정하며, 신뢰할 수 있을 때에만 처리량이 증가한다.

Air는 개발자가 브랜치에서 세션을 시작하고 작업을 임시 Git worktree에 배치할 수 있게 한다. worktree는 동일한 저장소 이력에 연결된 별도의 작업 사본이다. 이를 통해 agent의 편집을 개발자의 현재 체크아웃과 분리한다.

이러한 격리는 병렬 작업에 필수적이다. 하나의 워크스페이스에서 동일한 파일을 편집하는 두 agent는 서로의 가정을 덮어쓰거나, 각각에서는 통과하지만 함께 사용하면 실패하는 변경을 만들 수 있다. 별도의 worktree는 직접적인 간섭을 줄인다.

Air는 결과를 표시하고 개발자가 선택한 커밋을 활성 프로젝트로 다시 전송할 수 있게 한다. 문서화된 세션 워크플로는 변경 사항을 대상 브랜치에 cherry-pick하기 전에 검토하는 과정을 지원한다.

격리가 통합 작업을 없애지는 않는다. 다섯 agent가 연결된 영역을 변경하면 개발자는 다섯 개의 브랜치, 중복 편집, 일관되지 않은 추상화, 병합 충돌에 직면할 수 있다. 각 agent는 그럴듯한 로컬 결과를 만들 수 있지만, 결합된 시스템은 오히려 덜 일관되게 될 수 있다.

그러면 병목은 코드 생산에서 사람의 주의력으로 옮겨간다. 개발자는 각 agent가 무엇을, 왜 변경했는지 이해해야 한다. 또한 코드를 작성한 동일한 시스템이 생성한 성공 요약을 그대로 받아들이기보다, 어떤 테스트가 의미 있는 증거를 제공하는지 결정해야 한다.

Air의 세션 목록은 이러한 작업량을 드러내는 데 도움이 된다. 활성 세션, 읽지 않은 업데이트, 변경된 파일, 전송 예정 커밋, 입력을 기다리는 작업을 보여줄 수 있다. 이러한 가시성은 유용하지만, 근본적인 결정이 올바른지 판별할 수는 없다.

이것이 JetBrains Air EAP의 핵심적인 트레이드오프다. 병렬화는 대기 시간을 줄일 수 있지만, 동시에 검토 의무를 늘릴 수도 있다. 검증할 수 있는 속도보다 더 빠르게 agent를 실행하는 팀은 불확실한 패치의 대기열만 더 크게 만들게 된다.

프리셋은 또 다른 거버넌스 문제를 제기한다. 구성을 반복 가능하게 하지만, 팀은 각 작업 유형에 어떤 모델, 권한, 노력 수준이 적절한지 결정해야 한다. 일회성 테스트 저장소에는 적합한 고권한 agent가 프로덕션 인프라에는 용납될 수 없을 수 있다.

인증 역시 여전히 균일하지 않다. JetBrains는 제공업체 관리 로그인, 타사 자격 증명, JetBrains AI를 포함한 여러 경로를 지원한다. 그러나 한 인터페이스에서 사용할 수 있는 구독이 다른 환경에서 동일한 agent를 승인하지는 않을 수 있다.

Claude는 이러한 복잡성을 잘 보여준다. JetBrains는 Claude 구독을 터미널 환경을 통해 사용할 수 있다고 밝히는 한편, 구조화된 채팅의 Claude Agent에는 JetBrains AI 또는 API 과금이 설정된 Anthropic API 키가 필요하다고 설명한다. 개발자는 Air를 범용 구독 허브로 간주하기 전에 현재 인증 규칙을 확인해야 한다.

클라우드 실행은 더 많은 경계를 추가한다. 로컬 세션은 개발자의 머신에서 실행되지만, 자격을 갖춘 조직은 특정 작업을 JetBrains 인프라로 보낼 수 있다. 클라우드 실행은 IDE를 닫은 뒤에도 계속될 수 있지만, 이용 가능 여부는 조직 설정, 저장소 호스팅, JetBrains AI 구독에 따라 달라진다.

따라서 데이터 처리는 선택한 경로에 따라 달라진다. JetBrains는 타사 구독을 사용할 때 타사 agent 데이터가 사용자의 기존 계약에 따라 해당 제공업체로 직접 전송된다고 말한다. JetBrains AI와 클라우드 기능에는 적용되는 약관이 적용된다.

EAP 계약도 성숙도 수준을 명확히 한다. 얼리 액세스 소프트웨어에는 오류가 있을 수 있고, 예기치 않게 동작할 수 있으며, 개발 과정에서 변경될 수 있다. agent가 파일을 편집하고 명령을 실행할 수 있는 상황에서 팀은 EAP 레이블을 일상적인 배지로 취급해서는 안 된다.

신중한 도입은 중요하지 않은 저장소와 제한적인 권한에서 시작해야 한다. 팀은 사람의 검토를 요구하고, 복구 가능한 브랜치를 유지하며, 병합 전에 독립적인 테스트를 실행해야 한다. 민감한 코드는 agent에게 컨텍스트를 제공하기 전에 명확한 제공업체 및 데이터 라우팅 결정이 필요하다.

이러한 통제 장치는 IDE에서 JetBrains Air를 반대하는 논거가 아니다. 이는 병렬 모델이 유용해지는 조건이다. 오케스트레이션은 활동 대시보드 뒤에 책임을 숨기는 대신 책임을 더 명확히 보이게 할 때에만 레버리지를 만든다.

JetBrains는 경쟁사를 교체 가능한 구성 요소로 바꾸고 있다

Air는 JetBrains 개발 환경을 유지하면서 경쟁사의 agent를 흡수해 agent 우선 에디터에 도전한다.

가장 중요한 경쟁자는 한 회사가 아니다. 코딩 agent가 개발자 워크스페이스 전체를 소유해야 한다는 발상이다.

agent 우선 에디터는 하나의 통합 시스템을 중심으로 모든 상호작용을 최적화할 수 있다. 이는 집중된 경험을 만들지만, 개발자의 워크플로를 해당 제품의 모델 라우팅, 인터페이스 결정, 출시 일정에 의존하게 만들 수도 있다.

JetBrains는 반대 입장을 취한다. IDE는 안정적으로 유지되고, agent는 그 안에서 작업을 두고 경쟁한다. 개발자는 코드를 생성하는 시스템을 바꾸면서도 익숙한 탐색, 리팩터링, 디버깅, 검사 도구를 계속 사용할 수 있다.

ACP는 이러한 제안을 신뢰할 만하게 만든다. 공유 프로토콜이 없다면 여러 agent를 지원하려면 계속 늘어나는 비공개 통합 모음이 필요하다. 제공업체 업데이트가 커넥터를 손상시키거나 제품 전반에서 기능을 일관되지 않게 만들 수 있다.

ACP를 사용하면 교체 가능한 단위는 모델 하나에 그치지 않는다. agent는 계획 수립 로직, 도구, 권한, 모델 라우팅, 인터페이스 동작을 함께 가진다. Air는 공통 클라이언트 경계를 통해 이 전체 패키지에 연결한다.

이는 JetBrains가 외부 혁신의 혜택을 얻는 방법이기도 하다. Codex가 저장소 규모의 변경 작업을 더 잘하게 되면 Air 사용자는 이를 선택할 수 있다. Gemini가 다른 워크로드에 더 적합해지더라도 워크스페이스를 바꿀 필요는 없다. 내부 ACP agent는 제한된 작업을 담당할 수 있다.

따라서 다섯 개의 명명된 agent는 고정된 상한이 아니라 초기 구성원이다. Codex, Gemini, GitHub Copilot, Claude Agent, Junie는 EAP에 인지하기 쉬운 선택지를 제공한다. 레지스트리와 사용자 지정 구성은 가능한 선택의 범위를 넓힌다.

Cursor는 이를 잘 보여주는 사례다. Cursor는 AI 지향 코딩 환경으로서 개발자의 관심을 두고 경쟁하지만, 그 agent는 ACP를 통해 JetBrains 제품에도 연결할 수 있다. JetBrains는 에디터 전환과 연관된 제품을 자체 IDE 안에서 사용할 수 있는 작업자로 바꿀 수 있다.

그렇다고 사용자가 반드시 머문다는 보장은 없다. 네이티브 agent 우선 제품은 여전히 더 일관된 인터페이스, 더 빠른 기능 제공, 선호 모델과의 더 긴밀한 통합을 제공할 수 있다. 프로토콜 호환성이 모든 클라이언트 경험을 동일하게 만드는 경우는 드물다.

Air는 선택의 복잡성도 정당화해야 한다. 서로 다른 권한, 구독, 모드, 강점을 가진 다섯 agent는 익숙한 하나의 도구보다 관리하기 더 까다로워질 수 있다. 워크스페이스에는 명확한 상태, 예측 가능한 구성, 신뢰할 수 있는 검토 정보가 필요하다.

JetBrains 자체 제품군도 또 다른 위험을 더한다. 사용자는 이미 AI Assistant, Junie, Air, ACP agents, 제공업체 계정, JetBrains AI를 접하고 있다. Air는 더 깔끔한 개념적 구분을 만들지만, 전환 기간에는 여전히 파편화되어 느껴질 수 있다.

회사는 AI Assistant는 채팅과 인라인 지원을 위해 유지하면서, Air를 agent 기반 워크플로를 위한 전용 환경으로 만들어 이 문제를 해결하려 한다. 사용자가 이러한 구분을 이해하고 선호하는지가 EAP의 핵심 결과가 될 것이다.

JetBrains는 처음에 독립형 Air 환경을 AI가 추가된 에디터가 아니라 agent를 중심으로 구축된 공간으로 소개했다. 3월 공개 프리뷰는 동시 위임을 제품의 핵심 아이디어로 확립했다.

그 경험을 기존 IDE로 가져오면 제안의 성격이 바뀐다. 개발자는 워크플로를 시험하기 위해 별도 애플리케이션을 채택할 필요가 없다. JetBrains는 이미 엔지니어링 팀에 자리 잡은 제품을 통해 Air를 배포할 수 있다.

이러한 배포상의 이점은 의미가 있지만, 도입은 일상적인 유용성에 달려 있다. 개발자는 단지 여러 agent를 인식한다는 이유만으로 또 하나의 도구 창을 계속 사용하지 않을 것이다. Air는 별도의 터미널이나 제공업체 애플리케이션보다 동시 작업을 더 쉽게 이해하고, 검토하고, 병합할 수 있게 해야 한다.

JetBrains Air EAP 이후 주목할 점

다음 시험대는 Air가 몇 개의 agent를 나열하는지가 아니라, 팀이 더 적은 컨텍스트 전환과 감당 가능한 검토 비용으로 실제 작업을 완료하는지다.

첫 번째 신호는 일반적인 저장소 전반의 도입이다. JetBrains는 병렬 세션 실행의 새로움이 사라진 뒤에도 개발자가 Air를 계속 사용하는지에 대한 증거가 필요하다. 디버깅, 유지보수, 테스트, 리팩터링 전반에서 반복적으로 사용된다면 오케스트레이션 가설을 뒷받침할 것이다.

유용한 지표는 프롬프트 수가 아니다. 팀은 완료된 작업, 승인된 변경, 검토 시간, 재발견된 결함, agent가 작업을 마친 뒤 필요한 수동 수정량을 살펴봐야 한다. 높은 세션 수는 낮은 품질의 출력을 가릴 수 있다.

두 번째 신호는 worktree 기반 통합의 신뢰성이다. Air는 브랜치 상태, 커밋되지 않은 변경, 충돌, 전송 대상을 분명하게 보여줘야 한다. 병렬 agent를 위해 설계된 시스템은 개발자가 작업을 잃거나 올바른 패치를 잘못된 브랜치에 적용하지 않도록 막아야 한다.

JetBrains는 안전장치와 검토 제어 기능을 문서화하고 있지만, EAP는 이것들이 일상의 압박 속에서 어떻게 작동하는지 드러낼 것이다. 대규모 저장소, 생성된 파일, 모노레포, 중복되는 리팩터링은 고립된 데모보다 더 어려운 시험을 제공할 것이다.

세 번째 신호는 agent 제공업체와 경쟁 에디터의 대응이다. 더 폭넓은 ACP 도입은 개발자가 지원되는 클라이언트 사이에서 agent를 이동할 수 있게 하므로 JetBrains의 개방형 워크스페이스 전략을 강화할 것이다. 반대로 제공업체는 자체 애플리케이션에서 가장 잘 작동하는 독점 기능을 선호할 수 있다.

일반적인 기능 지원은 agent 수만큼 중요하다. 권한, 도구 호출, 컨텍스트 첨부, 비용 보고, 세션 재개, diff 출처 표시는 일관되게 동작해야 한다. 많은 agent를 연결하지만 가장 낮은 공통 기능만 노출하는 프로토콜은 Air의 이점을 제한할 것이다.

조직은 관리 제어 기능도 지켜봐야 한다. JetBrains는 기업이 관리형 AI 액세스를 통해 Air를 비활성화할 수 있다고 말하지만, 문서에는 IDE Services 관리가 아직 완전하지 않다고 명시돼 있다. 엔터프라이즈 도입에는 제공업체, 자격 증명, 클라우드 실행, 데이터 라우팅, 감사 가능성에 관한 명확한 정책이 필요하다.

Air와 AI Assistant의 관계도 또 하나의 구체적인 신호다. JetBrains는 Air가 선호되는 에이전틱 경험이 되더라도 AI Assistant는 계속 지원될 것이라고 밝혔다. 향후 릴리스에서는 이 구분이 더 단순해질지, 아니면 인터페이스가 겹치게 될지가 드러날 전망이다.

성공적인 전환이 이루어진다면 개발자는 위임 작업을 위한 명확한 한 공간과 가벼운 인라인 도움을 위한 또 다른 공간을 갖게 될 것이다. 반대로 혼란스러운 전환은 사용자가 각 에이전트, 구독 또는 채팅 모드를 어떤 플러그인이 담당하는지 이해해야 하는 상황을 만들 수 있다.

지원되는 5개 에이전트는 전문화가 실질적인 가치를 제공하는지도 보여줄 것이다. 개발자에게는 한 작업에는 Codex를, 다른 작업에는 Junie 또는 Gemini를 선택해야 하는 분명한 이유가 필요하다. 그렇지 않으면 선택기는 생산성 기능이 아니라 관리상의 선택지가 된다.

IDE의 JetBrains Air는 생성된 코드가 컨텍스트와 검토의 가치를 높인다는 타당한 전제에 기반한다. 아직 해결되지 않은 질문은 하나의 IDE가 개발자를 상시 큐 관리자로 만들지 않으면서 충분한 에이전트를 체계화할 수 있느냐는 것이다.

복구 가능한 브랜치에서 EAP를 사용해 여러 파일, 테스트, 검토 단계를 넘나드는 작업을 맡겨 보라. 그런 다음 전체 워크플로를 현재의 에이전트 구성과 비교해 보라. Air는 컨텍스트 전환을 줄이고, 변경 사항을 더 쉽게 검토하게 하며, 리포지토리에 대한 통제권을 유지해 주었는가? 아니면 단지 하나의 창에 다섯 개의 인터페이스를 모아 놓았을 뿐인가? 실제 팀들에서 반복적으로 나올 그 답이 JetBrains Air가 에이전틱 개발을 위한 운영 계층이 될지, 아니면 흥미로운 실험으로 남을지를 결정할 것이다.