메타버스 구축 - 동시성 인프라
기본적인 수준에서 볼 때 수백 명의 사람들이 동기화된 공유 경험에 참여하는 것은 고사하고 아직 기술이 존재하지 않습니다. 포트나이트의 2019 마쉬멜로 콘서트를 생각해보세요. 놀라운 11MM 사람들이 실시간으로 그 행사를 경험했습니다. 하지만, 그들은 함께 그렇게 하지 않았습니다. 실제로 마쉬멜로 콘서트는 10만 건이 넘었는데, 모두 약간 동조화가 안 되고 한 건당 100명씩으로 상한선이 정해졌습니다. 에픽은 오늘날 이것보다 더 많은 것을 할 수 있을 것입니다. 하지만 수백만이 아니라 수백만이 될 수도 없습니다. 메타버스는 현재 존재하지 않는 인프라를 필요로 할 뿐만 아니라, 인터넷은 이러한 경험에 가까운 어떤 것도 위해 설계된 적이 없습니다. 결국, 그것은 한 컴퓨터에서 다른 컴퓨터로 파일을 공유하도록 설계되었습니다. 그 결과, 인터넷의 대부분의 기본 시스템은 한 서버가 다른 서버 또는 최종 사용자 기기와 통신하는 것을 중심으로 합니다. 이 모델은 오늘도 계속됩니다. 예를 들어, 오늘날의 페이스북에는 수십억 명의 사람들이 있지만, 각각의 사용자는 다른 사용자가 아닌 페이스북 서버와 개별적인 연결을 공유합니다. 따라서, 당신이 다른 사용자의 컨텐츠에 접속할 때, 당신은 페이스북이 당신에게 제공하는 최신 정보를 가져오는 것입니다. 의사 동기화 프로그램의 가장 초기 형태는 문자 채팅이었지만 여전히 정적 데이터를 서버로 밀어넣고 필요할 때, 장소, 방법, 필요에 따라 최신 정보를 가져옵니다. 인터넷은 수많은 다른 사람들과 정확한 실시간으로 동기화된 지속적인 의사소통은 고사하고 지속적인 의사소통을 위해 설계되지 않았습니다. 메타버스는 비디오 회의나 비디오 게임에 더 가까운 것을 필요로 합니다. 이러한 경험은 실시간으로 서로를 업데이트하는 지속적인 연결과 다른 프로그램에서 일반적으로 필요하지 않은 수준의 정확도로 인해 작동합니다. 그러나 대부분의 비디오 채팅 프로그램은 몇 명을 넘어 최대치를 기록하고 50이 되면 양방향 연결을 공유하기보다는 시청자에게 방송을 "라이브 스트림"해야 하는 경향이 있습니다. 이 경험들은 꼭 살아있을 필요도 없고 실제로 살아있을 필요도 없습니다. 이를 위해, 배틀로얄 장르가 비디오 게임에서 최근에야 인기 있는 이유 중 일부는 다른 수많은 사용자들과 라이브로 플레이하는 것이 최근에야 가능하기 때문입니다. 비록 Second Life나 Warcraft와 같이 가장 높은 동시 통화의 일부 게임들이 20년 이상 존재했지만, 그들은 근본적으로 사용자들을 다른 "세계"와 서버로 분할하여 경험을 스푸핑했습니다. 예를 들어, Eve Online은 기술적으로 10만 명 이상의 플레이어를 "한 게임"에 포함할 수 있지만, 그것들은 다른 은하들(즉, 서버 노드)로 나뉘어 있습니다. 그 결과, 한 플레이어는 실제로 한 번에 소수의 다른 플레이어를 보거나 플레이어와 상호 작용합니다. 게다가, 다른 은하로 여행하는 것은 하나의 서버로부터 연결을 끊고 다른 서버를 로딩하는 것을 의미합니다 (게임이 광대한 공간을 건너기 위해 플레이어들에게 광속으로 점프하도록 강요함으로써 서술적으로 "숨길" 수 있습니다). 그리고 이브 온라인(Eve Online)이 수백 명의 사용자와 전투를 벌이게 되면 시스템이 서서히 느려졌습니다. 그리고 이것은 게임플레이의 역동성이 주로 대규모의 사전 계획된 함선에 기반을 두었기 때문에 여전히 효과가 있었습니다. 로켓 리그나 콜 오브 듀티와 같은 "패스트 트위치" 게임이었다면 이러한 속도 저하는 할 수 없었을 것입니다. 임팩터블이라는 적절한 이름을 가진 이 문제를 해결하기 위해 많은 회사들이 열심히 일하고 있습니다. 그러나 이것은 엄청난 컴퓨터 도전이며 인터넷의 근본적인 디자인/의도와 맞서 싸우는 문제입니다.
메타버스 구축 -표준, 프로토콜 채택
오늘날 우리가 경험하는 인터넷은 시각적인 표현, 파일 로딩, 통신, 그래픽, 데이터 등을 위한 표준과 프로토콜 때문에 작동합니다. 여기에는 소비자가 인식할 수 있는 것부터 모든 것이 포함됩니다.GIFs filetypes는 브라우저와 인터넷의 다른 서버 간의 거의 모든 실시간 통신의 기초가 되는 웹 소켓 프로토콜에 대한 파일 형식입니다. 메타버스는 더 광범위하고, 더 복잡하고, 탄력적인 S&P 세트를 필요로 할 것입니다. 또한 상호 운용성과 실시간 동기화 경험의 중요성으로 인해 일부 기존 표준을 제거하고 기능별로 더 작은 세트를 중심으로 "표준화"해야 합니다. 예를 들어, 오늘날에는 다양한 이미지 파일 형식이 있습니다.GIF, .JPEG, .PNG, .BMP, .입니다.TIFF, .WEBP 등이 있습니다. 또한 오늘날 웹은 개방형 표준을 기반으로 구축되지만, 웹의 대부분은 폐쇄적이고 독점적입니다. 아마존과 페이스북, 구글은 비슷한 기술을 사용하지만, 포드의 바퀴가 GM의 섀시에 맞게 설계되지 않은 것처럼 서로 전환되도록 설계되지는 않았습니다. 또한 이러한 기업은 시스템을 교차 통합하거나 데이터를 공유하는 데 매우 저항적입니다. 이러한 움직임은 "디지털 경제"의 전반적인 가치를 높일 수 있지만, 또한 초가치 네트워크 효과를 약화시키고 사용자가 디지털 라이프를 다른 곳으로 이동하기 쉽게 만듭니다. 이것은 엄청나게 어렵고 수십 년이 걸릴 것입니다. 또한 Metaverse의 가치와 상호 운용성이 높을수록 데이터 보안, 데이터 지속성, 호환 가능한 코드 진화 및 트랜잭션과 같은 주제에 대한 업계 전반의 합의를 도출하기가 어려워집니다. 게다가, 메타버스는 검열, 통신 통제, 규제 집행, 세금 보고, 온라인 급진화 방지, 그리고 오늘날 우리가 여전히 어려움을 겪고 있는 더 많은 도전들을 위해 완전히 새로운 규칙들을 필요로 할 것입니다. 표준 제정에는 보통 실제 회의, 협상 및 토론이 수반되지만, 메타버스에 대한 표준은 미리 확립되지 않을 것입니다. 표준 프로세스는 회의와 의견이 즉흥적으로 변경되는 등 훨씬 더 복잡하고 유기적입니다. 메타버스에 메타비유를 사용하려면 심시티를 고려하십시오. 이상적인 상황에서는 "Marker"(즉, 플레이어)가 먼저 메가 메트로폴리스를 설계한 다음 첫날부터 이 최종 비전까지 건설합니다. 그러나 실제 생활과 마찬가지로 게임에서도 10MM 인력의 도시를 "만들" 수는 없습니다. 처음에는 작은 마을부터 시작하여 그 마을에 맞게 최적화합니다(예: 도로, 학교, 공공시설 용량 등). 그것이 성장함에 따라, 당신은 때때로 그러나 현명하게 오래된 "구간"을 허물고 교체하며, 때로는 문제(전력 공급 부족)나 재난(화재)이 닥칠 때만 이 마을 주변에 건설합니다. 하지만 심시티와 달리, 시장들은 한 곳이 아니라 많이 있을 것이고, 그들의 욕망과 인센티브는 종종 충돌할 것입니다. 어떤 기존 표준이 어떤 방식으로, 어떤 효과로, 언제 또는 어떤 애플리케이션 및 그룹을 이전할지는 고사하고 메타버스에 정확히 무엇이 필요한지 알 수 없습니다. 그 결과, 어떤 기술 표준이냐가 아니라 어떻게 메타버스가 등장하는지 고려하는 것이 중요합니다.
댓글