1.1 들어가며
1.2 자바 기술 시스템
1.3 자바의 과거와 현재
1.4 자바 가상 머신 제품군 - 핫스팟 VM
1.5 자바 기술의 미래
1.1 들어가며
자바는 엄격한 구조를 갖춘 객체 지향 프로그래밍 언어란 점 외에도 아래와 같은 장점들이 있다.
- 하드웨어 플랫폼이라는 족쇄를 제거하여 `한 번 작성하면 어디서든 실행된다`
- 상당히 안전한 `메모리 관리 시스템`을 갖춘 덕에 메모리 누수 문제와 엉뚱한 메모리를 가리키는 문제 대부분을 피할 수 있다.
- 런타임에 핫 코드를 감지, 컴파일하고 최적화하여 최상의 성능을 내도록 도와준다.
- 표준 API 자체가 풍부할 뿐 아니라 수많은 기업과 오픈 소스 커뮤니티에서 제공하는 다양한 기능의 서드 파티 라이브러리를 활용할 수 있다.
1.2 자바 기술 시스템
JRE(Java Runtime Enviroment)는 자바 프로그램을 실행할 수 있는 표준 환경을 제공한다.
실행용 환경 (JVM 포함, 개발 도구 없음)
JDK(Java Development Kit)는 자바 프로그램 개발에 필요한 최소한의 환경이다.
개발용 키트 (JRE 포함)
1.3 자바의 과거와 현재
1.3.1 자바의 탄생
한 번 작성하면, 어디서든 실행된다
(Write Once, Run Anywhere)
1991년 제임스 고슬링 박사의 그린 프로젝트에서 시작되었다. 이 프로젝트는 자바 언어의 시초가 된 오크(Oak)를 낳았다. 오크는 당시 목표한 시장에서 제대로 자리 잡지 못했으나 1995년부터 인터넷이 급부상하면서 빠르게 자바 언어로 진화하게 된다. 1995년 오크 언어는 이름을 자바로 바꾸고, 썬월드(SunWorld) 콘퍼런스에서 자바 1.0이 정식 데뷔한다. 자바의 구호인인 `Write Once, Run Anywhere` 가 처음으로 제시된 날이다.
1996년 JDK 1.0 출시 - JDK 1.0의 자바 가상 머신(썬 클래식VM)은 순수한 인터프리트(해석) 방식이었다.
1.3.2 유년기
JDK 1.3 - 기본 자바 가상 머신으로 핫스팟 가상 머신 제공
JDK 1.4 - JDK 1.4에 와서 자바가 진정으로 성숙됐다고 볼 수 있다. 20년 정도 지난 오늘까지도 주류 애플리케이션 중 JDK 1.4로 구동되거나 1.4 버전을 지원하는 제품이 존재할 정도다.
2002년에는 마이크로소프트 닷넷(.NET) 프레임워크가 등장하였다.
JDK 5 - 이 버전부터 썬은 `JDK 1.x` 방식의 이름을 버리고 `JDK x` 형태로 부르기로 한다. 코딩 편의성을 개선하는 큰 폭의 변화 (오토박싱, 제네릭스, 동적 애노테이션, 열거형, 가변 길이 매개 변수, foreach 순환문 등의 문법 변화..),
1.3.3 오픈 소스의 세계로
2006년 JDK 6 - 2006년 11월 자바원 콘퍼런스에서 썬은 자바를 오픈 소스로 전환할 계획을 발표한다. JDK 6 출시 후 코드 복잡도 증가, 자바의 오픈 소스화, 자바FX 개발, 세계 경제 위기, 오라클에 썬 매각 등에 너무 많은 에너지와 자원을 허비한 썬은 자바를 제대로 돌보지 못하게 된다.
1.3.4 오라클의 품으로
2009년 오라클의 썬 인수 - 오라클은 시장 가치 2000억 달러 이상인 썬 마이크로시스템즈를 74억 달러에 인수 완료했다. 당시 썬은 기술 및 비즈니스 경쟁에서 어려움을 겪고 있었으며, 주가가 하락하면서 JDK 7의 주요 개선 사항인 람다, 직소, 동적 언어 지원 등의 개발도 차질을 빚었다. 오라클은 인수 후, 플랜B를 가동하여 JDK 7의 일부 기능들을 JDK 8로 연기했다. 그 결과, 2011년에 출시된 JDK 7에는 G1 컬렉터만이 주요 개선 사항으로 포함되었고, 그마저도 실험 버전이었다.
1.3.5 모던 자바의 시작
2014년 출시된 JDK 8(LTS)은 오라클이 JEP 제도를 도입하여 JDK 개선 사항을 체계적으로 관리하기 시작한 첫 버전이다. JDK 8에는 JDK 7에서 완성하지 못한 여러 기능들이 포함되었다. 주요 기능은 다음과 같다:
- JEP 126: 람다식 지원, 함수형 프로그래밍 도입
- JEP 104: 나스혼 자바스크립트 엔진 내장
- JEP 150: 새로운 시간 및 날짜 API 도입
- JEP 122: 핫스팟에서 영구 세대 제거
직소(모듈화 기능)는 JDK 9로 다시 연기되었으며, 자바 개발 역사상 가장 큰 도전 과제 중 하나였다.
2017년 JDK 9는 오라클과 OSGi 연합 간의 모듈화 표준을 둘러싼 치열한 경쟁 속에서 출시되었다. IBM이 이끄는 OSGi 연합은 OSGi를 자바 표준 모듈 시스템으로 삼길 원했지만, 오라클은 직소를 JDK 9의 표준 모듈 시스템으로 도입하려 했다. 결국, 오라클의 제안이 채택되어 JDK 9는 직소와 함께 출시되었다.
1.3.6 기민하게
JDK 9 출시 후, 오라클은 자바 개발을 기민하게 진행하고 매년 3월과 9월에 JDK 메이저 버전을 두 차례 출시하는 지속적 배포 형태로 전환했다. 이를 통해 기능 추가 과정에서 발생하는 위험을 줄이고 출시 지연 문제를 해결했으나, JDK 버전이 많아지면서 유지보수와 기술지원에 어려움을 겪게 되었다.
해결책으로 오라클은 모든 JDK 버전을 최소 3년 이상 지원하는 전통을 끝내고, 매 6번째 메이저 버전만 LTS 버전으로 지정했다. 2021년에는 정책을 바꿔 LTS 버전을 2년 주기로 출시하기로 하였으며, JDK 17 다음 LTS는 2023년에 출시된 JDK 21이다.
JDK 11(LTS) - ZGC 실험 버전의 추가, 타입 추론의 람다 구문 지원 등
JDK 12에서 가장 주목받은 기능 중 하나는 레드햇이 개발한 셰넌도어 가비지 컬렉터였다. 이는 오라클 외부에서 개발된 첫 번째 가비지 컬렉터로, JDK 11에 포함된 오라클의 ZGC와 유사한 목표를 가지고 있어 경쟁 관계에 놓였다. 오라클은 이에 대응해 JDK 12에서 조건부 컴파일을 이용해 오라클 JDK에서 셰넌도어 코드를 제거했다. 결과적으로 셰넌도어는 OpenJDK에서만 사용할 수 있는 기능이 되었다.
JDK 14~16
- JDK 14: 새로운 switch 문이 정식 표준 기능이 되었다.
- JDK 15: ZGC와 셰넌도어 가비지 컬렉터가 실험 버전에서 정식 기능으로 전환되었다.
- JDK 16: 메타스페이스 관리 방식이 개선되었으며, 언어 측면에서는 instanceof 패턴 매칭과 레코드 클래스 도입 등의 개선이 이루어졌다.
JDK 17(LTS)에서는 봉인된 클래스가 도입되고, 의사 난수 생성기가 개선되었다. JDK 11과 비교해 70개 이상의 JEP가 추가되었으며, 실험 버전이었던 AOT(Ahead-of-Time) 컴파일러는 삭제되었다.
JDK 21(LTS)에서는 JDK 17과 비교해 37개의 JEP가 추가되었다. 주요 변화로는 세대 구분 ZGC와 가상 스레드 도입이 있다. 세대 구분 ZGC는 기존 ZGC에 세대별 가비지 컬렉션을 추가한 버전이며, 가상 스레드는 자바의 동시성 프로그래밍에 큰 변화를 가져왔다. 커널 스레드에 의존하지 않게 되어 더 많은 스레드를 동시에 운용할 수 있게 되었고, 지연 시간이 크게 개선되었다.
1.4 자바 가상 머신 제품군
많은 자바 개발자가 `자바 가상 머신`을 오라클 JDK의 `핫스팟 가상 머신`과 동일시한다. 물론 BEA의 JRockit이나 이클립스의 openJ9(IBM의 J9) 가상 머신을 떠올리는 개발자도 있을 것이다. 하지만 대다수는 구체적인 제품명이 아니라 전체를 그저 `자바 가상 머신`으로 인식한다. 이번 절에서는 자바 가상 머신 제품군의 개발 궤적과 역사적으로 중요한 변화 과정을 살펴보겠다.
1.4.1 가상 머신의 조상: 썬 클래식 VM과 이그잭트 VM
1996년 JDK 1.0에 포함된 가상 머신을 클래식 VM이라 한다. 이 가상 머신은 자바 코드를 순전히 인터프리터 방식으로 실행했다. JIT 컴파일러를 사용하려면 플러그인을 추가하면 됐는데, 플러그인하는 순간 가상 머신의 실행 시스템 전체가 JIT 컴파일러에 넘어가는 구조였다. 즉 인터프리터는 더 이상 동작하지 않았다. 당시 인터프리터와 컴파일러는 함께 구동되지 않았기 때문에 컴파일러를 사용하기 시작하면 실행 빈도 등 컴파일에 따른 득실과 상관없이 `코드 전체`를 컴파일해야 했다. 그래서 자칫하면 프로그램 응답 속도가 너무 느려지므로 오래 걸리는 최적화 기법은 적용할 수 없었다. JIT 컴파일러로 네이티브 코드를 만들어 냈음에도 C, C++ 프로그램보다 실행 효율이 훨씬 나쁠 수밖에 없던 이유다. 이 차이 때문에 `자바 언어는 느리다`는 인상이 개발자들 머릿속에 자리 잡기 시작했다.
썬의 가상 머신 개발 팀은 클래식 VM이 직면한 이 효율성 문제를 해결할 방법을 고심했다. JDK 1.2와 함께 공개된 이그잭트 VM이 그 결실이다. 이그잭트 VM은 상용으로 활용하기 시작한 지 얼마 안 되어 썬 외부에서 개발된 핫스팟 VM으로 대체되었다. JDK 1.2까지의 기본 가상 머신은 클래식VM이었고, JDK 1.3부터는 핫스팟 VM이 기본 가상 머신으로 사용되어 이그잭트 VM은 단명하였다.
1.4.2 일인자: 핫스팟 VM
썬, 오라클 JDK와 OpenJDK의 기본 가상 머신이자 가장 널리 사용되는 자바 가상 머신이다. 처음에는 롱뷰 테크놀러지스라는 작은 회사에서 Self라는 언어의 실행 효율을 높이고자 개발된 가상 머신이었다. 1997년 썬은 롱뷰 테크놀러지스를 인수하여 핫스팟 VM을 손에 넣었다.
대표적인 기술로는 `핫스팟` 이란 이름을 탄생시킨 핫 코드 감지(hot code detection) 기술이다. `컴파일했을 때 효과를 가장 크게 볼 수 있는 코드 영역` 을 런타임에 알아내어 JIT 컴파일러에 알려준다. 그러면 JIT 컴파일러가 해당 코드를 메서드 단위로 컴파일한다. 메서드가 자주 호출되거나 메서드 안에 시간을 많이 잡아먹는 순환문이 있다면 JIT 컴파일을 수행해 스택을 치환하는 것이다. 이처럼 런타임에 스택을 치환하는 기술을 온스택 치환(OSR)이라고 한다. 이런 식으로 컴파일러와 인터프리터가 조화롭게 협력해 프로그램 응답 속도와 실행 성능 사이의 균형을 잡아 주는 것이다. 컴파일 없이 즉시 실행한 다음, 일부 코드만 백그라운드에서 컴파일하여 치환하는 방식이다. JIT 컴파일을 빨리 끝내야 한다는 압박이 크게 줄어든 덕분에 더 복잡한 최적화 기법을 도입하여 고품질 네이티브 코드를 만들어 낼 수 있게 되었다.
1.5 자바 기술의 미래
오라클의 썬 인수 이후 자바는 빠른 개발 속도와 활발한 경쟁으로 전환되었지만, 혁신 속도, 경쟁 언어, 클라우드 및 마이크로서비스 적응 등의 도전에 직면했다. 이 위기들은 자바의 성장 기회가 될 수 있으며, 앞으로의 발전은 자바 진영이 이러한 도전에 어떻게 대응하느냐에 달려 있다. 이번 절은 이런 맥락에서 오라클 연구소에서 한창 연구 중인 그랄 VM, 발할라, 앰버, 파나마 등 미래 지향적인 프로젝트들을 소개하겠다.
1.5.1 언어 독립
인터넷에서 이따금 `앞으로 자바를 대체할 언어`라는 주제의 이야기를 볼 수 있다. 주인공으로는 코블린, 고, 자바스크립트, 파이썬 등이 자주 언급된다. C언어와 함께 지난 20여 년 동안 줄곧 1~2위를 다투던 자바는 인공 지능과 파이썬의 급부상으로 2020년대 들어 3~4위로 살짝 내려온 상황이다. (TIOBE Index - TIOBE)
자바가 다른 언어로 대체된다고 해서 두려워할 이유는 없다. 더구나 거대한 사용자 기반과 성숙한 소프트웨어 생태계 덕에 업계에서 자바의 중요도가 하루아침에 흔들리기는 어렵다. 하지만 자바스크립트는 인터넷, 파이썬은 인공 지능, 고 언어는 마이크로서비스 등의 사례에서 볼 수 있듯이 새로운 시장을 등에 업고 세를 넓혀 가는 언어들이 끊임없이 등장하고 있다. 모든 분야를 지배할 수 있는 언어는 없다. 자바는 한때 그 위치에 가장 가까운 언어처럼 보였지만, 그보다 더 크게 발전하기 위해서는 자바 언어 자체를 잊고 기반 기술 영역으로 들어가야 할 것이다.
2018년 4월 오라클 연구소는 그랄VM 이라는 새로운 기술을 발표했다. 강렬한 야망을 담은 `Run programs faster anywhere`라는 구호를 보면 자바의 `Write Once, Run Anywhere`가 떠오른다.
`유니버설 VM` 또는 `폴리글랏 VM` 이라고도 하는 그랄VM은 핫스팟 가상 머신 위에 구축된 `크로스 언어 풀 스택 가상 머신`이다. 자바, 코틀린, 스칼라, 그루비 같은 자바 가상 머신 언어들은 물론 LLVM 기반 컴파일러를 사용하는 C, C++, 러스트 같은 언어들, 그 외 자바스크립트, 루비, 파이썬, R, 웹어셈블리까지도 지원한다. 서로 다른 언어들이 데이터를 같은 메모리 공간에서 주고받을 수 있고, 각 언어용으로 작성된 기존 네이티브 라이브러리들도 사용할 수 있다.
그랄 VM은 기본적으로 각종 언어의 소스 코드를 인터프리터를 통해 그랄VM이 이해할 수 있는 중간 표현(IR)으로 변환하는 식으로 동작한다. 그랄 VM은 진정한 의미에서 `물리 머신에 대응하는 고수준 언어 가상 머신` 이다.
Run programs faster anywhere
어디서든 더 빠르게 실행한다
1.5.2 차세대 JIT 컴파일러
서버용 제품처럼 장기간 운용되는 애플리케이션에서는 자주 실행되는 핫 코드를 탐지하여 네이티브 코드로 컴파일한다. 이런 유형의 자바 애플리케이션은 JIT 컴파일러의 출력 품질이 실행 효율을 크게 좌우할 수밖에 없다.핫스팟 가상 머신은 기본적으로 JIT 컴파일러를 두 개 내장하고 있다. 하나는 컴파일 속도가 빠른 대신 최적화를 적게 하는 클라이언트 컴파일러(C1 컴파일러)이고, 다른 하나는 컴파일 속도는 느리지만 더 많은 최적화를 적용하는 서버 컴파일러(C2 컴파일러)이다. 여기에 인터프리터까지 포함하여 총 3개의 실행 메커니즘이 협력하여 핫스팟 가상 머신의 실행 서브시스템을 구성한다.JDK 10부터는 하나가 더 추가되었따. 바로 그랄 컴파일러이다. 그랄 컴파일러는 C2 컴파일러를 대체할 목적으로 핫스팟에 도입되었다. JDK 16부터는 개발과 관리 효율을 높이고자 그랄 컴파일러를 JDK에서 독립시켜 그랄VM으로 터전을 옮겼다.
1.5.3 네이티브를 향한 발걸음
장시간 실행할 필요가 없거나 크기가 작은 애플리케이션의 경우 자바로 개발하면 본질적인 단점이 몇 가지 있다. HelloWorld를 실행하려 해도 100MB가 넘는 JRE가 필요하다는 점도 있지만, 더 중요한 문제는 애플리케이션 아키텍처의 중심이 거대한 단일 아키텍처에서 작은 마이크로서비스 아키텍처로 빠르게 옮겨가고 있지만 자바는 이 추세와 잘 맞지 않는다는 점이다. 자바는 구동 시간이 길고 최고 성능을 내기까지 예열이 필요하다. 마이크로서비스가 요구하는 특성과는 반댄인 것이다. 게다가 서버리스 아키텍처에서는 이러한 모순이 더욱 두드러진다. 함수는 서비스보다도 크기가 작고 실행 시간이 짧다. 현재 가장 널리 쓰이는 서버리스 런타임인 AWS 람다는 함수 실행 시간을 최장 15분까지만 허용한다.
물론 서버 애플리케이션을 핵심 분야로 생각해 온 자바가 이런 흐름을 손에 놓고 있지많은 않았다. 최근 JDK에는 애플리케이션 클래스 데이터 공유(Class Data Sharing, AppCDS)와 노옵(no-op) 가비지 컬렉터인 엡실론 등의 기술이 포함되었다. AppCDS는 로딩한 클래스 정보를 캐시해두어 다음번 구동시간을 줄이는 기술이다. 앱실론은 메모리를 할당만해줄 뿐 회수는 하지 않는 컬렉터로, 간단한 작업을 빠르게 처리한 후 즉시 종료하는 애플리케이션에 매우 적합하다.
더 급진적인 기술로는 애플리케이션을 실행하기 전에 네이티브 코드로 컴파일해두는 AOT 컴파일이 있다. 사전(ahead of time)이란 의미의 AOT는 적시(just in time)의 상대적인 개념이다. 지금까지 자바 가상 머신은 애플리케이션을 우선 실행한 후 JIT 컴파일러를 써서 빈번하게 실행되는 로직을 네이티브 코드로 바꿔 실행했다. 하지만 컴파일을 미리 해두면 이러한 예열 과정을 건너뛰고 처음부터 네이티브 코드를 실행할 수 있다.
AOT 컴파일의 단점도 명확하다. `한 번 작성하면 어디서든 실행된다` 라는 자바의 약속을 지킬 수 없다. 다시 말해 하드웨어와 운영체제별로 따로 컴파일해 배포해야 한다. 또한 자바의 동적 링크 특성이 크게 줄어든다. 컴파일할 코드에 대한 모든 것을 컴파일타임에 알 수 있어야 한다는 뜻이다. 그렇지 않으면 사전에 컴파일된 결과를 폐기하고 JIT 컴파일 형태로 되돌아가야 한다.
JDK 9~15에서는 실험 버전의 AOT 컴파일러는 제공했으나 사용자 대부분은 실망했다. 그에 따라 서브스트레이트 VM이 등장했다. 그랄VM의 한 요소인 서브스트레이트 VM은 사전 컴파일된 네이티브 코드를 핫스팟 가상 머신 없이 실행하는 기술로 독자적인 예외처리, 스레드관리, 메모리관리, JNI 접근 메커니즘 등을 갖춘 극히 작은 런타임 환경이다. 그랄VM은 서브스트레이트VM과 사용자 프로그램을 하나로 묶어 네이티브 이미지를 생성한다. 이때 포인트 분석 기술을 활용하여 사용자 프로그램으로부터 도달 가능한 코드만 추려 네이티브 이미지에 담는다. 또한 이 과정에서 초기화까지 수행하여 최종 실행 파일이 생성되면 초기화된 힙 스냅샷을 저장해 둔다. 이런 식으로 자바 가상 머신이 수행하던 초기화 과정을 건너뛰고 프로그램을 곧바로 실행하여 초기 구동 시간을 획기적으로 줄인 것이다.
서브스트레이트VM은 구동 시간은 최대 50배 빨라지고, 메모리 사용량은 최대 5배까지 줄어든다.
1.5.5 언어 문법의 지속적인 개선
언어의 기능적 특성과 문법 이야기는 일부러 마지막으로 미뤄두었다. 상대적으로 가장 덜 중요한 개선이기 때문이다. 예컨대 인간 친화적이지 못한 문법을 갖춘 자바스크립트는 결국 엄청난 성공을 거두었고, 자바보다 문법이 훨씬 우아한 C#은 아직도 자바를 따라오지 못하고 있다. 그렇더라도 언어가 제공하는 기능과 문법은 생산성과 개발 효율에 많은 영향을 주는 중요한 요인임으 틀림없다. 언어를 날마다 사용하는 개발자에게는 행복한 선물일 수 있다. JDK 7의 코인 프로젝트가 완료된 후 자바 커뮤니티는 또 다른 언어 기능 개선 프로젝트인 앰버를 발족했다. JDK 10 이후로 정식 표준이 된 구문 개선은 다음과 같다.
- JEP-286: 지역 변수 타입 추론(var) (JDK 10)
- JEP-323: 람다식 매개 변수로 사용할 수 있도록 지역 변수 구문 개선 (JDK 11)
- JEP-361: switch 문을 표현식으로 사용할 수 있는 문법 추가 (JDK 14)
- JEP-378: Text Blocks - +없이 문자열 여러 줄을 쉽게 표현할 수 있는 문법 추가 (JDK 15)
- JEP-394: 패턴 매칭 능력을 부여해 instanceof 연산자의 표현력 강화 (JDK 16)
- JEP-395: 데이터 전달용 불변 클래스인 Record 타입 추가 (JDK 16)
- JEP-409: 자신을 확장하거나 구현할 수 있는 클래스와 인터페이스를 제한하는 Sealed 클래스&인터페이스 추가 (JDK 17)
- JEP-440: Record 클래스로부터 데이터를 가져올 때 패턴 매칭 제공 (JDK 21)
- JEP-441: switch문, 표현식의 패턴 매칭 능력 개선 (JDK 21)
여전히 진행 중인 개선안도 많다.
- JEP-430, JEP-443, JEP445, JEP447...
편의 문법 외의 언어 기능도 다방면에서 지속적으로 개선되고 있다. 현재 비교적 명확하게 드러난 프로젝트는 다음과 같다.
- 발할라 프로젝트, 파나마 프로젝트
아래는 아직 미정리된 내용들..
1995년 자바의 구호 `한 번 작성하면 어디서든 실행된다.`
2018년 그랄VM의 구호 `어디서든 더 빠르게 실행된다`
나는 아래와 같이 이해된다.
자바의 어디서든 - 하드웨어&운영체제에 대한 anywhere (운영체제 독립적인)
그랄VM의 어디서든 - 언어에 대한 anywhere (java를 넘어 언어 독립적인)
그랄VM의 더 빠르게 실행된다 - 네이티브 이미지를 통한 구현
다음 주제로 확인해볼 것.
2021년 9월 JDK 17 출시(LTS) - 봉인된 클래스가 도입되었고 의사 난수 생성기가 개선되다. 직전 LTS 버전인 DJK 11과 비교하면 추가된 JEP가 70개 이상이다.
JDK 11 대비 JDK 17에 추가된 JEP 확인해보기
2023년 9월 JDK 21 출시(LTS) - 직전 LTS인 JDK 17과 비교하면 총 37개의 JEP가 추가되었다. 가장 큰 변화는 세대 구분(generational) ZGC와 가상 스레드 도입일 것이다.
세대 구분 ZGC와 가상 스레드에 대해 알아보기
대표적인 기술로는 `핫스팟` 이란 이름을 탄생시킨 핫 코드 감지(hot code detection) 기술이다.
hot code detection 알아보기
JIT 컴파일러, AOT 컴파이러.. 이해하기
[Java] GraalVM이 제공하는 네이티브 이미지(Native Image) - MangKyu's Diary (tistory.com)
JVM 밑바닥까지 파헤치기 - 해당 책의 1장 자바 기술 시스템 소개를 주로 보고 작성 함.
JVM 밑바닥까지 파헤치기 - 예스24
“자바 가상 머신의 깊숙한 내부를 향해 떠나는 흥미진진한 모험”C·C++를 사용해 주로 프로그래밍을 하던 시절 까다로운 메모리 관리와 플랫폼 이식성 문제는 개발자들에게 적지 않은 부담이
www.yes24.com