오늘은 Claude Code 관련 소식이 많네요. Claude Code 행동 관찰자 앱 AgentWatch, 안드로이드 Local AI Coding agent CODEY-V2, Google TurboQuant 구현 사례 소개, LLM이 “잘 모르겠다”는 대답을 하는 것과 관련한 토론이 흥미롭습니다.

AgentWatch – Claude Code 관찰자 앱

프로젝트 개요:

AD

AgentWatch라는 Claude Code 관찰자 앱을 주말에 개발하여 공유. 목적은 기존의 “사용자가 코드를 쓰고 AI가 보조하는” 모델이 아니라, Claude가 코딩을 주도할 때 사용자가 그 동작을 관찰·유도·감사할 수 있게 하는 인터페이스 제공.

주요 기능:

  • 2D 트리맵(코드베이스 전체 시각화): 파일 유형 색상 구분, Claude가 파일을 읽거나 수정할 때 에이전트 구체가 실시간으로 이동.
  • 라이브 diff 스트림: Claude가 타이핑 중일 때도 편집이 즉시 diff로 표시되며 파일/작업별 편집 히스토리 저장.
  • 사용량 대시보드: 토큰 수와 USD 비용을 작업·프로젝트·일별로 추적(세션 간 지속 저장).
  • 파일 마인드맵: 의존성(임포트) 기반의 force-directed 그래프, 파일을 열어 노드 확장/축소 가능.
  • 아키텍처 패널: 파일 확장자로 기술 스택 탐지 후 아키텍처 레이어로 그룹화, 비동기 Claude 분해(pass)로 레이어 건강 상태 판정 및 캐싱.
  • 자동 파일 요약: 열람한 파일마다 Claude가 요약을 생성해 .ctx.md로 캐시.


구현 및 요구사항:

  • Tauri(Rust) 셸 + React/TypeScript 프론트엔드, Zustand 상태관리.
  • 로컬에서 실행(클라우드 사용 안 함).
  • 현재 macOS 전용(Windows/Linux는 예정).
  • Claude Code CLI 필요.

CODEY-V2 출시

Android 기기에서 실행 가능한 데몬 기반 AI 코딩 에이전트로, 기본적으로 클라우드 의존 없이 완전히 온디바이스(안드로이드의 Termux 또는 리눅스)에서 실행됩니다.

  • Qwen2.5-Coder-7B (주 코딩/추론 에이전트)
  • Qwen2.5-0.5B (플래너 및 요약기)
  • nomic-embed-text-v1.5 (RAG 임베딩)”

Hermes용 Token 분석 대시보드 – 모든 API 호출의 73%는 고정 오버헤드

대시보드 이용해서 API 호출을 분석한 결과, 아래와 같은 결론을 도출했다고 합니다.

다음은 프레임워크 수준의 변경을 필요로 합니다:

  • 플랫폼별 도구집합: 메시징 플랫폼에 대해 browser_* 도구를 로드하지 않음(요청당 약 1.3K 절약)
  • 지연된 스킬 로딩: 카탈로그를 모든 시스템 프롬프트에 주입하는 대신 필요 시 스킬을 로드(요청당 약 2.2K 절약)
  • 더 이른 압축: 긴 대화에서 더 빨리 압축하도록 임계값을 0.5 → 0.3으로 변경
  • 보호된 메시지 감소: 보다 공격적인 컨텍스트 압축을 위해 protect_last_n: 20 → 10

위 옵션 1-2만으로도 요청당 약 3,500 토큰을 절약할 수 있으며 — 이는 기능 손실 없이 약 18% 감소입니다.

turboquant-vllm v1.3.0 – vLLM plugin

Google TurboQuant 적용한 vLLM plugin입니다. Llama, Mistral, Qwen, Phi, Gemma + Molmo2 모델 계열 KV Cache 압축이 가능하다고 합니다.  KV Cache만 압축이 가능한 제약은 있고, FP16 비전 모델이 FP8 Text 모델 보다 압축율이 더 좋게 나왔습니다. 약간의 학술적인 내용은 건너뛰고 실제적으로 plugin 추가하면 기존 모델과 성능 차이(손실) 없이 KV Cache 압축이 가능하다는 것을 확인하고 사용하면 될 것 같습니다.

TurboQuant (ICLR 2026) 논문을 순수 C로 구현한 프로젝트

주요 기법

  • Key(키)를 1비트로 압축: 랜덤화된 하다마드 변환 + sign hashing 사용.
  • Attention 계산을 비트 연산 기반으로 구현: XOR + popcount(비트 집계).
  • Value(값)는 독립적으로 Q4 또는 Q2로 양자화.

성능·효과

  • K+V 합계에서 4.9×–7.1× 압축(테스트 모델: Gemma 3 4B).
  • 32K 컨텍스트에서 최대 약 3.7GB 메모리 절약 보고.

품질 검증

  • 1비트 attention cosine = 0.634 (이론적 한계 2/π와 근접).
  • NEON(ARM SIMD) 경로는 스칼라 레퍼런스와 검증됨.
  • ASan 클린, 26개 테스트 스위트 통과.
  • 외부 종속성 없음(순수 C 구현).

[토론] LLM이 확실하지 않을 때 명시적으로 “모릅니다(I don’t know)”라고 답하게 만드는 문제의 난이도와 해결 가능성에 대한 토론.


논점

  • 많은 참가자들이 이 문제를 단순한 프롬프트 엔지니어링 수준을 넘어선, 학습(훈련) 문제라고 봄 — 기본 모델의 학습 방법·데이터 보강이 필요하다는 주장.
  • 반대 의견도 있음: LLM은 본질적으로 확률적 생성기이므로 “모른다”를 완전히 보장하는 건 구조적 한계가 있다는 주장(LLM은 ‘모름’을 인식하지 못함).

제안된 접근들

  • 훈련 단계에서 “I don’t know” 레이블로 미세조정(fine-tuning)하거나 오답에 대해 강하게 패널티 주기.
  • 별도의 신뢰도(확신) 판단 모델 또는 critic/planner/critic/writer 같은 다중 역할 모델 파이프라인을 도입해 불확실성을 검증하게 함.
  • 응답의 perplexity(또는 불확실성 지표)를 측정해 임계값 이상이면 “모르겠다”를 반환하게 함.
  • RAG(검색 기반 증거 취합)·evidence orchestration 방식을 써서 근거가 부족하면 회피하도록 설계.
  • 반대·주의: 너무 쉽게 “모르다”를 내놓으면 정답을 줄 수 있는 경우도 놓칠 수 있음(위양성/위음성 트레이드오프).
  • 철학적/근본적 관점: 일부는 이는 의식(consciousness) 문제와 연관된 오해이며, 현재 아키텍처로는 본질적 한계가 있다고 봄. 다른 이는 단지 분류 문제일 뿐이며 더 나은 학습·평가 메커니즘으로 해결 가능하다고 봄.

커뮤니티 논평(핵심 관점들)

  • “훈련·가중치 조정으로 해결 가능” / “fine-tune으로 I don’t know 라벨 학습” (예: No-Consequence-1779 등)
  • “LLM은 아무 것도 알지 못한다(항상 환각 가능)” — hallucination이 본질이다 (datbackup 등)
  • “별도 모델로 신뢰도/메타인지 판단을 해야 한다” (Helpful-Account3311 등)
  • critic/planner/writer 루프나 evidence-driven 설계로 실용적 해결을 시도 중(예: sn2006gy의 경험 공유)
  • 구현적 팁: 높은 perplexity(또는 불확실성)일 때 ‘모르겠다’ 출력하도록 설정하면 간단히 적용 가능하다는 주장(gh0stwriter1234)

(보너스) X(구,Twitter) 링크만 추가합니다. 

※ 지난 게시글:

※ 출처: Reddit/LocalLLaMa, OpenClaw

AD

RELATED ARTICLESMORE FROM AUTHOR

LEAVE A REPLY

Please enter your comment!
Please enter your name here