Codex를 만든 설계 원칙과 AI 개발 프로세스의 변화

URL: https://www.youtube.com/watch?v=sLSTM9znQNs
날짜: 2026-09-11
채널: pragmaticengineer
출연: Tibo Sottiaux (Codex 팀 리더)
재생 시간: 74분 23초

---

📌 핵심 질문 / 핵심 논점

==Codex는 단순한 모델 호출기가 아니라, 모델의 능력을 안전하고 효율적으로 제품에 연결하는 오픈소스 coding harness이며, 모델이 좋아질수록 harness·개발 프로세스·유지보수의 역할 자체가 다시 설계된다.==

• Codex는 OpenAI 내부 연구용 에이전트에서 출발해 CLI, SDK, app server를 갖춘 제품으로 성장했다.
• 모델과 제품 인터페이스를 분리하기 위해 Rust 경계를 선택했고, 커뮤니티의 실험과 기여를 위해 오픈소스로 공개했다.
• harness는 모델의 한계를 보완하는 crutch, guardrail, developer message를 제공하며, 다음 세대 모델이 같은 능력을 학습하면 그 보조 장치를 줄인다.
• 코드 리뷰·테스트·의존성 업그레이드·재아키텍처가 자동화되면서 인간은 코드의 모든 줄보다 의도, 계약, 불변조건(invariant), 사용자 가치를 결정하는 데 집중한다.
• 로컬 Codex를 ChatGPT의 관리형 클라우드 환경에 통합하는 merge는 서로 다른 스택을 하나의 제품 경험으로 합치는 대규모 시스템 작업이었다.

Tibo가 말하는 공통 원리는 사용자를 lock-in으로 붙잡는 것이 아니라 모델, 제품, harness, 개발 경험 각각의 실력으로 이기는 것이다. 이 원리를 실현하려면 기술 선택을 장기적으로 바라보되 속도를 잃지 않아야 하며, 커뮤니티의 실제 문제를 계속 관찰하고 명확한 의도를 유지해야 한다.

1. Tibo Sottiaux의 출발점: 외딴 마을의 컴퓨터와 응용수학

1.1. 어린 시절부터 컴퓨터로 세계를 넓히다

1. 브뤼셀에서 인구 200명 정도의 마을로 이동하다

   1. Tibo는 브뤼셀에서 태어났지만 부모가 작은 집을 사서 고치기 위해 마을 한가운데로 이사했다.
   2. 마을에는 대략 200명이 살았고, 또래 중 대화하거나 친구가 되고 싶은 사람이 거의 없었다.
   3. 여덟 살 무렵 외딴 환경에 사실상 갇힌 그는 컴퓨터와 초기 인터넷을 통해 세상을 배우기 시작했다.
   4. 그는 “부모님이 아무것도 없는 곳으로 이사해 주셨기 때문에 컴퓨터에 관심을 가질 수밖에 없었다”는 식으로 이 경험을 농담처럼 회고했다.

2. 응용수학을 현실 문제의 언어로 사용하다

   1. 대학에는 비교적 일찍 들어가 응용수학(applied mathematics)을 공부했고, 스스로 중퇴할 것이라고 오래 생각했지만 일찍 졸업했다.
   2. 재학 중 작은 회사와 컨설팅 사업을 병행하며 은행의 문제를 다뤘고, 공급망과 응용수학 문제에 강한 흥미를 느꼈다.
   3. 이론수학과 이론과학이 패턴과 아름다움, 발견되지 않은 영역을 밀어붙이는 일이라면, 응용수학은 현실에 놓인 문제를 실제로 개선하는 방법이라고 보았다.
   4. 그는 “정교한 수학을 주변 세계를 최적화하는 데 어떻게 적용할까”라는 질문을 창업의 핵심 가설로 삼았다.

1.2. 최적화 창업과 여러 산업의 문제

1. 임상시험 의약품 공급망을 최적화하다

   1. 첫 창업은 임상시험(clinical trial)의 의약품 공급망을 분석하는 일이었다.
   2. 어느 지역에서 약을 더 생산할지, 어디로 보낼지, 언제 배분할지 결정해 폐기물을 줄이고 임상시험을 더 효율적으로 만드는 것이 목표였다.
   3. 당시에는 머신러닝(ML)이 아니라 전통적인 최적화 기법을 사용했다.
   4. Monte Carlo simulation, stochastic multi-stage optimization 같은 방법으로 불확실한 공급망의 선택지를 계산했다.

2. 최적화 문제의 모양을 가진 영역으로 확장하다

   1. 같은 접근을 철강 산업에 적용했다.
   2. 유럽의 전력망(electrical grid)에도 적용해 자원과 운영 결정을 개선했다.
   3. 어떤 산업이든 “최적화 문제의 형태”를 갖고 있으면 그 안의 구조를 찾아 해결하는 데 관심을 가졌다.
   4. 회사는 현재도 존재하며, Tibo는 전통적 수학 문제에 현대 AI가 결합되면서 앞으로도 크게 바뀔 것이라고 봤다.

2. Google과 DeepMind: 제품 실패에서 연구 도구로

2.1. Google에서 배운 product-market fit의 교훈

1. 모바일 웹을 빠르게 만드는 프로젝트

   1. 2015년 Google London에 합류한 뒤 처음부터 Google Maps에서 일한 것은 아니었다.
   2. 데스크톱에서 모바일로 트래픽이 이동하던 시기에 모바일 웹사이트를 빠르게 만드는 소규모 프로젝트에 참여했다.
   3. 이 사업은 모바일 전환으로 인한 광고 매출 손실을 상쇄하려는 Google Ads 조직 내부의 여러 이니셔티브 중 하나였다.
   4. 약 2년 동안 기술적으로 가장 재미있는 어려운 문제를 풀었지만, 결국 프로젝트는 취소됐다.

2. 프로젝트가 취소된 방식이 남긴 교훈

   1. 서비스 사용자는 수백 명 수준에 불과했고 Google 규모로는 명백히 작았다.
   2. 캘리포니아에서 날아온 VP가 어느 날 프로젝트를 취소한다고 통보했으며, 팀원들은 그때까지 프로젝트가 잘 진행된다고 믿었다.
   3. Tibo는 product-market fit, 올바른 사용자, 충분한 feedback loop가 없었다는 사실을 뒤늦게 깨달았다.
   4. 제품 관리자가 “잘 되고 있다”고 말해도 실제 사용자와 영향, 프로젝트의 중요성을 직접 의심하고 확인해야 한다는 교훈을 얻었다.

2.2. Maps와 DeepMind에서 연구 생산성에 집중하다

1. Google Maps에서 리뷰를 다루다

   1. 취소된 프로젝트 뒤 Google Maps로 옮겨 리뷰(review) 업무를 맡았다.
   2. 이미 재미있는 공간이었지만, 런던에 본부를 둔 DeepMind가 다루는 문제의 난도와 방향을 무시할 수 없었다.

2. DeepMind의 초기 연구 인프라

   1. 당시 DeepMind에는 AlphaGo의 조짐을 포함해 매우 큰 연구 문제가 모이고 있었다.
   2. Tibo는 연구 인프라(research infrastructure)와 연구 도구(research tooling)를 만들었다.
   3. 대규모 데이터 저장·분석과 training run을 이해하는 도구를 구축했으며, 이후 거의 10년 동안 “다른 사람이 더 빠르고 효율적으로 일하게 만드는 제품”이라는 주제를 이어 갔다.
   4. 새로운 연구를 직접 독점하기보다, 연구자가 더 큰 문제를 풀 수 있도록 도구와 플랫폼을 제공하는 방식이 그의 일하는 방식이 됐다.

2.3. ChatGPT보다 약 1년 앞선 내부 대화형 봇

1. DeepMind 내부의 별도 LLM 실험

   1. DeepMind의 주된 관심은 거대한 과제와 게임, 언어와 다른 의미의 reinforcement learning이었지만, 대규모 언어 모델(large language model)을 밀어붙이는 별도 그룹도 있었다.
   2. Google Brain에도 별도 노력이 있었으며, LLM은 당시 DeepMind의 주류 연구 방향은 아니었다.
   3. 이 그룹은 “대규모 텍스트 말뭉치가 전부라면 어떨까, 언어 모델을 최대한 확장하면 general intelligence에 도달할 수 있을까”를 논쟁했다.

2. 연구 도구에서 chat 시스템으로

   1. Tibo는 연구자가 모델의 입력과 출력을 디버깅하고 살펴보도록 도구를 만들다가 자연스럽게 대화형 인터페이스를 만들게 됐다.
   2. 초기 모델은 일관성이 약하고 유용하지 않은 답을 내놓았지만, 내부에서 모델을 만지고 대화를 공유하는 일 자체가 재미있었다.
   3. 대화가 DeepMind 내부에 빠르게 퍼지며 단순한 연구 프로젝트보다 더 큰 성격을 띠었다.
   4. 외부 제품으로 출시하고 싶은 욕구가 생겼지만, DeepMind와 Google에는 제품을 출시하는 승인 절차와 표준화된 production stack이라는 거대한 기계가 있었다.
   5. 그 체계는 수년 동안 안정성과 품질을 최적화했지만, 동시에 진정한 혁신을 시도하기 어렵게 만드는 환경이기도 했다.

3. OpenAI 합류와 Codex의 전신

3.1. 안정성보다 직접적인 미션을 선택하다

1. OpenAI를 선택한 이유

   1. Tibo는 Google에서 편안하게 지낼 수 있었지만, 훌륭한 사람들과 일하고 자신이 진심으로 믿는 미션에 참여하고 싶었다.
   2. 연구 결과를 누군가가 나중에 유용하게 만들기를 기다리는 조직보다 연구와 제품을 함께 설계(co-design)하며 직접 세계에 영향을 주는 조직을 원했다.
   3. 당시 ChatGPT가 빠르게 성장하는데도 약 20명의 엔지니어만 제품을 운영한다는 이야기를 듣고, 그 작은 팀의 자율성과 생산성에 큰 인상을 받았다.
   4. 사람들의 실력, 미션, 속도, 직접적인 영향력이 그를 OpenAI로 끌어들였다.

2. reasoning 모델의 출발을 함께하다

   1. 2024년에 합류하자마자 pre-reasoning 노력에 들어갔다.
   2. “새로운 paradigm인 reasoning model을 곧 출시한다”는 상황에서 바로 작업을 시작했고, 약 한 달 뒤 o1 및 o1-preview가 공개됐다.
   3. 빠르게 움직이면서도 세상과 사용자의 반응을 듣고, 강한 feedback loop를 통해 제품을 개선하는 문화가 이후 Codex를 만들 때의 기준이 됐다.

3.2. 연구를 가속하는 내부 coding agent

1. Python codebase에 특화된 초기 모델

   1. Tibo는 OpenAI에서도 대규모 데이터 저장·분석과 training run 도구를 만들던 연구 인프라 작업으로 시작했다.
   2. 모델이 연구 자체를 돕지 않으면 연구와 엔지니어링의 속도를 충분히 높일 수 없다는 점을 깨닫고, 모델을 이용해 모델을 만드는 일에 몰입했다.
   3. 연구팀의 다른 구성원들과 함께 내부 모델과 작은 agent를 훈련하고 만들었다.
   4. 초기 에이전트는 OpenAI의 Python codebase를 잘 이해하고, architecture와 code style에 “좋은 취향(good taste)”을 보이도록 훈련됐다.
   5. 목적은 연구 인프라를 빠르게 구축하고 연구자가 더 빨리 코딩하게 만드는 것이었다.

2. ASWE/AS3 노력과 Codex로의 수렴

   1. 인터뷰어는 당시 Autonomous Software Engineer(ASWE) 노력을 언급했고, Tibo는 내부적으로 AS3라고 발음했다고 정정했다.
   2. 초기 cloud Codex는 사용 과정의 friction이 높아 product-market fit을 얻지 못했다.
   3. 그와 별도로 Codex CLI를 출시했고, 모델이 실제 개발을 돕는 가장 핵심적인 인터페이스를 계속 밀어붙였다.
   4. Greg Brockman과 Sam Altman은 연구팀을 강하게 지원했고, 특히 Greg는 OpenAI 내부만이 아니라 세계에 이익을 주는 제품이어야 한다고 강조했다.
   5. 이 연구용 에이전트와 ASWE 노력을 하나로 합치며 현재의 Codex 방향이 만들어졌다.

4. 왜 Rust인가: 제품 인터페이스와 에이전트의 경계

4.1. distribution보다 장기 구조를 먼저 선택하다

1. 모델과 제품 인터페이스를 분리하다

   1. Codex 초기에 제품 인터페이스와 agent 자체를 서로 다른 것으로 보았다.
   2. 제품과 무관하게 존재할 수 있는 핵심 agent를 robust, secure, efficient, scalable하게 만드는 것이 중요했다.
   3. 재미있는 프로토타입이 데이터센터 최대 규모의 시스템으로 커질 때는 초기에 내린 구조적 결정이 큰 차이를 만든다.
   4. 단, 장기 설계가 단기 velocity를 지나치게 희생해서는 안 된다는 trade-off도 함께 고려했다.

2. Rust를 선택한 구체적 이유

   1. 내부에 능력 있는 Rust 개발자가 있었고, 내부 모델도 Rust를 완전히 낯설어하지 않았다.
   2. 정적 검증(static verification)과 컴파일 시점의 보장, 메모리 안전성은 agent가 실행하는 도구에 유리했다.
   3. 처음부터 Rust가 모델 분포(distribution) 측면에서 가장 좋은 언어였던 것은 아니다. TypeScript나 Python으로도 충분히 성공할 수 있었을 것이다.
   4. 하지만 정확성(correctness)과 실행 효율(efficiency)을 우선했고, Rust가 agent의 기반으로 빠르게 좋은 선택임이 분명해졌다.

4.2. 언어 경계가 혁신의 경계가 되다

1. 나중에 다시 쓰는 비용을 줄이다

   1. TypeScript나 Python으로 시작해도 제품은 성공할 수 있지만, 언젠가는 다시 작성할 수 있다.
   2. agent와 제품을 한 codebase·한 언어에 모두 넣으면 구현이 느슨해지고 서로 얽히기 쉽다.
   3. 일단 얽히면 이후의 혁신과 재설계가 어려워진다.

2. Rust boundary가 제공한 구조적 이점

   1. Rust 경계는 핵심 실행 agent와 제품 계층을 분리하는 실질적인 scaffolding 역할을 했다.
   2. 이 경계 덕분에 agent를 독립적으로 개선하면서도 제품 계층을 계속 혁신할 수 있었다.
   3. 장기적으로 빠르게 변할 것을 알 때 좋은 abstraction과 명확한 경계가 속도의 적이 아니라 속도의 기반이 된다.

5. 오픈소스 Codex와 model optionality

5.1. coding agent를 스스로 개선하는 커뮤니티

1. agent가 자기 자신을 가리키게 하다

   1. Codex는 coding agent이므로, 사용자가 Codex를 Codex 자체의 codebase에 연결해 개선할 수 있다는 발상이 자연스러웠다.
   2. 커뮤니티 기여자가 agent를 사용해 agent를 개선하면, 팀은 실제 사용에서 나오는 문제와 아이디어를 더 많이 배울 수 있다.
   3. 코드 작성의 역할 자체가 바뀔 것이라면 그 변화의 커뮤니티에서 떨어져 있기보다 직접 참여하는 편이 낫다고 판단했다.
   4. 당시에는 좋은 harness의 정답을 모두 알고 있지 않았고, 모델 capability를 가장 유연하게 표현하는 방법도 탐색 중이었다.

2. 오픈소스의 실험 공간

   1. 기술적인 deep dive와 blog post를 공개해 “좋은 harness를 이렇게 생각한다”는 관점을 설명했다.
   2. 세상에는 매우 똑똑한 개발자가 많고, 다른 오픈소스 프로젝트에서 영감을 받을 수 있으므로 level playing field를 만드는 편이 유리했다.
   3. CLI뿐 아니라 SDK와 app server도 오픈소스로 공개해 사람들이 다양한 방식으로 tinkering하고 실험하도록 했다.

5.2. 공개 저장소의 이점과 비용

1. 팀과 커뮤니티가 얻는 이점

   1. 작은 저장소를 공개하면 지원자가 Codex 팀에 합류하기 전에 이미 repository와 PR을 살펴본다.
   2. 입사 뒤의 onboarding이 사실상 끝난 상태에서 질문과 기여를 시작할 수 있다.
   3. 실제 커뮤니티에 기여한다는 감각이 팀에 큰 에너지를 주며, “커뮤니티를 중요하게 생각한다”는 선언보다 실제 행동으로 증명할 수 있다.

2. 오픈소스가 부과하는 세금

   1. Codex 저장소는 OpenAI의 나머지 코드와 분리돼 있어, 여러 repository 사이에 인위적인 경계를 만들고 작업을 조율해야 한다.
   2. 공개 상태에서 개발하는 동안 경쟁자가 아직 출시하지 않은 기능을 복사해 먼저 내놓을 수 있다.
   3. 매우 허용적인(permissive) 라이선스를 택했으므로 복사를 막을 수 없고, 그 사실이 “조금 아프다”고 Tibo는 솔직히 말했다.
   4. 무관하거나 품질이 낮은 기여가 쓰나미처럼 몰려오며, 이를 읽고 분류하고 대응하는 추가 유지보수 세금도 생긴다.
   5. 그 비용을 해결할 자동화와 운영 방식을 만들게 된다는 점에서는 오픈소스의 압력이 긍정적인 forcing function이 되기도 한다.

5.3. 특정 모델에 묶지 않는 이유

1. 10줄짜리 fork를 양산하지 않다

   1. 뛰어난 coding harness를 만드는 일과 특정 모델을 쓰게 만드는 일은 별개라고 판단했다.
   2. 다른 모델 provider를 지원하는 데 10줄만 바꾸면 된다면, 사용자가 fork를 만들어야 할 이유를 제공하는 것은 어리석다.
   3. 처음부터 다른 모델을 지원하면 fork의 분열과 그에 따른 유지보수 overhead를 줄일 수 있다.

2. 사용자와 기업에 선택권을 주다

   1. 오늘 OpenAI 모델을 좋아하던 사용자가 내일 나온 새로운 모델을 시험하고 싶을 수 있다.
   2. 설정 전체를 버리고 다른 도구로 옮기게 하지 않으면, 팀은 다른 모델이 무엇을 잘하고 못하는지에 대한 feedback도 얻는다.
   3. 기업은 모델 provider와 실행 환경의 optionality를 원하므로, 같은 harness에서 여러 모델을 비교할 수 있어야 한다.
   4. Tibo의 표현대로 사용자를 lock-in으로 붙잡기보다 가장 좋은 모델, 가장 효율적인 모델, 가장 좋은 제품으로 이겨야 한다.
   5. 사용하는 모델과 관계없이 경험이 delightful해야 하며, merit로 선택받는 제품이 최고의 인재도 끌어들인다.

6. Codex의 실행 환경: 로컬 sandbox에서 클라우드로

6.1. 기본 로컬 실행의 안전 모델

1. 모든 도구 실행은 기본적으로 sandbox 안에서 일어나다

   1. 기본 설정에서 Codex는 사용자의 컴퓨터에서 실행되며, 모든 tool execution은 sandbox 안에 있다.
   2. sandbox 밖의 추가 권한이 필요한 명령을 실행하려면 사용자에게 permission을 요청한다.
   3. 로컬 실행은 1년 넘게 유지된 기본 동작이며, 로컬 PostgreSQL, SQLite, 서버, MCP 도구 같은 개인 환경에 바로 접근할 수 있다는 장점이 있다.

2. 로컬 실행의 현실적인 비용

   1. 여러 agent를 동시에 돌리면 CPU를 많이 사용한다.
   2. 노트북을 닫으면 실행 중인 작업을 계속할 수 없어, 사용자가 화면을 반쯤 열어둔 채 agent를 돌리는 상황도 생긴다.
   3. 인터뷰어는 AI 회사 사무실에서 노트북을 반쯤 열어둔 것을 보고 “agent를 돌리고 있느냐”는 말을 들었다고 농담했다.

6.2. 관리형 클라우드 실행과 미래의 혼합 모델

1. ChatGPT Work와 같은 관리형 VM

   1. 사용자가 선택하면 Codex는 로컬이 아니라 ChatGPT Work를 통해 제공되는 것과 같은 managed VM에서 실행된다.
   2. VM 안의 Kata container가 안전한 실행 환경을 제공하며, 코드와 도구는 그 안에서 작동한다.
   3. 사용자의 컴퓨터에서는 입력을 보내고 출력 스트림을 받는 일만 일어나므로 CPU를 아끼고 더 많은 agent를 확장할 수 있다.
   4. 인터넷이 연결된 강력한 VM에서 Blender를 설치해 3D 모델링을 하거나, 다른 모델을 훈련하는 등 창의적인 작업도 가능하다.

2. 로컬과 클라우드의 간극

   1. 로컬에는 사용자가 오랫동안 쌓은 DB, 서버, MCP 설정이 있어 클라우드로 옮기는 일이 번거롭다.
   2. 2022~2023년의 cloud development environment는 대규모 회사 밖에서 크게 확산되지 못했는데, 초기 구축 비용과 지속적인 유지보수 비용이 컸기 때문이다.
   3. agent가 환경을 이해하고 구성 파일을 생성·동기화할 수 있다면 초기 구축 및 유지보수 비용은 거의 사라진다.
   4. 로컬 SQLite나 서버, MCP가 있다면 “동일한 setup을 cloud dev box에 구성하고 계속 동기화하라”고 agent에게 시킬 수 있다.
   5. 따라서 완전히 클라우드에서 orchestrate되는 개발 머신이 다시 부상할 가능성이 크다.

3. 노트북에서 벗어나는 사용 경험

   1. Tibo는 ChatGPT Work에서 모바일로 작업을 시작하고, 커피를 마시며 걸어 다니면서 음성으로 여러 작업을 지시한다.
   2. calendar, email, Slack에 접근해 질문과 업무를 처리할 수 있으면 노트북을 계속 들고 다닐 필요가 없다.
   3. 앞으로는 일부 실행을 노트북에서, 일부를 클라우드에서 수행하는 혼합 방식이 자연스러워질 수 있다.
   4. 모델이 더 많은 compute와 리소스를 활용하게 되면 로컬 머신만으로 실행을 제한하는 것이 오히려 병목이 된다.

7. Harness와 모델의 공동 설계

7.1. Harness는 모델보다 한 발 앞선다

1. 모델에 crutch를 붙이는 계층

   1. 모델은 특정 능력을 가지고 있지만, harness는 그 능력을 사용자가 기대하는 신뢰성·효율성·행동 양식으로 끌어올린다.
   2. guardrail로 안전을 보장하고, 실행을 효율화하며, steerability와 controllability를 높이는 것이 harness의 역할이다.
   3. 매 turn의 시작에 developer message를 context에 주입해 agent의 목적과 행동을 조정한다.
   4. 사용자가 “변경 후 unit test를 실행하라”고 매번 상기해야 했던 초기에는 harness가 그 행동을 유도하는 crutch를 제공했다.

2. 다음 모델이 crutch를 흡수하다

   1. 더 나은 모델은 사용자의 진짜 의도를 더 잘 반영해, 별도의 reminder 없이 테스트를 실행한다.
   2. 그 결과 developer message가 짧아지고 harness 자체도 작아진다.
   3. Tibo는 harness가 모델보다 늘 조금 앞서 있으며, 모델이 capability를 흡수하면 그 보조 장치를 제거하는 순환이 일어난다고 설명했다.

7.2. 다음 버전의 우선순위를 정하는 방식

1. 모델 변경과 harness 변경을 구분하다

   1. 팀은 현재 잘하는 일과 못하는 일, 새 제품 기능으로 만들고 싶은 일을 먼저 확인한다.
   2. 문제가 harness로 해결될지, 모델의 학습으로 해결될지 결정한다.
   3. 모델 수정이라면 한 달, 세 달, 여섯 달 중 언제 가능한지와 어느 수준의 training이 필요한지를 판단한다.
   4. 모델이 곧 해결할 문제라면 10,000줄짜리 workaround를 harness에 추가하지 않고 기다리는 편이 낫다.

2. Research와 engineering의 co-design

   1. 연구팀과 core agent harness를 만드는 engineering 팀이 지속적으로 협업한다.
   2. 모델의 pre-training 및 전반적인 성능이 좋아지면 전체 capability가 함께 올라가지만, 특정 약점과 제품 요구에는 별도의 주의를 기울인다.
   3. 사용자가 coding뿐 아니라 finance, communications, marketing 등 여러 영역에서 agent를 쓰므로 모든 영역의 feedback을 분석한다.
   4. agent 자체를 사용해 feedback의 패턴과 theme을 묶고, 우선순위 대화를 준비하며, 무엇을 먼저 개선할지 정한다.

8. Codex 팀의 개발 방식과 north star

8.1. 새로 합류한 엔지니어가 가장 먼저 듣는 말

1. “Have you asked Codex?”

   1. Tibo는 신입에게 훌륭한 사람을 소개한 뒤, 질문이 생길 때 가장 많이 듣는 말이 “Codex에게 물어봤나?”라고 설명했다.
   2. OpenAI 내부 Codex는 Slack, 문서, code에 연결돼 있어 프로젝트의 현재 상태, 담당자, 결정이 내려진 이유를 파악할 수 있다.
   3. 새로 온 사람도 문서와 대화를 agent에게 읽히면 조직의 맥락을 빠르게 이해하고 첫 기여를 만들 수 있다.

2. 공개된 맥락을 조직의 기반으로 만들다

   1. 팀은 가능한 한 public channel에서 일한다.
   2. 문서도 넓은 권한으로 열어 여러 사람이 읽게 하며, agent가 정보를 검색하고 추론하기 쉬운 상태를 만든다.
   3. 팀 생산성과 협업을 위한 추가 기능도 준비 중이며, 일부는 Dev Day에서 공개될 예정이라고 언급했다.
   4. 핵심 원칙은 사용자, 제품 전체의 coherence, 모델의 방향을 돌보는 것이다.

8.2. 아이디어를 PR로 만들고 배포하는 과정

1. 전통적인 개발 과정과 닮았지만 더 빠르다

   1. 엔지니어는 아이디어를 Codex와 동료에게 설명하고, Codex로 구현·테스트한 뒤 변경을 제안한다.
   2. Codex에 배포되는 변경과 ChatGPT에 배포되는 변경의 기본 과정은 놀라울 정도로 비슷하다.
   3. Codex는 약 2,000만 active user를 넘겼고 ChatGPT는 10억 명 규모로 성장했지만, 큰 변경도 당일 또는 다음 날 배포할 수 있다.
   4. 엔지니어가 큰 변경을 시도할 수 있도록 권한을 주되, 사용자에게 잘 받아들여질 증거, 가치 있는 추가라는 증거, 장기 유지 가능성에 대한 근거를 요구한다.

2. 반복적인 품질 관리를 자동화하다

   1. code review, deploy, regression detection 같은 과정은 가능한 한 자동화한다.
   2. 엔지니어는 기계적인 검증에 모든 주의를 쓰기보다 아이디어와 사용자에게 주는 가치, 제품의 coherence에 집중한다.
   3. 유지보수 비용이 크게 내려갔기 때문에 예전처럼 모든 변경에 긴 승인 의식을 부과할 필요도 줄었다.

3. Personal AGI라는 north star

   1. 장기 방향은 사용하기 쉽고 delightful한 개인용 AGI다.
   2. 개인에게 필요한 지식과 리소스에 접근하고, 일정과 목표를 이해하며, 때로는 사용자를 대신해 위험한 행동을 수행하되 push notification으로 확인하게 해야 한다.
   3. 자연어와 음성으로 제어할 수 있고, 감정이나 camera feed까지 이해할 수 있는 매우 자연스러운 시스템을 상상한다.
   4. AGI는 10개의 버튼과 복잡한 설정이 있는 제품이 아니라 단순하고 자연스럽게 써야 한다.

9. 코드 리뷰의 전환: 줄 단위 검증에서 의도·계약 검토로

9.1. 모델이 인간보다 깊이 보는 correctness와 security

1. 초기 code review model의 목표

   1. Tibo가 Codex에서 맡은 초기 프로젝트 중 하나는 research 팀과 code review model을 개발하는 일이었다.
   2. 목표는 사람이 여러 시간을 들여야 찾을 수 있는 논리·추론 오류를 agent가 찾아내는 수준이었다.
   3. dependency를 세네 단계 깊게 따라가고, 문서가 틀렸거나 third-party 구현이 예상과 다른지 확인하며, 그 때문에 invariant가 깨지는지 판단해야 했다.
   4. 해당 라이브러리의 전문가가 아니면 놓치기 쉬운 버그까지 잡아내는 것이 목표였다.

2. Mainline 모델에 capability가 흡수되다

   1. 초기 review 모델의 깊은 검증 능력은 이후 mainline 모델에 포함됐다.
   2. Tibo는 benchmark에서 모델의 code review 및 reasoning이 superhuman 수준이라고 말했다.
   3. correctness뿐 아니라 security에서도 복잡한 맥락을 가로질러 critical vulnerability를 찾아낼 수 있다.
   4. OpenAI에서는 자동 review가 security issue를 표시하면 pull request가 merge되지 않도록 막는 것이 필수 절차가 됐다.

9.2. 인간 리뷰의 남은 가치

1. 기계에 넘길 수 있는 영역

   1. 로직 오류, dependency의 실제 동작, 테스트 누락, invariant 위반, 보안 취약점처럼 깊은 검증이 필요한 영역은 agent가 더 빠르고 일관되게 처리한다.
   2. 단순히 “코드가 동작하는가”를 줄 단위로 확인하는 일은 점점 자동화된다.
   3. agent가 만들어내는 코드 양이 급증하면 모든 줄을 사람이 읽는 방식은 확장되지 않는다.

2. 사람이 계속 맡아야 할 영역

   1. code review는 correctness 외에도 정보 교환, 지식 공유, 다른 사람이 맥락을 배우는 사회적 의식이었다.
   2. 그러나 때로는 바쁜 reviewer가 PR을 보지 않아 작업이 막히고, 서로 context switch를 반복하는 고통스러운 의식이 되기도 했다.
   3. 앞으로 핵심 토론은 “무엇을 하려는가, 그 의도가 사용자에게 옳은가”로 이동해야 한다.
   4. 코드를 merge하기 전 설계와 intent를 논의하면, 구현된 코드의 모든 줄을 놓고 토론할 필요가 줄어든다.

9.3. Box, contract, invariant

1. 먼저 합의할 바깥 상자

   1. 하나의 컴포넌트를 box로 보고, 그 box가 무엇을 하는지와 외부에 보이는 계약(contract)을 합의한다.
   2. resource utilization, data access, security 등 반드시 지켜야 하는 invariant를 엄격히 보장한다.

2. 상자 안의 구현은 자유롭게 바꾸다

   1. box의 계약과 불변조건이 보장되면 내부가 어떤 구현인지 매번 사람이 논의할 필요가 없다.
   2. agent가 내부를 재작성하고 최적화하거나 구조를 바꿔도 외부 영향이 계약 안에 머무르면 된다.
   3. 인간의 주의력은 구현의 세부사항보다 box의 목적과 invariant를 설계하는 대화에 쓰는 편이 가치 있다.

10. 유지보수와 재아키텍처의 비용이 급격히 내려가다

10.1. Maintenance tax를 자동화하다

1. 반복적인 유지보수 작업

   1. 유지보수는 시스템을 계속 운영하기 위해 시간이 지나며 지불하는 세금이다.
   2. third-party dependency의 버전 번호를 올리는 일은 changelog와 문서가 있고 코드가 잘 구조화돼 있다면 agent가 완전히 자동화할 수 있다.
   3. 과거에는 재미없어서 미루던 dependency upgrade도 보안 패치를 위해 반드시 해야 하는 업무였다.
   4. agent는 codebase 전체를 훑고 몇 시간 안에 변경을 적용할 수 있어 유지보수의 큰 부분이 사실상 공짜가 된다.

2. 재아키텍처를 두려워하지 않게 되다

   1. 새로운 trade-off나 workload, 기능을 맞추기 위해 시스템 전체를 재아키텍처하는 일은 과거 여러 해가 걸릴 수 있는 큰 투자였다.
   2. 모델과 agent를 사용하면 실수의 비용과 재작성 비용이 모두 낮아지고, 예전보다 훨씬 빠르게 새 구조를 실험할 수 있다.
   3. 다만 좋은 abstraction과 명확한 경계가 여전히 중요하다.
   4. box와 invariant를 올바르게 그려두면 내부를 신속하게 바꾸면서 다른 서비스와 인프라에 영향을 주지 않을 수 있다.

10.2. 아키텍처를 모든 엔지니어의 책임으로 만들다

1. 모듈성과 병렬 기여

   1. 인터뷰어는 OpenClaw를 만든 Peter Steinberger가 코드를 줄마다 읽지 않더라도 전체 architecture를 머릿속에 두고, 100명이 서로 발을 밟지 않고 기여하도록 모듈화한다고 회고했다.
   2. Tibo의 설명도 같은 방향이다. agent가 장기 유지보수 부담과 미래의 기능 확장을 판단하므로, 구조 설계는 소수의 architect만의 일이 아니다.

2. 모델도 장기 구조를 판단하기 시작하다

   1. GPT 계열 모델은 파일 하나의 code quality뿐 아니라 장기 유지보수 부담을 줄이는 architecture인지 점점 더 잘 판단한다.
   2. 향후 기능 확장과 trade-off를 위한 공간을 남기는지까지 고려하는 것이 모델의 다음 자연스러운 능력이다.
   3. 따라서 모든 엔지니어가 코드를 만들 때 현재 구현뿐 아니라 이후의 변경 속도와 영향 범위를 생각해야 한다.

10.3. 에이전트 시대의 압축된 생애주기

1. 수년에 걸친 성장 곡선이 주말에 압축되다

   1. 과거에는 한두 명으로 시작한 시스템이 성공하면 1년 뒤 50명 또는 100명의 엔지니어로 커질 것을 미리 볼 시간이 있었다.
   2. 문서화하고 사람을 onboard하며 architecture를 다듬을 시간도 그만큼 있었다.
   3. 이제는 agent 100개가 한 주말에 동시에 기여하면서 시스템이 갑자기 폭발적으로 커질 수 있다.
   4. 짧은 시간 안에 더 많은 코드를 만들 수 있는 만큼 구조·계약·유지보수 설계의 중요성도 함께 커진다.

2. 개발자의 craft가 사라지는 대신 이동하다

   1. Tibo는 Vim에서 늦은 밤 Coke Zero를 마시며 문제에만 몰입해 코드를 짜던 기억을 여전히 좋아한다.
   2. 하지만 세 시간 동안 refactor하다가 막다른 길임을 깨닫고 처음부터 다시 시작하거나, 코드가 컴파일되지 않아 새벽까지 씨름하는 일도 있었다.
   3. agent는 “작동하거나 실패했다는 증거가 있는 상태”까지 일을 진행해 이런 미완성 상태의 정신적 부담을 줄인다.
   4. 30초 안에 benchmark를 실행하고 수치를 얻어 trade-off를 판단할 수 있으므로, 코드 자체를 쓰는 craft보다 문제를 잘 고르고 결과를 검증하는 craft가 중요해진다.

3. 문제가 고갈되지 않는 조직

   1. OpenAI에는 수학적·과학적 breakthrough, 세상의 중요한 문제, 인간을 위한 제품이라는 해결 과제가 아직 매우 많이 남아 있다.
   2. 도구가 엔지니어를 더 효율적으로 만들어도 해결해야 할 문제가 줄어들지 않으므로, 작업이 사라지기보다 더 야심 찬 문제로 이동한다.
   3. OpenAI는 더 효율적인 inference와 compute 활용으로 같은 자원에서 더 많은 문제를 풀고 이를 세계에 배포하려 한다.

10.4. 장시간 작업과 /goal

1. 하룻밤 동안 질문을 맡기다

   1. Tibo는 낮에 떠오른 큰 질문이나 대화 중 생긴 궁금증을 Codex에 보내 밤새 조사하게 한다.
   2. 아침에 결과를 확인하는 일이 항상 기대되는 일과가 됐다.
   3. 작업이 끝났거나 실패했다는 증거를 얻을 수 있어, 사람이 중간 상태를 계속 붙잡고 있을 필요가 줄어든다.

2. 하나의 목표에 오래 머무르게 하는 harness

   1. /goal 명령은 agent가 장시간 하나의 목표에서 이탈하지 않도록 만든 harness 장치였다.
   2. 아주 어려운 문제라면 며칠 또는 몇 주 동안 작업하도록 유지하는 데 필요했다.
   3. 최신 세대 모델은 별도 /goal crutch 없이 “일주일 동안 작업하라”고 말해도 실제로 그 목표를 수행할 수 있는 방향으로 발전하고 있다.

11. ChatGPT와 Codex의 merge

11.1. 서로 다른 실행 스택을 하나의 제품으로 만들다

1. 로컬 Codex와 관리형 ChatGPT의 차이

   1. Codex는 완전히 local에서 실행되며 사용자의 환경과 상호작용하는 coding agent였다.
   2. ChatGPT는 OpenAI가 관리하는 cloud-based stack에서 실행되고 상태·컴퓨트·효율을 전통적인 방식으로 관리했다.
   3. merge의 핵심은 로컬 agent의 능력을 클라우드에서 재현하고, 훨씬 더 넓은 사용자에게 제공하는 일이었다.

2. 대규모 사용자와 $20 플랜의 제약

   1. cloud Codex는 ChatGPT Work의 강력한 managed VM 안에서 full Codex harness와 함께 동작한다.
   2. 이를 수천만 명, 수억 명에게 효율적으로 제공해야 했고, ChatGPT Plus의 월 20달러 요금 안에 포함할 수 있을 만큼 실행 비용을 낮춰야 했다.
   3. 강력한 VM과 인터넷 접근 덕분에 Blender 설치·3D 모델링·모델 훈련 같은 실험까지 가능해졌다.

11.2. 통합 과정의 시스템 문제

1. 플러그인·라이브러리·아키텍처를 합치다

   1. Codex와 ChatGPT 사이의 작은 동작 차이를 해소해야 했다.
   2. plugin architecture와 library를 합치고, 두 제품에서 가능한 일이 서로 달라지지 않도록 공통 시스템을 지향했다.
   3. 목표는 Codex에서 되는 일이 ChatGPT에서 안 되거나 그 반대인 상황을 없애고, 같은 intelligence에 사용자가 원하는 인터페이스로 접근하게 만드는 것이다.

2. Codex를 사용해 Codex를 합치다

   1. Codex는 merge에 필요한 infrastructure를 살펴보고 만들며, 두 시스템의 미세한 차이를 해결하는 데 직접 사용됐다.
   2. 팀이 나눈 Slack 대화와 문서를 읽으며 단계·논쟁·결정의 기록을 만들었다.
   3. 무엇을 무엇으로 merge할지, 이름을 어떻게 정할지, work toggle을 언제 도입할지에 대해 여러 permutation이 오갔다.
   4. 이 기록 방식은 Codex가 프로젝트의 “기자(journalist)”가 되어 토론을 정리하는 것처럼 작동했다.

11.3. Toggle arc와 완전한 통합의 방향

1. Work toggle이 임시 상태가 되다

   1. ChatGPT 안에 Codex의 강력한 작업 모드를 제공하기 위해 work toggle을 도입했다.
   2. 팀 안에서도 toggle이 올바른 제품 경험인지에 대한 논쟁이 많았지만, 사용하면서 점차 이 방식을 좋아하게 됐다.
   3. 외부에서는 이를 OpenAI의 “toggle arc”라고 부를 정도로 merge의 상징이 됐다.

2. 하나의 통합 제품으로 수렴하다

   1. work mode와 일반 ChatGPT 사이에 capability 차이가 있는 현재 상태는 과도기다.
   2. 시간이 지나면 Codex의 능력을 ChatGPT를 사용하는 모든 사람에게 더 깊게 가져가 완전히 통합할 계획이다.
   3. 이 merge와 사용성 개선이 Codex active user 증가 속도를 크게 끌어올렸다.

12. Tibo의 실제 사용 방식

12.1. 모바일·음성·맞춤 지시로 개인 agent를 만들다

1. 회의 사이의 질문을 바로 위임하다

   1. Tibo는 ChatGPT Work를 모바일에서 사용하며, 떠오른 질문을 나중에 적어두기보다 음성 dictation으로 즉시 보낸다.
   2. 회의와 회의 사이에 agent가 답을 조사하게 하고, 돌아와 report를 읽는다.
   3. 자신의 업무 방식에 맞는 custom skill과 custom instruction을 설정해 report, slide deck, code exploration을 원하는 형식으로 받는다.

2. 조직 지식을 실행 가능한 답으로 바꾸다

   1. Slack, Notion, Google Docs에 공개된 대화와 문서가 많기 때문에 agent는 팀의 맥락을 읽을 수 있다.
   2. 특정 기능에 대한 대중의 반응, production log에서의 사용량, traction이 없는 기능의 deprecation 후보를 물을 수 있다.
   3. 특정 팀이 무엇을 하는지, 어떤 결정이 왜 내려졌는지 등 거의 모든 질문에 30분 안에 첫 답을 받을 수 있다.

12.2. 주말 prototype과 실행 속도

1. 아이디어를 하루 만에 외부화하다

   1. 주말에는 제품의 미래를 상상하며 다른 팀원과 code exploration이나 prototype을 만든다.
   2. 아침에 “이것을 만들어 보면 어떨까”라고 생각한 내용을 Codex로 표현해 하루 안에 사람들 앞에 내놓는다.
   3. 반드시 출시하려는 것이 아니라, 아이디어를 머릿속에서 꺼내 동료가 비판하고 영감을 얻도록 만드는 것이 목적이다.

2. 생산성의 의미가 바뀌다

   1. Tibo는 calendar가 Tetris처럼 꽉 차 있어도 기술 덕분에 훨씬 많은 일을 할 수 있다고 말했다.
   2. 개발자의 역할은 모든 산출물을 직접 입력하는 것보다 문제를 선택하고, 질문을 정교하게 만들고, 결과를 비판하는 쪽으로 이동한다.

13. 엔지니어가 AI 시대에 갖춰야 할 능력

13.1. 깊은 호기심과 빠른 시스템 이해

1. 새 codebase와 시스템을 빠르게 파악하다

   1. OpenAI에서 뛰어난 사람은 작동 원리를 깊이 궁금해하고, 새로운 시스템을 빠르게 흡수하며, 낯선 codebase의 구조를 재빨리 파악한다.
   2. agent는 정보의 양을 감당하고 첫 탐색을 가속하지만, 무엇을 물을지 결정하는 사람의 호기심을 대체하지 못한다.

2. Five Ws를 반복하다

   1. “왜 이런가, 무엇이 일어나는가, 누가·언제·어디서 관여하는가”를 계속 질문한다.
   2. 한 번 답을 얻는 것으로 멈추지 않고 더 깊이 파고들면 agent와 함께 매우 빠르게 학습할 수 있다.
   3. 도구를 잘 사용하는 능력은 시스템을 이해하려는 태도 위에 세워져야 한다.

13.2. 커뮤니티와 의도에 연결되다

1. 문제를 풀 사람을 정확히 이해하다

   1. 해결하려는 사람들의 community와 계속 연결돼 있어야 한다.
   2. 모든 문제가 즉시 드러난 직접적인 문제는 아니며, 다른 그룹을 위한 기반을 만드는 과정에서 인간 전체에 유용한 문제를 풀 때도 있다.
   3. 그래도 누구의 어떤 요구를 위해 만드는지, 사용자의 taste와 필요가 무엇인지 명료하게 알아야 한다.

2. 명료한 의도와 기술적 기본기를 유지하다

   1. 무엇을 달성하려는지 설명할 수 없고, 그 의도와 community의 연결이 없으며, 좋은 설계에 대한 taste가 없다면 훌륭한 결과를 내기 어렵다.
   2. Tibo의 조언은 “도구만 잘 쓰라”가 아니라 curiosity, fundamentals, clarity of thought, 사용자 감각을 agent와 결합하라는 것이다.

주요 발언 모음

“Have you asked Codex?” — 새로 합류한 사람이 질문을 가졌을 때 가장 먼저 듣는 말이다.

“유지보수는 일을 계속 굴러가게 하려고 시간이 지나며 내는 세금과 같다.”

“Harness는 모델에 몇 가지 crutch를 붙여 모델이 실제로 일을 하게 만드는 역할을 한다.”

“사용자를 lock-in으로 이기고 싶지 않다. merit로 이기고 싶다.”

“상자(box)의 계약과 invariant를 엄격히 보장한다면, 상자 안에서 일어나는 일은 말 그대로 무엇이든 될 수 있다.”

“우리는 당분간 해결할 문제가 고갈되지 않을 것이다.”

“AGI는 사용하기 단순해야 한다.”

“오픈소스로 만들면 출시 전에 누군가가 복사할 수 있고, 그건 조금 아프다. 하지만 오픈으로 짓는다는 계약의 일부다.”

“모델이 더 많은 compute와 리소스를 쓸 수 있게 되면 로컬 머신에만 실행을 제한하는 것은 결국 제약이 된다.”

“정말 좋은 일을 하려면 무엇을 이루려는지, 그 의도가 무엇인지, 누구를 위한 것인지 명확하게 설명할 수 있어야 한다.”

핵심 데이터 & 수치

• 약 200명: Tibo가 어린 시절 이사한 마을의 대략적인 인구다.
• 8세: 컴퓨터와 초기 인터넷에 깊이 빠지기 시작한 시기다.
• 2015년: Google London에 합류한 시점이다.
• 약 2년: 모바일 웹 성능 프로젝트에 참여한 기간이며, 프로젝트는 수백 명 사용자만 남긴 채 취소됐다.
• 약 20명: 당시 ChatGPT를 운영한다고 들은 OpenAI 엔지니어 수로, 작은 팀의 자율성에 깊은 인상을 줬다.
• 약 1개월: OpenAI 합류 뒤 reasoning 모델 작업을 시작해 o1·o1-preview 공개를 경험하기까지의 맥락이다.
• 2,000만 명 이상: 인터뷰 시점에 Codex가 넘겼다고 언급된 active user 규모다.
• 10억 명 이상: ChatGPT의 사용자 규모를 설명하며 언급된 수치다.
• 월 20달러: ChatGPT Plus에 cloud Codex를 포함하기 위해 고려해야 한 비용 제약이다.
• 3~4단계: code review model이 dependency와 구현의 차이를 깊이 추적해야 하는 예시다.
• 30분 이내: Tibo가 조직의 거의 모든 질문에 Codex로 첫 답을 얻는 데 걸리는 시간이다.
• 30초: agent를 백그라운드에 띄워 benchmark를 실행하고 수치를 확인할 수 있는 예시 시간이다.
• 100개 agent / 주말: 전통적인 수년짜리 시스템 확장이 에이전트 시대에는 한 주말에 일어날 수 있다는 비유다.
• 10,000줄: 모델 결함을 장기 workaround로 감싸는 잘못된 접근의 과장된 예시다.
• 며칠~몇 주: 과거 /goal harness가 하나의 어려운 목표를 유지하도록 상정한 장시간 실행 범위다.

광고 세그먼트에서 언급된 도구

Turbopuffer

1. object storage를 상태 저장소로 사용하고 NVMe SSD·memory cache를 compute 계층으로 사용하는 hybrid search engine으로 소개됐다.
2. namespace는 database table, search index, S3 prefix와 비슷한 단위이며, 질의가 없을 때는 저렴한 object storage에 머물러 compute 비용이 없다.
3. 활성 namespace만 hot cache tier로 올리므로 수억 개 namespace와 namespace당 수억 개 문서를 구성 변경 없이 다룰 수 있다는 설명이 나왔다.

Entire

1. agent가 병렬로 더 많은 코드를 push하면서 Git이 병목이 되는 문제를 해결하려고 만들어진 Git hosting 서비스로 소개됐다.
2. GitHub의 마지막 Czar가 만들었고, 공개 수치로 초당 418 push와 경쟁사 대비 최대 89배 빠른 성능을 제시했다.
3. GitHub를 버리지 않고 repository를 mirror할 수 있으며, agent의 prompt history를 repository와 함께 기록하고 UI에서 확인할 수 있다.

Antithesis

1. code review만으로 잡기 어려운 버그를 찾기 위해 전체 시스템을 hostile simulation 안에서 실행한다.
2. targeted testing과 fuzz testing을 함께 수행하며, deterministic simulation으로 모든 이슈의 재현 절차를 제공한다.
3. Jane Street, Fly.io, TSC community 등이 agent가 작성한 코드의 검증에 사용한다고 소개됐다.

결론 및 시사점

1. Codex의 핵심 경쟁력은 모델 자체만이 아니라 모델을 안전한 도구 실행, 맥락, 사용자 경험으로 묶는 harness에 있다.
2. 모델과 제품 계층을 분리하고 Rust boundary를 둔 선택은 단기 언어 분포보다 장기 정확성·보안·효율·혁신 가능성을 우선한 결정이다.
3. 오픈소스 공개는 onboarding과 커뮤니티 학습을 빠르게 하지만 저장소 경계, 낮은 품질 기여, 경쟁자의 선행 복사라는 비용을 동반한다.
4. 다른 모델을 지원하는 것은 사용자를 잠그지 않고 merit로 경쟁하며 기업에 optionality를 제공하는 전략이다.
5. 로컬 sandbox는 개인의 개발 환경과 자원을 활용하고, managed cloud VM은 노트북에서 벗어난 장시간·대규모 실행을 가능하게 한다.
6. harness의 crutch와 developer message는 모델이 능력을 흡수할수록 줄어들지만, 모델이 사용할 도구·프로토콜·경계 설계는 계속 중요하다.
7. 코드 리뷰는 correctness와 security의 줄 단위 검증에서 intent, contract, resource·data·security invariant를 합의하는 설계 대화로 이동한다.
8. dependency upgrade, 보안 패치, 테스트, 재아키텍처가 자동화되면서 maintenance tax와 실수의 비용이 내려간다.
9. 그 대신 agent가 주말에 100개 단위로 기여할 수 있으므로 모듈성·abstraction·문서·계약을 처음부터 설계해야 한다.
10. 엔지니어의 craft는 코드 타이핑량보다 문제 선택, 질문의 깊이, 결과 검증, 사용자 의도에 대한 감각으로 이동한다.
11. ChatGPT와 Codex의 merge는 로컬 agent와 클라우드 stack을 합쳐 같은 intelligence를 여러 인터페이스로 제공하는 과정이다.
12. 개인용 AGI의 north star는 사용자의 맥락을 알고 필요한 리소스에 접근하며 자연어·음성으로 단순하게 통제되는 시스템이다.
13. 가장 강한 엔지니어는 깊은 호기심으로 새로운 시스템을 빠르게 이해하고, agent를 이용해 더 많은 질문과 실험을 수행한다.
14. 기술적 기본기는 사라지지 않으며, 명확한 의도·좋은 taste·커뮤니티와의 연결이 agent 시대에도 탁월한 결과의 조건으로 남는다.

핵심 요약 (20줄)

1. Tibo Sottiaux는 브뤼셀에서 인구 약 200명의 마을로 이사한 뒤 여덟 살부터 컴퓨터와 초기 인터넷으로 세상을 배웠다.

2. 응용수학을 공부한 Tibo는 임상시험 의약품 공급망, 철강 산업, 유럽 전력망의 최적화 문제를 전통적인 수학 기법으로 풀었다.

3. Google의 모바일 웹 성능 프로젝트는 약 2년 뒤 수백 명의 사용자만 남긴 채 취소됐고 product-market fit과 feedback loop의 중요성을 남겼다.

4. Tibo는 Google Maps에서 리뷰를 다룬 뒤 AlphaGo의 초기 분위기가 있던 DeepMind에서 연구 인프라와 연구 도구를 만들었다.

5. DeepMind의 별도 LLM 그룹은 ChatGPT보다 약 1년 앞서 내부 대화형 봇을 만들었고, 초기 모델은 서툴렀지만 구성원 사이에서 빠르게 퍼졌다.

6. Tibo는 연구와 제품을 직접 연결해 세계에 영향을 주는 미션을 찾아 OpenAI에 합류했고, 한 달 뒤 o1-preview 공개를 경험했다.

7. Codex의 전신은 OpenAI Python codebase와 아키텍처·코드 스타일을 학습해 연구자의 개발을 가속하던 내부 모델과 작은 agent였다.

8. Rust는 제품 인터페이스와 핵심 agent를 분리하고 정확성·보안·효율·확장성을 확보하기 위한 경계로 선택됐다.

9. Codex를 오픈소스로 공개하면 agent가 자기 codebase를 개선하고 커뮤니티의 아이디어를 흡수할 수 있지만 복사와 낮은 품질 기여라는 비용도 생긴다.

10. 특정 모델에 Codex를 묶지 않는 전략은 사용자의 선택권과 기업의 optionality를 보장하고 lock-in 대신 merit로 경쟁하려는 원칙에서 나왔다.

11. 로컬 Codex는 sandbox 안에서 실행되고 권한이 필요한 작업만 사용자에게 묻기 때문에 개인의 DB와 도구를 안전하게 활용할 수 있다.

12. managed cloud VM은 노트북의 CPU와 열린 화면에 대한 의존을 줄이고 장시간 실행과 대규모 병렬 agent 작업을 가능하게 한다.

13. Harness는 guardrail, 도구, developer message라는 crutch로 모델을 보조하며 모델이 능력을 학습하면 그 보조 계층을 줄인다.

14. Codex 팀은 연구와 engineering을 함께 설계하고 여러 도메인의 feedback을 agent로 분석해 harness와 모델의 개선 우선순위를 정한다.

15. OpenAI의 신입 엔지니어는 Slack·문서·코드에 연결된 Codex에게 프로젝트의 상태와 결정 배경을 물으며 조직에 빠르게 온board한다.

16. 코드 리뷰는 논리·dependency·보안 오류를 자동으로 잡는 방향으로 이동하고 인간은 intent, 계약, 불변조건을 논의하는 데 집중한다.

17. 의존성 업그레이드와 보안 패치, 재아키텍처가 agent로 빨라지면서 유지보수 세금과 실수의 비용이 함께 내려간다.

18. agent 100개가 한 주말에 시스템에 기여할 수 있으므로 모듈성, 명확한 abstraction, 문서화, 장기 architecture 설계가 더 중요해진다.

19. ChatGPT와 Codex의 merge는 서로 다른 로컬·클라우드 스택을 통합해 수천만 명 이상의 사용자에게 같은 intelligence를 제공하는 작업이었다.

20. AI 시대의 뛰어난 엔지니어는 깊은 호기심, 빠른 시스템 이해, 명확한 의도, 사용자 커뮤니티에 대한 감각을 agent와 결합한다.