Senior SWE-Bench: 시니어 엔지니어급 에이전트 평가용 오픈소스 벤치마크

 (senior-swe-bench.snorkel.ai)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Senior SWE-Bench는 코딩 에이전트를 과도하게 정리된 주니어 과제가 아니라, 실제 시니어 엔지니어가 맡는 기능 개발·버그 수정·성능 문제에 가깝게 평가하려는 벤치마크임
  • 기능 과제는 자연어 메시지처럼 읽히는 현실적인 지시사항을 쓰고, 제출된 해법에 맞춰 행동 테스트를 만드는 검증 에이전트로 평가 신뢰성을 높임
  • 버그 과제는 사용자 리포트에서 출발해 서비스 실행, 로그, 프로파일링 데이터, 재현 절차 같은 런타임 조사를 요구하는 PR에서 가져옴
  • 점수는 런타임 정합성뿐 아니라 코드베이스 관행 기반 품질 지표를 결합해 tasteful solve를 평가하며, 지시사항에 없는 중요한 관행도 검증 대상이 될 수 있음
  • 리더보드 최고 모델인 Claude Opus 4.8도 Mini-SWE-Agent max 설정에서 pass@1 24.0% 에 그쳐, 상위 모델도 시니어 수준의 정합성과 taste를 갖춘 해결에는 75% 이상 실패함

실제 PR에 가까운 과제 설계

  • Senior SWE-Bench는 코딩 에이전트가 실제로는 시니어 엔지니어처럼 사용되지만, 평가는 주니어용 과제처럼 이뤄지는 간극을 줄이려는 벤치마크임
  • 과제는 라이브러리부터 다중 서비스 애플리케이션까지 여러 저장소의 PR에서 가져오며, 각 저장소에서 수백 개 커밋을 작성한 엔지니어가 만든 PR을 대상으로 함
  • 주요 과제 유형은 두 갈래로 나뉨
    • 여러 단계와 여러 스택에 걸친 기능 PR
    • 상당한 런타임 조사가 필요했던 버그·성능 PR
  • 공개 과제는 50개이며, 비공개 과제도 50개임
  • 포함 저장소 예시는 다음과 같음

기능 과제: 자연어에 가까운 지시사항

  • 기능 과제는 과도하게 세분화된 요구사항 대신 자연어 메시지처럼 읽히는 현실적인 지시사항을 사용함
  • 이런 과제를 안정적으로 평가하기 위해 검증 에이전트(validation agent) 를 도입함
    • 전문가가 설계한 레시피를 사용함
    • 제출된 해법에 맞춰 행동 테스트를 작성함
  • 지시사항은 자연스러운 에이전트 커뮤니케이션을 반영하며, 길이의 중앙값은 SWE-Bench Pro의 31% 수준임

버그 과제: 사용자 리포트에서 런타임 조사까지

  • 버그 과제는 까다로운 사용자 리포트를 반영해, 단순 코드 수정보다 원인 조사와 재현 과정을 더 요구함
  • 과제에는 다음 같은 작업이 포함될 수 있음
    • 서비스 시작
    • 미묘한 런타임 문제 디버깅
    • 로그 확인
    • 프로파일링 데이터 활용
    • 재현 절차 추적
  • 출처는 해결 과정에서 상당한 런타임 조사가 필요했던 PR임

평가 기준: 정합성과 taste를 함께 측정

  • Senior SWE-Bench는 런타임 정합성 테스트와 여러 품질 지표를 결합해 tasteful solve를 채점함
  • 품질 지표는 관찰된 코드베이스 관행을 기반으로 함
  • 검증기와 검증 에이전트는 지시사항에 쓰이지 않았더라도, 코드베이스에서 중요한 관행을 테스트할 수 있음
  • 리더보드의 solve 조건은 다음 항목을 포함함
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

리더보드: 최고 모델도 낮은 pass@1

  • 리더보드는 Tasteful solve rate(pass@1) 기준으로 결과를 보여줌
  • 상위 결과는 다음과 같음
    • Claude Opus 4.8, Mini-SWE-Agent max: 24.0%
    • Claude Sonnet 5, Mini-SWE-Agent max: 19.4%
    • GPT-5.5, Mini-SWE-Agent xhigh: 16.0%
    • Claude Opus 4.7, Mini-SWE-Agent max: 14.1%
    • GPT-5.4, Mini-SWE-Agent xhigh: 14.0%
    • GLM-5.2, Mini-SWE-Agent max: 12.5%
    • Kimi K2.6, Mini-SWE-Agent default: 8.2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8.2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6.1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3.0%
  • 가장 강한 최전선 모델도 시니어 수준의 정합성과 taste를 갖춘 과제를 75% 이상 완료하지 못함

과제 범위와 벤치마크 특성

  • 과제 유형은 feature, bug, perf, migrat로 표시됨
  • 스택은 Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE 등을 포함함
  • 기능 과제는 여러 서비스에 걸칠 수 있으며, 과제당 평균 11개 파일을 건드림
  • 긴 작업 흐름을 요구하도록 설계돼 가장 강한 에이전트도 수백 단계가 필요함
  • 참조 해법의 SLOC와 파일 수는 세 벤치마크에서 동일한 방식으로 측정됨
  • 지시사항 길이는 하네스 보일러플레이트를 제외함
  • 다른 벤치마크의 토큰 수와 단계 수는 각 벤치마크의 자체 보고 지표를 기반으로 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Twitter에서 본 바로는 Tsinghua University의 기계학습 수업에서 학생들에게 최대한 많은 LLM이 실패하는 퀴즈를 만들게 하는 시험이 있었다고 함
    이런 방식의 벤치마크를 만들고 ELO 점수를 붙이면 어떨까 싶음. 모델들이 서로 맞붙어 질문, 버그, 미완성 구현을 내고 상대가 답하거나 고치거나 완성하게 하는 식임

    • 이걸 생성적 적대 신경망(GAN)이라고 부를 수 있겠음 :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • 퇴화 전략을 어떻게 막을지가 문제임. 예를 들어 SHA256 해시를 주고 원본 입력을 맞히라고 하면 너무 쉽게 불가능한 문제를 만들 수 있음
      수업에서는 적어도 하나의 LLM은 답을 낼 수 있어야 한다는 규칙을 둘 수 있겠지만, 일대일 대결에서는 어떻게 풀어야 할지 모르겠음
    • 그건 Tsinghua가 아니라 Fudan이었던 것 같음

  • 이 벤치마크가 시간이 지나도 어떻게 관련성을 유지할지 궁금함
    벤치마크가 오픈소스 프로젝트의 기능 구현이라면, LLM이 그 변경사항을 학습 데이터에 포함하고 있을 수 있어서 그대로 또는 약간 바꾼 답을 낼 수도 있음
    반대로 모델의 지식 컷오프 이후 코드 변경만 벤치마크에 넣으면, 시점 T와 T+1의 문제가 달라져서 시간에 따른 비교 가능성이 떨어짐

  • Staff SWE Bench라면 LLM이 애초에 이걸 해야 하는지 의심하고, 프로젝트 전체를 문제 삼고, 코드 병합은 거부하지만 삭제는 기꺼이 할 것 같음

    • 농담처럼 들리지만 실제로 거절은 업무의 핵심이라고 봄. 단순히 “안 돼, 가”가 아니라 한발 물러서서 큰 그림을 요구하고, 조직 전체가 그 프로젝트를 장기적으로 필요로 하고 감당할 수 있는지 보는 건 시작 전 최소한의 절차에 가깝다
      LLM도 이걸 충분히, 어쩌면 우리보다 잘할 수 있을 것 같지만, 그에 맞춰 별도로 훈련되어야 함. 다만 그런 훈련 데이터를 어디서 구할지 잘 떠오르지 않음
    • Principal 버전은 비슷하지만, 유일하게 허용되는 접근법이 전 회사에서 했던 방식이라고도 말함

  • 그래서 내가 늘 Opus 4.8이 GPT 5.5보다 훨씬 앞서 있다고 느낀 이유가 설명됨. 불완전한 요구사항을 받아서 프로젝트에 맞는 합리적인 방식으로 빈칸을 채우는 능력이 정말 좋음

    • 애초에 왜 불완전한 요구사항을 주는지 모르겠음. 두 모델 모두 가정과 엣지 케이스를 따지고 명확화를 위한 질문을 하는 데 능하지만, 명시적으로 요청했을 때만 그런 것처럼 보임. 예를 들면 “브레인스토밍” 같은 기술로 요청할 때임
      두 평가 방식 모두 모델이 모든 가정을 의심하고 질문하도록 충분히 유도하지 않는다고 봄. 사용자가 귀찮아할 수 있어서일지도 모르지만, 그 단계는 거의 필수라고 생각함
      GPT-5 계열은 전부 매우 꼼꼼해서 코드 리뷰와 수학에는 유용했음. 내 업무에는 중요하지만, “미적인” 코드에는 방해가 되는 듯함. 예컨대 가능성이 낮은 엣지 케이스까지 전부 방어하려는 식임
      유연성과 지시 준수 사이에도 절충이 있는 것 같음. 내 경험상 Opus는 가끔 지시를 무시하지만 빈칸을 더 잘 채우고, GPT-5.5는 지시는 더 잘 따르지만 그만큼 경직되는 듯함
    • 가장 좋은 벤치마크는 직접 만든 벤치마크임
      내 경험으로는 Opus가 압도적으로 앞서거나 더 낫지는 않았음. 어쨌든 GPT 5.5에는 Instant, Medium, High, Extra High, Pro가 있는데, 표에서는 Extra High와 비교한 것처럼 보이니 Pro와 비교해야 하는 것 아닌가 싶음
    • 내가 이상한 버블 안에 사는 건지 모르겠지만, 내게는 GPT 5.5가 Opus 4.8보다 훨씬 좋음. 어떻게 평가하는지, 어떤 일을 하는지 궁금할 정도임
      프런트엔드 개발과 디자인처럼 Opus가 더 잘하는 특정 작업은 있지만, 그 외에는 5.5가 그냥 압도함
    • 항상 덜 명시하는 바이브 코더에게는 더 나을 수 있음. 하지만 어느 지점부터 모델이 “요구사항이 덜 명시됐다”고 판단하다가, 실제로는 충분히 명시한 사양을 넘어서는 구현을 해버리는지가 문제임
    • 나도 같은 관찰을 했음. Opus 4.8은 훨씬 성숙했고, 마음에 걸리는 요청에는 되묻거나 반대도 했음. 반면 GPT 5.5는 기꺼이 동의하고 시키는 대로 하지만, 몇 번 다시 시켜야 하는 경우가 많았음
      4.8도 한 번 이상의 프롬프트가 필요하긴 하지만 출력 품질이 훨씬 높고 더 많은 통찰을 줌
      다만 Fable 5는 또 다른 존재임

  • 현재 최고 해결률이 Opus 4.8 기준 24% 인데, 유능한 인간이라면 어느 정도 점수를 받아야 하는 걸까?

    • 아마 최고 모델이 쓰는 걸 인간도 쓸 수 있으니, 그 이상이 아닐까 싶음
      반대로 모델이 인간을 마음대로 부릴 수 있다면 더 높은 점수를 받을지도 궁금함
    • 이 문제들은 전부 이미 해결된 것들이라고 가정하면 100%일 것 같음. 물론 같은 한 사람이 전부 해결한 건 아니겠지만, 모델은 다양한 코드베이스에 잘해야 하는 반면 인간은 한 제품에 특화하고 학습할 수 있음
      제품 작업에 익숙한 개인과 비교하는 건 공정하다고 봄
      Fable이 어떻게 나올지가 더 궁금함

  • 시니어 역할의 가치는 알려진 해법과 전략을 새로운 문제에 적용하는 데 있음. 한 번도 바뀌지 않는 벤치마크가 오래 새로운 도전으로 남을 수 있을지 모르겠음
    괜찮은 벤치마크라면 TRIZ 전체를 이용해 거대한 문제 덩어리를 먼저 만들고, AI가 최적 해법을 추론하는지 봐야 함

  • Snorkel에서 새로운 공개 벤치마크가 나온 건 반가움. 저쪽에서 꽤 정교한 일을 하고 있음

  • Sonnet 5가 Opus 4.8에 꽤 근접한다는 점이 흥미로움

  • 이런 방식이 작동한다면 기술 면접도 자동화할 수 있다는 뜻 아닐까?

  • “You are a senior SWE-Bench reviewer, make no mistakes.”라는 식으로 LLM에게 주관적 판단을 시키는 접근은 근본적으로 결함이 있어 보임
    실현 가능성을 유지하면서 더 나은 방식이 무엇인지는 모르겠음

    • 더 중요한 건, 이게 실제로 작업을 방해할 수 있다는 점임. LLM이 실수를 하면 인정하고 고치기보다 축소해서 넘어가도록 유도될 수 있음
    • 이 방식은 사실상 LLM이 어떻게 행동해야 하는지에 대한 맥락을 심는 것임. “senior reviewer”는 원하는 응답 스타일이고, “SWE-Bench”는 LLM이 작동할 맥락과 영역임
      시스템 프롬프트에서 흔한 방식이고 응답의 프레임을 잡아줌
      예를 들어 “프로그래밍에 대한 뱃노래를 쓰는 해적”, “물리학 기사를 쓰는 뉴스 기자”, “PostgreSQL을 완벽히 아는 시니어 소프트웨어 엔지니어”라고 하면 각각 다른 응답이 나옴
      첫 번째라면 Wellerman풍으로 “There once was a program that was set to C ...” 같은 답이 나올 수 있음
      다만 “make no mistakes” 부분은 의심스러움. 그 문구를 넣었을 때와 뺐을 때 결과를 비교하고, 같은 원하는 행동을 얻는 다른 방법도 시험해보면 흥미로울 듯함
    • “make no mistakes”라는 훈계는 꽤 우스워 보임. YouTube에서도 이미 많이 조롱당했지만, 작동할 법한 방식은 쉽게 상상할 수 있음. 예를 들어 단순히 “작업을 검토하라”로 해석될 수 있음
      물론 이런 비교 측정을 공개적으로 수행해서 합리적 결론에 도달하게 해주는 곳은 없어 보임
답변달기