한국어 Terminal-Bench 2.1: 우리가 측정한 것과 못 한 것

한국어 Terminal-Bench 2.1이란 무엇인가#

터미널에서 파일과 명령어를 다루며 여러 단계의 작업을 끝내는 능력을 한국어로 측정한 Patty 내부 테스트입니다. 공식 리더보드가 아니며, 아래 점수는 공개된 독립 검증 결과가 아니라 내부 결과입니다.

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

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

확인된 자료에는 테스트의 목적과 내부 점수가 있지만, 과제 목록과 선정 방식, 표본 수, 한국어 과제의 구성, 실행 환경과 설정, 반복 횟수, 채점 기준과 점수 산출 방식은 없습니다. 표본·환경·채점 방식이 다른 평가의 수치와 직접 비교해서는 안 됩니다.

재현 자료를 받을 때는 다음 묶음이 함께 있어야 합니다. 아래는 실제 과제 목록이나 설정값을 공개한 표가 아니라 필요한 원본 자료의 명세입니다.

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

이 점수는 Patty 내부 테스트 결과이며, Mirr 1.0 Pro 모델 페이지에는 이 수치가 표시되어 있지 않습니다. 점수의 분모와 채점 세부 사항은 확인되지 않았으므로 성공한 과제 수나 신뢰 구간으로 해석할 수 없습니다. 다른 모델의 내부 점수도 제품 자료에 기록되어 있지만, 비교에 필요한 표본·환경·채점 세부 사항이 확인되지 않아 여기서는 비교표를 제시하지 않습니다.

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

과제 선정에 따른 편향과 평가 데이터에 대한 모델의 사전 노출 여부는 확인되지 않았습니다. 반복 횟수와 실행별 결과도 없어 변동성을 알 수 없으며, 단일 실행이었다고 단정할 수도 없습니다. 이 점수 하나로 실제 업무 전반의 성능이나 다른 환경에서의 결과를 예측하기는 어렵습니다.

2026-11-03에 읽은 Terminal-Bench 공식 홈페이지는 벤치마크 데이터가 학습 말뭉치에 들어가서는 안 된다는 문구를 게시합니다.

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

이 한국어 코딩 벤치마크는 공식 리더보드가 아니며 일반 성능 우위를 주장하지 않습니다. 특히 이 내부 점수는 Anthropic이나 OpenAI의 모델보다 모든 작업에서 우수하다는 근거가 아닙니다.

재현 방법과 원본 데이터#

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

원본이 제공되면 우선 집계값을 다시 계산하고 실패·미실행이 분모에서 어떻게 처리됐는지 확인하세요. 이 확인 순서를 적었다는 사실이 재현을 수행했다는 뜻은 아닙니다.

2026-11-03에 확인한 terminal-bench-1 저장소 (초기 베타 버전 기준)는 과제마다 영어 지시문, 결과를 판정하는 테스트 스크립트와 기준 해법을 함께 둔다고 설명합니다. 이 구성은 내부 자료에서 빠진 항목을 점검하는 목록으로 쓸 수 있지만, 같은 형식의 한국어 과제가 내부 테스트에 존재한다는 뜻은 아닙니다.

외부 저장소는 Terminal-Bench가 과제 데이터셋과, 언어 모델을 터미널 샌드박스에 연결하는 실행 하네스 두 부분으로 구성된다고 설명합니다. 하네스를 설치하려면 패키지 외에 uv와 Docker 같은 의존성이 필요하고, 리더보드 제출 때는 데이터셋 이름과 버전을 하네스 옵션으로 지정하라고 안내합니다.

내부 점수를 읽는 데 필요한 구분#

92%라는 백분율 표시는 점수의 정의까지 설명하지는 않습니다. 과제별 성공을 평균한 값인지, 여러 조건의 충족을 합친 값인지 현재 자료에는 설명이 없습니다. 아래에서는 점수의 분모, 한국어 범위와 실행 환경을 서로 다른 축으로 읽는 방법을 설명합니다.

평가 이름에 버전이 들어가 있어도 실제 실행 환경이 고정됐다는 뜻은 아닙니다. 과제 묶음의 버전과 모델 버전, 에이전트 및 실행 이미지의 식별자는 다른 항목입니다. 현재 내부 테스트 이름과 외부 프로젝트의 릴리스를 같은 것으로 취급하지 마세요. 2026-11-03 읽은 Terminal-Bench 공식 홈페이지는 현재 다른 버전의 외부 벤치마크를 안내합니다. 그 페이지는 이 한국어 내부 테스트의 과제, 방법이나 원본을 입증하지 않습니다. 이름이 비슷하다는 이유로 외부 방법론을 내부 실행에 소급 적용할 수 없습니다.

이후의 해석 예시는 빠진 자료를 채운 방법론이 아니라 서로 다른 평가 질문을 구분하는 설명입니다.

과제의 난도보다 과제의 범위를 먼저 봅니다#

터미널 과제는 파일을 읽는 일, 명령을 실행하는 일과 여러 결과를 연결하는 일을 포함할 수 있습니다. 그러나 어떤 종류가 실제 내부 표본에 들어갔는지는 현재 알 수 없습니다. 일반적인 평가를 설계할 때는 도구 사용의 종류와 요구하는 최종 상태를 나눠 보는 편이 좋습니다. 문법 오류 하나를 고치는 작업과 여러 파일의 계약을 맞추는 작업은 같은 성공 표시를 받아도 의미가 다릅니다. 과제 유형을 공개하지 않은 점수에서 특정 업무의 강점을 추정하지 않는 이유입니다.

외부 소개 문구는 이 벤치마크가 코드 컴파일부터 모델 학습과 서버 설정까지 실제 종단간 작업을 자율적으로 수행하는지 평가한다고 설명합니다. 저장소는 재현 가능한 과제 묶음과 실행 하네스를 실용적인 실제 환경 평가를 위해 제공한다고도 소개합니다. 같은 홈페이지는 Stanford, Harbor, Laude Institute가 호스팅한다고 표시하고, 과제 목록을 보는 경로도 둡니다. 이 페이지의 한국어 내부 테스트에는 공개된 과제 목록이 없습니다.

저장소에서 과제는 tasks 폴더에 있으며, 현재 과제 목록으로 한눈에 훑어볼 수 있다고 설명합니다. 커뮤니티가 제안한 과제 아이디어를 둘러보는 메뉴도 있고, 리더보드 제출 방법은 별도의 제출 안내 문서에서 다룬다고 적습니다. Terminal-Bench-Core라는 과제 묶음은 베타 릴리스의 과제 집합이며 현재 리더보드와 대응한다고 설명합니다. 이 대응 관계는 어떤 과제 묶음을 기준으로 리더보드를 읽는지 확인하는 출발점이 됩니다.

같은 저장소는 현재 베타 단계이며, 앞으로 텍스트 기반 환경의 AI 에이전트를 위한 포괄적인 시험대로 확장할 계획이라고 적습니다.

같은 저장소는 새롭고 어려운 과제의 기여를 특히 환영한다고 분명히 덧붙입니다.

또한 짧은 과제가 항상 쉽고 긴 과제가 항상 어려운 것은 아닙니다. 짧은 요청에도 숨은 환경 제약이나 정밀한 조건이 있을 수 있습니다. 평가를 읽을 때는 입력 길이보다 수용 기준과 허용 행동을 봐야 합니다. 모델이 필요한 파일을 찾도록 요구했는지, 파일 위치를 미리 알려 줬는지도 조건입니다. 이 글은 내부 과제가 어떤 방식이었다고 말하지 않습니다.

한국어라는 조건도 한 가지로 정의되지 않습니다. 요청만 한국어인지, 파일명과 데이터도 한국어인지, 결과 설명의 언어까지 평가했는지는 다른 문제입니다. 한글 입력을 이해한 뒤 영어 도구 출력을 처리하는 과제와 한국어 문서를 정확히 수정하는 과제는 평가하는 능력이 다릅니다. 공개된 내부 점수에서 이 범위를 확인할 수 없으므로 한국어의 모든 작업에 대한 점수라고 표현하지 않습니다. 실제 업무에 적용할 독자는 자신의 작업에서 어떤 언어 요소가 중요한지 따로 정하세요.

최종 상태와 과정의 안전성을 함께 읽기#

과제 완료를 판단할 때는 최종 파일이 기대와 맞는지뿐 아니라 과제 밖에 어떤 변경이 있었는지도 중요할 수 있습니다. 테스트를 통과했지만 필요한 파일을 삭제했거나 허용하지 않은 외부 행동을 했다면 실무에서는 수락하기 어렵습니다. 일반 평가에서는 이런 조건을 수용 기준에 넣을지 미리 정할 수 있습니다. 다만 내부 채점이 실제로 무엇을 검사했는지는 현재 확인되지 않았습니다.

실패와 미실행도 구분하세요. 모델이 잘못된 수정을 한 경우, 환경을 준비하지 못한 경우와 요청 자체가 실행되지 않은 경우는 원인이 다릅니다. 집계에서는 어느 항목을 분모에 넣었는지에 따라 숫자가 달라질 수 있습니다. 현재 내부 기록의 처리 규칙을 알 수 없으므로 특정 제외나 포함을 가정하지 않습니다.

중간에 사람이 개입했는지도 결과의 해석을 바꿀 수 있습니다. 사람의 힌트, 수정과 환경 준비를 허용한 평가라면 어떤 도움을 포함했는지 밝혀야 합니다. 사람이 고친 최종 상태와 모델의 최초 결과는 다릅니다. 일반적인 평가에서는 둘을 분리해 기록하는 편이 유용합니다. 이 글은 내부 실행에 사람이 개입했다거나 개입하지 않았다고 단정하지 않습니다. 그런 사실을 판단할 원본이 없기 때문입니다.

실행 환경이 바뀌면 결과의 뜻도 바뀝니다#

같은 요청이라도 이미 설치된 도구와 파일, 권한과 네트워크 접근에 따라 수행 가능한 행동이 달라집니다. 인터넷에서 의존성을 내려받을 수 있는 환경과 준비된 파일만 쓰는 환경은 다릅니다. 로컬 저장소의 상태도 결과에 영향을 줄 수 있습니다. 평가를 읽는 독자는 모델만 아니라 실행 환경까지 함께 봐야 합니다. 현재 내부 이미지 digest와 도구 목록이 없으므로 다른 환경에서 같은 점수가 나올 것이라고 말하지 않습니다. 제품을 도입할 때 필요한 접근 조건과도 구분하세요.

권한 제한은 수행 가능한 행동의 집합을 바꿉니다. 읽기 전용 환경의 탐색과 파일 쓰기를 허용한 수정은 다른 과제 조건입니다. 외부 의존성을 받을 수 있는 환경과 준비된 도구만 쓰는 환경도 구분할 수 있습니다. 따라서 평가의 환경 범위를 읽을 때는 도구와 자원, 허용 행동을 연결해야 합니다. 현재 내부 테스트의 권한과 샌드박스·외부 도구 범위는 확인되지 않았습니다.

시간 제한과 자원 제한도 성능의 일부 조건입니다. 어느 순간 실행을 멈추고 어떤 결과를 채점했는지 모르면 미완료의 의미를 알기 어렵습니다. 긴 작업을 기다린 평가와 짧은 제한을 둔 평가의 숫자를 직접 비교하면 안 됩니다. 이 글에서는 내부 실행 시간이나 비용을 추정하지 않습니다. 백분율 표시에서 처리 속도, 작업량과 비용을 역산할 수 없기 때문입니다. 사용자는 자신에게 중요한 일정과 예산의 조건을 별도의 수용 기준으로 정하세요.

반복 실행과 변동성을 읽는 법#

한 번의 결과는 그 실행의 관찰을 보여 줍니다. 반복 결과가 있다면 같은 조건에서 얼마나 달라지는지 살펴볼 수 있지만 반복했다는 사실만으로 모든 편향이 사라지지는 않습니다. 같은 과제를 여러 번 실행한 것과 서로 다른 과제를 추가한 것도 다릅니다. 현재 내부 반복 횟수가 없으므로 단일 실행이라고 단정하지 않으며 반복 평균이라고 설명하지도 않습니다.

2026-11-03에 읽은 외부 홈페이지의 해결률 그래프는 신뢰구간을 표시하고, 순위표에는 비용과 토큰 열이 있습니다.

여러 번 시도해 하나를 고르는 방식과 처음 시도를 채점하는 방식도 구분하세요. 둘 다 평가 목적에 따라 의미가 있을 수 있지만 같은 비용과 기회를 쓴 결과는 아닙니다. 선택 기준에 테스트나 사람의 판단이 들어갔다면 그 과정도 결과의 조건입니다. 이 글은 내부 평가가 어느 방식을 썼는지 모릅니다. 따라서 외부 모델의 처음 시도 성적과 이 내부 수치를 같은 열에서 비교하지 않습니다. 숫자가 백분율이라는 공통점만으로 비교 가능한 측정이 되지는 않습니다.

과제의 종류를 나누면 전체 평균과 다른 질문을 할 수 있습니다. 파일 탐색, 내용 변경과 결과 검증 중 어디에 어려움이 있었는지 구분하는 식입니다. 다만 한 과제가 여러 행동을 포함하면 분류 기준을 먼저 정의해야 합니다. 실패한 항목만 보고 범주를 붙이면 결과를 설명하기 위해 만든 분류가 될 수 있습니다. 아래 질문은 실제 내부 실패 분포가 아니라 자신의 합성 과제를 읽을 때 쓸 수 있는 검토안입니다.

실제 업무에서 점수 대신 확인할 질문#

자신의 저장소에 적용할 때는 모델이 필요한 파일을 찾았는지부터 볼 수 있습니다. 잘못된 경로를 반복해서 읽거나 관련 없는 파일을 고쳤다면 어떤 지침과 입력을 줬는지 확인합니다. 다음으로 요청한 동작과 변경 금지 조건을 지켰는지 봅니다. 마지막에는 검증 명령과 실제 출력을 대조합니다. 이 순서는 도입 시험의 제안이지 내부 벤치마크 재현 방법이 아닙니다. 같은 이름의 점수를 다시 만드는 절차로 소개하지 않으면 적용 범위가 분명해집니다.

합성 과제를 사용하더라도 테스트 대상이 무엇인지 설명하세요. 실제 고객 자료를 지운 저장소와 처음 만든 작은 예제는 조건이 다릅니다. 자신이 만든 예제에 맞춘 결과를 일반적인 제품 우위로 표현하지 마세요. 이 페이지는 새 합성 실행도 수행하지 않았습니다. 앞으로 별도의 승인 아래 얻는 자료가 있다면 사용한 환경과 실행 범위에 한정해 보고해야 합니다.

작은 도입 시험에서 확인할 수 있는 가치는 제한적이지만 구체적입니다. 예를 들어 팀의 테스트 명령을 따르는지, 한글 파일 경로를 정확히 다루는지와 실패를 보고하는지를 관찰할 수 있습니다. 그 결과가 좋으면 더 넓은 시험을 검토할 이유가 되고, 실패하면 필요한 수정이나 지침을 찾을 수 있습니다. 숫자 하나로 모든 선택을 끝내는 것보다 업무와 연결되는 근거가 남습니다.

같은 백분율이 다른 질문에 답하는 이유#

설명을 위해 과제별 판정을 xᵢ, 과제 수를 N이라고 두겠습니다. 모든 과제를 같은 비중으로 평균하면 Σxᵢ / N이라는 형태로 생각할 수 있습니다. 과제별로 여러 조건을 부분 점수로 주는 방식이라면 xᵢ 자체가 성공·실패의 이진 판정과 다릅니다. 난도나 업무 중요도에 따라 가중치 wᵢ를 쓰는 방식은 Σwᵢxᵢ / Σwᵢ가 됩니다. 이것들은 가능한 집계 정의를 대비한 기호이며 Patty 내부 계산식을 공개한 것이 아닙니다.

각 방식은 독자의 질문을 바꿉니다. 동일 비중 평균은 선택한 과제의 평균적인 충족을 묻고, 가중 평균은 지정한 중요도가 반영된 충족을 묻습니다. 부분 점수는 여러 조건 중 얼마나 충족했는지 설명할 수 있지만, 모든 필수 조건을 만족한 과제가 몇 개인지는 다른 정보입니다. 그래서 백분율 하나에서 성공 과제 수를 얻으려면 먼저 xᵢ가 무엇을 뜻하는지 알아야 합니다. 분모를 안다고 해서 부분 점수를 완전 성공의 개수로 바꿀 수 있는 것도 아닙니다.

반복 실행을 넣으면 관측 단위가 하나 더 생깁니다. 과제 i의 실행 j를 xᵢⱼ로 쓰면 과제별 반복 평균을 먼저 구할지, 모든 실행을 한데 평균할지 선택이 필요합니다. 모든 과제의 실행 수가 같다면 두 계산이 같은 조건도 있지만 실행 수가 다르면 과제의 비중이 달라질 수 있습니다. 여러 번 실행한 과제가 전체 계산에서 더 큰 비중을 갖는지와 각 과제가 같은 비중인지가 다른 질문인 것입니다. 내부 반복 수를 가정하지 않고도 집계 단위를 확인해야 하는 이유를 설명할 수 있습니다.

제외 항목도 분모와 연결됩니다. 실행 환경을 시작하지 못한 항목을 별도로 보고하는 안과 실패로 포함하는 안은 다른 대상에 대한 요약입니다. 어느 쪽이 항상 정답이라고 여기서 정하지는 않습니다. 평가 목적이 모델의 해결 능력인지 전체 실행 체계의 완료 능력인지에 따라 정의가 필요합니다. 중요한 점은 모델 성능과 환경 준비를 한 숫자로 묶었는지, 따로 읽었는지를 설명할 수 있어야 한다는 것입니다.

한국어 터미널 과제를 세 층으로 나눈 설명용 예시#

다음은 내부 표본이 아닌 가상 과제 설계입니다. 첫 과제는 한국어로 쓴 요청에 따라 이미 준비된 영문 이름의 파일에서 특정 항목을 찾는 일입니다. 둘째는 한글 경로의 파일을 정확히 골라 내용을 바꾸는 일입니다. 셋째는 한국어 데이터의 의미를 보존하며 결과 파일을 만드는 일입니다. 요청 언어는 모두 한국어여도 각각 요구 이해, 경로 처리와 데이터 해석이라는 다른 조건을 포함합니다. 이를 하나의 언어 능력으로 묶기 전에 어떤 층을 평가했는지 볼 필요가 있습니다.

첫 과제를 읽을 때는 요청의 의미가 파일의 필드와 어떻게 연결되는지 봅니다. 예를 들어 “보관된 항목은 제외하라”라는 조건에서 보관의 뜻이 파일 상태와 일치하는지가 질문입니다. 출력 설명이 한국어인지는 다른 부가 조건입니다. 에이전트가 영어로 짧게 보고해도 결과 항목이 맞을 수 있고, 한국어로 매끄럽게 설명해도 제외 조건을 빠뜨릴 수 있습니다. 결과의 언어와 요청의 이행을 나눠 평가하면 어느 층의 문제가 생겼는지 더 정확히 읽을 수 있습니다.

둘째 과제에서는 같은 화면 모양의 이름과 실제 경로의 관계가 중요할 수 있습니다. 파일 이름, 공백과 확장자를 포함한 대상 선택을 명세하고 수정하지 않을 파일을 함께 둡니다. 경로를 찾는 행동과 내용을 바꾸는 행동을 나누면 대상 선택 오류를 내용 생성 오류와 구분할 수 있습니다. 이 예시에서는 특정 터미널이나 파일 시스템에서 오류가 났다고 주장하지 않습니다. 평가가 어떤 입력을 줬고 무엇을 정답으로 판정하는지에 따라 읽어야 할 자료가 달라진다는 설명입니다.

셋째 과제에서는 숫자와 날짜, 용어가 보존돼야 할 수 있습니다. 파일을 만들었다는 결과와 필드 의미를 맞게 해석한 결과는 다릅니다. 예시로 보관 상태를 삭제 상태와 혼동하면 형식은 올바른 결과라도 의미가 틀릴 수 있습니다. 채점이 파일 존재만 확인하는지, 내용의 조건도 확인하는지에 따라 점수의 뜻이 달라집니다. 언어·파일·의미 중 무엇을 본 평가인지 구분하는 구체적인 질문입니다.

환경 식별자는 무엇을 고정하고 무엇을 남기는가#

실행 이미지의 digest를 고정하면 시작 환경의 어떤 바이트를 사용했는지 식별하는 데 도움이 됩니다. 그러나 같은 이미지를 가리킨다는 사실만으로 모델 응답, 외부 네트워크 상태와 추가 파일까지 같아지는 것은 아닙니다. 환경에 포함한 의존성과 실행 때 내려받는 의존성을 구분하세요. 모델 버전, 에이전트와 도구 권한도 별도의 축입니다. 이 구분을 하면 환경을 고정했다는 문장이 전체 실험을 결정적으로 고정했다는 말로 과장되지 않습니다.

temperature와 seed는 적용 가능한 모델과 실행 경로에서 어떤 생성 조건을 사용했는지 설명하는 항목입니다. 어떤 API에서 그 값을 받는지와 실제로 적용됐는지까지 구분하세요. 적용되지 않는 경로에 관례적인 값을 써 넣으면 정확한 기록이 아닙니다. 또한 생성 조건을 같게 하더라도 도구 결과나 외부 서비스의 상태가 바뀔 수 있습니다. 내부 자료의 빈 설정을 임의로 채우는 대신, 평가를 읽는 관점에서 각 식별자가 제한하는 변동의 종류를 나눌 수 있습니다.

집계 확인과 새 실행은 다른 검증입니다#

원본 결과에서 집계를 다시 계산하는 일은 선택한 분모와 규칙이 표시 점수와 연결되는지 확인하는 작업입니다. 새 환경에서 과제를 다시 실행하는 일은 그 조건에서 결과가 재현되는지 보는 별도 작업입니다. 계산을 맞게 다시 했다고 모델이 같은 결과를 낸다는 뜻은 아니고, 새 실행이 비슷했다고 기존 집계의 오류가 사라지는 것도 아닙니다. 독자가 어떤 검증을 요청하는지에 따라 필요한 자료가 달라집니다.

이 페이지의 내부 92%는 Patty 내부 테스트 결과로만 남습니다. 위의 기호와 가상 과제는 그 수치를 재계산하거나 새로 측정한 것이 아닙니다. 그렇더라도 점수의 정의, 한국어의 범위와 환경의 범위를 분리하면 독자는 자신이 궁금한 질문이 어떤 자료를 필요로 하는지 구체적으로 이해할 수 있습니다.

수정·보완 기록#

92%를 내부 점수로만 유지하고 성공 과제 수나 일반 성능 우위로 해석하지 않도록 보완했습니다. 과제 목록, 실행 이미지와 설정, 원본 로그가 없는 상태에서 재현 절차가 검증됐다고 주장하지 않았습니다.

관련#

• Mirr 1.0 Pro 모델