에이전트 실행 기록을 위한 개방형 표준: 공유 로그 스키마의 필요성

r/ClaudeAI의 Reddit 게시물이 에이전트 실행 기록(세션 중 AI 에이전트의 모든 작업을 기록하는 로그)을 위한 개방형 표준의 필요성을 강력히 주장합니다. 작성자는 현재 런타임 간 단편화가 세 가지 구체적인 비용을 초래한다고 주장합니다:

1. 교차 런타임 디버깅: 각 프레임워크마다 다른 로그 스키마를 배우는 것은 프로덕션에서 사용하는 프레임워크 수에 비례해 인지 부하를 증가시킵니다.
2. 교차 런타임 감사: 감사관의 질문에 답하기 위해 세 가지 다른 로그 형식을 수동으로 결합하는 것은 단순한 조회가 아니라 소프트웨어 프로젝트입니다.
3. 이식성: 런타임의 로그 형식에 의존하는 도구(디버거, 규정 준수 뷰, 평가 도구)는 사용자를 고정시킵니다. 런타임을 전환하면 이러한 도구를 다시 작성해야 합니다.

제안된 표준은 새로운 필드에 관한 것이 아닙니다. 이미 더 나은 런타임에 존재하는 필드들입니다. 핵심 스키마는 다음을 포함합니다:

• session_id, agent_id, runtime_version
• tool_call: 도구, 입력, 출력, 상태, 검증자, 증거 경로
• decision: 주장, 근거, 상태, 가정
• approval: 요청됨, 승인자, 승인 시간, 범위
• diff: 파일 또는 동작 수준, 전/후
• resume_verdict: 완료, 부분, 재개 불가, 다음 안전 동작

가치는 모든 런타임이 동일한 스키마를 생성하여 동일한 디버거, 감사 쿼리 및 재개 로직이 모든 런타임에서 작동하도록 하는 데 있습니다. 작성자는 표준이 단일 벤더나 느린 위원회에 의해 소유될 경우 분쟁의 장이 될 위험이 있다고 경고합니다. 건강한 모델은 POSIX보다 OpenTelemetry에 가깝습니다: 소형 코어 스키마, 맞지 않는 기능을 위한 벤더 확장, 필드 의미가 진화할 때 업데이트를 제공하는 유지 관리자입니다.

게시물은 런타임 빌더에게 묻습니다: 핵심 스키마에 동의하는 데 의미 있는 비용이 드는가? 그렇지 않다면 단편화는 단지 관성일 뿐입니다. 그렇다면 그 비용은 사용자(더 나쁜 도구, 더 어려운 감사)가 부담하는가, 아니면 런타임 벤더(덜한 종속)가 부담하는가? 작성자는 실행 기록 스키마에 대한 세 가지 서로 다른 논의가 거의 동일한 필드 집합에 도달했으며, 이는 '형식이 존재하기를 원한다'는 것을 시사한다고 지적합니다.