[오늘의 한마디] 경기에서는 개의 크기가 아니라, 팀의 조화가 중요하다.

얼마전 "스노우버디즈"라는 가족 영화를 보았는데, 비록 개가 한 소리(?)지만 좋은 말이 있어서 인용을 해볼까 합니다.

"경기에서는 개의 크기가 아니라, 팀의 조화가 중요하다."

어린 강아지들이 개썰매 대회를 준비하면서 스승이 해준 말입니다.

하물며 개들이 알고 있는 것을 인간들이 모르면 안되겠지요. ^^

아주 소규모 (2,3명 이하)의 개발팀이라면 각 개인의 역량이 프로젝트를 성공시키는 가장 큰 요소가 되겠지만, 3,4명만 넘어가는 개발팀에서도 팀의 조화가 아주 중요한 요소가 됩니다. 특히 팀이 커질수록 프로젝트의 성공은 한두명의 역량보다는 팀워크에 달려 있다고 해도 과언이 아닙니다.

혼자서는 개발을 잘하고 아는 것은 많지만 협력해서 일할 줄 모르는 개발자는 큰 프로젝트에서는 배제를 하게 됩니다. 그런 개발자에게는 연봉을 많이 줄수 없는 이유이기도 합니다. 

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

언제부터인가 소프트웨어 개발자를 경력 개발자 위주로 채용하는 것이 일반화 된 것 같습니다.

물론 다른 업계도 마찬가지이지만, 당장 써먹을 수 있는 경력직을 선호하는 것은 사실입니다.

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

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

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

여기서 예로든 하부 조직이나 중간 조직이 빈약한 구조가 개발에 전혀 지장을 주고 있지 않다면 특수한 개발 조직이거나 각개격파형 개발조직 구조일 것입니다. 또는 주먹구구이거나요.

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

그럼에도 불구하고 경력개발자만을 위주로 채용하는 이유는 여러가지가 있습니다.

• 단기적인 이익을 내려는 경영층의 조급증
• 신입 개발자를 채용해도 효과적으로 교육시킬 수 있는 교육 시스템 부재
• 3,4년 미래도 내다보지 못하는 HR Plan
• 주먹구구 식으로 개발을 하고 있기 때문에 체계는 필요 없고, 무조건 경험 많고 능력 있는 개발자만 필요한 경우

이미 회사를 위해서 오랫동안 헌신한 개발자들이 개발은 잘하고 업무관련 지식은 뛰어난데, 소프트웨어 전문가로서는 턱없이 모자라는 경우가 흔합니다. 오랫동안 각개격파식으로 혼자서 북치고 장구치고 하는 식으로 개발들을 많이 해왔기 때문에 이런 일들이 일어납니다. 이경우 이러한 고참 개발자들이 다른 회사로 이직을 할 경우 그 가치가 현저히 떨어지는 경우가 많습니다. 전문가로서의 역량은 부족하기 때문입니다. 자칫하면 이러한 공신들이 희생될 수도 있고, 골치덩어리가 될 수도 있습니다.

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

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

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

타이핑이 느린 프로그래머

대부분의 프로그래머의 타이핑 실력은 정말 뛰어납니다.

심야에 정말 빠른 타이핑 실력을 가지고 있는 프로그래머가 타이핑을 하고 있는 소리를 들어보면 음악과도 같습니다. "딱딱딱"이 아니고 "좌르르~"소리나 납니다.

이런 개발자들을 많이 봐왔죠.

그런데, 가끔 타이핑이 느린 프로그래머를 접하게 됩니다.

심지어는 자판을 보지 않고는 영어를 입력하지 못하는 프로그래머도 본적이 있습니다.

타이핑이 개발 실력과는 크게 연관이 없는 것처럼 보일 수도 있지만, 프로그래머의 무기는 키보드인데, 타이핑이 느리다는 것은 대단한 손해가 아닐 수 없습니다.

프로그래머의 일생의 수십%는 타이핑을 하면서 보냅니다. 그 시간의 10~20%는 절약하는 것은 인생의 대단한 시간 절약이 아닐 수 없습니다. 그 반대의 경우는 대단한 낭비죠.

한글, 영어 구분하지 않고, 자신의 생각이 주르륵 바로 입력이 될 수 있도록 훈련이 되어 있어야 합니다. 타이핑이 느려서 생각의 흐름이 끊겨서는 안됩니다. 더불어서 자신이 사용하고 있는 개발툴과 에디터의 단축키들을 몸에 익혀서 자동으로 단축키를 사용할 수 있어야 합니다.

혹시 자신이 타이핑이 느리거나, 마우스에 많은 의존을 하고 있는 개발자라면 타이핑 속도 향상을 위해서 연습을 해야 합니다. 

이것은 프로그래머에게는 기본의 기본의 기본이 아닐 수 없습니다.

필자의 첫번째 상용 프로그램이 타자연습프로그램이었는데, 타자연습프로그램을 이용해서 꾸준히 일정기간만 연습해도 필요한 만큼의 속도는 누구나 달성할 수 있습니다. 그렇지 않고 실무적으로 일을 하면서 자연스럽게 속도가 느는 것을 바라는 것은 자칫 자꾸 자판을 본다던지, 또는 손가락의 위치가 틀렸다던지 하는 나쁜 습관을 가질 수 있으므로, 제대로 연습을 하는 것이 중요합니다.

이 글은 대부분의 프로그래머에게는 필요 없는 글이나, 본인이 타이핑 속도가 느리거나 팀원들 또는 신입개발자가 타이핑이 느리다면 당연히 해결해야 할 것입니다.

Waterfall과 Agile

주변에서 Waterfall이 좋다 Agile이 좋다 등의 논쟁을 가끔 보게 됩니다.

하지만 Waterfall을 비교 대상으로 삼기에는 적당하지 못한 것 같습니다.

즉, 너무 극과 극의 비교입니다.

이미 Waterfall 방식은 너무 느리고 비용이 많이 들어서 대부분의 소프트웨어 프로제트에서는 사용하지 않습니다. 하지만 Waterfall 방식은 소프트웨어 개발의 기본 원리를 이해하는데 가장 중요한 모델이고 다른 모든 개발 모델들은 Waterfall에서 파생해 나온 것들이기 때문에 Waterfall 방식을 이해하는 것은 소프트웨어 개발 기본 원리를 이해하는 것처럼 중요합니다.

순수한 Waterfall 모델은 다음 단계로 진행하기 위해 전 단계가 완벽하게 끝나야 하고 모든 결과가 문서로 작성되어야 합니다. 폭포를 거슬러 올라가는 것이 원칙적으로 불가능하므로 Waterfall 모델에서는 이전 단계로 거슬러 가는 것이 불가능하거나 비용이 아주 많이 들게 됩니다.

현실에서는 이를 제대로 적용하기가 어려운 이유는 대부분의 소프트웨어 프로젝트는 요구사항을 초기에 완벽하게 파악하여 고정하는 것이 불가능하기 때문입니다. 더 많은 시간을 들여서 요구사항을 완벽하게 해도 시간이 흐르면서 주위 환경이 바뀌고 경쟁자들이 새로운 제품을 내놓는 등의 이슈로 인해서 이미 만들어 놓은 요구사항은 쓸모 없어 집니다. 그리고 너무 많은 문서를 요구하기 때문에 문서 작성과 관리에 너무 많은 시간을 쏟아 부어야 합니다. 그리고 프로젝트가 끝날 때까지 진행과정을 거의 볼 수가 없어서 사용자의 요구사항이 만족스러운지를 프로젝트가 끝날 때까지는 알 수가 없습니다. 이 또한 큰 리스크입니다.

만약에 Waterfall 모델을 따라서 개발하고 있다고 말할 수 있는 회사가 있다면 제대로 적용하고 있지 않거나 화성탐사선을 만드는 회사일 것입니다.

모든 종류의 프로젝트에 딱 적합한 방법이 있는 것은 아니니까 어느 한 라이프사이클 모델을 엄격하게 따를 필요는 없습니다. 원리만 알고 있고 경험이 있다면 응용이 가능하니까요. 

달콤한 유혹에 중독되어 있는 고객들 (SW 저가수주)

5throck님의 "프로젝트 저가수주의 폐해"라는 글을 읽고 의견을 적어봅니다.

그리고 "이 문제를 해결할 좋은 방법은 정말 존재하지 않는 것일까요? "라는 질문에 대한 나름 답변을 해볼까 합니다.

우리나라 소프트웨어 산업구조는 정말 기형적이라고 하지 않을 수 없습니다. 대형 SI업체가 시장을 지배하고 있고, 성공한 팩키지, 솔루션 회사는 거의 찾아보기 힘들고 과거에 성공했던 회사들도 그리 오래가지 못하고 쓰러져왔습니다. 그 이유야 여러가지가 있겠지만, 그 많은 이유 중에서 대형 SI업체가 지배하고 있는 시장구조에 대해서 의견을 적어보고자 합니다.

외국에서 유래를 찾아보기 힘든 대형 SI업체 구조는 우리나라 고객들에 입맛에는 맞는 것 같습니다. 대충의 요구사항만 가지고 있으면 대형SI업체에서 모든 것을 다 알아서 해줍니다. 심지어는 고객의 제시해야할 요구사항도 업체에서 달 알아서 해주기 때문에 고객은 신경쓸 일이 적은 대형 SI업체를 선호하게 됩니다. 그러다보니 불확실한 요구사항으로 프로젝트를 시작하는 것은 일반적이고, 프로젝트 비용이 얼마나 들어갈지 알수도 없는 상황에서 입찰과 수주과 이루어지며, 이또한 저가 낙찰은 너무 흔합니다. 그 손실은 당연히 하청 업체들에게 전가가 되기 일쑤입니다. 이러한 구조하에서 많은 하청업체들은 기술개발보다 저가 용역에만 매달리게 되곤합니다.

이러한 현상은 무지한 대부분의 고객이 초래한 면이 있지만, 결국 그 피해는 프로젝트 품질의 저하로 고스란히 고객에게 다시 돌아가는 악순환이 벌어집니다. 여기서 손해를 보는 회사들은 대형SI회사들이 아니고 수많은 하청 업체와 솔루션 개발 업체들이 됩니다. 이런 업체들이 우리나라에서 장사 못해먹겠다고 외국으로 나갈려고도 해보지만 뾰족한 수가 없는 것이 대부분이죠.

해결책은 2가지로 생각하고 있습니다.

첫째, 대형 SI업체의 해체입니다. 부정적이인 해체가 아니고, 대형 SI업체도 수익을 제대로 낼 수 있는 건설적인 구조로 변화해야 합니다. 프로젝트의 모든 것을 알아서 몽땅 해줘서 수익성이 낮은 자잘한 프로젝트와 일까지 매달리지 말고 큰 업체가 할만한 일들을 해야 합니다. 대형SI업체들은 작은 프로젝트와 업무로 인해서 대부분 손실을 보고 큰 프로젝트에 몇개에서 그 손실을 매꾸는 것으로 알고 있습니다. 더이상 SI라는 분야에 매달리기 보다는 IT컨설팅, IT서비스의 영역으로 포커싱이 되어야 한다고 생각합니다. 이것이 대형 SI업체도 살수 있는 길이고 이는 SI업체들이 스스로 변화해야 하는 부분입니다.

둘째, 제도적으로 더욱 보완이 되어야 합니다. 정부에서 해야 할 일이지요. 현재 분리발주법이 시행 중이지만 그 효과는 글쎄입니다. 편법이 얼마든지 가능하죠. 그리고 SW분리발주가 아닌 분석프로젝트 분할발주가 필요합니다. 현재는 대충의 요구사항을 가지고 수주를 하다보니 프로젝트를 진행하다보면 프로젝트가 2배로 커지기도 합니다. 특정 규모이상의 대형 프로젝트인 경우는 분석을 분리하여 프로젝트의 범위를 명확하게 하면, 전체 프로젝트의 비용이 합리적으로 나오게 됩니다. 여기에 저가입착을 어렵죠. 들어가는 비용이 뻔한 상태에서 저가 입찰은 품질을 포기하는 것이고, 이런 환경이라면 기술력이 낙찰의 중요한 요소가 되겠죠. 외국의 경우는 이미 분석 프로젝트를 분할하여 발주하는 것은 일반적입니다. 이를 제도적으로 더욱 보완해서 고객이나 업체 모두 상생의 길로 가야 할 것 같습니다.

악순환의 고리를 누가 먼저 끊을까요? 정부일까요? SI업체일까요? 수많은 중소기업들이 조금씩 바꿔나가기에는 너무나 머나먼 길일 겁니다.

Second System Syndrome (뭐 이따위로 만들었어?)

프레드 브룩스가 얘기한 "Second System Syndrome"은 주변에서 흔하게 접할 수 있습니다.

현재의 개발자들이 과거에 선배들이 만들어 놓은 First System의 문제 요소를 지적하며 Second System을 만들어야 한다고 주장합니다. 이러한 현상은 정말로 지겹게 봐왔습니다. 즉, 선배들이 만든 시스템을 "뭐 이따위로 만들었어? "하고 생각하면서 Second System을 만들어야 하는 온갖 이유를 대면서 경영자를 현혹시킵니다.

이렇게 주장하는 개발자들은 어리고 경험도 부족하기 때문에 First System이 얼마나 어려운 문제를 다루고 있었는지 제대로 이해하지 못합니다. 또 자신들이 문제로 지적하고 있는 요소들 외에 얼마나 많은 복잡한 이슈들을 First System에서 해결하고 있는지 알지 못합니다. 또한 과거의 문제를 근사하게 해결했다는 성과를 뽑내고 싶은 욕구도 있습니다.

이렇게 만들어진 Second System은 대부분의 경우 First System을 얕잡아 보기 때문에 예상치 못한 이슈들과 많이 부딪히게 되고 예상된 일정을 지키지 못하게 됩니다. 또 이미 First System에서 해결했던 수많은 문제들이 Second System에서는 버그로 나타나는 경우가 허다합니다.

v1.0이 허접하고 문제도 많다고, 기능을 잔뜩 붙여서 v2.0을 만들었지만, 고객들이 기능은 적어도 문제가 적은 v1.0을 다시 찾는 일을 보는 것은 그리 어렵지 않습니다. 비록 v2.0이 예상된 일정을 훨씬 넘겨서 어렵게 출시가 됐는데도 말입니다.

Third System Syndrome이란 현상이 없는 이유는 Second System Syndrome의 쓴맛을 본 경영자가 세번째는 허용을 하지 않기 때문이겠죠.

이렇게 Second System Syndrome이 일어나는 결정적인 이유는 First System을 만들어 놓은 개발자들이 달랑 소스코드만 남겨 놓았기 때문인 경우가 대부분입니다. Second System을 주장하는 개발자들은 대부분이 이 First System을 유지보수하는 하는 개발자들이고 지겹도록 문제점만을 봐왔기 때문입니다. 그러면서도 본인들도 Second System을 만들면서 달랑 소스코드와 별 쓸모 없는 문서 몇 개 만들어 놓는 것이 고작입니다.

애초에 정상적인 체계를 갖추고 개발에 모든 정보가 지식화가 되어서 동료들간에 또 후배에게 전달이 되어 있었다면 이러한 First System의 무조건적인 비판은 일어나지 않을 겁니다.

만약에 현재 여러분이 문제가 많은 First System을 유지보수 하느라고 고생을 하고 있고 이를 만든 선배들은 이미 퇴사를 하였다면, 무조건적으로 Second System을 주장하지 말고 냉정한 판단을 해야 합니다. Second System이 실패하는 일은 너무나 흔하니까요. First System의 기반을 완전히 무시하는 것은 그동안 개발팀이 쌓아온 재산을 무시하는 것과 다름이 없습니다. 차라리 First System의 Refactoring이나 Rearchitecturing을 통해서 문제 해결을 시도하면서 좀더 지식과 경험을 쌓고, 

"자신의 First System을 만들 때를 대비해서 내공을 쌓아가세요."

깨끗한 개발 환경, 빌드 환경, 테스트 환경

개발, 빌드, 테스트 환경을 별도로 두지 않고 그냥 개발자 PC에서 수행하는 경우들이 많습니다.

이렇게 되면 자칫 빌드 시 개발 환경에 영향을 받아서 의도하지 않는 문제가 발생할 수 있습니다.

따라서 개발, 빌드, 테스트 환경은 각각 어떻게 구성을 해야 할지 미리 정하고, 그에 따라야 합니다.

일반적인 경우 빌드는 깨끗한 환경에서 항상 원하는 빌드를 만들어 낼 수 있도록 하며, 테스트는 스펙에서 요구하는 테스트 요구사항에 따라서 각각의 테스트 환경을 구축해야 합니다. 여러 플랫폼을 지원하는 경우 테스트 환경 구축이 아주 복잡하고 비용이 많이 들기도 합니다. 테스트 환경에 대한 이해는 많이들 하고 있다고 가정하고, 빌드 환경에 대해서 조금 더 얘기를 해보고자 합니다.

빌드가 무엇인지 먼저 얘기를 해보죠. 개발자 Visual Studio나 Eclipse 같은 IDE을 이용해서 빌드하는 것은 여기서 말하는 빌드는 아닙니다. 여기서 말하는 빌드는 공식 빌드입니다. 공식 빌드는 Release를 위해서 빌드하는 것을 말합니다. 개발자들이 하는 빌드는 그냥 개발의 일부이죠.

많은 개발자들이 자신의 개발 환경에서 그냥 빌드한 결과물을 묶어서 제품을 만들어 고객에게 전달하곤 합니다. 그렇게 되면 IDE의 빌드 설정에 따라서 빌드의 결과가 달라져서 예기치 못한 문제가 발생하기도 하고, 개발자가 퇴사하고 새로운 개발자가 빌드를 하려고 하니 빌드가 안되기도 합니다. 또는 개발자 PC의 환경에 영향을 받아서 개발자 PC에서는 잘 동작했으나, 고객의 환경에서는 문제가 발생하기도 합니다.

각각의 환경의 관리는 개발팀, B/R팀, 테스트 팀이 맡고 있고 함부로 건드리지 못합니다. 

지금까지 이러한 구분없이 개발을 하고 계셨다면 혹시 이로 인한 문제는 없었는지 생각해보세요. 없었다면 정말 운이 좋은 겁니다. 시스템이 점점 커지고 고객이 많아지는데도 계속 운만을 바랄 수는 없겠죠.