이전 포스팅에서는 자바의 시작과 철학에 대해 정리해봤다. 이번 포스팅에서는 지금까지 자바가 어떻게 변화했는지에 대해 정리해보고자 한다.
Java의 현 주소
설명에 앞서 약간의 사족을 붙이자면 학교에서 "프로그래밍 언어론"이라는 전공 강의를 수강한 적이 있는데, 교수님께서 앞으로 프로그래밍 언어가 어떻게 바뀔 것인가에 대한 주제로 강의를 해주신 적이 있다.
결론적으로 교수님께서는 프로그래밍 언어가 점점 더 자연어를 닮아갈 것 같다고 말씀하셨는데, 최근 코틀린 언어를 습득하고, 자바의 변화에 대해 조사하다 보니 정말 그럴 것 같다는 생각이 들었다.
현재 26년 1월 기준 자바는 25버전까지 출시된 상태이다. 처음에는 25년도에 릴리스해서 25버전인가? 라고 생각했었는데 아니었다.. 그냥 우연히 맞물렸던 걸로..
자바 10(2018년)부터 기능 중심의 릴리스에서 일정한 시간마다 반드시 릴리스하는 방식으로 변화를 결정했고 이전과 비해 상당히 자주자주 릴리스되게 되었다(6개월 주기), 뿐만 아니라 주기적으로 안정판인 LTS 버전을 지정하여 8~10년동안 보안 업데이트를 보장해준다. 현재는 2년 주기로 LTS가 출시된다!
이와 관련된 자세한 내용은 오라클의 자바 플랫폼 그룹 수석 아키텍트의 블로그 포스트에 나와있다.(https://mreinhold.org/blog/forward-faster)
이렇듯 자바는 많은 버전이 존재하는데 포스팅 분량과 시간 상 모든 버전의 변화를 상세히 다루기는 어렵다고 생각해 중요하고 큰 변화가 일어난 자바 버전에 대해 중심적으로 조사하고 설명해보려고 한다(특히 8버전).
Java 8 버전 등장 시기의 배경
우선 자바 8버전 등장 시기의 배경에 대해 먼저 알아보려고 한다.
멀티코어 CPU의 대중화, 멀티쓰레딩 프로그래밍의 중요성 대두
위 시기에 멀티코어 CPU가 대중화 되었는데 이러한 배경이 자바 8에 꽤 큰 영향을 미쳤다고 할 수 있다. 특히 점점 개발자가 다뤄야 하는 데이터의 크기가 늘어남에 따라 멀티 쓰레딩 프로그래밍의 중요성이 부각되었는데, 이전까지의 자바 프로그램은 프로세서가 멀티 코어여도 나머지 코어는 유휴 상태로 두는 등 싱글코어 환경에 좀 더 최적화 되어있었다고 한다.
때문에 나머지 코어를 활용하려면 개발자가 직접 OS 스레드(Native Thread) 를 사용해야 했다. 하지만 알다시피 멀티스레딩 프로그래밍은, 컨텍스트 스위칭, 동기화, 데드락 등등.... 고려할 문제가 많기 때문에 여러모로 문제가 많이 발생할 수 있다.
(사실상 싱글코어에 최적화라기 보단 멀티코어를 활용하기 어려웠다...고 보는게 좋을 것 같다.)
개발 팀은 사실 자바 1.0부터 이를 고려하여 락 기능이나, 메모리 모델까지 지원했다고 한다. 하지만 당시에는 이렇게 최선의 선택을 해도 애초에 멀티스레딩 프로그래밍이 어려워서 전문가 팀이 아니면 잘 사용할 수 없었다고 한다.
여담으로 컴퓨터 네트워크 시간에 팀 프로젝트로 MVC 프로그래밍을 이용하여 ARP를 구현해야 했는데 계속 패킷을 날리고 받으려면 스레드를 사용해야해서 꽤나 고생했었던 기억이 있다...
사실 자바는 이를 해결하기 위해 이전부터 노력해왔다.
자바 5에서는 스레드 풀, 병렬 실행 컬렉션, 자바 7에서는 포크/조인 프레임워크를 제공했다. 하지만 결국 이러한 기능을 도입해도 멀티쓰레드 프로그램의 구현이 어려웠던 것으로 보인다.
이에 대한 이유는 추가로 조사하여 포스팅으로 남겨놓을 예정이다.
Java 8의 변화
위 문제의 해결을 포함하여 자바 8은 그렇다면 어떻게 바뀌었을지 찾아봤고 이제 이에 대해 소개해보도록 하겠다.
스트림 API 도입
자바 8에서는 멀티쓰레딩의 복잡한 관리를 사용자에게서 최대한 덜어내고자 하였다.
사용자가 작성한 코드를 스트림 라이브러리를 이용하여 최적의 저수준 실행 방법을 선택하는 방법을 도입하였다고 한다.
이에 대해 좀 더 생각해봤을 때, 그렇다면 스트림 라이브러리는 사용자의 코드를 입력으로 받는다는건지, 어떻게 사용자가 작성한 코드를 입력으로 받는지 의문이 들었다. 다행히 바로 다음에 이와 관련된 내용이 등장했다.
스트림 api와 관련된 더 구체적인 내용은 추후 학습을 더 진행한 후에 포스팅으로 남겨놓을 예정이다.
함수를 값의 형식으로 추가
자바 8에서는 함수를 아예 값의 형식으로 추가해버렸다. 사실 이를 처음 봤을 때, 함수를 구조체나 클래스 등으로 넣으면 나름 자유롭고 체계적으로 사용할 수 있지 않나? 라는 생각이 들긴 했다.
하지만 책에서는 값에도 계급이 있다는 내용으로 설명해 주었다.
String, Integer, Double 등의 값들은 일급(First Class)값으로 프로그램을 실행하면서(런타임에) 자유롭게 전달하고 받을 수 있다. 하지만, 그 당시 자바의 메서드는 일급 값이 아니었으므로, 프로그램 실행 시 전달하고 받는데 제약이 있었다,
즉 굳이 함수를 전달하려면 객체를 생성하고, 해당 객체를 넘겨준 다음에, 해당 객체에서 함수를 사용하는 방법을 사용해야 했다.
때문에 이러한 문제를 해결하기 위해 등장한 업데이트라고 할 수 있을 것 같다. 또한 이러한 변화는 함수형 프로그래밍에 큰 영향을 미쳤을 것이라 생각된다.
이와 관련된 내용도 추후 학습을 더 진행한 후 별도의 포스팅으로 남겨놓을 예정이다.
디폴트 메서드
우선 디폴트 메서드는 꽤 생소한 개념이었는데 어떤 메서드인지 핵심만 설명해보면 다음과 같다,
인터페이스에서 사용하는 메서드이다.
디폴트 메서드는 인터페이스를 구현한 클래스에서 구현할 필요가 없다.
결론적으로 자바 8에서는 구현 클래스에서 구현하지 않아도 되는 메서드를 인터페이스에 추가할 수 있는 기능을 제공하게 되었다.
그렇다면 해당 기능은 왜 추가된 것일까? 바로 앞서 소개했던 스트림 API의 도입 때문이었다. 컬렉션 인터페이스에 stream() 추상 메서드를 추가했다고 가정해보자,
디폴트 메서드로 구현하지 않는다면, 이 메서드는 구현 클래스에서 반드시 구현되어야한다. 때문에 이러한 상태에서 스트림 API를 구현하면 전세계의 구현 코드에 오류가 발생할 것이다.
때문에 자바 개발자들은 구현하지 않았을 때 사용할 수 있는 디폴트 코드를 인터페이스에서 제공할 수 있도록 하는 디폴트 메서드를 추가하게 된 것이었다.
그렇지만 여기서 또 기존에는 이런 기능을 추가하지 않은 이유가 있었을 것이다. 바로 다중 상속과 유사한 문제가 발생할 수 있다는 점인데 이에 대해서는 추후에 포스팅으로 정리하도록 하겠다.
Optional 클래스를 이용한 NullPointer 예외 회피
Null Pointer 예외는 개발자들이 가장 골치 아프게 겪는 예외 중 하나였다. 특히 이 예외는 컴파일 타임에 검출하기 어렵다는 문제가 있다.
자바 또한 이러한 문제를 겪고 있었기 때문에 자바 8 이전의 개발자들은 일일히 코드를 널 체크로 래핑하거나, 특정 패턴을 사용하면서 문제를 회피했다.
이와 관련된 내용도 추후 학습을 더 진행한 후 별도의 포스팅으로 남겨놓을 예정이다.
때문에 이러한 문제를 해결하기 위해 자바 8부터 Optional<T> 클래스를 도입하였다. 이는 값을 갖거나 갖지 않을 수 있는 컨테이너로 값이 없는 상황의 동작을 명시할 수 있게 했다.
지금까지 자바 8까지의 변화를 중점적으로 살펴보았다. 자바 8의 모든 변화 내용을 담지는 못했지만, 앞으로 자바를 점점 더 공부해 나가면서 계속 채워나가려고 한다.
'Java' 카테고리의 다른 글
| Java 8 이전의 멀티스레딩에 대해 알아보자: Thread Pool (0) | 2026.01.29 |
|---|---|
| Java 개념 장착하기 01 - Java의 시작과 철학 (0) | 2026.01.27 |