한빛출판네트워크

제공 : 한빛 네트워크
저자 : Trisha Gee
역자 : 김동혁
원문 : Technical Tests: You’re Doing It Wrong, Part 2

불필요한 테스트를 없앨 수 있는, 회사와 지원자 모두를 위한 대안 그리고 해결책들

기술 테스트 : 과연 제대로 이루어지고 있는 걸까(Part 1)에서는 주로 기존에 이루어져왔던 기술 테스트들의 종류, 상대적 비용 그리고 회사 입장에서 왜 지원자들이 테스트에 임하는데 드는 비용을 고려해야 하는가를 다루었다. 특히 회사가 지원자들에게 어필하고자 할 때, 어느 시점에서 무엇을 중요시 해야 할지를 지적했다.

하지만 기술 테스트의 대안들에 대한 논의에는 아직 이르지 않았었다. 대기업들은 아무래도 좀 더 규모가 작은 회사들에 비해 리크루팅면에서 유리한 점이 많고, 리크루팅 부서에서도 기술 테스트에 드는 비용을 좀 더 수월하게 감당해낼 수 있다. 예산이 충분하다면, 지원자를 개인적으로 면접 자리로 불러 대인 관계 능력을 검토하고, 지원자에게 직접적으로 어필할 여지도 더 많은 것이 사실이다. 작은 기업 입장에서 굳이 이런 프로세스를 따라 해야 하는 것도 아니며, 그래야만 경쟁이 되는 것도 아니다. 대기업에 비해 그들만의 좀 더 유연한 프로세스를 구축할 수 있다는 점에서 도리어 장점을 갖기도 한다. 만약 채용 프로세스에 개발자 인력(혹은 수석 개발자, CTO, 그 외에 기술 파트 직원 누구라도)이 투입되어야 한다면, 반드시 그 시간을 최소화 하려는 노력이 필요하다. 회사의 실질적인 이윤을 가져다 주는 서비스 개발에 쓰일 시간만큼을 채용 프로세스에 소모하는 셈이기 때문이다. 하지만 동시에 분명 개발자 직원들이야 말로 더 좋은 개발자를 가려내는데 적합한 사람들이라는 점도 명심해야 한다. 그러니 지원자를 가려내기 위해 단 하나의 채널(예를 들자면, 기술 테스트)에만 기댈 필요만은 없다. 분명 다른 대안도 존재한다.

예를 들어 지원자의 CV를 살펴보니 GitHub 계정을 적어두었더라, 그럼 곧바로 확인해 보도록 하자. 실무와는 동떨어진 기술 테스트 자리에 그들을 앉히는 것 보다, 충분 혹은 그 이상의 소득을 거둘 수도 있다. 예를 들면 각 함수에 적용된 유닛 테스트, 소스 코드마다 꼼꼼히 달린 주석들, 전체 코드 구조의 우수성, 변수/함수명 네이밍 스타일, 혹은 그 프로젝트의 목적과 용도 그 자체 역시 지원자의 성향을 파악하는데 큰 도움이 된다. 지원자가 직접 시작한 프로젝트인지 여부와 다른 프로젝트에 기여한 정도 등도 역시 중요한 판단 요소가 되겠지만, 그렇다고 우수성을 판단하는데 정답이 있는 것은 아니다. 언제나 개발자를 필요로 하는 프로젝트 혹은 그 팀에서 요구하는 조건에 기대어 판단을 내리는 것이 중요하다. 혹시 지원자가 책을 쓴 적이 있고 (예를 들면 Java8 등의 전문 기술서) 아마존에서 잘 팔리고 있다면 지원자에게 굳이 "Java에서 lambda의 기능은 무엇이죠?" 등의 간단한 질문들은 면접에서 할 필요도 없다. 이와 유사하게, 지원자의 Youtube 계정을 확인해보니 지원자가 업로드 한 영상 중 꽤나 깊은 전문 지식이 필요한 프레젠테이션 영상을 발견했다면 역시 그 주제에 대해서는 질문이나 테스트를 생략할 수도 있다. 지원자에게 주어진 질문이 "이러 저러한 제약을 가진 로봇이 이러 저러한 방 안에 있을 때 모든 구역을 탐색하려면…" 등의 실무와는 거리가 먼 질문보다는 그들의 책, 블로그 혹은 GitHub 프로필을 통해 우리가 원하는 포지션에 지원자가 얼마나 적합할지를 더욱 효과적으로 검증할 수 있다. 회사 차원에서는 지원자를 가려내는데 좀 더 유연성을 부여함으로써, 시간과 비용을 절약하고 다양한 지원자들을 포괄적으로 평가할 수 있다.

채용 담당자로서 꼭 기술 테스트를 고집하고 있다면, 이전 글에서 언급했던 효용성 표를 참조하여 지원자와 회사가 모두 윈-윈 할 수 있는 방법을 모색하길 바란다.

드디어 끝! 그런데 전체 내용이 뭐였죠?

면접 프로세스에 있어서 기술 테스트는 특별한 목적을 갖는다: 지원자가 CV에 적어둔 내용을 검증하여, 충분한 프로그래밍 역량을 갖췄는지 판단하기 위해서다. CV에 번지르르하게 적고, 면접 때 그럴싸하게 말하는 것은 마음만 먹으면 누구든지 쉽게 할 수 있다. 하지만 실제 코딩 스타일을 속인다? 그건 결단코 쉽지 않다, 설사 그런 지원자가 있다면 속이기 위해 본 실력을 그 만큼 키워야 가능할지도 모른다(이미 내용이 충분히 길어져서, 경력이나 실력을 위조하는 것에 대해서는 여기서 다루지 않도록 한다).

채용을 진행하는 회사 입장에서는 언제나 저비용, 고효율의 기술 테스트 방식을 취해서 하루빨리 인력을 충원하고 싶은 유혹에 이끌리지만, 결국 그러한 선택은 지원자에게 비용을 전가하는 꼴이 되고 만다. 게다가 위험성마저 내재된 경우도 더러 있다. 지원한 회사에서 일하기를 정말로 열망해 온 지원자가 아닌 이상, 이미 다른 방식이나 경력을 통해 충분히 자신의 개발 능력을 증명했음에도, 또 다시 기술 테스트를 요구하는 회사에 기꺼이 응할 마음이 들지 않는 것이 일반적이다. 우수한 지원자는 스스로 당신 회사의 채용 프로세스에서 빠져 나가려 들 것이다.

지원자로서는 아무래도 그 회사에 대해 좀 더 알고, 어떤 포지션에서 사람을 구하고 있는지 또는 내가 정말 그 곳에 입사하길 원하는지를 알기도 전에, 지원한 많은 회사들의 기술 테스트에 일일이 대응한다는 것은 여러모로 힘든 일이다. 구직활동 자체가 하나의 풀 타임 업무인 셈이며, 때로는 그냥 쉽게 쉽게 하려는 유혹에도 끌린다(원문 : stick with the devil you know, 악마의 꾀임에 넘어간다 치면 그 중 낯 익은 악마에게 더 이끌린다…는 표현). 즉 이게 과연 내가 얻을 수 있는 최고의 직장인지 생각할 것도 없이 남은 관문이 적거나 쉬운 쪽으로 마음을 돌려버릴지도 모른다는 이야기다.

필자는 이 논리들을 토대로 양측에게 좀 더 나은 선택을 가져다 줄 수 있는 옵션들을 아래와 같이 정리해보았다.

지원자를 위한 대안들

• GitHub로 눈을 돌려라. 지금 말하려는 건, 갑자기 근사한 오픈 소스 프로젝트를 하나 시작하라! 가 아니다. 그렇다고 OpenJDK와 같이 유명한 프로젝트에 커미터로 이름을 올리라는 것도 아니다. 작은 몇 개의 프로젝트라도 관심 있게 유지하거나 단 몇 줄의 pull request라도 좋으니 오픈 소스에 기여해보라는 것이다(독자 중 원하는 사람이 있다면 필자가 하나쯤 accept 시켜 줄 수도 있다!). 이 작은 노력만으로도 당신과 똑 같은 위치에 있는 다른 개발자 중 90%를 제치고 앞서나갈 수 있다.
  
  
• 블로그를 시작 해라. 필자도 여러분이 딱히 블로그에 올릴 내용이 없다는 걸 잘 안다. 단지 예전에 겪었던 프로그래밍이나 인스톨 시 겪은 어려움을 풀어 쓰는 것으로 불씨를 당겨 보는 것도 좋다. 분명 어딘가에는 당신이 겪었던 문제와 똑같은 것으로 머리를 싸매고 있는 사람이 있을 것이다. 필자의 경우 그냥 배웠던 내용을 포스팅하는 것으로 블로그를 시작했고, 그것이 결국 현재의 커리어를 가질 수 있도록 나 자신을 변화시켰다.
  
  
• 하루 10분, 1주일에 1시간을 StackOverflow(세계적으로 유명한, 프로그래머들을 위한 QnA 기반 커뮤니티)에 쏟아라. 질문을 해도 좋고, 답변을 해줘도 좋으며, 이미 이뤄진 토론 글들을 좀 더 읽기 쉽게 포맷만 바꿔준다거나 하는 식으로 어떻게든 당신이 기여할 수 있는 구석은 있을 것이다. 다른 사람들에게 초보로 보일 까봐 괜히 걱정할 필요도 없다. 오히려 누군가 당신의 질문에 좀 더 논리 정연하게 답변해주려고 답변을 다듬어 줄 수도 있고, 오류를 수정하거나 보완해 주어 결과적으로 커뮤니티 본연의 가치를 높이는데 기여한 셈이 될 것이다.
  
  
• 지역 유저/개발자 그룹에 가입해라. 필자가 거쳐왔던 많은 직장들에서 유저/개발자 그룹 모임을 통해 채용된 개발자들을 어렵지 않게 만날 수 있었다. 당신의 활발하고 사교적인 성격을 4시간 동안 묵묵히 코딩하는 것으로 평가 받기 보다 이런 곳에서 어필할 수 있다면 아무래도 더 유리하지 않을까?
  
  
• 저명한 국제 학회에서 발표하는 것만이 경험이고 CV에 쓰기 부끄럽지 않을 수준의 경력인 것은 아니다. 지역 개발자 그룹에서의 라이트닝 톡(Lightning talk, 짧고 간결하게 이루어지는 비교적 덜 형식적인 발표) 수준일 필요도 없이 Webcast/ Youtube/ Slideshare등을 통해 자신이 알고 있는 것들을 정리해서 온라인으로 알리는 것만으로도 충분하다. 물론 앞서 말한 경험들은 더 말할 나위 없이 우수한 경력들이다.

위의 사항들만 잘 살려도 기술 테스트의 압박에서 다소 벗어날 수 있을뿐더러, 만약 당신이 약간의 인턴 경력(혹은 비전공자로서 개발자에 뛰어들었거나)만을 가진 채 졸업하는 상황이라면 포트폴리오를 좀 더 알차게 구성할 수 있는 조언이 되리라 믿는다.

회사를 위한 대안들

• 피드백을 받아라. 아마 지금 이 순간에도 계속해서 지원자들이 등을 돌린다는 사실을 인지하지 못 하고 있는지도 모른다. 채용 전담 에이전트를 고용하고 있거나, 사내 HR팀을 운영 중이라면 채용 프로세스 도중 자진 하차한 지원자들을 찾아, 그 원인을 분석해보아라. 또한 분석 결과를 다음 채용 프로세스에 반영해라. 지원한 사람들이 힘들게 몇 시간 동안 기술 테스트를 거치고 나서 "불합격" 3글자만 달랑 받는 것을 좋아할 리 없다. 비록 원하는 기회는 떠나버렸지만 자신이 어떤 점에서 부족했는지, 무엇을 개선하면 좋을지를 나중에 들을 수 있다면 지원자 개인으로서도 큰 도움이 될 것이고, 다른 잠재적 지원자들에게도 간접적으로 영향을 주어 긍정적 효과를 기대할 수 있을 것이다.
  
  
• 현실적이 되어라. 만일 지금 필요한 개발직 자리가 악몽 같은 유지 보수직이라면 지원자를 테스트할 때 그에 걸 맞는 스파게티 코드 수정하기 혹은 코드 상의 하자를 찾는 테스트를 적용해라. 뜬금없이 온라인 스포츠 게임 설계를 하라며, 화이트 보드에 구조를 적어보라는 식의 형식적인 면접은 실제로 필요한 역량을 측정하는데 하등 도움이 되지 않는다. 지원자에게 너무 티나게 보이는 건 사실일 테지만 원하는 포지션에 더 알맞은 사람을 찾을 수 있을 것이고, 지원자가 입사 후에 이런 일을 하게 될 줄 몰랐다며 기겁하는 사태도 미연에 방지할 수도 있다.
  
  
• 유연하게 생각해라. 어떤 지원자가 GitHub에 줄줄이 많은 코드를 작성해두었다고 치자. 그런 지원자에게도 기술 테스트를 치르게 해야 할까? 그 지원자의 GitHub를 통해 유추한 사항 외에 검증해야 할 사항이 있다면 그 부분들에 대해서만 추가 테스트를 적용해라. 약간 의문스러운 부분 10%를 검증 하기 위해 준비된 전체 기술 테스트를 진행할 필요가 없다. 한 지원자가 자신의 블로그에서 회사에서 고려하던 부분을 잘 설명하는 글을 올려두었다면, 굳이 이를 검증하기 위해 반복시킬 필요는 없다. 서로 간의 시간을 아끼는 것은 중요하다.
  
  
• 회사 내 개발자 직원들을 유저 그룹에 참여시켜라. 그 곳에서는 다양한 사람(발표자, 혹은 단순 참가자) 들이 기꺼이 경험을 쌓고 지식을 나누고자 자신의 시간을 할애하여 참가한 것이다. 이는 지식과 배움에 대한 그들의 열정을 여실히 보여주는 증거다.
  
  
• 더 좋은 방법은, 개발자 직원들에게 유저 그룹이나 학회에서 발표하게끔 독려하는 것이다. 이 방법을 통해 정말 뛰어난 개발자들을 당신에게 끌어오는 계기를 만들 수 있고, 혹은 최소한 회사 이름을 좀 더 알릴 수 있는 자리가 될 것이다.

기본적으로 언제나 지원자들을 존중하고 한 명의 "개인"으로 대해라. 회사의 면접 프로세스는 그 자체로 회사를 홍보하는 수단이자 대표하는 이미지를 지원자들에게 심어주며, 사람들의 입소문을 타고가 긍정적인 이미지를 도처에 남길 것이다.