Firefly·Adobe CC 로그인 Clash DOMAIN-SUFFIX 분할

왜 “앱은 켜지는데 로그인·Firefly만 멈춤”인가

2026년 전후 여러 매체가 Adobe Creative Cloud 전반에 걸친 Firefly AI Assistant(또는 이에 준하는 크리에이티브 워크플로 어시스턴트) 공개·베타 소식을 다루면서, 사용자 입장에서는 “새 패널이 생겼다”는 인상과 함께 온라인 인증·API 호출 의존도가 한 번에 올라간 느낌을 받기 쉽습니다. 포토샵·일러스트 등 데스크톱 소프트웨어 본체는 로컬에 있어도, 구독 확인·자산 동기화·생성형 기능은 서로 다른 서브도메인으로 HTTPS 세션을 열고 끊습니다.

이 글은 Firefly 기능 자체를 평가하지 않고, 제한된 네트워크나 분할 규칙이 어긋난 Clash 환경에서 나타나는 대표 증상—로그인 화면의 무한 로딩, Creative Cloud 데스크톱 앱의 동기화 지연, 앱 내 Firefly 패널의 타임아웃—을 도메인 축으로 좁힌 뒤, Clash 분할과 DOMAIN-SUFFIX, 전략 그룹, DNS를 재현 가능한 순서로 맞추는 방법을 정리합니다. 범용 챗봇 웹만 다루는 글과 달리, 여기서는 Adobe 크리에이티브 스택에 초점을 둡니다. 웹 챗 분할 예시는 ChatGPT·Claude 분할 가이드와 겹치는 부분이 있으나 호스트 목록은 Adobe 쪽이 훨씬 넓고 잡음이 많습니다.

참고: 소속 기관·국가의 이용 약관과 네트워크 정책을 위반하는 우회는 하지 마세요. 본문은 합법적인 개인 환경에서의 연결 진단과 Clash 설정 절차를 다룹니다.

증상을 세 가지 축으로 나누기

먼저 증상을 한 문장으로 뭉뚱그리지 말고, 어느 단계에서 멈추는지로 나누면 원인 추적이 빨라집니다.

Adobe ID·브라우저 로그인: 브라우저 창이 뜬 뒤 리디렉션이 반복되거나, “잠시만 기다려 주세요”류의 문구에서 더 이상 진행되지 않습니다. 이 경우 OAuth·세션 쿠키가 걸린 호스트와 리다이렉트 체인이 핵심입니다.
Creative Cloud 데스크톱·백그라운드 동기화: 앱은 실행되지만 폰트·프리셋·라이브러리 동기가 멈추거나 오류 코드가 주기적으로 뜹니다. 여기서는 대용량 CDN과 메타데이터 API가 다른 경로로 나가는 경우가 많습니다.
Firefly·생성형 패널: 메뉴는 보이나 패널만 로딩에서 빠져 나오지 않거나, 특정 리전 노드에서는 항상 실패합니다. 이 축은 생성 API·추론 게이트웨이가 일반 웹과 다른 서픽스를 쓰는 경우가 잦습니다.

세 축이 동시에 터지면 “Adobe가 전부 망가졌다”로 보이지만, 실제로는 한 그룹의 호스트만 DIRECT에 남아 타임아웃이거나, 반대로 프록시 체인이 너무 길어 TLS 핸드셰이크만 실패하는 경우가 섞여 있습니다. 아래 단계는 이 세 축을 Clash 로그와 브라우저 개발자 도구로 분리해 보는 것에서 시작합니다.

1단계: 로그와 개발자 도구로 “누가 막혔는지” 모으기

Clash·Mihomo 계열 클라이언트에서 연결 로그를 켠 채로 문제를 재현하세요. 필터를 걸 수 있다면 adobe, ims, cc-api, firefly 같은 부분 문자열로 좁혀 봅니다. 동시에 브라우저 기반 로그인을 쓰는 경우 개발자 도구의 네트워크 탭에서 실패한 요청의 호스트 이름을 적어 두면, 이후 DOMAIN 규칙을 단 하나만 추가해도 되는지 판단하기 쉽습니다.

로그에 찍히는 이름이 something.adobe.com처럼 길게 반복된다면, 우선 DOMAIN-SUFFIX로 상위 존을 묶고 세부 예외를 나중에 두는 편이 관리에 유리합니다. 반면 cdn-xxx.example.com처럼 CDN 전용 호스트가 따로 보이면, 같은 SUFFIX로 묶기 전에 실제로 몇 개의 루트가 있는지부터 세어 보세요. 잘못 묶으면 다른 Adobe 서비스까지 한꺼번에 원치 않는 노드로 갈 수 있습니다.

2단계: 자주 관측되는 Adobe 관련 도메인 축(참고용)

Adobe는 제품·리전·A/B 테스트에 따라 호스트가 바뀔 수 있으므로, 아래는 고정 공식 목록이 아니라 분류용 힌트입니다. 최종 목록은 항상 본인 환경의 로그를 기준으로 잡아야 합니다.

계정·인증(IMS): adobe.com, adobe.io, adobelogin.com 계열과 이들 하위 호스트. 로그인 리디렉트가 여기를 오가다 멈추는 패턴이 흔합니다.
Creative Cloud 메타·구독 상태: cc-api-data.adobe.io 등 *.adobe.io API. 데스크톱 앱이 주기적으로 두드리는 엔드포인트가 이 축에 많습니다.
자산·동기화·CDN: 대용량 다운로드와 작은 메타 호출이 섞입니다. 지연만 길고 끊기지는 않는 경우 대역·버퍼 이슈에 가깝고, 아예 연결 실패면 경로(DIRECT vs PROXY) 이슈에 가깝습니다.
Firefly·생성형 워크플로: 제품 업데이트마다 서픽스가 늘 수 있으므로, 로그에 새로 뜬 firefly·generative·sensei 류 문자열을 우선 수집하세요.

한 번에 모든 adobe 문자열을 같은 그룹에 넣으면 간단해 보이지만, 결제·문서 포털까지 같은 노드로 보내고 싶지 않다면 전략 그룹을 둘 이상으로 쪼개는 편이 안전합니다. 예를 들어 “로그인 전용”과 “대용량 동기화 전용”을 나누면, 느린 노드 때문에 로그인만 실패하는 상황을 줄일 수 있습니다.

3단계: DOMAIN-SUFFIX와 전략 그룹 YAML 예시

이름은 예시이며, 구독 프로필에 맞게 바꿔 쓰세요. 위에서 아래로 먼저 매칭된 규칙이 이깁니다.

# Example only — replace PROXY-ADOBE-* with your policy-group names
proxy-groups:
  - name: PROXY-ADOBE-AUTH
    type: select
    proxies: [REJECT, DIRECT, YOUR-NODE-A, YOUR-NODE-B]
  - name: PROXY-ADOBE-CC
    type: select
    proxies: [DIRECT, YOUR-NODE-A, YOUR-NODE-B]

rules:
  - DOMAIN-SUFFIX,adobelogin.com,PROXY-ADOBE-AUTH
  - DOMAIN-SUFFIX,adobe.io,PROXY-ADOBE-CC
  - DOMAIN-SUFFIX,adobe.com,PROXY-ADOBE-CC
  - DOMAIN-KEYWORD,firefly,PROXY-ADOBE-CC

DOMAIN-KEYWORD는 편하지만 과매칭 위험이 있으므로, 로그로 범위를 확인한 뒤 가능하면 DOMAIN-SUFFIX와 DOMAIN 조합으로 좁히는 것이 좋습니다. GEOIP나 MATCH가 파일 상단에서 너무 많은 트래픽을 먹어 버리면 아래 Adobe 규칙이 실행되지 않습니다. 규칙 전체 순서를 출력해 검토하는 방법은 규칙 분할 라우팅 가이드와 TUN 모드 가이드를 함께 참고하세요. TUN을 켠 상태에서만 데스크톱 앱 트래픽이 Clash를 타는 경우가 많습니다.

4단계: DNS·fake-ip와 인증 세션

로그인은 DNS 응답과 실제 TCP 경로가 어긋나면 같은 증상을 냅니다. fake-ip를 쓰는 프로필이라면, Adobe 관련 도메인이 fake-ip-filter나 동등한 예외 목록에 들어 있는지, 혹은 반대로 불필요하게 예외 처리되어 국내 DNS로만 해석되고 있는지 확인하세요. 브라우저에서 열리는데 앱만 실패하면, 앱이 시스템 DNS를 직접 쓰는지·DoH를 박아 두었는지도 함께 봅니다.

터미널에서 dig나 OS 도구로 동일 호스트를 조회해, Clash DNS를 경유했을 때와 경유하지 않았을 때의 응답이 다른지 비교해 보세요. 응답이 제3국으로 새면 엣지 서버 선택이 바뀌어 Firefly 패널이 기대한 리전과 어긋날 수 있습니다. 이때는 “무조건 빠른 노드”보다 세션 일관성이 나은 노드를 고르는 편이 낫습니다.

5단계: 노드 선택과 TLS 지연

Firefly류 기능은 짧은 텍스트 요청이 아니라 긴 세션·스트리밍형 응답을 쓰는 경우가 있어, 핑만 낮고 패킷 손실이 큰 회선에서는 중간에 끊깁니다. 전략 그룹 안에서 두세 개 노드를 번갈아 고른 뒤, 동일한 재현 절차(같은 프로젝트 파일 열기, 같은 패널 열기)를 반복해 보세요. 한 노드에서만 TLS 핸드셰이크가 반복 실패하면 해당 POP를 피하는 것이 맞습니다.

회사망에서는 SSL 검사 때문에 클라이언트 인증서 체인이 깨지는 경우도 있습니다. 이 경우 Clash 규칙만으로는 한계가 있으므로, IT 정책 허용 범위 안에서 해결해야 합니다.

6단계: 실측 체크리스트

Clash에서 로그를 켜고 Creative Cloud 앱을 완전히 종료한 뒤 다시 실행해 동기화를 유발합니다.
로그인·Firefly를 재현하고, 실패 직전에 반복되는 호스트 이름을 목록으로 옮깁니다.
해당 호스트마다 DIRECT와 PROXY를 번갈아 적용해 보고, 어느 쪽에서 타임아웃이 사라지는지 기록합니다.
확정된 SUFFIX를 전용 전략 그룹에 묶고, 규칙 순서에서 상위의 광역 규칙과 충돌하지 않게 조정합니다.
DNS 모드·fake-ip·TUN을 한 번에 바꾸지 말고, 한 변수씩 바꿔 가며 동일 시나리오를 반복합니다.

팁: 구독 제공자가 배포한 “Adobe 스트리밍” 류의 고정 규칙 세트가 있다면 출발점으로 쓰되, Firefly 어시스턴트처럼 새로 추가되는 호스트는 자동 목록보다 로그 기반 패치가 빠른 경우가 많습니다.

한계와 오해

Clash는 트래픽 경로를 바꾸는 도구일 뿐, Adobe 계정 자체의 잠금·결제 실패·베타 자격을 고쳐 주지는 않습니다. 웹 대시보드에서는 정상인데 앱만 실패하면 앱 캐시·키체인·오래된 세션 토큰 문제일 수도 있으므로, 네트워크 조정과 병행해 공식 트러블슈팅도 확인하세요.

주의: 출처가 불분명한 “완성 규칙 세트”를 그대로 붙여 넣으면, 예상치 못한 도메인까지 프록시로 보내져 보안·성능 문제를 일으킬 수 있습니다. 반드시 로그로 검증하세요.

정리

Firefly 같은 클라우드 어시스턴트가 붙으면 Adobe Creative Cloud 전체가 “로컬 앱 하나”가 아니라 여러 HTTPS 축으로 쪼개져 동작합니다. 증상을 로그인·동기화·패널로 나누고, Clash에서 DOMAIN-SUFFIX와 전략 그룹·DNS를 순서대로 맞추면 재현과 해결이 훨씬 수월합니다. 범용 LLM만 다룬 분할 글과 달리 이 글은 크리에이티브 소프트웨어 구독 맥락에 맞춘 호스트 수집에 초점을 두었습니다.

규칙 표현과 커널 옵션이 유연한 편인 Clash·Mihomo는, 한 번 경로가 안정되면 이후 미세 조정을 반복하기 좋습니다. 반대로 말하면 초기에 로그를 제대로 모으지 않으면 같은 증상을 반복하게 됩니다.

동일한 환경에서 바로 실험해 보시려면 Clash를 무료로 다운로드한 뒤, TUN 또는 시스템 프록시로 앱 트래픽이 실제로 클라이언트를 통과하는지 먼저 확인하고 본문의 체크리스트를 적용해 보시길 권합니다.