기술 요약: MPC-Patch-Bench

1. 문제 정의

SWE-bench와 같이 대규모 언어 모델(LLM)의 코드 수리 능력을 평가하기 위한 기존 레포지토리 수준의 벤치마크는 보안 다자간 계산(Secure Multi-Party Computation, MPC) 소프트웨어에 적용하기에는 구조적으로 부적합합니다. 저자들은 일반 목적의 벤치마크를 MPC 도메인으로 이식할 때 발생하는 세 가지 주요 구조적 실패 요인을 식별했습니다:

1. 범용 인프라의 지배력: MPC 레포지토리는 핵심 암호화 로직보다는 범용적인 Python 인프라(CI/CD, API 래퍼 등)로 구성된 경우가 많아, 단순한 벤치마크는 MPC 특유의 추론이 아닌 표준 소프트웨어 엔지니어링을 측정하게 됩니다.
2. 표준화된 테스트의 부재: 가치가 높은 MPC 수정 사항들은 엄격한 추출 파이프라인에 필요한 표준화된 "Fail-to-Pass"(F2P) 및 "Pass-to-Pass"(P2P) 테스트가 결여되어 있는 경우가 많습니다. 예를 들어, 7,305개의 원시 MPC 풀 리퀘스트(PR)에 엄격한 SWE-bench 필터링을 적용했을 때 생존한 사례는 단 42개에 불과했습니다.
3. 기능적 평가의 불충분성: 단순한 기능적 정확성(테스트 통과)만으로는 MPC를 평가하기에 불충분합니다. MPC 패치는 반드시 암호학적 안전성 보장(예: 데이터 비가시성, 비밀 공유 무결성)과 수치적 충실도(예: 유한 환 또는 고정 소수점 드리프트 방지)를 만족해야 하며, 표준 단위 테스트로는 이를 감지할 수 없습니다.

결과적으로, 기존의 MPC 특화 노력은 연산자 수준의 합성이나 단일 프레임워크 작업에 국한되어 있어, 실제 세계의 레포지토리 수준 MPC 수리를 수행하는 LLM 에이전트를 평가하는 데 공백이 존재합니다.

2. 방법론

본 논문은 CrypTen, tf-encrypted, MP-SPDZ, SecretFlow, PySyft 등 5개의 주요 MPC 프레임워크에서 선별된 205개의 완전 검증된 인스턴스로 구성된 레포지토리 수준 벤치마크인 MPC-Patch-Bench를 소개합니다. 구축 및 평가는 다음 두 가지 핵심 프레임워크를 기반으로 합니다:

A. 데이터 큐레이션 프레임워크

이 프레임워크는 2단계 프로세스를 통해 원시 PR을 실행 가능한 벤치마크 인스턴스로 변환합니다:

1. 도메인 특화 큐레이션 에이전트: AI 에이전트가 7,305개의 원시 PR을 세 가지 암호학적 계층을 통해 필터링하여 진정한 MPC 추론을 수행하는 것들만 남깁니다:
   • 계층 1 (프리미티브 체크): 핵심 프리미티브(예: 비밀 공유, Oblivious Transfer)의 조작 여부를 확인합니다.
   • 계층 2 (프로토콜 로직): 수학적 MPC 정확성을 다루는 수정 사항과 일반적인 시스템 래퍼를 구분합니다.
   • 계층 3 (도메인 특수성): 해결책이 특수한 제약 조건(예: 데이터 비가시성, 고정 소수점 절단 관리)을 요구하는지 확인합니다.
   • 라우팅: 후보들은 신뢰도 점수에 따라 라우팅됩니다. 높은 신뢰도의 PR은 자동으로 수락되며, 중간 신뢰도의 PR은 인간의 검토를 거칩니다. 이 과정을 통해 후보군이 1,175개의 암호학적으로 관련 있는 후보로 줄어들었습니다.
2. 인간-AI 협업 엔진: MPC PR의 테스트 부족 문제를 해결하기 위해, 인간 전문가가 합성 에이전트와 함께 코파일럿 역할을 수행합니다. 인간은 도메인 직관을 제공하고 암호학적 정확성을 검증하며, 에이전트는 누락된 문제 정의, F2P/P2P 테스트 패치 및 실행 허니스를 합성합니다. 이 과정은 가치는 높지만 불완전했던 PR들을 구제하여, 엄격한 필터링으로 얻은 42개의 인스턴스를 205개의 완전 검증된 인스턴스로 확장했습니다.

B. MPC 검증기 (The MPC Verifier)

LLM이 생성한 패치를 평가하기 위해, 저자들은 기능 테스트를 넘어선 이중 스트림 검증기를 설계했습니다:

1. 동적 테스트 스트림: 평문 오라클(plaintext oracle)에 대해 보안 프로토콜을 실행하여 수치적 충실도 드리프트(정밀도 오류)를 탐지하고, 차분 테스트(differential testing)를 통해 대수적 엣지 케이스를 검증합니다.
2. 도메인 특화 정적 애플리케이션 보안 테스트(SAST): 소스 코드 스캐닝을 수행하여 다음과 같은 MPC 안티 패턴을 플래그 처리합니다:
   • 안전하지 않은 노출 (예: 루프 내부의 reveal())
   • 안전하지 않은 산술 연산 (예: secret-shared 타입에 대한 가공되지 않은 부동 소수점 강제 변환)
   • 잘못된 타입 캐스팅 (승인되지 않은 공개/비공개 변환)
   • 컨텍스트 인식 암호 규칙 위반

3. 주요 기여

• MPC-Patch-Bench: 5개 프레임워크에 걸쳐 205개의 다양한 실행 가능 인스턴스를 포함하며, MPC 소프트웨어 내 LLM 코드 수리를 평가하기 위해 특별히 설계된 최초의 레포지토리 수준 벤치마크입니다.
• 새로운 큐레이션 파이프라인: 도메인 특화 AI 에이전트와 인간-AI 협업을 결합하여 누락된 테스트와 문제 정의를 합성함으로써, MPC 레포지토리의 "테스트 희소성" 문제를 극복하는 방법론을 제시합니다.
• 보안 인식 검증: 동적 차분 테스트와 정적 분석을 통합하여 암호학적 안전성과 수치적 충실도를 강제하는 이중 스트림 평가 프레임워크를 구축하였으며, 이는 일반 목적의 벤치마크에는 없는 기준입니다.

4. 결과

저자들은 8개의 주요 LLM(Claude 3.5/4, GPT-4/5, Gemini 2.5 포함)을 대상으로 벤치마크를 평가했습니다:

• 기능적 해결 (Functional Resolution): 가장 강력한 모델(Sonnet 4.6)조차 205개 작업 중 **22.9%**만을 기능적으로 해결했습니다. 성능은 프레임워크마다 크게 달랐는데, PyTorch 스타일의 라이브러리(CrypTen)는 다루기 쉬웠던 반면, 프로토콜 수준의 시스템(MP-SPZ)은 거의 해결되지 않은 상태로 남았습니다.
• 검증의 영향: MPC 검증기를 적용했을 때 해결률이 유의미하게 감소했습니다. 최상위 모델의 검증된 해결률은 **17.1%**로 떨어졌습니다.
• 기능적 패치의 거부: 기능 테스트를 통과한 패치의 최대 **40%**가 암호학적 또는 수치적 충실도 위반으로 인해 검증기에 의해 거부되었습니다.
• 리더보드 재순위 결정: 보안 검증의 포함은 모델 순위를 변경했습니다. 예를 들어, Opus 4.6은 기능적 해결률이 더 낮음에도 불구하고 검증된 리더보드에서 Sonnet 적을 앞질렀으며, 이는 기능적 정확성과 보안 안전성이 서로 다른 신호임을 입증합니다.

5. 의의 및 주장

본 논문은 기능적 정확성만으로는 개인정보 보호 소프트웨어에서의 LLM 신뢰도를 과대평가하게 된다고 주장합니다. 결과는 MPC 수리가 일반적인 벤치마크가 포착하는 수준 이상의 역량을 요구함을 보여줍니다. 구체적으로:

• 표준적인 Fail-to-pass 평가는 엄격한 보안 및 수치적 충실도 보장을 준수해야 하는 코드에 대해 불충분합니다.
• 표준 테스트를 통과한 패치의 상당 부분이 보안 또는 수치적 검사를 통과하지 못하며, 이는 현재의 LLM이 MPC 엔지니어링의 특정 제약 조건을 다루는 데 어려움을 겪고 있음을 나타냅니다.
• 이 방법론은 정확성이 단순히 테스트 결과 이상에 의해 결정되는 도메인(특히 보안 민감 소프트웨어)에서 LLM을 벤치마킹하기 위한 템플릿 역할을 합니다.

저자들은 현재 5개의 프레임워크만 커버하고 있다는 한계를 언급하며, 향후 완전 동형 암호(FHE) 하이브리드 및 영지식 증명 환경과 같은 다른 암호학적 스택으로 벤치마크를 확장하는 후속 연구를 제안합니다. 또한, 자신들의 큐레이션 파이프라인이 레포지토리 불가지론적(repository-agnostic)이며 다른 전문 분야의 벤치마크를 구축하는 데 재사용 가능하다는 점을 강조합니다.