개발자 채용, 어떻게 할 것인가?
개발자 채용에 관한 생각
예전에 개발자 취업에 관한 글을 몇개 작성했습니다. (참고1, 참고2, 참고3) 주로 신입 개발자로 취업할 때 어떤 것들을 염두에 두고 준비하면 좋을 지에 관한 글이었는데요, 이번에는 취업하는 개발자 입장이 아닌, 채용하는 입장에서 개발자 채용을 어떻게 하면 좋을지에 관해 글을 써보려고 합니다. 채용하는 회사 입장에서 쓰는 글이긴 하지만 취업자 입장에서도 도움이 듯 합니다.
인터넷에 보면 Interview question을 모아놓거나 취업 팁에 관해서 알려주는 경우는 많지만, 어떻게 채용하는지에 관한 정보는 잘 없는 것 같습니다. 개발자 채용은 정말 중요한데요 (특히 사람이 모든걸 하는 IT업종에서는) 이에 관한 체계적인 교육이나 정보는 좀 부족한 편인 것 같습니다. 또한 잘나가는 큰 규모의 기업에서도 채용에 관한 교육이나 체계적인 가이드라인 등이 좀 부족한 편이고, 특히나 이런 현상은 스타트업 일수록 더 심한 편입니다. 특히 채용과 관련된 시장은 굉장히 큰 규모인데, 대부분은 소싱 (헤드헌팅, 취업 희망자 - 회사 연결 플랫폼 등) 에 집중을 하며, 코딩 테스트 등을 도와주는 플랫폼만 있는 정도 수준입니다. 그 이유는 회사에서 원하는 인재상을 제대로 외부 회사가 평가하기가 쉽지 않기 때문이죠.
물론 이 글은 지극히 개인적인 제 경험을 기반으로 하기 있기 때문에 이게 정답이라는 의미는 아닙니다. 채용에 정답은 없죠. 하지만 채용은 IT기업에게 매우x100 중요하기 때문에, 어떻게 보면 가장 중요한 것 중 하나이기 때문에 조금이라도 더 잘 하기 위한 노력이 많이 필요합니다. 저도 아직 부족한 점이 많고 항상 배우고 있습니다. 다만 지금까지 이런 과정을 통해 채용했을 때 실패했다고 생각되는 경우는 없었기 때문에 공유하고자 합니다. 또한 구글이 인수한 Firebase 공동창업자가 몇 년 전에 작성한 개발자 채용에 관한 글 (link) 을 봤을 때 제가 생각하는 좋은 채용방식과 굉장히 유사하다고 생각했기 때문에, 제가 사용하는 채용 방식이 그래도 꽤 좋은 방식이라고 생각하고 있습니다. (Firebase의 co-founder가 쓴 글은 내용이 좋아서 한번 읽어보는걸 추천드립니다.)
어떠한 개발자를 채용할까?
개발자 채용을 하기전에 어떠한 개발자를 원하는지 부터가 중요합니다. 업종, 회사 규모, 사업 분야 등에 따라서 많이 달라지기 때문입니다. 따라서 Job Description 부터 명확히 작성할 필요가 있습니다. 다만, 이 글에서는 기술 별로 어떤 개발자가 적합한지 보다는 대기업/스타트업에 어떠한 개발자를 뽑는것이 더 유리할지만 조금 살펴보도록 하겠습니다.
Early stage startup
보통 seed ~ series A 수준의 스타트업의 경우 항상 자금이 부족하고 수익을 내기 힘든 경우가 많기 때문에 좋은 사람을 뽑기도 쉽지 않고, 체계를 갖추기도 굉장히 힘듭니다. 해야 되는 일도 미친듯이 많을 것이구요. 경험 상 뛰어난 개발자가 가장 선호하는 조건은 돈/복지 보다도 성장 가능성인데, 이러한 극초기 단계 스타트업들은 성장 가능성을 맞추어 주기도 힘듭니다. 왜냐면, 개발을 할 때 테스트 코드나, 인프라를 잘 갖추어서 개발하는 것 등이 개발자의 성장을 하는 주요한 요소인데 이 시기에는 속도가 No 1. priority 가 되기 때문이죠. 또한 빈번하게 사업 아이템이 피벗 될 수도 있구요. 실력 좋은 개발자들은 일반적으로 코드 퀄리티를 중요시하고 체계가 잡힌 개발을 선호하는데, 이런 잘 하는 개발자들을 어렵게 채용하더라도 불만을 가질 가능성이 큽니다.
따라서, 이런 불만이 발생할 수 있는 부분을 잘 관리하거나, 한가지를 깊게 파는 개발자보다는 빠르게 뭔가를 프로토타이핑하고 카오스적인 개발환경에서도 즐겁게 개발하는 것을 즐기는 개발자 위주로 채용을 하는 등 상황에 맞는 유연한 채용 전략을 가져갈 필요가 있습니다. 따라서 실력이 완성된 개발자보다는 경력이 비교적 짧더라도 이런 상황을 즐길 수 있는 개발자 위주로 알아보는 것이 비교적 좋습니다.
사업이 안착한 스타트업이나 중규모 기업
이 경우에는 Series B이상을 넘어선 기업들이라고 볼 수 있고 어느정도 주력 사업이 갖추어진 상태이기 때문에 개발자를 채용하기 좋은 상태라고 볼 수 있습니다. 성장을 하는 중이기 때문에 개발자들에게 스톡옵션의 매력을 어필할 수 있으며, 성장욕구가 강한 개발자들을 채용하기가 비교적 수월합니다. 물론, 이 단계에서도 항상 일은 많고 개발과 관련된 체계를 잡기 힘들 수도 있습니다만, 이 정도 되면 고객이나 사용자도 어느 정도 확보한 단계이기 때문에 개발 체계를 잡는게 중요하며, 따라서 실력 좋은 개발자를 채용하는 데 문제가 없고, 그런 개발자들을 채용하는 것이 가장 좋습니다.
대기업을 향해 가는 기업이나 대기업
유니콘 이상이며 상장을 해서 많은 수익을 내는 수준의 기업들은 이미 잘하고 있기 때문에 제가 딱히 할말은 없을 거 같네요. 이미 잘 하고 있으니까요. 다만, 경험상 국내 최고라고 하는 대기업들도 개발자 채용을 약간 주먹구구식으로 하는 경향이 있기는 합니다. 면접자에게 어떻게 개발자 면접을 잘 할 수 있을지에 관한 교육이나, 면접관으로서의 매너, 어떠한 기술적인 포인트를 중요하게 검증할 것인지, 지원자의 진짜 실력을 파악하기 위한 팁 등에 관한 교육 체계가 잘 안잡혀 있는 경우가 많기 때문에 이런 부분은 아직 개선이 되어야 할 부분인 것 같습니다.
어떤 개발자를 채용할지에 대한 고민이 끝나면, 본격적으로 채용을 진행해야 합니다. 개발자를 채용하는 과정은 크게 아래와 같은 과정으로 나눌 수 있을 것 같습니다.
소싱
서류검토
코딩 테스트
면접
오퍼 및 처우협의
온보딩
이 과정들에 대해서 간단하게 알아보겠습니다.
소싱
개발자를 소싱하기 위한 루트는 다양하게 많습니다. 일반적으로 공식 채용 페이지, 헤드헌터, 채용 플랫폼 (원티드, 리멤버, 로켓펀치, 프로그래머스 등), 링크드인 및 SNS, 채용 지원 프로그램 (예를 들어 정부의 인턴 지원 프로그램 같은) 등 다양하게 많습니다.
급격히 성장중인 잘 나가는 회사라던가 대기업은 소싱에 별로 어려움을 겪지 않습니다. 물론 국내 최고의 IT 기업들도 항상 지원자가 없다고 난리이긴 합니다만, 그래도 수 많은 뛰어난 사람들의 지원서를 매일 몇백 통 이상 받는 기업들과 작은 기업들을 비교하기는 힘들겠죠. 작은 규모의 기업들은 면접은 둘째치고 소싱부터가 난관입니다. 이런 규모 회사들에 들어가고 싶어하는 지원자 자체가 적기 때문이며, 많은 경우 비용이 높은 헤드헌팅 펌에 의뢰하는 것 조차도 굉장히 부담입니다.
이렇게 소싱 자체에서 부터 어려움을 겪는 회사들은 직접 개발자들에게 메세지를 보내는 수 밖에 없습니다. 개발 관련 블로그를 운영하는 사람이나 기술 블로그를 쓰는 사람들 중 괜찮아 보이면 메일을 보내거나, 링크드인이나 원티드 같은 플랫폼에서 개발자를 찾아서 메세지를 보내는 등 가능한 모든 방법을 동원에서 소싱하는 수 밖에 없습니다. 이 부분은 답이 있는 부분이 아닌 것 같습니다. 그저 개발자들에게 우리 회사가 매력이 얼마나 많은지를 어필을 잘 해야 합니다.
이력서 검토
이력서는 구지 포맷이 필요 없습니다. 자유 형식의 이력서를 받으면 되고, 필요하다면 추가 정보를 요청하면 됩니다. 이력서를 많이 보다 보니 이제 웬만하면 이 지원자가 우리가 원하던 사람인지 아닌지 대략적으로 느낌이 오고, 일반적으로는 그 느낌이 맞는 것 같습니다.
학벌이 좋으면 눈길이 좀 더 가기는 하지만, 학벌이 그렇게 중요한 요소는 아닌 것 같습니다. 중요한 부분은 해당 지원자의 경력이나 어떠한 일을 했는가 입니다. 어떠한 일을 주로 했고, 어떠한 문제를 해결했고 기술적으로 어떤 전문성이 있는지를 중점적으로 살펴보면 됩니다.
서류 검토 시 괜찮다고 판단되면 phone interview 를 하는 경우도 많습니다. (특히 실리콘 밸리) 근데 30분 내외의 phone interview 자체로 많이 판단하는 것은 쉽지 않은 편이고 이런 시간도 사실 실무자의 입장에서는 많은 리소스가 들어가는 일이기 때문에 이것은 상황에 맞게 판단하는 게 좋습니다. 물론 phone interview 과정이 있는 것이 더 좋기는 합니다. 이 때는 너무 technical 한 질문 말고 (어차피 전화로 그런걸 이야기 하기 쉽지않기 때문에) 기술적인 흥미나 지원자와의 커뮤니케이션, interview process 설명, 회사에서 관한 Q&A를 하는 것이 좋습니다.
이력서의 느낌이 좋다면 티타임 등을 가지는 것도 좋은 방법입니다. 기술적인 부분을 물어본다기 보다는, 개발 문화를 소개한다거나 회사에 대해서 어필할 만한 점들을 어필하고 Q&A를 하는 것도 좋습니다. 수요와 공급 법칙에 따라서 개발자 구인 시장에서는 회사가 갑이 아닌 경우가 많습니다. 실력 있는 개발자들은 언제든 회사를 떠날 수 있고 항상 좋은 오퍼를 많이 받기 때문에 공들일 필요가 있습니다.
코딩 테스트
채용에서 중요한 과정 중 하나를 꼽으라면 코딩 테스트일 것입니다. 저는 개인적으로 codility 같은 플랫폼에서 나오는 문제를 선호하지는 않습니다. 왜냐면 그런 코딩 테스트 문제만 열심히 준비하는 케이스가 꽤 있기 때문입니다. 마치 시험문제를 달달 외우는 것 처럼요. 따라서 기본적인 알고리즘이나 자료구조 실력을 평가하는 정해진 문제만 내는 것은 별로인 것 같습니다. 물론 customization이 가능한 코딩 테스트 플랫폼들도 있어서 그런 걸 활용하는 것은 좋을 것 같네요.
그리고 whiteboard coding도 별로 선호하지는 않는데요, 실제 개발하는 환경과 많이 다르기 때문입니다. 이런 것은 실리콘 밸리 기업들이 많이 사용하는 방식이기도 하고 논쟁의 여지가 항상 많기는 합니다만, 그런 기업들도 효과적이라기보다는 효율적이기 때문에 아직도 많이 사용하는 것 같습니다.
코딩 테스트는 위에 추천한 firebase co-founder의 글을 참고할 만 합니다. 저도 비슷한 방법을 많이 사용했었습니다.
집에서 자신이 선호하는 개발환경에서 코딩 테스트를 진행할 수 있도록 합니다.
프로그래밍 언어는 어떤 것이든 선호하는 걸 사용해서 풀 수 있도록 합니다.
이 때 문제는 기본적인 솔루션은 쉽게 찾을 수 있지만, 최적 솔루션을 찾기는 굉장히 어려운 (다양한 최적화 방식을 사용할 수 있는) 문제로 만드는 게 좋습니다.
팀원들이 풀어보고 어느정도 시간이 걸리는지, 난이도는 어떤지를 미리 확인을 해야 합니다.
문제는 실제 회사에서 하는 업무와 관련된 것이 좋습니다. 회사에서 일을 하며 맞닥뜨린 문제들을 코딩 테스트 문제로 구현하는 것이 좋을 것입니다.
코딩 테스트 진행한 것에 관한 코드 설명등도 간단히 작성을 요구해서 어떤 생각으로 이렇게 코딩했는지 물어보는 것도 좋습니다.
문제를 풀며 재미를 느낄 수 있다면 더 좋을 것입니다.
어떠한 기업들을 보면 2~3일 짜리 코딩 테스트 문제를 내는 경우도 있는데 이건 좀 과한 것 같기도 합니다. 그정도로 지원자의 시간을 뺏으려면 소정의 비용을 지급하는게 맞을 것 같습니다.
코딩 테스트 결과에 대해서는 간단한 코드 리뷰 정도는 해 주는 게 좋습니다. 지원자의 시간을 많이 뺏은 건데, 그정도 배려는 필요하다고 생각됩니다.
면접
코딩 테스트를 통과했다고 판단이 되면, 채용에서 가장 중요한 요소인 면접을 진행하게 됩니다. 면접 진행의 경우 1~2명이 한 팀이 되어 30분 ~ 1시간 정도 진행하는 것이 좋고, 최소 3세션 정도는 하는 것이 좋습니다. 지원자도 면접자도 힘들기는 하겠지만 경험 상 이정도 검증은 필요한 것 같습니다. 세션별 면접관마다 질문을 구지 나눌 필요는 없습니다. 답변의 일관성을 볼 수 있도록 같은 질문을 물어보는 것도 괜찮습니다.
지원자 (면접자) 도 면접관에 대해서 다양한 느낌을 받기 때문에, 면접관도 평가를 할 수 있을 만한 기술적인 실력이 있는 사람이 면접을 진행 할 필요가 있습니다. 그래야 원활이 진행될 수 있고 제대로 된 기술적 깊이를 평가할 수 있습니다. 회사에 따라서 주니어 레벨이 면접관으로 들어가는 경우도 있는데, 이건 기술적 평가를 제대로 하지 못할 가능성이 크기 때문에 면접 볼 사람이 없다고 그냥 대충 진행하는 것은 절대 지양해야 할 필요가 있습니다. 물론, 주니어 레벨을 막 벗어나기 시작한 엔지니어의 경우 면접관 경험 등을 쌓기 위해서 2인 1조 정도로 들어가는 것은 좋다고 생각합니다.
면접 시에 이전 회사 등에서 수행한 프로젝트에 관한 내용은 당연히 물어볼 것이고, 그와 관련된 기술적인 내용을 깊게 물어보는 것이 좋습니다. 또한 코딩 테스트 진행한 것과 관련하여, 어떤 생각으로 이렇게 코드를 작성했는지 등에 관한 질문을 하는 것도 좋습니다.
추가로 면접 시에는 아래와 같은 것들을 물어보는 것도 좋습니다.
개발과 관련된 기본 지식 (기초적인 알고리즘이나 자료구조 등, 그리고 해당 분야에서 중요한 기본 지식 등)
이러한 서비스를 만드려고 한다. 어떤 구조로 어떻게 개발하는 것이 좋겠는가? 이러한 질문은 정답은 없지만 전체적인 지식과 경험을 살펴보기에 좋습니다.
서비스하다가 이러한 문제가 생겼다. 이걸 어떻게 해결하겠는가?
이러한 운영 상 이슈가 발생했다. 이걸 어떻게 해결하고 재발을 방지하겠는가?
요즘 관심을 가지고 있는 기술이 무엇인지? 그에 관해 토론
평소에 얼마나 개발에 관심이 많고 어떤 목표를 가지고 있는지
특정 기술을 주로 사용했다면 해당 기술의 내부적인 구조 등에 관하여 토론
주로 해보고 싶은 분야, 하고 싶은 기술, 어떤 능력을 더 키우고 싶은지
질문을 하기만 하는 게 아니라 회사, 기술, 개발 문화 등에 대해 질문이 있다면 질문을 받도록 합니다. 면접자도 면접관을 평가하기 때문에, 갑이라는 생각은 절대로 가져서는 안되며, 면접 과정이 전체적으로 매끄럽게 진행되도록 해야 하며 매너는 반드시 지켜야 하고, 개인적인 질문은 웬만하면 지양해야 합니다.
면접에 관하여는 아래와 같은 것들을 평가하면 됩니다. 정량화 할 수 있다면 더 좋습니다.
전문성과 업무역량 : 가장 기본이 되는 요소로 업무를 잘 수행할 수 있을지에 관한 것들을 평가합니다. 면접 시 다양한 기술적 질문에 대해서 이론적/경험적인 답변을 하는 것과 문제에 대한 해결방법을 물어보는 질문에 대한 답변에서 어느 정도의 역량을 보일 지 유추가 가능합니다.
커뮤니케이션 : 프로젝트 진행 및 개발 경험, 다양한 문제 해결 방법 등에 관해 이야기 하며 말이 잘 통하는지를 보는 것이 좋습니다. 이게 말을 잘하는지 보는게 아니라 개발자들끼리 기술적 문제 등을 토론하고 논의를 잘 할 수 있을지를 보는 것입니다. 질문에 대해서 잘 이해를 못하거나 엉뚱한 답변을 계속 한다거나 하면 커뮤니케이션이 잘 안된다고 보는 게 맞을 것입니다. 개발자들 뿐 아니라 HR 매니저나 기획자 등 개발자와 협업이 많은 다른 직군과의 면접도 진행한다면 기본적인 말이 통하는지 정도 보는 것도 좋을 것입니다.
성실성이나 태도 : 이건 정량화 하기가 쉽지 않지만, 다양한 질문과 뉘앙스 등을 통해서 유추할 수 있습니다.
성장 의지나 열정 : 경험이나 경력이 좀 적고 아직 아는게 많이 없더라도 특정한 분야에 깊이 몰입 해 보았거나, 평소에도 개발 능력 향상 등을 위해서 노력을 많이 하고 있다면 좋은 개발자가 될 확률이 굉장이 높습니다. 특히나 성장의지가 높은 개발자일수록 좋은 개발자일 확률이 높은 것 같습니다. 일을 대하는 자세에 대해서도 물어보는 게 좋습니다. 업무 강도가 강한 것에 대해 괜찮은지를 물어보는 것도 좋은데, 이런 것은 열정페이를 강요하려는 게 아니라 커리어 성장을 위해서는 몰입과 노력이 필요하기 때문에 물어보는 것입니다.
완벽한 사람은 없고, 다 잘하는 사람은 없기 때문에 어떠한 점이 좀 부족하더라도 그 사람의 강점을 위주로 회사에 도움이 될 지를 판단하는 것이 좋습니다.
오퍼 및 처우 협의
면접 결과에 대해서 기준을 세워 정량화하여 평가 결과를 작성하는 게 좋습니다. 면접 후에 모든 면접관에게 positive 응답을 받은 경우는 오퍼를 주면 됩니다. 만일 한명이라도 negative가 있다면, 그것을 상쇄 할 만한 강한 positive 가 있어야 하며 이는 토론을 통해 결정하는 것이 좋습니다.
그리고 제가 위에서 면접관도 매너를 지키는 게 중요하다고 썼는데, 왜냐면 우리가 맘에 드는 지원자는 이미 많은 회사에서 오퍼를 받았을 확률이 높기 때문입니다. 따라서 면접관도 면접 시부터 회사의 장점 등에 대해서 어필하는 것이 좋습니다. 뛰어난 동료가 있고, 회사의 성장 가능성이 크며 굉장히 흥미롭고 성장할 수 있는 일을 하고 있다라는 점을 어필해야겠죠. 개발자 채용 전쟁이 꽤나 심하기 때문에, 처우 협의 시에는 작은 부분 등을 협의하다가 좋은 기회를 날리는 소탐대실은 경계해야 합니다.
온보딩과 follow-up
채용된 후에 입사를 하게 되면 그 사람에게 일을 믿고 맡겨야 합니다. 성장 의지나 능력을 보고 채용한 것이니 진행한 업무에 대한 퀄리티는 평가해야겠지만 마이크로 매니징은 지양하는게 좋습니다.
원활한 온보딩을 위해서는 가이드 문서를 만들어 놓는 것이 좋습니다. 업무에 필요한 계정 발급, 개발 환경 설정, 개발 문화, 그 외 개발과 관련된 다양한 문서와 설명 등을 제공하는 게 좋습니다.
그리고 채용 과정에서 좋았던 점, 입사를 하게 된 계기, 불편했던 점, 불만족스러웠던 점은 면담이나 설문 등을 받아서 지속적으로 개선하는 것이 좋습니다. 채용 과정은 완전히 정해진게 아니라 지속적 개선이 필요한 과정이기 때문입니다.
또한, 지속적인 성장이나 커리어 개발을 위해서 challenging 한 과제를 제공하거나 다양한 스터디를 운영, 지속적인 개발 리더와의 면담 등을 통해서 커리어 발전에 관심이 많고 노력하고 있다는 점을 알려주는 것이 좋습니다. 연봉/복지가 물론 중요한 요소이긴 하지만 이는 쉽게 바꾸기 힘든 요소이며, 일반적으로 좋은 개발자가 중요시 하는 것은 성장이기 때문에, 자신의 만족이 채워지지 않으면 회사를 옮길 수 있기 때문입니다.
채용 기준에 관해서
스타트업 등을 다룬 많은 글에서 채용 기준은 절대로 낮추면 안된다고 많이 말하는데요, 이건 맞는 말인 것 같습니다. 좀 오래 걸리더라도 채용 기준을 낮추게 되면 문제가 되는 케이스를 많이 봤습니다. 물론, 서비스나 제품의 난이도가 그리 높지 않거나 유지보수만으로도 충분한 경우에는 그런 기준을 고집 할 필요는 없습니다. 모든 것은 case by case 이기 때문이죠. 하지만 서비스의 난이도가 좀 높다면 시간이 오래 걸리더라도 기준을 정해놓고 그 기준에 맞는 채용을 할 필요가 있습니다. (특히나 개발자들은 같이 일하는 동료 개발자도 회사를 평가할 때 중요한 요소이기 때문에 수준이 기준에 못미치는 개발자가 팀원이 된다면, 앞으로 그런 사람들도 채워지게 될 가능성이 높습니다. 채용 기준에 관해서도 따로 글을 써 보겠습니다.)
글을 적고 보니 사실 어찌 보면 당연하고 기본적인 이야기들에 관해서 적어 놓은 것 같습니다. 하지만, 이런 기본적이라고 생각되는 요소들을 잘 모르는 경우도 많은 것 같아서 적어 보았습니다. 개발자 채용에 관해서 궁금한 점이나 의견이 있으시다면 메일을 보내 주시면 최대한 답변 드리도록 하겠습니다.
