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

크고 중요한 프로젝트가 진행되던 중 갑자기 사방이 붕괴된다. 이리저리 꼬인 코드는 도저히 디버깅할 엄두가 나지 않는다. 유닛 테스트는 해본 적도 없고, 뭔가를 변경할 때마다 40여 명의 사람들이 모여 회의를 해야 한다.

 

만일 “고급” 개발자 10명으로 구성된 팀이 이 프로젝트를 맡았더라면 99.999%의 가용성으로, 두 배 더 많은 기능을, 절반의 시간에 구현할 수 있었을 것이다!

 

아니, 어쩌면 아닐 수도 있다. 고참 개발자들로 구성된 팀은 복잡한 설계만 만들 뿐 막상 코드를 내놓지 못하는 경우가 많다. 그 이유는 다음과 같다.

 

진실 1 : 고참 개발자는 비싸다

관리자는 소프트웨어 개발자 시장에 대해 잘못 이해하는 경우가 많다. 이들은 최고참 개발자 딱 10명만 애플리케이션 개발에 투입하면 무조건 성공한다고 생각한다. 또 이들은 시장 가격의 절반도 안되는 비용을 들여 고참 개발자를 채용하려 든다. 예를 들어 최고참 개발직의 경우 10만 달러로는 미국 어디에서도 인력을 구하기가 어렵다. 잘해봐야 1~2명의 고참 개발자와 허위 경력을 내세우는 8~9명의 거짓말쟁이들이 찾아올 뿐이다.

 

진실 2 : 절박한 상황이어야 최선을 다해 일한다

고참 개발자가 JSP 페이지를 단순 입력하는 작업을 한다면 사실 그 개발자의 능률은 신참 개발자보다 떨어진다. 고참 개발자의 경우, 성실한 사람이라 해도 이미 수없이 반복해온 입력 작업은 지겨울 수밖에 없고, 따라서 처음 몇 주가 지나면 설렁설렁 일을 하게 된다. 이런 일은 신참 개발자가 훨씬 더 열심히 한다.

 

진실 3 : 고참 개발자가 너무 많으면 배가 산으로 간다

만일 필자를 포함해서 고참 개발자들끼리 앞서 언급한 것과 같은 단순한 프로젝트를 진행한다면, 아마 지루함을 이기기 위해 아예 JSP 페이지를 사용하지 않는 방법을 찾아낼 것이다. 대신 JSP로는 절대 설계할 수 없는 강력하고 유연한 템플릿 시스템을 고안해낼 것이다.

 

광범위한 토론과 아키텍처 논의도 벌어진다. 아주 기본적인 B2B 웹 사이트 하나를 두고 복잡하기 이를 데 없는 아키텍처가 만들어진다. 왜냐고? 우리는 그렇게 할 수 있기 때문이다. 우리는 똑똑하고 일을 추진할 능력이 있다. 당연히 완벽하게 기능하는 프로그래밍을 설계할 것이다. 친구들에게 이 방법이 가능하단 것을 보여줄 기회이기 때문이다.

 

어쨌든 몇 가지 “자질구레한 일”과 “버그 사냥”은 여전히 필요하기 때문에, 우리는 시간외 근무를 하게 되고 수습 사원을 뽑아달라고 요청하게 된다. 결국 고참 개발자들이 특기인 화이트보드에 끄적거리기를 계속하는 동안 실질적인 프로젝트 업무는 대부분 똘똘한 수습 사원들 몇 명이 다 하게 된다.

 

억지 같다고? 1년 이상 지속된 수백만 달러 규모의 기업 웹 사이트 프로젝트에서 필자가 직접 목격한 광경이다. 필자는 비교적 최근 4명의 신참급 인력과 함께 소규모 팀으로 복잡한 B2B 포털 프로젝트를 수행했는데, 약 3개월 만에 작업을 마쳤다. 아직까지 두 가지 프로젝트의 ROI를 직접 비교해 본 사람은 없다.

 

진실 4 : 대부분의 고참 개발자는 사실 고참이 아니다

지금까지 회사에서 행한 면접에서 필자는 코딩도 할 줄 모르는 자칭 유능한 고참 개발자들을 적어도 열 명 이상 만났다. 대부분의 개발자는 자신을 과대평가하고 원하는 급여를 기준으로 자신의 직책을 정한다. 모나드와 하둡에 대해 이야기할 줄 안다고 해서 이런 것들을 언제, 어떻게 사용해야 하는지, 또는 어떤 경우에 사용하지 말아야 하는지(이게 더 중요함) 안다고 단정할 수는 없다. 심지어 단순한 SQL 문을 작성할 줄 안다는 것조차 보장할 수 없다.

 

필자 회사의 면접 과정에는 코딩 테스트가 있는데, 이 코딩의 요구 사항은 정말로 간단하다. 바로 “할머니가 사용할 주소록 만들기”다.

 

고참 개발자라면 요구 사항을 읽고 그에 따라 다른 사람이 보고 이해할 수 있는 합리적인 코드를 작성할 줄 알아야 한다. 소프트웨어를 설치하고 배포하는 방법에 대한 간단한 지침도 쓸 줄 알아야 한다. 그러나 면접에 임하는 사람들 대부분은 시작과 동시에 예외를 내뱉는 코드를 작성하며, 지침도 내용이 틀리는 경우는 그나마 나은 수준이고, 최악의 경우 무슨 말인지 알아볼 수조차 없는 난해한 지침을 써낸다.

진실 5 : 오만함에는 추락이 뒤따른다

필자는 극히 정교한 프로젝트가 아주 기본적인 부주의로 인해 실무 환경에서 장애를 일으키는 경우를 여러 번 봤다. 문제의 원인은 대부분 “훌륭한” 코드를 작성할 줄 알지만, 타이타닉호의 기술자들처럼 자신의 창조물은 결코 가라앉지 않는다는 확고한 믿음에 다른 가능성을 살펴볼 생각을 하지 않는 똑똑한 사람들이다.

 

자만은 개발자 세계에서 가장 두드러진 특징인데, 경험이 많다고 줄어들지도 않는 듯하다. 고참 개발자들의 경우 주변 사람들이 대단하다고 칭찬해 주면 안 그래도 나쁜 버릇이 더욱 나빠질 수 있다. 우리 고참들은 복잡성을 통제할 수 있다고 생각하고, 그래서 복잡하게 만든다. 검증되지 않은 기술이라도 상관없다. 철저히 테스트할 필요도 없다. 잘 작동될게 확실하다. 왜냐하면 고참인 우리가 만들었으니까!

 

말은 쉽지만 중요한 것은 결과다. 결과는 신중한 판단에 따라 선택한 방법과 재료에 의해 도출된다. 과학적인 방법에 따르려면 아는 것에 그치지 않고 그것을 증명해야 한다. 오만과 자만에 빠지면 증명하지 않고 믿으려 한다.

 

진실 6 : 개인이 최고의 가치는 아니다

프로젝트를 만드는 것은 여러 사람들로 구성된 그룹이다. 그룹은 유기적이고 동적이다. 그룹을 구성하는 개개인만큼 그룹 내의 상호 작용도 중요하다. 최고의 그룹은 구성원의 성장을 이끄는 그룹이다. 개발자들은 극단적인 개인주의에 빠지기 쉽고 항상 정당한 대우를 받지 못한다고 느낀다.

 

그러나 모든 것을 온전히 혼자서 배울 수는 없다. 누구나 다른 사람의 기술과 요령을 보고 배운다. 공식적인 멘토든 비공식적인 멘토든 이들은 경력에 중요한 영향을 미친다. 관리자 또는 수석 개발자가 할 수 있는 가장 중요한 일은 다른 사람을 가르치는 환경을 조성하는 것이다. 이렇게 해서 내부적으로 고참 개발자를 육성할 수가 있다.

 

고참 개발자에겐 제약이 필요하다. 시간과 예산이 정해져 있지만 복잡함이 계속 쌓여가면 그것도 강한 제약이 되지 못할 수 있다. 팀에 신참 개발자가 포함되면 이들은 복잡한 개발 방식을 따라가기는 데 어려움을 겪는다. 이것은 좋은 현상이다. 이들로 인해 단순함을 추구하는 분위기가 조성되고 단순함은 대부분 좋은 것이기 때문이다.

 

고참과 신참이 섞인 팀은 회사의 이익과 개발자들의 이익을 일치시킨다. 혼합 팀은 모두에게 경력을 쌓을 좋은 기회를 제공한다. 고참 개발자는 리더십 경험을, 신참 개발자는 새로운 것을 배울 기회를 갖게 된다.

재미있는 글이네요 ~

(http://www.itworld.co.kr/news/77598?page=0,1)