Eclipse 3.5 GalileoNetBeans 6.7가 릴리즈를 앞둔 6월의 어느 일요일 오후. 문득, Turbo Pascal을 처음 접했던 때가 떠오른다. 상념은 꼬리에 꼬리를 물고...

RUN과 CALL-151

8비트 애플은 말그대로 "개발자의, 개발자를 위한, 개발자에 의한 PC"였다(PC의 P는 Personal보다는 Programmer가 아니었을까?). 컴퓨터의 전원을 켜면 바로 베이직 인터프리터가 실행되서 BASIC 코드를 작성하고 실행(RUN)할 수 있었고, "CALL -151"이라는 명령을 치면 기계어 모드로 들어가서 어셈블리어/기계어 프로그래밍도 할 수 있었다((유명한 유겸아부지의 블로그 제목이 여기에서 나온거다). 이 때만 해도 IDE는 고사하고 풀스크린 에디터나 디버거의 존재도 몰랐다. 번들되어 나오는 Macro Assembler를 쓰다가, Lisa Assembler의 속도에 환호하고, Merlin Assembler에 감탄하던 그런 시절이었다.


시대를 너무 앞서간 USCD Pascal 그리고 ...

큰형兄의 책꽂이에 꽂힌 책(물론 원서였다-,.-)을 통해 UCSD Pascal을 접하게 되었다. 구질구질한 베이직과 단순무식한 6502 어셈블리에 지루함을 느낄 무렵, 파스칼의 우아함은 너무나도 크게 다가왔다(그 영향일까? 지금도 나는 파스칼이 가장 우아한 언어라는 깨고 싶지 않은 환상을 품고 산다). 문제는 UCSD Pascal로 만든 프로그램을 실행하기 위해서는 UCSD-P System(요즘 자바나 .NET과 비슷하다고 보면 된다)이 필요하다는 건데, 그게... 배보다 배꼽이 (한참) 컸다(스몰톡과 비슷한 딜레마?)

(맨 윗 줄에 나와있는 명령 리스트를 보고 L, E, R, ...등을 치면 해당 명령이 수행된다. 이 화면은 Filer라고 불리우는 UCSD-P 시스템의 파일 관리자 화면이다)

마소(당시에는마이크로소프스社가 아니라 월간 마이크로소프트웨어를 이렇게 줄여서 불렀다)에 소개된 Whitesmith C와 BDS C 등을 힘들게 구해(물론 불법 복제였지만, 지방에 사는 중딩에겐 이것도 쉬운 일이 아니었다) 이것 저것 삽질을 했었는데, 컴파일하고 링킹하는데만 몇시간씩 걸리곤 했다(그 영향일까? 지금도 나는 C가 조잡한 언어라는 말도 안되는 선입견을 갖고 있다).

(시간적인 순서가 오락가락하긴 하는데)마소의 특집 기사로 소개된 ASBEC(Apple Structured Basic Environment and Compiler?)이라는 프로그램이 아직도 기억에 남는다. 구조적인 프로그래밍이 가능하도록 구문을 확장한 베이직이었는데, 그것보다 더 쇼킹했던것은 그 개발환경이었다! 풀스크린 에디터와 통합된 컴파일러! 그것도 울나라 사람이 만든!

그리고...

Turbo Pascal의 등장

처음 접한 Turbo Pascal은(3.0이었다고 기억한다) 8비트 애플에 소프트카드(마이크로소프트에서 만든)라는 확장 카드를 꽂고 CP/M이라는 OS로 부팅해야 사용할 수 있는 소프트웨어였다. 지금은 구글을 통해서도 스크린샷도 찾기 어려운데... CP/M의 커맨드 프롬프트에서 TURBO.COM을 실행하면 풀스크린 메뉴를(화면 가득 메뉴를 표시하면 각 메뉴 앞에 표시된 선택 키를 직접 눌러 메뉴를 선택하는 방식. 예를 들어 E.Edit 라고 되어 있으면 E 키를 누르면 편집이 되는 식이다) 통해서 소스를 편집하고, 컴파일하고, 실행할 수 있었다.

E키를 눌러 편집기로 들어가서 Ctrl+E,Ctrl+S,Ctrl+D,Ctrl+X 를 화살표키 대신 사용하고(8비트 애플에는 화살표키가 없었다), Ctrl+K,B, Ctrl+K,K로 블럭을 지정하는... 편집이 끝나면 Ctrl+K,D로 다시 풀스크린 메뉴로 나와서 C키를 눌러 컴파일하고, R키를 눌러 실행한다. 아직까지 풀스크린 디버거는 나오기 전이었지만, 이것만으로도 충분히(!) 감동적이었다.

IDE는 익히 알려진 것처럼 Integrated Development Environment, 우리말로 직역하면 통합된 개발 환경이다. IDE는 기본적으로:
  • 편집기
  • 컴파일러 / 인터프리터
  • 디버거
를 하나의 틀 안에 포함하고 있는 통합 소프트웨어다. 그런 면에서 보면 UCSD Pascal이 내가 접한 최초의 IDE였지만, 워낙 특이한 시스템이니 논외로 치면, Turbo Pascal은 실제로 내가 사용한 최초의 IDE가 아닐까 싶다.

Borland와 "Turbo"의 전성 시대

IBM-PC가 등장하고 (지금의 것과 거의 유사한)풀 다운 메뉴를 갖춘 Turbo Pascal도 4.0이 등장했다(Turbo Pascal 4.0으로 4.0의 그것과 똑같은 풀다운 메뉴와 팝업 윈도를 구현하기 위해 삽질하던 기억은 지금도 생생하다.) Turbo Pascal은 그 후 디버거와 프로파일러를 포함한 5.0, Object Pascal을 지원하기 시작한 5.5를 거쳐 Delphi와 Borland Pascal로 이어진다.


(Pull Down Menu, Overlapped Popup Window, Split Window 등의 혁신적인 UI를 선보인 Turbo Pascal 4.0)

Borland는 기세를 몰아 Turbo C, Turbo Assembler, 그리고 Turbo C++까지 내놓으면서 80년 후반에서 90년대 초반에 걸쳐 IDE 시장을 석권했다. GW-BASIC, Macro Assembler, Microsoft C 같은 전통적인 개발 툴로 나름대로 선전하던 Microsoft도 Quick Basic(요즘도 윈도에 기본으로 포함되어 나오는 QBASIC이 이 녀석의 후손이다), Quick C 등의 IDE 제품을 내놓았지만 Borland의 아성을 무너뜨리기엔 역부족이었다.

(Turbo 시리즈의 친숙한 블루 스크린)
그러나...

Microsoft와 "Visual"의 전성 시대

윈도 3.0의 등장과 함께 순식간에 상황이 역전되었다. Borland가 도스와 윈도 사이에서 갈등하는 사이(Turbo시리즈는 DOS용, Borland 시리즈는 윈도용), 공전의 히트작인 Visual Basic과 Visual C++이 등장했다. Borland도 뒤늦게 Delphi로 반격을 시도했지만 이미 전세는 기울어진 뒤였다. Visual Basic이 Quick Basic의 제대로된 Windows 버전이었던 반면, 볼랜드의 (Delphi를 제외한) 윈도용 제품들은 어색하기만 했다.

Turbo C 2.0과 Turbo C++ 1.0을 쓰다가 군대갔다 와서... 그나마 익숙한 Borland C++로 어색한 윈도 프로그래밍을 해보겠다고 친구들과 삽질하던 시절. 학교 연구실에서 복사해온 Visual C++을 깔고 처음 내뱉은 말...
"도대체 어디가 비주얼 하다는 거야?"

이후로도 한참 동안 두 회사의 치열한 공방전이 계속되었지만 Microsoft의 "홈그라운드"인 Windows에서 벌어지는 전쟁에서 Borland가 이길 가능성은 희박했다. Windows의 새 버전이 나올때 마다, 그리고 DirectX의 새 버전이 나올때 마다, Borland는 점점 힘을 잃어갔고, Visual Studio는 아주 조금씩 Visual 해져갔다.

(오랫동안 내 밥줄이었던 Microsoft의 역작(!) Visual Studio 6.0)

문득, 오라클의 Power Object인가 하는 툴(기억이 가물가물)을 보면서 그 비주얼함에 감동먹었던 기억이 난다. 한편, 당대 최고의 밥줄이던 Power Builder의 그 Non-비주얼함에 감사했던 기억도 새록새록... 비주얼했다면 Power Builder가 자랑하는 CPM 방법론(Copy-and-Paste-and-Modify)가 쉽지 않았을 테니...-O-

어느새, 아무도 IDE라는 말을 쓰지 않게 되었다. 특별한 수식어가 붙지 않는 모든 개발툴은 당연히 IDE이며, IDE가 아닌 개발툴은 SDK라는 표현을 쓰기 시작했다.

IDE의 귀환 - "Eclipse"의 전성 시대

Microsoft가 자아도취에 빠져 주춤한 사이에 슬며시(그러나 강력한 임팩트와 함께) 등장한 Java가 주류 언어로 급부상하면서 Java를 위한 IDE들이 앞다투어 등장했다. 그러나 Borland의 JBuilder, Symantec의 Visual Cafe, 그리고 Microsoft의 Visual J++ 등의 1세대 Java IDE들은 기존 IDE를 답습한 에디터/컴파일러/디버거 그리고 GUI Designer를 하나로 뭉쳐놓았을 뿐, 자바와 같은 동적인 언어(물론 자바보다 훨씬 더 다이나믹한 언어가 많다는 건 알지만... C/C++에 비해 상대적으로)의 특성을 툴에 녹여내지 못했다. IBM의 VisualAge for Java와 Sun의 NetBeans는 너무나 앞서간 개념들로 버림 받았다(...고 생각했었다).

자바 개발자들이 EditPlus와 Ant 스크립트를 이용해서 모든 것을 해결하는데 익숙해질 무렵... Eclipse가 혜성처럼(어쩌면 시나브로) 등장했다. 갑자기 등장한 것 처럼 보이지만 Eclipse는 오래 전에 SmallTalk으로 개발했던 VIsualAge 시리즈를 자바로 재작성한 것이다. 10년 전의 설계가 이제서야 사람들에게 인정받기 시작한 것일까? 아니면 하드웨어가 자바로 만든 개발 툴을 수용할 수 있을 정도로 강력해진 덕분일까? Eclipse는 그 이름처럼 Java를 넘어 (거의) 모든 IDE 들을 삼키기 시작했다. 시장의 요구에 맞춰 무리하게 (어설픈) IDE를 만들 수 밖에 없던 플랫폼 SDK 벤더들, 그리고 아무 벤더도 자신들의 언어를 위한 IDE를 만들어주지 않는 군소 언어 사용자은 Eclipse에게 기대는 편이 훨씬 편한 길이었다.

(이클립스는 운영체제 고유의 네이티브 L&F를 제공하는 SWT 덕분에 더욱 각광받았다)

Eclipse가 무소불위의 전성시대를 구가할 무렵, NetBeans는 아무런 관심도 받지 못한채Forte for Java, Sun Creator Studio 따위의 어처구니없는 이름을 거쳐, Matisse 다시 NetBeans로 돌아왔다. 그리고 점점 비대해지는(그리고 점점 더 먼 우주로 날아가고 있는) Eclipse의 빈틈을 파고들며 외로운 추격전을 벌이고 있었다. Sun이 Oracle로 인수되면서 NetBeans가 희생양이 될것인지... (JBuilder가 그랬던 것처럼) Oracle JDeveloper라는 이름으로 살아남을 것인지는... 조금 두고보면 알 수 있을 듯...

(NetBeans는 Swing의 어설픈 GUI때문에 버림받았지만, 아이러니하게도 Swing GUI 편집기인 Mitisse 덕분에 재조명 받게 되었다)

...

Eclipse 3.5 RC 설치하고 간단히 리뷰를 남기려고 왔다가 옆길로 (너무 멀리) 샜다. -,.-;;;;;

덧. 이 글은 어디까지나 주관적인 경험과 취향에 근거하여 작성한 것으므로, 정치적인 태클(예를 들어 emacs 얘기가 왜 없냐~든가)은 정중히 사절하는 바입니다.


Road to Web3.0

hacking/web 2009/06/08 21:28
제목은 거창한데... 내용이 없다. -,.-;;;;
그도 그럴것이... 뜬구름 중의 뜬구름 Web3.0 얘기 아닌가.

사내용으로 만든 자료라 좀 부실하긴 하지만,
웹의 탄생이전 부터 이어져오는 흐름을 정리한다는데 의미를 두고 보면 의외로 볼만할지도...*^^*

현재까지 Web3.0에 대한 논의는 시맨틱 웹, 플랫폼으로써의 웹, 그리고 유비쿼터스 세상으로의 관문으로서의 웹, 세가지 흐름으로 볼 수 있다. 물론 세가지 논의가 서로 간에 밀접한 관련이 있어서 무 자르듯 자를 수는 없겠지만...

IMHO, 시맨틱 웹은 내가 이 바닥에서 먹고 살 동안은 "The Dream of Web"으로 남을 것 같다. 유비쿼터스 웹는 돈독이 오른 가전 업체들의 말장난 단계를 벗어나려면 좀 더 시간이 필요할 듯... 가장 현실적인 것은 (구글이 밀고 있는) 어플리케이션 플랫폼으로서의 웹인 것 같은데, 이건 웹3.0이기보다는 웹2.5 정도가 적당할 듯.


Web2.0도 이제 조금씩 정리되어가는데.. 벌써 Web3.0이라니... 마지막 페이지에선 Web4.0도 나온다-,.-;;;


들어가는 글

오늘 삽질은 이클립스PyDev를 사용해서 이클립스에서 AppEngine(Python)어플리케이션을 개발할 수 있는 환경을 꾸미는 거다. AppEngine이 나오자 마자 guestbook 예제만 따라해보고 잊어버렸는데, 뭔가 해보긴 해봐야겠는데 지난 번 AppEngine for Java 삽질을 해보니 당분간은 파이썬 버전이 현실적인 듯 해서...^^;

리눅스에서는 사실 이클립스 같은 거 있어봐야 걸리적 거리기만 하고, OSX이라면 허접하긴 해도 구글에서 제공하는 간단한 툴이 있어서 나름대로 유용하게 쓸 수 있다. 윈도에선... 그야말로... Orz 나로 말할 것 같으면, 최근 몇년 동안 소스 코드 편집에 vi와 이클립스 외엔 써본적도 없다.

준비 - 이클립스 + PyDev

이클립스PyDev 플러그인은 재주껏 설치하시라. 파이썬을 잘 알아도 이클립스는 모르겠다는 분은 trigger님의 블로그를 참조하시면 되겠다. 파이썬이 뭔지도 모르겠다는 분은 Dive Into Python을(현재 한글 번역본은 빌드를 잘못해서... 깨져서 보이는데 어차피 옛날 버전이니 영문판 보는게 나을 듯) 참조하시길...

PyDev 프로젝트 생성

아무튼, File -> New -> Project 에서 PyDev Project를 선택하여 새로운 PyDev 프로젝트를 만들어 보자:

그 다음 화면에서 Project name(여기서는 iolo)을 입력하고, Grammer Version2.5로(AppEngine 1.2.2 기준) 맞춰주자. 그 밑에 보면 소스를 src 폴더에 만들겠다는 체크박스가 있는데(기본으로 선택되어 있다) 니맘대로 하면된다. 프로젝트 이름은 꼭 AppEngine 어플리케이션 이름(****.appspot.com)과 같을 필요는 없다. 정확한 이름은 app.yaml에 적어주면 된다. 

그 다음 화면은 참조할 모듈(이클립스 프로젝트)를 지정하는 건데, 그 모듈을 디버깅하는게 목적이 아니라면 필요없으니, 무시하고 넘어가자. 어차피 PYTHONPATH로 지정해주면 되니까 다음(Next)를 눌러 구경하던가, 그냥 마침(FInish)를 누르자.

PyDev 프로젝트 설정 
본격적인 코딩에 들어가기에 앞서, 프로젝트의 PYTHONPATH에 AppEngine 전용 라이브러리들을 추가해주자. 화면 왼쪽(Pydev Package Explorer)에서 프로젝트를 선택하고(이거 안해주면 이클립스가 삽질한다. 이후에도 프로젝트에 대해서 뭔가하려면 항상 프로젝트를 먼저 선택해주는 걸 잊지말자. 이게 귀찮으면 그냥 프로젝트의 컨텍스트 메뉴를 쓰는게 제일 확실하다), Project -> Properties (혹은 프로젝트 컨텍스트 메뉴에서 Properties)를 선택하면 프로젝트 Properties 대화상자가 열린다. 대화상자의 왼쪽에서 PyDev - PYTHONPATH를 클릭하면 아래 그림같은 화면이 나온다:

오른쪽의 External Source Folders 옆에 있는 Add source folder 버튼을 눌러가면서 아래의 폴더들을 추가하자(단, D:\devel\google_appengine은 본인이 AppEngine SDK(Python)를 설치한 디렉토리다):
  • D:\devel\google_appengine\
  • D:\devel\google_appengine\lib\django
  • D:\devel\google_appengine\lib\webob
  • D:\devel\google_appengine\lib\yaml\lib
실행 설정(Run Configuration)

이제부턴 구글에서 제공하는 튜토리얼을 따라서 app.yaml도 만들고, 필요한 helloworld.py파이썬 소스도 만들고... 이것 저것 해보자. 흠 여기까진 별 문제 없는데, 문제는 이걸 실행하는 거다. 물론 튜토리얼에서 설명하는대로 커맨드 프롬프트를 열어서(윈도 시작 메뉴 -> 실행(비스타라면 그냥 검색창에) -> cmd) dev_appserver.py를 실행해도 되겠지만, 그래도 명색이 IDE니까... IDE스럽게...^^

Run -> Run Configuration 메뉴(또는 Run  툴바()의 드롭다운 메뉴에서)를 선택하면 Run Configurations 대화상자가 열린다. 대화상자의 왼쪽에서 Python Run을 클릭하고, 다시 대화상자 위쪽에 있는 작은 New 툴바(또는 Python Run에서 오른쪽 버튼을 클릭하고 팝업 메뉴에서 New 메뉴)를 클릭하자(혹은 Run -> Run As -> Python Run을 해도 된다).

대화상자 오른쪽을 보면 여러개의 탭들이 장황하게 늘어서 있는데, 맨 앞의 Main 탭에서 Main Module 아래에 dev_appserver.py의 위치를 입력(!)해주자. 옆에 있는 Browse는 해봐야 소용없다. 내 경우엔 D:\devel\google_appengine\dev_appserver.py 인데, 알아서 맞게 입력하면 되겠다:

계속해서, 그 옆에 Arguments 탭에서 Program arguments 아래에 소스 디렉토리를 입력하자. 내 경우엔 "${project_loc}\src" 인데, 프로젝트 생성할 때 src 폴더를 만든다는 체크박스를 껐던가 나름대로의 디렉토리 구조를 잡아놓았다면 알아서 맞게 입력하면 되겠다. 여기에 dev_appserver.py가 제공하는 여러가지 옵션을 지정할 수 있는데, 많이 쓰이는 것은 --port 옵션이다(기본값은 8080):

이제 Run을 누르면 실행된다. 다음부터는 그냥 Run -> Run 메뉴(또는 Run 툴바)를 선택하면 마지막으로 실행한 녀석을 다시 실행한다. 중간에 다른 뭔가를 실행했다면 Run -> Run History Run 툴바의 드롭 다운 메뉴를 열어서 지금 설정한 녀석을 고르면 된다(위의 스크린샷대로라면 기본값인 New_configuration인데 하다보면 바꾸게 될거다).

실행 및 디버깅

dev_appserver.py의 출력 메시지는 이클립스 창 아래에 있는 Console 탭에 표시된다. 종료하려면 그 탭 위쪽에 있는 빨깐 네모()를 눌러주면 되겠다(이런거 까지 얘기할 필요가...).

여기까지면 일단 명령 프롬프트 열어서 할 수 있는 건 다 할 수 있고, 보너스로 디버깅)까지 할 수 있다. 디버깅을 하고 싶으면 Run 툴바()대신 바로 왼쪽에 있는 초록색 딱정벌레(캡쳐하기 귀찮다-,.-)를 눌러주면 된다. 자세한 사용법은 PyDev 홈페이지에서 제공하는 문서를 참조하자.

나가는 글

별 내용은 없지만 -,.- 딱히 일도 손에 안잡히고... 심심하기도 하고... 혹시나 도움이 될까해서 써 봤다. 근데 파이썬으로 코딩같은 코딩을 해본지가 거의 4~5년이 지나니 뭘 해야할지 완전 막막하다 -,.- 아무튼 어여어여~ 맘잡고 좀 더 보람있는 일로 저녁시간을 써야...


난 천성이 보수적인 인간이다. 인터넷에서 조문을 하는... 아고라에서 애도 서명을 하는... 혹은 블로그 제목이나 메신저 닉네임에 까만 리본(▶◀)을 다는 행위에 대해서도 (반대까지는 하지 않지만) 그다지 공감하지 않는다.

그제, 어제, 그리고 오늘도 저녁 내내 멍하니 앉아서 인터넷을 뒤적거리며...
혼자 분해하고, 혼자 눈물을 글썽이고, 혼자 부끄러워하고...
그러다가... 먹을 걸로 아기를 놀리는 철없는 시골 촌부의 사진 네 장을 보게 됐다.

가슴이 메마른... 혹은 눈물이 부끄러운 이들을 위해서...
그리고, 금새 사그러들 지금의 분노와 슬픔과 부끄러움을 기억하기 위해서...


움짤로 만들면 좋겠다.

저 사진 속의 철없는 시골 촌부가 살아만 계신다면... 말이다.


오늘은 오랜 만에 개발 관련 포스팅을 가장한 투덜투덜.
뭔가 기술적인 내용을 기대했다면... 낚인거다.

구글 앱엔진이 자바를 지원하게 됐다는 소식은 꽤 오래된 얘기. 그동안 여유가 없어 못본척 넘어가다가, 지난 주에 짬을 내서 삽질을 좀 했다.

일단, 헬로월드... 훗~ 잘되네~ 속도도 짱 빠르고, 이클립스 플러그인도 있으니 금상첨화~ 오오~ 이거! 날로 먹는 톰캣 호스팅 서비슨가? ^O^ 그러나, 섣부른 판단은 금물. 고수일 수록 칼은 조심스럽게 고르는 법... 흠흠... 좀 더 그럴싸한 걸 만들어 보자. 뭘 만들까... 고민하다가 예전에 만들다 말았던 녀석을 옮겨 보기로 했다. (기대 만땅)

제대로 할려면 맥가이버칼(메이븐)이 필요한데... 흠흠... 구글 이클립스 플러그인이 만들어주는 프로젝트의 디렉토리 레이아웃을 보니... 대략 난감. 나중에 좀 더 찾아보기로 하고, 패스 ~.~ 구글링 좀 해보면 알겠지만 나름대로 어수룩한 해법이 있긴 하다. (쉽게 포기)

ORM은 앱엔진에서 제공하는 (JDO 비스므리한) 녀석을 쓰면 되고... 일단, 스프링부터 추가하자. 그러나 1분도 안되 터져나오는 괴성~ 이 뭥미! 스타트업도 안되네. -,.- 거의 무조건 반사로 구글링~ 안되는게 정상이지만, 이러케 저렇게 요로케 조로케~ 조금만(?) 삽질하면 돌아가긴 한다는 군. 하긴... 이런걸 클라우드 위에서 돌리려면 뭔가 제약이 있을 수 밖에 없지... 꽁짜! 톰캣 호스팅 서비슨데... 이정도는 감수해야쥐 ~.~ (미련 둔탱)

그래도, 구글에서 만든 쥬스는 돌아가겠지... 라고 생각하고 후다닥~ 이것 저것 바꿔 봤지만 -.-; 천만의 말씀 만만의 콩떡. 역시 무조건 반사로 구글링 한 결과, 쥬스 최신 스냅샷 버전을 받아서 이러케 저렇게 요로케 조로케~ 조금만(?) 삽질하면 대충 돌아가긴 한다는데... (내가 뭔가 엄한 삽질을 하고 있는게 아닐까...) IoC 컨테이너라는게 첨엔 번거롭고 거추장스럽고 귀찮지만, 있다가 없으면 정말 갑갑한데... 그래도 어쩌랴... 일단 그게 중요한게 아니지! 목표에 집중하자! 집중~ 이렇게 속으로 외치며~ (근거없는... 홧팅!)

jersey를 추가하기로 하고, (메이븐이 없으니 이런 *삽질을...) 여기저기 돌아다니며 관련 jar들을 받아서 추가... 예전에 만들었던 코드에서 DAO만 살짝 바꿔치고 실행하니~ 이건 또 뭥미! ㅠ.ㅠ 다시 구글링... JAXB는 쓸 수 없다는 군 -.-; 뭐 어쩌라는 거냐! (버럭) 뭐 괜찮아... json으로 바꾸면 되지~ (대충 대충)

jettison을 추가하고 다시 이것 저것 뜯어고치기 시작. 흠... JAXB가 안되니 StAX는 당연히 안될꺼고... 그냥 단순무식하게 JSONObject로 만들어서 무식하게 toString()... 이렇게 할꺼면 jersey 쓰는 보람이 없는데... 투덜투덜... 뭔가 더 깔끔한 방법이 있겠지. 내가 GAE/J를 잘 몰라서 그런 걸꺼야~ (구글 만쉐)

오호! 된다 된다!

...

흐뭇한 마음으로 appengine에 프로젝트를 생성하고, 디플로이~~ 했으나... 끝도없이 쏟아지는 경고와 에러들...ㅠ.ㅠ appengine에 만들어진 프로젝트는 삭제도 못하는데... ㅠ.ㅠ "도대체 되는 게 뭔거냐! 그거 먼저 말해줘라!"라고 투덜거리며, 다시 구글링... oTL
구글링할 필요도 없었다. 앱엔진 자바 사이트에 예쁜 이름을 가진 페이지가 하나 있다: JRE Class White List... 이걸 이제서야 보다니... (RTFM)

애초에 블랙리스트 같은 건 없었다. 왜냐 하면 되는 것만 적는게 더 짧으니까... -,.-

물론, maven 없다고, spring 없다고, guice 없다고, jersey 없다고, JAXB 없다고, *없다고... 자바 코딩이 안되는 것도 아니고, 웹 서비스를 못 만드는 것도 아니다. 게다가 구글링 조금만 열심히 하면 나름대로 해결책도 있고, 꼼수도 있고... 그래! 문제는 이거다! 왜 그냥 자바에선 안해도 되는 꼼수를 남발하게 만드는 거냐? 구글 앱엔진에서 돌아가게 만든답시고 엄한 패치를 양산하게 만드는 거냐? (책임 전가)

예전에 마이크로소프트가 Swing 대신 DirectX를 집어 넣고 Visual J++이라는 불세출의 IDE와 함께 배포했던 MSJava를 기억하는가? 나는 그 J++로 수십만줄의 코드를 만들었었다. 그 덕분에 내 자바 실력이 얼마나 늘었는지 모르겠지만, 그 이후로는 MS의 개발자용 제품을 쓰지게 되었다. 지금 구글이 하는 짓을 보고 있노라면 그 때의 MS가 생각난다. (논리 비약)

구글은 이 따위로 만들어놓고 자바를 지원한다고 하면 안된다. 공짠데, 그 정도면 감지덕지라고? 그러니까 자바를 지원한다고 하지 말라고... -,.- 아직 "Early Look"인데 이해하라고... 그러니까 자바를 지원한다고 하지 말라고... -,.- 그랬으면 전세계의 수많은 자바 고수들이 한푼 값어치도 없는 엄한 삽질(내가 jersey에서 json을 뿌리기 위해 한 삽질같은... 값어치 없는... 그런 삽질)하느라고 시간을 낭비하지 않을 꺼 아닌가. (거짓 걸룐)

메일링에서 누가 그러더라. "이걸 Goole AppEngine for Java (GAE/J)라고 부르지말고 Guava라고 부르자"고...여기도 +1 한 표 추가!

이렇게 말하면서도 공짜 톰캣 호스팅(혹은 Django 호스팅)의 유혹을 뿌려치기란 쉽지 않다. 뭔가 낚시에 걸리지 않고(이미 걸렸나?) 떡밥만 쏙~ 빼먹는 방법은 없을까~ 궁리 중... -,.- (무전유죄 유전무죄)