빌린 엔진의 청구서

유니티가 2023년에 런타임 요금제를 발표했을 때, 나는 그게 단순한 가격 인상 소식이라고 생각했다. 설치 한 번당 돈을 받겠다는 발상. 개발자들이 들고일어났고 회사는 며칠 만에 후퇴했다. CEO가 바뀌었고 정책은 폐기됐다. 사건은 닫힌 것처럼 보였다.

그런데 그 소동이 드러낸 건 가격이 아니었다. 구조였다. 엔진이 내 게임의 출고가 아니라 내 게임의 운명에 과금하겠다고 선언한 순간, 도구와 사용자의 관계가 무엇이었는지가 들통났다. 엔진은 망치가 아니었다. 엔진은 내 작업장의 지주(地主)였다.

도구값과 임대료는 다른 청구서다

전통적으로 게임 엔진은 도구를 팔았다. 라이선스를 사면 그걸로 만든 게임은 내 것이었다. 언리얼의 로열티 모델조차 명료했다. 일정 매출을 넘으면 5퍼센트. 성공한 만큼 떼주되, 룰이 게임 출시 전에 고정돼 있었다. 나는 내가 무엇을 양보하는지 알고 시작했다.

구독과 런타임 과금은 그 계약의 시제(時制)를 바꾼다. 도구값은 만들기 전에 치르는 비용이다. 임대료는 만든 다음에, 그것도 잘 만들었을수록 더 많이 흘러나가는 비용이다. 설치당 과금이라는 발상이 그토록 공포스러웠던 건 금액이 커서가 아니다. 내 게임이 흥할수록 내가 통제할 수 없는 청구서가 자라기 때문이다. 성공이 곧 부채가 되는 설계. 인디 개발자에게 이건 단순한 비용 문제가 아니라, 자기 성공의 지분을 미리, 그리고 영구히 떼어주는 거래다.

비평가로서 나는 게임 안의 경제를 자주 들여다본다. 잘 만든 게임은 플레이어에게 위험과 보상의 관계를 정직하게 보여준다. 너가 이만큼 걸면 이만큼 돌려준다. 런타임 과금 모델은 정반대다. 개발자가 무엇을 거는지는 명확한데, 무엇을 잃을지는 출시 후에야 드러난다. 도박장에서 칩을 사는데 환전 비율을 게임이 끝난 뒤에 알려주는 격이다.

인디는 왜 그 칼자루를 쥐여주나

그럼 안 쓰면 되지 않나. 이 반론은 정당하고, 절반만 맞다.

고드와 같은 오픈소스 엔진이 있다. MIT 라이선스, 로열티 제로, 런타임 과금 제로. 유니티 사태 직후 고드 후원이 급증한 건 우연이 아니다. 기술적으로 인디는 이미 탈출구를 쥐고 있다. 2D 게임이라면 고드는 충분히 성숙했고, 어떤 면에선 더 가볍고 빠르다.

문제는 엔진이 코드를 돌리는 프로그램이 아니라는 데 있다. 엔진은 생태계다. 튜토리얼, 에셋 스토어, 채용 시장에서 통하는 경력, 외주를 줄 때 말이 통하는 표준. 부산의 작은 팀이 유니티를 못 버리는 건 런타임 요금이 무서워서가 아니라, 유니티를 아는 동료를 구하기 쉽고 유니티로 짠 포트폴리오가 다음 일을 물어다 주기 때문이다. 종속은 기술이 아니라 인적 자본과 경로 의존성으로 잠근다. 엔진사는 이 점을 안다. 그래서 임대료를 매길 수 있다.

여기서 진짜 설계의 교활함이 보인다. 엔진사는 개발자를 도구로 묶지 않는다. 개발자가 쌓아온 시간으로 묶는다. 내가 5년간 익힌 워크플로, 내 손에 붙은 단축키, 내 회사 위키에 적힌 노하우. 이걸 버리는 비용이 곧 전환 비용이고, 그 전환 비용의 크기가 곧 엔진사가 받아낼 수 있는 임대료의 상한이다.

마찰을 어디에 둘 것인가

나는 늘 재미가 마찰에서 나온다고 쓴다. 좋은 게임은 플레이어에게 의도된 거부를 들이민다. 다크 소울이 친절하지 않아서 그 승리가 값진 것처럼. 도구도 마찬가지다. 너무 매끄러운 도구는 너를 그 매끄러움에 길들인다.

엔진 종속의 본질은 마찰의 위치 문제다. 만들 때의 마찰을 없애주는 대가로, 떠날 때의 마찰을 키운다. 입구는 매끄럽고 출구는 끈적하다. 이 비대칭이 임대 모델의 엔진이다. 그러니 인디가 고민할 것은 어떤 엔진이 더 편한가가 아니라, 어디에 마찰을 둘 것인가다. 지금 조금 불편한 오픈소스를 택해 떠날 자유를 사둘 것인가, 지금 편한 상용 엔진을 택하고 내 성공의 지분을 담보로 잡힐 것인가.

부산 인디 씬에 이건 추상적인 얘기가 아니다. 여기 팀들은 대개 작다. 두세 명, 많아야 대여섯 명. 한 명이 떠나면 워크플로 전체가 흔들리는 규모다. 그런 팀일수록 전환 비용의 충격이 크고, 그래서 임대 모델에 더 깊이 묶인다. 대형 스튜디오는 자체 엔진을 짤 여력이라도 있다. 작은 팀에겐 그 선택지가 없다.

내 제안은 단순하다. 첫 프로젝트부터 출구를 설계 변수로 넣어라. 코어 로직을 엔진에 의존하지 않는 순수 코드로 분리하고, 에셋 파이프라인을 표준 포맷으로 유지하고, 적어도 다음 프로젝트 한 편은 오픈소스 엔진으로 짜보라. 이건 이상주의가 아니라 협상력이다. 떠날 수 있는 자만이 머무는 값을 깎을 수 있다. 게임을 잘 만드는 일과, 잘 만든 게임의 몫을 지키는 일은 다른 기술이다. 부산의 작은 팀이 다음 십 년을 버티려면, 두 번째 기술을 첫 프로젝트부터 연습해야 한다.