OpenAI의 에이전틱 소프트웨어 공장 내부

원문: Inside OpenAI's agentic software factory (Gergely Orosz, The Pragmatic Engineer, 2026-09-16)

들어가며

필자는 토큰 예산에 제한을 두지 않는 흔치 않은 환경을 취재하기 위해 OpenAI 본사를 다시 방문했습니다. 이곳에서는 엔지니어와 연구자뿐만 아니라 재무와 마케팅 담당자까지 모두 무제한에 가까운 토큰을 사용하며 일합니다. 필자가 작년에 방문했을 때와 비교하면 가장 크게 달라진 점은 Codex의 위상입니다. 1년 사이에 Codex는 있으면 좋은 도구에서 회사의 거의 모든 업무를 지탱하는 기반으로 바뀌었습니다.

취재에는 일곱 명의 엔지니어링 리더와 엔지니어가 참여했습니다. Venkat Venkataramani(Applied Infra 엔지니어링 부사장), Sulman Choudhry(ChatGPT 엔지니어링 총괄), Andrew Ambrosino(데스크톱 리드), Joe Gershenson(Core Agent 팀 리드), Akshay Nathan(생산성 팀 엔지니어링 리드), Ahmed Ibrahim(Codex 엔지니어), Steve Coffey(Responses API 엔지니어)입니다.

1. Codex가 회사 전체를 장악한 과정

방문에서 가장 두드러진 인상은 대략 1월을 기점으로 Codex와 ChatGPT Work가 회사의 모든 업무를 잠식했다는 사실입니다. 데스크톱 리드 Andrew Ambrosino는 최근 몇 달의 핵심 주제를 "이제 모든 것이 코딩 에이전트가 되었다"라고 정리했습니다. 눈에 보이는 코드가 최종 산출물이 아니더라도 산출물을 작성하는 주체는 에이전트라는 뜻입니다. 삶의 거의 모든 일이 소프트웨어를 통해 이루어지는 상황에서, 반복하고 추론하며 코드를 작성하는 능력은 결국 무엇이든 해내는 능력과 같다는 설명입니다.

비엔지니어링 조직의 채택 속도가 특히 극적입니다. 재무, 채용, 법무처럼 코드와 거리가 먼 조직의 Codex 사용률이 4개월 만에 0%에 가까운 수준에서 90%까지 올라갔습니다. 지금은 거의 모든 임직원이 Codex와 ChatGPT Work를 매주 사용합니다. 배경에는 제품 출시 일정이 있습니다. OpenAI는 2월에 macOS용 Codex 앱을, 3월에 Windows용 앱을, 7월에는 Codex 하네스를 기반으로 하는 ChatGPT Work를 내놓았습니다. 비엔지니어들은 이 흐름에 따라 업무 전반을 Codex로 옮기고 다시 Work로 옮겼습니다. 다만 사내에서 쓰는 Codex는 외부 버전보다 훨씬 고도화되어 있다는 점을 감안해야 합니다. 사내 버전은 OpenAI의 거의 모든 시스템에 연결되어 있습니다.

흥미로운 대목은 채택이 시작된 시점입니다. 2월부터 4월까지 Codex 앱은 여전히 화면에 코드를 그대로 노출했고 비개발자에게 상당히 불친절했는데도, 비엔지니어링 조직에서 이미 40% 가까운 채택률이 나왔습니다. 조사를 수행하거나 발표 자료와 문서, 스프레드시트처럼 내용이 풍부한 산출물을 만들어 내는 복잡한 작업을 처리할 수 있었기 때문입니다. 그 무렵 어렵게 도구를 익힌 사람들이 지금은 가장 무겁게 사용하는 이용자가 되었습니다.

채택을 끌어올린 결정적 요인은 더 길고 복잡한 작업을 맡길 수 있게 된 변화였습니다. OpenAI는 Codex에 /goal 설정을 추가해서, 목표를 지정하면 에이전트가 완료될 때까지 계속 작업하도록 만들었습니다. 4월부터 5월 사이에 사용률은 60%에서 90%로 급등했습니다. Andrew는 하네스가 장시간 실행 작업을 다루는 능력이 개선된 점을 주된 원인으로 봅니다. 그는 사람들이 하나의 스레드를 훨씬 길게, 때로는 며칠씩 유지하는 현상이 가장 큰 변화라고 말합니다. 목표를 설정해 두고 모델이 계속 돌아가게 만드는 방식입니다. 그리고 Codex가 장시간 작업을 잘 처리하게 되자 오히려 사람들이 여러 작업을 동시에 병렬로 돌리는 빈도는 줄어들었습니다. 장시간 실행되는 에이전트가 필요에 따라 다른 에이전트를 파생시키면서, 사람이 직접 관리해야 하는 표면적을 줄여 주기 때문입니다.

Codex 팀은 또 다른 원인으로 "인식의 격차"를 지목합니다. 생산성 팀 엔지니어링 리드 Akshay Nathan의 설명에 따르면, 오랫동안 문제는 모델은 유능한데 제품이 그 역량을 충분히 끌어내지 못하는 "역량 과잉" 상태였습니다. 이제는 역량이 아니라 인식이 병목입니다. 일부 구성원은 Codex로 Slack을 모니터링하거나 Airtable을 갱신하거나 온보딩 자료를 만들 수 있다는 사실을 스스로 알아냈지만, 많은 사람은 한 가지 용도로만 쓰다가 동료를 통해 입소문으로 다른 활용법을 알게 됩니다. 수면 아래에는 아직 발견되지 않은 활용 방식이 훨씬 많이 남아 있다는 것입니다.

역할별, 팀별 플러그인을 만들어 배포하는 관행도 확산을 가속했습니다. 각 조직이 자기 업무에 맞는 워크플로를 플러그인 형태로 서로 배포하기 시작했습니다. Andrew는 범용 코딩 에이전트만 제공하면 충분하지 않은 이유를 이렇게 설명합니다. 무엇이든 할 수 있는 제품을 만들었다면 각 팀이 그것을 자기 것으로 만들 수단이 필요하고, 빈 상자만 건네줄 수는 없습니다. 스킬과 플러그인은 팀이 에이전트를 자기 업무에 맞게 적응시키는 장치이며, 때로는 에이전트가 스킬과 함께 사용할 브라우저처럼 앱 차원의 새로운 기능도 필요합니다. 그럼에도 동일한 구성 요소만으로 이미 상당히 다양한 직무를 포괄할 수 있다고 합니다.

ChatGPT Work 엔지니어링 팀에는 도메인 전문가가 직접 합류해 있습니다. 일부 영역에서는 모델이 개발자보다 더 "똑똑해져서" 개발자가 자신의 취향을 하네스에 주입할 수 없게 되었습니다. 그래서 해당 분야의 전문가를 엔지니어링 팀에 온보딩시켜, 좋은 발표 자료나 스프레드시트, 사업 보고서가 어떤 모습인지 개발자에게 조언하도록 합니다. ChatGPT Work가 비엔지니어링 영역 전반에서 사용되면서 나타난 결과입니다. 물론 도메인 전문가를 엔지니어링 팀에 두는 방식은 품질 좋은 제품을 만드는 수십 년 묵은 모범 사례인데, 몇 년마다 다른 맥락에서 다시 발견되는 것처럼 보입니다.

OpenAI는 이제 Codex와 Work에 완전히 의존합니다. 의존도가 얼마나 높은지는 장애 상황에서 드러납니다. 경미한 장애가 발생해도 동료들이 보내는 사내 메시지가 자동 알림과 동시에, 또는 그보다 먼저 Codex 팀과 Work 팀에 도착합니다. 업무는 Codex와 Work를 통해 일어나고 그 밖의 경로는 사실상 없습니다. 외부에서 보면 단일 하네스에 이 정도로 의존하는 모습이 특히 눈에 띕니다. 불과 2년 전에는 AI 에이전트라는 것이 없었고 고도화된 자동 완성만 있었습니다.

2. IDE와 풀 리퀘스트의 종말

작년 말까지 Codex 팀은 데스크톱 앱을 출시할지를 두고 의견이 갈렸습니다. Andrew가 회상하는 당시의 망설임은 이렇습니다. 2025년 12월까지도 출시 여부를 확신하지 못했는데, 이미 터미널에서 쓰는 Codex CLI가 있고 기능이 풍부한 대형 IDE도 존재하는 상황에서 터미널과 IDE 사이에 놓인 개발 도구에 자리가 있을지 의문이었습니다. 그는 이 제품이 아이패드처럼 어중간한 물건이 되는 미래를 떠올렸다고 합니다. 아이패드를 산 다음 거의 쓰지 않는 사람이 많은데, 결국 더 작고 휴대성이 좋은 스마트폰(이 비유에서는 CLI에 해당합니다)이나 기능이 풍부한 노트북(IDE에 해당합니다)을 쓰기 때문입니다. 게다가 11월에 Antigravity가 VS Code 포크로 출시되면서, Codex 앱도 VS Code를 포크해야 하지 않겠느냐는 압박이 커졌습니다. 그럼에도 팀은 AI 에이전트가 좋아질수록 IDE의 중요성은 떨어진다는 직관을 따라 그 유혹을 물리쳤습니다.

실제로 1월 이후 IDE 사용량은 감소했고, OpenAI의 판단은 적절했던 것으로 보입니다. 다만 Codex 앱 자체는 조금씩 IDE에 가까워지고 있습니다. 예를 들어 앱 안에서 파일을 직접 편집하는 기능이 6월에 출시되었습니다.

CI/CD 시스템의 부하는 폭발적으로 증가했습니다. Codex의 생산성 향상을 보여 주는 지표 하나는 사내 개발 인프라를 통과하는 코드의 양입니다. 더 많은 코드가 만들어지고 푸시되면서 새로운 확장 과제가 생겼고, 팀은 현재 이 문제를 해결하는 데 집중하고 있습니다. Applied Infra 엔지니어링 부사장 Venkat Venkataramani는 엔지니어 한 명당 풀 리퀘스트 수가 하키 스틱 곡선처럼 가속하며 늘어나고 있다고 말합니다. 빌드와 테스트, 배포 파이프라인의 모든 구간에서 부하가 극적으로 증가했고, 일부 시스템은 대략 10배 수준입니다. 대부분의 회사라면 2~3년에 걸쳐 일어날 성장을 OpenAI는 약 6개월 만에 경험하고 있습니다. 이 정도로 가속되면 모든 곳에서 병목이 드러납니다. 버전 관리 시스템은 훨씬 많은 코드를 처리해야 하고, CI/CD도 그에 맞춰 확장되어야 하며, 프로덕션 릴리스 절차는 훨씬 높은 변경 빈도를 흡수해야 합니다. 그래서 매달 아침이면 새로운 인프라 확장 과제를 마주하게 됩니다. 다음 성장 단계에 대비할 용량을 충분히 확보했다고 생각하는 순간, 모델이 또 다른 역량의 물결을 열면서 시스템의 다른 곳에 새로운 병목이 생깁니다.

이 맥락에서 풀 리퀘스트와 코드 리뷰도 다시 검토되고 있습니다. 두 가지 모두 소프트웨어 엔지니어링의 핵심 원형이지만, 개발이 이 정도로 가속된 상황은 그것들을 재구상할 기회이기도 합니다. Venkat은 지금처럼 개발이 가속되는 와중에 우리가 스스로 던져야 할 질문은 그동안 당연하게 여겨 온 것들을 어떻게 다시 상상할지라고 말합니다. 지속적 통합과 지속적 배포 절차를 어떻게 재구상할지, 이런 세계에서 관측 가능성은 무엇을 의미하며 사람은 풀 리퀘스트와 어떻게 상호작용해야 하는지가 그런 질문입니다. 그가 보기에 오늘날의 코드 리뷰 방식은 점점 타당성을 잃어 가고 있고, 풀 리퀘스트도 마찬가지입니다.

이미 코드 변경을 여러 관점에서 살펴보는 에이전틱 코드 리뷰가 등장했습니다. 과거에는 클라우드 인프라 엔지니어와 보안 엔지니어가 모든 코드 변경을 하나하나 리뷰하는 것이 비현실적이었지만, 에이전트를 쓰면 가능해집니다. 배포 방식도 에이전트와 함께 재고할 수 있습니다. OpenAI는 코드 변경이든 피처 플래그 뒤의 변경이든, 하나의 변경을 프로덕션까지 손을 잡고 인도하는 에이전트를 만들고 있습니다. 이 에이전트는 관련 모니터링 그래프를 관찰하고, 필요하면 중요한 신호를 감시할 대시보드를 스스로 구축하기도 합니다. 점점 더 많은 코드 변경이 이런 에이전트의 감시를 받으며 프로덕션에 올라가고 있습니다.

갈수록 고통스러워지는 병목은 네이티브 모바일 앱 배포입니다. 풀 리퀘스트가 열 배로 늘어나면 백엔드나 웹에 배포하는 것도 쉽지 않고 더 많은 인프라가 필요합니다. CI/CD를 개편하고 실행 용량을 충분히 확보한 다음에는, 그만큼 많은 풀 리퀘스트를 프로덕션으로 내보내야 합니다. 그런데 iOS와 Android 앱은 모든 업데이트가 Apple과 Google의 수동 심사를 거쳐야 하고, 이 절차에는 수 시간에서 수 일이 걸립니다.

ChatGPT 엔지니어링 총괄 Sulman Choudhry는 이 심사 병목이 반복 속도에 어떤 영향을 주는지 설명했습니다. 그는 과거 Facebook에서 일하면서 이 회사가 모바일 릴리스 속도를 끌어올리던 과정을 기억합니다. 2010년대에 Facebook은 네이티브 모바일 코드를 더 빠르게 출시하는 방법에서 중요한 돌파구를 찾았고, 앱스토어 릴리스 주기를 월 단위에서 격주로, 다시 주 단위로 단축했습니다. 동시에 실험 체계와 피처 플래그를 도입해서 아직 공개 준비가 되지 않은 코드도 먼저 배포하고 준비가 끝나면 원격으로 기능을 켜도록 만들었습니다. 이 모델은 모바일 개발에 훨씬 큰 속도를 가져왔습니다.

Sulman은 Codex 시대에 이 문제의 다음 판본을 마주하고 있다고 봅니다. 코드 생성은 극적으로 빨라졌지만 그 코드를 네이티브 모바일에서 사용자 손에 전달하는 속도는 그렇지 않습니다. 특히 Codex는 모바일 사용 비중이 높아서 이 격차가 회사와 사용자 모두에게 이미 고통스럽게 느껴지고 있습니다. 그는 이 압력이 빠르게 커질 것으로 예상합니다. 소프트웨어를 몇 분 만에 작성할 수 있는데 그것을 휴대폰에 올리기 위해 며칠이나 몇 주를 기다리는 상황은 점점 더 부조리하게 보이기 시작합니다. 네이티브 모바일에 코드를 출시하는 속도가 웹에 출시하는 속도와 같아지는 세계를 목표로 삼아야 하며, 그러기 위해서는 무엇을 출시하고 언제 출시하며 무엇을 원격으로 활성화할 수 있는지에 관한 창의적인 재고가 필요합니다. 그의 평가에 따르면 지금은 그 목표에 전혀 근접하지 못한 상태입니다.

네이티브 앱 출시가 앱스토어가 시작된 2008년과 똑같은 문제를 여전히 안고 있다는 점에는 아이러니가 있습니다. 18년이 지나도록 크게 달라진 것이 없습니다. Apple은 의미 있는 사용자 경험 변경을 심사 없이 배포하는 것을 아직 공식적으로 허용하지 않습니다.

3. OpenAI의 에이전틱 소프트웨어 공장

"소프트웨어 공장"이라는 개념은 로봇과 사람이 함께 자동차를 만드는 물리적 공장에 대응합니다. 소프트웨어 맥락에서는 AI 에이전트와 사람이 함께 소프트웨어를 생산합니다. 제조업에는 사람이 없어서 조명조차 필요하지 않은 완전 자동화 "다크 팩토리"가 존재하는데, 소프트웨어 엔지니어링에서도 같은 수준의 완전 자동화가 나타날 수 있을지가 질문입니다. 현재 OpenAI에는 Codex를 중심으로 구축된 소프트웨어 공장이 실제로 돌아가고 있습니다. Venkat이 설명한 파이프라인은 다음과 같습니다.

1단계, 사람이 원하는 결과를 정의합니다. 소프트웨어 엔지니어나 프로덕트 매니저가 문제와 바라는 결과를 명세합니다. 이 단계에서는 판단과 우선순위 설정, 취향이 점점 더 중요해집니다. 흥미롭게도 Venkat은 OpenAI의 엔지니어들이 전통적인 시스템 엔지니어보다 프로덕트 매니저에 가까워지고 있다고 말했습니다.

2단계, Codex가 컨텍스트를 수집합니다. OpenAI는 모든 문서를 소스 코드 안으로 옮겼고, 덕분에 에이전트가 코드베이스를 훨씬 폭넓게 이해할 수 있게 되었습니다. Codex가 접근하는 대상은 다음과 같습니다.

• Git 저장소와 GitHub
• Slack과 Notion
• 내부 데이터 소스: Databricks, Datadog, 내부 로그 등
• 내부 Codex 스킬. 이 가운데 일부는 Codex 구현체 자신이 관리합니다

Codex가 사내 시스템에 이 정도로 깊이 연결되어 있기 때문에, 신규 입사자는 온보딩 기간에 생기는 어떤 질문이든 Codex에 물어보라고 안내받습니다. 놀라울 정도로 많은 컨텍스트를 갖고 있기 때문입니다.

3단계, Codex가 코드 변경을 구현합니다. 이 부분은 비교적 단순합니다. Codex는 목표에 도달할 때까지 일련의 코드 변경을 수행하고, 그 소프트웨어가 의도한 대로 동작하는지 검증합니다.

4단계, 빌드와 테스트를 거쳐 CI로 넘어갑니다. 에이전트가 코드를 빌드하고 테스트를 실행하며, 테스트가 깨지면 코드를 고친 다음 풀 리퀘스트를 생성합니다. 이 풀 리퀘스트는 CI 서버를 작동시켜 더 철저한 린터와 테스트 모음을 실행하게 만듭니다. 에이전트는 CI가 초록색이 될 때까지 풀 리퀘스트를 돌보며, 실패를 수정하고 풀 리퀘스트를 자동으로 갱신합니다. 여기에 새로 추가된 요소가 "퍼프 하네스"입니다. 에이전트는 이 하네스를 통해 문제가 될 만한 풀 리퀘스트를 Synthetics A/B 프레임워크로 보내 성능에 미치는 영향을 평가합니다.

5단계, 에이전틱 코드 리뷰를 수행합니다. OpenAI는 범용 AI 리뷰어 하나에 의존하지 않고, 각각 도메인 전문가 설정을 지닌 여러 에이전트를 파생시킵니다. Venkat은 이것이 관련 인프라 팀마다 사람 전문가를 두고 모든 변경을 리뷰받는 것과 동등하다고 봅니다.

필자는 클라우드 인프라 전문가라고 지시받은 에이전트가 범용 에이전트와 다른 리뷰를 내놓을지 회의적이었다고 밝힙니다. 다만 모든 Codex 에이전트가 OpenAI의 코드와 문서에 완전히 접근할 수 있으므로, 이 "클라우드 인프라 전문가" 에이전트는 인프라 구성과 모범 사례에 관한 컨텍스트를 상당히 축적했을 것이고 그래서 정확히 겨냥된 피드백을 제공할 수 있다고 정리합니다. 중요한 것은 이 도메인 전문가 에이전트를 어떻게 설정하는지, 어떤 컨텍스트에 접근할 수 있는지, 그리고 제한된 컨텍스트 윈도우를 최대한 활용하기 위해 자기 도메인에만 집중하도록 만드는지입니다.

코드 변경은 위험도에 따라 분류됩니다. 고위험 변경은 더 엄격한 절차로 보낼 수 있습니다. 예를 들어 AI 코드 리뷰를 더 많이 호출하거나, AI 에이전트의 작업이 끝난 뒤에 사람이 반드시 리뷰하도록 의무화할 수 있습니다. 저위험 변경은 더 가벼운 경로를 따릅니다. 코드베이스의 특정 영역은 저위험 풀 리퀘스트를 자동 승인하는 에이전트에 옵트인할 수 있고, 그러면 사람의 승인이 병목에서 제거되어 속도가 개선됩니다. 위험도 평가의 좋은 점은 추가적인 컴플라이언스 검토가 필요한 시점을 자동화할 수 있다는 것입니다. 다른 에이전트를 통한 자동 검토와 사람 검토 가운데 무엇이 필요한지를 판별합니다. 지금처럼 많은 풀 리퀘스트가 생산되는 상황에서는 도움 없이 사람이 모든 코드를 리뷰하는 일이 애초에 불가능합니다. CI에서와 마찬가지로, 코딩 에이전트는 리뷰 코멘트를 계속 돌보며 지적된 문제를 고치도록 풀 리퀘스트를 갱신합니다.

6단계, 에이전틱 배포를 진행합니다. 사람이 프로덕션 반영을 승인하면, 그 변경에는 전담 에이전트가 배정됩니다. 지시는 "이 변경이 안전하고 온전하게 프로덕션에 배포될 때까지 끝까지 돌봐라"로 요약할 수 있습니다. 에이전트는 코드 변경과 피처 플래그 뒤의 변경을 모두 인도합니다. 피처 플래그의 경우 에이전트는 다음 순서로 일합니다.

• 코드베이스를 읽고 해당 피처 플래그가 어디에 있는지 파악합니다
• 그 변경이 무엇을 하는지 이해합니다
• 어떤 신호가 성공과 실패를 가리키는지 결정합니다
• 직접 사용할 모니터링 대시보드를 스스로 구축합니다. 이는 상당히 인상적인 진전이며 필자에게도 처음 보는 방식입니다
• 관련 프로덕션 신호와 자신이 만든 대시보드를 관찰합니다

OpenAI의 장기 목표는 변경 단위로 배정되는 자율 SRE에 해당하는 에이전트를 확보해서, 배포를 거의 자율적으로 수행하게 만드는 것입니다.

7단계, 프로덕션을 관찰합니다. 프로덕션 시스템을 추적하는 수단은 두 가지입니다. 하나는 앞 단계에서 에이전트가 생성한 대시보드이고, 다른 하나는 로그와 메트릭, 트레이스, 와이드 이벤트 데이터를 생성하는 다수의 자체 도구를 포함한 사내 관측 스택입니다. Codex 이전의 방문과 비교해 크게 달라진 점은 대시보드를 만드는 주체입니다. 예전에는 엔지니어가 서비스를 감시할 대시보드를 만들었지만, 지금은 에이전트가 변경별 배포 단위의 세분도로 대시보드를 만듭니다.

8단계, 프로덕션 모니터링 결과가 개발로 환류합니다. OpenAI의 "퍼프 팩토리"는 에이전트를 사용해 알림과 대시보드를 훑어보고 신호를 중복 제거하며, 실제 지연 회귀를 식별한 뒤 근본 원인을 규명하고 수정안을 제안합니다. 계속 쌓이는 코드 변경이 유발한 성능 문제를 포착하는 데 도움이 되며, 워크플로를 배포 이후의 지속적 개선까지 확장합니다.

9단계, 장애에 대응합니다. Sevbot은 OpenAI의 사내 장애 대응 에이전트이며, 예상할 수 있듯이 이 역시 Codex 위에 구축되었습니다. 장애가 감지되면 봇이 깨어나서 다음 일을 수행합니다.

• 장애에 관한 컨텍스트를 수집합니다
• 가능한 완화 조치를 판단합니다. 다만 직접 실행하지는 않습니다
• Slack 채널의 구성원으로서 개발자의 질문에 답합니다
• 엔지니어가 특정 완화 조치를 적용하라고 지시하면 그대로 수행합니다

OpenAI는 Sevbot이 일부 장애를 완화할 때 자율적으로 조치할 수 있는 단계까지 가고자 합니다. 이상적인 그림은 Sevbot이 통상적인 장애를 자율적으로 처리하고 사람은 업무에 복귀한 뒤 그 조치를 검토하는 방식이어서, 근무 시간 외에 아무도 깨어나지 않는 상태입니다. 다만 현재로서는 이 회사에서도 온콜 근무가 사라지지 않았습니다.

4. 엔지니어링 도구와 관행의 변화

놀랍지 않게도, Codex는 내부 툴 구축의 용이성을 변화시키고 있으며 디버깅과 같은 표준 엔지니어링 관행에도 영향을 미치고 있습니다. 다음은 제가 OpenAI 관계자들과 대화하며 수집한 내용입니다.

(이하 원문 미확보)