Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 글은 게임 개발 시 모든 요소를 처음부터 새로 만들지 말고, 저장 시스템, 오디오 매니저 등 공통적인 유틸리티를 구축하여 재사용하는 것이 중요하다고 강조합니다. 이러한 '영구적인 도구 상자'를 만드는 것이 초보자와 전문가의 가장 큰 차이점이며, 실제 게임 개발에 집중할 시간을 확보하게 해줍니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 YouTube Code Monkey (Unity C#)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기안녕하세요, CodeMakie입니다. 이런 경험을 몇 번이나 해보셨나요? public class, 체력 시스템(health system) 같은 것을 만들고, 그리고 체력 양(health amount)에 대한 private int가 있고, 그리고 damage amount라는 int를 받는 public void damage 함수가 있습니다. 그리고 그냥 health amount에서 damage amount만큼 빼는 식이죠. 만약 이걸 한 번 해봤다면 훌륭하지만, 이런 걸 정말 여러 번 작성했다면, 아마도 제대로 하고 있지 않을 가능성이 높습니다. 기본적으로 이 영상에서는 여러분에게 모든 새 프로젝트를 '절대적인 제로(Absolute Zero)'부터 시작하는 것을 멈추도록 권장하고 싶습니다. 여러분이 만드는 모든 게임에는 몇 가지 공통적인 요소들이 있을 것입니다. 저장 시스템(save system), 설정(settings), 오디오 매니저(audio manager), 메인 메뉴(main menu), 일종의 장면 로더(scene loader) 같은 것들 말이죠. 이들은 기본적으로 모든 게임에 필요할 것이기 때문에, 저는 여러분이 이것들을 한 번 작성하고 재사용하기를 권장합니다. 자신만의 유틸리티(utilities)를 구축하고, 새로운 프로젝트를 시작할 때마다 그것들을 재사용하는 것입니다. 이것은 놀라울 정도로 중요하지만, 초보자들은 얼마나 중요한지 제대로 이해하지 못하는 부분입니다. 만약 이렇게 하지 않고, 매번 모든 것을 처음부터 구축한다면, 결국 지루한 인프라(infrastructure)를 만드는 데 많은 시간을 보내고, 실제 게임을 만드는 시간은 극히 적게 남게 됩니다. 반면에 자신만의 유틸리티, 자신만의 툴킷(toolkit)을 구축하는 노력을 기울인다면, 모든 게임에서 발생해야 하는 그 지루한 설정 작업들이 재사용되기 때문에 훨씬, 훨씬 빠르게 처리할 수 있고, 그러면 여러분이 실제로 게임의 독특함을 만드는 데 적절한 시간을 할애할 수 있습니다. 이것은 초보 개발자와 전문 개발자 사이의 가장 큰 차이점 중 하나입니다.
본질적으로 전문가들은 매번 모든 것을 새로 구축하기보다는 검증된 솔루션을 재사용합니다. 예를 들어, 저장 시스템(save system)이 필요하다면, 그것을 반복해서 다시 작성하는 것이 아니라 이미 작동하는 것을 가져다 쓰기만 하면 됩니다. 이것을 하는 것이 지루한 인프라 대신 실제로 자신만의 게임 만드는 것에 집중할 수 있도록 도와줍니다. 따라서 시간이 지나면서 점점 더 많은 게임을 만들수록, 기본적으로 이 점에 대해 생각해 보려고 노력해야 합니다. 게임마다 들고 다닐 수 있는 영구적인 도구 상자(permanent toolbox)에 넣을 수 있는 다양한 시스템들을 생각해보는 것입니다. 저장 시스템이나 설정(settings), 오디오 및 씬 로딩(audio and scene loading), 유틸리티 객체 풀러(utility object pullers)나 UI 도우미 같은 것들, 어떤 종류의 입력 또는 디버그 도구 등이 있습니다. 이 모든 것은 한 번 구축하고 다듬은 다음, 다음 프로젝트에서도 반복적으로 재사용하기에 아주 좋은 것들입니다. 다시 말하지만, 전문가가 되고 싶다면 바로 이것을 해야 합니다. 하지만 이 주제에 대해 주의할 점이 하나 있습니다. 모든 것을 처리하는 범용 프레임워크(universal framework)를 만들려고 해서는 안 됩니다. 자신만의 재사용 가능한 도구와 시스템을 구축해야 하지만, 첫날부터 모든 것을 일반화(generic)해서 만들어서는 안 됩니다. 어떤 시스템을 만들면서 '좋아, 나중에 다른 프로젝트에서도 사용할 수 있도록 이걸 아주 범용적으로 만들어야지'라고 생각하지 마세요. 그렇게 하면 너무 복잡한 무언가를 만드는 데 빠져들 위험이 있고, 이는 오히려 부정적이며 실제 게임을 완성하는 것을 방해할 수 있습니다. 따라서 과도한 엔지니어링(over-engineering)을 경계해야 합니다. 목표는 대략 이와 같아야 합니다. 먼저, 현재 게임에 필요한 어떤 종류의 시스템이나 무언가를 구축합니다. 그것을 만들고, 그 특정 시스템에서 무엇이 작동하는지 배웁니다. 그리고 '좋아, 이 시스템이 다른 프로젝트에서도 재사용될 수 있을까?'라고 살펴봅니다. 만약 그렇다면, 단지 그 하나의 시스템만 추출하여 다듬고 사용하기 매우 쉽게 만드는 것입니다.
그러면 여기에 모든 종류의 재사용성 개선 사항을 추가하고, 작업하기 쉽게 만들고, 조금 더 일반화하며, 기본적으로 드래그 앤 드롭만 하면 되게 만듭니다. 그리고 다시 한번, 그 결과물을 다음 프로젝트에 가져갑니다. 그리고 또다시, 그 다음 프로젝트를 구축하면서 무엇이 효과적인지 배우고, 그것을 반복하고, 기본적으로 이 사이클을 계속해서 거칩니다. 그래서 이것과 이것의 차이점은 여기에선 필요할지도 모른다는 것조차 모르면서 무언가를 과도하게 엔지니어링(over-engineering)한다는 점입니다. 반면에 여기서는 먼저 실제로 무언가를 구축하고, 그것이 작동하는지, 유용한지 확인한 다음, 다듬어서 다음번에는 이미 아주 잘 작동하는 것이 있다는 것입니다. 본질적으로 제가 여기서 말하는 모든 것의 핵심은 바로 이것입니다. 만들게 되는 모든 게임이 다음 게임을 더 쉽게 만들어야 한다는 것입니다. 그래서 첫 번째 게임에서는 어떤 종류의 유틸리티나 툴킷도 없기 때문에, 문자 그대로 모든 것을 처음부터 구축해야 합니다. 하지만 그렇게 한 후에, 만약 올바르게 구축한다면, 작업 도구 상자에 여러 가지 도구를 추가할 수 있습니다. 그리고 다음 게임을 할 때는 더 많은 도구들을 갖게 됩니다. 그러다가 게임 다섯 번째쯤에 이르면, 갑자기 엄청난 양의 인프라가 이미 준비되어 있는 것입니다. 다시 이 그래프로 돌아가서, 게임 번호 5까지는 실제로 게임 자체를 만드는 데 대부분의 시간을 쓸 수 있게 됩니다. 개인적으로 저는 이 주제의 열렬한 팬입니다. 코드 재사용, 자신만의 유틸리티, 자신만의 툴킷을 만드는 것을 정말 좋아합니다. 왜냐하면 제가 직접 경험했기 때문에 얼마나 더 효율적인지 알기 때문입니다. 저에게는 일반적으로 10년 이상 동안 유틸리티를 작성하고 재사용해 왔습니다. 긴 시간이죠. 2013년으로 거슬러 올라가서, 저는 게임 'Survivor Squad'를 만들었습니다. 그것이 제가 만든 첫 번째 Steam 게임이자, 동시에 제가 만든 첫 번째 Unity C# 게임이었습니다.
그리고 2013년에 출시된 이 게임에서 실제로 이 클래스, 즉 Function Timer 클래스를 작성했습니다. 아주 간단한 클래스입니다. 특정 시간이 지난 후에 일종의 대리자(delegate)를 호출하기 위해 단 하나의 코드 줄만 호출하면 됩니다. 따라서 타이밍과 관련하여, 예를 들어 5초 후에 적을 스폰시키고 10초 후에 플레이어를 공격하도록 지시하는 경우에 사용됩니다. 이런 종류의 로직에는 엄청나게 유용합니다. 아니면 버튼의 경우, 마우스 오버 시 이 버튼을 더 크게 만들고 1초 후에 다시 작게 만드는 식입니다. 또는 컷신(cut scene)의 경우, 1초 후에 이 메시지를 표시하고, 5초 후에 이 메시지를 표시하는 식으로요. 네, 정말 유용한 범용 클래스입니다. 그리고 네, 또 말씀드리지만 제가 직접 만들었고 원래부터 만들어온 것입니다. 제 PC에 실제 파일이 있습니다. 제가 처음에 이걸 만들었거나 아니면 마지막으로 수정한 것이 2013년인 것 같습니다. 이게 제가 실제로 쓴 코드가 무려 13년 전의 코드입니다. 정말 오래된 거죠. 여기 실제 클래스가 있으니 한번 보실 수 있습니다. 그리고 제 채널을 꾸준히 지켜보신 분들은 아마 '이건 요즘 내가 쓰는 코드 품질은 확실히 아니다'라고 말씀하실 수 있을 겁니다. 저는 모든 것을 public으로 만들었고, 이름을 재사용하기 위해 new private를 사용했습니다. 밑줄(_)도 있습니다. 네, 여기에는 매우 이상한 코드가 작성되어 있는데, 이것 또한 매우 중요한 지점입니다. 제가 도구를 만들면서 말했듯이 개선 과정이 있다는 것입니다. 여러분이 쓰는 것은 절대 고정된 것이 아닙니다. 다시 이 그래프로 돌아가서, 여러분은 그것을 만들고, 무엇이 작동하는지 배우고, 추출하고, 다듬고, 개선한 다음, 반복적으로 재사용합니다. 이것이 2013년경 제가 시작했던 코드이며 기술적으로는 작동했지만, 아주 좋지는 않았고 사용하기 쉽지도 않았습니다. 그래서 수년 동안 이 클래스를 계속해서 다듬고, 재사용하고, 개선해 왔습니다.
그리고 현재 이것은 실제로 제 도구 상자(toolkit)에 있는 도구 중 하나입니다. 그리고 이것은 지난 15년 동안 저의 영상, 제가 만든 게임, 제가 진행한 튜토리얼 등 정말 많은 다른 것들에 사용해 온 도구입니다. 그리고 세월이 흐르면서 코드를 확실히 많이 다듬었습니다. 그래서 이제는 적절한 네임스페이스(namespace) 안에 있고, 적절한 설명도 갖추고 있으며, 사용하기 매우 쉽도록 모던 비헤이비어 훅(behavior hook)을 가지고 있습니다. 그런 다음 초기화와 수많은 다른 것들을 자동으로 처리합니다. 따라서 다시 말해, 끊임없는 반복과 지속적인 개선, 그리고 가장 중요하게는 지속적인 재사용을 통해 매번 같은 코드를 다시 작성할 필요가 없습니다. 그래서 저만의 유틸리티(utilities)는 엄청나게 가치 있는 것입니다. 그리고 이것이 제가 이 전체 영상을 만드는 이유입니다. 여러분 스스로도 자신만의 유틸리티를 만들도록 장려하기 위해서입니다. 저는 2018년 유튜브 채널을 시작한 후에도 계속 같은 일을 해왔습니다. 제가 가장 첫 번째 영상인 '건강 시스템 만들기(How to Make a Health System)'를 만들었을 때, 이 영상은 8년 전에 나왔습니다. 이 영상의 설명란에 '프로젝트 파일 및 유틸리티 받기(Get the Project Files and Utilities)'를 넣도록 신경 썼습니다. 따라서 채널 시작 첫날부터 저는 좋은 유틸리티 세트를 갖는 것이 얼마나 중요한지에 대해 끊임없이 이야기해 왔습니다. 이것은 엄청난 양의 작업을 절약해 줍니다. 그리고 세월이 흐르면서 저는 수많은 튜토리얼을 만들었습니다. 그리드 빌딩 시스템(grid building system)을 만들었고, 안전 시스템(safe system)도 만들었습니다. 다시 말해, 함수 타이머 클래스(Function Timer class)는 실제로 그에 대한 튜토리얼을 만들었습니다. 마우스 위치를 가져오는 방법이나 툴팁(tooltip)을 만드는 방법 등에 대한 함수도 만들었습니다. 그리고 이 튜토리얼들 이후의 많은 영상들에서는 저는 기본적으로 전체 것을 처음부터 다시 작성하는 대신, 그 코드를 재사용했습니다. 그래서 제가 유틸리티에 걸쳐 10년 이상을 투자하여 재구축하고 추가했기 때문에, 새로운 프로젝트를 시작할 때마다 저는 실제로 완전히 제로(zero)에서 시작하지 않습니다. 시작할 때 이미 저를 도울 수 있는 많은 것들을 가지고 있습니다. 다시 말해, 이 게임을 정말 독특하게 만드는 실제 부분에만 집중할 수 있게 해줍니다.
그리고 작년에는 실제로 제가 수십 년 전에 작성했던 유틸리티들을 다시 가져왔습니다. 그 모든 스튜럴(suturals), 그 모든 것들을 다 뜯어고쳐서, 아주 사용하기 쉽게 만들었고, 저의 공식 CodeMonkeyToolget 에셋을 만들었습니다. 작년에 이걸 출판했고, 실제로 지금도 또 업데이트를 해서 더 많은 도구와 요소를 추가했습니다. 현재 Unity의 가을 세일 기간 동안 50% 할인 중입니다. 이것은 게임을 더 좋고 빠르게 만드는 데 도움을 주는 정말 멋진 도구 및 요소 모음집입니다. 예를 들어, 다시 말하지만, 저장 시스템(save system)을 처음부터 구축할 필요 없이, 그냥 이걸 재사용할 수 있습니다. 메인 메뉴가 필요하면 이걸 사용하면 됩니다. 또는 마우스 위치를 가져오는 것, 2D든 3D든 상관없이요. 이것은 제가 아주 오래전에 직접 작성한 것이라, 마우스 위치가 필요할 때마다 정말 이 도구를 재사용합니다. 아니면 플레이어에게 어떤 종류의 데이터를 입력받아야 할 때도 마찬가지입니다. 다시 말하지만, 몇 년 전에 만들었던 이 창을 그냥 재사용합니다. 만약 플레이어에게 질문하고 싶다면, 또 제 질문 대화 상자(question dialog)를 사용합니다. 그리드 시스템이 필요하거나, 턴제 전략 게임 같은 것을 만들고 있다면, 여기 보세요. 그냥 제 그리드 시스템을 사용하면 됩니다. 프로토타입을 만들면서 그래픽 설정이 필요한 경우도 있고, 이 프리팹(prefab)을 드롭하기만 하면 끝입니다. 그리고 물론, 제가 말 그대로 10년 넘게 작성한 함수 타이머(function timer)도 여기 있습니다. 그래서 이것을 수많은 다른 도구 및 요소들과 함께 사용하면 됩니다. 말씀드렸듯이, 현재 Unity의 세일 기간 동안 50% 할인 중이니, 게임을 더 좋고 빠르게 만들고 싶다면 설명란의 링크에서 확인해 보세요. 시간을 절약하고 싶다면, 제 툴킷(toolkit)을 구매하거나 아니면 직접 유틸리티를 구축하고 다듬는 데 시간을 좀 쓰는 것을 강력히 권장합니다. 다시 기억하세요, 이것이 목표입니다. 지루한 인프라만 만드는 데 이 모든 시간을 쓰고 싶지 않습니다. 아닙니다, 실제 게임을 만드는 데 그 모든 시간을 써야 합니다.
그리고 시간의 관점에서 볼 때, 게임을 취미가 아닌 생계 수단으로 만들려고 노력하는 분들에게는 이것 또한 매우 중요한 개념입니다. 즉, 게임 제작에 더 오래 시간을 쓸수록 실제로는 비용이 더 많이 들게 된다는 것입니다. 물론 여러분의 시간은 가치가 있기 때문이죠. 따라서 만약 여러분의 유틸리티 덕분에 12개월 대신 8개월 만에 게임을 만들 수 있다면, 본질적으로 비용이 낮아진 것이고, 이는 손익분기점(break-even points)이 낮아짐을 의미합니다. 그리하여 성공적인 히트작을 실제로 만들 기회가 더 많아지는 것입니다. 따라서 자신만의 유틸리티를 만드는 것은 정말 멋집니다. 첫째, 게임 제작에 실제로 도움이 되는 부분에 집중할 수 있도록 도와주고, 둘째, 효율성을 높여주어 결과적으로 더 수익성 높은 게임을 만들게 해주기 때문입니다. 그리하여 여러분이 오랫동안 계속해서 게임을 만들 수 있게 해줍니다.