Steam(스팀)이 Go(고) 런타임을 망가뜨린다고? 게임 개발, 이제 Go로도 가능한가?

Steam(스팀)이 Go(고) 런타임을 망가뜨린다고? 게임 개발, 이제 Go로도 가능한가?

여러분, 안녕하세요! 오늘은 게임 개발자, 특히 Go(고) 언어를 사용하는 개발자분들에게 흥미로운 소식을 가져왔는데요.

 

최근 Steam(스팀) 커뮤니티에서 "Steam이 Go 런타임을 망가뜨린다(Steam breaks Go runtime)"는 제목의 글이 올라와 뜨거운 논쟁이 벌어지고 있습니다.

 

이 글은 단순한 불만을 넘어, Steam 플랫폼과 Go 언어의 통합, 더 나아가 Go 언어를 이용한 게임 개발의 가능성에 대한 심도 있는 논의로 이어지고 있는데요. 과연 무슨 내용일까요?

 

함께 자세히 알아봅시다!

 

1. Steam(스팀)이 Go(고) 런타임을 망가뜨린다고?

결론부터 말씀드리자면, Steam이 Go 런타임을 '망가뜨린다'기보다는, Steam 오버레이(Steam Overlay) 기능이 프로세스 전환을 처리하는 과정에서 Go 런타임과 예상치 못한 상호작용을 일으키는 것으로 보입니다.

 

Steam 오버레이는 게임 내에서 친구 목록, 채팅, 웹 브라우징 등 다양한 기능을 제공하는 편리한 기능인데요.

 

하지만 이 오버레이가 활성화될 때 Go 런타임과 충돌을 일으킬 수 있다는 것이죠.

 

이 문제는 GitHub(깃허브)의 Go 이슈 트래커(https://github.com/golang/go/issues/71242)에서도 확인할 수 있는데요.

 

일부에서는 Steam이 Go 런타임에 어떤 '마법'을 부리고 있다는 추측을 하기도 하고, Steam의 안티 치트 기술(Anti-Cheat Technology)과 관련이 있을 수 있다는 가설을 제기하기도 했습니다.

 

하지만 이는 사실이 아니며, Steam 오버레이와 관련된 문제로 밝혀졌습니다.

 

2. 왜 Go(고)로 게임을 만들까? C#은 안될까?

Go 언어(Go Language)로 게임을 개발한다는 사실에 의아해하는 분들도 있을 텐데요.

 

"Meg's Monster"와 같은 Go로 개발된 게임이 Steam에 출시되기도 했습니다.

 

그렇다면 왜 C#과 같이 더 많은 지원을 받는 언어 대신 Go를 선택하는 걸까요?

 

이에 대한 답변은 다양합니다.

• Go의 간결함과 안정성: Go는 깔끔하고 안정적인 언어라는 평가를 받고 있습니다.
• IDE(Integrated Development Environment) 불필요: Go는 IDE 없이도 개발이 가능합니다.
• 뛰어난 의존성 관리(Dependencies Management): Go의 모듈 시스템(Module System)은 버전 관리를 단순하고 재현 가능하게 만들어줍니다. go.mod 파일만 있으면 오래된 코드도 안정적으로 빌드할 수 있습니다.
• 네이티브 바이너리(Native Binary) 컴파일: Go는 별도의 런타임(.NET, JVM 등) 없이 네이티브 바이너리로 컴파일되기 때문에 배포가 간편합니다.
• 크로스 플랫폼(Cross-Platform) 빌드 지원: 다양한 운영체제에서 실행 가능한 게임을 쉽게 만들 수 있습니다.
• 뛰어난 동시성(Concurrency): Go의 가장 큰 장점 중 하나는 Goroutine(고루틴)인데요. 고루틴은 동시성 프로그래밍(Concurrent Programming)을 매우 쉽게 만들어줍니다. (하지만 아이러니하게도 Goroutine은 Steam 클라이언트와 잘 작동하지 않아 게임 개발에서는 큰 이점을 제공하지 못할 수도 있다는 의견도 있습니다.)

물론 C#과 같은 다른 언어들도 훌륭한 선택지입니다.

 

C#은 안정적이고, IDE 없이도 개발이 가능하며, 의존성 관리도 잘 되어 있습니다.

 

하지만 Go의 동시성 처리 모델(고루틴, 채널)은 병렬 프로그래밍(Concurrent Programming)을 매우 쉽게 만들어준다는 점에서 차별점을 가집니다.

 

3. Ebitengine(에비텐진), Raylib-go 등 Go 게임 개발 프레임워크의 등장!

Go 언어로 게임을 개발할 수 있도록 지원하는 다양한 프레임워크(Framework)들이 등장하고 있는데요.

 

그중 대표적인 것이 Ebitengine(에비텐진)과 Raylib-go입니다.

 

특히, Ebitengine은 다양한 플랫폼을 지원하며, 이번 Steam 이슈를 제기한 사람도 바로 Ebitengine의 개발자인 Hajime Hoshi(하지메 호시)입니다.

 

Ebitengine을 사용하여 2D, 3D, 아이소메트릭 2D(Isometric 2D) 등 다양한 형태의 게임을 개발하려는 사람들이 늘어나고 있습니다.

 

4. Steam(스팀)은 단순한 게임 플랫폼이 아니다?

Steam은 단순히 게임을 구매하고 실행하는 플랫폼을 넘어, 게임 개발과 관련된 여러 기술적인 부분에도 관여하고 있는 것으로 보입니다.

 

특히, Steam 오버레이(Steam Overlay)와 같은 기능이 Go 런타임과 충돌을 일으킬 수 있다는 점은 시사하는 바가 큰데요.

 

Steam이 프로세스 전환 시 오버레이로 인해 발생하는 문제를 제대로 처리하지 못하는 것 같다는 의견, Steam이 낮은 수준의 기술까지 관여하는 것에 대한 우려 등 다양한 의견이 나오고 있습니다.

 

Steam은 CEF(Chromium Embedded Framework, 크로미움 임베디드 프레임워크)를 기반으로 하지만, 뭔가 추가적인 작업을 하고 있는 것으로 보이며, 이 문제는 Windows(윈도우) 환경에서 발생하는 것으로 추정됩니다.

 

5. 결론: Steam(스팀)과 Go(고) 런타임의 문제는 해결될 수 있을까?

Steam과 Go 런타임 간의 문제는 아직 명확하게 해결되지 않았지만, Go 언어로 게임을 개발하려는 시도는 계속될 것으로 예상됩니다.

 

Ebitengine과 같은 프레임워크를 통해 Go로도 충분히 훌륭한 게임을 만들 수 있다는 것을 증명하고, Steam과의 호환성 문제를 해결해 나간다면, Go는 게임 개발 분야에서 더욱 매력적인 선택지가 될 수 있을 것입니다.

 

앞으로 Go 커뮤니티와 Steam 개발자들이 이 문제를 어떻게 해결해 나갈지 함께 지켜봅시다!

 

---