모비릭스 게임 개발자, 백승열입니다
저는 한예종 디자인과에서 2015년 취미로 개발을 시작하였고. 2022년 우연한 기회를 얻어 정규직 개발자로 일하게 되었습니다. 현재는 12명 규모의 프로젝트팀에서 메인 개발자 포지션으로 다른 2명의 개발자와 함께 일하고 있습니다. 거창한 제목이지만, 이 글은 어떻게 개발에 재미를 붙일 수 있었는지를 가볍게 공유하기 위해 작성하였습니다. 다소 개인적인 경험에 기반하고 있으므로 "저 사람은 이렇게 개발에 입문했구나" 정도로 봐주시길 바랍니다.
"게임 개발, 왜 하나요?"
본질적으로 개발은 재밌습니다. 농담이 아니라 실제로 개발은 도파민 친화적입니다. 가령 뽑기를 생각해 봅시다. 소환 버튼을 누르다 픽업 캐릭터를 얻었을 때 등줄기를 타고 흐르는 쾌감을 떠올려 봅시다. 수집 게임을 해본 적 없다면, 유사한 다른 컨텐츠를 떠올려 보아도 좋습니다. 왜 쾌감이 느껴질까요? 우리의 기대가 확률적으로 충족되었기 때문입니다. 좌절될 가능성이 있는 기대감이 충족되면 사람은 도파민을 느낍니다. 개발도 비슷합니다. 실행 버튼을 누르기 전 우리는 우리가 원하는 상태를 구체적으로 기대합니다. 그리고 버튼을 누르면 좌절되기도 하고 달성되기도 합니다. 개발을 하면 이 기대-충족 보상 사이클을 한 시간에도 몇 번씩 상당히 자주 느끼게 됩니다. 그리고 결국 원하는 것을 해내면 도파민에 취할 수 있죠. 개발은 재밌습니다.
"디자이너는 꼭 개발을 해야 되나요?"
종종 "개발 공부를 하면, 컴퓨터의 원리를 알게 되니, 그 지식을 바탕으로 앱이나 시스템 디자인을 더 잘하게 되겠죠?" 하는 기대를 마주합니다. 저도 처음 개발 공부를 시작했을 때, 그런 시너지를 기대하기도 했고요. 근데 겪어보고 나니 개발에서 얻어진 지식이 디자인에 직접적인 도움을 주지는 않았습니다. 생각해 보면 당연한 일입니다. 기타를 배운다고 그림 실력이 늘지 않는 것과 같습니다. 개발과 디자인은 별개의 스킬 셋이므로 개발을 배우면 개발할 줄 아는 사람이 될 뿐 디자인 능력이 같이 성장하는 것은 아니었습니다. 그렇기 때문에, 의무감에 무리하면서까지 개발을 배우려 하거나, 개발을 잘 모른다는 이유로 뒤쳐 진다거나 당연히 해야 하는 것을 안 하고 있다고 생각하는 등의 죄책감을 느끼지 않으셔도 됩니다.
개발을 하면 좋아지는 것들
"그렇다면 디자이너는 개발을 좀 배워봐야 아무 쓸모 없는 걸까?"하면 그렇지는 않습니다. 개발 공부 끝에 디자인 100 개발 100 도합 200의 맨-파워를 가진 사람이 되는 건 아니지만, 개발은 배우는 것 그 자체로 배우는 이에게 소소한 이점을 제공합니다. 아래는 제가 개발을 배우면서 느낀 이점들입니다.
- 도파민 원천이 생김
개인적으로 느꼈던 디자인은 도파민보다는 엔돌핀에 조금 더 가까운 행위였다고 생각합니다. 정신없이 몰입하기는 좋지만, 한 작업 단위 내에서 기대와 충족(피드백)은 작업 말미에 주로 발생하기 때문에 좀처럼 도파민을 느끼기 어렵습니다. 이런 상황에서, 시도마다 즉각적으로 기대와 충족을 느낄 수 있는 개발은 좋은 도파민 원천이 될 수 있습니다. 인생이 무료하고 문득 뭘 해도 공허한 느낌이 든다면 개발이 필요한 것일 수도 있습니다.
- 토이프로젝트 문턱이 낮아짐
조금이라도 구현을 할 수 있게 되면, 토이프로젝트 문턱이 말도 안 될 정도로 낮아집니다. "여차하면 내가 머리 부딪혀가며 만들 수 있다"는 감각은 프로젝트 시작 전 아주 큰 용기가 됩니다. 만약 개발 팀원이 이미 있다고 해도 이점이 없는 것이 아닙니다. 상대방이 이탈해도 내가 끝까지 끌고 갈 수 있다는 것은 프로젝트 완결 여부를 상당히 많이 좌우합니다.
- 자잘한 수요를 많이 잡을 수 있음
세상에는 생각보다 개발 수요가 많이 있으며 그중에는 엄격한 전문성을 요구하지 않는 수요들도 많이 있습니다. 가령 학부생들이 디자인 과제 파이널 프로덕트에 실제로 작동하는 프로덕트를 한 스푼 넣고 싶어 하는 경우 등 말입니다. 이런 수요들을 잘 잡을 수 있다면 미묘하지만 확실하게 삶이 윤택해집니다.
"어떻게 시작하나요?"
학습에 대한 별다른 계획이 없다면, 일단 유니티를 설치하는 것을 추천드립니다. “유니티는 게임엔진 아닌가요?" 하는 의문이 들 수 있습니다. 그리고 맞습니다. 유니티는 게임 엔진입니다. 하지만 그럼에도 유니티를 추천드리는 이유는 다음과 같습니다.
- 인터페이스를 눈으로 확인할 수 있다.
포토샵처럼 이것저것 눌러보면서 친숙해질 수 있기 때문에 생각보다 중요한 특성입니다. 특히 인디자인이나 피그마 같은 디자인 툴을 다뤄본 적이 있다면, 유니티 씬 정도는 클릭해 보면서 금방 다룰 수 있습니다.
- 재생 버튼을 클릭하면 실행된다.
사실 이전 문단에서 서술한 개발의 재미를 느끼려면 전제조건이 있습니다, 컴파일과 빌드를 할 줄 알아야 한다는 것인데, 지식이 0인 사람은 자세한 영문도 모른 채 “컴파일”을 하기 위해 가이드를 무작정 따라 하며 고통스러운 시간을 보내게 되고, 그러다가 흥미를 잃게 됩니다. 반면 유니티에서 사용자에게 필요한 것은 오직 재생 버튼을 식별할 수 있는 인지능력과 손가락만 있으면 됩니다. 진지하게 개발을 지속하겠다면, 언젠가는 저 두 개에 대한 지식도 갖춰야 하겠지만, 입문 단계에서는 자잘한 것은 유니티에 맡기고 개발이 주는 즐거움에 집중해도 좋다고 생각합니다.
- 다양한 플랫폼을 타깃으로 빌드하기가 비교적 쉽다.
효율적이지는 않지만 윈도우 & 웹 & 모바일 모두 대응할 수 있기 때문에, 효용을 느낄 수 있는 기회가 그만큼 많아집니다.
유니티 이외에 웹으로 입문하는 경우도 있고. 저도 입문할 때 웹과 유니티를 병행했는데, 개인적으로 아무것도 모르는 사람이 개발을 처음 시작하기에는 상술한 점에 의해 유니티가 조금 더 낫다고 생각합니다.
학습을 위한 조언
이제 유니티를 설치했다면, 뭐든 시작하시면 됩니다. (막막하다면 학부 때 과제용으로 기획해 둔 앱이나 시스템 프로토타입을 만들어보는걸 추천드립니다.) 일단 유니티의 창과 버튼들을 클릭해 보며 이걸 누르면 무슨 일이 일어나는지 파악합니다. 겁먹지 않으셔도 됩니다! Ctrl + z를 누르면 대부분의 상태를 되돌릴 수 있으며, 되돌아가지 않는 상태는 새 프로젝트를 만들어 리셋하면 됩니다. 중간에 "이게 뭐지?" 싶은 것들은 “Unity + [이름]”으로 구글에 검색하거나 AI들에게 물어보면 됩니다.
충분히 파악하셨다면, 'Hierarchy'에서 우클릭 후 우클릭 메뉴에서 UI 하위 메뉴의 컴포넌트들을 생성할 수 있다는 것을 알게 되셨을 겁니다. 먼저 코드를 짜기 전에 컴포넌트들을 생성하여 씬을 채워주세요. 씬을 다 채웠다면, 액션을 주고 싶은 오브젝트를 마우스와 Inspector의 값들을 이용해 수동으로 액션을 흉내 내보세요. 가령 “어떤 팝업창이 우 > 좌로 미끄러지듯 나타났으면 좋겠다”를 원한다면, 해당 팝업창을 마우스로 클릭하고, 직접 오른쪽에서 왼쪽으로 움직여보는 겁니다. 그러면서 'Inspector'에서 무엇이 바뀌는지 관찰해 보세요.
변화하는 부분을 포착했다면, 그것을 어떻게 코드로 변화시킬 수 있는지를 알아내면 됩니다. 우측에서 좌측으로 이동했으니 아마 Transform의 Position 값이 바뀌었을 겁니다. 구글에 Unity + Transform + Position + Move 등의 키워드를 조합해 검색하거나, 혹은 AI에게 방금 자신이 발견한 것을 상세하게 설명하고 어떻게 해야 하는지 물어보세요. 성공했다면, 그다음 스텝으로 넘어가면 됩니다.
그리고 하다 보면 “뭔가 잘 안되는” 상황을 분명히 만나게 될 겁니다. 그때는 출력되는 붉은색의 "Error"와 뒤따라오는 문장들을 를 주의 깊게 읽어보세요. 이것은 혼내기 위해서가 아니라 여러분을 돕기 위해 존재합니다. 읽다보면 에러의 종류, 어디에서 에러가 발생했는지, 뭘 하다가 발생했는지 등에 대한 정보를 알게되실 겁니다. 그러면 그것을 기반으로 구글과 AI에게 도움을 청하시면 됩니다. 망가진 것도 아니고 큰일 난 것도 아니니까 차근차근 살펴보세요! 대부분은 해결하실 수 있는 문제입니다.
그 외 자잘한 첨언
이하는 미리 알았다면 좋았을 내용들입니다.
- 자신감을 갖자
혼자서 학습하다 보면 이렇게 쓰는 게 맞을까? 이런 방식이 옳을까? 하는 의문과 끊임없이 싸우게 되는 것 같습니다. 하지만 이 의문은 그 상황에서 혼자서 고민한다고 해결되는 의문이 아닙니다. 여러분은 무용한 곳에 쓸데없는 시간을 낭비하지 마시고, 일단 익숙해지는데 집중하셨으면 좋겠습니다. 어느 정도 경험이 쌓여야 받아들일 수 있는 지식이 있고. 개발을 배우는 초반에는 절대적인 시간 투자가 중요합니다.
- 버전 관리를 하자
github에 프로젝트를 업로드하고, 주기적으로 버전 관리를 하면 좋습니다. 처음 프로젝트를 진행하면서 이것저것 건들이다 보면, 무엇을 건드린 건지 모르겠는데 프로젝트가 망가지는 경우가 종종 발생합니다. 경험이 좀 쌓이면, 본인이 한 일이었고 충분히 돌이킬 수 있다는 것을 알게 되지만 그렇지 않을 때에는 상당한 공포를 불러 일으킵니다. 버전 관리는 그런 상황에서 내가 명시적으로 기록해 둔 곳까지 전부 돌아갈 수 있도록 해주는 최소한의 안전장치 역할을 해줍니다.
- 다시 만들어보자
조금 정체된 것 같다는 느낌이 들면, 이미 완성해서 치워둔 프로젝트를 다시 읽어보고, 가능하다면 다시 만들어보는 것을 추천드립니다.
프로그래밍은 마법이 아닙니다. 심지어 최근에 나오는 것 일수록 더 마법이 아닙니다. 누군가의 말마따나 "다 사람보고 쓰라고 나온 것"이며 이 글을 읽는 당신도 사람이기 때문에 사용할 수 있습니다. 진짜로 개발은 꽤 괜찮은 취미가 될 수 있습니다! 한번 찍어서 먹어보셨으면 좋겠어요. 화이팅입니다!
모비릭스 게임 개발자, 백승열입니다
저는 한예종 디자인과에서 2015년 취미로 개발을 시작하였고. 2022년 우연한 기회를 얻어 정규직 개발자로 일하게 되었습니다. 현재는 12명 규모의 프로젝트팀에서 메인 개발자 포지션으로 다른 2명의 개발자와 함께 일하고 있습니다. 거창한 제목이지만, 이 글은 어떻게 개발에 재미를 붙일 수 있었는지를 가볍게 공유하기 위해 작성하였습니다. 다소 개인적인 경험에 기반하고 있으므로 "저 사람은 이렇게 개발에 입문했구나" 정도로 봐주시길 바랍니다.
"게임 개발, 왜 하나요?"
본질적으로 개발은 재밌습니다. 농담이 아니라 실제로 개발은 도파민 친화적입니다. 가령 뽑기를 생각해 봅시다. 소환 버튼을 누르다 픽업 캐릭터를 얻었을 때 등줄기를 타고 흐르는 쾌감을 떠올려 봅시다. 수집 게임을 해본 적 없다면, 유사한 다른 컨텐츠를 떠올려 보아도 좋습니다. 왜 쾌감이 느껴질까요? 우리의 기대가 확률적으로 충족되었기 때문입니다. 좌절될 가능성이 있는 기대감이 충족되면 사람은 도파민을 느낍니다. 개발도 비슷합니다. 실행 버튼을 누르기 전 우리는 우리가 원하는 상태를 구체적으로 기대합니다. 그리고 버튼을 누르면 좌절되기도 하고 달성되기도 합니다. 개발을 하면 이 기대-충족 보상 사이클을 한 시간에도 몇 번씩 상당히 자주 느끼게 됩니다. 그리고 결국 원하는 것을 해내면 도파민에 취할 수 있죠. 개발은 재밌습니다.
"디자이너는 꼭 개발을 해야 되나요?"
종종 "개발 공부를 하면, 컴퓨터의 원리를 알게 되니, 그 지식을 바탕으로 앱이나 시스템 디자인을 더 잘하게 되겠죠?" 하는 기대를 마주합니다. 저도 처음 개발 공부를 시작했을 때, 그런 시너지를 기대하기도 했고요. 근데 겪어보고 나니 개발에서 얻어진 지식이 디자인에 직접적인 도움을 주지는 않았습니다. 생각해 보면 당연한 일입니다. 기타를 배운다고 그림 실력이 늘지 않는 것과 같습니다. 개발과 디자인은 별개의 스킬 셋이므로 개발을 배우면 개발할 줄 아는 사람이 될 뿐 디자인 능력이 같이 성장하는 것은 아니었습니다. 그렇기 때문에, 의무감에 무리하면서까지 개발을 배우려 하거나, 개발을 잘 모른다는 이유로 뒤쳐 진다거나 당연히 해야 하는 것을 안 하고 있다고 생각하는 등의 죄책감을 느끼지 않으셔도 됩니다.
개발을 하면 좋아지는 것들
"그렇다면 디자이너는 개발을 좀 배워봐야 아무 쓸모 없는 걸까?"하면 그렇지는 않습니다. 개발 공부 끝에 디자인 100 개발 100 도합 200의 맨-파워를 가진 사람이 되는 건 아니지만, 개발은 배우는 것 그 자체로 배우는 이에게 소소한 이점을 제공합니다. 아래는 제가 개발을 배우면서 느낀 이점들입니다.
개인적으로 느꼈던 디자인은 도파민보다는 엔돌핀에 조금 더 가까운 행위였다고 생각합니다. 정신없이 몰입하기는 좋지만, 한 작업 단위 내에서 기대와 충족(피드백)은 작업 말미에 주로 발생하기 때문에 좀처럼 도파민을 느끼기 어렵습니다. 이런 상황에서, 시도마다 즉각적으로 기대와 충족을 느낄 수 있는 개발은 좋은 도파민 원천이 될 수 있습니다. 인생이 무료하고 문득 뭘 해도 공허한 느낌이 든다면 개발이 필요한 것일 수도 있습니다.
조금이라도 구현을 할 수 있게 되면, 토이프로젝트 문턱이 말도 안 될 정도로 낮아집니다. "여차하면 내가 머리 부딪혀가며 만들 수 있다"는 감각은 프로젝트 시작 전 아주 큰 용기가 됩니다. 만약 개발 팀원이 이미 있다고 해도 이점이 없는 것이 아닙니다. 상대방이 이탈해도 내가 끝까지 끌고 갈 수 있다는 것은 프로젝트 완결 여부를 상당히 많이 좌우합니다.
세상에는 생각보다 개발 수요가 많이 있으며 그중에는 엄격한 전문성을 요구하지 않는 수요들도 많이 있습니다. 가령 학부생들이 디자인 과제 파이널 프로덕트에 실제로 작동하는 프로덕트를 한 스푼 넣고 싶어 하는 경우 등 말입니다. 이런 수요들을 잘 잡을 수 있다면 미묘하지만 확실하게 삶이 윤택해집니다.
"어떻게 시작하나요?"
학습에 대한 별다른 계획이 없다면, 일단 유니티를 설치하는 것을 추천드립니다. “유니티는 게임엔진 아닌가요?" 하는 의문이 들 수 있습니다. 그리고 맞습니다. 유니티는 게임 엔진입니다. 하지만 그럼에도 유니티를 추천드리는 이유는 다음과 같습니다.
포토샵처럼 이것저것 눌러보면서 친숙해질 수 있기 때문에 생각보다 중요한 특성입니다. 특히 인디자인이나 피그마 같은 디자인 툴을 다뤄본 적이 있다면, 유니티 씬 정도는 클릭해 보면서 금방 다룰 수 있습니다.
사실 이전 문단에서 서술한 개발의 재미를 느끼려면 전제조건이 있습니다, 컴파일과 빌드를 할 줄 알아야 한다는 것인데, 지식이 0인 사람은 자세한 영문도 모른 채 “컴파일”을 하기 위해 가이드를 무작정 따라 하며 고통스러운 시간을 보내게 되고, 그러다가 흥미를 잃게 됩니다. 반면 유니티에서 사용자에게 필요한 것은 오직 재생 버튼을 식별할 수 있는 인지능력과 손가락만 있으면 됩니다. 진지하게 개발을 지속하겠다면, 언젠가는 저 두 개에 대한 지식도 갖춰야 하겠지만, 입문 단계에서는 자잘한 것은 유니티에 맡기고 개발이 주는 즐거움에 집중해도 좋다고 생각합니다.
효율적이지는 않지만 윈도우 & 웹 & 모바일 모두 대응할 수 있기 때문에, 효용을 느낄 수 있는 기회가 그만큼 많아집니다.
유니티 이외에 웹으로 입문하는 경우도 있고. 저도 입문할 때 웹과 유니티를 병행했는데, 개인적으로 아무것도 모르는 사람이 개발을 처음 시작하기에는 상술한 점에 의해 유니티가 조금 더 낫다고 생각합니다.
학습을 위한 조언
이제 유니티를 설치했다면, 뭐든 시작하시면 됩니다. (막막하다면 학부 때 과제용으로 기획해 둔 앱이나 시스템 프로토타입을 만들어보는걸 추천드립니다.) 일단 유니티의 창과 버튼들을 클릭해 보며 이걸 누르면 무슨 일이 일어나는지 파악합니다. 겁먹지 않으셔도 됩니다! Ctrl + z를 누르면 대부분의 상태를 되돌릴 수 있으며, 되돌아가지 않는 상태는 새 프로젝트를 만들어 리셋하면 됩니다. 중간에 "이게 뭐지?" 싶은 것들은 “Unity + [이름]”으로 구글에 검색하거나 AI들에게 물어보면 됩니다.
충분히 파악하셨다면, 'Hierarchy'에서 우클릭 후 우클릭 메뉴에서 UI 하위 메뉴의 컴포넌트들을 생성할 수 있다는 것을 알게 되셨을 겁니다. 먼저 코드를 짜기 전에 컴포넌트들을 생성하여 씬을 채워주세요. 씬을 다 채웠다면, 액션을 주고 싶은 오브젝트를 마우스와 Inspector의 값들을 이용해 수동으로 액션을 흉내 내보세요. 가령 “어떤 팝업창이 우 > 좌로 미끄러지듯 나타났으면 좋겠다”를 원한다면, 해당 팝업창을 마우스로 클릭하고, 직접 오른쪽에서 왼쪽으로 움직여보는 겁니다. 그러면서 'Inspector'에서 무엇이 바뀌는지 관찰해 보세요.
변화하는 부분을 포착했다면, 그것을 어떻게 코드로 변화시킬 수 있는지를 알아내면 됩니다. 우측에서 좌측으로 이동했으니 아마 Transform의 Position 값이 바뀌었을 겁니다. 구글에 Unity + Transform + Position + Move 등의 키워드를 조합해 검색하거나, 혹은 AI에게 방금 자신이 발견한 것을 상세하게 설명하고 어떻게 해야 하는지 물어보세요. 성공했다면, 그다음 스텝으로 넘어가면 됩니다.
그리고 하다 보면 “뭔가 잘 안되는” 상황을 분명히 만나게 될 겁니다. 그때는 출력되는 붉은색의 "Error"와 뒤따라오는 문장들을 를 주의 깊게 읽어보세요. 이것은 혼내기 위해서가 아니라 여러분을 돕기 위해 존재합니다. 읽다보면 에러의 종류, 어디에서 에러가 발생했는지, 뭘 하다가 발생했는지 등에 대한 정보를 알게되실 겁니다. 그러면 그것을 기반으로 구글과 AI에게 도움을 청하시면 됩니다. 망가진 것도 아니고 큰일 난 것도 아니니까 차근차근 살펴보세요! 대부분은 해결하실 수 있는 문제입니다.
그 외 자잘한 첨언
이하는 미리 알았다면 좋았을 내용들입니다.
혼자서 학습하다 보면 이렇게 쓰는 게 맞을까? 이런 방식이 옳을까? 하는 의문과 끊임없이 싸우게 되는 것 같습니다. 하지만 이 의문은 그 상황에서 혼자서 고민한다고 해결되는 의문이 아닙니다. 여러분은 무용한 곳에 쓸데없는 시간을 낭비하지 마시고, 일단 익숙해지는데 집중하셨으면 좋겠습니다. 어느 정도 경험이 쌓여야 받아들일 수 있는 지식이 있고. 개발을 배우는 초반에는 절대적인 시간 투자가 중요합니다.
github에 프로젝트를 업로드하고, 주기적으로 버전 관리를 하면 좋습니다. 처음 프로젝트를 진행하면서 이것저것 건들이다 보면, 무엇을 건드린 건지 모르겠는데 프로젝트가 망가지는 경우가 종종 발생합니다. 경험이 좀 쌓이면, 본인이 한 일이었고 충분히 돌이킬 수 있다는 것을 알게 되지만 그렇지 않을 때에는 상당한 공포를 불러 일으킵니다. 버전 관리는 그런 상황에서 내가 명시적으로 기록해 둔 곳까지 전부 돌아갈 수 있도록 해주는 최소한의 안전장치 역할을 해줍니다.
조금 정체된 것 같다는 느낌이 들면, 이미 완성해서 치워둔 프로젝트를 다시 읽어보고, 가능하다면 다시 만들어보는 것을 추천드립니다.
Don't Panic!
프로그래밍은 마법이 아닙니다. 심지어 최근에 나오는 것 일수록 더 마법이 아닙니다. 누군가의 말마따나 "다 사람보고 쓰라고 나온 것"이며 이 글을 읽는 당신도 사람이기 때문에 사용할 수 있습니다. 진짜로 개발은 꽤 괜찮은 취미가 될 수 있습니다! 한번 찍어서 먹어보셨으면 좋겠어요. 화이팅입니다!