AI Relay 서비스의 계정 정지를 효과적으로 줄이는 방법

Wokey Team · 2026-06-27

모델 제공업체들이 최근 대규모 계정 정지를 단행했습니다. 범위가 너무 넓어 정상적으로 쓰던 개인 사용자까지 휘말렸습니다.

Relay 서비스를 운영하고 있거나 고르는 중이라면 진지하게 생각해 볼 문제입니다. 계정 정지는 운의 문제일까요, 아키텍처의 문제일까요?

제 답은 후자입니다. 계정 정지율은 무작위가 아니라 아키텍처가 결정합니다.

한발 물러서서 보겠습니다. 제공업체는 계정이 공유되거나 재판매되고 있는지 판단할 때 보통 다음 신호를 봅니다.

• IP 변화와 IP 유형 — 요청이 갑자기 주거용 IP에서 데이터 센터 IP로 바뀌거나, 여러 지역을 오갑니다.
• 행동 이상 — 호출 빈도, 동시 실행 수, 시간 분포가 분명히 한 사람의 것처럼 보이지 않습니다.
• 여러 계정이 출구를 공유 — 수십 개 계정의 요청이 같은 IP 묶음으로 몰려 나갑니다.
• 클라이언트 지문 이상 — 요청 헤더, TLS 지문, 기기 특성이 일반 클라이언트와 맞지 않습니다.

이런 신호가 쌓이면 제공업체의 위험 관리 시스템이 계정에 표시를 합니다.

그런데 어떤 신호가 가장 무겁고 가장 감지하기 쉬우냐고 묻는다면, 저는 IP라고 답하겠습니다.

이유는 간단합니다. IP는 가장 바깥에 있고 비용이 가장 적게 드는 선별 기준입니다. 주거용 IP에서 온 요청과 데이터 센터 IP에서 온 요청은 위험 관리 시스템의 눈에 완전히 다른 위험 등급입니다. 데이터 센터 ASN + IP 이동 + 지리적 이상, 이 세 가지가 함께 나타나면 위험 관리 시스템에 "이건 정상 사용자가 아니다"라고 말하는 것이나 다름없습니다.

솔직히 말해 기존 Relay 서비스의 아키텍처는 정확히 이 지뢰를 밟고 있습니다. 모든 요청이 Relay의 서버에서 나가고, 수십 개 계정이 같은 데이터 센터 IP 묶음을 공유합니다. 아무리 부하를 분산하고 프록시 풀을 교체해도 출구는 근본적으로 서버실입니다. 다른 Relay 운영자들의 방식도 살펴봤는데, 부지런히 프록시를 교체하지만 ASN을 조회해 보면 전부 클라우드 사업자입니다. 가면만 다를 뿐 얼굴은 같습니다.

그래서 Relay 서비스를 세 곳이나 옮겨 다녀도 가는 곳마다 2주마다 정지당하는 사람이 있는 것입니다. 운이 나빠서가 아니라 모든 서비스의 아키텍처가 같기 때문입니다.

그렇다면 IP를 바뀌지 않게 유지하려면 어떻게 해야 할까요?

개인 사용자라면 이미 자리 잡은 방법이 있습니다. 집의 NAS에 New API나 One API 같은 통합 게이트웨이를 배포하거나 sam-to-API 같은 도구를 써서, 모든 제공업체 API를 그곳을 거치게 하는 것입니다. 휴대폰, 노트북, 모델을 호출하는 어떤 클라이언트도 제공업체에 직접 접속하지 않습니다. 대신 집의 기기를 거치고, 그 기기가 제공업체 API로 전달합니다. 이렇게 하면 어떤 모델을 호출하든 제공업체가 보는 출구 IP는 항상 집 인터넷의 IP이며, 집에서 평소처럼 쓰는 것과 구별되지 않습니다.

밖에 있을 때는요? Tailscale이나 WireGuard 같은 메시 네트워크 도구로 휴대폰이나 노트북의 트래픽을 먼저 집 NAS로 돌린 다음 집에서 나가게 하세요. 카페에 있든, 사무실에 있든, 기차에 있든 요청은 여전히 집 인터넷에서 나갑니다. Wi-Fi를 바꾸거나 모바일 데이터를 켰다고 해서 제공업체가 IP 이동을 보게 되지는 않습니다.

이 방법은 fnOS 커뮤니티와 AI 셀프 호스팅 분야에서 충분히 검증되었고, 튜토리얼과 실천하는 사람도 많습니다. 개인 사용자에게는 현재 가장 믿을 만한 IP 고정 방법입니다.

하지만 이것은 한 사람의 문제만 해결합니다.

Relay 서비스는 수십에서 수백 명의 Provider 계정을 관리합니다. 한 사람 한 사람의 집에 찾아가 NAS를 설치하고 게이트웨이를 설정할 수는 없습니다. 각 Provider가 가벼운 노드를 설치해 플랫폼에 연결할 수 있는 체계적인 방법이 필요합니다. 요청은 여전히 Provider 자신의 네트워크에서 나가지만, 주문 배분과 트래픽 라우팅은 플랫폼이 중앙에서 처리합니다.

이 아키텍처를 Provider 측 출구라고 합니다. 요청이 Relay의 서버가 아니라 Provider 자신의 네트워크에서 나갑니다.

비유하자면 NAS 방식은 길가에 내 가게를 직접 여는 것과 같습니다. 집에서 발송하고, 매입, 상품 선정, 주문 처리를 모두 혼자 합니다. Provider Node는 플랫폼 가맹점에 가입하는 것과 같습니다. 여전히 집에서 발송하지만 주문은 플랫폼이 배정해 줍니다. 발송 주소는 그대로이고, 바뀌는 것은 누가 주문을 배정하느냐입니다.

이것이 Wokey Provider Node가 하는 일입니다.

설치는 간단합니다. 명령 하나로 끝나며 macOS, Linux, Windows, Docker를 지원합니다. 설치 후 로컬 콘솔을 열어 Wokey 계정을 연결하고 로컬 구독 자격 증명을 가져오세요. 노드가 시작되면 Wokey 플랫폼과 WebSocket 연결을 유지합니다. 플랫폼이 사용자 요청을 보내면 노드가 로컬에서 공급사 API로 요청을 보냅니다. 전체 과정이 Provider 자신의 IP에서 나가므로, 공급사가 보기에는 Provider가 자기 구독을 평소처럼 쓰는 것과 똑같습니다.

현재 지원하는 공급사는 OpenAI/Codex, Anthropic/Claude, Zhipu, Kimi, DeepSeek, Gemini, xAI 등입니다.

이 아키텍처를 직접 운영해 보고 가장 직관적으로 느낀 점은 이것입니다. 위험 관리와 "싸우는" 것이 아니라, 위험 감지의 전제 조건을 애초에 건드리지 않는다는 것입니다. 공급사가 보기에는 집에서 자기 구독을 쓰는 평범한 사용자일 뿐이며, 해명할 이상 징후가 전혀 없습니다.

프로젝트 전체가 Apache-2.0으로 오픈 소스이며, 출구 화이트리스트는 소스에 하드코딩되어 있습니다. 제가 그렇다고 말해서 안전한 것이 아니라, 모든 코드 한 줄 한 줄을 감사할 수 있기 때문에 안전합니다.

물론 Provider 측 출구가 계정 정지 0건을 보장한다고 말하지는 않겠습니다. IP는 정지 요인 중 하나일 뿐이며, 호출 빈도, 동시 실행 패턴, 시간 분포도 위험 관리를 작동시킬 수 있습니다. 정지율 0을 보장할 수 있는 방법은 없습니다.

하지만 논리는 분명합니다. 가장 큰 신호를 해결하지 않았다면 다른 모든 최적화는 모래 위에 짓는 집입니다.

계정 정지율을 낮추는 핵심은 사용 패턴을 정상과 구별할 수 없게 만드는 것입니다. IP를 바뀌지 않게 유지하는 것이 가장 중요한 부분입니다. 개인 사용자에게는 개인용 방법이 있고, Relay 서비스에는 체계적인 Provider 측 출구 방식이 필요합니다.

Relay 경쟁이 막바지에 이르면, 승부는 누가 모델이 더 많고 가격이 더 낮으냐가 아니라 누구의 아키텍처가 제공업체로 하여금 Relay임을 알아채지 못하게 하느냐에 달려 있을 것입니다. 지금 쓰고 있는 서비스는 누구의 네트워크에서 요청을 내보내고 있나요?