Codex /goal and OpenGUI: 장기 실행 작업은 상태가 필요합니다

Source: Dev.to

Long‑running agents tend to fail in the second half

첫 번째 단계는 대체로 괜찮다 – CI 실패를 고치고, 앱을 열고, 버튼을 누르고, 키워드를 검색한다. 모델은 합리적인 첫 번째 행동을 만들어낼 수 있다. 문제가 시작되는 것은 약 10단계쯤부터이다: 이미 일어난 일, 작업이 어디에서 멈췄는지, 원래 경계가 무엇이었는지, 그리고 작업이 언제 멈춰야 하는지. 이러한 세부 사항들이 맥락에서 벗어나 버린다.

Codex CLI 0.128.0은 **/goal**을 추가했다. 릴리스 노트는 지속된 목표 워크플로우를 설명한다: 앱‑서버 API, 모델 도구, 런타임 연속성, 그리고 create, pause, resume, clear를 위한 TUI 제어 기능이다. Simon Willison은 이를 OpenAI 버전의 Ralph 루프와 비교했다: Codex에 목표를 설정하고, 목표가 달성되거나 예산이 소진될 때까지 계속 실행·점검·수정하도록 한다.

장기 실행 작업의 맥락에서 이 변화는 목표가 어디에 존재하는가에 관한 것이다. 목표가 단일 프롬프트의 텍스트에서 재개·일시정지·삭제·재참조가 가능한 상태로 옮겨진다.

코딩 에이전트가 목표가 필요한 이유

CI 실패를 예로 들어 보자. 즉각적인 실패는 하나의 깨진 테스트일 수 있다. 에이전트는 테스트를 수정하고, 구현을 바꾸고, 코드가 어색해 보이므로 타입을 조정한다. 각 단계는 정당화될 수 있지만, 최종 diff는 원래 문제보다 훨씬 커진다.

코드 생성 자체가 여기서 어려운 부분은 아니다. 실행에는 안정적인 제약 조건이 붙어 있지 않다. 원래 목표는 다음과 같이 아주 작을 수 있다:

/goal 修复当前 failing tests，保持 diff 尽量小，最后跑完 npm test

또는:

/goal 处理这个 PR 的 review comments，不改无关文件，最后给出改动摘要

이러한 목표는 목표(target), 경계(boundary), 그리고 **수용 조건(acceptance condition)**을 포함한다. 이는 에이전트에게 어디로 가야 하는지, 무엇을 건드리지 말아야 하는지, 언제 멈춰야 하는지를 알려준다.

그러한 상태가 없으면 에이전트는 현재 오류에 쉽게 휘둘린다. 타입이 어색해 보이면 타입을 바꾸고, 테스트 작성이 어렵다면 테스트를 바꾸고, 구조가 지저분해 보이면 리팩터링한다. 각 로컬 움직임은 의미가 있을 수 있지만, 전체 작업은 점점 흐려진다.

휴대폰에서 어려운 부분은 화면 상태

OpenGUI는 실제 Android 휴대폰을 작동시키는 장기 실행 작업을 수행합니다.

Repository:

코드베이스에서는 상태가 파일, 테스트, diff 등에 남을 수 있습니다. 휴대폰에서는 상태가 실시간 화면입니다.

예를 들어, 휴대폰에 다음을 요청합니다:

1. X를 엽니다.
2. 모바일 AI 에이전트에 관한 토론을 검색합니다.
3. 주요 포인트를 수집합니다.
4. 사람들이 관심을 갖는 내용을 요약합니다.

문장으로는 간단해 보이지만, 휴대폰에서는 일련의 상태 확인으로 바뀝니다:

• 앱이 열려 있나요?
• 현재 홈 화면인가요?
• 검색창에 포커스가 맞춰져 있나요?
• 결과 로딩이 끝났나요?
• 로그인 프롬프트, 권한 요청, 혹은 팔로우‑추천이 나타났나요?

스크린샷 → 탭 → 스크린샷 루프는 짧은 작업만 수행할 수 있습니다. 화면이 변하지 않으면 시스템은 탭이 빗났는지, 네트워크가 느린지, 페이지가 로딩 중인지, 혹은 동작에 시각적 피드백이 없는지를 판단해야 합니다. 페이지가 다른 곳으로 이동하면 뒤로 가야 할지, 재시도할지, 아니면 새로운 페이지에서 계속 진행할지를 결정해야 합니다.

따라서 모바일 목표는 몇 가지 구체적인 질문에 답해야 합니다:

• 작업이 현재 어느 단계에 있나요?
• 현재 화면이 다음 단계를 지원하나요?
• 실패 후 어디에서 복구해야 하나요?
• 언제 실행을 종료할 수 있나요?

OpenGUI가 목표를 상태 흐름으로 전환

OpenGUI를 실행하고 소스를 살펴보았습니다. 이 시스템은 전화 자동화를 단순 스크립트로 남겨두는 대신 백엔드 그래프, 디바이스 연결, Android 측 액션 실행을 연결합니다.

• Backend entry point: server/apps/backend/src/modules/graph-agent/graph/mobile-agent.graph.ts
• Plan Supervisor: 복잡한 계획을 실행 가능한 하위 작업으로 나눕니다.
• Executor subgraph: executor.graph.ts가 디바이스에서 액션을 실행합니다.
• Result handling: Supervisor가 실행 결과를 받아 계속 진행, 재시도, 재계획 또는 Summarizer에 전달할지를 결정합니다.

Android에서는 실제 디바이스에 액션이 적용됩니다:

• client/core_accessibility/.../GestureService.kt가 탭, 입력 등 GUI 액션을 실행합니다.
• 디바이스는 백엔드와 WebSocket 연결을 유지하며, client/core_network/.../StandbySocketManager.kt가 대기 연결을 관리합니다.
• Feishu/Lark, Telegram, REST API가 원격 작업 진입점으로 작동하여, 휴대폰을 로컬 데모 디바이스에서 작업을 받을 수 있는 워커로 전환합니다.

OpenGUI는 목표를 여러 상태 조각으로 퍼뜨립니다:

각 디바이스 액션 후에 백엔드는 최신 디바이스 상태를 받아 다음 동작을 결정합니다. 단순 스크립트는 페이지가 예상 순서를 따를 것이라고 가정하지만, OpenGUI는 페이지가 변할 수 있다고 가정하므로 Executor가 실제 상태를 지속적으로 백엔드에 보고해야 합니다.

비용

목표를 그래프로 구현하면 시스템이 무거워집니다.

• 작업 상태 유지.
• WebSocket 연결을 유지.
• 장치 대기 상태 처리.
• 실행 결과와 스크린샷을 다시 전송.
• continue, retry, cancel, summarize에 대한 상태 전환 설계.
• 모델 호출 및 스크린샷 분석도 비용이 듭니다.

작업이 오래 실행될수록 그 비용은 작은 세부 사항이 아니라 엔지니어링적인 고민이 됩니다.

하지만 모바일에서는 이 비용을 피하기 어렵습니다. 실제 앱은 팝업을 표시하고, 로딩 화면에서 멈추며, 탭을 잘못 인식하고, 사용자를 완전히 다른 페이지로 보냅니다. 프롬프트 루프만으로도 금방 스크린샷 기반 while true가 됩니다.

OpenGUI는 그 복잡성을 시스템에 넣습니다. 잘못된 탭은 감독자가 소비할 실행 결과가 됩니다. 장치는 계속 상태를 보고합니다. 클릭되는 화면이라기보다 작업자처럼 동작합니다. 설계가 무거워지지만, 장기 실행 작업을 디버깅, 복구, 검토할 수 있는 장소를 제공합니다.

잠재적인 첫 번째 사용 사례

• 커뮤니티 연구 (예: 모바일 포럼에서 의견 수집)
• 모바일 흐름 테스트 (자동 UI 회귀)
• 휴대폰 운영 작업 (예: 대량 설정 변경)
• 앱 수준 시연 또는 튜토리얼

개요

웹 자동화로 도달할 수 없는 워크플로만 전용 실행 시스템이 필요합니다. 이러한 작업은 가장 강력한 모델이 필요하지 않을 수 있지만 다음을 수행할 수 있어야 합니다:

• 목표를 지속적으로 추적하기
• 실패를 즉시 감지하기
• 상태 업데이트를 컨트롤러에 다시 전송하기

코딩 에이전트에서는 Codex가 /goal 엔드포인트를 사용해 목표를 복구 가능한 상태로 저장합니다. 모바일 기기에서는 OpenGUI가 작업 진행, 기기 피드백, 실패 처리를 하나의 일관된 상태 흐름으로 연결합니다. 따라서 장기 실행 에이전트는 다음이 필요합니다:

1. 다음 단계뿐 아니라 전체 실행을 추적하기
2. 중단 사이에도 지속적인 상태 유지하기
3. 오류에 대응하고 계획을 적절히 조정하기

참고 문헌

• OpenAI Codex 0.128.0 release
• Simon Willison – “Codex Goals” (30 Apr 2026)
• OpenGUI (Core‑Mate)