개발자 채용을 위해 수 많은 이력서와 그들의 경력사항을 중점적으로 보면서 느낀 게 있다. ‘개발자의 능력은 오로지 개발 능력으로만 판단되지 않는다.’라는 것이다.
자기PR은 꼭 개발직군만이 아니라 다른 직군에서도 매우 중요한 능력 중 하나라 생각된다. 하지만 자기 PR에만 특화된 개발자들과 함께 일해 본 적이 있는데 ‘아는게 하나도 없어도, 모두 아는 것처럼 PR 할 수도 있구나’ 라고 느낀 경우가 있었다. 흔히들 말하는 ‘입 개발’에 능한 사람들에 대해서 말해보고자 한다.
1. 첫번째 사례
한국의 명문대를 나왔고, 사실 IT쪽 학과라고는 하기는 좀 애매했지만 경력상으로 봐도 문제없고, 면접에서도 질문에 완벽하게 대응해 꽤 높은 수준의 개발자라는 평을 받은 신입이 있었다.
근데 이 신입이 첫 출근 하던 날 API문서와 기존 테스트서버를 오픈하며 교육을 진행하고 있는데 REST방식의 API통신의 개념을 이해하지 못했다. 분명 이력서에서도 모바일 앱과 통신을 개발하고 푸시서버를 구성하는 것에 대한 이야기를 적어두었다. 면접에서도 REST방식은 어떤 것이 좋고 나쁜지 주절주절 잘만 얘기했는데 정작 실무를 시작하니 통신하는 원리를 모르고 있는 경우였다.
대체 어떻게 면접을 통과한 것일까?
그 당시 면접관이었던 나는 혼란스러움을 아직도 떨치지 못했다.
2. 두번째 사례
엘리트로 이루어진 스타트업에 일할 기회가 있어 기존 인프라를 분석 중이었다. 고질적으로 발생되는 문제점에 대해 근본적인 이유를 찾아내어 어떻게 수정을 하는 게 좋은 것 같냐고 카이스트 출신 CSO와 서울대 출신의 CTO에게 나의 의견을 개진했다.
한참을 떠들었지만 그들은 내 말을 전혀 이해하지 못했다. (이해하지 ‘않’은게 아니라 ‘못’했다.) 나는 그들에게 설명하기 위해 슬로우쿼리라는 개념과 Push agent를 설명하는데 꼬박 3일을 보내야만했다. 물론 대표는 ‘새로 온 개발 팀장이 최상위의 기술자 CTO와 CSO와 급이 맞지 않아 의견충돌이 있구나’라는 선에서만 이해했고, 정작 교육을 실시하고 있던 나는 왜 저런 사람들이 엔지니어 책임자로 있는지 이해할 수 없던 적이 있다.
그리고 교육(?)이 끝난 다음 날, CEO에게 데이터베이스 안정화 방안과 푸시알림에 관한 전략을 설명하는 CTO를 보며.. 또다시 내 말을 제대로 이해하지 못했음을 개탄하며 쓰린 속을 부여잡고 있었다.
3. 세번째 사례
작은 SI 스타트업의 기존 멤버들이 그들의 수준은 부족함을 인지했고, 해결책으로 고령의 많은 경력과 연륜을 갖춘 개발자를 채용하여 개발팀의 기틀을 잡고자 했다. 헤드헌팅업체에 연락해, 여러 대기업에서 개발자로 근무하며 수백 줄에 이르는 많은 프로젝트를 진행했으며 연봉도 어마무시한 수준을 제시한 개발자를 제시받아 그를 채용하기에 이른다.
하지만 대표는 채용 후 한달 만에 그것이 잘못된 선택이었음을 깨닫는다.
그 새로 채용한 고령의 개발자는 개발자가 아닌 처음부터 개발자관리직에 있었던 사람이었다. ‘실무개발’ 이라기 보다는 ‘실무관리’를 해왔던 것이다. 스타트업이 정작 그에게 원하는 형상관리, 프로젝트관리, 인프라관리의 실무는 전혀 모르고 ‘실무를 할 수 있는 전문가’를 다룰 줄만 알았던 것이다.
헤드헌터측에서 말한 내용과 너무 달랐다. 헤드헌터업체도 그 방면에 아는 것이 없이 단순 실적을 위해 사람을 끼워넣은 사례였다.
그 새로 채용된 개발자는 첫 날 출근과 동시에 직무가 자신의 이력과는 상관없는 일임을 깨달았지만 참고 견뎌 연봉을 받을 수 있을 때까지 받아보자는 생각으로 버티면서 작은 회사에서는 참 중요한 자산인 한 달이라는 시간을 낭비하게 한다.
해리포터 영화 시리즈를 보면서 위의 3가지 경우에 매우 적당한 인물이 하나 등장하는데, 질데로이 록허트가 바로 그 인물이다. 근거없는 실적을 책으로 옮겼고 맹목적으로 추종하는 팬들 덕분에 명성을 얻게 되어 그로 인해 호그와트의 교수로 부임한다. 하지만 핵심적인 사건이 터질 때마다 한발 늦게 그리고 발 빼기 매우 적절한 시기에 등장해서 그의 도움이 필요할때마다 이런저렁 핑계를 대고 실체가 밝혀진 뒤 철저하게 실무자들에 의해 무시당하고 폐인으로 남는다.
사실 어느 직종이나 마찬가지지만 실력의 검증은 매우 어렵다. 그런 대안으로 코드리뷰를 요청한다던가 알고리즘테스트 혹은 레퍼런스 테스트등 여러가지 방법을 동원한다. 하지만 각각의 대안은 빠져나갈 구멍이나 약점들이 있다. 실력검증은 일단 직접 업무를 함께 진행하면서 판가름 낼 수 밖에 없는 게 현실이다.
좀 안정되고 시스템이 갖추어진 기업에서야 시간이 해결해주는 문제이겠지만 그럴 시간과 시스템이 없는 스타트업 혹은 소기업의 경우에는 이러한 입개발자들을 걸러내기란 정말 어려운 숙제와도 같다. 가뜩이나 사람도 많이 없는 편에 대기업급의 복지와 급여가 제공되지 않는 조직에서는 과연 어떤 식으로 이런 사람들을 판별해 내야 할까?
‘입사 전까지 이러한 개발자들을 걸러 낼 방법은 없다.’ 난 이 전제를 깔고 채용을 시작했고 딱 두 가지의 대안만 남는다고 보는 쪽이다. 한 가지 대안은 경력을 부풀린 개발자들을 채용 후 능력 개발을 시키는 것이다.
다음으로는 실제 채용의 시간을 넉넉하게 잡고 몇 몇을 거를 수 있는 여유를 두는 방법이 있다. 바로 채용을 없었던 것으로 하면 깔끔하게 끝나는 거 아니냐는 말이 나올 수 있다. (수습 기간동안 보고 아니다싶으면 언제든 쿨하게 내보내고 다시 구인하는 방식. 그러라고 수습계약 이라는것도 존재한다라는 의견)
그러나 나는 첫번째를 선호한다. 내 개인적인 경험에 따르면, 개개인이 가진 능력 이상의 PR을 했다면 그 분야에 아무런 지식이 없거나 능력이 크게 떨어지지는 않는다라는 것이 내 결론이다.
아직 능숙한 경력은 없지만 그만큼 분야에 관심을 많이 가지고 있으며, 아는 만큼 경험을 쌓고자 발버둥 친 결과라고 생각한다는 의미다. (내가 상식선에서 사람 보는 눈이 있다는 전제하에서.. )
가령 예를들어 이런 쪽으로 생각해볼 수 있다. 서버전문 개발자로 근무한지 5년여 된 개발자 R씨가 있다. 근무 중 모바일 앱 프로젝트를 진행했고, 모바일 앱 개발자들과 어떤 방식으로 API 통신을 해왔는지 지식을 쌓았다. 그에 흥미를 느껴 개인적인 프로젝트를 진행하며 완전히 모바일개발자로 전향하려는 목표가 만들어졌다. 하지만 서버 개발자로서의 5년여 경력도 버릴 수 없었고 경력은 짧긴 하지만 아는 것은 많은 지라 서버개발경력으로 알고 있는 지식과 개인적으로 진행한 모바일 개발 지식으로 PR을 매우 성공적으로 했고, 그는 그렇게 모바일 앱 경력 개발자로 입사하게 된다.
하지만 개인적으로 배운 기술로는 단순한 개발진행은 되었을지 몰라도 해당 경력에 맞는 디자이너들 과의 협업, 화면 설계, 디버깅, 이슈관리, 형상관리 등등에서 문제점이 발견되었고 결국 모바일팀에서 R씨는 입개발자로 낙인 찍히고 만다.
이 R씨는 입개발자로 낙인 찍힌채 회사에서 채용취소가 되어야 하는 것일까? 처음부터 솔직히 면접때 ‘앱 개발 쪽은 처음이긴 하지만 개인적인 프로젝트로 경험을 쌓았고 실무경력만 없는 것이니 경력 대비 연봉은 조금 까이더라도 감수하고 입사하고 싶다’는 식으로 말을 풀어 갔으면 베스트였겠지만 사실 그렇게 해서는 개발자 업종을 전향한다는게 쉽지 않다. 그렇기에 어떻게든 발을 들여놓고 난 뒤 빠른성장으로 입증해 내겠다라는 의지로 입사하는 경우도 있기 때문에 마냥 욕먹어도 싼 개발자라고 치부하기엔 조금은 안타깝다.
반대로 자신의 뛰어난(?) 이력 혹은 말빨만으로 날로 먹으려 하는 사람도 분명히 있다. 이 역시 ‘먹튀가 목적인 질데로이 록허트’이냐 아니면 ‘개발 전공 변경이 간절한 개발자이냐’하는 판단의 선택이 기로에 선다.
이래저래 고민만 할 시간에 효율적인 방법을 찾는다면 입개발자를 해고시켜버리는 게 제일이겠지만, 자유로운 개발전공 변경의 길이 좁아지는 것은 역시 옳지 않아보인다. 서로에게 너무 어려운 문제다.결국 근본적인 문제는 그런 ‘명성 혹은 자기 PR에만 능통한 개발자가 되지 않도록 하는 환경이 중요하다.’겠지만 그 것보다는 전세계 평화가 더 먼저 올 것같다.
