‘이건 정말 못 참아!’ 자바가 미움 받는 15가지 이유

긴 카멜케이스(CamelCase) 이름 첫 번째 문자를 대문자로 표시하는 방법을 사용해서 긴 문장을 묶어 변수 이름으로 만든다는 개념은 식상하다. 이 방법이 코드 자체에 설명적 기능을 부여한다는 데는 의심의 여지가 없지만 다음 두 라인을 비교해 보자. i // holds the interest rate before taxes as per regulation 43 위가 당연히 아래의 경우보다 읽기가 쉽다. interestRateHoldingVariableAdjusted ForTaxesAsDefinedByRegulation43

구두점 자바와 새로운 언어 간의 가장 큰 차이점을 한 가지 꼽자면 바로 구두점이다. 자바 프로그램에는 중괄호, 세미콜론, 그리고 괄호가 꽉 들어차 있다. 그루비 또는 루비와 같은 다른 언어에서는 이러한 모습을 볼 수 없다. 물론 구두점 애호가들 역시 자바와 같은 구두점 대신 이해하기 어려운 공백 규칙을 사용해서 식과 블록을 구분하는 파이썬과 같은 언어에 대해 불만이 없는 것은 아니다. 그러나 대부분의 프로그래머는 구두점을 지긋지긋하게 여기며, 시각적 공해이자 컴파일러에서 끊임없는 오류를 유발하는 원인으로 생각한다. 결국, 가장 쉬운 해결 방법은 취향에 따라 그루비를 쓰거나 자바를 쓰는 것이다. 어쨌든 코드는 같은 JAR로 컴파일할 수 있다.

오픈 소스 혼란 자바는 오픈 소스인가, 아닌가? 어떤 라이브러리가 오픈 소스인가? 구글과 오라클 간의 긴 싸움이 끝났지만, 여전히 모르겠다. 대부분의 경우 자바 프로그래머는 걱정할 필요가 없다. JRE와 JDK는 무료로 제공되기 때문이다. 그러나 우리 마음 한편에는 언제든 변호사가 불쑥 나타나 앞을 막아설지 모른다는 불안감이 항상 자리 잡고 있다. IBM, 오라클, 구글 사이의 싸움에서 우리가 모두 인질로 잡혀 있는 듯한 기분이다.

자바 스레드 양돈장 자바가 등장했던 시점만 해도 스레드는 다른 방법에 비해 가벼웠다. 여러 작업을 같은 메모리 공간에서 요리조리 다루기 위한 손쉬운 방편이었다. 현재 Node.js를 사용하는 개발자는 자바 서버 플랫폼이라고 하면 고개를 젓는다. 자바 스레드 팩토리는 누군가가 웹 링크를 클릭할 때마다 서버 RAM 프로파일에 2MB씩 살을 찌운다고 해서 양돈장에 비유되곤 한다. 자바 스레드 모델을 사용하는 것은 예전보다 절대 가볍지 않다(무거워졌다는 건 자바로 프로그래밍하는 사람들도 마찬가지지만 그건 문제 해결과는 아무런 상관도 없다).

참을 수 없도록 느린 시작 자바를 사용해서 안드로이드 앱을 만들고자 한 경험이 있다면 데스크톱에서 시뮬레이터 코드가 얼마나 느리게 실행되는지 잘 알 것이다. 자바 프로그램을 실행하기가 토요일 아침 일찍 10대 아이를 깨워 방을 치우도록 하기만큼 어렵다는 말이 괜히 나온 것이 아니다. 자바 앱은 일단 시작되면 상당히 매끄럽게 움직이지만, 문제는 그 시작 속도가 짐을 가득 실은 대형 트럭이 오르막길에서 정지 신호 후 출발할 때의 시작 속도와 맞먹는다는 사실이다.

끝없는 널 포인터 확인 이 불평에 대한 근거? 잠깐 이게 널인지 확인하고 넘어가자. 문제없는 것 같다. 키보드가 널 요소로 대체되지 않고 제대로 잘 있는지도 확인해야겠다. 잘 있다. 그럼 이제부터 널 테스트에 대해 왜 불평하는지 알려주겠다. 자바는 끝없는 if 문으로 변수가 널로 끝났는지 테스트할 것을 요구한다. 널로 끝나지 않으면 NullPointerExceptions 오류가 발생하며 전체 스레드가 작동을 멈춘다. 잘난 척하는 개발자라면 애초에 입력을 확인하지 않은 내 잘못이라고 말하겠지만, 라이브러리를 만들 때는 확인이 불가능할 때도 있다. 앞으로 누군가가 이 클래스 파일을 사용하려고 한다면 모든 변수를 다시 확인하는 것이 좋다. 이들이 이 파일을 어떻게 재사용할지 알 수 없으니까.

객체 생성 오버헤드 모조리 객체로 밀어 넣는 것은 깔끔하게 프로그래밍하는 방법처럼 생각되지만 그건 자바 객체를 만드는 속도가 얼마나 느린지 알기 전의 이야기다. 속도를 높이기 위해 코드를 리엔지니어링 하는 경우 열이면 열 가장 먼저 하는 작업은 최대한 객체 지향 모델을 걷어내는 것이다. 객체 생성은 상대적으로 리소스 소비가 크며 일부 자바 코드에서 속도 저하를 유발하는 가장 큰 이유이기도 하다.

데이터 구조를 사용하기 위한 프리미티브 래퍼 자바 컬렉션 클래스와 기타 데이터 구조는 좋지만, 사용하려면 기본값을 객체에 래핑해야 한다. 즉, 4바이트 int 하나가 비대한 객체가 되고, 따라서 객체의 무거움과 생성 시간을 감수해야 한다는 의미다. 어떤 프로그래머는 이 문제를 피하려고 기본적인 프리미티브(Primitive)를 사용하여 자기만의 데이터 구조를 만들기도 했지만, 주류 자바에 적용하기에는 너무 늦었다. 4바이트 int와 Integer 객체를 구분할 수밖에 없다.

크고 오버헤드가 필요하며 변경할 수 없는 문자열 문자열도 또 하나의 객체인데, 변경할 수 없다. 처음에 제대로 하는 수밖에 없다. 1바이트를 변경하려면 완전히 새로운 객체를 만들어서 모두 복사해야 한다. 또한, 오버헤드가 추가된다. 큼직한 텍스트 블록들을 이리저리 옮기는 경우에는 문제가 없지만 작은 문자열들의 경우 정말 귀찮다. 선택권이 있을까? 없다. 다만, 시작 지점과 끝 지점의 오버헤드가 자르고 있는 작업을 할 때는 유용하다는 것이 위안거리일 뿐이다.

전역 변수 없음 프로그래머가 자바에서 전역 변수의 부재에 대해 불평한다면 그건 솔직하지 못한 것이다. PHP와 같은 다른 언어에 사용되는 전역 변수의 위험에 대해서도 언제든 불평할 것이기 때문이다. 아무튼, 전역 변수가 있다면 간단한 일을 많은 고생을 해가며 해야 한다는 점은 사실이다. 어떤 사람들은 Global 클래스를 만들고 여기에 정적 변수를 집어넣는다. 항상 하나의 객체를 반환하는 get 루틴을 사용해서 싱글톤 객체를 만드는 사람도 있다. 싱글톤 객체를 만들 때 경합 조건과 효율성에 대한 문제만 따르지 않는다면 괜찮은 방법이었을 것이다.

자바가 주요 공격 목표라는 것이 자바의 잘못은 아니라고 할 수 있다. 다른 플랫폼에는 더 많은 보안 결함이 있고, 적어도 자바 엔지니어는 견실한 샌드박스를 만들기 위해 노력했다고 변호할 수도 있다. 또한, 보안 문제는 필연적이며 최소한 오라클은 버그 수정을 공개한다는 점을 내세울 수도 있다(작년에 발표된 42개의 보안 수정과 같이, 보통 대량으로 내놓음). 모두 일리가 있는 말이지만 그렇다고 자바를 사용하는 일상이 더 수월해지지는 않는다. 자바의 인기가 높은 만큼 많은 해커가 JVM을 대상으로 공격한다. 자바의 보안 모델은 많은 프로그래머가 JVM을 신뢰한다는 것을 의미한다(무조건 신뢰해서는 안 됨에도 불구하고). 소프트웨어가 완벽하다는 것을 믿을 수 있다면 얼마나 좋을까.

JVM 프리로더 현재 많은 언어가 자바 바이트코드로 컴파일되므로 이들은 어떤 JVM에서도 실행할 수 있다. 그러나 호환성과 다양한 플랫폼에서의 실행 가능성만 놓고 보면 클로저(Clojure), 스칼라(Scala), J루비(JRuby), 리노(Rhino) 등 다른 대안이 얼마든지 있다. 이런 점은 통합에서는 장점이 될 수 있다. 예를 들면 자바와 루비 같은 경우다. 그러나 동시에 필연적으로 혼란이 야기되기도 한다. 어느 날 갑자기 현재 가진 라이브러리로는 자바 코드를 컴파일하기에 충분치 않은 경우가 발생하는 식이다. 이제 개발자들은 JVM에서 문제없이 실행되는 N-언어에 대해서도 걱정해야 할 처지가 됐다. 이것이 구현되면 자바 스택의 힘을 증명할 수 있겠지만, 모든 개발자에게 새로운 골칫거리가 될 수 있다.

리비저니즘 자가발전은 일반적으로 환영할 만한 것이지만 자바 스택의 세계에서는 새로운 혼란을 유발할 수도 있다. 예를 들어 최신 버전 스트링빌더(StringBuilder) 클래스를 사용하는 것이 좋을까 아니면 오래된 스트링버퍼(StringBuffer)를 사용해야 할까? 혹은 스트링빌더가 더 오래된 것일까? 어쩌면 같은 것은 아닐까? 적어도 새 IO 클래스와 NIO는 구 버전보다 신 버전을 기억하기가 더 쉽다. 자바 스택의 세계에는 매력적인 신기술과 신버전이 매우 많다. 이들은 자바 스택의 세계를 더 풍부하게 하고 새로운 발전을 구현하고 있지만, 개발자들에게는 이 수많은 문법을 새로 배워야 한다는 것을 의미한다.

헤아릴 수 없는 방대함 공식 자바 API와 아파치 같은 그룹이 내놓은 비공식 오픈소스 패키지 같은 것들은 자바를 더 충실한 개발환경으로 만들어 준다. 문제는 이 모든 것들의 존재를 모르면 제대로 이용할 수조차 없다는 것이다. 이 다양한 API 중에서 나에게 정말 필요한 것이 무엇인지 찾아내는 데만 며칠이 걸릴 수도 있다. 물론 그 후에는 더 큰 문제가 기다릴 수 있다. 다른 개발자가 사용하는 것이 더 근사해 보일 수 있다는 것이다.

자바는 모든 곳에 있다 '자바는 모든 곳에 적용할 수 있다'는 말이 있다. 휴대폰과 블루레이 디스크, 하둡 클라우드, 데스크톱 등 한계가 없다. 그러나 이것이 과연 기뻐할 일일까? 실제로 바로 이 점이 자바가 미움을 받는 이유가 되기도 한다. 이 모든 버전을 관리하기가 더 어려워지고 있기 때문이다. 심지어 자바 버전의 변화를 추적하기만 하는 정규직 일자리가 있을 정도다. 예를 들어 1.6에서 1.7로 업그레이드할 때 고쳐야 할 것은 무엇일까? 어떤 아파치 커몬이 좋을까? 같은 것들이 모두 새로운 일이 되는 것이다. 어떤 의미에서 자바 전문가가 된다는 것은 사실상 불가능하다. 어느 정도 수준에 오르면 새로운 언어가 짠~하고 등장해 ‘너는 더는 자바 전문가가 아니다’라고 계시를 하기 때문이다.