ChatGPT 계정으로 “로컬 OpenAI API”처럼 쓰는 법: openai-oauth 정리

API 키 발급과 과금 설정이 번거로워서, “일단 로컬에서만 빠르게 실험해보고 싶은데…” 같은 상황 많죠.
최근 GitHub에 올라온 openai-oauth는 ChatGPT(정확히는 Codex) 로그인 토큰(OAuth)으로 OpenAI 호환 엔드포인트를 로컬에 띄우는 방식이라, 프로토타이핑에 꽤 흥미로운 선택지예요.

1) openai-oauth가 뭔가요? (핵심 아이디어)

요약하면, openai-oauth는 **localhost 프록시(proxy)**를 만들어서 chatgpt.com/backend-api/codex/responses로 요청을 중계해줘요.
그 결과, 내 PC에서 http://127.0.0.1:10531/v1 같은 OpenAI 호환(Base URL) API를 쓰는 것처럼 호출할 수 있어요.

중요한 포인트는 API 키가 필요 없다는 점이에요. 대신 내 로컬에 저장된 Codex/ChatGPT 인증 캐시(auth.json) 를 사용해요.
즉 “공식 OpenAI API 크레딧”이 아니라, ChatGPT 계정 쪽의 인증/한도 체계(Codex 경로)를 활용하는 구조로 이해하면 됩니다.

2) 가장 쉬운 사용법: npx openai-oauth로 로컬 엔드포인트 열기

요약은 간단해요. 터미널에서 한 줄 실행하면 로컬에 OpenAI 호환 서버가 떠요.

• 실행: npx openai-oauth
• 준비되는 엔드포인트: http://127.0.0.1:10531/v1
• 특징: No API key required
• 모델: gpt-5.4, gpt-5.3-codex 등 계정에서 접근 가능한 Codex 모델을 자동 탐색

이게 유용한 상황은 딱 이런 경우예요.
로컬에서 Cursor, Continue, 자체 스크립트, 사내 PoC 도구가 “OpenAI base URL만 바꾸면” 붙을 수 있을 때, API 키/결제 없이 형태를 빨리 검증할 수 있거든요.

3) Vercel AI SDK용: openai-oauth-provider로 코드에 붙이기

요약하면, CLI로 프록시를 띄우는 방식 말고도 Vercel AI SDK Provider 형태로도 제공돼요.
즉 앱 코드에서 createOpenAIOAuth()로 클라이언트를 만들고, generateText() 같은 호출로 바로 연결할 수 있어요.

기사의 예시는 아래 흐름이죠.

• createOpenAIOAuth()로 Provider 생성
• generateText({ model: openai("gpt-5.4"), prompt: ... }) 형태로 호출
• 결과는 result.text로 수신

이 방식은 프론트/백엔드에서 “OpenAI Provider 갈아끼우듯” 실험할 때 장점이 커요.
예를 들어 “기존에 Vercel AI SDK로 OpenAI 연결하던 프로젝트”라면, 키 관리/과금 세팅 없이 로컬 인증 기반으로 빠르게 동작 확인이 가능해집니다.

4) 지원 기능: 무엇이 되고, 어디까지 되는가

요약하면, openai-oauth는 “대부분의 기본 호출 경험”을 목표로 이미 꽤 갖춰져 있어요.
프로젝트 README 기준으로 현재 동작하는 것들은 다음이에요.

• 지원 엔드포인트
  • /v1/responses : Responses API 스타일 호출
  • /v1/chat/completions : ChatCompletions 호환
  • /v1/models : 기본은 계정 접근 가능 모델을 자동 인식, 또는 --models로 제한 가능
• Streaming Responses(스트리밍 응답)
  • 타이핑처럼 토큰이 흘러나오는 UX 만들 때 필수라 실사용성이 커요.
• Toolcalls(도구 호출)
  • 함수 호출(툴 호출) 기반 에이전트/워크플로 구성에서 중요해요.
• Reasoning Traces(추론 트레이스)
  • 디버깅/분석용으로 “모델이 어떤 단계를 거쳤는지” 확인이 필요한 경우 도움이 됩니다.

이 구성만으로도, 로컬에서 “에이전트 + 스트리밍 UI + 툴 호출”까지 한 번에 실험해볼 수 있는 셈이에요.

5) 설정 옵션: --port, --host, --models가 의미 있는 이유

요약하면, 설정은 “로컬 프록시 운영”에 필요한 것들이고 CLI/Provider가 코어 설정을 공유해요.
특히 아래 옵션들이 실전에서 자주 쓰일 만해요.

• --port (기본 10531)
  • 이미 다른 도구가 포트를 쓰고 있으면 충돌나기 쉬워요. 개발환경에서 포트 바꾸는 건 필수 스킬이죠.
• --host (기본 127.0.0.1)
  • 기본은 로컬 바인딩이라 안전한 편이에요. 실수로 외부에 열리면 위험해질 수 있는 성격이라 더 중요합니다.
• --models (모델 allowlist)
  • 팀/프로젝트에서 “이 모델만 쓰자”를 강제하거나, 도구에서 모델 목록이 너무 길어 혼란일 때 깔끔하게 정리할 수 있어요.
• --base-url (기본 upstream: https://chatgpt.com/backend-api/codex)
  • 상위 엔드포인트를 바꾸는 옵션인데, 일반 사용자는 기본값을 건드릴 일은 많지 않아요.
• OAuth 관련(--oauth-file, --oauth-client-id, --oauth-token-url)
  • 인증 파일 위치가 특이한 환경(예: 여러 계정, 여러 툴 공존)에서 유용해요.

6) 한계와 주의사항: “무료”보다 중요한 리스크 정리

요약하면, README도 분명히 말하듯 이 프로젝트는 비공식(community-maintained) 이고, 토큰을 다루는 방식이 매우 민감해요.

알려진 제한도 있어요.

• Codex에서 지원되는 LLM만 사용 가능
  • “OpenAI 전체 모델”을 다 쓰는 게 아니라, 내 계정/플랜에서 Codex 경로로 노출되는 모델에 따라 달라져요.
• 로그인 플로우가 포함되어 있지 않음
  • npx @openai/codex login으로 auth 파일을 만들어야 해요.
• CLI /v1/responses는 상태 저장형 리플레이가 없음
  • 프록시는 stateless(무상태)라서, 대화 히스토리는 호출자가 매번 전체 컨텍스트를 포함해 보내야 해요.

가장 중요한 건 보안/컴플라이언스예요.

• 로컬 auth 파일(~/.codex/auth.json 등)은 비밀번호급 자격증명으로 취급해야 해요.
• README는 개인·로컬·신뢰 가능한 머신에서만, 호스팅 서비스로 운영하지 말 것, 토큰 공유/풀링 금지 등을 강하게 권고해요.
• OpenAI 약관/정책 위반 소지가 생기면 레이트리밋/정지/종료 같은 리스크는 사용자 책임입니다.

마무리: “로컬 실험”엔 강력하지만, 운영은 신중하게

openai-oauth는 API 키 없이도 OpenAI 호환 엔드포인트를 로컬에서 빠르게 열어볼 수 있는 도구라는 점에서, 프로토타이핑 속도를 확 올려줘요.
특히 스트리밍, 툴콜, 모델 목록 같은 실전 요소가 이미 갖춰져 있어서 “데모/PoC 제작”에 잘 맞습니다.

다만 인증 토큰을 다루는 구조 자체가 민감하니, 정말로 README가 말하듯 개인 로컬에서만 가볍게 테스트해보는 용도로 접근하는 걸 추천해요.
오늘 할 일은 하나예요: 로컬에서만 npx openai-oauth로 띄워보고, 여러분이 쓰는 클라이언트의 Base URL을 http://127.0.0.1:10531/v1로 바꿔 실제로 붙는지 확인해보세요.