태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

이슈관리시스템을 쓰면서 일이 더 많아졌다.

2011/07/20 00:22 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이슈관리시스템을 쓰기 시작하면서 일이 오히려 더 많아졌다고 하소연하는 경우들이 많다.

이슈관리시스템을 쓰지 않다가 또는 전사적으로는 쓰지 않고 소수의 팀내에서만 쓰다가 이슈관리시스템을 전사적으로 제대로 쓰기 시작하면서  일이 더 많아졌다고 하곤 한다.

이것은 오히려 긍정적인 신호이다. 이슈관리시스템을 쓰지 않고는 회사내의 모든 이슈를 다 표면위로 드러낼 수도 없고 관리도 할 수 없다.

일이 많아졌다고 느끼는 것은 절대적인 일이 늘어난 것이 아니고 숨어 있던 이슈들이 모두 공유된 것 뿐이다. 이슈관리시스템이 없다면 잊혀지거나 개인이 알아서 챙기다가 유야무야되는 이슈들이 매우 많다. 이슈관리시스템은 모든 이슈들이 등록이 되고 개인의 의지에 따라서 해결이 되고 안되고가 결정이 되는 것이 아니고 전사적으로 공개적으로 처리가 된다. 물론 많은 이슈는 처리하지 않고 해결하는 것으로 종료된다.

이슈가 빠짐없이 처리되는 것은 물론 이슈를 처리하는 과정은 완전히 투명하게 공개가 된다.

억지주장을 해도 모두 알게 되고 요청을 무시하거나 늦장을 부려도 누구나 알 수 있다. 완전히 투명하게 업무가 진행된다. 투명한 업무처리를 싫어하는 사람들은 이를 꺼려할 수는 있지만 전사적으로는 대단히 큰 강점이 된다. 

따라서 이슈관리시스템에는 버그 뿐만 아니라 업무요청, 자료요청, 새로운 아이디어 등 온갖 이슈는 모두 등록하는 것이 좋다. 또한 이슈관리시스템을 사용하면서 전화로 구두로 요청하는 것은 거의 없애야 하면 이슈를 공유하고 논의하는 회의의 대부분은 사라져야 한다. 회의에 불려가는 시간도 줄어야 하며 전화나 구두로 요청하는 인터럽트도 많이 줄어야 한다. 이렇게 세이브된 시간은 쉬거나 좀더 창의적인 일을 하는데 쏟는 것이 좋겠다.

이슈관리시스템은 전사적으로 제대로 쓰는 것만으로도 회사의 개발문화에 많은 변화를 가져온다.

 * 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
 joomlatools
저작자 표시 비영리 변경 금지

전규현 기반시스템/버그관리 개발문화, 이슈관리

Trackback Address: http://allofsoftware.net/trackback/228 관련글 쓰기
  1. 이제 블로그 댓글에서 점점 Facebook 댓글로 옮겨 가고 있군요. ^^
    좋은 현상일까요?

  2. 아무래도 눈에 당장 들어오는게 페이스북 댓글이니까 더 손이 많이 가지 않을까요? ㅎㅎ 이름/비밀번호/홈페이지 이런거 일일이 입력하지 않아도 되구요. :)

  3. 페북계정은 있지만 웬지 정감이 안더라구요 ^^;

    음.. 일단 공론화 되는게 유쾌하지 않은 사람들이 많다는게 문제지만
    보이지 않는다고 다루지 않아도 될 문제는 아니니 바쁨을 즐겨야 할것 같아요 ㅎ

  4. 구차니님 안녕하세요.
    전 페북은 지인들과 소식 전하는 개인 용도로만 쓰고 있습니다. ^^

  5. 일반 블로그 댓글의 가장 큰 문제점은, 자기가 댓글을 단 글에 댓댓글이 달린 것을 알 수 없다는 점입니다.
    페북댓글을 사용하게 된 가장 큰 이유는 이 문제 때문 아닐까요?

  6. 안녕하세요. 이린님
    댓글알리미에서 제가 다른 블로그에 댓글 단것에 또 댓글이 달리면 알려주더군요. 그게 그 기능이 아닌가요? 되는 블로그가 있고 안되는 블로그도 있을 수 있겠군요.

  7. 이슈가 공유되서 일이 많아졌다는 것에 전적으로 공감합니다.

    이슈 관리 시스템을 쓰다보니 확실히 일이 좀 늘긴 했는데요,
    가만히 생각해보면 그간 잊혀지고 사라졌던 이슈들이 그대로 남아있기 때문이더군요.

    좋은 글 항상 잘 보고 있습니다. ^^

  8. 안녕하세요. kkamagui님
    항상 글을 읽어주셔서 감사합니다.

  9. 좋은 글입니다. 일이 많아진 게 아니라 드러나지 않던 게 드러나는 거란 통찰이 멋진 것 같습니다.

  10. 안녕하세요. 녹풍님
    반갑습니다. 이슈관리시스템 잘 쓰고 계시나보죠?

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

2011/07/17 11:15 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



이론과 실제는 다르다.

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

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

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

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

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

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

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

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

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

 개발자

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

 영업

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

 경영진

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

 마케팅

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

 결론

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

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

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

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

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

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by 
Leopostle
 
 
저작자 표시 비영리 변경 금지

'개발문화' 카테고리의 다른 글

우리 식대로  (1) 2011/10/30
우리나라 소프트웨어 회사에는 ???이 없다.  (4) 2011/07/30
주먹구구를 더 좋아 하는 이유  (11) 2011/07/17
나쁜 습관  (2) 2011/06/19
내가 소스코드를 몰래 고치는 이유  (13) 2011/02/01
평가를 어떻게 해야 할까?  (4) 2011/01/18

전규현 개발문화 개발문화

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

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

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

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

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

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

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

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

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

  6. Blog Icon
    아리스토

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

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


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

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

  9. Blog Icon
    설성운

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

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


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

    통제에만 집중되있죠.


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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

  11. gsong님 안녕하세요.

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

매일 불난 호떡집 같은 회사 (중요한 일 vs. 시급한 일)

2011/01/03 16:25 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed



필자가 컨설팅을 진행했던 수많은 회사들 중에서 80% 이상은 불난 호떡집처럼 매일 불끄느라고 정신이 없습니다.
  • 너무 바빠서 새로운 기술을 연구할 시간도 없다고 한다.
  • 프로젝트를 진행할 때도 가장 빠른 방법으로 문서도 작성하지 않고 가장 뛰어난 개발자가 바로 코딩부터 한다고 한다.
  • 고객들은 기다려주지 않기 때문에 요구하자마자 바로 며칠 안에 제품에 기능을 반영해야 한다고 한다.
  • 제품에 버그가 발견되면 하루 이틀 안에 버그를 수정해줘야 한다. 그렇지 않으면 고객들이 엄청나게 컴플레인을 한다.
  • 사소한 버그 수정도 빨리 해야 하기 때문에 신입 개발자들에게는 시킬 수가 없다. 고참 개발자가 2시간이면 고칠 것을 신입 개발자를 시키면 2일이 걸릴 뿐더러 고참 개발자가 신입 개발자에게 일을 시키고 검토해주는데 2시간이 넘게 걸린다.
  • 제품의 아키텍처가 취약해서 기능을 추가할 때 아주 애를 먹는다. 언제 시간을 내서 아키텍처를 깨끗하게 새로 만들고 싶지만, 유지보수에 바빠서 도저히 그럴 시간이 나지 않는다.
  • 이러다 보니 수시로 야근이다. 
  • 운동할 시간도 없어서 몸이 점점 망가진다.
  • 영어공부도 하고 싶은데 시간이 없다.

이런 회사의 미래는 누구나 짐작할 수 있습니다. 
설령 제품이 고객들 입맛에 맞고 영업도 잘되어서 큰 성공을 이뤘다고 하더라도 시간이 흐를 수록 채산성은 악화되고 개발자들의 사기는 떨어지고 있을 겁니다. 자꾸 옛날에 개발이 더 잘되었다고 회상할 것입니다.

매일 불끄기 모드로는 회사가 성장할 수 없습니다.

회사에서 해야 할 일은 4가지로 구분할 수 있습니다.

 구분 중요한 일  중요하지 않은 일  
 시급한 일  A  B
 시급하지 않은 일  C  D

A. 중요하고 시급한 일
중요한 계약을 따기 위해서 급하게 해결해야 하는 일

B. 중요하지 않으나 시급한 일
일상적으로 제품에 버그를 잡는 일
고객들의 기능 추가 요청을 들어주는 일

C. 시급하지는 않으나 중요한 일
새로운 기술을 연구하는 일
회사의 개발 프로세스를 꾸준히 발전시켜 나가는 일
새로운 아키텍처를 연구하는 일
차세대 제품을 개발하는 일
회사의 개발 문화를 발전시키는 일

D. 중요하지도 않고 시급하지도 않은 일
이런 일은 영원히 미뤄도 된다. 나중에 중요해지거나 시급해질 때 해도 된다.


이 중에서 회사의 미래를 결정짓는 일들은 "C. 시급하지는 않으나 중요한 일"들입니다.
어치파 "A중요하고 시급한 일"은 누구나 열심히 하게 되어 있습니다. 하지만 "B. 중요하지 않으나 시급한 일"을 처리하느라 "C. 시급하지는 않으나 중요한 일"을 처리 하지 않으면 미래는 없습니다.

제가 만난 수많은 회사들 중 대부분은 C에는 거의 신경을 못쓰고 있습니다. B를 조금이라도 소홀히 하면 회사가 당장 망할 것 같은 생각을 하면서 C는 전혀 손을 못댑니다. 거의 99:1인 경우도 많습니다. 하지만 회사를 망하게 하는 것은 C를 소홀히 하는 것이 장기간 지속되는 경우입니다. 평상시에 B와 C에 균형을 가지고 투자를 해야 합니다. 20%~30%는 C에 꾸준히 투자를 해야 합니다. 꾸준히 투자를 하지 않으면 어느날 갑자기 투자를 할 수 없습니다. 지금은 너무 바빠서 중요한 것을 알지만 지금은 투자를 할 수 없다고 말한다면 영원히 중요한 일에 투자를 할 시간은 생기지 않을 겁니다.

"C. 시급하지는 않으나 중요한 일"에 투자를 하는 방법은 여러가지가 있지만 가장 좋은 방법 중에 하나는 조직을 나누는 것입니다. 일부 조직은 항상 중요한 일을 할 수 있도록 하는 겁니다. 또한 개발자들에게도 중요한 일을 소홀히 하지 않도록 항상 상기를 시켜주는 것이 좋습니다.

당장 어렵다면 해야할 일들을 A, B, C, D로 나누기를 먼저 해보시기 바랍니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.

저작자 표시 비영리 변경 금지

전규현 개발문화 개발문화

Trackback Address: http://allofsoftware.net/trackback/204 관련글 쓰기
  1. 회사를 개인(나)로 바꾸니....
    저의 조급한 같은 문제도 어느정도 답이 나오는거 같아요..
    잘 읽었습니다~

  2. 레알님 안녕하세요.
    세상사 원리는 다 비슷한가 봅니다.

  3. "성공하는 사람들의 7가지 습관" 인가요. :D

  4. 우울한 딱다구리님 오랫만입니다.
    제가 그 책을 못읽어봐서... 기본적으로 사람이나 회사나 비슷한 측면이 많아 보입니다.
    저는 실제로 컨설팅 현장에서 직접적으로 많이 겪는 내용을 통해서 현상들을 파악하고 있습니다.

  5. 문제는 기업을 경영하는 사람들에게 있어서 C는 사원들이 알아서 해야할일 ... 이라고 생각하죠.
    애초에 A가 얼마나 로드가 걸리는지 모르는 경영진이 태반입니다.
    저 4개를 나눠봤자 A는 역시 바쁘기 때문에 C를 알아서 해라.. 라고 하고 하부에 로드를 더 걸어버리는 수가 생기죠.
    그래서 애초에 경영자의 마인드가 글러먹으면 아무리 좋은 방법론이 나와도 결국은 사용하지 않게 되버립니다. 안타까운 현실이죠.

  6. black_H님 안녕하세요.
    C는 당장 수익이 보이지 않는 투자이기 때문에 경영자의 지원이 없이는 직원들이 알아서 하기 매우 어렵습니다.
    즉, 소프트웨어 회사가 장기적으로 성장하는데 가장 중요한 키는 경영자가 가지고 있다는 것입니다. 뛰어난 개발자가 있어도 경영자가 환경을 조성해줘야 하죠.

  7. Blog Icon
    Jake

    전규현님께서도 말씀하셨지만 이런 회사들이 대부분이죠. 그런데 그런 회사들로 소프트웨어 산업이 계속 굴러가는 걸 보면 참 신기합니다.

  8. 안녕하세요. Jake님
    그래서 어느 한계를 넘어서는 회사가 별로 없다고 생각합니다.
    Global 소프트웨어 회사와 어깨를 나란히 하기는 어렵죠.
    생기고 없어지고, 반복을 하고 잘 망하지 않는 큰 회사들도 소프트웨어 경쟁력보다는 영업력이나 또는 직원들을 쥐어 짜서 내부적으로 엉망인 경쟁력으로 버티는 회사들도 많습니다.
    이 굴레를 벗어나야 할텐데 말입니다.

  9. Blog Icon
    thankee

    그런데 과연 우리나라 개발환경이 C를 위해 A와 B를 희생할 수 있는 환경인가요..? 우리나라 중소기업들의 대부분이 2~3명인분의 일을 한명이서 처리하고 있지요.. 이는 대표자가 돈좀 아낄려고 그러는 회사 뿐만아니라 사원들을에게 베풀고 경쟁력을 키워주고 싶어하는 회사에서도 마찬가지라고 생각합니다.. 대부분의 경우에 경제적으로 여유가 부족한 경우가 많기 때문에 그럴 수 밖에 없는 경우가 아닌가 생각됩니다.. 대부분의 회사들이 제살깎아내기 식으로 경쟁하고 있는데.. 어떻게 A와 B를 줄이고 C에 투자를 할 수 있을지.. 혹시 알려주실 분 없나요..?

  10. 안녕하세요. thankee님
    B:C의 비율을 99:1이 아닌 80:20 정도는 해야 합니다.
    당장 B를 99만큼 하지 않으면 큰일 날 것처럼 생각하는 경우가 있는데 그렇지 않은 경우가 많습니다. 99를 80으로 내리기 위해서는 해야 할 것들이 몇가지 있습니다.
    개발 프로세스와 기반시스템이 잘 갖춰져 있어야 줄일 수 있습니다. 모든 개발자들이 일당백으로 으쌰으쌰 하는 것 만으로는 어렵습니다.
    구체적인 방법은 한마디로 설명하기 어려우니 제가 쓴 책과 블로그의 여러가지 글들을 참조하시는 것이 좋겠습니다.

    그렇다고 하더라도 여전히 어려운 문제인 것은 동감합니다.

  11. Blog Icon

    비밀댓글입니다

  12. 생각해볼만한 주제네요. 감사합니다.

  13. 확실히 오래가는 회사일수록 유지보수(버그잡고 고객대응하고) 비용이 많이 들어가는게 보이는것 같아요.
    그런 이유로 새로운 라인업으로 갈아태우면서 단종시키는게 아닐까 싶긴 하지만 말이죠 ^^;

  14. 구차니님
    저도 동감합니다. 그래서 여전히 팔리는 제품도 유지보수 비용을 감안해서 적절할 때 단종시키기도 합니다.
    제품 라인업을 단순하게 가져가려고 노력하는 것도 중요합니다.
    제품을 개발하기 이전에 향후 유지보수를 고려하는 것이 필요합니다.

삼성이 소프트웨어 분야에서도 최고가 되려면?

2010/03/02 14:26 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


최근 삼성과 소프트웨어에 대한 글들을 몇 건 올리면서 정말로 다양한 의견을 접하게 되었습니다.
댓글뿐만 아니라 메일을 통해서도 의견을 들을 수 있었습니다. 

그 중에는 삼성 관계자 분들도 있었고, 삼성 내부 개발자, 삼성 협력사의 개발자들도 많이 있었습니다. 
현재 삼성으로 대표되는 대한민국 대기업들의 소프트웨어 개발 현황을 살펴보고 해결책을 찾아보려고 하는 블로그 글에 상당히 과민반응을 보이는 글들을 보면서 현 상황을 더욱 잘 짐작하게 해줍니다.
특히, 인상적인 글들은 삼성 내부 개발자와 삼성 협력사의 개발자의 글들이었습니다. 상당히 충격적인 증언들도 있었습니다. 댓글과 메일을 포함해서 삼성 내부 소프트웨어 조직의 심각성을 좀더 잘 알 수 있었습니다.
어쨌든 모든 댓글 및 메일을 보내주신 분들에게 감사 드립니다.

이제 결론을 내릴 때가 된 것 같습니다. 애초의 글들의 목적은 도무지 가망이 없어 보이는 대한민국의 소프트웨어 환경, 특히 삼성으로 대표되는 대기업들의 열악한 소프트웨어 개발 환경을 극복하고 소프트웨어 분야에서도 최고가 되는 방법을 찾아보려는 것이었습니다. 제 사견이긴 하지만, 그 동안의 소프트웨어 개발 및 컨설팅 경험을 근거로 나름대로 전문적이고 현실적인 방법을 찾아보려고 노력했습니다.

그럼 삼성이 소프트웨어 분야에서도 최고가 되는 방법의 시나리오를 보죠.

1. 좀더 실패가 필요합니다. 
어이 없는 결론이기는 하지만 몇번 더 실패를 통해서 소프트웨어의 중요성을 좀더 깨달아야 합니다.
현재 돌아가는 상황을 보면 소프트웨어 분야에 있어서 실패를 했고 실력은 부족하고 소프트웨어에 투자를 해야 한다는 간단한 현황을 진정으로 인식하고 있는 것으로 보이지 않습니다.
제가 삼성 및 대기업의 소프트웨어 개발 능력 부족을 지적하는 글을 작성한 이후에 놀랍게도 신문, 방송 모두 거의 똑같은 의견을 연일 쏟아 냈습니다. 이에 대응하여 삼성에서 발표한 극복 방안은 대부분 단기적이고 비전문가적인 접근들이었습니다. 소프트웨어 전문가라면 금방 문제가 있다는 것을 눈치챌 정도로 허술한 것들이었습니다. 
이는 현재상황을 진정으로 이해하고 있는 것이라고 볼 수 없습니다. 안타깝게도 몇번의 실패를 더 해야 진짜 문제가 심각하고 이대로는 안 된다는 것을 알 수 있을 것 같습니다. 삼성 내부에서도 아랫사람들이 아무리 얘기를 해봤자 시장에서 크게 실패하기 전에는 이를 깨닫기 어려울 것 같은 같습니다.
개인적인 바램은 최상위 경영층에서 가능하면 빨리 이를 인지해야 할 것 같습니다. 자칫하면 너무 늦을 수도 있습니다.

2. 소프트웨어 전문 경영자를 다시 중용해야 합니다.
기업의 경영자 인사는 다분히 정치적인 요소가 강합니다. 그러기 때문에 소프트웨어 전문 경영자가 중용되거나 오래 버티기가 힘들지만, 진짜 실패를 통해서 최고의 자리를 유지하기 위해서는 소프트웨어에 투자하는 수밖에 없다는 것을 깨닫고 나면 이를 이끌 소프트웨어 전문 경영자가 필요합니다. 
대기업의 소프트웨어 현황을 대변하는 말 중 하나가 "조삼모사"입니다.
"조三모四"아니 "조三모七"을 주장하는 소프트웨어 전문 경영자보다 "조四모一"을 얘기하는 경영자가 더 오래 살아남습니다. 여기서 저녁의 "일"은 얘기거리도 안됩니다. 소프트웨어 분야에서는 "조三모四현상이 더욱 극명하게 나타납니다.
애플은 아이폰의 플랫폼은 단 하나만을 사용하고 있고 구글도 안드로이드 하나를 사용하고 있습니다. 안드로이드는 핸드셋마다 변경될 수는 있지만 상당부분 호환성을 유지하고 있습니다.
그런데 국내의 한 굴지의 핸드폰 제조사는 지금까지 나온 6,000여개의 핸드셋에서 서로 다른 6,000개의 플랫폼을 사용하고 있습니다. 이를 공통으로 사용할 수 있는 플랫폼을 개발 할 수도 있었겠지만, 하나의 핸드셋만 놓고 보면 소스코드 복사해서 따로 만드는 것이 시간이 더 단축되기 때문에 "조三모七"이 아니고 "조四모一"을 선택한 것입니다. 
"一"이 아니고 마이너스 상황이 되고 소프트웨어가 지속적으로 발목을 잡기 전에 "소프트웨어 전문 경영자"가 이를 극복할 수 있도록 해야 할 것입니다. 또한 기존의 조직, 기존 사업부에서 결국 단기적인 실적 목표에 또 밀려 나지 않도록 새로운 조직이 필요할 것이며 정치논리에 밀리지 않도록 최상위 경영층의 지원이 필요합니다.

3. 외국의 전문 SW회사를 인수합니다.
삼성 내부의 개발조직을 가지고 어떻게 잘해보기에는 이미 늦은 듯 합니다. 물론 삼성 내부에도 뛰어난 개발자들이 많이 있지만, 조직으로 놓고 보면 얘기가 달라집니다. 이런 조직에서 오랫동안 길들여진 개발자들은 대부분 제대로 된 소프트웨어 개발 조직에서 제 역할을 하는 것을 기대하기는 힘듭니다. 
그렇다고 새로운 조직을 신입 개발자들을 뽑아서 만들어가기에는 시간이 이를 허용하지 않습니다. 
따라서 외국의 뛰어난 전문 SW회사를 인수해야 합니다. 이 또한 정치 논리가 아니고 진짜 소프트웨어 회사를 제대로 평가할 수 있는 전문가 그룹에서 삼성의 미래에 도움이 되는 소프트웨어 회사를 선택해서 제대로 평가하여 인수해야 합니다.
소프트웨어 전문 경영자는 인수한 SW회사와 삼성의 가교역할을 해야 합니다.

4. 인수한 SW회사는 삼성 내부의 개발조직과는 분리를 해야 합니다.
인수한 외국의 SW회사는 삼성 내부 개발자들과는 너무나 다른 개발문화를 가지고 있습니다. 이들을 자칫 그냥 섞어 놓다가는 둘 다 망칠 수 있습니다. 따라서 삼성 내부 개발자 중에서도 철저한 평가를 통해서만 인수한 SW회사로 이동이 가능할 것입니다. 아직 삼성의 개발문화에 많이 길들여지지 않았지만, 영어를 잘하고 똑똑한 개발자들은 인수한 SW회사와 섞어서 일하는 것이 가능할 것입니다. 
이 과정을 통해서 서서히 글로벌 소프트웨어 개발 문화를 익혀나가는 것이 필요합니다. 즉, 삼성에서 직접 활약할 선임 소프트웨어 개발자들을 양성해야 합니다.

5. 독자적인 성장을 할 수 있도록 보호를 해주고 지원해야 합니다.
인수한 소프트웨어 회사에도 "조삼모사"논리로 기존의 개발문화를 깨게 되면 평범한 소프트웨어 회사가 되어 버릴 수도 있습니다. 기존의 삼성 조직에 필요한 것들은 개발자 순환을 통해서 조금씩 익혀나가고 인수한 소프트웨어 회사에서는 독자적인 사업 영역을 계속 가져갈 수 있도록 보호를 해주고 지원해야 합니다. 이런 SW회사를 여러 개 인수하여 다양한 개발 문화를 접해야 합니다. 

6. 기존 조직의 반대와 방해로부터 보호를 받아야 합니다.
이러한 과정에서 내부 조직의 반대와 방해에 부딪힐 것은 뻔합니다. 이러한 방해는 아주 작은 소프트웨어 회사들에서도 존재하는데 삼성 같은 거대 기업은 말할 필요가 없습니다. 이를 보호해줄 수 있는 사람은 삼성내의 최상위 경영층 밖에 없을 겁니다. 이렇게 5년, 10년 투자가 이루어져야 소프트웨어 분야에서도 최고라는 소리를 조금씩 듣기 시작할 수 있을 겁니다.

고민 끝에 내린 시나리오는 이렇지만, 이 시나리오의 최대 키포인트는 바로 최고 경영층의 지원일 겁니다. 현재 상황을 얼마나 심각하게 깨닫고 기존의 경영자들은 이를 해결 할 수 없다는 것을 얼마나 빨리 깨닫느냐가 관건이라고 할 수 있습니다.

대한민국 소프트웨어 개발환경은 대기업, 중소기업 가리지 않고 열악하기 그지없습니다. 특히 삼성은 우리나라 경제의 가장 큰 버팀목이기도 하지만 수많은 중소 소프트웨어 회사의 밥줄이며 동시에 목줄을 죄고 있습니다. 삼성이 잘하면 모두 상생할 수도 있지만, 잘못하면 삼성은 약간의 타격이지만, 중소 소프트웨어 회사들은 와해되기 때문에 이것이 삼성이 소프트웨어 분야에서도 잘해야 하는 제가 생각하는 가장 큰 이유입니다. 

이는 비단 삼성만의 문제는 아닙니다. 제 바램은 이런 목소리를 통해서 소프트웨어 환경이 조금씩 나아지는 길로 가는 것입니다. 

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by whisperwolf
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기 M&A, 개발문화, 삼성, 소프트웨어, 인수

Trackback Address: http://allofsoftware.net/trackback/175 관련글 쓰기
  1. 2010/03/02 15:39
    k16wire의 생각 Tracked from moai's me2DAY
  2. 2010/03/03 08:41
    tkhwang의 생각 Tracked from tkhwang's me2DAY
  3. 2010/03/26 09:14
  1. 정말 100% 공감하는 글 입니다.
    극단적인 표현일지 몰라도 . 많은 프로젝트들이 실패를 해야 한다고 생각이
    듭니다.
    부정적인 시각이라기 보다 현실적인 시각이죠...
    프로젝트가 시작하면 이미 절반이상 실패를 했다고
    생각합니다.
    근거를 알 수 없는 개발공수, 복불복 개발 방법론(나만 아니면돼),
    커뮤니케이션 없는 일방적 진행,무늬만 개발 총괄,
    기술보단 정치가 중요한 환경등...
    재난이 난 후 피해액보다 예방에 투자한 금액이 훨씬 저렴하고
    안정적이란걸 깨달았으면 합니다.
    쓰나미가 밀려오는 걸 알면서 피하지 않고 기다린다는게 너무 슬프군요

  2. 안녕하세요. Beyond J2EE
    또다른 문제는 소프트웨어 분야에서 문제가 많음에도 불구하고 삼성이 잘해왔다는 겁니다. 최근 스마트폰이 대두되면서 문제가 되고 있기는 하지만 지금까지 겉으로 보기에는 잘 해왔습니다.
    그래서 더욱 경영층들이 설득이 알될 가능성이 높습니다.

  3. 바늘로 찔러 고름을 짜낼것을 미루고 미루다가
    10%도 안되는 성공율의 수술을 받아야 하는 상황이 된게 아닐까 싶습니다.

  4. 안녕하세요. 구차니님
    지금까지 왜 이렇게 되어 왔는지 이해는 되지만 안타깝죠.

  5. 시나리오는 영화로 제작하지 않는한 실감하기가 쉽지 않죠.
    또한 영화로 제작한다고 시나리오가 현실이 되는것도 아니고요.
    삼성의 SW 성공 시나리오는 말그대로 시나리오일 뿐..

    현실에서의 실질적인 대책은
    역시 어느 누구도 세울 수 없는 상황인 것 같습니다.

  6. 안녕하세요. 크레브님
    그나마 최선의 방법을 제시한 것이지만 이렇게 되지 않을 확률이 훨씬 높아 보입니다.

  7. Blog Icon
    도모네

    그 동네는 해외 유학파 출신 인재들도 많은 걸로 알고 있습니다만, 선진국으로부터 배운 것들은 조직문화에 별 영향을 주지 못하는 것 같습니다. '인천공항의 기적'이라는 말도 있던데.. 주로 대학 쪽에서 쓰이던 말이지만, 업계에서도 그것은 통용되고 있지 않나 싶네요.

소프트웨어 회사에 산업 스파이가 존재하는가?

2010/02/16 12:04 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed


최근에 블로그에 올린 글들의 댓글을 보면 소프트웨어를 잘 개발하는 것이 어떤 것인지 바라보는 시각이 무척 다릅니다. 필자는 주장하는 바가 있어서 소프트웨어 개발에 대한 생각을 꾸준히 공유하고자 합니다. 제 블로그의 미션은 어떻게 하면 소프트웨어를 효과적으로 잘~~ 개발하느냐를 공유하는 겁니다. 대상은 학생 개인부터 대기업에 이르기까지 모두 포함합니다. 하지만 이를 효과적으로 전달하는 것은 쉽지 않습니다. 또한 블로그 글 몇 건으로 생각을 바꾸게하는 것은 더욱더 어렵습니다. 그래서 다양한 측면에서 조명을 해봅니다. 

오늘은 소프트웨어가 하드웨어와 얼마나 다른지 하나의 예를 보여주겠습니다.

예나 지금이나 산업 스파이에 관련된 뉴스들은 종종 나옵니다.
수백억, 수천억을 투자한 기술을 1,2명이서 빼돌려서 해외에 팔아 넘기곤 합니다. 이런 일이 발생하면 회사에 치명적인 손실을 가져오게 합니다. 

위 기사만 봐도 얼마나 많은 기술 유출이 발생하고 있는지 알 수 있습니다. 

하지만 소프트웨어 분야에서 이런 일이 일어난 것을 본 적이 있나요? 소프트웨어 분야에서는 Open Source 정책을 통해서 심지어는 소스코드를 모두 공개하기도 합니다. 구글을 비롯해서 실리콘밸리의 대부분의 소프트웨어 회사들은 개발자가 입사를 하면 바로 회사의 거의 모든 소스코드를 바로 볼 수 있습니다. "개발자가 이 소스코드를 유출하면 어떻게 하나"하는 걱정은 하지 않습니다.

여기서 알 수 있는 것은 소프트웨어 회사의 핵심 기술이 무엇인가 하는 것입니다. 소프트웨어 회사의 핵심 기술을 설계 도면도 아니고 소스코드도 아니고 "사람과 개발 문화"입니다. 아무리 똑같은 소스코드를 가지고 있어도 그대로 따라 할 수가 없습니다. 당연히 그대로 팔아 먹을 수는 없겠죠? 또 유지보수는 어떻게 할까요? 소스코드를 열심히 연구해서 더 좋은 것을 만들려고 해도 만들 수가 없습니다. 

이런 소프트웨어 회사를 다니다가 본인에게 기회가 생기면 회사를 나와서 창업을 하기도 합니다. 이 때 소스코드 다 들고나가도 별로 신경을 쓰지 않습니다. 소스코드를 그대로 사용할 수도 없습니다. 개발자가 들고 나가는 것 중에서 가장 가치 있는 것은 "개발문화와 좋은 동료들"입니다. 이렇게 새로운 Start up이 탄생을 하고 성장하기도 하고 망하기도 하고 이런 시도가 계속 되면서 좋은 소프트웨어 토양을 이룹니다. 이 과정에서 기술과 문화가 계속 섞이면서 발전해나갑니다.

우리나라에서는 많은 소프트웨어 회사들은 소스코드를 신주단지 모시듯하고 심지어는 개발자들에게 공개하지 않고 소수의 개발자들만 볼 수 있게 하기도 합니다. (물론 우리나라에서는 꼭 이래야 하는 극소수의 예외는 있습니다.) 그 이유는 "사람과 개발 문화"가 변변치 않기 때문입니다. 개발자 한두명이 퇴사를 하여 경쟁업체를 만들거나 경쟁업체에 입사를 하면 치명적인 타격을 입기도 합니다. 참으로 척박한 환경입니다. 

소프트웨어 회사에서는 훔칠게 별로 없어야 합니다. 회사가 개발자들을 제대로 Retain하지 못해서 몽땅 나가버리는 경우라면 어쩔 수 없겠지만, 자연적인 개발자 순환을 거치면서도 소프트웨어 회사는 지속적인 기술 발전을 시킬 수 있어야 합니다. 소스코드를 모두 공개해도 좋은 개발팀을 유지하고 있으면 어느 누구도 우리보다 잘 할 수 없어야 합니다. 한두명 개발자가 퇴사를 해도 치명적인 타격을 입지 않아야 합니다. (아주 작은 회사는 예외) 소프트웨어 회사의 재산은 "좋은 개발자들과 개발 문화"여야 합니다. 

적당히 뽑은 공대생들 잔뜩 모아 놓고 프로그래밍 가르쳐서 회사에서 정해 놓은 프로세스대로 개발하고 지정한 문서 만들게 해서 좋은 개발팀이라고 착각하면 안됩니다. 세계 유수의 개발방법론 도입하고 CMMI Level5라고 해서 좋은 소프트웨어 개발 문화와 프로세스를 가지고 있다고 착각하면 안됩니다. 지금까지 나열한 것들은 오히려 방해요소가 될 수도 있습니다. 

물론 하드웨어도 소프트웨어와 공통점이 있겠죠. 좋은 인재가 필요하고 문화도 필요하겠죠. 하지만 저는 하드웨어 전문가는 아니니 이것은 언급하지 않겠습니다. 소프트웨어가 얼마나 다른지를 강조하고자 합니다. 이글을 자신의 회사에 적용해보고 우리 회사의 "개발문화"를 한번씩 가늠해보도록 합시다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by laverrue
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기 CMMI, 개발문화, 개발팀, 스파이

Trackback Address: http://allofsoftware.net/trackback/174 관련글 쓰기
  1. 2010/02/16 22:10
    회사의 기밀정보 유출경로? Tracked from 뎅꽁이의 보안창고
  1. 딱 규정된 방법론이란게 없는 것. 더 나은 방법을 회사내에서 가꾸어야 한다는 것.
    많이 공감이 되는 내용입니다.
    소프트웨어와 하드웨어의 공통점중에서 표준과 스팩을 정립하는 것은
    어떤 분야라도 더 안정된 시장을 만들 수 있는 초석이 아닌가 싶습니다. 물론 여러가지 사례를 통해서 알 수 있는것이구요. 하지만 하드웨어와 소프트웨어는 이름 명명을 보더라도 확연하게 다른 시장임을 참작할 수 있습니다. ( 단, 소프트웨어도 스팩재정의 힘은 있습니다. ), 장점과 단점을 잘 다스려서 가꾸어 나갔으면 하는 바램입니다.

  2. moova님 안녕하세요.
    실리콘밸리의 소프트웨어 회사에 가서 "너희 방법론은 뭐냐?"라고 물어보면 대부분 그런거 없고 그냥 개발한다고 합니다. 요즘은 Agile에 관심이 좀 있기는 하더군요. 하지만, 자신의 회사에 맞게 이거 저거 섞어서 사용하기 때문에 특별한 방법론은 없습니다.
    그래도 스펙을 가장 중요시하는 것은 여전합니다. 뭐하나 개발을 해도 스펙을 꼭 작성하고 리뷰를 한 후에 개발을 하죠.

  3. 어떤 곳에서는, 어떻게 일을 하는지, 어떤방식으로 소프트웨어를 개발하는지 하나 하나 모니터링을 하더군요.
    결국 그런 모니터링을 하더라도.. 똑같이 따라할 수가 없는 이유는 자신의 노하우가 아니기 때문일 것입니다. 이런 관점에서 보면 소스코드도 마찬가지 입니다.
    아무리 숨기고 기발한 소스코드라고 하더라도 소스코드만을 가지고 똑같이 따라하려 해도 그것과 똑같이 만들 수는 없는 것이죠.
    더 발전된 기업일 수록 소스의 오픈화를 합니다. 경험적으로도 더 창의적인 기업은 소스코드에 집착하는 모습을 볼 수 없었습니다.
    ( 오픈소스 프로젝트에서 소스코드를 블랙박스화를 한 곳을 봤습니다. 그곳도 기술적 가치나 흐름을 주장했지만 결국, 소스코드는 결국 장벽으로 쌓아놓더군요. 왜 아무것도 아닌데, 그렇게 숨기려고 하는지 모르겠습니다만, 신생기업이나 안정된 기업이 아닐 수록 그런 폐쇄적인 모습들을 종종 보곤합니다.

    결국 그런곳은 가치를 배우는 것보다, 가치를 전달해 주는것 때문에 골머리를 앓고 말죠.

    각 조직의 장단점을 아는 이들이 움직이면,
    그에 따라 귀를 열고 있어야 하는데 조직내부의 목표가 소프트웨어 목표로 둔갑해서,
    목표를 상실하는 것이 당연시 되는 문화도 있더군요..
    아무것도 아닌 소스코드나 전달한 소스코드도 오픈하지 말라고 하는 것 상식적으로나, 요즘 추세쪽으로나 이해가 가지 않는 부분입니다. )

  4. 정말 획기적이고 기발하고 어렵고 새로운 것은 별로 없습니다. 아이디어는 새로울 수 있으나 소프트웨어를 개발하면서 사용하는 기술들의 99%는 그렇지 않습니다. 새로운 기술이라면 바로 프로젝트에 적용할 수 없죠. 이를 검증하는 프로젝트가 별도로 필요하곤 하죠.

  5. 신기술이라면 바로 프로젝트에 적용할 수 없다는 것에 공감합니다. 그것에 더해서, 신기술에 대해 기술적 검증이 필요한 기간은 꼭 필요한 것 같습니다. 신기술이라고 해서 장담할 수 없는 것 중에 하나가, 기존 사례가 미약해서 쉽게 계약이나 결정을 못하는 것은 어떻게 보면 당연한 것 같습니다. 하지만, 사례가 많다면 여러가지 장점을 취할 수도 있겠습니다.

  6. 하지면 현실은 시궁창이란 문제가 ㅠ.ㅠ

    아! 새해복 많이 받으세요!

  7. 안녕하세요. 구차니님
    우리들이 바꿔나가야 하겠죠. 아자.

  8. Blog Icon
    ajure

    원래 무른모 개발이란 건설과 판박이랍니다.
    엔지니어링회사가 다 디자인 하죠. 그래서 건축가들은 명성을 얻는답니다. 이런 디자인에 바탕하여 하청, 재하청이 반복됩니다. 이런 구조적 사슬에 있다는 것을 이 땅의 무른모개발자/지망자는 몰랐다는 것이고
    무른모 개발이 이 딴 것이었다면 갑/을 이었다면 애초 쳐다보지도 않았을 것이랍니다.

    그러나 이런 갑/을 관계가 무른모의 구조적인 문제는 아니고
    무른모는 모두 공짜여야 한다는 무의식적인 산짜이 의분에 휩싸여서
    거의 깨어나올 가망이 없는 것이지요.

    그저 과거부터 현재까지 약간의 보조금을 주고서 연명을 하는 것이지요.
    다만 게임분야만큼은 좀 모습이 괜찮은 듯 하나
    정부.공기업.대기업 하는 꼴을 보면 바로 이집트 세리의 모습이고
    이 장면 한번 보면 다 이 곳이 이런데구나 하고 뼈아프게 후회한답니다.

    한 편으로 이런 나약한 약골들은 이 나라의 무른모 세상에서 빨리 떠나 다른 길을 모색해야 한답니다.
    그만큼 척박한 땅이 이 땅의 무른모 세상이니.

    사실 지나보면 이런 멋진 디자인을 하고 멋진 건축을 만든 무른모 선배가 없어
    롤모델이 없기도 한데
    세상에 선배가 별볼일 없으면 더 멋진 디자인과 건축물을 만들면 돼지요.

    지나보면 무른모란 벌레들이 많이 기어다니지만 결국 멋진 건축물, 멋진 손만, 멋진 그림을 만드는 사람들이라 생각한다오.

    무엇보다 중요한 것은 기골을 키워야 한다오.
    무른모란 결국 기골에 들어가는 것이니
    그래야 다른 기골들이 움직인다오.
    기골을 키우고 고집理를 쉽게 꺾지 말기요.

  9. Blog Icon
    목표성취

    이슈와는 거리가 먼 답글입니다만..
    소프트웨어 개발자로써 종사하는 사람임에도 "무른모"가 무슨 뜻인지 몰라서 사전을 찾아봤습니다.
    소프트웨어를 의미하는 말이더군요. 색다른 표현을 알려주신것에 대해 감사드립니다. (__)a

  10. "무른모"란 용어를 안다는 것은 오래된 개발자라는 뜻?
    한때 외래어 한글화 일환으로 여러 단어들의 한글화가 시도되었었죠.
    누리꾼, 댓글 등 자리잡은 단어들도 많은데 "무른모"는 소리소문없이 사라졌네요.
    그런데, 한글화의 문제점이 일반인은 좋지만, 개발자 입장에서 두 단어를 모두 알아야 하는 단점이 있죠. 그래서 그냥 영어를 그대로 쓰는게 개발자에게는 편하긴 합니다.

  11. 소프트웨어 산업의 고질적인 문제를 더 언급하셨네요.

    저가 수주에 따른 저가 하청 및 재하청
    불합리한 갑/을 관계
    소프트웨어의 가격을 쳐주지 않는 관행 및 불법복제
    정부 지원금 및 이것으로 연명하는 기업들

    블로그가 있으면 좀 알려주시지요? 감사합니다.

  12. Blog Icon
    Akemi T

    무른모..라는 말이 먼저 나왔는지 모르겠는데 한참 그말이 널리 쓰이려는 즈음에 "씨앗" 이라는 순수 한글 풀그림 언어도 있었죠. 한때나마 이 척박한 땅에서도 나무를 키워 숲을 이룰수 있다고 생각해본 순진한 시기였습니다만...

  13. '소스코드를 모두 공개해도 좋은 개발팀을 유지하고 있으면 어느 누구도 우리보다 잘 할 수 없어야 합니다. 한두명 개발자가 퇴사를 해도 치명적인 타격을 입지 않아야 합니다.'

    좋은 지표네요. :)

  14. 안녕하세요. 영회님 오랫만이예요.
    요즘도 블로그 잘 보고 있습니다.

  15. 아래 부분 200% 공감 합니다.

    - 소프트웨어 회사의 핵심 기술을 설계 도면도 아니고 소스코드도 아니고 "사람과 개발 문화"입니다.

    회사들도 이제는 폐쇄적 접근 방법 보다는 오픈을 하면서도 수익이 발생 할수
    있는 방법에 대해서 고민이 필요한 시기라고 생각합니다.
    그러기 위해서는 정말 유연하고 자유로운 조직 문화가 필요하다고 생각합니다.
    이런 분위기라면 개발자들도 조직을 쉽게 떠나지 않을 것입니다.

  16. 안녕하세요. Beyond J2EE님
    많은 경영자들이 개발자를 단순히 도구로 생각하고 있습니다. 공장에서 조립라인의 직원 생각하듯히 하는 경우가 많습니다.

  17. 매번 공감하는 글을 쓰셔서 잘 봅니다.

    아직까지 소프트웨어만의 특성을 이해하는 상위 관리자는 많지 않은 듯 합니다. 바로 앞의 성과만 중요시하다보니 사람과 개발 문화에 대한 이야기를 하면 왠 뚱딴지 같은 소리하냐며 무시 당하기 일쑤입니다.

    외국의 소프트웨어 기술과 환경이 급속히 발전하고 있는데 국내는 계속해서 정체만 하고 있는 듯하여 마음이 아플 따름입니다.

  18. 안녕하세요. 자바지기님
    아직 저변이 부족해서 그런 것 같습니다. 요즘 스마트폰이 관심의 대상이 되면서 삼성전자의 부진이 이슈가 되고 그 원인으로 소프트웨어가 대두되고 있는 상황입니다. 이런 일이 반복되면 소프트웨어에 대한 시각이 바뀌는데 일조하지 않을까 생각합니다.

  19. Blog Icon
    BackToT

    많이 공감되는 글입니다.

    부족한 토론 문화, 싹을 잘 죽이는 조직문화, 다른것을 인정 안하는 문화

    대충 생각만해봐도 개발문화에 걸림돌이 되는 사회적인 습관이 많군요.

    사람자원은 최고중 하나인 나라에서 문화가 걸림돌이 되는데 이와같은

    문제의식을 지닌 사람 자체가 드물다는게 더 슬프군요.

    PS: 글 주제에선 약간 벗어낫지만 소프트웨어 산업의 핵심이 사람과 문화라는것에 동조하면서 다른생각이 나서 씁니다.

  20. 안녕하세요. BackToT님
    "토론문화" 중요하죠. 소프트웨어 개발하는데 있어서 정말 중요한 요소입니다.

  21. 사람들이 쓸것이고 사람들이 모여서 만들기 때문에
    사람들과 그 사이에서 피어나는 문화를 이해하는 것이 가장 중요한것 같습니다.
    틀에 갖히고 안주하지 않기 위해 계속 틀을 깨야 한다고 생각합니다.
    개인적으로 이번에 큰 틀을 깨고 나옵니다.^^ 지금까지 해온게 아쉽지만 기대되네요..

  22. 청하님 안녕하세요.
    소프트웨어 문화 막상 보면 별거 아니고 다 아는 것처럼 보입니다. 하지만 교과서에서 보고 아는 것과 오랫동안 해와서 몸에 익은 것은 하늘과 땅 차입니다.

  23. Blog Icon
    Mr봉쿠레

    항상 좋은글 감사합니다 ^^ 어쩜 이리도 부지런 하실까요~! 배워야겠습니다~~

  24. 안녕하세요. Mr봉쿠레님
    감사합니다. 사실 별로 부지런하지도 않습니다. - -;

삼성은 왜 소프트웨어를 잘 만들지 못할까?

2010/01/05 12:13 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

오늘 아침 조선일보 IT관련 기사를 보다가 다음 글을 보게 되었습니다.


사실 삼성에서 개발하고 있는 바다에 관심은 있지만 큰 기대를 하고 있지 않기 때문에 별 생각 없이 기사를 훑어 보고 있는데, 생각해볼 내용이 있어서 인용합니다.

삼성전자는 이를 통해 '하드웨어는 강하지만 소프트웨어는 약하다'는 인식을 단번에 뒤집겠다는 것이다. 삼성전자가 '바다(bada)'라는 한글 이름을 해외 시장에서도 그대로 사용한 것도 한국에서 개발한 휴대폰 플랫폼이라는 이미지를 세계인에게 각인시키기 위해서다. 홍 상무는 "바다 프로그램은 스마트폰뿐 아니라 일반 휴대폰에서도 사용할 수 있도록 설계된 게 차별화 요소"라면서 "(바다는) 전 세계 개발자들이 만든 수많은 응용프로그램이 거래되는 장터라는 의미도 있다"고 말했다. 

조선일보기사에서 인용

'하드웨어는 강하지만 소프트웨어는 약하다'는 인식을 단번에 뒤집겠다"
이 의미는 원래 소프트웨어가 강한데 인식만 안 좋은 것이고 바다를 기똥차게 만들어서 인식을 바꾸겠다는 걸까요?
아니면 원래 소프트웨어가 약한데 이번에 바다를 개발하면서 갑자기 소프트웨어를 잘 만드는 조직으로 탈바꿈하겠다는 걸까요?

사실 둘다 말이 안되기는 마찬가지입니다.
일단 삼성도 소프트웨어는 약하다고 스스로 인정하는 것 같고, 그 동안의 경험을 토대로 판단해보면 절대로 소프트웨어를 잘 만드는 조직이라고 볼 수 없기 때문에 첫번째는 무시하죠.

비록 소프트웨어는 잘 못 만들지만, 소니, 모토롤라가 따라 올 수 없는 큰 강점들이 많아서 지금은 성공을 이루었기 때문에 삼정 자체를 평가할 생각은 없습니다. 단지 소프트웨어 얘기를 좀 해보죠.

왜 소프트웨어를 잘 못 만들까요? 사실 외형적인 것만 보면 부족할 것이 없어 보입니다. 조직, 프로세스 모두 갖추고 있고(오히려 과도하기도 합니다.), 개발툴이나 시스템은 세계 최고의 것들을 쓰고 있고, 똑똑한 개발자들이 바글바글(반대하는 사람도 많을 것 같네요.) 합니다. 

마치 "아이폰"과 "옴니아2"를 스펙만 놓고 보면 큰 차이가 없지만 막상 둘을 나란히 놓고 써보면 느낌이 확 다른 것과 비슷하다고 할까요?

겉보기에는 비슷하게 흉내를 내고 있지만, 속을 까보면 조금씩 다릅니다. 그 작은 차이들이 모여서 이렇게 되었다고 볼 수 있죠. 결국의 개발문화의 차이로 나타납니다. 실제 제 컨설팅 경험에 의하면 그런 환경에서 그런 방법으로 소프트웨어를 개발하고도 지금까지 살아 있는 것에 감탄을 하면서도 그 속의 개발자들을 안타깝게 생각한 적이 있었습니다. '좋은 환경과 제대로된 조직에서 개발을 해왔으면 훨씬 잘 되었을 개발자들인데'라는 생각이 들더군요.

결국 그 원인은 경영층의 소프트웨어에 대한 무지 때문이라고 생각합니다. 하드웨어 분야는 몇 십년간 정말 많은 투자를 해온 것에 비해서 소프트웨어는 그렇지 못합니다. 하드웨어적인 마인드로 소프트웨어 조직을 키울 수 있다고 생각하는 것 자체가 말이 안됩니다. 소프트웨어 조직은 소프트웨어를 철저히 이해하고 있는 경영자가 있어야 합니다. 이러한 경영자가 힘을 가지고 10년 이상은 노력해야 세계적인 소프트웨어 회사들과 어깨를 조금 나란히 할까 말까 합니다. 그렇게 할 수 있을 까요?

힘이 있고 소프트웨어를 정말 잘 이해하는 경영자가 있어야 소프트웨어 개발자들이 꾸준히 성장할 수 있는 길을 열어 줄 수 있습니다. 소프트웨어 개발이란 철저히 사람이 하는 일이라서 뛰어난 개발자들을 10년 이상 키워내야 합니다. 그냥 연수만 10년을 채운다는 의미는 아닙니다. 형식적으로만 갖춰진 조직이 아닌 정말 소프트웨어 개발조직다운 환경에서 제대로 된 개발문화 속에서 꾸준히 키워져야 "이제 소프트웨어 개발 좀 하겠구나~"하는 소리를 들을 수 있습니다. 

소프트웨어 개발조직 다운 환경과 개발문화가 구체적으로 무엇이냐고요? 짧은 글에서 다 설명하기는 정말 어렵습니다. 우리 전통문화를 잘 이해하지 못하는 사람에게 그게 뭔지 글로 설명하는 것이라고 해야 할까요?
궁금하다면 제 블로그 자체가 지속적으로 얘기하는 내용이므로 다른 글들을 읽어 보시기 바랍니다. 제 블로그를 구독하고 계신 분들은 나름대로 이해를 하고 계실 겁니다.

안타까운 것은 하드웨어와 소프트웨어의 갭이 상상이상으로 크고 삼성같은 큰 조직은 바뀌는 것이 훨씬 어렵다는 것입니다. 내부에 변화를 싫어하는 사람들이 너무 많기 때문입니다. 하지만 삼성은 이미 이전에 몇번의 변화를 통해서 지금에 이르렀기 때문에 약간의 희망을 가져봅니다. 

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
image by www.bada.com
저작자 표시 비영리 변경 금지

전규현 소프트웨어이야기 개발문화, 개발조직, 바다, 삼성

Trackback Address: http://allofsoftware.net/trackback/165 관련글 쓰기
  1. 2010/01/05 13:51
    제주소년의 느낌 Tracked from handk85's me2DAY
  2. 2010/01/05 14:24
    동치미의 생각 Tracked from dongchimi's me2DAY
  3. 2010/03/22 11:36
    삼성이 만들면 쓰레기가 된다! Tracked from 도아의 세상사는 이야기
  1. 공감이 많이 가는 글이네요. 비단 삼성만의 문제는 아닌 것 같습니다.

  2. 안녕하세요. myideom님
    상당히 광범위한 문제이기는 하죠. 삼성이 그만큼 주목받고 있으니 더 잘 해주기를 바라는 마음일 겁니다.

  3. 우리나라 전반적인 SW개발에 대한 인식이 바꾸기 전에는 아마 힘들지 않을까 생각이 됩니다.

    문득 삼성에서 항의해서 몇일만에 이 글이 내려갈까 궁금해지는건..
    역설적으로 SW개발에 대한 생각을 여실하게 보여주는 게 아닐까 생각이 됩니다.

  4. 구차니님 안녕하세요.
    가장 바뀌어야 하는 계층이 개발자도 관리자도 아닌 최고 경영층이라는 겁니다. 그래서 더 어려운 것 같습니다.
    삼성은 제 컨설팅 고객 중 하나이고 이런 글이 삼성에 해가 될 것으로 생각하지 않습니다. 쓴약이 몸에 좋다고 하잖아요.

  5. 평소 의문을 갖고 있던 부분이였는데 가려운곳을 시원하게 긁어주시네요.
    그러고 보면 우리나라 전통적인 기업문화를 갖고 있는 소프트웨어 회사 중
    규모는 크지만 이렇다할 회사가 없군요..
    우리나라에서 소프트웨어로만 먹고 사는 포털등에서는
    개방된 기업문화를 표방하고 있고요 ^^ㅋ

  6. 제주소년님 안녕하세요.
    포털은 기업문화는 개방되어 있을지는 몰라도 소프트웨어 개발 수준은 낮죠. 우리나라의 소프트웨어 역사가 짧아서 그런 측면도 있지만, 꼭 그 탓만을 할 수는 없습니다. 선배들이 망쳐 놓은 책임이 어느 정도 있습니다.

  7. 친구들 보면 대부분 소프트웨어 멤버십준비하고 그러는데;; 좋은 인력을 흡수해도 뭔가 안되는 이유가 있군요;;

  8. 물어님 안녕하세요.
    얼마전 S그룹 소프트웨어멤버쉽 세미나 요청이 있었는데, 일정이 안맞아서 못했는데, 꼭 했었어야 하는데 말입니다. ^^

  9. Blog Icon
    Richpapa

    저도 그냥 이 업계 떠 도는 얘기를 들었습니다만, 그러더군요. L사 또다른 S사 등은 경영 그리고 임원들 출신들중에 대략 엔지니어 출신 특히 소프트웨어 개발 출신자들이 더러 있어서 중심을 잡는다는군요. (루머처럼 도는 얘깁니다. 저도 정확히는 ^^) 근데, 말씀하신 S사는 무슨 유통, 건설쪽에서 사람을 돌림빵 한다는 얘기도 있었습니다. ㅎㅎㅎ

  10. 안녕하세요. Richpapa님
    저도 그와 관련된 글을 본 적이 있습니다.
    CEO는 그렇더라도 CTO가 엔지니어 출신으로 특히 소프트웨어 회사라면 CTO가 소프트웨어를 잘 이해하고 있어야 할 것입니다.

  11. Blog Icon
    tungsten

    컴퓨터 사면 OS며 Office며 기타 여러 유명 프로그램들은 꽁짜로 깔려야 컴퓨터 잘 샀네라는 사회적
    분위기 속에서 최고 경영층에게만 뭐라하기도 뭐하네요.

    그래도 삼성은 자사컴퓨터 팔면서 자사오피스로 나름 선전(?)하는걸 보면 나름 소프트웨어에도 관심은
    있었지 않았나 싶네요. LG는 하나워드로 처음 스타트는 나름 좋았으나...지금은 뭐...없잖아요.

    한글과 컴퓨터가 결국 MS에게 밀린것도 그렇고..
    옆나라 일본에선 새로운 게임 나오면 전날 살려고 기다리는 사람들 봐도 그렇고...

    몇몇사람들에게만 한정된 얘기는 아닌듯 싶네요.

  12. 안녕하세요. tungsten님
    삼성이 소프트웨어를 잘 못만드는 문제와 소프트웨어 불법 복제는 큰 상관이 있는 이슈는 아니지만 문제는 문제죠.

  13. Blog Icon
    ..

    개발일 좋아하고 천직으로 알던 사람도 개발일 몇년 하면 뒤돌아서게 만드는게 현재 한국 IT업계 현실이죠.

  14. 저도 점점 나이지길 기대하고 있습니다.

  15. 저도 동의하는 바입니다. 경영진의 해결방법은 공장에서 물건 찍어내듯 '휴일에도 일하고 밤새서 내일까지 되게해'이고 늘 촉박한 일정과 만성적인 야근속에서 어떻게 좋은 소프트웨어가 나올 수 있을까요? 위에 링크의 기사를 봐도 그런 상황이 중간중간에 묘사되고 있습니다. 결정적으로 앞을 내다보고 이끌어갈 수 있는 능력있는 임원이 없습니다. 맨날 뒤쳐지니까 하는거라고는 빨리빨리 따라하기죠. 그리고 삼성에서는 모델나와서 많이 팔리면 인정 받습니다. 안에 들어간 내용은 그다지 중요하지 않습니다. 얼마나 소프트웨어를 잘 만들었냐를 판단할 수 있는 기준도 사실 없고 그것을 신경쓸 여유도 없습니다. 그렇기 때문에 맨날 테스트하는 사람들만 늘려서 버그 잡기만 하고 있죠. 근본적인 설계나 개발방식의 문제에 대해서는 전혀 건드리지 못합니다. 인재가 중요하다고 말하지만 사실 혁신적인 생각을 가진 사람은 살아남기 어렵고 적당히 똑똑하고 말잘듣는 사람만 살아남을 수 있는 조직문화이기 때문에 앞으로 크게 변하리라 기대하지는 않습니다.

  16. 안녕하세요. coderiff님
    저도 바라고는 있지만 별로 기대하고 있지는 않습니다. 하지만 노력은 해야겠죠.

  17. Blog Icon
    삼성맨

    콕콕 잘 찝어주셨네요 ^^
    그런데 세계 최고의 개발툴과 시스템이라고 하셨는데..어떤 것을 두고 하는 말씀이신지요 ^^

  18. 안녕하세요. 삼성다니시나보네요.
    좋은 회사 다니시고 계시네요. 세계 최고의 개발툴과 시스템이라고 하는 것은 사실이기도 하고 약간 반어법적이 표현입니다.
    삼성은 회사가 워낙 여러개가 있고 삼성전자만 하더라도 내부에 개발탐이 워낙 많아서 한꺼번에 얘기할 수는 없지만, ClearCase나 ClearQuest외에도 테스트툴, 모델링툴 등 일반적인 회사에서는 근접하기 어려운 고가의 툴과 시스템을 많이 사용합니다. 1copy에 수천만원씩 하곤 합니다. 하지만 이는 가격이 비싸다 뿐이지, 정말 SW를 개발하는데 꼭 필요한지는 다른 이슈입니다. 오히려 더 부담이 될 수도 있습니다. 실제로 일부 개발팀은 실제적으로는 Opensource툴을 사용하고 있는 것으로 알고 있습니다. 이렇게 이중화가되면 더 부담이죠.

    즉, 요약하면 돈은 많이 들이지만 실속은 없다.라고 할까요? 하지만 이를 도입하는 담당자입장에서야 무료 툴이나 시스템은 불안하고 무료인 경우 본인이 할일이 많아지고, 비싼 툴을 도입하며 폼도나고 지원도 잘 받을 수 있고 또 영업사원들이 가만히 놔두지 않기 때문에 이런 저런 이유로 비싼 툴들이 선호되고 있는 것 같습니다.

    하지만 그런 비싼 툴들이 실리콘밸리에서는 오히려 별로 팔리지 않는다는 것을 보면 소프트웨어를 개발하는데 꼭 비싼 툴이 필요한 것은 아닙니다. 유무료와 상관없이 자신의 회사에 알맞은 툴이 뭔지 찾아서 "제대로" 쓰는 것이 중요합니다.

  19. 정말 동감합니다.
    저희 회사도 ClearCase와 ClearQuest를 사용합니다.
    하지만 그 용도는 소스 저장 용도/체크아웃/체크인 밖에 없습니다.
    SVN이라도 쓰면 다른 툴들과의 연동이라도 즐길 수 있는데..ㅠㅠ
    뭘 쓰던 제대로 쓰는게 좋겠죠...

  20. Blog Icon
    지나가는 삼성개발자

    좋은글 주셔서 감사합니다. 좀 더 강력한 쓴 약도 올려주세요.

    하나의 밀알이 땅에 썩어져 많은 열매를 맺듯이...

    규현님의 좋은글이 삼성의 개발자에게도 많은 힘이 됩니다.

    삼성의 특정 사업부 대다수 개발자들은 중구난방식 개발 설계, 벼락치기 일정등으로

    매일 14시간 이상씩 주말도 없이 일하고 그나마 쉬는날도 마음편히 못쉬는 시스템입니다.

    그런데, 국내 대기업 몇군데를 다녀본 1인으로서 느낀 한국의 기업문화는

    일단 일정을 최대한 당겨서 설계든 개발이든

    일단 밀어붙이고,

    각종 큰 이슈든 작은 이슈든 생기면 땜질 하면 그만이라는 생각을 대 다수 높으신 분들의 생각입니다.

    큰 이슈 같은 경우, 설계 자체가 잘 못 되어서 도저히 일정이 안나오는 경우도 많은데 말이죠..

    개발자 이전에 한사람의 대한민국 국민으로서..

    국제적 망신인

    소프트웨어 삼풍 사건이 일어나질 않길 바랍니다.

    (기존 어플개발도 마찬가지겠지만, 플랫폼은 특히 건물을 새로 짓듯이 거대한 일인만큼)

  21. Blog Icon
    지나가는 삼성개발자, too

    개발자로서 회사생활이 쉽지않은건 사실이지만..미국에서 애플, 구글, MS에 다니는 지인들의 말을 들어보면 그들도 그다지 다르지 않습니다. 특히 애플은 우리나라 기업보다 더하다는 말도 많구요..더군다나 삼성이 SW 투자를 늘린다고 해서, bada를 포기한다고 해서...개발자의 삶이 나아진다고 절대 생각하지 않습니다..투자가 늘어난다는건 그만큼 개발자들의 일의 강도가 높아진다는 뜻인데...일은 똑같이 하면서 돈은 많이 준다는 것으로 잘못생각하시는건 아닐테고 ㅎㅎ...SW의 삼풍백화점이라...참, 삼성을 너무 높게 평가해도 안되지만, 이렇게 낮게 평가하는것도....

  22. Blog Icon
    지닌사

    매우 공감합니다.

  23. 통찰력 있는 말씀입니다.

    저 역시 S 사에 있지만..
    아직 윗분들이 제조업 마인드를 벗어나지 못한게 정말 안타깝습니다.

    언제쯤 저희에게도 희망이 올지.. 힘드네요..

  24. Blog Icon
    성명준

    글 잘 읽었습니다.. 사장님도 잘 계시지요.. 반갑기는 한데... 내용이 가슴이 아프네요.
    담에 뵈면 많은 조언 부탁합니다.

Google을 이끄는 힘

2009/10/30 23:20 by 전규현
 All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다. rss RSS Feed

아이디어 내면 "네가 한번 만들어봐"

소프트웨어 업계만큼 아이디어가 넘치는 곳도 찾기 어렵습니다.
Google이 탄생하게 만든 힘도 아이디어이고, Google이 지속 성장하여 지금이 Google이 된 힘도 아이디어입니다. Google에서는 업무시간의 20%는 새로운 아이디어를 생각하거나 준비하는데 사용할 수 있고 좋은 아이디어만 있다면 얼마든지 시도해 볼 수 있습니다. Google이 풍족하기 때문에 그렇게 할 수 있다고 말하는 사람들도 있지만, 이는 닭이 먼저냐? 달걀이 먼저냐?의 이슈입니다.

소프트웨어 업계에 종사하고 있는 사람이라면 항상 새로운 아이디어에 대해서 고민하기 마련입니다.

하지만, 좋은 아이디어를 내면 "네가 한번 만들어봐"라고 하는 경우가 많습니다. 또는 "뜬구름 잡고 있네"라고 하는 경우도 있죠.
안 그래도 바쁜데 아이디어만 내며 그 책임이 나에게 돌아오고 지금 하고 있는 일에 지장을 초래할 수 있기 때문에 좋은 아이디어가 있어도 쉽사리 얘기하기도 힘들어 집니다..
그러다 보니 자연스럽게 지금 하고 있는 일이나 열심히 하지 "생각은 무슨 생각" 그냥 아무 생각 없이 일이나 하게 됩니다.

아이디어가 나오면 아이디어를 더 발전 시키는 일은 회사에서 할 일입니다.
물론 아이디어를 내놓은 사람이 아이디어를 Follow up하는 일을 맡을 수도 있지만, 이를 위한 배려는 해야 합니다. 안 그래도 바쁜데 언제 그러고 있냐고요? 그러다 보면 지금 하고 있는 업무에 지장이 있다고요? 그런 회사는 어차피 현재 일에만 치여서 미래는 준비 못하는 겁니다. 즉 R&D에 투자를 못하는 것이고 미래가 없는 것이죠.
SW 회사의 중요한 자산은 개발자의 시간이기 때문에 개발자의 시간을 사용하는 것은 중요한 투자 수단의 하나 입니다. 공짜가 아니죠.

아이디어가 나오면 일단 공론화 할 수 있는 창구가 필요합니다.
그래서 누구나 볼 수 있고 토론을 할 수 있어야 합니다. Wiki를 이용하는 것도 좋은 방법이고 주기적으로 아이디어를 발표하게 하는 것도 좋습니다. 사소한 아이디어 하나가 여러 사람의 머리를 거치면서 훨씬 더 멋진 아이디어로 발전하는 경우는 흔합니다.

아이디어를 많이 생각해 낼 수 있는 수단이 필요합니다. 간단한 포상을 해도 되고, 평가에 반영할 수도 있습니다. 또 아이디어가 실현되어서 수익을 내게 되면 그 수익의 일부를 지급하는 방법도 있습니다.

꾸준히 아이디어를 내지 않는 SW회사는 용역회사밖에 될 수 없을 겁니다. 
아이디어는 10개 나오면 그 중에 하나 쓸만하고, 그 쓸만한 아이디어 10개 수행하면 한 개 정도 성공하고 그 성공한 아이디어 10개 중에서 한 개 정도 대박이 터질까 말까 합니다.
즉, 아이디어가 1,000개는 나와야 대박이 나올까 말까 한다는 겁니다.
999개의 아이디어가 없으면 대박 아이디어 1개가 나오지 않습니다. 그래서 꾸준히 아이디어를 고민하지 않고 몇 명이 머리 맞대고 대박 아이디어 고민하는 것은 확률이 너무 낮습니다.

아이디어는 어느날 갑자기 계시를 받듯이 하늘에서 뚝 떨어지는 것이 아닙니다. 업계 동향도 꾸준히 살펴야 하고, 신기술도 열심히 익혀 놓고, 새롭고 창의적인 생각을 장려하는 기업 문화가 있지 않으면 아이디어가 생기지 않습니다. 좋은 아이디어라고 하더라도 시장의 상황과 맞지 않는 다면 별 효과를 발휘하지 못할 수도 있습니다. 이런 시기 적절하지 못한 아이디어라고 하더라도 잊혀지지 않도록 꾸준히 관리할 수 있는 도구도 필요합니다. 

아이디어를 먹고 살 수 밖에 없는 Software회사가 아이디어 발굴에 소홀히 한다면 지금은 그럭저럭 살아남을 수 있어도 지속적으로 성장하는 회사가 되기는 어려울 겁니다. 아이디어 없이 영업으로 성장한 회사의 개발자들은 참 고될 수 밖에 없습니다. 그런 회사에서 일하는 개발자를 흔히 "앵벌이"라고 하죠. 

끊임 없이 아이디어 발굴에 투자하는 기업문화가 개발자들을 더욱 즐겁게 일하고 건전하게 성장하는 소프트웨어 회사를 만들어 줍니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by Cayusa


저작자 표시 비영리 변경 금지

'개발문화' 카테고리의 다른 글

내가 지금 하고 있는 일의 가격  (6) 2010/11/02
개발자를 잘못 채용하는 방법  (20) 2010/04/19
Google을 이끄는 힘  (7) 2009/10/30
SW개발과 Teamwork, 그리고 Review  (2) 2009/10/19
우리는 다르다.  (6) 2009/10/09
Peer review의 혜택  (2) 2009/05/13

전규현 개발문화 개발문화, 신기술, 아이디어, 업계동향, 포상

Trackback Address: http://allofsoftware.net/trackback/153 관련글 쓰기
  1. 2009/11/23 14:51
    아이디어 보상제의 함정 Tracked from All of Software
  1. 전 이사님, 그간 잘 지내셨는지요.
    지난번 강의 감사드립니다.
    다음번에 또 좋은 주제가 있으면 연락드리겠습니다.

  2. 박수석님 오랫만입니다.
    요즘, 바빠서 정신없이 보내고 있네요. ^^
    항상 열심히 하시는 모습이 보기 좋습니다. 나중에 기회가 되면 또 뵙죠.

  3. 오랜만에 들렸는데 좋은 글이 첫페이지를 장식하고 있네요. 감사합니다.

  4. 두렁청해님 안녕하세요.
    요즘 블로그 업데이트가 뜸하시네요. ^^

  5. 매일 접속하긴 하는데 포스팅한지는 좀 됬네요^^
    조만간 소소한 내용이라도 한 번 올려봐야겠어요

  6. 우리날에서 그런 환경의 회사를 찾는 것도 참 어려운 일이겠군요..

    나중에 저도 취직하게 되면, "그냥 하는 일이나 잘하지"처럼 되버리는 건 아닐지 겁이 나네요.

  7. funeasy님 안녕하세요.
    IT강국이라는 우리나라가 소프트웨어에 있어서는 후진국처럼 느껴집니다. 대부분 회사가 그러니 너무 겁먹지 마시고요. ㅎㅎ 자신이 처한 환경에서 최선을 다하면 됩니다.

관리자가 이런 일까지?

우리나라 SW 조직에서 관리자란 위치는 참 애매한 위치다. 물론 전문 관리자라면 얘기가 다르지만 왕년에 SW를 조금 개발해 본 경우가 애매하다. 개발팀에서 가장 경험이 많은 SW 개발자들이 주로 팀장이 되곤 한다. 이 경우와..

과거의 성공이 발목을 잡을 때

수많은 소프트웨어 회사들이 첫번째 성공을 거두고 나서 두번째 도약에 실패하고 사라져간다. 물론 첫번째 성공도 어렵지만 이미 성공의 경험이 있고 방법을 알고 있는 회사들이 두번째 또는 세번째에는 많이 실패하는 이유가 무엇일까?..

스펙을 제대로 작성하는 것은 구식이다?

'소프트웨어 개발 방법이 얼마나 발전했는데 아직도 스펙을 제대로 작성하고 개발을 하는가?' 라고 하면서 스펙 작성에 반대하는 주장을 하는 사람들이 있다. 스펙, 설계를 작성하고 구현을 하고 테스트를 하는 방식으로 개발하는 것..

내가 개발에 집중할 수 없는 이유

우리나라에서는 개발자들이 개발에 집중할 수 없는 환경인 곳이 참 많다. 정도의 차이가 있지만 거의 대부분이라고 봐도 무방하다. 그 결정적인 이유는 개발자 혼자서 북치고 장구치고 다해야 하는 상황이기 때문이다. 원래는 이렇게..

설계가 필요할까?

최근에 Software Architect의 정체에 대해서 혼란을 겪고 있는 것 만큼 Software 설계에 대해서도 혼동스러운 것은 마찬가지인 것 같다. 그래서 설계에 대해서도 깔끔하게 정의를 해보자. 흔히 설계에 관한 다음..

Software Architect를 양성하는 나라

우리나라에서는 종종 SW Architect를 양성한다고 한다. 정부에서 막대한 예산이 지원도 되며 SW Architect를 양성하는 학원도 생기고 야단법석이다. 그럼 도대체 SW Architect는 무엇인가? SW Archi..

우리에게 지금 필요한 것은? 바로 이것

우리나라 대부분의 소프트웨어 회사들에게 가장 시급하게 필요한 것은 "기초 체력"이다. 히딩크가 우리나라 국가대표 축구팀을 처음 맞았을 때 강조한 것이 기초 체력이었다. 그전까지 우리는 국가대표 축구팀이 체력은 세계 어디를 내..

프로토타입을 재활용하면 될까? 안될까?

며칠 전 프로토타입에 관해 올린 글에 대해서 프로토타입 재사용에 대해서 여러 의견이 있어서 이 내용에 대해서 조금더 설명해보려고 한다. 2011/11/03 - [프로젝트/요구사항분석] - 프로토타입이란? 소프트웨어공학의 목적..

프로토타입이란?

프로토타입 (경제/경영) 양산(量産)에 앞서 제작해보는 원형(原型)을 '프로토타입'이라 하는데, 프로토타이핑이란 개발자들과 사용자들의 의사소통상의 효과를 증진시키기 위하여 취하는 시스템개발상의 기법이다. 일반적인 분석방법을..

같이 일하려면 적어라.

"협업은 말로 하는 것이 아니라 문서로 하는 것이다." 동서고금을 막론하고 개발자들은 적는 것을 싫어하고 또 잘 적지 못한다. 우리나라 개발자들은 그 정도가 훨씬 심하다. 우리나라에서는 회사가 크던 작던 상관없이 대부분 5년..