서진호

30 분 소요

Codex 앰버서버의 한서우님이 링크드인에 공유해 준 댄 시퍼(Dan Shipper)의 Codex는 어떻게 탄생했나?(How Codex Happened) 컬럼을 더 많은 한국 분들이 읽었으면 좋겠다는 생각에 그의 글을 번역했다. 참고로 존 댄 시퍼는 에브리(Every)의 공동 창업자이자 CEO이다. 주로 에브리에서 AI 관련 칼럼 ‘체인 오브 소트(Chain of Thought)’를 쓰고, ‘에브리 팟캐스트’를 공동 진행한다. 이 글에서는 외부 취재자로서 Codex 개발에 참여한 오픈AI 관계자 여섯 명을 인터뷰하고, 직접 제품을 사용한 경험을 바탕으로 Codex의 개발 과정을 설명한다.

전체 글이 상당히 길어서 들어 가기 전에 바쁘신 분들을 위해 이 컬럼의 핵심을 다음과 정리한다.

  • Codex는 처음부터 완성된 계획에 따라 만들어진 제품이 아니라, 실패와 방향 전환을 거치며 발전했다.
  • 초기 Codex 클라우드는 내부에서는 좋은 반응을 얻었지만, 외부에서는 복잡한 환경 설정과 작업 중 개입의 어려움, 부족한 모델 역량 때문에 안착하지 못했다.
  • 팀은 개발자의 컴퓨터에서 실행하는 방식으로 전환하고, 여러 인터페이스에서 공통으로 사용할 에이전트 기반을 다시 만들었다.
  • 터미널과 편집기 확장 기능이 성장하는 상황에서도, 여러 에이전트에게 작업을 맡기고 관리할 데스크톱 앱에 투자했다.
  • 코드 편집기를 넣지 않는 선택은 내부에서도 논쟁적이었다. 이후 모델 성능이 개선되면서 직접 코드를 고치기보다 에이전트에 지시하는 방식이 실용성을 얻었다.
  • 연구자와 제품팀의 긴밀한 협업, 실제 업무에서 얻은 피드백, 독립적인 모델 개발이 개선 속도를 높였다.
  • 저자는 Codex의 성장을 모델 역량의 변화에 맞춰 제품 형태를 바꾼 사례로 해석한다. 마지막에는 사용자가 자리를 떠나도 계속 일하는 클라우드 에이전트라는 초기 비전으로 다시 돌아간다.

오픈AI가 천명을 잃을지도 모르겠다고 처음 생각한 순간을 정확히 기억한다. chatGPT가 처음 인기를 얻은 뒤 AI 코딩 분야에서 쌓아 온 도저히 따라잡을 수 없을 것 같던 우위를 잃을지도 모른다는 생각이었다. 2025년 여름, GPT-5 출시 전날 밤이었다. 나는 오픈AI의 미션베이 사무실에 있었다. 건물에는 묘한 활기가 감돌았다. 천장 조명은 무대 조명처럼 밝게 빛났고, 따뜻한 적갈색과 갈색으로 꾸며진 복도를 오가는 사람들의 걸음은 평소보다 조금 빨라 보였다. 중력마저 더 강하게 느껴졌다. 다음 날 있을 거대한 출시 행사가 세상 나머지 전부를 자기 궤도 안으로 끌어당긴 것 같았다.

그래서 내가 하러 온 이야기를 꺼내기가 조금 난처했다. 내가 운영하는 회사 에브리는 새로운 AI 모델을 실제 업무에 써 보고, 무엇을 할 수 있고 무엇을 할 수 없는지 설명하는 곳으로 이름을 알리기 시작했다. 오픈AI는 출시 약 한 달 전에 우리에게 GPT-5를 쓸 수 있게 해 주었다. 모델의 강점과 약점을 파악하는 데 도움을 받고, 출시 당일 우리가 상세 리뷰인 ‘바이브 체크’를 공개할 수 있도록 하기 위해서였다.

1. Codex를 만든 사람들에게 배우기

이 기사를 위해 그렉 브록먼, 알렉산더 엠비리코스(Alexander Embiricos), 티보라는 이름으로 불리는 티보 소티오(Thibault Sottiaux), 아멜리아 글레이즈, 앤드루 앰브로시노, 에드 베이스를 인터뷰했다. 이 여섯 사람은 리서치, 엔지니어링, 프로덕트, 디자인 분야에서 Codex를 만드는 데 참여했다. 각 인터뷰는 Codex가 어떻게 만들어졌는지 서로 다른 관점을 보여 준다. 여섯 명 인터뷰의 전문을 모두 읽어 볼 수 있다. 직접 읽거나 에이전트와 함께 살펴보면서 자신의 업무에 가져올 만한 아이디어를 찾아볼 수 있다.

우리 팀 열 명은 워크숍을 위해 뉴욕주 북부의 한 집에서 일주일을 보냈다. 긴 나무 탁자 하나에 둘러앉아 함께 먹고 일했고 큰 화면 앞 소파에 모여 오랫동안 기다려 온 모델을 시험했다. AI가 가장 빠르게 발전하고 있던 코딩 분야에서 써 보는 일이 특히 기대됐다. 일상적인 용도로는 마음에 들었지만 Codex에서 써 본 반응은 미지근했다.

오늘날 Codex는 오픈AI 부활의 중심에 있다. chatGPT를 안에서부터 집어삼켰고, 회사가 앞으로 만드는 모든 것의 토대가 된 제품이다. 하지만 그해 여름만 해도 AI 소프트웨어 엔지니어를 만들려는 작고 분주한 시도에 가까웠다. 몇 달 전 클라우드에서 출시한 버전은 제품과 시장의 접점을 찾지 못했고, 팀은 개발자 컴퓨터의 터미널과 코드 편집기에서 실행되는 새 버전으로 방향을 바꾸는 중이었다.

Codex에서 GPT-5는 빨랐고 똑똑해 보였다. 우리 팀에서도 기술력이 뛰어난 엔지니어인 나빈 나이두는 음성 받아쓰기 앱 모놀로그에서 며칠 동안 풀지 못했던 원인 불명의 멈춤 현상을 추적하는 데 GPT-5를 활용했다. 하지만 허용된 범위를 벗어나는 일을 지나치게 경계하는 것처럼, 너무 일찍 멈추는 듯한 모습도 보였다. 페어 프로그래머로 쓰도록 설계된 느낌이었다.

우리 팀은 이미 AI 모델과 한 단계씩 협업하는 방식을 넘어가고 있었다. 키어런 클라선(Kieran Klaassen)이 이끄는 몇몇 팀원은 앤트로픽의 터미널 에이전트인 Claude Code를 이용해 오퍼스 4에 작업 전체를 맡긴 뒤 자리를 떠나기 시작했다. 완성된 기능이 때로는 앱 전체가 돌아올 때까지 기다리는 방식이었다. 전속 작가 케이티 패럿은 엔지니어의 도움을 조금만 받고도 며칠 만에 자신만의 AI 콘텐츠 관리 시스템을 만들어 배포했다. 버그가 조금 있었지만, 예전 같았으면 만들 엄두도 내지 못했을 것이다.

Claude Code에서 돌아가는 오퍼스 4와 비교하면, Codex의 GPT-5는 틀 안에 갇힌 느낌이었다. 이런 시험 결과를 공유하기 위해 나는 오픈AI 사무실의 회의실에서 커뮤니케이션팀의 린지 매컬럼, Codex팀의 알렉산더 엠비리코스(Alexander Embiricos)와 만나게 됐다. 시장 분위기의 변화를 예민하게 포착하는 매컬럼이 이 자리를 마련한 것 같았다. 내가 왜 갑자기 이 새로운 작업 방식에 관해 쉬지 않고 떠드는지, 엠비리코스(Alexander Embiricos)에게 직접 설명하게 하려는 의도였을 것이다.

회의 탁자 맞은편에서 매컬럼은 노트북에 집중해 무언가를 입력하고 있었다. 내 옆에 앉은 엠비리코스(Alexander Embiricos)는 이야기를 하면서도 코딩을 하고 있었는데, 나는 그것을 좋은 신호로 받아들였다. 그는 GPT-5 출시에 맞출 기능 하나를 급히 마무리하고 있었다. 에이전트가 샌드박스 밖의 파일에 접근하거나 명령을 실행해야 할 때, 잠시 멈추고 사람에게 허락을 구할 수 있게 하는 기능이었다.

“Claude Code는 그냥 마음껏 하게 두면 됩니다.” 내가 엠비리코스(Alexander Embiricos)에게 말했다. “GPT-5는 조금 소극적인 느낌이에요. 샌드박스에 발목이 잡혀 있고, 자기 능력을 쓰는 것조차 두려워하는 것처럼 보입니다.”

매컬럼의 키보드 소리가 느려졌다. 노트북에서 눈을 떼지 않은 채 이렇게 말했던 것으로 기억한다. “알렉산더에게 그 새로운 개발 작업 방식을 설명해 주세요.”

엠비리코스(Alexander Embiricos)가 의자를 돌려 나를 똑바로 바라봤다.

“이제 저희는 코드를 제대로 들여다보지도 않아요.” 나는 이렇게 말을 꺼냈다. 하지만 그 말을 하면서 얼굴이 붉어졌다. 다른 사람도 아니고 엠비리코스(Alexander Embiricos)에게 에이전트에 일을 위임하는 방식을 설명하고 있다니 우스웠다. 자율 코딩 에이전트를 만드는 것이 바로 그의 일이었다. 게다가 당시에는 우리 개발 방식이 이 작은 팀을 넘어 다른 곳에서도 통할지 확신하지 못했다.

슬랙 알림이 엠비리코스(Alexander Embiricos)의 화면을 밝히며 갑자기 조용해진 회의실의 정적을 깼다. 그는 컴퓨터 소리를 끄고 노트북 덮개를 4분의 3쯤 닫았다. Codex 에이전트가 계속 생각할 수 있을 만큼만 열어 둔 것이었다.

그날 밤 미션베이(Mission Bay, 샌프란시스코에서 있고 OpenAI 본사가 있는 지역)를 떠나면서, 오픈AI가 사라져 가는 작업 방식에 완벽하게 맞는 도구를 만들고 있는 것은 아닐까 생각했다. 클라우드 에이전트의 실패로 한 번 데인 회사가 chatGPT가 프로그래머를 단계별로 돕는 코드 편집기로 물러나는 것처럼 보였다. 반면 Claude Code는 작업 전체를 맡기고 자리를 떠나는 사람들 사이에서 인기를 얻고 있었다.

편집기에 머물러야 할 이유도 충분했다. GPT-5 출시 후 Codex팀은 마이크로소프트의 비주얼 스튜디오 코드(VS Code)와 커서(Cursor) 같은 코드 편집기의 사이드바에 Codex를 넣는 확장 기능을 출시했다. VS Code는 프로그래머가 코드를 작성하고 실행하고 디버깅하는 도구다. 지난 10월까지 사용량은 열 배 넘게 늘었고, 편집기 확장 기능은 빠르게 터미널을 제치고 Codex에서 가장 많이 쓰이는 인터페이스가 됐다.

대부분의 회사라면 그 사업에 더 집중했을 것이다. 하지만 엠비리코스(Alexander Embiricos)와 오픈AI 내부의 소수 엔지니어, 디자이너, 연구자들은 더 큰 뜻을 품고 있었다. 이후 몇 달 동안 Codex팀은 chatGPT에 쓰이는 모델과 별개로 코딩 전용 모델 계열을 학습시키고 빠르게 개선했다. 동시에 여러 에이전트를 한꺼번에 관리할 수 있는 데스크톱 앱을 만들었다. 2026년 6월에는 Codex의 주간 활성 사용자가 500만 명을 넘었고 프로그래밍을 넘어 다른 지식 업무로도 쓰임이 넓어지고 있었다.

2026년 7월에는 Codex가 주력 chatGPT 데스크톱 앱에 통합됐다. 팀을 이끌던 티보 소티오(Thibault Sottiaux)는 chatGPT, Codex, API를 포함한 오픈AI의 모든 핵심 제품과 플랫폼을 총괄하는 자리로 올라갔다. 현재 Codex와 chatGPT 포 워크를 합친 주간 활성 사용자는 4,000만 명이다. 1년도 채 안 되는 사이 Codex팀은 클라우드 제품 출시의 실패를 딛고 오픈AI 주력 제품의 토대가 됐다. 그 과정에서 회사 자체를 바꾸는 데도 기여했다.

이것은 Codex가 어떻게 만들어졌는지에 관한 이야기다.

2. 2026년에는 AI 모델에 복잡한 요청을 할 때마다 답변이 나타날 자리에 그 단어가 반짝이는 모습을 보게 된다. ‘생각 중.’

별 의미 없는 표시처럼 보일 수도 있다. 컴퓨터가 너무 바빠 응답하지 못한다는 뜻으로, 맥OS에서 돌아가는 비치볼이나 윈도 커서 옆의 파란 원을 단어 하나로 바꿔 놓은 것처럼 말이다. 하지만 여기서 ‘생각 중(thinking)’은 새로운 컴퓨팅 방식을 가리킨다. 이 방식이 없었다면 Codex도 탄생하지 못했을 것이다.

1세대 대규모 언어 모델은 생각을 밖으로 드러내며 처리했다. 내부 추론을 나타내는 반짝이는 상태 표시가 없었다. 대신 사용자에게 답변하는 과정 자체가 생각하는 과정이었다. 이메일을 써 달라고 하든 코드 한 줄을 써 달라고 하든, 미리 계획하거나 나중에 고칠 기회 없이 한 단어씩 답을 만들어 가야 했다.

그런 점에서 초기 대화 모델은 관객에게 소재를 받아 즉석에서 장면을 만들어 내는 즉흥극 배우와 비슷했다. 그 자리에서 내용을 지어내면서도 인상적인 결과를 보여 주곤 했지만, 의도치 않게 웃긴 결과를 내기도 했다. ‘strawberry’에 r이 두 개라고 우기고 그것을 증명하겠다며 철자를 하나씩 쓴 뒤 스스로 잘했다고 칭찬하는 식이었다.

초기 사용자들은 모델에게 답하기 전에 추론 과정을 단계별로 써 보라고 요청하면 더 나은 답을 얻는 경우가 많다는 사실을 알아차렸다. 초등학교 수학 선생님이 학생에게 할 법한 이 조언은 ‘사고 사슬 프롬프팅’이라고 불렸다.

사고 사슬(chain of thought) 프롬프팅은 2세대 AI 모델과 반짝이는 ‘생각 중(thinking)’ 인터페이스로 이어졌다. 오픈AI는 사용자가 매번 문제를 단계별로 풀라고 요청하게 하는 대신 그런 행동을 모델 자체에 학습시켰다. 추론 모델은 답변하기 전에 ‘추론 과정(reasoning trace)’이라고 부르는 일종의 연습장에서 작업한다. 문제에 여러 방향으로 접근하고, 막다른 길에서 되돌아오며, 성공할 가능성이 더 높은 경로를 고른다. 답이 정리된 뒤에야 응답한다.

오픈AI는 이런 종류의 첫 모델에 o1이라는 이름을 붙이고 2024년 9월에 미리보기 버전을 공개했다. 그전까지 발전은 주로 더 큰 모델을 더 오랫동안 학습시키는 데 달려 있었다. o1을 통해 오픈AI는 같은 모델이라도 어려운 문제에 더 많은 시간을 쓰면 답을 개선할 수 있다는 사실을 발견했다.

다른 어떤 분야보다 이 변화의 혜택을 크게 받을 일이 있었는 데 그것이 바로 프로그래밍이었다. 프로그래밍은 추론 모델에 특히 잘 맞는다. 모델이 코드를 수정하고 실행한 뒤, 몇 초 안에 수정이 제대로 작동했는지 확인하는 완결된 피드백 구조가 있기 때문이다. 사람이 확인해 주지 않아도 스스로 시험하고 수정할 수 있다. 이론적으로는 충분히 오랫동안 생각하게 두면 추론 모델이 어떤 프로그래밍 작업이든 혼자 해낼 수 있었다.

3. 여러 번의 시작

AI 프로그래머를 만드는 것은 오픈AI의 오랜 목표였다. 그래서 Codex에는 여러 번의 시작이 있었다. 2021년에 공개된 최초의 Codex는 공개 코드로 미세 조정한 GPT-3 버전이었다. 초기 깃허브 코파일럿을 구동한 모델이기도 했다. 3년 뒤, o1 미리보기가 추론 모델의 가능성을 보여 준 직후 몇 주 동안 경영진의 주문을 계기로 오픈AI의 여러 그룹이 서로 다른 방향에서 다시 그 꿈을 좇기 시작했다.

그중 하나는 2024년 말 엠비리코스(Alexander Embiricos)에게서 시작됐다.

“제가 처음으로 정말 강렬하게 ‘AGI가 느껴진다’고 생각한 순간은 누군가 터미널에 연결된 추론 모델을 돌리는 모습을 봤을 때였습니다.”[3] 그가 말했다. AI가 도구처럼 느껴지는 단계를 넘어, 사람처럼 생각하고 행동할 수 있는 기계로 느껴지는 순간을 말하는 것이었다. “지금은 별로 신기하지 않다는 걸 알지만요.” 그래도 모델이 파일을 읽고 명령을 실행하고 오류를 스스로 해결하는 모습은 “정말 끝내줬습니다.”

GPT-5 출시 전날 내가 만났던 제품 책임자 엠비리코스(Alexander Embiricos)는 오픈AI가 그와 동료들이 창업한 멀티를 인수하면서 그해 초 합류했다. 멀티는 프로그래머를 위한 다자간 화면 공유 도구였다. 오픈AI에서도 그는 이와 관련된 아이디어를 추진했다. 사람과 에이전트가 실제로 사용하는 앱 안에서 함께 일하게 하는 구상이었다. 처음에는 chatGPT 데스크톱 앱에서 이후에는 AI 브라우저인 아틀라스에서 그 비전을 좇았다. 하지만 당시 모델은 사용자 화면을 읽는 속도가 너무 느리고 서툴러서 실용적이지 못했다.

반면 터미널에서는 모델이 화면을 읽을 필요가 없었다. 텍스트와 코드를 직접 다루면 됐다. 초기 추론 모델이 터미널에서 작동하는 모습을 보고 엠비리코스(Alexander Embiricos)는 이것으로 실제 코딩 제품을 만들 수 있다고 확신했다. 아직 코딩이 그의 전담 업무는 아니었지만 곧바로 제품 구상을 시작했다. 제대로 작동하려면 사용자가 모델이 무엇을 하는지 30초마다, 아무리 길어도 1분마다 확인할 수 있어야 한다고 생각했다.

4. 라이브 행사: Codex가 글쓰기에 무엇을 해 줄 수 있는지 알아보기

댄 시퍼, 케이트 리, 잭 청이 Codex로 이 기사를 어떻게 취재하고 작성했는지 이야기한다. 10월 16일 금요일, 미국 동부 시간 낮 12시~오후 1시, 온라인으로 진행한다.다시 문제가 된 것은 속도였다. 당시 AI 코딩 제품 대부분은 VS Code를 중심으로 발전했다. 깃허브 코파일럿은 확장 기능으로 AI 자동 완성을 추가했다. 커서와 윈드서프(WindSurf)는 VS Code의 오픈소스 코드를 바탕으로 자체 편집기를 만들었고 프로그래머가 작업하는 화면 옆에 AI 채팅을 붙였다.

이 도구들은 짧고 긴밀한 피드백 주기에 의존했다. 코파일럿은 사용자가 입력 중인 줄을 완성했고 커서와 윈드서프는 몇 초 안에 질문에 답했다. 모델이 오랫동안 혼자 일하도록 요구하는 도구는 없었다. 모델이 그렇게 할 수 없었기 때문이다. 오픈AI의 초기 추론 모델은 정반대였다. 느렸고 생각하는 시간을 짧게 제한하면 성능도 떨어졌다.

응답을 받는 데 시간이 오래 걸린다는 약점을 장점으로 바꿀 수 있을까?

5. 빌더를 만드는 빌더들

한편 오픈AI의 다른 곳에서는 티보라는 이름으로 불리는 소티오가 추론 모델을 그 모델 자체를 만드는 일에 활용하려고 하고 있었다. 모델의 능력으로 연구자들이 다음 세대 모델을 만드는 일을 돕는 것이었다.

“2024년 12월쯤 코딩 에이전트에 관여하기 시작했습니다.”

티보가 말했다. 우리는 오픈AI 구내식당에 앉아 있었다. 윤기 나는 갈색 머리는 한쪽으로 넘어가 있었고, 가느다란 금속테 안경에는 오후 햇빛이 비쳤다. 코 위쪽만 보면 건축가 같았지만 아래쪽은 영락없는 프로그래머였다. 갈색 수염이 짧게 자라 있었고, ‘Research and Deployment Co’라고 적힌 짙은 갈색 후드티를 입은 채 손에는 페퍼로니 피자 한 조각을 들고 있었다.

그는 피자를 한입씩 먹는 사이 목표를 설명했다.

“인프라 코드를 작성하고 연구하는 속도를 높이는 것이었습니다.”

소티오는 경력의 상당 부분을 연구자용 인프라를 만드는 데 보냈다. 처음에는 딥마인드에서 이후에는 오픈AI에서 일했다. AI 연구자가 실험을 실행하고 평가하고 재현하고 배포할 때 사용하는 공통 코드인 연구 인프라는 훗날 Codex를 이끌게 될 사람의 출발점으로는 조금 의외로 보일 수 있다. 인프라라고 하면 서버나 해저 케이블을 떠올릴 것이다. 기술 세계의 배관 같은 존재다. 꼭 필요하지만 관이 새기 전까지는 눈에 들어오지 않는다.

하지만 AI 세계에서는 연구 인프라에서 중요한 일이 많이 벌어진다. 실험 하나에 걸리는 시간을 줄이면 더 많은 실험을 할 수 있고 더 좋은 모델을 더 빨리 얻을 수 있다.

“모델 계열을 따로 분리한 시점은 언제였나요?” 내가 물었다. “어떻게 결정했나요?” 나는 본격적인 이야기가 나오는 부분으로 빨리 넘어가고 싶었다. Codex가 특별했던 핵심에는 독자적인 모델 계열이 있다고 느꼈다. 소티오나 공동 창업자이자 사장인 그렉 브록먼, 혹은 CEO 샘 올트먼이 회의에서 Codex를 나머지 chatGPT와 분리하자는 선견지명 있는 결정을 내리는 장면을 상상했다. 팀이 빠르게 출시하고 회사 내부에서부터 판을 바꿀 자유를 준 결정 말이다.

“모델 계열을 분리하자는 결정은 없었습니다.” 소티오는 담담하게 말했다. 처음에는 “연구를 위한 탐색이자 우리 작업 속도를 높이려는 시도”였다고 했다.

소티오의 그룹은 대중에게 제공할 모델을 만드는 대신 오픈AI의 모든 코드가 모여 있는 단일 저장소인 모노레포를 대상으로 내부 코딩 에이전트를 학습시켰다. 에이전트는 오픈AI 연구자들이 새 모델을 만드는 시스템을 실행하고 개선하는 데 필요한 파이썬 코드를 작성했다. 연구자들이 매일 이 에이전트를 사용하면서 팀은 긴밀한 피드백을 얻었다.

“코딩에서 빠른 성능 향상이 나타나고 있었습니다.” 소티오가 말했다. 그의 팀은 자주 모델을 학습시켰다. 그때 사용한 기법은 회사 전체가 대중용 모델을 학습시키는 방식과 달랐고, 한동안은 두 방식을 함께 맞추기도 어려웠다.

소티오 역시 다른 AI 연구소 사람들처럼 이런 학습 기법에 관해서는 말을 아꼈다. 하지만 효과가 있다는 사실은 분명해졌다. 그의 그룹은 모델을 그 모델을 만들어 낸 연구 과정에 성공적으로 투입했고, 연구자들은 그 모델을 이용해 다음 세대를 만들고 있었다. 엔지니어들은 이것을 부트스트래핑(Bootstrapping)이라고 부른다. 연구자가 실험하는 일을 잘 돕는 모델을 만들면, 연구자는 그 모델로 더 강력한 모델을 만들 수 있다. 더 강력한 모델은 더 나은 실험을 돕고, 그것이 다시 더 좋은 모델로 이어진다. 이런 과정이 반복된다.

이 시도는 훗날 Codex가 되는 것의 절반을 제공했다. 새 모델을 만드는 인프라를 개선할 수 있는 에이전트였다. 회사의 다른 사람들도 쓸 수 있고, 결국 오픈AI 밖으로도 나갈 제품이 되려면 나머지 절반이 필요했다. 사람이 이런 에이전트와 어떻게 일해야 하는지에 관한 엠비리코스(Alexander Embiricos)의 구상이었다.

6. 수렴

탐색 다음에는 수렴(Convergence)이 온다. 2024년 말부터 2025년 초까지 오픈AI를 위에서 내려다보는 모습을 상상해 볼 수 있다. 코딩이 회사의 최우선 목표 중 하나가 된 뒤 소티오와 엠비리코스(Alexander Embiricos)를 비롯한 여러 팀이 같은 질문을 서로 다른 각도에서 다루기 시작했다.

브록먼에 따르면 아직 답을 찾지 못한 질문은 적절한 ‘제품 형태’였다. 에이전트는 개발자가 명령을 실행하는 터미널에 있어야 할까? 코드를 작성하는 편집기에 있어야 할까? 아니면 클라우드에서 자기 컴퓨터를 쓰며 일해야 할까? 어떤 길은 막다른 길이었지만 당시에는 누구도 어느 쪽인지 알지 못했다.

올트먼은 2025년 벤 톰슨과의 인터뷰에서 이렇게 말했다. “어떤 의미에서는 오픈AI가 여러 스타트업에 투자하는 셈입니다. 다만 모두 회사 내부에 있을 뿐이죠.” 내가 만난 일부 내부 관계자에게 이런 병렬 탐색 방식은 때때로 혼란스럽고 낭비처럼 느껴졌다. 오픈AI 안에서 세 번째로 좋은 에이전트 제품을 만든 팀에서 일하고 싶은 사람이 누가 있겠는가? 나 역시 회사에서 비슷한 전략을 운영해 봤기에 탐색할 여지를 주는 것과 완전히 엉망으로 만드는 것 사이의 경계가 얇다는 사실을 안다.

하지만 오픈AI를 지켜보면서, 내부에서 들려오는 불평에도 불구하고, 기술의 최전선이 계속 움직이는 상황에서는 이런 방식이 필요하다고 생각하게 됐다. AI에서는 모델 수준의 빠른 ‘존속적(sustaining)’ 발전이 새로운 종류의 앱을 가능하게 하며 이전 앱들을 계속 뒤흔든다. 고인이 된 하버드대 교수 클레이턴 크리스텐슨의 표현을 빌리자면 그렇다.

코드 한 줄을 완성할 수 있는 모델은 자동 완성 도구에 잘 맞는다. 30초 동안 생각할 수 있는 모델은 채팅 사이드바에서 질문에 답할 수 있다. 한 시간 동안 일할 수 있는 모델에는 전혀 다른 형태가 필요하다. 이전 모델을 바탕으로 성공적인 제품을 만들었다고 해서 다음에 무엇이 올지 아는 것은 아니다. 여러 팀이 서로 다른 아이디어를 시험하고 무엇이 유용한지 드러났을 때 그 결과를 합쳐야 한다.

2025년 초 오픈AI는 그렇게 할 준비가 됐다. “결국 ‘사이언티스트 어시스턴트(Scientist Assistant)’라는 다른 프로젝트와 힘을 합쳐야겠다고 생각했습니다.” 소티오가 말했다. 그 통합으로 그는 엠비리코스(Alexander Embiricos)와 함께 일하게 됐다. 브록먼은 여러 내부 코딩 프로젝트를 두고 이렇게 설명했다. “그중 두 개를 합쳤습니다. 그런 다음 또 다른 두 개를 합쳤고요.” 그렇게 모인 팀은 작은 다분야 조직이었다. 엠비리코스(Alexander Embiricos)처럼 기술을 이해하는 제품 기획자, 소티오처럼 인프라와 엔지니어링에 능한 사람, 미아 글레이즈 같은 연구자가 함께했다.

7. 업무 곳곳에 흩어진 시도를 합치면 무엇을 해낼 수 있을까?

글레이즈는 딥마인드에서 제미나이와 모델 정렬을 연구하다 오픈AI로 왔다. 오픈AI에서는 모델 학습과 정렬에 쓰이는 데이터를 담당했다. 모델의 구체적인 행동을 형성할 데이터를 확보하고 활용하는 전문가였다는 뜻이다.

어떤 면에서 그는 감상에 흔들리지 않는 철저한 경험주의자다. 인터뷰에서도 정량적 접근을 분명히 강조했다. “연구에서 감만 믿는 것은 별로 유용하지 않습니다.” 하지만 모델을 만드는 과정을 이야기할 때는, 그중 얼마나 많은 부분이 미지의 세계로 뛰어드는 일인지 말하며 곧잘 웃었다.

“모델을 학습시킬 때마다 마법 같은 모험을 떠납니다. ‘이걸 어떻게 하지?’ 하고요.” 그가 말했다.

제품 담당자와 연구자가 나란히 일하는 이런 다분야 팀은 AI 분야에서 다소 이례적이다. AI는 역사적으로 연구가 주도해 온 분야다. 최고의 연구자는 르브론 제임스를 떠올리게 할 정도로 수백만 달러 규모의 계약을 맺는 반면, 다른 사람은 업계 표준 수준의 엔지니어 연봉을 받는다. AI 연구소들은 연구자든 아니든 대부분의 기술 인력에게 ‘기술 직원’이라는 같은 직함을 주는 방식으로 이런 슈퍼스타 중심의 위계에 대응하려 해 왔다.

제품팀과 함께 일하면서 글레이즈와 다른 연구자들은 자신들이 만든 모델이 어떻게 쓰이는지 보고 사람들이 다음에는 무엇을 해 주길 바라는지 들을 수 있었다. 제품 담당자가 “모델이 이런 일을 할 수 있으면 정말 좋지 않을까요?”라고 물으면 연구자가 그것을 구현할 수 있었다. 소티오의 부트스트래핑 순환이 다시 나타난 셈이었다. 이번에는 모델과 그 위에 만든 제품 사이에서 돌아갔다.

오픈AI에는 마침내 제품, 디자인, 연구가 함께 움직이는 Codex팀이 생겼다. 이제 무엇을 만들지만 결정하면 됐다.

8. 클라우드와 그 한계

앤트로픽에서는 이미 유망한 접근법이 인기를 얻기 시작했다. 2025년 2월 24일 앤트로픽은 클로드 3.7 소네트와 함께 Claude Code의 연구 미리보기를 공개했다. 커서나 비슷한 도구와 달리 Claude Code에는 내장 코드 편집기가 없었다. 터미널에서 실행되며 사용자 컴퓨터의 파일을 직접 다뤘다. 원하는 것을 말하면 코드를 읽고 수정한 뒤 실행했다.

사용자 컴퓨터에서 돌아갔기 때문에, 이미 작업하던 파일과 이미 설치한 도구를 그대로 사용했고 그때까지 함께한 작업의 맥락도 이어졌다. 작업 중간에 끼어들 수도 있었다. 한 세션에서 배운 내용을 다음 세션으로 가져가 작업 체계가 시간이 지날수록 나아지고 개선 효과가 쌓이게 할 수도 있었다. 매번 임시 클라우드 컴퓨터를 사용하는 Codex 클라우드에서는 할 수 없는 일이었다.

개발자들은 빠르게 Claude Code를 받아들였다. 에브리의 에드마르 페헤이라는 2025년 3월 바이브 체크에서 “Claude Code는 내가 지금까지 써 본 어떤 에이전트보다도 낫다”고 썼다. 다른 팀원들도 동의하기 시작했다.

2025년 봄, 엠비리코스(Alexander Embiricos)와 소티오, 글레이즈를 비롯해 몇 명이 모인 Codex팀은 소프트웨어 엔지니어링의 미래를 다른 방식으로 그렸다. Codex 클라우드였다. 자기 컴퓨터를 가진 에이전트가 클라우드에서 일하는 구상이었다. 비동기 작업을 위해 설계해 사용자가 컴퓨터나 휴대전화에서 코딩 작업을 맡길 수 있게 하려 했다. 팀은 개발부터 출시까지 약 7주라는 기한을 잡았다.

chatGPT 사이드바에서 Codex를 누르면 작업 공간이 열렸다. 거기에 할 일을 적고 ‘Code’를 누르면 됐다. 작업은 대기열로 넘어가고 입력창은 다음 요청을 받을 수 있게 비워졌다. Codex는 코드베이스를 격리된 클라우드 컴퓨터로 복사하고, 파일을 수정하고, 테스트와 린터를 실행했다. 린터는 코드에서 흔히 발생하는 실수를 찾아내는 도구다. 결과로 작업 요약과 변경 내역, 풀 리퀘스트를 여는 버튼이 제공됐다.

Codex 클라우드는 2025년 5월 16일 출시됐다. 내가 미션베이에서 매컬럼(Lindsay McCallum), 엠비리코스(Alexander Embiricos)를 만난 밤보다 거의 석 달 전이었다. 소티오는 “내부에서는 매우 성공적이었다”고 말했다. 하지만 오픈AI 밖에서는 출시 당시 관심을 끌었을 뿐, 꾸준한 사용으로 거의 이어지지 않았다.

제품을 쓰려면 개발자는 노트북에 있던 소프트웨어와 권한, 설정을 클라우드에 다시 구성해야 했다. 인증 정보를 옮기고 필수 소프트웨어 패키지를 설치해야 해서 몇 시간이 걸릴 수도 있었다. 설정을 마치면 명확하게 정의된 작업은 해낼 수 있었다. 하지만 작업 도중 끼어들어 방향을 바로잡을 수 없었고, 후속 요청을 보내도 새 클라우드 컴퓨터가 시작됐다. 나는 출시 당일 바이브 체크에 이렇게 썼다.

“기존 코드베이스에 기능을 추가하거나 버그를 고치는 기술 책임자라면 찾게 될 도구다. 바이브 코딩으로 기업가치 10억 달러짜리 1인 SaaS 회사를 새로 만들려 한다면 다른 곳을 찾아봐야 한다.”

오픈AI 내부에서는 개발 환경이 표준화돼 있어 설정이 자동으로 이뤄졌고 연구자에게는 맡길 작업도 명확하게 정리돼 있었다. 팀 자신들의 작업 환경 때문에 다른 사람에게 얼마나 많은 준비를 요구하는지 보이지 않았던 것이다.

Codex 클라우드의 발목을 잡은 것은 제품만이 아니었다. 엠비리코스(Alexander Embiricos)는 “모델이 충분히 똑똑하지 않았기 때문에 시기상조였다”고 말했다.

“우리는 좀 더 먼 미래의 비전에서 접근하고 있었습니다.” 글레이즈가 말했다. “‘사람들이 지금 있는 곳으로 가자’는 식으로 하지는 않았죠.” 사람들이 있던 곳은 “자신의 노트북”이었다.

그렇다면 오픈AI는 왜 앤트로픽에서 성과를 내기 시작한 터미널 방식을 건너뛰었을까? “건너뛴 것은 아닙니다.” 구내식당에서 소티오가 말했다. 공개하지 않은 내부 시제품을 가리키는 말이었다. “그런 버전을 만들었다가 한 달 만에 버리고 완전한 클라우드 버전으로 갔습니다.”

“왜요?” 내가 물었다. 사방으로 난 커다란 통유리 너머를 잘 살펴보면 어딘가에 앤트로픽 사무실이 보일지도 모르겠다는 생각이 들었다. 적어도 걸어가는 데 큰 어려움은 없을 것이다. 샌프란시스코는 작은 도시다.

“설정에 많은 노력을 들일 의향이 있다면 우리에게 가장 큰 이익을 줄 것이라고 생각한 방향에 맞춰 최적화하고 있었기 때문입니다.” 그가 말했다. 그 답 뒤에는 오픈AI 사람들에게서 거듭 들었던 믿음이 있었다. 그들에게 이상적인 AI 에이전트는 언제나 클라우드에서 자율적으로 일하며, 노트북 덮개를 닫아도 멈추지 않는 존재였다. 브록먼도 인터뷰에서 같은 말을 했다. “미래를 내다보면 올바른 형태는 자기 노트북을 가진 클라우드 속 AI입니다. 그래서 실제로 그것을 만들었습니다.”

9. 에이전트가 작업을 처음부터 끝까지 처리하려면 무엇이 필요할까?

그 선택은 모델의 한계와 타협한 결과이기도 했다. 팀은 프로그래머에게 매 순간 반응하는 모델 대신, 하나의 작업에 더 오랜 시간을 쓸 수 있는 모델을 중심으로 첫 클라우드 제품을 만들었다. 문제는 통하지 않았다는 것이다. 클라우드 제품은 시장에 안착하지 못했다. 팀의 엔지니어링 매니저는 기업가치 90억 달러로 AI 코딩 시장을 선도하던 커서로 떠났다. 이 무렵 오픈AI는 커서의 가장 가까운 경쟁사인 윈드서프를 30억 달러에 인수하기로 합의했다고 보도됐다. 그 거래는 7월에 무산됐다.

“가장 힘들었던 때는 무엇을 해야 할지 모르겠다고 느꼈을 때였습니다. 혹은 무엇을 해야 하는지는 알지만, 실제로 진전이 일어나는 모습을 보기가 정말 어려웠을 때였죠.” 엠비리코스(Alexander Embiricos)가 말했다.

Codex팀은 처음으로 길을 잃었다. 어느 정도는 오픈AI의 더 큰 코딩 구상도 마찬가지였다.

10. 다른 길

추론 모델을 강력하게 만드는 것은 되돌아가 생각할 수 있는 능력이다. 코드의 특정 부분에 버그가 있다고 판단해 다시 작성했는데도 버그가 남아 있다면, 대개 확신에 찬 채 잘못된 방향으로 계속 나아가지는 않는다. 자신의 가정을 다시 검토하고, 해결책을 찾는 범위를 넓히고, 배운 것을 바탕으로 더 유망한 새 경로를 고를 수 있다.

실수를 활용해 방향을 바로잡는 능력 덕분에 추론 모델은 처음에는 뻔히 보이지 않던 답을 찾을 수 있다. 클라우드 제품 출시 이후인 2025년 늦봄과 여름, Codex팀은 다른 길을 시도할 준비가 됐다. 당시 프로젝트는 오픈AI에서 소외된 곳에 있었다. 막 합류했던 디자이너 에드 베이스는 그곳을 “변방”이라고 회상했다. “잘나가는 디자이너가 되고 싶다면 chatGPT에서 일해야 했습니다.”

이렇게 주목받지 못하던 곳에서 소티오가 팀의 엔지니어링 매니저를 맡게 됐다. “팀을 맡은 다음 방향을 꽤 많이 바꿨습니다.”[22] 그가 말했다. “로컬로 전환했죠.”

‘로컬’은 Claude Code처럼 클라우드 대신 개발자 자신의 컴퓨터에서 에이전트를 실행한다는 뜻이었다. 팀은 로컬 Codex CLI에서 출발했다. 엠비리코스(Alexander Embiricos)의 표현에 따르면 두 사람이 부업처럼 매달려 “영웅적으로” 만들어 낸 프로젝트였다. 소티오는 곧바로 기능을 추가해 빠르게 추진력을 얻는 대신 다른 길을 택했다. 에이전트를 다시 작성하기로 했다.

“아주 좋은 CLI 기능을 갖추는 데는 좀 느렸습니다.” 그가 말했다. “에이전트 자체를 개발하느라 너무 바빴거든요.”

CLI는 사용자가 접하는 인터페이스였지만, 소티오가 우선한 것은 그 아래에서 움직이는 장치였다. 파일을 읽고 명령을 실행하는 등의 일을 하는 에이전트였다. 그는 그것을 개선하고 터미널 인터페이스에서 분리해 어디서든 작동할 수 있게 만들고 싶었다. 코드 편집기, 데스크톱 앱, 모바일 앱, 클라우드, 심지어 chatGPT 자체 안에서도 말이다. 팀은 속도와 안전이 중요한 시스템을 위해 설계된 언어인 러스트로 에이전트를 다시 만들었다.[25] 그러면 같은 기반으로 터미널 CLI와 나중에 나올 편집기 확장 기능을 모두 구동할 수 있었다.

11. 에이전트를 위해 만든다는 것은 무슨 뜻일까?

하지만 여전히 부족한 것이 있었다. 그 에이전트를 제대로 움직일 만큼 좋은 모델이었다. Codex팀이 소티오의 지휘 아래 에이전트를 다시 만드는 동안, 미셸 포크래스는 GPT-5가 실제 프로그래밍을 더 잘하도록 개선하고 있었다.

GPT-4.1 연구를 이끌었던 포크래스는 후속 학습을 지휘했다. 이미 학습된 모델의 행동을 다듬어 실제 프로그래밍 업무를 처리하게 만드는 과정이었다. 더 나은 대화형 코딩을 요청한 고객에게 초점을 맞췄다.

코딩 모델은 SAT 만점을 받았지만 한 번도 직장에 다녀 본 적 없는 학생과 비슷할 수 있다. 오픈AI 모델은 코딩 대회에서 뛰어난 성적을 냈지만, 그 결과가 일상적인 개발 업무로 이어지지는 않았다. 브록먼은 “정리되지 않은 코드베이스나 프로그래머가 작업 중간에 끼어드는 상황을 한 번도 본 적이 없었다”고 말했다.

책으로만 배운 모델에 현장 경험을 주기 위해 포크래스와 팀은 프로그래머 옆에 앉아 일하는 모습을 지켜봤다. 모델이 어디서 제대로 작동하지 않는지 확인하고, 그 실패를 반복해서 학습할 수 있는 과제로 바꿨다.

그렇게 오픈AI는 2025년 8월 나를 미션베이 회의실로 이끌었던 모델과 그 순간에 도달했다. Codex팀이 보낸 격동의 여름을 안에서 바라보면, 그날 밤 GPT-5에서 느꼈던 조심스러움은 이해할 만했다. 오픈AI는 Codex 클라우드로 완전한 자율성을 향해 단번에 뛰어들려다 실패했고, 더 나은 대화형 협업 도구를 원한다는 고객의 요구를 받았다. 그 결과 사람 프로그래머와 한 단계씩 함께 일하는 데 뛰어난 모델을 만들었다. 복잡하고 정리되지 않은 코드베이스의 여러 부분이 어떻게 맞물리는지 이해하고, 계획을 설명하고, 버그를 조사하고, 허용 범위를 벗어나기 전에 멈춰서 물을 수 있는 모델이었다.

에브리에서 느끼기에 Codex CLI의 GPT-5는 여전히 Claude Code보다 뒤처져 있었다. 키어런은 출시 당일 바이브 체크에 이렇게 썼다. “GPT-5는 소네트 3.5를 잡는 모델이지, 미래를 향한 도약은 아니다.” 하지만 당시 대다수 소프트웨어 엔지니어가 원한 것은 신중한 협업 상대였다. 모든 코드를 직접 작성하는 데 익숙한 프로그래머들은 실제 서비스 코드를 자율 에이전트에 맡긴다는 말을 여전히 코웃음 치곤 했다.

루비 온 레일스를 만든 개발자이자 엔지니어링 커뮤니티의 영향력 있는 인물인 데이비드 하이네마이어 핸슨은 GPT-5 출시 무렵 이렇게 말했다. “내 코드를 에이전트가 주도하게 두지는 않습니다.” 이어 말했다. “프로그래머의 즐거움, 적어도 프로그래머인 제 즐거움은 코드를 직접 입력하는 데 있습니다.” 게다가 에이전트가 주도하면 “능력이 손끝에서 빠져나가는 것이 실제로 느껴진다”고 했다.

Codex팀이 GPT-5 출시에 이어 8월 말 VS Code와 커서용 확장 기능을 내놓자, 이런 개발자들이 몰려들었다. 그들의 열렬한 반응은 오픈AI가 확장 기능을 계속 개선할 이유가 됐다. 새로운 사용자와 기능 요청이 하나씩 더해질 때마다 팀은 프로그래머의 단계별 작업을 돕는 쪽으로 끌려갔고, 작업 전체를 맡을 에이전트를 만드는 방향에서는 멀어졌다.

하지만 엠비리코스(Alexander Embiricos)에게 같은 출시는 더 큰 구상을 추진할 수 있다는 뜻이었다. 몇 달간 헤맨 끝에 다시 만든 로컬 에이전트가 마침내 자신을 움직일 만한 모델을 갖게 된 것이다. 그는 개편한 CLI와 GPT-5를 함께 출시하자 “스스로 추진력을 만드는 선순환이 생겼다”고 말했다. 당시 그는 이렇게 생각했다고 했다. “드디어 이제 싸워 볼 수 있겠구나.”

Codex CLI와 편집기 확장 기능이 드디어 인기를 얻고 있다. 고객은 사이드바를 좋아하고 터미널에서는 Claude Code가 넘어야 할 상대다…

편집기 확장 기능에 더 집중하고 터미널에서 따라잡자…

12. 데스크톱 앱이라는 승부수

티보가 끼어들었다. Codex CLI와 VS Code 확장 기능의 인기가 폭발적으로 늘고 있었으니, 둘에 계속 투자하는 것이 합리적인 선택이었을 것이다. 하지만 Codex팀은 뜻밖의 일을 했다.

“CLI는 계속 유지하되, 당장 다음으로 가장 크게 투자할 대상은 네이티브 데스크톱 앱이어야 한다고 결정했습니다.” 소티오가 말했다.

오픈AI 안에서 그는 모델이 더 긴 작업을 완수하고 코드베이스 밖의 정보를 활용하는 모습을 보고 있었다. 음성과 이미지도 곧 들어올 참이었다. 머지않아 사람들은 여러 에이전트를 동시에 실행하고 하루 종일 함께 일하게 될 것이었다. “온종일 그 안에서 지낼 거라면 인터페이스가 아주 풍부해야 합니다.” 그가 말했다. 1970년대에 만들어진 텍스트 전용 창 안에서 텍스트, 이미지, 음성, 영상으로 소통하는 에이전트 대여섯 개를 다루려는 것은 어리석어 보였다.

엠비리코스(Alexander Embiricos)에게 로컬 데스크톱 앱은 Codex 클라우드에서 실현하지 못했던 작업 방식을 향한 길이기도 했다. Codex 클라우드에서는 작업 도중 에이전트에게 끼어들 수 없었다. 자기 컴퓨터의 앱이라면 처음에는 에이전트와 긴밀하게 함께 일하다가, 새 동료를 적응시키듯 어떤 일을 맡겨 두어도 되는지 배울 수 있다고 생각했다.[27] 같은 인터페이스를 통해 Codex는 언젠가 개발자를 넘어 터미널을 한 번도 열지 않을 사람들에게까지 다가갈 수 있었다.

설계와 개발을 돕기 위해 소티오는 디자이너이자 프로그래머이며 전직 스타트업 창업자인 앤드루 앰브로시노를 데려왔다. 앰브로시노를 보면 드라마 《오피스》에서 B. J. 노백이 연기한 인물이 떠오른다. 검은 머리, 짙은 눈썹, 입을 다문 채 살짝 짓는 미소 때문이다. 직접 만나도 온라인에서 봐도 늘 속으로 혼자 재미있어하는 인상을 준다. 다른 사람도 그 농담에 함께 웃는지는 신경 쓰지만, 대체로 그다음 문제인 것처럼 보인다.

인공지능의 미래에 관한 통찰을 얻으려고 그를 팔로우한 사람이라면, 피드를 내리다 ‘ai’라는 단어 하나만 적힌 게시물을 보게 될 수 있다. 좋아요는 617개다. 또 다른 게시물에는 수수께끼처럼 ‘tibo’라고만 적혀 있다. 좋아요는 1,000개가 넘는다. 앰브로시노가 앱을 만드는 작은 그룹에 합류했을 때, 팀은 데스크톱 앱을 만들고 싶다는 것만 알았지 어떤 모습이어야 하는지는 몰랐다.[28] 확실한 것은 자신들이 직접 쓸 제품을 만들고 싶다는 점뿐이었다.

앰브로시노에 따르면 첫 번째 목표는 그 앱을 일상 업무의 주력 도구로 만드는 것이었다. “매일 주로 쓰는 작업 공간을 원한다는 것은 알고 있었습니다. 다만 IDE보다는 가벼워야 했죠.”

Claude Code가 인기를 얻으면서 몇몇 앱이 터미널 밖에서 코딩 에이전트의 작업 공간이 어떤 모습일지 실험하기 시작했다. 코딩 에이전트를 실행하는 맥 앱 컨덕터에는 작업 목록이 있는 사이드바가 있었다. 각 작업에는 자체 에이전트와 채팅이 있어서 지시를 내리고 진행 상황을 따라갈 수 있었다. chatGPT도 참고 대상이었다. 한쪽에는 대화 목록이, 가운데에는 선택한 대화가 있었다. 앰브로시노는 Codex 앱의 디자인 과정을 설명하며 “VS Code보다 채팅에서 더 많은 영감을 받았다”고 말했다.[30] 당시에는 앤트로픽에도 클로드 데스크톱 앱이 있었다.

팀은 빠르게 움직이며 기본적인 질문에 답을 정했다. 사용자가 작업을 어떻게 추적할 것인가? 작업마다 에이전트와의 대화를 따로 둔다. 사이드바는 어떻게 정리할 것인가? 대화를 프로젝트별로 묶는다. 기본 화면은 어떻게 배치할 것인가? 선택한 대화 옆에 작업 목록 사이드바를 둔다.

그다음에는 더 어려운 질문이 나왔다. 에이전트가 잘못했을 때 Codex 안에서 사용자가 직접 코드를 고칠 수 있어야 할까? 팀은 위험을 감수하는 답을 내렸다. 내장 코드 편집기를 넣지 않기로 했다. 코드를 조금이라도 바꾸려면 에이전트에게 요청해야 했다.

“의도적으로 코드 편집기와는 다른 제품이 되기를 원했습니다.” 앰브로시노가 말했다. 개발자가 앱 안에서 코드를 직접 입력하게 하면 실행 취소, 검색, 단축키처럼 기존 편집기가 해 주던 다른 모든 기능도 기대하게 된다. 그러면 Codex에 무엇이 빠졌는지 눈에 들어올 것이다. 네 명뿐인 팀이 그런 기대를 뛰어넘기는커녕 충족하기만 해도 엄청난 노력이 필요했다.

Codex는 어설픈 코드 편집기가 돼서는 이길 수 없었다. 개발자가 편집기를 아쉬워하지 않을 만큼 에이전트로 코딩하는 경험이 좋아야 했다. 문제는 VS Code를 대체할 제품을 여전히 VS Code로 만들고 있었다는 점이었다.

“알렉산더가 매일 와서 이랬습니다. ‘한 사람씩 물어볼게요. 이 앱을 주로 쓰고 있나요? 이 앱을 주로 쓰고 있나요?’”[31] 앰브로시노가 말했다.

처음에는 모두 “아니요”라고 답했다. Codex를 주력 코딩 도구로 쓰는 사람이 없었다. 코드 편집기가 없어서 사소한 수정도 에이전트와 대화를 해야 했다. 개발자 경험을 담당하는 도미니크 쿤델은 초기 슬랙 메시지에서 문장 하나를 바꾸는 데도 “Codex에 프롬프트를 입력해야 한다는 게 번거롭게 느껴진다”고 썼다.

앰브로시노에게도 의구심이 있었다. 그는 11월 팀에 이렇게 적었다. “출시 범위에서 가장 회의적인 부분은 ‘파일을 직접 편집할 수 없다’는 점인 것 같습니다.”

외부 시장의 상황은 코드 편집기를 빼기로 한 선택을 더 위험해 보이게 했다. 2025년 11월 구글은 VS Code를 바탕으로 만든 또 다른 코딩 도구인 안티그래비티를 공개했다. AI 에이전트와 완전한 편집기를 결합한 제품이었다.

“그냥 서로를 쳐다봤습니다.” 앰브로시노가 회상했다. “VS Code를 포크하지 않은 것이 엄청난 실수였을까? 정말 고민이 많았습니다. 팀 안에서도 의견이 일치하지 않았던 것 같아요.”

앱을 구동하는 모델도 문제였다. 오픈AI는 9월에 Codex 전용 모델 계열을 내놓았지만, 11월에도 만들고 있던 데스크톱 제품을 뒷받침하기에는 부족했다. 앰브로시노는 앱의 기능이 완벽하게 갖춰졌더라도 “당시 모델의 품질 때문에 출시할 수 없었을 것”이라고 말했다.

13. 모델이 준비되기 전에 만들어 둘 만한 것은 무엇일까?

그 뒤 몇 주 동안 상황이 바뀌기 시작했다. 11월 19일 오픈AI는 한 번에 몇 시간씩 코딩할 수 있는 GPT-5.1 Codex Max를 공개했다. 12월 18일에는 GPT-5.2 Codex가 뒤를 이었다. 대규모 코드베이스 전반을 수정하는 능력이 더 좋아졌다.

글레이즈는 나머지 Codex팀과 직접 협업하며 개발자의 피드백이 모델 개선으로 이어지는 주기를 더 줄였다. 핵심은 유명 벤치마크의 점수만 높이기보다 실제로 쓰는 사람에게 Codex가 더 잘 작동하도록 만드는 데 집중했다는 점이다. Codex 모델 계열이 chatGPT의 주력 모델과 분리돼 있었기 때문에, 변경 사항이 chatGPT 사용자 8억 명에게 어떤 영향을 줄지 걱정하지 않고 더 빠르게 움직일 수 있었다.

12월이 되자 코드 편집기보다 Codex 앱을 쓰는 팀원이 늘었다. 쿤델은 슬랙에 이렇게 썼다. “처음에는 코드 편집기가 정말 간절했습니다. 이제는 대부분의 변경 사항을 코드 줄에 댓글로 남기기만 하는데, 엄청나게 빨리 처리됩니다.” 앰브로시노는 여전히 모델의 방향을 잡아 줘야 했지만, 더는 코드를 손으로 고칠 필요가 없다는 사실을 알게 됐다. 글레이즈도 내부 분위기가 달라졌음을 느꼈다. “5.2는 전환점이었습니다. ‘와, 이게 나를 위해 무엇을 해 줄 수 있을지 정말 기대된다’고 생각했죠.”

업계 전반에서도 연말 휴가가 변곡점이 됐다. 개발자들은 크리스마스 휴가 동안 앤트로픽의 오퍼스 4.5와 오픈AI의 GPT-5.2로 코드 한 줄 직접 만지지 않고 앱 전체를 처음부터 끝까지 만들었다.

1월 초에는 팀 전체가 Codex 앱을 쓰고 있었다. 이제 오픈AI의 다른 사람들도 쓸지 확인해야 했다. 그렇지 않다면 앰브로시노의 말대로 “원점으로 돌아가야 했다.”

2월에는 Codex 데스크톱 앱이 엔지니어링팀과 연구팀에서 널리 쓰이기 시작했다. 오픈AI 연구자 노엄 브라운은 “완전히 갈아탔다”고 했고, 터미널과 이맥스 편집기의 열렬한 사용자였던 브록먼도 마찬가지였다. 브록먼은 예전 작업 방식으로 돌아가면 “과거로 돌아간 느낌”이라고 말했다. 올트먼은 나중에 이 앱을 “우리가 지금까지 만든 내부 제품 중 가장 사랑받는 제품”이라고 표현했다.

Codex팀은 오픈AI 개발자들이 좋아하는 제품을 만들었다. 하지만 Codex 클라우드도 내부에서는 환영받다가 외부에 출시한 뒤 실패했다. 이번에는 다를까?

14. Codex 앱

Codex 맥OS 데스크톱 앱은 2026년 2월 2일 대중에게 공개됐다. 코드 편집기보다는 채팅 앱에 가까운 모습이었다. 사이드바에는 진행 중인 작업과 지난 작업이 있었고, 하나를 누르면 에이전트가 한 일을 확인하고 추가 지시를 보낼 수 있었다.

한 에이전트에게 버그 수정을 맡기고 다른 에이전트에게 기능 개발을 보낸 다음, 둘 사이를 오가며 질문에 답하거나 변경 사항을 검토할 수 있었다. 에이전트마다 자기 코드 사본에서 작업하므로 다른 에이전트의 작업을 덮어쓰지 않았다. 가까이에서 방향을 잡아 줄 수도 있었고, 여러 작업을 돌려 두었다가 자신이 필요할 때 돌아올 수도 있었다.

당시 이런 기능 자체가 특별히 획기적인 것은 아니었다. 예를 들어 클로드 데스크톱 앱에서는 기술 사용자와 비기술 사용자 모두 몇 달 전부터 같은 일을 할 수 있었다. 하지만 클로드 데스크톱 앱은 채팅으로 시작해 코드를 추가하고, 다시 코워크를 추가하는 식으로 단계적으로 만들어졌다. 그 때문에 인터페이스가 복잡하고 여러 부분을 덧붙여 놓은 것처럼 느껴졌다. 어떤 작업에 어느 탭을 써야 하는지, 탭마다 어떤 기능과 권한이 제공되는지 파악하기 어려웠다.

Codex 앱에는 이런 흔적이 없었다. 며칠 뒤 나온 새 모델 GPT-5.3 Codex와 함께 처음 써 봤을 때, 빠르고 단순했으며 처음부터 끝까지 에이전트를 중심으로 만들어져 있었다. 제품의 세세한 부분이 모두 잘 맞아떨어질 때 느끼는 매끄러움이 있었다. 팀이 초기에 코드 편집기를 빼겠다고 고집한 덕분에, 사용자가 앱 안에서 할 수 있는 일이라면 거의 무엇이든 Codex 에이전트도 할 수 있도록 만들어 놓았다. 예를 들어 새 도구를 연결하려고 설정을 뒤질 필요가 없었다. 그냥 에이전트에게 부탁하면 됐다.

15. 오늘 작업 방식을 처음부터 다시 만든다면 무엇을 빼겠는가?

GPT-5.3 Codex는 오픈AI 모델의 역량에서도 전환점이었다. 글레이즈에 따르면 Codex 계열에서 프로그래밍에 특화된 학습을 넘어 다른 영역으로 넓혀 가기 시작한 첫 시점이었다. 이름은 여전히 Codex였고, 모든 일을 더 잘한다고 주장한 것도 아니었다. 다만 팀은 코딩 에이전트가 온갖 지식 업무에 유용해지려면 무엇을 더 알아야 하는지 묻기 시작했다.

내 작업 방식에는 즉각적인 변화가 생겼다. 거의 클로드만 쓰던 상태에서 업무의 상당 부분을 Codex로 옮겼다. 내가 만들고 있던 문서 편집기 프루프에서는 Codex가 별다른 개입 없이 복잡한 버그를 자율적으로 고치는 모습을 봤다. 머지않아 어려운 문제를 맡겨 놓고 밤새 일하게 두기 시작했다. 특히 까다로운 일이 생기면 Codex부터 찾았다.

3월 초 GPT-5.4가 나오면서 Codex는 내 주력 도구로 확실히 자리 잡았다. 여전히 뛰어난 코딩 모델이었지만, 이제는 설명도 명확했고 내가 원하는 것을 더 잘 이해했다. Codex 앱의 인터페이스가 깔끔하고 빨랐기 때문에 모든 일을 그 안에서 하기 시작했다.

그 무렵 에브리의 많은 사람도 오픈AI의 도구와 모델을 매일 쓰고 있었다. 불과 몇 달 전 클로드가 압도적인 선택이었던 상황에서 정반대로 바뀐 것이다. 우리는 GPT-5.4 바이브 체크에서 이렇게 표현했다. 오픈AI가 돌아왔다.

같은 변화는 에브리 밖에서도 일어나고 있었다. 오픈AI는 3월 19일 기준 Codex의 주간 사용자가 200만 명을 넘었고, 전체 사용량은 연초보다 다섯 배 늘었다고 밝혔다. 4월에는 앱 내 브라우저를 추가했다. 에이전트가 정보를 찾고 실제 웹페이지에서 자신의 작업을 확인할 수 있게 됐다. 다른 맥 앱을 오가며 작업하고 문서, 슬라이드, 스프레드시트의 미리보기를 보여 주는 것도 가능했다. 코드를 한 번도 써 보지 않은 사람도 발표 자료나 예산 보고서를 요청하고 앱을 떠나지 않은 채 결과를 볼 수 있었다.

6월에는 Codex의 주간 사용자가 500만 명을 넘었고, 약 다섯 명 중 한 명은 지식 노동자였다. 7월 9일 오픈AI는 Codex 데스크톱 앱을 새로운 chatGPT 데스크톱 앱으로 바꾸고, 그 안에 채팅을 넣었다. 내부적으로 새 chatGPT가 맥에 알리는 자신의 이름은 여전히 <span>com.openai.codex</span>다.

Codex 클라우드는 chatGPT 안의 탭으로 출시됐다. 이제는 chatGPT가 Codex 위에서 돌아간다. 에드 베이스(Ed Bayes)는 통합을 발표한 전사 회의를 마치고 나오며 팀이 얼마나 멀리 왔는지 생각했던 일을 기억한다. “구석에 있던 몇 사람”으로 시작한 것이 이제는 “chatGPT의 미래”가 됐다. 그는 내게 말했다. “미국 기업사의 한 장면 같은 일입니다.”

16. 다음 성장 곡선

GPT-5 출시로부터 열 달 뒤, 나는 다시 알렉산더 엠비리코스(Alexander Embiricos)와 회의실에 앉아 있었다.

“여기서는 정말 솔직하게 이야기해도 되는 거죠?” 엠비리코스(Alexander Embiricos)가 물었다. “그렇게 해 주세요.” 내가 말했다.

6월 초였다. 뜨거운 관심을 받던 Codex가 chatGPT에 통합되기 한 달 전, 우리는 맨해튼 도심의 오픈AI 사무실에 있었다. 그는 소매를 걷어 올린 회색 집업을 입고 있었다. 최근 Codex 에이전트의 제품 책임자에서 오픈AI의 기업용 제품 총괄로 역할이 바뀌었다. 뒤에는 화이트보드가 있었다. 나는 그의 팀이 Codex 클라우드의 실패에서 어떻게 chatGPT의 토대가 될 제품을 만드는 데까지 이르렀는지 물으러 왔다. 미션베이에서 내가 걱정했던 페어 프로그래밍의 함정에 어떻게 갇히지 않았는지도 알고 싶었다. 대부분의 팀은 이미 잘되는 것을 더 발전시킨다. Codex팀은 그러지 않았다. 무엇이 계속 앞으로 움직일 수 있게 했을까?

엠비리코스(Alexander Embiricos)는 검은 마커를 집어 들고 화이트보드에 Codex의 성장 곡선을 그렸다. 먼저 Codex 클라우드를 나타내는 짧은 상승 곡선을 그렸다. 제법 올라갔지만 곧 평평해졌다. 그다음 GPT-5 이후 CLI를 나타내는 더 가파르고 큰 곡선을 그렸다. 이어 편집기 확장 기능을 나타내는 더 높은 곡선을 그렸다. 마지막은 5.3 Codex와 데스크톱 앱이었다. 다른 곡선들이 작아 보일 만큼 컸다. 처음 그린 선은 이제 화이트보드 바닥 근처의 작은 흠집처럼 보였다.

화이트보드의 곡선들은 크리스텐슨의 《혁신기업의 딜레마》에 나오는 도표를 닮았다. 크리스텐슨은 하드디스크와 프로세서의 꾸준한 발전이 메인프레임에서 미니컴퓨터, 데스크톱 PC, 노트북, 그리고 마침내 휴대전화로 이어지는 전환을 어떻게 이끌었는지 설명한 것으로 유명하다. 기반 하드웨어가 도약할 때마다 더 단순한 제품 형태가 가능해졌고, 더 크고 기술에 덜 익숙한 시장을 열면서 이전 형태를 앞질렀다.

전통적인 컴퓨팅에서는 여러 신생 기업을 거치며 반세기에 걸쳐 나타났던 패턴이, 오픈AI 안에서는 소수의 팀원이 일한 열 달 동안 축소판처럼 펼쳐졌다. 모델은 끊임없이 도약하며 자신을 둘러싼 인터페이스의 한계를 넘어섰다. 그 때문에 Codex팀은 코드 편집기의 사이드바와 터미널을 거쳐, 코드 편집기를 아예 뺀 가벼운 데스크톱 앱으로 이동해야 했다.

크리스텐슨의 책에서 성공하는 성장 곡선을 탄 팀은 거의 다음 곡선을 타지 못한다. 기존 제품의 성공이 뒤에 오는 것을 질식시키기 때문이다. Codex팀이 그런 운명을 피한 데에는 오픈AI 경영진이 스타트업 세계에서 성장하며 바로 그 함정을 공부해 왔다는 배경도 있었다. 회사는 여러 가능성에 동시에 투자하는 포트폴리오처럼 움직이도록 구성돼 있었다. Codex팀은 chatGPT의 거대한 규모와 사용자 기반이 주는 제약에서 벗어나 독자적인 제품과 모델 계열을 개선할 여지를 얻었다.

AI를 만드는 데 AI를 쓰는 일은 제품 개발이 움직이는 방식 자체도 바꿨다. 전통적인 회사에서 새 제품을 시작하려면 예산과 엔지니어를 확보하기 위해 몇 달씩 회의해야 한다. 이런 논쟁에서는 잘나가는 기존 제품이 거의 언제나 이긴다. 오픈AI에서는 Codex로 Codex를 만들고 있었기 때문에 소수의 인원이 몇 주 만에 새로운 인터페이스를 만들어 낼 수 있었다. 소티오는 내게 이렇게 말했었다. “이제 사람들을 설득하는 데 말이 훨씬 덜 필요합니다.”

17. 화이트보드에 있는 어떤 아이디어를 실제로 만들어 사람들에게 써 보게 할 수 있을까?

화이트보드를 바라보던 엠비리코스(Alexander Embiricos)에게는 그릴 새 곡선이 하나 더 남아 있었다. 이제 수백만 명이 자기 컴퓨터에서 에이전트를 믿고 쓰고 있었다. 다음 단계는 지난봄 실패했던 비전으로 돌아가는 것이었다. 사람이 자리를 떠난 뒤에도 오랫동안 계속 일하는 에이전트였다.

“비동기 방식으로 갈 겁니다.” 그가 말했다. “그러려면 다시 클라우드로 올려야 하죠.”

이번에는 회의 탁자 위에 놓인 그의 노트북이 눈에 들어왔다. 덮개는 단단히 닫혀 있었다. 댄 시퍼는 에브리의 공동 창업자이자 CEO다. 에브리에서 ‘체인 오브 소트’ 칼럼을 쓰고 ‘에브리 팟캐스트’를 공동 진행한다.

18. 참고 자료

댓글남기기