JetBrains Copilot에 Claude가 들어왔다: 에이전트 IDE 시대의 운영 계약

JetBrains IDE를 쓰는 팀이라면 이번 GitHub Copilot 업데이트를 단순한 플러그인 릴리스로 넘기기 어렵다. 2026년 6월 22일 GitHub Changelog는 JetBrains IDE 안에서 조직/엔터프라이즈 custom agents, 실행 중 메시지 queue/steer, Agent Debug 로그 요약, Claude agent provider public preview, model picker 개선, per-turn AI credits 표시, Cloud agent GA를 함께 공개했다. 각각은 작아 보이지만, 합치면 “에이전트가 IDE 안에서 오래 실행되고, 조직 정책과 비용 표시와 디버그 로그를 남기는 개발 도구”로 이동했다는 신호다.

핵심은 Claude가 들어왔다는 사실 하나가 아니다. GitHub Copilot for JetBrains가 Copilot CLI를 기본 agent harness로 옮기는 흐름과 맞물리면서, JetBrains 사용자는 이제 IDE 플러그인, 로컬 CLI 세션, GitHub 조직 정책, 외부 agent provider, credits 소비, 디버그 로그를 하나의 운영면으로 봐야 한다. AI 코딩 도구를 개인 생산성 도구로만 쓰던 단계에서는 “잘 답하는 모델”이 중요했다. 팀 단위에서는 “누가 어떤 에이전트를 쓸 수 있고, 어떤 권한으로 파일과 명령을 건드리며, 문제가 생겼을 때 무엇을 추적할 수 있는가”가 더 중요해진다.

무슨 일이 있었나

GitHub의 6월 22일 Changelog는 JetBrains IDE용 Copilot에 몇 가지 운영형 기능을 추가했다고 설명한다. 관리자는 GitHub 조직이나 엔터프라이즈 레벨에서 정의한 custom agents를 JetBrains IDE의 Copilot Chat agent picker에 노출할 수 있다. 사용자는 실행 중인 Copilot CLI 세션에 메시지를 queue하거나, 현재 tool execution이 끝난 뒤 즉시 방향을 바꾸도록 steer하거나, 현재 turn을 중단하고 새 메시지를 보낼 수 있다. Agent Debug panel에는 세션 활동을 요약해서 보는 화면이 추가됐고, Cloud agent는 더 이상 Editor Preview feature flag 뒤에 있지 않은 GA 상태가 됐다.

가장 눈에 띄는 변화는 Claude as agent provider public preview다. 사용자는 로컬 머신에 Claude Code CLI를 설치하고 JetBrains 설정에서 CLI 경로를 지정한 뒤, Copilot Chat의 agent picker에서 Claude를 선택해 세션을 시작할 수 있다. 다만 GitHub는 현재 Claude agent가 bypass permissions mode로 실행되어 파일 편집과 tool call이 자동 승인된다고 명시했다. Copilot Business/Enterprise에서는 관리자가 Editor preview features policy를 켜야 사용할 수 있다는 조건도 붙어 있다.

며칠 전 Microsoft for Java Developers 블로그는 Copilot for JetBrains가 Copilot CLI를 기본 agent harness로 옮긴다고 설명했다. 기존 JetBrains local harness를 별도로 유지하면 기능과 모델 parity가 늦어질 수 있으므로, IDE는 세션을 시작하고 모니터링하고 steer하고, 실제 장기 실행 agent session은 Copilot CLI harness가 백그라운드에서 맡는 구조로 가겠다는 방향이다. 이 문맥에서 이번 업데이트는 “JetBrains 플러그인도 agent runtime 표준화 흐름에 들어왔다”는 신호로 읽는 편이 정확하다.

왜 개발팀에 중요한가

첫째, IDE 선택과 agent 선택이 분리된다. 과거에는 VS Code를 쓰면 특정 agent 경험이 빠르고, JetBrains를 쓰면 기능 도착이 늦는 식의 표면 차이가 컸다. Copilot CLI harness로 수렴하면 JetBrains 사용자는 IDE를 바꾸지 않고도 조직 agents, Cloud agent, CLI steering, provider 선택 같은 기능을 더 빠르게 받을 가능성이 커진다. 이는 Java, Kotlin, Android, Python, Go 백엔드 팀처럼 JetBrains 의존도가 높은 조직에 실질적이다.

둘째, agent provider 선택이 개인 취향이 아니라 정책 문제가 된다. GitHub Docs의 Copilot 모델 문서는 모델 가용성이 plan과 client에 따라 달라지고, 모델이 교체되거나 업데이트될 수 있다고 설명한다. VS Code의 third-party agents 문서도 Claude나 Codex 같은 provider가 각자의 harness와 강점을 가지지만, Copilot 구독과 조직 설정을 통해 통합 관리될 수 있다고 설명한다. JetBrains에 Claude provider가 들어온다는 것은 팀이 “어떤 provider를 어떤 업무에 허용할지”를 문서화해야 한다는 뜻이다.

셋째, 장기 실행 agent를 다루는 UX가 바뀐다. GitHub Docs는 Copilot CLI에서 agent가 생각하는 동안 추가 입력을 보내면 steering으로 처리되어 현재 작업 맥락 안에서 반영된다고 설명한다. JetBrains 업데이트는 여기에 queue, steer, stop-and-send라는 명시적 선택지를 더했다. 긴 리팩터링이나 테스트 수정에서 agent가 잘못된 방향으로 가는 것을 기다리거나 취소하는 대신, 사람이 중간에 운영자처럼 개입하는 패턴이 표준화되고 있다.

커뮤니티 신호

커뮤니티 반응은 “어떤 모델이 더 좋은가”보다 “JetBrains에서 Copilot CLI, BYOK, MCP, debug panel, custom agent가 실제로 얼마나 안정적으로 붙는가”에 가깝다. r/JetBrains의 6월 업데이트 글에서는 Copilot CLI session용 agent picker, MCP configuration, BYOK, agent debug panel, unified sessions view 같은 항목이 언급됐다. 이 글은 공식 사실의 근거로 쓰기보다, JetBrains 사용자들이 모델 성능만큼이나 세션 지속성, billing UX, debugability, IDE freeze 같은 운영 경험에 민감하다는 신호로 보는 것이 적절하다.

개발 현장에서 이 신호는 중요하다. AI agent rollout은 “선호 모델을 켜는 일”이 아니라 IDE 성능, terminal 권한, 로그 보존, PR 품질, 비용 가시성, 조직 policy까지 얽힌 변경이다. JetBrains 사용자가 많은 팀일수록 파일 감시, 대형 monorepo indexing, Gradle/Maven 작업, Android emulator, database tool window 등 IDE 고유 작업과 agent CLI 실행이 충돌하지 않는지 검증해야 한다.

운영 영향: 팀이 새로 정해야 할 계약

특히 bypass permissions mode는 파일 편집과 tool call을 자동 승인한다는 점에서, production branch나 민감한 monorepo에 바로 적용하기 어렵다. 격리된 작업tree, 테스트용 브랜치, 제한된 권한의 dev container, 사내 package registry 접근 정책을 먼저 확인해야 한다. “편하다”와 “운영 가능하다”는 다르다.

이번 주 JetBrains 팀 체크리스트

• Pilot 범위를 정한다: 한두 개 저장소, 한 팀, 한 sprint로 제한하고 Cloud agent와 Claude provider를 분리해 평가한다.

• 권한 정책을 먼저 쓴다: bypass permissions mode가 허용되는 작업과 금지되는 작업을 문서화한다.

• CLI 환경을 고정한다: Copilot CLI, Claude Code CLI, shell, Node/Python/JDK 버전, proxy 설정을 bootstrap 스크립트로 재현 가능하게 만든다.

• 로그와 비용을 본다: Agent Debug summary와 per-turn credits를 rollout 회고에 포함한다.

• 성공 기준을 정한다: “잘 답했다”가 아니라 PR diff 품질, 테스트 통과율, 리뷰 수정 횟수, rollback 여부를 본다.

개발자가 지금 할 수 있는 일

개인 개발자라면 먼저 Copilot plugin을 최신 버전으로 올리고, Copilot CLI session이 JetBrains에서 어떻게 시작되고 종료되는지 확인하자. 긴 작업을 일부러 실행해 queue, steer, stop-and-send 흐름을 테스트하면 실제 업무 중 agent를 어떻게 제어해야 하는지 감이 온다. Claude provider preview를 켠다면, 소규모 샘플 저장소에서 파일 편집과 tool call이 어떤 식으로 승인 없이 실행되는지 먼저 관찰해야 한다.

팀 리드라면 바로 전체 rollout을 하기보다 “agent 운영 계약”을 만들어야 한다. 예를 들어 리팩터링, 테스트 보강, 문서 생성, PR 리뷰, 마이그레이션 초안처럼 agent에게 맡길 수 있는 작업 유형을 분류하고, 각 유형마다 허용 provider, 필요한 승인, 로그 보존, 비용 한도를 정한다. JetBrains 팀은 IDE 표면이 익숙하다는 이유로 위험이 낮다고 착각하기 쉽지만, 실제 실행은 CLI harness와 외부 provider가 결합된 구조다.

반론과 주의할 점

아직 public preview인 기능을 운영 표준으로 삼는 것은 이르다. Claude provider는 설정 절차와 권한 모델이 앞으로 바뀔 수 있고, GitHub 문서도 모델 availability가 plan과 client에 따라 달라질 수 있다고 명시한다. 또한 여러 provider가 한 IDE 안에 들어오면 도구 선택은 쉬워지지만, 결과 비교와 책임 경계는 더 복잡해진다. 같은 issue를 Copilot, Claude, Cloud agent가 각각 다른 방식으로 고쳤을 때 어떤 기준으로 merge할지 정하지 않으면 오히려 리뷰 부담이 늘 수 있다.

그래도 방향성은 분명하다. AI 코딩 도구는 autocomplete에서 chat으로, chat에서 장기 실행 agent session으로, 이제는 조직 정책과 provider marketplace와 비용 관측을 갖춘 운영 도구로 이동하고 있다. JetBrains 업데이트는 그 변화가 VS Code 사용자만의 이야기가 아니라는 점을 보여준다. IDE는 그대로 두어도 된다. 대신 agent가 일하는 방식은 이제 팀의 engineering governance 안으로 들어와야 한다.

출처

• GitHub Changelog: New features and Claude as agent provider preview in JetBrains IDEs
• Microsoft for Java Developers: Copilot for JetBrains is moving to Copilot CLI as the default agent harness
• GitHub Docs: Steering agents in GitHub Copilot CLI
• GitHub Docs: Supported AI models in GitHub Copilot
• VS Code Docs: Third-party agents in Visual Studio Code
• Reddit r/JetBrains: GitHub Copilot for JetBrains - June Updates