객체지향으로부터 시작해서 자료구조, 데이터마이닝, 온톨로지, 나아가 빅데이터나 IOT 등의 개념에 대해서 정리하고 

가능하다면 나무위키에 이를 정리해둘 계획도 있구요. 

그에 따른 시작점이라고 이해해주시면 좋겠습니다.

지적사항은 환영합니다. 저도 객관적이고 사실에 기반한 이야기로 정리하고 싶으니까요 ㅇㅅㅇ!

1. 설명에 앞서.

~~지향 프로그래밍 방법이라는 것은 일반적으로 패러다임이라는 말로 구분됩니다. 패러다임이라는 것은 사람들이 시간이 지남에 따라서 새로운 형태의 생각을 바탕으로 세상을 이해하고 해석하는 것에서 출발하고 있기 때문에, 같은 현상에 대해서 다양한 패러다임에 의해 해석될 여지가 있습니다.

절차지향, 객체지향, 최근에는 서비스 지향, 모델 기반 등등의 개발방법들이 제안되고 있습니다만, 어느것이 가장 우수하냐 라는 말은 위의 이유로 큰 의미를 갖지 못하게 되죠. 

예를 들자면 이런 겁니다. 구구단을 짜는데, 고작 세줄에서 열줄정도 되는 코드를 짜기 위해서 연산자와 피연산자를 객체화 하는 것은 아무리 생각해도 비효율적입니다. 나아가 이를 서비스적으로, 모델 기반으로 해석, 개발하는 것은 언어도단 수준의 병신력을 뿜뿜할 뿐이죠. 

하지만 현업에서 일하시는 분들이나, 현재 프로그래밍을 공부하시는 분들에게 있어서 객체지향 프로그래밍이라는 것은 마치 바이블의 한 구절마냥 회자되고 누구나 지켜야 할 계명으로 들리실지도 모르겠습니다. 이렇게 사람들이 객체지향의 장점을 주장하고 공감대를 형성하는 것은 그 나름의 이유가 있습니다.

하지만 이 아래의 설명을 읽어주시면서 기억하셔야 할 것은, 누구나가 중요성을 말하고 당연하게 여기더라하더라도, 필요에 따라서는 얼마든지 절차지향이나 나아가 어쩔때는 어셈블리 수준의 단순한 프로그래밍이 더욱 효율적인 상황이 발생할 수도 있다는 사실입니다. 

지금은 누구나가 겪는 당연한 문제와 그 해결법 들이 여러분이 실제 프로그래밍을 하는 과정에서는 발생하지 않거나, 오히려 반대 작용의 걸림돌이 되는 경우도 적지 않기 때문입니다.

이론은 이론입니다. 어떻게 적용할 것인지는 여러분의 몫입니다. 다만 어떨때 이론을 적용하면 좋은지 위주로 설명을 이어가도록 노력해보겠습니다.

2. 객체지향의 배경

아이가 크면 어른이되고 성숙해지는 것은 당연한 이치입니다. 고작 반세기 남짓한 역사를 가진 소위 말하는 소프트웨어의 역사도 이제는 세상의 풍파를 겪으며 이제는 거의 어른이 되어가고 있다는 느낌입니다. 

사람이 자라고 머리가 굵어지면, 세상을 살아가는 지혜라는 것이 생기기 마련입니다. 여기서 말하는 지혜라는 것은, 세상에서 발생하는 어떤 문제에 대해서 자신이 별로 힘을 들이지 않아도 쉽게 고난을 헤쳐나갈 수 있는 요령과도 같은 것이죠.

사실 공학이라는 것의 본질은 바로 이것입니다. 공학을 한마디로 정의한다면, '어떤 기술을 이용하여 어떻게 "낮은 비용"으로 "높은 품질"의 결과물을 "효과적으로" 얻을수 있을까"를 연구하는 학문이라고 할 수 있겠죠. 소프트웨어 공학도 그런 이유로 만들어진 학문입니다. 

소프트웨어 공학을 정규적으로 배우신 분이라면 소프트웨어 위기(software crisis) 라는 말을 들어보신 분이 있을지 모르겠는데요. 사실 그냥 이름만 그럴싸하게 붙였을 뿐 딱히 별 의미가 있는 말은 아닙니다. 말하자면 사람들이 소프트웨어는 많이 만들어달라고 하는데 만들 사람은 예나 지금이나 거기서 거기이기에 돈벌어먹기 힘들어 졌다! 라는 것이 소프트웨어 위기의 개념입니다. 

말하자면 개발자들이 호프집에 가서 

'야 일 많은 건 좋은데 집에 못가서 죽겠음' 

'그건 니사정 ㅇㅇ'

'ㅠㅠ 그래도 뭐 방법 없겠냐?'

'ㅡㅡ그래 생각좀 해보자'

그리하여 소프트웨어 공학은 세상에 태어났습니다.

소프트웨어 공학의 목표는 결국 여기에 있습니다. 제한된 숫자의 인력이 어떻게 좋은 프로그램을 만들기 위해서는 어떻게 프로그래밍을 해야 할 것인가?

이 안에는 개발자와 소비자간의 의사소통 방법, 개발자간에 협력하는 방식, 프로그램의 성능, 시스템의 개발 비용 등 다양한 방법으로 소프트웨어 개발의 효율을 높이기 위한 방법이 제안되어 있습니다. 

객체지향 프로그래밍 이라는 방법은, 이 중에서도 개발자간의 협력 방식과 시스템 개발 비용을 획기적으로 개선할 수 있는 방법으로서 제안된 새로운 프로그래밍 패러다임이라고 말할 수 있겠습니다. 객체라고 하는 사람들이 쉽게 상상할 수 있는 개념을 바탕으로 쉽게 도식화 하여 의사소통을 할 수 있고, 각자의 책임을 명확하게 정의하여 작업을 분담하기도 편합니다. 나아가 기존에 만들었던 객체를 새로운 프로그램에 다시 사용하거나 기존에 프로그램의 문제를 빠르게 해결하기에도 기존에 비해 탁월한 특징을 지니고 있습니다.

다만 기억해주셔야 합니다. 여러사람이 협업해서 프로그램을 짜야하는 상황이 아닌 정도의 규모, 이를테면 계산기라던가 하는 고작해야 1000여라인의 코드에는 딱히 객체지향을 써야 할 이유가 전혀 없습니다. 그냥 줄줄이 짜는게 더 편한 분들도 많아요. 

객체지향 프로그램이 적절한 대상은 어디까지나, 수명~수십명의 인력이 동시에 개발을 진행해야 하고, 방향을 수정하고 공감대를 형성하기 위한 노력이 많이 필요한 경우입니다. 

적합한 대상에 적합한 수단을 선택한다면 패러다임의 가치를 더욱 빛나게 할 수 있을 겁니다.

다음번에는 객체의 개념에 대해서 다뤄볼게요.

연재물로 만들 생각은 없었는데, 한번에 긴 글 쓰기가 쉽지 않네요.