polyforge, MCP 서버용 신뢰성 감사기와 폴백 라우터

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 에이전트가 타사 MCP 도구 서버의 잘못된 응답을 모델이 조용히 흡수하면서 downstream을 오염시키는 문제를 지적했다. 이를 해결하기 위해 각 서버를 9개 신호로 점수화하고 GitHub API로 저비용 신호를 자동 수집하며 점수에 따라 서버를 production·light·dead로 버킷화하는 방식이 도입되었다. 점수는 결정론적이며 유닛 테스트로 검증되고, 폴백 라우터는 가장 건강한 서버로 능력을 라우트하며 dead로 판단된 의존성은 CI에서 실패 처리해 배포를 차단한다. 현재 소스 기반 배포와 라우팅까지만 구현된 초기 단계이며 루브릭 가중치 검증과 PyPI 배포 등이 향후 과제로 남아 있어 커뮤니티 검증이 필요하다.

섹션별 상세

작성자는 에이전트가 외부 MCP 서버에 의존할 때 발생하는 침묵적 실패 모드를 문제로 제기했다. 구체적으로 서버가 깨지거나 동작이 바뀌어도 모델이 예외를 발생시키지 않고 응답을 즉흥으로 보강하면서 downstream 데이터와 의사결정이 조용히 오염되는 현상이 반복되었다. 이 문제로 인해 런타임에서 발견하기 어려운 무결성 손상이 발생하며 사전 차단 메커니즘이 필요하다고 판단되었다. 따라서 외부 서버의 건강 상태를 측정해 배포 전 검증하거나 폴백을 적용하는 시도가 핵심 대응책으로 제시되었다.

프로젝트는 각 MCP 서버를 9개 신호로 점수화하는 규칙 기반 루브릭을 채택했다. 규칙은 마지막 커밋 시점, 단독 유지관리자 위험, CI 상태, 미패치 CVE, 클린 설치 여부, 호스팅 가동 시간, 스키마 안정성 등 구체적 지표들을 포함하며 일부 저비용 신호는 GitHub API로 자동 수집된다. 점수화는 결정론적이며 채점 경로에 LLM을 포함하지 않고 유닛 테스트로 검증되어 재현 가능성과 예측 가능성을 확보했다. 이런 접근은 비정형 모델 추론 대신 명시적 신호 기반으로 의존성 건강을 판단하려는 설계 철학을 반영한다.

프로젝트 헤더 스크린샷으로서 프로젝트명과 '9-point rubric'이라는 핵심 문구를 포함하고 있다. — Screenshot이미지는 저장소 제목과 핵심 태그라인을 캡처해 본문에서 언급한 '9개 신호 루브릭'과 'fallback router'라는 기능 설명을 직접적으로 뒷받침한다. 이 스크린샷은 글에 적힌 점수화 접근과 CI 연동 목적을 시각적으로 확인할 수 있는 근거로 활용될 수 있다.

폴백 라우터는 특정 기능을 제공하는 가장 건강한 서버로 요청을 라우트하는 역할을 수행한다. 라우터는 점수화 결과를 입력으로 받아 능력을 제공할 수 있는 서버를 선택하며, 의존성이 'dead'로 분류되면 CI를 실패시켜 배포 차단을 지원한다. 현재 라우터는 서버 선택까지만 수행하며 실제 MCP 호출 실행은 아직 포함되지 않아 런타임 검증은 별도 구현이 필요하다. 이 설계는 배포 전 보수적 게이트를 만들면서도 런타임 폴백 체인을 별도 단계로 남겨두어 개발의 단계적 확장을 가능하게 한다.

저자는 루브릭 가중치의 타당성 검증과 신호 추가에 대한 피드백을 요청했다. 저장소는 소스 기반 배포를 우선하며 PyPI 배포는 계획 단계에 있고, 커뮤니티에서 제안된 스키마 드리프트 빈도 추적은 현재 추가 작업으로 반영 중이라고 명시했다. 이러한 열려 있는 설계는 실무 검증과 라벨링된 데이터셋에 기반한 가중치 튜닝이 다음 단계임을 시사한다. 따라서 외부 기여와 실제 사용 케이스로부터 수집되는 증거가 향후 신뢰성 판단 성능 향상의 핵심이 될 것이다.

용어 해설

MCP: — MCP는 에이전트가 외부 도구 서버와 상호작용할 때 사용하는 프로토콜 또는 인터페이스를 가리킨다. 이 맥락에서는 모델이 타사 MCP 도구 서버에 요청을 보낼 때 발생하는 실패 모드와 능력 라우팅 문제를 다루는 대상이다. 서버의 가용성이나 스키마 변화가 에이전트 응답을 침묵적으로 훼손할 수 있어 상태 평가와 폴백 라우팅이 중요하다.
지속적 통합(CI)(Continuous Integration (CI)): — CI는 코드 변경을 자동으로 빌드·테스트하는 파이프라인을 의미한다. 이 프로젝트에서는 의존하는 외부 서버가 'dead'로 판단되면 CI를 실패 상태로 만들어 배포 전 문제를 차단하는 데 CI가 사용된다. CI 게이트로 상태 점검을 연동하면 런타임에서 발생하는 침묵적 오류를 사전에 포착할 수 있다.
스키마 드리프트(Schema Drift): — 스키마 드리프트는 외부 API나 도구의 입력·출력 형식이 변경되어 기존 파이프라인이 더 이상 예상대로 동작하지 않는 현상이다. 게시물에서는 스키마 안정성 추적을 점수화 신호 중 하나로 사용하고, 드리프트 빈도를 추적하는 제안이 추가 검토 중이라고 언급되었다. 스키마 변동은 에이전트의 무결성을 해치는 주요 원인 가운데 하나로 지목되었다.
GitHub API: — GitHub API는 저장소 메타데이터를 자동으로 수집하는 데 사용되는 표준 REST 인터페이스이다. 이 프로젝트는 마지막 커밋 시점, 기여자 수, CI 상태 같은 '저비용' 신호를 GitHub API로 수집해 서버 점수화에 활용한다. 자동화된 신호 수집은 점수 결정을 재현 가능하고 deterministic하게 만드는 핵심 요소이다.

언급된 도구

GitHub API중립

저장소의 마지막 커밋 시점, 기여자 수, CI 상태 등 저비용 신호를 자동 수집해 서버 점수화에 활용한다.

PyPI중립

배포 방식으로 계획되어 있으며 현재는 소스 기반 배포가 우선이다.

언급된 리소스

GitHubpolyforge