2012.09.03

고급 개발자에 대한 6가지 진실

Andrew Oliver | InfoWorld
크고 중요한 프로젝트가 진행되던 중 갑자기 사방이 붕괴된다. 이리저리 꼬인 코드는 도저히 디버깅할 엄두가 나지 않는다. 유닛 테스트는 해본 적도 없고, 뭔가를 변경할 때마다 40여 명의 사람들이 모여 회의를 해야 한다.
 
만일 “고급” 개발자 10명으로 구성된 팀이 이 프로젝트를 맡았더라면 99.999%의 가용성으로, 두 배 더 많은 기능을, 절반의 시간에 구현할 수 있었을 것이다!
 
아니, 어쩌면 아닐 수도 있다. 고참 개발자들로 구성된 팀은 복잡한 설계만 만들 뿐 막상 코드를 내놓지 못하는 경우가 많다. 그 이유는 다음과 같다.
 
진실 1 : 고참 개발자는 비싸다
관리자는 소프트웨어 개발자 시장에 대해 잘못 이해하는 경우가 많다. 이들은 최고참 개발자 딱 10명만 애플리케이션 개발에 투입하면 무조건 성공한다고 생각한다. 또 이들은 시장 가격의 절반도 안되는 비용을 들여 고참 개발자를 채용하려 든다. 예를 들어 최고참 개발직의 경우 10만 달러로는 미국 어디에서도 인력을 구하기가 어렵다. 잘해봐야 1~2명의 고참 개발자와 허위 경력을 내세우는 8~9명의 거짓말쟁이들이 찾아올 뿐이다.
 
진실 2 : 절박한 상황이어야 최선을 다해 일한다
고참 개발자가 JSP 페이지를 단순 입력하는 작업을 한다면 사실 그 개발자의 능률은 신참 개발자보다 떨어진다. 고참 개발자의 경우, 성실한 사람이라 해도 이미 수없이 반복해온 입력 작업은 지겨울 수밖에 없고, 따라서 처음 몇 주가 지나면 설렁설렁 일을 하게 된다. 이런 일은 신참 개발자가 훨씬 더 열심히 한다.
 
진실 3 : 고참 개발자가 너무 많으면 배가 산으로 간다
만일 필자를 포함해서 고참 개발자들끼리 앞서 언급한 것과 같은 단순한 프로젝트를 진행한다면, 아마 지루함을 이기기 위해 아예 JSP 페이지를 사용하지 않는 방법을 찾아낼 것이다. 대신 JSP로는 절대 설계할 수 없는 강력하고 유연한 템플릿 시스템을 고안해낼 것이다.
 
광범위한 토론과 아키텍처 논의도 벌어진다. 아주 기본적인 B2B 웹 사이트 하나를 두고 복잡하기 이를 데 없는 아키텍처가 만들어진다. 왜냐고? 우리는 그렇게 할 수 있기 때문이다. 우리는 똑똑하고 일을 추진할 능력이 있다. 당연히 완벽하게 기능하는 프로그래밍을 설계할 것이다. 친구들에게 이 방법이 가능하단 것을 보여줄 기회이기 때문이다.
 
어쨌든 몇 가지 “자질구레한 일”과 “버그 사냥”은 여전히 필요하기 때문에, 우리는 시간외 근무를 하게 되고 수습 사원을 뽑아달라고 요청하게 된다. 결국 고참 개발자들이 특기인 화이트보드에 끄적거리기를 계속하는 동안 실질적인 프로젝트 업무는 대부분 똘똘한 수습 사원들 몇 명이 다 하게 된다.
 
억지 같다고? 1년 이상 지속된 수백만 달러 규모의 기업 웹 사이트 프로젝트에서 필자가 직접 목격한 광경이다. 필자는 비교적 최근 4명의 신참급 인력과 함께 소규모 팀으로 복잡한 B2B 포털 프로젝트를 수행했는데, 약 3개월 만에 작업을 마쳤다. 아직까지 두 가지 프로젝트의 ROI를 직접 비교해 본 사람은 없다.
 
진실 4 : 대부분의 고참 개발자는 사실 고참이 아니다
지금까지 회사에서 행한 면접에서 필자는 코딩도 할 줄 모르는 자칭 유능한 고참 개발자들을 적어도 열 명 이상 만났다. 대부분의 개발자는 자신을 과대평가하고 원하는 급여를 기준으로 자신의 직책을 정한다. 모나드와 하둡에 대해 이야기할 줄 안다고 해서 이런 것들을 언제, 어떻게 사용해야 하는지, 또는 어떤 경우에 사용하지 말아야 하는지(이게 더 중요함) 안다고 단정할 수는 없다. 심지어 단순한 SQL 문을 작성할 줄 안다는 것조차 보장할 수 없다.
 
필자 회사의 면접 과정에는 코딩 테스트가 있는데, 이 코딩의 요구 사항은 정말로 간단하다. 바로 “할머니가 사용할 주소록 만들기”다.
 
고참 개발자라면 요구 사항을 읽고 그에 따라 다른 사람이 보고 이해할 수 있는 합리적인 코드를 작성할 줄 알아야 한다. 소프트웨어를 설치하고 배포하는 방법에 대한 간단한 지침도 쓸 줄 알아야 한다. 그러나 면접에 임하는 사람들 대부분은 시작과 동시에 예외를 내뱉는 코드를 작성하며, 지침도 내용이 틀리는 경우는 그나마 나은 수준이고, 최악의 경우 무슨 말인지 알아볼 수조차 없는 난해한 지침을 써낸다.
 



2012.09.03

고급 개발자에 대한 6가지 진실

Andrew Oliver | InfoWorld
크고 중요한 프로젝트가 진행되던 중 갑자기 사방이 붕괴된다. 이리저리 꼬인 코드는 도저히 디버깅할 엄두가 나지 않는다. 유닛 테스트는 해본 적도 없고, 뭔가를 변경할 때마다 40여 명의 사람들이 모여 회의를 해야 한다.
 
만일 “고급” 개발자 10명으로 구성된 팀이 이 프로젝트를 맡았더라면 99.999%의 가용성으로, 두 배 더 많은 기능을, 절반의 시간에 구현할 수 있었을 것이다!
 
아니, 어쩌면 아닐 수도 있다. 고참 개발자들로 구성된 팀은 복잡한 설계만 만들 뿐 막상 코드를 내놓지 못하는 경우가 많다. 그 이유는 다음과 같다.
 
진실 1 : 고참 개발자는 비싸다
관리자는 소프트웨어 개발자 시장에 대해 잘못 이해하는 경우가 많다. 이들은 최고참 개발자 딱 10명만 애플리케이션 개발에 투입하면 무조건 성공한다고 생각한다. 또 이들은 시장 가격의 절반도 안되는 비용을 들여 고참 개발자를 채용하려 든다. 예를 들어 최고참 개발직의 경우 10만 달러로는 미국 어디에서도 인력을 구하기가 어렵다. 잘해봐야 1~2명의 고참 개발자와 허위 경력을 내세우는 8~9명의 거짓말쟁이들이 찾아올 뿐이다.
 
진실 2 : 절박한 상황이어야 최선을 다해 일한다
고참 개발자가 JSP 페이지를 단순 입력하는 작업을 한다면 사실 그 개발자의 능률은 신참 개발자보다 떨어진다. 고참 개발자의 경우, 성실한 사람이라 해도 이미 수없이 반복해온 입력 작업은 지겨울 수밖에 없고, 따라서 처음 몇 주가 지나면 설렁설렁 일을 하게 된다. 이런 일은 신참 개발자가 훨씬 더 열심히 한다.
 
진실 3 : 고참 개발자가 너무 많으면 배가 산으로 간다
만일 필자를 포함해서 고참 개발자들끼리 앞서 언급한 것과 같은 단순한 프로젝트를 진행한다면, 아마 지루함을 이기기 위해 아예 JSP 페이지를 사용하지 않는 방법을 찾아낼 것이다. 대신 JSP로는 절대 설계할 수 없는 강력하고 유연한 템플릿 시스템을 고안해낼 것이다.
 
광범위한 토론과 아키텍처 논의도 벌어진다. 아주 기본적인 B2B 웹 사이트 하나를 두고 복잡하기 이를 데 없는 아키텍처가 만들어진다. 왜냐고? 우리는 그렇게 할 수 있기 때문이다. 우리는 똑똑하고 일을 추진할 능력이 있다. 당연히 완벽하게 기능하는 프로그래밍을 설계할 것이다. 친구들에게 이 방법이 가능하단 것을 보여줄 기회이기 때문이다.
 
어쨌든 몇 가지 “자질구레한 일”과 “버그 사냥”은 여전히 필요하기 때문에, 우리는 시간외 근무를 하게 되고 수습 사원을 뽑아달라고 요청하게 된다. 결국 고참 개발자들이 특기인 화이트보드에 끄적거리기를 계속하는 동안 실질적인 프로젝트 업무는 대부분 똘똘한 수습 사원들 몇 명이 다 하게 된다.
 
억지 같다고? 1년 이상 지속된 수백만 달러 규모의 기업 웹 사이트 프로젝트에서 필자가 직접 목격한 광경이다. 필자는 비교적 최근 4명의 신참급 인력과 함께 소규모 팀으로 복잡한 B2B 포털 프로젝트를 수행했는데, 약 3개월 만에 작업을 마쳤다. 아직까지 두 가지 프로젝트의 ROI를 직접 비교해 본 사람은 없다.
 
진실 4 : 대부분의 고참 개발자는 사실 고참이 아니다
지금까지 회사에서 행한 면접에서 필자는 코딩도 할 줄 모르는 자칭 유능한 고참 개발자들을 적어도 열 명 이상 만났다. 대부분의 개발자는 자신을 과대평가하고 원하는 급여를 기준으로 자신의 직책을 정한다. 모나드와 하둡에 대해 이야기할 줄 안다고 해서 이런 것들을 언제, 어떻게 사용해야 하는지, 또는 어떤 경우에 사용하지 말아야 하는지(이게 더 중요함) 안다고 단정할 수는 없다. 심지어 단순한 SQL 문을 작성할 줄 안다는 것조차 보장할 수 없다.
 
필자 회사의 면접 과정에는 코딩 테스트가 있는데, 이 코딩의 요구 사항은 정말로 간단하다. 바로 “할머니가 사용할 주소록 만들기”다.
 
고참 개발자라면 요구 사항을 읽고 그에 따라 다른 사람이 보고 이해할 수 있는 합리적인 코드를 작성할 줄 알아야 한다. 소프트웨어를 설치하고 배포하는 방법에 대한 간단한 지침도 쓸 줄 알아야 한다. 그러나 면접에 임하는 사람들 대부분은 시작과 동시에 예외를 내뱉는 코드를 작성하며, 지침도 내용이 틀리는 경우는 그나마 나은 수준이고, 최악의 경우 무슨 말인지 알아볼 수조차 없는 난해한 지침을 써낸다.
 

X