AI 에이전트도 모니터링이 필요하다: Agent Cat으로 만드는 세련된 Agent Workflow
AI 에이전트도 모니터링이 필요하다: Agent Cat으로 만드는 세련된 Agent Workflow
Coding Agent를 처음 사용할 때는 대개 하나만 실행한다.
Terminal
↓
Codex
↓
작업 완료이 정도라면 별도의 모니터링 도구가 없어도 크게 불편하지 않다.
하지만 Coding Agent가 일상적인 개발 도구가 되기 시작하면 화면이 조금씩 복잡해진다.
Terminal 1
Codex
Terminal 2
Claude Code
Terminal 3
Gemini CLI
Terminal 4
Build
IDE
Git
Browser그리고 어느 순간 이런 문제가 생긴다.
지금 Agent가 작업 중인가?
응답을 기다리는 건가?
이미 끝난 건가?
오늘 Token을 얼마나 썼지?
이번 주 한도는 얼마나 남았지?
어느 프로젝트가 Token을 가장 많이 먹었지?
Codex와 Claude 중
이번 주에 무엇을 더 많이 사용했지?Agent를 잘 쓰는 것과 Agent가 지금 어떻게 사용되고 있는지 아는 것은 다른 문제다.
서버를 운영할 때 Application만 띄우고 끝내지 않는 것처럼, Coding Agent를 자주 사용하기 시작하면 Agent에도 Observability가 필요해진다.
Agent Cat은 이 문제를 꽤 재미있는 방식으로 해결한다.
macOS 메뉴바나 Windows 트레이에 작은 캐릭터를 올려놓고 Codex, Claude Code, Gemini CLI 등의 로컬 Agent 활동을 읽는다.
Agent가 쉬고 있으면 캐릭터도 쉬고,
작업량이 늘어나면 걷고,
활동량이 높아지면 뛰기 시작한다.
하지만 핵심은 캐릭터가 아니다.
그 아래에는:
Agent Process
Token
Model
Quota
Cost
Cache
Project
History를 하나의 화면으로 모으는 Agent Monitoring Layer가 있다.
Agent를 많이 사용할수록 이 부분이 더 중요해진다.
1. Agent Cat은 새로운 Coding Agent가 아니다
먼저 역할부터 분명히 해야 한다.
Agent Cat이 코드를 작성하는 것은 아니다.
Codex
Claude Code
Gemini CLI가 실제 작업을 수행한다.
Agent Cat은 그 옆에서:
실행 상태
활동량
Token 사용량
Model
남은 한도
비용 추정
프로젝트별 사용량을 관찰한다.
구조를 단순화하면:
Developer
│
├── Codex
├── Claude Code
└── Gemini CLI
│
▼
Agent Cat
│
▼
Observability이다.
따라서 Agent Cat을 가장 잘 설명하는 표현은:
Agent Manager보다는
Agent Observatory또는
Agent Cockpit에 가깝다.
2. 설치하면 기존 사용법을 바꿀 필요가 없다
이 부분이 꽤 중요하다.
Agent Cat을 쓰기 위해:
Agent Cat 전용 Prompt
Agent Cat 전용 Terminal
Agent Cat 전용 Coding Agent를 배울 필요가 없다.
평소처럼:
codex를 실행하거나,
claude또는 Gemini CLI를 사용한다.
Agent Cat은 로컬에 실행되는 Agent의 활동 정보를 읽는다.
공식 안내 기준으로 현재 macOS 14 이상과 Windows 10/11을 지원하며, macOS에서는 메뉴바, Windows에서는 시스템 트레이에서 동작한다.
처음 실행하면 앱이 로컬 Connector 설치를 안내하고, 정상 연결되면 기존 CLI를 그대로 사용하면서 상태를 확인할 수 있다.
3. 처음 해야 할 설정은 단순하다
macOS라면:
Agent Cat 설치
↓
실행
↓
Connector 연결 확인
↓
메뉴바에 고정
↓
로그인 시 자동 실행정도면 된다.
Windows에서도 비슷하다.
Agent Cat 설치
↓
Connector 확인
↓
트레이 아이콘 고정
↓
시작 프로그램 등록핵심은 Agent Cat 자체를 계속 열어두는 것이 아니다.
메뉴바 또는 트레이에 항상 보이게 두는 것이다.
4. 첫 번째로 볼 것은 Token이 아니라 “상태”다
Agent를 사용하면서 가장 자주 확인하는 것은 의외로 Token이 아니다.
지금 일을 하고 있는가?이다.
예를 들어 Codex에게 꽤 큰 작업을 맡겼다.
현재 프로젝트의
네트워크 레이어를 분석해서
중복된 Request 처리를 정리하고
Test까지 추가해줘.Agent가 작업을 시작한다.
그동안 다른 일을 한다.
10분 뒤 돌아오면:
아직 돌고 있나?
끝났나?
멈췄나?부터 확인해야 한다.
Agent Cat에서는 활동 상태를 캐릭터 움직임으로 바로 볼 수 있다.
공식 구현에서는 CPU 사용률과 실행 가능한 Agent Process 수 등을 이용해 활동 점수를 만들고, 이를 캐릭터의 움직임 단계로 변환한다.
즉 캐릭터는 단순 장식이 아니라 Peripheral Awareness UI다.
화면 한쪽을 계속 보지 않아도 주변 시야로 Agent 상태를 파악할 수 있다.
5. 이게 Multi-Agent 환경에서 특히 편하다
예를 들어 이렇게 사용한다고 해보자.
Codex
→ Feature 구현
Claude Code
→ 다른 Repository 작업
Gemini CLI
→ 별도 CLI Task반드시 세 도구를 동시에 사용할 필요는 없다.
각각 독립적으로 사용해도 된다.
하지만 여러 Agent를 사용하는 개발 환경에서는:
Codex는 끝났고
Claude는 아직 돌고 있고
Gemini는 대기 중같은 상태를 Terminal을 하나씩 열어보지 않고 확인할 수 있다는 점이 꽤 편하다.
6. Agent를 많이 쓰기 시작하면 Token보다 “흐름”을 본다
처음 AI Coding Tool을 사용할 때는 이런 숫자가 신경 쓰인다.
오늘 Token 몇 개 썼지?하지만 조금 오래 사용하면 더 중요한 질문이 생긴다.
어디에 썼지?이다.
Agent Cat Home에서는 사용량을:
Provider
Model
Project
Date기준으로 나눠서 볼 수 있다.
그래서:
Token = 80M이라는 숫자 하나보다:
Project A 42M
Project B 21M
Experiment 12M
Others 5M처럼 보는 편이 훨씬 의미가 있다.
7. 프로젝트별 Token을 보는 습관이 좋다
예를 들어 한 달 동안 프로젝트가 세 개 있었다.
Mobile App
Internal Tool
PrototypeAgent Cat이 Directory 기준으로 사용량을 분리해 보여주면:
Mobile App
52%Internal Tool
18%Prototype
30%같은 흐름을 확인할 수 있다.
여기서 중요한 것은 비용만이 아니다.
이 데이터를 보면:
어느 프로젝트에서
AI Agent 활용도가 높은가?를 알 수 있다.
8. 프로젝트 Token이 갑자기 증가하면 이유를 찾는다
예를 들어 평소:
Mobile
Daily 1.5M수준이었는데 어느 날:
Daily 11M이 됐다.
단순히:
AI를 많이 썼네.하고 넘어가지 않는다.
다음 질문을 한다.
대규모 Refactoring 때문인가?
같은 Context를 반복해서 읽었나?
Retry가 많았나?
큰 Log를 반복해서 넣었나?
Agent가 Repository 전체를 계속 다시 분석했나?Agent Monitoring이 가치가 생기는 순간이다.
9. Agent Cat을 “비용 절약 앱”으로만 보면 아깝다
좋은 사용 방식은:
Token 많이 사용
↓
무조건 줄인다가 아니다.
예를 들어 Architecture Migration을 한 날 Token이 많이 나왔다면 자연스럽다.
반대로:
README 수정
↓
엄청난 Token 사용이라면 이상하다.
즉 중요한 것은:
Token
÷
작업 가치다.
Agent Cat은 이 판단을 하기 위한 데이터를 보여주는 역할을 한다.
10. Model별 사용량도 꽤 재미있는 지표다
Agent를 오래 사용하다 보면 예상과 실제 사용 패턴이 다르다.
예를 들어 느낌상:
Claude를 제일 많이 사용하는 것 같은데?라고 생각했는데 실제 30일 데이터를 보면:
Codex 58%
Claude 31%
Gemini 11%일 수도 있다.
또는 특정 프로젝트에서만 특정 Provider 사용량이 높을 수도 있다.
이런 데이터는 어떤 Agent가 더 좋다는 순위를 매기기 위한 것이 아니다.
어떤 업무에서 어떤 Tool을 실제로 선택하고 있는지 확인하는 자료다.
11. Model Routing을 데이터로 개선할 수도 있다
예를 들어 반복적으로 이런 패턴이 보인다.
작은 수정
→ Codex
Architecture 조사
→ Claude Code
CLI 분석
→ Gemini또는 완전히 다른 개인 패턴이 나타날 수도 있다.
그걸 보고 자신의 Agent Workflow를 정리한다.
Simple Task
→ 빠르게 처리Deep Analysis
→ 충분한 Context 허용Large Migration
→ 별도 Session이런 기준은 다른 사람의 추천보다 자신의 실제 데이터에서 만드는 편이 낫다.
12. 남은 한도는 꽤 중요한 UI다
Agent를 많이 사용하는 날 가장 난감한 상황 중 하나는:
중요한 작업을 시작했는데
중간에 사용 한도가 부족해지는 것이다.
Agent Cat은 Provider가 로컬 인증 상태나 Usage API 등을 통해 한도 정보를 노출하는 경우 남은 Quota와 Reset 정보를 표시한다.
중요한 점은 값이 없는 경우 추측하지 않는다는 것이다.
공식 Connector 설명에서도 Provider가 제공하는 값이 없는 경우 unavailable로 처리한다고 명시한다.
이런 태도가 모니터링 도구에서는 중요하다.
13. 작업 시작 전에 한도를 보는 습관을 만든다
예를 들어 오후에 큰 Refactoring이 예정되어 있다.
시작 전에 메뉴바를 열어본다.
Codex
5-hour quota 충분Claude
이번 Session 여유같은 상태를 확인한 후 Agent를 고른다.
이렇게 하면:
중요하지 않은 작업에서
한도를 먼저 소진하는 일을 줄일 수 있다.
14. Agent Cat의 Budget Cap도 활용할 만하다
무료 기능에서도 기본적인 한도 알림과 예산 Cap을 제공한다.
이를 단순히:
이번 달 $100 이상 금지로 사용하는 것보다,
개발 습관에 맞게 다음처럼 생각하면 좋다.
Experiment Budget
Production Budget
Side Project Budget처럼 프로젝트 기준으로 관리하는 것이다.
15. 개인적으로 가장 볼 만한 지표 중 하나는 Cache다
LLM 비용 최적화에서 Cache는 꽤 중요하다.
동일하거나 재사용 가능한 Context가 Cache에 적중하면 반복 계산 비용을 줄일 수 있다.
Agent Cat은 캐시 적중률과 절약 흐름을 확인할 수 있게 구성되어 있다.
예를 들어:
Project A
Cache Hit 65%인데:
Project B
Cache Hit 5%라면 왜 차이가 나는지 살펴볼 가치가 있다.
16. Cache Hit가 낮다면 Prompt만 고칠 문제는 아니다
원인은 여러 가지일 수 있다.
Task마다 Context 순서가 크게 바뀜
공통 Instruction이 자주 수정됨
Repository 전체를 계속 다시 읽음
Session이 지나치게 잘게 끊김
매번 다른 대형 Context를 구성일 수 있다.
즉 Cache 정보는:
비용 숫자라기보다
Agent Context가
얼마나 안정적으로 재사용되는지를 보는 지표로 사용할 수 있다.
17. 30일 Calendar는 개발 습관을 보여준다
Agent Cat은 최근 사용량을 일·주·월 흐름으로 볼 수 있다.
이걸 보면 의외로 자신의 작업 방식이 보인다.
예:
월요일
Agent 사용 낮음화~목
높음금요일
Review 위주또는:
밤 10~12시
Agent 사용 집중같은 패턴이 보인다.
단순한 통계처럼 보이지만 실제 Developer Workflow를 정리하는 데 도움이 된다.
18. 활동 Heatmap도 같은 방식으로 본다
요일 × 시간 데이터를 보면:
언제 Agent를 가장 많이 사용하는가?가 보인다.
예를 들어:
오전
직접 개발오후
Agent Task 병렬 실행저녁
Review같은 개인 패턴이 발견될 수 있다.
그러면 Workflow를 의도적으로 바꿀 수 있다.
19. Agent를 “기다리는 시간”에 다른 일을 하는 구조
Coding Agent가 주는 가장 큰 생산성 변화 중 하나는:
사람이 Agent 응답을
계속 보고 있을 필요가 없다.는 것이다.
좋은 Workflow는:
Task A
Agent에게 전달
↓
다른 작업
↓
Agent 상태 확인
↓
완료 시 Review다.
Agent Cat 같은 메뉴바 모니터는 여기서 상당히 잘 맞는다.
Terminal을 계속 들여다보지 않고도 상태를 볼 수 있기 때문이다.
20. 세련되게 쓰려면 “Agent Watching”을 줄여야 한다
나쁜 사용 패턴:
Agent에게 작업 요청
↓
Terminal 계속 바라봄
↓
한 줄 출력될 때마다 확인이렇게 쓰면 Agent를 사용하면서도 사람의 Attention은 계속 묶인다.
추천:
Agent Task 시작
↓
Agent Cat 상태 확인 가능
↓
IDE에서 다른 작업
↓
Agent 완료 확인
↓
Diff Review이다.
Agent를 사용해서 절약해야 하는 것은 Token보다 Attention일 때가 많다.
21. 가장 현실적인 개인 Agent Workflow
개인 개발자라면 다음 정도가 깔끔하다.
Morning
Agent Cat Home 확인↓
오늘 남은 Quota 확인↓
Coding Session↓
Agent에게 큰 작업 전달↓
메뉴바로 상태만 확인↓
작업 완료
Diff / Test Review↓
저녁
프로젝트별 Token 확인이 정도다.
매 순간 Dashboard를 볼 필요는 없다.
22. 아침에는 숫자 세 개만 보면 된다
복잡하게 볼 필요 없다.
남은 한도
이번 주 사용량
현재 실행 Agent이 세 가지 정도면 충분하다.
23. 작업 중에는 캐릭터만 본다
Agent가:
Sleeping이면 멈춰 있고,
Walking이면 비교적 가벼운 상태,
Running / Sprinting이면 활동량이 높은 상태로 볼 수 있다.
매번 Dashboard를 열 필요가 없다.
이게 메뉴바 UI의 장점이다.
24. 작업이 끝난 뒤에야 Dashboard를 본다
큰 작업을 완료한 후:
이번 Task가
얼마나 큰 Token을 사용했나?를 확인한다.
그리고 비슷한 Task와 비교한다.
예:
Feature A
2.3MFeature B
8.9M왜 차이가 났는지 생각해본다.
25. 여기서 Agent Workflow를 개선한다
만약 Feature B에서:
Repository 탐색 반복
Build Log 반복 투입
같은 Retry
긴 Session이 있었다면 다음 작업에서는 개선한다.
즉:
Agent Cat
↓
Observation
↓
Workflow 개선이다.
Agent Cat 자체가 Workflow를 자동으로 고쳐주는 것은 아니다.
사용 패턴을 볼 수 있게 해주는 것이 역할이다.
26. 그래서 Agent Cat을 이렇게 두는 게 가장 좋다
Coding Agent
= WorkerAGENTS.md / CLAUDE.md
= Working RulesTests / Build / CI
= VerificationAgent Cat
= Observability역할이 명확하다.
27. Agent Cat으로 Test 성공 여부를 판단하면 안 된다
중요한 구분이다.
Agent Cat에서:
Agent 활동 높음
Token 사용 많음
Process 실행 중이라고 해서 코드가 정상이라는 뜻은 아니다.
실제 검증은 여전히:
Compiler
Test
Lint
CI가 담당해야 한다.
Agent Cat은 에이전트 활동 모니터링 도구이지 코드 품질 검증 도구가 아니다.
28. 비용도 “추정값”이라는 점을 알아야 한다
공식 FAQ에 따르면 비용은 로컬 Log에서 읽은 Token 수에 공개된 모델 단가를 적용해 추정한다.
따라서:
Agent Cat Cost
=
공식 청구서라고 생각하면 안 된다.
실제 Billing과 정확히 일치하지 않을 수 있다.
용도는:
어디에서
얼마나
비용이 발생하고 있는지흐름을 보는 것이다.
이 정도가 적절하다.
29. Privacy 구조도 꽤 흥미롭다
Agent Monitoring Tool에서 가장 먼저 확인해야 할 질문은:
내 Prompt를 읽는가?
코드를 서버로 보내는가?다.
Agent Cat의 공개 Connector는 Local-first 구조를 사용한다.
공식 Repository 설명에 따르면:
Prompt Text
→ 저장하지 않음
Claude / Gemini Hook Payload
→ 저장 전 Sanitizing
Local Daemon
→ 127.0.0.1
Local Event Store
→ ~/.agentcat방식으로 동작한다.
공개 Connector 자체에서는 데이터를 서버로 업로드하지 않는다고 명시되어 있다.
30. Pro에서도 무엇이 동기화되는지 확인해야 한다
Agent Cat의 Pro/Agent Hub에서는 여러 장비의 사용량을 하나의 계정에서 볼 수 있다.
하지만 공식 설명상 서버에 묶이는 것은:
일별 요약
Project Label
Provider 흐름같은 집계 정보다.
반대로:
Prompt
Response
Code
전체 Path는 동기화하지 않는다고 안내한다.
Agent Tool을 회사 프로젝트에서 사용할 때는 이런 데이터 경계를 확인하는 습관이 중요하다.
31. 여러 Mac이나 Windows 머신을 쓴다면 Agent Hub가 재미있다
예를 들어:
MacBook
이동 작업Mac Studio
큰 Coding TaskWindows PC
Windows 프로젝트를 사용한다.
각 머신의 Agent 사용량을 따로 보면 전체 흐름을 파악하기 어렵다.
Agent Hub는 여러 장비의 요약 정보를 하나의 Home으로 모으는 방향이다.
32. 이런 구조가 된다
MacBook
Codex / Claude
│
Mac Studio
Codex
│
├──── Agent Hub
│
Windows
Gemini / Codex그리고 Home에서는:
Project
Provider
Daily Usage
Cost흐름을 합쳐서 본다.
여러 개발 머신을 사용하는 사람에게 특히 의미가 있다.
33. Team 기능은 개인 Dashboard의 확장이다
팀 단위가 되면 질문이 바뀐다.
개인:
이번 주에 Token 얼마나 썼지?팀:
어느 프로젝트가
Agent 사용량이 높은가?어떤 Provider를
팀에서 많이 사용하고 있는가?예산이 어디에서 증가하고 있는가?Agent Cat Team은 멤버별 Token·비용 Rollup, 프로젝트·Provider·Model 구성, 공유 리포트와 예산 알림을 제공하는 방향으로 구성돼 있다.
다만 이런 정보 역시 개인 평가용 KPI로 쓰기보다 팀의 Agent 운영 상태를 보는 Resource Metric으로 사용하는 편이 낫다.
34. Token 사용량으로 개발자를 평가하면 안 된다
예:
Developer A
100M TokenDeveloper B
20M Token라고 해서:
A가 AI를 5배 잘 활용한다.고 판단할 수 없다.
A는 같은 작업을 계속 Retry하고 있을 수도 있다.
B는 Skill이나 Script로 효율화했을 수도 있다.
Agent Cat을 사용할 때도 Token은:
Usage Metric이지
Productivity KPI가 아니다.
35. 대신 프로젝트 단위 질문을 한다
좋은 질문:
이 프로젝트에서
Agent 활용도가 왜 높은가?이 프로젝트의
Cache Hit가 왜 낮은가?최근 일주일간
사용량이 왜 증가했는가?큰 작업이 끝났는데
사용량이 정상화됐는가?이런 질문이 훨씬 의미 있다.
36. Agent Cat을 활용한 추천 Routine
실전에서는 이런 흐름이 가장 깔끔하다.
09:00 — 시작
Agent Cat
남은 Quota 확인↓
오늘 큰 Agent Task가 있는지 판단작업 시작
Codex / Claude Code / Gemini CLI
Task 실행↓
Agent Cat
실행 상태 확인작업 중
Terminal 감시 X
메뉴바 상태만 확인↓
다른 Coding / Review 작업Task 종료
Git Diff
Tests
Build검증.
저녁
Agent Cat Home
프로젝트별 사용량
Provider
Quota
Cache확인.
금요일
Weekly Report
↓
이번 주 Agent 사용 패턴 Review정도로 끝낸다.
이 정도면 Dashboard 자체를 관리하는 일이 새로운 업무가 되지 않는다.
37. Friday Review에서 보면 좋은 것
금요일에는 네 가지만 보면 충분하다.
1. 가장 많이 사용한 프로젝트2. 예상보다 Token이 많았던 작업3. Cache가 낮은 프로젝트4. Provider / Model 사용 흐름그리고 하나만 개선한다.
예:
다음 주부터
Build Log 전체를 Agent Context에 넣지 않는다.같은 식이다.
38. Agent Monitoring의 목적은 Agent를 덜 쓰는 것이 아니다
목적은:
Agent 사용량 최소화가 아니다.
더 좋은 목표는:
불필요한 Agent 실행 최소화다.
필요한 Architecture 분석에 5M Token을 쓰는 것은 괜찮다.
하지만 같은 Repository를 다섯 번 다시 분석해서 5M Token을 쓰는 것은 개선 대상이다.
39. Agent Cat과 가장 잘 맞는 개발 방식
Agent Cat은 특히 다음 방식에서 가치가 커진다.
Agent에게
작은 질문만 계속 하는 방식보다:
의미 있는 Task 단위로
Agent에게 일을 맡기는 방식이다.
예:
"이 함수 설명해줘."보다:
"Session Refresh Race Condition을 조사하고
원인을 특정한 뒤
수정안과 Test까지 만들어줘."처럼 Task Boundary가 명확하면 사용량과 결과를 연결하기 쉽다.
40. Task 단위로 Agent를 사용하면 Observability도 의미가 생긴다
Task A
3M Token
Task B
800K Token
Task C
12M Token이 데이터를 보고:
Task C는 왜 비쌌지?를 판단할 수 있다.
반대로 하루 종일 사소한 질문을 수백 개 던지면 사용량은 보여도 어떤 결과와 연결됐는지 판단하기 어렵다.
41. Agent Cat은 “AI를 쓰고 있다”를 시각화한다
이 앱의 캐릭터 UI가 재미있는 이유도 여기에 있다.
Agent 사용은 눈에 잘 보이지 않는다.
Background에서:
Search
Reasoning
Tool Call
Build가 계속 일어난다.
Agent Cat은 그 상태를:
잠듦
걷기
뛰기같은 단순한 시각 신호로 변환한다.
복잡한 Telemetry를 메뉴바 하나로 압축한 셈이다.
42. 이것이 꽤 좋은 Ambient UI다
모니터링 화면은 보통 사용자가 직접 찾아가야 한다.
Dashboard 열기
↓
Metric 확인하지만 Agent Cat은:
메뉴바
↓
상태가 계속 보임이다.
스마트워치의 Activity Ring이나 Mac의 배터리 아이콘처럼 자주 보지만 자세히 볼 필요는 없는 정보에 잘 맞는 UI다.
43. 귀여운 UI와 전문적인 Observability는 충돌하지 않는다
Agent Cat을 처음 보면:
고양이가 뛰어다니는 앱처럼 보인다.
하지만 실제 기능을 뜯어보면 상당히 개발자 도구답다.
Process Activity
CPU
Memory
Provider
Model
Token
Quota
Cost
Cache
Project
History가 중심이다.
그래서 재미있는 UI를 걷어내면 사실상:
Coding Agent Telemetry Dashboard에 가깝다.
44. Connector 구조도 개발자 입장에서는 볼 만하다
공개 Agent Cat Connector는 로컬에 작은 Collector와 Daemon을 설치한다.
기본 구조는:
Codex
Claude Code
Gemini CLI
│
▼
Agent Cat Connector
│
├─ Local Event Store
├─ Snapshot
└─ Local API
│
▼
Agent Cat이다.
Local Daemon은 127.0.0.1:8765에서 동작하고, Snapshot과 Event 정보는 ~/.agentcat 아래에 저장한다.
45. 개발자가 직접 Snapshot을 볼 수도 있다
공개 Connector에는 CLI가 있다.
예:
agentcat snapshot또는 Local API:
curl http://127.0.0.1:8765/v1/snapshot을 통해 Normalize된 상태를 확인할 수 있다.
즉 Agent Cat 앱 UI뿐 아니라 로컬 Agent Telemetry Layer 자체가 존재한다.
46. 이 부분은 Agent 자체에서도 활용할 수 있다
공개 Repository에는 Codex 스타일 Agent가:
현재 사용량을 추측하지 말고
agentcat snapshot --json을 호출하도록 알려주는 Skill도 포함돼 있다.
이 아이디어가 꽤 좋다.
Agent 자신이:
현재 한도가 얼마나 남았는지
어떤 Provider 사용량이 높은지를 추측하지 않고 로컬 Telemetry를 읽게 만들 수 있기 때문이다.
47. 조금 더 발전시키면 이런 Workflow도 가능하다
예:
큰 작업 시작↓
Agent Cat Snapshot↓
현재 Quota 확인↓
Agent 선택↓
Task 실행↓
작업 후 Usage 확인이다.
Agent Routing까지 자동화할 필요는 없지만, 실제 Usage를 보고 판단하는 구조가 된다는 점이 중요하다.
48. 설치 직후 추천 설정
처음 사용한다면 다음 정도만 해도 충분하다.
1.
메뉴바 / 트레이에 항상 표시2.
로그인 시 자동 실행3.
자주 사용하는 Agent 연결 확인4.
한도 알림 설정5.
프로젝트 이름 정리6.
일주일 정도 아무것도 최적화하지 않고 사용마지막 항목이 중요하다.
49. 처음부터 Token을 줄이지 않는다
처음 일주일은 데이터를 모은다.
어떤 Agent를 많이 쓰는지
어떤 프로젝트가 비싼지
언제 많이 사용하는지
Cache가 어떤지를 본다.
그다음 개선한다.
Monitoring은 항상:
Measure
↓
Understand
↓
Optimize순서가 좋다.
50. 이런 사람에게 특히 잘 맞는다
Codex나 Claude Code를
하루 종일 사용하는 개발자여러 프로젝트를
동시에 진행하는 개발자AI Coding 비용이
어디에서 발생하는지 궁금한 사람Agent 한도를 자주 소진하는 사람MacBook과 데스크톱 등
여러 개발 머신을 사용하는 사람에게 특히 맞는다.
51. 반대로 가끔 Agent를 쓰는 사람은?
한 달에 몇 번:
작은 코드 질문
간단한 Refactoring정도만 한다면 굳이 Usage Dashboard를 깊게 볼 필요는 없다.
그 경우에는 메뉴바에서:
Agent 실행 상태정도만 보는 것으로도 충분하다.
Monitoring Tool도 사용하는 복잡도보다 얻는 정보가 더 많아야 한다.
52. Free부터 시작해도 충분하다
현재 공식 안내 기준 Free에서는:
실시간 Provider / Model 상태
30일 History
주간 결산
기본 한도 알림
예산 Cap
마스코트등을 제공한다.
그래서 먼저 Free로 자신의 Agent 사용 패턴을 확인해보고:
여러 머신
프로젝트별 비용 분석
더 긴 Report
팀 집계가 필요해질 때 Pro나 Team을 검토하는 흐름이 자연스럽다.
53. Pro 가격도 확인해두자
현재 Agent Cat 사이트 기준 Personal Pro는:
월 $6.99
연 $59.99로 안내되어 있다.
가격이나 기능은 변경될 수 있으므로 실제 가입 전 공식 사이트를 다시 확인하는 것이 좋다.
54. 가장 세련된 Agent 사용법은 더 많은 Agent를 띄우는 게 아니다
AI Agent를 잘 쓴다고 하면 흔히:
Agent 5개 병렬 실행
Subagent 10개
Model 여러 개같은 모습을 떠올린다.
하지만 실제로 더 중요한 것은:
지금 무엇이 실행되고 있는지 알고
얼마나 사용하고 있는지 알고
어디에서 비용이 발생하는지 알고
필요 없는 반복을 줄이는 것이다.
즉 Agent의 수보다 Visibility가 먼저다.
55. 추천하는 최종 구조
개인 Coding Environment를 정리하면 이렇게 된다.
Developer
│
▼
Coding Agent 선택
│
┌──────────┼──────────┐
▼ ▼ ▼
Codex Claude Gemini
│ │ │
└──────────┼──────────┘
▼
Agent Cat
│
┌───────────┼───────────┐
▼ ▼ ▼
Status Usage Quota
│ │ │
├─ Model ├─ Token ├─ Reset
├─ CPU ├─ Cost └─ Limit
└─ Activity ├─ Cache
└─ Project
│
▼
Developer Review그리고 실제 코드 품질은 별도다.
Agent Cat
ObservabilityGit Diff
ReviewTest / Build / CI
Verification각각 역할을 나눈다.
56. 마무리
Coding Agent가 하나일 때는 Terminal만 보면 된다.
하지만 Agent가 일상적인 개발 환경의 일부가 되기 시작하면:
누가 돌고 있는지
얼마나 사용했는지
어디에 사용했는지
얼마나 남았는지를 보는 Layer가 필요해진다.
Agent Cat은 이 정보를 상당히 가볍게 풀어낸다.
복잡한 Monitoring Dashboard 대신 메뉴바에 작은 캐릭터 하나를 놓는다.
캐릭터가 뛰고 있으면 Agent가 일하고 있고,
조용히 누워 있으면 Agent도 쉬고 있다.
조금 더 보고 싶을 때 클릭하면:
Provider
Model
Token
Cost
Cache
Project
Quota
History가 열린다.
이 구조가 좋은 이유는 Monitoring 때문에 새로운 집중력을 요구하지 않는다는 데 있다.
Agent를 잘 사용하는 환경은:
Agent를 계속 지켜보는 환경이 아니라
Agent에게 일을 맡기고
필요할 때 상태만 확인하고
끝나면 결과를 검증하는 환경에 가깝다.
그래서 Agent Cat을 단순한 Token Counter보다 이렇게 보는 편이 더 정확하다.
Coding Agent가 Worker라면, Agent Cat은 그 Worker들이 어떻게 움직이고 있는지 보여주는 작은 Observability Layer다.
AI Coding이 점점 일상화될수록 중요한 것은 더 좋은 Prompt 하나가 아니라:
Task
Agent
Usage
Cost
Quota
Result를 하나의 개발 Workflow로 관리하는 능력일 수 있다.
그리고 그 시작은 생각보다 단순하다.
Codex나 Claude에게 일을 맡긴다.
↓
메뉴바 고양이는 뛰게 둔다.
↓
개발자는 다른 일을 한다.
↓
고양이가 쉬기 시작하면
Diff와 Test를 확인한다.Agent를 사용하는 동안 사람까지 Agent를 감시하느라 바쁠 필요는 없다.
그게 Agent Cat을 가장 세련되게 사용하는 방법이다.
참고 자료
-
Agent Cat 공식 사이트 — agentcat.app
macOS·Windows 지원, Codex·Claude Code·Gemini CLI 모니터링, 실시간 활동 상태, Token·비용·Cache·Project·Quota·History, Merlin 및 Agent Hub 기능에 대한 공식 설명. -
Agent Cat Connectors — GitHub
Agent Cat의 Local Connector 구조, 설치 파일, Local Daemon, Snapshot, Provider별 Usage·Quota 수집 방식과 Privacy 정책을 확인할 수 있다.
핵심 참고 포인트
Agent Cat은 Coding Agent 자체가 아니라 로컬 Coding Agent의 상태와 사용량을 관찰하는 도구다. 따라서 Codex·Claude Code·Gemini CLI를 Agent Cat 전용 방식으로 사용할 필요가 없고 기존 CLI Workflow를 유지한 채 Monitoring Layer만 추가하면 된다.
비용 표시는 Local Token 기록과 공개 Model 단가를 바탕으로 한 추정치이므로 실제 Provider 청구서와 완전히 같다고 가정하면 안 된다. 또한 남은 Quota 역시 Provider가 실제로 노출하는 정보를 우선하며 확인할 수 없는 값은 임의로 추측하지 않는 구조다.
공개 Connector는 Local-first 방식이며 Prompt·Response·Code 자체를 Monitoring하기보다 Token·Process·CPU·Quota 같은 Metadata를 중심으로 수집한다. 여러 기기를 묶는 Pro/Agent Hub에서도 공식 설명상 일별 집계와 Project Label 중심으로 동기화하며 Prompt·Response·Code·전체 Path는 서버로 보내지 않는 방향을 명시하고 있다.
따라서 가장 좋은 활용 방식은 Agent Cat을 계속 들여다보는 것이 아니라 평소에는 메뉴바의 활동 상태만 보고, 작업 전에는 Quota, 작업 후에는 Project·Token·Cache, 주말이나 주간 단위로는 History를 확인하는 가벼운 Agent Observability Routine을 만드는 것이다.
