생산적인 개발을 위한 지속적인 테스트
View more presentations from 기룡 남

얼마전에 이사하느라고 짐을 정리하다 보니,
작년 KGC 예비 발표장에 갔다가 메모한 쪽지가 나왔는데
나중에 블로그나 위키에 정리 한 번 해두어야지... 하고는 여태 그냥 방치되어 있던게 생각나서 얼른 정리한다.

마이에트사의 레이더즈 팀에서 적용하고 사용중인 테스팅 환경을 정리해 발표해 주신 듯.
적어도 내가 소식을 접해본 개발팀 중 국내에서는 가장 개발 환경이 잘 정리된 팀이 아닐까 하는 생각을 해본다.
DB 유닛 테스팅 같은 경우 초기 구축이나 유지가 힘들어 보이긴 하지만 그래도 한 번 구축해 보고 싶은 생각이 들었다. 요즘 안그래도 팀 내에서 DB쪽 모델링이나 테스팅에 대한 이슈가 좀 있어서 더욱이.

레이더즈 팀도 잘 되고 대박나셔서 개발환경 구축의 중요성에 대한 좋은 선례로 길이길이 남아주시길! :)
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

1. 빌드 스크립트를 만든다.

어딜 가나 빌드 스크립트 작성은 늘 내차지군.... 빌드 스크립트 내용은 공유할 수 없다. 자료는 웹에 많으니 검색해서 작성할 것. 커맨드창에서 비주얼 스튜디오 빌드하는 것만 적어보자면

call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86
devenv /rebuild Release "솔루션파일명.sln"

2. 빌드 스크립트 인자로 Cruise Control의 빌드버전 넘기기.

http://confluence.public.thoughtworks.org/display/CCNET/Executable%2BTask

<exec>
  <executable>(빌드 스크립트 파일명).bat</executable>
  <buildArgs>%CCNetLabel%</buildArgs>
  <baseDirectory>실행경로 명시</baseDirectory>
  <buildTimeoutSeconds>수행시간 명시</buildTimeoutSeconds>
</exec>

3. 배치파일의 인자를 받을 땐 %1%을 이용한다.

SET FOLDERNAME=(배포본복사할폴더명앞부분)_%1%
MD %FOLDERNAME%
CD %FOLDERNAME%

4. 빌드 스크립트도 버전관리툴에 집어넣고, ccnet을 수행할 때 싱크받도록 하자. 그러면 개발자 자리에서 바로 수정되고, 바로 적용된다.

5. 압축하기 

압축시대 사용. 압축시대 안에 들어있는 7zg32.exe를 이용한다. 압축시대 폴더를 path 환경변수에 추가해준다.
7zg32.exe a -tzip (압축할파일명).zip .\(압축할폴더명)

6. 네트워크 디렉토리로 복사 

xcopy를 이용하면, 공유설정이 된 다른 머신의 폴더로 바로 복사가 된다. 호오 신기하지... ftp 사용할 필요 없이 xcopy 한줄이면 압축한 파일 복사 완료.
xcopy (압축파일명).zip "\\공통머신\공통폴더\어디엔가"

7. 배치파일의 실행결과 (에러값) 리턴
배치파일의 올바른 수행여부를 리턴해야 한다. 빌드과정중 실패하는 경우 cctray에 빨간불이 뜨게 해서 개발자들이 알아챌 수 있도록 한다.

if not exist (존재해야 될 파일).확장자 ( set msg="무슨파일 생성 실패"&set errorlevel=-1&goto fail_proc
...
:fail_proc
echo %msg%
exit /b %errorlevel% 

이렇게 하면 이제 어느 개발자든지 트레이창에서 cctray 꺼내서 build 버튼 한 번 누르면 배포본 파일이 뚝 떨어짐!

아 이런건 진작에 했었어야 돼 ㅜㅠ...


앞으로 더 할 것 :
  • 빌드 마치고 배포하기 전에 심볼서버에 pdb 인덱싱해서 저장하기.
  • 패치개념 도입. 서비싱할 폴더에 변경된 사항들만 선별적으로 업데이트 하는 방식 구상하기.
    (현재 우리 프로젝트는 패치방식이 아니기 때문에 좀 독특하게 패킹한다.)
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

목표설정 절차는 회사목표→본부목표→팀목표→개인목표 순으로 정한다.회사목표와 본부목표는 경영방침을 먼저 제시하고, 제시된 경영방침을 달성하기 위하여 추진해야 할 핵심목표와 전략을 수립하여, 협의, 조정을 거친 후  consensus meeting을 통하여 확정한다.부문장, 팀장, 팀원의 목표는 상사가 먼저 목표를 제시하고, 부하는 상사가 제시한 목표를 달성하기 위하여 자신이 추진해야 할 목표를 설정한다. 상위조직의 목표는 하위조직으로 내려갈수록 보다 세분화, 구체화된다. 

목표는 분명해야 한다. 목표가 분명치 못하면 계획을 세울 수가 없다.  목표는 “어디에서”, “무엇을”에 관심을 갖는다면 계획은 “어떻게” 에 관심을 갖는 것이다.

출처 : 삼성경제연구소 - 목표관리(MBO)의 정의.

* 잘못된 TODO 작성 : 담주부터 뭐할지 알아서 각자 써서 내고, 그대로 작업하라.
* 올바른 TODO 작성 : 현재 우리 프로젝트에서 작업의 우선 순위는 1. 클라이언트 안정화 > 2. 신규유저 이탈방지 > 3. 유료화 준비 및 매출소스 창출 > 4. 게임편의성 증대의 순서다. 이에 맞추어 우리가 할 수 있는 일들에 대한 의견들을 수렴해보자. 이를 토대로 작업 방향 및 백로그를 결정하겠다.

나는 이렇게 생각함.

전에 읽었던 글 중에, "리더는, 팀원들에게 업무에 관한 자율적인 권한을 보장하는 것과 뚜렷한 작업 방향을 제시해주지 못하고 주저하는 것을 헷갈려서는 안된다." 라는 구절을 봤었는데... 인용하려고 다시 찾으려니깐 못찾겠다.

아... 이래서 독서 노트가 중요해.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요


Feature creep이라는 말이 있습니다. 게임 개발 뿐만 아니라 많은 소프트웨어 개발 프로젝트에서 발견할 수 있는 것들입니다.

 

마침 위키피디아에서 feature creep을 잘 설명한 글이 있습니다. (링크) 요약해보죠.

  • 제품을 개발하다보면 사용자들이 원하는 기능과 쓸모있는 기능들을 넣고자 하는 열망이 생긴다. 그리고 그렇게 함으로 매출을 올리고자 한다. 아이러니하게도, 이것이 feature creep의 시작이다.
  • feature creep이 지속되면 불필요한 기능들이 자꾸만 들어가게 되고 프로젝트의 복잡도가 증가하며 제품의 특장점과 핵심 기능이 서서히 감춰지게 된다.
  • feature creep은 이미 개발된 (혹은 개발중인) 프로젝트를 유지하려는 의지가 원인이 되기도 한다.
  • feature creep은 프로젝트의 개발 비용을 과다하게 증가시킬 뿐만 아니라 프로젝트를 죽여버리는 원인이 되기도 한다.

Feature creep으로 진화된 물건. 바지 주머니에 넣으려면?

 

feature creep은 매우 흔합니다. 당장에 여러분이 참여하고 있는 프로젝트에서도 발견할지도 모릅니다.

 

feature creep을 일으킬 수 있는 위험인자는 흔하게 널려있습니다. 여러분의 직장 상사, 여러분의 친인척들, 심지어 여러분 자신 및 여러분이 지금 열심히 보고 있는 책에도 있을 수 있습니다. 저 또한 많은 feature creep에서 고생해본 사람이기도 합니다.

 

어떤 경우에서 생기는지 보도록 하죠.

 

프로그래머들은 신기술이 나오면 바로 적용해보고 싶어합니다. 뭔가 엘레강스한 대단한 아키텍처(나중에 알고보니 안티패턴임을 뒤늦게 깨달을)를 적용해보고 싶어합니다. 어느날, 모노리스 코드가 만들어지고 심지어 자기 스스로도 감당하기 힘든 복잡도를 가진 괴물을 만들고 맙니다. 그리고 회사가 개발 일정과 (자금이) 나빠지면서 슬슬 구인 게시판을 뒤져보기 시작합니다. 중요한 실력과 정교한 개발보다 많은 시도를 해보고 싶어하는 (나쁘게 말해서 회사를 상대로 실험해보려는) 모험심 강한 (그러나 실력과 책임감이 그만큼 받쳐지지 못하는) 프로그래머에게서 볼 수 있습니다.

 

게임 기획자들은 대단한 게임을 만들고 싶은 마음에 여러가지 아이디어들을 계속 집어넣습니다. 다른 게임에서 감동한 기능들을 자꾸만 넣습니다. 뭔가 엘레강스한 완성도의 게임을 꿈꾸며 대량의 기획서를 작성합니다. 그리고 플레이를 해보니 별로 재미가 없습니다. 안되겠습니다. 뭔가를 추가해야겠다고 생각합니다. 장르도 늘어납니다. 처음에는 액션 게임이었는데 만들다보니 MMO + RPG + 전략시뮬 + 커뮤니티 + 어드벤처 + 음악댄스 + 영어교육 게임이 되어버립니다.

 

경영진,마케터,운영팀도 feature creep에 일조합니다. 유저들의 피드백, 시장 현황, 소문 등은 개발 방향에 자꾸만 쓸데없는 암세포를 붙이게 합니다.

 

횟집은 뭐니뭐니해도 회가 신선하고 맛있어야 합니다. 스끼다시와 매운탕만 잔뜩 줘봤자 회가 물러터졌으면 소용없죠. Feature Creep은 동네 음식점에서도 흔히 볼 수 있습니다.

 

feature creep으로 고생하는 게임 개발 프로젝트의 공통점은 다음과 같습니다.

  • 프로젝트 초기에 만들려고 했던 것이 분명하게 구체화되어있지 않았습니다. 아무것도 구체화되어있지 않으면서 정작 만들고자 하는 것은 거대한 꿈 덩어리입니다.
  • 현실 감각을 잊은 지나친 열정을 갖고 있습니다. 단 한개의 궁극 완성도 제품을 만들려는 열망만 가득합니다. 현실적으로, 신차를 개발해도 포니부터 시작해야 소나타도 만들고 그랜저도 만들고 궁극적으로 에쿠스도 만드는건데, 처음부터 페라리를 만들려고 합니다. 즉 프로젝트 범위의 상한선을 미리 그어놓지 않았습니다.
  • 디렉터가 중간 결과물이 별로 마음에 들지 않는다는 이유로 당황합니다. 그리고 돌파구를 "더 멋진 시스템의 추가"에서 찾으려만 합니다. 그냥 버리고 완전히 새로운 것을 시작하는게 더 나을 것 같은데 말이죠.

단도직입적으로 말하죠. Feature creep은 가장 쉬우면서 무능력한 개발 방향입니다. 본질에 자신없어서 자꾸만 서비스를 추가하는 것이니까요.

 

Feature creep이 "자꾸만 넣는다"인데 이에 반대되는 말은 "더 이상 뺄 것이 없을 때까지 빼기"입니다. 그리고 더 이상 뺄 것이 없을 때까지 빼버리고, 남은 것들에 대해서는 최고의 품질을 만들기 위해 집중을 한 제품 중에서는 시장에서 성공한 것이 많습니다. 제가 생각하는 이러한 예는 비주얼드, 광란의 수족관, 팡야(골프게임), 아이팟입니다. ProudNet을 쓰는 프로젝트 중 몇 개도 있고요.

 

혹시 여러분의 프로젝트에서는 알게 모르게 feature creep이 범해지고 있지 않나요?

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요


http://heycalmdown.springnote.com/pages/1873674


저는, 무슨 생각이었는지, 어릴 때부터 게임 기획자가 아닌 다른 직업을 가질거라고는 한 번도 생각해본 적이 없었습니다. 특히 --- 회사원이오! (매일 사무실에서 서류를 뒤적이면서, 뭘 하고 돈을 받는 거죠?) 그렇다고 뭐 싹수가 보이는 훌륭한 기획자 지망생이었던 것은 아니지만 그 외에 아무 것도 할 수 없었거든요. 제 청소년기는 온전히 게임 디자인 동호회에서 보냈고, 어느새 정신을 차려보니 게임 기획자로 현업에 데뷔했죠. 열심히 일했고, 오랫동안 준비했기에 자신도 있었습니다. 그리고, 저는, 어느 순간, 마침내, 게임 기획자의 길에서 도망쳤습니다! 단 하나 외에는 한 번도 생각해보지 않은 길에서 내려온 것입니다. 그래서 저는 뭘 하면 좋을지 전혀 모르게 되어버렸었어요.

저는 이제 8년차 게임 서버 프로그래머입니다. 저는 지금 게임 기획자가 아니지만, 제가 예전에 많은 시간을 온전히 거기에 바쳤다는 것을 잊지 않았고, 거의 모든 게임 개발업 종사자들과 마찬가지로 언젠가 내 마음에 꼭 들, 부끄럽지 않은 게임을 만들기 위해 일을 하고 있습니다. 다른 프로그래머들에 비해 제가 좀 유리한 점이 있긴 합니다. 언제라도 기획자의 입장을 이해할 준비가 되어 있다는 것이지요. 준비가 되어 있는 것과 그렇게 하는 것은 조금 다른 문제입니다만. 저는 가능하면 늘 게임 기획자가 원하는 기능을 정확히 구현하려고 노력합니다. 그들이 말하지 않았거나 빠뜨렸던 것까지요. 가끔은 제게 '자꾸 그렇게 해주면 버릇만 나빠진다'거나 '네게 익숙해지면 다른 프로그래머와는 일하기 힘들어진다' 하고 충고해주는 분들도 계십니다만, 저는 예전에 기획자였다는 것을 잊지 않으려고 노력합니다.

하지만 --- 이렇게 생각해봤어요. 내가 언젠가 기획자였기에 유리한 점이 있다면(혹시나 조금이나마 그랬다면), 나중에 다시 게임 기획을 할 적에, 프로그래머였어서 유리할 점도 있을까? 하고요. 그 전에 그런 생각을 한 적이 전혀 없었다는 것은 사실이 아닙니다만 돌이켜보니 구체적인 사례를 떠올려가며 생각한 적은 없더군요. 이 글은 그런 차원에서 생각해보고자 써내려가고 있습니다.

왜 기획서가 못마땅한가?

많은 프로그래머가 기획자나 기획서에 불만을 터뜨리는데, 그 이유가 무엇일까요? 어떤 프로그래머는 기획서가 완벽하지 않으면 코드를 한 글자도 짜지 않겠다기도 하고, 이 기획서 그대로 만들테니 나중에 다른 소리 하지 말라고 다짐을 받기도 합니다. 다 좋은 게임 만들자고 하는 건데 그들이 이렇게 까다롭게 구는 이유가 무엇일까요? 그냥 프로그래머들은 까칠한 성격이 많아서이거나, 까칠해야 프로그래머가 될 수 있다거나 하는 그런 이유일까요?

그들이 가능할 리 없는 --- 한치의 오류도 없이 정확한 기획서를 원하는 것처럼 보이는 이유는 그저 일을 다시 하고 싶지 않기 때문입니다. 프로그래머는 일을 대충하는 것을 싫어합니다. 결과가 신통치 않으면 다시 해야 되고, 정해진 시간에 두 번 일을 하려면 대충하는 수밖에 없죠. 일이 갑자기 늘어나거나 일정이 줄어들어 어쩔 수 없을 때면 죄책감에 빠지기도 하는 게 프로그래머입니다. 어느 수준을 넘으면 그만 자포자기하기도 하고요. 연약한 마음을 가진 사람들이죠.

기획서에 있는 그대로 만들었다고 해서 기획자가 원하는 게임이 만들어진다는 법은 없습니다. 그래서 기획서 그대로 토씨 하나 차이 없이 만들어 내고 나면 기획자도 프로그래머도 고객도 모두가 불만족스러워지는 것입니다. 일을 정말 잘 하기 위해서 필요한 건 사실 기획서가 아닙니다. 정말로 필요한 건 기획자가 원하는 것이 무엇인지 알아내는 거죠. 기획서는 기획자의 부분집합일 뿐입니다. 그들도 사람인지라 실수를 하고 논리적 허점을 발견하지 못하기도 하고, 알고 있는 것을 완벽히 표현하지도 못합니다. 기획서란 그들이 정말로 원하는 것이 무엇인지 알 수 있는 단초에 불과하죠. 그런데 프로그래머는 대체 왜 그런 기획서를 토씨 하나까지 그대로 만들어 내겠다고 하는 건가요? 뻔히 보이는 실수까지 그대로 말입니다. 좀 물어보면서 하면 안 됩니까? 간단한 오류는 스스로 고쳐서 하면 안 되고요?

그것은 많은 프로그래머들이 지쳐있기 때문입니다. 트라우마를 가지고 있기 때문이기도 하고, 어차피 결과를 알고 있기도 하고요. 기획서에 빠진 부분이나 논리적인 결함을 '해결'해서, 소위 빈 칸을 채워가며 개발하고 나면 자기가 들을 소리라고는 '왜 이렇게 만들었느냐' 또는 '내가 원한 건 이게 아니다' 정도 아니겠습니까?

문제가 뭘까?

기획자와 프로그래머의 말이 모두 일리 있습니다. 그렇다면 일이 왜 이 지경이 된 걸까요? 문제는 모든 일이 끝난 다음에야 기획자가 평가를 하기 때문입니다. 모든 일어날 수 있는 사건은 이미 다 일어났습니다. 실수라는 실수는 다 벌어졌고요, 문제라는 문제는 다 발생했죠. 단어 하나에도 까다로운 프로그래머 역시 사람이기 때문에 실수를 합니다. 오해도 하고요. 기획자란 자기가 원하는 결과를 기획서에 옮겨적는 것 하나 제대로 못 하는 사람들이지만 프로그래머는 그걸 그대로 만드는 것조차 못합니다. 결과가 어떻게 되었겠습니까? '글쎄, 이건 내가 원한 게 아니군요.' '그럼 기획서나 제대로 써놓던지요!'

프로그래머가 원하는 기획서는 별 게 아닙니다. 공백이 많은 기획서라도 좋습니다. 기획자의 의도만 확실히 알 수 있다면 그 공백을 유추하여 채울 수 있습니다. 그러고 나서 유추한 결과가 맞는지 미리 알 수 있으면 됩니다. 네, 그렇습니다. 일이 다 벌어진 다음이 아니라 말이죠. 프로그래머가 원하는 건 논리적 결함없이 섹시하게 잘 빠진 기획서가 아니라, 기획자 그 자체입니다. 기획서 따위 알 게 뭐에요. 기획서를 그대로 만든 게임이 재미가 없다면 무슨 소용이 있습니까. 기획자라면 어떻게든 문제를 해결하겠지만요.

한 가지 짚고 넘어갈 게 하나 있습니다. 바로 위에서 내린 결론은 공백이 많은 기획서가 좋다는 게 아닙니다. 모든 일이 다 끝나기 전에 우리가 잘 가고 있는지 가이드가 필요하다는 말입니다. 사람이 쓴 글이라면 늘 오해가 있는 법이라고 말했죠?

한 줄 요약 - 프로그래머가 원하는 기획서는...

사실 그들은 기획서를 원하지도 않습니다. 부분과 전체가 올바르게 제자리를 찾아갈 때까지 기획자와의 반복적이고 지속적인 교감을 원하는 것 뿐이죠.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wangmul.egloos.com/1099445




요즘 열심히 읽고 있는 책은 실용주의 프로그래머이다.
많은 분들이 좋은 책이라고 이야기하는 것은 확실히 그 이유가 있다고 생각한다.

요즘 읽은 조엘 온 소프트웨어라던가 이전에 봤던 Professinal 소프트웨어 개발과 같은 책을 볼때의 그 감동과 뿌듯함을 다시 느낄 수 있는 책을 볼 수 있다는 것에 정말 감사하다. 이렇게 끊임없이 읽을 책이 나온다는 것이 행복하기 그지없다.

어설픈 변명을 만들지 말고 대안을 제시하라.
- p32. 고양이가 소스코드를 삼켰어요 중에서


프로젝트를 진행하다보면 문제라는것은 당연하게 생긴다.
DB를 날리거나 소스코드에 버그가 있거나 논리적인 오류로 인하여 문제가 발생하거나 운영상의 미스가 생기는 등의 문제는 생기기 마련이다.

중요한 것은 이런 문제가 발생했을 때의 대처방법이다.

내가 처음 다녔던 회사의 경우 문제가 발생하였을 경우 해당 문제에 대하여 보고를 하면 "어떻게 하면 해결할 수 있어?"라고 항상 되물었다.

1. 문제를 만들어냈던 사람에게 해결 방법에 대하여 물어본다.
2. 제시한 해결방법이 정확하게 확실한 방법인지 선임자에게 확인을 한다.
3. 해당 방법에 따라서 해결하게 한다.
4. 완벽하게 해결이 되었다면 문제 발생으로 인한 손실에 대하여 책임을 전가시키지 않는다.

이런 방식의 문제 해결은 설령 문제가 생기더라도 변명꺼리를 만드는 것이 아니라 해결방법을 능동적으로 찾게 만들었고 자신이 하는 업무에 자신감이 붙게 만들었다.

그러나 문제가 생겼을 때
1. 문제를 발생시킨 사람에게 책임을 묻는다.
2. 문제의 해결을 선임자가 하며 문제를 발생시킨 사람은 어떻게 해결이 되었는지 알지 못한다.
3. 해결 방법을 찾는 것이 아니라 문제의 원인만을 찾는다.

이런 방식으로 문제를 다루게 된다면 그것은 팀원의 사기 저하를 시킬 뿐만 아니라 팀 전체를 소심하게 만들어버린다.

회사는 학원이 아니라고 말을 한다.
회사는 손실을 감수해가면서 트레이닝 시키는 곳이 아니라고 말을 한다.
그러나 대기업에서 시간과 비용을 감수하며 신입사원을 트레이닝 시킨다. 전투기 조종사를 양성하는 비용은 수억원이 필요하다.

팀원은 하늘에서 떨어지는것이 아니라 만들어지는 것이다. 경력이 있건 없건 회사에서 그 사람을 뽑았다면 그 사람의 가능성에 투자를 해야 한다.
첫 회사에서 그렇게 투자를 했던 팀원들은 1년후부터 문제를 발생시키는 사람에서 문제를 해결하는 사람으로 바뀌었고 또 1년이 지난 뒤에 회사에서 없어서는 안되는 사람이 되었다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wangmul.egloos.com/1728273


내가 우리팀에 들어온 것은 게임의 두번째 대규모 업데이트를 한지 몇달 지나서였다. 내가 입사했을 때는 게임서버 상태가 굉장히 좋지 않아서 일주일에 몇번씩 죽어나갔고 그것 때문에 업무인수인계를 받을 여유조차 있지 않아 혼자 끙끙 앓으며 소스코드를 파악했던 기억이난다. 그리고 벌써 3년이 지났다.
처음 들어왔을 때는 대여섯명 정도의 인원밖에 되지 않았던 프로그램파트는 이제 10명이 훌쩍 넘어버렸다.

평균적인 팀원 교체 속도에 비해서는 굉장히 느린 편이다. 게임회사에서 기존 팀원들이 나가고 새로운 팀원이 들어와서 그 자리를 메꿔 팀원 전체가 바뀌는 주기가 1년정도였는데 네명의 팀원은 아직도 그대로 우리 팀에 남아 일을 하는 중이다. 억지로 기수를 만들어보자면 내가 2기팀원쯤 되고 지금의 팀은 2기와 3기 팀원이 섞여있다고 할 수 있다.

오랜 시간 계속되는 팀에 새로운 사람이 들어오게 되면 드러나는게 뭐가 있을까?
예상치도 않게 드러나는 것이 소스코드의 견고함이다.

새로운 팀원이 들어오고 새로운 기능이 만들어질 때 아무리 소스코드에 대한 파악을 한다고 해도 20%이상 파악을 하기 힘들다.
프로그래머는 소스코드로 이야기를 하고 소스코드만 봐도 그 사람이 이 코드를 짤때 어떤 생각을 하는지 느껴진다고 해도 역시나 20%이상 파악하기 어렵다.

예를 들어 유저에 대한 정보가 저장되어 있는 클래스인 유저 클래스가 있다고 하자.
그 유저 클래스에 유저에 대한 정보가 모두 들어있고 그것을 외부에서 가져와 사용한다고 할 때 처음에야 GET/SET함수를 만들어놓지만 시간이 없다는 이유로 Public으로 선언하여 내부 변수를 가져다 쓰게 만들곤 한다. '뭐 별일 있겠어?' 라고 생각하면서.

하지만 소스코드의 견고함은 여기에서 무너지게 된다.
유저가 가지고 있는 게임머니를 1번 쓰레드에서 가져와서 바꾸려는 사이에 2번 쓰레드에서 그 값을 덮어쓰기 해 버린다면 2번 쓰레드에서 벌어들인 유저의 게임머니는 공중으로 사라져버린다. (Critical Secion같은 것으로 막아버리면 되겠지만 이렇게 막기 시작하면 그 이후부터는 계.속. 그 방법만을 쓸 수 밖에 없다.)

지난 3년의 시간동안 신규 기능 업데이트 이외에 우리가 꾸준히 해 왔던 일은 이런 일이었다.
처음 이 게임을 개발할 때 개발자가 시간이 없어 소스코드의 견고함을 신경쓰지 못한 부분에 대한 보수작업을 계속 해 왔다. 이런 보수작업을 통해 우리는 끊임없이 게임의 안정성을 높여왔고 이런 것이 하나씩 완료되면서 게임서버가 죽는 일도, 게임 클라이언트가 죽는 일도 점점 줄어들었다.

신입사원이 많이 들어오고 새로운 기능들을 추가할 때 상상하지도 못했던 문제가 계속해서 생기게 되면 그 신입사원의 능력을 의심하기전에 지금의 소스코드가 얼마나 바닥이 단단하게 만들어져 있는지를 먼저 살펴봐야 한다. 만일 그게 안 되어 있다면 지금이라도 늦지 않았으니 꾸준히 바꿔나가야 한다. 그게 바로 팀의 힘이고 팀의 능력이 된다.

덧붙임.
소스코드를 견고하게 만드는 건 정말 지루하고 답답한 작업이다. 잘 돌아가는 걸 바꾸는 것이라고 생각하기에 뭐하러 하냐는 생각이 들기도 한다. 그래서 난 그런 일을 불평없이 완벽하게 해 준 나의 동료들이 정말 고맙다.
'P군. 패킷 압축해서 전송하게 바꿔줘.'
'K양. 게임머니 처리하는 것 GET/SET으로 다 바꿔주세요.'
누구든지 짜증을 잔뜩 낼만한 일에 대해서 소스코드의 견고함의 필요성을 느끼고 그게 문제가 생기지 않도록 만들어 줬다. '수고했어요.' 라는 말이 항상 너무 부족하다고 느끼고 있다.
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://wangmul.egloos.com/1751696


'가장 일을 효율적으로 할 수 있는 팀원은 몇명이어야 할까?'라는 질문은 소프트웨어 개발이라는 것이 시작된 이래도 아직 아무도 해결하지 못한 대답이다.


갈락티코님의 피터몰리뉴에 대한 글을 보면 피터몰리뉴는 한 팀의 적정 인원을 20명으로 생각하고 있다.

90명이나 되는 던전키퍼의 제작인원이 피터 몰리뉴의 머리 속에 다 들어가 볼 수 있는 것은 아니지 않는가? 피터 몰리뉴는 자신이디자인한 게임을 팀원들을 이해시키기 위해서 노력하였으나 대규모 화된 게임팀안에서 커뮤니케이션하는 것은 여간 힘든 것이 아니었다.피터 몰리뉴는 자기가 무슨 게임을 만드는지도 모르는 팀 내의 다른 개발자들을 보면서 한심하기도 했지만 그들에게 일일이 게임내용을 설명할 때면 짜증이 나기 시작했다.
...중략...
피터 몰리뉴는 게임 개발사를 차리면서 한가지 결심을 하게 된다. 한 팀에서 20명 이상을 투입시키지 않겠다는 것이다.  가족 같은 분위기를 유지하고 긴밀한 관계 속에서 게임을 개발할 수 있는 개발 인력의 한계를 20명 정도로 생각했던 것이다.
(갈락티코님의 파퓰러스와 블랙엔화이트로 갓게임의 원조가 된 페이블의 피터 몰리뉴중에서)

20명이 적정인원인 이유. 참 뻔한 대답 아닌가? 그는 20명이 팀원이 커뮤니케이션을 하기 가장 적절한 팀원수라고 생각했기 때문이란다. 20명. 난 이 숫자를 보고 '그래 넌 진짜 거장이구나.'라고 무릎꿇어버렸다.

내가 지금까지 일해왔던 팀을 쭉 돌이켜보면 10명까지는 가족적으로 어찌어찌 지내볼 수 있었지만 10명이 넘어가면 가족적인 분위기가 사라지게 되고 15명이 넘어가면 팀원들끼리 매일 대화하기도 힘들어진다.

생각해보면 당연한 일이다. 게임팀에서 파트를 구성할 때 기획,서버,클라이언트,원화,모델링,애니메이터,배경이 기본 파트라고 할 때 한 파트가 2명 이상이 되게 되면 자연스럽게 [파트장과 파트원]의 관계가 되어버리고 파트원은 파트장하고만 이야기를 해도 일을 하는데 어려움이 없어진다. 다른 파트와의 대화를 파트장이 다 알아서 해 주는데 뭐하러 힘들게 다른 파트와 이야기를 하겠는가. 그리고 한국에서는 섣불리 이야기하다간 월권행위라고 이야기 듣기 일수인데.

다른 파트와 대화없이 일을 한다는 것. 사실 이게 뭐 중요하랴. 팀장이 프로젝트에 대한 이해가 높다면 프로젝트가 진행되는데 문제가 생기거나 힘들어지는 것은 아니다. 그리고 프로젝트가 실패하는 척도가 되지도 않는다.

걱정해야 할 것 단 한가지는 "왜 나는 이 일을 하고 있는거지?"라는 의문을 팀원이 가지게 해선 안된다는 것이다.

"왜?". 이 질문은 정말 중요하다.
이것은 자신의 업무에 대한 애정, 그리고 관심도, 집중도를 나타내주는 가장 중요한 질문이다. 답변은 수만가지가 될 수 있다.
"돈을 벌어야 하니까요.",
"내 스킬 향상을 위해 일을 해요.",
"팀원과 함께 일하는 것이 즐거워요."
이런 답변. 흔히 들을 수 있는 답변들이다.

그런데 위와 같은 식의 답변은 하루, 한달만 지나도 언제 사라질 지 예측할 수도 없는 답변들이다.
이런 답변들이 흐트러지더라도 팀원을 잡아줄 수 있는 단 한가지 답변은 바로
"이 프로젝트에서 저는 정말 중요하고 꼭 필요한 사람이니까요."
이다.

이런 대답을 할 수 있게 하려면 가장 먼저 선결되어야 하는게 뭘까? 당연히 우리 팀에서 만들고 있는 것이 어떤 것이고 나는 그 중에서 어떤 것을 담당하고 있는지 정확하게 알고 있어야 한다. 설마 이런것도 모르고 일을 하는 팀원이 있을까 하겠지만 다음 질문에 제대로 대답할 수 있는지 잘 생각해보자.

* 지금 일하는 팀에서 프로젝트 팀장이 생각하는 '이 게임에서 가장 재미있어야 하는 요소'가 어떤 것인가.
* '이 프로젝트에서 다른 것은 모두 제대로 동작하지 않아도 반드시 동작해야 하는 가장 중요한 것'은 어떤 것인가.
* 내가 담당한 업무중에서 일정이 부족해 두가지 중 한가지만 해야 한다면 그 한가지가 어떤 것인지인가.
* 내가 이 프로젝트에서 빠지게 된다면 어떤 부분에서 업무 손실이 생기게 되는가.

이 대답을 제대로 하지 못한다면 우리팀에서 만들고 있는 것이 어떤 것인지, 그리고 내가 그 중에서 뭘 담당하고 있는지 제대로 파악하고 있지 못하고 있거나 자신이 정말 팀에서 중요한 인물이라고 생각하지 않고 있다.
대답을 제대로 하지 못한다고 해서 스스로 탓할 필요는 없다. 이 질문에 대한 대답을 팀원이 자신있게 할 수 있도록 해주는 것이 바로 팀장이 해야 하는 일이고 팀원이 이 대답을 제대로 하지 못한다면 그건 팀장이 팀을 제대로 끌어가고 있지 못하고 있는 것이다.

팀에 적절한 팀원수는 몇명일까에 대한 해답은 바로 여기에 있다.

팀장이 모든 팀원들에게 위의 질문에 대한 대답을 자신있게 할 수 있도록 만드는 인원 수. 바로 그것이 적절한 팀원 수이다. 그래서 적절한 팀원 수는 팀장의 능력에 따라 달라지게 되고 최대 15명의 팀원을 이렇게 이끌 수 있다면 그것만으로도 대단한 것이라고 생각한다. 그래서 난 피터몰리뉴의 20명이라는 인원수가 놀랍기만 하다.

Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요

http://korean.joelonsoftware.com/Articles/PainlessSoftwareSchedules.html
Posted by leafbird 트랙백 0 : 댓글 0

댓글을 달아 주세요