본 포스팅은 Code Complete 책이 지닌 정보를 재가공하여 올림을 알립니다.
안녕하세요 !
오늘은 Top Down vs Bottom Up을 주제로 들고 왔습니다.
Top Down, Bottom Up 개념의 경우 알고리즘 문제를 풀 때 많이 봐왔습니다.
Top Down은 재귀, Bottom Up은 DP에서 많이 등장하는 개념이죠.
그런데 오늘 제가 말할 이 두 가지 개념은 알고리즘이 아닌 소프트웨어 설계 범주에서 얘기드릴겁니다.
시작하겠습니다.
Top Down / Bottom Up의 접근 방법은 객체지향적인 설계를 작성하는 데 도움이 되는 통찰력을 제공해줍니다.
Top Down의 경우 높은 추상화 수준에서 시작합니다. 예를 들어서 화장실 변기 물을 내린다고 했을 때, '버튼을 누르면 물이 내려간다.'를 시작으로 설계를 시작하는거죠. 그리고 버튼을 누르면 레버가 움직이면서, 지렛대의 원리를 통해서 변기 내의 마개가 열리면서 미리 채워둔 물이 이동하면서 Blah Blah... 와 같은 구체적인 다른 설계 요소를 정의해나가는겁니다.
즉, 추상화로 시작하여 상세화 수준을 높이는 설계 방법입니다.
Bottom Up의 경우 구체적인 것부터 시작해서 일반적인 쪽으로 작업합니다. 미리 물을 채우고, 마개를 열고, 이 마개를 지렛대의 힘을 이용하고, 레버를 달고.... 해서 변기 버튼을 누르면 물이 내려간다 !!를 설게하는 것이죠.
즉, 구체적인 것부터 일반적인 것의 순서를 가진 설계방법입니다.
그래서 둘 중 뭐가 좋을까요?
Top Down / Bottom Up을 지지하는 양측 주장을 들어보겠습니다.
Top Down 측을 주장하는 G모씨
아니 Bottom Up 좋다고 치자. 근데 인간의 두뇌가 한 번에 집중할 수 있는 양에 한계가 있는데, 레버 생각하고, 지렛대 생각하고, 마개 생각하고, 물 채우는 거 등 그 많은 세부 사항을 처리하려고 하는게 솔직히 부담되지 않나?
그렇기 때문에 일반적인 클래스부터 시작해서 단계별로 클래스를 더 구체적인 클래스로 분해하는 방법을 하면 우리 두뇌가 좀 더 편하기 때문에 Top Down을 지지해야해 !
분할-정복 프로세스 알지? 이 것도 결국 Top Down이야 ! 결국 분해를 계속하다보면 설계가 분명해지고 작업이 완료될거야 !
Bottom Up 측을 주장하는 D모씨
Top Down은 솔직히 너무 추상적이야 ! 피보나치 생각해보자? n번째부터 재귀적으로 1번째까지 수를 체크하고 더해오는 것보다, 애시당초 1번째부터 n번째 수까지 더해오는게 좀 더 가시적이지 않아?
결국, 앞에 숫자를 더해가는거잖아 !? 즉, 이 시스템이 무엇을 해야하는지에 대해서 잘 알고 있기 때문에, 이렇게 짤 수 있었던거야 !
시스템에 필요한 저수준 책임을 알 수도 있는 좋은 기회가 되겠지 ! 보고서를 작성한다고 할 때, 프린터로 출력하고, 데이터를 계산하고, 제목을 중심에 맞추고, 화면에 보고서를 표시하는 등 시스템에 필요한 작업들을 시작부터 알 수 있는거잖아 !
과연 승자는?
두 논쟁에 대해서 들어봤습니다.
저들이 했던 얘기가 사실 다 맞는 말입니다. 중요한 차이는 전자는 분해 전략이고 후자는 결합 전략이라는 것이죠.
Top Down은 일반적인 문제에서 관리할 수 있는 조각으로 나누고, Bottom Up는 관리할 수 있는 부분에서 시작해 일반적인 솔루션을 구축하는 방식이죠.
모두 장단점이 있습니다.
Top Down의 장점은 설계가 쉽다는 것입니다. 사람들 특히 개발자는 큰 것을 작은 요소로 분해하는 것에 능숙하며, 세부 사항 구현을 미루면서 혼란스러워 지는 최하위 부분에 있는 클래스를 미룰 수가 있다는 것입니다.
Top Down의 단점은 시작이 간단하지만 저수준에서의 복잡성이 최상위 수준에 영향을 미치게 되어 필요 이상으로 복잡해질 수 있다는 점입니다. 재귀함수의 퍼포먼스가 좋지 않은 이유가 이 예가 되겠죠. 함수 하나하나의 요소 때문에 전체 시스템이 무너지니까요.
Bottom Up의 경우 일반적으로 필요한 기능을 초기에 파악할 수 있어서 간결하고 잘 구성된 설계가 만들어진다는 것입니다. 그렇게 하므로써 재사용 할 수 있는 기능들을 알 수 있고, 새로운 시스템의 설계에 큰 도움이 되겠죠.
Bottom Up의 단점은 이 접근 방법만 사용해서 개발하기 힘들다는 것입니다. 대부분의 사람은 작은 개념으로 큰 개념을 만드는 것보다 큰 개념을 가져다가 작은 개념으로 나누는 것을 더 잘합니다. 저희가 레고를 조립할 때 설명서대로 했는데, 항상 레고 부품이 남는 경우를 생각하면 ..... 아시겠죠? 또한, 이미 작은 것부터 시작한 설계가 원하는 프로그램에 도움이 안된다는 사실을 알게 되는 경우도 있습니다. 알고리즘 문제를 풀 때 잘 못된 DP를 도입했을 때 문제를 풀지 못하는 경우가 이 경우가 되겠죠.
결론
결론은 Top Down과 Bottom Up의 경우엔 배타적인 것이 아닌 상호 보완적인 개념입니다.
항상 옳은 솔루션은 존재하지 않죠. 그러니 설계를 함에 있어서 어떤 것이 좋은 지 생각을 해야하며, 많은 시행착오가 필요합니다.
그렇기 때문에, 두 개념을 확실히 알고 넘어가는 것이 설계에 큰 도움이 되겠죠.
이상 Top Down vs Bottom Up였습니다. ^_^
'개발 상식' 카테고리의 다른 글
| 객체지향의 사실과 오해 (1) (2) | 2021.08.15 |
|---|---|
| OOP (0) | 2021.03.14 |
| 부동 소수점의 한계 (0) | 2020.03.06 |
| 컴퓨터 공학에서 헤르츠(Hz)라는 단위 (0) | 2020.03.06 |
| 버전 표기법 (SemVer) (0) | 2020.02.14 |
