MS가 M&A로 구글을 사려했다는 소식은 유명하다. 깔끔한 디자인으로, 단순하고 명료한 검색엔진개발사 구글의 생각을 마소와 웹싸이트에서 얻어왔다. 명확한 목표의식을 통해서 연구원들에게 힘을 만들어주고, 격려하고, 신뢰성있는 소프트웨어를 만드는 일.. 을 꿈구고 싶다.


출처 : http://www.google.com/corporate/software_principles.html ,  http://www.google.com/jobs/reasons.html, 마소 2005 년, 10월호


구글에서 일해야 하는 10가지 이유

1) 상부상조(Lend a helping hand) : 위대한 삶을 살기 위해 필요한 정보를 사람들에게 제공한다.
2) 인생은 아름다워(Life is beautiful) : 리마커블한 제품 개발
3) 감사는 최고의 동기 부여책이다 (Appreciation is the best motivation) 
4) 놀이와 일은 별개가 아니다. (Work and play are not mutually exclusive)
5) 종업을 사랑하며 이런 사실을 알기를 바란다. (We love our employees, and we want them to know it)
6) 혁신이 생명줄이다 (Innovation is our bloodline). 정보처리 부분에서 최고를 지향한다.
7) 어딜 보더라도 좋은 동료가 있다.(Good company everywhere you look) : 다양한 부분에 걸쳐 온갖 경력으로 무장한 친구를 찾을 수 있다.
8) 세계를 하나로 묶는다 (Uniting the world, one user at a time. ): 모든 국가와 모든 언어를 지원한다.
9) 아무도 간 적이 없는 신세계로 용감하게 나가자(Boldly go where no one has gone before : 풀어야 할 수많은 난제가 있다. 여기서 수많은 사람을 기쁘게 해줄 창조적인 신제품을 만들 기회를 얻을 것이다.
10) 공짜 점심과 같은 선물이 있다. (There is such a thing as a free lunch after all)
사랑으로 만들어지고, 건강한 음식을 먹을 수 있다.
구글 식당은 품질이 높기로 유명하다. 최근 구글 식당의 수석 요리사가 그만둔다고 해서 새로운 요리사를 구하기 위해 난리가 났었다.

구글이 밝히는 설치형 구글 소프트웨어 원칙 (www.google.com/corporate/software_principles.html)

1) 설치 : 사용자를 속이면서 소프트웨어를 설치하지 않아야 한다. 소프트웨어를 컴퓨터에 설치하는 과정에서 거부할 수 있어야 하며, 다른 소프트웨어 설치 과정에서 끼어들어서도 안된다.
2) 솔직한 소개 : 소프트웨어를 설치하거나 활성화할 경우에 주된 기능을 알려줘야 하며 광고를 통해 돈을 벌어들일 경우 이런 사실을 밝히지 말고 가장 눈에 잘 띄는 곳에 보여줘야 한다.
3) 단순한 제거 : 소프트웨어를 비활성화하거나 삭제할 경우에 손쉬운 방법을 제시해야 한다. 응용 프로그램의 모든 기능을 제거해야 하며 삭제된 이후에 다른 응용 프로그램을 동작시킬 경우 동작해서는 안된다.
4) 명확한 동작 방식 : 사용자 환경 설정을 변경할 ㅅ경우에 이런 변경을 가하는 이유에 대해 명확하게 설명해야 한다.
5) 훔쳐보기 : 응용 프로그램이 개인주소와 같은 정보를 수집해서 전송할 경우 사용자에게 알려야 한다. 정보를 수집해서 전송한다는 사실을 명시적으로 알리고 동의를 구해야 한다.
6) 좋은 회사 만들기 : 응용 프로그램 제공자는 상기 가이드라인을 어기는 소프트웨어를 함께 포함시켜 배포하지 않아야 한다. 여러 가지 응용 프로그램이 동시에 설치될 경우에 사용자에게 각 소프트웨어가 무엇인지 알려줘야 한다.

Posted by '김용환'
,
요약

실패한 프로젝트의 유형
1. 프로젝트의 진행 중간에 취소 또는 중단된 프로젝트이다.
2. 프로젝트의 완료 시점에서 고객이 그것을 받아들이지 않아 결과적으로 프로젝트의 최종 인도물이 무용지물인 경우이다.

성공한 프로젝트
1. 계획된 시간, 비용, 범위를 제대로 충족시키고, 결과적으로 고객의 수용과 만족을 얻어낸 프로젝트를 뜻한다.

문제 프로젝트
1. 계획된 일정이 초과되었거나
2. 예산을 초과하였거나
3. 기능 중 일부를 구현하지 못하는 경우

프로젝트 매니저의 첫번째 덕목은 경영과 관리의 업무니다.
업종의 특수성을 초월하는 보편성을 깨달음으로써, 완전한 도의 경지에 도달한 사람이다.

소프트웨어 매지니맨트는 개발자의 심리를 깊이 이해해야 한다. 실무지식 및 통찰력이 필요하다.

프로젝트의 실패 요인 중 큰 부분
프로젝트에 혼란을 가중하는 가장 일반적인 원인은 역할 즉 권한 과 책임을 명백히 규정하지 않는 것이다.

Posted by '김용환'
,
요약
실용주의는 기존의 관념적이고, 형이상학적 사고를 부정하고,그 관념들이 실세계에 초래하는 결과가 유용하고 실용적인 실제들로 증명되었을 때만 의미가 있다라는 단초를 갖고 시작한다. 실제 프로젝트에서 이상적인 시스템을 구축할 수 있어야 그 유용성을 증명할 수 있는 것이다.

실용주의란 요구사항에 맞는, 시스템의 목적에 충실한 방법을 말한다. 실용주의에 맞는 개발을 하려면 다음의 방법론을 가져야 한다.

1. 자신의 능력에 충실한 방법
설계자는 아키텍처에 대한 거시적인 관점을 항상 유지해야 한다.

2. 개발 단계를 고려한 미시적 설계
두 쓰레드가 컨텍스트 스위칭을 하며 각자의 작업을 실행하듯이 양 관점을 주깆거으로 바꾸어 디자인하려는 습관을 기른다.

3. 모듈화 극대하기
소프트웨어 시스템에서 서브 시스템과 컴포넌트의 그룹핑을 통해 의미있는 분류 상태를 말한다.

4. 모듈화 인터페이스, 팀 나누기
변할 수 있는 인터페이스에 대해 변경을 위한 여지를 남겨두는 기법이 필요하다. 방법은 이런 부분의 인터페이스를 유연하고 다의적이며 느슨한 인터페이스로 구성함으로 가능하다.
변경을 염두로 한 유연하고 느슨한 다의적인 인터페이스를 정의한다.
자신이 할 수 있는 것과 할 수 없는 것을 냉정히 분석하여 자신이 할 수 있는 것을 확실히 잘 하는 지혜가 필요하다.

5. 거시와 미시 두가지 관점 갖기

6. 아키텍터를 반영한 거시적 설계
아키텍처 스타일을 따르기 위해 아키텍처 스타일을 숙지하고 적용할 부분을 잘 포착할 수 있어야 한다.
아키텍처 레벨에서 정의한 방법을 디자인레벨에서 재정의 한는 일이 없어야 한다. 잘못된 인터페이스의 설계로 모듈간의 불협한 소통은 곧 팀사이의 불협한 소통으로 이어진다. 그래서 모듈화를 잘해야 하며 모듈간의 인터페이스를 잘 정의해야 한다.

7. 모듈화와 공학적인 일정 추정, 관리
예상되는 기간 + a의 일정추정법을 사용한다. 노련한 개발자의 소양 중 하나는 일정 예측을 잘 하는 것이다.
조엘 온 소프트웨어에서는 모듈명, 작업내용, 우선순위, 최초 추정시간, 현재 진행시간, 경과시간, 남은 시간으로 구분한다.
안정된 프로젝트 관리와 자신의 생산성과 신뢰성을 확보하기 위해서이다.

8. 자신의 무지 인정하기
경험이 갖춰지기 전에 자존심이 강해지기 때문에, 데드라인을 지키지 못하는 일정을 잡아 억지로 납기일을 맞추다보니 기능이 제한되든가 품질이 떨어지는 소프트웨어가 만드는 경우가 빈번하다.
제작한 설계의 허점과 단점을 깨닫게 될 때, 적절한 자기 관용을 통해 어느 선으꼬 마무리를 짓고, 다음 기회에 더 괜찮은 소프트웨어를 설계하기 위해 노력하는 것이 유익하다.

9. 진화를 위한 방법
항상 자기 계발을 늦춰서는 안된다.

10. 진지전과 기동전
장기적인 계획이나 방향이 필요하다. 시대적인 트랜드나 개인적 호기심을 따라 두서없이 학습하다 보면 중심을 잃게 되고 균형 잡힌 지식형성을 효율적으로 못한다. 기술력을 만들기 위해서는 로드맵을 만드는 것이 좋고, 거시적인 비전을 갖고 비전에 으르는 과정의 사이마다 이정표를 세워 자신의 캐리어 패스를 구상해야 한다.

의지와 성실함의 성격이 중요하다.

11. 포교활동
새로운 기술을 배우면, 반드시 그 기술을 적용한 프로토타입 모델을 리뷰한다거거나 요점을 정리해서 메일을 돌리는 것만으로 새로운 반응을 얻을 수 있다.

12. 응집성과 결합성
역할과 의도에 따라 분류를 잘하고 방향성을 잡아야 한다. 자신의 주관적인 설계 의도가 시스템의 객관적인 설계 문제를 잘 해결하고 있는지 자주 평가 / 확인하는 습관이 필요하다.

13. 몸에 맞는 옷
무조건적인 패턴을 쓰는 것보다 원리 원칙은 알되, 현재 설계문제가 필요로 하는 용도를 분석할 수 있어야 한다. 용도가 정확히 맞아 떨어지는 모델을 말한다.

14. 다시 관념 속으로
자기 확인이 필요하다. 비판적으로 스스로를 확인하는 습관이 필요하다. 실용주의는 수동적인 수용을 거부한다. 계속해서 검증해야 하고, 비판해야 하며 확인해야 한다. 또한 새로운 것을 계속해서 찾아야 한다. 또한 새로운 것을 계속해서 찾아야 한다. 그래서, 실용주의 엔지니어는 부지런해야 한다.

Posted by '김용환'
,
운영체제와  jdk 버젼, jni/kni에 따라서 performance가 상당히 차이가 난다.

JNI/KNI native call은 2가지 상황에 따라서 달라질 수 있다.

첫번째, 잘 된 알고리즘 기반의 native call이 속도를 높일 수 있다.

둘째, JIT 버젼은 상당히 속도면에서 아닌 버젼과 비교할 (cost of a native call) 때, 데이터를 접근할 때(cost of accessing data from native code) 엄청난 차이가 난다. 

논문을 쓰면서 자기들이 만든 제품이 뛰어나다고 쓰다니.. 음.. 별 커다란 가치가 없는 논문이지만, native call 에 대한 performace를 제대로 체크했다는 점을 높이 산다.
Posted by '김용환'
,

글 단어나 문장자체가 어려워서 이해하기 어려운 부분이 있었다.
나름대로 이해하고, 내 언어로서 표현해 본다.

베네바 부시는 전쟁속에서 많은 고민들을 했던 거 같다. 1945년 7월 The Atlantic지에 등재한 논문 'As we may think'는 어투상에서 느끼는 많은 상황을 해결하려고 노력한 거 같다.

정보가 많아지고, 커지고, 저장을 해서 컨설팅을 받아야 하는 상황이 생기고 있다. 즉, 과거의 정보를 이용하여 새로운 이론이나 학문을 증진시켜야 할 필요성이 생기고 있다.
기계의 속도는 점점 빨라지고, 분석기가 쓰임이 효율적으로 증대되고 있다. 하지만, 지금의 컴퓨터 언어로서는 특징에 맞는 정보를 저장하기 어렵다.

또한 입력을 하고, 그 입력된 정보를 통해서, 처리되고, 분석되어서 서로간의 커뮤니케이션이 효율적으로 증대할 수 있으며, 기계에 인간이 맞춰가는 것이 아니라, 인간이 기계의 능력을 초월하는 아이디어를 통해서 기계를 보다 인간과 비슷하게 만들 수 있는 시스템을 그려 보았다.

Memex, 그 그계를 통해서 다양한 정보들을 저장하고, 그 저장된 정보들을 확장하여, 능력을 극대화시켜서, 경험을 쌓는 것, 역사학자가 주욱 역사들을 기록하는 것처럼 기록하여 인류가 저지른 문제들을 최소화하고, 실수를 다시 일으키지 않도록 하는 것이다.


이 메멕스가 html로 비슷하게 보는 경우가 있지만, 개인적으로는 이 메멕스는 일종의 Web DataBase 같은 개념으로 생각을 했다. 누가 언제든지 접근할 수 있으며, 항상 저장된 페이지를 통해서 진화하는 시스템을 생각하는 것으로 받아들인다.

부시의 논문이 어려워서 이해를 많이 하지 못해서 가슴이 너무 아프다. 영어 공부를 많이 해야겠다는 생각이 들었다..

Posted by '김용환'
,
요약본이다.

버그의 종류
1. 자료의 비정상적인 흐름을 통제하지 못해서 발생하는 버그
2. 논리의 정확하지 않은 정의에 의해 발생하는 버그
3. 프로그램의 외부의 요인(라이브러리, 운영체제, 아키텍쳐, 프레임워크)에 의해 발생하는 버그

또다른 버그의 종류 분류
1. 일관성이 없는 UI
2. 기대에 미치지 못하는 기능
3. 낮은 성능
4. 크래쉬 및 데이터 충돌

버그의 한예
STL의 자료구조에 대한 동기화 문제
-> 해결 뮤텍스를 이용하여 동기화 해결

쓰레드 사용 가이드 라인
1. 메인쓰레드로 충분한 처리가 가능하고 불가피한 이유가 없다면 불필요한 쓰레드를 만들어 구조를 복잡하게 만들지 마라.
2. 어떠한 자료구조이든 사용될 때 여러 쓰레드에 의해 이 자료구조가 접근될 수 있음을 항상 고려하라.
3. 불가피한 경우가 아니라면 여러 개의 쓰레드에서 동시에 접근 가능한 글로벌 변수와 스태틱 변수를 사용하지마라. 글로벌 변수와 스트택 변수를 사용시에는 개발 팀 전체의 코드 리뷰를 거쳐서 반드시 사용해야 하는 타당성을 입중해라.

커널오브젝트(뮤텍스, 이벤트, 세마포어)를 다룰때, 커널오브젝트의 이름 명명 규칙, 커널오브젝트의 시큐리티 속성을 조심스럽게 다루어야 한다. 제대로 짓지 않은 naming, 혹은 NULL값을 할당함으로서, 오류를 일으키지 않도록 해야 한다.

MSDN을 참조할때는 API의 설명외에도 Remarks와 Requirement를 반드시 확인해야 한다.
(용용 : API를 설계할때, 가장 중요한 점은 바로 이해하기 쉬운 문구를 써야 한다는 것이다. 글을 보고도 이해를 할 수 없다는 것은 가장 불쌍한 것이다. 특정 뛰어난 아키텍트의 api 설계 원칙에 의해서 설계되어도 다른 팀원들에게 이해되지 않는 문구로 설명해놓으면, 결국 잘못된 쓰임새로 인식하게 되고, 버그를 생성하게 되는 요인으로 작용하게 된다.
api를 설계할때는 충분하게 이해되기 쉬운 구어체가 쓰여야 하면, 적절한 예면, Remark, Requirement를 잘 기술해야 한다.
다른 팀원들에게도 쉬운 이해를 도울 수 있으며, 자신에게도 도움이 될 수 있다.)

실수를 줄이기 위한 개발 시스템, 조엘 테스트
1. 소스코드 관리시스템을 사용하고 있습니까?
2. 한번에 프로젝트의 빌드를 만들어 낼수 있습니까?
3. 일일 프로젝트 빌드(Daily Build)를 하고 있습니까?
4. 버그 추적 시스템을 운영하고 있습니까?
5. 코드를 새로 작성 전에 버그를 수정합니까?
6. 개발 일정을 지속적으로 업데이트하고 있습니까?
7. 명세서를 작성하고 있습니까?
8. 조용한 작업환경에서 일하고 있습니까?
9. 돈이 허락하는 한도 내의 경제적인 범위애서 최고 성능의 도구를 사용하고 있습니까?
10. 테스터를 별도로 두고 있습니까?
11. 프로그래머 채용 인터뷰때 코딩 테스트를 합니까?
12. 무작위 사용편의성 테스트를 수행하고 있습니까?

거시적인 관점에서의 개발추
1. 연구/개발
2. 판매/마케팅
3. 고객지원

Posted by '김용환'
,
요약본이다.

프로그램 소스코드는 고수는 더 기억을 잘한다.
실험에 따르면, 고수는 한번 이상 본 코드를 기억해내는 능력이 월등하며, 코드를 보는 순서가 다르다는것.
OOP의 고수는 짧은 시간 내에 주로 클래스들의 관계, 책임등ㅇ을 읽어낸는 반면, 하수는 주로 어떤 콘트롤 구조가 사용되었는지에 주목했다.
OOP세상에서는 아무래도 고수의 코드 이해 능력이 더 뛰어날 수 밖에 없다.

의도적 수련은 반복적이다. (전문가일수록 일주일중 공휴일까지 하루에 투입하는 의도적 수련의 양이 일정했다) 그리고, 피드백을 거의 즉각적으로 받을 수 있다는 것 , 나중에 오류 수정이 가능하다는 것, 실수에 대한 부담이 크지 않다는 것, 자신이 한 것에 대해 생각해 볼 여유가 주어진다는 것 등이다.

프로그래머의 직업적 특성
1. Use what you know
2. Fell it work
3. Share the experience
4. Wait for insight
5. Refactor to include it

수련의 의미
전무가들일수록 수련을 즐긴다.
전문가들일수록 일정 수준에 오른 이후에도 꾸준히 수련을 계속하며, 그 활동 자체에서 큰 즐거움을 얻는 것으로 알려져 있다. 고수가 되는 길은 오히려 '고수'보다 '길'에 대한 집착에 나오는 것일 수 도 있다.
Posted by '김용환'
,
나름대로의 요약을 했다.

마켓 중심의 개발자가 되는 3가지 조건
1. 시대와 어울리는 개발자야여 한다.
몸과 마음을 늘 열어야 한다.
혁신가 - 선각 수용자 - 전기다수 - 후기 다수 - 지각수용자 중에서 지각수용자에는 포함되지 않도록 해야 한다.

2. 혁신지향의 개발자야 한다.
내가 어디쯤에서 뛰는 것이 좋을지 결정해야 한다.

3. 균형 잡힌 개발자여야 한다.
많은 경험과 학습을 많이해서, 실패의 경험속에서 배워야 한다. 항상 프로젝트가 끝나면, 반드시 평가회(postmortem)을 거치고 이를 기록해야 한다.


소프트웨어 엔지니의 윤리
- 1988년 AC과 IEE는 소프트웨어 공학 윤리 강령과 업무 규범(Software Engineering Code of Ethics and Professional Practive)를 채택했다.

"소프트웨어 엔지니어는 소프트웨어의 분석, 명세, 설계, 개발, 테스팅, 유지보수가 유익하고 존경받는 전무직이 되도록 헌신해야 한다. 공공의 행복, 안전, 번영에 대한 헌신과 더불어...
Posted by '김용환'
,
보통 자바 클래스들을 배포할 때에는 JAR로 묶는 경우가 많다.
효과적인 Archive 방법을 이용하여 용량을 크게 줄이는 방법을 제시한 이 논문을 보자.

Jazz는 중복을 제거기 위해서 자바 클래스의 특징을 이해하였다. 모든 Constant pool을 한 공간에 할당하고, Constant pool에 대한 Huffman Table을 생성하며, 비슷한 Method들을 분류하고, 나머지 필드등을 각각 클래스별로 압축하는 방법을 사용하는 File Format을 가지고 있다.

Jazz 압축은 다음과 같은 전략을 가지고 있다.

1. Huffman codes are used for constant pool indices.
2. A unified constant pool is used for all classes in the Jazz archive.
3. Strings, opcodes, and arbitrary data compressed with Zip.
4. Start-step-stop code are used for instruction and string lengths; they are also used to encode the tables of Huffman codes.
5. Redundant constant pool entries are eliminated.

(Start-step-stop 인코딩 방법, 허프만 방식은 공부를 더 해야하는 부분이다. 추후, 이 부분에 대한 공부를 더 할 계획이다.)

이런 Jazz 압축을 통해서, uncompressed JAR 파일에 비해서, 대략 1/4정도로 줄여주는 특징이 있다. compressed JAR에 비해서 약 2배정도의 압축 효율이 있음을 알 수 있다.
메모리 공간차지와 속도에 대한 자료는 전혀 나와 있지 않으나, 논문 저자들은 속도에 큰 오버헤드는 존재하지 않는다고 밝혔다. 그리고, 압축을 풀어 소스를 decoding할때는 예전소스와는 약간 다르게 소스가 생성된다고 하였다. 그리고, 동작은 잘 동작된다고 하였다.

약간의 los가 있지만, 동작의 신뢰성이 보장되며, 효율이 좋은 형태로 저장될 수 있는 Jazz 파일 포맷을 쓰는 것은 참 매력적이다.

'After reading article or paper' 카테고리의 다른 글

마소의 의도록 수련을 보고  (0) 2006.07.20
마소의 마켓 중심의 개발자가 되는 길  (0) 2006.07.20
Licklider의 꿈.  (0) 2006.07.20
The Emperor's old Clothes-Hoare  (0) 2006.07.20
Iterative communication  (0) 2006.07.20
Posted by '김용환'
,
1955~60년대에 Licklider는 ARPANET에서 시분할 연구를 진행한 연구자로 유명한 사람이다.
Licklider는 1960년 Man-Computer Symbiosis, 1968년 Taylor와 함께 공저한 The Computer as a Communication Device 를 쓴 것으로 유명하다.
두 편의 논문을 통해서, 컴퓨터의 기능을 좀 더 효과적으로 통신의 수단으로 사용하려 했던 것을 찾으려 했음을 알 수 있었다. Calculating 뿐 아니라, Communication의 Tool로서 보고 아이디어를 내었다.

릭라이더는 매우 친밀하고, 유사한 기관이 함께 엮는 컴퓨터의 인간과의 관계 설정에 대한 비젼을 보여주었다. 그리고, 컴퓨터는 통계적 추론, 의사결정론, 패턴, 게임이론등과 같은 이론등이 컴퓨터에 적용될 것이라고 생각을 했다. 인간과 컴퓨터의 한계인, 스피드, 메모리의 크기와 영속성, 언어와 IO등의 문제를 해결해야 비젼이 성립된다고 Man-Computer Symbiosis에서 의견을 피력했다.

8년의 시간이 지나, 제자 테일러와 함께 The Computer as a Communication Device라는 제목으로 좀 더 그의 컴퓨터에 대한 비젼을 확실히 밝혔다. (상당히 쉬운 논문이라, 중학생이상이면 이해할 수 있다.) 통신 모델로서의 컴퓨터의 기능을 통해서, 서로 멀리 떨어져 있는 경우나, 말로 설명하면서 일어나는 경우에 대해서, 의사소통등에 대한 오해의 소지등을 도식화한 이미지를 통해서 생산성을 높이고, 마치 face to face 의사소통을 가능케 한다고 생각했다.

그리고, 인간 몸체의 신경 명령 체제(뉴런)을 바탕으로 컴퓨터의 쓰임을 그런 모습으로 비교하며, 운영체제와 컴퓨터, 소프트웨어, 프로세서등을 도식화하였다. 그래서, 뉴런과 비슷한 개념으로 Node를 들었으며, 프로세서는 메세지를 분석하고 처리하는 것으로 인식하였다. 이 메시지 프로세서는 서로 통신이 가능하다는 그림을 통해 보여주었다.

data 통신에 대한 상업적인 평가 또한 놓치지 않아 console당, 사람당, 시간당 비용의 affodable을 생각해 보았다.

릭라이더는 컴퓨터는 의사소통을 도와주는 도구로서, 비서의 역할과 비슷한 모습으로, 학습과 경험하는 모델로 생각하였다. 그의 생각이 테일러에게 큰 영향을 주고, 테일러의 영향을 통해서 네트웍이 점차 구성화하고 초기화하는 아이디어가 되었음을 간과할 수 없다.

인터냇을 결국 만들어낸 45년전의 연구자로서, 그 당시에는 획기적인 아이디어를 제공하고, 진보적인 생각을 통해서 많은 후배들을 양성해서 실효성을 거두었다고 생각이 든다.

나는 40~50년후의 컴퓨터의 모습, 임베디드 시스템의 모습을 상상할 수 있을까?

상상을 해본다면, 다음과 같을 것이다.
앞으로 10년후의 모습은 상당히 다를 것이다. 모든 전자부품에서는 블루투스나, 무선랜이 장착된 통신성/Wireless가 강한 제품군들이 나올 것이며, 전력선이 굳이 없어도, Wireless한 전자부품들이 나와 충전/통신이 될 것이다. 특히, 집안의 TV가 홈 네트워크의 결정적인 게이트웨이가 될 것이며, 인공지능의 로봇들이 천천히 현실화되는 모습으로 변해갈 것이다.

릭라이더, 테일러를 통해서 미래에 대한 비젼을 생각해 보는 좋은 시간을 가졌다.
Posted by '김용환'
,