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 들의 등장을 가르키는 것이 바로 "스페셜 리스트 + 폭넓은 이해력" 을 이야기 하는 것이라면, 이 상황에서 지금까지처럼 "이도 저도 전반적인 작업을 하는데 딱히 뭐라 하긴 힘든" 직렬적 서비스들을 개발하던 인력들은 시대의 청소대상이 될 가능성이 높을 것이다.
육하원칙으로 생각해보는 직업
문득 똥싸다가 내가 하는 그림 그리고, 개발하는 기술직이란 걸 육하원칙으로 정리해보게 되었다.
기본적으로 기술직은 "어떻게" 의 비중이 높은 편이다. 최하로 "그림을 그린다" 나 "코드를 짠다" 라는 "어떻게"가 받쳐주지 않으면 애초에 모든 것이 가능하지 않은 상태가 되어버리므로, 지식적인 면에서 "어떻게" 에 매달리게 되는것이 지금까지는 당연하다 싶은 상황이었다.
하지만, "어떻게" 만 파들어갈 수 있었던 배경에는 다른 요소들에 대한 분업화가 뒷받침 되었었는데, 그런 분업화의 배경에는 다시 "물리적인 제약성" 을 바탕으로 한 규칙성이 존재했다. 즉, 물리적으로 "어짜피 이렇게 만들 수 밖에 없기 때문에" 그런 일정한 약속을 바탕으로 한 분업화가 가능했다고 본다.
최근들어 IT 라는 "신이 내려준 물리적인 법칙" 이 아닌, "인간이 최저 단위부터 만들어가는" 배경이 생기면서 그런 약속들은 많이 무너져 내리고 있다고 본다. 내가 겪었던 많은 프로젝트들의 실패에는 "물리적인 약속의 붕괴" 로 인한 파트간의 부조화가 상당히 큰 몫을 했던 것 같다. 즉, 일정한 약속이 없는채로 분업화가 생기면서 각각 "어떻게" 에만 치중해온 파트들이 잘못된 "어떻게" 를 바탕으로 일을 하게 되고, 그 어그러짐이 합쳐지면서 요소들이 아귀가 안맞으면서 붕괴되었다는 것이 상당히 큰 이유가 되었었던 것 같다.
도저히 개발되기 힘든 달나라 떡방아 찧는 것 같은 상식 밖의 기획서와 작동에 대한 기초적인 상식도 없이 그냥 그려버린 디자인이 부실공사를 초래하고, 그 부실공사가 실제 구현단이 되어버리는 개발에서 붕괴되는 현상은 지금껏 실패했던 모든 프로젝트에서 공통적으로 존재했던 문제들이고, 그 비중이 상당히 컸다.
그리고, 그런 이전 파트 작업들의 붕괴는 다른 파트의 "어떻게" 에 대해 상식에만 의존하는 것에서 부터 시작되는 경향이 높다.
물리적인 약속이 무너지는 시점이 되면서 "어떻게" 에 집중되던 직업 개념엔 "왜" 와 "무엇을" 을 생각해야 하는 시점이 되었다고 본다. 작업단위가 그간 "왜 > 무엇을 > 어떻게 > 어떻게 > 어떻게..." 와 같이 "왜" 와 "무엇을" 을 계획단에서 정하고 그 이후로는 무작정 "어떻게" 만 반복하는 개념에서 "왜" 와 "무엇을" 을 모든 파트가 공유해야 하는 상황이 되었다고 본다.
"누가" 와 "언제" 와 "어디서" 라는 것은 아직까지 계획단에서 잡아도 될만한 문제이지만, 가장 원초적인 이유가 되는 "왜" 와 어떻게의 이전 단계가 되는 "무엇을" 을 기술적 지식이 없는 계획단에서만 잡는 것은 이젠 상당한 리스크를 지니게 된다고 본다.
시대상황에서 "분업화를 바탕으로 한 산업시대" 는 이미 종말을 맞이 했다고 본다. 그것은 "생산 경쟁력" 을 위주로 한 "어떻게" 에 대해 집중한 전문가 시대가 끝났다는 것을 의미한다고도 할 수 있을 것 같다. 시대가 원하는 "보다 창조적인" 것에 대한 집중은 전반적인 상황을 살피고, "어떻게" 를 판단할 수 있는 인력을 필요로 한다고 할까...
신이 내려준 물리적인 제약은 모바일과 네트워크를 통해 공간이 붕괴되고, 터치스크린을 통한 센서의 간접적 활용이 늘어나면서 점진적으로 인간이 만들어낸 디지털로 인해 사라질 것이다. 즉... 이전까지 (나름 창조라고 깝쳤지만 알고보면 무진장의 물리적 제약속에서) 만들어지던 모든 것들의 상식이 붕괴되고, 가장 원론적인 단계에서부터 작업되어야 하는 상황이 된다고 본다. 그런 상황에서 "어떻게" 라는 가장 노동력을 크게 잡아먹는 요소에 대한 집중은 결국 "실패" 를 "재작업" 함으로서 해결하려는 기존의 패턴을 "원론적인 단계" 에서 부터 반복해야 하기 때문에 끔찍한 실패를 만들어낼 수 밖에 없는 실패의 수식이 되어버린다.
즉, "누가", "무엇을", "언제", "어디서", "왜" 라는 요소들에 대한 파악은 실패의 리스크를 줄여줌으로서 "어떻게" 라는 비용이 큰 단계를 절약할 수 있게 해준다. 그리고, 이런 "어떻게" 이전 단계가 이루어지기 위해서는 자신의 "어떻게" 에 대해서만 파악하는 점적 기술인력이 아닌 주변지식을 깔고 있는 범위적 기술인력이 뒷받침 될때 가능하고...
