Choco + mug = Happiness♥

필자가 짧지 않은 실리콘밸리에서의 미국생활 중에 컨퍼런스에서나 비즈니스 회의에서 소프트웨어 전문가를 만나거나 할 경우에 보면 의외로 나이 많은 사람들과 만날 경우가 많다. 40-50대의 기술자는 쉽게 만나게 되고 그보다 더 나이 많은 사람들도 심심찮게 만나게 된다. 이런 사람들은 주로 명함에 “Chief Scientist”, “Chief Engineer”, “Fellow Engineer”, “Chief Architect”등의 직책을 들고 다닌다. 회사에 따라 이름을 다르게 붙이지만 다 비슷한 맥락이다. 마이크로소프트의 빌 게이츠의 직책도 “Chairman and Chief Software Architect” 이다. 대 주주이며 Chairman으로서 경영에 관여는 하겠지만 진정으로 본인이 하기 원하는 것은 아마 Chief Software Architect” 가 아닌가 한다. 그냥 통일해서 “Chief Scientist”라고 부르기로 한다.

회사에서 이런 명함을 가진 사람들의 권위는 막강하다. 이런 사람들이 기술에 관한 결정에서 한마디 “No” 라고 하면 그것은 “No” 이다. 그 프로젝트는 더 이상 진행하기 힘들다. 이런 사람들한테 잘못 보였다가는 프로젝트 진행 안 된다. 기술의 최고전문가가 아니라고 했는데도 관리자가 “Yes” 라고 한다면 그런 회사는 오래가지 못할 것이다. 비즈니스적인 관점을 가지고 있는 관리자는 유연성 있게 정치적인 발언을 할 지 모르지만 이런 기술자들이야 자기가 가지고 있는 지식에 의한 정확한 판단을 가장 가치 있는 일로 생각하고 보람을 느끼니까 자기의 임무를 충실히 하려면 객관적이고 논리적인 근거로서 판단을 하게 된다. 물론 기술자라고 하더라도 사람 사는 세상이고 비즈니스적인 측면이 전혀 고려되지 않을 수는 없지만 그런 비기술적인 요소들은 둘째이다..

올해 초에 미국의 비행기제조회사 보잉에 근무하는 엔지니어 친구 한 명이 모든 친구들에게 email을 보내왔다. 자기가 Chief Engineer가 되었으니 축하해 달라는 것이다. 잘 모르는 사람들은 지금 나이에 엔지니어가 뭐 대단하고 축하할 일인가 하고 생각할 지 모르나 보잉의 수만 명 직원 중 몇 십 명 밖에 안 되는 직책으로서 기술자로서는 최고로 존경 받는 자리인 것이다. 기술자로서는 더 이상 높은 자리는 없다. 그리고 가장 안정된 자리가 바로 이런 자리이다. 필자의 경험으로 최고의 기술자가 감원 당했다는 소리는 들어본 적이 없다. 반면에 CEO는 언론에서도 많이 나오지만 툭하면 회사에서 쫓겨나기 일수이다. 하여튼 내 친구는 백발이 성성한 성공한 엔지니어가 되었다.

요새 CEO자리가 별로 인기가 없다고 언론에 보도가 났다. 현재의 CEO들 중에 CEO로 다시 제안이 들어온다면 수락하지 않겠다는 사람들이 더 많았다. CEO는 여러 가지 책임도 많고 재정관리나 인사관리 등 수 많은 골치 아픈 일을 수행해야 한다. 또 언론에 노출이 많이 되어 사생활이 잘 보장이 안 된다. 반면에 자기가 하고 싶은 일을 하면서 골치 아픈 업무인 사람관리 같은 일은 다른 관리자에게 맡기고 편하게 지내고 싶은 사람에게는 Chief Scientist만큼 좋은 자리는 없다. 필자가 실리콘밸리에서 수 년간 벤처 회사를 경영해 본 후로는 책임도 많고 스트레스도 많은 CEO 보다는 Chief Scientist나 CTO를 훨씬 선호하는 이유도 바로 이것이다. 단 명예욕이나 권세욕 같은 인간의 본능적인 욕심은 어느 정도 희생 해야 한다.

Chief Scientist가 이렇게 편하고 좋은 자리라면 인생이 치열한 경쟁인데 아무나 쉽게 될 수는 없을 것이다. 그렇다. Chief Scientist가 되기 위해서도 많은 노력과 시간과 경험이 필요하다. 반대로 백발이 성성하지 않다면 Chief Scientist는 되기는 힘들 수 도 있다는 말도 된다. 지식과 경험의 깊이와 넓이가 다 필요하다. 가끔 야후나 구굴같이 초창기에 젊은 인재들이 기발한 아이디어를 가지고 모여서 회사를 시작하고 초기에 성공하게 만들지만 회사가 자리를 잡으면서 성장해 나가는 데는 수 많은 경험 있는 전문가들의 힘이 필요하다. 그런 경험 있는 전문가들은 실리콘밸리에서 보면 회사가 커 가면서 꼭 필요한 사람들이기에 대부분 다른 회사에 있는 사람들을 스카우트하는 방법으로 충원하게 된다.

백발이 성성한 개발자 혹은 백발이 성성한 프로그래머?

회사에서 개발자 채용을 위해 면접을 할 때 왜 우리회사에 입사지원을 하게 되었느냐고 물어보면 대부분 “백발이 성성한 개발자”로 성장할 수 있다는 채용광고를 보고 왔다는 답을 듣는다. 기쁘기도 하지만 진정으로 전문개발자가 무엇인지를 알고 있는 가 하는 의문이 든다. 그래서 계속 물어보다 보면 “백발이 성성한 프로그래머” 를 생각하는 경우가 대부분이다. 그러면 필자는 “아닙니다. 우리회사에는 백발이 성성한 프로그래머로 성장할 수 있는 경로는 없고 프로그래머는 30대 초반이나 중반이면 끝납니다” 라고 말한다.

가끔 직원들에게서 이런 말을 듣는다. “나는 개발자로 일하기 위해서 들어 왔는데 개발이 아닌 일을 하게 되어서 혼란스럽다.”는 말이다. 개발의 정의를 어떻게 생각하는가의 차이인데 개발을 프로그래밍이라고 생각한다면 요구사항 분석이라든지 설계라든지 테스트라든지 형상관리라든지 하는 작업은 마치 개발 일이 아닌 것 같은 착각에 빠지게 된다. 물론 코딩과 같은 실제 구현 작업이 없이는 아무것도 의미가 없다. 코딩이 중요하다는 것은 안다. 하지만 코딩이 모든 것이 아니고 개발기간중의 20%정도를 소비해야 한다. 그 이상 사용하면 뭔가 잘못되었다고 생각하는 것이 옳다. 20%의 코딩 시간을 진실로 깨닫기 전에는 개발 전문가라고 할 수 없다. 훌륭한 프로그래머 일 뿐이다. 그런 이유로 코딩의 중요성을 조금이라도 덜 강조하기 위한 목적으로 필자는 항상 코딩은 아르바이트생을 고용해서 할 수 있다는 말을 한다. 실제로 설계가 잘 되어 있으면 아르바이트생이 코딩을 할 수 있어야 한다. 코딩을 최우선으로 놓는 순간 모든 것이 망가져 버린다. 코딩은 마지막 순간에 하고 그때까지는 코딩이 아닌 다른 개발 작업들을 해야 한다. 코딩을 하고 싶어서 개발자가 된 사람들에게는 미안하지만 계속 아르바이트생 프로그래머와 별로 다르지 않은 위치에 있다고 말하고 싶다. 그래도 코딩에 시간을 많이 보내는 변명은 단 하나다. “개발시간이 모자라서 코딩을 빨리 해야 한다” 이다. 이 말을 하는 사람에게는 다음과 같은 말을 해준다. “개발시간이 없을수록 시행착오를 줄이기 위해 요구사항도 정리하고 설계도 해야 한다” 이다.

그러면 어디서 이런 근본적인 차이가 온 것일까? 진정한 소프트웨어전문가가 갖추어야 할 소양이 무엇인지를 볼 수 있는 기회가 많지 않았기 때문이다. 소프트웨어가 3D라는 업종이라는 말은 바로 소프트웨어에 종사하는 사람들인 우리가 만들어 냈다. 미국에서는 가장 많은 연봉을 받는 학과중의 하나가 전산학이다. 한국에서 소프트웨어 업종을 다른 사람들이 3D라고 한 적은 없다. 다 우리 자신이 만들어낸 정부, 학계, 기업 그리고 개발자들의 합작품이다. 고급기술자나 초급기술자나 별 차이 없으니 기왕이면 싼 임금으로 고용 가능한 인력을 사용하고 요구사항이 뭔지도 모르면서 발주하고 수주하고 나중에 적당히 편법으로 마무리 하기 일수이고 고급인력의 부족으로 부실한 소프트웨어양산하고 밤새워 일해도 대접받기 힘들고 등등 똑 같은 말을 수도 없이 들어 왔다. 이런 열악한 환경에서 소프트웨어를 성공적으로 개발하기는 힘들다. 빈곤의 악순환이 이제는 끝나야 하고 또 모두 노력하고 있는 것도 사실이다. 자체정화를 해서 스스로 개발자들부터 전문가가 되어 가치를 올려야 한다. 이대로 가다가는 단기적인 피해자는 개발자들일 수 밖에 없고 장기적으로는 국가, 정부, 기업이 피해를 입을 수 밖에 없다. 안타깝게도 미래에 올 좋은 시절을 못보고 이미 벌써 많은 인력들이 IT업계를 떠난 것은 잘 알려져 있다.

소프트웨어 전문가란?

소프트웨어 공학이란 용어 자체가 없던 10여 년 전 혹은 20년 전에도 개발은 지금과 다름없이 진행되어 왔지만 소프트웨어 공학이 이바지 한 것 중의 하나는 체계적으로 잘 정리해 놓은 데 있다. 실제로 소프트웨어 공학이란 용어가 널리 쓰이게 된 것은 오래 되지 않는다. 하여튼 소프트웨어공학에서 잘 정리해 놓은 소프트웨어 전문가가 갖추어야 할 전문지식을 다음과 같이 10개 분야로 나누어 놓은 것이 있다.
1. 요구사항
2. 설계
3. 구축
4. 테스팅
5. 유지보수
6. 형상관리
7. 품질
8. 공학관리
9. 공학도구와 방법론
10.프로세스

이렇게 근래 소프트웨어공학이 활성화 되면서 체계적으로 분야를 분류해 놓기 전에도 이미 전문가들은 몸으로 체득해서 알고 있는 것들이다. 사실은 소프트웨어공학도 이런 소프트웨어 전문가들이 다시 과거의 일을 복기하면서 체계화해서 만든 것이기 때문이다. 소프트웨어 전문가가 되기 위해서 이 10개 분야에서 모두 전문가가 되기는 힘들다. 여기 나열된 분야 하나하나가 상당히 많은 지식과 경험을 요구하기 때문이다. 한가지만도 박사논문을 쓸 수도 있다. 시간적으로도 다 깊이 안다는 것은 불가능하다. 하지만 모든 것을 다 깊이는 모르더라도10개 분야가 무엇을 뜻하는 지를 알고는 있어야 한다. 또 모든 분야에서 어느 정도의 경험도 있어야 한다. 그리고 이 10개의 각 분야를 초보부터 최고전문가까지 4단계의 지식능력, 4단계의 경험능력으로 세분해 놓았다. “C++을 아십니까?” 라는 질문에 금방 학교에서 과목 이수한 사람이나 10년간 경험을 한 사람이나 다 똑같이 “압니다” 라고 대답할 지 모르나 그 경험능력은 엄청난 차이가 있다. “안다”가 다 똑 같은 “안다” 가 아니라는 것이다.

요구사항의 예

첫 번째인 요구사항을 예를 살펴보자. 사실 이 열 개 분야 중에서 가장 중요하다고 생각하는 분야가 바로 이 요구사항이다. 필자가 강연할 때나 컨설팅 할 때 즐겨서 물어보는 질문이 “숫자 3개를 정렬하는 제품을 개발하는데 얼마나 걸립니까?” 이다. “제품” 이라는 말을 주시하기 바란다. 보통 가장 많은 답이 프로그래밍에 자신 있는 개발자들은 30분이라고 대답한다. 혹은 1시간 이라고 하기도 한다. 1시간 이상 걸린다고 하는 사람들은 드물다. 이렇게 쉬운 문제를 1시간 이상 걸린다고 하면 창피하게 생각하는 것 같다. 이런 즉각적인 답은 학교에서 알고리즘을 배울 때는 맞을 수 있다. 하지만 이런 프로그램을 “1시간 걸립니다” 라고 개발시간을 그 즉시 산정해서 준다는 것 자체가 잘못된 것이다. 왜 잘못인가?

처음에 필자가 분명히 “제품” 이라는 단어를 주시하라고 했다. 학교숙제가 아닌 제품으로 생각한다면 얘기는 달라진다. 결론부터 말하자면 1년이 걸려도 개발 못하는 제품이 될 수 있다. 최초에 “숫자 3개를 정렬” 이라는 말을 했을 때 이것이 제품에 대한 요구사항이 정해졌다고 생각한 것 자체가 잘못이다. 이 제품을 누가, 언제, 어디서, 무엇을, 왜, 어떻게 사용할 지를 어떻게 알고 제품개발을 시작한단 말인가? 나는 단 한마디만 했을 뿐인데.

일단 문제가 될 수 있는 몇 가지만 생각해 보자. 나는 마이크로소프트 윈도우즈라고 말 한 적이 없다. 하지만 대부분의 개발자면 윈도우즈에서 개발하는 것을 당연히 생각할 것이다. 지원해야 되는 Platform이 윈도우즈가 아니고 IBM 메인프레임이라고 해보자. 일단 IBM 장비를 구하는 데만 해도 많은 시간이 소요될 것이다. 그리고 언어도C나 자바가 아닌 Smalltalk이라는 언어로 개발을 해야 한다고 해보자. 또 영어, 한국어, 중국어, 일본어 등으로 메시지가 출력되어야 한다고 해보자. 또 1초에 1조 번의 연산을 수행할 수 있어야 한다고 하자. 그러면 ASIC으로 Chip을 구워야 할지도 모른다. 또 통계를 내고 싶어 한다. 그러면 DB에 저장을 해야 할지도 모른다. 아직 시작에 불과하다. 애플 컴퓨터에도 사용하고 싶다. 등등 수 많은 요구사항 중에 금방 생각할 수 있는 몇 가지만 나온 것이다. 하지만 지금도 요구사항을 정의한다면서 생각나는 대로 주먹구구식으로 나열을 하고 있다. 이렇게 요구사항을 주먹구구식으로 접근하다 보면 생각이 떠오른 것은 적지만 무엇이 빠졌는지를 알 길이 없다. 적혀 있는 것은 진위여부도 확인하고 고객의 확인도 받고 할 수 있겠지만 적혀 있지 않은 것은 확인할 길이 없다. 그래서 체계적으로 요구사항을 적는 방법도 나오고 또 경험이 필요한 것이다. 솔직히 요구사항을 정확히 기술할 수 만 있다면 그 소프트웨어는 제대로 구현될 수 있는 확률이 높다. 소프트웨어 버그의 50% 이상이 이 요구사항 단계에서 나온다는 통계가 있다.

요구사항분야에 대해 지식적인 측면으로만 보면 책도 보고 요구사항서의 표준템플릿도 보고 공부해서 지식능력수준은 높일 수 있을지 모르나 경험이 없다면 경험능력수준은 초보자의 수준일 것이다. 소프트웨어 공학은 공학이라는 말이 의미하듯 Computer Science를 현실세계에 적용하는 것이다. 세계최고수준의 전산학과가 있는 U.C. Berkeley의 소프트웨어공학의 교재에도 “소프트웨어공학은 가르칠 수 없다 그러나 배울 수는 있다” 고 가르친다. 현실에서 시행착오에 의해서 배울 수 있다고 한다. 단 시행착오를 적게 겪을 수 있는 시스템을 갖춘 환경이 바로 좋은 개발환경이고 앞서 나가는 회사일 것이다.

요구사항의 예에서 보듯이 알고리즘 구현하는 기술을 가졌다고 소프트웨어 전문가라고 할 수 있는가? 절대 아닐 것이다. 소프트웨어 전문가의 역량은 학교에서는 20%를 배우고 회사에서 80%를 배운다는 통계도 있다. 일전에 미국 마이크로소프트의 관리자와 신입사원 채용에 대해 얘기를 나눈 적이 있다. 자기가 소프트웨어개발자로 대학 졸업생들을 채용하러 UC Berkeley를 가는 데 Berkeley에는 EECS(Electrical Engineering and Computer Science) 라고 전기공학과 전산학과가 같이 있다. 흥미롭게도 전기공학을 전공한 학생이 전산을 전공한 학생보다 나은 점을 가끔 발견한다고 한다. 그 이유는 전기공학을 한 사람들은 전기공학을 현실에 적용하기 위해 자기도 모르는 사이에 소프트웨어를 현실에 필요한 방법대로 개발하는 방식을 배운다고 한다. 하지만 전산학과 출신들은 소프트웨어에 관한 학문적인 지식은 많으나 현실에서 사용되는 제품을 만든다기 보다는 현실을 무시하고 이론적으로 치우친다는 데에 문제가 있다. 이론적으로 재미있고 도전적인 일을 좋아한다는 것이다. 전산학과에서 소프트웨어공학을 가르치긴 하지만 그것만으로는 현실을 그대로 반영하지 못한다는 한계가 있다. 그래서 두 전공의 장단점을 살려 두 전공학생들을 적절히 섞어서 채용한다고 한다.

또 소프트웨어 공학이라면 전세계 최고권위를 자랑하는 카네기 멜론대학의 교수가 필자에게 한 말이 있다. 학교에서 소프트웨어공학을 전공하고 졸업하는 사람들이 십 년씩 경험이 있는 개발자들에게 소프트웨어공학을 현실에 적용하도록 컨설팅하는 경우를 본 적이 있는데 자기가 볼 때는 말이 안 된다고 한다. 지식능력수준은 컨설팅할 수 있으나 지식능력수준과 경험능력수준은 엄연히 다르기 때문에 다양한 경험이 없이는 현실과는 맞지 않는 교과서적인 지식능력만 주장하는 상황이 된다.

소프트웨어공학이 알기 쉽게 체계화 해 놓았기에 필자도 설명하기가 쉬운 혜택을 받는다. 예를 들기 위해 요구사항에 대해서만 설명을 했는데 다른 분야도 그 심오한 지식과 경험을 가지려면 많은 시간이 걸린다. 보통 개발자들이 자신 있게 할 수 있다고 주장하는 10가지 영역중의 구축에 대해서 살펴보자. 오래 프로그래밍을 했으면 구축은 자신 있다고 말할 지 모르나 오랫동안 혼자서만 프로그래밍을 해 왔다면 다시 생각해 보아야 한다. 혼자서 배울 수 있는 프로그래밍기술은 그렇게 많지 않다. 프로그래머들 중에 다른 사람이 쓴 프로그램을 보고 잘 썼다고 하는 사람이 얼마나 있는가? 다 다른 사람 소스코드는 엉망이라고 흔히 말한다. 서로 그런다. 그만큼 자기 눈에 익숙하지 않고 자기 스타일이 아닌 것은 비판적이기 마련이다. 코딩능력을 자신하려면 적어도 수 많은 사람의 소스코드를 검토했어야 하고 또 자기 소스코드도 다른 사람에게 검토를 받았어야 한다. 서로 검토 하면서 좋은 점을 받아들이고 그러면서 구축능력이 향상되기 마련이다. 그만큼 소프트웨어 공학에서 빠질 수 없는 것이 Peer Review의 중요성이다. 같이 보고, 비판하고, 의논하고 배우면서 큰다. 참고로 필자는 모든 소스코드는 누군가가 검토를 해야 한다는 원칙을 항상 지킨다.

항상 갖추어야 하는 개발시스템

필자가 아침에 출근하면 누구한테 부탁하거나 물어보지 않고도 다음 몇 가지를 항상 쉽게 확인해 볼 수 있는 시스템이 되어 있기를 요구한다. 하루 아침에 10분 정도를 소비해서 그 전날 어떤 일이 벌어 졌는지를 확인할 수 있어야 한다.
- 소스코드 상태: 누가 왜 Source Code를 어제 수정했으며 어떤 부분을 수정했는지 등 모든 소스코드의 이력을 알 수 있어야 한다.
- 버그 상태: 새로운 버그는 몇 개나 발견되었으며 어제 처리된 버그는 몇 개나 되며 등등 버그에 관한 모든 정보를 볼 수 있어야 한다.
- 프로젝트 상태: 프로젝트의 일정이나 요구사항에 변경이 있었는지 등등.

“버그리스트 보내주세요” 이런 말 들린다는 것 자체가 문제일 것이다. 이러한 요구를 할 시간에 시스템에 들어가서 원하는 정보를 원하는 방식대로 보면 되지 왜 사람 불러서 시간낭비 시키고 있는가? 이런 시스템이 없이 개발을 한다는 것은 컨트롤이 어려운 상태가 되어 서로 남이 하는 일 상관하지 않고 좋게는 믿고 일하는 상황이 되지만 소프트웨어에서는 바람직하지 않은 결국은 지뢰와 시한폭탄이 숨어 있는 상황을 만들어 낸다. 이러한 개발하기 위한 Infrastructure를 준비하고 정리해 놓는 것도 전문가의 일이다. 10개 분야 중 형상관리와 소프트웨어공학도구의 일부분을 얘기한 것이다.

개발자의 길

마지막으로 개발자의 경로를 가는 사람들에게 충고해 주고 싶은 말이 있다. 전문개발자가 되려면 인사관리를 할 시간이 없다는 것이다. 인간이 가지고 있는 다섯 가지 욕심중의 하나인 권세욕을 버리라는 것이다. 기술자의 권위는 기술력에서 오는 것이지 자리에서 오는 것이 아니다. 단 회사에서 이런 환경과 문화가 우선되어야 함은 말할 것도 없고 그런 문화를 만들기 위해 우리 모두가 노력해야 할 것이다. 반대로 관리자의 경로를 가는 사람에게도 충고해 주고 싶은 말이 있다. 관리와 기술자는 하는 일이 다르고 결정사항도 다르다는 것을 분명히 알아야 한다. 절대로 기술에 관한 한 기술자의 결정을 존중하라는 것이다.

Tactic과 Strategy라는 것이 있는데 항상 Tactic이 우선한다는 말이 있다. Tactic은 전투가 벌어지고 있는 상황에서 취해야 하는 전술을 말하는 것이고 Strategy는 느긋하게 전투가 벌어지기 전에 전략을 생각하는 것이다. 전투가 시작되는 순간 그 동안 수립한 모든 전략은 쓸모 없는 것이 된다고 한다. 인사관리는 시도 때도 없이 해야 할 일이 생기는 전투와 같다. 인사관리에 한 발을 들여 놓는 순간 총알이 빗발치는 전투가 시작되어 개발을 할 수 있는 시간을 빼앗기며 소프트웨어전문가의 경로에서 멀어지는 것이다. 기술자가 관리에 재미를 붙인다면 이미 백발이 성성한 개발자로서의 길은 물 건너 간다. 단 기술자의 말을 한마디 하면 척척 이해할 수 있는 관리자와 일하는 것은 기술자의 경로를 가는 사람에게는 행운이다.

결론

소프트웨어의 중요성은 이미 통계로 많이 나와 있다. 현대 산업에서 하드웨어보다는 소프트웨어의 비중이 점점 더 높아 진다는 것을 부정할 수 있는 사람은 아무도 없다. 자동차나 전자제품 등의 많은 부분이 소프트웨어로 이루어져 있다. 임베디드 소프트웨어의 모양으로 나타나더라도 소프트웨어는 소프트웨어이다. 미국대학의 전산학과 신입생 수는 1995-1999 사이에 약 2배 가량이 늘었다. 그 후에도 계속 증가하고 있다. 그러면서도 미래에 소프트웨어인력이 모자란다고 한다. 반면에 한국은 같은 기간에 대학 신입생 수가 반으로 줄었다. 그 후에도 계속 감소하는 추세다. 정반대로 나가는 것이다. 미래에 누가 소프트웨어를 개발할 지 걱정부터 된다.

소프트웨어 전문개발자가 되기 위한 구체적인 방법은 얘기하지 않았지만 전문가가 무엇인지는 대충 감을 잡을 수 있을 것이라 믿는다. 지금은 불행히도 많은 소프트웨어 전문가가 나올 수 있는 환경과 문화도 갖고 있지 않고 또 소프트웨어 전문가가 제대로 대접을 받는 사회도 아니지만 곧 좋은 날이 올 것을 확신한다. 아이러니컬하게도 소프트웨어산업이 희망이 없어 회피하는 업종이 되어 버린 것이 현재의 사람들에게는 전화위복이 되어 공급부족으로 높은 몸값을 누릴 수도 있을 것이다. 하지만 누구나 가치를 인정할 수 있는 전문성 없이는 이루어질 수 없다. 전문성 없이 몸 값만 높아진다면 그것은 또 다른 재앙의 시작이다. 소프트웨어 산업자체를 폐허로 만들 수 있기 때문이다. 우리가 수년 전 IT 거품 때 이미 경험했다. 거품도 거품이었지만 제대로 된 소프트웨어 제품을 만들 수 있는 역량이 있었나, 내가 전문개발자라고 말할 수 있나, 그냥 오래된 프로그래머는 아닌가를 다시 생각해 보고 항상 경쟁력을 유지 할 수 있는 전문개발자로서의 소양은 닦아야 한다. 코딩 잘하는 구현 전문 프로그래머가 아닌 “백발이 성성한 개발자”로서 말이다.


[출처] 마이크로소프트웨어 2005년 12월호