-
오픈클로에 Claude·Codex·Gemini 붙이기 — OAuth는 막히고 AgentRuntime은 되는 이유IT 2026. 9. 20. 21:00

▶ 동영상 개요 — 오픈클로에 Claude·Codex·Gemini 붙이기 — OAuth는 막히고 AgentRuntime은 되는 이유
5분 40초 — 오픈클로에서 구독형 모델을 붙일 때 OAuth 토큰 재사용은 신분 위장이라 정책 위반이고, 공식 CLI를 서브프로세스로 감싸는 AgentRuntime 방식은 벤… — NotebookLM 동영상 개요로 생성 🎧 오디오 개요 — 오픈클로에 Claude·Codex·Gemini 붙이기 — OAuth는 막히고 AgentRuntime은 되는 이유
18분 19초 — 오픈클로에서 구독형 모델을 붙일 때 OAuth 토큰 재사용은 신분 위장이라 정책 위반이고, 공식 CLI를 서브프로세스로 감싸는 AgentRuntime 방식은 벤…. 화면은 이 글의 인포그래픽 한 장 고정 — NotebookLM 오디오 개요로 생성 집에서 오픈소스 AI 어시스턴트 오픈클로(OpenClaw)를 띄워 쓰고 있다. 텔레그램으로 말을 걸면 답을 주고, 파일을 뒤지고, 웹을 검색하는 자기 호스팅 에이전트다. 처음엔 직접 돌리는 로컬 모델로만 붙여 뒀는데, 어려운 작업에서는 아무래도 상용 모델이 낫다. 그래서 이미 결제해 둔 Claude·ChatGPT·Gemini 구독을 그대로 오픈클로에 물려 쓰면 되겠다고 생각했다.
그런데 붙이는 방법을 뒤지다 이상한 지점에서 멈칫했다. 같은 "Claude를 붙인다"인데 OAuth 방식은 정책 위반이고 AgentRuntime(에이전트 런타임) 방식은 허용이라는 것이다. 둘 다 내 구독으로 내가 쓰는 건데 왜 하나는 되고 하나는 안 될까. 파고들수록 이건 오픈클로만의 문제가 아니라, 2026년 상반기에 상용 LLM 벤더들이 그은 새 경계선의 문제였다. Anthropic은 2026년 2월에 구독 토큰의 서드파티 사용을 명시적으로 금지했고, Google은 6월 18일에 소비자용 Gemini CLI 로그인을 닫았다. 그 경계가 정확히 어디를 지나는지 정리해 본다.
먼저 용어부터 — 프로바이더와 에이전트 런타임은 다르다
오픈클로 문서는 모델에 닿는 경로를 프로바이더(provider)와 에이전트 런타임(agent runtime) 두 층으로 나눈다. 프로바이더는 "누구로 로그인하고 어떤 모델 목록을 쓸 수 있는지" 곧 인증과 모델 발견을 맡는 층이다. 에이전트 런타임은 "프롬프트를 받아 실제로 모델을 굴리고, 도구 호출을 처리하고, 완성된 턴을 돌려주는" 실행 엔진이다. 쉽게 말해 프로바이더는 신분증이고, 런타임은 실제로 일을 굴리는 손이다.
이 둘이 갈리기 때문에 "구독을 붙인다"가 두 가지 전혀 다른 그림이 된다. 하나는 구독 계정의 인증 토큰을 오픈클로가 직접 들고 벤더 API를 때리는 그림이고, 다른 하나는 벤더가 만든 공식 CLI(명령줄 도구)를 오픈클로가 겉에서 실행만 하는 그림이다.
위 다이어그램이 보여주는 것은 같은 요청이 오픈클로에서 두 갈래로 갈라진다는 점이다. "방식 1 — OAuth 프로바이더" 쪽으로 가면 오픈클로가 구독 계정에서 뽑은 인증 토큰을 스스로 들고 벤더의 API 서버를 직접 두드린다. "방식 2 — 에이전트 런타임" 쪽으로 가면 오픈클로는 API를 직접 부르지 않고, 벤더가 배포한 공식 명령줄 도구를 하위 프로세스로 띄워 그 도구가 대신 호출하게 둔다. 겉보기 결과는 똑같이 "Claude가 답을 줬다"지만, 실제로 벤더 서버에 접속한 주체가 다르다. 이 "누가 호출했느냐"의 차이가 정책 위반과 정상 사용을 가르는 선이다.
OAuth 방식이 왜 막히는가 — 구독 토큰 재사용은 신분 위장이다
OAuth(Open Authorization, 비밀번호를 넘기지 않고 "이 앱이 내 계정을 쓰도록 허가"하는 표준 인증 방식)로 로그인하면, 앱은 계정 대신 액세스 토큰이라는 일회용 열쇠를 받는다. Claude Code나 ChatGPT 앱이 로그인 버튼을 눌렀을 때 받는 것도 이 토큰이다. 문제는 이 토큰이 그냥 문자열이라, 마음만 먹으면 뽑아내 다른 도구에 붙여 넣을 수 있다는 것이다. 오픈클로 같은 서드파티가 그 토큰을 들고 벤더 API를 부르면, 벤더 입장에서는 공식 앱이 부른 것처럼 보이지만 실제로는 아니다.
Anthropic은 2026년 2월 법무·컴플라이언스 문서를 고쳐 이 지점을 못박았다. 요지는 이렇다 — Claude Free·Pro·Max 계정으로 얻은 OAuth 토큰을 다른 제품·도구·서비스에서 쓰는 것은 허용되지 않으며, 여기에는 Agent SDK도 포함된다. 그 토큰이 정상적으로 쓰일 수 있는 곳은 Claude Code와 Claude.ai 같은 Anthropic 자체 앱뿐이다. 서드파티 도구를 만들 거면 구독 토큰이 아니라 콘솔에서 발급한 API 키로 정식 과금 경로를 타라는 것이다.
왜 이렇게까지 막을까. 이유는 기술이 아니라 경제다. Claude Max 구독은 월 200달러 안팎에 넉넉한 사용량을 준다. 같은 양을 API로 그대로 사면 1,000달러가 넘는다. 구독은 벤더가 손해를 감수하며 싸게 파는 상품인데, 그 싼 구독 토큰을 빼내 서드파티 도구로 우회하면 사실상 비싼 API를 싼값에 쓰는 차익거래가 된다. Anthropic은 여기에 더해 서드파티 트래픽이 "평소 텔레메트리(계측 신호) 하나 없는 낯선 패턴"으로 들어와 지원과 디버깅을 어렵게 만든다는 점도 들었다.
엄포로 끝난 게 아니다. 또 다른 오픈소스 코딩 에이전트 OpenCode는 Anthropic의 법무 요청을 받았다며 커밋 메시지에 그 사유를 적고 Claude 지원을 통째로 들어냈다. 구독 토큰을 뽑아 쓰는 길은 이렇게 실제로 닫혔다.
AgentRuntime 방식이 왜 되는가 — 벤더의 손을 그대로 빌린다
그럼 AgentRuntime 방식은 뭐가 다르길래 허용될까. 핵심은 호출을 오픈클로가 하지 않는다는 데 있다. 오픈클로의
claude-cli런타임은 Anthropic이 배포한 공식 명령줄 도구를 하위 프로세스로 띄워claude -p(비대화형 실행 모드) 같은 명령으로 실제 모델 호출을 넘긴다. 오픈클로는 대화의 흐름만 조율하고, 벤더 서버에 접속하는 주체는 벤더가 만든 공식 클라이언트 그 자신이다. 인가된 하네스(harness, 모델을 감싸 실행을 통제하는 공식 실행기)가 자기 신원으로 호출하니, 벤더가 금지한 "낯선 서드파티의 토큰 재사용"에 해당하지 않는다.이 차이를 두 그림으로 나눠 보면 선명하다.
첫 번째 그림은 OAuth 토큰 재사용이다. 구독 계정에서 뽑아낸 토큰을 오픈클로가 자기 안에 저장해 두고, 벤더 API를 향해 마치 공식 앱이 부르는 것처럼 호출을 흉내 낸다. 벤더 서버에는 "공식 클라이언트라면 당연히 따라와야 할 계측 신호가 하나도 없는 정체불명 트래픽"으로 찍힌다. 이게 Anthropic이 금지한 바로 그 그림이다.
두 번째 그림은 AgentRuntime 방식이다. 오픈클로는 API 근처에도 가지 않고, 벤더의 공식 CLI를 실행만 시킨다. 벤더 서버에 접속하는 건 벤더가 직접 배포한 그 클라이언트라, 트래픽이 인가된 하네스의 정상 사용으로 인식된다. 오픈클로가 하는 일은 "이 질문을 공식 도구에 넘기고 답을 받아 대화에 이어 붙이는" 오케스트레이션뿐이다. 실제로 오픈클로는
claude-cli런타임을 두고 Anthropic 측이 이 방식의 Claude CLI 재사용을 용인했다고 밝히고 있다. 다만 이건 벤더의 방침에 기댄 것이라 언제든 바뀔 수 있어서, 상용 서비스를 만들 거라면 여전히 API 키가 안전한 길이다.놓치기 쉬운 함정이 하나 있다. "그럼 토큰만 안 뽑으면 다 되는 거네"가 아니다. 정책의 경계는 토큰을 어디서 얻었느냐가 아니라 최종 호출을 누구의 클라이언트가 하느냐에 있다. 공식 CLI를 실행하는 순간 그 CLI가 자기 인증으로 붙으니 문제가 없는 것이고, 그 인증을 가로채 오픈클로가 직접 붙는 순간 위장이 된다. 같은 구독, 같은 계정이어도 "손"이 누구냐가 다르면 결과가 갈린다.
세 벤더의 태도가 제각각이다 — Claude·Codex·Gemini
여기서 한 발 더 들어가면 재미있어진다. "OAuth는 안 되고 AgentRuntime은 된다"는 깔끔한 규칙처럼 들리지만, 실제로는 벤더마다 그은 선이 다르다. 같은 OAuth 재사용도 어떤 벤더는 막고 어떤 벤더는 오히려 공식 지원한다.
이 다이어그램이 정리하는 것은 세 벤더의 서로 다른 정책이다. "Anthropic Claude"는 구독 OAuth 토큰을 빼서 쓰는 것은 막았지만, 공식 CLI를 감싸 실행하는 방식은 용인한다. "OpenAI Codex"는 한 발 더 관대해서, ChatGPT 구독 OAuth를 Codex CLI 바깥에서 쓰는 것까지 명시적으로 허용했다 — 실제로 OpenAI가 오픈클로용 Codex OAuth를 열어 줬다. "Google Gemini"는 반대 방향으로 갔다. 소비자용 Gemini CLI의 "Google 계정으로 로그인"을 2026년 6월 18일에 닫았고, 실험적 도구 Antigravity의 약관도 서드파티 접근을 금지한다. 그래서 Gemini를 오픈클로에 붙이려면 구독이 아니라 AI Studio나 Vertex에서 발급한 유료 API 키를 써야 한다.
왜 이렇게 갈릴까. Anthropic은 앞서 본 대로 구독 차익거래를 막는 데 가장 단호하다. OpenAI는 "내 ChatGPT 계정으로 서드파티에 로그인하면 그 도구가 내 사용량 한도를 대신 쓴다"는 구조를 오히려 성장 지렛대로 열어 뒀다. Google은 소비자 로그인 경로 자체를 걷어내고 과금이 명확한 API 키로 사용자를 몰았다. 세 회사가 같은 질문("싼 구독을 서드파티가 우회해도 되는가")에 각기 다른 답을 낸 셈이다.
그래서 실무 결론은 하나로 안 떨어진다. Codex는 OAuth로 붙여도 되고, Gemini는 OAuth 길이 아예 없어 API 키를 사야 하며, Claude는 토큰을 빼면 안 되지만 공식 CLI를 런타임으로 감싸면 된다. "어느 벤더냐"를 먼저 확인하지 않고 "OAuth 되냐 안 되냐"만 물으면 답을 못 찾는다.
정리 — 경계는 토큰이 아니라 "누가 부르느냐"에 있다
구독형 모델을 자기 호스팅 에이전트에 붙일 때, 진짜 물어야 할 질문은 "이 토큰을 써도 되나"가 아니라 "최종 호출을 누구의 클라이언트가 하는가"다. 벤더가 만든 공식 도구를 그대로 실행하면 그 도구가 자기 신분으로 붙으니 정책 안에 남고, 그 인증을 가로채 내 도구가 직접 붙으면 신분 위장이 되어 선을 넘는다. 오픈클로가 프로바이더와 에이전트 런타임을 굳이 두 층으로 나눈 것도 이 경계를 코드 차원에서 구분해 두기 위해서다.
내 경우엔 결론이 단순해졌다. 급하지 않은 작업은 로컬 모델로 계속 돌리고, 상용 모델이 꼭 필요하면 토큰을 뽑아 우회하는 유혹 대신 공식 CLI를 런타임으로 감싸거나 정식 API 키를 쓰기로 했다. 월정액을 아끼려다 계정이 정지되면 그게 더 비싸다. 무엇보다 이 경계선은 2026년 들어 반년 사이에도 여러 번 움직였으니, 붙이기 전에 그 벤더의 현재 방침을 한 번 더 확인하는 습관이 결국 가장 싸게 먹힌다.
참고한 공개 자료:
- Model providers · OpenClaw — https://docs.openclaw.ai/concepts/model-providers
- Agent runtimes · OpenClaw — https://docs.openclaw.ai/concepts/agent-runtimes
- OAuth · OpenClaw — https://docs.openclaw.ai/concepts/oauth
- Legal and compliance · Claude Code Docs — https://code.claude.com/docs/en/legal-and-compliance
- Anthropic clarifies ban on third-party tool access to Claude · The Register — https://www.theregister.com/2026/02/20/anthropic_clarifies_ban_third_party_claude_access/
- Using Codex with your ChatGPT plan · OpenAI Help Center — https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
- Google (Gemini) · OpenClaw — https://docs.openclaw.ai/providers/google
이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.
'IT' 카테고리의 다른 글
Acorn은 플러그인도 테마도 아니다 — 워드프레스 안에 라라벨을 심는 물건의 정체와 2026년 현황 (0) 2026.09.21 라라벨은 워드프레스에 필수가 아니다 — 그런데도 '많이 쓴다'고 들리는 이유 (0) 2026.09.21 Amazon ECR로 Traefik·WordPress 업데이트하기 — 이미지를 어디서 당겨올지 내가 정한다는 것 (0) 2026.09.19 OpenClaw는 Lobster의 승인자를 어떻게 지원하나 — 문에서는 신원을 인증하고, 승인자는 환경변수로 흘려보낸다 (1) 2026.09.18 Lobster에서 멈춘 워크플로우를 다시 달리게 하기 — 재개 토큰과 승인자 신원은 같은 호출에서 만난다 (0) 2026.09.17 Lobster의 approval 게이트 — 승인을 프롬프트로 부탁하는 것과 런타임이 멈추는 것은 다른 물건이다 (0) 2026.09.17 Lobster의 .lobster 파일은 LLM을 빼지 않는다 — 판단만 남기고 분기를 파서에게 넘긴다 (0) 2026.09.17 도커가 다른 네트워크의 컨테이너를 막는 법 — iptables와 FORWARD 사슬이라는 검문소 (0) 2026.09.16 0.0.0.0에 listen한다는 것과 네임스페이스의 포트 — 컨테이너는 호스트의 포트를 나눠 쓰지 않는다 (0) 2026.09.16 PerspectiveGap — 최상위 모델 62%, 평균 17%. 오케스트레이션 프롬프팅은 코딩 실력과 다른 능력이었다 (0) 2026.09.15