Codex Record & Replay 원칙
요약
Codex의 Record & Replay 원칙은 사용자의 macOS 워크플로우를 기록하여 재사용 가능한 '스킬(Skill)'로 변환하는 기술을 설명합니다. 단순한 좌표 매크로를 넘어, 이벤트 트레이스를 분석해 API나 Computer Use 등 최적의 도구로 의도를 재현하는 워크플로우 학습 모델을 지향합니다.
핵심 포인트
- 단순 매크로가 아닌 의도(Intent) 기반의 워크플로우 학습
- 이벤트 트레이스를 통한 재사용 가능한 스킬(Skill) 생성
- 상황 변화에 적응하는 안정적인 자동화 도구 활용
- Computer Use 및 MCP 서버를 통한 로컬 플러그인 구현
Codex Record & Replay는 매우 인간적인 습관에서 시작한다는 점에서 흥미롭습니다. 무언가를 설명하기 어려울 때, 한 번 보여주는 것이죠.
모든 클릭, 창 전환, 설정, 예외 상황을 설명하는 긴 프롬프트를 작성하는 대신, 사용자는 macOS에서 워크플로우 (workflow)를 기록합니다. Codex는 이 워크플로우를 관찰하고, 이벤트 트레이스 (event trace)를 읽어 재사용 가능한 스킬 (Skill) 초안을 작성합니다.
핵심 아이디어는 간단합니다:
인간의 시연 (Human demonstration)
-> 구조화된 이벤트 트레이스 (structured event trace)
-> 재사용 가능한 스킬 (reusable Skill)
...
기록된 트레이스는 최종 자동화가 아닙니다. 그것은 증거입니다. 재사용 가능한 결과물은 스킬 (Skill)입니다.
그 차이가 중요합니다.
이것은 좌표 매크로가 아닙니다
전통적인 매크로 기록기는 여기로 이동, 저기를 클릭, 이것을 입력, 잠시 대기와 같은 저수준 동작 (low-level actions)을 기억하는 경향이 있습니다.
이는 금방 깨지기 마련입니다. 버튼이 이동하거나, 페이지가 바뀌거나, 창이 다른 크기로 열릴 수 있습니다. 어떤 실행에서는 사용자가 이미 로그인되어 있고, 다른 실행에서는 로그아웃되어 있을 수도 있습니다.
Record & Replay는 더 나은 모델을 제시합니다. 기록은 Codex가 워크플로우를 이해하는 데 도움을 주지만, 재생 (replay) 시에는 사용 가능한 가장 안정적인 도구를 사용해야 합니다.
API가 있다면, API를 사용하세요.
브라우저 대상이 있다면, 브라우저 자동화 (browser automation)를 사용하세요.
데스크톱 UI가 있다면, Computer Use를 사용하세요.
무언가 변경되었다면, 상태를 확인하고 적응하세요.
이것이 이 제품이 마우스 재생 (mouse replay)보다는 워크플로우 학습 (workflow learning)에 더 가까운 이유입니다.
공개된 형태
공개된 Codex 문서에 따르면, 흐름은 대략 다음과 같습니다:
- 사용자가 Codex에서 기록을 시작합니다.
- 사용자가 macOS에서 워크플로우를 수행합니다.
- Codex가 Computer Use를 통해 동작과 창 컨텍스트 (window context)를 캡처합니다.
- 기록이 중단됩니다.
- Codex가 캡처된 트레이스를 읽습니다.
- Codex가 검사, 편집 및 재사용이 가능한 스킬 (Skill) 초안을 작성합니다.
이는 워크플로우를 설명하는 것보다 보여주는 것이 더 쉬울 때 유용합니다:
- 반복적인 UI 워크플로우
- 개인적 또는 팀의 선호도
- 좋은 API가 없는 도구
- 브라우저 페이지, 데스크톱 앱, 파일 및 대화 상자를 가로지르는 작업
그 약속은 “Codex가 모든 픽셀을 기억한다”가 아닙니다. 그 약속은 “Codex가 데모(demonstration)로부터 재사용 가능한 운영 가이드를 생성할 수 있을 만큼 충분히 학습한다”입니다.
로컬 플러그인이 제안하는 것
로컬 Codex 앱에는 record-and-replay 플러그인이 번들로 포함되어 있습니다. 이 플러그인은 Computer Use 헬퍼(helper)를 통해 event-stream MCP 서버를 노출합니다.
번들된 스킬(Skill)은 Codex에게 다음과 같이 지시합니다:
event_stream_start로 녹화를 시작할 것;event_stream_status로 상태를 확인할 것;event_stream_stop으로 녹화를 중단할 것;- 반환된
metadataPath와eventsPath를 읽을 것; events.jsonl을 주요 증거(evidence)로 취급할 것;session.json을 타이밍 및 경로 메타데이터(metadata)로 취급할 것;- 녹화를 모든 UI 액션을 정확히 재현하라는 명령이 아니라, 의도(intent)의 증거로 사용할 것.
마지막 지점이 설계의 핵심입니다.
헬퍼 바이너리(helper binary)의 문자열 검사(String inspection)를 통해서도 event_stream_start, event_stream_status, event_stream_stop, eventsPath, metadataPath, suppressedEventsPath, AXUIElement, 그리고 screenRecordingGranted와 같은 이름들이 확인됩니다.
이것이 비공개 구현(private implementation)을 드러내지는 않지만, 공개된 형태(public shape)와 일치합니다: macOS 접근성(Accessibility), 입력/윈도우 컨텍스트(input/window context), 화면 컨텍스트(screen context), 로컬 트레이스 파일(local trace files), 그리고 스킬 컴파일러(Skill compiler).
한눈에 보는 아키텍처
flowchart LR
U["사용자가 워크플로우를 시연함"] --> P["Record & Replay 플러그인"]
P --> MCP["event-stream MCP 서버"]
...
중요한 분리는 다음과 같습니다:
- 녹화(Record)는 발생한 일을 포착합니다.
- 트레이스(Trace)는 증거를 저장합니다.
- 컴파일(Compile)은 노이즈가 섞인 증거를 읽기 가능한 스킬(Skill)로 변환합니다.
- 재생(Replay)은 사용 가능한 최선의 도구로 스킬을 실행합니다.
- 검증(Verify)은 결과가 실제로 올바른지 확인합니다.
컴파일(compile)과 검증(verify)이 없다면, 이 시스템은 취약한 매크로 기록기(macro recorder)가 되어버립니다.
이벤트 트레이스(event trace)에 포함되어야 할 내용
공개 문서에는 전체 이벤트 스키마(event schema)가 게시되어 있지 않지만, 유용한 트레이스에는 클릭 이상의 것이 필요합니다.
다음 사항들이 보존되어야 합니다:
- 마우스 및 키보드 동작 (mouse and keyboard actions);
- 포그라운드 앱 및 윈도우 컨텍스트 (foreground app and window context);
- 브라우저 URL 및 페이지 상태 (browser URL and page state);
- 버튼, 필드, 메뉴 및 선택된 객체와 같은 접근성 대상 (Accessibility targets);
- 텍스트 입력 및 선택 (text input and selection);
- 구조가 불완전할 때의 스크린샷 또는 키프레임 (screenshots or keyframes);
- 시작, 중지, 취소, 타임아웃 및 레드액션 (redaction) 경계.
이벤트는 다음과 같이 모델링될 수 있습니다:
{
"timestamp": "2026-06-22T10:00:00.000Z",
"surface": "desktop",
...
핵심은 완벽한 저수준 재생 (low-level playback)이 아닙니다. 핵심은 Codex가 워크플로 (workflow)를 추론할 수 있을 만큼 충분한 증거를 제공하는 것입니다.
스킬 컴파일 (Skill compilation)이 어려운 부분입니다
원시 트레이스 (Raw traces)는 노이즈가 많습니다. 대기 시간, 포커스 변경, 스크롤, 반복된 클릭 및 실수로 인한 동작들이 포함되어 있습니다.
컴파일러는 이를 하나의 스킬 (Skill)로 압축해야 합니다:
flowchart TD
A["events.jsonl"] --> B["Clean noise"]
B --> C["Infer task goal"]
...
좋은 스킬은 다음 사항들을 명시해야 합니다:
- 언제 사용할 것인지;
- 실행 간에 어떤 입력값이 변하는지;
- 어떤 로그인, 권한, 페이지, 파일 또는 앱이 필요한지;
- 어떤 단계가 중요한지;
- 성공을 어떻게 검증할 것인지;
- UI가 변경될 때 어떻게 할 것인지;
- 어떤 민감한 데이터를 저장해서는 안 되는지.
이것이 클래식 RPA (classic RPA)와의 주요 차이점입니다. RPA는 종종 동작을 재생하려고 시도합니다. Record & Replay는 의도 (intent)를 재생하려고 시도합니다.
재생 (Replay)은 가장 강력한 경로를 사용해야 합니다
재생이 events.jsonl을 읽고 모든 줄을 실행하는 것을 의미하지는 않습니다.
나중에 사용자가 유사한 작업을 요청하면, Codex는 스킬 (Skill)을 로드하고, 입력값과 전제 조건 (preconditions)을 해결한 다음, 각 단계에 대해 가장 안정적인 경로를 선택해야 합니다.
flowchart TD
A["User asks for a similar task"] --> B["Codex loads matching Skill"]
B --> C["Resolve inputs and preconditions"]
...
이를 통해 재생의 회복 탄력성 (resilience)이 높아집니다. 버튼의 위치가 바뀌더라도 접근성 이름 (accessible name)이 동일하다면 Codex는 여전히 이를 찾을 수 있습니다. 커넥터나 API가 존재한다면 Codex는 UI를 완전히 건너뛸 수도 있습니다.
유사한 MVP를 구축한다면
저는 브라우저 전용 레코더(browser-only recorder)로 시작하지 않을 것입니다. 흥미로운 점은 Record & Replay가 실제 컴퓨터 워크플로 (workflows)를 학습할 수 있다는 것입니다.
가장 신뢰할 수 있는 최소한의 MVP에는 다음이 필요합니다:
- URL, DOM 타겟, ARIA 역할/이름 (role/name), 셀렉터 (selectors), 입력 (input), 내비게이션 (navigation) 및 스크린샷 (screenshots)을 위한 브라우저 레코더 (browser recorder);
- 포그라운드 앱 (foreground app), 창 (window), 접근성 타겟 (Accessibility target), 마우스, 키보드, 선택 (selection) 및 스크린샷 (screenshots)을 위한 컴퓨터 레코더 (computer recorder);
surface필드가 포함된 하나의 통합된events.jsonl타임라인 (timeline);- 트레이스 (trace)를
routine.md또는SKILL.md로 변환하는 컴파일러 (compiler); - 단계별로 브라우저, 데스크톱, CLI, API 또는 커넥터 (connector)를 선택할 수 있는 런타임 (runtime);
- DOM, 접근성 상태 (Accessibility state), 스크린샷, 파일 출력 또는 API 결과를 확인하는 검증기 (verifier).
패턴은 다음과 같습니다:
Record -> Trace -> Compile -> Execute -> Verify -> Improve
그 외의 모든 것은 세부 사항일 뿐입니다.
안전은 선택 사항이 아닙니다
실제 워크플로를 기록하는 시스템은 민감한 정보를 보게 될 것입니다.
최소한의 규칙:
- 기록을 시작하기 전에 기록 범위를 시각화할 것;
- 언제든지 중지 및 취소를 허용할 것;
- 기본적으로 트레이스 (traces)를 로컬에 저장할 것;
- 비밀번호, 토큰 (tokens), 키 (keys), 결제 데이터 및 개인 식별 정보 (private identifiers)를 비식별화 (redact)할 것;
- 페이지 및 창의 텍스트를 신뢰할 수 없는 입력 (untrusted input)으로 취급할 것;
- 되돌릴 수 없는 작업, 결제, 권한 부여 또는 파괴적인 작업에 대해 확인을 요구할 것;
- 생성된 루틴 (routines)에 실제 자격 증명 (credentials)을 절대 기록하지 말 것.
프롬프트 인젝션 (Prompt injection) 또한 중요합니다. 기록된 페이지에는 모델에게 지시를 내리려는 텍스트가 포함되어 있을 수 있습니다. 컴파일러는 페이지 텍스트를 명령이 아닌 데이터로 취급해야 합니다.
핵심 요약
Codex Record & Replay는 워크플로 학습 시스템 (workflow-learning system)으로 이해하는 것이 가장 좋습니다:
실제 워크플로 관찰 (observe a real workflow)
-> 구조화된 증거 저장 (store structured evidence)
-> 증거를 기술(Skill)로 컴파일 (compile the evidence into a Skill)
...
실질적인 교훈은 명확합니다: 마우스 레코더를 만들지 마십시오. 트레이스 시스템 (trace system), 컴파일러, 시맨틱 런타임 (semantic runtime), 그리고 검증 루프 (verification loop)를 구축하십시오.
그것이 바로 Record & Replay를 일반적인 자동화와 의미 있게 다르게 만드는 요소입니다.
출처 및 관련 리소스
- OpenAI Codex Record & Replay 문서:
- OpenAI 커뮤니티 공지:
- Azuki 분석:
- OpenAI Codex GitHub 이슈:
- OpenBrowser:
- Interceptor:
- Record & Replay macOS 앱 기술 계획
- MD+HTML Reader 제품 페이지
- 로컬 증거: 번들로 포함된 Codex.app의
record-and-replay플러그인, 해당.mcp.json, 그리고 포함된 Skill
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기