작성자 주석: 이 글은 YC Paper Club Harness Night의 공개 발표를 바탕으로, 팀이 점수 차이가 모델에서 온 것인지 Harness에서 온 것인지 구분할 수 있도록 실제 적용 가능한 모델 평가 방법을 정리했어요.
같은 Claude Opus가 비공개 홀드아웃 세트에서 기록한 최고 점수는 30%였어요. 그런데 Prime Agent에 넣었을 때 공개 발표에서 언급된 점수는 95.5%였죠. 리더보드만 보면 모델이 질적으로 완전히 달라졌다고 생각할 수 있지만, 이 숫자들은 먼저 이런 점을 일깨워줘요: 모델 평가는 종종 모델만이 아니라 전체 시스템을 비교하는 일이에요.
이 글은 리더보드를 포기하라고 권하는 글이 아니에요. Harness만 붙이면 어떤 모델이든 점수가 끝없이 오른다고 주장하는 것도 아니고요. 이 글에서는 별도 재검증을 하지 않았고, 인용한 점수는 모두 InfoQ가 정리한 발표 내용에서 가져왔어요. 핵심은 그 경험을 실행 가능한 평가 프로세스로 바꾸는 데 있어요.
핵심 가치: 이 글을 다 읽으면 6단계로 모델과 Harness의 대조 실험을 설계하고, 점수 차이가 어디서 비롯됐는지 판단하며, 더 신뢰할 수 있는 모델 선택 결론을 내리는 방법을 익힐 수 있어요.

Harness만 바꿔도 성적이 두 배: 모델 평가의 핵심 포인트
Harness는 LLM과 외부 세계 사이에 놓인 하나의 시스템 계층으로, 영속 상태와 도구, 연산 능력을 제공해요. Seth Karten은 이런 비유를 썼어요. 맨몸의 LLM은 튜링 기계 같고, Harness는 외부 메모리를 읽고 쓸 수 있는 폰 노이만 컴퓨터 같다는 거죠. 에이전트를 평가할 때는 모델의 추론 능력과 이 계층 시스템의 표현력이 동시에 결과에 영향을 줘요.
아래 표는 발표 내용 중 ARC-AGI와 관련된 일부 공개 데이터를 정리한 거예요. 이 성적들은 서로 다른 모델, Harness, 평가 구성에서 나온 것이라 모델 순위처럼 그대로 받아들이면 안 돼요.
| 구성 | 공개 성적 | 읽을 때 주의할 점 |
|---|---|---|
| Claude Opus, 비공개 보존 세트 검증 | 최고 성적 30% | 발표에서의 베이스라인일 뿐, 모든 실행 조건을 대표하지는 않아요 |
| Prime Agent + Opus | 95.5% | 자료가 베이스라인과의 모든 차이를 항목별로 공개하지 않았으니 단일 변수 탓으로만 돌리기는 어려워요 |
| Prime Agent + GPT-5.6 Sol | 78% | 샌드박스 격리를 마친 뒤의 성적이에요 |
| Prime Agent + GPT-5.6 Terra | 25.7% | 같은 Harness에서도 모델 간 차이는 여전히 뚜렷해요 |
| Nvidia AVO | 100% | 발표에서는 결과만 제시했으니 비교 전에 구체적인 구성을 확인해야 해요 |
Harness와 모델 평가의 관계
Prime Agent는 컨텍스트를 세 계층으로 나눠요. L1은 모델 가중치, L2는 활성 컨텍스트와 REPL, L3는 파일 시스템 같은 스케줄링 상태예요. Harness는 계층과 계층 사이에서 압축, 조회·추가·수정·삭제, refinement를 수행하는데, 그 역할이 캐시에 가비지 컬렉션을 얹은 것에 가까워요. 즉 같은 모델이라도 Harness를 바꾸면 활용할 수 있는 기억과 연산 능력이 달라질 수 있다는 뜻이에요.
하지만 그렇다고 모델이 중요하지 않다는 건 아니에요. Prime Agent는 ARC-AGI에서는 두드러진 성적을 냈지만, Oolong, Emulator Bench 같은 장기 주기 평가에서는 대체로 비슷하거나 조금 나은 수준이었고, GPU 커널 작업도 대략 비슷했어요. 작업 유형이 Harness가 차이를 얼마나 증폭시킬 수 있는지를 결정해요, 그래서 특정 항목의 성적을 모든 시나리오에 외삽할 수는 없어요.

모델 평가에서 가장 자주 틀리는 5가지 변수
| 변수 | 흔한 잘못된 비교 | 기록해야 할 것 |
|---|---|---|
| 모델 | 시리즈 이름만 쓰고 구체적인 버전은 안 씀 | 모델 ID, 실제 호출 기록, 폴백이나 전환 상황 |
| Harness | 기본 구성을 모델 능력으로 착각 | 도구, 시스템 프롬프트, 서브 에이전트, 기억과 압축 메커니즘 |
| 예산 | A는 플랫폼기에 도달할 때까지 돌리고 B는 일찍 중단 | 토큰, 실제 시간, 비용, 조기 중단 조건 |
| 평가 세트 | 공개 세트 성적으로 비공개 세트 성적과 비교 | 데이터셋 버전, 격리 방식, 정보 유출 여부 |
| 판정 방식 | LLM에게 수정이나 정답 성공 여부만 판단시킴 | 채점 규칙, 사람 표본 검수 비율, 논쟁이 되는 표본 |
실무 제안: 같은 평가 프로세스에서 여러 모델을 비교해야 한다면 APIYI apiyi.com을 통해 이 글에 나온 모델을 호출해 접속 차이를 줄일 수 있어요. APIYI는 OpenAI와 Anthropic 인터페이스 형식을 지원하며, 구체적인 모델 이름과 접속 방식은 docs.apiyi.com 문서를 기준으로 확인하세요.
Harness 모델 평가 빠르게 시작하기: 6단계
아래 흐름은 모델 선정, Agent 업그레이드, 내부 벤치마크 테스트에 적합해요. 처음부터 거대한 평가 플랫폼을 구축할 필요는 없고, 먼저 변수를 빠짐없이 기록한 다음 작업과 모델을 점차 늘려가면 돼요.
1단계: 모델 평가의 비교 대상 명확히 하기
먼저 한 문장으로 실험 질문을 정의하세요. 예를 들어 “동일한 Harness와 예산 아래에서 두 모델이 내부 코딩 작업을 완수하는 능력을 비교한다”처럼요. 만약 질문을 “어떤 Agent가 더 나은가”로 쓴다면 비교 대상은 모델과 Harness의 조합이 되고, 결론도 “어떤 모델이 더 강한가”로 쓸 수 없어요.
평가 스펙에는 최소한 model, 시스템 프롬프트, 도구 목록, max_tokens, 최대 턴 수, 총 예산을 고정해야 해요. Harness가 Agent의 런타임 자율 선택을 허용한다면, 각 단계에서 실제로 사용된 모델도 기록해야 하죠. QM의 설계는 Agent가 거부를 만났을 때 다른 모델로 전환하는 것을 허용하는데, 이 경우 최종 점수는 더 이상 단일 모델에 속하지 않아요.
2단계: Harness 평가 환경과 데이터 격리
Seth는 한때 커뮤니티 리더보드의 시스템 프롬프트를 Prime Agent에 넣었고, 첫 실행에서 99.9%를 기록했어요. 그런데 로그를 확인해 보니 자신이 사실상 ‘치팅’을 하고 있었다는 걸 발견했고, 하루를 들여 샌드박스 격리를 마친 뒤 GPT-5.6 Sol의 점수는 78%가 됐어요. 높은 점수가 반드시 잘못된 것은 아니지만, 이상하게 높은 점수는 반드시 로그부터 확인해야 해요.
점검할 때는 세 가지를 중점적으로 봐요. Agent가 정답이나 과거 결과를 읽을 수 있는지, 프롬프트에 평가 세트 전용 정보가 들어 있는지, 도구 호출이 사전에 정한 권한을 벗어났는지예요. 공개 벤치마크 외의 작업에서는 튜닝에 참여하지 않는 홀드아웃 샘플 세트를 남겨 두어야 해요. 프롬프트와 Harness가 과적합되는 걸 막기 위해서죠.
3단계: ‘모델 × Harness’ 매트릭스로 비교하기
‘모델 A + Harness A’와 ‘모델 B + Harness B’만 돌리면 안 돼요. 두 변수가 동시에 바뀌면 어떤 요인 때문인지 귀속시킬 수 없거든요. 최소안은 2 × 2 매트릭스예요. 두 모델을 각각 두 세트의 Harness에서 실행하고, 작업 세트와 예산은 동일하게 유지해요.
| 매트릭스 결과 | 더 가능성 높은 해석 | 다음 단계 행동 |
|---|---|---|
| 모델을 바꾸면 크게 변하고, Harness를 바꾸면 변화가 작음 | 현재 작업이 모델 능력에 더 의존함 | 모델 선정을 우선 |
| Harness를 바꾸면 크게 변하고, 모델을 바꾸면 변화가 작음 | 시스템 능력이 주요 병목 | 도구와 컨텍스트 관리 개선을 우선 |
| 둘의 교차 영향이 뚜렷함 | 모델과 Harness 사이에 적합성 관계가 존재 | 조합 단위로 선정하고 단일 순위는 쓰지 않음 |
| 둘 다 뚜렷한 변화가 없음 | 작업이 너무 쉽거나 너무 어렵거나, 채점이 둔감함 | 평가 세트와 지표를 재설계 |
대조 실험 제안: 매트릭스 실험은 모델을 자주 바꿔야 해요. APIYI apiyi.com을 통해 하나의 계정과 인터페이스 설정으로 여러 모델을 호출하고, 실험 기록에 모델 ID를 남겨 두면 나중에 추적하기 편해요.

4단계: 예산을 맞추고 모델 성능 플래토 관찰하기
Seth는 공유에서 이렇게 짚었어요. 어떤 모델이 충분히 오래 실행되지 않거나, 예산이 소진된 뒤 멈추는데 다른 모델은 계속 작동한다면, 같은 지출 기준으로 비교하지도 못하고 실제 성능도 가리게 된다고요. 더 합리적인 방법은 여러 예산 지점을 설정하고, 점수가 토큰 또는 시간에 따라 증가하는 곡선을 관찰하는 거예요.
QM 팀의 경험도 예산의 중요성을 보여줘요. 이들은 Agent가 너무 일찍 포기하는 경우가 많다는 걸 발견하고, 이른바 “도구를 갈고닦기”를 시도했어요. 목표에 예산을 설정하고, 실제 시간이나 토큰 소비에 도달하기 전에는 포기하지 못하게 했더니 연구 출력이 좋아졌다고 해요. 그래서 평가 스펙에는 예산 상한만 적을 게 아니라, 최소 투입 요구가 있는지도 분명히 적어야 해요.
5단계: Harness에 대한 어블레이션 테스트 하기
Harness가 향상을 가져온 걸 확인했다면, 다음 단계는 그 향상이 어느 능력에서 나오는지 찾는 거예요. Prime Agent는 표현력을 강조하며, 압축, Python REPL, 프로그래밍 방식의 하위 Agent, 상태 접근, 피드백 메커니즘을 쉽게 제거해서는 안 된다고 봐요. 하지만 여러분의 작업에서는 각 능력의 실제 기여도를 여전히 테스트해야 해요.
방법은 한 번에 하나의 능력만 끄는 거예요. 예를 들어 REPL을 끄거나, 하위 Agent를 끄거나, 장기 기억을 끄고 다른 구성은 그대로 두는 식이죠. 껐을 때 점수는 거의 그대로인데 비용이 눈에 띄게 줄어든다면, 그 능력은 당분간 유지할 가치가 없을 수 있어요. 자동 연구처럼 분산이 큰 작업은 여러 번 반복 실행해야 해요. Seth도 이런 작업은 Harness나 모델에 직접 귀인하기 어렵다고 언급했기 때문이에요.
6단계: 비용 산정과 수동 검토 추가
Seth는 또, Hermes Agent로 평가를 돌리다가 5,000달러를 순식간에 써 버렸는데도 뚜렷한 개선이 없어 중단할 수밖에 없었다고 해요. 이게 Hermes Agent의 성능 한계를 뜻하는 건 아니지만, 비용 대비 성능을 평가 결론에 반드시 넣어야 한다는 점은 충분히 보여줘요. 최종 보고서에는 성공률, 완료 시간, 토큰 소비량, 성공 1회당 비용을 함께 적는 걸 권장해요.
비용을 계산할 때 평가 스크립트 설명에 가격을 하드코딩하지 마세요. 모델의 입력·출력 단가, 캐시 가격, 과금 기준은 APIYI 가격 페이지인 https://docs.apiyi.com/models 의 실제 데이터를 기준으로 하고, 보고서에는 조회 날짜를 표시하세요.
채점 단계에서도 수동 표본 검사는 남겨 두어야 해요. QM 팀은 LLM이 수정 결과를 평가할 때 “주인공 증후군”이 나타난다는 걸 발견했어요. 코끼리의 일부만 보고 전체 시스템은 보지 못하는 거죠. 비즈니스 프로세스가 얽힌 경우에는 권한 경계도 테스트해야 해요. Agent는 사회적 맥락을 이해하는 능력이 떨어져서, 특권 정보가 나오면 안 되는 컨텍스트로 새어 나갈 수 있기 때문이에요.
API로 모델 평가 매트릭스 구현하기
실제로 실행할 때는 평가를 작업 세트, 실행 구성, 결과 기록의 세 부분으로 나누는 걸 권장해요. 이렇게 하면 모델이나 Harness를 바꿀 때 구성 항목 하나만 수정하면 되고, 전체 프로세스를 다시 작성할 필요가 없어요.
| 구성 항목 | 기록 권장 내용 | 설명 |
|---|---|---|
| 인터페이스 형식 | OpenAI 호환 또는 Anthropic 형식 | 형식에 따라 도구 호출과 메시지 구조가 다를 수 있으므로 별도로 검증해야 해요 |
| 접속 주소 및 키 | base_url, 환경 변수 이름 |
주소는 docs.apiyi.com 문서를 기준으로 하고, 키는 평가 보고서에 기록하지 마세요 |
| 실행 파라미터 | model, max_tokens, 최대 라운드 수, 반복 횟수 |
각 실험을 재현할 수 있어야 해요 |
| 비용 산정 기준 | 입력·출력·캐시 및 조회 날짜 | APIYI 가격 페이지 docs.apiyi.com/models의 실제 데이터를 기준으로 해요 |
| 실행 결과 | 점수, 실패 이유, 토큰, 소요 시간, 호출 로그 | 플래토(정체기)와 비용 대비 성능 비율을 분석하는 데 사용해요 |
Harness가 두 인터페이스를 모두 지원한다면, 먼저 같은 모델로 형식 대조를 한 번 해 보세요. 이렇게 하면 메시지 변환, 도구 정의, 스트리밍 응답이 결과에 영향을 주지 않았는지 확인할 수 있고, 연동 문제를 모델 성능 차이로 오판하는 일을 피할 수 있어요.
연동 팁: APIYI는 이 글에서 다루는 모델의 API 호출을 제공하며, OpenAI와 Anthropic 인터페이스 형식을 모두 지원해요. 실험을 시작하기 전에 docs.apiyi.com에서 현재 사용 가능한 모델과 호출 방식을 확인한 뒤, 모델 ID를 평가 스펙에 기록하세요.

자주 묻는 질문 FAQ
Q1: 모델 평가에서 Harness란 무엇인가요?
Harness는 모델과 외부 세계를 연결하는 시스템 계층으로, 일반적으로 루프 제어, 컨텍스트 관리, 도구, 서브 에이전트, 메모리, 상태 접근을 포함해요. 모델이 무엇을 볼 수 있고, 무엇을 호출할 수 있으며, 얼마나 오래 실행될 수 있는지를 결정하죠.
Q2: Harness 점수가 더 높으면 모델이 강해졌다고 볼 수 있나요?
아니요. 가중치가 변하지 않았을 때 점수 상승은 시스템이 더 많은 능력을 끌어냈다는 뜻이거나, 설정이 이 작업에 더 적합했다는 뜻일 가능성이 커요. Harness, 예산, 모델이 동시에 바뀌면 개별 요인으로 귀인할 수 없고, 평가 환경에 누수가 있었을 수도 있어요.
Q3: 언제 모델 평가를 다시 해야 하나요?
모델 버전, 시스템 프롬프트, 도구 권한, 압축 전략, 비즈니스 작업이 바뀌면 모두 다시 평가해야 해요. Harness 분야는 반복이 매우 빨라서, 이 글의 데이터는 2026년 11월 InfoQ에서 발표한 정리 내용을 바탕으로 한 것이며 이후 성적은 달라질 수 있어요.
Q4: 이 모델 평가 방법은 어떤 상황에 적합한가요?
주로 다음 상황에 적합해요.
– **내부 코딩 에이전트 선정**: 모델과 Harness 조합의 작업 완료율을 비교해요.
– **장기 연구 작업**: 예산을 늘린 뒤의 정체 구간과 결과 분산을 관찰해요.
– **기업 에이전트 출시 전 검증**: 품질, 비용, 권한 경계를 동시에 테스트해요.
Q5: 여러 모델을 빠르게 연결해 Harness를 비교하려면 어떻게 해야 하나요?
먼저 평가 작업과 모델 목록을 정한 다음, APIYI apiyi.com을 통해 연결하면 돼요. 플랫폼은 이 글에서 다룬 모델의 API 호출을 제공하며 OpenAI와 Anthropic 인터페이스 형식과 호환돼요. 구체적인 모델 ID와 설정 방법은 docs.apiyi.com 문서를 확인하고, 실험 중에는 다른 변수를 그대로 유지하세요.
Q6: 평가 보고서의 모델 가격은 어떻게 적어야 하나요?
검증된 가격 데이터만 인용하고 조회 날짜를 명시하는 걸 권장해요. 모델의 입력·출력 단가, 캐시 가격, 과금 기준은 모두 APIYI 가격 페이지 https://docs.apiyi.com/models 의 실제 데이터를 기준으로 해야 하며, 오래된 표나 추정값을 그대로 쓰지 마세요.
Q7: 이 Harness 평가 방법에는 어떤 한계가 있나요?
매트릭스 실험, 반복 실행, 사람에 의한 재검토는 모두 시간과 비용을 늘려요. 장기 작업의 분산도 클 수 있어서, 주요 변수를 통제하더라도 정확하게 귀인하기는 어려워요. 따라서 의사 결정을 뒷받침하는 용도에 더 적합하며, 한 번의 결과를 절대적인 순위로 받아들여서는 안 돼요.
Harness 모델 평가 핵심 요점 Key Takeaways
- 먼저 비교 대상을 정의하세요: 비교하는 것이 모델인지, 아니면 모델과 Harness의 조합인지 구분해야 해요.
- 비정상적으로 높은 점수는 먼저 로그를 확인하세요: 99.9%의 사례가 격리 환경이 평가의 전제임을 보여줘요.
- 매트릭스로 변수를 분리하세요: APIYI를 통해 여러 모델을 연결한 뒤 모델 × Harness 대조를 수행하세요.
- 예산은 반드시 정렬해야 해요: 여러 예산 지점에서 곡선을 관찰해 실제 플래토(정체 구간)를 찾으세요.
- 어블레이션으로 기여도를 파악하세요: 한 번에 하나의 기능을 끄면서 개선이 어디서 오는지 확인하세요.
- 비용 데이터는 검증해야 해요: 가격과 과금 기준은 APIYI 가격 페이지를 기준으로 하세요.
- 인간의 판단을 남겨두세요: LLM 평가는 편향될 수 있고, 권한 리스크도 별도로 테스트해야 해요.
정리
“Harness만 바꿔도 성적이 두 배가 된다”는 점은 주목할 만하지만, 이를 단순히 “모델이 중요하지 않다”고 이해해서는 안 돼요. 공유된 데이터는 Harness의 증폭 효과를 보여주는 동시에, 서로 다른 모델과 작업 사이에 여전히 뚜렷한 격차가 있음을 보여줘요. 신뢰할 수 있는 결론은 반드시 통제된 실험 위에 세워져야 해요.
실제 적용 시 우선 기억해야 할 세 가지:
- 평가 대상을 명확히 작성하세요: 모델, Harness, 예산, 평가 세트, 평가 방식을 기록하세요.
- 실험 설계는 귀인이 가능해야 해요: 매트릭스 실험과 어블레이션 테스트로 변수를 분리하고, 평가 환경을 격리하세요.
- 결론은 시나리오를 지향해야 해요: 플래토, 비용 대비 성능 비율, 인간 검토 결과, 권한 리스크를 함께 살펴보세요.
자신의 모델 조합을 검증할 준비가 되었다면 APIYI apiyi.com을 통해 이 글에서 다룬 모델을 연결하고, docs.apiyi.com 문서에 따라 설정을 완료하세요. 비용 산정이 필요할 때는 https://docs.apiyi.com/models 에서 현재 가격 데이터를 확인하세요.
📚 참고 자료
- InfoQ: 같은 모델이 30점에서 95점으로 — 격차를 만드는 것은 모델이 아니라 Harness
- 링크:
infoq.cn/article/C1C1DThg8z1Dy0rZAmLB -
설명: 이 글에서 인용한 성적, 사례, 설계 관점은 모두 이 정리 글에서 가져왔습니다.
-
YC Paper Club Harness Night 발표 영상
- 링크:
youtube.com/watch?v=n9xKblqyQ28 -
설명: Prime Agent, OpenJarvis, QM 세 세션의 전체 맥락을 확인할 수 있습니다.
-
APIYI 문서 센터
- 링크:
docs.apiyi.com -
설명: 사용 가능한 모델, 인터페이스 형식, 연동 설정을 확인할 때 사용합니다.
-
APIYI 모델 가격 페이지
- 링크:
docs.apiyi.com/models - 설명: 모델 단가, 캐시 가격, 과금 기준은 모두 이 페이지의 실제 데이터를 기준으로 합니다.
작성자: APIYI 기술팀
기술 문의: 모델 연동 방식을 알고 싶다면 APIYI 공식 웹사이트 apiyi.com을 방문해 주세요. 더 많은 자료는 docs.apiyi.com 문서 센터에서 확인할 수 있습니다.
