증상이 왜 “간헐”로 보이는지

2026년 기준으로도 개발자 책상 위에서는 GitHub Copilot CLI와 MCP(Model Context Protocol) 같은 조합이 빠르게 늘었습니다. 그런데 현장에서 반복되는 질문은 비슷합니다. IDE 안에서는 대화가 되다가 터미널에서 같은 계정으로 로그인 교환만 막히거나, MCP가 붙었다 떨어졌다 하며 TLS 타임아웃·connection reset·401·403 같은 문자열이 한 번씩 튀어 나오는 패턴입니다. 브라우저로 GitHub는 열렸는데 CLI만 실패하면 사람들은 “Copilot이 망가졌다”기보다 프록시를 모르고 나가는 경로와 규칙이 붙은 경로가 갈라졌다고 보는 편이 훨씬 현실적입니다.

또 하나의 함정은 “어제는 됐는데 오늘은 첫 요청에서 끊긴다” 같은 DNS·노드·세션 교차 변수입니다. 회사 중간 장비나 지역 회선은 대상 호스트를 시간대별로 다르게 다루기도 하고, CLI가 IPv6 레코드를 먼저 잡았다가 중간 구간에서만 막히는 그림도 흔합니다. 이 글의 목표는 단 하나의 원인을 단정하지 않고, Clash Verge Rev를 중심으로 구독·프록시 그룹·규칙 모드·TUN·DNS를 한 흐름으로 묶어 개발자 프록시 경로를 재현 가능하게 만드는 것입니다. 특정 상용 서비스의 내부 정책까지 논하지 않고, 네트워크 레이어에서 설명 가능한 범위만 다룹니다.

왜 클라이언트 예로 Clash Verge Rev를 고르는가

Clash 계열 생태에는 여러 그래픽 셸이 있지만 Verge Rev 계열은 Windows·macOS·Linux에서 동일한 경험에 가깝고, Mihomo 코어와의 연동·구독 관리·TUN 토글·연결 패널까지 한 화면에 모이는 편입니다. “규칙 YAML만 잘 쓰면 된다”고 말하기는 쉬운데, 현실에서는 코어 로그와 연결 기록 문자열을 IDE 옆 작은 창에서 빠르게 확인할 수 있어야 디버깅이 돌아갑니다. Copilot CLI처럼 짧게 재시도하는 도구는 오류문을 스크롤하기도 전에 사라지기 때문에, UI에서 목적지가 어떤 규칙에 붙었는지 보이는 구조가 체감 난이도를 많이 낮춥니다.

다만 이 글은 특정 클라이언트 홍보가 아니라, 독자가 검색했을 때 “구독 넣고 끝”이 아니라 실제로 어떤 도메인 묶음이 DIRECT로 새는지를 확인하는 과정까지 포함한다는 뜻에서 예시를 고정했습니다. 다른 Clash UI를 쓰더라도 아래 단계의 레이블 이름만 바꾸면 거의 그대로 옮겨갈 수 있습니다.

CLI·MCP 트래픽이 흔히 새는 경로

많은 팀이 OS 설정에 시스템 프록시를 넣고 끝내지만, 터미널 프로세스는 그 힌트를 읽지 않습니다. Node·Go·Rust 등으로 빌드된 CLI는 자체 TLS 스택으로 직접 연결을 여는 경우가 많아서, 브라우저만 보고 “망은 정상”이라고 결론 내리면 하루 종일 같은 자리를 맴돌게 됩니다. MCP도 마찬가지입니다. 부모 프로세스가 VS Code 계열이면 확장이 만든 자식 프로세스에 환경 변수가 그대로 전달되기도 하고, 반대로 다른 IDE 래퍼에서는 빈 셸에서만 도는 경우도 있습니다. stdio MCP는 “표준 입출력 파이프”에 의존하므로, 부모 셀의 HTTPS_PROXY 유무가 곧 출구입니다.

HTTP 기반 원격 MCP는 호스트 문자열이 IDE와 다를 수 있습니다. 이 때도 동일하게 실제로 어떤 FQDN에 붙는지를 먼저 적어 두고, 그 문자열이 규칙 설계에 포함돼 있는지를 봐야 합니다. “Copilot”이라는 단어만 검색해서 규칙을 붙이기보다, 실패 로그에 찍힌 호스트 전체를 메모하는 습관이 장기적으로 규칙 품질을 지키는 데 더 낫습니다.

규칙 분기 설계에서 놓치기 쉬운 지점

실무에서 규칙 세트는 팀마다 다르지만, GitHub Copilot CLI 주변에서는 GitHub 본체·Microsoft 로그인·CDN·API 게이트웨이까지 묶음이 넓게 퍼집니다. 상위에 DIRECT로 빠지는 DOMAIN-SUFFIX 하나만 있어도, 브라우저는 엣지 캐시 덕에 “되는 것처럼” 보이는데 CLI만 끊기는 그림이 나옵니다. Clash Verge Rev의 연결 패널에서 해당 호스트가 어떤 정책 이름으로 매치됐는지 확인하면, “규칙 파일은 멀쩡한데 우선순위가 잘못됐다” 같은 단순 결론까지 빨리 갑니다.

개발자 프록시라는 표현을 쓰는 이유도 여기에 있습니다. 단순히 속도를 내는 VPN과 달리, 저장소·이슈·패키지 레지스트리·AI API가 섞인 업무 트래픽은 목적지마다 정책이 달라야 합니다. 국내 SaaS·사내 레지스트리는 DIRECT, 공용 클라우드 API는 특정 그룹, 로그인·Copilot 종단은 안정적인 우회 노드처럼 나누는 형태가 일반적입니다. GEOIP 기본값이 너무 공격적이면 국내 좌표까지 해외로 돌아가 지연이 커지고, 반대로 보수적이면 CLI만 계속 ISP 경로로 새는 부작용이 생깁니다.

TUN을 켜야 하는지, 시스템 프록시면 되는지

브라우저 위주 작업이라면 시스템 프록시와 규칙 모드만으로도 충분한 날이 많습니다. 그러나 CLI 로그인 실패가 반복되면 TUN 계층을 켜서 운영체제 스택 전체가 같은 규칙 엔진을 통과하게 만드는 편이 디버깅 비용을 줄입니다. 이해를 쉽게 하면 TUN은 “가상 어댑터 뒤에서 나가는 패킷을 한 번 더 걸러 내는 파이프”에 가깝고, 시스템 프록시는 “프록시를 아는 앱만 따라오는 힌트”에 가깝습니다. Copilot CLI처럼 힌트를 챙기지 않는 프로그램이 많을수록 전자가 유리합니다.

반대로 TUN을 켠다고 모든 문제가 사라지는 것은 아닙니다. DNS 모드와 fake-ip 조합이 어긋나면 패널에는 이상이 없어 보이는데 실제 접속 문자열만 다른 쪽으로 붙는 패턴이 생깁니다. 또 일부 보안 에이전트는 TUN과 충돌하기도 하니, 테스트는 가능한 한 작은 호스트 하나로 좁혀서 반복하는 것이 안전합니다.

Clash Verge Rev로 맞추는 실무 순서

로그 문자열·재현 조건을 먼저 적기

터미널 출력 전체를 그대로 복사해 두면 나중에 패턴 비교가 쉬워집니다. HTTP 코드인지 TCP 단계에서의 타임아웃인지, 아니면 인증 리다이렉트 루프인지에 따라 다음 행동이 갈립니다. 같은 명령을 네트워크가 조용한 시간대에 다시 실행해 보고, 회사 VPN 켜짐·끔 차이도 함께 적어 두세요.

# example: check GitHub API reachability from host
curl -sI --max-time 25 https://api.github.com/

구독·코어 상태 정리

구독이 오래됐거나 규칙 프로바이더가 갱신 실패한 상태면 우선순위가 꼬인 파일을 보고 있게 됩니다. Clash Verge Rev에서 구독 새로고침 후 코어 재시작까지 포함해 “파일 내용이 실제로 반영됐는지”를 확인합니다. 팀 표준이 있다면 fork 한 설정이 상위 정책을 덮어쓰지 않았는지도 같이 봅니다.

연결 패널로 종단 매칭 검증

실패가 나는 순간에 패널을 열어 목적지 호스트가 DIRECT로 떨어지는지, 의도한 프록시 그룹으로 붙는지 확인합니다. 여기서 처음 보는 서브도메인이 튀어 나오면 규칙 목록에 추가 후 다시 테스트합니다. “브라우저는 됐는데 CLI만 안 된다”는 말이 나오면 거의 항상 이 단계에서 설명이 시작됩니다.

TUN 토글과 권한

Windows는 관리자 권한, macOS는 네트워크 확장 승인 흐름이 따라옵니다. 켠 직후에는 작은 요청 하나로 TLS 헤더를 받아 보는 식의 저비용 테스트를 권합니다. 과한 대역폭 벤치마크보다 짧은 확인이 오히려 원인 레이블을 빨리 줍니다.

CLI·MCP에 환경 변수로 루프백 출구 맞추기

TUN이 켜져도 특정 바이너리가 우회를 타지 않는다면, 로컬 혼합 포트에 맞춰 환경 변수를 명시합니다. 숫자는 본인 환경의 mixed-port로 바꿉니다.

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7891

팀에서는 direnv나 작은 래퍼 스크립트로 위 값을 고정해 “셸마다 다른 출구” 문제를 줄이기도 합니다. MCP 부모 프로세스가 IDE라면, IDE가 띄운 통합 터미널에 값이 전달되는지까지 확인해야 재현이 사라집니다.

DNS·IPv6 교차 검증

IPv6 레코드가 먼저 잡혀 TLS만 멎는 패턴, fake-ip 때문에 매칭 문자열이 실제와 다른 패턴을 의식적으로 나눠 봅니다. DNS 모드를 바꿔 짧은 테스트를 여러 번 돌리면, “노드 문제인지 이름 해석 문제인지”가 분리됩니다.

MCP 운영 관점에서의 체크리스트

IDE가 MCP 서버 프로세스를 주기적으로 재시작하면 프록시 환경도 같이 초기화될 수 있습니다. 개발자 프록시 설정을 문서 한 줄로 남겨 두고, 신입 온보딩 때 셸 프로필과 IDE 통합 터미널을 동시에 맞추면 “내 컴퓨터만 간헐적” 이슈가 줄어듭니다. 원격 HTTP MCP는 허용 목록·mTLS·자체 CA 같은 추가 변수가 붙을 수 있으니, 네트워크 레이어에서 막힐 때와 인증 레이어에서 막힐 때를 로그 형태로 분리해 기록하세요.

자주 묻는 질문

Q. 브라우저 로그인은 되는데 Copilot CLI만 실패합니다. CLI가 시스템 프록시를 따르지 않아 DIRECT 경로로 나가는 경우가 흔합니다. 패널에서 GitHub·Microsoft 관련 호스트가 어디로 붙는지 확인하고 TUN 또는 환경 변수로 출구를 고정하세요.

Q. MCP는 어디에서 프록시를 물려받나요? stdio MCP는 부모 셸·IDE가 준 환경 변수를 그대로 씁니다. 원격 MCP는 별도 프로세스라면 해당 실행 환경까지 같이 봐야 합니다.

Q. TUN을 켜면 전체 앱이 느려지나요? 규칙 설계에 따라 다릅니다. 국내·사내 트래픽을 DIRECT로 두고 API만 우회하면 체감은 크게 나빠지지 않습니다.

정리하면

단순 VPN 한 줄을 켜서 “전부 해외로” 보내는 방식은 당장은 편해 보여도, 패키지 미러·사내 Git·모니터링 대시보드까지 같이 멀어져 체감 지연이 커지기 쉽습니다. 반면 Clash·Mihomo 생태는 도메인 단위 규칙과 TUN으로 패킷 경로를 한 규칙 엔진에 모으는 경험을 함께 제공해서, GitHub Copilot CLI·MCP처럼 프록시 힌트가 약한 도구에서도 원인을 패널 기준으로 설명할 여지가 생깁니다.

오래된 일부 클라이언트는 코어 업데이트·규칙 공급·연결 시각화가 느려, 같은 증상을 만나도 되돌아오는 시간이 김니다. 최신 Clash 계열 앱은 구독·지연 테스트·규칙 세트·TUN을 한 흐름에서 다루기 쉬워 반복 작업 중 끊김이 발생했을 때 실험 비용이 줄어듭니다. 내 환경에 맞는 빌드를 내려받은 뒤 이 글 순서대로 패널 확인과 환경 변수만 맞춰 보시면, “간헐”이라는 말 뒤에 숨은 경로 레이블을 훨씬 빨리 잡을 수 있습니다.

Clash 클라이언트 무료 다운로드 →