목차
- 복귀 보도, 알려진 것과 모르는 것
- OpenAI 엑소더스 타임라인 — 개발자 시점
- 첫 시도 — 모델명만 바꾸면 된다고 믿던 시기
- 추상화 레이어로 도망친 결과
- Murati 복귀가 보내는 신호 셋
- 지금 당장 점검할 것
openai.BadRequestError: Error code: 400 - {
"error": {
"message": "The model `gpt-4-32k` has been deprecated. Please use one of the latest models...",
"type": "invalid_request_error",
"code": "model_not_found"
}
}
또한, 이 메시지를 처음 본 건 운영 서버에 배포한 직후였다. 사내 RAG 백엔드 한 줄이 모델명 하나로 멈추던 시점에, OpenAI 인사 뉴스가 또 떴다는 슬랙 알림이 같이 울렸다. 코드와 뉴스가 같은 시간에 도착하던 시기는 그렇게 한참 이어졌다.
2024년 9월 Mira Murati가 OpenAI CTO 자리에서 내려온 뒤로 줄줄이 이어진 핵심 인사 이탈을 업계는 ‘OpenAI 엑소더스’라고 부른다. 그리고 2026년 봄, Murati가 OpenAI로 다시 들어간다는 보도가 나왔다(공식 발표는 매체별로 표현이 다르다). 엑소더스 이후 첫 번째 귀환이라는 점에서 신호가 작지 않다.
복귀 보도, 알려진 것과 모르는 것
먼저 사실 관계부터 좁혀두는 게 좋다. 2026년 6월 기준 공개된 정보는 한정적이다.
- 확인된 사실: Murati는 2024년 9월 OpenAI를 떠났고, 2025년 초 Thinking Machines Lab을 세웠다(공식 페이지 — Thinking Machines Lab, 2025-02).
- 매체별로 다른 부분: 이번 복귀가 자문(advisor) 형태인지, 임원 복귀인지는 보도마다 다르게 전해진다.
- 미확인: 본인 명의의 공식 입장은 본 글 작성 시점까지 1차 출처로 확인되지 않았다.
따라서 이 글은 ‘복귀’를 단정하기보다, 보도가 사실이라면 시장에 어떤 신호를 보내는지 정리하는 쪽에 무게를 둔다. 출처가 불완전한 상태에서 단정하면 결국 우리 코드에 영향을 주는 판단까지 흐릿해진다. 인사 뉴스 한 줄이 운영 의사결정에 들어오는 통로는 생각보다 짧다.
한편, (개인적으로는 1차 출처가 확인될 때까지 운영 환경 결정을 미루는 게 합리적이라고 본다)
OpenAI 엑소더스 타임라인 — 개발자 시점
업계 뉴스는 결재 라인이 바뀌었다는 식으로 쓰지만, 운영하는 입장에서 엑소더스는 매우 구체적인 형태로 도착했다. 분기마다 도착한 변경 안내가 그것이다. 굵직한 인사 사건과 우리 쪽 변경 작업의 시간차를 표로 정리하면 이렇다.
| 시점 | 업계에서 본 인사 사건 | 우리에게 도착한 변경 | 영향 |
|---|---|---|---|
| 2024 Q3 | Sutskever, Leike, Schulman 이탈 | Assistants API → Responses API 마이그레이션 안내 | 서버 코드 12군데 수정 |
| 2024 Q4 | Murati 사임, 일부 리더 동반 퇴사 | 구형 모델 deprecation 예고, 토큰 가격 조정 | 토큰 카운팅 로직 재작성 |
| 2025 Q2 | Thinking Machines Lab 등 신생 조직 정착 | 사용량 기반 청구 옵션 변경 | 월 단위 비용 재추정 |
| 2025 Q4 | Anthropic·xAI로 추가 이탈 보도 | 응답 포맷 옵션 기본값 일부 변경 | 파서 회귀 테스트 추가 |
| 2026 Q1 | (보도) Murati 복귀 가능성 | 신모델 프리뷰 액세스 정책 조정 | 액세스 재신청 |
반면, 뉴스 한 줄과 PR 한 줄의 거리는 가깝다. CTO가 바뀌면 6주 뒤 우리 코드가 바뀐다. 농담이 아니라 실제 분기 평균이 그 정도였다. 분기마다 운영자가 마주하는 변경의 종류는 달라도, 핵심 인사 변동 → 제품 로드맵 조정 → API 변경 공지의 흐름은 비교적 일정했다.
프론트엔드에서 옮겨온 시각
프론트 2년 하다 백엔드로 옮긴 지 2년쯤 됐다. React 18 → 19 메이저 업데이트를 따라가던 피로감과 OpenAI API 변경을 따라가는 피로감은 결이 다르다. 프론트는 빌드 타임에 깨지고, LLM API는 런타임에서 트래픽을 받으며 깨진다. 후자가 훨씬 무서운 건 결국 ‘비용’과 ‘사용자 응답’에 직결되기 때문이다.
물론, 프론트 쪽 메이저 업데이트는 보통 마이그레이션 가이드가 한 달 이상 먼저 나온다. LLM API 쪽은 deprecation 페이지 갱신과 이메일 한 통으로 시작해, 60~90일 안에 운영 모델을 옮겨야 하는 경우가 잦았다. 같은 ‘메이저 업데이트’라는 단어지만 운영 호흡이 다르다.
첫 시도 — 모델명만 바꾸면 된다고 믿던 시기
그래서, 엑소더스 첫 분기에는 단순했다. 알림 메일이 오면 모델명만 치환하면 끝이라고 믿었다. 그래서 모델명을 문자열 상수로 관리하던 코드를 그대로 두고 핫픽스로 밀어버렸다.
# 처음에 짠 코드 — 모델명을 그대로 박아뒀다
def summarize(text: str) -> str:
response = client.chat.completions.create(
model="gpt-4-32k", # 여기만 바꾸면 된다고 믿었다
messages=[{"role": "user", "content": text}],
max_tokens=1024,
)
return response.choices[0].message.content
그래서, 결과는 운영에서 토큰 카운팅이 깨지는 형태로 돌아왔다. 모델이 바뀌면 컨텍스트 윈도우가 바뀌고, 토크나이저가 바뀌고, 청구 단가가 바뀐다. 모델명만 치환한 PR은 이 셋을 전부 놓쳤다. 그 주에 토큰 초과 에러가 한꺼번에 터지면서 알람이 한밤중까지 울렸다.
무엇을 놓쳤는지
게다가, 핫픽스가 빠뜨린 건 단순한 사실 하나였다. 모델 메타데이터를 코드 안에서 따로 관리하지 않았다는 것. 토큰 윈도우, 가격, 토크나이저, 기능 지원(예: function calling, JSON mode) 같은 것들이 모델마다 다르다는 걸 그제서야 정리하게 됐다.
이처럼, 해당 이슈가 운영에서 표면화된 패턴은 셋이었다. 첫째, 컨텍스트 윈도우가 줄어든 신모델로 옮기면서 RAG 청크 길이를 그대로 사용해 토큰 초과가 났다. 둘째, 응답 토큰 가격이 미세하게 올라 월 청구가 12% 늘었는데 사내 비용 알람이 잡지 못했다. 셋째, JSON mode 기본값이 바뀌면서 파서가 회귀로 깨졌다. 세 사건 다 모델명 치환 한 줄에서 시작한 일이었다.
추상화 레이어로 도망친 결과
그래서 만든 게 모델 메타데이터 테이블이다. 코드보다는 데이터에 가깝다. 운영하는 사람이 손볼 곳을 한 군데로 모으는 게 목적이다.
# llm_registry.py
from dataclasses import dataclass
@dataclass(frozen=True)
class ModelSpec:
provider: str # openai, anthropic, google
name: str # 외부 식별자
context_window: int # 토큰
input_price_per_1k: float
output_price_per_1k: float
supports_json_mode: bool
fallback: str | None # 같은 등급의 백업 모델 이름
REGISTRY: dict[str, ModelSpec] = {
# 등급은 우리가 정의한다. 매핑된 외부 모델은 갱신 대상
"premium": ModelSpec("openai", "gpt-4.1", 200_000, 0.005, 0.015, True, "claude-sonnet"),
"standard": ModelSpec("openai", "gpt-4o-mini", 128_000, 0.00015, 0.0006, True, "gemini-flash"),
# 가격/식별자는 2026-06 시점 기준 — 분기별로 갱신 필요
}
특히, 위 코드는 단순해 보여도 ‘운영 규약’에 가까운 역할을 한다. 모델별 등급(premium/standard)을 우리가 정의하고, 프로바이더는 그 등급을 만족시키는 외부 모델로 매핑한다. deprecation 알림이 와도 등급 정의는 그대로 두고 매핑만 바꾸면 된다. 호출하는 쪽 코드는 summarize(text, tier="standard") 같은 형태로 등급만 알면 된다.
같이 도입한 게 백업 프로바이더다. OpenAI 응답이 5xx를 반환하거나 레이트 리밋이 걸리면 같은 등급의 다른 프로바이더로 떨어뜨린다. Anthropic의 Claude Sonnet 계열, Google의 Gemini Flash 계열을 등급별로 매칭해두었다(Anthropic Models 문서, 2026-05 갱신).
측정 가능한 변화
추상화 이후 6개월 운영하면서 체감한 차이는 두 가지다.
- deprecation 대응에 드는 PR 수가 12개 → 1개로 줄었다. 등급 매핑 수정 한 줄이면 끝난다.
- 백업 프로바이더 자동 폴백 비율은 전체 호출의 0.7~1.2% 사이로 측정된다. 큰 숫자는 아니지만, 백업이 없을 때 그 1%는 5xx로 돌아갔던 트래픽이다.
알람 빈도는 절반 이하로 떨어졌다. 정확한 수치는 트래픽 패턴마다 다를 거다. 운영 채널의 LLM 관련 알람 수를 주 단위로 집계해보면 추상화 도입 직전 4주 평균 대비 도입 후 12주 평균이 47% 수준이었다.
무엇을 안 했는지
추상화 레이어를 만들면서 의도적으로 미룬 작업이 둘 있다. 하나는 프롬프트 자체의 모델별 튜닝이다. 같은 프롬프트가 OpenAI와 Anthropic에서 다른 결과를 내는 건 사실이지만, 등급별로 ‘최저 품질선’만 맞추면 운영상 큰 문제가 없다고 봤다. 다른 하나는 자동 비용 라우팅이다. 비용이 더 싼 프로바이더로 자동으로 옮기는 로직은 사고 위험이 더 커서 일부러 사람이 결정하게 두었다. 이건 시간을 두고 다시 본다.
Murati 복귀가 보내는 신호 셋
또한, 여기서 본 글의 본론으로 돌아간다. 보도가 사실이라는 전제 아래, 이번 복귀가 시장에 보내는 신호는 셋으로 정리된다.
1. 안정성 서사로의 전환
결국, 엑소더스 시기에 OpenAI의 메시지는 ‘속도’에 집중되어 있었다. 신모델 발표 주기, 신기능 추가 속도가 헤드라인이었다. 핵심 인사 한 명의 복귀는 그 자체로 ‘안정성’ 서사로 무게중심이 옮겨갈 수 있다는 신호다. 시장이 그렇게 해석할지는 다른 문제지만, 적어도 내부 정리가 어느 정도 진행됐다는 뜻으로 읽힌다. 운영자 입장에서 안정성 서사가 강해지면 단기적으로는 deprecation 주기가 길어지는 효과가 따라온다고 보인다. 분기 한 번씩 도착하던 변경 안내가 두 분기에 한 번으로 늘어지면 운영 비용 자체가 줄어든다.
2. 인재 시장의 미세한 재정렬
엑소더스 이후 OpenAI에서 나간 사람들은 Anthropic, Thinking Machines Lab, xAI, 그리고 신생 스타트업으로 흩어졌다. 한 명이라도 돌아간다는 건 다른 방향으로의 이동이 잠시 멈출 수 있다는 뜻이다. 인재 시장에서 미세한 재정렬이 일어날 가능성이 있고, 이는 6~12개월 시차로 모델 로드맵에 반영될 수 있다. 다만 Thinking Machines Lab이 어떤 형태로 영향을 받는지는 본 글 작성 시점에 단정하기 어렵다.
3. 다중 프로바이더 전략의 효용은 유지된다
그래서, 복귀가 곧 OpenAI의 안정으로 직결된다고 보지는 않는다. 한 사람이 돌아왔다고 운영의 불확실성이 사라지지 않는다는 게 더 정확하다. 그래서 위에서 적은 추상화 레이어 결정을 되돌릴 이유는 보이지 않는다. 오히려 이런 시점에 단일 프로바이더로 다시 묶으면 다음 인사 사건이 도착했을 때 회피 옵션이 줄어든다. 다중 프로바이더 전략은 인사 뉴스의 진폭과 독립적으로 작동해야 의미가 있다.
지금 당장 점검할 것
반면, 분석으로 끝내면 글이 가벼워진다. 운영하는 입장에서 이번 주 안에 점검하면 좋을 것을 셋만 적는다.
- 모델 식별자가 코드 안에 박혀 있는지 검색해보자.
grep -r "gpt-4" src/같은 명령으로 빠르게 잡힌다. 박혀 있다면 메타데이터로 분리하는 게 우선이다. - deprecation 메일을 어디로 받는지 확인해보자. 개인 계정으로만 가고 있다면 운영 채널로 라우팅을 추가하자. 6주 시차의 첫 단추는 이쪽이다(OpenAI Deprecations, 2026-06 기준 분기 갱신).
- 같은 등급의 백업 프로바이더를 한 곳만이라도 정해두자. 코드까지 안 짜도 좋다. 운영 문서에 ‘standard 등급 백업은 Gemini Flash’ 정도만 적어두어도 장애 시 의사 결정이 빨라진다.
세 가지 모두 작은 작업이다. 어느 것 하나라도 이번 주에 끝나면 다음 분기 인사 뉴스가 코드에 도착하기 전에 한 박자 먼저 움직일 수 있다.
개인적으로는 Murati 복귀 보도가 사실로 확인되더라도 운영자의 결정은 바뀌지 않는 게 더 나은 것 같다. 추상화 레이어와 백업 프로바이더는 인사 뉴스와 무관하게 유지하는 쪽이 결국 코드와 청구서 양쪽에 이득이다.
관련 글
- 중국 AI 인재 자국 잔류, 실리콘밸리 인재 전쟁 끝나나 – 통계 출력 한 줄 보고 머리가 멈췄다. ‘중국 출신 AI 인재의 미국 잔류율 56% → 38%’를 한 줄로 정리하려다 실패한 기록이다.
- Ferrari + IBM이 AI로 F1 슈퍼팬 만드는 법 — 개인화 프로젝트 회고 – Ferrari + IBM이 노린 슈퍼팬 전략의 구조와, 비슷한 개인화 시스템을 3개월 운영하며 부딪힌 현실을 시간순으로 비교한다.
- Cerebras IPO 108% 급등, AI 칩 투자 거품을 판단하는 5가지 기준 – Cerebras가 IPO 첫날 108% 급등하면서 NVIDIA 독점 구도에 균열이 보이기 시작했다. WSE-3가 H100을 대체할 수 있는…