들어가며
지난 글에서는 초기 창업 팀이 파편화된 AI 사용에서 벗어나기 위해 manifest.md와 YAML 기반의 명세서를 도입하고, 팀의 컨벤션에 맞게 Claude Code를 통제하는 '컨텍스트 엔지니어링' 과정을 공유했습니다.
그렇게 나름의 규칙을 세우고 매번 수정하며 '컨텍스트 엔지니어링 회고'를 진행하고 있습니다. 하지만 회고를 진행할 때마다 /resume 으로 대화 흐름을 보고 피드백하기를 반복하는 과정이 불편했고, 생산성을 위해 오히려 더 번거로운 일을 하는 것은 아닌가? 하는 의문이 들었습니다. 이 글은 claude code의 대화 내용을 웹으로 직접 보기위한 대시보드를 만들기까지의 회고 입니다.
1. 터미널 창을 벗어나고 싶다는 단순한 귀찮음
Claude Code는 기본적으로 CLI 기반으로 동작합니다. 그러다 보니 지난주 대화 기록을 보며 리뷰를 하려면 까만 터미널 창에서 마우스 휠을 한참 올리며 맥락을 파악해야 했습니다.
게다가 대화 효율을 측정할 수 있는 유일한 단서인 토큰 사용량은 그저 "제한량의 몇 %를 사용했다" 정도로만 표기되었습니다. 매 세션마다 이 퍼센티지를 따로 기록하고 추적하는 건 Agent 도입으로 얻은 생산성을 되려 깎아먹는다고 생각했습니다.
"터미널에 갇힌 대화 기록과 애매한 토큰 사용량을 웹에서 좀 편하게 볼 수 없을까?" 하는 개발자 같은 귀찮음과 불편함이 이 프로젝트의 시작이었습니다.
2. 백엔드 개발자의 Antigravity 찍어 먹어보기
저는 주로 Java와 Spring Boot 생태계에서 백엔드 개발을 해왔습니다. 그렇다 보니 Node.js 생태계나 IDE 환경에서 AI 에이전트가 코드를 직접 작성해 주는 워크플로우를 써볼 기회가 거의 없었습니다.
프론트엔드 개발하시는 분들이 Cursor로 편하게 작업하시는 걸 항상 부럽게만 생각했는데, 이렇게 아이디어가 나온 김에 저도 Antigravity를 써보고자 했습니다. 학생 신분이기 때문에 추가 과금이 필요 없었고, Opus도 제약적이게나마 사용할 수 있다는 점이 매력적이었습니다.
개발 자체는 수월했습니다. 대화 로그 포맷을 알려주고 룰을 잡아주니 에이전트가 훌륭하게 파싱 코드를 짜주었습니다.
생각보다 너무 빠르게 만들어줘서 놀랐습니다. 2시간도 걸리지 않고 만들었다는게 참 놀라웠습니다.
그런데 오히려 의외로 문제가 됐던 것이 '파일 경로'였습니다. 프로토타입을 만들자마자 지인에게 배포를 했었는데, 다른 PC에서는 .claude 폴더를 찾지 못해서 실행이 안 되는 이슈가 있었습니다. AI가 아무리 로직을 잘 짜준다고 한들, 결국 실행 환경을 제어하고 보장하는 것은 온전히 인간 개발자의 몫이라는 걸 다시금 깨달았던 순간이었습니다. (이 경로 문제는 어찌저찌 잘 해결했습니다.)
3. 컨텍스트가 짧으면 효율적인 걸까?
완성된 대시보드를 처음 로컬에 띄웠을 때, 대시보드에서 가장 먼저 보려고 했던 지표는 '컨텍스트의 크기'였습니다. 우리가 컨텍스트 엔지니어링을 잘했다면 불필요한 토큰 낭비가 줄었을 테니, 전체 컨텍스트 길이가 짧게 나올 것이라는 단순한 가설이었습니다.
하지만 데이터를 시각화해서 보다 보니 이 지표에 치명적인 허점이 있었습니다. Claude가 생성해 내는 결과물(Output) 역시 컨텍스트 길이에 포함된다는 사실이었습니다.
가령 AI가 요구사항을 한 번에 완벽하게 이해하고 수백 줄의 훌륭한 코드를 반환했다면 전체 컨텍스트 길이는 길어집니다. 길이는 길지만 효율은 좋은 상태죠. 반대로 대화는 짧게 끝났지만 엉뚱한 코드만 뱉어냈다면 수치상으로는 '효율적'인 것으로 오해할 수 있습니다.
결국 단순히 '숫자가 적다 = 효율적이다'라는 1차원적인 지표로는 이 복잡한 대화를 평가할 수 없다는 것을 깨달았습니다. 애매한 지표를 넣고 나니, 오히려 "우리가 진짜 집중해야 할 지표가 무엇인가?"를 다시 생각하게 된 경험이었습니다.
4. 점수표 대신 워크플로우 시각화하기
하지만 이 툴을 만든 원래의 목적은 충분히 달성하고 있었습니다. 바로 '시각화'입니다.
고심해서 만든 CLAUDE.md 문서에 적힌 대로 잘 로드되고 있는지, /feature나 /fix 같은 Skill들이 의도한 타이밍에 정확하게 워크플로우를 타고 작동하고 있는지. 이전에는 까만 터미널 창에서 ctrl + o를 눌러가며 일일이 확인해야 했던 것들을 이제는 대시보드를 통해 눈으로 직접 확인할 수 있게 되었습니다.
이 프로젝트는 무조건적인 효율을 숫자로 쾅 찍어주는 절대적인 평가 도구가 아닙니다. 그보다는 우리가 주입한 컨텍스트들이 대화 속에서 어떻게 흘러가는지 궤적을 보여주는 시각화 도구에 가깝습니다.
최근에는 Anthropic에서 공개한 Claude Skill Building Guide 를 보며 턴 수를 줄이거나, 자율적으로 실행하는 시간의 비율을 측정하는 방식으로 지표를 업데이트 해 나가고 있습니다. 하지만 정량적인 측정 방식이 상대적으로 효율을 대변하기에는 어렵다고 생각하여 의도한대로 동작하는지 판단하는 모니터링 용도에 초점을 두고 개발해 나가고자 합니다.
마치며
사실 이 프로젝트를 깃허브에 퍼블릭으로 공개하고 이 글을 쓰는 지금도 마음 한편에는 불안함과 머쓱함이 있습니다.
저는 AI 프롬프트 전문가도 아니고, 데이터를 전문적으로 공부해보지도 않은 그냥 대학생이기 때문입니다. 개발을 하다가 "이거 너무 불편한데?"라는 생각에 AI의 힘을 빌려 뚝딱 만들어본 툴입니다.
하지만 이 툴을 공개해보는 이유는, 저희 팀과 똑같은 고민을 하고 있을 누군가에게 작은 도움이 되길 바라기 때문입니다. AI 코딩 어시스턴트를 실무에 도입하며 "우리 팀, 지금 잘 쓰고 있는 걸까?" 막막해하던 분들이 계신다면, 이 툴을 통해 여러분의 대화 로그를 한 번쯤 시각화해 보시길 추천합니다.
긴 글 읽어주셔서 감사합니다!
🔗 GitHub - rootTiket/claude-analytics (직접 써보시고 많은 피드백을 남겨주시면 큰 힘이 될 것 같습니다!)
