
평생 사용할 나만의 AI 벤치마크를 만들었다 — 차이가 난 것은 「지능」이 아니었다
요약
기존 공개 벤치마크의 한계를 극복하기 위해 개인화된 AI 성능 측정 방식을 설계하고 실험한 과정을 다룹니다. 모델 간의 지능 차이를 명확히 구분하기 위해 난이도(천장)를 높이는 방법과 채점 체계 구축에 대해 설명합니다.
핵심 포인트
- 공개 벤치마크의 한계를 극복하는 개인용 벤치마크 설계법
- 모델 간 차이를 식별하기 위한 태스크 난이도(Ceiling Effect) 조절의 중요성
- Claude, Gemini 등 최신 모델을 활용한 비교 실험 환경 구축
- 복잡한 태스크에서의 객관적 채점 및 검증 방법론

뷰티 업계 종사자이자 독학 초보자, 마리 앙투아네트 계열 엔지니어를 목표로 하고 있습니다!
이번에는 AI의 실력 차이를 공개 벤치마크 (Benchmark)로 알 수 없다면, 평생 사용할 나만의 벤치마크를 만들면 되잖아 👸🍰 입니다.
읽는 데 소요되는 예상 시간: 약 18~22분 (
결과만 보고 싶은 분은 제8장으로 건너뛰셔도 좋습니다 📊)
🧭 이런 분들께 추천합니다 (어디서부터 읽을지에 대한 안내 포함)
| 대상 | 추천 시작 지점 |
|---|---|
| 📊 모델의 실력 차이를 측정하는 방법을 알고 싶은 사람 | 제3장 (테스트 설계) |
| 🎮 결과만 보고 싶은 사람 | 제8장 (3개 모델의 성적) |
| 🧠 무엇이 차이를 만들었는지 궁금한 사람 | 제9장 (내려올 수 있는가) |
| 🔍 자작 테스트의 검증 방법을 알고 싶은 사람 | 제5장 (킥 테이블 대조) |
| 💎 자신의 현장에서 벤치마크를 만들고 싶은 사람 | 제12~13장 (자산화와 실무 응용) |
| 🙈 실험자의 실패담을 보고 싶은 사람 | 제11장 (이번에만 6번) |
📋 전제 조건 · 동작 확인 환경 (클릭하여 열기)
- 피험자: Claude Sonnet 5 / Claude Opus 5 (Claude Code · effort
Ultracode), Gemini 3.6 Flash High (Antigravity) - 채점기를 만든 측 (관제실): Claude Opus 5 + 필자 (역할 분담은 아래에 기재)
(※ 이해 상충의 가능성은 제12장에 명시) - 채점: Node.js 24 / Headless Chrome (DevTools Protocol) / 의존 패키지 없음
- OS: Windows 11 Home
- 소요 비용: 0엔 (Claude Pro + Google 구독 범위 내)
- 이전까지의 기사: 1엔 연구소 전편 · 후편
채점기 코드를 작성한 것은 Claude Opus 5입니다. 필자는 독학 초보자로, 혼자서 이것을 작성할 능력은 없습니다.
누가 무엇을 했는지에 대한 분담과 그로 인해 발생하는 이해 상충(Conflict of Interest)은 제12장에 솔직하게 적어 두었습니다 ⚖️
숫자의 정의 (만점 · 집계 규칙 · 비교 가능한 축)는 결과가 나오는 제8장 직전에 정리해 두었습니다 📏
1. 서론: 지난번의 결론이 아마 틀렸을지도 모른다 🔰
지난 기사에서 저는 이렇게 썼습니다.
Gemini 3.6 Flash가 Opus 5와 대등한 결과물을 만들어냈다.
그리고 그 이유를 다음과 같이 설명했습니다. 「태스크의 난이도가 AI의 능력 상한에 도달하지 못했다 (천장 효과, Ceiling Effect)」. 누구나 만점을 받을 수 있는 문제를 냈기 때문에 차이가 나지 않았던 것이 아닐까 하고 말이죠.
……그것, 확인해 보지 않으셨죠?
「천장 효과라고 생각한다」는 것은 가설일 뿐, 측정은 아닙니다. 정말 그렇다면, 천장을 높이면 차이가 나타나야 합니다. 나타나지 않는다면, 정말로 대등하다는 뜻이 됩니다.
2. 「IQ 비교」는 개인에게 너무나도 힘들었다 😭
천장을 높이기로 결정했지만, 개인이 하기에는 세 가지 허들이 있었습니다.
⚠️ ① 「천장」까지 난이도를 끌어올려야 한다
지난번의 1달러 툴 (후리가나 드롭이나 OGP 생성)은 AI에게 너무 쉬워서 모두가 100점이었습니다.
지능의 차이를 보려면, 복잡하고 어려운 태스크 (복잡한 게임 제작, 수학적 알고리즘, 수천 줄에 달하는 코드의 버그 수정 등)를 부여하여 AI를 일부러 고생시킬 필요가 있습니다.
⚠️ ② 「채점 (승패 판정)」이 어려워진다
지난번에는 「작동하는 웹 페이지가 나왔는가」로 판정할 수 있었습니다. 하지만 고도의 문제로 넘어가면——
- 코드는 작동하지만, 사실 잠재적인 버그가 있다
- 작동은 하지만, 처리 속도가 느리다
이런 것들을 객관적으로 채점하는 자동 테스트 (Automated Test)를 인간이 미리 만들어 두어야 할 필요가 생깁니다. 문제를 만드는 것보다 채점기를 만드는 것이 더 힘듭니다 (이것은 정말 그랬습니다. 제5장).
⚠️ ③ 토큰 비용 (지갑)이 늘어난다
어려운 문제로 AI가 장시간의 사고 (Deep Thinking)나 시행착오를 거치게 하면, Opus나 Pro 모델에서는 토큰 비용이 수천 엔에서 수만 엔 규모로 녹아내릴 가능성이 있습니다 😭
그리고——
그래서: 「같은 난제 게임을 힌트 없이 만들게 하기」로 결정했다
가볍게 천장을 탐색하는 방법으로 선택한 것이 **낙하물 퍼즐 (Falling Block Puzzle)**이었습니다. 이유는 난이도를 깔끔하게 3단계로 나눌 수 있기 때문입니다.
1. 【보통 레벨】 겉모습만 있는 낙하물 퍼즐 (모두가 만들 수 있음)
블록이 떨어지고, 옆으로 움직이며, 한 줄이 맞춰지면 사라진다.
👉 이것은 Sonnet도 Opus도 Gemini Flash도 모두 100점으로 만들 수 있습니다.
2. 【진심 레벨】 원작의 숨겨진 신의 규칙 (차이가 나기 시작함)
원작에는 사실 굉장히 복잡한 프로그램 메커니즘이 있습니다.
벽 차기 (SRS): 벽에 딱 붙어 있을 때 회전을 누르면, 벽을 차면서 회전하는 메커니즘
예를 들어 벽 차기는, 이런 「위치를 옮기는 양의 표」를 16행 분량으로 정확하게 가지고 있지 않으면 재현할 수 없습니다.
// 회전 전후(0→R 등)마다, 시도할 위치가 5패턴으로 정해져 있음
"0>1": [[0,0], [-1,0], [-1,+1], [0,-2], [-1,-2]],
"1>2": [[0,0], [+1,0], [+1,-1], [0,+2], [+1,+2]],
...
게다가 I 피스만은 별도의 표를 사용합니다. 모르면 절대로 작성할 수 없기 때문에, 지식의 유무가 그대로 드러납니다.
7-bag 알고리즘: 완전 랜덤이면 막대 블록이 전혀 오지 않아 막히기 때문에, 7종류를 한 세트로 묶어 셔플하여 배분하는 메커니즘
T-Spin 판정: T형 블록을 틈새에 회전시켜 끼워 넣는 고등 테크닉의 판정
👉 여기까지의 세세한 사양을 **「사양서 한 장으로 버그 없이 구현할 수 있는가」**를 시키면, 똑똑한 모델과 경량 모델 사이에서 차이가 나기 시작할 것입니다.
3. 【신 레벨】 자동으로 플레이하는 AI를 만들게 하기 (매우 어려움)
가장 차이가 크게 나는 것이 이것입니다. **「인간보다 잘하며, 영원히 플레이를 계속하는 오토 플레이어를 짜줘」**라고 지시를 내립니다.
똑똑한 AI: 고도의 평가 함수 (구멍을 만들지 않음·표면을 평평하게 유지함 계산)를 작성하여, 수천 라인을 자동으로 계속 지워나가는 신의 플레이어를 만듦
보통의 AI: 적당히 놓다가, 몇 분 만에 블록이 쌓여 게임 오버
단순한 퍼즐은 모두가 만들 수 있지만, 원작의 완전 재현이나 최강의 자동 플레이 기능 포함을 만들게 하면 진짜 차이가 나타날 것이라는—예측이었습니다.
요컨대 이 장에서는, 「어렵게 만들기」와 「채점할 수 있기」를 동시에 만족하는 과제를 선택하는 것이 전부입니다!
3. 테스트 설계: 3가지만 지킬 것 📐
적당히 어려운 문제를 내는 것은 의미가 없습니다. 지난번까지 세 번이나 숫자를 틀렸기 때문에, 이번에는 처음부터 측정 방법을 정했습니다.
① 숨겨진 테스트 방식
채점용 테스트를 먼저 작성하고, 피험자에게는 절대 보여주지 않는다.
이것은 지난번의 교훈 그 자체입니다. 어떤 라운드에서 AI가 작성한 코드는 자신의 유닛 테스트(Unit Test)는 모두 통과했지만, 실제로는 망가져 있었습니다. 이유는 단순했습니다. 2~3건의 작은 입력값만 주었기 때문입니다.
스스로 테스트를 작성하게 하면, AI는 자신이 통과할 수 있는 테스트를 작성합니다.
따라서 채점은 반드시 이쪽(작성자)의 테스트로 진행합니다. 피험자가 스스로 테스트를 작성하는 것은 자유입니다.
② 난이도 사다리
한 단계만 어렵게 하면 「둘 다 성공」 혹은 「둘 다 실패」로 끝나버립니다. 단계를 만들어, 몇 단계에서 무너지는지를 봅니다.
| 단계 | 과제 | 목적 |
|---|---|---|
| 1 | 플레이 가능한 낙하물 퍼즐 | 천장 효과(Ceiling Effect) 확인 (아마 모두 만점) |
| ... | 탐색 및 평가 함수 설계 | |
| 4 | 자동 플레이 AI (점수 최대화) | 전략 및 리스크 관리 |
③ 인간의 기지해(Known Solution)라는 척도
모델끼리 비교하는 것만으로는 「그래서, 그게 좋은 점이야?」를 알 수 없습니다.
그래서 채점 측에 인간이 생각한 유명한 알고리즘(Dellacherie의 평가 함수)을 구현해 두었습니다. 이를 통해 **「인간의 도달점 대비 어느 정도인가」**를 말할 수 있습니다.
🔰 「평가 함수」란 무엇인가? 왜 인간의 기지해가 필요한가? (클릭하여 열기)
평가 함수란, 「현재의 판면(Board)이 몇 점 정도 좋은가」를 숫자로 반환하는 함수를 말합니다.
자동 플레이 AI의 내부 구조는 대략 다음과 같습니다.
현재 피스를 놓을 수 있는 모든 위치를 시도 (10열 × 4방향 ≒ 40가지)
→ 각각 놓은 후의 판면을 평가 함수에 대입
→ 가장 점수가 높았던 놓기 방식을 선택
즉 AI의 똑똑함 ≒ 평가 함수의 설계입니다. 무엇을 「좋은 판면」으로 정의하느냐에 따라 강함이 결정됩니다.
Dellacherie의 평가 함수는 이 분야에서 유명한 인간이 만든 정답입니다 (El-Tetris의 해설에 원래의 6개 항목과 그 의미가 정리되어 있습니다). 다음과 같은 요소에 가중치를 두어 합산합니다.
| 보고 있는 것 | 직관적인 의미 |
|---|---|
| 착지한 높이 | 낮은 곳에 두고 싶어 함 |
| ... | 구멍의 수 |
| 뚜껑이 덮인 칸은 최악 (파내지 않으면 없앨 수 없음) | |
| 우물의 깊이 | 너무 깊은 홈은 위험 |
왜 이것을 배치했는가. 모델끼리 비교하기만 하면 "A는 B보다 우수하다"라고밖에 말할 수 없습니다. 인간의 기지해(known solution)를 나란히 배치하면, **"인간의 도달점에 닿아 있는가, 아니면 넘어서고 있는가"**를 말할 수 있습니다. 이번에는 이것이 결정적인 역할을 했습니다 (제6장).
4. 레벨 2의 내용: 알고 있는가를 측정한다 🎮
레벨 2에서 제시한 것은, 플레이해 본 사람이라면 알고 있는 "숨겨진 사양" 3가지입니다.
🔰 벽 차기 (SRS)・7-bag・T-Spin이란 무엇인가? (클릭하여 열기/닫기)
① 벽 차기 (SRS = Super Rotation System)
벽에 딱 붙어 있는 상태에서 회전 버튼을 누르면, 보통은 회전할 공간이 없어서 회전할 수 없습니다.
하지만 원작은 **"그럼 위치를 조금 옮겨서 회전시켜 주자"**라며 자동으로 위치를 보정합니다. 이것이 벽 차기입니다. 벽을 차면서 회전하는 것처럼 보이기 때문에 그렇게 불립니다.
문제는 옮기는 양이 고정되어 있지 않다는 점입니다. "어느 방향에서 어느 방향으로 회전하는가"의 조합마다 시도하는 순서가 5가지 패턴으로 정해져 있으며, 총 16행의 표로 구성됩니다. 게다가 I 피스만 별도의 표를 사용합니다.
② 7-bag
피스를 완전히 랜덤하게 배분하면, 막대(I)가 20회 연속으로 나오지 않는 것과 같은 일이 확률적으로 발생하여 플레이어가 불합리하게 막히게 됩니다.
그래서 7종류를 한 봉투(bag)에 넣어 셔플하고, 한 봉투를 다 쓰면 다음 봉투를 꺼내는 방식으로 배분합니다. 이렇게 하면 연속되는 7개에는 7종류가 반드시 한 번씩 들어가므로, "막대가 전혀 나오지 않는" 상황이 구조적으로 발생하지 않습니다.
③ T-Spin
T자 모양의 피스를 회전시키지 않으면 들어갈 수 없는 틈새에 비집어 넣는 고등 테크닉입니다. 성공하면 점수가 크게 뛰어오릅니다.
판정 기준은 다음과 같습니다.
직전 조작이 회전이고,
T 중심의 대각선 네 모서리 중 3개 이상이 채워져 있으면 → T-Spin
단, "정면 쪽"의 두 모서리가 모두 채워져 있지 않으면 → mini로 강등
여기에 예외가 하나 더 있습니다. 이것은 사양서에 적지 않고, "예외 조건이 하나 있으니 조사할 것"이라고만 적었습니다. 지식을 측정하는 부분이기 때문에 정답은 숨겨두었습니다.
채점은 "차분 테스트"로 수행한다
수기로 테스트 케이스를 40건 만드는 것이 아니라, 참조 구현(reference implementation)과의 차분 테스트 (differential testing) 방식을 택했습니다.
랜덤한 판면·피스·회전 상태를 수천 가지 생성
→ 참조 구현과 피험자의 구현 모두에 동일한 입력을 제공
→ 단 한 건이라도 답이 다르면 불합격. 틀린 판면을 출력
수기 방식보다 강력하며, 제가 실수할 리스크도 줄어듭니다.
🔰 "차분 테스트"란 무엇인가? 일반적인 테스트와 무엇이 다른가? (클릭하여 열기/닫기)
일반적인 유닛 테스트 (unit test)는 "이 입력이라면 이 답이 나와야 한다"를 인간이 한 건씩 작성합니다.
// 일반적인 테스트: 기대값을 인간이 준비함
expect(tryRotate(board1, 'T', 0, 3, 5, 1)).toEqual({ x: 4, y: 5, state: 1 });
여기에는 두 가지 약점이 있습니다.
- 인간이 생각할 수 있는 케이스만 테스트할 수 있음 (제3장의 "AI는 자신이 통과할 수 있는 테스트를 작성한다"와 동일한 문제)
- 기대값을 인간이 계산하므로, 그 부분에서 틀리면 테스트 자체가 틀림 ← 이번에 가장 우려했던 부분
**차분 테스트 (differential testing)**는 기대값을 작성하지 않습니다. 신뢰할 수 있는 구현(참조 구현)과 나란히 두고, 동일한 입력을 양쪽에 흘려보낸 뒤 답이 다르면 불합격 처리합니다.
랜덤한 입력 → ┬→ 참조 구현 → 답 A
└→ 피험자의 구현 → 답 B (A ≠ B 이면 불합격)
| 구분 | 수기 테스트 | 차분 테스트 |
|---|---|---|
| 기대값 | 인간이 작성 | 참조 구현이 출력 |
| 케이스 수 | 현실적으로 수십 건 | 수천 건을 자동 생성 (이번에는 3,415건) |
| 발견되는 버그 | 상정한 범위 내 | 상정하지 못했던 조합 |
| 약점 | 망라할 수 없음 | 참조 구현이 틀렸다면 전부 무의미 (다음 장에서 설명) |
컴파일러나 DB, 암호 라이브러리의 테스트에서 자주 사용되는 수법입니다. "정답을 쓰는 것"이 아니라 "정답을 가진 누군가와 대조하는 것" ——이기에 다음 제5장, 참조 구현 (Reference Implementation) 그 자체를 어떻게 신뢰할 것인가가 최대의 관문이 됩니다.
🔧 첫 번째 채점기는 고장 나 있었습니다 (클릭하여 열기)
조잡한 구현(벽 차기(Wall Kick) 없음·단순 난수·T-Spin 판정 없음)을 만들어 채점기에 통과시켰더니, 93.95점이 나왔습니다.
원인은 바로 알 수 있었습니다. 랜덤한 판면의 대부분은 벽 차기도 T-Spin도 관계가 없기 때문입니다. 그 자리에서 평범하게 돌릴 수 있는 케이스가 9할이었고, 평균을 내면 차이가 사라지고 있었습니다.
그래서 "벽 차기가 필요한 케이스"와 "T-Spin이 성립하는 케이스"만 별도로 집계하도록 했습니다.
| 구분 | 종합 | ★항목만 |
|---|---|---|
| 참조 구현 | 100 | 100 |
| 조잡한 구현 | 52.56 | 5.42 |
T-Spin이 성립하는 케이스도 2000건 중 19건밖에 나오지 않았기에, 판면의 구석을 의도적으로 채워 만들어내도록 하여 388건까지 늘렸습니다.
채점기는 만들고 나면 반드시 "떨어져야 할 것"으로 테스트한다. 만점만 나오는 것들로만 테스트해도, 고장 났는지 여부는 알 수 없습니다.
5. 자신의 답이 맞는지 어떻게 확인할 것인가 🔍
이 부분이 이번에 가장 두려웠던 지점입니다.
참조 구현의 킥(Kick) 표가 틀렸다면, 실험 전체가 무효가 됩니다. 게다가 까다로운 점은, 참조 구현을 그대로 피실험자인 척하게 하여 채점하면 반드시 100점이 나온다는 것입니다 (같은 코드이므로 당연합니다).
자기 검증은 "채점기가 고장 나지 않았음"만을 보증합니다.
그래서 3개 층(Layer)으로 확인했습니다. 층 1과 층 3은 관제실 (Claude Opus 5)이 검사 스크립트를 작성하여 자동으로 수행하고, 층 2만 필자가 직접 눈으로 확인했습니다. (분담 내용은 서두의 🤝에 적어두었습니다)
층 1: 표가 자기 자신과 모순되지 않는가
SRS의 킥은 "상태별 오프셋의 차이"로 정의됩니다. 여기서부터 반드시 성립하는 성질이 도출됩니다.
0→R
과 R→0
은 부호를 반전시킨 관계가 된다 (차이의 정의로부터 수학적으로 확정) - 우회전과 좌회전은 좌우 대칭이 된다
1칸이라도 잘못 입력하면 거의 확실하게 어느 한쪽이 망가집니다. 전체 16행을 검사 → 전부 통과.
층 2: 외부 사양과 대조하기
대조 대상은 이 분야의 1차 정보에 해당하는 두 곳입니다.
- SRS - Hard Drop Tetris Wiki — 벽 차기 표 그 자체
- T-Spin - Hard Drop Tetris Wiki / Spins - TETR.IO Wiki — mini의 승격 조건
그런데, 이 Wiki들은 자동 수집(Scraping)이 차단되었습니다 (403). 즉, AI 측에서는 읽을 수 없습니다. 이 부분만큼은 인간이 브라우저로 열어서 눈으로 직접 비교할 수밖에 없었습니다.
다만 전부 비교할 필요는 없습니다. 층 1에서 부호 반전이 보증되었으므로, JLSTZ는 2행만 확인하면 표 전체를 유도할 수 있습니다. 실제로 필자가 확인한 것은 I 피스의 3행뿐이었고, 30초 만에 끝났습니다.
층 3: 동작으로 확인하기
표가 맞더라도 코드가 틀려 있을 수 있으므로, 실제로 미끄러뜨려 보며 눈으로 확인합니다.
I 0>1의 4번째 킥 편차 dx=1 dy=-2
회전 전 회전 후
.......... ...o......
...
가로 방향의 I가 오른쪽으로 1, 위로 2만큼 어긋나서 세로가 되어 있습니다. 숫자를 읽지 않아도 "확실히 이렇게 차는 것이 맞다"라고 판단할 수 있습니다.
덧붙여 "그 킥이 정말로 사용될 수 있는가"도 조사했습니다. 랜덤 탐색에서는 29단이 도달하지 못했지만, 판면을 목표하여 구성하니 4건까지 줄었습니다 (전부 T 피스). SRS에서는 일부 킥이 다른 단에 흡수되어 사용되지 않는 것은 알려진 성질이므로, 표의 오류는 아닙니다.
📦 제5장 요약: 자체 제작한 정답을 검증하는 3개 층
| 층 | 수행 작업 | 방지하는 것 | 비용 |
|---|---|---|---|
| 층 1 | 데이터가 자기 자신과 모순되지 않는지 검사 (대칭성·부호 반전) | 오타·복사 실수 | 자동·순식간 |
| 층 2 | 외부의 1차 정보와 대조 | 데이터 자체의 오류 | 층 1 덕분에 30초 |
| 층 3 | 동작을 눈으로 확인 | 표는 맞지만 코드가 다른 경우 | 수 분 |
층 1을 수행하면 층 2가 급격히 줄어드는 것이 포인트입니다. "전부를 인력으로 대조"하는 것은 현실적이지 않으므로, 먼저 기계적으로 걸러낸 뒤 남은 몇 줄만 눈으로 확인합니다.
요컨대 이 단계에서는, 채점하는 측이야말로 자신을 의심하는 절차를 먼저 준비해 두는 것이 중요합니다!
6. ……하지만, 또다시 천장에 부딪혔습니다 🙈
여기가 본론입니다. ……인데, 초기 설계는 실패했습니다.
처음 제시한 과제(레벨 3)는 너무 쉬웠다
Sonnet 5에게 실행시킨 결과, 다음과 같이 되었습니다.
| 라인 수 | 테트리스율 |
|---|---|
| 인간의 기지해 (Known Solution) | 398 |
| ... | |
| 상한선 400에 대해 398. 인간의 기지해와 동점입니다. 이보다 더 좋은 점수가 존재하지 않기 때문에, Opus 5도 Gemini도 최고 점수가 동점에 그칠 뿐입니다. 차이가 나지 않습니다. |
그리고 진단을 통해 더 결정적인 것이 나왔습니다. 테트리스율 0.000. 둘 다 4행 동시 제거를 단 한 번도 하지 않았습니다.
이유는 명확합니다. 제 지시가 잘못되었기 때문입니다. "라인 수를 최대화하라"는 지시를 받으면, 한 줄씩 야금야금 지우며 살아남는 것이 최적해입니다. 홈을 파고 긴 막대(I-piece)를 기다릴 필요가 없습니다.
천장을 높였다고 생각했지만, 또다시 "누구나 만점을 받을 수 있는 문제"를 내고 있었습니다.
수정할 전망은 있었습니다
목적만 바꿉니다. 최대화하는 것은 스코어 (Score) 입니다.
| 한 번에 제거한 행 수 | 점수 |
|---|---|
| 1행 | 100 |
| ... | 4행 (동시 제거) |
여기에 4행 제거를 연속으로 성공하면 2회차부터는 1.5배 (1200점)를 부여합니다.
이 스코어 표로 다시 계산해 보면 풍경이 달라집니다.
현상태 (한 줄씩 지우며 살아남는 방식) → 약 45,800점
이론치 (4행 제거만 계속하는 방식) → 약 120,000점 ← 2.6배의 성장 잠재력
여기에 도달하려면 "홈을 파고, 긴 막대를 기다리며, 그동안 계속 참는 것" = 눈앞의 제거를 참으며 리스크를 감수하고, 큰 보상을 노리는 판단이 필요합니다. 생존 능력과는 별개의 문제이므로, 여기라면 차이가 날 것입니다.
레벨 4 (스코어 최대화)를 신설. 여기가 진정한 기울기 (Gradient)가 됩니다.
7. 측정하고 싶은 능력 옆에, 측정할 수 없는 작업을 두지 마라 🎨
설계에서 한 가지 더 결정한 것이 있습니다. 그래픽에는 일절 요구 사항을 내지 않는다.
이유는 "채점할 수 없기 때문"만은 아닙니다. 다른 결과들을 오염시키기 때문입니다.
그렇다고 해서 "외형을 만들지 마라"고 금지하면 그것대로 부자연스럽습니다. 그래서 사양서에는 "외형은 자유입니다"라고만 적었습니다.
공을 들여도 좋지만, 요구하지는 않는다. 이 상태가 딱 적당하다고 생각합니다.
(이 판단, 지난번까지의 '1엔 랩(1-yen lab)'에서는 전혀 이루어지지 않았습니다. "1달러 벌기"라는 목적 안에 능력과는 무관한 작업(계정 생성, UI 조작)이 대량으로 섞여 있었던 것이 근본적인 문제였으니까요.)
8. 결과: 3체의 성적 📊
📏 먼저, 숫자의 정의 (모두 여기에 집약했습니다)
점수가 여러 종류로 나오기 때문에, 무엇을 어떻게 측정했는지를 여기에 정리합니다. 개별 근거는 각 장에 있지만, 정의는 여기가 유일한 정답입니다.
① 레벨별 만점과 의미
| 레벨 | 측정 대상 | 만점 | 채점 방법 |
|---|---|---|---|
| 1 | 동작하는 결과물을 낼 수 있는가 | 4/4 | Headless Chrome으로 4개 항목을 기계적 체크 |
| 2 | 숨겨진 사양의 재현 정밀도 | 100 | 참조 구현(Reference Implementation)과의 차이 테스트 (동일 입력 시 답이 하나라도 다르면 감점) |
| 3 | 탐색 및 평가 함수 설계 | 상한 400 | 1게임 1000피스에서 종료했을 때 제거한 라인 수 |
| 4 | 전략 및 리스크 관리 | 상한 약 120,000 | 동일 조건에서의 스코어 (1행 100 / 2행 300 / 3행 500 / 4행 800, 4행 연속은 1.5배) |
② 레벨 4의 집계 규칙
- **동일한 15개의 시드 (Seed)**를 3체 모두에게 부여했습니다 (피스 배열은 완전히 동일) -
- 중앙값 (Median): 15게임을 점수 순으로 나열했을 때의 중간값. 평균 (Mean): 15게임의 단순 평균 -
- 생존: 15게임 중, 쌓이지 않고 1000피스 종료 시점까지 도달한 횟수 -
- 테트리스율: 제거 1회당 "4행 동시 제거"가 차지하는 비율 (0.000 이라면 한 번도 하지 않음) -
- 쌓여서 더 이상 놓을 수 없는 시점에서 종료. 해당 회차의 남은 점수는 0점으로 처리하여 평균에 포함됩니다.
③ 비교해도 되는 축 / 비교하면 안 되는 축
- ⭕
동일 환경의 Sonnet 5와 Opus 5의 비교— Claude Code끼리이므로 완전히 클린함 - ⚠️
Gemini와의 비교— 하네스(Harness)가 Antigravity로 다릅니다. 결과 숫자는 비교할 수 있지만, 「모델의 차이」라고 단정 지을 수는 없습니다.
④ 이 글에서 측정하지 않은 것 (솔직하게)
- 소요 시간: 스톱워치로 측정하지 않았습니다. 아래의 「Sonnet이 느리다/Gemini가 폭속이다」는 체감입니다.
- 토큰 소비량: 측정하지 않았습니다 (구독 범위 내이므로 엔화 환산도 하지 않았습니다).
- 통계적 유의성: 모델 3개·문제 1종류·15개 시드(Seed)로는, 검정력(Statistical power)이 전혀 부족합니다.

같은 과제·같은 채점기·같은 15개 시드. 갈린 것은 마지막 한 단계뿐
전원 만점 🤝
레벨 1~3: | 레벨 1 | 레벨 2 | 레벨 3 (상한 400) | 레벨 3 생존율 |
|---|---|---|---|
| Sonnet 5 | 4/4 | 100 | 398 | 15/15 |
| Opus 5 | 4/4 | 100 | 398 | 15/15 |
| Gemini 3.6 Flash | 4/4 | 100 | 399 | 14/15 |
SRS 벽차기(Wall kick)도, 7-bag도, T-Spin 승급 조건도, 3개 모델 모두 완벽했습니다. 차분 테스트(Differential test) 3,415건 중 불일치가 단 1건도 없습니다.
레벨 3의 중앙값은 **Gemini가 톱(399)**입니다. 다만 15회 중 1회, 쌓이다가 종료(사망)했습니다. Claude 2개 모델은 한 번도 죽지 않았습니다. 이 시점에서 이미, 나중에 영향을 미칠 차이가 모습을 드러내고 있습니다 (제9장).
지식에서는 차이가 나지 않았습니다. 이는 지난번의 「호각」이 어떤 의미에서는 맞았음을 의미합니다.
레벨 4: 여기서 갈라짐 💥
| 스코어 중앙값 | 평균 | 생존 | 테트리스율 |
|---|---|---|---|
| 인간의 기지해(Known solution) | 45,800 | 45,780 | 15/15 |
| Sonnet 5 | 45,300 | 45,513 | 15/15 |
| Gemini 3.6 Flash | 56,300 | 46,746 | 6/15 |
| Opus 5 | 102,800 | 103,833 | 15/15 |
| 상한 | 약 120,000 | — | — |
Opus 5가 이론적 상한의 86%까지 도달했습니다. 게임당 84~88회의 4줄 동시 제거를 성공시키며, 15회 모두 단 한 번도 죽지 않았습니다.
Sonnet 5는 45,300점. 홈을 파는 전략은 구현했으나, 4줄 제거는 게임당 1~5회 정도에 그쳐 스코어는 인간의 기지해와 거의 비슷했습니다. 시도는 했으나 도달하지 못한 형태입니다.
⏱️ 시간에 관한 이야기 (체감입니다)
숫자를 측정하지 않았기에 체감상의 이야기입니다만, 적어두고 싶은 것이 있습니다.
Sonnet 5가 무서울 정도로 시간이 걸렸습니다. 그리고 Gemini는 폭속(爆速)입니다.
그 점을 고려하면, 정말 Flash인데도 대단하다고 생각합니다. 지난번 글에서 「Flash가 최중량급과 호각」이라고 썼을 때는 과제가 너무 쉬웠던 게 아닌가 의심스러웠지만, 이번 난이도에서도 레벨 1~3 만점 (레벨 3 중앙값은 399로 3개 모델 중 톱)이므로, 속도와 정밀도를 양립하고 있는 것은 진짜였습니다.
(※ 단, 그 399점도 15회 중 1회는 죽은 뒤의 중앙값입니다. 이 글은 마지막까지 이 점에 발목을 잡히게 됩니다.)
(※ 단, 시간은 측정하지 않았습니다. 제0장의 📏정의에 썼듯이 이것은 체감입니다. 게다가 Gemini만 하네스가 다르기 때문에, 모델이 빠른 것인지 Antigravity가 빠른 것인지도 분리할 수 없습니다.)
9. Gemini의 「중앙값」에 속을 뻔한 이야기 🎭
그리고 Gemini 3.6 Flash입니다.
중앙값 56,300점. Sonnet 5(45,300점)보다 높습니다.
……라고 쓰고 싶지만, 평균을 봐주세요. 46,746점. Sonnet과 거의 비슷해집니다.
🔰 중앙값과 평균이 어긋난다는 것은 무슨 의미인가? (클릭하여 열기)
평균 (Average): 모든 값을 더해 개수로 나눈 값. 이상치 (Outlier, 극단적인 값)에 의해 수치가 왜곡됩니다.
중앙값 (Median): 작은 순서대로 나열했을 때 정확히 중간에 위치한 값. 이상치에 강합니다.
예를 들어 5명의 점수가 0, 0, 60, 61, 62
였다면——
| 지표 | 값 | 의미 |
|---|---|---|
| 중앙값 | 60 | "잘 풀렸을 때는 60점을 얻을 수 있다" |
| 평균 | 36.6 | "전체적으로 보면 36.6점" |
둘 다 올바르게 계산되었습니다. 단지 바라보는 관점이 다를 뿐입니다.
그리고 중앙값은 보통 "우연히 실패한 회차 때문에 수치가 깎이고 싶지 않을" 때 선택합니다. 이번에도 그런 의도로 선택했습니다.
……하지만, 그것이 함정이었습니다.
중앙값과 평균이 어긋날 때는, 그 중간에서 무언가가 일어나고 있습니다. 여기서는 사망률이었습니다.
15회 중 9회, 쌓여서 게임 오버
생존한 게임에서는 28~43회의 테트리스를 수행하고 있습니다. 전략은 구현되어 있고, 지식도 만점입니다. 하지만 절반 이상의 게임에서, 쌓여서 죽고 있습니다.
무엇이 달랐는가
3개의 코드를 읽고 비교해 보니, 명확한 차이점이 하나 있었습니다.
Opus 5만이 "재정비 모드 (Recovery Mode)"를 가지고 있었습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기