OpenAI Codex app 26.616 릴리스에서 가장 실무적인 변화는 Record & Replay입니다. 2026년 6월 18일 Codex changelog에 따르면 이 기능은 macOS에서 사용자가 직접 시연한 워크플로우를 재사용 가능한 skill로 바꿉니다. 초기 제공 지역에는 EEA, UK, Switzerland가 제외되고, Computer Use도 활성화돼야 합니다. 겉으로 보면 데모 녹화 기능처럼 보이지만, 개발팀 관점에서는 “반복 작업을 agent playbook으로 만드는 방식”에 가깝습니다.
이 글은 Record & Replay를 어디에 쓰면 좋은지, 어디에는 쓰면 안 되는지, 기존 스크립트/매크로/CI와 어떻게 구분해야 하는지 정리합니다. 특히 AI 코딩 에이전트를 팀에 도입했지만 매번 같은 온보딩, 브랜치 정리, QA, 릴리즈 노트 작성에서 시간이 새는 팀이라면 이번 업데이트를 운영 프로세스 관점에서 볼 필요가 있습니다.
일반적인 매크로는 클릭 좌표와 키 입력을 재생합니다. 화면이 조금 바뀌면 실패합니다. Codex Record & Replay가 흥미로운 이유는 Computer Use와 결합해 사람이 보여준 절차를 skill 형태로 재사용하려는 방향이기 때문입니다. 즉, “이 화면에서 이 버튼을 누른다”보다 “릴리즈 전 대시보드에서 실패한 job을 확인하고, 관련 로그를 열고, 원인을 요약한다” 같은 업무 흐름을 캡처하는 데 더 어울립니다.
개발팀에서 반복되는 작업은 생각보다 많습니다.
이런 일은 완전히 자동화하기에는 API가 부족하고, 매번 사람이 하기에는 낭비입니다. Record & Replay는 이 중간 지대를 겨냥합니다.
Record & Replay를 처음 도입할 때 가장 흔한 실수는 너무 큰 업무를 녹화하는 것입니다. 예를 들어 “버그를 고치고 배포까지 해줘”는 skill로 만들기 어렵습니다. 반대로 “Sentry에서 최근 24시간 결제 오류를 열고 상위 3개 stack trace를 요약해줘”는 후보가 됩니다.
좋은 후보는 네 가지 조건을 만족합니다.
예를 들어 QA smoke test는 적합합니다. 로그인, 핵심 화면 이동, 폼 제출, 에러 메시지 확인처럼 절차가 분명합니다. 반면 결제 환불 처리나 고객 계정 삭제처럼 외부 영향이 큰 작업은 바로 자동 replay 대상에 넣으면 안 됩니다. 먼저 read-only 점검 skill로 시작해야 합니다.
반복 작업이라고 모두 Record & Replay로 보내면 운영이 지저분해집니다. 개발팀은 세 가지 자동화 계층을 분리하는 게 좋습니다.
첫째, deterministic 작업은 스크립트나 CI로 처리합니다. 테스트 실행, 린트, 빌드, 타입체크, 마이그레이션 검증은 사람이 화면을 보여줄 필요가 없습니다. 코드로 남겨야 재현성과 감사가 됩니다.
둘째, API가 있는 업무는 서버 사이드 자동화로 처리합니다. GitHub label 정리, Slack 알림, Notion 업데이트, 배포 상태 조회는 API 호출이 더 안전합니다.
셋째, UI와 판단이 섞인 업무가 Record & Replay 후보입니다. 예를 들어 내부 어드민에서 특정 필터를 조합해 데이터를 확인하거나, 브라우저에서 실제 렌더링 상태를 보며 문제를 찾는 작업입니다. 이 영역은 스크립트로 만들기 어렵고, 사람에게 계속 맡기기엔 반복 비용이 큽니다.
Record & Replay 기반 skill을 팀에서 쓰려면 “어떻게 하는지”뿐 아니라 “언제 멈춰야 하는지”가 필요합니다. AI 에이전트는 절차를 따라가다가 애매한 화면이 나와도 계속 진행하려는 경향이 있습니다. 그래서 skill 설명에는 중단 조건을 명시해야 합니다.
예시로 배포 전 어드민 점검 skill을 만든다면 다음 항목을 넣습니다.
이런 규칙이 없으면 replay가 “뭔가 했다”로 끝납니다. 팀 운영에서 필요한 것은 행동이 아니라 검증 가능한 결과입니다.
Record & Replay는 Computer Use가 필요합니다. 이는 에이전트가 화면을 보고 클릭하고 입력할 수 있다는 뜻입니다. 편하지만 권한 설계가 없으면 위험합니다. 특히 브라우저에 로그인 세션이 있고, 어드민 권한이 있으며, production 데이터가 보이는 환경에서는 read-only와 write action의 경계를 명확히 해야 합니다.
권장 운영 방식은 다음과 같습니다. 처음에는 staging 환경에서만 녹화합니다. production에서는 읽기 전용 점검부터 시작합니다. 삭제, 발송, 결제, 권한 변경 같은 action은 replay 대상에서 제외하고 사람 승인으로 남깁니다. 또한 replay 결과는 로그로 남겨 누가 언제 어떤 skill을 실행했는지 확인할 수 있어야 합니다.
팀 단위로는 skill registry를 두는 것도 좋습니다. skill 이름, 목적, 사용 환경, 권한 범위, 마지막 검토일을 적어두면 “누가 만든지 모르는 자동화”가 쌓이는 문제를 줄일 수 있습니다.
Codex Record & Replay는 개발자를 대체하는 기능이라기보다, 개발팀의 반복 업무를 더 잘 문서화하고 실행 가능하게 만드는 기능입니다. 자동화할 수 있는 것은 코드로, 코드화하기 애매한 UI 기반 반복 절차는 skill로, 외부 영향이 큰 결정은 사람 승인으로 남기는 균형이 핵심입니다.
