initech 프로젝트의 기술 글.
2026년 4월 1일
Claude Code, Codex, OpenCode를 같은 TUI에서 실행하기
initech는 처음에 모든 패인이 Claude Code라고 가정했다.
실제 작업에서는 이 가정이 오래가지 않는다. 큰 리팩터링은 Claude Code, 닫힌 작업은 Codex full-auto, 다른 상호작용 모델은 OpenCode를 쓰게 된다. 문제는 실행이 아니라, 그것들을 한 화면에서 같이 다루는 일이다.
이제 initech는 Claude Code, OpenAI Codex, OpenCode를 같은 TUI에서 나란히 실행할 수 있다.
대부분의 multi-agent 도구는 모든 패인이 같은 CLI를 실행한다고 가정한다. 그 가정은 실행 방식, 입력 방식, 프롬프트 판별, submit 키까지 스며든다.
도구를 섞으면 차이가 바로 드러난다. 어떤 CLI는 bracketed paste를 기대하고, 어떤 CLI는 그 입력을 싫어한다. 어떤 도구는 단순한 > 프롬프트에서 바로 입력을 받고, 어떤 도구는 아직 trust 화면이나 서비스 부팅 단계에 있다. 권한 확인 하나만 떠도 자율 실행이 멈춘다.
보이는 변화는 initech.yaml의 role_overrides다. 기본 실행 명령에서 벗어나는 역할만 별도 command 배열을 갖고, agent_type이 그 패인에 맞는 하네스를 고른다.
project: myproject
root: ~/src/myproject
claude_command: ["claude"]
claude_args: ["--continue"]
roles:
- super
- eng1
- eng2
- qa1
role_overrides:
eng2:
command: ["codex", "resume", "--last", "--full-auto"]
agent_type: codex
qa1:
command: ["opencode", "--continue"]
agent_type: opencode
command는 append가 아니라 완전한 교체다. Claude 전용 플래그가 Codex 역할에 섞이지 않는다. 그리고 agent_type은 장식용 메타데이터가 아니라, ready 체크, bracketed paste, submit key, CLI별 자동화를 결정하는 스위치다.
터미널 멀티플렉서에서 가장 지루하지만 중요한 문제는 submit이다. 여기가 틀리면 나머지는 전부 의미가 없다.
Claude Code는 기존 bracketed paste 경로를 유지한다. Codex 계열 패인은 프롬프트가 실제로 준비될 때까지 기다리고, 메시지 본문을 PTY에 직접 쓰고, paste burst 판정이 끝난 뒤 submit 키를 보낸다.
Codex 자율 실행에서 또 하나의 문제는 권한 프롬프트다. 확인 하나가 뜨면 그 패인은 사람이 돌아올 때까지 멈춘다.
agent_type: codex에서는 initech가 auto_approve를 기본으로 켠다. 터미널 하단의 알려진 패턴을 보면 p를 보내 승인과 기억을 처리한다.
중요한 점은 "이제 Codex도 된다"가 아니다. initech가 agent-agnostic terminal multiplexer 쪽으로 가고 있다는 점이다.
운영자가 보는 인터페이스는 하나다. TUI도 하나, 감독 지점도 하나다. 그 안에서 역할에 맞는 에이전트를 고르면 된다.
설치: initech.sh/install.sh
소스 코드: github.com/nmelo/initech
2026년 3월 31일
역할별 명령어 오버라이드: Codex, Amp, Claude Code를 나란히 실행
initech는 더 이상 Claude Code 전용이 아닙니다. initech.yaml의 role_overrides를 사용하면 모든 역할에 다른 CLI를 지정할 수 있습니다. 한 에이전트에는 Codex, 다른 에이전트에는 Amp, 나머지에는 Claude Code. 동일한 IPC, 동일한 활동 감지, 동일한 TUI.
initech.yaml의 새로운 role_overrides 블록으로 역할별 기본 명령어를 오버라이드할 수 있습니다:
# initech.yaml role_overrides: codex-eng: command: ['codex', '--full-auto', '--no-alt-screen'] amp-design: command: ['amp']
각 오버라이드는 역할 이름을 명령어 배열에 매핑합니다. 역할은 여전히 자체 PTY, TUI 내 자체 패인, initech send / initech peek에 대한 전체 액세스를 유지합니다. 런타임은 PTY 안에서 무엇이 실행되는지 신경 쓰지 않습니다.
"에이전트 런타임"이라는 프레이밍은 지금까지 목표에 불과했습니다. initech는 모든 곳에서 Claude Code를 가정했습니다. 활동 감지는 Claude의 스피너에 의존했고, 이벤트 시스템은 Claude의 JSONL 로그를 파싱했으며, 역할 템플릿은 CLAUDE.md 파일이었습니다.
명령어 오버라이드를 통해 핵심 프리미티브는 계속 작동합니다. PTY 바이트 흐름은 어떤 CLI가 출력을 생성하든 활동을 감지합니다. IPC 메시징은 터미널 수준에서 작동하며 Claude에 특화되지 않습니다. CLAUDE.md 템플릿은 Claude Code를 실행하는 역할에만 적용됩니다. 다른 CLI는 자체 설정을 가져옵니다.
Claude가 아닌 CLI에서 잃는 것: JSONL 기반 이벤트 파싱(비드 완료 감지, 정체 감지)과 세션 로그 기반 토스트 알림. 활동 감지와 IPC는 계속 작동합니다. 혼합 플릿의 경우 Claude Code 에이전트는 전체 기능 세트를 사용하고, 나머지는 안정적인 PTY 관리와 메시징을 사용합니다.
명확한 사례: 같은 코드베이스에서 에이전트 CLI를 비교하고 싶을 때. eng 역할을 Claude Code로 실행하고 병렬 eng 역할을 Codex로 실행합니다. 같은 작업, 다른 에이전트, 나란히 표시.
실용적 사례: 일부 작업은 다른 도구가 더 적합합니다. 단순한 리팩토링에는 풀 오토 모드의 Codex 에이전트. 더 많은 가이드가 필요한 복잡한 멀티 파일 변경에는 Claude Code. 둘 다 하나의 터미널에서 확인하고 주소 지정 가능.
$ curl -fsSL https://initech.sh/install.sh | bash
소스 코드 및 운영자 가이드: github.com/nmelo/initech
2026년 3월 30일
크로스 머신 조율: 여러 머신에서 에이전트 플릿 실행하기
initech가 이제 크로스 머신 조율을 지원합니다. 워크스테이션, 원격 GPU 머신, 클라우드 VM 등 어느 머신에서나 initech serve를 실행하면, 로컬 TUI가 모든 에이전트 패인을 실시간으로 스트리밍합니다. 하나의 터미널. 모든 에이전트. 어느 머신이든.
원격 머신의 initech.yaml에 mode: headless, peer_name, listen, token을 추가합니다:
project: myproject root: /home/user/myproject mode: headless peer_name: workbench listen: ":7391" token: "공유-시크릿" roles: - eng1 - eng2 - eng3
데몬 시작:
$ initech serve
로컬 initech.yaml에 remotes: 블록을 추가합니다:
project: myproject
root: /Users/you/myproject
token: "공유-시크릿"
roles:
- super
- pm
- qa1
remotes:
workbench:
addr: "192.168.1.100:7391"
TUI를 평소대로 실행:
$ initech
$ initech send workbench:eng1 "API 리팩토링 시작" $ initech peek workbench:eng2 -n 30 $ initech peers
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