# C로 게임을 만드는 이유 (네, C로요) > Clean Markdown view of GeekNews topic #26510. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26510](https://news.hada.io/topic?id=26510) - GeekNews Markdown: [https://news.hada.io/topic/26510.md](https://news.hada.io/topic/26510.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-09T02:32:55+09:00 - Updated: 2026-02-09T02:32:55+09:00 - Original source: [jonathanwhiting.com](https://jonathanwhiting.com/writing/blog/games_in_c/) - Points: 3 - Comments: 1 ## Topic Body - 개인 프로젝트의 모든 게임을 **‘순수 C’로 개발**하며, 이는 현재 드문 선택임 - 언어 선택의 핵심 기준은 **신뢰성, 이식성, 장기적 지속 가능성**으로, 특정 OS나 플랫폼에 종속되지 않음 - **단순성과 빠른 컴파일 속도**, 그리고 **엄격한 타입 검사와 강력한 경고 시스템**을 중시함 - C++·C#·Java·Go·Haxe 등 대안 언어들을 검토했으나, 복잡성·GC·OOP 강제 등으로 인해 적합하지 않다고 판단함 - C는 **위험하지만 단순하고 빠르며**, 폭넓은 플랫폼 지원과 견고한 라이브러리 생태계 덕분에 여전히 최적의 선택임 --- ### 언어 선택의 기준 - 필수 조건은 **신뢰성과 안정성**으로, 내가 만들지 않은 버그에 시간을 낭비하지 않기 위함 - 과거 Flash 기반 게임을 개발했으나 Flash의 쇠퇴로 인해 새로운 플랫폼으로의 이식 대신 **새로운 게임 제작에 집중**하고자 함 - 특정 OS에 종속되지 않고, **콘솔 개발 가능성**을 열어두기 위해 **이식성과 범용 라이브러리 지원**을 중시함 - 바람직한 조건으로는 **단순한 문법과 기억하기 쉬운 구조**를 꼽음 - 복잡한 API나 언어 기능을 계속 찾아보는 과정을 피하고자 함 - **엄격한 타입 검사, 강력한 경고, 정적 분석**을 통해 버그를 줄이고, **좋은 디버거와 동적 분석 도구**로 문제를 쉽게 찾고자 함 - **컴파일 속도**를 매우 중요하게 여김 - 긴 대기 시간은 집중력을 깨뜨리고 생산성을 떨어뜨림 - **객체지향(OOP)** 에 회의적이며, 데이터와 코드를 분리해 상황에 맞게 처리하는 방식을 선호함 ### 주요 대안 언어 평가 - **C++** - 게임 개발에서 여전히 표준이지만, **복잡성과 느린 컴파일 속도**로 인해 불만족 - 높은 성능과 다양한 기능을 제공하지만, 원하지 않는 기능이 많고 복잡도 비용이 큼 - **C#과 Java** - **장황하고 복잡**하며, 강한 OOP 중심 구조로 인해 자유도가 낮음 - 고수준 언어 특성상 복잡성을 숨기지만, 근본적인 문제를 막지는 못함 - **Go** - C의 현대적 재해석으로 긍정적으로 평가하지만, **stop-the-world 가비지 컬렉션**이 게임 개발에 부적합 - 게임용 라이브러리 부족과 장기적 지속성에 대한 우려 존재 - **JavaScript** - 웹 개발 환경의 빠른 변화와 Flash의 종말로 인해 불안정하게 느껴짐 - **느슨한 문법**으로 인해 대규모 소프트웨어 작성에 부적합하다고 판단 - **Haxe** - 웹 개발 시 유망하다고 평가하지만, **상대적 신생 언어**로 지속성에 대한 우려 존재 - **자체 언어 개발** - 매력적인 발상이지만, **기존 라이브러리 포기와 호환성 유지 부담**으로 인해 현실적이지 않다고 판단 ### C를 선택하는 이유 - **위험하지만 신뢰할 수 있는 언어**로, 단순한 구조 덕분에 주의 깊게 사용하면 안정적 - “날카로운 칼”에 비유하며, 다루기 어렵지만 숙련되면 강력한 도구임을 강조 - **컴파일 속도가 매우 빠르며**, 거의 모든 플랫폼에서 실행 가능 - 이식 과정도 비교적 간단하고, 장기적으로도 지속 가능성이 높음 - **라이브러리와 툴링 지원이 강력**하고 꾸준히 유지되고 있음 - 개인적으로는 이미 많은 **‘순수 C’ 코드 경험**이 있어 익숙함 - 다른 사람에게 C 사용을 권장하지 않으며, 이는 **개인적 취향과 작업 방식에 최적화된 선택**임 ## Comments ### Comment 50838 - Author: neo - Created: 2026-02-09T02:32:55+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46925808) - 나는 주로 **C 스타일**로 코드를 작성하지만, 필요할 때만 C++ 기능을 사용함 그래서 얼핏 보면 Rust 코드처럼 보이기도 함 게임을 C로 쓴다는 사람들은 C++ 기능을 싫어하면서 결국 **가상 인터페이스**를 직접 구현하거나 거대한 switch문을 만들어서 비슷한 일을 함 언어에 있는 기능을 안 쓰면 그만인데, 그 존재 자체를 불평하는 건 의미 없다고 생각함 C++은 템플릿을 남용하지 않으면 컴파일이 느려지지 않음 - 혼자 개발할 때는 그럴 수 있지만, 팀 단위로 장기간 유지되는 프로젝트에서는 상황이 다름 시간이 지나며 팀원이 바뀌고 리더가 바뀌면, 사용되는 기능의 **집합이 점점 커짐** 한 번 늘어난 기능을 줄이기는 매우 어려움 또, 원치 않는 기능을 사용하는 **라이브러리**를 써야 할 수도 있음 예를 들어, 나는 암묵적인 호출(소멸자, 연산자 오버로딩 등)을 싫어하지만, 라이브러리가 그걸 쓰면 결국 따라가야 함 - 적어도 switch문은 읽을 수 있음 C++의 가장 나쁜 점 중 하나는 자동으로 생성되는 **숨은 코드**가 너무 많다는 것임 - C++의 **동적 디스패치**는 모든 타입에 vtable을 붙이는 방식임 코드 대부분이 구체 타입(Goose, Duck 등)을 다루더라도, 모든 객체가 vtable 포인터를 들고 다님 반면 Rust는 필요한 곳에서만 vtable을 사용해서 메모리를 절약함 C 프로그래머는 필요한 기능만 직접 구현하므로, 언어가 강제하는 구조에 덜 묶임 - C++은 템플릿을 남용하지 않아도 느림 `<vector>` 하나만 포함해도 수만 줄의 코드가 포함됨 그래서 표준 라이브러리를 안 쓰면 “왜 다시 바퀴를 발명하냐”는 논쟁이 생김 이런 논쟁이 반복되면 그냥 **C로 돌아가는 게 훨씬 편함** 나도 2017년쯤 C로 전환했고, 지금도 C++ 라이브러리를 쓸 때마다 피로함 예외적으로 Dear ImGui는 괜찮지만, 그마저도 C 바인딩을 선호함 - 실제로 C++ 파일을 작성했는데 C++ 기능을 하나도 안 쓴 적이 있음 확장자를 .c로 바꾸자 **컴파일 시간이 절반**으로 줄었음 - 나는 C의 **거칠고 단순한 성격**을 좋아함, 다만 전처리기는 싫어함 그래서 Zig는 정말 신의 선물 같음 — C보다 단순하면서도 더 **정확한 언어 설계**를 가짐 예를 들어 Zig는 단일 포인터와 배열 포인터를 구분함 C 라이브러리를 가져와 더 사용하기 쉽게 만들 수 있고, 게임 개발에서 매우 유용함 대부분의 C++ 라이브러리도 C 헤더를 함께 제공함 [zig-gamedev](https://github.com/zig-gamedev)에는 이런 **Zig화된 C 라이브러리**가 많음 전처리기 대신 Zig의 **comptime** 기능이 훨씬 낫고, 단지 “컴파일 시점에 실행되는 Zig 코드”일 뿐임 - 하지만 실제로는 C++ 라이브러리 중 C 헤더를 내보내는 경우가 **너무 적음** - 나도 글쓴이의 생각에 공감함 언어를 좋아하게 되는 가장 큰 이유는 **단순함**임 그래서 C, Go, Odin, Zig 같은 언어를 선호함 하지만 **필요한 복잡성**을 우아하게 다루는 언어도 중요함 메모리 안전성과 동시성, 함수형 패턴이 필요한 네트워크 코드에서는 Rust가 자연스러움 반면, 인디 게임처럼 단순하고 빠른 코드에는 C나 Odin이 잘 맞음 Odin은 Go의 단순함과 C의 성능을 결합한 느낌이라 추천함 Raylib로 게임 만들기도 쉬움 - 흥미롭게도 나는 Zig를 **Go와 C의 중간 지점**으로 설명하곤 함 Odin이 Zig보다 그 자리에 더 잘 맞는다고 생각하는지 궁금함 - 참고로 언어 이름은 Go이고, golang은 단지 도메인 이름임 - 원문에서 Go의 게임 라이브러리 지원이 부족하다고 했는데, 그건 **2015년쯤 글**로 보임 지금은 상황이 달라졌을 수도 있음 - [Wayback Machine](https://web.archive.org/web/20160110012902/http://jonathanwhiting.com/)에 2016년 1월의 스냅샷이 있음 당시 만든 게임들의 스크린샷도 볼 수 있음 예를 들어 [Knossu](https://web.archive.org/web/20160112060328/http://jonathanwhiting.com/games/knossu/press.html)는 독특한 3D 스타일을 가짐 - 2026년에 C로 게임을 만드는 건 약간 **미친 짓**일 수도 있지만, 나도 그렇게 함 예를 들어 [Chrysalis](https://store.steampowered.com/app/1594210/Chrysalis/)를 C로 개발했음 (GLFW3, FMOD 사용) - 나는 2년째 **Jedi Academy 코드베이스**를 다루고 있음 (C & C++) idTech3 기반인데, 전투 시스템이 너무 정밀해서 작은 변경도 전체 밸런스를 깨뜨림 심지어 `i++` 하나 추가해도 타이밍이 달라짐 그래서 22년 된 컴파일러를 그대로 사용 중임 현대화된 포크들도 있지만, 원래의 감각을 잃었음 idTech3는 정말 **C의 정수(精髓)** 를 보여주는 엔진임 - 수천 개의 게임이 C로 작성되었고, OpenGL, Vulkan, DX 같은 **그래픽 API**도 전부 C 기반임 그래서 전혀 이상하지 않음 대부분의 게임 엔진도 C/C++로 작성됨 - Khronos API는 C, DirectX는 C++ 기반 COM/WinRT, Metal은 Objective-C와 C++ 혼합임 콘솔은 세대마다 다름 - SDL3도 C로 작성되었고, Box2D의 최신 버전도 **C로 다시 작성됨** - DirectX는 C++이고, 대부분의 게임 엔진도 C++임 리눅스 프로그래밍과 달리, 게임 개발은 30년 넘게 C++ 중심이었음 - 나는 근본적으로 **C를 사랑하는 사람**임 수십 년 동안 잘 써왔지만, 팀 단위로 C 코드를 관리하면 고통이 커짐 또, 현대 언어에 비해 개발 속도가 느림 그래도 단순함의 매력은 여전함 - 왜 C 코드베이스가 팀 작업에서 더 아픈지 궁금함 내 경험상 C++보다 C가 덜 고통스러웠음 - “적게 말하고 더 의미 있게” — 즉, **간결함**이 핵심임 - 리눅스 커널에는 2025년에만 2,134명의 개발자가 참여했음 그 사실이 C의 협업 한계를 약화시킴 - “아무도 C로 게임 안 만든다”는 말은 과장임 지금은 주류는 아니지만 여전히 많은 사람이 C로 게임을 만듦 - “아무도”나 “모두” 같은 표현은 보통 **절대적인 의미가 아님** 당신은 예외일 뿐이고, 그 말은 여전히 통계적으로 맞음 - 나는 C가 좋음 **메모리 관리**를 완전히 통제할 수 있고, 예측 가능한 동작을 얻을 수 있음 MISRA 규칙처럼 사전 할당을 요구하는 환경에서는 특히 유용함 하드웨어 수준의 예외나 오류를 직접 다루기에도 좋음 단위 테스트 작성도 쉬움 - C는 진입 장벽이 낮지만, **메모리 관리 지식**은 필수임 Java 개발자인 내가 .h와 .so만 주어진 상황에서 빠르게 커넥터를 만들어야 했을 때, C++보다 C를 선택했음 C가 날카로운 칼이라면, C++은 **회전하는 칼기둥** 같음 — 방심하면 다침 다만 문자열 처리는 C에서 너무 고통스러워서 C++의 문자열 시스템을 빌려오고 싶음 - C++의 좋은 점은 **원하지 않는 기능은 안 써도 된다는 것**임