[CHAPTER 9] 인재 채용, Part2 완전한 전환 시작

인재 채용에 대한 이야기다

채용하는 입장이 아니여도 내용을 이해할 수 있다.

오히려 취준생, 주니어에게 채용에 관한 좋은 이야기를 들려준다.

 

챕터 시작부터 나오는 문구다.

새로운 인재를 채용할 때 현재의 문제를 더 키우지 않아야 한다는 것을 우선으로 고려해야 한다....

기준에 미달되는 개발자를 채용하는 것도 어리석은 일이다...

회사들이 최고의 인재를 원한다고 표방하지만 최고의 인재가 실제로 어떤 의미인지는 잘 모르는 경우가 허다하다...

 

전형적인 채용 공고

회사에서 인재를 구하면 채용 공고는 빠질 수가 없다.

금융 IT 업계에서는 아래와 같은 공고를 쉽게 볼 수 있다.

- 자바프로그래밍 경력(5년 이상)
- 스프링 프레임워크 경험
- 금융권 IT 업무 경험(2년 이상)
- 전산 전공(석박사 우대)
...
- 우대 경력 : C#, C++, MQ 메시징, 애자일 방법론, 분산/복제 캐시, Sybase, DB2

흔하게 볼 수 있는 형태의 채용공고다. 너무 많아서 전형적이다.

 

앞이 채용 공고 직무 요건들은 잠재적으로 실력있는 개발자 다수를 제외 시킨다.

 

채용공고가 능력있는 개발자를 제외시킨다고 한다. 왜 그럴까?

 

이 채용 공고의 요구 조건 목록은 엉뚱한 것에 집중하고 있고 회사의 가치와 후보자에게 기대되는 태도에 대해서는 아무것도 말하지 않는다...
회사에서 내보내고 싶은 사람과 같은 부류의 사람을 또 채용하게 될 수도 있다.

 

저자는 이 책을 보는 채용 담당자에게 충고의 말을 전한다.

 

당신이 가진 불만들은 그 개발자들의 문제가 아니다...
그들은 채용 과정을 거쳤다...

 

채용 방법에 문제가 있다고 한다.

 

인사부서나 회사 밖에 HR 에이전시에 채용을 맡기고 내버려 둔다는 것은 개발팀의 문화와 정체성에 별 관심없는 사람의 손에 개발팀의 새로운 구성원에 대한 선별권을 넘긴다는 의미다.

 

어느 정도 규모가 있는 회사라면 대부분 인사팀을 통해 인재를 채용하게 된다.

누구나 회사에 지원을 하면 인사팀을 거치게 될텐데, 이 인사팀에 대해 문제가 있다고 한다.

 

 

인터뷰할 시간이 없다는 변명

면접관들이 가장 많이 하는 실수는 너무 바빠서 인터뷰를 할 시간이 없다는 것이다...
우리는 가족, 연인보다 회사 동료들과 훨씬 많은 시간을 보낸다...
면접에 투자할 시간이 없다는 것은 훌륭한 팀을 구성하는 것을 소홀히 한다는 것과 같다...

 

정시에 퇴근한다해도 우리의 생활 중 반 이상은 회사 동료들과 함께 한다.

바쁜 곳이라 야근을 한다면 항상 동료들과 붙어있다고 생각해야한다.

이런 중요한 사람을 대충 뽑을 수 있을까? 면접관의 중요한 책임을 언급해 준다.

 

면접관의 자질이 중요하다. 지원자들은 항상 주관적으로 평가될 수 밖에 없다.

 

운칠기삼이란 말이 있다. 운이 7 재능이 3 이라는 말이다. 많은 개발자들이 면접은 운이라고 한다.

면접관의 주관적 평가 때문에 나온 말이 아닐까 싶다.

 

면접 시간도 문제지만 전체 채용 절차에 소용되는 시간도 문제다...

4,5명을 뽑기위해 100명을 면접하는 것은 현실적으로 무리다. 외부의 HR 에이전시에 채용을 맡기는 것은 더 위험한 노릇이다.
유일한 대안은 선별하는 기준을 더욱 상세화하는 것이다.

 

채용하는 과정은 길다.

서류 -> 코딩테스트(혹은 과제) -> 면접 -> 면접2 -> 최종

같은 채용과정이라고 하면 단계마다 일주일씩 걸리는 경우가 많다.

한명에게 보통 한달이란 시간을 소비하는 거다.

수백명 이상이 지원을 한다면 서류와 코딩테스트에서 분류하는 시간도 만만치가 않다.

 

틀에 박힌 직무 요건

채용 공고에 직무 요건 목록을 기술하는 방식은 피해야 할 관례다.

애들러는 기술과 경험을 나열하는 전통적인 직무 요건이 "재능에 반하고, 다양성에도, 반하며, 성공적인 채용과의 상관관계도 최악이다" 라고 말한다.
다음은 왜 그런지 몇가지 이유다.

- 절대적인 숫자 : 숫자는 임의적이고 오해하기 쉬우며 변덕스럽다. 5년간의 자바 경력 또는 얼마 이상의 대학 학점은 별 도움이 안된다. 같은 기술만으로 오랫동안 일하는 개발자들이 많다. 대학 학점 또한 의미가 없다. 필요한 기술은 자발적인 자기계발을 통해서 배울 수 있지 학점이나 자격증을 통해 얻는게 아니다.

- 키워드 매칭 : 채용 담당자는 해당 업무의 본질적인 부분을 잘 모르기 때문에 선무당에게 굿을 맡기는 결과가 된다.

- 기술 목록의 나열 : 불필요하게 너무 많은 기술 목록을 나열하면 재능있는 개발자가 지원을 포기할 수 있다. 나열된 기술이나 경험 목록이 실제 그 업무를 잘하기 위한 것과 전혀 관계 없는 경우도 있다.

- 잘못된 기업 문화 설명 : 채용 공고에 기업의 가치외 기대되는 태도, 책임을 잘못 설명하는 경우가 많다.

- 잘못된 요구 항목 : 더 훌륭한 개발자를 유인하기 위해서는 기술, 경력, 산업군, 출신학교, 학점보다 그 직무에서 무엇을 책임져야 하는지 설명하는 것이 낫다.

- 잘못된 선별 조건 : 직무 요건들은 최악의 인재를 걸러내기 위한 목적으로 설계되어 있다. 최고의 개발자들은 경험 년수에 기반한 채용 공고에 지원하지 않는다. 회사의 문화, 업무에서의 책임, 프로젝트의 종류를 더 중요하게 여긴다. 이런 직무 요건들은 최고의 개발자들을 배척하는 부작용이 된다.

이 밖에도, 이유들이 있지만 충분한 설명이 될 것이다.

 

채용공고의 잘못된 점을 나열해 주었다.

문제는 우리 주변의 채용공고가 대부분 저런 형식이라는 것이다.

 

 

추천 채용

소프트웨어 장인이라면 다른 개발자를 추천하는 것 자체가 스스로의 평판을 시험대에 올리는 행위임을 이해한다. 즉, 추천한 본인과 동등한 수준의 열정, 가치, 원칙으로 헌신하는 사람이어야 한다.

 

기업이 추천을 받는 것은 해당 추천인을 신용한다는 의미다.

 

 

커뮤니티의 활용

채용하기 위한 최선의 방법은 여러 개발자 커뮤니티와 접촉하는 것이다.
후원하는 것도 훌륭한 접근 방법이다.

다음은 후원함으로써 얻는 이득이다.
- 훌륭한 개발자들에게 노출
- 사내 개발자들이 무료로 배울 수 있는 기회
- 무료 기술 컨설팅
- 저렴한 투자 비용

가장 큰 이익은 재능있는 개발자를 발견하고 직접 다가갈 수 있다는 것이다.

 

회사가 인재를 구하기 위해 커뮤니티를 활용하라는 내용이다.

반대로보면 개발자도 커뮤니티 활동을 해야 좋은 기회를 얻을 수 있다는 의미다.

 

효과적인 선별 조건의 정의

훌륭한 개발자를 놓치지 않으려면 어떻게 해야할까? 가장 먼저 훌륭한 개발자에 대해서 명확히 정의해야 한다.
기존의 일반적인 이력서만으로는 열정 수준을 가늠할 방법이 없었다. 

다음 사항들 중 해당되는 것이 있다면 기술하도록 했다.
- Github 계정
- 블로그
- 오픈 소스 활동
- 기술 커뮤니티나 사용자 그룹 활동 내역
- 펫 프로젝트 내용
- 트위터 계정
- 좋아하는 기술서적 목록
- 참석했거나 발표했던 컨퍼런스

 

열정이 있는지 파악하기 위한 방법 중 하나다.

개인시간에 공부에 투자하는건 쉽지가 않다. 회사가 그런 지원자의 열정을 확인하는 건 더욱 쉽지가 않다. 

하지만 깃이나 블로그 같은 걸로 꾸준히 관리가 되고 있다면 평가하는데 많은 도움이 될 것이다.

 

---

후기

이번 챕터는 채용입장이 아니여도 다양한 걸 느끼게 해주었다.

채용자의 입장에서 바라봐야 할 내용이지만 반대로 채용당하는 입장에서 알아야할 내용이였기 때문이였다.

 

다음은 리뷰를 작성하는 시점의 어느 구직 사이트에 올라온 공고 중 하나이다

담당 업무
- 백엔드/프론트앤드 개발

자격 요건
- 경력 : 5~10년
- Java, Spring, Spring boot, Mybatis
- jQuery, Javascrpt
- MySQL, MariaDB
- 다양한 API를 활용한 개발 경험자

[우대사항]
- 쇼핑몰 개발 경험
- Open API 개발 경험

자격요건은 절대적인 숫자만 있고, 키워드 매칭으로 개발자를 구한다.

예제같은 공고지만 더 간단해서 무엇을 하는지 알 수가 없다.

 

심지어 이런 공고도 많이 보인다.

담당 업무
- 웹 서비스 개발 및 유지보수

자격 요건
- 학력 : 학력무관
- 경력 : 자바 5년 이상

우대 사항
- 스프링 프레임워크 개발 경력 우대
- 즉시 출근 가능자 우대

도대체 무엇을 하는지 알 수가 없는 공고다. 

심지어 이상한 우대조건이 있다

즉시 출근 가능자 우대

상황이 안 좋았던 프로젝트 경험이 떠올랐다. 짤리는 개발자들... 그리고 곧바로 들어오는 새로운 인력들

개발자를 어디서 구해오는지 궁금했었는데 답은 여기에 있었다. "즉시 출근 가능자 우대"......

 

겪었던 결말이 안 좋은 프로젝트 관리자마다 항상 개발자가 문제라면서 불만을 달고 살았다.

그런 관리자가 직접 개발자 면접을 보면 기껏해야 물어보는게 "이 업무를 해봤나요?", "스프링 사용해봤나요?", "내일부터 출근 가능한가요?"

관리자가 직접 채용하는 개발자 중엔 개발자가 아닌 사람도 있었다. 관리자가 스스로 상황을 더 악화시킬 뿐이였다.

"즉시 출근 가능자 우대" 이 요구조건은 어찌보면 그저 그런 개발자?만 유혹하는 문구가 아니였을까 생각된다.

 

저자는 마지막에 이런 문구를 남긴다.

회사 입장에서 사내의 개발자들이 마음에 들지 않는다면, 회사의 채용 방식에 의문을 품어야 한다.

이번 챕터는 많은 생각과 회상을 해주는 내용이다.