ChatGPT·GPT API 에러 4종, 원인별 해결법 총정리

Prompt Architect · 2026-06-17 · 9분

TL;DR — "Something went wrong", 401, 429, 모델 사용 한도까지. ChatGPT 웹 사용자와 OpenAI API 개발자가 가장 자주 만나는 4가지 에러를 실제 메시지와 원인, 단계별 해결법으로 정리했다. 특히 같은 429라도 rate limit인지 insufficient_quota인지 구분하는 법이 핵심이다.

"또 Something went wrong이야?" — 어느 새벽의 디버깅

새벽 두 시, 운영 중인 서비스의 분석 기능이 갑자기 500을 뱉기 시작했다. 프론트는 멀쩡한데 백엔드 로그를 까보니 Error code: 429. 처음엔 "트래픽이 몰렸나?" 싶어 레이트리밋부터 의심했는데, 정작 에러 본문에는 insufficient_quota라고 적혀 있었다. 한마디로 호출이 많아서가 아니라 결제 크레딧이 바닥나서 멈춘 거였다. 만약 그날 백오프 재시도 로직만 더 짰다면 영원히 안 고쳐졌을 문제다.

ChatGPT와 OpenAI API를 쓰다 보면 이런 식으로 "겉보기 증상"과 "진짜 원인"이 어긋나는 경우가 정말 많다. 이 글에서는 웹/앱 ChatGPT 일반 사용자와 API를 코드로 호출하는 개발자가 가장 자주 마주치는 4가지 에러를, 실제 에러 메시지 → 원인 → 단계별 해결 순서로 풀어본다. 시니어 입장에서 "이건 이렇게 빨리 끊고 가라"는 실전 우선순위까지 같이 적었다.

laptop showing code error on screen

먼저, 두 부류의 사용자부터 나누자

문제 해결의 절반은 "내가 어느 쪽인지" 아는 데서 끝난다.

구분	누가	주로 만나는 에러
웹/앱 ChatGPT 사용자	브라우저·모바일 앱으로 대화	Something went wrong, network error, conversation not found, 모델 사용 한도
OpenAI API 개발자	코드로 `api.openai.com` 호출	HTTP 401, 429, 5xx

두 부류는 한도 체계도, 과금 구조도, 해결법도 다르다. 웹에서 한도에 걸렸다고 API도 막힌 게 아니고, 그 반대도 마찬가지다. 헷갈리면 엉뚱한 곳을 고치게 된다.

핵심 원칙: 에러는 "증상"이 아니라 "에러 본문의 type/code 필드"로 진단한다. 특히 429는 같은 코드 아래 완전히 다른 두 원인이 숨어 있다.

1. "Something went wrong" / network error / conversation not found

웹·앱에서 가장 흔한 세션·네트워크성 오류다. 실제로 뜨는 메시지는 대략 이렇다.

Something went wrong.
A network error occurred. Please check your connection and try again.
Error in conversation not found
We're experiencing exceptionally high demand.

원인

브라우저/앱과 OpenAI 서버 사이의 통신이 끊긴 경우다. 세부적으로는,

(a) OpenAI 서버 측 과부하·장애·점검 — "exceptionally high demand"가 대표적. 내 문제가 아니다.
(b) 불안정한 네트워크 — 공용 와이파이, 호텔·사내망 방화벽, 패킷 손실.
(c) 손상된 캐시·쿠키 또는 만료된 로그인 세션.
(d) 특정 대화 컨텍스트 로딩 실패·타임아웃 — 여기서 나오는 게 conversation not found다.

오해 정정: conversation not found는 계정 정지가 아니다. 단지 그 대화 세션을 서버가 못 불러온 로딩 실패다. (출처: godofprompt, GeeksforGeeks 정리) 당황해서 새 계정 만들 필요 없다.

단계별 해결

새로고침 (Ctrl+R / Cmd+R) 후 재시도 — 절반은 여기서 끝난다.
status.openai.com에서 OpenAI 측 장애·점검 여부 먼저 확인. 서버 문제면 기다리는 것 외에 방법이 없으니, 내 환경을 헤집기 전에 이걸 본다.
로그아웃 → 재로그인. 만료된 세션을 복구하고 대화 히스토리를 다시 로딩한다.
사이드바 New Chat으로 새 대화에서 동일 프롬프트 시도. 특정 대화만 손상된 경우(conversation not found)에 효과적이다.
다른 네트워크로 전환(모바일 핫스팟) 또는 시크릿 모드/다른 브라우저로 테스트해 네트워크가 원인인지 격리.
캐시·쿠키 삭제, VPN·광고차단 확장프로그램 일시 비활성화.

실무 팁: 2번(status 확인)을 1순위에 두는 사람과 아닌 사람의 디버깅 시간 차이가 크다. 내 환경을 5분간 만지작거리다 알고 보니 OpenAI 점검이었던 경험, 한 번씩 다 있다.

2. API 429 — 같은 코드, 두 개의 원인 (가장 중요)

개발자가 가장 많이, 가장 헷갈려하는 에러다. 메시지 예시는 이렇다.

Error code: 429 - Rate limit reached for requests
Too many requests
You exceeded your current quota, please check your plan and billing details
(error type: insufficient_quota)

원인 — 둘로 갈린다

같은 429라도 원인이 정반대다. 이 구분을 못 하면 처방이 통째로 틀린다.

원인	`type`/메시지	진짜 의미	해결 방향
Rate limit	`rate_limit` / "Rate limit reached"	분당 요청수(RPM)·토큰수(TPM) 한도 초과	재시도·호출 분산
크레딧 소진	`insufficient_quota` / "exceeded your current quota"	선불 크레딧 0 또는 무료 토큰 만료	결제·충전

Rate limit: usage tier별 RPM/TPM 한도 초과. 무료·저티어는 한도가 매우 낮아서(예: 분당 몇 회 수준) 짧은 시간 동시·반복 호출만 해도 걸린다.
insufficient_quota: 선불 크레딧이 바닥났거나 무료 체험 토큰이 만료된 경우. 2024년 2월 정책 변경 이후 API는 잔액이 양수여야 호출된다. 결제수단 미등록·크레딧 0일 때 흔하다.

credit card and online payment concept

단계별 해결

에러 본문의 type 필드부터 읽는다. insufficient_quota면 결제 문제, rate_limit이면 호출 빈도 문제. 여기서 갈라진다.
insufficient_quota라면: OpenAI 대시보드 → Billing에서 결제수단 등록 + 크레딧 충전. Usage/Limits에서 잔액·tier 확인. (재시도 로직 아무리 짜도 절대 안 풀린다.)
rate limit이라면: 지수 백오프(exponential backoff) + jitter 재시도를 구현하고, 응답의 Retry-After 헤더를 존중한다.
클라이언트 측 호출 빈도 제한(요청 큐·딜레이)으로 RPM/TPM 아래로 분산.
사용량이 지속 증가하면 usage tier 상향(누적 결제로 자동 승급)하거나 상위 플랜으로 한도 확대.

지수 백오프 재시도의 최소 골격은 이런 모양이다.

import time, random
from openai import OpenAI, RateLimitError

client = OpenAI()

def call_with_backoff(**kwargs):
    for attempt in range(5):
        try:
            return client.chat.completions.create(**kwargs)
        except RateLimitError as e:
            # insufficient_quota는 재시도해도 소용없으니 즉시 중단
            if "insufficient_quota" in str(e):
                raise
            wait = (2 ** attempt) + random.uniform(0, 1)  # 백오프 + jitter
            time.sleep(wait)
    raise RuntimeError("최대 재시도 초과")

주목할 부분은 insufficient_quota일 때 재시도를 즉시 포기하는 분기다. 이게 없으면 결제가 문제인데 5번 헛재시도하고 똑같이 죽는다.

서비스 관점 팁: 백엔드가 OpenAI를 호출하는 구조라면 분석 엔드포인트에 429 재시도 + 결과 캐싱을 넣고, 비용 폭주를 막기 위해 IP당 분당 호출 제한을 함께 둔다. 우리 프로젝트도 RATE_LIMIT_PER_MINUTE로 이 방어선을 유지한다. 비슷하게 Claude API의 과부하(529) 처리 패턴도 참고할 만하다 — /blog의 Claude 529 오버로드 핸들링 글 참고.

3. API 401 — Invalid / missing API key (인증 실패)

Error code: 401 - Incorrect API key provided
You didn't provide an API key.
Authentication error: invalid_api_key

원인

키가 잘못됐거나, 누락됐거나, 폐기(revoked)된 경우다. 의외로 키 자체보다 "키를 다루는 과정"에서 사고가 난다.

키 앞뒤에 공백·줄바꿈이 섞여 들어감 (복사할 때 자주).
따옴표까지 함께 복사됨 ("sk-...").
OPENAI_API_KEY 환경변수 미설정 또는 오타.
키 회전(rotation)으로 폐기된 옛 키를 그대로 사용.
잘못된 조직/프로젝트로 발급된 키 사용.

단계별 해결

키가 sk-로 시작하는지, 앞뒤에 공백·줄바꿈·따옴표가 섞이지 않았는지 확인.
OPENAI_API_KEY가 실제로 런타임에 로드됐는지 확인. .env 파일 값과 런타임 값이 일치하는지 본다.
OpenAI 대시보드 API keys에서 해당 키가 폐기되지 않았는지, 올바른 프로젝트/조직 소속인지 확인.
의심되면 새 키 발급 후 교체. 단, 보안 원칙상 키는 절대 커밋·로그에 남기지 말고 서버 환경변수만 갱신한다.
조직 헤더가 필요한 계정이면 OpenAI-Organization 헤더가 올바른지 확인.

런타임에서 키가 진짜 들어왔는지 확인하는 가장 빠른 방법.

# 키 전체를 출력하지 말고, 로드 여부와 형식만 확인 (보안)
python -c "import os; k=os.getenv('OPENAI_API_KEY'); \
print('loaded:', bool(k), '| starts sk-:', (k or '').startswith('sk-'), \
'| len:', len(k or ''))"

보안 주의: 디버깅한다고 키 전체를 print하거나 로그에 찍지 말 것. 위처럼 로드 여부·접두사·길이만 확인한다. 유출된 키는 곧 직접 과금 피해다.

security lock on keyboard data protection

4. ChatGPT Plus/Pro 모델 사용 한도 도달

웹/앱 유료 사용자가 만나는 메시지다.

You've reached your limit for [모델명].
You've hit the [GPT-5 Thinking] usage cap — try again after [reset time].

원인

ChatGPT Plus/Pro는 모델별로 동적 메시지 한도가 있다. 가벼운 Instant 계열은 보통 N시간당, reasoning(Thinking) 계열은 주(7일) 단위 rolling window로 제한된다. 한도를 넘기면 해당 모델이 모델 선택기에서 일시적으로 사라지고, 더 가벼운 모델로 자동 전환된다.

정직하게 짚을 점: 구체적인 한도 수치(예: "3시간당 N회", "주 N회")는 서드파티 정리 글 기준이며 OpenAI가 수시로 바꾼다. OpenAI 자신도 "동적이며 부하에 따라 달라진다"고 명시한다. 따라서 정확한 숫자는 추정·변동값으로 보고, OpenAI Help Center에서 그때그때 재확인하는 게 맞다. 인터넷에 떠도는 단정적 숫자는 광고성 과장이 섞여 있을 수 있다.

단계별 해결

모델 선택기에서 모델명에 마우스를 올려 리셋 시각 확인. rolling window라 "첫 메시지 기준 N시간/7일 후" 리셋되는 경우가 많다.
리셋 전까지는 자동 전환된 경량 모델로 작업 계속하거나 사용 가능한 다른 모델로 전환.
급하면 상위 플랜(Pro/Team) 업그레이드로 한도 확대 검토.
한도 절약: 단순 작업에 굳이 reasoning(Thinking) 모델을 쓰지 말고 Instant/경량 모델을 쓴다. 무거운 모델일수록 한도가 빨리 닳는다.
대량·반복 자동화가 목적이면 웹 ChatGPT 대신 API로 전환. 한도 체계와 과금이 분리돼 훨씬 통제하기 쉽다.

Do's / Don'ts — 한 장 요약

상황	Do (이렇게)	Don't (이러지 말 것)
웹에서 "Something went wrong"	status.openai.com 먼저 확인 후 새로고침·재로그인	곧장 계정·환경부터 의심하며 시간 낭비
429 발생	본문 `type` 읽고 원인부터 분기	무조건 백오프 재시도만 추가
insufficient_quota	Billing에서 크레딧 충전	재시도 횟수 늘리기 (절대 안 풀림)
401 인증 실패	공백·따옴표·환경변수 로드 확인	키 전체를 로그·콘솔에 출력
키 교체	서버 환경변수만 갱신	`.env`·키를 git에 커밋
모델 한도	리셋 시각 확인, 경량 모델로 계속	떠도는 한도 숫자를 확정 사실로 믿기
대량 자동화	API로 전환해 한도·비용 분리	웹 ChatGPT를 매크로로 도배

마무리 — 진단이 곧 해결이다

ChatGPT·GPT 에러는 종류는 많아 보여도 진단 분기점은 단순하다.

웹/앱이면 → 서버 상태(status) → 세션(재로그인) → 네트워크 순으로 격리한다. conversation not found는 정지가 아니라 로딩 실패다.
API면 → 에러 본문의 type/code를 먼저 읽는다. 429는 rate_limit(재시도·분산)인지 insufficient_quota(결제)인지가 전부고, 401은 키의 형식·로드·폐기 여부 세 가지만 보면 된다.
모델 한도는 동적이라 숫자에 집착하지 말고 리셋 시각만 확인, 무거운 작업만 무거운 모델에 맡긴다.

다음 행동으로는, API를 운영한다면 (1) 호출부에 insufficient_quota 즉시 중단 분기가 들어간 백오프 재시도, (2) 결과 캐싱, (3) IP/사용자 단위 레이트리밋 — 이 세 가지를 점검 리스트로 넣어두길 권한다. 비용과 안정성을 동시에 잡는 가장 가성비 좋은 방어선이다.

더 많은 AI 도구 문제 해결 글은 /blog, 실전 팁 모음은 /blog?type=tips에서 볼 수 있다.

참고 출처

OpenAI Status — 서버 장애·점검 실시간 확인
OpenAI Help Center — 모델별 한도·요금제 공식 안내(수시 변경)
OpenAI API 공식 문서 — Rate limit·에러 코드 레퍼런스

본문의 모델별 한도 수치는 2026년 6월 기준 서드파티 정리(godofprompt, GeeksforGeeks, customgpt.ai 등)와 OpenAI 커뮤니티 스레드를 참고했으며, OpenAI가 수시로 변경하므로 공식 페이지 교차 확인을 권한다.