결정을 서둘지 말라. 하룻밤을 자고 나면 좋은 지혜가 생긴다. - 푸시킨
p4 change -d [번호]예: p4 change -d 1000
어떤 사람은 문제를 정공법으로 공략하려고 하지 않고, 지금 당장 쉽고 편해 보이는 방법으로 해결하려고 합니다. 재치가 있다거나 영리하다는 평가를 받는 사람이 대개 이런 경향을 갖습니다. 이런 사람이 제안하는 방법을 관리에 도입하면 나중에 상당히 골치 아파집니다.
임시방편은 그 순간엔 유용한 해결책이 될 수 있습니다. 하지만, 임시방편은 시간이 지날수록 아무것도 하지 않는 것보다 못하게 되는 때가 잦습니다. 문제는 되도록 장기적 관점에서 접근해서 근본적인 부분을 해결해야 합니다. 임시방편은 어디까지나 임시로 쓰여야 합니다.
문제를 해결하는 방법을 선택하는 기준은, 어떤 방법이 지금 당장 제일 편한가가 아니라, 어떤 방법이 제일 합리적인가입니다.
게임 개발을 하다 보면, 외부에서 제작한 도구를 많이 사용하게 됩니다. 예를 들어, 컴파일러, 그래픽 소프트웨어, 게임 엔진, 그리고 기타 라이브러리 등입니다. 이런 도구는 새 버전이 계속 나오는데, 과연 새 버전을 계속 적용해야 하는지 판단하기 어렵습니다. 이럴 때엔 제일 많은 사람이 사용 중인 버전으로 계속 갱신하는 게 좋습니다.
외부 도구를 지속적으로 갱신하면 다음과 같은 장점이 있습니다. 지원을 쉽게 받을 수 있고, 필요한 기능이 이미 구현돼 있을 수 있으며, 최적화나 버그 수정이 더 돼 있을 수도 있습니다. 반면에 외부 도구를 갱신하지 않으면 다음과 같은 장점이 있습니다. 예상치 못한 부분에서 문제가 생길 확률이 적고, 커스터마이제이션(customization)이 좀 더 쉬우며, 손에 익숙하므로 생산성이 높습니다.
위와 같이 어느 방식이 항상 더 낫다고 말할 순 없어서, 프로젝트의 상황에 따라 결정하는 게 바람직합니다. 하지만, 기본적으로는 제일 다수가 사용하는 버전을 그대로 따라가는 게 장기적으로 봤을 때 편합니다. 장기적으로 볼 때엔 유지보수라는 측면이 제일 중요한데, 어떤 버전이 얼마나 지원을 쉽게 받을 수 있고 얼마나 다수의 개발자가 그 일을 할 수 있는지 생각해 보면, 왜 다수가 사용 중인 버전을 따라가는 게 좋은지 알 수 있습니다.
저장소의 내용 일부를 외부 저장소에 그대로 반영시켜야 할 때가 있습니다. 예를 들면, 개발팀의 소프트웨어를 QA팀에 제공한다든지 할 때입니다. 이런 일을 할 때에도 어떤 방법이 가장 효율적일지 생각해 봐야 합니다.
우선 이럴 때 접근 권한을 어떻게 할 것인지 정해야 합니다. 예를 들어, 개발팀의 저장소를 열어 주고 QA팀에게 읽기 권한만 줄 수도 있을 것이고, QA팀에게 저장소를 열어 달라고 하고 쓰기 권한을 얻을 수도 있을 것입니다. 전자의 방법을 채택하면 동기화를 고민할 필요가 없으니까 제일 좋습니다. 여기서는 후자의 방법을 채택해야만 하는 상황을 가정합니다.
동기화 방법으로 제일 쉽게 떠오르는 것은 변경된 파일을 모았다가 QA팀의 저장소에 복사하고 직접 커밋하는 방법일 것입니다. 하지만 이 방법은 변경된 파일 목록을 일일이 관리해야 하는 문제가 있으므로 추천하지 않습니다.
대안은 서브버전이 관리해 주는 변경된 파일 목록을 이용해 합병(merge)을 사용하는 방법입니다. 이 방법은 개발팀에서 QA팀에게 최신 소프트웨어를 항상 제공하고 싶지는 않을 때 좋습니다. 개발팀에서 소프트웨어를 넘겨 줘야 할 때마다 QA팀 저장소에 합병하면 됩니다.
만약 QA팀이 개발팀의 최신 버전을 항상 자동으로 얻고 싶어 한다면, 서브버전의 external 기능을 사용하면 됩니다. 동기화가 자동으로 되므로, 특별한 문제가 없다면 이 방법이 좋겠습니다.
형상 관리를 하려면 대개 서버 애플리케이션을 설치해야 하는 번거로움이 있습니다. 하지만 TortoiseSVN을 사용하면, 서버를 설치하지 않고도 로컬 저장소를 만들고 형상 관리를 할 수 있습니다. 이 기능은 개인적으로만 사용하는 자료가 있는데, 백업만으로는 충분하지 않고 버전 관리를 해야 하는 파일이 있을 때 유용합니다.
로컬 저장소를 만드려면 탐색기에서 마우스 오른쪽 버튼 클릭으로 컨텍스트 메뉴를 띄운 다음에 'Create Repository here...'를 선택하면 됩니다. 로컬 저장소의 경로는 file:///D:/work와 같은 형태입니다. 자세한 사용법은 Chapter 3. The Repository을 참고하시면 됩니다.
요즘 게임 개발자는 스크립트 언어를 많이 사용하고 있습니다. 문제는 스크립트 언어를 남용하는 때가 적지 않다는 것입니다.
스크립트 언어를 프로그래머만 사용하고 편집이나 디버깅이 까다롭다면, 스크립트 언어 사용의 큰 장점을 살리지 못하는 것입니다. 게임 개발에서 스크립트 언어를 사용하는 최대 장점은, 프로그래머가 아닌 사람이 게임 로직을 제어할 수 있다는 것입니다. 이 장점을 살리지 못하는 스크립트 사용은, C++ 대신에 다른 언어를 사용하는 것일 뿐입니다. 프로그래머만 스크립트 언어를 사용한다고 해도, 빌드와 게임 로딩에 걸리는 시간을 줄인다거나 코드가 간결해지는 장점이 있을 수도 있습니다. 하지만 낯선 언어, 기능이 부족한 편집기와 디버거, 그리고 C++과의 연동 작업 등을 고려하면, 단점이 더 많습니다.
텍스트 데이터 표현을 스크립트 언어로 하는 것도 스크립트 남용의 좋은 예입니다. 스크립트 언어는 로직을 제어하는 데에만 써야 합니다. 텍스트 데이터 표현엔 XML이나 엑셀 문서 등의 좋은 포맷이 많이 있습니다.
스크립트 언어는 분명히 장점을 갖고 있지만, 단점이 더 많은 일에도 스크립트 언어를 사용하는 것은 좋은 선택이 아닙니다.
도대체 공 있는 자가 후한 녹을 받고 유능한 자가 큰 벼슬자리에 있게 된다면 임협의 인사가 어찌 사사로운 용맹을 떠나서 적을 막는 데 힘쓰지 않을 수 있겠으며 벼슬길 찾는 인사가 어찌 권세가를 꺾고서 결백을 힘쓰지 않을 수 있겠는가. - 책 <한비자>많은 기업이 말로는 인재 경영을 외치지만, 인재를 실제로 소중하게 생각하는 곳은 드뭅니다. 좋은 인재를 찾아 뽑는 일도 중요하지만 인재를 잘 관리하는 것도 중요한데, 그 관리를 어떻게 할 것인지 심각하게 고민하는 기업은 거의 못 봤습니다.
피드백은 좋은 결과를 얻고자 할 때 필수적인 요소입니다. 계속 노력하는데도 결과가 좋지 않다면, 그 원인은 피드백을 제대로 활용하지 못한 것일 확률이 높습니다. 피드백을 잘 활용하려면 여러 가지 생각해야 할 것이 많은데, 그중에서 주기에 대해 생각해 보겠습니다.
애자일(Agile) 방법론 중의 하나인 스크럼(Scrum)에서는 반복 주기를 한 달로 할 것을 권장합니다. 이것은 보통 프로토타입 시연 이후 알파 테스트 전까진 프로젝트를 한 번도 점검하지 않는 일반적인 게임 개발 과정보다는 피드백을 상당히 적극적으로 활용하려는 편입니다. 하지만, 저는 이 정도 주기도 상당히 긴 편이라고 봅니다. 물론 애자일 문화가 정착되지 않은 팀에는 한두 달 정도의 반복 주기도 벅찹니다. 그러나 팀에 애자일 문화가 뿌리내렸거나 처음부터 그런 자세를 가진 사람이 모였다면, 반복 주기는 최대 1주를 넘지 않는 게 좋습니다.
왜 피드백 주기가 짧을수록 좋을까요? 피드백이 잦을수록 일이 크게 잘못될 확률이 낮아지기 때문입니다. 모니터를 보지 않고 타자하다 보니 한영 전환이 잘못돼 있어서 엉뚱한 글씨가 나온 경험을 누구나 갖고 있을 것입니다. 이처럼 작고 쉬운 일조차도 피드백 주기가 길면, 일이 많이 잘못된 후에야 실수했다는 걸 알기 쉽습니다. 더구나 게임 개발처럼 크고 어려운 일이라면 두말할 이유가 없습니다.
피드백은 어떤 일을 할 때 제일 유용한 도구 중 하나이고, 그 피드백의 주기를 짧게 가져가는 것은 피드백을 잘 활용하기 위해 꼭 필요한 일입니다.
로이스터는 "한국에서는 통역을 거친다는 제약 때문에라도 나는 불가피하게 간결하고 명쾌한 지시를 내려야 하는데 이는 오히려 리더에게 긍정적 제약"이라며 "어떤 비즈니스에서도, 어떤 조직에서도 간결하고 명쾌하고 반복적인 커뮤니케이션은 매우 유익하다"고 단언했다.간결한 커뮤니케이션은 중요도가 작은 정보를 걸러 내서 전달하기에, 수용자가 핵심을 좀 더 빨리 파악하게 합니다. 그리고 명쾌한 커뮤니케이션은 오해의 소지를 없애므로 불필요한 재작업을 줄일 수 있습니다. 마지막으로, 반복적인 커뮤니케이션은 상황의 변화에 따른 피드백을 자주 반영할 수 있게 합니다. 그는 이렇게 커뮤니케이션에 필요한 덕목을 알고 있으니, 한국어를 잘 못한다 해도 별로 문제될 것이 없습니다.
로이스터에게 "당신은 선수를 평가할 때 어떤 지표에 가장 비중을 두느냐"고 묻자 "나는 숫자나 통계를 보지 않고 선수를 본다"는, 매우 의외의 대답이 돌아왔다.
"숫자에는 함정이 있다. 1게임에 3안타를 쳤다는 기록만 보면 그 선수는 굉장히 잘한 것 같다. 하지만 빗맞은 공이 높은 바운드 덕분에 운 좋은 안타가 될 수 있다. 숫자에만 집착하면 이를 알아낼 수 없다. 나는 선수를 주시하고, 그들의 플레이를 관찰해 판단한다."
"올해 롯데의 실책 수가 작년보다 늘어났으니 수비가 나빠졌다고 보는 전문가가 있더라. 절대 그렇지 않다. 과거에는 수비 시도조차 하지 못해서 아예 손도 못 대던 어려운 타구를 이제는 수비수가 잡게 되니 송구 실수가 나오고 실책 수가 늘어난 것이다."많은 관리자가 객관적으로 측정하기 쉬운 수치만 맹신합니다. 목표 대비 업무량을 측정하고, 출퇴근 시간을 확인하며, 문제를 몇 개나 일으켰는지 셉니다. 그에 비해 정작 중요한, 고객 만족도, 작업 품질, 협업 능력, 문제 해결 능력, 작업 과정 개선 능력, 아이디어 창출 능력 등은 객관적으로 측정하기 어렵다는 이유로 무시합니다. 이러니 조직이 제대로 돌아갈 리가 없습니다.
士爲知己者死 女爲悅己者容(사위지기자사 여위열기자용: 선비는 자신을 알아주는 이를 위해서 죽고, 여자는 자기를 사랑해 주는 이를 위해 화장을 한다.) - 전국책(戰國策)두 감독이 전국책을 읽었는지는 모르겠지만, 전국책의 지혜를 알고 있군요.
아래에 여러 가지를 적어 보았습니다만, 개발 기간을 단축하는 주된 방법은 경험의 활용이 아닐까 생각합니다.
1. 엔진 사용 경험
사용하려는 엔진을 써 본 사람이 있으면, 그 한 사람 때문에 개발 속도가 상당히 향상됩니다. 어떤 엔진을 쓰느냐보다 그 엔진을 잘 다룰 수 있는가가 더 중요한지도 모르겠습니다.
2. 게임에 맞는 엔진 사용하기
다른 장르의 게임을 만들려고 하는데, FPS에 적합한 엔진을 쓰는 것은 위험 부담이 큽니다. 개발 도중 발생하는 많은 문제를 스스로 해결해야 하기 때문입니다.
3. 엔진에 맞는 게임을 제작하기
위와 비슷한 얘기지만, 반대의 상황일 때입니다. 이미 특정 엔진을 보유하고 있고 그 엔진을 잘 다룰 수 있는 개발자가 있다면, 그에 맞춰서 게임을 제작하는 게 좋습니다.
4. 비슷한 형태의 게임 제작 경험
어떤 게임을 만들든지, 비슷한 게임을 만들어 본 사람이 있으면 이 또한 큰 도움이 됩니다. 개발 도중 발생하는 많은 문제를 미리 준비할 수 있고, 문제를 어떻게 해결해야 하는지 알 수 있기 때문입니다.
5. 지식 공유
어떤 문제가 생겼을 때, 개인이 처음부터 해결책을 찾는 것보다 여러 사람이 이미 가진 경험을 활용하는 게 훨씬 이득인 경우가 많았습니다. 많은 개발사가 팀 단위로 나뉘고 회사 전체의 지식이 공유되지 않는 경우가 많은데, 개발 기간을 단축할 수 있는 좋은 방법을 놓치는 것 같습니다.
6. 쉬운 방법으로 개발하기
처음부터 최적화되고 일반적이지만 복잡한 방법으로 개발하려고 하지 말고, 경험이 있거나 간단한 방법으로 개발하는 게 좋은 것 같습니다. 연구가 필요한 것은 개발과 별도로 진행해야 합니다.
7. 직무에 맞는 일을 하기
경험이 있는 일을 하는 게 아무래도 효율이 좋습니다. 했던 일을 또 하기 때문에 의욕이 좀 떨어진다는 문제가 있지만, 그렇다 하더라도 경험은 중요한 것 같습니다. 또 실제 업무를 담당하는 사람이 관련 작업을 해야 합니다. 예를 들어 기획자가 수치 하나를 바꿔 보고 싶은데, 프로그래머에게 부탁해야 하는 일이 자주 생긴다면 문제가 있습니다.
8. 도구의 활용
엔진뿐만 아니라 다른 도구의 중요성도 상당히 큽니다. 컴파일시간을 줄이도록 분산 컴파일 도구를 쓰기, 검증된 라이브러리를 쓰기, 최대한 다른 사람의 라이브러리를 활용하기, 그리고 익숙한 도구를 쓰기 등이 있겠습니다.
9. 우선순위 설정
세부적인 부분은 서비스 이후에 추가하거나 변경하고, 핵심적인 부분부터 만드는 방법도 있겠습니다. 전체 개발 기간은 그대로지만, 서비스를 좀 더 빨리 시작할 수 있다는 장점이 있습니다.
어떤 게임 개발사가 작품 하나로 우연히 성공하는 일은 많지만, 그 성공을 꾸준히 이어가며 성장하는 개발사는 아주 드뭅니다. 왜 그럴까요? 단 한 번 성공하려면 운만으로도 가능하지만, 여러 번 연속해서 성공하려면 운이 아니라 내공이 뒷받침돼야 하기 때문입니다. 그 내공에서 가장 중요한 두 가지 요소는, 직원 개개인의 능력, 그리고 모든 직원의 능력을 최대한 발휘하게 하는 기업 문화입니다.
성공한 게임의 유명 개발자 한두 명을 모셔 오고 그들에게 절대 권력을 주면, 저절로 성공하리라 생각하는 사람이 많은 것 같습니다. 그러나 그들에게 무한한 권력을 주면 그게 독이 되어, 다른 직원의 의견은 듣지도 않고 대상 게이머의 취향도 무시한 채로 자신이 원하는 게임을 원하는 방식대로 만드는 때가 잦습니다.
참고로, 美블리자드 한국인 개발자 강형원씨 '디아블로3' 개발자 되다에서 새겨볼 만한 부분을 아래에 인용합니다.
'블리자드는 어떤 회사인가'라는 질문에 강씨는 "일단 개발이 시작되면 모든 사람이 아이디어를 쏟아냅니다. 현실성이 없더라도 절대 버리거나 무시하지 않아요. 각자 자기 역할을 하지만 궁극적으로 전체에 이익이 될만한 아이디어는 언제든 제시할 수 있고, 받아들여질 가능성이 열려 있는 곳"이라고 말했다.
평점
★★☆☆☆
평가
회고의 내용을 어떻게 하면 좋은가보다는 회고를 진행하는 방법에 초점을 맞춘 책입니다. 회고에 참여하면서 아쉬웠던 것은 회고의 방법보다는 내용이었는데, 그 부분에 대해 해결책을 별로 제시하지 않아서 만족스럽지 않습니다. 회사에 있던 책이 아니라 제 돈으로 산 책이라면, 돈이 상당히 아까울 것 같습니다.
인상깊은 부분
33쪽:
설명이 끝났다면 방에 있는 모든 사람이 돌아가며 한마디씩 이야기하는 시간을 갖는다. 회고를 시작할 때부터 말을 하지 않은 사람은 이후에도 계속 말을 하지 않아도 괜찮다고 생각하기 쉽기 때문이다. 회고의 목적은 사람들이 함께 생각하고 배우는 것이니만큼 진행자는 모든 사람을 참여시켜야 한다.
44쪽:
회고를 시간낭비라고 생각하는 팀들은 일상적인 작업 계획과 개선 계획을 분리시킨다. 이렇게 계획이 분리되어 있으면 일상 작업외의 일을 할 여유가 전혀 나지 않는다.
댓글을 달아 주세요
전 게임 개발이 아니라 이번에 전세집을 구하면서 너무 즉흥적으로 결정한듯... 막상 계약걸고 난 다음에 이것저것 체크해야할게 많다는걸 뼈져리게 느꼈습니다!!!
전세는 전세금 돌려 받기 어려운 일도 종종 생겨서, 꼼꼼하게 확인하고 계약하는 게 좋다고 하더라구요. ㅎㅎ