멀티 에이전트를 실제로 굴려본 사람이라면 공감할 것이다. tmux 세션 네 개를 띄워놓고 각각 Claude Code를 돌리다 보면, 어느 순간 어떤 에이전트가 끝났는지, 어느 게 내 입력을 기다리며 멈춰 있는지 파악이 안 된다. 더 나쁜 경우는 usage limit이 조용히 걸려버린 걸 한참 뒤에야 발견하는 것이다. 에이전트를 '더 많이' 돌리는 건 이미 가능하다. 문제는 그걸 '제대로 보는 것'이다.
이 지점을 정면으로 파고든 두 가지 도구가 최근 주목받고 있다. 하나는 comux—4개월간 직접 제작한 AI 에이전트 전용 tmux 스타일 멀티플렉서다. 사이드바에 세션별 에이전트 상태(working / ready / blocked)를 실시간으로 표시하고, 에이전트가 턴을 마치거나 입력을 기다리면 즉시 데스크톱 알림을 쏜다. 서버 재부팅 후에도 각 에이전트를 대화 중이던 지점으로 복원하며, 의존성 없는 단일 정적 바이너리라 SSH 헤드리스 서버에서도 그냥 돌아간다. 다른 하나는 Agent Island—macOS와 Windows에서 Claude Code와 Codex의 상태를 관찰하는 오픈소스 데스크톱 컴패니언이다.
두 도구가 공유하는 철학이 있다. 관찰(observe)과 실행(operate)을 명확히 분리한다는 것이다. Agent Island의 설계 원칙이 특히 날카롭다. '조용한 터미널은 모호하다'—프로세스가 계산 중인지, 툴에 막힌 건지, 멈춘 건지, 끝난 건지 파일 수정 시간만 봐선 알 수 없다. 그래서 Agent Island는 세션 레코드의 시맨틱 이벤트를 기반으로 상태를 추론한다. 최근 툴 이벤트가 있으면 working, 어시스턴트 메시지가 입력을 요청하면 your turn, 완료 이벤트가 있으면 finished. 그리고 증거가 불충분하면 confident한 레이블을 붙이지 않는다—uncertain으로 남긴다. 이 '불확실성을 인정하는 설계'가 인상적이다.
이건 단순한 UX 얘기가 아니다. 팀 레벨에서 보면 명확한 운영 리스크다. 에이전트 세 개가 동시에 돌고 있을 때 'Codex가 당신을 기다립니다'라는 알림만으로는 부족하다—어느 프로젝트의 어느 Codex인지 컨텍스트가 유지돼야 한다. 알림이 중복 발화되거나, 앱 재시작 후 같은 이벤트가 두 번 울리거나, 세션이 이미 포그라운드에 있는데 소리까지 나는 것—이런 노이즈는 금방 '알림 무시' 습관을 만들고, 결국 관리 도구 자체를 신뢰하지 않게 된다. Agent Island가 알림 정책을 '정확성의 일부'로 정의하는 이유가 여기 있다.
테크 리드 입장에서 지금 당장 팀에 적용할 수 있는 시사점은 두 가지다. 첫째, 에이전트 수가 늘어나기 전에 관찰 레이어를 먼저 세팅하라. comux는 단일 바이너리 설치라 도입 장벽이 낮다. CI 서버나 개발 머신 어디서든 curl 한 줄이면 된다. 에이전트를 두 개 이상 동시에 굴리기 시작하는 시점이 도입 타이밍이다. 둘째, 'your turn 알림'의 의미를 팀이 명확히 합의해야 한다. Agent Island가 강조하듯 이 알림은 '구현이 맞다'는 보장이 아니다. 테스트가 통과됐다는 신호도 아니다. 단지 '다음 행동이 당신 차례'라는 핸드오프 신호다. 이 구분이 없으면 알림을 받은 팀원이 검토 없이 다음 단계로 넘어가는 습관이 생긴다.
더 큰 그림에서 보면, 이 두 도구는 AI-First 개발 워크플로우의 성숙 단계를 보여준다. 초기에는 '에이전트를 어떻게 잘 쓸까'가 화두였다면, 이제는 '에이전트를 어떻게 잘 관리할까'로 질문이 이동하고 있다. 에이전트 하나를 잘 쓰는 건 개인 생산성이지만, 여러 에이전트를 팀이 함께 운용하는 건 운영 설계의 문제다. comux와 Agent Island 같은 도구들이 등장한다는 건 그 운영 복잡도가 임계점을 넘기 시작했다는 신호다.
앞으로 이 레이어는 더 정교해질 것이다. 단순 상태 표시를 넘어 에이전트별 토큰 소비 추이, 세션 간 컨텍스트 연결, 팀 대시보드 통합까지 확장될 가능성이 높다. 지금 comux나 Agent Island를 써보는 이유는 이 도구들 자체의 완성도 때문만이 아니다—멀티 에이전트 환경을 실제로 운용해보면서 우리 팀에 어떤 관찰 레이어가 필요한지 감을 잡는 것이 진짜 목적이다. 설계는 언제나 실제 운용 경험에서 나온다.