'허위 프로젝트', 당신은 안전한가?

안녕하세요, 스마트플레이스의 TechnoBabbler(Technology + Babbler)입니다. 스마트플레이스의 팀블로거에 새로 합류한 블로거입니다. 앞으로 IT와 관련된 전반적인 내용들을 다룰 계획입니다. 스마트플레이스를 통해서 자주 인사드리도록 하겠습니다. 소개는 이정도로 하고 첫번째 글 들어갑니다.

최근에 불거지고 있는 '허위학력' 사건이 사회적으로 큰 이슈가 되고 있습니다. 이름만 대면 알 수 있는 업계의 유명 인사들이 '허위학력'의 힘을 등에 업고 승승장구해왔는데 모두 거짓이었다니, 당사자는 물론이거니와 그들을 채용하고 입에 바르도록 칭찬해왔던 모든 이들이 한꺼번에 뻘쭘해지는 일이 아닐 수 없습니다. 

널리고 널린 '허위학력'에 관한 글에 제 글을 하나 더 추가하고 싶지는 않습니다. 다만 소프트웨어 업계에 종사하는 저는 여러분들에게 이런 질문을 하고 싶습니다. "'허위 프로젝트'에 대해서는 어떻게 생각하십니까?" 소프트웨어 업계에서는 학력보다 프로젝트 경험이 당사자의 능력을 가늠하는데 있어서 매우 중요한 요소임을 감안할 때 허위로 프로젝트를 기술하는 일이 전혀 없을 수는 없다는게 저의 생각입니다. 사실 마음만 먹으면 '허위학력' 조작보다 '허위 프로젝트' 조작이 더 쉽습니다. 그 이유는 소프트웨어 프로젝트의 특징에 기인하고 있는데 그 이유를 하나씩 살펴보도록 하겠습니다. 


1. 동시성

SI (System Integration)와 같이 프로젝트 하나가 자신의 일과 일대일로 맞대응되는 일이 아닌 이상, 한 명의 개발자가 반드시 하나의 프로젝트에만 집중하는 경우는 많지 않습니다. 많은 경우 개발도 하면서 테스트도 하고 문서 작성까지 동시에 합니다. 어디 그 뿐입니까? 작은 기업일 수록 한 명이 슈퍼맨처럼 여러 프로젝트에 걸쳐 일을 진행해야 하는 경우가 허다합니다. 저 같은 경우도 한 때 프로젝트 3개를 동시에 진행해야 했습니다. 메인으로 맡았던 프로젝트에도 많은 시간을 보냈지만, 곁다리로 걸쳐있었던 프로젝트에도 많은 시간을 보내야 했습니다. 

자, 그렇다면 이런 경우 제가 이력서를 작성한다면 메인 역할을 했던 프로젝트만 이력서에 기입해야 할까요? 아니면 나머지 프로젝트에 대해서도 기입해야 할까요? 이는 선택과 집중에 관한 문제이기도 합니다. 여러 프로젝트를 동시에 진행했다는 것이 그 사람의 뛰어난 능력을 대변하는 동시에 어느 프로젝트에도 집중하지 못했다는 전문성의 결여를 대변합니다. 저라면 전문성이 요구되는 일을 구할 때는 메인으로 맡았던 프로젝트에 대해서만 자세하게 기입하고, 다양한 경험이 요구되는 일을 구할 때는 가능한한 많은 프로젝트에 대해서 기입하는 방법을 취사 선택하겠습니다. 이 방법이 옳은 것인지에 대해서는 판단 기준이 다를 것 같습니다. 

이런 이유로 인해 소프트웨어 업계에서는 특정 분야에 대한 이력이 다양하게 표현됩니다. 예를 들면, A라는 사람이 소프트웨어 업계에서 일한지 10년인 경우 그는 '시스템 소프트웨어 개발 경력 8년, 웹 프로그래밍 5년, 보안 컨설팅 3년, 프로젝트 관리 4년'과 같이 자신의 이력을 소개할 수 있습니다. 10년 이라는 시간동안 20년(8+5+3+4) 치의 일을 했다고 볼 수 있는데, 이런 계산 방법에 대해서 어떻게 생각하십니까? 소프트웨어 업계에 종사하지 않는 사람들이 이런 계산 방법을 본다면 터무니 없다고 생각하지는 않을까요?


2. 비연속성과 모호성

소프트웨어 프로젝트는 시작과 끝이 모호한 경우가 많습니다. 기획 단계부터 시작되었다고 해야 하는지, 실제 개발 단계부터 시작인지에 대해서 어느 누구도 정답을 말해줄 수 없습니다. 프로젝트가 끝나는 시점은 이보다 더 모호합니다. 개발이 완료된 시점인지, 출시가 된 시점인지, 버전업이 계속되는 경우 내가 개발에 참여했던 그 시점까지가 프로젝트의 끝인지가 너무나 모호합니다. 가장 확실하고 객관적인 기준이라면 내가 회의에 참석한 시점부터 회의에 참석하지 않은 시점까지가 될 수 있겠죠. 하지만 이 역시도 어려운데, 소프트웨어의 특성 상 출시된 이후로 유지보수 잡업에 많은 시간이 투입되기 때문에 유지보수 기간도(굉장히 결정하기 어려운 기간) 전체 프로젝트 기간에 포함시켜야 하기 때문입니다. 

뿐만 아니라 프로젝트가 시작되었다가 외부/내부 사정으로 인해 프로젝트가 잠시 중단될 수도 있고, 1년이 지나서 프로젝트가 다시 시작되는 경우도 있습니다. 이런 경우에는 어떻게 프로젝트 기간을 산정해야 할까요? 이런 이유들을 고려해볼 때 개발자 한 사람이 자신의 이력서에 프로젝트 기간을 정확하게 기입하기란 너무나 어려워 보입니다.


3. 추상성

프로젝트의 결과란 것이 완전히 위조가 가능한 이유는 그 존재 자체가 너무나 추상적이기 때문입니다. 만들어진 소프트웨어가 너무나 방대한 경우 전체 프로젝트를 놓고 개발자가 어느 부분에 참여했는지를 따지기란 여간 쉽지가 않습니다. 물론 그가 개발한 내용을 위주로 질문을 해보면 이력서에 기술한 내용이 사실인지 아닌지를 알 수 있겠지만, 서류 상으로는 알아낼 방법이 없습니다. 당시 프로젝트의 팀장으로부터 직접적인 얘기를 듣지 않는한 어려운 일입니다. 물론 일 자체가 추상적이어서 그 자체만으로 인정받아야 하는 경우도 있습니다. 예를 들어, 각각의 개발자들이 개발한 컴포넌트를 통합하는 일은 특정한 기술이 요구되기 보다는 주어진 기술이나 사용자 인터페이스 스펙에 따라서 컴포넌트들을 통합하였으므로 이에 대해서는 구체적인 내용을 기술하기가 무척 어렵습니다.


그렇다면 해결 방안은 없는가?

가장 쉽고 확실하다고 생각되는 방법은 바로 '프로젝트 등록' 제도의 도입입니다.  이를 위해 한국소프트웨어 산업협회는 경력증명시스템 서비스를 제공하고 있습니다.


"기술인력 경력증명 시스템"은 S/W개발사업의 수·발주 과정에 있어 수요·공급자간의 안정적이고 성공적인 사업수행을 위해 필요로 하는 제반 적격심사 및 증명용 자료를 S/W업계를 대표하는 우리 협회를 통해 공적으로 증명하여 사업자간 공정경쟁을 유도하고 공인된 평가와 서비스가치의 질을 보장함으로써 S/W 산업 발전에 기여하기 위해 구축된 시스템입니다.



                                                  <경력증명시스템 흐름도>

한마디로 요약하자면, 협회에 가입한 회원이 자신의 경력과 기술자격등을 등록하면 전문가가 이를 승인한 후 최종적으로 경력을 인정하는 시스템입니다. 물론 경력 증명 위해서 관련 서류를 제출해야 합니다. SW 기술인이 객관적이며 체계적으로 경력을 관리할 수 있도록 돕기 위한 시스템이지만. 이 제도가 업계 전반에 걸쳐 활성화되기 위해서는 협회 담당자가 경력 증명승인시 협회 이름이 아닌 자신의 실명을 거론하여 객관성을 보장해야 합니다. 또한 법적 효력이 없다는 점도 경력증명 제도 활성화의 걸림돌로 작용하고 있습니다.

한편으로는 외국에서와 같이 지원자가 일했던 회사 또는 팀원에게 연락을 해서 경력 증명의 허위여부를 판단하는 문화가 필요하다고 봅니다. 이를 위해서 현재 우리나라에서 사용되고 있는 이력서 양식에 팀장이나 동료의 이름과 연락처를 적어야 하는 항목을 만들어 둔다면 (적어도 지레 겁을 먹는 사람들로부터는) '허위 프로젝트'를 예방할 수 있지 않을까 싶습니다. 

어쩌면 저의 개인적인 생각으로 성급하게 '허위 프로젝트' 조작과 같은 화두를 던지는 것은 아닌가라는 생각을 해보지만, 앞서 살펴본 소프트웨어 특성들을 고려했을 때 자의든 타의든간에 100% 완벽하게 모든 개발자들이 프로젝트 이력을 사실에 입각하여 작성한다고 생각하지 않습니다. 마지막으로 개발자 개인의 입장에서는 언제 회사를 옮길지 모른다는 생각으로 평생동안 자신의 이력을 진실되게 꾸준히 관리하는 노력도 필요하다고 봅니다.  
  
혹시 주위에서 '허위 프로젝트' 조작으로 망신을 당한 사례가 있습니까? 아울러 '허위 프로젝트' 조작을 예방하기 위해서 어떤 방법이 필요하다고 보십니까?
스마트플레이스의 글을 편리하게 구독하세요. 한RSS 추가 구글추가
크리에이티브 커먼즈 라이센스
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

트랙백 (1) | 덧글 (8)
트랙백 주소: http://www.smartplace.kr/trackback_post_217.aspx
스마트플레이스의 트랙백은 스팸방지를 위해 관리자 승인 후 등록됩니다.
GOODgle.kr 2007-08-31 17:49:47
주간 블로고스피어 리포트 35호 - 2007년 8월 5주
IT 핫이슈 : 차세대 디지털 문서 표준안 선정을 놓고 전세계적인 논란이 일고 있습니다. 요는 현재 ISO 26300 표준안으로 정해져 있는 ODF(Open Document Format)과 별도로 MS가 자체적으로 만든 OOXML(Offfice Open XML) 규격이 오는 9월 2일, ISO 위원회 투표에서 표준안으로 통과될 가능성이 커짐에 따라 오픈소스...

짠이아빠 2007-08-30 08:40:24     답글 삭제
음.. 어찌생각하실지 모르지만.. 전 한편으로 이 글을 읽으면서.. 참.. 허탈함을 느꼈습니다. 우리들이 어쩌다... 경력까지 시스템화 시켜야하는 처지에 놓였는지.. 이러다가 양심 검증 시스템도 도입되는 것 아닌지 모르겠습니다. 진실되게 사는 것은 인간 본연의 가장 중요한 인간성인데 말입니다.. ㅜ.ㅜ
TechnoBabbler 2007-08-30 17:58:01     삭제
저 역시 개개인이 정말로 진실되게 살고 있다면 바로 그게 우리가 원하는 유토피아라고 생각합니다. 그렇지 않은 현실이 너무나 안타깝습니다. 아직 이 문제가 공식적으로 확인된 것은 아니니, 제 우려가 너무 성급했기를 바랄 뿐입니다.

Magicboy 2007-08-30 12:15:27     답글 삭제
이게 사실 아주 민감한 문제죠...-_-; 분명 많은 개발자들이 자신이 참여했던 프로젝트들을 과대포장해서 이력서에 기재하고 있습니다. 하지만.. 그걸 증명할 시스템이라는 것... 넌센스라고 생각되네요. 과연 어떤 누가 있어서 IT 업계의 모든 업무를 전반적으로 다 파악하고 그 사람의 경력을 인증해 줄 수 있을까요... (특히나.. 꽤나 희귀한 분야의 일을 하는 사람이라면... 인증기관에서 그 사람의 업무를 파악하기란 거의 불가능합니다.. 그냥 그 사람이 요청하는대로 경력인증에 다 적어줄 수 밖에 없죠) ... 짠이아빠님 말씀에 공감이 갑니다....인간성이 문제죠.. 이미 대학생들이 기업 공채에 응모할 때 부터 .. 해외 여행을 단기 어학연수로 기재하는 마당이니..쩝...
TechnoBabbler 2007-08-30 17:59:25     삭제
저도 이 문제가 시스템적으로 해결될 수 있을거라고는 생각하지 않습니다. 한가지 예로 든것 뿐이며 가장 확실한 것은 역시나 인간성을 믿는 수 밖에 없는데, 그걸 또 검증하려 하니까 문제가 생기는게 아닐까 싶습니다.

여비대디 2007-08-30 13:04:48     답글 삭제
개발 관리자의 입장에서 경력을 검증하는 문제는 언제나 프로젝트의 성패와 직결되기 때문에 매우 민감한 문제인 것 만은 사실인 것 같습니다. 프로젝트 중간에 팀원 중 하나가 도저히 진도를 따라올 수 없는 수준임을 깨닫게 되는 경우, 또는 스파게티 코드를 시스템 전반에 퍼뜨리고 다니는 팀원을 발견하게 되는 경우, 여러분은 어떻게 대처 하시는지 궁금하군요. 관리자든 개발자든 제역할을 못하는 팀원의 존재는 '죽음의 행진'을 하게하는 또 다른 원인이 되기도 합니다. 어쩌면 S/W 못지않게 피플웨어에 대해서도 '가차없는' 테스트가 필요할지도 모르겠습니다.
TechnoBabbler 2007-08-30 18:01:35     삭제
프로젝트를 진행하는 중에 문제가 있는 팀원을 제외시키기란 무척 어렵습니다. 쉽게 결정할 수 없는 일이죠. 하지만 Debugging .NET Application을 쓴 John Robbins는 실제로 문제가 있는 팀원을 크리스마스 전날에 해고한 경험이 있다고 하더군요.
또한 말씀하신 '피플웨어'에 대한 테스트는 참으로 어려운 주제인것 같습니다. 흑~

3fisher 2007-08-30 14:17:26     답글 삭제
비밀 댓글이 등록되었습니다.

christian louboutin wedding shoes 2011-04-29 15:25:16     답글 삭제
프로젝트를 진행하는 중에 문제가 있는 팀원을 제외시키기란 무척 어렵습니다. 쉽게 결정할 수 없는 일이죠. 하지만 Debugging .NET Application을 쓴 John Robbins는 실제로 문제가 있는 팀원을 크리스마스 전날에 해고한 경험이 있다고 하더군요. 또한 말씀하신 '피플웨어'에 대한 테스트는 참으로 어려운 주제인것 같습니다. 흑~

이름 비밀번호
홈페이지
덧글
비밀글
RSS 피드
전체글한RSS 추가 구글추가
스마트가젯북스타일
Demo Day