좋은 개발자란

효율이 좋다고 평가받는 개발자가 있다고 하자. 이 개발자에게 일을 시키면 예상한 기간보다 하루나 이틀 정도 빨리 끝나고, 품질도 예상한 수준과 비슷하거나 조금 높다. 기간과 결과만을 가지고 이 개발자를 평가하자면, 상당히 좋은 개발자임이 틀림 없다. 그런데 이 개발자가 일하는 방식을 살펴 보면 평가가 달라질 수 있다. 자신의 신념일 수도 있고, 일종의 버릇에서 비롯된 것일 수 있는데, 이 개발자는 절대로 IDE와 같은 개발도구를 사용하지 않는다. 오로지 윈도 메모장만을 사용해서 개발을 한다고 하자.

메모장도 나쁜 도구는 아니지만, 일반적인 에디터 도구나 IDE를 사용하면 쉽게 할 일도 윈도 메모장을 사용하면 손이 많이 간다. 예를 들어 모든 파일에서 변수 이름을 바꾸는 작업을 한다면, 에디터 도구에서 프로젝트 전체 바꾸기를 사용하거나 IDE의 리팩토링 기능을 사용해서 쉽게 바꿀 수 있다. 하지만 윈도 메모장에서는 파일을 일일이 열어서 바꾸기 기능을 사용해, 변수 이름을 바꾸는 일을 해야 한다. 어떻게 보면 변수 이름을 바꾸는 작업은 처음부터 모든 것?을 잘 고려했다면 하지 않을 일이니, 이 개발자에게 해당하지 않을 것이다.

하지만 모든 것을 예측하고 한다는 것은 인간에게 불가능한 일로, 만에 하나 변수 이름을 프로젝트 전체에 걸쳐서 바꿔야 한다면, 이 개발자는 순간적으로 효율이 떨어질 수 있다. 물론 이런 독특한 작업방식을 고수하고도 약속된 날짜보다 일찍, 예상되는 품질보다 더 우수한 코드를 만들어 내니 상당한 능력임에 틀림없다. 하지만 이 개발자가 그럭저럭 쓸만한 개발도구를 사용한다면 그 결과는 어떨까? 이 결과는 누구나 쉽게 예측할 수 있다.

앞에서 든 가상의 개발자는 현실에 있지 않을 것이다. 설명하기 위해 만들어 낸 예로서 상당히 허구적이다. 하지만 현실로 눈을 돌려 보면 정도의 차이는 있지 이 개발자와 일하는 방식이 크게 다르지 않은 동료 개발자들을 주위에서 찾아 볼 수 있다. 개발을 하면서 늘상 접하는 것이라서 개선의 의지를 느끼지 않는 경우가 많은 것 같다. 컴파일 시간이 느려서 결과를 확인하는 데 시간이 오래 걸린다거나, 개발환경이 자동화될 수 있음에도 늘 하던 일이라 불편을 느끼지 않아 수작업으로 하는 경우가 여기에 해당한다.

사실 이런 일들은 참을성을 가지고 기다리거나 수작업으로 무척 많이 해서 달인의 경지에 오른다고 해도, 개인적인 삶의 복지 향상이나 회사의 생산성 향상에 도움이 되지 않는다. 오히려 기다리는 시간이 반복되고 같은 작업을 어제도 하고 오늘도 수작업으로 한다면, 분명히 개선할 점이라고 느껴야 한다. 물론 이런 고난과 역경을 이겨내고도 정해진 날짜와 예상되는 품질로 결과물을 만들어 낼 수 있다,하더라도 우리가 흔히 말하는 좋은 개발자의 덕목에서 부족함이 확실히 있다. 생각해 보자! 지난주에 했던 수작업, 오늘도 수작업으로 하고 있지는 않는지 말이다.

글 : 신승환
출처 : http://goo.gl/3Kc0B8