현실과 혁신의 속도차이 by 김윤정

새로운 시도를 위한 체질개선. by antiegoist.

사실 혁신은 이전에도 내가 가장 좋아했고, 어떻게든 최신의 최강의 기술과 조직, 그러면서도 기본기가 탄탄한 그런 조직을 예전부터 원했었는데, 그걸 10여년 동안 여러 가지 방법으로 저질러보거나, 안주해도 보면서 여러 가지 경험을 쌓게 되었습니다.
(자랑같아서 조금 그렇지만, 나름대로 10여년 전 2D 게임 만들면서부터 각종 제작 방법과 노하우를 메뉴얼화 시키도록 노력했었고, 덕분에 국내에서 처음 나온 게임 그래픽 기술에 관한 서적에 참여했었죠. 그때까지 타일 제작과 프리렌더링 캐릭터 제작 프로세스는 구전밖에 없었고, 제 책으로 그런 기술을 처음 배웠다는 분을 만났을 때 깜짝 놀랐었습니다 )
그렇게 불탔던 예전에도 그때 나름대로의 최신의 기술과 조직을 시도해 본 적이 있었지요. 분명 그런 열정의 경험은 나중에도 도움이 되는 것이 사실이었지만, 문제는 그 방향이 모두가 이해하는 방향일 리는 없다는 것과 최신의 기술과 조직이 얼만큼의 장점이 생긴다면 그만큼의 단점도 동시에 생긴다는 것이었습니다.


예를 들어 SVN을 그래픽 데이터 유지에 도입하는 것은 대승적으로 이득이 되는 방법인건 사실입니다. 그래픽 데이터의 버전관리와, 마치 인터넷과 같이 유기적으로 백업되는 시스템. 데이터의 전달의 오류를 줄일 수 있고 프로그래밍이나 기획과의 호환도 편합니다.
그렇지만 그만큼의 단점도 존재하게 되는데, 일단 기본적으로 개인마다의 저장 경로나 형식을 통일해야 하며, 너무 큰 데이터는 SVN의 근본적 문제로 저장공간과 백업의 낭비와 전달 실패율, 그만큼의 작업부하를 유발하게 됩니다.(기본적으로 SVN은 프로그래머의 소스공유와 서브버전을 위해 만들어진 프로그램이기 때문이지요. 그렇다고 에일리언 브레인 같은 비싼 툴을 도입해 보자니 검증이 안되어서 불안했고..) 그렇게 하면서 개인의 자유도를 제한하는 일이 생길 수 있고, 가끔 SVN이 꼬이기 시작하면 대책이 없는 관계로 복구하는데 시간이 낭비됩니다. 그리고 개인 교육이 제대로 되지 않으면 유지가 엉망이 되어 버리기도 하지요. 익숙해져야 한다는 단점이 있는거죠.

그렇지만 그런 단점을 안고 가서라도 이런 툴을 유지하는 것은 분명 장기적으로 이득이 되는 방법입니다. 이것은 이러한 최신 기술만에 해당되는 문제는 아닙니다. 기본기를 키우는 것도 대승적으로는 이득이 되지만 당장 결과가 보이지 않거나 당장은 오히려 기존의 실력에 반해 실력과 속도의 하락을 유발할 수도 있습니다. 그야말로 장기적으로, 크게 생각하지 않으면 어떠한 혁신이건 '스트레스' 나 '쓸 데 없는거 벌여서 꼬장부리는 것' 이 될 수 밖에 없고, 나의 이런 생각을 모두가 공유하고 이해할 것이다 - 라고 기대하는 것은 대통령의 생각을 모든 국민이 이해할 것이라고 생각하는 것과 다를 바가 없습니다

그리고 이런 혁신의 시도로 많은 저항을 받아보았기도 했고, 팀원의 분열도 겪어 봤고, 반대로 신경쓰지 않고 내버려두면서 안주하는 모습도 다 겪어보았습니다. 그리고나니 확실히. 정치인의 마음이 무엇인지 이해하겠더군요.
오래 된 회사일수록, 조직구조가 바뀌지 않는 경우는 기본적으로 '안정상태'를 유지하게 됩니다. 사람은 누구나 안정을 추구하지요.물론 몇 명은 이대로 있으면 곤란하다라고 생각하지만, 그렇다고 조직을 개인이 어떻게 뒤집어 놓는다는 것은 보통 힘든 일이 아닙니다. 아니 힘든 일이 아닐 뿐만 아니라, 전체를 바라보지 못하는 지엽적인 입장에서는 무슨 일을 어떻게 혁신해야 전체의 방향과 다르지 않으면서 (혹은 전체를 혁신시키도록 유발하면서) 자신이 소속된 부분의 개혁을 강하게 추진할 수 있는지를 알기란 사실 불가능한 일입니다. 특히나 게임이란 영역은 서로 다른 부분의 영역이 상충되거나 반대되는 일이 너무나도 많습니다. 그걸 모두 이해하지 못하고 한쪽에서만 집중하게 되면 이미 흔적을 알 수 없게 된 많은 회사들처럼 균형을 잃고 쓰러지기 십상이지요.

때문에 이러한 시도는 매우 능구렁이처럼 신중하게 이루어져야 하며, 사람에 대한 정치적인 기반과 함께 효율적이고도 부담없는 방향으로 (급진주의적 입장에서 보면 겁쟁이라는 소릴 듣습니다만) 이루어져야 합니다.

일례를 들어 보지요. SVN의 사용은 분명 대승적으로 유용한 결과를 내놓는 단편적인 개혁의 한 일화라고 할 수 있습니다만, 물론 그만큼의 단점도 존재한다는것을 알 수 있었지요. 만약 그런 상태에서 어떤 관리자가 급진적으로 전 그래픽 직원이 내일부터 SVN을 사용해야 한다고 주장한다면 어떻게 될까요?
우리들이 게임 유저들을 향해 늘 하는말이 있습니다. '유저는 게으르다' 그렇습니다. 일단 사람들은 정체를 알지 못하는 변화를 두려워합니다. 물론 SVN 같은 경우는 프로그래머들 사이에서 워낙 정평이 나있는 툴이긴 하지만, 그렇다고 그래픽 디자이너들이 우리도 모두 그런 시스템으로 바꿔타야 한다고 주장하긴 힘듭니다. 오래되고 커다란 조직일수록 말이죠.

그렇다고 권력이 있는 사람이 그걸 급진적으로 진행해야 한다고 주장한다면, 분명 그 반대파가 생기기 마련입니다. (권력이 강대하여 말 못한다면, 뒤에서 생기게 됩니다. 가장 위험한 '뒷구멍파'죠 ) 그러면서 나타내는 반대파의 명분은 바로 그 새로운 시스템의 단점입니다. 이 단점을 부각시킨다면? 솔직히 답을 내놓을 사람은 없게 됩니다. 이쪽 말도 맞고, 저쪽 말도 맞기 때문이지요. 시스템을 바꿈으로써 생기는 혼란과 단점들을 생각하면 오히려 구식의 무식한 방법이 나을 때도 분명히 있기 때문입니다.
또한 심적으로 실제 사용하는 사람들의 동의를 이끌어내지 못하면, 결국에는 '시키니까 억지로 쓰긴 하지만, 결국에는 내 식대로 따로 한다' 라는 체계가 될 수도 있습니다. 아아 이건 정말로 비효율적이 되는거지요. 똑같은 일을 2번 하게 됩니다. 중요 권력자가 SVN을 쓰라고 지시했는데, A팀에서는 SVN은 중요 권력자에게 보고할때만 쓰고, 결국에는 팀장에게 수동으로 데이터를 보내는 일일보고 방식을 유지하는 등의 방법으로 이원화 시켜 버리기도 합니다.(!!!) - 비슷한 예를 먼 옛날에 보고서 작성때 본 일이 있습니다. 자신들이 사용하는 보고서 방식과, 위에 보고하는 문서를 두 번 작업했었습니다!! -    

즉 급진적 개혁은 사실상 낭비를 초래하게 되는 것이고, 이러한 실패를 한 번 겪은 조직은 다시는 혁신을 일으키지 않으려 하게 됩니다. 그러면서 혁신을 원하는 직원들은 결국 제 3자의 입장처럼 '여기는 나의 목표가 되는 곳이 아니야' 라고 하면서 '뭔가 더 잘 갖춰진' 곳으로 옮기려 합니다. 그들을 탓하기는 힘들죠. 그들은 아무것도 하지 않았고, 아무것도 할 수 없었을 뿐이니까요.

그러므로 혁신은 확실히 중간관리자가 아닌 더 윗 선의 관리직이 움직여야 부드럽게 움직입니다. 시초는 각 팀의 팀장이나 팀원이 될 수 있겠지만, 그것을 크고 부드럽게 움직여 나가기 위해서는 결국 리더급의 관리자가 혁신을 이해하고 움직여야 가능한 것입니다. 그러면서 사실 상당히 개혁은 완화되고 둥그렇게 되기도 하지요. 하지만 조급하면 조급할수록 안 좋습니다. 현재 나름대로 굴러가는 차를, 굴러가고 있는 동안에 뜯어고치는 일은 그렇게 만만한 작업이 아니니까요. (프로젝트를 실패해 본 경험이 있는 분들은 아시겠지만, 회사 조직이나 프로젝트가 한 번 삐끗해서 타격을 입으면 다시 복구하기는 거의 불가능할 정도로 힘듭니다) 하지만 작은 성공은 결국 팀원이나 회사 전체에 그것이 성공할 수 있고 개혁은 우리에게 유익하다라는 인식을 심어주게 된다면, 그 다음부터는 상당히 쉬워지게 됩니다.

그리고 그것이 반복하면 반복할 수록 개혁은 이상과 가까워지게 되고, 또한 현실과 융화/타협하면서 보다 실용적이 되어 가는 것입니다. 그리고 이것을 제대로된'정치' 라고 하며, 제대로된 '조직' 이라고 할 수 있습니다. 대통령이 추진하는 일은 결국 주변 참모들이 조사하고 결정한 일입니다. 그러나 추진하는 것은 대통령을 중심으로 추진하여야 하는 것이고, 대통령은 그것이 현실적이고 부드럽게 진행되기 위해 정치적으로 노력해야 하는 것이지요. 근본적으로 개혁이 필요하다라는 것을 인지하는 리더가 필요한 문제가 있지만, 사실 뭐 리더가 개혁이 필요없다면 그건 근본적으로 개혁 실패일 수 밖에요 -_-;;;

그 개혁의 방법은 종류와 긴급성에 따라 다르지만, 기본적으로는 역시 소규모 팀의 실험이 유리합니다. ...설명히 장황하고 모호해지는 것을 막기 위해 또다시 SVN 얘기를 하자면, 우선 선행팀이 SVN을 사용해 봅니다. 그 안에는 이 툴에 익숙한 팀원이 참여하고 있고, 나머지 4명이 일으키는 문제 정도는 이 익숙한 팀원이 해결해 나갈 수 있습니다. 그렇게 5명의 팀이 이런 하나의 '개혁' 의 효과를 소규모로 검증하고, 트러블슛팅을 할 수 있을 정도의 요원으로 자라나게 되면 이번엔 다시 10명으로 늘이고, 다시 20명으로, 40명으로 늘여가는 방식을 택하는 것입니다.
이러면서 개혁의 저항은 상당히 완화되고, 생겨날 수 있는 단점도 최소화시킬 수 있습니다. 덕분에 일반 직원들의 스트레스도 적당한 선에서 조절할 수 있게 되겠지요. 물론 경우에 따라 다른 방법을 사용해야 하므로, 이것은 하나의 단편적인 예일 겁니다.
때로는 급진적으로 모험이 필요할 때도 있으며, 때로는 개혁보다도 보수적인 익숙함이 더 이득이 클 때도 있습니다. 이것을 결정하는 것은 미묘한 것이며, 이 얘기까지 지금 쓰는 것은 무리이므로 줄입니다 ㅡ.,ㅡ ;;;

어쨌거나 근본적으로 발전하고 변화하는 모습을 계속 보이는 것은 중요합니다. 그리고 그 개혁은 지속적으로 성공해야 합니다. 프로젝트의 완료도 힘든 상황에서 개혁을 위해 대규모로 모험을 걸 회사는 없을테니까요. 개혁을 통한 이상적인 목표로의 진행도 중요하지만, 그만큼 중요하게 생각해야 하는 것은 안정입니다. 게임뿐만 아니라, 세상의 모든 조직은 이런 두 가지의 가치관을 가지고 저울질하면서 살아가고 있는 것이니까요.

덧글

  • 그레이오거 2010/03/22 12:33 #

    도전이 경계받는 이유는 적응기간동안 소모되는 비용과 실패시의 책임소재 때문입니다. 뒤집으면 비용을 각오할 이유가 있고 책임으로부터 자유롭다면 비교적 쉽게 혁신이 꾀해질 수도 있다는 말이 됩니다. 변화가 관리자(권력)로부터 시도될 경우 위험한 점이 자발적이기 힘들고(비용이 크게 느껴짐) 실패시 후폭풍이 일어난다는 점입니다. 만약 관리자의 직책이 너무 높아 후폭풍이 일어나지 않으면 오히려 무기력증이라는 더 위험한 상태가 될 수 있습니다. 따라서 말씀하신대로 모든 시도가 성공해야한다는 부담이 생기게 됩니다.

    어느 개발팀이든 막장이 아닌 이상 보통은 팀원들로부터 고른 신뢰를 받고 있는 개발의 중심인물이 존재하기 마련입니다. 이 신뢰라는 것이 무서운게... 예를 들어 프로그래머중 누군가 알파관련 질문을 받고 맥스파일을 수정해 해결했을 때, 신뢰받는 사람일 경우 '프로그래머가 맥스도 할 줄 아네. 내 일을 대신해주다니 고맙군.'이라는 평을 얻습니다만 그 반대일 경우는 '저 XX는 자기가 할 일을 나한테 미루고 있어!'소리를 듣고 맙니다. 이쁜 사람은 뭘 해도 이쁘고 미운사람은 뭘 해도 욕먹는 지극히 인간적인 현상이죠.

    아시다시피 신뢰란 긴 시간동안 점진적으로 쌓이는 '무적의 코인'입니다. 이런 사람이 도전을 시작할 경우 반발이 거의 없으며 오히려 능동적인 협조-그동안 신세 졌으니 까짓거 좀 도와주자-를 얻게 되고 실패하더라도 코인 하나 소모하는 것으로 끝납니다. 베스트 케이스는 '신뢰받는 중심인 == 관리자 == 권력자'입니다만... 그러기는 힘든 일이고, 관리자와 중심인이 계획적으로 협력하여 성공과 실패를 반복하며 한 파트씩 물들이는 방식이 기회와 위험의 적절한 trade-off로 보여집니다.

    최악의 케이스는 관리자와 중심인이 사이가 안좋고, 중심인으로부터 발언권을 뺏어오기 위해 관리자가 무리하게 개혁이란 이름으로 변화를 꾀하는 상황입니다. 결과는 대부분 같이죽자 형태가 되죠. 체계가 안잡힌 중소개발팀에서 의외로 자주 보이는 형태이기도 하지요. ㅡ,.ㅡ
  • 김윤정 2010/03/22 13:03 #

    후후후 같이죽자... 상당히 많이 봤습죠.
  • 2010/03/23 11:34 # 비공개

    비공개 덧글입니다.
  • 김윤정 2010/03/23 12:03 #

    넹 혁신도 좋지만 무리하게 진행하면 같이죽자의 모습밖에 되질 않더군요 ㅎㅎ
  • 청람 2010/03/25 17:44 #

    저희 회사서도 SVN을 적용한지 2년 정도 흘렀습니다.
    2년간 작업물들이 쌓이다보니 슬슬 그 전엔 없던 문제들이 나오기 시작하네요.
    이를테면 엄청난 양의 파일 갯수로 인해 트렁크에서 서버로 업데이트시 인덱싱 하다 서버가 뻗어버린다던가 하는...

  • 김윤정 2010/03/25 17:52 #

    그래픽 데이터용으로 svn 사용할때는 중간중간 백업을 해야겠다능..
※ 로그인 사용자만 덧글을 남길 수 있습니다.


MyADD

<script> (adsbygoogle = window.adsbygoogle || []).push({}); </script>