Kurrent Capacitor 프리뷰, 코딩 에이전트 세션을 팀 자산으로

AI 요약

• 무슨 일: Kurrent가 Capacitor private preview로 코딩 에이전트 세션 기록 제품을 공개했습니다.
  • 보도자료 기준 지원 대상은 Claude Code, Codex, Cursor이며 preview 기간에는 무료 사용을 내세웁니다.
• 제품 범위: transcript, tool call, token, repo, branch, PR 문맥을 이벤트 스트림으로 저장합니다.
• 개발자 영향: 에이전트가 만든 diff를 리뷰할 때 실행 로그와 결정 이유를 함께 조회하는 방향입니다.
• 주의점: 아직 private preview이며 공개 저장소와 npm 패키지는 초기 단계라 실제 팀 도입 수치는 확인되지 않았습니다.

Kurrent가 2026년 6월 4일 Kurrent Capacitor private preview를 발표했습니다. Capacitor는 Claude Code, Codex, Cursor 같은 코딩 에이전트가 한 세션을 실시간으로 기록하고, 그 기록을 대시보드, CLI, MCP 도구, PR 리뷰, 세션 평가에 다시 쓰게 만드는 제품입니다. 보도자료는 preview 기간 무료 사용과 private preview 신청 방식을 함께 밝히며, 공식 사이트는 제품을 "coding agents를 위한 shared memory"로 설명합니다.

이 발표가 AI 개발자에게 닿는 지점은 모델 성능표가 아닙니다. 코딩 에이전트가 만든 pull request에는 diff가 남지만, 어떤 테스트가 실패했고 어떤 가설이 버려졌고 어떤 권한 요청을 사람이 거절했는지는 팀 단위 자산으로 남기 어렵습니다. Kurrent는 이 공백을 "팀 조정 계층" 문제로 부르고, 자신들의 event-native database인 KurrentDB를 세션 기록 저장소로 연결합니다.

Capacitor 공식 문서는 제품의 상호작용 지점을 두 가지로 나눕니다. 첫 번째는 Kurrent가 호스팅하는 tenant입니다. 문서는 tenant URL을 https://<your-github-org>.kcap.ai 형태로 설명하고, 이 인스턴스가 이벤트 저장, 대시보드 projection, 웹 UI 제공을 맡는다고 적습니다. 두 번째는 npm install -g @kurrent/kcap로 설치하는 CLI입니다. CLI는 Claude Code와 Codex hook을 설치하고 transcript를 tenant로 스트리밍하며, kcap recap, kcap review, kcap eval 같은 명령을 제공합니다.

공개 저장소도 확인됐습니다. kurrent-io/kcap-cli GitHub 저장소의 README는 Capacitor를 "Claude Code sessions를 위한 full observability"라고 설명합니다. 기록 대상은 session lifecycle, transcript data, subagent trees, tool usage, token consumption, repository context입니다. GitHub API 기준 저장소는 2026년 4월 8일 만들어졌고 2026년 6월 5일에도 push가 있었습니다. 별 1개, fork 1개라서 공개 생태계 신호는 아직 작습니다. npm에서 확인한 @kurrent/kcap 패키지 버전은 0.6.4이고, 설명은 "Kurrent Capacitor의 CLI companion"입니다.

보도자료의 제품 주장은 더 넓습니다. Capacitor는 모든 agent turn, tool call, test run, reasoning block을 팀의 Capacitor server로 실시간 전송하고 full-text search 대상으로 인덱싱한다고 설명합니다. 또한 repository와 pull request 연결을 붙여 리뷰 시점에 구현 transcript를 불러오는 흐름을 제시합니다. Kurrent CEO Kirk Dunn은 에이전트가 소프트웨어 개발 속도를 높였지만 팀의 조정 계층은 그대로 남았고, Capacitor가 그 답이라고 말했습니다. 이 인용은 제품 포지셔닝을 잘 드러내지만, 현재는 vendor statement라는 점을 분리해서 읽어야 합니다.

개발팀에서 가장 먼저 체감할 기능은 PR 리뷰 문맥입니다. AI 코딩 에이전트가 만든 diff만 보면 reviewer는 의도를 추정합니다. Capacitor의 kcap review <pr-url> 흐름은 PR 뒤의 세션을 찾아 테스트 시도, 실패 로그, 대안 선택, 구현 이유를 붙이는 방향입니다. 이 접근은 리뷰 품질을 "모델이 코드를 얼마나 잘 읽는가"에서 "리뷰 모델이 실행 기록까지 볼 수 있는가"로 이동시킵니다. 리뷰어가 에이전트에게 "왜 이 migration을 먼저 바꿨나"라고 물을 때 diff가 아니라 세션 transcript가 답의 근거가 됩니다.

두 번째 사용처는 세션 recall입니다. 공식 문서는 kcap mcp sessions stdio server가 과거 Capacitor 세션을 코딩 에이전트 안에서 검색하게 한다고 설명합니다. 예를 들어 이전 분기 같은 저장소에서 이미 OAuth callback race condition을 다뤘다면, 현재 agent는 "이 문제를 전에 다룬 적이 있나"라는 질문으로 관련 세션을 찾고 특정 turn 근처 transcript를 가져올 수 있습니다. 기존 repo memory 제품이 파일 구조, 규칙, 결정 문서를 저장하는 쪽에 가까웠다면, Capacitor는 agent 실행 transcript를 event stream으로 쌓는 쪽에 무게를 둡니다.

세 번째 축은 평가입니다. 문서는 Capacitor가 session을 safety, plan adherence, quality, efficiency 기준으로 LLM-as-judge 평가하고, findings를 per-repo cluster로 모아 관리자가 큐레이션한 뒤 다음 세션 상단에 재주입한다고 설명합니다. 이 기능이 제대로 작동하면 한 세션의 실수가 다음 세션의 guardrail이 됩니다. 예를 들어 "마이그레이션 파일을 만든 뒤 seed script를 실행하지 않아 build만 통과했다"는 평가 결과가 repo guideline으로 남으면, 다음 agent는 실행 초기에 같은 점검을 받을 수 있습니다.

Kurrent가 자신 있게 말하는 기술적 차별점은 KurrentDB 기반입니다. 보도자료는 모든 agent turn, tool call, session lifecycle event가 append-only stream의 immutable event로 저장된다고 설명합니다. 금융기관과 규제 산업에서 쓰는 auditability 패턴을 코딩 에이전트 세션에 적용한다는 주장입니다. 이 말은 제품 마케팅으로만 읽으면 평범해 보이지만, 세션 데이터를 단순 채팅 로그가 아니라 replay, query, projection 가능한 event stream으로 본다는 점은 실제 설계 차이를 만듭니다.

그 차이는 multi-agent handoff에서 드러납니다. 보도자료는 여러 에이전트를 병렬 또는 순차로 돌릴 때 Capacitor가 어떤 작업이 끝났고 어떤 판단이 이미 내려졌는지 공유한다고 설명합니다. 지금의 코딩 에이전트 운영은 같은 repo 안에서도 Claude Code, Codex, Cursor 세션이 서로의 실패를 모르는 상태로 출발할 때가 많습니다. Capacitor는 이 기록을 특정 도구의 내부 로그가 아니라 팀이 소유한 공통 event stream으로 만들겠다고 말합니다.

물론 이 제품이 바로 표준이 된다고 보기는 어렵습니다. 첫째, private preview라서 실제 고객 수, latency, 저장 비용, data retention, 권한 모델 세부 조건이 공개적으로 검증되지 않았습니다. 둘째, transcript와 reasoning block 저장은 보안팀이 좋아할 audit trail이면서 동시에 민감한 코드, secret 주변 로그, 내부 의사결정이 집중되는 저장소가 됩니다. 셋째, 보도자료는 "secure session memory"를 말하지만, 세부 암호화, tenant isolation, deletion, SSO, audit export 조건은 공개 문서만으로 충분히 판단하기 어렵습니다.

경쟁 제품군도 이미 보입니다. 검색 결과에는 memctl, Engram, Kage, Memstate처럼 "shared memory for AI coding agents"를 내세우는 제품이 다수 나타납니다. 이들은 MCP 기반 recall, repo-local memory, hosted memory, organization policy 같은 서로 다른 방향을 잡고 있습니다. Capacitor의 차별점은 세션 transcript와 PR 리뷰, 평가 루프를 KurrentDB event stream 위에 묶는다는 점입니다. 다만 같은 범주의 제품들이 빠르게 늘고 있어, 도입 팀은 memory가 파일 기반인지, SaaS 기반인지, audit trail인지, semantic recall인지부터 구분해야 합니다.

개발자 관점에서 지금 확인할 수 있는 실행 경로는 단순합니다. 공식 README는 npm install -g @kurrent/kcap로 CLI를 설치하고 kcap setup으로 server URL, GitHub Device Flow login, default visibility, agent hooks, daemon 설정을 진행한다고 안내합니다. Codex hook을 설치한 뒤에는 Codex 안에서 /hooks를 열고 kcap 항목을 신뢰해야 한다는 문서도 있습니다. 이 세부사항은 제품이 IDE plugin 하나로 끝나는 것이 아니라 terminal hook, agent hook, hosted tenant, dashboard를 모두 건드린다는 뜻입니다.

Capacitor는 코딩 에이전트 시장에서 "누가 더 좋은 모델을 붙였나"보다 "누가 작업 기록을 팀 운영 단위로 바꾸나"를 묻는 발표입니다. June 4 발표의 크기는 아직 작습니다. 저장소 지표도 초기이고, private preview 밖에서 검증된 사례도 많지 않습니다. 그래도 Claude Code, Codex, Cursor가 한 팀 안에서 섞여 쓰이는 환경이라면 세션이 닫힌 뒤 사라지는 설명 비용은 이미 현실적인 비용입니다. Capacitor는 그 비용을 event stream, MCP recall, PR review, eval guideline이라는 네 가지 기능으로 청구서에 올린 첫 제품군 중 하나입니다.

지금 도입을 검토한다면 질문은 세 가지입니다. agent transcript를 저장해도 되는 저장소와 branch 범위가 어디인지, reviewer가 diff와 함께 봐야 하는 최소 세션 정보가 무엇인지, 평가 결과를 다음 agent prompt에 자동 주입해도 되는 정책 기준이 무엇인지입니다. 이 질문을 정리하지 않으면 shared memory는 협업 자산이 아니라 민감한 로그 더미가 됩니다. Kurrent Capacitor가 실제로 풀어야 할 문제도 그 지점입니다. 기억을 많이 저장하는 것이 아니라, 팀이 검토할 수 있는 방식으로 저장하고 다시 쓰는 것입니다.