웹게임 포털 출시 가이드: Poki와 CrazyGames

2026-09-28

웹게임을 만들어 놓고 어디에 낼지 고민하는 개발자라면 Poki와 CrazyGames를 가장 먼저 떠올리게 됩니다. 둘 다 HTML5 게임을 받아 자체 트래픽으로 노출시켜 주는 포털이지만, 제출 절차부터 수익 구조까지 세부 방식은 꽤 다릅니다. 이 글은 두 플랫폼의 공식 문서를 기준으로 제출 절차, 기술 요건, SDK 연동, 수익 배분과 독점 조건을 정리합니다. 정확한 수치가 공개되지 않은 항목은 그렇게 밝혀 두었습니다. itch.io처럼 자유도 높은 플랫폼에 먼저 게임을 올려보고 싶다면 itch.io 페이지 꾸미기도 참고하세요.

제출 절차

Poki는 "Poki for Developers"라는 제출 폼으로 게임을 신청받고, 이후 Poki 팀이 직접 UX와 코어 루프를 검토하는 큐레이션 방식을 씁니다. 자동 승인이 아니라 사람이 플레이해 보고 판단하는 구조라, 튜토리얼 없이도 5초 안에 뭘 해야 하는지 보이는 게임일수록 통과가 쉽습니다.

CrazyGames는 개발자 포털에 빌드와 SDK, 메타데이터(설명, 썸네일, 조작법)를 함께 제출합니다. 공식 개발자 약관은 최초 공개 단계를 "Basic Launch"라고 부르는데, 이는 계약서 원문 기준으로 "게임의 사용자 지표를 테스트하기 위한 초기 제한 공개"로 정의되어 있고, 이후 CrazyGames가 편집·품질·성과 기준으로 판단해 "Full Launch"로 전환하거나 포털에서 내리는 구조입니다. Basic Launch가 정확히 며칠, 몇 회 플레이를 기준으로 끝나는지는 이번 확인 과정에서 공식 문서로 명확히 대조하지 못했으므로, 제출 화면에 표시되는 안내를 직접 확인하는 편이 정확합니다.

기술 요건

CrazyGames는 초기 다운로드 용량을 측정하는 기준도 문서에 구체적으로 밝혀 두었습니다. 로딩 시작부터 첫 게임플레이 시작 이벤트가 발생하는 시점까지를 초기 다운로드로 보고, 외부 호스팅 리소스를 쓰는 경우 QA팀이 게임플레이 도달까지 20초 이내인지를 별도로 평가합니다. Poki는 요건 문서에서 정확한 용량 숫자 대신 유니티 게임은 별도 최적화 가이드를 따르라고 안내하는 정도로만 그칩니다. 두 플랫폼 모두 시크릿 모드에서 localStorage가 제한될 수 있으므로 저장 로직을 try/catch로 감싸는 것이 안전합니다.

SDK 연동과 광고 호출

Poki SDK는 광고를 직접 스케줄링하지 않습니다. 대신 게임이 commercialBreak()와 rewardedBreak()를 자연스러운 끊김 지점(레벨 사이, 재시작 등)에서 호출하면, 실제로 광고를 보여줄지 언제 보여줄지는 Poki 시스템이 결정합니다. 공식 문서는 "내부적으로 광고 타이머를 직접 구현하지 말고 Poki의 빈도 조절에 맡기라"고 명시합니다. gameplayStart()/gameplayStop() 이벤트를 정확히 호출하는 것도 심사 통과의 전제 조건입니다.

CrazyGames는 window.CrazyGames.SDK.ad.requestAd("midgame", callbacks)와 requestAd("rewarded", callbacks) 두 종류를 제공하며, 유니티에서는 CrazySDK.Ad.RequestAd(CrazyAdType.Midgame, ...) 형태로 동일하게 씁니다. 미드게임 광고를 짧은 간격으로 반복 호출하지 못하게 SDK가 자체적으로 빈도를 제한한다고 알려져 있지만, 정확한 간격 수치는 이번 조사에서 공식 SDK 문서 원문으로 재확인하지 못했으므로 단정하지 않습니다.

외부 링크와 자체 광고 금지

두 플랫폼 모두 "자사 광고 시스템 외 다른 광고 네트워크 삽입"을 금지합니다. Poki는 외부 리소스 문서에서 승인된 도메인이 아니면 외부 요청 자체를 차단한다고 밝히고, 디스코드 같은 외부 링크도 SDK 이벤트를 통해서만 열도록 요구합니다. CrazyGames는 게임플레이 요건에서 크로스 프로모션을 원칙적으로 금지하되, 메인 CTA가 아닌 커뮤니티 링크나 데스크톱 한정 스토어 링크는 예외로 허용합니다.

수익 배분 구조

정확한 퍼센트를 찾는 개발자에게는 아쉬운 답이지만, 두 회사 모두 고정된 배분율을 공개 문서에 못 박아 두지 않습니다. Poki는 공식 문서에서 Poki의 프로모션·추천·마케팅을 통해 유입된 플레이어에 대해서는 수익을 나누고, 검색·북마크·SNS 등 개발자 자체 채널로 유입된 플레이어는 개발자가 전부 가져간다는 구조를 밝히면서도, 문서 자체가 "5년 계약 기간, 수익 배분율, 투자 규모는 모두 예시이며 실제 조건은 게임별 계약서에 따로 정해진다"고 명시합니다. 즉 유입 경로별로 나눈다는 구조는 확인되지만, 정확한 배분 비율을 "몇 대 몇"으로 단정할 수는 없습니다.

CrazyGames도 마찬가지입니다. 공식 FAQ는 "수익은 게임 성과에 따라 다르며 플레이어 참여도, 리텐션, 인기도, 광고주 수요가 핵심 요인"이라고만 답합니다. 개발자 약관 원문(Article V)도 퍼센트 배분 방식이 아니라, 트래픽과 광고 성과라는 객관적 기준에 따라 매달 보상 금액을 산정하는 구조로 적혀 있습니다. 인터넷에 떠도는 "광고 60/40, 인앱결제 70/30" 같은 숫자는 공식 계약서 어디에도 없으므로 그대로 믿지 않는 것이 안전합니다.

독점 조건

Poki는 웹 독점을 선호하는 플랫폼입니다. 기본 계약은 5년 동안 오픈 웹에서 Poki 단독 게시를 조건으로 하되, Steam이나 모바일 앱스토어, 콘솔은 이 독점 범위에서 제외됩니다. 비독점을 원하면 수익 배분 대신 일회성 라이선스 비용을 받는 방식도 선택할 수 있습니다.

CrazyGames는 기본적으로 비독점입니다. 같은 게임을 Steam, 구글 플레이, 앱스토어, 심지어 Poki에도 동시에 올릴 수 있고 CrazyGames 수익 배분에 영향이 없다고 FAQ에 명시되어 있습니다. 다만 "브라우저 게임 사이트에 한해 Full Launch 이후 2개월간 독점"을 선택하면 계약서 5.5조에 따라 보상이 50% 인상됩니다. 이때의 독점은 어디까지나 다른 브라우저 게임 포털을 의미하며, Steam이나 앱스토어는 이 조건에서도 제외된다고 계약서가 별도로 명시합니다.

엔진별 주의점

Unity WebGL은 Brotli 압축을 켜는 것만으로 용량이 크게 줄어드는 경우가 많습니다. 빌드 설정에서 Code Optimization을 "Faster (smaller) builds"나 "Disk Size with LTO"로 바꾸고, 텍스처는 Crunch Compression을 적용하면 추가로 줄일 수 있습니다. 자세한 옵션은 Unity 공식 매뉴얼에 정리되어 있습니다.

갓엔진(Godot)은 HTML5 익스포트가 WebAssembly와 WebGL 2.0을 지원하는 브라우저를 전제로 합니다. Poki는 Godot 3.4 이상을 지원하는 전용 SDK 플러그인을 공식으로 제공하므로 PokiSDK 싱글톤을 오토로드에 추가하는 방식으로 붙일 수 있습니다. 멀티스레드 익스포트가 SharedArrayBuffer 관련 브라우저 헤더 요구사항 때문에 웹 퍼블리셔 환경과 호환성 문제를 일으킬 수 있다는 이야기가 개발자 커뮤니티에서 종종 나오지만, 이 부분을 뒷받침하는 공식 문서를 이번 조사에서 직접 확인하지는 못했습니다. 웹 배포가 목적이라면 싱글스레드 익스포트부터 시도해 보는 편이 무난합니다.

정리

결론부터 말하면, 두 플랫폼 모두 정확한 수치(용량 상한, 배분율, 심사 기간)를 공개 문서에 명시하지 않는 부분이 많습니다. 대신 공통으로 확인되는 원칙은 뚜렷합니다. 자사 SDK를 통한 광고만 허용하고, 외부 광고 네트워크나 무단 크로스 프로모션은 금지하며, 정확한 조건은 결국 게임별 계약서로 확정된다는 것입니다. 제출 전에는 각 플랫폼의 최신 문서와 제출 화면 안내를 다시 한번 확인하는 것이 가장 정확합니다.