OpenAI의 에이전트 기반 소프트웨어 팩토리

The Pragmatic Engineer 블로그에서 게르겔리 오로스(Gergely Orosz) 가 작성한 공개글만 번역했다.

Codex가 어떻게 OpenAI를 ‘장악’했는지, 최첨단 AI 연구소가 에이전트 기반 소프트웨어 팩토리를 어떻게 구축하고 있는지, 그리고 10억 명의 사용자를 위한 엔지니어링 과제를 심층 분석한다.

1. 개요

토큰을 제한 없이 쓸 수 있는 환경에서 일하는 경우는 드물다. 하지만 OpenAI에서는 엔지니어와 연구원부터 재무팀, 마케팅팀 직원까지 모두 그렇게 일한다. 최근 세계적인 프런티어 AI 연구소 중 하나인 OpenAI를 방문했다. 지금 이 회사가 어떻게 일하는지 알아보고, 소프트웨어 엔지니어라는 직업이 앞으로 어떻게 달라질지도 엿보고 싶었다.

지난해 OpenAI 본사를 방문했을 때와 비교하면 많은 것이 달라졌다. 불과 1년 사이에 Codex는 ‘있으면 좋은 도구’에서 회사의 거의 모든 업무를 떠받치는 핵심 도구가 됐다.

더 자세한 이야기를 듣기 위해 OpenAI의 엔지니어링 리더와 엔지니어 일곱 명을 만났다. 응용 인프라 엔지니어링 부사장 벤캇 벤카타라마니, 챗GPT 엔지니어링 총괄 술만 초드리, 데스크톱 부문 리드 앤드루 앰브로시노, 코어 에이전트 팀 리드 조 거셴슨, 생산성 부문 엔지니어링 리드 악셰이 네이선, 코덱스 엔지니어 아흐메드 이브라힘, 응답 API 엔지니어 스티브 코피다. 인터뷰에 참여해 준 모든 분께 감사한다.

2. 오늘 다룰 내용

오늘 다룰 내용은 다음과 같다.

1. 오픈AI 전반으로 확산된 Codex: 불과 몇 달 사이에 오픈AI의 비개발 직군 직원 거의 모두가 코덱스와 챗GPT 워크로 옮겨 갔다. 윗선에서 사용을 지시한 것도 아니었다.
2. 통합 개발 환경과 풀 리퀘스트의 종말: 코덱스 사용이 급증하기 시작한 1월부터 통합 개발 환경 사용은 줄고 있다. 풀 리퀘스트와 코드 리뷰도 다시 생각해야 할 때다.
3. 오픈AI의 에이전트 기반 소프트웨어 팩토리: 오픈AI는 에이전트가 작업과 검증을 자동으로 반복하는 여러 구조를 갖춘 ‘소프트웨어 공장’을 만들었다. 예를 들어 ‘성능 공장’은 실제 운영 환경을 모니터링하다가 성능 문제가 생기면 코덱스 에이전트를 실행해 자동으로 수정한다.
4. 달라지는 개발 도구와 작업 방식: 직접 만든 내부 도구는 점차 코덱스로 대체되고 있다. 디버깅에서도 전용 도구보다 코덱스를 선호하는 경우가 늘고 있다. 소프트웨어 공장에서는 에이전트의 실행과 검증을 관리하는 하네스의 효율이 핵심이다.
5. 10억 명의 사용자를 위한 개발: 오픈AI가 인프라를 확장하는 방법 먼저 외부 제품이나 서비스를 구매해 쓰고, 나중에 내부로 가져온다. 인프라를 여러 지역에 분산하는 방식과 처리 용량을 계획하는 전략, 그 과정에서 겪는 어려움도 살펴본다.
6. 오픈AI API의 안정성과 성능을 높이는 방법 중앙 처리 장치가 병목이 되는 상황, 의도적으로 배포 속도를 늦추는 이유, 시스템 부하 문제를 해결하는 방법을 다룬다.
7. 달라지는 소프트웨어 엔지니어의 일 엔지니어링 분야의 전문 영역 간 경계가 사라지고, 판단력과 주도성이 더 중요해지고 있다. 예전에는 ‘불가능하다’고 여겼던 전면 재작성과 시스템 이전도 이제 엔지니어 한두 명이 해낸다.

시작하기 전에 발행 일정 변경을 알린다. 이번 주에는 뉴욕에 머물며 엘디엑스3 콘퍼런스에 참석하고, 현지 스타트업과 기술 기업 몇 곳을 방문한다. 따라서 목요일에는 ‘더 펄스’를 발행하지 않는다. 다음 주부터는 평소 일정대로 발행한다.

일부 이메일 프로그램에서는 이 글의 뒷부분이 잘릴 수 있다. 온라인에서 잘림 없이 글 전체를 읽을 수 있다.

3. 오픈AI 전반으로 확산된 Codex

이번 본사 방문에서 가장 인상 깊었던 점은 1월 무렵부터 코덱스가, 최근에는 코덱스와 챗GPT 워크가 회사의 모든 업무에 자리 잡았다는 것이다. 데스크톱 부문 리드인 앤드루 앰브로시노는 이렇게 말했다.

“지난 몇 달간 가장 큰 변화는 이제 모든 일이 코딩 에이전트를 통해 이뤄진다는 점이다. 눈에 보이는 코드가 최종 결과물이든 아니든, 작업 결과물은 에이전트가 만든다.

이렇게 생각하면 된다. 우리 삶의 모든 일이 소프트웨어를 통해 이뤄진다. 컴퓨터 안에는 에이전트라는 강력한 도구가 있다. 이 도구가 작업을 반복하고, 추론하고, 코드를 작성할 수 있다는 것은 곧 모든 일을 할 수 있다는 뜻이다.”

아래 토큰 사용량 그래프는 사용이 얼마나 급격하게 늘었는지 보여준다.

Codex usage since August 2025 at OpenAI by department. Source: OpenAI

불과 4개월 사이에 재무, 채용, 법무 같은 비개발 조직의 코덱스 사용률은 거의 0%에서 90%로 올라갔다. 이제 오픈AI 직원 거의 모두가 매주 코덱스와 챗GPT 워크를 사용한다. 무슨 일이 있었던 것일까?

오픈AI는 2월에 맥용 코덱스 앱을, 3월에 윈도우용 앱을 출시했다. 7월에는 코덱스 하네스를 기반으로 작동하는 챗GPT 워크를 내놓았다. 이후 사내 비개발 직군 직원들은 모든 업무를 코덱스로 옮겼고, 이어 워크로 옮겨 갔다. 다만 오픈AI 내부에서 쓰는 코덱스는 거의 모든 사내 시스템에 연결돼 있어 외부에 공개된 버전보다 훨씬 발전돼 있다는 점을 감안해야 한다. 램프의 인스펙트 AI 에이전트가 사내 시스템에 연결된 방식과 비슷하다.

흥미로운 점은 Codex 앱이 비개발 직군 직원들에게 쓰기 어려웠던 시기에도 비개발 팀의 사용률이 40% 가까이 됐다는 것이다. 2월부터 4월까지는 앱 화면에 코드가 그대로 표시됐다. 그런데도 개발 조직 밖의 비전문가 동료들은 코덱스를 썼다. 자료를 조사하고 발표 자료나 문서, 스프레드시트를 만드는 등 내용과 형식이 풍부한 결과물을 내는 복잡한 작업을 해낼 수 있었기 때문이다. 지금은 이들이 코덱스를 아주 많이 사용한다.

더 복잡한 일을 더 오래 처리할 수 있게 되면서 사용이 늘었다. 오픈AI는 코덱스에 /goal 설정을 추가했다. 에이전트에게 목표를 정해 주면, 목표를 달성할 때까지 계속 작업하는 기능이다. 4월에서 5월 사이 사용률은 60%에서 90%로 급증했다. 앤드루는 하네스가 장시간 이어지는 작업을 더 잘 처리하게 된 것이 그 이유 중 하나라고 본다.

“가장 큰 변화는 사람들이 하나의 대화를 훨씬 오래 이어 가기 시작했다는 점이다. 이렇게 오래 사용할 수 있게 된 것이 돌파구가 됐다. 사람들이 하나의 대화에서 작업하는 시간을 보면 놀랍다. 며칠씩 이어 가기도 한다. 목표를 정해 놓고 모델이 계속 작업하게 두는 경우가 많다. Codex가 오래 걸리는 작업을 잘 처리하게 되면서 사람들이 직접 여러 일을 동시에 벌이는 경우는 줄어드는 듯하다. 오래 작업하는 에이전트가 다른 에이전트를 띄워 여러 일을 맡기는 경우가 많기 때문이다. 그만큼 사람이 직접 관리해야 할 일도 줄어든다.”

Codex 팀은 ‘기술이 할 수 있는 일과 사람들이 알고 있는 것 사이의 격차’도 빠른 확산의 또 다른 이유라고 본다. Productivity 팀의 엔지니어링 리드인 악셰이 네이선은 이렇게 말했다.

“오랫동안 모델의 능력을 제품이 충분히 끌어내지 못하는 ‘역량 격차’가 있었다. 모델은 많은 일을 할 수 있었지만, 제품이 그 능력을 온전히 활용하게 해 주지는 못했다. 이제는 사람들이 무엇을 할 수 있는지 아는 데서 격차가 생기고 있다. 어떤 사람들은 코덱스로 슬랙을 모니터링하거나, 에어테이블을 업데이트하거나, 신규 입사자 교육 자료를 만들 수 있다는 사실을 알아냈다. 하지만 여전히 많은 사람은 한 가지 작업에만 쓰다가 동료들의 이야기를 듣고 다른 활용법을 알게 된다.

그런데 코덱스로 할 수 있는 일 중 아직 알려지지 않은 것이 훨씬 더 많다.”

직무별·팀별 플러그인을 만들어 공유한다. 각 조직이 자기 직무에 유용한 업무 흐름을 플러그인으로 만들어 배포하기 시작한 것도 확산을 앞당겼다. 앤드루는 범용 코딩 에이전트를 제공하는 것만으로는 충분하지 않은 이유를 이렇게 설명했다.

“무엇이든 할 수 있는 제품을 만든다면, 각 팀이 자기 업무에 맞게 바꿔 쓸 방법도 있어야 한다. 모두에게 빈 상자만 건네줄 수는 없다. 스킬과 플러그인이 있으면 팀마다 에이전트를 자기 업무에 맞출 수 있다. 때로는 에이전트가 스킬과 함께 사용할 수 있는 브라우저처럼 앱에 새로운 기능을 추가해야 할 때도 있다. 하지만 지금 있는 기본 기능들만으로도 이미 다양한 직무를 지원할 수 있다.”

챗GPT 워크 개발팀에는 분야별 전문가가 함께 일한다. 일부 분야에서는 모델이 개발자보다 더 ‘똑똑해졌다’. 그러다 보니 개발자가 그 분야에서 무엇이 좋은 결과물인지 판단하는 감각을 하네스에 반영하기 어렵다. 그래서 해당 분야의 전문가를 개발팀에 합류시킨다. chatGPT Work가 개발 외의 여러 분야에서 널리 쓰이면서 생긴 변화다. 개발팀에 합류한 전문가들은 좋은 발표 자료나 스프레드시트, 업무 보고서가 어떤 모습이어야 하는지 개발자에게 조언한다.

물론 분야별 전문가가 개발팀에 참여하는 것은 좋은 제품을 만들기 위해 수십 년 전부터 권장해 온 방식이다. 몇 년마다 다른 맥락에서 같은 사실을 다시 발견하는 듯하다.

오픈AI는 코덱스와 워크에 전적으로 의존한다. 사소한 장애만 생겨도 동료들이 보낸 사내 메시지가 자동 경보와 동시에, 때로는 그보다 먼저 코덱스와 워크 팀에 도착할 정도다.

사실상 모든 업무가 코덱스와 워크를 통해 이뤄진다. 다른 도구로 처리하는 일은 거의 없다. 외부에서 보면 하나의 공통 하네스에 이토록 의존한다는 점이 특히 눈에 띈다. 불과 2년 전만 해도 AI 에이전트는 없었고, 고도화된 AI 자동 완성 기능만 있었다.

4. 통합 개발 환경과 풀 리퀘스트의 종말

지난해 말, Codex 팀은 Codex Desktop 앱을 출시할지를 두고 고민했다. 앤드루는 당시 망설였던 이유를 이렇게 회상했다.

“2025년 12월만 해도 코덱스 앱을 출시할지 확신하지 못했다. 터미널에서 쓰는 코덱스 명령줄 도구가 이미 있었고, 다양한 기능을 갖춘 대형 통합 개발 환경도 나와 있었다. 그렇다면 터미널과 통합 개발 환경 사이에 있는 개발 도구가 들어설 자리가 있을까? 내 머릿속에는 이 앱이 자리를 잡지 못하고 아이패드처럼 어딘가 애매한 제품이 되는 미래도 떠올랐다.

아이패드를 사 놓고 쓰지 않는 사람이 많다. 더 작고 휴대하기 편한 스마트폰을 쓰거나, 기능이 풍부한 노트북을 쓰기 때문이다. 이 비유에서 스마트폰은 명령줄 도구에, 노트북은 통합 개발 환경에 해당한다.

게다가 11월에는 비주얼 스튜디오 코드를 바탕으로 만든 안티그래비티가 나왔다. 그래서 우리도 비주얼 스튜디오 코드를 바탕으로 코덱스 앱을 만들었어야 하는 것 아닐까 하는 생각이 더 들었다. 그래도 그 유혹을 뿌리치고 직감을 따랐다. AI 에이전트가 발전할수록 통합 개발 환경의 중요성은 줄어들 것이라는 직감이었다.”

실제로 1월 이후 통합 개발 환경 사용이 줄어들면서 오픈AI의 선택은 옳았던 것으로 보인다. 다만 코덱스 앱도 조금씩 통합 개발 환경과 비슷해지고 있다. 예를 들어 6월에는 앱 안에서 파일을 편집하는 기능이 추가됐다.

지속적 통합·배포 시스템의 부하가 크게 늘고 있다. 코덱스로 생산성이 높아졌다는 징후 중 하나는 오픈AI의 개발 인프라를 거치는 코드의 양이 늘었다는 점이다. 코드를 더 많이 만들고 저장소에 올리면서 인프라 확장에 새로운 문제가 생겼고, 팀은 지금 이를 해결하는 데 집중하고 있다. 응용 인프라 엔지니어링 부사장 벤캇 벤카타라마니는 이렇게 말했다.

“엔지니어 한 명당 풀 리퀘스트(Pull Request) 수가 하키 스틱 모양의 곡선을 그리며 치솟고 있다. 증가 속도 자체가 점점 빨라지고 있다는 뜻이다. 빌드부터 테스트, 배포까지 모든 단계에서 부하가 크게 늘고 있다.

일부 시스템에서는 부하가 대략 10배로 늘었다. 대부분의 회사라면 2~3년에 걸쳐 일어날 증가다. 오픈AI에서는 약 6개월 만에 이런 일이 벌어진다.

이 정도로 빠르게 늘어나면 곳곳에서 병목이 드러난다. 버전 관리 시스템은 훨씬 더 많이 작성되고 저장소에 올라오는 코드를 처리해야 한다. 지속적 통합·배포 시스템도 그에 맞춰 확장해야 하고, 실제 서비스에 반영하는 절차도 훨씬 잦아진 변경을 감당해야 한다.

매달 눈을 뜨면 해결해야 할 새로운 인프라 확장 문제가 기다리고 있다. 다음 성장 단계에 필요한 처리 용량을 충분히 확보했다고 생각할 즈음이면, 모델이 또 새로운 일을 할 수 있게 된다. 그러면 시스템의 다른 곳에서 새로운 병목이 생긴다.”

이런 컨텍스트에서 풀 리퀘스트와 코드 리뷰를 다시 생각하고 있다. 그둘은 소프트웨어 개발의 기본 요소로 자리 잡아 왔다. 하지만 개발 속도가 이토록 빨라진 지금은 그 방식을 새롭게 구상할 기회이기도 하다. 벤캇은 이어 이렇게 말했다.

“개발 속도가 이토록 빨라지는 상황에서 우리가 물어야 할 것은, 그동안 당연하게 여겼던 여러 방식을 어떻게 새롭게 바꿀 것인가다. 예를 들어 지속적 통합과 지속적 배포 절차를 어떻게 바꿀 수 있을까? 이런 환경에서 시스템 상태를 관찰하고 파악한다는 것은 어떤 의미이며, 사람들은 풀 리퀘스트를 어떻게 다뤄야 할까?

내 생각에 지금의 코드 리뷰 방식은 갈수록 타당성을 잃고 있다. 풀 리퀘스트도 마찬가지다.

이제는 에이전트가 여러 관점에서 코드 변경 사항을 검토한다. 과거에는 클라우드 인프라 엔지니어와 보안 엔지니어가 모든 코드 변경을 하나하나 검토하는 것이 현실적으로 어려웠다. 에이전트가 있으면 가능해진다.

에이전트를 활용하면 코드 배포 방식도 다시 생각할 수 있다. 우리는 변경 사항이 실제 서비스에 반영될 때까지 전 과정을 챙기는 에이전트를 만들고 있다. 코드 변경이든, 기능 플래그로 제어하는 변경이든 마찬가지다. 이 에이전트는 관련 모니터링 그래프를 살펴보고, 중요한 신호를 추적할 대시보드를 직접 만들 수도 있다. 이런 에이전트의 감시 아래 실제 서비스에 반영되는 코드 변경이 점점 늘고 있다.”

네이티브 모바일 앱 배포는 갈수록 더 큰 병목이 되고 있다. 풀 리퀘스트가 10배로 늘어나면 백엔드나 웹에 배포하는 일도 어려워지고, 더 많은 인프라가 필요해진다. 그래도 지속적 통합·배포 시스템을 손보고 충분한 처리 용량을 확보하면, 늘어난 만큼의 변경 사항을 실제 서비스에 반영할 수 있다.

네이티브 iOS와 안드로이드 앱의 업데이트를 배포할 때는 문제가 생긴다. 앱을 업데이트할 때마다 애플과 구글의 수동 심사를 거쳐야 하고, 심사가 끝나기까지 몇 시간에서 며칠이 걸리기 때문이다.

챗GPT 엔지니어링 총괄 술만 초드리는 앱 심사라는 병목이 제품을 개선하고 다시 배포하는 속도에 어떤 영향을 주는지 설명했다. 페이스북에서 일했던 그는 당시 회사가 모바일 앱 출시 속도를 높였던 과정을 떠올렸다.

“2010년대에 페이스북은 네이티브 모바일 코드를 더 빨리 배포하는 데 중요한 돌파구를 마련했다. 앱스토어 출시 주기가 한 달에서 2주로, 다시 1주로 짧아졌다. 동시에 실험과 기능 플래그를 활용해 정식 공개할 준비가 되기 전에도 코드를 배포하고, 준비가 끝나면 원격으로 기능을 켤 수 있게 됐다.

이 방식 덕분에 모바일 개발 속도가 크게 빨라졌다.

코덱스 시대에는 같은 문제가 새로운 형태로 나타나고 있다고 생각한다. 코드 생성은 엄청나게 빨라지고 있지만, 네이티브 모바일 앱에서 그 코드를 사용자에게 전달하는 속도는 그렇지 않다. 특히 모바일 중심으로 사용되는 코덱스에서는 이 격차가 이미 우리와 사용자 모두에게 큰 불편을 주고 있다.

이 문제를 해결해야 한다는 압박은 빠르게 커질 것이다. 소프트웨어를 몇 분 만에 작성할 수 있는데 휴대폰에 반영하기까지 며칠이나 몇 주를 기다려야 한다면, 갈수록 납득하기 어려워진다.

네이티브 모바일에서도 웹만큼 빠르게 코드를 배포할 수 있는 환경을 목표로 삼아야 한다. 그러려면 무엇을 언제 배포하고, 어떤 기능을 원격으로 켤 수 있게 할지 창의적으로 다시 생각해야 할 것이다. 지금은 그 목표에 한참 못 미친다.”

네이티브 iOS나 안드로이드 앱을 배포할 때 겪는 문제가 앱스토어가 출시된 2008년과 지금도 똑같다는 점은 아이러니하다. 18년이 지났지만 크게 달라진 게 없다. 애플은 여전히 앱스토어 심사를 거치지 않고 사용자 경험에 실질적인 변화를 주는 업데이트를 배포하는 것을 공식적으로 허용하지 않는다.

5. 오픈AI의 에이전트 기반 소프트웨어 팩토리

‘소프트웨어 팩토리’은 로봇과 사람이 함께 자동차를 만드는 실제 공장과 비슷한 개념이다. 소프트웨어에서는 AI 에이전트와 사람이 함께 제품을 만든다. 일부 제조 현장은 사람이 없어 조명조차 필요 없는 완전 자동화된 ‘암흑 공장’으로 운영된다. 소프트웨어 개발에서도 이처럼 모든 과정이 자동화될 수 있을까? 현재 오픈AI에서는 코덱스를 중심으로 만든 ‘소프트웨어 공장’이 가동되고 있다.

응용 인프라 엔지니어링 부사장 벤캇 벤카타라마니의 설명을 바탕으로, 기존의 ‘전통적인’ 소프트웨어 개발 과정과 현재 오픈AI의 에이전트 기반 인프라 개발 과정을 비교하면 다음과 같다.

OpenAI’s “agentic software factory

개발 과정은 다음과 같다.

1. 사람이 원하는 결과를 정한다. 소프트웨어 엔지니어나 제품 관리자가 해결할 문제와 원하는 결과를 구체적으로 정한다. 이 단계에서는 판단력, 우선순위를 정하는 능력, 좋은 결과물을 알아보는 감각이 점점 더 중요해지고 있다. 흥미롭게도 벤캇은 오픈AI의 엔지니어들이 전통적인 시스템 엔지니어보다 제품 관리자에 가까워지고 있다고 말했다.

2. 코덱스가 맥락을 파악한다. 오픈AI는 모든 문서를 소스 코드 안으로 옮겼다. 덕분에 에이전트가 코드를 더 폭넓게 이해하기 쉬워졌다. 코덱스는 다음 자료에도 접근할 수 있다.

• 깃 저장소와 깃허브
• 슬랙과 노션
• 데이터브릭스, 데이터독, 내부 로그 등 사내 데이터
• 사내 코덱스 스킬. 일부는 오픈AI 내부의 코덱스가 직접 관리한다.

코덱스는 오픈AI의 시스템과 깊이 연결돼 있고, 놀라울 정도로 많은 맥락을 알고 있다. 그래서 신입 엔지니어에게는 입사 적응 과정에서 궁금한 것이 있으면 코덱스에 물어보라고 안내한다.

3. 코덱스가 코드를 수정한다. 이 부분은 비교적 단순하다. 코덱스가 작업을 시작해 목표에 도달할 때까지 코드를 수정하고, 소프트웨어가 의도대로 작동하는지 확인한다.

4. 빌드와 테스트를 거쳐 지속적 통합을 실행한다. 에이전트는 코드를 빌드하고 테스트한다. 테스트에 실패하면 코드를 고친 뒤 풀 리퀘스트를 만든다. 그러면 지속적 통합 서버가 실행돼 더 광범위한 코드 검사와 테스트를 수행한다. 에이전트는 모든 검사를 통과할 때까지 풀 리퀘스트를 계속 살핀다. 지속적 통합 과정에서 실패가 발생하면 문제를 고치고 풀 리퀘스트를 자동으로 업데이트한다.

새로 추가된 것은 ‘성능 검증 하네스’다. 에이전트는 이를 이용해 성능 문제가 의심되는 풀 리퀘스트를 ‘신세틱스 A/B’ 프레임워크로 보내 성능에 미칠 영향을 평가한다. 앞서 언급했듯 지난 6개월 동안 지속적 통합 시스템의 부하는 크게 늘었다.

5. 에이전트가 코드를 리뷰한다. 오픈AI는 범용 AI 코드 리뷰어 하나를 쓰는 대신, 분야별 전문가로 설정한 에이전트를 여러 개 실행한다. 벤캇은 이를 관련 인프라 팀의 전문가들이 모든 변경 사항을 검토하는 것과 같다고 본다고 말했다.

필자 게르게이의 덧붙임: 처음에는 에이전트에게 클라우드 인프라 전문가 역할을 맡긴다고 해서 범용 에이전트와 다른 리뷰가 나올지 의문이었다. 하지만 모든 코덱스 에이전트는 오픈AI의 코드와 문서 전체에 접근할 수 있다. 따라서 ‘클라우드 인프라 전문가’ 에이전트는 클라우드 인프라 구성과 권장 방식에 관한 맥락을 충분히 파악한 뒤, 해당 분야에 맞는 구체적인 의견을 줄 수 있을 것이다. 중요한 것은 이런 전문가 에이전트를 어떻게 설정하는지, 어떤 맥락에 접근할 수 있는지, 그리고 제한된 맥락 처리 범위를 최대한 활용하도록 자기 분야에만 어떻게 집중하게 하는지다.

코드 변경 사항은 위험도에 따라 분류한다. 위험도가 높은 변경에는 더 엄격한 절차를 적용할 수 있다. 예를 들어 AI 코드 리뷰를 추가로 실행하거나, 에이전트의 검토가 끝난 뒤 사람이 반드시 검토하도록 할 수 있다. 위험도가 낮은 변경은 더 간단한 절차를 따른다. 코드베이스의 각 영역에서는 위험도가 낮은 풀 리퀘스트를 자동 승인하는 에이전트를 선택해 도입할 수 있다. 그러면 사람의 승인을 기다리는 병목이 줄어 개발 속도가 빨라진다.

위험도 평가에서 눈에 띄는 점은 규정 준수와 관련한 추가 검토가 필요한 시점도 자동으로 판단할 수 있다는 것이다. 추가 검토는 다른 에이전트가 자동으로 수행할 수도 있고, 사람이 맡을 수도 있다. 지금처럼 풀 리퀘스트가 많이 생성되는 상황에서는 사람이 도움 없이 모든 코드를 검토하는 것이 불가능하다.

지속적 통합 단계에서와 마찬가지로, 코딩 에이전트는 리뷰 의견을 계속 확인하고 지적된 문제를 해결하도록 풀 리퀘스트를 수정한다.

6. 에이전트가 배포를 관리한다. 사람이 실제 서비스에 반영할 변경 사항을 승인하면, 해당 변경을 맡을 전담 에이전트가 배정된다. 에이전트에게 주어지는 지시는 다음과 같이 요약할 수 있다.

“이 변경 사항이 실제 운영 환경에 안전하게 완전히 배포될 때까지 전 과정을 챙겨라.”

에이전트는 코드 변경뿐 아니라 기능 플래그로 제어하는 변경도 관리한다. 예를 들어 기능 플래그를 사용하는 변경이라면 다음과 같이 작업한다.

• 코드베이스를 읽고 기능 플래그가 어디에 있는지 찾는다.
• 변경 사항이 어떤 역할을 하는지 파악한다.
• 성공과 실패를 판단할 신호를 정한다.
• 모니터링에 사용할 대시보드를 직접 만든다. 이 부분은 상당히 인상적인 발전이며, 나도 처음 접한 방식이다.
• 관련 운영 지표와 자신이 만든 대시보드를 지켜본다.

오픈AI의 장기 목표는 변경 사항마다 ‘자율적으로 일하는 사이트 신뢰성 엔지니어’를 붙이는 것이다. 에이전트가 그 역할을 맡아 배포를 거의 자율적으로 수행하게 하려 한다.

7. 운영 환경을 관찰한다. 운영 중인 시스템을 살피는 데는 다음 도구를 사용한다.

• 앞선 단계에서 에이전트가 만든 대시보드
• 로그, 지표, 추적 데이터, 다양한 속성을 담은 이벤트 데이터를 생성하는 여러 자체 도구를 포함한 오픈AI의 내부 관측 시스템

코덱스가 도입되기 전인 지난 방문 때와 비교하면 큰 변화가 있다. 당시에는 엔지니어가 서비스 모니터링용 대시보드를 만들었다. 지금은 에이전트가 개별 변경 사항을 배포할 때마다 대시보드를 만든다.

8. 운영 환경에서 관찰한 내용을 다시 개발에 반영한다. 오픈AI의 ‘성능 공장’은 에이전트를 활용해 경보와 대시보드를 살펴보고, 중복된 신호를 걸러 내고, 실제로 응답 속도가 느려진 문제를 찾아낸다. 이어 근본 원인을 분석하고 수정 방안을 제안한다. 이를 통해 계속되는 코드 변경으로 발생한 성능 문제를 찾아낸다. 개발 과정이 배포에서 끝나지 않고 지속적인 개선으로 이어지는 것이다.

9. 장애에 대응한다. ‘세브봇’은 오픈AI의 사내 장애 대응 에이전트다. 예상대로 이 역시 코덱스를 기반으로 만들어졌다. 장애가 감지되면 봇이 ‘깨어나’ 다음 작업을 수행한다.

• 장애와 관련된 맥락을 수집한다.
• 가능한 완화 조치를 찾는다. 다만 이 단계에서는 어떤 조치도 실행하지 않는다.
• 슬랙 채널에 참여해 개발자들의 질문에 답한다.
• 엔지니어가 특정 완화 조치를 적용하라고 지시하면 실행한다.

오픈AI의 목표는 일부 장애에 대해 세브봇이 자율적으로 완화 조치를 취할 수 있게 하는 것이다. 일상적인 장애는 세브봇이 스스로 처리하고, 사람은 업무에 복귀한 뒤 조치 내용을 검토하는 것이 이상적인 모습이다. 그러면 근무 시간 밖에 장애가 나도 사람을 깨울 필요가 없다. 하지만 현재 오픈AI에서 온콜 근무가 사라진 것은 아니다.

6. 레퍼런스

이 블로그는 유료라 이후 내용은 번역하지 못했다. 더 자세한 내용을 볼 사람은 여기를 참고하기 바란다.