[원론 이야기] 왜 모든 개발 언어는 "Hello, World!"부터 시작할까? (환경 구축과 예제 포함)
안녕하세요, 가야태자 @talkit 입니다.
오늘은 실습보다는 다시 원론적인 이야기를 조금 해보려고 합니다.
새로운 프로그래밍 언어를 배울 때, 우리가 가장 먼저 화면에 띄우는 문장은 백이면 백 모두 "Hello, World!"입니다. 문득 '왜 개발 언어에서는 이걸 제일 처음에 가르칠까?'라는 의문이 들었습니다.
단순히 오래된 전통이라서, 혹은 귀여운 인사말이라서 따라 하는 걸까요? 제 생각과 AI의 생각을 같이 정리해 보니, 여기에는 개발 환경을 구축하는 과정에서 가장 핵심적인 '엔지니어링적 이유'가 숨어 있었습니다.
이번 글에서는 그 이유와 함께, 끝부분에 간단한 개발 환경 구축 방법과 주요 언어의 Hello World 예제도 만들어 두었으니 참고 부탁드립니다.
1. "Hello, World!"에 숨겨진 진짜 이유
생각해 보면 "Hello, World!"를 출력하는 것은 단순히 글자 몇 개를 화면에 보여주는 일이 아닙니다. 이 짧은 한 줄이 성공적으로 실행되었다는 것은, 내 컴퓨터 안에서 다음과 같은 복잡한 과정이 완벽하게 작동했다는 방증입니다.
컴파일러/인터프리터 설치: 언어를 해석하는 엔진이 컴퓨터에 올바르게 깔렸는가?
환경 변수(PATH) 설정: 터미널이나 IDE가 해당 언어의 실행 파일 위치를 정확히 인식하고 있는가?
구문 분석(Syntax Parsing): 가장 기본적인 문법 구조를 도구가 이해하고 있는가?
출력 스트림(I/O) 연결: 프로그램이 OS의 표준 출력 시스템과 제대로 상호작용하고 있는가?
즉, "내 컴퓨터에 이 언어를 위한 기초적인 개발 환경이 완벽하게 세팅되었다"라는 것을 검증하는 가장 완벽하고 최소한의 단위 테스트(Minimum Viable Test)인 셈입니다.
만약 첫 시간부터 복잡한 알고리즘 코드를 짰다가 에러가 나면, 우리는 '문법이 틀린 건지', '논리가 틀린 건지', '애초에 설치가 잘못된 건지' 원인을 찾기 힘듭니다. 하지만 문법이 틀릴 리 없는 "Hello, World!"에서 에러가 난다면 100% '개발 환경 세팅의 문제'로 원인을 좁힐 수 있습니다. 복잡한 변수를 제거하고, 오직 '환경 구축'이라는 첫 번째 관문에만 집중할 수 있도록 도와주는 마법 같은 코드인 것이죠.
2. 주요 언어별 환경 구축 및 예제 살펴보기
언어마다 개발 환경을 만들고 실행하는 방식(컴파일 vs 인터프리터)이 조금씩 다릅니다. 대표적인 4가지 언어의 핵심 요약을 정리해 두었으니 참고해 보세요.
① C 언어 (컴파일러 방식)
C 언어는 기계어로 직접 변환되는 컴파일 언어입니다. 코드를 작성한 후 실행 파일을 만드는 변환 과정이 필요합니다.
환경 구축 핵심: * Windows: GCC 컴파일러(MinGW) 설치 및 시스템 환경 변수(PATH) 등록
macOS: 터미널에서 xcode-select --install 명령어로 Command Line Tools 설치
Hello, World! 코드:
#include <stdio.h>
int main() {
printf("Hello, C World!\n");
return 0;
}
실행 방법: 터미널에서 gcc main.c -o main으로 빌드 후, ./main으로 실행
② Java (가상 머신 방식)
Java는 OS에 종속되지 않고 JVM(자바 가상 머신) 위에서 돌아갑니다.
환경 구축 핵심: * JDK(Java Development Kit) 설치 (OpenJDK 등)
시스템 환경 변수에 JAVA_HOME 등록 및 PATH에 bin 디렉토리 추가
Hello, World! 코드:
public class Main {
public static void main(String[] args) {
System.out.println("Hello, Java World!");
}
}
실행 방법: 터미널에서 javac Main.java로 컴파일 후 java Main으로 실행
③ Python (인터프리터 방식)
파이썬은 컴파일 없이 코드를 한 줄씩 읽어가며 바로 실행하는 대표적인 언어입니다.
환경 구축 핵심: * Python 공식 홈페이지에서 인스톨러 다운로드 및 설치
[중요] 설치 화면에서 "Add python.exe to PATH" 체크박스 반드시 선택
Hello, World! 코드:
print("Hello, Python World!")
실행 방법: 터미널에서 python main.py 입력 시 즉시 실행
④ Node.js (JavaScript 런타임)
웹 브라우저 밖(로컬 컴퓨터)에서 자바스크립트를 실행할 수 있게 해주는 환경입니다.
환경 구축 핵심: * Node.js 공식 홈페이지에서 LTS(안정화) 버전 설치
설치 시 node 환경 변수와 패키지 매니저인 npm이 자동으로 함께 세팅됨
Hello, World! 코드:
console.log("Hello, Node.js World!");
실행 방법: 터미널에서 node app.js 입력 시 즉시 실행
💡 글을 마치며
언어별 예제를 보면 아시겠지만, 파이썬이나 Node.js는 단 한 줄이면 끝나는 반면, C나 Java는 무언가 감싸고 있는 뼈대(구조)가 많습니다. "Hello, World!"를 직접 실행해 보면 '아, 이 언어는 기본적으로 이런 구조를 갖추고 시작해야 하는구나'라는 언어별 스타일을 첫눈에 파악할 수 있다는 장점도 있습니다.
"Hello, World!"는 단순한 인사가 아니라, 새로운 언어의 세계로 들어가기 전 컴퓨터와 개발자가 나누는 첫 번째 악수와 같습니다. 화면에 이 문구가 무사히 떴다면, 여러분은 이미 가장 어렵고 중요한 첫 번째 베이스캠프인 '환경 구축'을 정복하신 겁니다.
지난 글까지 우리는 MacOS 환경에서 우여곡절 끝에 Java 1.8 엔진을 얹고, STS4 설치에 이어 감격의 스프링 부트(Spring Boot) Hello World 웹 서버를 구동하는 데 성공했습니다! 매번 익숙한 윈도우 환경에서만 개발 설정을 하다가, 맥북 터미널을 두들기며 실습해 보니 사소한 에러를 잡는 것도 아주 색다르고 재미있네요. ^^
단순히 화면에 글자 하나를 띄우는 HelloWorld 단계를 넘어서니, 이제 실무에서 사용하는 진짜 비즈니스 로직(데이터베이스 연동, 아키텍처 설계 등)을 추가하고 싶어지더군요. 그래서 본격적인 코드 작성에 앞서, 머릿속을 맴돌던 몇 가지 근본적인 궁금증들을 정리해 보았습니다.
전통적인 Spring MVC와 순수 Spring Boot 설정은 구체적으로 무엇이 다른가? (그 많던 XML들은 다 어디로 갔나?)
사람들은 왜 유독 Spring Boot를 두고 '클라우드 친화적(Cloud-Friendly)'이라고 부르는가?
그렇다면 기존 Spring MVC는 도커(Docker)나 쿠버네티스(Kubernetes) 같은 현대적인 클라우드 환경으로 전환이 불가능한가?
오늘은 본격적인 아키텍처 설계에 들어가기 전, 이 궁금증들을 아주 명쾌하고 쉽게 풀어보는 시간을 가져보겠습니다!
1. Spring MVC vs Spring Boot 설정의 차이: "설정 지옥의 해방"
전통적인 Spring MVC(예: 전자정부프레임워크 등)로 비즈니스 프로젝트를 시작하려면, 코드를 짜기도 전에 엄청난 양의 환경 설정에 지치곤 했습니다.
applicationContext.xml, spring-mvc.xml, context-datasource.xml 등 거대하고 복잡한 XML 파일들을 매번 복사해 와서 데이터베이스 커넥션 풀(DBCP)을 셋팅하고, 컴포넌트 스캔 범위를 지정해야 했죠. 오타라도 하나 나면 컴파일 시점엔 알 수도 없고 런타임 에러를 뿜어내기 일쑤였습니다.
하지만 Spring Boot는 이 패러다임을 완전히 바꿨습니다. 부트에는 스프링 관련 설정을 위한 XML 파일이 단 하나도 필요 없습니다!
스프링 부트는 "설정보다는 관례(Convention over Configuration)"를 내세웁니다.
자동 설정(Auto Configuration):spring-boot-starter-web 라이브러리를 추가하는 순간, 부트가 내부적으로 "아, 이 개발자가 웹 서버를 만드는구나!" 하고 내장 톰캣 서버, JSON 변환기, 문자 필터 등을 알아서 자바 코드로 셋팅해 줍니다.
프로퍼티 중심 제어: 과거 복잡했던 데이터소스(DB 접속) 설정은 이제 application.properties 파일에 딱 세 줄, 드라이버 이름과 URL, 계정 정보만 적어주면 끝납니다.
개발자는 인프라 설정에 힘을 뺄 필요 없이 오직 비즈니스 로직(Controller - Service - DTO - Mapper)에만 100% 집중할 수 있게 된 것이죠.
2. Spring Boot는 왜 '클라우드 친화적'일까?
최근 실무 백엔드 인프라의 대세는 AWS 같은 클라우드 환경입니다. 그리고 클라우드 세상에서 스프링 부트는 독보적인 위치를 차지하고 있습니다. 왜 그럴까요?
① 내장 WAS를 품은 '독립 실행형 JAR' (이식성)
레거시 Spring MVC는 빌드하면 WAR 파일이 나옵니다. 이 파일은 혼자서 실행할 수 없고, 클라우드 서버마다 외부 웹 서버(Tomcat)를 따로 설치하고 설정을 맞춘 뒤에 그 안에 '주입(Deploy)'해야 구동됩니다. 반면, Spring Boot는 웹 서버(Tomcat)를 자바 패키지 내부에 아예 내장하고 있습니다. 빌드하면 웹 서버가 포함된 단 하나의 JAR 파일이 툭 떨어집니다. 클라우드 서버에 자바만 깔려 있다면 java -jar app.jar 명령어 한 줄로 즉시 어디서든 똑같이 구동됩니다. 인프라 의존성이 사라진 것입니다.
② 압도적인 구동 속도와 가벼움 (오토스케일링 최적화)
클라우드의 핵심은 사용자가 몰릴 때 서버를 순식간에 수십 대로 늘리는 오토스케일링(Auto Scaling)입니다. 레거시 시스템은 톰캣을 켜고 WAR 압축을 풀고 비대한 XML을 읽느라 서버가 준비되는 데 수십 초에서 수분이 걸렸습니다. 하지만 스프링 부트는 불필요한 인프라 구조를 걷어내고 자바 코드로 즉시 기동하므로 구동 속도가 극도로 빠릅니다. 클라우드가 명령하는 즉시 트래픽을 받아낼 준비를 마칩니다.
③ 모니터링 기능(Actuator) 기본 내장
수많은 서버가 분산되어 있는 클라우드 환경에서는 서버 상태 감시가 필수입니다. 스프링 부트는 Actuator 라이브러리를 통해 현재 서버의 메모리 상태, DB 커넥션 풀 상태 등을 확인할 수 있는 모니터링 창구를 코딩 한 줄 없이 기본으로 제공해 줍니다.
3. 그럼 Spring MVC는 도커나 쿠버네티스를 사용하지 못하나요?
결론부터 말씀드리면, 당연히 사용할 수 있습니다! 꼭 스프링 부트만 써야 도커/쿠버네티스를 쓸 수 있는 것은 아닙니다.
도커(Docker)와 쿠버네티스(Kubernetes) 입장에서는 컨테이너 안에 담긴 프로그램이 옛날 스프링인지 최신 스프링 부트인지 상관하지 않습니다. 표준 규격만 맞추면 어떤 프로그램이든 다 담아서 굴려줍니다. 실제로 수많은 기업들이 기존에 운영하던 거대한 레거시 Spring MVC 시스템을 그대로 도커 이미지로 패키징하여 쿠버네티스 환경으로 이주(Migration)시켜 운영하고 있습니다.
다만, 장점을 활용하는 효율성의 차이가 존재합니다.
Spring MVC를 도커에 올릴 때: 도커 이미지 안에 우분투 OS를 깔고, 외부 톰캣 서버를 설치하는 스크립트를 짜고, 거기에 WAR 파일을 복사해 넣어야 하므로 도커파일(Dockerfile)이 복잡해지고 이미지의 크기가 무거워집니다. 쿠버네티스가 컨테이너를 복제하거나 자가 치유(Heal)를 할 때도 구동 속도가 느려 굼뜨게 반응합니다.
Spring Boot를 도커에 올릴 때: 순수한 자바 환경 이미지에 JAR 파일 하나만 복사해 넣으면 끝납니다. 이미지 크기가 매우 가볍고, 쿠버네티스의 헬스 체크(Liveness/Readiness Probe)와 부트의 Actuator 기능이 찰떡처럼 연동되어 시스템 자가 치유 능력이 극대화됩니다.
즉, "도커와 쿠버네티스는 Spring MVC라는 옛날 자동차도 트레일러에 실어서 얼마든지 움직여줄 수 있다. 다만, 처음부터 컨테이너 비행기에 쏙 들어가도록 규격화되어 설계된 Spring Boot를 태웠을 때 훨씬 더 가볍고 안전하게 날아갈 수 있다"고 이해하시면 좋습니다!
🏁 가야태자의 요약 및 예고
결과적으로, 기존의 복잡한 인프라 환경을 다루어보신 분들이라면 스프링 부트가 제공하는 이 간결함과 클라우드 네이티브(Cloud Native)적인 특성에 감탄할 수밖에 없습니다. 과거의 자동차 조립 단계 같은 설정을 뒤에서 부트가 다 알아서 해주니까요.
궁금증이 시원하게 해결되었으니, 다음 글에서는 진짜 실무 아키텍처의 뼈대를 세워보겠습니다! 우리가 설치한 자바 1.8 환경에 딱 맞춰서 Controller - Service - DTO - Mapper - MyBatis - DB까지 이어지는 표준 5계층 아키텍처의 패키지를 쪼개고 실제 소스 코드를 채워 컴파일하는 실전 과정으로 찾아오겠습니다.
환경 설정을 진행하시면서 궁금한 점이나 의견이 있으시면 언제든 댓글로 편하게 소통해 주세요. 감사합니다! bananas 🍌
이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 본격적으로 개발 환경을 꾸려볼까 합니다. 이때 사용할 수 있는 개발 환경(IDE)이 여러가지가 있는데, 오늘부터는 무료이면서도 강력한 스프링 공식 지원 도구인 STS(Spring Tools 4)를 활용하여 환경을 구성하는 이야기를 해보고자 합니다.
지난번 제글에서 인용하면 위와 같습니다.
즉 통합 개발 환경입니다.
메모장 + JDK + Maven 등을 이용해서 단순하게 진행할수도 있겠지만 저렇게 진행하면 ^^
개발자가 해야할일이 너무 많습니다.
그래서 개발자들을 편안하게 해주는 IDE중에서 오늘은 Spring Tools(STS)를 설치해보겠습니다.
맥오른쪽 하단에 파란색 다운로드 폴더가 보이면 그걸 클릭하면 여러가지 다운로드 파일이 보입니다.
저걸 실행 하겠습니다.
아이콘이나 파일명을 더블 클릭하시면 열립니다.
JDK를 맥에서 설치 해보는 것은 처음이라서 기대되네요.
약관을 보여주고 약관에 동의 할꺼냐고 묻습니다. 저거 동의 안하면 설치가 안되니까 동의 하겠습니다. ^^
설치 버튼을 누릅니다.
암호나 터치아이디를 누르라고 해서 저는 지문인식으로 처리 했습니다.
그러면 이제 설치를 시작 합니다.
엥 중간에 설치 과정좀 캡처 하려고 했더니 이미 설치가 다 되어 버렸네요.
이제 닫기를 누르시면 설치는 다 된 상태 입니다.
설치가 잘 되었는지 확인하기 위해서 터미널을 열겠습니다.
(base) kjh0523@kjh0523ui-MacBookPro ~ % ls -al $(/usr/libexec/java_home -v 1.8)
total 103312
drwxr-xr-x 15 root wheel 480 4월 26 21:04 .
drwxr-xr-x 6 root wheel 192 4월 26 21:04 ..
-r--r--r-- 1 root wheel 1522 4월 26 21:04 ASSEMBLY_EXCEPTION
drwxr-xr-x 45 root wheel 1440 4월 26 21:04 bin
drwxr-xr-x 3 root wheel 96 4월 26 21:04 bundle
drwxr-xr-x 9 root wheel 288 4월 26 21:04 include
drwxr-xr-x 7 root wheel 224 4월 26 21:04 jre
drwxr-xr-x 9 root wheel 288 4월 26 21:04 lib
-r--r--r-- 1 root wheel 19274 4월 26 21:04 LICENSE
drwxr-xr-x 5 root wheel 160 4월 26 21:04 man
-rw-r--r-- 1 root wheel 2400 4월 26 21:04 NOTICE
-rw-r--r-- 1 root wheel 480 4월 26 21:04 release
drwxr-xr-x 12 root wheel 384 4월 26 21:04 sample
-rw-r--r-- 1 root wheel 52669599 4월 26 21:04 src.zip
-r--r--r-- 1 root wheel 191545 4월 26 21:04 THIRD_PARTY_README
(base) kjh0523@kjh0523ui-MacBookPro ~ % date
2026년 7월 3일 금요일 22시 42분 43초 KST
(base) kjh0523@kjh0523ui-MacBookPro ~ % $(/usr/libexec/java_home -v 1.8)/bin/java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)
(base) kjh0523@kjh0523ui-MacBookPro ~ % java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)
(base) kjh0523@kjh0523ui-MacBookPro ~ %
기존에 자바가 있는 것인지 일단 자바의 버전은 1.8로 확인되었습니다.
패키지의 날짜 때문인지 왜 4월 26일에 설치 된걸로 나오죠?
오늘 설치 했는데 말이죠.
그래도 패스는 지정 해야해서.
패스와 JAVA_HOME을 지정해 보겠습니다.
vi ~/.zshrc
# 파일이 열리면 맨 아래로 이동해서 i 키를 클리하고
export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)
export PATH=$JAVA_HOME/bin:$PATH
# 위 두줄을 복사해서 넣습니다.
# Esc 키를 클릭하고
:wq
# 를 입력후 엔터를 칩니다.
# 위 환경을 적용하기 위해서 source 명령어를 입력 합니다.
source ~/.zshrc
(base) kjh0523@kjh0523ui-MacBookPro ~ % java -version
openjdk version "1.8.0_492"
OpenJDK Runtime Environment (Temurin)(build 1.8.0_492-b09)
OpenJDK 64-Bit Server VM (Temurin)(build 25.492-b09, mixed mode)
[가야태자의 Spring Boot 교실] Java 1.8 & STS 4 개발 환경 완벽 구축부터 HelloWorld 구동까지
안녕하세요! 가야태자 @talkit 입니다. 😊
이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 본격적으로 개발 환경을 꾸려볼까 합니다. 이때 사용할 수 있는 개발 환경(IDE)이 여러가지가 있는데, 오늘부터는 무료이면서도 강력한 스프링 공식 지원 도구인 STS(Spring Tools 4)를 활용하여 환경을 구성하는 이야기를 해보고자 합니다.
"선생님, 지금 Java 21이 나오는 시대에 왜 굳이 Java 1.8인가요?"라고 물으실 수 있습니다. 하지만 실무에 나가보면 수많은 기존 시스템(Legacy)들이 여전히 Java 1.8 위에서 굳건히 돌아가고 있습니다. 이 환경에서 개발 환경을 완벽히 세팅하고, 프로젝트의 뼈대를 잡아 HelloWorld를 띄울 수 있다는 것은 백엔드 개발자로서 아주 강력한 무기가 됩니다.
자, 그럼 내 컴퓨터를 완벽한 스프링 부트 개발 기지로 만드는 환경 설정부터 실전 코드 구동까지 단번에 나아가 봅시다!
오늘은 일단 실습을 위한 준비 정도를 하고 실제 코딩은 주말에 해볼 계획입니다.
실제 코딩을 하면서 본 문서의 잘못된 점이나 코드 등은 바로 잡겠습니다.
1단계: Java 1.8이 품을 수 있는 스프링 부트 버전은?
가장 중요한 첫걸음은 엔진(Java)과 차체(Spring Boot)의 호환성을 맞추는 것입니다.
Java 1.8에서 사용 가능한 마지막 스프링 부트 버전은 2.x 대역입니다. 그중에서도 가장 안정적이고 최신 기능(Java 1.8 기준)을 담고 있는 2.7.x 버전을 선택해야 합니다.
참고 사항: 스프링 부트 3.0부터는 Java 17이 최소 요구 사항입니다. Java 1.8로는 절대로 구동할 수 없습니다. 따라서 과거 레거시 시스템을 다루거나 Java 8 환경을 고수해야 한다면 반드시 2.7.x 대역 버전을 선택해야 합니다.
package com.talkit.banana;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
// [핵심] 이 클래스가 스프링 부트의 구성이자 시작점임을 알리는 마법의 어노테이션입니다.
@SpringBootApplication
public class BananaApplication {
public static void main(String[] args) {
// [핵심] 실제 내장 서버를 올리고 스프링 부트를 가동하는 메인 코드입니다.
SpringApplication.run(BananaApplication.java, args);
}
}
③ 📄 HelloController.java: 웹 요청을 처리하는 컨트롤러
package com.talkit.banana;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
// [핵심] 이 클래스가 웹 요청을 받아 문자열 데이터를 브라우저에 전송하는 컨트롤러임을 명시합니다.
@RestController
public class HelloController {
// [핵심] 사용자가 웹 브라우저에서 "/" (기본 경로)로 접속하면 이 메서드를 연결합니다.
@GetMapping("/")
public String helloBanana() {
return "🍌 가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7! 🍌";
}
}
7단계: STS 4에서 대시보드로 프로젝트 구동하기
이제 모든 코드가 준비되었습니다! 우리가 장착한 STS 4의 가장 큰 무기인 '부트 대시보드'를 활용하여 아주 편안하게 시동을 걸어보겠습니다. ① 프로젝트 불러오기 (Import) 1. STS 4를 실행하고 상단 메뉴에서 File -> Import...를 클릭합니다. 2. Maven 폴더 아래의 Existing Maven Projects를 선택하고 Next를 누릅니다. 3. Root Directory 옆의 Browse... 버튼을 눌러 우리가 코드를 작성해 둔 banana-helloworld 폴더를 선택합니다. 4. 중간 목록에 pom.xml 파일이 잘 체크되었는지 확인하고 Finish를 누릅니다. 5. STS 우측 하단에 인터넷에서 필요한 메이븐 빌드 라이브러리를 다운로드하는 게이지가 지나갑니다. 다운로드가 끝날 때까지 잠시만 기다려 주세요. ② 대시보드로 시동 걸기 (Run) 1. 프로젝트 빌드가 완료되면 STS 화면의 Boot Dashboard 탭을 클릭합니다. 2. local 항목을 펼쳐보면 방금 불러온 우리의 banana-helloworld 프로젝트가 예쁘게 떠 있을 것입니다. 3. 프로젝트 이름을 마우스 우클릭한 뒤, (Re)start (또는 상단의 초록색 재생 버튼 아이콘)를 클릭합니다. ③ 브라우저에서 감격의 결과 확인하기 1. STS 중앙 하단의 Console 탭에 로그가 시원하게 올라갑니다. 마지막 행에 "Started BananaApplication in X.XXX seconds"라는 문구가 나타나면 서버 구동 성공입니다! 2. 크롬 등 사용하시는 웹 브라우저를 엽니다. 3. 주소창에 http://localhost:8080을 정확히 입력하고 엔터를 탁! 칩니다. 4. 화면에 우리가 컨트롤러에 적어두었던 바나나 환영 인사가 멋지게 출력되는 것을 볼 수 있습니다!
🍌 가야태자의 바나나 교실에 오신 것을 환영합니다! Hello World for Java 1.8 & Spring Boot 2.7! 🍌
🏁 가야태자의 정리 및 복습 팁
드디어 우리는 Java 1.8이라는 전통적인 환경 위에서 스프링 부트 2.7 완성차를 조립하고 첫 주행(HelloWorld)까지 훌륭하게 마쳤습니다! 스프링 부트 개발을 배울 때 가장 좋은 복습 방법은 각 파일이 왜 이 자리에 있어야 하고, 어노테이션(@)이 무슨 역할을 하는지 구조와 코드를 매칭하며 눈으로 짚어보는 것입니다. 이 기초 체력이 굳건해야 복잡한 비즈니스 로직을 짤 때 흔들리지 않습니다. 다음 시간에는 이 띄워놓은 HelloWorld 웹 페이지 위에 실제 데이터를 예쁘게 주고받는 더 흥미진진한 백엔드 이야기로 찾아오겠습니다. 실습 도중 에러가 나거나 막히는 점이 있다면 언제든 댓글 창에 질문을 남겨주세요. 같이 해결해 봅시다! 😊
[테크/개발] 자바 백엔드의 날개, Spring Boot 개발 환경(IDE) 완벽 가이드: 나에게 맞는 도구는?
안녕하세요 가야태자 @talkit 입니다.
이번에 여러가지 자바 역사를 살펴봤고 스프링 부트의 역사와 개념도 알아봤는데, 이제 개발 환경을 꾸려볼려고 합니다. 이때 사용할 수 있는 개발 환경이 여러가지가 있는데 이 개발 환경들을 어떻게 구성할지에 대한 이야기를 해보고자 합니다.
스프링 부트(Spring Boot)는 과거의 복잡한 설정을 자동화해 주어 개발 생산성을 극대화해 주지만, 우리가 어떤 도구(IDE)를 손에 쥐느냐에 따라 그 개발의 '편안함'과 '작업 속도'는 천차만별로 달라집니다. 현재 자바 생태계에서 선택할 수 있는 대표적인 개발 환경들의 특징, 지원 OS, 그리고 가장 중요한 유료/무료 여부와 공식 참조 링크를 낱낱이 비교해 드리겠습니다.
🚀 [특화 섹션] 인텔리제이 커뮤니티(무료) vs 얼티밋(유료) 집중 비교
많은 초보 개발자분들이 *"인텔리제이가 대세라고 해서 다운받으려고 보니 얼티밋 버전은 너무 비싸요. 무료인 커뮤니티 버전으로 스프링 부트 개발해도 괜찮을까요?"*라는 질문을 던지십니다.
결론부터 말씀드리면 "개발은 가능하지만, 얼티밋에 비해 많은 수고로움(수동 작업)이 필요하다"입니다. 두 버전이 스프링 부트 개발 환경에서 어떤 차이를 보이는지 핵심만 비교해 드립니다.
1) 프로젝트 생성 방식의 차이
Ultimate (유료): IDE 내부에서 Spring Initializr를 곧바로 호출하여 몇 번의 클릭만으로 스프링 부트 프로젝트를 뚝딱 생성할 수 있습니다.
Community (무료): 내장 프로젝트 생성기에서 스프링 부트를 공식 지원하지 않습니다. 따라서 웹 브라우저를 켜고 스프링 공식 스타터 웹사이트(start.spring.io)에 접속하여 프로젝트를 생성한 뒤, 압축을 풀고 커뮤니티 버전에서 Import(열기)하는 번거로운 과정을 거쳐야 합니다.
2) 애플리케이션 구동 및 모니터링 (부트 대시보드)
Ultimate (유료): 전용 'Run Dashboard(Services)'가 존재하여 내장 톰캣 서버 제어, 액추에이터(Actuator) 연동 데이터 분석, 현재 활성화된 프로필(Profile) 변경 등을 GUI 환경에서 직관적으로 관리합니다.
Community (무료): 스프링 부트 전용 대시보드가 없습니다. 일반 자바 메인 클래스를 실행하듯 Application.java 파일을 직접 찾아 우클릭 후 Run을 실행해야 합니다. 여러 서버를 동시에 띄우거나 관리할 때 다소 직관성이 떨어집니다.
3) 코드 어시스트 및 설정 파일(Application.properties / yaml) 자동 완성
Ultimate (유료): 스프링 부트의 설정 파일들을 완벽하게 인식합니다. 예를 들어 server.port나 데이터베이스 연결 설정을 타이핑할 때 지능적인 자동 완성을 제공하고, 오타가 나면 경고해 줍니다. 또한 컨트롤러와 매핑된 URL 엔드포인트를 모아서 보는 전용 도구도 제공합니다.
Community (무료): 텍스트 기반의 단순 자동 완성만 지원하거나 아예 지원하지 않는 경우가 많아, 설정 파일의 키값을 개발자가 직접 공식 문서를 보며 타이핑해야 하므로 오타로 인한 삽질(?) 가능성이 커집니다.
💡 가야태자의 커뮤니티 버전 활용 팁: > 비용 부담 때문에 반드시 인텔리제이 커뮤니티 버전을 써야 한다면, 마켓플레이스에서 'Spring Boot Helper' 같은 서드파티 플러그인을 찾아서 수동으로 설치해 보세요. 완벽하진 않지만 얼티밋 버전의 갈증을 조금이나마 해소할 수 있습니다. 다만, 무료 환경에서 편안한 스프링 부트 개발을 원하신다면 커뮤니티 버전보다는 차라리 아래의 STS 4나 VS Code가 기능적으로 더 쾌적할 수 있습니다.
현재 전 세계 자바 및 스프링 부트 개발자들이 가장 사랑하고, 실무 표준으로 자리 잡은 통합개발환경입니다.
지원 OS: Windows, macOS, Linux
비용 (유료/무료):하이브리드 (Community 버전: 무료 / Ultimate 버전: 유료)
개인 및 기업에서 무료로 쓸 수 있는 커뮤니티 버전이 있지만, 스프링 부트 전용 핵심 편의 기능들은 연간 구독 형태의 Ultimate(유료) 버전에 집중되어 있습니다.
Spring Boot 개발 편안함: * Ultimate 버전: ⭐⭐⭐⭐⭐ (최상 - 돈값을 톡톡히 하는 완벽한 빌트인 인프라)
Community 버전: ⭐⭐⭐☆☆ (보통 - 자바 코딩은 훌륭하나 스프링 특화 기능이 빠져 수동 작업 필요)
2. 스프링 공식 전용 도구: STS (Spring Tools 4)
스프링의 친정인 VMware(Tanzu)에서 전통의 이클립스(Eclipse)를 기반으로 스프링 개발에 딱 맞게 최적화하여 내놓은 공식 전용 IDE입니다.
지원 OS: Windows, macOS, Linux
비용 (유료/무료):100% 무료 (오픈소스)
Spring Boot 개발 편안함: ⭐⭐⭐⭐☆ (우수)
오직 '스프링 및 스프링 부트 개발'만을 타깃으로 커스텀 되었기 때문에, 무료 도구 중에서는 최고의 안정성과 편의성을 자랑합니다.
화면 우측 하단의 '부트 대시보드(Boot Dashboard)'를 통해 여러 개의 스프링 부트 애플리케이션을 직관적으로 켜고 끌 수 있으며, 런타임 상태를 쉽게 모니터링할 수 있습니다. IntelliJ Ultimate의 유료 기능 중 상당수를 무료로 누릴 수 있는 훌륭한 대안입니다.
하지만 플러그인 간의 버전 충돌 가능성이 있고, 과거 무거운 XML 방식의 잔재가 남아있어 초기 세팅이 다소 번거롭습니다. 만약 이클립스 기반의 개발 환경을 선호하신다면, 순수 이클립스보다는 앞서 소개해 드린 STS(Spring Tools 4)를 다운로드하여 곧바로 사용하시는 것이 정신 건강에 훨씬 이롭습니다.
5. 그 외의 틈새 선택지들
NetBeans (Apache): Windows/Mac/Linux 지원, 무료. 자바 표준 스펙(Jakarta EE)엔 강하나 스프링 부트 전용 플러그인 생태계가 빈약하여 추천도가 떨어집니다. (편안함: ⭐⭐☆☆☆)
Fleet (JetBrains): Windows/Mac/Linux 지원, 현재 프리뷰(무료) 진행 중. VS Code처럼 가벼우면서도 IntelliJ의 스마트 코드 분석 엔진을 가져와 쓸 수 있는 젯브레인의 차세대 경량 에디터입니다. (편안함: ⭐⭐⭐☆☆)
클라우드 IDE (구름IDE, GitHub Codespaces 등): OS 무관, 기본 무료+유료 요금제. 웹 브라우저만 있으면 가상 컨테이너에서 스프링 부트를 띄울 수 있어 태블릿(아이패드 등) 코딩이나 외부 강의·실습용 환경 구성에 매우 편안합니다. (편안함: ⭐⭐⭐☆☆)
🏆 한눈에 보는 요약 및 추천 가이드
IDE 명
주요 추천 대상
비용 (개인/기업)
Spring Boot 개발 편안함 정도
IntelliJ (Ultimate)
실무/상용 서비스 개발, 최고의 생산성을 위해 돈을 지불할 용의가 있는 분
유료 (구독제)
🔴 최상 (가장 스마트하고 편리함)
STS 4
비용 부담 없이 스프링 공식 전용 도구의 안정적인 기능을 쓰고 싶을 때
무료 (오픈소스)
🟢 우수 (무료 도구 중 가장 직관적)
VS Code
사양이 낮은 PC, 가볍고 빠른 기동성과 스타일리시한 코딩 환경 선호
무료 (오픈소스)
🟡 양호 (쾌적하고 가벼운 확장성)
IntelliJ (Community)
인텔리제이의 단축키와 코드 분석 엔진을 무료로 부드럽게 쓰고 싶을 때
무료 (오픈소스)
🟡 양호 (자바 코딩은 좋으나 스프링 수동 세팅 필요)
Eclipse
기존 금융권/공공기관의 오래된 레거시 시스템 유지보수 환경
무료 (오픈소스)
⚪ 보통 (직접 수동 플러그인 세팅 필요)
🏁 가야태자의 결론: 나에게 맞는 환경 구성은?
스프링 부트 개발 환경을 구성할 때의 핵심은 "자신의 장비 사양"과 "비용 투자 여부"입니다.
만약 장비가 훌륭하고 생산성을 위해 비용을 투자할 의향이 있다면 IntelliJ Ultimate(유료) 환경이 최고의 정답입니다.
인텔리제이 특유의 UI와 코드 리팩토링 능력을 사랑하지만 비용이 부담된다면 조금 번거롭더라도 IntelliJ Community(무료) 버전에 수동 플러그인을 세팅해 볼 수 있습니다.
완전히 무료이면서도 장황한 수동 세팅 없이 스프링 부트 전용 기능을 안정적으로 쓰고 싶다면 STS 4가 가장 합리적인 선택입니다.
마지막으로, 컴퓨터 사양이 아쉽거나 경량화된 환경을 원한다면 VS Code 조합을 추천해 드립니다.
여러분은 어떤 IDE로 스프링 부트의 첫 발을 내딛고 싶으신가요? 여러분의 PC 환경과 목적에 맞는 최적의 환경을 꾸리시길 바라며, 다음에는 실제 프로젝트를 생성하고 구동하는 이야기로 찾아오겠습니다.
[테크/회고] 자바 웹 프레임워크 연대기: 스트럿츠(Struts)의 왕좌와 스프링(Spring)의 대혁명
자바(Java) 백엔드 생태계를 주도해 온 프레임워크의 역사를 되짚어보면, 이는 단순히 기술의 변화가 아니라 "복잡성과의 처절한 사투", 그리고 "개발자 중심의 생산성 향상"이라는 거대한 흐름의 연속이었습니다.
오늘날 자바 개발자들에게 공기처럼 당연한 존재가 된 Spring Boot와 Spring MVC가 있기까지, 자바 웹 생태계의 패러다임을 바꾸었던 두 주인공 '스트럿츠(Struts)'와 '스프링(Spring)'의 흥망성쇠, 그리고 자바의 표준이 된 스프링 생태계의 거대한 진화 과정을 한눈에 정리해 봅니다.
1. 태동기: EJB의 독점과 스파게티 코드의 어둠 (2000년대 초)
초기 대규모 자바 엔터프라이즈 환경은 썬 마이크로시스템즈(Sun Microsystems)가 주도한 J2EE 규격과 EJB(Enterprise JavaBeans)가 지배하고 있었습니다. 분산 환경과 트랜잭션을 컨테이너가 알아서 제어해 준다는 거창한 명분이 있었지만, 현실은 처참했습니다. 코드 한 줄을 고치거나 테스트하려면 수많은 인터페이스를 상속받아야 했고, 무거운 WAS(웹 애플리케이션 서버)를 매번 재부팅해야 했습니다. "자바의 본질인 객체지향(POJO)을 잃어버렸다"는 혹평이 쏟아졌습니다.
덮친 데 덮친 격으로 당시 웹 화면을 담당하던 JSP 영역은 HTML, 자바스크립트, 비즈니스 로직, 데이터베이스 쿼리까지 한 파일에 뒤섞여 있는 이른바 '모델 1' 방식이 흔했습니다. 조금만 프로젝트가 커져도 유지보수가 불가능한 스파게티 코드가 되기 일쑤였습니다.
2. 스트럿츠(Struts)의 등장: 최초의 웹 MVC 표준과 황금기 (2000년대 초중반)
이 어둠 속에서 자바 웹 구원의 투수로 등판한 것이 바로 아파치 재단의 스트럿츠(Struts)였습니다. 2001년 출시된 스트럿츠는 스파게티 코드처럼 엉켜있던 웹 개발 프로세스에 '모델 2 MVC(Model-View-Controller) 패러다임'을 확고하게 심어주었습니다.
화면(View), 비즈니스 로직(Model), 제어 흐름(Controller)을 명확하게 분리.
개발자들이 역할 분담을 할 수 있는 구조적 명확성 제공.
스트럿츠는 출시 직후 폭발적인 인기를 끌며 2003년부터 2007년 무렵까지 전 세계 자바 웹 시장을 사실상 지배했습니다. 당시 한국의 초기 대형 공공기관 프로젝트나 대기업 시스템 역시 대부분 스트럿츠를 뼈대로 구축되었습니다. 자바 웹 개발자들에게 "웹 앱은 무조건 MVC로 짜야 한다"는 공식을 각인시킨 주역이 바로 스트럿츠입니다.
3. 스프링(Spring)의 탄생: 오픈소스 혁명과 '공존'의 시대 (2000년대 중반)
스트럿츠가 앞단(웹 화면 제어)을 평정하고 있을 때, 뒤 영역(비즈니스 로직 및 객체 관리)에서는 또 다른 혁명이 시작되고 있었습니다. 2004년, EJB의 지독한 복잡성에 분노한 로드 존슨(Rod Johnson)을 필두로 스프링 프레임워크(Spring Framework) 1.0이 세상에 나왔습니다.
스프링은 무거운 컨테이너 없이도 엔터프라이즈 기능을 수행할 수 있도록 IoC/DI(의존성 주입)와 AOP(관점 지향 프로그래밍)를 전면에 내세웠습니다. 기술 인프라와 비즈니스 로직을 완벽히 분리하여 "다시 순수한 자바(POJO)로 돌아가자"고 외친 것입니다.
재미있는 점은, 초기 스프링은 스트럿츠의 경쟁자가 아니라 '가장 완벽한 파트너'였다는 사실입니다. 2000년대 중반 자바 웹 진영의 가장 트렌디하고 강력한 '꿀조합' 스택은 다음과 같았습니다.
웹 화면 및 요청 제어(MVC): Struts
비즈니스 로직 및 트랜잭션 관리(DI/AOP): Spring
데이터베이스 매핑(SQL 매퍼): iBATIS (현 MyBatis)
웹 요청을 받는 앞문(Controller)은 스트럿츠가 열고, 문을 열고 들어온 데이터를 처리하는 알맹이 객체 관리는 스프링이 맡는 식으로 두 프레임워크는 아름답게 공존했습니다.
4. 세대교체: '공존'에서 '대체'로, 스프링의 왕좌 장악 (2000년대 후반)
영원할 것 같았던 스트럿츠와 스프링의 동맹은 2000년대 후반으로 넘어가며 균열이 가기 시작했고, 결국 완전한 세대교체로 이어지게 됩니다. 여기에는 몇 가지 결정적인 이유가 있었습니다.
Spring MVC의 대두: 스프링 진영에서 자체 웹 프레임워크인 Spring MVC를 고도화(Spring 2.5 ~ 3.0)하면서 굳이 앞단에 스트럿츠를 따로 연동할 필요가 없어졌습니다. 스프링 컨테이너와 완벽하게 네이티브로 결합하는 Spring MVC는 스트럿츠보다 훨씬 유연하고 강력했습니다.
설정 지옥(XML)의 한계: 스트럿츠는 화면 하나나 액션 하나를 추가할 때마다 거대한 struts-config.xml 설정을 매번 장황하게 수정해야 하는 번거로움이 있었습니다.
결정타가 된 보안 취약점 사태: 스트럿츠가 스트럿츠2(Struts2)로 버전 업을 치는 과정에서, 원격으로 코드를 실행할 수 있는 치명적인 보안 취약점(CVE)이 주기적으로 발생했습니다. 금융권과 대기업 시스템이 해커들의 표적이 되자, 안정성이 최우선인 기업들은 대대적으로 스트럿츠를 버리고 스프링 생태계로 탈출하기 시작했습니다.
5. 스프링 생태계의 거대한 양대 축: Spring Framework vs Spring Boot
스트럿츠를 흡수하고 자바 생태계를 통일한 스프링은 거대해진 몸집만큼 강력한 진화를 거듭했습니다. 현대 자바 백엔드는 크게 인프라와 기술 표준을 정의하는 'Spring Framework'와, 이를 기반으로 빠른 생산성을 제공하는 'Spring Boot'의 두 축으로 움직입니다. 각 프레임워크가 걸어온 핵심 버전을 브리핑합니다.
🧱 Spring Framework의 진화 (1.0에서 6.0까지)
1.0 (2004): 순수 자바 객체(POJO) 기반의 DI/AOP 개념 증명. 무거운 XML 설정 중심.
2.0 ~ 3.0 (2006~2009): 웹 계층을 위한 Spring MVC의 본격적인 강화. 점차 XML을 벗어나 @Component, @Autowired 같은 자바 어노테이션(Annotation) 기반 설정의 표준 도입.
4.0 (2013): 자바 8(Java 8) 지원 개시. 람다식과 새로운 날짜 API 등을 수용하며 현대적 자바 문법과의 정합성 확보.
5.0 (2017): 대규모 트래픽 처리를 위한 비동기·논블로킹 리액티브 프로그래밍 스택인 Spring WebFlux 탑재.
6.0 (2022~현재): 자바 17을 최소 요구 버전으로 지정하여 구조적 최적화 단행. 가상 스레드(Project Loom) 연동 및 클라우드 환경을 위한 GraalVM 네이티브 이미지 빌드 공식 지원.
1.0 (2014): 수많은 XML/자바 설정에 지친 개발자들을 구원하기 위해 등장. "설정보다는 관례(Convention over Configuration)"를 모토로 내장 톰캣(Tomcat)과 자동 설정(starter) 개념 최초 도입.
2.0 (2018): Spring Framework 5.0 기반으로 업그레이드되면서, 리액티브 웹 스택과 새로운 모니터링 툴(Actuator) 기능 대폭 강화.
3.0 (2022): 자바 17 표준 탑재 및 Spring 6 기반 리프레시. 빌드 타임에 C/C++ 프로그램처럼 바이너리를 뽑아내어 구동 속도를 밀리초(ms) 단위로 줄이는 GraalVM 네이티브 컴파일 전면 수용. 클라우드 네이티브(MSA/Serverless)의 최적화 달성.
4.0 ~ 4.5 (현재): 더 고도화된 자바 최신 스펙 완벽 튜닝. 대규모 언어 모델(LLM) 연동을 위한 Spring AI 프레임워크 인프라가 코어 단에 밀접하게 내장되었으며, 가상 스레드(Virtual Thread) 최적화를 통해 리액티브 코딩 없이도 초고효율 멀티스레딩을 가볍게 구동하는 완성형 아키텍처 구축.
6. 두 프레임워크의 상관관계: 엔진과 자동차
종종 신입 개발자들이 "스프링 프레임워크와 스프링 부트 중 무엇을 공부해야 하나요?" 혹은 "부트가 나왔으니 스프링 프레임워크는 끝난 건가요?"라는 질문을 하곤 합니다. 하지만 두 기술은 대체 관계가 아닌 완벽한 상호보완적 결합 관계입니다.
쉽게 비유하자면, 스프링 프레임워크는 '고성능 자동차 엔진'이고, 스프링 부트는 그 엔진을 얹고 바퀴, 시트, 내비게이션까지 완벽하게 조립해 둔 '완성차'입니다.
Spring Boot: 편리한 완성차 (내장 톰캣, 자동 설정, 자동 버전 관리)
Spring Framework: 핵심 심장 엔진 (DI/AOP Core, Spring MVC, WebFlux 테크놀로지)
스프링 부트는 독자적인 프레임워크가 아닙니다. 내부를 뜯어보면 결국 스프링 프레임워크가 핵심 심장(Core)으로 돌고 있습니다. 과거에는 엔진(Spring Framework)만 덜렁 주어졌기 때문에 개발자가 직접 차체(Tomcat 서버)를 구해서 용접하고, 연료 공급 장치(XML 파일 수백 줄)를 직접 커스텀 조립해야 했습니다.
반면, 스프링 부트는 개발자가 Boot를 실행하는 순간, 뒤편에서 스프링 프레임워크의 DI/AOP 엔진을 깨우고 필요한 라이브러리들을 관례에 맞게 알아서 조립해 줍니다. 결국 부트를 깊고 단단하게 쓴다는 것은 그 내부에서 돌아가는 스프링 프레임워크의 사상을 완벽히 이해하는 것과 같습니다.
🏁 마치며
스트럿츠(Struts)는 무질서하던 자바 웹 개발에 최초로 MVC 패턴의 규격을 제시하며 웹 제어의 대중화를 이끈 선구자였습니다.
스프링(Spring Framework)은 EJB의 무거움에 반대하며 순수 자바(POJO) 정신을 깨웠고, 기술을 유연하게 통합하는 포용력으로 시작해 웹 영역(Spring MVC)까지 완벽히 흡수하며 생태계를 통일했습니다.
스프링 부트(Spring Boot)는 거대해진 스프링 엔진을 개발자들이 단 몇 초 만에 도로 위로 끌고 나갈 수 있게 완성차 형태로 포장해 준 혁신이었습니다.
현재 스트럿츠는 오래된 레거시 시스템의 유지보수 단계에서나 볼 수 있는 '살아있는 화석'이 되었지만, 그가 남긴 MVC 패러다임은 여전히 스프링의 심장 속에 살아 숨 쉬고 있습니다. 세월을 관통하며 다듬어진 이 견고한 생태계 덕분에, 현대의 우리는 인프라 설정에 고통받지 않고 오롯이 비즈니스 로직에만 집중할 수 있는 최고의 개발 풍요를 누리고 있습니다.
[Java 보안] Log4j 사태로 보는 패치의 중요성, 오픈 JDK 벤더별 EOS 비교 및 오라클의 상용화 비화
안녕하세요 가야태자 @talkit 입니다.
최근 자바를 다시 복습하면서, 시스템의 안정성을 책임지는 '보안 업데이트'의 중요성을 격하게 절감하고 있습니다. 전 세계 웹과 대규모 기업용 엔터프라이즈 시스템의 뼈대를 이루는 Java 환경에서 보안 패치는 단순한 버전 업그레이드가 아닌, 서비스의 생명줄과 같습니다.
오늘 포스팅에서는 전 세계 IT 백엔드를 뒤흔들었던 Log4j 사태를 통해 왜 우리가 보안 업데이트에 민감해야 하는지 알아보고, Oracle의 공식 JDK와 Eclipse 재단, Red Hat, Azul Systems 등 다양한 진영의 오픈 JDK가 제공하는 보안 업데이트 종료(EOS) 일자를 명확하게 비교해 보겠습니다. 더불어 오라클이 자바 업데이트를 상용(구독 모델)으로 전환한 배경과 비화까지 함께 정리해 드립니다.
1. Java 보안 업데이트가 왜 중요한가: Log4j 사태의 교훈
Java 환경에서 보안 업데이트가 기업의 생존과 직결된다는 것을 증명한 가장 대표적인 사건이 바로 2021년 말 발생한 Log4j 취약점 사태(Log4Shell)입니다. Log4j는 거의 모든 Java 기반 애플리케이션과 대형 기업 웹 서버에서 로그를 기록하기 위해 공통으로 사용하는 핵심 라이브러리였습니다.
이 라이브러리에서 발견된 취약점은 공격자가 서버에 원격으로 접속해 악성 코드를 무조건 실행할 수 있는 원격 코드 실행(RCE) 취약점이었습니다. 해커가 마음만 먹으면 기업의 핵심 DB를 탈취하거나 시스템을 마비시킬 수 있는, 보안 등급 최악의 치명적인 약점이었습니다.
당시 전 세계 수많은 대기업과 금융권의 개발자들이 이 약점을 막기 위해 최신 보안 버전으로 긴급 업데이트 패치를 적용하느라 사상 초유의 비상사태를 겪었습니다. 만약 사용 중인 JDK나 라이브러리의 보안 업데이트 지원이 이미 종료된 상태였다면, 기업들은 이 무시무시한 취약점을 알고도 방어막을 치지 못해 고스란히 무방비로 당했을 것입니다.
이처럼 알려진 보안 취약점(CVE)을 빠르게 봉쇄하고 시스템의 대외 신뢰도를 유지하기 위해서, 기업이 어떤 JDK를 사용하든 공식적인 보안 업데이트 지원 기간(LTS)을 명확히 확인하고 추적하는 것은 필수적입니다.
2. 주요 진영별 Java LTS 버전 보안 업데이트 종료(EOS) 비교
오라클이 제공하는 무료 OpenJDK 빌드는 새로운 메이저 버전이 출시되면 이전 버전의 무료 지원을 몇 개월 내로 빠르게 중단합니다. 반면 기업용 시스템의 장기 안정성을 위해 오픈소스 커뮤니티와 다른 전문 벤더사들은 자체적인 LTS(Long-Term Support) 일정을 길게 확보해 두고 있습니다.
각 진영의 공식 가이드라인을 기반으로 정리한 버전별 최소 지원 종료(End of Support) 마일스톤입니다.
Java LTS 버전
Oracle OpenJDK (무료 빌드)
Eclipse Adoptium (Temurin) [1]
Red Hat OpenJDK [2]
Azul Zulu (Core 기준) [3]
Java 8
지원 종료
최소 2030년 12월까지
완전지원 종료: 2026년 11월 30일 ELS-1 종료: 2030년 12월 31일
2030년 12월까지
Java 11
지원 종료
최소 2027년 10월까지
완전지원 종료 (2024년 10월 31일) ELS-1 종료: 2027년 10월 31일
2032년 1월까지
Java 17
지원 종료
최소 2027년 10월까지
완전지원 종료: 2027년 12월 31일
2029년 9월까지
Java 21
2026년 9월까지 (예정)
최소 2029년 12월까지
완전지원 종료: 2029년 12월 31일
2031년 9월까지
3. 오라클은 왜 자바 업데이트를 상용(유료)으로 전환했는가?
자바의 소스 코드 자체는 오픈소스(OpenJDK) 프로토콜로 풀려있지만, 오라클은 기업들이 실제 운영 서버에서 가장 신뢰하며 사용하는 자사 브랜드의 Oracle JDK 기술 지원을 유료화(상용 전환)했습니다. 여기에는 오라클의 철저한 비즈니스 수익 모델 체질 개선 전략이 숨어 있습니다.
① 상표권의 독점과 기술 지원의 자산화
오라클은 과거 선 마이크로시스템즈를 인수하면서 자바의 소스 코드는 커뮤니티에 기증(Jakarta EE 등)했으나, 'Java'라는 브랜드 상표권과 독점 기술 스펙은 끝까지 유지했습니다. 즉, '가장 순수하고 최적화된 오라클의 자바 기술 지원과 긴급 패치를 받고 싶다면 정당한 비용을 지불하라'는 비즈니스적 판단입니다.
② 라이선스에서 구독(Subscription) 모델로의 체질 개선
오라클은 과거 일회성으로 소프트웨어 라이선스를 판매하던 방식에서 완전히 탈피하여, 매달 서버 혹은 프로세서 수(또는 전사 직원 수) 기준으로 비용을 청구하는 'Java SE Subscription' 모델을 정착시켰습니다. 클라우드 시대에 인프라의 핵심인 자바 보안 패치를 정기적으로 공급하는 행위 자체를 거대한 고정 구독 수익원(Cash Cow)으로 만든 것입니다.
결국 장기적인 보안 거버넌스와 면책 조항이 필수적인 글로벌 대기업이나 대형 금융권들이 비용을 지불하더라도 오라클의 밀착 기술 지원을 선택할 수밖에 없도록 비즈니스 환경을 설계한 결과입니다.
4. 요약 및 시사점
자바 생태계에서 보안 업데이트는 인프라의 생명줄과 같습니다. 오라클이 자사 공식 JDK를 상용 구독 모델로 전환하며 장벽을 세우자, 시장은 오히려 Eclipse Adoptium이나 Red Hat, Azul 같은 대체 오픈 JDK 진영의 무상 장기 지원(LTS)을 적극적으로 수용하는 방향으로 건강하게 파편화되었습니다.
따라서 개발자와 아키텍트는 서비스의 특성에 맞춰 오라클의 유료 구독 모델을 선택할지, 혹은 무료로 장기 지원을 제공하는 타 진영의 오픈 JDK로 마이그레이션할지 명확한 EOS 로드맵을 바탕으로 인프라 이주 전략을 세워야 할 것입니다.
💡 각주: Red Hat의 Full Support와 ELS-1 안내
완전지원 종료(End of Full Support): 레드햇의 일반 서브스크립션(구독) 고객 모두에게 무상으로 정기적인 보안 패치와 버그 수정 업데이트를 제공하는 마감일입니다. 만약 이 기간이 종료되면 일반 RHEL 가입자 대상의 무상 패치 배포가 중단됩니다. (예: OpenJDK 11은 2024년 10월 31일부로 완전지원이 종료되었습니다.)
ELS-1 종료(End of Extended Life Cycle Support Phase 1): 완전지원이 끝난 후, 마이그레이션 시간을 벌어야 하는 기업들을 위해 운영되는 유료 연장 보안 지원 단계입니다. 별도의 'OpenJDK ELS 서브스크립션'을 구매한 고객에 한해, 새로운 기능 추가 없이 시스템에 치명적인 영향을 미치는 핵심 보안 취약점(Critical/Important CVE) 패치만 제한적으로 백포팅하여 제공합니다.
요즘 Java를 다시 정리 겸 공부하고 있는데, 문득 한 가지 깊은 의문이 생겼습니다. "Java는 명실상부 웹과 기업용 시스템 시대를 지배한 대표 언어인데, 왜 정작 지금의 AI(인공지능) 시대에서는 주인공이 되지 못했을까?" 여러분도 'AI 시대의 언어'라고 하면 자바보다는 파이썬(Python)이 가장 먼저 떠오르실 텐데, 대체 어떤 기술적·인간적 배경이 이런 차이를 만들었는지 무척 궁금해졌습니다.
그래서 오늘 포스팅에서는 자바가 왜 AI의 주역 자리를 내주어야 했는지 그 이유를 날카롭게 파헤쳐 보고, 반대로 자바 진영이 AI 시대를 집어삼키기 위해 뒤에서 칼을 갈며 준비해 온 놀라운 최신 기술들과 미래 비전까지 함께 자세히 알아보겠습니다.
1. 웹/기업 시대의 절대 강자, Java
자바(Java)는 1990년대 후반 웹의 폭발적인 성장과 함께 기업용 시스템(Enterprise) 시장의 절대 강자로 자리매김했습니다. 거대하고 복잡한 금융권 인프라나 대기업의 백엔드 시스템에서 자바가 표준으로 선택된 이유는 타의 추종을 불허하는 '안정성'과 '확장성' 덕분이었습니다.
자바는 컴파일 시점에 타입을 엄격하게 검사하는 강력한 타입 시스템을 갖추고 있어, 대규모 협업 시 발생할 수 있는 휴먼 에러를 사전에 차단합니다. 또한 가상 머신(JVM) 아키텍처를 기반으로 하여 "한 번 작성하면 어디서나 실행된다"는 이식성을 보장했고, 가비지 컬렉터(GC)가 메모리를 자동으로 관리해 주어 개발자가 비즈니스 로직에만 집중할 수 있게 했습니다. 여기에 대용량 트랜잭션 처리에 특화된 Java EE(현 Jakarta EE) 스펙과 스프링(Spring) 프레임워크 생태계가 결합하면서, 자바는 수십 년간 엔터프라이즈 아키텍처의 견고한 뼈대로 군림해 왔습니다.
2. Java가 AI 시대의 주 언어가 되지 못한 이유
반면 AI와 머신러닝 시대의 주도권은 자바가 아닌 파이썬(Python)이 가져갔습니다. 여기에는 AI 학계의 독특한 인적 구성과 언어의 '타입(Type) 선언 방식'이 자아낸 결정적인 차이가 있었습니다.
초기 AI 및 데이터 과학 생태계를 구축한 주역들은 전통적인 컴퓨터공학과나 전산학과 출신의 소프트웨어 엔지니어보다는 수학, 통계학, 물리학, 뇌과학 등을 전공한 데이터 과학자 및 연구원(Researcher)들이 주류를 이뤘습니다. 이들의 주 목적은 완벽한 소프트웨어를 빌드하는 것이 아니라, 가설을 세우고 수식을 코드로 구현해 빠르게 데이터를 검증(Prototyping)하는 것이었습니다.
이 지점에서 자바와 파이썬의 생산성 격차가 벌어졌습니다. 물론 파이썬 역시 들여쓰기(Indentation) 규칙 등 문법적 엄격함이 존재하지만, 자바에 비하면 변수와 함수의 '형 선언(Type Declaration)'이 완전히 자유로운 동적 타입(Dynamic Typing) 언어입니다.
자바에서는 데이터 하나를 다루려 해도 데이터의 형태(int, String 등)를 엄격하게 미리 정의해야 하고, 클래스와 메서드를 장황하게 감싸는 보일러플레이트 코드를 작성해야 합니다. 반면 파이썬은 형 선언 없이 x = 10처럼 변수를 바로 만들어 쓰고, 함수도 유연하게 주고받을 수 있어 수학적 아이디어를 즉석에서 코드로 실험하기에 최적의 자유도를 제공했습니다.
또한, AI 연산의 핵심은 C/C++로 작성된 하드웨어 가속 라이브러리를 얼마나 매끄럽게 연결하느냐에 있었습니다. 파이썬은 이른바 '글루(Glue) 언어'로서 외부 로우레벨 라이브러리와의 결합이 매우 쉬웠고, 이를 바탕으로 연구원들이 넘파이(NumPy), 판다스(Pandas), 텐서플로우, 파이토치 등 독점적인 AI 생태계를 빠르게 선점해 나갔습니다. 반면 자바는 복잡한 JNI 아키텍처 한계와 장황한 문법 탓에, 속도가 생명이었던 초기 AI 연구원들의 선택을 받지 못하며 트렌드에서 뒤처지게 되었습니다.
3. Java가 AI 시대의 언어로 변신하기 위해 준비하는 기술들
현재 자바 진영의 AI 전략은 파이썬처럼 거대 언어 모델(LLM)을 바닥부터 직접 학습시키는 스크립트를 짜는 것이 아닙니다. 자바의 진정한 강점은 전 세계 기업들이 이미 구축해 놓은 거대한 엔터프라이즈 인프라 위에서, 오픈AI나 구글 제미나이(Gemini) 같은 외부 LLM을 가장 안정적으로 연결, 제어, 오케스트레이션하는 인터페이스 표준을 확립하는 것에 있습니다.
이 중심에 있는 기술이 바로 '스프링 AI(Spring AI)'와 'LangChain4j' 같은 엔터프라이즈급 AI 프레임워크입니다. 이들은 타사 LLM과의 연동 인터페이스를 고도로 추상화하여, 개발자가 코드 한 줄만 바꾸면 다양한 진영의 AI 모델을 스왑(Swap)할 수 있도록 돕습니다. 또한, 기업 내부 데이터를 안전하게 결합하는 RAG(검색 증강 생성) 아키텍처와 벡터 데이터베이스 연동을 자바 특유의 유연한 인터페이스 구조로 표준화했습니다.
여기에 하드웨어 레벨의 성능을 내기 위한 오라클 주도의 로우레벨 혁신이 뒷받침되고 있습니다. '프로젝트 파나마(Project Panama)'는 기존의 무거웠던 JNI를 완전히 대체하여, C/C++ 기반의 고성능 외래 AI 엔진(예: llama.cpp 등)과 메모리에 직접 접근할 수 있는 표준 API를 제공합니다. 또한 '벡터 API(Vector API)'는 최신 CPU의 SIMD(단일 명령 다중 데이터) 아키텍처를 활용해 행렬 연산 속도를 네이티브급으로 끌어올렸습니다.
더불어 자바는 로봇, 가전, 팩토리 자동화 등 하드웨어와 결합하는 피지컬 AI(Physical AI)와 IoT 생태계에서도 강력한 미래를 준비하고 있습니다. 당초 가전제품 제어를 위해 탄생했던 자바의 모태(Oak)답게, 기기 독립적인 가상 머신 환경은 피지컬 에이전트를 구동하기에 최적입니다. 최근 자바는 메모리를 극도로 아끼면서 수만 개의 동시 대량 요청을 처리할 수 있는 가상 스레드(Virtual Threads) 기술을 도입했습니다. 이를 통해 수많은 센서와 액추에이터가 실시간으로 통신하는 피지컬 AI 환경에서 자바는 고성능 프레임워크와 결합해 강력한 실시간 제어 능력을 발휘하고 있습니다. 자바는 단순한 언어적 변신을 넘어, 엔터프라이즈 안정성과 최신 자율형 AI 에이전트 아키텍처를 아우르는 견고한 통합 AI 플랫폼으로 진화하는 중입니다.
4. 요약: 엔터프라이즈의 무기를 쥔 자바의 AI 역습
요약하자면 자바가 초기 AI 시대의 주역이 되지 못한 것은, 완벽함보다는 빠른 실험과 유연성이 중요했던 수학·통계학 기반 연구원들의 니즈와 자바의 엄격한 정적 타입 문법이 맞지 않았기 때문입니다.
하지만 AI 기술이 연구실을 넘어 '실제 기업 서비스(Production)' 단계로 진화하면서 판도가 바뀌고 있습니다. 자바 진영은 직접 모델을 만드는 대신, 프로젝트 파나마와 벡터 API를 통해 로우레벨 연산 속도를 확보하고, 스프링 AI를 앞세워 다양한 외부 LLM을 안전하게 통제·결합하는 최강의 인터페이스 전략을 취하고 있습니다. 여기에 가상 스레드를 무기로 하드웨어를 직접 제어하는 피지컬 AI 영역까지 영토를 확장하고 있습니다.
Java를 다시 복습하며 느낀 점은, 자바는 결코 낡은 언어가 아니라 시대의 요구에 맞춰 자신의 가장 강력한 무기인 '신뢰성과 구조화'를 바탕으로 AI를 흡수하고 있다는 점입니다. 기업용 대형 시스템에 AI를 이식해야 하는 순간이 오면, 결국 다시 자바가 주인공이 될 날이 머지않은 것 같습니다.
[Java] JDK 버전별 AES 256 암호화 적용 방법과 "Illegal key size" 에러 해결책
안녕하세요 가야태자 @talkit 입니다. Java관련된 글을 계속 적고 있는데, 해당글들에 이어서 그리고, 제가 이번 프로젝트를 를 진행하면서 겪었던 Java 1.7에서 AES256 암호화 시에 여러분은 오류가 발생하지 않았으면 하는 바램에 이글을 적습니다. 해당 글은 1.6, 1.7에서 AES 256 암호화시 겪게 되는 오류와 해결책, 그리고 JDK 각 버전별 예제를 담고 있습니다.
Java로 보안 관련 기능을 개발하다 보면 가장 흔하게 접하는 암호화 알고리즘이 바로 AES 256입니다. 하지만 분명 로컬(최신 JDK)에서는 잘 돌아가던 코드가 운영 서버(구버전 JDK)에만 올라가면 마법처럼 에러를 뿜어내는 경우가 있습니다.
오늘 그 원인과 JDK 버전별 차이점, 그리고 레거시 환경에서의 해결책까지 완벽하게 정리해 보겠습니다.
🚨 왜 구버전 Java에서는 AES 256이 실패할까?
AES 256 암호화를 적용하고 구버전 자바 환경에서 구동하면 높은 확률로 아래와 같은 치명적인 예외를 만나게 됩니다.
이 에러가 발생하는 이유는 과거 미국의 암호화 기술 수출 통제법 때문입니다. 미국은 강력한 암호화 기술이 해외로 유출되는 것을 막기 위해, 기본적으로 Java에 128비트(16바이트)를 초과하는 키를 사용할 수 없도록 제한을 걸어두었습니다. AES 256은 256비트(32바이트) 키를 사용하기 때문에 "키 사이즈가 불법(Illegal)"이라며 거부하는 것입니다.
📅 JDK 버전별 AES 256 지원 차이점
자바가 발전하면서 이 규제와 내부 정책도 많이 변했습니다. 내가 쓰는 JDK 버전이 어디에 속하는지 확인해 보세요.
JDK 버전
AES 256 지원 상태
특징
JDK 1.6 / 1.7
❌ 기본 차단
기본 128비트 제한. AES 256 사용 시 수동 패치 필수.
JDK 1.8
⚠️ 버전별 상이
- 8u151 미만: 수동 패치 필요 - 8u151 이상: 설정 파일로 활성화 가능 - 8u161 이상: 기본 활성화
JDK 11 / 17 / 21
⭕ 기본 활성화
제약 없음. 성능 최적화 및 최신 암호화 모드(GCM) 권장.
⚠️ Java 1.6 & 1.7 환경에서의 핵심 주의사항 및 해결책
제가 이번에 Java 1.7 프로젝트를 진행하며 깊게 겪었던 부분입니다. 구버전 환경에서 이 에러를 해결하려면 반드시 아래 사항을 숙지하고 조치해야 합니다.
1. 무제한 강도 정책(JCE) 파일 수동 패치 (올바른 해결책)
Oracle 공식 홈페이지에서 버전에 맞는 'Unlimited Strength Jurisdiction Policy Files'를 직접 다운로드받아 서버의 Java 경로에 덮어씌워야 합니다.
Oracle 공식 다운로드 링크 검색 키워드:Java Cryptography Extension (JCE) Unlimited Strength
파일을 덮어쓸 경로:${JAVA_HOME}/jre/lib/security/
교체할 파일:local_policy.jar, US_export_policy.jar
💡 Tip: 만약 운영 환경이 Oracle JDK가 아닌 OpenJDK라면, 오픈소스 특성상 이 수출 규제 파일이 적용되지 않아 수동 패치 없이도 바로 AES 256이 작동할 수 있습니다. 서버의 Java 벤더사를 먼저 확인해 보세요!
2. 리플렉션(Reflection) 우회 꼼수 코드는 금물!
인터넷을 찾아보면 JCE 다운로드가 귀찮아서 Java 내부의 isRestricted 필드를 리플렉션 코드로 강제로 false로 바꾸는 팁이 공유되곤 합니다. 하지만 실무 운영 환경에서는 절대 사용하시면 안 됩니다. JVM 내부 보안 구조를 강제로 비트는 행위라, 자바 마이너 업데이트나 환경 변화에 따라 갑자기 애플리케이션이 뻗어버릴 수 있는 시한폭탄 같은 코드입니다. 반드시 위의 1번 방법(JCE 패치)으로 해결하셔야 합니다.
🔒 3. 가장 중요한 보안 규칙: 암호화 키 관리 (필독!)
코드 구현보다 더 중요한 것은 암호화 키를 안전하게 다루는 것입니다. 실무에 적용하실 때 다음 규칙을 반드시 지켜주세요.
예제 키 사용 금지: 암호화키는 여러분의 키를 직접 만들어서 쓰셔야 합니다. 제가 아래 예제 코드에서 사용한 키나, 다른 인터넷 블로그 등에서 샘플로 받은 키를 그대로 사용하시면 심각한 보안상 문제가 발생합니다. 예제 키는 누구나 알 수 있기 때문에 암호화의 의미가 완전히 사라집니다.
소스코드와 키 분리 보관: 암호화 키는 절대 소스코드 내에 하드코딩하면 안 됩니다. 해당 키는 소스와 완전히 분리되어 OS 환경 변수(Environment Variable), 외부 설정 파일(Properties, YAML), 혹은 AWS Secrets Manager나 HashiCorp Vault 같은 전문 키 관리 시스템(KMS)에 보관되어야 합니다.
외부 노출 절대 금지: 키가 담긴 설정 파일을 실수로 GitHub 같은 공용 저장소에 업로드하는 일이 없도록 .gitignore 설정을 철저히 하셔야 합니다. 절대로 키를 외부에 공개하시면 안 됩니다.
💻 JDK 버전별 AES 256 구현 예제
1️⃣ JDK 1.6, 1.7, 1.8 (레거시 환경 - AES/CBC/PKCS5Padding)
구버전 환경에서 가장 범용적으로 쓰이는 CBC 모드 예제입니다. (※ 1.6, 1.7은 위에 설명한 JCE 패치가 완료된 상태여야 작동합니다.)
import javax.crypto.Cipher;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.util.Base64; // JDK 1.8 미만은 별도의 Base64 라이브러리(Apache Commons 등) 필요
public class Aes256Legacy {
// ⚠️ 주의: 아래 키와 IV는 예시일 뿐입니다. 실무에서는 소스코드와 분리하여 고유한 키를 사용하세요!
private static final String KEY = "abcdefghijklmnopqrstuvwxyz123456"; // 32바이트 키 (256비트)
private static final String IV = "1234567890123456"; // 16바이트 IV (CBC 모드 필수)
public static String encrypt(String text) throws Exception {
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
SecretKeySpec keySpec = new SecretKeySpec(KEY.getBytes("UTF-8"), "AES");
IvParameterSpec ivSpec = new IvParameterSpec(IV.getBytes("UTF-8"));
cipher.init(Cipher.ENCRYPT_MODE, keySpec, ivSpec);
byte[] encrypted = cipher.doFinal(text.getBytes("UTF-8"));
// JDK 1.8 기준 Base64Encoder 사용 (1.7 이하는 외부 라이브러리 활용)
return Base64.getEncoder().encodeToString(encrypted);
}
}
2️⃣ JDK 11, 17, 21 (최신 환경 - AES/GCM/NoPadding)
최신 자바 버전에서는 단순 CBC 모드보다 무결성 검증까지 함께 수행하여 보안성이 훨씬 강력한 GCM 모드 사용을 강력히 권장합니다. 별도의 JCE 설정 없이 즉시 실행됩니다.
import javax.crypto.Cipher;
import javax.crypto.spec.GCMParameterSpec;
import javax.crypto.spec.SecretKeySpec;
import java.security.SecureRandom;
import java.util.Base64;
public class Aes256Modern {
// ⚠️ 주의: 아래 키는 예시일 뿐입니다. 실무에서는 소스코드와 분리하여 고유한 키를 사용하세요!
private static final String KEY = "abcdefghijklmnopqrstuvwxyz123456"; // 32바이트
private static final int GCM_IV_LENGTH = 128; // IV bits
private static final int GCM_TAG_LENGTH = 16; // Tag bytes (128 bits)
public static String encrypt(String text) throws Exception {
// GCM 모드는 매번 새로운 IV 사용을 강력히 권장
byte[] iv = new byte[GCM_IV_LENGTH / 8];
new SecureRandom().nextBytes(iv);
Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding");
SecretKeySpec keySpec = new SecretKeySpec(KEY.getBytes("UTF-8"), "AES");
GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH * 8, iv);
cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec);
byte[] ciphertext = cipher.doFinal(text.getBytes("UTF-8"));
// IV와 암호문을 함께 저장/전송해야 복호화가 가능합니다.
byte[] cipherWithIv = new byte[iv.length + ciphertext.length];
System.arraycopy(iv, 0, cipherWithIv, 0, iv.length);
System.arraycopy(ciphertext, 0, cipherWithIv, iv.length, ciphertext.length);
return Base64.getEncoder().encodeToString(cipherWithIv);
}
}
📝 마치며
오래된 시스템을 유지보수하거나 레거시 환경으로 마이그레이션할 때, 자바의 버전별 보안 정책 차이를 모르면 뜬금없는 에러에 며칠을 허비하게 됩니다. 특히 Java 1.6이나 1.7 환경에서 AES 256을 구현하실 때는 서버의 JCE 정책 파일 확인 단계를 거치셔서, 저처럼 삽질(?)하지 않고 한 번에 성공하시길 바라는 마음입니다. 아울러 아무리 코드가 완벽해도 암호화 키가 노출되면 무용지물이 되니 키 관리도 꼭 신경 써주세요! 궁금한 점이 있으시다면 언제든 댓글로 남겨주세요. 감사합니다!
요즘 Java를 다시 정리겸 공부하고있는데, Java의 역사를 공부하다 보니 다른 언어의 역사와 프로그래밍의 발전이 궁금 해졌습니다. 기계어와 천공카드라는 거친 환경에서 출발해, 현대의 자바와 AI 협업 코딩에 이르기까지 우리가 사용하는 컴퓨터 언어들이 어떻게 발전해 왔는지 각 연대 별로 정리하면 아래와 같습니다.
1. 1950년대 이전~1960년대: 프로그래밍의 새벽과 하드웨어 제어
초기의 컴퓨터 프로그래밍은 인간의 언어와는 거리가 먼, 철저히 기계 중심적인 작업이었습니다. 1940년대 코딩은 전선을 직접 꽂고 뽑는 하드웨어 재배치나 0과 1로 구성된 정교한 기계어를 직접 입력하는 방식이었습니다. 이 지독한 복잡함을 개선하기 위해 기계어와 일대일 대응하는 어셈블리어가 등장했고, 데이터를 입력하기 위해 종이에 구멍을 뚫어 표현하는 천공카드(Punch Card) 시스템이 널리 활용되었습니다.
1950년대 후반을 지나 1960년대에 접어들면서 비로소 인간이 이해할 수 있는 '고급 언어'의 기틀이 마련됩니다. 수학적 계산을 위해 설계된 최초의 고급 언어 포트란(Fortran), 대규모 기업 비즈니스 데이터 처리를 위해 탄생하여 미 국방부 표준으로 자리 잡은 코볼(COBOL)이 이 시기를 지배했습니다. 당시 프로그래머들은 천공카드 한 장에 코드 한 줄을 정성껏 컴퓨터에 입력하며, 기계 제어 중심에서 인류의 비즈니스 문제를 소프트웨어로 해결하는 첫 패러다임의 전환을 맞이했습니다.
2. 1970년대: 구조적 프로그래밍과 C언어의 탄생
1970년대는 전산학 역사상 가장 위대한 유산이 탄생한 시기입니다. 60년대까지의 고급 언어들은 코드의 실행 흐름이 중구난방으로 튀는 'GOTO' 문을 남발하여 시스템이 거대해질수록 유지보수가 불가능한 '스파게티 코드' 양산이라는 고질적인 문제를 안고 있었습니다. 이를 해결하기 위해 프로그램을 순차, 선택, 반복이라는 명확한 구조로 나누어 작성하는 구조적 프로그래밍(Structured Programming) 패러다임이 확립되었습니다.
이 철학의 정점에서 탄생한 것이 바로 1972년 데니스 리치와 켄 톰슨이 개발한 C언어입니다. C언어는 하드웨어를 직접 제어할 수 있는 강력한 로우레벨(Low-level) 제어 능력을 갖추면서도, 인간이 읽기 쉬운 하이레벨(High-level) 언어의 이점을 완벽하게 결합한 혁명적인 언어였습니다. UNIX 운영체제 개발과 맞물려 C언어는 폭발적인 인기를 얻었고, 소프트웨어의 이식성(Portability)을 극적으로 끌어올리며 현대 운영체제와 시스템 프로그래밍의 굳건한 표준으로 자리 잡았습니다.
3. 1980년대: 복잡성과의 전쟁, 객체 지향 프로그래밍(OOP)의 부상
1980년대는 개인용 컴퓨터(PC)의 보급과 함께 소프트웨어의 규모와 복잡도가 상상할 수 없을 정도로 거대해진 시기입니다. 기존의 구조적 프로그래밍과 데이터 중심의 접근 방식으로는 대규모 시스템을 안정적으로 구축하는 데 한계가 찾아왔고, 이를 타개하기 위해 객체 지향 프로그래밍(OOP)이 핵심 패러다임으로 부상했습니다.
현실 세계의 개념을 데이터와 기능이 묶인 '객체(Object)'로 모델링하여 재사용성과 유지보수성을 극대화하자는 이 철학은 시장을 완전히 바꾸어 놓았습니다. 1983년 비아네 스트롭스트룹은 C언어에 객체 지향 개념을 얹은 C++을 발표하며 고성능 시스템과 대규모 애플리케이션 개발의 지배자로 우뚝 섰습니다. 또한, 애플 매킨토시의 기반이 된 Objective-C가 주목받기 시작했고, 소프트웨어를 컴포넌트 조립식으로 개발하는 시대가 본격적으로 열렸습니다.
4. 1990년대: 인터넷의 폭발과 Java의 등장
1990년대는 월드 와이드 웹(WWW)의 보급과 함께 '네트워크 분산 환경'이 소프트웨어 개발의 핵심 화두로 떠오른 격동의 시기였습니다. 기존의 C/C++은 운영체제와 하드웨어 아키텍처가 바뀌면 프로그램을 매번 다시 컴파일해야 하는 심각한 파편화 문제를 겪고 있었습니다. 이러한 시대적 한계를 해결하기 위해 1995년 선 마이크로시스템즈는 "Write Once, Run Anywhere"를 슬로건으로 내건 Java(자바)를 출시합니다.
자바는 가상 머신(JVM)을 도입하여 하드웨어 종속성을 완벽히 극복했고, 메모리를 자동으로 관리해 주는 가비지 컬렉터 덕분에 안정적인 대형 웹 서버 구축의 독점적인 표준이 되었습니다. 한편, 웹 브라우저 안에서 역동적인 화면을 구현하기 위해 탄생한 JavaScript(자바스크립트)가 급부상했으며, 쉬운 문법과 빠른 개발 속도를 무기로 삼은 인터프리터 언어 Python(파이썬)과 웹 전용 언어인 PHP 등이 등장하여 웹 생태계의 대폭발을 이끌었습니다.
5. 2000년대: 엔터프라이즈의 다각화와 웹 생태계의 정착
2000년대는 90년대에 구축된 웹 기술이 고도화되고, 대규모 기업용 시스템(Enterprise) 시장이 성숙기에 접어든 시기입니다. 마이크로소프트는 자바의 독주를 견제하고 윈도우 생태계를 공고히 하기 위해 2000년 넷(.NET) 프레임워크와 함께 C# 언어를 발표했습니다. 이로 인해 시장은 자바 기반의 진영과 윈도우 기반의 C# 진영으로 양분되며 대형 아키텍처 경쟁이 심화되었습니다.
동시에 웹 표준과 비동기 통신 기술(AJAX)의 발전으로 단순한 문서 전달자에 불과했던 웹 페이지가 '웹 애플리케이션'의 형태로 진화하기 시작했습니다. 브라우저의 한계를 극복하려는 자바스크립트의 고도화가 진행되었고, 루비 온 레일즈(Ruby on Rails) 프레임워크의 성공과 함께 Ruby 같은 생산성 중심의 다이나믹 언어들이 주목받았습니다.
6. 2010년대: 모바일 혁명과 모던 언어의 세대교체
2010년대는 스마트폰의 폭발적인 보급으로 인한 모바일 혁명과 클라우드 컴퓨팅, 그리고 빅데이터/인공지능의 급부상이 프로그래밍 언어의 판도를 완전히 바꾸어 놓은 시기입니다. 스마트폰 앱 개발을 위해 구글의 안드로이드는 자바를, 애플의 iOS는 Objective-C를 채택하며 자바의 위상은 한층 더 공고해졌습니다. 하지만 기존의 오랜 언어들이 가진 무겁고 복잡한 문법을 탈피하기 위해 대기업 주도의 신생 '모던 프로그래밍 언어'들이 대거 등장했습니다.
애플은 iOS 개발을 위해 안전하고 직관적인 Swift를, 구글은 안드로이드 공식 언어로 Kotlin(코틀린)을 채택했으며, 사내 인프라 고도화를 위해 동시성 처리가 강력한 Go(고랭) 언어를 발표했습니다. 또한, 웹 생태계에서는 자바스크립트에 타입 시스템을 도입해 안정성을 높인 TypeScript(타입스크립트)가 대세로 부상했습니다. 한편, 방대한 데이터 처리와 머신러닝 생태계를 독점한 파이썬은 단숨에 전 세계에서 가장 인기 있는 언어의 자리에 올랐습니다.
7. 2020년대: 클라우드 네이티브와 에이전틱 AI(Agentic AI), 그리고 MCP의 시대
현재 2020년대의 프로그래밍 세계는 클라우드 네이티브(Cloud-Native) 인프라의 완전한 정착과 더불어, 단순한 코드 추천을 넘어 개발의 전 과정을 스스로 수행하는 자율형 AI 에이전트(Agentic AI)의 등장으로 유례없는 대격변을 맞이하고 있습니다. 마이크로서비스 아키텍처(MSA) 환경에 맞춰 메모리 안정성과 가공할 성능을 지닌 Rust(러스트)가 핵심 인프라 언어로 급부상했고, 자바 역시 가상 스레드(Virtual Threads)를 도입하며 클라우드 최적화 혁신을 이어가고 있습니다.
그러나 가장 파괴적인 변화는 '개발 패러다임' 그 자체에 있습니다. 초기의 단순 텍스트 완성형 어시스턴트를 넘어, 스스로 판단하고 코드를 작성 및 디버깅하는 에이전틱 AI(Agentic AI)가 개발 프로세스의 중심에 섰습니다. 특히 다양한 인공지능 모델들이 개발자의 로컬 개발 환경, 소스 코드 저장소, 개발 도구(IDE)의 컨텍스트를 안전하고 표준화된 방식으로 연결할 수 있도록 돕는 MCP (Model Context Protocol, 모델 컨텍스트 프로토콜)가 핵심 기술 표준으로 정착했습니다.
이제 프로그래머는 고립된 환경에서 타이핑하는 것을 넘어, MCP를 통해 프로젝트 전체의 맥락을 완벽히 이해하고 있는 AI 에이전트(예: 제미나이 기반 도구)에게 복잡한 설계와 아키텍처 리팩토링 작업을 지시하고 오케스트레이션(통제 및 조율)하는 고차원적 아키텍트의 역할을 수행하고 있습니다.
8. 요약: 프로그래밍 언어 발전을 돌아보며
돌아보면 컴퓨터 프로그래밍의 역사는 '인간 중심의 추상화'와 '생산성 극대화'를 향한 끊임없는 여정이었습니다.
0과 1의 기계어와 천공카드라는 투박한 물리적 제약에서 출발한 언어는, 하드웨어를 지배한 C언어의 구조적 패러다임을 거쳐, 거대한 시스템을 조립식으로 만드는 C++의 객체 지향 세계로 발전했습니다. 인터넷의 폭발과 함께 등장한 Java는 가상 머신(JVM)을 통해 하드웨어의 종속성을 무너뜨렸고, 2020년대에 이르러서는 MCP(Model Context Protocol)와 에이전틱 AI(Agentic AI) 생태계가 결합하면서 개발자가 반복적인 코드 구현에서 벗어나 오직 '비즈니스 논리와 고도화된 아키텍처 설계'에만 집중할 수 있는 진정한 추상화의 정점에 도달했습니다.
Java를 다시 공부하며 시작된 이 역사 탐구를 통해, 우리가 지금 당연하게 사용하는 문법과 도구들 속에 수많은 선배 개발자들의 치열한 고민과 격변의 비화가 녹아있음을 다시금 느끼게 됩니다. 앞으로 자바 공부를 이어가면서 마주할 다양한 기술적 아키텍처들도 이 거대한 역사의 흐름 속에서 한층 더 깊이 있게 이해할 수 있을 것 같습니다.
오늘날 자바(Java)는 단순한 프로그래밍 언어를 넘어 전 세계 거대한 IT 인프라를 지탱하는 거대한 플랫폼입니다. "한 번 작성하면, 어디서나 실행된다(Write Once, Run Anywhere)"라는 강력한 철학을 바탕으로 지난 30년간 수많은 격변을 겪으며 발전해 왔습니다.
자바의 역사를 이해하는 것은 단순히 과거의 기록을 보는 것을 넘어, 현대 엔터프라이즈 소프트웨어 아키텍처가 왜 지금과 같은 모습으로 자리 잡았는지 이해하는 핵심 열쇠입니다. 개인용 개발을 위한 표준 에디션(Java SE)과 대규모 기업 시스템을 위한 에디션(Java EE)이라는 두 축이 시대의 흐름에 따라 어떻게 발맞추어 성장하고 변천해 왔는지, 그 흥미진진한 역사의 타임라인과 숨겨진 비화를 정리해 드립니다.
2. 본론
① Java SE & Java EE 통합 연혁 타임라인
자바의 표준 스펙(SE)과 기업용 분산 환경 스펙(EE)은 기술의 발전과 패러다임의 변화에 맞춰 유기적으로 결합하며 진화해 왔습니다. 최초의 버전부터 현재에 이르기까지의 핵심 마일스톤입니다.
JDK 1.0 (1996): 최초의 공식 버전, 제임스 고슬링의 '오크(Oak)' 프로젝트에서 시작된 자바 언어의 탄생
JDK 1.1 (1997): 내부 클래스, 데이터베이스 연동을 위한 JDBC, 컴포넌트 모델인 JavaBeans 도입
J2SE 1.2 / J2EE 1.2 (1998~1999): 스윙(Swing) GUI 및 컬렉션 프레임워크 추가 / 최초의 기업용 스펙(Servlet, JSP 1.1) 표준화
J2SE 1.4 / J2EE 1.4 (2002~2003): 정규표현식 및 비동기 NIO 지원 / 웹 서비스(Web Services) 기본 프로필 지원
Java SE 5 / Java EE 5 (2004~2006): 제네릭, 열거형(Enum), 어노테이션 도입 / EJB 3.0 도입으로 기업용 개발의 복잡성 대폭 완화
Java SE 6 / Java EE 6 (2006~2009): JVM 가비지 컬렉션 성능 향상 및 스크립트 지원 / 웹 프로필(Web Profile) 개념 및 CDI(의존성 주입) 최초 도입
Java SE 7 / Java EE 7 (2011~2013): 다이아몬드 연산자 및 try-with-resources 추가 / HTML5 지원 파이프라인 구축 및 WebSocket 표준 채택
Java SE 8 / Java EE 8 (2014~2017): 람다식, 스트림(Stream) API 혁신 / 오라클 주도의 마지막 기업용 버전, HTTP/2 지원 및 JSON-B 추가
Java SE 11 / Jakarta EE 8 (2018~2019): 6개월 정기 출시 주기 정착 / 이클립스 재단으로 이관 후 첫 버전 (기능은 Java EE 8과 동일)
Java SE 17 / Jakarta EE 9 (2021~2020): 봉인된 클래스 정식 추가 / 패키지 명칭 대전환 (javax.* -> jakarta.* 변경)
Java SE 21 / Jakarta EE 10 (2023~2022): 가상 스레드(Virtual Threads) 도입으로 동시성 혁신 / 클라우드 네이티브 아키텍처 공식 지원
Java SE 25 / Jakarta EE 11 (2025~2024): 최신 장기 지원(LTS) 버전으로 안정성 확보 / 가상 스레드 기술을 기업용 스펙에 본격 통합
Java SE 26 (2026): 최신 버전, HTTP/3 지원 및 런타임 성능의 지속적인 개선
② Java EE에서 Jakarta EE로의 대전환과 상표권 분쟁 비화
자바가 전 세계 금융권과 대기업 시스템의 백엔드를 독점할 수 있었던 원동력은 Java EE였습니다. 하지만 2010년 오라클(Oracle)이 선 마이크로시스템즈를 인수하면서 자바 생태계에는 거대한 제약과 격변이 일어납니다. 오라클 체제 하에서 기업용 자바 표준의 발전이 정체되자, 오픈소스 커뮤니티는 더 개방적인 혁신을 요구했습니다. 결국 2017년, 오라클은 Java EE의 소스 코드와 운영 권한을 오픈소스 재단인 이클립스 재단(Eclipse Foundation)에 완전히 넘겨주기로 결정합니다.
그러나 이 아름다운 이관 과정 뒤에는 거대한 상표권 갈등이 숨어 있었습니다. 오라클이 소스 코드는 넘겼지만, 'Java'라는 브랜드 상표권만큼은 자신들의 소유라며 양도하지 않은 것입니다. 이로 인해 이클립스 재단은 기존의 명칭인 'Java EE'를 더 이상 사용할 수 없게 되었고, 소스 코드 내부에서 수십 년간 표준으로 사용되던 핵심 패키지 명칭인 java.*와 javax.* 역시 새로 업데이트하는 코드에 사용할 수 없게 되는 사상 초유의 제약을 받게 됩니다.
결국 이클립스 재단은 커뮤니티 투표를 거쳐 Java EE의 새 이름으로 Jakarta EE(자카르타 EE)를 공표합니다. 그리고 명칭만 바꾼 것에 그치지 않고, Jakarta EE 9에 이르러 소스 코드 내부의 핵심 API 경로를 javax.servlet.*에서 jakarta.servlet.* 형태로 통째로 바꾸는 대대적인 이주(Migration) 작업을 단행합니다.
이 변화는 초기에 전 세계 수많은 라이브러리와 프레임워크(대표적으로 스프링 부트 3.0 이상 버전)가 코드를 완전히 리팩토링해야 하는 극심한 호환성 진통을 유발했습니다. 하지만 결과적으로 오라클이라는 단일 기업의 독점적 제약에서 완전히 벗어나, 전 세계 개발자와 기업들이 함께 주도하는 진정한 의미의 '개방형 클라우드 네이티브 기업용 자바 표준'으로 완벽하게 재탄생하는 위대한 계기가 되었습니다.
3. 요약: 독점에서 개방으로, 쉼 없이 진화하는 자바 생태계
자바의 역사는 단순히 소프트웨어 버전 업그레이드의 기록이 아니라, 하드웨어의 한계와 기업의 독점 시도를 기술적 아키텍처와 커뮤니티의 힘으로 우아하게 해결해 온 투쟁의 역사입니다.
C/C++의 메모리 관리 한계를 극복하기 위해 가전제품 제어용 '오크' 언어로 출발한 자바는 웹의 폭발적인 성장과 함께 표준 스펙(SE)을 다져왔으며, 대규모 기업 환경을 겨냥한 EE 스펙을 통해 시장의 절대 강자로 군림했습니다. 비록 오라클 인수 이후 상표권 분쟁이라는 초유의 진통을 겪으며 javax 패키지를 jakarta로 통째로 바꾸는 아픔을 겪었지만, 이 계기를 통해 자바는 특정 기업의 전유물이 아닌 진정한 오픈소스 커뮤니티 중심의 '개방형 표준'으로 거듭날 수 있었습니다.
탄생한 지 30년이 넘은 지금도 최신 가상 스레드 기술(Virtual Threads)과 클라우드 네이티브 아키텍처를 적극 흡수하며 진화하고 있는 자바는, 앞으로도 오랫동안 전 세계 백엔드 생태계의 견고한 표준으로 자리를 지킬 것입니다.
자바(Java)는 전 세계 수많은 개발자가 사용하고 있는 현대 소프트웨어 개발의 핵심 프로그래밍 언어입니다. 1990년대 중반에 처음 등장한 이후, 가전제품부터 시작하여 웹 애플리케이션, 거대한 기업용 시스템, 그리고 스마트폰 앱에 이르기까지 거의 모든 IT 영역에서 중추적인 역할을 담당해 왔습니다.
자바를 관통하는 가장 중요한 철학은 "한 번 작성하면, 어디서나 실행된다(Write Once, Run Anywhere)"입니다. 이는 기존의 언어들이 특정 운영체제나 하드웨어에 종속되어 코드를 매번 다시 작성하거나 수정해야 했던 한계를 정면으로 돌파한 혁신이었습니다. 자바는 강력한 안정성과 보안성, 그리고 객체 지향 프로그래밍이라는 직관적인 개념을 바탕으로 설계되어 복잡한 시스템도 안정적으로 유지보수할 수 있는 기반을 제공합니다.
특히 인터넷의 폭발적인 성장과 궤를 같이하며 네트워크 기능이 기본적으로 내장되어 있어, 분산 환경에서 데이터를 주고받는 프로그램을 개발하는 데 최적의 효율을 발휘합니다. 오늘날 자바는 단순히 하나의 언어를 넘어, 방대한 생태계와 표준을 제시하는 거대한 플랫폼으로 자리 잡고 있습니다.
2. 컴퓨터 언어의 종류
컴퓨터가 이해하는 근본적인 언어는 0과 1로 이루어진 기계어입니다. 하지만 사람이 직접 기계어를 작성하는 것은 불가능에 가깝기에, 이를 사람이 읽을 수 있는 문자 형태로 일대일 대응시킨 어셈블리어가 등장했습니다. 이후 기술이 발전하면서 인간의 언어와 유사한 고급 프로그래밍 언어들이 개발되었습니다.
고급 언어는 크게 두 가지 방식으로 실행됩니다. C언어와 같은 컴파일러 언어는 작성한 소스 코드를 실행하기 전에 컴퓨터가 이해할 수 있는 기계어로 한 번에 번역해 둡니다. 번역 과정이 미리 끝나 있기 때문에 실행 속도가 매우 빠르다는 장점이 있습니다.
반면, 베이직(Basic)과 같은 인터프리터 언어는 코드를 한 줄씩 읽어가며 즉석에서 번역하고 실행합니다. 빌드하는 과정이 없어 개발자가 코드를 수정하고 바로 확인하기에 편리하지만, 실행 속도는 컴파일러 언어에 비해 상대적으로 느립니다.
3. Java의 역사
자바는 1991년 선 마이크로시스템즈(Sun Microsystems)의 제임스 고슬링이 이끄는 그린 프로젝트(Green Project)에서 시작되었습니다. 당초 연구원들의 목표는 가전제품이나 셋톱박스 등 다양한 임베디드 장치에서 동작하는 소프트웨어를 만드는 것이었습니다. 당시 지배적이었던 C나 C++ 언어는 하드웨어와 운영체제에 맞춰 코드를 일일이 변경해야 했고, 메모리를 잘못 관리하면 시스템이 쉽게 다운되는 치명적인 문제가 있었습니다. 가전제품은 컴퓨터보다 메모리 환경이 열악하고 오작동이 용납되지 않기에, 제임스 고슬링은 C++의 강력한 기능을 유지하면서도 더 안전하고 이식성이 높은 새로운 언어를 개발하게 되었는데 이것이 바로 자바의 모태인 '오크(Oak)'였습니다.
이후 이 언어는 인터넷의 가능성을 발견하고 웹 브라우저에서 실행 가능한 기술로 발전하며 1995년에 'Java'라는 이름으로 공식 발표됩니다. 웹의 대중화와 함께 자바는 폭발적인 인기를 얻었으며, 2010년 오라클(Oracle)이 선 마이크로시스템즈를 인수하면서 현재는 오라클의 주도 하에 지속적인 성능 개선과 오픈소스 생태계 확장을 이어가고 있습니다.
4. Java의 에디션 차이: Standard Edition vs Enterprise Edition
자바는 사용 목적과 규모에 따라 여러 가지 에디션(Edition)으로 나뉘어 제공됩니다. 가장 기본이 되는 자바 SE(Java Standard Edition)는 자바 언어의 핵심 기능을 담고 있습니다. 변수, 데이터 타입, 객체 지향 프로그래밍 문법을 비롯하여 파일 입력과 출력, 네트워크 통신 등 일반적인 컴퓨터 애플리케이션을 개발하는 데 필요한 표준 API를 제공합니다.
반면 자바 EE(Java Enterprise Edition, 현재 명칭 Jakarta EE)는 SE를 기반으로 하여 대규모 기업용 시스템 개발에 특화된 기능을 확장한 버전입니다. 대형 웹사이트를 구축하기 위한 서블릿(Servlet)과 JSP, 분산 환경을 위한 엔터프라이즈 기술, 그리고 복잡한 데이터베이스 연동과 대용량 트랜잭션 처리를 안정적으로 지원하는 사양들이 포함되어 있습니다. 일반적인 개발은 SE로 충분하지만, 거대한 백엔드 서버나 금융권 시스템 등을 다룰 때는 EE의 생태계가 필수적으로 활용됩니다.
5. Java 가상 머신(JVM)과 개발 키트(JDK)
자바 개발과 실행 환경을 이해하기 위해서는 JVM과 JDK의 관계를 아는 것이 중요합니다.
먼저 JVM(Java Virtual Machine, 자바 가상 머신)은 자바 프로그램이 운영체제 종류에 상관없이 실행될 수 있도록 돕는 핵심 장치입니다. C언어는 특정 OS용 기계어로 컴파일되지만, 자바는 중간 형태인 '바이트코드'로 변환된 후 각 OS에 설치된 JVM 위에서 실시간으로 해석되어 실행됩니다. JVM 덕분에 개발자는 운영체제마다 코드를 새로 짤 필요가 없습니다.
그리고 이 JVM을 포함하여 자바 프로그램을 실제로 개발하는 데 필요한 모든 도구를 모아둔 종합 패키지가 바로 JDK(Java Development Kit, 자바 개발 키트)입니다. JDK 안에는 자바 소스 코드를 바이트코드로 바꾸어 주는 컴파일러(javac)와 디버깅 도구, 그리고 코드를 실행할 수 있는 환경(JRE/JVM)이 모두 포함되어 있습니다. 결론적으로 개발자는 JDK를 설치하여 프로그램을 만들고, 완성된 프로그램은 JVM을 통해 사용자 환경에서 돌아가게 됩니다.
6. 요약
결론적으로 자바는 C언어의 강력한 제어 능력과 베이직 같은 인터프리터 언어의 유연함, 그리고 기계어와 어셈블리어가 가진 하드웨어 종속성을 극복하기 위해 탄생한 스마트한 고급 언어입니다.
C언어처럼 JDK의 컴파일러를 거쳐 바이트코드를 생성하므로 실행 효율을 높이면서도, JVM이라는 가상 머신을 통해 인터프리터처럼 실시간으로 환경에 맞춰 실행되는 독특한 하이브리드 방식을 취하고 있습니다. 또한 개인용 앱을 위한 표준 SE부터 대규모 기업 시스템을 위한 EE까지 용도별 맞춤 표준을 제시하여 확장성까지 확보했습니다.
메모리를 자동으로 관리해 주는 편리함과 플랫폼 독립성이라는 무기를 바탕으로 출발한 자바는, 하드웨어와 운영체제의 한계를 소프트웨어적 아키텍처로 우아하게 해결하며 오늘날 전 세계 소프트웨어 산업의 견고한 표준으로 자리 잡았습니다.
public static void main(String[] args) throws GeneralSecurityException, IOException {
String encodeText = encode("Hello World. Welcome to Korea. * ");
System.out.println(encodeText);
System.out.println("encoded Text : " + encodeText);
String decodeText = decode(encodeText);
System.out.println("decoded Text : " + decodeText);
}
Hello World. 으로 시작하는 문자열을 암호화 했다가 복후화 하는 코드 입니다.
실행하면
encoded Text : c8AcbCp4bIARJA3EOW9cf41pRIefVhCvCWyxwcgwifWaDK8AX9RJoe8dOgPzuvauCZZG5ibbOMtvEPh06DUwojFzMngCtT3T6VOyzWDA/CBFN52jXZzqw9M1K1v3vZJ+0uft86TomxZvbWdxv5XPo5keh0HyWyexv3U5c5cXypMwBTDECUiQkUPjZN1aUf7dHGQG0uC+KuyNEKK4NDMddPWoo0gzlWxsxIBkm7oLpuKEcXP9ThM16JQD8rhskJbXwbhUL39xfmDSti8Om9DcrU6KCDakKeT7i72yRjAD5B60Da28jT1DlzwS9p7IlfPXdlybjLKUMUcQsF1rJ1Xvww==
decoded Text : Hello World. Welcome to Korea. *
원래 이책을 산 이유는 Maven이라는 툴에 대해서 알고 싶어서였습니다. 하지만, 사고 나서 보니 Maven 보다는 이책에서 지향하는 목표가 참 마음에 들었습니다.
이책의 저자인 박재성님은 자바지기(http://www.javajigi.net)라는 웹사이트를 운영하고 계시는 분이니다. 저는 박재성님의 책을 몇권더 읽었습니다. Spring 과 스트럿츠에 관한 책입니다. 그 책들도 프로젝트 하는데 실질적으로 도움이 많이 되었습니다.
아직 이책을 다 읽진 못했지만 이책에서 필요한 점들은 도입하고 있습니다. ^^;; 우선 이책을 읽기전에 제가 하는 프로젝트에 여러명의 개발자가 참여 하기 때문에 Subversion을 버전 관리툴로 사용하고 있었습니다. 프로젝트를 진행하다가 이 책을 사게 되었습니다. 우선 애자일(기민한) 방법론에 대한 이야기가 참 마음에 들었습니다. 그리고, 저자가 이야기 하는 이야기 중에 애자일 방법론을 완벽하게 국내에 도입하기는 어렵다 하지만, 필요한 부분만 잘 적용하면 좋은 프로젝트 방법론이 될 것이라는 이야기는 실감이 나는 이야기 입니다. 저도 프로젝트를 많이 해봤지만, 애자일 방법론을 적용하기는 무리가 좀 있다고 생각합니다. 하지만, 방법론에서 사용하는 여러가지는 참고하고 사용해볼만하다고 생각합니다.
그리고 프로젝트 관리툴을 도입하는 이야기가 적혀 있습니다. 이책에서는 Trac에 대해서 이야기 하고 있지만 저는 이번 프로젝트를 하면서 Trac을 도입하고 싶었습니다. ^^;; 하지만, Trac까지는 설치를 했는데 Subversion 연동이 잘 되질 않아서 ^^;; Mantis라는 이슈관리툴로 만족하고 있습니다. 이 책에 보면 Trac과 eclipse의 연동 방법이 나옵니다. 그 부분은 Trac을 Mantis로만 바꿔서 사용하면 그대로 적용할 수 있습니다.
아직 다 읽지 못했기 때문에 뒤쪽에 소스코드 관리라던지, 정작 필요한 Maven에 관한 내용은 건너 띄고 읽고 있습니다. ^^;;
Java 프로젝트를 진행하는데 정말 도움이 되는 책입니다. ^^;; 이 책에서 읽은 내용과 인터넷에서 찾은 내용들은 다음 포스트에서 차근 차근 이야기를 풀어 볼까힙니다. ^^;;
