스마트폰으로 Codex CLI 원격 제어하기｜DevRemote 개발기

퇴근하고 컴퓨터 앞에 다시 앉았는데, 꼭 자리를 비운 뒤에야 AI 코딩 에이전트의 작업 결과가 궁금해질 때가 있었다. 원격 데스크톱으로 작은 스마트폰 화면에서 개발 도구를 조작하는 방식은 몇 번 써보면 금방 피곤해진다. 내가 원한 건 화면 전체를 옮기는 것이 아니라 프로젝트를 고르고, 명령을 보내고, 진행 상황과 결과만 확인하는 도구였다.

그래서 만들기 시작한 프로젝트가 DevRemote다. 스마트폰에서 텍스트나 음성으로 작업을 보내면 Windows PC에 상주한 Agent가 지정된 프로젝트 폴더에서 Claude Code 또는 Codex CLI를 실행하고, 로그와 상태를 휴대폰으로 중계하는 구조다.

스마트폰 원격 개발을 원격 데스크톱과 다르게 잡은 이유

처음부터 가장 중요하게 정한 기준은 'VS Code를 휴대폰에 욱여넣지 않는다'는 것이었다. 스마트폰 화면에서 필요한 것은 코드 편집기 전체가 아니라 아래 다섯 가지였다.

- 작업할 프로젝트 선택
- AI에게 보낼 명령 입력
- 현재 상태와 최근 로그 확인
- 추가 질문 또는 승인 응답
- 잘못된 작업 즉시 중지

실제 코드 수정과 빌드, 테스트는 PC에서 돌아간다. 휴대폰은 지시와 관찰에 집중한다. 이 경계를 정하고 나니 모바일 화면도 단순해졌고 보안 범위도 설명하기 쉬워졌다.

Claude Code와 Codex CLI는 실행 방식이 달랐다

설계 문서만 작성했을 때는 두 CLI를 하나의 인터페이스로 감싸면 될 것처럼 보였다. 실제로 프로세스를 붙여보니 차이가 컸다.

Claude Code는 헤드리스 스트리밍 모드에서 하나의 프로세스를 유지하며 추가 입력을 stdin으로 보낼 수 있었다. 반면 Codex CLI는 한 턴이 끝나면 프로세스가 종료되고, 다음 입력은 저장된 스레드 ID로 resume해 새 프로세스를 실행하는 방식이었다.

겉으로는 똑같은 채팅처럼 보여도 내부 생명주기가 달랐다. 이 차이를 억지로 숨기지 않고 세션 모델을 두 가지로 나눴다.

- Interactive: 한 프로세스를 유지하며 여러 번 입력
- OneShotResumable: 턴마다 프로세스를 다시 실행하고 세션을 이어감

상태 머신은 공통으로 유지했다

도구마다 분기문을 늘리는 대신 상태는 같은 흐름으로 정규화했다.

Idle → Starting → Running → WaitingInput → Completed / Cancelled / Failed

Claude와 Codex의 출력 형식은 각 Parser가 해석하고, 세션 관리자는 정규화된 신호만 받는다. 덕분에 프로젝트당 한 세션 제한, 최근 로그 200줄, 취소, 종료 상태 보호 같은 기능은 두 도구가 그대로 공유한다.

실제 CLI로 확인한 것

Phase 1에서는 보기 좋은 모바일 화면보다 먼저 PC Agent가 CLI를 제대로 제어할 수 있는지 확인했다.

- 프로세스 시작 후 실시간 출력 수신
- 첫 작업이 끝난 뒤 추가 입력 전달
- 취소 시 자식 프로세스까지 종료
- 성공·실패·취소 상태가 뒤섞이지 않는지 확인
- Claude와 Codex 모두 두 번의 연속 입력 처리
- stdout과 stderr에 수신 시각·순번을 붙여 로그 재구성

테스트에서는 두 CLI 모두 Starting → Running → WaitingInput → Running → WaitingInput → Completed 흐름을 통과했다. 문서 속 아이디어가 아니라 실제 명령줄 도구를 대상으로 확인한 결과다.

개발하면서 가장 오래 걸린 건 화려한 기능이 아니었다

Windows에서 npm으로 설치된 CLI는 .cmd 형태인 경우가 있어 .NET Process가 그대로 실행하지 못했다. cmd.exe를 안전하게 거쳐 실행하도록 런처를 따로 만들었다.

또 프롬프트를 명령행 인자로 넘기면 따옴표와 특수문자 때문에 문제가 생겼다. 입력은 stdin으로 보내는 방식으로 바꾸니 셸 인용 문제가 줄었다. Codex는 stdin을 닫지 않으면 작업이 끝나도 대기하는 특성이 있어 첫 입력을 보낸 직후 EOF를 전달하도록 처리했다.

아직 만들지 않은 부분도 분명하다

현재 저장소에는 Windows Agent 골격과 CLI 제어 검증 코드가 있다. Relay Server, WebSocket 중계, 모바일 PWA 화면은 다음 단계다. 실제 도구 사용 승인 왕복과 세션 로그 영속화, Codex 작업 권한 정책도 아직 보완해야 한다.

그래서 지금 DevRemote를 완성된 서비스라고 소개할 단계는 아니다. 다만 가장 불확실했던 '서로 다른 AI CLI를 하나의 상태 모델로 제어할 수 있는가'는 실제 테스트로 확인했다.

다음 목표

다음 단계에서는 Agent와 중계 서버 사이의 연결을 붙이고, 휴대폰에서 프로젝트 선택과 로그 확인이 가능한 최소 화면을 만들 예정이다. 그때도 원격 데스크톱처럼 많은 기능을 넣기보다 명령, 상태, 승인, 중지라는 핵심 흐름부터 연결하려고 한다.

퇴근 후 만드는 프로젝트에서는 기능 하나를 더 넣는 것보다 가장 위험한 가정을 먼저 검증하는 편이 시간을 아껴줬다. DevRemote의 첫 검증 대상은 모바일 UI가 아니라 AI CLI의 실제 제어 가능성이었다.

※ 이 글은 E:\MY_FOLDER\AI_Remote_Controller 저장소의 README와 Phase 1 실제 테스트 보고서를 바탕으로 정리했다. 제품은 개발 중이며 공개 서비스 단계가 아니다.