Codex 장기 작업 운영법: 1시간짜리 에이전트 일을 안전하게 맡기는 기준

OpenAI는 내부 Codex 사용 데이터를 공개하면서 에이전트 사용 방식이 짧은 대화에서 장기 위임 작업으로 이동하고 있다고 설명했다. 2026년 5월 기준 샘플링된 개인 사용자 중 70.2%가 사람이 1시간 이상 걸릴 것으로 추정되는 Codex 요청을 최소 한 번 보냈고, 25.6%는 8시간 이상 규모의 요청을 보냈다고 한다. 내부 OpenAI 직원의 경우 Codex가 주간 출력 토큰의 99.8%를 차지한다는 수치도 나왔다.

이 숫자를 그대로 자기 팀에 대입할 필요는 없다. 중요한 것은 방향이다. AI 코딩 도구는 이제 “함수 하나 설명해줘”에서 “이 기능을 분석하고 수정하고 테스트까지 돌려줘”로 이동했다. 따라서 개발팀은 프롬프트 팁보다 운영 기준을 먼저 세워야 한다.

긴 작업은 좋은 프롬프트보다 작업 정의가 중요하다

1시간짜리 에이전트 작업은 질문이 아니라 위임이다. 위임에는 목표, 제약, 완료 기준, 중단 조건이 필요하다. “결제 오류 고쳐줘”는 부족하다. “결제 실패 시 retry가 중복 청구를 만들 수 있는지 확인하고, 재현 테스트를 작성한 뒤, 코드 변경은 최소화하고, 위험하면 수정 전 보고하라”처럼 써야 한다.

좋은 작업 정의에는 다음 요소가 들어간다.

• 목표: 무엇을 바꿀 것인가
• 범위: 어떤 파일과 모듈을 볼 수 있는가
• 금지: 어떤 행동을 하면 안 되는가
• 검증: 어떤 테스트나 빌드를 통과해야 하는가
• 보고: 결과를 어떤 형식으로 남길 것인가

특히 금지 조건이 중요하다. 에이전트는 목표를 달성하려고 돌아가는 시스템이다. “테스트 통과”만 강조하면 스냅샷을 잘못 수정하거나, 실패 테스트를 삭제하거나, 근본 원인 대신 우회 코드를 넣을 수 있다.

작업 크기를 시간 단위로 나눠야 한다

Codex 데이터에서 30분, 1시간, 4시간, 8시간 기준이 나온 점은 실무적으로 유용하다. 에이전트 작업도 티켓처럼 크기를 재야 한다. 모든 일을 한 번에 맡기면 중간 경로가 보이지 않는다.

권장 분류는 다음과 같다.

처음부터 8시간짜리 일을 맡기는 팀은 실패 원인을 알기 어렵다. 먼저 30분 단위 작업에서 로그, 테스트, 리뷰 흐름을 안정화한 뒤 긴 작업으로 늘려야 한다.

병렬 에이전트는 속도보다 충돌 관리가 먼저다

OpenAI는 상위 사용자가 하루에 60시간 이상의 Codex agent turns를 여러 병렬 에이전트로 생성한다고 설명했다. 병렬화는 매력적이다. 하지만 같은 저장소에서 여러 에이전트가 동시에 수정하면 충돌, 중복 구현, 테스트 오염이 생긴다.

실무에서는 병렬 작업을 세 종류로만 허용하는 것이 안전하다.

1. 읽기 전용 조사: 코드베이스 분석, 로그 원인 후보 정리
2. 독립 영역 수정: 서로 다른 패키지나 화면의 변경
3. 대안 생성: 같은 문제에 대한 2~3개 해결안 작성, 최종 적용은 하나만 선택

반대로 같은 파일을 여러 에이전트가 고치게 하거나, DB 스키마와 API와 프론트를 동시에 여러 에이전트가 만지게 하는 것은 위험하다. 속도보다 merge 가능성이 먼저다.

코드 에이전트 로그는 결과보다 과정 중심으로 남겨야 한다

사람 개발자는 PR 설명에 “무엇을 바꿨는지”를 쓴다. 에이전트는 여기에 “어떻게 판단했는지”가 추가로 필요하다. 그렇지 않으면 리뷰어가 결과 diff만 보고 추론해야 한다.

최소 로그 항목은 다음과 같다.

• 읽은 파일 목록
• 주요 가정
• 변경한 파일 목록
• 실행한 테스트와 결과
• 실패한 시도와 되돌린 이유
• 남은 위험
• 사람이 확인해야 할 지점

이 로그는 감사 목적만이 아니다. 다음 에이전트 실행의 컨텍스트가 된다. “이전 시도에서 A 방식은 실패했고 B 파일의 테스트가 깨졌다”는 정보가 남아 있으면 같은 실패를 반복하지 않는다.

비개발 부서 사용까지 고려하면 권한 모델이 바뀐다

OpenAI 발표에서 흥미로운 지점은 Legal, Finance, Recruiting 같은 비개발 부서도 Codex를 주 AI 도구로 쓰기 시작했다는 점이다. 이는 코딩 에이전트가 개발팀 내부 도구로만 남지 않는다는 뜻이다. 데이터 변환, 자동화 스크립트, 내부 도구 수정, 리포트 생성은 비개발자도 맡길 수 있다.

하지만 비개발자에게 바로 저장소 쓰기 권한을 주면 안 된다. 권장 흐름은 다음과 같다.

• 비개발자는 요구사항과 샘플 데이터를 제공한다.
• 에이전트는 별도 브랜치나 샌드박스에서 결과를 만든다.
• 자동 테스트와 정적 검사를 통과해야 한다.
• 코드 소유자가 PR을 리뷰한다.
• 운영 반영은 CI/CD 권한을 가진 사람이 승인한다.

이렇게 하면 비개발자도 자동화 이점을 얻으면서 운영 시스템의 안정성은 유지할 수 있다.

바로 적용할 체크리스트

Codex나 Claude Code 같은 코딩 에이전트를 장기 작업에 쓰려면 다음부터 정리한다.

1. 에이전트 작업을 10분, 30분, 1시간, 4시간, 8시간 이상으로 분류한다.
2. 1시간 이상 작업에는 계획, 중간 체크포인트, 완료 기준을 필수로 둔다.
3. 병렬 실행은 읽기 전용 조사나 독립 영역 수정으로 제한한다.
4. 모든 실행에 읽은 파일, 변경 파일, 테스트 결과, 실패 시도를 로그로 남긴다.
5. 테스트 삭제, 스냅샷 무단 갱신, 보안 설정 완화는 금지 규칙으로 둔다.
6. 비개발자 요청은 샌드박스 브랜치와 PR 리뷰를 거치게 한다.
7. 성공 기준을 “응답이 그럴듯한가”가 아니라 “테스트와 리뷰를 통과했는가”로 바꾼다.

코딩 에이전트의 생산성은 모델 성능만으로 결정되지 않는다. 긴 작업을 맡길 수 있는 구조를 만든 팀과 그렇지 않은 팀의 차이가 커진다. 지금 필요한 것은 더 멋진 프롬프트가 아니라, 에이전트가 실패해도 안전하게 멈추고 사람이 이어받을 수 있는 운영 체계다.