강의 자료를 대충 살펴보면 알겠지만,
뜬구름 같은 트렌드 혹은 패러다임을 "얘기"하고 있어서,
구체적인 기술이 중요한 3일짜리 속성 과정에 적합하지 않은 것 같아 자진 사퇴(?)하고, 발표자료를 공개(?)한다.
내가 발표했던 첫날 3시간은 @ibare님이 좀 더 실무적이고 유익한 내용으로 강의하실 듯~ ^^
아래에, xui.js가 제공하는 모든(!) 함수를 간략하게 설명합니다. 개발자 분들의 이해를 돕기 위해 대응하는 jquery와 dojo의 함수도 같이 소개 했습니다.
기본 함수
extend(object)
프로토타입 상속
[ jquery.extend(), dojo.extend() ]
find(selector, context)
css 셀렉터에 부합하는 노드 선택.
[ jquery.find(), dojo.query() ]
set(array)
명시적으로 노트 선택.
reduce(elements, index)
중복 제거
[ jquery.unique() ]
has(selector)
css 셀렉터에 부합 여부 확인
[ jquery.has(), dojo.query() ]
filter(fn)
노드 필터링(제외).
[ jquery.filter(), dojo.filter() ]
not(selector)
css 셀렉터에 부합하지 않는지 확인.
[ jquery와 dojo의 not() css selector ]
each(fn)
노드 순회
[ jquery.each(), dojo.forEach() ]
DOM 조작 함수
html(location, html)
HTML 컨텐츠 조작.
location: inner,outer,top,bottom,remove,before,after 중의 하나(생략가능; 생략하면 inner). 동일한 이름을 가진 단축함수(inner(html) 등) 사용 가능.
[ jquery.html(), dojo.place() ]
attr(attribute, value):
HTML 속성 조작.
value를 생략하면 get.
[ jquery.attr(), dojo.attr() ]
이벤트 함수
on(type, fn)
이벤트 핸들러 등록.
type: click, load, touchstart, touchmove, touchend, touchcancel, gesturestart, gesturechange, gestureend, orientationchange 등. 동일한 이름을 가진 단축함수(예: click() 등) 사용 가능.
[ jquery.bind(), dojo.connect() ]
un(type, fn)
이벤트 핸들러 등록 해제.
fn을 생략하면 해당 이벤트에 등록된 모든 이벤트 핸들러 등록 해제.
[ jquery.unbind(), dojo.disconnect() ]
fire(type, data)
가상의 이벤트 발생.
data: 이벤트 핸들러로 전달되는 event 객체의 data 속성으로 전달(생략 가능).
[ jquery.trigger() ]
화면 효과 함수
tween(properties, callback)
css 속성 인비트윈(inbetween) 에니메이션.
properties: 에니메이트할 css 속성-값 pairs과 duration, after, easing 등의 추가 속성들 또는 속성들의 배열.
[ jquery.animateProperty(), dojo.animateProperty() 등 ]
CSS 스타일 함수
setStyle(property, value)
css 속성 설정.
[ jquery.css(), dojo.style() ]
getStyle(property, callback)
css (계산된)속성 얻기.
[ jquery.css(), dojo.style() ]
addClass(className)
css 클래스 추가.
[ jquery.addClass(), dojo.addClass() ]
hasClass(className)
css 클래스 확인.
[ 참고: jquery.hasClass(), dojo.hasClass() ]
removeClass(className)
css 클래스 제거.
[ jquery.removeClass(), dojo.removeClass() ]
css(properties)
css 속성 일괄 설정.
[ jquery.css(), dojo.style() ]
XHR(AJAX) 함수
xhr(loation, url, options|fn)
AJAX 요청.
location: 결과(responseText)를 반영할 노드(생략 가능).
options: method, async, data, callback 등의 추가 속성 지정(생략 하거나 callback 함수만 지정 가능).
[ jquery.ajax(), ajax.load(), ajax.get(), ajax.post(), dojo.xhr(), dojo.xhrGet(), dojo.xhrPost() 등 ]
결론
xui.js는 jquery나 dojo 등의 기존 자바스크립트 라이브러리에서 널리 사용되지 않는 기능들과 다양한 데스크탑용 브라우져 지원을 위한 부가적인 코드를 제거하고, 자주 사용되는 함수들과 모바일 환경에서 꼭 필요한 브라우져만 지원하도록 최적화된 자바스크립트 라이브러리 입니다. 장단점을 요약하면 다음과 같습니다:
PROS: 크기, 성능, 구성, 소스 코드 품질
CONS: UI 툴킷 부재. 데스크탑 브라우져 호환성 부재. 문서 / 사용자 커뮤니티 부재.
직접 UI 툴킷을 만들 게 아니라면, 별도의 UI 툴킷을 사용해야 하므로 작은 크기로 인한 장점이 오히려 단점이 됩니다. JQueryMobile을 쓰려면 결국 jQuery가, Sench Touch를 쓰려면 결국 ExtJS가, Dijit(Dojo Widget)을 쓰려면 결국 dojo가 필요하게 되는데, 말 그대로 배보다 배꼽이 더 큰 상황이 됩니다. 또한, 데스크탑 브라우져 호환성이 부족하므로 xui.js는 모바일 웹에만 적용하고, 데스크탑 웹을 위해 별도의 자바스크립트 라이브러리를 사용해야 하므로 2중의 학습/개발이 필요하므로 장점보다는 단점이 커 보입니다.
여러 측면을 고려할 때, 새로운 모바일 웹 UI 툴킷을 자체 개발하거나, 새로운 범용 자바스크립트 라이브러리를 자체 개발한다면 좋은 기반(혹은 참고)가 될 수 있겠지만, 기존의 범용 자바스크립트 라이브러리(jquery, prototype, dojo 등...)의 대체품으로는 부적합 -_-;
지난 포스트에서는 CORS에 대해서 (아직 지원하지 않는 브라우져가 많다고 지레 짐작하고) 용어만 언급하고 넘어갔다.
최근에 올라온 "Methods of communication"이라는 글에 걸린 링크를 통해 지금 당장이라도 쓸 수 있음을 확인하고, 몇 자 적어보려고 한다.
Ajax에는 Same Origin Policy라는 원칙이 있다. 말 그대로, 현재 브라우져에 보여지고 있는 HTML을 내려준 웹서버(Origin)에게만 Ajax 요청을 보낼 수 있다.
MS가 XMLHttpRequest를 처음 만들 때만 해도 이런 제약은 당연한 것처럼 보였지만, 지금에 와서는 OpenAPI를 통한 매시업(Mashup)이 활성화되는 데 가장 큰 장애물이 되었다. 매시업이 아니더라도 여러 개의 도메인을 사용해야 하는 대규모 사이트를 개발할 때도 골치거리였다. Same Origin Policy를 우회하는 방법으로 JSONP, IFRAME IO, CrossDomain Proxy 등이 고안되었지만, 보안성이 취약하다거나, 동기 호출이 안되거나, 주고 받는 데이터 형식이 제한되거나, 직관적이지 못하거나(dirty hack), ... 등의 문제점 때문에 표준화되기엔 무리가 있었다.
(중략) 한 참 뒤에야 W3C는 (MS의 IE가 제공하는 방식을 수용하여) 크로스도메인간에도 Ajax요청을 주고 받을 수 있는 방법을 표준화 했는데, 그것이 바로 CORS다.
CORS를 한 마디로 요약하면, "요청을 받은 웹서버가 허락하면 크로스도메인이라도 Ajax로 통신할 수 있다"라는 정책이다. 기술적으로는 크로스도메인에 위치한 웹서버가 응답에 적절한 Access-Control-Allow-류의 헤더를 보냄으로써 크로스도메인 Ajax를 허용 수 있다.
말이 뺑뺑도는 느낌인데, 예를 들어 보자(코드를 줄이기 위해 jQuery를 사용했지만 XMLHttpRequest를 직접 사용해도 마찬가지다). Ajax 요청을 보내는 one.html을 내려 준 a.com이 오리진 웹서버다. 이 요청을 받는 b.com이 크로스도메인 웹서버다. a.com에서 b.com으로... 그래서 크로스-도메인이다.
보다시피, Ajax 클라이언트 측에는 추가적으로 할 일이 없고, 서버 측에서 할 일도 많지 않다. 웹서버(b.com)이 응답에 Access-Control-Allow-Origin헤더를 통해 모든 Origin(*)에서 오는 요청을 허락했으므로 다른 도메인(요청을 보낸 one.html을 내려 준 a.com)과 Ajax로 통신을 할 수 있다. 플래시에 익숙한 개발자라면 crossdomain.xml 을 떠오를 것이다. 맞다. 사실상 똑같다.
CORS는 FF 3.5+, 사파리 4+, 크롬 등의 대부분의 현대적인 브라우져에서 지원한다. IE의 경우엔 IE8부터 지원하는데, XMLHttpRequest대신 XDomainRequest객체를 사용해야 한다. 즉, 거의 다 된다! IE6,7만 무시하면... oTL
CORS 표준에 따르면 Origin외에도 HTTP 인증 여부, HTTP 메소드(GET, POST, ...), 특정 헤더 존재 유무 등의 다양한 기준으로 접근을 허용(preflight request)할 수 있는데, IE8은 이 스펙을 지원하지 않는다. -_-; CORS가 IE의 비표준 확장에 근거해서 만들어졌다는 점을 생각해보면.. 개그도 이런 개그가... -_-; IE9은... 아직 확인해보지 못했다.
클라이언트 대신 서버 측에서 뭔가를 해야 한다는 것은 장점인 동시에 단점인데, 기존의 수많은 OpenAPI들을 활용하고 싶어도 제공자들이 CORS를 적용하기 전까지는 무용지물... -_- OpenAPI를 제공하고 있거나, 제공할 계획이라면 JSONP 뿐 아니라 CORS도 고려해야 할 듯...
처음 언급된지 십년이 다 된 "Web as a Platform"이 실감나는 요즘이다. 팀 버너스 리가 원하던 원치않던... 웹은 점점 플랫폼으로 진화(혹은 변신)하고 있다. 별것 아닌 CORS도 이런 관점에서 보면 조금은 다르게 보일지도...
앱스프레소에서는 개발의 편의를 위해 확장 API를 제공하는데, 네트웍 관련 API들은 ax.ext.net에 모여있습니다.
이 글에서는 예제를 통해 크로스도메인 AJAX 요청을 지원하는 앱스프레소 확장 API들에 대해 알아보겠습니다.
중요: 첨부된 예제의 src/apis 폴더 아래에 여러개의 js 파일들이 들어있는데, 이는 기존에 배포된 Appspresso SDK의 버그로 인해 사용할 수 없었던 확장 API를 사용할 수 있도록 임시로 제공되는 것이며, 이후에 배포될 Appspresso SDK에서는 이 js 파일들이 없어도 확장 API를 사용할 수 있습니다.
예제 웹앱 프로젝트
AxExtNet.zip 파일을 Appspresso SDK의 Workspace 디렉토리에 압축을 풀고, File/Import/Existing Projects into Workspace로 이클립스 프로젝트로 추가하세요.
src/index.html에 이 글에서 설명할 ax.ext.net.get/post/curl API를 사용한 예제 코드가 모두 들어있습니다.
첫번째 인자로 지정한 URL로 GET 요청을 보냅니다. 요청이 성공하면(서버의 응답 코드와 무관하게, 요청이 서버로 보냈고 응답을 받았으면) success 콜백함수가 호출되고, 실패하면 error 콜백함수(생략가능)가 호출됩니다. success 콜백 함수로 전달되는 인자의 data, status, headers 등의 속성을 이용해서 응답의 세부 결과를 확인할 수 있습니다.
ax.ext.net에는 이 글에서 설명한 것 외에도 업로드/다운로드(진행 상황을 확인까지), 메일 보내기 등의 기능을 제공합니다. 이 확장 API들을 활용하기 위해서는deviceapis.filesystem를 함께 사용해야 하는데, 다음 기회에 별도의 예제와 함께 설명하겠습니다.
/*
막간을 이용해서 CSS 삽질~~ just for fun~~
나름 삽질한다고 했는데... 해서 만들었는데... 아무도 안쳐다보는 것 같아서... ㅠㅠ
결과 동영상을 짤방으로~~(웅장한 사운드 주의!!!!)
*/
웹킷 CSS 애니메이션으로 스타워즈 오프닝 크롤 구현하기
CSS3에는 자바스크립트의 도움없이 애니메이션 효과를 구현할 수 있는 방법이 추가되었다. 대표적인 것인 transition과 animation이다. transition은 간단한 전환 효과를 구현할 때 주로 사용되고, animation은 플래시와 유사한 키프레임 기반 애니메이션을 만들 때 사용된다.
21세기, 머나 먼 은하계 저 멀리... IE6가 세계에서 두번째로 많은 대한민국의에서 HTML5와 CSS3의 멋진 기능들이 그림의 떡일 뿐이라고 생각하던 시절이 있었지만...
우리에겐 모바일 웹이 있다! 스마트폰, 태블릿등의 모바일 단말의 브라우져는 거의 대부분이 웹킷 기반이다. 그리고 그 숫자는 기존의 PC 숫자보다 훠~ㄹ씬 많다. 적어도 모바일 웹에서만큼은 마음놓고 HTML5와 CSS3를 써도 된다!!고 말하고 싶지만... -_- 구글의 크롬은 아직 3차원 변형을 지원하지 않는다. OTL
각설하고, 이 글에서는 웹킷의 CSS 애니메이션, 정확히는 -webkit-animation과 -webkit-keyframes, -webkit-transform, -webkit-perspective 등을 활용해서 스타워즈의 오프닝 크롤을 구현해 보려고 한다.
백문이 불여일견! 소스부터 보자! 먼저, 롱~ 타임 어고 파 파~ㄹ어웨이 어쩌고 하는 부분이다.
@-webkit-keyframes starwars_galaxy { from { opacity:1; } 50% { opacity:1; } to { opacity:0; } }
-webkit-animation-name:<애니메이션_식별자> 은, 노드가 표시될때 지정한 애니메이션을 수행하라는 의미다. 구체적인 애니메이션 내용은 @-webkit-keyframes <애니메이션_식별자> { … } 형식으로 정의한다. 애니메이션에서 핵심이 되는 프레임은 from(혹은 0%)에서 to (혹은 100%)까지 순차적으로 애니메이션을 수행되며, 중간 과정은 (플래시의 in-between과 비슷한 원리로) 자동으로 만들어진다. -webkit-animation-duration:<재생시간> 은 지정한 애니메이션 전체를 재생하는 시간이다. -webkit-animation-timing-function:<타이밍함수> 은 시간이 점점 빠르게 혹은 느리게 가는 등의 효과를 지정한다. -webkit-animation-delay:<지연시간> 은 애니메이션이 시작되기 전까지의 지연 시간을 지정한다. 위의 예는, 시작하면(from) 화면에 #galaxy 레이어의 표시(opacity:1)하고, 1.5초(50%)이후 부터 투명도를 조절하기 시작해서(opacity:1) 마지막(to)에는 화면에서 사라지는(opacity:0) 애니메이션이다.
다음으로, STAR WARS라는 아웃라인 로고가 익스트림 클로즈업에서 빠르게 멀어지는 장면이다.
#title { position:absolute; display:block; left:-400%; top:30%; width:900%; height:100%; color:transparent; font-size:10em; -webkit-text-stroke-width:0.05em; -webkit-text-stroke-color:#ff3;/*XXX: this will not animated! :'( */ text-align:center; white-space:nowrap; overflow:hidden; opacity:0; -webkit-animation-name:starwars_title; -webkit-animation-duration:7s; -webkit-animation-timing-function:ease-in-out; -webkit-animation-delay:3s; }
@-webkit-keyframes starwars_title { from { font-size:1000em; opacity:1; } 90% { font-size:0; opacity:1; } to { font-size:0; opacity:0; } }
#title > p { font-family:'Orbitron',sans-serif; font-weight:900; }
좀 더 복잡해보이지만 기본적으로는 동일하다. 타이밍 함수를 easy-in-out으로 지정해서 애니메이션의 시작과 끝은 빠르고 중간은 천친히 진행되도록 지정한 것, -webkit-text-storke 으로 텍스트의 윤곽선을 표시하는 것, 웹 폰트를 활용하는 것 정도가 특이한 부분이다.
@-webkit-keyframes starwars_crawl { from { top:50%; opacity:1; } to { opacity:1; top:-100%; } }
-webkit-perspective:<투영된_상단_너비> 는 2차원 평면을 원근법에 따른 3차원으로 투영할 때 상단의 너비를 지정한다. 하단의 너비는 이에 맞게 늘어나거나 줄어든다. -webkit-perspective-origin:<소실점_가로_위치> <소실점_세로_위치> 은 3차원 투영의 기준이 기준이 되는 위치(소실점)를 2차원 평면을 기준으로 지정한다. perspective는 머리 속으로 상상하기가 쉽지 않으므로 임시로 background/border 등을 설정해서 투영 전과 투영 후에 영역을 확인하는 것이 편하다. 위의 예는, 가로 60% 세로 60% 너비의 2차원 평면을 상단 가운데(50% 0%)가 다섯글자 너비(5em)인 3차원 평면(하단은 이에 맞춰 늘어나므로 밑변이 넓은 사다리꼴이 만들어진다)을 만든다. 애니메이션 자체는 단순하다. 10초동안 기다렸다가 40초에 걸쳐서 상단 좌표(top)을 50%(화면 아래에서) 위치에서 -100% 위치(화면 위로 텍스트들이 다 사라질 때까지)로 바꾸는 애니메이션이다. 이 과정이 3차원으로 변형된 평면 위에서 애니메이션되면 꽤 그럴 듯하게 보인다.
백견이 불여일RUN! 결과를 “눈"과 “귀”로 확인하자! 안타깝지만, 데스크탑용 사파리에서만 제대로 확인할 수 있다. 꽤 웅장한 사운드가 나오니 조용한 곳에선 주의 요망!!
아이폰이나 아이패드에서도 되어야겠지만, 마지막 자막이 올라가는 부분이 의도한대로 동작하지 않았는데, 화면을 톡톡 탭하면 정상적으로 자막이 올라가는 걸로 봐선 버그인 듯... 이 부분에 대해 명쾌한 해결책을 알려주시는 분에게 보라매 공원 반경 1km이내에서 별다방급 커피 1회 빌붙기 허용권을 증정하겠다. -_-;
사파리 깔기 싫다는 분들을 위해서 유투브 동영상도 준비했다 -.-v 역시나, 꽤 웅장한 사운드가 나오니 조용한 곳에선 주의 요망!!
이 글에서는 웹킷이 제공하는 CSS 애니메이션을 이용해서 스타워즈의 오프닝 크롤을 구현해보았다. 이미지와 자바스크립트를 조금 쓰면 훨씬 더 그럴듯한 결과를 만들 수도 있겠지만, 웹앱과 CSS의 가능성을 보여준다는 의미에서 의도적으로 사용하지 않았다.
“하이브리드 모바일 웹앱”이라는 생소한 용어를 떠들고 다니다 보니, “네이티브로 하면 훨씬 더 쉽게 빠르게 만들 수 있는데 왜 웹으로 할려구 그러지?” 라는 얘기를 많이 듣는다. 반은 맞고 반은 틀린 얘기다. 웹으로 모든 걸 다할 순 없다. 그러나 우리가 일상적으로 접하는 앱의 90%는 웹으로도 충분히 만들 수 있다. 그리고 대부분의 경우에는 더 쉽다. 설령 조금 더 어렵다고 하더라도 그렇게 만들어두면 (아직은 좀 먼 얘기지만) 웹브라우져만 있는 환경이라면 어디에서라도 접근할 수 있다.
페이지 컨트롤(UIPageControl; Carousel; 일명 회전목마 컨트롤)은 아이폰이나 안드로이드폰을 쓰면 가장 먼저 접하게되는 UI 컨트롤이다. 일명 홈 스크린이라고 불리는 화면에서 가로 또는 세로로 플리킹(flicking)하면 이전/다음 페이지로 이동하는 그 컨트롤이다. 아이폰의 경우에는 화면 하단에 하얗고 까만 작은 동그라미가 있고, 안드로이드는 화면 상단 좌우에(폰에 따라 조금씩다르다) 작은 동그라미가 있어서, 총 몇 페이지 중에서 몇 번째 페이지를 보고 있는 지를 알려준다.
이 글에서 설명하는 방법을 안드로이드용 푸딩얼굴인식 앱을 만들면서 활용했는데, 데모 동영상에서 35초와 1분 10초 근처에 나오는 화면이 이 컨트롤을 활용한 것이다.
이 글에서는 iScroll 라이브러리를 활용하여 페이지 컨트롤을 구현하고, 덤으로 아이폰과 유사한 인디케이터 까지 구현해 보았다.
모바일 단말은 화면이 작기 때문에 이런 유형의 컨트롤(탭/Carousel/...)들이 꽤 다양하고, 또 유용하지만, 직접 만들자면 쉽지 않다. 그렇다고 이 컨트롤 하나 때문에 Sencha나 jQueryMobile 같은 덩치 큰 프레임웍을 사용하는 것이 부담스럽다면, iScroll 라이브러리는 한 번 쯤 살펴볼 가치가 있다.
아이폰/아이패드/아이팟의 모바일 사파리와 안드로이드의 모바일 크롬 등은 모두 터치기반 모바일 웹킷을 사용하는 브라우져들이다. 이 브라우져들은 버튼 등을 눌렀다(touchstart) 떼도(touchup) 즉시 반응(click)하지 않는데, 그 이유는 연속되는 터치 동작(touchstart-touchmove-touchend)들이 제스쳐(swipe, long click, …)인지 여부를 확인하기 위해 최대 300ms의 지연시간이 생기기 때문이다. 모바일 웹 사이트를 만드는 경우라면 이 정도의 지연시간은 크게 문제가 되지않지만, 상대적으로 신속한 반응을 요구하는 “웹앱"이라면 얘기가 달라진다.
해결책은 간단하다: 1. 손가락으로 무언가를 누르면(touchstart) 2. 웹킷의 기본 동작(300ms 지연)을 못하게 막고(preventDefault) 3. 움직임(touchmove) 없이 4. 손가락을 떼면(touchend) 5. 클릭(click)으로 간주한다.
touchstart/touchend을 mousedown/mouseup으로 바꿔놓고 보면 HTML5 이전에 drag & drop을 처리하기 위해서 사용하는 방식과 유사하다.
다시 말하지만, 위의 페이지는 터치기반의 모바일 웹킷, 즉 모바일 사파리나 모바일 크롬으로 봐야 효과가 있다.
일단 눈에 보이는 Slow Button과 Fast Button 각각을 평소대로 눌러보자. 클릭을 감지하는데 걸린 시간이 표시되는데, Fast 쪽이 조금 빠르긴 하지만 큰 차이는 없어 보인다. 이번에는 평소보다 좀 더 손끝에 감각을 모아서 “톡톡 두드린다는 느낌”으로 각 버튼을 눌러보자. Slow Button의 경우엔 아예 반응을 하지 않거나 확대(아이폰등에서는 더블탭이 자동 확대/축소)기능이 동작된다. Fast Button은 그런 동작을 하지 않는다.
이 글에서는 touchstart-touchmove-touchend 이벤트를 활용하여 버튼의 반응속도를 개선하는 방법을 알아보았다. 이 세가지 이벤트의 활용법을 잘 익혀두면 다양한 유형의 터치 입력을 처리하는데 많은 도움이 될 것이다.
이젠 추억이라 말할 수 있을 만큼의 시간이 지났고... 그냥 생각나는 대로 적어보려고 한다.
초딩.. 정확히는 국딩 시절, 처음 접한 FC-30은 그냥 신기하고 알 수 없는 그 무엇 그 이상도 그 이하였다.(응?) 컴퓨터라는 것을 인식하고 접한 기계는 8비트 애플... 정확히는 로얄 컴퓨터라는 회사에서 만든 애플II+호환 기종이 처음이라고 보는 게 맞겠다. 한수찬님이 쓴 애플 입문 II+(제목이 특이해서 지금도 기억한다)와 애플 어셈블리 두 권의 책이 유일한 (한글로 된)스승이 었고, 컴퓨터에 한글이 안나오는 것이 전혀 이상하다는 생각도 못했다.
그 무렵에는 (전산을 전공했던)형이 남겨둔 디스켓들을 뒤적거리다가 이것 저것 실행시켜보곤 했는데, 그러다가 우연히 "사주풀이" 프로그램을 보고 컴퓨터에 한글이 나온다는 사실을 처음 알게 됐다. 그 한글 프로그램이 소위 "CALL-3327" 한글이라고 불리는 프로그램이었다는 사실을 안 것은 한 참 뒤의 일이다. 또 하나의 한글 프로그램을 발견했는데 그것이 유홍준님의 "애플 한글"이라는 것을 안 것도 역시 한 참 뒤의 일이다.
공식 기록(?)에 따르면 CALL-3327 한글은 류백현님이 1981년에 개발한 것이라고 하는데...
CALL-3327의 -3327은 메모리 상에서 한글 화면으로 전환하는 프로그램이 있는 주소다. 아무튼 이 프로그램을 실행 시키면...
한 화면에 20x12~40x24자의 한글이... 즉, 종성이 있으면 영어 두 줄, 가로 모음(ㅏ,ㅑ,ㅓ,ㅕ...)이 있으면 영어 두 칸... OTL
CALL-3327 한글은 N-byte 코드라는 것을 사용했는데, 별다른 한글 코드가 없다고 보면 된다. 한글 화면에서는 한글로 보이지만 영문 화면에선 그냥 영어 알파벳들로 보인다. 다만 한글 시작 부분에 CTRL+K 끝날 때 CTRL+A가 들어있어서 한글 화면에서는 그 표시들(SHIFT-IN/SHIFT-OUT; SI/SO)을 인식해서 그 이상이 알파벳들을 한글로 보여주었다.
LIST
10 PRINT "<CTRL-K>GKSRMFDMSDKFMAEKQEK<CTRL+A>"
CALL-3327
LIST
10 PRINT "한글은 아름답다"
뭐 이런 식이다. -_-; 물론 한글이 위의 그림처럼 보인다.
당시, CALL-3327 한글을 사용해서 주소록 관리 프로그램을 만들다가, 생각지도 못했던 난관에 봉착했는데... 그것이 바로 "소트"였다. 나름 똑똑했던 나는(?!) 베이직 입문서에서 배운 "버블 소트"를 훤~히 꿰뚫고 있었으므로(흠...흠...)자신있게 덤볐는데... but... OTL
CALL-3327 한글에서는 별도의 한글 코드라는 개념없이 같은 키보드 위치에 존재하는 영어 알파벳의 코드를 쓰다보니, 별 생각없이 소팅하면 ㅁ(A)가 ㄱ(R)보다 앞에 나오게 되는 거였다. 나름 똑똑했던 나는(?!) 한글 코드라는 개념도 없었음에도 불구하고 일종의 변환 표(!!)를 만들어 소팅하는데 성공했다고... 생각했지만... but... OTL
CALL-3327 한글에서는 한글 한 글자가 1바이트(초성만)부터 5바이트(초성자음+중성모음+중성복모음+종성자음+종성복자음)까지 다양한 길이를 갖다보니, 그냥 비교하면 엉뚱한 결과가 나오게 된다.예컨데 "하마"와 "한글"을 비교하면 "하마"이 앞에 와야 하지만, "ㅎㅏㅁㅏ"와 "ㅎㅏㄴㄱㅡㄹ"을 비교하게 되어 "한글"이 앞에 오는 것이다. 말하자면 한글을 풀어서 쓴 상태로 소팅이 되는 것인데, 한글 코드라는 개념이 없던 나로써는 풀기 힘든 문제였다. 완전 OTL
85년인가 86년인가에 "멋한글"이라는 이름을 가진 CALL-3327의 개선판이 나왔는데, 버그도 많이 잡혔고, 글자 모양도 조금 더 예뻐졌고(?)... 아무튼 이름만큼이나 멋졌다고 기억된다. 만든 분의 성함은 아쉽게도 기억이... -_-;
마소(애초에는 Microsoft가 아닌 정보시대의 월간지 Microsoftware의 애칭이었다)에서 한글 코드에 대한 특집 기사 등을 통해 2바이트 조합형과 완성형, 3바이트 조합형... 같은 한글 코드의 원리를 깨우쳤지만, 그 무렵엔 이미 한글 소팅 따위는 관심 밖이었다. 그 무렵의 관심사는 어떻게 하면 한글이 예쁘게 나올까?, 그리고 한 화면에 많은 글자가 나올까?, 그리고 터보 파스칼에서(CP/M에서) 한글을 쓸 수 있을까?... 였다. 중앙한글(근거 없는 기억에 따르면, 당시 중앙대 천문학과 학생이었던 이충수님가 한글III를 개선해서 만든 한글 워드 프로세서?)에 빼낸 6x2x1벌 한글 폰트를 사용할 수 있는 라이브러리를 만들어서 이것 저것 가지고 놀았던 기억이 있다.
지금 생각해보면, 한글 문제에 있어서 압도적인 차이(한 화면에 40x24글자를, 예쁘게, ...)가 우리나라에서 8비트의 수명을 단축시키고, 16비트 시대의 시작을 앞당기는 큰 원인이었던 것 같다.
이런 쓰잘데기 없는 동영상을 굳이 만들어 올리는 이유는 "웹 앱"(WebApp; HTML5App)이 그렇게 거창한 것도 아니고, 어려운 것도 아니고, 멀리 있는 남의 나라 이야기도 아니라는 것을 보여주기 위해서다.
PhoneGap, Titanium, QuickConnect 같은 거창한(?) 제품을 동원하지 않더라도 JQueryMobile, Jo, Wink, Sencha Touch 같은 UI 툴킷과 HTML5 canvas 태그 그리고 HTML5 JS API들(WebStorage, WebSQLDatabase, WebWorker, ...), 그리고 W3C의 DAP(Geolocation, ...)를 사용하면 웬만한 앱은 만들 수 있다.
풍경 1. 아이폰이 국내에 출시된지 1년도 안됐는데... 아... 아이폰 없던 시절이 어땠는지 기억조차 가물가물... 먹고 살려니 아이폰 개발 공부는 해야겠는데, 망할 놈의 옵씨... 옵씨는 그렇다 치고, 코어 파운데이션, 코어 그래픽스, 코어 애니메이션, 뭔 코어가 이렇게 많냐? 핵분열도 아니고... OTL
풍경 2. 없는 살림에 거금 10만원 들여 아이폰 앱 개발자 등록해서 1년 동안 앱 3개 겨우 올렸는데... 안드로이드가 대세? 열라 안드로이드 공부해서 앱 좀 올려 볼려니... 안드로이드 마켓은 뭐고 티스토어는 뭐고 올레마켓은 또 뭐냐? 그까이꺼 대충~ 눈감고 넘어가려니... 블랙베리? 심비안? 팜프리? 윈폰7? 바다? OTL
풍경 3. 아래아한글 새 버전 나온 줄 알았던 넷스케이프와의 첫만남, 문자열과 한판 승부를 벌였던 CGI 시대, ASP, PHP, JSP... OOO 서버 페이지 시대, 유행따라 삼만리 AJAX 시대... 어느새 HTML만으로 어플리케이션을 만드는 시대??? 먹고살려니 안할 순 없고... OTL
풍경 4. 스마트폰(그게 뭔데? 먹는거냐?)용 앱을 만들긴 만들어야 겠는데.. 새로운 언어 배우기도 귀찮고, API는 낯설고, 당장 할 줄 아는 건 웹... 그래서 웹 기술만으로 앱을 만들 수 없을까... phonegap은 또 뭐고 titanium은 또 뭐고, WAC은 또 뭐냐? OTL
Palm WebOS, Safari(iOS,Desktop,Dashboard), Chrome(Android,Desktop) 등 webkit 기반 브라우져만 지원.
경량
자바스크립트 41K(최소화된 버전) + UI CSS/리소스(176K)
PhoneGap 호환(?)
PhoneGap과 호환되지 않는 자바스크립트 라이브러리는 ”없음”.
주요 기능
UI
최근 모바일 단말 UI의 de-facto인 iOS의 UI을 염두에 둔 UI 툴킷. 하나의 화면(joScreen)은 상단의 헤더(joTitle, joToolbar)와 푸터(joFooter, joToolbar)로 구성. 화면과 화면 사이를 앞뒤(위아래)로 이동하는 네비게이션 레이아웃(joStackController, joStack). 기본적인 HTML 폼의 입력 필드에 대응하는 위젯들(joControl, ...), 페이지 내부 팝업(joPopup) 등의 필수적인 위젯 제공. CSS를 통한 테마/스킨 지원. 캘린더, 챠트 등의 고급 위젯 부족.
joContainer
joCard
joFlexcol
joFlexrow
joFooter
joGroup
joPopup
joScreen
joScroller
joStack
joStackScroller
joTitle
joToolbar
joControl
joButton
joCheckBox
joExpando
joHTML
joInput
joDateTime
joPasswordInput
joTextarea
joLabel
joList
joMenu
joTabBar
joTable
joKnob
joSlider
joDivider
joShim
Data
HTML5의 WebSQLDatabase(Webkit 기반 브라우져에는 대부분 제공됨)를 통한 로컬(클라이언트측) 데이터베이스 접근 제공. 추후에 PhoneGap과 연계하여 로컬 파일을 통한 데이터 접근을 제공할 계획으로 보임(joFile, joFileDataSource) 원격(서버측) 데이터 접근 부재.
joDatabase
joDataSource
joFileDataSource (x)
joSQLiteDataSource
joFile (x)
Utility
기본적인(필수적인) 유틸리티 API 제공. 추후에 PhoneGap과 연계하여 모바일에 특화된 기능을 제공할 계획으로 보임.
weak typing은 아주 편리한 언어적 특성이지만, 잘못쓰면 - 특히 strong typing(C, 자바 등의 대부분의 주류 언어)에 익숙한 개발자들에게 - 치명적인 독이 될 수 있다. underfined, null, NaN 그리고 ""(빈문자열) 간의 차이는 상당히 오묘하므로, 가장 확실한 방법은 확신이 없다면 명시적인 형변환을 수행하는 것이다.
nested block scope
function test() {
var foo = -1;
for (var foo = 0; foo < 10; foo++) { … }
alert(foo);
}
위의 코드에서 두번째 var 선언문은 아무 효과가 없다. 따라서, -1이 아니라 10이 출력된다. 별것 아닌것 처럼 보이지만, 문제가 되면 굉장히 찾기 어려운 버그다. jslint를 사용하면 경고를 해주는 데, 가장 확실한 방법은 모든 변수 선언을 함수 앞에 모아두는 것이다(예전 C 스타일).
function overloading
function test(foo) {
alert('one arg');
}
function test(foo, bar) {
alert('two args');
}
function test() {
for (var i = 0; i < arguments.length; i++) {
alert(arguments[i]);
}
}
위의 코드에서 앞에 두개의 함수 정의는 무시되고, 마지막의 세번째 함수 정의만 유효하다. 자바스크립트에서는 arguments를 사용하여 가변 파라메터를 처리할 수 있다. 그러나, 더 좋은 방법은 이름있는 파라메터를 사용하는 것이다. 즉, 객체 하나에 파라메터의 이름과 값을 함께 전달 하는 것인데, 요즘 많이 쓰이는 대부분의 자바스크립트 라이브러리들이 모두 이 방식을 선호한다.
"string" is not array-of-chars
var str = "hello";
alert(str.charAt(2));
alert(str[2]);
위의 코드에서 앞의 alert은 출력되지만, 뒤의 alert은 에러다. 잘된다고? IE에서는 해보시길...
자바 개발자들에겐 익숙할텐데, C/C++ 개발자들은 좀 귀찮을 듯... ^^;
비슷한 예로, NodeList(예: document.getElementsByName() 등의 리턴 형식)도 배열이 아니다.
뭐가 이상하냐고? 자바에서 똑같은 짓을 해보자. -.-;;;; 자바에선 Integer.parseInt()에 radix를 지정하지 않으면 10을 지정한 것으로 처리하지만, 자바스크립트에선 알아서 하라는 뜻으로 해석한다.
var sum = parseInt(num1.value) + parseInt(num2.value);
alert(sum);
위의 코드는 의도했던 안했던, 8진수와 16진수 계산기 기능도 갖고 있다. ^^; 이런 사소한 문제가 찾아내기 힘든 버그를 만든다. jslint를 사용하면 경고를 해주는데, 가장 확실한 방법은 parseInt()를 호출할 때 무조건 두번째 파라메터(radix)를 지정하는 것이다.
자바스크립트의 this는 함수가 "선언된 위치"가 아니라, 함수가 "호출 문맥(invocation context)호출된 위치"에 따라 결정된다.
위의 코드에서, 사용자가 버튼을 누르면 button.onclick에 연결된 콜백 함수를 호출하는데, 그 시점의 this는 함수가 선언된 위치인 test 객체가 아니라, 콜백 함수를 호출하는 "버튼"(DOM 노드)이다. 그래서 엉뚱한 값(버튼 태그의 name 속성 값)이 출력되는 것이다.
지난 주 토요일에 한국 developerWorks의 dW Live!의 마지막 순서 "개발자들의 수다"에서 있었던 일.
앞 순서에서 아주 멋진 발표를 한 젊고 똘똘한 개발자에게 질문이 집중됐다. "개발팀의 젊은 멤버들에게 조언해줄만한 학습 로드맵이 없는가"라는 질문으로 시작된 토론(?)은 "성공한 개발자가 되기 위한 경력 관리"를 거쳐 어느새 "개발자의 창업" 이야기로 흘러갔다.
오늘의 이야기는 여기서 시작된다.
이런 식의 얘기를 하다보면 늘 자연스럽게 창업 얘기로 흘러가곤 하는데, 창업을 하면 성공한 개발자 일까? 세르게이 브린과 래리 페이지? 스티브 잡스? 빌 게이츠? 처럼? 글쎄... 이 사람들은 성공한 개발자가 아니라 성공한 "개발자 출신" 사업가가 아닐까? "사업가"가 아닌 성공한 개발자들도 많다. 레이 오지, 리챠드 스톨만, 제임스 고슬링, 라이너스 토발츠, 스테픈 워즈니악... 앤디 허츠펠트는 어떤가? 누군지 모르겠다고? 그래도 나에게는 위대한~ 그리고 성공한 프로그래머다. 성공한 개발자들은 많지만 그들의 현재 모습은 (위키피디아에 남들이 만들어 준 개인 페이지가 있다는 것만 빼면) 너무나 다르다.
가만히 생각해보면, 성공한 개발자라는 것은 (대부분의 경우) 최종 목표가 아니다. 그들의 최종 목표는 성공한 개발자 출신의 "무엇"이다. 성공한 "개발자 출신" 사업가?, 성공한 "개발자 출신" 관리자?, 성공한 "개발자 출신 "유명인? ...
많은 개발자들은 창업을 꿈꾸고, 경영과 회계를 공부하고, 사업 아이템이라는 말만 나오면 눈을 빤짝이며 열변을 토하고, 드물게는 실천에 옮긴다. 그러나, 그들 모두가 성공한 개발자 출신 "사업가"가 되고 싶은 것은 아니다.
많은 개발자들은 "가방끈"과 "자격증"을 위해 시간과 돈을 허비하고, 예측 가능하면서도 애자일한 프로젝트 관리 방법론(!)에 집착하고, 소꿉놀이 만도 못한 정치판을 기웃거린다(밀려나지 않기 위한 최소한의 자기 방어일 뿐~이라고 말하겠지만). 그러나, 그들 모두가 성공한 개발자 출신 "관리자"가 되고 싶은 것은 아니다.
많은 개발자들은 블로그의 방문자 수와 트위터의 팔로어 수에 연연하고, 실속없는 세미나와 번역에 에너지를 허비하고, 유명한 개발자(사실, 그 분들 개발에서 손 뗀지 좀 오래됐다) 아무개에게 오마주를 날린다. 그러나, 그들 모두가 성공한 개발자 출신 "유명인"이 되고 싶은 것은 아니다.
아주~ 소수의 개발자들은 더 명쾌한 코드를 위해 봤던 코드를 다시 보고 다시 고치고, 한번 쓰고 버릴 빌드 스크립트를 만들기 위해 한나절을 소비하고, 스프링 프레임웍의 소스 안으로 Trace Into 하는 것을 당연하게 생각하고, Wireshark으로 패킷을 까는 걸 두려워하지 않는다. 그러나, 그들도 성공한 "개발자"가 되고 싶다.
더~ 많은 개발자들은 위의 것 어디에도 관심이 없다. 그러나, 그들도(!) "성공한" 개발자가 되고 싶다.
개인적으로 만나 본 젊고 똘똘한 개발자들이 하는 얘기는 거의 비슷하다.
"내가 만들고 싶은 거 만들면서 밥먹고 살 수 있으면, 큰 돈은 안벌어도(못버는게 아니고 안버는거다!) 괜찮다"
글쎄... 다들 말은 그렇게 하지만(나도 젊을 때는 그렇게 떠들고 다녔고)... 개뿔~ 별 것도 아닌 거 하나 만들었다가 큰 회사에 팔리면서 떼돈 벌었다는 아무개 사장님이 부럽고, 개뿔~ 개발의 개자도 모르고 폭탄주만 잘 마시는 CTO 아무개가 부럽고, 개뿔~ 알맹이도 없이 "하이테크 야부리"만 쳐대는 유명 블로거 아무개와 컬럼니스트 아무개가 부럽고, 말하는 것보다 코딩이 빠르다는 아무개가 부럽고, 주식으로 대박쳐서 회사를 그만 둔 옆 팀의 아무개가 부럽고, 또...
너무 멀리 왔다. 다시 개발자들의 수다로 돌아가자.
학습 로드맵과 경력 관리를 고민하기 전에, 내가 되고자 하는 그 "무엇"을 생각해보자. 그 "무엇"에 따라 학습 로드맵과 경력 관리는 달라질 수 밖에 없다. 이것 저것 다 부러워해봐야 하나도 가질 수 없다. 하나만 부러워해야 한다. 지금 그 "무엇"을 결정할 수 없다면, 아직은 때가 아니니, 수풀을 헤치고 물길을 건너~ 전진할 수 밖에... 그러면서도 그 "무엇"에 대한 고민을 잊지말자. (누구처럼...) 너무 늦기 전에...
먼저, 주최측에서 WebSphere sMash라는 솔루션을 소개했다. 그러나, 생뚱맞은 REST에 대한 질문 답변에 시간을 다 써버리고 sMash는 맛도 제대로 못봤다. (발표하시느라 고생하신 분께는 죄송하지만)오늘 데모만 놓고 보면 그냥 Yahoo! Pipes 설치형 버전이라는 느낌... -.-; REST로 딴지거신 분...은... 다음에 비슷한 행사나 세미나에선 좀 참아주셨으면... 발표자도 나름대로 계획이 있다는...
이어서, 페차쿠차 형식의 발표들이 이어졌다. 숨을 헐떡이는 발표자들...을 보면서 걱정이 되기 시작했다.(대산님 발표 여러번 봤지만 이렇게 힘들어하시는 건 처음 봄 :D) 아이팟 터치 타이머 켜놓고 한 번 연습하긴했는데.. 제비뽑기로 순서를 정하다보니... 나는 끝에서 두번째... 혹유랑 소곤거리느라 긴장도 다 풀리고, 별 생각없이 30초*15장을 넘기고 내려왔다. 듣는 사람은 어땠는지 모르겠음=3=333 짧은 시간에도 불구하고 좋은 내용을 핵심만 꼭꼭집어 발표하시는 분들... 대단하심 @..@)b
계속해서, 개발자들의 수다가 이어져야 하는데... -.-? 예전에는 몇가지 주제를 걸어놓으면 원하는 그룹에 끼어서 그 주제에 대해서 토론하는 방식이었는데... 이번에는 앞 순서의 발표자들을 앞에 앉혀놓고 질문 답변 시간... 쉽게 말해 "미수다" 스타일-.-;;; 나는 형식이 바뀐 줄도 모르고, "개발자의 커리어 패스 관리, 로드맵, 창업" 등에 대한 다양한 얘기들이 오고 가는 동안, "너무 옆길로 새는거 아닌가~"하면서 입 꾹 닫고, 진행자(우일님)만 바라보고 있었다는... 끝날 때쯤 되서야 상황을 파악하고, 딸랑 한마디~ 했더니... 행사 종료... 본의 아니게 클로징 멘트를 -.-;;;;;
행사가 끝나고, 발표자들은 기념품(8G USB 메모리! 막대기 아님!) 주최측 + 발표자들 + 꼽사리들은 근처 고급(!) 반점에 가서 맥주 or 고량주를 한 잔씩하고, 자장면 or 짬뽕 or 볶음밥을 먹고~(이게 오늘 나의 첫 끼니였다ㅠ.ㅠ) 후다닥~ 집으로~ 고고씽~
아무튼, 이런 류의 작은 행사들이 KOEX에서 하는 행사 보다 훨씬 재미도 있고~ 유익하다는 사실을 재확인했다.
이름과는 달리, 현재는 스프레드시트 형식(ods, xls, csv)만 보고 편집할 수 있다. 지원하는 스프레드시트 함수가 부족해서... 글쎄...
Androffice 1.3 $7.9
Androffice
...
모바일 오피스의 특성상 편집보다는 보기 위주이고, 편집이 가능하더라도 제한적인 경우가 많다. IMHO 모바일의 열악한 입력 환경을 고려할 때 편집 기능이 의미가 있는지도 의문이다.
이 쪽은 당분간 춘추전국 시대가 될 듯하다. (DataViz가 제2의 MS가 되지 못했음에 비추어 볼때...) 아직까지는 이 바닥이 큰 돈이 안된다는게 문제라면 문제인데... 스마트폰 시장이 어떤 식으로 전개되느냐에 따라 시장 규모가 달라질테고, 그렇게 되면 메이저 플레이어들이 지금까지처럼 두고 보진 않을 테니... 지금은 니치 마켓에서의 승자가 그때에도 승자라고 보긴 힘들다.
웹오피스라는 말이 언제 어떻게 생긴건지는 모르겠지만... 아는 사람만 알고 모르는 사람은 모르는 그런 단어다. 웹오피스라는게 오피스 어플리케이션(워드, 엑셀, 파워포인트 같은)에 스토리지 서비스(웹하드)와 협업 서비스가 결합된 형태인데, 어느 쪽이 비중이 높은가에 따라 서비스의 전체적인 성격이 결정된다.
저번 글에서도 밝혔듯이 스샷이 많아서 스크롤의 압박이 있지만, 깊이 있는 내용은 아니니, 이런것도 있구나라고 스샷만 보고 넘어가면 충분할 듯 ^^;
Document, Spreadsheet, Presentation 외에 다양한 협업 기능을 제공한다.
웹오피스라는 용어를 널리 알린 장본인이자, 현재로썬 최고의 "웹"오피스다.
애플릿은 물론이고, 플래시조차 사용하지 않는 "순혈 웹"을 추구하다보니, 웹브라우져들이(특히 IE) 많이 힘들어 한다. 개발자 관점에서 Google Docs의 PDF 뷰어는 엽기의 결정체다. 그러나... Chrome OS를 보면 왜 그렇게 "순혈 웹"에 집착했는지 이해된다. 그 집착 덕분에 Chome OS는 시작하자마자 완전한(완벽하진 않지만) 오피스 어플리케이션 수트를 확보했다.
처음에는 Writely를 인수하면서 조촐한 HTML 편집기로 시작했지만, 이후에 2Web Technologies의 XL2Web을 인수해서 Spreadsheet를, 곧이어 Tonic Systems를 인수해서 Presentaion을 추가하면서, 명실상부한 오피스 수트를 확보했다.(즉, 처음부터 구글이 만든건 아무것도 없다는... 역시 돈이 최고 -.-ㅋ)
저장 공간과 문서 크기에 대해서 꽤 복잡한 제한이 있는데, 계산해보면 대충 5G 정도의 저장공간을 제공하는 셈이다. IMNSO 저런 제한들은 고객들의 컴플레인에 대응하기 위한 핑계거리에 불과하다.
장점: 순수 웹오피스이므로 부가적인 설치과정이 필요없다. 다양한 협업 기능(여러 사람이 하나의 문서를 동시에 편집할 수 있는 공동 편집 기능은 압권!) 풍부한 Open API.
단점: MS Office 문서 호환성. 단순한 편집 기능. 성능(순수 웹오피스에 집착하다보니). 개발 문서 크기 제한.
Google Docs보다 더 오랜 역사를 가진 사실상 최초의 웹기반 오피스 수트다. 씽크프리가 먼저라고하는 설도 있지만... 애플릿을 "순수" 웹 오피스로 보기엔 무리가 있다. 그렇게 치면 한글과 컴퓨터의 넷피스(Netffice)(문 닫은지 좀 됐다)가 훨씬 먼저다.
개별적인 어플리케이션은 기능이나 성능면에서 Google Docs에 비해 크게 밀리지 않지만, 전체적으로 어수선한 느낌. 여러모로 Google Docs와 ThinkFree Online의 중간 정도의 위치인데 Zoho 만의 특징이 없다. (이름이 그래서 그런지) 좀 무시당하는 경향이 있지만, 여러모로 좋은 웹오피스다.
장점: 순수 웹오피스이므로 부가적인 설치과정이 필요없다. 다양한 제품. 다양한 협업 기능. 풍부한 OpenAPI. 특별한 단점이 없다 -.-;
단점: MS Office 문서 호환성. 단순한 편집 기능. 성능(Google Docs보다는 대체로 나은 성능을 보여줌). 어수선한 UX. 특별한 장점이 없다 -.-;
Write, Calc, Show 외에 MyOffice, Workspace, Docs 등을 통해 다양한 협업 기능을 제공한다.
자칭 The Best Online Office On Earth 라는... 웹오피스 서비스다.
오피스 어플리케이션 자체는 ThinkFree Office의 애플릿 버전이며(ThinkFree Server라는 제품으로 따로 판매하고 있다), 예전에는 Quick Write, Calc, Show라는 순수 웹 버전도 있었는데... 지금은 다 없어지고 애플릿 버전의 Write, Calc, Show와 순수 웹 버전의 Note를 제공한다.
MS Office 문서(doc, ppt, xls 등)와 Office 2007 형식(docx, pptx, xlsx 등)은 애플릿을 통한 편집을 지원하며, HWP와 PDF는 보기만 지원한다(문서를 볼 때는 애플릿이 아닌 UniPaper라는 플래시 기반 뷰어를 사용한다)
ThinkFree PowerTool이라는 전용 클라이언트 어플리케이션을 데스크탑(윈도, 맥, 리눅스)에 설치하여 사용하면 웹과 로컬의 디스크의 파일들이 자동으로 동기화되며, 데스크탑에 설치된 오피스 어플리케이션(MS Office, 한컴 오피스 또는 오픈오피스)으로 문서를 편집할 수 있다.
장점: 애플릿이 제공하는 Fidelity(오피스 2003과 유사한 UX). MS Office 문서 호환성(이 부분에서는 여타 웹오피스에 비해 압도적이다).
단점: 문서를 편집하려면 애플릿 설치가 필요하다. 고급 협업 기능 부재
가격: 무료(1G), 유료 서비스 추가 예정
아래 문서는 ThinkFree Docs의 임베딩 기능(UniPaper)을 사용해 본 것이다:
마이크로소프트가 심혈을 기울여 삽질하고 있지만 존재감이 없는 서비스인 Windows Live의 SkyDrive 서비스를 통해서도 사용해 볼 수 있다(Technical Preview). 어떤 분이 UX 디자인을 하셨는지 모르겠지만... 곳곳에 초가 숨어있다... 그래도 많이 좋아졌다. 저장 공간도 무려 25G!
무료(25G)
MS가 "팀 킬"을 피하면서 웹오피스 시장에서 자리잡기 위해서 여러모로 애를 쓰고 있다는 느낌. 좀 더 기다려 봐야 평가를 내릴 수 있을 듯...
아래 문서는 Windows Live SkyDrive의 문서 공유/임베딩 기능을 사용해 본 것이다:
우리 Word, 우리 Calc, 우리 Show 외에 웹하드, 서식, SMS 서비스 등을 제공한다.
또하나의 "국산" 웹오피스. 웹오피스라곤 하지만, 시작부터 끝까지 Active-X인지라... (웹에서 실행된다고 웹오피스라고 하면... 카트라이더도 웹에서 실행되니까 웹게임?) 웹오피스라고 하기엔 뭣하지만... 웹오피스 서비스가 갖추어할 것들은 모두 갖추고 있는데, 서비스가 제대로 알려지지 못해서 안타깝다.
두 말이 필요없는 de facto standard. 데스크탑 오피스의 절대 강자다. Word, Excel, Powerpoint 라는 제품명이 word-processing, spreadsheet, presentation를 작성하는 소프트웨어 또는 문서를 칭하는 일반 명사/동사가 되었다.
이제는 일반 명사가 되어버린 Word, Excel, Powerpoint 외에도Access, Accounting, Groove, InfoPath, OneNote, Outlook, Project, Publisher, SharePoint Designer, Visio, ... 겁나 많다.
최근에 한창 오픈 베타 중인 2010을 쓰고 있는데, 말도 많고 탈도 많은 리본 UI가 어느정도 자리를 잡은 듯 하다.
Microsoft Office 2007 / $149.95(HomeStudent), $399.95(Standard), $499.95(Professional), $679.95(Ultimate)
아래아한글(HWP), 넥셀(Nexcel), 슬라이드(Slide)와 한컴타자연습, 한컴사전, 한컴쪽지... 등으로 구성되어 있다.
흠흠... 자타공인 "대한민국 대표 오피스"다. HWP는 오랜 역사만큼이나 안정적이고 다양한 기능을 갖고 있지만 문제는 MS Office와의 호환성. 넥셀과 슬라이드는 지못미... 최근 한컴오피스 2010 (9.0)의 오픈베타가 한창 진행중인데, 반응은 나쁘지 않은 듯...
개인적으로는 1.0부터 돈주고 사서 썼는데(20만원이 넘었던 걸로 기억하는데), 만원짜리 815버전을 마지막으로(마음이 상해서) MS 오피스로 돌아섰다.
한글과 컴퓨터 오피스 2007 / 대충 279400원(대충 $250)) ~ 39600원(대충 $35; 가정용)
StarDivision에서 만든 상용 오피스를 (지금은 오라클에 인수된)썬 마이크로 시스템즈가 1999년에 인수하여, 그 이듬해 소스를 공개하면서 만들어진 오픈소스 오피스다.
윈도뿐 아니라 맥과 리눅스도 지원하며, 여러가지 유료/무료 변종이 있다. T모사가 "국산" OS, "국산" 브라우저와 함께 "국산" 오피스라고 우겼던(?) 그 녀석이다.
StartOffice(혹은 StarSuite)은 OpenOffice.org 프로젝트의 최대 스폰서인 Sun이 OpenOffice.org를 다듬어서 제품화하고 고객지원과 함께 판매하는, 말하자면 OpenOffice.org 상용 버전인데... 썬 홈페이지에서도 관련 정보를 찾기가 쉽지 않다. -,.-;;;; 그런데 이 녀석이 OpenOffice.org 보다 훨씬 팔랑거린다는 느낌은 나만의 착각일까?
맥에 번들되어 있던 평가판만 써 봤지만... Office 2007보다 더 낯설다. 내가 진정한 맥마니아 아니어서 그런가 보다~하고 포기했다. 익숙해질 정도로 써보질 못했으니 편리함은 잘 모르겠고, UI 만큼은 정말 멋지다. 키노트의 큐브가 회전하는 슬라이드 전환 효과는 동네 방네 사용되고 있다.
Documents, Spreadsheets, Presentations 등으로 구성되어 있다.
OpenOffice.org 프로젝트의 주요 스폰서인 IBM이 만든, 또 하나의 OpenOffice.org 변종. 안그래도 무거은 OpenOffice.org를 Eclipse RCP로 엮어 놓았는데... 말 그대로 "참을 수 없는 오피스의 무거움"을 느낄 수 있다. 그러나 이렇게 무거운 녀석을 만든데는 나름의 이유가 있으니... 궁극의 SDK를 통해 오피스를 문서가 아닌 어플리케이션 플랫폼화 해버렸다.
리눅스의 대표적인 GUI환경인 Gnome(이라고 쓰고 그놈~이라고 읽는다)을 위한 오피스 소프트웨어들이다. 둘 다 윈도로도 포팅되어 있다. 기능은 좀 부족하지만, 가벼운 걸로 치면 둘 다 쵝오 -.-)b 둘다 라이브러리화가 잘 되어 있어 AbiCollab, EditGrid 등의 웹오피스에 백엔드로 사용되고 있다. MS오피스 호환성은 KIN~ 더욱 결정적인 문제는... 프레젠테이션 툴이 없다는 것...
오픈소스 / Gnome Office / 무료
AbiWord
Gnumeric
말그대로 走馬看山~ 이름만 나열하는 것도 쉽지 않을 정도로 다양한 오피스들이 있는데... 다들 잘 먹고 살까?
오타가 잔뜩 있는 문장을 입력한 다음, 툴바의 오른쪽 끝에서 세번째 있는 필름롤 아이콘을 클릭하면 스펠 체커가 틀린 단어를 빨갛게 표시해 준다. 이 빨간 단어를 클릭하면 추천 목록이 나오고, 추천 목록에서 맞는 단어를 클릭하면 해당 단어를 선택한 단어로 대치한다. 웹 기반 스펠 체커 API는 익숙한 환경이라 금방 만들었는데, 다음 오픈 에디터의 구조에 익숙하지 않아서(오후에 코딩해야하는 줄 모르고, 오전 세미나를 대충 들어서 ㅠ.ㅠ) UI가 엉망이다. UI를 전반적으로 손을 많이 봐야 할 듯...
그날 만든 다음 오픈 에디터 예제에, 간단한 API 사용 예제와 자바독 문서, 관련 링크 등을 추가해서 급하게 프로젝트 홈페이지도 만들었다.
덧: 지금은 개인적으로 호스팅하고 있는 열라 후진 서버(셀2.66G/1.5G)에 올려놓았는데, 좀 쓸만한 서버를 확보할 수 있으면 올려두고, 여기저기 웹 프로젝트에서 써 먹을 수 있을 듯...한데, 혹시 도와주실 분 계신가요? ^^;
이번엔 혼자 좋아라 하는 넷빈즈다. IMNSHO, 이클립스는 IDE로써는 이미 맛탱이가 갔다. 그냥 다른 대안이 없어서 쓸 뿐~ 3.4 까진 달나라였는데... 이젠 안드로메다를 넘어 아공간으로 날아가버린...-,.-;
미리 말해두는데, 이 글의 관심사는 Java가 아니고 Python이다. Google AppEngine for Java라면 꽤 쓸만한 플러그인이 이미 있다.
아무튼 넷빈즈 6.0 이후로 비공식적으로 Python(Jython 포함)이 지원되는데... 이걸 이용하면 gnome-terminal + vim 만큼 손에 착 달라붙진 않지만, 몇가지 편리한 기능들이 있어서 아쉬운대로 쓸만하다. 이걸 AppEngine(Python) 개발에도 써먹어 볼려구 했더니... 문제가 좀 있어서 삽질이 필요하다.
Tools -> Plugins -> Available Plugins -> Python을 찾아서 체크한 다음 Install을 눌러주시면 된다. 직관적이다. 이클립스 P2인지 뭔지만큼 플렉서블하며 스케일러블하고 엘레강스하고 개떡같진 않지만, 나같은 촙오도 대충 하면 될 정도로 직관적이다. 참고로 Jython도 덩달아 설치된다. 리스타트하라고 겁주는데... 겁나니까 그냥 리스타트 하자.
5. 파이썬 런타임 등록
넷빈즈의 파이썬 플러그인은 아무말 안하면 Jython 런타임을 사용하지만, 앱엔진 개발을 위해선 Python 2.5.x가 필요하다. Tools -> Python Platforms -> New 해서 c:\python25 를 선택하면 대부분의 값은 자동으로 채워진다. Python Path 탭으로 가서 앱엔진 라이브러리들을 등록해주자:
c:\google_appengine\lib\antlr3
c:\google_appengine\lib\django
c:\google_appengine\lib\webob
c:\google_appengine\lib\yaml\lib <-- 요기 끝에 lib 한 번 더 있다. 오타 아님.
6. 파이썬 프로젝트 만들기
File -> New Project 에서 Categories를에서 Python을 고르면 두가지가 있다:
Python Project
Python Project with Existing Source
설명할 것도 없고, 제목 그대로다. 사용할 파이썬 런타임 물을 때(Python Platform... 얘네들 플랫폼 참 좋아한다) 미리 등록해둔 Python 2.5.x를 선택하자.
7. 넷빈즈 안에서 dev_appserver.py 실행하기
일반적인 파이썬 프로젝트라면 여기서 끝인데... 앱엔진 프로젝트는 난관이 하나 더 있다.
(현재로썬)넷빈즈용 파이썬 플러그인은 현재 프로젝트 밖에 있는 모듈을 메인 모듈로 지정할 수 없다...-,.-;;;
그래서 밖에서(명령 프롬프트, cmd, 터미널, 콘솔... 머라고 부르던...) 실행 해야하는데... 이래서야 IDE라고 할 수 없다. 그래서 삽질을 좀 했다:
"Chrome Frame"이라는 이름의 IE 플러그인(Active-X)이 그것인데, 기술적으로는 Firefox의 IE Tab 확장과 비슷하지만, IE Tab은 사용자가 명시적으로 IE로 보겠다고 해야만 활성화되지만, Chrome Frame은 색다른(?) 접근 방식을 제안한다(물론, 두가지 방식 모두 Chrome Frame이 깔려있을때만 동작한다):
1. (사용자가) URL 앞에 "cf:"를 붙인다. 예를 들면 http://acid3.acidtests.org/ 하면 IE가 X같은 반응을 보이지만, cf:http://acid3.acidtests.org/ 하면 잘 된다.
2. (개발자가) HTML 페이지에 <meta http-equiv="X-UA-Compatible" content="chrome=1" /> 메타 태그를 달아놓으면 해당 페이지를 보는데 크롬을 사용한다.
첫번째 방식은 GUI 메뉴를 URL로 옮겨놓았을 뿐, 결과만 확인하고 넘어가자:
Chrome Frame 없이 IE8로 Acid3 테스트에 도전!
IE8을 가장한 Chrome으로 Acid3 테스트에 도전!
두번째 방식을 주목해보자. 이 방식을 사용하면 Chrome Frame 플러그인만 깔려있다면 자동적으로 활성화 된다. 그렇다면 Chrome Frame 플러그인만 자동으로(강제로) 깔 수 있으면... -.-ㅋ 뭔가 구린 냄새가 솔~솔~ IE로 인터넷 뱅킹이나 쇼핑몰 결제할 때만 되면 난리 법석을 떨던 ActiveX의 *랄 발광을 역이용(!)할 수 있다. 금상첨화(혹은 설상가상) 우리나라 사용자들은 ActiveX 설치할 때 "보안 경고"가 뜨면 무조건 "예"라고 해야 한다고 배워서 실천하고 있으니~ =..=
CFInstall.check() 함수는 기본적으로 지정한 노드(여기서는 placeholder)를 설치 페이지를 표시하는 iframe 태그로 바꾸서 설치를 유도하고, 설치가 끝나면 destination 페이지로 이동한다(자세한 설명은 공식 개발자 문서를 참조하시라~).
이런식의 스크립트를 웹 서비스의 진입부에 적당히 끼워넣어 두면... "부끄러운" 대한민국의 웹(한국 웹의 불편한 진실 참조)이 우리에게 강요했던 방식 그대로~~~ 크롬을 쓰도록 강요할 수 있다 -.-ㅋ
그런데, 구글은 이런걸 왜 만들었을까? 무엇보다도 구글이 만든 대다수의 초첨단(?) 웹 어플리케이션들을 돌리기엔 IE(6,7은 말할것도 없고 8도 도토리 기재기)의 렌더링 / 자바스크립트 엔진이 너무 구리기 때문일 것이다.
Chrome Frame이 널리 보급되기엔 넘어야 할 산이 많다. 첫째, 사용자 경험이 너무 거칠다. 플래시의 경우처럼 매끈하게(뭔가 설치한다는 느낌을 주지않고) 설치할 필요가 있다. 설치 유도 스크립트(CFInstall.js)를 많이 다듬어야 할 듯... 둘째, 다음으로 77M를 넘어서는 설치 용량이다. 사용자의 컴퓨터에 구글 크롬이 설치되어 있다면 이를 그대로 활용할 수 있을 것이다. 아마 조만간 그렇게 되겠지? 셋째, 아직은 버그가 많다. 첫술에 배부를 순 없겠지...
하지만, 개인적으로 prototype이나 jQuery 보다는 dojo를 선호하기 때문에(대부분의 경우엔 별 차이가 없지만, 마이너리티 체질의 똥고집이랄까...) dojo로 Lightbox를 만들기로 했는데... 웬걸 -.-; dojox.image.Lightbox라는 녀석이 이미 있더라. 그냥 쓸까 하다가... 이 녀석이 dijit(dojo의 위젯 시스템; jQuery UI 쯤에 해당하는 모듈이다)에 의존하는 관계로 버림받고 있길래 간단히 하나 맹그러봤다.
솔직히... 만만하게 보고 시작했는데... 생각보다는 많이 복잡하더라. -,.-;;;
이름은 Lightbox와 비슷하면서도 dojo로 만들었다는 느낌이 들도록 Delightbox라고 지었다 ^^;
2. xml-maven-plugin의 transform 골을 실행하여, 앞에서 풀어놓은 docbook 스타일 시트와 카탈로그들을 사용하여 xslt(여기서는 xalan을 사용했지만 saxon등 다른 xslt를 사용해도 된다)를 실행하여 fo 파일을 만든다. 예제에서는 generated-resources 페이즈에 src/docbook 디렉토리 아래에 manual.xml을 처리하여 처리하여 manual.fo인 파일을 만든다(parameters 요소를 사용하여 XSLT 파라메터를 지정할 수 있다):
3. maven-antrun-plugin의 run 골을 실행하여, fop를 실행하여 앞에서 만들어진 fo 파일들을 처리하여 pdf를 만들어 낸다. 이 부분은 maven에서 ant 스크립트를 사용하는 전형적인 형태다. 예제에서는 pre-site 페이즈에 fop에 포함된 ant task를 사용하여 manual.fo를 처리하여 manual.pdf를 만든다(userconfig 속성를 통해 fop 설정 파일을 지정할 수 있다):
명령을 실행하면 sourceDirectory(위의 예에서는 src/docbook) 아래에서 includes로 지정한 패턴(위의 예에서는 모든 하위디렉토리에서 -manual.xml로 끝나는 docbook 소스 파일을 처리해서 targetDirectory(위의 예에서는 target/docbook) 아래에 pdf로 만들어 준다.
위의 명령을 실행하면 sourceDirectory(위의 예에서는 src/fonts/truetype)안에 있는 *.ttf 파일들을 처리해서 targetDirectory(위의 예에서는 src/fonts/metrics)에 파일 이름 끝에 -metrics.xml을 붙인 메트릭 파일을 생성한다.
위에서는 코멘트 쳐둔 excutions절을 사용하면 빌드 과정에 포함시킬 수 있지만, 시간도 꽤 오래걸리는 작업이고, 큰 글꼴의 경우엔 out of memory도 잘 나고, 결정적으로 대부분의 한글 글꼴들의 경우엔 폰트 헤더의 인코딩 때문에 문제가 있어서 수작업으로 처리했다.(그래서 targetDirectory가 target/...이 아니고 src/...다)
덧. 수작업이라는 건 만들어진 메트릭 파일에서 <family-name>...</family-name>사이에 들어 있는 요상한 문자들을 좋은 편집기(절때 notepad나 eclipse같은 멍청한 편집기 쓰면 안된다!)로 열어서 알아보기 쉬운 영어로 고쳐주던가... <family-name> 태그 자체를 날려버리면 된다.
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키를 눌러 실행한다. 아직까지 풀스크린 디버거는 나오기 전이었지만, 이것만으로도 충분히(!) 감동적이었다.
를 하나의 틀 안에 포함하고 있는 통합 소프트웨어다. 그런 면에서 보면 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 얘기가 왜 없냐~든가)은 정중히 사절하는 바입니다.
웹의 탄생이전 부터 이어져오는 흐름을 정리한다는데 의미를 두고 보면 의외로 볼만할지도...*^^*
현재까지 Web3.0에 대한 논의는 시맨틱 웹, 플랫폼으로써의 웹, 그리고 유비쿼터스 세상으로의 관문으로서의 웹, 세가지 흐름으로 볼 수 있다. 물론 세가지 논의가 서로 간에 밀접한 관련이 있어서 무 자르듯 자를 수는 없겠지만...
IMHO, 시맨틱 웹은 내가 이 바닥에서 먹고 살 동안은 "The Dream of Web"으로 남을 것 같다. 유비쿼터스 웹는 돈독이 오른 가전 업체들의 말장난 단계를 벗어나려면 좀 더 시간이 필요할 듯... 가장 현실적인 것은 (구글이 밀고 있는) 어플리케이션 플랫폼으로서의 웹인 것 같은데, 이건 웹3.0이기보다는 웹2.5 정도가 적당할 듯.