SW가내수공업
2009/10/01 21:49 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
우리나라 SW회사들의 개발 상황을 보면 크나 작으나 가내수공업 형태를 벗어나지 못한 경우가 많습니다. 회사가 작을 경우에는 이런 가내수공업 형태의 개발이 큰 문제를 일으키지 않기도 하지만, 회사 규모가 가파르게 커 나가는데도 계속 그런 형태를 유지한다면 회사의 효율성은 급격하게 떨어지게 됩니다.
마치 원생동물이 군집생활을 하는 것 같은 이런 조직은 서로 같이 일함으로써 상승효과를 얻기는커녕 점점 비효율적으로 바뀌게 됩니다.
SW개발조직은 정교하게 진화된 생체조직과 같이 서로 분업이 잘 이루어져 있고 각 역할은 전문적으로 발전을 해야 하고 시스템적으로 커뮤니케이션이 원활하게 진행이 되어야 합니다. 이러한 조직을 회사가 커진 이후에 준비를 하려고 하면 이미 늦습니다. 회사가 아주 작거나 심지어는 혼자서 회사를 하더라도 조직과 시스템을 갖춰놔야 자연스럽게 회사의 성장에 맞춰서 효율적인 조직을 유지할 수 있습니다.
아직도 전적으로 각 개발자 한 명, 한 명에 너무 크게 의존을 하고 개발의 대부분이 코딩이며, 프로젝트의 성패는 소수의 개발자에 달려 있다면 원생동물의 군집생활과 비슷한 조직이라고 보면 됩니다.
이런 조직을 효율적이고 리스크가 적은 조직으로 탈바꿈하기 위해서는 가장 먼저 필요한 기반시스템을 통해서 모든 개발 과정과 커뮤니케이션을 투명화 하면서 잘 분업화된 전문조직으로 하나씩 바꿔나가야 합니다. 물론 이 과정이 그렇게 쉬운 일도 아니고, 책보고 따라 하기도 쉽지 않죠. 그래도 일단 이 정도만 해도 상당한 효과를 볼 수 있죠. 그만큼 투명한 개발이라는 것은 대단한 변화를 가져옵니다. 그리고 나면 각 개발자들의 역량 향상인데, 이는 대단히 오래 걸리는 일입니다.
가내수공업형태를 못 벗어난 여러 SW회사들이 미국에 진출한다고 해서 수많은 실패를 경험한 것을 잘 알고 있습니다. 동네 축구 좀 한다고, 월드컵에 나가 보겠다고 하는 것처럼 무모하게 들리기도 합니다. 물론 동네축구에도 정말 뛰어난 인재들이 있습니다. 하지만 박지성이 기회 없이 계속 동네 축구만 했다면 세계적인 선수가 못되었겠지요. 조직은 전문화가 되고 개발자는 진짜 개발자에게 필요한 역량을 키워나가고 해야만 그나마, 게임이 좀 될 수 있습니다.
이 와중에 이를 해결해보고자 방법론들을 기웃거린다면 문제가 될 수 있습니다. 왜냐하면 방법론에서는 조직이나 시스템에 대해서는 별로 가이드를 하지 않기 때문에 엉뚱한 곳에서 헤맬 수가 있습니다. SW를 효율적으로 잘 개발하는 방법은 특별한데 있지 않습니다. 우리가 소홀히 하는 아주 기초적인 것들에 있습니다. 기본에 충실해야 할 때입니다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
(image by Microsoft Office Online)
'개발조직' 카테고리의 다른 글
| SW회사, 이런 사장이 문제 (11) | 2009/11/10 |
|---|---|
| 내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ... (8) | 2009/10/23 |
| SW가내수공업 (4) | 2009/10/01 |
| 항상 보스가 먼저 말하게 하라. (4) | 2009/08/21 |
| 우리는 개발자가 테스트도 다 해요. (2) | 2009/08/09 |
| 사업부가 소프트웨어 조직에 미치는 영향 (0) | 2008/12/23 |
Trackback Address: http://allofsoftware.net/trackback/146
-
2009/10/05 08:34toracle의 생각 Tracked from toracle's me2DAY
방법론이라는것이 조직에 대해서는 가이드를 하지 않고 있다는 것은 공감합니다. 물론 기초적인 부분도 점거을 해 봐야겠지요. 경험적으로 프로젝트를 진행해 보면 차 후 항상 어떤 방법론과 비슷하게 되는 과정을 간접/직접적으로 느낄 때가 많습니다. 물론 이론적인 방법론에 충실한 것은 아니겠지만요.
체계가 없고 난잡한 상황에서도 꾸준히 체계를 잡아서 나아가다 보면 어떤 방법론과 흡사해 지는 과정처럼
방법론을 미리 본다고 그것이 문제가 될 수 있는 것는 아닌것 같습니다. 대게 나와있는 방법론들은 충분히 경험적인 바탕으로 나온것들이기때문에참고정도는 할 수 있겠죠.
문제는 현 시점에서 어떤 것들을 도입하면 좋은가.필터링 할 수 있는 것때문에 헤매는것 같습니다. 저 같은 경우 최근 예전에 한번 본 애자일관련 방법론을 다시한번 보고 있습니다. 어떤 것을 해결 하겠다고 보는것이 아니라 그것에서 장점을 추려내기 위함이죠..
안녕하세요. stmind님
잘못된 방법론이라는 것은 존재하지 않죠. ^^ 하지만 우리에게 알맞은 방법론은 있습니다. 문제는 경험이 부족하면 어떤 것이 알맞은지 알기 어려운 것이죠.
애자일을 시도해 보셨다고 하는데, 아주 좋은 시도입니다. 그 과정에서 장단점도 파악이 되고 회사에 알맞게 변화를 줄 수도 있습니다.
딱 하나의 방법론을 따르기 보다 여러 방법들을 혼합해서 쓰는 경우도 많고, 한 회사에서도 프로젝트의 성격에 따라서 다른 방법들을 써야 합니다. 따라서 너무 엄격한 프로세스 규칙은 효율성을 떨어뜨립니다.
안녕하세요 전규현님.
전규현님의 좋은 글들 항상 잘 보고 있습니다.
전규현님께서는 많은 글에서 경영자의 의지가 중요하다, 경영자부터 바뀌어야 한다 하시는데 맞는 말이지만 정작 직원으로서 영향을 미치기는 힘든 부분이 아닌가 싶습니다. 전규현님의 글을 보시는 분들중에는 경영자 보다는 일반 개발자들이 훨씬 더 많을 것이라고 생각이 듭니다. 그래서 말인데 혹시 경영자의 마인드를 어떻게 바꿀수 있는지에 대한 글을 부탁드려도 될까요?
C-Thinker님 안녕하세요.
항상 글을 보고 계신다니 감사합니다.
사실 축구선수 하나가 축구팀을 바꾸는 것보다는 감독이 미치는 영향이 훨씬 큽니다. 10배 이상일 겁니다.
개발자들 스스로 회사를 바꿔나갈 수 있는 것도 있지만, 많은 부분은 경영자의 후원이 필요합니다. 경영자 스스로가 SW를 잘 알고 있다면 괜찮겠지만, 우리나라에서는 흔한 일이 아닙니다.
이런 경우 CTO가 있어서 기술적인 부분을 담당해준다고 하면 되지만, CTO가 없는 회사가 대부분이고, 있다고 하더라도 제 역할을 못하는 경우가 더 많습니다.
그렇다면 개발자들이 경영자의 기술적인 부분을 보충해줘야 하는데, 그럴려면 개발자가 개발자의 용어로 얘기를 해서는 안됩니다. 또, 개발자의 사고방식에만 머물러서는 경영자와 얘기도 안됩니다. 또, 경영자는 개발자 마인드에만 머물러 있는 개발자의 판단을 믿지 않습니다.
개발자가 성장을 할 수록 회사 전체, 시장 전체를 보고, Business 마인드가 없다면 경영자를 설득할 수 없습니다. CTO가 기술과 경영마인드를 다 갖고 있는 사람이죠.
따라서, 경영자를 탓할 것이 아니라, 개발자가 경영자의 신뢰를 얻어야 합니다.
저는 수많은 경영자들과 얘기를 많이 하기 때문에 경영자들이 개발자의 기술력은 믿지만, 그들의 전략적인 판단이나 경영마인드에 대한 믿음은 별로 없는 경우가 많다는 것을 잘 알고 있습니다.
결국 어려운 일처럼 들리지만, 어려운 일 맞습니다. 저와 같은 외부 전문가가 경영자를 설득하는 일은 더 쉽지만, 개발자들이 내부에서 스스로 경영자를 설득하는 일은 좀더 어렵습니다.
추후 이에 대한 글을 한번 올려 보도록 하겠습니다. 감사합니다.