"1분반-Ludex"의 두 판 사이의 차이
cdc wiki
(새 문서: <div>__TOC__</div> ==프로젝트 개요== === 기술개발 과제 === ''' 국문 : ''' 00000000.. ''' 영문 : ''' 00000000.. ===과제 팀명=== 00000.. ===지도교수=== 000...) |
|||
| 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를 이용하게 함으로써 수익 확대를 노릴 수 있고, 실패한 게임의 경우 개발 중 산출된 리소스의 로열티를 얻을 수 있어 생계 유지에 추가적인 도움을 얻을 수 있다. | ||
===기술개발 일정 및 추진체계=== | ===기술개발 일정 및 추진체계=== | ||
| 61번째 줄: | 156번째 줄: | ||
내용 | 내용 | ||
====구성원 및 추진체계==== | ====구성원 및 추진체계==== | ||
| − | 내용 | + | 구성원 |
| + | ◇ 임진우 | ||
| + | 팀장, 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 이후에는 작업 브랜치를 삭제하고 관련 이슈를 종결한다. | ||
==설계== | ==설계== | ||
===설계사양=== | ===설계사양=== | ||
| − | ==== | + | ====액터 정의==== |
내용 | 내용 | ||
| − | ==== | + | ====기능 요구사항 정의==== |
내용 | 내용 | ||
| − | === | + | ====유스케이스 정의==== |
내용 | 내용 | ||
| − | + | ====UI 구성==== | |
| − | === | + | 내용 |
| + | ====시스템 설계==== | ||
| + | 내용 | ||
| + | ====스마트 컨트랙트 설계==== | ||
| + | 내용 | ||
| + | ====서버 아키텍처==== | ||
내용 | 내용 | ||
| − | + | ====DB 설계==== | |
| − | === | ||
내용 | 내용 | ||
| 82번째 줄: | 220번째 줄: | ||
===완료 작품의 소개=== | ===완료 작품의 소개=== | ||
====프로토타입 사진 혹은 작동 장면==== | ====프로토타입 사진 혹은 작동 장면==== | ||
| − | |||
| − | |||
내용 | 내용 | ||
| 93번째 줄: | 229번째 줄: | ||
===향후계획=== | ===향후계획=== | ||
| − | 내용 | + | *어려웠던 내용들 |
| + | ◇ 스마트 컨트랙트 및 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일 (수) 01:52 판
프로젝트 개요
기술개발 과제
국문 : 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 이후에는 작업 브랜치를 삭제하고 관련 이슈를 종결한다.
설계
설계사양
액터 정의
내용
기능 요구사항 정의
내용
유스케이스 정의
내용
UI 구성
내용
시스템 설계
내용
스마트 컨트랙트 설계
내용
서버 아키텍처
내용
DB 설계
내용
결과 및 평가
완료 작품의 소개
프로토타입 사진 혹은 작동 장면
내용
관련사업비 내역서
내용
완료작품의 평가
내용
향후계획
- 어려웠던 내용들
◇ 스마트 컨트랙트 및 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의 브랜드 이미지를 강화하고자 한다.
