2011년 7월 17일 일요일

주먹구구를 더 좋아 하는 이유

이론과 실제는 다르다. 

모두들 착하게 살아야 한다는 것을 알지만 많은 사람들이 착하게 살지 않고, 운동을 해야 하는 것을 알지만 대부분의 사람들은 운동을 하지 않는다. 이유는 다 있다.

착하게 살고 꾸준히 운동을 하는 사람들은 꾸준히 하다보니 특별한 목적보다도 그 자체가 좋아하고 자연스러운 행동이 된다. 

소프트웨어 회사도 주먹구구식으로 개발하면 안되고 체계적으로 개발해야 한다는 것을 이론적으로는 알아도 그 구성원들은 막상 체계적으로 변화를 하려고 하면 완전히 적응되기 전까지는 크고 작은 거부감과 저항이 있게 된다.

그래서 주먹구구로 회기하려는 힘이 강하게 작용하게 된다.

많은 회사들은 자신의 회사는 주먹구구가 아니라고 생각할 것이다. 물론 Black and White로 구분할 수는 없지만 나의 경험에 의하면 우리 나라 소프트웨어 회사의 90% 이상이 주먹구구에 가깝게 개발을 하고 있고 나머지의 대부분은 체계적인 개발을 하려고 노력하고 있으나 너무 과해서 더 효율성이 떨어지거나 회사에 알맞는 체계를 갖추고 있지 못하다. 정말 극소수의 몇개의 회사들이 효율성 높은 체계를 가지고 있고 문화적으로 자리를 잡고 있다.

여기서는 주먹구구에서 벗어나기 어려운 장애 요인은 무엇이 있나 알아보자. 시간이 흐르고 자리를 잡으면 별거 아닌 것들이지만 변화에 대한 거부감들은 의외로 매우 강한 경우가 많다.

주먹구구로 계속 개발을 하다보면 초창기에는 특공대처럼 놀랄만큼 좋은 성과를 내지만 인원이 많아지고 프로젝트의 규모가 커지면서 프로젝트는 점점 늦어지고 문서는 여전히 거의 없고 정보는 공유가 안되고 회사가 도대체 어떻게 굴러가고 있는지 잘 파악이 안된다. 제품이 버그는 점점 많아지면서 고객의 신뢰를 점점 잃어가는 위기를 겪게 된다.

이를 극복하기 위해서 소프트웨어 회사가 체계를 제대로 갖춰가면 
개발 프로세스를 정립하고 
프로젝트를 수행하면서 문서를 만들고 
조직을 전문화하고
기반 시스템을 구축하고
공유 등 개발 문화를 정착시키기 위해서 애쓴다.

단어적으로 보면 아무도 거부할 것이 없지만 실제로 많은 저항에 부딛히게 된다.
제대로 정착하면 장점으로 가득차 있지만 오로지 단기적인 시각으로 단점만 보면 다음과 같은 것들이 있다.

 개발자

개별 개발자들이 과거에는 파워라고 생각했던 것들이 많이 줄어들게 된다.
과거에는 제품, 기술에 관련된 것들은 모두 개발자에게 물어 봐야 하고 개발자의 은총을 받아야만 일들이 진행이 되었다.
심지어는 프로젝트가 언제 끝나는지도 아무도 모르지만 개발자가 열심히 해서 끝내주기만 기다리곤 했다.
하지만 이제는 문서화를 통해서 제품의 스펙도 이미 다 공유가 되어 있고 개발자에게 물어볼 일들이 점점 줄어 들게 되었다. 개발자들은 이렇게 할 수 있도록 스펙(SRS)을 작성하는 일이 짜증나는 일이 됬다. 
나중에 마음에 내키는 대로 개발도 할 수 없게 된다.
과거에는 개발자에게 요청할 것이 있으면 직접 와서 부탁을 해야 했지만 이제는 시스템에 모두 등록이 되어서 개발자들이 이슈 처리를 잘하고 있는지 못하고 있는지 만천하에 드러나게 되었다.
소스코드를 수정한 것도 한줄한줄 완전히 투명하게 공개가 된다.
프로젝트를 진행할 때도 일정이 너무 상세하게 관리되어서 압박이 심하다.
개발자가 한두명이 퇴사를 해도 회사는 잘 굴러갈 것 같은 체계로 가고 있는 것들이 개발자는 불안해지고 파워를 점점 잃는 것을 거부하게 된다.

 영업

과거에는 프로젝트를 할 때 별로 할 일이 없었다. 
개발자들이 SW를 만들어 주면 알아서 팔기만 하면 되었는데 이제는 스펙이라고 작성해와서 몇백페이지나 되는 문서를 꼼꼼히 읽어보고 사인을 하라고 한다. 그리고 나중에 잘못된 내용이 있으면 책임 지라고 한다.
개발이 힘들고 돌아다니는 것이 좋아서 영업을 하는데 공부는 개발자만큼 해야 하나보다.
고객의 요청도 개발자에게 가서 무조건 우기면 제품에 반영해주고 했는데 이슈관리시스템에 자세히 적어야 하고 내용이 만천하에 드러나므로 무조건 우길 수도 없게 되었다. 

 경영진

옛날에는 내용을 파악하려면 담당자에게 와서 보고하라고 하면 되는데 이제는 시스템에서 확인해야 한다. 이게 더 좋다고 하지만 나는 영 불편하다.
프로젝트를 진행할 때 무조건 야근과 주말작업을 강요했는데 체계화 되면서 그러기 어려운 분위기가 되어가고 있다.


 마케팅

옛날에는 제품 기능 목록 주욱 적어주면 개발자가 개발하고 이렇게 간단했는데 제품 기획을 제대로 하느라고 힘들다. 모든 내용이 문서화되고 시스템에 남기 때문에 나중에 딴 소리를 할 수 없다. 


 결론

물론 모든 구성원이 이런 저항감을 가지는 것은 아니다. 변화의 필요성을 잘 알고 적극적으로 변화를 이끄는 많은 사람들이 있다. 이런 구성원이 많다면 회사는 계속 번창해 나갈 것이다. 회사의 분위기와 상황에 따라서 매우 다르다.

하지만 많은 회사들이 이런 이유들 때문에 많은 저항에 부딪혀서 적당한 정치적인 타협으로 기형적인 구조가 되어서 망하는 길로 들어서게 된다. 이러한 저항은 특이한 현상도 아니고 아주 자연스런 현상이다. 이러한 조직 구성원은 잘못된 생각을 가지고 있는 것이 아니고 인간의 자연스러운 본성에 가깝다. 따라서 이를 비난할 수는 없고 이들을 계속 이끄는 것은 회사의 책입니다.

이 고비를 넘어가면 회사의 모든 구성원들에게 그 혜택이 돌아가고 과거에는 어떻게 그렇게 일했는지 모르겠다고 회상하는 때가 온다. 그 중에서도 개발자에게 돌아가는 혜택이 가장 크다고 할 수 있다. 개발자에게 돌아가는 가장 큰 혜택의 개발자의 몸값을 높여준다는 것이다. 

나는 주먹구구 식으로 밖에 개발을 하지 못하는 개발자에게는 20년 이상의 경력이 있어도 연봉 5천도 아깝다. 하지만 체계적인 개발이 몸에 베어서 스펙도 잘 쓰고 설계도 잘하며 공유, 리뷰 문화에 익숙한 개발자는 연봉 1~2억도 아깝지 않다.

체계적으로 바꿔갈려면 감당할 만큼씩 단계적으로 변화를 해야 한다. 보통의 중소기업이 이렇게 단계적으로 변화를 하려면 2~3년 정도의 시간이 걸리고 대기업은 훨씬 더 오래 걸린다. 
또한 그 과정에서 뻔히 보이는 저항에는 굴복하지 말고 슬기롭게 헤쳐나가야 한다. 여기서 가장 중요한 것은 최고경영자의 통찰력과 의지이다. 그래서 최고경영자의 책임은 더욱 무겁다.

댓글 11개:

  1. 참... 언제나 읽으면서 느끼는건데 여기 포스트의 대부분은 책임을 하위 직원들에게 지우는 묘한 뉘앙스가 들어있네요...
    야근야근을 면치 못하는 IT회사가 거의 대부분인게 우리나라입니다.
    이게 뭘 뜻하는지 아실텐데요..
    애초에 기본적인 문제조차도 해결되지 않은 나라에서 각 파트의 구성원들이 또 손해를 감수하고 내부 구조를 바꾸도록 노력한다?
    주먹구구식밖에 못배운 배테랑 개발자의 책임이 본인에게 한정되는걸까요?

    어떤개발자도 주먹구구식을 좋아하지 않습니다 대게는 자신들이 힘들어진다는걸 개발자들은 알아요.
    그럼에도 그런 분위기가 유지되는게 가발자탓일까요 경영진 탓일까요?

    답글삭제
  2. 음, 제가 보기에는 처음에는 개개인의 능력(특히 개발자의 능력)이 중요시돠다가 회사가 커짐에 따라 시스템, 제도, 어떠한 프로세스를 만들게 될 수 밖에 없고, 이에 따라야 한다는 얘기를 하시는 것 같은데요. 개발 같은 경우를 보더라도 초기 개발에서는 코딩 규칙이나 함수 명명법, 유닛 분할법등에 대한 방법론이 없지만, 시간이 가면 갈 수록 cowork이 중요시하게 되고 이러한 제도(규격)를 만들어 가게 되죠.

    저 또한 source code version 관리도 하지 않았던 예전과 비교해서 요즘에는 그나마 이런 저런 프로세스를 스스로나마 구축해 가고 있답니다. 어찌 보면 일종의 구속이죠. ^^

    답글삭제
  3. 이경문님 안녕하세요.
    이경문님 회사같이 감당할 만큼의 변화를 해가는 것도 좋은 방법입니다. 하지만 어떤 회사는 급격한 변화를 해야할 수 밖에 없는 경우도 있습니다. 특히 대기업이 이런 방법을 많이 쓰는데 대부분 잘 적응을 못합니다.
    또 어떤 경우는 너무 천천히 변화를 해서 결국에는 어정쩡한 상태가 되기도 합니다.
    결국 가능하면 처음부터 제대로 된 체계를 갖추고 시작하는 것이 좋고 그렇지 않으면 현재 회사에 맞는 속도와 방법이 필요합니다.

    답글삭제
  4. 안녕하세요. black_H님
    제 블로그를 많이 읽어보시면 그 책임은 회사에 대부분 있다는 말들을 많이 볼 것입니다.
    이 글은 또다른 측면을 보는 겁니다.
    누구의 책임이냐는 것이 아니고 자꾸 과거로 회기하려는 속성을 말하는 것이고 실제로 많이 존재합니다.
    우리나라에는 피해의식을 가지고 있는 개발자들이 많습니다. 그만큼 회사에서 해준것이 별로 없는 경우가 많기 때문입니다.
    또한 개발자가 변화에 거부감을 가지고 있는 것도 자연스러운 현상입니다. 하지만 이러한 거부감에 밀려서 변화를 포기하는 것 또한 회사의 책입니다.

    답글삭제
  5. 문제는 '개발을 즐길 준비가 되어 있냐?'인지 모르겠네요.
    스트레스를 받아가며 새로운 것을 수용하기는 힘들지 모릅니다. 내가 즐기기 위해서 좋은 버릇을 만들어야 한다로 보면 어찌보면 쉬운지 모릅니다. 현재 우리가 생명유지를 위해 물질적 만족을 위해 원하지 않는 개발자로 살고 있는지 먼저 생각 해 봐야 할지 모릅니다. 그리고 나면 내가 현재 만족하고 있느냐가 될거고 그리고 나서 수용하는 것을 두려워 하지 않겠죠. 원인은 스트레스이고 그 스트레스의 원인은 자기 정체성인지 모릅니다. 하고 싶은 것을 위해서 과감히 자신을 바꾸는자 생각을 하는 사람이 많지 않는 것이 현실인지 모릅니다. 거꾸로 자신을 바꿀 수 있는 테스트에서 시작하면 자신의 꿈을 찾고 도전하는 기회가 될지 모르겠네요.

    답글삭제
  6. 전체의 문제인데, 그 전체 구성원 중 하위직원이 많다면, 각 개인의 문제는 %가 다르겠지요.
    전 항상 느끼는 것이지만, 전체 구성원이 모두 이해하고, 같이 잘하기 위해 노력해야 한다고 이해됩니다.

    현실 세상에서 아래로 책임을 미루는 그런 조직도 있는 반면에, 제대로 해보려해도, 방법을 몰라 헤메는 그런 조직이 더 많다고 봅니다.

    그리고 근본적으로 책임은 회사와 대표이사가 집니다.
    물론 악독 사주도 있지만...

    답글삭제
  7. 개발자가 편해지려면 체계를 갖추는 것이 좋지만
    다르게 말하자면 개발자들이 너무나 많은 부분을 감당하고 있고
    급여 이상의 일을 하고 있다는 의미도 되지 않을까 생각을 합니다.


    결론은 개발자들도 자기 할일만 하고 대신 권력을 약간 포기하면 편해지려나요? ㅋ

    답글삭제
  8. 구차니님 안녕하세요.
    아시다시피 개발을 제대로하려면 개발자는 개발에만 집중해야 합니다. 권력, 관리나 다른 잡일에 신경써가면서도 개발도 잘할 수 있을 만큼 개발이 만만하지 않습니다.
    개발자의 경쟁력은 개발 실력이기 때문에 그리고 개발을 잘하는 개발자가 더 좋은 대접을 받아야 합니다.
    지금은 어찌보면 과도기인데 점차 인식이 바뀌어 갈 것으로 생각합니다.

    답글삭제
  9. 제 1 의 목적은
    결국엔 좋은말로는 한사람에게 권한이 집중되지 않게 하겠다는,
    경영진의 의도겠지요. 정치의 가장기본인 힘의균형을 유지하는 것이겟지요.

    의도는 좋을지 몰라도
    나쁘게 말하자면 기술자, 개발자는 언제든지 갈아 엎을수 있는 환경을 만드는 것이기도 하고요.
    저게안되면 최소한 단가라도 깍을수 있는 환경을 만들수도 있고요.


    요즘 뿐만 아니라 우리나라는 대체로 기술을 천시하는 경향이 있어서, 이런 이론이 찬사를 받을 소지가 다분합니다.

    통제에만 집중되있죠.


    일명 빅 3라는곳에서 시작된 통제로인한 프리랜서 개발의 패해가 요즘 은행사태나,
    교육시스템인 neis 에서 고스란히 드러나는건 아닌가합니다.


    잘못된 방향으로 관리가 되어진다는 의미지요.
    영어공부만 하는 사람들이 개발관리가 재대로 된까요?
    갑이니깐 가능한겁니다.

    기술천시현상의 고착화로 인해 요즘은 쓸만한 개발자들이 줄어들고 있습니다.


    그러나 여기 대부분 포스트들의 이론대로라면, 프로세스가 잘잡혀있으면
    개발자는 언제 든지 갈아 엎을수 있고, 대처될수 있겠지요.

    기술회사에게 있어서 기술이 제 1 번째 요소임을 잊어서는 안 될 것입니다.
    개발을 모르는 사람이 관리를 한다?

    과연 재대로 된 개발자 통제가 될까요?
    과연 저게 프로세스가 좋아서 현재 관리가 되고 있을가요?
    솔직히 말해서 빅3가 외주업체 관리는 되겟죠.
    왜냐면 갑이니깐요.
    프로세스라는 명목하에 희생되고 있는 수많은 개발자들의 피와땀을 잊어서는 안될것입니다.

    같은회사에서 위의 환경같이 개발을 전혀 모르는 사람이 기획하고, 일정산출하고, 개발자에게 지시하고
    솔루션을 개발한다면 관리가 될까요?

    여기글들에 해당하는건 솔직히 우리나라 빅3에게서만 해당되는 이론같습니다.

    외국을 보세요 한결같이 성공한 기업들은 기술력이 뒷받침 되는 회사들입니다.

    우리나라 IT>? 죄다 SI입니다.
    갑을 구조를 이용한 인력장사지요.

    그러니 프로세스가 중요하죠.
    모르는 분야의 기술자를 통제해야하니깐요.

    우리나라식의 개발 프로세스가 잘되어 있다는것은 다른말로하면 창의력의 말살입니다.
    현재 그문제점이 고스란히 모바일 쪽에서 드러나고 있죠.

    그래도 아직까지는 통제로 재미를 보아왓기에, 그습성을 못버리고 언론통제라는 것만 해대고 있죠 아직도.

    어느정도 까지 개발자 이탈현상이 진행될지 모르나, 그 책임은 전적으로 현 구조를 만든 빅3의 책임이라는것이 제 개인적인 생각입니다.

    얘기가 좀 삼천포로 빠진 경향도 있는데.

    무조건적인 프로세스 맹신또한 위험하다는게 제 생각입니다.
    더군다나 창의력을 요하는 작업에서는요.

    답글삭제
  10. 좋은 글 잘 읽었습니다. 글에서 보이는 통찰력을 통해 많이 배웁니다. 문화는 곧 습관의 문제라고 이해가 됩니다. top down 으로는 회사 경영진등이 좋은 개발 문화에 대한 이해를 하고 지원을 해줘야 될 것 같고, bottom-up 으로 생각을 해보면 개발자 개개인이 변화를 위해 노력해야 될 것 같아요. 이런 변화를 어떻게 이끌어 내야 하는지 무척 궁금합니다.

    답글삭제
  11. gsong님 안녕하세요.

    경영진이 할 일은 교육 등을 통해서 마인드를 바꾸게 해주는 일을 먼저 해야 합니다. 그리고 당근과 채찍을 통해서 강제화도 하고 포상도 해서 자연스럽게 자리잡도록 해야 합니다. 시간도 2~3년은 투자를 해야 바뀐 모습이 느껴집니다.

    답글삭제