Claude Code를 회사 규칙대로 굴린다 — Anthropic이 '앱 게이트웨이'를 열었어

개발팀 리드 입장에서 한번 생각해보자. Claude Code를 회사 전체에 풀고 싶은데, 문제는 딱 하나야. "누가 API 키를 몇 개나 만들었는지" 아무도 모른다는 거지. 신입이 들어오면 키 하나 새로 발급해주고, 퇴사자가 생기면 그 키를 찾아서 지우는 걸 깜빡하고, 분기 말에 클라우드 비용 청구서가 날아오면 어느 팀이 얼마를 썼는지 계산하느라 스프레드시트와 씨름하고. 이게 지금 대부분 회사에서 AI 코딩 툴을 굴리는 방식이야. 편리한 건 둘째치고, 보안팀이 이 얘기를 들으면 바로 눈살을 찌푸릴 상황이지.

이번 주 Anthropic이 이 문제를 정면으로 겨냥한 발표를 했어. 이름하여 "Claude apps 게이트웨이". Amazon Bedrock과 구글 클라우드 Vertex AI 위에서 Claude Code를 돌릴 때, 자격증명이 사방에 흩어지고 수작업 설정이 쌓이는 그 익숙한 골칫거리를 없애주는 자체 호스팅 컨트롤 플레인이야. 문서에는 마이크로소프트 Foundry도 언급돼 있어서, 세 개의 주요 클라우드 플랫폼을 아우르겠다는 그림인 거야.

핵심은 간단해. 개발자는 이제 API 키를 손에 쥐고 다닐 필요가 없어. 회사 SSO로 로그인하면 끝이야. 관리자는 누가 어떤 권한으로 Claude Code에 접근하는지, 얼마를 쓰고 있는지, 정책을 어떻게 강제할지를 한 군데에서 관리할 수 있게 됐어. 규제가 빡빡한 금융, 의료, 정부 관련 산업에서 AI 코딩 툴을 도입하려면 이 정도 통제력이 없으면 애초에 검토 테이블에도 못 올라가거든. 그 벽을 Anthropic이 스스로 허물고 나선 셈이야.

등장인물 (The players)

이 이야기의 주인공은 당연히 Anthropic이야. Claude Code라는 제품을 대기업들이 실제로 대량 도입하게 만들기 위해서, 이번엔 모델 성능이 아니라 "관리와 통제"라는 전혀 다른 영역에서 승부를 걸었어. 지금까지 Anthropic이 개발자들 사이에서 쌓아온 평판은 훌륭했지만, 그 평판이 실제 기업 구매 결정으로 이어지려면 IT 부서와 보안팀을 통과해야 하는데, 이번 게이트웨이는 바로 그 관문을 스스로 만들어서 넘겨준 거야.

두 번째 등장인물은 클라우드 플랫폼들이야. Amazon Bedrock, 구글 클라우드 Vertex AI, 그리고 문서상 언급된 마이크로소프트 Foundry. 이들은 이미 수많은 대기업이 워크로드를 올려놓은 인프라이자, 동시에 IAM(자격 증명 및 접근 관리)과 컴플라이언스 체계를 가장 촘촘하게 갖춘 곳들이야. Anthropic 입장에서는 이 클라우드들 위에서 자연스럽게 동작하는 게이트웨이를 만드는 게, 고객이 이미 신뢰하는 인프라 위에 자기 제품을 얹는 가장 빠른 길이었던 거지.

세 번째는 기업의 플랫폼 엔지니어링팀과 보안팀이야. 이들이 진짜 의사결정권자야. 개발자가 아무리 Claude Code를 쓰고 싶어해도, 보안팀이 "자격증명 관리 체계가 없다"고 반려하면 그걸로 끝이거든. 이번 게이트웨이는 사실상 이 사람들을 설득하기 위해 만들어진 제품이야. 스테이트리스 컨테이너, PostgreSQL 백엔드, ID 공급자 연동 같은 단어들이 등장하는 이유가 바로 여기 있어.

마지막으로 잊지 말아야 할 건 현장의 개발자들이야. 이들에게는 이번 변화가 "API 키를 관리해야 하는 번거로움"이 사라지고 "회사 계정으로 로그인만 하면 되는" 경험으로 바뀌는 거야. 겉보기엔 사소해 보이지만, 매일 여러 개의 자격증명을 돌려쓰던 사람 입장에선 꽤 큰 변화지.

핵심 내용 (How the gateway works)

구조부터 보면 생각보다 심플해. 게이트웨이는 리눅스에 배포되는 스테이트리스 컨테이너 하나야. "스테이트리스"라는 말이 중요한데, 컨테이너 자체는 상태를 저장하지 않고, 실제 데이터는 뒤에 붙는 PostgreSQL 데이터베이스가 담당해. 이 구조 덕분에 필요하면 컨테이너를 여러 개 띄워서 부하를 분산시키거나, 문제가 생기면 컨테이너만 갈아치우고 데이터베이스는 그대로 유지하는 식의 운영이 가능해져. 인프라 엔지니어들이 좋아할 만한 설계야.

이 컨테이너가 하는 일은 크게 네 가지야. 첫째, 업스트림 자격증명을 보유해. 즉, Bedrock이나 Vertex AI에 접근하는 진짜 열쇠는 게이트웨이가 쥐고 있고, 개별 개발자에게는 나눠주지 않아. 둘째, 개발자를 회사의 ID 공급자(IdP)에 대고 인증해. 셋째, 관리형 설정을 배포하고 강제해. 넷째, 사용자별 사용량을 회사가 운영하는 수집기(collector)로 보고해. 이 네 가지가 합쳐지면 "누가, 언제, 얼마나" 썼는지가 자동으로 기록되는 시스템이 완성되는 거야.

로그인 경험도 확 달라져. 개발자는 API 키나 클라우드 자격증명을 손에 쥐고 있을 필요가 없어. 회사 IdP로 로그인하면, 게이트웨이가 짧은 수명의 베어러 토큰(bearer token)을 발급해줘. 이 토큰의 기본 수명은 세션당 1시간이야. 그리고 이 구조의 진짜 장점은 오프보딩(퇴사자 처리)에서 드러나. 관리자가 IdP에서 해당 사용자를 삭제(deprovision)하기만 하면, 그 사람의 게이트웨이 접근 권한은 세션 수명 안에 자동으로 만료돼. 예전처럼 "그 사람이 갖고 있던 API 키가 어디 있는지" 찾아 헤맬 필요가 없어지는 거야.

아래 표로 정리해보면 이해가 더 빠를 거야.

항목 기존 방식 (API 키/클라우드 자격증명) Claude apps 게이트웨이
로그인 방식 개별 API 키 발급·보관 회사 SSO 로그인
접근 토큰 장기 유효 키 단기 베어러 토큰(기본 1시간)
퇴사자 처리 키를 수동으로 찾아 폐기 IdP에서 삭제만 하면 자동 만료
비용 추적 팀·개인별 수동 집계 사용자별 자동 보고
정책 적용 개별 설정, 일관성 낮음 중앙에서 배포·강제

지원 대상 클라우드는 Amazon Bedrock과 구글 클라우드 Vertex AI가 중심이고, 문서에는 마이크로소프트 Foundry도 함께 언급돼 있어. 즉 특정 클라우드에 종속되지 않고, 기업이 이미 쓰고 있는 인프라 위에 그대로 얹을 수 있게 설계된 거야. 이 부분이 "브링유어오운클라우드(bring-your-own-cloud)"라는 표현으로 요약돼.

각자의 이득 (What each side gains)

Anthropic이 가장 크게 얻는 건 "규제 산업으로 가는 문"이야. 지금까지 아무리 좋은 모델을 만들어도, 은행이나 병원, 정부 기관 같은 곳은 API 키를 손으로 발급하고 관리하는 체계로는 애초에 도입 검토 자체가 시작되지 않았어. 보안팀이 첫 미팅에서 "자격증명 관리는 어떻게 하냐"고 물었을 때 명쾌한 답이 없으면 그걸로 끝이거든. 이번 게이트웨이는 그 질문에 대한 답을 통째로 준비해서 들고 나온 셈이야. 문서에서 강조하는 세 가지 — 브링유어오운클라우드 아키텍처, 엔터프라이즈 SSO, 감사 로깅 — 이 정확히 규제 산업 보안팀이 체크리스트에 올려두는 항목들이야.

기업 고객이 얻는 건 훨씬 실무적이야. 우선 자격증명 관리 부담이 확 줄어. API 키가 여기저기 흩어져서 누가 어떤 키를 갖고 있는지 파악이 안 되던 상황에서 벗어나, 회사 IdP 하나로 접근을 통제할 수 있게 돼. 퇴사자 처리도 IdP에서 계정 하나만 지우면 끝나니까, 이전처럼 여러 시스템을 돌아다니며 키를 회수할 필요가 없어져. 그리고 사용자별 비용 추적이 자동화되니까, "이번 분기에 어느 팀이 Claude Code를 얼마나 썼는지" 같은 질문에 스프레드시트 없이 바로 답할 수 있게 돼.

클라우드 플랫폼들도 조용히 이득을 봐. Bedrock이나 Vertex AI 위에서 Claude Code가 잘 굴러간다는 건, 결국 그 클라우드 위에 워크로드가 더 많이 얹힌다는 뜻이거든. 기업이 이미 AWS나 구글 클라우드에 인프라를 갖고 있다면, 굳이 새로운 벤더의 인프라로 옮기지 않고 기존 클라우드 계약 안에서 Claude Code를 도입할 수 있어. 이건 클라우드 플랫폼 입장에서도, 기존 고객을 자기 생태계 안에 더 단단히 묶어두는 효과가 있어.

개발자 개인에게 돌아가는 이득은 소소하지만 확실해. API 키를 발급받고, 어디 안전하게 보관하고, 만료되면 다시 갱신하고 하는 그 반복 작업이 사라져. 회사 계정으로 로그인하는 익숙한 흐름 하나로 대체되니까, 새로운 프로젝트에 합류하거나 팀을 옮길 때도 접근 권한 문제로 발을 묶이는 일이 줄어들 거야.

과거 유사 사례 — 성공과 실패 (Precedents: wins and failures)

기업용 소프트웨어 역사를 돌아보면, "게이트웨이"나 "프록시" 형태로 접근 통제를 중앙화하는 시도는 늘 있어왔어. API 게이트웨이라는 개념 자체가 이미 마이크로서비스 시대에 자리를 잡았고, 여러 개의 백엔드 서비스에 대한 인증·인가·로깅을 한 군데로 모으는 방식은 검증된 패턴이야. Anthropic이 이번에 한 일도 본질적으로는 같은 아이디어를 AI 코딩 툴에 적용한 거라고 볼 수 있어. 이미 성공 사례가 쌓여있는 아키텍처 패턴 위에 올라탔다는 점에서는 상당히 안전한 선택이야.

SSO와 IdP 연동이 기업 소프트웨어 도입의 필수 조건이 된 흐름도 비슷한 맥락이야. 예전에는 여러 개의 SaaS 툴마다 별도 계정을 만들고 관리해야 했지만, 지금은 SSO 지원 없이는 기업 고객을 확보하기 어려운 시대가 됐어. 특히 보안에 민감한 산업일수록 "SSO 없음"은 도입 검토 리스트에서 바로 탈락하는 조건이야. Anthropic이 이번 게이트웨이에서 SSO를 세 가지 비타협 조건 중 하나로 못 박은 것도 이런 업계 흐름을 그대로 따라간 거라 볼 수 있어.

반면 실패 사례도 참고할 만해. 중앙화된 컨트롤 플레인은 잘 만들면 강력하지만, 잘못 만들면 오히려 "단일 장애점(single point of failure)"이 돼버려. 게이트웨이 하나가 다운되면 회사 전체 개발자가 Claude Code에 접근하지 못하는 상황이 벌어질 수 있다는 뜻이야. 과거에 여러 기업들이 사내 프록시나 게이트웨이 시스템을 도입했다가, 운영 부담과 장애 대응 복잡도 때문에 오히려 개발 생산성이 떨어졌다는 사례들이 종종 보고돼왔어. 이번 게이트웨이가 스테이트리스 컨테이너 구조를 택하고 여러 인스턴스를 띄울 수 있게 설계한 것도, 바로 이런 실패를 의식한 선택으로 읽혀.

또 하나 참고할 지점은, 이런 종류의 엔터프라이즈 인프라 제품은 발표 시점과 실제 대규모 도입 사이에 시간차가 크다는 거야. 문서와 기능이 아무리 잘 갖춰져 있어도, 실제로 수천 명 규모의 조직이 기존 워크플로우를 이 게이트웨이로 옮기기까지는 파일럿, 보안 검토, 단계적 롤아웃 같은 과정을 거쳐야 해. 지금 시점에서는 "가능해졌다"는 것과 "실제로 널리 쓰이고 있다"는 것 사이에 아직 거리가 있다고 보는 게 맞아.

경쟁자 카운터 플레이 (Rivals' counterplay)

AI 코딩 툴 시장은 지금 Claude Code 혼자만의 리그가 아니야. GitHub Copilot을 비롯해 여러 경쟁 제품들이 이미 기업 시장을 겨냥하고 있고, 이들도 하나같이 엔터프라이즈용 관리 기능, SSO 연동, 사용량 대시보드 같은 것들을 갖추는 방향으로 움직여왔어. 이번 게이트웨이 발표는 Anthropic이 이 영역에서 "우리도 준비됐다"는 걸 명확히 보여주는 카드지만, 동시에 경쟁사들도 비슷한 기능을 이미 갖고 있거나 조만간 대응책을 내놓을 가능성이 커.

특히 마이크로소프트 입장이 흥미로워. 이번 발표 문서에 마이크로소프트 Foundry가 지원 대상으로 함께 언급됐다는 건, Anthropic이 마이크로소프트 인프라 고객까지 끌어안으려 한다는 뜻이야. 그런데 마이크로소프트는 동시에 Copilot이라는 자체 코딩 툴을 밀고 있는 회사이기도 해. 즉 마이크로소프트 클라우드 위에서 Claude Code가 잘 돌아가게 만드는 동시에, 같은 인프라 위에서 마이크로소프트의 경쟁 제품과도 맞붙는 묘한 구도가 만들어지는 거야. 클라우드 인프라 협력과 제품 경쟁이 동시에 벌어지는 셈이지.

아마존과 구글도 단순히 인프라만 빌려주는 입장은 아니야. 두 회사 모두 자체적으로 AI 모델과 개발자 도구를 밀고 있고, Bedrock이나 Vertex AI 위에 여러 모델 제공사의 제품을 나란히 올려놓는 "멀티모델 마켓플레이스" 전략을 취하고 있어. Claude Code용 게이트웨이가 이 클라우드들 위에서 잘 돌아간다는 건 좋은 소식이지만, 동시에 같은 클라우드 위에서 다른 AI 코딩 툴들과 나란히 비교당하는 위치에 서게 된다는 뜻이기도 해.

경쟁사들의 대응은 아마 두 갈래로 나뉠 거야. 하나는 자기들도 비슷한 자체 호스팅 게이트웨이나 온프레미스 컨트롤 플레인을 서둘러 내놓는 것이고, 다른 하나는 이미 갖고 있던 엔터프라이즈 기능을 더 적극적으로 마케팅하며 "우리는 이미 하고 있었다"는 메시지를 내는 것. 어느 쪽이든, 이번 발표가 AI 코딩 툴 시장에서 "엔터프라이즈 관리 기능"이 성능 경쟁 못지않게 중요한 전선이라는 걸 다시 한번 확인시켜준 셈이야.

그래서 뭐가 달라지는데 (So what changes)

플랫폼 엔지니어나 IT 관리자 입장에서는 확실히 일이 줄어들어. 예전엔 개발자 한 명 한 명에게 API 키를 발급하고, 그 키가 어디서 어떻게 쓰이는지 추적하고, 퇴사자가 생기면 수동으로 키를 찾아 없애는 과정을 반복했어. 이제는 회사 IdP 하나만 관리하면 접근 통제, 정책 강제, 비용 추적이 자동으로 따라와. 특히 보안 감사를 준비할 때, "누가 언제 무엇에 접근했는지"를 게이트웨이 로그 하나로 설명할 수 있다는 건 꽤 큰 무게를 덜어주는 일이야.

개발자 입장에서는 겉으로 드러나는 변화는 크지 않을 수 있어. 여전히 Claude Code를 쓰는 경험 자체는 비슷할 거야. 다만 로그인 방식이 API 키에서 회사 계정 SSO로 바뀌고, 세션이 기본 1시간마다 갱신되는 구조로 바뀌면서, "내가 갖고 있던 키가 언제 만료되는지" 신경 쓸 필요가 없어져. 대신 회사가 정한 역할별 접근 정책 안에서 움직이게 되니까, 예전보다 자유도는 살짝 줄어들 수도 있어.

규제 산업에 속한 회사들에게는 이번 발표가 실질적인 도입 문턱을 낮춰주는 계기가 될 가능성이 커. 금융이나 의료, 정부 관련 조직들은 지금까지 AI 코딩 툴 도입을 검토하면서도 자격증명 관리와 감사 로깅 요건 때문에 주저해온 경우가 많았어. 브링유어오운클라우드 구조로 자체 인프라 안에서 게이트웨이를 운영할 수 있고, SSO와 감사 로깅이 기본으로 딸려온다면, 그동안 보류돼왔던 도입 검토가 다시 테이블 위에 올라올 수 있어.

경영진이나 예산을 쥔 사람들 입장에서는 사용자별 비용 추적과 지출 한도(spend cap) 기능이 특히 반가울 거야. 지금까지는 AI 코딩 툴 도입을 승인하면서도 "이게 결국 얼마나 나갈지" 예측하기 어려웠던 게 사실이거든. 이제는 팀별, 사용자별로 지출 상한을 걸어둘 수 있고, 실제 사용량이 실시간으로 집계되니까, 예산 관리 차원에서 AI 도구 도입을 훨씬 편하게 승인할 수 있는 환경이 만들어진 거야.

🥄 남은 궁금증 세 가지

— 이거 도입하면 회사가 게이트웨이 서버를 직접 운영해야 하는 거야? 맞아. 스테이트리스 컨테이너와 PostgreSQL 데이터베이스를 리눅스 환경에 직접 배포하고 운영하는 구조야. 즉 클릭 몇 번으로 끝나는 SaaS가 아니라, 플랫폼팀이 인프라를 책임지고 관리해야 하는 자체 호스팅 모델이라는 뜻이야. 이 부담을 감수할 만큼 규모가 큰 조직에 우선 맞는 방식일 거야.

— API 키를 아예 안 쓰게 되는 거야, 완전히? 개발자 개인 입장에서는 그렇다고 봐도 돼. 업스트림 자격증명은 게이트웨이가 대신 보유하고, 개발자는 회사 IdP 로그인과 단기 베어러 토큰만으로 접근하거든. 다만 게이트웨이 자체가 클라우드에 접속할 때 쓰는 자격증명은 여전히 존재해. 그 열쇠를 게이트웨이 한 곳으로 모았다는 게 핵심이야.

— 마이크로소프트 Foundry 지원은 언제부터 완전히 되는 거야? 문서에는 마이크로소프트 Foundry가 함께 언급돼 있지만, Bedrock과 구글 클라우드만큼 구체적인 세부 사항까지 확인된 건 아니야. 세 플랫폼이 동시에 동일한 수준으로 지원되는 건지, 순차적으로 확대되는 건지는 단정하긴 일러. 공식 문서를 계속 지켜봐야 할 부분이야.

참고 자료

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