안녕하세요, 스마트플레이스의 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% 완벽하게 모든 개발자들이 프로젝트 이력을 사실에 입각하여 작성한다고 생각하지 않습니다. 마지막으로 개발자 개인의 입장에서는 언제 회사를 옮길지 모른다는 생각으로 평생동안 자신의 이력을 진실되게 꾸준히 관리하는 노력도 필요하다고 봅니다.
혹시 주위에서 '허위 프로젝트' 조작으로 망신을 당한 사례가 있습니까? 아울러 '허위 프로젝트' 조작을 예방하기 위해서 어떤 방법이 필요하다고 보십니까?