336x280(권장), 300x250(권장), 250x250, 200x200 크기의 광고 코드만 넣을 수 있습니다.
'나누어 해결하기'는 많은 사람들이 익히 잘 알고 있는 매우 친숙한 문제해결지침입니다. 친숙한 만큼 개념 또한 매우 간단합니다.
이렇게 단순한 개념이라 그런지 몰라도 제게는 왠지 현실과 거리가 있는 개념으로 보였습니다. 예를 들어 누군가 "소프트웨어 개발을 잘하는 방법이 무엇인가요?"라고 물어보았을 때 "잘 개발해라"라고 대답해주는 느낌이라고 할까요. 그렇지만 얼마 전 저는 '나누어 해결하기'가 가진 아름다움에 대해 엿보는 경험을 하게 되었습니다. 그래서 이번 글에서 나누어 해결하기에 대해 제가 본 부분을 써보고자 합니다.
소프트웨어 개발을 하다보면 필연적으로 어려운 문제를 만나게 됩니다. 설계를 하다 어려운 문제를 만나기도 하고 코딩을 하다 어려운 문제를 만나기도 합니다. 때때로 이러한 문제들은 절망스럽게 느껴집니다. 문제가 복잡하면 머리가 아프고 어디서부터 시작해야 할지 감이 잡히지 않을 때가 있습니다. 예전 개발에 익숙하지 않은 시절에 저는 복잡하고 어려운 문제를 만나면 허둥될 수 밖에 없었습니다. 문제 해결을 시도하면 할수록 문제가 해결되어 간다는 느낌보다는 오히려 문제가 더욱 복잡해지는 듯한 느낌을 받았습니다. 그 늘어가는 복잡함에 기가 질려 결국 프로젝트를 포기한 적도 몇번 있었습니다. 저는 당시 왜 이런 일이 일어나는지 알 수가 없었습니다.
다행히 경험이 쌓이면서 복잡한 문제를 해결하지 못하는 일은 점점 줄어들어 갔습니다. 하지만 여전히 저는 예전에 복잡한 문제를 잘 해결하지 못했던 이유에 대해 명확히 알 수 없었습니다. 그냥 경험을 쌓다보니 문제해결능력이 향상 되었구나라고 생각했습니다. 이렇듯 무의식 속에 지내던 저는 얼마전 실마리를 찾게 되었습니다. 바로 경험이 쌓임에 따라 자연스레 나누어 해결하기를 사용해왔다는 사실이였습니다.
우리는 소프트웨어를 개발할 때 구조를 설계합니다. '이 시스템을 구현하려면 A,B,C 세 부분이 있으면 되겠네.'라고 얘기합니다. 이것이 바로 나누어 해결하기 입니다. 시스템 구현이라는 문제를 해결하기 위해 문제를 A,B,C로 나누었고 A,B,C는 시스템 구현이라는 문제를 해결하기 위해 상호작용합니다. 서두에 소개한 위키피디아의 나누어 해결하기 정의와 같습니다. 또한 하나의 클래스를 만들 때 우리는 해당 클래스가 지향하는 목적을 달성하기 위해 여러 메서드를 만듭니다. 이것 역시 나누어 해결하기의 예라고 볼 수 있습니다.
좀더 큰 관점에서 소프트웨어 개발이라는 것은 추상적인 아이디어로 시작하여 소프트웨어 구조 그리고 소프트웨어의 코드들로 점점 구체화 되가는 과정이라 볼 수 있습니다. 이 과정에서 나누어 해결하기가 계속적으로 사용됩니다. 이 때문에 소프트웨어 개발을 잘한다라는 것은 결국 나누어 해결하기를 잘 한다라고 보아도 무방할 것 같습니다.
더욱 흥미로운 것은 나누어 해결하기는 소프트웨어의 세계를 뛰어넘어 실세계의 많은 부분에서 적용될수 있고 실제로 무의식적으로라도 사용되고 있는 강력한 문제해결지침이라는 것입니다. 예를 들어 우리가 가계부를 적을 때 주별로 혹은 월별로 소계를 내서 총계를 구합니다. 즉 총계를 구하기 위해 그것을 작은 단위로 나누어 각각을 해결한 후에 소계를 더하는 방법으로 원래의 문제를 해결한다는 것입니다. 이것은 소프트웨어에서 사용하는 나누어 해결하기와 동일합니다. 또한 회사 조직도를 보며 나누어 해결하기를 발견할 수 있습니다. 회사의 목적을 위해 여러 부서들로 나누고 해당 부서들은 회사의 목적을 위해 상호작용 합니다. 이러한 조직도를 통해서도 나누어 해결하기의 철학을 엿볼 수 있습니다.
끝으로 나누어 해결하기 원칙에 대해 몰랐던 어떤 구독자가 이 글을 통해 나누어 해결하기를 배우고 이해한다 하더라도 갑자기 소프트웨어 개발을 잘 하게 되지는 않을 것 같습니다. 하지만 현재 직면한 복잡한 문제를 해결하기 위한 좋은 접근 방법은 될 수 있다고 생각합니다. 또한 '소프트웨어 개발은 나누어 해결하기의 연속이다.'라는 시각을 갖는 것은, 문제에 대해 체계적으로 접근할 수 있게 도와줄 것이라 생각합니다.
2008/05/13~2009/05/04
In computer science, divide and conquer (D&C) is an important algorithm design paradigm based on multi-branched recursion. A divide and conquer algorithm works by recursively breaking down a problem into two or more sub-problems of the same (or related) type, until these become simple enough to be solved directly. The solutions to the sub-problems are then combined to give a solution to the original problem.
출처 : http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm
(위 위키 페이지에서는 나누어 해결하기가 가진 여러 가지 장점들을 얘기하고 있습니다. 이 글은 그 중 'Solving difficult problems' 에 대한 상세한 내용이라고도 볼 수 있습니다.)
이렇게 단순한 개념이라 그런지 몰라도 제게는 왠지 현실과 거리가 있는 개념으로 보였습니다. 예를 들어 누군가 "소프트웨어 개발을 잘하는 방법이 무엇인가요?"라고 물어보았을 때 "잘 개발해라"라고 대답해주는 느낌이라고 할까요. 그렇지만 얼마 전 저는 '나누어 해결하기'가 가진 아름다움에 대해 엿보는 경험을 하게 되었습니다. 그래서 이번 글에서 나누어 해결하기에 대해 제가 본 부분을 써보고자 합니다.
소프트웨어 개발을 하다보면 필연적으로 어려운 문제를 만나게 됩니다. 설계를 하다 어려운 문제를 만나기도 하고 코딩을 하다 어려운 문제를 만나기도 합니다. 때때로 이러한 문제들은 절망스럽게 느껴집니다. 문제가 복잡하면 머리가 아프고 어디서부터 시작해야 할지 감이 잡히지 않을 때가 있습니다. 예전 개발에 익숙하지 않은 시절에 저는 복잡하고 어려운 문제를 만나면 허둥될 수 밖에 없었습니다. 문제 해결을 시도하면 할수록 문제가 해결되어 간다는 느낌보다는 오히려 문제가 더욱 복잡해지는 듯한 느낌을 받았습니다. 그 늘어가는 복잡함에 기가 질려 결국 프로젝트를 포기한 적도 몇번 있었습니다. 저는 당시 왜 이런 일이 일어나는지 알 수가 없었습니다.
다행히 경험이 쌓이면서 복잡한 문제를 해결하지 못하는 일은 점점 줄어들어 갔습니다. 하지만 여전히 저는 예전에 복잡한 문제를 잘 해결하지 못했던 이유에 대해 명확히 알 수 없었습니다. 그냥 경험을 쌓다보니 문제해결능력이 향상 되었구나라고 생각했습니다. 이렇듯 무의식 속에 지내던 저는 얼마전 실마리를 찾게 되었습니다. 바로 경험이 쌓임에 따라 자연스레 나누어 해결하기를 사용해왔다는 사실이였습니다.
우리는 소프트웨어를 개발할 때 구조를 설계합니다. '이 시스템을 구현하려면 A,B,C 세 부분이 있으면 되겠네.'라고 얘기합니다. 이것이 바로 나누어 해결하기 입니다. 시스템 구현이라는 문제를 해결하기 위해 문제를 A,B,C로 나누었고 A,B,C는 시스템 구현이라는 문제를 해결하기 위해 상호작용합니다. 서두에 소개한 위키피디아의 나누어 해결하기 정의와 같습니다. 또한 하나의 클래스를 만들 때 우리는 해당 클래스가 지향하는 목적을 달성하기 위해 여러 메서드를 만듭니다. 이것 역시 나누어 해결하기의 예라고 볼 수 있습니다.
좀더 큰 관점에서 소프트웨어 개발이라는 것은 추상적인 아이디어로 시작하여 소프트웨어 구조 그리고 소프트웨어의 코드들로 점점 구체화 되가는 과정이라 볼 수 있습니다. 이 과정에서 나누어 해결하기가 계속적으로 사용됩니다. 이 때문에 소프트웨어 개발을 잘한다라는 것은 결국 나누어 해결하기를 잘 한다라고 보아도 무방할 것 같습니다.
더욱 흥미로운 것은 나누어 해결하기는 소프트웨어의 세계를 뛰어넘어 실세계의 많은 부분에서 적용될수 있고 실제로 무의식적으로라도 사용되고 있는 강력한 문제해결지침이라는 것입니다. 예를 들어 우리가 가계부를 적을 때 주별로 혹은 월별로 소계를 내서 총계를 구합니다. 즉 총계를 구하기 위해 그것을 작은 단위로 나누어 각각을 해결한 후에 소계를 더하는 방법으로 원래의 문제를 해결한다는 것입니다. 이것은 소프트웨어에서 사용하는 나누어 해결하기와 동일합니다. 또한 회사 조직도를 보며 나누어 해결하기를 발견할 수 있습니다. 회사의 목적을 위해 여러 부서들로 나누고 해당 부서들은 회사의 목적을 위해 상호작용 합니다. 이러한 조직도를 통해서도 나누어 해결하기의 철학을 엿볼 수 있습니다.
끝으로 나누어 해결하기 원칙에 대해 몰랐던 어떤 구독자가 이 글을 통해 나누어 해결하기를 배우고 이해한다 하더라도 갑자기 소프트웨어 개발을 잘 하게 되지는 않을 것 같습니다. 하지만 현재 직면한 복잡한 문제를 해결하기 위한 좋은 접근 방법은 될 수 있다고 생각합니다. 또한 '소프트웨어 개발은 나누어 해결하기의 연속이다.'라는 시각을 갖는 것은, 문제에 대해 체계적으로 접근할 수 있게 도와줄 것이라 생각합니다.
2008/05/13~2009/05/04
WRITTEN BY
- 차민창
르세상스 엔지니어가 사회를 이끌어나가는 상상을 하며!
,
