계층 1: 영상 전체 핵심 주장 요약
에이전트 시대의 엔지니어에게 필요한 단 하나의 아이디어는 **"컴퓨트를 스케일해서 임팩트를 스케일하라"**이다. 멀티 에이전트 오케스트레이션의 핵심 과제는 세 가지로, (1) 에이전트에 대한 프로그래밍 방식 접근, (2) 에이전트 모니터링 및 개선 가시성, (3) 에이전트 팀의 빠른 런칭이다. CMUX는 Mac 전용 터미널 멀티플렉서로, T-Mux 대비 현대적인 UX와 스크립터블 API를 제공하며, 에이전트가 다른 에이전트를 직접 조작할 수 있는 "에이전틱 액세스"를 가능하게 한다. 영상은 단순 "바이브 코딩"에서 벗어나 에이전트를 관찰하고 개선하는 "에이전틱 엔지니어링"을 주창하며, 3계층 오케스트레이션 아키텍처(오케스트레이터 → 팀 리드 → 워커)를 실전 데모로 보여준다.
계층 2: 섹션별 상세 내용
[00:00–01:20] 도입: 에이전트 오케스트레이션의 핵심 질문
- 에이전트 시대에서 최고의 엔지니어들이 던지는 질문: "최대 임팩트를 위해 에이전트를 어떻게 오케스트레이션해야 하는가?"
- 다양한 패턴들 소개: 루프 엔지니어링, Ralph 스타일 투두리스트, 서브에이전트 위임
- 발표자(15년+ 엔지니어링 경험)는 세 가지 핵심 문제를 해결하기 위해 CMUX를 탐색
[01:20–04:00] 세 가지 멀티 에이전트 문제 정의
- 프로그래밍 방식 접근 부재: 수동 개입이 병목이 되어 에이전트 속도를 저하
- CMUX/T-Mux: 모든 터미널에 에이전틱 액세스 제공 → 병목 해소
- 모니터링 불가: "볼 수 없는 에이전트는 개선할 수 없는 에이전트"
- CMUX: 워크스페이스별 색상/아이콘/뱃지/배너로 시각적 식별 가능
- 에이전트 팀 부팅의 속도 문제: 손수 부팅하면 에이전틱 속도에 역행
- CMUX: 재사용 가능한 세션 파일 + 에이전틱 액세스로 즉시 해결
[04:00–07:00] CMUX 멘탈 모델: 윈도우 → 워크스페이스 → 페인
- 윈도우: Ctrl+Shift+N으로 새 윈도우 생성 (최상위 컨테이너)
- 워크스페이스: Cmd+N으로 생성, 에이전트 팀 단위로 구성 (핵심 단위)
- 페인(Pane): 개별 터미널 창. Cmd+T는 기존 페인 안에 새 서피스 오픈
- 오케스트레이션 레이아웃: 왼쪽 = 팀 리드, 오른쪽 = 워커 에이전트들
[07:00–10:00] CMUX API와 제어 방식
- Send → Read → Open/Close Surface 루프로 에이전트 제어
send_key로 텍스트 전송, 액션 후 화면 읽기, 라이프사이클 이벤트 구독 가능- 에이전트가 CMUX를 통해 다른 에이전트의 터미널을 직접 조작 가능
[10:00–15:00] 기초 데모: 워크스페이스 생성 및 그리드 레이아웃
- Claude Code Opus 오케스트레이터가 CMUX 워크스페이스를 열고 파일 조작 후 닫기
- 2×2 그리드: htop, 날짜 업데이터, 틱 모니터, 빈 터미널 동시 실행
- 워크스페이스 이름 실시간 업데이트("retired"로 리네임), 이름이 "Flash"로 업데이트되는 것을 라이브로 확인
- 핵심: 에이전트가 워크스페이스 UX를 프로그래밍 방식으로 제어
[15:00–20:00] 멀티 에이전트 플릿 데모: 보안 취약점 탐색
- 4개 코딩 에이전트 동시 실행: Claude Code(Opus 4.8), Codeex, Pi(Minimax M3), GLM 5.2
- 동일한 저장소에서 각 에이전트가 독립적으로 보안 취약점 탐색
- 에이전트 완료 시 오케스트레이터 윈도우에 알림 이벤트 전송
- 오케스트레이터가 화면을 읽어 결과를 집계, 유휴(idle) 상태로 전환
- 핵심 가치: 서로 다른 모델의 강점을 동시에 활용
[20:00–24:00] 에이전트-투-에이전트 통신: 평면(Flat) 계층 구조
- CMUX 스킬을 통해 Claude Code 워커가 다른 에이전트에게 Ping 전송
- 3계층 아키텍처: 오케스트레이터 → 팀 리드 → 워커 (하향식이 아닌 평면 통신)
- 어떤 에이전트도 어떤 에이전트에게든 프롬프트 가능 (양방향 평면 통신)
- 팀 리드를 왼쪽, 워커를 오른쪽에 배치하는 UX 패턴
[24:00–28:00] 프로덕션 버그 핫픽스 시나리오: 8에이전트 레이스
- 시나리오: 프로덕션 장애 → 초당 손실 발생 → 즉시 해결 필요
- 8개 에이전트를 동시에 런칭하여 needle-in-haystack 방식으로 경주
- 다양한 모델(Opus, Sonnet, Codeex, Pi)이 각자의 강점으로 동일 문제 공략
- 첫 번째 완료 에이전트의 결과를 즉시 배포 → 병렬 컴퓨트의 핵심 가치
- 한계: 알림 이벤트가 오케스트레이터에 제대로 전달되지 않는 버그 목격
[28:00–34:00] CMUX vs T-Mux 비교 및 3계층 실전 런칭
- CMUX: Mac 전용, 현대적 UX, 커스터마이저블, 초보자 친화적 개발자 경험
- T-Mux: Linux/Windows/WSL 지원, 성숙도 높음, 커스터마이징 난이도 높음
- 발표자의 실전 워크플로:
just파일의jfast cc명령으로 에이전트 팀 즉시 부팅- 오케스트레이터(상단) → GLM 5.2 팀 리드 → 플랜/빌드/프론트엔드/테스트 워커
- 각 에이전트 1M 컨텍스트 × 5 = 5M 토큰 컨텍스트 풀 확보
[34:00–끝] 결론 및 아젠틱 엔지니어링 철학
- CMUX 총평: T-Mux 대비 경쟁력 있음, 스크립터블 API가 핵심 가치
- 5대 에이전틱 엔지니어링 필러 중 "에이전틱 액세스"가 5번째 핵심 기둥
- 경고: 신상 도구는 버그가 있을 수 있음 → 성숙도 모니터링 필요
- 철학: 바이브 코딩(바퀴를 AI에 맡기는 것)이 아닌 에이전틱 엔지니어링(오케스트레이션 지능)이 엔지니어의 도메인
계층 3: 핵심 개념/용어 설명
| 용어 | 설명 |
|---|---|
| CMUX (Ghostty 기반) | Mac 전용 현대적 터미널 멀티플렉서. 스크립터블 API를 통해 에이전트가 직접 제어 가능 |
| T-Mux | 전통적 터미널 멀티플렉서. Linux/Windows 지원, 성숙도 높지만 DX는 다소 복잡 |
| 에이전틱 액세스 (Agentic Access) | AI 에이전트가 도구/서비스/터미널을 인간 속도가 아닌 에이전트 속도로 제어할 수 있는 능력 |
| 3계층 오케스트레이션 | 오케스트레이터(최상위) → 팀 리드(중간) → 워커(실행) 구조. 하향식이 아닌 평면 통신 |
| Core 4 (코어 4) | 에이전트 동작을 정의하는 4요소: Context, Model, Prompt, Tool |
| 바이브 코딩 vs 에이전틱 엔지니어링 | 전자는 AI에 맡기고 결과만 보는 방식, 후자는 에이전트를 관찰·개선·오케스트레이션하는 방식 |
| 루프 엔지니어링 | Boris/Peter가 주창하는 방식. 에이전트를 루프에 돌리는 것. 발표자는 이것만으로는 부족하다고 주장 |
| Ralph 스타일 투두리스트 | 에이전트가 대규모 작업 목록에 집중하게 하는 방식 (Fable 모델과 잘 맞음) |
| Pi 코딩 에이전트 | 발표자가 커스터마이즈한 IPI 기반 코딩 에이전트. 여러 확장 기능 내장 |
| 알림 이벤트 | 에이전트 완료 시 CMUX가 오케스트레이터 윈도우에 전송하는 이벤트 |
| 워크스페이스 | CMUX의 핵심 조직 단위. 에이전트 팀을 그룹화하는 컨테이너 (Cmd+N) |
계층 4: 실행 포인트 & 시사점
즉시 실행 가능한 것들
- CMUX 설치 및 스킬 파일 생성: 오케스트레이터 에이전트가 CMUX를 인식하도록 스킬 문서 작성
- 3계층 워크플로 템플릿화:
just파일에jfast cc <feature>명령으로 에이전트 팀 원클릭 부팅 - 시각적 구분 설정: 워크스페이스별 색상/이름/아이콘을 설정해 에이전트 팀 식별 용이하게
- Send-Read-Close 루프 패턴 습득: CMUX API의 핵심 제어 흐름 숙지
전략적 시사점
- 다양한 모델을 병렬 활용하라: 동일 문제에 다른 모델(Opus, Sonnet, GLM, Minimax)을 동시에 투입해 최선의 결과를 가장 빨리 획득
- "볼 수 없는 에이전트는 개선할 수 없다": 에이전트 모니터링 인프라에 투자하는 것이 장기적 성능 향상의 핵심
- 프로그래밍 방식 접근이 없으면 사용 가치 없음: 에이전틱 액세스 없는 도구는 선택지에서 제외
- 컨텍스트는 곧 팀 지능: 5개 에이전트 × 1M 컨텍스트 = 5M 토큰의 집단 지성 활용 가능
- CMUX는 Mac 전용: Linux/Windows 환경은 T-Mux가 유일한 대안
주의 사항
- CMUX는 비교적 신생 도구 → 알림 이벤트 미수신 등 버그 존재
- 에이전트 팀 복잡성 증가 시 오케스트레이터 프롬프트 엔지니어링 난이도 상승
- 성숙도 관점에서 T-Mux 대비 아직 검증 기간 필요