[Agent] 연구원 1명당 에이전트 3.1일치가 일합니다 — 병목은 어디로 갔나

연구원 한 명이 출근하면, 그 옆에서 에이전트 세 명이 하루 종일 일하는 셈입니다.

OpenAI가 9월 6일 공개한 내부 자료에 따르면, 2026년 8월 중순 연구 조직 전체의 코딩 에이전트 실행 시간은 사람 노동일 하나당 3.1 agent-workdays였습니다. 8시간을 한 노동일로 놓고 환산한 값입니다.

숫자만 보면 이렇게 들립니다.

“AI 연구원 한 명이 에이전트 세 명을 거느리게 됐다.”

방향은 맞지만, 그대로 믿으면 중요한 것을 놓칩니다. 이 수치는 사람 세 명을 고용한 것과 다르며, 연구가 세 배 빨라졌다는 뜻도 아닙니다. 에이전트가 빠르게 가져간 일과 오히려 더 중요해진 사람의 일이 다르기 때문입니다.

3.1일치는 무엇을 세었나

먼저 단위를 풀어야 합니다.

agent-workday는 급여나 인원 수가 아니라 에이전트가 실행된 시간입니다. OpenAI는 이를 표준 8시간 근무일로 환산했습니다. 연구자가 여러 에이전트를 동시에 돌리고, 그 에이전트가 다시 하위 에이전트를 만들면 실행 시간은 겹쳐서 쌓입니다.

그래서 아래 둘은 완전히 다른 말입니다.

말	실제 뜻
에이전트가 사람의 3.1배 일했다	연구 조직 전체의 에이전트 실행 시간이 사람 노동 시간의 3.1배였다
연구 생산성이 3.1배가 됐다	이 자료만으로는 알 수 없다

두 번째 문장이 성립하려면, 실행 시간이 늘어난 만큼 좋은 연구 결과가 더 나와야 합니다. 그런데 좋은 결과는 코드 줄 수나 실행 횟수만으로 재기 어렵습니다. 가설을 잘못 세우면 실험을 백 번 더 돌려도 연구는 앞으로 가지 않습니다.

OpenAI도 이 점을 직접 경고합니다. 코드 생성량과 실험 횟수는 측정하기 쉽지만, 그것이 연구 진전과 어떤 관계인지는 해석하기 어렵다고 썼습니다.

실제로 먼저 사라지는 병목

그렇다고 이 숫자가 장식은 아닙니다. 연구 현장에는 오래된 잡일 병목이 있습니다.

• 실험이 왜 실패했는지 인프라 로그를 뒤지는 일
• 데이터 형식을 맞추고, 평가 코드를 고치고, 재현 환경을 만드는 일
• 수많은 실행 중 무엇이 깨졌는지 확인하는 일
• 기존 도구를 새 환경으로 옮기고 테스트를 보강하는 일

이 일들은 “무엇을 발견할까”보다 “실험을 할 수 있게 만들까”에 가깝습니다. OpenAI 자료에서도 에이전트 사용은 연구·인프라 코드에서 먼저 컸고, 기술 지원과 실행 모니터링 쪽도 눈에 띄게 늘었습니다. 한 내부 기술 지원 채널은 질문이 줄어 한 팀이 오피스아워를 중단했다고 합니다.

이건 연구원이 없어졌다는 이야기가 아닙니다. 연구원이 다른 연구원의 환경을 고쳐 주느라 쓰던 시간이 줄었다는 이야기입니다.

실험을 더 많이 하면 발견도 더 많아질까

OpenAI는 2026년 8월, 연구자 한 사람당 실험 횟수가 2025년 1월 이후 최고였다고 보고했습니다. 에이전트 채택 증가와 함께 나타난 변화입니다.

하지만 원인을 하나로 못 박지는 않았습니다. 같은 기간 가용 컴퓨트도 크게 늘었기 때문입니다. 이 구분이 중요합니다.

에이전트 사용 증가 ─┐
                     ├─ 실험 횟수 증가
컴퓨트 증가 ──────────┘

관측된 상관관계를 “에이전트가 실험을 늘렸다”로 바꾸면, 자료가 말하지 않은 결론이 됩니다. 다만 에이전트가 실험 준비와 장애 해결의 마찰을 줄이는 역할을 했다는 해석은, 이 수치와 현장 사례에 잘 맞습니다.

아직 가장 적게 맡기는 일

OpenAI는 연구 업무를 여섯 단계로 나눠 에이전트 토큰을 분류했습니다.

1. Decide — 무엇을 할지, 무엇을 계속할지, 어디에 자원을 쓸지 결정
2. Design — 연구 아이디어와 엔지니어링 명세 설계
3. Build — 코드와 데이터셋 구축
4. Run — 학습·평가 실행, 하드웨어, 서빙
5. Analyze — 실험·모델·배포 결과 분석
6. Communicate — 결과·피드백·결정 공유

모든 범주에서 사용량은 늘었습니다. 그러나 고수준 계획은 에이전트 출력 토큰에서 여전히 아주 작은 비중입니다.

이건 의외로 자연스럽습니다. “이 코드의 예외 처리를 고쳐라”는 성공 여부를 테스트로 확인할 수 있습니다. 반면 “다음 분기에 어떤 가설에 컴퓨트를 써야 하나”는 정답 데이터가 없습니다. 경쟁 모델의 움직임, 안전 위험, 연구팀의 직관, 지금 포기할 기회의 비용까지 함께 판단해야 합니다.

에이전트가 잘하는 일은 대체로 정답을 외부에서 확인할 수 있는 일입니다. 사람에게 남는 일은 정답 자체를 정하거나, 무엇을 정답으로 볼지 결정하는 일입니다.

긴 작업도 방치하면 끝나지 않는다

여기에도 숫자 하나가 있습니다. OpenAI가 1월부터 7월까지 성공 여부를 확인할 수 있었던 연구 업무를 분류했을 때, 사람이라면 4~8시간 걸릴 성공 사례의 절반 이상에는 한 번 이상의 사람 개입이 있었습니다.

에이전트가 긴 작업을 수행할 수 있다는 말과, 긴 작업을 던져 두면 끝까지 완성한다는 말은 다릅니다.

특히 연구에서는 중간 개입이 단순한 감독이 아닙니다.

에이전트가 할 수 있는 일	사람이 끼어드는 이유
실험 코드 작성·수정	측정하려는 것이 정말 맞는지 확인
실행 실패 원인 후보 찾기	어느 가설부터 버릴지 결정
결과 표와 그래프 만들기	우연·누수·교란변수를 판정
여러 구현안 제시	무엇을 제품·논문·학습에 반영할지 결정

에이전트가 속도를 올릴수록, 사람이 한 번 개입할 때의 값은 더 커집니다. 하루에 하나만 하던 실험을 열 개 할 수 있게 되면, 열 개 중 어느 하나를 믿을지 고르는 일이 새 병목이 됩니다.

구현보다 검증이 비싸지는 순간

이 변화는 연구에만 있지 않습니다. OpenAI가 공개한 과학 소프트웨어 사례 여덟 건에서도 비슷한 패턴이 나왔습니다. 에이전트는 유지보수, 언어 전환, 최적화, 새 구현을 빠르게 만들었지만, 연구자가 맡은 일은 구현에서 검증과 오케스트레이션으로 이동했습니다.

좋은 팀은 “잘 만들어 봐”라고 던지지 않았습니다. 기존 도구와 정확히 같은 결과가 나오는지, 시뮬레이션 데이터에서 통계적 성질이 맞는지처럼 외부 기준을 먼저 두었습니다. 초안 구현은 빨랐지만, 경계 사례와 미세한 수치 차이를 해결하는 마지막 구간이 오래 걸렸습니다.

이 블로그에서 평가 주도 개발로 다뤘던 이야기와 닿아 있습니다. 에이전트 시대에 평가가 덜 중요해지는 게 아닙니다. 만드는 비용이 떨어질수록, 무엇을 통과로 볼지 정하는 평가가 더 중요해집니다.

그래서 연구자는 무엇을 하게 되나

“사람 연구원 한 명당 에이전트 3.1일치”는 사람을 3.1명 복제했다는 숫자가 아닙니다. 실험실의 반복 작업이 병렬화됐다는 숫자입니다.

그 뒤에 남는 사람의 역할은 더 선명해집니다.

• 좋은 질문을 고른다.
• 에이전트가 틀렸음을 드러낼 평가를 만든다.
• 나온 결과가 우연인지, 일반화되는지 판정한다.
• 빠르게 만들 수 있다는 이유만으로 위험한 연구·배포를 밀어붙이지 않는다.

연구의 속도는 빨라질 수 있습니다. 하지만 실행 시간이 늘었다는 지표는 출발점일 뿐, 발견의 속도를 증명하지는 않습니다. 지금 벌어지는 변화는 “AI가 연구자를 대체했다”가 아니라 연구의 구현 병목이 검증·판단 병목으로 옮겨 갔다는 쪽에 더 가깝습니다.

참고

• Research acceleration: The view inside OpenAI — OpenAI, 2026-09-06. 3.1 agent-workdays, 연구 업무 분류, 실험 횟수, 사람 개입 비율, 측정 범위와 한계의 출처입니다. 내부 조직 자료이므로 다른 연구 조직 전체에 일반화할 수는 없습니다.
• Scientific computing in the age of agentic AI — OpenAI, 2026-07-28. 과학 소프트웨어 사례 여덟 건과 구현·검증·장기 유지보수의 역할 변화에 관한 출처입니다. 탐색적 사례 보고서입니다.
• How agents are transforming work — OpenAI, 2026-06-25. 긴 작업의 시간 추정이 모델 기반 분류이며 방향성으로 해석해야 한다는 방법론적 단서의 출처입니다.