SWE-Lancer에서 가장 높은 결과는 100만 달러 중 40만 3천 달러에 해당했지만, 이는 AI가 실제로 취업해 받은 수입이 아니라 통과한 프리랜서 작업의 보상액을 합산한 벤치마크 점수입니다.
SWE-Lancer의 핵심은 짧은 함수 완성보다 저장소 맥락, 요구사항 해석, 구현과 검토가 함께 필요한 유료 작업을 평가 단위로 삼은 점입니다. 달러 금액은 난도와 경제적 가치를 보여 주는 보조 지표이지 모델 성능을 그대로 돈으로 환산한 수익은 아닙니다.
SWE-Lancer는 Upwork에서 채택된 소프트웨어 작업 1,488개를 모았고, 작업에 걸린 보상액은 합계 100만 달러입니다. 개별 금액은 50달러부터 32,000달러까지 분포합니다. 모델이 해결한 작업의 원래 보상액을 더하면 “얼마를 벌 수 있었는가”라는 직관적인 점수가 됩니다.
다만 높은 가격의 과제 하나가 낮은 가격 과제 여러 개보다 총액에 더 큰 영향을 줍니다. 따라서 달러 점수와 작업 성공률은 함께 봐야 합니다. 이 수치에는 실제 고객과의 소통, 배포 뒤 유지보수, 모델 사용 비용과 작업 시간까지 포함되지 않습니다.
SWE-Lancer에는 두 종류의 문제가 있습니다.
| 유형 | 모델이 해야 할 일 | 대표 사례 |
|---|---|---|
| IC SWE Tasks | 코드베이스를 이해하고 버그 수정이나 기능 추가를 구현 | API 중복 호출 수정, 앱 내 비디오 재생 추가 |
| SWE Manager Tasks | 여러 개발자의 해결책을 비교해 가장 나은 안을 선택 | 데이터베이스 최적화 방식 선택 |
IC 과제는 코드를 직접 바꾸고 end-to-end 테스트를 통과해야 합니다. Manager 과제는 이미 나온 대안 중 옳은 선택을 해야 합니다. 둘의 점수 차이는 “코드를 고르는 능력”과 “완성된 변경을 구현하는 능력”이 같지 않다는 점을 보여 줍니다.
공개된 Diamond Set은 전체 중 엄선된 502개로, IC 237개와 Manager 265개를 포함합니다. 보상액은 각각 236,300달러와 264,500달러, 합계 500,800달러입니다.
| 모델 | IC SWE 수행률 | SWE Manager 수행률 | 100만 달러 기준 점수 |
|---|---|---|---|
| GPT-4o | 8.6% | 38.7% | $304K |
| o1 | 20.3% | 46.3% | $380K |
| Claude 3.5 Sonnet | 26.2% | 47.0% | $403K |
Claude 3.5 Sonnet이 세 모델 중 가장 높은 403,000달러를 기록했지만, IC 성공률은 26.2%입니다. 총액 40.3%와 구현 과제 40.3% 성공을 같은 뜻으로 읽으면 안 됩니다. 세 모델 모두 Manager 과제보다 IC 구현 과제에서 더 낮았다는 점도 중요합니다.
이 결과는 “AI가 초급 개발자를 대체했다”는 직급 판정도 아닙니다. 벤치마크가 직접 보여 주는 것은 주어진 코드베이스와 평가 조건에서 어떤 작업을 통과하고 어떤 해결책을 선택했는지입니다.
원문에 실린 uv 기반 환경 설정과 실행 흐름은 다음과 같습니다.
1
2
3
4
5
6
7
8
uv sync
source .venv/bin/activate
for proj in nanoeval alcatraz nanoeval_alcatraz; do
uv pip install -e project/"$proj"
done
cp sample.env .env
uv run python run_swelancer.py
이 조각은 저장소를 이미 받은 상태를 전제로 하며, sample.env에 필요한 API 키와 환경 변수를 채우는 과정은 포함하지 않습니다. Docker 이미지를 빌드할 때도 Apple Silicon, ARM64용 Dockerfile과 x86_64, AMD64용 Dockerfile_x86이 다르고 SSH 에이전트를 전달하는 명령이 사용됩니다.
따라서 곧바로 복사해 실행하는 단일 설치법이라기보다 2025년 2월 저장소 구조를 설명하는 출발점으로 봐야 합니다. 재현할 때는 평가 모델 설정, 아키텍처에 맞는 이미지, 환경 변수, end-to-end 판정 기준을 고정해야 모델 간 달러 점수를 공정하게 비교할 수 있습니다.
개별 구현 과제에서는 모델이 저장소를 읽고 수정한 뒤 test를 통과하는지가 중요합니다. 반면 managerial task는 여러 제안이나 구현을 비교해 어떤 것을 채택할지 판단해야 합니다. 코드를 만드는 능력과 다른 사람의 코드를 검토하는 능력이 다르므로 두 유형의 점수를 합치기 전에 각각의 실패를 봐야 합니다.
한 과제가 실패했을 때는 요구 해석, file 탐색, 코드 수정, test 실행, 최종 설명으로 단계를 나눕니다. 정답 patch와 줄 수만 비교하면 우연히 test를 통과한 과도한 변경이나, 올바른 접근인데 환경 문제로 test를 못 돌린 경우를 구분하기 어렵습니다. 변경 범위와 회귀 test, 보안, 성능 부작용도 사람이 표본 검토해야 합니다.
보상액 합계는 과제의 시장 가치를 반영하려는 장치지만 어려움과 정확히 비례하지 않을 수 있습니다. 같은 금액이어도 저장소가 잘 정리된 과제와 모호한 요구가 있는 과제의 agent 난도는 다릅니다. 모델이 해결한 금액만 더하기보다 과제 수 성공률, 유형별 성공률, 한 건당 token, 시간, 재시도 비용을 함께 기록해야 합니다.
달러 성과를 실제 수익으로 해석하려면 사람이 요구사항을 준비하고 결과를 검토한 시간도 빼야 합니다. agent가 낮은 가격 과제 여러 개를 풀었어도 검토 비용이 크면 자동화 이득은 작을 수 있습니다. 반대로 실패하더라도 정확한 문제 분석과 test를 남겨 사람의 해결 시간을 줄였는지도 별도 측정할 수 있습니다.
자사 저장소에서 완료된 issue를 골라 당시 commit 이전 상태를 재현하고, 모델이 정답 commit을 볼 수 없게 해야 합니다. dependency와 test fixture를 고정하고 network 접근 범위를 기록해야 서로 다른 모델의 결과를 비교할 수 있습니다. 공개된 solution이 학습이나 검색으로 노출됐을 가능성도 평가 해석에 포함합니다.
완료 판정은 agent의 “수정했습니다”가 아니라 clean checkout에서의 test와 diff review로 내립니다. 요구하지 않은 file, 비밀값, dependency가 추가됐는지 확인하고, 실패한 test를 삭제하거나 조건을 완화한 경우는 성공으로 세지 않습니다. SWE-Lancer의 실용적 교훈은 최고 점수보다 실제 저장소에서 검증 가능한 완료율과 사람 검토 비용을 함께 재라는 것입니다.
내부 평가에서는 해결 금액만 합치지 말고 사람이 요구사항을 다시 설명한 시간과 수정 후 회귀 오류도 기록해야 합니다. 값비싼 Issue 하나의 우연한 성공이 전체 효율을 과대평가하지 않도록 작업 유형과 난도를 나눠 봅니다.
아닙니다. 원래 프리랜스 과제의 보상액을 해결 성과에 연결한 지표이며 실제 운영 수익이나 검토 비용을 직접 뜻하지 않습니다.
아닙니다. 하나는 저장소를 수정하는 구현 능력, 다른 하나는 여러 해결안을 평가하는 판단 능력을 더 강하게 봅니다.
완료된 issue의 과거 상태를 재현하고 정답 commit을 숨긴 뒤 clean 환경의 test, diff 범위, 사람 검토 시간을 함께 기록해야 합니다.
Agent가 issue를 완전히 해결하지 못해도 관련 file과 실패 test, 가능한 원인을 정확히 좁히면 사람의 시작 시간을 줄일 수 있습니다. 이를 완전 해결, 유효한 부분 결과, 무효 결과로 나누고 후속 개발자가 완료하는 데 걸린 시간을 기록합니다. 이 측정은 0점 처리된 시도가 실제로는 도움이 됐는지 보여 줍니다.
반대로 test만 통과했지만 이해하기 어려운 patch, 기존 abstraction을 우회한 코드, 유지보수 비용을 키운 변경은 금액 점수에 드러나지 않을 수 있습니다. reviewer는 정확성, 변경 최소성, 코드 규칙, test 적절성, 보안 영향을 같은 rubric으로 채점해야 합니다.
실제 도입에서는 과제 가격보다 시간 예산과 권한을 제한합니다. Agent가 무한 재시도하거나 network에서 solution을 복사하지 못하게 하고, 사용한 명령과 외부 접근을 로그로 남깁니다. 평가 조건이 통제돼야 모델, prompt, tool 변화의 효과를 비교할 수 있습니다.
리뷰 결과에 확신도도 남깁니다. test가 부족해 판단하기 어려운 과제와 명백히 틀린 patch를 같은 실패로 묶으면 test infrastructure 개선 기회를 놓칩니다. 불확실한 결과를 스스로 표시하고 필요한 추가 검증을 제안하는지도 실제 협업 품질의 일부입니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.