Codex 사용량 모니터를 CLI와 Discord 알림으로 만든 이유
목차
그 날 팀이 모니터링 대시보드를 원했다. Codex 같은 대규모 도구의 사용량을 실시간으로 추적해야 한다는 요구였다. 숫자만 알아야 하는 게 아니라, 팀의 이목이 닿는 곳에서 바로 알림이 떴으면 했다. 그래서 만들었다: CLI 도구와 Discord 연동이 함께하는 사용량 모니터.
CLI와 Discord, 둘 다 필요했던 이유
처음엔 고민했다. "대시보드를 하나 만들까, 아니면 CLI 도구로 충분할까?" 생각해 보니 둘 다였다.
팀원들이 주기적으로 대시보드를 열어 볼 문화가 아니었기 때문이다. 대신 Discord 채널은 항상 열려 있었다. 거기서 알림을 받으면, 누군가는 당장 참고하고, 누군가는 나중에 재확인하고, 누군가는 그것만으로 충분하다. 그래서 Discord 알림은 필수였다.
그런데 "지금 정확한 수치가 뭔데?"라고 물어보는 엔지니어를 위해선 CLI가 필요했다. 빠르게 터미널에서 codex-usage 한 줄 쳐서 현황을 확인하는 게 훨씬 자연스럽기 때문이다. 그것도 가독성 있게.
이 과정에서 배운 게 있다. 관찰성(Observability) 도구를 하나만 고민하면 안 된다는 것. 팀의 일하는 방식, 정보 수집 패턴, 의사결정 속도를 모두 고려해야 한다.
| 채널 | 역할 | 타겟 |
|---|---|---|
| Discord 카드 | 정기적 공지, 이상 신호 감지 | 전체 팀, 빠른 인식 |
| CLI 조회 | 즉시 상세 정보 확인 | 당사자 엔지니어, 정밀 분석 |
파일 구조: 관심사의 분리
두 파일로 나눈 설계가 마음에 들었다.
codex-usage.py는 순수 로직이다. 데이터 수집, 집계, 포맷팅. CLI로도 쓸 수 있고, 다른 곳에서 import 해서 데이터 source로도 쓸 수 있다. 일종의 라이브러리처럼.
codex-usage-discord.py는 알림 레이어다. codex-usage의 데이터를 가져와서 Discord 메시지로 변환하고 전송한다. 여기가 변하더라도 (예: Slack으로 넘어간다 해도) 핵심 로직은 건드릴 일이 없다.
이런 식으로 나누면:
- 테스트하기 편하다 (codex-usage 로직만 단위 테스트 가능)
- 재사용이 쉽다 (다른 알림 채널이 생기면 codex-usage-other-platform.py 추가)
- 유지보수가 깔끔하다 (핵심과 전달 방식이 섞이지 않음)
# 개념적 의존성
codex-usage.py (데이터 수집/변환)
↓
codex-usage-discord.py (알림 전송)
이건 CLI/DevOps 스크립트 작성할 때 자주 마주하는 패턴이다. "핵심 로직"과 "인터페이스"를 분리하는 것. 단순한 원라이너 스크립트처럼 보이지만, 규모가 조금만 커지면 이 구분이 기술 부채를 줄여준다.
회고: 왜 이걸 지금 했나
팀 리딩 입장에서 보면, 이건 단순한 모니터링 도구가 아니었다. 투명성의 문제였다. 사용량이 누적되면서 "우리가 얼마나 쓰고 있는데?"라는 질문이 자연스럽게 나왔다. 그 질문에 대시보드 링크로 답하는 것보다, 팀이 이미 있는 채널에서 정보를 얻도록 설계하는 게 훨씬 효율적이었다.
또한 개발자로서 "정기적으로 이 수치를 추적해야 한다"고 느꼈을 때, 자동화 도구를 먼저 만드는 습관도 중요하다. 수작업으로 일주일에 한 번 물어봐서 답하는 것보다, 스크립트 두 개 (각각 100-200줄 정도)를 짜는 게 누적 시간으로는 훨씬 싸다.
이 글을 읽는 팀장들이라면: 팀이 자주 묻는 질문을 추적하자. 그게 자동화 후보일 가능성이 높다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.