20여 개 코딩 에이전트의 기록을 한 로그로: Asymptote-Labs/agent-beacon의 세션 텔레메트리·CEL 위협 탐지·핸드오프·승인형 메모리 심층 해부와 박스 실측

Claude Code로 오전에 고친 버그를 오후에 Codex가 처음부터 다시 헤매는 일은 흔하다. 세션 기록은 하네스마다 다른 폴더, 다른 형식(JSONL, SQLite, OTLP)으로 흩어져 있고, 누가 어떤 명령을 실행했는지 보안팀이 볼 방법도 마땅치 않다. Asymptote-Labs/agent-beacon(이하 Beacon)은 이 두 문제를 한 바이너리로 묶는다. 20여 개 코딩 에이전트의 세션을 하나의 정규화된 JSONL 런타임 로그로 모으고, 그 위에서 위협 탐지 규칙(CEL), 토큰·비용 집계, 하네스 간 세션 이어받기(handoff), MCP로 검색, 그리고 리뷰를 거친 프로젝트 메모리를 제공한다. 오늘(2026-10-22) GitHub Trending Go 일간 3위(+443)에 올랐다.

README의 첫 문장은 “Self-improving memory for coding agents”지만, 바이너리를 직접 돌려 보면 무게중심은 엔드포인트 텔레메트리 에이전트 쪽에 있다. 명령 체계가 beacon endpoint …로 시작하고, 출력은 Wazuh 호환 JSON이며, Splunk·Datadog·Sentinel·CrowdStrike Falcon·S3로 보내는 포워더가 기본 탑재돼 있다. 이 글은 그래서 “메모리 도구”가 아니라 “에이전트 활동을 기록·감사하는 계층”으로 보고 구조와 타협점을 따진다. 박스(리눅스 x64 VM, 8코어)에서 v1.3.45 릴리스 바이너리를 SHA-256 검증 후 받아, 격리 HOME + unshare -rn(네트워크 차단) + API 키 없음 조건으로 설치·백필·규칙 스캔·훅·handoff·MCP·규모 테스트를 직접 돌렸다. 입력은 가짜 AWS 키·GitHub 토큰·프롬프트 인젝션 문구·curl | bash·강제 푸시를 일부러 넣은 합성 Claude Code/Codex 세션이다. 수치는 2026-10-22 17:30~17:40 KST 실측이거나 GitHub API·저장소 문서에서 확인한 값이다.

한눈에 보기: 오늘 기준 스냅숏

무엇이 들어 있나: 다섯 개의 얼굴

Beacon을 처음 보면 기능이 너무 많아 무엇이 핵심인지 헷갈린다. 최상위 명령만 24개다. 역할별로 묶으면 다섯 덩어리가 된다.

아키텍처: 바이너리 네 개와 로그 하나

리눅스 tar.gz(88.2MB)를 풀면 실행 파일 네 개가 나온다. 크기 차이가 설계를 그대로 보여 준다.

데이터 경로는 세 갈래가 한 파일로 합쳐진다. ① OTLP 경로: Claude Code·Codex처럼 OpenTelemetry를 내보내는 하네스는 환경변수로 로컬 컬렉터를 가리키게 한다. ② 훅 경로: PreToolUse·PostToolUse·SessionStart 같은 훅에서 beacon-hooks가 직접 로그에 쓴다. ③ 폴링/백필 경로: OTel도 훅도 없는 하네스(Cursor·Cline·OpenCode SQLite 등)는 세션 저장소를 직접 읽는다. 설치 시 지난 30일치를 한 번에 백필한다. 세 경로 모두 같은 스키마(schema_version 1.0, event.action, harness.name, session.id, trace.id)로 ~/.beacon/endpoint/logs/runtime.jsonl에 append되고, 이 파일이 스캔·집계·MCP·handoff의 단일 진실 원천이 된다.

이 설계의 장점은 분명하다. 하네스가 늘어도 탐지 규칙·대시보드·MCP는 그대로이고, 규칙은 “Claude냐 Codex냐”가 아니라 e.event.action == "command.executed" 같은 공통 필드만 본다. 단점은 정규화가 하네스가 무엇을 알려 주느냐에 묶인다는 것이다. 아래 실측에서 보듯 같은 ‘자격 증명 파일 읽기’라도 Read 도구로 읽으면 file.read, Bash cat으로 읽으면 command.executed가 되고, 규칙 매칭 결과가 달라진다.

설치가 실제로 바꾸는 것

엔드포인트 에이전트는 사용자 환경 설정을 직접 고친다. 도입 전 가장 먼저 확인해야 할 부분이라 격리 HOME에서 --dry-run과 실제 설치(--service none --no-start) 후 생성·변경 파일을 모두 뽑았다.

export HOME=$PWD/run/home DO_NOT_TRACK=1
unshare -rn ./beacon endpoint install --harness claude,codex \
  --service none --no-start --no-browser --collector ./beacon-otelcol
# Claude Code hooks installed: ~/.claude/settings.json
# Codex CLI endpoint hooks installed: ~/.codex/hooks.json
# Session backfill: 485 events from the last 30 days (Claude Code 480, Codex CLI 5).

박스 실측 ①: 비밀 마스킹과 탐지 규칙

합성 세션 20개(Claude Code) + 1개(Codex)를 만들었다. 각 Claude 세션은 첫 프롬프트에 가짜 GitHub 토큰(ghp_…)과 AWS 키(AKIA…EXAMPLE), “ignore previous instructions” 문구를 넣고, 도구 호출 5개(cat ~/.aws/credentials, curl … | bash, .env 편집, npm test, git push --force origin main)를 수행한다. 원본 세션 파일 합계 126,108바이트가 백필 후 런타임 로그 486줄·477,359바이트(약 3.8배)가 됐다.

탐지는 내장 기본 규칙 6개만으로 먼저 돌리고, 공개 룰팩(77개, 카테고리 10종)을 rules lint로 검증한 뒤 스토어에 넣어 다시 돌렸다. 린트는 규칙마다 들어 있는 적합성 픽스처 544개를 0 실패로 통과했다(132ms).

정리하면 규칙 엔진 자체(CEL + 픽스처 내장 + 린트)는 잘 만들어졌지만, 탐지 범위는 이벤트 정규화의 해상도를 넘지 못한다. 자격 증명 파일 읽기처럼 중요한 행위는 Read 도구 경로와 셸 경로 양쪽 규칙을 함께 두는 게 안전하고, 중복 발견은 세션·행위 단위로 묶어 보는 후처리가 필요하다.

박스 실측 ②: 훅 지연, 토큰 집계, MCP

훅 한 번에 5–8ms로 체감 비용은 거의 없다. 대신 오픈소스 판 훅은 관찰 전용이다. 위험 명령에도 빈 JSON을 돌려주고 차단하지 않는다. 실행 전 차단은 endpoint enforcement(“enterprise edition” 표기)로 분리돼 있다. 즉 무료 판은 “사후 탐지 + 감사 로그”이고, 실시간 가드레일을 원하면 하네스 자체 권한 설정이나 다른 도구와 함께 써야 한다. 훅 입력 4종 × 5회 = 20줄이 로그에 추가됐다.

MCP 서버(beacon mcp serve, stdio)는 search_activity, summarize_activity, get_activity_event, list_activity_filters, search_memory, get_memory, get_memory_context 7개 도구를 노출했다. 모두 읽기 계열이지만 readOnlyHint 주석은 붙어 있지 않았다. 에이전트가 “지난주에 이 테스트 어떻게 고쳤지?”를 스스로 찾게 하는 통로가 이것이다.

박스 실측 ③: 규모와 백필 한도

1,000세션에서는 “Claude Code: stopped at the backfill size limit”가 뜨고 약 530세션(12,773 이벤트)에서 백필이 멈췄다. 나머지는 beacon endpoint claude sync로 따로 읽으라고 안내한다. 로그는 약 10MB에서 runtime.jsonl.1로 회전했고, 스캔은 회전 파일까지 읽어 발견 수가 세션 수에 비례했다(약 532×4=2,128). 스캔은 이벤트 수에 대략 선형이라 CI에서 세션 로그 하나 검사하는 용도에는 충분히 빠르지만, 수개월치 개발자 PC 로그 전체를 주기적으로 훑는 용도라면 SIEM 쪽 탐지로 넘기는 게 자연스럽다.

설계 타협점

비슷한 도구와 위치

도입 체크리스트

# 최소 로컬 감사 구성 예
beacon endpoint install --harness claude,codex --no-backfill
beacon rules lint ./rules && beacon rules add ./rules
beacon scan --min-severity medium
beacon token-usage --top 10
beacon handoff export <session-id> --print   # 공유 전 제목 줄 확인

실측하지 않은 것

결론

Beacon은 “에이전트가 배운 걸 기억하게 한다”는 문구보다 “여러 에이전트가 이 컴퓨터에서 무엇을 했는지 한 형식으로 남긴다”에서 진가가 나온다. 23종 하네스를 한 스키마로 묶는 정규화, 픽스처가 딸린 CEL 규칙, 5–8ms짜리 훅, 마스킹된 로컬 로그는 플랫폼·보안팀이 바로 쓸 만한 수준이다. 반면 무료 판 훅은 막지 않고 기록만 하며, 탐지 범위는 이벤트가 얼마나 잘게 정규화되느냐에 묶이고, handoff 제목처럼 마스킹 경로 밖의 출력이 아직 남아 있다. 메모리는 외부 평가기와 사람 승인이 있어야 돈다. 여러 코딩 에이전트를 섞어 쓰는 팀이라면 먼저 로컬 전용 모드로 깔아 scan과 token-usage부터 써 보고, 포워딩과 메모리는 정책이 정해진 다음 켜는 순서를 권한다.