"1분반-Ludex"의 두 판 사이의 차이
cdc wiki
(새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...) |
(→프로토타입 사진 혹은 작동 장면) |
||
(같은 사용자의 중간 판 63개는 보이지 않습니다) | |||
3번째 줄: | 3번째 줄: | ||
==프로젝트 개요== | ==프로젝트 개요== | ||
=== 기술개발 과제 === | === 기술개발 과제 === | ||
− | ''' 국문 : ''' | + | ''' 국문 : ''' Ludex - 게임 개발자, 판매자, 구매자 모두를 위한 ESD |
− | ''' 영문 : ''' | + | ''' 영문 : ''' Ludex - A Unified Digital Distribution Platform for Game Developers, Publishers, and Players |
===과제 팀명=== | ===과제 팀명=== | ||
− | + | Ludex | |
===지도교수=== | ===지도교수=== | ||
− | + | 이동희 교수님 | |
===개발기간=== | ===개발기간=== | ||
17번째 줄: | 17번째 줄: | ||
===구성원 소개=== | ===구성원 소개=== | ||
− | 서울시립대학교 | + | 서울시립대학교 컴퓨터과학부 20149200** 임*우(팀장) |
− | 서울시립대학교 | + | 서울시립대학교 컴퓨터과학부 20199200** 김*호 |
− | 서울시립대학교 | + | 서울시립대학교 컴퓨터과학부 20179200** 서*영 |
− | 서울시립대학교 | + | 서울시립대학교 컴퓨터과학부 20229200** 이*진 |
− | |||
− | |||
==서론== | ==서론== | ||
===개발 과제의 개요=== | ===개발 과제의 개요=== | ||
====개발 과제 요약==== | ====개발 과제 요약==== | ||
− | + | ◇ 인디게임 개발자들을 위한 ESD(Electronic Software Distribution) 플랫폼 | |
+ | ◇ 하나의 게임 컨텐츠로부터 여러 파생 게임 컨텐츠를 만들어가는 플랫폼 | ||
+ | ◇ 스테이블 코인 스마트 컨트랙트를 사용한 개발자 간 수익 분배 기능을 제공 | ||
+ | ◇ NFT 스마트 컨트랙트를 사용한 게임 정품 구매 인증 기능 제공, 다운로드권 보장 | ||
+ | ◇ 하나의 IP에 대한 할인 전략을 제공하여 IP를 공유하는 게임들 사이의 수익 증대 제공 | ||
====개발 과제의 배경==== | ====개발 과제의 배경==== | ||
− | + | ◇ 게임 개발 리소스 관련 통합 플랫폼의 부재 해결 | |
+ | 게임 개발 관련 에셋을 판매하는 플랫폼은 유니티 에셋 스토어, itch.io 등 현재 많은 상태이다. 또한 게임 유통을 하는 플랫폼도 존재하지만, 이를 통합한 플랫폼이 존재하지 않는다. 이 두가지 목적을 달성할 수 있는 플랫폼은 원작 게임의 개발 리소스를 구매해 만든 파생 게임과 관련되어 여러 긍정적인 기대 효과가 존재한다. | ||
+ | |||
+ | ◇ 게임 리소스 공유 허들을 낮춰 게임 개발 시장 활성화 | ||
+ | 이 플랫폼에선 코드 블록부터 시작해서 에셋, 기획서, 콘텐츠 흐름도, 코드 관리법, 게임 전체 소스 등 게임 개발과 관련된 모든 것들이 판매 및 공유가 가능하다. 낮은 품질의 리소스라도 개발자간 공유가 활발해지며 게임 제작의 접근성이 하락될 것이라 생각된다. 이렇게 만들어진 원작 게임의 파생 게임들을 통해서 하나의 IP가 좋은 퀄리티의 콘텐츠로 성장할 수 있고, 게임을 플레이하는 유저도 파생 게임에 대한 접근성이 좋아져 긍정적인 효과를 얻을 수 있을 것으로 예상된다. 모든 걸 거래 및 공유함으로써 게임의 다양성 및 2차 창작 등 인디 게임 시장의 활성화가 되는 기대 효과 또한 존재한다. | ||
+ | |||
+ | ◇ 스마트 컨트랙트를 활용한 신뢰성 있는 로열티 지급 | ||
+ | 기존의 게임 시장에서는 영세 개발자들 간에 로열티를 지불하는 계약을 맺기가 어려운 상태였다. 본 프로젝트의 플랫폼에서는 게임 개발 리소스를 판매 및 공유할 시 판매자와 구매자간 스마트 컨트랙트를 이용해 계약을 진행한다. 스마트 컨트랙트는 조건이 만족되면 자동으로 대금 지급이 완료되는 변조 불가능한 사이버 계약이므로, 이는 신뢰성 있게 보장되어 계약이 확실히 이행한다는 믿음을 줄 수 있다. 이 때 판매자와 구매자간 서로 협의를 통해 파생 게임의 일부 수익의 로열티를 얼마로 지정할 것인지, 파생 게임 내 원작 게임에 대한 표시를 강제하는지 등 계약 내용을 자유롭게 정할 수 있다. 이 기능을 사용해 영세 개발자라 하더라도 로열티를 지불하는 조건으로 게임 개발 리소스를 공유받아 사용할 수 있어 게임 개발에 대한 접근성을 더욱 낮출 수 있다. | ||
+ | |||
+ | ◇ 정품 구매를 인증 가능한 DRM-Free 소프트웨어 유통망 | ||
+ | 기존 게임 시장에선 불법 복제/크랙 문제에 대해 DRM(Digital Rights Management)기술을 사용하여 정품 구매 이력을 확인을 하곤 하였는데, 이는 코드 입력, 네트워크 연결 등 정품 유저를 불편하게 만드는 요소가 있었다. 이에 대해 DRM 기술을 적용하지 않는 유통망도 있지만, 이는 전적으로 유저의 양심에 의존하는 구조로서 게임을 유통하는 입장에선 악의적인 무단 배포에 대해 부담이 있게 되는 구조이다. 본 프로젝트는 이에 대응하여 게임을 구매한 이력에 대해 NFT를 주조하여 제공함으로써, 오직 구매자 본인만 가질 수 있는 구매 이력 토큰을 통해 유통사가 특정 구매자가 게임을 구매했음을 확인할 수 있는 시스템을 제공하여, DRM-Free 정책을 택하는 시장에서도 정품 구매를 확인할 수 있는 방법을 제공한다. | ||
====개발 과제의 목표 및 내용==== | ====개발 과제의 목표 및 내용==== | ||
− | + | ◇ 게임 유통 및 다운로드 시스템 개발 | |
+ | 게임 판매자는 자신이 개발한 게임을 플랫폼에 등록해 업로드 및 판매를 할 수 있다. 또한 유저들은 플랫폼을 통해 구매한 게임을 다운로드 할 수 있다. | ||
+ | |||
+ | ◇ 게임 리소스 마켓플레이스 구현 | ||
+ | Ludex에 게임을 등록한 개발자들은 언제든지 자신의 게임 내 코드, 에셋, 기획서 등을 다른 개발자들에게 로열티를 대가로 판매할 수 있다. 이 리소스 거래는 플랫폼 내 별도의 마켓플레이스를 통해 이루어진다. | ||
+ | |||
+ | ◇ 스마트 컨트랙트 기반 계약 관리 | ||
+ | 게임 리소스 거래 시, 중개자 없이 스마트 컨트랙트를 통해 계약이 자동으로 체결된다. 계약의 내용은 판매자와 구매자 간 합의를 통해 자유롭게 구성하며, 거래 조건 및 권리 분배 등도 함께 명시된다. | ||
+ | |||
+ | ◇ IP 기반 파생 게임 허브 기능 | ||
+ | 플랫폼은 동일한 게임 IP를 기반으로 한 다양한 파생 게임을 유저에게 추천한다. 이를 통해 유저는 하나의 게임을 즐긴 후 해당 IP를 활용한 다른 파생 게임도 쉽게 접할 수 있다. 파생 게임 제작자가 손해를 보지 않는 선에서 한 IP에 일괄 적용 가능한 할인 기능을 제공하여 IP 일반에 대한 접근성을 강화할 수도 있다. | ||
+ | |||
+ | ◇ NFT(Non-Fungible Token)를 통한 정품 인증 및 유저 혜택 | ||
+ | 유저가 게임을 구매할 시 유저의 구매 기록이 담긴 NFT를 발급한다. 이는 유저가 정품 게임을 구매했음을 증명하는 역할을 하며, 유통사는 플랫폼을 거치지 않아도 구매이력을 확인할 수 있다. | ||
+ | |||
+ | ◇ FT(Fungible Token)를 통한 플랫폼 내 거래 시스템 | ||
+ | 플랫폼 내 모든 거래(게임 구매, 게임 리소스 거래)는 FT를 통해 이루어진다. 유저는 실물 화폐로 FT를 구매하여 플랫폼 내에서 사용할 수 있으며, FT는 1USD = 1Token 수준의 스테이블 코인으로 고정된다. | ||
+ | |||
+ | ◇ 온라인 결제 시스템 병행 제공 | ||
+ | 블록체인 사용에 익숙치 않는 유저들을 위해, 토스(Toss), 페이팔(PayPal) 등 일반적인 온라인 결제 수단도 함께 지원한다. 해당 방식으로 구매한 게임의 기록은 플랫폼 내 서버에 저장되며, 이를 유저가 NFT로 소유하고 싶을 경우 언제든지 해당 구매 기록을 바탕으로 한 NFT를 생성해 유저에게 제공한다. | ||
+ | |||
+ | ◇ 오프라인 플레이 지원 및 어밴던웨어(Abandonware) 방지 | ||
+ | 게임 등록 시, 개발자는 DRM-Free 또는 유사한 형태의 오프라인 플레이 지원에 동의해야 한다. 또한 게임이 더이상 판매되지 않더라도, 플랫폼은 이미 구매한 사용자에게는 재다운로드 권한을 계속 제공한다. 이 내용은 서비스 약관에 명시된다. | ||
===관련 기술의 현황=== | ===관련 기술의 현황=== | ||
====관련 기술의 현황 및 분석(State of art)==== | ====관련 기술의 현황 및 분석(State of art)==== | ||
*전 세계적인 기술현황 | *전 세계적인 기술현황 | ||
− | + | ◇ 이더리움 네트워크 (Ethereum Net.) | |
+ | 이더리움은 블록체인 네트워크 중의 하나로서, 스마트 컨트랙트를 사용한 첫 블록체인 네트워크이다. 이더리움은 지분증명(PoS; Proof of Stake) 합의 알고리즘으로 트랜잭션 기록을 검증/유지하여 환경 오염이 상대적으로 적은 네트워크를 제공한다. 이더리움은 EVM이라는 가상머신 모델을 구현하여 모든 네트워크가 하나의 동일한 상태를 가진 가상의 컴퓨터를 공유하는 모델로서 내부에 작동하는 스마트 컨트랙트들을 지원하며, 이에 사용되는 언어인 Solidity는 Javascript를 기반으로 설계되어 개발 난이도가 낮다. 이더리움에서 트랜잭션에 사용되는 코인인 이더(ETH; Ether)는 현재 비트코인 외에 가장 시가총액이 높고 지명도가 높은 블록체인 네트워크로서 현재 업계에서 가장 널리 사용되고 신뢰도가 높은 것으로 평가되는 것으로 볼 수 있다. | ||
+ | |||
+ | ◇ JSON-RPC (JSON-Remote Procedure Call) | ||
+ | JSON-RPC는 JSON 원격 프로시져 호출을 뜻한다. 이는 서버와 클라이언트 상의 상호작용을 위한 통신 프로토콜로서 JSON으로 인코딩 된 데이터를 통해 의사소통이 이뤄진다. JSON-RPC 프로토콜의 작동 원리는 다음과 같다. 서버는 백엔드 상에서 작동하는 프로그램을 조작하기 위한 API를 제공하고, 클라이언트는 JSON으로 호출할 함수와 함수의 인자 값들을 통해 API 상의 함수 호출을 요청한다. 서버는 이 데이터를 통해 요청을 처리하고, 그 결과 값을 다시 JSON으로 반환하여 유저가 프로그램의 결과를 확인할 수 있도록 한다. | ||
+ | |||
+ | ◇ DApp (Decentralized App.) | ||
+ | DApp은 '탈중앙화 앱'을 의미하며, 블록체인 상에서 작동하는 스마트 컨트랙트와 상호작용하는 어플리케이션이다. DApp에선 웹/모바일 어플리케이션 상의 UI/UX 조작을 통해 유저가 스마트 컨트랙트와 상호작용이 이뤄지는데, 이때 스마트 컨트랙트 상에 존재하는 함수들을 호출하기 위해 JSON-RPC를 사용한다. 메타마스크 등의 상용 암호화폐 지갑들은 DApp과 연동되어 호출자의 지갑의 주소와 수수료, 트랜잭션에 사용되는 코인의 양 등의 정보를 같이 넘길 수 있다. | ||
+ | |||
+ | ◇ 스테이블 코인(Stable Coin) | ||
+ | 스테이블 코인은 그 가치가 특정 자산의 가치와 같도록 고정되는 암호화폐로서, ERC-20 표준을 구현하는, Fungible Token의 일종이다. 스테이블 코인은 일반적으로 달러화 등의 기축통화, 석유/금 등의 고가치 자산을 보유한 기관이 자신이 보유한 자산의 가치만큼의 토큰을 발행하여 유지된다. 현재 잘 알려진 스테이블 코인은 USDT/USDC가 있으며, 이들은 달러화와 연동되어 1 USDT, 1 USDC는 1달러와 같은 가치를 갖도록 유지된다. 스테이블 코인은 스마트 컨트랙트로서 일주일 내내 24시간 거래가 가능하다는 점에서 특정 시간에 제약 받는 기존의 해외 송금 결제 방법에 비해 강점이 있어 점점 해외 무역에서 결제에 사용되는 비중이 많아지고 있다. | ||
+ | |||
*특허조사 및 특허 전략 분석 | *특허조사 및 특허 전략 분석 | ||
− | + | ◇ 저작권 침해 방지를 위한 스마트 컨트랙트 시스템; 1020190002448 (2019.01.08) | |
+ | 상기 특허는 저작물에 대한 온라인 결제를 스마트 컨트랙트로 제공하고 해당 저작물에 대한 저작권 항목별로 각 항목에 관련된 계약을 담은 스마트 컨트랙트를 제공하며 표절을 자동으로 감지하는 시스템을 내용으로 담고 있다. 해당 특허의 경우 서버에 등록된 저작물에 대한 저작권만을 관리 대상으로 보고 있으며, 저작물을 제작하는 데에 사용된 중간 산출물에 대한 조항은 없고, 2차 저작의 관리에 대한 부분 역시 존재하지 않는다. 한편 표절 감지를 자동으로 할 수 있는 시스템에 대한 구상을 담고 있으나, 그에 대한 예시로 제공한 이미지 표절 감지의 사례에서 '패턴 코드'를 통한 검출이라는 구현 가능성이 요원한 기능을 제시하고 있다. | ||
+ | |||
+ | ◇ 블록체인을 이용한 저작권 보호 시스템; 1020190111692 (2019.09.09) | ||
+ | 상기 특허는 온라인 상에 존재하는 저작권이 있는 파일에 대해 해당 파일이 실행되는 경우 스마트 컨트랙트를 통해 계약된 사항에 따라 저작권료가 분배되는 시스템을 구상하고 있다. 이는 사용자가 전자지갑을 가지고 온라인 상에서 Web3 기능을 사용하여 파일을 실행하는 비용을 제공하는 것으로, 이용권에 대한 구매 모델로 이해될 수 있으며, 일종의 클라우드 서비스를 구축하려는 모델로 평가할 수 있다. | ||
+ | |||
+ | ◇ NFT를 이용한 디지털 저작물 수익 공유 시스템 및 방법; 1020210098931 (2021.07.28) | ||
+ | 상기 특허는 디지털 저작물의 2차 저작물에 대해서 그 정보를 NFT로 기록하는 기능을 구상하고 있다. 해당 특허에서는 콘텐츠의 유사도에 따라 저작권료가 분배되도록 하고 있는데, 이때 콘텐츠의 유사도를 밝히기 위해서 딥러닝을 사용할 수 있다고 명시하고 있다. 다만 수익 분배에 대해서 해당 NFT의 거래 기록에 따라 저작권료가 분배되는 것으로 구상한 것으로 보아 2차 저작물에서 발생한 수익이 아닌 2차 저작물 자체의 값을 거래한 수익을 공유하는 것으로 이해될 수 있다. 한편 2차 저작물에 대해서 해당 2차 저작물이 유해성이 있는 콘텐츠인 경우에 1차 저작권자에게 경고를 전송하는데, 이를 위한 검출 시스템을 구성하는 것은 그 실현 가능성이 요원하고, 꼭 유해성이 있지 않더라도 콘텐츠의 내용이 1차 저작물의 평판을 해하는 것으로 판단될 수 있는 경우에 대해 1차 저작권자가 제어할 수 있는 부분이 존재하지 않는다. | ||
+ | |||
+ | ◇ 블록체인 네트워크에 기반하여 NFT 권리 관계를 인증하기 위한 방법 및 이를 이용한 권리 관계 인증 서버; 미등록, 출원 번호 1020220070318 (2022.06.09) | ||
+ | 상기 특허는 디지털 콘텐츠에 대한 저작권과 관련된 권리 관계를 블록체인 상에서 장부로 유지하는 스마트 컨트랙트를 구상하고 있다. 이 특허는 권리 관계라는 해석 범위가 넓은 상호작용에 대한 검증을 내용을 하고 있는데, 이에 따라 중간 산출물이나 2차 저작물도 포함될 가능성이 존재한다. 그런데 이 특허의 경우에 저작권으로부터 파생된 수익에 대한 분배를 가능하게 하는 기능은 별도로 명시되어 있지 않은데, 이 기능이 별도로 신뢰 있는 방식으로 제공되지 않는 한 수익 분배에 있어 2차 저작권자가 2차 저작물로부터 발생한 수익에 대해 1차 저작권자에게 보고할 의무를 따로 갖추게 하는 계약으로 법의 보호를 따로 받지 않는 이상 신뢰 있는 저작권 권리 관계를 맺게 하기 어려울 것으로 보인다. | ||
+ | |||
+ | ◇ 기존 출원된 특허 중 저작권에서 발생할 수 있는 문제를 스마트 컨트랙트로 해결해보려는 시도가 적지 않음을 확인할 수 있다. 우리는 이에 대응하여 기존 특허의 접근법들과 유사하지만 충분한 기술적 차별점을 가진 모델을 만드는 특허 회피의 전략을 취한다. | ||
+ | |||
+ | ◇ 기존 특허들의 경우 저작물의 유사도를 알고리즘적으로 판단하여 표절을 사전배제하거나 2차 저작물의 수익 발생을 분배하는 모델을 취하는데, 이것은 AI를 통해 기술을 마련하더라도 최종적으로는 법적으로 해결해야 되는 문제로 보인다. 우리는 기존의 법률 인프라에 의존하되 수익 분배가 가능한 합리적인 솔루션을 제공하는 것으로 접근법을 달리 취하기로 한다. | ||
+ | |||
+ | ◇ 기존 특허에서는 완성된 2차 저작물에서 발생하는 수익의 분배를 추적할 수 있는 방법이 없어 2차 저작물에서 발생한 수익에 대한 정당한 로열티가 1차 저작권자에게 주어지지 않을 수 있다. 이에 대해 본 프로젝트에서는 플랫폼 혹은 플랫폼에서 제공한 스마트 컨트랙트 상에서 구매가 이뤄지도록 하여 발생 수익에 대한 신뢰도 있는 분배가 이뤄지게 할 수 있다. | ||
*기술 로드맵 | *기술 로드맵 | ||
− | + | ◇ React: Front-end | |
+ | 웹 앱의 프론트엔드를 개발하는데 사용되는 라이브러리로, 메타에서 개발했다. 동일한 구조로 모바일 앱과 윈도우 앱의 UI/UX를 만들 수 있어 추후 확장에 유용하다. | ||
+ | |||
+ | ◇ Node.js: Back-end | ||
+ | 웹 앱의 백엔드를 개발하는데 사용되는 런타임 환경으로서 다양한 패키지를 지원하고 있으며, 패키지 매니저인 npm에서 다양한 패키지를 지원하여 기능을 여러 방면으로 확장할 수 있다. DApp 개발을 위한 RPC 기능을 제공해주는 Web3.js 역시 Node.js의 패키지로서 지원되고 있다. | ||
+ | |||
+ | ◇ Solidity: 스마트 컨트랙트 프로그래밍 언어 | ||
+ | 이더리움에서 사용되는 객체지향 언어로서 컨트랙트 기반 디자인 철학을 따르고, 언어 자체에서 수수료를 사용하는 작업과 그렇지 않은 작업을 구분할 수 있는 문법을 지원하여 스마트 컨트랙트 제작에 용이한 프로그래밍 언어이다. | ||
+ | |||
+ | ◇ Hardhat: DApp 개발 환경 | ||
+ | DApp을 개발하기 위한 개발 툴로서 Node.js를 기반으로 ethers.js와 통합된 구조를 가진 프로젝트를 생성해주는 기능을 제공하며, Solidity의 컴파일러가 내장되어 있다. 또한 컴파일한 컨트랙트의 인터페이스 정의를 기반으로 그에 맞는 wrapper 타입들을 정의한 js 파일 및 d.ts 파일들을 생성하여 웹3 기능 개발에 있어 컨트랙트를 스크립트 파일에서 쉽게 접근할 수 있는 방법을 제공한다. | ||
====시장상황에 대한 분석==== | ====시장상황에 대한 분석==== | ||
*경쟁제품 조사 비교 | *경쟁제품 조사 비교 | ||
− | + | ◇ itch.io – 인디게임 중심 전자 소프트웨어 유통 플랫폼으로 누구나 게임을 자유롭게 등록하고 판매할 수 있다. DRM-Free, 자유로운 가격 책정의 정책이 특징이다. 하지만 한 IP에 대한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다. | |
+ | ◇ GOG.com – 고전 게임 중심이지만 인디게임과 최신 게임도 취급하는 플랫폼으로, DRM-Free를 지원한다. 그러나 한 IP에 대한 다양한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다. | ||
+ | ◇ Steam – 세계 최대 규모의 유통 플랫폼으로 DRM을 강제하여 서비스에 종속된 게임 접근권을 제공한다. 인디게임 등록은 가능하지만 높은 수수료와 치열한 경쟁이 문제이며, 개발자 간 자료 공유 및 파생 콘텐츠 제공을 지원하지 않고, 정품 구매자 혜택이 없다. | ||
+ | ◇ 기존 개발자 리소스 공유 사이트: 유니티 에셋 스토어, CraftPix.net, OpenGameArt.org 등의 사이트들은 게임 개발에 필요한 자료를 제공한다. 그러나 게임 유통과 개발 자료 공유가 분리되어 있어 즉각적인 파생 게임 제작이나 아이디어를 바로 실현하는 데 제약이 존재한다. | ||
*마케팅 전략 제시 | *마케팅 전략 제시 | ||
− | + | ◇ 통합 콘텐츠 큐레이션 및 변주 제공 | |
+ | - 경쟁 플랫폼과 달리 Ludex는 한 게임의 원작은 물론 파생 게임과 다양한 변주 버전을 한 곳에서 큐레이션하여 제공한다. 이를 통해 사용자가 특정 게임을 즐긴 후에 해당 IP의 다양한 파생 게임을 탐색 및 구매할 수 있다. | ||
+ | ◇ 개발 자료 직접 구매 기능 강화 | ||
+ | - 게임을 플레이하는 도중, 마음에 드는 요소나 새로운 아이디어가 발견되면, 해당 게임의 개발 자료(코드, 기획 문서, 애셋 등)를 바로 구매할 수 있도록 하여 창작과 개발에 직접 연결될 수 있는 생태계를 조성한다. | ||
+ | ◇ 개발자 지원 및 수익 모델 개선 | ||
+ | - 스마트 컨트랙트 기반으로 파생 게임 제작 권한 및 개발 자료 거래를 관리하여, 인디게임 개발자들이 자신의 IP를 활용해 다양한 수익 창출 기회를 얻을 수 있도록 지원한다. | ||
+ | - 파생 게임의 판매 수익의 일정 비율을 원작 개발자에게 자동 배분하는 시스템으로, 기존 플랫폼 대비 보다 공정한 수익 분배를 강조한다. | ||
+ | ◇ 스마트 컨트랙트 기술적 우위 활용한 기능 확장으로 차별화 지위 확보 | ||
+ | - 스마트 컨트랙트를 사용하면 투표를 통한 게임잼 개최, 한 게임 팀 내에서의 수익 분배와 같이 기존 플랫폼에선 수행하기 어려웠던 기능을 손쉽게 구현할 수 있다. | ||
+ | - 본 플랫폼에선 스마트 컨트랙트로만 구현할 수 있는 기능들을 지속적으로 추가하여 다른 플랫폼에 비해 차별화된 시장 지위를 갖는 것을 목표로 삼는다. | ||
+ | - 현재 블록체인 기술에 대한 회의적 시각을 갖고 있는 소비자가 많은 현실을 반영하여 스마트 컨트랙트 자체를 마케팅 용어로 삼지는 않지만, 스마트 컨트랙트를 사용해야만 구현 가능한 기능들을 공격적으로 구현하여 활용하는 전략을 사용한다. | ||
===개발과제의 기대효과=== | ===개발과제의 기대효과=== | ||
====기술적 기대효과==== | ====기술적 기대효과==== | ||
− | + | ◇ 소액 금융 거래에 대한 기술적 수단 제공 | |
+ | 현재 대부분의 온라인 마켓플레이스는 구매자 – 판매자 관계를 일대일로 상정하고 있는데, 이는 판매자 측이 소규모 법인 혹은 여러 법인의 연합체인 경우 수익 배분과 관련하여 관리의 어려움을 낳는다. 이는 기존의 Web2 기술에 기반한 금융 인프라 사업들의 경우 금융 거래에 대한 수수료를 거래에 건수별로 적용하고 있기 때문으로, 소액 결제의 경우 수수료를 거래 건당 지불하게 되면 수수료의 비중이 너무 커지는 문제가 있다. 본 프로젝트는 이에 대응하여 이더리움 네트워크에서 사용되는 ERC-20 토큰의 거래로 변경한다. ERC-20 토큰은 거래 건수가 아닌 전체 연산의 복잡성에 따라 수수료를 매기는 방식을 따르는데, 이를 이더리움 네트워크의 L2 솔루션인 옵티미즘 네트워크에 적용할 경우 여러 유저 사이의 수익 배분이 일어나는 거래에 대해서도 수수료를 낮게 유지하면서도 Web2에 뒤지지 않는 거래를 제공할 수 있어서 소액 금융 거래에 대한 실질적인 방법을 제공한다. | ||
+ | |||
+ | ◇ Gasless 마켓플레이스 DApp 구현 | ||
+ | 블록체인 네트워크 상에서 동작하는 탈중앙화 애플리케이션(이하 DApp; Decentralized Application)들은 블록체인 네트워크에 새로운 상태를 기록을 하는 유저 동작에 대해 일정량의 수수료를 가져간다. 이더리움의 경우 이를 Gas라 하는데, 이는 마켓플레이스 DApp에 있어 가격을 정찰제 형식으로 제공하기 어렵고, 추가적인 비용에 대한 우려로 인해 소비자 심리를 약화시킬 수 있는 문제로 작동하게 된다. 이에 대해 현재 이더리움 네트워크 상에서 제안된 표준 중 하나인 ERC-2771은 스마트 컨트랙트의 상호작용을 원격으로 수행할 수 있는 컨트랙트를 만들고 이 원격 호출을 대리해주는 객체, 주로 서비스 제공자가 수수료를 대신 지불할 수 있게 하여 Gas를 지불하지 않는, Gasless DApp을 구현할 수 있는 방법을 제공하는데, 아직 이를 실제로 구현한 DApp은 많지 않은 실정이다. 본 프로젝트에서는 ERC-2771 표준을 실질적으로 구현한 DApp을 개발하여, 아직 미개척의 영역에 있는 Gasless DApp에 하나의 선례를 제공한다. | ||
====경제적, 사회적 기대 및 파급효과==== | ====경제적, 사회적 기대 및 파급효과==== | ||
− | + | ◇ 게임 콘텐츠 산업의 다양성 창출 | |
+ | 게임 산업에 있어서 대규모 자본의 지원을 받지 않는 인디게임은 산업의 건전성에 있어 필수적인 영역으로 자리 잡은 지 오래 되었다. 혁신적인 아이디어를 가진 게임을 만들어 기존과 다른 참신한 컨텐츠를 만드는 인디게임의 중요성은 영화 산업에서 독립 영화들이 가지고 있는 중요성에 대응되는 수준이다. 하지만 인디게임을 만드는 것은 독립 영화를 만드는 일과는 달리 기술적인 요구사항이 많아서 일정 수준의 퀄리티를 갖춘 게임을 만드는 일에는 진입 장벽이 굉장히 높은 편이다. 본 플랫폼은 이에 도움이 될 수 있는 방법으로서 성공한 게임의 개발 리소스를 빌려 사용할 수 있으면서도 원작 제작자에게도 이득이 되는 수익 분배 계약을 제공하여 경험이 없는 개발자들이 인디게임을 조금 더 쉽게 만들 수 있는 환경을 제공한다. 이를 통해 인디게임 제작의 진입 장벽을 낮추어, 게임 산업의 콘텐츠 다양성의 창출에 기여할 수 있다. | ||
+ | |||
+ | ◇ 게임 개발의 대안적 모델 제공 | ||
+ | 현재의 게임 산업은 하나의 게임을 개발하는 전체 과정을 전적으로 하나의 법인이 도맡아서 수행하는 형태로 동작하고 있는데, 이 모델은 개발직 노동자가 한 프로젝트의 성사를 위해 너무 많은 노동 시간을 감내해야 하는 형태로 지적되고 있다. 본 프로젝트는 하나의 IP를 여러 다른 이익집단이 함께 발전시켜나갈 수 있는 형태를 취함으로써, 각자 기여할 수 있는 만큼 기여하면서 점진적으로 게임을 발전시키는 효과를 누릴 수 있는 방법을 제공한다. 이는 오픈소스 소프트웨어가 다른 소프트웨어 분야에서 대안적 모델로 작동하는 것과 유사하지만, 신뢰 가능한 수익 분배 모델을 제공함으로써 소프트웨어를 프리웨어화하지 않고도 합리적인 기여 모델을 세울 수 있다. | ||
+ | |||
+ | ◇ 영세 개발자도 할 수 있는 IP 확장 | ||
+ | 인디게임 개발은 성공하면 큰 돈을 벌지만, 실패할 가능성이 아주 높은 일이라고 알려져 있다. 그런데 인디게임 개발은 소규모 인원이 하는 일이기 때문에 성공하는 경우와 실패하는 경우 모두에게 있어 문제가 발생한다. 성공한 인디게임의 경우 IP를 공격적으로 확장하고 싶어도 인력 부족의 문제로 인해 그것이 원활하게 이뤄지지 못하는 경우가 많다. 예컨대 성공한 게임의 외전을 만들거나 확장팩을 만드는 것도 인디게임 개발자들에겐 품이 많이 들어가는 일이기 때문이다. 한편, 실패하는 경우 개발자는 인디게임 개발자로서 생계를 유지하는 것이 어려운 경우가 많고, 때문에 업계 자체를 떠나게 되는 경우도 많은 상황이다. 이에 대해 게임 IP의 리소스에 대한 로열티를 대가로 새로운 게임을 만들 수 있게 하는 본 프로젝트의 플랫폼의 경우 성공한 게임의 경우 IP 자체를 공격적으로 사용하여 다른 이들이 자신의 IP를 이용하게 함으로써 수익 확대를 노릴 수 있고, 실패한 게임의 경우 개발 중 산출된 리소스의 로열티를 얻을 수 있어 생계 유지에 추가적인 도움을 얻을 수 있다. | ||
===기술개발 일정 및 추진체계=== | ===기술개발 일정 및 추진체계=== | ||
====개발 일정==== | ====개발 일정==== | ||
− | + | [[파일:개발일정 중간.jpeg]] | |
+ | |||
====구성원 및 추진체계==== | ====구성원 및 추진체계==== | ||
− | 내용 | + | 구성원 |
+ | ◇ 임진우 | ||
+ | 팀장, DB 설계 및 Back-End 개발 | ||
+ | ◇ 김준호 | ||
+ | DB 설계 및 Back-End 개발 | ||
+ | ◇ 서호영 | ||
+ | 스마트 컨트랙트 설계 및 개발, DApp 기능 개발 | ||
+ | ◇ 이희진 | ||
+ | PM, Front-End 개발, UI/UX 설계 및 개발 | ||
+ | |||
+ | 추진체계 | ||
+ | ◇ 회의 및 개발 운영 | ||
+ | 본 프로젝트는 매주 주말에 팀 전체가 참여하는 개발 회의를 통해 진행 상황을 점검하고, 스프린트 계획 및 개발 일정을 조율한다. 회의록은 팀원들이 교대로 작성하여, 회의 결과를 체계적으로 기록하고 공유하는 방식을 따른다. | ||
+ | 개발 프로세스는 Scrum 방식을 기반으로 운영한다. 스프린트는 1주일 단위로 구성되며, 스프린트 시작 시에는 스프린트 계획 회의(Planning) 를 진행하여 이번 주의 주요 개발 목표를 설정한다. 매일 데일리 스크럼을 통해 팀원들이 각자의 진행 상황을 공유하며, 장애 요소나 협력이 필요한 사항을 빠르게 조율한다. 매주 스프린트 종료 시에는 그 주에 개발한 기능이나 프로토타입을 프로토타입 시연(Prototype Demo) 형태로 공유하고, 이를 바탕으로 스프린트 회고(Retrospective) 를 실시하여 개발 과정에서의 문제점과 개선사항을 도출한다. | ||
+ | 전체 개발 일정은 1주일 단위 스프린트를 기준으로 관리하여, 명확한 목표 설정과 주기적인 점검을 통해 일관성 있는 개발 흐름을 유지하고자 한다. | ||
+ | |||
+ | ◇ 형상 관리 | ||
+ | 형상 관리는 GitHub를 통해 진행하며, 브랜치 전략은 git-flow 모델을 기반으로 간소화해 운영한다. 업무 단위 또는 기능별 개발은 별도의 브랜치를 생성하여 관리하고, 작업 완료 시에는 Pull Request(PR)을 생성하여 코드 리뷰를 요청한다. | ||
+ | Merge 방식은 Squash and Merge를 기본으로 사용하여, 작업 이력을 깔끔하게 관리하고자 한다. PR 작성자는 팀원의 승인(Approve)을 받은 후, 본인이 직접 PR을 Merge하는 절차를 따른다. 이를 통해 리뷰와 승인 과정을 명확히 거친 뒤 안정적으로 개발 통합을 수행한다. | ||
+ | |||
+ | ◇ 코드 리뷰 프로세스 | ||
+ | PR(Pull Request) 작성 시에는 일정한 규칙을 따른다. PR 제목은 [type] subject 형식으로 작성하며, type은 작업의 성격에 따라 구분한다. 주요 타입 종류로는 기능 추가를 의미하는 feat, 버그 수정을 나타내는 fix, 문서 수정 작업인 docs, 코드 포맷팅 및 비기능성 수정을 위한 style, 코드 리팩토링을 나타내는 refactor, 테스트 코드 추가 및 수정을 나타내는 test, 빌드 설정 변경이나 기타 작업을 의미하는 chore가 있다. PR 제목은 예를 들어 feat: 사용자 로그인 기능 추가와 같이 작성하며, 제목의 첫 단어는 반드시 소문자로 시작한다. PR 본문은 두 부분으로 구성한다. 본문(body)에는 작업 내용 요약, 구현 방법, 팀원과 공유할 필요가 있는 정보 등을 작성하며, 꼬리말(footer)에는 이슈 번호 연결 정보를 포함한다. 이슈 연결은 resolves: #123과 같이 작성하여, PR이 특정 이슈를 해결하는 것임을 명시한다. PR 작성 후에는 반드시 팀원 중 1명 이상을 Reviewer로 지정하여 코드 리뷰를 요청한다. Reviewer는 기능 요구사항 충족 여부, 코드의 가독성과 유지보수성, 잠재적인 버그나 예외 처리 누락 여부, 코딩 스타일 준수 여부, 그리고 성능 최적화 여부 등을 중심으로 검토를 진행한다. 리뷰 과정에서 피드백이 발생하면, 작성자는 해당 피드백을 반영하여 코드를 수정하고 다시 리뷰를 요청한다. 모든 리뷰가 완료되고 승인이 이루어진 이후에는 PR 작성자가 본인의 PR을 직접 Merge한다. | ||
+ | |||
+ | ◇ Git 브랜치 네이밍 규칙 | ||
+ | Git 브랜치 관리는 명확한 네이밍 규칙을 따른다. 배포를 위한 메인 브랜치는 main, 개발 통합을 위한 브랜치는 dev로 고정하여 사용한다. 개별 업무나 이슈 단위의 작업은 issue/#이슈번호 형식으로 브랜치를 생성하여 진행한다. 작업 흐름은 다음과 같다. 우선 GitHub에서 새로운 이슈를 생성하고, 이슈 번호를 확인한다. 이후 로컬 환경에서 issue/#이슈번호 형식으로 새로운 작업 브랜치를 생성하고, 해당 브랜치에서 목표 기능을 개발한다. 개발 완료 후 PR을 생성하여 팀원에게 리뷰를 요청하며, 리뷰 완료 및 Merge 이후에는 작업 브랜치를 삭제하고 관련 이슈를 종결한다. | ||
==설계== | ==설계== | ||
===설계사양=== | ===설계사양=== | ||
− | ==== | + | ====액터 정의==== |
− | + | [[파일:액터-정의.jpeg]] | |
− | ====설계 | + | |
− | + | ====기능 요구사항 정의==== | |
+ | [[파일:기능-요구사항-정의.jpeg]] | ||
+ | |||
+ | [[파일:기능-요구사항-정의-2.jpeg]] | ||
+ | |||
+ | [[파일:기능-요구사항-정의-3.jpeg]] | ||
+ | |||
+ | ====유스케이스 정의==== | ||
+ | [[파일:유스케이스-정의-1.jpeg]]<br> | ||
+ | [[파일:유스케이스-정의-2.jpeg]]<br> | ||
+ | [[파일:유스케이스-정의-3.jpeg]]<br> | ||
+ | [[파일:유스케이스-정의-4.jpeg]]<br> | ||
+ | [[파일:유스케이스-정의-5.jpeg]] | ||
+ | |||
+ | ====UML Diagram==== | ||
+ | [[파일:유스케이스-다이어그램.jpeg]] | ||
+ | |||
+ | ====Sequence Diagram==== | ||
+ | *주요 유스케이스 - UC220: 상품 목록 열람 | ||
+ | [[파일:시퀀스-UC200.jpeg]] | ||
+ | 진행 과정: | ||
+ | 콘텐츠 목록 요청 및 표시 | ||
+ | 사용자는 메인 페이지 UI에 콘텐츠 목록을 요청한다. (requestToViewContent) | ||
+ | 메인 페이지 UI는 큐레이션 시스템에 콘텐츠 미리보기 목록을 요청한다. (fetchPreviewList()) | ||
+ | 큐레이션 시스템은 게임 객체 집합으로부터 미리보기 정보를 요청한다. (getPreview()) | ||
+ | 각 게임 객체는 큐레이션 시스템에 미리보기 정보를 반환한다. (preview) | ||
+ | 큐레이션 시스템은 메인 페이지 UI에 콘텐츠 미리보기 목록을 전달한다. (previewList) | ||
+ | 메인 페이지 UI는 사용자에게 콘텐츠 목록을 화면에 출력한다. (displayContents) | ||
+ | |||
+ | 콘텐츠 상세 조회 및 화면 출력 | ||
+ | 1. 사용자는 특정 콘텐츠에 대한 상세 정보를 요청한다. (requestDetails) | ||
+ | 2. 메인 페이지 UI는 콘텐츠 상세 페이지 UI로 화면을 전환한다. (navigate) | ||
+ | 3. 콘텐츠 상세 페이지 UI는 게임 객체(a game)에 콘텐츠 상세 정보를 요청한다. (getDetails()) | ||
+ | 4. 게임 객체(a game)는 콘텐츠 상세 정보를 콘텐츠 상세 페이지 UI에 반환한다. (detail) | ||
+ | 5. 콘텐츠 상세 페이지 UI는 사용자에게 콘텐츠 상세 정보를 출력한다. (showDetail) | ||
+ | |||
+ | *주요 유스케이스 - UC310: 판매 개시 | ||
+ | [[파일:시퀀스-UC310.jpeg]] | ||
+ | 진행 과정: | ||
+ | 게임 등록 화면 진입 | ||
+ | 1. 사용자는 메인 페이지 UI에서 ‘Submit Game’ 버튼을 클릭한다. (ClickRegisterButton) | ||
+ | 2. 메인 페이지 UI는 게임 등록 페이지 UI로 이동한다. (navigate) | ||
+ | 3. 게임 등록 페이지 UI는 게임 등록 화면을 사용자에게 보여준다. (showPage) | ||
+ | |||
+ | |||
+ | 콘텐츠 기본 정보 입력 및 검증 | ||
+ | 1. 사용자는 상품 정보를 입력한다. (provideProductInformation) | ||
+ | 2. 게임 등록 페이지 UI는 입력된 정보를 검증하고 사용자에게 결과를 반환한다. (validInformation) | ||
+ | 3. 사용자는 태그를 선택한다. (selectTag) | ||
+ | 4. 게임 등록 페이지 UI는 선택된 태그의 유효성을 검증한다. (validTag) | ||
+ | |||
+ | 파생 콘텐츠일 경우의 처리 (opt) | ||
+ | 1. 사용자가 등록하는 콘텐츠가 파생 콘텐츠인 경우, 원작 IP 코드를 입력한다. (EnterIPCode) | ||
+ | 2. 게임 등록 페이지 UI는 IP 코드의 유효성을 검증하고 결과를 반환한다. (validIPcode) | ||
+ | |||
+ | 콘텐츠 파일 업로드 및 등록 | ||
+ | 1. 사용자는 게임 파일을 업로드한다. (uploadFile) | ||
+ | 2. 게임 등록 페이지 UI는 업로드된 파일의 유효성을 검증한다. (validFile) | ||
+ | 3. 사용자는 최종적으로 ‘Launch’ 버튼을 누른다. (pushLaunchButton) | ||
+ | 4. 게임 등록 페이지 UI는 새로운 게임 인스턴스를 생성한다. (create → A game : Game) | ||
+ | |||
+ | *주요 유스케이스 - UC340: 할인 개시 | ||
+ | [[파일:시퀀스-UC340.jpeg]] | ||
+ | 진행 과정: | ||
+ | 판매 중인 상품 목록 조회 | ||
+ | 1. 사용자는 라이브러리 페이지 UI에 자신이 판매 중인 콘텐츠 목록 조회를 요청한다. (viewSellingProductList) | ||
+ | 2. 라이브러리 페이지 UI는 사용자에게 판매 중인 콘텐츠 목록을 출력한다. (displaySellingProductList) | ||
+ | |||
+ | 할인 시작 팝업 활성화 | ||
+ | 1. 사용자는 특정 콘텐츠의 할인 시작 버튼을 클릭한다. (clickDiscountStartButton) | ||
+ | 2. 라이브러리 페이지 UI는 할인 정보를 입력할 수 있는 팝업을 출력한다. (showDiscountPopup) | ||
+ | |||
+ | 할인 정보 입력 및 등록 요청 | ||
+ | 1. 사용자는 할인율과 할인 기간을 입력하고 할인 시작을 요청한다. (enterDiscountRateAndPeriod && startDiscount) | ||
+ | 2. 라이브러리 페이지 UI는 새로운 할인 인스턴스를 생성한다. («create» A discount : Discount) | ||
+ | 3. 생성된 할인 인스턴스는 해당 콘텐츠(게임)에 할인 정보를 등록한다. (registerDiscountInfo(discountDetails)) | ||
+ | 4. 게임 객체는 할인 정보를 성공적으로 등록했음을 할인 인스턴스에 응답한다. (registerSuccess) | ||
+ | 5. 할인 인스턴스는 라이브러리 UI에 할인 생성 완료를 알린다. (createSuccess) | ||
+ | 6. 라이브러리 UI는 사용자에게 할인 시작 완료를 알린다. (notifyDiscountStart) | ||
+ | |||
+ | *주요 유스케이스 - UC411-UC412: API 활용 상품 구매 - 스마트 컨트랙트 활용 상품 구매 | ||
+ | [[파일:시퀀스-UC411.jpeg]] | ||
+ | 진행 과정: | ||
+ | 결제 UI 진입 및 금액 선택 | ||
+ | 1. 사용자는 게임 구매 페이지 UI에서 결제 버튼을 클릭한다. (clickPurchaseButton) | ||
+ | 2. UI는 결제 팝업을 사용자에게 표시한다. (showPurchasePopup) | ||
+ | 3. 사용자는 결제할 금액을 선택한다. (selectAmountToPay) | ||
+ | 4. UI는 결제 방식 선택을 위한 드롭다운 버튼을 표시한다. (displayDropdownButton) | ||
+ | |||
+ | 결제 방식 선택 – 분기 처리 (alt) | ||
+ | [분기 A] Fintech 결제 버튼 클릭 시 | ||
+ | 1. 사용자는 핀테크 결제 버튼을 클릭한다. | ||
+ | 2. UI는 핀테크 API 제공자에게 결제를 요청한다. (requestViaFintech) | ||
+ | 3. 핀테크 API 제공자는 purchase() 동작을 수행한다. | ||
+ | 4. 결제 팝업이 표시된다. (showPaymentPopup) | ||
+ | 5. 결제가 처리되며, 결제 내역이 반환된다. (processThePayment → paymentHistory) | ||
+ | 6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess) | ||
+ | |||
+ | [분기 B] 스테이블 코인 결제 버튼 클릭 시 | ||
+ | 1. 사용자는 스테이블 코인 결제 버튼을 클릭한다. | ||
+ | 2. UI는 사용자의 암호화폐 지갑에 결제를 요청한다. (requestViaStableCoin) | ||
+ | 3. 결제 팝업이 표시된다. (showPaymentPopup) | ||
+ | 4. 결제가 처리되며, 사용자의 지갑이 purchase() 동작을 수행한다. | ||
+ | 5. 결제 내역이 UI로 반환된다. (paymentHistory) | ||
+ | 6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess) | ||
+ | |||
+ | *주요 유스케이스 - UC510-UC520: 리소스 열람 - 리소스 사용 계약 | ||
+ | [[파일:시퀀스-UC510.jpeg]] | ||
+ | 진행 과정: | ||
+ | 리소스 정보 조회 | ||
+ | 1. 사용자는 게임 구매 페이지 UI에서 리소스 상세 정보를 조회한다. (browseResourceDetails) | ||
+ | 2. UI는 리소스 객체에 리소스 세부 정보를 요청한다. (getResourceDetails()) | ||
+ | 3. 리소스 객체는 요청된 정보를 UI에 반환한다. (resourceDetails) | ||
+ | 4. UI는 사용자에게 리소스 정보를 출력한다. (displayResourceDetails) | ||
+ | |||
+ | 거래 조건 동의 및 스마트 컨트랙트 실행 | ||
+ | 1. 사용자는 거래 조건에 동의한다. (agreeToTerms) | ||
+ | 2. UI는 사용자의 암호화폐 지갑에 스마트 컨트랙트 실행을 요청한다. (invokeSmartContract()) | ||
+ | |||
+ | 스마트 컨트랙트를 통한 블록체인 거래 | ||
+ | 1. 사용자의 암호화폐 지갑은 스마트 컨트랙트에 서명 및 실행 요청을 보낸다. (signAndExecuteTransaction()) | ||
+ | 2. 스마트 컨트랙트는 블록체인에 거래 정보를 저장한다. (storeInformation()) | ||
+ | 3. 블록체인은 거래 해시값을 스마트 컨트랙트에 반환한다. (transactionHash) | ||
+ | 4. 스마트 컨트랙트는 거래 상태를 사용자 지갑에 반환한다. (transactionStatus) | ||
+ | 5. 사용자 지갑은 거래 상태를 UI에 전달한다. (transactionStatus) | ||
+ | 6. UI는 사용자에게 거래 완료 메시지와 상태를 표시한다. (displaySuccessMessageWithTransactionStatus) | ||
+ | |||
+ | ====UI 구성==== | ||
+ | ◇ UI 플로우차트 | ||
+ | [[파일:UI-flowchart.jpeg]] | ||
+ | 해당 UI Flow Chart는 플랫폼 사용자, 판매자, 관리자 각 역할별로 수행할 수 있는 주요 UI 흐름을 정리한 것이다. 상단에서 메인 메뉴 구조를 시작으로 하여, 하위 행동 단계들이 절차적으로 구성되어 있으며, 요구사항 명세서의 유스케이 스와 연동되어 있다. | ||
+ | |||
+ | 1. 초기 진입 및 사용자 인증 흐름 | ||
+ | 사용자는 메인 페이지에서 로그인/회원가입을 선택할 수 있으며, 이메일 또는 전자지갑 인증을 통해 계정을 생성한다. | ||
+ | |||
+ | 로그인 후 플랫폼 기능 접근이 가능하며, 이는 UC111 (계정 생성), UC120 (로그인/로그아웃) 등의 요구사항과 대응된다. | ||
+ | |||
+ | 2. 게임 검색 및 상세 정보 조회 | ||
+ | 메인 페이지에서는 게임 검색 또는 상품 등록 기능으로 진입할 수 있으며, 검색어 입력 또는 태그 필터를 통해 원하는 상품 목록을 조회할 수 있다. | ||
+ | 사용자는 원하는 게임 슬롯을 선택하여 상세 페이지로 진입할 수 있으며, 이 흐름은 UC210 (검색어 기반 검색), UC220 (상품 목록 열람)에 해당한다. | ||
+ | |||
+ | 3. 상품 등록 및 판매 | ||
+ | 판매자는 상품 등록 페이지에서 게임 정보를 입력하고, 상품 설명, 가격, 태그, 티저 이미지 등을 포함하여 업로드할 수 있다. | ||
+ | |||
+ | 상품 등록 시 리소스를 함께 게시할 수 있으며, 파생 콘텐츠인 경우 IP 코드 입력을 통해 연계 정보를 제공한다. 해당 흐름은 UC310 (판매 개시), UC320 (리소스 게시)로 대응된다. | ||
+ | |||
+ | 4. 상품 상세 페이지에서의 사용자 행동 | ||
+ | 사용자는 상품 상세 페이지에서 신고 버튼 클릭 또는 구매 버튼 클릭을 선택할 수 있다. | ||
+ | 신고는 UC810 (콘텐츠 신고) 흐름과 연결되며, 관리자에 의해 확인되어 처리된다 (UC820). | ||
+ | 구매를 선택한 경우 핀테크 API 또는 전자지갑 기반 결제 방식 중 하나를 선택할 수 있다. | ||
+ | |||
+ | 5. 구매 및 결제 프로세스 | ||
+ | 구매 버튼 클릭 후, 사용자는 결제 방식(핀테크 / 전자지갑)을 선택한다. | ||
+ | 핀테크 API의 경우 외부 결제 창이 호출되며 결제 완료까지 연결된다. | ||
+ | 지갑 결제는 스테이블 코인을 이용하며 스마트 컨트랙트를 통해 처리된다. | ||
+ | |||
+ | 이 전체 프로세스는 스마트 컨트랙트 기반 구매 및 거래 기록 생성까지 이어지며, 블록체인에 기록되는 흐름으로 확장된다. | ||
+ | |||
+ | 이는 UC411, UC412 (API 활용 상품 구매, 스마트 컨트랙트 활용 상품 구매)으로 이어진다. | ||
+ | |||
+ | 6. 마이페이지 기능 | ||
+ | 사용자는 마이페이지에서 정보를 수정하거나 계정을 삭제할 수 있으며, 구매 목록 및 판매 상품 목록, 할인 설정 등을 관리할 수 있다. | ||
+ | |||
+ | UC130 (계정 정보 수정), UC140 (전자지갑 연동), UC420~UC430 (구매 이력, 다운로드), UC331~UC340 (판매 목록 열람, 판매 상품 정보 수정, 할인 개시) 등의 유스케이스가 해당된다. | ||
+ | |||
+ | 7. 관리자 기능 | ||
+ | 관리자 페이지에서는 상품 판매 상태 설정, 계정 관리, 신고 확인, 배너 편집 및 알림 발송 등 | ||
+ | 전반적인 플랫폼 운영 기능이 배치되어 있다. | ||
+ | |||
+ | 이는 UC610~UC820에 해당하는 관리자용 유스케이스들과 연결된다. | ||
+ | |||
+ | ◇ UI 와이어프레임 | ||
+ | 사이트화면구성 와이어프레임 | ||
+ | [[파일:와이어프레임.jpeg]] | ||
+ | 구매자와 판매자가 사이트에 로그인하고, 게임을 탐색, 판매, 등록, 다운로드하는 화면들의 구성 | ||
+ | |||
+ | 관리자페이지 와이어프레임 | ||
+ | [[파일:관리자페이지-와이퍼프레임.jpeg]] | ||
+ | 관리자가 신고를 접수, 알림을 보내고 특정 상품의 정보를 확인, 판매를 중단하는 화면들의 구성 | ||
+ | |||
+ | ====시스템 설계==== | ||
+ | ◇ 전체 시스템 구성 | ||
+ | [[파일:시스템설계.jpeg]] | ||
+ | (Cryptocurrency Wallet은 구현 사항이 아닌 외부 소프트웨어임) | ||
+ | |||
+ | 프론트엔드: 유저가 DApp과 상호작용하기 위한 UI를 제공하고, 데이터베이스와 스마트 컨트랙트에 백엔드가 특정 정보를 입출력 해주는 것을 요청할 수 있다. 또한 Ingegration Library를 통해 스마트 컨트랙트 상의 정보를 직접 확인할 수 있다. 본 프로젝트에서는 구현에 node.js와 React 프레임워크, Express를 사용하였다 | ||
+ | 백엔드: UI 상의 유저 조작으로 인해 발생한 입출력 요청을 기반으로 데이터베이스와 스마트 컨트랙트에 데이터를 입출력한다. 본 프로젝트에서는 node.js와 Express를 사용하였고, 실제 서버 동작에는 AWS 클라우드를 사용하였다 | ||
+ | 데이터베이스: DApp 상에서 스마트 컨트랙트 상에 저장할 수 없는 데이터를 저장하는 공간으로 기능한다. 본 프로젝트에서는 MySql을 사용하였고, 실제 데이터베이스 동작에는 AWS 클라우드를 사용하였다 | ||
+ | 통합 지원 라이브러리: 블록체인에 정의된 스마트 컨트랙트를 호출하기 위하여 인증 및 서명과 같은 기능에 복잡한 과정을 캡슐화한 타입을 정의한 라이브러리로 기능한다. 본 프로젝트에서는 node.js를 사용하였고, 스마트 컨트랙트 호출을 위한 모듈로서 ethers.js (v6)를 사용했고, 호출을 위한 API 서비스로는 Alchemy를 사용하였다 | ||
+ | EVM(Ethereum Virtual Machine): 이더리움 블록체인 전체가 같은 상태 값을 유지하는 가상 머신 으로서, 프로젝트 진행 중에 정의한 스마트 컨트랙트가 프로그램으로서 작동하고 있다. 컨트랙트 코드의 작성에는 OpenZeppelin 라 이브러리가 사용되었다. | ||
+ | |||
+ | ====스마트 컨트랙트 설계==== | ||
+ | ◇ 컨트랙트 다이어그램 | ||
+ | [[파일:컨트랙트-다이어그램.jpeg]] | ||
+ | ◇ 컨트랙트 구성 | ||
+ | |||
+ | IERC20 (OpenZepplin) | ||
+ | ERC-20 표준을 구현하는 컨트랙트들에 대한 인터페이스로서, 대체 가능한 토큰(Fungible Token)을 사용하기 위한 함수들, 즉 토큰 계좌 잔액 확인, 토큰 전송 등이 정의되어 있고, 다른 전자지갑 소유자 혹은 프로그램이 토큰 전송을 대 행해주는 것을 승인해줄 수 있는 함수 역시 정의되어 있다 | ||
+ | |||
+ | IERC20Permit (OpenZeppelin) | ||
+ | ERC-20 표준의 확장인 EIP-2612를 구현하는 컨트랙트에 대한 인터페이스로서, 다른 계좌 소유자 혹은 프로그램에서 토큰 전송을 대행해 주는 작업을 별도의 트랜잭션 없이 오프체인에서 생성한, 검증 가능한 서명을 기반으로 할 수 있는 함수가 정의되어 있다 | ||
+ | |||
+ | IERC721 (OpenZepplin) | ||
+ | ERC-721 표준, 즉 NFT를 구현하는 컨트랙트의 인터페이스. 해당 인터페이스를 통해 주소별로 소유하고 있는 NFT들을 확인할 수 있고, 특정 NFT에 대해 소유권자의 주소를 확인할 수 있으며, 소유자가 특정 주소로 자신의 NFT를 전송. 또한, 별도의 승인 과정을 거치는 경우 승인 받은 주소의 호출자가 특정 주소에서 다른 주소로 특정한 NFT를 전송한다. | ||
+ | |||
+ | ERC2771Context (OpenZeppelin) | ||
+ | ERC-2771 표준, 즉 메타트랜잭션이 수행되는 컨트랙트. 해당 컨트랙트는 릴레이어라는 별도의 주소에서 호출한 요청에 대해 그것이 대리하고 있는 실제 호출의 정보를 확인한다. | ||
+ | |||
+ | ERC2771Forwarder (OpenZeppelin) | ||
+ | 메타트랜잭션에서 RPC로 요청된 함수 호출에 대해 그 호출이 특정 주소의 호출을 대리하는 호출임을 서명 검증 과정을 통해 확인하는 컨트랙트로서, ERC2771Context 컨트랙트 생성 시에 주입되어 ERC2771Context가 수행하는 호출 들에 대해 그 호출이 안전한 대리자 호출임을 보증한다. | ||
+ | |||
+ | Ownable (OpenZeppelin) | ||
+ | 컨트랙트가 특정 주소에 의해 소유되었다고 명시할 수 있으며, 특정 함수를 오직 해당 컨트랙트의 소유자만이 호출할 수 있도록 제한할 수 있는 onlyOwner modifier를 제공한다 | ||
+ | |||
+ | OwnableERC2771Context | ||
+ | Ownable 컨트랙트와 ERC2771Context를 다중 상속하는 컨트랙트, 본 시스템의 다수의 컨트랙트가 상속한다 | ||
+ | |||
+ | Store | ||
+ | 아이템의 구매 요청을 확인하는 컨트랙트로, 구매 요청을 PaymentProcessor에 넘겨 실제 토큰 지불 과정이 수행되도록 하며, Ledger 컨트랙트에 해당 구매에 대한 NFT 토큰 발급을 요청한다 | ||
+ | |||
+ | ProfitEscrow | ||
+ | 아이템의 구매로 인해 발생한 수익에 대하여 특정 판매자 계좌가 얼마나 많은 토큰을 받기로 되어 있는지 기록하는 에스크로 역할의 컨트랙트로서, 판매자는 이 컨트랙트를 통해 자신의 수익을 확인하고, 해당 수익을 요청할 수 있다. 또한 Web2 금융 인프라에 의해 수행된 결제의 수익은 Owner가 지불할 예정인 토큰의 양이 기록되고, Owner는 실제 토큰을 해당 컨트랙트에 입금하고 정산 기능을 호출함으로써 결제된 수익을 판매자가 요청 가능한 상태로 변경할 수 있다 | ||
+ | |||
+ | PaymentProcessor | ||
+ | 구매 요청을 받아 구매할 아이템의 가격과 해당 아이템에서 발생하는 수익의 분배 조건을 확인하여 구매자의 주소로부터 토큰을 이체하여 여러 개의 판매자 주소에 대해 어떤 판매자가 얼마나 수익을 가져가야 하는지 ProfitEscrow에 기록 요청을 전달하고, 수수료에 해당하는 양만큼 Owner 계좌에 전달한다 | ||
+ | |||
+ | PriceTable | ||
+ | 아이템의 가격이 관리되는 컨트랙트로, 오직 아이템의 판매자만이 아이템의 가격을 변경할 수 있도록 하는 기능을 제공하며, 한 아이템에서 파생된 아이템들에 대하여 수익 배분이 어떻게 진행되는지의 정보를 기록할 수 있고, 할인 및 특정 아이템에 대한 수익 지분율 감면을 통한 IP 전체에 대한 할인 기능을 지원한다 | ||
+ | |||
+ | Ledger | ||
+ | 아이템의 구매가 일어날 때 해당 구매 이력에 대한 정보를 저장하고 이에 대한 NFT를 발행하는 컨트랙트이다 | ||
+ | ItemRegistry | ||
+ | 판매자가 자신이 판매할 상품 및 상품의 파생 상품에 대한 로열티 조건을 등록할 수 있는 컨트랙트이다. 또한, Owner는 문제를 발생시킨 상품에 대해 판매를 중단할 수 있고, 문제가 해결되는 경우 판매를 재개할 수도 있다 | ||
+ | |||
+ | PurchaseProxy | ||
+ | 이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 구매하는 경우, 이에 대해 해당 상품에서 발생한 수익을 Owner가 지불할 예정임을 Store에 알려서 수익 정산 예정 상황을 기록하게 하고, Ledger로 하여금 구매 이력을 기록하 도록 하는 역할을 수행하는 컨트랙트이다. 유저는 자신이 구매한 상품타에 대해 구매 이력을 확인하고, 이에 대한 권한을 전자지갑으로 옮기도록 할 수 있다 | ||
+ | |||
+ | SellerProxy | ||
+ | 이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 등록한 경우, 해당 아이템에 대해 가격 및 수익 지분율 조정과 같은 작업을 수행할 수 있게 하고, 자신의 상품 수익에 의해 발생한 수익을 Web2로 정산한 경우 해당 양과 동등한 토 큰을 ProfitEscrow로부터 플랫폼이 관리하는 주체의 계좌로 옮길 수 있다 | ||
− | === | + | ====서버 아키텍처==== |
− | + | ◇ 아키텍쳐 다이어그램 | |
+ | [[파일:server-architecture-final.jpeg]] | ||
+ | ◇ 구조 설명: 마이크로서비스 아키텍쳐 | ||
+ | 프론트엔드의 요청을 처리할 때 서버가 각각의 서비스를 분리하여 처리할 수 있도록 마이크로서비스 아키텍처를 사용한다. 구성되는 서비스의 목록은 다음과 같다 | ||
+ | - 유저 계정 관리 서비스 | ||
+ | - 파일 정보 관리 서비스 | ||
+ | - 관리자 계정 관리 서비스 | ||
+ | - 이더리움 블록체인과 상호작용을 위한 Web3 관련 서비스 | ||
+ | - 게임 및 리소스 파일의 다운로드 서비스 | ||
+ | - 파일 업로드 서비스 | ||
+ | 각각의 서비스에 대해 마치 각각에 대해 별도의 서버가 존재하는 것처럼 서버를 작성하여, 논리적으로 분리되는 서비스 단위를 물리적으로도 분리하여 유지보수성이 높은 서비스를 제공한다 | ||
− | + | ◇ 구현 전략: 도커 컨테이너 오케스트레이션 | |
− | + | 각각의 마이크로서비스를 도커를 사용하여 구성한다. 각각의 서비스는 각각의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 작동하며, 이 전체의 조화 작업을 쿠버네티스를 사용하여 오케스트레이션한다. 이때 컨테이너 간 호출을 위한 기술로서 gRPC를 사용하도록 한다 | |
− | === | + | ◇ 지원 기술 |
− | + | 서비스 아키텍쳐를 뒷받침하는 Backing Sevice들의 목록은 다음과 같다 | |
+ | - AWS RDS: MySql 데이터베이스 입출력을 담당하는 AWS 클라우드의 서비스 | ||
+ | - Redis: DB 입출력, 로그인 세션 유지를 위한 Json Web Token Refresh등 빈번한 작업에 캐싱을 수행하는 인프라로 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작하며, 전체 서비스의 지원을 담당한다 | ||
+ | - Qdrant: 웹앱 상에서 검색 기능을 제공하기 위해 DB 상의 텍스트 데이터들에 대해 생성한 워드 임베딩 벡터들을 담당하는 임베딩 벡터 전용 DB로서 별도의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작한다 | ||
+ | - AWS S3: 웹앱 상에서 제공하는 게임, 리소스등의 파일을 저장하고 관리하기 위한 전용 서비스이다 | ||
+ | |||
+ | ====DB 설계==== | ||
+ | ◇ ER 다이어그램 | ||
+ | [[파일:Ludex DB ERD_real-1.jpeg]] | ||
+ | ◇ DB 테이블 구성 | ||
+ | account | ||
+ | - 사용자 및 관리자의 정보를 저장하는 테이블 | ||
+ | - 비밀번호는 해시값을 저장하여 DB 관리자가 비밀번호를 알 수 없도록 한다. | ||
+ | - 사용자 또는 관리자임을 나타내는 컬럼을 사용하여 구분한다. | ||
+ | - 전자지갑은 다수를 소유할 수 있으므로 무결성을 지키기 위해 별도의 테이블로 둔다. | ||
+ | - 잘못을 범한 유저의 계정 정지/해제를 다룰 테이블을 sanction Table로 둔다. | ||
+ | |||
+ | game | ||
+ | - 플랫폼에 등록되는 게임의 정보를 저장하는 테이블 | ||
+ | - 다운로드 URL는 File Chunk단위로 나눠 다운로드를 가능하게 할 예정으로, 여러 URL이 필요해 무결성을 지키기 위해 별도 테이블로 만든다. | ||
+ | - 게임 구동사양 또한 게임별로 자유롭게 여러 항목을 개발자 재량으로 작성할 수 있도록 별도 테이블로 만든다. | ||
+ | - 원작 게임과 파생 게임의 구분을 위한 origin_or_variant 컬럼이 존재한다. | ||
+ | - 파생 게임의 경우 원작 게임이 어떤 것들이 있는지를 저장할 origin_game 테이블 별도로 존재한다. | ||
+ | - 태그들을 저장할 테이블을 game_tag Table로 별도로 둬 무결성을 지킨다. | ||
+ | |||
+ | resource | ||
+ | - 등록된 게임에서 판매 또는 공유할 리소스를 저장할 테이블 | ||
+ | - game Table과 마찬가지로 개발자 재량으로 이미지 및 다운로드URL를 제공하도록 별도 테이블로 존재한다. | ||
+ | |||
+ | transaction | ||
+ | - 거래 목록을 담당하는 테이블 | ||
+ | - 무결성을 위해 게임 거래와 리소스 거래를 구분하여 각각 테이블로 존재한다. | ||
+ | |||
+ | report | ||
+ | - 유저가 약관위반 등 플랫폼에 등록된 게임에 문제가 있다고 판단했을 때 신고한 내역을 저장하는 테이블 | ||
+ | - 내용과 담당한 관리자의 정보들을 저장한다. | ||
+ | |||
+ | sended_email | ||
+ | - 관리자가 유저에게 알림을 보낸 정보를 기록하는 테이블 | ||
==결과 및 평가== | ==결과 및 평가== | ||
===완료 작품의 소개=== | ===완료 작품의 소개=== | ||
====프로토타입 사진 혹은 작동 장면==== | ====프로토타입 사진 혹은 작동 장면==== | ||
− | + | ◇ 메인 화면 | |
− | + | [[파일:메인화면.jpeg]] | |
− | + | - 사용자에게 다양한 게임을 소개하는 LUDEX 플랫폼의 메인 페이지이다. 상단에는 로고, 검색창, 메뉴(Home, Submit Game, My Page)가 위치해 있으며, 중앙에는 대표 게임을 강조하는 배너가 배치되어 있다. 배너 오른쪽에는 장르 또는 태그별로 게임을 탐색할 수 있도록 태그 버튼들이 나열되어 있다. 하단에는 등록된 게임들이 썸네일 카드 형식으로 정렬되어 있으며, 각 게임을 클릭하면 상세 페이지로 이동할 수 있다. | |
+ | |||
+ | ◇ 게임 상세 정보 화면 | ||
+ | [[파일:게임상세정보화면.jpeg]] | ||
+ | - 선택한 게임의 상세 정보를 보여주는 페이지로, 게임 플레이 화면이 슬라이드 형식으로 표시되며, 오른쪽에는 게임 제목, 가격, 제작자, 설명, 장르 태그, 구동 사양 등의 정보가 제공된다. 또한 왼쪽 하단에는 해당 게임의 파생 게임 상세 페이지로 이동할 수 있는 썸네일 이미지가 표시된다. 하단에는 “Buy” 버튼이 있어 사용자가 게임을 구매하거나 이전 화면으로 돌아갈 수 있다. | ||
+ | |||
+ | ◇ 검색 화면 | ||
+ | [[파일:검색화면.jpeg]] | ||
+ | - 상단의 검색창에 검색어를 입력하거나, 메인 화면에서 태그를 클릭하면 진입하는 검색 화면이다. 입력된 검색어는 태그, 게임명(영문/한글), 게임 설명에 속하거나 그에 유사하다 판단되는 항목들과 매치되어 관련된 태그 또는 게임이 검색 결과로 나타난다. | ||
+ | |||
+ | ◇ 결제 화면 | ||
+ | |||
+ | 결제 수단 선택 모달 | ||
+ | [[파일:결제방법선택화면.jpeg]] | ||
+ | - 게임 상세 페이지에서 “Buy” 버튼을 클릭했을 때 나타나는 결제 수단 선택 모달이다. 다양한 결제 방식을 제공하여 사용자 편의성과 접근성을 높이는 것을 목표로 한다. | ||
+ | |||
+ | 전자지갑 결제 모달 | ||
+ | [[파일:전자지갑-결제-화면.jpeg]] | ||
+ | - 결제 수단 선택 모달에서 결제 수단으로 전자지갑 결제를 선택한 경우 나타나는 모달이다. 블록체인 기반의 토큰(USDC)을 활용한 결제를 진행할 수 있도록 구성되어 있다. | ||
+ | |||
+ | 카드 결제 모달 | ||
+ | [[파일:카드결제-화면.jpeg]] | ||
+ | - 결제 수단 선택 모달에서 카드 결제를 선택했을 때 연동되는 토스페이먼츠(Toss Payments)의 카드 결제 모달이다. 실제 결제는 신용카드 및 간편결제 수단을 통해 이루어지며, 사용자는 원하는 수단을 선택 후 인증을 거쳐 결제를 완료할 수 있다. | ||
+ | |||
+ | ◇ 게임 등록 화면 | ||
+ | [[파일:게임등록화면.jpeg]] | ||
+ | - 게임을 플랫폼에 등록할 수 있는 게임 등록 화면이다. 게임 등록 시에는 게임 파일 뿐만 아니라 썸네일, 설명, 가격 등 게임의 메타데이터도 함께 입력하게 된다. 또한, 해당 게임에서 사용된 리소스를 함께 등록하고자 할 경우, 게임 등록 과정에서 동시에 리소스 등록도 진행할 수 있다. 리소스 등록 시에는 리소스 파일, 설명, 미리보기 이미지, 수익 분배 비율, 사용 조건, 추가 조건 등의 정보를 입력하게 된다. 여기서 설정하는 수익 분배 비율은, 이 리소스를 다른 제작자가 구매해 파생 게임을 제작 및 등록했을 경우, 해당 게임의 판매 수익을 원작자와 파생 제작자가 어떻게 나누게 될지를 결정하는 기준이 된다. | ||
+ | |||
+ | ◇ 마이페이지 화면 | ||
+ | [[파일:마이페이지-화면.jpeg]] | ||
+ | - 사용자의 마이페이지 화면으로, 기본 정보(닉네임, 이메일, 지갑 주소)와 함께 구매 및 판매 내역, NFT 조회, 다운로드 기능, 정산(Payout) 등을 확인하고 관리할 수 있다. | ||
+ | |||
+ | 구매기록 화면 | ||
+ | [[파일:구매기록-화면.jpeg]] | ||
+ | - 마이페이지 내 구매 기록 상세 화면으로, 구매한 게임 리스트와 함께 각 항목의 다운로드, NFT 발급 여부를 확인할 수 있으며, 구매한 리소스에 대한 정보도 하단에 함께 표시된다 | ||
+ | |||
+ | 판매기록 화면 | ||
+ | [[파일:판매기록-화면.jpeg]] | ||
+ | - 마이페이지 내 판매 기록 화면으로, 사용자가 등록한 게임 목록과 함께 각 게임의 가격, 설명, 이미지, 할인 설정(Set Discount) 및 수정(Edit) 기능을 확인하고 관리할 수 있다. | ||
+ | |||
+ | Web3 구매 게임 NFT 조회 모달 | ||
+ | [[파일:nft-web3구매-화면.jpeg]] | ||
+ | - Web3 방식으로 구매한 게임의 NFT 발급 정보를 확인하는 팝업 화면으로, Token ID, Item ID, 구매자 지갑 주소, 구매 일시 등의 정보를 보여준다. | ||
+ | |||
+ | 정산요청 모달 | ||
+ | [[파일:정산요청-화면.jpeg]] | ||
+ | - 사용자가 판매 수익에 대한 정산 요청을 진행하는 화면으로, 정산할 게임과 등록된 지갑 주소를 선택한 뒤 "정산 요청" 버튼을 눌러 수익을 출금할 수 있다. | ||
+ | |||
+ | 지분감면 할인 모달 | ||
+ | [[파일:지분감면-할인-화면.jpeg]] | ||
+ | - 지분 감면 기반 할인 설정 팝업 화면으로, 할인 기간과 함께 감면율(%)을 입력하면 자동으로 감면된 지분이 계산된다. 설정된 감면율은 해당 게임을 기반으로 제작된 파생 게임들에 할인 혜택으로 적용된다. | ||
+ | |||
+ | ◇ 관리자 화면 | ||
+ | |||
+ | 유저 관리 화면 | ||
+ | [[파일:유저관리페이지.jpeg]] | ||
+ | - 관리자가 전체 사용자 목록을 조회하고 차단 여부를 설정할 수 있는 유저 관리 페이지로, 닉네임 또는 이메일로 검색이 가능하며 각 사용자에 대해 "set block" 기능을 통해 제재 조치를 적용할 수 있다. | ||
+ | |||
+ | 게임 관리 화면 | ||
+ | [[파일:게임관리페이.jpeg]] | ||
+ | - 관리자가 등록된 게임 목록을 조회하고 차단/해제할 수 있는 콘텐츠 관리 페이지로, 게임명 또는 설명을 검색해 상세 정보를 확인하고 "set block" 또는 "set unblock" 버튼을 통해 게임의 공개 여부를 제어할 수 있다. | ||
===관련사업비 내역서=== | ===관련사업비 내역서=== | ||
− | + | [[파일:관련사업비내역서 중간.jpeg]] | |
===완료작품의 평가=== | ===완료작품의 평가=== | ||
− | + | [[파일:완료작품의평가 중간.jpeg]] | |
===향후계획=== | ===향후계획=== | ||
− | 내용 | + | *어려웠던 내용들 |
+ | ◇ 스마트 컨트랙트 및 Web3 관련 개발 환경은 아직 인프라가 완전히 성숙하지 않은 상태라, 통합된 공식 문서를 찾기 어렵고, 자료 간의 일관성도 부족했다. Solidity 언어 자체가 아직 버전 1 이전이며, 버전에 따라 문법이나 기능이 상이한 점이 많았다. 또한 Web3 라이브러리로 사용한 ethers.js의 경우 최신 버전인 v6을 기준으로 개발을 진행했지만, 기존 문서들은 대부분 v5를 기준으로 작성되어 있어 적용에 혼선을 겪었다. 참고용으로 도서관에서 관련 교재를 대출해 공부했으나, MetaMask의 경우 교재 집필 당시에는 지원되던 기능이 우리가 학습하던 시점에서는 더 이상 제공되지 않아 학습 자료의 신뢰성에도 어려움이 있었다. | ||
+ | |||
+ | ◇ Web3 외적인 부분에서도 여러 난관이 존재했다. Web3 분야가 아직 생소하고, 이미 시장에는 다양한 유사 서비스가 존재하다 보니 차별화된 방향성을 설정하는 것이 쉽지 않았다. 기획 단계에서는 상품성 있는 아이템을 도출하는 것이 가장 큰 과제였다. 프로젝트 주제에 대한 제한이 없었던 만큼, 어떤 소비자층을 타겟으로 어떤 기능과 서비스를 제공할 것인지 결정하는 데 많은 시간이 소요되었고, 유사 서비스와의 비교를 통해 차별점을 찾는 과정에서도 끊임없는 검토와 고민이 필요했다. | ||
+ | |||
+ | ◇ 개발 측면에서는 백엔드 개발 경험이 두 번째인 팀원이 있어, 프로젝트 구조를 잡거나 기능을 설계하는 과정에서 시행착오가 많았다. 특히 Web3와 결합된 백엔드 구조는 일반적인 웹 개발보다 구조가 복잡하고 고려해야 할 보안 요소도 많아 학습과 구현을 병행하는 데 부담이 컸다. | ||
+ | |||
+ | ◇ 서비스 간 책임 및 리소스 분리를 위해 쿠버네티스(Kubernetes) 클러스터를 도입했지만, 이 과정에서도 적지 않은 어려움을 겪었다. 기존에 사용하던 서버 인프라와 쿠버네티스 기반 인프라는 구성 방식과 운영 방식에 큰 차이가 있었고, 특히 CI/CD 파이프라인을 새롭게 구축하는 과정에서 설정 방식과 배포 방식의 차이로 인해 시행착오가 반복되었다. 클러스터 내 서비스 간 연결, 환경 변수 관리, 볼륨 설정 등 인프라 레벨의 개념들이 익숙하지 않아 초기 세팅과 디버깅에 많은 시간이 소요되었다. 결과적으로 이는 개발보다 인프라 운영 측면에서 예상보다 더 많은 리소스를 요구하는 작업이었다. | ||
+ | |||
+ | ◇ 팀 내 일부 구성원이 게임 산업에 대한 경험이 부족했던 점도 기획과 UX 설계에 영향을 미쳤다. 게임을 평소 즐기지 않다 보니, 소비자 입장에서 어떤 요소가 매력적으로 작용할지 예측하기 어려웠고, 사용자 니즈나 시장 흐름에 대한 인식이 낮아 기능 제안이나 설계에 확신을 가지기 힘들었다. 결과적으로, 기술적인 문제뿐만 아니라 콘텐츠 기획과 소비자 이해도 측면에서도 다방면의 고민이 필요한 프로젝트였다. | ||
+ | |||
+ | *차후 구현할 내용 | ||
+ | ◇ 개발자간 수익 분배 기능 확장 | ||
+ | - 인디게임은 소규모 개발자 또는 법인 간의 협업이 빈번하게 이루어지는 구조다. 그러나 현재의 수익 분배 방식은 플랫폼으로부터 수익을 수령한 팀 리더가 이를 팀원에게 개별적으로 분배하는 형태로, 신뢰성 부족과 함께 리더에게 장기간의 관리 책임이 과도하게 부여된다는 단점이 있다. 특히 게임 수익이 수년, 혹은 수십 년간 발생할 수 있다는 점에서 리더 개인에게 지속적인 관리 책임이 부담으로 작용한다. 현재 itch.io나 Game Jolt 등 인디게임 중심 플랫폼에서는 이러한 협업 구조에 적합한 수익 분배 시스템을 제공하지 않는다. 이는 기술적인 제약 때문인데, 예컨대 Web2 기반의 금융 인프라는 소액 정산 시 건당 수수료가 발생하는 구조여서 효율적인 분배가 어렵다. 또한 에스크로 방식의 경우, 거래 기록을 데이터베이스 상에서 관리하고 별도의 확인 절차를 요구하는 번거로움이 존재한다. Ludex는 이러한 문제를 이더리움 기반 스마트 컨트랙트를 통해 해결할 수 있다. 스마트 컨트랙트는 본질적으로 신뢰 가능한 에스크로 역할을 수행하며, 소액 정산의 경우에도 고정된 건당 수수료가 아닌 연산 비용 기반의 수수료 구조이기 때문에 경제적이다. 아울러 컨트랙트 구현 난이도도 낮아, 비교적 빠른 시간 안에 해당 기능을 플랫폼에 확장 적용할 수 있다 | ||
+ | |||
+ | ◇ 게임 등급 분류 제도 대안책 BM 확장 | ||
+ | - 대한민국에서는 게임을 유료로 배포하기 위해 게임물관리위원회의 등급 분류를 반드시 받아야 한다. 이 제도는 일종의 사전 검열로 기능하며, 절차의 복잡성이나 높은 수수료로 인해 인디 개발자들에게는 진입장벽으로 작용하고 있다. 특히 일부 게임의 경우 심의 수수료가 100만 원을 넘기기도 하여 영세 개발자들에게 큰 부담이 된다. 이러한 문제를 해결하기 위해 Ludex는 예치금 기반의 예약 구매 시스템을 제안한다. 이 시스템은 판매가 개시되기 전, 소비자가 구매 대금을 컨트랙트에 예치하고, 게임이 등급 분류를 마친 이후에야 예치금이 개발자에게 전달되는 구조다. 이 과정에서 발생하는 수익은 등급 분류 이후에 인식되므로, 제도적 검열을 우회할 수 있는 가능성이 존재한다. Ludex는 이와 함께 자사의 수수료 수익도 예치 상태로 유지하며, 예치금이 일정 수준 이상 쌓일 경우에는 심의 신청을 대행하는 방식으로 인디 개발자를 지원할 수 있다. 다만, 이러한 방식은 법적 리스크가 존재하므로, 전문적인 법률 검토를 거친 뒤 적법성이 확보된 경우에만 진행된다. 만약 합법성이 확보되면, 온라인 신문 및 인디게임 커뮤니티를 통해 본 시스템을 널리 홍보할 계획이다. 구현 측면에서는 기존 스마트 컨트랙트에 소폭 수정만 가하면 되므로 기술적 난이도는 낮은 편이다. | ||
+ | |||
+ | *프로모션 방안 | ||
+ | ◇ 온라인 게임잼 개최 | ||
+ | - 게임잼은 인디게임 개발자들이 48~72시간 동안 주어진 주제에 따라 짧은 기간 내 게임을 제작하는 행사로, 인디 커뮤니티에서 가장 널리 사용되는 이벤트 방식 중 하나다. Ludex는 UGC(사용자 제작 콘텐츠) 확장성을 주제로 반년에 한 번씩 총 세 차례 게임잼을 개최할 계획이다. 특히 두 번째와 세 번째 게임잼에서는 첫 번째 게임잼에서 제작된 게임을 기반으로 한 파생 게임 부문을 별도로 마련하여 2차 창작 생태계의 활발한 형성을 유도한다. 이와 같은 파생 게임에 대한 출품 조건은 플랫폼의 정식 출시 이후부터 적용될 예정이다. | ||
+ | |||
+ | |||
+ | ◇ 플레이엑스포 2026 부스 참여 | ||
+ | - 플레이엑스포는 매년 참가 기업 수와 방문객 수가 증가하고 있는 국내 주요 오프라인 게임 전시회다. 특히 2026년 기준으로는 약 11만 5천 명의 관람객과 721개의 게임 관련 기업이 참여하는 등 그 규모가 상당하다. 다른 대형 전시회인 지스타가 대기업 중심인 것과 달리, 플레이엑스포는 인디게임 친화적인 전시회로서 인디게임 전용관 운영과 같은 실질적인 지원을 제공하고 있다. 또한 게임 출품 기업뿐 아니라 게임 관련 기술 및 플랫폼 기업도 부스를 신청할 수 있어, Ludex와 같은 플랫폼 사업자에게도 적합한 전시 기회가 된다. 반면 부산인디커넥트와 같은 일부 전시회는 게임 출품 기업에 한정해 참가 자격을 부여하므로, 이번 기회에 플레이엑스포를 전략적 홍보 채널로 삼는 것이 적절하다. 부스 운영 방안으로는 게임잼 출품작 중 파생 게임이 존재하는 작품들을 직접 체험할 수 있는 플레이존을 제공할 계획이다. 또한 ‘아이디어잼’이라는 참여형 코너를 통해, 방문객이 제시된 주제에 따라 메모지로 게임 아이디어를 적고 이를 보드에 붙이는 방식의 콘텐츠를 마련한다. 나아가 아이디어 간 파생 관계를 구성하여 연결할 수 있게 하고, 심사를 통해 선정된 아이디어의 제안자와 그 파생 아이디어 제공자 모두에게 상품을 수여함으로써 Ludex의 2차 창작 철학을 효과적으로 전달하고자 한다. | ||
− | + | ◇ Google Display Network(GDN) | |
− | + | - Google Display Network(GDN)는 전 세계 200만 개 이상의 웹사이트, 앱, 유튜브 등 다양한 온라인 채널을 통해 광고를 노출할 수 있는 구글의 디스플레이 광고 플랫폼이다. Ludex는 게임 2차 창작이라는 독창적 시장 포지션을 기반으로, 해당 차별점을 적극적으로 부각하는 방향으로 GDN을 활용할 계획이다. 특히 CPC(클릭당 과금) 방식보다는 브랜드 인지도 제고에 초점을 맞춘 CPM(노출 1,000회당 과금) 방식을 채택하여, 개발자 및 게임 유저 커뮤니티를 중심으로 플랫폼 인식을 확산시키는 것이 핵심 전략이다. 이는 신규 유저 유입보다는 초기 브랜드 포지셔닝과 업계 내 존재감 확보를 우선시하는 마케팅 방향성과도 부합한다. GDN을 통해 주 타겟은 게임 개발자 관련 블로그, 인디게임 커뮤니티, 게임 유저 대상 매체 등을 중심으로 설정할 예정이며, 시각적 임팩트가 큰 배너와 명확한 가치 제안을 통해 Ludex의 브랜드 이미지를 강화하고자 한다. |
2025년 6월 18일 (수) 09:09 기준 최신판
프로젝트 개요
기술개발 과제
국문 : Ludex - 게임 개발자, 판매자, 구매자 모두를 위한 ESD
영문 : Ludex - A Unified Digital Distribution Platform for Game Developers, Publishers, and Players
과제 팀명
Ludex
지도교수
이동희 교수님
개발기간
2025년 3월 ~ 2025년 6월 (총 4개월)
구성원 소개
서울시립대학교 컴퓨터과학부 20149200** 임*우(팀장)
서울시립대학교 컴퓨터과학부 20199200** 김*호
서울시립대학교 컴퓨터과학부 20179200** 서*영
서울시립대학교 컴퓨터과학부 20229200** 이*진
서론
개발 과제의 개요
개발 과제 요약
◇ 인디게임 개발자들을 위한 ESD(Electronic Software Distribution) 플랫폼 ◇ 하나의 게임 컨텐츠로부터 여러 파생 게임 컨텐츠를 만들어가는 플랫폼 ◇ 스테이블 코인 스마트 컨트랙트를 사용한 개발자 간 수익 분배 기능을 제공 ◇ NFT 스마트 컨트랙트를 사용한 게임 정품 구매 인증 기능 제공, 다운로드권 보장 ◇ 하나의 IP에 대한 할인 전략을 제공하여 IP를 공유하는 게임들 사이의 수익 증대 제공
개발 과제의 배경
◇ 게임 개발 리소스 관련 통합 플랫폼의 부재 해결
게임 개발 관련 에셋을 판매하는 플랫폼은 유니티 에셋 스토어, itch.io 등 현재 많은 상태이다. 또한 게임 유통을 하는 플랫폼도 존재하지만, 이를 통합한 플랫폼이 존재하지 않는다. 이 두가지 목적을 달성할 수 있는 플랫폼은 원작 게임의 개발 리소스를 구매해 만든 파생 게임과 관련되어 여러 긍정적인 기대 효과가 존재한다.
◇ 게임 리소스 공유 허들을 낮춰 게임 개발 시장 활성화
이 플랫폼에선 코드 블록부터 시작해서 에셋, 기획서, 콘텐츠 흐름도, 코드 관리법, 게임 전체 소스 등 게임 개발과 관련된 모든 것들이 판매 및 공유가 가능하다. 낮은 품질의 리소스라도 개발자간 공유가 활발해지며 게임 제작의 접근성이 하락될 것이라 생각된다. 이렇게 만들어진 원작 게임의 파생 게임들을 통해서 하나의 IP가 좋은 퀄리티의 콘텐츠로 성장할 수 있고, 게임을 플레이하는 유저도 파생 게임에 대한 접근성이 좋아져 긍정적인 효과를 얻을 수 있을 것으로 예상된다. 모든 걸 거래 및 공유함으로써 게임의 다양성 및 2차 창작 등 인디 게임 시장의 활성화가 되는 기대 효과 또한 존재한다.
◇ 스마트 컨트랙트를 활용한 신뢰성 있는 로열티 지급
기존의 게임 시장에서는 영세 개발자들 간에 로열티를 지불하는 계약을 맺기가 어려운 상태였다. 본 프로젝트의 플랫폼에서는 게임 개발 리소스를 판매 및 공유할 시 판매자와 구매자간 스마트 컨트랙트를 이용해 계약을 진행한다. 스마트 컨트랙트는 조건이 만족되면 자동으로 대금 지급이 완료되는 변조 불가능한 사이버 계약이므로, 이는 신뢰성 있게 보장되어 계약이 확실히 이행한다는 믿음을 줄 수 있다. 이 때 판매자와 구매자간 서로 협의를 통해 파생 게임의 일부 수익의 로열티를 얼마로 지정할 것인지, 파생 게임 내 원작 게임에 대한 표시를 강제하는지 등 계약 내용을 자유롭게 정할 수 있다. 이 기능을 사용해 영세 개발자라 하더라도 로열티를 지불하는 조건으로 게임 개발 리소스를 공유받아 사용할 수 있어 게임 개발에 대한 접근성을 더욱 낮출 수 있다.
◇ 정품 구매를 인증 가능한 DRM-Free 소프트웨어 유통망
기존 게임 시장에선 불법 복제/크랙 문제에 대해 DRM(Digital Rights Management)기술을 사용하여 정품 구매 이력을 확인을 하곤 하였는데, 이는 코드 입력, 네트워크 연결 등 정품 유저를 불편하게 만드는 요소가 있었다. 이에 대해 DRM 기술을 적용하지 않는 유통망도 있지만, 이는 전적으로 유저의 양심에 의존하는 구조로서 게임을 유통하는 입장에선 악의적인 무단 배포에 대해 부담이 있게 되는 구조이다. 본 프로젝트는 이에 대응하여 게임을 구매한 이력에 대해 NFT를 주조하여 제공함으로써, 오직 구매자 본인만 가질 수 있는 구매 이력 토큰을 통해 유통사가 특정 구매자가 게임을 구매했음을 확인할 수 있는 시스템을 제공하여, DRM-Free 정책을 택하는 시장에서도 정품 구매를 확인할 수 있는 방법을 제공한다.
개발 과제의 목표 및 내용
◇ 게임 유통 및 다운로드 시스템 개발 게임 판매자는 자신이 개발한 게임을 플랫폼에 등록해 업로드 및 판매를 할 수 있다. 또한 유저들은 플랫폼을 통해 구매한 게임을 다운로드 할 수 있다.
◇ 게임 리소스 마켓플레이스 구현 Ludex에 게임을 등록한 개발자들은 언제든지 자신의 게임 내 코드, 에셋, 기획서 등을 다른 개발자들에게 로열티를 대가로 판매할 수 있다. 이 리소스 거래는 플랫폼 내 별도의 마켓플레이스를 통해 이루어진다.
◇ 스마트 컨트랙트 기반 계약 관리 게임 리소스 거래 시, 중개자 없이 스마트 컨트랙트를 통해 계약이 자동으로 체결된다. 계약의 내용은 판매자와 구매자 간 합의를 통해 자유롭게 구성하며, 거래 조건 및 권리 분배 등도 함께 명시된다.
◇ IP 기반 파생 게임 허브 기능 플랫폼은 동일한 게임 IP를 기반으로 한 다양한 파생 게임을 유저에게 추천한다. 이를 통해 유저는 하나의 게임을 즐긴 후 해당 IP를 활용한 다른 파생 게임도 쉽게 접할 수 있다. 파생 게임 제작자가 손해를 보지 않는 선에서 한 IP에 일괄 적용 가능한 할인 기능을 제공하여 IP 일반에 대한 접근성을 강화할 수도 있다.
◇ NFT(Non-Fungible Token)를 통한 정품 인증 및 유저 혜택 유저가 게임을 구매할 시 유저의 구매 기록이 담긴 NFT를 발급한다. 이는 유저가 정품 게임을 구매했음을 증명하는 역할을 하며, 유통사는 플랫폼을 거치지 않아도 구매이력을 확인할 수 있다.
◇ FT(Fungible Token)를 통한 플랫폼 내 거래 시스템 플랫폼 내 모든 거래(게임 구매, 게임 리소스 거래)는 FT를 통해 이루어진다. 유저는 실물 화폐로 FT를 구매하여 플랫폼 내에서 사용할 수 있으며, FT는 1USD = 1Token 수준의 스테이블 코인으로 고정된다.
◇ 온라인 결제 시스템 병행 제공 블록체인 사용에 익숙치 않는 유저들을 위해, 토스(Toss), 페이팔(PayPal) 등 일반적인 온라인 결제 수단도 함께 지원한다. 해당 방식으로 구매한 게임의 기록은 플랫폼 내 서버에 저장되며, 이를 유저가 NFT로 소유하고 싶을 경우 언제든지 해당 구매 기록을 바탕으로 한 NFT를 생성해 유저에게 제공한다.
◇ 오프라인 플레이 지원 및 어밴던웨어(Abandonware) 방지 게임 등록 시, 개발자는 DRM-Free 또는 유사한 형태의 오프라인 플레이 지원에 동의해야 한다. 또한 게임이 더이상 판매되지 않더라도, 플랫폼은 이미 구매한 사용자에게는 재다운로드 권한을 계속 제공한다. 이 내용은 서비스 약관에 명시된다.
관련 기술의 현황
관련 기술의 현황 및 분석(State of art)
- 전 세계적인 기술현황
◇ 이더리움 네트워크 (Ethereum Net.) 이더리움은 블록체인 네트워크 중의 하나로서, 스마트 컨트랙트를 사용한 첫 블록체인 네트워크이다. 이더리움은 지분증명(PoS; Proof of Stake) 합의 알고리즘으로 트랜잭션 기록을 검증/유지하여 환경 오염이 상대적으로 적은 네트워크를 제공한다. 이더리움은 EVM이라는 가상머신 모델을 구현하여 모든 네트워크가 하나의 동일한 상태를 가진 가상의 컴퓨터를 공유하는 모델로서 내부에 작동하는 스마트 컨트랙트들을 지원하며, 이에 사용되는 언어인 Solidity는 Javascript를 기반으로 설계되어 개발 난이도가 낮다. 이더리움에서 트랜잭션에 사용되는 코인인 이더(ETH; Ether)는 현재 비트코인 외에 가장 시가총액이 높고 지명도가 높은 블록체인 네트워크로서 현재 업계에서 가장 널리 사용되고 신뢰도가 높은 것으로 평가되는 것으로 볼 수 있다.
◇ JSON-RPC (JSON-Remote Procedure Call) JSON-RPC는 JSON 원격 프로시져 호출을 뜻한다. 이는 서버와 클라이언트 상의 상호작용을 위한 통신 프로토콜로서 JSON으로 인코딩 된 데이터를 통해 의사소통이 이뤄진다. JSON-RPC 프로토콜의 작동 원리는 다음과 같다. 서버는 백엔드 상에서 작동하는 프로그램을 조작하기 위한 API를 제공하고, 클라이언트는 JSON으로 호출할 함수와 함수의 인자 값들을 통해 API 상의 함수 호출을 요청한다. 서버는 이 데이터를 통해 요청을 처리하고, 그 결과 값을 다시 JSON으로 반환하여 유저가 프로그램의 결과를 확인할 수 있도록 한다.
◇ DApp (Decentralized App.) DApp은 '탈중앙화 앱'을 의미하며, 블록체인 상에서 작동하는 스마트 컨트랙트와 상호작용하는 어플리케이션이다. DApp에선 웹/모바일 어플리케이션 상의 UI/UX 조작을 통해 유저가 스마트 컨트랙트와 상호작용이 이뤄지는데, 이때 스마트 컨트랙트 상에 존재하는 함수들을 호출하기 위해 JSON-RPC를 사용한다. 메타마스크 등의 상용 암호화폐 지갑들은 DApp과 연동되어 호출자의 지갑의 주소와 수수료, 트랜잭션에 사용되는 코인의 양 등의 정보를 같이 넘길 수 있다.
◇ 스테이블 코인(Stable Coin) 스테이블 코인은 그 가치가 특정 자산의 가치와 같도록 고정되는 암호화폐로서, ERC-20 표준을 구현하는, Fungible Token의 일종이다. 스테이블 코인은 일반적으로 달러화 등의 기축통화, 석유/금 등의 고가치 자산을 보유한 기관이 자신이 보유한 자산의 가치만큼의 토큰을 발행하여 유지된다. 현재 잘 알려진 스테이블 코인은 USDT/USDC가 있으며, 이들은 달러화와 연동되어 1 USDT, 1 USDC는 1달러와 같은 가치를 갖도록 유지된다. 스테이블 코인은 스마트 컨트랙트로서 일주일 내내 24시간 거래가 가능하다는 점에서 특정 시간에 제약 받는 기존의 해외 송금 결제 방법에 비해 강점이 있어 점점 해외 무역에서 결제에 사용되는 비중이 많아지고 있다.
- 특허조사 및 특허 전략 분석
◇ 저작권 침해 방지를 위한 스마트 컨트랙트 시스템; 1020190002448 (2019.01.08) 상기 특허는 저작물에 대한 온라인 결제를 스마트 컨트랙트로 제공하고 해당 저작물에 대한 저작권 항목별로 각 항목에 관련된 계약을 담은 스마트 컨트랙트를 제공하며 표절을 자동으로 감지하는 시스템을 내용으로 담고 있다. 해당 특허의 경우 서버에 등록된 저작물에 대한 저작권만을 관리 대상으로 보고 있으며, 저작물을 제작하는 데에 사용된 중간 산출물에 대한 조항은 없고, 2차 저작의 관리에 대한 부분 역시 존재하지 않는다. 한편 표절 감지를 자동으로 할 수 있는 시스템에 대한 구상을 담고 있으나, 그에 대한 예시로 제공한 이미지 표절 감지의 사례에서 '패턴 코드'를 통한 검출이라는 구현 가능성이 요원한 기능을 제시하고 있다.
◇ 블록체인을 이용한 저작권 보호 시스템; 1020190111692 (2019.09.09) 상기 특허는 온라인 상에 존재하는 저작권이 있는 파일에 대해 해당 파일이 실행되는 경우 스마트 컨트랙트를 통해 계약된 사항에 따라 저작권료가 분배되는 시스템을 구상하고 있다. 이는 사용자가 전자지갑을 가지고 온라인 상에서 Web3 기능을 사용하여 파일을 실행하는 비용을 제공하는 것으로, 이용권에 대한 구매 모델로 이해될 수 있으며, 일종의 클라우드 서비스를 구축하려는 모델로 평가할 수 있다.
◇ NFT를 이용한 디지털 저작물 수익 공유 시스템 및 방법; 1020210098931 (2021.07.28) 상기 특허는 디지털 저작물의 2차 저작물에 대해서 그 정보를 NFT로 기록하는 기능을 구상하고 있다. 해당 특허에서는 콘텐츠의 유사도에 따라 저작권료가 분배되도록 하고 있는데, 이때 콘텐츠의 유사도를 밝히기 위해서 딥러닝을 사용할 수 있다고 명시하고 있다. 다만 수익 분배에 대해서 해당 NFT의 거래 기록에 따라 저작권료가 분배되는 것으로 구상한 것으로 보아 2차 저작물에서 발생한 수익이 아닌 2차 저작물 자체의 값을 거래한 수익을 공유하는 것으로 이해될 수 있다. 한편 2차 저작물에 대해서 해당 2차 저작물이 유해성이 있는 콘텐츠인 경우에 1차 저작권자에게 경고를 전송하는데, 이를 위한 검출 시스템을 구성하는 것은 그 실현 가능성이 요원하고, 꼭 유해성이 있지 않더라도 콘텐츠의 내용이 1차 저작물의 평판을 해하는 것으로 판단될 수 있는 경우에 대해 1차 저작권자가 제어할 수 있는 부분이 존재하지 않는다.
◇ 블록체인 네트워크에 기반하여 NFT 권리 관계를 인증하기 위한 방법 및 이를 이용한 권리 관계 인증 서버; 미등록, 출원 번호 1020220070318 (2022.06.09) 상기 특허는 디지털 콘텐츠에 대한 저작권과 관련된 권리 관계를 블록체인 상에서 장부로 유지하는 스마트 컨트랙트를 구상하고 있다. 이 특허는 권리 관계라는 해석 범위가 넓은 상호작용에 대한 검증을 내용을 하고 있는데, 이에 따라 중간 산출물이나 2차 저작물도 포함될 가능성이 존재한다. 그런데 이 특허의 경우에 저작권으로부터 파생된 수익에 대한 분배를 가능하게 하는 기능은 별도로 명시되어 있지 않은데, 이 기능이 별도로 신뢰 있는 방식으로 제공되지 않는 한 수익 분배에 있어 2차 저작권자가 2차 저작물로부터 발생한 수익에 대해 1차 저작권자에게 보고할 의무를 따로 갖추게 하는 계약으로 법의 보호를 따로 받지 않는 이상 신뢰 있는 저작권 권리 관계를 맺게 하기 어려울 것으로 보인다.
◇ 기존 출원된 특허 중 저작권에서 발생할 수 있는 문제를 스마트 컨트랙트로 해결해보려는 시도가 적지 않음을 확인할 수 있다. 우리는 이에 대응하여 기존 특허의 접근법들과 유사하지만 충분한 기술적 차별점을 가진 모델을 만드는 특허 회피의 전략을 취한다.
◇ 기존 특허들의 경우 저작물의 유사도를 알고리즘적으로 판단하여 표절을 사전배제하거나 2차 저작물의 수익 발생을 분배하는 모델을 취하는데, 이것은 AI를 통해 기술을 마련하더라도 최종적으로는 법적으로 해결해야 되는 문제로 보인다. 우리는 기존의 법률 인프라에 의존하되 수익 분배가 가능한 합리적인 솔루션을 제공하는 것으로 접근법을 달리 취하기로 한다.
◇ 기존 특허에서는 완성된 2차 저작물에서 발생하는 수익의 분배를 추적할 수 있는 방법이 없어 2차 저작물에서 발생한 수익에 대한 정당한 로열티가 1차 저작권자에게 주어지지 않을 수 있다. 이에 대해 본 프로젝트에서는 플랫폼 혹은 플랫폼에서 제공한 스마트 컨트랙트 상에서 구매가 이뤄지도록 하여 발생 수익에 대한 신뢰도 있는 분배가 이뤄지게 할 수 있다.
- 기술 로드맵
◇ React: Front-end 웹 앱의 프론트엔드를 개발하는데 사용되는 라이브러리로, 메타에서 개발했다. 동일한 구조로 모바일 앱과 윈도우 앱의 UI/UX를 만들 수 있어 추후 확장에 유용하다.
◇ Node.js: Back-end 웹 앱의 백엔드를 개발하는데 사용되는 런타임 환경으로서 다양한 패키지를 지원하고 있으며, 패키지 매니저인 npm에서 다양한 패키지를 지원하여 기능을 여러 방면으로 확장할 수 있다. DApp 개발을 위한 RPC 기능을 제공해주는 Web3.js 역시 Node.js의 패키지로서 지원되고 있다.
◇ Solidity: 스마트 컨트랙트 프로그래밍 언어 이더리움에서 사용되는 객체지향 언어로서 컨트랙트 기반 디자인 철학을 따르고, 언어 자체에서 수수료를 사용하는 작업과 그렇지 않은 작업을 구분할 수 있는 문법을 지원하여 스마트 컨트랙트 제작에 용이한 프로그래밍 언어이다.
◇ Hardhat: DApp 개발 환경 DApp을 개발하기 위한 개발 툴로서 Node.js를 기반으로 ethers.js와 통합된 구조를 가진 프로젝트를 생성해주는 기능을 제공하며, Solidity의 컴파일러가 내장되어 있다. 또한 컴파일한 컨트랙트의 인터페이스 정의를 기반으로 그에 맞는 wrapper 타입들을 정의한 js 파일 및 d.ts 파일들을 생성하여 웹3 기능 개발에 있어 컨트랙트를 스크립트 파일에서 쉽게 접근할 수 있는 방법을 제공한다.
시장상황에 대한 분석
- 경쟁제품 조사 비교
◇ itch.io – 인디게임 중심 전자 소프트웨어 유통 플랫폼으로 누구나 게임을 자유롭게 등록하고 판매할 수 있다. DRM-Free, 자유로운 가격 책정의 정책이 특징이다. 하지만 한 IP에 대한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다. ◇ GOG.com – 고전 게임 중심이지만 인디게임과 최신 게임도 취급하는 플랫폼으로, DRM-Free를 지원한다. 그러나 한 IP에 대한 다양한 파생과 로열티를 통한 수익 분배의 개념을 지원하지는 않는다. ◇ Steam – 세계 최대 규모의 유통 플랫폼으로 DRM을 강제하여 서비스에 종속된 게임 접근권을 제공한다. 인디게임 등록은 가능하지만 높은 수수료와 치열한 경쟁이 문제이며, 개발자 간 자료 공유 및 파생 콘텐츠 제공을 지원하지 않고, 정품 구매자 혜택이 없다. ◇ 기존 개발자 리소스 공유 사이트: 유니티 에셋 스토어, CraftPix.net, OpenGameArt.org 등의 사이트들은 게임 개발에 필요한 자료를 제공한다. 그러나 게임 유통과 개발 자료 공유가 분리되어 있어 즉각적인 파생 게임 제작이나 아이디어를 바로 실현하는 데 제약이 존재한다.
- 마케팅 전략 제시
◇ 통합 콘텐츠 큐레이션 및 변주 제공 - 경쟁 플랫폼과 달리 Ludex는 한 게임의 원작은 물론 파생 게임과 다양한 변주 버전을 한 곳에서 큐레이션하여 제공한다. 이를 통해 사용자가 특정 게임을 즐긴 후에 해당 IP의 다양한 파생 게임을 탐색 및 구매할 수 있다. ◇ 개발 자료 직접 구매 기능 강화 - 게임을 플레이하는 도중, 마음에 드는 요소나 새로운 아이디어가 발견되면, 해당 게임의 개발 자료(코드, 기획 문서, 애셋 등)를 바로 구매할 수 있도록 하여 창작과 개발에 직접 연결될 수 있는 생태계를 조성한다. ◇ 개발자 지원 및 수익 모델 개선 - 스마트 컨트랙트 기반으로 파생 게임 제작 권한 및 개발 자료 거래를 관리하여, 인디게임 개발자들이 자신의 IP를 활용해 다양한 수익 창출 기회를 얻을 수 있도록 지원한다. - 파생 게임의 판매 수익의 일정 비율을 원작 개발자에게 자동 배분하는 시스템으로, 기존 플랫폼 대비 보다 공정한 수익 분배를 강조한다. ◇ 스마트 컨트랙트 기술적 우위 활용한 기능 확장으로 차별화 지위 확보 - 스마트 컨트랙트를 사용하면 투표를 통한 게임잼 개최, 한 게임 팀 내에서의 수익 분배와 같이 기존 플랫폼에선 수행하기 어려웠던 기능을 손쉽게 구현할 수 있다. - 본 플랫폼에선 스마트 컨트랙트로만 구현할 수 있는 기능들을 지속적으로 추가하여 다른 플랫폼에 비해 차별화된 시장 지위를 갖는 것을 목표로 삼는다. - 현재 블록체인 기술에 대한 회의적 시각을 갖고 있는 소비자가 많은 현실을 반영하여 스마트 컨트랙트 자체를 마케팅 용어로 삼지는 않지만, 스마트 컨트랙트를 사용해야만 구현 가능한 기능들을 공격적으로 구현하여 활용하는 전략을 사용한다.
개발과제의 기대효과
기술적 기대효과
◇ 소액 금융 거래에 대한 기술적 수단 제공 현재 대부분의 온라인 마켓플레이스는 구매자 – 판매자 관계를 일대일로 상정하고 있는데, 이는 판매자 측이 소규모 법인 혹은 여러 법인의 연합체인 경우 수익 배분과 관련하여 관리의 어려움을 낳는다. 이는 기존의 Web2 기술에 기반한 금융 인프라 사업들의 경우 금융 거래에 대한 수수료를 거래에 건수별로 적용하고 있기 때문으로, 소액 결제의 경우 수수료를 거래 건당 지불하게 되면 수수료의 비중이 너무 커지는 문제가 있다. 본 프로젝트는 이에 대응하여 이더리움 네트워크에서 사용되는 ERC-20 토큰의 거래로 변경한다. ERC-20 토큰은 거래 건수가 아닌 전체 연산의 복잡성에 따라 수수료를 매기는 방식을 따르는데, 이를 이더리움 네트워크의 L2 솔루션인 옵티미즘 네트워크에 적용할 경우 여러 유저 사이의 수익 배분이 일어나는 거래에 대해서도 수수료를 낮게 유지하면서도 Web2에 뒤지지 않는 거래를 제공할 수 있어서 소액 금융 거래에 대한 실질적인 방법을 제공한다.
◇ Gasless 마켓플레이스 DApp 구현 블록체인 네트워크 상에서 동작하는 탈중앙화 애플리케이션(이하 DApp; Decentralized Application)들은 블록체인 네트워크에 새로운 상태를 기록을 하는 유저 동작에 대해 일정량의 수수료를 가져간다. 이더리움의 경우 이를 Gas라 하는데, 이는 마켓플레이스 DApp에 있어 가격을 정찰제 형식으로 제공하기 어렵고, 추가적인 비용에 대한 우려로 인해 소비자 심리를 약화시킬 수 있는 문제로 작동하게 된다. 이에 대해 현재 이더리움 네트워크 상에서 제안된 표준 중 하나인 ERC-2771은 스마트 컨트랙트의 상호작용을 원격으로 수행할 수 있는 컨트랙트를 만들고 이 원격 호출을 대리해주는 객체, 주로 서비스 제공자가 수수료를 대신 지불할 수 있게 하여 Gas를 지불하지 않는, Gasless DApp을 구현할 수 있는 방법을 제공하는데, 아직 이를 실제로 구현한 DApp은 많지 않은 실정이다. 본 프로젝트에서는 ERC-2771 표준을 실질적으로 구현한 DApp을 개발하여, 아직 미개척의 영역에 있는 Gasless DApp에 하나의 선례를 제공한다.
경제적, 사회적 기대 및 파급효과
◇ 게임 콘텐츠 산업의 다양성 창출 게임 산업에 있어서 대규모 자본의 지원을 받지 않는 인디게임은 산업의 건전성에 있어 필수적인 영역으로 자리 잡은 지 오래 되었다. 혁신적인 아이디어를 가진 게임을 만들어 기존과 다른 참신한 컨텐츠를 만드는 인디게임의 중요성은 영화 산업에서 독립 영화들이 가지고 있는 중요성에 대응되는 수준이다. 하지만 인디게임을 만드는 것은 독립 영화를 만드는 일과는 달리 기술적인 요구사항이 많아서 일정 수준의 퀄리티를 갖춘 게임을 만드는 일에는 진입 장벽이 굉장히 높은 편이다. 본 플랫폼은 이에 도움이 될 수 있는 방법으로서 성공한 게임의 개발 리소스를 빌려 사용할 수 있으면서도 원작 제작자에게도 이득이 되는 수익 분배 계약을 제공하여 경험이 없는 개발자들이 인디게임을 조금 더 쉽게 만들 수 있는 환경을 제공한다. 이를 통해 인디게임 제작의 진입 장벽을 낮추어, 게임 산업의 콘텐츠 다양성의 창출에 기여할 수 있다.
◇ 게임 개발의 대안적 모델 제공 현재의 게임 산업은 하나의 게임을 개발하는 전체 과정을 전적으로 하나의 법인이 도맡아서 수행하는 형태로 동작하고 있는데, 이 모델은 개발직 노동자가 한 프로젝트의 성사를 위해 너무 많은 노동 시간을 감내해야 하는 형태로 지적되고 있다. 본 프로젝트는 하나의 IP를 여러 다른 이익집단이 함께 발전시켜나갈 수 있는 형태를 취함으로써, 각자 기여할 수 있는 만큼 기여하면서 점진적으로 게임을 발전시키는 효과를 누릴 수 있는 방법을 제공한다. 이는 오픈소스 소프트웨어가 다른 소프트웨어 분야에서 대안적 모델로 작동하는 것과 유사하지만, 신뢰 가능한 수익 분배 모델을 제공함으로써 소프트웨어를 프리웨어화하지 않고도 합리적인 기여 모델을 세울 수 있다.
◇ 영세 개발자도 할 수 있는 IP 확장 인디게임 개발은 성공하면 큰 돈을 벌지만, 실패할 가능성이 아주 높은 일이라고 알려져 있다. 그런데 인디게임 개발은 소규모 인원이 하는 일이기 때문에 성공하는 경우와 실패하는 경우 모두에게 있어 문제가 발생한다. 성공한 인디게임의 경우 IP를 공격적으로 확장하고 싶어도 인력 부족의 문제로 인해 그것이 원활하게 이뤄지지 못하는 경우가 많다. 예컨대 성공한 게임의 외전을 만들거나 확장팩을 만드는 것도 인디게임 개발자들에겐 품이 많이 들어가는 일이기 때문이다. 한편, 실패하는 경우 개발자는 인디게임 개발자로서 생계를 유지하는 것이 어려운 경우가 많고, 때문에 업계 자체를 떠나게 되는 경우도 많은 상황이다. 이에 대해 게임 IP의 리소스에 대한 로열티를 대가로 새로운 게임을 만들 수 있게 하는 본 프로젝트의 플랫폼의 경우 성공한 게임의 경우 IP 자체를 공격적으로 사용하여 다른 이들이 자신의 IP를 이용하게 함으로써 수익 확대를 노릴 수 있고, 실패한 게임의 경우 개발 중 산출된 리소스의 로열티를 얻을 수 있어 생계 유지에 추가적인 도움을 얻을 수 있다.
기술개발 일정 및 추진체계
개발 일정
구성원 및 추진체계
구성원 ◇ 임진우 팀장, DB 설계 및 Back-End 개발 ◇ 김준호 DB 설계 및 Back-End 개발 ◇ 서호영 스마트 컨트랙트 설계 및 개발, DApp 기능 개발 ◇ 이희진 PM, Front-End 개발, UI/UX 설계 및 개발
추진체계 ◇ 회의 및 개발 운영 본 프로젝트는 매주 주말에 팀 전체가 참여하는 개발 회의를 통해 진행 상황을 점검하고, 스프린트 계획 및 개발 일정을 조율한다. 회의록은 팀원들이 교대로 작성하여, 회의 결과를 체계적으로 기록하고 공유하는 방식을 따른다. 개발 프로세스는 Scrum 방식을 기반으로 운영한다. 스프린트는 1주일 단위로 구성되며, 스프린트 시작 시에는 스프린트 계획 회의(Planning) 를 진행하여 이번 주의 주요 개발 목표를 설정한다. 매일 데일리 스크럼을 통해 팀원들이 각자의 진행 상황을 공유하며, 장애 요소나 협력이 필요한 사항을 빠르게 조율한다. 매주 스프린트 종료 시에는 그 주에 개발한 기능이나 프로토타입을 프로토타입 시연(Prototype Demo) 형태로 공유하고, 이를 바탕으로 스프린트 회고(Retrospective) 를 실시하여 개발 과정에서의 문제점과 개선사항을 도출한다. 전체 개발 일정은 1주일 단위 스프린트를 기준으로 관리하여, 명확한 목표 설정과 주기적인 점검을 통해 일관성 있는 개발 흐름을 유지하고자 한다.
◇ 형상 관리 형상 관리는 GitHub를 통해 진행하며, 브랜치 전략은 git-flow 모델을 기반으로 간소화해 운영한다. 업무 단위 또는 기능별 개발은 별도의 브랜치를 생성하여 관리하고, 작업 완료 시에는 Pull Request(PR)을 생성하여 코드 리뷰를 요청한다. Merge 방식은 Squash and Merge를 기본으로 사용하여, 작업 이력을 깔끔하게 관리하고자 한다. PR 작성자는 팀원의 승인(Approve)을 받은 후, 본인이 직접 PR을 Merge하는 절차를 따른다. 이를 통해 리뷰와 승인 과정을 명확히 거친 뒤 안정적으로 개발 통합을 수행한다.
◇ 코드 리뷰 프로세스 PR(Pull Request) 작성 시에는 일정한 규칙을 따른다. PR 제목은 [type] subject 형식으로 작성하며, type은 작업의 성격에 따라 구분한다. 주요 타입 종류로는 기능 추가를 의미하는 feat, 버그 수정을 나타내는 fix, 문서 수정 작업인 docs, 코드 포맷팅 및 비기능성 수정을 위한 style, 코드 리팩토링을 나타내는 refactor, 테스트 코드 추가 및 수정을 나타내는 test, 빌드 설정 변경이나 기타 작업을 의미하는 chore가 있다. PR 제목은 예를 들어 feat: 사용자 로그인 기능 추가와 같이 작성하며, 제목의 첫 단어는 반드시 소문자로 시작한다. PR 본문은 두 부분으로 구성한다. 본문(body)에는 작업 내용 요약, 구현 방법, 팀원과 공유할 필요가 있는 정보 등을 작성하며, 꼬리말(footer)에는 이슈 번호 연결 정보를 포함한다. 이슈 연결은 resolves: #123과 같이 작성하여, PR이 특정 이슈를 해결하는 것임을 명시한다. PR 작성 후에는 반드시 팀원 중 1명 이상을 Reviewer로 지정하여 코드 리뷰를 요청한다. Reviewer는 기능 요구사항 충족 여부, 코드의 가독성과 유지보수성, 잠재적인 버그나 예외 처리 누락 여부, 코딩 스타일 준수 여부, 그리고 성능 최적화 여부 등을 중심으로 검토를 진행한다. 리뷰 과정에서 피드백이 발생하면, 작성자는 해당 피드백을 반영하여 코드를 수정하고 다시 리뷰를 요청한다. 모든 리뷰가 완료되고 승인이 이루어진 이후에는 PR 작성자가 본인의 PR을 직접 Merge한다.
◇ Git 브랜치 네이밍 규칙 Git 브랜치 관리는 명확한 네이밍 규칙을 따른다. 배포를 위한 메인 브랜치는 main, 개발 통합을 위한 브랜치는 dev로 고정하여 사용한다. 개별 업무나 이슈 단위의 작업은 issue/#이슈번호 형식으로 브랜치를 생성하여 진행한다. 작업 흐름은 다음과 같다. 우선 GitHub에서 새로운 이슈를 생성하고, 이슈 번호를 확인한다. 이후 로컬 환경에서 issue/#이슈번호 형식으로 새로운 작업 브랜치를 생성하고, 해당 브랜치에서 목표 기능을 개발한다. 개발 완료 후 PR을 생성하여 팀원에게 리뷰를 요청하며, 리뷰 완료 및 Merge 이후에는 작업 브랜치를 삭제하고 관련 이슈를 종결한다.
설계
설계사양
액터 정의
기능 요구사항 정의
유스케이스 정의
UML Diagram
Sequence Diagram
- 주요 유스케이스 - UC220: 상품 목록 열람
진행 과정: 콘텐츠 목록 요청 및 표시 사용자는 메인 페이지 UI에 콘텐츠 목록을 요청한다. (requestToViewContent) 메인 페이지 UI는 큐레이션 시스템에 콘텐츠 미리보기 목록을 요청한다. (fetchPreviewList()) 큐레이션 시스템은 게임 객체 집합으로부터 미리보기 정보를 요청한다. (getPreview()) 각 게임 객체는 큐레이션 시스템에 미리보기 정보를 반환한다. (preview) 큐레이션 시스템은 메인 페이지 UI에 콘텐츠 미리보기 목록을 전달한다. (previewList) 메인 페이지 UI는 사용자에게 콘텐츠 목록을 화면에 출력한다. (displayContents) 콘텐츠 상세 조회 및 화면 출력 1. 사용자는 특정 콘텐츠에 대한 상세 정보를 요청한다. (requestDetails) 2. 메인 페이지 UI는 콘텐츠 상세 페이지 UI로 화면을 전환한다. (navigate) 3. 콘텐츠 상세 페이지 UI는 게임 객체(a game)에 콘텐츠 상세 정보를 요청한다. (getDetails()) 4. 게임 객체(a game)는 콘텐츠 상세 정보를 콘텐츠 상세 페이지 UI에 반환한다. (detail) 5. 콘텐츠 상세 페이지 UI는 사용자에게 콘텐츠 상세 정보를 출력한다. (showDetail)
- 주요 유스케이스 - UC310: 판매 개시
진행 과정: 게임 등록 화면 진입 1. 사용자는 메인 페이지 UI에서 ‘Submit Game’ 버튼을 클릭한다. (ClickRegisterButton) 2. 메인 페이지 UI는 게임 등록 페이지 UI로 이동한다. (navigate) 3. 게임 등록 페이지 UI는 게임 등록 화면을 사용자에게 보여준다. (showPage) 콘텐츠 기본 정보 입력 및 검증 1. 사용자는 상품 정보를 입력한다. (provideProductInformation) 2. 게임 등록 페이지 UI는 입력된 정보를 검증하고 사용자에게 결과를 반환한다. (validInformation) 3. 사용자는 태그를 선택한다. (selectTag) 4. 게임 등록 페이지 UI는 선택된 태그의 유효성을 검증한다. (validTag) 파생 콘텐츠일 경우의 처리 (opt) 1. 사용자가 등록하는 콘텐츠가 파생 콘텐츠인 경우, 원작 IP 코드를 입력한다. (EnterIPCode) 2. 게임 등록 페이지 UI는 IP 코드의 유효성을 검증하고 결과를 반환한다. (validIPcode) 콘텐츠 파일 업로드 및 등록 1. 사용자는 게임 파일을 업로드한다. (uploadFile) 2. 게임 등록 페이지 UI는 업로드된 파일의 유효성을 검증한다. (validFile) 3. 사용자는 최종적으로 ‘Launch’ 버튼을 누른다. (pushLaunchButton) 4. 게임 등록 페이지 UI는 새로운 게임 인스턴스를 생성한다. (create → A game : Game)
- 주요 유스케이스 - UC340: 할인 개시
진행 과정: 판매 중인 상품 목록 조회 1. 사용자는 라이브러리 페이지 UI에 자신이 판매 중인 콘텐츠 목록 조회를 요청한다. (viewSellingProductList) 2. 라이브러리 페이지 UI는 사용자에게 판매 중인 콘텐츠 목록을 출력한다. (displaySellingProductList) 할인 시작 팝업 활성화 1. 사용자는 특정 콘텐츠의 할인 시작 버튼을 클릭한다. (clickDiscountStartButton) 2. 라이브러리 페이지 UI는 할인 정보를 입력할 수 있는 팝업을 출력한다. (showDiscountPopup) 할인 정보 입력 및 등록 요청 1. 사용자는 할인율과 할인 기간을 입력하고 할인 시작을 요청한다. (enterDiscountRateAndPeriod && startDiscount) 2. 라이브러리 페이지 UI는 새로운 할인 인스턴스를 생성한다. («create» A discount : Discount) 3. 생성된 할인 인스턴스는 해당 콘텐츠(게임)에 할인 정보를 등록한다. (registerDiscountInfo(discountDetails)) 4. 게임 객체는 할인 정보를 성공적으로 등록했음을 할인 인스턴스에 응답한다. (registerSuccess) 5. 할인 인스턴스는 라이브러리 UI에 할인 생성 완료를 알린다. (createSuccess) 6. 라이브러리 UI는 사용자에게 할인 시작 완료를 알린다. (notifyDiscountStart)
- 주요 유스케이스 - UC411-UC412: API 활용 상품 구매 - 스마트 컨트랙트 활용 상품 구매
진행 과정: 결제 UI 진입 및 금액 선택 1. 사용자는 게임 구매 페이지 UI에서 결제 버튼을 클릭한다. (clickPurchaseButton) 2. UI는 결제 팝업을 사용자에게 표시한다. (showPurchasePopup) 3. 사용자는 결제할 금액을 선택한다. (selectAmountToPay) 4. UI는 결제 방식 선택을 위한 드롭다운 버튼을 표시한다. (displayDropdownButton) 결제 방식 선택 – 분기 처리 (alt) [분기 A] Fintech 결제 버튼 클릭 시 1. 사용자는 핀테크 결제 버튼을 클릭한다. 2. UI는 핀테크 API 제공자에게 결제를 요청한다. (requestViaFintech) 3. 핀테크 API 제공자는 purchase() 동작을 수행한다. 4. 결제 팝업이 표시된다. (showPaymentPopup) 5. 결제가 처리되며, 결제 내역이 반환된다. (processThePayment → paymentHistory) 6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess) [분기 B] 스테이블 코인 결제 버튼 클릭 시 1. 사용자는 스테이블 코인 결제 버튼을 클릭한다. 2. UI는 사용자의 암호화폐 지갑에 결제를 요청한다. (requestViaStableCoin) 3. 결제 팝업이 표시된다. (showPaymentPopup) 4. 결제가 처리되며, 사용자의 지갑이 purchase() 동작을 수행한다. 5. 결제 내역이 UI로 반환된다. (paymentHistory) 6. UI는 사용자에게 결제 완료를 알린다. (notifyPaymentSuccess)
- 주요 유스케이스 - UC510-UC520: 리소스 열람 - 리소스 사용 계약
진행 과정: 리소스 정보 조회 1. 사용자는 게임 구매 페이지 UI에서 리소스 상세 정보를 조회한다. (browseResourceDetails) 2. UI는 리소스 객체에 리소스 세부 정보를 요청한다. (getResourceDetails()) 3. 리소스 객체는 요청된 정보를 UI에 반환한다. (resourceDetails) 4. UI는 사용자에게 리소스 정보를 출력한다. (displayResourceDetails) 거래 조건 동의 및 스마트 컨트랙트 실행 1. 사용자는 거래 조건에 동의한다. (agreeToTerms) 2. UI는 사용자의 암호화폐 지갑에 스마트 컨트랙트 실행을 요청한다. (invokeSmartContract()) 스마트 컨트랙트를 통한 블록체인 거래 1. 사용자의 암호화폐 지갑은 스마트 컨트랙트에 서명 및 실행 요청을 보낸다. (signAndExecuteTransaction()) 2. 스마트 컨트랙트는 블록체인에 거래 정보를 저장한다. (storeInformation()) 3. 블록체인은 거래 해시값을 스마트 컨트랙트에 반환한다. (transactionHash) 4. 스마트 컨트랙트는 거래 상태를 사용자 지갑에 반환한다. (transactionStatus) 5. 사용자 지갑은 거래 상태를 UI에 전달한다. (transactionStatus) 6. UI는 사용자에게 거래 완료 메시지와 상태를 표시한다. (displaySuccessMessageWithTransactionStatus)
UI 구성
◇ UI 플로우차트
해당 UI Flow Chart는 플랫폼 사용자, 판매자, 관리자 각 역할별로 수행할 수 있는 주요 UI 흐름을 정리한 것이다. 상단에서 메인 메뉴 구조를 시작으로 하여, 하위 행동 단계들이 절차적으로 구성되어 있으며, 요구사항 명세서의 유스케이 스와 연동되어 있다. 1. 초기 진입 및 사용자 인증 흐름 사용자는 메인 페이지에서 로그인/회원가입을 선택할 수 있으며, 이메일 또는 전자지갑 인증을 통해 계정을 생성한다. 로그인 후 플랫폼 기능 접근이 가능하며, 이는 UC111 (계정 생성), UC120 (로그인/로그아웃) 등의 요구사항과 대응된다. 2. 게임 검색 및 상세 정보 조회 메인 페이지에서는 게임 검색 또는 상품 등록 기능으로 진입할 수 있으며, 검색어 입력 또는 태그 필터를 통해 원하는 상품 목록을 조회할 수 있다. 사용자는 원하는 게임 슬롯을 선택하여 상세 페이지로 진입할 수 있으며, 이 흐름은 UC210 (검색어 기반 검색), UC220 (상품 목록 열람)에 해당한다. 3. 상품 등록 및 판매 판매자는 상품 등록 페이지에서 게임 정보를 입력하고, 상품 설명, 가격, 태그, 티저 이미지 등을 포함하여 업로드할 수 있다. 상품 등록 시 리소스를 함께 게시할 수 있으며, 파생 콘텐츠인 경우 IP 코드 입력을 통해 연계 정보를 제공한다. 해당 흐름은 UC310 (판매 개시), UC320 (리소스 게시)로 대응된다. 4. 상품 상세 페이지에서의 사용자 행동 사용자는 상품 상세 페이지에서 신고 버튼 클릭 또는 구매 버튼 클릭을 선택할 수 있다. 신고는 UC810 (콘텐츠 신고) 흐름과 연결되며, 관리자에 의해 확인되어 처리된다 (UC820). 구매를 선택한 경우 핀테크 API 또는 전자지갑 기반 결제 방식 중 하나를 선택할 수 있다. 5. 구매 및 결제 프로세스 구매 버튼 클릭 후, 사용자는 결제 방식(핀테크 / 전자지갑)을 선택한다. 핀테크 API의 경우 외부 결제 창이 호출되며 결제 완료까지 연결된다. 지갑 결제는 스테이블 코인을 이용하며 스마트 컨트랙트를 통해 처리된다. 이 전체 프로세스는 스마트 컨트랙트 기반 구매 및 거래 기록 생성까지 이어지며, 블록체인에 기록되는 흐름으로 확장된다. 이는 UC411, UC412 (API 활용 상품 구매, 스마트 컨트랙트 활용 상품 구매)으로 이어진다. 6. 마이페이지 기능 사용자는 마이페이지에서 정보를 수정하거나 계정을 삭제할 수 있으며, 구매 목록 및 판매 상품 목록, 할인 설정 등을 관리할 수 있다. UC130 (계정 정보 수정), UC140 (전자지갑 연동), UC420~UC430 (구매 이력, 다운로드), UC331~UC340 (판매 목록 열람, 판매 상품 정보 수정, 할인 개시) 등의 유스케이스가 해당된다. 7. 관리자 기능 관리자 페이지에서는 상품 판매 상태 설정, 계정 관리, 신고 확인, 배너 편집 및 알림 발송 등 전반적인 플랫폼 운영 기능이 배치되어 있다. 이는 UC610~UC820에 해당하는 관리자용 유스케이스들과 연결된다.
◇ UI 와이어프레임 사이트화면구성 와이어프레임
구매자와 판매자가 사이트에 로그인하고, 게임을 탐색, 판매, 등록, 다운로드하는 화면들의 구성
관리자페이지 와이어프레임
관리자가 신고를 접수, 알림을 보내고 특정 상품의 정보를 확인, 판매를 중단하는 화면들의 구성
시스템 설계
◇ 전체 시스템 구성
(Cryptocurrency Wallet은 구현 사항이 아닌 외부 소프트웨어임) 프론트엔드: 유저가 DApp과 상호작용하기 위한 UI를 제공하고, 데이터베이스와 스마트 컨트랙트에 백엔드가 특정 정보를 입출력 해주는 것을 요청할 수 있다. 또한 Ingegration Library를 통해 스마트 컨트랙트 상의 정보를 직접 확인할 수 있다. 본 프로젝트에서는 구현에 node.js와 React 프레임워크, Express를 사용하였다 백엔드: UI 상의 유저 조작으로 인해 발생한 입출력 요청을 기반으로 데이터베이스와 스마트 컨트랙트에 데이터를 입출력한다. 본 프로젝트에서는 node.js와 Express를 사용하였고, 실제 서버 동작에는 AWS 클라우드를 사용하였다 데이터베이스: DApp 상에서 스마트 컨트랙트 상에 저장할 수 없는 데이터를 저장하는 공간으로 기능한다. 본 프로젝트에서는 MySql을 사용하였고, 실제 데이터베이스 동작에는 AWS 클라우드를 사용하였다 통합 지원 라이브러리: 블록체인에 정의된 스마트 컨트랙트를 호출하기 위하여 인증 및 서명과 같은 기능에 복잡한 과정을 캡슐화한 타입을 정의한 라이브러리로 기능한다. 본 프로젝트에서는 node.js를 사용하였고, 스마트 컨트랙트 호출을 위한 모듈로서 ethers.js (v6)를 사용했고, 호출을 위한 API 서비스로는 Alchemy를 사용하였다 EVM(Ethereum Virtual Machine): 이더리움 블록체인 전체가 같은 상태 값을 유지하는 가상 머신 으로서, 프로젝트 진행 중에 정의한 스마트 컨트랙트가 프로그램으로서 작동하고 있다. 컨트랙트 코드의 작성에는 OpenZeppelin 라 이브러리가 사용되었다.
스마트 컨트랙트 설계
◇ 컨트랙트 다이어그램
◇ 컨트랙트 구성 IERC20 (OpenZepplin) ERC-20 표준을 구현하는 컨트랙트들에 대한 인터페이스로서, 대체 가능한 토큰(Fungible Token)을 사용하기 위한 함수들, 즉 토큰 계좌 잔액 확인, 토큰 전송 등이 정의되어 있고, 다른 전자지갑 소유자 혹은 프로그램이 토큰 전송을 대 행해주는 것을 승인해줄 수 있는 함수 역시 정의되어 있다 IERC20Permit (OpenZeppelin) ERC-20 표준의 확장인 EIP-2612를 구현하는 컨트랙트에 대한 인터페이스로서, 다른 계좌 소유자 혹은 프로그램에서 토큰 전송을 대행해 주는 작업을 별도의 트랜잭션 없이 오프체인에서 생성한, 검증 가능한 서명을 기반으로 할 수 있는 함수가 정의되어 있다 IERC721 (OpenZepplin) ERC-721 표준, 즉 NFT를 구현하는 컨트랙트의 인터페이스. 해당 인터페이스를 통해 주소별로 소유하고 있는 NFT들을 확인할 수 있고, 특정 NFT에 대해 소유권자의 주소를 확인할 수 있으며, 소유자가 특정 주소로 자신의 NFT를 전송. 또한, 별도의 승인 과정을 거치는 경우 승인 받은 주소의 호출자가 특정 주소에서 다른 주소로 특정한 NFT를 전송한다. ERC2771Context (OpenZeppelin) ERC-2771 표준, 즉 메타트랜잭션이 수행되는 컨트랙트. 해당 컨트랙트는 릴레이어라는 별도의 주소에서 호출한 요청에 대해 그것이 대리하고 있는 실제 호출의 정보를 확인한다. ERC2771Forwarder (OpenZeppelin) 메타트랜잭션에서 RPC로 요청된 함수 호출에 대해 그 호출이 특정 주소의 호출을 대리하는 호출임을 서명 검증 과정을 통해 확인하는 컨트랙트로서, ERC2771Context 컨트랙트 생성 시에 주입되어 ERC2771Context가 수행하는 호출 들에 대해 그 호출이 안전한 대리자 호출임을 보증한다. Ownable (OpenZeppelin) 컨트랙트가 특정 주소에 의해 소유되었다고 명시할 수 있으며, 특정 함수를 오직 해당 컨트랙트의 소유자만이 호출할 수 있도록 제한할 수 있는 onlyOwner modifier를 제공한다 OwnableERC2771Context Ownable 컨트랙트와 ERC2771Context를 다중 상속하는 컨트랙트, 본 시스템의 다수의 컨트랙트가 상속한다 Store 아이템의 구매 요청을 확인하는 컨트랙트로, 구매 요청을 PaymentProcessor에 넘겨 실제 토큰 지불 과정이 수행되도록 하며, Ledger 컨트랙트에 해당 구매에 대한 NFT 토큰 발급을 요청한다 ProfitEscrow 아이템의 구매로 인해 발생한 수익에 대하여 특정 판매자 계좌가 얼마나 많은 토큰을 받기로 되어 있는지 기록하는 에스크로 역할의 컨트랙트로서, 판매자는 이 컨트랙트를 통해 자신의 수익을 확인하고, 해당 수익을 요청할 수 있다. 또한 Web2 금융 인프라에 의해 수행된 결제의 수익은 Owner가 지불할 예정인 토큰의 양이 기록되고, Owner는 실제 토큰을 해당 컨트랙트에 입금하고 정산 기능을 호출함으로써 결제된 수익을 판매자가 요청 가능한 상태로 변경할 수 있다 PaymentProcessor 구매 요청을 받아 구매할 아이템의 가격과 해당 아이템에서 발생하는 수익의 분배 조건을 확인하여 구매자의 주소로부터 토큰을 이체하여 여러 개의 판매자 주소에 대해 어떤 판매자가 얼마나 수익을 가져가야 하는지 ProfitEscrow에 기록 요청을 전달하고, 수수료에 해당하는 양만큼 Owner 계좌에 전달한다 PriceTable 아이템의 가격이 관리되는 컨트랙트로, 오직 아이템의 판매자만이 아이템의 가격을 변경할 수 있도록 하는 기능을 제공하며, 한 아이템에서 파생된 아이템들에 대하여 수익 배분이 어떻게 진행되는지의 정보를 기록할 수 있고, 할인 및 특정 아이템에 대한 수익 지분율 감면을 통한 IP 전체에 대한 할인 기능을 지원한다 Ledger 아이템의 구매가 일어날 때 해당 구매 이력에 대한 정보를 저장하고 이에 대한 NFT를 발행하는 컨트랙트이다 ItemRegistry 판매자가 자신이 판매할 상품 및 상품의 파생 상품에 대한 로열티 조건을 등록할 수 있는 컨트랙트이다. 또한, Owner는 문제를 발생시킨 상품에 대해 판매를 중단할 수 있고, 문제가 해결되는 경우 판매를 재개할 수도 있다 PurchaseProxy 이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 구매하는 경우, 이에 대해 해당 상품에서 발생한 수익을 Owner가 지불할 예정임을 Store에 알려서 수익 정산 예정 상황을 기록하게 하고, Ledger로 하여금 구매 이력을 기록하 도록 하는 역할을 수행하는 컨트랙트이다. 유저는 자신이 구매한 상품타에 대해 구매 이력을 확인하고, 이에 대한 권한을 전자지갑으로 옮기도록 할 수 있다 SellerProxy 이더리움 전자지갑이 없는 사용자가 Web2를 통해 상품을 등록한 경우, 해당 아이템에 대해 가격 및 수익 지분율 조정과 같은 작업을 수행할 수 있게 하고, 자신의 상품 수익에 의해 발생한 수익을 Web2로 정산한 경우 해당 양과 동등한 토 큰을 ProfitEscrow로부터 플랫폼이 관리하는 주체의 계좌로 옮길 수 있다
서버 아키텍처
◇ 아키텍쳐 다이어그램
◇ 구조 설명: 마이크로서비스 아키텍쳐 프론트엔드의 요청을 처리할 때 서버가 각각의 서비스를 분리하여 처리할 수 있도록 마이크로서비스 아키텍처를 사용한다. 구성되는 서비스의 목록은 다음과 같다 - 유저 계정 관리 서비스 - 파일 정보 관리 서비스 - 관리자 계정 관리 서비스 - 이더리움 블록체인과 상호작용을 위한 Web3 관련 서비스 - 게임 및 리소스 파일의 다운로드 서비스 - 파일 업로드 서비스 각각의 서비스에 대해 마치 각각에 대해 별도의 서버가 존재하는 것처럼 서버를 작성하여, 논리적으로 분리되는 서비스 단위를 물리적으로도 분리하여 유지보수성이 높은 서비스를 제공한다
◇ 구현 전략: 도커 컨테이너 오케스트레이션 각각의 마이크로서비스를 도커를 사용하여 구성한다. 각각의 서비스는 각각의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 작동하며, 이 전체의 조화 작업을 쿠버네티스를 사용하여 오케스트레이션한다. 이때 컨테이너 간 호출을 위한 기술로서 gRPC를 사용하도록 한다
◇ 지원 기술 서비스 아키텍쳐를 뒷받침하는 Backing Sevice들의 목록은 다음과 같다 - AWS RDS: MySql 데이터베이스 입출력을 담당하는 AWS 클라우드의 서비스 - Redis: DB 입출력, 로그인 세션 유지를 위한 Json Web Token Refresh등 빈번한 작업에 캐싱을 수행하는 인프라로 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작하며, 전체 서비스의 지원을 담당한다 - Qdrant: 웹앱 상에서 검색 기능을 제공하기 위해 DB 상의 텍스트 데이터들에 대해 생성한 워드 임베딩 벡터들을 담당하는 임베딩 벡터 전용 DB로서 별도의 도커 컨테이너로 캡슐화되어 AWS EC2 머신 상에서 동작한다 - AWS S3: 웹앱 상에서 제공하는 게임, 리소스등의 파일을 저장하고 관리하기 위한 전용 서비스이다
DB 설계
◇ ER 다이어그램
◇ DB 테이블 구성 account - 사용자 및 관리자의 정보를 저장하는 테이블 - 비밀번호는 해시값을 저장하여 DB 관리자가 비밀번호를 알 수 없도록 한다. - 사용자 또는 관리자임을 나타내는 컬럼을 사용하여 구분한다. - 전자지갑은 다수를 소유할 수 있으므로 무결성을 지키기 위해 별도의 테이블로 둔다. - 잘못을 범한 유저의 계정 정지/해제를 다룰 테이블을 sanction Table로 둔다. game - 플랫폼에 등록되는 게임의 정보를 저장하는 테이블 - 다운로드 URL는 File Chunk단위로 나눠 다운로드를 가능하게 할 예정으로, 여러 URL이 필요해 무결성을 지키기 위해 별도 테이블로 만든다. - 게임 구동사양 또한 게임별로 자유롭게 여러 항목을 개발자 재량으로 작성할 수 있도록 별도 테이블로 만든다. - 원작 게임과 파생 게임의 구분을 위한 origin_or_variant 컬럼이 존재한다. - 파생 게임의 경우 원작 게임이 어떤 것들이 있는지를 저장할 origin_game 테이블 별도로 존재한다. - 태그들을 저장할 테이블을 game_tag Table로 별도로 둬 무결성을 지킨다. resource - 등록된 게임에서 판매 또는 공유할 리소스를 저장할 테이블 - game Table과 마찬가지로 개발자 재량으로 이미지 및 다운로드URL를 제공하도록 별도 테이블로 존재한다. transaction - 거래 목록을 담당하는 테이블 - 무결성을 위해 게임 거래와 리소스 거래를 구분하여 각각 테이블로 존재한다. report - 유저가 약관위반 등 플랫폼에 등록된 게임에 문제가 있다고 판단했을 때 신고한 내역을 저장하는 테이블 - 내용과 담당한 관리자의 정보들을 저장한다. sended_email - 관리자가 유저에게 알림을 보낸 정보를 기록하는 테이블
결과 및 평가
완료 작품의 소개
프로토타입 사진 혹은 작동 장면
◇ 메인 화면
- 사용자에게 다양한 게임을 소개하는 LUDEX 플랫폼의 메인 페이지이다. 상단에는 로고, 검색창, 메뉴(Home, Submit Game, My Page)가 위치해 있으며, 중앙에는 대표 게임을 강조하는 배너가 배치되어 있다. 배너 오른쪽에는 장르 또는 태그별로 게임을 탐색할 수 있도록 태그 버튼들이 나열되어 있다. 하단에는 등록된 게임들이 썸네일 카드 형식으로 정렬되어 있으며, 각 게임을 클릭하면 상세 페이지로 이동할 수 있다.
◇ 게임 상세 정보 화면
- 선택한 게임의 상세 정보를 보여주는 페이지로, 게임 플레이 화면이 슬라이드 형식으로 표시되며, 오른쪽에는 게임 제목, 가격, 제작자, 설명, 장르 태그, 구동 사양 등의 정보가 제공된다. 또한 왼쪽 하단에는 해당 게임의 파생 게임 상세 페이지로 이동할 수 있는 썸네일 이미지가 표시된다. 하단에는 “Buy” 버튼이 있어 사용자가 게임을 구매하거나 이전 화면으로 돌아갈 수 있다.
◇ 검색 화면
- 상단의 검색창에 검색어를 입력하거나, 메인 화면에서 태그를 클릭하면 진입하는 검색 화면이다. 입력된 검색어는 태그, 게임명(영문/한글), 게임 설명에 속하거나 그에 유사하다 판단되는 항목들과 매치되어 관련된 태그 또는 게임이 검색 결과로 나타난다.
◇ 결제 화면
결제 수단 선택 모달
- 게임 상세 페이지에서 “Buy” 버튼을 클릭했을 때 나타나는 결제 수단 선택 모달이다. 다양한 결제 방식을 제공하여 사용자 편의성과 접근성을 높이는 것을 목표로 한다.
전자지갑 결제 모달
- 결제 수단 선택 모달에서 결제 수단으로 전자지갑 결제를 선택한 경우 나타나는 모달이다. 블록체인 기반의 토큰(USDC)을 활용한 결제를 진행할 수 있도록 구성되어 있다.
카드 결제 모달
- 결제 수단 선택 모달에서 카드 결제를 선택했을 때 연동되는 토스페이먼츠(Toss Payments)의 카드 결제 모달이다. 실제 결제는 신용카드 및 간편결제 수단을 통해 이루어지며, 사용자는 원하는 수단을 선택 후 인증을 거쳐 결제를 완료할 수 있다.
◇ 게임 등록 화면
- 게임을 플랫폼에 등록할 수 있는 게임 등록 화면이다. 게임 등록 시에는 게임 파일 뿐만 아니라 썸네일, 설명, 가격 등 게임의 메타데이터도 함께 입력하게 된다. 또한, 해당 게임에서 사용된 리소스를 함께 등록하고자 할 경우, 게임 등록 과정에서 동시에 리소스 등록도 진행할 수 있다. 리소스 등록 시에는 리소스 파일, 설명, 미리보기 이미지, 수익 분배 비율, 사용 조건, 추가 조건 등의 정보를 입력하게 된다. 여기서 설정하는 수익 분배 비율은, 이 리소스를 다른 제작자가 구매해 파생 게임을 제작 및 등록했을 경우, 해당 게임의 판매 수익을 원작자와 파생 제작자가 어떻게 나누게 될지를 결정하는 기준이 된다.
◇ 마이페이지 화면
- 사용자의 마이페이지 화면으로, 기본 정보(닉네임, 이메일, 지갑 주소)와 함께 구매 및 판매 내역, NFT 조회, 다운로드 기능, 정산(Payout) 등을 확인하고 관리할 수 있다.
구매기록 화면
- 마이페이지 내 구매 기록 상세 화면으로, 구매한 게임 리스트와 함께 각 항목의 다운로드, NFT 발급 여부를 확인할 수 있으며, 구매한 리소스에 대한 정보도 하단에 함께 표시된다
판매기록 화면
- 마이페이지 내 판매 기록 화면으로, 사용자가 등록한 게임 목록과 함께 각 게임의 가격, 설명, 이미지, 할인 설정(Set Discount) 및 수정(Edit) 기능을 확인하고 관리할 수 있다.
Web3 구매 게임 NFT 조회 모달
- Web3 방식으로 구매한 게임의 NFT 발급 정보를 확인하는 팝업 화면으로, Token ID, Item ID, 구매자 지갑 주소, 구매 일시 등의 정보를 보여준다.
정산요청 모달
- 사용자가 판매 수익에 대한 정산 요청을 진행하는 화면으로, 정산할 게임과 등록된 지갑 주소를 선택한 뒤 "정산 요청" 버튼을 눌러 수익을 출금할 수 있다.
지분감면 할인 모달
- 지분 감면 기반 할인 설정 팝업 화면으로, 할인 기간과 함께 감면율(%)을 입력하면 자동으로 감면된 지분이 계산된다. 설정된 감면율은 해당 게임을 기반으로 제작된 파생 게임들에 할인 혜택으로 적용된다.
◇ 관리자 화면
유저 관리 화면
- 관리자가 전체 사용자 목록을 조회하고 차단 여부를 설정할 수 있는 유저 관리 페이지로, 닉네임 또는 이메일로 검색이 가능하며 각 사용자에 대해 "set block" 기능을 통해 제재 조치를 적용할 수 있다.
게임 관리 화면
- 관리자가 등록된 게임 목록을 조회하고 차단/해제할 수 있는 콘텐츠 관리 페이지로, 게임명 또는 설명을 검색해 상세 정보를 확인하고 "set block" 또는 "set unblock" 버튼을 통해 게임의 공개 여부를 제어할 수 있다.
관련사업비 내역서
완료작품의 평가
향후계획
- 어려웠던 내용들
◇ 스마트 컨트랙트 및 Web3 관련 개발 환경은 아직 인프라가 완전히 성숙하지 않은 상태라, 통합된 공식 문서를 찾기 어렵고, 자료 간의 일관성도 부족했다. Solidity 언어 자체가 아직 버전 1 이전이며, 버전에 따라 문법이나 기능이 상이한 점이 많았다. 또한 Web3 라이브러리로 사용한 ethers.js의 경우 최신 버전인 v6을 기준으로 개발을 진행했지만, 기존 문서들은 대부분 v5를 기준으로 작성되어 있어 적용에 혼선을 겪었다. 참고용으로 도서관에서 관련 교재를 대출해 공부했으나, MetaMask의 경우 교재 집필 당시에는 지원되던 기능이 우리가 학습하던 시점에서는 더 이상 제공되지 않아 학습 자료의 신뢰성에도 어려움이 있었다.
◇ Web3 외적인 부분에서도 여러 난관이 존재했다. Web3 분야가 아직 생소하고, 이미 시장에는 다양한 유사 서비스가 존재하다 보니 차별화된 방향성을 설정하는 것이 쉽지 않았다. 기획 단계에서는 상품성 있는 아이템을 도출하는 것이 가장 큰 과제였다. 프로젝트 주제에 대한 제한이 없었던 만큼, 어떤 소비자층을 타겟으로 어떤 기능과 서비스를 제공할 것인지 결정하는 데 많은 시간이 소요되었고, 유사 서비스와의 비교를 통해 차별점을 찾는 과정에서도 끊임없는 검토와 고민이 필요했다.
◇ 개발 측면에서는 백엔드 개발 경험이 두 번째인 팀원이 있어, 프로젝트 구조를 잡거나 기능을 설계하는 과정에서 시행착오가 많았다. 특히 Web3와 결합된 백엔드 구조는 일반적인 웹 개발보다 구조가 복잡하고 고려해야 할 보안 요소도 많아 학습과 구현을 병행하는 데 부담이 컸다.
◇ 서비스 간 책임 및 리소스 분리를 위해 쿠버네티스(Kubernetes) 클러스터를 도입했지만, 이 과정에서도 적지 않은 어려움을 겪었다. 기존에 사용하던 서버 인프라와 쿠버네티스 기반 인프라는 구성 방식과 운영 방식에 큰 차이가 있었고, 특히 CI/CD 파이프라인을 새롭게 구축하는 과정에서 설정 방식과 배포 방식의 차이로 인해 시행착오가 반복되었다. 클러스터 내 서비스 간 연결, 환경 변수 관리, 볼륨 설정 등 인프라 레벨의 개념들이 익숙하지 않아 초기 세팅과 디버깅에 많은 시간이 소요되었다. 결과적으로 이는 개발보다 인프라 운영 측면에서 예상보다 더 많은 리소스를 요구하는 작업이었다.
◇ 팀 내 일부 구성원이 게임 산업에 대한 경험이 부족했던 점도 기획과 UX 설계에 영향을 미쳤다. 게임을 평소 즐기지 않다 보니, 소비자 입장에서 어떤 요소가 매력적으로 작용할지 예측하기 어려웠고, 사용자 니즈나 시장 흐름에 대한 인식이 낮아 기능 제안이나 설계에 확신을 가지기 힘들었다. 결과적으로, 기술적인 문제뿐만 아니라 콘텐츠 기획과 소비자 이해도 측면에서도 다방면의 고민이 필요한 프로젝트였다.
- 차후 구현할 내용
◇ 개발자간 수익 분배 기능 확장 - 인디게임은 소규모 개발자 또는 법인 간의 협업이 빈번하게 이루어지는 구조다. 그러나 현재의 수익 분배 방식은 플랫폼으로부터 수익을 수령한 팀 리더가 이를 팀원에게 개별적으로 분배하는 형태로, 신뢰성 부족과 함께 리더에게 장기간의 관리 책임이 과도하게 부여된다는 단점이 있다. 특히 게임 수익이 수년, 혹은 수십 년간 발생할 수 있다는 점에서 리더 개인에게 지속적인 관리 책임이 부담으로 작용한다. 현재 itch.io나 Game Jolt 등 인디게임 중심 플랫폼에서는 이러한 협업 구조에 적합한 수익 분배 시스템을 제공하지 않는다. 이는 기술적인 제약 때문인데, 예컨대 Web2 기반의 금융 인프라는 소액 정산 시 건당 수수료가 발생하는 구조여서 효율적인 분배가 어렵다. 또한 에스크로 방식의 경우, 거래 기록을 데이터베이스 상에서 관리하고 별도의 확인 절차를 요구하는 번거로움이 존재한다. Ludex는 이러한 문제를 이더리움 기반 스마트 컨트랙트를 통해 해결할 수 있다. 스마트 컨트랙트는 본질적으로 신뢰 가능한 에스크로 역할을 수행하며, 소액 정산의 경우에도 고정된 건당 수수료가 아닌 연산 비용 기반의 수수료 구조이기 때문에 경제적이다. 아울러 컨트랙트 구현 난이도도 낮아, 비교적 빠른 시간 안에 해당 기능을 플랫폼에 확장 적용할 수 있다
◇ 게임 등급 분류 제도 대안책 BM 확장 - 대한민국에서는 게임을 유료로 배포하기 위해 게임물관리위원회의 등급 분류를 반드시 받아야 한다. 이 제도는 일종의 사전 검열로 기능하며, 절차의 복잡성이나 높은 수수료로 인해 인디 개발자들에게는 진입장벽으로 작용하고 있다. 특히 일부 게임의 경우 심의 수수료가 100만 원을 넘기기도 하여 영세 개발자들에게 큰 부담이 된다. 이러한 문제를 해결하기 위해 Ludex는 예치금 기반의 예약 구매 시스템을 제안한다. 이 시스템은 판매가 개시되기 전, 소비자가 구매 대금을 컨트랙트에 예치하고, 게임이 등급 분류를 마친 이후에야 예치금이 개발자에게 전달되는 구조다. 이 과정에서 발생하는 수익은 등급 분류 이후에 인식되므로, 제도적 검열을 우회할 수 있는 가능성이 존재한다. Ludex는 이와 함께 자사의 수수료 수익도 예치 상태로 유지하며, 예치금이 일정 수준 이상 쌓일 경우에는 심의 신청을 대행하는 방식으로 인디 개발자를 지원할 수 있다. 다만, 이러한 방식은 법적 리스크가 존재하므로, 전문적인 법률 검토를 거친 뒤 적법성이 확보된 경우에만 진행된다. 만약 합법성이 확보되면, 온라인 신문 및 인디게임 커뮤니티를 통해 본 시스템을 널리 홍보할 계획이다. 구현 측면에서는 기존 스마트 컨트랙트에 소폭 수정만 가하면 되므로 기술적 난이도는 낮은 편이다.
- 프로모션 방안
◇ 온라인 게임잼 개최 - 게임잼은 인디게임 개발자들이 48~72시간 동안 주어진 주제에 따라 짧은 기간 내 게임을 제작하는 행사로, 인디 커뮤니티에서 가장 널리 사용되는 이벤트 방식 중 하나다. Ludex는 UGC(사용자 제작 콘텐츠) 확장성을 주제로 반년에 한 번씩 총 세 차례 게임잼을 개최할 계획이다. 특히 두 번째와 세 번째 게임잼에서는 첫 번째 게임잼에서 제작된 게임을 기반으로 한 파생 게임 부문을 별도로 마련하여 2차 창작 생태계의 활발한 형성을 유도한다. 이와 같은 파생 게임에 대한 출품 조건은 플랫폼의 정식 출시 이후부터 적용될 예정이다.
◇ 플레이엑스포 2026 부스 참여 - 플레이엑스포는 매년 참가 기업 수와 방문객 수가 증가하고 있는 국내 주요 오프라인 게임 전시회다. 특히 2026년 기준으로는 약 11만 5천 명의 관람객과 721개의 게임 관련 기업이 참여하는 등 그 규모가 상당하다. 다른 대형 전시회인 지스타가 대기업 중심인 것과 달리, 플레이엑스포는 인디게임 친화적인 전시회로서 인디게임 전용관 운영과 같은 실질적인 지원을 제공하고 있다. 또한 게임 출품 기업뿐 아니라 게임 관련 기술 및 플랫폼 기업도 부스를 신청할 수 있어, Ludex와 같은 플랫폼 사업자에게도 적합한 전시 기회가 된다. 반면 부산인디커넥트와 같은 일부 전시회는 게임 출품 기업에 한정해 참가 자격을 부여하므로, 이번 기회에 플레이엑스포를 전략적 홍보 채널로 삼는 것이 적절하다. 부스 운영 방안으로는 게임잼 출품작 중 파생 게임이 존재하는 작품들을 직접 체험할 수 있는 플레이존을 제공할 계획이다. 또한 ‘아이디어잼’이라는 참여형 코너를 통해, 방문객이 제시된 주제에 따라 메모지로 게임 아이디어를 적고 이를 보드에 붙이는 방식의 콘텐츠를 마련한다. 나아가 아이디어 간 파생 관계를 구성하여 연결할 수 있게 하고, 심사를 통해 선정된 아이디어의 제안자와 그 파생 아이디어 제공자 모두에게 상품을 수여함으로써 Ludex의 2차 창작 철학을 효과적으로 전달하고자 한다.
◇ Google Display Network(GDN)
- Google Display Network(GDN)는 전 세계 200만 개 이상의 웹사이트, 앱, 유튜브 등 다양한 온라인 채널을 통해 광고를 노출할 수 있는 구글의 디스플레이 광고 플랫폼이다. Ludex는 게임 2차 창작이라는 독창적 시장 포지션을 기반으로, 해당 차별점을 적극적으로 부각하는 방향으로 GDN을 활용할 계획이다. 특히 CPC(클릭당 과금) 방식보다는 브랜드 인지도 제고에 초점을 맞춘 CPM(노출 1,000회당 과금) 방식을 채택하여, 개발자 및 게임 유저 커뮤니티를 중심으로 플랫폼 인식을 확산시키는 것이 핵심 전략이다. 이는 신규 유저 유입보다는 초기 브랜드 포지셔닝과 업계 내 존재감 확보를 우선시하는 마케팅 방향성과도 부합한다. GDN을 통해 주 타겟은 게임 개발자 관련 블로그, 인디게임 커뮤니티, 게임 유저 대상 매체 등을 중심으로 설정할 예정이며, 시각적 임팩트가 큰 배너와 명확한 가치 제안을 통해 Ludex의 브랜드 이미지를 강화하고자 한다.