파트 2/2: 설치 격차를 해소하는 npm-to-uv-to-PyPI 브릿지와 자율적으로 행동할 가치가 있게 만드는 적대적 재검증 규율

공동 작성자: Rudrendu Paul 및 Sourav Nandy.

레포: github.com/RudrenduPaul/memtrust, 에이전트 메모리 백엔드를 위한 독립적이고 재현 가능한 벤치마크 하네스입니다. pip install memtrust-cli로 설치합니다.

간단 요약: memtrust-cli가 이제 npm에 올라왔습니다. npx memtrust-cli를 사용하면 Python 도구 체인(toolchain)이 필요 없이 uv를 사용하여 파이썬 벤치마크 도구를 자동으로 실행합니다. 아래에는 전체 브릿지 설계, 평가에서 포착된 구체적인 시간적 KG 경계 버그, 그리고 출력 결과를 자율적으로 행동할 가치가 있게 만드는 검증 규율이 설명되어 있습니다.

본 시리즈의 파트 1에서는 자체 MemPalace 어댑터가 위조된 API 메서드를 호출하는 것을 발견했습니다. 이 백엔드에 대해 지금까지 보고했던 모든 결과는 허구였습니다. 그 격차를 해소한다는 것은 프로젝트의 모든 어댑터를 적대적으로, 처음부터 재검증해야 함을 의미했습니다. 그 이야기는 자체로 완성도가 높으며, 이번 글은 그 직후에 이어져 관련 질문에 답합니다: 자율 에이전트가 이 도구를 실행할 때,

"에이전트 네이티브 (Agent-native)"라는 용어는 매우 느슨하게 사용되고 있어 엄격한 정의가 필요합니다. 진정으로 에이전트 네이티브인 도구는 다음 두 가지 조건을 동시에 충족해야 합니다:

1. 자동으로 설치 가능할 것. 에이전트나 CI 작업 (CI job)은 프로그래밍 방식으로 구성된 단일 명령어를 사용하여 "설치된 것 없음" 상태에서 "도구 실행 중" 상태로 넘어가야 하며, 환경에 이미 구축된 어떤 런타임 (runtime)에서도 실행되어야 합니다.
2. 기계가 읽을 수 있을 것 (Machine-legible). 모든 응답은 프로그램이 직접 파싱 (parse)하고 조치할 수 있는 구조화된 데이터 (structured data)여야 합니다.

memtrust의 이전 릴리스를 포함한 대부분의 개발자 도구는 이 두 가지 기준을 모두 놓치고 있습니다. pip install memtrust-cli를 실행하는 것은 시스템에 이미 특정 Python 버전이 프로비저닝 (provisioned)되어 있고, 가상 환경 (virtual environment)이 구성되어 있으며, pip를 위한 쓰기 가능한 경로 (writable path)가 있다고 가정합니다. Node만 탑재된 CI 러너 (CI runner)나 에이전트 샌드박스 (agent sandbox)는 여기서 막히게 됩니다. 초기 memtrust CLI 출력 또한 인간 독자만을 대상으로 했습니다. 우리는 색상이 있는 표, 진행률 표시줄 (progress bars), 그리고 요약 라인을 출력했습니다.

이 프로젝트의 npm 측면은 이러한 설치 격차를 해소합니다. 이 글의 나머지 부분은 두 가지 과제 중 더 어려운 것으로 판명된 가독성 (legibility) 문제에 집중합니다.

두 레지스트리 모두에서 라이브 중

지금 바로 npx memtrust-cli를 통해 memtrust-cli를 설치할 수 있습니다. 이는 npm 레지스트리 (registry)에 등록되어 있습니다. 오늘 레지스트리에 대해 npm view memtrust-cli version을 실행하면 PyPI의 버전과 일치하는 0.3.3이 반환됩니다.

저희는 저장소의 npm/memtrust-cli/에 테스트를 마친 완전한 npm 패키지를 배포하였으며, 플랫폼별 6개의 컴패니언 패키지(@memtrust-cli/darwin-arm64, @memtrust-cli/darwin-x64, @memtrust-cli/linux-arm64, @memtrust-cli/linux-x64, @memtrust-cli/win32-arm64, @memtrust-cli/win32-x64)를 함께 제공합니다. 배포 프로세스는 엄격한 드라이 런 (dry-run) 원칙을 따랐습니다. npm pack --dry-run을 통해 정확한 타르볼 (tarball)을 생성한 후, npm publish --dry-run으로 레지스트리 인증을 포함한 전체 배포 흐름을 점검하였으며, 이 모든 과정을 거친 후에야 실제 npm publish를 실행했습니다. 실제 실행 전 드라이 런을 수행하는 것은 저희가 평가 (eval) 주장들에 적용하는 검증 습관과 동일합니다. 다만 이번에는 이를 릴리스 (release)에 적용했을 뿐입니다.

PyPI의 라이브 경로는 pip install memtrust-cli이며, 버전은 0.3.3입니다. 이는 npm 배포 날짜인 2026-07-21에 PyPI 자체 API를 통해 확인되었습니다. 더 짧은 이름을 찾는 분들을 위해 memtrust라는 이름의 미러 패키지가 현재 동일한 버전에 머물러 있으며, 이는 자동화된 방식이 아닌 수동 릴리스 단계를 통해 동기화됩니다. 아래의 모든 예시는 현재 pip 또는 npx를 통해 작동합니다.

다음은 bin/memtrust.js의 전체 구현부입니다. 전체 설계는 100줄 미만으로 간결하게 구성되어 있습니다:

// 이 npm 패키지 자체의 버전에 고정되어 있으며, 유동적으로 두지 않습니다: 버전 지정자가 없는
// "uv tool run --from memtrust"는 항상 PyPI에서 현재 가장 최신인 것을 가져옵니다.
// 이 패키지 자체의 버전에 고정함으로써...

이 스크립트는 require.resolve()를 통해 플랫폼별 uv 바이너리를 찾아내고, 모든 인자를 변경 없이 전달하며, 모든 memtrust 로직을 해당 바이너리에 위임합니다. 이때 PyPI 릴리스만 해당 패키지의 버전으로 고정합니다. 파일 전체를 처음부터 끝까지 읽는 데 약 1분 정도 걸리는데, 이것이 바로 저희의 의도였습니다. 저희는 한눈에 감사 (audit)할 수 있고, 아무것도 숨기지 않으면서 결정론 (determinism)과 단순함을 모두 제공하는 작은 브릿지 (bridge)를 원했습니다.

우리는 실제로 uv 바이너리를 어디에서 가져올지 결정하는 데 상당한 시간을 소비했습니다. 각 플랫폼 패키지의 prepack 스크립트는 Astral의 GitHub releases에서 일치하는 uv 릴리스 아카이브를 직접 가져오며, uv가 함께 게시하는 아카이브별 .sha256 체크섬 (checksum) 파일도 함께 가져옵니다. 그리고 스크립트는 진행하기 전에 정확히 일치하는지 확인을 요구합니다. 릴리스를 실행하는 유지 관리자 (maintainer)는 npm publish 시점에 이 검증을 한 번 수행합니다. 우리는 의도적으로 이러한 트레이드오프 (tradeoff)를 선택했습니다. 공급망 (supply chain)을 완전히 가시적으로 확인하며 체크섬을 검증하는 유지 관리자는, 매 설치 시마다 확인을 반복하는 것보다 더 강력한 보증을 제공하며, 다운스트림 (downstream)의 npm install 실행은 이미 검증된 상태에 단순히 의존하게 됩니다. uv 바이너리가 이미 실행 준비가 된 상태로 node_modules에 들어있기 때문에, 오프라인 또는 네트워크가 제한된 설치 환경에서는 Astral의 서버에 전혀 접속할 필요가 없습니다.

그 이후의 핵심적인 작업은 uv tool run --from memtrust==<pinned version> memtrust <args>가 수행합니다. 이 명령은 시스템에 Python 인터프리터 (interpreter)가 없는 경우 이를 프로비저닝 (provisioning)하고, 첫 사용 시 PyPI로부터 해당 고정된 (pinned) memtrust 릴리스를 격리된 도구 환경 (isolated tool environment)에 설치한 다음, 해당 도구를 캐싱하고 실행합니다. Node를 사용할 수 있는 에이전트나 CI 잡 (job)은 추가 설정 없이도 완전히 작동하는 Python 벤치마크 도구를 갖게 됩니다.

Node의 점유율은 이 격차를 스스로 메우기에 충분히 큽니다. Sonatype의 2026년 소프트웨어 공급망 상태 보고서 (2026 State of the Software Supply Chain Report)에 따르면, 2025년 동안 npm의 패키지 다운로드 횟수는 전년 대비 65.43% 증가한 7.97조 회를 기록한 반면, 같은 기간 PyPI는 8,049.7억 회를 기록했습니다 (Sonatype, 2026). 이를 CI 이미지에 무엇이 들어있을지에 대한 대략적인 대리 지표 (proxy)로 삼는다면, Node 기반 툴링 (tooling)은 기본적으로 엄청난 비율의 환경에 도달하며, 이는 큐레이션된 Python 툴체인 (toolchain)이 없는 곳에서도 Node가 이미 존재할 확률을 높입니다. Node 래퍼 (wrapper)는 그 격차를 직접적으로 메워줍니다.

uv 도구 자체는 실제적인 채택(adoption)을 이끌어내고 있습니다. Astral의 저장소는 2026-07-17 기준으로 87,595개의 GitHub 스타를 기록하고 있습니다 (GitHub API, astral-sh/uv). pypistats.org에 따르면 지난 한 달 동안 1억 6,567만 건의 다운로드를 기록했습니다. PSF와 JetBrains가 실시한 Python Developers Survey에 따르면, JetBrains의 "The State of Python 2025" 보고서에서 uv의 사용률은 도입된 단 1년 만에 0%에서 11%로 증가한 것으로 나타났습니다. Stack Overflow의 2025 Developer Survey에서는 uv의 채택률이 9.5%로 기록되었으며, 이는 pip의 40.9% 및 npm의 56.8%와 대조됩니다. 이러한 수치들을 고려할 때, uv를 기반으로 부트스트랩(bootstrap) 단계를 구축하는 것은 쉬운 결정이었습니다.

구조화된 JSON 출력 생성하기

모든 memtrust run 호출은 기본적으로 전체 JSON 보고서를 디스크에 작성하며, --output을 통해 다른 위치를 지정하지 않는 한 ./memtrust-report-<date>.json에 저장됩니다. 이 명령은 콘솔 요약과 더불어 해당 JSON 보고서를 생성하므로, 사용자가 --json 스위치를 따로 기억할 필요가 없습니다. 보고서의 results 블록은 내부 평가(evals)에서 사용하는 것과 동일한 시그널 분류 체계(signal taxonomy)를 사용하여 백엔드별, 평가(eval) 결과별로 상세 내용을 나누어 보여줍니다. memtrust run --eval 명령은 현재 longmemeval부터 temporal_kg_boundary까지 총 17개의 등록된 평가(evals)를 노출합니다. 파일을 읽는 프로그램은 콘솔 표를 읽는 사람이 얻는 것과 동일한 판결을 받게 됩니다.

다음은 에이전트나 CI 작업이 파싱하는 실제 페이로드(payload)입니다. 우리는 memtrust 0.3.3 버전을 대상으로 실행한 실제 memtrust run --backends mempalace,mem0,zep,openviking --eval all 호출에서 이를 직접 추출했습니다. 이 실행에는 구성된 자격 증명(credentials)이 전혀 사용되지 않았으며, 출력 결과는 전혀 수정하지 않은 상태입니다.

{
  "mempalace": {
    "status": "skipped",
...

출력은 엄격한 키-값(key-value) 쌍으로 이루어져 있습니다. status 및 missing_env_var 필드는 프로그램이 즉시 조치를 취할 수 있도록 기계가 확인 가능한 데이터를 제공하며, 이는 언급할 가치가 있는 설계 선택입니다.

우리는 이전 실행의 JSON을 다시 읽고 서식이 지정된 요약본을 출력하기 위한 memtrust report <path> 서브커맨드(subcommand)를 추가했습니다. 이는 평가(eval)를 실행하는 에이전트와 이를 검토하는 사람 또는 시스템이 서로 별개의 프로세스일 때 유용합니다.

하지만 파서(parser)가 이를 잘못 처리할 수 있는 쉬운 방법이 하나 있습니다. 구성된 자격 증명 환경 변수(credential environment variable)가 누락된 백엔드(backend)는 실행을 계속 유지합니다. 즉, 해당 백엔드의 섹션에 SKIPPED를 출력하고 계속 진행합니다. CI에서 무인으로 실행되는 CLI는 반드시 이런 방식으로 동작해야 합니다. 특정 백엔드의 API 키가 누락되었다고 해서 나머지 평가 스위트(eval suite)의 완료를 중단시켜서는 안 되기 때문입니다. 하지만 이는 JSON을 파싱하는 프로그램이 각 백엔드 고유의 status 필드를 확인해야 함을 의미합니다. 만약 명령의 종료 코드(exit code)에만 의존한다면, 건너뛴(skipped) 백엔드가 실제로 통과(passed)했다고 잘못 가정하게 될 것입니다.

또한 CLI에는 memtrust keygen으로 생성된 Ed25519 키 쌍(keypair)을 기반으로 하는 --sign 플래그가 포함되어 있습니다. 이는 JSON 보고서와 함께 서명된 영수증을 작성하며, 이 서명은 어떤 키가 파일을 생성했는지와 내용이 변경되지 않았음을 증명합니다. 우리는 이를 에이전트 간 소비(agent-to-agent consumption)를 위해 구축했습니다. 구조화된 출력(structured output)은 이를 읽는 에이전트가 출처를 검증할 수 있을 때에만 의미가 있으며, 서명되지 않은 JSON 파일은 위조하기가 매우 쉽기 때문입니다. 서명은 일반적인 실행에서는 선택 사항으로 유지되지만, 신뢰 경계(trust boundary)를 넘나들어야 하는 보고서를 위해 준비되어 있습니다.

에이전트 도구 배포에 대한 현재 접근 방식

기존의 여러 관행이 에이전트-도구 배포 간극을 메우려고 시도하고 있습니다. 각 방식이 실제로 무엇을 해결하는지, 그리고 어디에서 한계가 있는지를 정확하게 짚어볼 가치가 있습니다.

에이전트-도구 호출 (agent-tool-calling)을 위한 프로토콜 수준의 표준은 도구 호출 (tool invocation)에 대한 직접적인 해답을 제시합니다. 2024년 11월에 도입되어 2025년 12월 Linux Foundation 산하의 직접 기금인 Agentic AI Foundation에 기부된 Model Context Protocol은, 해당 발표 당시 월간 SDK 다운로드 수가 9,700만 회를 넘었으며 10,000개 이상의 활성 공개 서버를 기록했다고 보고되었습니다. 프로토콜 표준은 호출 계약 (invocation contract) 문제를 해결합니다. 즉, 도구가 자신의 기능을 어떻게 설명하는지, 그리고 에이전트가 이를 어떻게 예측 가능한 형태 (predictable shape)로 호출하는지를 정의합니다. 하지만 근본적인 도구는 여전히 진실된 값을 반환해야 할 완전한 책임을 집니다. 봉투 (envelope)를 표준화한다고 해서 그 내용물까지 완전히 검증되는 것은 아닙니다.

**pip 및 npm의 기본 동작을 포함한 전통적인 패키지 관리자 설치 흐름 (package-manager install flows)**은 판단을 내리기 위해 터미널 출력을 읽는 사람이 필요합니다. 사용자는 프롬프트를 수락하고, 경고를 인지하며, 스택 트레이스 (stack traces)를 해석해야 합니다. 기본 pip install 또는 npm install은 비정형 텍스트 (unstructured text)를 출력하는데, 이는 이 도구들을 설계한 사람들이 이를 파싱하는 프로그램이 아니라 터미널을 지켜보는 사람을 위해 만들었기 때문입니다.