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

어째서? 

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

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


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

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

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


폴 그레이엄 지음
임백준 역

세세한 내용을 다루기에는 그가 다룬 주제가 너무 많습니다. 학교, 일, 프로그래밍 언어, 사업, 스타트업(실리콘 밸리에서 말하는 우리나라식 벤쳐) 물론 그 주제들이 제 생활과 많이 맞 물리는 게 있어서 많이 고개를 끄덕거리며 보긴 했습니다. 너무나 절절히 공감이 가는 글들 이군요.

'해커와 화가' 라고 멋진 이름을 달고 있지만, 사실상 그것은 챕터2의 에세이 제목입니다. 이 책은 '폴 그레이엄'의 전형적인 수필집이라고 볼 수 있습니다. 그 내용이 공감은 가지만 탁 들었을때 폴 그레이엄 이름이 귀에 와 닿는 사람이 아닌 이상 수필집으로서 인기는 그리 보장되지 않는다고 봐야합니다.

게다가 너무 주제가 산만합니다. 한가지 주제만 중점적으로 다루었으면 좋겠지만 그러기에는 그가 한 분야에 집중적으로 글을 남긴 분량이 안되나 봅니다. (이건 책을 미루어 보아 생각해봤습니다.)

그래서 제가 굳이 있는 내용 없는 내용 다 보태서 끌어내자면 전반적으로 책에 흐르는 주요 내용은 '스케치' 입니다. 얼마만큼 빠르게 스케치를 (그림이 됐던 프로그래밍이 됐던 사업이 됐던) 이끌어 내고 그것을 수정해 나가는 것인가가 그의 화두 라고 볼 수 있습니다.전산적이나 디자인적 용어로 표현하자면 '프로토타입' 입니다. 그 '스케치'를 토대로 상향식으로 모든 것을 쌓아나가야 한다는 것이 주제입니다.

참으로 지혜란 알고 있어도 실행하기가 어려운 것인데, 그는 이 '스케치'의 지혜를 인생 전반에 잘 활용해서 정말 멋진 인생을 살았습니다. 그런 그가 자신의 인생 전반을 '스케치'하듯 담담하게 그려나간 것이 이 수필집입니다.


EDITED 2012-08-27


다시 보게 되니 그의 탁월한 식견에 감탄을 금치 못하겠습니다. 마치 하수가 고수의 너무나 당연하게 이야기 하는 것에 당연하지 않는가?!! 라고 반발하듯이 생각했었던 예전이 부끄러워 지더군요. 

여러 많은 에세이 가운데서 공통적으로 이야기 하고 있는 것이 있습니다.

'스케치' 와 '바텀-업 (Bottom-Up)' 입니다.

일을 해 감에 있어서 스케치 하듯이 조금씩 조금씩 완성해 나가야 한다. 어떠한 복잡한 프로젝트라도 바텀-업 스타일로 한시간에 해 낼 수 있는 일들을 조금씩 조금씩 완성해 나가야 한다는 것. 두개는 살짝 다른 듯 하지만 그레이엄이 말하고자 하는 바로서는 같게 볼 수가 있는 것입니다.

얼마나 탑-다운(Top-down) 방식으로 일을 진행하다가 많이 망했는지에 관한 이야기도 언급이 되어 있습니다.  다시금 CS (Computer Science) 쪽 일에 관한 마음가짐을 새로 할 수 있어서 좋았던 시간입니다.


+ Recent posts