기능 테스트만 통과한 패치 중 상당수가 리뷰 제약을 못 지킵니다 | DAKER 커뮤니티

2026년 9월 4일 SWE-Gate 논문이 arXiv에 공개되었습니다. 저장소 단위 코딩 에이전트 벤치가 기능 테스트 통과만 보면, 실제 PR 리뷰에서 나온 수용 제약을 놓친다고 지적합니다. SWE-Gate는 기능 정확성과 리뷰 제약 준수를 함께 측정합니다. 실제 풀 리퀘스트 리뷰 댓글에서 제약을 뽑아 수리 인스턴스를 만듭니다. 인스턴스마다 기능 테스트와 제약 테스트, 비준수 패치와 gold 패치를 둡니다. 75개 오픈소스 Python 저장소에서 303개 저장소 단위 수리 인스턴스를 구성합니다. 공통 코딩 에이전트 스캐폴드 아래 능력대가 다른 LLM 백엔드 4종을 실험합니다. 기능 테스트를 통과한 수리 644건 중 221건이 제공된 리뷰 제약을 만족하지 못했습니다. 기능만 보면 에이전트 능력을 과대평가한다고 결론냅니다. 복제 패키지는 GitHub에 있습니다. 오늘 팀은 “테스트 통과”와 “리뷰 제약 통과”를 채점표에 나눕니다.

논문은 2026-09-04 arXiv에 올라왔습니다. 초록은 arXiv:2609.04167에서 확인할 수 있습니다. 영문 제목은 SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents입니다. 저자는 Xin He, Yanlin Wang, Mingwei Liu, Jiachi Chen, Hongyu Zhang, Guanbin Li입니다. PDF는 같은 번호의 pdf입니다. 복제 패키지는 github.com/DeepSoftwareAnalytics/SWE-Gate입니다. 오늘 본문은 제공된 사실과 초록에서 확인한 범위만 옮깁니다. 없는 숫자는 쓰지 않습니다.

리뷰 제약을 벤치에 넣습니다

기존 저장소 단위 소프트웨어 엔지니어링 벤치는 생성 패치가 기능 테스트를 통과하는지를 주로 봅니다. 실제 개발에서는 리뷰 댓글에서 나온 수용 제약도 패치 수락에 영향을 줍니다. SWE-Gate는 이 리뷰 제약 준수를 기능 정확성과 나란히 평가합니다.

제약은 실제 풀 리퀘스트 리뷰 댓글에서 가져오고, 그 제약을 중심으로 저장소 단위 수리 인스턴스를 합성합니다. 각 인스턴스는 기능 테스트와 제약 테스트를 따로 두며, 제약을 어기는 패치와 gold 패치를 함께 제공합니다. 이슈 해결 능력과 리뷰 제약 준수를 분리해 볼 수 있습니다.

DACON·DAKER 제출에서도 “테스트 초록색”만으로 끝내지 말고, 리뷰어가 남긴 제약 목록을 체크박스로 옮깁니다.

보고된 규모와 실패 비율

SWE-Gate는 75개 오픈소스 Python 저장소에 걸친 303개 저장소 단위 수리 인스턴스로 구성됩니다. 소프트웨어 도메인은 다양하다고 적습니다. 세부 저장소 목록은 초록에 없으므로 나열하지 않습니다.

공통 코딩 에이전트 스캐폴드 아래 능력대가 다른 LLM 백엔드 4종을 실험합니다. 모델 이름과 개별 점수는 초록에 없으므로 쓰지 않습니다. 핵심 결과는 기능 테스트를 통과한 수리 644건 중 221건이 제공된 리뷰 제약을 만족하지 못했다는 점입니다.

해커톤 채점표를 만들 때는 기능 통과 수와 제약 통과 수를 별도 열로 둡니다. 배포가 제출입니다. 올린 링크가 제출입니다.

빌더 팀에 옮기는 점검

팀이 오늘 할 일은 에이전트 평가를 “이슈 닫힘” 한 칸이 아니라 “기능 테스트 / 리뷰 제약 테스트” 두 칸으로 나누는 것입니다. PR 템플릿에 리뷰어 제약을 복사해 넣는 칸을 둡니다.

비준수 패치와 gold 패치를 로컬 픽스처로 저장해, 에이전트가 제약을 무시하는지 회귀 테스트합니다. 공통 스캐폴드를 쓸 때는 백엔드 모델을 바꿔도 같은 제약 테스트가 돌아가게 고정합니다.

복제 패키지를 받을 때는 라이선스와 실행 명령을 README에 먼저 적습니다. 출처 arXiv 번호와 GitHub URL을 상단에 둡니다. DAKER 월간 해커톤이라면 데모에 제약 실패 사례 하나를 같이 보여 줍니다.

Controller와 Worker를 나누는 팀이면, 패치 생성 프롬프트와 제약 목록 파일을 한 메시지에 섞지 마십시오. 제약 파일 해시와 테스트 로그 해시를 나란히 둡니다.

도구 권한과 CI 토큰을 쓰는 팀이면 전역 설정을 별도 파일로 둡니다. 시크릿을 프롬프트나 공개 저장소에 넣지 않습니다.

채점표를 제출 문서로 옮기는 방법

SWE-Gate가 강조하는 점은 기능 통과만으로는 실제 수용 요건을 담지 못한다는 것입니다. 팀 문서에도 같은 구조를 둡니다. 인스턴스 수(303), 저장소 수(75), 기능 통과 후 제약 실패(644 중 221)를 표 한 장에 모읍니다.

내부 벤치를 만들 때도 리뷰 댓글에서 제약을 추출하는 절차를 적습니다. 기능 테스트와 제약 테스트를 한 스크립트로 뭉개지 마십시오. 실패 유형을 로그에 태그로 남깁니다.

데모 페이지에는 “기능만 보면 과대평가” 문장을 크게 두고, 바로 옆에 644와 221 숫자를 둡니다. 없는 모델별 리더보드를 만들지 마십시오.

팀 회고에는 “테스트 통과율”과 “리뷰 제약 통과율”을 서로 다른 항목에 적습니다. 한 항목에 섞으면 개선 방향이 흐려집니다.

제출 전에 로컬에서 동일 스캐폴드로 한 인스턴스를 재실행합니다. 결과는 로그만 남기고 과장 문구를 붙이지 않습니다.

리뷰 제약을 CI에 넣는 최소 절차

SWE-Gate는 실제 풀 리퀘스트 리뷰 댓글에서 제약을 가져온다고 적습니다. 팀 CI에도 같은 최소 절차를 둡니다. 이슈 본문과 리뷰 댓글을 제약 파일로 복사하고, 기능 테스트와 제약 테스트를 서로 다른 job으로 돌립니다. 한 job이 실패해도 다른 job 로그가 남게 합니다.

303개 인스턴스·75개 저장소라는 규모는 벤치 소개에만 쓰고, 우리 내부 세트 크기는 따로 적습니다. 기능 통과 644건 중 221건 제약 실패는 과대평가 위험을 설명하는 인용으로만 둡니다.

에이전트 스캐폴드를 바꿀 때마다 같은 제약 픽스처를 재실행합니다. gold 패치와 비준수 패치를 픽스처로 두면, 프롬프트 변경이 제약을 무시하는지 바로 보입니다. 백엔드 모델 네 종을 모두 돌릴 필요는 없고, 우리가 쓰는 백엔드 하나라도 제약 열을 채우면 됩니다.

공개 데모에는 제약 실패 사례 요약과 GitHub 복제 패키지 링크를 나란히 둡니다. 시크릿과 토큰은 CI 시크릿 저장소에만 둡니다.

과대평가를 막는 제출 전 확인

기능 테스트만 초록색이면 에이전트가 리뷰 제약을 지킨 것처럼 보일 수 있습니다. 제출 전에 제약 테스트 job이 실제로 돌았는지 확인합니다. 644건 중 221건 실패 비율은 우리 점수가 아니라 논문 실험 인용입니다. 같은 위험이 우리 파이프라인에도 있는지만 점검합니다.

리뷰 제약이 모호하면 제약 파일을 문장 단위로 쪼갭니다. 한 문장에 여러 요구가 있으면 테스트를 분리합니다. gold 패치가 모든 제약을 통과하는지도 함께 확인합니다.

이 글이 아닌 것입니다

모든 코딩 에이전트가 같은 비율로 실패한다는 뜻이 아닙니다. 보고된 실험 설정에서의 644 중 221입니다.

모델 4종의 개별 점수를 이 글이 확정한다는 뜻이 아닙니다. 초록에 없는 항목은 쓰지 않습니다.

기능 테스트를 없애라는 주장이 아닙니다. 리뷰 제약을 함께 보자는 안내입니다.

DACON·DAKER 공식 우승 공지가 아닙니다. 빌더가 옮길 수 있는 벤치 설계 안내입니다.

GitHub 외 미확인 미러를 이 글이 만든다는 뜻이 아닙니다. 확인된 링크만 씁니다.

오늘 할 일

첫째, 초록과 PDF를 직접 여십시오. arXiv:2609.04167와 pdf를 같은 탭에 둡니다. 제출일 2026-09-04를 메모 첫 줄에 적습니다.

둘째, 복제 패키지를 확인하십시오. SWE-Gate GitHub에서 코드·데이터·실험 결과 위치를 추적합니다.

셋째, 우리 채점표를 기능/제약 두 열로 나누십시오. PR 리뷰 제약을 체크리스트로 옮깁니다.

넷째, 644와 221 숫자는 조건과 같이 인용하십시오. 우리 실측과 섞지 않습니다.

다섯째, 비준수 패치 픽스처를 하나 만드십시오. 제약 무시 회귀를 돌립니다.

여섯째, 공통 스캐폴드와 백엔드 모델을 문서에 고정하십시오. 재현 노트에 해시를 남깁니다.

일곱째, 데모와 채점 로그를 공개 주소로 올리십시오. 배포가 제출입니다. 올린 링크가 제출입니다.

출처: arXiv:2609.04167 — SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents (2026-09-04) · PDF · GitHub