Prime Agent Benchmark 2026 검증법

작업이 끝났다는 메시지는 나오지만 숨은 테스트에서 실패하고, 실행 시간과 API 사용량은 예상보다 커집니다.

가장 빠른 해결책은 공식 순위를 그대로 채택하지 않는 것입니다. 같은 모델, 저장소, 권한과 예산으로 기존 코딩 에이전트와 Prime Agent를 나란히 실행하고, 완료율·전체 소요 시간·모델 호출량·사람의 재작업률을 함께 기록한 뒤 이전 여부를 결정해야 합니다.

마지막 업데이트: 2026년 8월 11일
Prime Agent의 현재 저장소, 사용 설명서, 장기 실행 문서와 공식 기술 설명을 기준으로 내용을 확인했습니다. 공식 결과와 외부 관찰을 구분했으며, 공식 수치를 일반적인 운영 성능으로 확대하지 않습니다.

이 글은 Prime Agent가 기존 코딩 에이전트보다 실제 개발 환경에서 나은지 확인하려는 연구 책임자를 위한 글입니다. 긴 작업의 연산량과 API 비용을 추정해야 하는 인프라 팀, 에이전트 회귀 평가 체계를 만들려는 AI 엔지니어도 대상입니다.

먼저 성공 판정을 세 가지 층위로 나누기

Prime Agent는 지속적인 파이썬 실행 환경, 하위 에이전트 호출, 장기 세션 유지와 목표 보존을 중심으로 설계되어 있습니다. 저장소 설명에는 터미널 연결이 끊긴 뒤 세션을 다시 연결하고, 자동 문맥 압축과 진행 목표를 사용할 수 있다고 적혀 있습니다. 다만 기능이 있다는 사실과 작업이 정확히 끝났다는 사실은 다릅니다. 공식 저장소의 구조와 사용 범위를 먼저 확인해야 합니다.

평가 결과는 다음처럼 분리해야 합니다.

화면에 성공 메시지가 나오거나 마지막 답변이 자연스럽다는 이유만으로 성공 처리하면 안 됩니다. 자동 품질 검사는 자신이 검사한 항목만 확인합니다. 실행 제한에 도달했다는 사실도 작업 성공을 뜻하지 않습니다. 장기 실행 및 자동 모드 문서를 기준으로 성공 조건을 따로 정의하세요.

첫 번째 점검: 정확도는 숨은 검증과 재작업으로 측정하기

실제 개발 작업은 한 파일의 단순 수정만으로 구성하면 안 됩니다. 다음 유형을 섞어야 장기 작업 능력과 코드 품질을 함께 볼 수 있습니다.

• 기존 결함 수정과 회귀 테스트 작성
• 여러 파일을 가로지르는 구조 변경
• 테스트가 부족한 모듈의 검증 코드 보완
• 의존성이나 설정 변경
• 실패한 테스트의 원인 추적과 수정
• 코드 변경 뒤 문서와 예제의 일관성 확인

각 작업에는 공개 지시문과 별도로 숨은 검증을 준비합니다. 공개 테스트만 제공하면 에이전트가 특정 테스트를 통과하는 좁은 경로를 선택할 수 있습니다. 숨은 테스트는 입력 경계, 오류 처리와 기존 기능 보존을 확인해야 합니다.

정확도는 다음 방식으로 기록할 수 있습니다.

유효 완료율 = 숨은 검증을 통과한 작업 수 ÷ 전체 작업 수

사람의 수정이 들어간 작업은 별도 표시해야 합니다. 에이전트가 만든 결과를 사람이 고쳐 통과시켰다면 완전 성공이 아니라 부분 성공 또는 사람 인계 성공으로 분류하는 편이 안전합니다.

코드 검토에서는 테스트 통과 여부만 보지 마세요. 중복 로직, 위험한 권한 사용, 되돌리기 어려운 변경, 문서 누락과 회귀 가능성을 함께 기록해야 합니다. 이 기록이 있어야 Prime Agent의 최종 답변이 실제 유지보수에 적합한지 판단할 수 있습니다.

두 번째 점검: 속도는 모델 응답이 아니라 전체 시간으로 재기

RLM Agent는 문맥을 변수처럼 다루고, 지속적인 실행 환경에서 하위 모델을 호출하는 방식입니다. 공식 기술 설명은 하위 모델 호출을 병렬화할 수 있다고 설명하지만, 병렬 호출이 항상 전체 작업 시간을 줄인다는 뜻은 아닙니다. 하위 작업 대기, 재시도, 문맥 압축과 최종 통합 시간이 함께 발생할 수 있습니다. RLM 구조와 실험 조건을 확인할 때도 이 조건을 분리해서 읽어야 합니다.

측정 구간은 다음처럼 고정하세요.

1. 실행 환경을 준비한 시점부터 시작합니다.
2. 에이전트가 저장소와 지시를 읽는 시간을 포함합니다.
3. 계획 수립, 파일 탐색, 도구 실행과 하위 에이전트 대기 시간을 포함합니다.
4. 테스트, 재시도와 문맥 압축 시간을 포함합니다.
5. 최종 검증과 사람이 결과를 확인하는 시점까지 기록합니다.

짧은 작업과 긴 작업도 분리해야 합니다. 짧은 결함 수정에서는 초기화 시간이 결과를 좌우할 수 있습니다. 긴 구조 변경에서는 하위 에이전트 대기와 상태 복구가 더 큰 비중을 차지할 수 있습니다. 모델의 첫 응답 시간만 비교하면 Prime Agent의 실제 운영 특성을 측정하지 못합니다.

주의: 터미널이 멈추지 않았다는 사실은 작업이 진행 중이라는 뜻이 아닙니다. 일정 시간 동안 로그와 파일 변경이 없으면 대기, 교착 또는 반복 호출 상태로 따로 기록해야 합니다.

세 번째 점검: 비용은 전체 작업 사슬로 계산하기

하위 모델 호출은 별도의 입력과 출력을 만들 수 있습니다. 긴 입력을 여러 하위 작업으로 나누면 주 모델의 사용량만 확인했을 때 실제 비용이 작게 보일 수 있습니다. 따라서 주 모델과 하위 모델의 호출을 같은 로그에서 집계해야 합니다. 공식 RLM 실험의 토큰 사용 설명을 참고할 수 있습니다.

한 번의 유효 완료 비용에는 다음 항목이 들어갑니다.

• 주 모델의 입력 및 출력 토큰
• 하위 에이전트의 입력 및 출력 토큰
• 실패 뒤 재시도와 중복 실행
• 문맥 압축이나 요약에 사용된 호출
• 검색, 실행기와 저장소 분석 같은 외부 도구 호출
• 에이전트가 사용하는 클라우드 맥 또는 서버의 실행 시간
• 사람이 로그를 읽고 수정한 시간

유효 완료 비용 = 성공 작업의 전체 비용 + 실패 작업 비용 + 사람의 재작업 비용

단순한 호출 단가 비교보다 이 식이 구매 판단에 적합합니다. 실패율이 낮아도 긴 작업마다 하위 에이전트가 과도하게 호출되면 총비용이 커질 수 있습니다. 반대로 한 번의 실행 비용이 높아도 사람의 수정 시간이 줄어들면 유효 완료 비용은 낮아질 수 있습니다.

네 번째 점검: 장기 안정성과 복구를 따로 시험하기

Prime Agent 저장소는 세션 재연결, 저장된 세션 재개, 목표 유지와 일정 실행을 지원한다고 설명합니다. 그러나 복구 기능이 있다는 것만으로 진행 상태가 올바르게 복원된다고 판단할 수는 없습니다. 공식 사용 명령과 세션 문서를 기준으로 실제 중단 시험을 설계하세요.

다음 상황을 순서대로 넣어 보세요.

• 계획을 세운 직후 터미널 연결을 끊습니다.
• 파일을 일부 수정한 뒤 프로세스를 종료합니다.
• 테스트 실패가 발생한 상태에서 세션을 다시 연결합니다.
• 하위 에이전트가 실행 중일 때 주 세션을 재개합니다.
• 예산이나 시간 제한에 도달한 뒤 다시 시작합니다.

복구 후에는 네 가지를 확인해야 합니다. 목표를 잊지 않았는지, 이미 완료한 명령을 반복하지 않는지, 실패 원인과 중간 결과를 보존하는지, 최종 결과가 처음 작업 공간의 조건과 일치하는지입니다.

같은 파일을 여러 번 덮어쓰거나 이미 통과한 테스트를 반복 실행하면 시간과 비용뿐 아니라 데이터 손상 위험도 커집니다. 중단 전후의 변경 파일 목록, 실행 명령과 테스트 결과를 저장하면 복구 품질을 비교하기 쉽습니다. 원격 접속 방식과 작업 공간 권한을 사전에 점검하려면 ZavCloud 도움말 센터의 관련 안내도 함께 확인하세요.

다섯 번째 점검: 같은 조건으로 기존 도구와 비교하기

공정한 Agent Evals를 만들려면 도구보다 조건을 먼저 고정해야 합니다. Prime Agent와 기존 에이전트에 다음 항목을 동일하게 제공하세요.

• 같은 저장소 커밋과 초기 작업 공간
• 같은 모델 이름과 모델 버전
• 같은 시스템 지시와 작업 프롬프트
• 같은 파일 및 셸 권한
• 같은 최대 시간과 토큰 예산
• 같은 테스트 명령과 성공 판정
• 같은 사람의 개입 규칙

실행 순서는 번갈아 바꾸는 편이 좋습니다. 한 도구를 항상 먼저 실행하면 캐시나 저장소 상태가 결과에 영향을 줄 수 있습니다. 공식 RLM 실험도 같은 환경에서 일반 모델 구성과 RLM 구성을 비교하며, 절대 점수보다 상대적인 차이를 보는 방식으로 설명합니다.

비교 결과에는 평균만 쓰지 마세요. 긴 작업의 최악 구간, 실패 작업의 재시작 횟수, 사람 인계가 발생한 비율을 함께 표시해야 실제 운영 위험이 드러납니다.

결과를 배포 선택으로 바꾸는 조건

다음 조건으로 결론을 나누면 됩니다.

• 완료율과 숨은 테스트 통과율이 기존 도구보다 높고 유효 완료 비용이 예산 안에 있으면 제한된 저장소에서 계속 시험합니다.
• 완료율은 높지만 장기 작업의 복구나 재작업률이 불안정하면 공유 환경 대신 격리된 전용 환경에서 제한적으로 운영합니다.
• 하위 호출량과 사람의 검수 시간이 커서 유효 완료 비용이 높으면 모델이나 지시를 바꾸기 전에 작업 집합을 다시 설계합니다.
• 터미널 중단 뒤 목표나 상태를 잃으면 장기 작업의 기본 도구로 채택하지 않고 짧은 작업에만 사용합니다.
• 권한 경계와 저장소 격리가 불명확하면 운영 서버가 아니라 별도 클라우드 맥 환경에서만 시험합니다.

Prime Agent는 모델이 생성한 파이썬과 프로젝트 명령을 사용자의 권한으로 실행할 수 있습니다. 공식 저장소도 이를 완전한 보안 격리 환경으로 보지 말라고 안내합니다. 신뢰하지 않는 코드나 지시를 실행할 때는 외부 격리 환경 또는 제한된 권한을 사용해야 합니다. 공식 보안 안내를 반드시 검토하세요.

평가 전에 확인할 항목

• [ ] Prime Agent의 현재 버전과 실행 명령을 저장했습니다.
• [ ] 모델 버전과 모델 제공 조건을 고정했습니다.
• [ ] 공개 테스트와 숨은 테스트를 분리했습니다.
• [ ] 짧은 작업과 긴 작업을 모두 포함했습니다.
• [ ] 시작부터 최종 검수까지 전체 시간을 기록합니다.
• [ ] 주 모델, 하위 에이전트와 재시도 호출을 합산합니다.
• [ ] 중단과 재연결 뒤 상태 복구를 시험합니다.
• [ ] 사람의 재작업 시간과 인계 비율을 기록합니다.
• [ ] 기존 도구와 같은 저장소, 권한, 예산을 사용합니다.
• [ ] 결과를 공유 환경, 전용 환경 또는 이전 보류로 연결합니다.

공식 문서의 모델, 기본 설정과 평가 방식이 바뀌면 같은 결과를 그대로 비교할 수 없습니다. 게시하거나 구매 결정을 내리기 전에는 현재 버전, 라이선스, 명령과 테스트 조건을 다시 확인해야 합니다.

Prime Agent가 기존 방식보다 유리하더라도 모든 조직에 즉시 적합한 것은 아닙니다. 현재 사용 중인 방식은 장기 세션 복구가 약하고, 하위 작업 호출과 전체 비용을 한눈에 보기 어렵고, 터미널이 끊긴 뒤 진행 상태를 확인하기 힘들 수 있습니다. 반대로 Prime Agent도 실행 권한이 넓고, 긴 작업에서 호출량과 검수 비용이 커질 가능성이 있습니다.

따라서 바로 교체하기보다 같은 이미지와 저장소를 준비한 격리된 클라우드 맥에서 두 도구를 병렬 실행해 자신의 기준선을 확보하는 편이 안전합니다. 임시 평가 환경이나 구매 전 검증이 필요하다면 ZavCloud의 맥 미니 대여 안내를 확인하고, 결과가 축적된 뒤 계속 시험, 제한 운영 또는 이전 보류 중 하나를 선택하세요.