이번 주 X(트위터)에서 OpenAI 내부 엔지니어링 파이프라인 다이어그램이 반쯤 입소문을 탔습니다. 이 다이어그램은 '소프트웨어 빌더가 결과물을 정의한다'는 단계부터 프로덕션 그래프를 모니터링하고 자체 인시던트 보고서를 제출하는 에이전트에 이르기까지 10개의 상자를 보여주었습니다. 출처는 Gergely Orosz의 뉴스레터인 The Pragmatic Engineer의 ‘OpenAI의 에이전트 기반 소프트웨어 팩토리’라는 글이며, 다이어그램 자체는 X에서 빠르게 확산되었습니다.
대부분의 반응은 중요한 한 가지 세부 사항을 놓쳤습니다. 그 10개의 상자 중 몇 개는 오늘날 설치할 수 있는 Codex 제품이 아니라 OpenAI의 내부 엔지니어링 설정을 설명합니다. 이 둘을 혼동하는 것이 이 다이어그램을 둘러싼 논의에서 가장 흔한 실수입니다. 이 기사는 각 상자를 하나씩 살펴보며 외부 팀이 실제로 복사할 수 있는 유일한 단계인 CI에서 멈춥니다.
10가지 단계, 순서대로
이 다이어그램은 왼쪽에서 오른쪽으로 루프처럼 읽힙니다. 사람이 목표를 설정하고, 에이전트가 코드를 작성하며, 자동화된 게이트가 이를 확인하고, 에이전트는 그 게이트를 통과할 때까지 계속 반복합니다. 각 단계에 대해 내부와 출시된 부분의 경계를 표시한 전체 순서는 다음과 같습니다.
| # | 단계 | 내용 | 내부 전용 또는 Codex에 포함된 기능 |
|---|---|---|---|
| 1 | 소프트웨어 빌더 | 엔지니어 또는 PM이 결과물을 정의함 | 소프트웨어가 아닌 사람의 단계 |
| 2 | Codex가 코드를 작성/수정 | 소스, 문서, GitHub, Slack, Notion, 내부 기술, 그리고 Databricks 및 Datadog와 같은 데이터 시스템에서 컨텍스트를 가져옴 | 출시된 Codex는 코드를 작성함; 내부 컨텍스트 그래프(Slack, Notion, 내부 데이터)는 내부 전용임 |
| 3 | CI: 빌드 + 테스트 | 에이전트 규모의 부하를 위해 재구축되는 파이프라인, 그리고 "Perf Harness" | 출시됨 (자체 CI); OpenAI의 특정 확장 작업은 내부 전용임 |
| 4 | 에이전트 기반 코드 검토 | 데이터, 인프라, 클라우드, 보안 전문 에이전트의 병렬 검토 및 위험 분류 | 내부 전용 |
| 5 | 저위험 결정 | 저위험 변경 사항은 진행; 고위험 변경 사항은 추가적인 인간 엔지니어 검토를 받음 | 내부 전용 |
| 6 | 에이전트 기반 배포 | 에이전트가 기능 플래그 롤아웃을 포함하여 변경 사항을 프로덕션 환경으로 "돌보고" 자체 대시보드를 구축함 | 내부 전용 |
| 7 | 프로덕션 모니터링 | 에이전트가 OpenAI 내부 관측성 스택에서 그래프, 신호, 경고를 모니터링함 | 내부 전용 |
| 8 | 장애 감지 -> Sevbot | 인시던트를 조사하고, 완화 방안을 제안하며, 질문에 답변함 | 내부 전용 |
| 9 | 성능 팩토리 | 중복 경고를 필터링하고, 지연 시간 회귀를 찾아내며, 수정 사항을 제안함 | 내부 전용 |
| 10 | 루프 백 | 에이전트가 CI 및 검토를 통과할 때까지 문제를 수정하고, 빌더는 제안된 수정 사항을 받음 | 내부 루프를 설명함 |
정확히 한 단계, 즉 CI 단계와 2단계의 일부만이 외부 팀이 가리키며 “우리도 저것이 있다”고 말할 수 있는 부분입니다. 에이전트 기반 검토부터 Sevbot에 이르는 모든 것은 OpenAI의 내부 구축물입니다.
내부 전용 칼럼은 또한 소싱 문제입니다. OpenAI가 방화벽 뒤에 보관하는 부분, 즉 오케스트레이션, 검토 게이트, 사람의 승인은 대부분의 팀이 갖추지 못한 계층입니다. Sharkly는 이를 구축할 수 있는 공급업체 중립적인 한 곳입니다. 빌더는 결과물을 작업(Task)으로 정의하고, 이를 에이전트에 할당하며, 에이전트는 이미 가지고 있는 런타임(Claude Code 또는 Codex)을 사용하여 컴퓨터에서 실행됩니다. '릴리스 준비 완료(Ready for Release)'는 어떤 것이든 '완료(Done)' 상태에 도달하기 전에 사람이 변경해야 하는 상태이므로, 승인 작업은 파이프라인의 역할이 아니라 사람의 역할로 남습니다. Sharkly는 Codex를 대체하거나 자체적으로 코드를 작성하지 않습니다. 이는 이미 비용을 지불하고 사용하는 런타임을 실행하며 주변 루프가 존재할 수 있는 공간을 제공합니다.
단계 1-2: 여전히 사람이 목표를 설정하고, Codex가 코드를 작성합니다
소프트웨어 빌더, 즉 엔지니어 또는 제품 관리자가 원하는 결과물을 정의합니다. 그러면 Codex는 그 목표에 도달하고 결과가 작동하는지 확인할 때까지 일련의 코드 변경을 수행합니다. 이 검증 루프는 오늘날 출시되는 Codex의 일부입니다. 즉, 데스크톱 앱(Mac은 2026년 2월, Windows는 3월), 2026년 7월부터 제공되는 ChatGPT Work 통합, 역할 기반 플러그인 및 스킬, 그리고 장기간 실행되는 작업을 위한 /goal 명령입니다. 해당 명령의 작동 방식이 궁금하다면, 자율 에이전트 실행을 위한 /goal 명령에 대해 별도로 다루었습니다.
출시되지 않은 것은 Codex에 내부적으로 컨텍스트를 제공하는 그래프입니다. Slack 스레드부터 Databricks 대시보드까지 거의 모든 OpenAI 시스템이 해당됩니다. Orosz의 기사는 이를 직접적으로 언급합니다. OpenAI의 내부 Codex는 “거의 모든 OpenAI 시스템에 연결되어 있기 때문에 외부 Codex보다 훨씬 더 발전되어 있다”고 말입니다. 내부 Codex와 외부 Codex 사이의 이러한 격차가 이 기사의 진정한 핵심입니다.
단계 3: CI는 루프가 실제로 강제되는 곳입니다
이 단계는 OpenAI뿐만 아니라 모든 팀이 이미 소유하고 있는 전체 파이프라인의 유일한 상자이기 때문에 속도를 늦춰볼 가치가 있습니다. 이 기사는 OpenAI의 CI가 약 6개월 동안 부하를 약 10배 증가시키기 위해 재구축되고 있다고 언급합니다. 이는 에이전트가 이제 인간 혼자서 했던 것보다 훨씬 더 많은 변경 사항을 파이프라인을 통해 푸시하기 때문입니다. "Perf Harness"가 함께 실행되어 성능 저하가 검토에 도달하기 전에 포착합니다.
놓치기 쉬운 부분이 있습니다. 'CI와 검토를 통과할 때까지 문제를 수정하는' 에이전트는 CI가 실제로 무엇을 확인하는지에 따라 신뢰도가 결정됩니다. 테스트 스위트가 단위 로직만 다루고 API 계약을 다루지 않는다면, 에이전트는 여전히 중대한 변경 사항을 포함하는 그린 빌드를 루프할 수 있습니다. 상태 코드, 스키마 형태, 인증 동작, 부하 시 응답 시간 예산은 대부분의 팀이 단위 테스트에 비해 투자를 적게 하는 정확한 검사 유형입니다. 바로 이 지점에 Apidog이 적합합니다. CI 단계 내에서 Apidog CLI를 통해 Apidog의 테스트 시나리오를 실행하면 에이전트에게 '코드가 컴파일되었다'는 것보다 더 어려운 만족 기준을 제시하게 됩니다. 저희는 Codex 내 Apidog CLI에서 이 연결 방법에 대해 썼습니다. 이것이 Apidog가 이 파이프라인에서 수행하는 유일한 역할입니다. Apidog는 에이전트가 아니며, 배포, 검토 또는 인시던트 대응에 관여하지 않습니다.
단계 4-5: 전문 검토 에이전트 및 위험 결정
CI 통과 후, OpenAI의 내부 설정은 데이터, 인프라, 클라우드, 보안 전문 에이전트로부터 병렬 검토를 통해 변경 사항을 라우팅합니다. Orosz는 이를 "각 관련 인프라 팀의 인간 도메인 전문가가 모든 변경 사항을 검토하는 것과 동일하다"고 설명하는데, 이는 대부분의 인간 팀이 모든 풀 리퀘스트에 대해 배치할 수 있는 것보다 더 높은 검토 기준입니다. Codex의 출시된 코드 검토 기능은 이러한 내부 전문 에이전트와는 다른, 더 가벼운 기능입니다. 일반적인 에이전트 기반 검토자가 자신의 스택에 무엇을 할 수 있는지 결정하고 있다면, AI 코드 검토 도구에 대한 저희의 종합 가이드가 좋은 시작점이며, OpenAI의 에이전트 기반 검토 및 위험 게이트 설계에 대한 동반 기사는 이 특정 상자에 대해 더 깊이 다룹니다 (형제 링크, 링크 전에 라이브 확인).
위험 분류는 다음 단계를 결정합니다. 코드베이스의 저위험 영역은 에이전트가 자체 PR을 자동 승인하도록 선택할 수 있어, 해당 유형의 변경 사항에 대해서는 인간의 승인 절차를 완전히 제거합니다. 고위험 변경 사항은 더 많은 AI 검토 통과, 필수적인 인간 검토 또는 둘 다를 받습니다. OpenAI는 무엇이 저위험으로 간주되는지에 대한 정확한 규칙을 공개하지 않았으며, 여기에서 추측하지 않을 것입니다. OpenAI의 특정 설정 외에 일반화될 수 있는 한 가지 아이디어는 다음과 같습니다. 공개 API 계약에 대한 중대한 변경 사항은 아무리 diff가 작아 보이더라도 결코 저위험으로 분류되어서는 안 됩니다. OpenAPI 정의와 테스트를 동일한 위치에 유지하는 스펙 우선 도구는 스키마 diff가 줄 수 차이보다 훨씬 더 명확한 위험 신호이므로, 이러한 구분을 자동으로 적용하기 더 쉽게 만듭니다.
단계 6-8: 사람의 호출 없이 배포, 모니터링, 대응
변경 사항이 검토를 통과하면, 내부 에이전트가 기능 플래그 롤아웃을 포함하여 이를 프로덕션 환경으로 "돌보고", 해당 특정 변경 사항에 대한 자체 모니터링 대시보드를 구축합니다. 일단 서비스가 시작되면, 동일한 에이전트(또는 관련 에이전트)가 OpenAI의 내부 관측성 스택에서 그래프와 경고를 모니터링합니다. 문제가 발생하면 Sevbot이 개입합니다. Sevbot은 인시던트를 조사하고, 완화 방안을 제안하며, Slack에서 개발자 질문에 답변합니다. Sevbot이 하지 않는 일에 대해 정확히 알아두는 것이 중요합니다. Sevbot은 제안만 할 뿐, 실행하지는 않습니다. 사람은 여전히 완화 방안을 승인하고 온콜(oncall) 의무를 가집니다. 기사에서 명확히 언급하듯이, “온콜 근무는 과거의 일이 아닙니다.” 구매할 수 있는 Codex 제품에는 6단계부터 8단계까지의 어떤 기능도 존재하지 않습니다.
단계 9-10: 성능 회귀 및 루프 백
Perf Factory는 인시던트 경로와 함께 작동합니다. 이는 경고와 대시보드를 샅샅이 뒤져 중복 신호를 필터링하고, 실제 지연 시간 회귀를 찾아내며, 수정 사항을 제안하고, 이 수정 사항은 원래 빌더에게 다시 전달됩니다. Sevbot과 함께, 이것은 OpenAI가 경고 피로에 대응하는 방법입니다. 온콜 엔지니어가 모든 핑을 분류하는 대신, 에이전트가 먼저 사전 필터링하고 사전 진단합니다. 루프는 10단계에서 닫힙니다. 에이전트는 CI와 모든 검토 계층이 통과할 때까지 계속 수정합니다.
내부/외부 경계가 팀에 중요한 이유
이번 분기에 팀이 'OpenAI 스타일' 에이전트 기반 엔지니어링을 채택할 수 있는지 평가하고 있다면, 솔직한 답변은 다음과 같습니다. 1단계부터 3단계까지는 오늘 당장 채택할 수 있으며, 4단계부터 9단계까지는 구매 가능한 기능이 아니라 방향성을 설명합니다. 이는 OpenAI를 비난하는 것이 아닙니다. 그러한 규모의 내부 도구는 구축하는 데 수년이 걸립니다. orchflows라는 한 오픈소스 프로젝트는 Claude Code 및 Codex용 /software-factory 명령을 사용하여 이 루프를 근사치로 구현하려는 공개적인 시도입니다. 해당 README는 목표에 대해 솔직하게 설명하며, 라이브러리 전체 대신 두 가지 기술만 있으면 된다고 주장합니다. 이는 초기 단계의 비공개 프로젝트이며 OpenAI 릴리스가 아니므로, 즉시 사용할 수 있는 팩토리보다는 참조 구현으로 간주해야 합니다.
OpenAI 내부에서의 채택은 맞춤형 내부 배관이 필요 없는 부분에서 빠르게 진행되었습니다. 비 엔지니어링 팀에서의 Codex 사용률은 2026년 2월부터 5월까지 4개월 만에 약 0%에서 90%로 증가했습니다. 이는 파이프라인 다이어그램만으로는 알 수 없는 더 분명한 신호입니다. 이는 쉬운 부분(명시된 목표를 향해 코드를 작성하는 에이전트)이 이미 OpenAI에서 일반적이라는 것을 의미하는 반면, 어려운 부분(모든 내부 시스템에 연결된 에이전트 기반 배포, 검토 및 인시던트 대응)은 여전히 맞춤형으로 존재한다는 것을 보여줍니다.
인간의 역할로 남는 것
이 기사는 변하지 않는 것에 대해 신중하게 다룹니다. 빌더는 여전히 결과물을 정의합니다. 인간은 여전히 고위험 변경 사항을 승인하고 인시던트 완화를 승인합니다. 누군가는 Sevbot이 사후에 무엇을 했는지 여전히 검토하며, 온콜 교대 근무는 여전히 존재합니다. 이 기사가 마무리되는 문장은 어떤 통계보다도 변화를 잘 포착합니다. “판단, 우선순위 지정, 취향이 더욱 중요해지고 있다.” 두 가지 주의사항 또한 이를 현실에 기반하게 합니다. 모바일 앱 스토어 검토는 에이전트가 우회할 수 없는 수동적인 병목 현상이며, 인프라 확장은 해결된 문제가 아니라 매달 벌어지는 싸움입니다.
벤더가 4단계부터 9단계까지의 기능을 출시하기를 기다리는 대신, 1단계부터 3단계까지의 자체 버전을 구축하고 있다면, 파이프라인에 이미 존재하는 게이트인 CI부터 시작하십시오. Codex를 중심으로 더 가벼운 소프트웨어 팩토리 구축에 대한 저희의 동반 기사에서는 해당 구축 과정을 자세히 설명하며(형제 링크, 링크 전에 라이브 확인), Sevbot/Perf Factory 설계는 OpenAI의 성능 팩토리 및 Sevbot에 대한 저희 기사에서 별도로 다루어집니다(형제 링크, 링크 전에 라이브 확인). 테스트가 통과할 때까지 반복하는 에이전트는 해당 테스트가 실제로 무언가를 주장할 때만 좋은 아이디어입니다. Apidog은 API 계약 테스트를 사양 옆에 유지하여, 인간뿐만 아니라 에이전트가 변경 사항을 푸시하기 시작할 때에도 해당 게이트가 정직하게 유지되도록 합니다.