AI 연구 인턴의 시대, 3.1일이라는 숫자 읽기

Frontier One · 2026년 9월 7일 선정분
원 발표: 9월 6일 · 이 해설의 실제 공개·재확인: 9월 10일.
증거 등급: INDUSTRY_TRIGGER. OpenAI의 내부 운영 보고서이며 동료평가 논문이나 독립 생산성 실험이 아니다. 아래 계산식은 지표 해석을 위한 교육용 모델이다. 회사의 미공개 집계 코드나 측정 그래프를 재현한 것으로 제시하지 않는다.

#L0. 먼저 30초: 무엇이 달라졌는가?

핵심은 AI 과학자가 완성됐다는 선언이 아니라, 연구자가 여러 AI 에이전트에 일을 배분하는 운영 방식의 변화다.

OpenAI는 사람이 지정한 연구 과제를 수행하는 자체 기준의 ‘연구 인턴’ 단계에 도달했다고 밝혔다. 2026년 8월 중순 조직 합계는 인간 노동 1일당 3.1 에이전트 작업일이었다. 성공한 ‘사람 기준 4~8시간’ 과제의 절반 이상에는 개입이 있었다. 실험 수 증가와 함께 가용 계산 자원도 늘었다. 따라서 실행량, 무개입 능력, 인과적인 생산성 향상을 구분해야 한다. 공식 보고서 §1~3 및 방법 설명

이 글의 목표는 세 가지다. 에이전트가 연구의 어디를 맡는지 이해하고, 3.1이라는 수의 분모를 확인하며, 우리 연구실에서 무엇을 측정해야 실제 시간을 아꼈다고 말할 수 있는지 설계하는 것이다.

#L1. 코드를 쓰는 AI와 연구를 진행하는 AI는 무엇이 다른가?

로봇 카메라의 인식 성능을 개선하는 가상의 연구를 떠올려 보자. 코드를 고치는 것만으로는 연구가 끝나지 않는다. 어떤 장면에서 실패하는지 정하고, 비교할 기준 모델을 고르고, 같은 데이터와 계산 예산으로 실험해야 한다. 모델이 좋아 보이면 데이터 누수나 평가 오류가 아닌지도 확인해야 한다.

일반적인 코드 답변은 이 과정의 한 조각을 제공한다. 반면 에이전트(agent)는 허용된 도구로 파일을 읽고, 코드를 수정하고, 테스트 결과를 관찰해 다음 행동을 선택하는 실행 구조다. OpenAI의 2025년 Codex 출시 설명에도 독립 작업 환경, 파일 편집, 테스트·타입 검사, 결과 검토가 포함돼 있었다. 여기서는 당시 문서를 개념의 출발점으로만 사용하며 현재 제품 기능 전체를 설명하는 자료로 사용하지 않는다. 2025년 공식 출시 설명

이 차이는 제어공학의 피드백과 비슷하다. 답변 하나를 받는 것은 명령안을 얻는 일이고, 테스트 실패를 보고 수정하는 것은 관찰을 다시 행동에 반영하는 일이다. 그러나 테스트 자체가 틀리면 피드백을 많이 돌려도 잘못된 목표를 더 잘 맞출 수 있다. 반복 실행이 가능하다는 것과 좋은 연구 판단을 한다는 것은 다르다.

#연구를 여섯 단계로 나누면 맡길 일이 보인다

원문이 사용한 분류의 출처는 Epoch AI의 연구 업무 분류다. 결정, 설계, 구현, 실행, 분석, 소통을 별도 단계로 구분한다. 다음은 그 분류를 가상의 비전 실험에 적용한 교육용 예시이지, OpenAI 내부 프로젝트를 재구성한 표가 아니다. 분류 제안 원문

Epoch AI가 제안한 AI 연구의 결정·설계·구현·실행·분석·소통 여섯 단계 원본 도식 — **원문이 사용한 분류 체계의 원본 도식** Epoch AI의 2026년 6월 연구 업무 분류. 색은 단계의 구분이며 원의 넓이는 소요시간이나 자동화율을 나타내지 않는다. OpenAI의 9월 운영 보고서가 채택한 분류의 출처다. Jean-Stanislas Denain, Joe Kwon, Anson Ho · Epoch AI · 2026-06-17 · 출처 · CC BY 4.0 · 원본 변경 없음 · 설명과 번역은 본문에 별도 제공

단계	비전 연구에서의 질문	결과물의 예
Decide · 결정	무엇이 실제 실패 원인인가?	연구 질문, 중단 조건
Design · 설계	개선 효과를 어떻게 분리할까?	비교 조건, 데이터 분할
Build · 구현	그 비교를 실행할 코드를 만들었나?	코드, 단위 테스트
Run · 실행	설정대로 실험이 끝났나?	로그, 체크포인트
Analyze · 분석	차이가 의미 있고 재현되는가?	반복 실험, 오차 분석
Communicate · 소통	무엇을 어느 조건에서 확인했나?	보고서, 재현 절차

그림 읽기: 원 그림의 여섯 색 영역은 분류를 구별한다. 같은 크기로 그려졌다고 각 단계에 시간이 6분의 1씩 든다는 뜻은 아니다. 가운데 원도 실측 생산성 그래프가 아니다. 무엇을 자동화했는지 이름을 붙이기 위한 지도다.

예를 들어 구현을 자동화해도 잘못 설정한 검증 데이터는 고쳐지지 않는다. 반대로 실행 로그를 안정적으로 수집하게 만드는 것만으로도 사람이 중간에 실험 상태를 확인하느라 끊기는 일을 줄일 수 있다. 어느 단계의 시간을 얼마나 바꾸는지 따로 측정해야 하는 이유다.

#L2. 3.1 agent-workdays는 사람 세 명을 추가한 것일까?

원문은 표준 8시간 작업일로 환산한 조직 합계 비율을 보고한다. 개인 연구자의 중앙값이나 성과의 비율이 아니다. ‘연구자’에는 연구 인프라·프로젝트 지원 인력도 포함되며, 집계가 모든 도구 사용을 완전히 포괄하는 것도 아니다. 보고서 §1 및 Appendix

공개 문장의 의미를 단순하게 재표현하면 다음과 같다. 정확한 활성시간 판정과 유휴시간 처리까지 재현한 공식 집계식은 아니다.

R=\frac{W_A}{W_H},\qquad W_A=\frac{T_A}{8\,\mathrm{h}},\quad W_H=\frac{T_H}{8\,\mathrm{h}}

T_A는 집계된 에이전트 실행시간의 합, T_H는 같은 범위의 인간 노동시간이다. W_A, W_H는 8시간으로 나눈 작업일 수, R은 단위가 없는 비율이다. 여러 에이전트가 동시에 움직이면 실행시간은 서로 겹쳐도 합산될 수 있다.

가상 예시: 인간 노동 8시간에 대응해 에이전트 4개가 각각 6.2시간 실행되면 합계는 24.8시간, 비율은 3.1이다. 벽시계로 24.8시간을 기다렸다는 말도, 인간 수준 결과물을 3.1배 얻었다는 말도 아니다.

여기에는 정답의 수, 코드의 유지보수성, 사람 검토 시간, 실패한 실험 비용이 들어 있지 않다. 컴퓨터가 오래 돌아가는 것은 유용한 실험이 많아졌다는 신호일 수도 있지만, 같은 오류를 여러 번 반복한 결과일 수도 있다. 두 경우를 구별하려면 결과와 비용을 추가로 봐야 한다.

#생산성을 말하려면 산출물과 비용도 정해야 한다

연구실 내부의 운영 지표를 설계한다면 다음과 같이 둘 수 있다. 이 식 역시 회사가 발표한 측정식이 아니라 이 글의 제안이다.

P_H=\frac{N_{\mathrm{accepted}}}{T_{\mathrm{human}}},\qquad C_{\mathrm{unit}}=\frac{C_{\mathrm{compute}}+C_{\mathrm{review}}+C_{\mathrm{rework}}}{N_{\mathrm{accepted}}}

N_accepted는 미리 정한 검증을 통과한 결과 수다. 첫 지표의 단위는 건/인간시간, 두 번째는 원/건이다. 인간시간에는 지시·검토·재작업을 포함하고, 비용 항목은 서로 중복되지 않도록 정의해야 한다. 채택 결과가 0건이면 건당 비용은 계산 불가로 남겨야지 0원으로 처리하면 안 된다.

다만 논문 아이디어 하나와 로그 정리 하나를 같은 1건으로 합치면 다시 지표가 왜곡된다. 비슷한 과제끼리 비교하고, 쉬운 과제를 더 많이 선택한 효과도 구분해야 한다. 시간 단축과 연구 가치 향상을 동시에 하나의 숫자로 표현하려 하지 않는 편이 낫다.

#L2. AI를 네 개 돌려도 전체 연구가 네 배 빨라지지 않는 이유

병목(bottleneck)은 전체 흐름을 제한하는 단계다. 코드 생성이 빨라져도 GPU 대기나 사람의 결과 검토가 그대로면 최종 결론까지의 시간은 그 단계에 묶인다.

이를 고정된 작업량의 간단한 모델로 유도해 보자. 기존 전체 시간은 T_0, 그중 빨라질 수 있는 비율은 p, 해당 부분의 실제 가속 배수는 s라고 하자. 먼저 병렬화가 완벽하고 추가 조정 비용은 없다고 가정한다.

T_{\mathrm{new}}=T_0(1-p)+\frac{T_0p}{s}

전체 가속 배수는 기존 시간을 새 시간으로 나눈 값이다.

S=\frac{T_0}{T_{\mathrm{new}}}=\frac{1}{(1-p)+p/s}

가령 전체 시간의 70%가 네 배 빨라져도 S = 1/(0.3+0.7/4) ≈ 2.11이다. 네 배가 아니다. 가속 가능한 부분을 무한히 빠르게 해도 나머지 30%가 남아 상한은 약 3.33배다. 이것이 암달의 법칙 형태로 읽는 병목의 의미다.

가속 가능한 비율 0.3·0.7·0.9에서 부분 가속과 전체 가속을 비교한 교육용 계산 곡선 — **직접 계산한 교육용 그래프 · 실측 데이터 아님** S=1/((1-p)+p/s)를 p=0.3, 0.7, 0.9에 대해 계산했다. 고정된 작업량, 완전한 병렬화, 추가 조정 비용 없음이 가정이다. OpenAI의 운영 데이터나 원본 그래프를 재현한 것이 아니다. JJo · 자체 수식 계산 · 2026-09-10 · 출처 · 자체 제작 · 외부 이미지 복제 없음 · 교육용 함수 그래프를 Matplotlib으로 생성 · 외부 폰트 파일 미포함

그래프 읽기: 가로축은 해당 부분의 가속 배수 s, 세로축은 전체 가속 배수 S다. 세 곡선은 가속 가능한 비율 p를 각각 0.3, 0.7, 0.9로 둔 계산 결과다. 실제 연구팀 데이터나 원문 그래프의 복제가 아니다. 모든 곡선이 s=1에서 1로 시작하고 점점 완만해진다. 자동화하기 어려운 부분이 크게 남을수록 추가 가속의 이익이 빨리 줄어든다.

사람이 에이전트의 결과를 합치는 데 시간이 더 들면 모델은 다음처럼 바뀐다.

S=\frac{1}{(1-p)+p/s+h},\qquad h=\frac{T_{\mathrm{overhead}}}{T_0}

추가 시간 비율 h=0.1이면 앞의 예시는 약 1.74배로 내려간다. 지시를 잘못 전달해 재작업이 반복되면 분모가 1보다 커져 오히려 느려질 수도 있다. 여기서 s는 실측한 부분 가속 배수이지 에이전트 개수와 자동으로 같은 값이 아니다.

실제 연구는 고정 작업이 아니고 더 많은 가설을 탐색할 수 있다. 따라서 이 모델을 OpenAI의 총 연구 가속률로 대입할 수는 없다. 목적은 내부 생산성을 추정하는 것이 아니라, 왜 실행량만으로 전체 성과를 계산할 수 없는지 이해하는 것이다.

#L3. 사람이 돕고 성공한 것과 스스로 성공한 것은 다르다

원문의 4~8시간은 사람이 완료하는 데 걸릴 것으로 추정한 시간으로 나눈 난도 구간이다. AI 실행시간의 구간이 아니다. 또 해당 개입률은 성공한 과제에 조건을 건 값이다. 결과가 불확실한 분류는 그래프에서 제외됐다. 보고서 §3

이 차이를 확률 기호로 써 보자. 이 절에서는 S를 성공 사건, I를 사람 개입 사건, H를 해당 사람 기준 시간 구간에 속하는 사건으로 정의한다. 앞 절의 가속 배수 기호와는 별개의 표기다.

\begin{aligned}P(I\mid S,H)&=\frac{P(I\cap S\cap H)}{P(S\cap H)}\\P(I\mid H)&=\frac{P(I\cap H)}{P(H)}\end{aligned}

세로 막대는 ‘~라는 조건에서’, 교집합 기호는 여러 조건을 동시에 만족한다는 뜻이다. 분모가 양수일 때 첫 식은 성공한 해당 구간 과제, 두 번째 식은 해당 구간 전체 과제를 기준으로 한다. 두 값이 우연히 같을 수는 있지만, 추가 정보 없이 서로 바꿔 쓸 수는 없다.

교육용 숫자: 같은 난도 과제 100건의 결과를 모두 확인했다고 하자. 60건이 성공했고, 성공한 60건 중 40건에 사람이 개입했다면 ‘성공 중 개입률’은 40/60이다. 전체 요청 대비 무개입 성공은 남은 20건을 100건으로 나눈 20%다. 실패한 과제의 개입 여부까지 알아야 전체 개입률을 계산할 수 있다.

원문의 ‘절반 이상’만으로 위 예시의 20% 같은 무개입 성공률을 역산할 수는 없다. 실제 전체 성공률, 과제 분포와 개입 정의가 더 필요하다. 중요한 것은 사람의 도움을 실패로 몰아가는 것이 아니라, 사람과 함께 일하는 도구의 성과와 사람 없이 위임할 수 있는 성과를 따로 평가하는 것이다.

#결과를 모르는 작업을 빼면 성공률은 어떻게 달라질까?

전체 요청 100건 중 성공 60건, 실패 20건, 결과 미확인 20건이라는 별도의 가상 예시를 보자. 판정 가능한 80건만 쓰면 성공률은 75%다. 미확인 건을 포함한 전체 성공률은 아직 확정되지 않는다.

\frac{N_S}{N}\le p_{\mathrm{all}}\le\frac{N_S+N_{?}}{N}

N은 전체 요청 수, N_S는 확인된 성공 수, N_?는 결과 미확인 수다. 모든 요청이 최종적으로 성공 또는 실패 중 하나가 된다고 가정하면 이 예시의 가능한 범위는 60~80%다. 이것은 통계적 신뢰구간이 아니라 미확인 결과에 따른 산술적 범위다. 원문 데이터의 실제 범위를 계산한 것이 아니다.

보고서를 읽을 때 ‘몇 퍼센트 성공했나’에 더해 ‘전체 요청 중 몇 퍼센트의 결과를 판정했나’를 물어야 한다. 쉬운 작업의 결과만 잘 관찰된다면 관측된 성공률이 전체를 대표하지 않을 수 있기 때문이다.

#L3. Run 단계의 자동화는 왜 코드 작성만큼 중요한가?

다음 원본 그림은 실행 단계의 업무를 더 잘게 나눈다. 입력, 출력, 모니터링, 이상 진단과 복구를 구분하는 분류 예시이며 9월 성능 측정표가 아니다. Epoch AI 원문

연구 실행 단계의 입력과 출력, 모니터링 및 복구 작업을 나눈 Epoch AI 원본 분류 예시 — **실행·모니터링 작업의 원본 분류 그림** 입력과 출력부터 읽고 실행·감시·복구가 별개의 일임을 확인한다. 대괄호의 숫자는 분류 저자들의 자동화 수준 평가이지, 성공 확률이나 OpenAI의 9월 실측 점수가 아니다. Jean-Stanislas Denain, Joe Kwon, Anson Ho · Epoch AI · 2026-06-17 · 출처 · CC BY 4.0 · 원본 변경 없음 · 설명은 본문에 별도 제공

그림 읽기: 위쪽의 입력·출력부터 보고, 가운데 모니터링이 어떤 문제를 감지하는지 읽으면 된다. 항목 옆 대괄호 숫자는 해당 분류 저자들의 자동화 수준 평가다. 성공 확률이나 OpenAI가 9월에 기록한 점수가 아니다.

가상의 학습 실험에서 손실값이 급격히 커지면, 학습률이 높은 것인지 데이터가 손상된 것인지 먼저 구분해야 한다. 그래프를 그리는 자동화, 원인을 좁히는 자동화, 설정을 바꾸는 자동화, 변경을 승인하는 권한은 서로 다르다. 모든 권한을 한 번에 주는 대신 관찰과 제안을 먼저 맡기는 설계가 가능하다.

예를 들어 에이전트 A는 로그 이상을 찾고, B는 재현용 작은 테스트를 만들며, C는 수정 전후의 지표를 비교하게 할 수 있다. 최종 실험 설정과 데이터 분할 변경은 사람이 검토한다. 이것은 특정 회사의 내부 구조를 추정한 것이 아니라 연구실 적용을 위한 설계 예시다.

평가 데이터에 맞춰 코드를 고쳐 놓고 ‘성능이 좋아졌다’고 끝내지 않으려면, 비교 기준과 실패 조건은 작업 전에 고정해야 한다. 여러 에이전트가 같은 저장소를 동시에 수정한다면 작업별 변경을 분리하고 통합 검사를 거치는 것도 필요하다.

#무엇이 반대 증거이고, 무엇은 아직 모르는가?

도구가 빠르게 발전할수록 다른 시점과 다른 집단의 결과를 구분해야 한다. METR의 2025년 7월 연구는 경험 많은 개발자 16명의 실제 저장소 과제 246건을 무작위 배정했고, 당시 도구를 허용한 조건에서 완료 시간이 평균 19% 더 길었다고 보고했다. 이는 ‘모든 개발자에게 AI가 느리다’는 결론이 아니다. 연구 설계와 범위

2026년 2월 후속 보고에서는 연구 참여를 원하지 않는 개발자가 늘어나는 선택 효과와 동시 에이전트 사용의 시간 측정 문제가 지적됐다. 저자들은 최신 효과 크기에 대한 신뢰할 만한 추정을 얻기 어려워 실험 설계를 바꾼다고 밝혔다. 따라서 2025년의 수치를 2026년 9월 도구의 현재 성능인 것처럼 반복해서는 안 된다. 후속 보고

이 두 자료는 OpenAI 내부 측정을 직접 반박하는 동일 조건 재현 실험이 아니다. 사용자의 체감, 도구 사용량, 비교군이 있는 생산성 측정이 서로 다른 종류의 증거라는 점을 보여주는 비교 자료다.

인과를 더 분명히 보려면 비슷한 과제를 AI 허용·비허용 조건으로 배정하고, 같은 계산 예산과 품질 기준을 사용해야 한다. 작업 난도, 숙련도, 과제 선택이 달라지면 단순 전후 비교가 섞인다. 연구 질문 자체를 더 잘 고르게 된 효과는 고정 과제의 완료시간 실험만으로는 충분히 측정하지 못한다.

#보안은 생산성과 별개인 부록이 아니다

OpenAI는 2026년 8월 18일 보고서에서 배포 예정 최신 모델의 강화학습을 2주간 중단하고 연구 환경의 격리와 모니터링을 강화했다고 밝혔다. 모든 연구가 중단됐다는 뜻은 아니며, 보고서는 안전조치와 작업별 재개를 구분한다. 공식 안전 보고서

이를 실험실의 자동 장비로 생각하면 쉽다. 빨리 움직이는 장비라도 정지 명령과 접근 제한이 없으면 전체 실험실을 위험하게 만들 수 있다. 코드 에이전트도 실행 권한, 네트워크 접근, 비밀키, 생산 데이터의 변경 범위를 설계해야 한다.

효율을 높이기 위해 테스트를 우회하거나 권한을 무작정 넓히는 것은 같은 결과를 더 싸게 얻는 최적화가 아니다. 성공 조건을 바꿔 버린 것이다. 이 글에서 제안한 시간·비용 지표 역시 사전에 고정한 안전·품질 조건을 통과한 결과에 대해서만 의미가 있다.

#연구실에서 다음 주부터 무엇을 기록하면 좋을까?

우선 비슷한 종류의 작은 과제 묶음을 정하고, 과제 ID와 입력 버전, 허용된 도구, 완료 조건을 남긴다. 이어서 지시 시간, 실행 대기, 검토·재작업 시간을 따로 기록한다. 마지막에는 테스트 통과 여부와 사람이 채택한 결과인지, 미확인 상태인지 구분한다.

중요한 비교는 ‘오늘 에이전트를 몇 개 켰는가’가 아니라 같은 기준의 결과를 얻는 데 들어간 사람 시간과 전체 비용이 줄었는가다. 실험을 더 많이 돌릴 수 있다면 같은 예산에서 가설 검증의 범위가 넓어졌는지도 별도로 볼 수 있다.

이 접근은 인간의 역할을 없앤다는 이야기가 아니다. 사람이 기준을 설계하고, 에이전트가 반복 실행을 맡으며, 사람이 예상 밖의 결과를 검토하는 방식에서 어느 부분이 실제 병목인지 찾아내는 것이다. 첫 측정에서 이득이 작게 나와도 과제 분해와 검증 절차를 개선할 근거가 생긴다.

#이해 확인: 두 질문에 답해 보자

질문 1. 전체 시간의 절반을 차지하던 코드 작업이 10배 빨라지고 나머지는 그대로라면 전체 연구도 10배 빨라질까?

답은 아니다. 추가 비용이 없을 때 1/(0.5+0.5/10) ≈ 1.82배다. 전체 작업량과 비교 기준이 같다는 가정도 필요하다.

질문 2. ‘성공한 작업의 60%에 사람이 개입했다’만으로 ‘전체 작업의 40%를 AI가 혼자 성공했다’고 말할 수 있을까?

그럴 수 없다. 성공한 작업이라는 조건부 분모와 전체 작업이라는 분모가 다르다. 전체 성공 건수와 전체 요청 건수를 추가로 알아야 한다.

마지막 한 문장: AI 연구 자동화의 의미는 실행시간을 늘리는 것에 그치지 않는다. 무엇을 맡겼고, 어떤 기준으로 성공을 판단했으며, 검토까지 포함한 비용이 얼마나 달라졌는지를 함께 설명할 수 있어야 한다.

#원문, 그림, 관련 글

두 원본 도식은 Epoch AI의 CC BY 4.0 자료로 저자·출처·라이선스를 표시하고 내용 변경 없이 삽입했다. 가속 곡선은 본문 식을 계산한 자체 교육 자료다. OpenAI의 원본 대화형 그래프는 출처 1에서 확인할 수 있으며, 이번 글의 그림을 그 실측 그래프와 혼동하지 않도록 구분했다.