태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

똑똑한 개발자를 찾기 위한 인터뷰 전략

2014.04.24 23:15 by 전규현


잠시 후 Google blogger로 이동됩니다.






나는 오랫동안 많은 개발자 인터뷰에 참석했다. 여러 소프트웨어 회사에서 개발자 인터뷰를 어떻게 진행하는지 들을 수 있는 기회가 있었고 회사의 관계자 대신 면접관으로서 기술 인터뷰를 진행한 경험도 많다. 그래서 소프트웨어 업계에서 개발자 인터뷰를 어떻게 하고 있는지 알 수 있는 기회가 있었다. 

 

우리나라에서 개발자 인터뷰를 어떻게 진행하는지 보면 해당회사와 직접적으로 관련된 경력을 집중적으로물어본다. 구체적으로 무슨 프로젝트를 어떻게 진행했느냐? 무슨 기술을 다뤄 봤느냐? 이런걸 아느냐? 우연히 면접관이 아는 지식과 유사한 경험을 한 개발자는 재수좋게 시원하게 답변을 할 수있다. 또한 개발자는 경력에 대해서는 자신이 한 것이나 동료가 한 것이나 구분하지 않고 과장되게 설명하곤 한다. 

 

개발자의 역량보다 동일하거나 유사한 분야의 경험을 더 중시하여 개발자를 채용하는 것은 초단기적으로는회사에 급한 불을 끄는데는 도움이 되지만 중장기적으로는 좋은 전략이 아니다. 이는 마치 부품이 고장나서똑같거나 호환되는 부품을 갈아 끼우겠다는 전략과 별반 다를 바가 없다. 

 

이렇게 동일 경험 개발자를 선호하다보니 경쟁사 개발자를 데려오기도 하고 동종업계 이직금지 서약을 더욱 중요시 하게 되고 논란도 많다.이러다 보니 여러 분야에 손을 대고 있는 대기업은 어느 중소기업에서 개발자가 오더라도 동일 분야라고 주장을 하면 송사에 휘말릴 우려가 있고 개발자의 이직 자유권을 제한하기도 한다. 동일 분야 개발자를 특히 선호하는 이유는 회사의 개발 문화가 낙후되어 있기 때문이다. 

 

공유가 안되고 협업이 힘들어서 어느 개발자가 오더라도 능력을 발휘하는데 오래 걸린다. 이런 이유로 동일 경험 개발자 위주로 채용하는 현상은 개발자에게 이직의 범위를 축소시키고 기회를 박탈하게 된다. 소프트웨어 개발자는 자신이 일해왔던 분야 뿐만 아니라 거의 모든 분야에서 일할수 있다. 또 그렇게 일해야한다. 

 

물론 개발자 스스로가 다른 분야에 거부감이 있는 경우도 있지만 이 또한 환경이 그렇게 만든 측면이 크다. 문제는 회사가 문화적으로 프로세스적으로 준비가 되어 있는가이다. 여러 분야의 개발자가 섞이는 것은 개발자에게 기회의 확대외에도 다양한 경험이 창의적인 아이디어와 혁신에 도움이되어 소프트웨어 산업 전반적으로 꼭 필요하다. 

 

단기적인 부품교체를 하겠다는 생각이 아니라면 개발자를 채용할때 가장 중요한 것은 회사의 미래 개발에필요한 똑똑한 개발자를 뽑는 것이다. 고급 개발자에게 필요한 것은 3가지가있다. 첫째, 소프트웨어 이론 지식이다. 둘째, 공학적인 경험과 개발 문화적인 소양이다. 고참 개발자에게는 중요한 요소다. 셋째, 가장 중요한 논리적인 두뇌와 수학적인 능력, 그리고창의력이다. 

 

신입 개발자를 채용하는 경우라면 이중에서 세번째만 집중적으로 봐도 된다. 세번째를 확인할 수 있는 방법은 문제해결(Problem solving)능력을 확인할 수 있는 창의적인 질문과 코딩 테스트(Coding Test)다. 이 두가지로 개발자가 얼마나 논리적이고 수학적인 사고를 하는지, 또 창의적인지 확인할 수 있다. 

 

동일 분야 경험이 전혀 없더라도 회사가 문화적으로 프로세스적으로 준비가 되어 있다면 1, 2개월후에는 동일 경력만 있는 개발자보다 우수한 능력을 보여줄 수 있고 그 성과의 차이는 시간이 흐를수록 점점 벌어지게된다. 이중에서 코딩 테스트에 대해 좀 더 알아보자. 코딩테스트를 하는 회사가 과거보다 많이 늘었다. 하지만 코딩 테스트의 방향을 못잡고 엉뚱하게 진행하는 회사도 있고 코딩 테스트에 거부감을 가지고 있는 개발자들도 있다. 

 

사실 코딩 테스트를 한다는 것은 개발자에게 긍정적인 신호일 가능성이 더 높다. 개발자의 역량을 제대로 평가할 줄 알고 그 만큼의 대우가 있을 가능성이 더 높다. 가끔 소프트웨어 회사의 코딩 테스트를 보면 나도 통과하기 힘든 것 같은 문제들이 나오기도 한다. 동일분야의 상세한 경험이 없으면 풀 수 없는 문제가 대표적이다. 동일 분야 동일 경력 개발자를 채용하기 위한 방법으로 코딩 테스트를 사용할 뿐이다. 

 

이런 회사는 단기적으로 부품을 교체하겠다는 생각이라면 상관이 없지만 그렇지 않고 좋은 개발자를 뽑기 위한 목적이라면 잘못된 방법을 사용하고 있는 것이다. 역사를 배운다고 연도나 줄줄이 외워야 하는 것처럼 이런 것을 물어보는 쪽지 시험과 같은 코딩 테스트는 뛰어난 개발자를 놓치기 쉬운, 좋지 않은 방법이다. 

 

그런데 지금도 이런 문제들을 갖고 개발자를 채용하고 있는 회사들이 꽤 있다. 이런 현상이 벌어지는 이유는 회사에서 고참 개발자들에게 코딩테스트 준비를 하라고 하면 그 동안 암기식 교육에 익숙해서 이런 문제 밖에 못 내고 인사 담당자는 이를 평가할 능력이 없기 때문이다. 코딩 테스트시 집중적으로 봐야하는 것은 개발자의 논리적인 사고 능력과 문제해결 능력, 창의성이다. 

 

그러기 위해서 특정분야의 지식을 필요로 하는 문제는 삼가는 것이 좋다. 코딩 테스트에는 대략 5가지 방법이 있다. 아래 방법 중 한 두가지를 선택해서 코딩테스트를 진행한다. 

 

첫째, 온라인 사이트 코딩 테스트다. 지원자가 너무 많은 경우 정말 자격이 안되는 개발자를 거르기 위한 용도로 사용한다. 인터넷을 검색해 보면 이런 서비스를 제공하는 회사가 많이 있다. 지원한 회사에서 지정한사이트에 등록을 하고 자신이 선호하는 개발언어로 주어진 시간동안 코딩을 하면 된다. 

 

둘째, 24시간에서 며칠이 소요되는 프로젝트 테스트다. 좀더 가능성이 있는 개발자에게는 첫 번째 온라인 사이트를 이용한 코딩 테스트보다 몇 시간 또는 하루 이틀 걸릴 간단한 코딩 숙제를 주고 1~3일안에 온라인으로 제출을 하게 한다. 

 

이때는 개발자의 논리적인 사고와 창의력도 보고 코딩 스타일도 보게 된다. C사의 경우 이 코딩 테스트에서 95% 이상의 개발자가 탈락을 한다고 한다. 개발자들이 정말로 가고 싶어하는 유명한 회사가 아니고 이름이 잘 알려지지 않은 중소 소프트웨어 회사라 면이 방법을 사용하기 힘들다. 개발자들이 그냥 귀찮아서 포기할 가능성이 높다. 

 

셋째, 전화 코딩 테스트다. 전화를 이용해서 코딩 테스트를 하는 방법인데 위 방법보다 좀더 많은 것을 볼 수가 있다. 전화를 통해서 지원자와 대화를 하면서 화면을 공유할 수 있는 방법을 통해서 직접 코딩하는 것을 보면서 코딩 테스트를 진행한다. 

 

구글 드라이브 문서를 통해서 공유하기도 하고 이와 비슷한 공유가 가능한 온라인 편집기를 사용하기도 한다. 또는 스카이프 등 화면을 공유하는 소프트웨어를 이용하기도 한다. 이런 협업 도구를 통해서 코딩하는것을 직접보면서 면접관은 이런 저런 질문을 하고 개발자는 코딩하는 것을 설명하면서 진행한다. 토론식으로 진행도 가능함으로써 코딩 결과만 보는 것보다는 훨씬 많은 것을 파악할 수가 있다. 지역적으로먼거리에 있는 개발자를 검증하기 위해서 사용할 수 있다. 

 

넷째, 1~3시간 온사이트 테스트다. 지금까지의 방법은 다른 사람의 도움을 일부 받을 수가 있다. 하지만 온사이트 테스트는 확실히 본인만의 실력으로만 진행해야 한다. 이 방법은 인터뷰전에 혼자서 노트북에 직접코딩을 하는 것이다. 1~3시간안에 풀 수 있는 문제를 주고 컴파일 및 실행이 되도록 직접 코딩을 하는 것이다. 인터뷰시에는 코딩한 결과를 설명할 수 있어야 한다. 이런 테스트는 면접자에게 많은 시간과 부담을 주기 때문에 이에 합당하는 면접 비용을 지불하는 것이 좋다. 

 

다섯째, 면접관과 함께 하는 칠판 코딩 테스트다. 내가 가장 선호하는 방법은 짧은 시간에 진행하는 칠판 코딩 테스트다. 가장 많은 것을 볼 수 있다. 칠판이라는 특성 때문에 문법은 보지 않는다. Pseudo Code(실행되지 않고 로직만 표현한 소스코드)로 작성을 해도 된다. 코딩결과만 보는 것이 아니라 어떻게 진행하는지더 눈여겨 본다. 

 

개발자가 문제를 정확하게 이해했는지 면접관에게 물어보는 자세도 중요하게 본다. 일부러 질문을 유도하기 위해서 문제에 질문이 필요한 함정을 넣기도 한다. 이를 질문도 없이 일사천리로 코딩을 해나가면 의심을 해봐야 한다. 

 

코딩을 하면서 중간 중간에 적절하게 설명하는 자세도 아주 중요하다. 그런데 우리나라 개발자들은 설명없이 그냥 써내려가는 경우가 많다. 평상시에 개발하는 방식이 그대로 반영된다. 이때 면접관이 지적하는 것에 대해서 어떻게 대응하는지도 중요하다. 코딩을 다하고 나면 개선점을 가지고 간단한 토론을 하는 것이 좋다. 이렇게 면접관과 상호작용이 잘 되는 개발자는 나중에 개발시에도 공유 및 커뮤니케이션이 잘될 수 있다. 

 

이렇게 10~30분동안 진행하는 코딩 테스트는 평소 개발의 축소판이고 창의력, 문제 해결 능력, 커뮤니케이션 능력까지도 볼 수 있는 좋은 수단이다. 실제 인터뷰에서 경력은 화려한데 칠판 코딩 테스트에서 탈락하는 경우가 부지기수다. 기본적인 논리적 사고와 수학적인 능력도 없이 본인이 설명하는 수 많은 프로젝트를 수행했고 높은 연봉을 받은 고참 개발자들을 보면 안타깝기 그지 없다. 

 

누가 설계를 해야하고 누가 프로그래밍을 해야하는지 구체적인 구분도 없이 고참이고 경력이 많다는 이유로 프로젝트의 설계를 주도하고 망쳐와서 정작 경력이 적더라도 똑똑하고 뛰어난 개발자들이 성장의 기회를 놓치게 된다. 개발자에게 진짜로 필요한것이 무엇인지 생각해보자. 

 

회사에서 진짜 뛰어난 개발자를 구분할 수 있고 그에합당한 대우를 할 수 있을때 우리 주변에 연봉 수억의 개발자들이 바글바글하게 될 것이다. 그래야 뛰어난두뇌를 가진 사람에게 소프트웨어 개발자는 충분히 매력적인 직업이 될 수 있을 것이다. 그쯤되면 소프트웨어 생태계가 더욱 좋아지고 개발자에게는 롤모델도 생기고 개발자에 대한 전반적인 인식과 대우도 더 좋아질 것으로 확신한다.

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 개발자, 인터뷰, 채용, 코딩테스트

  1. Blog Icon

    비밀댓글입니다

SW개발자 블랙홀

2011.10.22 16:44 by 전규현


잠시 후 Google blogger로 이동됩니다.







중소기업, 심지어는 중견 기업들도 SW개발자를 뽑기 정말 힘들다.


신입은 물론 경력직도 구하기 어렵다.

몇년전부터 소프트웨어 경쟁력이 이슈화되면서 대기업들이 SW개발자들을 블랙홀처럼 빨아드리고 있는 것이 그 중요한 원인 중 하나이다.

이러한 현상은 비단 중소기업 뿐만 아니라 장기적으로 보면 SW생태계에도 좋은 영향을 끼치지 못하고 SW개발자들에게도 별 도움이 안된다.

그 이유는 대기업들이 SW 경쟁력 확중을 인원 확충과 같은 것으로 착각하고 있기 때문이다. 심지어는 중소기업 밥그릇을 뺏기 위해서 중소기업들이 주력하던 분야에 진출해서 관련된 개발자들을 데려가서 중소기업을 고사시켜서 시장을 뺏어 오기도 한다. 

중소기업, 중견기업을 다니는 많은 개발자들은 어려운 근무여건과 불안한 미래 때문에 대기업으로 옮기기를 선호하는 경향이 많다. 또한 대기업에 가면 체계적인 프로세스와 뛰어난 방법론 등 SW 개발에 대해서 뭔가 더 배울 수 있지 않을까 착각들을 한다.

하지만 막상 대기업으로 자리를 옮겨보면 자신들의 기대는 큰 착각이었다는 것을 깨닫곤 한다. 대부분의 대기업 SW조직은 작은 회사가 여러개 있는 것과 별반 다르지 않고 SW공학적인 능력은 중소기업보다 뒤쳐지는 경우도 많다. 

따라서 제대로된 소프트웨어 회사에서 10명이면 할 수 있는 일을 100명이 하는 경우도 있다. 이렇듯 대기업은 많은 개발자들을 빨아들이지만 개발자들을 효과적으로 활용하지도 못하고 개발자들의 역량을 제대로 키워주지도 못하고 있다. 그렇다고 딱히 다시 돌아갈 작고 좋은 SW회사들이 많지도 않다.

SW산업에 있어서 좋은 생태계는 다음과 같은 것이라고 생각한다.

좋은 토양에서는 대기업에서 체계적인 개발 방법을 배우고 좋은 아이디어가 생기면 창업을 하던지 작은 기업으로 옮겨서 자신의 생각을 펼쳐 보는 것다. 이 과정에서 대기업과 중소기업이 서로 협력하고 전체 파이를 키워야 서로 상생할 수 있다.
  
몇몇 대기업들이 상생을 외치고 있지만 구호로만 끝날지는 지켜볼 일이다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by 
 thebadastronomer

저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 대기업, 채용

  1. 무턱대고 대기업으로 가는 건 비추입니다.
    NHN이나 삼성에서 많이 뽑지만 정원은 크게 변하지 않았다고 들었습니다. 그만큼 많은 인원이 회사를 떠납니다.
    위에 두 기업말고도 s/w사업으로 대기업이라 불릴만한 기업들 상황은 대강 비슷한 것 같습니다.

    규현님 말씀처럼 대기업이라고 프로세스가 굉장히 뛰어난 것은 아닙니다. 과거에 같이 일해보았던 CMMI 5레벨 인증했다는 국내 굴지의 SI기업도 분석/설계한 내용을 산출물로 만든다기 보다 문서따로 개발따로의 프로젝트를 하더군요. 모든 팀이 다 그렇지는 않겠지만 현실적으로 어느 팀으로 지원을 하냐에 따라 명암이 갈리는 것 같습니다.

  2. 안녕하세요. 김철진님

    그래도 우리나라에서는 안정적인 직장을 원하는 사람들이 많은 것 같습니다. 이직률을 감안하면 그렇게 안정적인 직장도 아니죠.

개발자를 잘못 채용하는 방법

2010.04.19 15:23 by 전규현


잠시 후 Google blogger로 이동됩니다.






뛰어는 개발자를 보유하는 것은 소프트웨어 회사의 절대 필요 조건입니다.

뛰어난 개발자를 보유하는 방법은 내부 개발자들이 잘 성장할 수 있도록 좋은 환경과 기회를 제공하는 것도 중요하지만 기본적으로 뛰어난 개발자를 뽑아야 합니다.

적어도 능력은 B급 이상은 되야 입사 후 성장 가능성이 높습니다. 하지만 좋은 개발자들을 채용하는 것은 그렇게 쉽지 않습니다. 공채, 헤드헌터, 소개 등 갖가지 방법을 써도 쉽지는 않지만 흔히 잘못된 방법이 무엇인지는 쉽게 알 수 있습니다.

어떤 경영자들은 같이 일할 동료들을 개발자 채용 인터뷰에 참여시킵니다. 같이 일할 동료들이 보고 같이 일하기 좋은지 판단하라는 이유에서 입니다. 팀웍이 중요하다는 이유에서 입니다.

하지만 이 경우 잘되는 경우도 있지만 문제가 있는 경우도 많습니다. 기본적으로 같은 레벨에서 개발자를 평가하는 것은 쉽지 않습니다. 즉 인터뷰를 할 능력이 없는 사람에게 인터뷰를 맡기는 것과 비슷합니다. 그런 정도의 인성은 상급자들이 더 잘 볼 수 있습니다.

인터뷰에 참여한 개발자의 입장에서 보면 자신보다 뛰어난 개발자를 뽑는 것은 상대적으로 자신의 비중이 낮아지고 결국에는 자신에게 손해를 가져오기 때문에 본능적인 자기 방어차원에서 그런 개발자들의 채용에 반대하곤 합니다. 이유야 다른 곳에서 찾지요.

채용인터뷰는 특히 개발자 채용인터뷰는 CTO와 개발팀장 등 충분히 기술적인 면과 조직적인 면을 모두 볼 수 있는 사람이 해야합니다. 동료가 될 개발자들에게 인터뷰를 맡기는 것은 인터뷰의 책임이 있는 사람들이 기술적인 식견이 부족해서 기술적인 판단의 책임을 개발자들에게 전가하는 것일 수도 있습니다. 이런 경우 차라리 외부 전문가에게 부탁을 하는 것이 나을 수 있습니다.

개발자는 똑똑하며 긍정적인 사람을 뽑아야 합니다.

하지만, 현실에서는 경력직을 뽑을 때는 해당 분야에서 일해봤는지가 가장 채용의 조건이 되곤 합니다. 이런 개발자들이 똑같은 일을 하다가 똑같은 분야로 옮긴다는 것은 실력이 그리 뛰어나지 않고 그저 경험만 있을 가능성이 높습니다. 정말 일을 잘 했다면 이전 회사에서 더 좋은 대우를 받으며 더 오래 일 했을 겁니다. 뛰어난 개발자들이라면 이런 식으로 옮기지 않습니다. 자신의 미래에 도움이 되는 분야나 최신 기술을 배울 수 있는 곳으로 옮길 겁니다. 또한 퇴사 이전에 이미 누가 데려가지 이렇게 인력 시장에 잘 나오지를 않습니다. 

따라서 급하다고 동일 경력 개발자라는 이유만으로 뽑는 것은 며칠 전에 그만 두었거나 곧 그만둘 개발자의 대타는 될 수 있어도 장기적으로는 회사에 손해가 될 수 있습니다. 

결론은 항상 좋은 개발자를 뽑기 위해서는 당장 발등에 떨어진 불을 끄기 위해서가 아니고 평상시에 꾸준히 노력해야 한다는 겁니다. 그래서 당장 급해서 경력직을 뽑는 것보다 신입으로 미리 준비를 해서 꾸준히 키워 놓은 것이 더 좋은 결과를 가져올 때가 많습니다. 하지만 회사의 프로세스나 개발문화가 엉망이라면 위의 모든 것이 공염불이죠. 이런 경우는 어쩔 수 없이 발등의 불끄기 모드로 채용을 할 수 밖에 없습니다.

결국 악순환이 또다시 시작되는 거죠.

채용은 단발성으로 진행하지 말고 장기적인 안목을 가지고 꾸준히 노력해야 합니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.


저작자 표시 비영리 변경 금지
신고

전규현 개발문화 개발자, 인터뷰, 채용

  1. 잘 읽었습니다.
    글 내용에는 동의합니다만, 실천하기는 무척 어려운 사항이네요.

  2. 안녕하세요. 지킬박수님

    사실 평소에 채용을 위해 꾸준히 노력하는 것은 관리자의 의무입니다. 대부분 의무를 태반하는 것이지요. 또는 회사에서 개발자를 무슨 공장에서 부품 고장나면 교체하듯이 결원이 생길 때만 채용할 수 있도록 하는 회사도 있습니다.
    사실 그렇게 어려운 것이 아닌데, 회사 정책상 또는 게을러서 못하고 있는 경우도 의외로 많습니다.

  3. 댓글 고맙습니다.^^

    말씀하신 게 맞습니다. 어려움은 사장님을 어떻게 설득하느냐에 있습니다. 결원이 생기기 전에 좋은 사람을 미리 확보해 두는 식으로 허용되지 않는 경우 말이죠. 정말 참 어렵네요.

  4. 개발자를 미리 확보해두는 것은 어렵습니다. 평소에 채용을 위해 노력한다는 것은 개발자를 미리 뽑아 놓는 다는 의미는 아닙니다. 평소에 꾸준히 개발자들을 물색해 놓고 좋은 개발자들과 관계를 유지해 놓다가 기회가 되면 데려 올 수 있도록 하는 것도 한 방법입니다.

  5. 평소에 꾸준히 개발자를 물색해 놓는 거, 필요한 일이겠네요. 노력도 해 봐야겠고요. 이 부분은 미처 생각하지 못했습니다.

    다만, 이 또한 쉽지 않다는 생각도 함께 듭니다. 앞서 말씀 드린 대로 결원이 생기기 전에 미리 준비하지 않는 문화를 가진 조직에서는 평소에 꾸준히 개발자를 물색해 놓는 노력을 할 만 한 여유(?)를 만들기가 어렵거든요.

    이게 개인적으로 노력한다고 해서 가능한 것인지 좀 더 고민해 보겠습니다.

  6. 채용에 대한 노력은 관리자의 R&R에 명시적으로 포함이 되어 있어야 합니다. 이를 위한 시간 및 예산이 제공되어야 하며 평가에 반영이 되어야 합니다.
    흔히 관리자의 R&R에 개발자 retain만 포함되는 경우가 많지만, 채용을 위한 노력도 그에 못지 않게 중요합니다.
    개인이 회사의 지원 및 관심도 없이 혼자서 노력하는 것은 쉽지 않습니다.

  7. 예전 개발 환경에서는 기술/업무의 규모가
    크지 않았기 때문에 못하는 사람이나 잘하는 사람이나
    크게 차이가 없었지만 최근 동향을 보면 그 규모나 난이도가 예전과 비교 했을 경우 엄청난 차이가 납니다.

    못하는 사람과 잘하는 사람이 단순 본수로 판단했을 경우
    10본이상 차이가 난다고 합니다.

    즉 앞으로 회사 경쟁력은 테크니컬 인재를 많이
    가지고 있는 회사가 살아 남을 것 같습니다.

    최근 프로젝트를 하면 누가 고급이고 누가 중급인지
    판단이 애매 합니다.

  8. 개발자를 본수로만 따지는 프로젝트가 많죠. ^^

  9. 불러주는 사람도 없고..
    있어도 항상 망하는 회사에만 있는 저는 능력없는 나쁜 개발자인거군요 ㅠ.ㅠ
    이렇게 3년 일하니... 긍정적인 생각도 다 가출해버렸어요 OTL

  10. 구차니님 안녕하세요.
    운이 없으신 거겠죠. ^^ 제 글이 개발자 입장에서는 오해를 일으킬 수 있는 내용이네요. 죄송합니다.
    개발자도 한 회사에 평생 몸 담겠다는 마음가짐 보다는 적절한 때 회사를 잘 옮길 수 있도록 평소에 노력을 해 놓아야 한다고 생각합니다. 그래야 인연이 되는 좋은 회사도 만날 수 있고 그에 필요한 준비도 미리 할 수 있습니다.

  11. Blog Icon
    현실직시

    님께서 작성하신 글은 제가 보기엔 교과서적인 내용입니다.
    저도 여러개발과 수장 노릇도 해봤지만 님의 블로그 내용은 현실적 괴리가 있네요.
    특히, 결론부분은 인력시장을 잘 이해하지 못하신 것이 아닌지요?

    대기업같이 인력 풀이 잘되어 있는 곳이 적절한 예는 아닌 것같고
    그외의 회사를 예로 든다면 개발자를 잘 채용하는 비결은 적정한 보수입니다.
    신입을 키워 향후 활용하는 것은 그때뿐이며 다 자기능력에 대응하는 보수를 찾아 나갑니다.
    남게되는 경우는 대부분 인맥관계나 그외의 사정때문이지 그 회사가 키워줘서 남아 있는 것이 아니지요.
    이런 행태가 솔직히 비난받을 일은 아닙니다.

    경력의 경우 가장 필요한 덕목은 역량도 중요하지만, 책임감과 문제해결능력이 신입보다 높다는 것이지요.
    당장 발등에 불이 떨어져도 경력자가 위의 조건에 충족한다면 된 것입니다.
    제 경험상, 어차피 새로 온 조직에 적응과 업무이해를 위해 가르쳐주는 것은 대부분 경력자가 이해가 더 빠릅니다. 그래서 회사의 신입은 이직하기 전 열심히 배워야 하지요.
    그리고 퇴사 전 이미 누가 데려간다는 것은 대기업이 아닌 이상 대부분 다 인맥으로 가는 것입니다. 그런데 아는 사이이다 보니 연봉협상이 편하질 않죠. 누가 데려가지 않아서 실력이 낮을 것이다라는 편견은 아니시겠죠?
    대부분의 사람들이 적정한 보수와 하고싶은 분야의 일을 찾아 나온것입니다.

    그리고 동일개발자 부분은 저도 동의합니다.
    사실 개발자들은 한우물만 파서는 안됩니다. 일례로 Pro*C 부분만해도 그리 어려운 것이 아님에도 일부 금융권에서는 Pro*C 경력자만 뽑더군요. 전산프로젝트는 종합예술같아서 한가지 부분만 가지고 퍼포먼스 향상을 기대하지 못하는데..
    다양한 지식과 경험을 겸비한 개발자의 개발 능력은 한우물만 판 사람보다 생각의 틀이 넓습니다.

    컨설턴트 하실 때 저와같은 생각을 가지는 사람도 있다는 것을 염두해 두셨으면 합니다.

  12. 좋은 의견 감사합니다.
    경력직 개발자를 채용하는 첫번째 조건은 연봉 맞습니다. ^^ 그런데 발등에 불떨어진 듯 개발자를 뽑으면 높은 연봉을 주고도 좋은 개발자를 찾기가 어렵죠. 작은 회사들은 개발자를 미리 뽑아 놓는 것은 어렵죠. 그렇다고 하더라도 평소에 채용을 위해서 활동을 해야 할 것들이 많습니다. 그런데 대부분 평소에는 전혀 신경을 쓰지 않습니다. 평소에 준비를 잘 해놔야 필요할 때 좋은 개발자를 채용하기가 용이합니다. 연봉은 필요한 만큼 줘야하지요.

    그리고 누가 데러가지 않는 개발자는 실력이 낮다는 것은 아닌데, 제 글을 다시 읽어보니 그런 오해를 할 수 있는 문맥이군요. - -; 당연히 묵묵히 일하는 뛰어난 개발자들도 많이 있죠. 하지만 인력시장에서 좋은 개발자를 찾는 것이 쉽지 않은 것은 경험상 사실이죠. 여전히 여러 인맥을 통해서 뛰어난 개발자를 찾고 꾸준히 관계를 유지해 놓다가 서로 연결을 해서 데려가는 것은 좋은 개발자를 채용하는 효과적인 방법입니다.

    어쩔때는 제가 쓴 글을 다시 읽어보면 이번 글과 같이 의도하지 않은 의미로 이해가 될 수 있는 글들이 종종 있습니다. 이글도 관리자나 경영자의 시야에서 작성했었는데, 개발자 입장에서는 기분이 나쁠 수 도 있겠네요. 나중에 개발자 입장에서 이직에 대해서 글을 써봐야겠습니다.

    좋은 지적 감사합니다.

  13. 참으로 공감하는 내용입니다. 개발자 채용시 기술면접을 외부전문인에게 맡기는 것. 객관성을 유지할 수 있을 것 같습니다. 만약에 개발자 면접을 주관해야 하는 입장이라면 새로 면접하러 온 개발자의 능력을 자신의 능력과 경험에 견주어서 판단할 수도 있겠습니다. 말쓰하신대로 자신보다 뛰어난 개발자가 들어왔다거나, 정치적으로 자신이 위축될만한 인재라고 느낀다면 위축되고 경계하겠죠. 실제로 이런곳 여러군데 봤습니다.ㅎ
    장기적인 안목 그것이 중요할것 같네요 ( 참~ 전 이번 병고 이후 새로운 직장에 몸을 담을 예정입니다. 엔지니어링과 IT개발은 취미로 삼고 말이죠. 앞으로 규현님과 비슷한 일을 할 것 같은 예상이 듭니다. 많은 조언 부탁드리겠습니다.:)

  14. 안녕하세요. moova님
    몸은 많이 나아지셨나보네요. 다행입니다. 블로그에서 자주 뵙기를 희망합니다.

  15. 이글에 추천한표 던집니다. :)
    근데 이런 좋은 글은 저같은 개발자들이 공감하는거 보다도,
    각회사 인사담당자들이 좀 읽고 느껴야 하는데 말이죠.

  16. 안녕하세요. kevin님
    호주에 계시나봐요? 멋진 블로그도 가지고 계시고요. 반갑습니다.
    앞으로 종종 들려주세요.

  17. 이번에 "프로젝트가 서쪽으로 간 까닭은" 이라는 이름으로 번역되어 나온 책이나, 조엘의 책 등에서도 언급했고, 개인적으로도 그동안 인터뷰를 했던 경험으로 보자면 말씀하신 것과 같이 외부인력이나 CTO만으로는 부족합니다. 팀에서 일할 사람을 뽑는데 외부인력이 무슨 내용을 어떻게 알까요? 실제개발에 손놓은지 오래 된, 회사의 기술적 나갈 방향을 결정하는 CTO가 세세한 기술 인터뷰를 제대로 할 수 있을까요?
    함께 일할 사람을 뽑는데 있어 동료들만큼 기술인터뷰를 제대로 할 수 있는 사람들은 없다고 생각합니다.

    1차 기술 인터뷰를 동료들이 직접 하고, pass한 사람들에 대해서 CTO나 다른 사람들이 발전가능성/인성/조직 친화력? 등을 점검해야 합니다.
    최소한 전화인터뷰 - 팀 기술인터뷰 - 최종인터뷰 의 3가지 정도 과정을 거치는 것이 좋더군요.

    자신보다 일을 잘하는 사람을 일부러 떨어뜨린다? 글쎄요, 한명이라도 더 일 잘하는 사람이 들어왔으면 하는 바램으로 가득찬 게 개발자 집단이고, 만약 자신보다 일을 더 잘할 것 같아서 떨어뜨린다면 그 조직은 이미 정치가 난무하는 비효율의 하급 개발자들이 넘친다고 밖에 볼 수 없을 것 같습니다.

    A급 인재는 A급이나 S급 인재를 데려오지만, B급 인재는 자신보다 못한 사람들을 데려온다고 했던 조엘의 이야기가 생각나네요. 스타트업부터 시작해서 회사가 존재하는 한 '우수인력 유치'를 지속적인 프로젝트로 진행해야 하는 이유가 여기에 있을겁니다.

  18. 안녕하세요. 우울한 딱따구리님
    좋은 의견 감사합니다. 사실 CTO만 하더라도 우리나라에서는 상당히 왜곡된 이미지를 가지고 있습니다. 한마디로 우리나라 CTO는 기술을 잘 모르는 사람이 많죠. 그래서 말씀하신 내용이 일리가 있는 것 같습니다.

    거의 대부분의 소프트웨어 회사는 B급, C급 인재가 넘쳐나고 A급, S급 인재는 찾기 어렵습니다. 상황이 이러다보니 채용시에도 좋은 개발자를 가려내기 힘든 것 같습니다.

  19. Blog Icon
    jp

    B급, C급 인재에 대한 대책은 없나요?.^^..

  20. 안녕하세요. jp님
    어느 조직이나 다양한 인재가 필요합니다. 문제는 A급인제인줄 알고 뽑았는데, C급인재인 경우입니다.
    보통의 소프트웨어 회사는 A급인재 10~20% 정도, 그 외에는 B, C급 인재로 채워집니다. 물론 B,C급 인재를 키워서 역량을 갖추게 하는 것도 중요하지만, A급인재가 하나도 없는 회사는 또 곤란합니다.

    회사 입장에서는 그런 것이고, 개발자 개인 입장에서 자신은 B급, C급이 되겠다고 하는 사람들은 없을 겁니다. 그러므로 자신의 목표도 A급, S급에 맞춰야 겠죠.

  21. Blog Icon

    별로 공감이 안가네요.

    같은분야로 전직하는 사람은 위에서 얘기하고 있는 전제인 "실력이 있으면 더 좋은 대우를 받는다" 라는게 안들어맞기 때문입니다.

    오히려 실력이 있던 말던 대우는 똑같이 해주니까 그나마 실력이 있는 사람은 같은분야로 옮기고 실력이 없어서 옮길자신조차 없는사람이 그 회사에 눌러잇죠

  22. Lyn님 안녕하세요.

    핵심과는 좀 다른 글이군요. ^^
    제가 말하는 실력과는 좀 다른 기준을 가지고 있을 수 있는 것 같네요. 여기서 실력이란 오랜 공력에 따른 Domain지식 보다는 진정한 SW개발 실력, 즉, 분석/설계 등 공학적인 경험과 실력을 말합니다.

    실력이 있으면 좋은 대우를 받는다는 것은 음~ 회사마다 다르고 좋은 대우 받는 것은 상황에 따라서 완전히 다른 것 아닐까요?

    실력이 차이가나도 똑같은 대우을 해주는 회사는 호봉제 같은 회사인데 대부분의 회사는 실력에 따라서 차등 대우를 해주려고 노력하고 있고, 하지만 정확하게 실력에 따라 대우을 못해 주는 것이 현실이기는 합니다.

    여기서 핵심은 급하다고 동일 경험이 있는 개발자라고 마구 뽑다 보면 실력 있고 회사의 미래에 도움이 되는 개발자를 뽑기 어렵다는 것입니다.

    개발자는 동일 Domain 경험보다는 "문제 해결 능력" 등 근본적인 실력과 공학적인 경험 및 실력을 보고 뽑는 것이 회사의 미래에 더 좋다는 것입니다.

    ^^

아이폰, 안드로이드폰 개발자 급구

2010.01.19 12:35 by 전규현


잠시 후 Google blogger로 이동됩니다.





요즘 확실히 스마트폰이 이슈이긴 한 모양입니다.

종종 "아이폰 개발 경험이 있는 개발자 급구" 또는 "안드로이드폰 개발 경험이 있는 개발자를 모십니다"와 같은 채용 광고를 보게 됩니다.

과연 아이폰이나 안드로이폰 개발 경험이 있는 개발자가 아이폰과 안드로이드 앱을 더 잘 만들까요?
전 아니라고 생각합니다. 당장은 실력은 부족하지만 해당 경험이 있는 개발자들이 개발 속도가 조금더 빠를 수는 있지만, 6개월 아니 1,2달만 지나도 아이폰, 안드로이드폰 개발 경험은 없지만 원래 소프트웨어를 잘 개발하는 개발자가 훨씬 더 낫습니다. (경험도 있고 실력도 있다면 말할 필요도 없지만...)

개발자를 채용하려는 회사에서 이런 경험있는 개발자를 요구하는 것은 소프트웨어 개발에 대한 이해가 부족하거나 진짜 급해서일 겁니다. 첫번째 경우도 별로 가고 싶은 회사가 아니지만 두번째 경우도 문제네요. 소프트웨어 회사에 있어서 가장 중요한 자산은 개발자인데 이렇게 근시안적으로 개발자를 뽑는 회사는 문제가 있어보입니다.

요지는 개발자들의 개발 능력은  Domain지식과 경험에 크게 구애받지 않아야 한다는 겁니다. 물론 Domain지식이 소프트웨어를 개발하는데 필요한 것은 사실이지만 이는 어느 환경에서 일하느냐에 따라서 자연스럽게 익히게 됩니다. Domain지식을 핵심무기로 삼는 개발자들은 더 좋은 회사로의 이직이 어렵고 계속 그 물에서만 돌아다니다가 소프트웨어 개발자로서의 실력은 형편없는 개발자가 되고맙니다.

또한 개발자들은 Coding도 잘해야 합니다. 그런데 하나의 개발 언어에 매달리는 경우도 위와 비슷한 경우입니다. 나는 Java밖에 못한다. 또는 나는 C++밖에 못한다라고 못을 박는 개발자들이 있습니다. 물론 손에 익은 언어를 사용하는 효율이 높기는 하지만 그렇다고 하나의 개발 언어로만 개발을 하면 스스로 자신의 미래 진로를 가로막는 꼴입니다. 

진정 소프트웨어 개발자라면 특정 개발 언어, 특정 Domain 지식, 특정 Technology에 올인하지 말고 골고루 다 경험을 해야 하고 새로운 것에도 쉽게 적응할 수 있어야 합니다. 특히 고참 개발자가 될수록 다양한 경험과 적응력이 있어야 View도 넓어지고 회사내에서도 기술적으로 중요한 업무를 수행할 수 있습니다. 그래야 개발자로서 10년, 20년 지속적으로 가치있게 일할 수 있습니다.

뛰어난 아이폰, 안드로이드폰 개발자를 뽑고 싶으면 그냥 뛰어난 개발자를 채용하셔야 합니다. 그 개발자와 1,2달 일하고 말것이 아니라면요.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by ntr23
저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 개발자채용, 아이폰, 안드로이드폰, 채용

  1. Blog Icon
    고집불통

    안녕하세요.
    언제나 좋은 글 잘 읽고 있습니다. 저도 개인적으로 많이 공감하지만 글 중에 조금 생각이 달라서
    몇자 적어 봅니다.
    자바 밖에 못한다가 꼭 나쁜건 아니라고 생각 합니다.
    물론 님의 말씀도 꼭 그런 의미는 아니라고 생각합니다만 우리 나라 소프트웨어 산업을 보면
    두루 두루 슈퍼맨을 인정하는 분위기가 많은거 같습니다.
    특정 한 분야만 잘 하는 사람이 다수 존재하더라도 그들 사이의 커뮤니케이션 혹은 조율만 잘 할수 있다면
    훨씬 더 좋은 결과를 낼수 있지 않을까요?
    박사 과정의 전공만 놓고 보더라도... 왜 그 사람들이 한 분야만을 집중적으로 공부할까요?
    분명 뭔가 그럴수 밖에 없는 이유가 있지 않을까요?
    가장 중요한 것은 얼마나 깊이있는 지식을 습득하는 것이 아닐런지요.
    대학 수업에서도 똑같은 과목을 전공 교수가 가르치는 것과 타학과 교수가 가르치는 것은
    분명 차이가 있습니다.
    수업을 잘하는 교수와 연구를 잘하는 교수 둘다가 대학에 필요하듯이
    특정 언어를 가장 잘 이해하는 개발자만도 좋은 룰모델 혹은 평가를 받았으면 해서 몇자 적어 봅니다.

  2. 한가지 언어를 깊이있게 공부한 개발자는 다른언어로 전환할때에도 쉽게 다룰 수 있는 것 같습니다
    학원등에서 모바일플랫폼을 공부하고 프로젝트 한두개를 경험한 초급개발자와 한가지 플랫폼만 깊이 공부한 중급개발자를 비교한다면 한달이면 중급개발자가 초급개발자의 생산성을 앞지를 것 같습니다

  3. 안녕하세요. 고집불통님
    좋은 의견 감사합니다.
    하나의 개발언어에 대해서 정말 능통하고 전문가가 되는데 다른 언어를 공부하는 것도 도움이 됩니다. ^^ 특히나 C언어는 low level 언어중 하나로 java나 기타 언어를 전문으로 사용하는 개발자들도 C언어를 아는 것을 권장합니다.
    한분야의 최고의 전문가가 되는 것도 중요하고 여러가지 지식을 두루 익히는 것도 중요합니다. Toyota에서는 이러한 인재를 T인재라고 하죠. 소프트웨어 필드에서도 적용이 된다고 생각합니다.
    박사 전공을 하는 사람들도 자신의 연구분야는 깊에 연구를 하지만 자신의 연구를 더욱 잘하기 위해서 해당 분야의 지식을 두루 잘 알고 있다고 생각합니다.
    감사합니다.

  4. 특히 요즘들어 도메인 지식보단 메타지식의 가치는 아무리 강조해도 지나치지 않는 시대 같습니다.

    무엇보다 결론이 명쾌하시군요^^
    그냥 뛰어난 개발자를 구하라!
    너무 단순한지만 확실한 정답이 없는 것 같습니다^^

  5. 안녕하세요. 이가님
    그럼, 뛰어난 개발자는 어떻게 구하느냐?라고 물어 볼 수 있는데, 이것 또한 한참 얘기해도 부족하겠죠? ^^

  6. 좋은 글 잘 읽고 갑니다. RSS 등록해놨습니다. ^^
    "아이폰 개발 경험이 있는 개발자 급구" 또는 "안드로이드폰 개발 경험이 있는 개발자를 모십니다"는 개발자를 찾는게 아니라 경험을 찾는 게 아닐까요?

  7. 안녕하세요. MegaWave님
    소프트웨어 채용 현장에서 개발자의 잠재력 및 기반 지식보다 구체적으로 무슨일을 해봤는지를 확인하고 동일한 일을 해본 개발자들을 뽑으려고 하는 풍토가 만연하여 올린 글입니다. 경험이 있는 것이 나쁠 것은 없죠.

  8. "개발자들의 개발 능력은 Domain지식과 경험에 크게 구애받지 않아야 한다는 겁니다."
    본문의 이 부분에 크게 공감합니다.

  9. 안녕하세요. 제주소년님
    평생 은행 소프트웨어만 개발한 개발자들을 보면 은행업무는 빠삭하게 잘 아는데 막상 소프트웨어 개발 능력은 크게 발전하지 못한 것을 알 수 있습니다. 스스로를 Domain지식의 울타리에 가두는 것은 어리석은 행동입니다.

  10. 저는 SI를 주로 하고 있습니다.
    개발언어, 도메인을 전혀 가리지 않고 있습니다만,
    접해본것은 몇가지 되지 않습니다.

    프로젝트 면접을 보면 그쪽 언어, 혹은 도메인을 경험해보지 않았다고
    탈락시키는 경우가 많더군요..

    실제로 몸을 사리는 개발자들도 많지만
    (말씀하신대로 난 java밖에 몰라, 또는 C밖에 몰라.. 나머진 다른 사람 시켜.. 하는 사람도 많더군요.)
    경험이 없는 개발자는 절대 뽑지 않는 프로젝트도 많더군요..
    3대 SI에서도요..

    예전에(2003년도) 3대 SI업체중 한곳에서 스트러츠로 개발하는데 다른 사람만큼
    퍼포먼스가 안 나온다고 일주일만에 쫓겨난 경험도 있고요.. (그때가 스트러츠 처음.. MVC도 처음)

    개인의 노력도 중요하지만 업체들의 시각도 바뀌었으면 합니다...
    물론 SI 기준입니다.. (패키지,솔루션등은 잘 몰라서요..)

  11. 안녕하세요.무혹님
    그런 회사는 안가신데 더 잘된 것 아닐까요?
    대부분 개발자를 단기간 혹사하고 커리어 관리도 안되는 회사들입니다.

  12. 첫번째 드는 생각은, 아직도 많은 사람들이 프로그래밍을 단순히 조금 더 '아는 것' (언어를 아는 것/SDK 를 아는것) 정도로 생각하는거 같다는 생각이고,

    두번째 드는 생각은, 저렇게라도 뽑아야 할 정도로 훌륭한 프로그래머들을 찾는 것 역시 어렵겠구나... 생각이 듭니다. 아무리 지혜롭지 않은 사장이라 하더라도 그 밑에 훌륭한 프로그래머가 있다면, 그 프로그래머에게 시킬테니까 말이죠.

  13. 안녕하세요. Hybrid님
    성장하는 소프트웨어 회사라면 개발자를 꾸준히 뽑게 마련입니다. 1년 1명이든 100명이든요...
    그 1명을 뽑기 위해서 1년 내내 꾸준히 노력해야 합니다. 1명 나갔다고 급히 뽑고, 새로운 일 생겼다고 그런 종류의 일 해본 개발자 뽑고 하는 것은 정말 근시안적인 행동이죠.

  14. 이직하려고 해도 도메인을 벗어나면 신입이 되니.. 그게 힘들게 하네요 후우..

  15. 구차니닌 안녕하세요.
    도메인지식 비중을 조금씩 다른 쪽에 내공을 점점 쌓아나가면 되지 않을까요?

  16. 어플리케이션의 생명은 이젠 아이디어가 아닌가 합니다.
    업무 분할이 잘 되어서 아이디어를 살릴 수 있는 사람들은 아이디어를 잘 살리고,
    코딩을 해야 하는 사람은 코딩을 잘 할 수 있는 환경이 마련되었으면 좋겠다는 바램인데,,
    현실은 그렇지 않네요 ㅎ

  17. 안녕하세요. 꼬마낙타님
    개발자의 가장 두드러진 특징은 바로 창의성이라고 할 수 있는데 현실에서 만나는 개발자들은 현업에 지쳐서 아이디어는 생각할 겨를도 없어보입니다. 모든 것이 맞물려 있지만, 도메인지식 위주로 개발자를 혹사하는 것도 한 원인입니다.

뛰어난 개발자는 타고 나는 것

2009.11.27 23:18 by 전규현


잠시 후 Google blogger로 이동됩니다.




1. 처음부터 똑똑한 개발자를 뽑아라.
2. 똑똑하지 않는 개발자를 채용해 놓고 똑똑한 개발자로 바꾸려고 시도하지 마라.
3. 특출나게 똑똑하지 않은 개발자도 다 적절한 역할이 있다.
4. 그 역할을 찾아서 제 역할을 하도록 하라. 각 개발자에게 알맞은 역할을 찾아 주고 제대로 일하게 하는 것만으로도 얼마나 힘든지 아는가?
소프트웨어 회사 경영자와 관리자에게 전하는 말입니다.
요즘은 뛰어난 개발자를 구별하기 정말 어렵습니다. Labor market에는 실업자가 넘쳐나지만 뛰어난 개발자는 눈을 씻고 찾아봐도 볼 수가 없습니다. 뛰어난 개발자는 이직을 잘하지 않고 노출이 잘 안되기 때문입니다.

그래서 적당한 개발자, 또는 해당 분야에 경험이 좀 있는 정도의 개발자를 그냥 채용하는 경우가 많습니다. 하지만, 이런 개발자들은 뛰어난 개발자를 대신할 수는 없습니다.
뛰어난 개발자는 타고납니다.
뛰어난 개발자의 필수 조건인 논리력은 태어날 때 이미 50%는 결정되고 교육과정을 거치면서 나머지 49%가 결정됩니다. 사회에 나와서 아무리 노력을 해도 이미 완성된 두뇌는 별로 바뀌지 않습니다. 경험이 쌓이면서 좀더 지식이 풍부해지고 노련해질 뿐입니다.

요즘의 개발환경은 뛰어난 개발자와 그저 그런 개발자를 구별하기 점점 어렵게 만들고 있습니다.
뛰어난 개발자들은 정말 복잡한 알고리즘을 몇 시간 만에 구현해 낼 수 있지만, 그저 그런 개발자들은 몇 달을 줘도 불가능합니다. 하지만, 요즘은 그런 알고리즘을 구현하지 않아도 개발이 가능한 분야가 얼마든지 있고, 일반인 수준의 논리력만 가지고도 개발자로서 일하고 있는 사람들이 넘쳐납니다.

하지만, 이런 그저 그런 개발자들만 잔뜩 모아 놓은 회사는 그저 그런 회사일 수 밖에 없습니다.
물론, 소프트웨어 회사가 돌아가려면 이런 개발자들도 필요합니다. 그런데, 뛰어난 개발자와 그저 그런 개발자를 구분하지 못하는 회사는 챔피언이 될 수 있는 선수를 후보로 썩히는 것과 같은 행동을 합니다.

일단 수학을 잘한다면 뛰어난 개발자가 될 가능성이 아주 높습니다. 물론 수학을 잘하는 모든 사람이 뛰어난 개발자가 될 수 있는 것은 아니지만, 하나의 중요한 요소인 것은 사실입니다. 하지만 수학 실력은 아주 형편없는데 뛰어난 개발자가 될 가능성은 별로 높지 않습니다. 애초부터 복잡한 논리를 처리할 수 있는 두뇌를 가지고 있지 않기 때문입니다.  

경력직 개발자중에서 똑똑한 개발자를 찾기 어려우면 아직 세상 물정을 잘 모른 대학생들 중에서 찾는 것이 좋습니다. 참고로 저도 대학교 다닐 때부터 회사 생활을 했었습니다. 
뛰어난 개발자들은 대학 재학 중에도 이미 뛰어난 실력을 보입니다. 대학에서 적당히 학점 따서 졸업하는 학생들보다 학점은 낮을 수 있어도 확실히 실력은 뛰어날 수 있습니다. 하지만, 요즘 같이 치열한 취업 환경에서는 학점에서 탈락해서 취업이 어려울 수 있습니다. 이런 학생들을 찾아서 회사로 끌어들이는 것이 관리자들이 해야 할 중에서 가장 중요한 일이죠.

요즘은 보통의 머리를 가진 사람도 개발을 할 수 있는 세상이 되었습니다.
그렇다고 보통이나 그 이하의 개발자들만 뭉쳐 놓고 훌륭한 제품을 만들 수 있을 것으로 착각하면 안됩니다. 뛰어난 개발자 채용에 회사의 사활을 걸어야 합니다. 관리자나 HR부서에서는 채용 시즌이나 결원이 생길 때만 잠시 채용에 관심을 둬서는 안됩니다. 1년 내내 채용에 온 힘을 쏟아야 합니다. 그렇다고 미련한 방법도 소용 없습니다. 참신한 방법들을 만이 연구해야죠. 

언젠가 똑똑한 개발자들이 스스로 몰려가는 SW회사가 우리나라에고 생기면 좋겠습니다.

PS) 똑똑하다는 것이 개발자에게 필요한 오직 한가지 조건은 아닙니다. 즉, 똑똑하기만 하다고 최고는 아니죠. 특히 인성과 긍정적인 자세가 중하죠. 이런 부분은 나중에 기회가 되면 풀어 보겠습니다. 또한 다양한 채용 방법에 대해서도 글을 올려 볼 계획입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 사람과 기술 hr, 개발자, 경력, 두뇌, 똑똑한개발자, 수학, 신입, 알고리즘, 채용

  1. 개인적으로 문과 성향이 짙긴 하지만 컴퓨터 하나만 보고 이과를 선택한 저로서는

    수학과 개발능력간의 상관관계라.. 실제로 느끼는 바가 있어서 그런지 몰라도 좀 씁쓸하네요.

    하지만 개발능력이 높다고 해서 뛰어난 개발자라는 논리에는 쉽게 수긍이 가질 않네요.

    극단적인 예입니다만 개인적인 개발능력이 아무리 뛰어나다 해도

    팀웍을 해치거나 자기만 이해할 수 있는 코드를 개발하시는 분을 뛰어난 개발자라고 할 수 있을까요? ^^

  2. 안녕하세요. 제주소년님.
    PS에 말씀하신 내용이 있습니다. 너무 당연한 얘기죠. 뭐 굳이 제가 강조를할 필요도 없는...
    똑똑하다고 뛰어난 개발자는 아니죠. 개발자를 채용할 때 머리보다 먼저 보는 것은 마음가짐, 긍정적인 마인드, 팀웍을 잘 유지할 수 있는 지 등입니다.
    본인을 너무 Underestimate할 필요는 없을 것 같습니다. ^^

  3. 수학..... 전 중1인데 아직 수학을 잘하지 못하는데요. 지금부터라도 노력하면 '똑똑한 개발자'가 되는 것이 가능할까요?

  4. 하나님 안녕하세요.
    이것 또한 논리적인 판단인데... 수학을 매우 잘하면 일단 논리력이 뛰어날 가능성이 아주 높습니다. 그래서 뛰어난 개발자가 될 가능성이 높죠.
    하지만, 수학을 못한다고 뛰어난 개발자가 될 가능성이 낮다는 것은 아닙니다. 첫째 수학과 논리력은 100% 동일화 할 수 없고, 수학을 잘하지 못하는 원인이 두뇌가 아니고 다른 원인 일수도 있습니다.
    그래서 뛰어난 개발자가 될 수 있다 아니다는 말할 수 없습니다.
    위의 글은 소프트웨어 회사를 운영하는 사람에게는 유용할지 몰라도 개발자에게는 별 소용이 없는 글입니다. 회사 운영자들은 수많은 개발자중에서 선택을 해서 채용해야 하지만, 개발자는 본인이 전부 즉 100%이기 때문이죠.
    또한 개인으로만 본다면 똑똑한 개발자가 더 성공하고 더 행복하고 더 만족을 느끼는 것은 아닙니다.
    또한 똑똑한 개발자가 퍼포먼스가 더 높은 것은 절대로 아닙니다. 단 똑똑한 개발자만이 할 수 있는 일이 몇가지 있을 뿐입니다. 따라서 나머지 대부분의 일들은 성실한 개발자들의 몫이고 이들이 회사에 미치는 영향이 더큽니다.
    자신이 어느 영역에 해당하는지 그리고 어느 방향으로 성장해야 할지는 스스로를 잘 알아야 합니다. 자신의 두뇌의 한계를 모르고 덤비는 것은 히딩크가 감독으로는 세계적인 명장이 될 수 있는데 끝까지 선수를 해보겠다고 하는 것과 같을 수 있습니다.
    그래서 소크라테스가 몇천년전에 이미 "너자신을알라"라고 했나보죠.

  5. 씁쓸하지만 인정할 수 밖에 없는거 같아요-_-;

  6. 안녕하세요 두렁청해님
    별로 씁쓸해할 필요는 없는 것 같습니다. 이와 반대되는 글, 즉 개발자를 위한 글을 지금 준비중입니다. ^^

  7. Blog Icon
    김무니

    개발자도 개발자지만...
    제발 기획자도 뛰어난 기획자로 쫌...

  8. 김무니님 안녕하세요.
    더욱 척박한 분야가 기획분야입니다. 특히 국내 소프트웨어 업계에서 기획 분야는 척박하기 이를데 없죠. SI나 용역으로 먹고하는 회사들이 주를 이루니 그렇기도 하고 기획(마케팅)의 중요성을 잘 몰라서 투자를 잘 안하니 뛰어난 개발자를 양성할 수도 없죠.

  9. 아.. 초 씁쓸입니다 ㅠ.ㅠ

    그래도 뛰어난 개발자라고 해서 대단한 알고리즘이 툭~하고 튀어나오고 그러진 않을꺼 같아요.
    그건 뛰어난 개발자라서가 아니라.. 그냥 천재인겁니다 ^^;

  10. 구차니님 안녕하세요.
    저도 씁쓸하지만 현실이긴 하죠. 전 똑똑한 개발자를 좀 많이 봐왔다고 생각합니다. 하지만 10여년이 지난 지금 성공은 두뇌순으로 되지는 않더군요. 하지만 회사 경영자 입장에서는 똑똑한 개발자가 필요하죠.

  11. 뛰어난 개발자는 이직을 잘 하지 않고 노출을 잘 하지 않다고 하는건.
    어떻게 보면 이글과 좀 상반되는 이야기 인것 같습니다. - http://allofsoftware.net/117
    정말로 인질범처럼 하나를 움켜잡고 프로젝트 끝까지 질질 끄는 사람들이 많습니다. 누군가는 계속되는 알고리즘을 제공해주는 반면. 이직을 잘 하지 않는 개발자중 상당수는 인질범심리가 꽤나 많더군요.

  12. 안녕하세요. moova님
    현실적으로 일반적으로 똑똑한 개발자는 회사에서 붙잡으려는 경향이 많고, 이직을 하려고 Labor market에 나오는 것이 아니라 그전에 누가 먼저 데려가곤 합니다. 그런 의미죠. 제 이전 글들고 모두 읽고 기억하고 계시는 군요. 감사합니다.

  13. Blog Icon
    Richpapa

    뭔가 동의 할 수 없는 이유는 뭘까요? (논리력이 떨어지기 때문일까요?) 초.중까지 수학경시대회 나갈 만큼 수학을 잘 했었고(상도 많이 받았지요), 학부 때는 교수가 잘 설명하다가 갑자기 그날 따라 못 풀더군요. 그래서 과감히 문제에 도전을 받고 풀었는데, 중간고사/기말고사를 보지도 않고 A+를 맞았고. 공업수학도 곧 잘 해서, A+, 알고리듬, 고급 알고리듬도 A+이고, 수치해석 A+를 맞았는데... (이 정도면 수학을 잘 한다고 봐도 될까요?) 나름 뜻이 있어 학부 3학년 때부터 산학협동을 시작으로 일을 하기 시작을 하긴 했는데...

    그런데... 제가 개발을 잘 하는 사람인지는 모르겠습니다. 가끔은 후배녀석들이 수학을 잘해야 되냐고 묻는데, 나중에 필요할지 모르니까. 공부는 해둬라 정도였습니다. 제 업무가 수치 계산적인 부분이 필요한 콴트 개발자도 아니지만.... 글쎄요.

    전체 그림은 무엇을 말씀하시는지 알겠지만, 국부적인 부분에 반감이 생깁니다.

    "뛰어난 개발자의 필수 조건인 논리력은 태어날 때 이미 50%는 결정되고 교육과정을 거치면서 나머지 49%가 결정됩니다. 사회에 나와서 아무리 노력을 해도 이미 완성된 두뇌는 별로 바뀌지 않습니다. "

    두뇌에 대해서 고정적인 듯 말씀하시는데, 뇌는 결정되지 않습니다. 또는 경험과 노련이 논리적인 것과 상관이 없다는 뉘앙스적 말씀하시는 것에 대해서는 상당히 반감이 생깁니다. 아... 전규현 컨설턴트도 틀린 말을 할 때도 있구나 라는 생각이 들었습니다. 뇌에 관련 된 책을 좀 읽으셨으면 합니다.(잘 모르면 제가 추천해드리겠습니다.) 러닝 스타일(learning style = 태아에서부터 만들어지는)이 존재하긴 하지만 이것은 계발을 통해서 바뀝니다.

    그러니, 논리력 상태를 통해서 개발능력이 뛰어나다 아니다라고 말씀하시는 것에는 동의 할 수 없습니다. 내면의 어떤 동기부여에 따라서 그 사람의 스타일은 바뀝니다. 전체적으로 무슨 말씀인지는 잘 압니다. 저도 소위 말하는 문서면접이 아닌 구글만큼은 아니지만 시험을 보고 회사를 다닙니다.(수학문제도 있었고요.)

    하지만, 논리, 뇌에 해당하는 문맥은 전체 글을 망가트리는 것 같습니다.

  14. 안녕하세요. Richpapa님
    일단 좋은 의견 감사합니다. 말씀하신 내용에 100% 공감하고 또한 두뇌의 능력은 저도 잘 알고 있습니다.
    글이란 한문장만 뽑으면 이상할 수도 있고, 또 타겟이 아닌 사람은 크게 반발할 수도 있습니다.
    결론은 맨 위에 있습니다. 글이 타깃은 경영자구요. 두뇌는 얼마든지 개발 가능하니, 무조건 뽑아서 훈련을 시켜서 똑똑한 사람으로 만드는 일을 하지 말라는겁니다. 거의 불가능하다는 거죠. 개인입장에서 보면 가능한 일이 회사입장에서는 불가능한 거죠.
    그리고 이글은 서로 반대되는 의견의 2글을 대비시켜서 적은 것의 1탄입니다. 이글을 보고 반감들을 충분히 많이 가지셨다면, 경영자들이 개발자를 어떤 식으로 보고 있는지 충분히 이해를 하셨으리라고 봅니다. 이 글은 경영자 View에서는 사실입니다.
    수학을 잘하면 똑똑한 개발자가 될 가능성이 높은 것이고, 필요 충분 조건은 아닙니다. 그리고 그 반대되는 의견이 다음글에 있으니 잘 보시죠.

  15. 경영자의 한사람으로써 동의합니다. 이런 비밀을 공개하시다니... ㅎㅎㅎ

  16. 전경헌 사장님 안녕하세요.
    항상 블로그 잘 보고 있습니다. 경영 마인드가 없는 개발자들은 이 글에 대해서 반감을 많이 느끼는 것 같습니다. 오히려 경영자가 이런 개발자들과 똑같이 완전 개발자 마인드라면 회사 경영이 어렵겠지요.
    전사장님은 잘 이해해주시네요.

  17. Blog Icon
    마이

    저는 개발자는 수학뿐만이 아니라 국어도 잘해야한다고 생각합니다.
    결국, 코드라는 것은 자기의 생각을 표현해내는 것이기 때문에, 표현력이 요구된다고 생각하구요. 또 훌륭한 표현력은 다른 사람들과 공유할 수 있는 산출물 작성에도 꼭 필요하기 때문이죠.
    현장에 있다 보면 많은 분들이 이런 점은 간과하시는 거 같더라구요.

  18. 안녕하세요. 마이님
    동감입니다. 조엘도 글을 잘 못쓰는 개발자는 뽑지 않는다고 했죠.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..

티스토리 툴바