저는 하나 이상의 AI 코딩 도구를 사용합니다.

하나의 작업은 Claude Code에서 시작되어, Codex를 거쳐, 몇몇 위임된 에이전트(agents)를 포함하고, 에디터에서의 수동 정리로 마무리될 수 있습니다.

결과적으로, 모든 도구는 저에게 토큰(tokens)이 사용되었다고 알려줄 수 있습니다.

하지만 그 어떤 도구도 제가 실제로 궁금해하는 질문에는 답할 수 없었습니다:

• 어떤 프로젝트가 토큰을 소비했는가?
• 어떤 세션(sessions)이 비용이 많이 들었는가?
• 비용이 많이 드는 모델이 더 나은 결과를 만들어냈는가?
• 특정 풀 리퀘스트(pull request)에 얼마나 많은 작업이 투입되었는가?
• 동일한 파일을 재시도하거나 재작업하는 데 얼마나 많은 비용이 들었는가?
• 나의 구독 플랜이 실제 사용량을 따라가고 있는가?
• 위임된 하위 에이전트(subagent) 세션에서는 어떤 일이 일어났는가?

이러한 질문 중 상당수에 답하기 위해 필요한 데이터는 이미 제 컴퓨터에 존재했습니다. 단지 JSONL 파일, SQLite 데이터베이스, 에디터 저장소, 에이전트 트랜스크립트(transcripts), 그리고 제공자별 캐시(caches)에 흩어져 있었을 뿐입니다.

그것이 CodeBurn이 되었습니다.

CodeBurn은 이러한 기존 세션 데이터를 읽어 데스크톱 애플리케이션, 터미널 대시보드(terminal dashboard), 로컬 웹 대시보드, CLI, 그리고 MCP 서버로 변환해주는 오픈 소스(open-source) 기반의 로컬 퍼스트(local-first) 도구입니다.

이 포스트는 데스크톱 앱과 각기 다른 화면들이 실제로 무엇에 유용한지에 초점을 맞춥니다.

CodeBurn desktop overview

개요(Overview) 화면은 개별 세션을 일일이 뒤져보기 전에 "무슨 일이 일어났는가?"에 대한 답을 주기 위한 것입니다.

사용 패턴의 형태부터 시작하세요

월간 API 청구서는 하나의 숫자일 뿐입니다. 그것은 어떻게 그런 비용이 발생했는지에 대해 거의 아무것도 알려주지 않습니다.

개요(Overview) 화면은 활동을 일별로 분류하여 다음을 보여줍니다:

• 총 예상 지출
• 세션 및 호출(calls) 횟수
• 모델 사용량
• 일일 변경 사항
• 비용이 많이 드는 세션
• 잠재적 낭비
• 최근 워크플로(workflow) 활동

비용이 많이 드는 세션 목록은 총액보다 훨씬 더 유용할 때가 많습니다.

평범한 하루에는 열 개의 작은 세션과, 예산의 대부분을 조용히 소모해 버린 단 한 번의 에이전트 실행(agent run)이 포함될 수 있습니다. 해당 세션을 즉시 확인하면 조사해야 할 구체적인 지점을 바로 파악할 수 있습니다.

이 지점은 또한 도구 간의 차이가 드러나는 곳이기도 합니다. 어떤 제공업체(provider)는 빠른 수정(quick fixes)을 저렴하게 처리하는 반면, 다른 업체는 더 긴 계획(planning)이나 리팩터링(refactoring) 세션에서 우위를 점하고 있다는 사실을 발견할 수도 있습니다.

세션 목록은 문맥(context)이 있을 때 더 유용합니다

AI coding sessions with project and cost context

세션(Sessions) 화면은 실제 에이전트 작업의 검색 가능한 기록입니다.

CodeBurn은 가공되지 않은 트랜스크립트 식별자(raw transcript identifiers)를 제시하는 대신, 다음과 같은 유용한 문맥(context)을 유지하려고 노력합니다:

• 세션 제목 (Session title)
• 프로젝트 (Project)
• 제공업체 (Provider)
• 사용된 모델 (Models used)
• 시작 및 종료 시간 (Start and end time)
• 턴(turn) 및 호출(call) 횟수 (Number of turns and calls)
• 예상 비용 (Estimated cost)

이는 개요(Overview) 페이지의 숫자가 의심스러울 때 도움이 됩니다.

만약 화요일의 비용이 유난히 높았다면, 일일 총액에서 해당 비용을 발생시킨 세션으로 바로 이동할 수 있습니다. 거기에서 실제로 규모가 큰 구현 작업인지, 아니면 반복 작업에 빠져버린 짧은 작업이었는지를 구분할 수 있습니다.

목표는 단순히 비용이 많이 들었다는 이유로 세션을 판단하는 것이 아닙니다. 어떤 어려운 작업들은 비용이 많이 드는 것이 당연합니다. 유용한 부분은 비용을 실제 작업과 연결할 수 있다는 점입니다.

풀 리퀘스트(pull requests)에 에이전트 작업 할당하기

제가 가장 원했던 기능은 풀 리퀘스트(pull-request) 귀속(attribution) 기능이었습니다.

Pull request spend with models and agent runs

풀 리퀘스트(Pull Requests) 화면은 작업이 발생한 PR을 중심으로 작업을 그룹화합니다.

각 풀 리퀘스트에 대해 다음을 보여줄 수 있습니다:

• 귀속된 지출 (Attributed spend)
• 사용된 모델 (Models used)
• 연결된 세션 (Linked sessions)
• API 호출 (API calls)
• 활성 날짜 (Active dates)
• 작업 카테고리 분류 (Work-category breakdown)
• 위임된 서브 에이전트 실행 (Delegated subagent runs)

에이전트가 작업을 위임할 때 이 점이 흥미로워집니다.

부모 세션(Parent session)이 오케스트레이션 (Orchestration)을 위해 하나의 모델을 사용하는 동안, 여러 서브 에이전트 (Subagents)가 조사, 테스트 또는 구현을 위해 다른 모델들을 사용할 수 있습니다. 부모 세션만 살펴보면 PR (Pull Request) 비용이 실제보다 저렴해 보이고, 대부분의 작업을 수행한 모델들이 숨겨지게 됩니다.

CodeBurn은 연결된 서브 에이전트의 활동을 이를 실행한 부모 턴 (Parent turn)에 통합합니다. 중첩된 에이전트 실행 (Nested agent runs)도 포함되며, 동일한 작업이 중복 계산되지 않도록 안전 장치가 마련되어 있습니다.

기여도 산정 (Attribution)은 턴 (Turn) 단위로 이루어집니다. 하나의 긴 세션이 여러 PR에서 작업하는 경우, 전체 세션 비용을 모든 PR에 청구하는 대신 각 턴을 해당 작업이 진행 중이었던 PR과 연관시킵니다.

또한 충분한 로컬 Git 및 세션 컨텍스트 (Context)가 존재하는 경우, 서로 다른 제공자(Cross-provider) 간의 작업도 상관 관계를 분석합니다. 이는 한 도구가 작업을 시작하고 다른 도구가 동일한 리포지토리에서 작업을 이어갈 때 중요합니다.

그 결과, "이번 달 AI 비용은 얼마인가?"라는 질문보다 훨씬 더 유용한 질문을 던질 수 있게 됩니다.

그 질문은 다음과 같습니다:

이 변경 사항에 대한 AI 지원 작업에는 실제로 어떤 과정이 포함되었는가?

지출은 모델에 관한 것만이 아닙니다

AI coding spend broken down by project and activity

지출 (Spend) 뷰는 다음과 같은 여러 가지 관점을 제공합니다:

• 프로젝트 (Projects)
• 활동 카테고리 (Activity categories)
• 도구 (Tools)
• MCP 서버 (MCP servers)
• 서브 에이전트 (Subagents)
• 모델-프로젝트 흐름 (Model-to-project flow)

이러한 세부 분류는 모델 전용 보고서가 놓치는 패턴을 드러냅니다.

예를 들어, 어떤 프로젝트가 비용이 많이 드는 이유는 실제로 대부분의 작업이 그 프로젝트에 집중되어 있기 때문일 수 있습니다. 하지만 에이전트가 반복적으로 리포지토리를 검색하거나, 실패하는 명령어를 실행하거나, 동일한 파일을 다시 방문하기 때문에 비용이 많이 들 수도 있습니다.

도구(Tool) 및 MCP(Model Context Protocol) 분석을 통해 에이전트가 작업에 어떻게 접근하는지도 파악할 수 있습니다. 토큰 총량이 비슷한 두 세션이라도 매우 다른 워크플로(Workflow)를 나타낼 수 있습니다. 하나는 대부분의 시간을 편집(Editing)과 테스트(Testing)에 소비하는 반면, 다른 하나는 검색(Searching)과 컨텍스트(Context) 재독해에 시간을 보낼 수 있습니다.

품질을 추측하는 대신 재시도(Retry)를 측정하세요

비용만으로는 모델이 효과적이었는지 알 수 없습니다.

CodeBurn은 작업을 코딩(Coding), 디버깅(Debugging), 테스트(Testing), 계획(Planning), 문서화(Documentation), 리뷰(Review), 리서치(Research) 등의 카테고리로 분류합니다. 편집 중심의 작업의 경우, 파일 인지 재시도 사이클(File-aware retry cycles)도 추적합니다.

재시도(Retry)는 단순히 "에이전트가 Edit 도구를 두 번 사용했다"는 의미가 아닙니다.

그것은 다음과 같은 패턴에 더 가깝습니다:

1. 파일 편집 (Edit a file)
2. 명령어 실행 (Run a command)
3. 동일한 파일로 복귀 (Return to the same file)
4. 다시 편집 (Edit it again)

구현 과정에서 여러 다른 파일을 편집하는 것은 정상입니다. 하지만 검증 실패 후 동일한 파일로 반복해서 돌아오는 것은 첫 번째 시도가 성공하지 못했다는 더 강력한 신호입니다.

이를 통해 CodeBurn은 원샷 비율(One-shot rate), 즉 추가적인 수정 사이클 없이 편집이 성공하는 빈도를 계산할 수 있습니다.

이것이 완벽한 소프트웨어 품질 지표는 아닙니다. 하지만 워크플로 신호(Workflow signal)입니다.

그리고 이는 단순히 토큰 가격을 비교하는 것보다 모델 비교를 훨씬 더 의미 있게 만들어 줍니다.

수행한 작업을 사용하여 모델을 비교하세요

Model usage and task performance comparison

Models 및 Compare 화면은 다음과 같은 질문에 답을 제공합니다:

• 어떤 모델이 가장 자주 사용되는가?
• 어떤 작업에 모델들이 사용되고 있는가?
• 세션당 평균 비용은 얼마인가?
• 재시도 없이 편집이 성공하는 빈도는 어느 정도인가?
• 저렴한 모델이 수정 사이클을 거친 후에도 실제로 더 저렴한가?
• 비싼 모델이 더 작은 모델로도 충분히 처리할 수 있는 작업에 사용되고 있는가?

이 지점에서 저는 종종 가장 실질적인 변화를 발견하곤 합니다.

결론은 결코 “항상 가장 저렴한 모델을 사용하라”거나 “항상 가장 강력한 모델을 사용하라”가 아닙니다.

대개는 다음과 같이 더 구체적인 내용입니다:

• 이 모델은 문서화(Documentation)에는 괜찮지만, 디버깅(Debugging)에는 어려움을 겪습니다.
• 이 비싼 모델이 단순한 수정 작업에 사용되고 있습니다.
• 이 더 저렴한 모델은 절약된 비용이 사라질 정도로 충분한 재시도(Retries)가 필요합니다.
• 계획(Planning)은 저렴하지만, 구현(Implementation)에서 대부분의 비용이 발생합니다.

이것은 모델을 선택하거나 라우팅 규칙(Routing rules)을 설정할 때 활용할 수 있는 정보입니다.

살아남지 못한 작업 찾기

Optimize 화면은 재작업된 파일, 되돌려지거나(Reverted) 중단된 변경 사항을 포함하여 피할 수 있었던 작업의 징후를 찾습니다.

이는 마법 같은 최적화 점수라기보다는 의도적으로 증거로서 제시됩니다.

되돌려진 편집이 자동으로 낭비인 것은 아닙니다. 개발자들은 아이디어를 탐색하고, 대안을 테스트하며, 의도적으로 작업을 폐기하기도 합니다. 하지만 반복되는 패턴은 여전히 유용할 수 있습니다:

• 동일한 파일이 여러 번 다시 작성됨
• 비용이 많이 드는 세션이 대부분의 변경 사항이 되돌려진 채 종료됨
• 특정 모델이 특정 작업 범주에서 반복적으로 실패함
• 상당한 지출이 최종 결과에 도달하지 못함

이 화면은 여러분이 조사할 수 있는 지점들을 제공합니다. 해당 작업이 필요했는지 여부는 여러분이 결정합니다.

구독 속도 추적하기

많은 개발자가 더 이상 API 토큰당 비용만 지불하지 않습니다. 우리는 Claude, ChatGPT, Cursor 및 기타 구독 플랜(Subscription plans)도 사용합니다.

Plans 화면을 통해 제공업체별 월간 플랜을 구성하고 사용량을 비용과 비교할 수 있습니다.

이 기능은 제공업체의 숨겨진 제한 사항을 안다고 자처하지 않습니다. 벤더(Vendors)들은 일반적으로 소비자용 구독에 대한 정확한 토큰 허용량을 공개하지 않습니다.

대신, 다음과 같은 더 간단한 질문에 답하는 데 도움을 줍니다:

내가 이 도구들을 사용하는 방식을 바탕으로 볼 때, 이 구독이 여전히 나에게 합리적인가?

이 앱은 별도의 CLI 설치를 요구하지 않습니다

패키징된 데스크톱 앱에는 자체 CodeBurn CLI가 포함되어 있습니다.

Electron 프로세스는 해당 번들된 CLI를 사용하여 로컬 데이터를 파싱(Parse)하고 집계(Aggregate)합니다. 데스크톱 인터페이스를 위해 구성해야 할 데몬(Daemon)이나 로컬 HTTP 서버도 필요하지 않습니다.

이 애플리케이션은 다음 환경에서 사용할 수 있습니다:

• Apple Silicon 기반 macOS
• Intel 기반 macOS
• Windows
• AppImage 또는 Debian 패키지 형태의 Linux

데스크톱 릴리스(Release)에서 다운로드할 수 있습니다:

https://github.com/getagentseal/codeburn/releases/tag/desktop-v0.9.19

소스 코드는 여기에 있습니다:

https://github.com/getagentseal/codeburn

여기서 "로컬 우선 (local-first)"의 의미

CodeBurn은 지원되는 도구들에 의해 생성된 파일과 데이터베이스로부터 세션 데이터를 직접 읽습니다.

제공자(Provider)에 따라 다음 항목들이 포함될 수 있습니다:

• JSON 또는 JSONL 트랜스크립트 (Transcripts)
• SQLite 데이터베이스
• 에디터 워크스페이스 저장소 (Editor workspace storage)
• 토큰 수 이벤트 (Token-count events)
• 도구 호출 기록 (Tool-call records)
• Git 브랜치 및 작업 디렉토리 (Working directories)

AI 호출을 프록시(Proxy)나 래퍼(Wrapper)를 통해 라우팅할 필요가 없습니다. 또한 기존의 로컬 세션을 분석하기 위해 제공자의 API 키를 요구하지도 않습니다.

가격 데이터는 LiteLLM에서 가져와 로컬에 캐싱(Caching)됩니다. 제공자가 정확한 토큰 수를 노출하는 경우 CodeBurn은 이를 사용합니다. 그렇지 않은 경우 결과는 추정치일 수 있습니다.

이러한 차이는 중요합니다.

한계점은 분명히 존재합니다

이러한 종류의 도구는 기반이 되는 데이터만큼만 정확합니다.

제공자마다 노출하는 세부 정보의 수준이 다릅니다:

• 일부는 정확한 입력, 출력 및 캐시 토큰 수를 저장합니다.
• 일부는 누적 카운터(Cumulative counters)만 저장합니다.
• 일부는 메시지 내용으로부터 토큰 추정이 필요합니다.
• 일부는 파일 작업은 노출하지만 정밀한 모델 사용량은 노출하지 않습니다.
• 일부는 PR 귀속(Attribution)을 위한 충분한 Git 컨텍스트를 유지하지 않습니다.
• 로컬 모델 및 프록시는 커스텀 가격 규칙이 필요할 수 있습니다.

CodeBurn은 모든 숫자를 동일하게 정밀한 것처럼 제시하는 대신, 이러한 사례들을 명시적으로 나타내려고 노력합니다.