본문 바로가기
IT 공부/공부하며 알게된 사실들

왜 자바는 클래스를 난잡하게 쓰는 것일까 해답...!!

by exdus3156 2023. 11. 14.

 

 

왜 자바는 모든 것을 class로 처리하려는 것일까? (주절주절)

공부하면서 느끼는 제 개인적인 생각과 감정입니다... 자바는 클래스에서 시작해서 클래스로 끝난다. 처음부터 객체지향 설계 언어를 목표로 만들어진 언어라 그런가 싶다. 하지만 본질적으로

linocraft.tistory.com

 

이전에 내가 공부를 하면서 들었던 의문이 오늘 약간이나마 해소된 기분이다. 나는 이전에 왜 자바가 모든 것을 지나치다 싶을 정도로 class로 처리하려는 것인지 의문을 품었었다. 위 링크를 들어가면 상세한 내용을 볼 수 있다.

여기서 간단히 요약하자면, Java에서는 순수한 데이터 구조 (C언어로 따지면 struct) 마저 객체로 만들어버린다. 로버트 c 마틴조차 이런 스타일을 사이비 객체지향이라고 비판하기도 했다.

그런데 이런저런 공부를 하다가 우연히 아래의 영상을 보고 왜 자바가 이런 식으로 흘러가야만 하는 것인지 감을 약간 잡은 느낌이다.

 

 

PopeTV에서는 이렇게 OOP 언어가 지나치다 싶을 정도로 모든 것을 객체로 만들어버리는 것에 대한 이유를 알려준다. 다소 충격적인 내용이며, 개발자로 성장하고 싶은 나에게 무언가 울림을 준다. 

영상 내용을 요약하자면, 제목 그대로 OOP는 허접한 개발자들이 코드를 이것저것 건드리다가 시스템을 망가뜨리는 짓을 하지 못하게 막는 기능도 있다고 말한다. 물론 반드시 이런 이유 때문에 OOP가 생긴 것은 아닐테지만, 분명히 객체지향에서 말하는 온갖 기법들이 코드 수정 시 버그나 문제를 일으키지 않게 하는 것은 분명한 사실이다.

실제로 실력 있는 개발자들이 모인 기업에는 겉으로는 OOP 언어를 사용했으나 실제 코딩 스타일은 그다지 객체지향적이지 않았다고 한다. 게임 업계 또한 그랬다. 게임 업계에는 실력 좋은 프로그래머가 많았기 때문에 객체지향의 기법을 그다지 신뢰하지도, 유용하다고 생각하지도 않았다.

그래서 게임이나 기타 실력 좋은 프로그래머를 요구하는 산업의 기업들은 객체지향의 장점과 C, C++의 퍼포먼스 개선을 위한 코드를 전부 사용했다.

반대로 대기업에서는 실력 낮은 프로그래머들이 코드를 망가뜨리는 짓(?)을 하지 못하게 하기 위해 온갖 클래스들로 분리를 하면서 성능을 포기했다.

실력이 있는 사람끼리 모여 있는 경우, OOP 언어를 사용하면서도 제약을 많이 풀기도 했었다. 그러나 실력이 떨어지는 개발자들과 함께 하는 경우 제약을 많이 걸었다.

원래 실력이 정상인 프로그래머라면 함수를 고치거나 리팩토링할 때, 그리고 테스트를 할 때 주의를 세심하게 기울인다. 그러나 어떤 사람이 예를 들어, 로그인ID와 빌드ID의 매개변수 순서를 바꾸거나, 혹은 학생의 로그인을 자신(조교)의 ID로 착각해서 밀어 넣는 방식으로 에러를 일으키기도 한다. 타입이 같기 때문에 에러를 발견하지 못했던 것이다. 이런 경우 컨텍스트에 맞게 클래스를 만들기도 한다. 이것이 바로 실력이 없는 프로그래머들의 실수를 막으려고 쓸데 없는 코드를 만들어주는 것이다. 너는 이것만 써라. 이렇게 해라! 라고 지시하는 것에 가깝다.

필요한 문맥마다 클래스를 설계해 사용하는 것이 실수를 막을 수 있는 것이다. 이것은 어려운 실수가 아니라 부주의한 사람들이며, 이런 부주의함은 개발자에게서 나오면 안 되는 나쁜 습관이다.

특히 한국에서 하청받는 자바 코드 베이스를 보면 정말 이렇게 int 따위마저 문맥을 부여해 클래스로 만드는 것을 많이 봐왔다.

안타깝게도 이것은 성능을 극한으로 줄여버린다. 어떤 개발자들은 제품의 성능을 줄이면서까지 이런 짓을 해야하는지 싫어하기도 한다. 그런 개발자들은 언어를 바꾸기도 하는데, 왜냐하면 자바는 처음부터 이렇게 실력 없는 개발자들이 문제를 일으키지 않도록 만드는데 머물러 있기 때문이다.

 

결론

정말 필요한 해답이었으며, 이야기를 들으며 깨달았다는 신호가 와서 즐겁기도 했다. 그러면서 몇 가지 생각이 들었다.

첫 번째로는, 객체지향의 모든 기법을 마치 그 패러다임이 정답인양 떠받들지 말자는 교훈이다. 

객체지향은 그 개념을 보면 확실히 변경에서 올 수 있는 문제점을 방어하기 위한 전략들로 가득하다. SRP도 그렇다. 클래스의 책임을 분리하라는 것 자체가 클래스 내부의 코드를 건드려 다른 기능까지 망쳐버리는 짓을 하지 못하게 함이 아닌가!

그러나 하드웨어나 자료구조 및 알고리즘을 잘 아는 실력 좋은 개발자라면 객체지향의 코드는 번거롭게 느껴질 것 같긴 하다. 객체지향 또한 사용할 수 있는 하나의 전략일 뿐이지, 객체지향을 반드시 통달해야만 소프트웨어를 개발할 수 있고 그런 개념은 아닐 것이다.

두 번째로는, 나 스스로의 실력에 대한 반성이다.

솔직히 영상의 내용을 아주 못 따라가진 않았다. 나는 분명 첫 언어가 C언어였고, 게임 개발을 위해 인프런의 Rookis님의 C++ 강의를 통해 어셈블리어로 내부 성능의 차이를 분석하는 기법도 배운 적이 있었기 때문이다. 함수 스택이 쌓이는 방식이나 함수의 return 값이 어떤 어셈블리어를 통해 호출한 곳으로 전달되는지 이것저것 본 적이 있었다.

하지만 그러면서도 실무의 개발이 얼마나 매섭고 어려운지도 알게 되었다. 

나는 분명 개발 공부가 재밌긴 하지만, 과연 내가 성장 가능성이 충분한 사람이 될 수 있을까? 만약 내가 영상에서 언급된 허접한 개발자이며, 나를 위해 온 개발자들이 클래스를 이것저것 만들어서 데이터 타입을 strong 하게 설정하는 수고로움을 만들어야 한다면 그 굴욕을 내가 견딜 수 있을까? 이런저런 불안이 고개를 내민다.

열심히 공부했으나 실력이 뒤떨어지거나 공부한 기간 치고는 형편없는 평가를 받는다고 할 때, 과연 나는 어떤 마음가짐을 가지고 개발을 해야 하는 것일까? 어떻게 다시 용기를 낼 수 있을지 (아직 오지도 않은 미래를) 앞서 걱정하기도 했다.