JetBrains Air로 AI 코딩 에이전트 시작하기

JetBrains Air를 사용하면 JetBrains IDE 안에서 AI 코딩 에이전트를 시작하고, 필요한 프로젝트 컨텍스트를 골라 전달한 뒤, 평소 코드를 탐색하고 테스트하던 화면에서 변경 사항을 검토할 수 있습니다. 첫 시도부터 대규모 리팩터링을 맡길 필요는 없습니다. Air Alpha를 설치해 에이전트 하나를 연결하고, 파일 하나와 실패하는 테스트 하나만 건네십시오. diff와 테스트 결과가 납득되기 전에는 어떤 변경도 받아들이지 않는 것이 핵심입니다.

핵심만 먼저 보기

Air는 자동완성 버튼이 아니라 에이전트 관제실처럼 사용해야 합니다. 실제 작업은 에이전트가 수행하고, Air는 세션을 구성해 IDE 컨텍스트를 전달한 뒤 결과를 IDE에 자연스럽게 통합된 검토 화면으로 가져옵니다.

첫 세션은 다음 순서로 진행합니다.

1. IDE Marketplace에서 Air Alpha를 설치합니다.
2. 직접 테스트할 수 있는 일회용 프로젝트나 브랜치를 엽니다.
3. New Session 프리셋을 고르고 Standard Access를 유지합니다.
4. 첫 메시지를 보내고, Air가 요구하면 로그인을 마칩니다.
5. @file:로 관련 파일을 첨부합니다.
6. 작은 수정 하나와 테스트 하나를 요청합니다.
7. Agent Sessions에서 변경된 모든 파일을 확인합니다.
8. 테스트를 직접 실행한 다음 변경 사항을 유지, 수정, 커밋 또는 되돌릴지 결정합니다.

실제로 필요한 흐름은 이것이 전부입니다. 병렬 세션, 더 많은 에이전트, 조직 제어, 클라우드 인계는 이 흐름을 신뢰할 수 있게 된 뒤로 미뤄도 됩니다.

JetBrains Air는 정확히 무엇인가

Air는 JetBrains 프로젝트와 하나 이상의 코딩 에이전트 사이를 잇는 계층입니다. 모형 제작소의 검사대와 비슷합니다. 에이전트가 제안한 부품을 작업대에 올리지만, 치수를 재고 맞물림을 확인하며 최종 결정을 내리는 도구는 여전히 IDE에 있습니다.

9월 22일 릴리스에서 Air는 이름이 붙은 세 축으로 확장됐습니다. 개인 작업용 Air in JetBrains IDEs, 조정과 자동화를 위한 Air Teams, 정책·가시성·비용 관리를 위한 Air Governance입니다. 이 가이드는 로컬에서 직접 실행할 수 있는 Air Alpha IDE plugin에 집중합니다.

IDE 플러그인 자체가 새로운 기반 모델인 것은 아닙니다. Codex, Gemini, GitHub Copilot, Claude, Junie를 기본으로 실행할 수 있으며, JetBrains에 따르면 다른 에이전트도 ACP를 통해 연결할 수 있습니다. ACP, 즉 Agent Client Protocol은 IDE와 에이전트의 전체 작업 체계 사이를 잇는 공통 소켓으로, 에이전트의 툴과 모델 라우팅까지 연결합니다.

현재 Air IDE 페이지에서도 로컬 작업을 클라우드로 넘기는 기능은 아직 출시 예정으로 표시합니다. 첫 실행을 안정적으로 검증하려면 작고 로컬에서 끝나는 작업부터 시작하는 편이 좋습니다.

JetBrains Air 설치 전에 확인할 사항

Air Alpha는 조용히 써도 되는 안정판 유틸리티가 아니라 공개 알파 제품입니다. JetBrains는 UI와 동작이 바뀔 수 있으며 대략 매주 업데이트가 나올 예정이라고 안내합니다. 문제가 생겼다면 다른 원인을 찾기 전에 먼저 호환성을 확인하십시오.

2026년 9월 23일을 기준으로 2026.2 계열용 최신 Marketplace 패키지는 Air 262.8665.463이었습니다. IntelliJ IDEA 2026.2부터 2026.2.3까지, 그리고 목록에 포함된 JetBrains IDE의 해당 2026.2 릴리스를 지원합니다. Marketplace에는 2026.3 계열용 빌드도 있으므로, 사용하는 IDE 브랜치에 따라 정확한 플러그인 빌드는 달라질 수 있습니다.

이번 검증 환경의 호환성

IntelliJ IDEA 2026.2.3 빌드 IU-262.10968.63은 격리된 프로필에서 Air 262.8665.463을 로드했고, 일회용 Node 프로젝트도 플러그인 오류 없이 인덱싱했습니다. 감지된 에이전트는 codex-cli 0.153.4였지만 로그아웃 상태였고, 호스트에는 그래픽 세션이 없었습니다. 따라서 Air의 대화형 작업을 실행했다거나, diff를 생성했다거나, 에이전트가 작성한 테스트가 통과했다고 주장하지 않습니다. 아래 UI 절차는 JetBrains의 현재 퀵스타트와 해당 플러그인 빌드에 포함된 레이블을 따릅니다.

JetBrains Air에서 AI 코딩 에이전트 사용하는 법

1. Air Alpha 설치하기

IDE 설정을 열고 Plugins를 선택한 다음 Marketplace 탭으로 이동합니다. Air Alpha를 검색해 Install을 클릭하고, IDE에서 요청하면 재시작합니다.

Air 자체는 무료입니다. 다만 그 뒤에서 작동하는 에이전트에는 계정, 구독 또는 API 사용료가 필요할 수 있습니다. 비용 때문에 도입을 결정하지 못하고 있다면 Is JetBrains Air Free에서 플러그인 비용과 에이전트 비용을 구분해 확인할 수 있습니다.

2. 부담 없이 실패시킬 수 있는 프로젝트 열기

폐기하거나 초기화해도 되는 기존 프로젝트에서 시작합니다. 첫 작업으로는 관련 파일이 하나이고, 눈으로 확인할 수 있는 실패가 하나이며, 변경 성공 여부를 입증할 명령어가 하나인 문제가 좋습니다.

반복 공백을 제대로 처리하지 못하는 slug 헬퍼, 경계 조건 하나가 빠진 포매터, 단위 테스트 하나가 실패하는 작은 유효성 검사 함수 등이 적합합니다. 첫 실행부터 마이그레이션, 인증, 배포 코드, 광범위한 의존성 업그레이드를 맡기지는 마십시오.

세션을 열기 전에 다음 기준 상태를 기록합니다.

• 현재 브랜치 또는 일회용 worktree
• 정확한 테스트 명령어
• 해당 테스트가 현재 통과하는지 실패하는지
• 작업 중 변경될 것으로 예상하는 파일

이렇게 해야 검토가 막연한 느낌이 아니라 전후 비교가 됩니다.

3. New Session 프리셋 선택하기

메인 툴바의 New Session 버튼을 누르면 현재 선택된 프리셋으로 세션이 시작됩니다. 다른 프리셋을 사용하려면 버튼의 펼침표를 누릅니다.

프리셋은 저장된 실행 구성입니다. 사용할 에이전트를 정하고, 모델·추론 강도·접근 수준·세션 화면을 미리 선택할 수 있습니다. Air는 내장 프리셋과 함께 컴퓨터에서 감지한 에이전트를 표시합니다. 선택한 에이전트가 설치돼 있지 않으면 플러그인이 설치를 안내할 수 있습니다.

첫 작업에는 Standard Access를 선택합니다. 현재 플러그인에서 Standard Access는 프로젝트 내부의 파일을 읽고 수정하며 명령어를 실행할 수 있게 합니다. 프로젝트 밖의 파일이나 네트워크에 접근하려면 승인이 필요합니다. Full Access는 네트워크 사용과 컴퓨터 어디서든 파일을 수정할 때 필요한 승인 절차를 없앱니다. 첫 세션의 기본값으로 삼기에는 적절하지 않습니다.

4. 첫 메시지를 보내고 에이전트 인증하기

인증은 에이전트가 실제로 필요로 하는 순간 진행됩니다. 짧은 첫 메시지를 입력하고 Enter를 누릅니다. Air가 해당 에이전트가 이미 컴퓨터에서 사용하는 자격 증명을 찾으면 세션이 계속됩니다. 찾지 못하면 Choose a sign-in method to continue가 표시됩니다.

사용할 수 있는 경로는 에이전트에 따라 다릅니다.

• 에이전트 로그인은 브라우저나 터미널에서 이어질 수 있습니다.
• 조건에 맞는 JetBrains AI 라이선스나 조직 워크스페이스가 크레딧을 제공할 수 있습니다.
• Add an AI provider를 누르면 서드파티 구독 또는 API 키를 설정하는 Tools | Air | Accounts가 열립니다.

Accounts에서 More Providers를 선택하고 필요한 자격 증명을 추가합니다. Test Connection으로 연결을 확인하고 OK를 눌러 저장한 뒤, 세션으로 돌아와 해당 공급자를 선택합니다.

작업 프롬프트에 비밀 정보를 붙여 넣지 마십시오. 자격 증명은 공급자 연결 절차에서 관리해야 합니다.

5. 작업에 꼭 필요한 컨텍스트만 추가하기

Air에서는 컨텍스트 추가 컨트롤을 이용해 파일, 커밋, 스킬을 첨부할 수 있습니다. @file:을 입력해 파일을, @folder:를 입력해 폴더를 지정할 수도 있습니다. 둘의 차이는 중요합니다. 관련 파일 하나를 첨부하는 것은 정비사에게 고장 난 부품을 건네는 일과 같지만, 저장소 전체를 첨부하는 것은 차고 안의 물건을 모두 작업대에 쏟아 놓는 것과 같습니다.

첫 실행에서는 구현 파일을 첨부하고 테스트 명령어를 명시합니다. 기존 패턴을 파악해야 할 때만 테스트 파일을 추가합니다.

6. 범위가 명확하고 증명 가능한 변경 요청하기

좋은 프롬프트에는 결함, 허용 범위, 검증 명령어가 들어갑니다. 예를 들면 다음과 같습니다.

@file:src/slug.js에서 반복 공백 처리 문제를 수정하십시오. 관련된 최소 범위의 테스트를 추가하거나 업데이트하고 node --test를 실행하십시오. 의존성을 변경하거나 관련 없는 파일을 건드리지 마십시오. 테스트 명령어를 실행할 수 없다면 중단하고 이유를 설명하십시오.

이 프롬프트에는 에이전트가 도달해야 할 결승선이 있습니다. “이 헬퍼를 개선해 주세요”에는 없습니다.

7. 세션은 지켜보되 진행 설명으로 결과를 평가하지 않기

에이전트는 진행 상황을 알리고 질문할 수 있습니다. 빠진 요구 사항에는 답하되, 이해한 작업만 승인하십시오. 예상하지 못한 네트워크 요청이나 프로젝트 밖의 파일 접근에는 특히 주의합니다.

진행 문구는 맥락을 파악하는 데 유용하지만 증거는 아닙니다. 증거는 결과물인 diff와 직접 다시 실행할 수 있는 테스트입니다.

8. Agent Sessions에서 변경 사항 검토하기

Agent Sessions를 열고 완료된 세션을 펼칩니다. 변경된 모든 파일의 diff를 확인하십시오. 현재 패키지에는 Show Diff, Generate summary..., Revert 작업이 포함돼 있습니다. JetBrains 퀵스타트에 따르면 수정된 파일은 유지하거나 편집하거나 커밋하거나 되돌릴 수 있습니다.

다음 순서로 검토합니다.

1. 범위: 예상한 파일만 바뀌었습니까?
2. 동작: 구현이 정확히 그 실패를 해결합니까?
3. 테스트 품질: 수정 코드가 없다면 새 테스트가 실패합니까?
4. 부작용: 구성, 의존성 또는 공개 인터페이스가 달라졌습니까?
5. 검증: 에이전트의 진행 설명과 별개로 직접 실행했을 때 테스트가 통과합니까?

diff가 거의 맞는다면 직접 고치거나, 다음 반복 작업을 위해 구체적인 피드백을 남깁니다. 변경 범위가 예상 밖이라면 되돌린 뒤 더 좁은 프롬프트로 다시 시작합니다. 그럴듯한 설명만 듣고 커밋해서는 안 됩니다.

비용을 따져 보면

Air가 바꾸는 것은 작업을 조율하는 비용 항목이지, 그 아래에서 쓰이는 지능의 비용이 아닙니다. 플러그인 소프트웨어 비용은 $0이지만, 연결된 에이전트는 기존 구독, API 잔액 또는 JetBrains AI 크레딧을 사용할 수 있습니다.

이미 에이전트 비용을 내는 팀이라면 이 차이가 중요합니다. 두 번째 관제 화면이 검토를 실제로 개선하는지 알기도 전에 좌석 비용부터 추가될 수 있기 때문입니다. 공개된 비교 기준으로 GitHub는 현재 Copilot Business를 사용자당 월 $19, Enterprise를 사용자당 월 $39에 제공합니다. Business 좌석 열 개면 추가 사용량을 제외하고도 월 $190입니다. Air는 Air 플러그인 비용을 더하지 않고 지원되는 에이전트를 연결할 수 있지만, IDE 라이선스·공급자 구독·API 사용량·사람의 검토 시간까지 없애 주지는 않습니다.

따라서 실무 예산에서 물어야 할 것은 명확합니다. 무료 로컬 검토 화면 하나가 기존 에이전트 비용을 더 쉽게 통제하고 검증하게 해주는가? 다른 구매나 표준화에 앞서 한 팀과 한 종류의 작업으로 검증하십시오.

누가 가장 큰 효과를 얻나: 여섯 가지 활용법

1. 이미 여러 에이전트에 비용을 내는 JetBrains 팀

어떤 작업에는 Codex를, 다른 작업에는 Claude를 쓰는 엔지니어링 팀이라면 동일한 IDE 환경에서 두 에이전트를 시작하고, 같은 프로젝트 컨텍스트를 첨부하며, 한곳에서 변경 파일을 검토할 수 있습니다. 기본적으로 토큰 비용이 싸지는 것이 핵심은 아닙니다. 이미 비용을 내는 구독을 두고 툴을 오가는 시간을 줄이는 동시에 일관된 검토 습관을 만들 수 있다는 점이 이점입니다.

2. 작고 테스트 가능한 결함을 처리하는 메인테이너

메인테이너는 실패하는 헬퍼를 첨부하고 회귀 문제 하나를 설명한 다음, 범위가 좁은 테스트를 요구하고 브랜치에 반영하기 전에 결과 diff를 검토할 수 있습니다. 진단은 분명하지만 기계적인 수정 작업 때문에 더 깊이 있는 업무가 밀릴 때 효과가 큽니다.

3. 낯선 고객 코드베이스에 들어가는 컨설턴트

컨설턴트는 IDE의 코드 탐색 기능으로 심볼을 확인하고, 관련 파일만 첨부해 에이전트에게 범위가 명확한 변경을 요청할 수 있습니다. Standard Access를 적용한 일회용 브랜치 안에서 작업하면 익숙하지 않은 저장소 규칙 때문에 수정 범위가 걷잡을 수 없이 커질 가능성을 낮출 수 있습니다. 에이전트가 명시되지 않은 고객 규칙까지 안다고 가장하지 않으면서 초기 파악 속도를 높이는 것이 이점입니다.

4. 재현 가능한 버그를 회귀 테스트로 바꾸는 QA 엔지니어

버그를 재현할 수 있는 QA 엔지니어는 관련 구현 파일과 테스트 영역을 첨부하고, 가장 작은 회귀 테스트를 요청한 뒤 그 테스트가 실제 실패를 정확히 포착하는지 살펴볼 수 있습니다. 재현 단계에서 검토 가능한 엔지니어링 결과물까지 넘기는 시간이 짧아집니다.

5. 구체적인 diff로 코드 리뷰를 가르치는 시니어 개발자

시니어 개발자는 에이전트가 작은 구현을 제안하게 한 다음, 익숙한 IDE에서 주니어 팀원과 함께 범위·가정·테스트 설계·되돌리기 결정을 살펴볼 수 있습니다. 결과물은 코드에 그치지 않습니다. 실제 변경 세트로 진행하는 눈에 보이는 리뷰 훈련이 됩니다.

6. 같은 작업으로 에이전트를 비교하는 플랫폼 팀

플랫폼 팀은 똑같이 범위가 제한된 작업을 서로 다른 프리셋으로 실행하고 변경된 파일, 테스트 동작, 승인, 검토에 든 노력을 비교할 수 있습니다. 평가 단위가 채팅 답변이 아니라 같은 저장소에서 검증된 변경이므로 더 유용한 비교 결과를 얻습니다.

이 흐름을 바탕으로 만들 만한 제품 두 가지

1. 에이전트 변경을 위한 리뷰 증거 사이드카

더 유망한 기회는 이것입니다. 에이전트 세션을 검토 패킷으로 바꾸는 작은 보조 도구를 만듭니다. 작업, 첨부된 컨텍스트, 변경 파일, 테스트 명령어, 테스트 결과, 사람의 결정, 최종 커밋 참조를 한데 모으는 제품입니다. 어떤 에이전트가 코드를 만들었든 그 위에 깔끔한 기록을 남길 수 있다면 엔지니어링 관리자와 규제 대상 팀은 비용을 지불할 것입니다.

수요도 충분히 구체적입니다. ai powered code review platform은 미국에서 월 약 1,900회의 검색량을 보이며 상업적 의도가 있습니다. GitHub의 Business $19, Enterprise $39라는 좌석 가격도 팀이 이미 코딩 지원과 거버넌스에 예산을 편성하고 있음을 보여줍니다.

판매 가능한 최소 버전은 에이전트를 직접 제어할 필요가 없습니다. diff와 테스트 출력을 받아 검토자 체크리스트 작성을 요구하고, 서명된 Markdown 또는 JSON 기록을 내보내면 됩니다. 단, 플랫폼 위험은 있습니다. Air는 알파 제품이고 인터페이스가 매주 바뀔 수 있으며, JetBrains가 더 풍부한 증거 또는 감사 기능을 직접 추가할 수도 있습니다. 단일 IDE 안의 얇은 버튼이 아니라 에이전트를 가로지르는 정책과 오래 보존되는 보고 기능이 해자가 돼야 합니다.

2. 저장소 맞춤형 에이전트 설정 어드바이저

저장소의 언어, 테스트 명령어, 민감한 경로, 기여 규칙을 분석한 뒤 안전한 첫 작업 템플릿과 프리셋 설정을 추천하는 온보딩 도구를 만듭니다. 개발자마다 설정 작업을 반복하고 있는 혼합형 저장소 환경에서 에이전트를 도입하는 팀이 고객이 될 수 있습니다.

넓은 시장의 수요는 큽니다. ai coding assistant는 미국에서 월 약 18,100회, ai powered coding agent는 약 8,100회 검색됩니다. MVP는 저장소 설문, 자동 생성된 설정 안내, 범위가 명확한 시작용 프롬프트, 스모크 테스트 체크리스트로 구성할 수 있습니다. 초기에는 IDE와 깊게 통합할 필요도 없습니다.

문제는 방어력입니다. JetBrains, 에이전트 공급자 또는 저장소 템플릿이 일반적인 설정 조언을 흡수할 수 있습니다. 살아남으려면 조직별 정책 검사 기능과 추천 설정이 실패하거나 범위를 벗어난 변경을 줄였다는 근거가 필요합니다.

한계와 솔직한 평가

이미 JetBrains IDE를 선호하고 IDE에 자연스럽게 통합된 검토 기능을 유지하면서 에이전트 선택권을 얻고 싶다면 Air가 가장 유용합니다. 검증할 수 없는 위험한 변경을 대신 맡길 이유가 되는 도구는 아닙니다.

현재는 세 가지 제약을 기억해야 합니다.

• 알파 제품입니다. 대략 매주 이어지는 릴리스 주기에 따라 레이블과 동작이 바뀔 수 있습니다.
• 플러그인은 무료지만 작업은 무료가 아닙니다. 에이전트 인증, 구독, API 사용, IDE 라이선스, 사람의 검토에는 각각 비용이 듭니다.
• 처음에는 로컬 작업이 가장 안정적입니다. IDE 페이지에서도 클라우드 인계가 아직 출시 예정이라고 설명하므로, 노트북을 덮은 뒤에도 작업이 계속되는 흐름을 첫 워크플로의 전제로 삼지 마십시오.

Standard Access도 읽기 전용은 아닙니다. 프로젝트 안에서 파일 수정과 명령어 실행을 허용합니다. 일회용 브랜치나 worktree를 사용하고, diff를 살펴본 뒤 테스트를 직접 다시 실행하십시오.

결론은 단순합니다. JetBrains가 이미 일상적인 작업 공간이라면 작은 변경 하나에 Air를 시험해 볼 만합니다. 다만 롤백 계획, 공급자 정책, 검토 증거 없이 민감한 저장소의 의무 경로로 정하기에는 아직 이릅니다.

다음 업무일에 바로 해볼 일

명령어 하나로 테스트할 수 있는 버그 하나를 고릅니다. 일회용 브랜치에 올리고, 개발자 컴퓨터 한 대에 호환되는 Air Alpha 빌드를 설치합니다. Standard Access를 선택하고 관련 파일 하나를 첨부한 뒤, 가장 작은 수정과 회귀 테스트를 요청합니다. diff의 범위가 좁고 테스트를 직접 실행했을 때 통과하는 경우에만 변경을 유지하십시오. 이 한 번의 흐름에서 얻는 정보가 에이전트 데모를 일주일 동안 보는 것보다 많습니다.

JetBrains Air는 어떤 일을 합니까?

JetBrains Air는 JetBrains IDE 안팎에서 코딩 에이전트와 에이전트가 사용하는 컨텍스트, 세션, 검토 과정을 조율합니다. 로컬 IDE 플러그인에서는 에이전트를 고르고 프로젝트 컨텍스트와 함께 작업을 보낸 다음, Agent Sessions에서 결과 변경 사항을 확인합니다.

JetBrains Air와 Claude Code의 핵심 차이는 무엇입니까?

Claude Code는 하나의 코딩 에이전트입니다. Air는 여러 에이전트를 제어하고 검토하는 화면입니다. 사용 가능한 연동과 인증 방식에 따라 Claude뿐 아니라 Codex, Junie, GitHub Copilot, Gemini, OpenCode, ACP 호환 에이전트도 실행할 수 있습니다.

에이전트 코딩에 가장 좋은 IDE는 무엇입니까?

모두에게 맞는 하나의 정답은 없습니다. 팀이 이미 JetBrains의 탐색, 검사, diff 도구에 의존하고 있다면 Air가 매력적입니다. 가장 좋은 선택은 에이전트 작업의 범위를 제한하고, 결과를 검토하고, 테스트하고, 안정적으로 되돌릴 수 있는 환경입니다.

JetBrains는 무료로 사용할 수 있습니까?

Air Alpha 플러그인은 무료입니다. JetBrains IDE와 Air 뒤에서 작동하는 에이전트에는 별도의 라이선스, 구독 또는 API 비용이 들 수 있습니다.

저장소와 리뷰 규칙에 맞춘 안전한 에이전트 워크플로가 필요하다면 AI agent development를 확인해 보십시오.