Codex Desktop에 풀 리퀘스트 QA를 매시간 맡겼습니다

TMT

원문: I Made Codex Desktop QA My Pull Requests Every Hour (DongYun Kang, The AI Platform, 2026-08-20)

매시간 Codex Desktop이 풀 리퀘스트 하나를 빌드해 실제 앱에서 바뀐 흐름을 테스트하고, 증거를 붙인 리뷰를 남깁니다.

AI 덕분에 코드를 쓰는 속도는 훨씬 빨라졌습니다. 그렇다고 그 코드가 실제로 무슨 일을 하는지 확인할 시간이 늘어난 것은 아닙니다.

개발이 빨라지면서 풀 리퀘스트를 리뷰하는 일은 더 힘들어졌습니다. diff를 읽는 것은 일의 일부일 뿐입니다. UI가 바뀌었다면 여전히 실제 앱을 열어서 직접 눌러 보고 확인해야 합니다. 저는 코드가 올라오는 만큼 자주 이 확인 작업도 돌아가기를 바랐습니다.

그래서 Codex Desktop이 매시간 그 일을 하도록 설정했습니다. 풀 리퀘스트 하나를 고르고, QA 전용 체크아웃에서 빌드하고, 코드 변경 내용을 보고 무엇을 테스트할지 정하고, Computer Use로 개발용 앱을 직접 조작하고, 스크린샷을 찍고, GitHub에 실제 리뷰를 남깁니다.

이 루프 뒤에 별도의 QA 프레임워크나 오케스트레이션 서비스가 있는 것은 아닙니다. 작업을 예약하고 실행하는 것은 Codex Desktop입니다. GitHub API에 빠져 있는 기능을 메우려고 작은 스킬 하나를 만들었을 뿐, 리뷰어 자체는 프롬프트입니다.

매시간 돌아가는 프롬프트 하나

예약 작업은 데스크톱 앱에서 로컬 프로젝트를 대상으로 실행할 수 있습니다. 제 작업은 QA용으로 따로 잡아 둔 체크아웃에서 돌아가기 때문에, 로컬 변경을 전부 버리고 테스트할 풀 리퀘스트로 갈아치워도 됩니다.

프롬프트는 먼저 대상 목록을 좁히는 것으로 시작합니다.

풀 리퀘스트 하나를 고른다. 다음 조건을 만족해야 한다.

- 머지 충돌이 없다
- kdy1이 이미 승인한 상태가 아니다

여기에 다음 조건도 만족해야 한다.

- labor0-bot[bot]이 올렸고 kdy1에게 할당되어 있다.

이렇게 하면 작업에는 구체적인 PR 하나와 내려야 할 판단 하나가 남습니다. 테스트를 시작하기 전에는 최신 head를 체크아웃하고 저장소를 준비합니다.

풀 리퀘스트를 체크아웃하고, 체크아웃이 최신 상태인지 확인한다.

- 로컬 변경은 전부 버려도 된다.
- pnpm i 를 실행한다.
- 이미 떠 있는 개발 세션은 pnpm stop:dev 또는 pnpm tap stop 으로 종료한다.
- 첫 빌드 전에는 cargo clean 을 실행해 캐시 없이 빌드를 시작한다.
- 가능하면 pnpm tap dev --profile local 로 앱을 띄운다.

체크아웃은 언제든 버려도 되지만 앱 환경은 그렇지 않습니다. 같은 컴퓨터에서 The AI Platform 정식 버전이 이미 돌아가고 있을 수 있고, 작업은 그쪽을 절대 건드리면 안 됩니다. 그래서 프롬프트에 개발용 빌드를 분명히 지정해 두었습니다.

@Computer 를 사용해 수동 QA를 수행한다.

- The AI Platform 정식 버전은 절대 조작하지 않는다.
- 개발용 앱은 The AI Platform Dev 이다.
- 번들 식별자는 io.the-ai-platform.app.dev 이다.

테스트 계획은 diff가 정합니다

저는 클릭할 경로를 미리 정해서 주지 않습니다. PR의 코드 변경을 살펴보고, 그 변경에서 무엇을 직접 확인해야 하는지 스스로 도출하라고 시킵니다.

설정 폼을 바꾼 풀 리퀘스트는 그 폼을 통해 테스트해야 합니다. 화면 이동을 바꾼 풀 리퀘스트는 실제로 이동해 보며 테스트해야 합니다. 핵심은 그 PR이 바꿨다고 말하는 동작을 확인하는 것이지, 매시간 앱을 똑같이 한 바퀴 훑는 것이 아닙니다.

그다음 Codex는 Computer Use를 호출해 개발용 앱을 조작합니다. OpenAI의 Computer Use QA 가이드도 같은 기본 패턴을 설명합니다. 환경을 분명히 지정하고, 중요한 흐름을 실제로 실행해 보고, 다른 사람이 검토할 수 있는 증거를 남기는 것입니다.

스크린샷도 그 증거의 일부입니다. 요약만 믿어 달라고 하는 대신, Codex가 판단을 내린 순간에 무엇을 보고 있었는지 보여 줍니다.

GitHub 리뷰에는 스크린샷을 둘 자리가 필요합니다

GitHub에는 풀 리퀘스트 리뷰에 이미지 바이너리를 올리는 API 경로가 없습니다. 사람은 웹 화면에 이미지를 끌어다 놓을 수 있지만, API로 움직이는 리뷰어에게는 그에 해당하는 방법이 없습니다.

그래서 $upload-image 스킬을 만들었습니다. 워크플로가 골라낸 스크린샷마다 민감한 정보가 들어 있는지 검사하고, 그다음 스킬이 공개된 Cloudflare R2 증거 버킷에 올려 URL을 돌려줍니다. Codex는 그 이미지를 GitHub 리뷰 본문에 인라인으로 넣고 아래에 설명을 붙입니다.

이 스킬은 일부러 작게 만들었습니다. 무엇이 통과했고 무엇이 실패했는지, 어떤 흐름을 테스트할지는 스킬이 정하지 않습니다. GitHub 리뷰 API로는 올릴 수 없는 증거를 붙일 방법만 Codex에 제공합니다.

결과물은 리뷰입니다

프롬프트의 마지막 부분은 세 가지 결과를 정의합니다.

QA를 통과하면:

- 수동 QA 증거를 붙여 풀 리퀘스트를 승인(Approve)한다.

QA에 실패하면:

- 변경 요청(Request Changes)을 남긴다.
- 개발자가 PR을 직접 돌려 보지 않고도 문제를 고칠 수 있을 만큼
  증상과 원인을 자세히 적는다.

QA가 끝난 뒤에 풀 리퀘스트가 바뀌었으면:

- 같은 실행에서 다시 테스트하지 않는다.
- 결과는 승인이나 변경 요청이 아니라 일반 코멘트(Comment)로 남긴다.
- 작업은 성공으로 종료한다.

스크린샷은 $upload-image 로 올린다. 각 이미지는 인라인으로 넣고
설명은 그 아래에 붙인다.

head가 바뀐 경우를 따로 정해 둔 이유는, 리뷰가 Codex가 실제로 테스트한 커밋을 설명해야 하기 때문입니다. 테스트가 끝난 뒤 새 커밋이 올라오면 앞서 모은 증거는 여전히 쓸 만하지만, 한 번도 실행해 보지 않은 코드를 승인하거나 막을 수는 없습니다. 바뀐 head는 다음 시간대 작업이 확인하면 됩니다.

변경 요청이 늘 루프의 끝인 것도 아닙니다. PR을 올린 쪽이 Labor0였다면, Labor0가 Codex가 적어 둔 증상과 원인, 스크린샷을 가지고 같은 풀 리퀘스트를 고칩니다. 그러면 뒤이어 돌아가는 QA 작업이 확인할 새 커밋이 생깁니다.

까다로운 경우들도 프롬프트에 담아 두었습니다

지금 구성에는 따로 처리해 줘야 하는 경우가 몇 가지 있습니다.

The AI Platform의 정식 버전과 개발 버전이 동시에 돌아갈 수 있으니, 프롬프트에 개발용 앱 이름과 번들 식별자를 적어 둡니다. QA가 도는 중에 PR이 바뀔 수 있으니, 프롬프트는 일반 코멘트로 물러섭니다. GitHub는 리뷰 API로 스크린샷 업로드를 받지 못하니, 워크플로에 $upload-image가 필요합니다.

더 어려운 쪽은 동시 실행입니다. QA 세션은 한 번에 하나만 돌아야 합니다. 이미 다른 세션이 돌고 있으면, 나중에 시작된 작업은 실패하고 멈춰야 합니다. 같은 예약 작업이 여러 컴퓨터에서 실행될 수 있으면 문제가 더 복잡해집니다. 자기 컴퓨터의 다른 프로세스만이 아니라, 다른 곳에서 돌고 있는 세션까지 알아채야 하기 때문입니다.

이런 조율 문제와 증거 문제는 Labor0의 Chatty QA에 이미 관련 처리가 들어가 있습니다. Chatty QA는 아직 비공개 알파 단계라, 지금은 누구나 쓸 수 있는 Labor0 기능이 아닙니다. 이 작업은 Labor0 공개 로드맵에 있는 '증거로 뒷받침하는 QA' 방향의 일부입니다. 앞으로 이 장치들을 다듬어 Labor0 제품 전반에 넣을 계획입니다.