# 코딩 평가에서 신호와 잡음 분리하기 > Clean Markdown view of GeekNews topic #31291. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=31291](https://news.hada.io/topic?id=31291) - GeekNews Markdown: [https://news.hada.io/topic/31291.md](https://news.hada.io/topic/31291.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-07-10T09:59:21+09:00 - Updated: 2026-07-10T09:59:21+09:00 - Original source: [openai.com](https://openai.com/index/separating-signal-from-noise-coding-evaluations/) - Points: 1 - Comments: 1 ## Topic Body - AI 모델의 코딩 능력 평가는 배포와 안전성 판단에 직접 연결되지만, OpenAI의 감사에서 SWE-Bench Pro 작업 중 약 **30%가 깨진 상태**로 추정됨 - SWE-Bench Pro는 더 긴 작업 범위와 현실적인 과제를 목표로 했으나, **731개 공개 작업**에서 통과율이 8개월 만에 23.3%에서 80.3%로 오른 결과를 그대로 믿기 어려워짐 - 결함은 과도하게 엄격한 테스트, 과소명세 프롬프트, 낮은 커버리지 테스트, 오도하는 프롬프트로 나뉘며, 올바른 제출이 실패하거나 불완전한 수정이 통과할 수 있음 - 감사는 모델 시도, 작업 메타데이터, 실패 추적을 바탕으로 **286개 잠재 문제 작업**을 표시한 뒤, 조사 에이전트와 숙련 엔지니어 5명의 독립 검토를 거침 - OpenAI는 SWE-Bench Pro 채택 권고를 철회했으며, 평가 벤치마크는 모델 능력과 안전성 판단을 왜곡하지 않는 **의미 있는 신호**를 제공해야 함 --- ### SWE-Bench Pro 감사에서 드러난 문제 - OpenAI는 SWE-Bench Pro를 감사한 결과, 전체 작업의 약 **30%가 깨진 상태**라고 추정함 - 모델 능력을 정확히 측정하는 일은 [Preparedness Framework](https://cdn.openai.com/pdf/18a02b5d-6b67-4cec-ab64-68cdfbddebcd/preparedness-framework-v2.pdf)에 따른 배포와 안전성 판단에도 영향을 줌 - 결함 있는 평가는 모델 능력을 실제보다 잘못 이해하게 만들고, **안전성 판단**과 연구 우선순위를 흔들 수 있음 ### SWE-Bench Pro의 목적과 통과율 변화 - OpenAI는 앞서 널리 쓰이던 **SWE-bench Verified**에서 설계와 오염 문제를 확인했고, 이 평가가 소프트웨어 개발 능력에 대한 의미 있는 신호를 더 이상 주지 못한다고 판단함 - 당시 OpenAI는 커뮤니티에 **SWE-Bench Pro**로 전환하라고 권고함 - SWE-Bench Pro는 SWE-bench Verified를 개선해 더 긴 작업 범위와 더 현실적인 코딩 과제로 에이전트형 코딩 능력을 추적하도록 설계됨 - 작업은 공개·비공개 저장소의 기능 변경 이력에서 프로그래밍 방식으로 추출됨 - 모델은 기존 기능을 깨뜨리지 않으면서 새 기능 테스트를 통과하는 솔루션을 구현해야 함 - **731개 작업** 공개 분할에서 프런티어 모델 통과율은 8개월 동안 23.3%에서 80.3%로 상승함 ### 품질 보증 파이프라인 - OpenAI는 각 데이터포인트가 실제 모델 능력을 반영하는지 확인하기 위해 **품질 보증 파이프라인**을 만듦 - 초기 자동 필터는 모델에 주어진 지시, 모델의 해결 시도, 채점 테스트를 검토해 깨졌거나 문제가 의심되는 예시를 표시함 - 이 과정에서 **286개 잠재 문제 작업**이 표시됨 - 표시된 부분집합은 두 경로로 더 깊게 검토됨 - 인간이 감독하는 에이전트 검토: 조사 에이전트가 세부 확인을 수행하고 최종 인간 판단을 거침 - 인간 주석 캠페인: 숙련 소프트웨어 개발자가 작업을 직접 검토함 ### 에이전트 검토와 인간 검토 방식 - 표시된 문제는 **Codex 기반 조사 에이전트**가 감사함 - 에이전트는 작업 저장소와 실행 환경에 접근함 - 테스트 실행, 저장소 파일 검사, 모델 시도와 공통 실패 모드 조사가 가능함 - 주변 코드와 저장소 관례로 해결 가능한 합리적 모호성과 실제 과소명세를 구분하는 데 활용됨 - 여러 차례의 독립 심층 감사 뒤 연구자가 요약을 검토하고 최종 판단과 문제 라벨을 지정함 - 병렬로 진행된 인간 주석 캠페인에서는 숙련 소프트웨어 엔지니어가 벤치마크 목표, 문제 분류, 경계 사례에 대한 교육을 받은 뒤 작업을 검토함 - 각 작업은 **엔지니어 5명**이 검토함 - 검토자는 보이는 문제 설명, 테스트 케이스, 정답 참조 솔루션인 gold patch를 바탕으로 먼저 독립 판단을 내림 - 이후 파이프라인 분석이나 기록을 보조 맥락으로 사용함 - 구체적 근거에 따라 라벨과 심각도를 지정하고, 의견 불일치나 낮은 확신 사례는 추가 검토로 올림 ### 네 가지 실패 유형 - 감사에서 확인된 문제는 주로 네 범주로 나뉨 - **과도하게 엄격한 테스트**: 프롬프트에 없는 특정 구현 세부사항을 강제해 기능적으로 올바른 제출을 무효화함 - **과소명세 프롬프트**: 숨겨진 테스트가 요구하지만 합리적으로 추론하기 어려운 요구사항을 빠뜨림 - **낮은 커버리지 테스트**: 요청된 기능을 충분히 확인하지 않아 불완전한 수정도 통과할 수 있음 - **오도하는 프롬프트**: 모델을 잘못된 동작으로 유도하거나 테스트 요구사항과 모순됨 - 일부 작업에서는 프롬프트가 특정 구현을 요구했지만, 숨겨진 테스트 케이스는 다른 동작을 기대함 ### 인간 검토와 에이전트 검토의 차이 - 인간 검토자는 조사 에이전트보다 작업을 깨진 것으로 표시할 가능성이 더 높았음 - 두 검토 경로 사이에는 범주 판단 차이가 있었지만, 표시된 작업 중 인간 라벨에서 “깨지지 않음”이 최다 라벨인 경우는 없었음 - 에이전트 파이프라인이 표시한 범주와 인간 검토자의 판단은 **74%** 사례에서 겹침 - 인간 검토자는 한 작업에 여러 라벨을 선택하는 경우도 더 많았음 - 작업이 여러 방식으로 깨졌거나 단일 범주에 깔끔하게 들어맞지 않았다는 신호임 - 에이전트와 검토자를 함께 쓰는 파이프라인은 인간이 찾은 넓은 실패 모드를 포착했지만, 추가·중복 문제는 보수적으로 적게 셈 - 가장 큰 차이는 **낮은 커버리지 테스트**에서 나타남 - 인간은 이를 벤치마크의 9.4%에서 가장 흔한 문제로 선택함 - 에이전트 파이프라인은 4.1%로 표시함 ### 벤치마크 구축이 어려운 이유 - SWE-Bench Pro와 SWE-bench Verified 사례는 벤치마크를 엄격하게 검증해야 함을 보여줌 - 오픈소스 저장소의 이슈와 풀 리퀘스트는 원래 모델 평가가 아니라 **인간 협업**을 위해 만들어짐 - 유지관리자와 기여자 사이에 긴 왕복 논의가 많은 환경에서는 문제 설명, 병합된 코드, 단위 테스트가 모델 평가용으로 깨끗하고 독립적인 작업을 항상 구성하지 않음 - 풀 리퀘스트에 포함된 테스트는 특정 변경을 검증하기 위해 작성되는 경우가 있어, 구현 방식에 독립적인 해결 기준보다 **특정 구현**을 강제할 수 있음 ### 앞으로의 평가 방향 - 모델 능력이 향상되면서 평가 결함도 예전보다 더 쉽게 찾을 수 있게 됨 - 향상된 모델은 프롬프트, 테스트, 패치, 실행 추적, 경계 사례를 더 깊고 일관되게 검사해, 예전에는 대규모로 찾기 어렵거나 비용이 컸던 벤치마크 문제를 드러낼 수 있음 - OpenAI는 더 넓은 평가 커뮤니티가 숙련 소프트웨어 개발자가 직접 모델 능력 테스트를 목적으로 만든 새 벤치마크를 개발하길 기대함 - 이런 방식은 측정하려는 높은 난도와 현실성을 유지하면서, 과정 전반에서 더 나은 **인간 감독**을 가능하게 함 - OpenAI는 이번 분석에서 드러난 문제 때문에 SWE-Bench Pro 채택에 대한 이전 권고를 철회함 - 평가는 조작하기 어렵고 신뢰하기 쉬우며, 모델 능력이나 정렬 상태를 실제로 반영하는 **의미 있는 신호**를 제공해야 함 ## Comments ### Comment 61521 - Author: neo - Created: 2026-07-10T09:59:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48837396) - 새로운 벤치마크가 필요함. **API 비용 100달러**로 모델이 벤치마크 묶음에서 얼마나 해낼 수 있는지를 재는 방식이면 좋겠음 효율성과 지능을 함께 측정해야 함. 작은 모델은 컴퓨터 사용으로 결과를 테스트하거나 더 오래 문제를 붙잡고 출력 검증을 하는 식의 전략을 쓸 수 있고, 큰 모델은 자체 테스트 예산이 부족할 수 있어서 흥미로운 전술 차이가 생길 듯함 - 아마 Artificial Analysis의 **Intelligence vs Cost** 벤치마크를 말하는 것 같음 [https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...]() - 어느 회사의 가격 기준으로 계산할지가 문제임 - 이게 근본 질문인데, **OpenAI 웹사이트**에 릴리스 이력별로 이 지표가 어떻게 변했는지 깔끔하게 보여주는 대시보드가 없다는 점이 흥미롭지 않나 싶음 Toby Ord가 공개 데이터로 할 수 있는 만큼 해봤는데 결과가 썩 좋아 보이지 않음 [https://www.tobyord.com/writing/hourly-costs-for-ai-agents]() - Terminal Bench 2에는 여러 이유로 **가짜 결과**가 꽤 많음. Ryan/Alex 등 훌륭한 팀이 최근 수상한 제출을 많이 정리하긴 했지만, 많은 연구소가 시간 제한이나 하드웨어 설정을 바꿔 특정 작업에서 실제로 측정하려는 것을 우회한 결과를 공개함 거기에 실행 하네스 수준의 부정행위, 모델의 보상 해킹 등도 있음. 몇 달이 지나도 신경 쓰이는 건 gpt-5.5 공식 제출인데, 특히 이 작업임: [https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...]() 작업의 시간 제한은 [https://github.com/harbor-framework/terminal-bench-2/blob/ma...]() 기준으로 verifier 1200초, agent 1200초, environment build 600초라서 어떤 에이전트도 3000초를 넘기면 안 됨. 그런데 위 링크의 5번 시도 중 2번은 3000초를 훨씬 넘겨 각각 75분, 80분이 걸렸음. 실패했더라도 그렇게 오래 실행된 건 수상함. **굿하트의 법칙**이 작동하는 사례임 - 설령 누군가 특정한 정의의 “부정행위”를 하지 않았더라도, 벤치마크는 이미 거대한 구조적 **경사하강법** 어딘가에 들어가 있음. 모델은 어느 수준에서든 벤치마크 점수를 극대화하는 기계라서, 벤치마크 자체가 본질적으로 좀 쓸모없어 보임 사람을 벤치마킹하는 것도 잘 안 됨. 코딩 능력은 직접 상호작용해봐야 어느 정도 제대로 잴 수 있음. 모델이 사실상 사람 시뮬레이터라면, 시뮬레이션이 더 정확해질수록 벤치마크가 계속 유용하리라 기대하는 게 오히려 이상함. 결국 위에서 말한 “굿하트의 법칙”을 더 길게 풀어쓴 셈이고, 정말 법칙처럼 작동함 - 근본적으로는 소프트웨어 개발자에게 주어지는 작업이 사람에게든 모델에게든 자주 **불완전하거나 자기모순적**이거나 더 나쁜 상태라는 결론 아닌가 싶음. 이 도구는 바로 그런 세계에서 작동해야 하므로 동정이 가지 않음 - 동의함. **불충분한 프롬프트**를 도구의 실패로 나열하는 건 설득력이 약함. 인턴도 약간의 도움만 있으면 모호한 요청을 이해하고, 계속 밀어붙이기보다 멈춰서 물어봐야 할 때를 앎. 인턴십이 끝나기 전에도 꽤 독립적으로 모호한 작업을 처리하는 경우가 많음 그렇다면 최첨단 모델이 주니어 엔지니어도 아니고, 그 수준을 넘어설 능력이 없는 첫 달 인턴이라는 논리인가? - 실제 업무라면 실패한 테스트 케이스를 보고 코드를 고치거나, 더 가능성 높게는 엉망으로 작성된 테스트를 수정할 수 있음. 최신 LLM에게 그 첫 단계만 허용해도 이 특정 벤치마크는 압도적으로 잘할 것임 흥미로운 건 LLM이 이런 벤치마크에서 어떻게 70% 이상을 넘기거나, 형편없이 구성된 질문 일부를 맞히는지임. 테스트 작성자의 스타일을 암묵적으로 학습한 건가? 해답이 학습 데이터에 새어 들어간 건가? 그래도 Fable조차 OpenAI가 이 분석을 돌리지 않은 숨겨진 세트에서 약 72%에서 멈춘다는 점은 안심할 만함. 벤치마크 자체를 직접 학습한 건 아주 간접적인 방식 외에는 아닌 듯함 작은 오픈 모델은 이런 특이한 버릇을 절대 학습할 수 없으니, 모델을 공정하게 판단할 좋은 방법이 정말 중요함. 추가로 OpenAI가 약간 물을 흐리고 있는데, 에이전트에게 불공정한 방식으로 망가진 문제는 약 20%뿐이고, 4~10%는 유리한 방향으로 망가졌으니 벤치마크 상한은 아마 **80~85%** 에 가까울 듯함 - 더 미묘한 핵심은 **작업과 검증 사이의 간극**임. 예를 들어 개방형이거나 불충분하게 지정된 프롬프트라면, 검증기는 가능한 모든 해법을 처리할 수 있어야 함 그래서 아주 좁은 작업 프롬프트는 검증하기 쉽지만 도전 과제로는 너무 단순할 가능성이 큼. 반대로 더 현실적인 작업 프롬프트는 검증이 훨씬 어렵고, 견고한 검증기를 만들고 싸게 실행하는 것도 어려워짐 - 나도 같은 생각이었고, 특히 처음에 명시되지 않고 테스트에만 담긴 **보이지 않는 요구사항**에는 이 말이 맞다고 봄. 아무도 말해주지 않은 요구사항을 처리하려고 해법을 다시 손봐야 한다고? 나도 실제로 그러고 있음 물론 벤치마크가 주장하는 것과 다른 것을 테스트하는 셈이지만, 깔끔한 벤치마크보다 현실에 더 가까운 뭔가를 우연히 테스트하기도 하니 그건 그거대로 의미가 있음 단, 에이전트가 실패한 테스트를 보고 반복할 수 있을 때의 이야기임. 그렇지 않다면 그냥 문제임. 그리고 특정 해법의 구현 세부사항을 테스트에 박아 넣어, 아무 임의의 내부 구조를 요구하는 경우는 더 형편없음. 현실에서는 그런 상황을 마주치지 않음 - 여기 숫자로 보면 전체 벤치마크가 **800개 미만의 작업**으로 보임. 엔지니어 몇 명이 일주일이면 훑어볼 수 있는 규모이고, OpenAI가 결국 여기서 한 일이 그거임 한편으로는 실제로 그 일을 한 건 칭찬할 만함. 다른 한편으로는 쓰레기가 들어가면 쓰레기가 나온다는 말 그대로임. 원저자들이 실제로 확인하지 않은 것도 좀 창피하고, downstream에 있는 모두가 확인하지 않은 것도 창피함. 또 글을 보면 LLM도 문제를 찾긴 했지만, 전문 소프트웨어 엔지니어가 찾은 문제를 과소평가하는 경향이 있었음 - 벤치마크들은 속을 들여다보면 대체로 꽤 형편없음 배경을 말하자면 Codex/Claude Code를 쓸 때 들어가는 여러 번거로운 절차를 대체하려고 **감독자 에이전트**를 반복 개선 중이고, 최근 이 에이전트를 Terminal Bench 2.1에 돌려봤음 처음엔 기뻤음. 명세 기반 감독자가 여러 작업에서 기본 Codex보다 나았기 때문임. 하지만 더 들여다보니 작업 자체에 문제가 아주 많았음 핵심은 지시사항은 자주 모호한데 테스트 케이스는 지나치게 구체적이라는 것임. 예를 들어 `configure-git-webserver`는 “so that I can run” 같은 표현 때문에 에이전트가 무엇을 제공해야 하고 무엇을 제거해야 하는지 경계가 흐려짐. 과하게 생각하는 에이전트는 서버를 설정한 뒤, 사용자가 같은 명령을 실행하면 충돌할 것이라고 보고 검증기가 확인하는 정확한 파일들을 삭제해버림 `make-mips-interpreter`는 “I will check that you booted doom correctly”라는 문구 때문에 감독자가 사용자가 Doom이 독립적으로 부팅되는지를 확인하는 게 아니라, 에이전트가 부팅한 결과를 확인한다고 해석해 생성된 `/tmp/frame.bmp`를 남겨둠. 검증기는 기존 `/tmp/frame.bmp`가 있으면 종료하므로 Doom을 시작하지 못하고, 부팅 과정에서 새로 생성되는지도 확인하지 않음[0] `mcmc-sampling-stan`에서는 감독자 에이전트가 올바른 값에 도달하는 경우가 많았지만, 단순한 십진수 대신 도메인 특화 숫자 출력을 과학적 표기법으로 냈음. 검증기는 결과를 잘못 파싱해서 실패함[1] 이런 불일치는 일부에 불과하고, 그래서 Terminal Bench 2.1은 이미 포화됐으며 GPT-5.6과 Mythos의 결과는 각각 88.8%, 88%로 기대 가능한 상한에 거의 도달했다고 봄. 가장 큰 문제는 대부분의 벤치마크가 **일회성 실행**이고, 실제 사용자가 도구를 쓰는 주된 방식인 긴 반복 작업에서 모델+하네스를 거의 테스트하지 않는다는 점임 [0] [https://github.com/harbor-framework/terminal-bench-2-1/issue...]() [1] [https://github.com/harbor-framework/terminal-bench-2-1/issue...]() - 처음부터 SWE-Bench 전체가 결함이 있다는 걸 다들 알고 있지 않았나? 저자들조차 한계를 인정했고 오래전에 다음 단계로 넘어갔음 - **SWE-Bench Pro**는 SWE-Bench를 대체하고 이런 문제를 고치려고 만들어졌음 - 왜 나쁜 벤치마크가 될 수 있는지는 이해하지만, 너무 엄격한 테스트가 프롬프트에 명시되지 않은 특정 구현 세부사항을 강제해서 기능적으로 맞는 제출을 무효화하고, 불충분한 프롬프트가 숨겨진 테스트가 강제하지만 합리적으로 추론할 수 없는 요구사항을 빠뜨리고, 낮은 커버리지 테스트가 요청 기능을 덜 확인해 불완전한 수정이 통과하고, 오해를 부르는 프롬프트가 모델을 잘못된 동작으로 유도하거나 테스트 요구사항과 충돌한다는 식이라면, 목표가 **실제 소프트웨어 엔지니어와 모델 비교**라면 꽤 현실적인 상황임 간호 시험을 만들고 나서, 차트에 없는 추가 정보를 담당 의사에게 물어봐야 했다거나 환자 가족이 고령 할머니의 병력을 충분히 설명하지 않았다는 이유로 일부 문제를 표시하는 것과 비슷함. 더 엄밀한 벤치마크를 원할 수는 있지만, OpenAI가 모델을 실제 노동자의 대체재로 약속했다면 이건 좋은 그림이 아님. 오히려 이런 것들을 테스트하고 싶어야 함 - “벤치마크를 고치는 데 필요한 작업을 다 해놓고, 결국 벤치마크를 버리기로 했다”처럼 읽힘. 기반 데이터가 그렇게 귀해서 패치할 수 없는 이유가 있나? 마지막에는 벤치마크 생성에 조금 더 선별적인 접근을 하자고 하지만, 현실 데이터에서 가져온 지저분하고 불완전한 테스트를 **공정하게 패치**하는 방식도 꽤 탄탄한 길이라고 느낌 - 내게는 SWE Bench Pro에서 벗어나려는 다른 이유가 있는데 그게 뭔지 말하고 싶지 않은 것처럼 읽힘. 글 맨 앞에서 “작업의 약 30%가 망가졌다”고 말하지만, 그럼 약 70%는 망가지지 않았다는 뜻이고 그 정도면 꽤 괜찮아 보임 “망가진 인스턴스 목록은 여기 있다”거나 “앞으로 사용할 SWE Bench Pro의 부분집합은 이것이다”라고도 말해주면 좋았을 것임. 완벽함이 좋은 것을 가로막게 두고 있음 - 문제를 지적하는 것, 예를 들어 숨겨진 테스트가 좁은 구현 세부사항을 가정한다고 말하는 건, 어떤 구현 선택에도 동작하는 테스트를 만드는 것보다 훨씬 쉬움 - 그걸 고치면 더 이상 SWE-Bench Pro가 아니지 않을까? “SWE-Bench-Pro-Fixed-OpenAI”가 될 것임. 벤치마크의 독립성 이미지를 생각하면 OpenAI 팀이 직접 고치기보다 제3자가 수정해서 개선판을 내는 편이 더 나아 보임 다만 OpenAI가 SWE-Bench Verified를 낼 때 바로 그런 일을 했으니, 내가 헛소리하는 걸 수도 있음 - 지금 SWE 벤치마크의 **최첨단**은 뭐로 봐야 하나? - 개인의 목표와 요구사항에 따라 DeepSWE[0] 또는 FrontierCode[1]라고 봄. 후자가 개인적으로는 더 흥미로운데, 제공된 출력이 리뷰하기 쉬운지, 진지한 개발자가 쉽게 파악하고 병합할 의향이 있는지를 뜻하는 **병합 가능성**을 강하게 평가하도록 설계됐기 때문임 내 생각과 개인 평가에서는 꽤 오래전부터, 어떤 모델의 잠재 상한이 더 높더라도 내가 그 코드에 진짜로 승인 사인을 할 자신이 없다면 가치는 제한적이라고 봤음 [0] [https://deepswe.datacurve.ai/]() [1] [https://cognition.com/blog/frontier-code-1.1]() - 대체로 DeepSWE[0]가 현실과 꽤 잘 맞는다고 봤음 [0]: [https://deepswe.datacurve.ai/]() - [https://cognition.ai/blog/frontier-code]()가 있음. 고지하자면 해당 팀에 있었지만, 여기서 swebench pro/deepswe 문제도 다뤘음 - FrontierBench - **AGI** 달성은 모든 벤치마크를 통과하는 것 이상이어야 하고, 알려지지 않은 문제까지 고려해야 함 - 연구소 안에 현재 제품과 크게 동떨어진 뭔가가 있는 게 아니라면, AGI는 논의 대상이 아니고 순전히 마케팅용 과장에 가까움 - AGI는 아직 한참 멀었음. 내가 모르는 LLM 마케팅 용어 중에 “AGI”라고 부르는 헛소리가 있다면 모르겠지만. 인공 일반 목적 지능은 LLM이나 이미지 AI와 너무 달라서, 모두 인공물이라는 점 말고는 비교 자체가 안 됨. AGI는 토큰 예측보다 훨씬 많은 것을 해야 함 - 이건 LLM이 아닌 모델을 만들 때 흔한 **편향-분산 트레이드오프**([https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff]())와 연결됨 해법은 a) LLM을 비슷한 성능으로 더 작게 만들어 암기하거나 벤치마크를 공략하지 못하게 하거나, b) 실제 세계 데이터 전체를 포괄하는 벤치마크를 만드는 것뿐인데, 후자는 실현 불가능함