한빛출판네트워크

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

리크루팅과 기술 테스트에 대해 갖기 쉬운 편견, 오해들

대다수의 사람들은 회사에 취직하기 위해, 혹은 작은 아르바이트 자리를 위해서라도 면접관과 마주 앉아 본 경험이 있을 것이다. 혹은 면접관 자격으로라도 말이다. 이러한 이유 때문인지 몰라도, 런던 자바 커뮤니티(London Java Community, 런던 중심의 자바 개발자 그룹)에서는 리크루팅, 기술 테스트에 대한 꽤나 진지한 토론들이 연일 이어지곤 한다. 단순히 직업을 얻기 위해, 혹은 사람을 잘 뽑기 위한 토론으로 보일지 모르지만 그 이면에는 지원자로서는 면접관의 시각을 엿볼 수 있는, 반대로 면접관은 지원자의 입장에서 생각해 볼 수 있는 좋은 토론의 장이 되기도 한다.

최근에 주로 오갔던 토론들은 단연 기술 테스트에 대한 것이었다. 필자의 생각에 아직까지 이 정도로 가지 각색의 의견이 난무하고 "하나같이 그럴싸한" 의견들만 있는 주제가 또 있을까 싶다. 이 주제를 지겹도록 마주치다 보니 과연 테스트 지원자의 기술 능력을 완벽히 파악할 수 있는 방법이 있기는 할까 라는 의문도 문득 든다. 물론 그랬다면 우린 아마 그 방법만 파고들었을 테다.

기술 테스트가 정확히 어떤 형태의 테스트를 말하는 것인지?

우선 기술 테스트의 정의에 대해서부터 짚고 넘어갈 필요가 있다. 필자의 경험에 의하면 기술 테스트는 다음과 같은 형태가 있다.

• 과제 형태로 주어지는 프로그래밍 능력 검증 테스트. 이 테스트는 다음 테스트로 넘어가기 위한 중간 과정인 경우가 일반적이다(번역 주 : 일명 스크리닝 테스트(Screening test)).
  
  
• 역시 과제 형태로 진행되는 프로그래밍 문제 해결 테스트. 이후 과정으로 해결한 문제에 대해 면접관과 페어 프로그래밍 테스트를 한 차례 더 갖는 형태.
  
  
• 온사이트(방문) 면접 형태의 페어 프로그래밍을 통한 프로그래밍 문제 해결 테스트.
  
  
• 실제 프로젝트를 대상으로 진행하는 페어 프로그래밍 테스트.
  
  
• 구글 독스나 collabedit(온라인으로 동시에 여러 명이 함께 같은 문서를 수정할 수 있는 서비스)를 통한 프로그래밍 테스트. 컴파일러를 사용하지 못 하므로, 보통은 간단한 자료 구조나 디자인 패턴 문제가 주어지곤 한다.
  
  
• 면접실에 비치된 화이트 보드나 종이에 코드를 적어나가야 하는 이른바 손코딩.
  
  
• 임의의 프로그래밍 언어로 진행되는 프로그래밍 테스트.
  
  
• 주어진 코드를 평가하는 형태의 테스트. 단순 코드 스타일부터 시작해서 멀티 스레드 코드 등에서 발생 가능한 동기화 버그를 찾기 등, 폭이 넓은 편이다.
  
  
• "정답"이 없는 문제를 놓고 진행하는 테스트. 예를 들면 "음… 영국에서 일년에 휘발유가 몇 리터나 팔릴까요?"와 같이 "답"을 요구하기 보다 창의적인 답변, 그리고 그에 대한 면접자의 설명, 호소 능력을 검증하기 위한 테스트다.
  
  
• 특정 API나 문법에 대한 기본적인 단답형 문제를 해결하는 테스트. ("DB에서 3차 정규화는 무엇인가?" 같은 문제들이 주어진다)
  
  
• 자격증 시험처럼 보기가 주어지는 사지선다 형태의 문제지를 푸는 테스트.
  
  
• 주어진 가상의 시스템을 놓고 시스템을 디자인하는 테스트.

면접관과 마주보고 질의 응답하는 형태만이 엄밀한 의미의 "면접"이라고 생각하는 독자도 있겠으나, 여기서는 좀 더 넓은 의미로 기술 역량 측정을 위한 "테스트" 범주에 속하는 모든 것들을 다루기로 한다.

위의 테스트 예들을 쭉 훑어 보면 알겠지만, 고용주 입장에서는 이렇게나 다양한 방법으로 지원자의 기술 능력을 검증할 수 있다는 사실에 놀라며 기뻐할지도 모르겠다. 하지만 다음과 같은 것들도 함께 고려해야 할 필요가 있다. a) 각 테스트 프로세스를 구비하는데 필요한 비용도 천차만별이고, 지원자가 느끼는 부담감과 테스트 준비에 쏟는 시간과 노력도 다양하다. b) 사람을 뽑기 전에, 우리 회사가 정말로 원하는 인재상이 어떤 것인지, 또한 심사 과정에서 고려해야 하는 요소들이 무엇인지 확실히 인지해야 한다.

그래서, 당신은 어떤 인재상을 원하고 있죠?

바로 이전에 이야기 한 것들 중 항목 b) 부터 면밀히 들여다보도록 하자. 우선 놀랍게도 너무나도 많은 회사들이 이 점을 간과하고, 혹은 잘못 이해하고 있다는 사실을 먼저 말하고 싶다. 우리 모두 구글이나 페이스북과 같이 멋진 IT회사에 취직하길 원하지만, 그 회사들의 테스트 방식을 그대로 카피해서 우리 회사에서 써먹어 봤자 갑자기 멋진 인재들이 우르르 몰려와서 구글, 페이스북처럼 회사가 바뀌진 않는다(오히려 우리 회사가 갖춰야 할 최선의 테스트 방식보다 더 나쁜 경우가 태반이다). 심지어 카피해 온 구글의 테스트 방식이, 사실은 구글의 진정한 테스트 방식이 아닐지 모른다는 점도 염두해 두어야 한다. 어찌되었든, 세상에 수 많은 IT회사들은 규모와 방향도 제각기 다르기 때문에 최상의 인재들을 찾고, 발굴하여 우리 회사로 오게 만드는 가장 좋은 방법은 회사들이 스스로 자신의 위치를 깨닫고 우리 회사가 어떻게 돌아가며 어떤 환경을 갖췄고 어떤 팀에서, 어떤 역할을 갖는 자리에 지원자를 앉힐 것인지 정확히 이해하는 것에서부터 시작된다. 특히 지원자에게 기대치를 심어주고, 이를 충족시켜준다면 지원자로서는 이보다 더 만족스러운 일이 따로 없다. 지원자가 계약서에 사인을 하면서 내가 어떤 곳에서, 어떻게 일할지 자신의 미래가 머릿속에서 확고히 그려지기 때문이다. 바꿔 말하면, 한 지원자가 매우 중요한 평가 항목에서 확실한 역량을 갖췄다는 것이 판단되었고, 그 역시 자신이 지원한 포지션이 요구하는 역량의 기대치를 인지하였다고 가정해보자. 그 후 회사로부터 제안이 들어오고 지원자가 이를 수락한다면, 그 때 우린 적임자를 찾았다고 말할 수 있는 것이다.

과연 이 테스트 프로세스에 얼마나 많은 노력을 쏟아야 할까?

앞서 이야기한 확고한 리크루팅의 목적과 평가 요소를 갖추고 지원자를 테스트해야 한다는 필자의 주장은 단지 서론에 지나지 않는다. 이제 앞서 언급하였던 a) 즉 테스트를 위한 비용과 노력에 대해 이야기해보도록 하자.

아래 쪽에 있는 표에서 사용된 단위는 없음 -> 낮음 -> 보통 -> 높음 -> 매우높음 순으로 표기하였다. 몇몇 군데 기재된 것처럼 (낮음/보통)과 같이 병행 표기된 것들은 (온라인 혹은 과제 형태의 테스트)/(온사이트 면접시 드는 비용)을 의미한다. 혹시나 외국에서 거주하는 개발자를 우리 회사 면접자리에 모셔 오게 된다면, 상당한 추가 비용을 고려해야 함을 명심하도록 하자.

하단 표의 평가 항목(column headers)에 대한 설명을 곁들여 보자면, 1) 시간적 비용 : 말 그대로 테스트를 진행하고, 임하는데 소모되는 시간을 말한다. 2) 유용성 : 지원자의 입장에서는 테스트를 통해 그 회사가 원하는 인재상과 포지션의 성격을 얼마나 잘 알게 될 수 있는지를 의미하며, 고용주 입장에서는 지원자가 가진 역량을 얼마나 잘 파악할 수 있는지를 뜻한다. 3) 사전 비용 : 테스트 프로세스를 회사 입장에서 갖추는데 드는 사전 비용을 말한다. 세부적으로 어떻게 진행할 것이고, 프로그래밍 문제를 준비하는 노력 등이 포함되며, 면접관들을 교육시키고 평가 항목을 설정하는 기본적인 것도 역시 포함된다. 참고로 이 비용들은 초기에 드는 1회 비용만을 산출하였고, 새롭게 들어온 신입 면접관을 위한 비용 등의 추가적으로 발생 가능한 비용들은 고려하지 않았다. 각 줄에 적힌 테스트 방법들은 앞서 나열한 기술 테스트들의 순서와 동일하며, 설명은 간략화하여 표기하였다.

	지원자		고용주
	시간적 비용	유용성	시간적 비용	유용성	사전 비용
과제 형태의 프로그래밍 테스트용	매우높음	없음	보통	높음	높음
과제 형태 프로그래밍 및 면접관 과의 페어 프로그래밍	매우높음	높음	높음	높음	높음
온사이트, 페어 프로그래밍을 통한 프로그래밍 문제 해결	보통	높음	높음	높음	높음
실제 프로젝트를 대상으로 프로그래밍 테스트	보통	높음	높음	높음	보통
온라인 공유 문서를 통한 간단한 자료구조, 디자인 패턴 테스트	낮음	보통	보통	보통	보통
온사이트, 손코딩	보통	낮음	보통	보통	보통
불특정 프로그래밍 언어로 진행하는 테스트	낮음 / 보통	없음	낮음	보통	높음
주어진 코드를 분석하고 취약점 파악하기	낮음 / 보통	높음	보통	높음	보통
정답이 없는 문제를 놓고 진행하는 테스트	낮음 / 보통	없음	보통	보통	보통
특정 API와 문법 등의 단답형 질의응답	낮음 / 보통	보통	낮음	낮음	보통
보기가 주어지는 일종의 사지선다형 문제	낮음 / 보통	없음	낮음	보통	보통
시스템 설계 문제	높음	낮음	보통	보통	높음

누군가에게 고용주 입장에서 적당한 기술 테스트 형태를 골라보라 한다면, 고용주 입장에서의 시간적 비용과 유용성을 유심히 바라볼 것이다. 물론 적은 비용으로 가장 유용한 것을 고르는 것이 회사 입장에선 최선이 되기 때문에 충분히 합리적 선택이 될 수 있다. 또한 비싼 사내 개발자들의 귀중한 시간을 기술 면접관 이름표를 달고 지원자들의 역량을 분석하는데 할애하게 하는 것은 피차 썩 유쾌한 일만은 아니다. 그래서인지 최근 런던에서의 기술 테스트 트렌드는 첫번째 방식 - 과제 형태의 프로그래밍 테스트 - 를 스크리닝 테스트로 이용하여 온사이트 인터뷰를 진행할 수준의 지원자인지 아닌지 평가하는 방식이 주를 이루고 있다. 간혹 사지선다 형태를 사용하기도 하지만, 보통은 지원자의 치팅을 막기 위해 온사이트에서 많은 지원자를 사전 심사하기 위해서만 사용된다.

아주 뛰어난 개발자라고 해서 기술 테스트를 마냥 좋아할까?

가장 큰 문제는 기업 입장에서 지원자가 테스트에 기울이는 노력과 비용을 생각하지 않는다는 것이다. 아마 차고 넘치는 지원자들을 마주하고 숫자 몇 개로 그들을 바라보고 평가하면 족하다고 믿고 있는지도 모른다. 하지만 지원자 중 몇몇은 테스트에 할애할 시간이 여의치 않아서, 혹은 성향상 손 코딩과 같은 형태의 테스트에서 자신의 역량을 제대로 보이지 못하는 개발자들도 상당 수 있을 수 있음을 간과해서는 안 된다. 이는 결국 기업들이 "진정한 리크루팅 비용"을 생각치 못 하고 있다는 사실로 귀결된다. 지원자들은 결코 단편일률적인 잣대로 평가 가능한 능력을 가진 것이 아니다. 혹시라도 우리 회사에 가장 이상적인 개발자가 테스트 장소로 이동하고 테스트를 치르는 시간이 아쉬워서, 혹은 특정 테스트 형태에 심리적 부담을 느껴 포기한다면 어떨까? "에이 설마…" 라고 생각할지 모르겠지만 결코 적지 않은 수의 지원자들이 마음속으로 고민하며 테스트 장소로 발걸음을 쉽게 떼지 않고 있다.

그 이유는

• 대다수의 경력직 개발자들은 가족을 부양하고 있으며, 직업만이 전부가 아닌 삶을 가지고 있다. 혹은 이미 숱한 기술 테스트들을 거쳐오며 많은 경력을 쌓고 난 뒤 이직을 결심하고 보니, 여전히 자신에게 요구되는 듣지도 보지도 못 해본 새로운 테스트 방식들에 거부감을 느끼는 경우도 적지 않다.
  
  
• 오픈 소스 커뮤니티 등지에서 자신의 역량을 가감없이 발휘하는 열정적인 개발자들은 이미 MongoDB와 같이 혜성처럼 날아온 회사(번역 주 : NoSQL DB 제공 업체, 최근 1억 5천만 달러 투자 유치에 성공한 바 있다)에서 덥석 낚아채가는 바람에 지원자 명단에서 하나 둘씩 빠져나가는 중이다. 이러한 신생 회사들은 오픈 소스 커뮤니티나 GitHub와 같은 곳에서 "예비 지원자"들의 코드를 통해 진정한 역량을 평가하고 원석들을 발굴하고 있다. 그들은 열정적인 개발자들에게 절대로 "남는 시간에 우리 회사에 지원해서 프로그래밍 문제 테스트에 참가해 보세요. 물론, 테스트 때 작성한 코드들은 심사 후 곧 바로 버려질 거지만"라는 제안을 하지 않고 개발자 직을 제안한다.
  
  
• 프로그래밍을 잘하는 개발자로서의 역량을 갖췄다기 보다, 기술적 지식을 가진 공학자 타입, 즉 기술적인 컨셉을 잘 이해하여 다른 개발자들에게 쉽게 이해시키거나 넓은 스펙트럼을 갖춘 인재들 역시 그들이 조직 내의 개발자들 사이에 놓였을 때 어느 위치에서 그들의 가치를 뽐낼 수 있는지를 아는 회사들에 의해 스카우트 되어가고 있다.

여기 나열한 예들은 단지 일부에 불과하다. 하지만 이 정도의 예시들 만으로도 리크루팅을 위한 "효율적"으로 보이는 수단들을 단순히 적용하는 기업들이 경계해야 하는 것들이 무엇이며 중요한 인재들은 과연 어떻게 생각하고 행동하는지를 깨닫는데 충분하지 않나 생각한다.

수퍼 개발자가 하늘에서 뚝 떨어질 것이란 상상은 그만 두어도 좋다. 사실 많은 개발자들은 당신 회사의 기술 테스트를 볼 생각도 않고 있는지도 모른다.

지금까지 많은 기술 테스트의 예를 곁들이며 그 이면을 들여다보았다. 이제는 조금 다른 주제로 넘어가서 과연 어느 때 지원자에게 테스트를 제안하는 것이 적당할 지에 대해 논의해보도록 하자. 실제로 이는 지원자 입장에서의 기회 비용과 긴밀히 연관되는 내용이다.

보통 고용주 입장에서는 단지 회사가 갖는 리크루팅 방침, 일정에 맞춰 테스트 일자를 고르고 배치하면 그만이다. 간혹 충동적으로(내심 이성적이라 생각했겠지만) 서류 전형 직후 기술 테스트를 배치하는 경우도 있다. 지원자 입장에서는 회사 인사 담당자와 한마디 말도 건네기 보기 전에 맞닥뜨린 난데없는 기술 테스트에 당황할지 모르나, 회사 입장에선 일사천리로 잘 진행되는 것처럼 느껴진다. 굳이 비용을 들여 서류 전형 이후 번거로운 전화 테스트, 면접을 통해 단계별로 거르는 과정을 도입하지 않아도 되니 말이다. 물론 그 와중에 if 문과 for 루프도 모르는 사람이 개발자 기술 인터뷰 보러 들어와서 앉아 있을 수 있는 게 조금 곤란할 수는 있겠다. 어쨌든 당신은 "서류도 통과했고, 당연히 프로그래밍은 어느 정도 하는 사람이지 않겠나" 라고 생각하고 있는 것은 아닌지 다시 생각해보아야 한다.

다시 한번 지원자 입장에서 생각해보자. 그들 입장에서도 기술 테스트는 숫자 놀이에 지나지 않는다. 분명 온갖 회사에 자신의 이력서와 자기소개서를 보낼 것이고, 관심이 좀 더 있는 회사에는 자기소개서에서 회사 이름만 바꿔 재활용하지 않고, 나름 성의를 보이겠지만 이는 시작에 불과하다. 기술 테스트는 이보다 더 하면 더 했지 결코 순탄치 않다. 회사별로 다른 기술 테스트를 통과하기 위해 준비해야 할 것도, 심적 부담도 만만치 않다. 필자의 경험상 기술 테스트당 최소 1시간에서 어느 곳은 12시간까지 걸린 경우도 있으며, 개발자 커뮤니티에서는 평균적으로 대략 4시간이 소요된다고 말한다(번역 주 : 저자가 언급한 런던의 최근 기술 테스트 트렌드와 문맥을 고려하였을 때, "과제 형태로 주어지는 기술 테스트"를 기준으로 서술하고 있음). 만일 어떤 지원자가 기술 테스트당 4시간 씩만을 할애하기로 다짐했다면 (아니면 최소한 부끄럽지 않을 정도로) 정말로 자신이 일하고 싶은 회사를 먼저 추려내고 그 회사 기술 테스트들을 통과하려는데 우선순위를 둘 것이다. 아마 다른 회사에도 조금씩 시간을 내겠지만, 30분 언저리 혹은 신경도 안 쓸지 모른다.

지원자 입장에서 "저 회사에서 정말 일하고 싶다"라는 생각이 들게 만드는 데는 여러 가지 요인들이 작용한다. 하지만 당신이 구글이나 페이스북이 아닌 이상, 지원자들에게 당신의 식상한-기술-테스트-자료.txt 를 보내기 전에 개인적으로 귀찮을 수준으로 연락을 취하며 그들에 대한 관심을 어필하지 않는다면 아마 그들의 관심 목록에서 당신은 최하위로 떨어지게 될 것이다. 회사가 지원자 한 명 한 명에 신경을 쓰지 않는다면, 지원자가 그 회사에 신경 쓸 이유가 뭐가 있겠는가? 대학을 갓 졸업하고 나오는 구직자는 하늘에 별처럼 많지만 직업도 그 만큼 다양하다. 런던 같은 곳만 하여도 대기업, 중소기업, 신생 스타트업에 다양하고 흥미로운 포지션이 즐비하게 준비되어 구직자들이 오길 손꼽아 기다리고 있다.

그러니 다시 한번 리크루팅에 있어서 "비용 : 유용성" 이라는 척도를 따르는 것은 그저 손쉬운 테스트를 선택하고, 연이은 테스트 스케쥴 압박을 통해 좋은 인재를 놓치는 지름길이라 말하고 싶다. 그렇다고 테스트를 너무 늦은 시점에 배치하는 것도 지원자로 하여금 소중한 시간을 긴장 속에서 낭비하게 만드는 결과를 초래할 수도 있다. 어떻게 보면 어려운 딜레마로 비춰질 수 있으나, 사실 더욱 간단한 방법이 여기 있다. 당신이 잘 알려진, 누구나 입사하고 싶어하는 회사의 입장이라면 테스트를 최대한 빨리 배치 하는 것이 능사다. 많은 지원자들은 하루 빨리 이처럼 멋진 기업에서 일하고 싶어하는 입장인 만큼 기꺼이 자신의 시간과 노력을 할애할 것이다. 만일 잘 알려지지 않은 회사이거나 혹은 개발자들의-파라다이스와는 거리가 먼 이미지로 소문이 나버린 경우 지원자 한 명 한 명에 대해 개인적으로 어필하거나 대화를 시도하는 것이 큰 도움이 되리라 생각한다.

필자가 직장에서 면접관들을 코칭할 때, 예전 상관이 말하길 "난 모든 지원자들이 하나같이 열정적인 마음으로 이 회사에서 일하길 원했으면 좋겠어요. 비록 합격되는 건 소수고, 나머지는 다른 회사를 찾아 떠나겠지만, 테스트를 마친 뒤 친구들에게 "그 회사 좀 멋지더라" 라고 나중에 말할지도 모르죠. 입으로 전해지는 그 영향력을 무시하면 안 됩니다." 런던 같은 한 도시에서도 조차 이는 적용된다. 언제라도, 어느 입장에서라도 이 바닥이 생각보다 매우 좁다는 점을 잊어선 안 될 것이다.