JetBrains Air 퍼블릭 프리뷰 실전 평가 가이드: 멀티 에이전트 개발환경 도입 전 확인할 5가지

1. 문제 정의: 어떤 팀이 지금 JetBrains Air를 검토해야 하나

JetBrains Air는 단순히 “AI 채팅창이 하나 더 생긴 도구”가 아닙니다. JetBrains가 공개한 설명대로, 여러 코딩 에이전트를 한 환경 안에서 병렬로 돌리고 전환하는 agentic development environment에 가깝습니다. 문제는 이런 유형의 도구가 좋아 보인다고 바로 전사 도입하면, 실제로는 기존 IDE·보안 규칙·리뷰 프로세스와 부딪혀 생산성이 오히려 흔들릴 수 있다는 점입니다.

이 글은 다음 팀을 대상으로 씁니다.

Codex, Claude Agent, Gemini CLI처럼 서로 다른 에이전트를 이미 쓰고 있는데 작업 맥락이 흩어져 있는 팀
Git worktree, Docker 격리, 코드리뷰를 포함한 개발 표준을 유지하면서 에이전트 실험을 하고 싶은 팀
JetBrains 생태계와 ACP를 활용해 “특정 벤더 종속” 없이 운영 모델을 설계하려는 팀

반대로 이 글의 범위에서 제외하는 것은 두 가지입니다. 첫째, 아직 macOS 외 운영체제에 바로 배포하는 시나리오입니다. 공식 발표 기준으로 현재 퍼블릭 프리뷰는 macOS 우선이며 Windows와 Linux는 “coming soon” 상태입니다. 둘째, IDE를 완전히 버리고 에이전트 환경 하나로 모든 개발을 대체하는 접근입니다. JetBrains도 Air를 기존 IDE를 대체하는 도구보다, 에이전트 오케스트레이션 중심 환경으로 설명하고 있습니다.

2. 왜 지금 주목할 만한가: Air의 핵심 가치와 한계

공식 발표에서 가장 중요한 포인트는 세 가지였습니다. 첫째, Codex·Claude Agent·Gemini CLI·Junie를 기본 지원한다는 점입니다. 둘째, 각 작업을 Docker 컨테이너나 Git worktree로 격리해 병렬로 실행할 수 있다는 점입니다. 셋째, 특정 라인·커밋·클래스·메서드 단위로 태스크 컨텍스트를 지정할 수 있어, 에이전트에게 막연한 텍스트 대신 구조화된 코드 맥락을 전달할 수 있다는 점입니다.

다만 한계도 분명합니다. 현재는 개인 개발자 생산성 중심의 퍼블릭 프리뷰 단계이고, 팀 협업 기능은 “다음 단계”로 예고된 수준입니다. 운영체제 지원도 macOS 우선입니다. 따라서 지금 할 일은 “전사 표준 도구 채택”이 아니라, 고품질 파일럿 평가입니다. 도입 여부보다 먼저 검증 항목을 고정해야 합니다.

3. 대안 비교: Air를 어디와 비교해야 판단이 맞나

Air를 평가할 때 가장 흔한 실수는 Cursor, Claude Code, Copilot CLI 같은 단일 에이전트 경험과 1:1로 비교하는 것입니다. 실무에서는 비교 축을 “누가 더 똑똑한가”가 아니라 “운영 모델이 팀에 맞는가”로 바꿔야 합니다.

대안	강점	약점	적합한 팀
JetBrains Air	멀티 에이전트 전환, 작업별 격리, 코드 문맥 지정, JetBrains 워크플로우 친화성	퍼블릭 프리뷰, macOS 우선, 팀 기능은 아직 제한적	이미 여러 에이전트를 혼용하고 있고 운영 표준을 만들려는 팀
단일 에이전트 CLI/에디터 조합	빠른 시작, 개별 도구 최적화, 학습 비용 낮음	세션 분산, 컨텍스트 단절, 병렬 작업 관리가 사람 손에 의존	개인 생산성 최적화가 우선인 팀
IDE 내 ACP 연동 중심	IDE를 유지하면서 ACP 에이전트 확장 가능, 구독 의존도 낮춤	에이전트 오케스트레이션 UX는 Air보다 단순할 수 있음	현재 IDE를 유지한 채 ACP 기반 실험만 필요한 팀

의사결정 기준은 최소한 다음 네 가지여야 합니다.

시간: 병렬 작업이 실제 리드타임을 줄이는가, 아니면 검수 비용만 늘리는가
통제: Docker/worktree 격리, 로그 수집, 승인 절차를 붙이기 쉬운가
호환성: 현재 개발환경이 macOS 중심인지, WSL 의존도가 높은지
벤더 리스크: ACP와 BYOK로 교체 가능성을 확보할 수 있는가

4. 단계별 실행: 5일 파일럿 평가 절차

도입 검토는 기능 시연이 아니라 파일럿 운영으로 해야 합니다. 아래는 5일 평가 절차입니다.

Day 1. 평가 범위 고정

대상 저장소 1개만 선택합니다. 프론트엔드/백엔드가 섞인 중간 난이도 프로젝트가 좋습니다.
업무 3종만 고릅니다: 버그 수정 1개, 리팩터링 1개, 문서/테스트 보강 1개.
성공 기준을 미리 적습니다. 예: PR 생성 시간 30% 단축, 사람 재작업 20% 이하, 테스트 통과율 100%.

Day 2. 에이전트 조합 설계

Air가 기본 지원하는 에이전트 중 최소 2개를 조합합니다. 예를 들어 구조 탐색은 Codex, 긴 문맥 리팩터링은 Claude Agent, 스크립트성 작업은 Gemini CLI처럼 역할을 나눕니다. 핵심은 “최고 모델 찾기”가 아니라 어떤 작업을 어떤 에이전트에 맡길지 역할 경계를 만드는 것입니다.

Day 3. 격리 전략 검증

공식 발표대로 Docker 컨테이너 또는 Git worktree 격리를 실제로 사용합니다. 병렬 세션 2개 이상을 띄워 다음을 기록합니다.

의존성 설치 재현 시간
작업 충돌 여부
메인 브랜치 반영 전 diff 검토 난이도

Day 4. ACP 확장성 검증

JetBrains 공식 문서 기준으로 ACP 호환 에이전트는 레지스트리 설치 또는 ~/.jetbrains/acp.json 수동 등록이 가능합니다. 가능하면 파일럿 중 하루는 ACP 기반 커스텀 에이전트도 붙여 보십시오. 그래야 특정 벤더 UI가 아니라 프로토콜 기반 운영이 가능한지 확인할 수 있습니다.

{
  "default_mcp_settings": {
    "use_idea_mcp": true,
    "use_custom_mcp": true
  },
  "agent_servers": {
    "example-agent": {
      "command": "/path/to/agent",
      "args": ["acp"],
      "env": {
        "API_KEY": "redacted"
      }
    }
  }
}

이 예시는 JetBrains 공식 ACP 문서 구조를 축약한 것입니다. 실제 운영에서는 민감정보를 별도 비밀관리 체계로 분리해야 합니다.

Day 5. 리뷰/통제 보고서 작성

파일럿 마지막 날에는 다음 항목을 1페이지로 남기면 됩니다.

작업별 소요 시간과 사람 검수 시간
에이전트별 강점/실패 패턴
격리 미사용 대비 충돌 감소 여부
정식 도입 조건: macOS 파일럿 유지 / Linux 대기 / 특정 팀만 제한 도입 등

5. 자주 실패하는 4가지 패턴과 복구법

실패 1. “모든 작업을 병렬로 돌리면 더 빠르다”는 착각

병렬 실행은 처리량을 늘리지만, 검수 대기열도 같이 늘립니다. 해결책은 병렬 세션 수를 팀 리뷰 역량에 맞추는 것입니다. 일반적으로 한 명의 리뷰어가 동시에 제대로 검수할 수 있는 활성 세션은 2개 안팎입니다.

실패 2. 에이전트 역할 경계가 없음

같은 문제를 여러 에이전트에게 무작정 던지면 비교는 가능하지만 운영 표준은 남지 않습니다. 해결책은 “탐색형/수정형/검증형”처럼 역할을 먼저 나누고, 실패 시 다른 에이전트로 넘기는 승격 규칙을 정하는 것입니다.

실패 3. ACP는 붙였지만 로그를 안 남김

JetBrains 문서에는 ACP 로그 수집 방법이 따로 있습니다. 퍼블릭 프리뷰를 운영하면서 로그를 남기지 않으면 문제 재현이 거의 불가능합니다. extended logging은 개발용 샌드박스에서만 켜고, 민감정보 마스킹 규칙을 함께 두는 편이 안전합니다.

실패 4. 운영체제 현실을 무시함

현재 공식 가이드 기준으로 ACP 호환 에이전트는 WSL을 지원하지 않습니다. 또 Air 자체도 macOS 우선 공개입니다. Windows/Linux 주력 조직이라면 “지금 바로 표준화”가 아니라 “macOS 실험군 한정 검증”이 맞습니다.

6. 실행 체크리스트와 Definition of Done

대상 저장소 1개와 대표 업무 3종을 선정했다
에이전트별 역할 분담표를 작성했다
Docker 또는 Git worktree 격리 중 최소 1개를 실제로 적용했다
병렬 세션 2개 이상을 운영하며 충돌/검수 시간을 기록했다
ACP 레지스트리 설치 또는 acp.json 수동 등록을 1회 이상 검증했다
로그 수집 및 민감정보 마스킹 원칙을 문서화했다
정식 도입/보류/조건부 도입 중 하나로 결론을 냈다

Definition of Done: 위 7개 항목을 모두 충족하고, 최소 3개의 실제 작업에서 “시간 절감 또는 컨텍스트 통합” 효과가 문서로 확인되며, 운영체제 제약과 보안 통제 방안까지 포함한 결론 보고서가 남아 있으면 파일럿 완료로 봅니다.

7. 작성자 관점: 지금 추천하나, 아직 이른가

제 판단은 명확합니다. 개인 또는 소규모 macOS 중심 팀의 제한적 파일럿은 추천합니다. 이유는 Air가 단일 모델 성능 경쟁보다, 멀티 에이전트 오케스트레이션과 컨텍스트 관리라는 더 실무적인 문제를 정면으로 건드리고 있기 때문입니다.

하지만 전사 표준 도입은 아직 이릅니다. 현재는 퍼블릭 프리뷰이고, Windows/Linux 지원도 진행 중이며, 팀 협업 기능 역시 완성형이라고 보기 어렵습니다. 따라서 가장 현실적인 전략은 “macOS 실험군에서 2주 파일럿 → 격리/로그/역할 분담 표준 수립 → OS 지원 확대 후 재평가”입니다.

한 줄로 정리하면 이렇습니다. Air는 “가장 똑똑한 단일 에이전트”를 찾는 팀보다, 여러 에이전트를 운영 가능한 시스템으로 묶고 싶은 팀에게 더 큰 가치가 있습니다. 그 조건에 맞는 팀이라면 지금 살펴볼 이유가 충분합니다.

참고자료

2026-03-09 — JetBrains Air Launches as Public Preview
2026-03-05 문서 업데이트 — JetBrains AI Assistant Documentation: Agent Client Protocol (ACP)
ACP 공식 사이트 — Agent Client Protocol Introduction