[Info]Tags categorized posts and contents patterns..

[AJAX] Ajax Code E xamples.. [Book] About the book.. [CSS] CSS Code E xamples.. [DB] Sql Code E xamples.. [DEV] All development stor...

2016년 10월 19일 수요일

[NEWS] 자바스크립트 생태계 통합될까..

출처 : 지디넷코리아 임민철 기자

자바스크립트 관련된 뉴스가 눈에 띄었다.. 읽어보고 생각보다 괜찮은 내용이고, IT 일반적인 기술 내용이 기사 1면에 나왔다는 것이 신기하기도 해서 겸사 겸사 글을 갖고 왔다.. 다만, 내가 생각해서 쓴 글이거나 그런 부분이 아니기에 전체적으로 게시하지 않고 편집해서 게시한다.. 이하는 해당 내용이다.. 근데 자바스크립트라고 하니 왠지 햄이 떠오르는군.. ㅋㅋㅋㅋ..

■파편화는 필연?
짐작컨대 파편화는 2가지 현상을 뭉뚱그려 지칭하는 것 같습니다. 하나는 같은 이름을 쓰는 기술에 관련된 코드가 개발 및 구동 환경 측면에서 통일성이 없거나 약한 것입니다. 다른 하나는 기술을 다루는 개발자 커뮤니티의 경험과 지식이 모이고 쌓이기보단 산산이 흩어져서 참고하기 어려운 것이고요. 전자는 업계에 공인된 사실이고, 후자는 흔히 접할 수 있는 실무자의 고충입니다. 파편화를 논하는 게 이상해 보일지도 모르겠습니다. 자바스크립트라는 언어 자체는 일련의 국제 표준(ECMAscript)에 기반하니까요. 하지만 어떤 프로그래밍 언어가 잘 정리된 표준에 기반해 만들어졌다는 사실과, 그 언어를 사용해 프로그래밍을 하는 환경은 전혀 별개 사안입니다.

일단 사용자들이 쓰는 각 브라우저 개발사가 저마다의 자바스크립트 엔진을 구현하고 있죠. 브라우저 종류와 버전에 따라 같은 코드가 다른 결과를 내는 게 현실이에요. 또 개발언어의 형태를 변형하거나 기능을 확장한 (슈퍼셋) 언어, 또는 기존 버전을 보완하기 위한 수많은 라이브러리가 있고요. 활용 범위에 비해 그에 내장된 함수같은 게 부족하다는 지적에 시달려 온만큼 그걸 보완할 수단이 필요했거든요.

한 마디로, 서비스 운영 환경이나 개발 의도에 따라 자바스크립트 코드가 돌아가는 사용자 환경도, 개발 도구와 환경도 제각각이라는 겁니다. 그래서 자바스크립트라는 공통분모를 제외하면 실용적인 단일 접점을 찾기 어려울만큼 거대하고 파편화된 커뮤니티가 형성됐고요. 자바스크립트 전체 생태계를 관통하는 뚜렷한 구심점 없이 다양한 현장의 개별적인 문제 해결 수단이 자생한 결과라 볼 수 있겠네요.

■리눅스재단, JS재단 출범 "자바스크립트 오픈소스 키우겠다"
리눅스재단이 지난 17일부터 영국 런던에서 열리고 있는 유럽 오픈소스컨퍼런스(OSCON Europe)에서, 자바스크립트 기반 웹 애플리케이션과 서버 측 애플리케이션 개발 기술에 관련된 오픈소스 프로젝트를 육성하겠다는 구상을 제시했거든요.

공식 발표에 따르면 리눅스재단은 컨퍼런스 현장에서 'JS재단(JS Foundation)'이라는 이름의 비영리조직을 통해 여러 자바스크립트 관련 오픈소스 프로젝트 후원에 협력하겠다고 선언했습니다. 주요 웹 기술 업계에서 널리 활용되고 있거나 전도유망하다고 판단한 프로젝트를, 리눅스재단의 우산 아래 적극 밀어주겠다고 나선 모양새죠.

JS재단 발족과 함께 공개된 첫 후원 대상은 23가지입니다. 저마다 자바스크립트 개발 영역에서 이미 인지도를 얻은 오픈소스 프로젝트입니다.

■JS재단, 파편화 해결 실마리?
영국 IT미디어 더레지스터는 이 소식을 다음과 같이 전했습니다. "자바스크립트 프로젝트들의 위용을 키워줄 프로젝트가 리눅스재단에 의해 발족했다. JS재단이 자바스크립트 애플리케이션과 서버측 프로젝트를 육성한다. 광범위한 자바스크립트 기술 채택과 개발을 주도하고 협력을 촉진하기 위한 중심에 두려는 의도다. JS재단은 개발자와 툴 제작자가 빠른 변화 추세를 받아들이도록 도울 것이다."

미국 지디넷은 "(JS재단은) 고품질 표준과 장기적인 지속가능성을 장려할 모범사례와 정책을 촉진함으로써 자바스크립트 애플리케이션 및 서버측 프로젝트를 돕기로 했다. …(중략)… 자바스크립트 개발자는 발전하나 뒤죽박죽인 오픈소스 기술 포트폴리오에 의존해 핵심 애플리케이션을 만들고, 테스트하고, 배포한다. 재단 목표는 핵심 자바스크립트 솔루션과 관련 기술의 광범위한 채택과 개발 진척을 주도하는 것이다."

공식 발표 내용과 외신들의 이런 관측으로 짐작해 보면, JS재단을 통해 선별된 오픈소스 프로젝트는 상대적으로 그렇지 않은 프로젝트나 기술에 비해 커뮤니티의 관심과 지원을 이끌어내는 데 유리할 것 같습니다. 다종다양한 오픈소스 프로젝트로 어수선한 자바스크립트 생태계가 공신력을 갖춘 후원자의 선별을 통해 정리되는 결과를 맞을 지도 모릅니다.

■다양성 위협 여지에 주목
경쟁관계에 있는 자바스크립트 기반 오픈소스 프로젝트 중 하나가 JS재단의 후원 대상이 될 경우 빠르게 사용자층을 늘리고 참여 개발자 생태계를 확대할 수 있습니다. 시장관점에선 독점 사업자간 경쟁으로 묻히는 기술에 비하면, 소외된 오픈소스 기술을 쓰더라도 사용자 부담이 적겠죠. 사용자 입장에선 장기적으로 기술 난립의 혼란을 줄일 수도 있고요. 하지만 다른 성숙된 오픈소스가 소외될 가능성도 있습니다.

JS재단은 여느 오픈소스 후원 재단처럼 비영리조직을 표방했습니다. 재정을 충당하는 회원사뿐아니라 다른 웹기술 표준화 조직과도 협력한답니다. 글로벌 웹표준화기구 '월드와이드웹컨소시엄(W3C)'과, 브라우저 개발업체간의 웹기술표준화 협력 커뮤니티인 '웹 하이퍼텍스트 애플리케이션 기술 워킹그룹(WHATWG)'과, 서버측 자바스크립트 프레임워크 기술 커뮤니티의 주축인 '노드JS재단' 등과도 일한다 하고요.

앞으로 W3C와 WHATWG와 노드JS재단을 비롯한 수많은 웹기술 관련 단체와 소속 회원사와 거기서 일하는 개발자와 외부 개발자 커뮤니티를 아울러 많은 눈들이 JS재단을 지켜보겠죠. 삼성전자나 IBM을 비롯한 회원사들에겐 저마다 JS재단을 지렛대 삼아 사업적 이익에 맞물리는 방향으로 자바스크립트 생태계를 이끌려는 바람이 있을텐데, 그 바람이 생태계 전체에 도움이 된다는 걸 입증할 의무도 있으니까요.

2016년 10월 18일 화요일

[Book] 린 스타트업..

출처 : Outsider's Dev Story https://blog.outsider.ne.kr/

린 스타트업 - 8점
에릭 리스 지음, 이창수.송우일 옮김/인사이트

이 책은 린 스타트업 운동을 만든 에릭 리스(Eric Ries)가 린스타트업에 대해서 설명한 책이다. 린 스타트업은 도요타의 린 방법론에 착안(아마도?)해서 스타트업에 적용한 방법론이도 에릭 리스가 3D 아바타 채팅 서비스를 만드는 IMVU라는 스타트업에서 일하면서 배우고 알아낸 것을 시작으로 린스타트업을 본격적으로 연구하게 되고 이 책은 그 결과인 린 스타트업에 대해서 정리한 책이다.

요즘의 추세대로 린 스타트업도 애자일과 비슷한 면이 있다. 애자일이 개발부분에 포커싱이 되어 있다면 린 스타트업은 이러한 부분이 스타트업이라는 사업 분야까지 확장되어 있기 때문에 평소에 이러한 부분이나 애자일에 관심이 있다면 완전히 새로운 개념을 얘기해 주거나 하진 않겠지만 에릭 리스의 경험과 연구를 하면서 다른 회사들로부터 얻어낸 사례등을 통해서 꽤 정리가 잘 되어 있고 사업적으로 생각할 수 있는 많은 관점을 제공해 주고 있다고 생각한다. 여러 모로 인상깊은 부분이 많이 있었다.

에릭 리스는 린 스타트업을 지속적인 혁신을 만드는 새로운 방법으로 정의하고 있고 여기서 말하는 스타트업을 우리가 일반적으로 얘기하는 소규모로 새로 시작해서 도전한 회사들만을 얘기하는 것이 아니라 극심한 불확실성 속에서 새로운 제품과 서비스를 만드는 조직을 모두 스타트업으로 정의하고 있기 때문에 대기업이라고 하더라도 비슷한 도전을 하고 있는 조직은 린 스타트업을 적용할 수 있다고 얘기하고 있다. 그래서 린 스타트업은 창업가는 어디에다 존재할 수 있고, 스타트업은 제품만으로 성공할 수 없으므로 창업가의 정신은 관리이고 유효한 학습을 계속 할 수 있어야 하며 만들고 측정하고 배우는 과정을 최대할 빨리 반복하면서 혁신 회계에 집중해야 한다.

그리고 에릭 리스는 기존의 스타트업들이 실패하는 이유를 시장조사나 정교한 전력/기획등에 현혹되서 이를 성공의 지표로 여겼고 기존 경영방식의 실패를 보면서 "일단 해보자"라는 방식에 길들여졌기 때문이라고 보고 있다. 스타트업을 만든다는 것은 조직을 만드는 것인데 기존의 관리 기법이 창의성을 죽여버릴까봐 걱정하는 경우가 많은데 오히려 "일단 해보자"라는 방식이 조직을 혼란스럽게 만드는 경우가 많다는 것이다.

린 스타트업은 책 내내 "만들기-측정-학습"의 과정을 강조하고 있는데 여기서 중요한 것은 유효한 학습이어야 한다는 것이다. 그래서 어떻게 측정하고 상황에 따라 어떤 측정 경과를 보고 어떤 부분은 조심해야 하는지를 설명하고 실패해도 학습했으니 괜찮다는 변명을 주의하라고 하고 있다. 즉, 결과가 나온 후에 끼워 맞추거나 실패를 감추는 것이 아니라 극심한 불확실성 속에서 성과를 측정하기 위한 까다로운 방법론이라는 것이다. 그래서 어떤 부분이 가치를 창출하는 부분이고 어떤 부분이 낭비인지를 찾는 것이 중요하고 "얼마나 많이 만들었느냐"가 아니라 "얼마나 제대로 된 학습을 했느냐"를 가지고 생산성을 측정해야 한다는 것이다. 회사를 바쁘게 움직이게 하는 것이 목적이 아니라 정말 필요한 일에만 하게 하는 것에 집중하게 해야 한다는 말은 특히 많이 와닿았다. 그러면서 예를 든 것이 어떤 기능을 몇개월에 걸쳐서 개발해서 공개했더니 소비자들이 원하지 않는 기능이었다는 것이었다.(실제로 바쁘고 열심히 했지만 그것 자체가 의미 없었다는 얘기다.) 그래서 린 스타트업에서는 "만들기-측정-학습"의 과정을 빠르게 반복하는 것을 강조하고 있고 MVP(minimal viable product)가 그 핵심 중 하나이다.

그리고 스타트업은 "이 제품을 만들수 있을까?"하는 것이 주요 질문이 되기 보다는 "이 제품이 과연 만들 가치가 있는가?", " 이 제품과 서비스를 기반으로 우리가 지속가능한 사업을 만들 수 있는가?"가 되어야 한다.(여기에는 무척 공감한다. 이 질문이 선행되어야 어떻게 만들지.. 혹은 그 방법이 안되었을 때 다른 방법으로 해결할 수 있을지를 고민할 수 있다.) 그래서 가설을 실제 과학적으로 테스트하면서 실험을 하고 이 실험으 목표를 비전을 바탕으로 지속가능한 사업을 구축하는 방법을 찾는데 있다. 책에서 모든 스타트업이 정기적으로 "방향을 전환할 지 아니면 고수할지"에 대한 회의를 진행하는 것을 권장하고 있다. 에릭 리스의 경험에 따르면 수주이내면 너무 잦고 수개월 이상은 너무 뜸하다고 하는데 이런 회의를 정기적으로 하는 것은 참 좋은것 같다.

린 스타트업의 목적은 제품을 더 효율적으로 만드는 것이라기 보다는 "지속 가능한 살업을 만드는 방법"을 최대한 빨리 배우는 것이다. 대기업이라면 내부 혁신팀이 자리를 잡아가면서 실험을 지속해 나갈수 있는 플랫폼을 만들어야 하는데 이런 것들은 모두 최고 경영진의 책임이다. 린 스타트업에 대한 실천적인 방법도 여러가지로 제시하고 있는데 인상적인 것은 큰 일괄 작업 크기를 줄이라는 것이다. 여기서 큰 일괄작업 크기라는 것은 제품의 완성형이 나오기까지 돌아가는 프로세스를 얘기하고 이 부분이 클수록 중간에 잘못되었음을 깨달았을 때 작업 크기가 너무 커서 오히려 비효율적이 된다는 것이다. 이 부분은 오히려 시스템의 문제인데 이를 줄이기 위해서 더욱 더 큰 작업 크기를 요구하는 악순환이 된다는 것이다. 그리고 다섯번 '왜'라고 묻는 과정을 권장하고 있다. 이는 도요타에서 사용한 방법인데 어떤 문제가 발생했을 때 그 문제가 왜 발생한 것인지 다섯번 물어봄으로써 그 문제를 막기 위한 근본적인 해결책을 찾는 과정인데 참 괜찮아 보인다.
책에서 많은 이론적인 설명과 함께 실천적인 얘기도 하고 있어서 유용하지만 당연히 다루는 문제 자체가 쉽지 않으므로 이 책대로 한다고 성공한다거나 그러진 않을 것이다. 각 회사나 조직마다 자신만에 맞는 방법을 찾아가는 과정이 필요하겠지만 이 책이 얘기하는 부분은 여러가지로 곰곰히 생각해 볼만 하다고 생각하고 조직을 이끄는 사람이라면 읽어보라고 권하고 싶을 정도다. 마지막으로 이 책에서 에릭 리스는 "린 스타트업은 틀이지 따라야 할 청사진이 아니다"라고 얘기하고 있다.

몇가지 책에서 인상적이었던 부분을 얘기하자면...
몇년 전 큰 미디어 회사에 제품을 판매하는 어떤 스타트업이 자기네 엔지니어들이 별로 열심히 일하지 않는 것 같다고 자문을 요청한 적이 있다. 하지만 문제는 엔지니어링 팀에 있지 않았다. 문제는 의사 결정을 하는 회사의 프로세스에 있었다. 고객은 있었지만 고객을 잘 이해하지 못하고 있었다.
실수가 생기면 그 실수를 저지르기 쉽게 만든 우리가 부끄러운 일이다.
1. 첫실수에는 전부 관대하라.
2. 가능한한 실수를 두번 하게 하지 말라.
"전혀 해서는 안 될 일을 매우 효율적으로 하는 것만큼 무용한 짓은 확실히 없다." - 피터 드러커

My Comment..
흠.. 이런 것도 있었구나.. 햄이 올려둔 지식들을 보다보면, 신기한게 많다.. 이 책도 그런 부분중에 하나다.. 참 많은 것을 알게 해주는 햄이다.. 대단하심.. ㅎㅎㅎ..