에이전트가 몇 시간씩 일해도 실험 성공까지 사람의 개입이 반복됩니다.
가장 빠른 해법은 모든 작업을 감시하는 것이 아니라, 작업을 세 등급으로 나누고 위험한 도구 호출에서만 멈추게 한 뒤 상태를 저장하고 격리된 작업 공간에서 재개하는 것입니다.
이 글은 코덱스가 장시간 실험, 코드 수정, 평가 작업을 맡은 연구팀을 위한 안내입니다. 에이전트 플랫폼과 작업 대기열을 운영하는 플랫폼 엔지니어, 원격 맥과 엑스코드 작업을 관리하는 기술 책임자도 함께 적용할 수 있습니다.
배포 전 경계선
오픈에이아이 자동 연구 인턴을 실제 업무에 연결할 때 가장 먼저 해야 할 일은 모델의 답변을 평가하는 것이 아닙니다. 어떤 행동을 자동으로 허용하고, 어느 시점에 사람의 승인을 요구할지 정하는 일입니다. OpenAI가 2026년 9월 6일 공개한 연구 글에서도 복잡한 성공 작업에는 여전히 사람의 안내가 자주 필요하다고 설명합니다. 이 결과는 오픈에이아이 내부 연구와 자체 측정에 관한 것이며, 일반 팀의 성공률이나 생산성 보장으로 해석하면 안 됩니다. 오픈에이아이의 연구 공개 내용을 먼저 확인해야 합니다.
작업을 다음 세 범주로 나누면 승인 대기열이 과도하게 커지는 것을 막을 수 있습니다.
- 읽기 전용 조회, 임시 분석, 이미 분리된 작업 공간 안의 로그 확인은 자동 실행 대상으로 둡니다.
- 코드 패치, 임시 파일 생성, 다시 실행할 수 있는 실험 제출은 조건부 승인으로 둡니다.
- 공유 저장소 반영, 외부 시스템 기록, 권한 변경, 비용이 발생하는 실행은 반드시 사람이 승인합니다.
승인자는 모델의 숨은 추론 과정을 판정하는 사람이 아닙니다. 도구 이름, 전달 인자, 대상 작업 공간, 예상 변경 범위와 외부 영향처럼 관찰 가능한 정보만 확인해야 합니다. 도구 호출 하나에 모든 권한을 묶으면 읽기 작업까지 대기하게 되고, 반대로 모든 호출을 자동 승인하면 거부와 복구의 경계가 사라집니다.
주의: 승인 화면에 자연어 설명만 보여주지 마십시오. 저장소 버전, 실행 환경, 쓰기 대상과 외부 부작용을 함께 표시해야 잘못된 작업 공간에서 승인하는 사고를 줄일 수 있습니다.
첫 시간의 상태 보존
OpenAI Agents SDK를 연결할 때는 실행 함수보다 중단 이후의 상태 모델을 먼저 설계해야 합니다. 공식 문서의 interruption과 RunState는 승인 대기 중인 도구 호출과 실행 상태를 직렬화하고 다시 이어 가는 기반을 제공합니다. 다만 RunState가 외부 부작용을 자동으로 취소하거나 되돌려 주는 기능은 아닙니다. 인간 승인 문서와 RunState 문서를 기준으로 구현 범위를 확인하십시오.
상태에는 다음 항목을 넣습니다.
- 승인 대기 중인 도구 이름과 인자 요약
- 작업 버전과 사용한 모델, 프롬프트, 도구 스키마 버전
- 연결된 저장소와 격리 작업 공간 식별자
- 완료한 단계, 마지막 성공 단계와 다음 재개 지점
- 현재 승인자, 대기 시각, 만료 정책
상태를 연구자의 노트북이나 채팅 세션에만 남기면 프로세스가 종료되거나 담당자가 자리를 비운 순간 작업을 잃습니다. 애플리케이션 데이터베이스나 지속 큐에 저장해야 합니다. 반대로 에이피아이 비밀 키, 저장소 토큰과 같은 민감 정보는 상태에 넣지 말고 실행 환경의 비밀 저장소에서 다시 주입해야 합니다. 에이전트 실행 결과와 문맥의 경계는 실행 결과 문서와 문맥 문서에서 함께 점검할 수 있습니다.
승인 후에는 원래 작업에서 어떻게 계속 실행합니까?
승인 이벤트가 도착하면 새 작업으로 자연어 지시를 다시 보내지 말고, 저장된 상태의 작업 버전과 대기 중 도구 호출을 검증한 뒤 재개해야 합니다. 승인 결정과 재개 결과를 같은 사건 기록에 묶으십시오. 모델, 프롬프트, 도구 스키마 또는 작업 공간이 바뀌었다면 이전 승인을 폐기하고 다시 계획하거나 다시 승인해야 합니다.
첫 실행의 가역성
첫 시험에서는 코드 패치, 임시 분석 파일, 읽기 전용 실험 조회처럼 결과를 되돌릴 수 있는 작업만 연결합니다. OpenAI Agents SDK의 승인 흐름은 호출을 멈추고 사람의 결정을 기다리는 데 사용되지만, 실제 도구가 중단 전에 실행되지 않는지는 여러분의 연결 코드와 도구 경계가 결정합니다. 따라서 승인 전과 승인 후의 도구 로그를 분리해 남겨야 합니다.
다음 세 경로를 각각 실행하십시오.
- 승인: 도구가 한 번만 실행되고 결과가 같은 작업 상태에 기록되는지 확인합니다.
- 거부: 작업이 안전하게 종료되거나 변경된 계획으로 다시 대기하는지 확인합니다.
- 장기 대기: 담당자가 처리하지 않아도 큐가 중복 호출을 만들지 않고 만료 상태로 남는지 확인합니다.
거부를 일반 네트워크 오류처럼 취급하면 에이전트가 같은 작업을 계속 재시도할 수 있습니다. 거부에는 별도의 사건 유형을 부여하고, 재계획 조건과 종료 조건을 분리해야 합니다. 도구 이름, 인자 요약, 승인자 식별자, 결정 시각, 재개 결과를 모두 기록하십시오.
여러 코덱스 작업의 인계 책임은 어떻게 나눕니까?
작업마다 담당자를 수동으로 찾지 말고 저장소, 위험 등급, 실행 환경을 기준으로 라우팅하십시오. 읽기 전용 작업은 공용 대기열에 둘 수 있지만, 공유 저장소 쓰기와 외부 기록은 소유 팀의 승인자에게 보내야 합니다. 승인자가 자리를 비우면 대체 승인자에게 넘기고, 대기 중인 입력 버전은 고정해야 합니다. 한 사람이 여러 작업을 동시에 승인할 때는 각 작업의 환경 식별자가 화면에 함께 보여야 합니다.
첫날의 격리 연결
승인 대기열과 실행 환경을 따로 만들면 승인자는 올바른 결정을 해도 다른 호스트에서 작업을 풀어 줄 수 있습니다. 각 연구 작업에 저장소 버전, 코드 작업 공간, 실행 환경을 하나의 식별자로 묶으십시오. 일반 실험은 일회성 작업 공간으로 처리하고, 맥 운영체제나 엑스코드, 데스크톱 도구가 필요한 작업은 격리된 클라우드 맥 풀로 보내는 방식이 안전합니다.
이 단계에서 확인할 항목은 다음과 같습니다.
- 승인 화면의 대상 맥, 저장소 버전과 작업 공간 식별자
- 예상 파일 변경 범위와 외부 시스템 기록 여부
- 네트워크 권한, 비밀 값 주입 위치와 종료 시 정리 방식
- 작업 완료, 거부, 만료 때 임시 파일과 인증 정보가 삭제되는지
- 여러 작업이 같은 디렉터리와 포트를 공유하지 않는지
원격 맥 배포 구조를 처음 설계한다면 클라우드 맥에서 에이전트 호스트를 구성하는 안내에서 운영체제와 컨테이너 경계를 먼저 확인하십시오. 맥 작업을 여러 개 병렬로 돌릴 계획이라면 맥 미니 기반 인공지능 에이전트 장비 대여 안내도 작업 공간 분리 관점에서 비교할 수 있습니다.
사십팔 시간 복구 시험
사십팔 시간 안에는 정상 승인보다 예외 경로를 시험해야 합니다. 이 시간 표현은 배포 기준으로 정한 운영 창이며, 오픈에이아이 내부 성과를 뜻하지 않습니다. 다음 상황을 순서대로 재현하십시오.
- 원래 승인자가 오프라인이 된 상태에서 대체 승인자가 인계합니다.
- 에이전트 프로세스를 재시작한 뒤 대기 중 도구 호출을 복원합니다.
- 다른 실행 호스트에서 상태를 불러오되 원래 작업 공간과 일치하는지 확인합니다.
- 도구 정의나 스키마를 바꾼 뒤 기존 승인이 폐기되는지 확인합니다.
- 원격 맥 작업을 거부하고, 변경 없이 종료하거나 새 계획으로 안전하게 재개합니다.
원격 맥에서 긴 작업이 거부되면 안전하게 복구할 수 있습니까?
상태가 저장되어 있고 거부된 호출의 외부 효과가 없으며 작업 공간이 보존되어 있다면 새 승인 절차를 거쳐 재개할 수 있습니다. 그러나 이미 파일을 수정했거나 외부 시스템에 기록했다면 단순한 재개가 아니라 멱등성 확인과 변경 검사가 먼저입니다. 환경이 바뀌었거나 인증 정보가 만료되었다면 기존 결정을 재사용하지 말고 새 계획을 세워야 합니다.
첫 주의 확대 조건
첫 주에는 작업 유형별로 개입 이유, 승인 대기 시간, 거부 결과, 중복 부작용, 독립 재실행 결과를 기록하십시오. 오픈에이아이 연구 조직의 내부 측정값을 여러분의 목표치로 복사해서는 안 됩니다. 내부 연구는 적용 범위와 측정 방식이 다르기 때문입니다. 오픈에이아이의 연구 가속화 설명도 이 범위에서 읽어야 합니다.
다음 목록은 확대 전 실제로 확인할 수 있는 운영 판단 도구입니다.
- [ ] 승인 전 도구가 실행되지 않는다는 로그를 확인했습니다.
- [ ] 승인, 거부, 장기 대기 세 경로의 결과가 서로 구분됩니다.
- [ ] 상태가 연구자 단말이 아닌 데이터베이스나 지속 큐에 저장됩니다.
- [ ] 상태에 비밀 키와 저장소 토큰이 포함되지 않습니다.
- [ ] 작업 공간, 저장소 버전과 실행 호스트가 승인 화면에서 일치합니다.
- [ ] 프로세스 재시작과 다른 호스트 복구를 완료했습니다.
- [ ] 도구 스키마나 환경 변경 시 재승인이 발생합니다.
- [ ] 거부된 작업이 오류 재시도로 무한 반복되지 않습니다.
- [ ] 작업 완료와 거부 뒤 임시 파일, 인증 정보가 정리됩니다.
- [ ] 독립 담당자가 최종 결과를 다시 실행해 확인했습니다.
목록에서 하나라도 빠지면 장시간 작업이나 동시 에이전트 수를 늘리지 마십시오. 조건을 모두 통과한 뒤에도 모든 승인 단계를 자동화할 필요는 없습니다. 기록상 반복되는 저위험 호출만 규칙 기반 자동 승인으로 옮기고, 공유 저장소와 외부 시스템 쓰기는 계속 사람에게 남기는 편이 낫습니다.
현재 개발자 맥 한 대에서 이 흐름을 운영하면 작업 충돌, 장시간 실행 중단, 담당자 변경 때의 상태 유실이 실제 제약이 됩니다. 공용 서버는 맥 전용 도구와 데스크톱 세션을 분리하기 어렵고, 작업을 오래 유지할수록 다른 실험과 권한이 섞일 위험도 커집니다. 반면 MacPull의 클라우드 맥을 임시 실행 풀로 사용하면 작업별 맥 환경을 분리하고, 승인 뒤 필요한 작업만 연결하는 구조를 검증하기가 수월합니다. 먼저 위의 중단·거부·복구 시험을 통과시킨 뒤, 원격 맥 계약과 운영 절차를 확인해 단기 실험 풀로 시작할지 지속 환경으로 확장할지 결정하십시오.