Codex는 어떻게 탄생했나
TMT저는 OpenAI가 천명(天命)을 잃을 수도 있겠다고 처음 생각한 순간을 정확히 기억합니다. 여기서 천명이란 ChatGPT가 처음 돌풍을 일으킨 이후 OpenAI가 AI 코딩에서 쌓아 온, 도저히 따라잡을 수 없을 것 같던 선두 자리를 말합니다. 2025년 여름, GPT-5 출시 전날 밤에 저는 OpenAI의 Mission Bay 사무실에 있었습니다.
건물 안에는 묘한 활기가 감돌았습니다. 천장 조명은 무대 조명처럼 이글거렸고, 사람들은 따뜻한 적갈색과 갈색으로 꾸민 복도를 평소보다 조금 더 빠르게 걷는 것 같았습니다. 중력마저 더 무겁게 느껴졌습니다. 마치 다음 날 있을 출시의 엄청난 규모가 나머지 세상을 자기 궤도로 끌어당기기라도 한 것 같았습니다.
제가 운영하는 회사 Every는 새로운 AI 모델을 실제 업무에 써 보고, 그 모델이 무엇을 할 수 있고 무엇을 할 수 없는지 설명하는 곳으로 이름을 알리기 시작한 참이었습니다. OpenAI는 출시 약 한 달 전에 저희가 GPT-5를 먼저 써 볼 수 있게 해 주었습니다. 저희가 모델의 강점과 약점을 OpenAI가 파악하도록 돕고, 출시 당일에 자세한 리뷰인 Vibe Check를 발행할 수 있게 하려는 것이었습니다.
저희 열 명은 팀 워크숍을 위해 뉴욕주 북부의 한 집에서 일주일을 보냈습니다. 길쭉한 나무 식탁 하나에 둘러앉아 함께 먹고 일했고, 큰 화면 앞 소파에 모여 오래 기다려 온 모델을 시험했습니다. 특히 AI가 가장 빠르게 발전하고 있던 코딩에 써 보는 것을 기대했습니다. 그런데 일상적인 용도로는 마음에 들었지만, Codex에서 써 본 반응은 시큰둥했습니다.
오늘날 Codex는 OpenAI가 반격하는 중심에 있습니다. ChatGPT를 안에서부터 집어삼켰고, 회사가 앞으로 만들 모든 것의 기반이 된 제품입니다. 하지만 그해 여름만 해도 Codex는 AI 소프트웨어 엔지니어를 만들려는, 아직 엉성하지만 악착같은 시도였습니다. 몇 달 전 클라우드에서 출시한 버전은 제품-시장 적합성(product-market fit)을 찾지 못했고, 팀은 개발자의 컴퓨터에서 터미널과 코드 에디터 안에서 돌아가는 새 버전으로 방향을 트는 중이었습니다.
Codex 안에서 GPT-5는 빨랐고, 똑똑해 보였습니다. 저희 팀에서 기술적으로 가장 뛰어난 엔지니어 중 한 명인 Naveen Naidu는 GPT-5를 써서, 직접 만든 음성 받아쓰기 앱 Monologue에서 며칠 동안 풀지 못하던 정체 모를 멈춤 현상의 원인을 찾아냈습니다. 하지만 GPT-5는 마치 허용된 범위 밖으로 나가기를 지나치게 꺼리는 것처럼, 너무 일찍 멈추는 것 같기도 했습니다. 페어 프로그래머로 쓰도록 설계된 모델처럼 느껴졌습니다.
팀으로서 저희는 AI 모델과 한 단계씩 협업하는 방식에서 벗어나고 있었습니다. Kieran Klaassen이 이끄는 몇몇은 Anthropic의 터미널 에이전트인 Claude Code를 써서, 작업 전체를 Opus 4에 맡기고 완성된 기능이, 때로는 앱 전체가 돌아올 때까지 자리를 비우기 시작했습니다. 스태프 작가 Katie Parrott는 엔지니어의 도움을 거의 받지 않고 며칠 만에 자신만의 AI 콘텐츠 관리 시스템을 만들어 배포했습니다. 버그가 좀 있었지만, 예전 같으면 엄두도 못 낼 일이었습니다.
Claude Code 안의 Opus 4와 나란히 놓고 보면, Codex 안의 GPT-5는 상자에 갇혀 있는 느낌이었습니다.
테스트에서 알게 된 것을 공유하러 온 덕분에, 저는 OpenAI 사무실의 한 회의실에서 커뮤니케이션 팀의 Lindsay McCallum, Codex 팀의 Alexander Embiricos와 마주 앉게 되었습니다. 시장 분위기의 변화를 예리하게 감지하는 McCallum이, 제가 왜 갑자기 입만 열면 이 새로운 작업 방식 이야기를 하는지 Embiricos에게 설명할 수 있도록 이 자리를 마련한 것 같았습니다.
McCallum은 회의 테이블 건너편에서 노트북으로 무섭게 집중해서 타이핑하고 있었습니다. Embiricos는 제 옆에 앉아 이야기하면서 코딩을 했는데, 저는 그걸 좋은 신호로 받아들였습니다. 그는 GPT-5 출시에 맞춰 들어갈 기능을 서둘러 마무리하고 있었습니다. 에이전트가 샌드박스 밖의 파일에 접근하거나 명령을 실행하기 전에 잠시 멈추고 사람에게 허락을 구하게 하는 기능이었습니다.
"Claude Code는 그냥 마음껏 달리게 두면 돼요." 제가 Embiricos에게 말했습니다. "GPT-5는 좀 소심하게 느껴져요. 샌드박스에 발이 묶인 것처럼, 자기 힘을 쓰는 걸 겁내는 것 같아요."
McCallum의 타자 소리가 느려졌습니다. "Alexander한테 요즘 쓰는 새 엔지니어링 워크플로 얘기 좀 해 줘요." McCallum이 노트북에서 눈을 떼지 않은 채 그렇게 말했던 기억이 납니다.
Embiricos는 의자를 돌려 저에게 온전히 집중했습니다.
"저희는 이제 코드를 거의 보지도 않아요." 제가 말을 꺼냈습니다. 하지만 말하면서 얼굴이 달아올랐습니다. 다른 사람도 아닌 Embiricos 앞에서 에이전트에게 일을 맡기는 방식을 설명하자니 우스꽝스럽게 느껴졌습니다. 자율 코딩 에이전트를 만드는 게 바로 그의 일이었으니까요. 게다가 그때는 저희 엔지니어링 방식이 저희 같은 작은 팀 밖에서도 통할지 확신이 없었습니다.
Slack 알림이 Embiricos의 화면을 밝히며 회의실에 갑자기 찾아온 정적을 깼습니다. 그는 컴퓨터 소리를 끄고 노트북 덮개를 4분의 3쯤 닫았습니다. Codex 에이전트가 계속 생각할 수 있을 만큼만 열어 둔 것입니다.
그날 밤 Mission Bay를 나서면서, 저는 OpenAI가 저물어 가는 워크플로를 위해 완벽한 도구를 만들고 있는 건 아닌지 궁금했습니다. 실패한 클라우드 에이전트로 한 번 데인 OpenAI는, AI가 프로그래머의 작업을 한 단계씩 돕는 코드 에디터로 물러서는 것처럼 보였습니다. 그사이 Claude Code는 작업 전체를 맡기고 자리를 뜨는 사람들 사이에서 급속히 퍼지고 있었습니다.
에디터에 머물 만한 이유는 충분했습니다. GPT-5 출시 후 Codex 팀은 확장 프로그램을 내놓았습니다. 프로그래머가 코드를 작성하고 실행하고 디버깅하는 Microsoft의 Visual Studio Code(VS Code)나 Cursor 같은 코드 에디터의 사이드바에 Codex를 넣어 주는 확장 프로그램이었습니다. 사용량은 지난 10월까지 10배 넘게 늘었고, 에디터 확장 프로그램은 금세 터미널을 제치고 Codex에서 가장 많이 쓰이는 사용 환경이 되었습니다.
대부분의 회사였다면 이 사업에 더 힘을 실었을 것입니다. 하지만 Embiricos와 OpenAI 내부의 엔지니어, 디자이너, 연구자 몇 명으로 이루어진 작은 그룹은 더 큰 야망을 품고 있었습니다.
그 뒤 몇 달 동안 Codex 팀은 ChatGPT를 구동하는 모델과는 별도로 코딩 전용 모델 라인을 학습시켜 빠르게 개선했고, 여러 에이전트를 한꺼번에 관리하는 데스크톱 앱을 만들었습니다. 2026년 6월에는 Codex의 주간 활성 사용자가 500만 명을 넘었고, 프로그래밍을 넘어 다른 종류의 지식 노동으로도 퍼지고 있었습니다.
2026년 7월에는 Codex가 OpenAI의 대표 제품인 ChatGPT 데스크톱 앱에 통합되었습니다. Codex를 이끌던 Thibault Sottiaux는 ChatGPT, Codex, API를 포함해 OpenAI의 핵심 제품과 플랫폼 전체를 총괄하는 자리로 승진했습니다. 현재 Codex와 ChatGPT for Work를 합친 주간 활성 사용자는 4,000만 명입니다.
1년도 안 되는 사이에 Codex 팀은 실패한 클라우드 출시에서 출발해 OpenAI 대표 제품의 기반이 되었고, 그 과정에서 회사를 새롭게 바꾸는 데 힘을 보탰습니다.
이 글은 Codex가 어떻게 탄생했는지에 대한 이야기입니다.
생각 중...
뭔가 이상하다. 1년 전에 앞서 있던 격차가 결과에 보이지 않는다…
문제는 내가 생각했던 것보다 더 앞에서 시작된 것 같다…
처음으로 돌아가 보자…
생각 중…
OpenAI의 반격은 "생각 중..."(Thinking...)이라는 단순한 한 줄에서 시작됩니다.
2026년에는 AI 모델에게 조금이라도 복잡한 요청을 할 때마다, 응답이 나타날 자리에서 생각 중이라는 말이 반짝이는 것을 보게 됩니다.
별것 아닌 장치처럼 보일 수도 있습니다. macOS에서 돌아가는 비치볼이나, Windows가 커서 옆에 띄우는 빙글빙글 도는 파란 고리를 한 단어로 바꿔 놓은 것뿐이니까요. 둘 다 컴퓨터가 너무 바빠서 응답할 수 없다는 신호입니다.
하지만 여기서 "생각 중"이라는 말은 새로운 컴퓨팅 방식을 뜻하며, 이 방식이 없었다면 Codex는 결코 탄생하지 못했을 것입니다.
1세대 대규모 언어 모델은 말하면서 생각을 정리하는 유형(external processor)이었습니다. 내부 추론을 보여 주는 반짝이는 상태 표시가 없었고, 대신 사용자에게 응답하는 과정에서 곧바로 생각을 했습니다. 이메일을 써 달라고 하든 코드 한 줄을 써 달라고 하든, 미리 계획하거나 나중에 고칠 기회 없이 한 번에 한 단어씩 답을 만들어 내야 했습니다.
그런 의미에서 초기 채팅 모델은 관객이 던져 준 제시어를 바탕으로 그 자리에서 장면을 지어내는 즉흥극 배우와 비슷했습니다. 이 도구들은 즉석에서 글을 써 내려갔기 때문에, 결과가 인상적일 때도 있었고 의도치 않게 우스울 때도 있었습니다. (모델은 "strawberry"에 r이 두 개라고 우기고, 증명하겠다며 철자를 하나하나 적은 다음, 마지막에는 스스로를 칭찬하곤 했습니다.)
이런 모델을 일찍 써 본 사용자들은, 답하기 전에 추론 과정을 한 단계씩 적어 보라고 하면 모델이 더 나은 답에 이르는 경우가 많다는 것을 알아차렸습니다. 초등학교 수학 선생님이 학생에게 해 주는 조언과 똑같은 이 기법은 사고의 사슬(chain-of-thought) 프롬프팅이라고 불렸습니다.
사고의 사슬 프롬프팅은 2세대 AI 모델과 반짝이는 "생각 중" 사용자 인터페이스로 이어졌습니다. OpenAI는 사용자가 모델에게 문제를 한 단계씩 풀어 보라고 요청하게 하는 대신, 그 행동을 모델 자체에 학습시켰습니다. 추론 모델은 응답하기 전에 추론 트레이스(reasoning trace)라고 부르는 일종의 연습장에서 작업합니다. 여기서 모델은 여러 각도로 문제를 공략하고, 막다른 길에서는 되돌아 나오고, 성공할 가능성이 더 높은 경로를 고를 수 있습니다. 그리고 답을 정한 뒤에야 응답합니다.
OpenAI는 이런 종류의 첫 모델을 o1이라고 부르고, 2024년 9월에 프리뷰 버전을 공개했습니다. 그때까지 발전은 주로 더 큰 모델을 더 오래 학습시키는 데 달려 있었습니다. o1을 통해 OpenAI는 같은 모델이라도 어려운 문제에 시간을 더 들이기만 하면 더 나은 답을 낼 수 있다는 것을 알아냈습니다.
이 변화로 다른 어떤 일보다 큰 이득을 볼 분야가 있었습니다. 바로 프로그래밍입니다. 프로그래밍은 닫힌 루프를 제공하기 때문에 추론 모델에 유난히 잘 맞습니다. 모델은 코드를 고치고, 실행하고, 그 변경이 효과가 있었는지 몇 초 안에 확인할 수 있습니다. 덕분에 사람이 확인해 주지 않아도 스스로 수정안을 시험하고 고쳐 나갈 수 있습니다.
이론적으로는 추론 모델에게 충분히 오래 생각할 시간을 주면, 어떤 프로그래밍 작업이든 혼자 해낼 수 있습니다.
여러 번의 시작
AI 프로그래머를 만드는 일은 OpenAI가 너무 오랫동안 품어 온 목표라서, Codex에는 시작이 여러 번 있었습니다. 이름부터가 그렇습니다.
2021년에 나온 첫 번째 Codex는 공개 코드로 미세 조정한 GPT-3의 한 버전으로, 초창기 GitHub Copilot을 구동했습니다. 3년 뒤, o1 프리뷰가 추론 모델의 가능성을 보여 준 지 몇 주 만에, 경영진의 요청을 계기로 OpenAI 곳곳의 여러 그룹이 저마다 다른 방향에서 다시 그 꿈을 좇기 시작했습니다.
그런 시작 가운데 하나는 2024년 말 Embiricos에게서 나왔습니다.
"제게 처음으로 'AGI가 실감 난다(feel-the-AGI)' 싶었던 진짜 엄청난 순간은, 누가 터미널에 연결된 추론 모델을 돌리는 걸 봤을 [때]예요." 그가 제게 말했습니다. AI가 더는 도구처럼 느껴지지 않고, 사람처럼 생각하고 행동할 수 있는 기계처럼 느껴지기 시작하는 순간을 가리키는 말이었습니다. "지금은 [그게] 별로 신나는 일이 아니라는 거 알아요." 하지만 모델이 혼자서 파일을 읽고, 명령을 실행하고, 오류를 해결해 나가는 모습을 지켜보는 건 "미치게 멋졌어요."
Embiricos는 제가 GPT-5 출시 전날 밤에 만났던 제품 책임자로, 그해 초 자신이 공동 창업한 프로그래머용 멀티플레이어 화면 공유 도구 Multi를 OpenAI가 인수하면서 OpenAI에 합류했습니다. OpenAI에서는 이와 관련된 아이디어를 좇았습니다. 사람과 에이전트가 자기가 쓰는 앱 안에서 함께 일하게 하는 것이었습니다. 이 비전을 처음에는 ChatGPT 데스크톱 앱에서, 그다음에는 AI 기반 브라우저인 Atlas에서 추구했지만, 당시 모델은 사용자의 화면을 읽기에는 너무 느리고 서툴러서 쓸모가 없었습니다.
하지만 터미널에서는 모델이 화면을 읽을 필요가 없었습니다. 텍스트와 코드를 직접 다루면 됐습니다. 초기 추론 모델이 터미널에서 일하는 모습을 보고, Embiricos는 추론 모델로 진짜 코딩 제품을 만들 수 있다고 확신했습니다. 아직 코딩이 그의 본업은 아니었지만, 그는 곧바로 그런 제품을 구상하기 시작했습니다. 그는 제품이 제대로 돌아가려면 사용자가 모델이 하는 일을 30초마다, 길어도 1분마다 볼 수 있어야 한다고 믿었습니다.
이번에도 문제는 속도였습니다. 당시 AI 코딩 제품 대부분은 VS Code를 중심으로 성장했습니다. GitHub Copilot은 확장 프로그램으로 AI 자동 완성을 추가했고, Cursor와 Windsurf는 VS Code의 오픈 소스 코드를 바탕으로 자체 에디터를 만들어 프로그래머가 작업하는 화면 옆에 AI 채팅을 붙였습니다.
이런 도구는 촘촘한 피드백 루프에 의존했습니다. Copilot은 입력 중인 줄을 완성해 주었고, Cursor와 Windsurf는 몇 초 안에 질문에 답했습니다. 어느 도구도 모델에게 오랫동안 혼자 일하라고 하지 않았는데, 모델이 그럴 수 없었기 때문입니다. OpenAI의 초기 추론 모델은 정반대였습니다. 느렸고, 생각할 시간을 줄이면 성능이 약해졌습니다.
그는 모델의 결함, 즉 응답을 받기까지 오래 걸린다는 점을 오히려 장점으로 바꿀 수 있을까요?
만드는 이를 만들기
한편 OpenAI의 다른 곳에서는 Tibo라는 이름으로 통하는 Sottiaux가 추론 모델을 바로 그 모델을 만드는 일에 다시 투입하려 하고 있었습니다. 추론 모델의 능력으로 연구자들이 다음 세대 모델을 만드는 일을 돕게 하려는 것이었습니다.
"저는 2024년 12월쯤 코딩 에이전트 일에 뛰어들었어요." 그가 제게 말했습니다. 저희는 OpenAI 구내식당에 앉아 있었습니다. 윤기 나는 갈색 머리는 한쪽으로 흘러내렸고, 가는 금속테 안경에 오후 햇살이 비쳤습니다. 코 위로는 건축가 같았다면, 코 아래로는 영락없는 프로그래머였습니다. 갈색 수염이 까칠하게 자라 있었고, "Research and Deployment Co"라고 찍힌 짙은 갈색 후드티를 입었으며, 손에는 페퍼로니 피자 한 조각을 들고 있었습니다.
그는 피자를 한입씩 먹는 사이사이에 목표를 이렇게 설명했습니다. "인프라를 작성하고 연구를 더 빠르게 하도록 돕는 것이었어요."
Sottiaux는 처음에는 DeepMind에서, 그다음에는 OpenAI에서 경력의 상당 부분을 연구자를 위한 인프라를 만드는 데 보냈습니다. 연구 인프라는 AI 연구자들이 실험을 실행하고, 평가하고, 재현하고, 배포할 때 기대는 공용 코드를 말합니다. 결국 Codex를 이끌게 될 사람의 출발점으로는 조금 의외로 보일 수도 있습니다. 인프라라고 하면 서버나 해저 케이블을 떠올리기 쉽습니다. 기술 업계의 배관 같은 것으로, 꼭 필요하지만 파이프가 새기 전까지는 눈에 띄지 않습니다.
하지만 AI 업계에서는 인프라, 특히 연구 인프라에서 많은 일이 벌어집니다. 실험 한 번에 걸리는 시간을 줄이면 더 많은 실험을 돌릴 수 있고, 더 좋은 모델을 더 빨리 얻을 수 있습니다.
"모델 라인은 언제 분리하셨어요?" 제가 물었습니다. "어떻게 결정하셨어요?" 저는 본론으로 빨리 넘어가고 싶었습니다. 자체 모델 라인을 갖췄다는 점은 Codex가 가진 마법의 핵심처럼 느껴졌습니다. 저는 OpenAI 안에서 열린 어떤 회의를 상상했습니다. Sottiaux나 사장이자 공동 창업자인 Greg Brockman, 또는 CEO Sam Altman이 Codex를 ChatGPT의 나머지 부분과 분리하기로 선견지명 있는 결정을 내리고, 팀이 빠르게 출시하며 회사를 안에서부터 뒤집을 수 있는 자유를 주는 장면이었습니다.
"모델 라인을 분리하자는 결정 같은 건 없었어요." Sottiaux가 담담하게 말했습니다. 그의 말에 따르면 처음에 이 일은 "연구 차원의 탐색이자 저희 속도를 최적화하는 일"이었습니다.
Sottiaux의 그룹은 일반 사용자용 모델을 만드는 대신, OpenAI의 모노레포로 내부 코딩 에이전트를 학습시켰습니다. 모노레포는 조직의 모든 코드가 들어 있는 단일 저장소입니다. 에이전트들은 OpenAI 연구자들이 새 모델을 만드는 시스템을 운영하고 개선하는 데 필요한 Python 코드를 작성했습니다. 연구자들은 이 에이전트를 매일 썼고, 덕분에 팀은 촘촘한 피드백 루프를 얻었습니다.
"코딩 성능이 빠르게 좋아지는 게 보였어요." Sottiaux가 말했습니다. 그의 팀은 모델을 자주 학습시켰는데, 더 큰 조직이 일반 사용자용 모델을 학습시키는 방식과는 다르고, 한동안은 그 방식과 맞추기도 어려운 기법을 썼습니다.
Sottiaux도 다른 AI 연구소 사람들처럼 그 학습 기법에 대해서는 입을 굳게 다뭅니다. 하지만 그 기법이 효과가 있다는 것은 분명해졌습니다. 그의 그룹은 모델을 탄생시킨 연구 과정에 그 모델을 다시 투입하는 데 성공했고, 연구자들은 그 모델로 다음 세대 모델을 만들고 있었습니다.
엔지니어들은 이를 부트스트래핑(bootstrapping)이라고 부릅니다. 연구자들이 실험을 돌리는 것을 잘 돕는 모델을 만들면, 연구자들은 그 모델로 더 강력한 모델을 만들 수 있습니다. 그 모델은 더 나은 실험을 돌리고, 그 실험은 더 나은 모델로 이어지는 식으로 계속됩니다.
이 작업으로 훗날 Codex가 될 것의 절반이 갖춰졌습니다. 새 모델을 만드는 인프라를 개선할 수 있는 에이전트였습니다. 회사의 다른 사람들도 쓸 수 있는 제품이 되려면, 그리고 결국 OpenAI라는 울타리를 넘어 바깥으로 나가려면, 나머지 절반이 필요했습니다. 사람들이 그런 에이전트와 어떻게 함께 일해야 하는지에 대한 Embiricos의 가설이었습니다.
생각 중...
지금까지 접근법이 세 가지다…
그중 두 개가 겹친다…
그 둘을 합치고, 효과 있는 쪽으로 계속 가자…
수렴
탐색 다음에는 수렴이 옵니다.
2024년 마지막 몇 달과 2025년 초의 OpenAI를 위에서 내려다본다고 상상해 보겠습니다. 코딩이 회사 최상위 목표가 된 뒤, Sottiaux와 Embiricos를 포함한 여러 팀이 같은 질문을 저마다 다른 각도에서 파고들기 시작했습니다.
Brockman의 말에 따르면, 아직 답이 나오지 않은 질문은 알맞은 "폼 팩터"가 무엇이냐였습니다. 에이전트가 개발자가 명령을 실행하는 터미널에 있어야 하는지, 코드를 작성하는 에디터에 있어야 하는지, 아니면 클라우드에서 자기 컴퓨터로 혼자 일해야 하는지였습니다. 이 경로 중 일부는 막다른 길이었지만, 당시에는 어느 쪽이 그런지 아무도 몰랐습니다.
"어떤 의미에서 OpenAI는 여러 스타트업에 베팅하고 있는 셈인데, 그게 전부 내부에 있는 거죠." Altman은 2025년 Ben Thompson과 한 인터뷰에서 이렇게 말했습니다. 제가 이야기를 나눈 몇몇 내부 사람들에게는, 회사 안에서 여러 갈래로 동시에 탐색하는 이런 분위기가 때로 혼란스럽고 낭비처럼 느껴집니다. OpenAI 안에서 세 번째로 좋은 에이전트 제품을 만든 팀에서 일하고 싶은 사람이 누가 있을까요? 제 회사에서도 비슷한 전략을 써 본 저로서는, 탐색할 여지를 만드는 것과 완전히 엉망을 만드는 것 사이의 경계가 아주 얇다는 것을 압니다.
하지만 OpenAI를 지켜보면서, 그리고 내부에서 들려오는 불만에도 불구하고, 저는 최전선이 계속 움직일 때는 이런 방식이 필요하다고 보게 되었습니다. 고(故) 하버드 교수 Clayton Christensen의 용어를 빌리자면, AI에서는 모델 수준의 빠른 "존속적" 발전이 새로운 종류의 앱을 가능하게 하고, 그 앞에 나온 앱들을 끊임없이 밀어냅니다.
코드 한 줄을 완성할 수 있는 모델은 자동 완성 도구로 잘 작동합니다. 30초 동안 생각할 수 있는 모델은 채팅 사이드바에서 질문에 답할 수 있습니다. 한 시간 동안 일할 수 있는 모델은 완전히 다른 무언가가 되려고 합니다. 이전 모델을 중심으로 성공적인 제품을 만들었다고 해서 다음이 무엇인지 아는 것은 아닙니다. 여러 팀이 서로 다른 아이디어를 시도하게 하고, 무엇이 쓸모 있는지 보이면 그 작업을 하나로 모아야 합니다.
2025년 초, OpenAI는 바로 그 일을 할 준비가 되어 있었습니다. "결국 Scientist Assistant라는 다른 프로젝트와 힘을 합쳐야겠다고 생각했어요." Sottiaux가 말했습니다. 이 통합으로 그는 Embiricos와 한 팀이 되었습니다. Brockman은 내부의 여러 코딩 프로젝트를 두고 이렇게 말했습니다. "결국 그중 두 개를 합쳤어요. 그리고 또 다른 두 개를 합쳤죠." 합쳐진 팀은 여러 분야 사람들이 모인 작은 팀이었습니다. Embiricos 같은 기술적인 제품 기획자, Sottiaux 같은 인프라와 엔지니어링의 귀재, Mia Glaese 같은 연구자가 함께했습니다.
Glaese는 DeepMind에서 OpenAI로 왔습니다. DeepMind에서는 Gemini와 모델 정렬(alignment) 작업을 했습니다. OpenAI에서는 모델 학습과 정렬에 쓰이는 데이터를 책임졌는데, 모델의 구체적인 행동을 만들어 낼 데이터를 확보하고 활용하는 일이 전문이었다는 뜻입니다.
어떤 면에서 Glaese는 감상이라고는 없는 철저한 경험주의자입니다. 인터뷰에서도 거리낌 없이 수치를 앞세웠습니다. "그냥 감(vibe)을 믿는 건 연구에서 그다지 쓸모가 없어요." 하지만 모델을 만드는 과정을 이야기할 때는, 그 과정의 상당 부분이 미지의 세계로 뛰어드는 일이라며 금방 웃음을 터뜨립니다.
"모델을 학습시킬 때마다 저희는 마법 같은 모험을 떠나요. '이걸 대체 어떻게 하지?' 하면서요." Glaese가 말했습니다.
제품 담당자와 연구자가 나란히 일하는 이런 다학제 팀은 AI 업계에서 다소 드문 편입니다. AI는 역사적으로 연구 중심 분야였고, 최고의 연구자들은 LeBron James급의 수백만 달러짜리 계약을 따내는 반면, 나머지는 업계 표준 수준의 엔지니어 연봉을 받았습니다. (AI 연구소들은 이렇게 슈퍼스타를 떠받드는 분위기에 맞서려고, 오래전부터 연구자든 아니든 대부분의 기술직 직원에게 "Member of Technical Staff"라는 직함을 붙여 왔습니다.)
제품 팀과 함께 일하면서 Glaese와 다른 연구자들은 자기 모델이 어떻게 쓰이는지 보고, 사람들이 모델에게 다음으로 무엇을 원하는지 들을 기회를 얻었습니다. 제품 담당자는 이렇게 물을 수 있었습니다. "모델이 이런 걸 할 수 있으면 정말 멋지지 않을까요?" 그러면 연구자들이 그것을 실현했습니다. Sottiaux의 부트스트래핑 루프가 다시 등장한 셈인데, 이번에는 모델과 그 모델 위에 만든 제품 사이에서 돌아갔습니다.
마침내 OpenAI에 제품, 디자인, 연구가 모두 함께 일하는 Codex 팀이 생겼습니다. 이제 무엇을 만들지만 정하면 됐습니다.
생각 중...
터미널, 에디터, 클라우드 중 하나를 시도해 볼 수 있다…내가 가진 모델에는 어떤 접근법이 맞을까?
우리 연구자들은 클라우드에서 일한다. 다른 개발자들도 거기서 일할 수 있을까?
클라우드와 그 한계
Anthropic에서는 유망한 접근법이 이미 인기를 얻기 시작했습니다.
2025년 2월 24일, Anthropic은 Claude 3.7 Sonnet을 출시하면서 Claude Code 리서치 프리뷰도 함께 공개했습니다. Cursor 같은 도구와 달리 Claude Code에는 코드 에디터가 내장되어 있지 않았습니다. Claude Code는 터미널에서 실행되었고, 사용자의 컴퓨터에 있는 파일을 직접 다뤘습니다. 원하는 것을 말하면 Claude Code가 코드를 읽고, 변경하고, 실행했습니다.
사용자의 컴퓨터에서 실행되었기 때문에, Claude Code가 한 작업은 사용자가 이미 작업하던 바로 그 파일에, 이미 설치해 둔 바로 그 도구로, 지금까지 함께 해 온 모든 작업의 맥락을 그대로 안고 반영되었습니다. 작업 도중에 끼어들 수도 있었습니다. 한 세션에서 배운 교훈을 다음 세션으로 가져가서, 시간이 지날수록 자기 시스템이 나아지고 그 효과가 쌓이게 할 수도 있었습니다. 일회용 클라우드 컴퓨터를 쓰는 Codex Cloud에서는 불가능한 일이었습니다.
개발자들은 Claude Code를 빠르게 받아들였습니다. 예를 들어 Every의 Edmar Ferreira는 2025년 3월 Vibe Check에 이렇게 썼습니다. "에이전트 쪽에서는 Claude Code가 내가 써 본 어떤 것보다 낫다." 나머지 팀원들도 동의하기 시작했습니다.
2025년 봄, Embiricos, Sottiaux, Glaese를 비롯한 몇 명으로 이루어진 통합 Codex 팀은 소프트웨어 엔지니어링의 미래를 두고 다른 비전에 눈을 돌렸습니다. 바로 Codex Cloud였습니다. 팀이 그린 것은 자기 컴퓨터를 갖춘 채 클라우드에서 일하는 에이전트였습니다. 비동기 작업을 위해 설계되어, 사용자가 자기 컴퓨터나 휴대폰에서 코딩 작업을 맡길 수 있는 에이전트였습니다. 팀은 이를 만들고 출시하는 데 약 7주라는 기한을 스스로 정했습니다.
ChatGPT 사이드바에서 Codex를 누르면 작업 공간이 열리고, 거기서 작업을 설명한 뒤 "Code" 버튼을 누를 수 있었습니다. 그러면 그 작업은 대기열로 빠져나가고, 프롬프트 입력창은 다음 작업을 위해 비워졌습니다. Codex는 사용자의 코드베이스를 격리된 클라우드 머신으로 복사하고, 파일을 수정하고, 테스트와 린터를 실행했습니다. 린터는 흔한 실수를 찾아 코드를 검사하는 도구입니다. 그런 다음 요약과 변경 사항의 diff, 그리고 풀 리퀘스트를 여는 버튼을 돌려주었습니다.
Codex Cloud는 2025년 5월 16일에 출시되었습니다. 제가 Mission Bay에서 McCallum, Embiricos와 만난 그날 밤보다 3개월쯤 앞선 때였습니다. Sottiaux는 Codex Cloud가 "내부에서는 아주 성공적이었다"고 말했습니다. OpenAI 밖에서는 출시가 관심을 끌었지만, 꾸준히 쓰는 사람은 많지 않았습니다.
Codex Cloud를 쓰려면 개발자는 노트북에 있는 소프트웨어, 권한, 설정을 클라우드에 다시 만들어야 했습니다. 자격 증명을 복사하고 핵심 소프트웨어 패키지를 설치해야 했기 때문에, 이 과정에 몇 시간이 걸리기도 했습니다. 일단 설정을 마치면, 명확하게 정의된 작업은 해낼 수 있었습니다. 하지만 방향을 바로잡으려고 도중에 끼어들 수는 없었고, 후속 프롬프트 하나만 보내도 새 클라우드 컴퓨터가 시작되었습니다.
"기존 코드베이스에 기능을 추가하거나 버그를 고치는 테크 리드라면 손이 갈 도구다. 바이브 코딩으로 혼자서 10억 달러짜리 SaaS 회사를 새로 만들려는 거라면 다른 데를 알아보라." 저는 출시 당일 Vibe Check에 이렇게 썼습니다.
OpenAI 내부에서는 표준화된 개발 환경 덕분에 설정이 자동으로 이루어졌고, 연구자들에게는 맡길 일이 명확하게 정해져 있었습니다. 팀은 자기들이 일하는 환경 때문에, 다른 사람들에게 얼마나 많은 것을 요구하고 있는지 보지 못했습니다.
Codex Cloud의 발목을 잡은 것은 제품만이 아니었습니다. "모델이 충분히 똑똑하지 않았기 때문에 너무 일렀어요." Embiricos가 말했습니다.
"저희는 좀 더 미래의 비전을 가지고 접근했던 것 같아요." Glaese가 말했습니다. "'사람들이 있는 곳으로 가자' 같은 식으로 하지 않았어요." 사람들이 있는 곳은 바로 "그들의 노트북"이었습니다.
그렇다면 OpenAI는 왜 Anthropic에서 효과를 보기 시작한 터미널 폼 팩터를 건너뛰었을까요?
"건너뛴 게 아니에요." 구내식당에서 이야기를 나누던 중에 Sottiaux가 말했습니다. 공개되지 않은 내부 프로토타입을 두고 한 말이었습니다. "그런 버전을 만들었다가, 완전한 클라우드 버전으로 가려고 한 달 만에 버렸어요."
"왜요?" 제가 물었습니다. 사방으로 바닥부터 천장까지 이어진 커다란 창밖 어딘가를 제대로 살펴보면, 지평선 위로 Anthropic 사무실을 찾을 수 있을 것 같았습니다. 그리 힘들이지 않고 걸어갈 수도 있는 거리였습니다. 샌프란시스코는 작은 동네입니다.
"설정에 많이 투자할 각오만 되어 있다면 저희가 가장 큰 이득을 볼 거라고 생각한 쪽에 맞춰 최적화하고 있었으니까요." 그가 말했습니다.
그 대답 뒤에는 OpenAI 내부 사람들에게서 거듭 들은 믿음이 있었습니다. 그들에게 AI 에이전트의 이상적인 형태는 언제나 클라우드에서 자율적으로 일해 주고, 노트북 덮개를 닫아도 응답을 멈추지 않는 에이전트였습니다. Brockman도 인터뷰에서 같은 말을 했습니다. "미래를 내다보면, 알맞은 폼 팩터는 자기 노트북을 가진 클라우드 속 AI예요. 그래서 실제로 그걸 만든 거죠."
그 선택은 모델의 한계와 타협한 결과이기도 했습니다. 팀은 첫 Cloud 제품을 프로그래머에게 매 순간 반응하는 모델이 아니라, 한 작업에 더 오래 매달릴 수 있는 모델을 중심으로 만들었습니다.
문제는 그게 통하지 않았다는 것입니다. Cloud 제품은 제품-시장 적합성을 찾지 못했습니다. 팀의 엔지니어링 매니저는 기업 가치 90억 달러로 AI 코딩 분야 선두를 달리던 Cursor로 떠났습니다. 이 무렵 OpenAI는 Cursor의 가장 가까운 경쟁사인 Windsurf를 인수하기로 30억 달러 규모의 합의에 이르렀다고 알려졌습니다. 이 거래는 결국 7월에 무산되었습니다.
"가장 힘들었던 때는 뭘 해야 할지 모르겠다고 느꼈을 때였어요. 아니면 뭘 해야 할지는 알았는데, 그게 실제로 [진전되는] 걸 보기가 정말 어려웠을 때요." Embiricos가 말했습니다.
처음으로 Codex 팀은, 그리고 어느 정도는 OpenAI의 더 큰 코딩 야망도, 황야에서 길을 잃었습니다.
생각 중...
음, 우리 환경에서는 이게 통했다. 사용자에게는 왜 안 통하지?
엉뚱한 걸 고치려 하고 있는지도 모른다…
제쳐 뒀던 로컬 접근법으로 돌아가 보자…
여기에 뭔가 있다. 그런데 다시 만들어야겠다…
다른 길
추론 모델이 강력한 이유는 되돌아갈 줄 알기 때문입니다. 버그가 코드의 특정 부분에 있다고 믿고 그 부분을 다시 썼는데 버그가 여전히 남아 있다면, 추론 모델은 보통 틀린 방향으로 자신만만하게 계속 나아가지 않습니다. 자신의 가정을 다시 검토하고, 해결책을 찾는 범위를 넓히고, 배운 것을 바탕으로 더 유망한 새 경로를 정할 수 있습니다.
실수를 이용해 방향을 바로잡는 이 능력 덕분에 추론 모델은 처음에는 분명하지 않던 답을 찾아낼 수 있습니다.
Cloud 출시의 여파가 이어지던 2025년 늦봄과 여름, Codex 팀은 다른 길을 시도할 준비가 되어 있었습니다. 당시 이 프로젝트는 얼마 전 팀에 합류한 디자이너 Ed Bayes의 기억에 따르면 OpenAI의 "변방"에 있었습니다. "주목받는 디자이너가 되고 싶으면 ChatGPT 쪽에서 일[했]죠." 그가 말했습니다.
바로 이 외면받던 전초기지에서, Sottiaux가 팀의 엔지니어링 매니저로 올라섰습니다. "제가 팀을 맡고 나서 방향을 꽤 많이 바꿨어요." 그가 말했습니다. "로컬로 방향을 틀었죠."
"로컬"이란 에이전트를 클라우드가 아니라 Claude Code처럼 개발자 자신의 컴퓨터에서 실행한다는 뜻이었습니다. 팀은 로컬 Codex CLI에서 출발했습니다. Embiricos의 말처럼, 두 사람이 사이드 프로젝트로 "영웅적으로" 만든 도구였습니다. Sottiaux는 곧바로 기능을 추가해 빠르게 추진력을 얻는 대신, 다른 방법을 택했습니다. 에이전트를 다시 작성하기로 한 것입니다.
"정말 좋은 CLI 기능을 갖추는 게 좀 늦었어요." 그가 말했습니다. "에이전트를 개발하느라 너무 바빴거든요."
CLI는 사용자가 직접 다루는 인터페이스였지만, Sottiaux가 우선으로 둔 것은 그 밑에 있는 기계 장치였습니다. 파일을 읽고, 명령을 실행하는 등의 일을 하는 에이전트 말입니다. 그는 에이전트를 개선하고 터미널 인터페이스에서 떼어 내서, 코드 에디터 안이든, 데스크톱이나 모바일 앱이든, 클라우드든, ChatGPT 자체든 어디에서나 돌아갈 수 있게 만들고 싶었습니다.
팀은 속도와 안전성이 중요한 시스템을 위해 설계된 언어인 Rust로 에이전트를 다시 만들었습니다. 그러자 같은 기계 장치로 터미널 CLI와, 나중에는 에디터 확장 프로그램까지 구동할 수 있게 되었습니다.
하지만 아직 부족한 것이 있었습니다. 이 에이전트를 몰 만큼 좋은 모델이었습니다.
Codex 팀이 Sottiaux의 지휘 아래 에이전트를 다시 만드는 동안, Michelle Pokrass는 GPT-5가 실제 프로그래밍을 더 잘하도록 만드는 작업을 하고 있었습니다.
GPT-4.1 연구를 이끌었던 Pokrass는 사후 학습(post-training)을 맡았습니다. 사후 학습은 이미 학습된 모델의 행동을 다듬어 실제 프로그래밍 작업을 감당할 수 있게 만드는 과정입니다. Pokrass는 더 나은 대화형 코딩을 요청한 고객들에게 초점을 맞췄습니다.
코딩 모델은 SAT 만점을 받았지만 직장에 다녀 본 적은 없는 학생과 같을 수 있습니다. OpenAI의 모델은 코딩 대회에서는 뛰어난 성적을 냈지만, 그 결과가 일상적인 엔지니어링 작업으로 이어지지는 않았습니다. "모델은 지저분한 코드베이스를 본 적도, 프로그래머가 작업 도중에 끼어드는 상황을 겪어 본 적도 없었어요." Brockman이 말했습니다.
책으로만 배운 모델에게 실전 경험을 주기 위해, Pokrass와 팀은 프로그래머들 옆에 앉아 그들이 일하는 모습을 지켜보며 모델이 어디서 무너지는지 확인했고, 그 실패를 반복 가능한 학습 과제로 바꿨습니다.
그렇게 해서 OpenAI는 2025년 8월 저를 Mission Bay의 그 회의실로 이끈 모델, 그리고 그 순간에 이르렀습니다.
Codex 팀이 보낸 격동의 여름을 안에서 들여다보니, 그날 밤 제가 GPT-5에서 느꼈던 조심스러움이 이해가 됐습니다. Codex Cloud로 곧장 완전한 자율로 도약하려다 데었고, 더 나은 대화형 협업자를 원하는 고객들의 요청을 따랐기에, OpenAI는 사람 프로그래머와 함께 한 단계씩 일하는 데 뛰어난 모델을 만들었습니다. 그 모델은 지저분한 코드베이스의 조각들이 어떻게 맞물리는지 이해하고, 자기 계획을 설명하고, 버그를 조사하고, 선을 넘기 전에 멈춰서 물어볼 수 있었습니다.
Every에 있는 저희가 보기에, Codex CLI 속 GPT-5는 Claude Code와 비교하면 여전히 뒤처져 있었습니다. Kieran은 저희 출시 당일 Vibe Check에 이렇게 썼습니다. "GPT-5는 Sonnet 3.5 킬러이지, 미래로 도약한 모델은 아니다." 하지만 당시 대다수 소프트웨어 엔지니어가 원한 것은 신중한 협업자였습니다. 코드를 한 줄 한 줄 손으로 써 온 프로그래머들은 프로덕션 코드를 자율 에이전트에게 맡긴다는 생각을 여전히 코웃음 치며 넘기곤 했습니다.
"저는 제 코드의 운전대를 AI에게 넘기지 않아요." Ruby on Rails를 만들었고 엔지니어링 커뮤니티에서 영향력이 큰 David Heinemeier Hansson은 GPT-5가 출시될 무렵 이렇게 말했습니다. "프로그래머의 즐거움, 프로그래머로서 제 즐거움은 코드를 직접 타이핑하는 데 있어요." 게다가 에이전트가 운전대를 잡으면 어떤지 이렇게 말했습니다. "손끝에서 실력이 빠져나가는 게 말 그대로 느껴져요."
Codex 팀이 8월 말 GPT-5 출시에 이어 VS Code와 Cursor용 확장 프로그램을 내놓자, 이런 개발자들이 몰려들었습니다. 그들의 열광은 OpenAI가 확장 프로그램을 계속 개선할 이유가 되기에 충분했습니다. 새로운 사용자와 기능 요청이 생길 때마다 팀은 프로그래머가 한 단계씩 작업하도록 돕는 쪽으로 끌려갔고, 작업 전체를 맡을 수 있는 에이전트를 만드는 일에서는 멀어졌습니다.
하지만 Embiricos에게는 같은 출시가 팀이 더 큰 야망을 좇을 수 있다는 뜻이기도 했습니다. 몇 달 동안 황야를 헤맨 끝에, 다시 만든 로컬 에이전트에 마침내 그것을 몰 수 있는 모델이 생긴 것입니다.
그는 개편한 CLI와 함께 GPT-5를 내놓고 나서 어떻게 됐는지 이렇게 말했습니다. "스스로 굴러가는 플라이휠이 생긴 거죠."
그는 그때 이렇게 생각했던 것을 기억합니다. "드디어 이제 싸워 볼 수 있겠다."
생각 중...
CLI와 에디터 확장 프로그램이 드디어 뜨고 있다…고객들은 사이드바를 좋아하고, 터미널에서는 Claude Code가 넘어야 할 상대다…
에디터 확장 프로그램에 힘을 더 싣고, 터미널에서는 따라잡자…
Tibo가 중단함
데스크톱에 건 승부
Codex CLI와 VS Code 확장 프로그램이 폭발적인 인기를 얻고 있었으니, 논리적으로는 두 가지 모두에 계속 투자하는 것이 맞는 선택이었을 것입니다.
그런데 Codex 팀은 뜻밖의 일을 했습니다.
"CLI는 계속 유지하되, 당장 가장 크게 투자할 다음 대상은 네이티브 데스크톱 앱이어야 한다고 결정했어요." Sottiaux가 말했습니다.
OpenAI 안에서 그는 모델이 더 긴 작업을 끝내고, 코드베이스 밖의 정보까지 끌어다 쓰는 모습을 볼 수 있었습니다. 음성과 이미지도 곧 들어올 예정이었습니다. 머지않아 사람들은 여러 에이전트를 동시에 돌리며 하루 종일 그 에이전트들과 지내게 될 것이었습니다. "하루 종일 그 안에서 지낼 거라면 아주 풍부한 인터페이스여야 해요." 그가 말했습니다. 텍스트, 이미지, 음성, 영상으로 소통하는 에이전트 대여섯 개를 1970년대에 만들어진 텍스트 전용 창 안에서 한꺼번에 다루려는 건, 그가 보기에 우스꽝스러운 일이었습니다.
Embiricos에게도 로컬 데스크톱 앱은 Codex Cloud에서 놓쳤던 워크플로로 가는 길을 가리켰습니다. Codex Cloud에서는 사용자가 작업 도중에 에이전트에게 끼어들 수 없었습니다. 그는 자기 컴퓨터에 있는 앱이라면 사람들이 처음에는 에이전트와 긴밀하게 함께 일하다가, 새 팀원을 적응시킬 때처럼 어떤 일을 에이전트에게 맡겨도 되는지 차차 알게 될 거라고 생각했습니다. 같은 인터페이스로 언젠가는 Codex를 개발자 너머, 터미널을 한 번도 열어 보지 않을 사람들에게까지 데려갈 수 있을 것이었습니다.
앱을 설계하고 만드는 일을 돕도록, Sottiaux는 디자이너이자 프로그래머이며 스타트업 창업자 출신인 Andrew Ambrosino를 데려왔습니다.
Ambrosino를 보면 드라마 The Office에서 B.J. Novak이 연기한 인물이 떠오릅니다. 검은 머리, 짙은 눈썹, 입술을 꼭 다문 채 짓는 작은 미소가 그렇습니다. 직접 만나도, 온라인에서 봐도, 그는 늘 속으로 혼자 재미있어하는 사람 같은 인상을 줍니다. 다른 누군가가 그 농담에 함께 웃어 주느냐도 고려하긴 하지만, 대개는 다소 부차적인 문제로 보입니다.
인공지능의 미래에 대한 통찰을 얻으려고 그를 팔로우하는 사람이라면, 피드를 내리다가 "ai"라는 단어 하나로만 된 게시물에 좋아요가 617개 달린 것을 보게 될지도 모릅니다. 또 다른 게시물은 알 수 없게도 "tibo"입니다(좋아요 1,000개 이상).
Ambrosino가 앱을 만드는 소규모 그룹에 합류했을 때, 팀은 데스크톱 앱을 만들고 싶다는 것은 알았지만 그 앱이 어떤 모습일지는 몰랐습니다. 팀이 아는 것이라고는 자신들이 직접 쓸 무언가를 만들고 싶다는 것뿐이었습니다.
Ambrosino에 따르면, 팀의 첫 번째 임무는 이 앱을 자신들의 일상 업무용 주 도구로 만드는 것이었습니다. "매일 쓰는 주력 도구가 될 수 있으면서도, IDE보다는 가벼운 [무언가]를 원한다는 건 알고 있었어요." 그가 말했습니다.
Claude Code가 인기를 끌면서, 몇몇 앱이 터미널 밖에서 코딩 에이전트가 머물 곳이 어떤 모습일 수 있는지 실험하기 시작했습니다. 코딩 에이전트를 실행하는 Mac 앱인 Conductor에는 작업 목록이 있는 사이드바가 있었고, 작업마다 자체 에이전트와 채팅이 있어서 지시를 내리고 작업을 지켜볼 수 있었습니다. ChatGPT도 또 하나의 참고 대상이었습니다. 옆에는 대화 목록이, 가운데에는 대화 스레드 하나가 있는 구조였습니다. Ambrosino는 디자인 과정을 두고 Codex 앱이 "VS Code보다는 채팅에서 더 많은 영감을 얻었다"고 말했습니다. 그 무렵 Anthropic에도 Claude 데스크톱 앱이 있었습니다.
팀은 빠르게 움직이며 기본적인 질문에 답해 나갔습니다. 사용자가 자기 작업을 어떻게 추적할지(작업마다 에이전트와의 대화가 따로 있음), 사이드바를 어떻게 구성할지(대화를 프로젝트별로 묶음), 기본 인터페이스를 어떻게 배치할지(선택한 대화 옆에 작업 사이드바를 둠) 같은 질문이었습니다.
그다음에는 더 어려운 질문이 기다리고 있었습니다. 에이전트가 무언가를 잘못했을 때, Codex 안에서 사용자가 직접 손으로 코드를 고칠 수 있어야 할까요? 팀은 위험한 답을 골랐습니다. 코드 에디터를 내장하지 않기로 한 것입니다. 코드를 조금이라도 바꾸고 싶으면 반드시 에이전트에게 요청해야 했습니다.
"일부러 [코드 에디터와는] 다른 무언가가 되게 하고 싶었어요." Ambrosino가 말했습니다. 개발자가 앱 안에서 코드를 타이핑할 수 있게 하면, 개발자들은 실행 취소, 검색, 키보드 단축키처럼 에디터가 해 주던 다른 모든 것도 기대하게 되고, 그러면 Codex에 무엇이 없는지 눈에 띄게 됩니다. 그런 기대를 뛰어넘는 건 고사하고 충족하기만 해도, 네 명짜리 팀에게는 엄청난 노력이 필요했을 것입니다.
형편없는 코드 에디터가 되어서는 Codex가 이길 수 없었습니다. 에이전트와 함께 코딩하는 경험이 아주 좋아서 개발자들이 에디터를 아쉬워하지 않을 정도가 되어야 했습니다.
딱 한 가지 문제는, 팀이 여전히 VS Code를 대체할 도구를 VS Code로 만들고 있었다는 것입니다.
"매일 Alexander가 들어와서는 이랬어요. '한 사람씩 돌아가면서 말해 봐요. 이 앱을 주력으로 쓰고 있어요? 이 앱을 주력으로 쓰고 있어요?'" Ambrosino가 말했습니다.
처음에는 대답이 전부 "아니요"였습니다. 누구도 Codex를 주력 코딩 도구로 쓰지 않았습니다. 코드 에디터가 없으니 사소한 수정 하나에도 에이전트와 대화를 나눠야 했습니다. 개발자 경험 분야에서 일하는 Dominik Kundel은 초기 Slack 메시지에, 문장 하나를 바꾸려고 "Codex에 프롬프트를 써야 하는 게 번거롭게 느껴진다"고 썼습니다.
Ambrosino조차 의문을 품었습니다. 그는 11월에 팀에 이렇게 썼습니다. "'파일 편집 없음'이 출시 범위 중에서 제가 가장 회의적인 부분인 것 같아요."
바깥 시장 상황을 보면, 코드 에디터를 빼기로 한 결정은 훨씬 더 위험해 보였습니다. 2025년 11월, Google은 VS Code를 기반으로 만든 또 다른 코딩 도구 Antigravity를 출시했습니다. AI 에이전트와 완전한 에디터를 결합한 도구였습니다.
"그냥 서로 얼굴만 쳐다봤죠." Ambrosino가 떠올렸습니다. "VS Code를 포크하지 않은 게 큰 실수였나? 이 문제로 정말 마음이 복잡했고, 팀 안에서도 의견이 갈렸던 것 같아요."
앱을 구동하는 모델도 문제였습니다. OpenAI는 9월에 Codex 전용 모델 라인을 출시했지만, 11월이 되어서도 팀이 만들던 데스크톱 제품에 쓰기에는 충분히 좋지 않았습니다. Ambrosino는 기능을 모두 갖춘 앱이라 해도 마찬가지였을 거라며 이렇게 말했습니다. "그 시점 모델 품질로는 출시할 수 없었을 거예요."
그 후 몇 주 동안 상황이 바뀌기 시작했습니다. 11월 19일, OpenAI는 한 번에 몇 시간씩 코딩할 수 있는 GPT-5.1 Codex Max를 출시했습니다. 12월 18일에는 GPT-5.2 Codex가 뒤를 이었고, 대규모 코드베이스 전반에 걸쳐 변경하는 능력이 더 좋아졌습니다.
Glaese는 Codex 팀의 나머지 사람들과 직접 협력해, 개발자 피드백이 모델 개선으로 이어지는 피드백 루프를 더 짧게 만들었습니다. 결정적으로, 팀은 인기 벤치마크에서 모델 점수만 올리는 대신 Codex를 쓰는 사람들에게 Codex가 더 잘 맞도록 만드는 데 집중했습니다. 그리고 Codex 모델 라인이 메인 ChatGPT 모델과 분리되어 있었기 때문에, 그런 변경이 ChatGPT를 쓰는 8억 명에게 어떤 영향을 줄지 걱정하지 않고 더 빠르게 움직일 수 있었습니다.
12월이 되자 팀원 중 더 많은 사람이 코드 에디터 대신 Codex 앱을 쓰고 있었습니다. Kundel은 Slack에 이렇게 썼습니다. "원래는 코드 에디터가 너무 아쉬웠다. 이제는 변경 대부분을 인라인 코멘트만 남기면 끝이고, 엄청 빠르다." Ambrosino는 여전히 모델을 이끌어 줘야 했지만, 더는 모델이 짠 코드를 손으로 고칠 필요가 없다는 것을 알게 되었습니다. Glaese도 내부 분위기가 바뀌었다는 것을 알아차렸습니다. "5.2가 전환점이었어요. '와, 이게 저를 위해 할 수 있는 일이 정말 기대된다' 싶었죠." Glaese가 말했습니다.
업계 전체로 보면 연휴가 변곡점이 되었습니다. 개발자들은 크리스마스 연휴 동안 Anthropic의 Opus 4.5와 OpenAI의 GPT-5.2로 코드 한 줄 건드리지 않고 앱 전체를 처음부터 끝까지 만들었습니다.
1월 초에는 팀 전체가 Codex 앱을 쓰고 있었습니다. 이제 OpenAI의 나머지 사람들도 이 앱을 쓸지 알아봐야 했습니다. Ambrosino는 그렇지 않다면 "원점으로 돌아가야" 했다고 말했습니다.
2월이 되자 Codex 데스크톱 앱은 엔지니어링 팀과 연구 팀에서 널리 쓰이고 있었습니다. OpenAI 연구자 Noam Brown은 Codex 앱으로 "완전히 갈아탔다"고 말했고, 터미널과 Emacs 에디터의 열성 사용자인 Brockman도 마찬가지였습니다. Brockman은 예전 워크플로로 돌아가는 것이 "과거로 돌아가는 느낌"이었다고 말했습니다. Altman은 나중에 Codex 앱을 "저희가 만든 내부 제품 중 가장 사랑받는 제품"이라고 표현했습니다.
Codex 팀은 OpenAI 내부 개발자들이 사랑하는 무언가를 만들었습니다. 하지만 Codex Cloud도 OpenAI 안에서는 환영받았다가, 출시하자마자 실패했습니다. 이번에는 달랐을까요?
생각 중...
여기서는 많은 사람이 쓰고 있다…
하지만 전에도 이걸 성공으로 착각한 적이 있다…
이번에는 사용자가 이미 일하는 곳에서 돌아간다…
밖에서 시험해 볼 때다…
Codex 앱
Codex macOS 데스크톱 앱은 2026년 2월 2일 일반에 공개되었습니다. 코드 에디터보다는 채팅 앱에 더 가까워 보였습니다. 사이드바에는 진행 중인 작업과 지난 작업이 있었고, 작업 하나를 누르면 에이전트가 한 일이 보이고 추가 지시를 보낼 수 있었습니다.
한 에이전트에게는 버그를 고치라고 하고, 다른 에이전트에게는 기능을 만들라고 보낸 뒤, 그 사이를 오가며 질문에 답하거나 변경 사항을 검토할 수 있었습니다. 에이전트마다 자기 코드 사본에서 작업할 수 있어서 서로의 작업을 덮어쓰지 않았습니다. 가까이에서 지켜보며 방향을 잡아 줄 수도 있고, 여러 작업을 돌려 놓고 에이전트가 필요로 할 때 돌아올 수도 있었습니다.
당시로서는 이 중 어느 것도 특별히 획기적이지 않았습니다. 예를 들어 Claude 데스크톱 앱은 이미 몇 달 전부터 기술직과 비기술직 사용자 모두가 같은 일을 할 수 있게 해 주고 있었습니다. 하지만 Claude 데스크톱 앱은 Chat에서 시작해 Code를 더하고, 그다음 Cowork를 더하는 식으로 한 단계씩 만들어졌고, 그 탓에 인터페이스가 헷갈리고 이것저것 덧붙인 것처럼 느껴졌습니다. 어떤 작업에 어떤 탭을 써야 하는지, 탭마다 어떤 기능이나 권한을 쓸 수 있는지 알기 어려웠습니다.
Codex 앱에는 이런 흉터가 하나도 없었습니다. 며칠 뒤 출시된 새 Codex 모델 GPT-5.3 Codex와 함께 처음 써 봤을 때, Codex 앱은 빠르고, 단순하고, 철저하게 에이전트 네이티브였습니다. 제품의 모든 디테일이 맞아떨어질 때 받는 그 매끄러운 느낌이 있었습니다. 초기에 코드 에디터를 빼자고 고집했던 만큼, 팀은 사용자가 앱 안에서 할 수 있는 거의 모든 일을 Codex 에이전트도 할 수 있도록 신경 썼습니다. 그래서 예를 들어 새 도구를 연결하려고 설정을 뒤질 필요가 없었습니다. 그냥 에이전트에게 부탁하면 됐습니다.
GPT-5.3 Codex는 OpenAI 모델 역량에서도 전환점이었습니다. Glaese에 따르면, Codex 라인에서 프로그래밍에 특화된 학습을 넘어 다른 영역으로 뻗어 나가기 시작한 첫 모델이었습니다. 이름은 여전히 Codex였고, Glaese도 이 모델이 모든 면에서 더 낫다고 주장하지는 않았습니다. 하지만 팀은 코딩 에이전트가 온갖 지식 노동에 쓸모 있으려면 무엇을 더 알아야 하는지 묻기 시작했습니다.
제 워크플로에는 곧바로 영향이 있었습니다. 거의 Claude만 쓰던 저는 업무의 많은 부분에 Codex를 쓰는 쪽으로 바꿨습니다. 제가 만들고 있던 문서 편집기 Proof에서는 Codex가 제가 별로 개입하지 않아도 복잡한 버그를 스스로 고치는 것을 지켜봤습니다. 곧 저는 어려운 문제를 Codex에게 맡겨 밤새 돌려 두게 되었고, 특히 까다로운 작업을 만날 때마다 Codex부터 찾았습니다.
3월 초 GPT-5.4가 나오면서 Codex는 확실히 제 주력 도구가 되었습니다. 여전히 전문가 수준의 코더였지만, 이제는 자기 생각을 명확하게 설명했고 제가 원하는 것을 더 잘 이해했습니다. 그리고 Codex 앱의 인터페이스가 깔끔하고 빨랐기 때문에, 저는 모든 업무를 그 안에서 하기 시작했습니다.
그 무렵 Every의 많은 사람도 OpenAI의 도구와 모델을 매일 쓰고 있었습니다. Claude가 압도적으로 우세했던 불과 몇 달 전과 비교하면 완전히 뒤집힌 상황이었습니다. 저희가 GPT-5.4 Vibe Check에 쓴 것처럼, OpenAI가 돌아온 것입니다.
Every 밖에서도 같은 일이 훨씬 넓게 벌어지고 있었습니다. 3월 19일 OpenAI는 Codex의 주간 사용자가 200만 명을 넘었고, 전체 사용량은 연초보다 5배 늘었다고 밝혔습니다. 4월에는 앱 안에 브라우저를 추가해, 에이전트가 정보를 찾아보고 실제 웹 페이지에서 자기 작업을 확인할 수 있게 했습니다. 에이전트는 다른 Mac 앱을 넘나들며 일할 수도 있었고, 문서, 슬라이드, 스프레드시트의 미리 보기를 보여 줄 수도 있었습니다. 코드를 한 번도 써 본 적 없는 사람도 프레젠테이션이나 예산 보고서를 요청하고, 앱을 떠나지 않고 결과를 볼 수 있었습니다.
6월에는 Codex의 주간 사용자가 500만 명을 넘었고, 그중 다섯 명에 한 명꼴로 지식 노동자였습니다. 7월 9일, OpenAI는 Codex 데스크톱 앱을 채팅 기능을 담은 새 ChatGPT 데스크톱 앱으로 바꿨습니다. 내부적으로 새 ChatGPT는 지금도 Mac에 자기 이름을 com.openai.codex라고 알립니다.
Codex Cloud는 ChatGPT 안의 탭 하나로 출시되었습니다. 이제는 ChatGPT가 Codex 위에서 돌아갑니다.
Ed Bayes는 통합 발표가 있었던 전체 회의에서 걸어 나오며, 팀이 얼마나 먼 길을 왔는지 생각했던 것을 기억합니다. "구석에 있던 몇 명"으로 시작한 일이 이제는 "ChatGPT의 미래"가 되어 있었습니다.
"이건 미국 기업사의 한 페이지 같은 거예요." 그가 말했습니다.
GPT-5 출시로부터 10개월 뒤, 저는 다시 회의실에서 Alexander Embiricos와 마주 앉았습니다.
"그냥 완전히 솔직하게 말할게요, 괜찮죠?" Embiricos가 물었습니다.
"그렇게 해 주세요." 제가 말했습니다.
6월 초였습니다. 지금은 한창 주목받는 Codex가 ChatGPT와 합쳐지기 한 달 전이었고, 저희는 맨해튼 다운타운에 있는 OpenAI 사무실에 앉아 있었습니다. 그는 소매를 걷어 올린 회색 집업을 입고 있었습니다. 그의 역할은 얼마 전 Codex 에이전트의 제품 리드에서 OpenAI의 엔터프라이즈 제품 총괄로 바뀌었습니다. 그의 뒤에는 화이트보드가 있었습니다.
저는 그의 팀이 Codex Cloud의 실패를 딛고 어떻게 훗날 ChatGPT의 토대가 될 제품을 만들어 냈는지, 그리고 제가 Mission Bay에서 걱정했던 페어 프로그래밍(pair programming)의 함정에 어떻게 빠지지 않았는지 Embiricos에게 물어보러 왔습니다. 대부분의 팀은 잘되고 있는 것을 바탕으로 계속 쌓아 갑니다. Codex 팀은 그렇게 하지 않았습니다. 무엇 덕분에 그들은 계속 앞으로 나아갈 수 있었을까요?
Embiricos는 검은 마커를 집어 들고 화이트보드에 Codex가 성장해 온 과정을 그렸습니다. 그는 먼저 Codex Cloud를 나타내는 짧은 상승 곡선을 그렸습니다. 곡선은 보기 좋게 치솟았지만 금세 평평해졌습니다.
이어서 그는 GPT-5 이후의 CLI를 나타내는 더 가파르고 큰 곡선을 그렸고, 에디터 확장 프로그램을 나타내는 그보다 더 높은 곡선을 그렸습니다. 마지막은 5.3 Codex와 데스크톱 앱이었는데, 다른 곡선들이 왜소해 보일 만큼 큰 곡선이었습니다. 처음 그은 곡선은 이제 보드 아래쪽에 난 긁힌 자국처럼 보였습니다.
그가 화이트보드에 그린 곡선들은 Christensen의 혁신기업의 딜레마(The Innovator’s Dilemma)에 나오는 도표처럼 보였습니다.
Christensen은 하드 드라이브와 프로세서가 꾸준히 발전하면서 컴퓨터의 주류가 메인프레임에서 미니컴퓨터로, 데스크톱 PC와 노트북으로, 마침내 휴대폰으로 옮겨 간 과정을 추적한 것으로 유명합니다. 기반 하드웨어가 한 단계 도약할 때마다 더 단순한 폼 팩터가 가능해졌고, 그 폼 팩터는 기술에 덜 익숙한 더 큰 시장을 열어 이전 세대를 앞질렀습니다.
전통적인 컴퓨팅 업계에서 잇따라 등장한 새 회사들을 거치며 반세기에 걸쳐 펼쳐진 패턴이, OpenAI 안에서는 단 몇 명으로 이루어진 팀을 통해 10개월 만에 축소판으로 되풀이된 것입니다. 모델이 쉼 없이 도약하면서 모델을 중심으로 만든 인터페이스는 번번이 모델을 따라가지 못했고, 그래서 Codex 팀은 코드 에디터의 사이드바에서 터미널로, 다시 코드 에디터를 아예 걷어 낸 가벼운 데스크톱 앱으로 옮겨 가야 했습니다.
Christensen의 책에서는 성공한 곡선을 타고 있는 팀이 다음 곡선에 올라타는 경우가 거의 없습니다. 기존 제품의 성공이 그 뒤에 오는 모든 것의 숨통을 조이기 때문입니다. Codex 팀이 그런 운명을 피할 수 있었던 것은, OpenAI 경영진이 스타트업 세계에서 바로 그 함정을 연구하며 성장한 사람들이었기 때문이기도 했습니다. OpenAI는 여러 베팅을 동시에 진행하는 포트폴리오처럼 움직이도록 조직을 짜 두었고, Codex 팀은 ChatGPT의 거대한 규모와 사용자층이 주는 제약에서 벗어나 자기 제품과 모델 라인을 거듭 다듬어 갈 여지를 얻었습니다.
AI로 AI를 만들게 되면서 제품 개발의 물리 법칙도 달라졌습니다. 전통적인 회사에서 새 제품을 시작하려면 예산과 엔지니어를 따내기 위해 몇 달 동안 회의를 거쳐야 하고, 그런 논쟁에서는 한창 잘나가는 기존 제품이 거의 언제나 이깁니다. OpenAI에서는 팀이 Codex로 Codex를 만들고 있었기 때문에, 몇 사람만으로도 몇 주 만에 새로운 사용 환경을 만들어 낼 수 있었습니다.
"이제는 사람들을 설득할 때 말을 훨씬 덜 해도 돼요." Sottiaux가 제게 했던 말입니다.
어떤 아이디어를 화이트보드에서 꺼내 사람들이 직접 써 보게 할 수 있을까요?
화이트보드를 바라보는 Embiricos에게는 그려야 할 새 곡선이 하나 더 남아 있었습니다. 이제 수백만 명이 자기 컴퓨터에서 에이전트를 믿고 쓰게 되었으니, 다음 단계는 지난해 봄에 실패했던 비전, 즉 사용자가 자리를 뜬 뒤에도 한참 동안 일을 계속하는 에이전트로 돌아가는 것이었습니다.
"저희는 비동기 방식으로 넘어갈 거예요." 그가 말했습니다. "그러면 다시 클라우드로 끌어올려야 한다는 뜻이죠."
이번에는 회의 테이블 위에 덮개가 굳게 닫힌 채 놓여 있는 그의 노트북에 눈길이 가지 않을 수 없었습니다.