Rmux — Playwright처럼 코드로 조종하는 새로운 터미널 멀티플렉서

tmux를 코드로 조종할 수 있다면?

터미널을 자주 쓰는 분이라면 tmux나 screen 같은 도구를 한 번쯤 만져보셨을 거예요. 창 하나에 여러 세션을 띄워놓고 분할해서 쓰는 그 도구들이요. 그런데 이게 진짜 편한 만큼, 자동화하려고 하면 의외로 까다로워요. tmux는 명령줄 인터페이스로 제어할 수 있긴 한데, 출력에서 뭔가를 읽어와서 조건 분기하거나, 특정 텍스트가 나타날 때까지 기다렸다가 다음 명령을 보내거나 하는 게 셸 스크립트로는 좀 지저분해지거든요.

이번에 공개된 Rmux는 그런 답답함에서 출발한 프로젝트예요. 한 줄로 요약하면 '코드로 조종하는 터미널 멀티플렉서'예요. 핵심 컨셉은 웹 자동화 도구인 Playwright에서 가져왔어요. Playwright가 뭐냐면, 브라우저를 띄워놓고 "이 버튼 누르고, 이 텍스트 나올 때까지 기다리고, 입력창에 이거 쓰고" 같은 동작을 깔끔한 코드로 표현할 수 있게 해주는 라이브러리예요. Rmux는 그 경험을 터미널 세계로 옮겨온 셈이에요.

어떻게 동작하나

Rmux는 SDK를 통해 터미널 세션을 프로그래밍 방식으로 제어해요. 코드에서 새 세션을 만들고, 명령을 보내고, 출력에서 특정 문자열을 기다리고, 화면을 캡처하고, 분할 창을 다루는 게 다 함수 호출로 이뤄져요. Playwright를 써본 분이라면 친숙하게 느낄 만한 API 스타일이에요. await session.sendKeys(...), await session.waitForText(...) 같은 식으로요.

이게 왜 강력하냐면, 셸 스크립트로는 어려운 '상태 기반 흐름 제어'가 쉬워지기 때문이에요. 예를 들어 서버를 띄우고 → 로그에 "Listening on port" 문자열이 나타날 때까지 기다리고 → 그제서야 다음 단계로 테스트 클라이언트를 실행하는 시나리오를 생각해볼게요. 셸로 짜면 sleep을 박거나 tail -f를 grep하면서 별의별 트릭을 써야 하는데, Rmux에서는 그냥 await waitForText('Listening on port') 한 줄이면 끝나요. 코드가 의도를 그대로 표현하는 거죠.

또 하나 흥미로운 부분은 AI 에이전트와의 궁합이에요. 요즘 LLM 기반 에이전트가 셸 명령을 실행하면서 작업을 수행하는 패턴이 많아졌잖아요. Claude Code나 OpenAI의 Codex 같은 도구들이요. 이런 에이전트가 터미널을 다룰 때 가장 큰 어려움이 '명령이 끝났는지, 어떤 출력이 나왔는지를 정확히 알기 어렵다'는 거예요. Rmux 같은 프로그래머블 터미널은 출력을 깔끔하게 캡처해서 에이전트에게 돌려줄 수 있기 때문에, 에이전트 친화적인 인프라로 쓰일 가능성이 커요.

기존 도구들과 비교해보면

Rmux 같은 컨셉이 완전히 새로운 건 아니에요. 비슷한 결의 도구로 expect가 있죠. 1990년대부터 있던 도구인데, "이 출력 보이면 이거 입력해라" 같은 시나리오를 스크립트로 짜는 데 쓰여왔어요. 하지만 expect는 Tcl 기반이라 요즘 개발자에게 낯설고, 분할 창이나 세션 관리 같은 멀티플렉서 기능은 없어요. 또 pexpect(Python), node-pty(Node.js) 같은 라이브러리도 있는데, 이건 더 저수준이라 직접 PTY를 다뤄야 해서 코드가 길어져요.

tmux 자체에도 tmux send-keys나 tmux capture-pane 같은 명령이 있어서 자동화가 아예 불가능하진 않은데요, 이런 명령들을 셸에서 조합하다 보면 결국 비동기 흐름이나 출력 파싱에서 막혀요. Rmux는 이런 부분들을 모던한 SDK로 추상화해서, 자동화 스크립트를 '진짜 프로그램'처럼 짤 수 있게 해준다는 게 차별점이에요.

한국 개발자에게 주는 시사점

당장 실무에서 써볼 만한 시나리오가 꽤 많아요. CI/CD 파이프라인의 통합 테스트가 대표적이에요. 여러 프로세스를 띄우고, 로그를 보면서 단계적으로 검증하는 테스트는 항상 짜기 까다로웠는데, Rmux 같은 도구를 쓰면 의도가 명확한 시나리오 코드로 정리할 수 있어요. 개발 환경 자동 셋업 스크립트에도 좋아요. 새 팀원이 들어왔을 때 docker 띄우고, 마이그레이션 돌리고, 시드 데이터 넣고, 서버 띄우고 하는 일련의 과정을 "각 단계의 출력을 기다렸다가 다음으로 넘어가는" 안정적인 흐름으로 만들 수 있죠.

AI 에이전트를 활용한 개발 워크플로를 구축하는 분들에게도 매력적일 거예요. 에이전트가 명령을 실행하고 결과를 정확히 읽어가는 통로로 쓸 수 있으니까요. 다만 아직 초기 프로젝트인 만큼 프로덕션에 바로 도입하기보단, 사이드 프로젝트나 내부 도구부터 천천히 검증해보는 게 좋겠어요.