College와 취업률 데이터, 그리고 제 체감 취업률

요즘 연이어서 저에게 문의를 주신 많은 분들께서 '취업이 잘 되는 컬리지를 가는 것이...' 라는 말씀을 하셔서 글을 올립니다.

이전에도 제 다른 포스트에 댓글이나 메일로 따로 문의주신 분들께 답장으로도 이미 나간 적이 있는 내용이긴 한데, College의 SW 학과 졸업생의 취업률에 대한 이야기입니다.

캐나다에 첫 발을 내딛기 위한 준비 하면서 컬리지를 알아보았을 때에 제가 가장 중요하게 생각하고 찾아본 데이터는 각 프로그램의 커리큘럼과 취업률 데이타입니다. 아무래도 이미 전공을 했던 분야인지라 너무나 기초적인 과목으로 커리큘럼이 되어 있으면 피하고 싶어 커리큘럼을 찾아 봤었고, 당연히 이민을 간 이후에 일을하며 돈을 벌고 살아야 하기에 가장 중요한 '취업'을 확인하지 않을 수 없었죠.

정확한 수치로는 기억이 나지 않지만, 대부분의 토론토 인근 컬리지 SW 관련 학과의 취업률 데이터는 졸업 후 6개월 이내 70%를 웃돌았던 것으로 기억합니다. 그 외에 조금 더 범위를 넓혀서 오타와나 나이아가라 등 다른 온타리오 주의 컬리지들을 찾아 보아도 낮아봐야 60-70% 정도는 되었던 것으로 기억하고요.

당시에 이 데이터는 저에게 상당히 긍정적인 요소로 작용을 했던 것이 사실입니다. 아무리 언에에서는 disadvantage가 있다고 해도 60-80%의 확률이면 충분히 스스로의 힘 만으로도 돌파해 낼 자신이 있었거든요.

이 자료는 누구나 쉽게 인터넷으로 찾을 수 있는 자료이긴 한데, 저도 처음 준비를 했을 때에는 직접 자료를 찾아 볼 생각은 하지 않았고, 유학원에 문의를 하여 자료를 받아 보았었습니다. 대부분 유학원들이 캐나다 컬리지 요강 같은 두꺼운 책이 있고, 그 책에는 각 학교/학과 별 입학시기, 입학정원, 취업률 같은 데이터들이 있었죠.

예를들어 제가 다녔던 학교의 취업률 통계 자료는 이 링크에서 찾아볼 수 있죠.

위 스크린샷은 2015년 자료 첫 장을 캡쳐한 것입니다. 저도 사실 본 포스팅을 준비하면서 처음 본 자료인데, 위 자료에서 가장 중요한 부분은 % Working Related 부분과 Available for Employment가 아닐까 생각합니다.

한국에서도 정부에서 발표하는 실업률과 취업률 수치와 실제 체감하는 정도에 차이가 많아 허수가 많다고들 이야기가 많이 나오는데, 그 원인 중 하나가 이를 계산할 때 모수가 전체를 대상으로 하지 않고 Available for Employment만을 대상으로 하기 때문이죠.

위 표에서도 볼 수 있듯, 총 6,449명의 졸업자 중 Available for employment는 2,730 명입니다. 그리고 2,730명이 취업률을 계산할 때 분모로 들어가는 숫자인데, 실제 전체 졸업자의 약 40% 수준밖에 되지 않습니다. 즉 졸업자 100명 중 10명만 취업이 되었어도 취업률 계산은 10/100으로 하지 않고 10/40으로 계산하여 25%라고 말하는 것과 같습니다.

위 테이블에서 녹색 부분에 표시된 72%라는 취업률은 캐나다에 오기 전에 보았던 수치와 상당히 유사한 수치인지라 익숙한 데이터이지만 그 옆에 Working Related의 48%는 저에게는 매우 생소한 수치입니다. 제가 컬리지를 생각하면서 받아보았던 자료에서는 절대 나온적이 없었던 과반 미만의 취업률 수치입니다.

자 그러면 실제로 제가 체감하는 컬리지 SW 학과 취업률에 대해 말씀드리고자 합니다.

다른 글과 마찬가지로 제가 경험하고 아는 캐나다 사회는 제 경험만을 기반으로 하기에 전체를 대변하기는 어려울 수 있지만, 실제 이 곳에서 생활하는 사람 중 한 명으로서 어떻게 느끼고 생각하는지를 참고하실 수는 있을 것입니다.

제가 입학을 한 시기는 2014년 1월 학기이며, 프로그램은 3년제 프로그램의 Fast-Track 과정인 Software Engineering Technology Fast-Track 과정입니다. 그리고 같은 시기에 같은 프로그램에 입학했던 친구들의 절대다수는 외국인 학생이였으며, 또 대부분이 Co-op 프로그램으로 등록을 하여 저처럼 non co-op으로 등록한 학생들은 많지 않았고, 또 non co-op으로 처음에 입학을 했어도 상당수의 학생들이 첫 학기중에 학교에 이야기 하여 Co-op으로 프로그램 변경을 했었습니다.
1월학기에 시작했던 당시 프로그램의 일정상 코업 유무와 상관없이 방학이 없이 학사계획이 잡혀있어 졸업까지 non co-op의 경우 16개월, Co-op의 경우 24개월이 걸리는 과정으로 저처럼 중간에 자퇴?를 한 경우를 제외하면 대부분 2015년 4월에서 2015년 12월 사이에 졸업을 했기에 졸업 후 지금까지는 약 1.5~2년 정도의 시간이 흘렀습니다. 같이 입학했던 친구들 중 한 명은 Software Engineering Technician Fast-Track 과정으로 8개월(2학기)만에 졸업을 했지만 총 50여명의 모수 중 1명이니 일단 예외로 하겠습니다. (참고로 그 친구는 졸업과 동시에 BlackBerry QA로 취업이 되서 월털루로 갔으며 이후로는 연락이 안되서 잘 모릅니다)

졸업 후 1.5-2년이 지난 지금 시점에서 살펴보면 졸업자의 대부분은 취업을 했습니다.

하지만 단순 취업률이 아닌 전공 관련분야 취업률을 보자면 이야기가 조금 달라지는데요, 카페나 식당, 마트 등에서 전공과 무관한 일을 하고있는 경우를 제외하고 전공 관련분야인 Software Developer, QA, Tech Support, IT 테크니션, Tech sales 등으로 취업을 한 경우는 다 합치면 21명으로 절반에 미치지 못합니다. 그리고 그 중 가장 근무여건이나 연봉 면에서 가장 나은 대우를 받는 직업군인 SW Developer (DBA 포함)로만 보자면 총 11명이 SW Developer로 현재 일을 하고 있어 25% 미만이고요.

시계를 돌려서 졸업 후 반년 정도의 시점인 2016년 여름으로 돌아 가보겠습니다.

당시에는 SW Developer로 취업을 한 사람은 총 8명이고, QA 등 다른 포지션 취업자는 정확히 기억나지는 않지만 매우 소수였습니다. 제 생각에는 당시만 해도 친구들이 근무 조건이나 연봉에서 상대적으로 나쁜 대우를 받는 다른 포지션에는 지원을 잘 안했기 때문이라고도 생각합니다.

그러면 SW Developer로 취업을 한 8명의 면면을 살펴보겠습니다.

컬리지 입학 전에 모국에서 Software Developer (or DBA) 근무 경력이 있던 사람은 저를 포함하여 총 8명이지만, 저는 제대로 된 경력자는 7명이라고 생각을 합니다. '본인 주장'에 의거하여 PHP 경력이 3년 남짓 된다는 한 친구는 같이 과제나 프로젝트를 하면서 코드를 보면 3년의 경력이 거짓 주장이거나, 제대로 된 회사에서 일을 했던 경력이 아닐꺼라고 생각되기 때문입니다. PHP의 syntax는 이것저것 많이 아는 것이 확실하지만, 프로젝트 설계나, 로직 구현 수준에서는 도무지 경력자라고 믿어지지 않는 수준이였거든요. 아마 개인 웹 서비스 개발/운영 정도를 경력으로 말한 것이 아닐까 생각됩니다.

이 7명 중 6명은 졸업 후 반년 정도가 지났던 당시 시점에 Software Developer로 취업을 했습니다. 나머지 경력자 1명은 상해에서 C++ 쪽에서 경력도 10년이 넘었고, 실력도 좋은 친구였는데, 이력서를 아무리 넣어도 좀처럼 인터뷰 기회조차 잡지 못하고 있다며 힘들어하곤 했었죠.
그 외에 기존 학력은 있으나 (Fast-track 이였기에 기존 학력이 다들 있었습니다) 경력이 없었던
친구들 중에 Software Developer로 취업이 된 케이스는 단 2명입니다. 지금은 취업이 안되 고생하던 그 상해 친구도 구직에 성공을 해서 경력자들은 100% 취업을 했고, 경력이 없지만 SW Developer가 된 사람은 현재 기준 총 4명입니다.

물론 제 체감 통계에는 여러가지 구멍이 있습니다.
제가 아는 케이스들로만 예를 들자면, 당초부터 명확히 SW 개발자가 되겠다는 의지는 없었던 홍콩인 캐나다 영주권자 아저씨는 졸업 후 모국으로 돌아갔습니다. 처음 입학 후 학기초에 영주권 갱신을 위해 머무르기 위해 왔는데, 그냥 놀 수는 없어서 컬리지에 왔고, 20대 시절에 코볼 개발을 한 적이 있기에 요즘 기술이 궁금해서 왔다고 했었죠. 캐나다에서 모델로 활동하던 여자친구와 함께 살기 위해 캐나다 컬리지에 왔던 베네주엘라 친구는 졸업 후 1년정도 지났을 때, 여자친구가 주 신청자가 되어 영주권을 받은 뒤 다시 모국으로 돌아갔고요. 또, 정확한 나이는 잘 모르지만 최소 40세 이상이였던 파키스탄인 아저씨는 나이 감점때문에 자력 이민이 어렵다는 판단으로 캐나다에 이민와 개인 비지니스를 하는 친척이 사는 도시로 이동하여 그 업체의 스폰서를 받아 영주권을 받기 위해 자발적으로 전공분야 취업을 하지 않았다고 다른 친구를 통해 전해들었습니다.

이런저런 케이스들을 모두 고려한다면 제 체감 통계도 좀 더 정확해 질 수 있지만, 제가 그들 모두와 친밀하게 지내고 있는 것도 아니고, 또 지금은 건너 건너서도 연락이 닿지 않는 사람들도 있다보니 실제 취업이 되었어도 알지 못하는 케이스도 있을겁니다만, 저와 같은 학교 같은 프로그램에 같이 입학했던 친구들도 그렇고, 주변에 다른 사람들의 경험을 통해 보더라도 대략적인 느낌은 비슷합니다.

졸업 후 1년이 넘으면 전공관련 분야는 전체 졸업자 중에 절반가량이 취업을 하고, SW Developer로는 25% 가량이 취업을 합니다. 그리고 SW Developer로 취업을 한 친구들의 면면을 살펴보면 학교 재학시 "저 친구랑 팀프로젝트 같이 해야겠다" 라는 생각이 들었던, 나름 잘한다는 느낌을 받았던 친구들이기도 하고요.

그리고 "학사/석사를 받았으나 취업이 안되어 컬리지에 다시 갈 정도로 컬리지에 가면 취업이 잘된다더라" 라는 말이 있어 이에 대해서도 잠깐 말씀드립니다.

컬리지는 직업 시장을 위한 직업 학교라는 그 특성상 학교 전체를 놓고 보자면 학문 연마를 목적으로 하는 대학/대학원 대비 전반적으로 취업률이 높을 수 있습니다. 아무래도 실질적인 특정 직업을 겨냥한 학과의 졸업생이 순수학문 학과를 졸업한 졸업생 보다는 특정 직업군에 특화되어 있기에 구직 시장에서 더 유리할 수 있죠.
하지만 이는 전반적인 컬리지 vs 유니의 이야기라면 맞을 수 있지만, 대학/대학원/컬리지 졸업자, 심지어 그냥 고졸자라도 모두 같은 포지션을 두고 다투는 SW Developer라는 직업군에서는 맞는 이야기가 아닙니다.
만약 컬리지가 아닌 대학/대학원이라면 "꼭 관련분야 취업을 해야하나?", "취업률이 전부는 아니자나!" 라는 말이 맞겠지만, 직업을 위한 교육기관에서 가장 중요한 지표는 결국 졸업생들이 졸업 후 관련분야에 얼마나 정착하는가라고 생각합니다.

대학/대학원에 대한 저의 직접적인 경험은 없지만, 저희 팀에 들어오는 갓 대학/대학원을 졸업한 쥬니어 개발자들을 통해 듣는 바에 의하면 그들 역시 그 누구도 손쉽게 취직이 되지는 않지만, 제가 느끼는 컬리지 졸업생들의 취업률 수준에 비하면 훨씬 수월하다는 느낌이였습니다.

제가 생각하는 Software, Computer Science 관련 컬리지의 취업을 정리하자면 이렇습니다.

- 학교 다닐 때 잘 했던 사람들은 시간이 좀 걸리지만 결국엔 SW Developer로 취업을 한다.

- 컬리지 졸업해서 SW Developer가 되는 것은, 낙타가 바늘구멍 들어갈 만큼의 어려운 경쟁은 아니지만 졸업하면 대부분 취업되는 수준도 아니다.

- Developer가 아니라 해도 전공 관련분야/유사분야로의 취업 역시 절반 미만으로 쉽지는 않지만 많이 어렵다고 하기는 힘들다.

- SW/CS 관련 학과로 한정지어 보자면 컬리지 졸업자의 취업률은 대학/대학원 취업률보다 낮으면 낮았지 높지는 않다.

제 블로그의 다른 글에서 오직 컬리지만이 유일한 선택지는 아니라는 말씀을 드린 적이 있는데요, 간혹 "컴싸/컴공 석사를 하는 것 보다 컬리지를 가는 것이 취업에 유리할 것 같아 컬리지로 간다" 라고 생각하시는 분들이 계시다는 것은 참 안타까운 일입니다.
컬리지와 석사는 분명 그 목적성도 다르고, 입학 요건도 다르며, 졸업의 난이도 또한 차이가 나고, 학비 역시 대학원이 더 비쌉니다. 입학 요건의 문제, 시기상의 문제, 다른 환경적인 문제, 자금의 문제, 혹은 졸업시 까지 공부를 할 자신감의 문제라면 모를까 만약 취업률을 걱정하여 컬리지에 오신다면 컬리지에 실망을 하실 수도 있을 것입니다. 만에하나 컬리지에 오시면서 70%의 취업률이라는 통계만 믿고 하위 30%에만 벗어날 정도의 노력을 하며 졸업한다면 최악의 경우가 될 것이고요.

오늘 포스팅을 준비하면서 갑자기 짧게나마 같이 생활했던 컬리지 친구들이 생각나서 오래간만에 페북/페북 메신져/링크드인/문자 등으로 연락을 했네요.

Probationary period는 안전할까?

벌써 2년이 넘었네요. 아직 스스로 준비가 되었다고 생각하지 않은 상태에서 정말 운이 좋게도 회사에 들어가게 되었고, 스스로 자신이 없는 상황이라 언제든지 당장이라도 해고가 가능한 probationary period를 어떻게 버텨야 할지 항상 고민을 하며 발버둥 쳤던 것이 바로 딱 2년전 저의 모습인 것 같습니다.

갑자기 이 이야기를 꺼낸 이유는 최근 팀 이동 후 겪은 몇 가지 일들 때문입니다.

팀 이동을 한 지 벌써 벌써 한 달이 넘었는데, 처음 2주 정도 제가 맡았던 일은 빌드 파이프라인 서비스용 플로그인을 제작하는 일이였습니다. 아니, 정확히 말하면 현재 사용중인 플러그인의 개발 프로세스를 완료하는 일이였습니다. 그 전에 DevOps팀에 몸 담았던 어떤 직원이 개발한 플러그인으로 현재 사용중인 플러그인이지만 정상적인 개발 프로세스를 거치지 않아 코드리뷰 상태에서 거의 한달 째 팬딩이였죠.

처음 이들 정도는 전체 빌드 파이프라인 서비스 서버의 구조와 플러그인 설계관련된 문서등을 참고하고 그 플러그인이 어떤 동작을 해야하는 것인지 requirement 파악에 주력했고, 이후 현재 소스코드와 그간 코드 작성이 된 히스토리를 살펴보기 시작했습니다. 오픈소스 프로젝트인지라 문서화에 중간중간 공백이 있었지만 전체 그림을 읽는데는 큰 문제가 없었는데, 문제는 코드 리딩과 히스토리 확인이였죠.

 일단 코드 리딩을 시작하니 온갖 곳에 다양한 예외처리 로직들이 있었습니다. 메인 비지니스 로직보다 더 길고 복잡하게 구현되어있는 예외처리 로직들이 제가 흐름을 쫒아가는데 방해가 되기 시작했죠. 그래서 최종 마스터 브랜치를 읽는 것이 아니라, 그간 커밋 히스토리를 읽으며 왜 그러한 예외코드들이 작성되어있는지 알아보기로 했습니다. 하지만 더욱 더 가관은 커밋 히스토리였죠. 분명 git을 도입하면서 저희가 만든 가이드라인에 의하면 한 커밋에 2개의 티켓이 포함되어도 안되고, 하나의 티켓이라고 해도 각각의 구현 내용, 목적 등에 따라 커밋을 나눠어야 하는데, 이 프로젝트의 각 개별 커밋에는 3~4개의 티켓 번호가 들어간 것은 기본이거니와 각 티켓번호마다 4~5개 이상의 수정 내역을 적어 두었더군요. 그나마 커밋 메시지에 들어온 내용이면 다행인데, 전혀 언급이 되지 않은 수정내역도 많이 있었고요.

플러그인이라 그다지 큰 프로젝트는 아니기에 하루면 충분히 프로젝트 파악이 될 수 있을 것이라는 저의 생각은 완전히 물 건너갔고, 현재 코드 구조를 읽고 이해하는데만 첫 주의 남은 근무일을 모두 소진하고 말았습니다.

코드 리딩에 결정적인 장애물은 위 두 가지였지만, 사실 자잘하게도 여러가지가 있었습니다. Java 프로젝트임에도 Java에서 사용하는 네이밍 노테이션을 따르지도 않았고, 코드 인덴테이션도 맞지도 않고, 함수명이나 변수명이 그 목적이나 의미와 잘 맞지 않은 경우도 많았으며, 프로젝트 생성 시에는 퍼블릭 함수에 Java Docs를 만들어 두고서는 관리를 전혀 하지않아 설명과 실제 코드가 맞지 않기도 했고, 유닛 테스트는 유의미한 유닛테스트를 한 것이 아니라 단순 테스트 커버리지를 어느정도 확보하기 위한 테스트들만 있었기에 유닛 테스트를 통해 각 매서드의 expected behaviour를 알아내기도 힘들었습니다.
 예를들어 플러그인에서 외부 웹 서비스를 통해 어떠한 값을 받아오면, 그 값에 따라 3가지 다른 핸들링 케이스가 나오며, 그 외의 경우에는 BAD_REQUEST exception을 던져야 한다고 가정해보죠. 그런 경우 보통 외부 서비스를 mocking 처리를 하고, 유효한 리턴값 3가지와, 유효하지 않은 임의의 리턴값을 포함한 최소 4가지 시나리오가 나오는 테스트 매서드를 만드는 것이 보통의 접근 방법이겠죠? 그런데 이 유닛테스트는 어찌 된 것인지, 외부 서비스를 mocking하지 않고, JUnit테스트 프로젝트 내에서 더미 서비스를 직접 구현했고, 리턴 값에대한 setter/getter 함수를 만들어 놓고, "외부 서비스가 1을 리턴하게 설정했을 경우 서비스는 1을 리턴해야 한다." 를 테스트 하는 말도안되는 유닛 테스트를 하고 있었습니다. 즉 실제 제품의 비지니스 로직은 전혀 테스트 하지 않고, 테스트 프로젝트 내에서 작성한 더미 클라스의 세터와 게터 함수를 확인하는 것이였죠.

사실 Java 개발자가 한명도 없는 DevOps팀에서 신입 개발자가 이 플러그인을 개발했다면 어느정도 이해를 할 수도 있는 부분이 있긴 했습니다. 그래서 어마어마한 인내심을 가지고 1달동안 이 프로젝트 리뷰를 어떻게든 해보려고 노력했던 Java Architect에게 그간의 이런저런 히스토리를 듣고 거의 처음부터 다시 작성한다는 기분으로 하나씩 하나씩 리팩토링에 들어갔습니다.

그렇게 2주 정도 지났을 무렵, 이전 팀 매니져와 만나서 이런저런 이야기를 하다가, 지금 제가 하고있는 프로젝트 상황을 잠깐 이야기 했죠. 그러자 바로 매니져가 대뜸 하는 말이 

"아. 그 코드 original author가 누군지 말 안해도 알겠다. 분명 xxx일꺼야."

"응? 맞아. 너 xxx알아?"

"알아. 너 우리회사 오기 전에 안드로이드 팀이였거든"

"근데 난 그 친구 얼굴도 본 적이 없는데? 언제부터 DevOps로 옮긴거야?"

"말하자면 긴데, xxx가 첨에 면접 통과해서 Intermediate 급으로 안드로이드 왔었지. 근데 너 그 프로젝트 보면 이해 되겠지만, 도저히 같이 일할 수 없어서 probationary 기간 중에 그만 뒀어"

"뭐야? 그럼 회사 나갔다가 다시 DevOps로 재입사 한거야?

"응. DevOps에서 면접본거 우연히 알게되서 안드리(DevOps 매니져)에게 절대 뽑지 말라고 얘기했는데, 2년이면 사람이 바뀔만한 충분한 시간이고 면접할 때 인상 좋고 잘했다면서 구지 뽑더니만... 결국 DevOps에서도 2달정도 있었나? 그러다 짤랐지."

"그래, 솔직히 프로젝트 코드 보면서 어쩜 이럴까 싶긴 했는데... Build Tool 전문가가 그냥 코드 짰거나 쥬니어나 인턴이 작성한건줄 알았어"

"걔 DevOps엔 시니어로 들어왔어! 그것도 Java Specialist로!"

"DevOps에 Java Developer가 없어서 면접볼때 제대로 확인 못했나보네"

"아냐, 우리팀에서 면접권으로 같이 나가서 봐줬었어"

"그럼 우리팀 면접 질문에 문제가 있네. 바꿔야지"

"근데, 참 신기한게 내가 xxx 채용 할 때에도 면접할 때엔 정말 인상 좋았어. 기술면접 진행한 시니어들도 평가가 좋았고. 그래서 채용한거고"

"안드리도 마찬가지였나보네."

"응, 내가 그래서 속지 말라고, 진짜 후회한다고 그렇게 말렸던거지."

잠시잠깐 제가 개고생 하고있는 프로젝트의 원작자의 뒷담화?를 하면서 속으로 뜨끔 했습니다.

'헉! 그래... 면접을 잘 봐서 실제 실력보다 과대평가 되서 다른 회사에 간다면 이런 일이 생길 수도 있겠구나. 내가 만약에 그 전에 면접에서 어찌어찌하다 잘 되서 다른회사로 이직 했으면 바로 이 꼴 났겠다.'

불행인지 다행인지 사실 저는 직접적으로 팀 내에서 이런 팀 동료를 아직까지는 만난 적이 없기는 합니다. 게으른 동료들은 있어도 못해도 잘하는척, 몰라도 아는척 하면서 자기 실력을 뻥튀기 하지는 않았거든요. 대학생 코업 학생 중에 그런 친구가 한 명 있긴 했는데, 팀원 다수가 매니져에게 차라리 인력 1명이 줄더라도 그 친구는 있는 것 보다 없는 것이 오히려 도움이 된다고 이야기 해서 그 친구는 다른 팀으로 보낸 이력이 있죠. 그래도 그나마 그 친구는 코업 학생이라 해고되지는 않았는데 이 친구는 intermediate와 senior로 들어와 그 미만의 실력을 보였던지라 회사에서 probationary 기간 중에 바로 쫒아 낸 것이였죠.

그리고 플러그인 개발을 마친 후 빌드용 VM관리 서버의 동작 확인을 위해 VM관리용 서비스 C# 프로젝트를 오픈하고나니, 또 비슷한 상황을 볼 수 있었습니다. 당연히 같은 친구가 한 일이라 생각했는데, 또 다시 제가 모르는 다른 이름이 나오더군요. 그래서 처음 DevOps팀 설립 멤버인 동료에게 물어보니 이런 말을 해주더군요.

"아, 전에 팀에 있던 사람이야. 지금은 회사 떠났어. 처음에 우리도 Continuous Delivery 공부하면서 팀을 만들 때, 인력 확장도 필요하고, 기존에 관련 경험과 경력이 있는 사람이 필요해서 채용한건데, 사실 우리가 이에대해 아는 것이 없다보니 그 사람이 얼마나 아는건지, 제대로 아는건지 확인을 하지도 못하고 채용했던 사람이야."

역시나 약간의 허세와 말빨, 그리고 인터뷰를 위한 공부를 통해 들어왔던 사람 이였던 것 같았습니다.

예전에 차승원씨가 삼시세끼에서 손호준씨를 칭찬하면서 이 모든 것을 갖추었다며 이런 말을 한 적이 있었죠.

“능력이 없으면 열정이 있어야 하고, 열정이 없으면 겸손해야 하며, 겸손하지도 못하면 눈치가 있어야 한다”

그런데 Probationary 기간 중에 해고되었던 그 친구들의 사례를 보면, 차승원씨가 한 이야기 중에 눈치는 확실히 있었던 것 같네요. 능력과 열정은 없거나 부족하지만, 겸손하기는 커녕 자기 자신을 과대포장해서 인터뷰 시에 눈치껏 잘 홍보 한 것이죠.

그리고 코드 자체를 보면 능력이 부족하다는 것이 (적어도 Senior로 들어온 사람으로서는) 명약관화하게 보이며,  코드리뷰 히스토리를 보면 정말 겸손함과 열정이 없습니다. 회사 가이드라인에 맞지 않은 커밋에 대해 Architect가 초반부터 지적했음에도 조금도 개선되지 않았죠. 사실 git이기에 본인 브랜치 삭제하고 커밋을 다시 잘라 push해도 되는 일인데, 그 리뷰에 대해 "나 그 가이드라인 따르려고 많이 노력중임. 그런데 그거 다 따라하기는 어려움. 일단 그냥 마지막 커밋 기준으로 코드 리뷰 해주길 바람. 돌려보면 동작함" 이런 답변을 달고 끝낼 정도로 열정도 없고, 리뷰어에 대한 존중도 없었죠.

최근에 갑자기 Probationary기간에 해고된 2명의 직원 이야기를 몰아서 들은 후에, 제대로 다른 회사에서 Senior로 일 할 만한 실력도 준비도 안된 상태에서 면접을 보러 다녔던 제가 부끄럽기도 했거니와 오히려 이직을 하지 않은 것에 대한 감사함이 떠오름과 동시에, 2년여 전 처음 어쩌다 입사를 해서 항상 게눈을 하고 이곳저곳 동태를 살피며 눈치보고, 캐나다 직장에서는 나에게 바라는 기대치가 얼마일지 전혀 감을 잡지 못해 행여나 운 좋게 잡은 직장에서 해고당할까봐 밤 늦게까지 공부하고 일하면서 보냈던 그 때의 시간이 다시 생각나기도 했네요.

그 때엔 능력은 정말 없었지만, 열정도 있었고, 또 스스로를 바닥이라고 생각했던 만큼 당연히 겸손했으며, 모든 것이 불안했기에 당연히 또 눈치가 있었는데, 요즘 겨우 경력 다시 시작한지 2년 조금 넘었다고 열정은 있으나 거만하고, 눈치없이 자기 목소리만 너무 내세우지만, 그렇다고 또 어디 가서도 지지않을만큼 당당한 실력도 갖추지 못한... 그런 애매한 실력에 성격도 좋지 못한 개발자가 된 것 같네요.

팀 이동도 했고, 새로운 분야에서 일을 시작했으니 초심으로 돌아가 하나씩 다시 배워봐야 할 것 같습니다.