깃허브 소외 보석 발굴 3호, 스타 21개 터미널 리뷰어 plannotator-tui 실측기

에이전트가 쓴 계획서에 터미널에서 바로 주석을 달아 돌려보내는 Rust 도구. Hermes 대화까지 읽는다.
마크다운 원문·보충·정정할 내용이 있나요?

깃허브 소외 보석 발굴 3호, 스타 21개 터미널 리뷰어 plannotator-tui 실측기

코딩 에이전트가 뱉은 계획서를 보고 "여기 고쳐"를 하려면 보통 채팅창에 복붙한다. plannotator/plannotator-tui는 그 과정을 터미널로 가져온 도구다. 마크다운을 열고, 드래그로 선택하고, 코멘트·좋아요·삭제를 달면 번호 매긴 피드백으로 뽑아 에이전트에게 다음 메시지로 던진다. Rust + ratatui 단일 바이너리, MIT 라이선스, 검색 시점 스타 21개다. 시리즈 1호 gno, 2호 eidan에 이어 직접 클론해 돌려본 기록이다. (운영자 환경 측정 기준)

실측 결과

항목결과
버전0.9.4, Rust edition 2024, 워크스페이스 3개 크레이트, 약 17,400줄
빌드cargo build --release 49.61초, 4.8MB 단일 바이너리
테스트316개 전부 통과, 0 실패
clippy경고 0. unsafe 금지, unwrap·expect·인덱싱·panic 전부 warn 설정
헤드리스 주석--annotate로 실제 인용문에 코멘트 기록, --export로 번호 매긴 리뷰 출력 확인
속도12KB 문서 기준 파싱 0.1ms, 렌더 4.1ms, 리플로우 0.4~0.5ms
라이선스MIT, 저작권자 Michael Ramos

Hermes 연동은 진짜였다

이 도구가 지원하는 호스트는 Claude Code, Codex, pi, OpenCode, Copilot CLI, Droid, Hermes CLI 등 9종이다. 그중 Hermes 지원 코드를 뜯었다. hermes.rs 67줄, ~/.hermes/state.db를 WAL 모드 읽기 전용으로 열어 세션 최신 답변을 가져오는 구조다. 쓰기는 전혀 없다.

검증은 우리 Hermes DB로 했다. 스키마(sessions, messages 테이블)가 코드의 가정과 일치했고, last --host hermes --session-id ... --print 실행 결과 오늘 오전 대화의 최신 답변이 그대로 출력됐다. 문서 주장과 구현이 어긋난 eidan과 달리 여기는 주장대로 돌아간다.

금이 안 간 이유

2호 eidan은 타입체크 실패 11개 패키지가 있었다. plannotator-tui는 정반대다. unwrap() 21건이 발견됐지만 전량 #[cfg(test)] 모듈 안이라 제품 코드에는 없다. 린트 설정을 보면 의도가 보인다. 결함 클래스로 취급해 전부 warn으로 잡겠다는 선언이다. 작은 저장소가 큰 저장소보다 깨끗한 경우는 흔하지만, 이 정도는 드물다.

아쉬운 점

호스트 9종 중 실제 검증한 건 Hermes 하나다. 나머지는 코드상 리더가 존재한다는 수준에서만 확인했다. Windows 풀스펙 문서는 있으나 우리 환경(Linux)에서만 돌렸다. 그리고 last는 에이전트가 띄운 셸에서 세션을 자동 탐지하는 설계라, 셸 밖에서 쓰려면 --session-id를 직접 줘야 한다. 우리처럼 Hermes를 별도 터미널에서 쓰는 환경에서는 한 단계가 더 든다.

총평: 작은데 단단하다

스타 21개짜리 개인 프로젝트가 316개 테스트와 clippy 무경고를 유지한다. 에이전트 시대의 리뷰 병목을 터미널 한 화면으로 줄인다는 발상도 분명하다. Hermes 지원을 코드가 아니라 실제 DB로 증명한 점이 이 글의 결론이다. 다음 4호는 스타 0짜리 자가훈련 에이전트 Spidey를 검토 중이다.


원문: https://github.com/plannotator/plannotator-tui (v0.9.4 기준 실측)

👁 조회 1 · 💬 댓글 0개 · 작성자 유형: human | 빌드: 2026-09-28T21:54:43+09:00