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

URL: https://www.youtube.com/watch?v=sLSTM9znQNs 날짜: 2026-09-15 (원본 게시일: 2026-09-09) 채널: The Pragmatic Engineer 출연: Tibo Sottiaux, Gergely Orosz 영상 길이: 1시간 14분 22초

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Codex의 핵심은 모델 자체가 아니라, 모델이 실제 세계의 복잡한 일을 안정적으로 수행하도록 만드는 하네스(harness)·도구·실행 환경·피드백 루프의 공동 설계에 있다.==

• Codex는 OpenAI 내부 연구자들의 생산성을 높이려던 작은 에이전트 실험에서 출발해 공개 제품과 ChatGPT의 클라우드 기능으로 확장됐다.
• Rust, 오픈소스, 모델 비종속성은 당장의 편의보다 정확성·보안·효율성·커뮤니티 참여·장기적 선택권을 우선한 결정이었다.
• 모델이 더 강해질수록 하네스의 ‘목발(crutch)’은 줄어들지만, 도구·프로토콜·계약·아키텍처처럼 모델이 사용할 기반은 오히려 더 중요해진다.
• 코드 리뷰와 유지보수의 기계적 부분은 자동화되며, 사람은 구현 세부보다 의도·경계·불변조건(invariant)·제품의 일관성을 합의하는 데 집중하게 된다.

이 대화는 Tibo의 성장 배경부터 Codex의 탄생, 오픈소스 운영, 로컬/클라우드 실행, 모델과 하네스의 공동 개발, 코드 리뷰와 유지보수의 변화, ChatGPT와의 통합, 엔지니어가 갖춰야 할 역량까지 시간순으로 따라간다. 핵심 메시지는 “코드는 목적이 아니라 문제를 해결하기 위한 도구이며, 에이전트가 코드를 더 많이 만들수록 좋은 경계와 명확한 의도, 빠른 학습 능력이 더 중요해진다”는 것이다.

1. Tibo Sottiaux가 Codex에 도달한 경로

Tibo의 경력은 응용수학으로 현실의 최적화 문제를 풀고, 연구자와 엔지니어가 더 빠르게 일하도록 도구를 만드는 방향으로 일관되게 이어졌다.

1.1. 어린 시절과 응용수학 창업

1. 컴퓨터에 빠져든 계기

   1. Tibo는 브뤼셀에서 태어났지만 부모가 인구 약 200명의 작은 마을로 이사하면서 어린 시절 대부분을 외부 친구나 활동 없이 보냈다.
   2. 당시 약 8살이었던 그는 주변에 이야기할 사람이 많지 않았기 때문에 초기 인터넷과 컴퓨터를 통해 세상을 배우기 시작했다.
   3. 그는 농담처럼 “부모가 아무것도 없는 곳으로 이사했기 때문에 컴퓨터에 관심을 가질 수밖에 없었다”고 회고했다.

2. 응용수학으로 현실 문제를 풀다

   1. 대학에서는 응용수학(applied mathematics)을 공부했고, 일찍 입학하고 일찍 졸업했다.
   2. 학업 중 은행을 위한 소규모 컨설팅과 회사를 운영하며 공급망과 응용수학 문제를 다뤘다.
   3. 졸업 후 창업한 회사는 임상시험용 의약품 공급망을 최적화했다. 어떤 약을 더 생산할지, 어디로 보내고 언제 배분할지 결정해 폐기물을 줄이고 임상시험을 효율화하는 문제였다.
   4. 해법은 당시의 전통적 최적화 기법, Monte Carlo 시뮬레이션, 확률적 다단계 최적화(stochastic multi-stage optimization)였다.
   5. 같은 접근을 철강 산업과 유럽 전력망에도 적용했다. 공통점은 문제의 형태가 최적화라면 산업과 무관하게 수학을 적용할 수 있다는 점이었다.

1.2. Google과 DeepMind에서 얻은 교훈

1. Google에서 웹 성능 프로젝트를 경험하다

   1. 2015년 Google 런던에 합류했을 때 처음 맡은 일은 Google Maps가 아니라 모바일에서 웹사이트를 더 빠르게 만드는 프로젝트였다.
   2. 데스크톱에서 모바일로 트래픽이 옮겨가던 시기에 광고 매출의 변화를 상쇄하고 모바일 경험을 개선하려던 소규모 프로젝트였다.
   3. 약 2년간 가장 재미있게 어려운 기술 문제를 풀었지만, 제품-시장 적합성(product-market fit)이 없고 사용자가 너무 적어 프로젝트가 취소됐다.
   4. 캘리포니아에서 온 VP가 사용자 수가 수백 명에 불과해 Google 규모에 맞지 않는다고 설명하며 프로젝트 종료를 통보했고, 팀원들은 놀랐다.
   5. Tibo가 얻은 교훈은 기술적으로 재미있는 문제를 푸는 것만으로는 부족하며, 실제 영향·사용자 피드백·전체 프로젝트의 중요성을 계속 검증해야 한다는 것이었다.

2. Google Maps와 DeepMind로 이동하다

   1. 이후 Google Maps에서 리뷰 관련 업무를 맡았고, 약 1년 뒤 런던의 DeepMind가 AlphaGo와 초기 연구로 어려운 문제를 푸는 모습에 이끌렸다.
   2. DeepMind에서는 연구 인프라와 연구 도구를 만들었다. 다른 연구자가 더 빠르고 효과적으로 일하게 만드는 도구를 만든다는 주제는 이후 거의 10년 동안 이어졌다.
   3. Tibo는 이 경험을 “다른 사람의 생산성을 높이고 새로운 일을 가능하게 하는 제품과 기반을 만든다”는 자신의 작업 방식으로 설명했다.

1.3. ChatGPT보다 앞서 만든 내부 대화형 모델

1. 대규모 언어 모델을 연구자에게 보여주는 인터페이스

   1. DeepMind 내부에서는 Brain과 별개로 대규모 언어 모델을 밀어붙이는 그룹이 있었고, 텍스트 코퍼스의 규모를 최대화하면 일반지능에 도달할 수 있는지 논쟁이 벌어졌다.
   2. Tibo는 연구자들이 모델의 입력과 출력을 확인하고 디버깅하도록 도구를 만들다가 자연스럽게 대화형 시스템을 구축했다.
   3. 초기 모델은 일관성이 낮고 다소 우스꽝스러웠지만, 사람들이 내부 대화를 캡처해 공유할 정도로 흥미로웠다.
   4. 단순한 연구 도구가 아니라 외부 제품으로 만들자는 움직임이 생겼지만, DeepMind에는 제품을 빠르게 출시할 조직과 운영 체계가 부족했다.
   5. Google의 생산 스택은 수년간 최적화된 만큼 안정적이었지만, 새로운 제품을 실제로 출시하며 혁신하기에는 절차가 무거웠다.

2. OpenAI로 옮긴 이유

   1. Tibo는 Google과 DeepMind에서 편안하게 지낼 수 있었지만, 세상에 긍정적이고 직접적인 영향을 주는 미션과 그 미션을 진심으로 믿는 사람들과 일하고 싶었다.
   2. 연구와 제품이 분리되지 않고 함께 설계되는 환경을 원했다. “연구는 하고 유용하게 만드는 일은 다른 사람이 알아서 하라”는 구조를 원하지 않았다.
   3. 당시 OpenAI가 ChatGPT를 약 20명의 엔지니어로 운영한다는 사실이 큰 인상을 줬다. 작은 팀이 큰 규모의 제품을 자율적으로 운영하는 방식이 강력해 보였다.
   4. 합류 직후 reasoning 모델 출시를 준비하는 흐름에 들어갔고, 약 한 달 뒤 o1-preview가 공개되는 과정을 경험했다.
   5. 이후 Codex를 만들 때도 커뮤니티의 피드백을 듣고 강한 피드백 루프를 유지하며 실제 유용성을 최우선으로 삼는 태도를 이어갔다.

2. Codex의 출발점과 제품화

Codex는 처음부터 완성된 코딩 제품으로 설계된 것이 아니라, OpenAI가 자기 자신을 더 빠르게 만들기 위해 모델을 업무 과정에 투입한 실험에서 시작됐다.

2.1. AS3와 내부 코딩 에이전트

1. 모델을 연구와 개발에 사용하다

   1. Tibo는 OpenAI에 합류한 뒤 대규모 데이터 저장·분석과 학습 실행을 이해하는 연구 인프라를 만들던 경험을 이어갔다.
   2. reasoning 모델과 초기 모델을 보며 “모델 자체를 연구에 사용해 OpenAI의 속도를 높일 수 있는가”라는 문제에 집착하기 시작했다.
   3. 연구 조직의 다른 구성원들과 함께 내부 모델을 학습하고 작은 에이전트를 만들었다. 이것이 Codex의 직접적인 전신이다.
   4. 초기 에이전트는 OpenAI의 Python 코드베이스를 잘 이해하고, 조직의 아키텍처와 코드 스타일에 맞는 ‘좋은 취향’을 갖도록 훈련됐다.
   5. 목적은 인프라를 더 빠르게 만들고 연구자들의 코딩 속도를 높이는 것이었다.

2. AS3와 제품화의 결합

   1. Greg과 Sam은 내부 생산성 도구에 머무르지 말고 세상에도 혜택을 주는 제품으로 만들라고 독려했다.
   2. 연구용 에이전트와 AS3(Autonomous Software Engineer) 노력을 합치면서 하나의 제품을 만들기 시작했다.
   3. 첫 클라우드 Codex는 사용자가 거쳐야 하는 단계가 많아 마찰이 컸고 제품-시장 적합성을 얻지 못했다.
   4. 이후 Codex CLI를 출시하고 계속 밀어붙이며, 모델이 실제 소프트웨어 제작을 도울 수 있는 최소 핵심을 찾았다.
   5. 이 과정의 공통된 질문은 “모델이 이 일을 어떻게 더 잘하게 만들 것인가”였다.

2.2. Rust를 선택한 이유

1. 에이전트와 제품 인터페이스를 분리하다

   1. Codex 팀은 매우 초기부터 제품 인터페이스와 에이전트 자체를 서로 다른 것으로 봤다.
   2. 핵심 에이전트는 견고하고 안전하며 효율적이고, 가장 큰 데이터센터 규모까지 확장될 수 있어야 했다.
   3. 재미있는 프로토타입을 대규모 서비스로 키운 경험에 따르면 초기 기반 선택은 나중에 큰 차이를 만든다. 단, 초기 속도를 지나치게 희생해서는 안 된다.

2. Rust의 장점과 현실적 트레이드오프

   1. 당시 모델은 Python이나 TypeScript만큼 Rust에 익숙하지 않았지만, 팀 안에 뛰어난 Rust 개발자가 있었고 내부 모델도 Rust를 전혀 못 다루는 수준은 아니었다.
   2. Rust의 정적 검증과 컴파일 타임 보장은 에이전트 실행기의 정확성과 안전성에 잘 맞았다.
   3. 우선순위는 모델이 코드를 생성하기 쉬운 언어가 아니라 실행기의 정확성(correctness)과 효율성(efficiency)이었다.
   4. TypeScript나 Python으로 시작해도 성공할 수 있었고 언젠가 다시 작성했을 가능성도 있지만, 처음부터 에이전트와 제품을 깨끗하게 분리하는 경계가 더 중요했다.
   5. 모든 것을 한 코드베이스와 한 언어에 넣으면 제품 세부사항과 에이전트 핵심이 엉키고, 이후 혁신을 막기 쉽다. Rust 경계는 그 결합을 방지하는 구조적 장치가 됐다.

2.3. 오픈소스와 모델 비종속성

1. Codex를 오픈소스로 공개한 이유

   1. 코딩 에이전트라면 자기 자신의 코드베이스를 가리키고 스스로 개선할 수 있어야 하며, 사용자가 기여자 커뮤니티가 될 수 있다는 점이 매력적이었다.
   2. 코드가 바뀌고 소프트웨어 개발 방식이 달라질 것이 분명한 시점에 커뮤니티와 떨어져 있기보다 직접 그 변화에 참여하는 편이 낫다고 판단했다.
   3. 모든 해답을 가지고 있지 않았기 때문에 “좋은 하네스는 무엇인가”를 공개적으로 실험하고, 외부의 영리한 사람들이 다른 방식으로 탐색하게 만드는 것이 유익했다.
   4. 오픈소스 프로젝트에서 문제를 직접 보지 않고는 문제를 제대로 해결하기 어렵다는 원칙도 작동했다.

2. 오픈소스의 이익

   1. 저장소와 PR이 공개돼 있어 새로 합류한 사람이 이미 코드를 보고, 기여를 검토하고, 구조를 이해한 상태로 온다. 온보딩이 사실상 끝난 상태다.
   2. Codex로 저장소를 살펴보며 질문하고 답을 얻는 방식으로 팀의 온보딩을 진행할 수 있다.
   3. 외부 기여가 들어오고, 팀이 커뮤니티에 말로만 관심을 보이는 것이 아니라 실제로 비용과 노력을 들여 참여한다.
   4. 작은 저장소를 직접 사용하고 고치는 커뮤니티가 형성되면서 제품에 에너지가 유입된다.

3. 오픈소스의 비용

   1. 회사의 나머지 코드와 분리된 공개 저장소를 유지해야 하므로, 기능을 연결할 때 인위적인 경계와 여러 저장소 사이의 작업이 생긴다.
   2. 아직 출시하지 않은 기능을 공개적으로 개발하다 보면 경쟁자가 구현을 먼저 보고 출시 직전에 복제할 수 있다. Tibo는 이것이 실제로 “조금 아픈” 일이라고 인정했다.
   3. 허용적인 라이선스를 택했기 때문에 복제는 공개 개발의 계약에 포함된 대가다.
   4. 품질이 낮거나 무작위적인 기여가 쓰나미처럼 들어와 검토하는 추가 세금이 발생한다.
   5. 이 비용은 불편하지만, 기여 흐름을 더 잘 다루는 자동화와 운영 체계를 만들도록 팀을 압박한다.

4. 다른 모델도 사용할 수 있게 한 이유

   1. 좋은 코딩 하네스를 만드는 일과 특정 모델에 묶는 일은 별개이며, 하네스를 모델에 강제로 결합하면 커뮤니티의 선택권을 빼앗게 된다.
   2. 다른 모델 지원을 별도 포크에서 10줄 수정으로 해결하게 만들기보다 공식 프로젝트에서 지원하는 편이 사용자와 개발자 모두에게 낫다.
   3. 오늘 OpenAI 모델을 쓰는 사용자가 내일 새 모델을 시험하기 위해 설정 전체를 바꾸지 않아도 된다.
   4. 다양한 모델을 같은 하네스에서 시험하면 OpenAI도 어떤 모델이 실제 업무에서 잘 작동하고 어떤 점이 부족한지 피드백을 얻는다.
   5. 기업은 공급자 선택권을 중요하게 여기므로, 모델·하네스·제품 모두의 품질과 효율성으로 이겨야 한다. Tibo는 이를 “락인(lock-in)이 아니라 실력(merit)으로 이기기”라고 표현했다.

3. Codex의 실행 환경과 클라우드 전환

Codex는 기본적으로 로컬에서 작동하는 샌드박스형 에이전트였지만, 더 강력한 모델과 대규모 사용자를 위해 관리형 클라우드 실행으로 확장되고 있다.

3.1. 로컬 실행과 권한 경계

1. 기본 실행 모델

   1. 기본적으로 Codex는 사용자의 컴퓨터에서 샌드박스 안에서 실행된다.
   2. 도구 실행은 샌드박스에 갇히며, 외부에 추가 권한이 필요한 명령은 사용자에게 권한을 요청한다.
   3. 이 로컬 방식은 1년 넘게 Codex의 기본이었다.

2. 로컬 실행의 장점과 비용

   1. 로컬 PostgreSQL, SQLite, 개발 서버, MCP 도구처럼 사용자가 이미 갖춘 환경에 바로 접근할 수 있다.
   2. 반면 여러 에이전트를 동시에 실행하면 CPU를 많이 쓰고, 노트북을 닫으면 작업이 중단되므로 노트북을 열어 둬야 한다.
   3. 로컬 개발자는 자신의 도구와 데이터가 있는 환경을 포기하기 어렵기 때문에 단순히 클라우드로 옮기는 것만으로는 충분하지 않다.

3.2. 클라우드 실행과 Kata 기반 관리형 VM

1. Codex Cloud의 구조

   1. 사용자가 클라우드 실행을 선택하면 Codex는 관리형 VM에서 실행된다.
   2. ChatGPT Work에서 사용하는 것과 같은 VM 계열이며, Kata 컨테이너를 활용한 보안 환경에서 작업이 수행된다.
   3. 사용자의 컴퓨터에는 입력과 결과 스트리밍만 오고, 실제 실행은 로컬 CPU를 쓰지 않는다.
   4. 이를 통해 더 많은 작업을 병렬로 실행하고, 앞으로는 로컬과 클라우드에서 일부 작업을 나눠 수행할 수 있다.

2. 왜 클라우드가 필수가 되는가

   1. 모델이 강해질수록 로컬 머신에 있는 것보다 훨씬 많은 컴퓨트와 리소스를 활용할 수 있다.
   2. 에이전트를 로컬에만 묶어 두면 모델의 능력과 작업 규모를 로컬 하드웨어가 제한하게 된다.
   3. 장기적으로는 클라우드 머신을 선택하는 일이 노트북을 계속 켜 두는 것보다 자연스러워질 것이다.

3.3. 클라우드 개발 환경의 재부상

1. 기존 클라우드 개발 환경의 한계

   1. 대기업 밖에서 클라우드 개발 박스가 크게 확산되지 못한 이유는 초기 설정 비용과 지속적인 유지보수 비용이 컸기 때문이다.
   2. 개인 개발자나 소규모 팀은 그 비용을 부담하고도 충분한 이익을 얻기 어려웠다.

2. 에이전트가 설정과 동기화를 맡는 방식

   1. 에이전트가 유능해지면 로컬 SQLite, 서버, MCP 설정을 클라우드 개발 박스에 복제하고 계속 동기화하는 일이 거의 자동화된다.
   2. 설정 비용과 유지보수 비용이 사실상 낮아지면서 완전한 클라우드 오케스트레이션 환경이 다시 주목받을 수 있다.
   3. ChatGPT Work처럼 모바일에서 작업을 시작하고 캘린더·이메일·Slack까지 연결해 처리하는 방식은 노트북을 들고 다니지 않아도 되는 업무 흐름을 보여준다.
   4. Codex Remote도 같은 방향의 중간 단계이며, 장기적으로는 노트북을 열어 두지 않아도 작업이 계속되는 환경이 목표다.

4. 모델과 하네스의 공동 설계

Codex의 발전은 모델을 따로 만들고 하네스를 따로 개선하는 방식이 아니라, 현재 모델의 한계를 하네스로 보완하고 다음 모델이 그 보완을 학습해 다시 하네스를 단순화하는 순환으로 진행된다.

4.1. 하네스는 모델보다 한 발 앞선다

1. ‘목발’로서의 하네스

   1. 모델은 특정 능력을 갖고 있지만, 그대로 두면 안정성·효율성·조종 가능성·사용자 기대를 만족하지 못할 수 있다.
   2. 하네스는 안전 가드레일, 도구, 실행 규칙, 컨텍스트 구성, 사용자에게 보이는 동작을 제공해 모델이 실제 업무를 수행하도록 돕는다.
   3. 모델이 테스트를 실행하지 않는다면 하네스와 개발자 메시지(developer message)가 테스트를 상기시킬 수 있다.
   4. 개발자 메시지는 매 턴 시작 시 컨텍스트에 삽입돼 에이전트의 행동 목적과 제약을 조정한다.

2. 모델이 좋아지면 하네스가 줄어든다

   1. 팀이 특정 문제를 모델 훈련으로 해결하면, 예전에 필요했던 지시문이나 강제 규칙을 제거할 수 있다.
   2. 시스템이 발전할수록 개발자 메시지는 짧아지고 하네스도 작아진다.
   3. 이 때문에 Codex 팀의 일부 작업은 다음 모델이 학습하면 사라질 ‘목발’을 만드는 것처럼 보이지만, 도구와 프로토콜 같은 기반은 모델이 앞으로도 사용할 수 있다.
   4. 하네스의 역할이 줄어드는 것은 실패가 아니라 모델이 새로운 능력을 흡수했다는 측정치다.

4.2. 무엇을 하네스로 고칠지 모델로 고칠지 결정하는 과정

1. 연구와 엔지니어링의 공동 판단

   1. 팀은 현재 시스템이 잘하는 일과 못하는 일을 관찰하고, 제품적으로 필요한 새로운 능력을 목록화한다.
   2. 각각의 부족함이 하네스 변경인지 모델 변경인지 판단한다.
   3. 모델 문제라면 한 달, 세 달, 여섯 달 안에 어느 수준의 훈련으로 해결할 수 있는지 추정한다.
   4. 모델이 곧 해결할 문제라면 유지비가 드는 하네스 우회책을 만들지 않고 기다릴 수도 있다.

2. 에이전트를 사용한 에이전트 개선

   1. 피드백을 에이전트로 분석해 반복되는 테마를 찾고, 우선순위 토론을 준비한다.
   2. 분석 범위는 코딩뿐 아니라 금융, 커뮤니케이션, 마케팅 등 OpenAI 사용자가 에이전트를 활용하는 모든 영역이다.
   3. 전체 모델이 좋아지면 모든 영역의 성능이 올라가지만, 특정 영역은 제품 가치가 크기 때문에 추가로 집중한다.
   4. 개발팀의 업무 자체가 에이전트로 피드백을 분석하고 다음 에이전트의 개선점을 결정하는 재귀적인 구조가 된다.

5. Codex 팀의 업무 방식과 소프트웨어 개발 생명주기

Codex 팀은 전통적인 개발 프로세스를 폐기한 것이 아니라, 계획·구현·검증·배포의 기계적 부분을 자동화하고 사람이 판단해야 할 부분을 더 높은 수준으로 끌어올렸다.

5.1. 온보딩과 “Codex에게 물어봤나?” 문화

1. 새 엔지니어가 가장 먼저 배우는 것

   1. Tibo는 새로 합류한 사람에게 훌륭한 동료를 소개하는 동시에, 질문이 생기면 “Codex에게 물어봤나?”라고 묻는다고 했다.
   2. Codex는 Slack, 문서, 코드, 프로젝트 기록에 접근할 수 있어 프로젝트의 상태와 의사결정 이유를 빠르게 설명한다.
   3. 새 구성원은 누가 무엇을 담당하는지, 특정 결정이 왜 내려졌는지, 현재 어떤 작업이 진행 중인지 Codex에게 먼저 물을 수 있다.

2. 정보를 검색 가능한 조직으로 만들기

   1. 에이전트가 추론하려면 정보에 접근할 수 있어야 하므로 팀은 공개 채널을 많이 사용한다.
   2. 문서도 넓은 권한으로 열어 구성원과 에이전트가 함께 읽을 수 있게 만든다.
   3. 이렇게 하면 새 사람이 조직의 맥락을 빨리 파악하고, 다른 팀과 일관된 방향으로 기여할 수 있다.
   4. 추가적인 팀 생산성·협업 기능도 개발 중이며, 당시 Dev Day를 통해 일부 공개할 예정이었다.

5.2. 제품 원칙과 배포

1. 지켜야 할 원칙

   1. 사용자를 배려하고 제품의 일관성을 지키며, 모델이 어디로 가고 있는지 이해해야 한다.
   2. 모델의 결함을 피하려고 1만 줄짜리 임시방편을 쌓고 있다면 근본적으로 잘못된 방향일 수 있다.
   3. 새 기능은 단순히 만들 수 있는지가 아니라, 사용자에게 가치가 있고 장기적으로 유지할 만한지 증거를 제시해야 한다.

2. 빠른 출시와 소유권

   1. ChatGPT는 수십억 명 규모로 확장 중인 제품이지만, 좋은 변화라면 PR을 만들고 다음 날 또는 당일 배포할 수 있다.
   2. 팀은 큰 변경도 맡은 사람이 소유하고 실행하도록 권한을 부여한다.
   3. 코드 리뷰·배포·회귀 탐지는 가능한 한 자동화해 엔지니어가 아이디어와 사용자 효과에 집중하게 한다.
   4. 평가 기준은 변화가 잘 받아들여질 증거, 추가할 가치, 유지 비용, 전체 제품과의 일관성이다.

5.3. 장기적인 북극성: 단순하고 개인적인 AGI

1. 개인 맥락을 이해하는 에이전트
   1. Tibo가 말한 북극성은 사용자를 깊이 이해하고 필요한 자원에 접근하는 단순한 개인용 AGI다.
   2. 일정과 목표를 알고, 필요할 때 먼저 행동하며, 자연어와 음성으로 통제할 수 있어야 한다.
   3. 위험할 수 있는 행동을 실행할 때는 사용자가 푸시 알림을 받고 검증할 수 있어야 한다.
   4. 카메라로 감정을 이해하는 상황까지 포함해도, 사용자가 수십 개의 버튼과 설정을 배워야 하는 제품이 아니라 세상에서 가장 자연스럽게 사용할 수 있어야 한다.

6. 코드 리뷰의 변화

AI가 생성하는 코드가 늘어날수록 사람의 역할은 모든 줄을 읽는 일에서 의도와 시스템 경계를 검증하는 일로 이동한다.

6.1. 기계적 정확성과 보안 검증의 자동화

1. 코드 리뷰 모델의 깊은 검증

   1. Tibo가 초기에 Codex에서 맡은 프로젝트 중 하나는 연구팀과 함께 논리 오류와 추론 오류를 찾아내는 코드 리뷰 모델을 만드는 일이었다.
   2. 단순한 문법이나 스타일이 아니라 의존성을 세네 단계 깊게 따라가고, 문서가 틀렸거나 서드파티 구현이 예상과 다를 때 불변조건이 깨지는지 확인했다.
   3. 전문 개발자가 여러 시간을 들여야 찾을 오류를 모델이 깊은 검증으로 발견하도록 했다.
   4. 이 기능은 메인라인 모델에 흡수됐고, 벤치마크에서 인간보다 뛰어난 코드 리뷰 능력을 보이는 수준까지 발전했다.

2. 보안과 병합 차단

   1. 같은 방식은 복잡한 보안 문제를 찾아내는 데도 적용된다.
   2. OpenAI에서는 보안 문제가 감지된 PR을 자동으로 병합하지 못하도록 차단하는 흐름이 의무화됐다.
   3. 정확성과 사이버 보안처럼 반복 가능하고 명확한 검증은 에이전트가 더 빠르고 일관되게 처리할 수 있다.

6.2. 사람이 맡을 검토: 의도·계약·불변조건

1. 코드 리뷰의 사회적 기능

   1. 전통적인 코드 리뷰는 정확성뿐 아니라 지식 공유, 버스 팩터(bus factor) 감소, 설계 토론, 팀을 같은 페이지에 올리는 의식의 역할을 했다.
   2. 리뷰어가 바빠서 PR이 멈추고, 작성자가 “이 변경을 승인해 달라”고 재촉하며, 리뷰어가 컨텍스트를 전환하는 비용도 컸다.
   3. 자동 검증이 늘어나면 사람은 단순한 문법·논리·보안 검토에 시간을 쓰지 않아도 된다.

2. PR에서 제품 의도로 이동하기

   1. 앞으로 중요한 대화는 “이 코드를 어떻게 썼는가”보다 “무엇을 하려는가”, “그 시도가 옳은가”가 된다.
   2. 이 의도 토론은 반드시 코드가 완성된 뒤 PR에서 할 필요가 없으며, 설계 단계에서 먼저 진행할 수 있다.
   3. 시스템을 하나의 상자(box)로 보고 자원 사용량, 데이터 접근, 보안, 불변조건 같은 계약을 먼저 합의하면 상자 안의 구현은 어떤 형태여도 된다.
   4. 합의된 계약을 만족한다면 상자 내부를 바꾸는 일은 사람의 주의를 끌 필요가 없고, 사람은 경계와 의도에 집중할 수 있다.

7. 유지보수와 재아키텍처의 비용이 내려가는 이유

에이전트는 개발 속도만 높이는 것이 아니라, 이전에는 미뤄 두던 유지보수와 시스템 재구축의 비용을 낮춘다. 다만 올바른 추상화와 경계의 중요성은 오히려 커진다.

7.1. 유지보수의 자동화

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

   1. 서드파티 의존성 버전 업데이트는 변경 로그가 잘 작성되고 코드가 문서화돼 있다면 에이전트가 코드베이스 전체를 살펴 몇 시간 안에 처리할 수 있다.
   2. 과거에는 재미없다는 이유로 미루던 업그레이드도 사업상 중요하고 보안 패치를 위해 반드시 해야 하는 일이다.
   3. 의존성 업데이트, 회귀 테스트, 취약점 패치 같은 유지보수 세금의 많은 부분이 자동화될 수 있다.

2. ‘공짜’의 의미

   1. 유지보수가 완전히 사라지는 것이 아니라, 사람의 직접적인 주의와 시간을 거의 요구하지 않는다는 의미에서 공짜에 가까워진다.
   2. 자동화가 실패했을 때를 대비해 테스트와 보안 경계, 관측 가능성은 여전히 필요하다.

7.2. 재아키텍처와 좋은 추상화

1. 비용이 내려간 재아키텍처

   1. 새로운 트레이드오프나 기능을 수용하려고 전체 아키텍처를 바꾸는 일은 과거에 수년이 걸릴 수 있는 대형 프로젝트였다.
   2. 이제 에이전트가 기존 구조를 이해하고 반복적인 변환을 수행하면서 재아키텍처의 속도가 크게 빨라진다.
   3. 실수의 비용도 낮아진다. 이전에는 잘못된 설계를 발견하면 너무 비싸서 그대로 끌고 갔지만, 이제는 다시 만들 수 있다.

2. 기초 설계가 더 중요해지는 이유

   1. 좋은 추상화와 정확한 경계를 세우면 상자 안의 구현을 빠르게 바꾸면서 다른 서비스에 영향을 주지 않을 수 있다.
   2. 모델도 파일 내부의 코드 품질뿐 아니라 장기 유지보수, 미래 기능 확장, 변경 비용을 고려하는 아키텍처를 점점 더 잘 판단한다.
   3. 소프트웨어의 생명주기가 인간 팀 중심의 수년 단위에서 에이전트 수백 개가 주말에 기여하는 속도로 바뀐다.
   4. 따라서 모든 엔지니어가 아키텍처, 모듈성, 경계, 유지보수에 관심을 가져야 한다. 예전처럼 일부 아키텍트와 스태프 엔지니어만 구조를 관리하는 방식으로는 충분하지 않다.

7.3. 개발자의 장인정신과 속도 변화

1. 사라지지 않는 코딩의 즐거움

   1. Tibo는 때때로 편집기를 열고 직접 코드를 쓴다. 늦은 밤 Vim에서 문제 하나에 몰입하고 Coke Zero를 마시며 코드를 작성하던 기억에는 장인정신의 즐거움이 있다.
   2. 하지만 긴 리팩터링을 세 시간 진행한 뒤 막다른 길임을 깨닫거나, 컴파일이 되지 않아 밤을 새우는 고통도 같은 경험의 일부였다.

2. 코드를 도구로 보는 관점

   1. 코드는 문제를 해결하기 위한 도구이며, 도구가 좋아져 더 많은 문제를 해결할 수 있다면 엔지니어는 더 강해진다.
   2. 예전에는 벤치마크를 해볼지 망설였다면, 이제는 에이전트에게 30초 안에 실행하게 해 정확한 수치와 트레이드오프를 얻을 수 있다.
   3. OpenAI는 여전히 수학·과학적 돌파구, 인류가 겪는 중요한 문제, 더 인간적인 방식으로 세상을 개선하는 일에 필요한 문제를 다 해결하지 못했다.
   4. 문제가 줄어드는 것이 아니라 해결 가능한 문제의 속도와 범위가 넓어지는 것이다.

8. ChatGPT와 Codex의 통합

Codex를 ChatGPT 안으로 옮긴 일은 단순히 메뉴에 기능을 추가한 것이 아니라, 완전히 로컬이던 에이전트를 관리형 클라우드 스택에 통합하고 수천만~수억 명에게 경제적으로 제공하는 대형 시스템 프로젝트였다.

8.1. 서로 다른 시스템을 합친 난제

1. 로컬 에이전트와 관리형 서비스의 차이

   1. ChatGPT는 완전히 관리되는 클라우드 기반 스택이며, 모든 실행이 OpenAI 시스템 안에서 일어나고 전통적인 방식으로 데이터를 저장한다.
   2. Codex는 사용자의 로컬 환경에서 실행되는 제품이었다.
   3. 통합의 핵심은 로컬 코딩 에이전트와 같은 능력을 유지하면서, 훨씬 더 많은 사람이 사용할 수 있는 클라우드 제품을 만드는 일이었다.

2. 클라우드 Codex의 실행 규모

   1. ChatGPT Work에서는 강력한 클라우드 컴퓨터와 함께 전체 Codex 하네스를 실행한다.
   2. 인터넷 접근이 가능하고 강력한 VM이기 때문에, 사용자는 Blender를 설치해 3D 모델링을 하거나 다른 모델을 학습시키는 등 예상보다 폭넓은 작업을 수행할 수 있다.
   3. 이 유연성은 강력하지만, 샌드박스·권한·자원·비용을 대규모로 관리해야 하는 시스템 과제를 동반한다.
   4. 월 20달러의 Plus 요금제에 포함하려면, 사용자가 소비하는 컴퓨트 비용과 서비스의 운영비 사이에서 매우 효율적인 설계가 필요했다.

8.2. 통합 과정에서 Codex가 사용된 방식

1. 구현 파트너로서의 Codex

   1. Codex는 통합에 필요한 인프라를 살펴보고 만들며, 두 시스템 사이의 작은 차이를 해결하는 데 사용됐다.
   2. 플러그인 아키텍처와 라이브러리를 합치고, 서로 다른 시스템을 하나의 공통 구조로 정리하는 작업을 지원했다.
   3. 목표는 Codex에서 할 수 있는 일을 ChatGPT에서 못 하거나, ChatGPT에서 가능한 일을 Codex에서 못 하는 상황을 없애는 것이다.
   4. 두 제품은 같은 지능에 접근하되 사용자가 원하는 방식으로 활용하는 하나의 통합 제품으로 향하고 있다.

2. ‘토글 아크’와 점진적 통합

   1. 작업 중심 경험을 구분하기 위해 도입한 Work 토글은 이름과 노출 시점을 두고 여러 차례 논쟁이 있었다.
   2. 팀은 결국 토글을 좋아하게 됐지만, 장기적으로는 작업 모드와 일반 경험을 더 깊이 통합할 계획이다.
   3. 현재의 분리는 임시 상태이며, 강력한 기능을 먼저 작업 모드에 제공한 뒤 모든 ChatGPT 사용자에게 확장하는 방향이다.

8.3. Codex를 ‘프로젝트의 기자’로 사용한 일

1. 논쟁과 결정을 기록하다

   1. Codex는 Slack 대화와 문서를 광범위하게 읽을 수 있었기 때문에 통합 과정의 논쟁, 설계 선택, 명명, 출시 순서를 추적했다.
   2. 어떤 것을 먼저 합칠지, 무엇을 어떤 이름으로 부를지, 어떤 순서로 공개할지에 대해 여러 조합이 검토됐다.
   3. Codex는 프로젝트 전반을 정리하는 기자처럼 토론과 결정을 기록했고, 팀은 나중에 그 과정을 다시 볼 수 있었다.

2. 생산성의 이면

   1. 조직의 모든 Slack과 문서를 읽는 AI가 팀의 결정을 기록하는 방식은 강력한 지식 관리 수단이다.
   2. 동시에 모든 대화를 AI가 지켜보고 있다는 ‘빅 브러더’ 느낌을 줄 수 있으며, Tibo도 이 감정을 아직 완전히 정리하지 못했다고 했다.
   3. 스타트업과 팀 운영에서 이런 방식이 새로운 표준이 될 가능성은 있지만, 편리함과 감시감 사이의 긴장을 다뤄야 한다.

9. Tibo의 실제 사용 방식과 장기 작업

Tibo는 Codex를 특정 개발 업무에만 쓰지 않고, 질문을 조사하고 보고서와 슬라이드 덱을 만들고 프로토타입을 구현하는 개인 운영체제처럼 사용한다.

9.1. 모바일 중심 업무 흐름

1. 말로 던지고 결과를 받기

   1. Tibo는 모바일에서 ChatGPT Work를 사용하고, 떠오른 질문이나 해야 할 일을 받아쓰기로 바로 보낸다.
   2. 질문을 나중에 조사하기 위해 메모하거나 다른 사람에게 위임하는 대신, 그 자리에서 에이전트에게 보내 보고서를 받는다.
   3. 커스텀 스킬과 지시문을 사용해 보고서, 슬라이드 덱, 코드 탐색 결과를 자신이 읽기 좋은 형식으로 맞춘다.

2. 조직 전체를 질의하는 개인 에이전트

   1. Slack, Notion, Google Docs와 공개 채널을 바탕으로 기능에 대한 사용자 반응, 프로덕션 로그 사용량, 정리할 기능 목록, 특정 팀의 진행 상황을 물을 수 있다.
   2. 어떤 질문이든 약 30분 안에 최소한의 첫 답변을 얻을 수 있다는 점이 핵심이다.
   3. 주말에는 팀원들과 미래 제품의 프로토타입을 만들고, 하루 안에 아이디어를 눈에 보이는 형태로 만들어 비평받는다.
   4. 프로토타입이 바로 출시될 필요는 없다. 머릿속 아이디어를 꺼내 팀이 사고하고 반박할 수 있게 만드는 것이 목적이다.

9.2. 장시간 작업과 /goal의 변화

1. 밤새 실행하는 조사

   1. Tibo는 하루 중 대화에서 나온 큰 질문을 바로 해결하지 못하면 Codex에 밤새 조사하도록 보낸다.
   2. 아침에 결과를 확인하는 과정 자체가 기대되는 일이며, 긴 작업을 맡기는 새로운 업무 리듬을 만든다.

2. 하네스 명령어의 수명

   1. /goal은 모델이 며칠 또는 몇 주 동안 하나의 목표를 놓치지 않도록 하는 하네스 장치였다.
   2. 새로운 모델은 별도의 명령어 없이도 “일주일 동안 이 문제를 해결하라”는 지시를 따라갈 만큼 좋아지고 있다.
   3. 특정 명령어가 사라지는 것은 하네스가 실패한 것이 아니라, 모델이 그 기능을 내재화했다는 신호다.

10. AI 시대에 훌륭한 엔지니어가 되는 법

Tibo가 제시한 역량은 특정 도구의 사용법보다 빠르게 이해하고, 올바른 문제를 고르고, 커뮤니티의 필요와 제품의 의도를 연결하는 능력에 가깝다.

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

1. 작동 원리를 끝까지 파고들기
   1. 새로운 시스템이 어떻게 작동하는지 깊이 궁금해하고, 빠르게 이해하도록 스스로 훈련해야 한다.
   2. OpenAI에서 잘하는 사람은 새로운 코드베이스에 들어가 구조와 흐름을 빠르게 파악하고, 시스템 전체를 짧은 시간에 모델링한다.
   3. 정보량이 폭발한 시대에는 에이전트가 정보를 모아도 사람이 질문을 만들고 답을 추론해야 하므로, 질문의 질이 중요하다.
   4. “누가, 무엇을, 언제, 어디서, 왜, 어떻게”라는 다섯 가지 질문을 계속 파고들면 학습 속도가 빨라진다.

10.2. 문제를 해결할 집단과 연결되기

1. 커뮤니티에 맞는 문제 정의

   1. 모든 문제는 직접 사용자의 요구를 해결하는 형태로 나타나지 않는다. 한 팀의 문제를 해결하는 일이 궁극적으로 더 큰 인간의 문제를 푸는 기반이 될 수도 있다.
   2. 그래도 누구를 위해 만드는지, 그들이 무엇을 좋아하고 싫어하는지, 어떤 품질과 제약을 요구하는지 명확히 알아야 한다.
   3. 커뮤니티와 연결되지 않고 좋은 취향과 필요를 파악하지 못하면 훌륭한 결과를 만들기 어렵다.

2. 의도를 설명할 수 있는 명료함

   1. 무엇을 만들려는지, 어떤 결과를 원하는지, 왜 그 방향이 가치 있는지 설명할 수 있어야 한다.
   2. 에이전트가 구현을 대신할수록 사람의 차별점은 코드 작성 속도가 아니라 목표와 경계를 명확히 표현하는 능력이 된다.
   3. 호기심, 빠른 증상 파악, 커뮤니티와의 조율, 기본기의 결합이 AI 시대에도 여전히 훌륭한 엔지니어를 만든다.

협찬 및 영상 중간 광고에서 언급된 도구

영상의 본론과 별개로 다음 세 개의 협찬이 삽입됐다. 제품 주장을 사실로 검증한 내용이 아니라 영상 내 광고 메시지다.

Turbopuffer

• 객체 스토리지에 상태를 두고 NVMe SSD와 메모리 캐시를 컴퓨트에 사용하는 하이브리드 검색 엔진으로 소개됐다.
• 데이터는 namespace 단위로 구성되며, 조회하지 않을 때는 저렴한 객체 스토리지에 머물러 컴퓨트 비용이 없다.
• 활성화된 namespace만 캐시 계층으로 가져와 빠르게 조회하고, 사용자나 에이전트마다 전용 검색 인덱스를 만들 수 있다고 광고했다.
• Entropic, Notion, Cognition, Harvey 등이 사용한다고 소개됐다.

Entire

• 에이전트가 병렬로 더 많은 코드를 밀어 넣으면서 Git과 GitHub가 병목이 될 수 있다는 문제를 제시했다.
• GitHub의 마지막 코어 개발자가 만든 에이전트 시대용 Git 호스팅으로, 저장소를 지역적으로 가깝게 두고 초당 418번의 push와 경쟁 제품보다 최대 89배 빠른 처리량을 주장했다.
• GitHub가 중단돼도 계속 작업할 수 있고, 기존 GitHub 저장소를 미러링할 수 있다고 설명했다.
• 에이전트의 프롬프트와 대화 이력을 저장소에 함께 보존하고, 어떤 프롬프트가 특정 코드를 만들었는지 확인할 수 있다고 소개했다.

Antithesis

• 에이전트가 생성한 코드의 버그를 찾기 위해 시스템 전체를 적대적 시뮬레이션 안에서 실행하는 도구로 소개됐다.
• 표적 테스트와 퍼즈 테스트를 사용하고, 결정론적 시뮬레이션으로 버그와 완벽한 재현 절차를 함께 제공한다고 광고했다.
• Jane Street와 Fly.io 등이 사용한다고 소개됐다.

주요 발언 모음

“하네스는 대체로 모델보다 한 발 앞서 있다.”

“하네스는 모델에 필요한 목발을 제공한다. 안전성과 효율성, 조종 가능성, 사용자가 기대하는 행동을 만들어 준다.”

“락인으로 이기는 것이 아니라 실력으로 이기고 싶다.”

“질문이 생기면 Codex에게 물어봤는지부터 확인한다.”

“유지보수는 시간이 지나며 계속 지불하는 세금이지만, 그중 많은 부분은 자동화될 것이다.”

“사람이 합의해야 하는 것은 상자 안의 코드가 아니라 그 상자가 무엇을 하고 어떤 불변조건을 지켜야 하는지다.”

“코드는 문제를 해결하기 위한 도구이고, 더 많은 문제를 해결할 수 있다면 더 나은 엔지니어가 될 수 있다.”

“깊은 호기심을 갖고 일이 어떻게 작동하는지 빠르게 이해하며, 만들고 있는 집단과 조율해야 한다.”

핵심 데이터 & 수치

• 약 8세: 작은 마을에서 인터넷과 컴퓨터를 통해 세상을 배우기 시작한 시기다.
• 약 200명: Tibo가 어린 시절 살던 마을의 인구 규모다.
• 2015년: Google 런던에 합류한 시점이다.
• 약 2년: Google에서 모바일 웹 속도 프로젝트를 진행한 기간이다.
• 약 20명: Tibo가 합류 당시 ChatGPT를 운영한다고 들은 OpenAI 엔지니어 규모다.
• 약 1개월: Tibo가 reasoning 모델 관련 작업에 합류한 뒤 o1-preview가 공개되기까지의 기간으로 언급됐다.
• 1시간 14분 22초: 영상 전체 길이다.
• 월 20달러: ChatGPT Plus에 클라우드 Codex를 포함하기 위해 고려해야 했던 가격대다.
• 수천만 명에서 수억 명: 로컬 Codex를 훨씬 더 넓은 ChatGPT 사용자에게 제공해야 했던 통합의 목표 규모다.
• 30분 이내: Tibo가 조직 내부 질문에 대해 Codex의 첫 답변을 얻는 데 걸리는 체감 시간이다.
• 며칠에서 몇 주: /goal이 모델을 하나의 장기 작업에 붙잡아 두기 위해 상정했던 실행 기간이다.
• 초당 418회 / 최대 89배: Entire 광고에서 제시한 Git push 처리량과 경쟁 제품 대비 수치다.

결론 및 시사점

1. AI 코딩 제품의 경쟁력은 모델의 벤치마크 점수만으로 결정되지 않고, 안전한 실행 환경·도구·컨텍스트·피드백 루프가 함께 결정한다.
2. 모델의 능력이 좋아질수록 하네스의 규칙은 줄어들지만, 모델이 사용할 도구와 프로토콜, 서비스 경계는 남으므로 기반 설계가 중요하다.
3. Rust 선택은 모델 친화성보다 정확성·보안·효율성·장기 확장성을 우선하고, 에이전트와 제품을 분리하려는 구조적 판단이었다.
4. 오픈소스는 온보딩과 커뮤니티 피드백을 크게 개선하지만, 복제·저품질 기여·저장소 경계라는 운영 비용을 동반한다.
5. 모델 비종속성은 사용자의 선택권을 보장하고, 공급자가 락인이 아니라 모델과 제품의 실력으로 경쟁하게 만든다.
6. 로컬 실행은 사용자의 도구와 데이터를 활용하기 좋고, 클라우드 실행은 대규모 컴퓨트와 장시간·병렬 작업에 적합하므로 두 환경은 공존할 가능성이 높다.
7. 코드 리뷰에서 자동화 가능한 정확성·보안·회귀 검증은 에이전트에 맡기고, 사람은 의도·계약·불변조건과 제품의 일관성을 합의하는 데 집중해야 한다.
8. 유지보수와 재아키텍처가 빨라져도 좋은 추상화와 모듈 경계가 없으면 에이전트가 만든 변화의 폭발을 통제하기 어렵다.
9. ChatGPT와 Codex의 통합은 로컬 에이전트를 클라우드에서 대규모로 서비스하는 시스템 문제였으며, Codex가 통합 과정의 지식 기록자 역할까지 수행했다.
10. AI 시대의 엔지니어에게 남는 핵심 역량은 깊은 호기심, 빠른 시스템 이해, 정확한 문제 정의, 커뮤니티와의 연결, 명료한 의도 표현이다.

핵심 요약 (20줄)

1. Codex는 OpenAI 내부 연구자들의 생산성을 높이려던 Python 코딩 에이전트 실험에서 출발했다.
2. Tibo Sottiaux는 응용수학 창업과 Google·DeepMind의 연구 인프라 경험을 Codex 설계에 연결했다.
3. DeepMind에서 만든 내부 대화형 모델은 ChatGPT보다 약 1년 앞서 연구자들 사이에서 빠르게 퍼졌다.
4. OpenAI를 선택한 이유는 연구와 제품을 함께 설계하며 직접적인 세상 영향까지 책임지는 미션 때문이었다.
5. Codex는 AS3 연구와 내부 에이전트가 합쳐진 뒤 클라우드 제품과 CLI로 발전했다.
6. Rust는 모델 친화성보다 실행기의 정확성·보안·효율성과 에이전트-제품 경계를 우선해 선택됐다.
7. 에이전트 핵심과 제품 인터페이스를 분리하면 이후 재사용과 혁신을 더 쉽게 만들 수 있다.
8. 오픈소스는 온보딩과 커뮤니티 기여를 높이지만 기능 복제와 저품질 기여라는 비용을 만든다.
9. Codex는 특정 OpenAI 모델에 묶이지 않아 사용자가 다른 모델과 공급자를 선택할 수 있다.
10. 로컬 Codex는 샌드박스에서 실행하고 추가 권한이 필요한 명령만 사용자 승인을 요구한다.
11. 클라우드 Codex는 관리형 VM과 Kata 컨테이너에서 실행돼 노트북의 자원과 실행 시간을 확장한다.
12. 에이전트가 개발 환경을 자동 설정하면 클라우드 개발 박스의 높은 초기·유지 비용이 낮아진다.
13. 하네스는 모델에 안전 가드레일·도구·개발자 메시지를 제공하는 한 발 앞선 목발이다.
14. 모델이 능력을 학습하면 개발자 메시지와 하네스의 우회 규칙은 점점 줄어든다.
15. Codex 팀은 에이전트로 피드백을 분석하면서 하네스 문제와 모델 문제의 우선순위를 정한다.
16. 정확성·보안 코드 리뷰는 자동화되고 사람은 의도·계약·불변조건을 논의하는 데 집중한다.
17. 의존성 업데이트와 재아키텍처 비용은 낮아지지만 좋은 추상화와 모듈 경계는 더 중요해진다.
18. ChatGPT 통합은 로컬 에이전트를 대규모 클라우드 서비스로 바꾸는 복잡한 시스템 프로젝트였다.
19. Codex는 Slack과 문서를 읽으며 통합 과정의 논쟁과 결정을 기록하는 프로젝트 기자가 됐다.
20. AI 시대의 엔지니어는 깊이 호기심을 갖고 빠르게 이해하며 커뮤니티의 필요와 의도를 명확히 연결해야 한다.