브라우저와 달리 Mac 앱이 깨지기 쉬운 이유

Safari·Chrome에서 Gemini를 열었을 때와, Gemini Mac 앱을 실행했을 때의 네트워크 경로는 같아 보여도 다를 수 있습니다. 브라우저는 대개 시스템 프록시를 따르고, 앱 번들은 자체 HTTP 스택·인증서 고정·백그라운드 동기 태스크를 가져 프록시 우회나 다른 DNS 해석 경로를 탈 수 있습니다. Clash를 시스템 프록시만으로 켠 상태에서 앱 프로세스가 직접 소켓을 열면, 사용자는 「같은 노드인데 웹만 된다」고 느낍니다. 이때 TUN 모드로 커널 라우팅에 얹어 경로를 통일하는 접근이 자주 쓰입니다.

또 한 가지는 호스트 단위 분류입니다. 로그인 한 번에 accounts.google.com·oauth2.googleapis.com·www.googleapis.com·gstatic.com·앱 전용 하위 도메인이 섞입니다. 규칙 테이블에서 일부만 GOOGLE_APP 같은 그룹에 들어가고 나머지가 DIRECT에 남으면 TLS 핸드셰이크가 서로 다른 출구로 나가며, UI는 무한 로딩처럼 보입니다. 원인을 빠르게 가리려면 연결 로그의 timeout·TLS 패턴을 먼저 읽는 습관이 필요합니다.

ℹ 관측 우선: 앱에서 로그인을 재현한 뒤 Clash 라이브 연결 화면에서 호스트별 정책 적중을 확인하세요. 브라우저 DevTools만으로는 앱 백그라운드 요청이 다 보이지 않을 수 있습니다.

로그인·동기·업데이트에 자주 등장하는 Google 이름 공간

아래 목록은 형태를 보여 주는 출발점이며, 실제 배포·AB 테스트·지역 엣지에 따라 바뀔 수 있습니다. 운영자는 YAML 주석에 「어느 날 어떤 호스트를 DevTools·앱 로그·Clash 로그로 확인했는지」를 남겨 두면 이후 갱신이 쉬워집니다.

웹 중심으로 이미 정리해 둔 Gemini·Google AI Studio 분류 글의 generativelanguage.googleapis.com 묶음은 여전히 유효하지만, Mac 앱은 브라우저보다 OAuth·gstatic 비중이 커질 수 있어 규칙 폭을 조정해야 합니다.

정책 그룹 설계: GOOGLE_APP 한 덩어리 vs API·CDN 분리

한 덩어리로 묶는 경우

운영 단순성을 우선하면 GOOGLE_APP 하나에 UI·API·OAuth·CDN을 모두 넣고, 뒤에는 장시간 HTTPS에 강한 노드를 두는 방식이 있습니다. 단점은 범위가 넓어질수록 의도하지 않은 Google 트래픽까지 같은 출구로 가는 부작용이 생길 수 있다는 점입니다. 그래도 「로그인만 빨리 살리자」는 초기 대응으로는 실용적입니다.

API와 CDN을 나누는 경우

GOOGLE_API와 GOOGLE_CDN처럼 나누면 원인 분리는 쉬워지지만, 둘 다 같은 엄격도로 유지하지 않으면 한쪽만 느려져 다시 스피너가 납니다. 분리했다면 규칙 순서와 규칙 분류 모범 사례에서 말하는 매칭 우선순위를 함께 문서화하세요.

어떤 클라이언트가 로그를 잘 보여 주는지는 Clash 클라이언트 선택에서도 이어집니다. 앱 트래픽은 호스트명이 빠르게 바뀌므로, GUI에서 복사해 YAML에 붙여 넣는 루프가 짧을수록 좋습니다.

최소 예시 YAML과 규칙 세트 운영

아래는 시작용 조각입니다. 본인 환경에서 관측한 호스트를 덧붙이고, 불필요하게 넓은 DOMAIN-SUFFIX,google.com 한 줄로 모든 Google 웹을 끌어오는 실수는 피하세요. 대신 확인된 호스트를 DOMAIN으로 명시하고, 반복되는 패턴만 DOMAIN-SUFFIX,googleapis.com처럼 트리 단위로 덮는 편이 예측 가능합니다.

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,googleapis.com,GOOGLE_APP
  - DOMAIN-SUFFIX,gstatic.com,GOOGLE_APP
  - DOMAIN-SUFFIX,googleusercontent.com,GOOGLE_APP
  - DOMAIN,accounts.google.com,GOOGLE_APP
  - DOMAIN,oauth2.googleapis.com,GOOGLE_APP
  - GEOIP,KR,DIRECT
  - MATCH,DIRECT

엔드포인트 변화가 잦으면 손으로만 유지하기 어렵습니다. 규칙 세트(원격 RULE-SET)를 쓰더라도 공급자는 신뢰 자산이며, 광범위한 세트가 직접 적은 세밀 규칙을 가릴 수 있습니다. 갱신 URL 자체도 안정 출구가 필요하므로, 구독·노드 운영 흐름은 구독·노드 유지보수 가이드와 같은 맥락으로 보시면 됩니다.

TUN·시스템 프록시·Meta DNS·DoH를 같이 맞추기

앱이 시스템 프록시를 무시하면 DNS만 Clash로 가고 TCP는 다른 길로 나가는 불일치가 생깁니다. Clash Meta DNS nameserver·fallback·fake-ip 설정을 정리한 뒤, TUN으로 애플리케이션 소켓을 같은 스택에 얹었는지 확인하세요. macOS에서 시스템 확장·다른 VPN과 겹치면 라우팅 표가 바뀌어 로그인만 실패하는 일이 있어, macOS TUN·시스템 확장·프록시 충돌 절차로 먼저 정리하는 편이 빠른 경우가 많습니다.

브라우저나 OS 전역 DoH가 Clash의 DNS hijack과 경쟁하면 이름은 빨리 풀렸는데 정책 적중이 엇갈리는 패턴이 납니다. 가능하면 한 기기 안에서 누가 권위 DNS인지를 하나로 줄이고, 변경 후에는 앱을 완전히 종료했다가 다시 열어 세션을 초기화하세요.

Clash를 종료한 뒤에도 시스템 프록시 잔류로 사이트가 안 열리면 Clash 종료 후 인터넷 복구 절차로 macOS 쪽 프록시 토글을 점검합니다. 로그인 문제와 증상이 비슷해 착각하기 쉽습니다.

검증: 연결 로그 키워드와 체크리스트

재현 시나리오를 고정하세요. 예: 앱을 완전히 종료 → Clash 프로필 적용 → 앱 실행 → Google 계정 로그인 버튼 탭까지 동일한 순서. 그다음 아래를 순서대로 확인합니다.

  1. 라이브 연결에서 googleapis.com·gstatic.com·accounts.google.com이 모두 기대한 정책 이름으로 찍히는지.
  2. 동일 시각에 DIRECT와 프록시가 섞여 나오는 호스트가 있는지 — 있으면 규칙 구멍 후보입니다.
  3. timeout·TLS 로그가 정책 문제인지 노드 품질 문제인지 — 정책이 맞는데도 지연만 크면 노드 교체 쪽으로 이동합니다.
  4. 규칙 세트를 갱신한 직후에만 깨졌다면, 세트 삽입 위치와 광고 차단 목록 등 넓은 RULE-SET이 Google 호스트를 가로막지 않는지 diff합니다.

변경 이력을 YAML 주석이나 팀 위키에 한 줄이라도 남기면, 며칠 뒤의 자신이 고마워합니다. 「2026-04-22, 라이브 로그에 oauth2.googleapis.com이 DIRECT로 나와 DOMAIN 규칙 추가」처럼 적으면 됩니다.

준수와 한계

⚠ 준수 알림: 현지 법령·Google 서비스 약관·고용주·학교의 네트워크 정책을 준수하세요. 본문은 허용된 환경에서 라우팅 위생을 설명하며, 무단 접근·보안 통제 우회를 조장하지 않습니다.

기업망·캠퍼스는 SSL 검사·강제 프록시·호스트 화이트리스트를 둘 수 있어, 개인 YAML만으로는 동일하게 재현되지 않을 수 있습니다. 기술적으로 가능하다고 해서 정책상 허용되는 것은 아니니, 제한이 있으면 IT 절차를 따르는 것이 안전합니다.

맺음말

Gemini Mac 앱 로그인 스피너는 종종 「단일 서버 장애」가 아니라 Google API·CDN·OAuth가 서로 다른 출구로 흩어졌을 때 드러납니다. Clash에서는 이를 도메인 분류와 규칙 세트로 서술하고, TUN과 DNS까지 같은 이야기로 맞출 때 체감이 좋아집니다. 브라우저 중심 가이드와 중복되지 않게, 이번 글은 데스크톱 앱 트래픽에 초점을 맞춰 호스트 지도와 검증 순서를 달리했습니다.

다른 생성형 AI 앱도 프로세스 경로는 비슷한 패턴을 보이므로, 한 번 정리해 둔 관측 루프는 그대로 재사용할 수 있습니다. 다만 호스트명은 제품마다 다르므로 규칙을 통째로 복사하지 마세요.

→ Clash를 무료로 다운로드하고, 로그인 스피너 뒤에 숨은 호스트 불일치를 줄여 보세요.