가뿐한 주말과 언짢은 시간낭비

오래간만에 상쾌하고 가뿐한 주말이 찾아왔습니다.

주말이야 매 7일마다 찾아오는 것인데 '상쾌하며 가뿐한' 주말은 정말 오래간만인 것 같습니다. 요즘에는 계속 주말에 제가 해야만 하는 일들 혹은 주말에 제가 계속 공부나 연구 혹은 고민을 해봐야만 하는 일들을 안고 주말을 맞이했었는데, 이번 주에는 머릿 속을 하얗게 비워두고 쉬어도 될 만큼 뒷일을 남겨두지 않아도 되는 주말입니다.

그런데... 제 업무 자체와는 상관이 없지만, 이번 주의 목요일 금요일의 시간 낭비 자체와 시간 낭비를 하게 된 회사 정책때문에 조금 언짢은 기분이 있었습니다.

지난 달 말에 저희 팀원 중 한 명이 회사를 떠났습니다. 자발적인 퇴사가 아닌 해고였죠.

회사의 기본 견습 (probation) 기간은 3개월입니다. 법적으로 probation기간동안은 회사에서는 아무런 제약없이 직원을 해고 할 수 있기에 채용 프로세스를 통과 했어도 이 probation을 통과 해야 사실상 진정한 정직원이 되었다고 할 수 있죠. 저도 이 친구의 probation 평가 리포트를 작성하기도 했지만, 첫 3달이 지났을 때 정말 애매한 상황이였습니다.
입사할 때 조건이 시니어급이였는지 아닌지는 알 수 없었으나 그의 그간 경험이나 나이로 미루어 봤을때, 그리고 일반적인 주제에 대해 말하는 것으로 봐서는 시니어로 봐도 될 것 같은데, 조금은 새로운 분야에 대해 논할때에는 시니어의 고집과 함께 쥬니어급의 이해도를 보였습니다. 그리고 가장 문제가 된 것은 실제 퍼포먼스가 쥬니어 급이였습니다. 새로운 분야에 이해도가 쥬니어급이라고 했는데, 새로운 일은 거의 하지 못했죠. 기존 그가 익숙한 분야의 업무는 말로는 청산유수이고 모든 일이 조만간 끝날 것인 것 처럼 말을 했지만 매일매일 팀 sync up 미팅을 할 때마다 같은 업무내용에 대해 "곧 끝난다" 라는 말만 며칠간 반복이 되어 생각보다 일의 진척이 늦었었죠.
그렇다보니 처음 3개월 이후에도 Extended Probation이라 하여 추가 3달의 견습 기간을 거치게 되었는데 결국 그 기간동안 이렇다 할 진척을 보이지 못했고, 우리가 바라던 만큼의 수준을 보여주지 못해 어느날 갑자기 해고되었습니다.

원래 매니져 포함 6명인 작은 조직에서 1명이 줄어드니 이래저래 일이 몰리고 밀릴 수 밖에 없었고, 그렇다보니 제가 원래 잘 하지 않던 Ops쪽 일도 해야하여 주말에는 Ops 관련 툴들을 공부하거나 밀린 개발관련 일들을 해치우거나, 혹은 업무시간 중 바빠 미처 확인하지 못한 새로운 pilot 서비스들을 돌려보느라 이래저래 바빴습니다. 사실 그 친구가 함께했던 기간 중에도 항상 우리가 기대했던 만큼의, 또 그가 말한 만큼의 성과가 안나와 매 스프린트마다 마지막 주차가 되면 뒤쳐진 일들을 쳐내느라 바빴는데, 든자리는 몰라도 난자리는 티가 난다고, 그가 빠지니 그 정도가 더 심했었죠.

회사에서 주말근무를 요구하거나 반드시 각 스프린트마다 주어진 일을 마쳐야 한다고 강제하는 것은 아닌데, 이건 약간의 사람의 성격 문제인 것 같아요. Sprint planning에서 약속한 업무들을 모든 sprint마다 다 해치우자는 것 까지는 아니지만, 연속으로 3-4 스프린트에서 목표 달성을 못하는 상황을 제가 차마 지켜보지 못하여 저 혼자라도 더 달려서 어떻게든 목표 달성을 위해 달렸던 것 같아요. 

그래서 이전까지는 피동적으로 DevOps 포지션의 지원자를 구하다가 지난달 말 부터는 외부 헤드헌터들에게도 요청을 하는 등 조금은 더 공격적으로 사람을 구하기 시작했습니다.

그리고 이번주 금요일, 드디어 한 명과 인터뷰가 잡혔습니다.

월요일 밤에 매니져를 통해 지원자의 이력서를 받았는데, 모국인 우크라이나에서 석사를 마쳤고 전체 경력은 10년이 조금 넘었습니다. 특히나 좀처럼 구하기 힘든 DevOps 포지션의 경력이 최근 3년간 있었죠. 그래서 지금 그가 일하는 회사의 CD 수준을 파악하고자 이력서에 기재된 회사명을 검색 해 보았는데, 좀처럼 이렇다 할 정보를 얻을 수 없었습니다. 회사 공식 웹사이트는 찾을 수 없었고 페북 그룹이나 링크드인에 그 회사에서 일하는 직원들이 보이는 정도였죠.

그래도 지난 경력을 보니 우크라이나 석사 졸업 후 4-5년 정도 캘리포니아에서 웹 개발자로 일을 했고, 이후 모국으로 돌아가 다시 2-3년 정도 자바 개발자로 일을 했으며, 최근 3년간은 토론토에서 DevOps 및 자바 개발자로 일을 한 경력이 있는 점이 마음에 들었습니다. 저희 팀에 저만 자바 개발자이다보니 저희가 쓰는 오픈소스 툴에 contribution 할 일이 있을경우 그 일들이 저에게만 몰리는 상황이라 다른 자바 개발자가 있었으면 싶었거든요.

그래서 목요일 밤, 인터뷰를 준비하기 위해 코딩을 시작했습니다.
손코딩을 통한 간단한 알고리즘이나 369 게임, 혹은 fizz-buzz 같은 것을 구현하는 테스트를 하기 보다는 실제 코딩을 통해 그의 코딩 습관이나 실력을 조금이라도 엿보고 싶었기 때문입니다. 물론 인터뷰를 보기 전에 온라인 코딩시험을 치루기는 하는데, 무슨 이유인지는 몰라도 저희 회사 HR은 인터뷰가 끝난 이후에야 온라인 시험 점수를 알려줬거든요. 더구나 저는 살짝 목표 지향적인지라 업무와 무관한 지식들을 시험하기 보다는 실무에서 실제로 하는 일이나 할 법한 일과 유사한 일에 대해 실무적인 능력을 보고 싶었습니다.

제가 준비했던 문제는 지금도 저희 CD 파이프라인에서 사용중인 저희 자체 VM 클라우드 관련된 것이였습니다. VM 클라우드에서 동시 처리능력과 파이프라인 처리 병목 정도를 파악하기 위한 간단한 모니터링 툴을 만드는 상황을 가정하였고, 각 데몬에서 리포팅한 로그들을 가져와 실제 운영상황에 대한 데이터를 필터링하는 것을 문제로 만들었습니다.

실제 문제는 매우 단순화 하여 각 VM 별로 VM 생성시간과 종료 시간의 array를 입력값으로 주었을 때, 특정 moment에 운영중인 VM의 최대 갯수가 몇 개인지를 구하는 method를 구하는 문제가 한 문제였고, 두번재 문제는 각 VM Host의 매니져 서비스에서 로그를 가져와 각 VM별로 생성 요청을 받은 시간과 생성이 종료된 시간 로그를 array 형태로 뽑아낸 뒤, 2분간 처리하는 최대 VM 생성 개수가 몇 개인지를 구하는 method를 만들라는 문제였습니다. 실제로 VM이 생성된 이후 빌드를 돌리거나 테스트를 돌리는데에도 리소스가 많이 사용되지만, 내부 클라우드에서 가장 병목이 되는 것은 Disk IO였는데, VM이 생성 될 때 마다 20GB가 넘는 VM Image 파일이 복사가 되기에 성능에 가장 크리티컬 했던 것이 Disk IO 문제였던지라 실제로 툴과 스크립트를 만들어 의사결정에 활용될 만한 metric들을 뽑아낸 적이 있었던 것입니다.

문제를 내는데 코딩을 한 이유는 간단합니다. 주어진 몇 시간의 기술 인터뷰 중에 가능한 짧은 시간동안 코딩 테스트를 하기 위해서였죠.
그래서 먼저 제가 뽑아온 데이터 중에 가장 데이터가 복잡하여 연산 중 작은 오류가 있으면 오답이 나올만한 부분을 골라내고 나머지 데이터는 삭제를 했습니다. 그리고 일일히 손으로 계산을 해 보았고, 제가 계산한 값과, 테스트 데이터를 기반으로 Unit Test 코드를 작성했습니다.
그리고 각 문제별로 시간이 얼마나 주어져야 할 지를 판단하기 위해 직접 method 구현을 했고, 문제의 배경이나 요구사항, 테스트 데이터가 어떻게 주어지고 원하는 값이 어떠한 것일지를 이해 할 만한 설명 문서도 작성을 했습니다. 물론 구두로도 그 자리에서 설명을 할 예정이였지만, 문제를 풀어나가며 생기는 질문들로 인한 지연을 최소화 하고 싶어 그렇게 준비 했죠. 그리고 코딩 테스트용 문제를 다 만든 이후에는 로그에서 timestamp를 datetime으로 변환하는 것과, 로그에서 regex로 읽어올 데이터만 뽑아내는 것 관련 행여나 시간 낭비를 할까봐 답안을 작성 할 class 내에 관련 기능은 미리 method를 작성해 만들어 주었습니다. 그리고 정말 오래간만에 나서는 인터뷰인지라 인터뷰에서 질문 할 내용들도 추렸습니다.

그렇게 자정이 넘어 시작한 인터뷰 준비는 좋은 동료와 함께 일을 할 수도 있다는 기대감과 함께 새벽 2시가 넘어서야 끝이 났습니다.

그리고 금요일. 먼저 매니져가 인터뷰를 시작 했습니다. 매니져 인터뷰가 끝나고 제가 면접장으로 가는데, 매니져가 저를 붙잡고 짧게 말하더군요.

"아마 한 두개 정도의 질문만 하면 그가 어떤지 바로 알 수 있을꺼야"

의미심장한 말이였습니다. 몇 마디의 말로도 고수의 향기를 느낄 수 있는 그런 사람이거나, 정말 아니거나...

그런데 정말 불행하게도 그는 전자가 아닌 후자였습니다. 일단 영어가 정말 안되었습니다. 캐나다에서 일을 하면서 거의 처음으로 저보다 영어를 더 못하는 사람을 일터에서 만났습니다.

그래도 처음 두개 정도의 질문을 하면서는 그래도 10년가량의 경력도 있는데, 언어적 문제로 인해 답변을 잘 못하는 것이 아닐까라는 생각을 했습니다.
하지만 조금씩 더 깊게 들어갈수록 정말 아니라는 생각이 확고해졌습니다. 결국 제가 준비한 코딩 문제는 차마 꺼내지도 못했고, 일반적으로 어느 회사를 가건 질문하는 기본적인 Java 관련 질문들만 하고 끝이 났습니다.

아... 아까운 내 시간... 잠도 줄여가며 인터뷰 준비를 했건만, 지금까지 봐온 인터뷰 중 가장 준비가 안된 인터뷰였던 것 같습니다.

인터뷰가 끝난 후 그의 온라인 코딩 테스트 성적이 너무나도 궁금했습니다. 그래서 매니져에게 달려가 물었습니다. 

"아까 나에게 한 말이 무슨 뜻인지 이제 알겠다. 그런데, 혹시 HR에서 codility test 점수 알려줬어?"

"응. 받았어."

"몇 점이야?"

"0점"

"응? 뭐라고?"

"0점"

미리 점수를 안알려주는 것이야 선입견 방지를 위해 그럴 수도 있다지만, 0점 임에도 인터뷰를 arrange하는 HR은 도대체 뭐지요?

덕분에 저와 매니져가 업무시간 중 본 손실은 총 3시간 가량입니다. 저도 인터뷰 준비를 위해 문제를 만드느라 두세 시간 정도 개인 시간을 쓰기도 했지만, 매니져 역시 그와 관련된 정보를 찾아보기 위해 어젯 밤에 몇시간 동안 인터넷을 헤맸다고 하는군요.

사실 이런 문제가 어제오늘 일은 아닙니다. 수 년 전에도 다른 팀 시니어와 매니져가 HR 리크루터에게 이와 관련된 항의를 하는 모습을 본 적이 있었습니다. 사실 그 이후에 개선이 되었을 것이라고 생각했는데, 아직도 유효하더군요. 온라인 테스트 점수를 통해 미리 사람을 걸러내면 좋은 사람을 놓칠 수도 있다나요?

물론 그럴 수도 있습니다. 저도 이 회사에 오면서 봤던 온라인 시험을 볼 때 웹 환경인 IDE 툴에서 개발하는 것이 익숙하지 않다보니 처음 10분 정도는 '이게 뭐지?' 하다가 흘러갔던 기억이 납니다. 그리고 주어진 시간에 문제를 풀다보면 실수를 할 수도 있고, 그래서 평소 실력대비 점수상으로는 20-30점 정도가 낮게 나올 수도 있습니다.

그런데 0점이라도 면접을 봐야 한다니요. 0점이라면 말 그대로 주어진 문제에서 부분점수조차 획득하지 못한 것인데, 어떤 실력인지 확실히 검증이 되지 않은 사람이 아니라 확실히 수준 미달의 실력이라는 것이 검증된 사람과 면접을 본다는 것이 정말 납득이 되지 않았습니다.

DevOps로 옮긴 이후로는 처음 interviewer로 나섰던 자리인데다, 기존 팀과는 다르게 팀 차원에서 공동으로 준비한 인터뷰 문제들도 없는 상황에서 나간 인터뷰라 좀 더 많은 시간을 투자했는데, 정말 죽쒀서 개줬다는 말 처럼 너무나 허무하고 언짢은 기분이 들더군요.

지원자 일정에 따라 다음주 중으로도 인터뷰가 하나 더 잡힐 수도 있다고 하는데, 다음 번에는 제발 이런 케이스가 아니길 바래봅니다.