Prologue

몇년전에 있었던 일이었다. 누군의 정치가에 의해 창조경제라는 말이 나타나게 되었고 진정으로 창조경제를 하기 시작했다. 문과생의 취업이 되지 않으니 문과 졸업생에게 programming을 한달간 가르쳐 개발자로 만들겠다는 어마어마한 계획이었다. 혹자는 그렇게 하면 되지 하며 좋은 아이디어 인데 하고 생각할 수 있겠다. 그런데, 가만히 생각해보자. programming을 한다는 것은 어떤 도구로 하는 것일까? 기본적으로 보통 language 라는 도구를 사용한다. C, C++, Java, Python, .... 등등 아주 많은 언어가 있다. 그런데, 이들을 지칭하는 이름부터 보자. 언어라고 한다. language. 우리가 사람들과 의사소통을 위해 사용하는 것을 무엇이라고 할까? 그것도 언어다. 이것도 언어 저것도 언어인 것이다. 왜 언어라고 하는 것일까? 즉, 컴퓨터(또는 기계)와 의사소통을 위한 도구인 것이다. 그러면, 아까 앞에 이야기 했던 부분을 생각해보자. 다른말로 표현해보자. 문과생들에게 새로운 언어를 가르쳐서 한달만에 기계와 효과적으로 의사소통을 하기위해 언어를 가르치는데 이것이 한달만에 가능하다. 여러분들이 영어 또는 한국어를 한달만에 가르쳐서 해당 언어로 의사소통이 가능할까? 바디랭귀지를 빼고서 말이다. 바디랭귀지 또한 추가적으로 다른 감각기관을 통해 사용하는 의사소통이기 때문에 기계는 그런 것이 가능하지 않기 때문에 동일한 조건을 위해 빼야 한다. 그렇다면 이렇게 해볼 수 있겠다. 전화로 한달 배운 언어로 의사소통이 가능할까? 그래 아주 간단한 의사소통은 가능할지도 모르겠다. 하지만 상대방이 어떤행동을 해주기를 바라고 하는 의사소통이 가능할까? 그것도 아주 자세히 정확하게 말이다. 
답은 불가능하다. 영어를 중학교 고등하교 3년을 배워도 외국인이랑 통화하면 아무말도 못하고 버벅일 것이다. 그렇다면, 기계와 의사소통을 위한 언어는 한달만 배워서 의사소통이 가능하냐는 말이다. 아주 정말이지 프로그래밍은 별거 아니야 이게 모라고 생각하는 사람들의 1차원적인 정말이지 미친 생각인 것이다. 물론 아주 옛날에는 가능할지도 모르겠다. 왜냐하면 언어를 사용하여 수백줄 이내에 몇가지 동작만 하면 되던 시대에는 하지만, 현재 일부 프로그램을 보면 수만줄 부터 시작해서 수십만 아니 수백만줄이 필요한 시대이다. 그걸 한달안에 배워서 하겠다고? 그건 마치 영어를 하나도 할 줄 모르는 사람이 한달 배워서 특정행동을 즉, 예를들면 교과서 같은 것을 만들라고 하는 것이다. (소설책은 미사여구가 더 들어가기 때문에 여기에는 해당하지 않는다고 생각한다. 프로그래밍은 책으로 비유하자면 어떤 특정분야를 가르치고 guide document 라고 볼 수 있다. 불필요하게 가끔 자기가 잘났다는 생각에 꽤나 읽기 어렵게 필요없이 코드를 꼬아서 쓰는 사람이 있는데 이건 아주 나쁜 습관이다.) 
또 한가지 여기서 아예 가르치지 않는 것이 있다. 여러분들이 언어만 배웠다고 해서 글을 쓸 수 있는가? 그것도 팔 수 있는 책을? (코드를 짜는 이유는 누군가에게 댓가를 받고 파는 것이다. 즉, 책을 만들어 파는 행위와 같다고 볼 수 있다. ) 책에도 쓰는 요령이 있고 절차가 있다. 물론 작가들 마다 다 책을 만들어가는 방식이 다르다. 여기서 책을 쓰는 작가와 개발자간의 다른점이 있다. 개발자가 만든 코드는 점점 진화되고 발전되어 가야 한다는 것이다. 그리고, 계승되어야 한다. 만약, 작가가 만든 책을 보지 않고 작가가 책을 만들기 위한 자료만을 보고 그 책을 똑같이 쓸 수 있을까? 그 대답은 그렇게 하기 어렵다 이다. 왜냐하면 학교에서 책을 쓰기 위한 틀은 있지만 작가마다 다 다르다. 작가는 그래도 된다. 왜? 그 자료를 누가 보고 똑같은 책을 쓸 필요가 없기 때문이다. 하지만 개발자는 다르다. 내가 만든것을 누군가에게 위임하고 그 코드가 세상의 변화에 맞게 계속 발전되어야 한다면 코드를 만들기 위한 사전 자료가 있어야 하는데 그 자료 조차 누가 봐도 동일하게 이해하고 자료만 보고도 동일하게 코드를 만들 수 있어야 한다. 그런데, 요즘도 주변에는 모두 코드 문법만 가르치지 코드 문법을 사용하는 방법 더 나아가서 전체의 구조를 설계하는 방법을 가르쳐주지는 않는다. 즉, 설계의 방법을 가르쳐주지 않는 것이다. 나는 현재 이것이 문제라고 말하고 싶은 것이다. 
이제 여기서는 전체 만들고자하는 프로그램의 전체 구조를 구상하고 설계하는 방법부터 그게 어떻게 코드로 구현되는지 까지를 알려주고 싶다. 그래서, 최초로는 UML이라는 설계 도구를 간단한게 설명할 것이다. 간단하게 설명하는 이유는 UML에 대한 자료와 책은 세상에 널려있다. 그런데 그게 모랄까 법전같이 너무 어렵고 또 너무 두꺼워서 모두 읽다가 포기한다. 그리고, 넓게 설명하려고 하다 보니 너무 추상적으로 설명하는 경향이 있다. 그리고, 약간의 잘못된 설명으로 인해 읽는 독자로 하여금 이해하기 어렵게 만들고 있는 것이 현실이다. 그래서, 여기에서는 기본적으로 C와 C++을 중심으로만 UML을 설명할 것이다. 어떻게 코드와 맵핑이 되는지를 그리고 어떻게 사용해야 하는지를 설명할 것이다. 
여기까지가 이해가 되었다면 이제야 본론으로 들어갈 수 있다. 그럼이제 내가 만들고 싶은게 무엇인지를 추상적으로 설명하며 어떤 이론을 도입하여 만들것인지를 말해야 하는 architectural pattern 을 사용하여 설명할 것이다. 그 다음은 design pattern 을 사용하여 어떻게 내가 만들고자 하는 것을 효율적으로 설계하는 방법을 설명할 것이다. 그리고, 마지막으로 여러분들이 배웠던 문법을 사용하여 algorithm을 구현하면 코드를 작성하는 단계로 가는 것이다. 
그러면, 여기에서 설명한 것들을 모두 읽었고 이해했으니 내가 코드를 짤 수 있겠구나 라고 생각할 수도 있겠다. 이게 가능하다면 내가 정말로 정말로 잘 썼거나 또는 여러분들이 천재가 되시겠다. 유시민의 글쓰기 특강을 읽고 여러분들이 이제 책을 쓸 수 있다는 말과 다를바가 없다. 이건 하나의 가이드가 될 것이다. 여러분들이 만나게 되는 갈림길에중에 어떤 길로 가야 좋을지를 고민할 수 있게 해주는 가이드가 될 뿐이다. 그 갈림길을 만나게 될 때까지 한 걸음 한 걸음 걸어야 하는 것인 바로 여러분들 스스로의 힘이 필요하다. 즉, 글을 많이 써보고 다른 사람의 글을 많이 읽어봐야 글을 잘 쓰는 것처럼 여러분 스스로가 계속 개발하고 또는 누군가가 개발한 것을 많이 봐야 한다. 여기서 보여주는 것은 개발의 한 편린이다. 각각 단계에서 해야될 것에 대한 아주 작은 부분만 보여주는 것이다. 이 부분을 보고 여런분들 스스로가 많이 걸어봐야 하는 것이다. 그래서, 내가 바라는 바램은 아주 작을 수 밖에 없다. 여러분들의 큰 걸음에 작은 도움이 되었으면 하는 것입니다.