자바의 아버지 고슬링「자바는 계속 진화중」

ZDNet기사입니다.
Java에 대해서 요즘 관심이 부쩍 늘었습니다.
자바가 OS를 가리지 않고, 컴퓨터뿐만 아니라 가전제품등에 쓰이니 정말 배우고 싶네요.

자바의 아버지 고슬링 「자바는 계속 진화중」
[Stephen Shankland(ZDNet Korea) 01/07/2005


10년 전, 썬은 자신에게 미래 지향적이라는 명성을 얻게 해줌과 동시에 컴퓨터 업계 곳곳에 뿌리를 내린 소프트웨어인 ‘자바’를 세상에 처음 내놓았다. 제임스 고슬링이 바로 자바를 탄생시킨 장본인이다.

고슬링은 1990년대 초 자바를 구상한 후 코드명 ‘그린(Green)’ 프로젝트를 출범시켰다. 이 프로젝트가 향후 자바가 됐다. 자바의 기본적인 아이디어는 모든 컴퓨터가 커스터마이징을 거치지 않고도 다양한 컴퓨팅 기기에서 운영될 수 있도록 하자는 데서 출발했다. 예를 들면 자바 가상 머신을 장착한 휴대폰용 게임을 다른 컴퓨터에서도 운영할 수 있도록 하자는 것이다.

그러나 자바가 지난 10년간 순탄대로만을 걸어온 것은 아니다. 이 프로젝트의 초기 멤버인 MS가 약간 다른 형식의 자바 윈도우 버전을 개발하면서 7년 동안이나 법정 공방에 시달리기도 했다. 자바 프로그램의 보편성이 윈도우에 악영향을 미칠 것이라는 점을 MS가 깨닫고 입장을 바꿨기 때문이다. 이로 인해 자바는 다기능 장비, PC, 서버 등에 적합한 다른 기능 개발에 주안점을 둘 수밖에 없었다.

썬은 자바 제어권을 다른 업체들과 잘 공유할 수 있는 방법을 찾기 위해 상당한 노력을 기울였다. 그리고 이제는 IBM을 비롯해 많은 기업들이 자바의 핵심 컴포넌트를 오픈소스로 공개해 달라고 썬에 요청하고 있다.

숱한 어려움에도 불구하고 자바는 이제 컴퓨팅 분야에서 확고한 입지를 굳혔다. 썬 회장 스콧 맥닐리가 과장된 표현을 종종 사용하기는 하지만 지난 28일 자바원(JavaOne)에서의 발표는 그리 과장된 것만이 아니었다.

맥닐리는 “7, 8, 9년 전 자바원에 대한 기조 연설을 들었다면 아마 당황스러웠을 것이다. 당시 썬의 공언은 단순히 과장된 것만이 아니었다. 또 자바가 어떤 방식으로 변화할지에 대해서도 전혀 예측하지 못했었다”라고 밝혔다.

이번 주에 열리고 있는 자바원 행사장에서 고슬링은 길게 드리운 백발에 청바지, 티셔츠, 버켄스탁 샌들 등 스포티 컨셉을 고수한 차림으로 나타났다. “나이든 히피 같아요.” 올해 50세가 된 자바 창시자의 다소 상기된 모습이 담긴 비디오 화면 속의 딸의 멘트다.

CNET News.com에서는 고슬링을 만나 자바에 관한 이야기를 나누는 시간을 가졌다.

자바를 처음 설계할 때에도 지금과 같은 모습을 구상했나?
그린 프로젝트 시절에는 아주 먼 미래에 대해 상당히 많은 얘기를 나눈 바 있다. 당시에 자바 시나리오를 담은 소책자를 만들었는데 자바 설계의 상당 부분이 이 시나리오에 포함돼 있던 것들이다.

나에게는 자바가 SF보다 더 흥분되는 것이다. 세상이 어떤 방향으로 움직일지는 아무도 예측하지 못한다. 사람들은 대부분 바람이 부는 방향을 보고 앞을 예측한다. 기술에 대한 예측도 마찬가지다.

그러나 단지 추측만 하는 것과 어떤 일이 실제로 일어날 것이라고 확신하는 것은 전혀 다른 얘기다.

나는 무어의 법칙이 본 궤도에 올랐다고 확신하고 있었다. 그리고 각각의 점들을 네트워킹으로 연결하는 것은 상당히 쉬운 일이었다.

다양한 기술이 결국에는 이 방향으로 갈 것이라고 분명히 확신하고 있었다는 것이다. 여기에 더해 보안, 신뢰성, 이식성 등에 관한 이슈도 이미 문제로 대두되고 있었다. 이러한 문제에 해답을 주는 개발 작업에 실제로 참여하게 된 것은 사실 놀랄만한 일이다.

하지만 초기의 그린 프로젝트는 가전제품을 겨냥해서 시작된 것 아닌가?
처음 그린 프로젝트를 시작했을 때 여러 분야의 다양한 사람들과 대화를 나누는 데 상당한 시간을 할애했다. 그리고 나서 가전 분야, 휴대폰, 임베디드 제어 시스템 등 여러 분야에서 모두 유사한 상황이 벌어지고 있다는 것을 알게 됐다.

심지어는 엘리베이터, 기관차, 조명 제어 시스템, 그리고 자동차 부품을 제조하는 사람들과도 이야기를 나눴으며 VCR, TV 개발자들의 의견도 들었다.

그린 프로젝트는 첫 단계부터 프로토타입을 만들기로 결정했다. 따라서 엄청나게 집중해야 했다. 가전 분야를 선택한 것은 단지 다른 분야보다 더 흥미롭다는 점 때문이었다.

그러자 여러 사람들이 관심을 보이기 시작했다. 그러자 우리는 스스로에게 다시 묻게 됐다. 이 프로젝트에 자생력을 불어넣을 수 있는 방법은 없을까??

그때 마침 타임워너가 자사의 모든 서비스를 네트워크로 구성한다는 제안요청서를 들고 왔다. 홈네트워크, 네트워크상의 음성·비디오, 양방향 콘텐츠 등등... 그야말로 환상적인 제안이었다. 눈이 번쩍 뜨였다. “그래! 바로 이거야. 우리가 찾던 거야. 우리가 개발하려는 바로 그거라구!” 그래서 바로 작업에 착수했다.

양방향 TV의 초기 모습이었나?
그렇다. 정말 꿈같은 제안이었다. 많은 사람들이 “우리도 그걸 해야 하는데”라고 말했다.

그러나 타임워너 프로젝트는 여러 가지 복잡한 이유 때문에 이상한 방향으로 흘러갔으며, 우리는 입찰에서 떨어졌다. 그 후에 입찰에서 SGI에 패한 것이 오히려 잘됐다고 생각했다. SGI는 이 프로젝트를 완수하려고 상상할 수 없을 정도의 거액을 쏟아부었기 때문에 결국 자금 압박에 직면하고 말았다.

당시에 자바가 이처럼 협소한 범위에서만 이용될 것으로 생각했나, 아니면 컴퓨팅 산업 전반으로 확산될 수도 있다고 생각했나?
자바를 업계 전반으로 확산시킨다는 계획은 없었다. 그러나 실제로 각 분야의 얘기를 듣고 나서는 모든 분야에서 이와 유사한 작업이 초보적인 수준에서 진행되고 있다는 것을 알게 됐다. 모든 분야에서 디지털 컨트롤러를 갖춘 시스템을 개발하고 있었다는 얘기다.

그러나 가장 큰 문제는 시스템간의 비호환성이었다. 모든 것을 통합해야 한다는 점을 피부로 느끼려면 이 문제를 세심하게 살펴봐야 한다. 이른바 자동차 파괴 경기장에서 멀찌감치 떨어진 외부에 서 있다면 모든 자동차들이 무대 중앙으로 돌진한다는 사실을 금새 알아챌 수 있을 것이다.

당신의 지적에 따라 자바는 상호운영성 문제를 몇몇 해결했다. 그러나 MS는 닷넷을 들고 나오면서 자체 전략을 선택했다. 닷넷은 더 높은 수준의 상호운영성 문제를 야기하고 있다. 닷넷과 자바를 하나의 기술로 통합할 수 있는 방법은 없나?
어떤 측면에서 보면 그 부분이 바로 웹서비스가 하는 일이다. 가교 역할을 하는 것이다. 하지만 양자가 결합을 원치 않는다면 어느 누구도 결합시킬 수 없다.

MS는 차별화라는 분명한 정책을 갖고 있다. 다른 업체와 다르게 보이고 싶은 것이다. 실제로도 MS는 상당히 꼿꼿한 편으로 6개월에서 1년 정도는 자바 커뮤니티의 열성 회원이었지만 나중에 이 생각이 잘못됐다고 판단하고 뛰쳐나갔다.

그때가 1995년이었나? 1996년이었나?
아마 1996년이었던 것 같다. 공동으로 작업한다는 것은 공동 작업을 좋아해야 가능하다. 그러나 MS에게는 공동 작업이 길고 긴 교육과정에 불과했다. 그리 좋아하는 것 같지는 않았으며, 아마 가까워지려고 했던 것 같다.

우리는 MS와 엄청나게 많은 일을 했지만 약간의 거리감이 존재했다. 인터페이스, 웹서비스, 상호운용성 등을 공동으로 추진하려고 노력했다.

C# 언어로 닷넷용 프로그램을 자바 가상 머신에 추가할 수 있나?
가능하긴 하다. 그러나 아주 중요하면서도 유일한 문제는 닷넷이 자주 사용하는 부분인 불안전 모드의 존재이다. 내가 중시하는 원칙 중 하나는 불안전 모드는 없어져야 한다는 것이다.

불안전이란 무슨 의미인가?
닷넷에는 관리되는 코드와 관리되지 않는 코드 개념이 존재한다. 관리되는 코드는 보안과 신뢰성에 관해 언급할 수 있지만 관리되지 않는 코드는 그 어떤 것에도 의존할 수가 없다.

메모리 훼손은 올바르게 조작했는지 만으로는 구별이 안된다. 프로그램이 실제로 어떤 작업을 수행하고 있는지 분석하는 것은 상당히 어렵다.

관리되지 않는 코드 유형인 C 프로그램은 불가사의한 방식을 거쳐 실패하는 경향이 있다. C 언어는 보안 메커니즘이 어떻게 작동하는지에 대해 암시만 주고는 종료돼 버린다. 또한 C에서는 진행 중인 작업이 무엇인지 속일 수 있어야 하지만 자바에서는 진행되는 작업의 성격을 속일 수가 없다.

MS를 자바 커뮤니티 프로세스(JCP)에 끌어들일 수 있는 방법이 있을까?
전혀 모르겠다. 그렉 파파도풀로스(썬 CTO)한테 물어보는 게 나을 거다.

MS와 6개월간 누렸던 허니문 기간으로 다시 돌아가고 싶은 생각은 있나?
MS가 JCP의 다른 커뮤니티와 함께 작업할 수 있게 되기를 진정으로 바란다.

이번에 썬의 자바 애플리케이션 서버를 글래스피시 프로젝트를 통해 오픈소스 소프트웨어로 발표했는데. 자바 스탠다드 에디션을 오픈소스에 적용할 수 있는 가능성도 존재하나?
그럴 수도 있다. 우리가 자바 스탠다드 에디션을 추진하는 방법은 상당 부분이 오픈소스 프로젝트와 매우 유사하다. 주요 분할 라인은 썬이 라이선스를 갖고 있고, 테스팅 요구사항도 있다.

자바가 실제로 자주 사용되는 곳에서 조사를 해봤는데, 전체 테스팅이 상당히 중요한 이슈로 부각됐다. 오픈소스 커뮤니티에는 한편으로는 “좋다”라고 하면서도 테스트를 진행하려고 하면 동의하기는 싫다는 사람들이 꽤 많다.

언젠가는 자바 스탠다드 에디션을 오픈소스로 발표할 수 있을 것이다. 그 시기가 언제일지는 커뮤니티가 얼마나 편안하게 받아들이느냐에 달려 있다. 우리를 정말 화나게 하는 부정적인 사례들은 상당히 많다.

자바스크립트에 대해 사람들이 경험한 것을 한 번 들여다봐라. 자바스크립트는 자바와는 연관되지 않은 향상된 웹페이지용 언어다. 상호운영성 문제가 존재하는 자바스크립트의 여러 기능들은 웹페이지 제작자들에게는 악몽이나 다름없다.

이 브라우저에서 자바스크립트를 실행하려면 이렇게 해라, 저 브라우저에서는 저렇게 해라… 자바 세계의 사람들이 자바스크립트 매뉴얼만 믿고 시키는 대로 하다가는 정말 끔찍하단 생각이 들 것이다.

하지만 BEA 시스템즈 같은 회사들은 자사의 자바 애플리케이션 서버에 해당 소프트웨어를 운영하는 경우에만 사용할 수 있는 특별한 기능을 추가할 예정이다. 그렇다면 자바 코드가 결국 이식성이 부족하다는 말 아닌가?
그렇다. 그 부분이 문제다. 하지만 최소한 기존에 해왔던 방식으로 본다면 특별한 기능은 특별한 기능일 뿐이다. 자바는 패키지명을 붙일 때 상당히 편리한 측면이 있다. API를 사용할 때 공개적인 표준 API, 즉 ‘java.패키지명’으로 시작되는 명칭을 분명히 알고 사용해야 한다. 사유 소프트웨어의 경우 ‘com.bea.패키지명’이나 다른 식으로 이름을 붙인다.

이는 개발자들이 분명히 알고 있어야 하는 사항이다. 개발자들은 실제로 이식성에 대해 상당히 신경을 쓴다. com.bea를 작성해야 하는 경우 개발자들은 갈고리가 살갗을 후벼파는 듯한 느낌을 갖는다. 자바스크립트 세계에서 어려운 문제는 개발자가 이 브라우저 혹은 저 브라우저에 대해 특정 기능을 사용하고 있다는 사실을 실제로는 알 수 없다는 점이다.

또한 지금까지 지켜봤을 때 발전해온 방식은 어떤 아이디어를 가진 애플리케이션 서버 업체와 함께 일하는 것이다. 이 경우 대다수 사람들이 이 아이디어가 좋다고 인정하게 되며 때로는 자바 스펙 요청(JSR)으로 전환될 수도 있다. 이 회사의 두 번째나 세 번째 버전은 표준 자바 프레임워크 안에서 만들어지게 된다.

자바를 오픈소스로 발표하고, 브랜딩을 통해 호환성을 제어할 수는 없나? 당신은 자바 명칭의 사용을 허가하기 전에 소프트웨어에 대한 인증을 요구할 수 있지 않나?
그 부분에 대해서도 상당히 많은 논의가 있었다. 썬은 민주적인 조직이며 일부에서는 그같은 아이디어가 좋다는 생각도 하고 있다. 하지만 긍정적인 사람보다 부정적인 사람이 더 많다.

당신은 부정적인 편에 속하나?
대부분의 경우 나는 긍정적인 편에 속한다. 하지만 두 가지 입장을 모두 수용해야 한다.

5년 전과 지금의 자바 작업을 비교한다면?
지난 5년 동안의 작업과 현재 작업의 가장 큰 차이점은 자바가 많은 기간 시스템의 중심부에서 역할하고 있다는 사실이다. 이 때문에 상당히 보수적이기도 하다.

매일 밤 수천억 달러의 금융 거래를 처리하는 대형 은행이라면 작은 버그조차도 엄청난 문제를 일으킬 수 있다. 초기에는 복잡한 문제만 해결하기도 했지만 현재는 어떤 부분에 실제로 영향을 미치는지에 더 신경을 써야 한다. 그동안 수정했던 버그들은 특이한 작업을 하는 누군가에게 모두 문제를 일으켰다. 이 점이 매우 세심한 규율로 자리잡았다.

썬은 그루비 같은 프로젝트를 통해 자바 세계와 스크립팅 언어를 더욱 밀접하게 연계하겠다고 발표했다. 하지만 솔직히 말하면 프로그래밍 언어가 PHP, 펄, 혹은 파이썬 등 스크립팅 언어와 뭐가 다른지 정확히 모르겠다.
맞는 지적이다. 수없이 많은 다양한 언어가 존재한다. 같은 용어라도 사람들마다 다르게 사용하는 경향이 있는 것 같다.

사람들이 스크립팅 언어를 말할 때는 대개 개발자들이 정말 신속하게 무언가를 내놓을 수 있고, 몇 분 내에 데모를 보여줄 수 있는가 하는 것이다. 프로그램이 얼마나 빠르게 동작하는지, 확장성은 좋은지, 얼마나 큰 시스템을 구축할 수 있는지 등은 두 번째 고려사항으로 치부되는 경향이 있다.

자바를 설계할 때는 개발자들이 얼마나 빨리 데모를 보여줄 수 있는지에 대해서는 그다지 신경쓰지 않았다. 오히려 얼마나 신속하게 크고 확장가능한 시스템을 보여줄 수 있는지에 대해 신경썼다. 결국 어려운 결정을 내렸다.

일반적으로는 스크립팅 언어가 실제 프로그래밍 언어보다 설계하기가 훨씬 수월하다.

자바 설계는 자바 가상 머신(JVM)과 자바 언어 두 가지 레벨로 돼 있다. 가장 어려운 부분은 JVM과 그 하위 레벨이다. 자바 가상 머신을 겨냥하는 스크립팅 언어를 만들 수 있다면 두 가지 모두를 충분히 다룰 수 있을 것이다.

당신은 JVM에서 스크립트를 실행하고 있나?
그렇다. 모든 자바 라이브러리가 그루비 안에서 작성된 것들을 이용할 수 있다. 또한 자바 애플리케이션들도 그루비를 이용할 수 있고, 그루비 스크립트릿도 통합할 수 있다. @