주요 결정과 시행착오
이유가 기록된 설계 결정과 평가 결과
평가 수치를 읽는 법
아래 모델 평가 수치는 평가 담당 장민석의 러너·게이트 산출물입니다. 류준이 잰 값이 아닙니다. 측정은 2026-09-16 기준 Core advisor 22문항, evaluator 14케이스, NPC 대화 20케이스 × 2반복입니다. 표본이 매우 작고(n=1~3), 「비열등」은 통계 검정이 아니라 역할별 게이트를 비교하는 운영 규칙이며, PCA 는 주성분분석이 아니라 「기대 방향 일치율」입니다.
| 축 | 로컬 기준 | Anthropic 후보 결과 |
|---|---|---|
| Core 채점 일관성(PCA) · evaluator 기대 일치 | gemma4:12b — 0.90 · 0.57 | Sonnet n=1 0.90 · 0.71, n=3 0.9667 · 0.7143 — 통과 |
| Core 지연 | advisor p50 2,918ms / p95 4,231ms | Sonnet 은 n=1 과 n=3 사이에서 게이트가 뒤집힘. Opus 는 둘 다 미달 |
| Core 완주(5회차 self-play) | 완주 · 폴백 0/17 | Opus 완주 · 폴백 0. Sonnet 은 planner 5회 중 2회 재생성 + 1회 폴백 |
| NPC 구조 실패 | 41/41, 재생성 0 | 구조 실패 0. 재생성 0 게이트는 두 후보 모두 미충족 |
| NPC 7세 정책 | kanana 4/5 | kanana · Haiku · Sonnet 모두 4/5. 누설은 이 러너 범위 밖(미측정) |
| 비용 | 모델 API 호출료 0 | 부분 추정 약 $1.06(실측 토큰 아님). 총 $10 미만인지는 확인 불가 |
전 게이트 통과가 아닙니다. 제출 구성은 위 예외를 알고 내린 팀의 결정입니다.
시행착오
1. 구조화 출력을 provider 가 강제해 주지 않는다. 5회차 self-play 에서 Sonnet 의 planner 가 beats 를 7개 냈는데 스키마 상한은 6이었습니다. Anthropic 구조화 출력에서 maxItems 가 강제되지 않는 어댑터 한계였고, 재생성 2회와 폴백 1회가 일어났습니다. 절단(truncation)을 하네스 쪽에 구현해 해결했습니다. 「모델이 스키마를 지킨다」를 전제로 두면 안 된다는 교훈입니다.
2. 작은 표본에서 게이트가 뒤집힌다. Core 지연 게이트가 n=1 과 n=3 사이에서 반대 결론을 냈습니다. 뒤집힌 사실을 지우지 않고 변동성으로 해석해 기록했고, 채택을 「전 게이트 통과」가 아닌 「예외를 알고 내린 결정」으로 남겼습니다.
3. 채점기가 파싱에 실패하면 모델이 억울하게 떨어진다. 7세 정책 검사에서 Haiku 가 미달했는데, 원인은 채점기의 파싱 실패였습니다. 채점기를 gemma4:12b(think off)로 통일해 다시 재측정하자 kanana · Haiku · Sonnet 모두 4/5 가 나왔습니다. 측정 도구를 먼저 의심해야 한다는 교훈입니다.
4. 로컬 모델로는 심사 기간을 감당할 수 없다. 문제는 성능이 아니라 서빙 현실이었습니다. GPU 1장에 Core·NPC 가 동거하고, 홈 회선·정전·재부팅이 곧 서비스 장애가 됩니다. 어댑터 패턴 덕분에 .env 두 줄로 외부 API 로 전환했고 로컬 구성은 롤백 경로로 유지했습니다.
5. 키 관리. API 키는 측정 당일에만 넣고 끝나면 즉시 제거하며, 제출일에 다시 넣는 운영 규칙을 두었습니다.