Codex를 모델, 하니스, 제품 표면으로 나누어 이해하는 개인적인 프레임워크와, 각각이 소프트웨어 엔지니어링 에이전트에서 어떤 역할을 하는지 설명합니다.
사람들이 “Codex”라고 말할 때, 항상 같은 것을 뜻하는 것은 아닙니다. 때로는 모델을 뜻하고, 때로는 앱을 뜻하며, 때로는 에이전트를 뜻합니다.
이해할 만하게도, 이는 혼란스러울 수 있습니다.
간단히 말하면, Codex는 여러 인터페이스를 통해 사용할 수 있는 OpenAI의 소프트웨어 엔지니어링 에이전트이며, 에이전트는 모델에 지침과 도구를 더하고 사용자를 대신해 작업을 실행할 수 있는 런타임으로 감싼 것입니다.
대부분의 개발자는 내부 구조를 생각할 필요가 없습니다. 자신의 워크플로에 맞는 표면을 고르고 바로 만들기 시작하면 됩니다. 대개
을 통해 그렇게 합니다. 에이전트형 코딩이 처음이라면, 독립형 Codex 앱이 가장 간단한 진입점입니다.
에이전트형 코딩이나 Codex가 처음이라면, Codex App이 시작하기에 권장되는 방법입니다! 이는 Codex 스레드를 병렬로 작업하기 위한 집중형 데스크톱 경험으로, 내장된 worktree 지원, 자동화, Git 기능을 제공합니다.
출처:
하지만 팀 차원에서 Codex를 평가하고 있거나, 온라인 토론과 문서, 잦은 릴리스를 이해하려고 한다면 이러한 구분은 중요합니다. “Codex”는 시스템의 서로 다른 계층을 가리킬 수 있습니다.
이 글은 개발자를 위한 것이며, 무언가 새로운 것이 출시될 때 실제로 무엇이 바뀌는지 이해하기 위해 제가 사용하는 개인적이고 매우 비공식적인 사고 모델을 제시합니다.
높은 수준에서 저는 Codex를 함께 작동하는 세 부분으로 봅니다.
Codex = Model + Harness + Surfaces
where
모델은 지능을 제공합니다.
하니스는(즉, 지침과 도구의 모음입니다) 그 지능을 실제 개발 환경에서 안전하게 작동할 수 있는 것으로 바꿉니다.
표면은 그 에이전트를 실제로 일하게 만드는 런타임과 인터페이스입니다.
그리고 더 구체적으로 말하면:
Model + Harness = Agent
Surfaces = 에이전트와 상호작용하는 방식
이 계층들을 분리해 놓고 나면, 나머지는 훨씬 이해하기 쉬워집니다.
Codex의 핵심에는 소프트웨어 엔지니어링에 특화되도록 최적화된 대규모 언어 모델(LLM)이 있습니다.
기본적인 수준에서 LLM은 다음 토큰을 예측하고, 코드는 텍스트입니다. 하지만
은 자동완성을 넘어섭니다. 답을 생성하기 전에 모델은 구조화된 내부 추론을 수행할 수 있습니다. 작업을 분해하고, 선택지를 평가하고, 여러 단계의 수정을 계획합니다. 그래서 Codex는 항상 즉시 응답하지는 않습니다 — 추론하고 있기 때문입니다.
PS: 벤치마크 결과에서 때때로 모델 이름에
high또는xhigh같은 용어가 붙어 있는 것을 볼 수 있습니다. 이것은reasoning_effort매개변수로, 모델이 얼마나 많은 추론을 수행할지 제어하는 설정 가능한 다이얼입니다. 일반적으로 더 높은 effort는 지연 시간을 늘리는 대신 더 강한 계획 능력과 복잡한 작업에서 더 나은 결과를 제공합니다.
하지만 실제 소프트웨어 엔지니어링은 단지 코드 몇 줄을 생성하는 것이 아닙니다. 여기에는 다음이 포함됩니다.
저장소를 읽고 이해하기
여러 단계의 계획 세우기
많은 파일에 걸쳐 수정하기
도구를 실행하고 출력을 해석하기
실패에 대응하기
실제로 작동할 때까지 반복하기
오늘날 OpenAI의 주력 모델은 다음과 같습니다.
이 동일한 모델들은 제품과 통합 선택에 따라 다른 코딩 경험에도 사용될 수 있습니다. 예를 들어,
또는
같은 도구 안에서 사용할 수 있습니다. 또한
같은 도구에서는 ChatGPT 요금제를 통해 접근할 수 있습니다. 그리고 Responses API를 통해서도 사용할 수 있지만, API 출시는 자사 표면보다 뒤처질 수 있어
에 먼저 제공되지 않을 수도 있습니다.
Cursor
@cursor_ai
이제 Cursor에서 GPT-5.3 Codex를 사용할 수 있습니다! 5.2보다 눈에 띄게 더 빠르며, 이제 우리 엔지니어 다수에게 선호되는 모델입니다.
dax
@thdxr
이제 opencode v1.1.11에서는 ChatGPT Plus/Pro 요금제를 OpenCode에서 사용할 수 있습니다. 설정하려면 /connect를 사용하세요
핵심은 이렇습니다. 모델은 지능입니다. 하지만 지능만으로는 에이전트가 되지 않습니다.
모델은 코드를 생성하고, 수정 사항을 제안하며, diff를 추론할 수 있습니다. 하지만 스스로 할 수 없는 것은 실제 저장소 안에서 작동하는 일입니다. 파일 시스템을 검사하거나, 테스트를 실행하거나, 빌드를 수행하거나, 엔지니어가 매일 의존하는 도구를 호출할 수는 없습니다.
그것이 바로 하니스의 역할입니다.
하니스는 모델을 실제 소프트웨어 환경에 연결하는 시스템입니다. 파일과 저장소에 대한 통제된 접근, 명령 실행 능력
, 그리고 정보가 모델 안팎으로 오갈 수 있는 구조화된 방식을 제공하여 더 큰 작업을 처리할 때 문맥 때문에 무너지지 않도록 합니다. 하니스는 모델이 추가 문맥을 끌어오고 도구를 사용해 일을 수행하게 해 줍니다 — 예를 들어
또는
을 통해서입니다.
실질적으로 하니스는 에이전트가 읽고, 계획하고, 실행하고, 검증하고, 작동하는 결과를 향해 반복하도록 만듭니다.
하니스가 없으면, 제안만 있습니다.
하니스가 있으면, 실행이 있습니다.
특히 Codex 하니스는
입니다. 실행이 어떻게 구조화되어 있는지 살펴보고 이해할 수 있습니다. 예를 들어 더 오래 걸리는 작업의 경우, 시스템은
을 사용합니다. 계속 늘어나는 대화 기록을 그대로 이어 가는 대신, 이전 문맥을 계속 진행하는 데 필요한 상태를 보존하는 요약으로 압축합니다. 목표는 문맥이 비대해지지 않으면서도 연속성을 유지하는 것입니다.
Codex 하니스에 대해 더 알아보고 싶다면, 엔지니어링 블로그
를 참고할 수 있습니다.
출처:
모델과 하니스는 나중에 따로 조립되는 별개의 부품이 아닙니다 — 함께 설계됩니다.
Codex 모델은 하니스가 있는 환경에서 훈련됩니다. 도구 사용, 실행 루프, compaction, 반복적 검증은 나중에 덧붙인 행동이 아니라, 모델이 작동하는 법을 배우는 방식의 일부입니다. 반대로 하니스는 모델이 계획하고, 도구를 호출하고, 실패에서 회복하는 방식에 맞추어 형성됩니다.
이를 선수와 라켓의 관계로 생각해 보세요. 프로 선수는 특정 장비와 함께 수년간 훈련합니다. 대회를 하루 앞두고 장비를 바꾼 뒤 같은 성능을 기대하지는 않을 것입니다.
Codex의 행동은 이 짝지음에서 나타납니다. 하나를 바꾸면, 에이전트도 바뀝니다.
모델과 하니스가 있으면, 에이전트가 생깁니다. 남은 질문은 그것을 어떻게 사용하고 싶은가입니다. 그 지점에서 제품 표면이 등장합니다.
Codex 에이전트는 작업에 따라 다양한 방식으로 사용할 수 있습니다. 때로는 여러 장기 실행 스레드를 병렬로 감독하고 싶을 수 있습니다. 때로는 에디터 안에서 긴밀한 반복 작업이 필요할 수 있습니다. 때로는 터미널 네이티브 조합 가능성이 필요할 수 있습니다. 때로는 원격 또는 비동기 작업을 위한 가벼운 진입점이 필요할 수 있습니다.
Codex가 여러 표면에 존재하는 이유는 소프트웨어 개발 생명주기의 각 단계가 서로 다른 상호작용 패턴을 요구하기 때문입니다.
은 병렬 작업 조율에 최적화되어 있습니다. 여러 에이전트, 여러 스레드, 장기 실행 작업을 한곳에서 감독할 수 있습니다. 또한 자동화와 skills를 관리하는 단일한 관점을 제공하며, 특히 이것들이 시간이 지나며 팀 내에서 늘어날수록 유용합니다. 2.
은 명시적 제어와 조합 가능성이 중요한 터미널 우선 워크플로를 위해 만들어졌습니다. 스크립트와 CI 파이프라인에 자연스럽게 통합되며, 동일한 에이전트 인프라 위에 프로그래밍 방식 워크플로를 구축할 수 있는
도 제공합니다. 3. VSCode
확장은 빠르고 문맥 내적인 편집에 중점을 둡니다 — diff를 검토하고, 변경 사항을 수락하고, 코드를 작성하는 바로 그곳에서 반복할 수 있습니다. 이외에도
와
을 위한 다른 네이티브 통합도 제공됩니다. 4.
은 원격 환경에서 비동기 작업을 시작하고 감독할 수 있는 가벼운 방법을 제공합니다.
출처:
내부적으로 이러한 경험의 상당수는
에 의해 구동됩니다. 앱 서버는 인증, 대화 기록, 승인, 스트리밍되는 에이전트 이벤트를 관리하여 IDE 확장이나 임베디드 통합 같은 풍부한 클라이언트가 동일한 기반 에이전트 시스템과 상호작용할 수 있게 합니다. 이를 통해 일관된 실행 모델을 유지하면서 Codex를 다른 제품에 내장하는 것이 가능해집니다. 앱 서버 역시 오픈 소스이므로 팀은 이를 살펴보거나 직접 그 위에 구축할 수 있습니다. 앱 서버에 대해서는 이
에서 더 알아볼 수 있습니다.
Codex는 협업 워크플로 안에서도 등장하도록 설계되었습니다.
에서는 코드 리뷰에 사용하고 PR에서 비동기 웹 작업을 실행할 수 있습니다.
또는
같은 도구에서는 팀이 작업을 계획하고 조율하는 곳에서 Codex가 동작할 수 있으며, 작업을 트리거하고 실행을 공유된 계획 시스템에 다시 연결할 수 있습니다.
결론적으로, 저는 Codex를 모델, 하니스, 제품 표면이라는 관점에서 생각하는 것이 무언가 새로 출시될 때 실제로 무엇이 바뀌는지 이해하는 데 도움이 된다고 봅니다.
다만 시간이 지나면 이러한 구분은 일상적인 사용에서는 덜 중요해져야 합니다. 그저 현재 작업에 맞는 곳에서 Codex를 꺼내 쓰게 될 것이고, 어디서 호출하든 하나의 일관된 툴킷처럼 느껴져야 합니다 — 일관된 동작, 일관된 안전 경계, 일관된 기대치와 함께 말입니다.
에이전트형 코딩이 처음이라면, 다음 단계는 아키텍처를 머릿속에 넣는 것이 아닙니다. 실제 작업 하나를 처음부터 끝까지 시도해 보는 것입니다. 하나의 표면을 고르고(Codex 앱이 보통 가장 쉬운 출발점입니다), 자신에게 중요한 무언가에서 어떻게 동작하는지 확인해 보세요.
마지막으로 한 가지 역사적 메모를 덧붙이자면: “Codex”는 원래 GitHub Copilot의 첫 번째 버전을 구동했던
을 가리키는 이름이었습니다. 오늘날의 Codex 모델과 제품군은 별개의 시스템입니다 — 다른 아키텍처, 다른 하니스, 다른 에이전트 설계 — 하지만 이름은 이어졌습니다. 근본적인 아이디어는 그대로였습니다. AI로 개발자가 더 빠르게 만들 수 있도록 돕는 것입니다. 이제는 단순히 코드 몇 줄을 돕는 데 그치지 않고, Codex가 완성된 작업을 실제로 출하하도록 도울 수 있습니다 — 그리고 당신은 그저 무언가를 만들면 됩니다.
