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

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

[조형래 IT팀장의 심층 리포트] 삼성폰 운영체제 '바다' 순항 준비 끝!

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

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

'하드웨어는 강하지만 소프트웨어는 약하다'는 인식을 단번에 뒤집겠다"

이 의미는 원래 소프트웨어가 강한데 인식만 안 좋은 것이고 바다를 기똥차게 만들어서 인식을 바꾸겠다는 걸까요?

아니면 원래 소프트웨어가 약한데 이번에 바다를 개발하면서 갑자기 소프트웨어를 잘 만드는 조직으로 탈바꿈하겠다는 걸까요?

사실 둘다 말이 안되기는 마찬가지입니다.

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

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

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

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

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

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

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

소프트웨어 개발조직 다운 환경과 개발문화가 구체적으로 무엇이냐고요? 짧은 글에서 다 설명하기는 정말 어렵습니다. 우리 전통문화를 잘 이해하지 못하는 사람에게 그게 뭔지 글로 설명하는 것이라고 해야 할까요?

궁금하다면 제 블로그 자체가 지속적으로 얘기하는 내용이므로 다른 글들을 읽어 보시기 바랍니다. 제 블로그를 구독하고 계신 분들은 나름대로 이해를 하고 계실 겁니다.

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

SW회사, 이런 사장이 문제

모든 회사가 마찬가지이지만, SW회사에서 경영자의 중요성에 대해서는 여러 번 얘기를 했습니다.

여러 경영자 중에서 어설프게 아는 경영자가 아예 잘 모르는 경영자보다 더 무섭습니다.

많은 SW회사 경영자들을 만나보면, 소시적에 코딩도 좀 해보고 밤새우면 개발도 해봤다고 SW 개발을 아주 잘 이해하고 있다고 착각하는 경우를 자주 접하게 됩니다. 또 본인이 상당한 수준의 전문가라고 착각하기도 합니다.

이런 경영자일수록 자신이 잘 알고 있다고 생각하므로 진짜 전문가인 내부 개발자들이나 외부의 목소리에 귀를 기울이지 않게 됩니다.

이는 마치 바둑 7,8급 정도 두는 실력으로 1,2단 실력을 가진 개발자들 머리 위해서 마음대로 휘두르는 것과 같습니다. 

비록 자신이 모르더라도 전문가를 채용하고 전문가의 의견을 존중하는 경영자가 오히려 낫습니다.

이런 어설픈 전문가 증상은 개발자 출신 경영자에게서 종종 나타납니다.

이러한 경영자들은 회사가 커지면서 부딪히는 문제들을 자신의 경험을 토대로 해결하려고 하곤 합니다. 그러면서 개발자들이 자신이 왕년에 개발하는 것처럼 열심히 안 한다고 한탄하기도 합니다. 본인은 과거에 꽤 괜찮은 소프트웨어를 개발하여 회사를 이만큼 키워 놓았지만, 잘 개발했던 것은 아닙니다. 회사가 작고 개발 인원이 얼마 안되니 그냥 주먹구구식으로 개발을 했어도 별 문제 없이 개발이 되었던 것일 뿐입니다.

차라리 소프트웨어 개발에 대해서 잘 몰라도 전문가의 말에 귀를 기울이고 이해를 하려고 노력하는 경영자가 어설픈 전문가 경영자보다 낫습니다. 물론 진짜 소프트웨어 전문가인 경영자가 있다면 좋겠지만, 이것은 거의 불가능한 일이고 그렇다면 그런 사람은 CEO보다는 CTO역할을 하는 것이 맞겠죠. 이러한 연유로 우리나라 SW회사에는 제 역할을 하는 CTO를 만나는 것이 쉬운 일이 아닙니다.

최고의 SW전문가는 아니더라도 경영자가 적절히 SW개발에 대해서 이해를 하고 있고 내부 개발자들의 의견을 존중하고 전문가의 말에 귀를 기울이고 개발팀에 적극적으로 투자를 해준다면 금상첨화입니다. (물론, 이런 경영자도 많이 만나 봤습니다.)

내가 오래 일하면 일 처리 속도가 느린 것이고, Boss가 오래 걸리면 ...

재미 있는 유머입니다.

My Boss & I

직장 상사와 나
When I take a
long time, I am slow.
When my boss taking a long time, he is thorough.

내가 일을 오래 끌면 일 처리 속도가 느린 것이고,
나의 상사가 일을 오래 끌면 일을 철저히
하는 것이다.

When I don't do it, I am lazy.
When my boss doesn't do it, he is too
busy.

내가 그 일을 하지 않으면 게으른 것이고,
나의 상사가 그 일을 하지 않으면 너무 바쁜
것이다.

When I do something without being told, I am trying to be smart.   

When my boss does the same, that is initiative.  

내가 시키지 않은 일을 하면 잘난척하는 것이고,
나의 상사가 시키지 않은 일을 하면
솔선수범하는 것이다.

When I please my boss, I am apple-polishing. 
When my boss pleases his
boss, he's co-operating.  

내가 상사를 기쁘게 하면 아첨하는 것이고,
나의 상사가 자신의 상사를 기쁘게 하면 협력을
잘하는 것이다.

When I do well, my boss never remembers.  
When I do wrong, he never
forgets.  

내가 잘한 일은 상사가 절대 기억하지 못하고,
내가 잘못한 일은 상사가 절대 잊지
않는다.

출처:이찬승영어등대

SW가내수공업

우리나라 SW회사들의 개발 상황을 보면 크나 작으나 가내수공업 형태를 벗어나지 못한 경우가 많습니다. 회사가 작을 경우에는 이런 가내수공업 형태의 개발이 큰 문제를 일으키지 않기도 하지만, 회사 규모가 가파르게 커 나가는데도 계속 그런 형태를 유지한다면 회사의 효율성은 급격하게 떨어지게 됩니다.

마치 원생동물이 군집생활을 하는 것 같은 이런 조직은 서로 같이 일함으로써 상승효과를 얻기는커녕 점점 비효율적으로 바뀌게 됩니다.

SW개발조직은 정교하게 진화된 생체조직과 같이 서로 분업이 잘 이루어져 있고 각 역할은 전문적으로 발전을 해야 하고 시스템적으로 커뮤니케이션이 원활하게 진행이 되어야 합니다. 이러한 조직을 회사가 커진 이후에 준비를 하려고 하면 이미 늦습니다. 회사가 아주 작거나 심지어는 혼자서 회사를 하더라도 조직과 시스템을 갖춰놔야 자연스럽게 회사의 성장에 맞춰서 효율적인 조직을 유지할 수 있습니다.

아직도 전적으로 각 개발자 한 명, 한 명에 너무 크게 의존을 하고 개발의 대부분이 코딩이며, 프로젝트의 성패는 소수의 개발자에 달려 있다면 원생동물의 군집생활과 비슷한 조직이라고 보면 됩니다.

이런 조직을 효율적이고 리스크가 적은 조직으로 탈바꿈하기 위해서는 가장 먼저 필요한 기반시스템을 통해서 모든 개발 과정과 커뮤니케이션을 투명화 하면서 잘 분업화된 전문조직으로 하나씩 바꿔나가야 합니다. 물론 이 과정이 그렇게 쉬운 일도 아니고, 책보고 따라 하기도 쉽지 않죠. 그래도 일단 이 정도만 해도 상당한 효과를 볼 수 있죠. 그만큼 투명한 개발이라는 것은 대단한 변화를 가져옵니다. 그리고 나면 각 개발자들의 역량 향상인데, 이는 대단히 오래 걸리는 일입니다. 

가내수공업형태를 못 벗어난 여러 SW회사들이 미국에 진출한다고 해서 수많은 실패를 경험한 것을 잘 알고 있습니다. 동네 축구 좀 한다고, 월드컵에 나가 보겠다고 하는 것처럼 무모하게 들리기도 합니다. 물론 동네축구에도 정말 뛰어난 인재들이 있습니다. 하지만 박지성이 기회 없이 계속 동네 축구만 했다면 세계적인 선수가 못되었겠지요. 조직은 전문화가 되고 개발자는 진짜 개발자에게 필요한 역량을 키워나가고 해야만 그나마, 게임이 좀 될 수 있습니다.  

이 와중에 이를 해결해보고자 방법론들을 기웃거린다면 문제가 될 수 있습니다. 왜냐하면 방법론에서는 조직이나 시스템에 대해서는 별로 가이드를 하지 않기 때문에 엉뚱한 곳에서 헤맬 수가 있습니다. SW를 효율적으로 잘 개발하는 방법은 특별한데 있지 않습니다. 우리가 소홀히 하는 아주 기초적인 것들에 있습니다. 기본에 충실해야 할 때입니다.

항상 보스가 먼저 말하게 하라.

오늘 재미있는 글을 봤습니다. 그래서 공유를 할까 합니다.

A junior manager, a senior manager and their boss are
on their way to a meeting.
길이었다.

On their way through a park, they come across a wonder lamp.
이들은 공원을 지나다가 신기한 램프를
발견했다.
They rub the lamp and a ghost appears.

The ghost says,
유령이
말했다.
"Normally, one is granted three wishes but as you are three, I
will allow one wish each"

들어주겠다."
So the eager senior manager
shouted,
그러자 성격 급한 고참 부장이 소리쳤다.
"I want the
first wish. I want to be in the Bahamas , on a fast boat and have no worries."
“제가 먼저 소원을 빌게요. 저는 바하마 제도에 가서 쾌속정을 타면서 근심․걱정을 떨쳐버리고
싶어요.”
Pfufffff, and he was gone.


이번에는 신참부장이 얌전히 있지 못하고 소리쳤다
"I want to be in
Florida with beautiful girls, plenty of food and cocktails."
“저는 플로리다에 가서 맛있는 음식과 칵테일을 마시면서 예쁜 여자들과 지내고
싶어요.”
Pfufffff, and he Was also gone.
휭 소리와 함께
후임 과장도 사라졌다.
The boss calmly said,
그러자 사장이 나직한 목소리로 말했다.
"I want these two idiots
back in the office after lunch at 12.35pm."
“나는 이
멍청한 두 녀석이 점심 먹고 오후 12시 35분까지 사무실로 돌아오길 바랍니다.”

SPEAK FIRST."
* 이야기의 교훈: “항상 윗사람에게 먼저 말할 기회를 양보하라.

신참 부장과 고참 부장, 그리고 사장이 회의장으로 가는

 램프를 문지르자 한 유령이 나타났다.

"보통 한 명에게 세 가지 소원을 들어주지만, 너희는 셋이니 한 명당 하나씩 소원을

휭 소리와 함께 고참 부장은 사라졌다.

Now the junior manager could not keep quiet and shouted

* MORAL OF THE STORY IS: "ALWAYS ALLOW THE BOSSES TO 

(출처 영어등대이찬승)

우리는 개발자가 테스트도 다 해요.

별도의 테스트팀이 없는 회사는 정말 많습니다.

별도의 테스트팀이 없이 개발자가 또는 팀장이 테스트에 참여하는 이유는 개발자가 아니면 제품의 기능을 속속들이 알 수 없어서 테스트를 하기가 어렵기 때문입니다. 이렇게 되는 이유는 제품의 스펙이 따로 문서화되어 있지 않기 때문에 개발자가 아니면 스펙을 알지 못하기 때문입니다.

하지만, 개발자는 인건비도 비쌀 뿐더러 테스트를 잘 하지도 못합니다. 그리고 아무리 테스트 능력이 있는 개발자라고 할지라도 자신이 작성한 기능을 테스트 하는 것은 좋은 방법이 아닙니다. 본인은 내부 동작방식을 잘 알기 때문에 기능이 정상적으로 동작하는 방식 위주로 테스트를 하기 마련입니다.

테스트는 반복적이고 전문적인 작업이기 때문에 개발자가 담당하고 있는 이상 정상적으로 이루어지고 있다고 보기 힘듭니다. 

테스트팀을 따로 두기 위해서는 기본적으로 제품의 스펙이 있어야 합니다. 그렇지 않다면 테스트 팀은 그냥 Random 테스트를 마구 해주는 아르바이트생 수준의 역할 밖에 할 수가 없게 됩니다. 실제 수많은 테스트 팀들이 그 정도 수준에서 밖에 테스트를 할 수 없는 열악한 상황에서 일을 하고 있습니다.

기본적으로 제품에 스펙이 존재를 해야 이를 토대로 테스트케이스를 만들어 낼 수 있고, Regression Test가 가능해 집니다. 그리고 테스트팀이 있다면 테스트 자동화에 대해서 좀더 연구를 하게 되고 테스트 효율성을 높이기 위한 작업들을 진행할 수 있습니다.

테스트팀을 두는 것이 비용을 줄이면서도 제품의 품질을 높일 수 있는 방법입니다. 개발 조직을 효율적으로 운영하고 싶으면 전문 테스트팀에 대해서 심각하게 고려해봐야 합니다.

사업부가 소프트웨어 조직에 미치는 영향

주변 소프트웨어 회사에서 사업부 형태의 조직을 접하는 것은 어려운 일이 아닙니다.

사업부라는 조직 구조가 꽤 인기를 끈 것은 사실입니다.

사업부란 특정 시장에 집중하고 시장의 요구에 빠르게 대응하기 위해서 만든 특수한 형태의 조직입니다.

보통 사업부는 상당히 많은 독립권을 가지고 있고 대부분의 결정을 사업부 내부에서 독립적으로 할 수 있습니다.

하지만 작은 회사를 사업부로 나눠서 각 사업부에 독립적인 책임과 권한을 주게 되면 득보다 실이 더 많아집니다.

하지만 사업부가 가지고 있는 단기적인 성과에 대한 욕심 때문에 사업부 조직 형태에 현혹이 되곤 합니다. 하지만 장기적으로는 잃는 것이 더 많을 수 있습니다.

사업부는 장점도 가지고 있는 조직 구조이지만 다음과 같은 단점들을 가지고 있습니다.

• 사업부 간에 지식과 정보가 서로 공유하기 쉽지 않다.
• 사업부 간에 인력을 공유하기가 어려워져서 한쪽 사업부의 인력이 모자라도 인력을 공유하는 등의 효과적인 인력활용이 어렵다.
• 사업부 간에 기반시스템이 달라지고 개발 표준이 상이해져서 전사적인 개발 효율이 떨어지고, 미래에 다시 통합을 하려고 해도 쉽지 않게 된다.
• 영업 위주로 개발을 하게 되어서 제품의 아키텍처가 점점 취약해진다. 버그가 많아지고, 시간이 흐를수록 신규 개발보다는 유지보수에 시간을 많이 소비하게 된다.
• 단기적인 성과에 집착하여 개발자들의 역량 향상에 소홀해지고 장기적으로는 개발 생산성이 떨어진다.
• 각 기능 조직의 인원이 분리되어 사업부끼리 기능이 중복되고 각각의 전문성도 떨어진다.
• 사업부의 이익과 회사의 장기적인 이익이 서로 일치하지 않을 수 있다.

사업부를 시행하기 적당한 조직의 크기는 몇 백명 단위가 아닙니다. 몇 천명, 몇 만명의 조직 정도의 규모가 되어야 사업부를 시행할 수 있는 조직이라고 할 수 있습니다.

조직규모가 대단히 크거나 특수한 시장 상황에 대응하기 위한 특별한 목적이 있는 경우라면 상관이 없지만, 회사의 규모가 몇 백명 이하라면 개발조직은 한 조직에 속해서 관리되는 것이 좋습니다.

이미 사업부를 시행하고 있는 조직이라면 각 사업부의 개발 및 기술 전체를 통제할 수 있는 조직이나 CTO가 필요합니다. 그리고 가능하면 개발 조직은 하나로 합쳐서 전사적인 개발조직으로 움직이는 것이 좋습니다.

사업부 조직으로 인해서 개발조직이 이미 통합이 어려운 상태라면 개발 조직을 쪼갤 때보다도 몇배의 배용을 치뤄야 합니다.

따라서 개발조직은 장기적인 안목으로 신중하게 다뤄야 합니다.

우리나라에는 전지전능한 슈퍼 개발자가 있다.

여러 소프트웨어 회사를 컨설팅하다보면 아주 많은 개발자들을 만나게 됩니다. 

그 중에는 전지전능한 슈퍼 개발자를 만나게 됩니다.

코딩, 설계, 분석, 테스트, 기획, 고객 전화응대, 고객 지원, 프로젝트 관리, 일반 관리, 아키텍처 등등 엄청나게 많은 일을 하는 개발자들을 보게 됩니다.

이들은 대부분 팀장 쯤 됩니다.

어떻게 생각하시나요? 

바람직해 보입니까?

"나도 그런 전지전능한 개발자야 돼야지"라는 생각이 드십니까?

혹시 지금 이렇게 모든 분야의 일을 다 하고 계시나요?

이것은 One man company 얘기가 아닙니다. 

개발자가 100명이 넘는 회사도 이러한 경우를 여럿 봤습니다.

대부분은 회사가 성장과정에서 적당한 때에 조직을 변화시키지 못하고 그냥 달려온 경우입니다.

이런 경우 전지전능한 개발자가 대부분의 기술과 이슈를 꽤 뚫고 있어서 조직이 그럭저럭 굴러갑니다. (개발자들은 몰라도 사장님은 고민 많으실 겁니다.)

모든 길은 로마로 통하듯 모든 기술적인 이슈도 이 전지전능한 개발자를 통해야 해결됩니다.

이런 개발자가 나가면 회사는 망할 것만 같습니다.

이러한 상황이 정상일까요?

어떤 사람도 서로 완전히 다른 Skill set들을 필요로 하는 일들을 동시에 다 잘 수행해 낸다는 것은 불가능합니다. 아주 작은 회사라면 그렇게 해야지요. 다른 대안이 없으니까요.

이렇게 모든 일을 다하는 전지전능한 개발자는 그 모든 업무를 다 잘 못하고 있다고 봐야 합니다. 그건 애초에 불가능합니다.

이들은 예전에는 뛰어난 개발자였습니다. 하지만, 개발 이외의 일들을 하나씩 떠 맡으면서 각 분야의 일들의 전문성이 점점 떨어지게 됩니다. 그리고 각 일의 Switching cost가 만만치가 않습니다. 이일하다 저일하다하면 그냥 시간이 지나가버리지요. 톰 디마르코는 몰입에는 15분의 시간이 필요하다고 했습니다. 전화한번만 받아도 15분은 그냥 추가로 까먹는거죠.

심지어는 테스트, 고객 전화응대, 고객 지원까지 한다는 것은 100원의 돈을 받으면서 20원짜리 일을 하는 것과 같습니다. 그런 일은 싸게 고용할 수 있는 사람을 시켜야지요. 그리고 기획 같은 일은 전문성이 부족하여 제대로 수행하지도 못합니다. 

결국 이 개발자는 다른 소프트웨어 회사에 가면 별로 가치 없는 개발자가 되고 맙니다. 분야가 달라지면 Domain Knowledge에 의한 경쟁력을 잃고, 개발 실력도 경력에 걸맞지 않게 떨어지고 어느 것 하나 특출난게 없게 됩니다. 관리자로 가야 할까요? 그래서 회사에 꼭 붙어 있으려고 하고, 정치를 하면서 세력을 키우고, 회사의 개혁이나 변화를 반대하고, 골치덩어리 영웅이 되고 맙니다.

회사는 이들에 의존도가 커져서 리스크를 감당할 수 없는 수준에 이르게 됩니다.

이들이 등돌리면 회사는 휘청합니다. 

이것이 개발자 탓일까요? 아니면 회사 탓일까요? 

네, 회사 탓입니다. 회사는 개발자가 실력을 발휘할 수 있도록 여건을 조성해주고 훈련도 시켜줘야죠.

그런데 맨땅에 개발자가 북치고 장구치고 다 하다 보니까, 어쩌다보니 그렇게 된 것이지요.

그럼 어떻게 해야 할까요?

조직이 작을 때부터 나중에 커질 때를 대비해야 합니다.

조직이 커지면 언제든지 분리하기 쉬운 업무부터 띄어낼 수 있도록 말입니다.

이렇게 하려면 갖춰야 할 것이 3가지 있습니다.

이는 "프로세스"와 "기반시스템" 그리고 "문서"입니다.

이 3가지가 있어야 개발 조직이 전문적으로 움직일 수 있습니다.

단 제대로 갖춰야지요. (제대로의 의미는 너무 많이 설명해야 하니 앞으로 계속 올리는 글에서 설명하도록 하죠, 그리고 사실 문서는 프로세스에 포함된 것입니다.)

혼자 일을 하더라도 "스펙"을 작성하고 "설계문서"도 작성하고 "Test Case"도 만들어 놓습니다. 물론 남에게 일을 시키는 것보다는 간소화 할 수 있습니다.

인도에 외주를 줄만큼 자세히 작성하는 것은 낭비죠.

그리고 적절한 개발 프로세스를 만들어서 조직이 커질 때마다 그에 알맞게 계속 발전시켜나가야 합니다.

그리고 "소스코드관리시스템"과 "버그(이슈)관리시스템"은 무조건 제대로 갖추고 있어야 합니다.

이전 포스트 참조하세요(기반시스템(Infrastructure System)을 사용하고 계신가요?)

이 모든 것은 혼자 소프트웨어 회사를 한다고 해도 갖추고 있어야 합니다.

프로세스, 문서 얘기가 나오니까 오히려 개발이 늦어질 것 같은가요?

혼자 개발을 해도 이것들은 꼭 필요합니다. 개발이 더 빨라지고, 제품의 품질도 올라가죠.

왜?

지금 이해가 가지 않는 분이라면, 여기서 납득을 시켜드릴 수는 없습니다. 

제 책(소프트웨어개발의 모든 것)을 읽어보시거나 저를 찾아오시면 친절하게 설명드리겠습니다.

각설하고..

그렇게 준비가 되고 나면 회사 커지면 직무를 하나씩 전문화시켜야 합니다.

우선 "테스트팀"을 만드십시오. 회사가 작다면 이들이 Technical Support(고객지원)도 병행할 수 있을 겁니다. 

물론 테스트 직무도 전문화를 시키십시오. Random Test가 아닌 제대로 된 절차에 의한 테스트를 할 수 있도록 훈련시켜야 합니다. 그 방법은 제 책을 포함해서 시중에 좋은 책들이 얼마든지 있습니다.

그리고 개발자가 많아지면 관리자를 나누고, 기획, 프로젝트 관리자, 빌드/릴리즈 역할을 나눠 나갈 수 있을 겁니다. 

아직 "프로세스", "기반시스템", "문서", 이런 것들을 갖추고 있지 않은 회사라면은 조직을 어떻게 바꿔도 결국 그 전지전능개발자에게 커뮤니케이션이 다 몰리고 리스크는 여전할 것입니다.

이렇게 회사를 바꾸려면 개발자나 회사나 모두 "성장통"을 감내해야 합니다.

개발자는 현재 자신이 하는 일에만 가치가 있다고 생각하면 안됩니다. 좀더 큰일을 하기 위해서 과감하게 현재의 일을 버리고 자신이 가장 잘하는 일에 집중해서 더욱 가치를 높여야 합니다.

회사는 이 과정에서 임시적을 생산성이 떨어집니다. 이 기간이 짧게는 5,6개월에서 길게는 1년이 갈 수도 있습니다. 부작용을 최소화 하기 위해서 점진적인 변화를 할 수도 있고, 전문가를 영입하여 한번에 바꾸는 방법도 있습니다.

회사 안에 있으면 경영자나 개발자나 이러한 상황을 잘 느끼지 못하는 경우가 많습니다.

개구리를 냄비 안의 찬물에 넣고 서서히 데우면 뜨거워서 견지디 못하는 순간이 될 때까지 잘 느끼지 못하는 것과 같은 거죠.

그냥 익숙해지는 겁니다.

이런 경우 외부의 전문가가 회사를 분석하는 것이 효과적일 때가 많습니다.

궁금하신 내용이 있으면 언제든지 E-mail([email protected])으로 연락주세요. 궁금증을 시원하게 풀어드리지요. 

장문의 글을 읽어주셔서 감사합니다.

우리나라 소프트웨어 회사에는 Technical career path가 없다.

우리나라에서는 소프트웨어 개발자로 일을 하면서 부딪히는 큰 걸림돌이 있습니다.

"Technical career path가 없다"는 겁니다.

이 말에 바로 무슨 뜻인지 팍 와 닺지 않는 사람은 우리나라의 소프트웨어 환경에 이미 익숙해지신 겁니다.

소프트웨어 개발자들은 일을 열심해도 위로 올라갈 데가 없는 경우가 대부분입니다.

그래서 팀장도 되고, 관리자도 되고 다른 직종으로 점점 옮겨가게 됩니다.

그러다 보면 기술과는 점점 멀어지게 됩니다.

뛰어난 기술자들의 보석과 같은 실력을 썩히는 거지요.

대부분의 소프트웨어 회사에서는 Technical Track과 Management Track를 구분해야 한다는 사실을 인식하지 못하고 있습니다. 두 Track은 완전히 다른 것이고 서로 잘 호환 되지도 않습니다.

지금까지 수많은 회사의 소프트웨어 컨설팅을 하면서 Technical career path가 제대로 있는 회사를 거의 접하지못했습니다. Technical career path가 제대로 있다고 하면 CTO급, 이사급까지 차례대로 거쳐 올라갈 수 있는 단계가 정의가 되어 있어야 합니다.

우리나라의 경영자들은 개발자가 고참이 되면 팀장이 되고 여러 개발자를 거느리고 나중에 부서장이 되고 하는 것이 문제라는 생각을 하고 있는 경우는 많지 않습니다.

개발자는 개발을 잘하는 것이고, 관리자는 관리를 잘하는 것이지요.

그래서 개발자는 개발을 관리자는 관리를 해야지요.

그런데, 수평적인 미국의 조직구조에 비해서 수직적인 우리나라의 조직구조에서는 개발자들조차도 고참이 되어서 관리자가 되어서 개발자들을 거느리고 싶어 하기도 합니다. 그래서 힘도 생기고 여태 일한 보람이 있다고 생각하는 경우도 있습니다. 이것은 개발자의 탓이 아니고 "Technical Career Path"가 없기 때문입니다. 그래서 관리자가 되지 않고서는 파워를 가질 방법이 없게 됩니다.

이는 Technical Leading하고는 다릅니다. 점점 일반 관리자가 되어가는 거지요.

Technical career path가 보장된 회사에서 엔지니어들은 관리적인 파워가 아닌 기술적인 파워를 갖습니다. 회사의 기술적인 결정에 대한 파워를 가지고 신참엔지니에게서는 기술적인 존경을 받죠. 미국에서는 연봉도 관리자 path보다 더 높은 것이 일반적입니다.

미국의 소프트웨어 회사에서 채용을 할 때는  엔지니어와 매니저가 완전히 구분되어 있습니다. 엔지니어는 아무리 나이가 먹어도 엔지니어입니다. 엔지니어들은 HR(Human Resource)이슈는 신경쓰지 않습니다. 언제 그런 이슈를 신경쓰고 개발할 시간이 있겠습니다. 누가 아프고, 휴가가야 하고, 엔지니어 새로 채용해야 하고 그런 것들을 신경쓰고 기술에 집중하기는 어렵겠죠. 엔지니어들은 기술적인 이슈가 개발에 필요한 비즈니스 이슈만 신경씁니다. 사람 다루고 평가하고 하는 귀찮은 일들은 관리자 트랙에 있는 사람들이 해줍니다.

외국의 컨퍼런스에 가보셨지요? 저는 할아버지 엔지니어도 만나봤습니다. 정말 재미있지요. 그런 분도 최신 기술동향 다 알고 정말 엔지니어입니다. 

외국에서는 소프트웨어 회사에서 정말로 파워를 가지고 있는 사람들은 이러한 고참개발자들입니다. 이들을 Chief Engineer, Fellow Engineer, Chief Scientist라고 부르며 회사가 구조조정을 해도 관리자들을 잘라도 이러한 핵심 개발자들은 손을 못 댑니다. 다시 회사가 좋아지면 관리자는 다시 뽑으면 되지만, 이러한 개발자를 다시 키우려면 몇 년이 걸릴지 모르기 때문이지요.

소프트웨어 엔지니어의 실력이 한 10년 일하면 완전히 바닥나는 것도 아닙니다. 사실 10년 정도까지는 개발은 잘하는 개발자가 될 수 있죠. 그리고 10년 이상이 되면 시야도 넓어지고, 회사의 전략적인 결정이나 중요한 아키텍처를 결정할 수 있는 실력과 경험을 고루 갖추게 됩니다. 그런데, 그런 사람을 우리나라에서는 관리자로 만들어버리는 경우가 허다하지요. 

내 옛날 직장에서는 "백발이 휘날리도록 개발을 할 수 있는 개발자"를 뽑은 적이 있습니다. Technical career path를 평생 보장하겠다는 것이지요. 이 문구에 감동을 받아서 지원한 개발자도 꽤 많았습니다. 그만큼 많은 개발자들이 관리자로 가지 싫어 한다는 방증이기도 합니다.

이것이 개발자 혼자 몸부림 친다고 해결될 일이 아닙니다. 경영자가 Technical career path를 보장하는 것이 회사에 왜 이익인지를 깨닫고 회사에서 제도적으로 만드는 것 밖에 없습니다. 물론 직원이 4,5명 이하인 회사에서는 다들 멀티플레이어인기 때문에 이러한 제도가 의미가 없겠죠. 하지만 조직이 조금만 커지면 분명히 Technical career path를 명확히 해서 최고의 개발자를 키워내야 합니다.

(아래 분들은 Software Engineer들입니다.)