JetBrains는 Qwen3.6-27B 모델을 사용해 MacBook M5에서 Junie Local의 첫 번째 버전을 로컬로 실행한 엔지니어링 세부 사항을 공개했다. 실용적인 성능에 도달하기 위해서는 단순히 압축 모델을 선택하는 것만으로는 충분하지 않았으며, 코딩 에이전트 자체와 추론 엔진, 모델 설정, 컨텍스트 관리 방식에 대한 수정이 필요했다고 설명했다.
회사는 클라우드 추론 없이 Junie 전체를 기기에서 실행하는 프로젝트가 광범위한 하드웨어 구성 지원을 목표로 하는 장기 프로젝트라고 밝혔다. 현재 제공되는 첫 번째 버전은 MacBook M5 기기에 초점을 맞추고 있으며, 이는 발표된 최적화가 해당 칩의 특성에 집중된 이유를 설명한다.
세션 안에서 작업 컨텍스트 유지하기
다른 코딩 에이전트와 마찬가지로 Junie는 사용자가 모델에 작업을 보내면 모델이 Bash 명령 실행, 파일 읽기 및 쓰기와 같은 도구를 호출하고, 해당 작업의 결과를 다시 모델에 전달하는 실행 루프를 통해 작동한다. 새로운 요청이 있을 때마다 컨텍스트가 확장되며, 모델이 이전 요청에서 처리한 KV-cache 데이터를 재사용할 수 있다.
클라우드 모델에서는 prefill 단계, 즉 응답을 생성하기 전에 초기 컨텍스트를 처리하는 단계가 비교적 빠르기 때문에 에이전트가 필요할 때 파일을 다시 요청할 수 있다. 그러나 JetBrains는 로컬 모델에서 파일을 읽는 데 시간이 많이 걸린다는 사실을 발견했다. 이에 따라 로컬 추론 로직을 수정해 새로운 요청마다 해당 요청에 적합하다고 판단되는 부분만 남기는 대신, 각 요청을 이동 중인 컨텍스트에 직접 추가하도록 했다. 이렇게 하면 모델이 읽은 파일이 컨텍스트에 남아 KV-cache를 재사용할 수 있으므로 다시 처리할 필요가 없다.
또한 회사는 새로운 코딩 세션을 시작할 때 Junie가 전송하는 데이터의 순서를 변경하고, 추론 엔진에 사용자 요청까지의 프리픽스를 저장하는 로직을 추가했다. 그 결과 동일한 프로젝트 내의 후속 작업에서 이 프리픽스를 재사용할 수 있다. 사용자 요청 이후에 이어지는 프로젝트 컨텍스트는 같은 방식으로 저장하지 않았는데, 상대적으로 작고 자주 변경될 수 있는 최상위 수준 파일로 주로 구성되기 때문이다.
모델 동작에 따른 조정
Qwen3.6은 Junie가 클라우드 모델에서 기대하는 방식으로 진행 상황 업데이트를 처리하지 않았다. XML과 유사한 형식의 상태 업데이트 블록을 대체로 무시했지만, 도구 호출과 함께 자신의 동작을 텍스트로 설명했다. JetBrains는 이 동작을 활용해 생성된 텍스트를 사용자 업데이트로 표시했다. 회사는 이러한 적응이 모델에 특화된 것이라고 설명하며, 다른 모델은 텍스트를 전혀 출력하지 않거나 지나치게 많은 텍스트를 생성할 수 있다고 밝혔다.
JetBrains는 작업에 대한 짧은 설명을 생성하는 로직을 포함해 모델에 대한 선택적 요청도 비활성화했다. 회사는 요청 수를 줄이는 대가로 발생하는 제한적인 사용성 저하는 감수할 수 있다고 판단했다. 또한 멀티 에이전트 모드도 중단했다. 테스트 결과 M5 기기에서는 순차 처리가 더 효율적이었으며, 병렬 요청은 여전히 추론 속도에 의해 제한되기 때문이다.
Qwen3.6-27B를 선택한 이유
JetBrains는 로컬 버전에서 reasoning을 완전히 비활성화하기로 결정했다. 회사의 Qwen3.6-27B 클라우드 버전에 대한 내부 테스트에 따르면 reasoning을 활성화해도 품질이 크게 향상되지 않았다. reasoning 토큰이 추론 엔진이 생성하는 토큰에 포함되기 때문에 이를 비활성화하면 필요한 토큰 수가 약 2~3배 줄어들었고, 회사는 이를 작업 실행 속도가 약 2배 빨라지는 결과로 환산했다. 품질에 미치는 영향은 중요하지 않은 수준이라고 설명했다.
회사는 4-bit 양자화 버전을 사용했다. 벤치마크에서 8-bit 버전보다 성능이 약간만 낮았고, 메모리와 관련된 토큰 생성 속도가 8-bit 버전보다 약 2배 빨랐기 때문이다. 그러나 초기 테스트에서는 4-bit, 8-bit, 16-bit 버전 사이에 prefill 속도 차이가 없었고, 이에 따라 팀은 엔진 내부의 산술 연산을 조사했다.
보이지 않는 병목: prefill 단계
JetBrains의 수치에 따르면 기본 설정에서 RTX 5090의 prefill 속도는 초당 약 3,700토큰에 이를 수 있는 반면, 최적화 전 M5에서는 초당 약 650토큰이었다. 파일을 조사하는 작업에서는 응답 자체를 생성하는 데보다 컨텍스트를 처리하는 데 대부분의 시간이 소요됐다.
팀은 prefill 중 행렬 연산의 상당 부분이 16-bit 정밀도로 실행된다는 사실을 발견했다. 가중치가 4-bit로 압축되어 있어도 연산을 실행하기 전에 가중치가 16-bit로 변환되었기 때문이다. M5에는 8-bit 정밀도 계산을 위한 특수 명령어가 있으므로, JetBrains는 MLX-VLM 패키지를 수정해 self-attention 계층의 일부 행렬 연산을 8-bit로 수행하도록 했다. 그 결과 prefill 속도가 약 40% 향상됐다. 이 수정은 full-attention 계층에는 적용되지 않았으며, 이 계층의 가중치는 양자화를 적용해도 16-bit 정밀도로 유지된다.
회사는 특히 이러한 산술 연산 명령어 때문에 현재 M5에 집중하고 있다고 설명했다. M4 칩에는 해당 명령어가 없으며, JetBrains에 따르면 prefill 단계에서 M4의 16-bit 계산은 M5보다 20%에서 30% 느리다.
생성 속도 향상과 모델 선택
JetBrains는 두 가지 speculative decoding 방식을 함께 활성화했다. 하나는 별도의 초안 모델을 사용하는 다중 토큰 예측 MTP이고, 다른 하나는 컨텍스트에서 반복되는 시퀀스를 찾아 다음 토큰을 예측하는 n-gram 매칭이다. 일부 경우 MTP를 통해 제안된 약 3개의 토큰과 n-gram 매칭을 통해 추가로 최대 8개의 토큰을 수락할 수 있었으며, 이를 통해 생성 속도가 최대 2배 빨라졌다.
회사는 Qwen3.8-27B가 Mac 기기에서 최선의 선택은 아니었다고 설명했다. 제대로 작동하려면 reasoning이 필요하기 때문이다. reasoning을 비활성화하면 품질이 크게 저하되고, 모델이 동일한 도구 호출을 반복하는 루프에 빠질 수 있다. 반면 중간 수준으로 활성화하면 생성되는 토큰 수가 약 5배 증가해 실제로는 속도가 약 4배 느려진다. prefill 시간은 크게 변하지 않기 때문이다. 따라서 JetBrains의 평가에 따르면 현재 Qwen3.6-27B가 Mac 하드웨어에서 Junie를 로컬로 실행하기에 가장 적합한 선택으로 남아 있다.
certi.news의 분석: 실제로 무엇이 달라지는가?
이번 실험은 로컬 코딩 에이전트를 초당 생성 토큰 수만으로 측정하면 불완전한 그림을 얻을 수 있다는 점을 보여준다. 사용자는 파일 로딩, 컨텍스트 재사용, 도구 호출 실행도 기다려야 하며, 이러한 단계가 생성이 시작되기 전에 병목이 될 수 있다. 실제로 Junie의 수정은 파일을 다시 읽어야 할 필요성을 줄이고, MLX-VLM 수정은 M5에서 컨텍스트 처리 속도를 높이며, reasoning 비활성화는 필요한 토큰 수를 줄인다.
그러나 제약도 분명하다. 첫 번째 버전은 M5에 집중하고 있으며, 품질 유지를 위해 reasoning에 의존하는 모델에는 reasoning 비활성화가 적합하지 않을 수 있다. 또한 진행 상황 업데이트의 활용 여부는 Qwen3.6의 동작에 따라 달라진다. JetBrains는 DGX Spark와 RTX 5090 지원을 위한 프로토타입을 보유하고 있으며, 24GB 용량의 카드도 검토하고 있다고 밝혔다. 그러나 이 자료는 해당 버전의 출시 시점이나 사양을 제시하지 않는다. 따라서 Junie Local은 더 사용하기 쉬운 로컬 코딩 에이전트를 향한 중요한 기술적 단계이지만, 모든 클라우드 모델과 경험이 동등해졌거나 모든 종류의 하드웨어에서 이용할 수 있게 됐다는 증거는 아니다.