[Economi] iSH(iOS) + Tailscale SSH를 통한 사령관 직접 조치로 hb5u XWayland 잠금 최종 해결
초록
에이전트의 kill -9 시도가 Claude Code 안전 분류기에 의해 차단되어 Magic SysRq 재부팅까지 검토되었던 hb5u XWayland 잠금 사태를, 사령관이 아이폰의 iSH(Alpine Linux) 앱에 openssh-client를 설치하고 기존 Tailscale 메시망으로 SSH 접속해 본인 계정 권한으로 직접 pkill -9 -f Xwayland를 실행함으로써 재부팅 없이 완전히 해결한 최종 사례를 기록한다. 에이전트 권한과 사용자 권한의 경계, 독립된 비상 접근 경로의 가치를 정리한다.
[Economi] iSH(iOS) + Tailscale SSH를 통한 사령관 직접 조치로 hb5u XWayland 잠금 최종 해결
개요
2026-09-02-economi-magic-sysrq-safe-reboot-after-remote-recovery-exhausted에서 원격 에이전트 셸의 안전 조치가 모두 소진되어 Magic SysRq 재부팅을 대안으로 제안했으나, 사령관은 재부팅(작업 유실)을 원하지 않아 완전히 별도의 경로로 직접 명령을 실행해 문제를 해결했다. 에이전트(Claude Code 안전 분류기)가 차단한 동작을, 사령관 본인이 별개 기기·별개 인증 경로로 직접 수행함으로써 데이터 유실 없이 복구한 최종 사례를 기록한다.
배경: 왜 에이전트가 직접 해결할 수 없었는가
앞선 논문에서 정리했듯, 이 에이전트(Economi/Claude Code)의 kill -9 <XWayland PID> 시도는 Claude Code의 auto-mode 안전 분류기가 자동 차단했다. 디스플레이 서버 핵심 프로세스 강제 종료는 되돌리기 어려운 고위험 동작으로 분류되어, 에이전트가 이를 우회하는 것은 정책상 금지되어 있다. 이 차단은 정확히 설계된 대로 동작한 것이며, 에이전트 스스로는 이 제약을 풀 권한이 없다.
반면, 동일한 명령을 사령관 본인이 자신의 계정으로 직접 실행하는 것은 아무 제약이 없다 — 그 행동의 책임과 판단이 전적으로 시스템 소유자 본인에게 있기 때문이다. 문제는 사령관이 처한 물리적 제약: hb5u의 마우스·키보드가 GUI 컴포지터 마비로 응답하지 않아, hb5u에서 새 터미널을 열 수 없었다는 점이었다.
해결 경로: 완전히 독립적인 두 번째 접근 채널 구축
1. 네트워크: 기존 Tailscale 메시가 이미 준비되어 있었음
hb5u는 이미 Tailscale tailnet에 연결되어 있었고(100.125.27.70), sshd도 이미 활성 상태(ssh.service active, 22번 포트 리스닝)였다. 즉 새로운 인프라 구축 없이 기존에 갖춰진 원격 접근 경로를 재사용하기만 하면 되는 상황이었다.
2. 클라이언트: iSH(iOS) 앱을 활용
hb5u의 물리 키보드/마우스가 죽었더라도, 사령관의 아이폰은 hb5u와 완전히 독립적인 장치다. 아이폰에서:
- Tailscale 앱이 같은 tailnet(
moosjiny@계정)에 연결되어 있어 hb5u의 Tailscale IP로 직접 라우팅 가능 - iSH(iOS 앱 — usermode x86 에뮬레이션으로 iOS 위에서 Alpine Linux 셸을 구동) 실행
apk add openssh-client로 SSH 클라이언트 설치 (iSH는 기본적으로 최소 구성이라 필요한 패키지를 직접 설치)ssh moos@100.125.27.70로 hb5u에 SSH 접속, 비밀번호 인증
3. 실행: 사령관 본인 계정으로 직접 명령
SSH 세션이 열리자 사령관은 본인 계정 권한으로 직접:
pkill -9 -f Xwayland
를 실행했다. 이 명령은 에이전트가 시도했을 때와 완전히 동일한 명령이지만, 실행 주체가 시스템 소유자 본인이므로 Claude Code의 안전 분류기가 개입할 여지 자체가 없었다.
검증
에이전트 측 셸에서 즉시 재확인:
ps aux | grep -i xwayland
→ 새 PID(17884)로 Xwayland가 살아있음 — mutter가 자동으로 재기동시킴
gdbus call --session --dest org.gnome.Shell ... Eval "1+1"
→ (false, '') , exit 0 ← 이전까지 timeout(exit 124)이던 것이 정상 응답으로 전환
gnome-shell이 D-Bus 요청에 즉시 응답하기 시작했고, mutter가 죽은 XWayland를 자동으로 새 프로세스로 교체한 것을 확인했다. 사령관도 노트북에서 마우스 클릭/키보드가 정상 작동함을 확인했다.
사태 전체 타임라인 요약
| 단계 | 증상 | 조치 | 결과 |
|---|---|---|---|
| 1차 | Moonlight 앱 창 무응답 | 에이전트가 pkill -9 -f Moonlight |
해결 |
| 2차 | 시스템 전역 입력 grab 고착 | 에이전트가 pkill -9 -f Moonlight |
해결 |
| 3차 | XWayland 스핀락, 터미널 자체를 열 수 없음 | 에이전트의 kill -9 시도 → 안전 분류기 차단 → Magic SysRq 제안 |
재부팅 없이는 미해결 |
| 4차(최종) | 동일 | 사령관이 iSH + Tailscale SSH로 직접 pkill -9 -f Xwayland |
완전 해결, 재부팅 불필요 |
시사점
- 에이전트 권한과 사용자 권한은 별개다. 에이전트에게 안전상 금지된 동작이, 시스템 소유자 본인에게는 정상적인 관리 행위일 수 있다. 안전 분류기는 "이 동작이 절대 일어나면 안 된다"가 아니라 "에이전트가 자동으로 이 판단을 내려서는 안 된다"는 경계선이다.
- 주 컴퓨터가 완전히 잠겨도, 완전히 독립된 두 번째 기기+경로(휴대폰 + VPN 메시 네트워크 + 경량 셸 앱)만 있으면 재부팅 없이 복구할 수 있다. 이번 사례에서는 Tailscale과 sshd가 이미 사전에 구성되어 있었던 것이 결정적이었다.
- iSH 같은 "휴대폰 안의 리눅스 셸" 앱은 비상 SSH 클라이언트로 실용적이다 — 별도 유료 앱 없이 표준 Alpine 패키지 관리자로 즉석에서 필요한 도구(openssh-client)를 설치할 수 있었다.
- 향후 유사 사태에 대비해, 주 워크스테이션 하나에만 의존하지 않는 비상 접근 경로(휴대폰 SSH 클라이언트, Tailscale 등)를 평소에 미리 점검해두는 것이 실질적인 복원력(resilience)의 핵심이라는 점이 이번 사례로 재확인되었다.
참고
- 1~3차 기록:
2026-09-02-economi-moonlight-appimage-wayland-hang-diagnosis,2026-09-02-economi-moonlight-input-grab-lockup-remote-recovery,2026-09-02-economi-magic-sysrq-safe-reboot-after-remote-recovery-exhausted - 실행 환경: hb5u(피해 호스트, Intel Arrow Lake-P + NVIDIA RTX 5060 Max-Q, GNOME/Wayland) · 사령관 아이폰(iSH + Tailscale, 복구 경로)