기술 에세이

인간에게 가장 친숙한 개념은 결국 OOP

Razelo 2021. 10. 1. 09:45

아침에 알렉님이 리액트의 기본 원리를 간략하게 설명해주시는 영상을 보는데 문득 이런 생각이 들었다. 

리액트에서는 태그 하나하나를 트리의 요소로 간주하여 오브젝트로 취급한다. 즉 예를 들어서 H1태그가 있다면 이 친구 하나가 하나의 오브젝트가 되는 것이다. 

그런데 아 여기서도 모든 걸 오브젝트로 취급하려는 시도를 하는 구나라는 생각이 듬과 동시에 파이썬에서도 오브젝트로 모든 것을 취급하는 것이 생각나면서 어느 공통점이 느껴졌다. 

 

둘다 아주 핫한 기술이다. 파이썬은 말할 필요도 없고, 리액트도 그러하다. 

그런데 왜 둘다 오브젝트로써 대상을 표현하는 방법을 사용했을까? 

그것이 어떠한 대상을 표현하는데 가장 적합해서일 수도 있고 아니면 사람들이 느끼기에 그냥 오브젝트로써 모든걸 표현하는게 정말 편하게 느껴져서일 수도 있다. 

 

이런 생각을 하다 보면 어느분께서 말씀하신게 생각난다. 

 

"함수형 프로그래밍 혹은 다른 새로운 패러다임을 가진 프로그래밍언어가 등장하더라도 객체지향을 사용하는 언어는 결코 사라지지 않을 것이다. 객체지향 즉 대상을 오브젝트로 표현하고 생각하는 방식이 인간에게 가장 친숙하기 때문이다. "

 

이 말이 맞다라는 걸 새삼 느끼게 된다. 

 

사람이 생각하는데 가장 편하다는건 즉 직관적으로 떠올릴 수 도 있으며 이해하는데 문제가 없다라는 것이다. 그렇기에 이런 방식을 택한다면 개발효율성도 늘어날 것이며 속도도 빨라질 것이다. 

 

그렇다면 사람이 생각하기에 편한것 즉 사람에게 익숙한것, 우리가 보고 느끼고 듣고 하는 모든 것을 대신 해주는 것이 딥러닝이 하는 일인데 그럼 과연 객체지향적으로 실세계를 바라보고 분석하는 것을 딥러닝을 대신 해줄 수 있을까? 

왜냐면 직관과 통찰이 필요한 분야에서 딥러닝은 큰 효과를 발휘한다. 우리가 보고 듣는 것을 너무나 자연스럽게 하는 것처럼 딥러닝 또한 computer vision을 통해서 결과를 도출해낸다. 


아쉽게도 방금 찾아봤는데 이미 있다. 하지만 자세히 살펴보니 어떤 제품이 만들어진것이 아니라 지금은 어떤 논문의 단계에 있는 것 같다. 날짜가 최신인데 아마 조만간 관련된 제품이 나오지 않을까 싶다. 코파일럿도 나왔는데 이런 제품도 나오면 또한번 유튜버들이 난리법석을 떨면서 이 내용을 다루지 않을까.  (아래에 관련 링크가 있다. )

 

https://ieeexplore.ieee.org/document/9092144

 

A Sketch of a Deep Learning Approach for Discovering UML Class Diagrams from System’s Textual Specification

Drafting a formal or semi-formal model describing the functional requirements of a system from a textual specification is a prerequisite in the context of a model-driven engineering approach, such as the model-driven architecture initiative proposed by OMG

ieeexplore.ieee.org


중요한건 객체지향이 만능이라는 게 아니라 우리에게 가장 친숙한 개념이라는 선에서 머물지 않을까 싶다. 와중에도 다른 패러다임들은 필요가 있는 곳에서 반드시 쓰여야할 것이다. 

 

함수형프로그래밍에 대해서 저번에 교수님께서 하신 말씀이 기억이 나는데 기본적인 폰노이만 아키텍쳐로 인해서 발생하는 오버헤드를 함수형 프로그래밍을 통해 성능 향상을 이끌어낼 수 있다라는 말씀을 하신 적이 있다.

 

기본적인 폰노이만 아키텍처는 아주 간단히 말해서 메모리에서 값을 가져와서 ALU에 연산을 진행한뒤 다시 그 값을 메모리에 쓰게 된다. 즉 읽고 연산하고 다시 쓴다. 즉 왔다가 갔다가 또 간다. 이리저리 왔다갔다 한다. (이부분에서의 성능 향상을 말하고 싶은거다.) 그런데 함수형프로그래밍에서 변수의 의미에 대해서 말씀하시면서 연산할적에 변수의 값이  (이부분은 지금 맞는걸 얘기하는지는 잘모르겠다. 정확하게 기억이 맞는지는 모르겠지만 지금 쓰면서도 아리송해서 함수형 프로그래밍에서의 변수의 의미에 대해서는 나중에 좀더 알아봐야 겠다. )  중간에 메모리에 쓰는 과정이 없고 결론적으로 모든 연산이 끝나고 난뒤에 그 값을 메모리에 쓴다고 했다. 그래서 이로인해 어느정도 성능향상이 이뤄질 수 있다고 말씀하신 것 같다. 왜냐면 왔다갔다 하지 않아도 되니까. 

 

-> 위에서 아리송하다고 했는데 근접한 답을 알아냈다.

 

함수형프로그래밍에서는 변수의 연산에 접근할적에 y = F(X) 와 같은 방식으로 접근한다. 즉 진짜 우리가 수학적 수식으로 함수 사용할때처럼 작동을 하는데, 즉 흔히 어떻게 떠올리면 되냐면 변수 설명할때 자주 나오는 박스를 떠올리면 된다. 

X 가 F라는 박스에 들어가서 x제곱이 되었든 뭐가 되었든 값이 나온다. 즉 정말 결과값만 딱 나온다. 하지만 함수형이 아닌 프로그래밍에서는 연산을 진행하고 중간값을 다시 메모리셀에 쓰고 다시 읽어오고 하는 과정을 반복한다. 여기서 오버헤드가 발생하는 뜻이지 않나 싶다. 

 

뭐 아무튼 객체지향이 아닌 다른 패러다임 언어도 쓸 이유가 있다는 걸 말하고 싶었던 것 같다. 물론 아직 내가 접해본건 절차형과 객체지향이 전부다. 언젠가부터 스칼라같은 함수형 프로그래밍언어를 한번 써보고 싶다는 생각을 했는데 솔직히 말해서 지금 어디서 어느 프로젝트를 만들면서 어떻게 써야하는지 모르겠다. 그리고 가장 중요한건 굳이 지금 왜써야하는지 모르겠다. 즉 지금 내가 만들 계획이 있는 프로젝트나 내가 상상하고 있는 프로젝트들에서 굳이 쓸 이유는 없다라는 생각때문에 일단 원래하고 있던 걸 계속 공부하고 있는 중이다. 언젠가 필요할때가 올텐데 그때 배워서 쓰면 되지 않을까 싶다. 

 

만약 필요한 순간이 오면 마틴오더스키의 Prgramming in Scala 4/e가 있던데 이걸 읽는게 제일 좋을 것 같다. 

 

반응형