Claude 토큰 도난이 드러낸 작은 팀의 보안 맹점

쓰지도 않았는데 토큰이 사라졌다

지난달, 해외 Claude 구독자 한 명이 이상한 걸 발견했다. 아무것도 하지 않은 날인데 계정 토큰이 꾸준히 줄고 있었다. Anthropic은 뒤늦게 사용자들에게 해킹 경고를 보냈다. TechCrunch가 보도한 이 사건의 표면적 결론은 단순하다 — 누군가 계정을 탈취해 토큰을 무단으로 소비했다.

핵심 답을 먼저 주자면, 이 사건의 본질은 '구독자 개인 부주의'가 아니라 AI 벤더 의존 구조에 뚫린 구멍이다. 문제는 작은 팀일수록 그 구멍이 더 크게 열려 있다는 것. 그리고 피해가 났을 때 보상받을 법적 경로가 현재로선 거의 없다는 것. 이 두 가지를 같이 읽어야 한다.

작은 팀이 유독 취약한 구조

대기업은 보안팀이 있다. API 키 하나가 털려도 즉시 감지하고, 폐기하고, 재발급한다. 작은 팀은 다르다.

솔직히 말하면, API 키가 .env 파일에 들어가고 그게 배포 서버에 올라가는 순간 관리 주체가 흐릿해진다. 서버 접근 권한을 공유하는 팀원이 늘어날수록, 그 키가 어디 복사됐는지 추적하기 어려워진다. 테스트 목적으로 로컬에 복사한 키가 실수로 GitHub에 올라가는 사고는 지금도 빈번하다. 실제로 GitHub에서 ANTHROPIC_API_KEY를 검색하면 공개된 레포에서 키가 박힌 커밋이 수두룩하게 나온다.

우리 팀 같은 경우, 블로그·보험·금융·식단 등 10개가 넘는 봇이 동일한 API 키 라인을 공유하는 구조다. 키 하나가 노출되면 전체 봇이 동시에 멈춘다. 이건 단순한 비용 문제가 아니라 운영 연속성 문제다. 매일 발행하는 콘텐츠가 하루 이틀 멈추면 SEO 지표에도 흔적이 남는다.

더 무서운 건 탐지 지연이다. 이번 사건에서 피해자가 "쓰지도 않았는데 토큰이 줄었다"고 발견한 건 어느 정도 운이 좋았기 때문이다. 자동화 봇을 돌리는 팀은 "어차피 봇이 계속 호출하니까"라며 토큰 소비 패턴을 꼼꼼히 들여다보지 않는 경향이 있다. 이상 소비가 노이즈에 묻힌다.

피해가 나면 누가 보상하는가

신용카드가 도용됐을 때는 환급 청구를 할 수 있다. 은행 계좌가 털렸을 때는 보호 절차가 있다. LLM API 토큰이 도용됐을 때는? 지금 시점에선 아무것도 없다.

Anthropic의 서비스 약관을 뜯어봐도 "계정 보안은 사용자 책임"이라는 조항이 핵심이다. 해커가 내 키로 수백만 토큰을 태워도, 청구서는 내 앞으로 온다. AWS 크레덴셜 도용으로 수십만 달러 청구서가 날아온 사례들이 이미 있었고, 피해자들은 제각각 다른 결과를 받았다 — 일부는 면제됐고, 일부는 고스란히 냈다. 어느 쪽이 될지는 지원팀의 선의에 달려 있었다.

LLM 시장은 그 논의조차 아직 시작 전이다. EU AI Act는 고위험 AI 시스템 규제를 다루지만 '토큰 도용으로 인한 소비자 피해 보상'을 명문화하지 않았다. 미국 FTC도 AI 서비스 보안 책임을 벤더에게 얼마나 귀속시킬지 정립 중이다. AI 시대이긴 한데, 규제 속도가 기술 속도를 한참 못 따라간다.

외부 서비스 API 키를 잘못 관리해서 예상치 못한 과금이 발생했을 때 지원팀이 크레딧을 돌려준 경험이 있다. 그때는 안도했지만 — 그건 법적 의무가 아니라 그쪽의 선의였다. 다음에도 그렇게 될 거라는 보장은 없다.

단일 벤더 의존이 만드는 또 다른 리스크

이번 사건을 보안 사고로만 읽으면 놓치는 게 있다. 벤더 리스크의 더 근본적인 면 — 서비스 중단이나 정책 변경이다.

Anthropic이 새로운 사용 정책을 발표하거나, 특정 용도에 대한 API 접근을 제한하면 어떻게 되는가. 우리 팀처럼 LLM 호출이 콘텐츠 생산 파이프라인 전체를 받치고 있는 구조라면, 그 결정 하나가 운영 전체를 흔든다. 대안 경로 없이 단일 벤더에 의존하는 것 자체가 규제 리스크를 내포한다.

물론 지금 당장 멀티 LLM 아키텍처를 구축하는 건 오버엔지니어링이다. 하지만 최소한 핵심 봇 하나 정도는 다른 API로 폴백할 수 있는 구조를 머릿속에 그려두는 것과, 아예 생각조차 안 하는 것은 다르다. 실제로 claude_cli 헬퍼를 교체 가능한 추상 레이어로 두고 있는 것 자체가 이미 좋은 시작이다.

우리 팀이라면 어떻게 막을까

가장 먼저 해야 할 건 키 분리다. 단일 API 키로 모든 봇을 돌리고 있다면, 최소한 개발/스테이징/프로덕션 환경별로 분리해야 한다. 봇 슬러그별로 키를 다르게 쓰면 어느 경로에서 유출됐는지 추적하기도 쉬워진다. 관리할 시크릿 수가 늘어난다는 트레이드오프가 있다 — 그래서 Vault나 AWS Secrets Manager 같은 시크릿 관리 도구 도입을 진지하게 고려해야 한다.

두 번째는 소비 모니터링이다. /opt/common/claude_cli.py 헬퍼를 통해 모든 LLM 호출이 통과한다면, 여기에 일별 토큰 사용량을 로깅하고 임계치 초과 시 Discord 알림을 붙이는 건 하루 작업이다. Anthropic 콘솔의 Usage 탭도 있지만, 그건 내가 능동적으로 들어가봐야 보인다. 봇이 직접 이상을 감지해서 알려줘야 의미 있는 조기 경보가 된다. 평소 일일 토큰 소비량 대비 200% 초과가 오전 중에 발생하면 즉시 알람이 오는 구조, 생각보다 간단하게 구현된다.

세 번째는 인시던트 대응 절차다. 지금 "API 키가 털렸다"는 경보가 오면 우리 팀은 몇 분 만에 키를 교체할 수 있는가. 실제로 해본 적이 없다면, 어디서 교체하는지 모르는 팀원이 있을 수 있다. Anthropic 콘솔 → API Keys → Revoke가 기술적으론 전부지만, 교체 후 각 서버의 .env를 어떤 순서로 업데이트하고 어떤 봇을 재확인해야 하는지 런북이 없으면 사고 상황에서 패닉이 온다.

지금 30분 안에 할 수 있는 것

보안 체계를 하루 만에 다 바꿀 수는 없다. 하지만 오늘 바로 할 수 있는 것들이 있다.

Anthropic 콘솔(console.anthropic.com)에 들어가서 Usage 탭을 열어라. 지난 7일 일별 토큰 사용량 그래프를 보고 패턴 외 스파이크가 있는지 확인한다. 동시에 Settings → API Keys 탭에서 현재 발급된 키 수와 마지막 사용 시각을 확인한다. 오래된 키나 어디서 쓰는지 모르는 키가 있으면 그 자리에서 폐기한다.

그다음, 현재 사용 중인 키가 어디 저장돼 있는지 지도를 그려라. 서버 .env, 팀원 로컬 환경, CI/CD 시크릿 등 키가 존재하는 곳 전부를 목록화한다. 이 목록이 없으면 유출 경로 파악도, 빠른 교체도 불가능하다.

Anthropic 콘솔의 결제 한도 설정도 확인한다. 월 예산의 150%를 초과하면 자동으로 API를 차단하도록 설정하면, 최악의 시나리오에서도 피해를 일정 수준으로 막을 수 있다. 완벽한 방어는 아니지만, 청구서 폭탄을 막는 가장 빠른 안전장치다.

마지막으로 키 교체 런북을 한 페이지로 적어서 팀 내부 위키에 올려라. 침착하게 따라갈 수 있는 순서만 있으면 된다: 콘솔에서 신규 키 발급 → 구 키 폐기 → 서버별 .env 교체 순서 → 봇 재확인. 이 문서가 없으면 실제 사고 났을 때 가장 느린 팀이 된다. 그리고 가장 느린 팀이 가장 많은 토큰을 잃는다.

원문: AI News & Artificial Intelligence | TechCrunch