Soup Raiders 엔진 전환, AI 시대에도 손수 만든 기술은 남는다

커스텀 엔진은 줄었지만 사라지지 않았다

Elias Farhan의 Soup Raiders native port 글은 한 가지 숫자로 시작한다. VGInsights에 따르면 2024년 Steam 출시 게임 중 custom engine 사용 비중은 약 13%로, 2012년 71%에서 크게 줄었다. 그러나 같은 보고서 기준으로 custom engine 게임은 2024년 판매량의 43%를 차지했다. 대부분 AAA 게임의 영향이 크겠지만, 직접 엔진을 만드는 선택이 완전히 비경제적인 것은 아니라는 뜻이다.

글은 custom engine을 Unity나 Unreal 위에 도구를 조금 얹는 것이 아니라, SDL3, SFML, Assimp, DirectX, OpenGL 같은 라이브러리를 조합해 게임 루프, 입력, 렌더링, 자산 로딩, 플랫폼 대응을 직접 책임지는 구조로 정의한다. Soup Raiders의 native port 목표도 Unity나 Unreal과 경쟁하는 범용 엔진이 아니라, 이 게임에 맞춘 엔진이다.

이 이야기는 AI 뉴스처럼 보이지 않을 수 있다. 그러나 소프트웨어 개발에서 AI가 boilerplate와 반복 구현을 줄이는 지금, 커스텀 기술의 경제학은 다시 바뀐다. AI가 없앤 것은 개발자 중산층이 아니라 피드백 한계다, LLM 코딩은 10배가 아니라 2배에 가깝다, Ante, 단일 바이너리 코딩 에이전트가 겨냥한 틈는 모두 같은 질문을 다른 각도에서 본다. 무엇을 직접 만들 것인가.

만들지 말라는 조언은 여전히 맞다

게임 개발 입문자에게 make a game, not an engine이라는 조언은 여전히 유효하다. 글도 이를 부정하지 않는다. Unity와 Unreal, Godot은 범용 기능, 에디터, 콘솔 대응, 자산 파이프라인, 커뮤니티를 제공한다. 작은 팀이 이를 모두 이기려는 것은 비현실적이다. Tyler Glaiel의 조언처럼 특정 use case에서 더 나은 것을 만들 수는 있지만, 범용 엔진을 이길 수는 없다.

그런데 특정 use case가 있으면 이야기가 달라진다. Farhan은 교육, 성능 이해, 기술 독립, 법적 독립, 특수 렌더링, 모딩, niche platform을 이유로 든다. 예를 들어 cascaded shadow map을 직접 구현해 본 사람은 Unity 설정에서 비용과 품질을 더 잘 판단한다. 오브젝트가 서로 가리지 않는 게임에서는 occlusion culling이 비용만 만들 수 있다는 것도 직접 안다.

기술 독립성은 계약과도 연결된다

글은 Unity runtime fee 논란, license revocation 사례, RenderWare의 쇠퇴, Our Machinery 사건을 언급하며 엔진 의존이 기술뿐 아니라 법적 의존이라고 말한다. Unity는 이후 runtime fee를 취소했지만, 논란 자체는 개발자 기억에 남았다. Godot은 MIT 라이선스라는 장점이 있고, Unreal은 라이선스 옵션과 소스 접근을 제공하지만 완전한 소유는 아니다.

이 관점은 게임 밖에도 적용된다. SaaS, AI 에이전트, 데이터 파이프라인도 플랫폼 위에 지어진다. 클라우드, 모델 API, 벡터 DB, CI, 앱스토어 정책이 바뀌면 제품이 흔들린다. Nine PBS 소송, AI 시대 데이터 보관권의 경고가 데이터 보관 계약을 다뤘듯, 엔진 선택도 장기 자산 통제 문제다.

외부 자료로는 VGInsights The Big Game Engines Report of 2025, SDL3 문서, Noel Berry의 engine 없이 게임 만들기 글, Handmade Network manifesto가 같은 논의를 넓혀준다.

AI는 커스텀 기술의 비용을 낮추지만 책임은 못 없앤다

글의 마지막에는 LLM이 덜 중요한 generic feature를 도와줄 수 있으니 지금이 자기 엔진을 쓰기 좋은 때라는 Sebastian Aaltonen의 인용이 나온다. 이 주장은 설득력이 있다. 입력 처리, 자산 변환, 빌드 스크립트, 에디터 UI 같은 주변 코드는 AI가 빠르게 초안을 만들 수 있다. 그러면 개발자는 제품을 차별화하는 렌더링, 물리, 레벨 제작 흐름, 플랫폼 최적화에 집중할 수 있다.

하지만 AI가 책임을 없애지는 않는다. 엔진은 게임 루프와 메모리, 파일, 플랫폼 API, 프레임 타이밍을 다룬다. 잘못 만든 추상화는 몇 년 동안 비용을 만든다. 따라서 AI 보조 커스텀 엔진의 조건은 분명하다. 실제 게임과 함께 만들어야 하고, 초기에 playable loop를 확보해야 하며, 범용 기능 욕심을 버려야 한다. Soup Raiders의 native port가 흥미로운 이유도 기술 데모가 아니라 Nintendo Switch에서 60Hz와 3초 이하 로딩을 겨냥한 실제 제품 목표를 말하기 때문이다.

자주 묻는 질문

Q1: 인디 개발자는 커스텀 엔진을 만들어야 하나요?

A: 대부분은 아니다. 빠르게 게임을 완성해야 한다면 Unity, Godot, Unreal이 더 안전하다. 특정 성능이나 플랫폼 요구가 있을 때만 검토할 만하다.

Q2: AI 코딩 도구가 있으면 엔진 개발이 쉬워지나요?

A: 반복 구현은 쉬워질 수 있다. 하지만 렌더링, 타이밍, 메모리, 플랫폼 버그의 책임은 여전히 개발자에게 있다.

Q3: Soup Raiders 글의 핵심 숫자는 무엇인가요?

A: 2024년 Steam 출시작 중 custom engine 비중은 약 13%였지만, 판매량 기준으로는 43%를 차지했다는 VGInsights 수치다.

Q4: 기술 독립성이 왜 중요한가요?

A: 라이선스, 가격, 지원 플랫폼, 서비스 종료가 바뀌면 제품 로드맵이 흔들릴 수 있다. 직접 통제하는 영역은 이런 위험을 줄인다.

Q5: 가장 좋은 원칙은 무엇인가요?

A: 엔진만 만들지 말고 게임과 함께 만들어야 한다. 실제 콘텐츠가 없는 엔진은 요구사항을 검증하지 못한다.