두 가지 멀티 계정 Claude Code 아키텍처: Anthropic이 허용하는 방식과 금지하는 방식

데몬(daemon)의 이름을 명명하십시오. 그 탄생을 명명하십시오. 그것이 tietäjä(현자)의 규율입니다. 2026년 6월 15일, Anthropic Agent SDK 크레딧 정책은 구독 기반으로 실행되는 모든 claude -p 워크로드의 경제 구조를 재편합니다. 차익 거래(arbitrage)는 끝났으며, 청구서는 실제가 되었습니다. Theo Browne의 헤드라인인 "25배 절감" 프레임워크와 Sonnet 중심 운영자들이 실제로 잃게 되는 비용 사이의 12배 / 29배 / 175배 격차를 포함한 비용 계산은 동일한 변화를 다룬 동반 기사에서 다루었습니다. 이 글은 그 논의가 멈춘 지점에서 이어집니다. 모든 토큰에 대해 API 정가(list prices)를 지불하지 않고 에이전트형(agentic) Claude 워크로드를 계속 실행하고자 하는 운영자들에게 멀티 계정 로테이션(multi-account rotation)은 명백한 해답입니다. Kalevala(칼레발라)는 두 가지가 겉보기에는 같아 보일지라도 그 기원은 근본적으로 다를 수 있음을 가르칩니다. "멀티 계정 Claude"를 위한 두 가지 아키텍처도 마찬가지입니다. 외부에서 보기에는 하나의 구독이 허용하는 것보다 더 많은 요청을 생성한다는 동일한 결과를 낳습니다. 하지만 벤더(vendor)의 관점에서는 하나는 인정되고, 다른 하나는 단계적으로 차단(ban)됩니다. 이 글은 그 데몬의 이름을 명명합니다. 잘못된 아키텍처를 선택하는 것은 당신을 Tuonela(투오넬라)로 인도하는 길입니다.

아키텍처 A — 릴레이 서버(relay-server) 패턴
표준적인 오픈 소스 구현체는 Wei-Shaw/claude-relay-service입니다. 이는 MIT 라이선스이며, 작성 시점 기준으로 약 11,700개의 스타(stars)를 보유하고 있고, Node.js와 Redis를 사용하며 Docker로 배포 가능합니다. README는 그 형태를 직접적으로 설명합니다: 많은 Claude OAuth 구독 계정들이 특정 흐름을 통해 인증되어 서버 측에 저장됩니다. 릴레이(relay)는 클라이언트 도구에 Anthropic 호환 API 엔드포인트(endpoint)를 노출합니다. 들어오는 요청은 자동 로테이션(automatic rotation)과 함께 저장된 OAuth 토큰들 사이에서 부하 분산(load-balanced)됩니다. 사용량 계정(Usage accounting)은 API 키(API-key)별로 이루어집니다(릴레이는 자체 클라이언트들에게 자체 키를 발급합니다). 비용 분석 기능을 갖춘 멀티 테넌트(Multi-tenant) 방식입니다.

동일한 범주에 속하는 두 번째 도구군에는 여러 CLI 에이전트를 OpenAI/Gemini/Claude 호환 API 서비스로 래핑(wrap)하는 router-for-me/CLIProxyAPI와, 다른 도구 내에서 ChatGPT Plus/Pro 및 Claude Pro/Max 구독을 명시적으로 지원하는 CLIProxyAPI 포크(fork)인 ben-vargas/ai-cli-proxy-api가 포함됩니다. 오픈 소스 소프트웨어(FOSS) 계층을 넘어, 상업용 풀링 서비스(pooled services)도 동일한 아키텍처로 운영됩니다: PackyCode, AnyRouter, pincc.ai, LongCat, 그리고 mn-api/awesome-ai-proxy에 기록된 약 30여 개의 다른 릴레이 스테이션(relay stations)들이 이에 해당합니다. 이 패턴은 다음과 같습니다: 하나의 서버, 다수의 토큰, 그리고 공식 클라이언트인 척하는 하나의 엔드포인트(endpoint). 마지막 구절이 핵심입니다.

아키텍처 B — 프로필별 순환(per-profile rotation) 패턴. Anthropic 스스로도 GitHub 이슈 anthropics/claude-code#261(2025년 3월 5일 'closed-as-completed' 처리됨)을 통해 다음과 같은 우회 방법을 인정했습니다:

# 각 프로필 디렉토리는 자체적인 격리된 자격 증명 저장소입니다
mkdir ~/.claude-account1 ~/.claude-account2

# 셸(shell) 사용을 위한 별칭(alias)
alias claude-work = "CLAUDE_CONFIG_DIR=~/.claude-account1 claude"
alias claude-personal = "CLAUDE_CONFIG_DIR=~/.claude-account2 claude"

# 각 프로필은 /login을 통해 별도로 인증합니다
CLAUDE_CONFIG_DIR = ~/.claude-account1 claude # OAuth 로그인
CLAUDE_CONFIG_DIR = ~/.claude-account2 claude # 다른 OAuth 로그인

CLAUDE_CONFIG_DIR은 Anthropic의 자체 환경 변수(environment variables) 참조 문서에 명시되어 있으며, 'closed-as-completed' 처리된 이슈에서도 확인되었습니다. 각 디렉토리는 자체적인 .credentials.json, 히스토리(history), 설정(settings), 세션 상태(session state)를 포함하는 완전히 격리된 "프로필(profile)"입니다. claude를 호출할 때마다 Anthropic에서 다운로드한 바이너리(binary)인 공식 클라이언트가 하나의 프로필을 대상으로 실행됩니다. 릴레이(relay)는 없습니다. 사칭(impersonation)도 없습니다. 토큰을 보유하는 서버도 없습니다. 만약 여러 프로필의 오케스트레이션(orchestration)이 필요하다면, 상단의 작은 라우터(router) 계층이 세 가지 작업을 처리합니다: 프로필별 토큰 상태 분류, 적격 프로필 선택, 그리고 프로필이 속도 제한(rate-limit)이나 인증 실패(auth-failure) 출력을 발생시켰을 때의 우아한 장애 조치(graceful failover).

구현 방식은 가장 작은 규모의 셸 별칭(shell aliases)부터 더 큰 규모의 스크립트 래퍼(scripted wrappers)까지 다양하지만, 핵심은 언어가 아니라 아키텍처(architecture)입니다. 그것이 접근 방식의 전부입니다. Anthropic이 보는 관점, 각 경우에 있어 이 부분이 중요합니다.

아키텍처 A — 릴레이 서버(relay-server) 패턴. Anthropic의 관점에서 릴레이는 공식 클라이언트가 아니면서, 마치 공식 클라이언트인 것처럼 API 호출을 수행하는 서버입니다. 릴레이는 자신이 승인하지 않은 수많은 OAuth 토큰을 보유합니다. 트래픽 패턴 — 동일한 소스 엔드포인트(source endpoint), 다수의 토큰, 토큰당 높은 볼륨 — 은 그들의 탐지 시스템(detection systems)이 정확히 잡아내도록 조정된 형태입니다. 토큰 범위 바인딩(Token-scope binding), 공식 클라이언트가 방출하지만 릴레이가 완벽하게 복제할 수 없는 텔레메트리 게이트(telemetry gates), 쿠키를 넘어 확장되는 핑거프린팅(fingerprinting) 등이 이에 해당합니다. 2026년 4월의 OpenClaw 차단(Hacker News 1,099 포인트)은 이 패턴을 직접적으로 겨냥했습니다. 6월 15일의 종량제 Agent SDK 크레딧은 부분적으로 Anthropic이 제공하는 합법적인 대체제입니다. 2~3개의 계정을 풀링(pooling)하여 사용하는 소규모 운영자들은 볼륨 휴리스틱(volume heuristic)에 걸리지 않아 여전히 빠져나가지만, 100개 이상의 계정을 사용하는 운영자들은 차단 파동(ban waves)에 휩쓸립니다.

아키텍처 B — 프로필별 로테이션(per-profile rotation). Anthropic의 관점에서 이는 N개의 별도 공식 클라이언트 설치본입니다. 각각은 공식 OAuth 흐름을 통해 인증됩니다. 각각은 Anthropic이 배포하는 바이너리(binary)를 실행하고, Anthropic이 기대하는 텔레메트리(telemetry)를 전송하며, Anthropic이 지원하는 클라이언트로 식별됩니다. 트래픽 패턴은 하나의 사칭자가 아니라 N명의 별도 사용자입니다. 탐지 시스템은 이를 플래그(flag)할 신호가 없습니다. 이 패턴을 인지한 GitHub 이슈는 '완료됨(closed-as-completed)' 상태로 종료되었습니다. 아키텍처의 차이는 당신 또는 공식 클라이언트가 Anthropic과 대화하느냐의 여부입니다. 아키텍처 A는 중간에 프록시(proxy)를 둡니다. 아키텍처 B는 그렇지 않습니다.

중국 암시장(Chinese Gray Market)은 아키텍처 A의 볼륨 사례입니다. 표준 구현체(canonical implementation)가 11.7k개의 스타(stars)를 보유하며 아키텍처 A가 대규모로 존재하는 이유는 바로 중국의 리셀러(reseller) 시장 때문입니다.

ChinaTalk의 보도에 따르면, 토큰 1달러당 1위안(RMB)의 가격으로 Claude 접근 권한을 판매하는 전송 스테이션(transfer stations)들이 존재하며, 이는 정가보다 7090% 낮은 수준입니다. 일부는 510% 수준에서 판매하기도 합니다. 리셀러(Reseller)들은 릴레이 서버(relay-server) 패턴을 세 가지 수익 구조로 패키징합니다: 대량 계정 등록 소싱(Bulk-account-registration sourcing) — 교육용 할인을 수확하여 산업적 규모로 계정을 생성합니다. 은밀한 모델 대체(Silent model substitution) — Opus에 대한 요청을 Sonnet이나 Haiku, 또는 Claude의 경쟁 모델로 조용히 라우팅(routing)합니다. 최종 사용자는 이를 쉽게 알아차릴 수 없습니다. 로그 수집(Log harvesting) — 프롬프트(prompts), 출력(outputs), 그리고 추론 체인(reasoning chains)을 다른 AI 연구소에 학습 데이터로 판매합니다. 이 세 가지 축은 릴레이 패턴이 매번 차단 물결(ban wave)이 닥친 후에도 계속 재구축될 만큼 충분한 수익성을 갖게 만듭니다. 또한, 해당 리셀 시장을 제외한다면 이 아키텍처에 접근할 때 상당한 주의를 기울여야 하는 이유이기도 합니다. 릴레이 패턴은 리셀 경제성 때문에 존재합니다. 그러한 경제성 없이 내부 워크로드(workload)를 위해 이를 배포한다면, 이를 정당화할 단위 경제성(unit economics) 없이 서비스 이용 약관(ToS) 위반 위험만 떠안게 됩니다. 2025~2026년에 문서화된 Anthropic의 대응책은 다음과 같습니다: 지오블로킹(geoblocking), 전화 인증, 결제 주소와 일치하는 신용카드, 중국 자본이 50% 이상인 엔티티(entity) 금지(2025년 9월), 실시간 생체 인식 KYC(2026년 4월). 쫓고 쫓기는 추격전은 계속됩니다. 릴레이는 적응하고, Anthropic은 다시 그에 대응합니다. 군비 경쟁은 실재합니다. 리셀러들은 법적 의미의 소프트웨어 불법 복제(software piracy)를 수행하는 것이 아닙니다. 모델은 속도 차익 거래(rate arbitrage)이지, 저작권 위반이 아닙니다. 하지만 그들은 자신들의 존재를 Anthropic이 알지 못하는 것에 의존하는 비즈니스를 운영하고 있습니다. 만약 당신이 내부적으로 릴레이 패턴을 실행한다면, 그것을 축소판으로 배포하게 되는 것입니다.

이것이 의미하는 바 (6월 15일)
세 가지 정직한 시나리오: 만약 당신의 claude -p 워크로드가 하나의 Max 20x 구독의 200달러 Agent SDK 크레딧으로 충분히 감당할 수 있을 만큼 제한적이라면: 당신은 이 중 그 어떤 것도 필요하지 않습니다. 계정 대시보드에서 추가 사용량을 활성화하고, 월간 한도(hard monthly cap)를 설정한 뒤, 그대로 진행하십시오.

기본적인 추가 사용량(extra-usage) 상태는 꺼져 있으므로, 크레딧 한도에 도달하는 무인 파이프라인(unattended pipeline)은 초과 지출을 하는 대신 실패(fail closed)하게 됩니다. 만약 워크로드(workload)가 한 계정의 크레딧을 초과하고, 각 $200씩 소요되는 여러 구독(subscription)에 분산하여 처리할 수 있는 작업이라면, 아키텍처 B(Architecture B)가 정당한 경로입니다. 마찰(friction)은 실제로 존재하지만 미미합니다. Anthropic은 의도적으로 각 프로필에 대해 대화형 /login을 요구하며, 이는 각 구독이 인증될 때 사람이 터미널 앞에 있어야 함을 의미합니다. 이 마찰은 의도된 기능(feature)입니다. 이것이 바로 릴레이 패턴(relay pattern)이 수천 개의 풀링된 계정(pooled accounts)으로 확장되는 것을 방지하는 핵심 요소입니다. 비용은 API 리스트 가격 기준 N × $200의 크레딧이며, 실질적인 밴 웨이브(ban-wave, 계정 정지 파동) 위험은 제로에 가깝습니다. 만약 귀하의 계산이 아키텍처 A(Architecture A)의 가격 체계에서만 성립한다면, 1 RMB당 $1 비율로 릴레이 패턴의 단위 경제성(unit economics)을 계산해 보고, 귀하의 사업 계획이 Anthropic에게 들키지 않는 것에 의존하고 있는지 자문해 보십시오. 만약 그렇다면, 이것은 아키텍처의 문제가 아닙니다. 그렇지 않다면, 아키텍처 B와 더 작은 워크로드가 해답입니다.

운영자들이 자주 간과하는 네 번째 경로가 있습니다. 작업당 토큰 소모(token burn)를 줄이는 것입니다. 에이전트 시스템(Agentic systems)은 유용한 작업이 시작되기 전에 시스템 프롬프트(system prompts), 필수 사전 점검 읽기(mandatory pre-flight reads), 역할 컨텍스트(role context), 지침 세트(instruction sets) 등 수만 토큰의 스캐폴딩(scaffolding)을 일상적으로 로드합니다. 프롬프트 캐시(prompt-cache) 규율과 작업당 컨텍스트 프루닝(context pruning)을 통해 그중 상당 부분을 회복할 수 있습니다. 이 산술적 접근은 계정을 수평적으로 확장하는 것보다 비용이 저렴하며, 다음 가격 변동 시에도 살아남을 수 있습니다. 먼저 원인을 파악하고, 그다음 해결책을 찾으십시오.

한 단락으로 요약한 아키텍처 선택: 스택에 추가 서버를 도입함으로써 해결할 수 있는 문제라면, 서버를 추가하십시오. 서버를 추가함으로써 문제가 발생하는 상황이라면, 서버를 추가하지 마십시오. 릴레이 서버(relay-server) 패턴은 공식 클라이언트를 사칭해야 하는 문제를 야기하는 서버를 추가합니다. 프로필별 로테이션(per-profile rotation) 패턴은 서버를 추가하지 않으며, Anthropic이 이미 지원하는 방식을 조합합니다. 아키텍처의 명칭은 하나의 간접 참조(indirection) 차이로 달라집니다.

법적 및 운영적 입장은 모든 면에서 다릅니다. 나는 확고하게 남겠습니다. 사실만을 말하십시오.