DeepSWE 한국어 하락: 점수보다 중요한 과제 유형

DeepSWE 한국어 하락이란 무엇인가#

같은 코딩 과제를 영어와 한국어로 풀었을 때 점수가 얼마나 달라지는지 살펴본 Patty 내부 테스트입니다. 다른 모델들의 한국어 점수는 영어 대비 평균 7.0%p 낮았고, 일부 모델은 최대 17%p 하락했습니다. 이 수치는 언어에 따른 차이에 관한 내부 관찰이지 모델 전체의 순위가 아닙니다.

📸 필요한 증거(미확보): 한국어 화면 스크린샷

방법론: 표본·환경·채점 기준#

확인된 설명은 같은 코딩 과제를 두 언어로 비교했다는 범위까지입니다. 과제 목록과 선정 방식, 표본 수, 비교 모델과 버전, 언어별 문항의 대응 관계, 실행 환경 및 설정, 반복 횟수, 채점 기준과 평균 산출 방식은 확인되지 않았습니다. 이 정보가 없으므로 특정 과제 유형에서 하락이 컸다거나 그 원인이 무엇인지 판단할 수 없습니다.

이 표는 실험 설계를 검토할 때 필요한 항목입니다. 가상의 과제 쌍이나 개별 점수로 빈칸을 채우지 않았으며, 어떤 작업 유형이 원인인지도 추정하지 않습니다.

공개된 내부 수치와 확인 범위#

%p는 두 백분율 점수의 차이입니다. 예를 들어 80%에서 73%로 낮아졌다면 7%p 하락이며, 위 결과의 실제 개별 점수를 뜻하지는 않습니다. 모델별·과제별 점수와 평균의 분모는 확인되지 않아 표에 넣지 않았습니다. 이 평균 하락 수치는 Patty 내부 테스트 결과이며 Mirr 1.0 Pro 모델 페이지에는 표시되어 있지 않습니다.

한계: 과제 편향, 오염, 단일 실행#

과제 선정과 구성은 결과의 적용 범위를 바꿀 수 있습니다. 모델이 평가 과제를 사전에 접했는지, 반복 실행에서 차이가 유지되는지 확인할 자료도 없습니다. 단일 실행이었다고 단정할 근거 역시 없습니다. 따라서 과제 편향, 데이터 오염, 실행 변동성이 결과에 미친 영향은 알 수 없습니다.

이 페이지가 말하지 않는 것: 공식 리더보드가 아니며, 일반 성능 우위가 아닙니다#

이 결과는 공식 리더보드가 아니며 일반 성능 우위를 주장하지 않습니다. 평균 하락만으로 모든 모델이 같은 폭으로 떨어졌다는 뜻도, 한국어 요청의 하락 원인이 번역이나 특정 작업 유형에 있다는 뜻도 아닙니다.

재현 방법과 원본 데이터#

미해결 근거: 확인된 자료에는 언어별 과제 쌍, 실행 설정, 채점 방법, 개별 결과와 원본 로그가 없습니다. 따라서 재현 절차나 공개 데이터셋을 제공한다고 말할 수 없습니다. 독립 검증에는 이 자료와 모델 버전, 반복 횟수 및 집계 방식이 필요합니다.

DeepSWE라는 이름의 외부 자료와 내부 관찰#

이 페이지의 평균과 최대 하락은 Patty 내부 테스트에 귀속됩니다. 외부에 공개된 DeepSWE 자료를 읽었다고 이 내부 평가의 과제와 설정이 확인되는 것은 아닙니다. 2026-11-03 읽은 Agentica의 DeepSWE-Preview 모델 카드는 모델, 학습과 외부 평가 조건을 설명합니다. 그 자료는 이 페이지의 한국어 과제 쌍이나 비교 대상 모델을 공개한 문서가 아닙니다. 따라서 외부 모델 카드의 설정을 내부 실험의 실제 방법으로 옮겨 적지 않습니다.

외부 모델과 내부 평가의 실제 대상 목록을 연결할 정보는 아직 없습니다. 아래의 기호와 요청 예시는 언어별 의미와 가설을 설명하기 위해 작성했으며 실제 내부 문항·실행·점수가 아닙니다. 내부 과제 쌍과 delta 분포, 설정·원본 및 공개 범위는 아직 확인되지 않았습니다.

언어 차이를 보려면 과제가 같아야 합니다#

영어와 한국어 요청이 같은 일을 요구하는지부터 봐야 합니다. 단어를 직역해도 조건의 범위나 의무의 강도가 달라질 수 있습니다. 반드시 지켜야 할 조건을 권장 사항처럼 번역하거나 금지 조건을 빠뜨리면 언어 외의 차이가 생깁니다. 파일명, 코드 조각과 테스트 기준을 그대로 유지했는지도 확인할 항목입니다. 현재 내부 과제 쌍이 없어 이 점을 검토할 수 없습니다. 그래서 한국어 표현 자체가 하락의 원인이라고 단정하지 않습니다. 결과의 방향과 원인의 설명은 다른 주장입니다.

문장 길이와 정보량도 나눠 봐야 합니다. 한국어 요청이 더 길거나 짧다는 사실만으로 어렵다고 판단할 수는 없습니다. 중요한 예외가 어디에 배치됐는지, 용어가 일관적인지와 코드 식별자를 유지했는지가 영향을 줄 수 있습니다. 일반적인 비교 설계에서는 번역의 동등성을 사람이 검토하고 애매한 문항을 표시할 수 있습니다. 이 글은 내부 번역을 사람이 검토했다고 말하지 않습니다. 그런 기록이 없으므로 동등성이 검증됐다고 표현하지 않는 것이 현재의 정확한 한계입니다.

도메인 용어는 특히 조심할 부분입니다. 팀에서 특정 의미로 쓰는 한국어 명사를 일반적인 뜻으로 번역하면 다른 동작을 요청하게 될 수 있습니다. 반대로 영어 식별자를 불필요하게 한국어로 바꾸면 검색과 수정 대상이 달라질 수 있습니다. 자기 평가를 설계하는 독자는 번역할 문장과 유지할 코드·경로를 구분할 수 있습니다. 이 제안은 내부 실패 유형을 보고하는 내용이 아닙니다. 실제 과제별 자료가 없으므로 어느 종류의 번역이 점수를 낮췄는지 알 수 없습니다.

대응 과제의 차이를 읽는 방법#

언어별 평가를 비교할 때는 같은 과제의 결과를 연결해야 전체 평균에 가려진 차이를 볼 수 있습니다. 한 과제에서 영어만 성공하고 다른 과제에서는 한국어만 성공했을 수 있습니다. 두 언어 모두 실패한 과제와 둘 다 성공한 과제도 해석이 다릅니다. 그러나 현재 개별 결과가 없어 이런 분포를 계산하거나 예시 점수를 실제처럼 제시하지 않습니다. 일부 모델의 최대 하락도 모든 모델의 값이 아닙니다.

delta의 부호는 정의와 함께 써야 합니다. 한국어 점수에서 영어 점수를 뺄지, 하락 폭을 양수로 표시할지에 따라 표의 모양이 달라집니다. 이 글의 7.0%p와 17%p는 내부 관찰의 하락 폭입니다. 개별 점수와 기준 영어 점수가 없어 상대 감소율은 계산하지 않습니다. 본문의 80%와 73%도 단위 설명의 예시이며 실제 내부 점수가 아닙니다.

원인 가설은 서로 다른 예측으로 나눕니다#

언어별 차이가 관찰됐을 때 생각할 수 있는 가설은 여럿입니다. 번역된 요구의 차이, 코드와 설명의 연결, 도구 출력의 처리와 실행 환경의 차이를 각각 검토할 수 있습니다. 가설을 나열하는 일은 그 원인이 확인됐다는 뜻이 아닙니다. 내부 원본이 없으므로 특정 가설에 확률이나 순위를 붙이지 않습니다. 독자가 다음 시험을 설계한다면 어떤 자료가 가설을 지지하고 어떤 자료가 반박하는지 먼저 적는 편이 좋습니다. 결과를 본 뒤 그럴듯한 설명만 고르는 일을 줄일 수 있습니다.

번역 동등성 가설을 보려면 요청의 의미를 검토하세요. 도구 출력 처리 가설을 보려면 어느 행동에서 문제가 생겼는지 실제 기록을 봐야 합니다. 실행 환경 가설을 보려면 언어 외의 설정과 자원이 같았는지 확인하세요. 이 세 검토는 다른 자료를 필요로 합니다. 지금의 내부 평균은 어느 검토도 대신하지 않습니다. 이 페이지는 실패한 행동이나 로그를 보지 않았으므로 실제로 무엇이 원인이었다고 서술하지 않습니다. 제안하는 분류를 이미 수행한 내부 분석으로 부르지 않습니다.

반복과 순서가 만드는 혼동#

같은 과제를 두 언어로 실행할 때 이전 결과가 다음 실행에 전달되면 조건이 달라집니다. 세션 기록, 수정된 파일과 캐시 등 무엇을 초기화했는지 평가 설계에서 정하세요. 다만 이 글은 내부 실행에서 이러한 영향이 있었다고 주장하지 않습니다. 실제로 통제했는지도 확인할 자료가 없습니다. 일반적인 제안은 언어 외 조건을 기록하고 서로의 결과를 보여 줬는지 공개하는 것입니다. 이를 수행하지 않은 상태에서 독립된 비교라고 단정해서는 안 됩니다.

실행 순서에 따른 서비스 상태나 자원 차이도 검토할 수 있습니다. 그러나 순서가 다르면 반드시 편향됐다고 말할 수도 없습니다. 자료가 있어야 어떤 영향을 배제하거나 의심할지 판단할 수 있습니다. 반복 실행도 한 번의 우연을 살펴보는 데 도움이 될 수 있지만 데이터 오염이나 번역 오류를 자동으로 없애지는 않습니다. 내부 반복 횟수가 없으므로 단일 실행이라고 부르지 않는 기존 제한을 유지합니다. 불확실성을 정확히 적는 것이 원인을 상상해 채우는 것보다 유용합니다.

업무 도입에서 사용할 수 있는 작은 언어 평가#

독자가 자신의 팀에서 언어 선택을 시험한다면 업무 용어와 수용 기준이 분명한 과제를 고를 수 있습니다. 같은 코드 상태에서 한국어와 영어 요청이 같은 계약을 설명하도록 검토하고 결과를 분리해 보관하세요. 자연스러운 설명, 코드의 정확성과 검증 보고를 따로 볼 수 있습니다. 이 절차는 내부 벤치마크의 재현이 아니며 새 점수표를 만드는 지시도 아닙니다. 실제 계정이나 유료 서비스 실행에는 별도의 승인과 자료 처리 범위가 필요합니다. 이 글을 쓰면서 그런 실행은 하지 않았습니다.

결과를 보고 언어를 선택할 때는 요청을 작성하고 리뷰하는 사람의 부담도 고려할 수 있습니다. 영어로 다시 쓰는 시간이 줄어도 코드 결과가 부정확하면 이득이라고 단정하기 어렵습니다. 반대로 설명이 조금 어색해도 요구를 정확히 지키면 실무에서 수락할 수 있습니다. 어떤 기준을 중요하게 보는지 팀이 정하세요. 평균 하락 하나를 근거로 한국어 사용을 금지하거나 모든 요청을 번역하도록 강제하는 결론은 이 페이지의 내부 관찰이 뒷받침하지 않습니다.

한국어로 시작해 코드 식별자와 오류 출력은 원문으로 유지하는 방식처럼 여러 운영안도 생각할 수 있습니다. 이는 실제로 점수를 개선했다고 확인한 처방이 아닙니다. 자신의 과제에서 입력과 결과를 비교해야 판단할 수 있습니다. 특정 언어로 질문하면 항상 더 잘한다는 주장을 피하고, 실패할 때 어떤 조건을 다시 확인할지 정하는 편이 낫습니다. 모델과 버전, 도구와 과제에 따라 결과가 달라질 수 있다는 범위를 유지하면 한 번의 관찰을 일반 법칙으로 바꾸지 않습니다.

가상 요청 쌍에서 의미가 달라지는 지점#

다음 예시는 실제 내부 문항이 아니라 번역의 동등성을 읽는 연습입니다. 코드 식별자 archived를 보관 상태라고 정의하고, 삭제 상태와는 다르게 둡니다. 영어 요청을 “Exclude archived items, but preserve their source records.”라고 썼다면 한국어의 대응은 “보관된 항목은 결과에서 제외하되 원본 레코드는 유지한다”로 읽을 수 있습니다. 반면 “보관된 항목은 제거한다”만 남기면 결과에서 빼는 것인지 원본을 삭제하는 것인지 범위가 모호해집니다. 두 요청으로 다른 변경이 나왔다면 언어 능력보다 과제 계약이 같았는지 먼저 볼 이유가 있습니다.

이 표의 중요한 구분은 문장 자연스러움과 논리의 동등성입니다. 한국어 문장이 유창해도 금지를 권장으로 바꾸면 허용하는 행동의 집합이 커집니다. 조건부 표시에서 “경우에만”을 빠뜨리면 권한 없는 경우의 동작이 비어 있을 수 있습니다. 이런 차이는 생성된 설명의 말투를 평가하는 것과 다른 검토입니다. 먼저 입력이 같은 계약을 지시하는지 확인해야 출력의 차이를 언어에 따른 결과로 읽을 수 있습니다.

코드 식별자의 보존은 또 다른 분기입니다. 한국어 요청에서 archived를 삭제라고 설명하면 모델이 올바른 필드를 골라도 의미가 어긋날 수 있습니다. 반대로 용어는 정확하지만 식별자를 다른 이름으로 바꾸면 잘못된 필드를 찾을 수 있습니다. 그래서 예시의 검토는 도메인 뜻과 코드 표기를 따로 고정합니다. 이 구분은 한국어와 영어 중 어느 쪽을 우선하라는 처방이 아니라 과제의 같은 부분을 비교하기 위한 계약 설계입니다.

가설을 반박할 관찰까지 정해 보기#

이 반증 지도는 실제 내부 분석 결과가 아닙니다. 원본 없이 어떤 가설이 맞는지 순위를 매기지 않습니다. 대신 특정 설명을 하려면 무엇을 확인하고 어떤 관찰 앞에서 설명을 바꿔야 하는지를 구체적으로 보여 줍니다. 제목의 과제 유형이라는 말도 입력 이해, 대상 식별과 도구 해석처럼 다른 실패 지점을 나누는 데 쓸 수 있지만, 지금 자료로 어느 유형의 하락이 가장 컸다고 결론 낼 수는 없습니다.

평균 차이와 대응 결과는 수학적으로 다른 정보입니다#

설명용 기호로 같은 과제의 영어 점수를 eᵢ, 한국어 점수를 kᵢ라고 두면 차이는 dᵢ = kᵢ − eᵢ로 정의할 수 있습니다. 양쪽이 같은 과제와 같은 가중치를 갖는 조건에서는 평균 차이를 과제별 차이의 평균과 연결할 수 있습니다. 그러나 제외된 과제가 다르거나 모델마다 과제 구성이 다르면 그 연결을 먼저 확인하세요. 이 식은 내부 평균의 실제 산출법이 아니라 대응 비교를 읽는 일반적인 정의입니다.

평균 d만 알면 각 dᵢ의 방향을 모두 알 수는 없습니다. 어떤 과제에서 변화가 없고 다른 과제에서 차이가 커도 같은 평균이 될 수 있습니다. 최대 하락은 가장 큰 하락의 범위를 알려 주지만 그 값에 가까운 모델이나 과제가 얼마나 많은지는 별개입니다. 따라서 평균과 최대를 합쳐 전형적인 사용자의 감소율을 계산할 수 없습니다. 개별 대응 결과와 집계의 단위를 알아야 어떤 업무에 차이가 몰렸는지 읽을 수 있습니다.

모델별 평균을 다시 평균하는 경우도 가중치의 질문이 생깁니다. 모델마다 비교한 과제 수가 같지 않다면 모델을 같은 비중으로 보는 평균과 모든 과제를 합친 평균은 다른 대상을 요약합니다. 반복 실행을 모두 합쳤는지, 과제별로 먼저 요약했는지도 별도 선택입니다. 현재 내부 분모와 가중치가 없으므로 어느 방식이라고 지정하지 않습니다. 이 차이를 설명하면 평균 7.0%p를 개별 모델의 예측값으로 읽지 않아야 하는 이유가 단순한 주의 문구보다 분명해집니다.

외부 DeepSWE 자료가 답하는 질문#

외부 모델 자료는 어떤 모델과 평가에 관한 설명인지 식별하는 출처로 쓰고, 내부 평균의 비교 대상과 방법은 현재 미확인 범위로 둡니다.

SWE-bench 저장소는 이 벤치마크를 GitHub에서 모은 실제 소프트웨어 이슈로 대규모 언어 모델을 평가하는 틀이라고 소개합니다. 코드베이스와 이슈를 받은 모델이 설명된 문제를 해결하는 패치를 만들도록 요구된다는 설명입니다. 이 정의는 외부 벤치마크의 설명이며, Patty 내부 테스트의 과제 정의로 옮긴 것이 아닙니다.

SWE-bench 논문 초록은 평가 틀을 인기 있는 여러 Python 저장소의 실제 GitHub 이슈와 그에 대응하는 풀 리퀘스트로 구성된 문제 묶음이라고 설명합니다. 과제가 실제 이슈와 변경에서 만들어졌다면, 한국어 drop이 어떤 출처의 과제를 썼는지를 적는 것이 기준이 됩니다.

같은 저장소는 추론 단계를 저장소와 이슈를 주고 모델이 수정안을 만들게 하는 단계로 나누고, 평가 과정에서 빌드 로그와 평가 로그를 따로 남긴다고 안내합니다. 기록을 단계별로 나눠 남긴다는 점은 내부 drop의 기록 항목을 설계할 때 참고할 기준입니다.

저장소는 Docker를 써서 평가를 재현 가능하게 만들었고, 2024년 6월 업데이트에서 컨테이너화된 평가 하네스로 옮겼다고 적습니다. 같은 문서는 ARM 기반 시스템에서는 이미지를 로컬에서 빌드하는 별도 옵션을 쓰라고 하고, Docker 데스크톱에서는 가상 디스크 공간을 충분히 늘리라고 안내합니다. 실행 환경이 아키텍처와 자원에 따라 달라진다는 뜻이며, 이 페이지에 기록되지 않은 실행 환경 정보가 어떤 종류인지 구체적으로 보여 줍니다.

다국어 수학 벤치마크 MGSM의 논문 초록은 GSM8K 문제를 사람이 직접 번역해 만든 벤치마크라고 밝힙니다. 이런 번역 과정은 외부 벤치마크가 공개한 설명이므로, 내부 번역에 필요한 검토 절차를 적는 기준으로 쓸 수 있습니다.

Codex 논문 초록은 어려운 문항에서 같은 문제에 여러 샘플을 만드는 반복 샘플링이 작동하는 해법을 얻는 효과적인 전략이라고 설명합니다. 그래서 샘플을 몇 번 만들고 어떤 결과를 채점하는지는 성적을 읽을 때 적어야 할 조건입니다.

공식 SWE-bench 페이지의 기본 Verified 보기는 모든 모델을 같은 실행 환경에서 비교한다고 적습니다. 공통 환경이라는 기준은 한국어 drop의 비교 조건을 적을 때 참고할 항목이 됩니다.

공식 SWE-bench 홈페이지는 SWE-bench Verified가 OpenAI와 함께 만든 판이라고 표시합니다. 기본 보기가 이 판을 쓰므로, 보기의 이름만 보고 과제 묶음을 같다고 보지 않도록 적으세요.

외부 Codex 논문은 독스트링에서 프로그램을 합성하는 과제를 기능 정확성으로 측정한다고 설명합니다. 내부 drop의 채점 기준은 이 방식과 같은지 따로 적으세요.

SWE-bench 논문 초록은 실제 소프트웨어 공학 과제가 차세대 언어 모델을 평가하는 풍부하고 지속 가능하며 도전적인 시험대라고 주장합니다.

SWE-bench 논문 초록은 이 과제가 실행 환경과 상호작용하고, 매우 긴 문맥을 처리하며, 코드 생성을 넘는 복잡한 추론을 요구한다고 설명합니다. 과제 요구가 이렇게 넓으면 실행 환경과 문맥 조건을 점수와 함께 적어야 한다는 뜻으로 읽을 수 있습니다.

같은 README는 추론 단계를 기존 모델에 대해 실행하는 단계로 소개하며, 로컬 모델과 API 모델이 모두 대상이라고 적습니다. 실행 경로가 바뀌면 같은 과제라도 어떤 모델 접근 경로를 썼는지 따로 기록하세요.

Codex 논문 초록은 이 모델이 공개된 GitHub 코드로 미세조정되었다고 소개합니다. 평가 과제와 학습 자료의 관계를 보려면 학습 자료의 출처를 적는 것이 기준이 됩니다.

같은 초록은 GitHub Copilot을 구동하는 제품 버전이 따로 있다고도 밝힙니다. 같은 이름의 모델이라도 연구 버전과 제품 버전을 같은 조건으로 보지 않도록 모델 항목에 함께 적으세요.

실무에서 언어를 고를 때는 이런 구분을 요청서의 품질로 연결할 수 있습니다. 도메인 용어와 코드 식별자를 유지하고, 금지·조건·실패 시 보존을 명확히 쓰면 두 언어의 계약을 비교하기 쉬워집니다. 현재 공개할 수 있는 결과는 Patty 내부 관찰인 다른 모델들의 평균 7.0%p 하락과 일부 모델 최대 17%p 하락이며, 원인·모델별 순위·과제별 분포는 여전히 확정할 수 없습니다.

수정·보완 기록#

평균 7.0%p와 일부 모델 최대 17%p는 허용된 내부 관찰로만 유지했습니다. 원인·과제 유형별 분포·모델 순위를 추정하지 않았고, 원본 데이터와 공개 범위가 없다는 제한을 그대로 남겼습니다.