4.9 총선의 거친 바람에 변두리 블로그가 휩쓸릴까 두려워 포스팅도 자제하며 한달동안의 은둔생활 마치고 컴백. 블로그에 글 쓰기 싫어 빈둥대던 때에 적절하게 국가적인 행사로 핑계꺼리 만들어주니 어찌나 고마운지.
한달동안 쉬면서 뭘로 머리 들이밀까 고민하고 있던 차에 적절한 동영상 발견
광고에 대한 이야기이지만 이게 어찌 광고만 해당되는 이야기겠는가. 어디든 마찬가지인 이야기.
개발자가 제일 무서워 하는 이야기는 "이건 아니야! 그러니까 새로 만들어!"가 아니다.
신입일때야 이 이야기가 제일 무섭지만 2,3년쯤 지나게 되면 적어도 윗 사람이 그렇게 이야기할 때는 '만드는 기간이 좀 길어지더라도 내가 널 지켜줄테니까 걍 다시 만들어.'라는 의미도 포함하고 있는 것이다. 만일, 이런 의미를 포함하지 않고 다시 만들라고 하는 것이라면 평생 고생할테니 회사를 그만두거나 다른 팀으로 빨리 옮기는게 좋다.
정말 무서운 이야기가 "괜찮긴 한데 이게 좀 부족해. 그걸 이렇게 바꿔봐"이다.
이 이야기의 배후에는 '그정도 고치는 건 2,3시간이면 충분하지? 일정 변경은 없다.'라는 의미가 포함되어 있다. 별거 아닌 수정이니까 부담가지지 말고 그냥 고치라는 것이다보니 반박하기가 정말 힘들다. 어쩔 수 있나. 야근하면서 고쳐야지. 그런데 정말 무서운 이유는 몸이 힘들어지기 때문이 아니다.
이런 "윗사람이 보기에 별거 아닌 변경"이 가져오는 정말 큰 문제는 본질이 바뀐다는 점이다. 원래 의도가 뭐였는지 알 수 없어진다. 결국 이것은 개먹이 광고에 강아지에게 출연 기회조차 주지 못하게 되어버리거나 도대체 뭘 재미있게 하라는 것인지 도저히 알 수 없는 게임을 만들어버리게 된다.
개구리를 솥 안에 넣어두고 물의 온도를 서서히 높이게 되면 뜨거워지는 지도 모르고 죽는 것 처럼 이런식의 작은 변경이 계속되다보면 결국 "내가 뭘 만들고 있었지?"가 되어버린다.
"이거 조금만 바꿔보지?"라는 의견이야말로 그게 정말 필요한 것인지 아닌지 꼭 생각해봐야 한다. 작은 변경은 반드시 나비효과로 돌아온다.
한달동안 쉬면서 뭘로 머리 들이밀까 고민하고 있던 차에 적절한 동영상 발견
광고에 대한 이야기이지만 이게 어찌 광고만 해당되는 이야기겠는가. 어디든 마찬가지인 이야기.
개발자가 제일 무서워 하는 이야기는 "이건 아니야! 그러니까 새로 만들어!"가 아니다.
신입일때야 이 이야기가 제일 무섭지만 2,3년쯤 지나게 되면 적어도 윗 사람이 그렇게 이야기할 때는 '만드는 기간이 좀 길어지더라도 내가 널 지켜줄테니까 걍 다시 만들어.'라는 의미도 포함하고 있는 것이다. 만일, 이런 의미를 포함하지 않고 다시 만들라고 하는 것이라면 평생 고생할테니 회사를 그만두거나 다른 팀으로 빨리 옮기는게 좋다.
정말 무서운 이야기가 "괜찮긴 한데 이게 좀 부족해. 그걸 이렇게 바꿔봐"이다.
이 이야기의 배후에는 '그정도 고치는 건 2,3시간이면 충분하지? 일정 변경은 없다.'라는 의미가 포함되어 있다. 별거 아닌 수정이니까 부담가지지 말고 그냥 고치라는 것이다보니 반박하기가 정말 힘들다. 어쩔 수 있나. 야근하면서 고쳐야지. 그런데 정말 무서운 이유는 몸이 힘들어지기 때문이 아니다.
이런 "윗사람이 보기에 별거 아닌 변경"이 가져오는 정말 큰 문제는 본질이 바뀐다는 점이다. 원래 의도가 뭐였는지 알 수 없어진다. 결국 이것은 개먹이 광고에 강아지에게 출연 기회조차 주지 못하게 되어버리거나 도대체 뭘 재미있게 하라는 것인지 도저히 알 수 없는 게임을 만들어버리게 된다.
개구리를 솥 안에 넣어두고 물의 온도를 서서히 높이게 되면 뜨거워지는 지도 모르고 죽는 것 처럼 이런식의 작은 변경이 계속되다보면 결국 "내가 뭘 만들고 있었지?"가 되어버린다.
"이거 조금만 바꿔보지?"라는 의견이야말로 그게 정말 필요한 것인지 아닌지 꼭 생각해봐야 한다. 작은 변경은 반드시 나비효과로 돌아온다.
태그 : 게임개발



덧글
kkamagui 2008/04/19 13:40 # 삭제 답글
방금 글을 읽으면서 깜짝 놀랐습니다. @0@ 회사에 있으면서 가장 듣기 싫었던 말이 "이거 조금만 바꾸자" 였는데... 정말 공감이 가는 글입니다. 조금만 바꾸니까 일정의 변경도 없고... ㅜ_ㅜ... 나중에 프로그램은 엉망이 되는거죠.정말 이런 일 좀 없었으면 좋겠습니다. ^^
영두리 2008/04/19 15:19 # 답글
잘 봤음..뜨끔하면서도 심히 공감함.
꼬니 2008/04/21 23:18 # 삭제 답글
공감가는 영상과 글입니다..잘 보고 잘 읽고 갑니다.
쩌비 2008/04/22 09:34 # 답글
이거 저도 후배에게 이런짓을 하고 있는것은 아닌지, 걱정이 됩니다.
굴돌 2008/04/22 10:32 # 답글
또 문제가 되는게...보통 중간에 수정한 것들은 전체에 미치는 영향을 완벽히 파악하지 못한다는 것이죠.
좀 안좋은 예이긴 합니다만,
이름 속성에 쉼표를 넣지 못하도록 했었는데
관리자가 자기는 성과 이름 사이에 쉼표를 넣는다는 이유로 쉼표를 허용하도록 했을 경우...
어디선가 여러 사람이름을 나열할때 csv로 표현한다고 했을 경우에는 그 쪽에서 버그가 생기게 되죠...
물론 이런 부분은 문서화를 잘 하면야 되겠지만...
기능 하나 바꾸면 속성명세서에서부터 클래스 다이어그램까지 싹 바꿔주고...
또 그러면 모양이 바뀌니까 이쁘게 모양도 맞춰줘야 하고...
그러다보면 1시간 코드 수정하고 3시간 테스트하고 3시간 문서 수정을 해야 하는...그러고 나서도 어디서 문서가 실제와 어긋나는지도 모르게 되는 상황이 되어버리죠.
뭐 유닛테스트에 소스코드를 문서처럼! 문서는 자동생성툴로~
라고 해봤자 애초에 유닛테스트로 모든 테스트를 할 수도 없고, 관리자는 소스코드따위 관심 없으며, 자동생성된 문서는 문서로 쳐주지도 않아서 어차피 수작업을 해야 하는 등등...
피곤하죠 =.=
붉은울림 2008/04/23 12:04 # 답글
링크는 제가 데려가겠습니다..
도이모이 2008/04/29 09:12 # 삭제 답글
ㅋㅋㅋ. 재미 있네요. 일하는 방식은 어느 나라나 동일한거 같아요... 어느 조직의 특성상 어쩔 수 없는 듯.
codewiz 2008/04/30 15:29 # 삭제 답글
보고 한참을 웃었습니다.정말 완전 공감 가네요...ㅋㅋㅋ
왕멀 2008/05/06 14:41 # 답글
kkamagui님 // 요구사항 변경이라는 것은 당연히 있는 것이라고 생각하지만 대놓고 하는게 아니라 별거 아닌 것처럼 하는 변경에 대한 주의는 확실히 필요하다고 생각한답니다.영두리님 // 웃... 잘 봐주셔서 정말 감사해요 ^^
꼬니님 // 감사합니다~
쩌비님 // 항상 주의주의주의 하고 있답니다.
굴돌님 // 적절한 예를 들어주셨네요. 처음부터 반영하지 못했다는건 잘못된 것이긴 하지만 작은 수정이 정말 전체를 건드리지는 않는 것인지 신중하게 판단할 필요가 있다고 생각합니다.
붉은울림님 // 옛
도이모이님 // 다른 나라에서도 같은 일이 일어나고 있다는게 정말 재미있었답니다.
codewiz님 // ^^ 하하 정말 재미있는 동영상이예요.
김재호 2008/05/30 19:52 # 삭제 답글
쿠쿠쿠쿠 정말 공감가네요^^
소천환 2008/06/02 01:59 # 삭제 답글
아하.. 정말..대박 작품이 나왔군요..
역시.. 힘이 하나로 모아지면..
ㅡ_ㅡ; 엄청나군욤.. 훕~
잘보고 갑니다 ^^ ㅎㅎ
달룟 2008/06/14 23:51 # 삭제 답글
반대하던걸 옹호하는 작가의 모습이 좀 슬프네요. 일단 만들고 나면, 안고쳤으면 하는 마음이 드러나는군요.
오현석 2008/11/23 22:47 # 삭제 답글
하하하~ 잘 봤습니다. 정말 공감가는 내용이네요~ 지금 저의 모습이 아닐런지...퍼~ 갑니다 ^^
heestory.k 2008/12/01 11:58 # 삭제 답글
하핫..공감가는 내용이네요-..동영상이...ㅋㅋ
점점 군더더기가 많아지는 코드처럼... 완벽한 비유군요-ㅋㅋ
잘 보고 가요~ㅎ