Argusic 방법론

Argusic이 실제 소프트웨어가 실행되는지 어떻게 테스트하는지, 그리고 AI coding agent를 어떻게 채점하는지 설명합니다. 여기에 있는 모든 규칙은 의도적으로 공개되어 있습니다. 누구나 우리의 작업을 확인할 수 있도록 하는 것이 핵심이기 때문입니다. 이 규칙에 대한 모든 변경은 맨 아래의 변경 기록에 기록되고, 다음 테스트 주기부터 적용되며, 절대 소급 적용되지 않습니다.

1. 요약

• 실제 오픈 소스 프로젝트를 가져와 AI agent가 사람의 도움 없이 설치하고, 실행하고, 디버깅하도록 합니다. 신입 엔지니어가 첫날에 하는 것과 똑같습니다.
• 모든 테스트는 처음부터 끝까지 기록됩니다. 공개된 모든 수치는 해당 log와 터미널 녹화로 연결됩니다.
• 각 프로젝트는 명확한 판정을 받습니다: 실행되는지, mock 서비스와 함께 실행되는지, 아니면 우리가 검증할 수 없었는지입니다.
• agent는 동일한 조건에서 비교됩니다. 각각 세 번 실행하고, 가운데 결과를 채택하며, 크게 일관되지 않은 결과는 표시해 따로 둡니다.
• 우리는 어떤 agent도 판매하지 않으며 결과를 바꾸는 대가로 돈을 받지 않습니다. Argusic은 심판입니다.
• 측정은 자동화되어 있습니다. 글쓰기는 그렇지 않습니다: 이 사이트의 어떤 문장도 모델이 쓰지 않으며, 페이지의 모든 수치는 기록된 실행에서 채운 템플릿이고, 무엇이든 게시되기 전에 사람이 승인합니다. 콘텐츠 작성 방식을 참조하세요.

2. 이 방법론이 답하는 질문

실제 오픈 소스 프로젝트가 주어졌을 때, AI coding agent가 사람의 도움 없이 완전히 혼자서, 첫날의 엔지니어처럼 그것을 설치하고, 실행하고, 오류를 해결하고, 소프트웨어가 실행되는지 검증할 수 있는가?

3. 새로운 프로젝트를 쓰는 이유

정적 benchmark는 정답이 학습 데이터로 유출되면서 가치가 떨어집니다. SWE-rebench(Badertdinov et al., 2025)는 같은 agent를 SWE-bench Verified와, 그 benchmark가 공개된 이후에 수집한 작업에 대해 실행했고, 점수는 크게 달라졌습니다: Table 2에 따르면 DeepSeek-V3-0324는 SWE-bench Verified의 39.7%를 해결했지만 시간으로 필터링한 세트에서는 21.3%를 해결해, 한 모델에서만 18퍼센트포인트의 차이가 났습니다. Argusic은 최근 몇 주 안에 인기를 얻고 있는 프로젝트를 테스트하며, 비공개 풀을 매월 교체하므로 암기할 것이 없습니다.

4. 측정하는 것

우리는 정확히 한 가지를 측정합니다: 실제 소프트웨어를 스스로 실행되게 만드는 능력입니다. 테스트 대상인 각 agent는 고정된 버전의 모델, 고정된 버전의 harness, Argusic이 공개한 표준 지침, 그리고 동일한 시간과 리소스 제한의 고정된 조합입니다. 모든 agent는 정확히 같은 조건을 받습니다.

5. 테스트 대상 agent

첫 번째 주기가 진행 중입니다. agent 목록은 첫 리더보드와 함께 공개됩니다. 각 agent는 중립적인 Argusic 정체성으로 제시되는 고정된 구성입니다. 정확한 버전이 기록되고 보관되므로 보드의 모든 수치는 그것을 만들어 낸 정확한 구성까지 추적할 수 있으며, 요청이 있으면 Argusic을 통해 결과를 재현할 수 있습니다("결과를 재현하는 방법" 참조).

6. 프로젝트 풀

• 80% 공개 풀: 목록과 정확한 버전(commit 해시)은 각 주기 전에 공개됩니다.
• 20% 비공개 풀: 최근 30일 동안 인기를 얻은 프로젝트에서 선정하며, 주기가 끝난 뒤에만 공개하고, 매월 교체합니다. 이것이 agent가 테스트에 맞춰 조정되는 것을 막습니다.
• 선정 기준: 허용적인 라이선스, README, 다양한 언어와 난이도, 그리고 유료 계정 없이 기본 수준으로 실행할 수 있을 것.

6a. 테스트 대상이 될 수 있는 것

테스트 대상은 agent에게 설정하고 실행하도록 요청할 수 있는 것입니다. Argusic은 현재 한 종류를 테스트하며, 결과를 얻는 방식은 전혀 바꾸지 않고 다른 종류를 추가할 수 있도록 만들어져 있습니다: 채점 기준표, 증거 규칙, 판정 용어는 모든 출처에서 동일하므로 한 출처의 수치는 다른 출처의 수치와 같은 의미를 가집니다.

출처	여기서 "실행됨"의 의미	상태
오픈 소스 리포지토리	고정된 commit을 clone하고, 설치하고, 실행한 뒤, 프로젝트 자체 README가 설명하는 작업을 수행하는지 검증합니다	사용 중. 프로젝트 3,669개 테스트됨
Hugging Face 모델	고정된 revision의 모델을 다운로드하고 GPU 워커에서 model card가 문서화한 그대로 추론을 실행합니다. 테스터가 다시 작성하지 않고도 문서화된 코드 조각이 깨끗한 머신에서 출력을 생성하면 실행되는 것으로 봅니다	사용 중. 프로젝트 1개 테스트됨
Hugging Face Space	Space 자체 정의로 빌드하고 실행한 뒤, 인터페이스에 접속해 Space가 내세우는 상호 작용을 완료합니다	선언됨, 시작 전
게시된 패키지(npm, PyPI)	고정된 버전을 빈 프로젝트에 설치하고 패키지 자체 README의 빠른 시작을 실행합니다	선언됨, 시작 전
제작사 도구	제작사가 직접 게시한 빌드를 제작사 자체 지침만 따라 설치하고 실행합니다	선언됨, 시작 전
사전 빌드된 클라우드 템플릿	템플릿을 자체 목록 페이지가 문서화한 대로 배포하고, 테스터가 미리 패치하지 않아도 시작되어 내세우는 기능을 제공하는지 확인합니다	선언됨, 시작 전
컨테이너 이미지	고정된 digest의 이미지를 pull하고 이미지 자체 설명에 나온 명령을 실행한 뒤, 그 설명이 주장하는 대로 동작하는지 확인합니다	선언됨, 시작 전
MCP server	문서대로 server를 설치하고 시작한 뒤, client를 연결해 server가 내세우는 tool을 나열하고 응답하는지 확인합니다	선언됨, 시작 전

위의 상태 열은 손으로 작성하지 않습니다. 이 페이지가 제공될 때마다 데이터베이스에서 읽어 옵니다: 해당 종류의 공개된 테스트 대상에 기록된 실행이 생기면 그 출처는 사용 중으로 표시되고, 개수가 표시됩니다. 이는 이 사이트의 다른 모든 수치가 따르는 것과 같은 규칙이며, 새로운 출처가 첫 결과를 낼 때 누군가 이 페이지를 업데이트하는 것을 기억할 필요가 없다는 뜻입니다.

Hugging Face 테스트 대상이 리포지토리와 다른 점은 두 가지이며, 둘 다 적당히 넘어가지 않고 실행과 함께 기록됩니다. GPU 워커가 필요하므로 시도당 비용이 더 높고 예산은 별도로 결정됩니다. 그리고 model card는 애플리케이션이 아니라 코드 조각을 문서화하는 경우가 많으므로, 검증되는 동작은 "제품이 작동한다"가 아니라 "문서화된 코드 조각이 출력을 생성했다"입니다: 실행 페이지는 어느 쪽인지 바로 그 표현으로 밝히며, 점수는 같은 방식으로 얻습니다.

표에 "곧 제공"이 아니라 "시작 전"이라고 쓴 것은 의도적입니다. 어떤 출처는 해당 종류의 실제 실행이 증거와 함께 기록된 날에 사용 중으로 간주되며, 그보다 하루도 빠르지 않습니다. 그때까지 그 행은 범위에 대한 진술일 뿐 결과에 대한 진술이 아닙니다: 실행되지 않은 출처에 대해서는 어떤 페이지도 판정, 개수, 순위, 공유 카드를 표시하지 않으며, 계획된 출처의 이름이 나오는 곳은 이 표뿐입니다.

7. 한 번의 측정

1. 깨끗한 일회용 머신(정확한 환경이 공개됩니다). 인바운드 연결을 받지 않으며 실행이 끝나면 폐기됩니다. 이번 판에서는 아웃바운드 네트워크 접근을 필터링하지 않습니다. 실행을 제한하는 것은 일회용 머신과 목록 아래의 모델 키 규칙입니다. 머신은 고정된 commit만 가져오며, 테스트의 일부가 아닌 프로젝트 이력은 가져오지 않습니다.
2. agent는 하나의 임무를 받습니다: 공개된 표준 지침에 따라 이 프로젝트가 작동하게 만드는 것입니다.
3. 시간 제한. 모든 실행은 정확히 세 가지 예산 중 하나를 받으며(목록 아래 표), 실행에 주어진 예산은 해당 실행 페이지에 표시됩니다.
4. 독립적인 세 번의 실행. 가운데 결과를 채택합니다. 세 결과의 차이가 30%를 넘으면 그 세트는 불안정으로 표시되고 해당 주기의 보드에서 제외됩니다.
5. 모든 실행은 전체 log와 완전한 터미널 녹화를 저장하며, 결과와 함께 공개됩니다.
6. 데스크톱 애플리케이션은 머신 안의 가상 디스플레이에서 실행됩니다(v1.1부터). "실행됨"은 애플리케이션의 메인 프로세스가 그 디스플레이에서 시작되어 계속 유지되었거나, 버전 또는 도움말 명령에 응답했다는 뜻입니다. 아무것도 클릭하지 않습니다. 측정하는 것은 소프트웨어가 새 머신에서 올라오는지이며, 다른 모든 프로젝트에 묻는 것과 같은 질문입니다. agent는 모델에 이미지를 보내지 말라는 지시를 받습니다(v1.3부터): 표준 모델은 텍스트만 받으며, 메시지에 첨부된 스크린샷 때문에 보고서가 나오기 전에 세션이 끝난 적이 있습니다.

3번 항목의 시간 예산:

등급	예산
standard	90분
heavy	120분
gpu	120분

표준 예산은 v1.3 이전에는 45분이었습니다: 첫 주의 어느 하루에 시간 초과 38건 중 36건이 예산을 모두 쓴 채 아직 빌드 중이었기 때문에 두 배로 늘렸습니다. heavy 등급은 v1.2부터 있으며, Owner가 heavy로 표시한 프로젝트나 GitHub이 보고하는 리포지토리 크기가 500 MB보다 큰 프로젝트에 적용됩니다. 큰 게임이나 데스크톱 애플리케이션은 빌드에 그만큼의 시간이 필요하기 때문입니다. GPU가 필요한 프로젝트도 같은 120분을 받습니다.

위의 세 수치는 장식이 아닙니다. scripts/check-ttl-methodology.sh가 이 표를 읽어 orchestrator에 실제로 구성된 예산과 비교하며, 둘이 다르면 make test가 실패합니다. 이 검사가 있는 이유는 2026-09-06부터 2026-09-11까지 실행 중인 시스템의 GPU 예산이 240분이었는데 이 페이지에는 120분이라고 적혀 있었고, 아무것도 그 둘을 비교하지 않았기 때문입니다(ISSUE-072).

모델 키. agent는 모델을 호출하려면 키가 필요하고, 실행은 신뢰할 수 없는 프로젝트의 코드를 실행하므로, 그 키는 가장 제한할 가치가 있는 자격 증명입니다. Argusic의 라우팅 계층을 통해 모델에 접근하는 agent의 경우, 모든 실행은 그 실행만을 위해 생성된 자체 키를 받습니다. 각 실행의 모델 키 지출 한도: 3 USD. 키는 실행이 끝나거나, 취소되거나, 시간 초과되면 삭제되며, 예약된 정리 작업이 더 이상 실행 중인 작업에 속하지 않는 키를 모두 삭제합니다. 실행의 키를 만들 수 없으면 실행은 시작되지 않고 다시 시도됩니다. 공유 키로 대체하는 일은 절대 없습니다. 모델 제작사 자체 서비스를 사용하는 agent는 실행별 키가 아니라 Argusic이 보유한 공유 키로 호출합니다. 이들을 실행별 키로 옮기는 작업은 backlog에 있습니다. 위의 한도 줄은 scripts/check-cost-methodology.sh가 읽으며, 구성된 값과 다르면 시간 예산과 같은 이유로 make test를 실패시킵니다.

8. 채점, 100점 만점

• 설치 성공: 30
• 실행 또는 테스트 성공: 30
• 오류 복구: 20, 발생한 오류 중 올바르게 수정한 비율에 비례
• 검증 깊이: 20(실제로 실행됨을 검증: 20, mock 서비스로 검증: 12, 검증 안 됨: 0)

실행의 결과는 다음 중 하나입니다:

결과	의미
pass_full	실행되었고 실제로 검증됨
pass_mock	실행되었고 mock 서비스로 검증됨
fail	설치되지 않았거나 실행되지 않음
timeout	시간 초과

네 개의 채점 항목은 일부 경우를 명시하지 않습니다. 그 경우는 코드에서만이 아니라 여기에서 정합니다. 아무도 읽을 수 없는 규칙은 아무도 확인할 수 없는 규칙이기 때문입니다. 채점은 아래의 모든 규칙을 다루는 테스트를 갖춘 결정론적 프로그램이며, 어느 단계에서도 AI 모델이 채점에 관여하지 않습니다.

• 아무 문제도 없었다면 오류 복구는 만점인 20점입니다. 점수를 전혀 주지 않으면 프로젝트가 마침 깔끔하게 설치되었다는 이유로 agent에게 불이익을 주게 되며, 이는 agent가 아니라 프로젝트를 측정하는 것입니다.
• 그렇지 않으면 오류 복구는 발생한 오류 중 수정된 비율을 20점 만점으로 환산한 것입니다. 실행은 발생한 오류보다 많은 오류를 수정했다고 주장할 수 없으며, 그런 실행은 거부됩니다.
• 실행에는 설치가 필요합니다: 소프트웨어를 설치하지 않은 agent는 그것을 실행할 수 없었을 것입니다.
• 검증 깊이에는 실행이 필요합니다: 실행에 성공하지 못하면 검증할 것이 없으므로 깊이는 0점입니다.
• 설치하고 실행했지만 검증하지 않은 경우는 통과가 아닙니다. 100점 중 80점을 받지만 여전히 실패로 계산됩니다. 질문은 agent가 소프트웨어가 실행됨을 검증했는지이며, 검증되지 않은 실행은 그 질문에 답하지 못하기 때문입니다.
• 시간 초과는 모든 항목에서 0점입니다. 부분 점수가 아닙니다: agent는 다른 모든 agent에게 주어진 것과 같은 제한 안에 끝내지 못했습니다.
• 완전한 log와 녹화가 없는 실행은 무효이며 다시 실행합니다. 절대 채점되지 않으며 보드에 오르지 않습니다.

9. 여러 실행에서 하나의 보드 점수로

채점은 프로젝트와 agent 한 쌍을 평가합니다. 리더보드에는 agent마다 하나의 수치가 필요하며, 이를 어떻게 결합하는지는 방법론상의 선택이므로 여기에 명시합니다.

agent의 보드 점수는 프로젝트별 중간 점수들의 중간값입니다. 평균이 아니라 다시 중간값을 쓰는 이유는 같습니다: 처참한 프로젝트 하나가 유능한 agent를 끌어내려서는 안 되고, 운 좋은 프로젝트 하나가 약한 agent를 끌어올려서도 안 됩니다.

두 종류의 결과는 그 수치에서 제외되며, 제외가 조용히 일어나지 않고 보이도록 둘 다 보드에는 계속 표시됩니다: 불안정으로 표시된 결과(다음 섹션 참조)와, 검토 중으로 표시된 프로젝트의 모든 결과(환경 품질 관리 참조)입니다.

결과가 모두 제외된 agent는 보드 점수가 없습니다. 삭제하지 않고 점수 없이 맨 아래에 표시합니다. 테스트를 받았지만 쓸 만한 것을 내지 못한 agent는 그 자체로 하나의 결과이며, 이를 숨기면 전체 참가자를 은근히 실제보다 좋아 보이게 만들기 때문입니다.

통과율은 agent가 해당 주기에 시도한 모든 시도를 실패와 시간 초과까지 포함해 계산합니다. 아래의 독립성과 결과 선별 금지를 참조하세요.

10. 편차와 불안정성

편차는 세 번의 실행 범위를 그 중간값에 대한 백분율로 나타낸 것입니다:

spread = (highest - lowest) / middle * 100

편차가 30%보다 엄격하게 클 때 세트는 불안정으로 표시됩니다. 정확히 30%는 30%를 넘지 않으므로 보드에 남습니다. 공식에서 두 가지 경계 사례가 나옵니다:

• 중간값이 0인데 어느 한 실행이라도 0보다 높은 점수를 받았다면 편차는 무한대이며 세트는 불안정입니다: 한 번은 나타나고 나머지 두 번은 나타나지 않은 결과는 가장 재현성이 낮은 결과입니다.
• 세 실행이 모두 0점이면 공식은 영으로 나누게 되어 값이 없으므로, 이 규칙에 따라 편차를 0으로 정의하며 세트는 안정입니다. 일관된 실패는 재현 가능한 측정이며 그렇게 보드에 오를 자격이 있습니다.

11. 프로젝트 판정

보드는 agent의 순위를 매깁니다. 판정은 프로젝트 자체에 관한 다른 질문에 답합니다: AI agent라는 형태의 신규 사용자가 오늘 이 소프트웨어를 실행되게 만들 수 있는가?

증거가 한쪽으로만 작용하기 때문에 테스트는 적응형입니다. 한 번의 통과는 프로젝트가 실행된다는 것을 증명하지만, 한 번의 실패는 그 자체로는 아무것도 증명하지 않습니다. 실패의 원인이 프로젝트가 아니라 agent에 있을 수 있기 때문입니다.

1. 먼저 표준 agent가 한 번 실행합니다. 어떤 통과든 그것으로 끝납니다: 완전한 통과는 "실행됨", mock 서비스로 검증한 통과는 "mock으로 실행됨"이 됩니다. 이미 실행된다는 것이 확인된 것을 계속 테스트할 이유가 없습니다.
2. 실패했다면 같은 agent로 한 번 재시도하여 일회성 우연을 배제합니다.
3. 그래도 실패했다면 판정은 "검증할 수 없음"이며, 절대 "고장"이 아닙니다: Argusic은 agent가 할 수 있었던 것을 보고하고, 정확히 그것을 명시합니다(v1.3부터: 표준 agent의 완전한 시도 두 번으로 판정이 확정됩니다). 요청이 있으면 더 강력한 agent를 실행할 수 있습니다. 그 경우 그 agent가 통과하면 프로젝트는 "실행됨"이 되고(기록에 어느 agent가 검증했는지 표시됩니다), 실패하면 역시 "검증할 수 없음"으로 확정됩니다.

완전한 시도란 녹화에서 agent가 스스로 끝날 때까지 또는 시간 제한까지 작업한 것이 보이는 시도입니다. Argusic 자체 도구가 중간에 끊은 시도(agent의 보고서를 읽지 못한 harness, 프로젝트와 무관한 측정 도구 오류)는 그 이유를 실행에 저장한 채 무효로 표시되며, 증거와 함께 계속 공개되고, 계산에 포함되지 않습니다.

판정은 어느 시도든 도달한 가장 좋은 결과입니다:

• 실행됨(runs): 어떤 시도가 실행되었고 실제로 검증되었습니다.
• mock으로 실행됨(runs with mocks): 가장 좋은 시도가 실행되었고 mock 서비스로 검증되었습니다. 보통 프로젝트에 실제 서드파티 자격 증명이 필요하기 때문입니다.
• 검증할 수 없음(could not verify): 완전한 시도 두 번 이후에도(또는 더 강력한 agent를 실행한 경우 그 이후에도) 통과가 없습니다. 페이지에 그렇게 밝히고, 각 시도가 어디서 멈췄는지 보여 주는 log로 연결합니다.
• 아직 검증되지 않음(not yet verified): 테스트가 끝나지 않았습니다.

판정과 관계없이 모든 시도는 전체 증거와 함께 공개되며, 한 가지 예외가 있습니다: 활성 자격 증명이 없다는 것을 증명할 수 없는 녹화는 공개를 보류하고 해당 실행을 다시 실행합니다(17번 섹션, "보안 마스킹").

12. Argusic이 측정하지 않는 것

오해를 막기 위해 분명히 밝힙니다. Argusic은 agent가 작성한 코드의 장기적인 품질, 수정 사항의 보안성, 기능 수준의 깊은 제품 경험을 측정하지 않습니다. 측정하는 것은 한 가지입니다: 실제 소프트웨어를 스스로 실행되게 만드는 능력입니다.

13. 독립성과 결과 선별 금지

• Argusic은 방법론, 채점, 순위를 바꾸는 대가로 어떤 돈도 받지 않습니다.
• 컴퓨팅 후원이 있다면 그것으로 얻는 것은 정확히 한 가지입니다: 후원사의 모델이 다른 모든 agent와 동일한 조건으로 테스트 목록에 추가되며, 후원 사실은 결과 옆에 공개됩니다.
• 모든 agent의 모든 실행이 계산되고 공개됩니다. 비공개로 테스트한 뒤 가장 좋은 결과만 공개하는 일은 없습니다. agent가 보드에 있다면, 그 주기의 모든 시도가 기록에 남아 있습니다.

14. Harness 공개

harness(모델을 둘러싼 스캐폴딩, 도구, 지침, 제한)는 공개되어 있으며 한 주기 안에서 모든 agent에게 동일합니다. 점수의 차이는 배관이 아니라 agent에서 비롯된 것이어야 합니다. harness 변경은 주기 사이에만 배포되며 변경 기록에 기록됩니다.

15. 환경 품질 관리

어떤 프로젝트가 모든 agent에서 실패하면, 자동으로 검토 중으로 표시되고 사람이 확인할 때까지 채점에서 제외됩니다: 실패의 원인이 agent가 아니라 환경이나 프로젝트에 있을 수 있기 때문입니다. 공통된 설정 문제가 agent의 실패로 채점되어서는 절대 안 됩니다.

16. 검증은 탐색이 아니라 디코딩입니다

파일이 존재하는 것은 결과가 아니며, 헤더를 읽는 것은 검사가 아닙니다. ffprobe -show_streams, file, 바이트 수는 모두 컨테이너를 보고할 뿐 아무것도 디코딩하지 않습니다: 모든 프레임이 초록색인 동영상도 정상 동영상과 똑같이 세 가지를 모두 통과합니다. v1.4부터 시행 중인 규칙은 agent가 예상한 것이 아니라 디코딩한 것을 보고한다는 것입니다.

• 만든 것을 디코딩하세요. 동영상과 오디오는 ffmpeg -v error -i FILE -f null -, 이미지는 실제 디코더, 텍스트는 출력해 봅니다. 명령과 그 명령이 반환한 내용을 보고합니다.
• 관찰하지 않은 것은 절대 진술하지 마세요. 모델에 준 prompt는 무엇이 나왔는지에 대한 증거가 아닙니다. README가 약속하는 내용은 여기에서 그 일이 일어났다는 증거가 아닙니다. "81개 프레임이 오류 없이 디코딩됨"은 발견 사항입니다. "고양이 두 마리가 나오는 동영상"은 그렇지 않습니다.
• 최고 검증 깊이를 얻는 것은 디코딩입니다. test_depth는 실행이 어디까지 갔는지 기록하는 필드입니다(8번 섹션: tier1_real은 "실제로 실행됨을 검증"으로 20점, tier2_mock은 "mock 서비스로 검증"으로 12점, tier3_none은 "검증 안 됨"으로 0점). tier1_real에는 출력을 설명하는 능력이 아니라 성공적인 디코딩이 필요합니다.
• verified_how가 증명을 담습니다. agent가 자신의 출력을 검증하기 위해 실행한 정확한 명령과 그 명령이 반환한 내용을 담는 보고서 필드입니다. "not verified"도 받아들여지는 유용한 답입니다.
• final_state는 무슨 일이 있었는지에 대한 agent 자신의 마무리 문장이며, 실행 페이지와 테스트 대상 페이지에 그대로 공개되므로, 그 안의 모든 사실은 agent가 자신의 명령으로 관찰한 것이어야 합니다.

17. 증거 무결성

두 개의 계층이 있으며, 절대 혼동하지 않습니다.

증거 계층은 원본 그대로이며 영구적입니다: 모든 실행은 실제 세션의 전체 터미널 녹화를 만들고, 그래픽 앱의 경우 원본 세션 동영상도 만들며, 완전한 log도 함께 남깁니다. 각 파일은 도착 시 지문(fingerprint)을 남기고 영구히 저장됩니다. 누구나 편집되지 않은 전체 세션을 다시 재생할 수 있습니다.

표현 계층은 파생물입니다: 모든 소셜 동영상이나 이미지는 증거를 렌더링한 것입니다. 허용되는 편집은 빨리 감기, 길이를 맞추기 위한 자르기, 기록된 오류와 수정 타임라인에서 가져온 자막, 그리고 내레이션입니다. 금지되는 편집은 사건 순서 바꾸기, 서로 다른 세션 이어 붙이기, 실패 숨기기, agent가 한 일의 본질을 바꾸는 것입니다. 공개된 모든 동영상은 해당 증거로 다시 연결됩니다.

녹화를 제공하기 전에 세 가지 파생 변환이 적용되며, 그 어느 것도 agent 작업의 본질을 바꾸지 않습니다:

• 보안 마스킹. 활성 자격 증명 값이 제거됩니다. 신뢰할 수 없는 리포지토리가 agent를 꼬드겨 환경 변수를 출력하게 하는 것을 막을 방법은 없으며, 환경 변수에는 agent에게 필요한 키 하나가 들어 있으므로, 비밀 값처럼 보이는 모든 값은 녹화를 저장하거나 제공하기 전에 지워집니다. 자격 증명이 없다는 것을 증명할 수 없는 녹화는 공개를 보류하고, 해당 실행을 다시 실행합니다.
• 생성된 키 자료. 어떤 프로젝트는 키를 생성하는 것이 기능이며(비밀번호 관리자, PKI 도구), agent가 이를 실행해 결과를 출력할 수 있습니다. 이는 Argusic 자격 증명이 아니라 실제 테스트 출력이므로 실행을 보류하지 않습니다: 제공되는 녹화와 log 사본에서는 그러한 개인 키의 본문이 가려지고, 원본 파일은 자체 지문이 실행에 기록된 채 보관되며, 실행 페이지에 마스킹이 적용되었다고 명시합니다. 가려졌음을 증명할 수 없는 본문은 여전히 실행을 보류시킵니다(v1.2부터, Owner 결정 2026-09-05).
• 중립적인 agent 브랜딩. 녹화는 Argusic Agent의 목소리로 제시됩니다: 기반 도구 자체의 시작 배너(제작사, 공급자, 모델 이름이 나옴)는 서식이 적용된 보기가 원시 머신 출력을 대신하는 것과 같은 방식으로 숨겨집니다. 이는 agent가 실행한 명령이나 수행한 변경을 절대 편집하지 않으며, 그것들은 전부 표시됩니다. 또한 파일 경로, 패키지 이름, 리포지토리 자체 코드에 자연스럽게 나오는 제작사 이름은 실제 작업의 일부이므로 검열하지 않습니다.

인용된 텍스트에는 표시 변환 하나가 적용됩니다(Owner 결정 2026-09-04): 페이지가 agent 자신의 최종 상태 문장("테스트에서 발견한 내용")이나 리포지토리의 GitHub 설명을 표시할 때, 작성자가 입력한 대시는 사이트의 구두점 규칙을 따르도록 쉼표나 마침표로 표시됩니다. 저장된 보고서, 리포지토리 기록, log, 녹화, 녹화에서 렌더링한 이미지는 그대로 유지되며, 단어와 그 순서는 절대 바뀌지 않습니다.

상시 규칙: 모든 수치는 log로 추적되고, 모든 프레임은 실제 세션의 녹화로 추적됩니다.

18. 결과를 재현하는 방법

모든 결과의 프로젝트 측면은 완전히 공개되어 있습니다: 테스트한 정확한 commit, 공개된 환경, 표준 지침, 그리고 완전한 log와 녹화입니다. 각 실행 페이지에 이 모든 것이 담겨 있습니다. agent는 중립적인 정체성을 가진 고정된 Argusic 구성입니다. Argusic은 정확한 버전을 보관하고 있으며 결과를 재현하기 위해 다시 실행할 수 있습니다. 공개 프로젝트 목록과 비공개 풀 공개 내용은 첫 리더보드와 함께 공개됩니다.

19. 결과에 대한 이의 제기

메인테이너나 연구소가 결과가 잘못되었다고 생각하면 이의를 제기할 수 있습니다. 실행 링크와 함께 [email protected]으로 연락해 주세요. 우리는 전체 log와 녹화를 주장과 대조해 검토하고 답변합니다. 결과가 우리 측의 환경이나 설정 문제의 영향을 받았다면, 다시 실행하고 메모와 함께 기록을 정정합니다. 증거가 원래 결과를 뒷받침한다면, 녹화가 무엇을 보여 주는지 설명합니다. 원래 증거는 절대 편집되거나 삭제되지 않습니다.

20. 변경 기록

각 판에는 두 개의 날짜가 나오며, 서로 다른 질문에 답합니다. 작성일은 규칙이 이 문서에 기록된 날입니다. 시행일은 그 규칙에 따라 첫 실행이 실제로 측정된 날로, 이 파일이 아니라 실행 기록에서 읽어 옵니다. 보통은 일치합니다. 일치하지 않는 경우 실행 기록이 우선하며 여기에 표시합니다. 이 페이지보다 먼저 머신에 적용된 판이야말로 변경 기록이 공개하기 위해 존재하는 것이기 때문입니다. 어떤 판도 소급 적용되지 않습니다: 실행은 실행된 날 시행 중이던 규칙을 유지합니다.

v0.2부터 v1.0까지의 판은 모두 2026-08-31에 첫 공개판을 만든 commit에서 기록되었습니다. 아래의 날짜는 첫 측정 이전에 규칙 자체가 결정된 날입니다.

• v0.2(2026-08-29): 채점 기준표가 명시하지 않았던 경우(오류가 하나도 없을 때의 오류 복구, 설치와 실행의 의존 관계, 시간 초과, 무효 실행)와 두 가지 경계 사례를 포함한 정확한 편차 공식을 명시했습니다. 첫 측정 전에 작성되었으므로 소급 적용된 것은 없습니다.
• v0.3(2026-08-30): 프로젝트별 결과가 하나의 보드 수치로 결합되는 방식(프로젝트별 중간값들의 중간값), 어떤 결과가 제외되는지, 그리고 채점할 수 있는 것이 없는 agent는 삭제하지 않고 점수 없이 표시한다는 것을 명시했습니다.
• v0.4(2026-08-30): 프로젝트 판정을 추가했습니다(적응형 테스트: 표준 agent, 한 번의 재시도, 그다음 더 강력한 agent, 첫 통과에서 중단). 보드 채점은 변경되지 않았습니다.
• v1.0(시행일 2026-08-31, 작성일 2026-08-31): 첫 공개판. v0.4에서 바뀐 규칙은 없습니다. 이 판은 문서 순서를 재구성하고, 용어를 쉬운 말로 정의하며, 재현과 이의 제기 섹션을 추가합니다.
• v1.1(시행일 2026-09-04, 작성일 2026-09-04): 데스크톱 애플리케이션을 테스트 머신 안의 가상 디스플레이에서 실행하여(7번 섹션, 6번 항목) 그래픽 인터페이스가 있는 프로젝트를 측정할 수 있게 했습니다. 머신 이미지에는 일반적인 데스크톱 런타임과 네이티브 빌드 도구도 추가되었습니다. 이미지 다이제스트가 모든 실행에 기록되므로 이전과 이후의 결과를 구분할 수 있습니다. 채점은 변경되지 않았습니다.
• v1.2(시행일 2026-09-04, 작성일 2026-09-05): heavy 등급(7번 섹션, 3번 항목): 큰 프로젝트는 같은 머신 등급에서 120분을 받으며, Owner의 표시나 500 MB 리포지토리 크기로 결정하고, 예산은 실행 페이지에 표시됩니다. 머신은 고정된 commit만 가져옵니다. 17번 섹션에 생성된 키 자료 변환이 추가되었습니다. 채점은 변경되지 않았습니다. 이 판은 처음에 2026-09-05부터 유효하다고 여기에 기록되었지만, 실행 기록에 따르면 세 개의 heavy 프로젝트(cataclysm-dda, veloren, supertux)가 이미 2026-09-04에 120분 예산으로 측정되었으므로, 위에 표시된 것은 더 이른 날짜입니다.
• v1.3(시행일 2026-09-05, 작성일 2026-09-05): 판정은 표준 agent의 완전한 시도 두 번 이후에 확정됩니다(11번 섹션). 더 강력한 agent는 더 이상 표준 절차의 일부가 아닙니다. Argusic 자체 도구가 중간에 끊은 시도는 무효이며 계산되지 않습니다(2026-08-30부터 2026-09-05까지 그러한 실행 92건이 각 실행에 이유와 함께 그렇게 표시되었습니다). 표준 시간 제한 90분(7번 섹션, 3번 항목). 모델에 이미지 전송 금지(6번 항목). 채점은 변경되지 않았습니다.
• v1.4(시행일 2026-09-07, 작성일 2026-09-07): 검증은 탐색이 아니라 디코딩입니다(16번 섹션). agent는 자신이 만든 것을 디코딩하고 사용한 명령을 보고해야 하며, 관찰하지 않은 것은 절대 진술할 수 없고, 디코딩에 성공한 경우에만 tier1_real을 얻습니다. 새 보고서 필드 verified_how가 그 명령과 결과를 담으며, "not verified"도 받아들여지는 답입니다. verified_how를 담은 첫 실행은 2026-09-07에 기록되었습니다. 채점은 변경되지 않았습니다. 이 판은 우리가 아니라 독자에게서 나왔습니다. 공개된 릴을 본 누군가가 MP4 형식은 유효하지만 프레임이 손상된 실패를 본 적이 있는지 물었고, 세션 cast를 보니 agent는 바로 그런 실패를 잡아낼 수 없는 헤더 검사만 실행했었습니다. agent가 보고한 문장의 절반은 검증 가능했고(코덱, 해상도, 프레임 수, 재생 시간, 모두 헤더에서 읽음) 절반은 그렇지 않았습니다: 동영상이 보여 주는 내용에 대한 설명은 model card의 prompt를 관찰인 것처럼 다시 쓴 것이었습니다. 그 문장은 릴, 캡션, 테스트 대상 페이지에 그대로 공개되었습니다(ISSUE-056).
• v1.5(시행일 2026-10-08, 작성일 2026-10-08): 7번 섹션의 테스트 머신 네트워크와 모델 키에 대한 설명을 실제로 구축된 시스템과 일치하도록 바로잡고, 시간 예산 표를 목록 뒤로 옮겨 그 섹션의 목록 번호를 고쳤습니다(그래서 v1.1과 v1.3의 "7번 섹션, 6번 항목"이 다시 6번 항목이 됩니다). 이 판 이전에 7번 섹션은 머신에 "제한된 네트워크"가 있다고 했지만, 머신의 아웃바운드 트래픽은 필터링되지 않았으며, 이 판은 그렇게 밝힙니다. 또한 실행별 모델 키, 그 3 USD 지출 한도와 삭제를 명시하며, 취소된 실행과 비상 정지에서도 이제 키가 삭제된다는 것(2026-10-08 이전에는 삭제되지 않았습니다), 그리고 모델 제작사 자체 서비스를 사용하는 agent는 공유 키를 쓴다는 것을 명시합니다. 이는 설명의 정정이며, 채점이나 측정 규칙의 변경이 아닙니다: 이전 실행의 레이블을 바꾸지 않으며, 다른 규칙으로 측정된 것은 없고, 이 판은 소급 적용되지 않습니다. 채점은 변경되지 않았습니다.

부록: 하드웨어 추정치, 어떤 모델이 들어가고 얼마나 빠른가

아래 추정치는 Argusic이 소개하는 프로그래밍, AI, 데이터 과학용 노트북과 데스크톱 옆에 표시됩니다.

이 부록은 위의 benchmark 규칙에 속하지 않으며 어떤 판도 바꾸지 않습니다: Argusic이 판매 목록에 올린 노트북과 데스크톱 옆에 표시하는 추정치를 설명합니다. 이 추정치는 제조사가 공개한 수치에 대한 산술 계산이며, 절대 측정값이 아닙니다. 여기의 수치는 하나의 공유 파일(lib/hardware-estimates.ts)이 계산하며, 그 파일과 테스트가 같은 commit에서 함께 바뀌지 않는 한 어떤 수치도 바뀔 수 없습니다.

Argusic의 하드웨어 목록은 각 노트북과 데스크톱에 대해 담을 수 있는 가장 큰 모델 크기와 텍스트를 생성할 수 있는 속도의 상한을 보여 줍니다. 둘 다 추정치입니다: 아래 공식으로 제조사가 공개한 사양에서 계산한 값입니다. Argusic은 이 머신들에서 모델을 실행하지 않았습니다. Argusic이 실제로 머신을 측정하면 그 수치에는 측정값 레이블이 붙고, 실행 log로 연결되며, 추정치와 절대 섞이지 않습니다.

추정치는 모든 입력값을 알고 있을 때만 표시됩니다. 메모리 크기, 메모리 종류, 칩의 대역폭 중 하나라도 없으면 페이지는 추측하지 않고 "알 수 없음"이라고 표시합니다.

입력값과 출처

• 모델 메모리: 모델이 올라갈 수 있는 메모리입니다. 외장 GPU가 있는 머신에서는 GPU의 VRAM입니다. Apple silicon, AMD Ryzen AI Max, NVIDIA GB10에서는 CPU와 GPU가 공유하는 통합 메모리입니다. 제품 목록에서 읽어 옵니다.
• 메모리 대역폭: 칩 또는 GPU 제조사(Apple, NVIDIA, AMD) 자체의 사양 페이지나 데이터시트에서 읽어 오며, 칩마다 참조 행 하나와 출처 페이지 링크가 있습니다. 제조사가 대역폭을 공개하지 않은 칩은 페이지에 대역폭이 없습니다. Argusic은 버스 폭과 메모리 속도로 대역폭을 계산하지 않으며, 서드파티 데이터베이스에서 복사하지도 않습니다.
• 모델 크기: 매개변수 수이며, 필터의 다섯 가지 크기 등급으로 나뉩니다: 7-8B, 14B, 27-32B, 70B, 120B 이상. 각 등급은 가장 큰 크기(8B, 14B, 32B, 70B, 120B)로 확인하므로, 들어간다고 하면 등급 전체에 해당합니다.

메모리: 어떤 모델 크기가 들어가는가

모델에는 세 가지를 위한 공간이 필요합니다.

1. 가중치. Argusic은 가중치당 4.8944비트인 llama.cpp의 Q4_K_M 양자화를 가정합니다(llama.cpp quantize README):

가중치 바이트 = 매개변수 x 4.8944 / 8. 예시(측정이 아니라 계산): 70B 모델에는 42.8 GB의 가중치가 필요합니다.

2. 컨텍스트(KV 캐시). NVIDIA의 공식에 따릅니다(Mastering LLM Techniques: Inference Optimization, NVIDIA Technical Blog, 2023-11-17):

token당 KV 캐시 바이트 = 2 x 레이어 수 x (헤드 수 x 헤드 차원) x 값당 바이트. 최신 모델은 여러 어텐션 헤드가 key/value 헤드를 공유하므로(grouped-query attention), 여기서 "헤드 수"는 모델이 실제로 캐시하는 key/value 헤드의 수입니다. Argusic은 16비트 정밀도(2바이트, llama.cpp의 기본 캐시 유형)로 8,192 token의 컨텍스트를 허용하며, 등급마다 공개된 dense 모델 하나의 공개 구성을 사용합니다: Qwen3-8B, Qwen3-14B, Qwen3-32B, Qwen2.5-72B-Instruct, Mistral-Large-Instruct-2411.

3. 런타임 오버헤드. Argusic은 추론 런타임 자체의 버퍼에 1 GB를 허용합니다.

8,192 token 컨텍스트와 1 GB 오버헤드는 Argusic이 정한 허용치이며, 측정이 아니라 정책상의 선택입니다. 컨텍스트가 길어지면 더 많은 메모리가 필요합니다. 여기서 들어가는 모델도 훨씬 긴 대화에서는 들어가지 않을 수 있습니다.

머신 메모리 중 얼마나 계산하는가. 외장 GPU의 VRAM은 전부 계산합니다. 통합 메모리나 시스템 메모리는 75%만 계산하고 25%는 운영 체제와 다른 프로그램을 위해 남겨 둡니다. 이는 AMD가 자사 통합 메모리 칩에 대해 밝힌 내용과 일치합니다: 128GB 중 최대 96GB를 VRAM으로 전환할 수 있고(AMD), 64GB에서는 최대 48GB까지 가능합니다(AMD).

메모리 크기는 제조사가 대역폭에 쓰는 것과 같은 단위인 GB당 10^9바이트로 읽습니다. 실제 메모리 크기는 이진 단위이므로 이 방식은 용량을 약 7% 적게 잡으며, 모든 판단을 약간 보수적으로 만듭니다.

위 규칙으로 계산한 등급별 필요량:

등급	가중치(Q4_K_M)	컨텍스트 허용치	오버헤드	필요량	VRAM 기준	통합 메모리 기준
7-8B	4.89 GB	1.21 GB	1 GB	7.10 GB	7.10 GB	9.47 GB
14B	8.57 GB	1.34 GB	1 GB	10.91 GB	10.91 GB	14.54 GB
27-32B	19.58 GB	2.15 GB	1 GB	22.73 GB	22.73 GB	30.30 GB
70B	42.83 GB	2.68 GB	1 GB	46.51 GB	46.51 GB	62.01 GB
120B 이상	73.42 GB	2.95 GB	1 GB	77.37 GB	77.37 GB	103.16 GB

예를 들어 8GB GPU에는 7-8B 등급이, 24GB GPU에는 27-32B 등급이, 64GB 통합 메모리에는 70B 등급이 들어갑니다. 첫 번째 행보다 작은 머신은 어떤 등급도 들어가지 않는 것으로 표시됩니다.

속도: 예측이 아니라 상한

token 하나를 생성할 때마다 모델의 모든 가중치를 메모리에서 한 번씩 읽어야 하므로, 텍스트 생성은 메모리 대역폭에 의해 제한됩니다(NVIDIA: "Model execution is frequently memory-bandwidth bound"). 이로부터 상한이 나옵니다:

초당 token 수, 최대 = 메모리 대역폭 / 가중치 바이트.

예시(측정이 아니라 계산): 546 GB/s 칩에서 Q4_K_M 8B 모델(가중치 4.89 GB)을 실행하면 초당 약 111 token을 넘을 수 없습니다.

실제 속도는 항상 더 낮습니다. 이 상한은 컨텍스트를 읽는 시간, 연산, 소프트웨어 오버헤드를 무시합니다. llama.cpp discussion #4167에 모인 측정값을 보면 속도는 대역폭에 따라 증가하지만 선형보다 낮습니다. Apple silicon에서 Q4_0 Llama 2 7B의 경우: M3 Max(400 GB/s) 초당 66.31 token, M4 Max(546 GB/s) 83.06, M2 Ultra(800 GB/s) 94.27. 400에서 546 GB/s로(대역폭 1.37배) 늘리면 속도는 1.25배가 되었고, 800 GB/s로 두 배가 되면 1.42배가 되었습니다. 이 상한은 "이 머신은 이보다 빠를 수 없다"로 읽어야 하며, 절대 "이 머신은 이 속도로 실행된다"로 읽어서는 안 됩니다.

이 상한은 모든 token마다 모든 가중치를 읽는 dense 모델을 가정합니다. Mixture-of-experts 모델은 각 token에 활성화된 expert만 읽으므로, 전체 크기로 계산한 상한보다 빠르게 실행될 수 있습니다.

달러당 모델 메모리

그 목록의 정렬 방식 중 하나는 달러당 모델 메모리입니다: 모델 메모리(VRAM 또는 통합 메모리)의 기가바이트를 현재 Amazon 가격으로 나눈 값이며, 가격의 날짜가 함께 표시됩니다. "이 돈으로 가장 큰 모델을 담을 수 있는 것은 무엇인가"에 답합니다. 품질이나 속도 순위가 아니며, 수수료가 이 순서를 바꾸는 일은 절대 없습니다.

이 추정치가 아닌 것

• benchmark가 아닙니다. 이 수치를 만들기 위해 목록의 머신에서 모델을 실행한 적이 없습니다.
• 배터리 수명, 발열, 소음, 부하 상태에서의 지속 성능은 다루지 않습니다.
• 사용자 한 명, 대화 하나, llama.cpp 방식의 Q4_K_M 가중치를 가정합니다. 다른 런타임, 다른 양자화, 더 긴 컨텍스트에서는 답이 달라집니다.