여러 AI 에이전트 로그를 한 화면에서 보는 것은 유용하지만, 이 원문은 서로 다른 Kibitz 저장소와 기능 설명을 섞고 있어 설치 전 프로젝트 정체부터 확인해야 합니다. front matter의 kibitzsh/kibitz, 본문의 Crazytieguy/kibitz, kibitz.sh는 같은 릴리스와 아키텍처라고 단정할 수 없습니다.
원문이 해결하려는 문제 자체는 현실적이며, Claude Code나 Codex 같은 에이전트를 여러 터미널에서 돌리면 표준 출력, 도구 호출, diff와 질문이 뒤섞입니다. 사람이 창을 오가며 중요한 중단 상태를 놓치지 않도록 세션을 모으고 요약하는 통제 화면이 필요합니다.
본문이 설명한 Narrative Engine은 터미널의 출력 조각을 읽어 “파일 탐색 중”, “테스트 실패 후 수정 중”, “사용자 입력 대기” 같은 상태로 묶습니다. ANSI 제어 문자와 JSON 덩어리를 그대로 보여 주는 것보다 여러 세션을 빠르게 훑기 좋습니다.
하지만 요약은 정보 손실을 만듭니다. 오류 코드 한 줄이나 실제 실행 명령이 빠지면 원인을 잘못 판단할 수 있습니다. 상태 카드는 반드시 원본 stdout, stderr로 돌아갈 수 있어야 하고, 파서가 모르는 새 출력 형식은 억지로 분류하기보다 미확인으로 표시해야 합니다.
원문은 하위 프로세스로 에이전트를 시작하는 방식과 이미 실행 중인 세션에 연결하는 방식을 함께 설명합니다. 두 경우의 권한과 장애 처리는 다릅니다. 직접 띄운 프로세스는 수명과 입출력을 통제하기 쉽지만, 연결 방식은 터미널 종류와 운영체제 지원에 영향을 받습니다.
세션 목록과 대상 전환 같은 명령도 소개되지만, 어떤 Kibitz 저장소의 어느 버전에서 제공되는지 확인하지 않으면 안 됩니다. 원문에 나온 기능 이름을 그대로 실행 절차로 쓰지 않고, 선택한 저장소의 README와 릴리스를 기준으로 다시 맞춰야 합니다.
Rust 기반 TUI, 파일 변경 감지, git diff와 delta 연동은 여러 작업의 진행 상태를 비교하는 데 도움을 줄 수 있습니다. 중요한 질문이 올라온 세션을 앞으로 가져오고, 멈춘 작업을 찾는 것이 핵심입니다. 이 화면이 에이전트 사이의 목표 충돌이나 코드 병합을 자동으로 해결해 주는 것은 아닙니다.
Hexmos의 소개는 이런 멀티 세션 관점을 보여 주지만, 외부 리뷰의 기능 설명도 현재 저장소 상태와 다를 수 있습니다. 실제 평가에서는 지원하는 에이전트, 운영체제, 세션 복구, diff 도구 의존성을 하나씩 확인해야 합니다.
먼저 사용할 저장소 하나를 고르고 라이선스와 최근 릴리스를 확인합니다. 다음으로 두 개의 폐기 가능한 테스트 저장소에서 세션을 띄워 출력 누락, 사용자 입력 대기 표시, 강제 종료 후 복구를 살핍니다. 마지막으로 요약과 원시 로그가 불일치할 때 어느 쪽을 기준으로 할지 운영 규칙을 둡니다.
에이전트가 많아질수록 화면 하나가 병목을 없애 주지는 않습니다. 동시에 진행할 작업 수를 제한하고, 같은 파일을 고치는 세션을 피하며, 최종 병합과 배포에는 별도 승인이 필요합니다. Kibitz를 자율 스웜의 두뇌로 기대하기보다 사람이 터미널 소음을 관리하는 관찰 도구로 보면 유용성과 한계가 모두 선명해집니다.
저장소 소유자, 패키지 이름, 실행 파일과 공식 사이트가 서로 연결되는지 확인합니다. README가 설명하는 언어, 설치, 지원 에이전트와 원문 기능 목록을 표로 비교합니다. 같은 이름의 다른 프로젝트에서 가져온 명령이나 스크린샷은 현재 후보의 기능으로 사용하지 않습니다.
선택한 저장소의 release와 commit을 고정하고 라이선스를 검토합니다. 문서에 없는 Narrative Engine이나 세션 attach 기능을 기대하지 말고 실제 binary의 도움말과 테스트로 확인합니다. 글을 업데이트할 때도 어느 출처의 어떤 버전을 검증했는지 남겨야 합니다.
ANSI 정리와 상태 분류 과정에서 짧은 오류, 경고, 경로와 exit code가 사라질 수 있습니다. 긴 반복 로그를 한 문장으로 줄이면 첫 실패와 마지막 재시도를 구분하기 어렵습니다. 요약 카드에 원본 시간 범위와 로그 위치를 연결하고 알 수 없는 출력은 “미확인”으로 남깁니다.
평가용으로 테스트 실행, 사용자 입력 대기, 명령 실패, 파일 수정과 idle 상태를 만든 뒤 요약이 맞는지 사람이 판정합니다. 새 에이전트 버전이 출력 형식을 바꾸면 parser가 조용히 잘못 분류할 수 있으므로 회귀 테스트를 실행합니다. 요약 정확도와 원본 누락률을 별도 지표로 둡니다.
Kibitz가 직접 하위 프로세스를 시작하면 실행 환경과 종료를 통제할 수 있지만 그 프로세스의 파일, 네트워크 권한도 함께 가집니다. 기존 터미널에 attach한다면 운영체제, multiplexer와 IPC 권한이 필요할 수 있습니다. 관찰 도구가 원래 세션보다 넓은 자격 증명을 갖지 않게 해야 합니다.
세션별 작업 디렉터리, 환경 변수와 사용자 ID를 표시합니다. 다른 저장소의 입력을 잘못 보내거나 한 세션의 비밀 로그가 다른 화면에 섞이지 않는지 시험합니다. 읽기 전용 관찰과 키 입력, 프로세스 종료 같은 제어 권한을 분리하는 편이 안전합니다.
세션마다 별도 worktree나 수정 가능한 경로를 배정하고 작업 소유권을 표시합니다. 같은 파일을 두 에이전트가 고쳐야 한다면 순서를 정하거나 한쪽을 읽기 전용 검토로 둡니다. TUI가 두 작업을 동시에 보여 준다고 충돌이 해결된 것은 아닙니다.
최종 병합 전에 각 diff와 테스트를 독립적으로 확인합니다. 하위 작업의 완료 문구보다 실제 commit, 파일 상태를 기준으로 합니다. 충돌 해결과 배포는 별도의 승인 단계로 남기고 화면에서 실수로 모든 세션에 같은 명령을 보내지 않게 확인을 둡니다.
명령 실행 중 TUI를 종료하거나 하위 에이전트가 crash한 상황을 만듭니다. 재실행 뒤 세션 상태와 원본 로그를 다시 찾을 수 있는지, 이미 끝난 명령을 중복 실행하지 않는지 봅니다. 복구 불가능한 세션을 정상 진행 중으로 표시하지 않아야 합니다.
세션 기록에는 모델, 에이전트 버전, 작업 디렉터리와 마지막 관찰 시점을 남깁니다. 프로세스는 살아 있지만 로그 연결만 끊긴 경우와 프로세스 자체가 끝난 경우를 구분합니다. 사용자가 작업을 포기할 때 파일, 하위 프로세스와 임시 로그를 어떻게 정리할지도 필요합니다.
폐기 가능한 두 저장소에서 서로 다른 에이전트 세션을 띄우고 정상 완료, 오류, 질문 대기와 충돌을 재현합니다. 상태 분류 정확도, 원본 이동 시간, CPU, 메모리, 로그 누락과 복구를 측정합니다. 화면 없이 기존 terminal multiplexer를 쓴 기준과 사람 확인 시간도 비교합니다.
실제 이득이 확인돼도 동시 작업 수에 상한을 둡니다. 사람이 검토할 수 있는 속도보다 많은 세션을 열면 요약 카드만 늘어납니다. Kibitz의 성과는 스웜 크기보다 놓친 질문, 충돌을 줄이고 원본 근거에 빨리 도달했는지로 평가하는 편이 맞습니다.
이 글의 근거로 그렇게 단정할 수 없습니다. 여러 세션과 로그를 관찰, 요약하는 도구와 작업 배분, 충돌 해결을 수행하는 오케스트레이터는 구분해야 합니다.
안 됩니다. 요약에서 오류 코드, 명령과 diff가 빠질 수 있으므로 원본 stdout, stderr와 실제 파일 변경, 테스트로 돌아가 확인해야 합니다.
원문에는 이름이 같은 여러 저장소와 사이트가 섞여 있으므로 원하는 기능의 공식 출처, 라이선스, 릴리스, README를 대조한 뒤 하나를 명시적으로 선택해야 합니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.