클로드 코드, 플러그인 뺀 점수와 비교한다

한 사례는 사람이 실제로 칠 만한 요청 한 덩어리와 채점기 하나 이상으로 이뤄져요. 실행마다 클로드 코드는 격리된 비대화형 세션을 새로 띄워 그 플러그인만 올리고, 클로드가 스스로 끝내거나 차례·시간 제한에 닿을 때까지 일하게 둬요. 채점기는 마지막 답변이나 작업 기록, 클로드가 만든 파일을 보고 통과와 실패를 가려요. 문서에 따르면 한 사례는 기본 세 번 돌고, 실행 점수는 통과한 채점기의 비율이며 사례 점수는 그 실행들의 평균이에요. 통과선 기본값이 1.0 이라 채점기 하나만 삐끗해도 그 사례는 떨어져요.

여기까지는 흔한 평가 도구예요. 갈라지는 곳은 그다음이에요. 같은 사례를 플러그인을 아예 올리지 않은 채 같은 횟수로 한 번 더 돌려서, 켠 점수와 끈 점수를 나란히 세워요. 요약 표에 WITH 와 W/OUT 이 찍히고 그 차이가 Δ 로 나와요.

문서는 "높은 점수 하나만으로는 플러그인이 도움이 됐는지 알 수 없습니다" 라고 적었어요. 켜도 1.0 이고 꺼도 1.0 이면 그 사례를 통과시킨 것은 플러그인이 아니라는 뜻이에요. 약을 시험할 때 위약을 먹은 집단을 반드시 같이 두는 것과 같은 구조예요.

문서가 든 예시 표를 보면 한 사례가 켜고 1.00, 끄고 0.33, Δ 가 +0.67 이고 실행 횟수는 6 회예요. 사례 하나에 여섯 번이 도는 셈이고, 열 사례면 예순 번이에요. 실행 하나하나가 계정에 청구되는 진짜 모델 호출이라는 점이 이 도구를 쓰는 쪽의 첫 제약이에요. 앤스로픽도 문서 맨 앞에 그 사실을 못 박아 뒀고, 비용 상한을 달러로 걸어 두는 옵션과 대조군을 끄는 옵션을 함께 뒀어요. 대조군을 끄면 비용이 절반으로 줄지만 Δ 도 사라져요.

채점기는 여섯 종류예요. 정규식으로 답이나 파일 내용을 훑는 것, 특정 도구가 몇 번 불렸는지 세는 것, 두 도구의 호출 순서를 보는 것, 파일이 만들어졌는지 확인하는 것까지 네 종류는 작업 기록과 파일만 읽어서 판정하니 추가 비용이 없어요. 나머지 두 종류는 심판 모델을 불러요. 그중 llm 채점기는 세 표 가운데 두 표 이상이 통과로 나와야 통과예요. 직접 코드를 짜서 끼우는 채점기는 없어요.

앤스로픽이 문서에 적어 둔 첫 결과 예측이 재미있어요. 처음 돌려 보면 Δ 가 0 근처인데 스킬이 불렸는지 보는 채점기가 실패하는 경우가 가장 흔하다고 해요. 사람이 자연스럽게 쓴 문장에서는 클로드가 그 스킬을 고르지 않는다는 뜻이고, 해법은 본문을 고치는 게 아니라 스킬 설명문을 고치는 거예요. 메탈은 에이전트 스킬에서 지식보다 절차가 성능을 갈랐다는 연구를 보도한 바 있으며, 이번 도구는 그 절차가 애초에 불리는지부터 재게 해 줘요.

대조군을 정직하게 만들려고 앤스로픽은 채점에서 일부러 빼는 항목도 뒀어요. 스킬이 불렸는지 보는 채점기는 플러그인이 없으면 절대 통과할 수 없으니, 그대로 세면 끈 쪽 점수가 0 으로 밀리고 Δ 가 부풀어요. 그래서 이 항목은 두 쪽 모두에서 점수에서 빼고 켠 쪽에만 통과·실패 표시로 남겨요. 만든 사람이 직접 with-only 로 표시한 채점기도 같게 처리돼요. 평가 도구가 자기에게 유리한 숫자를 만들지 않도록 설계 단계에서 손을 묶어 둔 셈이에요.

실행 환경은 생각보다 훨씬 비어 있어요. 실행마다 일회용 홈 디렉터리와 작업 디렉터리, 클로드 코드 설정이 새로 생기고, 사용자 설정과 훅, CLAUDE.md, MCP 서버, 다른 플러그인, 메모리, 스킬이 전부 없는 상태로 시작해요. 셸 환경 변수도 대부분 차단되고 허용 목록과 EVAL_ 로 시작하는 변수만 들어가요. 아티팩트 도구는 꺼져 있고, 시험 문제 정의 자체도 에이전트가 읽을 수 없어요. 주방을 통째로 비우고 이번 요리에 쓸 재료만 놓아 주는 것과 비슷해요.

권한 설계도 엔지니어가 먼저 볼 대목이에요. 실행은 허락을 묻느라 멈추지 않아요. 그래서 Bash·Write·Edit·WebFetch·WebSearch 처럼 손이 큰 도구는 허가하지 않으면 세션에서 아예 빠져 클로드가 부를 수조차 없어요. 사례가 요청했는데 내가 허가하지 않은 도구는 표준 오류로 not granted 라고 찍혀요. MCP 서버는 기본적으로 실제로 띄우지 않고, 서버별 폴더에 도구 하나당 마크다운 한 장으로 가짜 응답을 둬요. 그 파일에 기대하는 입력을 적어 두면 플러그인이 엉뚱한 값을 보낸 순간 실행이 0 점으로 중단되고 이유가 기록돼요.

CI 에 걸 때는 통과선을 1.0 에서 내리고 모델과 심판 모델을 둘 다 고정하라고 문서가 권해요. 모델이 바뀐 것을 플러그인이 나빠진 것으로 착각하지 않으려는 거예요. 종료 코드도 갈라 놨어요. 0 은 전부 통과, 1 은 통과선 미달이나 사례 로드 실패, 2 는 비용 상한에 닿았거나 인증이 거부된 부분 실행, 130 은 중단, 143 은 CI 시간 초과 같은 강제 종료예요. 리포트를 쓰거나 올리다 실패한 것은 종료 코드를 바꾸지 않아요.

결과는 자체 완결형 HTML 한 장으로 남아요. 외부 요청을 하나도 하지 않아서 CI 산출물로 붙이거나 디스크에서 바로 열 수 있고, 맨 위에는 플러그인 효과가 기준선보다 몇 점 올랐고 몇 사례가 좋아졌으며 몇 사례가 나빠졌는지가 한 문장으로 찍혀요. Δ 가 음수인 사례는 왼쪽 테두리가 빨갛게 표시돼서 스크롤만 해도 눈에 걸려요. claude.ai 구독으로 로그인해 있으면 같은 리포트가 비공개 아티팩트로 올라가고 주소가 함께 출력돼요.

앤스로픽은 이 도구가 재지 못하는 것도 문서에 적어 뒀어요. 실행을 격리하는 장치는 시험 대상 에이전트가 닿을 수 있는 범위를 좁히는 것이지 플러그인 자기 코드를 막는 울타리는 아니고, 시험을 통과했다는 사실이 그 플러그인이 안전하다는 말은 아니라고 했어요. 심판 모델을 먼저 의심하라는 조언도 있어요. 스킬이 불렸는데 Δ 가 음수면 플러그인보다 작은 심판 모델이 형식이 다른 정답을 오판한 쪽을 먼저 보라는 거예요. 재는 장치와 재는 대상이 같은 모델 계열이라는 점은 이 방식이 안고 가는 값이에요.

문제 해결 항목에는 통제권이 어디 있는지도 그대로 적혀 있어요. 명령이 사용할 수 없다는 메시지가 뜨면 앤스로픽이 서버 쪽에서 이 기능을 껐다는 뜻이고, 내 컴퓨터에서 그것을 되살릴 방법은 없다고 문서가 밝혔어요. 통과선을 CI 에 걸어 두는 팀이라면 재는 장치 자체가 회사 쪽 스위치에 달려 있다는 사실을 계산에 넣어야 해요.

메탈이 확인한 문서에는 동시 실행을 1 에서 8 까지 올릴 수 있다는 항목이 있는데, 이것도 계정의 속도 제한을 함께 쓰기 때문에 처리량이 늘지는 않고 벽시계 시간만 줄어든다고 명시돼 있어요. 플러그인 하나를 CI 에 걸어 두려면 비용과 시간을 미리 계산해 두어야 한다는 뜻이에요. 메탈은 팀 설정을 플러그인 하나로 묶어 배포하는 흐름을 다룬 바 있는데, 그렇게 배포한 묶음이 실제로 값을 하는지는 지금까지 감으로만 알 수 있었어요.

플러그인 생태계는 이 명령으로 한 단계 성숙해요. 만든 사람이 자기 점수를 자랑하던 자리에 끄고 돌린 점수가 나란히 붙으면, 설명문만 화려한 스킬과 실제로 결과를 바꾸는 스킬이 갈라져요. 앤스로픽이 문서에서 먼저 예고한 결과가 Δ 0 이라는 사실이 그 방향을 말해 줘요. 지금 배포된 플러그인 상당수는 있어도 되고 없어도 되는 것들이고, 이제 그 사실을 만든 사람이 먼저 알게 돼요.