자바(Java)의 역사에 대해서

자바의 로고

 

Write once, run anywhere - 한 번 쓰면, 어디서든 실행된다.

 

 위 문구는 자바를 대표하는 문구이다. 백엔드 개발자라면 누구나 한 번쯤은 접하게 되는 자바. 나 또한 피해 갈 수 없었는데, 시대생팀에서 서버를 개발하는 일을 맡게 되었을 때 나를 제외한 다른 팀원들이 스프링을 사용하기를 원했기 때문에 어쩔 수 없이 스프링으로 개발하게 된 적이 있었다. 뿐만 아니라, GDSC UOS 팀에서는 node를 사용하는 나를 제외한 모든 개발자들이 스프링을 사용하기 때문에 데일리 스크럼에서 자바와 관련된 이야기들이 오고 갔다. ex) 스프링 3.x 버전대에서 스웨거가 잘 안 되는 것 같다 -> 그 버전에서는 스웨거 오류가 있어서 swagger-ui 라이브러리를 써보실래요? 등..

 

예전부터 자바를 많이 쓴다는 것은 알고 있었고, 특히나 한국에서는 자바의 점유율이 높다고도 알고 있었다. 실제로 2023년 젯브레인즈에서 내놓은 통계에 따르면 백엔드 개발이 가능한 언어로는 파이썬 뒤를 잇는다. 

2023년도 개발자 에코시스템 현황

위 통계에 따르면 Java가 5위로 49%의 점유율을 꽉 잡고 있다. 1위와의 차이는 무려 12%p 차이밖에 나지 않는데, 자바의 바로 뒤에 바짝 붙어있는 Typescript라는 언어와는 15%p의 간격을 벌리고 있다. 세계적으로 자바는 굉장히 많은 사랑을 받고 있다는 증거로 볼 수 있다.

 

백엔드 개발을 파이썬과 node로 접해본 나로서는 자바에 대한 반감이 있었다. 개발하는 과정이 비교적 편리하고 빠른 node와 파이썬 같은 인터프리터와 다르게, 자바는 인터프리터인지 컴파일러인지 모호한 느낌이었고, JVM까지 뭔가 복잡한 역사와 사연이 많아 보였기 때문이다. 자바에 대해서 처음 접했을 때와 다르게 시간이 흘러 다양한 관점에서 자바를 바라보기도 하고, 자바와 관련된 분쟁, 역사 등을 조사해 보니 생각보다 재미있는 언어라고 느껴지게 되었다. 이번 포스팅에서는 자바라는 언어에 대해서 포스팅하려고 한다.

 

본론

자바의 역사

자바의 역사는 1990년대 초반에 시작된다. 원래 오크(Oak)라는 이름으로 선 마이크로시스템즈(Sun Microsystems)의 한 프로젝트에서 탄생된다. 이 프로젝트의 목표는 소비자 가전제품을 위한 언어를 개발하는 것이었는데, 오크는 특정 플랫폼에 국한되지 않는 보다 범용적인 프로그래밍 언어로 발전되게 됐다.

 

나중에는 이름이 Java로 변경되었는데, 창시자인 제임스 고슬링이 자바 커피 애호가로 자바 커피의 원산지인 자바(Java) 섬에서 이름을 가져와 Java라는 이름이 붙었다. 로고가 커피 모양인 이유를 알 수 있을 것 같다. 자바라는 이름으로 1995년에 발표되어 많은 사람들의 인기를 끌었다.

 

JVM (Java Virtual Machine)

 자바를 다른 컴파일언어와 구분 짓는 가장 큰 특징은 컴파일된 코드가 크로스 플랫폼이라는 것이다. 자바 컴파일러는 .java 확장자. 즉 자바 언어로 작성된 프로그램을 바이트코드라는 특수한 바이너리 형태로 변환하고, 이러한 바이트코드를 실행시키기 위해서는 JVM이 필요하다. 이 JVM은 자바 바이트 코드를 어느 플랫폼에서나 동일한 형태로 실행시킨다. 

 

이러한 JVM 덕분에 자바로 개발된 프로그램은 CPU나 운영 체제의 종류에 관계없이 어디서나 실행될 수 있으며, 한 번 쓰면, 어디에서나 실행된다는 철학과 맞아떨어진다.

 

예전에 포스팅한 글의 내용에 따르면 자바를 하이브리드라고 정의했다.

• 빌드 그리고 컴파일러와 인터프리터 : https://marsboy.tistory.com/12

빌드(build) 그리고 컴파일러와 인터프리터

 

C와 Java를 비교해 보자. C 언어로 쓰인 파일을 컴파일러를 통해서 빌드하면, 바로 CPU 자체가 실행시킬 수 있는 실행 파일이 나온다. 하지만 이러한 실행 파일은 OS와 CPU의 영향을 받는다. 당장 MacOS와 WindowsOS에서 간단한 Hello, world!를 출력하는 코드를 컴파일해 보면 확장자가 다르게 나오는 것을 알 수 있을 것이다. ( 윈도우에서는 a.exe, 맥에서는 a.out 실행 파일이 나온다! )

 

이러한 것을 생각하면 왜 Java가 하이브리드인지 알 수 있다. C는 CPU 레벨이 이해할 수 있는 수준까지 컴파일시켜 버리는 반면, 자바는 JVM이 이해할 수 있는 수준(바이트코드)까지만 컴파일한 후, 나머지는 JVM을 통한 인터프리팅 과정을 통해서 애플리케이션을 실행시키는 것이다. 컴파일러와 인터프리터의 속성을 섞을 생각을 하다니 재미있는 아이디어인 것 같다.

 

C의 이러한 플랫폼 의존적인 특징을 생각해 보면 그 시대의 개발자들은 많이 답답했을 것이다. 제 컴퓨터에서는 되는데요? 와 같은 쉽지 않은 일을 달고 살고 있는 셈이기 때문이다. 그렇기 때문에 실제 자바의 창시자 고슬링의 목표는 C/C++ 스타일의 언어와 가상 머신을 구현하는 것이었다. "Wirte Once, Run Anywhere"라는 문구를 약속하여 다양한 플랫폼에 무료 런타임을 제공하여, 자바의 인기는 급상승하였고 이후로 자바의 시대가 본격적으로 열리게 된 것이었다. 1990년대 중반에 크로스 플랫폼이 생기다니, 정말 대단한 사람들이 많지 않은가.

 

자바의 철학

자바 언어는 1991년도에 발표된 다섯 가지의 철학을 가지고 있다고 한다. 

• 참고 : https://www.oracle.com/java/technologies/introduction-to-java.html

1. 객체 지향 방법론을 사용해야 한다.
2. 같은 프로그램(바이트코드)이 여러 운영 체제(마이크로프로세서)에서 실행될 수 있어야 한다.
3. 컴퓨터 네트워크 접근 기능이 기본으로 탑재되어 있어야 한다.
4. 원격 코드를 안전하게 실행될 수 있어야 한다.
5. 다른 객체 지향 언어들의 좋은 부분만 가지고 와서 사용하기 편해야 한다.

다른 부분은 이미 앞에서 짚고 넘어갔지만 객체 지향 방법론이 눈에 띈다. 우리가 아는 절차 지향 언어인 C를 발전시킨 C++ 이 1983년에 발표되면서 객체 지향이라는 개념이 확산되기 시작되었다. 그렇게 당연하게 1990년대에 접어들면서 많은 사람들이 객체 지향 방법론을 발전시키면서 소프트웨어 공학에서 중요한 패러다임으로 자리 잡게 되었다.

 

1991년에 만들기 시작했던 자바의 철학에 이러한 객체지향이 담기게 된 것은 당연한 수순이었다. 객체지향의 장점인 재사용성과 확장성, 유지보수의 용이성 등등... 많은 부분에서 생산성을 높이는 객체지향의 특성을 가진 자바의 등장은 당연히 큰 여파를 몰고 올 수밖에 없었던 것이다.

 

자바의 유행

 

1990년대 당시 사용한 객체 지향 언어들은 Smalltalk, C++, Objective-C 같은 언어들이었다는 걸 생각하면, C++를 제외한 다른 객체지향 언어들은 거의 사장되고 Java만 살아남은 결과를 통해 자바가 프로그래밍 언어계의 초신성이라는 것을 알 수 있다. 또한 "JVM 위에서 바이트코드가 실행된다!"라는 개념은 자바 애플리케이션을 다양한 플랫폼 위에서 실행시킬 수 있는 기반을 제공하기 때문에 이때 많은 개발자들이 자바를 통해 개발하며 다양한 자바의 프로젝트들이 생겨났고, 소유권 분쟁이 생겨나기 시작했다. 다양한 프로젝트를 살펴보면서 이어지는 저작권 분쟁까지 살펴보자.

 

Java ME ( Java Micro Edition / J2ME )

피처폰, PDA, 센서 등의 임베디드에 특화된 자바 에디션이다.

 

Java SE ( Java Standard Edition / J2SE )

대부분의 사람들이 가장 많이 접하는 표준이다. Java의 핵심 API와 기능들을 제공한다. 우리가 아는 일반적인 JDK(Java Developer Kit)를 말한다. 썬 마이크로시스템즈에서 개발한 Java 환경이 돌아가는 프로그램을 개발하는 데, 필요한 툴들을 모아 놓은 소프트웨어 패키지이다.

 

상술하지 않았지만 썬 마이크로시스템즈는 2010년 오라클에 인수되었기 때문에 이로 인해 다양한 저작권 분쟁이나 유로 라이선스 문제 등이 발생하게 되었다. 특정한 경우에서는 JDK 라이선스에 비용이 들지만, OpenJDK 등을 사용하면 비용 문제를 겪지 않는다.

 

Jakarta EE ( 예전 명칭은 Java EE, Java Enterprise Edition / J2EE )

기업에서 운영하는 서버 페이지에 특화된 에디션이다. JSP와 Servlet(HTTP 요청/응답을 쉽게 관리해 주는 자바 진영의 인터페이스)와 같은 다양한 툴을 포함하고 있는 에디션이다. 프레임워크를 사용해 본 사람들은 알겠지만, 생산성이 다른 수준을 넘어 없이는 개발할 수 없는 수준인데, JSP와 Servlet은 Java EE에서 프레임워크와 같은 큰 역할을 한다.

• JSP

JSP는 Servlet과 함께 1999년대에 선 마이크로시스템즈에 의해 처음 발표되었는데, 주목적은 웹 페이지 내에 Java 코드를 삽입하여 동적인 웹 콘텐츠를 생성하는 것이다. 현대에는 이러한 것을 MVC 패턴이라고 부른다. 서버에서 JSON이나 XML와 같은 값만 내려주는 것과 다르게, HTML 및 CSS를 렌더링 하여 웹페이지를 서버에서 내려주는 것을 MVC 패턴이라고 한다.

 

위 사진은 MVC에 대해서 설명해 주는 사진이다. MVC는 (Model - View - Controller)를 의미하며, MVC 프레임워크에는 Python의 Django, Ruby의 Ruby on Rails 등이 있다. 서버 프레임워크에서 View를 다루기 때문에 HTML을 렌더링 하여 서버에서 제공하는 구조를 의미한다.

 

현대에는 IT 기술이 발달함에 따라서 프론트엔드 및 클라이언트 개발자를 따로 두어, Model과 Controller를 서버 개발자 및 인프라 개발자가 전담하고, View와 관련된 UI 부분을 프론트엔드 개발자 및 클라이언트 개발자가 담당하는 구조지만, 이 당시에는 JSP를 통한 MVC 패턴으로 개발하는 것이 흔했다. 이때 웹 페이지를 개발하는 사람을 웹 퍼블리셔라고 부르는 이유가 JSP와 같은 이유였다.

 

• Servlet

서블렛은 복잡한 HTTP 통신에 대해 개발자가 쉽게 HTTP 요청을 받아 서버에서 처리하게 할 수 있는 기술을 말한다. 이는 직접 스프링의 간단한 코드를 통해서 느낌을 알 수 있게 해 보자.

 

서블릿 등록

package hello.servlet;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;

@ServletComponentScan // 서블릿 등록
@SpringBootApplication
public class ServletApplication {
      public static void main(String[] args) {
          SpringApplication.run(ServletApplication.class, args);
     }
}

 

서블릿 예시 컨트롤러

package hello.servlet.basic;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;

@WebServlet(name = "helloServlet", urlPatterns = "/hello")
public class HelloServlet extends HttpServlet {
@Override
      protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
          System.out.println("HelloServlet.service");
          System.out.println("request = " + request);
          System.out.println("response = " + response);
          
          String username = request.getParameter("username");
          System.out.println("username = " + username);
          
          response.setContentType("text/plain");
          response.setCharacterEncoding("utf-8");
          response.getWriter().write("hello " + username);
	}
}

 

 위와 같이 간단하게 HTTP 요청을 처리할 수 있게 도와주는 것이 서블렛이다. 언어 자체만을 통해서 HTTP 요청을 핸들링한다고 생각하면 얼마나 충격적인가. 하지만 이러한 것을 손쉽게 도와주는 서블릿을 통해 웹 개발은 폭발적인 생산성을 가지게 되었다.

 스프링의 다양한 어노테이션들은 내부적으로 이러한 서블릿을 이용하여 HTTP 관련 처리를 지원하게 되었고, 개발자들은 그저 Spring Docs를 참고하여 다양한 로직을 구현하는 것에 집중할 수 있게 되었다.

 

 

자바의 소유권

위에서 JSP와 Servlet 같이 굉장히 혁신적인 기술에 대해서 알아보았다. 한 가지 설명을 빼놓은 점은 Java EE에서 Jakarta EE로 이름이 전환된 이유를 빼놓았는데. 이는 소유권과 관련된 이유가 있다. 썬 마이크로시스템즈에서 처음 개발한 Java와 Java EE가 인수자인 오라클(Oracle)에게 소유권이 넘어가게 되었는데, JSP와 Servlet을 포함한 다양한 기술들이 오라클의 관리 하에 놓이게 됐다.

 

이 당시 많은 자바 개발자들이 Java EE의 발전 속도와 방향에 대해서 커뮤니티에서 다양한 우려를 제기했다. 많은 개발자들과 기업들이 Java EE에 대한 우려를 표했고, 자바에 대한 민심이 떨어지게 된 것이다. 오라클은 이러한 상황에 대응하여, 2017년 8월 17일에 Java EE를 포기한다고 발표했다.

 

이러한 소유권 분쟁은 주로 오픈 소스 커뮤니티에 소유권을 맡기는 데, 결국 Java EE의 소유권을 Eclipse Foundation에 이전하기로 결정하게 된다. 이클립스 파운데이션은 오픈 소스 소프트웨어 커뮤니티로, 오라클과 함께 이전 프로세스를 관리한 적이 있는 커뮤니티이다. 이렇게 소유권을 넘기게 되면서 Java의 상표권 문제로 인해, Jakarta EE로 이름이 변경되게 된다.

 

이러한 사례를 통해 Java EE의 이름이 Jakarta EE로 전환되며 커뮤니티 주도 개발이 이루어지게 되었다. 오픈 소스 생태계의 시작점이 되었으며 많은 개발자들이 서블릿과 JSP 등을 통해서 손쉽게 서버 개발을 접할 수 있게 되었다. 이는 오라클에서 한 번 양보한 케이스에 해당한다. 반대로 구글과 한판을 벌였던 사태도 있는데, 다음을 살펴보자.

 

구글 vs 오라클 - 저작권 분쟁

 

Java를 개발한 썬 마이크로시스템즈가 오라클에 인수되었고, 당시 2010년 오라클은 구글이 안드로이드를 개발하면서 Java의 API 37개를 소스 코드를 무단 복제하여 사용했다는 이유로 소송을 제기했다. 오라클은 구글이 자바를 이용해 OS를 개발하려는 상업적 목적을 가지고 있었으므로 사전에 허가를 받았어야 했다는 주장이고, 구글은 자바 API가 저작권이 인정되지 않는 작업물이거나, 저작권자의 허락 없이 이용할 수 있는 공정 이용의 대상이라면서 맞섰다. 

 

약 10년간의 치열한 공방 끝에 2021년 4월, 연방대법원이 구글이 자바 API를 공정한 관행에 따라 이용했기 때문에 저작권을 침해한 것이 아니라 판단하여 해당 분쟁이 종료되었고, 구글이 승리하게 되었다.

 

자바의 이후 행보 및 미래

이렇게 자바의 길고 긴 역사를 지나 자바는 JSP와 Servlet과 같은 핵심적인 기술을 가지고 있는 오픈소스가 되었다. 2000년대 초반의 자바 애플리케이션 프레임워크는 EJB가 표준이었다.

 

EJB가 어렵다고 생각하는 사람들이 꽤 있었는데, 한 개발자가 내가 이것(EJB) 보다 잘 짜겠다! 라며 책을 출판한다. 이 책은 로드 존슨의 Expert One-on-One J2EE Design and Development이라는 책이다. 또한 하이버네이트(Hibernate)라는 EJB에 존재하는 엔티티빈이라는 개념을 발전시킨 기술이 있었는데, 이 두 가지가 함께 발전되어 섞이며 2003년 6월 최초로 스프링이 탄생하게 된다.

 

EJB 시절을 겨울로 표현하여 추운 겨울 뒤에 봄이 온다는 뜻으로 Spring이라고 이름이 붙었다. 아파치 라이선스 2.0을 따르는 오픈 소스 프레임워크 스프링이 탄생하게 된 것이다! 또한 국내에서는 한국 전자정부표준프레임워크의 기반 기술이며 한국정보화진흥원에서는 공공기관의 웹 서비스 제공 시 스프링을 권장한다고 한다. 이렇게 스프링과 자바는 전 세계에서 사랑받는 프레임워크가 되게 되었다. 한국에서는 위 이유로 점유율이 특히 더 높다.

 

또한, 요즘 웹사이트 템플릿 엔진으로는 JSP가 아닌 Thymeleaf(타임리프)를 많이 쓴다. MVC 기반 개발이 필요하다면 타임리프를 참고해 보자.

 

마치며

자바와 관련해서 제일 좋아하는 개발 유머는 자바와 자바스크립트는 햄과 햄스터만큼의 차이가 있다.라는 말이다. 자바와 자바스크립트에 대해서 자세히 조사하면 할수록 진짜 아예 다른 언어라는 것을 알 수 있었다.

 

서버 개발을 시작한 지 약 2년 가까이 되면서 자바의 기술적인 구조 또한 흥미롭지만 가장 재미있었던 것은 그 역사이다. 1991년부터 개발이 시작되면서, 다양한 사건사고를 겪은 언어이기 때문에 자바에 대해서 조사하는 과정이 오래 걸렸지만 그만큼 자바의 역사뿐만 아니라 개발의 역사를 느껴볼 수 있는 기회였던 것 같다.

학창 시절, 마인크래프트를 킬 때마다 쓰던 자바의 커피 로고의 역사가 이렇게 굉장히 깊다는 것을 생각하면 참 오래된 일인 것 같다. 자바의 길고 긴 롱런의 이유를 꼽자면 오픈 소스 생태계라고 생각하는데, 많은 개발자들이 함께 자바 생태계를 발전시켜 나가며 스프링과 자바를 좀 더 효율적으로 쓸 수 있게 꾸준히 발전시키는 것이 오픈 소스의 순기능이라고 생각한다.

 

참고

• [위키피디아] 자바(프로그래밍 언어) : https://ko.wikipedia.org/wiki/자바_(프로그래밍_언어)
• [EDUCBA] What is Java SE? : https://www.educba.com/what-is-java-se/
• [mozilla] MVC : https://developer.mozilla.org/ko/docs/Glossary/MVC

감사합니다.