개발자로 입문하는 데 현실적인 방법을 찾아보던 중, 책을 사기 위해 들렀던 서점에서 우연히 눈에 들어온 책이 있었다.
커리어 스킬, 완벽한 개발자 인생 로드맵
이름만 봐도 딱 내가 찾던 책이 아닌가 싶어서 목차를 둘러봤을 때는 내가 생각하던 것보다 훨씬 방대한 양의 내용이 담겨 있었다. 솔직히 선뜻 읽을 용기가 사라질 정도로, 어려운 길인건 알지만 이 정도로 하드코어한 직업이던가...
그래서 나 뿐만 아니라 비슷한 고민을 하고 있을 많은 사람들을 위해서 내용을 간략하게나마 정리하고자 한다.
이 책의 방대한 내용은 입문자를 위한 파트, 이미 개발을 하고 있으며 취업을 준비하고 있는 예비 개발자들을 위한 파트, 이미 취직해서 자신의 커리어를 더 성장시켜나나기를 원하는 현직 개발자들을 위한 파트 등, 여러 부분으로 분류되어있다. 그리고 심지어 그 중에서 필요한 부분만 골라 본다고 해서 그 이전 장이나 다음 장이 이해가 가지 않는다던가 하는 일은 거의 없다. 필요한 부분만 골라서 읽어볼 수 있는 백과사전같은 느낌의 구성이라는 느낌도 든다.
물론 필자는 우선 입문하기 위한 길을 제대로 보기 위해서 이 책을 읽었고, 따라서 필자가 읽은 부분에 한해서 정리를 할 할 예정이다. 이후 필자의 수준이 더 올라서 그 뒷 내용이 필요할 경우, 다시 읽고 그 부분에 대한 내용을 추가할 예정이다.
이 책의 저자는 게임 개발자는 아니지만, 게임 개발자의 시점으로 조금 더 각색해서, 많은 게임 개발 꿈나무들에게 좋은 참고자료가 되었으면 하는 생각으로 글을 적는다.
1. 개발자로 입문하기
이 단계의 핵심은 어떻게든, 아무 것도 몰라도 일단 만져보는 것이다.
저자는 여기서 MUD(Multi-User Dungeon)이라는 게임의 소스 코드를 다운 받아서 모드 개발을 시도해봤다고 한다.
말은 거창해보이지만, 처음 소스 코드를 봤을 때, 본인이 뭘 보고 있는지도 몰랐고, 이것저것 찔러보면서 이건 원하는대로 되고, 저건 건들면 아예 작동도 안하는 등 여러 문제를 겪었다고 한다. 하지만 일주일쯤 지나니 저자가 만든 '기능'이 들어간 버전의 MUD가 어찌저찌 만들어 졌다고 한다. 그게 저자의 코딩 입문이였다.
이 사례처럼 필자 주변의 사람들은 다양한 방식으로 개발에 입문했다. 물론 게임 개발을 하고 있지 않은 사람이 더 많지만, 참고만 하길 바란다.
고등학교 때 친구들은 게임 개발을 하기 위해 프리바람을 만들자고 우리를 설득했다. 그리고 어디서 구했는지 모를 바람의 나라의 소스코드를 가지고 레이싱 모드를 추가하겠다며 맵을 새로 만들고, 이래저래 깨작깨작 만지기 시작했다. 아무 것도 몰랐지만 타일 파일 중에 트랙으로 쓸만한 걸 떼와서 새로운 맵에 찍어대며 경기장을 만들고, 그 맵으로 이동하기 위한 포탈을 만들고, 그 안에서만 작동하는 특수한 이동 규칙을 짜느라 학교에서 대부분의 시간을 쏟았다.
결국 그럴듯해보이는 것이 만들어지고는 있었지만, 끝내 만들어져서 배포되는 일은 없었다. 둘 사이의 사정이 있었는지, 생각보다 레이싱 모드가 재미 없었던지, 어찌됐든 간에 필자는 당시 게을러서 개발에 제대로 참가하진 않았지만 당시 그 프리바람을 만들겠다며 매달렸던 친구들은 지금도 개발자로서 어엿하게 1인분을 하고 있다.
정말 입문으로는 좋은 사례 아니였을까? 물론 프리바람이나 프리메이플같은 건 엄밀히 따지면 불법이니 하면 안된다. 만약 친구들이 정말 괜찮게 만들어서 운영이라도 했다간 필자는 이 글을 적지도 못했을 것이다. 프리서버 운영은 정말 불법이니 필자가 참고하라고 적은 것을 실천해서 앞길에 문제가 생기지 않길 바란다.
지금에서는 유니티 마켓플레이스나 언리얼 마켓플레이스에서도 괜찮은 수준의 RPG 튜토리얼 팩이나 여러 장르의 게임팩을 무료로 배포하고 있으니 그런 것들을 받아서 프리서버처럼 만들어보는 정도가 재밌게 시작할 수 있는 방법이 아닐까 싶다. 스피드핵처럼 이동속도를 빠르게 만들어본다던가, 쿨타임이 거의 0초에 가깝게 설정되서 무한 스킬을 사용한다던가 하는 등 말이다. 생각보다 재미있는 입문 방법이니 아직 입문하지 않았다면 한번쯤은 시도해보는 것을 추천한다.
2. 소프트웨어 개발자?
소프트웨어 개발자는 생각보다 쉬우면서 생각보다 어려운 직업이다. 단순히 프로그래밍 '만' 하면 되는 직업이 아니라는 것이다.
대부분의 소프트웨어 개발 프로젝트는 수동 프로세스를 자동화하거나 수동으로 하기 너무 어려운 무언가를 자동화할 새로운 방법을 만들어내는 것이다.
그 중 게임 개발은 '수동으로 하기 너무 어려운 무언가를 자동화하는' 작업에 가깝다.
RPG 게임을 수동으로 한다고 가정해보자. 우리는 포켓몬스터같은 턴제 전투 형태의 RPG를 예시로 잡을 것이다.
자, 나의 포켓몬 피카츄와 야생의 포켓몬 꼬렛이 조우했다.
둘의 체력은 각각 10이며, 둘 다 공격 시 1~6 사이의 데미지를 랜덤하게 입힌다.
나의 턴, 내 피카츄에게 공격 명령을 내렸다. 주사위를 굴린다. 값이 4가 나왔다.
야생 꼬렛에게 4의 데미지, 꼬렛의 체력은 6이 되었다.
상대방의 턴, 꼬렛은 피카츄에게 공격을 한다. 주사위를 굴린다. 값이 3이 나왔다.
나의 피카츄는 3의 데미지를 받았다. 피카츄의 체력은 7이 남았다.
나의 턴, 내 피카츄에게 공격 명령을 내렸다. 주사위를 굴린다. 값이 6이 나왔다.
야생 꼬렛에게 6의 데미지, 꼬렛의 체력은 0이 되었다.
승리!
굉장히 단순한 방식이지 않은가?
우리가 알고 있는 포켓몬스터 게임은, 이보다 훨씬 복잡한 형태로 구성되어있다. 저 기본적인 형태에 스피드 시스템을 넣는다면, 서로의 스피드를 비교해서 선공권을 부여한다던가, 일정 확률로 회피할 확률을 부여한다던가 할 수 있을 것이다. 공격력 시스템을 넣어서 공격력 수치가 상승하면 1~6에서 2~7로 바뀐다던지 하는 식으로 공격력 수치를 바꿀 수 있을 것이고, 치명타율 시스템을 넣어서 일정 확률로 2배의 데미지를 주게 한다던지, 여러가지 형태로 추가된 것들이 계속해서 쌓이고 쌓여서 지금의 포켓몬이 만들어진 것이라고 생각하면 된다.
그럼 전부다 덜어내고, 저 단순한 형태의 전투, 체력과 공격력(정확히는 데미지 범위)만으로 현실에서 보드 게임의 형태로 만든다면 할 수 있을까? 아마 조금 귀찮겠지만, 그래도 할 수 있을 것이다.
하지만 만약 우리가 배틀그라운드나 리그오브레전드 같은 게임을 보드 게임의 형태로(수동으로) 만들어야 한다면 만들 수 있을까? 아마 어떻게 만들어야할지 감도 제대로 잡히지 않을 것이다.
이 예시에서 말하고자 하는 것이 이런 부분이다.
수동으로 이 과정을 직접 만들어서 작동시킨다고 할 때, 어떻게 해야할 지 그 길이 보이는가?
그 길이 보이지 않는다면 당연히 코딩으로도 만들 수 없다.
소프트웨어, 혹은 게임을 개발한다는 것은 단순히 코딩을 하는 것이 아니다. 그 것을 설계하고 오류를 검증하고 제대로 작동하는지 테스트하고, 다 완료되고 나서도 추가적으로 생기는 문제에 대한 유지보수작업까지 전부 이루어지는 복합적인 과정이라는 것을 인지해야한다.
3. 문제 이해하기
앞서 말한 내용처럼, 자신이 무엇을 만드는지 이해하지 못한채 소프트웨어 코드 부터 작성하는 개발 지망생이 많다.
1단계의 '입문하기'의 내용을 시도하고 있는 것이라면 상관 없지만, 실제로 SW를 제작하고자 한다면 얘기가 달라진다.
SW 개발은 언제나 해결할 문제를 이해하는 것에서부터 시작한다. (괜히 개발자들이 알고리즘같은 것에 대해 얘기하는 것이 아니다.)
해결할 문제를 이해하기 위한 작업은 소프트웨어 방법론마다 차이가 있을 수 있지만, 본질은 어떤 방식으로든 해결할 문제를 이해하고 요구사항을 파악해야 한다는 점이다.
4. 설계하기
해결해야 하는 문제를 이해 했다면 그 문제를 코드로 어떻게 해결해야할 지 설계하는 과정이 필요하다.
이 역시 방법론에 따라 설계 과정에 차이가 있을 수 있지만, 아무리 설계가 덜 중요한 방법론이더라도 설계하는 과정은 꼭 필요하다.
5. 코드 작성하기
코드 작성은 그 자체 만으로 하나의 분과를 이룰 만큼 범위가 넓은 분야이다.
여기서 전부 다 설명할 수는 없기에 참고하면 좋을 책 두권을 추천하고 넘어가고자 한다.
1. Code Complete, 스티브 맥코넬 저자
https://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9791158390600
Code Complete 코드 컴플리트 2/E - 교보문고
더 나은 소프트웨어 구현을 위한 실무 지침서 | 프로그래밍에 대한 최고의 실무 지침서로 널리 알려진 스티브 맥코넬의 ≪CODE COMPLETE≫ 제1판은 10년이 넘는 기간 동안 개발자들이 더 나은 소프트
www.kyobobook.co.kr
2. Clean Code, 로버트 마틴 저자
https://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966260959
Clean Code(클린 코드) - 교보문고
애자일 소프트웨어 장인 정신 | 나쁜 코드도 돌아는 간다. 하지만 코드가 깨끗하지 못하면 개발 조직은 기어간다. 매년 지저분한 코드로 수많은 시간과 상당한 자원이 낭비된다. 그래야 할 이유
www.kyobobook.co.kr
우리나라에서도 번역되서 출간되었을 정도로 개발자들의 필독서로 꼽히는 책이다. 본 페이지의 '개발앞시 로드맵'은 그런 좋은 개발서, 혹은 참고 서적들이 잘 정리되어 있는 마인드맵이다. 한번 찾아 들어가서 참고해보면 좋을 것이다.
6. 테스트하고 배포하기
코드를 다 작성했다면 배포하기에 앞서 테스트가 필요하다. 물론 이도 방법론에 따라 테스트 주기도 다를 수 있지만, 어떤 방법을 채택했든 간에 최종 사용자들에게 공개하기 전 테스트를 꼭 거친다.
테스트가 끝나면 배포를 시작하는데
보통 소프트웨어의 배포는 소프트웨어를 서버에 설치하고 앱스토어의 올리는 등의 방법으로 사용자가 소프트웨어에 접근 할 수 있도록 해주는 과정을 말한다. ( 이 과정에서 소스 코드에 꼭 체크인도 이뤄져야한다. )
앞서 포켓몬스터 예시를 들었던 것으로 이 단계를 보여주자면 이런 것이다.
만약 당신이 전투시스템에 스피드 시스템을 추가했다.
서로의 스피드를 비교하고, 더 높은 사람이 먼저 공격하도록 코딩을 했다.
테스트를 해보니 같은 스피드를 가진 포켓몬이 싸우면, 공격 명령을 내리자마자 게임이 멈춰버린다!
확인해보니 스피드가 '같을 때' 어떻게 작동할지에 대해 코딩을 해두지 않았다.
그래서 스피드가 같을 때는 랜덤으로 선공권을 가져가도록 코드를 추가했다.
이런 과정이 테스트 - 수정 작업이다!
7. 코드 작성 그 이후
디버깅! 배포했다고 끝이 아니다. 테스트 단계에서 미처 발견하지 못한 버그가 쏟아져 나올 것이다.
그 버그를 수정하고 업데이트 하는 디버깅 작업이 지속적으로 이뤄져야한다.
다시 한번 포켓몬스터로 예를 들어보자면
전투 상태가 아니라 마을에 있을 때, 저장하기 위해서 일반적으로 핸드폰에 있는 취소 버튼을 누르면 메뉴 창이 나오도록 코딩해뒀다. 테스트할 때 본인의 폰에서 멀쩡히 잘 돌아가는 것을 확인했다.
배포를 진행하고 반응을 보니, 아이폰 사용자들이 저장을 할 수 없다며 1점 테러를 마구 하고 있다.
확인을 해보니 이럴수가, 아이폰 기기에는 뒤로가기 버튼이 따로 없다!
따라서 게임 내에서 뒤로가기 버튼을 통해서 메뉴를 여는 것이 아니라, 화면 구석에 x버튼을 삽입해서 해당 버튼을 터치하면 메뉴가 열리도록 수정해서 재배포를 했다.
이런 과정이라고 생각하면 된다.
8. 계획
자, 이렇게 소프트웨어가 만들어지는 과정을 살펴보았다.
그래서 정작 뭘 공부해야되고 뭘 준비해야하는지는 한마디도 안해주지 않았냐라면 할 말은 없지만, 그래도 다행인 점은 여기까지 알고서 시작한다는 것부터 대부분의 소프트웨어 개발자보다 희망차게 출발했다는 것이다.
9. 계획 준비하기
계획을 짜기 전에, 자신이 어디쯤에 위치해 있는지, 앞으로 배워야 할 것이 무엇인지 정직하게 평가하는 과정이 필요하다.
- 프로그래밍 경험이 있는가?
- 쓸 줄 아는 프로그래밍 언어가 있는가?
- 어플리케이션을 만들어본 경력이 있는가? 아니면 아주 기초 단계부터 시작해야 하는가?
- 앞에서 언급한 다른 기술에 대해서는 어떤 경험이 있는가?
- 그러한 기술 중 익혀둔 기술이 있는가?
- 데이터베이스, 소스 제어, TDD, 테스트하기, 디버깅, 소프트웨어 개발 방법론에 대해 아는게 있는가?
이러한 지표들을 체크해보며 어느 수준인지 파악한다. 그리고 자신이 어떤 분야의 개발자가 되고 싶은지도 생각해보아야한다.
특히 이 단계가 중요한 이유는 인생의 방향을 설정할 때 처음부터 충분한 시간을 들여 철저하게 자신의 생각을 점검해보는 사람은 많지 않기 때문이다.
이렇게 말해줘도 남이 도와주는 데에는 한계가 있다. 결국 정보를 줘도 실행 계획을 정리하고 실천하는 것은 당신의 몫이다.
10. 계획 세우기
성취하고자 하는 목표에서 시작해 거꾸로 되짚어 오면 계획을 세우기 편하다.
'좋은 개발자'처럼 광범위하게 설정하기 보단, 어떤 유형의 소프트웨어 개발자가 되고 싶은지 구체적인 목표를 세워야 한다.
그것이 구체적일 수록 과정이 더 쉬워진다.
비교를 해보자면 운동선수가 되고 싶어하는 사람이 좋은 예가 될 수 있겠다.
어떤 종목의 선수가 되고자하는게 아니라, 그냥 그저 운동선수를 목표로한다.
그렇다면 수영을 하든 육상을 하든 체조를 하든 스케이팅을 하든 어떤 운동에 투입되더라도 바로 경기를 뛸 수 있게 되어야하니 모든 종목의 훈련을 해야한다. 그저 목적도 없이 이런 저런 운동을 다 해야하는 것이다. 제대로 될 리가 없다.
소프트웨어 개발자라는 목표도 마찬가지다. 앱 개발자, 게임 개발자, 웹 개발자, 서버 개발자, 여러 분야로 나누고서도 또 언리얼 엔진 개발자, 유니티 엔진 개발자, cocos-2d 개발자, 그래픽스 개발자 등 그 안에서도 세부적으로 많이 나눠진다. (이 분류가 100%도 아니고 완전히 맞아 떨어지는 것도 아니다.) 그런 과정에 있어서 어떤 개발자가 될 지 정하는 과정은 꼭 필요하다.
어떤 개발자를 목표로 할 것인가? 어떤 직장에 지원할 것인가? 등
이 책은 그 모든 과정을 좀 더 수월하게 할 수 있도록 돕는데 목적을 두고 있지만, 지금 당장은 어떤 계획을 세워야 할지, 어떤 개발자가 되고 싶은지부터 생각해보자.
11. 사례 분석
저자는 이 부분에서 현실적인 Node.js 전문 개발자가 되기위한 현실적인 커리큘럼을 써뒀다.
하지만 필자는 게임 개발자를 꿈꾸는 사람으로서, 이전에 포스팅한 글을 참조해보는걸 추천드린다.
https://directorgette.tistory.com/9
이후 필자가 게임 개발자로서 정진하는 동안 잘못 작성된 내용이나 생각이 바뀐다면 구정작업을 할 예정이다. 문제나 의견이 있다면 댓글로 많은 코멘트 달아주면 감사하겠다.