블리자드의 개발팀은 ‘좋은 개발자’를 어떻게 채용할까?

모든 것이 소프트웨어화되면서 비즈니스에서 개발자의 중요성이 더욱 커졌다. Developer Relations, DevRel도 그러한 흐름에서 나왔다. 제품과 핵심 기술 중심의 커뮤니티를 운영하고 개발자에 대한 분석과 지원을 제공하며 브랜드를 제고하고 인재를 채용하는 역할을 하는 직업이다. DevRel은 없던 것이 갑자기 생겨난 것이 아니다. 《개발자로 살아남기》 속 블리자드의 한 개발팀의 채용 이야기는 오늘날의 DevRel의 가치를 블리자드는 그 전부터 어떻게 실천해왔는지, 인재를 채용하기 위해 어떻게 해야 할지에 대한 힌트가 되어 줄 것이다. _편집자 주

프로세스는 도로 체계 같습니다. 운전자와 보행자가 사고 없이 안전하고 쾌적하게 이용할 수 있어야 좋은 도로입니다. 좋은 프로세스라면 문제가 발생하지 않아야 하며 적합하고 효율적이어야 합니다. 처음 일하는 사람이 와도 그대로 따라 하면 되도록 프로세스를 세워야 합니다. 한 번도 가보지 않은 도시에 가서도 운전을 할 수 있는 이유는 도로라는 프로세스가 마련되어 있기 때문입니다. 잘 설정된 프로세스는 실수를 예방합니다. 앞서 블리자드 채용 사례에서는 사랑해서, 혹은 미워해서 저지를 수 있는 실수를 방지하고자 가장 높은 점수와 가장 낮은 점수를 제외하고 지원자를 평가했습니다. 이처럼 프로세스를 잘 만들고 나면 잘 따라야 합니다. 최고와 최저 점수를 제외하기로 해놓고 실행하지 않으면 아무런 의미가 없습니다. 한 번 잘 만든 프로세스를 반복 사용하는 것이 중요합니다. 그런데 세상은 빠르게 변합니다. 변화에 맞게 프로세스도 변해야 합니다. 5년 전에 채용할 때와 현재 채용할 때의 상황은 회사 사정과 세상 사정 모두가 판이하게 다를 겁니다. 5년 전의 채용 프로세스를 고집하면 과거에 잘 짠 프로세스가 현재의 발목을 잡게 될 수도 있습니다.

영국 버킹엄 궁전과 관련된 유명한 일화가 있습니다. 궁전 한 구석을 병사 두 명이 항상 지키고 있더랍니다. 관광객이 왜 지키냐고 물어봤더니, 그냥 그렇게 해왔다고 대답합니다. 호기심 넘치는 관광객이 이유를 찾아냈습니다. 300년 전에 병사들이 지키던 곳에 장미 한 송이가 피었답니다. 여왕이 장미를 보고 마음에 들어서 ‘장미가 부러지지 않게 보호해라’라고 명령을 내렸습니다. 지금은 장미가 흔적도 없이 사라졌지만 여전히 군인은 그곳에 서 있습니다. 프로세스를 업데이트하지 않으면 이런 상황이 발생합니다. 과거의 프로세스를 계속 사용하면 안 됩니다. 새로 운 기술, 새로운 서비스, 새로운 문화에 맞춰 프로세스도 바꿔나가야 합니다.

다음 그림은 블리자드의 한 팀에서 사용한 채용 프로세스입니다. 단계별로 사람을 어떻게 떨어뜨리고 어떻게 합격시킬지, 우리가 보고자 하는 것은 무엇이며, 실제로 무엇을 평가할지를 문서로 정리했습니다. 심지어 이력서 단계에서 최소 20%를 떨어뜨리고, 전화 면접에서는 30%를 떨어뜨리는 수치까지도 세웠습니다. 왜냐하면 전화 면접을 했을 때 전부 합격하거나 전부 탈락하는 일이 발생한다면 뭔가 이상한 겁니다. 지원자뿐 아니라 회사에도 이득이 되는 상황이 아니지요. 블리자드에서는 과거 6개월 동안의 채용 데이터를 기록해두고, 평균적인 탈락 수치 등을 근거로 프로세스를 만들고 진행했습니다. 이처럼 최대한 데이터에 근거해 판단하는 노력이 필요합니다.

블리자드는 이력서 검토 시스템을 만들어놓고 두세 팀장이 합격 혹은 불합격을 눌러 판단합니다. 하루 혹은 이틀 안에 지원자당 세 번 정도 평가받게 하는 겁니다. 대개 조직은 현실적인 문제로 한 명이 이력서를 검토합니다. 개인 취향으로 조직된 조직은 다양성이 부족합니다. 이력서는 여러 명이 봐야 하고, 가능하면 시스템을 구축해 쉽게 교차 검토가 가능하도록 만들어야 합니다.

전화 면접은 얼굴을 보지 않으려는 의도도 있습니다. 얼굴을 보는 순간 선입견이 생길 수 있기 때문입니다. 물론 목소리를 듣고도 선입견이 생길 수 있지만, 얼굴을 볼 때보다는 덜합니다. 사람마다 성향이 있어서, 선호하는 얼굴 스타일이 있고 선호하지 않는 스타일이 있습니다. 선입견이 반영되는 것을 피하고 싶다면 줌 같은 화상 통화보다는 전화 면접을 활용합시다. 전화 면접은 보통 두 명이 진행하되, 질문은 한 사람이 합니다. 다른 한 명은 들으면서 관찰합니다. 두 명이 진행해야 만일의 사태에 대비할 수도 있고, 추후에 다른 한 명이 유사한 방식으로 다른 사람을 인터뷰 할 수 있습니다. 대개 면접관이 50분 질문을 한 뒤 지원자에게 10분 정도 질문 기회를 줍니다.

전화 면접에서는 ‘스크립트’가 중요합니다. 블리자드는 반드시 스크립트를 만들어 전화 면접을 진행합니다. 프로세스는 데이터를 근거로 해야 합니다. 지원자 10명에게 모두 다른 질문을 한다면 어떻게 데이터를 수치로 비교할 수 있을까요? 비교 가능한 데이터를 만들려면 같은 질문을 사용해야 합니다. 그래서 전화 면접에는 스크립트가 필수입니다.

그렇다고 해서 8가지 질문만 만들어 모두에게 8가지 질문을 반복하면 안 됩니다. ‘블리자드는 인터뷰에서 똑같은 질문만 해’라고 소문이 돌고, 질문지가 돌면 아무 변별력도 없지 않습니까? 블리자드는 충분한 질문 풀^pool을 만들어놓고, 8문항 정도를 상황에 따라 물어봅니다. 질문 풀은 매년 업데이트하는 게 좋습니다. 물론 스크립트에 없는 질문을 해도 됩니다. 하지만 스크립트가 있어야 비교가 용이합니다. 면접관이 질문을 하고 답변을 기록해 데이터베이화해놓으면, 다른 관리자가 평가할 때도 활용할 수 있어 유용합니다.

요즘은 웹사이트에서 코딩 테스트를 진행합니다만, 제가 블리자드에 있을 때만 해도 이메일로 과제를 줬습니다. 집에서 혼자 하는 과제를 내 주고 프로그래밍해서 보내게 했습니다. 오픈북 시험과 비슷합니다. 지원자가 마음대로 코딩해볼 수 있게 시간을 충분히 제공합니다. 이렇게 테스트하면 지원자의 최대 역량을 엿볼 수 있습니다. 물론 다른 사람의 코드를 훔쳐서 제출하는 부작용도 있습니다. 그럼에도 ‘메일 인 테스트^{mail-in test}’는 유효합니다. 어차피 이후 면접에서 프로그래밍한 내용을 물어보게 됩니다. 본인이 만들지 않은 프로그램이라면 바로 들통날 겁니다.

코딩 테스트를 웹사이트에서 진행하면 답답한 면이 있습니다. 지원자 자신이 원래 쓰던 도구가 아니므로 부족한 점이 많죠. 웹사이트에서 진행 하는 테스트는 마지막에 지원자의 점수를 출력합니다. 이처럼 단순히 점수로 판단하면 과정은 외면됩니다. 예를 들어 50점 이상을 합격시킨다고 합시다. 75점과 35점 받은 두 사람이 있습니다. 점수가 두 사람의 실제 실력을 대변할 수 있을까요?

블리자드에서는 조금 아날로그 스타일로, 코드에 집중해 옛날 방식으로 코딩 테스트를 진행했습니다. ‘텍스트로 게임을 만들어라’, ‘코드 500 줄짜리 간단한 게임을 만들라’ 같은 과제를 주었습니다. 힌트도 많이 주고 기간도 일주일 정도로 주니, 지원자 대부분이 과제를 제출합니다. 그러면 면접관은 제품은 안정적인지, 코드가 읽기 편하게 잘 짜여 있는지, 버그 없이 잘 작동하는지, 해당 프로그래밍 언어를 잘 활용했는지, 구조를 잘 짰는지, 미래에 다른 기능을 추가할 수 있는지 등을 고려하며 소스 코드를 살펴봅니다. 소스 코드 리뷰도 팀장 세 명 정도가 진행합니다. 각자 자신의 의견을 말한 뒤, 평가를 합쳐서 합격 혹은 불합격을 결정합니다. 저는 이런 방식이 일반적인 코딩 테스트보다 지원자를 훨씬 깊이 파악할 수 있다고 생각합니다. 그런데 문제는 시간이 무척 많이 든다는 겁니다. 지원자와 평가자 모두의 시간을 흡수합니다.

회사마다 철학이 있겠지만, 저는 관리자라면 업무에서 1/3을 채용에 써야 한다고 생각합니다. 좋은 사람을 뽑는 게 제일 중요하니까요. 다른 1/3은 조직 관리에 씁니다. 사람들이 일을 잘할 수 있게 돕는 거죠. 마지막 1/3을 자신의 일에 쓰면 됩니다. 관리자라면 코딩 테스트 웹사이트 대신 직접 코드를 확인하는 아날로그 방식으로 자신에게 맡겨진 채용 의무를 져야 한다고 생각합니다. 이런 상황을 반대로 해석해볼까요? 코딩 테스트로 유명한 A 사이트가 있습니다. 여러분이 지원자이고, 입사하고 싶은 회사가 A 사이트를 사용한다고 합시다. 그러면 당연히 A 사이트에서 열심히 코딩 테스트를 준비해, 특유의 달달 외우는 능력을 발휘해 테스트를 통과하고 말게 아닙니까? 테스트를 통과하는 것과 현업을 잘하는 것은 별개입니다(그렇다고 지원자께 ‘코딩 테스트 준비를 하지 마세요’라고 말하는 건 아닙니다).

데이 제로^{day zero} 인터뷰라고도 부릅니다. 인 퍼슨 테스트^{in-person test}는 블리자드에서 진행한 굉장히 독특한 문화입니다. 입사를 했다고 가정하고 지원자 3명을 불러서 게임을 만들게 하는 겁니다. 그리고 게임을 개발하는 과정을 지켜봅니다. 3명이서 어떻게 진행하는지, 싸우는지, 협업은 하는지 보는 겁니다. 지원자들이 실제로 사무실에 앉아서 코딩을 하고 있으면, 미러링된 화면이 벽에 붙어 있는 큰 TV에 보입니다. 그리고 팀장 다섯 명이 앉아서 지켜봅니다. 프로그래밍을 얼마나 잘하는지, 얼마나 빠르게 프로젝트를 익히는지, 협업 능력이 있는지, 리더/팔로어 성향이 있는지, 아키텍처를 누가 제시하는지 등을 확인할 수 있습니다. 살 떨리죠. 그래서 개발 팀장들끼리 “야, 이거 우리가 했으면 입사 못했을 거야”라고 이야기하곤 했습니다. 너무 힘드니까요.

메일 인 테스트가 지원자의 최고 실력을 보는 테스트라면, 이 테스트는 최악의 상황에서 어떻게 행동하는지를 보는 테스트라고 할 수 있습니다. 아직 아무것도 모르는 상태에서 이상한 게임을 만들라고 했을 때를 시뮬레이션한 겁니다. 예를 들어 두 명이 계속 싸울 때 한 명은 나머지 사람을 설득하거나, 계속 코딩만 할 수도 있죠.

실무 회의를 진행해 테스트 과제에 대해 최대한 많은 것을 미리 정해둡니다. 테스트 예제를 하나 보여드리겠습니다.

보통은 지원자 3명을 모아 테스트를 하는데, 지원자가 부족할 때는 직원 중 한 명이나 두 명을 넣어서 진행합니다. 직원도 테스트에 참여하면, 지원자처럼 행동합니다. 하루 정도 휴가라고 생각하고 되게 재밌게 열심히 하더라고요. 돌아가면서 시키는데 의외로 참여하는 걸 좋아했습니다. 맨날 일만 하다가 지원자들과 재밌게 게임을 만들면 되니까요. 테스트는 하루 종일 진행됩니다. 아침에 해야 할 일을 설명하고 점심을 제공하고, 저녁까지 게임을 만들어서 데모를 합니다. 매우 힘듭니다. 그래도 생각보다 많은 팀이 게임을 완성하고, 데모도 했습니다. 저는 이 테스트에서 아주 뛰어난 성과를 보인 사람들이 10년 정도 후에 회사에서 아주 큰 일을 해내는 걸 두 눈으로 봤습니다.

이런 테스트는 지원자뿐만 아니라 면접관에게도 굉장히 힘듭니다. 하지만 이 관문을 거쳐 채용된 지원자들은 역시나 현업에 잘 적응합니다. 그래서 포기할 수 없을 정도로 달달한 꿀입니다만, 결국에는 너무 힘들어서 온라인 코딩 테스트로 전환하고 면접으로 채용하게 됐습니다.

이런 테스트에서 면접관은 지원자가 성공할 수 있게 도와야지 실패하도록 방치하거나 유도해서는 안 됩니다. 중간에 장벽을 마주하면 면접관들이 힌트를 주거나 돕는 거죠. 또한 지원자가 압박감을 느끼지 않도록 조심해야 합니다. 압박 면접을 하는 회사는 입사해서도 압박합니다. 실제로 테슬라에서 일하는 제 친구는 또 다른 개발자 꿈의 직장에 동시에 합격했습니다. 테슬라를 선택한 이유를 물어봤더니 다른 회사는 면접 때 너무 압박했다는 겁니다. 면접관 한두 명이 회사 전체를 대변하지는 못합니다만 압박 면접으로 인재를 놓치는 일이 발생하면 안 됩니다.

다소 생소한 검증 과정을 언급하기도 했습니다. 여러분이 우리나라 기업뿐만 아니라 해외 기업에 취업을 하고 싶다면, 다양한 테스트 방식을 알아두는 게 좋습니다.

‘사람들을 유혹하라attract, 사람들을 계발해라develop, 사람들을 연결시켜라engage.’ 블리자드 채용팀의 철학입니다. 블리자드가 매력적이어야 좋은 사람을 얻는다는 이야깁니다. 회사를 좋게 포장하라는 게 아니라, 매력적인 각종 제도와 철학으로 회사를 무장한다는 말입니다. 회사는 좋은 사람을 유혹할 수 있어야 하고, 좋은 사람을 데려와서 능력을 계발시킬 수 있어야 하고, 마지막으로 실제 일할 팀과 딱 들어맞게 합쳐져서 일할 수 있게 해야 합니다. 블리자드는 이런 철학에 딱 들어맞는 사례라고 생각합니다.

예를 들어 블리자드는 입사 즉시 일을 시키지는 않습니다. 회사마다 일하는 방식이 다르고, 이전에 썼던 기술과 다를 수 있기 때문에 온보딩^{on- boarding} 제도를 운용합니다. 회사에 적응할 수 있게 정보를 주고, 회사에 맞게 자신을 계발할 수 있게 돕는 제도입니다. 한두 달을 보내고 나서야 원하는 현업에 투입됩니다. 신규 입사자가 온보딩 기간을 허송세월로 보내지 않으려면 ‘회사 홍보 → 채용 → 온보딩’까지 쭉 연결된 프로세스를 세워야 합니다. 회사가 알려져야 채용도 잘 됩니다(스타트업 관계자는 공감할 겁니다). 그리고 온보딩까지 인사 시스템에 녹여넣어야 합니다.

우리 회사가 매력적인지, 회사가 직원들의 능력을 계발하는지, 인력이 필요한 팀에서 사람을 받아들일 수 있는지를 검토해봅시다. 지원자 입장에서도 비슷하게 생각해볼 수 있습니다. 자신이 매력적인 지원자인지, 입사해서 성장하는 모습을 보여줄 수 있는지, 회사의 프로젝트에 정말 관심이 있고 열심히 할 수 있는지 검토해야 합니다.

우리나라에서는 OJT^{On-the-Job Training}라는 이름으로 신규 직원을 맞이합니다. 명칭이야 어찌 되었든 입사를 하면 회사와 팀에 대해 설명하고, 가능 하면 여러 역할을 체험할 수 있게 해야 합니다. 예를 들어 클라이언트 개발, 서버 개발, 도구 개발을 일주일씩 경험하게 하는 거죠. 입사 후 3개월 이 지나면 회사를 다 알게 되고 익숙해집니다. 초기 3개월은 빠르게 성장하는 기간입니다. 많은 사람을 만나고, 많은 이야기를 하고, 많은 일을 해 봐야, 회사를 많이 알고 언젠가 큰 그림도 그릴 수 있습니다. 여러 팀과 점심을 먹고, 각 팀의 리더들과 미팅하면 직원의 시야가 넓어집니다.

만약 여러분이 스타트업에 입사했는데, 이런 온보딩 프로그램이 없다면 너무 실망하지 마시고, 여러분이 다음 사람을 위해 만들면 됩니다.