분할정복(divide & conquer)은 보통 알고리즘에 많이 쓰이는 방식으로
문제를 분할하여 해결한뒤 종합하는 방식을 말한다.
다른 분야에서도 이 접근 방식은 많이 쓰이는데 해결하려는 문제가 너무 큰 경우에
그 문제를 다루기 쉽게 적절히 나눈 뒤 풀어낸 결과를 종합하여 결론을 냄으로서 아무리
큰 문제도 해결 할 수가 있다.
보통의 문제는 이 방식으로 효과를 볼수가 있는데 큰 프로젝트를 진행하거나 계획을 짤 때 쓰이는
방식도 일종의 분할정복이라고 볼수가 있다.
그런데 이 방식은 몇가지 문제를 포함하고 있는데, 분할된 작은 프로세스들간의
숨겨진 영향 및 관계가 있을 경우 이런 접근 방식으로도 풀어내기 힘들수가 있다는것이다.
예를들면 프로그램에 버그가 있어 그 디버깅을 할 경우에 ,
만약 프로그램의 전체 행수가 1024라인 이라면 분할정복을 통해 전체 행수를 2로 나누어
접근하면 2의10승 즉 10번의 확인을 통해 버그가 난 장소를 찾을수가 있다.
그런데 이건 이론적인것이고 실제로는 A -> B -> C -> D 의 프로세스에서
A의 버그가 D의 프로세스의 원인이 될 수가 있다. 이런 경우에는 방금 말한 방식으로 버그가 난 장소는 찾을수
있겠지만 A와의 관계까지는 파악하기 힘들다. 아마 더욱 더 많은 시간을 투자해야 발견할수 있을것이다.
마찬가지로 프로젝트를 진행하거나 일정을 수립함에 있어 각 프로세스간의 관계를 고려하지 않고
단순히 분할하여 정리하려한다면 차후 전체적인 지연에 있어서 대응은 물론 그 원인조차 파악하기
힘들어질수가 있다.
...라고 잠깐 단상.
문제를 분할하여 해결한뒤 종합하는 방식을 말한다.
다른 분야에서도 이 접근 방식은 많이 쓰이는데 해결하려는 문제가 너무 큰 경우에
그 문제를 다루기 쉽게 적절히 나눈 뒤 풀어낸 결과를 종합하여 결론을 냄으로서 아무리
큰 문제도 해결 할 수가 있다.
보통의 문제는 이 방식으로 효과를 볼수가 있는데 큰 프로젝트를 진행하거나 계획을 짤 때 쓰이는
방식도 일종의 분할정복이라고 볼수가 있다.
그런데 이 방식은 몇가지 문제를 포함하고 있는데, 분할된 작은 프로세스들간의
숨겨진 영향 및 관계가 있을 경우 이런 접근 방식으로도 풀어내기 힘들수가 있다는것이다.
예를들면 프로그램에 버그가 있어 그 디버깅을 할 경우에 ,
만약 프로그램의 전체 행수가 1024라인 이라면 분할정복을 통해 전체 행수를 2로 나누어
접근하면 2의10승 즉 10번의 확인을 통해 버그가 난 장소를 찾을수가 있다.
그런데 이건 이론적인것이고 실제로는 A -> B -> C -> D 의 프로세스에서
A의 버그가 D의 프로세스의 원인이 될 수가 있다. 이런 경우에는 방금 말한 방식으로 버그가 난 장소는 찾을수
있겠지만 A와의 관계까지는 파악하기 힘들다. 아마 더욱 더 많은 시간을 투자해야 발견할수 있을것이다.
마찬가지로 프로젝트를 진행하거나 일정을 수립함에 있어 각 프로세스간의 관계를 고려하지 않고
단순히 분할하여 정리하려한다면 차후 전체적인 지연에 있어서 대응은 물론 그 원인조차 파악하기
힘들어질수가 있다.
...라고 잠깐 단상.