2025년 9월, OpenAI는 에이전트 기반 코딩에 최적화한 첫 번째 GPT-5 버전인 GPT-5-Codex를 공개했습니다. 그해 12월에 5.2를 출시하면서 사람들은 자율 코딩 에이전트에 작업을 믿고 맡길 수 있다고 생각하기 시작했습니다. 특히 모델이 지시를 안정적으로 따를 수 있는 시간이 크게 늘었습니다.
저는 그 한계가 어디까지인지 시험해 보고 싶었습니다. 그래서 Codex에 빈 리포지터리와 전체 권한을 주고 디자인 도구를 처음부터 만들어 달라는 과제 하나를 맡겼습니다. 모델은 GPT-5.3-Codex를 사용하고 추론 수준은 ‘Extra High’로 설정했습니다. Codex는 약 25시간 동안 중단 없이 작업하면서 약 1,300만 토큰을 사용했고 코드 약 3만 줄을 생성했습니다.
이번 작업은 프로덕션 배포를 위한 것이 아니라 실험이었습니다. 그래도 장시간 작업에서 중요한 일은 잘 해냈습니다. 명세를 따르고, 주어진 과제에 집중하고, 결과를 검증하고, 도중에 문제가 생기면 바로 수정했습니다.
장시간 실행한 Codex 세션 살펴보기
Codex에 이번 세션의 데이터를 요약한 페이지를 만들어 달라고 했습니다.
CLI에서 확인한 세션 통계와 토큰 사용량은 다음과 같습니다.
이 화면에서 에이전트 기반 코딩의 변화를 확인할 수 있습니다. 원샷으로 문제를 얼마나 잘 푸는지와 더불어, 에이전트가 감당할 수 있는 작업 시간 범위가 점점 중요해지고 있습니다.
달라진 것은 작업 시간 범위입니다
단순히 ‘모델이 더 똑똑해졌다’는 이야기만은 아닙니다. 실제로 에이전트는 더 오래 일관성을 유지하고, 더 큰 단위의 작업을 처음부터 끝까지 마무리하며, 오류가 발생해도 작업 맥락을 놓치지 않고 복구할 수 있게 됐습니다.
METR의 작업 시간 범위 벤치마크를 보면 이 추세를 이해하기 쉽습니다. 프런티어 에이전트가 약 50%와 80%의 성공률로 완수할 수 있는 소프트웨어 작업의 길이가 빠르게 늘고 있으며, 대략 7개월마다 두 배가 됩니다. AI의 장시간 작업 수행 능력 측정(METR)을 참고하세요.
최근 GPT-5.3-Codex 출시 발표에서 소개했듯이, 에이전트의 작업 능력은 두 가지 측면에서 더 발전했습니다.
- 여러 단계에 걸친 작업(계획 → 구현 → 검증 → 수정)을 더 잘 수행합니다.
- 전체 작업을 처음부터 다시 시작할 필요 없이 도중에 방향을 조정하기가 더 쉬워졌습니다. 방향을 바꿔도 그때까지의 작업 결과는 유지됩니다.
Cursor가 브라우저를 만든 실험을 비롯해 장시간 실행되는 자율 코딩 시스템을 다룬 글에서도 영감을 받았습니다. Cursor가 웹 브라우저를 만든 방법(에이전트 확장)에서 자세히 볼 수 있습니다.
Cursor 팀은 OpenAI 모델이 “장시간 자율적으로 작업하는 능력이 훨씬 뛰어나다. 지시를 따르고, 집중력을 유지하고, 목표에서 벗어나지 않으며, 요구 사항을 정확하고 빠짐없이 구현한다”고 썼습니다.
Codex가 장시간 작업에서도 일관성을 유지하는 이유
장시간 작업에서는 하나의 방대한 프롬프트보다 모델이 어떤 에이전트 루프 안에서 작동하는지가 더 중요합니다.
Codex의 루프는 대략 다음과 같습니다.
- 계획 수립
- 코드 수정
- 도구 실행(테스트, 빌드, 린트)
- 결과 확인
- 실패 원인 수정
- 문서와 진행 상태 업데이트
- 반복
이 루프를 통해 에이전트는 다음을 활용할 수 있습니다.
- 실제 작업 결과에 기반한 피드백(오류, 변경 내역, 로그)
- 외부에 기록된 작업 상태(리포지터리, 파일, 문서, 작업 트리, 출력 결과)
- 작업 도중 방향을 조정할 수 있는 구조(사용자가 결과를 보고 방향을 바로잡을 수 있음)
Codex 모델을 일반 채팅 창보다 Codex 환경에서 사용할 때 더 잘 작동한다고 느끼는 이유도 여기에 있습니다. 하네스가 리포지터리 메타데이터, 파일 트리, 변경 내역, 명령어 출력 등 구조화된 컨텍스트를 제공하고, 에이전트가 정해진 절차에 따라 완료 조건을 확인하도록 하기 때문입니다.
최근 공개한 글에서 Codex 에이전트 루프를 더 자세히 설명합니다.
이 루프를 일상 업무에 활용할 수 있도록 Codex App도 출시했습니다.
- 여러 프로젝트에서 스레드 병렬 실행 (오래 걸리는 작업을 맡겨 두고 일상 업무를 계속할 수 있습니다)
- 스킬 (계획, 구현, 테스트, 보고 절차를 표준화합니다)
- 자동화 (반복 작업을 백그라운드에서 처리합니다)
- Git 작업 트리 (각 작업을 분리해 변경 내역을 검토하기 쉽게 유지하고 불필요한 재작업을 줄입니다)
실험 환경 구성
이번 실험에서 디자인 도구를 선택한 이유는 어설픈 구현이 바로 드러나기 때문입니다. UI, 데이터 모델, 편집 기능을 모두 구현해야 하고 예외 상황도 많습니다. 겉모습만 그럴듯하게 만들어서는 통하지 않습니다. 아키텍처를 잘못 설계하면 금방 문제가 생깁니다.
GPT-5.3-Codex에 상세한 명세를 주고 추론 수준을 ‘Extra High’로 설정했습니다. 모델은 약 25시간 동안 중단 없이 일관되게 작업해 품질 좋은 코드를 완성했습니다. 마일스톤을 마칠 때마다 테스트, 린트, 타입 검사도 실행해 결과를 검증했습니다.
핵심 아이디어는 프로젝트 맥락을 오래 보존하는 것입니다
가장 중요한 방법은 프로젝트 정보를 지속적으로 참조할 수 있게 기록하는 것이었습니다. 저는 Codex가 언제든 다시 읽을 수 있도록 명세, 계획, 제약 조건, 진행 상태를 마크다운 파일에 작성했습니다. 덕분에 작업이 목표에서 벗어나지 않았고 ‘완료’의 기준도 일관되게 유지됐습니다.
아래 링크에서 리포지터리를 확인할 수 있습니다. 사용한 파일은 다음과 같습니다.
Prompt.md (명세와 결과물)
목적은 목표를 명확히 고정해 에이전트가 ‘그럴듯하지만 요구 사항에 맞지 않는 결과물’을 만드는 일을 막는 것입니다.
파일의 주요 항목은 다음과 같습니다.
- 목표와 목표에서 제외할 사항
- 반드시 지켜야 할 제약 조건(성능, 결정성, UX, 플랫폼)
- 결과물(작업 완료 시 반드시 갖춰야 할 항목)
- 완료 조건(점검 항목과 데모 플로우)
첫 프롬프트에서는 Codex에 프롬프트와 명세를 담은 파일을 프로젝트 전체 명세로 삼아 마일스톤별 계획을 세우라고 지시했습니다.
Plan.md (마일스톤과 검증 절차)
목적은 범위가 정해지지 않은 작업을 에이전트가 차례로 완료하고 검증할 수 있는 단계로 나누는 것입니다.
파일의 주요 항목은 다음과 같습니다.
- 루프 한 번에 완료할 수 있는 크기의 마일스톤
- 마일스톤별 인수 기준과 검증 명령어
- 검증 실패 시 작업을 멈추고 수정한 뒤 다음 단계로 넘어가는 규칙
- 같은 결정을 반복해서 번복하지 않도록 남긴 결정 기록
- 코드베이스의 목표 아키텍처
최근 Codex App, CLI, IDE 확장 프로그램에 플랜 모드가 기본 기능으로 추가됐습니다. 플랜 모드를 사용하면 변경을 시작하기 전에 큰 작업을 검토하기 쉬운 명확한 단계로 나눌 수 있어 접근 방식을 미리 조율할 수 있습니다. 더 명확히 할 부분이 있으면 Codex가 추가로 질문합니다. 플랜 모드를 켜려면 /plan 슬래시 명령어를 사용하세요.
Implement.md (계획을 참조하는 실행 지침)
이 파일은 실행 절차서입니다. 계획을 따르고, 변경 범위를 제한하고, 검증을 실행하고, 문서를 업데이트하는 등 Codex가 작업하는 방식을 구체적으로 지정합니다.
파일의 주요 항목은 다음과 같습니다.
- 마일스톤별 작업은 계획을 담은 마크다운 파일을 기준으로 진행
- 각 마일스톤을 마칠 때마다 검증 실행(실패하면 즉시 수정)
- 변경 내역을 정해진 범위로 제한(작업 범위 확대 금지)
- 작업을 기록하는 마크다운 문서를 지속적으로 업데이트
Documentation.md (구현 과정의 진행 상태와 결정 사항)
이 파일은 프로젝트 정보를 공유하고 작업 이력을 추적하는 감사 로그 역할을 합니다. 덕분에 몇 시간 자리를 비웠다가 돌아와도 그동안 어떤 일이 있었는지 파악할 수 있습니다.
파일의 주요 항목은 다음과 같습니다.
- 현재 마일스톤의 진행 상태(완료한 작업과 다음 작업)
- 결정 사항과 그 이유
- 실행 및 데모 방법(명령어와 간단한 스모크 테스트)
- 알려진 문제와 후속 작업
실제 작업에서 마일스톤별 검증은 다음과 같이 진행됐습니다.
모든 마일스톤에서 검증하기
Codex는 코드를 작성한 뒤 잘 작동하리라고 가정하지 않았습니다. 마일스톤을 마칠 때마다 검증 명령어를 실행했고, 실패하면 문제를 수정한 후에 작업을 이어 갔습니다.
다음은 Codex에 사용하도록 지시한 품질 검증 명령어의 예입니다.
다음은 린트 검사에 실패한 뒤 Codex가 문제를 수정한 예입니다.
에이전트가 만든 결과물
결과물은 완벽하지 않았고 프로덕션에 바로 배포할 수준도 아니었지만, 직접 실행하고 테스트할 수 있었습니다. 이번 실험의 기준은 ‘컴파일이 되는가’보다 높았습니다. ‘지시대로 구현했는가, 그리고 실제로 작동하는가’가 기준이었습니다.
구현한 주요 기능은 다음과 같습니다.
- 캔버스 편집(프레임, 그룹, 도형, 텍스트, 이미지와 아이콘, 버튼, 차트)
- 실시간 협업(접속 상태, 커서, 선택 영역, 편집 내용이 탭 간에 동기화됨)
- 인스펙터에서 위치와 크기, 스타일, 텍스트 조정
- 레이어 관리(검색, 이름 변경, 잠금 및 숨기기, 순서 변경)
- 가이드, 정렬, 스냅
- 작업 이력 스냅샷 생성 및 복원
- 타임라인 재생 및 이전 시점에서 브랜치 생성
- 프로토타입 모드(핫스폿과 플로우 탐색)
- 댓글(특정 위치에 고정한 스레드를 해결 처리하거나 다시 열기)
- 내보내기(저장, 가져오기, 내보내기 및 CLI를 통한 JSON과 React + Tailwind 코드 내보내기)
Codex에 장시간 작업을 맡길 때의 요점
이번 실험이 잘 진행된 것은 기발한 프롬프트 하나 덕분이 아니었습니다. 다음 요소가 함께 작용했습니다.
- 명확한 목표와 제약 조건(명세 파일)
- 단계별로 점검할 수 있도록 인수 기준을 정한 마일스톤(
plans.md) - 에이전트의 작업 방식을 정한 실행 절차서(
implement.md) - 지속적인 검증(테스트, 린트, 타입 검사, 빌드)
- 진행 상태와 작업 이력을 계속 기록해 언제든 작업 과정을 확인할 수 있게 한 감사 로그(
documentation.md)
장시간 코딩 작업은 사람이 일일이 지켜보는 시간을 줄이고, 에이전트가 지킬 기준을 마련해 더 많은 일을 위임하는 방향으로 나아가고 있습니다.
직접 Codex에 장시간 작업 맡겨 보기
Codex를 25시간 동안 실행한 이번 실험은 앞으로 코드로 제품을 만드는 방식이 어떻게 달라질지 보여 줍니다. 한 번의 프롬프트로 결과를 얻거나 페어 프로그래밍으로 매 단계 함께 작업하는 방식을 넘어, 이제 에이전트는 실제 업무의 일부를 처음부터 끝까지 맡아 장시간 일하는 팀원이 되어 가고 있습니다. 사람은 코드 한 줄 한 줄을 관리하는 대신 마일스톤마다 방향을 조정합니다.
Codex가 지향하는 방향은 단순합니다. 팀원처럼 더 잘 협업하고, 사용자의 실제 작업 컨텍스트와 더 긴밀하게 연동되며, 신뢰할 수 있는 결과물을 쉽게 검토하고 배포하도록 안전장치를 제공하는 것입니다. 에이전트가 반복적인 구현과 검증을 맡으면서 개발자가 더 빠르게 일하는 모습을 이미 볼 수 있습니다. 덕분에 사람은 디자인, 아키텍처, 제품 관련 의사 결정, 정해진 해법이 없는 새로운 문제에 집중할 수 있습니다.
이 변화는 개발자에게만 국한되지 않습니다. Codex가 사용자의 의도를 더 정확히 파악하고 계획, 검증, 미리 보기, 롤백을 통해 안전하게 작업할 수 있는 기반을 제공할수록, 더 많은 비개발자가 IDE를 늘 사용하지 않고도 직접 만들고 개선할 수 있게 됩니다. 앞으로 Codex의 여러 환경과 모델에 더 많은 변화가 있을 예정이지만 목표는 같습니다. 에이전트가 계속 지켜봐야 하는 도구에서 벗어나 장시간 작업을 믿고 맡길 수 있는 팀원처럼 느껴지게 하는 것입니다.
직접 시도해 보려면 다음 문서부터 살펴보세요.