AWS를 활용하여 Autodesk VRED 온디맨드 3D 디자인 리뷰 수행하기

이 글은 AWS Spatial Computing Blog에 게시된 3D Design Reviews On-demand with Autodesk VRED and AWS by Andy Mui, Eric Cornwell, David Israel, and Rob Aitchison 을 한국어로 번역 및 편집하였습니다.

들어가며

3D 제품 시각화와 가상 프로토타이핑은 제품 설계에서 중요하며, 특히 제조와 자동차 산업 등에서 중요한 역할을 합니다. 작년에는 AWS Spatial Computing 커뮤니티의 팀원들이 “AWS에서 Autodesk VRED로 가상 프로토타입 만들기 (Virtual prototyping with Autodesk VRED on AWS)”라는 제목의 Autodesk VRED에 관한 블로그 글을 작성했었습니다. 여기서 Autodesk VRED는 디자이너들이 엔지니어링 아티팩트의 고품질 스트림 또는 렌더링의 프로토타입을 생성하고 협업하는 데 널리 쓰이는 소프트웨어 패키지입니다. 해당 블로그에서는 Amazon Elastic Compute Cloud (Amazon EC2) G5 인스턴스 패밀리에 대한 VRED 최적화 방법과 디자인 자산을 위한 공유 파일 시스템 추가 방법 등 EC2에서 VRED를 구성하는 다양한 옵션과 세부 설정 가이드를 제공했습니다. 또한 “Autodesk VRED와 NVIDIA CloudXR on AWS” 에 대한 Quick Start 배포 가이드 링크도 포함되어 있었습니다.

이 블로그 포스트에서는 Autodesk VRED를 AWS에 배포하는 새로운 방법을 설명하고, 이를 디자인 및 엔지니어링 워크플로우에 통합하여 운영상의 부담을 줄이는 방법을 제시하고자 합니다.

작년에는 Autodesk Consulting에서 VRED의 Python API를 사용하여 협업 세션 (collaboration session) 설정을 자동화하는 Django 애플리케이션의 개념 증명(PoC)을 발표했었습니다. AWS에서 VRED를 사용하는 고객들 역시도 AWS 서비스를 활용하여 협업 세션을 확장할 수 있는 옵션을 모색해 왔습니다. 이를 통해 데이터를 쉽게 이동하고, GPU 및 스토리지와 같은 하드웨어의 구매 및 관리에 소요되는 운영 부담을 줄이는 것이 목표입니다.

AWS Open Source and Emerging Tech (OSET) 팀은 Autodesk AWS 파트너 팀으로부터 AWS에서 VRED 배포를 확장하는 방법에 대해 도움을 받았습니다. OSET 팀의 솔루션 엔지니어들은 Autodesk Consulting의 PoC와 지난해 발표된 AWS 파트너 Quick Start 에서 영감과 힌트를 얻어, 최종 사용자 경험 (UX)를 강화하여 VRED 배포 프로세스를 마치 웹 미팅을 만드는 것처럼 간단하게 바꾸고자 했습니다. 그 결과 VRED를 서비스로 구현한다는 아이디어가 떠올랐고, Autodesk 동료들 역시 이 아이디어를 더 구체화해보고자 했습니다.

이제 온디맨드 3D 디자인 리뷰를 가능하게 만든 VRED 세션 관리 서비스 (VRED Session Management Service, SMS)를 어떻게 설계하고 구현했는지 설명해 드리겠습니다.

디자인 고려 사항

우리는 두 가지 주요 사용자 그룹에 초점을 맞추어 VRED SMS를 설계했습니다. 디자인 리뷰를 시작하고 참여하는 최종 사용자와 해당 솔루션을 배포하고 관리하는 IT/DevOps 팀입니다.

최종 사용자를 위해 우리는 웹 미팅을 만드는 것과 유사한 사용자 경험을 목표로 했습니다. 최종 사용자는 이미 디자인 자산 (또는 프로젝트) 관리 시스템을 사용하고 있을 가능성이 높으며, 이 시스템은 디자인 리뷰를 시작하는 데에 있어 이상적인 출발점이 될 수 있습니다. 이 시스템은 기본적으로 디자인 자산들을 저장 또는 연결하고 있기 때문입니다. API 기반의 웹 서비스를 구축한다면 이와 같은 기존 시스템과 편리하게 통합하거나 보다 맞춤화된 사용자 경험을 제공할 수 있는 유연성을 제공할 수 있습니다.

이에 더해 우리는 Autodesk VRED와 NVIDIA CloudXR on AWS Quick Start 솔루션 (AWS 파트너 팀에서 출시)을 사용하여 VRED 세션을 완전히 시작하는 데 필요한 총 시간을 계산해 보았습니다. 이 솔루션은 AWS CloudFormation을 활용하여 AWS 리소스를 배포하고, Amazon EC2 사용자 데이터 스크립트 (user data scripts)를 사용하여 EC2 인스턴스에 VRED를 설치하고 구성합니다. 이와 같은 방식은 VRED 환경을 시작하는 것 자체에는 효과적이었지만, 시작하는 데 필요한 시간(약 30분)이 우리의 목표에 비해 너무 길었습니다. 우리의 궁극적인 목표는 활성화된 VRED 세션을 시작하는 데까지 걸리는 시간을 약 15분으로 줄이는 것이었습니다. 이 시간을 줄이기 위해 VRED 설치 및 기본 구성이 완료된 Amazon Machine Image (AMI)를 만들고, VRED API (VRED Python 문서 참조)를 활용하여 세션별 구성을 처리하는 방안을 고려하게 되었습니다. 또한 AMI를 빌드하고 VRED 세션을 핸들링하는 것은 특정한 단계들로 이루어져 있어 이를 워크플로우로 자동화할 계획을 세웠습니다. 기존의 Quick Start 솔루션을 사용할 경우, 최종 사용자 (및 IT를 포함한 팀)는 다른 자산이 포함된 후속 디자인 리뷰를 위해 VRED 구성을 수동으로 변경해야 했습니다. 우리는 워크플로우 자동화와 API 기반 서비스를 통해 최종 사용자에게는 셀프 서비스 사용자 경험을, 동시에 IT 팀에게는 운영 부담을 최소화하는 방안을 제공할 수 있을 거라고 생각했습니다.

IT/DevOps 팀을 위해서 우리는 서비스 아키텍처를 단순화하여 배포와 운영을 편리하게 하고, 필요에 따라 커스터마이징이 가능하도록 하는 것을 목표로 삼았습니다. 일반적으로 서비스 지향 아키텍처를 사용하는 프로젝트들에서 필요한 AWS 리소스(서버, 데이터베이스 등)들을 AWS Cloud Development Kit(AWS CDK)를 사용하여 코드로 정의합니다. 여기서 AWS CDK는 개발자가 코드를 사용하여 인프라를 정의할 수 있도록 하는 프레임워크입니다. 특히 추가적인 요구사항이나 특별한 설정이 필요할 때, 사용자의 필요에 맞춰 AMI 기반 파이프라인과 세션 처리 워크플로우를 수정하여 작업 절차를 원하는 대로 변경할 수 있습니다.

아키텍처 및 구현 세부 사항

이전 요구 사항과 설계 고려 사항을 바탕으로, 최종 솔루션은 두 가지 주요 구성 요소로 구성됩니다:

• Golden AMI 파이프라인: 다양한 VRED 버전 및 구성에 대한 기본 수준의 AMI를 생성합니다.
• VRED 세션 관리 서비스: VRED 협업 세션을 시작하고 종료합니다.

Golden AMI 파이프라인

Golden AMI 파이프라인은 표준 서버 이미지를 생성하는 시스템으로, Amazon EC2 Image Builder를 사용하여 VRED 및 필요한 모든 관련 소프트웨어가 미리 설치된 이미지(AMI)를 만들도록 구성했습니다. 이 파이프라인은 처음부터 끝까지 모든 과정을 자동으로 처리하여, 원하는 형태로 수정 가능한 표준 서버 이미지(Golden AMI)를 만듭니다. 이 시스템의 장점은 VRED 프로그램의 버전, 운영 체제, 그리고 필요한 관련 프로그램들을 쉽게 변경할 수 있다는 점입니다. 또한 모든 변경 사항은 체계적으로 버전 관리가 됩니다.

아래 그림은 Golden AMI 파이프라인의 대략적인 아키텍처입니다. 이 Golden AMI 파이프라인은 파이프라인 및 구성 요소 설정 파일들로 이루어져 있습니다. 이 설정 파일들은 기본 AMI, 각종 설정값, 그리고 AMI 커스터마이징에 필요한 소프트웨어 패키지들을 지정합니다. 이 파이프라인의 결과물로, 필요한 모든 소프트웨어가 미리 설치된 상태로 Amazon EC2에서 바로 실행 가능한 AMI가 만들어집니다. 이런 방식은 새로운 Amazon EC2 인스턴스를 실행할 때 매우 효율적입니다. 특히 설치해야 할 소프트웨어가 크거나 복잡할 때(많은 관련 프로그램들이 필요한 경우) 더욱 유용합니다

그림 1: High-level 아키텍처

구현

Golden AMI 파이프라인은 AWS 샘플인 aws-cdk-golden-ami-pipeline을 이용하여 만들었습니다. 이 파이프라인은 TypeScript로 작성되어 있고, AWS CDK Toolkit과 Node.js를 사용하여 배포합니다. 이를 통해 VRED를 위한 사용자 정의 AMI 파이프라인 구축을 간편하게 진행할 수 있습니다. Golden AMI 파이프라인과 VRED Quick Start는 서로 다른 방식으로 동작합니다. VRED Quick Start는 서버가 시작될 때마다 Amazon EC2 사용자 데이터 스크립트를 통해 필요한 모든 소프트웨어를 설치하고 설정합니다. 반면 Golden AMI 파이프라인은 Amazon EC2 Image Builder를 사용하여 필요한 모든 소프트웨어와 설정이 미리 포함된 이미지를 만듭니다. 이렇게 만들어진 Golden AMI를 사용하면 VRED 서버가 더 빠르게 시작되므로, 사용자들이 필요할 때 즉시 디자인 리뷰 서비스를 이용할 수 있습니다.

Golden AMI 파이프라인은 기본 AMI와 AWS SSM Parameter Store (SSM Parameter Store) 및 Amazon S3에 저장된 데이터를 입력으로 받아 사용합니다. 기본 AMI는 Windows Server 2022와 같은 기본 운영 체제 (OS)와 VRED Core를 실행하는 데 필요한 소프트웨어 드라이버를 포함합니다. SSM Parameter Store에는 VRED Core 설치 미디어의 경로 (예: /install-media-bucket/vred-16-0), VRED SMS에서 사용하는 로드 스크립트, 구성 요소 설정 파일 (다음 섹션에서 설명)의 설정 파라미터들이 저장됩니다. 앞서 언급한 구성 요소들은 모두 S3에 저장됩니다. Golden AMI 파이프라인은 사용자의 필요에 따라 변경이 가능하며, 여러 파이프라인들을 생성하여 다양한 VRED 버전 (예: VRED 2024.2, VRED 2023.1)과 운영 체제의 조합을 지원하는 사용자 정의 AMI들을 생성할 수 있습니다.

구성

Golden AMI 파이프라인은 파이프라인(또는 메인) 설정 파일과 및 구성 요소 설정 파일들로 이루어져 있습니다. 하나의 Golden AMI 파이프라인에는 JSON 형식의 ‘메인 설정 파일(main configuration file)’과 YAML 형식의 ‘구성 요소 설정 파일(component configuration file)’이 있으며, 두 파일 모두 버전 관리됩니다. 메인 설정 파일의 주요 목적은 전체 파이프라인의 작업 순서와 과정을 정의하는 것입니다. 빌드와 테스트를 위한 구성 요소 설정 파일들은 파이프라인 실행 시 수행될 상세한 명령어들을 정의합니다. 이러한 명령어들은 최종 AMI에 포함될 소프트웨어 패키지들을 설치하고, 설정하고, 테스트하는 역할을 담당합니다.

그림 2: Golden AMI 파이프라인 레서피와 구성요소

Golden AMI 파이프라인을 배포하고 나면, AWS 관리 콘솔의 Amazon EC2 Image Builder에서 이미지 파이프라인을 실행하여 맞춤형 AMI를 만들 수 있습니다. 이렇게 만들어진 AMI는 고유한 AMI ID를 받게 되며, 이를 사용해 원하는 AWS 리전에서 EC2 인스턴스를 실행할 수 있습니다. 필요한 경우, Amazon EC2 Image Builder 설정을 통해 이 VRED AMI를 다른 AWS 리전이나 계정으로 배포할 수도 있습니다. 이때 한 리전에서 여러 리전으로 서비스를 제공하거나, 각 리전마다 별도의 파이프라인을 구축하는 등 상황에 맞게 유연하게 구성할 수 있습니다

VRED 세션 관리 서비스

VRED 세션 관리 서비스(VRED SMS)는 REST API를 통해 VRED 협업 세션을 관리할 수 있게 해줍니다. 이 서비스를 사용하면 세션을 시작하거나 종료할 수 있고, 현재 진행 중인 세션의 정보도 확인할 수 있습니다. 고객들은 REST API를 지원하는 어떤 프로그램에서든 VRED 세션을 실행할 수 있습니다. 예를 들어, VRED Scene 파일을 저장하고 관리하는 시스템이나, 디자인 리뷰 일정을 관리하는 맞춤형 프로그램과 연동하여 사용할 수 있습니다.

표 1: VRED SMS REST 기반 API – 리소스와 메소드

그림 3: High-level 아키텍처

VRED 인스턴스와 그 협업 세션을 시작하는 프로비저닝 워크플로우는 이 아키텍처에서 가장 복잡한 부분입니다. 이 워크플로우는 다음 세 가지 AWS 서비스를 활용해 작동합니다. AWS Step Functions 스테이트 머신이 사용자의 요청을 받아 전체 작업 과정을 관리하고 조정하며, AWS Systems Manager의 SSM Automation 문서는 여러 VRED 인스턴스들을 동시에 실행하고, AWS Lambda는 VRED SMS API요청을 받아 VRED 협업 세션 생성 등의 작업을 처리합니다. 사용자가 요청을 보내면, 이 세 서비스가 협력하여 여러 사용자가 함께 작업할 수 있는 VRED 환경을 만들어냅니다.

스테이트 머신은 필요에 따라 다양한 상태를  선택하여 워크플로우를 유연하게 구성할 수 있습니다. 예를 들면:

• 작업 (Taks) 상태: 간단한 작업 단위 (예: Amazon DynamoDB 테이블에 데이터 쓰기).
• 선택 (Choice) 상태: 이전 상태의 출력 값에 기반한 조건부 논리 추가.
• 맵 (Map) 상태: 상태 간에 전달될 수 있는 데이터 세트를 병렬로 반복 처리.

VRED SMS 프로젝트의 스테이트 머신 정의는 처음에는 기본적인 기능만 갖추도록 의도적으로 간단하게 만들었습니다. 여기에 필요에 따라 오류 처리, 다른 메시징 서비스를 통한 알림 기능, 다른 AWS 서비스와의 연동 등을 추가할 수 있습니다. AWS Step Functions는 계속해서 AWS 서비스 통합과 직접적인 AWS SDK 서비스 통합을 진행하고 있어, 대부분의 필요한 기능들을 구현할 수 있습니다. 특히 Amazon API Gateway가 AWS Step Functions와 직접 연결할 수 있다는 것이 큰 장점입니다. 다음 그림은 사용자가 VRED 협업 세션을 요청했을 때 VRED SMS 스테이트 머신이 어떻게 작동하는지 보여줍니다.

그림 4: Orchestration automation

프로비저닝 워크플로우는 다음과 같이 작동합니다. 먼저 클라이언트 프로그램이 JSON 형식의 데이터를 담아 POST 요청을 보냅니다. API Gateway가 이 요청을 받으면 스테이트 머신이 작동을 시작합니다. 이때 전송되는 데이터는 특정 형식을 따르는데, 각 항목은 필드 이름(따옴표로 표시), 데이터 종류(대괄호로 표시), 그리고 필드 값 설명으로 구성됩니다.

{
   "input": [JSON string] Step Functions 실행에 제공된 입력 데이터,
   "name": [string] Step Functions 실행을 위한 고유 이름,
   "stateMachineArn": [string] 실행할 스테이트 머신 ARN
}

input 필드에는 VRED 협업 세션을 시작하는 데 필요한 모든 정보가 들어있습니다. 이 데이터는 스테이트 머신으로 바로 전달되며, name과 stateMachineArn은어떤 스테이트 머신을 실행할 지 지정하는 데 사용됩니다. 아래는 input 필드에 들어가는 데이터의 예시입니다:

{ 
  "bucket": [string] VRED scene 파일을 저장하는 S3 버킷,
  "prefix": [string] 특정 VRED scene 파일을 포함하는 접두사/폴더, 
  "key": [string] 특정 VRED scene 파일의 파일명,
  "participants": [
    { "user": [string] 사용자 ID, "host": [boolean] true 호스트 여부 },
    { "user": [string] 사용자 ID, "host": [boolean] false 호스트 여부 },
    { "user": [string] 사용자 ID, "host": [boolean] false 호스트 여부 },
    ...
  ],
  "session_pw": [boolean] 세션 비밀번호 설정 여부,
  "instance_type": [string] EC2 인스턴스 유형,
  "vred_version": [string] VRED 버전
}

참고: 위의 생략 부호 (…)는 협업 세션의다른 참가자 (participants)들을 나타냅니다.

스테이트 머신이 실행되면 먼저 제공된 S3 키와 접두사를 확인하여 요청된 VRED scene 파일이 지정된 위치에 존재하는지 확인합니다. 이후 새로운 협업 세션 ID를 나타내는 UUID를 생성하고 DynamoDB에 기록합니다. 이 DynamoDB는 새로 설정된 VRED 협업 세션과 관련된 VRED 노드들의 상태 정보를 유지합니다. 아래 표는 DynamoDB에 기록된 VRED 협업 세션 상태 정보의 예입니다.

표 2: VRED SMS 데이터베이스 디자인

다음으로, 요청 페이로드에 제공된 VRED 버전을 사용하여 VRED 인스턴스를 시작하기 위한 해당 AMI를 찾습니다. SSM Parameter Store는 VRED 버전과 AMI 간의 매핑 정보를 저장하며, 이 매핑 정보는 솔루션의 다양한 구성 요소에서 사용되는 구성 메타데이터와 함께 관리됩니다

그림 5: VRED SMS 구성 메타데이터

협업 세션 요청을 받게 되면 실행 전에 유효성 검증을 수행합니다. 그 후에는 필요한 VRED 노드(Amazon EC2 인스턴스당 1개)를 준비합니다. 성능을 최적화하기 위해 VRED SMS는 각 참가자에게 독립적인 VRED 노드를 제공하는데, VRED는 GPU를 필요로 하므로 최적의 그래픽 성능을 위해 G4dn 또는 G5 인스턴스 패밀리를 사용하는 것이 좋습니다.

prep-node는 워크플로우에서 Map 상태로 구현되어 있습니다. 입력 데이터의 세션 참가자 목록을 확인하고 SSM Automation을 통해 각 참가자의 VRED 인스턴스를 만들어 할당합니다. SSM Automation 문서에는 각 VRED 인스턴스를 설정하는 데 필요한 단계(아래 그림의 Step name 열에 나온 것과 같이)들이 정의되어 있습니다.

그림 6: VRED 노드 준비 SSM Automation

SSM Automation은 Step Functions와 유사하지만 주로 인프라 구성 및 배포 작업에 사용됩니다. SSM Automation 문서에는 VRED 노드를 협업 세션 준비 상태로 만들기 위해 필요한 중요한 항목들을 포함하고 있습니다. 노드 정보를 DynamoDB에 기록하고, 노드의 가용성 상태를 확인하며, VRED 실행 파일과 VRED API의 접근 가능 여부를 확인하고 실행 상태를 확인하는 작업이 바로 그것들입니다. 노드에서 실행이 필요한 호스트 기반 작업(예: SSM Run Command를 사용하여 로컬 스크립트 실행)들은 AMI에 포함된 SSM agent가 수행합니다.

VRED 인스턴스가 준비되면, SSM Run Command 문서가 해당 노드에서 로드(load) 스크립트를 실행합니다. 이 로드 스크립트는 Golden AMI가 이 커스텀 AMI를 생성할 때 추가되어 AMI에 포함됩니다. 스크립트 실행을 위해서는 S3에 저장된 scene 파일 위치와 VRED 버전, 이렇게 두 가지 인자가 필요합니다. VRED 버전은 라이선싱에 필요한 VRED 관련 레지스트리 키를 확인하고, VRED와 함께 제공된 Python 환경을 포함한 경로를 확인하는데 사용됩니다.

로드 스크립트는 먼저 S3에서 VRED scene 파일과 Python 보조 스크립트를 가져옵니다. 이어서 VRED 실행 파일을 구동하고, VRED API와의 상호작용에 필요한 보조 클래스들을 로드한 다음, VRED API가 정상적으로 사용 가능한지 확인합니다. 그 다음 단계에서는 SSM Parameter Store에서 라이선스 서버 정보를 조회합니다. 이 정보는 CDK 인프라 배포 과정에서 미리 설정된 것으로, 이를 바탕으로 VRED 라이선스 구성이 이루어집니다. 마지막으로 로드 스크립트는 보조 스크립트를 실행하여 VRED 실행 파일을 구동하고 요청된 scene 파일을 로드합니다. 이어서 Collaboration 클래스의 인스턴스를 생성하는데, 이 클래스는 VRED 협업 세션의 전체 생명 주기를 관리하고 이벤트 처리를 지원하는 데 필요한 다양한 메서드와 보조 함수들을 포함하고 있습니다.

모든 노드에서 VRED와 그 API가 실행되면, 스테이트 머신은 이 모든 VRED 노드가 협업 세션에 참여하도록 호출합니다. 이를 위해 스테이트 머신은 VPC를 통해 Lambda 함수를 호출하여 각 호스트의 VRED Web API(VRED Cluster Service에 의해 호스팅된)에 명령을 전달합니다. 이 Web API는 연결된 VRED 세션에서 협업 세션 참여, scene 파일 로드, 일반 상태 확인 등의 작업을 위해 코드를 실행할 수 있는 메커니즘을 제공합니다. 이처럼 외부에서 VRED 인스턴스를 구성하고 원격으로 제어하는 명령-제어 패턴은 VRED에서 무한한 수의 작업을 수행하는 데 폭넓게 적용될 수 있습니다. 만약 협업 세션에 비밀번호가 요청되면, Lambda 함수는 새로운 비밀번호를 생성하여 AWS Secrets Manager에 저장합니다. 이때 해당 시크릿의 ARN 참조는 DynamoDB에 저장된 세션 정보와 연결됩니다. 이 비밀번호는 협업 세션을 위한 추가적인 보안 계층 역할을 합니다.

모든 호스트가 협업 세션에 참여하게 되면, 해당 세션은 DynamoDB에서 “active” 상태로 표시되고, 협업 세션을 요청한 최종 사용자에게 Amazon Simple Notification Service(Amazon SNS)를 통해 알림 이메일이 전송됩니다. Amazon SNS는 HTTP API 요청이나 SMS 등 다양한 알림 방식을 지원합니다. 또한 클라이언트 애플리케이션에서 웹훅 콜백 함수(webhook callback function)를 등록하면, VRED 협업 세션의 준비 완료 상태를 이벤트나 신호로 받아볼 수도 있습니다.

그림 7: 활성 VRED 협업 세션

결론

전반적으로 VRED SMS 프로젝트는 성공적인 개념 증명(PoC)이었습니다. 우리는 AWS에서 VRED를 확장할 수 있는 아키텍처 패턴을 설계하고 구축했으며, 최종 사용자가 VRED SMS API를 통해 온디맨드로 디자인 리뷰를 요청할 수 있는 웹 서비스를 제공했습니다. 이 AWS 기반의 RESTful 웹 서비스는 VRED 리소스와 협업 세션의 설정부터 종료까지 모든 과정을 자동으로 관리하는 통합 환경을 제공합니다. AWS에 Autodesk VRED를 배포하는 이러한 혁신적인 접근 방식은 디자인 및 엔지니어링 워크플로우에 원활하게 통합될 수 있으며, 고객들의 운영상 부담을 덜어줄 수 있음을 보여줍니다.

VRED SMS 프로젝트에 대해 더 자세히 논의하고 싶으시다면 Autodesk 또는 AWS 어카운트 매니저에게 연락해 주시기 바랍니다. 담당자들은 귀사의 사용 사례로부터 역방향 작업(Working backwards)을 수행하고, 이 프로젝트를 참조 아키텍처로 활용하여 브레인스토밍을 진행할 것입니다.

추가 읽을거리

Autodesk VRED에 대해 더 알고 싶다면, Autodesk VRED 제품 페이지를 방문하세요.

관련된 AWS 블로그 게시물: AWS에서 Autodesk VRED를 사용한 가상 프로토타이핑

태그: 3D 자산 관리, Amazon EC2, Spatial Compute