JetBrains Junie CLI 베타 × Clash Verge Rev: 터미널 코딩 에이전트 API 분류와 DNS 실측 (2026)

① 검색 의도부터: 이 글이 맞는 경우와 아닌 경우

Junie CLI는 JetBrains가 내놓는 코딩 에이전트 경험을 셸에서 재현하려는 흐름으로 읽는 편이 안전합니다. 정확한 서브커맨드 이름이나 배포 채널은 업데이트될 수 있으니, 여기서는 「무엇을 눌러야 한다」보다 네트워크 스택이 어디서 갈라지는지에 초점을 둡니다.

회사 프록시나 Zero Trust 게이트가 이미 모든 터미널 트래픽을 잡고 있다면 Clash 쪽은 보조 수단에 그칠 수 있습니다. 반대로 개인 기기에서 Clash Verge Rev만 켜 두고 개발을 하는 패턴이라면, 이 글의 API 분류·DNS 순서가 바로 적용됩니다. 전반 개념은 Clash 입문 튜토리얼의 Rule·모드 설명과 같이 읽으면 헷갈림이 줄어듭니다.

② 왜 IDE에서는 되고 터미널 에이전트만 불안정해질까

JetBrains IDE는 내부적으로 HTTP 클라이언트 설정·플러그인 샌드박스·임베디드 JRE 네트워크 스택을 섞어 씁니다. 사용자가 체감하는 「잘 된다」는 보통 GUI 세션이 시스템 프록시나 자체 프록시 다이얼로그를 타고 있기 때문입니다.

Junie CLI처럼 터미널에서 도는 경로는 curl과 비슷하게 환경 변수와 라이브러리 기본값에 민감합니다. Clash Verge Rev에서 TUN을 켜도, 해당 프로세스가 TUN을 타기 전에 DIRECT로 붙어버리면 증상은 동일합니다. 비슷한 패턴은 Cursor 3 + Verge Rev DNS 글에서도 다뤘는데, 차이는 호스트 묶음 이름뿐입니다.

③ 준비: Verge Rev에서 프로필·로그 화면을 고정한다

작업 전에 다음을 맞춥니다. (1) 지금 활성 프로필이 맞는지, 구독 갱신 시각이 최근인지. (2) 규칙 모드가 의도한 스위치인지. (3) 동시에 켜 둔 VPN·필터 드라이버가 없는지.

Mihomo 로그는 한 줄만 봐도 RULE 적중 결과를 알 수 있습니다. 앱 UI 이름은 빌드마다 조금씩 달라도, 「프로필」「로그」「연결」 축은 같습니다. rule-providers 주기와 캐시 경로를 손보는 경우에는 Windows 11 기준 rule-providers 간격 글을 같이 보세요. 운영체제가 다르더라도 개념은 그대로 이어집니다.

④ 증상 문자열을 추측하지 말고 그대로 적는다

첫 단계는 항상 재현입니다. 실패한 직후 터미널에 남은 한 줄을 메모 앱에 붙여 넣고, 앞뒤 공백을 제거합니다.

• 패턴 A: 특정 API 접미사에서만 i/o timeout이 반복된다.
• 패턴 B: TLS 관련 문자열만 보이고 응답 본문은 없다.
• 패턴 C: 짧은 시간에만 429·503이 겹친다.

패턴 C는 라우팅보다 서버 속도 제한이나 재시도 폭주일 때가 많습니다. 이때는 규칙을 더 붙이기 전에 동시 실행 수를 줄이는 편이 빠릅니다. Cloud 에이전트와 ChatGPT Codex 비교가 필요하면 OpenAI Codex + Clash 분류·DNS 글의 진단 순서를 교차해 보세요.

⑤ API 분류 스케치: JetBrains 축을 별도 그룹으로 둔다

아래 YAML은 개념 예시입니다. 실제 접미사는 로그 근거로 채워야 하며, 이름은 자신의 proxy-groups 항목과 정확히 같아야 합니다. 젯브레인즈 도메인·플러그인 캐시·레지스트리를 한 줄에 몰아넣으면 나중에 원인 분해가 어렵습니다.

rules:
  - DOMAIN-SUFFIX,jetbrains.com,JUNIE_CLOUD
  - DOMAIN-SUFFIX,intellij.net,JUNIE_CLOUD
  - DOMAIN-SUFFIX,plugins.jetbrains.com,JUNIE_PLUGINS
  - DOMAIN-SUFFIX,resources.jetbrains.com,JUNIE_PLUGINS
  - DOMAIN-SUFFIX,download.jetbrains.com,JUNIE_ARTIFACTS
  - DOMAIN-SUFFIX,github.com,JUNIE_DEPS
  - DOMAIN-SUFFIX,githubusercontent.com,JUNIE_DEPS
  - GEOIP,KR,DIRECT
  - MATCH,PROXY

JUNIE_CLOUD와 JUNIE_PLUGINS를 나누면 「모델 호출만 끊긴다」「아이콘 리소스만 느리다」를 바로 분해할 수 있습니다. 규칙 중첩 순서를 바꿀 때는 사용자 정의 규칙 튜토리얼의 예시와 맞춰 검증하세요.

⑥ DNS: fake-ip와 DoH가 동시에 올 때의 교차 오염

Clash Verge Rev에서 흔한 실수는 fake-ip를 켠 채로 특정 접미사만 DoH로 보내려다, TCP 연결 시작 시점과 SNI가 어긋나는 경우입니다. CLI는 브라우저보다 짧은 타임아웃을 쓰기 때문에 겉으로는 같은 증상으로 보입니다.

점검 순서는 이렇게 잡습니다. (1) 문제 접미사에 대해 dig 또는 OS resolver와 Mihomo DNS 로그를 나란히 둔다. (2) fallback 그룹이 의도대로 응답 지연 시 다음 업스트림으로 넘어가는지 본다. (3) 한 번은 테스트 프로필에서 fake-ip를 끄고 동일 명령을 재현해 본다.

Mixin으로 DNS만 덮어써야 한다면 macOS나 Windows 각각의 Verge 튜토리얼을 참고해 구독 본문을 건드리지 않는 편이 안전합니다. 이미 CI에서 비슷한 분류를 맞춰 봤다면 Cursor Agent SDK + Clash 글의 DNS 절과 비교표를 만들어 두면 팀 내 공유가 빨라집니다.

⑦ 터미널 프록시 환경 변수: 대소문자·no_proxy까지

많은 턴키 VPN 앱은 「한 번 켜면 끝」처럼 보이지만, 실제 개발 셸은 HTTP_PROXY와 http_proxy를 서로 다른 레이어에서 읽습니다. Junie CLI가 사용하는 런타임이 어느 쪽을 우선하는지 릴리스 노트에 없을 때가 많으므로, 둘 다 같은 값으로 맞추는 편이 마음 편합니다.

no_proxy에는 사내 Git·사설 레지스트리·루프백을 넣어 순환을 막습니다. 회사망에서 *.local 예외가 필요하면 쉼표 목록을 팀 위키에 고정해 두세요.

⑧ RULE-SET으로 승격할 때의 운영 리듬

베타 기간에는 새 API 접미사가 자주 추가됩니다. 하드코딩한 DOMAIN-SUFFIX 줄을 계속 늘리면 PR 리뷰가 느려지므로, 안정화되면 RULE-SET으로 옮기고 갱신 주기를 정합니다.

이때 중요한 것은 interval과 path가 러너·노트북·데스크톱에서 충돌하지 않게 하는 일입니다. 캐시 경로가 꼬이면 「어제까지 됐는데 갑자기 안 됨」이 생깁니다.

⑨ 20분 점검 루틴: 새 Junie 빌드 직후에 돌린다

1. 프로필 체크섬: 활성 YAML의 해시를 메모해 두었다가 빌드 바뀔 때마다 비교합니다.
2. 호스트 캡처: 실패 stderr에서 HTTPS 호스트를 복사합니다.
3. RULE 라인: 동일 호스트를 Verge 로그에서 재생해 적중 그룹을 확인합니다.
4. DNS A/B: fake-ip on/off 한 판씩, 가능하면 DoH 업스트림도 한 단계씩 바꿉니다.
5. 셸 정리: env | grep -i proxy로 중복·빈 값을 제거합니다.
6. 문서화: 팀 문서에 접미사 표를 추가하고 리뷰어를 한 명 지정합니다.

기록이 쌓이면 「베타 업데이트 날」에 패닉이 줄어듭니다. 헤드리스 도구일수록 로그 디스플린이 생산성과 직결됩니다.

⑩ 자주 묻는 질문

IDE에서는 되는데 Junie CLI만 간헐적으로 실패합니다.

GUI는 시스템 프록시를 따르지만 터미널은 환경 변수와 자체 HTTP 스택을 쓰는 경우가 많습니다. 동일 프로필이라도 규칙 적중 전에 DIRECT로 나가는지 로그로 먼저 확인하세요.

fake-ip를 켜두면 인증 교환만 느려질 수 있나요?

가능합니다. 특정 접미사만 nameserver 예외를 두거나, 테스트용 프로필에서 fake-ip를 잠깐 끄고 A/B 비교하는 편이 빠릅니다.

Cursor나 Codex 글과 무엇이 다른가요?

검색 의도는 비슷하지만 호스트 묶음과 패키지 레이어가 다릅니다. Junie는 JetBrains 생태계·라이선스·아티팩트 경로가 중첩되므로 규칙 이름을 별도 그룹으로 두는 편이 유지 보수에 유리합니다.

⑪ 단순 VPN과 비교했을 때 Verge Rev·Clash 쪽이 주는 여지

한 번의 토글로 모든 트래픽을 같은 출구에 묶는 단순 VPN은 첫 화면은 간단해 보여도, IDE·패키지·클라우드 API가 섞인 개발 환경에서는 오히려 디버깅이 어려워지는 경우가 많습니다. 직접·우회를 나누려 해도 앱마다 예외 규칙이 흩어지고, 업데이트가 느리면 OS 보안 정책과도 어긋납니다.

Clash Verge Rev처럼 Mihomo 프로필을 파일과 UI에서 동시에 다루는 흐름은 처음에 손이 가지만, API 분류·DNS·프록시 그룹을 한 장의 지도처럼 유지할 수 있습니다. 터미널 코딩 에이전트처럼 짧은 타임아웃을 반복하는 도구일수록 이 지도가 있으면 원인을 숫자로 줄일 수 있고, 감으로만 대응하지 않아도 됩니다. 비슷한 방식으로 로컬 스택을 정리하고 싶다면 프로젝트에서 안내하는 배포 경로로 신뢰할 수 있는 빌드를 고른 뒤, Clash 공식 다운로드 안내에서 설치와 구성 흐름을 맞춰 보시길 권합니다.