[기술검토] tmux 도입 및 AI 에이전트 실행 워커 연동 가능성
터미널 멀티플렉서 tmux를 AI 에이전트 헤드리스 실행 워커에 도입해 SSH 끊김 대응, 장시간 실행 안정화, 다중 에이전트 모니터링을 개선하는 방안 검토. 기존 아키텍처 변경 없이 3단계 점진 도입 로드맵 제시.
[기술검토] tmux 도입 및 AI 에이전트 실행 워커 연동 가능성
터미널 멀티플렉서 tmux를 자체 구축 멀티에이전트 하네스(이하 "AI 개발 파이프라인")의 헤드리스 실행 워커에 도입하는 방안을 검토했습니다. 결론: 기존 아키텍처를 바꾸지 않고 tmux 세션으로 감싸는 것만으로 SSH 끊김 대응·장시간 실행 안정화·다중 에이전트 모니터링을 단계적으로 확보할 수 있습니다.
1. tmux란?
tmux (Terminal Multiplexer) — 터미널 하나를 여러 개로 나눠서 쓰는 CLI 도구.
핵심 개념 3가지
| 개념 | 설명 | 비유 |
|---|---|---|
| Session | 독립된 작업 공간. 프로세스가 서버에 유지됨 | 브라우저 창 |
| Window | 세션 안의 탭 | 브라우저 탭 |
| Pane | 창 안의 분할 화면 | 탭 안의 분할 뷰 |
┌─────────── tmux session ───────────────┐
│ Window 1: harness Window 2 │
│ ┌───────────────┬─────────────────┐ │
│ │ Pane 1 │ Pane 2 │ │
│ │ claude 실행 │ tail -f logs │ │
│ │ (진행 중) │ (모니터링) │ │
│ └───────────────┴─────────────────┘ │
└────────────────────────────────────────┘
↑ SSH 끊겨도 세션은 서버에서 계속 살아있음
Warp와의 차이
| Warp | tmux | |
|---|---|---|
| 정체 | 터미널 앱 자체 (GUI) | 터미널 내에서 실행하는 프로그램 |
| 세션 유지 | 앱 꺼지면 종료 | SSH 끊겨도 계속 실행 |
| 사용 위치 | 로컬 Mac 전용 | 서버/로컬 모두 |
| 설치 | GUI 앱 다운로드 | brew install tmux |
2. 관련 오픈소스 현황
tmux와 Claude Code를 조합한 도구들이 이미 오픈소스로 존재함.
| 도구 | GitHub | 방식 | 특징 |
|---|---|---|---|
| amux | mixpeek/amux | tmux + 웹 대시보드 | 수십 개 에이전트 병렬 실행, 칸반보드, 에이전트 간 오케스트레이션 |
| Claude Squad | smtg-ai/claude-squad | tmux + TUI | 격리된 git worktree별 Claude Code 관리, diff 미리보기 |
| Codeman | Ark0N/Codeman | tmux + WebUI | Claude Code/Opencode 세션을 WebUI로 관리, 60fps 실시간 출력 |
3. 현재 구조와의 관계
AI 개발 파이프라인은 백엔드(Docker)와 별도로, 호스트에서 헤드리스 실행 워커(이하 "실행 워커", scripts/worker.py)가 Claude Code 프로세스를 직접 spawn 하는 구조입니다.
실행 워커 실행 흐름
현재 문제점
| 문제 | 내용 |
|---|---|
| SSH 끊김 | 실행 워커 프로세스가 종료될 수 있음 |
| 장시간 실행 | 30분+ 하네스 작업 시 heartbeat 로직으로 간신히 유지 |
| 병렬 실행 가시성 | 여러 에이전트 동시 실행 시 터미널에서 모니터링 어려움 |
| 재기동 | 실행 워커 재시작 시 진행 중 작업 컨텍스트 소실 |
4. 도입 가능성 분석
도입 방식
tmux는 기존 실행 구조를 바꾸지 않고 감싸는 형태로 도입 가능.
활용 시나리오
시나리오 A: 실행 워커 자체를 tmux 세션으로 실행
# tmux 적용 후
tmux new-session -d -s agent-worker \
-c "$PROJECT_DIR" \
"python scripts/worker.py --ws-url $WS_URL"
# 재접속
tmux attach -t agent-worker
- SSH 끊겨도 실행 워커가 서버에서 계속 실행
tmux attach로 언제든 실시간 로그 확인 가능
시나리오 B: 하네스 장시간 실행 격리
tmux window 1: /자동개발_V4 이슈-A (진행 중)
tmux window 2: /자동검증_V4 이슈-B (완료)
tmux window 3: /자동분석 이슈-C (대기)
- 이슈 트래커의 이슈별로 tmux window 분리
- 실행 워커가 session_id를 추적 → 취소/상태 조회 가능
- 기존 30초 heartbeat 로직 단순화 가능
시나리오 C: 다중 에이전트 병렬 대시보드
amux 방식 참고하여 자체 구현:
실행 워커에서 tmux capture-pane 주기적 폴링 → WebSocket 브로드캐스트
5. 도입 권고안
단계별 로드맵
| 단계 | 작업 | 난이도 | 기대 효과 |
|---|---|---|---|
| 1단계 (즉시) | 실행 워커 실행을 tmux 세션으로 래핑 | 낮음 | SSH 끊김 대응, 재기동 편의성 |
| 2단계 (중기) | 하네스 개별 작업을 tmux window로 격리 | 중간 | 작업별 로그 분리, heartbeat 로직 단순화 |
| 3단계 (장기) | 대시보드에서 tmux pane 출력 표시 | 높음 | 다중 에이전트 실시간 모니터링 |
1단계 구체 구현
워커 설치 스크립트(scripts/install-worker.sh) 수정:
# tmux 설치 확인
if ! command -v tmux &> /dev/null; then
echo "tmux가 필요합니다: brew install tmux"
exit 1
fi
# 기존 세션 종료 후 재시작
tmux kill-session -t agent-worker 2>/dev/null || true
tmux new-session -d -s agent-worker \
-c "$PROJECT_DIR" \
"python scripts/worker.py --ws-url $WS_URL; read"
echo "실행 워커 시작됨 (tmux session: agent-worker)"
echo "로그 확인: tmux attach -t agent-worker"
6. 리스크 및 고려사항
⚠️ 대부분 경미하지만, launchd 이중화와 세션 정리 정책은 1단계 도입 시 함께 결정해야 합니다.
| 항목 | 내용 |
|---|---|
| tmux 의존성 | 경량 표준 도구. macOS: brew install tmux, Linux: apt install tmux |
| Docker 환경 | 백엔드는 Docker 실행 중이지만 실행 워커는 호스트에서 실행 → 문제 없음 |
| launchd와 이중화 | macOS launchd로 이미 실행 워커 관리 중. launchd가 tmux 세션을 직접 관리하도록 변경 필요 |
| Windows 미지원 | tmux는 Unix 전용. Windows 개발 환경에서는 WSL2 또는 대안 필요 |
| 세션 누적 | 장시간 운영 시 tmux session 정리 정책 필요 (완료된 window 자동 종료 등) |
7. 요약
| 구분 | 내용 |
|---|---|
| tmux 정의 | 터미널 세션 유지 + 분할 + 백그라운드 실행 도구 |
| 1단계 (즉시) | 실행 워커를 tmux 세션으로 실행 → SSH 끊김 즉시 대응 (공수 낮음) |
| 2단계 (중기) | 하네스 작업을 tmux window로 격리 → 안정성 향상, heartbeat 단순화 |
| 3단계 (장기) | 다중 에이전트 대시보드 구현 → amux 참고, 장기 과제 |
| 결론 | 기존 아키텍처 변경 없이 점진적 도입 가능 |
Comments
No comments yet. Be the first to comment!
★Reviews for this material
Write a reviewNo reviews for this material yet.