evals-from-sessions: 정답 ID가 달라도 통과해야 하는 평가

코딩 에이전트를 비교하기 전에, 채점기가 다른 형태의 정답도 받아들이는지 확인해야 합니다. 기준 답안과 다른 증거를 골랐다는 이유로 정답을 탈락시킬 수 있고, 그 검사를 느슨하게 고치다가 필요한 증거가 빠진 오답까지 통과시킬 수 있기 때문입니다. evals-from-sessions에서 살펴볼 부분은 이 두 실패를 따로 검사하는 절차입니다.

evals-from-sessions는 자신의 코딩 에이전트 작업 기록을 Harbor 평가 과제로 바꾸도록 안내하는 에이전트 스킬입니다. 이 글은 2026년 10월 14일의 커밋 4e85a19에 고정한 소스와 문서를 검토했습니다. 스킬 메타데이터의 버전은 1.0.4이며, 별도 GitHub 릴리스가 발표된 것으로 소개하는 글은 아닙니다. Harbor나 모델을 직접 실행하지 않았으며, 아래 판정은 설명용 사례의 기대 결과입니다.

실패 기록 F1과 F2, 통과 기록 C1과 C2에서 두 ID를 고르는 평가 개념도. F1·C1과 F2·C2는 통과하고 F1·F2는 통과 기록이 없어 실패한다.

AI로 생성한 설명용 이미지입니다. 실패 기록 하나와 통과 기록 하나를 골라야 하는 조건을 단순화한 개념도입니다. F1·C1과 F2·C2는 모두 조건을 충족하지만 F1·F2에는 통과 기록이 없습니다. 실제 Harbor 실행 결과가 아닙니다.

증거 두 개를 고르되, 정답을 하나로 고정하지 않기

실행 기록 네 개를 읽고 증거를 제출하는 작은 상황을 생각해 보겠습니다. F1과 F2는 실패한 실행의 ID, C1과 C2는 통과한 비교 실행의 ID입니다. 여기서는 원인 진단 과정은 생략하고, 증거 선택을 어떻게 채점할지만 보겠습니다.

출력 조건은 정확히 정합니다. evidence_ids에는 서로 다른 문자열 ID를 정확히 두 개 넣어야 합니다. 네 기록에 있는 ID만 허용하며, 실패 집합 {F1, F2}에서 하나, 통과 집합 {C1, C2}에서 하나를 골라야 합니다. 두 ID의 순서는 자유입니다. 이 네 기록은 채점 기준을 설명하기 위한 축약 예제이며, 그대로 사용할 완성된 벤치마크 과제는 아닙니다.

풀이선택한 증거기대 판정이유
기준 풀이F1, C1통과실패와 통과 기록을 하나씩 선택
다른 올바른 풀이F2, C2통과선택한 ID는 달라도 같은 조건 충족
그럴듯한 오답 풀이F1, F2실패통과한 비교 실행이 빠짐

표는 세 풀이의 실제 실행 기록이 아닙니다. 서로 다른 풀이를 만들었을 때 채점기가 내려야 할 결정을 먼저 적은 것입니다. 이 결정을 고정해 두면, 점수가 이상할 때 모델의 문제와 채점 기준의 문제를 나눠 조사할 수 있습니다.

배열을 그대로 비교하면 다른 정답이 탈락한다

기준 답안이 F1, C1이라고 해서 제출한 배열도 그 두 ID와 같아야 한다고 검사하면 F2, C2는 실패합니다. 순서만 뒤집은 C1, F1도 배열의 순서까지 비교하면 탈락합니다. 그러나 위 조건에는 특정 ID나 순서를 선택하라는 요구가 없습니다. 채점기가 지시문보다 더 많은 것을 요구한 셈입니다.

이 지점은 프로젝트의 verify.py 템플릿을 읽을 때도 중요합니다. same()은 JSON 객체의 키 순서를 무시하고 내부 값을 비교하지만, 리스트는 길이와 각 위치의 값을 비교합니다. 따라서 이 함수에 기준 답안 전체와 제출 답안 전체를 넣는 것만으로는 서로 다른 유효 증거 ID를 같은 정답으로 인정할 수 없습니다.

템플릿의 결함이라는 뜻은 아닙니다. 템플릿의 본체는 과제별 검사를 작성하도록 비워져 있고, 기본 상태에서는 실패하게 되어 있습니다. 검증기 작성 지침도 자유롭게 고르는 증거는 기준 목록과의 일치 대신, 허용된 증거인지와 필요한 종류를 모두 포함하는지 검사하라고 명시합니다. JSON을 구조적으로 비교하는 일과 과제에서 허용한 여러 정답을 인정하는 일은 별도로 구현해야 합니다.

하나라도 겹치면 통과시키는 수정도 부족하다

다른 정답을 받아들이려고 ‘기준 답안과 하나라도 겹치면 통과’로 바꾸면 이번에는 F1, F2가 통과합니다. F1이 기준 답안에 있기 때문입니다. 하지만 두 개 모두 실패 기록이라 통과한 비교 실행을 제출하라는 조건을 충족하지 못합니다. 게다가 이 규칙은 기준 답안과 겹치지 않는 F2, C2도 여전히 탈락시킵니다.

이 사례에서 필요한 검사는 분명합니다. evidence_ids가 길이 2의 문자열 배열인지 확인하고, 중복이나 모르는 ID를 거부합니다. 이어서 실패 집합에서 정확히 하나, 통과 집합에서 정확히 하나를 골랐는지 확인합니다. 기준 답안과 겹치는지는 판정 조건이 아닙니다. 실패·통과 집합도 에이전트가 수정한 결과 파일에서 가져오면 안 됩니다. 검증기 쪽의 고정 입력이나 기대값으로 유지해야 합니다.

실제 과제에 옮길 때는 F1, F2라는 결과만 손으로 만드는 데서 끝나면 안 됩니다. 예를 들어 ‘실패 기록 두 개를 증거로 고르면 된다’고 잘못 해석하고 입력 전체에 그 규칙을 일관되게 적용하는 풀이를 만듭니다. 그 풀이가 탈락하는지 봐야 같은 실수를 다른 입력에서도 잡는지 확인할 수 있습니다.

다른 정답과 근접 오답을 모두 실행하는 이유

evals-from-sessions의 과제 검증 단계는 이 차이를 실제 풀이 단위로 검사하도록 요구합니다. 대안 정답은 기준 풀이와 기대값을 보지 않고 작성하며, 입력을 읽어 다른 유효한 선택을 해야 합니다. 근접 오답은 각 실패 유형에 대응하는 일관된 풀이여야 합니다. 기대 답안의 필드 하나를 바꾸는 것으로 대신하지 말라는 조건도 있습니다.

위 사례라면 대안 풀이는 실패와 통과 기록을 하나씩 고르되 기준 풀이와 다른 선택 기준을 사용할 수 있습니다. 근접 오답 풀이는 통과 기록이 필요한 이유를 놓치고 실패 기록만 고릅니다. 전자는 통과하고 후자는 실패해야 합니다. 채점기가 지나치게 좁은지와 지나치게 느슨한지를 서로 다른 방향에서 확인하는 것입니다.

프로젝트는 여기에 아무것도 하지 않는 nop의 실패, 기준 해결 스크립트를 실행하는 oracle의 다섯 차례 통과도 요구합니다. 다섯 번 통과했다는 사실만으로 모든 정답과 오답을 구분한다고 보장되지는 않습니다. 대안 정답과 근접 오답을 별도로 두는 이유가 여기에 있습니다. 실제 에이전트의 시험 실행이 실패했을 때도 모델의 실수, 지시문의 모호함, 올바른 결과를 탈락시킨 검증기 오류를 구분하도록 안내합니다.

채점 기준을 고쳤다면 과제 버전을 올리고 검증 절차와 영향을 받은 모델 설정을 다시 실행합니다. 수정 전 점수와 수정 후 점수를 같은 기준의 결과처럼 비교해서는 안 됩니다. 이미 비교에 쓰던 과제라면 이전 버전과 결과를 보관하고, 새 검증이 끝날 때까지 새 점수로 모델 선택을 바꾸지 않습니다.

도입 범위는 한 과제의 채점 기준부터

이 스킬을 실제로 사용하려면 Docker와 git, Python 3.11 이상, Harbor, gitleaks 8이 필요합니다. 모델을 사용하는 검사와 시험 실행에는 해당 에이전트·모델의 인증 정보도 필요합니다. MIT 라이선스로 공개된 스킬이라고 해서 실행 비용까지 무료인 것은 아닙니다. 컨테이너 실행 자원과 모델 사용 비용은 별도로 고려해야 합니다. Harbor 연동 문서의 명령 예시는 0.24.0 기준이므로 설치한 버전의 도움말로 옵션을 확인해야 합니다.

작업 기록에는 비밀 키와 사내 코드가 들어 있을 수 있습니다. private 모드는 자신의 저장소 스냅샷을 포함하므로 비공개로 유지해야 하고, shareable 모드는 코드·데이터·이름을 새로 작성하는 방식입니다. 여기서 private는 평가 과제를 공개하지 않는다는 뜻입니다. 모델 API를 쓰지 않거나 모든 데이터가 컴퓨터 밖으로 나가지 않는다는 보장은 아닙니다. Harbor 연동 문서는 모델 API 접근과 에이전트 설치를 위한 네트워크 사용을 설명하므로, 사용하는 제공업체로 어떤 내용이 전송되는지와 조직의 데이터 정책도 확인해야 합니다.

출처를 기록한 provenance.md는 공개본에서 제외합니다. gitleaks 검사에서 탐지되지 않았다는 것만으로 모든 민감한 내용이 제거됐다고 판단해서는 안 됩니다. 먼저 민감하지 않은 예제 저장소에서 과제 작성과 비용을 확인하는 편이 안전합니다.

프로젝트의 완료 지점은 사람이 검토할 준비가 된 평가 과제입니다. 여러 모델의 가격이나 성능 순위를 자동으로 확정하는 단계까지 포함하지 않습니다. 2026년 10월 18일 확인한 저장소의 별은 총 42개였고, Hacker News 소개 글은 2점이었습니다. 이는 확인 시점의 작은 관심 지표이며, 별의 증가 추이나 실사용 규모를 입증하는 자료는 아닙니다.

이 도구에서 먼저 가져올 만한 것은 기준 답안 하나의 통과 여부를 넘어서는 검증 방식입니다. 자신의 과제에서 선택이 자유로운 부분을 하나 찾고, 다른 올바른 풀이와 조건 하나를 일관되게 놓치는 풀이를 나란히 두세요. F2, C2를 받아들이면서 F1, F2를 거부하는 기준이 있어야, 그다음에 나온 모델 점수를 해석할 수 있습니다.

댓글