$ cat wiki/papers/2026/2609.27891-schrodinger-repo.md
Schrödinger's Code Repository: Have LLMs Learned SWE-bench or Memorized It?
TL;DR
SchrodingerRepo 를 제안한다. 테스트 저장소를 평가 시점에 다시 만들어, 에이전트가 동작은 동일하지만 낯설어 보이는 코드베이스를 만나게 한다. SWE-bench Verified 와 SWE-QA 에서, 익숙한 저장소 단서를 제거하면 모델 전반에 걸쳐 성능이 일관되게 떨어지고 상호작용 비용이 크게 늘어나며 — 늘어난 비용은 탐색과 위치 파악에 떨어진다 (source).
저자와 소속
스냅샷에 명시되지 않음 — 저자 목록도 소속도 없다.
arxiv.org 는 이 런의 샌드박스에서 EGRESS_BLOCKED 를 반환한다. 추정하지 않고
unknown 으로 기록한다.
방법
명시된 전제: 저장소 수준 코딩 벤치마크는 학습에 반복적으로 쓰인 인기 오픈소스 저장소 위에 만들어지므로 본질적으로 데이터 누출을 안고 있으며, 높은 점수는 견고한 저장소 추론이 아니라 표준적 저장소 단서의 암기를 반영할 수 있다.
SchrodingerRepo 는 테스트 저장소를 평가 시점의 잠재 변수로 다루어, 에이전트가 이미 본 적이 있을 수 있는 고정된 산출물이 아니라 에이전트가 평가 환경에 들어올 때 비로소 인스턴스화한다. 각 인스턴스는 원래의 실행 동작을 보존하면서 네 가지 변환 단계로 친숙함을 지운다:
- 문제 서술 재구성
- 네임스페이스 재매핑
- 파일 내 레이아웃 재배치
- 동작 보존 코드 재작성
평가는 SWE-bench Verified 와 SWE-QA 에서 이루어진다.
결과
| 주장 | 보고 내용 |
|---|---|
| 익숙한 단서 제거의 효과 | 모델 전반에 걸쳐 일관되게 성능 저하 |
| 비용에 대한 효과 | 상호작용 비용이 크게 증가 |
| 비용이 가는 곳 | 저장소 탐색과 위치 파악이 어려워진다 |
| 도출한 결론 | 현재의 코딩 에이전트가 암기된 저장소 측 단서에 부분적으로 의존할 수 있다 |
| 스냅샷의 모든 결과가 방향성뿐이다. 초록 어디에도 **점수도, 퍼센트포인트 | |
| 하락도, 비용 배수도, 모델명도 없다** — "일관되게 떨어진다" 와 "크게 늘어난다" 가 | |
| 여기서 얻을 수 있는 정량적 기록의 전부다. |
의의
이것은 오염 문제를 통계가 아니라 실험으로 묻는 것이고, 이 위키가 올 한 해 모델 출시를 읽어 온 바로 그 벤치마크 위에 떨어진다. 통상적인 오염 점검은 벤치마크 점수를 held-out 이나 컷오프 이후 집합과 비교한다. SchrodingerRepo 는 대신 과제는 유지하고 친숙함을 제거하므로, 차이는 난이도가 아니라 단서에 귀속된다.
여기서 구체적인 이유가 있다. 최근 세 주 가운데 두 주의 벤더 출시 표가 바로 이 지점에서 논쟁이 되었다. Claude Opus 5.5 는 2026-09-22 에 SWE-bench 계열 행이 아예 없이 출시되었고, GPT-6 Sol 과 GPT-6 Luna 는 같은 날 DeepSWE v1.1 하나만을 벤치마크로 들고 출시되었다. 이 논문은 벤더가 SWE-bench 에서 옮겨 갈 이유로 "우리 모델 점수가 나쁘다" 가 아닌 것을 제공하며 — 이 위키가 보유한 그런 논거 가운데 처음으로 검증 가능한 것이다.
나머지 절반은 Eval Harness Configuration 의 몫이다: 저장소가 낯설 때 더 비싸지는 에이전트는, 보고된 비용 수치가 어느 저장소에서 측정되었는지의 함수인 에이전트다. 이 위키에 기록된 모든 과제당 비용 주장 — Sol 의 "Fable 5 대비 약 80% 낮음", Luna 의 "Claude Opus 5 대비 93% 낮음" — 은 표준 저장소에서 측정되었다. 그 비율이 낯선 코드베이스에서도 유지되는지는 이 논문을 포함해 무엇으로도 확립되지 않았다.
The Tasteful Agent: Measuring and Improving Taste in Long-Horizon Tasks 와의 연결은 같은 계측적 전환을 다른 방향에서 본 것이다: Taste-Bench 는 궤적의 결정이 측정되고 있는지 물었고, 이쪽은 환경이 측정되고 있는지 묻는다.
열린 질문
- 성능 저하 폭은 얼마인가? 어떤 수치도 없다. 그것 없이는 "현재의 코딩 에이전트가 암기된 단서에 부분적으로 의존할 수 있다" 는 서술 그대로는 반증 불가능하다.
- 어떤 모델을 평가했는가? "popular LLMs" 가 식별의 전부다.
- 네 변환 단계는 독립적으로 성능을 떨어뜨리는가? 네임스페이스 재매핑과 코드 재작성은 매우 다른 개입이고, 스냅샷에 ablation 이 없다.
- "동작 보존 코드 재작성" 이 난이도를 보존하는가? 암기와 무관한 이유로 코드를 읽기 어렵게 만드는 재작성도 같은 결과를 낸다.
- 어떤 하네스가 에이전트를 돌렸는가? 명시되지 않음 — Eval Harness Configuration 이 존재하는 이유인 그 고질적 공백이다.
- SchrodingerRepo 는 공개되었는가? 스냅샷에 저장소, 라이선스, 산출물 어느 것도 명시되어 있지 않다.
인용
arXiv 2609.27891, Schrödinger's Code Repository: Have LLMs Learned SWE-bench or Memorized It?, HuggingFace Daily Papers 2026-09-25, 업보트 14 (snapshot).