좋은 소프트웨어를 만들기 위해서는 정부, 학계와 기업의 역할도 중요하지만 역시 가장 중요한 것은 전문 개발자이다.

전문 개발자가 없으면 아무리 좋은 정책에 좋은 기업이 있어도 품질 좋은 소프트웨어를 만들어 내기는 어렵다. 좋은 소프트웨어의 생산에는 개발자들의 능력과 열정이 핵심일 수 밖에 없다.

전문 개발자가 되기 위해 어떤 요소가 필요한 지를 살펴보자.

소프트웨어 개발자중에 자기가 없으면 회사가 큰 일 난다고 말하는 사람들이 있다. 거기에는 두 가지 의미가 있을 수 있는데 첫째는 '자기 혼자 밖에 모르는 비밀을 갖고 있는' 과거지향형과 둘째는 '저 사람은 무슨 일을 시켜도 잘 해'라는 미래지향형이 있다.

과거지향형 인력 중에는 핵 폭탄이라고 불리는 극단적인 비밀지향형 인력도 있다. 전문가일 수도 있고 아닐 수도 있는 이 핵 폭탄은 회사로서는 치명적이다. 이 사람이 없어지면 단기적으로 큰 영향을 받는다.

반대로 미래지향형 인력은 지금 없어도 당장에 큰 타격은 없으나 회사의 미래를 위해 많은 기여를 하며 회사의 성공을 위해 꼭 지켜야 할 핵심 인력이다.

미래지향형 전문가가 많은 회사와는 믿고 거래할 수가 있다. 회사로서는 과거지향형 인력은 적으면 적을수록 좋고 미래지향형 인력은 많으면 많을수록 좋다.

이 두 가지 종류의 인력은 쉽게 판별 가능하다. 소스코드와 같이 개발해 놓은 발자취를 살펴 보면 판단을 할 수 있는데, 자기만을 위해 쓴 코드와 다른 사람을 위해 쓴 코드는 웬만한 경험을 가진 사람이면 쉽게 분별할 수 있다.

잘 아는 경영 컨설팅전문가가 하는 얘기가 있다. 어느 회사든 컨설팅을 가보면 회사인력 중에 자기의 핵 폭탄을 믿고 회사생활을 자기 멋대로 하려는 사람들이 꼭 있다고 한다. 이럴때 컨설턴트가 경영층에게 하는 조언은 항상 같은데, "지금 아무리 큰 타격이 있더라도 빨리 내 보내라"고 한다. 그러지 않으면 문제가 계속 더 커지고 언젠가는 폭발하기 때문이라고 한다.

반면에 미래지향형 인력은 자기의 많은 것을 다른 사람과 공유하기때문에 손해 보는 듯 보이지만 회사에서는 가장 중요시 해야 하는 인력이다. 능력 있는 경영자라면 안다.

지식의 깊이에는 세 종류가 있다. 첫째는 남이 말하면 이해하는 표면적인 수준의 지식이다. 둘째는 나 스스로 항상 알고 있는 지식이다. 셋째는 남을 가르칠 수 있는 지식 수준이다. 똑 같이 안다고 얘기해도 이 지식 수준의 차이에 따라 업무의 능력이 천차만별로 차이가 난다.

남이 얘기하면 "나도 그거 알아"라는 말은 누구나 할 수 있다. 전문가라고 말할 수 있으려면 남을 가르치고 지도할 수 있는 지식을 가져야 한다. 다른 사람의 설명을 듣고 이해해서 판단을 해야 한다면 전문가도 아니고 판단의 질도 떨어질 수 밖에 없다. 시행착오를 겪을 확률이 높다. "잘 모르지만 시키면 뭐든지 다 할 수 있습니다"라는 말은 정열은 인정하나 아직 준비가 되어 있지 않다는 말이다.

언제든지 무슨 일에 부딪쳐도 당장 실행할 수 있는 포괄적이고 깊이 있는 능력을 기르는 것이 중요하다. 그래서 전문가가 되려면 많은 시간과 노력이 필요하다. 배워야 할 기술이 얼마나 많은가? 예를 들어 XML이나 웹 서비스(Web Services) 같은 용어를 수도 없이 들었지만 이 기술을 언제든지 활용할 수 있게 깊이 알고 있는 소프트웨어 인력은 많지 않을 것이다.

이렇게 전문가가 되기 위해서는 많은 지식을 깊이 쌓아야 하는 데 그러기 위해서는 좋은 스승과 본인의 노력 모두를 필요로 한다. 지식을 혼자서 배우는 것에는 한계가 있다.

이런 우화가 있다. 바둑의 고수가 되기 위해 젊은 사람 둘이 산속에 들어가서 몇 십년을 연구하고, 이쯤이면 고수가 되겠지 하고 세상에 나왔다. 그런데 그들은 아직도 초보자에 불과했다. 혼자서 책만 보고 배워서는 절대 전문가가 될 수 없다. 스승은 자기보다 더 많이 아는 사람이면 금상첨화겠지만 누구든지 스승이 될 수 있다. 동료나 후배도 스승이 될 수 있다.

소프트웨어에서는 모든 사람이 서로 배운다. 간단한 문서 작성기도 사용하는 사람마다 사용법이 다 다르고 꼭 나보다 더 좋은 방법을 사용하는 부분이 있다. 똑 같은 문제를 푸는 알고리즘도 놀라울 정도로 열이면 열사람 모두 다른 방법을 사용한다. 다른 사람이 하는 것을 보고 서로 장점을 배우면 된다. 그래서 같이 검토하고 의견을 나누는 시간을 많이 가져야 한다. 요구사양서부터 설계, 코딩에 이르기까지 어떤 분야에서든지 항상 다른 사람에게서 배울 수 있다.

가장 효과적으로 배우는 방법은 전문가한테서 배우는 것이다. 미국에서 윈도우용 디바이스 드라이버를 개발할 때 였다. 물론 우리 회사에도 전문가가 있었지만 개발 중 막히거나 더 좋은 방법을 요구하는 경우가 나온다. 이럴 때 외부에 있는 같은 분야의 동료에게 묻는 등 여러 가지 방법이 있겠으나 궁극적인 정보소스는 마이크로소프트였다.

한밤중이라도 마이크로소프트 유료 기술지원부서에 전화를 걸어 물어 보곤 했다. 대부분의 경우 기술지원 첫 한 두 단계에서 해결되기도 하나 그 쪽 분야의 최고 전문가가 아니면 대답할 수 없는 문제도 있었다. 그런 문제의 경우에는 아무리 주위에 물어봐도 옳은 답을 얻을 수 없다. 많은 비용을 지불하고서라도 이렇게 전문가의 도움을 받는 것이 결국은 시간도 절약하고 비용도 절약하는 것이다.

물론 중요한 것은 지식의 터득이다. 썬 워크스테이션(Sun Workstation)에서 개발을 할 때는 썬 마이크로시스템즈(Sun Microsystems)에 근무하는 사람에게 물어볼 수 밖에 없는 경우가 꼭 생긴다.

혼자서는 평생 연구해도 모르는 경우가 있다. 근래에는 웹에 많은 정보가 들어 있어 정보습득이 훨씬 용이해 졌으나 그래도 전문가한테서 배우는 것 만큼 효율적인 방법은 없다. 'Random Fix'라고 혼자서 이것 저것 해 보다가 우연히 문제가 해결되는 경우도 있으나 그것은 지뢰와 마찬가지다. 완벽한 이해 없이 우연히 구동되는 것만큼 위험한 경우도 없다. 주위에 다양한 전문가를 많이 가지고 있는 것이 얼마나 중요한지를 강조하고 싶다.

전문가에게 요구되는 것은 기술도 기술이지만 계획성도 있다. 계획성은 대부분의 기술자에게서 발견되지 않는 취약한 분야이다. 그냥 최선을 다 한다는 것처럼 무모한 것은 없다. 항상 무슨 일을 하든 일정계획을 세우게 되는데 문제는 계획한 일정대로 진행이 안 된다는 것이다.

몇 해 전의 미국 소프트웨어 프로젝트 통계에 의하면 16%의 프로젝트만이 제 시간에 제 예산으로 성공적으로 개발되었다고 한다. 지연되는 것이 예외가 아니라는 것이다. 지연 자체가 문제가 아니라 지연될 경우 지연될 것이라는 것을 조금이라도 빨리 예상해서 대처하는 것이 전문가의 능력이다.

무모한 낙천주의와 열정으로 시간을 맞추려고 혼자서 고생은 고생대로 하며 진행하다 마지막 순간에 포기하는 최악의 상황을 만들어 내는 것을 흔히 본다. 미리 대처할 수 있게 만드는 것이 경험 있는 전문가의 역할이다. 프로젝트 관리 방법론에 의하면 정확한 예측(Estimate)은 일이 다 끝나야 나온다고 한다. 프로젝트 종료시까지는 항상 말 그대로 'Estimate'이라고 생각해야 하는 것이 현실이다. 미리 대처할 수 있게 하는 사람이 전문가이며 신뢰할 수 있다.

전문가라면 또 현명해야 한다. 동일한 일을 두 번 세 번 중복해서 하는 경우가 생기면 뭔가 조치를 취해야 한다는 생각을 해야 한다. 형상관리이건 코딩이건 효율적인 방법이 있을 것이라는 생각을 해야 한다. 놀랍게도 습관적으로 생각없이 같은 일을 반복하는 경우를 많이 본다. 빌드나 설치, 테스트 같은 업무라면 당연히 자동화를 생각해야 하며 코딩이라면 공통 라이브러리를 생각해야 한다. 반복적인 일을 하고 있다면 무엇인가 잘못된 것이다.

시간이 걸리더라도 빨리 효과적인 방법을 정립하고 다시 시작해야 한다. 지금 수행하는 프로젝트가 늦어질까 봐 계속해서 똑 같은 일을 반복적으로 하는 것처럼 비효율적인 것은 없다.

전문가라면 새로운 기술에 대한 접촉은 항상 유지해야 한다. 소프트웨어 기술 중에 필자가 생각하는 가장 유망한 미래의 기술을 꼽으라고 하면 웹 서비스(Web Services)를 꼽는다. 일전에 어느 회사에서 기술이사와 웹 서비스를 논의할 경우가 생겼는데 코바(CORBA)라는 기존 기술이 있는데 그것으로 웹 서비스가 할 수 있는 것을 다 할 수 있는 데, 왜 웹 서비스가 필요하냐고 하는 경우를 보았다. 마치 자전거로 어디든지 다 갈 수 있는 데 왜 자동차가 필요 하느냐는 식이다.

이는 소프트웨어 전문가라고 할 수 없다. 모든 분야의 근간이 되는 핵심기술은 확실히 알고 있어야 한다. 그런 기술은 언제든지 사용될 수 있는 가능성이 있기 때문이다. 모르고 있으면 그 혜택을 입지 못한다. 혜택을 입지 못한다는 사실 자체도 모르니 불행하지는 않지만 능력을 인정받지 못한다. 아는 것이 힘이다.

소프트웨어회사의 '역량성숙도모델'로 전 세계에서 비공식표준으로 사용되고 있는 카네기멜론대학의 SEI에서 정립한 CMM의 현 자문위원이며 카네기멜론대학의 교수이고 또 보잉사의 Chief Scientist인 존 뷰(John Vu)가 한국에 강연을 왔을 때 점심을 같이 하면서 얘기를 나누었다. John Vu와는 80년대 중반 국방부 프로젝트 회사인 GTE Government Systems에서 같이 근무하기도 했다.

John Vu는 소프트웨어에서 경험의 중요성을 강조한다. 경험이 무엇보다도 중요하다고 한다. CMM같은 이론은 제대로 사용하면 매우 유용하다. 하지만 충분한 경험없이 CMM을 사용하는 것은 큰 효과가 없다고 한다. 카네기멜론대학에서 CMM을 공부는 했지만 경험은 없는 20대의 인력들이 30대, 40대의 경험있는 인력들한테 소프트웨어 프로세스를 컨설팅한다고 하는 경우를 가끔 보는 데 난센스라고 한다.

그는 또 경험과 책의 중요도를 비교하며 이렇게 얘기한다. 강연을 하다 보면 청중중에 책을 인용하면서 "책에는 이렇게 적혀있는데 왜 다르게 말하느냐"고 질문하는 경우가 있다고 한다. 그럴 경우에 이렇게 말한다고 한다. "나를 믿던지 그 책을 믿던지 그건 당신 자유다. 하지만 나는 내 경험에서 이것이 옳다고 확신하기 때문에 가르친다".

주로 경험없는 사람들이 책의 한 구절을 갖고 '맞다 틀리다' 주장한다. 전체 문맥을 볼 수 있는 경험이 부족하기 때문이다. CMM 자체에서도 말하기를 CMM이나 기타 유사한 소프트웨어 엔지니어링 기법을 있는 그대로 실행해서도 안되며 오용과 남용을 해서도 안 된다고 말한다. 또 CMM은 규칙이나 법이 아니라 알아서 실행하는 안내지침이라고 한다. 경험이 없이 그대로 따라 한다는 것은 또 다른 시행착오를 부른다.

무슨 분야에서든 전문가가 되기는 쉽지 않다. 소프트웨어 전문가가 되기 위해 필요한 지식과 경험을 가져야 하는데 그렇게 되기 위해 좋은 환경, 좋은 스승, 좋은 방법과 올바른 자세가 필수적이다. 하지만 이러한 기회를 찾고 분별하는 것은 각 개인의 능력일 수 밖에 없다.