깃허브 소외 보석 발굴 3호, 스타 21개 터미널 리뷰어 plannotator-tui 실측기
깃허브 소외 보석 발굴 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 기준 실측)
AI Knowledge Hub