📖 튜토리얼 ⏱ 약 22분 분량

ReSharper 2026.2 Junie × Visual Studio × Clash Verge Rev: 분류 규칙과 DNS 단계별 실측 (2026)

2026년 5월 전후 JetBrains가 ReSharper 2026.2 EAP를 열면서 Visual Studio 안에서 돌아가는 Junie 형태의 JetBrains AI Agent가 다시 주목받고 있습니다. 검색으로 ReSharper 2026.2·Junie·Visual Studio와 함께 Clash Verge Rev·분류 규칙·DNS·모델 API 타임아웃까지 적었다면 보통 그림은 비슷합니다. 채팅 패널은 뜨는데 응답이 중간에 끊기거나, 특정 모델 API 호출만 짧게 타임아웃되고 라이선스·아티팩트 확인은 멀쩡합니다. 이 글은 Mihomo 코어를 쓰는 Clash Verge Rev를 전제로 IDE 안 에이전트와 터미널 CLI의 출구 차이를 짚고, JetBrains 축과 외부 LLM 공급자 축을 규칙으로 나눈 뒤 fake-ip·DoH가 겹칠 때 DNS를 정렬하는 순서를 한국어 실무 관점에서 묶었습니다.

① 검색 의도: 이 글이 맞는 증상인지부터 가른다

Visual Studio에서 ReSharper 번들을 켠 상태로 Junie 패널을 열었을 때, 네트워크 줄기는 대략 세 갈래로 갈립니다. 첫째는 jetbrains.com 계열 인증·라이선스·리소스, 둘째는 선택한 모델 공급자의 API 접미사, 셋째는 사내 Git·패키지 레지스트리 등 로컬망입니다. 한 갈래만 DIRECT나 잘못된 출구로 새면 패널 전체가 「불안정한 AI」처럼 보입니다.

회사 Zero Trust 클라이언트가 이미 모든 TLS를 가로챈다면 Clash는 보조에 그칠 수 있습니다. 반대로 집이나 개인 장비에서 Clash Verge Rev만 켜고 Visual Studio를 쓰는 패턴이라면, 아래 순서가 바로 적용됩니다. 전반 개념은 Clash 입문 튜토리얼의 Rule·모드 설명과 같이 읽으면 헷갈림이 줄어듭니다.

💡 한 줄 요약 Junie 로그에 찍힌 HTTPS 호스트를 기준으로 JetBrains·모델 API·의존성 축을 Verge Rev에서 서로 다른 프록시 그룹으로 나누고, fake-ip·DoH가 같은 접미사를 두 경로로 해석하지 않게 DNS를 먼저 정렬한 다음 Visual Studio가 타는 시스템 프록시와 포트를 맞춥니다.

② IDE 안 Junie와 터미널 Junie CLI는 출구가 다르다

같은 브랜드의 코딩 에이전트라도, Visual Studio 프로세스 안에서 돌아가는 경로와 PowerShell·cmd에서 도는 CLI는 네트워크 스택이 다릅니다. Junie CLI를 Verge Rev와 맞춰 본 경험이 있다면 JetBrains Junie CLI × Clash Verge Rev: 터미널 코딩 에이전트 API 분류와 DNS 실측 글과 짝지어 읽는 것이 좋습니다. 호스트 묶음 표는 재사용할 수 있지만, 확인해야 할 레이어가 달라집니다.

Visual Studio는 내부적으로 자체 HTTP 클라이언트와 Service Hub·부모/자식 프로세스를 섞습니다. 사용자가 체감하는 「잘 된다」는 종종 GUI 세션이 WinHTTP나 시스템 프록시를 따르기 때문입니다. 반면 터미널 CLI는 http_proxy 같은 환경 변수에 더 민감합니다. 분류 YAML이 같아도, 어느 쪽이 TUN·시스템 프록시·직접 연결 중 무엇을 타는지부터 로그로 가늠해야 합니다.

다른 IDE 조합에서 비슷한 패턴을 다룬 Cursor 3 + Verge Rev DNS 분류 글의 진단 순서도 교차 검증에 도움이 됩니다. 차이는 호스트 세트 이름과 프로세스 이름뿐입니다.

③ 준비: ReSharper 2026.2 EAP와 Verge Rev 화면을 고정한다

ReSharper 2026.2는 문서상 EAP 채널을 타는 빌드가 먼저 공개되는 흐름으로 이해하는 편이 안전합니다. 채널 이름·버튼 레이블은 바뀔 수 있으니, 여기서는 「어떤 메뉴인가」보다 네트워크 출구에 초점을 둡니다. 작업 전에 다음을 확인합니다.

  • (1) Clash Verge Rev에서 활성 프로필과 구독 갱신 시각이 최근인지.
  • (2) 규칙 모드가 의도한 스위치인지, 실수로 전역이나 직연결이 아닌지.
  • (3) 동시에 켜 둔 상용 VPN·필터 드라이버가 Visual Studio TLS를 가로채지 않는지.
  • (4) ReSharper 확장이 요구하는 최소 VS 버전과 실제 설치 버전이 맞는지.

Mihomo 로그 한 줄만 봐도 RULE 적중 결과를 알 수 있습니다. 연결 이벤트가 헷갈리면 Windows 11 기준 Verge Rev 로그·타임아웃 글의 패널 읽는 법을 참고하세요. OS가 달라도 로그 문법은 같습니다.

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

첫 단계는 항상 재현입니다. Junie 패널이나 Visual Studio 출력 창에 남은 한 줄을 메모 앱에 붙여 넣고, 앞뒤 공백을 제거합니다.

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

패턴 C는 라우팅 문제가 아니라 서버 속도 제한이나 재시도 폭주일 때가 많습니다. 규칙을 더 붙이기 전에 동시 요청 수·플러그인 자동 작업을 줄이는 편이 빠릅니다. 공급자별 진단 틀이 필요하면 OpenAI Codex + Clash 분류·DNS 글의 단계와 비교표를 만들어 두면 좋습니다.

⑤ 분류 스케치: JetBrains 축과 모델 API 축을 분리한다

아래 YAML은 개념 예시입니다. 실제 접미사는 로그 근거와 선택한 모델 공급자에 맞게 채워야 하며, proxy-groups 이름은 프로필 안의 실제 이름과 같아야 합니다.

rules:
  - DOMAIN-SUFFIX,jetbrains.com,JETBRAINS_CLOUD
  - DOMAIN-SUFFIX,jetbrains.space,JETBRAINS_CLOUD
  - DOMAIN-SUFFIX,plugins.jetbrains.com,JETBRAINS_PLUGINS
  - DOMAIN-SUFFIX,resources.jetbrains.com,JETBRAINS_PLUGINS
  - DOMAIN-SUFFIX,download.jetbrains.com,JETBRAINS_ARTIFACTS
  - DOMAIN-SUFFIX,api.openai.com,LLM_VENDOR
  - DOMAIN-SUFFIX,anthropic.com,LLM_VENDOR
  - DOMAIN-SUFFIX,googleapis.com,LLM_VENDOR
  - GEOIP,KR,DIRECT
  - MATCH,PROXY

LLM_VENDOR 접미사는 팀에서 쓰는 JetBrains AI 백엔드 설정에 맞춰 바꿉니다. 중요한 것은 「인증만 되고 응답만 실패」처럼 보일 때 JETBRAINS_CLOUD와 LLM_VENDOR를 한 덩어리로 두지 않는 것입니다. 그렇지 않으면 나중에 원인 분해가 불가능해집니다. 규칙 순서를 손볼 때는 사용자 정의 규칙 튜토리얼의 예시와 함께 검증하세요.

⑥ DNS: fake-ip와 DoH가 Visual Studio 타임아웃을 흉내 낼 때

Clash Verge Rev에서 흔한 실수는 fake-ip를 켠 채로 특정 접미사만 DoH로 보내려다, TCP 연결 시작과 SNI가 어긋나는 경우입니다. Visual Studio 쪽 HTTP 클라이언트는 브라우저보다 짧은 타임아웃을 쓰는 경우가 있어 겉으로는 같은 「모델 API 타임아웃」로 보입니다.

점검 순서는 이렇게 잡습니다. (1) 문제 접미사에 대해 OS resolver와 Mihomo DNS 로그를 나란히 둔다. (2) fallback 체인이 지연 시 다음 업스트림으로 넘어가는지 본다. (3) 테스트 프로필에서 한 번은 fake-ip를 끄고 동일 액션을 재현해 본다. (4) 동일 호스트가 브라우저에서는 빠르고 IDE에서만 느리면, 프로세스별 DNS 캐시 차이를 의심한다.

Mixin으로 DNS만 덮어쓸 때는 구독 본문을 직접 고치지 않는 편이 안전합니다. 이미 터미널 쪽에서 비슷한 실험을 했다면 Junie CLI × Clash 분류·DNS 글의 A/B 표를 복사해 VS 열에만 맞춰 수정해 보세요.

⑦ Visual Studio와 시스템 프록시: devenv가 실제로 타는 출구

Visual Studio 메뉴의 프록시 설정과 Windows 전체 시스템 프록시, 그리고 Clash Verge Rev의 시스템 프록시 토글은 각각 다른 레이어입니다. Junie Agent가 내부적으로 어느 레이어를 우선하는지 릴리스 노트에 모두 적혀 있지 않을 때가 많으므로, Verge Rev에서 허용한 mixed port·시스템 프록시 포트를 한 줄로 정리해 팀 위키에 올려 두는 편이 안전합니다.

no_proxy에는 사내 Git·사설 레지스트리·루프백을 넣어 순환을 막습니다. Visual Studio가 회사 PAC 파일을 읽는 환경이라면, Clash 규칙과 PAC 규칙이 같은 호스트에 서로 다른 출구를 지정하지 않는지도 확인해야 합니다.

⑧ RULE-SET으로 옮길 때의 운영 리듬

EAP 기간에는 새 API 접미사가 자주 추가됩니다. 하드코딩한 DOMAIN-SUFFIX 줄을 계속 늘리면 나중에 리뷰가 느려지므로, 패턴이 안정화되면 RULE-SET으로 옮기고 갱신 주기를 정합니다. 캐시 경로가 노트북과 데스크톱에서 달라지면 「어제까지 됐는데 갑자기 안 됨」이 생깁니다.

주기와 경로를 손볼 때는 rule-providers 간격·캐시 글의 체크리스트를 같이 적용하세요.

⑨ 22분 점검 루틴: ReSharper·Junie 빌드가 바뀐 직후

  1. 프로필 체크섬: 활성 YAML의 해시를 메모해 EAP 갱신 때마다 비교합니다.
  2. 호스트 캡처: VS 출력에서 HTTPS 호스트를 복사합니다.
  3. RULE 라인: Verge 로그에서 동일 호스트의 적중 그룹을 확인합니다.
  4. DNS A/B: fake-ip on/off 한 판씩, 가능하면 DoH 업스트림도 한 단계씩 바꿉니다.
  5. 시스템 프록시: OS와 Verge Rev의 포트·예외 목록을 다시 맞춥니다.
  6. 문서화: 접미사 표를 위키에 남기고 리뷰어를 한 명 지정합니다.

기록이 쌓이면 EAP 업데이트 날에 패닉이 줄어듭니다. IDE 안 에이전트는 로그 한 줄이 생산성과 직결됩니다.

⑩ 자주 묻는 질문

Junie CLI 글과 무엇이 다른가요?

CLI는 셸 환경 변수에 민감하고, Visual Studio 내 Junie Agent는 devenv·Service Hub 경로와 시스템 프록시를 타는 경우가 많습니다. 분류 이름은 같아도 확인할 프로세스 레이어가 다릅니다.

브라우저는 되는데 VS Junie만 타임아웃입니다.

브라우저 DNS와 IDE 스택이 달라서 흔합니다. 동일 호스트에 대해 Verge 로그 RULE 줄과 OS resolver 응답을 나란히 보고 fake-ip 교차 여부를 먼저 의심하세요.

로그 패널만 보고도 충분한가요?

첫 패스는 로그 줄로 충분한 경우가 많지만, 간헐적 타임아웃은 DNS fallback 지연과 겹칩니다. 짧은 윈도우에 두 번 재현해 동일 호스트인지 확인하세요.

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

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

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