한빛출판네트워크

By 한빛리포터 2기 이아스님 2001년 11월 29일 목요일 우선 쌩아침(9시반)에 벌어진 키노트에서는 일본의 삼대 이동통신사중 최근 가장 두각을 나타내고 있는 J-PHONE(제이-폰)의 총천연색(정확히는 65536칼라) 3D폴리곤이 꿈틀거리는 핸드폰이 가장 주목을 끌었습니다. 내년 초 발매예정인 이 기종은 SD메모리 칩도 읽을 수 있고, MP3와 같은 음악 재생은 물론 자바 기술 측면에서도 2D쪽은 전통의 세가가, 3D쪽은 게임계에서는 신생인 반다이와 합작해만든 만큼 게임 개발에 최적화 되어 있다고 보여지며, 특히 3D기능은 "저것이 핸드폰인가"가 의심스러울 정도로 엄청난 파워를 보여주었습니다. 자바로 만드는 모바일 3D 게임... 용량도 80킬로로 늘어 거의 옛날 MSX시절의 1메가 비트(128킬로 바이트) 급의 게임이 가능하지 않을까 싶을 정도였습니다. 뒤이어 AU(에이유)는 GPS와 동영상을 활용할 수있는 기술을 선보였는데, 특히 GPS기술중 XML기반 스케일러블 벡터 그래픽스(Scalable Vector Graphics) 포멧인 SVG를 자바에서 처리하는 Batik(버틱이라고 미국사람들은 발음하더군요.)과의 연동이 돋보였습니다. (곧 버틱은 1.1을 내놓다고 합니다.) 개인적으로는 내년 일본 자바 모바일 시장의 주축은 시장 점유율로는 엔티티일지 모르지만 실속과 진보성은 제이폰이 이끌고 가지 않을까 싶습니다. 올 한해도 샤메루(사진-메일)라는 독특한 기능으로 에이유를 재치고 당당히 시장 점유율 2위로 올라섰으며 무섭게 엔티티의 사용자층-특히 젊은 감각의 신세대들-을 끌어들이고 있으며, 엄청난 고성능의 단말기가 겨우 2만엔대에 보급되고 있음도(엔티티의 경우 그보다 성능상 처지는데도 3만엔대) 최근 탄탄한 인기의 바탕으로 분석되고 있습니다. 그 뒤에는 유럽 최대 이통사인 보다폰(Vodaphone)이 버티고 있지만요. 특히 이전의 자바 모바일 게임과는 달리 제이폰상에서 돌아가는 게임은 뒤에 세가 세션에서도 나오겠지만 확실히 격이 다릅니다. 2D게임에서는 기본이라고 할 수 있는 스프라이트 기능은 역시 발군이더군요. 자세한 얘기를 여기서 다 해버리면 세가 얘기할 것이 없으니 좀 있다 합시다. 자 그럼 본격 세션으로 들아가보지요. (오전 11시부터) 첫번째 세션은 웹서비스용 리치 클라이언트(rich client) 라는 제목으로 자바 웹 스타트를 집중 소개하였습니다. 발표장에서 보여준 데모는 기존의 HTML기반 달력과 일정 관리를 환상적인 GUI로 탈바꿈시켜 장내의 참석자들을 놀라고 흐믓하게 만들었는데, 데모용 피씨의 사양이 좋아서 그랬는지는 몰라도 매우 부드러운 애니메이션과 특수 효과로 보는 이의 눈을 즐겁게 해주었습니다. 그런데 정작 질문시간에 나온 얘기는 저런 컴포넌트 설계가 미적으로도 기능적으로도 힘들지 않냐는 현실적인 우려였었는데, 물론 디자인이야 전문가한테 의뢰했겠지만, 그것을 바탕으로 각종 효과를 넣어 필요한 컴포넌트를 만드는 데에는 2주밖에(?) 걸리지 않았다고 하니, 결국 안해서 그런거지 못할 것은 없다는 사실을 깨우쳤습니다. 다음 세션은 인상적인 모바일 애플리케이션을 개발하는 방법 이라는 제목으로 세가의 모바일 게임 개발 담당자분이 발표해주셨는데, 우선 세가의 제이폰용 2D 엔진의 의의를 밝힌 후, 세가의 모바일 게임 포탈 정책, 게임 개발의 방향등도 소상히 알려주어 동종 업계 관련자로서 저도 많은 도움이 되었습니다. 세가가 밝히는 현재 모바일 게임 개발 상황은 "핸드폰의 사양이 80년대 제 2세대 게임기과 흡사하다(패미콤 정도). 따라서 그당시의 게임을 리메이크하는 것이 주류."라고 지적하며, 옛날 게임이라서 재미없다는 말은 아니며, 오히려 현재 핸드폰을 가지고 있는 다양한 세대에 고루 어필할 수 있는 검증받은 게임성과 구수한 향수(?), 복고적인 리듬, 간단한 전략등이 어울어져 명작들의 부활이 가시화될 것이라는 얘기입니다. 이는 역으로 아직 네트웍 게임이라던가 대작 RPG의 개발은 그다지 진행하고 있지 않으며, 우선 간단한 게임의 포팅부터 시작해서 핸드폰 단말기상의 개발에 대한 노우하우를 쌓은 후 양질의 킬러 게임을 내놓겠다는 무척 탄탄한 미래 전략으로 다가왔습니다. "게임 개발은 자바 개발과는 다르다"는 말도 상당히 뼈아픈 말이었습니다. 세가는 게임 개발사이고, 게임 개발을 아는 회사입니다. "자바 게임"이라는 말 자체가 뭔가 자바는 앞서고 게임은 쫓아오는 느낌인데, 세가가 말하는 자바 게임이란 단지 게임을 만드는 도구가 자바일 뿐이며, 가장 중요한 것은 게임 그 자체, 따라서 게임을 위해서라면 자바의 어쩌고저쩌고는 다 희생-포기할 수도 있다는 업계의 냉엄한 현실을 숨김없이 보여주기도 했습니다. 자바 개발자에서 게임 개발자로 일하고 있는 저로서는 퍽 많은 것을 시사했던 세션이었습니다. 그 다음 세션은 J2SE의 보안:현재와 앞으로의 전망 이라는 제목으로 자바 2 보안 기술에 대한 조망, 그리고 차후 진행될 방향에 대해서 많은 이야기를 들었습니다. 아시다시피 J2SE 1.4에서는 JSSE, JCE, JAAS등 보안 관련 패키지를 기본 포함하는 보안강화책을 대폭 강행하였습니다. 앞으로 이들과 더불어 GSSI, CertPath 등 멀린에 새로 추가된 보안 관련 패키지로 단단히 무장한 자바 2 플랫폼의 미래를 엿볼 수 있었습니다. 다음 세션은 MacOS X에서의 자바 기술:J2SE에 관련되어 라는 제목으로 애플 컴퓨터 자바 기술 관련자가 발표하였습니다. 가장 관심 있는 것은 역시 MacOS X용 멀린의 진행상황인데, 내년 여름 완전판 공개를 목표로 열심히 작업중이랍니다. 맥오에스는 일반 소비자용 피씨 운영체계로서는 처음 자바 2 플랫폼을 기본 탑재했으며, 이번 10.1에서는 자바 웹 스타트까지 기본 탑재하여 명실상부한 최고의 자바 플라이언트 플랫폼이라고 할 수 있습니다. 여러모로 MS와 대조되지요. (XP는 아예 JVM이 빠졌을 정도인데.) 애플의 입장에서는 애플리케이션 부족을 해결하고 손쉬운 개발을 돕기 위한 시도라고 보여지는데, 일본의 경우 맥 사용자가 많아(적어도 전체 피씨 사용자중 10%는 넘지 않을까...) 많은 활약이 기대됩니다. 그 다음 세션은 톰켓 서블릿 컨테이너 라는 제목으로 톰켓 프로젝트 리더이신 크랙 맥클래너헌(Craig McClanahan)씨가 이번 서블릿 2.3+JSP 1.2를 구현한 톰켓 4의 개요와 앞으로의 톰켓이 갈 방향에 대해 흥미로운 얘기를 많이 해주셨습니다. 일본에서의 톰켓에 대한 관심과 열기는 높아서 그랬는지 비교적 큰 세션장에 거의 사람이 꽉 찼었는데, 이런 질문이 나왔습니다.

"톰켓을 단독으로 띄워서 실제 서비스를 해도 됩니까? (어느정도 규모의 서비스를 하려면) 아파치나 IIS와 반드시 연동해야하는 건가요?"

여기에 대해 그분(?)은

"음... 물론 예전에는 톰켓의 정적 컨텐츠 제공력이 떨어졌던 것이 사실이고, 그것을 보완하려는 의미에서 연동책이 필요했겠죠. 또한 정적 컨텐츠 자체도 많았을 터이고. 하지만 요새 하나의 웹사이트라면 동적 페이지가 대부분(약90%이상) 아닌가요? 그리고 (그정도로 정적 페이지가 적다면) 최근의 톰켓은 충분히 커버할 수 있을 정도로 성능의 향상이 이루어져 있습니다. 따라서 실제 필드 스트레스 테스트가 선행되어야겠지만 별 무리가 없다면 톰켓 단독으로 한다고 해서 (그 이유만으로) 서비스가 불안하다는 말은 옳지 않습니다."

이 이야기가 뜻하는 바는, 우리가 왜 그토록 톰켓-아파치 연동에 목을 매었는가에 대해 다시 생각해보게 하면서, 톰켓의 정적 컨텐츠 제공 기능은 사실상 아파치의 그것과 근본적으로 다르지 않으며, 다만 톰켓이 퓨어 자바라는 점이 아파치의 네이티브 코드라는 점과 차이가 나고, 따라서 톰켓의 정적 서비스 능력은 결론적으로 자바 퍼포먼스와 관련지어지며, 그 부분을 아파치에게 나눠지게 했었지만, (두둥!) 이제는 핫스팟을 비롯해 자바 VM의 성능도 향상되었고, 그간 톰켓 코드 자체의 기능도 일취월장하였고, 더우기 운영(service)이라는 측면에서 톰켓의 운영상의 문제이지 톰켓이기 때문에 그런 문제가 났다고 하는 것은 뭔가 잘못되었던 것이 아닌가... 하는 은유적인 답변이 아닌가 싶더군요. 그래서 제 개인적인 생각은 이렇습니다 정적 페이지가 전체 컨텐츠 구성에서 아주 미미하면 테스트 없이 톰켓을 단독으로해서 서비스해도 되고, 만약 10%이상으로 안미미하다면 어느정도 테스트를 통해 안정성을 확인한 후 별 무리 없으면 역시 톰켓 단독이 편하고 낫다고요. 특히 아파치-톰켓의 연동은 결국 내부 리다이렉션으로 이어지므로 동적 페이지가 중심인 사이트에서는 오히려 낭비(리던던시)가 생기는 것이 아닌가(이부분도 톰켓 리더가 지적한 점)... 그리고 멀린의 향상된 VM과 각종 서버 옵션을 잘 활용한다면 더욱 좋겠지요. 또 멀린의 발전된 I/O(New I/O-니오)로 톰켓을 재구성한다거나 가속화시킨다면 더욱 강력해질 것이고요. 물론 톰켓 개발자이니 톰켓을 두둔한 느낌도 들 수 있겠지만, 내가 보기엔 그의 말에 뼈가 있었습니다. 무작정 아파치... 무작정 J2EE가 아니라, 정말 서비스에 딱 어울리는 간편한 차림... 경제와 실용을 이제는 생각해야하지 않을까... 아파치 톰켓 연동 좋죠... 하지만 그 기술의 난이도가 가져다 주는 유지 보수문제를 비롯한 사이드 이펙트는? 역시 이런 것도 선입견을 가지고 있는 사람들을 설득하는 것이 어려울 수 있겠지만요. 다음 세션은 좀 황당했었는데, 적스터 프로젝트의 기술 개요 라는 제목으로 썬의 P2P(Peer to Peer) 프로젝트를 소개하였습니다. 흥미로웠던 점은 이제 J2ME까지 결합시켜 예제를 구성하고 있었는데요, 나중에 간단하게 따라할 수 있도록 글을 써볼까 생각이 들었습니다. (도통 무슨 소리인지 잘 감이 안오더군요.) BOF에서는요, 첫번째, 멀린과 XML 이라는 주제였는데, 발표하시는 분이 저랑 처지가 똑같더군요. 어떠냐면, 자기는 썬에서 자바 기술을 만드는 사람도 아니고, JCP를 통해 스펙을 주도하거나 참가하는 사람도 아니고, 그저 자바가 좋아서 주변에서(?) 열심히 주어들어 아는 정도라고, 결국 남들도 다 알 수 있는 정도가 자기가 아는 전부라고(즉 썬 내부의 특급 정보나 기타 신비주의적 발상과는 전혀 거리가 먼) 너무 겸손을 떨어 듣는 사람을 어리둥절하게 했습니다. (저는 물론 십분 이해가 갔지만.) 아무튼 이분에 밝히신 멀린의 XML 기술은 사실상 걸음마 단계라는 것이며, 젝스 시리즈중 이번에는 오직 젝스피, 즉 XML 처리 파트만 들어갔다는 것입니다. 젝스 시리즈에는 그밖에도 젝스 비, 젝스 알피씨등이 있는데, 이들은 겨우 시작된 것이어서 내후년 타이거에서나 정식 포함을 가늠할 수 있겠다더군요. (어디까지나 추측) 멀린은 단순이 API적 인터페이스만을 구현한 것이 아니라 실제 XML 처리를 위한 구현체도 포함하고 있는데, 묘하게도 이것들의 조달처가 다름 아닌 아파치 재단입니다. 아파치 XML 프로젝트를 보시면, 여러가지 관련 기술들이 나오는데, 이중 구분석기(parser)은 크림슨(Crimson)을, XSLT는 잘란(Xalan)을 채택하였습니다. 많은 분들이 가장 궁금해하는 것은 왜 파서로 저시스(Xerces)를 채택하지 않았냐는 것인데, 여러가지 편법으로 크림슨을 저시스로 교체하는 방범이 있지만 권장할만하지는 않더군요. (비표준 옵션 사용) 또한 크림슨 자체의 업그레이드도 마찬가지여서, 이러한 시스템의 유연성 결여를 무척 아프게 꼬집었습니다. 아무튼 멀린에 구분석기며 변환기며 다 들어있으니 편한것만은 사실이지요. 앞으로 어떤 구현체를 가지고 갈지는 귀추가 주목됩니다. 마지막 세션은 니오(NIO-new I/O)에서의 자바 국제화에대해 난상 토론이 벌어졌었는데, 일본은 한국보다도 문자 코드 문제가 더 심각하더군요. 우리의 경우 MS의 윈도우즈 덕분에(?) 고맙게도 완성형 코드가 거의 굳어져서 KSC5601 혹은 EUC-KR이 웹 표준으로, 거기에 MS의 확장 완성형과의 호환으로 별 무리없이 한글 처리를 해오고 있는 반면, 일본은 S-JIS와 Shift-JIS(쉬프트 지스)가 다를 정도로 정신 없고, 그 상황에서 DB 시스템의 페이지 코드 셋과의 변환 문제가 무진장(특히 MS SQL) 골치 아파보였습니다. 고로 자바 웹 애플리케이션과 MS SQL DB와의 궁합이 아주 지리멸렬해질 수도 있겠구요. 니오의 탁월한 인코딩-디코딩 능력이 이런 상황을 얼마나 타개해줄지 앞으로가 궁금해집니다. 아! 또 하나, 멀린에서는 유니코드 3.0을 지원하는데, 더 많은 문자셋을 지원하려다 보니 이전 자바 2에서 지원하던 유니코드 2.1과는 또 다른 문자 코드 시스템이 되었더군요. 하위 호환성은 있으므로 기존 프로그램을 뜯어고칠 필요는 없지만, 아무튼 일본어 문자(아마 한자겠지만) 일부도 확장 페이지로 들어가서 다소 접근이 불편해졌다고 푸념하던데, 우리 한글은 과연 유니코드 3.0에서 어떤 식으로 자리잡고 있는지 관심을 가져보아야 겠습니다. (더 풍요롭고 정확한 한글 처리를 자바로 할 수 있게 되기를 빌면서요.) 많은 도움이 되셨나요? 자바의 흐름이 더욱 더 빨라진다는 느낌이 들지만, 이럴 때 일수록 강태공처럼 유유자적 낚시대를 드리우고 싶은 것은 혹시 저만의 맹한 생각일지... 내일도 기대해주세요.

2001년 11월 30일 금요일 예고... 리눅스 자바 포팅팀의 애환-플스2에서 자바2가? 나츠노씨 또만나다-아직도 정신을... 자바 클라이언트 기술 노우하우-쓰레드가 보인다... 공개키 인프라스트럭쳐? 자바 보안 플랫폼-보안은 역시 어려워... 자바에 메모리 관리가 필요하다고?-일단은 하지마... 심비안의 신비한 모바일 게임-전 세션중 처음(이자 마지막) 여성 발표자!