2016년 8월 30일 화요일

이우소프트에서 경력직 공채를 실시합니다.

9/7까지 이우소프트의 그룹사 차원에서 공동으로 경력직 공채를 진행중입니다

많은 지원 부탁합니다. 

이우소프트에서는 SW개발, AI개발, AI마케팅, SW제품기획, Project Management 분야에서 직원을 채용합니다.



하반기 공채 안내

  • 지원기간 : 2016년 8월 25일(목) ~ 2016년 9월 7일(수)
  • 지원구분 : 경력
  • 전형단계 : 서류 전형 > 인성 검사 > 실무/임원 면접 > 최종 면접
  • 전형일정 : 서류합격자에 한해 인성 검사 진행 (*추후 상세 면접일정은 인성 검사 합격자에 한해 개별 공지 예정)
  • 지원방법 : recruit.vatech.co.kr 에서 온라인 지원


URL : https://recruit.vatech.co.kr/index.php?mid=recruit_notice

2016년 8월 17일 수요일

이우소프트에서 개발자를 채용하는 방법

최고의 개발자들이 최고의 소프트웨어를 만든다.

그래서 뛰어난 개발자를 채용하는 것은 소프트웨어 회사에서 가장 중요한 일이다. 그럼, 뛰어난 개발자의 정의는 무엇일까?

필자는 대한민국의 여러 벤처기업, 대기업, 중소기업, 실리콘밸리의 회사들에 대한 기업 문화를 두루 경험하고 봐왔기 때문에 나름 노하우가 생겨서 이를 공유하고자 하는 것이다. 물론 독자들이 처한 환경과 완전히 배치되는 의견이 될 수도 있음을 밝혀둔다. 인재는 1년에서 3년 이상 장기적인 관점으로 투자를 해야 하는 것이기 때문에 그 정도의 여유도 없다면 공염불인 이야기다.

필자가 채용한 개발자 중에서 최고의 개발자들은 이전 회사에서 뛰어난 개발자로 인정을 받지 못하고 연봉도 낮은 경우가 많았다. 흔히 얘기하는 중위권 대학 출신이거나 개발 환경이 안 좋아서 능력을 발휘하지 못한 경우들이다. 실리콘밸리에 있는 좋은 환경의 회사에 입사를 했다면 몇 년 안에 뛰어난 개발자라는 평가를 들을 사람들도 좋지 않은 개발 환경에서는 실력 발휘도 못하고 인정도 못 받는다. 잠재력은 프리미어리그 급인데 조기축구에서 볼보이하는 격인데, 사실 축구에서 이런 일이 벌어지지는 않을 것이다. 하지만 소프트웨어 필드에서는 이런 일이 종종 벌어진다.

반대의 경우도 있다. 우리 주변에는 흔히 뛰어나 개발자라고 일컫는 사람들이 있다. 이렇게 뛰어난 개발자라고 칭송 받는 개발자들 중에는 형편 없는 개발자들이 매우 많다. 이러한 개발자들을 “헛똑똑이”라고 부른다. 똑똑하기는 한데 다 헛것이라는 의미다. 지식과 경험은 뛰어나지만 논리적인 사고, 협동심, 인내심, 겸손함 등이 부족하고 오만함과 아집으로 자신만이 옳다고 생각하고 바뀌지 않으려고 하기 때문이다. 이러한 “헛똑똑이” 개발자들은 회사에서 “영웅”으로 불리면서 동료들을 이끌고 구렁텅이로 들어가곤 한다. 이러한 문제 개발자와 진짜 뛰어난 개발자를 잘 구분할 필요가 있다.

개발자의 역량은 크게 세가지로 나뉜다.

- 시간이 흐르면 향상되는 것 : SW 지식, 기술, 경험, 도메인 지식
- 좋은 환경에서 향상되는 것 : 협동심, 커뮤니케이션 능력, 문서 작성 능력, 공유
- 노력해도 크게 바뀌지 않는 것 : 수학적이고 논리적인 사고력, Top-down 사고, 창의력, 겸손함 (인내심, 오만함, 아집)

세가지 모두 뛰어난 역량을 가진 개발자라면 정말 좋겠지만, 그런 사람을 찾기란 쉽지가 않다. 신입이나 쥬니어와 경력이 많은 시니어 개발자를 채용할 때 기준이 다르다.

신입 개발자는 “노력해도 크게 바뀌지 않는 것”을 위주로 판단한다. 특히 수학적, 논리적 사고력을 가장 높게 본다. 나머지는 좋은 환경에서 개발을 하면 자연스럽게 향상되는 것들이다.

경력 개발자는 세가지를 모두 봐야 한다. 경력에 걸맞은 지식과 경험도 본다. 여기서도  “노력해도 거의 바뀌지 않는 것”은 중요하다. 게다가 협업, 커뮤니케이션, 문서 작성 등과 관련하여 나쁜 습관이 있는지도 본다.

그럼 좀더 구체적으로 개발자를 채용하는 방법을 얘기해보자.

필자가 가장 선호하는 채용 방식은 직원 또는 지인에게 소개를 받는 것이다. 일단 직원이나 지인은 문제가 되는 사람은 소개를 하지 않고 역량도 꽤 뛰어난 사람을 소개하곤 해서 경험적으로 성공 확률이 매우 높다.

하지만 소개만으로 모든 개발자를 채용하기는 매우 어렵다. 그래서 채용공고, 홈페이지, SNS, 헤드헌터나 서치펌 등 다양한 경로를 이용해서 개발자를 채용할 수 밖에 없다. 하지만 이렇게 공개적으로 채용을 할 경우 짧은 시간에 개발자의 실력을 측정하고 회사에 적합한 사람인지 알아내기가 쉽지는 않다. 특히 경험이 많은 개발자들의 화려한 언변에 현혹이 되면 실체를 파악하지 못하는 경우도 많다.

그래서 필자가 개발자를 어떻게 채용하는지 설명하려고 한다. 물론 일반적인 관점과 좀 다를 수는 있다. 필자의 회사에서는 개발과 관리가 완벽히 분리되어 있고 개발 체계와 문화도 실리콘밸리의 소프트웨어 회사들과 비슷하다.  채용에 있어서 특이한 것이 2가지가 있다.

첫째, 동일 도메인 경험이 풍부한 개발자를 특별히 선호하지 않는다.

금융회사는 금융회사 출신의 개발자를 선호하고 보안, 게임 등 여러 분야에서 도메인 경험은 상당한 우대 요소로 작용을 한다. 그 이유는 도메인 지식을 익히는데 시간이 오래 걸리고 그때까지는 역량을 제대로 발휘하지 못하기 때문이다. 물론 도메인 경험이 도움이 안되는 것이 아니다. 하지만 도메인 경험보다 개발자 본연의 역량이 훨씬 중요하고 도메인 지식은 시간이 흐르면 익혀지지만 원초적인 개발 역량은 쉽게 바뀌지 않는다. 게다가 도메인 지식으로 개발 후보를 제한하면 좋은 개발자를 채용할 수 있는 범위가 좁아진다. 이렇게 도메인 지식보다 기초 역량을 중요시 하는 것이 중장기적으로 좋다.

둘째, 관리 능력이 뛰어난 개발자를 별로 선호하지 않는다. 오히려 꺼려한다.

우리나라에서 개발자들은 경력이 5년~10년 정도 되면 조금씩 관리 요구를 받게 되고 관리를 하면 할수록 개발에 매진할 시간은 줄어든다. 소프트웨어 개발이 관리도 하면서 짬짬이 해서 실력을 꾸준히 유지하고 발전시킬 만큼 쉽지가 않다. 관리 능력도 뛰어난 개발자를 선호하는 회사도 있지만 우리 회사에서는 개발과 관리가 철저히 분리되어 있기 때문에 개발자는 순수 개발 능력만을 본다. 관리 능력도 있는 개발자라면 관리 능력은 쏙 빼고 개발 능력만 보기 때문에 관리 능력이 뛰어난 개발자가 관리자가 아닌 개발자로 채용되는 경우는 흔치 않다. 축구선수를 뽑는데 농구도 잘하는 경우는 축구선수로 채용되기 어려운 경우와 비슷하다고 할까? 물론 어쩔 수 없이 관리도 했지만 개발역량이 뛰어난 개발자도 있다. 이런 개발자라면 채용에 문제가 없다.

우리 회사도 타사와 채용 절차는 크게 다르지 않다. 서류심사, 온라인 코딩테스트, 전화 인터뷰, 대면 인터뷰 이런 순서대로 진행이 된다. 대면 인터뷰에서는 즉석에서 칠판에 쓰는 코딩테스트를 진행한다. 20년차 개발자를 채용할 때도 코딩테스트는 필수다. 그럼 채용 시 중점을 두는 것에는 어떤 것들이 있는지 알아보자.

첫째, 출신 대학과 전공은 별로 중요하지 않다. 남녀, 국적도 따지지 않는다.

실제로 출신 대학과 무관하게 코딩테스트에서는 매우 뛰어난 결과를 보였고 천재적인 역량을 발휘한 사례도 있다. 학교 성적과 상관없이 논리적인 사고력이나 수학적인 능력이 뛰어난 사람이 소프트웨어 개발에 탁월한 경우도 드물지 않게 있다. 전공도 마찬가지다. 소프트웨어 전공이 아닌 경우에도 뛰어난 개발자를 자주 발견하고 한다. 최근에는 수학, 통계학 등의 전공자를 일부러 찾기도 한다. 야근이 수월한 체력이 좋은 남자를 선호하는 회사도 있지만 성별을 전혀 따지지 않는다. 또한 국적도 따지지 않고 한국어를 못해도 실력만 좋거나 잠재력만 뛰어나도 채용을 한다.

둘째, 온라인 코딩 테스트를 통해서 개발자 기초 역량을 확인한다.

온라인 코딩 테스트는 보통 3문제를 제출하고 24시간 안에 풀도록 한다. 내가 풀었을 때 2시간 정도 소요가 되기 때문에 24시간은 충분한 시간이다. 경시대회 수준의 어려운 문제와 쉽지만 창의력이 필요한 문제를 출제한다. 적어도 하루를 투자해야 하기 때문에 후보자가 얼마나 진지하게 우리회사에 지원한 것인지 확인할 수도 있다. A~F 등급으로 평가를 하며 B 등급 이상이 되어야 통과된다. 온라인 코딩 테스트 서비스 회사는 많이 있지만 우리 회사에서는 손으로 직접 채점을 한다. 정답 도출 여부는 자동 테스트를 하고 코딩 내용은 직접 눈으로 확인한다. 정답을 도출하지 못해도 창의력과 프로그래밍 방식을 평가하여 높은 등급을 주기도 한다. 온라인 코딩 테스트는 다른 사람이 도와줄 가능성도 일부 있기 때문에 100% 신뢰를 하지는 않고 일정 수준으로 거르는 용도로 사용을 한다.




셋째, 인터뷰 시 진행하는 칠판에 하는 코딩 테스트는 개발의 축소판이다.

개발자 채용에서 가장 중요한 절차다. 온라인 코딩 테스트를 통과한 개발자도 인터뷰 시 꼭 코딩 테스트를 또 진행한다. 문제는 매우 쉽지만 제대로 하기는 만만치 않는 문제를 출제한다. 시간은 10~20분 정도 소요가 되며 이 과정에서 개발자의 두뇌, 논리적인 사고력, 문제 해결 능력을 본다. 알고리즘을 1초 안에 머리 속으로 빈틈없이 시뮬레이션 할 수 있는 사람과 수분에 걸쳐서 숫자를 대입해가면서 검증을 해야 로직이 확인되는 사람은 하늘과 땅 차이다. 칠판에 하는 코딩테스트에서는 이 차이가 적나라하게 드러난다. 물론 후자는 탈락한다는 것은 아니다. 물론 전자의 후보가 월등히 높은 평가를 받는다. 또한 진행하는 과정을 보면서 향후 개발자가 어떻게 개발을 할지 추측할 수 있다. 평소에 개발을 하던 습관이 이 짧은 시간에 다 나온다. 또한 말만 번지르르하고 실제로 코딩을 잘 못하는 고참 개발자들도 여기서 걸러진다. 실제 수백 번의 코딩테스트를 통계 내보면 경력에 따른 큰 차이가 없다. 이런 코딩 테스트를 평가하기 위해서는 매우 뛰어난 개발자가 직접 평가를 해야 한다. 그렇지 않고는 후보자의 논리적인 사고력, 두뇌 회전 속도 등을 판단하기 어렵다.

넷째, 개발언어, 도메인은 별로 중요하게 생각 안 한다.

C, C++, Java, C#, Objective C 등 개발 언어 하나는 완전히 마스터한 개발자를 채용하며 우리가 사용하는 개발 언어를 사용해보지 않은 개발자도 채용을 한다. 다른 개발 언어는 필요하면 익히면 된다. 빨리 익힐 수 있는 잠재력을 가지고 있는지가 더 중요하다. 특이한 경우지만 코딩 경험은 거의 없지만 잠재력이 무한한 사람이라면 개발 언어를 잘 몰라도 채용이 될 수도 있다. 보통 뭘 해봤고 무슨 툴, 라이브러리를 써봤는지 보다는 잠재력 확인에 주력한다. 그래서 가장 자신 있는 개발 언어에 대해서 그 특성을 제대로 이해하고 있는지 질문을 하고 OOP의 개념을 얼마나 잘 이해하고 있는지도 질문을 한다. 우리 회사와 동일한 도메인 지식 경험이 있다면 당연히 좋겠지만 그렇지 않더라도 상관하지 않는다. 우리는 Dental 분야지만 보안, 레저, 게임 등 분야를 가리지 않고 채용을 하며 입사 후 능력과 성과는 도메인과 별로 상관이 없다.

다섯째, 좋은 개발 습관을 가진 개발자를 선호한다.

경력이 많은 개발자일수록 자신의 습관을 바꾸기가 어렵다. 그래서 경력이 많을수록 습관을 주의 깊게 파악한다. 신입이라면 백지와 다름이 없기 때문에 거의 잠재 능력 위주로만 평가를 한다. 소프트웨어 공학에 관심이 많은 것은 긍정적인 요소이며 권위 의식이 있는지 협업과 커뮤니케이션에 능숙한지 공유하는 습관이 있고 문서 작성을 제대로 하는지 확인한다. 꾸준히 새로운 기술을 거부감 없이 익히고 공부하는 것을 즐기는 타입이면 좋다. 인터뷰에서는 보통 좋은 모습만 보여주려고 하기 때문에 습관을 숨길 수 없는 핵심적인 질문을 통해서 진짜 습관을 알아내려고 노력한다. 습관은 바뀌기 어렵기 때문에 인재에 투자할 여력이 된다면 잠재력이 뛰어난 신입개발자를 채용하여 좋은 환경에서 훈련시키고 회사의 문화를 습관화 시키는 것이 좋다.

우수한 개발자가 뛰어난 개발자로 성장하고 뛰어난 성과를 내려면 거기에 걸맞은 환경이 필요하다. 그 중에서 가장 중요한 것이 협업이다. 분석, 설계를 제대로 하고 공유를 하며 개발자의 경력을 보장하고 수평적인 조직 문화를 갖추는 등 개발자가 실력을 발휘하고 성장할 수 있는 환경이 필수적이다. 이건 워낙 광범위한 주제이기 때문에 이 글에서는 논외로 하자.

지금까지 회사 관점에서 어떻게 뛰어난 개발자를 채용하는지 알아봤는데 거꾸로 개발자 관점으로 보자. 필자가 걸어온 길이기도 한다.

개발 언어 하나는 일단 도사급이 되어야 한다. 그리고 다양한 개발 언어를 거부감 없이 수시로 익히고 특히 스크립트 언어 한두개도 능숙해져야 한다. 새로 나온 기술도 관심을 꾸준히 가지고 필요한 만큼 익혀 놓아야 한다. 영어는 끝이 없으므로 꾸준히 공부를 해야 한다. 수학과 논리적인 사고를 꾸준히 단련해야 하며 수시로 글을 쓰고 개발 문서를 써야 한다. 소프트웨어 공학이 몸에 익어야 하며 커뮤니케이션, 협업 역량 향상을 위해 노력하고 겸손함과 인내심을 갖추려고 노력한다. 이렇게 좋은 습관과 뛰어난 지식과 경험을 쌓은 개발자라면 대부분의 SW 회사에서 채용하고 싶을 것이다.

이렇게 준비하며 습관을 만들어가기 어려운 환경에서 일하고 있는 개발자도 매우 많다. 그래도 언제든지 이직의 기회는 발생하는 것이고 현재 환경에서 할 수 있는 최선을 다해서 자신을 만들어가면 좋겠다.

이글은 ZDNet Korea기업블로그에 기고한 글입니다.

2016년 8월 5일 금요일

이 세상에서 가장 먼 길

세상에서 가장 먼 길은 뭘까? 

여기에서 지구 반대 편까지?

김수환 추기경은 “머리에서 가슴까지 내려오는 길”이라고 했다. 여기서 머리는 지식을 말하고 가슴은 마음을 말한다. 즉, 습관을 말한다. 몰라서 못하는 것도 많지만 알아도 행하는데 까지는 긴 시간 동안 수련과 정진이 필요하며 평생 못하기도 한다.

이것이 회사의 기업문화를 바꾸기 어려운 이유 중 한다. 머리로만 알아서 되는 것이 아니라 가슴, 마음이 움직여야 한다. 즉 습관이 되게 해야 한다. 한 개인이 혼자서 습관을 바꾸는 것도 어려운데 많은 사람들이 모여 있는 회사 전체의 습관을 바꾸는 것은 상상을 초월할 정도로 어렵다. 

가장 좋은 것은 좋은 기업문화와 뛰어난 선배들이 많은 회사에 가는 것이다. 혼자서 20년을 정진해도 못 배울 것들을 1,2년 안에 배울 수 있고 그 습관은 평생을 간다. 인위적으로 단기간에 기업문화를 바꾸는 것은 대단한 각오로 추진하지 않으면 어렵다. 

내가 과거에 Survey한 정보에 따르면 10년전만 해도 이슈관리시스템을 쓰는 회사의 비율이 50%가 안되었다. 이제는 80% 이상의 회사가 이슈관리시스템을 쓰고 있는 것으로 추측된다. 하지만 제대로 쓰고 있는 회사의 비율은 10%가 안된다. 제대로 된 방향으로 강력히 드라이브를 해도 3년에서 5년은 걸린다. 하지만 이슈관리시스템을 쓰기만 하는 정도로 제대로 되고 있다고 착각하는 회사가 많다.

예를 들어서 설명하면 스펙은 5년, 빌드는 6개월, 소스코드관리는 1~2년, 공유 협업 문화는 5년 등 기업에서 뭘 하나 바꾸려고 해도 제대로 바꾸는데는 6개월에서 10년이상 걸린다. 이것이 머리에서 가슴으로 내려오는 시간이다. 많은 기업들은 이런 것을 몇개월만에 해치우려고 하고 그렇게 하면 흉내를 내는 것에 불과하고 오히려 부정적인 의식이 팽배해져서 더 손해가 된다.

그럼 가슴으로 내려오기 전까지는 전혀 도움이 안되는가? 그렇지는 않다. 분야에 따라서 다르지만 조금씩 좋아지고 임계점을 넘으면 생산성이 확 올라간다. 하지만 처음에는 생산성이 더 떨어진다. 임계점에 이르는데 짧게는 6월부터 5년이 걸릴 수 있다. Jira나 Redmine 깔았다고 Subversion이나 Git를 쓰고 CI 툴을 이용한다고 생산성이 올라갈 것이라는 생각은 버리자. 골프채 좋은 것 쓴다고 골프를 잘 치는 것이 아니다. 좋은 도구가 꼭 필요하기는 하지만 골프를 잘 치려면 결국에 올바른 훈련법에 따른 오랜 훈련이 필요한 것이다. 

회사가 크면 그만큼 변화가 느리다. 변화를 거부하는 직원이 많으면 실패할 확률이 높다. 

두뇌는 변화를 거부한다. 두뇌는 변화를 위기로 인식하기 때문에 변화를 시도하면 두뇌는 자꾸 원래대로 돌아가라고 명령한다. 작심삼일이 발생하는 이유다. 내가 의지력이 약한 사람이라서 그런 것이 아니라 두뇌의 잠재의식이 명령을 하기 때문이라고 이해하자. 그래서 변화를 거부하는 직원이 있는 것은 당연하다. 그래서 회사가 변화를 하려면 두뇌가 받아들일 수 있을 만큼씩 변화를 해야 하는데 전략이 필요하다. 

변화에 성공하는 회사는 몇% 안된다. 이는 나쁜 일도 아니다. 모든 회사가 변화에 성공해서 다 뛰어나지면 경쟁이 더 치열해질 것이다. 변화에 실패하는 다른 회사와 다른 사람을 탓하지 마라. 그들은 내가 또 우리 회사가 돋보일 수 있는 결정적인 기여자들이다. 

회사에서도 남들에게 영향을 미칠 수 있는 위치에 있다면 “머리에서 가슴까지의 거리”를 생각하자. 직원들이 잘 못한다고 나무라거나 스트레스 받지 말고 습관이 될 수 있도록 꾸준히 가이드를 해야 한다. 6개월에서 10년을 기다릴 각오를 해야 한다.

개발자 입장에서 가장 좋은 자세는 회사나 동료는 생각하지 말고 혼자서 배우고, 바뀌고, 정진하는 것이다. 회사를 바꾸려고 스트레스 받지 말고 스스로 정진하여 좋은 개발자가 되는 것이 좋다.