▲

게임 엔진 없이 비디오 게임 개발하기 (2025)

 (noelberry.ca)
25P by GN⁺ 1일전 | ★ favorite | 댓글 2개
  • 상용 게임 엔진 없이도 충분히 쉽고 재미있게 게임 개발을 할 수 있음
  • 대형 엔진의 대부분 기능이 필요 없고, 직접 도구를 작성하면 유연성과 개발 효율성이 커짐
  • 현대 C# 및 오픈소스 라이브러리를 활용하면 팀 규모와 관계없이 충분한 개발 환경 제공 가능함
  • FMOD, SDL3, Dear ImGui 같은 라이브러리와 자체 툴 결합으로 필요에 맞는 파이프라인을 구성할 수 있음
  • 크로스플랫폼 개발, 유지보수, 이식성 측면에서 직접 구축한 경량화 프레임워크가 매우 유리함

서문: 20년차 게임 개발자의 소회

  • 2025년에도 상용 게임 엔진 없이 비디오 게임을 개발 중임
  • 주변에서 상용 엔진을 쓰지 않는 점에 놀라는 경우가 많음
  • Unity나 Unreal 같은 대형 엔진의 기본 기능들은 직접 구현하는 것에 비해 만족스럽지 않고, 결국 많은 부분을 다시 만들게 됨
  • 상용 엔진을 활용할 때 잦은 비즈니스 정책 변경이나 업데이트로 인한 문제에 노출됨
  • 개별 프로젝트에 딱 맞는 작은 도구를 직접 만드는 것이 더 효율적이고, 장기적으로도 유지보수가 쉬움

게임 개발에 필요한 프로그래밍 언어 선택

  • 오랜 기간 C# 을 주력 언어로 사용함
  • 현대의 C#은 과거에 비해 성능과 문법, 개발 경험이 많이 개선됨
  • dotnet watch 같은 핫리로드 기능이 있어, 실시간 코드 수정 및 테스트에 매우 편리함
  • 비개발자도 쉽게 접근해 팀원 간 역할 분담과 협업 효율성이 높음
  • 내장된 reflection 기능으로 에디터나 툴 제작에 강점이 있음

크로스플랫폼 라이브러리와 렌더링·입력 구현

  • SDL3를 사용하여 윈도우, 렌더링, 컨트롤러, 크로스플랫폼 지원 등 모든 기본 기능을 구현함
  • SDL3의 GPU abstraction으로 DirectX, Vulkan, Metal 등 다양한 환경 지원이 쉬워짐
  • SDL 상단에 직접 작성한 C# 레이어(예: Foster)를 공용 유틸리티로 활용함
  • FMOD를 마지막 남은 상용 오디오 툴로 사용, 이외에는 오픈소스 기반 파이프라인 구축
  • 기존에는 OpenGL/DirectX 직접 구현도 경험, SDL의 안정성이 상당한 이점임

에셋(Assets) 처리 방법

  • 직접 엔진을 사용할 경우, 게임에서 필요한 파일만 간단히 로딩
  • 픽셀 아트 게임처럼 소규모 에셋의 경우 모든 파일을 초기화 때 한 번에 적재함
  • 대형 프로젝트에서는 필요한 에셋만 요청 시 로딩하고, 장면 전환시 메모리 해제 방식 적용
  • 컨버팅이 필요한 경우 컴파일 시 자동 처리 스크립트 작성만으로 충분함

레벨 에디터 및 UI 툴

  • LDtk, Tiled, Trenchbroom 등 오픈소스 레벨 에디터와 데이터 연동이 쉬움
  • 대체로 프로젝트마다 맞춤형 에디터를 직접 구현함
  • UI 본체는 직접 작성하지 않고, Dear ImGui의 즉시모드 GUI를 적극 활용함
  • C#의 reflection과 ImGui 조합으로 게임 오브젝트 상태를 실시간 시각화 가능
  • 필요시 목적에 적합한 외부 툴과 자체 툴을 혼용함

크로스플랫폼 및 콘솔 이식성

  • 과거엔 콘솔 이식 문제로 C++ 선택 필요성이 컸으나, C# Native-AOT 등장으로 해결됨
  • FNA 등 오픈소스 프레임워크에서 적극적으로 콘솔 지원 확장 중임
  • SDL3가 지원하는 범용 추상화 레이어를 활용하면 대부분 시스템에서 동일한 코드 베이스 운용 가능함

개발 환경: Linux 중심의 오픈 생태계

  • 주력 개발 플랫폼을 Linux로 전환, 오픈소스 툴체인과의 궁합이 매우 좋음
  • 특정 상용 소프트웨어와의 연결이 남아 있지만(예: vscode, github), 오픈소스 생태계가 넓어질수록 지원도 확대됨
  • 개인적으로 Steam Deck 등 다양한 Linux 기반 플랫폼에서 동일한 작업 환경 구성 중임

추가 Q&A 및 사례

  • Godot 사용 문의: 오픈소스 엔진 중심 개발 니즈가 있다면 Godot 추천, 그 외에는 커스텀 툴 선호함
  • 3D 작업: 대형 엔진 장점이 있으나, 소규모 특화된 프로젝트엔 맞춤 프레임워크로 충분함
  • 고성능 기술 요구: 요구 수준에 따라 Unreal 등 대형 엔진 사용도 무방함
  • 팀 단위 엔진 변경: 소규모/단독 개발에 적합, 중대형 스튜디오도 장기 리스크 회피 이유로 커스텀 엔진 전환 사례 증가 중임
  • 에셋 워크플로우: Aseprite 파일을 빌트인 태그와 타이밍을 활용해 자동으로 애니메이션 변환 가능함

결론

  • 상용 게임 엔진 없이 게임 제작을 하는 것은 취향과 작업 방식에 달린 선택임
  • 필요와 재미를 최우선으로 자신에게 적합한 방법을 선택하면 됨
▲
chanapple 1일전  [-]

최근에 전략 게임을 만드려고 엔진을 오랫동안 찾다 보니 이럴거면 하나 직접 만드는게 낫다 싶었는데, 실천해서 성공한 사례를 보니 용기가 샘 솟네요.

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • 5년 동안 혼자 2D 게임 엔진을 개발하고 관련 유료 업무를 하면서 사람들이 잘 모르는 중요한 점을 설명하고 싶음
    엔진은 쉬운 부분임
    진짜 중요한 부분은 엔진 주변의 툴링, 콘텐츠, 애셋 파이프라인임
    다양한 데이터 소스와 포맷에서 텍스처, 오디오, 모델 파일(gltf, fbx, 애니메이션 등) 임포트
    에디터 앱에서 자르기, 복사, 붙여넣기, 실행취소, 다시실행, 저장, 삭제 같은 기본 편집 기능
    개발자가 에디터로 실제 데이터를 만들고 조작할 수 있게 하는 시각화와 기능(엔티티, 애니메이션, 씬, 오디오 그래프, 스크립팅 지원 등)
    정적 지오메트리 베이킹, 셰이더 컴파일, 텍스처·오디오 리샘플링 및 패킹, 게임 콘텐츠 애셋 팩 만들기 같은 데이터 패키징 및 전처리
    이 모든 게 끝나면 실제로 런타임 부분(즉 게임 메인루프와 하위 시스템)은 전체 시스템 중 작은 부분임
    그래서 게임 스튜디오에서는 엔진 담당자는 소수고, 툴을 만드는 프로그래머가 대다수인 이유임
    detonator 엔진: https://github.com/ensisoft/detonator

    • 범용성보다는 내 게임에 맞는 엔진을 만드는 것에 집중하는 게 중요함
      UI, 압축 등은 라이브러리와 프레임워크로 해결 가능
      OP가 imGUI처럼 소형 라이브러리를 이용하는 것도 좋은 예시
      모든 게임을 위한 엔진을 만드는 게 아닌 만큼, 사실상 안 해도 되는 일이 많아짐

    • 엔진은 애셋 파이프라인에 달린 작은 런타임 덧붙이기 같은 존재임
      요즘 셰이더 컴파일러도 3D API보다 점점 더 중요해지는 상황
      흥미로운 부분은 셰이더 컴파일러에 집중되고, 3D API는 셰이더 실행과 데이터 전달 역할에 그침

    • 사람들이 엔진이라 하면 자주 애셋 파이프라인과 에디터까지 포함해서 말하는 경향
      오늘날의 엔진은 메인 루프 + 3D API 함수만 있는 게 아님
      Unity 같은 엔진을 쓴다고 해서 렌더링 코드만 쓰는 개발자는 매우 소수임
      물론 Unity/Unreal 쓴다고 직접 애셋 툴을 쓸 일이 완전히 없는 건 아님

    • 최근 후속작용 엔진을 갈아엎으면서 이 점에 매우 동의
      포스트모템에 적었듯이 대부분 엔진이라 하면 게임 실행파일에 포함된 코드를 떠올리지만, 실질적으론 레벨 에디터, 콘텐츠 파이프라인, 디버깅/프로파일링, 개발 워크플로우처럼 게임과 함께 배포되지 않는 코드의 비중이 더 크다고 생각
      툴 개발은 엔진 개발보다 지루하고 지치기 쉬운 작업
      이런 이유로 많은 커스텀 엔진 게임 개발이 중간에 멈추는 현상 발생
      포스트모템: https://ruoyusun.com/2025/04/18/game-sequel-lessons.html

    • 에디터를 처음부터 만드는 일은 상당한 작업
      가능하다면 이미 있는 에디터를 활용함
      예를 들면 TrenchBroom(Quake 에디터) + func_godot 조합, 2D에선 Tiled
      게임 데이터 관리는 CastleDB도 있었지만, 이제는 Hide(본격 3D 에디터)랑 통합된 상태
      툴 만들고 나선 게임 설계하고 콘텐츠 만드는 일이 또 주요 단계

  • 몇 년 전 SDL2와 약간의 C++로 간단한 "sprite" 클래스를 만들고 콜리전 등 간단 기능 추가
    내가 만든 걸 굳이 엔진이라 부르자면 일종의 전기자전거 보조 정도였음
    "엔진"이 프로젝트/게임 전체를 리드하는 상황이 자주 발생한다는 점
    게임을 엔진에 맞추게 되는 경우가 많아 Unity 같은 대형 엔진 사용을 항상 피함
    이런 엔진들은 결국 같은 게임 구조만 만들게 되고, 자산만 다를 뿐임
    개인적으로는 엔진을 배우느라 시간 낭비하는 것보다 SDL로 짧은 러닝커브로 시작할 수 있고, SDL은 게임 외 다른 크로스플랫폼 프로젝트에도 활용 가능
    내 게임: https://store.steampowered.com/app/2318420/Glypha_Vintage/

  • 엔진을 직접 만드는 게 오래 걸린다지만, Unreal이나 Unity를 제대로 익혀 아이디어를 바로 게임으로 구현할 수 있을 정도가 되려면 어느 정도 시간이 필요한지 질문
    결국 내 엔진 제작이 끝나면 바로 그 레벨의 전문성을 확보하므로 장기적으로 시간 절약
    엔지니어 경력이 쌓일수록 직접 만드는 쪽이 시간 관점에서 유리해짐
    게임이 독특하거나 틈새시장일수록 직접 만드는 쪽이 더 타당
    Unreal의 복잡한 UI에서 몇 달 헤매고 애초에 원하는 게 범용 엔진에선 거의 불가능한 걸 알게 되는 경험은 비효율
    반면 초현실적 오픈월드 RPG라면 직접 제작은 좋은 선택이 아님
    커스텀 엔진의 제약이 오히려 창의성을 불러오고, 최고 수준이 아니더라도 더 독창적인 게임이 나옴

    • 직접 엔진을 만들어 본 적 있음
      처음에는 수많은 시행착오와 막다른 길을 겪으며 1년 정도 걸렸음
      3D 렌더링, 적응형 UI, 스켈레탈 애니메이션, 세이브 파일, 스마트 오브젝트, 경로 탐색, 스크립팅, 오디오, 물리 등 게임에서 볼 수 있는 거의 모든 서브시스템 구현
      특히 되감기 기능(Braid의 시스템처럼)을 직접 구현
      이런 기능은 엔진의 모든 서브시스템(스크립트, 물리 등)의 지원 필요
      내가 만든 엔진의 모든 부분을 알고 있어 추가 기능 개발에 엄청난 자유로움
      하지만 1년 개발 후 점점 번아웃이 와서 의욕이 사라짐

    • Unreal은 모르지만 Unity는 직접 코딩과 비교해 10배 이상 빠르게 개발 가능
      물리 기능은 1분이면 추가 가능하지만, 직접 엔진이면 외부 라이브러리 연동만 해도 하루 이틀 소요
      Unreal 유저 Noel이 보여주는 내부 시각화 기능도 Unity엔 내장
      바운딩 박스 조작 같은 편집도 기본 탑재
      만약 엔진의 기본 동작이 부족하다면 ImGui나 Yoga 기반 CSS 엔진으로 쉽게 확장 가능
      고급 파티클 에디터, 복잡성 해소된 셰이더, 모듈형 데이터 스트리밍 등 수많은 기능 제공
      이론상 다 직접 만들고 싶지만 결국 시간 문제로 완성 우선

    • Unreal이나 Unity를 익혀 게임 아이디어를 바로 구현하는 데 걸리는 시간과, 직접 엔진 만드는 데 걸리는 시간은 다른 질문
      조금만 아이디어 주면 몇 시간 안에 게임 플레이 가능한 프로토타입 제작 가능
      Unity는 초기에 프로그래밍만 하면 되고, Unreal은 블루프린트만으로도 거의 게임 출시 직전까지 가능
      10분 만에 슈퍼 헥사곤 스타일 게임 프로토타입 완성하는 영상 참고: https://www.youtube.com/watch?app=desktop&v=p8MzsDBI5EI
      유니티의 고유 요소는 프리팹 정도고 나머지는 게임개발 일반 개념
      Unreal 개발자 입장에서라면 Unity로도 1시간 이내 비슷한 프로토타입 제작 가능

    • “엔진 완성 이후”란 가정 자체가 비현실적일 수도 있음
      GameObject.Instantiate 같은 간단한 동작도 엔진에서 직접 구현하려면 어마어마한 리소스 필요
      2D/3D 물리, 셰이더, 플랫폼 지원 등 복잡도 감안
      엔진이 목표면 엔진을 만들고, 게임이 목적이면 게임 자체를 만들라는 의견

    • 게임 엔진을 만들 만큼의 게임개발 지식이 충분하다면
      Unreal이나 Unity를 익혀 프로토타입 만드는 데 하루면 충분
      완벽한 숙련까지 오래 걸리지만, 원하는 게임 프로토타입 완성 시간은 비교 불가

  • "모두 다 하는" 대형 엔진 없이도 게임 만들기는 더 쉽고, 더 재밌고, 때론 더 효율적
    다만 엔진의 특정 기능(예: Unreal의 역운동학, 애니메이션 블렌딩) 파고들다 보면 "차라리 직접 2~3주 고생 안 하길 잘했다"는 생각
    미니멀리즘이나 비대화 방지도 중요하지만, 이런 엔진들이 무거운 일을 대신 해주니 인기가 많음

    • 예전엔 나도 이런 방식이었음
      첫 3D 게임 만들 땐 입력, 오브젝트 관리, 컬링, 모델 로딩, 수학 라이브러리, 그래픽스, 노멀맵, SSAA 등 다 구현하다가 정작 게임 완성률은 0%
      그래도 취미 2D 프로젝트에선 여전히 브라우저 캔버스만으로 무의존 개발
      사실상 브라우저가 엔진 역할

    • “차라리 직접 만들지 않은 게 다행”이라는 의견에 대해
      장기적으로 인디 개발자 커리어를 생각한다면, 몇 주 걸리더라도 주제 깊이 이해+100% 소스코드 소유 및 재사용 가치가 더 큼

    • 내 졸업 논문은 NeXTSTEP/Objective-C 기반 파티클 엔진을 Windows 95/Visual C++로 이식하는 주제(OpenGL 기반, marching cubes 샘플 포함)
      이런 테마도 요즘 엔진에선 그냥 한 줄짜리 기능 중 일부

    • 엔진을 쓰면 프로젝트 진행 속도가 훨씬 빨라지고, 인프라 개발에 시간 소진하지 않아도 됨
      바퀴를 또 만드는 일은 대부분에게 큰 재미가 아님

    • 역운동학이나 애니메이션 블렌딩 같은 기능은
      만약 게임의 핵심이라면 구현할 가치가 있고, 아니면 불필요한 기술적 함정임

  • Lua & Love2D를 활용해 내 방식대로 게임을 만듦
    자체 제약 걸기라는 점 자체가 재미의 핵심
    개발이 재미없어지면 뭔가 잘못됐다는 신호이니 더 나은 방법 탐색
    내 게임 YOYOZO는 39KB로 작지만 Ars Technica 2023 최고의 게임 목록에 대작들과 함께 올랐음
    https://news.ycombinator.com/item?id=38372936

    • 그 게임 기억 남
      Playdate 구입한 지 수년 만에 SDK로 놀기 시작했는데, Lua도 처음 익히는 중
      강 타입과 언어적 안전성 바람이 있지만 상황에 맞는 충분함
      텍스트가 크랭크에 따라 가짜 3D 공간에서 도는 작은 기술 데모 만든 게 전부
      https://bsky.app/profile/haydenblai.se/post/3lpgnya4cqk2a
      이 프로젝트를 하며 오래 전 CRUD/웹앱 경력으로 삼각법 거의 다 까먹은 것 깨달음
      Playdate 개발의 최고 장점은 고정 캔버스라서 픽셀 위치만 정하면 모든 기기에서 그대로 동작한다는 해방감
      지난 개발 경력에선 반응형 UI만 만들다 이런 경험 매우 새로움

  • 게임 엔진(Godot, Unity, Unreal 등)으로 뭔가를 만들려고 하면 항상 엔진이랑 씨름하게 됨
    결국 정해진 게임 형식에 에셋을 얹는 느낌이라 내가 원하는 게임 제작이 어려워짐
    웹 개발에 비유하면, 워드프레스 같은 완제품 느낌
    기본 구성이 의도와 다를 때는 엄청난 해킹과 우회 작업이 필요함

  • 저자(노엘)는 Celeste라는 게임을 만들었으며 3백만 장 이상 판매
    https://en.wikipedia.org/wiki/Celeste_(video_game)

  • 나도 상당 부분 동의하며, 코드 기반의 C# 게임 프레임워크를 만들고 있음(XNA/Monogame의 정신적 후계, SDL 대신 Sokol 사용)
    https://zinc.graphics/
    현대적 C#의 강점: 크로스플랫폼, NativeAOT 컴파일링, 네이티브 핫리로딩, 리플렉션 등
    개인적으로 소스 제너레이터도 추가
    과거 부정적 이미지 남아 있지만, 최근 5년간 CoreCLR과 언어 발전은 놀라운 수준
    딱 한 가지 바라는 건 Union Types인데, 현재 제안되어 내년에 추가 기대
    https://github.com/dotnet/csharplang/blob/main/proposals/TypeUnions.md

    • 혹시 이런 프로젝트에 C# 입문하는 데 참고 자료가 있는지 궁금함
      C#은 Win32나 Unity에서만 써봤고, C/C++ 쪽 저수준 엔진 지식은 있지만, 게임 콘솔 등 크로스플랫폼에 C#은 불가능하다고 생각했음
      내 생각이 틀렸다는 걸 이제 깨달음

  • 어떤 소프트웨어든 처음엔 무에서 시작하는 걸 선호
    대형 프로젝트 경험 있는 사람에겐 느리게 느껴질 수 있지만, 스타트업 단계에선 오히려 더 빠름
    최소한만 구현하고, 추상화가 들어서면 새로운 기능 추가 속도가 더 빨라짐
    기업용 대형 SW와 내가 직접 쓴 미니 엔진의 생산성은 완전히 다름
    직접 쓴 코드는 바로 커팅, 리팩터링이 쉬워 훨씬 빠름
    이런 이유로 마이크로서비스와 소규모 팀을 선호
    직접 만들 땐 시행착오와 망가지는 지뢰밭을 반드시 거쳐야 하며, 언어나 플랫폼의 진짜 특성을 익히는 데도 수 년 소요
    하지만 그 과정 자체가 결국 개발자의 내공으로 남음

답변달기