JetBrains Junie 리뷰: IntelliJ의 네이티브 AI 코딩 에이전트 테스트

AI 코딩 에이전트가 존재해 온 기간 내내, JetBrains 사용자들은 주변부에서 지켜볼 수밖에 없었습니다. 흥미로운 도구들은 VS Code 포크(fork)나 VS Code 확장 프로그램(extension) 형태로 출시되었고, IntelliJ 사용자들은 한 단계 뒤처진 느낌을 주는 플러그인을 받아야 했습니다. 유용한 자동 완성(autocomplete)과 채팅 패널은 있었지만, IntelliJ를 가치 있게 만드는 핵심 요소인 인덱스(index)에는 전혀 손을 대지 못했습니다. JetBrains IDE는 플러그인을 덧붙인 텍스트 에디터가 아닙니다. 그것들은 코드의 의미론적 모델(semantic models)이며, 그 모델이야말로 핵심입니다. 이 모델을 무시하는 에이전트는 가장 강력한 도구를 제대로 활용하지 못하는 것입니다.

Junie는 JetBrains의 해답입니다. 이는 IntelliJ 제품군 — IntelliJ IDEA, PyCharm, WebStorm, GoLand 등을 포함한 — 에 내장된 네이티브(native) AI 코딩 에이전트이며, 프로젝트를 단순한 텍스트 파일 폴더로 취급하지 않는다는 점을 핵심 가치로 내세웁니다. Junie는 IDE가 탐색(navigation)과 리팩터링(refactoring)에 사용하는 것과 동일한 인덱스를 읽고, 자신의 작업 내용을 확인하기 위해 기존의 실행 구성(run configurations)을 실행하며, 사용자가 각각의 의미 있는 단계를 승인하는 동안 다단계 작업을 수행합니다. 저는 이 깊은 통합이 마케팅 문구에 불과한지 아니면 진정한 강점인지 알아내기 위해, 대규모 Kotlin 서비스 내의 IntelliJ IDEA에서 이를 기본 에이전트로 사용하며 PyCharm에서도 몇 차례 테스트하며 2주를 보냈습니다. 요약하자면, 적절한 코드베이스에서는 진정으로 차별화됩니다. 하지만 적절하지 않은 코드베이스에서는 필요하지 않은 IDE의 무게감에 비용을 지불하는 셈이 됩니다.

"네이티브"가 실제로 제공하는 것

"네이티브(native)"라는 단어는 흔하게 사용되므로, Junie가 무엇을 재사용하는지 구체적으로 살펴보는 것이 가치가 있습니다. Junie에게 작업을 부여할 때, 단순히 저장소를 grep으로 검색하며 추측하는 것이 아닙니다. Junie는 IntelliJ 인덱스에 쿼리(query)를 보냅니다. 이는 Find Usages, Go to Definition, 그리고 제가 이 IDE를 사용한 15년 동안 단 한 번도 빌드를 깨뜨린 적 없는 이름 변경 리팩터링(rename refactor)을 구동하는 것과 동일한 데이터 구조입니다. 즉, Junie가 메서드 시그니처(method signature)를 변경하기로 결정했을 때, 정규 표현식(regex) 방식이 아니라 IDE가 보는 방식 그대로 모든 호출자(caller)를 확인할 수 있다는 의미입니다.

실제로 이러한 점은 모듈 간 변경(cross-module changes) 작업에서 가장 명확하게 나타났습니다. 저는 여러 Gradle 모듈에 걸쳐 약 40개의 호출 지점(call sites)이 흩어져 있는 서비스에 새로운 파라미터를 전달하도록 요청했습니다. grep 기반의 에이전트는 명백한 호출 지점들은 찾아내지만, 테스트 헬퍼(test helper) 안에 숨겨져 있거나 오버로드(overload) 뒤에 있는 호출은 놓치는 경향이 있습니다. 하지만 Junie는 인덱스(index)를 통해 이를 찾아냈습니다. 또한 Junie는 텍스트를 직접 수정하는 대신 IDE의 리팩터링 엔진(refactoring engine)에 의존했습니다. 이름을 변경할 때, 스코프(scope)와 섀도잉(shadowing)을 구조적으로 인식하는 실제 이름 변경 메커니즘(rename machinery)을 사용했습니다. 그 결과, 제가 직접 수정했을 법한 수준의 변경이 이루어졌으며, 제가 일일이 정리해야 하는 아쉬운 수준의 변경 사항들이 쌓이지 않았습니다.

두 번째 요소는 실행 구성(run configurations)입니다. Junie는 이미 설정된 실행 및 테스트 구성을 실행할 수 있습니다. 이는 Junie가 변경 사항을 작성하고, 관련 테스트 타겟을 실행하고, 실패 내용을 읽고, 이를 반복할 수 있음을 의미합니다. 이 모든 과정은 IDE 내부에서, 사용자가 실제로 사용하는 툴체인(toolchain)을 대상으로 이루어집니다. "컴파일이 되는가"와 "테스트를 통과하는가"가 Gradle, 어노테이션 프로세서(annotation processors), 그리고 느린 콜드 스타트(cold start)와 관련된 복잡한 문제인 JVM 프로젝트에서, 에이전트가 셸 명령어를 추측하는 대신 실제 구성을 구동한다는 것은 의미 있는 신뢰성 향상입니다.

JVM 코드베이스는 텍스트 수준의 도구에는 보이지 않는 요소들에 크게 의존합니다: 런타임(runtime)에 결정되는 인터페이스 구현(interface implementations), 의존성 주입(dependency injection) 연결, 어노테이션 프로세서로부터 생성된 코드, 그리고 파라미터 타입만 다른 메서드 오버로드(method overloads) 등이 그것입니다. 원시 텍스트를 읽는 에이전트는 이러한 요소들에 대해 신뢰할 수 있는 추론을 할 수 없습니다. 반면 IntelliJ 인덱스를 읽는 에이전트는 가능합니다. 인덱스가 이미 이들을 해결(resolve)해 놓았기 때문입니다. 이것이 바로 Junie가 대규모 Java 및 Kotlin 프로젝트에서 범용 에이전트보다 뛰어난 성능을 보이는 가장 결정적인 이유이며, 해결해야 할 구조가 거의 없는 작은 Python 스크립트에서는 그 격차가 줄어드는 이유입니다.

Junie와 기존 AI Assistant 플러그인 비교

최근 JetBrains IDE를 사용해 보셨다면, JetBrains가 처음 출시했던 채팅 및 완성 (chat-and-completion) 플러그인인 AI Assistant를 이미 만나보셨을 것입니다. 이 둘을 혼동하기 쉽고, JetBrains 또한 항상 그 차이를 명확하게 구분해 온 것은 아니지만, 이들은 서로 다른 작업을 수행하는 서로 다른 도구입니다.

AI Assistant는 대화형 및 인라인 (inline) 레이어입니다. 코드 완성 (code completion), 질문을 위한 채팅 패널, 코드 설명 (explain-this-code), 커밋 메시지 생성 (generate-a-commit-message) 등 하루에도 수십 번씩 호출하게 되는 작은 보조 기능들을 담당합니다. 반면 Junie는 에이전트 (agent)입니다. 당신이 일상적인 언어로 작업을 전달하면, Junie는 계획을 세우고, 여러 파일을 수정하며, 테스트를 실행하고, 결과를 보고합니다. AI Assistant는 대답하지만, Junie는 실행합니다. 제 워크플로에서 이 둘은 경쟁 관계가 아닌 상호 보완적인 관계로 자리 잡았습니다. 타이핑 속도 향상을 위해 AI Assistant의 완성 기능을 켜둔 상태에서, 질문에 대한 답을 얻고 싶을 때가 아니라 처음부터 끝까지 실행되어야 하는 별도의 작업이 있을 때 Junie를 사용했습니다.

실질적인 영향으로는 구독 중복 문제(나중에 다시 다루겠습니다)와 어떤 도구를 사용해야 할지 알아가는 데 약간의 학습 곡선이 필요하다는 점이 있습니다. 초기에는 단순히 질문만 하면 되는 일에 Junie를 사용하려 시도했는데, 이는 과잉 대응 (overkill)이었습니다.

2주가 넘는 기간 동안 승인 흐름 (approval flow)은 무모하게 느껴지지 않으면서도 대부분 제 방해를 하지 않았습니다. 범위가 명확하고 작은 작업의 경우, 일정한 리듬에 맞춰 승인하고 작업을 진행하게 둘 수 있었습니다. 더 큰 작업의 경우에는 마지막에 15개 파일에 달하는 차이점 (diff)을 되돌리는 대신, 두 번째 단계에서 잘못된 방향을 포착할 수 있다는 점이 만족스러웠습니다. 반면, Junie는 '실행 후 망각 (fire-and-forget)' 방식의 도구가 아니라는 점이 단점입니다. Junie는 체크포인트마다 사용자의 주의를 요구하는데, 이는 신뢰 구축 측면에서는 훌륭하지만, 긴 작업을 시작해두고 자리를 비우고 싶을 때는 그리 좋지 않습니다. 이는 버그가 아니라 의도된 설계 원칙이며, 프로젝트에 이토록 깊게 연결된 에이전트에게는 올바른 방향이라고 생각합니다.

Junie가 어려움을 겪은 부분은 모든 에이전트가 어려워하는 지점과 동일했습니다. 즉, 명확한 성공 신호가 없는 모호하고 방대한 작업들입니다. 실패하는 테스트나 구체적인 수락 기준 (acceptance check)을 지정해 주었을 때, Junie는 스스로 테스트를 실행할 수 있었기에 안정적으로 성공 (green)을 향해 반복 작업을 수행했습니다. 하지만 작업 내용이 "이 모듈의 에러 핸들링 (error handling)을 개선하라"와 같을 때는, 합리적이긴 하지만 초점이 맞지 않는 결과물을 내놓아 방향 지시가 필요했습니다. 이는 Junie에만 국한된 교훈은 아닙니다. 에이전트에게 검증 가능한 목표를 부여하라는 점 말입니다. 다만, Junie가 그 목표를 실제로 실행할 수 있는 능력이 있기에 범위가 명확한 작업에서 매우 뛰어난 성능을 발휘하는 것입니다.

Junie는 JetBrains AI 구독을 통해 실행되며, 이는 무제한이 아닌 할당량 (quota) 기반입니다. 에이전트의 다단계 실행 — 계획 수립, 편집, 테스트 반복 실행 및 출력 결과 읽기 — 은 빠른 채팅보다 더 많은 할당량을 소비하며, 에이전트 중심의 작업을 많이 하는 날에는 예산이 예상보다 빠르게 소진되는 것을 느꼈습니다. 정확한 한도와 등급은 시간이 지남에 따라 변하고 플랜마다 다르므로, 특히 Junie를 하루 종일 주요 에이전트로 사용할 계획이라면 사용 전 현재 JetBrains AI 가격 정책을 확인하십시오. 에이전트 기반 작업이 핵심 용도라면 엔트리 티어 (entry tier) 이상의 예산을 고려하십시오.

뒤처지는 부분, 그리고 IDE의 무게라는 비용

이 글을 무조건적인 승리라고 작성하는 것은 정직하지 못한 일일 것입니다. 두 가지 요소가 제가 비용을 지불하고 있다는 사실을 지속적으로 상기시켜 주었습니다.

첫 번째는 IDE의 무거움입니다. IntelliJ는 강력한 환경이며, 그 강력함에는 메모리 점유율(memory footprint), 새로운 체크아웃 시의 인덱싱 시간(indexing time), 가벼운 에디터보다 느린 시작 속도와 같은 대가가 따릅니다. 만약 당신이 이미 하루 종일 IntelliJ를 사용하고 있다면, Junie는 본질적으로 추가적인 오버헤드(overhead)를 발생시키지 않습니다. 왜냐하면 IDE라는 비용은 이미 지불한 상태이며, 에이전트는 그저 이미 그곳에 자리 잡고 있는 인프라를 사용할 뿐이기 때문입니다. 하지만 만약 당신이 더 가볍고 빠른 에디터 기반 도구들의 세계를 통해 AI 에이전트에 매력을 느꼈다면, Junie를 사용하기 위해 완전한 JetBrains IDE로 들어가는 것은 반응성 측면에서 퇴보하는 것처럼 느껴질 것입니다. 저의 M 시리즈 MacBook에서 IDE 자체는 괜찮았지만, 저는 그 안에서 생활하는 사람입니다. 아주 가벼운(feather-light) 설정에서 넘어온 입장에서 그 대비는 실재합니다.

두 번째는 최신 전용 도구들과 비교했을 때의 에이전트 완성도(agent polish)입니다. 카테고리 리더들은 지난 몇 년간 에이전트 루프(agent loop) — 응답 속도, 다중 파일 편집의 유연성, 사용감 등을 다듬는 데 모든 사이클을 쏟아부었습니다. Junie는 훌륭하며 빠르게 개선되고 있지만, 순수한 에이전트 인체공학(agent ergonomics)과 지연 시간(latency) 측면에서는 아직 최고의 전용 에이전트들을 앞서지 못합니다. Junie가 이를 대신해 얻는 것은 컨텍스트 품질(context quality)입니다. 대규모 프로젝트에서는 추측만 하는 빠른 에이전트보다 제 코드베이스를 이해하는 약간 덜 매끄러운 에이전트를 선택하겠지만, 인덱스가 이해할 내용이 거의 없는 소규모 프로젝트에서는 그 트레이드오프(trade-off)가 역전되며 속도 차이를 체감하게 됩니다.

Junie와 Cursor 및 Copilot의 비교

정직한 프레임워크는 "Junie가 최고의 에이전트인가"가 아니라 "누구에게 Junie가 최고의 에이전트인가"입니다. 자신의 IDE를 떠나고 싶지 않은 IntelliJ 제품군에 전념하는 개발자들에게 비교 대상은 적으며, Junie는 거의 당연하게 승리합니다. 왜냐하면 대안은 애초에 에이전트를 호스팅하도록 설계되지 않은 IDE 위에, 혹은 그 옆에 통합성이 떨어지는 도구를 덧붙이는 것뿐이기 때문입니다.

사람들이 "에이전트가 훨씬 더 낫다"라고 말할 때 가장 먼저 떠올리는 도구는 Cursor입니다. Cursor는 빠르고, 다중 파일 편집 (multi-file editing)이 유연하며, 저장소 이해도 (repository understanding)가 진정으로 강력합니다. 하지만 Cursor는 그 자체로 별도의 에디터입니다. 이를 채택한다는 것은 IntelliJ를 떠난다는 것을 의미하며, JetBrains의 탐색 (navigation), 리팩터링 (refactoring), 디버깅 (debugging)을 기반으로 생산성을 쌓아온 개발자에게 이는 결코 작은 요구가 아닙니다. 당신은 더 매끄러운 에이전트 루프 (agent loop)를 위해 코드에 대한 깊고 구조적인 이해를 맞바꾸게 되는 것입니다. 어떤 이들에게는 그만한 가치가 있는 거래일 수 있습니다. 하지만 IntelliJ에서 10년 동안 근육 기억 (muscle memory)을 쌓아온 Kotlin 팀에게는 대개 그렇지 않습니다.

Copilot은 실용적인 중간 지점입니다. JetBrains IDE 내부에서 플러그인 (plugin)으로 실행되므로 IDE를 떠날 필요가 없으며, 지원하는 언어 범위도 넓습니다. 하지만 플러그인으로 실행된다는 점이 바로 한계입니다. Junie가 JetBrains의 네이티브 제품으로서 구축된 방식처럼 IntelliJ 인덱스 (index)에 대한 일등 시민 (first-class) 수준의 접근 권한을 갖지 못합니다. IDE 내에 에이전트를 갖게 되지만, 에이전트가 IDE의 코드 모델을 완전히 이해하지는 못하는 상태가 됩니다. 이미 GitHub 생태계에 깊이 발을 담그고 있다면 이는 합리적인 선택지일 수 있지만, Junie를 흥미롭게 만드는 특정한 장점을 양보하는 셈이 됩니다.

누가 Junie를 사용해야 하는가

Junie는 한 그룹에게는 쉬운 추천이지만, 그 외의 모든 이들에게는 어려운 추천입니다. 만약 당신이 IntelliJ IDEA, PyCharm, GoLand 또는 다른 JetBrains IDE를 매일 사용하며, 상당한 규모의 Java 또는 Kotlin 코드베이스를 다루고 있고, 해당 환경을 떠날 의사가 전혀 없다면, Junie는 당신의 기존 작업 방식을 존중하는 에이전트입니다. 프로젝트의 구조(모듈, DI 와이어링, 생성된 코드, 광범위한 리팩터링 등)가 더 깊고 복잡할수록, Junie의 인덱스 접근 권한은 더 큰 보상을 제공하며, 코드를 단순 텍스트로 읽는 에이전트들보다 훨씬 앞서 나가게 됩니다.

해당 프로필에서 벗어날수록 이 사례는 약화됩니다. 만약 당신의 작업이 주로 이해해야 할 기존 구조가 거의 없는 작은 스크립트나 그린필드 프로젝트 (greenfield projects)라면, Junie의 핵심적인 장점은 거의 발휘되지 않으며, 사용하지도 않는 혜택을 위해 IDE의 무게를 감당하게 됩니다. 만약 당신이 아직 JetBrains 사용자가 아니라면, 단지 Junie를 사용하기 위해 전체 IntelliJ IDE를 도입하는 것은 큰 결심이 필요하며, 더 가벼운 에디터에서 작동하는 전용 에이전트가 일상적인 사용 측면에서 더 나은 느낌을 줄 가능성이 높습니다. 그리고 만약 무엇보다도 에이전트의 순수 속도와 가장 세련된 루프 (loop)를 최우선으로 최적화한다면, 최신 전용 도구들이 여전히 근소하게 앞서 있습니다.

2주간 사용해 본 저의 결론은, Junie가 마침내 "나는 IntelliJ를 떠나기를 거부한다"라는 입장을 더 이상 사과할 필요가 없는 위치로 만들어 주었다는 것입니다. 시장에서 가장 화려한 에이전트는 아니지만, 대규모 JVM 코드베이스에서는 제가 사용해 본 것 중 가장 신뢰할 수 있는 에이전트였습니다. 바로 Junie가 제가 애초에 이 IDE를 신뢰하게 만들었던 것과 동일한 토대 위에 서 있기 때문입니다.

FAQ