AI 에이전트를 여러 개 돌리자 흔들리는 tmux의 자리

한 참여자가 오전 대화방에 툭 던진 한마디로 시작됐다. 장기 작업은 클라우드 서버에 맡기고, 정작 자기 손 앞에서는 낯선 이름의 도구를 쓴다는 말이었다. 스치듯 지나갈 법한 발언이었지만, 뒤이은 반응들은 그렇지 않았다.

"장기작업은 우분투 vps 에 다떠넘기고, 윈도우에서는 herdr, orca 위주로 쓰네용"

오래 써온 tmux 대신 herdr·orca·zellij 같은 낯선 이름이 오갔고, 대화는 곧바로 도구별 불만과 장애 경험담으로 옮겨갔다.

가장 먼저 도마 위에 오른 건 orca였다. 마음에 안 드는 pull request를 알아서 계속 날려 괴롭힌다는 불만이 나왔고, 하루에도 두어 번씩 컴퓨터가 다운돼 아예 지웠다는 경험담도 이어졌다. 장기 작업을 믿고 맡기려던 도구가 오히려 하루 두 번꼴로 작업을 멈춰 세운 셈이다. 안정성 문제 하나만으로도 도구를 갈아탈 이유는 충분해 보였다.

그러나 진짜 골칫거리는 메모리였다.

"며칠에 한번씩 메모리 90기가씩 찍으면서"

M4 Max 64GB나 M5 Max 128GB 같은 고사양 맥에서도 며칠에 한 번씩 메모리 사용량이 90기가바이트까지 치솟았고, 남는 선택지는 강제종료뿐이었다는 하소연이 이어졌다. 개인용 컴퓨터로는 최상급 사양을 갖춘 기기들이 며칠 간격으로 손을 들었다는 사실이 이 불만의 무게를 키웠다. 윈도우 쪽도 사정은 다르지 않아서, 코덱스 앱의 CPU·메모리 이슈를 두고 orca 같은 터미널 CLI로 갈아타야 할지 고민하는 목소리도 나왔다.

이 불만을 단순한 도구 취향 문제로만 보기는 어렵다. 화두를 처음 던진 발언부터가 세션 하나를 붙드는 이야기가 아니라, 장기 작업은 VPS에 넘기고 로컬에서는 여러 세션을 동시에 굴리는 구조를 전제하고 있었다. 회원들이 오가는 도구는 창 하나를 여는 터미널이 아니라, AI 에이전트 여러 개를 동시에 붙잡아두는 관제탑에 가까운 셈이다. 이 역할이 무거워질수록, 예전에는 가벼운 배경 프로세스에 불과했던 터미널 멀티플렉서가 메모리를 가장 많이 잡아먹는 자리로 옮겨간 것으로 보인다.

도구 자체의 완성도보다 도구가 떠맡아야 하는 역할이 먼저 커져버렸다는 것이 이 논쟁의 진짜 축이다. orca의 자동 PR 제안이나 잦은 컴다운은 개별 버그로 손볼 수 있어도, 여러 에이전트를 동시에 돌리며 생기는 메모리 폭주는 앱 하나를 바꾼다고 풀리지 않는다. herdr·orca·zellij 사이를 오가는 시도는 최선의 대안을 찾는 과정이라기보다, AI 에이전트 병렬 실행이라는 새 사용 패턴에 터미널 생태계가 아직 따라가지 못하고 있다는 신호로 읽힌다.

그래서 이 대화는 특정 도구 하나를 추천하거나 퇴출하는 결론으로 끝나지 않았다. 대신 tmux 시절에는 없던 종류의 질문—세션을 몇 개까지 동시에 살려둘 것인가, 그 세션들이 잡아먹는 메모리를 누가 감당할 것인가—이 새로 던져진 채로 하루가 저물었다. 도구를 고르는 기준 자체가 '안정적으로 붙어 있는가'에서 '여러 에이전트를 얼마나 버티게 하는가'로 옮겨가고 있다는 점에서, 이 논쟁은 당분간 다시 불붙을 여지가 크다.