무척 오래전 대학에 갓 입학해서 뽀송뽀송할때 객체지향이란 단어를 처음 들었다.
그리고 아직 20여년이 안됐지만 객체지향이 무엇인지 아직도 모르겠다.
그동안 대학동문들부터 회사생활,프리랜서 생활동안 무수한 개발자들을 거쳐왔는데
그 많은 사람 중에 객체지향을 제대로 이해하는 사람은 단 한번도 못보았다.
예전에 빵집개발자께서 대한민국에 객체지향을 제대로 이해하는 사람은 3명도 안된다고 했던가? (정확한 기억은 아닌데, 레퍼런스를 못찾겠네)
어쨋든 비슷한 인구수를 말하고 뭇매를 맞으셨는데 아주 정확한 표현이라고 생각한다.
일단 내가 만난 수백명(?)의 개발자 중엔 단 한명도 없었고, 과연 대한민국에 있기나 할까? 라는 생각이 든다.
이 부분은 개인적으로는 사고방식 문제라 생각하는데, 늘 비유로 드는 점이 있다.
객체지향과 일맥상통하는 부분은 아닌데 양키와 우리들의 사고방식에 대한 생각이다.
email을 관리할때 , 구글의 tag 라는 개념은 상당히 오래전 도입됐다.
그리고 mac에서 파일 관리를 할때도 tag라는 개념이 있다.
이런 개념에 우리는 매우 약하다.
조직도.
바로 이런점이 우리의 사고방식이다. 수직적으로 tree를 만드는데 익숙한 사고방식.
tag 개념에서는 이런것을 초월한다.
현대에서는 무엇인가를 다 기억하기보다 어디있는지를 알아야하는 관점에서 tag로 사고하는 사람과 tree로 사고하는 사람은 차이가 난다.
아마 메일이나 파일시스템에서 tag의 장점을 느껴본 자는 알고 있으리라.
개발을 배우는 시점에서도 이미 수직적 사고를 해오다보니 소위말하는 절차지향, 구조지향은 매우 쉽게 구현되나,
객체지향부터는 헤매이기 시작한다.
심지어 이렇게 생각해오던 차에 전 회사에서 재미있는 경험이 있었다.
A라는 팀장이 a와 b 조직을 겸임하는 사례는 처리가 잘 되는데
a라는 팀에 A와 B라는 두명의 팀장이 생기자마자 시스템이 바보가 된 상황이다.
절망적이게도 오라클 ERP는 이 부분이 처리가 가능하다.
즉, 양키들이 만든 시스템은 받아들일 수 있게 해두었는데 우리가 커스트마이징하면서 사용을 막아버린 것이다.
그리고 모 팀장은 외쳤다.
"아니 팀에 팀장이 두개인 사례가 어딧어. 말도 안되게 조직개편을 해".
양키들이 만든 유연한 시스템을 막아버린 자의 항변.
오랫만에 글을 적다보니 두서가 없었는데, 어쨋든 객체지향이라는 것은 나에게 매우 어렵다.
1. 객체지향을 이해하고자 노력 (십수년)
2. 도저히 이해할 수 없어 버리고 절차지향으로 변심 (1년)
3. 아쉬워서 다시 객체지향을 살핌 (현재)
현재 3번을 하다보니 다시금 눈에 보이는 부분이 많다.
어차피 객체지향적 사고를 양키처럼 못할바에는 우리의 사고방식을 객체지향에 잘 맞춰보는 것이다.
사실 객체지향이 근 20여년을 지배해왔지만 최근에 functional programming인기를 끌고 있는데,
functional programming 이라고 크게 바뀐것은 없고 객체지향을 제대로 이해한 토양위에 내려진 축복이라고 생각한다.
현재 같이 일하시는 분의 사고방식은,
본인이 가장 잘 이해하는 부분의 장점을 가지고 , 전산학의 가장 기초에 충실하여
(도구는 객체지향언어가 되었던, 함수형언어가 되었던, 절차적 언어가 되었던, 혹은 어떤 프레임워크인던)
(그러면서도 최신기술을 사용하고 싶어하시는 욕심이 많으신데)
잘 녹여서 그것들을 마치 나에게 가장 익숙한 연장처럼 사용하신다.
그리고 더 나아가 주니어가 그 연장들을 사용할때도 주니어에게 가장 익숙한 연장이 되기를 원하신다.
그래서 주니어가 그 연장들을 사용하기 위한 공통모듈을 만들다보니 다시 객체지향이 필요함을 느끼고 있는데,
정확히는 객체지향을 사용함이 아니라 이해 후 장점으로 승화! 이다.
예전 읽었던 책 중에 고대그리스 VS 고대 중국을 비교했던 책이 있었는데,
이는 언어학적으로도 토론하기 좋은 영어와 명령하기 좋은 국어(사실 고대 중국기반)가 된 사유를 논했었다.
수직적 사고의 장점을 극대화하여 객체지향을 정복한다.
끝