# 같은 해결책이 안 통할 때, 코덱스에게 도구를 연결해보세요

> 출처: https://retn.kr/blog/codex-tools-hypothesis-debugging/ · 수정 2026-11-03 · 리텐션 주식회사

같은 해결책이 안 통할 때 코덱스에 터미널과 모바일 제어 도구를 연결하면, AI가 화면과 로그를 직접 확인하며 여러 가설을 시험할 수 있습니다. Codex 원격제어 페어링 오류를 해결한 과정과 가설별 확인 결과, 실제 요청문을 정리했습니다.

Codex 원격제어가 되면 ChatGPT 휴대폰 앱에 Mac mini가 나타나고, 그 컴퓨터의 Codex 작업 목록을 휴대폰에서 열 수 있습니다. 저는 휴대폰을 연결하는 페어링 단계에서 막혔습니다. QR 코드를 다시 만들어도, 휴대폰으로 다시 스캔해도 같은 오류가 나왔습니다. 그래서 QR을 계속 다시 스캔하는 대신 **코덱스가 화면과 로그를 직접 확인할 수 있도록 도구를 연결하고, 여러 가설을 세워 시험하게 했습니다.**

2026년 10월 5~6일에 Mac mini의 터미널, 안드로이드 기기 제어 도구 [ARTEMIS](https://github.com/google/artemis), 휴대폰 진단 명령, 서버 상태 조회를 함께 사용했습니다. 컴퓨터 쪽 원인을 찾았고, 휴대폰에서도 여러 조치를 거친 뒤 연결에 성공했습니다. 그 과정에서 AI가 잘못 추정한 부분도 있었습니다. 이 경험을 통해 어떤 도구를 연결해야 하는지, 무엇을 맡기고 무엇을 확인해야 하는지 정리해봤습니다.

## TLDR

- 같은 해결책이 실패하면, 다음 시도에서 새로운 정보를 얻을 수 있는지 확인합니다.
- 코덱스에 로그 조회와 실제 기기 제어 도구를 연결하면, 사람이 오류를 옮겨 적는 과정부터 줄일 수 있습니다.
- “알아서 고쳐줘”에 가설, 검증 방법, 실행 범위, 완료 기준을 함께 명시합니다.
- AI의 추정과 실제 관찰을 구분합니다. 이번에도 컴퓨터의 원인은 확인했지만 휴대폰을 해결한 단일 원인은 확정하지 못했습니다.

## Codex 원격제어가 하는 일과 페어링 실패 오류

Codex 원격제어는 컴퓨터에서 쓰던 Codex 작업을 휴대폰에서 이어가게 해주는 기능입니다. Mac의 데스크톱 앱에서 원격 연결을 켜고, 앱이 보여주는 QR 코드를 휴대폰으로 스캔하면 두 기기가 연결됩니다. 원격 연결을 켜는 토글은 [OpenAI 공식 안내(Remote connections)](https://learn.chatgpt.com/docs/remote-connections) 기준으로 데스크톱 앱 Settings > Connections > Control this Mac or PC 화면의 “Allow connections”입니다. 연결되면 휴대폰에 Mac mini가 표시되고, 그 컴퓨터의 작업 목록을 열어 기존 작업을 이어가거나 새 작업을 시작할 수 있습니다.

제 경우에는 처음에 Mac mini에서 이 원격제어 토글이 켜지지 않았습니다. 컴퓨터 쪽 문제가 해결된 다음에는 휴대폰이 연결되지 않았습니다. 휴대폰에는 “페어링 실패”라는 제목과 “페어링 중 문제가 생겼습니다. 코드를 다시 스캔하세요.”라는 안내가 반복됐습니다.

![삼성 휴대폰의 ChatGPT 앱에서 캡처한 페어링 실패 화면](/_emdash/api/media/file/01M5SPRD4FGNXXSZFG8DHPR2CB.jpg)

오류 메시지에 맞춰 코드를 다시 만들고 스캔했습니다. 하지만 결과가 같았습니다. 새 코드를 만드는 과정에서 원인을 설명할 정보가 더 생기는 것도 아니었습니다.

AI에게 물어봐도 제가 직접 화면을 확인하고, 오류를 복사하고, 앱 버전을 찾고, 다시 결과를 전달해야 한다면 확인 작업은 계속 제 몫입니다. 이때는 AI가 직접 확인할 수 있는 범위를 넓혀볼 수 있습니다.

## AI 에이전트에 필요한 도구는 문제에 따라 달라집니다

어떤 도구를 연결하느냐에 따라 AI가 찾을 수 있는 단서가 달라집니다. 이번에는 터미널만으로는 휴대폰에서 어느 인증 화면이 열리는지 알기 어려웠습니다. 화면만으로는 컴퓨터 뒤에서 어떤 서버가 연결을 점유하고 있는지 알기 어려웠습니다.

이번에 연결하거나 사용한 도구는 다음과 같습니다. 터미널에서 직접 실행한 명령과 ARTEMIS처럼 MCP를 통해 사용한 기기 제어 도구를 함께 활용했습니다.

- ARTEMIS는 구글이 2026년 8월 GitHub에 공개한 오픈소스 안드로이드 자동화 도구입니다. 말로 지시하면 AI가 휴대폰 화면을 읽고 사람처럼 버튼을 누릅니다. MCP 서버로 연결하면 Codex나 Claude Code가 휴대폰을 직접 조작합니다.
- [ADB(Android Debug Bridge)](https://developer.android.com/tools/adb)는 컴퓨터에서 USB로 안드로이드 기기에 명령을 보내는 구글의 공식 개발 도구입니다.

| 도구 | 코덱스가 직접 확인하거나 실행한 일 |
| --- | --- |
| Mac 터미널과 로그 조회 | 실행 중인 서버, 버전, 오류 로그, 연결 상태를 비교했습니다. |
| ARTEMIS 모바일 제어 | 휴대폰 화면을 읽고, 앱의 버튼을 누르고, 업데이트와 로그아웃 화면을 찾아갔습니다. |
| ADB 안드로이드 진단 명령 | USB 연결 상태, 운영체제와 앱 버전, 기기 진단 정보를 확인했습니다. |
| 서버 상태 조회 API | 휴대폰이 등록 대기인지 등록 완료인지, 대상 Mac mini에 추가됐는지 확인했습니다. |
| 공식 문서 확인 | 자동화로 시험한 경로와 공식 모바일 설정 경로가 같은지 대조했습니다. |

MCP는 AI가 외부 시스템의 도구를 사용할 수 있도록 연결하는 방식입니다. 연결할 도구를 고민하고 있다면 기존 글인 [MCP 서버와 AI 에이전트 운영법](/blog/ai-agent-compound-setup-part3/)을 함께 참고할 수 있습니다.

OpenAI도 에이전트를 다음과 같이 정의합니다.

> “Agents are systems that independently accomplish tasks on your behalf.”

출처: [A practical guide to building agents, OpenAI](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf)

이 가이드에서는 모델, 도구, 지침을 에이전트의 기본 구성으로 설명합니다. 이번 사례에서도 코덱스가 사용할 수 있는 도구와 확인해야 할 목표를 함께 정해주는 것이 필요했습니다.

## 도구를 연결하니 여러 가설을 확인할 수 있었습니다

여러 가설을 시험할 때 중요한 것은 시도한 방법의 개수보다 각 시도 뒤에 남은 정보입니다. 실패한 시도도 다음 가설을 정하는 단서가 됩니다.

컴퓨터에서는 오래된 서버가 원격 연결을 점유하고 있다는 가설을 확인했습니다. 앱 창은 하나였지만, 9월 21일부터 실행되던 별도의 구버전 서버가 남아 있었습니다. 현재 앱의 서버는 연결을 시도할 때마다 `Remote app server already online`이라는 409 오류를 받았습니다.

구버전 서버의 원격 연결을 비활성화하자 현재 앱의 상태가 `Connected`로 바뀌었습니다. 여기서는 관찰한 오류, 실행한 조치, 바뀐 상태가 연결됐습니다. 컴퓨터 쪽에서는 원인을 확인한 셈입니다.

휴대폰에서는 확인할 대상이 더 많았습니다. 같은 오류 화면 뒤에 무엇이 있는지 다음과 같이 조사했습니다.

| 가설 | 확인하거나 시도한 일 | 결과와 판단 |
| --- | --- | --- |
| 휴대폰 앱이 오래됐을 수 있습니다. | 앱을 1.2026.265에서 1.2026.272로 업데이트했습니다. | 직후에도 실패했습니다. 업데이트만으로 해결됐다고 볼 수 없습니다. |
| 로그인이나 원격제어 권한 승인에 문제가 있을 수 있습니다. | 계정과 워크스페이스를 비교하고, 재로그인과 추가 인증을 진행했습니다. | 추가 인증 창을 확인했지만, 중간 재시험에서는 계속 실패했습니다. |
| 네트워크에 따라 결과가 달라질 수 있습니다. | Wi-Fi와 모바일 데이터에서 각각 확인했습니다. | 시험한 두 환경에서는 같은 오류가 났습니다. |
| 휴대폰의 기기 인증 상태가 원인일 수 있습니다. | 구글 플레이 프로텍트(기기 보안 검사) 인증 화면을 확인했고, 코덱스가 기기 키 발급을 요청하는 진단 명령도 실행했습니다. | 기기는 인증된 상태였습니다. 이것만으로 앱의 등록 과정 전체가 정상이라고 볼 수는 없습니다. 키 요청은 화면을 읽기만 하는 확인이 아니었고, 그 영향은 분리해 확인하지 못했습니다. |
| Android 17에서 연결되지 않을 수 있습니다. | 다른 기기의 등록 상태와 해당 휴대폰의 결과를 비교했습니다. | 같은 Android 17 휴대폰이 최종 등록됐으므로 미지원이라는 추정은 철회했습니다. |
| 자동화로 시험한 경로가 실제 QR 연결과 다를 수 있습니다. | 코드 발급과 링크 실행 경로를 비교하고, 실제 데스크톱 QR을 다시 스캔했습니다. | 실제 QR 스캔에서 성공했습니다. 다만 앞선 조치들의 영향과 분리해 검증하지는 못했습니다. |

앱 업데이트 직후에도 실패했다는 결과는 다음 가설을 정하는 단서였습니다. 네트워크를 바꿔도 같았다는 결과 역시 확인한 범위 안에서 가설을 좁히는 데 도움이 됐습니다.

![Google Play 스토어에서 캡처한 Play 프로텍트 인증 화면](/_emdash/api/media/file/01M5SPRS7K4M6AFV67W44ERVRW.jpg)

## 도구가 있어도 AI의 결론은 확인해야 합니다

**“컴퓨터의 서버 충돌을 확인했다”와 “휴대폰이 여러 조치 후 등록됐다”는 서로 다른 수준의 결론입니다.** 앞의 것은 관찰한 오류, 실행한 조치, 바뀐 상태가 이어진 결론입니다. 뒤의 것은 여러 조치 중 어떤 조치가 영향을 줬는지 분리하지 못한 결론입니다.

이 과정이 처음부터 효율적이었던 것은 아닙니다. 코덱스는 중간에 CLI/API로 발급한 코드와 자동으로 연 페어링 링크를 사용했습니다. 그런데 공식 모바일 설정은 데스크톱 앱에서 시작합니다. 자동화한 시험이 제가 실제로 QR을 스캔하는 경로와 완전히 같지 않았던 것입니다. [Remote connections, OpenAI 공식 안내](https://learn.chatgpt.com/docs/remote-connections)

Android 17 기기의 등록이 계속 대기 상태였다는 사실도 잘못 해석할 여지가 있었습니다. 다른 기기는 등록됐고 이 기기만 실패했다는 차이는 조사할 단서였지만, 운영체제가 지원되지 않는다는 증거는 아니었습니다.

마지막에는 제가 데스크톱 앱의 QR을 직접 다시 스캔했고, 연결됐습니다. 코덱스도 서버를 조회해 휴대폰의 상태가 등록 완료로 바뀌고 Mac mini의 연결 기기 목록에 추가된 것을 확인했습니다. 앞서 기기 키 발급 요청도 실행했으므로, 최종 성공에 어떤 조치가 영향을 줬는지는 분리해 확인하지 못했습니다. 성공 뒤 휴대폰의 USB 연결이 해제돼 최종 작업 목록 화면을 도구로 다시 확인하지는 못했습니다.

제가 직접 한 일도 있었습니다. USB를 연결했고, 필요한 로그인 인증을 진행했고, 마지막 QR을 스캔했습니다. 코덱스에는 그 사이의 조사와 실행을 맡겼습니다. 이 역할 분담이 실제 경험에 더 가깝습니다.

## 코덱스에게 문제 해결을 맡길 때 이렇게 요청해보세요

다음 요청문은 코덱스에게 가설, 검증 방법, 실행 범위, 완료 기준을 한 번에 전달합니다. 이번 경험을 바탕으로 정리했고, 연결할 기기나 서비스에 맞게 대상을 바꾸면 됩니다. 도구를 연결한 뒤에는 코덱스가 실제로 그 도구를 호출할 수 있는지도 먼저 확인해야 합니다.

```text
Mac mini와 안드로이드 휴대폰 사이의 원격제어 연결이 실패합니다.

사용 가능한 터미널, 로그 조회, 모바일 제어, 공식 문서 확인 도구를
직접 사용해 원인을 조사하고 해결을 시도해주세요.

먼저 실제 화면과 로그를 확인한 뒤 가능한 원인을 정리해주세요.
각 가설마다 확인 방법과, 결과에 따라 다음에 할 일을 정해주세요.

같은 해결책이 실패하면 새 단서 없이 반복하지 말고,
다른 가설이나 다른 관찰 방법으로 넘어가주세요.
가능하면 한 번에 한 조건을 바꾸고 전후 상태를 비교해주세요.

현재 증상, 가설, 사용한 도구, 실행한 조치, 결과를 기록해주세요.
공식 연결 절차와 자동화로 시험한 경로가 같은지도 확인해주세요.

실행 범위:
- 읽기와 되돌릴 수 있는 진단·수정은 진행해주세요.
- 데이터 삭제, 기기 초기화, 계정 변경, 진행 중인 작업 중단은
  실행 전에 대상과 영향을 설명하고 확인을 받아주세요.
- 제가 직접 인증해야 한다면 기기, 앱, 화면, 버튼 위치를 알려주세요.

완료 기준:
- 휴대폰이 서버에서 등록 완료로 확인됩니다.
- 원하는 Mac mini가 휴대폰에 표시됩니다.
- 해당 컴퓨터의 기존 작업 목록을 실제로 열 수 있습니다.

직접 확인하지 못한 항목과 확정하지 못한 원인은 구분해서 보고해주세요.
```

무엇을 고쳐야 하는지에 더해, 어디까지 확인해야 완료인지도 정했습니다. 요청을 구조화하는 방법은 [Codex 프롬프트의 완료 기준과 출력 구조](/blog/codex-prompting-guide-vs-claude-code/)에서도 다뤘습니다.

## 업무에서 반복하던 확인 작업도 살펴볼 수 있습니다

이번 문제는 개인 기기의 연결 오류였지만, 마케팅이나 제품 운영에서도 비슷한 방식으로 접근해볼 수 있습니다. 숫자가 이상할 때 사람이 대시보드를 열고, 파일을 내려받고, 다른 시스템의 숫자와 비교한 뒤 다시 AI에게 전달하는 과정이 있는지 살펴보는 것입니다.

이런 작업에는 필요한 데이터 조회 도구부터 연결하고, 비교 기준과 완료 조건을 정해볼 수 있습니다. 광고 계정처럼 맥락이 중요한 업무라면 [AI 광고 계정 진단에 필요한 정보와 기준](/blog/ai-ad-account-diagnosis-playbook/)도 함께 확인해보세요.

이번에는 시간 절감 효과를 따로 측정하지 않았습니다. 제가 확인한 변화는 구체적입니다. 코덱스가 서버 로그를 읽고, 휴대폰 화면을 확인하고, 여러 조치를 시험하고, 결과를 다시 조회했습니다. 저는 같은 오류를 계속 옮겨 적는 일보다 목표와 실행 범위를 정하고 결과를 확인하는 일에 집중할 수 있었습니다.

다음에 같은 해결책을 반복하고 있다면, **AI가 직접 확인하고 실행할 수 있도록 어떤 도구를 연결할지**부터 살펴보세요. 그리고 각 시도가 어떤 가설을 확인했는지, 다음 시도에 쓸 정보가 남았는지 함께 확인해보세요.

## 우리 업무에도 적용해보고 싶다면

팀에서 반복하는 문제 해결 과정 하나를 골라보세요. 사람이 화면과 데이터를 확인해 AI에게 전달하는 단계가 있다면, 그중 어디를 도구로 연결할 수 있는지부터 검토할 수 있습니다.

[리텐션에 AX 도입 상담 문의하기](/contact/)

## 📚 더 읽어보기

- [MCP 서버와 AI 에이전트 운영법](/blog/ai-agent-compound-setup-part3/)
- [Codex 프롬프트의 완료 기준과 출력 구조](/blog/codex-prompting-guide-vs-claude-code/)
- [AI 광고 계정 진단에 필요한 정보와 기준](/blog/ai-ad-account-diagnosis-playbook/)
- [상태와 실행을 중심으로 보는 AI 에이전트 입문](/blog/what-is-ai-agent-stateful-worker-hermes/)