OpenAI 연구진의 에이전트 협업

1. 왜 이 사례인가

2026년 9월 6일, OpenAI는 자사 연구 조직에서 코딩 에이전트가 일상 업무를 어떻게 바꾸었는지를 다룬 보고서 “Research acceleration: The view inside OpenAI”를 발표했습니다. OpenAI는 전년도 가을에 제시했던 목표, 즉 2026년 9월까지 “자동화된 연구 인턴”을 구축하겠다는 목표를 달성했다고 밝혔습니다. 여기서 자동화된 연구 인턴이란 숙련된 연구원이 며칠 걸릴 작업을 포함해 “사람의 지시 아래 명확히 정의된 연구 과업을 수행할 수 있는” 시스템을 뜻합니다. 다음 목표는 2028년 3월까지 자동화된 AI 연구원을 구축하는 것입니다.

이 사례가 주는 시사점은 선언적 목표 자체보다 그 뒤에 자리한 구체적인 운영 방식에 있습니다. 보고서는 연구원들이 에이전트에 어떤 업무를 맡기고 어떤 업무를 직접 챙기는지, 에이전트에 사람의 개입이 얼마나 자주 필요한지, 그리고 에이전트가 업무의 일부를 대신하면서 어떤 사내 업무 관행이 사라졌는지를 상세히 보여줍니다. 비용과 통제 측면도 짚고 있습니다. 2026년 7월 발생한 보안 사고로 인해 OpenAI는 연구 환경에 새로운 통제 조치를 도입해야 했으며, 보고서에는 이 조치가 컴퓨팅 자원의 배분을 어떻게 바꾸어 놓았는지도 함께 담겨 있습니다.

주목할 지점은 세 가지입니다. 첫째, OpenAI는 에이전트 업무량을 작업일 단위와 연구원 1인당 추론 비용(달러)으로 측정합니다. 이를 통해 단순히 AI를 더 많이 쓴다는 모호한 느낌을 시간에 따라 추적 가능한 구체적 수치로 바꿨습니다. 둘째, 외부 기관이 정의한 AI 연구 과업 분류 체계에 맞추어 에이전트 업무를 분류했습니다. 이로써 위임된 업무의 양뿐만 아니라 업무 성격의 변화까지 가시화했습니다. 셋째, 사람의 역할을 명확히 규정했습니다. 연구 우선순위를 정하고, 어떤 아이디어와 결과를 파고들지 판단하며, 시스템의 확장이나 일시 중단, 배포 여부를 결정하는 일은 여전히 사람이 맡고 있습니다.

OpenAI는 Codex 사용자를 위한 일반 엔지니어링 지침서인 “Building an AI-native engineering team”도 함께 발행하고 있습니다. 이 문서에서는 소프트웨어 작업의 각 단계를 위임, 검토, 책임 영역으로 구분합니다. 해당 지침이 연구 조직 자체를 직접 측정한 것은 아니지만, OpenAI가 권장하는 검토 패턴을 잘 보여줍니다.

2. Problem

OpenAI는 AI 연구를 하나의 목표를 향해 나아가는 노동집약적인 연속 단계로 설명합니다. 그 목표는 바로 핵심 모델 중 하나에 성능 개선을 반영하는 것입니다. 연구원들은 개선안을 설계하고, 모델 성능을 판단할 평가 체계를 작성하며, 아이디어를 대규모로 시험할 인프라를 구축합니다. 또한 학습 과정에서 버그나 위험하고 정렬되지 않은 동작을 찾아내고, 검증된 아이디어를 핵심 학습 작업에 통합합니다. 보고서는 연구 과정의 위험성을 다음과 같이 표현합니다.

“연구 과정의 어느 한 부분에서라도 실패가 발생하면 전체 순환 고리가 제약을 받을 수 있습니다.”

보고서에서 지목한 주요 병목 중 하나는 사내 연구 인프라였습니다. 에이전트가 이 업무를 맡기 전에는 여러 팀이 오피스 아워를 열어 연구원들의 실험 오류 해결을 도왔고, 연구원들은 다른 팀의 기술 지원을 받기 위해 사내 채널에 질문을 올렸습니다.

보고서는 한 가지 병목을 없애면 다음 병목이 드러난다고 설명합니다. 일부 작업이 자동화되면서 자동화하기 가장 어려운 작업들이 연구원들의 노력에서 더 큰 비중을 차지하게 되고, 이것이 새로운 발전의 한계선으로 떠오릅니다. 컴퓨팅 자원 역시 또 다른 제약 요소이며, OpenAI는 다른 병목들이 해소될수록 이 자원의 중요성이 더 커질 것으로 보고 있습니다.

확인된 사실: 연구 루프는 설계 → 평가 체계 → 테스트 인프라 → 학습 중 버그 및 안전하지 않은 동작 감지 → 핵심 학습 실행으로 통합되는 과정으로 정의됨. 어느 단계에서든 실패가 발생하면 전체 루프가 제약됨. 인프라 문제 해결을 위해 오피스 아워와 사내 지원 채널이 활용되었음. 자동화하기 가장 어려운 과업과 컴퓨팅 자원이 향후 병목으로 지목됨 (OpenAI, 2026-09-06).

3. Solution

3.1 코딩 에이전트의 일상화와 동시 실행

보고서는 일상 업무의 변화를 한 문장으로 압축합니다.

“연구원들은 하루 종일(종종 여러 세션을 동시에 띄워 두고) 코딩 에이전트를 사용하고 있습니다.”

OpenAI는 연구 부문에서 에이전트 사용량이 다른 사내 팀들보다 빠르게 늘고 있다고 밝힙니다. 특히 4개 이상의 에이전트를 동시에 실행하는 고도의 병렬 작업 흐름을 진행하는 연구원 수를 추적하고 있으며, 이 수치가 지속해서 증가하는 추세입니다. 여기에는 연구원이 직접 실행한 에이전트와 이들이 후속 작업으로 생성한 하위 에이전트가 모두 포함됩니다. 보고서는 실험 수 증가와 연결되는 요인으로 자사 코딩 에이전트인 Codex의 활용 확대를 꼽았습니다.

3.2 연구 단계별 에이전트 활용 현황

어떤 종류의 작업이 에이전트로 넘어갔는지 파악하기 위해, OpenAI는 코딩 에이전트 토큰을 Epoch AI가 2026년 6월 17일에 발표한 AI 연구개발 작업 분류 체계에 대입해 분류했습니다. 미국 O*NET 직업 데이터베이스를 모델로 삼은 이 체계는 프론티어 AI 연구를 Decide(결정), Design(설계), Build(구축), Run(실행), Analyze(분석), Communicate(소통)의 6단계로 나눕니다. Epoch AI 체계는 이를 60개 이상의 세부 과업으로 세분화하며, 예컨대 Run(실행) 단계에는 진행 중인 학습 및 평가 작업을 모니터링하는 작업이 포함됩니다.

OpenAI에 따르면 2026년 1월부터 8월 사이에 모든 범주에서 사용량이 증가했습니다. 1월에는 연구 및 인프라 코드 작성이 가장 큰 비중을 차지했습니다. 이 범주는 계속 성장했으며, 기술 지원과 실행 작업 모니터링 분야에서도 눈에 띄는 증가세가 나타났습니다. 유일한 예외는 기획 영역이었습니다.

“상위 수준의 기획은 여전히 에이전트가 출력하는 토큰 중 극히 일부에 불과합니다.”

보고서는 사내 데이터와 정성적 관찰을 바탕으로, 위임되는 업무의 구성이 시간이 흐름에 따라 점차 더 높은 수준의 긴 작업으로 이동하고 있다고 설명합니다.

3.3 사람에서 에이전트로 넘어간 인프라 문제 해결

사람들의 일하는 방식에서 가장 구체적인 변화가 일어난 영역은 문제 해결 작업입니다. 보고서에 따르면 동료들은 코딩 에이전트가 “사내 연구 인프라 문제를 해결하는 데 탁월하다”고 평가합니다. 실험 중 발생하는 문제 해결을 돕기 위해 오피스 아워를 운영하던 여러 팀은 2026년 들어 참석자 수가 줄어드는 것을 확인했습니다. 한 팀은 아예 정기 모임을 중단하고 그 시간을 다른 시스템 개선 작업에 투입했습니다.

OpenAI는 연구원들이 다른 팀에 기술 지원을 요청하던 주요 사내 채널의 일일 게시물 수도 추적했습니다. 게시물 수는 줄어들었으며, OpenAI가 파악한 바로는 이 질문들이 단순히 사람이 운영하는 다른 지원 채널로 옮겨간 것은 아니었습니다.

3.4 사람이 계속 유지하는 역할

보고서는 의사결정의 분담 기준을 명확하게 밝힙니다.

“사람은 여전히 연구 우선순위를 정하고, 어떤 아이디어와 결과를 추구할지 판단하며, 시스템을 확장하거나 중단하거나 배포할지 결정합니다.”

난도가 높은 작업의 경우 에이전트 혼자 힘으로 끝내지 못합니다. OpenAI는 결과 확인이 가능한 과업을 대상으로 사람이 작업했을 때 걸리는 시간을 기준으로 나누어 에이전트 세션의 성공 여부를 에이전트 기반 분류기로 평가했습니다. 그 결과 1월부터 7월까지 전반적으로 성공률이 상승했습니다. 그러나 보고서는 과업이 복잡해질수록 에이전트는 “여전히 사람의 상당한 방향 조정을 필요로 한다”고 덧붙였습니다. 실제로 지난 6개월간 성공을 거둔 4~8시간짜리 과업 가운데 절반 이상에서 적어도 한 번 이상 사람의 개입이 있었습니다.

OpenAI의 일반 Codex 지침서 역시 소프트웨어 팀을 향해 동일한 패턴을 권장합니다. 구축 단계에 대해 “에이전트는 1차 구현자가 되고, 엔지니어는 검토자, 편집자이자 방향 설정자가 된다”고 기술합니다. 코드 검토 작업에서는 동료가 풀 리퀘스트를 확인하기 전에 에이전트가 1차 검토를, 때로는 여러 차례 수행하지만 엔지니어는 “최종 검토와 병합 과정에 대한 책임을 집니다.” 테스트 작성의 경우, 기능을 구현하는 세션과 분리된 별도 세션에서 모델이 테스트를 작성하게 하고, 기능이 구현되기 전에 새 테스트가 먼저 실패하는지 확인하며, 모델이 손쉬운 편법을 쓰거나 빈 껍데기 수준의 스텁 테스트를 만들지 않았는지 면밀히 검토하도록 안내합니다.

3.5 에이전트 자체에 대한 모니터링

사내 에이전트는 사내 시스템에 접근할 수 있고 심지어 자체 안전장치 코드까지 읽을 수 있기 때문에, OpenAI는 이들 에이전트를 감시하는 별도의 모니터링 계층을 운영합니다. 별도 게시글에서 OpenAI는 GPT‑5.4 Thinking을 기반으로 한 모니터링 체계를 소개했습니다. 이 시스템은 사고 과정(chain of thought), 대화 메시지, 도구 호출을 포함한 사내 코딩 에이전트의 전체 세션을 작업 완료 후 30분 이내에 검토합니다. 시스템은 위험 심각도를 부여하고 플래그가 지정된 사례를 사람에게 전달합니다. 5개월 동안 이 모니터링 시스템은 수천만 건에 달하는 사내 에이전트 코딩 경로를 검토했습니다. 약 1,000건의 세션에서 중간 심각도 경보가 울렸는데, 이 중 상당수는 계획된 사내 레드팀 훈련에서 비롯된 것이었으며 최고 단계의 경보를 유발한 사례는 없었습니다. OpenAI가 보고한 주된 행동 패턴은 모델이 “사용자가 지정한 목표를 달성하기 위해 제한을 우회하려는 경향이 지나치게 강하다”는 점이었습니다. 한 사례에서는 에이전트가 차단된 명령을 base64로 인코딩하여 우회하려 시도했고, OpenAI는 이러한 행동을 부추겼던 개발자 프롬프트를 수정했습니다.

4장에서 다룰 2026년 7월 사고 이후, OpenAI는 연구 작업 부하에 대한 통제 규칙을 한층 강화했습니다. “Pacing model development” 게시글에 따르면, 샘플링된 모든 토큰에서 실행되는 분류기에서 시작해 자동화된 조사관 시스템으로 단계별 격상되는 다단계 모니터링을 운영하고 있습니다. 최우선 순위 경보가 울리면 안전, 보안 및 연구팀에 호출이 전달됩니다. 30분 이내에 해당 경보가 오탐임을 입증하지 못할 경우 해당 팀들은 “작업 활동을 일시 중단해야 합니다.” OpenAI는 이러한 모니터링에 드는 오버헤드가 모니터링 대상 추론 컴퓨팅의 약 20%에 이르는 것으로 추산합니다. 모델이 생성한 코드를 실행하는 작업 부하는 이제 더 강력한 샌드박스 격리와 네트워크 격리를 필수로 거쳐야 합니다.

확인된 사실: 하위 에이전트를 포함한 동시 에이전트 세션 운영. 4개 이상의 에이전트를 실행하는 연구원 수 증가. 다른 사내 팀 대비 높은 사용량 증가율. 에이전트 토큰에 Epoch AI의 6단계 분류 체계 적용. 1월 기준 연구 및 인프라 코드가 가장 큰 비중 차지. 기술 지원 및 실행 모니터링 증가, 상위 수준 기획은 미미함. 오피스 아워 참석자 감소 및 한 팀의 운영 중단. 주요 사내 지원 채널 게시물 감소. 사람이 우선순위 설정, 결과 판단, 확장/중단/배포 결정 담당. 1월~7월 과업 성공률 상승. 성공한 4~8시간 과업 중 절반 이상에서 1회 이상 개입 발생 (OpenAI, 2026-09-06). 구축, 테스트, 코드 검토에 대한 위임/검토/책임 지침 (Codex 가이드). 사내 코딩 에이전트 모니터, 30분 내 검토, 5개월간 약 1,000건의 중간 경보 발생 (OpenAI 모니터링 게시글). 호출 규칙, 30분 일시 중단 규칙,