방법론과 같이 원리들과 프로세스가 모여있는 이론을 적용할 때에,방법론에 따른 단순한 행동 패턴보다 그 내면에 존재하는 사상과 원리가 더 중요한 것은이러한 이유에서이다.
사상과 원리를 이해하면 최소한 무턱대고 따라하는 것과, 무턱대고 경우에 맞지 않는데도 그 원리를 적용하려고 부질없는 애를 쓰지 않아도 된다.
개발 방법론은 기본적으로 매 프로젝트의 성격에 맞게 수정이 된다.
(개발 프로젝트마다 프로세스 핸드북이 있는 것은 좋은 반증이다. 없는가? 없는 것은 정상이 아니다. 10개의 프로젝트를 보았는데 10개 다 프로세스 핸드북과 같은 것이 없어도? 적어도 10개 다 정상이 아니라고 본다. 명칭이 프로세스 핸드북이 아닐지라도 그와 비슷한 내용을 담고 있는 문서가 있으리라 본다. 그와 비슷한 내용을 담고 있는 문서가 없다면 정말 정상이 아니라고 본다.)
이 수정의 기본은 방법론에 존재하는 사상과 원리의 이해이다.그것을 바탕으로 지켜야할 원리 그리고 버려야할 원리를 프로젝트의 성격에 맞게발라내고 적용시켜야 하는 것이다. (여기서 그러면 매번 새로운 방법론을 만들지?라고 반문하는 사람이 있을지도 모르겠다. 그러나 있는 것을 수정하는 것과 새로운 것을만들어 내는 것은 하늘과 땅차이이며 feasibility 검증에 대한 이슈도 존재하므로 논의의 대상이 안될 것이다.)그리고 모든 개발자들에게 기본 사상과 이론을 알기쉬운 언어로 설명되는 것도 바로 이 수정의 단계에서 이루어진다.
이쯤에서 XP의 페어 프로그래밍에 대해서 좀 논의를 해보자.다른 방법론과 구별되는 독특한 원리이고, XP의 대표적인 원리이기도 하다.또한 불행인지 다행인지 모르겠지만 인터뷰한 대부분의 개발자들이 XP하면 이 페어 프로그래밍의 원리를 먼저 언급하였다.
이렇게 튀는 덕에 XP 중 가장 많은 논란의 대상이 되는 원리가 되었다.
반대에 서는 나름대로의 큰 목소리중의 하나는 혼자서 해도 되는 것을 왜 굳이 둘이서 하느냐는 것이다. 인건비의 손해요 시간과 노력의 손해가 아니냐는 것이다.
그리고 여기에 나오는 반론이 책에서 쓴 것처럼, 둘이서 하나의 코드를 만들게 되면에러를 줄일 수 있고 높은 품질의 디자인을 생산할 수 있으므로, 한명의 n만큼의 일을 할 수 있다면 2n + alpha의 효과를 볼 수 있다는 것이다.
나는 여기에 큰 모순이 있다고 생각한다.
코드를 생성하는 데에는 정말 혼자서 해도 되는 일이 있고, 둘이서 하면 시너지를 매우 볼수 있는 일이 있다. 즉 코드의 종류와 목적 등에 따라서 그때 그때 달라진다는 의견을 나는 가지고 있다.
1999년도 부터 불어닥친 IT 열풍으로 (누가 그랬던가 2003년까지 소프트웨어 개발 인력이5만명이상이 부족해질 것이라고..) 개발자 양성 학원이 강남에 우후죽순처럼 생겨났다.수없이 많은 비전공자들이 3개월에서 6개월 정도만 교육을 받고 소위말하는 프로그래머로 활동을 하게 되었다. 그로부터 지금까지 그 프로그래머들에게 무슨일을 해왔는지 묻고 싶다.(세계 시장 점유율 측면에서 한국에 제대로된 소프트웨어 개발을 하는 회사는 그리 많지 않아 보인다.)
안타깝게도 인터뷰에 응한 개발자 중 반 이상이, 자신이 하는 일은 아무나 할 수 있는 일이라고생각한다고 답했다. 즉 전문가로서의 특별한 자질이 없어도 누구나 한 3개월 정도의 직업 교육훈련만 받으면 할 수 있는 일이라고 답했다. 누구나, 그리고 아무나 할 수 있는 일이라서 자신이 오늘 밤을 새는 것이며, 고객의 높은 언성을 참고 있는 것이라는 대답을 하는 사람도 있었다.물론 자신만이 이 일을 제대로 할 수 있으며 자신보다 잘하는 사람을 보지 못했다는 개발자도 있었다.
이런 조사의 결과에서도 볼 수 있듯이, 자신도 아무나할 수 있고 누구나 알수 있다고 생각하는데 (주위 사람들도 모두 그렇게 생각하는데) 이런일을 둘이서 앉아서 개발할 필요는 없을 것이다.이런 경우에 XP를 적용한다고 무턱대고 둘이서 앉아서 개발을 한다고 들면 그리 좋은 결과를 기대하기는힘들 것이다. 당장 고객이나 상급 관리자로부터 질책을 말을 먼저 들을 것이다.
어떤 코드들이 이런 것인지에 대해서 여전히 논란이 많은 것이다. 구분이 매우 모호하기 때문이다.이때의 모호하다는 의미는 같은 종류의 코드라고 상황에 따라 페어 프로그래밍을 적용해야 할 때도 있고그럴필요가 없을 때도 혹은 적용하지 말아야 할 때가 있다는 것이다.
예를 들어보자. 최근 몇 년간 가장 많은 소프트웨어 개발자가 참여한 소프트웨어 개발은 아마도 SI소위 말하는 기업 환경에서 소프트웨어 통합 구축프로젝트일 것이다. 이 일에서도 가장 많은 비중을 차지 했던 것은 웹기반 개발이다. 웹기반 개발을 하나만 보더라도 매우 많은 종류의 코드들이 존재한다.
이중에서도 가장 많이 보는 두가지 예를 들면 웹개발 전체를 위한 framework의 개발이고 또하나는 이를이용한 웹페이지와 이 그면의 로직 개발이다. 많은 경우 전자는 페어 그래밍의 필요한 부분이고 후자는적용하지 않아도 되거나 공수가 모자라고 기간이 짧은 경우에는 적용하면 안되는 그러한 경우라고 할 수 있다.
시스템 소프트웨어의 코드, 재사용이 많이 필요한 기간 코드 등은 페어프로그래밍이 꼭 필요하다고 할 수 있다.반면, 화면 디자인과 관련된 코드, 일회성 하드웨어 드라이버 제작 등은 페어 프로그램이 필요 없다고 할 수 있다.
일회성이라고 하더라도 매우 중요한 하드웨어 제어 코드 (hard real time)등은 알고리즘이나 기본 수치분석 등이중요하므로 객제 지향 패턴(책에서 강조한)과 상관없이 페어 프로그래밍의 효과를 크게 볼 수 있다고 할 수 있다.
모든 것에는 trade-offs가 존재한다. 그때 그때 다른 것에 대해서 어찌할 지는 이 trade-off들을 고려하여 결정하는것이 좋다. 그러기 위해서는 페어 프로그래밍의 경우 그 사상과 그것을 통해 얻고자 하는 바, 다른 원리들과의관계등을 명확히 이해하여 trade-off를 분석하고 그에 따라 결정해야 할 것이다.
No comments:
Post a Comment