InfoQ 내의 기사/칼럼 요약

1. Comparing Apple, Google and Microsoft (정의윤 대리 요약, 2011년 1월)

오늘날 어떤 위치에 서있고 서로 어떤 영향을 미치는지에 중점을 두면서 가트너는 Apple, Google and Microsoft를 비교

가트너에서는 " Google vs Microsoft: The Battle for future Dominance라는 이름으로 애플과 구글과 마이크로 소프트를 그들의 특징/현재 재정상태/미래전망에 대해서 다룸

 

애플은 다음 특징을 강조함
- 애플은 고객중심의 회사이다. 고객이 가장 중요하고 두번째가 기업의 이익이다.
- 애플은 디자인과 UX에 초점을 맞춘다.
- 두개의 주요 os는 : Mac OS X와 iOS
- 애플은 그들 자신의 클라우드 데이터 센터를 만든다는 소문이 있다.
- 모바일 공간에서 구글에 반응하기 위해 광고 비즈니스를 침투하려고 노력한다.

 

구글은 다음과 같음
- 구글은 민주주의적 정보의 비즈니스다.
- 그들은 20억 사용자에 초점을 맞추고 , 기업이익은 그 다음이다.
- 드러나지 않은 방해물에 대한 걱정을 많이 함 - 네트워크 제공자, silverlight같은 RIA solution , OS제공자 (MS나 apple같은)
- 새로운 클라우드 인프라를 짓고 있다- 급진적인 혁신자 이미지
- 구글의 검색 인프라는 다른 서비스에서도 많이 쓰이고 있고 실제로 이들은 아무것도 없는데서 시작함. 그들 자신의 마더보드를 설계하고, 네트워크 솔루션을 사용하고 분산시스템을 사용한다.

 

마이크로소프트는 다음과 같음
- 민주주의적 기술을 가지고 비즈니스를 함. 모든 집에 있는 오래동안 PC가 이 회사의 비전이었다.
- 그들은 회사이익을 주 초점으로 맞추고 그것을 잘 관리해왔다.
- 윈도우와 오피스를 중심으로 확장하려고 시도하고 있다. 구글의 뒤를 따라서 검색과 광고 산업에 들어감
이에 대해서 구글도 MS가 그들의 영역에만 집중하고 검색과 광고에 초점을 맞추지 않도록 OS와 엔터프라이즈 시장에 들어감.
이 전쟁은 마이크로 소프트가 이기기 위해 쓰는 돈이 훨씬 많기 때문에 비대칭이다.
- 구글은 프로젝트를 쉽게 시작하고 사용자가 별 반응이 없으면 버리는 반면 마이크로소프트는 지속적으로 추진하고 관리한다.

 

여기에 따르면 MS와 구글은 재정적으로 현재 잘하고 있지만 성장하진 못하고 있어서 계속 새로운 기회를 찾고있다.
MS가 검색과 광고비즈니스, 클라우드 컴퓨팅 시장을 원하는 반면, 구글은 예상할 수 없다.
그들은 여러가지 툴들을 짓고 있고- 크롬, 체크아웃, 분석기, 유투브, gmail등등 -
엄청난 사용자의 데이터 정보- ip, 위치, 검색히스토리, 웹방문기록 등등를 가지고 있어서
정보의 민주화를 어떻게 주조해 낼 것인지 기대된다고 한다.
애플은 반면에 지난 몇년동안에 폭풍적인 성장이 있었다. ipod과 iphone, ipad는 모두 회사에게 큰 이익이 되는 창조적인 역할을 하였다.

 

2. Google Releases the High Replication Datastore for App Engine (이명도 사원 요약, 2011년 1월)

 Google에서 Google App Engine Datastore 이후로 새로운 Datastore를 오픈했다.

High Replication Datastore라 불리는 이 서비스는 고성능 읽고 쓰기가 가능하고,

RDBMS의 추상 tuple과 NoSQL의 row-column storage 비슷한 데이터 모델을 정의하고 있다.

또한 transaction에 의해서 값이 적용될때를 위해, row/column 한쌍에 서로 다른 timestamp값을 가지고 복수의 값을 저장할 수 있는 기능도 있다.

3. Orion- Eclipse for the Web (정의윤 대리 요약, 2011년 2월 )

이클립스 설립의 디렉터였던 Mike Milinkovich는 Orion이라는 새로운 툴을 발표함
이는 새로운 버전의 이클립스라며 브라우저 기반의 환경을 제공할 것이라고 말함. 2월초에 마일스톤이 릴리즈됨

이클립스는 가장 많이 사용되는 개발환경인데 이의 성공중에 가장 큰 용요인은 오픈소스 플랫폼이 제공하는 확장성
다양한 개발자들이 그들의 애플리케이션을 이클립스에 올릴수 있음..
하지만 웹 기반 애플리케이션은 개발자의 컴퓨터에 설치해야만 하는 IDE를 사용하는 시대착오적인 것이 나타남
웹기반IDE는 사용자에게 설치노력이 거의 없고, 서버플랫폼 의 확장성, 단순한 연결등의 이익이 있을 것이다.

Orion은 Eclipse플래폼을 웹으로 옮길 의도이다. 이전 이클립스와 대조적으로 자바스크립트 같은 것도 사용할 수 있고, 클라이언트 사이드에서 웹 개발을 위한 브라우저 기반 툴이다.

Orion의 서버사이드는 웹컨테이너로써 Jetty를 사용해서 OSGi기반으로 구성되었다.
클라이언트와 서버간의 통신은 RESTful API를 사용

Mke의 블로그에는 긍정적인 반응이 많다. 하지만 모든 사용자들이 온라인 버전의 이클립스를 받아들이는 건 아니다.
Zviki Cohen은 대부분의 온라인 IDE가 특수화된 백엔드 프로그래밍 서비스 뿐만 아니라 자산을 위한 웹개반 클라이언트이다.

Mike Milinkovich에 따르면 3월초에 캐나다 오타와에서 위임자들과 Oron의 나아갈 방향과 로드맵에 관한실질적인 미팅이 있을 것이다.

4. Virtual Panel: How to Survive Asynchronous Programming in JavaScript (이명도 사원 요약, 2011년 1월)

Javascript에서는 쓰레드가 하나이기 때문에 비동기 프로그래밍을 사용한다.
그런데 application의 스케일이 커지고 하다보니 여러가지 문제들이 생긴다.
그래서 InfoQ에서 7개의 JavaScript 라이브러리 (Step, Flow-js, node-promise, Async, Async.js, FuturesJS, slide-flow-control)에 있는 전문가(?)와 인터뷰를 했다. 

인터뷰 내용은 (1) 각각의 라이브러리가 중점적으로 다루는 문제 (2) CS research를 통해 얻은 정보를 기능을 구현하는지 (3) 어떤 에러 핸들링 전략을 제공하는지 

(4) F#' Workflows, Rx 또는 다른 프로젝트에 영향을 주고 받는지 (5) 라이브러리를 더 발전시키기 위한 새로운 JavaScript 의 특징이나 변화가 있는지. 같은 내용이 있다.

5. Using JQuery Mobile and JSON to Create Mobile Application ( 정의윤 대리 요약, 2011년 3월)

모바일 앱 개발이 최근에 큰 화두가 되고 있다. 다는 아니라도 대부분 모바일앱은 기존의 데스크탑 개발 플랫폼을 많이 채택하고 있다. 웹 기반 프레임웍도 다르지 않다. 

JQuery는 모바일 앱을 위해 많이 채택되고 있다.(지난달에 Jquery Mobile Alpha 3가 릴리즈 되었음)

모바일개발에 있어서 하나의 주요한 화두는 사이즈다.

Aaron Quint가 설명하길.. JQuery는 4~50K정도, 추가로 UI나 애니메이션을 위해 100K정도로 압축할 수있다. 하지만 JQM alpha 3를 사용하면 좀더 약 17K정도로 줄일 수 있다.

Enrique Ortiz는 JQM의 장점을 다음과 같이 나열하였다.

• 간단함 - javascript를 최소한이나 사용하지 않고 개발 가능함

• 점진적인 향상과 우아한 성능저하(graceful degradation)

• 접근성 - Accessiblle Rich Internet Application을 지원

• 작은 사이즈

JQM을 설치하는건 하나의 stylesheet와 3개의 javascript를 추가하면 끝이다.(간단함)

게다가 JQM의 모바일에서의 가장 큰 장점중 하나는 AJAX에 대한 사용성이다. 

JQM으로 설계된 Web 애플리캐이션은 페이지 전환 시에 각 페이지를 대체하기 보단, 페이지의 DOM으로 관리한다. 

이건 실제로 HTML5의 data-* 로 시작하는 attribute때문에 가능해진다. 

JQM은 그것의 core 함수들을 위해서 이들의 data-role attribute를 사용했다고 한다.

JQM은 올해 전반기에 나올것으로 보인다.

6. QCon Keynote: Innovation at Google  (김명구 팀장 요약, 2011년 3월)

Qcon에서 나온 Keynote 자료입니다.

제목에서 알 수 있듯이 Patrick Copeland 란 사람이 구글의 innovation 문화에 대해 얘기하고자 하는 것 입니다.

이  사람은 구글 내에서 Engineering Productivity Group의 leader라고 하는데 우리로 따지면 생산성혁신팀 비슷할 듯  합니다.

(MS에 11년 있던 분이라고 하니 회사에 MS 출신 분들 중아시는 분이 있으실 지도 모르겠습니다.)

여기서는 일단 Pretotyping Manifesto 라는 걸 얘기합니다.
Pretotyping은 처음에 prototyping을 잘못 적은 줄 알았는데 그게 아니랍니다.
http://www.pretotyping.org/

위 링크 가보면 설명이 있는데, 요는 세 제품을 만들때 극단적으로 간단한 버전을 적은 비용으로 빠르게 만들어서 제품 아이디어를 빠르게 테스트해 보자는 것입니다.

prototyping 하고는 좀 다르다는데, 컨셉은 prototyping 보다 더 간단하게 (예시를 보면 mock 에 가깝게) 만들고 simulation 해 보라는 것 같습니다.

(접두사 pre는 pretending에서 따 온 것 같습니다.)

아무튼 이 Pretotyping Manifesto는 다음과 같습니다.

* Innovators Beat Ideas 

  : innovator가 idea를 이긴다.
   요는 혁신적인 idea보다는 '혁신적인 사람(innovator)'이 훌륭한 혁신을 이루는데 중요한 요소라는 것입니다.
   그리고 휼륭한 innovator는 열정과 기술과 끈기를 가지고, 아이디어를 고르고, 버리고, 프로토타이핑해 가면서 괜찮은 게 나올때까지 열나게 노력할 수 있는 사람이라는  것입니다. (물론 드물지요.)

   백날 혁신적인 idea가 넘쳐봐야 그걸 실현해 낼 수 있는 사람이 없으면 혁신을 이루지 못하는 것이고, 그런 사람이 혁신적 idea보다 더 중요하고 귀하다는 얘기가 되겠습니다.

   innovator % idea 하면 0 에 수렴한다는 얘기도 합니다.

* Pretotypes Beat Productypes
 : Pretotype(앞서 설명, 제품의 시뮬레이션)이 productype (어느정도 동작하는 prototype의 개념인 듯)을 이긴다.
  여기서는 한때 잘 나갔던 Palm pilot을 만들때의 사례를 얘기합니다.
 

  말하자면 오른쪽의 나무 조각에다가 대충 그린 것이 pretotype 입니다.
  장난하냐...싶기도 한데, 실제 저런 mock device를 사용한 시뮬레이션이 효과가 크다고 주장합니다.

  실제로 저렇게 만들어서 실제 기계...다 생각하고 실 생활에서 상상하면서 써보고 하면서 만들어진게 palm pilot 이라고 합니다.

  요는 만들수 있을까...를 테스트하지 말고, 만들어지면 실제로 사용할까?를 먼저 테스트 해야 한다는 게 핵심입니다.

  이게 왜 유리할까는 직접 생각해 보시기 바랍니다.

* Data Beats Opinion 

 : 데이타가 의견을 이긴다.

 잘 만들고 있다가 아니라 '옿은 것을 만들고 있다'는 것을 알려면 데이타를 활용해야 한다고 주장하는 내용입니다.

 예시로 초기부터 정 주기마다 사용자들이 얼마나 남아 있느냐를 데이타로 활용하라고 하는데, 흥미로운 것은 실패 사례로 구글 이브를 들고 있습니다.

 (구글이 의사결정에 데이타를 중시한다는 것은 이미 잘 알려져있습니다만, 사실 이 부분은 개인적으로 크게 공감이 가지 않는 부분 입니다.

 데이타가 잘못 사용될 때 개인의 직관을 억압하는 경우를 많이 봐왔고, 때로는 특정인의 직관에 따른 결정을 옹호하기 위해 데이타가 억지로 만들어지는 경우도 흔하기 때문입니다.)

 

 이렇듯 요는 구글의 극단적인 innovation은 pretotype manifasto의 3가지 항목에 기반하고 있다는 내용이 되겠습니다.
 (이거 말고도 더 있다고 합니다.)

 하지만 소개 내용을 보시면 아시겠지만 꼭 구글의 사례만으로 한정할 필요는 없을 것 같습니다.

  암튼 볼만하고 재미있습니다.

 링크 누르면 영상과 프리젠테이션이 같이 있으니 한번 보시길 권하고, UX쪽에 아는 사람들에게도 공유해 주심 좋겠습니다.

 

7. Product Owner Pattern (정의윤 대리 요약, 2011년 3월)

 스크럼의 Product Owner(제품책임자)역할은 많은 온라인 포럼과 블로그에서 논의되고있다. 최근에 Product Owner가 Agile 프로젝트에서 해야하는 공통적인 역할에 대해서 논의된 적이 있다.

Mary Poppendiek은 "The Product Owner Problem"에서 이렇게 언급했다.

제품을 짓는데 올바른 길을 찾는건 좋은 제품을 창조하는데 가장 중요한 step이다. 잘못가면 그 과정은 100%낭비에 불과하다. 

한사람의 Product Owner가 대표되는 결정을 하는 것은 마치 매우 중요한 개발팀의 일을 기술이나 지식이 별로 없는 개인이나 팀에게 아웃소싱을 주는 것이다.

그녀는 Product Owner의 다양한 역할과 책임에 대해서 논의하였다.

Scrum Product Owner는 하나의 역할일지도 모르나, 그것은 Job title이 아니다. Product Owner는 많은 역할을 가지고 있다. - 제품관리자, 시스템 엔지니어, UI디자이너, 소프트웨어 아키텍쳐, 비지니스 분석가, QA전문가, 심지어는 Technical Writer까지. 

우리는 관점을 흐리게 만들수 있는 새롭고 애매모호한 타이틀보단 이들 잘 알려진 역할을 사용함으로써 일을 더 잘할수 있다.

비슷하게 John Mansour는 Product Owner와 Product Manager역할 사이의 혼란에 대해서 말하고 있다. 그는 "Agile Product Owner - New Name, Same Old Problem"의 블로그에서 두가지 역할에 대해서 말하고 있다.

1. what & why역할 - 어떤 기능이 제품에 들어가야 하고, 왜 비지니스 측면에서 필요한지에 대해서 책임지고 있다. 이들은 내외적으로 모든 inputs들의 전달자다. "What & why"는 전형적으로 제품 매니저에게 책임이 부가되어 있다.

2. how역할 - 사용자가 사용하기 위해서 제품이 어떻게 되어야 하는지를 결정한다. 이 역할은 사용자 책임의 대리모역할이다.
   구두로 또는 글 등으로 사용자가 무엇을 하고 어떻게 그것을 하고 소프트웨어가 사용자를 위해서 어떤 기능이 행해져야 하는지에 대해서 설명한다.
   그들은 개발자와 많은 시간을 보내고, 기능성을 테스트한다.

그는 많은 agile팀들이 두개의 역할을 한명의 Product Owner가 수행하는 실수를 범하고 있다고 이야기한다.

내 의견은 혼란은 두가지 영역에 놓여있다. 첫째로 소프트웨어 회사는 수년간 제품 매니저와 기능적 제품 디자이너의 책임을 결합하려고 노력하였다. 이것은 내가 본 대부분의 경우 악몽이었다. 

그리고 이것은 제품 매니저와 Product Owner간에도 마찬가지 위기를 만들어냈다. 

개발방법론과 상관없이 이들 두가지 역할의 결합은 요구되는 기술가 성격이 완전히 다르기 때문에 실패의 지름길일 수 있다. 

두개가 결합되면 그 결과는 나쁜 사용성의 좋은 기능을 가지거나 누구도 신경쓰지 않는 좋은 사용성을 가진것이 나온다.

 

Jack Milunsky는 Product Owner의 10가지 행동을 충고하였다.

1. Product Backlog를 만들고 관리하라

2. 비즈니스 가지와 ROI에 따라서 Backlog의 우선순위화 하라

3. User Story에 대한 주제, 특징들의 퇴고를 도와라

4. 매 release와 sprint 시작에 비전과 목표를 전달하라

5. 고객을 대신하고, 고객과 약속하라

6. daily Scrum과 Sprint Planning Meeting, Review등에 참석하라

7. 매 스프린트가 끝날 때에 진행과정을 면밀히 살펴라

8. 매 Sprint끝날때에 프로젝트의 경로를 변경할 수 있다.

9. 대외적으로 프로젝트 상태를 전달하라

10. 프로젝트 방향의 큰 변화가 있을 때 Sprint를 종료해라

    
    

    
    

    
    

    이상입니다.

    감사합니다.