기술 요약: 변환되었으나 동등하지 않음: 관찰 동등성을 통한 코드베이스 변환 벤치마킹

문제 제기

최근 코딩 에이전트의 발전으로 프로젝트 탐색, 파일 편집, 대규모 소프트웨어 유지보수가 가능한 코드베이스 규모의 협업자가 등장했습니다. 그러나 치명적인 약점이 드러났습니다: 에이전트는 종종 자신의 로컬 검증 루틴을 과도하게 신뢰합니다. 코드베이스 변환 (예: PyTorch 에서 JAX 로 마이그레이션) 의 맥락에서 에이전트는 호출 가능한 진입점, 유한한 손실 (loss), 또는 문법적 유효성과 같은 표면적 검사를 기반으로 성공을 선언하는 경우가 많지만, 실제로 사용자가 의존하는 의미적 계약 (semantic contracts) 은 위반합니다.

코드베이스 변환에 대한 기존 평가 방법은 주로 결과 지향적이며, 숨겨진 평가자 하에서 최종 작업 성공이나 최종 상태 산출물을 비교합니다. 구현 공간에 비해 관찰 가능한 결과가 희소할 수 있기 때문에, 의미 보존 변환에 있어 이 접근법은 불안정합니다. 내부 계약이 극도로 다른 두 코드베이스가 단일 배치에서 거의 동일한 순방향 손실 (forward loss) 을 생성할 수 있지만, 기울기, 옵티마이저 상태, 또는 단시간 훈련 역학에서는 급격히 달라질 수 있습니다. 결과만 비교하는 방식은 얕은 프로브에서의 우연한 일치를 보상하면서 의미적 실패를 탐지하지 못할 위험이 있습니다.

방법론: T2J-Bench

이 평가 격차를 해결하기 위해 저자들은 T2J-Bench를 소개합니다. 이는 코드베이스 변환을 고정된 동등성 계약 하의 전이로 재정의하는 벤치마크입니다. 변환된 코드베이스가 단순히 실행되는지 여부를 묻는 대신, T2J-Bench 는 소스에서 파생된 고정된 일련의 유계 테스트 하에서 변환된 코드베이스가 원본과 동일하게 행동하는지 검증합니다.

핵심 프레임워크

이 벤치마크는 3 단계 순차 검증 프로세스를 통해 작동합니다. 후보 코드베이스는 성공으로 간주되기 위해 각 단계를 순차적으로 통과해야 합니다:

1. Spec (인터페이스 허용성): 변환된 코드베이스가 소스와 동일한 훈련 인터페이스를 노출하는지 검증합니다. 여기에는 파라미터 트리, 배치 스키마, 공개 진입점 확인 및 오류 없이 런타임을 구성할 수 있는 능력이 포함됩니다.
2. Numeric (순방향 출력 및 텐서): 유계 테스트 동안 계산된 특정 산출물을 비교합니다. 여기에는 순방향 출력, 손실, 기울기 및 목적별 텐서 (예: DPO 를 위한 정책 로그 확률, PPO 를 위한 가치 출력) 가 포함됩니다. 비교는 절대/상대 오차, 코사인 유사도, KL 발산에 대해 엄격한 허용 오차를 사용합니다.
3. Behavioral (단시간 역학): 고정된 시드 하에서 로컬 수치적 일치가 짧은 훈련 역학을 보존하기에 충분한지 탐구합니다. 이는 옵티마이저 업데이트, 보상 계산 및 참조 모델 상호작용이 소스와 일관된 궤적을 생성하는지 확인하기 위해 몇 단계의 훈련을 재연하는 것을 포함합니다.

실험 설정

• 작업: SFT(지도 미세 조정), DPO(직접 선호도 최적화), PPO(근접 정책 최적화) 를 위한 전체 PyTorch 훈련 코드베이스를 JAX로 변환합니다.
• 데이터셋: 15 개 모델 계열 (예: LLaMA 변형, Mistral, Qwen) 을 다루는 45 개의 데이터 포인트로, 크기 제약 (<7B 파라미터) 과 유계 구성을 포함합니다.
• 평가 프로토콜:
  • 통제된 베이스라인: 자체 구현된 백본 무관 멀티 에이전트 스케폴드를 사용하여 프론티어 모델 (예: Claude Opus 4.7, Gemini 3.1 Pro, Qwen3 Coder) 을 평가합니다.
  • 네이티브 에이전트: Claude Code, Codex 와 같은 전체 코딩 에이전트 시스템을 네이티브 인터페이스에서 평가합니다.
  • 제약 조건: 평가자 내부 정보를 유출하지 않고 훈련 인터페이스를 고정하기 위해 "최소 제약 프롬프트"($p^\star$) 를 사용합니다. 검증자는 외부에 고정되어 유지됩니다.

주요 결과

355 건의 블라인드 변환 시도 평가는 네 가지 핵심 발견을 도출합니다:

1. 코드베이스 변환은 아직 해결되지 않음: 초기 Spec 단계에서 높은 통과율 (최대 91.1%) 이 있음에도 불구하고, 가장 강력한 시스템의 전체 엔드 - 투 - 엔드 통과율은 @1 기준 **26.7–28.9%**에 불과합니다. 주요 병목 현상은 실행 가능한 코드를 생성하는 것이 아니라 수치적 동등성과 훈련 역학을 보존하는 것입니다.
2. 연산 예산은 약한 해결책: 추론 예산 (토큰 수) 을 늘리는 것은 체감 수익을 가져옵니다. 시도당 토큰 비용이 4.7 배 차이가 나더라도 전체 통과율은 2.2 배 차이만 납니다. 더 많은 토큰을 소비하는 시스템은 종종 반복적인 조사나 장황한 자기 검증을 수행하지만 최종 변환 품질을 향상시키지는 못합니다.
3. 체계적인 과신: 평가된 모든 시스템이 자신의 성공을 현저히 과대평가합니다. 자가 보고된 통과율 (종종 90% 초과) 과 평가자 측정 통과율 (0–29%) 사이의 격차는 66.6 에서 97.8 퍼센트 포인트에 이릅니다. 에이전트는 산출물이 존재하고 잘 형성되어 있는지 (예: "손실이 유한한 스칼라임") 검증하는 경향이 있지만, 이러한 산출물이 소스의 의미와 일치하는지 검증하지는 못합니다.
4. 실패 양상은 계약 불일치: 가장 어려운 실패는 제한된 백본 능력보다는 계약 불일치 자기 검증에서 비롯됩니다. 일반적인 실패 패턴은 다음과 같습니다:
   • Seam 오류: JAX/PyTorch 경계에서의 타입 혼동 (예: PyTorch 임베딩 레이어에 numpy.ndarray 전달).
   • 의미적 대체: forward_loss 슬롯에 DPO 방법 손실을 반환하여 로컬 스모크 테스트를 충족시키지만 평가자가 요구하는 특정 계약을 위반합니다.
   • 기울기/상태 발산: 순방향 통과를 일치시키지만 기울기 노름이나 옵티마이저 상태 업데이트를 보존하지 못함.

중요성과 주장

이 논문은 T2J-Bench 가 결과 지향적 평가에서 계약 지향적 평가로의 필수적인 전환을 제공한다고 주장합니다. 검증을 Spec, Numeric, Behavioral 단계로 분해함으로써 벤치마크는 절대적인 코드베이스 동등성의 불결정성을 우회하면서도 다양한 모델 및 에이전트 시스템 간에 차별성을 유지합니다.

저자들은 현재 코드베이스 변환 regime 에서 다음과 같이 주장합니다:

• 백본 스케일링만으로는 부족함: 최상위 모델과 최하위 모델 간의 격차는 자기 검증과 외부 검증 간의 격차에 비해 작습니다.
• 자기 검증이 주요 병목 현상: 에이전트가 올바른 값을 계산하지 못해 실패하는 것이 아니라, 내부 검증 루프가 "잘 형성된 산출물"을 "의미적으로 정확한 산출물"과 동등하게 취급하기 때문에 실패합니다.
• 향후 개선은 외부 정렬이 필요함: 격차를 해소하려면 에이전트가 자기 일관성 스모크 테스트에 의존하는 대신 소스 비교 루프를 내부화해야 합니다. 이 벤치마크는 이러한 불일치를 식별하기 위한 진단용 스케폴드로 작용합니다.

이 논문은 T2J-Bench 가 PyTorch 에서 JAX 로의 변환에 구체화되었지만, 고정된 동등성 계약과 단계별 검증의 프레임워크가 의미 보존 코드베이스 변환을 평가하는 일반화 가능한 접근법을 제공한다고 결론지었습니다.