Codex는 빅게임에 강한 걸까 — 한 Threads 글을 읽고 느낀 것
Codex는 빅게임에 강한걸까?
작년 말, 나는 codex를 써봤다. 사실 이틀정도 써보고 던졌다. 별로라서
하지만 이번엔 마음에 들었다. 왜 이런 차이가 발생했을까?
많은 사람들이 codex는 리뷰를 잘해준다고 했다.
그런데 내가 봤을 때에는 리뷰를 잘해주는 것 뿐 아니라 코드생성 품질또한 좋다. 어제 그제 이틀동안 코드 리팩토링을 진행했는데 결과물 테스트에서 오류가 없었다. 중간중간 직접 확인한 것도 아니고 그냥 따로 프로젝트를 복사하고, 망쳐도 된다는 생각으로 그냥 Codex가 하겠다는 대로 쭉쭉 진행한 거였는데 깔끔하게 성공했다. opus에게 리팩토링 많이 시켜봤지만 이정도 수준은 없었기에 좀 충격을 받았다.
그럼 이 차이가 어디에서 나왔을까? 최근 pro버전을 구매한 일부 분들이 opus 땡긴다고들 하던데 그분들과 작년의 나는 왜 codex가 별로라고 느꼈을까?
(결과 알려주는거 아니고 내가 너무 궁금함 ㅋㅋㅋㅋㅋ)
이건 그냥 내 뇌피셜인데,
순수 코딩능력 자체는 Opus가 우월하지만 Codex xhigh가 단서를 찾아내고 정보를 정리, 수집하는 능력이 우월한 것 같음.
그래서 일정수준 이하 사이즈의 프로젝트에서는 길을 헤맬일이 없으니 Opus가 우월하고, 기존 프로젝트의 뎁스가 깊어질수록 길찾기가 어려워지니 문제 해결의 단서를 찾아내고 정보 수집능력이 뛰어난 Codex xhigh가 정보의 근거를 많이 찾을 수 있어서 우월해지는게 아닐지?
https://www.threads.com/@hankyeol_90/post/DU4Nv7Rk1-o
5.2에서 5.3으로, “버전이 달라서”만으로는 설명이 안 되는 것
이 글을 읽으면서 가장 먼저 공감한 부분은 “작년 말 이틀 써보고 던졌다”는 경험이다. 실제로 GPT-5.2-Codex에 대한 불만은 글쓴이만의 것이 아니었다. OpenAI의 GitHub Discussion에서도 “5.2 Codex는 lazy하고 우유부단하다”, “복잡한 리팩토링에서 중간에 멈추거나 테스트 실행을 건너뛴다”는 보고가 반복적으로 올라왔고, 한 사용자는 동일한 프롬프트로 GPT-5.2 범용 모델과 GPT-5.2-Codex를 비교했을 때 범용 모델이 일관되게 더 높은 품질의 코드를 생성했다고 Issue를 올리기도 했다. 즉 “작년에 별로였다”는 감각은 상당히 보편적인 것이었고, 5.2-Codex는 에이전틱 코딩 모델이라는 타이틀에 비해 실제 자율 작업 능력이 기대에 미치지 못했던 것이 사실이다.
그래서 댓글에서 “신버전이 나왔기 때문 아닐까요?”라는 답변은 틀린 말은 아니지만, 절반만 맞다. GPT-5.3-Codex는 단순히 “5.2의 개선판”이 아니라 아키텍처적으로 다른 접근을 취한 모델이다. DataCamp의 분석에 따르면, 5.2 세대에서는 범용 GPT-5.2와 코딩 특화 GPT-5.2-Codex가 별도로 존재했지만 5.3-Codex는 이 둘을 통합했다. 범용 모델의 추론 능력과 코딩 모델의 에이전틱 실행력을 하나로 합친 것이다. Terminal-Bench 2.0에서 64%였던 5.2-Codex의 점수가 75.1%로 뛴 것도 이 통합의 결과이고, 동시에 GDPval에서 범용 5.2와 동일한 70.9%를 기록한 것도 추론 능력이 코딩 모델에 온전히 이식되었다는 뜻이다.
“리뷰만 잘한다”는 평판과 실제 사이의 간극
글쓴이가 흥미로운 지적을 한다. 많은 사람들이 Codex는 리뷰를 잘해준다고 했는데, 실제로 써보니 코드 생성 품질 자체가 좋았다는 것이다. 이틀간 리팩토링을 맡겼는데 별도 프로젝트를 복사해서 “망쳐도 된다”는 마음으로 Codex가 하겠다는 대로 밀었더니 테스트 오류 없이 깔끔하게 성공했다고 한다. Opus에게 리팩토링을 많이 시켜봤지만 이 정도는 없었다는 평가까지 덧붙인다.
이 경험은 현재 여러 리뷰어들의 관찰과도 일치한다. Lenny’s Newsletter에서 44개의 PR, 98개의 커밋, 1,088개의 파일을 5일 만에 처리하며 두 모델을 비교한 엔지니어는 Codex가 코드 리뷰에서 탁월하면서도 리팩토링 같은 구조적 작업에서 안정적인 결과를 낸다고 보고했다. Every의 Vibe Check 리뷰에서도 Codex 5.3에 대해 “빌드 에러 제로로 상당한 규모의 iOS UI 리디자인을 완료했다”는 평가가 나왔다. 즉 Codex의 강점이 “리뷰”에만 있다는 인식은 5.2 시절의 잔상일 가능성이 높고, 5.3에서는 코드 생성과 리팩토링 모두에서 실질적인 도약이 있었던 것으로 보인다.
다만 이것이 모든 상황에서 Opus보다 우월하다는 뜻은 아니다. Medium에서 48시간 동안 18개의 애플리케이션을 빌드하며 비교한 한 개발자는, 원샷 코딩 테스트에서 Opus 4.6가 220점 만점 중 220점이라는 완벽한 점수를 기록한 반면 Codex는 인증이나 파일 핸들링 같은 기본적인 부분에서 문제를 보였다고 보고했다. 이 엇갈리는 결과들이 의미하는 바가 있다. 그리고 그것이 바로 글쓴이의 “뇌피셜”이 건드리는 지점이다.
“단서를 찾아내는 능력”이라는 가설의 설득력
글쓴이의 핵심 가설은 이렇다. 순수 코딩 능력 자체는 Opus가 우월하지만, Codex xhigh는 단서를 찾아내고 정보를 정리·수집하는 능력이 우월하다. 그래서 프로젝트의 깊이가 깊어질수록 Codex가 유리해진다는 것이다.
이 가설은 상당히 설득력이 있다고 생각한다. 그 근거를 몇 가지 측면에서 살펴볼 수 있다.
첫째, 벤치마크 구조가 이를 뒷받침한다. Codex 5.3이 가장 큰 격차를 보인 벤치마크는 Terminal-Bench 2.0인데, 이것은 파일 편집, git 작업, 빌드 시스템 등 터미널 환경에서의 자율적 코딩을 측정한다. 77.3% 대 Opus 4.6의 약 65.4%라는 격차는, 코드를 “잘 쓰는” 능력이 아니라 코드베이스를 “잘 돌아다니며 필요한 것을 찾아내는” 능력의 차이를 반영한다. Adaline Labs의 분석이 이를 명확히 표현했다. Codex는 “플래너보다 오퍼레이터에 가깝다. 구체적인 작업을 주면 시도하고, 명령을 실행하고, 에러를 읽고, 다시 시도한다.” 이 반복 루프를 빠르고 정확하게 돌리는 능력이 곧 “단서를 찾아내는 능력”의 기술적 실체다.
둘째, OpenAI 자체의 하네스 엔지니어링 사례가 이를 확인해준다. OpenAI가 공개한 에이전트 퍼스트 개발 방법론에 따르면, Codex 에이전트의 관점에서는 “컨텍스트 내에서 접근할 수 없는 것은 존재하지 않는 것과 같다”는 전제 위에서 작동한다. 이 전제 위에서 레포지토리 안의 코드, 마크다운, 스키마, 실행 가능한 계획서 등 버전 관리되는 아티팩트를 탐색하고 수집하는 능력이 핵심이 된다. Codex가 작업 루프 중에 필요에 따라 파일을 읽고, 도구 출력을 수집하고, 자신의 행동 기록을 참조하는 방식은, 글쓴이가 말한 “정보 수집 능력”과 정확히 대응한다.
셋째, 프로젝트 규모와 성능의 관계에 대한 커뮤니티 관찰이 이 가설과 일치한다. Every의 비교 리뷰에서 Opus 4.6는 “어려운 오픈엔디드 작업에서 더 높은 천장”을 가지지만 “성공을 보고했는데 실제로는 실패한 경우가 있고, 요청하지 않은 변경을 하기도 한다”는 변동성이 지적되었다. 반면 Codex는 “안정적이고 신뢰할 수 있는 자율 실행”에서 강점을 보였다. 150K 노드 규모의 React 레포지토리를 대상으로 한 벤치마크에서도, Opus 4.6가 94%의 크로스 컴포넌트 상태 버그 식별률을 보인 반면, Codex는 빠른 보일러플레이트 생성과 실시간 API 통합에서 우위를 점했다. 규모가 커질수록 중요해지는 것은 한 번의 천재적 통찰이 아니라, 수많은 파일과 의존성 사이에서 올바른 단서를 찾아내고 일관되게 작업을 수행하는 능력이라는 점에서 글쓴이의 직관과 맞닿아 있다.
그렇다면 “빅게임”이란 무엇인가
글쓴이의 가설을 한 발 더 밀고 나가면, 결국 “빅게임에 강하다”는 것의 의미가 좀 더 선명해진다. 여기서 빅게임이란 단순히 코드 라인 수가 많은 프로젝트가 아니라, 의존성이 복잡하게 얽혀 있고, 변경의 영향 범위를 추적하기 어렵고, 문서화되지 않은 맥락이 코드 사이사이에 묻혀 있는 현실의 프로덕션 코드베이스를 뜻한다.
이런 환경에서 필요한 능력은 두 가지다. 하나는 올바른 단서를 빠르게 찾아내는 탐색 능력이고, 다른 하나는 찾아낸 단서를 바탕으로 일관되게 작업을 수행하는 실행 능력이다. 글쓴이의 경험이 시사하는 바는, Codex 5.3 xhigh가 이 두 가지를 동시에 갖추고 있다는 것이다. Opus가 “시니어 아키텍트”라면 Codex는 “하이퍼프로덕티브한 리드 개발자”라는 비유가 여러 리뷰에서 반복되는 것도 같은 맥락이다.
다만 글쓴이가 스스로 “뇌피셜”이라며 겸손하게 물러선 지점에서 한 가지 보완할 것이 있다면, 이 차이는 모델의 고유한 역량 차이이기도 하지만 동시에 에이전틱 하네스의 차이이기도 하다는 점이다. Codex는 앱, CLI, IDE 확장을 통해 격리된 샌드박스 환경에서 작동하며, 각 에이전트가 코드의 격리된 사본 위에서 작업한다. 이 인프라 자체가 “망쳐도 된다는 마음으로 쭉쭉 진행”할 수 있게 해주는 구조적 안전장치다. 반면 Claude Code의 강점은 Agent Teams를 통한 병렬 작업과 100만 토큰 컨텍스트 윈도우에서의 깊은 추론에 있다. 즉 “어느 모델이 더 낫냐”보다는 “어떤 구조에서 어떤 작업을 시킬 때 더 낫냐”가 더 정확한 질문이고, 글쓴이의 리팩토링 경험은 Codex의 구조가 빛나는 전형적인 케이스였다고 볼 수 있다.
결국 모델은 선택하는 게 아니라 조합하는 것
이 글과 댓글들을 읽으면서 드는 생각은, 2026년 2월 현재 AI 코딩 도구의 선택지가 “하나를 고르는” 문제에서 “조합을 설계하는” 문제로 넘어갔다는 것이다. Adaline Labs의 표현이 가장 적확했다. “한 모델 전략은 2026년에 팀이 일하는 방식이 아니다. 이기는 셋업은 위험, 범위, 반복 비용에 따라 작업을 적절한 모델에 배정하는 라우터다. 꾸준히 배포하는 엔지니어는 편을 고르지 않는다. 로스터를 고른다.”
글쓴이의 경험, 즉 이틀간의 리팩토링에서 Codex가 Opus보다 나은 결과를 냈다는 것은, Codex가 절대적으로 우월하다는 증거가 아니라 특정 작업 유형에서 Codex의 강점이 빛났다는 증거다. 그리고 그 “특정 작업 유형”이 바로 빅게임, 즉 깊이 있는 기존 프로젝트에서의 리팩토링이라는 점에서, 글쓴이의 가설은 뇌피셜이라고 겸손하게 말하기엔 꽤 잘 조준된 통찰이다.
작성일: 2026-02-18