땅콩버터와 마천루..
혹시 소프트웨어를 만드실때, 땅콩버터 방식으로 만드시지는 않나요?
땅콩 버터라는 것은 Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스를 말합니다.
Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들때 주로 사용하는 방법입니다.
이 방식은 견고하고, 더디지만 모든 Feature들이 골고루 기능 향상을 가져올수 있는 장점이 있습니다. 마치 땅콩 버터 (Peanut Butter) 처럼 모든 기능들이 골고루 퍼지고 진화할수 있어서 땅콩 버터 방식이라고 말합니다. 흔히 하위 레벨의 Framework이나 저수준의 Library를 개발할때는 이러한 방식이 선호 됩니다.
만약 여러분의 소프트웨어가 고객의 요구사항들을 많이 받아 들여야하고, 다양한 시나리오를 요구하는 경우인데도, Feature 에 초점을 맞춘 땅콩버터 식의 프로세스와 조직을 구성하게 되면 어떻게 될까요? 국내의 많은 회사들이 이러한 구조를 가지고 있는데요. 새로운 시나리오가 탄생하면 많은 조직들이 협업을 해야 될뿐만 아니라, 딱 기능을 나누기에 애매한 경우 많은 정치, 책임의 분배 문제등이 발생됩니다.
반면에 이와 상반된 방식으로 마천루 (Skyscraper) 방식이 있습니다. 
시나리오가 마천루처럼 높이 솟아 전체 소프트웨어의 기능을 구현하기 위한 좋은 기준이 된다는 것입니다. 명백한 기준이 있다는 것은 많은 시행착오를 줄일수 있을 뿐만 아니라. 고객의 관점에서 소프트웨어를 생각할수 있는 장점을 가질수 있습니다. 흔히 우리가 알고 있는 시나리오를 만들고 Protoype 방식으로 개발을 해 나가는 것이라고 생각하시면 됩니다.
바로 Top-Down 방식의 프로세스가 여기에 해당되어 지는데요. 여러분의 소프트웨어가 상위 레벨의 응용 소프트웨어로써, 많은 분들이 사용한다면 당연히 시나리오 기반( Sckscraper)의 방식으로 소프트웨어를 설계하는 것이 좋을 것입니다.
마이크로소프트의 VS2008 경우 개발자와 디자이너간의 협업에 중점을 두고 많은 시나리오를 만든 다음 제품을 개발했다고 합니다.
역시 이 방식도 단점이 있는데, 시나리오 기준으로 하다 보니 소프트웨어가 잘 정리된 일괄적인 구조로 설계 되기 어렵고, 특정 Feature들이 먼저 개발되는 급성장으로 인해 전제 모듈간의 불균형을 야기시킬수 있습니다. 그리고 갑자기 시나리오가 수정된다면, 이것이 소프트웨어 구조에 많은 영향을 미치게 됩니다.
바로 땅콩버터가 언급하는 점진적이면서 균형있는 발전이라는 장점을 잃어버리게 됩니다.
그럼 둘다 장,단점이 있는데 ,단점을 상쇄 시키고 장점을 얻을려면 어떻게 해야 될까요? 정답은..이것들을 적절히 혼용하는 것이겠죠 ^^
이전 포스팅인 “Microsoft 가 좋은 소프트웨어를 만들수 밖에 없는 이유“에서 언급한 것과 같이 땅콩 버터 (기본적인 기능부터 구현해서 점진적으로 기능을 추가) 방식을 유지하되, 릴리즈가 거듭될때마다 더불어 사용 가능한 시나리오들을 점진적으로 증가시켜 테스트하는 방식이 좋은 예가 될것입니다.
물론 이러한 프로세스를 하기 이전에 잘 정의된 계획과 합리적인 조직 구조가 기반이 되어야 가능한 방식일 겁니다.
회사에 말단으로 있을때는 단순히 설계에만 관심을 가졌는데. 요즘은 더욱더 프로세스의 중요성을 깨닫게 됩니다.
혹시 이글을 읽는 분중에, 마천루 또는 땅콩버터 + 마천루를 결합한 프로세스를 경험하신 분이 있으시면 여러분의 이야기를 저에게도 들려주시겠습니까? ^^
Architecture 101 
데브피아에서 올라온 피드백
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=4243&MAEULNO=4&no=36465
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=70&MAEULNO=4&no=172&page=1
[…] 포스트인 땅콩 버터와 마천루나 Conway의 법칙에서 언급한 것과 같이 우리가 설계하고자 하는 최종 S/W를 […]
[…] 땅콩버터와 마천루 […]
They can search for food in their environment. ,
your comment is very impressive.
I just help junior programmer.
recipes are very various. this idea is just my recipe.
[…] 그럼 팀 역시 시나리오나 Feature별로 구성되어야 합니다. 이 이야기는 땅꽁버터와 마천루 (https://arload.wordpress.com/2008/05/20/peanutbutter/ )를 읽으면 이해가 되실겁니다. […]
[…] 땅콩버터(Peanut Butter)는 ‘Feature들이 중심이 되어 소프트웨어를 만드는 Bottom-Up 방식의 프로세스’를 말합니다. Bottom-Up 프로세스는 기존의 비교 대상도 없고, 전혀 새로운 소프트웨어를 만들 때 주로 사용하는 방법입니다. 이 방식은 견고하고 더디지만 모든 Feature들이 골고루 기능 향상을 가져올 수 있는 장점이 있습니다. 실제 땅콩버터처럼 모든 기능들이 골고루 퍼지고 진화할 수 있어서 땅콩버터 방식이라고 말합니다. 흔히 하위 레벨의 프레임워크나 저 수준의 라이브러리를 개발할 때는 이러한 방식이 선호됩니다. […]
[…] 그림 5가 더 쉽게 이해 될것으로 보이며, 딱 맞는 비유는 아이지만 땅콩버터와 마천루라는 필자의 글을 보면 이해할수 있을 […]