brunch

매거진 Code States

You can make anything
by writing

C.S.Lewis

by 쿠우보이 Dec 21. 2019

첫 개발자 채용

무엇보다 제일 중요한 첫 엔지니어 채용

요즘은 어느 사업이건 IT와 결합되어 움직인다. 각 도메인 시장에서 Product Market Fit이 어느 정도 완료되고, 고객을 늘어나면서 투자와 함깨 압도적인 성장에 관심을 가지게 된다. 그 동안은 사람 손으로 하던 운영 작업들을 웹, 모바일 기술 등을 활용하여 시스템 구축 및 운영 비용 절감을 해야한다. 이때 회사는 자연스레 소프트웨어 엔지니어, 개발자 채용에 관심을 가지게 된다.


서둘러 채용 공고는 올려야하는데, 채용 공고를 어떻게 작성할지 모르니 주변에 괜찮다는 테크 기업의 채용공고를 적당히 가져와 수정한다. 수정만 해도 양반이지만, 그대로 복사 붙여 넣기 하면서 다른 회사 이름이나 채용 이메일까지 가져오시는 경우도 있다. 어떻게 채용 공고는 올렸는데 연락이 오지 않는다. 연락이 와도 지원자 분들을 어떻게 검증하고, 어떤 분들을 채용해야 할지 난감하다. 주변에 물어보기 시작한다.


어디 좋은 분 있으면 소개 좀 시켜주세요.


그러나 이 글을 적고 있는 필자도 알고, 독자분들도 알지 않는가. 누가 좋은 개발자 분 발견해서 자발적으로 소개해주지 않는다. 그런 좋은 개발자가 있으면 먼저 본인 회사에 채용을 위해 힘쓰지, 다른 회사 소개해줄 여유가 많진 않다.


결국, 좋은 개발자 채용은 기업의 대표, 혹은 Hiring Manager 담당자가 시간과 정성을 들여야 하는 부분이다. 시간과 정성, 실수, 실패를 통하지 않고 쉽고 빠르게 채용 노하우를 얻어가려 하는 것은 무임승차, 무전취식을 노리는것과도 같다. 컨설팅을 받고 누가 쉽게 도와줄 수 있는 영역이 아니다. 바닥부터 헛발질하며 땀흘려 쌓아나가야 하는 기술이다. 빨리 포기하고 내가 (혹은 팀이, 기업이) 직접 노하우를 쌓을 생각을 해야 한다.


기업의 대표가 개발자와의 협업 경험이 많거나, 대표 스스로가 개발자 출신이거나, 아니면 CTO급의 파트너 공동창업자가 있거나 하면 (잘못된 방향일지언정) 그나마 길이 보인다. 하지만 문제는, 기업 전체에 개발자 분이 없는 경우, 앞길이 막막하다고 생각하게 된다. 



개발자 분들을 만나 가장 크게 실수하는 경우는 어설프게 기술에 대한 이야기를 꺼내는 것이다. "요즘은 '리액트' 혹은 '뷰'가 핫하다고 하는데 그래서 그 기술을 사용하고 싶다. php는 별로라고 하고 노드나 고랭이 좋다고 해서 그런 최신 기술을 사용하려 한다." 등등...


지원한 개발자 입장에선 이런 논리가 부재한 기술 선택이나 트렌드 이야기를 들으면 1) 신이 나서 반박하고 다른 의견을 내거나 2) 그냥 듣고 흘리거나 둘 중 하나인데 그 두 가지 모두 별로 생산적이지 않다.


이에 개발자가 팀에 없는 기업에 권하는 것이 있다.

현재 기술적으로 세팅된 것이 없다고 솔직하게 드러내고, 해당 기반을 만들어 줄 수 있는지에 대해 물어볼 것. 개발팀이 없는데 개발 기반이나 세팅된 것들이 있다고 말하는 게 이상함

어설픈 기술 스택 및 프레임워크에 대한 이야기가 아니라 회사가 잘하고 있는 것들을 충분히 자랑할 것

기술이 없어도 현재 이미 손으로, 여러 도구로 시장에서 역할을 하고 있음을 증명해 낼 것. 여기에 기술이 접합되었을 때 얼마나 큰 영향을 미칠지에 지원자 분의 가슴을 울릴만한 스토리를 이야기할 것

개발팀이 없으니 개발 문화도 없지만, 우리가 자랑할 만한 조직문화가 있다면 충분히 자랑할 것. 개발 문화는 기업의 조직문화 안에서 파생되기 때문

첫 개발자 분은 정말로 많은 검토를 통해 신중히 채용할 것. 첫 개발자 채용을 잘 못 하면 그 첫 개발자 때문에 앞으로 수많은 개발자분들이 이 회사를 오지 않을 수 있음


일반적으로 개발자 분들은 좋은 개발자가 있는 곳으로 가길 원한다. 좋은 분들과 같이 팀을 형성할 때의 기쁨과 성장을 알기 때문이다. 그렇다면, 개발자가 한 명도 없는 곳에선 채용이 불가능한 것인가? 어렵지만, 종종 바닥부터 세팅하고 만들어내고자 하는 분들도 있다. 시니어 개발자분들만 그런 것은 또 아니다. 주니어 중에서도 충분히 빠르게 성장하고 책 읽고, 주변에 물어물어 좋은 환경을 구축해내는 경우도 있다. '신입이나 주니어 개발자는 못 할거야' 라고 섣불리 단정지을 필요는 없다. 반대로 경력자라고 해서 언제나 이 바닥부터 세팅을 해 낼 수 있는 것도 아니기 때문이다.


그런데 "개발자" 채용 이전에, 그냥 우리 회사에서 함께 일할 "동료"를 구하는 것이 먼저다. 따라서 당연한 이야기지만, 기술과 역량을 이야기하기 전에 우리 회사의 방향에 동의할 수 있고 회사의 비전, 미션을 들었을 때 흥분하는 분을 찾아야 한다. 기술은 그다음이지 않나?

 

대기업 같은 큰 조직이면 시스템이 잘 되어 있어서 해당 기술만 갖추면 잘 적응할 수도 있다. 하지만 스타트업이나 작은 조직들은 수차례 직무의 범위가 다이내믹하게 변경되기 때문에 기술과 직무역량으로만 사람을 구할 수 없다.


다시 강조하자면, 이 회사가 하고자 하는 일에 흥분하는 개발자여야만 한다. 여기서 회사가 하고자 하는 일은 미션 이라고도 불리우는데, 이 미션이 실제 회사가 하고 있는 일과 다르기 때문에 다르게 적었다. 회사의 서비스나 제품을 너무 좋아해야 한다. 동시에 이 일을 하는 동료들과 뭔가 느낌이 맞아야 한다. 


첫 면접 때부터 개발자 없는 회사라고 기술적으로 무시하거나 가르치려 드는 지원자도 상당히 많다. 이건 시니어나 주니어나 마찬가지다. 내가 알고 있는 것을 상대방이 모를 때 나타나는 가장 나쁜 거만함 중에 하나다. 또 다른 좋지 않은 지원자는, 비개발자분들이 이해할 수 없는 기술적 용어를 남용하며 은근히 상대방을 무시하는 것이다. 필자가 개발자를 양성할 때 가장 크게 강조하는 말이 있다. (물론 내가 한 말은 아니고, 나를 가르쳐 주셨던 팀장님의 말이다)


하수는 쉬운 내용을 어렵게 설명하고, 고수는 어려운 내용을 쉽게 이야기한다
고수는 쉬운 그림을 그릴 줄 아는 사람이다


일반적으로 좋은 개발자일수록, 개발 기술을 모르는 사람에게 어려운 내용을 일목요연하고 이해하기 쉽게 설명해 준다. 그것에 어려움을 느끼거나 귀찮아 않는다. 따라서 우리가 모르는 영역에 있어 평가하기를 포기하면 안 된다.


필자 역시 팀에서 데이터 전문가를 채용해야 하는 상황이다. 필자는 데이터 관련 백그라운드가 있거나 공부해 본 적이 없다. 이제 막 조금 공부를 시작했을 뿐이다. 그럼에도 불구하고 데이터 관련 전문가를 채용함에 있어 큰 두려움은 없다. 왜냐하면, 지원 과정 속에서, 또 면접 과정에서 일련의 질문과 응답 속에서 어느 정도 예측하고 추정할 수 있는, 또한 검증할 수 있는 것들이 많기 때문이다. (물론 기술적인 측면에서 주변의 데이터 전문가에게 끊임없이 조언을 구할 생각이고 지금도 그러고 있다. 기술적 조언을 구하는 것에 게을리 하자는 것이 이 글의 취지는 아니다.)


개발자를 채용해야 하는 담당자로서, 개발자 구인이 어렵다는 이야기를 습관처럼 할 때 주의하자. 개발자 이전에 팀원을 구하는 것일진대, 자칫하면 '나 사람 볼 줄 몰라요'라고 스스로의 부끄러움을 광고하는 것이 될 수 있다. 채용의 기술은 100% 자신의 시간과 노력과 정성을 들여 사람을 연구하는 눈을 키워내야 하는 인사 담당자의 필수 역량이다. 기술적 검증은 일반 채용 프로레스 위에 추가되는 검증이어야만 한다. 일반 채용과 완전히 다르지 않다는 것이다. 물론 기술적 검증에 대해선 필자도 계속 연구하고 실험하는 중이라 정답은 없는 것 같다. 이후 글에서 한 번 이야기해 볼 순 있을 것 같다.



혁신적인 프로그래밍 부트캠프 코드스테이츠에서 개발자를 양성하고 또, 파트너 기업사에 건강한 개발자 채용을 추천해 드리고 있습니다. 코드스테이츠 기업 파트너쉽에 관심있는 분들은 링크를 클릭해 주시기 바랍니다.

https://codestates.com



브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari