주 20시간? 파격적인 구인 글에 깜짝 놀랬고 주변 사람들까지 불러서 이런 곳이 정말 있을까 하고 구경했다(일부는 어제 새벽까지 작업한 사람들 -.-;;). 현재 내가 있는 곳뿐 아니라 지금까지 어느 곳에서도 받아본 적이 없는 제안이다. 시간만 좋다면 XP를 제대로 배울 수 있도록 지원해보는 것도 좋겠다는 생각이 들었다. 이런 도전은 정말 필요한 것이기 때문이다.

  이 글에 관해서는 류한석 님의 글(http://bobbyryu.blogspot.com/2007/02/20.htm)은 사람 종류(인용이기는 하지만 인적 자원이란 단어는 기분이 별로다)에 따른 차별적인 적용의 필요성을 강조하였다(블로그 타이틀이 “PeopleWare”라니 과연. ).

본인의 시각으로 보자면 우선 20시간이라는 것은 상당히 상징적이고 무엇인가 근거가 있어서 나온 것으로 생각된다. 하지만 실제로 중요한 것은 결과가 될 것 같다. 남들이 60~80시간 기준으로 일할 때 20시간으로 충분하다고 말할 수 있으려면 그만한 과정과 산출물이 따라야 한다. 이것은 능력이 뛰어나거나 접근 방법을 달리하면 해결되는 것으라고 말할 수도 있다. 하지만 현실적으로는 일의 종류에 따라 달라질 수 있으며 누구나 다 20시간으로 고용한 사람을 설득할 수 있다고 생각되지 않는다. 좀 더 생각해보면 이런 사고 방식이 통하는 것은 전략이나 분석을 담당하는 컨설팅 쪽이 가장 적합하다고 보여진다. 폭 넓게 살피고 올바른 길을 찾아야 하는 안내자의 역할이기 때문이다. 반면에 아래로 내려가면 내려갈 수록 이 것이 과연 가능한지는 의심스러워진다. 예를 들어 복잡한 설계나 모델링을 하는 사람의 경우 하루 최대 5~6시간까지 집중해서 작업을 할 수 있고 나머지는 회사의 자잘한 일을 처리한다. 더 특이한 종류의 작업도 있다. 통합, 배포, 테스트 등등은 얼마나 머리를 잘 쓰는가 보다는 오로지 시간과 끈기로 승부해야 한다. 현재까지는 말이다. 이 사람들에게 일주일 20시간 적용은 당연 불가해 보인다.

  현재 기존 폭포수 모델, CBD에 기반한 복잡한 방법론이 문제를 일으키는 것은 현실에 맞지 않으며 이런 방법론 자체의 완성도, 수행하는 사람들의 실력에 문제가 있기 때문이다. 결국 결론은 항상 기한에 맞추지 못하고 기능과 성능은 예상에 크게 못 미친다. 개발자들은 야근에 시달리고 말이다. SE에서는 이런 문제를 좀 더 정교한 방법, 보다 고도화된 방법론으로 해결하려고 시도하고 있으며 물론 현재도 진행 중이다. 이 방법론의 신봉자들은 제대로 방법론을 이해하지 못하는 인력과 잘못된 프로젝트 환경 에서 문제의 원인을 돌리고 있다. 하지만 지금은 많은 사람들이 “방법론은 맞는데 우리가 잘못하는 것”이라는 의견에 점점 의문을 품고 있고 있는데 그 중에는 XP 방법론에 수긍하는 사람들이 많을 것이다. 이러한 흐름에 XP가 좀 더 확실하게 이의를 제기하려면 그만한 근거와 실력이 있어야 한다고 본다. 즉, 어떻게 이것을 바꿀 수 있는지를 얘기해야 하고 실제 보여줄 수 있어야 하는 것이다. 본인이 알고 있는 것이 옳다면 대형이 아니더라도 많은 프로젝트에서 거의 XP가 받아들여지지 않는 것은 이 부분에서 설득력이 부족하기 때문이 아닐까 한다.

  위 사이트도 마찬가지로 보인다. 문제가 있으니 바꾸고 싶다는 열의는 느낄 수 있으며 많은 사람들이 동감할 만한 내용이고 충분히 자극적이다. 하지만 “어떻게?”라는 질문에는 적절한 답을 하고 있다고 보이는 글은 별로 없는 것 같다. 전 개발 라이프 사이클에 적용할만한 정교한 방법론도 없는 것 같고 이 방법론에서 정의한 아키텍처에 맞추어 툴과 개발 환경을 설정할 수 있는 가이드도 없는 것 같고 말이다. 덧붙여 XP/Agile 마인드의 개발자나 아키텍트도 드물다. 이런 상황이면 당연히 좋은 지표가 될만한 프로젝트가 되기는 상당히 어려워 보인다.

  덧붙여 원본의 글은 “20시간”이라는 파격적인 제안을 하고 있다. 글 자체만 보면 과정을 바꿈으로써 결과를 바꿀 수 있다고 생각한다는 느낌이 든다. 하지만, 본인 생각에 XP는 현실과 결과에 매우 집중하는 방법론이고 거기에서 모든 것이 시작되었다고 본다. 현재의 방법론이 어느 정도 잘 돌아가면 모를까 과정이나 일하는 방식에 대해서 XP가 설득력을 가지는데 것은 그다지 많은 것을 보여줄 필요도 없지 않을까. 예를 들어 10~50명, 1년 정도의 프로젝트에서 정시 출퇴근, 행복한 개발자, 원활한 의사 소통, 투명한 프로젝트 진행 이 정도만 잘 보여줘도 사람들이 놀랄만하다. 하지만 얼마나 뛰어나고 쉽게 파악되고 관리될 수 있는 산출물을 만들어냈는지는 다른 예기이다. 새로운 시도라면 파격보다는 멋진 결과를 보여주는 것이 좀 더 중요하다고 생각한다. 물론 좋은 결과는 기본이고 과정도 파격이라면 말할 나위도 없지만 말이다.