객체지향의 몰락

프로그래밍 언어 책을 보면 대뜸 '객체지향'이라는 말 부터 나온다.

파이선이든, 루비든, C++ 이든

파이선이란 이런 거예요? 라고 간단히 소개 한 후
다음 페이지에 대뜸 객체지향 어쩌고..

루비란? 이런 거에요?
이것도 마찬가지로 바로 다음 페이지엔 객체지향 어쩌고.

C++ 도 마찬가지다.

객체지향? 설명 들어 보면 그리 어렵지 않다.

뭔진 모르겠지만 객체지향 좋은 건가 보다? 이 정도 느낌?
애초에 컴공 전공도 아니고... 그렇게 대충 넘겼다.

프로그래밍 언어를 짤 때 정말 빡치는 순간이 있다.
틀릴때? 원하는 대로 작동 안할 때? 코드가 엉망진창일때?

아니다.

코드가 완벽한데 틀렸다는 메시지가 뜰 때다.

틀리면? 인정하면 된다.
이상하면? 수정하면 그만이다.

아무리 봐도 이상한게 없을 땐, 뇌정지가 온다.
방법이 안보이다. 막막하다.

그래도 세상 좋아졌다. AI 한테 물어 보니 바로 답해주더라
『그러니까 니 말은 '객체지향' 이란 것 때문에 이건 안되고 이건 이렇게 해야 한다는 거지? 』

아무튼 저땐 이렇게 생각했었다.
내 실력이 별로니 이런거지 익숙해지면 편해지겠거니...
아무튼 그렇게 생각하던 시절이 있었다.

반대였다.
『그러니까 문법이 이따위인 이유가 '객체지향' 때문이라고?』

『이 클래스는 이거랑 이게 안된다고? 진짜 등신 처럼 만들었네 』
-> 당시엔 클래스 만든 놈을 욕했지만 나중에 알고 보니 객체지향이라는 철학 때문이었다.

『그냥 복사 하면 작동해야지. 왜 굳이 컴프리헨션 시키는데?』
-> 리스트 문제 같지만 이것도 사실 범인은 '객체지향'이었다.

뭔가 직관적이지 않게 작동한다?
추적해 보면 범인은 거의 100% '객체지향'이라고 보면 된다.

암튼 입문서에서는 '객체'란 붕어빵 틀 정도라고 설명해 놓았지만
내가 볼땐 사기다. 별 쓰잘데기없는 거에 '인격'을 부여한다는 느낌에 더 가깝다.

예를 들면 숫자 1 을 객체화 한다는 건 1 인격을 부여한다는 느낌이다.
더 쉽게 표현하자면 숫자 1에게 '주인공'이 될 자격을 준다는 뜻이다.

헛소리 같아 보이는게 당연하다.
'객체지향' 보고 수십년 경력의 개발자들 조차
'객체지향'은 직관적이지 않다고 말하는 정도니까.

극단적인 케이스로 파이선에 join 함수가 있다.
엑셀에 textjoin 과 같은 놈인데 관상부터 희한하다.

"-".join(['아이브','리센느','뉴진스'])

엑셀 문법으로는
textjoin("-",1,{"아이브","리센느","뉴진스"}) 와 정확히 같다.

결과는
"아이브-리센느-뉴진스"

이거 이거 자세히 보면 황당하다.
첨엔 AI가 날 놀리는 줄 알았다.

"-".join(['아이브','리센느','뉴진스'])
이 공식에서 주인공은 "-" 라는 문자다.

주인공 "-" // 조연 join // 자료 ['아이브','리센느','뉴진스']

아무튼 저 문법은 이런 뜻이다.

"-" 글자 쪼가리가 주인공이고
그 놈이 join 이라는 함수를 갖고 있고(전문용어:메서드)
그 함수에 니가 합치고 싶은 재료를 넣어라.

엑셀 기준으로는 이상한 설명이지만
객체지향 논리로 풀어서 설명하면 저렇게 된다.

이 문법이 직관적이라면 대단한 재능이라 생각한다.
보통 몇년 씩 고생하는 부분이다.

다만 파이선의 join은 좀 극단적인 경우다.

파이선보다 객체지향이 더 강한 루비란 언어를 보면
구분자가 아니라 [자료]가 주인공이다.
[자료].join("-")
이게 더 직관에 맞고 실제로 다른 언어들도 보통 이런 식으로 한다.

파이선이 정말 특이한 경우다.

다만 엑셀이 특이하게 저걸 카피했다. (TEXTJOIN)

textjoin 을 볼때?
왜 별로 중요하지 않은 구분자를 앞에 두지?란 의문을 가졌었는데
무지성 '파이선 카피' 라서 그런거 아닐까 추측한다.

다른 언어들이 파이선 아이디어들을 그렇게 많이 훔쳤어도
join 함수 만큼은 거부했는데
유독 엑셀만 저걸 그대로 가져왔다.

만약 생각이란 걸 했다면 저걸 그냥 베끼진 않았을 텐데?

파이선의 join은 뇌절한 경우고

사실 객체지향이란 것들이 저정도로 까지 이상하진 않다.

물론 이상하지 않다는 말은 더더욱 아니다.
되게 애매하게 이상하다.

뭐 이딴 쓸데 없는 걸로 고생시켜? 딱 이정도 느낌이다.

저렇게 된 이유는 '객체지향'이 사실 '종교' 였기 때문이었다고 한다.
한 5년 전만 해도 객체지향을 비판하면 '이단' 취급 받았다고 한다.

객체지향 환자들을 보면 광신도랑 별 차이 없다.

프로그램이 제대로 작동 안하면
'객체지향'을 까는게 아니라
내가 '객체지향'을 제대로 익히지 못했구나. 이런다.

종교가 잘못된게 아니라.
내 믿음이 부족한게 문제구나? 라는 식의 사고 방식 말이다.

걔들 전문 용어로는
SOLID 라는 계명을 제대로 지키지 못했구나
디자인 패턴 22 가지를 아직 잘 쓰지 못하는 구나.

암튼 '객체지향'이 문제가 아니라 지 탓 한다.

하지만 현실은 다르다.(유튜브 번역)

@connorwilliams2999
1년 전
이 의견에 전적으로 동감합니다. 저는 10년 동안 소프트웨어 엔지니어로 일하면서 대부분의 시간을 객체 지향 방식으로 배우고 코드를 작성해 왔습니다. 하지만 이 프로그래밍 스타일이 규모 면에서 어떻게든 성공하는 모습을 본 적이 단 한 번도 없습니다. 제가 직접 코드를 작성하든, 함께 일하는 수많은 개발자들이 이 스타일로 코드를 작성하든 마찬가지입니다. 물론 작동하는 앱을 프로덕션 환경에 배포할 수는 있겠지만, 객체 지향 프로그래밍이 약속하는 체계성, 상호 운용성, 유지보수성은 현실에서 전혀 실현되지 않습니다. 객체 지향 코드베이스가 커질수록 유지보수성은 떨어지고 오류 발생 가능성은 높아집니다. 객체 지향 프로그래밍의 특성 때문입니다. 마치 이 방식이 통하지 않으면 틀렸고 멍청한 것이고, 객체 지향 코드를 작성하는 것이 틀렸고 멍청하다고 생각하는 사람은 객체 지향을 이해하지 못하는 것이고, 이해할 만큼 똑똑하지 못한 사람이라는 식의 광신적인 사고방식이 있는 것 같습니다. 솔직히 말해서, 8년간의 컨설팅 경력 동안 "올바른 방식으로 개발하는" 개발자를 한 명도 만나보지 못했습니다. 왜냐하면 객체지향 프로그래밍(OOP)에는 "올바른 방식"이라는 게 없다고 생각하기 때문입니다. OOP를 사용하면 20%가 같은 기능을 하는 1만 개의 인터페이스를 만들어 엄청난 혼란을 초래하게 되고, 시간의 90%는 OOP/SOLID 원칙을 굳이 필요 없는 문제에 억지로 적용하려 애쓰는 데 허비하게 됩니다. 사용자들은 그런 원칙에 전혀 관심이 없죠. OOP는 "대혼란 만들기 지향 프로그래밍(Making a Big Osm Oriented Programming)"이라고 부르는 게 더 적절할 것 같습니다. 지난 3~4년 동안 저는 명령형/함수형 프로그래밍 스타일로 전환했는데, 그 결과 팀들이 상상 이상으로 빠르게 제품을 출시할 수 있게 되었습니다. 문제를 파악하고 필요한 코드만 작성하기 때문이죠. 버그도 줄었고, 모두가 코드를 더 잘 이해하며, 소프트웨어 아키텍처나 디자인 패턴에 대한 쓸데없는 회의도 더 이상 하지 않습니다. OOP는 여러분의 코딩 속도를 늦추고 코드를 엉망으로 만들 것입니다. 왜냐하면 OOP는 똑똑해 보이고 싶어 하고, 아무도 따라가거나 이해할 수 없는 코드를 "그게 올바른 방법"이라고 생각하며 작성하는 사람들을 위한 것이기 때문입니다. 케이시 무라토리와 같은 훌륭한 엔지니어들도 이러한 생각을 공유하고 있으며, 저는 여전히 OOP로 코딩하는 모든 분들께 다른 방법론에 대해 알아보시기를 권합니다.

'OOP'는 '객체지향' 약자다.

전문가 싸움 같지만 실은 '종교싸움'이다.
위에 올린 댓글과 달리 여전히 객체지향을 믿는 사람도 많다.
완벽한 객체지향을 만들면 될거라는 믿음 말이다.

그래서 이런 조롱도 있다.
@WoodymC
4년 전
직원: 저희는 지금 POOP를 연습하고 있어요.
지원자: POOP가 뭐예요?
직원: 제대로 된 OOP(Proper OOP)를 의미합니다.

교리가 잘못된게 아니라
믿음이 부족하다는 식의 사고 방식을 비꼰 글이다.

암튼 현업 종사자들은 중심으로 비판 여론이 커지는 추세다.

@artxiom
2년 전
객체지향 프로그래밍(OOP)은 스스로가 만들어낸 문제를 해결하려 합니다. 유용하고 기능적인 추상화와는 달리, 추상화를 위한 추상화에 가깝습니다

@sagitswag1785
2년 전
@ steveripberger1802 "객체지향 프로그래밍을 올바르게 작성하는 방법은 시간의 90%를 객체지향 프로그래밍을 사용하여 문제를 해결하는 데 투자하는 것입니다

@ikarosouza
3년 전(수정됨)
아키텍트 관련 이야기를 하자면, 제 최고의 업무 경험은 회사에서 새로운 프로젝트를 시작했을 때였습니다. 프로젝트 시작 당시, 수석 아키텍트는 우리가 구축할 백엔드의 주요 "모듈"들을 이미 모두 계획해 놓은 상태였습니다. 그런데 한 달 만에, 계획된 부분이 제대로 작동하지 않아 일부를 수정해야 했습니다. 결국 저는 모듈 이름만 남기고, 계획된 내용의 약 50%를 변경하거나 완전히 "재설계"해야 했습니다

@Ogbobbyjohnson92010
2년 전
객관적으로 좋은 OOP는 객관적으로 나쁘다.

@MauriMahtava
2년 전
(축약)... OOP를 사용하는 프로젝트들은 대부분 무겁고 비용도 많이 드는 경향이 있습니다.

@martingeorgiev999
1년 전(수정됨)
좋은 지적입니다. 요즘 초보 프로그래머들은 프로그래밍 방법을 배우는 게 아니라 객체지향 프로그래밍(OOP) 원칙을 따르는 법만 배우고 있습니다. 이는 개발자와 OOP 패러다임 모두에게 해로운 일입니다. OOP는 그저 도구일 뿐입니다. 종종 공개 API를 설계할 때 그 도구를 사용하는 것이 가장 좋지만, 모든 곳에 OOP 방식을 적용하는 것은 비합리적입니다. 모듈에서 내보내지도 않을 복잡한 인터페이스 계층 구조를 작성하는 데 몇 시간을 투자할 이유가 있을까요? 나중에 확장하기는 더 쉬울지 모르지만, 결국 확장해야 할 때 (만약 필요하다면) 다시 작성하는 것이 처음부터 "OOP 방식"으로 작성하는 것보다 훨씬 효율적입니다.

그래서 2020년대 만들어진 최신 언어들은 이렇다.

@BlackistedGod
7개월 전
재밌는 건, 최근에 나온 언어들 중에는 객체지향 프로그래밍(OOP)을 아예 사용하지 않는 언어들이 많다는 겁니다. 예를 들어 Go, Elixir, Rust, Zig, Oden, V 같은 언어들은 고전적인 OOP 스타일을 버리고 캡슐화와 다형성을 다루는 자신들만의 방식을 가지고 있죠.

🤮 1. "클래스(Class)와 상속(Inheritance)을 아예 법으로 금지하다"
Go 언어에는 class라는 단어 자체가 아예 없습니다. 당연히 부모 상자가 자식 상자한테 족보를 물려주는 상속 기능도 법으로 금지되어 있습니다.

여기서 가장 주목할 건 Go 라는 언어다.
구글이 자기들이 쓰려고 만든 언어다.
'객체지향'을 엄청나게 축소했고 사실상 금지라고 봐도 될 정도다.

연봉 10억을 넘게 받는 엔지니어 집단 조차 객체지향을 금지 시켰다는 의미다.

종교가 깨지는 곳은 '전쟁터'다. 기도해 봤자 총알은 막지 못하니까.
신성한 상아탑 속에서 학생들 가르치고 책이나 쓰시는 분들은 깨기 어렵다.

'객체지향' 소개 영상을 보면 누구나 혹할만한 엄청과 비전과
멋진 것들을 아주 쉽게 척척해내는 모습을 볼 수 있다.
솔직히 나도 혹했다.

그러데 실은 그거 "밥아저씨의 쉽죠?"다.

아무튼 비전이나 매력적인 요소가 많기 때문에 여전히 신자들이 있고
고고한 상아탑에 계시는 분들이 여전히 믿기 때문에 학생들이 그걸 배우고 나오는 것 뿐이다.

아직은 종교전쟁 중이긴 하지만 지금은 분위기가 바껴서 객체지향이라는 종교는 깨졌고
필요하면 '객체'를 쓴다 정도다.

최신 트렌드는 '데이터 지향(DOD)'이다.
'객체지향(OOP)'와 정반대다.

객체지향에 가장 적합한 장르가 '게임'인데
게임 조차도 이젠 '데이터'지향으로 갈아 탔다.

엑셀 기준으로는 어렵지 않다.
엑셀은 기본적으로 데이터 지향이다.

객체지향이란 건 이렇게 보면 된다.
'김독자', '한성현', '강유진', '서지후'....

이런 식으로 주인공 이름 기준으로 파일을 관리하는 방법이
객체지향과 비슷한 방법이고

모든 데이터를 시트에 모아 raw 데이터로 하고
필요한 정보를 불러오는 (엑셀러들에겐 당연한)
이런 게 바로 데이터 지향이다.

그래서 이런 비유도 있다.
@mirandansa
11개월 전
객체지향 프로그래밍으로 글을 쓰는 것은 마치 명사만으로 소설을 쓰고 나서야 이야기가 없다는 것을 깨닫는 것과 같습니다.

혹시 프로그래밍 언어에 관심 있으신 분이 계시다면
'객체지향'이란 말에 낚이지 말고
구닥다리 문법이구나 하는 정도로 넘기시면 좋을 거 같습니다.