Claude 암시장 프록시 해설: API 90% 할인보다 먼저 봐야 할 것은 프록시가 아니라 로그·비밀·증류 경계다

발행일: 2026-05-10 | 카테고리: 개발정보

1) 한 줄 문제 정의

핵심 요약: 해외 모델을 우회 프록시로 싸게 쓰는 순간, 비용 절감이 아니라 데이터 유출·모델 증류·품질 사기 문제가 동시에 시작됩니다.

AI타임스는 2026년 5월 10일 중국의 이른바 ‘중계소(transfer station)’ 시장에서 Claude API 접근권이 공식 가격의 10% 수준으로 재판매되고 있다고 보도했습니다. 겉으로 보면 이슈는 가격 차이처럼 보이지만, 실무 관점에서 더 큰 문제는 개발자의 프롬프트, 응답, 코드 조각, 인증 구조, 내부 문서 문맥이 모두 제3자 프록시 서버를 지나간다는 점입니다.

이 글은 Claude, GPT, Gemini 같은 해외 프론티어 모델을 업무 자동화·코딩 에이전트·분석 도구에 붙이는 개발팀, 제품팀, 보안 담당자를 위한 해설입니다. 범위는 프록시 경제가 왜 생겼는지, 왜 단순 약관 위반이 아니라 운영 리스크인지, 팀이 지금 어떤 차단 기준을 문서화해야 하는지입니다. 반대로 개인 취미용 테스트만 하고 민감한 입력을 넣지 않는 경우까지 모든 상황을 같은 위험도로 보자는 글은 아닙니다.

2) 먼저 결론

핵심 요약: 팀이 통제하지 않는 프록시를 통해 모델을 쓰는 것은 ‘저렴한 API 대체재’가 아니라 ‘외부 로그 수집기’에 내부 업무를 넘기는 행동에 가깝습니다.

• 지금 바로 금지해야 할 팀: 코딩 에이전트, 고객 데이터, 사내 문서, 인증 토큰, 비공개 로드맵이 프롬프트에 섞일 수 있는 팀
• 조건부 허용이 가능한 경우: 완전히 공개된 데이터만 다루고, 출력 신뢰도보다 실험 속도가 중요한 비업무성 테스트
• 제 판단: 이번 사안의 핵심은 ‘클로드가 중국에서 인기다’가 아니라, 프록시가 API 재판매와 데이터 수집, 모델 바꿔치기, 증류용 로그 확보를 한 번에 묶는 사업 모델이라는 점입니다.

쉽게 말하면, 공식 API는 제조사 직영점이고 프록시는 이름표만 같은 중고 유통상입니다. 직영점은 최소한 계약, 지역 정책, 계정 추적, 사고 대응 경로가 있지만, 암시장 프록시는 사용자가 무엇을 보냈는지, 실제로 어떤 모델이 답했는지, 로그를 어디에 재판매하는지 확인할 길이 거의 없습니다.

3) 핵심 구조 분해

핵심 요약: 이 시장은 단순 우회 접속이 아니라 계정 조달, KYC 우회, 요청 중계, 로그 수집, 재판매까지 이어지는 공급망입니다.

ChinaTalk의 조사에 따르면 중계소는 GitHub, Taobao, Telegram, X 같은 공개 채널에서 운영되며, 사용자는 프록시 서버 주소만 바꿔 Anthropic에 직접 붙는 것처럼 도구를 사용합니다. 하지만 실제로는 중간 서버가 모든 요청을 보고, 저장하고, 다른 공급원으로 다시 라우팅할 수 있습니다.

초보 개발자 기준으로 풀면 프록시는 ‘인터넷 회선’이 아니라 ‘대필 기사’에 가깝습니다. 내가 Claude에게 묻는다고 생각했지만, 실제로는 누군가가 내 질문을 읽고 다른 모델에게 대신 물어본 뒤 답만 돌려줄 수도 있다는 뜻입니다.

4) 설계 의도 해설

핵심 요약: 프록시 사업자는 API 마진보다 로그와 수요 집중을 통해 더 큰 가치를 뽑아내려는 유인이 있습니다.

앤트로픽은 2026년 2월 distillation attack 공지에서 DeepSeek, Moonshot, MiniMax 관련 캠페인이 약 2만4000개 사기 계정과 1600만 회 이상의 Claude 대화를 사용했다고 밝혔습니다. 여기서 중요한 대목은 공격자가 프록시 네트워크를 써서 수많은 계정을 순환시키고, 특정 능력에 집중된 반복 프롬프트를 대량 생산했다는 점입니다.

왜 이런 구조가 생길까요. 이유는 간단합니다.

• 얻는 것 1: 공식 접근 제한이 있는 지역에서도 수요를 현금화할 수 있음
• 얻는 것 2: 사용자 프롬프트와 답변 로그를 축적해 별도 데이터 자산으로 판매 가능
• 얻는 것 3: 고가 모델 브랜드를 빌려 저가 모델 응답을 섞어도 일반 사용자는 즉시 검증하기 어려움
• 포기하는 것: 정식 계약, 재현 가능한 SLA, 고객 신뢰, 법적 안정성

즉 90% 할인은 원가 혁신의 결과가 아니라 계정 편법·품질 속임수·로그 상품화·위험 전가의 결과일 가능성이 큽니다. 저는 이 점에서 이번 이슈를 ‘지역 차단이 낳은 우회 시장’으로만 읽는 해석에 동의하지 않습니다. 실무팀이 봐야 할 본질은, 프록시가 입력 데이터의 소유권과 통제권을 뒤집는 구조라는 것입니다.

5) 근거 및 비교

핵심 요약: 판단 기준은 가격이 아니라 데이터 통제권, 실제 모델 신뢰도, 사고 대응 가능성입니다.

근거도 꽤 선명합니다.

• Anthropic 상업 약관: 경쟁 서비스 구축, 경쟁 모델 학습, 무단 재판매를 금지합니다.
• Anthropic 공지: 한 프록시 네트워크가 2만개 이상 사기 계정을 동시에 관리했다고 설명합니다.
• ChinaTalk 조사: 중계소가 공식 가격의 10% 수준으로 토큰을 팔고, 실제 수익은 로그 수집과 재판매에서 나온다고 지적합니다.
• AI타임스 인용 CISPA 사례: 17개 프록시 감사에서 의료 벤치마크 성능이 공식 API 84% 수준 대비 37%에 그쳤다고 보도했습니다. 수치가 말해주듯 싸다고 같은 모델이 아닐 수 있습니다.

여기서 중요한 의사결정 기준은 세 가지입니다. 첫째, 누가 내 입력을 저장하는가. 둘째, 내가 산 모델이 실제로 그 모델이 맞는가. 셋째, 사고가 났을 때 누구에게 추적과 삭제를 요구할 수 있는가. 이 세 질문에 답하지 못하면 가격 비교는 의미가 없습니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 대응은 ‘직원에게 쓰지 마세요’ 공지 1장으로 끝나지 않고, 네트워크·비밀관리·도구정책을 같이 묶어야 합니다.

1. 모델 호출 경로를 전수 조사합니다.
   사내 코드, VS Code 확장, Claude Code 유사 도구, 브라우저 확장, n8n 워크플로에서 어떤 base URL을 쓰는지 확인합니다.
2. 공식 도메인 allowlist를 정합니다.
   예: API 호출은 vendor 공식 엔드포인트와 계약된 게이트웨이만 허용하고, 임의의 중계 도메인은 차단합니다.
3. 민감 입력 분류 규칙을 붙입니다.
   소스코드, 토큰, 고객정보, 내부 문서 요약, DB 스키마는 외부 프록시 금지 대상으로 명시합니다.
4. 에이전트 도구에 egress 제약을 둡니다.
   코딩 에이전트가 모델 호출 전에 환경변수, .env, secrets, private repo 문맥을 자동 포함하는지 점검합니다.
5. 로그 감사를 자동화합니다.
   짧게라도 base URL, 모델명, 요청량, 응답 지연, 호출 주체를 남겨서 ‘누가 어떤 우회 경로를 썼는지’ 추적 가능하게 만듭니다.

# 예시: 사내 게이트웨이에서 허용된 모델 엔드포인트만 통과
from urllib.parse import urlparse

ALLOWED_HOSTS = {
  "api.anthropic.com",
  "api.openai.com",
  "generativelanguage.googleapis.com"
}

def validate_model_endpoint(url: str):
    host = urlparse(url).netloc
    if host not in ALLOWED_HOSTS:
        raise SecurityError(f"허용되지 않은 모델 프록시: {host}")

실무에서는 여기서 한 단계 더 가야 합니다. 프록시를 막는 것만으로 충분하지 않습니다. 직원이 개인 키로 우회 서비스에 붙여도 민감 프롬프트를 보내지 못하게 프롬프트 레드액션과 컨텍스트 최소화를 같이 설계해야 합니다. 특히 코딩 에이전트는 README보다 .env와 에러 로그에서 더 치명적인 정보가 새어 나갑니다.

7) 실수/함정(Pitfalls)

핵심 요약: 가장 흔한 실패는 프록시를 보안 이슈가 아니라 구매 이슈로만 보는 것입니다.

• 실수 1: “개발자가 알아서 조심하겠지”라고 넘김
  예방: 허용 엔드포인트를 코드와 네트워크 정책으로 고정합니다. 복구: 비허용 도메인 호출 로그를 수집해 차단 규칙을 즉시 추가합니다.
• 실수 2: 출력 품질만 확인하고 입력 유출 가능성은 무시
  예방: 프롬프트에 무엇이 들어가는지 먼저 분류합니다. 복구: 도구별 자동 첨부 문맥과 로그 보존 범위를 재점검합니다.
• 실수 3: 프록시와 공식 리셀러·게이트웨이를 구분하지 못함
  예방: 계약 주체, 데이터 처리 문서, 사고 대응 채널, 모델 동일성 보장을 문서로 요구합니다. 복구: 증빙을 못 내는 공급자는 비업무 용도로도 차단합니다.
• 실수 4: 금지 공지만 내고 우회 유인을 줄이지 않음
  예방: 공식 경로의 비용·속도·승인 절차를 현실적으로 개선합니다. 복구: 팀이 왜 우회했는지 원인을 분석해 합법 경로 UX를 고칩니다.

8) 강점과 한계

핵심 요약: 프록시는 접근성을 높일 수는 있어도, 기업 운영 기준에서는 그 이점이 너무 비싼 대가로 돌아옵니다.

• 강점: 접근 제한 지역에서 빠르게 모델을 써볼 수 있고, 결제 장벽을 낮출 수 있습니다.
• 강점: 개인 취미 프로젝트에서는 실험 진입장벽을 낮출 수 있습니다.
• 한계: 데이터 유출 여부를 검증하기 어렵고, 모델 바꿔치기나 출력 왜곡 가능성이 큽니다.
• 한계: 약관 위반, 계정 차단, 품질 불안정, 사고 조사 불능이 동시에 따라옵니다.
• 반례: 공개 데이터만 넣는 단발성 실험이라면 피해 범위가 제한될 수 있지만, 그래도 결과 재현성과 모델 진위 문제는 남습니다.

제 추천은 명확합니다. 팀 업무와 연결된 모델 호출은 공식 API 또는 계약된 게이트웨이만 사용해야 합니다. 우회 시장을 쓰고 싶어지는 이유가 있다면, 그건 대개 가격보다 사내 승인 절차가 너무 느리거나 공식 경로가 현장 요구를 못 따라가는 운영 문제일 가능성이 큽니다.

9) 더 깊게 공부할 포인트

핵심 요약: 이번 이슈는 단발 뉴스가 아니라, 에이전트 시대의 데이터 경계 설계 문제로 이어집니다.

• 코딩 에이전트가 자동 첨부하는 파일·로그·터미널 출력 범위를 어디까지 줄여야 하는가
• 공식 API와 사내 게이트웨이 사이에 추가적인 프롬프트 레드액션 계층이 필요한가
• 벤더 지역 제한과 기업 글로벌 운영 사이의 충돌을 어떤 조달 정책으로 해결할 것인가
• 모델 출력 증류를 막기 위한 watermarking, trace token, abuse fingerprinting이 어디까지 실효적인가
• 가격이 아니라 데이터 소유권 기준으로 멀티모델 전략을 다시 짜야 하지 않는가

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 싼 모델 경로를 찾기 전에, 어떤 입력이 절대 제3자 프록시를 통과하면 안 되는지부터 팀 문서에 못 박아야 합니다.

• 사내에서 사용 중인 모든 AI 도구의 base URL을 목록화했는가?
• 공식 벤더 또는 계약된 게이트웨이 외 도메인을 차단했는가?
• 소스코드, 비밀키, 고객정보, 내부 문서를 민감 입력으로 분류했는가?
• 코딩 에이전트가 자동 포함하는 컨텍스트 범위를 점검했는가?
• 모델 호출 로그에 호출 주체, 엔드포인트, 모델명, 응답 지연을 남기고 있는가?
• 공식 경로가 너무 불편해서 우회가 생기는 조직 병목을 파악했는가?
• 벤더 약관과 지역 정책 위반 시 서비스 중단 시나리오를 준비했는가?

Definition of Done: 팀이 허용 엔드포인트 목록, 민감 입력 금지 규칙, 에이전트 컨텍스트 최소화 기준, 우회 경로 탐지 로그를 문서와 시스템에 모두 반영했다면 1차 대응이 끝난 것입니다.

제 결론은 단순합니다. API 90% 할인은 비용 최적화 신호가 아니라 통제권 상실 신호입니다. 실무팀은 해외 모델 접근성 논쟁보다 먼저, 프롬프트와 로그가 누구 손을 거치는지부터 보셔야 합니다.

참고자료

• AI타임스, 중국 암시장에서 '클로드' 10% 가격으로 유통..."모델 증류의 온상" (입력일: 2026-05-10)
• ChinaTalk, How to Buy Cheap Claude Tokens in China (게시일: 2026-05-05)
• Anthropic, Detecting and preventing distillation attacks (게시일: 2026-02-23)
• Anthropic, Commercial Terms of Service (효력일: 2025-06-17, 확인일: 2026-05-10)
• Claude Help Center, Identity verification on Claude (확인일: 2026-05-10)