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 라는 "신이 내려준 물리적인 법칙" 이 아닌, "인간이 최저 단위부터 만들어가는" 배경이 생기면서 그런 약속들은 많이 무너져 내리고 있다고 본다. 내가 겪었던 많은 프로젝트들의 실패에는 "물리적인 약속의 붕괴" 로 인한 파트간의 부조화가 상당히 큰 몫을 했던 것 같다. 즉, 일정한 약속이 없는채로 분업화가 생기면서 각각 "어떻게" 에만 치중해온 파트들이 잘못된 "어떻게" 를 바탕으로 일을 하게 되고, 그 어그러짐이 합쳐지면서 요소들이 아귀가 안맞으면서 붕괴되었다는 것이 상당히 큰 이유가 되었었던 것 같다.
도저히 개발되기 힘든 달나라 떡방아 찧는 것 같은 상식 밖의 기획서와 작동에 대한 기초적인 상식도 없이 그냥 그려버린 디자인이 부실공사를 초래하고, 그 부실공사가 실제 구현단이 되어버리는 개발에서 붕괴되는 현상은 지금껏 실패했던 모든 프로젝트에서 공통적으로 존재했던 문제들이고, 그 비중이 상당히 컸다.
그리고, 그런 이전 파트 작업들의 붕괴는 다른 파트의 "어떻게" 에 대해 상식에만 의존하는 것에서 부터 시작되는 경향이 높다.
물리적인 약속이 무너지는 시점이 되면서 "어떻게" 에 집중되던 직업 개념엔 "왜" 와 "무엇을" 을 생각해야 하는 시점이 되었다고 본다. 작업단위가 그간 "왜 > 무엇을 > 어떻게 > 어떻게 > 어떻게..." 와 같이 "왜" 와 "무엇을" 을 계획단에서 정하고 그 이후로는 무작정 "어떻게" 만 반복하는 개념에서 "왜" 와 "무엇을" 을 모든 파트가 공유해야 하는 상황이 되었다고 본다.
"누가" 와 "언제" 와 "어디서" 라는 것은 아직까지 계획단에서 잡아도 될만한 문제이지만, 가장 원초적인 이유가 되는 "왜" 와 어떻게의 이전 단계가 되는 "무엇을" 을 기술적 지식이 없는 계획단에서만 잡는 것은 이젠 상당한 리스크를 지니게 된다고 본다.
시대상황에서 "분업화를 바탕으로 한 산업시대" 는 이미 종말을 맞이 했다고 본다. 그것은 "생산 경쟁력" 을 위주로 한 "어떻게" 에 대해 집중한 전문가 시대가 끝났다는 것을 의미한다고도 할 수 있을 것 같다. 시대가 원하는 "보다 창조적인" 것에 대한 집중은 전반적인 상황을 살피고, "어떻게" 를 판단할 수 있는 인력을 필요로 한다고 할까...
신이 내려준 물리적인 제약은 모바일과 네트워크를 통해 공간이 붕괴되고, 터치스크린을 통한 센서의 간접적 활용이 늘어나면서 점진적으로 인간이 만들어낸 디지털로 인해 사라질 것이다. 즉... 이전까지 (나름 창조라고 깝쳤지만 알고보면 무진장의 물리적 제약속에서) 만들어지던 모든 것들의 상식이 붕괴되고, 가장 원론적인 단계에서부터 작업되어야 하는 상황이 된다고 본다. 그런 상황에서 "어떻게" 라는 가장 노동력을 크게 잡아먹는 요소에 대한 집중은 결국 "실패" 를 "재작업" 함으로서 해결하려는 기존의 패턴을 "원론적인 단계" 에서 부터 반복해야 하기 때문에 끔찍한 실패를 만들어낼 수 밖에 없는 실패의 수식이 되어버린다.
즉, "누가", "무엇을", "언제", "어디서", "왜" 라는 요소들에 대한 파악은 실패의 리스크를 줄여줌으로서 "어떻게" 라는 비용이 큰 단계를 절약할 수 있게 해준다. 그리고, 이런 "어떻게" 이전 단계가 이루어지기 위해서는 자신의 "어떻게" 에 대해서만 파악하는 점적 기술인력이 아닌 주변지식을 깔고 있는 범위적 기술인력이 뒷받침 될때 가능하고...
개발자 키워서 뭐할라고…
http://www.adobeflex.co.kr/iwt/blog/blog.php?mode=view&tn=flex&id=479
이 내용을 보면서 여러가지 생각이 들더라...
현재 소프트웨어 시장이 나락으로 빠지는 이유가 과연 인재부족 때문일까? 내가 보기엔 아니다... 프리랜서로 여기저기 돌아다니면서 일하지만, 프로젝트 대부분이 삽질에서 태어나서 그 삽질의 뒷감당을 하다 끝난다.
최초에 삽질을 안하기 위해서는 "이 비지니스에 어떤 기술들을 사용해야 할 것인가?" 라는 명확한 타겟팅이 필요하다. 개발자를 꾸역꾸역 키우고, 꾸역꾸역 투입해서 어쩔건데... 막상, 프로젝트에 투입되는 노동력의 2/3 가량이 "그럴듯하게 있어보이게 만드는데 촛점을 둔 비현실적인 문서를 구현하는데 쓰이거나, 아니면, 뭘 해야할지 갈피를 못잡아서 이것저것 유행따라 찔러보는 식으로 만들어진 기획을 구현하는데 쓰이는" 삽질에 들어가는 것을...
명확한 타겟팅은 개발인력의 노동력을 가치라는 딴딴한 근육으로 만들어준다. 애플의 제품들이 그렇다. 애플 제품들을 보면 쉽게 느낄수 있는 것들이 "의외로 안되는게 드럽게 많다." 라는 것이다. 기본적인 디바이스 부터 시작해서 OS 까지 안되는게 드럽게 많다. 하지만, 명확한 타겟팅으로 제품에 투자되는 노동력이 가치로 뭉쳐져서 나오게 된다. 명확한 타겟팅 없이 개발자만 틀어박는 것은 돌맹이 깨부시겠다고 두부 100모 만드는 것과 비슷하다. (돌맹이 하나면 두부 100모 따위 곤죽으로 만들 수 있다. 그게 바로 아이폰이다...)
개발자의 기술을 가치있게 쓰지 못하는 기획력의 부족 위에서는 개발자를 백날 키워봤자 산업의 비곗살 밖에는 되지 않는다... 개발자의 노동력의 대부분이 가치없는 것에 투자되는 상황속에서는 아무리 난리를 쳐봤자 산업의 근육이 되지 않는다.
산업 전반적으로 키워야 할 인력이 어떤 것인지 잘 갈피를 못잡고 있는 것이 아닐까 싶다. 개발자의 기술력은 이미 차고 넘친다... 정말 필요한 신규 인력은 소프트웨어 비지니스에 있어 "소비자에게 무엇이 필요할지 찾아내는, 그것을 소프트웨어 적으로 어떻게 풀어내면 될 것인지를 파악해내는" 그런 인력이다.
애플이 파는 것은 구슬을 꿰어 만든 목걸이다. 애플의 제품엔 생각보다 많은 구슬이 들어가 있지 않다. 보다 우수한 개발자를 만들어서 경쟁력을 갖추겠다는 지금의 모습은 말 그대로 구슬 더 만들어야 한다고 호들갑 떠는 것과 같다. 구슬도 꿰어야 보배라는데... 꿸 놈이 없다는 이야기다.
말 그대로... 전문 기획자가 필요하다. 파워포인트 잡고 앉아 있다가 프린터기 앞에서 문서 나오길 기다리는 그런 인력이 아니라... 비지니스에 필요한 현실적인 소프트웨어 형태를 만들어내는 제대로된 기획자가 필요하다. (더불어 포토샵 잡고 그림 그리는게 다가 아닌 전문 디자이너도 필요하다.)
소프트웨어를 가치 있게 만드는 방법으로 아직까지 개발에게 답을 찾고 있다면 아직 갈 길을 찾지 못한 것일지도 모른다. 소프트웨어 경쟁력의 중요성은 이미 Code 를 떠난지 오래다... 그리고, 그 경쟁력을 만들어내는데 필요한 진짜 인력은 아직 황무지 상태고...
Queue, Deque, Stack
polygonal ds 를 보면서 그간 몰랐던 지식들을 많이 알게 되는 것 같다. 그 중, 관심을 끄는 것들이 Queue, Deque, Stack 이라는 자료구조 인데, 1열의 데이터들을 순차적으로 처리하는 방법론들이 있다는 것이 꽤 흥미로웠다.
큐, 스택 뭐 이런 말들을 들으면서 "뭔소리지?" 했었는데 실제로 해보니깐 어려운 개념들은 아니더라. (정리가 된 개념이니깐 당연히 어렵지 않겠지...;;;) 어려운 개념은 아닌데 꽤 큰 도움이 되는 것 같다. 대충 이런것들을 알고 작업을 하다보니 데이터들의 순차처리 부분의 설계에 대해서 다시 한 번 생각하게 되더라...
Queue 의 개념은 선입선출의 개념으로 정리할 수 있을듯 싶고, Stack 은 선입후출, 후입선출의 개념으로 정리가 되는 것 같다. Deque 는 양방향이 뚫린 입출이 양방향적인 녀석으로 정리가 될 것 같고...
각 Queue, Deque, Stack 들을 넘버링 기반의 Arrayed 와 체인 연결 방식의 Linked 로 정리를 해놓았던데, x0, x1 의 교환을 시키는데는 Arrayed 가 더 나을 것 같고, x0 을 x1 의 앞으로 이동시거나 할때 그 중간 x 들을 미는 등의 액션을 시키는데는 Linked 가 더 좋을 것 같다는 느낌이 들었다.
뭐... 이런 유사한 개념들이 더 없는지 살펴보고 싶어졌다. 그간, 그림쟁이, 기획 출신으로 개발을 하면서, 그래픽스를 어떻게 표현하면 되는지에 대한 개념은 있었는데, 막상 그것을 정형화된 논리로 정리하는 것에 어려움을 많이 느꼈었는데, 이렇게 정리된 개념들을 파악하고 있다면 좀 더 손쉽게 개발을 할 수 있을것 같다는 생각이 든다.
발전의 여지가 아주 뚜렷한 꺼리를 발견한다는 것은 꽤나 즐거운 일인 것 같다.
