코딩 전용 AI 모델은 왜 사라졌을까? — Codex부터 Codey까지, 빅3가 Coder 모델을 버린 이유

들어가는 말: "코딩 특화 모델이 코딩을 제일 잘할 것"이라는 직관

AI 모델 초기, 많은 개발자들은 당연하게 여겼던 가정이 하나 있습니다.

"범용 모델(General LLM)보다, 코드 데이터만 집중 학습시킨 '코딩 전용 모델(Coder LLM)'이 프로그래밍을 훨씬 더 잘할 것이다."

실제로 2021년~2023년 사이 AI 업계는 코딩 전용 모델 경쟁으로 뜨거웠습니다. GitHub Copilot의 최초 기반이었던 OpenAI의 Codex, Google의 PaLM 2 기반 Codey 패밀리(code-bison, code-gecko), Meta의 Code Llama 등이 잇달아 등장했습니다.

하지만 2026년 현재, 프론티어 AI 랩(OpenAI, Google, Anthropic)의 상용 라인업에서 'Coder'라는 별도 분할 모델은 완전히 자취를 감췄습니다.

오늘날 개발자들이 실무에서 가장 많이 쓰는 코딩 모델은 Claude Sonnet, GPT-4o / o1, Gemini Flash / Pro와 같은 **범용 기초 모델(General Foundation Model)**입니다. 왜 프론티어 빅3는 코딩 전용 모델을 버리고 범용 모델로 수렴했을까요?

1. 흔한 오해: "Claude Sonnet은 코딩 전용 라인업 아닌가요?"

많은 개발자들이 흔히 하는 오해 중 하나가 "Claude는 Opus(범용), Sonnet(코딩용), Haiku(경량)로 역할을 나누어 출시한 것 아니냐"는 생각입니다.

결론부터 말하면 전혀 아닙니다. Claude의 3단 분류는 코딩 여부로 나눈 것이 아니라 체급(지능 vs 지연시간/비용)에 따른 티어링입니다.

티어 (체급)	Anthropic (Claude)	Google (Gemini)	OpenAI
최상위 플래그십	Opus (Opus 3, 3.5, 5.5)	Pro (구 Ultra 흡수)	GPT-4o / GPT-5
주력 워크호스	Sonnet (Sonnet 3.5, 4.6, 5)	Flash / Pro (Gemini 2.5)	o1 / o3 / GPT-4o
초경량 / 저비용	Haiku (Haiku 3.5)	Flash-Lite (구 Nano)	mini (GPT-4o-mini)

Sonnet이 '코딩용 모델'처럼 인식된 이유는, 2024년 여름 출시된 Claude 3.5 Sonnet이 미들급 가격대임에도 불구하고 상위 플래그십인 Claude 3.0 Opus의 코딩 능력을 압도해버렸기 때문입니다. 즉, "미들급 가격에 코딩 가성비가 가장 뛰어나서 실무 코딩에 많이 쓰인 것"이지, 앤트로픽이 코딩 데이터만 학습시켜 파생한 모델이 아니었습니다.

2. 과거의 역사: 빅3가 겪었던 '코딩 전용 모델'의 퇴장사

실제로 구글과 OpenAI는 과거에 코딩 전용 분할 모델을 직접 만들고 서비스했던 역사가 있습니다.

[ 2021 ~ 2023년 : 전용 모델의 실험 ]
• OpenAI  : Codex (code-davinci-002, code-cushman-001) 출시
• Google  : Codey (code-bison, code-gecko, codechat-bison) 출시
• Meta    : Code Llama (7B / 13B / 34B / 70B) 출시

                     │
                     ▼ (한계 노출 및 범용 LLM의 급격한 성능 역전)
                     │

[ 2023년 ~ 2026년 : 전용 모델 폐지와 단일화 ]
• OpenAI  : 2023년 3월 Codex API 완전 셧다운 ➔ GPT-4 / o1 범용 흡수
• Google  : Gemini 출시와 함께 Codey 폐기 ➔ Gemini Pro / Flash 범용 흡수
• Anthropic : 단 한 번도 Coder 모델을 내지 않고 Opus/Sonnet/Haiku 체급 유지

1) OpenAI Codex의 공식 셧다운 (2023년 3월)

2021년 출시되어 GitHub Copilot 초기를 이끌었던 Codex(code-davinci-002)는 2023년 3월 전격적으로 API 서비스가 종료되었습니다.
OpenAI가 밝힌 종료 사유는 명확했습니다: **"범용 모델인 GPT-4가 코딩 전용 모델인 Codex보다 코드 문법뿐만 아니라 설계, 버그 추적, 논리 추론 전 영역에서 압도적으로 우수하다"**는 것이었습니다.

2) Google PaLM 2 Codey의 폐지 (2024년)

구글 역시 2023년 Google I/O에서 코드 생성용 code-bison과 초저지연 자동완성용 code-gecko를 발표했으나, Gemini 1.0 및 1.5가 등장하면서 Codey 브랜드를 완전히 폐기했습니다. 대신 코딩과 멀티모달 추론을 하나로 통합한 단일 Gemini 가중치로 전환했습니다.

3. 코딩 전용 모델이 도태된 4가지 공학적 이유

① "코딩은 언어의 부분집합이 아니라 종합 추론의 정점이다"

초기 연구자들은 프로그래밍 언어가 파이썬, 자바스크립트처럼 문법 규칙(BNF)이 엄격하므로, 코드 데이터셋만 학습시키면 적은 파라미터로도 완벽한 코더를 만들 수 있을 것이라 생각했습니다.

그러나 실제 소프트웨어 엔지니어링(SWE)은 문법을 맞추는 작업이 아닙니다.

기획서와 요구사항 문서의 모호한 비즈니스 로직 해석
다른 시스템 컴포넌트와의 상호작용 이해
에러 로그와 스택트레이스에서 원인을 역추적하는 연역적 추론

코딩 데이터만을 집중 파인튜닝(Fine-tuning)하면 가중치가 편향되어, 일반적인 문맥 이해나 복합 상식 추론 능력이 훼손되는 **파국적 망각(Catastrophic Forgetting)**이 발생했습니다. 문법은 맞지만 도메인 맥락을 모르는 코드를 짜게 된 것입니다. 반면 수천억 파라미터의 범용 기초 모델은 방대한 텍스트와 수학, 논리학을 통해 학습한 고차원 추론 능력을 코딩에 그대로 투사하며 전문 모델을 압도했습니다.

② 소프트웨어 개발은 '텍스트'가 아닌 '네이티브 멀티모달'이다

현대 개발 환경에서 개발자가 보는 것은 소스 코드 텍스트만이 아닙니다.

Figma 화면 시안 및 UI 캡처 이미지
클라우드 인프라 네트워크 토폴로지 및 DB ERD 다이어그램
성능 모니터링 대시보드의 실시간 그래프
PDF 형태의 복잡한 기술 사양서

만약 코딩 전용 모델을 텍스트 위주 가중치로 분리하면, 시각적 설계도를 보고 프론트엔드 컴포넌트를 만들거나 인프라 아키텍처 다이어그램을 코드로 옮기는 능력을 상실하게 됩니다. 딥마인드와 오픈AI는 코드와 이미지를 동일한 토큰 공간에서 처리하는 네이티브 멀티모달 단일 모델만이 실무 엔지니어링을 온전히 지원할 수 있다고 판단했습니다.

③ 100만~200만 토큰 롱컨텍스트와 RAG의 한계 극복

과거 4K~16K 수준의 좁은 컨텍스트 창 시절에는, 모델이 저장소 전체를 볼 수 없었기 때문에 작은 코딩 전용 모델로 RAG(검색 증강 생성)를 돌려 파일 조각(Chunk)을 던져주는 방식을 썼습니다.

하지만 현재는 100만(1M)에서 200만(2M) 토큰의 컨텍스트 윈도우가 기본 제공됩니다.

모노레포 전체 코드, 설정 파일, 의존성 라이브러리 인터페이스, 최근 커밋 히스토리 수백 개를 요약 없이 한 번에 주입합니다.
벡터 검색(RAG) 과정에서 누락되던 타입 정의나 클래스 간 참조 관계가 깨지지 않습니다.

전체 레포지토리를 조망할 수 있는 환경에서는, 코딩 조각에 특화된 소형 모델보다 거대한 컨텍스트를 소화하며 전역 구조를 파악하는 범용 모델의 정확도가 압도적입니다.

④ '비싼 단일 코더'보다 '저렴한 모델의 에이전틱 루프'가 우월하다

패러다임이 '단발성 완성(Completion)'에서 **'에이전틱 자율 수정(Agentic Self-Correction)'**으로 바뀌었습니다.

[ 기존 단발성 추론 ]
질문 ➔ [ 비싼 전용 코딩 모델 (Zero-shot) ] ➔ 오답 시 실패

[ 현대 에이전틱 루프 (Antigravity / Claude Code) ]
질문 ➔ [ 저렴하고 빠른 범용 모델 (Flash / Sonnet) ]
              │
              ├── 린터 및 컴파일러 실행
              ├── 단위 테스트(Unit Test) 구동
              ├── 터미널 에러 확인 후 스스로 코드 수정
              │
              └── 테스트 통과 시 최종 완료

복잡한 실무 버그를 잡을 때, 70B 규모의 전용 코딩 모델이 한 번에 완벽한 답을 맞힐 확률보다, Claude Sonnet이나 Gemini Flash 같은 저렴한 고속 범용 모델이 터미널 도구를 들고 3~5회 테스트를 돌려가며 스스로 고치는 확률이 압도적으로 높습니다.

토큰 단가가 극도로 저렴해진 범용 모델(100만 토큰당 $0.075~$3.00)을 린터와 터미널에 연결해 루프를 돌리는 방식이 확립되면서, 굳이 별도의 코딩 모델 가중치를 관리할 공학적 실익이 완전히 사라졌습니다.

4. 그렇다면 오픈소스 진영은 왜 여전히 Coder 모델을 낼까?

여기서 한 가지 의문이 남습니다.
“그렇다면 Meta의 Code Llama, Mistral의 Codestral, DeepSeek-Coder, Qwen-Coder 같은 모델들은 왜 여전히 나올까?”

답은 배포 환경과 VRAM의 현실적 제약 때문입니다.

구분	프론티어 빅3 (OpenAI, Google, Anthropic)	오픈소스 / 2선 벤더 (DeepSeek, Mistral 등)
운영 방식	자체 클라우드 API 서비스 중심	온프레미스 / 로컬 PC / 오픈 가중치 배포
하드웨어 제약	수만 대 TPU/GPU 클러스터 활용 가능	개발자 로컬 RTX 4090 (24GB VRAM) 등에 적합해야 함
롱컨텍스트	1M ~ 2M 토큰 원샷 제공	32K ~ 128K 수준 (메모리 제약)
모델 전략	단일 거대 범용 모델 (체급별 티어링)	특정 도메인(코딩) 데이터를 압축한 소형 특화 모델

로컬 GPU나 소규모 사내 서버에서 7B, 14B, 32B 크기의 모델을 띄워야 하는 환경에서는, 범용 상식 능력을 일부 포기하더라도 코딩 토큰만 집중 압축한 '특화 모델'이 여전히 실용적인 가치를 가집니다. 즉, 오픈소스의 Coder 모델은 아키텍처적 우월함 때문이 아니라 제한된 로컬 자원에 맞추기 위한 압축 타협안입니다.

결론: 코딩은 분리된 영역이 아니라 지능의 본체였다

과거 AI 업계는 '코딩', '수학', '일상 대화'가 서로 다른 전문 모델로 분화될 것이라 예측했습니다.

하지만 지난 3년간의 공학적 결과는 정반대였습니다. 코딩은 언어 모델에서 따로 떼어낼 수 있는 부가 기능이 아니라, 거대 언어 모델이 세상을 논리적으로 추론하고 문제를 분해하는 핵심 사고 메커니즘 그 자체였습니다.

프론티어 AI 랩들이 'Coder' 라인업을 접은 것은 코딩을 포기해서가 아닙니다. 반대로 모든 주력 모델의 뼈대 자체를 코딩과 멀티모달 추론이 가능한 시스템으로 만들었기 때문에, 더 이상 '코딩 전용'이라는 수식어가 필요 없어진 것입니다.