클로드 코드 대시보드 사용법 — Console에서 키·사용량·티어 보기

"클로드 코드 대시보드"라는 별도 화면은 따로 존재하지 않는다. 클로드 코드를 API 키로 운영하면 결제·사용량·한도 관리는 Claude Console(platform.claude.com)로 옮겨간다. 같은 콘솔이 클로드 API 일반·Agent SDK·Managed Agents 등 Anthropic의 모든 개발자 제품을 함께 관리하는 단일 창구다.

이 글은 그 콘솔에서 무엇을 볼 수 있고 무엇을 결정해야 하는지를 한 페이지에 정리한다. 결제 경로 비교가 먼저 필요하면 Pro·Max·API 결제 글, 코드에서 직접 호출하는 방법이 먼저 필요하면 Agent SDK 사용법 글이 앞 순서다.

1. 첫 진입 — API 키 한 개로 시작

콘솔 첫 진입의 목표는 단 하나다. API 키 발급. 가입 후 좌측 메뉴 API Keys에서 키를 만들고, 그 값을 ANTHROPIC_API_KEY 환경변수에 박으면 그 시점부터 Claude Code SDK·CLI 헤드리스 모드·Anthropic Client SDK가 모두 같은 키로 인증된다.

키 발급 시 두 가지를 결정하게 된다. 이름과 Workspace. 이름은 단순 라벨이라 자유롭게 짓되 어디서 쓰는 키인지 알아볼 수 있는 식별자로 둔다(예: ci-pr-review, local-dev). Workspace는 처음에는 default 하나만 있고, 팀이 커지거나 서비스가 갈라지면 분리하게 된다(§7에서 다시 다룬다).

2. Usage 페이지 — 무엇이 보이는가

콘솔 좌측 Usage에 들어가면 세 종류의 차트가 한 화면에 모인다.

세 차트의 의미는 같다 — "지금 한도의 몇 %를 쓰고 있는가, 한도를 올려야 하는가, 캐시로 풀 수 있는가." 답을 구할 때 차트의 피크 시간대를 잡고 그 시간대 코드 로직을 확인하면 거의 한 번에 원인이 잡힌다.

3. Limits — 사용량 티어 4단계

Anthropic API의 사용량 티어는 4단계로 정해져 있다. 누적 입금액이 일정 임계를 넘기면 자동으로 다음 티어로 승급되고, 승급되면 월 지출 상한과 RPM이 함께 풀린다. 콘솔의 Settings > Limits에서 현재 티어와 남은 승급 조건을 확인할 수 있다.

여기서 중요한 점이 두 가지다. 첫째, "진입 입금"은 누적 기준이다. Tier 2로 가려면 $40을 일시 입금이 아니라 누계로 채워야 한다. 이미 Tier 1에서 $35를 쓴 상태라면 $5만 더 충전해도 곧바로 Tier 2다. 둘째, 월 지출 상한 외에 고객이 직접 설정하는 상한이 별도로 있다. Settings > Limits에서 자신만의 더 낮은 상한을 박을 수 있다. 폭주 보호 장치다.

월간 청구(Monthly Invoicing)는 별도 트랙이다. 매월 사용량을 후불 청구하는 Net-30 결제이고 월 상한이 없다. 영업팀과 협의해 전환되며, 결제·세금계산서·구매 발주 같은 회사 행정 체계와 잘 맞물린다.

4. 모델별 RPM·ITPM·OTPM — 티어 올라가면 무엇이 풀리나

한도는 모델별로 따로 정해진다. 같은 티어 안에서도 Opus·Sonnet·Haiku가 받는 RPM(분당 요청), ITPM(분당 입력 토큰), OTPM(분당 출력 토큰)이 다 다르다. Tier 1과 Tier 4 사이 격차는 다음 표로 한눈에 잡힌다(2026년 5월 기준 표준 한도).

표에 적힌 한도는 같은 모델 계열의 합산이다. Opus 4.x의 RPM 한도는 Opus 4.7·4.6·4.5·4.1·4 트래픽을 모두 합쳐 적용되고, Sonnet 4.x도 마찬가지로 4.6·4.5·4 합산이다. 사이드 작업에 Haiku 4.5를 쓰면 Opus 한도와 독립이라 두 모델을 동시에 풀 한도로 돌릴 수 있다.

Tier 4까지 가는 동안 Opus 기준 RPM은 80배(50→4,000), ITPM은 20배(500K→10M), OTPM은 10배(80K→800K)가 풀린다. 한도가 풀리는 속도가 비례하지 않는다는 점이 중요하다 — Opus는 RPM이 빨리 풀리고, Sonnet은 ITPM이 빨리 풀린다. 어디서 먼저 막히는지가 모델 선택에 영향을 준다.

5. 캐시 적중률이 ITPM을 늘린다

한도 표만 보면 Tier 1에서는 너무 빨리 막힐 것 같지만 실제로는 한 가지 변수가 더 작동한다. 프롬프트 캐싱이다. 대부분의 Claude 모델에서 캐시에서 읽힌 토큰은 ITPM 한도에 카운트되지 않는다(Haiku 3.5만 예외). Anthropic 문서가 강조하는 부분이다.

예를 들어 2,000,000 ITPM 한도에 80% 캐시 적중률이면 분당 10,000,000 입력 토큰을 처리할 수 있다는 계산이 나온다(비캐시 2M + 캐시 8M). 한도를 올리는 가장 빠른 방법은 결제가 아니라 캐시 적중률을 올리는 것이라는 결론이 여기서 나온다.

적중률을 올리는 방법은 익숙해지면 단순하다. 시스템 프롬프트·CLAUDE.md·큰 컨텍스트 문서·도구 정의·대화 이력 같은 반복 입력을 캐시 가능한 위치에 놓는다. Usage 차트의 캐시 적중률을 일주일 단위로 모니터링하면서 적중률이 50% 아래로 떨어지면 프롬프트 구조를 점검하는 운영 흐름이 표준이다.

6. 응답 헤더 — 코드에서 직접 보는 한도

대시보드를 매번 들여다보지 않아도 API 응답 헤더에 한도 현황이 그대로 실린다. SDK·Client 어느 쪽이든 응답 객체에서 헤더를 꺼내 보면 다음 정보가 있다.

운영 자동화에서 가장 자주 쓰는 헤더는 retry-after다. 429를 받으면 임의의 백오프를 거는 대신 이 헤더 값만큼만 정확히 기다리면 된다. 그 외 헤더들은 대시보드 차트와 같은 정보를 코드에서 실시간으로 보는 길이다 — 자동화에 동적 페이싱이 들어가야 할 때 필수다.

7. Workspaces — 팀·서비스 단위로 분리

Workspace는 같은 조직 안에서 결제·키·한도를 별개 트랙으로 갈라 관리하는 단위다. 초기에는 default 하나로 시작하지만 다음 같은 상황에서 추가하게 된다.

주의할 점이 한 가지 있다. default Workspace에는 별도 한도를 박을 수 없다. 한도 분리가 필요하면 추가 Workspace를 만들어 거기에서 작업한다. 또 Workspace 한도를 모두 합한 값이 조직 한도를 넘어도 조직 한도가 항상 상위에서 적용된다 — 합산 초과는 의미가 없다.

8. 운영 시나리오 — 어디서 무엇을 봐야 하나

대시보드는 모든 정보를 한 화면에 모아두지만 운영 패턴에 따라 봐야 할 화면이 달라진다. 네 가지 시나리오로 정리하면 다음과 같다.