#1. 개발 배경

#Electron 다음은 React Native

electron-mcp-server를 만들고 나니 자연스럽게 다음 타겟이 보였다.

Electron 앱을 AI로 제어할 수 있으면, React Native 앱도 할 수 있지 않을까?

근데 React Native는 Electron보다 훨씬 복잡한 환경이다.

Electron은 크로미움 기반이라 CDP가 바로 먹히지만, React Native는 네이티브 앱이다. DOM이 없고, 브라우저가 없고, CDP 엔드포인트도 없다.

#기존 도구들의 한계

React Native 앱을 자동화하는 도구는 있다. Detox, Appium 같은 것들. 근데 이것들은 E2E 테스트 프레임워크이지, AI 어시스턴트와 연결하기 위한 도구가 아니다.

그리고 결정적으로, 이런 도구들은 React의 내부 구조에 접근하지 못한다. 네이티브 뷰 트리는 볼 수 있지만, React 컴포넌트 트리, 컴포넌트의 state, 렌더링 횟수 같은 React 고유의 정보는 알 수 없다.

#React Fiber에 직접 접근한다

React는 내부적으로 Fiber 트리라는 자료구조를 관리한다. 각 Fiber 노드에는 컴포넌트의 타입, props, state, hooks 정보가 들어 있다.

React DevTools가 이 Fiber 트리를 읽어서 컴포넌트 트리를 보여주는데, 같은 방법으로 MCP 서버도 Fiber에 접근할 수 있다.

React DevTools 없이 컴포넌트의 state를 읽을 수 있다

이게 이 프로젝트의 핵심 차별점이다. 스크린샷이나 접근성 라벨이 아니라, 실제 React 컴포넌트 트리와 상태값을 AI가 볼 수 있다.

#네이티브 모듈 없이

이런 걸 하려면 보통 네이티브 모듈이 필요하다. 근데 네이티브 모듈은 설치가 복잡하고, 앱을 다시 빌드해야 하고, iOS/Android 각각 따로 설정해야 한다.

이 프로젝트는 네이티브 모듈을 쓰지 않는다. 대신:

1. Babel 프리셋 — 빌드 타임에 앱 코드에 런타임을 자동 주입
2. WebSocket — 런타임과 MCP 서버가 WebSocket으로 통신
3. 호스트 CLI — 터치, 스크린샷 등 네이티브 조작은 adb(Android), idb(iOS)를 사용

앱 입장에서는 Babel 프리셋 하나 추가하면 끝이다. pod install이나 네이티브 빌드 수정이 필요 없다.

#845커밋, 6주

2월 7일에 첫 커밋을 찍고, 3월 16일까지 약 6주 동안 845개의 커밋을 했다. 14번의 RC 릴리즈를 거치면서 48개의 MCP 도구를 구현했다.

electron-mcp-server 경험이 있어서 MCP 서버 구조는 빠르게 잡았지만, React Fiber 접근과 네이티브 디바이스 제어가 새로운 도전이었다.