James Song's Blog

스콧 마이어스 <이펙티브 모던 C++> Item 23-26 요약

devsong — Fri, 6 Jan 2017 09:37:28 +0900

차례

1장. 형식 연역
2장. auto
3장. 현대적 C++ 적응하기
4장. 똑똑한 포인터
5장. 오른값 참조, 이동 의미론, 완벽 전달
6장. 람다 표현식
7장. 동시성 API
8장. 다듬기

Item 23: std::move와 std::forward를 숙지하라

기억해 둘 사항들

- std::move는 오른값으로의 무조건 캐스팅을 수행한다. std::move 자체는 아무것도 이동하지 않는다.
- std::forward는 주어진 인수가 오른값에 묶인 경우에만 그것을 오른값으로 캐스팅한다.
- std::move와 std::forward 둘 다, 실행 시점에서는 아무 일도 하지 않는다.

Item 24: 보편 참조와 오른값 참조를 구별하라

기억해 둘 사항들

- 함수 템플릿 매개변수의 형식이 T&& 형태이고 T가 연역된다면, 또는 객체를 auto&&로 선언한다면, 그 매개변수나 객체는 보편 참조이다.
- 형식 선언의 형태가 정확히 형식&&가 아니면, 또는 형식 연역이 일어나지 않으면, 형식&&는 오른값 참조를 뜻한다.
- 오른값으로 초기화되는 보편 참조는 오른값 참조에 해당한다. 왼값으로 초기화되는 보편 참조는 왼값 참조에 해당한다.

Item 25: 오른값 참조에는 std::move를, 보편 참조에는 std::forward를 사용하라

기억해 둘 사항들

- 오른값 참조나 보편 참조가 마지막으로 쓰이는 지점에서, 오른쪽 참조에는 std::move를, 보편 참조에는 std::forward를 적용하라.
- 결과를 값 전달 방식으로 돌려주는 함수가 오른값 참조나 보편 참조를 돌려줄 때에도 각각 std::move나 std::forward를 적용하라.
- 반환값 최적화의 대상이 될 수 있는 지역 객체에는 절대로 std::move나 std::forward를 적용하지 말아야 한다.

Item 26: 보편 참조에 대한 중복적재를 피하라

기억해 둘 사항들

- 보편 참조에 대한 중복적재는 거의 항상 보편 참조 중복적재 버전이 예상보다 자주 호출되는 상황으로 이어진다.
- 완벽 전달 생성자들은 특히나 문제가 많다. 그런 생성자는 대체 비 const 왼값에 대한 복사 생성자보다 더 나은 부합이며, 기반 클래스 복사 및 이동 생성자들에 대한 파생 클래스의 호출을 가로챌 수 있기 때문이다.

[C++ Korea] Effective Modern C++ Study item 24-26 from Seok-joon Yun

참고

예제, https://github.com/BartVandewoestyne/Effective-Modern-Cpp

- James Song

[NDC]라이브 프로젝트에서 C++로 테스트 주도 개발하기

devsong — Thu, 29 Dec 2016 16:34:25 +0900

많은 개발자들이 테스트 주도 개발이 좋다고 얘기한다. 그러나 막상 처음으로 프로젝트에 적용하려 하면 어떻게 시작해야 할지 막막하고 여러 난관에 부딛치게 된다. 테스트 도구는 무엇을 쓸 것인가? 레거시 코드의 의존성은 어떻게 깰 것인가? 어떻게 팀 개발 문화에 정착시킬 것인가? NDC 2013에서 홍종찬 님의 발표는 다른 개발자들은 테스트 주도 개발을 어떻게 실무에 적용해서 잘 사용하고 있을까라는 내 궁금증을 어느 정도 풀어줬다. 그리고 덕분에 그동안 미뤄오면 마이클 페더스의 <레거시 코드 활용 전략>도 읽는 계기가 됐다.

1. GoogleTest를 써라

2. 의존성을 끊어라

3. 시행착오로 얻은 행동요령들

참고

Google Test
https://github.com/google/googletest

null object 패턴
https://en.wikipedia.org/wiki/Null_Object_pattern

마이클 C. 페더스, <레거시 코드 활용 전략>, 에이콘출판사

라이브 프로젝트에서 C++로 테스트 주도 개발하기, <마이크로소프트웨어>
http://www.kodb.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=39&dbnum=175620&mode=detail&type=techreport

- James Song

폴 칼라니티 <숨결이 바람 될 때>

devsong — Fri, 23 Dec 2016 13:21:41 +0900

데이비드 실즈의 책 제목처럼 우리는 언젠가 죽는다. 어느 누구도 피할 수 없는 진실이다. 하지만 우리는 너무 쉽게 이 사실을 망각하며 살아간다. 내 인생의 끝이 언제인지 알 수 있다면 남은 시간을 계획적으로 더 가치있게 쓸 수 있을까? 어쩌면 언제 끝날지 모르는 삶의 불확실성 때문에 더더욱 오늘 하루 지금 이 순간을 가치있게 보내야 하는지도 모르겠다. 이 책을 읽으면서 훌륭한 의사이자 작가 폴 칼라니티를 알게 되었는데 이제 더 이상 그의 책도 그의 소식도 접할 수 없다니 안타깝다. 칼라니티에게 간절했던 건강한 하루 한 달 일 년을 지금 살고 있다는 사실을 잊지 않고 싶다. 아름다운 이 책의 제목처럼 그의 영혼은 숨결에서 바람이 되어 이 책을 읽는 사람들의 가슴속에 남아 특별한 가르침을 주고 있는 것 같다.

본문 중에서...

죽음 속에서 삶이 무엇인지 찾으려 하는 자는
그것이 한때 숨결이었던 바람이란 걸 알게 된다.
새로운 이름은 아직 알려지지 않았고,
오래된 이름은 이미 사라졌다.
세월은 육신을 쓰러뜨리지만, 영혼은 죽지 않는다.
독자여! 생전에 서둘러
영원으로 발길을 들여놓으라.
- 브루크 풀크 그레빌 남작, <카엘리카 소네트 83번>

Epilogue - 루시 칼라니티

"우리는 결코 완벽에 도달할 수는 없지만 거리가 한없이 0에 가까워지는 점근선처럼 우리가 완벽을 향해 끝없이 다가가고 있다는 것은 믿을 수 있다." 고되고 힘들었지만, 그는 절대 흔들리지 않았다. 그것이 폴에게 주어진 삶이었고, 그는 그 삶으로부터 이 책을 써냈다. 그래서 <숨결이 바람 될 때>는 지금 이대로 완결된 작품이다.

옮긴이의 말

그를 치료한 의사 헤이워드는 암에 걸린 사람들은 대체로 두 가지 반응을 보인다고 말한다. 하나는 평소에 하던 일을 집어치우고 칭병하며 아무것도 안 하는 절망적인 태도이고, 다른 하나는 오히려 그 병 때문에 더욱 평소 하는 일에 몰두하는 긍정적인 태도가 그것이다. 칼라니티는 후자의 태도를 보인다. 그는 처음에는 "나는 계속 나아갈 수 없어(I can't go on)."라고 말한다. 그러다가 "나는 계속 나아갈 거야(I'll go on)."라고 말하며 신경외과 수술실로 돌아간다.

책의 마지막 페이지에는 칼라니티 부부가 어린 딸 케이디를 안고 환히 웃는 사진이 실려 있다. 이 책을 다 읽고 이 사진을 들여다보면 웃고 있는 부부와는 다르게 우리는 샘솟는 눈물을 억누를 길이 없다. 부부는 왜 웃고 있겠는가? 웃지 않으면 그들이 먼저 울어버릴 것 같기 때문이다.

- James Song

마이클 C. 페더스 <레거시 코드 활용 전략> 8장 요약

devsong — Wed, 21 Dec 2016 18:48:55 +0900

8장. 특징, 어떻게 추가할까?

8.1. 테스트 주도 개발

테스트 주도 개발은 다음과 같은 순서로 진행한다.

1. 실패 테스트 케이스를 작성한다.
2. 컴파일되게 만든다.
3. 테스트에 통과하도록 만든다.
4. 중복을 제거한다.
5. 반복한다.

TDD와 레거시 코드

한 번에 한 작업만 집중하도록 해주는 것은 TDD의 가장 중요한 역할 중 하나이다. TDD를 적용하면 코드 작성이나 리팩토링 과정에서도 두 작업을 함께 하는 경우는 결코 일어나지 않을 것이다. 레거시 코드에 있어서 분리는 특히 중요하다. 분리를 통해 새로운 코드를 작성할 때 다른 새로운 코드와의 독립성을 유지할 수 있기 때문이다. 새로운 코드를 작성하고 나면 리팩토링해서 새로운 코드와 이전 코드 사이에 있는 중복을 제거할 수 있다.

8.2. 비교를 통한 프로그래밍

리스코프 대체 원칙은 한 클래스의 클라이언트 메서드들이 하위클래스의 객체인지 여부에 제한받지 않고 원하는 객체를 사용할 수 있도록 해야 함을 의미한다. 클래스가 이 원칙을 따르는지는 해당 클래스를 가지는 클라이언트 메서드와 클라이언트 메서드가 무엇을 원하는가에 따라 결정된다. 완벽하게 리스코프 대체 원칙 위반을 피해 가는 기계적인 방법은 없다. 하지만 다음과 같이 도움이 되는 몇 가지 방법을 고려할 수 있다.

1. 가급적이면 구체적인 메서드를 오버라이드하는 것을 피한다.
2. 가능하다면 오버라이딩하는 메서드 안에 있는 현재 오버라이딩하려는 메서드를 호출할 수 있는지 확인한다.

- James Song

마이클 C. 페더스 <레거시 코드 활용 전략> 7장 요약

devsong — Mon, 19 Dec 2016 13:01:57 +0900

7장. 코드 하나 바꾸는데 왜 이리 오래 걸리지?

제대로 유지되는 시스템과 레거시 시스템 간 차이점
적절히 유지된 시스템인 경우 어떻게 변경시키는지 알려면 오랜 시간이 걸릴지 모른다. 하지만 일단 어떻게 할지를 알고 나면 변경 자체는 매우 간단할 뿐만 아니라 변경 후 시스템이 휠씬 편안하게 느껴질 것이다. 레거시 시스템인 경우에는 무엇을 해야 하는지 이해하는데 오랜 시간이 걸릴 것이고 변경 자체도 힘든 과정이 될 것이다.

의존관계 깨기

의존관계를 깰수록, 그리고 클래스들을 새로운 패키지나 라이브러리로 이동시킬수록 시스템 전체 재빌드하는 비용은 늘어나지만, 빌드에 걸리는 평균 시간은 줄어들 것이다.

Opportunity handling 클래스들

ConsultantSchedulerDB 클래스에 대한 구현체 추출

OpportunityItem 클래스에 대한 구현체 추출

의존관계 반전 원칙
당신의 코드가 인터페이스에 종속되는 경우, 그 의존관계는 사실 경미한 수준으로 눈에 잘 띄지 않는다. 인터페이스가 변하지 않는 한, 코드를 변경시킬 필요는 없다. 또한 인터페이스들은 그들 아래에 위치한 코드에 비해 휠씬 적은 빈도로 변경된다. 인터페이스를 하나 가지고 있는 경우, 그 인터페이스를 구현하는 클래스를 편집하거나 그 인터페이스를 구현하기 위한 새로운 클래스들을 추가할 수 있다. 물론 그 인터페이스를 사용하는 코드에 영향을 주지도 않는다.
그런 이유 때문에 구체 클래스보다는 인터페이스나 추상 클래스에 종속되는 편이 좋다. 덜 변하는 것들에 종속됨으로써 특정 변경이 초래할지도 모를 대규모 재컴파일 사태의 위험을 최소화할 수 있다.

- James Song

마이클 C. 페더스 <레거시 코드 활용 전략> 6장 요약

devsong — Tue, 13 Dec 2016 18:13:33 +0900

6장. 고칠 건 많고 시간은 없고

6.1. Sprout Method

Sprout 메서드를 만드는 순서

어느 부분에 코드 변경이 필요한지 식별한다.
변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트라면, 관련 작업을 하는 새로운 메서드를 호출하는 코드를 작성한다. 그리고 주석을 표시한다.
소스 메서드에 어떤 지역 변수들이 필요한지를 결정하고 호출에 필요한 매개변수를 만든다.
Sprout 메서드가 소스 메서드에 값을 반환해야 할지 결정한다. 값을 반환해야 한다면 호출을 변경시켜 반환된 값이 변수에 할당되도록 한다.
테스트 주도 개발 방법을 사용해 sprout 메서드를 개발한다. 호출이 동작하게 만들기 위해 소스 메서드에 있는 주석문을 제거한다.

6.2. Sprout Class

Sprout 클래스를 만드는 순서

어느 부분에 코드 변경이 필요한지 식별한다.
변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트라면, 그 작업을 하는 클래스를 위한 적당한 이름을 생각한다. 그리고 그 클래스 안에 있는 메서드를 호출한다. 그 메서드는 당신이 해야 할 작업을 수행할 것이다. 그리고 주석을 표시한다.
소스 메서드에 어떤 지역 변수들이 필요한지 결정하고 클래스의 생성자를 호출하는 데 필요한 매개변수를 만든다.
Sprout 클래스 소스 메서드에 값을 반환해야 할지 결정한다. 값을 반환해서 한다면 호출을 변경시켜 반환된 값이 변수에 할당되도록 한다.
우선 sprout 클래스를 개발한다. 테스트 주도 개발을 참고하자.
객체 생성과 호출이 동작하도록 만들기 위해 소스 메서드에 있는 주석문을 지운다.

6.3. Wrap Method

방법 1. 기존의 메서드를 수정하는 방법
방법 2. 새로운 메서드를 생성하는 방법

방법 1 순서

변경시켜야 할 메서드를 식별한다.
변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트들에서 일어난다면 그 메서드를 재명명하고, 옛 메서드와 같은 이름과 서명을 갖는 새 메서드를 만든다. 이 작업을 하는 동안 서명 보전하는 것을 잊지 말자.
새로운 메서드에 옛 메서드 호출 부분을 위치시킨다.
새로운 특징을 위한 메서드를 개발하고 한번 테스트한 후에 새 메서드에서 그 메서드를 호출한다.

방법 2 순서

변경시켜야 할 메서드를 식별한다.
변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트에서 일어난다면, 테스트 주도 개발을 사용하는 새 메서드를 개발한다.
새 메서드와 기존 메서드를 호출하는 또 다른 메서드를 만든다.

6.4. Wrap Class

Wrap 클래스를 만드는 순서

어느 부분에 코드 변경이 필요한지 식별한다.
변경이 한 메서드 안의 한 부분에 있는 단일한 일련의 스테이트먼트에서 일어난다면, 생성자 매개변수로 포장하려는 클래스를 받는 클래스를 하나 만든다. 테스트 하니스 안에 있는 소스 클래스를 포장하는 클래스를 생성하는 데 문제가 있다면, 포장된 클래스 상에 구현체 추출이나 인터페이스 추출을 사용해 래퍼를 인스턴스화한다.
그 클래스 상에 테스트 주도 개발 방법을 사용해 메서드를 하나 생성한다. 이것은 새로운 작업이 될 것이다. 새로운 메서드와 포장된 클래스 상에 있는 옛 메서드를 호출하는 또 다른 메서드를 작성한다.
새로운 동작이 이뤄지도록 해야 하는 부분에 있는 코드 내의 포장 클래스를 인스턴스화한다.

- James Song

마이클 C. 페더스 <레거시 코드 활용 전략> Part 1 요약

devsong — Sun, 11 Dec 2016 19:36:34 +0900

코드가 얼마나 훌륭하게 작성되어 있는지 여부와는 상관없이 테스트 루틴이 없는 코드는 불량 코드다. 얼마나 멋지게 작성되어 있는가와 객체지향의 사용 여부, 그리고 캡슐화의 정도도 참작 요소가 전혀 되지 못한다. 테스트 루틴이 있으면 코드의 동작을 빠르고 검증 가능하게 변경시킬 수 있다. 하지만 테스트 루틴이 없으면 실제로 우리 코드가 더 나아지는지 더 나빠지는지를 알 수 없게 된다.

1장. 소프트웨어 변경

소프트웨어를 수정하는 네 가지 이유
1. 새로운 특징을 추가한다.
2. 버그를 제거한다.
3. 소프트웨어 설계를 개선한다.
4. 자원 이용률을 최적화한다.

	특징 추가	버그 수정	리팩토링	최적화
구조	변경시킴	변경시킴	변경시킴	-
기능	변경시킴	변경시킴	-	-
자원 이용률	-	-	-	변경시킴

위험한 변경
소프트웨어 변경에 따른 위험을 줄이려면 다음 세 가지 질문에 대해 충분히 생각해 봐야 한다.
1. 어떠한 변경을 가해야 하는가?
2. 그러한 변경을 올바르게 했는지 확인하는 방법은 무엇인가?
3. 어떤 조건을 위반했는지를 알 수 있는 방법은 무엇인가?

2장. 효과적인 피드백 활용

단위테스트는 빠르게 실행된다. 빠른 속도로 실행되지 않는 단위테스트는 단위테스트가 아니다.
의존관계는 소프트웨어 개발에 있어서 가장 중요한 문제 중 하나이다. 대부분의 레거시 코드 작업은 이러한 의존관계를 깨뜨려서 소프트웨어를 좀 더 쉽게 변경할 수 있다.

레거시 코드 변경 알고리즘
1. 변경 지점을 식별한다.
2. 테스트 지점을 찾는다.
3. 의존관계를 깬다.
4. 테스트 루틴을 작성한다.
5. 변경시키고 리팩토링한다.

3장. 감지와 분리

가짜 객체(fake objects)

가짜 객체는 객체를 테스트할 때, 각자가 구현한 클래스의 협력자들을 흉내 내는 객체를 말한다. 가짜 객체를 사용하는 것을 볼 사람들은 "그것은 실제 테스트가 아니다"라고 말하곤 한다. 하지만 그 말은 사실이 아니다. 이러한 테스트는 '분할 정복'을 이용하여 오류를 지역화할 수 있게 도와준다.

display 클래스와 통신하는 Sale 클래스

display 계층을 가지는 Sale 클래스

4장. 봉합 모델

봉합(Seams)은 프로그램 안에서 동작을 변화시킬 수 있는 위치를 말한다. 이때 동작을 변화시키기 위해 코드를 편집할 필요는 없다. 모든 봉합은 하나의 가능 지점(Enable Point)을 가진다. 이 지점은 하나의 동작이나 다른 동작을 사용하기 위한 결정을 내리는 지점이다.

봉합의 종류
1. 전처리 봉합
2. 연결 봉합
3. 객체 봉합

5장. 자동화된 리팩토링 도구

자동화된 리팩토링을 사용하기 전에 코드 주위에 테스트 루틴을 두는 것은 좋은 방법이다. 테스트 루틴 없이도 자동화된 리팩토링을 수행할 수 있지만, 그 도구가 무엇을 검사하고 무엇을 검사하지 않는지는 알아야 한다.

모조 객체
모조 객체 라이브러리 무료 제공 Mock Objects

단위테스트 하니스
- JUint
- CppUnitLite
- NUnit

일반적인 테스트 하니스
- FIT(Framework for Integrated Tests)
- Fitnesse

- James Song

오쇼 라즈니쉬 <틈>

devsong — Tue, 6 Dec 2016 09:04:19 +0900

틈
오쇼 라즈니쉬 저/나혜목 역

과거와 미래 사이에는 영원으로 통하는 틈이 있는데,

그것이 바로 '현재'이다.

- James Song

NDC 김종욱 님의 발표 <Rx와 Functional Reactive Programming으로 고성능 서버 어플리케이션 만들기>

devsong — Sat, 15 Oct 2016 18:12:15 +0900

"비트코인 마이너와 구글 데이터센터의 공통점은 무엇일까요?"
위와 같은 질문으로 시작하는 <Rx와 Functional Reactive Programming으로 고성능 서버 어플리케이션 만들기>는 비동기 처리를 통해 성능을 향상시킬 수 있는 함수형 리액티브 프로그래밍 페러다임의 철학과 개념에 대해서 주로 설명한다. 시간(응답성)의 개념과 함께 우리가 왜 컨트롤 흐름 방식에서 데이터 흐름 방식으로 프로그래밍 패러다임을 변화해야 하는지 설명하는 부분은 흥미롭다. 아래 리액티브 선언에서는 네 가지 속성으로 표현했지만 데이터 흐름 방식의 패러다임의 목적은 결국 빠른 응답성으로 귀결된다.

Reactive Manifesto
- Responsive
- Elastic
- Resilient
- Message Driven

Event-Driven 방식의 리액티브, 함수형 프로그래밍의 모나드, Rx의 개념을 알기 쉽게 설명해 주는 유용한 세미나다. 짧은 세미나지만 함수형 리액티브 프로그래밍을 더 깊이 알고 싶게 하는 자극제가 됐다.

1. 다시 만난 세계
: 지금까지 절차적 프로그래밍만 훈련한 이유

2. Reactive Programming
- 프로그래머들이 외면해 왔던 프로그래밍 패러다임

3. The Reactive Manifesto
: 새로운 시대의 새로운 소프트웨어를 위한 선언문

4. Functional Programming
: 함수형 프로그래밍으로 무엇을 얻을 수 있는가

5. Rx - Reactive Extensions
: 비동기 스트림으로 흐르는 데이터

6. You are (Not) Alone
: 같은 패러다임을 향하고 있는 기술들

발표 슬라이드

NDC14 - Rx와 Functional Reactive Programming으로 고성능 서버 만들기 from Jong Wook Kim

발표 동영상

참고

NDC REPLAY
http://ndcreplay.nexon.com/NDC2014/sessions/NDC2014_0049.html

Bret Victor, <The Future of Programming>
https://www.youtube.com/watch?v=8pTEmbeENF4

Reactive Manifesto
http://www.reactivemanifesto.org/

Reactive Streams
http://www.reactive-streams.org/

play
https://www.playframework.com/

akka
http://akka.io/

PROJECT REACTOR
https://projectreactor.io/

Dart
https://www.dartlang.org/

elm
http://elm-lang.org/

Apache Pig
https://pig.apache.org/

- James Song

토마스 슐츠 <구글의 미래>

devsong — Sun, 9 Oct 2016 19:31:21 +0900

구글의 미래
토마스 슐츠 저/이덕임 역

<구글의 미래>는 독일의 기자 토마스 슐츠가 쓴 구글에 대한 기록이다. 그는 좀처럼 외부에 문을 열지 않는 구글의 내부를 독점적으로 취재할 수 있는 기회를 얻어 기자답게 발로 뛰어가며 이 책을 완성했다. 구글에 대한 이야기는 다른 매체를 통해 이미 많이 소개되었지만 이 책만큼 그 내부의 움직임을 알기 쉽게 잘 정리한 책을 있을까 싶다. 책 속에 등장하는 수많은 구글의 경영진과 엔지니어들의 인터뷰 내용은 책의 재미와 디테일을 더한다. 구글의 미래 프로젝트를 통해 IT 기술이 앞으로 어떻게 흘러갈 것이지 큰 그림을 볼 수 있는 의미 있는 책이다.

(※주의※ 신세 한탄으로 이어질 수도 있으니 구글 기업 문화에 대한 부러움은 잠시 접어두고 읽어야 한다.)

제1장 그라운드 : 학교 기숙사에서 슈퍼 파워의 상징으로

제2장 창업자들 : 열정으로 세상이 바뀔 때까지

제3장 문샷 : 어떻게 미래를 만들 것인가

제4장 비밀 연구소 : 구글의 미래 전략

제5장 검색 : 과거의 성공을 미래로 연결하는 방법

제6장 마스터마인드 : 구글은 어떻게 일하는가

제7장 스마트폰, 로봇과 자동차 : 시스템으로 세상을 움직이다

제8장 디지털화 vs 사생활 보호 : 구글을 둘러싼 논쟁

제9장 미래 : 위대한 비전인가, 거대한 허상인가

본문 중에서

우주에서 가장 야심적인 CEO

괴짜에다 천재였던 테슬라는 동시대의 인물로 전구를 발명한 토머스 에디슨과 견줄 만하다. 물론 두 사람에게는 많은 차이점이 있다. 에디슨은 발명을 하는 와중에도 발명품을 상품화해 돈을 벌고자 재너 일렉트릭을 설립했다. 반면 19세기 후반 뉴욕으로 이민 온 테슬라는 빈곤 속에서 죽음을 맞이했다. 10대 시절에 테슬라의 전기를 읽은 페이지는 나중에 그에 관해 이렇게 말했다.
"세상에서 가장 위대한 발명가도 루저로 살 수 있다는 것을 깨닫고 나는 울었다."

페이지는 대기업이 되려면 거대한 야망이 필수적이며 그렇지 않다면 대기업이 될 자격이 없다고 말한다. 그렇다면 그의 기준에 부합하는 기업은 없다고 봐도 무방하다. (...)
"어떤 회사의 CEO를 만났는데 그에게 오직 돈을 벌려는 동기밖에 없다는 확신이 들면 나는 그 회사를 머릿속에서 삭제해버립니다."

구글, 미래를 시도하는 공간

전기 자동차 회사 테슬라와 로켓 제조회사 스페이스 X를 창업한 일론 마스크도 이렇게 강조했다.
"버닝 맨은 실리콘 밸리다."
머스크와 브린의 말에는 두 가지 의미가 담겨 있다. 첫째, 버닝 맨은 보헤미안적 이상주의의 최전방으로 기술 엘리트들은 이곳에서 무엇이든 자신이 원하는 것을 만든다. 둘째, 버닝 맨은 비즈니스 모델을 발전시키는 문화적 토대다. 실제로 이들은 버닝 맨에서 영감을 받아 사람들을 모으고 경제를 공유하는 방법 등을 연구한다.
(...)
"우리는 세상이 너무 빨리 변하는 것을 원치 않습니다. 그렇다면 세상의 한구석을 별도로 떼어내는 것 어떨까요? 나는 버닝 맨에 참가합니다. 그곳에서는 사람들이 무언가 새로운 것을 시도하지요. 우리 기술론자에게도 새로운 것을 시도하고 그것이 사회에 미치는 영향을 실험해볼 안전한 공간이 필요하다고 생각합니다. 세상에 즉각 적용하기 전에 사람들에게 실험해볼 수 있는 공간 말입니다."

무모한 도박인가, 대담한 투자인가

황당해 보이는 이이디어나 공상과학물에 등장하는 프로젝트에 투자하는 기업이 더 이상 구글 하나만은 아니기 때문이다.(...)그렇다면 실리콘 밸리의 모두가 미쳐가고 있는 것일까? 전혀 아니다. 궁극적으로 모든 프로젝트는 한 가지 핵심적인 면에서 비슷하다. 이 모든 것은 기하급수적으로 성장하는 컴퓨터 성능에 기반을 둔 기계학습의 커다란 진전과 연관되어 있다. 이들은 소프트웨어와 센서, 보다 뛰어난 지능 기계로 세상을 연결하는 것이 점점 궤도에 오르고 있고 기술 진보에 가속도가 붙을 것이라고 믿고 있다. 이 관점에서 온 힘을 다해 미래를 전망하는 것은 유용할 뿐 아니라 기업가적 사명이기도 하다.

최고의 두뇌를 얻기 위한 노력

(...) 그러므로 채용 과정에서 개인적이고 내밀한 선입견을 배제하는 것이 무엇보다 중요하다. 복은 지원자가 얼마나 일을 잘할지 예측하는 가장 좋은 방법은 미래에 할 일을 미리 주고 샘플 테스트를 하는 것이라고 말한다. 즉, 미래에 할 일을 미리 해보라고 지원자에게 요청하는 것이다. 또 해석할 필요 없이 분명한 답이 정해진 문항으로 일반적인 인지 능력 테스트를 하는 방법도 있다. 마지막으로 일반적인 질문을 하며 구조적인 대화를 나눠본다.

구글의 구조, 작은 세포의 집결과 해체

구글에서는 어떤 사람이 스무 명이나 쉰 명 혹은 백 명을 거느린 부서의 수장이라는 것을 알아채기까지 꽤 많은 시간이 걸린다. 홀레는 "여기엔 자신을 중요한 사람이라고 여겨 원칙에 어긋하는 일을 하려고 설치는 오만한 사람은 아무도 없다."라고 했다. 그에게는 상부의 책임자조차 사소한 일을 직접 처리하고 '자기 일을 자동적으로 사다리 아래로 내려 보내지' 않는 것이 매우 인상적이었던 모양이다.

발명가의 딜레마

페르트는 혁신이란 위로부터의 명령으로 이뤄지는 것이 아니며 직원들이 보다 혁신적이고 창의적이려면 그에 알맞은 기업 문화와 구조를 안착시켜야 한다고 말한다. 이를 위해 가장 중요한 요건은 바로 자유다. 그는 이렇게 강조한다.
"직원들이 무엇보다 창의적인 자신감을 갖도록 보장해야 합니다. 그러려면 자유가 필요하지요. 기업 직원들에게 자유를 최대한 보장하면 이들은 놀라운 성취를 보여줍니다."

네트워크로 연결된 미래를 위해

한때 그(토니 파델)는 스티브 잡스와 비밀을 털어놓는 친한 사이였지만 지금 래리 페이지의 측근 인사에 속한다. 한마디로 그는 실리콘 밸리의 두 거인 사이에서 중요한 역할을 담당하는 인물이다. 디지털 미래에 대한 그의 생각은 이렇다.
"앞으로는 우리가 인터넷을 쳐다보지 않아도 될 것입니다. 인터넷이 우리를 찾아올 테니까요. 우리 주위에는 네트워크 말고는 아무것도 없을 것입니다."

구글의 발전이 가져올 미래

조건 없는 기본 수입 방식이 합리적이든 아니든, 책 한 권을 쓸 만하거나 토론 주제로 가치가 있든 없든 상관없이 대부분의 전문가는 적어도 이것 하나만큼은 동의한다. 즉, 다음 세대가 기술 세계와 변화에 적응하도록 교육 제도에 근본적인 변화가 있어야 한다는 것이다. 그렇다고 컴퓨터공학자나 프로그래머를 더 많이 양산해야 한다는 게 아니라 지식 사회의 승자를 더 많이 배출해야 한다는 얘기다. 그래야 투자자와 기업가에게만 수익이 돌아가는 불균형적 혁신 구조에서 벗어날 수 있다. 현재의 교육 시스템은 여기에 대한 준비가 부족하다. 맥아피는 말한다.

참고

세르게이 브린: 왜 구글 글래스인가요?

도널드 노먼, <디자인과 인간 심리>, 학지사

클레이튼 M. 크리스텐슨, <혁신 기업의 딜레마>, 세종서적

에릭 슈미트, 제러드 코언, <새로운 디지털 시대>, 알키

에릭 브린욜프슨,앤드루 맥아피, <제2의 기계 시대>, 청림출판

- James Song