03. 브라우저 디펜스 게임 대회

1. 한 줄 요약

같은 지시문으로 로컬 LLM 15종이 각자 브라우저용 디펜스 게임을 만들고, 자동 실행 시험과 블라인드 심사로 1000점 만점 채점하는 대회입니다. 01 테트리스, 02 드래곤플라이트와 같은 틀(v1 / v2 / v3)이지만, 이번에는 조건을 최소로 줄였습니다.

• 참가 모델 15종의 제원은 00_model_info 에 있습니다.
• 모든 모델은 같은 서버에서, 같은 에이전트 도구로, 같은 지시문을 받고, 한 번에 하나씩 순서대로 일합니다.
• 앞의 두 시험과 다른 점 셋: 게임의 규칙과 장르 해석을 모델에 맡겼고, 주어진 시간이 15분뿐이며, 인터넷 제한이 없습니다(2절의 비교표 참고).

2. 시험 의도와 라운드 개념 (v1 / v2 / v3)

시험 의도

앞의 두 시험은 지시문이 무엇을 만들지 꽤 자세히 정해 주었습니다(테트리스는 아타리판 재현, 드래곤플라이트는 규칙 목록). 이번 시험은 거의 반대입니다. 지시문은 「웹 브라우저에서 실행되는 디펜스 게임」이라는 한 줄뿐이고, 다음을 모두 모델에 맡깁니다.

• 어떤 디펜스 게임으로 만들지: 장르 해석, 규칙, 세계관, 화면 구성, 조작 방식.
• 기획과 디자인을 어떻게 진행할지: 혼자 할지, 기획자·디자이너·개발자 같은 페르소나를 정할지, 서브에이전트에게 역할을 나눠 줄지, 기획서나 디자인 문서를 남길지.

그리고 시간을 15분으로 줄였습니다. 앞의 두 시험은 60분 제한이었지만 실제 생성 시간은 대개 3~14분이었고 가장 오래 걸린 것이 약 33분이었습니다. 이번에는 부족한 시간 안에서 기획·디자인·개발을 얼마나, 어떤 순서로 진행하는지가 관찰 대상입니다. 지시문에 실제 시작 시각과 마감 시각을 적어 주고, 마감 순간 폴더에 있는 결과물로 평가합니다.

마지막으로 인터넷 제한을 풀었습니다. 웹 검색, 외부 라이브러리·이미지·소리, 런타임 CDN 사용을 허용하고, 가져온 것은 출처와 라이선스를 README 에 적게 합니다. 페르소나와 서브에이전트도 허용합니다.

앞의 두 시험과의 비교

앞의 두 시험도 셸에서의 네트워크 접근을 따로 막지는 않았지만 사용을 허용한 것은 아니었고, 두 시험의 네트워크 사용 감사(각 README 의 5절)에서 셸 접속과 외부 URL 요청은 여섯 라운드 모두 0건이었습니다. 03 은 이를 공식 허용으로 바꾸고 「관찰」로 집계합니다.

라운드

대회는 앞의 두 시험처럼 「라운드」로 이어집니다. 같은 모델이 같은 게임을 라운드마다 한 단계씩 발전시킵니다.

v3 는 보스전 하나만 제한합니다. 02 와 달리 크레딧·컨티뉴는 요구하지 않습니다.

v2·v3 의 규칙은 다음과 같습니다.

• 각 모델은 자기 직전 라운드 결과물만(v2 는 v1, v3 는 v2) 이어받습니다. 다른 모델의 결과물은 보지 못합니다.
• 공평성을 위해 이전 라운드 채점에서 나온 결함·피드백은 모델에게 알려 주지 않습니다. 모델은 무엇이 틀렸는지 모른 채 지시문만 받습니다.
• 모델마다 매번 새 세션을 시작하므로, 모델이 아는 것은 지시문과 폴더 안의 코드뿐입니다(이전 대화 기억 없음).
• 라운드마다 15분이 새로 주어집니다.

폴더 이름 규칙은 simple_llm_test_{모델약어}_defense_{버전} 입니다.

simple_llm_test_q36_defense_v1    # q36 모델의 v1 결과물
simple_llm_test_q36_defense_v2    # 위 폴더를 복사해서 터치 조작을 추가한 v2 결과물
simple_llm_test_q36_defense_v3    # v2 폴더를 복사해서 보스전을 추가한 v3 결과물

3. 지시문 원문

모델마다 지시문은 폴더 이름({alias} 자리에 모델 약어)과 시간 값만 다르고 나머지는 글자 하나까지 같습니다. 아래는 실제로 보낸 문장 그대로이고, 값이 들어가는 자리만 다음과 같이 적었습니다.

• 제한 시간은 15 입니다.
• 「시작」 뒤에는 실행 직전의 실제 시각이 들어갑니다(아래에서는 「(실행 직전 시각)」으로 표기).
• 「마감」 뒤에는 시작 시각 + 15분이 들어갑니다(아래에서는 「(시작 + 15분)」으로 표기).

세 라운드 모두 인터넷 사용, 외부 라이브러리·이미지·소리 사용, 페르소나와 서브에이전트가 「자유롭게 해도 되는 것」으로 적혀 있습니다. v1 에는 기획서·디자인 문서 같은 산출물을 폴더 안에 남겨도 된다는 문장이 더 들어 있습니다.

v1

현재 작업 폴더 이름은 simple_llm_test_{alias}_defense_v1 입니다. 이 폴더 안에 웹 브라우저에서 실행되는 디펜스 게임을 만들어 주세요.

어떤 디펜스 게임으로 만들지(장르 해석·규칙·세계관·화면 구성·조작 방식)와, 기획과 디자인을 어떻게 진행할지는 모두 맡깁니다.

시간 제한:
- 이 작업에 주어진 시간은 15분입니다. 시작 (실행 직전 시각), 마감 (시작 + 15분) 입니다. 터미널에서 date 명령으로 현재 시각을 확인할 수 있습니다.
- 마감 시각이 되면 작업이 강제로 끝나고, 그 순간 이 폴더에 있는 결과물로 평가합니다.

자유롭게 해도 되는 것:
- 인터넷 검색·자료 조사, 외부 라이브러리·이미지·소리 사용(가져온 것은 출처와 라이선스를 README.md 에 적어 주세요).
- 기획자·디자이너·개발자 같은 페르소나를 정하거나 서브에이전트(subagent)를 만들어 역할을 나눠 진행하기.
- 기획서·디자인 문서 같은 산출물을 남기고 싶다면 이 폴더 안에 두세요.

요구사항:
- index.html 파일을 브라우저로 열면 바로 실행되어야 합니다(별도 설치·빌드·서버 없이).
- 필요한 파일은 모두 이 폴더 안에 만들어 주세요.
- 게임 소개, 실행 방법, 조작법, 파일 구성을 정리한 README.md 도 이 폴더에 만들어 주세요.

완성되면 만든 파일 목록과 조작 방법을 짧게 정리해 주세요.

v2

현재 작업 폴더 이름은 simple_llm_test_{alias}_defense_v2 입니다. 이 폴더에는 앞서 만든 디펜스 게임이 있습니다. 모바일 기기에서도 플레이할 수 있도록 터치 조작을 추가하고 휴대폰 화면에 맞춰 주세요.

시간 제한:
- 이 작업에 주어진 시간은 15분입니다. 시작 (실행 직전 시각), 마감 (시작 + 15분) 입니다. 터미널에서 date 명령으로 현재 시각을 확인할 수 있습니다.
- 마감 시각이 되면 작업이 강제로 끝나고, 그 순간 이 폴더에 있는 결과물로 평가합니다.

자유롭게 해도 되는 것:
- 인터넷 검색·자료 조사, 외부 라이브러리·이미지·소리 사용(가져온 것은 출처와 라이선스를 README.md 에 적어 주세요).
- 페르소나를 정하거나 서브에이전트(subagent)를 만들어 역할을 나눠 진행하기.

요구사항:
- 기존 기능은 그대로 유지해 주세요.
- index.html 파일을 브라우저로 열면 바로 실행되어야 합니다(별도 설치·빌드·서버 없이).
- README.md 에 터치 조작 방법을 추가해 주세요.

완성되면 바꾼 파일 목록과 터치 조작 방법을 짧게 정리해 주세요.

v3

현재 작업 폴더 이름은 simple_llm_test_{alias}_defense_v3 입니다. 이 폴더에는 앞서 만든 디펜스 게임(터치 조작 포함)이 있습니다. 스테이지 4개마다 보스전이 열리도록 게임을 구성해 주세요(예: 4·8·12 스테이지가 보스전).

요구사항:
- 보스는 일반 적과 다른 체력과 행동 패턴을 가져야 합니다.
- 현재 스테이지와 보스전 여부를 화면에서 알 수 있어야 합니다.
- 기존 기능(키보드·마우스·터치 조작 포함)은 그대로 유지해 주세요.
- index.html 파일을 브라우저로 열면 바로 실행되어야 합니다(별도 설치·빌드·서버 없이).
- README.md 에 스테이지·보스 규칙을 추가해 주세요.

시간 제한:
- 이 작업에 주어진 시간은 15분입니다. 시작 (실행 직전 시각), 마감 (시작 + 15분) 입니다. 터미널에서 date 명령으로 현재 시각을 확인할 수 있습니다.
- 마감 시각이 되면 작업이 강제로 끝나고, 그 순간 이 폴더에 있는 결과물로 평가합니다.

자유롭게 해도 되는 것:
- 인터넷 검색·자료 조사, 외부 라이브러리·이미지·소리 사용(가져온 것은 출처와 라이선스를 README.md 에 적어 주세요).
- 페르소나를 정하거나 서브에이전트(subagent)를 만들어 역할을 나눠 진행하기.

완성되면 바꾼 파일 목록과 스테이지·보스 규칙을 짧게 정리해 주세요.

4. 실행 환경

앞의 두 시험과 같은 서버, 같은 엔진, 같은 에이전트입니다. 자세한 값은 01 테트리스 대회의 실행 환경을 보세요. 이번 시험에서 달라진 부분만 적습니다.

서버

• AMD Strix Halo 노트북 서버(Radeon 8060S, 64GB 통합 메모리). 모델 추론은 llama.cpp b11701 (Vulkan), router 모드이고 모델은 한 번에 하나만 올라갑니다.
• 모델마다 서버에 등록된 자기 프리셋(생각 모드, 샘플링 등)을 그대로 씁니다. 각 값은 모델 정보 에 있습니다.
• mel (Mellum 2.1) 만 llama.cpp b11539 로 돌리는 예외도 같습니다. b11701 에서는 Mellum 의 연산 하나가 GPU 에서 CPU 로 밀려 생성 속도가 4.7배 느려지기 때문입니다. 이유와 수치는 01 테트리스 대회의 같은 항목에 있습니다.

에이전트

• opencode v1.18.35 를 opencode run --auto --pure -m halo/{alias} 로 실행합니다. 모델마다 새 세션, 새 임시 홈 디렉터리에서 시작합니다.
• 권한: 파일 편집 허용, 셸 명령 허용, 웹 가져오기(webfetch) 허용. 앞의 두 시험에서는 webfetch 를 거부했습니다.
• 샌드박스(bubblewrap)의 파일 시스템 격리는 그대로입니다. 다른 모델의 폴더와 서버의 다른 파일은 보이지 않고, 쓸 수 있는 곳은 자기 프로젝트 폴더와 일회용 임시 홈뿐입니다. 달라진 것은 인터넷을 쓸 수 있다는 점입니다.
• 서브에이전트와 페르소나: 모델이 서브에이전트를 만들면 opencode 는 그 서브에이전트를 부모와 같은 모델로 실행합니다. 같은 샌드박스, 같은 시간 제한 안에서 돌고, 아래의 게이트웨이도 똑같이 지납니다.
• 시간 제한 15분: 마감이 되면 작업을 강제로 끝내고, 그 순간 폴더에 있는 결과물로 평가합니다.

모델 고정 게이트웨이 (원리)

인터넷을 열면 새로운 위험이 생깁니다. 샌드박스 안의 모델이 대회 서버(모델 서버)에 직접 접속해서 다른 모델을 요청하면, 진행 중인 실행을 방해하거나 다른 모델의 시간을 빼앗을 수 있습니다. 인터넷을 막는 대신 이 길만 막기 위해 다음과 같이 합니다.

• 샌드박스에는 진짜 API 키를 넣지 않습니다.
• 대신 실행마다 새로 만든 1회용 토큰을 줍니다. 이 토큰은 대회 서버 앞의 중간 게이트웨이에서만 유효합니다.
• 게이트웨이는 그 실행에 배정된 모델 하나의 요청만 서버로 전달하고, 다른 모델을 요청하면 거부합니다.
• 실행이 끝나면(정상 종료, 시간 초과, 강제 종료 모두) 토큰을 폐기합니다.

주소, 경로, 키 같은 구현 세부는 공개 문서에 적지 않습니다.

5. 공정성 장치

진행 순서: q36, cn, orn, mg, bolt, lfm, mcv, q38, aw, fn, ff, c7, c7r, c1, mel (mel 은 엔진을 바꿔야 해서 맨 마지막). 앞의 두 시험과 같은 순서입니다.

6. 진행 순서 (파이프라인)

모델 한 개당 다음 단계를 거치고, 15종 모두 같은 절차를 반복합니다.

 [폴더 준비]  v1: 빈 폴더 생성 / v2: 자기 v1 폴더를 복사 / v3: 자기 v2 폴더를 복사
      |
      v
 [샌드박스 에이전트 실행]  opencode + 지시문 (15분, 게이트웨이 경유, 인터넷·서브에이전트 허용)
      |
      v
 [서버 로그 집계]  소요 시간, 요청 수, 입력/생성 토큰, 생성 속도,
      |            최대 컨텍스트 길이, 컨텍스트 잘림 여부, 시간 초과 여부
      v
 [네트워크 사용 관찰 기록]  무엇을 내려받았나, 결과물에 들어갔나
      |
      v
 [자동 시험]  헤드리스 Chrome: 데스크톱(모든 라운드), 모바일(v2·v3), 보스전(v3)
      |
      v
 [냉각 1분]  --> 다음 모델
      :
      v
 [블라인드 심사]  결과물에 익명 이름 A~O --> 점수 --> 이름 공개 --> 순위

서버 로그 집계: 에이전트가 끝나면 그 시간 동안의 서버 로그에서 해당 모델 몫만 뽑아 요청 수, 읽은 토큰(프롬프트), 생성한 토큰, 생성 속도(t/s), 최대 컨텍스트 길이, 컨텍스트 초과로 잘린 횟수를 계산하고 결과 폴더의 파일 목록과 크기도 기록합니다. 이번에는 15분 안에 끝났는지, 시간 초과로 강제 종료됐는지도 함께 기록합니다.

자동 시험: 이번 시험은 장르가 열려 있어 모델마다 규칙이 다릅니다. 그래서 시험은 「입력에 화면이 바뀌었나」가 아니라 결과 상태(적 체력 감소·제거, 자원 증감, 기지 체력, 웨이브 번호)를 읽습니다. CDN 사용을 허용했으므로 온라인 상태에서 실행합니다. 시험은 데스크톱(모든 라운드), 모바일 터치(v2·v3), 보스전(v3) 세 가지이고, 시작 경로(키·클릭·탭)를 각각 새 페이지에서 따로 시험합니다. 확인하지 못한 항목은 「없음」이 아니라 「확인 불가」로 기록해, 시험이 보지 못한 것과 게임에 없는 것을 구분합니다. 자동 시험은 사람 심사를 돕는 근거 자료이고 최종 판단은 스크린샷과 코드를 직접 보고 합니다.

7. 채점

1000점 루브릭

그래픽과 재미의 최종 판단은 사람이 하고, 여기 점수는 실측 기능 + 설계 + 과정 + 코드입니다. 아래 표는 v1 기준이고, 라운드별로 영역 1·2(500점)만 바뀝니다.

영역 1·2 — 라운드별 과제 (500점)

영역 3~6(코드와 문서)은 그 라운드 시점의 전체 코드와 문서에 같은 기준을 적용합니다.

장르가 열려 있다는 원칙

이 시험에는 「정답 장르」가 없습니다. 타워 디펜스든 기지 방어든 심사자는 장르를 가정하지 않고, 모델이 스스로 정한 규칙이 일관되게 구현됐는가를 봅니다. 서로 다른 게임을 같은 잣대로 줄 세우기 때문에, 장르 사이의 재미나 완성도 비교는 점수 밖입니다.

판정 원칙 (앞의 두 시험에서 얻은 교훈)

• 「반응한다」는 「동작한다」가 아닙니다. 결과 상태(적 체력 감소·제거, 자원 증감, 기지 체력, 웨이브 번호)로 확인합니다.
• 실측 우선, 상태 주입 허용. 도달하는 데 오래 걸리는 상태(보스 스테이지 등)는 콘솔로 상태를 주입해도 됩니다. 대신 주입한 방법을 근거에 적습니다.
• 코드로만 확인한 항목은 배점의 70% 가 상한입니다. 다른 버그 때문에 플레이로 도달할 수 없는 상태를 주입으로만 확인했을 때도 같은 상한을 둡니다.
• 입구가 여럿이면 모두 시험합니다. 키, 클릭, 탭, 시작 경로마다 새 페이지에서 확인합니다.
• 같은 결함은 한 번만, 가장 구체적인 항목에서 깎습니다.
• 시간 초과로 강제 종료된 결과물도 똑같이 채점합니다. 4절(시간 관리)이 그 사실을 반영합니다.
• 인터넷·외부 에셋·CDN 사용 자체는 가점도 감점도 아닙니다. 출처 표기만 6절에서 봅니다. 외부 코드를 가져왔다면 직접 작성한 부분을 평가합니다.

채점 방법

• 블라인드 리뷰: 결과물에 익명 이름(A~O)을 붙여 채점하고, 채점이 끝난 뒤 모델 이름을 공개합니다. 리뷰어는 어느 모델이 만든 것인지 모른 채 채점합니다.
• 모든 감점·가점에는 근거(파일:줄 번호, 시험 단계, 주입한 상태)를 적어야 합니다. 근거 없는 감점은 금지입니다.
• 아무것도 만들지 못했거나 실행이 안 되면 빈 엔트리로 0점입니다.
• 영역별 담당 리뷰어와 평균 방식은 심사 때 정해지며, 각 결과 절에서 밝힙니다.

실용 순위

1000점 순위와 별도로, 600점 이상인 결과물만 모아 만드는 데 걸린 시간 순으로 나열한 「실용 순위」를 함께 냅니다. 이번에는 시간 제한이 있으므로, 결과 표에 「15분 안에 끝냈는가 / 시간 초과로 강제 종료됐는가」 열을 둘 예정입니다.

빨리 끝낸 것 자체는 점수가 아닙니다. 4절(시간 관리)은 마감 순간에 동작하는 상태였는지와 범위를 조절한 흔적을 봅니다. 속도는 1000점에 섞지 않고, 쓸 만한 품질(600점 이상)을 갖춘 모델 사이에서 얼마나 빨리 끝냈는지를 별도 순위로 보여 줍니다.

8. 진행 기록과 한계

• 시작과 종료: 2026-10-17 23:43 시작(02 종료 직후 자동). v1, v2, v3 순서로 한 라운드씩 진행했고 세 라운드가 모두 끝났습니다(결과는 9절).
• 준비 완료: 라운드 체인, 모델 고정 게이트웨이, 자동 시험 도구. 게이트웨이와 시험 도구는 가짜 서버와 대조군으로 검증을 마쳤습니다.
• 표본 수: 모델당 라운드당 1회만 실행합니다. 15분이라 우연의 영향이 크고, 같은 모델을 다시 돌리면 결과가 크게 달라질 수 있으므로 점수 차이가 작은 구간은 순위보다 경향으로 읽어야 합니다.
• 인터넷을 허용한 대가: 같은 모델이라도 검색 결과와 외부 서비스(CDN 등)의 상태에 따라 결과가 달라질 수 있어 재현성이 낮습니다. 시험은 온라인 상태에서 실행합니다.
• 장르가 서로 다른 게임을 비교합니다. 1000점은 「정해진 규칙이 일관되게 구현됐는가」를 재는 값이어서, 어느 게임이 더 재미있는지는 알려 주지 않습니다.
• 페르소나·서브에이전트: 쓰면 요청 수와 생성 토큰이 늘 수 있고, 쓰지 않은 모델과 단순 비교하기 어렵습니다. 어느 모델이 무엇을 썼는지는 기록 로그로 확인할 수 있을 때 결과 절에 적습니다.
• 자동 시험의 한계: 자동 시험은 사람 심사를 돕는 근거 자료입니다. 최종 판단은 스크린샷과 코드를 직접 보고 합니다.
• 사람이 직접 해 봐야 아는 부분: 그래픽, 재미, 조작감, 효과음, 휴대폰 실기 동작은 점수에 반영되지 않은 부분이 있습니다.

9. 결과 — v1

채점 방식: v1(처음부터 만들기)의 1000점은 세 갈래로 나눠 채점했습니다. 1 실행·플레이(300)와 2 디펜스 게임 설계(200), 4-1 마감 시점에 동작하는 상태(60)는 QA 리뷰어가 헤드리스 Chrome 에서 직접 실측했습니다(560점). 3-1 기획 산출물(40), 3-2 산출물과 구현의 일치(60), 4-2 범위 조절의 흔적(40), 5 코드 품질(200), 6 README·출처(50)는 코드·기획 리뷰어가 문서와 코드를 읽고 채점했습니다(390점). 3-3 시각 디자인의 일관성(50)은 진행자(PM)가 QA 의 장면 스크린샷과 메모를 보고 채점했습니다. 장르는 모델이 정하므로 심사자는 정답 장르를 가정하지 않고 모델이 스스로 정한 규칙이 일관되게 구현됐는가를 봤습니다. 결과물은 A~O 로 익명 처리(블라인드)해 채점했고, 채점이 끝난 뒤 모델 이름을 공개했습니다. 시간 초과로 강제 종료된 결과물은 마감 순간의 폴더 상태로 똑같이 채점했습니다.

품질 순위 (1000점)

열 머리의 1/300 은 「항목/만점」입니다. 1 실행·플레이, 2 디펜스 게임 설계, 3 기획·디자인(3-1 + 3-2 + 3-3, 150), 4 시간 관리(4-1 + 4-2, 100), 5 코드 품질, 6 README·출처입니다. 「마감」 열은 15분 안에 끝냈는지(걸린 시간) 아니면 시간 초과로 강제 종료됐는지를 보입니다. 공동 13위는 제출 파일이 없는 3종입니다.

실용 순위 (600점 이상, 소요 시간순)

1000점 순위와 별도로, 총점이 600점 이상인 7종만 소요 시간이 짧은 순서로 나열했습니다.

실용 순위는 같은 규칙(총점 600점 이상을 생성 시간순)을 유지했지만, 이번 시험에는 15분 상한이 있습니다. ff·q38 은 시간 초과로 강제 종료된 결과물입니다. ff 는 기획서(DESIGN.md)와 동작하는 게임을 남기고 README 를 쓰기 전에 마감됐습니다. mcv 는 처치한 적이 사라지지 않아 방어와 무관하게 3웨이브에 지므로 600점을 넘지만 플레이 체험은 불완전합니다.

• 7종 중 15분 상한에 걸린 것은 ff·q38 둘뿐이고, 나머지 5종은 3분 11초에서 8분 40초 사이에 끝냈습니다. 파일을 만든 12종으로 넓혀 보면 10종이 9분 안에 끝났습니다.
• 가장 빨랐던 orn(3분 11초)은 총점 823점으로 2위입니다. 빨리 끝낸 것과 잘 만든 것이 겹친 드문 사례입니다.

각 모델이 고른 게임

장르와 규칙, 기획과 디자인의 진행 방식을 모델에 맡긴 시험의 핵심 관찰입니다. 「고른 게임」은 QA 가 게임을 직접 돌려 확인한 내용이고, 「기획 산출물」과 「기획 활용」은 코드 리뷰가 문서와 코드를 대조한 내용입니다. 12종이 모두 경로형 타워 디펜스(8종) 아니면 슈팅·사격형 방어(4종) 를 골랐고, 3종은 파일을 만들지 못했습니다.

이 시험만의 관찰

• 인터넷을 허용했지만 결과물에 외부 라이브러리·에셋·CDN 을 쓴 엔트리는 0개입니다. 게임 파일이 실행 중 불러오는 외부 URL 은 0건이고, 패키지 설치도 이미지·소리 같은 바이너리 에셋도 0건입니다. 15분 안에서는 조사보다 직접 만들기를 골랐다는 뜻입니다. 네트워크 사용은 「위반」이 아니라 「관찰」로 집계한 결과 webfetch 도구 호출은 15종 모두 0회였고, 셸에서 curl·wget 계열 명령을 실행한 것은 q36 의 3회뿐입니다(주소가 남지 않은 호출이고 내려받은 파일은 결과물에 없습니다). 외부 주소가 보이는 곳은 cn 의 README 에 있는 배지 이미지 링크 2개뿐인데, 출처 표기 없이 넣어 6절에서 3점을 깎았습니다. 모델 고정 게이트웨이는 다른 모델을 요청하는 시도를 한 건도 막은 적이 없습니다(거부 0건).
• 별도 기획서를 남긴 것은 ff 하나(DESIGN.md)이고, 그래도 1위입니다. 기획서의 수치가 데이터 표로 그대로 옮겨졌고 실측 1절 298/300, 2절 178/200 으로 가장 높습니다. 다만 15분 마감 전에 README 를 쓰지 못해 6절의 정확성 항목이 0점입니다. 나머지 11종은 README 가 기획을 겸했고 페르소나 기록이나 스타일 가이드를 따로 남긴 모델은 없습니다.
• q38 도 시간 초과입니다. 연출(파티클·글로우·흔들림), 5레벨 업그레이드, 철거까지 얹었지만 시작 골드가 0 이고 골드가 처치와 웨이브 보너스로만 들어와, 터렛을 하나도 짓지 못한 채 2웨이브에 집니다. 핵심 경제를 검증하지 않은 채 마감했다는 점이 4절(시간 관리)에서 감점되었습니다(4-1 30/60).
• 장르 해석은 경로형 타워 디펜스가 다수였습니다. 12종 중 8종(fn·q38·mg·ff·cn·q36·orn·mcv)이 경로형 타워 디펜스이고, 4종은 슈팅·사격형입니다. 이 가운데 aw(기지 이동·자동 사격)와 mel(방향키 이동·클릭 발사), lfm(세로 슈팅)은 하단의 아군을 움직여 적을 쏘는 방어이고, bolt 는 고정 기지에서 마우스 방향으로 직접 조준해 쏩니다. 자원 경제와 배치를 가진 것은 경로형 타워 디펜스뿐입니다.
• 15분의 흔적으로 보이는 결함은 시간 초과가 아니어도 나왔습니다. 시간 안에 끝냈는데 미완성인 경우로는 cn(스크립트의 템플릿 문자열이 닫히지 않은 채 끝나 6분 9초에 SyntaxError), lfm(시작 상태에서 플레이로 넘어가는 전이가 없음), q36(시작 뒤에도 전체 화면 덮개가 CSS 명시도 때문에 남아 입력을 막음), mcv(처치한 적을 배열에서 빼지 않음)가 있습니다. 시간 초과로 잘린 것은 ff(README 없음)와 q38(경제 미검증)입니다.
• 15분 안에 대부분 끝냈습니다. 파일을 만든 12종 가운데 10종이 9분 안에 끝났고(1분 11초 mel, 1분 33초 lfm, 1분 48초 bolt, 3분 3초 q36 …), 8분 40초 fn 이 그 가운데 가장 오래 걸렸습니다. 제한에 걸린 것은 ff·q38 뿐입니다. c1·c7r·c7 은 6~58초 만에 끝내고 파일을 만들지 못했습니다.
• 정상 동작하는 게임을 낸 모델은 5종(ff·orn·fn·aw·mg)입니다. ff·orn 은 20웨이브 이상에 승리·재시작·배속까지 갖췄고, fn 은 업그레이드가 없고 재시작이 새로고침이며, aw 는 경제와 배치가 없고, mg 는 경로 위 배치 제한이 서술과 다르게 동작하고 재시작이 없습니다.

심사 기록 (PM 판단)

• R3 를 03 에도 적용했습니다. 드래곤플라이트 v2 에서 신설한 누적 원칙으로, 사람이 시작하거나 조작할 수 없어 장면이 진행되지 않는 엔트리는 실측 항목(1절, 2절, 4-1)을 0점으로 합니다. 해당은 lfm(시작 전이 없음), q36(시작 뒤 덮개가 모든 입력을 막음), cn(스크립트 전체가 실행되지 않음) 3개이고, QA 는 주입으로 확인한 부분에 70% 상한(R2)을 적용해 점수를 주었습니다. 원점수는 심사 기록에 보존했습니다.

• 같은 결함은 한 번만 깎았습니다. mcv 의 「처치한 적이 배열에서 빠지지 않음」은 1절(실측)에서 이미 깎았으므로 코드 리뷰 3-2 의 −8 을 돌려주었습니다.
• 3-3 시각 디자인은 PM 이 채점했습니다. QA 가 남긴 장면 스크린샷과 메모를 보고 매겼고, 주입으로만 본 장면(q36)은 70% 상한을 적용했습니다.
• ff 의 README 미제출은 그대로 처리했습니다. 지시문이 README.md 를 요구했으므로 DESIGN.md 를 대용으로 인정하지 않고 6절 정확성을 0점으로 했습니다(코드 리뷰 판단 유지).

해석 주의

• 표본은 모델당 1회(n=1)이고 15분이라 우연의 영향이 큽니다. mg 682 와 q38 689, aw 733 과 fn 796 처럼 가까운 구간은 순위보다 경향으로 읽어 주세요.
• 서로 다른 장르를 같은 잣대로 줄 세운 값입니다. 1000점은 모델이 정한 규칙이 일관되게 구현됐는가를 재는 것이어서, 어느 게임이 더 재미있는지는 알려 주지 않습니다. 경제와 배치가 없는 슈팅형은 설계 항목(2절)에서 불리합니다.
• 코드·기획 리뷰가 총점의 4할입니다. 그래서 처치한 적이 사라지지 않는 mcv 도 600점을 넘었고, 실행되지 않는 lfm 과 cn 도 실측이 0 인데 코드·기획 점수만으로 각각 207점, 182점을 받았습니다. 총점만 보고 「잘 돌아가는 게임」으로 읽지 말고 표 아래 「각 모델이 고른 게임」을 함께 봐 주세요.

시험의 한계

• 원래 자동 시험 도구의 시작 판정에 결함이 있었습니다. 시작 버튼을 눌러도 한 번에 끝나는 변화(시작 화면이 사라짐)를 반응으로 읽지 못해 시작 실패로 판정하곤 했습니다. 시작 경로를 따로 시험하고 시작 뒤에도 화면을 덮는 층이 남는지 검사하는 개선 도구를 추가해 보완했고, 점수는 QA 의 직접 실측으로 매겼습니다. 개선 도구의 「덮는 층」 판정도 틀릴 수 있습니다. 예를 들어 bolt 에서 시작 뒤 다시 나타난 층은 CSS 명시도 문제가 아니라 1.7초 만에 뜬 승리 오버레이였습니다.
• 실측은 헤드리스 Chrome 을 DevTools 프로토콜로 조작해 했습니다. 1280×960, 낮은 우선순위(nice 19), 한 번에 하나씩이고 모바일은 시험하지 않았습니다.
• 후반 웨이브·승리·게임 오버처럼 오래 걸리는 상태 일부는 콘솔로 주입해 시간을 줄였습니다. 주입한 방법은 근거에 적었고, 자연 플레이로 도달할 수 있는 상태에는 70% 상한을 두지 않았습니다. 정상 플레이로 도달할 수 없어 주입으로만 본 상태(q38·lfm·q36)는 70% 상한이 걸렸습니다.
• 시작 화면이 없는 설계(자동 시작)는 시작 입력 항목에서 감점하지 않았습니다.
• 4-2(범위 조절의 흔적)는 실행 기록 없이 코드와 문서의 상태로만 판정했습니다. 파일 시각이 정규화돼 있어 작업 순서를 알 수 없기 때문입니다.
• 3-3 은 PM 1인이 스크린샷으로 채점했습니다. 그래픽, 재미, 조작감, 효과음은 점수에 반영되지 않은 부분이 있습니다.
• 네트워크 사용 관찰의 한계: 로그에 남지 않는 호출은 알 수 없고, 서브에이전트의 호출은 실행 직후 보관한 도구 호출 기록에서만 보입니다. 모델이 코드 안에서 직접 한 네트워크 접근은 그 코드가 기록에 남은 경우에만 보이므로 완전한 목록은 아닙니다.

9-2. 결과 — v2

채점 방식: v2(모바일 터치 조작 추가)는 영역 1·2(500점)가 v2 과제로 바뀌어 A 터치 조작 200, B 모바일 화면 100, C 기존 기능 유지 200 이고, 영역 3~6(코드·기획·시간·문서 500점)은 v2 시점의 전체 코드와 문서에 v1 과 같은 기준을 적용합니다. A·B·C 와 4-1(마감 시점 동작 60)은 QA 리뷰어가 모바일 에뮬레이션(390×844, 터치 입력) 과 데스크톱 v1 ↔ v2 비교로 직접 실측했고(560점), 3-1·3-2·4-2·5·6 은 코드·기획 리뷰어가(390점), 3-3 시각 디자인은 진행자(PM)가(50점) 채점했습니다. 결과물은 A~O 로 익명 처리(블라인드)해 채점했고, 채점이 끝난 뒤 모델 이름을 공개했습니다.

품질 순위 (1000점)

열 머리의 A/200 은 「항목/만점」입니다. A 터치 조작, B 모바일 화면 맞춤, C 기존 기능 유지, 3 기획·디자인(3-1 + 3-2 + 3-3, 150), 4 시간 관리(4-1 + 4-2, 100), 5 코드 품질, 6 README·출처입니다. 「마감」 열은 15분 안에 끝냈는지 보입니다. 「v1 → v2」 열은 루브릭이 달라 단순 뺄셈으로 읽으면 안 됩니다. 공동 13위는 제출 파일이 없는 3종입니다.

실용 순위 (600점 이상, 소요 시간순)

1000점 순위와 별도로, 총점이 600점 이상인 6종만 소요 시간이 짧은 순서로 나열했습니다.

실용 순위는 같은 규칙(총점 600점 이상을 생성 시간순)입니다. 다만 mcv 는 처치한 적이 사라지지 않는 v1 결함을 그대로 둬 방어와 무관하게 초반에 지고, orn 은 390px 에서 지도와 사이드바가 잘립니다. 두 모델은 600점을 넘지만 모바일 체험은 불완전합니다. 시간 초과는 0건이며 q38 의 14분 9초가 가장 길었습니다.

• v1 에서 15분 마감에 걸렸던 ff(15:00)와 q38(15:00)이 이번에는 둘 다 시간 안에 끝났습니다(ff 5분 18초, q38 14분 9초). ff 는 같은 기획서(DESIGN.md)를 두고도 세 배 가까이 빨라졌습니다.
• 600점 이상 6종 가운데 가장 빨리 끝낸 mcv(1분 42초)와 aw(1분 52초)는 기존 코드에 터치 입력을 얹는 작업이었습니다. 파일을 만든 12종 모두 v1 의 마감(15분)보다 짧게 끝났습니다.

눈에 띈 점

• ff 가 909점으로 1위입니다. v1 에서 마감에 쫓겨 쓰지 못한 README 를 이번에 새로 만들었고(터치 7단계 포함) 기획서 DESIGN.md 도 유지했습니다. 클릭, touchend, 키(U·S·Space), 버튼이 handleTap·upgradeTower·sellTower·startWave 한 벌로 모여 코드 리뷰의 구조 항목이 12종 가운데 가장 높고(70/80), 모바일에서는 데스크톱과 같은 남색 패널·칩·카드 디자인을 세로로 쌓은 큼직한 터치 UI 를 만들었습니다(3-3 46/50). 5분 18초에 끝났습니다. 감점은 DESIGN.md 의 조작·화면 구성이 v1 그대로라 v2 갱신 몫에서 10점을 잃은 점, 격자 칸이 18.5px 라 정밀 탭이 필요한 점, 그리고 문서가 말한 「자동 다음 웨이브」가 구현되지 않았고 클리어 보너스가 첫 웨이브에만 들어오는 v1 결함이 이어진 점입니다.
• q38 이 864점으로 2위이고 모바일 대응 폭이 가장 넓습니다. 길게 눌러 취소하기, 터치 뒤에 생기는 합성 click 이중 처리 차단, safe-area, 화면 크기에 따라 경로를 다시 만드는 반응형까지 갖췄습니다(코드 리뷰). 그러나 시작 골드가 0 인 v1 결함이 그대로라 자연 플레이로는 터렛을 살 수 없습니다(자연 플레이 최대 골드 25, 159초 만에 패배). v2 가 새로 넣은 「START WAVE」 버튼도 v1 의 상태 기계 결함 위에 얹혀 눌러도 반응하지 않습니다.
• 터치 항목은 aw 196, ff 192, mg 191(각 /200)이 가장 높습니다. aw 는 위치 계산 함수 하나에 스케일 보정까지 넣어 마우스와 터치가 같은 길로 가고, mg 는 pointerdown 하나로 마우스와 터치를 통일했습니다. aw 는 화면 아래 65% 가 비어 있고 캔버스 테두리 때문에 가로로 2px 넘칩니다.
• fn 은 v2 에서 유일하게 v1 보다 나빠진 회귀입니다. selBar 가 LH 선언보다 앞에 놓여 TDZ ReferenceError 가 나고, v1 에서 정상이던 게임(796점, 3위)이 통째로 멈춰 269점(10위)이 됐습니다. 터치 코드를 붙이는 작업이 선언 순서를 어긴 것입니다.
• bolt 는 모바일에서 시작할 수 없습니다. window 단위 touchstart 의 preventDefault 가 시작 버튼의 click 을 막아, 새 페이지에서 시작 버튼을 4번 눌러도 반응이 없었습니다. 데스크톱은 v1 과 같이 정상입니다. 탭 좌표를 캔버스 좌표로 바꾸지 않아 발사각도 어긋납니다(−159° 대 −90°). 같은 좌표 변환 누락이 q36·mcv·cn 에서도 코드 리뷰에서 지적됐습니다.
• 피드백이 없어 v1 결함을 하나도 고치지 못했습니다. q36(시작 뒤에도 남는 전체 화면 덮개), cn(템플릿 문자열 미종결 SyntaxError), lfm(시작으로 넘어가는 전이 없음), mcv(처치한 적 미제거)는 v1 과 똑같이 실행되지 않거나 불완전합니다. 같은 시험을 v1 과 v2 데스크톱에서 돌린 비교에서 고쳐진 항목은 없었고, mg·mel 의 재시작 수단 없음, orn 의 업그레이드 호출부 없음도 그대로입니다.
• orn 은 390px 에서 지도 왼쪽, HUD 숫자, 사이드바가 잘립니다. 터치 조작 자체는 되지만(164/200) 화면 맞춤이 28/100 이고, mcv 는 viewport 메타가 없어 모바일에서 0.4배로 축소되며 글자가 약 5px 입니다.
• 시간 초과는 0건이고 인터넷 사용 흔적도 없습니다. 파일을 만든 12종 모두 마감 안에 끝냈습니다. 네트워크 사용 관찰에서 v2 의 webfetch 도구 호출, curl·wget, 패키지 설치, 외부 URL 접근은 15종 모두 0건이고, 게임 파일이 실행 중 불러오는 외부 URL 도 0개입니다. 모델 고정 게이트웨이가 막은 다른 모델 요청도 0건입니다.

v1 → v2 변화

v1 순위·총점은 위 9절, v2 는 위 표입니다. 두 라운드의 루브릭이 달라 점수 차이는 「이 과제에서 얼마나 잘 했나」의 변화이지 같은 잣대의 증감이 아닙니다.

심사 기록 (PM 판단)

• R3 를 터치 항목에 일관되게 적용했습니다. 제출 상태로 사람이 시작·조작할 수 없는 q36(덮개), fn(TDZ 파손), bolt(모바일 시작 불가)는 터치 A 의 코드 근거 점수 21점(코드·CSS 로만 확인해 70% 상한이 걸린 값)을 0 으로 했습니다. 드래곤플라이트 v2 의 R3 와 같은 기준이고, 화면 B 의 정적 사실(viewport 메타 등)은 유지했습니다. QA 원점수는 심사 기록에 그대로 보존했습니다.

• bolt 는 환경별로 판정했습니다. 데스크톱은 정상이라 C(기존 기능 유지)는 200점, 4-1(마감 시점 동작)은 데스크톱 부분만 인정해 40점입니다. QA 의 환경별 판정을 그대로 유지했습니다.
• q38 의 시작 골드 0 은 부분 R2 로 유지했습니다. 자연 플레이로 도달할 수 없어 주입으로만 확인한 배치·업그레이드·철거 몫에만 70% 상한을 씌웠습니다(항목 전체가 아닙니다).
• 3-3 시각 디자인은 PM 이 채점했습니다. 모바일과 데스크톱 장면 스크린샷을 보고 매겼고, 고친 사본이나 주입으로만 본 장면만 있는 엔트리는 상한을 적용했습니다.

해석 주의

• 표본은 모델당 1회(n=1)이고 15분이라 우연의 영향이 큽니다. ff 909 와 q38 864, mg 788 과 orn 778 처럼 가까운 구간은 순위보다 경향으로 읽어 주세요.
• 기존 기능 유지(C 200점)는 v1 대비 회귀만 깎습니다. v1 부터 결함이 있던 q38·mg·mcv·mel 도 200점이므로, 총점이 높다고 완성된 게임은 아닙니다. 「터치로 플레이 가능?」 열과 위의 실용 순위 주의 문장을 함께 봐 주세요.
• v1 과 v2 의 루브릭이 다릅니다. v2 는 실측 500점이 터치 조작·모바일 화면·기존 기능 유지로 바뀌어, v1 → v2 총점 차이는 같은 잣대의 증감이 아닙니다.

시험의 한계

• 핀치와 끌기 스크롤은 대조 페이지로 먼저 검증한 뒤 측정했습니다. 제한이 없는 대조 페이지에서 끌기가 스크롤을 일으키고(scrollY 606) 두 손가락 터치가 확대를 일으키는 것(scale 5)을 확인해, 측정 도구가 감지할 수 있음을 보였습니다. 합성 핀치 명령은 대조 페이지에서도 확대를 못 일으켜 쓰지 않았습니다.
• 당겨서 새로고침은 에뮬레이션할 수 없어 touch-action·overscroll-behavior·preventDefault 코드로 판정했습니다(코드로만 확인한 항목은 70% 상한).
• 자동 시험 도구와 개선 도구는 근거 자료로만 썼습니다. 둘 다 휴리스틱이어서 점수는 QA 가 새 페이지에서 입구별로 직접 실측한 결과(타워가 놓였는가, 자원이 줄었는가, 탄이 그 방향으로 나갔는가)로 매겼습니다.
• 터치는 Chrome 의 터치 에뮬레이션(390×844, iPhone UA)이며 실제 폰과 다를 수 있습니다. 실측은 낮은 우선순위(nice 19)의 헤드리스 Chrome 으로 한 번에 하나씩 했고, 자연 플레이로 도달할 수 없는 상태만 주입했습니다.
• 3-3 은 PM 1인의 스크린샷 판단이며, 재미와 조작감, 효과음은 점수에 반영되지 않은 부분이 있습니다.

9-3. 결과 — v3

채점 방식: v3(4스테이지마다 보스전)는 영역 1·2(500점)가 v3 과제로 바뀌어 A 보스전 구성 150(4·8 스테이지에 보스전이 열림 100, 비보스 스테이지에는 보스가 없음 50), B 보스 100(일반 적과 다른 체력 40, 다른 행동 패턴 40, 실제로 싸울 수 있음 20), C 표시 50(현재 스테이지 25, 보스전 여부 25), D 기존 기능 유지 200 입니다. 영역 3~6(500점)은 v3 시점의 전체 코드와 문서에 v1 과 같은 기준을 적용합니다. A~D 와 4-1(마감 시점 동작 60)은 QA 리뷰어가 직접 실측했고(560점), 3-1·3-2·4-2·5·6 은 코드·기획 리뷰어가(390점), 3-3 시각 디자인은 진행자(PM)가(50점) 채점했습니다. 결과물은 A~O 로 익명 처리(블라인드)해 채점했고, 채점이 끝난 뒤 모델 이름을 공개했습니다.

품질 순위 (1000점)

열 머리의 A/150 은 「항목/만점」입니다. A 보스전 구성, B 보스, C 표시, D 기존 기능 유지, 3 기획·디자인(3-1 + 3-2 + 3-3, 150), 4 시간 관리(4-1 + 4-2, 100), 5 코드 품질, 6 README·출처입니다. 「마감」 열은 15분 안에 끝냈는지 보입니다. 공동 13위는 제출 파일이 없는 3종입니다.

각 모델의 보스 설계

보스 설계는 QA 가 게임을 돌려 확인한 내용과 코드 리뷰가 코드에서 읽은 내용입니다. 「4·8 보스전 실측」 칸에는 보스전이 열리는 스테이지 4·8 에 실제로 닿았는지, 어떻게 확인했는지를 적었습니다.

실용 순위 (600점 이상, 소요 시간순)

1000점 순위와 별도로, 총점이 600점 이상인 6종만 소요 시간이 짧은 순서로 나열했습니다.

실용 순위는 같은 규칙(총점 600점 이상을 생성 시간순)입니다. mcv 는 처치한 적이 사라지지 않는 결함(v2 부터)으로 보스에 정상 도달하지 못해 보스 항목이 주입 확인(70% 상한)입니다. 600점을 넘지만 플레이 체험은 불완전합니다. cn 은 v2 의 문법 오류를 피드백 없이 v3 에서 스스로 고쳐 처음으로 600점을 넘었습니다. 시간 초과는 fn 1건이며 fn 은 600점 미만이라 이 표에 없습니다.

눈에 띈 점

• ff 가 925점으로 1위이고 보스전 과제를 만점으로 풀었습니다. QA 실측이 560/560 입니다(A 150, B 100, C 50, D 200, 4-1 60). 보스 6종을 BOSSES 데이터 표로 정의했고, 보스마다 능력이 있습니다(타워를 멈추는 냉기 방출, 투사체를 지우고 경직시키는 EMP, 크롤러를 부르는 증식, 재생과 가속). 보스전이 열리면 맥박처럼 깜빡이는 「BOSS FIGHT」 배지가 뜨고, 한 단계 앞인 3·7 스테이지에서는 「NEXT: BOSS @ 4」로 미리 알려 줍니다. 보스가 없을 때는 배지가 숨어 거짓 표시도 없습니다. 감점은 별도 기획서 DESIGN.md 를 v3 로 갱신하지 않은 점(3-2 −6), README 가 「화면 상단 체력바」라고 했지만 실제로는 보스 머리 위에 그리는 점입니다. 9분 43초에 끝냈습니다.
• orn 이 896점으로 2위이고 2분 47초에 끝냈습니다. 보스 4종이 순환하고(발칸 1400, 프리제 1800, 토르 2200, 티탄 2800 HP) 체력이 절반 아래로 내려가면 속도가 오르고 초당 회복하는 2페이즈로 바뀝니다. BOSS_DEFS·BOSS_KEYS 로 보스를 데이터화했습니다. 흠은 두 가지입니다. 게임을 열자마자(웨이브 0, 보스 없음) 「보스전: 불의 보스 발칸」 박스가 켜져 있는 거짓 표시이고, 보스 박스가 켜지고 꺼질 때 사이드바 단추가 59px 움직여 「속도」 단추 클릭이 빗나갑니다(D 195/200). 또 README 는 보스가 「이동하며 공격」한다고 하지만 공격하는 코드는 없습니다.
• aw 와 mg 는 정상 플레이로 스테이지 4·8 보스에 닿았지만 보스는 단순합니다. aw 의 보스는 위에서 내려와 좌우로만 왕복해서(공격 없음) 이동 패턴만 다르고(B-2 30/40), 빠른 왕복 때문에 자동 사격이 거의 맞지 않아 처치에 약 345초가 걸렸습니다. mg 의 보스는 체력·속도·누출 피해만 다른 수치형 1종이고(B-2 25/40) 타워 발사 속도가 프레임 단위라 1초 만에 처치됩니다. 두 모델 모두 기존 기능은 회귀 없이 유지했습니다(D 200).
• q38 은 v2 의 864점(2위)에서 306점(7위)으로 떨어졌습니다. v3 변경이 적 이동 줄(e.dist += e.speed * dt)을 지우고 #waveNum 요소를 지우면서 참조는 남겨, 모든 적이 시작점에 멈추고 웨이브를 시작할 때마다 예외가 났습니다. 보스 코드 자체(WARDEN 부터 OVERMIND 까지 4티어, 대시·소환·분노)는 정돈되어 코드 리뷰 3-2 가 58/60 이었지만 제출 상태에서 장면이 정지해 QA 실측 560점이 통째로 0 입니다.
• cn 은 v2 의 문법 오류를 피드백 없이 v3 에서 스스로 고쳐 처음으로 600점을 넘었습니다(182 → 217 → 706). 템플릿 문자열이 닫히지 않아 스크립트가 통째로 죽던 상태에서 벗어나 게임이 뜹니다. 다만 방어기를 설치하는 코드 경로가 없어(v2 부터) 웨이브 3 에서 생명이 0 이 되고(72초), 보스는 주입으로만 확인되어 70% 상한이 걸렸습니다. 03 의 세 라운드에서 모델이 이전 라운드의 치명 결함을 스스로 고친 사실상 유일한 사례입니다.
• 실행 불가(R3)가 6개이고, 새로 깨뜨린 것과 이어받은 것이 갈립니다. QA 의 v2 → v3 회귀 목록으로 나누면 회귀가 4개입니다. q38(적 이동 줄 삭제), lfm(Illegal continue statement 구문 오류), mel(Unexpected identifier 'health' 구문 오류), bolt(dist() 함수를 지워 첫 화살에 루프 정지, 터치는 시작 불가)는 v2 에서 되던 부분을 v3 변경이 망가뜨렸습니다. 나머지 2개는 v2 부터 이어진 결함입니다. q36 은 시작 뒤에도 남는 전체 화면 덮개가 입력을 막고(보스 5종 연출은 고친 사본에서만 보임, 코드 리뷰는 여기에 v3 가 캔버스 크기 대입을 지운 변경도 찾았습니다), fn 은 선언 순서(TDZ) 오류로 시작하자마자 멈춥니다.
• 시간 초과는 fn 1건입니다. 15분(900초) 마감에 강제 종료됐고 그 순간의 결과물로 채점했습니다. 보스 코드는 파싱되고 동작하는 부분을 망가뜨리지 않았지만(4-2 24/40), 작은 변경(+69/−7)에 15분을 넘겼고 README 를 v3 로 갱신하지 못했습니다(스테이지·보스 규칙 절이 없어 3-2 34/60). v2 의 TDZ 오류도 그대로라 실측은 0 입니다.
• 보스 설계가 둘로 갈렸습니다. 능력이나 페이즈가 있는 보스는 ff·orn 이고(코드상 q38·q36·fn 도), mg·mcv·cn·bolt 는 체력·속도·누출 피해 수치만 다른 1종을 만들었습니다. aw 는 이동 패턴만 다릅니다. 보스를 데이터 표로 정의한 4종(ff·orn·q38·q36)은 5절 구조 점수가 66~70 으로, 나머지(55 이하)보다 높습니다.
• 인터넷 사용은 0건입니다. v3 실행 15건에서 webfetch 도구 호출, curl·wget, 패키지 설치, 결과물이 실행 중 불러오는 외부 URL 이 모두 0건이고, 모델 고정 게이트웨이가 막은 다른 모델 요청도 0건입니다. 기록에 남은 외부 주소는 cn 이 README 에 쓴 배지 이미지 링크 하나뿐입니다.

v2 → v3 변화

v2 순위·총점은 9-2절, v3 는 위 표입니다. 두 라운드의 루브릭이 달라 점수 차이는 「이 과제에서 얼마나 잘 했나」의 변화이지 같은 잣대의 증감이 아닙니다.

심사 기록 (PM 판단)

• R3 를 일관되게 적용했습니다. q38·lfm·mel·q36·fn·bolt 는 제출 상태로 장면이 진행되지 않아 실측 항목(A~D, 4-1)을 모두 0 으로 했습니다. q36·fn 은 v2 부터의 결함이지만 「유지 만점」을 주지 않는 R3 기준(드래곤플라이트 v2, 디펜스 v2 와 동일)을 유지했습니다. 고친 사본에서 잰 값은 근거로만 남겼고 점수에는 넣지 않았습니다.

• 4-2 와 D 는 둘 다 유지했습니다. 4-2(범위 조절)의 「동작하는 부분을 망가뜨림」 감점과 D(기존 기능 유지)의 R3 0점은 루브릭이 각각 명시한 다른 관점이라 둘 다 적용했습니다. 디펜스 v2 와 같은 처리입니다.
• QA 의 두 해석을 그대로 따랐습니다. cn 은 보스가 「스테이지」가 아니라 「웨이브」 4·8 에 열리고 화면의 스테이지 값은 4웨이브 묶음이라 기본 점수를 80 으로 보았고, 보스 행동 점수(B-2)는 능력·페이즈가 있으면 40, 이동 패턴만 다르면 30, 수치만 다르면 25, 한 가지 수치만 다르면 15 로 일관되게 매겼습니다.
• 3-3 시각 디자인은 PM 이 보스전 장면 위주로 채점했습니다. 주입이나 고친 사본으로만 본 장면이 있는 엔트리는 상한을 적용했습니다.

해석 주의

• 표본은 모델당 1회(n=1)이고 15분이라 우연의 영향이 큽니다. ff 925 와 orn 896 처럼 가까운 구간은 순위보다 경향으로 읽어 주세요. 같은 모델을 다시 돌리면 결과가 달라질 수 있습니다.
• v3 에서는 실행 불가가 순위를 크게 가릅니다. 실행 불가 6종의 총점은 실측이 0 이어서 코드·기획 점수만으로 153~306점입니다. q38 의 306점은 코드와 문서가 좋았다는 뜻이지 게임이 돌아간다는 뜻이 아닙니다.
• 보스전 점수는 설계의 풍부함을 반영합니다. 보스가 능력을 가지면 B-2 에서 최대 40점, 수치만 다르면 25점이라 같은 「보스 구현」이어도 점수가 갈립니다.

시험의 한계

• 스테이지 4·8 까지 가는 시간을 줄이려는 주입은 R2 로 보지 않았습니다. 정상 진행으로 도달할 수 있는 상태이기 때문입니다. ff·orn 은 웨이브 3 을 주입해 4 와 8 의 보스를 확인했고 orn 은 정상 플레이로도 4 에 닿았으며, aw·mg 는 주입 없이 정상 플레이로 4·8 에 도달했습니다. 방어기를 지을 수 없는 cn 과 죽은 적이 누출되는 mcv 는 정상 플레이로 보스에 닿을 수 없어 주입으로만 확인했고 70% 상한이 걸렸습니다.
• 보스의 증식·재생 같은 세부와 실행되지 않는 엔트리의 보스 연출은 코드로 확인했고 점수에는 쓰지 않았습니다.
• 자동 시험 도구(원래 도구와 개선 도구)는 휴리스틱이라 근거 자료로만 썼고, 점수는 QA 가 새 페이지에서 입구별로 직접 실측한 결과로 매겼습니다. 코드 리뷰의 「JS 예외」 건수는 회귀 확인에 참고했습니다.
• 판단이 갈릴 수 있는 점이 있었습니다. QA 는 q36·fn 의 D 를 「회귀만 감점」으로 보면 200 이지만 R3 문구에 따라 0 으로 주었고, cn 의 스테이지 해석도 위와 같이 보수적으로 잡았습니다. 둘 다 PM 이 확인해 유지했습니다.
• 실측은 낮은 우선순위(nice 19)의 헤드리스 Chrome 으로 한 번에 하나씩 했고 터치는 에뮬레이션입니다. 3-3 은 PM 1인의 스크린샷 판단이며 재미와 조작감은 점수에 반영되지 않은 부분이 있습니다.

10. 03 디펜스 종합 — v1 → v2 → v3 (완결)

세 라운드의 총점 평균으로 종합 순위를 냅니다. 테트리스, 드래곤플라이트와 같은 기준(종합 순위 = 3라운드 평균, 진행자(PM)가 정한 기준)입니다. 라운드마다 루브릭이 다르므로(v1 은 처음 만들기, v2 는 터치 조작, v3 는 보스전) 평균은 「세 과제를 두루 잘 했나」를 보는 값이지 한 잣대의 누적이 아닙니다.

• 15분 제한과 기획 위임 아래서, 기획서를 쓴 ff 가 세 라운드를 모두 이겼습니다(845 → 909 → 925, 매 라운드 1위, 평균 893.0). 별도 기획서 DESIGN.md 를 남긴 모델은 ff 하나였고, 그 수치가 데이터 표로 그대로 옮겨져 있었습니다. orn(평균 832.3)은 기획서 없이 README 만으로 빠르게 만들어 종합 2위, 코드 품질(5절) 점수는 세 라운드 모두 가장 높았습니다.
• 인터넷을 허용했지만 아무도 쓰지 않았습니다. 45번의 실행(15종 × 3라운드)에서 webfetch 도구 호출은 0회, 패키지 설치 0회, 결과물이 실행 중 불러오는 외부 URL 0건이었습니다. 셸에서 curl·wget 계열 명령을 실행한 것은 v1 q36 의 3회뿐이고 내려받은 것은 없습니다. 기록에 남은 외부 주소는 v3 cn 이 README 에 쓴 배지 이미지 링크 하나뿐입니다. 모델 고정 게이트웨이가 막은 다른 모델 요청도 0건이었습니다. 15분 안에서는 조사보다 직접 만들기를 골랐다는 뜻입니다.
• 시간 초과는 3건뿐입니다(v1 ff·q38, v3 fn). 파일을 만든 36번의 실행 가운데 30번이 9분 안에 끝났고 소요 시간의 중앙값은 약 3분 25초였습니다. 대부분 시간을 남기고 미완성으로 끝냈다는 뜻이고, 15분이라는 상한은 모델이 쓴 시간보다 넉넉했습니다.
• 대형 모델이 v3 에서 새 기능을 얹다가 기존 동작을 깨뜨렸습니다. q38 은 v2 의 864점(2위)에서 v3 의 306점으로, 변경이 적 이동 줄을 지워 장면이 멈췄습니다. q36 은 덮개가 입력을 막는 v1 결함을 세 라운드 내내(268 → 280 → 292) 못 고쳤고, v3 에서는 보스 시스템을 크게 덧붙이며 캔버스 크기 대입까지 지웠습니다. v3 에서 새로 깨진 것은 q38·lfm·mel·bolt 4건입니다.
• 피드백이 없으면 이전 결함은 거의 고쳐지지 않았습니다. 예외는 v3 의 cn 하나로, v2 의 문법 오류를 스스로 고쳐 182 → 217 → 706 으로 올랐습니다. 반대로 q36 의 덮개는 세 라운드, fn 의 TDZ 오류는 v2 와 v3 두 라운드 동안 그대로였고, lfm 의 시작 불가와 cn 의 문법 오류도 v1 에서 v2 까지 고쳐지지 않았습니다.

대회 전체 종합(세 시험의 평균)은 루트 README 의 「대회 종합」에 있습니다.

• 모델 정보: 00_model_info
• 저장소 첫 화면: llm_model_test
• 앞의 시험: 01 테트리스, 02 드래곤플라이트