JetBrains Air에 Copilot 지원: 로컬·클라우드와 구독 비용을 어떻게 고를까요?

JetBrains Air에서 Copilot을 고를 수 있게 됐지만, 기존 구독 하나로 모든 실행 환경과 비용 관리가 해결되는 것은 아닙니다. 로컬에서 작업할지, Air Teams의 클라우드에 맡길지부터 나누고, 그다음 구독과 조직의 관리 조건을 확인해 보세요. 이번 소식에서 실제로 달라진 선택지가 훨씬 또렷해집니다.

GitHub는 2026년 11월 3일 Air 지원을 발표했습니다. ACP라는 에이전트 연결 규약을 이용해 IDE 안이나 클라우드에서 코딩 작업을 맡기고 결과를 검토할 수 있다는 내용이에요. 기존 JetBrains용 Copilot 플러그인과 함께 사용할 수 있다는 안내도 있습니다. 따라서 플러그인을 당장 지우고 새 도구로 갈아타야 한다는 발표로 읽을 필요는 없습니다. GitHub의 Air 지원 공지를 기준으로 살펴봤습니다.

먼저 바꿀 것은 도구보다 작업을 맡기는 방식이에요

선택의 출발점은 ‘어느 제품이 더 똑똑한가’보다 지금 어떤 일을 넘기려는가입니다. 코드를 옆에서 보며 작은 수정을 주고받고 싶은지, 다른 일을 하는 동안 분리된 환경에서 작업을 진행하게 하고 싶은지를 적어 보세요. 같은 Copilot이라는 이름을 사용해도 내가 기대하는 협업 장면은 다를 수 있습니다.

이 글에서는 세 가지 기준으로 비교할 것을 제안합니다. 첫째는 작업 환경, 둘째는 비용을 확인할 책임, 셋째는 결과를 받아들이는 절차예요. 하나가 맞는다고 나머지도 자동으로 맞는 것으로 처리하지 않는 방법입니다. 이 기준은 실제 도입 효과를 측정한 점수표가 아니라, 발표를 자신의 상황에 연결하기 위해 만든 질문입니다.

선택 기준	먼저 적어 볼 질문
작업 환경	내가 보고 있는 작업 공간에서 함께 수정할까요, 별도 환경의 결과를 받아 검토할까요?
비용 책임	사용할 구독과 사용량을 누가 확인하고, 어느 곳에서 비용을 검토하나요?
완료 조건	파일 변경, 테스트, 사람의 검토 중 어디까지 확인해야 받아들일 수 있나요?

예를 들어 화면에 보이는 문구 몇 개를 바꾸려는 사람과, 낯선 저장소의 테스트를 정리하려는 사람은 같은 기능 목록을 보고도 필요한 질문이 달라질 수 있어요. 앞의 사람은 현재 편집 흐름을 얼마나 자연스럽게 유지하는지, 뒤의 사람은 작업을 어떻게 재현하고 결과를 설명받을지를 먼저 생각할 수 있습니다. 어느 쪽이 무조건 낫다는 결론은 이 예시에서 나오지 않습니다.

로컬과 클라우드의 이용 조건은 나눠 읽어야 해요

공식 공지는 로컬 작업과 클라우드 작업의 시작 조건을 따로 설명합니다. 로컬에서는 JetBrains IDE의 Air에서 Copilot을 선택해 계정을 연결하는 흐름을 안내합니다. 클라우드 작업에는 Air Teams를 사용할 수 있는 비즈니스 조직의 JetBrains 계정, Copilot 구독, Air 관리자의 Copilot 활성화가 필요하다고 명시합니다. 이 조건을 개인 계정이나 기존 IDE 플러그인 이용 경험만으로 충족했다고 판단하면 곤란하겠죠.

현재 자신의 상태를 확인할 때는 ‘Copilot을 쓰고 있다’는 문장 하나를 조금 더 풀어 보세요. 사용 중인 IDE에서 어떤 경로로 쓰는지, 해당 조직에 속해 있는지, 누가 Air를 관리하는지를 나누어 적는 방식입니다. 확인하지 않은 항목은 담당자에게 물어볼 질문으로 남겨도 됩니다. 모르는 조건을 채우기 위해 새 구독부터 결제할 필요는 없어요.

비교할 대상을 작게 잡는 것도 도움이 됩니다. 기존 플러그인에서 하던 구체적인 작업 한 가지를 적고, Air를 쓴다면 어떤 점을 더 확인하려는지 옆에 써 보세요. ‘전체 개발을 자동화한다’보다 ‘별도 작업의 변경 내용을 검토하기 쉽도록 받을 수 있는가’처럼 목표가 분명한 문장이 판단에 쓰기 좋겠습니다.

클라우드라는 말에서 확인할 것은 실행 장소와 경계입니다

실행 환경은 JetBrains의 클라우드 에이전트 격리 설명에서 더 자세히 읽었습니다. Air는 작업마다 새 가상 머신을 시작하고 그 안의 Docker 컨테이너에서 에이전트를 실행한다고 설명합니다. 연결은 프록시를 거치며, 그 가상 머신을 다음 작업에 재사용하지 않는다는 내용입니다.

같은 문서는 로컬 작업 공간과 Git worktree도 구분합니다. worktree는 파일 변경을 별도 사본에 모으는 데 도움이 되지만, 그 자체만으로 에이전트가 해당 폴더 밖에 접근하지 못하도록 만드는 완전한 격리는 아니라는 설명이에요. ‘파일을 나눴다’와 ‘접근할 수 있는 자원을 제한했다’를 다른 질문으로 읽으면 이해하기 쉽습니다.

팀의 검토 메모에는 세 항목을 따로 남겨 보세요. 가져갈 저장소와 기준 브랜치, 작업에 필요한 외부 자원, 결과를 검토할 사람이 그것입니다. 이 메모는 보안 승인을 대신하지 않습니다. 다만 격리된 환경이라는 제품 설명과 우리 조직에서 어떤 데이터를 어디까지 사용할 것인지에 대한 결정을 혼동하지 않도록 돕는 정리입니다.

가상의 사례로, 문서만 수정하는 작업과 사내 패키지에 의존하는 테스트 작업을 비교해 볼게요. 두 작업을 같은 체크리스트로 시작하더라도 두 번째에는 패키지를 얻는 경로와 접근 조건에 관한 질문이 더 남을 수 있습니다. 여기서 접근 권한을 넓혀 해결하자는 뜻은 아닙니다. 필요한 조건이 아직 정해지지 않았다는 사실을 작업 의뢰서에 남겨 두자는 제안이에요.

구독 선택과 사용량 확인을 한 화면으로 가정하지 마세요

Air의 일반 제품 소개에는 조직의 비용 제어와 분석 기능도 나옵니다. 반면 이번 Copilot 연결 공지는 Copilot에 적용되는 예외를 별도로 명시합니다. 제품 전체를 소개하는 화면과 특정 외부 에이전트의 지원 범위를 같이 읽어야 하는 대목이에요.

그래서 구매 담당자에게는 ‘Air에 비용 관리가 있나요?’라는 질문 다음에 ‘우리가 선택한 Copilot 경로도 같은 관리 범위에 들어가나요?’를 덧붙이는 방식을 제안합니다. 일반 소개의 장점을 특정 연결에 그대로 복사하지 않고, 실제 사용할 경로의 제한을 확인하려는 질문입니다.

비용에 관해서는 발표의 제한 사항이 중요합니다. Air의 클라우드 Copilot 작업은 JetBrains AI 크레딧이 아니라 Copilot 플랜을 이용한다고 안내합니다. 개별 작업마다 개인 플랜과 조직 플랜 중 어느 것을 사용할지 고를 수 없고, Air의 관리·분석 기능에 Copilot 사용량이 포함되지 않으며, Air 안에서 Copilot 지출 한도를 설정할 수도 없다고 명시합니다. 연결에 성공했다는 사실을 원하는 청구 방식이 확정됐다는 뜻으로 바꾸지 마세요.

구독이나 크레딧 이용 가능 여부는 클라우드 환경이 시작될 때 확인될 수 있고, 사용할 수 없으면 세션에 오류가 표시된다는 설명도 있습니다. 그러니 ‘계정을 연결할 수 있는가’와 ‘이 작업을 실제로 시작할 자격과 사용량이 있는가’를 따로 적어 두는 편이 좋겠습니다. 이 글은 가격표나 무료 사용량을 임의로 붙이지 않습니다.

직접 만든 비용 검토표에는 금액을 미리 쓰기보다 확인 경로를 적어 보세요. 누구의 구독을 쓰는지 확인할 담당자, 사용량을 살펴볼 위치, 내부 승인에 필요한 자료를 채우는 겁니다. 제품 화면에서 볼 수 없다고 명시된 항목을 가상의 대시보드나 예상 사용량으로 채워 넣으면 실제 구매 판단에 도움이 되지 않겠죠.

도입 전에 남길 항목	확인할 내용
이용 주체	개인과 조직 중 어떤 계약·계정 조건을 검토 중인지, 아직 확인하지 못한 항목은 무엇인지.
사용량 관찰	누가 어느 화면이나 공식 자료에서 확인할지, Air에서 보이지 않는 항목은 무엇인지.
시범 작업	범위를 제한한 어떤 작업을 검토할지, 중단과 후속 검토는 누가 판단할지.
평가 기록	실제 실행 여부, 확인한 결과, 사용량 자료를 얻지 못한 부분을 각각 기록하기.

작은 작업 하나로 비교한다면 이런 의뢰서를 써 보세요

아래는 실제 운영 사례가 아닌 자체 작성 예시입니다. ‘도움말 문서의 설치 안내와 현재 파일 구성이 서로 맞는지 확인하고, 차이가 있으면 수정안을 제안해 주세요. 사용자 데이터와 인증 설정은 다루지 않습니다. 완료 보고에는 읽은 파일과 바꾸려는 문장, 아직 확인하지 못한 부분을 적어 주세요.’ 작업의 범위와 받아 볼 결과를 함께 적는 형식이에요.

이 예시를 자신의 상황에 맞게 쓰려면 세 부분을 바꾸면 됩니다. 먼저 검토할 대상과 기준 버전을 정합니다. 다음으로 수정할 수 있는 범위와 확인이 필요한 경계를 적습니다. 끝으로 결과를 받아들일 사람이 읽어야 할 근거를 정하세요. 이렇게 만든 의뢰서는 제품을 바꾸어 비교하더라도 같은 질문을 유지하기 위한 자료로 사용할 수 있습니다.

비교 기록에는 잘된 부분뿐 아니라 손이 더 간 부분도 남겨 보세요. 예를 들어 결과 설명을 이해하기 어려웠는지, 필요한 자료가 없어 시작하지 못했는지, 변경안을 검토하는 데 추가 설명이 필요했는지를 적는 겁니다. 실제로 재지 않은 시간을 절감률로 만들거나, 한 작업의 결과를 팀 전체 생산성으로 확대하지는 않습니다.

결과가 파일 변경이라면 변경 내용을 읽어 볼 사람이 누구인지도 의뢰 전에 정해 두세요. 실행 환경을 선택하는 일과 변경을 최종 반영하는 일은 서로 다른 판단입니다. 테스트가 있는 작업은 어떤 검사를 기대하는지, 검사가 수행되지 않았다면 어떤 상태로 전달받을지도 적을 수 있습니다. ‘완료’라는 한 단어에 확인하지 않은 사실을 넣지 않으려는 방식입니다.

조직에서 여러 사람이 비교한다면 같은 작업 설명을 공유하되, 각자 확인한 환경은 따로 기록해 보세요. 개인 계정에서 본 결과와 조직 계정의 설정을 한 줄로 합치지 않는 겁니다. 확인한 날짜와 이용 경로를 남기면 나중에 조건이 달라졌을 때 무엇부터 다시 봐야 할지 찾기 쉽겠습니다.

자주 묻는 질문

기존 Copilot 플러그인을 반드시 교체해야 하나요? 공지는 함께 사용할 수 있다고 설명합니다. 기존에 하던 작업과 새로 맡기고 싶은 작업을 먼저 나누어 보세요. 특정 도구를 전부 교체해야 한다는 결론을 이번 발표에서 끌어내지는 않습니다.

Air에서 사용량이 보이지 않으면 비용이 없다는 뜻인가요? 그런 의미가 아닙니다. 발표가 밝힌 사용량 표시 범위와 플랜 이용 조건을 구분해야 합니다. 실제 비용은 자신의 계약과 공식 사용량 자료를 확인할 담당자에게 연결하세요.

클라우드에서 실행하면 결과를 바로 반영해도 되나요? 이 글은 그런 승인을 제공하지 않습니다. 환경의 격리 설명을 읽는 일과 자신의 코드 변경을 검토하는 일을 나누어 두세요. 실제 사용 시험을 했다면 확인한 내용과 남은 질문을 함께 기록하는 방식이 좋겠습니다.

이번 글의 확인 범위

사실 기준일은 2026년 11월 4일입니다. GitHub의 11월 3일 발표와 JetBrains의 격리 설명을 읽어 이용 조건·실행 환경·비용 관리의 경계를 대조했습니다. 실제 계정 연결, 구독 구매, 작업 실행이나 비용 측정은 하지 않았습니다. 11월 5일의 개별 계정 상태도 확정하지 않습니다.

오늘 남길 결론은 하나의 제품 점수보다 나에게 필요한 질문 목록이면 충분합니다. 어떤 작업을 어디에 맡길지, 이용 조건은 누가 확인할지, 어떤 근거를 보고 결과를 받아들일지를 한 장에 적어 보세요. 도입 여부는 그 질문에 실제 답을 얻은 뒤 선택할 수 있습니다.

조직 구독의 좌석 조건을 함께 살펴보고 있다면 GitHub Enterprise의 Copilot 포함 조건을 정리한 글도 참고할 수 있습니다. 좌석 이용 조건과 이번 Air 연결의 실행·관리 조건은 각각 확인하세요.

직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.