Parsimony: AI 코딩 에이전트가 추가하는 코드의 양을 측정하는 오픈소스 벤치마크

Parsimony는 AI 코딩 에이전트가 작업을 해결할 때 추가하는 코드의 양을 측정하는 오픈소스 벤치마크로, 단순히 작업을 해결하는지 여부만 보지 않습니다. 기존 벤치마크가 이미 공개한 패치를 재사용하고, 줄 수 대신 구문 수준의 "코딩 단위"를 세며, 삭제된 코드를 차감하여 순증가 수치를 산출합니다. 이 수치는 DeepSWE Python, JavaScript, TypeScript, Go, SWE-bench Verified, SWE-bench Live Lite, SWEeper-Bench PHP의 리더보드에서 모델 간 비교가 가능합니다.

이 프로젝트가 밝힌 동기는 기존 벤치마크가 해결률과 비용만 측정할 뿐 과도한 코드를 제재하지 않아, 장기적으로 코드베이스를 다루기 어렵게 만든다는 것입니다.

Parsimony가 패치를 채점하는 방법

Parsimony는 코드 줄 수가 아니라 코딩 단위 — 문, 호출, 비교, 이름, 리터럴과 같은 구문 요소 — 를 셉니다. 구문 요소를 세는 것은 코드를 더 적은 줄에 몰아넣는 것이 이득이 되지 않음을 의미하며, 삭제된 코드는 차감되므로 보고되는 수치는 순증가 값입니다: 순 단위 = 추가 − 제거.

Parsimony는 아무것도 실행하지 않습니다. 각 공개 패치는 작업의 코드에 적용되며, 변경된 모든 파일의 두 버전이 파싱됩니다. 테스트, 문서, 생성된 파일은 집계에서 제외됩니다. 통과/실패 결과는 원본 벤치마크의 공개 결과에서 가져오며, 테스트를 다시 실행하지 않습니다.

프로젝트의 Method 섹션에는 "Python만 측정된다"고 명시되어 있지만, 사이트는 JavaScript, TypeScript, Go, PHP 리더보드도 게시합니다. 이는 문서화된 제한이라기보다 소스 페이지의 명백한 불일치로 보입니다.

리더보드와 재현성

Parsimony는 7개의 리더보드를 게시합니다: DeepSWE Python, DeepSWE JavaScript, DeepSWE TypeScript, DeepSWE Go, SWE-bench Verified, SWE-bench Live Lite("Live Python"으로 표시), SWEeper-Bench PHP.

각 리더보드는 프로젝트의 GitHub 저장소에 있는 보고서와 매니페스트로 연결되며, 각각 매니페스트와 데이터셋에 대한 SHA-256 해시를 제공합니다. 예를 들어, DeepSWE Python 매니페스트 해시는 c16b15f80c140ffb4f0a548886962dda4173a02893a65b7faa1d6796940ecf65이고 데이터셋 해시는 41a44998c70248e0a3e2a4cf43a8838b70248537d1f3a458838f2f7e09ecef8a입니다. 자체 실행 리더보드에는 사용된 DeepSWE 커밋도 기록되어 있습니다: 0b9fabbb63b9104d678fe965e1632f2dd9eaa2ea.

DeepSWE Python 결과: 34개 작업에 대한 26개 모델

주요 DeepSWE Python 보드는 34개의 DeepSWE 작업에 대한 26개 모델을 다루며, 모델당 136회 시도(작업당 4회 시도)가 포함됩니다. 모델은 해결한 작업에서 추가된 평균 순 단위 수로 순위가 매겨지며, 낮을수록 좋습니다. 사이트는 실패한 시도를 포함한 두 번째 평균, DeepSWE에서 가져온 해결률, 그리고 2026-10-08 기준 Artificial Analysis Intelligence Index도 보고합니다. 이 지수는 모델과 추론 노력으로 매칭된 외부 점수이며 순위에는 영향을 미치지 않습니다.

사이트의 표는 숫자 열에 레이블을 붙이지 않습니다. 아래 레이블은 사이트가 순위 지표와 해결/측정 횟수에 대해 설명한 내용을 따릅니다.

순위	모델	평균 순 단위 (순위 지표)	실패 포함 평균 순 단위	해결률	AA Intelligence Index	측정됨
1	Gemini 3.1 Pro Preview (high)	1479.5	1156.3	8.1%	29.7	11/11
2	Claude Fable 5 (xhigh)	1557.5	1509.1	74.3%	—	97/101
3	Gemini 3.5 Flash (high)	1621.5	1707.6	29.4%	32.6	38/40
4	Claude Opus 4.8 (max)	1621.9	1592.2	63.2%	41.8	83/86
5	Kimi K3 (max)	1641.2	1601.1	67.6%	43.6	89/92
6	Claude Sonnet 5 (max)	1665.9	1563.5	59.6%	38.2	78/81
7	Claude Sonnet 4.6 (high)	1684.5	1587.9	29.4%	—	36/40
8	Qwen3.8 Max (xhigh)	1697.8	1770.5	55.1%	45.4	74/75
9	GLM-5.2 (max)	1733.2	1591.3	41.9%	33.7	53/57
10	Kimi K2.7 Code	1737.3	1600.1	24.3%	25.8	32/33

순위 보드의 하단은 Muse Spark 1.1 (xhigh)이 26위로 평균 2562.3 순 단위와 52.9% 해결률, Muse Spark 1.2 (xhigh)가 25위로 2484.1 순 단위와 50.7% 해결률을 차지합니다. Claude Opus 5 (max)는 23위로 2183.4 순 단위와 74.3% 해결률입니다.

보드의 두 모델은 Artificial Analysis 점수가 없습니다: Claude Fable 5 (xhigh)와 Claude Sonnet 4.6 (high).

자체 실행 모델은 표시되지만 순위에 포함되지 않음

Parsimony는 또한 작성자가 DeepSWE Python 작업의 처음 3–10개를 직접 실행한 흐릿한 모델 세트를 표시합니다. OpenAI 모델에는 pi를, Anthropic 모델에는 Claude Code를 사용했으며, 각 작업의 자체 테스트로 평가했습니다. 이러한 실행은 명시적으로 검증되지 않았으며 순위에 포함되지 않습니다.

이 세트에서 GPT-6 Luna (high)는 3/3 측정 시도에서 15.0% 해결률로 평균 1076.3 순 단위로 가장 낮은 평균을 보여주고, GPT-6 Astra (high)는 4/4 측정 시도에서 66.7% 해결률로 1103.0 순 단위를 보여줍니다. GPT-5.6 Sol (high)은 자체 실행 세트와 공개 보드 모두에 나타납니다. 사이트는 작성자의 실행이 공개 실행의 0.88배 코드를 추가했다고 언급합니다.

지표의 명시된 한계

Parsimony의 자체 Limits 섹션은 이 숫자가 의미하지 않는 것에 대해 이례적으로 솔직합니다.

• 더 작은 것이 항상 더 좋은 것은 아닙니다: 단위는 크기를 측정하지 가독성이나 설계를 측정하지 않습니다.
• 더 많은 코드를 작성하는 모델은 더 많은 작업을 해결하는 경향이 있으며, 26개 이상의 모델이 포함된 보드에서 Spearman 상관계수는 0.33–0.60입니다.
• 모든 모델은 동일한 에이전트인 mini-SWE-agent를 사용하지만, 에이전트는 여전히 작성되는 코드의 양에 영향을 미칩니다.

사이트는 동일한 함수의 두 구현으로 크기와 가독성의 차이를 설명합니다. found 플래그를 설정하는 루프 기반 has_negative와 한 줄짜리 any(value < 0 for value in values) 버전은 동일한 결과를 반환하지만, 둘 중 하나만 짧습니다.

커뮤니티 반응: 간결성 대 가독성

Hacker News 토론은 낮은 단위 수를 좋은 코드의 대리 지표로 취급하는 것에 반대했습니다. 가장 직접적인 반대는 작성자의 순위 미포함 실행에서 이긴 모델이 읽기 어려운 코드를 생성한다는 것이었습니다.

"한편으로는 LLM이 우리 코드베이스에 쏟아붓는 장황함을 측정하고 줄이려는 시도에 절대적으로 동의합니다. 다른 한편으로는 Astra가 이 벤치에서 '이기는' 것은 저에게 좋은 신호가 아닙니다. 제 생각에 Astra는 기본적으로 읽을 수 없는 코드를 생성하기 때문입니다. Astra는 코드 골프를 합니다. 제가 드러낸 선호는 Astra의 난해함보다 Claude의 과도한 주석과 테스트를 원한다는 것입니다." — fastball

두 번째 스레드는 측정보다 실용적인 기술을 요청했습니다. 한 댓글러는 에이전트가 생성한 코드의 복잡성과 장황함을 줄이는 방법이 있는지 직접 물으며, 이를 벤치마킹 문제보다 코드 품질 문제로 보았습니다.

세 번째 주제는 지표 범위였습니다. 한 댓글러는 순환 복잡도를 보조 가독성 지표로 요청하며, AI 관련 및 AI 작성 코드가 점점 더 이 문제로 고통받고 있다고 말했습니다. 다른 댓글러는 더 적은 코딩 단위가 패치를 읽어야 하는 인간의 검토 작업을 실제로 줄이는지 의문을 제기했습니다.

네 번째 주제는 모델 범위였습니다. 한 댓글러는 벤치마크에 일반인이 로컬에서 실행할 수 있는 최고의 코딩 및 작성 모델을 포함해야 한다고 주장하며, 현재 후보로 Q4에서 약 28GB RAM을 사용하는 Qwen 3.8 27B를 언급했습니다. 이는 오픈 가중치와 선도적인 상용 모델 간의 격차를 보여주기 위해서입니다. 같은 댓글러는 로컬 모델이 1년여 전보다 이미 더 낫다고 지적하며, 텍스트-이미지 및 텍스트-음성 모델과 동일한 비교를 했습니다.

한 댓글러는 전제를 완전히 일축하며, 사람들이 벡터 공간이 작동하는 규모를 이해하면 코드 양은 더 이상 중요하지 않을 것이고, AI 시스템에게 복잡성은 큰 문제가 아니라고 주장했습니다.

벤치마크를 북마크하겠다고 말한 댓글러는 측정 측면에서 가치를 설명했습니다: 측정하지 않으면 관리할 수 없으며, 측정을 추상 구문 수준으로 옮기면 주석과 형식의 노이즈 한 겹이 제거됩니다. 그들은 이 분야의 휴리스틱이 여전히 코드 생성 및 파이프라이닝 최적화의 여지를 남기므로 더 많은 실제 경험을 듣고 싶다고 덧붙였습니다.

자신의 벤치마크 추가하기

Parsimony는 외부 결과를 수용합니다. 사용자는 예제 파일을 다운로드하고 자신의 코드 크기 숫자를 채운 다음 열면 동일한 차트와 표를 얻습니다. 파일은 브라우저에 유지됩니다. 형식과 공유 지침은 프로젝트 저장소의 docs/custom-benchmarks.md에 문서화되어 있습니다.