initech 프로젝트의 기술 글.
2026년 3월 28일
AI 에이전트를 위한 터미널 멀티플렉서를 만든 이유
여러 Claude Code 에이전트를 병렬로 관리하는 Go TUI를 만들었습니다. 세션 런타임으로 tmux를 대체했습니다.
각 에이전트에 역할별 지침이 담긴 Claude Code가 실행되는 터미널을 부여합니다. 수퍼바이저 에이전트가 조율하고, 엔지니어 에이전트가 구현하고, QA 에이전트가 검증하고, 시퍼 에이전트가 릴리스합니다. 각 에이전트는 자신의 정체성, 제약 조건, 워크플로, 통신 프로토콜이 인코딩된 CLAUDE.md를 받습니다.
initech를 만들기 전에 네 개의 프로젝트에서 이 패턴을 실행했습니다. 실제 소프트웨어를 출시했습니다: 병렬 엔지니어링, 독립 QA, 릴리스 게이팅, 세션 간 조직 기억.
tmux는 에이전트를 추가할수록 악화되는 세 가지 방식으로 실패합니다.
tmux send-keys에는 전달 보장이 없습니다. 에이전트 패인에 메시지를 보내고 도착하기를 바랍니다. 도착하지 않아도 오류가 없습니다. eng에서 super로의 완료 보고가 유실되면, super는 eng가 완료된 것을 모르고, QA는 배정되지 않으며, 비드가 한 시간 동안 정체됩니다.
멈춘 에이전트와 생산적인 에이전트가 tmux에서 동일하게 보입니다. 완료된 것과 작업 중인 것이 동일하게 보입니다. 알 수 있는 유일한 방법은 각 패인을 확인하는 것입니다. 에이전트가 9개면, 10-15분마다 9번 수동 확인해야 합니다.
tmux는 어떤 작업이 있는지, 누가 무엇에 할당되었는지, 에이전트가 방금 작업을 QA 준비 완료로 표시했는지 모릅니다. 모든 오케스트레이션이 수퍼바이저의 컨텍스트 창에 있습니다. 컨텍스트가 압축됩니다. 메시지가 유실됩니다. 수퍼바이저 에이전트가 eng 완료를 잊습니다. 배정 체인이 정체됩니다.
tmux는 애플리케이션 수준의 지능이 필요한 작업을 수행하는 범용 터미널 멀티플렉서입니다.
각 세션은 Unix 도메인 소켓을 실행합니다. initech send는 에뮬레이터를 통해 에이전트의 PTY에 텍스트를 쓴 다음 전달을 확인합니다. 발신자는 몇 초 내에 명시적인 OK 또는 오류를 받습니다.
$ initech send eng1 "fix the auth bug in middleware.go" $ initech peek eng1 -n 20
처음에는 JSONL 세션 로그 테일링을 시도했습니다. 신뢰할 수 없었습니다: Claude는 예측 가능하지 않게 대화 경계에서 JSONL에 씁니다. 45초간의 사고 중단 동안 항목이 0개입니다. 어떤 타임아웃이든 일부 타임아웃 값에 대해 잘못됩니다.
효과적인 방법: PTY가 마지막으로 출력을 생성한 시점을 추적합니다. Claude Code의 스피너는 사고 중 10-30 fps로 애니메이션됩니다. 출력이 0인 유일한 상태는 프롬프트 대기입니다. 2초 최근성 임계값으로 깨끗한 이진 감지가 가능합니다.
녹색 점은 작업 중. 회색은 유휴. 노란색은 대기 작업이 있는 유휴. 오버레이가 패인을 열지 않고도 모든 에이전트의 상태를 보여줍니다.
JSONL은 활동 감지에는 실패했지만 의미론적 이벤트에는 작동합니다. 세션 로그에는 도구 사용 결과, 어시스턴트 메시지, 오류 시퀀스가 포함됩니다. 이벤트 시스템은 다음을 파싱합니다:
* 비드 완료: 에이전트가 bd update --status ready_for_qa 실행
* 정체: 비드가 할당된 상태에서 10분 이상 출력 없음
* 오류 루프: 3회 이상 연속 도구 실패
* 비드 클레임: bd 명령에서 자동 감지, 추가 CLI 호출 불필요
이벤트는 토스트 알림으로 표시됩니다. super가 보고하기 전에 "eng1 completed ini-bhk.3"이 녹색으로 나타납니다.
각 에이전트의 리본에 현재 비드가 표시됩니다. 오버레이가 모든 에이전트의 상태를 한눈에 보여줍니다. 에이전트가 비드를 보유한 채 유휴 상태가 되면, TUI가 수퍼바이저 에이전트에게 직접 알립니다: "[from initech] eng1 is now idle (bead: ini-bhk.3). Check if work is complete."
위의 모든 수치는 도구 자체가 생산한 것입니다. initech가 initech를 만든 에이전트들을 관리했습니다.
TUI는 런타임이고, 템플릿이 지능입니다. 나쁜 CLAUDE.md는 TUI가 아무리 좋아도 나쁜 출력을 만듭니다. 11개의 템플릿을 모두 세 번 다시 작성했으며, 매번 실제 실패에서 얻은 교훈을 코드화했습니다: 엔지니어 에이전트가 PLAN 코멘트를 건너뛰기, QA 에이전트가 형식적으로 승인하기, 수퍼바이저 에이전트가 배정 대신 직접 작업하기.
PTY 바이트 최근성이 작동하기 전에 세 가지 접근법을 시도했습니다. JSONL 테일링: 너무 느림. 터미널 출력 속도: SIGWINCH 오탐. 프롬프트 감지: UI 변경에 취약. 스피너 접근법은 Claude Code가 작업 중일 때 항상 출력을 생성하기 때문에만 작동합니다. 정적 "thinking..." 표시는 이를 깨뜨릴 것입니다.
수퍼바이저 에이전트의 최대 실패: 배정 대신 직접 구현하는 것. 배정은 느리게 느껴집니다. 하지만 멀티 에이전트의 핵심은 전문화입니다. "에이전트를 사용하지 않는 것"이 이제 수퍼바이저 템플릿의 첫 번째 치명적 실패 모드입니다.
모든 에이전트는 결국 코딩 전 PLAN 코멘트 작성, ready_for_qa 표시 전 푸시, 비드 디스플레이 클리어를 잊습니다. 에이전트가 완료 보고를 잊기 때문에 자동 알림이 존재합니다. 가드레일이 도움이 되지만 이를 완전히 제거하지는 못합니다. 프로세스 준수는 이진값이 아닌 연속체입니다.
세션 이식성은 아직 시작되지 않았습니다. 머신 간 세션 이동(MacBook에서 워크벤치로)에는 수동 rsync가 필요합니다. PRD에는 아직 존재하지 않는 initech migrate 명령이 기술되어 있습니다.
리소스 관리는 플래그 뒤에 있습니다. 메모리 압박 시 자동 일시 중지/재개(36GB 노트북에서 효과적인 에이전트 용량을 두 배로 늘리는 기능)는 구현되었지만 실제 세션에서 정책이 충분히 테스트되지 않아 --auto-suspend 뒤에 게이트되어 있습니다.
온보딩이 거칩니다. 처음 initech를 실행하는 새 사용자는 안내 없이 7개의 패인을 봅니다. 하단에 상태 바 팁이 순환하지만, 전체 워크플로를 문서화하는 운영자 가이드가 없습니다. 이 도구는 자체 사용자가 만들었고, 그것이 드러납니다.
초기 단계. initech는 현재 여러 프로젝트에서 사용되고 있지만 사용자 기반은 아직 작습니다. 더 많은 실제 사용이 독폴링에서 발견하지 못한 격차를 드러낼 것입니다.
curl -fsSL https://initech.sh/install.sh | bash mkdir myproject && cd myproject initech init initech