Roblox가 게임 제작을 어떻게 평가하는가

로블록스의 새로운 모바일 우선 제작 도구인 ‘Build’를 통해 사용자는 텍스트 프롬프트를 활용해 게임을 제작하고 전 세계 플레이어에게 공개할 수 있습니다. 완성도 높은 게임을 제작하려면 코드, 시각적 자산, 게임플레이 시스템, UI, 컨트롤을 하나의 복합적인 결과물로 통합하는 종단 간 에이전트 기반 게임 생성 시스템이 필요합니다. 이 시스템은 플레이어의 입력과 멀티플레이어 상호작용으로 발생하는 다양한 시나리오를 견고하게 처리해야 합니다. 뉴질랜드에서 알파 버전이 출시된 이후, 10만 명 이상의 플레이어가 Build를 사용하여 게임 제작을 시도했으며, 약 9,000개의 Build 게임이 공개되었습니다.¹ Build를 사용하여 게임을 제작한 수천 명의 사용자 중 71%는 이전에 Roblox Studio를 사용해 본 적이 없었으며,^¹ 이는 그들이 Build를 통해 새로운 시도를 하고 있음을 보여줍니다.

하지만 크리에이터들은 이 새로운 도구가 사용하기 쉽고, 생성된 게임의 품질이 충분히 높아 이를 기반으로 발전시킬 수 있을 때만 이를 사용할 것입니다. Build로 제작된 게임의 품질을 파악하기 위해, 저희는 제작 과정 전반을 평가하고, 이러한 평가 결과와 크리에이터의 피드백을 바탕으로 제품을 개선하고 있습니다. 저희의 평가(eval) 프레임워크는 의도 이해, 3D 플레이 가능성, 완성도 향상을 우선순위로 삼고 개선하는 데 도움이 되었습니다. 뉴질랜드에서 Build의 알파 버전이 출시된 이후, 크리에이터 만족도는 10% 향상되었고, 의도하지 않은 결과물은 18%에서 3%로 감소했으며, 프롬프트가 제공된 세션의 약 14%와 플레이 테스트의 19%가 공개되었습니다.² 이는 진행 상황을 보여주는 지표일 뿐, 평가의 영향력에 대한 인과적 추정치는 아닙니다.

게임 제작 평가가 다른 이유

게임은 앱, 동영상, 세계 모델 등 복합적인 산출물을 생성하는 다른 시스템에서 발견되는 평가상의 어려움 중 일부를 공유합니다. 예를 들어, 품질은 여러 구성 요소가 어떻게 상호 작용하느냐에 달려 있으며, 단일 구성 요소의 점수만으로는 결과를 완전히 설명할 수 없습니다. 

게임을 차별화하는 점은, 그 산출물이 플레이어가 주도하는 실행 가능한 실시간 시스템이라는 사실입니다. 반응성, 주체성, 진행성, 게임 감각과 같은 속성은 상호작용을 통해 드러나며, 코드나 자산만을 검토해서는 완전히 평가할 수 없습니다. 따라서 게임은 저수준의 정확성(결함 없고 플레이 가능한 상태)뿐만 아니라 고수준의 플레이어 경험(프로토타입이 아닌 완성된 게임처럼 느껴지는 것)이라는 유독 높은 기준을 충족해야 합니다. 

평가를 통해 우리가 답하고자 하는 질문은 개별 요소가 올바른지 여부가 아니라, 전체적인 결과물이 제작자의 의도와 일치하는지, 그리고 플레이어가 전체 경험을 끝까지 즐길 수 있는지 여부입니다. 이에 대한 답을 얻기 위해서는 하나의 지표만으로는 부족합니다.

네 가지 신호, 하나의 프레임워크

저희의 ‘빌드(Build)’ 창작 평가 프레임워크는 네 가지 신호를 결합합니다. 각 신호는 서로 다른 질문에 답하고, 서로 다른 유형의 실패를 포착하며, 구체적인 정량적 점수를 산출합니다:

1. 게임 사양 품질 (0 - 100점): Build는 엔드투엔드 생성 에이전트입니다. 제작자의 프롬프트를 사양으로 변환한 뒤, 이를 활용하여 게임을 생성합니다. 평가자는 해당 사양이 중요한 결정을 명시적으로 내리고, 제작자의 의도를 반영하며, Roblox 런타임 내에서의 실현 가능성을 고려하고, 명시되지 않은 요구 사항을 임의로 추가하지 않는지 여부를 평가합니다.

2. 정적 게임 품질 (0 - 100점): 정적 평가자는 Roblox Studio 편집 모드에서 생성된 게임을 검토합니다. 여기에는 게임 구조, 스크립트, 에셋, 속성, 연결, 클라이언트/서버 경계 등이 포함됩니다. 이 단계에서 우리는 두 가지 질문에 대한 답을 찾고자 합니다. 첫 번째는 게임이 올바르게 구축되었는지 여부입니다: 필수 시스템의 구현, 엔진 API 및 네트워킹 선택, 예상되는 컨트롤과 UI 구성 요소의 존재, 게임 아키텍처의 견고성과 일관성 등이 포함됩니다. 

두 번째는 게임이 재미를 주도록 설계되었는지 여부입니다: 코어 루프의 깊이, 콘텐츠의 다양성과 단계적 심화, 진행 시스템, 재플레이성, 그리고 장르의 기본 틀을 뛰어넘는 혁신성 등이 평가 대상입니다. 게임은 아키텍처상 깔끔할 수 있지만 콘텐츠의 깊이가 부족할 수도 있고, 아이디어는 풍부하지만 구현이 미흡할 수도 있습니다. 

이 두 가지 관점을 분리하고 모범 사례에 비추어 평가하면, 게임이 어떤 부분에서 부족한지 더 세밀하게 파악할 수 있습니다.

3. 플레이 테스트 (0~100% 합격률): 플레이 테스트 평가자는 게임을 실행하고, 코드에서 이벤트를 발생시키는 대신 탭, 클릭, 키 입력, 탐색 등 실제 플레이어와 유사한 입력을 통해 테스트 계획을 수행합니다. 사례별 테스트 계획은 게임이 시작되고, 반응하며, 진행되고, 오류에서 복구되며, 런타임 오류가 발생하지 않는지 확인합니다. 각 항목은 통과/불합격의 이분법적 결과로 평가되며, 단순한 ‘플레이 가능/불가능’ 판정과 함께 등급 가중치 적용 통과율로 보고됩니다. 일관성을 측정하기 위해 테스트를 반복합니다.

4. 시각적 및 체험적 품질 (0~100점): 게임의 외관과 느낌에 있어 가장 중요한 요소 중 일부는 코드만으로는 파악할 수 없으므로, 시각 평가자는 다양한 기기를 재현한 뷰포트에서 캡처한 게임플레이 영상을 바탕으로 표현력을 별도로 평가합니다. 이 평가 기준은 에셋 제작, UI 완성도, 모션, 조명, 오디오를 바탕으로 게임의 시각적 및 청각적 요소만을 살펴봅니다. 핵심 질문은 다음과 같습니다. 이 게임은 출시 가능한 제품처럼 보이나, 아니면 프로토타입처럼 보이나? 시각적 요소를 메커니즘과 분리하여 평가함으로써, “코드가 작동한다”와 “게임이 완성된 것처럼 보인다”는 두 가지 요소가 하나의 오해의 소지가 있는 점수로 합산되는 것을 방지합니다.

점수화되는 신호와 더불어, 매 실행마다 토큰 사용량, 툴 호출 횟수, 발동된 스킬, 지연 시간 등 정보 제공용 지표가 캡처됩니다. 이러한 지표는 평가 점수에 직접적인 영향을 주지는 않지만, 결과가 어떻게 도출되었는지 설명해 주거나, 동일한 게임임에도 빌드 비용이 두 배로 증가한 경우처럼 평가 기준에서 놓친 퇴보 현상을 포착하는 데 도움이 될 수 있습니다.

이러한 신호들은 감지한 오류와 다음과 같이 대응됩니다:

프롬프트가 제공된 3D 오비(Obby) 코스 탐방

실제 프롬프트에서 신호를 가장 쉽게 파악할 수 있습니다. 예를 들어, “시작 플랫폼, 움직이는 위험 요소, 체크포인트, 결승선이 있는 진정한 3D 오비 게임”과 같은 경우입니다. 오비는 로블록스에서 인기 있는 플랫폼 게임 유형입니다. 모든 구현 세부 사항을 명시하지 않더라도 제작자의 의도는 명확합니다. 빌더는 합리적인 가정을 바탕으로 세부 사항을 채워나가야 합니다.

계획 및 사양

빌드 팀은 '스카이포지 어센트(Skyforge Ascent)'라는 신규 게임에 대한 사양서를 작성했으며, 여기에는 체크포인트와 세 가지 유형의 위험 요소가 포함된 5개 구간으로 구성된 코스가 상세히 기술되어 있습니다. 이 사양서에는 핵심 루프, 난이도 곡선, 아트 디렉션, 화면, 오버레이 및 조작법이 정의되어 있습니다. 사양서 평가 결과 100점 만점에 91점을 받았으며, 완성도, 지침 준수, 실현 가능성 및 내부 일관성 항목에서 만점을 획득했습니다. 감점 사유는 구현 세부 사항과 수용 기준 충족도라는 두 가지 구체적인 항목에서 비롯되었습니다. 

이 사양서에는 회전 속도, 미끄러짐 거리, 타일 타이밍, 플랫폼 치수, 리셋 평면 높이 등의 수치 상수가 명시되어 있지 않아, 엔지니어는 여전히 이를 직접 결정해야 합니다. 또한, “약 24개의 플랫폼”이나 “셀레스티얼 포지 색상 팔레트”와 같은 몇 가지 수용 기준은 엄밀히 말해 반증할 수 없습니다. 높은 사양 점수는 해당 문서가 개발 준비가 완료되었음을 증명할 뿐입니다. 이러한 약속들이 실제 게임 개발 과정에서 유지될 수 있는지는 다음 세 단계에서 평가하게 됩니다.

정적 검사: 코드 품질 및 콘텐츠 품질

가상 심사관은 게임을 직접 플레이하지 않고 Skyforge Ascent의 플레이스파일을 검토했으며, 두 가지 평가 기준에 따라 서로 다른 결론을 내렸습니다.

동일한 플레이스파일을 분석한 엔지니어링 관점은 98/100점을 부여했습니다. 이 관점은 5개의 구역과 3개의 이동형 위험 요소를 갖춘 모범적인 구성을 확인했으며, 서버 기반 순차적 체크포인트, 추락 시 리셋 시스템, StyleSheet 프레임워크를 기반으로 한 UI를 통해 제작자의 의도를 완벽하게 충족시켰습니다. 사양서에 명시된 모든 요소가 구현되었습니다. 유일한 문제는 사용되지 않은 두 개의 헬퍼 함수 익스포트였습니다.

디자인 관점에서는 31/100점을 부여했습니다. 모든 기능은 정상적으로 작동했지만, 진행성, 재플레이성, 플레이어의 주도권, 독창적인 매력 요소에서는 0점을 받았습니다. 핵심 루프는 각 체크포인트에 도달하고 결승선을 통과하는 단순하고 선형적인 구조였으며, 플레이마다 다양성이 거의 없었고 다시 플레이할 이유가 없었습니다. 이는 오비(obby) 장르의 전형일 뿐, 독자적인 매력을 지닌 게임은 아니었습니다.

바로 그 차이가 핵심 발견 사항입니다. 코드 품질과 콘텐츠 품질은 근본적으로 다른 차원이며, 빌드는 한쪽에서는 거의 완벽할 수 있지만 다른 쪽에서는 실패할 수 있습니다. 단일 통합 품질 점수를 산출했다면 이 두 가지를 평균화하여 무의미한 결과만 도출했을 것입니다.

플레이 테스트

플레이테스트 에이전트는 실제 플레이어와 유사한 입력을 사용하여 게임을 플레이했으며, 테스트 계획에 포함된 9가지 항목(시작 플랫폼에서 캐릭터 생성, 틈새를 가로지르는 3D 지형 이동, 위험 요소 충돌, 체크포인트 및 자동 낙하 회복 트리거, 런 완료, 재시작)을 모두 통과했으며, 이 모든 과정에서 런타임 오류가 전혀 발생하지 않았습니다. 이번 특정 플레이에서 Skyforge Ascent는 플레이테스트에서 100/100점을 기록했습니다.

플레이테스트에서 만점을 받았다는 사실은 단순히 게임 메커니즘이 제대로 작동하며, 게임이 처음부터 끝까지 기술적으로 플레이 가능하다는 것을 증명할 뿐입니다. 이는 게임이 실제로 몰입감이 있는지, 플레이하기 재미있는지에 대해서는 아무것도 말해주지 않습니다. 바로 이러한 차이 때문에 디자인 평가 항목에서는 31점을 부여한 것입니다.

시각적 품질

마지막으로, 평가 시스템은 시각적 표현 측면에서 휴대폰 크기의 뷰포트에서 녹화된 세션을 평가했습니다. 『Skyforge Ascent』는 86/100점을 기록했습니다. 깔끔하고 일관성이 있으며, 전형적인 오비(obby) 게임의 비주얼과 자연스럽게 어우러집니다. 플랫폼 지오메트리가 명확하고, 위험 요소도 식별하기 쉬우며, 현대적이고 눈에 거슬리지 않는 HUD를 갖추고 있습니다. 사소한 시각적 한계로 인해 완벽하지는 않지만, 결함이 있는 부분은 없으며 플레이어가 스크롤을 멈추게 할 만한 요소도 없습니다.

추적 지표

동일한 플레이 세션에서 프로세스 메트릭스도 기록되었습니다. 게임 빌드에는 약 8분이 소요되었으며, 툴 오류는 전혀 발생하지 않았고, 빌드 과정에서는 3D, UI, 스크립트 편집, 에셋 삽입, 게임 오디오 기술이 사용되었습니다. 이러한 메트릭스는 평가 점수에 직접적인 영향을 미치지는 않지만, 게임이 어떻게 제작되었는지를 알려주며, 향후 이득 없이 속도가 느려지거나 비용이 증가하는 빌드가 발생할 경우 이를 경고해 줄 것입니다.

5단계에 걸쳐 ‘Skyforge Ascent’는 게임 사양, 코드 품질, 콘텐츠 품질, 플레이 테스트, 시각적 품질에서 각기 다른 점수를 받았습니다. 이 중 네 가지 측면에서는 ‘Build’가 단 하나의 프롬프트만으로 완전하고, 정확하며, 플레이 가능하고, 선보일 만한 Roblox 경험을 만들어낼 수 있음을 보여줍니다. 반면 한 가지 측면에서는 누구도 두 번 다시 플레이하고 싶어 하지 않을 게임이라는 평가를 받았습니다. 이러한 격차를 단순히 평균화하여 덮어 버리는 대신 정확히 측정하는 것이 바로 ‘Build’ 평가의 핵심입니다.

조기 평가가 Build를 어떻게 개선했는가 

평가 결과는 단순히 점수를 산출하는 데 그치지 않고, 제품 개선을 위한 실행 가능한 방향을 제시합니다. 개별 구성 요소 디버깅과 전체적인 시스템 수준 테스트를 결합하고, 표준화된 프롬프트 모음을 대상으로 한 오프라인 일괄 평가를 통해 Build의 개발 방향이 직접적으로 정립되었습니다. 

1. 알파 크리에이터의 고충을 신속하게 해결: 뉴질랜드 알파 출시 당시, 사용자들은 3D 게임을 만들고 싶었는데 Build가 때때로 2D 게임을 생성한다는 피드백을 주었습니다. 평가 프레임워크 덕분에 우리 팀은 Build의 3D 기능을 신속하게 개선할 수 있었습니다. 2주 만에, 사용자가 명시적으로 언급하지 않았더라도 3D 게임을 만들고자 하는 의도를 파악하는 Build의 능력을 향상시켰습니다. 또한 오브젝트 배치, 조명 등과 관련된 일반적인 문제를 수정하여 3D 게임의 플레이성과 완성도를 다듬었습니다. 그 이후로 전체 불만 사항 중 “원하는 것과 다르다”는 불만은 18%에서 3%로 감소했으며, 플레이 테스트 후 전반적인 불만족 반응은 10% 포인트 하락했습니다. 또한 프레임워크 자체를 반복 개선하는 과정에서 다양한 교훈을 얻었습니다. 
2. 모델 및 아키텍처 간 비교 벤치마킹: 당사는 평가 프레임워크를 활용하여 표준화된 프롬프트 모음을 기준으로 빌드 시스템 구성을 엄격하게 벤치마킹합니다. 변경 사항을 프로덕션에 배포하기 전에, 오프라인 A/B 평가 보고서를 통해 후보 릴리스를 당사의 프로덕션 기준선과 다음 네 가지 차원에서 비교합니다: 

예를 들어, 이러한 오프라인 차이점 분석을 통해 다양한 모델 업그레이드와 에이전트 라우팅 결정이 개별 품질 지표에 어떤 영향을 미치는지 파악할 수 있습니다:

• 기본 모델 성능: 기본 모델을 업그레이드함으로써 모든 지표에서 일관된 성능 향상을 달성했으며, 그 결과 첫 시도에서 빌드 오류가 줄어들고, 시각적 완성도가 향상되었으며, 게임플레이 콘텐츠의 깊이가 더해졌습니다.
• 에이전트 라우팅 아키텍처: 반대로, 듀얼 에이전트 구성에서 특정 하위 작업을 경량 모델에 위임하면 콘텐츠의 깊이와 다양성은 유지되었지만, 플레이 가능성과 시각적 완성도에서 급격한 성능 저하가 발생했습니다.

1. 제작 패러다임 전반에 걸친 품질 기준선 추적: 또한 이 프레임워크를 활용하여 가장 관련성 높은 평가 세트를 통해 다양한 시점에서 빌드의 현재 품질을 파악합니다. 이러한 세트들은 점차 광범위하고 복잡해지는 제작 작업의 단면을 보여줍니다.
   가장 초기의 세트는 비교적 단순한 메커니즘을 가진 순수 2D 게임으로 구성되어 있습니다. 게임 로직을 구축하기 쉬웠기 때문에 플레이테스트 점수는 높은 편이었으나, 정반대로 콘텐츠 점수는 정확히 같은 이유로 낮은 수준을 유지했습니다.
   3D 게임으로 초점을 옮기면 점수 분포가 자연스럽게 변화합니다. 버그 없는 플레이를 구현하기가 더 어려워져 플레이테스트 점수가 낮아집니다. 자산의 완성도가 부족하여 시각적 점수는 정체된 상태를 유지하며, 게임에 프로토타입 같은 느낌을 줍니다. 3D 게임은 더 깊은 내용을 담을 잠재력이 있어 콘텐츠 점수는 더 높지만, 단일 턴 프롬프트는 콘텐츠 확장의 여지가 제한적이기 때문에 전체 점수는 낮은 편을 유지하는 경향이 있습니다.

1. 장르별 병목 현상 파악: 평가 데이터는 장르 간 상당한 성능 차이를 보여줍니다. 플레이 메커니즘이 복잡한 장르(예: RPG, 슈팅 게임, 레이싱 게임)일수록 플레이성 문제가 더 많이 발생하는 경향이 있습니다. 논리가 비교적 단순한 장르(예: 서바이벌 및 타이쿤 게임)는 플레이 테스트에서 종종 더 나은 성과를 보이며, 이로 인해 시각적 완성도와 UI 디자인이 해결해야 할 다음 과제가 됩니다. 장르 간의 차이를 파악함으로써, 우리는 Build 게임 전반에 걸쳐 보다 균형 잡힌 표본을 확보하여 평가 세트를 확대할 동기를 얻게 됩니다.
2. 평가를 통해 얻은 교훈: 프레임워크 자체를 반복 개선하는 과정에서 하네스 신뢰성에 대한 중요한 교훈을 얻었습니다:

• 시스템 지표 대 구성 요소 지표: 깔끔한 코드 구조나 API 사용만으로는 플레이 가능한 게임을 보장할 수 없습니다. 우리는 수정 가능한 버그가 숨겨지는 것을 방지하기 위해 정확성, 설계, 표현을 명확히 구분합니다.
• 하네스의 약점과 인간에 의한 보정: 정적 검사만으로는 게임이 중단되는 런타임 차단 요인을 놓칠 수 있으며, 자동화된 플레이 테스트는 복잡한 물리 시뮬레이션을 처리하는 데 어려움을 겪습니다. 가상 심사위원은 전문 게임 개발자와 경험 많은 커뮤니티 리뷰어를 기준으로 지속적으로 보정됩니다.
• 다중 턴 및 실제 트래픽으로의 확장: 실제 제작자들은 지속적으로 반복 작업(시스템 추가, 난이도 조정, 버그 수정)을 수행하기 때문에, 저희는 다중 턴 편집과 실제 프롬프트 분포를 평가할 수 있도록 평가 하네스를 확장하고 있습니다.

향후 계획

현재 저희는 ‘Build’ 창작 평가 시스템을 다음 다섯 가지 방향으로 확장하는 데 주력하고 있습니다:

1. 장르, 2D/2.5D/3D 경험, 멀티플레이어 시나리오, 복잡도 단계에 걸친 더 광범위한 커버리지
2. 다단계 편집에 대한 지원 강화
3. 더 신뢰할 수 있는 플레이 테스트, 스크린샷, 동영상 및 오디오 증거
4. 대규모 인간 평가와의 보정 및 크리에이터 주도 벤치마크 사례
5. 오프라인 평가, 온라인 제품 신호, 회귀 테스트 간의 원활한 통합

저희의 장기적인 목표는 크리에이터들이 중요하게 여기는 수준, 즉 그들이 제작하고, 테스트하고, 공유하며 지속적으로 개발해 나갈 수 있는 경험의 품질을 측정하는, 투명하고 지속적으로 개선되는 평가 시스템을 구축하는 것입니다. 현재 이러한 신호들은 Build가 생성한 게임을 평가하는 데 사용되고 있습니다. 시간이 지남에 따라 이를 더욱 정교화하고 인간의 판단 기준에 맞춰 보정해 나감에 따라, 이러한 시스템은 다른 창작 워크플로우로도 일반화될 수 있으며, 더 넓은 Roblox 생태계 전반에서 게임 품질을 이해하기 위한 공통된 언어를 제공하는 데 기여할 것입니다.

Roblox Assistant의 에이전트 기반 시스템 평가에 대한 관련 내용은 ‘OpenGameEval을 활용한 Roblox Studio용 에이전트 기반 AI 어시스턴트 벤치마킹’을 참조하십시오.