흩어진 AI 개발 로그를 한곳으로: agentsview로 검색, 비용 확인, 회고하기

AI 코딩 에이전트 (AI Coding Agent)란 Claude Code, Codex, Cursor, Gemini CLI와 같이 코드 조사, 수정, 생성, 명령 실행을 도와주는 개발용 AI 도구를 말합니다.

처음 사용하기 시작할 때는 그저 편리합니다. 에러의 원인을 조사하고, 수정안을 제안받고, 설계를 상담하고, 다른 방안을 시도합니다. 하지만 한동안 사용하다 보면 다른 문제가 발생합니다.

"그 에러, 분명 전에도 조사했는데 찾을 수가 없어", "어떤 에이전트에게 맡긴 작업인지 기억이 안 나", "지난달 AI 이용 비용이 왜 늘었는지 설명하기 어려워". 이는 AI의 답변 품질만의 문제가 아닙니다. 작업 로그가 저장되는 위치가 도구마다 제각각이라는 점도 큽니다.

agentsview는 흩어진 로그를 모아서 나중에 읽을 수 있고, 검색할 수 있으며, 집계할 수 있는 형태로 만드는 도구입니다.

공식 사이트와 README에서는 단일 바이너리와 Web UI, 계정 불필요, 로컬 SQLite 저장, 전체 텍스트 검색, 비용 추적을 주요 기능으로 설명하고 있습니다 (AgentsView, GitHub README).

읽으면 알 수 있는 것	내용
어떤 도구인가	여러 AI coding agent의 세션 로그를 SQLite로 집약함
...

agentsview는 흩어진 AI 에이전트의 작업 로그를 검색, 비용 확인, 분석, 공유로 연결한다.

왜 지금 작업 로그가 문제가 되는가

개발 이력을 남기는 메커니즘 자체는 예전부터 있었습니다. **Git에는 커밋 히스토리 (Commit History)**가 있습니다. GitHub나 GitLab에는 issue, pull request, review comment가 있습니다. 터미널에는 shell history가 있고, CI에는 build log가 있습니다. 개발 팀은 줄곧 작업 결과뿐만 아니라 중간 과정의 기록에도 의존해 왔습니다.

다만 각각의 역할이 다릅니다. Git은 최종적인 차분(diff)을 남깁니다. issue는 논의나 의사결정을 남깁니다. CI log는 기계적인 실행 결과를 남깁니다. 여기에 AI 코딩 에이전트가 들어오면 조사, 가설, 실패, 수정안, 명령 실행, 모델에 대한 지시가 하나의 대화 로그에 뒤섞입니다. 게다가 그 로그는 도구마다 서로 다른 장소에 저장됩니다.

이러한 흐름이 강해진 것은 2021년 무렵부터입니다. GitHub는 2021년에 GitHub Copilot을 technical preview로 발표하며, 에디터 내에서 행이나 함수를 제안하는 "AI pair programmer"라고 설명했습니다. 같은 해, OpenAI는 자연어를 코드로 변환하는 OpenAI Codex를 API의 private beta로 공개했습니다.

당시의 중심은 자동 완성(Autocomplete)이나 코드 생성(Code Generation)이었습니다. 지금의 coding agent는 조금 더 깊이 파고듭니다. 코드베이스를 읽고, 파일을 편집하며, 명령을 실행하고, 개발 도구와도 연동합니다. Anthropic도 Claude Code를 코드베이스를 읽고, 파일을 편집하며, 명령을 실행하는 agentic coding tool이라고 설명하고 있습니다.

그렇게 되면 로그의 의미도 변합니다. 과거의 autocomplete라면 "나온 제안을 채택했는가"가 주요 관심사였습니다. 지금의 에이전트에서는 **"왜 그 수정에 이르게 되었는가", "어떤 명령을 실행했는가", "어떤 실패를 거쳤는가", "토큰을 얼마나 사용했는가"**까지 나중에 중요하게 작용합니다. agentsview가 다루는 것은 바로 이러한 새로운 종류의 개발 이력입니다.

agentsview는 무엇을 하고 있는가

AI 코딩 에이전트는 대화나 실행 이력을 단말기 내의 특정 디렉토리에 저장합니다. Claude Code에는 Claude Code의 저장 위치가 있고, Codex에는 Codex의 저장 위치가 있습니다. 형식도 JSONL, SQLite, JSON 등으로 나뉩니다.

agentsview는 이러한 저장 위치를 탐지하고, 파일을 읽어 들여, 공통된 형태로 통일하여 SQLite에 저장합니다. SQLite는 경량 데이터베이스입니다. 별도의 서버를 세우지 않아도 하나의 파일로서 로컬에 데이터를 가질 수 있습니다. 공식 사이트에서도 agentsview를 "과거의 AI coding session을 열람, 검색, 분석하는 local-first desktop and web app"이라고 설명하고 있습니다 (AgentsView).

지원 범위는 Claude Code뿐만이 아닙니다. Configuration의 Session Discovery에는 Claude Code, Codex, Copilot CLI, Cursor, Gemini CLI, OpenCode, Pi 등 여러 에이전트(Agent)의 저장 위치와 파일 형식이 나열되어 있습니다.

처리 흐름은 대략 다음과 같습니다.

각 에이전트의 세션 디렉터리(Session Directory)를 탐지한다
JSONL, SQLite, JSON 등의 형식을 읽어 들인다
메시지, 도구 호출(Tool Call), 토큰 사용량을 SQLite에 저장한다
FTS5를 통한 전문 검색(Full-Text Search), REST API, SSE, Svelte 기반의 Web UI로 볼 수 있게 한다
필요하다면 PostgreSQL이나 DuckDB로 동기화한다

FTS5는 SQLite의 전문 검색(Full-Text Search) 기능입니다. 대량의 메시지에서 함수 이름, 에러 메시지, 설계 메모와 같은 문자열을 찾는 용도에 적합합니다. REST API는 외부 프로그램에서 데이터를 다루기 위한 API이며, SSE는 서버에서 브라우저로 업데이트를 흘려보내는 메커니즘입니다.

세세한 기술명을 모두 외울 필요는 없습니다. agentsview는 로컬의 대화 로그를 검색하기 쉬운 데이터베이스로 변환하여, 브라우저와 CLI에서 사용할 수 있게 해주는 도구입니다.

용어	이 기사에서의 의미
SQLite	로컬에 둘 수 있는 경량 데이터베이스
...

과거의 AI 작업을 검색할 수 있다

AI 에이전트와의 대화에는 조사, 설계 판단, 실패한 시도, 수정 방침, 명령 실행 경위가 남습니다. 문제는 나중에 필요해졌을 때 찾기가 어렵다는 점입니다.

agentsview는 메시지 본문을 전문 검색(Full-Text Search)할 수 있습니다. 공식 사이트에서도 특정 함수, 에러 메시지, 설계 판단을 포함하는 대화를 찾을 수 있다고 설명하고 있습니다 (AgentsView).

예를 들어, 이전에 조사했던 에러를 찾을 수 있습니다. 설계 판단의 경위도 확인할 수 있습니다. 실패했던 구현 방침을 반복하지 않게 될지도 모릅니다. 다른 프로젝트에서 사용했던 절차나 프롬프트(Prompt)를 파헤쳐 보는 방식으로도 사용할 수 있습니다.

로그는 남아 있는 것만으로는 별로 도움이 되지 않습니다. 필요할 때 찾을 수 있는 상태가 되어야 비로소 개발의 자산이 됩니다.

여러 에이전트의 이력을 한곳에서 볼 수 있다

AI 코딩에서는 용도에 따라 여러 도구를 나누어 사용하는 경우가 있습니다. 큰 수정은 Claude Code, IDE 내에서의 상담은 Cursor, CLI를 통한 구현은 Codex, 다른 관점의 조사는 Gemini CLI와 같은 방식입니다.

이러한 운용 방식에서는 이력도, 비용도, 성과도 도구별로 나뉩니다. agentsview는 여러 에이전트의 세션을 동일한 데이터베이스에 모으기 때문에 작업 전체를 조망하기 쉬워집니다.

단순히 로그 목록을 보고 싶은 것이 아닙니다. 어떤 프로젝트에서 어떤 에이전트를 많이 사용하고 있는지, 길어지기 쉬운 세션은 무엇인지, 비용의 주된 원인이 모델인지, 프로젝트인지, 아니면 에이전트인지, 자동 실행이나 짧은 시도가 분석 노이즈가 되고 있지는 않은지 등 이러한 질문들을 추적하기 쉬워집니다.

공식 사이트에서는 27종류의 AI coding agent를 지원한다고 설명하고 있습니다. 각 agent의 탐지 방법은 Configuration에 정리되어 있습니다. 여러 도구를 병행해서 사용하고 있다면, 일원화하는 것만으로도 상당히 도움이 됩니다.

토큰 사용량과 비용을 설명할 수 있다

AI 에이전트는 편리하지만, 비용이 눈에 보이지 않는 채로 늘어나기 쉬운 도구입니다. 특히 여러 모델이나 여러 에이전트를 사용하면 어떤 작업이 지출을 높이고 있는지 파악하기 어려워집니다.

agentsview는 지원되는 에이전트의 세션으로부터 토큰(Token) 사용량을 가져옵니다. 토큰이란 LLM이 문장을 처리할 때 사용하는 단위입니다. 일본어의 '글자'와 완전히 일치하지는 않지만, 입력이나 출력이 많을수록 토큰 수도 늘어나고 요금도 늘어난다고 생각하면 충분합니다.

CLI에서는 agentsview usage daily나 agentsview usage statusline

사용할 수 있습니다 (CLI Reference). Token Usage & Costs에 따르면, Usage 대시보드에는 summary cards, cost trend, cost attribution, top sessions by cost, cache efficiency가 준비되어 있습니다. 비용 계산은 message row에 저장된 token usage와 model_pricing table을 사용하며, 가격 정보는 LiteLLM catalog에서 가져오고, 실패 시에는 embedded fallback을 사용한다고 설명되어 있습니다.

예를 들어, 다음과 같은 사항들을 확인하기 쉬워집니다.

확인하고 싶은 것	agentsview에서 보는 관점
어느 날에 비용이 증가했는가	일일 usage summary
...

작업 패턴을 회고할 수 있음

agentsview는 세션 목록(session list), 메시지 뷰어(message viewer), 액티비티 히트맵(activity heatmap), 도구 사용 현황(tool usage), velocity, 세션 상태(session health) 등을 제공합니다. Quick Start에서도 session list, message viewer, session intelligence, full-text search, analytics, session export를 볼 수 있다고 설명되어 있습니다.

이를 통해 AI 에이전트 이용을 단순히 그 자리의 채팅으로 끝내지 않고, 개발 프로세스로서 회고할 수 있습니다. 너무 긴 세션을 분리하기, 도구 호출은 많은데 성과가 미미한 작업을 찾아내기, 자동화된 세션을 제외하고 인간이 관여한 작업만 보기, 일간 또는 주간 단위로 무엇이 진행되었는지 요약하기 등이 가능합니다.

사소해 보일 수 있지만, 에이전트 이용 습관이나 병목 지점을 파악하는 것만으로도 다음 사용 방식이 달라집니다.

Session Insights를 사용하면 로컬 agent CLI를 통해 일일 요약이나 에이전트 분석도 생성할 수 있습니다. 단, 이 기능에서는 AgentsView가 세션 DB로부터 markdown prompt를 만들어 Claude, Codex, Copilot, Gemini, Kiro 등의 CLI에 전달한다고 설명되어 있습니다. 로컬 저장의 기본 설계와 AI 요약 시의 데이터 흐름은 분리해서 생각해야 합니다.

실제로 CLI를 격리 환경에서 실행해 보기

여기서부터는 실제로 직접 테스트해 본 내용입니다. '로컬 퍼스트 (Local-first)'라고 불리는 것이 CLI에서는 어떻게 보이는지 확인하기 위해, 기존 AI 세션을 읽히지 않고 빈 디렉토리만 보여주는 형태로 agentsview sync를 실행했습니다.

처음에 약간의 시행착오가 있었습니다. AGENTSVIEW_DATA_DIR만 변경해서는 검증 환경으로서 불충분했습니다. 데이터베이스 저장 위치는 바뀌지만, 각 에이전트의 기본 디렉토리 탐색 기능은 남아 있을 수 있기 때문입니다. 그래서 HOME 역시 임시 디렉토리로 지정하고, 대응하는 agent directory 환경 변수들을 모두 빈 검증용 디렉토리로 향하게 설정했습니다.

항목	이번 설정
agentsview	`v0.32.1`
검증 방침	기존 세션을 읽히지 않음
`HOME`	임시 디렉토리로 변경
`AGENTSVIEW_DATA_DIR`	검증용 빈 디렉토리로 변경
agent discovery roots	Claude, Codex, Copilot 등을 빈 디렉토리로 변경

mkdir -p experiments/agentsview-zenn-smoke-isolated/{home,data,empty/claude,empty/codex,empty/copilot}
HOME="$PWD/experiments/agentsview-zenn-smoke-isolated/home" \
AGENTSVIEW_DATA_DIR="$PWD/experiments/agentsview-zenn-smoke-isolated/data" \
...

실행한 버전은 다음과 같습니다.

agentsview v0.32.1 (commit 1964e4f, built 2026-06-05T19:05:25Z)

빈 검증 환경에서 sync는 1ms 만에 완료되었습니다. 세션과 메시지는 0건입니다.

Sync complete: 0 sessions synced in 1ms
데이터베이스: 0 sessions, 0 messages

Sync complete: 0 sessions synced in 1ms
Database: 0 sessions, 0 messages

그럼에도 불구하고, AGENTSVIEW_DATA_DIR에는 SQLite DB와 설정 파일이 생성됩니다.

data/daemon.lock
data/sessions.db
data/debug.log
...

sqlite3로 내부를 확인해 보니, 비어 있는 상태에서도 sessions, messages, tool_calls, model_pricing, messages_fts 등의 테이블이 생성되어 있었습니다. 먼저 스키마를 만든 후, 나중에 각 에이전트의 세션을 가져오는 구조입니다. 이는 이해하기 쉬운 방식입니다.

sqlite3 experiments/agentsview-zenn-smoke-isolated/data/sessions.db '.tables'

usage daily 또한 비어 있는 상태로 동작하며, 비용은 0으로 표시되었습니다.

TOTAL 0 0 0 0 $0.00

이 작은 검증을 통해 알 수 있는 점은 두 가지입니다. 첫째, agentsview는 CLI만으로도 초기화, 동기화, 사용량 표시까지 확인할 수 있습니다. 둘째, 검증이나 데모에서 기존 로그를 읽게 하고 싶지 않다면, 저장 위치뿐만 아니라 탐색 원천(source)도 격리하는 것이 좋다는 점입니다. 기사용 스크린샷 촬영이나 팀 내 데모를 진행할 때는 이 점을 유의하면 불필요한 로그를 포함하지 않을 수 있습니다.

로컬 퍼스트(Local-first)로 시도하기 쉬움

agentsview는 기본적으로 로컬 SQLite에 저장하며, Web UI도 127.0.0.1에 바인딩됩니다. Quick Start에는 데스크톱 앱, pip / uvx, shell script, Windows PowerShell, Docker, source build 설치 방법이 안내되어 있습니다. README에서도 "One binary, no accounts, everything local"이라고 설명하고 있습니다 (GitHub README).

이러한 특성은 개발 로그를 외부 SaaS에 노출하고 싶지 않은 경우에 적합합니다. 또한 개인 환경에서 먼저 테스트하고 싶을 때도 유용합니다. 기존 로컬 세션을 그대로 읽거나, CLI만으로 비용을 집계하거나, Docker로 명시적으로 마운트한 범위 내에서만 읽게 하는 등의 방식으로 사용할 수 있습니다.

단, 로컬 퍼스트가 "아무것도 하지 않아도 안전하다"는 의미는 아닙니다. Remote Access의 경우, 외부 단말에서 UI를 사용하려면 non-loopback bind 또는 proxy와 bearer token auth가 필요하다고 설명합니다. Host header validation, --public-url, trusted origins, Caddy proxy, CIDR allowlist 등도 remote access 시 고려해야 할 논점입니다.

팀 공유 및 다중 단말 운용으로 확장 가능

개인 이용 시에는 SQLite가 중심이지만, agentsview는 PostgreSQL로의 단방향 동기화 기능도 갖추고 있습니다. PostgreSQL은 팀 단위 이용이나 서버 운용에서 흔히 사용되는 데이터베이스입니다. PostgreSQL Sync는 각 머신의 로컬 SQLite에서 공유된 PostgreSQL DB로 push하고, pg serve를 통해 read-only UI를 제공하는 구성을 설명합니다. 용도는 team dashboards나 multi-machine setups입니다.

이 구성을 사용하면 여러 단말의 세션을 하나로 모을 수 있습니다. 팀별, 프로젝트별, 머신별로도 확인할 수 있습니다. 이는 Usage dashboard 공유나 세션 검색을 통한 지식 공유로 이어집니다.

반면, 공유 DB에는 프롬프트, 답변, 도구 결과, 그리고 경우에 따라 기밀 정보가 포함됩니다. 도입 전에 공유 범위, 보관 기간, 삭제 방법, 비밀 정보 취급 방침을 결정해야 합니다. PostgreSQL sync에는 "단방향 동기화", "영구 삭제가 자동으로 전파되지 않음" 등의 제약 사항도 존재합니다 (PostgreSQL Sync: Limitations).

감사(Audit), 인수인계, 재사용의 토대가 됨

AI 에이전트는 코드뿐만 아니라 판단 과정과 조사 과정도 생성합니다. agentsview를 통해 이를 나중에 읽을 수 있는 형태로 남겨두면, PR(Pull Request)이나 장애 대응 시의 배경 설명, 새로운 멤버의 온보딩, tool call(도구 호출) 확인, 비용이 많이 들었거나 시간이 너무 오래 걸린 작업의 개선, 유사한 작업의 프롬프트 재사용 등에 활용할 수 있습니다.

여기서 말하는 tool call이란 에이전트가 파일을 읽거나, 명령어를 실행하거나, 검색을 수행하는 등의 조작 기록을 의미합니다. 코드만 봐서는 왜 그런 변경에 이르게 되었는지 알 수 없는 경우가 있습니다. 세션 로그가 남아 있다면 판단의 중간 과정을 추적하기가 훨씬 쉬워집니다.

이는 observability(관측 가능성)와 유사한 가치를 지니지만, 프로덕션 애플리케이션의 모니터링과는 별개입니다. agentsview는 주로 로컬의 coding-agent 세션 아카이브에 특화된 도구입니다. 애플리케이션에 내장된 프로덕션 에이전트의 latency(지연 시간), failure rate(실패율), model call tracing(모델 호출 추적)을 직접 측정하는 기반은 아닙니다.

도입이 적합한 케이스

agentsview는 다음 조건에 해당할수록 도입 가치가 높아집니다.

도입 가치가 높은 상태와 도입 전에 결정해 두어야 할 운영 규칙.

도입 가치가 높은 케이스	반대로 우선순위가 낮아지는 케이스
여러 개의 AI coding agent를 사용 중인 경우	단일 도구의 이력만으로 충분한 경우
...

주의점: 다루는 데이터가 가볍지 않음

agentsview는 도입하기 쉬운 도구입니다. 하지만 다루는 데이터가 가볍지 않습니다. 세션 로그에는 프롬프트, 코드 조각, 파일 경로, 도구 결과, 실패한 구현, 경우에 따라서는 비밀 정보가 포함될 수 있습니다.

1. 개인정보 보호 표기에 차이가 있음

확인 가능한 자료들 사이에서 개인정보 보호 설명에 차이가 있었습니다. GitHub README에는 제한적인 익명 daemon_active telemetry ping에 대한 설명이 있습니다. 반면, Configuration의 Privacy and Telemetry 섹션에서는 "telemetry, analytics, crash reporting, diagnostics는 없다"라고 명시하며, 기본 자동 outbound(외부 송신)는 update check라고 설명하고 있습니다.

이 부분은 이번 조사 내용 중 가장 우려되는 지점입니다. 도입 시에는 설치한 버전의 README, 설정, 환경 변수, 그리고 실제 네트워크 동작을 확인하는 것이 안전합니다.

2. 공유 운영 시 데이터 거버넌스가 필요함

PostgreSQL sync는 편리합니다. 다만, 공유 DB에 들어가는 정보의 범위를 미리 결정해야 합니다. 누가 볼 수 있는지, 어떤 프로젝트를 sync할 것인지, 보관 기간은 어떻게 할 것인지, 삭제나 마스킹(masking)은 어떻게 처리할 것인지 등을 정해야 합니다. 이를 결정하지 않고 공유할 경우, 편리한 검색 기반이 그대로 정보 유출 리스크가 될 수 있습니다.

CLI Reference에는 agentsview secrets를 통한 secret scanning(비밀 정보 스캐닝)도 설명되어 있지만, 이것만으로 모든 유출 리스크를 제거할 수는 없습니다 (CLI Reference).

3. Docker에서는 보이는 범위가 마운트에 의존함

Docker로 사용할 경우, 컨테이너에 명시적으로 마운트한 세션 디렉터리만이 대상이 됩니다. Quick Start와 README는 이 제한 사항을 주의점으로 설명하고 있습니다. 이는 안전한 제한이기도 하지만, "실행했는데 세션이 보이지 않는" 원인이 되기도 합니다.

4. 프로덕션 AI observability의 대체재가 아님

agentsview는 coding-agent 세션의 로컬 아카이브, 검색, 분석, 비용 확인에 강점이 있는 도구입니다. 반면, 프로덕션 애플리케이션에 내장된 에이전트의 요청 단위 tracing, latency monitoring, failure alerting, 평가 데이터셋 관리에는 별도의 observability 설계가 필요할 수 있습니다.

도입 전 체크리스트

도입 전에 다음 질문에 답해 보면 판단하기가 쉬워집니다.

최근 1개월 동안 AI 에이전트의 과거 대화를 찾아본 횟수가 많은가
여러 개의 agent CLI나 IDE agent를 사용하고 있는가
AI 이용 비용을 프로젝트별로 설명해야 하는가
팀 내에서 세션 이력(session history)을 공유할 수 있는 범위가 정해져 있는가
로컬 저장(local storage), PostgreSQL 공유, DuckDB 분석 중 무엇이 필요한가
원격 접속(remote access)을 사용할 경우, 인증(auth), TLS, 허용된 서브넷(allowed subnet)을 설정할 수 있는가
Session Insights를 사용할 경우, 세션 내용이 선택한 agent/provider로 전달되는 것을 허용할 수 있는가

요약

agentsview의 가장 큰 가치는 AI 코딩 에이전트의 이용을 '일회성 대화'로 끝내지 않는 것입니다. 검색할 수 있고, 비용을 설명할 수 있으며, 작업 패턴을 회고할 수 있습니다. 필요하다면 팀과 공유할 수도 있습니다.

여러 에이전트를 사용하는 개발자, AI 이용 비용을 확인하고 싶은 팀, 과거의 에이전트 작업 내용을 재사용하고 싶은 조직에 적합합니다. 다만, 공유 운영 시에는 세션 내용의 기밀성, 삭제, 액세스 제어(access control)를 사전에 설계해야 합니다.

도입 자체는 가볍게 시작할 수 있습니다. 하지만 그곳에 모이는 것은 개발의 기억 그 자체입니다. agentsview는 그 기억을 방치된 로그가 아니라, 나중에 찾아볼 수 있는 작업 자산으로 다루기 위한 도구입니다.

참고 자료

AgentsView official site: https://agentsview.io/
GitHub Copilot launch: https://github.blog/news-insights/product-news/introducing-github-copilot-ai-pair-programmer/
OpenAI Codex announcement: https://openai.com/index/openai-codex/
Claude Code docs: https://code.claude.com/docs/en/
Quick Start: https://agentsview.io/quickstart/
CLI Reference: https://agentsview.io/commands/
Token Usage & Costs: https://agentsview.io/token-usage/
Configuration: https://agentsview.io/configuration/
Remote Access: https://agentsview.io/remote-access/
PostgreSQL Sync: https://agentsview.io/pg-sync/
Session Insights: https://agentsview.io/insights/
GitHub repository / README: https://github.com/kenn-io/agentsview