9월, 2017의 게시물 표시

[Java] Java 9의 모듈 시스템에 대한 단상

우여곡절 끝에 자바 9에 jigsaw 즉, Java Platform Module System이 포함되어 출시되었다. 오래동안 사용되던 ClassLoader 기반의 OSGi와 다르게 Java Platform Module System은 JDK 내부적으로 module을 지원한다. 이를 위해 java.lang.ClassLoader 등의 클래스가 module 관련 선언에 있는 내용대로 접근성이 허용되는지를 내부적으로 체크하도록 JDK 코드가 수정되었다. 그 외에도 모듈에 선언된 것 외에는 타 모듈의 클래스를 액세스할 수가 없는데 Class.forName(...)을 통해 Class 객체는 구할 수 있지만 newInstance 등을 통해 인스턴스 객체를 만들려고 시도하는 순간 에러가 나게 된다. 이 점은 기존 코드와 심각하게 비호환되게 하는데 이를 완화하기 위해 java.util.ServiceLoader를 통해서 객체를 만들 수 있도록 하고 있다. (이게 가능하려면 해당 제공 모듈에서 provides를 선언해야만 한다.) 기존의 자바는 클래스로더의 자유도를 기반으로 모듈화를 저해하는 일들을 많이 하는 일들을 많이 해왔다. 특히 프레임웍들은 그러한 형태를 권장해왔다. 모듈에 대한 제어가 없고 이를 통해 더 많은 기능을 제공할 수 있으니까. 자바 9 이후부터는 이러한 모듈화를 저해하는 것들이 많이 줄어들 것 같다. 아니, 새로 작성되는 프로그램들은 자바 9과 쉽게 호환할 수 있도록 자바 코드를 모듈화하여 분리시키는 설계를 항상 선행하여야 할 것 같다. OSGi는 표준 Java API를 기반으로 사용하므로 특별히 JPMS 기준의 타 모듈에 액세스하지 않는 한 잘 동작할 것이다. 현재로서는 JPMS는 같은 모듈의 멀티 버전을 지원하지 않는다. 그리고 동적 업데이트나 동적 unload도 지원하지 않는다. 엔터프라이즈 환경에서 동적 업데이트/unload는 여러 가지 상황에서 필요하다. 이 글에서 언급한 것처럼 IoT만 필요한 것은 아니다. 물론 클라

집단 창의의 기반을 만드는 포용적 리더쉽

이미지
창의성과 포용적 태도 창의성, 무언가 없던 걸 새로 만드는 것과 포용적인 태도가 어떤 관계가 있을까? 창의성의 핵심은 창의적인 문제 해결로 그 과정의 가장 어려운 부분은 엄밀한 사고critical thinking에 있다고 언급한 바 있다. 실제 문제를 해결하는 아이디어를 어떻게 구할 것인가에 대해서는 여러 가지 방법이 제시되고 있지만 개인별로 아하 현상 을 어떻게 체험할 것인지는 개인별 발견이 중요할 수 있다고 생각한다. 여기에는 집요한 반복된 생각이 중요할 수 있고, 엄밀한 사고가 중요할 수도 있고, 몰입이 중요할 수도 있고, 혼자가 아닌 토론과 대화가 중요할 수도 있고, 또 깊은 사고 후의 뇌가 회복하는 멍한 순간이 중요할 수도 있다. 아마도 이 모든 것이 다 문제를 창의적으로 푸는 과정에 관여할 것이다. 일례를 들어 끙끙 앓던 문제를 대화를 통해 공유하면서 스스로 문제를 해결하는 경우도 종종 발생한다. 대화 자체를 통해 답을 얻었다기보다는 대화를 하면서 자신의 머리 속에 있던 생각을 외부로 전달하는 과정에서 답을 얻는 경험이다. 일화를 들자면 다음은 아인슈타인이 특수 상대성 이론의 아이디어를 얻은 계기이다. 친구인 미셸 베소에게 안 풀리는 문제를 토론하러 갔다가 갑자기 통찰을 얻었다. "이렇게 대화를 시작했다. '요즘 어려운 문제를 풀고 있는데, 오늘 자네와 이 문제를 두고 전투를 벌리려고 왔네. '  우리는 이 문제의 모든 측면들을 토론했다. 그런데 갑자기 이 문제의 해법이 어디에 있는지 이해하게 되었다. 다음 날 다시 친구에게 와서 인사도 하지 않고 말했다. '고맙네. 문제를 완전히 풀어버렸어.'"  그렇다면 왜 포용적인 태도를 얘기하려는 걸까. 포용적인 태도는 문제 해결에 있어서 다양한 문제를 인지하고 또 다양한 측면들을 받아들일 수 있는 입력의 문제를 다룬다. 문제 해결 과정을 입력과 출력을 가진 블랙박스로 본다면 포용적 태도는 입력을 충분히 주기 위한 선결 조건이라고 볼 수 있다.