주요 벤더의 모든 에이전트.
클라이언트 하나, 각자 샌드박스.

둘 다 셸은 주지만, 살아남는 세션은 주지 않습니다. exec 도중에 터미널을 닫으면 프로세스는 연결과 함께 죽습니다. 여기서는 세션이 컨테이너 안에 살아 있어서 앱을 닫는 것은 WebSocket 하나를 닫는 일에 그칩니다. 다음 실행에서 출력이 멈춘 바이트부터 다시 붙고 같은 분할 레이아웃을 복원합니다. 배포 방식도 다릅니다. 클라이언트에 kubeconfig가 없고 port-forward도 없으며, 자격 증명이 허용하는 범위는 클러스터 전체가 아니라 세션 하나입니다.

Herdr는 에이전트 멀티플렉서 — 코딩 에이전트를 위한 tmux입니다. 각 에이전트에 실제 PTY를 주고, 연결이 끊겨도 계속 살려 두며, 각 패널을 working／blocked／idle로 분류하고, CLI와 socket API를 제공합니다. 지속성과 전체 조망이라는 점은 이 앱과 거의 그대로 겹칩니다. 다른 것은 에이전트가 어디서 실행되는가입니다:

• Herdr는 실행한 그 머신 위에서 돌리므로 사용자, 파일시스템, 자격 증명을 공유합니다 — 즉 영향 범위는 그 머신과 여러분 계정이 닿을 수 있는 모든 것입니다. 지속성은 연결 끊김에 대한 것이지 호스트 전원이 꺼지는 것에 대한 것이 아니므로, 노트북에서 돌린다면 덮는 순간 전부 끝납니다. (SSH 원격 모드는 이를 피할 수 있지만 영향 범위가 그 원격 호스트로 옮겨갑니다.)
• OpenAB Connect는 각 세션을 클러스터 안의 독립된 컨테이너에서 실행합니다 — uid 1000, sudo 없음, 호스트 자격 증명 없음, 루트는 읽기 전용, 워크스페이스는 일회용 — WireGuard tailnet으로 닿고 포트는 전혀 열지 않습니다. 영향 범위는 그 컨테이너이며 여러분의 기계가 아닙니다. 노트북을 닫아도, 잠자기로 두어도, 다른 노트북으로 바꿔도 계속 실행됩니다.

차이는 샌드박싱이며 멀티플렉싱이 아닙니다. Herdr가 할 수 있고 OpenAB Connect가 못 하는 일도 있습니다. 패널 상태 판정, 스크립트 가능한 로컬 API, 그리고 인프라가 전혀 필요 없다는 점입니다. 아무것도 배포하고 싶지 않다면 Herdr가 더 나은 답입니다.

Mac 위의 에이전트는 여러분 자신으로 실행됩니다. SSH 키, 클라우드 자격 증명, npm과 GitHub 토큰, 디스크의 모든 리포지터리에 닿을 수 있으므로 잘못된 명령은 여러분의 기계에서의 잘못된 명령이 됩니다. 이쪽 셸은 그런 것을 하나도 갖지 않고, 워크스페이스는 세션과 함께 버려지며, 여러 에이전트가 같은 작업 트리나 같은 포트를 두고 다투지 않고 동시에 일할 수 있습니다. 노트북을 닫거나 잠자기로 두어도 아무것도 멈추지 않습니다.대가는 실재합니다. 에이전트는 로컬 파일을 볼 수 없어 작업은 git으로 오가고, 이미지의 첫 내려받기는 몇 분이 걸리며, 클러스터나 AWS 계정이 필요합니다. 이미 열어 둔 리포지터리에서 한 줄 고치는 정도라면 로컬 실행이 더 간단하고 이것은 아무 도움이 되지 않습니다.

둘은 설계상 상호 보완적입니다. 갈림길은 무엇을 중요하게 보는가입니다:

• OpenAB는 ACP를 중개합니다 — 채팅 클라이언트에서 지시를 보내고, 중요한 것은 에이전트가 내놓은 결과이며 그 과정이 아닙니다. 여러분은 지시하는 쪽이고 세션은 턴 기반 요청·응답입니다.
• openab-pty는 PTY 모드 — 네이티브 터미널로 완전한 관측 가능성을 제공합니다. 중요한 것은 지금 무슨 일이 일어나는가이며, 실시간으로 보고 살피고 직접 손을 씁니다. 여러분은 키보드 앞의 운영자이고 세션은 끝이 없는 바이트 스트림입니다.

보완 관계는 비유가 아니라 구조입니다. PTY 이미지는 FROM ghcr.io/openabdev/openab이므로 셸은 에이전트가 돌아가는 것과 같은 이미지 안에서 열리며 같은 CLI와 같은 워크스페이스를 가집니다. 작업이 중간에 멈춰 있으면 그 자리에서 붙어 들여다봅니다. 어느 쪽도 다른 쪽을 필요로 하지 않고, 세션 모델은 의도적으로 아무것도 공유하지 않습니다 — 바이트 스트림의 생존은 바이트와 소켓으로 정의되며 턴으로 정의되지 않기 때문입니다.

자세한 내용은 openab-pty의 설계 문서에 있습니다. 그리고 OpenAB Connect는 openab-pty 클라이언트 계약의 첫 클라이언트 구현입니다 — 계약이 공개되어 있으므로 자격 증명을 들고 WebSocket을 말할 수 있는 것이면 다음 구현이 될 수 있습니다.

의도적으로 거의 못 합니다. uid 1000으로 열리며 sudo도, 서비스 어카운트 토큰도, 호스트 자격 증명도 없습니다. 루트 파일시스템은 읽기 전용이고 워크스페이스는 일회용입니다. 세션 셸은 loopback으로 런타임에 닿을 수 있는데, 바로 그래서 관리 자격 증명은 컨테이너 안에 두지 않습니다. 어태치 토큰은 세션 하나만 허용하고 만료됩니다.

아닙니다. 런타임은 127.0.0.1에 바인드하고 TLS 키를 갖지 않습니다. 같은 pod의 Tailscale 사이드카만 네트워크 신원을 가지며, 둘은 pod의 네트워크 네임스페이스 안에서 loopback으로 통신합니다. 트래픽은 WireGuard tailnet을 통해 도달하고 암호화는 그쪽이 담당합니다.

아무것도 전달되지 않습니다. 여기에 서비스가 없습니다. 앱이 연결하는 서버는 모두 여러분이 자신의 클러스터나 자신의 AWS 계정에 배포한 것입니다. 계정도, 가입도, 분석도, 텔레메트리도 없습니다. 입력한 자격 증명은 macOS 키체인에 남고 여러분 자신의 런타임 외에는 어디로도 전송되지 않습니다.

가능합니다. 런타임은 MIT 라이선스로 openabdev/openab-pty에 있고 클라이언트 계약도 공개되어 있어, 이 앱을 쓰지 않고 자신의 클라이언트를 만들 수도 있습니다. 이 앱은 그 계약의 한 구현이며 오픈소스가 아닙니다.

가능합니다. 앱 메뉴의 Demo Mode는 샘플 연결 두 개와 미리 녹화된 터미널만으로 동작하며 어떤 네트워크 연결도 하지 않습니다. 아무것도 배포하기 전에 앱을 평가할 수 있도록 넣었습니다.

세 번의 클릭 뒤에 여덟 단계가 진행됩니다. 자격 증명을 만들어 키체인에 저장하고, namespace를 확인하고, secret과 볼륨을 만들고, pod을 적용한 뒤, 실행을 기다리고, tailnet 참여를 기다리고, 관리 평면을 검증합니다. 매니페스트를 쓸 필요가 없습니다. 어떤 이미지의 첫 배포는 클러스터가 이미지를 받아오는 동안 몇 분이 걸릴 수 있습니다.

워크스페이스는 버려집니다. 이 부분은 확실합니다. 그 세션을 위해서만 존재하며, 세션을 삭제하면 함께 사라집니다.

확실하지 않은 것은 프로세스입니다. 세션을 삭제하면 해당 세션의 프로세스 그룹이 종료되지만, 그 그룹을 의도적으로 벗어난 프로세스 — nohup이나 setsid로 띄운 백그라운드 작업 — 는 pod이나 task가 교체될 때까지 살아남을 수 있습니다. 여전히 같은 샌드박스 안에 갇혀 있어 새로 닿을 수 있는 것은 없지만, 그 pod의 CPU와 메모리를 계속 씁니다.

그래서 앱에서는 깔끔하게 종료된다고 말하지 않고 best-effort라고 밝힙니다. 아무것도 남지 않게 하려면 pod이나 task를 삭제하십시오.

아직 안 됩니다 — 개발 중입니다. 지금은 각 세션이 독립적이어서 여러분이 각 에이전트에 지시하며, 에이전트끼리 일을 위임하지는 않습니다.

설계는 공개되어 있습니다. OpenAB의 Agent Control Plane ADR를 따르며, 채팅 플랫폼을 거치지 않고 ACP over WebSocket으로 에이전트가 직접 위임하도록 하는 허브앤스포크 등록·라우팅 서비스입니다. 채팅 경유는 레이트 리밋과 지연을 부르고, 사람을 위한 채널에 오케스트레이션 잡음을 쏟아붓습니다. 구성은 세 가지입니다. 누가 살아 있고 어떤 라벨을 가졌는지 아는 Registry, 이름·라벨·namespace로 보내는 Router, 위임 깊이·순환·namespace· allowlist를 다루는 Policy입니다.

그 설계의 한 가지는 이 앱의 방식과 맞아떨어집니다. 에이전트가 컨트롤 플레인으로 바깥으로 연결하므로, 네트워크를 넘어 동작시키는 데 어느 쪽에도 인바운드 포트가 필요하지 않습니다.

ADR은 병합되었고 구현은 아직 출시되지 않았습니다. 함께 만들어 주세요 — 그 문서가 논의의 출발점입니다.