AI 모델 비교, 진짜 어려운 건 순위가 아니라 채점 기준이었다

세 모델한테 똑같은 과제를 주면 순위가 나올 줄 알았다. 이틀 동안 라운드를 세 번 돌렸는데, 정작 시간은 전부 채점표를 고치는 데 들어갔다.

AI 모델 성능 비교라고 하면 보통 점수표부터 떠올린다. 새 모델이 나올 때마다 무슨 벤치마크에서 몇 점, 어디서 1위 같은 소식이 쏟아지니까. 나도 그런 표를 보다가 문득 궁금해졌다. 저 점수가 내 일에도 그대로 적용될까? 그래서 직접 재보기로 했다. 결과부터 말하면 순위는 나왔는데, 그 순위를 믿을 수 있게 만드는 일이 훨씬 어려웠다.

$AI 모델 성능 비교를 위해 손으로 고친 채점표$ ▲ AI 모델 성능 비교를 위해 손으로 고친 채점표 (자체 제작 이미지)

1. 순위를 매기려다 채점표만 세 번 고쳤다

먼저 판을 설명해둔다. 모델은 세 개, 서로 다른 회사 것이다. 이 글에서는 그냥 A, B, C로 부르겠다. 어느 게 어디 건지 일부러 안 적는 이유는 간단한데, 이 글의 요지가 순위가 아니라서다. 그리고 각 라운드를 한 번씩만 돌렸으니 "A가 B보다 낫다" 같은 말을 할 근거 자체가 없다. 표본 1회짜리 관측이다.

애초 목적은 소박했다. 작업 종류별로 어느 모델을 쓸지 정하고 싶었을 뿐이다. 그런데 첫 라운드를 돌리고 점수를 보는 순간 알았다. 순위는 나왔는데 그 순위가 뭘 의미하는지 내가 설명을 못 하겠더라.

문제를 잘 냈다고 생각했는데, 문제가 아니라 채점이 문제였네..

그래서 라운드마다 채점표를 새로 썼다. 1라운드 채점표로 2라운드를 못 돌리고, 2라운드 채점표도 3라운드에서 구멍이 났다. 결국 이틀 동안 내가 한 일은 모델 비교가 아니라 채점표 세 번 고치기에 가까웠다. 그 과정이 생각보다 남는 게 많아서 적어둔다.

참고로 "그래서 어떤 도구를 쓰면 되냐"는 질문에 대한 답은 여기 없다. 그건 전에 노코드 AI 자동화 도구 3가지, 언제 뭘 쓰나에 따로 정리해뒀다. 이 글은 그 답을 만들기 위한 자를 어떻게 깎았는가에 대한 기록이다.

2. 1라운드, 셋 다 90점대라 잴 게 없었다

첫 과제는 무난하게 잡았다. 100줄쯤 되는 간단한 명령줄 프로그램(터미널에서 글자로 실행하는 작은 프로그램)을 맨바닥에서 만들게 하는 것. 세 모델에 완전히 똑같은 프롬프트를 주고, 중간에 내가 끼어들지 않고 끝까지 알아서 하게 뒀다.

채점은 그 세 모델이 서로를 채점하게 했다. 자기 결과물도 포함해서. 심판을 따로 살 여력이 없었으니까.

결과는 이랬다.

셋 다 90점대
1등과 3등 차이가 5.75점
순위는 채점자 셋이 만장일치

만장일치라니 깔끔해 보이지? 근데 이건 좋은 신호가 아니었다. 점수가 죄다 위쪽에 몰려 있으면 순위가 같아도 아무 정보가 없다. 90점과 84점 차이가 실력 차인지 채점자 기분 차인지 구분이 안 되니까.

여기서 예상 못 한 게 몇 개 튀어나왔다.

첫째, 자기 채점 편향의 방향이 모델마다 달랐다. 하나는 자기한테 동료 평가보다 4점을 더 줬고, 하나는 1.25점을 더 줬는데, 나머지 하나는 오히려 2.5점을 깎았다. 자기한테 후한 모델과 박한 모델이 따로 있더라. AI 심판이 자기 답을 편애하는 경향은 예전부터 지적돼온 현상이고, 답이 길수록 점수를 더 주는 편향도 같이 보고돼 있다. 그걸 남의 논문에서 읽는 것과 내 표에서 보는 건 느낌이 좀 다르더군.

둘째, 실제로 분량이 길수록 점수가 높았다. 문서 줄 수 순서와 문서 점수 순서가 완전히 일치했다. 코드도 마찬가지였고. 표본이 3개라 이걸 증거라고 부를 순 없지만, 아 이래서 다들 그 얘기를 하는구나 싶었다.

▲ 1라운드에서 세 모델 점수가 모두 90점대에 몰린 분포 (자체 제작 이미지)

3. 채점자 성향이 실력 차이보다 컸다

1라운드 표를 뜯어보다가 제일 뜨끔했던 숫자가 이거다.

채점자 세 명이 매긴 평균 점수의 차이가 3.0점이었다. 그런데 1등과 2등의 격차는 0.75점이었다. 누가 채점하느냐가 누가 잘했느냐보다 점수를 네 배쯤 더 흔들었다는 뜻이다. 이 상태에서 뽑은 1등은 그냥 채점자 운이다.

의견이 갈린 자리도 한 곳에 몰려 있었다. 실행하면 답이 딱 나오는 항목, 그러니까 기능이 도는가, 테스트가 통과하는가 같은 건 셋이 완전히 일치했다. 반면 코드 품질이나 문서 품질처럼 읽고 판단해야 하는 항목에서만 갈렸다. 합의도가 "기계가 잴 수 있는가"와 정확히 비례한 셈이다.

그리고 더 허탈한 게 하나 있었다. 총점 차이의 대부분이 판단력 차이가 아니라 절차에서 왔다. 측정이 안 된 항목을 어떻게 처리할지, 그러니까 그 항목을 빼고 평균을 낼지 만점 처리할지를 내가 미리 안 정해뒀다. 그러니까 채점자 셋이 각자 알아서 다르게 처리했고, 점수 차의 상당 부분이 거기서 생겼다. 실력 비교라고 부르기 민망했다.

채점표에 안 적어둔 건 채점자가 알아서 지어낸다. 사람이든 모델이든 똑같더라.

4. 2라운드, 쓰기 말고 읽기를 재니 73점이 벌어졌다

1라운드 진단은 이거였다. 이 과제는 코드 쓰기만 재고 코드 읽기를 하나도 안 쟀다. 빈 화면에서 시작하는 과제는 셋 다 잘한다. 실무에서 어려운 건 남이 짜놓은 걸 읽고 손대는 쪽인데.

그래서 정반대로 설계했다.

빈 화면 대신 이미 돌아가는 코드 400줄을 주고, 거기에 기능 하나를 추가하게 했다
그 코드에 버그 5개를 미리 심어뒀다
작업 지시서에는 서로 모순되는 문장 2개와 빈칸 3개를 일부러 넣었다

채점표도 갈아엎었다. 100점 중에 사람이 읽고 판단하는 구간을 8점까지 줄였다. 나머지 92점은 채점 스크립트가 자동으로 매기거나 미리 만들어둔 정답지와 대조만 하면 되게 했고. 아무것도 안 하고 제출하면 몇 점이 나오는지 기준선도 실측해뒀다. 6점이었다.

결과는 100점, 76점, 27점.

1라운드에서 5.75점이던 격차가 73점으로 벌어졌다. 읽기를 재기 시작하니까 열두 배 넘게 벌어진 것이다. 모델이 바뀐 게 아니라 자가 바뀌었을 뿐인데.

지시서가 모호할수록 점수가 올라간 모델

여기서 설계할 때 전혀 예상 못 한 게 하나 나왔다.

내 가설은 상식적이었다. 지시가 모호하면 성능이 떨어질 것이다. 그래서 명확한 지시서와 모호한 지시서 두 조건을 계단식으로 돌렸다. 그런데 한 모델이 정반대로 나왔다. 명확한 지시서에서 15점, 모호한 지시서에서 만점. 같은 모델, 같은 코드, 지시서만 다른데 이렇게 갈렸다.

이유는 그 모델이 자기 작업 메모에 친절하게 적어놨더라. 명확한 지시서를 받았을 때는 버그를 발견하고도 "이번 작업 범위 밖이라 건드리지 않았다"고 썼다. 모호한 지시서를 받았을 때는 "이 버그가 동작을 깨뜨리므로 함께 고쳤다"고 썼고.

정리하면 이렇다. 모순된 지시를 풀려면 코드를 깊이 읽을 수밖에 없다. 그렇게 이미 깊이 들어간 상태에서는 눈에 띈 버그를 "범위 밖"으로 밀어내지 않게 된다. 모호함이 정독을 강제했고, 정독이 발견으로 이어진 것이다.

이게 "지시는 구체적으로 쓰라"는 통념을 뒤집는 얘기는 아니다. 평소 작업이라면 나는 여전히 구체적으로 쓴다. 그건 클로드코드 프롬프트, 이것만 바꿔도 엉뚱한 결과가 줄어듭니다에 적어둔 그대로고. 다만 능력을 측정하려는 자리에서는 얘기가 다르다는 걸 알았다. 조건 하나로만 돌렸으면 죽었다 깨어나도 못 봤을 결과다.

5. 3라운드, 다 맞다고 채점하고 며칠 뒤에 틀린 걸 알았다

2라운드까지는 내가 만든 문제였다. 정답지가 있으니 채점이 편했지. 3라운드는 정답지가 없는 과제로 갔다.

과제는 내가 실제로 굴리고 있는 프로젝트를 진단하고 개선안을 쓰게 하는 것이었다. 읽기 전용, 시간 상한 있음. 어떤 프로젝트인지는 여기 안 적는다. 굳이 말하면 노트가 서로 엮인 개인 위키 같은 걸 몇 년째 손보며 쓰고 있는 정도로 해두자.

정답지가 없으니 채점 기준을 이렇게 짰다. "모델이 주장한 사실이 진짜인가"를 재기로. 각 모델에게 자기 주장을 검증할 수 있는 명령어를 같이 내게 하고, 채점자가 그 명령을 다시 돌려서 출력이 일치하는지 확인했다. 그럴듯하지 않나? 나도 그때는 꽤 괜찮은 설계라고 생각했다.

1차 채점 결과는 거짓 주장 0건, 상위 두 모델 실질 동률.

이 결론이 틀렸다.

며칠 뒤에 그 진단서 내용을 실제 코드에 반영하려고 수치 하나를 옮겨 적다가 이상한 걸 봤다. 계산 방법 자체가 틀려 있었다. 순위 상관을 구하면서 동점 처리를 자기 마음대로 해버려서, 정식으로 계산하면 음수인 값이 양수로 나와 있었다. 부호가 반대면 결론도 반대다.

더 있었다. 그 모델은 "표준 라이브러리로 교차 확인해도 같은 값이 나왔다"고 적어놨는데, 하지 않은 검증을 했다고 쓴 것이었다. 이어서 표에 적힌 항목 이름 두 개가 실제와 다른 것도 나왔다. 1차 채점은 표의 숫자만 대조하고 이름은 안 봤던 거지.

1차 채점의 구조적 결함은 딱 한 줄로 요약된다.

모델이 "이 명령으로 확인하세요"라고 준 명령을 그대로 돌려서 출력이 맞으면 참으로 처리했다. 그러면 모델이 쓴 방법 자체가 틀린 경우에 채점이 눈이 먼다.

재채점을 했다. "동률"은 사라지고 10점 넘는 차이가 났다. 그나마 다행이라 할 만한 건, 정정 5건 중 4건이 채점자 자신의 모델을 깎는 방향이었다는 것 정도.

이 라운드에서 제일 크게 배운 건 따로 있다. 진단서의 오류는 채점하다가 나온 게 아니라 그걸 실제로 써먹다가 나왔다. 숫자 하나를 실제 작업에 이식해보는 게, 아무리 정교하게 짠 검증 절차보다 빨랐다. 이건 엑셀 취합할 때 검산 단계를 꼭 넣는 것과 같은 얘기다. 전에 흩어진 엑셀 파일 취합해서 주간 보고서 만들 때도 결국 검산에서 다 걸렸었다.

▲ 3라운드 1차 채점과 재채점 결과 비교 (자체 제작 이미지)

6. 내가 낸 사고 세 개, 원인은 하나였다

모델 얘기만 하면 불공평하니까 내가 낸 사고도 적는다. 이틀 동안 세 번 크게 삽질했다.

하나. 과제 원본이 제출본으로 덮어써졌다. 모델에게 파일 작업을 시키는 실행 환경을 임시 폴더가 아니라 실제 작업 폴더에 지어놨다. 파일 권한이 있는 모델이 원본을 직접 고쳐버렸고, 나는 그걸 모른 채로 다음 조건 폴더를 만들었다. 프롬프트 12개가 통째로 오염됐다. 복구하고 다시 만들었지. 웃긴 건 "이런 건 임시 폴더에서 돌려라"가 내 작업 규칙 문서에 이미 적혀 있었다는 것이다ㅋㅋ 규칙이 없어서 난 사고가 아니라, 있는 규칙을 내가 어겨서 난 사고였다. 대량 파일 만지다 사고 친 게 이번이 처음도 아닌데 말이지.

둘. "이 버그는 절대 피해갈 수 없다"고 문서에 적어놨는데 셋 다 피해갔다. 정답 예시를 하나 만들어보고는 "이 경로 말고는 없다"고 일반화한 것이다. 실제로는 새로 만든 함수 안에서 국소적으로 우회하는 세 번째 길이 있었다. 표본 1개로 전체 주장을 한 셈. 채점표 만드는 사람이 이러면 안 되는데.

셋. 채점자만 아는 규칙으로 감점했다. 2라운드 첫 채점에서 세 모델이 전부 같은 점수로 나와서 변별이 0이었다. 이상해서 제출물 메모를 열어봤더니 버그 발견 수가 0개, 1개, 5개로 크게 갈려 있더라. 원인은 나였다. "동작을 깨는 버그 수정은 작업 범위 내로 본다"는 기준을 채점자용 문서에만 적고, 정작 모델에게 준 지시서에는 안 넣었다. 모델들은 통상적인 "요청 범위 밖은 안 건드린다"는 규범을 따랐을 뿐인데, 알 수도 없는 규칙으로 점수를 깎인 것이다.

이건 고치는 방향도 고민이었다. 지시서에 "버그가 있을 수 있다"고 쓰면 실험 자체가 오염된다. 그래서 지시서 말고 채점표를 고쳤다. 배점을 발견 점수와 수정 점수로 쪼개고, 고치지 않고 발견만 해도 만점이 되게 했다. 이건 좀 괜찮은 수습이었던 것 같다.

세 사고를 관통하는 원인은 하나였다.

내가 만든 걸 내가 검증하면서, "내가 한 방식"이 유일한 경로라고 가정했다.

조심하면 되니까 실제 폴더에 지어도 괜찮을 것, 내가 이 방법으로 통과시켰으니 이게 유일한 통과 경로일 것, 내가 기준을 아니까 상대도 알 것. 셋 다 같은 모양이다.

그리고 끝까지 못 벗어난 문제도 있다. 참가 모델이 서로를 채점하는 구조라 자기 것도 자기가 채점한다. 정정이 대부분 자기를 깎는 방향이었다고 해서 편향이 없다는 증거가 되진 않는다. 심판을 따로 둘 여력이 없어서 그냥 안고 갔다ㅠㅠ

7. 정리, 채점표에 남긴 다섯 줄

이틀 세 라운드로 얻은 실용적 결론은 "누가 1등"이 아니라 "채점표를 어떻게 짜야 순위에 의미가 생기는가"였다. 다음에 또 할 때 쓰려고 다섯 줄로 정리해뒀다.

실행하면 답이 나오는 항목은 사람이나 모델이 읽고 판단하게 두지 말고 스크립트로 자동 채점한다. 채점자 간 불일치가 구조적으로 사라진다.
판단이 필요한 구간은 최대한 좁힌다. 1라운드는 판단 구간이 40점이었고 불일치가 정확히 거기서 났다. 2라운드는 8점으로 줄였다.
절차 규칙(측정 안 된 항목 처리법 같은 것)은 제출물을 보기 전에 못박는다. 보고 나서 정하면 결과에 맞춰 규칙이 휜다.
과제가 쉬우면 아무리 정교한 채점표도 소용없다. 1라운드는 전원 90점대라 잴 게 없었다.
점수 차이가 채점자 편차보다 작으면 그건 동률이다. 억지로 순위를 매기지 않는다.

지금은 작업 종류별로 어느 모델을 쓸지 나름대로 정해서 쓰고 있다. 다만 그 판단의 근거는 "이 과제, 이 채점표에서는 이랬다"는 조건부 관측이지 일반적인 우열이 아니다. 이 구분을 놓치면 남의 벤치마크 점수를 그대로 믿는 거랑 다를 게 없어진다. 참고로 모델을 골라 쓰는 게 왜 돈 문제이기도 한지는 비용 아끼는 법 편에 따로 적어놨다.

솔직히 말하면 새 모델 나올 때마다 나오는 점수표를 보면 여전히 눈이 간다. 근데 직접 같은 조건으로 돌려보니까 세 모델의 차이가 훨씬 선명하게 잡히더라. 이 글에 수치로 적지는 않았지만 작업 속도랑 토큰 소모량까지 같은 판에서 비교가 됐다. 남이 만든 점수표를 읽는 것과 내 과제로 재보는 건 해상도가 다르다. 이게 제일 큰 수확이었다.

남은 고민도 있다. 모델은 계속 새로 나올 텐데, 나올 때마다 이걸 매번 할 수는 없다. 3라운드 돌리는 데만 이틀이 갔으니까. 전부 다시 돌리지 않으면서 새 모델을 판단할 방법을 어떻게 만들지는 아직 답을 못 찾았다. 짧은 회귀 세트 하나만 유지하는 쪽으로 생각 중인데 이것도 아직..

3줄 요약 - 세 모델에 같은 과제를 주고 3라운드를 돌렸는데, 시간의 대부분은 채점표를 세 번 고치는 데 들어갔다. - 쓰기만 재면 다 90점대라 변별이 안 됐고(격차 5.75점), 남의 코드 읽기를 재니 73점까지 벌어졌다. - 채점만으로는 품질을 다 못 잰다. 결과물의 숫자 하나를 실제 작업에 이식해보는 게 제일 빨리 오류를 잡았다.

모델 비교를 해볼까 말까 고민 중이라면, 순위표부터 만들지 말고 채점표부터 만들어보는 걸 권한다. 잘 알지도 못하면서 주절거린 것 같지만, 자를 먼저 깎아야 잰 값을 믿을 수 있더라. 화이팅!

이 글은 개인 실험 기록이고, 작성 시점(2026년 7월) 기준이다. 각 라운드를 한 번씩만 돌렸기 때문에 재현성 근거가 없고, 인용한 점수는 전부 "이 과제, 이 채점표에서"에 한정된 값이다. 특정 모델의 일반적 우열을 뜻하지 않는다. 모델 버전과 요금·성능은 수시로 바뀌니 판단 전에 각 회사 공식 문서를 확인하는 게 좋다.

참고한 공식 자료 - AI 심판의 자기 편애·장문 편향 등 알려진 편향: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (arXiv) - 실제 저장소 이슈로 코드 수정 능력을 재는 벤치마크: SWE-bench - 모델을 여러 축으로 나눠 재는 공개 평가 프레임워크: Stanford CRFM HELM - 사람 투표 기반 공개 모델 비교판: LMArena [⚠️UNVERIFIED, 도메인 변경 이력 있음. 발행 전 접속 확인 필요]

이 글은 정보 제공이 목적이고, 작성 시점 기준이다. 요금·기능·정책은 이후 바뀔 수 있으니 결제·설치 전 공식 페이지를 한 번 확인하는 게 좋다. 특정 제품 사용을 권유하거나 결과를 보장하지 않는다.