Claude Code·Codex 계정 공유, 남는 한도를 여러 명이 나눠 쓰는 법

이 글은 Claude Code나 Codex에 사용할 수 있는 계정이 여러 개 준비되어 있고, 그 계정의 남는 사용량을 여러 사람이 나눠 쓰는 상황을 다룬다. 한 사람이 여러 계정을 관리할 수도 있고, 여러 사람이 제공한 계정을 모아 관리할 수도 있다. 각 사용자가 계정을 여러 개씩 갖고 있어야 하는 것은 아니다. 함께 쓸 수 있는 계정이 여러 개 있어야 한다.

예를 들어 세 사람이 Claude Code 계정 A·B·C를 함께 쓴다고 하자. 한 사람은 긴 작업으로 A의 한도를 거의 다 썼지만, B와 C에는 여유가 남아 있다. 매번 어느 계정에 여유가 있는지 확인하고 로그인할 계정을 바꾸는 대신, 서버가 여유 있는 계정을 골라 필요한 사람에게 연결해 주는 구성이다.

Claude Code에는 Claude Code용 계정이, Codex에는 Codex용 계정이 각각 여러 개 필요하다. 한 도구만 쓴다면 그 도구의 계정들만 준비하면 된다. Claude Code 계정 하나와 Codex 계정 하나를 묶어 두 도구의 사용량을 서로 옮겨 쓰는 방식은 아니다.

사용 한도는 계정마다 그대로 적용된다. 같은 계정을 배정받은 사람들은 그 계정의 한도를 나눠 쓴다. 계정 하나를 여러 컴퓨터에 연결해도 한도가 늘어나지는 않으며, 준비한 계정들이 모두 한도에 도달하면 배정할 여유도 없어진다. 이 구성이 필요한 이유는 이미 확보한 여러 계정 사이에서 남는 사용량을 활용하기 위해서다.

계정들을 등록하고 상태를 확인해 인증정보를 배정하는 서버도 준비되어 있어야 한다. 이 글에서는 이 서버를 공급처라고 부른다. 사용자는 공급처에서 고른 계정의 인증정보를 받아 각자의 컴퓨터에서 도구를 실행한다. 사용량이 쌓이면 공급처는 다음에 쓸 여유 있는 계정의 인증정보를 준비한다.

아래에서는 공급처가 준비되어 있다는 전제에서, 공유 계정을 개인 컴퓨터에 연결하는 방법을 설명한다. 나는 평소에는 내 구독 계정으로 작업하고 필요할 때 공유 계정으로 연결한다. 두 계정의 로그인·기록이 섞이지 않게 분리하고, 인증정보를 필요한 실행에만 전달하며, 다음 실행에 쓸 인증정보를 자동으로 준비하는 과정이다. 이미 실행 중인 세션에 새 계정을 반영하는 방법도 뒤에서 다룬다.

두 도구는 인증정보를 어디서 읽나

Claude Code는 시작할 때 여러 곳에서 인증정보를 찾아 정해진 순서대로 하나를 고른다. 이 구성에 해당하는 순서만 보면 셸에 ANTHROPIC_AUTH_TOKEN이나 ANTHROPIC_API_KEY가 있으면 그 값을 먼저 쓴다. 그다음이 구독 토큰을 넣는 환경변수 CLAUDE_CODE_OAUTH_TOKEN, 마지막이 /login으로 저장한 로그인이다. 공유 계정의 토큰은 CLAUDE_CODE_OAUTH_TOKEN으로 넣는다. 앞의 두 변수가 셸에 남아 있으면 공유 토큰보다 먼저 쓰이므로 두 변수는 지워 둔다. Claude Code 인증 문서

로그인은 설정 폴더별로 따로 저장된다. 기본 폴더는 ~/.claude이고 CLAUDE_CONFIG_DIR로 바꿀 수 있다. macOS에서는 로그인 정보를 Keychain에 저장한다. 설정 폴더를 바꾸면 그 폴더에 연결된 Keychain 항목도 따로 생긴다.

Codex는 codex login이 만든 auth.json 파일로 인증한다. 이 파일은 CODEX_HOME(기본 ~/.codex) 아래에 있다. CLI와 IDE 확장, 데스크톱 앱은 이 로그인을 함께 쓴다. 설정에 따라 운영체제 자격증명 저장소에 둘 수도 있지만 여기서는 파일에 저장하는 방식으로 설명한다. Codex 인증 문서

두 도구 모두 세션이 시작할 때 인증정보를 읽고 세션이 끝날 때까지 그 값을 쓴다. 설정 폴더 하나에는 계정 하나만 둘 수 있어서 같은 폴더에서 두 계정을 쓰면 로그인과 기록이 서로 덮어써진다. 이후 구성은 이 두 가지에 맞췄다.

공유 계정을 각자의 환경에 연결하는 구조

네 가지로 구성했다. 그림은 Claude Code 기준이며 Codex는 뒤에서 차이만 설명한다.

1. 설정 폴더 두 개. 내 계정은 기본 폴더를, 공유 계정은 전용 폴더를 쓴다. 작업 방식에 관한 설정만 링크로 공유한다.
2. 공유 계정용 실행 명령. 셸 함수 하나다. 실행할 때 공급처에서 최신 토큰을 받고 전용 폴더를 지정한다. 받은 토큰은 이 실행에만 넣는다. claude를 그냥 실행하면 지금까지처럼 내 계정을 쓴다.
3. Keychain. 공급처에 접속하는 키와 마지막으로 받은 토큰의 사본을 둔다. 평문 파일은 없다.
4. 교체 작업. launchd로 계속 실행하는 셸 스크립트다. 10분마다 현재 토큰의 상태를 확인하고 사용 한도에 가까워지면 새 토큰을 받아 사본을 바꾼다.

Codex도 같은 방식으로 구성했다. 다만 교체 작업이 Keychain 대신 전용 폴더의 auth.json을 직접 바꿔 두고 실행 명령은 CODEX_HOME만 그 폴더로 지정해 실행한다.

계정은 설정 폴더로 나누고 설정은 링크로 공유한다

CLAUDE_CONFIG_DIR을 새 폴더로 지정하면 계정은 바로 나뉜다. 다만 Claude Code는 이 폴더를 기준으로 인증과 설정 전체를 관리한다. 빈 폴더로 시작하면 플러그인과 스킬, 명령, 훅이 모두 없어 처음 설치한 상태가 된다. 그래서 계정별 항목과 작업 방식에 관한 설정을 나눈 뒤 설정만 기본 폴더로 링크한다. 폴더를 바꾸면 ~/.claude.json도 그 폴더 안의 .claude.json으로 옮겨 간다. Claude Code 설정 폴더 문서

두 계정의 대화 기록은 따로 남는다. 공유 계정으로 한 대화는 내 계정에서 --resume으로 이어 갈 수 없다. 개인 MCP 서버도 전용 폴더에서는 따로 등록해야 한다. 설정은 링크로 공유하므로 어느 쪽에서 바꿔도 같다.

설정 파일을 임시 파일에 쓰고 이름을 바꿔 저장할 때는 링크가 유지되지 않는다. 링크가 가리키던 원본 대신 링크 자체가 실제 파일로 바뀐다. 그 뒤로 두 폴더의 설정은 따로 바뀐다. settings.json에서 실제로 이 문제를 겪었다. 한쪽에서 바꾼 설정이 다른 쪽에 보이지 않으면 전용 폴더의 항목이 아직 링크인지부터 확인한다.

새 폴더의 첫 실행 화면

이번 구성에서는 첫 실행 화면을 처리하는 데 가장 오래 걸렸다. 새 폴더에는 온보딩 기록이 없어서 처음 대화형으로 실행하면 테마 선택과 로그인 방식 선택 화면이 뜬다. 토큰과는 관계없는 화면이라 claude -p는 정상적으로 돌아서 더 헷갈린다. 여기서 무심코 로그인하면 내 계정의 로그인 정보가 전용 폴더에 저장된다. 그다음부터는 공유 계정용 명령도 내 계정으로 접속한다.

그래서 기본 폴더의 .claude.json에서 온보딩을 마쳤다는 표식만 전용 폴더로 옮겨 둔다. hasCompletedOnboarding 하나만 옮기면 테마 화면이 계속 떴다. 온보딩 관련 키 몇 개를 함께 옮겨야 화면이 사라졌다. 필요한 키는 가상 터미널로 첫 화면을 캡처해 비교하면서 찾았다. 계정을 식별하는 oauthAccount는 옮기지 않는다. 계정 정보까지 딸려 오기 때문이다.

여기서 얻은 교훈대로 -p가 되더라도 대화형은 따로 확인한다. 구성을 바꾼 뒤에는 직접 들어가 /status로 어느 인증이 쓰이는지 확인한다. 공유 토큰이면 CLAUDE_CODE_OAUTH_TOKEN이 보인다. 내 계정이면 로그인 방식과 이메일이 보인다. 그래도 로그인 선택 화면이 뜨면 아무것도 고르지 말고 빠져나온다.

Codex는 폴더를 셋으로

Codex는 CODEX_HOME으로 같은 일을 한다. 나는 폴더를 셋으로 나눴다.

config.toml과 AGENTS.md, 스킬, 훅은 기본 폴더로 링크해 함께 쓰고 auth.json과 세션, 기록, 상태 데이터베이스는 폴더마다 따로 둔다. 여러 프로세스가 같은 상태 데이터베이스를 쓰면 깨질 수 있다.

Codex에서 폴더를 나눈 가장 큰 이유는 로그아웃으로 생기는 문제였다. 공유 계정으로 연결한 상태에서 codex logout이나 codex login을 실행하면 로컬 파일이 지워지고 제공자 쪽에서도 그 계정의 인증정보를 무효화한다. 같은 인증정보를 받아 쓰던 다른 사람과 기기의 연결도 한꺼번에 끊긴다. 공유 계정을 기본 폴더에 두면 평소 습관대로 로그아웃했다가 다른 사람의 연결까지 끊게 된다. 전용 폴더에 두면 codex를 그냥 쳐도 내 계정에 적용되므로 공유 계정에는 영향을 주지 않는다. 공유 계정의 로컬 인증정보만 지우려면 로그아웃하지 말고 그 폴더의 auth.json만 지운다. 교체 작업이 10분 안에 인증정보를 다시 저장한다.

인증정보는 실행할 때 그 실행에만 넣는다

공유 토큰을 넣는 가장 쉬운 방법은 셸 설정 파일에서 CLAUDE_CODE_OAUTH_TOKEN과 CLAUDE_CONFIG_DIR을 전역으로 설정하는 것이다. 편한 대신 두 가지 문제가 생긴다. 환경변수가 로그인보다 우선하므로 claude를 그냥 쳐도 공유 계정으로 연결되므로 내 계정으로는 연결할 수 없다. 그 셸에서 띄운 편집기 같은 다른 프로세스에도 토큰이 전달된다. 명령줄 인자로 토큰을 넘기는 방법도 피한다. 인자가 프로세스 목록에 그대로 보이기 때문이다.

그래서 실행 명령은 서브셸 안에서만 환경변수를 설정한 뒤 그 안에서 도구를 띄운다. 토큰은 그 도구 프로세스와 자식 프로세스에만 있고 명령을 친 셸에는 남지 않는다. 환경변수는 자식 프로세스에도 상속되므로 완전한 격리는 아니다. 그래도 셸 전체에 두는 것보다 토큰이 전달되는 범위가 훨씬 좁다.

토큰은 도구를 실행할 때 공급처에서 직접 받는다. Keychain 사본은 교체 작업이 10분마다 갱신한다. 그 사이에 공급처 쪽 토큰이 바뀌면 사본에는 이전 값이 남는다. 실제로 사본보다 공급처 쪽이 최신인 경우를 봤다. 공급처는 평소 0.1초 안에 응답해 실행이 느려지지 않는다. 5초 안에 응답이 없을 때만 사본으로 시작한다.

Codex에서는 교체 작업이 전용 폴더의 auth.json을 늘 최신으로 유지하므로 실행 명령은 CODEX_HOME만 지정하면 된다. 대신 교체 작업에서는 새 인증정보를 임시 파일로 받아 올바른 JSON인지 검사한 뒤 기존 파일과 내용이 다를 때만 교체한다. 실행 중인 도구가 읽는 파일을 10분마다 불필요하게 바꾸지 않기 위해서다. 그렇다고 같은 사본을 오래 쓰지는 않는다. 공급처가 토큰 갱신을 맡으므로 같은 계정이라도 인증정보가 새로 발급된다. 실제로 옛 사본이 서버에서 무효화되는 것을 본 적이 있다.

키와 토큰은 Keychain에 둔다

공급처에 접속하는 키와 토큰 사본은 macOS Keychain에만 둔다. 저장할 때 security 명령에 접근 권한을 주면 launchd로 도는 교체 작업도 암호 창 없이 읽을 수 있다.

구성을 마친 뒤에는 토큰이 노출되는 곳이 없는지 네 군데를 확인한다. 명령을 친 셸의 환경변수, 프로세스 목록의 인자, 셸 히스토리, .zshrc 같은 셸 설정 파일이다. 실제로 이 파일에서 평문 키를 발견했다. 복사해 붙인 셸 설정 블록에서 환경변수가 없을 때 쓰는 기본값이었다. Keychain에서 읽도록 바꾸고 노출된 키는 폐기했다. 기기마다 키를 따로 발급해 두면 한 대에서 노출되더라도 그 키만 폐기하면 된다.

Keychain을 쓰면서 알게 된 것이 셋 있다.

• 입력한 값이 128자에서 잘릴 수 있다. security add-generic-password에 값을 프롬프트로 입력하거나 표준 입력으로 넘기면 128자에서 잘린다. 프롬프트에는 입력한 글자가 보이지 않는다. 확인 입력도 똑같이 잘린 채 통과하므로 이 과정에서는 알아챌 방법이 없다. sk-proj-로 시작하는 OpenAI 프로젝트 키는 164자라 반드시 잘린다. 이 키만은 값을 인자로 넘겨 저장했고 프로세스 목록에 잠깐 보이는 것은 감수했다. 저장한 뒤에는 값이 있는지만 보지 않고 길이를 확인한다. 정확히 128자면 잘린 값이다.
• 기존 항목의 갱신이 느리다. 기존 항목을 덮어쓰는 데 20초, 30초씩 걸렸다. 교체 작업을 다시 실행한 직후에는 4분 가까이 걸린 적도 있다. 같은 시각에 새 항목을 만드는 데는 0.03초면 됐다. 그래서 기존 항목을 지우고 새로 만들도록 바꿨더니 0.5초로 줄었다. 삭제와 생성 사이에 아주 잠깐 항목이 없어지지만 실행 명령은 공급처에 먼저 요청하므로 영향이 없다.
• 로그인 암호를 재설정하면 로그인 키체인이 통째로 격리된다. 옛 암호를 입력하지 않고 암호를 바꾸면 macOS는 로그인 키체인을 새 암호로 다시 암호화하지 못한다. 다른 관리자 계정에서 재설정할 때가 그렇다. 대신 기존 키체인을 login_renamed_N이라는 이름으로 옮겨 두고 빈 키체인을 새로 만든다. 격리된 키체인은 마지막으로 동기화됐던 옛 암호로만 열리고 FileVault 복구 키로도 열 수 없다. 내 경우 90개 넘는 항목이 잠겼고 1년 전 날짜의 login_renamed_1도 이미 있었으니 이전에 암호를 바꿨을 때도 같은 일이 조용히 일어났다. 옛 암호가 떠오르지 않아 키는 모두 다시 발급했다. 로그인한 상태에서 시스템 설정의 Touch ID 및 암호 → 암호 변경으로 암호를 바꾸면 간단히 예방할 수 있다. 이 경로에서는 옛 암호를 입력하므로 키체인도 함께 다시 암호화된다.

교체 작업은 백그라운드에서 실행하고 실패해도 종료하지 않는다

교체 작업은 셸 스크립트 하나로 처리한다. 시작할 때 토큰을 한 번 받아 Keychain에 저장하고 이후 10분마다 공급처에서 현재 토큰의 상태를 확인한다. 사용 한도에 가까워졌거나 토큰을 쓸 수 없으면 새 토큰을 받아 사본을 바꾼다. 로그에는 토큰 값 대신 상태만 남긴다.

launchd로 이 스크립트를 계속 실행한다. 사용자 LaunchAgent로 등록해 RunAtLoad로 로그인할 때 시작하고 KeepAlive로 종료되면 다시 실행한다. plist는 ~나 $HOME을 풀어 주지 않으므로 경로는 절대 경로로 적는다.

처음 스크립트는 첫 토큰을 받지 못하면 오류를 내고 종료했고 이 때문에 큰 문제가 생겼다. launchd는 종료된 프로세스를 재시작 간격(ThrottleInterval, 30초로 설정)이 지나면 다시 실행한다. 공급처가 잠깐 토큰을 주지 못하거나 Keychain에 키가 없으면 종료와 재시작을 반복하며 30초마다 공급처에 요청을 보낸다. 토큰을 받지 못하던 이틀 동안 1,700번 재시작했다. 실패해도 종료하지 않도록 고쳤다. 키가 없으면 생길 때까지, 토큰을 받지 못하면 다음 주기까지 루프 안에서 기다린다. 자동으로 재시작되는 스크립트에서 "실패하면 종료"는 "실패하면 30초마다 재시도"와 같은 말이다.

고장처럼 보였던 로그 공백은 잠자기 때문이었다. 맥이 잠들면 교체 작업도 함께 멈춘다. pmset -g log의 잠자기 시각과 로그가 비는 시각을 맞춰 보면 된다. 공급처는 요청을 받을 때마다 가장 여유 있는 계정을 고른다. 그래서 10분마다 인증정보를 새로 받는 Codex 쪽 로그에서 계정이 자주 바뀌어도 정상이다.

자동으로 되는 일과 사람이 할 일

새 인증정보를 받아 두는 데까지만 자동화했다. 이미 실행 중인 세션은 사람이 직접 바꾼다.

Claude Code는 세션을 시작할 때 환경변수를 한 번 읽고 Codex도 auth.json을 시작할 때 읽는다. Codex는 로그인한 계정의 토큰을 사용 중에 스스로 갱신한다. 다만 내가 본 범위에서는 바깥에서 파일을 다른 계정 것으로 바꿔도 반영하지 않았다. 교체 작업이 사본을 B로 바꿔도 실행 중인 세션은 A로 계속 요청한다. A의 한도를 다 쓰면 그 세션은 더 쓸 수 없다. 세션을 끝내고 실행 명령으로 다시 띄우면 최신 토큰을 읽는다. 기록은 전용 폴더에 남아 있으므로 --resume으로 이어 가면 된다. Codex 데스크톱 앱은 창을 닫아도 프로세스가 계속 실행되므로 완전히 종료한 뒤 다시 열어야 새 인증정보를 읽는다.

스크립트에서 headless로 쓸 때는 실행 옵션도 확인한다. --bare로 띄우면 CLAUDE_CODE_OAUTH_TOKEN을 아예 읽지 않는다. 공유 토큰으로 돌리려면 --bare를 빼야 한다. 종량제 API 키를 쓸 때는 apiKeyHelper처럼 실행 중에도 키를 다시 받아 오는 공식 기능이 있다. 이 글에서는 구독 토큰을 환경변수로 넣으므로 세션을 다시 띄워야 한다.

정리

기본 원칙은 셋이다. 계정은 설정 폴더로 나누고 작업 방식은 링크로 공유한다. 인증정보는 셸 전체에 넣지 않고 실행할 때 그 프로세스에만 넣는다. Keychain에 보관하고 launchd로 교체 작업을 실행한다.

운영하며 얻은 규칙을 다섯 줄로 적었다.

1. 공유 계정은 전용 폴더에 둔다. 실수로 로그아웃하지 않게.
2. 백그라운드 작업은 실패해도 종료하지 않는다. 감시 기능이 다시 실행하면 재시작 루프가 된다.
3. 인증정보는 Keychain에만 두고 저장한 뒤에는 길이를 확인한다. 갱신할 때는 기존 항목을 지우고 새로 만든다.
4. 로그인 암호는 재설정하지 말고 변경한다.
5. 인증정보를 받아 두는 것까지만 자동화한다. 세션을 다시 띄우는 일은 사람이 한다.