Roblox가 2026년 6월 22일 공식 DevForum을 통해 “Convert Your Game to Streaming Using AI” early preview를 공개했습니다. 이름만 보면 작은 편의 기능처럼 보일 수 있지만, 실제 내용은 꽤 큽니다. 기존에 Instance Streaming을 쓰지 않던 게임을 AI 스킬이 분석하고, Workspace 설정, 모델 스트리밍 모드, LOD 설정, 스크립트의 WaitForChild 처리, nil 체크, 공간 질의, replication focus 같은 부분을 자동으로 손보는 흐름이기 때문입니다.
이건 단순히 “AI가 최적화 버튼을 눌러준다”는 이야기가 아닙니다. 게임 구조를 바꾸고, 런타임 로딩 방식에 영향을 주고, 플레이어가 보는 월드의 범위와 타이밍을 바꾸는 작업입니다. Roblox는 공식 글에서 이 기능이 large code refactorizations를 다루는 초기 단계라고 설명했고, 반드시 게임의 복사본에서 실행하라고 강조했습니다. 그 말은 개발자 입장에서 아주 중요합니다. AI가 시간을 아껴줄 가능성은 있지만, 자동 변경이 곧 안전한 변경이라는 뜻은 아니기 때문입니다.
이번 글은 Roblox 기능 소개라기보다, “AI가 프로젝트 최적화를 대신 고치는 시대에 팀은 무엇을 검사해야 하는가”를 보는 리스크 분석에 가깝습니다. Roblox 개발자가 아니더라도 읽을 만합니다. Unreal, Unity, Godot, 자체 엔진 어디서든 AI 에이전트가 프로젝트 설정과 코드, 에셋 구조를 만지는 흐름은 점점 늘어날 가능성이 높습니다. 그러면 개발자, 디자이너, 테크니컬 아티스트, VFX 아티스트 모두 같은 질문을 하게 됩니다. 이 자동화가 시간을 줄여주는가, 아니면 보이지 않는 제작 부채를 다른 곳으로 옮기는가.
1. 이번 기능은 최적화 도구이면서 프로젝트 구조 변경 도구입니다
Roblox의 primary source에서 가장 먼저 봐야 할 문장은 Instance Streaming이 non-streaming game을 최적화하는 좋은 방법이지만, 기존 게임을 바꾸는 과정은 지루하고 수동적인 작업이 될 수 있다는 설명입니다. 여기서 AI 스킬의 목적이 나옵니다. 이미 완성돼 있거나 오래 운영된 경험을 streaming-ready 상태로 전환할 때 반복적으로 확인해야 하는 설정과 코드 패턴을 자동화하겠다는 것입니다.
Instance Streaming은 플레이어 주변에 필요한 인스턴스만 클라이언트에 보내고, 멀리 있거나 당장 필요하지 않은 영역은 상황에 따라 늦게 보내거나 내보내는 방식입니다. Creator Hub의 streaming 문서도 이 기능이 load time, memory, server workload, device coverage에 직접 연결된다는 식으로 설명합니다. 낮은 사양 기기까지 플레이 가능 범위를 넓히려는 Roblox 게임에서는 꽤 실질적인 의미가 있습니다.
문제는 전환 비용입니다. 새 프로젝트에서 처음부터 streaming을 고려하는 것과, 이미 수많은 모델과 스크립트가 얽힌 게임을 나중에 바꾸는 것은 다릅니다. 어떤 모델은 통째로 들어와야 하고, 어떤 모델은 부분적으로 들어와도 됩니다. 어떤 스크립트는 월드 오브젝트가 항상 존재한다고 가정합니다. 어떤 UI나 상호작용은 특정 파트가 클라이언트에 없을 때 nil이 되는 상황을 고려하지 않았을 수 있습니다.
Roblox가 공개한 AI 스킬은 바로 이 지점을 건드립니다. Workspace streaming 설정을 권장값으로 맞추고, 모델 내용을 평가해 ModelStreamingMode를 적용하고, SLIM LOD를 설정하고, 모델 구조를 나누거나 묶고, 필요한 WaitForChild와 nil 체크를 넣고, streaming 환경에서 다르게 동작할 수 있는 client-side spatial query를 찾는다고 설명합니다. 말하자면 성능 버튼 하나가 아니라, 제작 데이터와 코드의 전제를 바꾸는 자동 리팩터링입니다.
게임 팀 입장에서는 이 차이를 분명히 해야 합니다. 최적화는 보통 “더 빠르게 만들기”로만 말해지지만, 실제로는 “게임이 언제 무엇을 존재한다고 믿어도 되는지”를 다시 정의하는 일입니다. 특히 디자이너와 아티스트가 만든 월드 구조, 퀘스트 트리거, 연출 오브젝트, VFX 스폰 지점, UI 안내, 사운드 발동 조건이 스트리밍과 맞물려 있으면 자동 변경의 영향 범위가 생각보다 커질 수 있습니다.
2. 장점은 분명합니다: 큰 월드 최적화의 진입 장벽을 낮춥니다
이 기능을 너무 경계만 할 필요는 없습니다. Roblox가 이 스킬을 만든 이유는 명확합니다. 많은 팀이 streaming의 장점을 알지만, 기존 게임에 적용하는 과정이 부담스러워 미루기 쉽기 때문입니다. 특히 라이브 서비스 성격의 Roblox 경험은 콘텐츠가 계속 쌓입니다. 플레이어가 늘어나고, 맵이 커지고, 장식과 상호작용이 붙고, 어느 순간 처음 설계한 로딩 구조가 현재 규모를 감당하지 못하게 됩니다.
그때 streaming은 매력적인 선택입니다. 플레이어 주변 중심으로 월드를 보내면 초기 로딩이 줄고, 클라이언트 메모리 사용량을 낮출 수 있고, 저사양 기기에서의 접근성을 키울 수 있습니다. 플레이어 입장에서는 게임이 더 빨리 열리고, 갑자기 튕길 가능성이 낮아지고, 큰 월드도 모바일 기기에서 더 견딜 만해질 수 있습니다. 개발자 입장에서는 같은 콘텐츠를 더 넓은 기기군에 배포할 수 있으니 운영 지표와 수익화에도 영향을 줍니다.
테크니컬 아티스트와 환경 아티스트에게도 의미가 있습니다. 월드가 커질수록 “멋진 배경을 얼마나 멀리까지 보여줄 것인가”와 “그 배경을 실제 오브젝트로 얼마나 오래 들고 있을 것인가”는 다른 문제가 됩니다. Instance Streaming과 LOD, model streaming control이 잘 맞으면 멀리 보이는 실루엣과 플레이 가능한 디테일을 나눠 생각할 수 있습니다. 플레이어가 지금 밟고 있는 공간에는 충분한 상호작용을 주고, 멀리 있는 공간은 낮은 비용으로 분위기만 유지하는 식입니다.
AI 스킬의 장점은 이 판단을 처음 시작하는 비용을 낮춘다는 데 있습니다. 기존 프로젝트를 사람이 전부 훑으려면 모델 구조, 스크립트 참조, ReplicatedStorage와 Workspace의 경계, StreamingEnabled 설정, 모델별 모드, replication focus 후보, 테스트 로그를 계속 오가야 합니다. 자동화가 “일단 어디가 위험한지 찾아주고, 권장 변경을 적용하고, 로그를 남기는” 역할을 해준다면 작은 팀에는 꽤 큰 도움이 됩니다.
또 하나의 장점은 교육 효과입니다. 팀원이 streaming을 잘 모르는 상태에서도 스킬이 어떤 파일과 모델을 건드렸는지 로그로 남긴다면, 그것 자체가 학습 자료가 됩니다. 왜 이 모델은 Atomic이 필요한지, 왜 어떤 참조에는 WaitForChild가 들어갔는지, 왜 특정 위치에 prefetch나 replication focus가 필요한지 회의에서 이야기할 수 있습니다. 잘 쓰면 AI가 최종 책임자가 아니라, 성능 전환 리뷰를 시작하게 만드는 조수 역할을 하게 됩니다.
3. 하지만 자동 리팩터링은 플레이 감각을 망가뜨릴 수도 있습니다
Roblox가 공식 글에서 복사본 실행을 강하게 권한 이유는 당연합니다. 자동 리팩터링은 편하지만, 게임의 재미를 이해하지는 못합니다. AI가 안전하다고 판단한 모델 분리나 스크립트 수정이 기술적으로는 맞아도, 플레이어 경험에서는 어색할 수 있습니다. 특히 월드의 등장 타이밍, 전투 중 시야 확보, 숨겨진 오브젝트의 발견감, 퀘스트 연출, 보스전 사전 신호처럼 감각적인 요소는 단순 정적 분석만으로 판단하기 어렵습니다.
예를 들어 공포 게임에서 멀리 있는 문, 그림자, 소품이 특정 타이밍에 보여야 긴장감이 생긴다고 해보겠습니다. 스트리밍 전환 과정에서 그 오브젝트가 플레이어 주변 거리 기준으로만 늦게 들어오면, 연출은 기술적으로 정상이어도 감정적으로 깨질 수 있습니다. 반대로 전투 게임에서 보스 공격의 경고 이펙트나 바닥 표시가 늦게 들어오면, 플레이어는 공격을 읽지 못하고 맞았다고 느낄 수 있습니다.
VFX 쪽에서는 더 직접적입니다. 이펙트는 독립된 장식이 아니라 게임 이벤트의 언어입니다. 히트 확인, 위험 구역, 상호작용 가능성, 스킬 쿨다운, 환경 변화가 이펙트로 전달됩니다. 자동화가 모델 구조나 replication focus를 바꾸면서 이벤트 발생 위치와 클라이언트 존재 여부가 달라지면, VFX가 제때 뜨지 않거나 엉뚱한 순간에 보일 수 있습니다. 플레이어는 이걸 “스트리밍 문제”라고 이해하지 않습니다. 그냥 게임 피드백이 이상하다고 느낍니다.
스크립트 수정도 위험합니다. WaitForChild와 nil 체크를 추가하는 것은 streaming 환경에서 필요한 방어 코드일 수 있습니다. 하지만 모든 nil을 조용히 무시하도록 바꾸면 진짜 버그가 숨을 수 있습니다. 원래는 특정 오브젝트가 반드시 있어야 하는 설계였는데, 자동 수정 후에는 없으면 넘어가게 된다면 QA가 더 어려워질 수 있습니다. 에러가 줄어든 것처럼 보이지만, 실제로는 게임 상태가 조용히 틀어지는 상황이 생깁니다.
그래서 이 스킬은 “한 번 실행하고 끝”으로 쓰면 안 됩니다. 실행 전후 diff를 보고, 변경된 설정과 스크립트를 사람이 이해해야 합니다. 특히 핵심 루프, 결제 또는 보상, 진행 저장, 매치 시작과 종료, 보스전, 튜토리얼, 이동 수단, 장거리 텔레포트, 연출 구간은 별도 테스트 케이스로 잡아야 합니다. AI가 변경을 만들 수는 있지만, 그 변경이 게임의 약속을 지키는지는 팀이 판단해야 합니다.
4. 팀에서 쓰려면 복사본, diff, 플레이테스트 순서를 고정해야 합니다
이 기능을 실제 팀에 도입한다면 가장 먼저 필요한 것은 사용 순서입니다. “궁금하니까 한번 돌려보자”는 접근은 위험합니다. Roblox 글 자체도 게임 복사본에서 실행하라고 말합니다. 저는 이걸 더 강하게 해석하는 편이 좋다고 봅니다. 라이브 프로젝트가 아니라 복사본에서 실행하고, 실행 전 상태를 버전 관리나 별도 백업으로 고정하고, 스킬이 만든 변경을 사람이 검토할 수 있는 단위로 나눠야 합니다.
첫 번째 체크는 구조 diff입니다. 어떤 모델이 나뉘었는지, 어떤 모델이 묶였는지, 어떤 ModelStreamingMode가 적용됐는지 봐야 합니다. Creator Hub의 ModelStreamingMode 문서를 보면 Atomic, Persistent, PersistentPerPlayer, Nonatomic 같은 모드가 각각 다른 stream in/out 의미를 갖습니다. 이건 단순 옵션이 아닙니다. 어떤 오브젝트가 플레이어에게 언제 complete unit으로 들어오는지, 절대 stream out되지 않는지, 특정 플레이어에게만 persistent하게 남는지 결정합니다.
두 번째 체크는 코드 diff입니다. 자동으로 들어간 WaitForChild, nil 체크, prefetch, replication focus 관련 변경을 훑어야 합니다. 이때 “에러가 안 나게 됐다”보다 중요한 질문은 “이 오브젝트가 없어도 게임이 진행돼도 되는가”입니다. 없어도 되는 경우라면 방어 코드가 맞습니다. 반드시 있어야 하는 경우라면, nil 체크로 조용히 넘어가는 것이 아니라 로딩 상태를 보여주거나, 재시도하거나, 오류를 개발 로그로 확실히 남겨야 합니다.
세 번째 체크는 제작 파트별 플레이테스트입니다. 프로그래머만 테스트하면 코드 오류는 찾지만, 연출과 감각 문제를 놓칠 수 있습니다. 디자이너는 퀘스트와 전투 흐름을 봐야 하고, 아티스트는 월드가 늦게 나타나는 구간과 배경 실루엣을 봐야 하고, VFX 아티스트는 위험 신호와 보상 피드백이 제때 보이는지 봐야 합니다. QA는 저사양 기기, 느린 네트워크, 빠른 이동, 반복 텔레포트, 부활, 팀 플레이 같은 스트리밍 취약 상황을 따로 잡아야 합니다.
네 번째 체크는 rollback 계획입니다. 자동화는 보통 많은 파일과 설정을 한 번에 만집니다. 문제가 생겼을 때 전체를 되돌릴 수 있어야 합니다. 더 좋은 방식은 스킬의 변경을 몇 개 묶음으로 나누는 것입니다. Workspace 설정, 모델 모드, 스크립트 방어 코드, replication focus, LOD 또는 SLIM 관련 변경을 각각 검토할 수 있으면 팀이 더 침착하게 판단할 수 있습니다. 이 과정을 생략하면 “성능은 좋아졌는데 왜 게임이 어색해졌는지 모르겠다”는 상황이 옵니다.
5. 이번 주 Roblox 업데이트 흐름을 보면 관찰성과 자동화가 같이 가고 있습니다
이 주제를 primary source 하나로만 보면 AI 스킬 이야기로 끝나지만, 2026년 6월 26일 Roblox Weekly Recap까지 같이 보면 조금 더 큰 흐름이 보입니다. 같은 주 Roblox는 Convert to Streaming Skill 외에도 LibMP MicroProfiler API beta, Next-Gen Draggers beta, UIShadow와 individual corner rounding full release, terrain early access program 등을 함께 언급했습니다. 하나의 roundup을 하려는 것은 아니지만, 방향성은 분명합니다. 제작 자동화, 성능 관찰, 편집 도구 개선, 월드 규모 확장이 동시에 움직이고 있습니다.
특히 LibMP는 이 글의 중요한 보조 맥락입니다. 2026년 6월 25일 DevForum에 공개된 LibMP MicroProfiler API는 MicroProfiler 데이터를 Luau API로 접근할 수 있게 하는 beta입니다. Roblox는 custom profiling widgets, client/server analytics, snapshots, offline analysis 같은 사용 사례를 언급했습니다. 이것은 AI 스트리밍 전환과 잘 맞물립니다. 자동 변경이 많아질수록, “바뀌었으니 좋아졌겠지”가 아니라 “실제로 frame, memory, client/server behavior가 어떻게 달라졌는지”를 더 쉽게 봐야 하기 때문입니다.
AI 자동화와 관찰성은 세트로 가야 합니다. 자동화만 있고 관찰성이 없으면 팀은 변경 결과를 느낌으로 판단하게 됩니다. 반대로 관찰성만 있고 자동화가 없으면 문제는 보이지만 수정 비용이 너무 커서 계속 밀립니다. Roblox가 같은 주에 AI 전환 스킬과 MicroProfiler API를 각각 보여준 것은, 의도했든 아니든 꽤 좋은 조합입니다. 하나는 변경을 만들고, 다른 하나는 변경 후 결과를 측정할 수 있는 길을 넓힙니다.
게임 개발 전체로 보면 이 흐름은 Unreal이나 Unity 팀에도 낯설지 않습니다. 요즘 엔진과 툴은 점점 더 많은 진단 정보를 내고, AI 에이전트는 그 정보를 읽고 수정을 제안하려 합니다. 하지만 최종 품질은 여전히 팀의 검증 루프에 달려 있습니다. “AI가 고쳤다”는 말보다 “AI가 고친 뒤 어떤 지표와 플레이테스트로 확인했다”는 말이 훨씬 중요해질 것입니다.
아트와 디자인팀도 이 흐름에 들어와야 합니다. 성능 지표는 프로그래머만 보는 숫자가 아닙니다. 어떤 배경이 stream out되었는지, 어떤 장면이 memory budget을 잡아먹는지, 어떤 VFX가 낮은 기기에서 과한지, 어떤 UI가 클라이언트 로딩 상태를 잘못 감추는지 모두 제작 판단과 연결됩니다. 좋은 자동화는 파트를 갈라놓는 것이 아니라, 각 파트가 같은 상태를 보고 이야기하게 만들어야 합니다.
6. 포트폴리오와 교육 콘텐츠로 만들 때의 좋은 각도
이런 소식은 블로그나 유튜브 교육 콘텐츠로도 꽤 좋습니다. 단순히 “Roblox에 AI 최적화 스킬이 나왔다”라고 소개하면 금방 끝납니다. 하지만 실제 제작자에게 필요한 건 사용법보다 판단법입니다. 어느 프로젝트에 적용하면 좋고, 어떤 프로젝트에서는 위험하며, 실행 후 무엇을 확인해야 하는지를 보여주면 콘텐츠 가치가 훨씬 커집니다.
포트폴리오 관점에서도 흥미로운 과제를 만들 수 있습니다. 예를 들어 작은 Roblox 경험을 하나 준비하고, streaming off 상태와 streaming on 상태를 비교합니다. 그다음 AI 스킬이 제안한 변경을 적용한 버전, 사람이 수동으로 다듬은 버전, 핵심 연출 구간을 보호한 버전을 나눠 보여주는 방식입니다. 결과 화면만 보여주는 것보다 memory, load time, object pop-in, VFX timing, player path 테스트를 함께 기록하면 훨씬 설득력이 있습니다.
VFX 아티스트라면 “스트리밍 환경에서 안전한 이펙트 설계”를 주제로 잡을 수 있습니다. 위험 표시가 월드 오브젝트에 의존하는 경우와 UI 또는 locally generated feedback에 의존하는 경우를 비교해볼 수 있습니다. 보상 이펙트가 서버 오브젝트 로딩에 묶였을 때 늦게 보이는 문제, 클라이언트에서 생성한 이펙트가 stream out과 무관하게 보이는 장점, 중요한 전투 신호를 persistent 모델이나 별도 replication focus와 어떻게 연결할지 같은 내용을 보여주면 실제 게임 제작자에게 도움이 됩니다.
디자이너라면 “스트리밍 전환 체크리스트”를 만들 수 있습니다. 빠른 이동 수단이 있는가, 플레이어가 멀리 있는 목표를 조준하거나 관찰하는가, 장거리 퍼즐이 있는가, 팀원이 서로 떨어져서 플레이하는가, 부활 지점이 여러 개인가, 특정 오브젝트가 항상 존재한다고 가정하는 퀘스트가 있는가 같은 질문입니다. 이런 리스트는 Roblox뿐 아니라 open world, multiplayer, mobile optimization을 다루는 어떤 엔진 글에도 활용할 수 있습니다.
개발자라면 자동화 도입 전후의 diff review workflow를 보여주는 것이 좋습니다. AI가 만든 코드 수정 중 어떤 것은 받아들이고, 어떤 것은 사람이 고쳤는지 기록하면 AI 시대의 실무 역량을 잘 보여줄 수 있습니다. 앞으로 포트폴리오에서 “AI를 썼다”는 말보다 “AI 변경을 검토하고 품질 게이트를 설계했다”는 증거가 더 중요해질 가능성이 큽니다.
7. 사용 여부를 결정하는 짧은 판단표
이 기능을 지금 써도 되는지 판단하려면, 먼저 프로젝트 상태를 봐야 합니다. 아직 프로토타입이거나, 월드 구조가 비교적 단순하거나, streaming 적용 전후를 마음껏 비교할 수 있는 팀이라면 early preview를 실험할 가치가 있습니다. 특히 기존 게임이 커졌고 낮은 사양 기기 대응이 중요해졌다면, AI 스킬은 시작점을 만들어줄 수 있습니다.
반대로 라이브 이벤트 직전, 저장/보상/결제 흐름이 복잡한 프로젝트, scripted sequence가 많은 프로젝트, 특정 오브젝트 존재 타이밍에 의존하는 게임, QA 여력이 없는 팀이라면 조심해야 합니다. 이 경우 자동 변경을 바로 통합하지 말고, 별도 브랜치나 복사본에서 분석 결과만 참고하는 편이 낫습니다. AI가 무엇을 바꾸려 하는지 보는 것만으로도 충분히 유용할 수 있습니다.
팀 회의에서는 세 가지 질문으로 정리할 수 있습니다. 첫째, 우리가 streaming 전환으로 얻고 싶은 명확한 목표가 있는가. 예를 들어 mobile crash 감소, join time 단축, memory peak 감소처럼 확인 가능한 목표가 있어야 합니다. 둘째, 자동 변경 후 핵심 플레이 루프를 테스트할 사람이 있는가. 셋째, 문제가 생겼을 때 변경을 되돌리거나 부분 적용할 계획이 있는가.
이 세 가지가 없으면 AI 스킬은 위험합니다. 목표가 없으면 결과가 좋아졌는지 판단할 수 없고, 테스트가 없으면 플레이 감각이 망가져도 늦게 알게 되고, rollback이 없으면 팀이 자동 변경에 끌려가게 됩니다. 반대로 이 세 가지가 있으면 early preview라도 꽤 생산적으로 써볼 수 있습니다.
개인적으로는 이 소식이 반갑습니다. AI가 게임 개발에서 정말 도움이 되는 지점은 “아이디어를 대신 내는 것”보다, 오래된 프로젝트를 현실적인 품질 기준까지 끌어올리는 반복 작업을 줄이는 쪽에 있다고 보기 때문입니다. 다만 그 반복 작업은 플레이어가 느끼는 세계와 붙어 있습니다. 그래서 자동화는 더 과감해질수록, 검증은 더 구체적이어야 합니다.
AI가 게임 최적화를 대신 고쳐줄 때: Roblox 스트리밍 전환 스킬을 조심해서 써야 하는 이유 작업 메모
Roblox의 Convert Your Game to Streaming Using AI early preview는 AI 개발 도구가 어디로 가고 있는지 잘 보여줍니다. 앞으로 AI는 단순한 코드 조각을 넘어, 엔진 설정, 에셋 구조, 런타임 로딩, 성능 패턴까지 건드릴 것입니다. 그것은 좋은 소식이지만, 동시에 팀의 책임이 사라진다는 뜻은 아닙니다.
게임 개발자에게 필요한 태도는 “AI를 믿을 것인가 말 것인가”가 아닙니다. 더 현실적인 질문은 “AI가 바꾼 것을 어떤 기준으로 받아들일 것인가”입니다. 복사본에서 실행하고, diff를 읽고, 핵심 루프를 플레이테스트하고, MicroProfiler나 로그로 결과를 확인하고, 아트와 VFX 타이밍까지 같이 보는 팀만이 이런 자동화를 안전하게 자기 워크플로우로 가져갈 수 있습니다.
게이머 입장에서는 이런 변화가 잘 보이지 않을 수 있습니다. 하지만 잘 적용되면 더 빠르게 열리고, 덜 끊기고, 낮은 기기에서도 더 안정적인 게임으로 느껴질 것입니다. 반대로 잘못 적용되면 오브젝트가 늦게 나타나고, 이펙트가 어긋나고, 월드가 빈틈 있게 느껴질 수 있습니다. 결국 AI 최적화의 성공 여부는 모델의 똑똑함보다 플레이어가 실제로 느끼는 안정감으로 판단됩니다.
VFX Diary 관점에서는 이 흐름을 계속 볼 가치가 있습니다. AI가 제작 파이프라인 안으로 깊게 들어올수록, 기술 아티스트와 VFX 아티스트는 “멋진 화면”뿐 아니라 “언제 로딩되고, 언제 복제되고, 언제 사라져도 안전한가”까지 함께 설계해야 합니다. 자동화가 강해질수록 실무자는 더 넓은 시스템 감각을 가져야 합니다.
참고 출처
- Roblox DevForum – Early Preview: Convert Your Game to Streaming Using AI – published 2026-06-22
- Roblox Creator Hub – Instance Streaming
- Roblox Creator Hub – ModelStreamingMode
- Roblox DevForum – Weekly Recap: June 22 – 26, 2026 – published 2026-06-26
- Roblox DevForum – Studio Beta: Introducing LibMP, the MicroProfiler API – published 2026-06-25