ITM 소식 > Focus
  최고의 개발자는 하루 아침에 만들어지지 않는다
  날짜 : 2006-09-05 10:17:42    조회 : 4335    
최고의 개발자는 하루 아침에 만들어지지 않는다

Robert L. Bogue ( TechRepublic )   2006/02/17    
 
개발 프로젝트를 위해 최고의 개발자를 확보하는 가장 좋은 방법은 외부 개발자를 고용하는 것이 아니라 조직 내부에서 양성하는 것이다.

최신 트렌드에 맞는 민첩한 개발에 대한 글을 읽다가 전통적인 소프트웨어 개발 테크닉과 최신 테크닉의 성공 여부가 모두 고도로 숙련된 개발자들의 손에 달려있다는 사실을 깨닫게 됐다. 

최고의 개발자들에게 시선이 집중되는 것은 당연하다. 유사한 경험을 갖고 있는 개발자들의 성과 수준은 10개 이상의 요인에 의해 달라질 수 있다. 수많은 개발 프로젝트가 여전히 한 명의 개발자나 개발자 소그룹이 자신의 헌신과 끈기에 전적으로 의존하는 ‘영웅 모드’를 기반으로 수행되고 있다. 

개발팀에서는 언제나 우수한 개발자를 필요로 하지만 이런 개발자를 과연 어디에서 구할 것인지는 아직 해결되지 않고 있다.

필자는 12년 이상 리쿠르팅 프로세스에 관여해왔기 때문에 최고의 개발자를 찾는다는 것이 가능하다고 말할 수 있다. 단지 가능성일 뿐이기는 하지만 말이다. 우수한 개발자를 찾아내는 프로세스는 매우 어렵다. 또 수천 통의 이력서를 받았다 하더라도 최종적으로 우수한 개발자라고 생각되는 사람은 1~2명밖에 발견하지 못할 수도 있다.

그러나 이 문제를 직접 고민해 본다면 최고의 개발자를 확보하는 가장 좋은 방법은 외부 개발자를 고용하는 것이 아니라 조직 내부에서 양성하는 것이라는 사실을 알게 될 것이다.

최고의 개발자는 어떻게 만들어지나?
최고의 개발자라는 의미는 분명 주관적이다. 최신 개발 테크닉과 전통적인 개발 테크닉이 모두 개발자와는 약간 다른 무언가를 필요로 한다. 그러나 개발자가 두 가지 테크닉 중 어떤 것을 사용해야 하는지는 한 마디로 정의할 수 있다. 다름 아닌 생각이다.

인식적인 숙련을 위한 블룸(Bloom) 교육 목표 분류의 근저에 깔린 철학은 지식이다. 이 지식은 데이터나 정보에 대한 인식을 말한다. 개발 범주에 적용하면 루프를 실행하기 위해 C# 구문을 인식하거나 올바른 구문을 생각해내는 것을 의미한다.

인식적인 분류의 최상층에는 통합과 평가가 존재한다. 통합은 새로운 솔루션을 만들어내기 위해 개별적인 요소를 한데 취합하는 것이다. 평가는 아이디어, 접근방식 혹은 재료의 가치를 판단하는 능력이다. 

개발자들은 이런 높은 수준의 인식적 능력을 자신의 프로젝트를 효과적으로 수행하는데 끊임없이 적용해야 한다.

대부분의 사람들은 이런 생각을 차이점에 대한 서술이라기보다는 좀더 자연스럽게 생각하는 것이라고 표현한다. 일반적으로 개별적인 조각들을 솔루션으로 구현하는 방법을 모색하는 등 더 높은 수준의 아이디어를 실행으로 옮기기 위해 생각을 더 많이 할수록 개발자의 능력도 향상된다.

최고의 개발자? 모래사장에서 바늘 찾기
최고의 개발자를 고용하는 방안을 아예 포기하기 전에 우선 기술 숙련도를 테스트하는 방식으로 개발자 고용 프로세스 전반을 살펴보자. 필자는 개발자들과 면접 인터뷰를 진행할 때 통상적으로 구두 테스트를 실시한다. 

그동안 인터뷰를 했던 개발자들은 대부분 데이터베이스의 효과적인 운영 능력을 갖추고 있어야 했기 때문에 다음과 같은 간단한 질문을 던졌다.

고객의 ID 필드, 이름, 기존 주문 ID가 담긴 주문 헤더 테이블, 고객 ID, 기타 세부적인 사항이 포함된 고객 테이블이 있는데 한 번도 주문한 적이 없는 고객 리스트에는 어떤 쿼리가 생성되나?
이 문제에 답변하려면 외부 결합에 대한 정확한 지식을 갖고 있어야 한다. (SQL-87 구문에서는 *=를 이용할 수 있지만 이 문제의 정답은 그리 일반적인 것이 아니다.) 지금까지 이 문제에 답변한 개발자들의 비공식적인 정답 수준은 10% 이하였다. 필자는 개발자 인터뷰를 수행할 때 상대방을 대졸, 1~2년 경력자 수준으로 놓고 대화를 진행한다. 하지만 그동안의 경험을 통해 보면 이 문제의 정답을 맞추느냐 그렇지 못하느냐는 경력과는 그다지 관련이 없는 것으로 보인다.

필자가 볼 때 이 질문에 답변하지 못하는 개발자는 SQL이 요구하는 셋 기반 로직을 완벽하게 이해하지 못한 사람이다. 이 부분은 필자가 우수한 개발자를 판단하는 기본적인 숙련도다.

정답이 없다는 사실 때문에 조금 전의 질문보다 더 재미있는 또 한가지 질문이 있다. ‘MS 닷넷에서 당신이 가장 좋아하는 것은 무엇인가?’

개발자들은 이 질문에 자신이 원하는 어떤 기술을 대입할 수 있다. 이 질문에 대한 대답을 듣게 되면 현재 인터뷰에 응하고 있는 개발자가 무엇을 생각하고 있는지 알 수 있다. 만약 개발자가 인텔리센스(대상과 방법에 대한 인터페이스를 기억하도록 도와주는 비주얼 스튜디오 기능)를 언급한다면 이 개발자는 코드 수정을 가장 먼저 우려하고 있다. 우수한 개발자와는 거리가 먼 사람이다. 그런데 만약 개발자들이 이 질문에 답변한다면 이들은 멀리건을 갖고 있는 사람들이다. 

필자는 개발자들이 텍스트 에디터 이상에 대해 생각하고 있다는 것을 알 수 있는 답변을 찾고 있다. ‘런타임 타입 정보 때문에 유연성 있는 코드를 작성하는 능력’과 같은 답변이다. 이러한 답변은 인터뷰 상대방이 최고의 개발자가 되기 위해 반드시 필요한 것에 대해 어떻게 생각하는지를 알 수 있도록 해준다.

이 질문은 ‘당신이 가장 좋아하지 않는 것은 무엇인가’라는 질문에 열중할 때와 마찬가지로 유익하다. C# 안에 세미콜론을 넣는 것을 잊어버리는 것과 같은 답변은 인터뷰 상대방이 자신의 업무에 대해 올바른 수준의 생각을 하고 있지 않다고 의심하게 만든다. ‘쓰레기 수거인에게 충분히 영향을 미치는 무능력’과 같은 답변은 개발자가 플랫폼에서 자신이 필요로 하는 것에 대해 생각하고 있는 것과 복합적인 문제에 대해 어떤 경험을 갖고 있는지 파악할 수 있도록 해준다.

‘무엇을 좋아하나/무엇을 좋아하지 않나?’와 같은 질문을 통해 얻는 결과는 사실 SQL에 대해 묻는 것보다는 낫지만 모든 문제를 말끔히 해소하지는 못한다. 필자가 그동안 인터뷰했던 개발자들 중 70%가 아주 사소한 이슈에 대한 답변으로 일관했다. 그리고 10% 정도는 자신이 갖고 있는 낮은 수준의 ‘코드를 추가하는’ 중앙화된 관점이나 더 높은 수준의 사고가 결여돼 있다는 사실을 보여주는 답변을 했다.

결국 필자가 얻은 결론은 최고의 개발자를 찾아내는 것이 거의 불가능하다는 것이다. 실제로도 그동안 개발자가 고용 상태에 있을 때 최고의 개발자에 속한다고 필자가 인정할 수 있는 정도의 2~3명을 고용하는데 그쳤을 뿐이다.

더 나은 개발자 양성하기
탐구적이고, 교육으로 다져진 잠재력이 풍부한 개발자를 찾아내는 것은 쉬운 일이 아니다. 이러한 개발자들은 진정으로 자신의 삶과 다른 사람의 삶에 차이점을 만들기를 원한다. 이들은 아직까지 관계형 데이터베이스를 이해하지 못하고 있을 수도 있지만 진정으로 배우고자 하는 의지를 갖고 있다. 또한 주변 사람들에게 활력을 불어넣는 학습 프로세스에 열정을 부여한다. 

대부분의 조직에서 이런 열정은 적합이라는 미명 하에 묻혀버린다. ‘우리는 언제나 이런 방식으로 처리해’라는 사고는 더 나은 것들에 대한 시도를 무참히 짓밟아 버린다. 이 때문에 개발자들은 종종 자신이 속한 조직이 세계적인 수준의 개발팀(모든 기업이 이런 팀을 원한다)을 원하고 있다는 말과 자신들이 이런 수준에 도달하기 위해 변화되기를 원하지는 않는다는 현실 사이에서 혼란을 느끼게 된다. 

그러나 이러한 추진력과 갈망이 새로운 개발자들을 짓밟지 않도록 할 수 있는 몇 가지 방안이 있다. 더 나은 개발자를 양성하는 프로세스를 시작하는데 필요한 몇 가지 팁을 소개한다. 

멘토링 각 개발자들에게 도움을 주는 멘토를 할당하라. 멘토는 수석 개발자, 개발 리더, 혹은 팀, 프로세스의 향상과 다른 사람을 지원하기 위해 고민하는 아키텍트 중에서 선정해야 한다. 멘토가 해당 개발자의 직접 상사이거나 매니저여서는 안 된다. 멘토링 대화는 개발자가 무엇을 원하는지, 그리고 조직이 무엇을 원하고 필요로 하는지 등에 집중돼야 한다.

코드 리뷰 코드 리뷰는 누군가의 개발 지식을 긍정적인 방향으로 옮겨오기 위한 효과적인 방법이다. 대부분의 조직에서는 코드 리뷰를 자주 수행하지 않는다. 또한 학습을 위한 기회라는 차원에서 코드 리뷰에 접근하는 경우도 거의 드물다.
대신 코드 리뷰를 개발자를 비난하는 잣대로 이용한다. 개발자를 비난하기 위해서가 아니라 교육의 수단으로 코드 리뷰를 수행하고 코드 리뷰에 접근하라.

진보적인 경험 개발자들의 성장을 독려하기 위해 개발자들에게 의미 있는 과제를 부여하라. 대부분의 기업은 끊임없이 쏟아져 들어오는 프로젝트에 대해 최소한의 통제만을 하기 때문에 이 팁은 구현하기가 가장 어** 것 중 하나다. 그러나 진보적인 과제와 관련된 가능한 한 많은 구조를 제공하면 결국에는 보상으로 돌아올 것이다. 

배움에 대한 도전 과제 외에도 소프트웨어 개발자들을 적절하게 배치할 수 있는 다른 방법을 찾아보라. 개발자들에게 이 방법이 직접적으로 유용하지 않더라도 이렇게 하면 개발자들이 가능한 한 많은 것을 배울 수 있다. 만약 당신이 웹 개발 숍이라면 개발자들이 스마트 클라이언트 기술을 배우도록 독려함으로써 학습 특성을 공식화하라. 

조직 내에서 원하는 개발자를 양성하라
다음 프로젝트를 진행할 때 또다시 우수한 개발자를 필요로 하겠지만 최고의 개발자를 찾기란 쉽지 않다. 여러분 프로젝트의 성공 여부는 개발팀에 속한 개발자들의 어깨에 달려 있다. 개발자들이 훌륭하면 성공할 수 있는 기회도 더 많아진다. 그러나 여러분이 필요로 하는 충분히 숙련된 기초가 튼튼한 사람을 찾기는 어렵다. 여러분이 필요로 하는 개발자를 얻을 수 있는 유일한 방법은 조직 내에서 원하는 개발자를 양성하는 것이다.