장시간 AI 에이전트 운영 사례
오래 일하는 AI에도 중단·재시도·사람 검토가 필요합니다
OpenAI가 2026년 10월 14일 공개한 Third Moment Research 사례입니다. 1만 개 에이전트의 병렬 운영과 36~48시간 연구 세션은 해당 회사 환경의 결과이며 모든 업무의 자동화를 뜻하지 않습니다.
이 글에서 다룰 내용
장시간 병렬 운영의 의미, 백테스트 최적화와 토큰 낭비, 하네스의 재시도·종료·사람 검토, 보안 점검과 사례의 한계
1만 개보다 중요한 질문, 오래 일하게 하려면?
AI 에이전트를 오래 실행하려면 모델만 잘 고르면 될까요? 이번 사례에서 눈여겨볼 부분은 실행 시간보다 작업이 막히거나 끝나지 않았을 때 어떻게 관리했는가입니다.
OpenAI는 2026년 10월 14일 고객 사례에서 서드 모먼트 리서치(Third Moment Research)가 AI 에이전트 1만 개를 동시에 운영하고 연구 세션을 36~48시간 이어간다고 소개했습니다. 독립 검증된 업계 공통 성능이나 새 모델 출시 발표가 아니라, 특정 회사의 연구 운영 사례입니다.
이 회사는 Codex, GPT-6 Astra, GPT-6 Sol, GPT-6.1 Sol을 연구와 계산에 사용합니다. 공동창업자는 GPT-6.1 Sol이 자사 과제에서 Astra와 유사한 성능을 더 적은 토큰으로 내 현재 가장 많이 쓴다고 설명했지만 이를 모든 작업에서의 절대 우위로 읽으면 곤란합니다.
백테스트 3시간을 줄인 건 모델 이름만이 아닙니다
초기 정량금융 연구 환경에서는 특정 백테스트 한 번에 약 3시간이 걸렸습니다. 이 회사는 Codex와 당시 최신 모델인 GPT-5.6으로 시뮬레이션 궤적, 시간기록, 코드를 함께 분석했습니다.
그 결과 캐싱과 메모리 패킹 최적화를 찾아 해당 백테스트를 약 3~5분으로 줄였다고 합니다. 특정 계산 작업의 병목을 개선한 결과이지, GPT-6.1 Sol 단독으로 전체 연구 성능을 끌어올린 수치는 아닙니다.
기다리는 방식에도 문제가 있었습니다. 에이전트가 완료 여부를 반복 조회하면서 토큰을 쓰고 문맥을 상태 확인 기록으로 채웠기 때문입니다.
이 사례의 개선 대상은 계산 지연뿐 아니라 기다리는 동안 발생하던 불필요한 조회까지 포함했습니다.
에이전트 하네스가 실행과 감독을 나눠 맡습니다
정량 연구는 Docker 환경 안의 기본 Codex 하네스에서 진행됩니다. 회사는 여기에 데이터, 문서, 연구 저장소를 제공하고 하네스는 도구 사용과 계획 수립, 목표 설정, 하위 에이전트 생성, 문맥 압축을 담당합니다.
쉽게 말해 이 사례의 에이전트 하네스는 모델이 실제 작업을 이어가도록 받쳐주는 실행 틀입니다. 어떤 자료를 보고 어떤 도구로 행동할지, 길어진 작업 문맥을 어떻게 정리할지가 이 틀 안에서 다뤄집니다.
감독은 한 겹 더 있습니다. GPT-6 Sol 또는 GPT-6.1 Sol 기반 외부 하네스가 Codex를 하위 에이전트로 다루며 작업이 미완료되면 실행 기록을 살펴 재시도, 종료, 사람 검토로 전달 중 하나를 선택합니다.
무조건 다시 돌리거나 인간 감독을 없앤 구조가 아닙니다.
오래 실행한다는 것과 계속 실행시킨다는 것은 다릅니다. 이 사례에서 주목할 지점은 실패를 숨기는 대신 미완료 상태를 확인하고 다음 처리를 구분했다는 점입니다.
보안 검사와 확장 목표는 따로 읽어야 합니다
회사는 시뮬레이션을 시작하기 전에 Daybreak로 연구 환경의 보안 테스트를 자동화합니다. 에이전트가 연구 환경을 벗어나 외부 네트워크에 접근할 수 있는지 검사하는 용도입니다.
이는 보안이 완전히 보장됐다는 뜻도, 실제 탈출 공격이 성공했다는 뜻도 아닙니다. 에이전트에 인터넷 무제한 연결을 허용했다는 설명으로 확대해서도 안 됩니다.
규모 역시 현재와 목표를 나눠 봐야 합니다. 공식 사례가 소개한 현재 동시 운영 규모는 1만 개이며 수십만 개의 협업 하위 에이전트로 확대하는 것은 향후 목표입니다.
특정 회사의 금융 연구 결과를 콘텐츠 제작이나 모든 기업의 성과로 일반화할 근거도 아닙니다.
실무에 적용한다면 완료와 중단부터 정합니다
여기부터는 공식 제품 기능이나 검증된 효과가 아니라 사례를 참고한 일반적인 실무 권고입니다. 장시간 AI 작업을 검토한다면 실행 시간을 늘리기 전에 완료 기준부터 정하는 편이 좋습니다.
어떤 결과물이 있어야 완료인지, 중간 결과는 어디에 저장할지, 같은 오류가 반복되면 언제 중단할지를 업무별로 적어두는 방식입니다. 재시도만으로 해결할 문제와 사람 검토가 필요한 문제를 구분하는 기준도 함께 검토할 수 있습니다.
권한과 비용도 별도 점검 대상입니다. 접근 가능한 데이터와 도구의 범위, 허용할 실행 시간과 비용, 한도에 도달했을 때의 처리 방식을 정해두는 것이 출발점입니다.
이 사례를 볼 때 가져갈 질문은 “우리도 1만 개를 돌릴 수 있을까?”보다 “끝나지 않은 작업을 누가, 어떤 기준으로 처리할까?”에 가깝습니다.
한 줄 요약: 장시간 AI 작업의 핵심은 오래 돌리는 모델뿐 아니라 완료·재시도·중단·사람 검토를 구분하는 운영 구조입니다.
참고 출처
OpenAI가 2026년 10월 14일 공개한 고객 사례를 기준으로 작성했습니다. 운영 규모와 개선 결과는 해당 회사 환경에 한정합니다.
감자나라 AI 강의보기 5,000 
