youdozi's memory
← 개발 기록

오픈소스 게임 엔진 비교: Godot·Bevy·Stride·O3DE 선택 기준

발행일:
이 글의 목차

소규모 팀이 일반적인 2D·3D 게임을 시작한다면 Godot을 첫 후보로 검증할 만합니다. Rust와 도구 개발을 함께 맡을 팀이라면 Bevy, C# 작업 흐름이 중요하면 Stride, 큰 3D 콘텐츠·빌드 파이프라인을 운영할 여력이 있다면 O3DE를 검토할 수 있습니다. 이는 검증을 시작할 후보이며 성능 순위가 아닙니다.

게임 엔진을 고르는 개발자를 위한 문서 기반 비교입니다. 2026년 11월 2일 확인한 릴리스 기준은 Godot 4.7.2, Bevy 0.20, Stride 4.4, O3DE 26.05입니다. 아래 실행 예제는 Godot의 작은 이동 함수만 검사합니다. 다른 엔진의 편집기 사용감·렌더링 속도·내보내기 안정성을 실험한 결과는 아닙니다.

무엇을 같은 기준으로 비교할까?

네 프로젝트 모두 게임 엔진을 표방하지만 제작 방식은 다릅니다. 통합 시각 편집기와 코드 중심 ECS 방식에서는 팀이 조합해야 하는 도구의 범위가 달라집니다. 프레임워크나 렌더링 라이브러리도 대안이 될 수 있지만, 그때는 직접 갖춰야 하는 씬·자산·편집 도구를 작업량에 포함해야 합니다.

엔진과 릴리스 기준 제작 방식 도입 전에 먼저 확인할 질문
Godot 4.7.2 씬·노드 편집기와 스크립트 선택한 언어로 실제 목표 기기에 내보낼 수 있는가?
Bevy 0.20 ECS 기반 Rust 시스템·컴포넌트 도구 구성과 API 마이그레이션을 팀이 감당할 수 있는가?
Stride 4.4 C#과 Game Studio 개발 머신에서 필요한 편집기를 쓸 수 있는가?
O3DE 26.05 확장 가능한 3D 편집기·컴포넌트 파이프라인 작은 씬의 빌드·자산 가져오기·패키징을 끝낼 수 있는가?

아래 시나리오는 이 제작 방식에서 도출한 추천입니다. 실제 팀이 네 엔진으로 게임을 출시한 경험담은 아닙니다.

팀의 작업 방식에는 어떤 엔진이 맞을까?

Godot: 편집부터 실행까지 한 흐름으로 시작하기

씬을 편집하고 동작을 붙인 뒤 한 환경에서 반복 실행하려는 팀에는 Godot이 합리적인 비교 기준입니다. MIT 라이선스는 비공개 소스 게임 제작을 허용하지만, 엔진을 배포할 때는 관련 저작권·라이선스 고지가 필요합니다. 플러그인·폰트·음악·모델의 조건은 별도로 확인해야 합니다.

언어와 플랫폼의 조합을 초기에 확인하세요. 현재 Godot 웹 내보내기 문서는 Godot 4의 C# 프로젝트를 웹으로 내보낼 수 없다고 명시합니다. 데스크톱 C# 시제품의 실행은 브라우저 배포의 증거가 아닙니다. 콘솔은 Godot 포팅 안내에 설명된 플랫폼 승인·공식 SDK·비공개 내보내기 템플릿 또는 외부 업체 경로가 필요합니다. 엔진이 오픈소스여도 이 절차가 없어지지는 않습니다.

Bevy: Rust와 도구 운영 책임을 함께 선택하기

Bevy는 렌더러만 제공하는 라이브러리가 아니라 엔진입니다. 공식 소개는 Rust·ECS와 MIT 또는 Apache 2.0 라이선스 선택을 설명합니다. API 호환성이 깨지는 릴리스와 쉽지 않을 수 있는 마이그레이션도 경고합니다.

따라서 시스템과 컴포넌트를 개발 모델의 중심에 두려는 팀이 검토할 만합니다. 편집기 연동·자산 수정과 실행의 반복·버전 이행은 실제 프로젝트로 확인할 항목에 넣으세요. Rust에 익숙하다는 사실만으로 제작이 빨라지는 것은 아니며, 병렬 ECS도 특정 게임의 프레임 시간 우위를 증명하지 않습니다.

Stride: C# 지원과 편집기 실행 환경을 구분하기

Stride의 FAQ는 MIT 라이선스와 엔진 로열티가 없다는 점을 설명합니다. 기존 .NET 팀이라면 C# 작업 흐름을 활용할 후보가 됩니다.

다만 플랫폼 표는 개발 호스트와 게임의 배포 대상을 구분합니다. Windows는 편집기를 완전 지원하고, Linux·macOS는 조건이 있는 빌드·코드 중심 경로를 지원하며 편집기를 네이티브로 실행할 수는 없습니다. 4.4 발표는 비Windows 빌드 개선을 소개합니다. 이를 모든 OS에서 같은 편집기 작업이 가능하다는 뜻으로 확대하면 안 됩니다.

O3DE: 시연 영상보다 제작 파이프라인을 먼저 확인하기

확장 가능한 3D 파이프라인을 직접 운영할 팀이라면 O3DE를 후보에 넣을 수 있습니다. 라이선스 파일은 기본 Apache 2.0과 MIT 선택권을 명시하고 외부 구성 요소의 조건을 별도로 다룹니다. 다운로드 페이지는 Windows·Linux 패키지와 상당한 개발 머신 요구사항을 제시합니다. 이는 호스트 요건이지 게임을 내보낼 모든 플랫폼의 목록은 아닙니다.

대표 자산 가져오기, 프로젝트 빌드, 작은 씬의 패키징부터 확인하세요. 26.05 릴리스 노트는 새 파티클 시스템을 실험 단계로 표시하고 운영 사용을 권하지 않습니다. 릴리스 노트에 실렸다는 이유만으로 제작에 바로 의존해도 되는 기능은 아닙니다.

무료라면 오픈소스이고 제작비도 들지 않을까?

그렇지 않습니다. 소스를 볼 수 있거나 구매 가격이 없다는 사실만으로 오픈소스 라이선스가 성립하지는 않습니다. 예를 들어 Defold는 현재 자신을 source available로 설명하므로, 위 네 엔진과 자동으로 같은 범주에 넣기보다 실제 라이선스를 확인해야 합니다.

엔진 라이선스가 콘솔 포팅·에셋 사용권·호스팅·플러그인·유지보수 비용까지 해결하지도 않습니다. 엔진이 제공하는 부분, 다른 라이선스가 필요한 부분, 팀이 구현할 부분을 나누세요. 그 범위 없이 총비용을 추정하지 않는 편이 낫습니다.

작은 시제품에서는 무엇을 검증할까?

후보 엔진에 같은 합격 과제를 주세요. 대표 자산 하나를 불러오고, 상호작용 하나를 구현하고, 의도한 기기로 배포할 빌드를 만듭니다. 준비 과정과 수정·실행의 반복에서 막힌 부분, 충족하지 못한 요구를 기록하세요. 이는 제안하는 평가 절차이며 이 글에서 수행한 엔진 벤치마크가 아닙니다.

그중 재현 가능한 한 부분으로 Godot의 화면 없는 이동 검사를 살펴봅니다. 위치·합성 방향 입력·경과 초를 받아 방향 벡터의 길이를 1 이하로 제한하고 속도를 적용한 다음, 결과 점을 사각 영역 안으로 제한합니다. 입력은 유한하고 경과 시간은 음수가 아니라고 가정합니다. 이 제한은 장애물 충돌·스프라이트 크기 처리·물리 시뮬레이션이 아닙니다.

위치·방향·경과 시간을 받아 방향 크기를 제한하고 속도와 시간을 적용한 뒤 영역 안으로 점을 제한해 새 위치를 반환하는 흐름

그림은 advance 한 번의 호출입니다. 아래 검사 코드는 호출을 반복해 결과를 확인하며 키보드 입력이나 캐릭터 렌더링은 하지 않습니다. 벡터 연산은 Vector2 문서에 설명돼 있습니다. 이렇게 검사한 동작을 편집기 생산성이나 게임 성능 주장과 분리합니다.

표준 Godot 4.7.2 편집기 바이너리를 godot으로 실행할 수 있는 환경에서, 같은 디렉터리에 project.godot과 movement.gd를 저장합니다. 엔진 설치 후 이 스크립트를 실행할 때는 씬·외부 자산·패키지·네트워크가 필요하지 않습니다.

project.godot:

config_version=5

movement.gd:

extends SceneTree

const SPEED := 120.0
const LIMIT := Vector2(640.0, 360.0)

func advance(pos: Vector2, direction: Vector2, delta: float) -> Vector2:
    var bounded := direction.limit_length(1.0)
    var next := pos + bounded * SPEED * delta
    return next.clamp(Vector2.ZERO, LIMIT)

func _initialize() -> void:
    var cases := [
        [Vector2(100, 100), Vector2.ZERO, 0.5, Vector2(100, 100)],
        [Vector2(100, 100), Vector2.RIGHT, 0.5, Vector2(160, 100)],
        [Vector2.ZERO, Vector2(1, 1), 1.0, Vector2(84.852814, 84.852814)],
        [Vector2.ZERO, Vector2(0.5, 0), 1.0, Vector2(60, 0)],
        [Vector2(639, 100), Vector2.RIGHT, 1.0, Vector2(640, 100)],
        [Vector2(5, 100), Vector2.LEFT, 1.0, Vector2(0, 100)],
        [Vector2(100, 359), Vector2.DOWN, 1.0, Vector2(100, 360)],
        [Vector2(100, 100), Vector2.RIGHT, 0.0, Vector2(100, 100)],
    ]
    for sample in cases:
        var actual := advance(sample[0], sample[1], sample[2])
        if not actual.is_equal_approx(sample[3]):
            push_error("movement mismatch")
            quit(1)
            return
    var split := advance(advance(Vector2(100, 100), Vector2.RIGHT, 0.25), Vector2.RIGHT, 0.25)
    if not split.is_equal_approx(advance(Vector2(100, 100), Vector2.RIGHT, 0.5)):
        push_error("time-step mismatch")
        quit(1)
        return
    print("movement cases=9")
    quit(0)

해당 디렉터리에서 Godot 명령행 인터페이스로 실행합니다. macOS에서 PATH에 등록하지 않았다면 godot을 설치한 번들의 Godot.app/Contents/MacOS/Godot 경로로 바꾸세요.

godot --headless --no-header --path . --script movement.gd --quit-after 1

macOS에서 Godot 4.7.2로 실행했을 때 출력은 다음과 같았습니다.

movement cases=9

검사는 정지 입력·수평 및 대각선 이동·부분 크기 입력·상한과 하한·경과 시간 0·경계에 닿지 않는 구간의 시간 분할을 다룹니다. 렌더링·목표 기기 내보내기·장애물·네트워킹·엔진 간 성능 비교는 검사하지 않습니다.

최종 선택은 어떻게 내릴까?

게임에 필요한 작업 흐름과 목표 빌드를 충족하고, 팀이 유지보수 부담을 감당할 후보를 고릅니다. 시각 편집과 반복 실행이 우선이면 Godot으로 시제품을 시작하세요. Rust·ECS 운영을 명시적으로 원한다면 Bevy의 도구 구성과 마이그레이션 비용을 확인합니다. C# 팀은 실제 편집기 호스트에서 Stride를 시험하고, 큰 3D 파이프라인은 O3DE의 자산·빌드 흐름을 검증한 뒤 시연 기능에 의존하세요.

다음에 필요한 결과물은 보편적인 엔진 순위표가 아니라 작은 목표 기기 빌드와 충족하지 못한 요구 목록입니다. 판단 근거를 프로젝트와 함께 남기면 엔진 업그레이드도 같은 동작을 기준으로 평가할 수 있습니다.

댓글

GitHub에서 보기 ↗