JetBrains AI
Supercharge your tools with AI-powered features inside many JetBrains products
JetBrains의 2026년 방향성: JetBrains IDE 내 AI와 기존 워크플로
코드를 작성하는 두 가지 유효한 방식. 그 모든 게 가능한 하나의 공간.
AI 뉴스에 피로감을 느끼는 분들을 위한 요약:
오늘날 개발자는 두 가지 방식으로 코드를 작성합니다.
- 기존 방식: 직접 입력하고, 리팩터링하며, 디버그하여 코드의 의도를 한줄 한줄 완성합니다.
- 새로운 방식: AI와 협업하여 자동 완성을 사용하거나 전체 작업의 초안을 작성하는 에이전트를 활용합니다.
두 방식 간 우열은 없습니다.
따라서 JetBrains는 두 방식을 JetBrains IDE 내에 자연스럽게 공존시키는 것을 목표로 합니다. 실제로 이러한 공존은 다음을 의미합니다.
- 사용자가 직접 코드를 작성할 때 IDE는 코드 작성을 중심으로 실행되고 AI는 핵심 코딩 경험을 방해하지 않아야 합니다.
- AI로 코드를 생성하거나 에이전트에 작업을 위임하려면 IDE는 UX와 기능 측면에서 자연스럽고 강력한 경험을 제공해야 합니다.
어느 쪽을 택하든 변하지 않는 한 가지 사실은 최종 코드에 대한 책임은 항상 개발자에게 있다는 것입니다. 그리고 그 코드를 읽고 이해하며 소유하는 작업은 여전히 IDE 중심으로 이루어집니다.
과장 없이 보는 'IDE 내 AI'의 의미
JetBrains는 IDE 내 AI를 하나의 '공식' 작업 방식으로 국한하지 않으려 합니다. 시장은 빠르게 진화하고 있으며, 개발자 또한 하나의 방식으로 묶을 수 없을 만큼 다양합니다.
당사에서 말하는 'JetBrains IDE 내 AI'란 에이전틱 부가 가치, 즉 필요할 때마다 활용 가능한 UX 및 기능을 의미합니다.
- AI Chat(AI 채팅) 도구 창에서는 채팅 중심 방식으로 작업합니다.
- IDE 터미널에서는 기존 CLI 워크플로를 그대로 활용할 수 있습니다.
- 에이전틱 시스템을 위해 설계된 새로운 옵트인 모드에서는 에이전트를 실행하고 몇 시간 동안 작업을 맡길 수 있습니다.
즉, 하나의 IDE 안에서 AI를 활용해 일을 끝내는 여러 가지 방식이 공존합니다. 사용자가 선택하고, 팀이 다듬으며, 실제 개발 현장의 기대와 기준 안에서 작동하는 방식입니다.
AI 전략: 벤더 종속성 방지 및 워크플로 호환성 유지
한 가지 분명한 사실은 현재 '최고'로 평가되는 모델이나 공급자, 에이전트가 영원히 최고의 자리를 지키지는 못하며, 당장 다음 달에도 순위가 바뀔 수 있다는 것입니다.
이런 이유로 특정 벤더의 로드맵에 의존하지 않는 IDE 경험을 의도적으로 구축하고 있습니다.
실제로 이는 AI 채팅 환경에서 공급자의 정책과 사용자의 요구 사항에 따른 다양한 연결 방식을 지원하는 것으로 이어집니다.
- JetBrains AI 관리형 설정(JetBrains AI 구독 사용 시)
- BYOK: 자체 API 키 사용
- OAuth 로그인: 지원되는 공급자 계정용(공급자가 지원하는 경우)
- ACP 에이전트: 표준 프로토콜을 통해 외부 코딩 에이전트 연결
주의할 사항은 OAuth가 항상 사용 가능한 인증 방식은 아니라는 것입니다. 에이전트 공급자가 OAuth를 지원하지 않거나 IDE에서 사용할 수 있는 방식으로 제공하지 않는 경우, 이를 임의로 구현할 수 없습니다.
에이전트 클라이언트 프로토콜(ACP): '자체 에이전트 사용'
ACP는 표준 인터페이스를 통해 외부 코딩 에이전트를 JetBrains IDE에 연결할 수 있도록 하며, 에이전트별 맞춤형 통합이 필요하지 않습니다. 에이전트는 엄선된 레지스트리에서 설치하거나 수동으로 구성할 수 있으며, 설치된 에이전트는 AI 채팅 내부에 표시됩니다.
사용자 요청이 많았던 대표적인 예는 Cursor 에이전트입니다. Cursor는 이미 ACP를 통해 JetBrains IDE 내에서 AI 에이전트로 제공되므로, 에이전트 선택기에서 선택해 해당 에이전틱 워크플로를 IDE 내에서 활용할 수 있습니다.
JetBrains가 기대하는 모습은 다음과 같습니다.
- 사용자는 자신의 워크플로나 팀에 적합한 에이전트를 선택합니다.
- 기존에 사용하던 IDE 환경을 그대로 유지합니다.
- 기존 IDE 중심 워크플로는 '에이전트 모드'로 대체되지 않습니다.
더 큰 책임을 요구하는 'AI 기반 전문 코딩'
JetBrains는 AI를 반대하지 않지만 혼란은 지양합니다.
일회성 산출물에 최적화된 코딩 방식도 있으며, 이는 상황에 따라 충분히 유효합니다. 그러나 JetBrains IDE는 일회용이 아닌, 장기적으로 사용될 코드를 위해 설계되었습니다.
설계 원칙은 다음과 같습니다. 생성된 코드를 대상으로 실제 코드와 동일하게 다음 작업을 수행할 수 있어야 합니다.
- 코드 읽기
- 코드 검토
- 코드 변경
- 오류 발생 시 롤백
- 코드베이스에 미치는 영향 이해
기본적인 기대 사항은 평범합니다.
- 변경 사항은 가시적이어야 합니다.
- 변경 사항은 가역적이어야 합니다.
- 프로젝트는 손상된 상태로 남아서는 안 됩니다('red code가 없는 상태'여야 작업을 시작할 수 있음).
에이전트는 여러 파일을 편집할 수 있습니다. 이는 강력한 기능이 될 수 있지만, 사용자가 결과를 완전히 검토하고 이해하며 수정할 수 있을 때만 그렇습니다. 이것이 IDE가 중요한 이유입니다. 사람이 생성했든 AI가 생성했든 생성된 코드에 대해 가시성과 제어 권한을 사용자에게 제공하기 때문입니다.
AI 활용 방식은 사용자 선택: 당사의 제품 원칙
1. AI와 기존 모드 공존
입력 중심 워크플로와 AI 중심 워크플로 모두 유효합니다. JetBrains는 개발자를 대체하기 위해 설계하지 않으며, 하나의 '정식' 워크플로로 사용자를 유도하는 IDE를 설계하지도 않습니다. 두 방식 모두를 존중합니다.
2. AI 에이전트는 IDE의 핵심 가치를 존중해야 함
에이전트를 위한 모든 발전은 IDE의 핵심 가치인 깊이 있는 코드 인텔리전스, 안전한 리팩터링, 디버그, 탐색, 검사, 검토 등 전문 개발의 구성 요소를 유지해야 합니다.
3. 벤더 종속성 없음
다양한 활성화 경로(구독, BYOK, OAuth(가능한 경우), ACP 에이전트)는 '있으면 좋은 것'이 아닙니다. JetBrains는 사용자의 워크플로가 특정 벤더에 종속되지 않도록 보장합니다.
4. 과장보다 장기적 효용
몇 주 후에도 실제 프로젝트에서 이 워크플로를 계속 사용한다면(실제 유지율, 실제 프로젝트), 그것이 신호입니다. 지금의 많은 AI 워크플로는 과장에 가깝습니다(랄프 루프도 한 예입니다).
5. 솔직한 커뮤니티 피드백 우선
JetBrains는 Reddit 사용자, Marketplace 리뷰어, 가감 없이 의견을 전달하는 커뮤니티 구성원의 목소리를 중요하게 생각합니다. 바로 그런 사용자들이 당사의 성과를 평가해 주기를 바랍니다.
AI는 많은 코드를 생성하게 될 것입니다. 이는 더 이상 예측이 아니라 2026년 4월의 현실입니다.
그러나 코드에 대한 책임은 여전히 사람에게 있습니다. 코드를 병합하기 전에 누군가는 반드시 코드를 읽어야 합니다. 에이전트는 속도를 높여주지만, 위험을 책임져 주지는 않습니다.
JetBrains가 드리는 약속은 명확합니다:
코드 생성 속도를 향상하는 AI 워크플로를 지속적으로 개발하는 동시에, 산출물에 대한 검토, 이해, 소유가 가능한 핵심 환경으로서 IDE를 계속 발전시켜 나갈 것입니다.
여러분은 AI 활용 수준을 결정하세요. JetBrains는 AI 지원 방식과 기존 방식이 함께 원활히 작동하도록 보장하여 여러분이 원하는 방식을 계속 사용할 수 있도록 지원하겠습니다.
게시물 원문 작성자
