Stutter Web Out
대충 web site out 기능을 만드는 중... 기본적인 원리는
이렇다...
아 졸라게 할 거 많다... 에러도 졸라 많고... 힘들어서 못해 쳐먹겠네... SQLite 에 Actionscript 에, PHP 에, CSS, Cross Browser 이슈들 까지 한꺼번에 덤비니깐 이 언어 하다, 저 언어하다 헷갈려 미쳐버릴 것 같다. AS 랑 JS 는 그럭저럭 비슷해서 할만한데, PHP 랑 같이 하니깐 뇌가 흔들흔들... AS 에다가 this-> 를 쓰고, PHP 에다가 $this. 를 쓰고...
대충 기본적인 web out 뼈대는 만들었기 때문에 이 기능들을 활용해서 기존의 내 홈페이지 구성들을 죄다 갈아치울 생각이다. 포트폴리오 데이터도 몽땅 옮겨놨기 때문에 옮기는데는 큰 무리가 없을듯...
문제는 IE 라는 이 빌어쳐먹을 브라우저인데... 다른 브라우저들하고 이 새끼만 차이가 나니... 아주 미쳐버릴 것 같다. 지금까지 한 작업들보다 이놈의 크로스 브라우저 맞추는게 더 짜증나...
아... 어쨌든 일단 뭐가 나오긴 나오는 시점이니 조금만 더 힘을 내자...
Stutter 1차 완성
아직 지뢰밭 상태일 것 같다는 느낌이 좀 들긴 하지만... 대충 쓰는데는 무리가 없어진지라 1차적인 완성을 해놓고, 현재 기존 컨텐츠들을 옮기는 중이다.
기본적인 프로그램의 목적은
- 위키언어를 통해서 프리젠테이션 양식과는 별도의 데이터를 구성한다.
- HTML, Flash, mobile HTML 등 어떤 플랫폼을으로든 파서를 구현한다. (그래서 다른 위키 언어들에 비해서 심각하다 싶을 정도로 단순하다는게 문제...;;;)
- 데이터는 하나의 폴더에 sqlite db 파일 하나와 첨부파일이 되는 폴더들로 구성되고, 이 데이터는 웹에 올린 다음 PHP 나 JSP 등의 서버 모듈과의 결합을 통해 보여질 수 있도록 한다.
- ===plugin=== 문법을 통해 javascript, actionscript 등으로 위키 언어를 확장시킬 수 있다.
뭐 대충... 위의 것들을 합치면 지금까지 내가 경험했던 "아 썅! 이놈의 글들은 써놓으면 플래시에 올리기도 애매하고, 홈페이지 리뉴얼 할때마다 스타일 수정하느라고 졸라 피곤해!" 가 될 것 같다... ㅡ ㄴ ㅡ;;; 애초에 홈페이지 만들다가 글관리가 왜이리 빡센가... 라는 짜증으로 부터 시작한 글관리 프로그램 이니깐... 뭐...
어쨌든 글의 원론적인 데이터를 아주 단순한 위키 문법을 써서 관리하고, 위키 언어의 불편함을 극복시키기 위해서 전용 프로그램을 만들었고, 데이터는 sqlite + 첨부파일이라는 단순한 형태로 존재하기 때문에 뭘로든 결합시켜가지고 view 를 다양하게 만들 수 있다... 는게 이 프로그램의 목적...
원노트나 에버노트와 같은 프로그램들이나 블로그툴 같이 졸라 좋은 프로그램들 보다 쬐끔 좋은 점은 프리젠테이션 서식에 독립적이라는 점과 데이터가 단순해서 간단한 프로그래밍으로도 다양한 활용을 할 수 있다는게 아닐까 싶다. (그거 하나 바라보고 몇 달동안 이 개고생을 해서 만든거니... 원 글 관리하기가 이렇게 힘들어서야... ㅜ ㄴ ㅜ)
뭐 아무도 참여할 것 같진 않지만... 어쨌든 소스가 공개되어 있는 프로그램...
http://dev.naver.com/scm/viewvc.php/trunk/?root=ssen
최하단의 Button 부터 Scroll, ScrollPane, Selector 등 모든 기능들을 죄다 개인적으로 만든 framework 를 사용해서 만들었더만 시간이 무진장 오래 걸려버린 케이스 이긴 하지만, 만들면서 왠만한 컨트롤의 작동 구조를 파악했다는 자산은 남았다.
위키언어를 새로 만들어서 진행하고 있고, 아직 파서가 Javascript 용 밖엔 없는데, 컨텐츠들에 대한 이주가 다 끝나면 Flash 와 RSS, PHP 용으로도 새로 만들 생각이다.
막상 다 만들고 나니 내가 왜 이 개고생을 했는지 의문이 드는 프로그램이기도 한데... 어쨌든 만들긴 만들었다는...
stutter
Stutter 라는 개인적으로 만드는 중인 wiki 언어의 데스크탑 관리자를 만드는 중이다.
AIR 로 만드는 중이고, 개인적으로 만든 framework 를 사용하고 있는 중이다.
원래는 web 쪽에 데이터를 두고, 데스크탑 관리자가 서비스를 호출해서 사용하는 방식을 할까 생각했었는데, 그냥 거꾸로 데스크탑 쪽에 데이터를 만들고, (sqlite 와 각 종 첨부파일들이 있는) 데이터 폴더를 ftp 로 올리면 php 가 해당 파일들을 읽어서 웹서비스가 되도록 하는 형태로 생각을 바꿨다.
대충 쓰고, 읽고 하는 부분들이랑 카테고리 관리자 까지는 만들었는데 자잘한 부분들이 아직 많이 남아있다.
이번달 안으로 어플리케이션을 완성시키고, 다음달 부터는 지금까지 내가 제작했던 모든 컨텐츠들을 이 stutter 기반으로 옮길 생각이다.
그다지 복잡하지 않은 프로그램인데 개인 framework 의 첫 적용 사례도 되는지라 framework 의 수정이랑도 겹쳐져서 작업시간이 꽤 걸리고 있다. 하여튼... 빨리 완성시켜야지...
web 은 죽었다?
web 은 죽었다... 라고 저기 미쿡인가 하는 나라의 유명한 잡지 편집장이 말을 했다고 말들이 많다.
과연 web 은 죽은걸까? 라는 이야기를 하기 이전에 중요한 것은 web 이 무엇인지 먼저 살펴볼 필요가 있지 않을까 싶다.
web 서비스를 분해해보면 그 요소들로 데이터와 HTML 이나 Flash 등 웹브라우저로 표현되는 프리젠테이션으로 나뉘어질 수 있지 않을까 싶다. 지금껏 web 서비스의 설계 라는 것은 이 두가지 요소가 밀접하게 결합되어 진행되어 왔기에 하나의 틀로 보였을 뿐이지, 사실상 jsp 나 asp, php 등 웹서버 서비스를 개발하는 개발자들은 "web 개발자" 라기 보다는 데이터 서비스의 원형을 개발하면서, 동시에 web 으로 프리젠테이션 되는 요소의 일부를 같이 개발하는 사람이었을 뿐이다.
web 대신 app 이 뜨고 있다는 배경에는 데이터 서비스의 프리젠테이션 요소로서 기존의 웹브라우저에 웹사이트 주소를 입력해서 보던 web 대신, 설치하는 app 이 사용되고 있다는 것이다.
그런 배경에는 몇가지 요소들이 작용을 하고 있다고 보는데
1 . 과거의 자잘한 사이트들이 난립하던 시대를 지나 트위터나 구글과 같은 거대 서비스 채널로 단순화 되고 있다
2 . 그로 인해서 web 이라는 이도저도 표현해야 하기 때문에 매우 "저수준의 표현능력 밖엔 갖추지 못했던" 프리젠테이션 채널 대신에, 아싸리 데이터에 최적화된 프리젠테이션을 보여줄 수 있는 app 이 선택되어 지고 있다는 것
3 . 채널이 단순화 되는데는 웹서비스 채널의 매스미디어화를 통한 "채널 선택권의 제한" 과 동시에 모바일과 같이 뭘 이것저것 하기엔 상당히 불편한 디바이스의 등장이 있을 수 있다.
대충 저런 이유들로 인해 사람들이 사용하는 웹서비스의 채널이 점차적으로 줄어들고, 그에 뒤따라 필연적으로 그런 서비스를 구지 "저급한 표현능력 밖엔 갖추지 못한 web 을 통해 보여주느니 차라리 app 으로 만들고 말지..." 라는 선택이 진행되어버리는데 있지 않을까 싶다.
이는 Flash 와도 연결이 될 수 있는 문제인데 이전까지 "저급한 표현능력" + "어플리케이션을 설치하게 되는데까지 걸리는 고생이 매우 높다" 라는 상황에서 표현능력의 증진을 위해서 Flash 가 사용되었던 시장 배경이 사라지고, 서비스 채널의 단순화와 앱스토어 시장의 활성화로 인해서 "사용하는 웹서비스 채널의 단순화로 인한 app 활용도의 강화" + "어플리케이션을 설치하는데 까지 큰 노력이 필요없다" 는 시장배경이 생겼다는 것을 의미한다. (즉... 사용되는 웹서비스 채널이 매스미디어 화 될 수록 플래시의 입지는 확연히 줄어들 가능성이 높고, 플래시의 죽음은 필연적이 되어버릴 수 있다.)
하지만, 프리젠테이션 채널이 단순히 웹브라우저에서 표현되는 html, flash 와 같은 기술에서 native app 으로 이동이 된다해서 web 이 죽은 것이다. 라는 이야기를 하기에는 무리가 있다고 본다. meta weblog api 와 같이 web url 을 기반으로 작동하는 api 서비스는 web 일까 아닐까? 라는 이야기가 되기도 하는 것이고...
앞으로의 서비스들은 지금까지의 웹서비스의 데이터 + 프리젠테이션의 결합도에서 벗어나서 데이터 서비스가 독립적으로 개발되고, web 은 그런 데이터 서비스를 2차적으로 활용하는 선으로 내려갈 가능성이 높다고 본다. 그러기 위해서는 데이터의 원형에 대한 정의내리는 표준안 역시 대대적으로 등장할 가능성이 높다고 본다.
현재 트위터 데이터 서비스 > 트위터 앱 서비스와 같이 직렬 연결을 가지는 서비스는 시간이 지나며 점차적으로 사라질 케이스가 될 것이라고 본다. 결과적으로 보자면 트위터, 버즈, 페이스북 > 데이터 서비스 표준 > 표준안을 수용하는 클라이언트 앱의 방향으로 갈 가능성이 높다고 본다. 뭐 서비스가 완전 윈도우처럼 완벽한 독점력을 가지는 서비스라면 특화된 클라이언트 기반이 될 가능성이 높지만, 사람들이 사용하는 서비스 플랫폼이 많아질 수록 데이터 표준안의 필요성은 더욱 더 커질 것이다. 트위터나 페이스북 같은 서비스들이 메신저와는 다른 면모를 가지는 이상 어쩔 수 없는 일이 될 것이다.
그리고, 만일 현재처럼 완벽한 독점력을 가지는 서비스들이 흐지부지 되고 이것저것 우후죽순의 서비스들이 늘어나기 시작한다면 app 기반의 데이터 소비는 사라지고, web 프리젠테이션 기반이 살아날 가능성이 높고...
app 과 web 의 차이는 단순하다. 데이터 서비스는 어짜피 뭘로 보든 상관없는 것이고... (하나나 보다 적은수의 서비스 채널에 특화된) app 과 (완전히 넓은 모든 서비스 채널을 포용할 수 있는) web 의 차이일 뿐이다.
이런 상황에서 사실 상 가장 득세할 사람들은 클라우드 데이터 서비스 개발자들이 아닐까 싶다. 아이폰 앱이다 안드로이드 앱이다 말들이 많지만, 그 모든 것들은 다양한 클라이언트과 서비스들의 판도변화에 빠르게 적응할 수 있는 포용력 있는 데이터 서비스를 개발할 수 있는가? 라는 데이터 서비스 개발자들의 능력이 돋보이게 될 가능성이 높다고 본다. 그리고, 가장 핵심에 가까운 분야일수록 벌이가 쏠쏠한 것 역시 사실이고... 클라이언트 개발자들이야 존나게 뛰는거지...
뭐... 생각은 있는데 쉽게 이야기 할 수 있는 주제가 아닌지라 삼천포로 빠지고 난리도 아닌데... 결론을 이야기 하자면
web 프리젠테이션은 전반적인 시장의 독점상황에 따라 죽거나 살 수 있는 문제이고, 현재의 흐름대로라면 html5 같은 기술은 시대착오적인 기술이 될 가능성이 높은 것이 사실이라는 것...
web 데이터 서비스는 현재의 web 프리젠테이션으로 직렬적으로 이어지던 기술의 흐름에서 벗어나서 점진적으로 open api 형태의 서비스로 변화될 가능성이 높다는 것... 여러 디바이스의 프리젠테이션을 포용할 수 없는 특정 프리젠테이션으로 직렬되는 서비스만 개발하는 서버 개발자들은 시대에 쓸려 떠내려갈 가능성이 높다는 것...
이런 상황에서 과연 web 은 죽은 것이라고 할 수 있는 것일까? 없는 것일까? 어느쪽에 포인트를 맞추느냐에 따라 틀릴 뿐이지, 결국 web 은 시대에 적응해 변화되는 것일뿐 web 의 사멸이라고 보기엔 무리가 있는 것일지 모른다.
그리고, 시대가 데이터 서비스의 병렬화와 특화된 클라이언트 app 들의 등장을 가르키는 것이 바로 "스페셜 리스트 + 폭넓은 이해력" 을 이야기 하는 것이라면, 이 상황에서 지금까지처럼 "이도 저도 전반적인 작업을 하는데 딱히 뭐라 하긴 힘든" 직렬적 서비스들을 개발하던 인력들은 시대의 청소대상이 될 가능성이 높을 것이다.
