앤트로픽, 'sk-ant-' 정적 API 키를 버린다 — 단기 토큰 인증 WIF 정식 출시

AI 에이전트 시대, '영원히 안 만료되는 키'를 폐기하다

자, 핵심부터. 앤트로픽이 6월 17일 Claude 플랫폼에 Workload Identity Federation(WIF)을 정식 출시(GA)했어. 한 줄로 말하면, 'sk-ant-...'로 시작하는 영원히 안 만료되는 정적 API 키 대신, 몇 분이면 만료되는 단기 OIDC 토큰으로 Claude API에 인증하게 만드는 기능이야. 화려한 모델 발표는 아니지만, AI를 실제 프로덕션에 굴리는 사람에겐 진짜 중요한 '보이지 않는 인프라'야.

왜 이게 큰 뉴스냐. AI 에이전트가 폭발적으로 늘면서, '에이전트가 어떻게 안전하게 인증하느냐'가 새로운 보안 급소가 됐거든. 지금까지는 대부분 정적 API 키를 코드나 CI 설정에 박아 썼어. 그런데 이 키는 한 번 만들면 안 만료되고, 깃허브에 실수로 올리거나 로그에 찍히면 그대로 유출돼. AI 에이전트가 수십·수백 개씩 돌아가는 환경에서 이런 '영구 비밀'을 뿌리는 건 점점 큰 위험이 됐어. WIF는 그 뿌리를 뽑겠다는 거야.

게다가 타이밍이 의미심장해. 같은 6월, 이 사이트는 'AgentJacking'이라는 에이전트 탈취 공격(Sentry MCP·Claude Code·Cursor 대상)을 다뤘고, 기업 AI가 '도입에서 ROI·거버넌스로' 넘어가는 국면도 짚었어. AI를 전 직원에, 수많은 에이전트로 푸는 시대가 오면서 '에이전트의 신원과 권한을 어떻게 통제하느냐'가 핵심 과제로 떠올랐거든. WIF는 그 흐름 한가운데서 나온 '에이전트 신원 관리'의 한 조각이야.

그래서 오늘 풀 이야기는 이거야. WIF가 정적 키와 뭐가 다른지, '단기 토큰 인증'이 왜 AI 에이전트 시대에 중요한지, 그리고 이게 보안 문제를 어디까지 풀고 어디부터는 못 푸는지. 핵심 개념 셋만 잡으면 그림이 잡혀.

등장인물 — 정적 API 키, OIDC 토큰, 그리고 서비스 계정

먼저 오늘의 '구악(舊惡)', 정적 API 키. 'sk-ant-...'로 시작하는 긴 문자열인데, 이게 있으면 누구든 Claude API를 그 권한으로 호출할 수 있어. 문제는 이 키가 '영원히 산다'는 거야. 한 번 발급하면 직접 폐기하기 전엔 안 만료돼. 그래서 CI 설정에 저장하고, 주기적으로 교체하고, 혹시 유출됐나 노심초사하는 운영 부담이 늘 따라붙었지. 깃허브에 실수로 커밋되거나 로그에 한 줄 찍히는 순간, 영구 비밀이 통째로 새는 거야.

다음은 오늘의 주인공 OIDC 토큰. OIDC(OpenID Connect)는 'AWS다', 'GitHub Actions다', '쿠버네티스 파드다' 같은 신원을 표준 방식으로 증명하는 규격이야. WIF의 핵심은 워크로드(에이전트·서버·CI 작업)가 이미 자기가 속한 신원 공급자(IdP)에서 받은 OIDC 토큰을 Claude에 내밀면, Claude가 그걸 검증하고 '몇 분짜리' 단기 액세스 토큰을 발급해주는 거야. 이 토큰은 금방 만료돼서, 유출돼도 피해 시간이 극도로 짧아. '영원히 사는 키' 대신 '곧 죽는 토큰'을 쓰는 게 핵심 전환이야.

세 번째는 둘을 잇는 다리, 서비스 계정과 페더레이션 규칙. 작동 방식은 이래. 관리자가 '페더레이션 규칙'을 만들어 외부 신원(예: 특정 AWS IAM 역할)을 Claude의 '서비스 계정'에 묶어둬. 그러면 그 신원을 가진 워크로드가 요청할 때, Claude가 OIDC 토큰의 클레임(주장)을 규칙과 대조하고, 서비스 계정에 부여된 역할 범위 안에서만 단기 토큰을 내줘. 그리고 모든 교환과 요청이 그 서비스 계정 단위로 감사 로그에 남아. 누가·무엇이·언제 접근했는지가 추적되는 거지.

이 셋의 관계를 한 문장으로 묶으면 이래. 영원히 사는 정적 키(구악)를 버리고, 이미 있는 신원 공급자가 발급한 단기 OIDC 토큰(주인공)을, 페더레이션 규칙으로 서비스 계정에 묶어(다리) 검증·발급·감사한다. 이게 이야기의 뼈대야.

핵심 내용 — WIF가 뭘 바꾸나

말로 풀면 흩어지니까, 확인된 사실을 표로 보자.

항목	내용
정식 출시(GA)	2026년 6월 17일, Claude 플랫폼
한 줄 요약	정적 API 키 대신 단기 OIDC 토큰으로 인증
토큰 수명	몇 분 단위 (정적 키는 '안 만료')
지원 신원 공급자	AWS IAM, Google Cloud, GitHub Actions, 쿠버네티스, SPIFFE, Microsoft Entra ID, Okta 등 표준 OIDC
작동 방식	페더레이션 규칙으로 외부 신원 → 서비스 계정 바인딩
감사	모든 교환·요청이 서비스 계정 단위로 로그 기록
보안 효과	저장·교체·유출할 정적 비밀 자체가 없어짐
하위 호환	기존 API 키도 계속 작동, 자동화 하나씩 점진 이전 가능

표를 한 줄씩 보자. 우선 **'토큰 수명 몇 분'**이라는 게 핵심이야. 정적 키가 위험한 건 '유출되면 영원히 위험하다'는 점이거든. 반면 단기 토큰은 유출돼도 몇 분 뒤면 죽어. 공격자가 쓸 수 있는 창이 극도로 좁아지는 거지. '비밀을 잘 숨기자'에서 '비밀이 새도 금방 무용지물이 되게 하자'로 보안 철학이 바뀌는 셈이야.

두 번째로 **'이미 있는 신원 공급자를 쓴다'**는 점이 실용적으로 중요해. 새 비밀 체계를 처음부터 만드는 게 아니라, 기업이 이미 운영하는 AWS·GCP·Okta 같은 IdP를 그대로 활용하거든. 'AWS에서 도는 워크로드면 AWS가 보증한 신원을 그대로 Claude에 제출'하는 식이야. 그래서 도입 마찰이 적고, AI 에이전트의 인증을 회사의 기존 보안 체계 안으로 자연스럽게 편입시킬 수 있어.

세 번째로 하위 호환이 현실적인 배려야. 기존 sk-ant- 키도 계속 작동하니까, 회사는 자동화를 하나씩 점진적으로 옮기면 돼. 새로 만드는 빌드는 처음부터 '키 없이' 시작하고, 오래된 스크립트는 마이그레이션할 때까지 계속 돌아가는 거지. '한 번에 다 갈아엎어야 한다'는 부담 없이 들어갈 수 있게 한 게, 실제 운영 현실을 아는 설계야.

각자의 이득 — 누가 뭘 얻나

앤트로픽의 이득부터 보자. 첫째, 엔터프라이즈 신뢰 강화야. 대기업이 AI를 프로덕션에 깊게 쓰려면 '보안·감사·거버넌스'가 필수 전제인데, WIF는 정확히 그 체크리스트를 채워줘. 둘째, 'AI 에이전트 인프라의 표준'을 선점하는 효과. 에이전트가 폭증하는 시대에 '에이전트는 어떻게 인증해야 하는가'의 모범 답안을 먼저 제시하는 거지. 셋째, 보안을 이유로 도입을 망설이던 보수적 고객(금융·의료 등)의 진입 장벽을 낮추는 의미도 커.

기업 고객·개발자의 이득도 분명해. 가장 큰 건 운영 부담과 유출 위험의 동시 감소야. 정적 키를 만들고, CI에 저장하고, 주기적으로 교체하고, 유출 안 됐나 모니터링하던 그 모든 수고가 사라져. 키가 아예 없으니 '키 유출 사고' 자체가 원천 차단되는 거지. 게다가 모든 접근이 서비스 계정 단위로 감사 로그에 남으니, '누가 우리 Claude를 호출했나'를 추적하는 거버넌스도 쉬워져. 보안과 편의를 동시에 챙기는 흔치 않은 조합이야.

그리고 의외의 변수는 **'완벽한 해결은 아니다'**라는 점이야. 보안 업계(Aembit, Security Boulevard 등)는 WIF를 환영하면서도 "이게 모든 걸 풀진 않는다"고 짚었어. 단기 토큰이 정적 키보다 안전한 건 맞지만, 신원 공급자(IdP) 자체가 뚫리거나, 페더레이션 규칙을 느슨하게 설정하거나, 토큰을 발급받은 워크로드가 탈취되면 여전히 위험은 남거든. WIF는 '키 유출'이라는 한 문제를 잘 풀지만, '신원·권한 관리 전체'를 자동으로 안전하게 만들어주진 않아. 도구가 좋아도 설정과 운영은 여전히 사람 몫이야.

종합하면, 단기 손익은 앤트로픽(엔터프라이즈 신뢰·표준 선점)과 고객(운영 부담·유출 위험 감소) 양쪽 다 플러스야. 다만 'WIF만 켜면 안전하다'고 안심하는 건 위험하고, 페더레이션 규칙을 얼마나 촘촘히 설계하느냐, IdP를 얼마나 잘 지키느냐가 진짜 안전을 가른다는 점은 기억해야 해.

과거 유사 사례 — 성공과 실패

'영구 비밀을 단기 토큰으로 바꾼다'는 발상, 사실 클라우드 업계가 먼저 갔어. AWS의 IAM 역할, GCP의 워크로드 아이덴티티가 정확히 같은 철학이야. 오래 사는 액세스 키 대신 짧게 사는 임시 자격증명을 발급해 유출 피해를 줄이는 거지. 이 방식은 클라우드 보안의 사실상 표준이 됐고, 성공의 핵심은 '개발자가 별 노력 없이 더 안전해진다'는 데 있었어. 앤트로픽이 이 검증된 모델을 AI API에 그대로 가져온 건 영리한 행보야. 바퀴를 다시 발명하지 않고, 이미 작동하는 표준을 채택한 거니까.

근데 실패 사례, 즉 '좋은 보안 도구가 무용지물이 된' 경우도 똑똑히 봐야 공정해. 아무리 좋은 인증 체계도 '느슨하게 설정하면' 의미가 없어. 권한을 과도하게 넓게 주거나, 페더레이션 규칙을 대충 짜면, 단기 토큰이라도 너무 많은 걸 할 수 있게 돼. 클라우드 보안 사고의 상당수가 'IAM을 잘못 설정해서' 터졌다는 걸 떠올리면, WIF도 같은 함정을 피해 가진 못해. 도구가 안전을 보장하는 게 아니라, 도구를 안전하게 쓰는 운영이 안전을 보장하는 거야.

또 하나 균형 잡힌 시각은 'WIF는 보안의 끝이 아니라 시작'이라는 거야. 같은 6월에 다뤘던 AgentJacking 같은 공격은 'API 키 유출'이 아니라 'AI 에이전트의 행동 자체를 조종'하는 방식이었어. WIF는 인증(누가 접근하나)을 단단히 하지만, 인가된 에이전트가 '나쁜 일을 하도록 속는' 위협까지 막진 못해. 즉 WIF는 AI 보안 퍼즐의 중요한 한 조각이지, 전체 그림은 아니야.

그래서 균형 잡힌 결론은 이래. '영구 비밀을 단기 토큰으로'라는 WIF의 방향은 클라우드 보안이 검증한 정석이고 분명히 옳지만, 진짜 안전은 도구가 아니라 그 도구를 얼마나 촘촘히 설정·운영하느냐가 가른다. 보안의 역사가 알려주는 교훈은 하나야. 가장 흔한 사고는 도구의 결함이 아니라 설정의 허술함에서 난다는 것.

경쟁자 카운터 플레이

앤트로픽이 이렇게 나오면 경쟁자들이 가만히 있을까? 첫 번째는 OpenAI·구글 등 다른 모델 회사야. AI 에이전트가 폭증하는 만큼 '에이전트 인증'은 모든 플랫폼의 공통 과제거든. 앤트로픽이 WIF로 표준을 제시하면, 경쟁사들도 비슷한 단기 토큰·페더레이션 방식을 따라올 가능성이 커. 결국 'AI 에이전트는 정적 키가 아니라 단기 신원으로 인증한다'가 업계 표준으로 굳어지는 흐름이지. 누가 먼저, 누가 더 매끄럽게 하느냐의 경쟁이야.

두 번째는 마이크로소프트의 'Entra Agent ID' 같은 신원 플랫폼이야. 마이크로소프트는 이미 AI 에이전트에게 기업 신원을 부여하는 체계를 밀고 있어. 흥미롭게도 WIF는 Microsoft Entra ID를 신원 공급자로 지원하니까, 경쟁이자 동시에 협력 관계야. 'AI 에이전트의 신원을 누가 발급하고 관리하느냐'를 놓고, 모델 회사(앤트로픽)와 신원 플랫폼 회사(마이크로소프트)가 겹치는 영역에서 줄다리기를 하는 그림이지.

세 번째는 에이전트 보안 스타트업들이야. WIF가 '인증'을 표준화하면, 그 위에서 '인가된 에이전트의 행동을 감시·통제하는' 도구의 수요가 커져. 같은 6월 펀딩을 받은 Ent.AI(AI 워크스페이스 보안) 같은 회사들이 이 틈을 노려. 모델 회사가 인증 기반을 깔면, 스타트업들이 그 위에 '에이전트 행동 보안'이라는 상위 계층을 쌓는 분업 구도가 만들어지는 거야.

그리고 잊지 말 변수, 표준화의 양날. WIF가 OIDC라는 개방형 표준을 쓴다는 건, 특정 벤더에 종속되지 않는다는 장점이자, 동시에 '누구나 비슷하게 만들 수 있다'는 뜻이기도 해. 즉 WIF 자체가 앤트로픽만의 해자가 되긴 어려워. 진짜 차별점은 '인증 표준'이 아니라, 그 위에 쌓는 거버넌스·감사·에이전트 관리 경험에서 나올 거야. 이번 출시는 'AI 에이전트 보안'이라는 긴 경쟁의 출발선이지 결승선이 아니야.

그래서 뭐가 달라지는데 — 입장별로

개발자·플랫폼 엔지니어라면. 주목할 건 '키 관리에서 신원 관리로의 전환'이야. 그동안 sk-ant- 키를 안전하게 숨기고 교체하던 수고가, 'IdP 신원을 Claude에 연결하는' 설정으로 바뀌어. 당장 기존 키도 작동하니 급할 건 없지만, 새 프로젝트는 처음부터 WIF로 시작하는 게 장기적으로 안전하고 편해. 'AI 에이전트의 신원과 권한을 설계하는' 능력이 점점 중요한 역량이 되는 흐름이야.

기업 보안 담당자라면. 교훈은 '도구 도입이 곧 안전은 아니다'라는 거야. WIF는 키 유출이라는 큰 구멍을 막아주지만, 페더레이션 규칙을 느슨하게 짜거나 IdP를 허술하게 지키면 새 구멍이 생겨. 그러니 WIF를 켜는 것과 동시에, '어떤 워크로드에 어떤 권한을, 얼마나 좁게 줄지'를 촘촘히 설계해야 해. 그리고 서비스 계정 단위 감사 로그를 실제로 들여다보는 운영이 따라와야 의미가 있어.

기업 의사결정자라면. 이 사건의 의미는 'AI를 프로덕션에 깊게 쓰려면 보안 인프라부터 갖춰야 한다'는 거야. 멋진 모델을 도입하는 것과, 그 모델을 수많은 에이전트로 안전하게 굴리는 건 다른 문제거든. WIF 같은 '보이지 않는 인프라'가 받쳐줘야 금융·의료처럼 규제가 센 분야도 AI를 본격적으로 쓸 수 있어. 화려한 발표보다 이런 기반 기술이 실제 도입의 문을 여는 열쇠라는 걸 기억할 만해.

세 입장을 관통하는 한 줄은 이거야. AI 에이전트가 폭증하는 시대의 진짜 과제는 '더 똑똑한 모델'만이 아니라 '에이전트를 안전하게 인증·통제하는 인프라'이고, WIF는 그 한 조각이다. 진짜 가치는 도구를 켜는 데가 아니라, 그 위에 촘촘한 권한·감사 운영을 쌓는 데서 확인될 거야.

🥄 남은 궁금증 세 가지

— 그래서 WIF만 켜면 우리 AI는 안전해? 단정하긴 일러. WIF는 '정적 키 유출'이라는 큰 구멍을 잘 막아주지만, 그게 보안의 전부는 아니야. 페더레이션 규칙을 느슨하게 짜거나 신원 공급자(IdP)가 뚫리면 여전히 위험이 남거든. 보안 업계도 "WIF가 옳은 방향이지만 모든 걸 풀진 않는다"고 짚었어. 도구를 켜는 것과 안전하게 운영하는 건 다른 얘기야.

— 기존 API 키는 이제 못 쓰는 거야? 아니야. 앤트로픽이 하위 호환을 유지해서 기존 sk-ant- 키도 계속 작동해. 그래서 한 번에 다 갈아엎을 필요 없이, 자동화를 하나씩 점진적으로 옮기면 돼. 새로 만드는 빌드는 처음부터 키 없이 시작하고, 오래된 스크립트는 마이그레이션할 때까지 그대로 두는 식으로. 급하게 서두를 필요는 없되, 새 프로젝트부터 적용하는 게 합리적이야.

— 이게 왜 'TOP 뉴스'야? 그냥 기능 추가 아냐? 표면적으론 작은 기능 같지만, 맥락이 커. AI 에이전트가 전 직원·수백 개로 퍼지는 시대(같은 달 '도입에서 거버넌스로' 국면 전환을 기억해)엔, '에이전트를 어떻게 안전하게 인증하느냐'가 도입의 전제 조건이 되거든. WIF는 그 보이지 않는 기반을 까는 일이라, 화려하진 않아도 'AI를 진짜 프로덕션에 쓰게 만드는' 중요한 한 수야.

참고 자료

• Workload Identity Federation (WIF) is now generally available on the Claude Platform — Anthropic
• Workload Identity Federation — Claude API Docs
• Anthropic Workload Identity Federation: What It Gets Right – and What It Still Doesn't Solve — Security Boulevard
• Your AI Agent Doesn't Need an API Key: Entra Agent ID and Anthropic's Workload Identity Federation — DEV Community
• Anthropic Makes Static API Keys Optional With Workload Identity Federation — imisofts

수치는 발표 시점 기준이라 바뀔 수 있어.