검색어 개발조직에 대한 글을 관련성을 기준으로 정렬하여 표시합니다. 날짜순 정렬 모든 글 표시
검색어 개발조직에 대한 글을 관련성을 기준으로 정렬하여 표시합니다. 날짜순 정렬 모든 글 표시

2009년 2월 10일 화요일

우리는 당장 써먹을 수 있는 경력 개발자 위주로 뽑아요.

언제부터인가 소프트웨어 개발자를 경력 개발자 위주로 채용하는 것이 일반화 된 것 같습니다.
물론 다른 업계도 마찬가지이지만, 당장 써먹을 수 있는 경력직을 선호하는 것은 사실입니다.

그렇게 경력직 위주로 개발자를 채용하다가 개발팀의 조직 구조가 효율적이지 못하게 변하는 경우를 종종 보게 됩니다. 소규모 개발조직이라면 어떠한 구조라도 별 상관이 없다면 일정 규모 이상의 개발조직은 각 직급별 적정한 분포를 가지는 것이 효율적입니다. 

그럼, 경력 개발자 위주로 채용을 하다가 종종 벌어지는 조직 구조의 변화의 예를 하나 들어 보겠습니다.


진화 단계설명
탄두형회사의 초기에 일반적인 조직 구조 형태입니다.
항아리형신입 개발자보다 경력 개발자를 위주로 채용을 하면서 자연스럽게 아래 부분이 줄어들게 됩니다. 또 아래 계층이 충성도가 부족하여 더 많이 퇴사를 하게 됩니다.
스페이드형항아리형이 점점 심해지면 뒤늦게 개발 조직이 비효율적으로 변한 것을 깨닫고, 신입 직원을 다시 뽑기 시작합니다. 이러면서 조직은 스페이드형으로 변합니다.
오뚜기형다시 정상적인 조직 구조로 바꾸려고 해도 비어있는 중간 계층은 쉽게 메꾸기가 어렵습니다. 즉, 회사를 이끌어가는 초창기 멤버와 고참들과 뽑은지 얼마 안되는 직원들이 개발조직의 주를 이루게 됩니다. 그래서 정상적인 분업이 이루어지지 않습니다. 일은 고참들에게 몰리고, 하층 개발자들은 기대에 못미치는 성과를 내고 있습니다.

여기서 예로든 하부 조직이나 중간 조직이 빈약한 구조가 개발에 전혀 지장을 주고 있지 않다면 특수한 개발 조직이거나 각개격파형 개발조직 구조일 것입니다. 또는 주먹구구이거나요.
대부분의 조직은 각 기능별 계층별로 업무가 나눠지며, 아래 계층의 개발자가 인원수로는 더 많이 필요하게 됩니다. 하지만 그렇지 못한 경우 그러한 Value가 낮은 일까지 고참들이 수행을 해야 하고, 이 과정에서 자연스럽게 이루어지는 교육 및 기술 전달이 이루어지지 않는 악순환이 벌어집니다. 이 과정에서 개발 팀의 생산성은 낮아지게 되고, 미래 전만도 어두워집니다.

그럼에도 불구하고 경력개발자만을 위주로 채용하는 이유는 여러가지가 있습니다.
  • 단기적인 이익을 내려는 경영층의 조급증
  • 신입 개발자를 채용해도 효과적으로 교육시킬 수 있는 교육 시스템 부재
  • 3,4년 미래도 내다보지 못하는 HR Plan
  • 주먹구구 식으로 개발을 하고 있기 때문에 체계는 필요 없고, 무조건 경험 많고 능력 있는 개발자만 필요한 경우
이미 회사를 위해서 오랫동안 헌신한 개발자들이 개발은 잘하고 업무관련 지식은 뛰어난데, 소프트웨어 전문가로서는 턱없이 모자라는 경우가 흔합니다. 오랫동안 각개격파식으로 혼자서 북치고 장구치고 하는 식으로 개발들을 많이 해왔기 때문에 이런 일들이 일어납니다. 이경우 이러한 고참 개발자들이 다른 회사로 이직을 할 경우 그 가치가 현저히 떨어지는 경우가 많습니다. 전문가로서의 역량은 부족하기 때문입니다. 자칫하면 이러한 공신들이 희생될 수도 있고, 골치덩어리가 될 수도 있습니다.

그러면 어떻게 해야 할까요? 

적어도 개발자를 채용할 때는 오늘 당장 필요해서 뽑는다는 생각만 가지고 채용하는 것은 위험합니다. 적어도 몇 년을 내다보는 채용 계획이 있어야 합니다. 그리고 계획에 따라서 항상 채용을 위한 노력을 기울여야 합니다. 그리고 이미 채용한 개발자와 미래에 채용할 개발자들의 경력 개발 계획을 갖추고 있어야 합니다. 이것만 따로 돌아가는 것이 아니고 회사의 개발 프로세스와 조직 등 모든 것이 맞물려 돌아가야 개발자도 성장을 하면서 자연스럽게 생산성이 높은 조직을 유지할 수 있게 됩니다. 사람에서 사람에게로 고참에서 신참에게로 기술과 지식이 전달되고 조직이 계속 성장하려면 기반시스템, 개발문화가 필수적입니다. 전혀 체계가 없는 개발조직이라면 지금이라도 하나씩 갖춰나가는 수 밖에는 없습니다

이것을 해결할 끝내주게 좋은 방법은 없습니다. 가장 효율적인 것부터 찾아서 하나씩 바꿔나가는 겁니다.

2008년 12월 23일 화요일

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

주변 소프트웨어 회사에서 사업부 형태의 조직을 접하는 것은 어려운 일이 아닙니다.
사업부라는 조직 구조가 꽤 인기를 끈 것은 사실입니다.
사업부란 특정 시장에 집중하고 시장의 요구에 빠르게 대응하기 위해서 만든 특수한 형태의 조직입니다.
보통 사업부는 상당히 많은 독립권을 가지고 있고 대부분의 결정을 사업부 내부에서 독립적으로 할 수 있습니다.
하지만 작은 회사를 사업부로 나눠서 각 사업부에 독립적인 책임과 권한을 주게 되면 득보다 실이 더 많아집니다.
하지만 사업부가 가지고 있는 단기적인 성과에 대한 욕심 때문에 사업부 조직 형태에 현혹이 되곤 합니다. 하지만 장기적으로는 잃는 것이 더 많을 수 있습니다.
사업부는 장점도 가지고 있는 조직 구조이지만 다음과 같은 단점들을 가지고 있습니다.

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

사업부를 시행하기 적당한 조직의 크기는 몇 백명 단위가 아닙니다. 몇 천명, 몇 만명의 조직 정도의 규모가 되어야 사업부를 시행할 수 있는 조직이라고 할 수 있습니다.
조직규모가 대단히 크거나 특수한 시장 상황에 대응하기 위한 특별한 목적이 있는 경우라면 상관이 없지만, 회사의 규모가 몇 백명 이하라면 개발조직은 한 조직에 속해서 관리되는 것이 좋습니다.
이미 사업부를 시행하고 있는 조직이라면 각 사업부의 개발 및 기술 전체를 통제할 수 있는 조직이나 CTO가 필요합니다. 그리고 가능하면 개발 조직은 하나로 합쳐서 전사적인 개발조직으로 움직이는 것이 좋습니다.
사업부 조직으로 인해서 개발조직이 이미 통합이 어려운 상태라면 개발 조직을 쪼갤 때보다도 몇배의 배용을 치뤄야 합니다.
따라서 개발조직은 장기적인 안목으로 신중하게 다뤄야 합니다.


2010년 1월 5일 화요일

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

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


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

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

조선일보기사에서 인용

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

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

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

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

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

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

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

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

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

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

2012년 9월 3일 월요일

Technical Career Path를 보장하는 방법

그 동안 개발자 경력에 대한 글들을 여러 건 작성했다. 많은 독자들이 문제 인식에 공감을 했지만 여전히 해결책은 쉽지 않다. 그래서 여기 방법을 제시하고자 한다. 소프트웨어 회사들이 어떻게 하면 Technical Career Path를 보장할 수 있을까?

첫째, 경영자 의식의 변화이다.

경영자가 개발자의 경력을 보장하는 것이 회사에 얼마나 큰 이득이 되는지 깨닫지 못한다면 개발자가 꾸준히 개발만 할 수 있도록 노력할 리가 없다.

축구는 체력이 떨어지는 30대 중후반이면 더 이상 선수로 뛰기 어렵지만, 소프트웨어 개발자는 체력과 상관없이 평생 시간이 흐를수록 점점 더 뛰어난 개발자로 일할 수 있다. 이렇게 뛰어난 선수로 일할 수 있는 개발자들을 관리나 하라고 낭비하지 않고 계속 선수로 뛸 수 있도록 회사에서 지원을 해야 한다는 것을 경영자들이 절실히 깨달아야 한다.

아직은 경영자들이 이같은 인식이 부족하거나 막연히 개념만 인지하고 현실은 다르게 행동을 하는데 주위에서 설득하려는 노력이 필요하다. 이 칼럼들을 공유해도 좋고 외국의 사례를 보여주는 한 방법일 것이다. 이는 회사를 위하고 개발자도 위하는 길이다.

둘째, 개발 조직의 변화이다.

개발 조직은 워낙 회사마다 서로 달라서 하나의 형태를 지켜야 한다고 말할 수는 없다. 하지만 개발 조직이 전문 개발자들이 제대로 일할 수 있는 구조가 되어야 한다. 우선 개발팀장, 개발리더, 매니저 등 구분 없이 마구 섞여서 일하는 것은 지양해야 한다.

조직이 아주 작아서 혼자 다해야 하는 경우를 제외하고는 관리자와 개발자는 구분을 하자. 팀이 커져서 관리 일이 점점 많아지면 더 이상 개발자가 개발을 겸해서 하기는 어렵다. 전문 관리자를 두는 것이 좋고, 프로젝트에서도 프로젝트매니저를 따로 두는 것이 좋다. 개발자는 개발에 전념할 때 가장 높은 성과를 낸다. 개발 외의 일은 관리자나 프로젝트매니저가 맡아야 한다.

셋째, 공정한 평가이다.

소프트웨어 개발자로 공정한 평가를 받기 매우 어렵다. 그래서 평가 대상보다는 평가자가 되려고 하는 경향이 있다. 공정한 평가가 대단히 어려운 일이지만 나름대로 객관적인 근거에 의한 평가를 위해서 노력해야 한다. 개발자가 어찌 해볼 수 없는 이유로 평가에서 불이익을 받는다면 개발을 계속 하기가 싫어질 것이다. 소스코드관리시스템과 이슈관리시스템의 기록을 활용하고 개발 일정 준수 등의 지표를 활용하는 것도 좋은 방법이다.

넷째, 적절한 대우이다.

많은 회사에서 팀장이 되고 관리자가 되어야 더 높은 연봉을 받을 수 있다. 그 주된 이유는 관리와 개발의 분리가 안되어 있어서 구분이 안되기 때문이다. 관리를 하지 않고 평생 개발을 한다고 해서 연봉이나 대우에서 불이익을 받아서는 안된다. 오히려 동일 경력에서 개발자가 관리자보다 더 높은 연봉을 받는 것이 맞을 수 있다. 관리자나 개발자나 자신의 전문분야에서 회사에 기여하는 만큼의 적절한 대우를 받아야 한다.

다섯째, Career Path 제공이다.

회사에서 다양한 Career Path를 제공해야 한다. 개발자는 이들 중에서 적절한 시점에 선택을 할 수 있어야 한다. 계속 개발자로 경력을 발전시켜 나갈 수도 있고 관리자나 프로젝트매니저가 될 수도 있다. 또는 다른 일을 맡을 수도 있다. 한번 개발자 경력에서 벗어나면 다시 돌아오기 어려우므로 신중하게 결정해야 한다.

여섯째, 개발문화, 개발 프로세스, 기반시스템이다.

너무 광범위한 내용이라서 다 설명하기는 어렵다. 개발자가 제대로 일하기 위해서는 공유를 기반으로 한 투명한 개발문화와 적절한 개발 프로세스가 필요하다. 또한 개발에 필요한 기반시스템을 제대로 갖추고 있어야 한다. 아무것도 갖추지 못한 회사에서는 개발자가 아무리 개발을 오래해도 가치를 높이기가 어렵다.

일곱째, 롤모델이 필요하다.

롤모델이 있다면 개발자들에게 확실한 길을 보여줄 수 있다. 하지만 무늬만 개발자가 아닌 진짜 개발자를 외부에서 영입하기는 쉽지 않다. 내부에서라도 개발자들의 롤모델을 만들도록 노력해 보자. 회사에서 가장 뛰어난 개발자들에게 관리 일은 덜어내고 개발에 전념할 수 있도록 해주고 회사의 제도가 이를 뒷받침하도록 하자. 회사의 개발 조직이 더욱 탄탄해 질 것이다.

개발자 경력 보장 문화는 개발자들의 인생이 달린 일이다. 아직은 척박하지만 우리가 하나씩 바꿔나가야 한다. 가장 어려운 일은 경영자를 설득하고 깨닫게 하는 일이다. 고양이 목에 방울달기 같은 일이지만 어렵다면 주변이나 전문가의 도움도 받아보자. 지금은 3D 취급하는 사람들도 있는 소프트웨어 개발이 좀더 좋은 대접을 받기 위해서는 개발자 경력 보장이 중요한 단초가 될 것이다.

이글은 Tech it에 기고한 글입니다.

2010년 3월 2일 화요일

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2012년 7월 9일 월요일

무늬만 개발자

우리나라에서 소프트웨어를 개발한지 10년이 넘은 개발자 중에서 진짜 개발자는 생각보다 적다. 15년쯤 지나면 자신은 스스로를 개발자라고 생각할지 몰라도 진짜 개발자인 경우는 급격히 줄어든다. 대부분은 개발과 관리의 경계에서 애매한 포지셔닝을 하다가 다시는 개발로 돌아오지 못하곤 한다.

그럼에도 자신은 개발자라고 착각을 하는 경우가 많다. 또는 자신을 Architect라고 우기기도 한다.

선임급 개발자를 채용하기 위해서 인터뷰를 하면 이런 "개발자가 아닌 무늬만 개발자"를 자주 볼 수 있다.

매일 수많은 회의에 쫓겨 다니고, 온갖 보고서를 만들고, 수시로 경영진에게 보고하고, 팀원들 관리하고 평가하느라고 시간을 다 보내면서, 스스로는 개발에 관해서 아는 것은 많다고 생각해서 개발할 때마다 간섭하고 스스로 뛰어난 Architect라고 생각한다.

이런 사람들은 개발을 좀 안다고 해도 절대로 개발자가 아니다. 개발과 관리의 차이에 대한 개념도 희미한 상태이다. 대부분은 개발자로 다시 돌아갈 수 없는 상태이다.

절대로 "개발"과 "관리" 둘 다 잘할 수는 없다.

우리나라 대부분의 기업에서 본부장, 부문장, 부서장쯤 되면 이러한 상태에 이르게 된다.  그래도 팀장급에서는 개발자의 모습을 아직도 간직하고 있는 경우가 종종 있다.

하지만 팀장급 이상으로 올라가게 되면 개발자이고 싶은 관리자가 되게 된다. 물론 외형적으로도 완전히 관리자를 선언한 사람도 있겠지만, 여전히 개발자이고 싶은 사람들도 매우 많다.

이렇게 되는 결정적인 이유는 경영자의 개발조직 관리에 대한 오해에서 비롯된다. 경영자는 개발조직을 관리하는 관리자는 개발을 매우 잘 알아야 하기 때문에 가장 뛰어난 개발자들이 관리를 하는 것이 옳다고 생각한다. 그래서 경험 많은 선임 개발자들에게 본부장, 부문장, 부서장을 맡기곤 한다.

개발조직을 관리하는 관리자는 개발에 대해서 개발자만큼 잘 알 필요가 없다. 개발자가 개발에 대해서 아는 정도와 관리자가 알아야 하는 정도는 엄청나게 다르다. 그런데 경영자는 이 둘을 같은 것으로 착각하곤 한다.

개발을 잘하는 개발자는 관리는 전혀 하지 않고 개발에 몰두할 때 가장 높은 가치를 창출한다. 경영자의 착각 속에 개발자는 점점 잘 하지도 못하는 관리 일에 치중하게 된다. 자연스럽게 회사는 개발 파워를 잃게 된다. 그럼 남는 것은 정치적인 경쟁밖에 없게 된다. 불쌍한 개발자들이다.

이렇게 관리자화 된 개발자들은 이직도 곤란하게 된다. 동일한 분야가 아니라면 이직을 해도 회사에 도움이 별로 안된다. 다른 분야로 이직을 한다면 관리 능력이 중요한데 사실 관리는 전문 관리자보다 훨씬 못하기 때문이다. 이미 전문 개발자는 아니기 때문에 다른 분야에서 개발자로서 활약하기도 어렵다. 정말 어중간한 위치기 된다.

결국 그 회사에서 관리자의 길을 걷거나 선택할 옵션이 별로 없게 된다.

물론 개발자 본인이 스스로 이런 선택을 하지 않았지만 결국 이런 결과에 이르는 것이 우리나라 개발자들의 안타까운 현실이다.

개발자가 원하고 실력이 된다면 은퇴할 때까지 개발자의 경력이 보장되는 외국의 상황은 부러울 따름이다.


주변의 환경을 무시하고 스스로 개발자로 계속 살아남는 다면 대단한 결심이 필요할 것이다.
하지만 결국 이런 개발자들이 언젠가는 대우를 받을 수 있을 것이다. (당장은 글쎄 …)
그런 환경을 만들고 싶다.

이글은 Tech it!에 기고한 글입니다.

2013년 11월 19일 화요일

서열문화가 SW산업 망친다. (개발문화 시리즈5)



이번 개발문화 이야기는 '서열이 지배하는 조직문화'다. 

우리나라는 옛날부터 서열을 매우 중요시 한다. 사람들이 모이면 서로 나이를 비교하고 서열을 정한다. 회사에서도 대리, 과장, 부장이 되려고 열심히 일한다. 직급에 따라 업무가 달라지고 급여도 서열에 비례한다. 물론 많은 변화가 있어 왔지만 뿌리깊게 자리 잡은 서열문화의 뿌리는 여전히 튼튼하다.

소프트웨어 산업에서도 서열 문화는 조직 문화에 많은 영향을 주었고 그로 인해서 많은 문제와 생산성 저하를 불러일으켰다. 소프트웨어 개발자도 직급에 따라 서열화 되며 주로 윗사람이 일을 시키고 아랫사람은 시키는 대로 일하는 형태가 많다.

이러한 수직적인 조직문화는 수평적인 조직 문화에 비하여 소프트웨어 개발에는 적합하지 않다. 자율성과 창의성이 강조되는 소프트웨어 개발 현장에서 수직적인 조직문화는 자칫 창의력을 저해하고 수동적인 마인드를 형성할 수 있다. 

내 경험에 의하면 소프트웨어 개발에 적합한 효율적인 조직은 수평적인 조직이다. 각자 역할을 나눠서 일을 하지만 상하관계는 아니다. 업무도 그렇게 수평적으로 전문화된다. 역할은 프로젝트 규모에 따라 세분화되기도 하고 크게 몇 개로 나뉘기도 한다. 

큰 프로젝트에서는 아주 많은 역할로 나뉜다. 소프트웨어 아키텍트, 프로그래머, 프로젝트 매니저, 프로덕트 매니저, 리스크 매니저, 빌드 엔지니어, 테크니컬 라이터 등 여러 역할이 있지만 이들은 상하 관계가 아니다. 전문화된 일을 하는 것이다.

그런데 수직적인 조직문화를 가진 소프트웨어 회사에서는 이들 역할과 비슷한 이름을 사용한다고 하더라도 수직적인 관계는 그대로 유지가 된다. 윗사람이 시키고 아랫사람은 지시에 따르는 스타일로 일을 한다. 그리고 전문적인 역할 구분 없이 윗사람이 모든 것을 결정할 권한을 갖는 경우가 많다.

개발자는 신참이나 고참이나 모두 소프트웨어 엔지니어다. 고참이 되면 그냥 시니어 엔지니어가 되는 것이다. 과장, 부장이나 연차에 따라 책임, 수석이 되는 것은 서열 중심의 조직에서 나타나는 현상이다. 물론 회사 대표 개발자에게는 수석 사이언티스트(Chief Scientist), 펠로우 엔지니어(Fellow Engineer) 등 특별한 타이틀이 있을 수 있지만 모두 소프트웨어 엔지니어다.

그 외에도 태크니컬 스티어링 커미티(Technical Steering Committee)나 아키텍트 그룹(Architect Group) 등의 조직이 있을 수 있지만 능력과 경험에 따른 역할의 구분이지 이들을 윗사람으로 생각하지는 않는다. 

부서간 커뮤니케이션에서도 서열은 많은 영향을 미친다. 합리적인 결정보다 서열에 의한 결정이 종종 발생한다. 대리급 개발자가 영업부서의 부장에게 직급으로 눌려서 합리적인 결정을 못하기도 한다. 이렇게 서열문화는 생산성을 떨어뜨리고 개발자의 전문성 향상을 저해한다. 

최근에 몇몇 젊은 회사에서 서열 파괴 시도를 하고 있다. 직원들간 직급을 모두 없애고 서로 이름을 부르며 나이와 상관없이 모두에게 존칭을 사용하는 것이다. 이러한 시도는 상당히 긍정적으로 평가한다. 물론 부작용이 없는 것은 아니다. 연공서열을 파괴 했을 뿐이지 나이 어린 사람이 또 윗사람이 되어서 서열화가 되는 경우도 발생한다.

결국 서열을 없애고 조직을 수평화시키는건 제도만으로 완성되는 것이 아니다. 조직이 전문화되고 전문가를 우대하는 문화도 정착이 되어야 한다. 각자 역할에서 전문가로 성장할 수 있고 관리자를 넘보지 않아도 대우를 받으며 일할 수 있어야 한다. 

소프트웨어 산업은 특수성이 강하다. 엄청나게 복잡한 지식산업이면서 예술성이 강하다. 서열에 의한 역할분담이나 지시에 의한 업무 진행은 소프트웨어 개발에 적합하지 않다. 서열보다는 각자의 특성, 실력에 따라서 수평적으로 일을 나눠서 하는 수평적인 조직문화가 필요하다. 

수평적인 조직이라도 다 같이 똑 같은 일을 하는 것은 아니다. 일반적으로 고참은 더 어려운 일을 하고 리뷰도 많이 한다. 대우도 서열보다는 실력에 의해서 차별화 되어야 한다. 그러려면 모든 개발이 투명화 되어 모든 개발자의 실력과 성과가 만천하에 드러나야 한다. 

결국 서열을 없애고 수평적인 조직을 만들기 위해서는 개발 방식 자체도 바뀌어야 한다. 조직뿐만 아니라 프로세스, 시스템도 모두 바뀌어야 한다. 제도만 바꿔서는 실패할 가능성이 크다. 모든 문화는 서로 얽혀 있어서 하나만 바꾼다고 될 일은 아니다. 연관된 모든 문화를 같이 바꿔야 하고 꾸준히 투자해야 한다. 

가장 중요한 것은 경영진의 마인드이다. 그래야 꾸준히 변화의 추진력을 얻을 수 있다. 변화는 1,2년에 마무리되는 것이 아니고 회사가 지속되는 한 끊임없이 투자를 해야 하는 것이다. 

본 칼럼은  ZDNet Korea에 기고한 글입니다.

2009년 10월 1일 목요일

SW가내수공업

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

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

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

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

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

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

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

2014년 5월 23일 금요일

할아버지 개발자를 만나고 싶다

외국 소프트웨어 회사에서는 할아버지 개발자들을 종종 볼 수 있다. 현재도 프로그래밍을 하고 있는 진짜 개발자들이다. 우리나라가 개발자들은 이런 할아버지 개발자를 만나보거나 이야기를 전해 들으면 많이 부러워한다. 

대부분의 개발자들은 경력이 쌓이면서 자연스럽게 관리 업무를 겸하거나 아예 관리자로 전환된다. 관리와 개발업무를 동시에 하는 개발자들도 관리하랴, 회의하랴 바빠서 본인이 가장 잘하며 좋아하는 개발 업무와는 점점 멀어지게 된다. 또 관리를 하지 않으면 회사에서 파워가 줄어들거나 대우도 안 좋기 때문에 자연스럽게 그리고 본의 아니게 관리 쪽 진로를 선택하지 않을 수 없게 된다. 종종 자신은 끝까지 개발만 하겠다고 고집하는 개발자들은 관리 능력, 커뮤니케이션 능력이 떨어지는 괴짜라고 생각하는 이상한 시각도 존재한다. 

S사의 예를 보자. 이 회사는 오래 전부터 개발자 경력을 보장해주고 있다. 제도적으로는 개발자 트랙을 선택한 사람들은 관리를 하지 않고 개발만 계속 할 수가 있다. 하지만 속을 보면 개발자 트랙을 선택하나 그렇지 않으나 큰 차이는 없다. 개발자 트랙을 선택한 경우에도 개발 일에만 집중할 수 없고 그렇지 않은 경우에도 개발과 관리를 겸하게 된다. 개발과 개발이 아닌 일을 명확하게 구분하지 않고 두루뭉술하게 일을 해서 대부분은 개발 경력이 쌓일수록 개발에 집중할 시간은 점점 줄어들게 된다. 

T사의 경우 10년차 이상이 되면 팀장이 되고 파트장을 맡는다. 대부분 회사에서 가장 뛰어난 개발자들이다. 하지만 관리를 조금이라도 맡은 이상 낮에는 개발에 집중할 시간이 거의 없다. 보고서 작성에 회의 참석, 다른 부서와 의견 조율, 이런 일로 하루를 보내다가 저녁이 되어서야 개발 일을 시작한다. 이런 생활을 몇 년 하다보니 자연스럽게 개발 일에서 손을 놓게 되었다. 

이런 회사에 경영자들에게 왜 회사의 가장 뛰어난 개발자들이 개발을 거의 못하는 관리 일을 시키냐고 물어보면 다음과 같은 얘기를 한다. 

“당연한 것 아닌가? 소프트웨어 개발은 워낙 특수해서 개발을 속속들이 잘 알아야 개발 조직을 관리할 수 있다. 그가 우리 회사에서 소프트웨어 개발을 가장 잘아는 사람이다. 그래서 그에게 개발 조직 관리를 맡기고 있고 본인도 그 자리를 원하고 있는 것으로 알고 있다.” 

주변에서 소프트웨어 업계의 유명했던 롤모델들을 보면 지금도 개발을 하고 있는 사람들은 그렇게 많지 않다. 왕년에 개발을 좀 했던 실력자이지만 현재도 개발을 하고 있는 엔지니어는 만나기 힘들다. 왠만한 뚝심으로는 개발자로 남아 있기가 어렵다. 당사자들이 환경에 순응해서 개발에서 손을 놓게 된 경향도 크다 

우리는 각 기업의 최고 개발자였지만 지금은 관리자인 사람들을 종종 만나게 된다. 이들은 대부분 본부장, 센터장, 부서장, 연구소장 등과 같은 직함을 가지고 있다. 이들 대부분은 과거에는 개발자였을지 모르지만, 그리고 지금도 코드를 잘 읽을 수 있을지 모르지만, 관리자로 몇년만 지나면 더 이상 개발자가 아니다.

개발도 잘하고 관리도 잘한다는 것은 착각이다. 관리자가 된 이상 개발에 대해 특히 아키텍처나 구체적인 기술에 대해서 이러쿵저러쿵 참견하는 것은 매우 위험하다. 관리를 잘하는 것이 본인의 업무이고 그것만도 매우 어렵다. 

나는 블로그를 통해서 자신의 회사에서 개발자 경력을 보장하고 있는지 설문 조사를 한적이 있다. 과거 4년동안의 통계를 보면 개발자 경력 보장 제도가 있는 회사는 14%이다. 물론 제도는 있어도 형식적이거나 현실적으로 개발자로 남기 불가능 회사가 많기 때문에 실제 개발자가 경력을 보장받을 수 있는 비율을 훨씬 떨어지게 된다. 한마디로 20년, 30년 개발자로 남아 있기는 낙타가 바늘 구멍 통과하기만큼 어렵다. 

우리나라는 장인정신보다는 관료주의적인 전통이 자리잡고 있어서 전문가보다는 관리자가 더 높은 자리로 인식된다. 그러다 보니 개발자도 분위기에 순응해서 자연스럽게 관리 쪽으로 슬금슬금 넘어가게 된다. 팀장, 부서장이 되어서도 개발에 집중하고 싶어도 주간보고, 월간보고, 업무 분배, 진척확인, 부서간 소통, 보고서 작성, 채용, 사업계획, 평가, 경영자에게 보고 등등 이런 일이 점점 늘어가고 그러다 보면 점점 관리자로 탈바꿈한다. 

개발자가 개발 일에서 떠나는 이유가 또 하나 있다. 개발 프로젝트가 대부분 합리적이지 못하고 무리한 경우가 많아서 몇 년 구르다 보면 야근과 각개전투가 난무하는 전투현장에서 벗어나고 싶게 된다. 개발이 진짜 즐겁고, 개발자로 충분히 대우도 받고 보장을 받을 수 있다면 관리자가 되려고 할까? 개발이 합리적이고 즐겁고 비전이 있어서 개발자들이 남아 있으려고 할 것이다. 

이렇게 고급 개발자들이 떠나게 되면 소프트웨어 생산성은 극도로 낮아진다. 이것은 회사적으로도 국가적으로도 큰 손해다. 뛰어난 개발자들이 관리를 잘 해준다고 해도 소프트웨어 생산성에는 별로 도움이 안된다. 그럼 소프트웨어 개발이 그렇게 관리가 많이 필요한가? 사실 개발팀은 관리할게 별로 없다. 

관리가 많이 필요한 개발팀은 비효율적 팀이라는 것을 단적으로 나타낸다. 단, 프로젝트 관리는 필요하고 전문 프로젝트 관리자가 있을 수 있다. 큰 조직이나 큰 프로젝트는 이보다 더 많은 전문 관리자가 있을 수 있다. 프로젝트 매니저(Project Manager), 리스크 매니저(Risk Manager), 프로덕트 매니저(Product manager), 프로그램 매니저(Program Manager) 등 다양한 전문 업무로 세분화 되기도 한다. 

외국 소프트웨어 회사와 같이 일해본 개발자들은 종종 할아버지 개발들을 만나게 된다. 이들은 50세가 넘어서도 가끔은 60세가 넘어서도 개발을 한다. 코딩도 직접 한다. 

왜 할아버지 개발자가 중요할까? 소프트웨어 개발자는 물론 예외도 일부 있지만 보통 경력이 쌓일수록 실력이 늘어간다. 그래서 회사의 개발자 층은 피라미드 구조를 이룬다. 그런데 가장 뛰어난 늙은 개발자가 관리를 하고 있으면 개발자 피라미드의 중간부터 꼭대기가 아예 없는 사다리꼴 피라미드가 된다. 이런 회사에서 개발 경쟁력을 기대하기는 어렵다.

개발자 본인은 어떨까? 나도 마찬가지지만 대부분의 개발자들은 관리를 극도로 싫어하고 잘하지도 못한다. 개발자들은 개발을 할 때 가장 행복하다. 행복한 일을 하면서 세상을 바꿀 수 있는 개발자라는 직업은 얼마나 멋진 직업인가? 하지만 40, 50세를 넘은 개발자를 찾아보기 어려운 현상은 개발자의 미래를 불투명하게 하고 직업 안정성을 해치고 있다. 

올림픽 금메달을 딴 선수가 20대 중반에 은퇴한 후 직장의 조직에서 불안해하는 것과 별반 다를게 없다. 이런 현상이 개발자 직업 선호도를 낮추는 원인이 되고 있다. 성공한 소프트웨어 회사에서 사장이나 연구소장이 나와서 브리핑하는 것이 아니고 백발의 진짜 개발자가 나와서 개발 이야기를 들려주는 일들이 뉴스에 자주 나와야 한다. 

소프트웨어 개발자의 경력을 보장하는 일은 개인, 회사, 사회적으로 매우 중요하다. 우리나라 소프트웨어 미래의 사활이 걸려있다고 봐도 과언이 아니다. 여기서 가장 중요한 역할은 회사가 해야 한다. 회사에서 개발자의 경력보장이 왜 중요한지 먼저 인식해야 한다.  왜? 거기에 회사의 소프트웨어 개발 경쟁력의 핵심이기 때문이다. 

먼저 개발자와 비 개발자의 트랙을 명확하게 나눠야 한다. 좋은게 좋은 거라고 두루뭉술해서는안된다. 개발자는 철저하게 관리 업무와 잡무에서 보호를 해야 한다. 

앞에서 언급한 보고서 작성, 사업 계획, 예산, 평가 등에 시간을 허비하지 않도록 해줘야 한다. 이런데 10%라도 시간을 빼앗기면 개발 생산성은 50% 이하로 떨어진다. 관리업무와 잡무는 다른 사람을 시키면 된다. 개발자가 10명 이하인 회사도 업무는 나눌 수 있다. 

회사에 롤모델과 멘토도 만들어야 한다. 내가 지금까지 개발자로 남아 있을 수 있던 이유는 롤모델이 있기 때문이다. 개발자는 어떻게 해야 하는지 보고 따라 할 수 있어야 한다. 눈에 보이지도 않는 요정과 같은 모습은 따라 할 수가 없다. 처음에는 어렵겠지만 개발자 롤모델을 키워내야 한다. 개발자에게 모든 것을 원하는 만능 개발자 위주 정책이 없어져야 한다. 한분야의 전문가라도 개발자로 일할 수 있게 해야 한다. 

회사가 준비가 되었다고 다는 아니다. 개발자 개인들도 생각을 바꿔야 한다. 본인의 성향을 보고 진로를 결정해야 한다. 인간의 두뇌 구조는 개발자와 관리자 모두를 잘할 수 있도록 되어 있지 않다. 물론 사회적 제도적 제한이 있어서 본의아닌 선택을 해야 하는 경우도 있지만 본인의 노력도 매우 중요하다. 개발자로 남고 싶으면 끊임없이 새로운 기술을 익혀야 한다. 시야도 넓혀야 한다. 비즈니스도 잘 알아야 한다. 개발자들이 서로 기술을 공유하고 경험을 나누며 같이 성장하려면 피어리뷰가 필수다. 

최고의 개발자들이 관리자나 다른 분야로 떠나고 신참들만 넘쳐나는 개발현장에서 경쟁력을 기대하기는 어렵다. 이런 관료적인 분위기를 소프트웨어 현장에서 없애지 않으면 우리나라 소프트웨어 미래는 없다. 나는 지금도 소프트웨어 경영자를 만나면 개발자 경력 보장이 얼마나 중요한지 역설 한다. 

물론 말 한마디로 30년차 개발자의 모습이 잘 그려지지 않고 실천하기는 어려울 것이다. 개발자 경력보장의 중요성에 대한 인식이 먼저 필요하다. 생각은 바뀌었는데 방법을 모르는 회사는 얼마든지 도와줄 의향이 있다. 그 중요성을 깨달은 것만으로도 이미 50%는 달성한 것이다. 

우리 주변에서도 할아버지, 할머니 개발자를 흔하게 보는 시기가 되면 소프트웨어 개발자들이 행복하게 일하는 세상이 이미 되어 있을 것이다.

2013년 10월 1일 화요일

왜 적은 인원으로 빨리 개발하나…개발문화의 비밀 (개발문화 시리즈 1)

우리나라에서 소프트웨어 개발이 3D 취급을 받는 이유는 여러가지다. 끝을 모를 야근과 낮은 대우 등도 포함되겠지만 좀더 근본적인 이유는 따로 있다.  낮은 생산성 때문이다. 소프트웨어를 개발해서 회사가 돈을 많이 벌고 세계적으로 성공하는 소프트웨어가 많이 나온다면 생산성의 핵심인 개발자에게 당연히 높은 대우를 해주게 마련이다.

하지만 우리나라에서는 크게 성공한 소프트웨어 회사가 많지 않다. 그리고 소프트웨어 회사의 수익률이 별로 높지 않기 때문에 소프트웨어 개발자에게 좋은 대우를 해줄 수 없다. 결국 이런 소프트웨어 개발에 대한 낮은 대우를 극복하기 위해서는 성공하는 소프트웨어, 성공하는 회사가 많이 나와야 한다.

 그럼 성공하는 소프트웨어 회사와 그렇지 못한 회사를 가르는 결정적인 차이는 무엇일까? 판단의 요소는 기술적인 것 외에도 많다. 좋은 아이디어, 적절한 타이밍, 경영, 마케팅 등이 더 중요하지만 이런 것들은 내가 논할 주제는 아니다. 나는 같은 조건에서도 성공하기도 하고 실패하기도 하는 차이가 무엇인지 알아보고자 한다. 성공하는 회사의 특징을 가진 회사가 많다면 성공하는 소프트웨어가 더 많이 나오고 우리나라에서도 소프트웨어 개발이 좀더 좋은 대우를 받을 수 있을 것이다.

 하지만 회사마다 제품이 다르고 환경이 달라서 직접적인 비교는 매우 어렵다. 같은 제품을 만드는 회사라도 다른 요소로 인해서 성공과 실패가 갈렸을 수도 있다. 그런데 필자가 알고 있는 비교하기 좋은 사례가 하나 있어 이를 소개한다.

미국의 유명한 글로벌 소프트웨어 업체가 하나 있다. 이 회사는 여러 나라에 지사를 설립했다. 물론 한국에도 지사를 설립해서 개발자를 채용했다. 한국에서 채용한 개발자들은 본사의 서비스를 지역화(Localization)하거나 한국에 특화된 서비스를 개발했다. 미국 본사에서는 한국에서도 소프트웨어를 개발할 때 본사의 프로세스를 따르도록 종용했으나 한국 개발자들은 이를 따르지 않았다. 한국의 개발자들이 보기에 본사 프로세스는 너무 복잡해 보였다.

이와 관련해 처음에는 본사와 한국 개발자들간 충돌이 있었으나 상황은 곧 바뀌었다고 한다. 본사에서 한국 개발자들의 놀라운 개발 속도에 깜짝 놀라서 더 이상 본사의 프로세스를 강요하지 않았다. 초기에는 척척 빠른 속도로 개발을 하다보니, 모든 상황이 좋았다고 한다. 그런데 몇 년이 지나자 완전히 상황이 또 바뀌었다고 한다. 개발이 너무 느려진 것이다. 그 당시 본사는 호주에도 지사가 있었는데, 한국 지사와 비슷한 일을 하고 있었다.

한국 지사는 호주 지사보다 10배 가까운 개발자를 보유하고 있었고, 개발자들이 야근을 거듭해도 호주지사의 개발속도를 따라가지 못했다고 한다. 자세히 파헤쳐보면 더 많은 사연들이 있겠지만 맥락만 봐도 우리나라에서 소프트웨어를 개발하는 방식의 낮은 생산성을 짐작하게 한다.

 물론 모든 회사가 문제가 있다는 것이 아니다. 우리나라에도 좋은 개발문화를 가진 회사가 많다. 상대적으로 그렇지 않은 회사가 많기 때문에 제기하는 문제로 이해해 줬으면 하는 바람이다.

나는 한국지사의 개발자들이 본사의 개발 프로세스를 따르지 않은 것이 문제의 주된 원인이라고 생각하지 않는다. 이렇게 대응한 한국의 개발자들을 비난하려는 것이 아니다. 한국 개발자들은 몸에 베어 있는 개발문화 때문에 본사 프로세스를 따르기도 쉽지 않다. 그런 개발문화와 습관을 익히게 된 우리의 개발 환경이 문제인 것이다.

한국에서 개발을 하다가 실리콘밸리 소프트웨어 회사에 취직을 한 개발자 중에는 개발 문화와 프로세스에 적응하는데 힘들어하는 사람들이 많다. 하지만 문화란 원래 작은 부분이 큰 부분에 흡수되듯이 한 개인은 모든 사람이 공통으로 행동하는 개발문화에 흡수되기 마련이다. 반대로 실리콘밸리의 아무리 뛰어난 개발자라도 우리나라에 오게 되면 꼼짝없이 한국식 개발문화에 적응해야 한다. 본인의 방법으로는 더 이상 어찌해볼 수 없는 상황이 된다.

필자는 한국적인 개발문화부터 실리콘밸리의 개발문화와 관료화된 거대 개발프로세스까지 직간접적으로 다양한 경험을 한 덕에 이를 서로 비교할 수 있다. 그래서 앞으로 효율적인 개발문화에 대해서 구체적으로 얘기를 해보고자 한다.

문화란 한 사회의 구성원들의 주요한 공통된 행동 양식이다. 개발문화는 소프트웨어를 개발하는 구성원들의 공통된 생각과 행동 양식이다. 프로세스처럼 명문화되어 있지는 않지만 대체로 그렇게 행동을 하는 것을 말한다. 우리나라의 개발문화는 형편없다고 주장하려는 것이 아니다. 우리나라의 문화가 더 훌륭한 부분도 있고 장점도 많다. 사실 문제가 되는 부분은 2%에 불과할 수도 있다.

이런 결정적인 결과의 차이를 만들어내는 주요 개발문화의 차이를 비교해보자.

개발 프로세스와 개발문화는 서로 보완적이며 개발문화 없이 효율적인 개발프로세스를 만들기 어렵다. 개발문화가 있다고 개발 프로세스가 필요 없는 것도 아니다. 반대로 아무리 정교한 개발 프로세스가 있어도 개발문화가 뒷받침되지 않으면 개발프로세스는 방해만 될 뿐이다. 그만큼 개발문화는 개발 프로세스보다 중요하다.

그럼 이런 차이를 만드는 개발 문화에는 어떤 것들이 있을까? 지금은 하나씩 나열만 해보고 다음 회부터 각각의 사항에 대해 좀더 자세히 풀어볼까 한다.

첫째, 공유 문화의 부족이다.

사실 우리나라에도 공유문화가 없는 것은 아니다. 하지만 결정적인 차이가 있다. 그 차이를 앞으로 얘기해보겠다.

둘째, 빨리빨리 문화다.

장기적인 고려 없이 무조건 빨리 하는 것은 단기적으로는 빠른 성과를 낼 수 있어도 장기적으로는 몇배 더 느려진다. 다른 산업분야에서는 톡톡히 효과를 봤어도 소프트웨어는 워낙 복잡한 지식 산업이라 빨리빨리 문화가 종종 큰 문제를 야기한다.

셋째, 전문가 vs. 만능 개발자이다.

소프트웨어 산업에서는 전문가에 대한 인식이 떨어진다. 뭐든지 잘하는 만능 개발자를 선호하며 그러다 보니 뛰어난 개발자도 본연의 업무인 개발에 집중하지 못하고 다른 일에 휘둘리다보니 회사는 효율이 떨어지고 개인의 캐리어는 발전하지 못한다.

넷째, 사람 중심 vs. 시스템 중심이다.

다른 분야도 마찬가지이지만 사람 중심의 개발은 리스크를 증가시키며 대체도 어렵게 만든다. 대체 못하는 개발자는 회사와 개발자 서로가 서로의 발목을 잡는 상황이 된다.

다섯째, 규칙 준수 문화 부족이다.

사회 전반의 문제지만 소프트웨어 회사에서는 규칙을 무시하는 사람들이 많다. 특히 조직의 윗선에서 이러한 현상이 더 심각해진다.

여섯째, 서열 중심 문화이다.

전통적으로 수직적인 조직문화가 소프트웨어 개발에는 문제가 된다. 어떻게 해야 이를 극복할 수 있을지 알아보겠다.

일곱째, 낙후된 토론 문화이다.

요즘은 토론 위주의 교육에 신경을 많이 쓰면서 개선되고 있지만 여전히 토론문화는 많이 부족하다.

우선 생각나는 것은 이 정도이며 앞으로 이것들을 포함하여 개선해야 할 여러 개발문화 대해서 하나하나 구체적으로 얘기를 해보고자 한다. 새로운 내용이 있으면 계속 추가해 나갈 계획이다.

그런데 이런 얘기를 시작하면 종종“우리도 해봤는데 안되더라는 얘기를 많이 듣는다. 우리도 공유해보려고 했는데 잘 안 안된다. 우리와는 안맞는다, 그렇게 피해의식을 가진 선배개발자들이 많아서 새로운 시도가 처음부터 막히는 경우가 많다. 대부분은 잘못 시도했거나 의지가 부족해서 실패한 경우가 많다. 이렇게 피해의식이 가득찬 회사는 바뀌기 어렵고 그 끝은 뻔하다. 그렇지 않고 개발문화를 조금씩 바꿔가고 싶은 사람들에게는 도움이 되길 바란다.

개발문화는 조직 전체를 바꿔야 하는 것이기 때문에 한명의 개발자가 몸부림친다고 쉽게 바뀌지는 않는다. 경영자나 중간관리자가 움직여줘야 한다. 회사를 움직일 수 있는 경험과 힘이 있어야 변화를 시켜 나갈 수 있다. 이런 분들에게도 많이 공유가 되면 좋겠다.

워낙 광범위한 주제이기 때문에 독자 여러분들과 많은 의견을 나누면서 얘기를 발전시켜나가면 좋겠다. 구체적인 얘기가 시작될 다음 칼럼에도 많은 관심 부탁드린다.

CNET 코리아에 기고한 칼럼입니다. (http://www.cnet.co.kr/view/25148)