한 게임 회사가 왜 범용 에이전트를 오픈소스로 공개했을까요?

7월 26일, 제8회 TapTap 개발자 살롱(TDW 2026)이 상하이에서 개막했다.올해 행사는 다소 특별한 의미를 지닌다. 10년 전 ChinaJoy에서 심동(心动) CEO이자 TapTap 창립자인 황이멍(黄一孟)은 대중 앞에서 ‘공동 운영하지 않고, 개발자와 수익을 나누지 않겠다’는 상식에 반하는 결정을 발표했다. 오늘로 정확히 10년이 지났다.

매년 황이멍의 강연은 TDW의 하이라이트입니다.올해 행사 전반의 분위기를 주도한 것은 한 가지 통계 자료였다. 2026년 상반기, TapTap에서 새로 출시된 플레이 가능한 게임은 5,002개로, 작년 같은 기간의 530개에 비해 거의 10배에 달했다. 그중 4,000개 이상은 AI를 활용해 제작된 미니 게임이었으며, 상당수는 TapTap 자체의 AI 창작 도구인 ‘TapTap 제조’를 통해 만들어졌다.

작년 TDW에서 황이멍은 TapTap이 “플레이어가 좋은 게임을 발견하도록 돕는 것”에서 “개발자가 좋은 게임을 만들 수 있도록 돕는 것”으로 방향을 전환하겠다고 밝힌 바 있습니다. 현재 AI 덕분에 ‘게임을 만드는 것’이 확실히 쉬워졌고, 창작 진입 장벽이 대폭 낮아지면서 수많은 개발자가 몰려들었으며, 이 과정에서 눈에 띄는 작품들도 많이 등장하고 있습니다.

공급 측에서 폭발적인 성장이 일어나고 있는 반면, 현재 또 다른 현실은 플레이어의 관심이 여전히 한정적이라는 점이다. 좋은 게임을 접할 기회가 늘어날수록 놀라움을 느끼기 점점 더 어려워지고 있다. 황이멍은 이 문제를 회피하지 않았다. 그의 말에 따르면, 신작 게임이 10배나 쏟아져 들어오면서 각 게임에 할당되는 노출도가 크게 희석되었고, 플레이어가 접하게 되는 게임의 “품질이 떨어지고 만족스럽지 않을” 수 있다고 한다.

하지만 제작 측면에서는 AI 도구가 창작의 평등을 실현하기까지 갈 길이 아직 멀다. 황이멍은 좋은 게임이 여전히 부족하며, 바로 그 부족함 때문에 진입 장벽을 낮추고 참여 인원을 늘려 더 많은 개발자가 시도하고, 실력을 키우며, 반복적으로 개선할 기회를 가져야 한다고 판단한다.AI는 여전히 빠르게 발전하고 있으며, 도구는 더욱 편리해질 것이므로, 그제야 비로소 더 많은 진정한 명작들이 빛을 볼 기회를 얻을 수 있을 것이다.

기술은 창작의 평등화를 가능하게 하지만, 공급과 수요 사이의 긴장 관계는 플랫폼이 반드시 해결해야 할 과제입니다. 창작의 진입 장벽을 어떻게 더 낮출 수 있을까요? 좋은 게임은 어떻게 발견될 수 있을까요? 올해 황이멍의 강연은 기본적으로 이 두 가지 문제를 중심으로 전개되었습니다.

01

TapTap의 탄생: ‘전면 개입’에서 ‘손 떼기’로

이번 공급 급증의 가장 큰 원동력은 바로 ‘TapTap’이었다. 1월 30일 이 제품이 출시된 당일 밤 바로 한정 테스트를 시작했으며, 그 후 몇 달에 걸쳐 점차 참가 인원을 확대해 나갔다.

이 기술이 처음 공개되었을 때 업계에 상당한 파장을 일으켰으며, 많은 사람들이 AI를 이용해 게임을 만드는 것이 이토록 쉽고 매끄러울 수 있다는 사실을 처음으로 깨달았습니다. 한 개발자는 황이멍에게 첫날 밤새도록 이 기술을 사용했다고 말했습니다.

반년이 지난 지금, 그 성과는 상당히 인상적이다. TapTap을 통해 제작된 게임은 5,000개에 육박하며, 누적 플레이어 수는 1,000만 명을 넘어섰고, 일일 평균 플레이어 수는 16만 명 이상, 크리에이터 수는 3,000여 명에 달한다.

출시된 작품 중에서도 주목할 만한 사례가 적지 않습니다. 『점프할수록 부자가 된다』는 한 창작자 챌린지 대회에서 탄생한 작품으로, 매출과 1인당 이용 시간이 모두 높은 수준을 기록하고 있으며, 현재까지도 성장세를 이어가고 있습니다. 『운명의 여정』, 『알바하며 수련하기』와 같이 수천 번의 대화를 거쳐 다듬어진 작품들은 완성도가 이미 상당히 높습니다.

구체적인 제품 외에도 더 중요한 것은 개발자의 성장 과정입니다. 단순하고 서툰 첫 시도에서 시작해, 수십 번, 수백 번, 심지어 수천 번의 대화를 거치며 두 번째, 세 번째 작품을 만들어 가면서 점점 더 숙련되어 가는 과정입니다.

하지만 무대 위에서 황이멍은 성과에만 머물지 않았다. 그의 성찰은, 지난 반년 동안 TapTap의 성장 속도가 충분히 빠르지 않았고, 사용자 규모도 충분히 확대되지 않았다는 것이었다. 그 원인은 제품 자체에 있는 것이 아니라, 연초에 설정된 비즈니스 모델에 있었다.

부담은 우선 비용 측면에서 나타납니다. 연초의 구상은 다음과 같았습니다. 제품은 창작자에게 완전히 무료로 제공하고, 토큰 비용은 플랫폼이 부담하며, 우수한 게임이 출시되어 성장과 수익을 창출하면 이를 다시 창작 비용에 재투자하여 선순환 구조를 형성하는 것이었습니다.

그러나 반년 동안 운영해 본 결과, 이 모델에는 몇 가지 한계가 드러났다. 3,000여 명의 크리에이터가 발생하는 토큰 비용을 전액 플랫폼이 부담해야 하는데, 매월 수천만 규모에 달할 수 있다. 한편, 아직 성장 단계에 있는 이 게임들이 그에 상응하는 수익을 창출하고, 그중 일부가 플랫폼으로 재유입되도록 하는 것은 너무나 어려운 일이다.

포인트 배분 역시 난제다. 누가 더 많이 받아야 하고 누가 적게 받아야 할지는 전적으로 플랫폼이 판단해야 하므로 부담이 크다. 황이멍은 스스로 이렇게 결론지었다. “이 모든 꼬인 문제들은 사실 포인트 정책과 관련이 있다.”

더 깊은 부담은 TapTap의 초기 포지셔닝에 기인한다. 연초에 이 플랫폼은 모든 것을 아우르는 ‘스마트 에이전트’로 설정되었다. 어떤 모델이 이미지 생성에 가장 뛰어난지, 어떤 모델이 동영상 생성에 가장 뛰어난지 등 본래 시장의 검증을 거쳐야 할 문제들을 모두 플랫폼이 직접 답해 주기로 한 것이다. 모델의 성능이 매달 진화하는 현재 상황에서, 이는 분명히 충분히 유연하고 민첩하지 못한 접근 방식이다.

조정 역시 이 두 가지 측면을 중심으로 이루어졌다. 먼저 비용 측면이다. 포인트 증정 제도는 유지되지만, 그 성격은 ‘추가적인 인센티브’로 재정의되었으며, 동시에 구매 제한을 해제해 개발자가 투자 규모와 제작 방식을 스스로 결정할 수 있도록 했다. 황이멍은 “우리는 포인트를 판매하려는 것도, 포인트를 통해 수익을 창출하려는 것도 아니다”라고 특별히 강조했으며, 심지어 개발자들에게 인터넷 전반의 가격을 비교해 볼 것을 권장하기도 했다.

다음은 ‘완전 자율’ 부분입니다. 컴퓨팅 성능과 도구 활용 능력이 더 이상 클라우드에만 국한되지 않으며, 개발자는 로컬에 원하는 에이전트를 설치하고 원하는 모델을 연동하여, MCP를 통해 TapTap이 제공하는 기능을 활용해 게임을 제작할 수 있습니다. 모델 선택에 있어서도 플랫폼이 더 이상 개발자를 대신해 결정하지 않습니다.

또한 TapTap 개발의 기반이 되는 자체 개발 AI Native 엔진에 대한 연구 개발은 지속적으로 진행될 예정이며, 더욱 개방될 것입니다. 더 이상 출시 플랫폼에 제한을 두지 않고, 개발된 게임은 Steam에 출시할 수 있게 되며, 향후 완전한 오픈소스로 전환될 예정입니다.

황이멍의 말을 빌리자면, “개발자들이 이 서비스를 사용하는 이유는 여기에 무료 토큰이 있어서도, 이 서비스를 통해서만 TapTap에 게임을 출시할 수 있어서도 아니어야 한다.” 이후 TapTap이 확보할 수 있는 경쟁력은 오직 다른 제품과 비교했을 때의 진정한 제품적 우위에서 비롯될 수밖에 없다.

02

배포 재구성: 훌륭한 게임이 저절로 탄생하도록 하기

TapTap이 단행한 조정은 주로 공급 측면을 겨냥한 것이다. 그러나 공급이 급증한 이후, 유통 측면에서도 적지 않은 어려움에 직면하게 되었다.

‘편집자 추천’은 줄곧 TapTap의 가장 큰 특징 중 하나였지만, 과거의 배포 논리는 지금 보면 다소 사치스러운 전제에 기반을 두고 있었습니다. 바로 게임 수가 한정되어 있어 편집자가 모든 게임을 일일이 살펴볼 수 있었고, 출시되는 모든 신작 게임이 최소한의 노출을 보장받을 수 있었다는 점입니다.

하지만 반년 동안 5,000여 종의 게임이 출시되면서 상황이 달라졌습니다. 추천 방식도 이에 맞춰 조정해야 했고, TapTap은 편집부 추천을 그대로 유지하되, 그 방향을 ‘모두 보기’에서 ‘추천할 만한 게임 선별’로 전환했습니다.

황이멍은 편집자가 모든 게임을 다 살펴보는 것이 더 이상 불가능하며, 필연적으로 일부 작품을 놓치게 될 것이라고 인정했다. 따라서 편집자의 추천은 선정된 게임에 추가적인 가산점이 되며, 상대적으로 마니아가 선호하는 작품이면서도 독창적인 취향을 지녔고 업계 차원에서 장려할 가치가 있는 작품들을 중점적으로 지원한다.

게임 수가 급증함에 따라 최소 노출 보장 제도도 도전에 직면하고 있다. 과거에는 모든 게임이 비교적 안정적인 최소 노출을 보장받았지만, 현재 신작 게임의 수가 이 정도 규모에 이르렀기 때문에 품질이 낮은 작품에 계속해서 최소 노출을 보장하는 것은 “사용자에게도 해가 된다”.

황이멍은 앞으로 게임 개발사와 브랜드의 중요성이 더욱 커질 것이라고 전망했다. 브랜드 인지도가 쌓이지 않은 상태에서 처음부터 시작하는 신작 게임의 경우, 성장 속도가 다소 더뎌질 수 있다.

그렇다면, 게임을 플레이어에게 알리는 역할은 누가 맡게 될까요?

먼저 추천 메커니즘입니다. 오해를 불러일으키기 쉬운 ‘알고리즘’이라는 표현보다는, 황이멍은 이를 ‘사용자 행동 기반 추천’이라고 부르는 것을 더 선호합니다.추천은 여전히 시스템이 수행합니다. 플레이어가 게임을 즐긴 후 호평을 남길지, 게임에 ‘좋아요’를 누를지, 지속적으로 시간을 투자할지, 개발자에게 건설적인 피드백을 줄 의향이 있는지 등—플레이어 스스로 설명할 수 있는 이러한 행동들이 한 게임이 추천할 만한 가치가 있는지 판단하는 근거가 됩니다. 동시에, 우수한 게임은 여전히 편집자의 추천을 받을 수 있습니다.

또 다른 새로운 메커니즘은 제작사 측에 적용되는 것으로, 바로 ‘제작사 신용 등급’입니다. 이 시스템은 7월 16일에 출시되어 TDW 당일까지 정확히 10일이 지났습니다.현장에서 발표된 바에 따르면, 플랫폼에는 현재 13,571개의 활성 제작사가 있으며, 각 제작사마다 신용 등급이 부여된다. 브랜드 가치를 소중히 여기고 장기적으로 양질의 콘텐츠를 생산하는 제작사는 향후 신작에 대해 더 높은 노출 가중치를 얻을 수 있다.

이 기능이 출시된 지 불과 10일 만에 변화가 나타나기 시작했다. 일부 업체들은 자발적으로 보조 계정을 통합하기 시작했으며, 여러 계정에 흩어져 있던 게임들을 주 계정으로 통합하고 있다.

황이멍은 다음과 같은 비유를 들었다. 마치 쇼핑을 할 때, 소비자는 브랜드가 있고 브랜드를 소중히 여기는 제조사의 제품을 구매하기를 원할 뿐, 브랜드가 없고 언제든 외관을 바꿔 다시 시작할 수 있는 ‘백라벨’ 제품은 원하지 않는다는 것이다. 후자의 경우 대개 모든 단계에서 한계를 시험하곤 한다.

이러한 배포 측면의 조정 사항들을 종합해 보면, 플랫폼은 사실상 한 걸음 물러선 셈입니다. 즉, 선별 과정을 플레이어의 몫으로 넘기고, 신뢰는 개발사의 브랜드에 맡긴 것입니다.

03

Cindy: 게임 회사들은 왜 범용 에이전트를 개발할까요?

연설의 대미를 장식한 것은 ‘Cindy’라는 이름의 범용 AI 에이전트 제품이었다.

Cindy는 오픈소스이며 설치 즉시 사용할 수 있는 AI 에이전트 클라이언트입니다. 로컬 컴퓨터에 설치하면 다양한 모델을 원스톱으로 활용할 수 있으며, 언어뿐만 아니라 이미지, 동영상, 오디오, 나아가 향후 3D 자산까지 지원합니다. 또한 TapTap 제조 기능이 네이티브 플러그인 형태로 내장되어 있습니다.

황이멍은 이를 다음과 같이 정의했다. “순수한 프로그래밍 도구보다 다루기 쉬우면서도, 시중에 나와 있는 다른 업무용 도구들보다 더 강력하다.”

한 게임 회사가 왜 “무엇이든 할 수 있는” 범용 에이전트를 만들게 되었을까? 그 해답은 신디의 탄생에서 찾아야 한다.

이 도구는 처음부터 외부 사용자를 위해 개발된 것이 아니라, 심동 내부에서 사용하던 도구였습니다.

처음에 가졌던 동기는 매우 소박했습니다. 모든 직원이 컴퓨터를 켜면 AI 클라이언트가 나타나, 복잡하고 비효율적인 업무는 AI에 맡기고 사람은 진정으로 가치 있는 의사결정만 하도록 하는 것이었습니다.

게다가 또 다른, 더 깊은 동기가 있다.AI의 도움으로 개인의 효율은 10배 이상 향상될 수 있지만, 팀 차원으로 돌아오면 효율이 그에 상응하게 증가하지는 않습니다. 황이멍은 문제의 원인이 협업 방식에 있다고 지적합니다. 즉, 업무 흐름이 여전히 직종 간의 릴레이 방식으로 진행된다면, 기획자가 프로그래머에게, 프로그래머가 아트팀에게, QA가 테스트를 마치고 결과를 돌려준 뒤 다시 프로그래머가 수정할 때까지 기다리는 식으로, 모든 시간이 대기 시간으로 소모된다는 것입니다.

Cindy는 ‘심동’ 내부에서 아트 작업을 담당하며, 먼저 콘셉트 아트를 그린 뒤 프로그래머에게 넘겨 구현하게 할 필요 없이, 도구 내에서 직접 시각적 효과를 반복적으로 수정하고 PR을 통해 코드 저장소에 제출합니다. 황이멍은 자신을 제품 매니저이자 요구사항 제안자로 정의하며, 코드를 통해 결과를 확인합니다. 프로그래머 동료들은 성능 검토를 담당합니다……

모든 단계가 동시에 진행되며, 누구도 다른 사람을 기다릴 필요가 없습니다. 코드는 각 프로젝트의 동료들이 함께 기여하며, 심지어 인사팀 직원들까지 코드를 커밋하고 있습니다.

황이멍은 “지난 두 달 반 동안 나는 그 일에 완전히 몰두해 왔다. 창업한 지 수년 동안, 이 기간만큼 긍정적인 피드백을 가장 강하게 느낀 적은 없었던 것 같다”고 말했다.

내부 도구가 완성되었는데, 왜 외부에 오픈소스로 공개해야 할까? 황이멍의 판단은 이렇다. 소프트웨어 업계는 이미 대대적인 변화를 겪었으나, 많은 사람들이 아직 그 사실을 깨닫지 못하고 있을 뿐이다. 미래에는 “누구나 자신만의 소프트웨어를 만들 기회가 있을 것”이며, 진입 장벽은 상상할 수 없을 정도로 낮아질 것이다.

신디 자신이 그 증거다. 그의 말에 따르면, 이 프로젝트는 “3주 전만 해도 회사에서 프로젝트 승인조차 받지 못했고, 예산도 전혀 없었다”고 한다. 게임을 만드는 데는 돈이 전혀 들지 않는 것에 비해, “Coding Plan을 몇 개 구입하는 것만으로 이 일이 성사되었다”고 한다.

이는 엔진을 오픈소스로 공개하고 플랫폼에 강제 연동을 하지 않는 것과 같은 논리입니다. 도구의 복제 비용이 0에 가까워지면, 비공개로 유지한다고 해서 아무것도 보호할 수 없으므로, 차라리 공개하여 생태계를 구축하는 편이 낫습니다.

04

개방성이 높을수록 경쟁 우위는 더욱 공고해진다

10년 전 ChinaJoy에서 황이멍은 TapTap이 공동 운영을 하지 않고 개발자와 수익을 나누지 않겠다고 발표했습니다. 유통 채널에서 일반적으로 50대 50으로 수익을 나누던 시절, 이 결정은 많은 사람들에게 이해하기 어려운 것이었습니다.10년 후의 이번 연설에서 그는 TapTap의 제작 방식을 일방적인 통솔에서 자율적인 운영으로 전환하고, 엔진을 오픈소스로 공개했으며, 갓 출시된 Cindy까지 통째로 공개해 버렸다…… 겉보기에는 이 또한 꽤 ‘상식에 반하는’ 결정으로 보인다.

하지만 종합해 보면, 두 번의 결정 모두 같은 대상에 베팅한 것이다. 10년 전에는 수익을 나누지 않음으로써 신뢰를 쌓았고, 오늘날에는 도구, 모델, 컴퓨팅 파워를 하나씩 넘겨주며, 콘텐츠 배포가 이용자의 행동과 업체의 신용에 따라 이루어지도록 하고, 플랫폼은 규칙을 설계하는 역할로 물러남으로써, 결국 얻은 것은 여전히 신뢰이다.

현장에서 누군가 황이멍에게 “앞으로 10년 동안 TapTap이 가장 희생하고 싶지 않은 것은 무엇인가요?”라고 물었다. 그의 대답은 브랜드였다. “전통적인 채널의 트래픽은 하드웨어나 다른 강력한 진입 경로에서 비롯될 수 있습니다. 하지만 TapTap의 모든 트래픽은 단 한 가지, 바로 플레이어들이 TapTap 브랜드에 대해 가지고 있는 인식과 신뢰에서 비롯됩니다.”

AI 덕분에 누구나 겉보기에는 괜찮은 게임을 만들 수 있게 되었지만, 공정하고 공평한 추천, 조작되지 않은 평점, 모든 설치 파일이 공식 버전이라는 약속들은 오히려 가장 귀한 것이 되어버렸다. 도구의 진입 장벽이 거의 제로에 가까운 이 시대에, 신뢰야말로 유일하게 복제할 수 없는 자산이다.

상점, 커뮤니티, 개발자 서비스부터 창작 도구와 범용 에이전트에 이르기까지, TapTap이 할 수 있는 일은 점점 더 많아지고 있다. 하지만 황이멍의 말에 따르면, 그 본질은 지난 10년 동안 변하지 않았다. TapTap은 개발자를 돕고, 게임이 플레이어를 찾을 수 있도록 지원하는 게임 플랫폼이다. 그 외의 모든 것은 보조적인 역할일 뿐이며, 개발자가 창작 자체에 집중할 수 있도록 하기 위한 것이다.