Show GN: comux - AI 코딩 에이전트를 위한 tmux

Claude Code, Codex 같은 AI 코딩 에이전트를 tmux 세션 여러 개에 띄워놓고 동시에 굴리다 보니 문제가 생겼습니다. 어떤 세션이 끝났는지, 어떤 게 저를 기다리며 막혀 있는지 놓치고, 백그라운드에서 돌아가는 에이전트는 usage limit도 걸리고 나서야 알게 되더라고요.
tmux로는 여기까지가 한계라 comux를 만들었습니다.

comux는 AI 에이전트를 굴리기 위한 tmux 스타일 멀티플렉서입니다.

• 모든 세션의 에이전트 상태(working / ready / blocked)를 사이드바에 실시간 표시합니다
• 에이전트가 턴을 끝내거나 입력을 기다리면 즉시 데스크톱 알림을 발송합니다
• 서버를 죽이거나 재부팅해도, 재시작 시 각 에이전트를 대화 중이던 지점으로 복원(tmux-resurrect와 달리 session을 재시작합니다)됩니다
• 에이전트들의 usage와, 쌓여있는 알림을 status bar에서 실시간으로 확인할 수 있습니다

의존성 없는 단일 정적 바이너리라 SSH 헤드리스 서버 등 어디서나 돌아갑니다.
더 큰 터미널 프로젝트(copad)의 일부지만 comux만 따로 설치할 수 있습니다:

# Comux만 설치  
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash  
  
# Copad까지 설치 (Linux & MacOS)  
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash  

4개월간의 제작기: https://marshallku.com/dev/road-to-making-my-own-terminal/

에이전트 여러 개 굴리시는 분들 피드백 환영합니다.

[ohah173]

블로그 글도 잘 읽었습니다.
저도 비슷한 동기로 터미널을 개발하고 있는 입장에서 궁금점이 생겼어요

개인적으로 요즘처럼 DX 환경이 빨리 바뀌고, 개발자마다 다른 시대가 있었나 싶은데,
제작자분도 느끼셨는지 모르겠지만, 이럴 때 일수록 제어권이 저한테 있는게 더 유리하다고 생각했고,
AI 시대의 DX의 근간은 무엇이냐?라고 생각했을 때 터미널 베이스라고 생각했습니다.

최근에 유행하는 터미널들 다 써보았지만, 한글 입력도 대부분의 터미널에서 부실하고, 에이전트를 쓰는데는 DX, UX가 불편했기에 저도 직접 개발하자라는 결론을 얻어서 진행하고 저도 제 터미널로 다른 사람보다 더 좋은 생산성을 확보했다고 생각하는데요.

저 같은 경우 제어권을 완전히 얻기 위해서
외부 라이브러리 의존성도 최소화 해야한다는 생각에 지그 다 자체개발을 선택했는데(부득이한 웹뷰같은 경우 제외)

블로그글이랑 코드 보니까 rust를 선택하시고, rataui 등 자체 개발보다는, 러스트에 존재하는 외부라이브러리를 선택하신 이유가 궁금합니다.
글에서도 보면 외부 라이브러리 의존성으로 인한 이슈들이 있었던것 같아서요

그리고 웹뷰가 네이티브 웹뷰인만큼 대부분의 웹환경은 사파리 환경이 아니여서 완전한 E2E 테스트는 어려울것 같은데 이 부분은 그냥 외부테스팅 도구로 넘기시는걸까요? 아니면 추후 CEF도 넣으실 계획이 있으신건지도 궁금해요.

저도 이제 터미널 어느정도 쓰면서 안정화 단계에 들어서서 기능 추가나 기획, 또는 UX 고민을 많이 하는 단계에 들어섰지만, 개발 중에는 크래쉬나 이것저것 버그가 많았을텐데,

개발 시작 후 언제쯤 실행도 외부 터미널이 아닌 자체 개발하신 터미널로 진입 할 정도로 안정화가 되었었는지도 궁금합니다.

[marshallku]

안녕하세요!
좋은 경험과 생각 공유해 주셔서 감사합니다.

물론 코드를 생산하는 단가가 낮아지면서 자체 제작에 대한 길이 열리긴 했으나, 개인적으로는 AI 시대가 온 것과 무관하게 외부 라이브러리를 도입하는 것을 바라보고 있습니다.

1. 나의 요구사항을 만족하는 라이브러리가 없다
2. 비슷한 툴을 내가 개조하는 것보다 다시 만드는 것이 저렴하다

이 두 가지가 참일 것으로 생각되는 경우에만 제가 직접 제작하곤 합니다.
다양한 이유가 있지만, 결국 아무리 작은 코드조각도 제가 관리하기 시작하면 결국 제가 검수, 테스트, 유지보수 등을 해야하는 영역에 들어오고, 단순히 코드를 작성하는 것 이상의 비용이 항상 따라온다고 생각해서입니다.
개발 과정에서도 있었던 이슈들은, window manager같은 꽤 코어한 프로그램과의 충돌이 많았어서, 만약 이것까지 전부 build from scratch한다면 외부 의존성과의 충돌로 디버깅하고 테스트하는 기간보다 훨씬 많은 시간을 구현과 검증에 들였어야 했을 것이라고 생각합니다.

추가로, 저는 개발에 들어가고부터 계속 고통스럽지만 제가 만든 툴을 사용했는데, 그것이 가능했던 이유도 어느정도 의존성들 위에서 개발을 시작해서 그런게 아닐까 싶기도 합니다.
MacOS에서 SwiftTerm을 걷어낸 사례처럼, 일단 외부 의존성을 들여와서 제가 원하는 컨셉이 동작하는지 확인하고, 제가 구현해야할 게 생기면 직접 구현을 시작하지만, 이 시점에도 외부 의존성으로 일단 제 프로그램들은 돌아가고 있으니 그 위에서 계속 안정화 및 기능 추가에 힘을 쏟을 수 있었습니다.

추가로 webkit을 들이면 대부분의 웹앱은 일반적인 브라우저를 띄웠을 때와 동일하게 동작합니다!
최근에 headless browser를 cli로 제어할 수 있는 도구랑, claude in chrome도 적극적으로 활용하고 있는데다, 터미널에까지 chromium을 얹어 메모리를 과도하게 사용하는 건 막고 싶어서, 큰 일이 없으면 터미널 내부의 웹뷰의 기술 스택은 크게 바꾸지 않을 것 같긴 합니다.

읽어주셔서 감사합니다!

[marshallku]

멀티플렉서 설치 링크가 잘리네요.. README의 이 항목을 확인해 주시면 멀티플렉서만 설치할 수 있습니다.