에이전트 메모리에도 OpenTelemetry 같은 전환점이 필요함

코딩 에이전트마다 메모리 형식이 달라 한 도구가 학습한 내용을 다른 도구가 읽지 못하며, 필요한 것은 새 도구보다 공통 형식에 대한 합의임 OpenTelemetry가 데이터 모델, 의미 규약, 프로토콜을 공동 표준으로 만들고 저장과 분석은 경쟁 영역으로 남겼듯, 에이전트 메모리도 공유할 기반과 차별화할 기능을 나눌 수 있음 기존 이식성 제안은 주로 업체 간 내보내기를 해결하지만, 같은 저장소에서 동시에 일하는 CI 에이전트와 편집기, 리뷰 봇이 동일한 메모리를 읽고 쓰는 실시간 주소 지정도 필요함 공통 레코드는 메모리의 적용 범위, 정체성, 내용, 유효 기간과 작성 주체를 담고, 공통 작업 계약과 적합성 테스트로 도구 간 의미를 일치시키는 형태가 될 수 있음 공유 메모리는 프롬프트 인젝션 경로가 될 수 있으며 어떤 형식도 오염을 완전히 막지는 못함. 표준화 역시 새 형식을 하나 더 추가하기보다 기존 프로젝트와 제안의 합의가 필요함 서로 읽지 못하는 에이전트 메모리 일반적인 코딩 환경에서도 호환되지 않는 메모리 형식이 함께 쓰임 저장소에는 AGENTS.md, CLAUDE.md, Cursor의 .cursor/rules/*.mdc가 쓰임 Anthropic 메모리 도구는 /memories 아래에 파일을 기록함 Copilot의 저장소별 사실은 GitHub 측에 저장됨 메모리 MCP 서버는 JSONL 지식 그래프를 사용함 각 형식은 개별적으로 합리적이지만, 모두 “에이전트가 미래의 자신을 위해 특정 주소에 남긴, 일정 기간 유효한 메모”라는 작은 개념을 다시 구현함 CI 에이전트가 얻은 교훈은 해당 도구 안에 머물며, 편집기 에이전트나 새로 도입한 도구가 읽을 수 없음 r/ClaudeAI, r/LocalLLaMA, r/cursor에 계속 등장하는 자체 메모리 계층은 실제 수요를 보여주지만, 각각의 저장 방식과 스키마, MCP 도구는 호환되지 않는 형식을 더 늘림 오픈소스 도구 LoreKit의 형식도 한계가 있는 여러 제안 중 하나이며, 메모리 문제를 이미 해결한 정답은 아님 OpenTelemetry가 보여준 합의 방식 2019년 이전 관측 가능성 업체들은 자체 에이전트, 계측 라이브러리, 데이터 형식을 제공했고, 업체를 바꾸려면 코드를 다시 계측해야 했음 이를 해결하려던 OpenTracing과 OpenCensus도 서로 경쟁하다가 2019년 OpenTelemetry로 통합됨 OpenTelemetry는 네 가지를 공동 기반...