Codex Record & Replay는 제가 매우 흥미롭다고 생각하는 제품 아이디어를 가리킵니다. 때때로 사용자들은 워크플로 (workflow)를 처음부터 설명하고 싶어 하지 않습니다. 그들은 이미 작업을 어떻게 수행하는지 알고 있습니다. 그저 한 번 보여주고 그 시연을 재사용 가능한 무언가로 바꾸고 싶을 뿐입니다.

이는 강력한 아이디어입니다. 하지만 독립적인 제품은 단순한 브라우저 녹화기나 마우스 좌표 매크로 (macro)가 되어서는 안 됩니다. 사람들이 이를 설치하고, 신뢰하며, 반복적으로 사용하게 하려면, 실제 브라우저와 실제 데스크톱을 기록해야 하며, 민감한 데이터를 보호해야 하고, 픽셀을 맹목적으로 재생하는 대신 워크플로 (workflow)의 의도를 재생해야 합니다.

제가 만들고자 하는 제품은 로컬 우선 (local-first) Mac 앱입니다:

브라우저 + 데스크톱 워크플로 (workflow) 기록
-> 캡처된 내용 검토
-> 편집 가능한 루틴 (routine)으로 컴파일
...

Codex 대비 장점은 "더 나은 범용 에이전트 (general agent)"가 아닙니다. 장점은 제품 소유권 (product ownership)에 있습니다: 로컬 저장소, 사용자 모델 가져오기 (bring-your-own-model) 설정, 루틴 (routine) 라이브러리, 실행 기록, 스케줄링, 로그, 그리고 내보낼 수 있는 워크플로 (workflow) 파일입니다.

핵심 제품 베팅 (core product bet)

유용한 Record & Replay 앱은 한 번의 시연을 다시 실행할 수 있는 루틴 (routine)으로 전환해야 합니다.

시연
-> 증거 캡처
-> 루틴 (routine) 컴파일
...

중요한 단어는 "컴파일 (compile)"입니다. 가공되지 않은 이벤트 (raw events)는 증거일 뿐입니다. 그것들은 최종적인 자동화 (automation)가 아닙니다.

사용자가 버튼을 클릭한다면, 제품은 단지 x=1040, y=72만을 기억해서는 안 됩니다. 해당 앱, 창, 접근 가능한 대상, 주변 텍스트, 브라우저 DOM, 필요한 경우 스크린샷, 그리고 그 단계가 왜 중요했는지에 대한 이유를 기억해야 합니다.

그것이 유용한 워크플로 (workflow) 시스템과 취약한 매크로 (macro) 녹화기의 차이점입니다.

첫 번째 버전은 브라우저와 데스크톱을 모두 다뤄야 합니다

브라우저 전용 자동화 (automation)도 유용하지만, 이 제품에는 그것만으로는 충분하지 않습니다.

실제 워크플로 (workflow)는 종종 경계를 넘나듭니다:

• Chrome에서 페이지 열기;
• 파일 다운로드;
• Finder에서 파일 찾기;
• 다른 곳에 업로드;
• Notes 또는 Slack에서 값 복사;
• macOS 대화 상자 확인;
• 브라우저로 돌아가서 제출.

제품이 브라우저만 볼 수 있다면, Record & Replay를 차별화하는 핵심 요소를 놓치게 됩니다.

따라서 첫 번째 신뢰할 수 있는 버전은 두 가지 인터페이스(surface)가 필요합니다:

flowchart LR
  User["사용자가 워크플로우 시연"]
  --> App["Mac 앱"]
  App --> Browser["브라우저 인터페이스\n확장 프로그램 + 네이티브 메시징"]
...

브라우저 인터페이스(browser surface)는 URL, 제목(title), DOM 대상(target), ARIA 역할/이름(role/name), 셀렉터 후보(selector candidates), 입력 변경 사항(input changes), 탐색(navigation) 및 주요 스크린샷을 캡처해야 합니다.

데스크톱 인터페이스(desktop surface)는 포그라운드 앱(foreground app), 창 제목(window title), 접근성 역할/이름/값(Accessibility role/name/value), 포커스(focus), 선택(selection), 입력 이벤트(input events) 및 스크린샷을 캡처해야 합니다.

두 인터페이스 모두 하나의 타임라인(timeline)에 기록해야 합니다. 루틴 컴파일러(routine compiler)는 워크플로우를 두 개의 단절된 로그가 아닌 하나의 이야기로 인식해야 합니다.

트레이스(Trace)는 증거이지, 제품이 아닙니다

트레이스 형식은 지루할 정도로 명확해야 합니다.

각 이벤트는 다음 사항을 명시해야 합니다:

• 어떤 인터페이스(surface)에서 발생했는지;
• 어떤 앱과 창이 활성화되어 있었는지;
• 사용자가 무엇을 했는지;
• 어떤 대상(target)이 연관되었는지;
• 어떤 컨텍스트(context)가 캡처되었는지;
• 어떤 필드가 비식별화(redacted)되었는지;
• 어떤 스크린샷, DOM 또는 접근성 스냅샷(Accessibility snapshot)이 해당 이벤트를 뒷받침하는지.

단순한 이벤트는 다음과 같은 형태일 수 있습니다:

{
  "eventId": "evt_001",
  "surface": "browser",
...

제품은 모든 것을 영구적으로 일반 텍스트로 저장해서는 안 됩니다. 원시 콘텐츠(raw content), 요약(summaries), 스크린샷 및 모델 결합 컨텍스트(model-bound context)는 분리되어야 합니다. 데이터가 기기를 떠나기 전에 사용자는 이를 확인할 수 있어야 합니다.

컴파일러가 진짜 제품입니다

컴파일러는 노이즈가 섞인 증거를 편집 가능한 루틴(routine)으로 변환합니다.

flowchart TD
  Raw["원시 이벤트(Raw events)"] --> Clean["노이즈 제거(Clean noise)"]
  Clean --> Segment["단계 세분화(Segment steps)"]
...

훌륭한 컴파일(compilation)이란 다음을 의미합니다:

• 타이핑을 하나의 입력 단계(input step)로 병합;
• 실수로 인한 클릭 및 유휴 시간(idle time) 제거;
• 실행 간에 어떤 값이 변경되는지 감지;
• 좌표(coordinates)보다 의미론적 대상(semantic targets)을 우선시;
• 중요한 단계에 대한 검증(verification) 작성;
• 위험 요소 및 민감한 필드 표시;
• 의도가 불분명할 때만 사용자에게 질문.

좋은 루틴은 다음과 같이 읽혀야 합니다:

리포트 페이지를 엽니다.
날짜 범위를 선택합니다.
선택한 파일을 업로드합니다.
...

이렇게 하지 마세요:

마우스를 1040,72로 이동.
클릭.
500ms 대기.
...

Replay에는 검증 루프 (verification loop)가 필요합니다

Replay는 단순히 한 줄씩 맹목적으로 실행되는 스크립트가 아니라, 상태 머신 (state machine)이어야 합니다.

stateDiagram-v2
  [*] --> LoadRoutine
  LoadRoutine --> CollectInputs
...

런타임 (runtime)은 다음 순서로 도구들을 시도해야 합니다:

1. 가장 안정적인 시맨틱 경로 (semantic path)를 우선 사용: API, MCP, Apple Events, 브라우저 DOM 액션, 또는 Accessibility 액션.
2. 그 다음 구조 (structure)를 사용: 셀렉터 (selector), ARIA 레이블 (label), 가시적 텍스트, Accessibility 역할 (role), 또는 윈도우 계층 구조.
3. 구조가 불완전할 경우 시각적 매칭 (visual matching)을 사용.
4. 좌표 (coordinates)는 알려진 윈도우 및 스크린샷과 결합된 최후의 수단으로만 사용.

위험한 작업에는 명시적인 확인이 필요합니다. 데이터 삭제, 결제 제출, 비밀번호 변경, 개인 파일 업로드, 소프트웨어 설치, 또는 민감한 정보 전송은 사용자 확인 없이 실행되어서는 안 됩니다.

BYOK는 실질적인 존재 이유입니다

BYOK (Bring-your-own-model, 모델 직접 가져오기) 지원은 단순한 설정 기능이 아닙니다. 이는 제품의 경쟁 우위입니다.

이를 통해 사용자는 비용, 개인정보 보호, 그리고 모델 품질을 직접 선택할 수 있습니다. 앱은 최소한 다음을 지원해야 합니다:

• OpenAI 호환 베이스 URL (base URL) + API 키 + 모델;
• Anthropic;
• Gemini;
• OpenRouter;
• Ollama 또는 호환 가능한 서버를 통한 로컬 모델.

키 (Keys)는 Keychain에 저장되어야 합니다. 설정 화면에는 연결 테스트, 모델 기능 힌트, 컨텍스트 미리보기, 그리고 대략적인 비용 추정치가 포함되어야 합니다.

저렴한 모델은 텍스트를 정제하고 트레이스 (traces)를 요약할 수 있습니다. 더 강력한 멀티모달 (multimodal) 모델은 모호한 화면이나 시각적 복구 (visual recovery)를 처리할 수 있습니다.

배포도 계획의 일부입니다

이러한 종류의 앱은 Mac App Store 외부에서 시작해야 합니다.

Accessibility, 화면 기록 (Screen Recording), 입력 모니터링 (Input Monitoring), 경우에 따라 Apple Events, 헬퍼 프로세스 (helper processes), 그리고 브라우저 확장 프로그램 설정이 필요합니다. Developer ID 서명 및 공증 (notarization)이 더 현실적인 첫 번째 경로입니다.

사용자 경험 (UX) 또한 권한(permissions)에 대해 명확하게 설명해야 합니다. 워크플로 레코더 (workflow recorder)는 매우 많은 것을 관찰합니다. 만약 앱이 무엇을 기록하는지, 데이터를 어디에 저장하는지, 그리고 모델로 무엇을 전송하는지를 설명하지 못한다면 신뢰를 얻을 수 없을 것입니다.

현실적인 v1

첫 번째 판매 가능한 버전은 범위는 좁지만, 기능은 완전해야 합니다.

다음 사항들을 지원해야 합니다:

• Chrome 또는 Brave 워크플로 기록 (workflow recording);
• macOS 앱/윈도우 트래킹 및 접근성 (Accessibility) 타겟;
• 하나의 로컬 트레이스 타임라인 (local trace timeline);
• 삭제 및 비식별화 (redaction) 기능이 포함된 트레이스 검토 화면;
• routine.md 및 workflow.json으로의 루틴 컴파일 (routine compilation);
• 검증 기능이 포함된 브라우저 + 데스크톱 재생 (replay);
• 앱이 불확실할 때의 인간 개입 (human takeover);
• 로컬 우선 저장 (local-first storage) 및 컨텍스트 미리보기;
• 서명 및 공증 (notarized)된 배포.

초기에 다루기 좋은 워크플로는 의도적으로 지루한 것들입니다: 백오피스 브라우저 양식, 브라우저 + Finder 업로드/다운로드 흐름, 그리고 Finder, Notes, Mail, Calendar 또는 Slack에서의 간단한 네이티브 앱 단계들입니다.

v1에서는 금융, 결제, 정부, 의료, 게임, 복잡한 디자인 도구, 그리고 완전히 무인으로 진행되는 민감한 작업은 피할 것입니다.

나의 최종 의견

포지셔닝이 정직하다면, 이것은 실행 가능한 제품 방향입니다.

이것은 “모든 앱을 자동화한다”가 아닙니다.

이것은 “픽셀을 기록하고 재생한다”가 아닙니다.

이것은 “더 나은 UI를 가진 브라우저 자동화”도 아닙니다.

더 강력한 약속은 다음과 같습니다:

브라우저 + Mac 워크플로를 한 번 기록하여, 편집 가능한 AI 루틴으로 변환하고, 당신만의 모델로 재생하세요.

이것은 제품이 Codex 옆에 존재해야 할 명확한 이유를 제공합니다: 로컬 우선 제어, 모델 선택권, 휴대 가능한 루틴, 그리고 반복적인 실제 환경 실행을 위해 구축된 UI입니다.

출처 및 관련 리소스

• OpenAI Codex Record & Replay:
• OpenAI Codex Computer Use:
• Captr for macOS:
• OpenBrowser:
• Interceptor:
• workflow-use:
• Apple notarization:
• Apple ScreenCaptureKit:
• Apple AXUIElement:
• Codex Record & Replay principles
• MD+HTML Reader product page