Codex를 만드는 방식, 모델과 실행 환경에서 코드 리뷰까지

TL;DR

• Codex는 내부 연구와 개발을 빠르게 만들려던 실험에서 외부 개발자용 제품으로 확장됐다. 팀은 제품 화면과 핵심 에이전트를 분리하고 정확성·효율·구조적 경계를 위해 Rust를 선택했다. 모델이 당장 가장 잘 다루는 언어만으로 장기 설계를 결정하지는 않았다.
• 오픈소스와 다른 모델 제공자 지원은 사용자의 선택권과 피드백을 넓히는 선택이다. 신규 합류자의 학습과 외부 기여에 도움이 되지만 저품질 PR과 공개 개발의 비용도 따른다. 경쟁자가 기능을 먼저 복제할 수 있다는 점까지 감수한다.
• 하네스는 도구·권한·실행 흐름으로 현재 모델의 부족함을 보완한다. 모델이 좋아지면 일부 지침과 보조 장치를 줄일 수 있다. 다만 모든 도구와 연결 기능까지 사라진다는 뜻은 아니다.
• 코드 리뷰의 초점은 생성된 줄 수보다 의도와 계약, 지켜야 할 조건으로 이동한다. 자동 검증을 늘리더라도 무엇을 만들지에 대한 논의는 남는다. 유지보수와 재설계가 쉬워질수록 좋은 경계와 추상화의 가치도 커진다.
• 로컬 Codex를 ChatGPT와 통합하는 일은 화면을 합치는 수준을 넘는다. 실행 환경·플러그인·라이브러리와 대규모 서비스의 비용 구조를 맞춰야 한다. 인터뷰의 발전 방향과 실제로 검증된 보장 범위는 구분해서 읽어야 한다.

연구 도구에서 외부 개발자의 제품으로

Tibo Sottiaux는 응용수학으로 제약 공급망과 산업의 최적화 문제를 풀다가 Google과 DeepMind에서 연구 인프라와 도구를 만들었다. Google의 모바일 웹 성능 프로젝트는 기술적으로 흥미로웠지만 충분한 사용자를 얻지 못해 중단됐다. 그 경험에서 얻은 교훈은 프로젝트가 잘된다는 내부 설명보다 실제 사용자와 효과를 직접 확인하는 것이었다. DeepMind에서 만든 내부 대화 도구도 인기를 얻었지만 연구 도구를 외부 제품으로 내놓는 데는 조직과 배포 체계의 제약이 있었다.

OpenAI에서는 추론 모델을 연구와 개발 자체에 활용하는 가능성에 몰두했다. 초기에는 회사의 Python 코드베이스와 코드 스타일, 아키텍처에 익숙한 모델과 작은 에이전트를 만들어 연구자와 인프라 엔지니어를 돕고자 했다. 이후 이 연구가 자율 소프트웨어 엔지니어를 만들려던 노력과 합쳐지면서 Codex로 이어졌다. 처음 공개한 클라우드형 경험에는 사용 장벽이 있었고 CLI를 함께 발전시키며 실제로 쓸 만한 제품을 찾아갔다.

Rust는 실행 코어와 제품의 경계를 만드는 선택이었다

Codex 팀은 사용자가 접하는 제품 인터페이스와 에이전트의 핵심을 처음부터 다른 문제로 다뤘다. 에이전트 코어는 다양한 환경에서 안전하고 정확하게, 효율적으로 실행돼야 했다. Sottiaux는 강한 타입과 컴파일 단계의 검사가 에이전트가 작성한 코드를 검증하는 데도 도움이 됐다고 설명한다. 팀에 뛰어난 Rust 개발자가 있었고 모델의 Rust 능력도 개선할 수 있다는 판단이 더해졌다.

그는 TypeScript나 Python으로 시작해도 성공했을 수 있으며 나중에 다시 작성하는 선택도 가능했다고 인정한다. Rust를 고른 의미는 모든 경쟁 언어보다 우월하다는 결론보다 제품과 코어가 무심코 뒤섞이지 않도록 경계를 세운 데 있다. 장기적인 효율을 준비하되 현재의 개발 속도를 지나치게 희생하지 않는 절충이었다. 모델이 익숙한 언어에 맞추는 것과 제품이 오래 유지할 구조를 정하는 것은 별개의 판단이다.

공개 개발과 모델 선택권의 이익과 비용

코딩 에이전트의 코드를 공개하면 사람들이 그 에이전트로 에이전트 자체를 개선할 수 있다. 팀은 외부에서 실험하는 사람들과 함께 좋은 실행 방식을 찾고자 했다. 신규 입사자도 합류 전에 저장소와 PR을 살펴볼 수 있어 학습의 장벽이 낮아진다. 이런 직접적인 커뮤니티 참여는 내부에서만 설계할 때 얻기 어려운 피드백과 에너지를 제공한다.

반면 공개 저장소는 회사의 다른 코드와 분리돼 있어 여러 저장소를 가로질러 일해야 하고 저품질 기여를 처리하는 부담도 생긴다. 공개적으로 개발하던 기능을 경쟁자가 복제해 먼저 출시할 때도 있다. Sottiaux는 그 경험이 불편하더라도 허용적인 라이선스와 공개 개발을 선택한 이상 감수해야 할 부분이라고 설명한다. 오픈소스는 비용이 없는 홍보 방식이 아니라 참여를 얻기 위해 운영 부담을 함께 떠안는 선택이다.

다른 제공자의 모델을 지원하는 것도 같은 논리다. 모델 하나를 바꾸려고 저장소를 포크하거나 전체 작업 환경을 옮겨야 한다면 사용자와 유지보수자 모두 불필요한 비용을 치른다. 같은 하네스에서 다른 모델을 시험하면 사용자에게는 선택권이 생기고 팀에는 비교 피드백이 돌아온다. 인터뷰는 이런 설계 의도를 설명하며 모든 모델이 동일하게 호환되거나 같은 성능을 낸다는 보장은 제시하지 않는다.

로컬과 클라우드 실행을 가르는 환경의 문제

인터뷰에서 설명하는 기본 실행은 로컬 머신의 샌드박스 안에서 도구를 사용하는 방식이다. 샌드박스 밖의 추가 권한이 필요하면 사용자에게 요청한다. 클라우드 실행을 선택하면 관리되는 VM과 Kata container 기반 환경에서 작업하고 로컬 장치는 입력과 출력 전달을 맡는다. 이는 소개된 실행 모델이며 샌드박스가 모든 보안 위험을 없앤다는 뜻은 아니다.

로컬 개발이 편한 이유는 데이터베이스와 서버, 개발 도구가 이미 준비돼 있기 때문이다. 과거 클라우드 개발 환경에는 초기 설정과 유지 비용이 있어 개인이나 작은 팀이 전환할 유인이 약했다. Sottiaux는 에이전트가 이런 환경 구성을 대신하면 클라우드 개발 머신이 다시 매력적일 수 있다고 본다. 로컬과 클라우드를 더 매끄럽게 함께 쓰는 모습은 발전 방향으로 설명되며 모든 프로젝트의 환경 복제가 이미 자동 해결됐다는 주장은 아니다.

하네스와 모델은 함께 바뀐다

하네스는 모델에 도구를 제공하고 실행을 조율하며 권한과 사용자 제어를 다루는 소프트웨어다. 모델이 테스트를 잘 실행하지 않을 때는 지침으로 상기시키고 사용자가 기대하는 동작을 안정적으로 수행하도록 보완한다. 이후 모델이 같은 의도를 더 잘 이해하도록 학습되면 반복 지침과 보조 코드 일부를 줄일 수 있다. Sottiaux가 하네스는 모델보다 조금 앞서간다고 말하는 이유다.

제품의 부족함을 발견하면 연구팀과 엔지니어링팀은 하네스에서 해결할지 모델 학습으로 해결할지를 함께 판단한다. 모델 개선을 곧 받을 수 있다면 복잡한 우회 코드를 만들지 않고 기다리는 선택도 가능하다. 코딩뿐 아니라 금융·커뮤니케이션·마케팅 같은 사용 영역의 피드백을 분류해 우선순위를 정한다. 다만 진행자 Orosz는 마무리에서 도구와 연결 기능까지 단순한 보조 장치로 볼 수는 없다고 덧붙인다. 일부 지침이 줄어드는 현상을 하네스 전체가 불필요해지는 미래로 확대해서는 안 된다.

코드 리뷰에서 남는 의도와 계약의 논의

Codex 팀의 신규 구성원은 코드뿐 아니라 Slack과 문서에서 프로젝트의 맥락을 찾는 데 에이전트를 활용한다. 공유된 채널과 접근 가능한 문서가 많아야 왜 어떤 결정을 했는지 질문할 수 있다. 새로운 변경에서는 사용자에게 가치가 있는지, 제품 전체와 어울리는지, 유지할 만한지에 대한 근거를 요구한다. 빠르게 코드를 만들 수 있다는 사실만으로 모든 기능을 추가하는 것은 아니다.

Sottiaux는 AI 리뷰가 여러 단계의 의존성을 따라가며 문서와 구현의 차이, 논리 오류와 보안 문제를 찾는 방향으로 발전했다고 설명한다. OpenAI 내부에서는 보안 문제가 표시된 PR의 병합을 막는 절차도 운영한다고 말한다. 그러나 이 인터뷰는 탐지율이나 오탐률, 누락률을 제시하지 않으므로 모든 변경이 안전하다고 단정할 수 없다. 자동 검증의 능력과 최종 안전 보장은 구분해야 한다.

사람 사이의 리뷰에는 정확성 확인 외에도 지식을 나누고 설계 의도를 맞추는 기능이 있었다. 그 논의를 반드시 코드 diff 위에서만 할 필요는 없다는 것이 그의 관점이다. 시스템이 무엇을 해야 하는지, 자원 사용과 데이터 접근, 보안에서 어떤 불변 조건을 지켜야 하는지를 먼저 합의할 수 있다. 내부 구현을 자주 바꾸더라도 그 계약이 유지되는지 검증할 수 있어야 사람의 주의력을 다른 결정에 쓸 수 있다.

변경 비용이 낮아질수록 좋은 경계가 중요해진다

의존성 업데이트와 보안 패치, 반복 유지보수는 에이전트가 맡기 좋은 작업으로 제시된다. 변경 기록과 문서가 충분하고 검증할 수 있다면 예전에는 미뤘을 수정을 더 쉽게 진행할 수 있다. 재설계의 비용이 낮아지면 새로운 부하나 기능에 맞춰 구조를 바꾸는 선택도 빨라진다. 유지보수가 거의 무료가 된다는 표현은 Sottiaux의 전망에 가까우며 모든 조직에서 측정된 결과는 아니다.

동시에 좋은 추상화와 경계는 더 빠른 변경을 가능하게 하는 조건으로 남는다. 한 영역의 구현을 바꾸어도 다른 서비스가 영향을 받지 않도록 불변 조건과 인터페이스를 정해야 한다. 여러 에이전트가 동시에 기여하면 과거에 팀이 천천히 커지며 겪던 조정 문제가 짧은 시간에 나타날 수 있다. 코드 생성 속도를 높이는 일과 서로 충돌하지 않는 구조를 준비하는 일을 함께 생각해야 한다.

ChatGPT와 Codex의 통합은 인프라 통합이기도 하다

ChatGPT에 Codex를 넣는 작업은 탭 하나를 추가하는 것처럼 보이지만 실행 방식이 다른 두 시스템을 맞춰야 했다. 관리되는 대규모 클라우드 서비스와 로컬 중심 에이전트의 능력을 연결하고 넓은 사용자층이 감당할 비용으로 제공해야 했다. 팀은 클라우드 컴퓨터에서 전체 Codex 하네스를 실행하는 방식과 플러그인·라이브러리의 차이를 정리했다. 인터뷰에서 목표로 삼는 것은 어느 화면에서 시작하든 같은 지능과 능력을 활용하는 통합 경험이다.

이 과정에서 Codex는 구현뿐 아니라 팀의 토론과 결정을 기록하는 역할도 맡았다. Sottiaux는 통합 방향과 명칭을 둘러싼 논의가 정리돼 남았다는 점을 흥미롭게 설명한다. Orosz는 마무리에서 편리함과 함께 AI가 모든 대화를 지켜보는 듯한 불편함도 느낀다고 밝힌다. 기록의 효용과 정보 접근의 경계는 같은 기능에서 함께 생기는 문제다.

도구 활용보다 오래 남는 호기심과 명확한 의도

Sottiaux는 이동 중에 음성으로 질문을 보내고 자신에게 맞는 보고서나 코드 탐색 결과를 받아보는 방식으로 도구를 쓴다. 아이디어를 빠르게 시제품으로 만들어 동료가 비판하거나 영감을 얻을 대상으로 삼기도 한다. 만들어 볼 수 있다는 것과 실제 출시해야 한다는 것은 구분한다. 구현이 쉬워지면 더 많은 가설을 시험할 수 있지만 무엇을 선택할지의 판단은 계속 필요하다.

그가 엔지니어에게 강조하는 것은 시스템이 어떻게 작동하는지 깊이 궁금해하고 낯선 코드베이스를 빠르게 이해하는 능력이다. 에이전트는 좋은 질문을 반복하며 학습하는 데 도움이 될 수 있다. 동시에 누구의 어떤 문제를 해결하는지, 왜 그 결과가 필요한지 명확히 설명할 수 있어야 한다. 제품을 사용할 사람들과 연결돼 요구를 이해하는 감각이 도구 사용 숙련도만큼 중요하다는 결론이다.

참고 자료

The Pragmatic Engineer — Building Codex with Tibo Sottiaux

The Pragmatic Engineer — How Codex is built

영어 자동자막 전체를 읽고 공식 설명과 관련 취재 글로 인명·제품명을 대조했다. 광고는 제외했으며 성능과 개발 속도에 관한 발언은 인터뷰 참여자의 경험·전망으로 구분했다. 관련 취재 글의 공개 부분을 참고했지만 유료 본문 전체를 확보한 것은 아니다.