Codex Record & Replay 활용법: 반복 QA 작업을 재사용 가능한 스킬로 바꾸기

OpenAI Codex changelog에는 macOS용 Record & Replay 기능이 추가됐다는 내용이 있습니다. 설명은 간단합니다. 사용자가 한 번 시연한 workflow를 재사용 가능한 skill로 바꾸는 기능입니다. 초기 제공 지역과 Computer Use 활성화 조건 같은 제약은 있지만, 방향은 분명합니다. 코딩 agent가 프롬프트를 받아 코드를 쓰는 단계를 넘어, 사람이 반복하던 GUI 기반 작업까지 skill로 흡수하려는 흐름입니다.

개발팀에서 바로 떠올릴 수 있는 용도는 QA입니다. 매번 같은 웹 화면을 열고, 같은 계정으로 로그인하고, 같은 버튼을 누르고, 같은 결과를 확인하는 작업은 자동화 후보입니다. 다만 모든 QA를 E2E 테스트 코드로 바꾸기에는 비용이 큽니다. Record & Replay는 그 사이의 틈을 메울 수 있습니다.

어떤 작업을 스킬로 만들면 좋은가

좋은 후보는 반복 빈도가 높고, 절차가 명확하며, 실패했을 때 사람이 확인할 수 있는 작업입니다. 예를 들어 관리자 페이지에서 신규 유저를 생성하고 권한을 바꾸는 흐름, 결제 sandbox에서 플랜 변경을 확인하는 흐름, 디자인 변경 후 주요 화면을 돌아보는 smoke test가 있습니다.

반대로 판단 기준이 복잡하거나, 개인정보가 많이 노출되거나, 실패 시 외부 고객에게 영향을 주는 작업은 조심해야 합니다. Record & Replay는 마법이 아니라 시연 기반 자동화입니다. 입력 화면이 조금 바뀌거나, 네트워크가 느리거나, 권한 팝업이 뜨면 실패할 수 있습니다.

E2E 테스트와 Record & Replay의 차이

Playwright나 Cypress로 만든 E2E 테스트는 코드입니다. 버전 관리가 쉽고, CI에 넣기 좋고, assertion을 명확히 쓸 수 있습니다. 대신 작성 비용이 있습니다. selector가 바뀌면 고쳐야 하고, 비개발자가 직접 만들기 어렵습니다.

Record & Replay는 사람의 workflow를 skill로 바꾸는 접근입니다. 초기 자동화 비용이 낮고, “이렇게 하면 돼”를 보여주면 agent가 흐름을 재현할 수 있습니다. 대신 엄밀한 테스트라기보다 운영 보조 자동화에 가깝습니다. 따라서 둘을 경쟁 관계로 보면 안 됩니다.

추천 기준은 이렇습니다. 핵심 결제, 로그인, 권한 같은 회귀 테스트는 E2E 코드로 둡니다. 릴리즈 전 수동 확인, 관리자 반복 작업, 환경 세팅, 데모 준비는 Record & Replay 후보로 봅니다.

스킬화 전에 workflow를 정리해야 한다

나쁜 시연을 녹화하면 나쁜 자동화가 생깁니다. 시연 전에 절차를 문서로 정리해야 합니다. 각 단계마다 입력값, 기대 결과, 실패 시 중단 기준을 써둡니다.

예시는 다음과 같습니다.

1. staging 관리자 페이지 접속
2. 테스트 계정으로 로그인
3. 사용자 검색에서 qa-user@example.com 입력
4. 플랜을 Pro로 변경
5. 변경 후 billing badge가 Pro로 표시되는지 확인
6. 실패하면 screenshot과 현재 URL을 남기고 중단

이 정도로 정리된 workflow는 Record & Replay뿐 아니라 나중에 E2E 테스트로 옮기기도 쉽습니다.

민감 작업에는 승인 지점을 넣어야 한다

GUI 자동화는 편하지만 위험합니다. 특히 삭제, 결제, 이메일 발송, 권한 변경 같은 작업은 replay 중 실수하면 실제 데이터에 영향을 줄 수 있습니다. 따라서 skill 안에 승인 지점을 둬야 합니다.

예를 들어 “삭제 버튼을 누르기 직전 멈추고 사용자 승인을 받는다”, “production 환경이면 읽기 작업만 한다”, “결제 API 호출 전 sandbox 여부를 확인한다” 같은 규칙이 필요합니다. agent가 화면을 조작할 수 있다는 것은 권한이 생긴다는 뜻입니다. 권한에는 항상 경계가 필요합니다.

운영 로그를 남기는 방식

Record & Replay 기반 skill도 실행 로그가 필요합니다. 최소한 언제, 누가, 어떤 host에서, 어떤 skill을 실행했고, 어떤 단계에서 실패했는지 남겨야 합니다. screenshot이나 browser trace를 남길 수 있다면 디버깅이 쉬워집니다.

로그가 없으면 실패 원인을 사람이 기억에 의존해 찾게 됩니다. 자동화의 목적이 반복 작업을 줄이는 것인데, 실패 분석에 더 많은 시간이 들면 본말이 전도됩니다.

팀에 도입하는 순서

처음부터 모든 QA를 자동화하려고 하면 실패합니다. 가장 지루하고 위험도가 낮은 작업 하나를 고르는 편이 낫습니다. 예를 들어 staging smoke test 10분짜리 흐름을 2분으로 줄이는 목표를 잡습니다. 성공하면 다음 후보를 늘립니다.

도입 순서는 다음이 현실적입니다.

1. 반복 수동 작업 목록 작성
2. 빈도와 위험도 기준으로 후보 3개 선정
3. 가장 낮은 위험도의 workflow를 문서화
4. Record & Replay로 skill 생성
5. 1주일 동안 사람 검수와 함께 실행
6. 실패 패턴을 반영해 절차 수정
7. 안정화 후 팀 공용 skill로 등록

실행 체크리스트

• 반복 빈도가 높은 QA 또는 운영 작업인가?
• 실패해도 고객 데이터에 직접 영향을 주지 않는가?
• workflow 단계, 입력값, 기대 결과가 문서화되어 있는가?
• 삭제, 결제, 이메일, 권한 변경 전에 승인 지점이 있는가?
• production과 staging을 명확히 구분하는가?
• 실행 로그, screenshot, 실패 단계가 남는가?
• 핵심 회귀 테스트는 여전히 E2E 코드로 관리하는가?

실패했을 때 남겨야 할 정보

스킬 실행이 실패하면 “안 됨”으로 끝내지 말고, 마지막으로 본 화면, 실패 단계, 입력값, 예상 결과를 남겨야 합니다. 이 네 가지가 있어야 다음 실행을 고칠 수 있습니다. 실패 로그가 쌓이면 어떤 단계가 자동화에 취약한지도 보입니다.

Codex Record & Replay의 실무 가치는 “사람처럼 클릭하는 AI”가 아닙니다. 팀 안에 흩어진 반복 절차를 skill이라는 형태로 남기고, 점진적으로 자동화 자산으로 바꾸는 데 있습니다. 작은 QA 작업 하나부터 시작하면, agent 도입이 추상적인 실험이 아니라 매주 시간을 아끼는 운영 개선으로 바뀝니다.