'계획-구현'(plan-and-implement) 방법론은 댐을 건설한다던가 국가를 침공하는데에는 훌륭한 방법이 될 수 있지만, 경험상 프로그래밍을 하는데는 좋은 방법론 같지는 않다. 

어째서? 

아마도 컴퓨터가 너무나 엄격하기 때문일 듯 싶다. 각각의 프로그램들간의 차이가 댐들이나 침공들 끼리의 차이보다 더 심하기 때문일 듯 싶다. 또는 아마도 여분을 남기는 것과 같은 오래된 행태는 소프트웨어 개발에서는 없기 때문에 옛날 방법론은 먹히지 않는다: 댐 건설시 30% 의 콘크리트를 더 가지고 있는 것은 실수에 대비한 방법이지만, 프로그램에서 30% 더 일을 한다는 것은 명백한 실수다. 

왜 오래된 방법론들이 실패했는지 말하기는 어려울 수도 있다. 하지만 그 방법론들은 명백히 실패했다. 누구나 실패한 것을 보지 않았는가? 언제 소프트웨어가 제때 개발되었는가? 경험 많은 프로그래머들은 아무리 조심스럽게 프로그램을 계획한다고 해도 막상 프로그램을 만들 때 계획은 예기치 못한 방향으로 바꿔버린다는 것을 알고 있다. 더구나 때때로 계획이란 것은 말도 안되게 잘못되어 버린다. 그러나 '계획-구현'(plan-and-implement) 방법론의 희생자중 극소수만이 기본적인 적합성에 의문을 가진다. 대신에 대부분의 사람들은 사람의 실수를 비난한다: 만약 계획이 더 많은 예측을 바탕으로 만들어 졌다면 이런 모든 문제들은 다 피해갈 수 있었을텐데.. 아무리 최고의 프로그래머라 할 지라도 '구현'단계로 접어들면 문제에 봉착한다. 아마도 사람들에게 그 이상으로 더 예측을 하라는 것은 너무 많은 기대를 가지는 것일 지도 모른다. '계획-구현'(plan-and-implement) 방법론은 우리의 한계에 더 잘 맞는 방법론으로 바꿔야 할지 모른다. 


폴 그레이엄의 Onlisp 책에서 언급되는 내용입니다. 이 책이 쓰여질 당시에 저는 졸업도 하기 전이였는데도 '계획-구현' 방법론을 옛날 방법론으로 치부하고 있습니다. 그 뒤로 애자일이니 래피드니 수많은 방법론들이 나왔지만 현실속에서 적용하기가 얼마나 쉬웠습니까? 석학들이 해외에서 95년도 쯤에도 이미 워터폴이니 뭐니 하는 소프트웨어 공학의 방법론들이 건설회사 방식에서 차용됐기 때문에 소프트웨어 개발에는 알맞지 않다고 이야기 해왔지만 습관이 참으로 무섭다는 생각이 듭니다. (10여년간 옛날 방식으로 꾸준히 개발되어 왔다는 이야기..) 

지금도 국내 굴지의 대기업과 개발을 진행하고 있는데, 개발 방향을 정하는 회의가 잡혔습니다. 이제 거기서 개발 진행이 결정되면 변경사항이 있을 수도 있을 것입니다. 그러나 이미 개발은 완료를 향해 나아가고 있습니다. 얼마나 세세한 계획을 요구하는지는 대기업 SI 회사들과 일해 보신 분들이라면 누구나 공감하실 것입니다. 하지만 그 시간에 개발에 총 집중을 한다면 또한 얼마만큼 빠르게 개발을 진행할 수 있는지도 잘 아실 것입니다. 

이제 진정한 소프트웨어 개발 방법론이 필요할 때라 생각합니다. 폴 그레이엄이 평소에도 계속 주장하듯이 'Bottom-Up' 방식도 또 하나의 대안이 될 수 있으며, 이 새로운 방법론에 대한 가능성은 소프트웨어를 개발하는 방법의 수만큼 많으리라 봅니다. 

+ Recent posts