프로그래밍을 몇 년간 해 본 분들이라면 어떻게 해야 문제의 복잡성을 단순하게 해결하고 해소시켜야 할지 문제를 대면하는 순간 먼저 떠오르게 됩니다. 즉, 프로그래밍이란 문제의 복잡성을 해결하는 과정(Process)이라고 할 수 있습니다. 서양철학의 태두이신 화이트헤드의 철학서적에는 “과정과 실재”라는 서적이 있습니다. 필자의 견해로는 과정이라고 하는 Process와 실재라는 Reality가 하나라는 것이죠. 즉, 프로그래머에게 있어서 프로그래밍이라는 과정 자체가 문제 해결의 본질이라고 볼 수 있습니다. 그만큼 과정이 중요하다고 할 수 있습니다. 실타래의 엉클어진 실에서 실오리를 하나하나 풀어나가는 것처럼 주도면밀하게 치밀한 기교가 요구되는 것이 프로그래밍입니다. 이는 만사(萬事)의 모든 일들에 대해서, 즉 일상생활 속에서 발생하는 사건이나 문제에 대해서 현실적으로 해결해 나가는 과정과도 일치합니다. 사건이나 문제는 그냥 단순하게 발생하는 것이 아니라 복잡한 양상을 띠고 해결하기 다소 어렵게 다가오는 경향이 있습니다. 따라서 차근차근 점진적으로(Incrementally) 해결해 나가는 것이 필요합니다.

    분할 후 정복(Divide and Conquer)이라는 소프트웨어 공략 기법이 있는데 이 또한 복잡한 프로그램을 해결해나가는 과정으로서 대두된 방법이라고 할 수 있습니다. 소프트웨어 자체는 복잡함 덩어리입니다. 이러한 복잡함의 덩어리를 얼마나 능숙하게 만들어 내느냐가 프로그래머의 관건입니다. 고객의 요구사항 또는 기능 명세에 입각하여 하나하나 기능들을 구현해 나가 눈사람을 뭉쳐서 만들 듯이 점진적으로 확장시켜서 소프트웨어를 구축해 나가는 것이 필요합니다. 이를 위해서는 단순함에 대해서 잘 알고 있어야 합니다. 단순할수록 이해하기 쉽고 배우기 쉬우며 적용하기 쉬웁니다. 아무리 어려운 이야기와 책이라도 단순하게 요약해 보면 어려울 것이 없습니다.

프로그래머의 고수는 문제를 항상 단순하게 바라보는 식견을 지니고 있다는 점입니다. 켄트백의 익스트림 프로그래밍에서도 단순성을 강조합니다. 단순성은 Simplicity라고 하며 모든 문제의식의 근원적 자리라고 생각하시면 됩니다. 다시 말해서, 모든 문제들에 대해서 깊이 참구해 들어가면 결국 단순한 사실이나 단순한 이치로 귀일한다는 점입니다. 요구사항이나 기능명세를 보고서 문제의식을 형성하게 되는데 이러한 문제의식의 궁극적 경지에 이르게 되면 아무리 복잡해 보이는 요구사항이나 기능명세서라도 단순한 이치가 존재함을 발견하게 된다는 것입니다. 고수 프로그래머는 그러한 단순함 또는 단순성을 많이 경험해 보았고 복잡한 문제의식 덩어리를 축소시켜 감소시킴(Reduction)으로서 해결해 나갑니다. Reduction이란 단어의 의미는 컴파일러 과목에서도 나오는 내용으로서 소프트웨어 공학에 적용한다면 문제의식을 점차적으로 줄여나가고 감소시켜 나감을 의미합니다. 한마디로 Reduction이란 문제를 축소시켜감을 의미합니다. 무를 짤라내서 무의 크기를 줄여나가듯이 복잡한 문제의식 덩어리를 하나하나 축소시켜감으로써 해소시켜 나가는 것을 의미합니다. 문제의식의 덩어리가 축소될수록 프로그램의 크기는 눈덩이처럼 증가하게 됩니다.

  사실, 요구사항이나 기능명세 등의 문제 덩어리는 복잡한 경향을 지니고 있습니다. 그것은 요구사항의 각 항목들이 서로 독립적이기 보다는 복합적으로 얽물려 있기 때문입니다. 카오스 이론이나 플랙탈 이론 등을 통해서 알 수 있듯이 모든 사사물물들이 서로 유기적으로 연계되어 있기 때문에 요구사항 명세의 어느 하나에 대해서 소홀히 할 수 없습니다. 독립적인 개체란 존재하지 않습니다. 개체란 서로 연결되어 있는 망의 한 부분입니다. 마찬가지로, 문제들의 항목을 이해하기 위해서는 유기적인 사유가 필요하며 이러한 유기적인 사유의 기초에는 문제를 단순하게 축소시킬 수 있는 지혜가 요구됩니다. 문제의 항목들을 쉽게 정복하기 위해서는 문제의식 자체가 통일된 관점을 지녀야 합니다. 어린아이들이 레고블럭을 조립하는 것처럼 문제의 항목들을 질서정연하게 통일성을 갖고 조립하고 구성할 수 있는 능력이 필요합니다.

  필자가 명상(Meditation)을 강조한 이유는 이러한 통일의식을 얻는데 명상이 큰 효과를 주기 때문입니다. 정신통일을 통해서 사사물물, 즉 고객의 요구사항문서와 기능명세서의 세부항목들을 어떻게 구현할 것인지에 대해 일관된 의식을 갖게 됩니다. 소프트웨어가 완벽하려면 프로그래머의 문제의식이 통일되어 있어야 하며 이는 문제들을 쉽게 이해하고 있어야 합니다. 문제들을 어렵게 이해하거나 복잡하게 생각하고 있다면 그 문제들을 제대로 해결해 낼 수 없습니다. 여하튼, 프로그래머는 복잡한 문제들에 대한 문제의식을 단순화시켜 프로그래밍을 통해서 구체화하는 것이 요구됩니다. 이를 도식으로 나타내면

   고객의 요구사항(기능명세) 문제 -> 프로그래머의 문제의식 -> 프로그래밍(문제의식의 해소) -> 프로그램

이 됩니다. 물론, 프로그래밍 과정에는 테스팅, 디버깅 등이 포함된다고 생각할 수 있습니다.

  실세계의 문제들이 지닌 복잡성을 해결하는 것이 프로그래밍이기 때문에 실세계의 문제를 보다 잘 해결하기 위해서는 복잡한 실체를 이해하기 쉽고 단순하게 자신의 것으로 소화하는 능력이 필요합니다. 이것이 바로 진실된 고수 프로그래머로 가는 길이라고 봅니다. 필자는 6년간의 프로그래밍 경험을 통해서 복잡함을 해소시키고 단순화시키는 방법으로써 경우의 수를 나누어 그것을 하나하나 고려하고 선택,배제 시킴으로써 단순화를 이룰 수 있다는 것을 알았습니다. 즉, 실세계의 문제가 얼마나 다양한 양상으로 전개되는지를 이해하고 그들을 하나하나 경우의 수를 따져가면서 체계화시키고 정리하는 것이 중요하다고 봅니다. 경우의 수를 따지는 것은 실세계의 다양성을 프로그램에 포섭하기 위함이며 문제(요구사항과 기능명세)들을 정리하기 위함이라고 할 수 있습니다. 경의 수는 if 문과 switch(또는 case) 문 등으로 구현됩니다. 논리적인 판단이라는 것도 if 문을 중심으로 이루어지고 있기 때문에 if문은 프로그램의 구조를 결정짓는 매우 중요한 요소가 아닐 수 없습니다. if 문은 조건문인 동시에 선택문의 역할도 하며 논리적 판단 기능도 포함하고 있습니다.

  논리적 체계의 근간을 이루는 if 문의 효율적 사용과 기능의 재사용성을 담당하는 함수(또는 메소드)의 효과적인 활용은 프로그래밍을 유익하게 하며 능률적으로 하도록 도와줍니다. 문제(요구사항과 기능명세)의 복잡함이나 프로그램의 복잡함이나 문제의식의 복잡함이나 모두 동일한 것이며, 그것들이 구체적으로 프로그래머에 의해서 어떻게 코딩이 되느냐가 관건입니다. 그러기 위해서는 논리적 뼈대를 구성하는 if 문, switch문, for문 그리고 함수 등이 중요합니다. OOP의 경우에서는 클래스, 메소드, 프로퍼티도 중요한 역할을 차지한다고 볼 수 있습니다. 윈도우즈 프로그래밍에서는 이벤트가 중요한 역할을 합니다. 이러한 프로그래밍 언어 또는 개발툴의 구성요소들을 잘 활용하여 문제의 복잡성 다시 말해서 문제의식의 복잡성을 해소시키는 단순한 방법을 찾는 것이 프로그래머의 몫이라 할 수 있습니다.

  고객의 요구사항이나 기능명세서에 적힌 항목들을 통해서 문제들을 읽을 때, 프로그래머는 어렵게 생각해서는 안되고 단순하게 생각할 줄 알아야 하며, 프로그램 경력이 늘어날수록 문제 항목들 간에 유기적 관계성을 파악하여 문제를 전체적으로 볼 수 있는 지혜의 눈을 얻게 됩니다. 즉, 문제의식 자체가 단순할수록 좋으며 문제의식들 간의 연계가 매끄럽게 이어져야 합니다. 이것은 바로 프로그래머의 내면에 나름대로 다소간의 정신적 통일성을 얻었다는 것을 의미합니다.

문제의식들 간의 연계라는 것은 고객의 요구사항이나 기능명세서 자체가 하나의 문제의식만을 나타내는 것이 아니라 다양한 문제의식을 나타내며 어떤 문제의식은 복합적이고 중층적이며 어떤 문제의식은 개별적이고 독립적일 수 있습니다. 하지만 이러한 문제들을 해결해 나가는 과정은 하나의 흐름을 형성하고 있으며 따라서 문제의식들 간의 연계가 중요한 것입니다.

프로그래머는 고객의 요구사항이나 기능명세를 보고 몇 개의 윈도우 화면이 구축될 것인지 그리고 세부적으로 하나의 윈도우에서 대략 몇 개의 if문과 함수를 사용할 것인지를 짐작할 수 있어야 합니다. 이러한 전체적인 시각으로 문제들을 바라볼 때 문제의식을 단순화할 수 있고 프로그래밍을 수월하게 하는데 도움이 됩니다. 물론 너무 계산적이고 정확하게 프로그램의 구조를 시작 전부터 파악하려고 할 필요는 없고 대강 짐작을 하고 개략적인 설계도를 마음속으로 그려 놓아야 한다는 것입니다. 이러한 개략적인 설계도는 심상(心象)으로 그리는 것이지 문서로 나타낼 필요까지는 없습니다. 물론 문서화가 필요하면 문서화를 하는데 절대로 형식적인 문서화에 얽매일 필요는 없습니다. 외면과 내면이 따로 돌면 괴롭지만 외면과 내면이 따로 돌아도 이를 합일시켜 나가도록 노력하고 정 안 되면 내면의 설계도에 근거하여 외면의 설계도를 매칭시켜 나가는 것이 중요합니다. 이것은 실제 회계감사를 할때 회계감사용으로 재무재표를 따로 만들고 내부용으로 재무재표를 따로 만드는 것과 비슷합니다. 형식과 실리는 항상 괴리감을 갖고 존재하는 것이 현실이 아닌가 합니다.

  여하튼, 프로그래머는 문제의식을 단순화시키는 것이 중요하며 문제의식을 단순화하고 간소화해 나감으로써 프로그래밍을 수월하게 할 수 있음을 주목할 필요가 있습니다. 다시 강조하는바, 문제의식을 단순화시키는 것은 경우의 수를 잘 나누는 것이며 if문과 함수(또는 메소드)의 구성을 개략적으로나마 파악하는 것입니다. 처음 프로그래머 도제들에게는 이것이 어려운데 점차로 장인으로 성장해 가면서 이러한 것이 눈에 보이기 시작합니다. 지혜의 눈이 떠지게 되는 것이지요. 실제로 프로그래밍은 지혜의 눈을 밝히는데 있습니다. 문제를 어떻게 하면 효과적이고 효율적으로 해결해 나갈 것인가를 아는 것이 중요합니다. 1년 전이나 2년 전이나 마냥 동일한 상태로 발전이 없이 정체되어 있다면 프로그래밍에 회의감을 느끼기 쉽습니다. 그러므로 항상 자신을 발전시키고 지혜와 앎을 증식시키고 신장시켜 나가는데 노력해야 합니다.

전체를 구성하는 부분들의 관점에서 어떻게 문제들이 문제의식으로 변환되고 그러한 문제의식들이 프로그램 기능으로 축소 및 분해 되는지 그것을 이해할 필요가 있습니다. 이러한 프로그램 제조 및 구성과정의 흐름을 이해하는 것이 문제의식의 결정화를 이해하는데 적지 않은 도움이 됩니다. 그리고 복잡한 논리(로직)를 간단하게 표현하는 능력을 배양하는 것도 요구됩니다. 고수 프로그래머는 어려운 문제를 쉽게 생각하고 쉽게 구현합니다. 즉, 복잡한 문제를 간단한 문제의식으로 변환하여 간단한 기능으로 구현해 냅니다. 이것은 처음부터 이루어진 것이 아니라 부단한 노력과 인내를 통해서 얻어진 것이라 할 수 있습니다. 프로그래머 도제(초보자)들도 3년 정도 열심히 노력하면 어느 정도 실력이 늘어날 것이며 6년을 넘고 10여년 정도 프로그래밍을 해봄으로써 산을 몇 번 넘고 넘으면 문제사항들을 대면할 때 어려움을 크게 느끼지 않을 것입니다. 반복되는 업무도 많고 비록 변화되는 부분이 있더라도 그것을 어떻게 대처해야하는지 명료하게 인식하는 지혜의 눈이 계발되어 있기 때문에 그렇게 난감함을 경험하지 않을 것입니다. 물론 새로운 문제사항들이 발생하면 새롭게 배우고자 하는 마인드와 자세가 필요합니다.

  여하튼, 프로그래밍의 진수(眞髓)는 문제의 복잡성(Complexity) 정복하는 과정 속에서 얻어지는 희열이자 환희심이며 그것을 많이 느끼고 경험할 수록 프로그래밍의 세계에 심취하게 되고 실력도 일취월장하게 된다고 생각합니다. 쉬운 문제를 많이 푸시고 쉬운 문제를 정말로 쉽게 풀도록 노력해 보십시오. 그 다음 중간 난이도의 문제를 많이 푸시고 그 중간 난이도의 문제를 간단하고 쉽게 푸는 방법을 연구하십시오. 그래서 실력이 증장되면 고난이도의 문제를 많이 푸시고 그 고난이도의 문제를 쉽게 풀 수 있도록 노력하십시오. 아마, 이것이 바로 고수 프로그래머로 가는 공부의 길이 아닌가 생각해 봅니다. 물론 바로 이 가르침에는 석가모니 부처님의 수능엄 삼매경의 내용을 참고한 것입니다. 공부는 점진적으로 차근차근 쉬운 것에서부터 시작해서 어려운 것으로 나아가야 하다는 것이 바로 붓다의 가르침이라고 할 수 있습니다.

아무쪼록 독자제현님들의 공부가 일취월장하시기를 바라며 항상 끊임없이 배우는 자세로 삶에 임하셨으면 합니다. 인생이건 프로그래밍이건 배움에 대한 동경을 놓치지 않는 이상 즐거움과 환희심은 언제나 함께하리라 생각합니다.

  감사합니다.