TRENDSHIFT 4위 딥다이브 · 2026-04-03 분석

cc-gateway 딥다이브
— Claude Code 앞에 앉는 리버스 프록시, 여러 기기를 한 대처럼 보이게 한다

Claude Code가 본사에 보내는 디바이스 정보와 텔레메트리를 가운데서 가로채 하나의 통일된 신원으로 다시 포장하는 리버스 프록시 게이트웨이. ⭐약 2.8k · 의존성 단 2개의 가벼운 Node.js/TypeScript 프로젝트지만, HTTP 프록시·OAuth·암호 해시 역공학·SSE 스트리밍 등 네트워크 프로그래밍의 알짜 패턴이 다 들어 있다. (저장소: motiful/cc-gateway · MIT 라이선스 · v0.2.0 alpha)
목차
  1. 프로젝트 한줄 요약
  2. 왜 주목받는가
  3. 기술 스택 전체 지도
  4. 아키텍처 심화 분석
  5. 디렉토리 구조 해부
  6. 학습 포인트 (기술별)
  7. 하드웨어 / 시스템 요구사항
  8. 직접 해볼 수 있는 실습 과제
  9. 관련 기술 심화 학습 로드맵
  10. 핵심 키워드 사전
  11. 참고 링크

1프로젝트 한줄 요약

cc-gateway가 정확히 무엇을 하는 도구인가

cc-gatewayClaude Code와 Anthropic API 사이에 끼어 앉아, 각 기기가 본사로 보내는 디바이스 ID·이메일·환경 정보·텔레메트리를 가로채 하나의 통일된 신원으로 다시 써서 전달하는 리버스 프록시다. 여러 대의 컴퓨터에서 같은 계정을 써도, 본사 입장에서는 "단 한 대의 기기"로만 보이게 만든다.

한 컷 비유

"내 기기 여러 대를 한 대처럼 보이게 한다 — 그것도 단 두 개의 의존성으로"

Claude Code는 데스크톱·노트북·서버마다 다른 디바이스 ID와 환경 정보를 본사에 보낸다. 이걸 그대로 두면 "한 계정이 다섯 기기에서 동시에 쓰인다"는 신호가 된다. cc-gateway는 모든 기기의 요청을 가로채 하나의 통일된 디바이스 ID와 환경 정보로 다시 포장한 뒤 Anthropic 서버로 보낸다.

핵심은 인터셉터 체인이다. 요청 한 건이 들어오면 인증 → 본문 수집 → 본문 리라이트 → 헤더 리라이트 → OAuth 토큰 주입 → 업스트림 포워딩의 6단계를 차례로 통과한다. 그리고 코드 자체가 학습 교본이다 — Node.js 빌트인 모듈만으로 프로덕션급 프록시를 만드는 방법이 전부 들어 있다.

2왜 주목받는가

트렌딩 이유와 이 레포만의 강점

요즘 AI 서비스는 "한 사람당 하나의 계정"을 강제한다. 하지만 사람들은 데스크톱·노트북·회사 PC·서버에서 같은 계정을 쓰고 싶어 한다. Claude Code는 각 기기마다 다른 디바이스 ID와 텔레메트리를 본사에 보내기 때문에 — 본사 입장에서는 "한 계정이 다섯 기기에서 동시에"라는 신호가 된다. cc-gateway는 이 신호 자체를 지운다.

용어
디바이스 핑거프린팅 (Device Fingerprinting, 기기 지문)
OS 종류, CPU 아키텍처, 메모리 크기, 터미널 종류, Node.js 버전 등 수십 가지 환경 정보를 조합해 그 기기만의 고유 ID를 만드는 기술. 쿠키나 IP만으로 추적할 수 없어도 "이 기기는 그 기기와 같다"고 식별한다. README 기준 cc-gateway는 이 핑거프린팅에 쓰이는 40개 이상의 차원을 통일된 값으로 교체한다.
기존 방식의 함정
"VPN이면 충분하다"는 착각

많은 사람이 VPN으로 IP만 숨기면 멀티디바이스 문제가 해결된다고 생각한다. 틀렸다. IP는 핑거프린팅의 한 조각일 뿐이다. OS, 메모리 크기, 터미널 종류 같은 40개 이상의 차원이 추가로 수집되는데 이건 VPN으로 못 가린다. IP가 같아도 환경 정보가 다 다르면 다른 기기로 식별된다.

cc-gateway의 해법
환경 정보 통째 교체 + 중앙 신원 집계

IP만 가리는 게 아니라 device_id, email, 세션 메타데이터, 메모리 사이즈, OS 정보 등 40개 이상의 차원을 모두 통일된 값으로 다시 쓴다. 모든 기기(관리자 포함)가 게이트웨이를 거치게 하면 본사는 전부 같은 한 대로 본다. 게다가 OAuth 토큰을 중앙에서 관리해 클라이언트가 토큰을 안 보내도 게이트웨이가 끼워 넣는다.

이 레포가 학습 자료로 좋은 이유

관점왜 배울 가치가 있나
의존성 최소화외부 의존성 단 2개. Express/Fastify/Axios 뒤에 숨은 HTTP의 진짜 동작이 그대로 드러난다
실전 프록시인증 → 본문/헤더 리라이트 → 업스트림 포워딩 — 모든 리버스 프록시의 공통 골격을 작은 코드로 본다
스트리밍SSE 응답을 pipe() 한 줄로 무손실 통과시키는 법 — "가공하지 않는 안전함"을 배운다
역공학관찰만으로 CCH 빌링 해시 알고리즘을 복원 — 리버스 엔지니어링의 사고법을 엿본다

3기술 스택 전체 지도

언어 구성 · 런타임 · 의존성 · 배포 인프라

언어 / 런타임

기술역할상세
TypeScript 5.7전체 소스tscdist/ 빌드, tsx로 개발 중 직접 실행
Node.js 22+런타임빌트인 http/https/crypto/fs/url 모듈이 코드의 토대
YAML설정 포맷config.example.yaml / clash-rules.yaml
Shell설치/배포scripts/*.sh — quick-setup, add-client, admin-setup

외부 의존성 — 단 2개 (확인됨)

runtime dependencies ├── yaml ^2.7.0 ← YAML 설정 파일 파싱 └── https-proxy-agent ^9.0.0 ← Clash/V2Ray 등 외부 프록시 환경 지원 devDependencies ├── @types/node ^22.0.0 ← Node 타입 정의 ├── tsx ^4.19.0 ← TS 무빌드 실행/watch └── typescript ^5.7.0 ← 컴파일러 그 외 전부 Node.js 빌트인: http · https · crypto · fs · url
목공 비유

요즘 npm 프로젝트의 의존성은 보통 50~200개다. 이건 "가구 하나를 만들려고 백 가지 공구를 다 사오는 목공"과 비슷하다.

cc-gateway의 저자는 정반대를 택했다 — 도끼와 끌만으로 가구를 짠 장인이다. 보안 면에서도 유리하다: 의존성이 적을수록 공급망 공격(supply chain attack)에 노출되는 표면이 작아진다.

배포 / DevOps

기술역할상세
Dockerfile컨테이너화빌드/런타임 분리 멀티 스테이지 패턴(추정) — 최종 이미지 경량화
docker-compose오케스트레이션docker compose restart로 프로덕션 운영
GitHub ActionsCICI 워크플로 없음 — .github/에 로고·메타 파일(logo-dark.svg, logo-light.svg, repo-meta.yml)만 존재
tests검증tests/rewriter.test.ts — 16개 통과 테스트(README 기준)

4아키텍처 심화 분석

리버스 프록시 골격 · 인터셉터 체인 · SSE 스트리밍 · CCH 해시
용어
리버스 프록시 (Reverse Proxy, 역방향 대리 서버)
진짜 서버 앞에 앉아 모든 요청을 가로채는 중간 서버. 일반 프록시가 클라이언트를 대신해 서버에 요청한다면, 리버스 프록시는 서버를 대신해 클라이언트의 요청을 받는다. 클라이언트는 리버스 프록시를 진짜 서버라고 믿는다. Nginx, Cloudflare, AWS API Gateway가 모두 리버스 프록시다.

시스템 구조도

┌──────────────────────────────────────────────────────────────┐ │ 여러 클라이언트 기기 │ │ 데스크톱 CC | 노트북 CC | 서버 CC | 관리자 CC │ │ (각자 다른 device_id / OS / 메모리 / 터미널) │ └───────────────────────────┬──────────────────────────────────┘ │ 요청 (x-api-key / Bearer) ┌───────────────────────────▼──────────────────────────────────┐ │ cc-gateway (Node.js) │ │ ┌────────────────────────────────────────────────────────┐ │ │ │ proxy.ts — http.createServer() 진입점 │ │ │ └───────────────────────────┬────────────────────────────┘ │ │ ▼ │ │ ┌────────────────────────────────────────────────────────┐ │ │ │ rewriter.ts — 인터셉터 체인 (요청 변환의 심장) │ │ │ │ ① 인증 → ② 본문 수집 → ③ 본문 리라이트 │ │ │ │ ④ 헤더 리라이트 → ⑤ OAuth 주입 → ⑥ 포워딩 │ │ │ └───────────┬───────────────────────────┬────────────────┘ │ │ │ │ │ │ ┌──────────▼────────┐ ┌───────────▼──────────┐ │ │ │ oauth.ts │ │ auth.ts / config.ts │ │ │ │ 중앙 토큰 사전갱신 │ │ 클라이언트 인증/설정 │ │ │ └───────────────────┘ └──────────────────────┘ │ └───────────────────────────┬──────────────────────────────────┘ │ https.request() (통일된 신원) ┌───────────────────────────▼──────────────────────────────────┐ │ Anthropic API (진짜 서버) │ │ 응답은 proxyRes.pipe(res) 로 무손실 통과 ───────────► │ └──────────────────────────────────────────────────────────────┘

핵심 설계 패턴 ①: 인터셉터 체인 (요청 변환의 순서)

이 프로젝트에서 가장 흥미로운 코드는 rewriter.ts다. 클라이언트의 요청 한 건이 들어오면 아래 6단계를 순서대로 거친다.

요청이 거치는 6단계

1) 클라이언트 인증. 게이트웨이를 쓸 권한이 있는지 확인. x-api-key나 Bearer 토큰 검증.

2) 본문 수집. HTTP 요청은 청크 단위로 도착한다. 다 모아 하나의 Buffer로 만든다.

3) 본문 리라이트. 경로별로 다르게 처리. /v1/messages면 메시지 본문을, /event_logging이면 텔레메트리를 변환한다.

4) 헤더 리라이트. 빌링 헤더 제거, User-Agent 교체, 기타 식별 헤더 정리.

5) OAuth 토큰 주입. 클라이언트가 자기 토큰을 안 보내도, 게이트웨이가 중앙 OAuth 토큰을 끼워 보낸다.

6) 업스트림 포워딩. 정리된 요청을 진짜 Anthropic API 서버로 전달.

보안 우체국 비유

절차가 까다로운 보안 우체국을 상상해보자. 신분증 확인하고, 봉투 내용을 검사하고, 보낸 사람 주소를 회사 공통 주소로 바꿔 적고, 회사 우표를 붙인 뒤, 마지막에 진짜 우체국으로 전달한다.

cc-gateway가 하는 일이 딱 그렇다. 각 클라이언트는 자기 편지를 보냈다고 생각하지만, 본사가 받아본 봉투에는 모두 같은 발신인이 적혀 있다.

핵심 설계 패턴 ②: SSE 스트리밍을 건드리지 않는다

요청은 통째로 바꾸지만, 응답은 한 글자도 안 건드린다. 코드로 보면 이 한 줄이다 — proxyRes.pipe(res). 업스트림 응답을 클라이언트 응답에 통째로 흘려보낸다.

용어
SSE (Server-Sent Events, 서버 발송 이벤트)
서버가 클라이언트에게 실시간으로 데이터를 한 글자씩 흘려보내는 HTTP 기술. Claude 답변이 한 글자씩 타이핑되어 보이는 게 SSE다. 일반 HTTP 요청-응답이 편지 한 통이라면, SSE는 끝나지 않는 라이브 방송이다.
함정
"응답도 가공해보자"는 유혹

처음 프록시를 만들면 응답도 변환하고 싶어진다. 그런데 SSE 스트리밍 응답에 잘못 손대면 실시간 타이핑이 멈추거나, 중간이 잘리거나, 인코딩이 깨진다. Claude 사용 경험을 망치는 가장 빠른 길이다.

해결책
pipe() 한 줄로 그대로 통과

Node.js 스트림은 데이터를 메모리에 다 쌓지 않고 도착하는 즉시 다음 단계로 흘려보낸다. proxyRes.pipe(res) 한 줄이면 본사에서 도착한 한 글자가 바로 클라이언트로 흐른다. 가공이 필요 없으면 가공하지 않는다 — 단순함이 최고의 안전장치다.

핵심 설계 패턴 ③: x-anthropic-billing-header 전략

가장 까다로운 부분은 x-anthropic-billing-header 처리다. Claude Code가 보내는 이 빌링 헤더에는 메시지 본문 기반 검증값이 포함돼 있는데, 게이트웨이가 본문을 리라이트하면 불일치가 발생할 수 있다. v0.2.0에서는 이 헤더를 완전히 제거(strip)하는 방식으로 전략이 바뀌었다 — Anthropic 공식 환경변수 CLAUDE_CODE_ATTRIBUTION_HEADER=false와 동일한 효과이며, 프롬프트 캐시 공유의 부산물이기도 하다.

v0.2.0 빌링 헤더 전략 (현행)

1) 헤더 완전 제거: 게이트웨이가 요청에서 x-anthropic-billing-header를 strip한다.

2) 재계산 없이 통과 — 헤더 자체가 없으면 불일치 검증도 발생하지 않는다.

3) 공식 CLAUDE_CODE_ATTRIBUTION_HEADER=false 옵션과 동일한 동작이다.

※ 구버전(v0.1.x)에는 SHA-256 기반 해시 재계산 fallback 코드가 있었으나 v0.2.0에서 기본 비활성화됨.

택배 스티커 비유

택배 박스에 원래 내용물 바코드 스티커가 붙어 있다고 하자. 박스 안을 바꿨는데 바코드는 그대로면 검수에서 걸린다.

v0.2.0의 해법은 "바코드를 다시 인쇄"하는 대신 바코드 스티커를 아예 떼어 보내는 것이다. 스티커가 없으면 바코드 불일치 검수 자체가 생략된다.

핵심 설계 패턴 ④: 고정값 대신 "현실적인 랜덤"

함정
모든 요청의 메모리가 똑같으면 의심받는다

현실에서 같은 컴퓨터의 메모리 사용량도 시시각각 변한다. 그런데 "모든 요청에서 정확히 348572104바이트"라면? 본사 분석 시스템은 즉시 "고정값 봇/위조"라고 판단한다. 고정값은 그 자체가 핑거프린트가 된다.

해결책
변동 지표는 합리적 범위 안에서 랜덤화

메모리(RSS·힙), 가동 시간처럼 자연히 변하는 값은 비현실적이지 않은 범위 안에서 매 요청 랜덤으로 생성한다. OS·아키텍처처럼 절대 안 바뀌는 값은 고정. 이 분류가 신뢰성을 만든다.

5디렉토리 구조 해부

src/ 가 핵심 — 파일 8개로 끝난다
motiful/cc-gateway/ ├── src/ # ⭐ 핵심 소스 (TypeScript) │ ├── index.ts # 엔트리포인트 (start 스크립트가 dist/index.js 실행) │ ├── proxy.ts # http.createServer() — 리버스 프록시 본체 │ ├── rewriter.ts # ⭐ 인터셉터 체인 (본문/헤더 리라이트, CCH) │ ├── oauth.ts # 중앙 OAuth 토큰 관리 + 사전 갱신 │ ├── auth.ts # 클라이언트 인증 (x-api-key / Bearer) │ ├── config.ts # YAML 설정 로딩 + 환경 변수 │ ├── proxy-agent.ts # 외부 프록시(Clash/V2Ray) 에이전트 구성 │ ├── logger.ts # 로깅 유틸 │ └── scripts/ # generate-token.ts, generate-identity.ts ├── tests/ │ └── rewriter.test.ts # 16개 통과 테스트 ├── scripts/ # 셸 설치/운영 스크립트 │ ├── quick-setup.sh # 로컬 개발 셋업 │ ├── add-client.sh # 클라이언트 추가 │ └── admin-setup.sh # 프로덕션(관리자) 셋업 ├── .github/ # 로고·메타 파일 (CI 워크플로 없음) ├── Dockerfile # 컨테이너 빌드 ├── docker-compose.yml # 프로덕션 오케스트레이션 ├── config.example.yaml # 설정 템플릿 ├── clash-rules.yaml # Clash 프록시 규칙 ├── package.json # 의존성 2개뿐 └── tsconfig.json

구조를 읽는 법: proxy.ts가 들어오는 연결을 받고 → rewriter.ts가 요청을 변환하고 → oauth.ts가 신원을 주입하고 → 다시 proxy.ts가 업스트림으로 포워딩한다. 파일 8개만 읽으면 전체 흐름이 손에 잡히는 크기라서 입문용 리딩 대상으로 이상적이다.

6학습 포인트 (기술별)

이 레포에서 무엇을 배울 수 있는가

A. 순수 Node.js HTTP 서버 — 프레임워크 없는 본질

배울 것: http.createServer()로 서버를 만들고, https.request()로 업스트림을 호출하고, pipe()로 스트림을 잇는 — 모든 Node.js 웹 서버의 토대. Express/Fastify가 마법처럼 느껴지는 이유는 이 기초를 안 봤기 때문이다.

B. 리버스 프록시 & 인터셉터 체인

배울 것: 인증 → 본문/헤더 변환 → 포워딩의 파이프라인 설계. 경로별 분기(/v1/messages vs /event_logging)로 같은 진입점에서 서로 다른 변환을 적용하는 라우팅 감각.

C. SSE 스트리밍 무손실 통과

배울 것: 요청은 버퍼링해 변환하되, 응답은 버퍼링 없이 즉시 흘려보내야 하는 이유. 백프레셔(backpressure)를 자동 처리하는 pipe()의 가치.

D. OAuth 토큰 사전 갱신 (Proactive Renewal)

배울 것: 외부 OAuth 라이브러리 없이 토큰 캐싱·만료 추적·setTimeout 사전 갱신을 직접 구현하는 법. 만료 5분 전 자동 갱신으로 서비스 중단을 막는다.

E. 암호 해시 & 역공학 사고법

배울 것: crypto 빌트인의 SHA-256 사용법과, 관찰 → 가설 → 시뮬레이션 → 복원으로 이어지는 리버스 엔지니어링 절차. "입력 한 글자가 바뀌면 출력이 완전히 달라진다"는 해시의 성질을 실전에서 다룬다.

F. 미니멀 의존성 & 공급망 보안

배울 것: 의존성 2개라는 극단적 선택이 주는 보안·유지보수 이점. 빌트인으로 충분한 일을 굳이 패키지로 끌어오지 않는 판단 기준.

G. Docker 멀티 스테이지 & TypeScript 빌드 파이프라인

배울 것: tsx watch로 개발하고 tscdist/를 만든 뒤 컨테이너에 담는 흐름. 빌드 환경과 런타임 환경을 분리해 최종 이미지를 줄이는 패턴은 Python·Go·Rust에도 그대로 적용된다.

7하드웨어 / 시스템 요구사항

가벼운 프록시 — 라즈베리파이급에서도 충분
항목최소권장
Node.js22+ (README 명시)22 LTS 최신
OSLinux / macOS / Windows (Node 동작 환경)Linux 서버 (상시 구동)
RAM256MB~512MB1GB+ (여유)
네트워크인터넷 연결 필수 (업스트림 API)안정적 회선 / 고정 IP
Docker선택 (로컬은 npm만으로 가능)프로덕션 권장 (compose)
계정유효한 Anthropic / Claude 자격증명중앙 OAuth 토큰 발급 완료
실행 방법명령용도
로컬 개발npm installbash scripts/quick-setup.shnpm run dev코드 읽고 고치며 실험
프로덕션bash scripts/admin-setup.shdocker compose restart상시 구동 게이트웨이
빌드npm run build (tsc) → npm start컨테이너 없이 직접 구동
테스트npm test (tsx tests/rewriter.test.ts)리라이터 회귀 검증(16개)

8직접 해볼 수 있는 실습 과제

난이도별 5가지 과제
과제 1

40줄짜리 에코 프록시 ★ 초급 30분

Express 없이 순수 http.createServer()만으로 — 들어오는 요청을 다른 URL로 그대로 전달하는 프록시를 만들어본다. 헤더 로깅과 SSE 스트리밍 통과 테스트까지.

// echo-proxy.mjs
import http from 'http';
import https from 'https';

http.createServer((req, res) => {
  // 업스트림으로 그대로 포워딩
  const up = https.request(
    { host: 'httpbin.org', path: req.url, method: req.method, headers: req.headers },
    (proxyRes) => {
      res.writeHead(proxyRes.statusCode, proxyRes.headers);
      proxyRes.pipe(res);   // ← SSE도 이 한 줄로 무손실 통과
    });
  req.pipe(up);
}).listen(8787);
과제 2

요청 본문 변환 미들웨어 ★ 초급 1시간

JSON 본문에서 user.email을 마스킹하고(j***@gmail.com 형태), user.ip를 SHA-256 해시로 바꾸는 미니 미들웨어를 만든다. 인터셉터 체인의 핵심을 익힌다.

힌트: 청크를 req.on('data')로 모아 Buffer 합치기 → JSON.parse → 필드 교체 → crypto.createHash('sha256') → 다시 직렬화해 업스트림에 write.
과제 3

OAuth2 자동 갱신 모듈 ★★ 중급 2시간

oauth.ts를 참고해 독립적인 토큰 관리 모듈을 짠다. 캐싱, 만료 추적, setTimeout 사전 갱신 스케줄링, 갱신 실패 시 재시도까지. 이걸 만들면 어떤 API와도 안정적으로 통신할 수 있다.

핵심: 토큰에 expires_at을 기록 → 만료 5분 전 시점에 setTimeout 예약 → 갱신 성공 시 캐시 교체, 실패 시 지수 백오프로 재시도.
과제 4

Docker 멀티 스테이지 배포 ★★★ 고급 3시간

이 레포의 Dockerfile을 읽고 빌드 환경과 런타임 환경을 분리하는 패턴을 익힌다. TypeScript를 빌드 스테이지에서 컴파일하고, 런타임 스테이지에는 dist/와 프로덕션 의존성만 복사해 최종 이미지를 1/3 이하로 줄인다.

구조: FROM node:22 AS build (npm ci + tsc) → FROM node:22-slim (dist + node_modules 프로덕션만 COPY). 같은 패턴이 Python·Go·Rust에도 적용된다.
과제 5

mitmproxy로 진짜 트래픽 관찰 ★★★ 고급 4시간

mitmproxy를 띄우고 자기가 쓰는 CLI 도구의 트래픽을 캡처한다. Claude Code뿐 아니라 git, npm, gh도 어딘가로 데이터를 보낸다. 이걸 직접 보는 경험이 네트워크 프로그래밍 시야를 넓힌다.

흐름: mitmproxy 실행 → HTTPS_PROXY=http://127.0.0.1:8080 환경변수로 대상 도구 실행 → 어떤 엔드포인트에 어떤 본문이 가는지 관찰 → cc-gateway가 무엇을 리라이트하는지 역으로 이해.

9관련 기술 심화 학습 로드맵

4주 학습 플랜

1주차: Node.js HTTP의 기초

요일학습 내용실습
http/https 빌트인 모듈createServer로 hello 서버
스트림과 pipe요청→업스트림 에코 프록시(과제 1)
요청 본문 수집 패턴청크 모아 Buffer 합치기
헤더 다루기User-Agent·식별 헤더 교체 실험
SSE 이해스트리밍 응답을 무손실 통과시키기

2주차: 리버스 프록시 & 변환

요일학습 내용실습
리버스 프록시 개념Nginx와 cc-gateway 비교
인터셉터 체인 설계rewriter.ts 흐름 따라 읽기
경로별 분기/messages vs /event_logging 처리 분리
본문 변환 미들웨어email 마스킹·ip 해시(과제 2)
핑거프린팅 차원 분류고정값 vs 랜덤값 분류 설계

3주차: 인증 · OAuth · 암호

요일학습 내용실습
OAuth2 기본 흐름토큰 발급/만료 개념 정리
사전 갱신 패턴setTimeout 갱신 모듈(과제 3)
crypto 빌트인SHA-256 해시 계산 실습
해시 검증 메커니즘CCH 재현 원리 따라가기
역공학 사고법관찰→가설→시뮬레이션 연습

4주차: 배포 & 운영

요일학습 내용실습
TypeScript 빌드 파이프라인tsx watch / tsc 빌드 비교
Docker 멀티 스테이지이미지 경량화(과제 4)
docker-compose 운영compose로 상시 구동·재시작
외부 프록시 연동https-proxy-agent로 Clash 경유
트래픽 관찰 종합mitmproxy 캡처(과제 5)

10핵심 키워드 사전

이 레포를 이해하는 데 꼭 필요한 용어들
키워드설명
리버스 프록시진짜 서버 앞에 앉아 요청을 가로채는 중간 서버. 클라이언트는 이걸 진짜 서버로 믿는다
인터셉터 체인요청이 거치는 변환 단계의 순서(인증→본문→헤더→OAuth→포워딩). rewriter.ts의 골격
디바이스 핑거프린팅OS·메모리·터미널 등 수십 차원을 조합해 기기를 식별하는 기술. cc-gateway가 무력화 대상으로 삼는다
텔레메트리소프트웨어가 사용 패턴·환경 정보를 본사로 보내는 데이터. "원격 측정"의 뜻
SSEServer-Sent Events. 서버가 데이터를 한 글자씩 실시간으로 흘려보내는 HTTP 기술
pipe()Node.js 스트림을 잇는 메서드. 데이터를 쌓지 않고 도착 즉시 흘려보내 백프레셔를 자동 처리
업스트림 (Upstream)프록시가 요청을 최종 전달하는 진짜 서버. 여기서는 Anthropic API
OAuth 토큰API 접근 권한을 증명하는 시간 제한 자격증명. 만료 전 갱신해야 끊김이 없다
사전 갱신Proactive Renewal. 토큰 만료 5분 전에 미리 갱신해 서비스 중단을 막는 패턴
CCHClaude Code Hash. 첫 메시지 기반 빌링 검증 해시. 본문을 바꾸면 재계산이 필요하다
SHA-256암호학적 해시 함수. 임의 길이 입력을 256비트 고정 출력으로. 한 글자만 달라도 결과가 완전히 바뀐다
소금값 (Salt)해시 입력에 덧붙이는 고정/비밀 문자열. 같은 입력이라도 결과를 예측·재현하기 어렵게 만든다
고정값 함정변동해야 할 지표를 상수로 박으면 오히려 위조 신호가 되는 문제. 합리적 범위 랜덤으로 회피
공급망 공격의존성(써드파티 패키지)을 통해 침투하는 공격. 의존성이 적을수록 노출 표면이 작다
멀티 스테이지 빌드Docker에서 빌드 환경과 런타임 환경을 분리해 최종 이미지를 줄이는 패턴
https-proxy-agent외부 프록시(Clash·V2Ray) 환경에서 Node가 업스트림에 나갈 수 있게 해주는 의존성

11참고 링크

더 깊이 파고들 때 유용한 자료들