일요일, 12월 29, 2013

스무살 때 알았으면 좋았을 스물 여섯 가지 시간 관리 기술

시간 관리는 대부분의 사람들한테 어려운 부분이고 시간 관리 능력에 따라 성과가 크게 다를 수 있다.

여러 가지 역할을 해야 하는 사람들은 성격이 다른 업무들 간의 전환을 할 때 어려움을 많이 겪는다. 어떻게 시간을 서로 다른 업무들 간에 효율적으로 배분할 수 있을까?

몰입(flow)이 필요한 창의적인 지적 노동을 하는 사람들에겐 더욱 시간의 관리가 중요한 요소이다. 하나의 생각에 깊이 몰입할 수 있어야만 성과를 얻을 수 있기 때문에 몰입할 수 있는 시간 여건을 만드는 관리가 필요하다.

개인적으로도 하루 종일 예정되어 있는 회의들 속에서 생각을 정리하고 설계할 수 있는 시간은 점점 더 찾아보기 어렵다.
어떻게 몰입하고 정리하는 시간을 만들어야 할까? 늘 고민이다.

육체의 피로와 뇌의 피로는 보통 직접적인 관련은 없다.
육체가 피로할 때에도 뇌는 활발하게 활동할 수 있으며, 반면 육체는 멀쩡할 때에도 뇌가 피로할 경우가 있다.
물론 육체가 활발하게 맑은 혈액을 공급해줘야 뇌의 활동이 보장되는 것은 장기적 관점에서 사실이다.

다음 프레젠테이션은 캐나다의 제품 마케팅 컨설턴트인 Etienne Garbugli라는 사람이 작성한 시간 관리 기술에 대한 것이다. 나름 공감되는 부분도 많아서 하나씩 음미해본다.

SlideShare : 26 Time Management Hacks I Wish I'd Known at 20

1. 하루 시간의 배분
 시간에 우선순위를 두자.
 무의미한 Boring 시간을 줄이고 우선순위가 있는 일들로 바꾸자.
2. 매일 일할 분량 4~5시간만 계획하자. 나머지 시간은 차게 마련이다.
3. 하루 종일 일이 전혀 진행되지 않거나, 12시간 이어서 일이 잘 진행되는 게 정상이다. 일이 잘 될 때 좀더 일을 하고, 일이 안될 때 좀더 여유를 갖도록 하자.
4. 자신의 시간당 비용을 생각해보고 그에 따라 행동하자. 내 시간을 존중하고, 또 내 시간이 존중받을 만큼 가치가 있도록 만들자.
5. 멀티태스킹을 없애자. 단지 집중도만 떨어뜨릴 뿐이다.
6. 일을 규칙적으로 만들고, 이를 지키자. 그러면 몸이 적응하게 된다.
7. 시간의 경계가 분명할 때 좀더 집중하고 생산적이다. 시간을 정해라.
8. 일을 시작할 때 일로서 시작하는 게 최선이다. 먼저 빨리 끝나는 짧은 일부터 시작하라.
9. 완전한 것보다 하는 게 낫다. (Doing is better than perfect). 나선형적으로(Iteratively) 일을 하라. 완벽에 대한 기대는 부담스럽기만 하다.
10. 많은 시간을 소비하는 게 더 나은 생산성을 가져다주지 않는다. 제약을 둬라.
11. 생각이 필요한 일과 생각이 필요없는 일은 분리해서 하라. 생각과 실행은 더빠른 실행과 더 나은 생각을 위해 분리되어야 한다.
12. 가능하면 회의는 아침 일찍 잡으라. 회의 시간에 가까워질수록 앞의 일들의 효율이 떨어지게 마련이다.
13. 회의와 커뮤니케이션(이메일이나 메시징)은 묶어서 진행하라. 불필요하게 쪼개면 다른 일들의 진행을 방해하게 된다.
14. 하루 종일 같은 문맥의 일을 하도록 하라. 프로젝트와 고객 등이 바뀌면 생산성이 떨어진다.
15. 업무 도중에는 꾸물거리지 않도록 하라. 단거리 전력 질주와 같은 방식의 업무 사이에 약간의 여유를 배치하라. (업무 도중에 SNS나 뉴스를 읽거나 하지 말라)
16. 이해하기 어려운 것들은 이해할 수 있는 작은 단위로 분해하라. 큰 목표는 매일 하는 작은 일들이 목표에 가깝게 끌어갈 때 비로소 이루어진다.
17. 두 개의 일이 같은 우선순위를 갖지 않도록 to-do 리스트를 관리하라.
18. 오늘 하루에 반드시 해야할 하나의 일이 무엇인지를 항상 명심하라.
19. 업무들을 시간 단위로 나누자. 긴 업무는 시작하기가 어렵다. 길다고 생각되는 업무는 시간 단위로 나눠야 한다.
20. 다른 사람이 해도 80% 정도는 달성할 수 있다고 판단된다면 위임하라. 위임하고 다른 사람들을 활용하는 법을 배워야 한다.
21. 어제 일은 잊어버리고 오늘과 내일에 대해서만 생각하라.
22. 모든 일에는 기한이 있어야 한다. 일이 무한히 진행되도록 하면 안된다.
23. 힘들고 긴장된 일에는 종료일을 정하자. 모든 일은 언젠가 끝난다.
24. 항상 메모를 남기는 습관을 갖자. 모든 걸 머리 속에서 기억하려고 하지 말고 reminder 프로그램들을 활용하자.
25. 주의를 분산시킬만한, 혹은 마음에 걸릴만한 모든 일들은 적어두도록 하자. 어떤 생각이든, 주요 검색 결과든, 새로운 아이디어든 적어두면 일이 궤도에 올랐을 때 머릿 속에 떠올라 가로막지 않게 된다.
26. 가끔은 휴식이 필요하다.


개인적으로 가장 필요한 것은 고정된 시간의 확보이다.
하루 종일 다른 문맥의 회의를 하는 건 어쩔 수 없고..

2 시간 정도를 어떻게 매일 고정적으로 확보하고 목표를 설정할 수 있을까 ..
하루 목표치를 8시간이 아닌 4~5시간 기준으로 잡으라는 충고는 아주 현실적인 조언인 것 같다. 8시간은 아니지만 60% 정도의 하루 의욕 목표치를 가지고 움직여야겠다.

좀 다른 성격의 글이지만 리더들을 위한 스케줄링 원칙을 함께 가져가면 도움이 되겠다.

How to Be Productive - The Mindmap of 35 Habits of the Uber-Productive.

1. 쉬운 일부터 먼저 한다.
2. 하루에 하나의 일에 우선 순위를 둔다.
3. 일과표를 항상 세워서 일한다.
4. 의사 결정 혹은 판단을 내릴 성격의 것이 아니면 회의를 소집하지 않는다.
5. 완벽한 것보다 마무리하는 것이 더 낫다.


토요일, 10월 26, 2013

창의적 문제 해결의 경험

창의적으로 (소프트웨어) 문제를 푸는 경험은 여러 경로로 만날 수 있다.

a. 똑똑하고 적극적인 개인들이 문제를 잘 푸는 경우.
b. 문제의 범주를 잘 인지하고 똑똑한 그룹을 형성하여 회의 속에서 토론하여 실마리를 풀어가는 경우.

문제를 푸는 과정이 단순히 a-ha 현상 한 스텝만은 아니므로 사실은 a와 b의 반복을 어느 정도의 긴장감 속에서 만들 수 있는 체계가 가장 효율적이라고 생각한다.

management는 이러한 문제를 가려내고 가치로운 문제 해결을 할 수 있도록 개인별 mission과 회의를 통한 아이디어 심화 및 공유를 잘 갖추어주고 회의를 잘 이끄는 것이 중요한 역할이다.

그럼에도 문제를 푸는 (답을 선택하는 게 아니라) 과정을 직접 해야 할 시점은 항상 존재하는데 다른 사람과의 토론 속에서 연상을 통해 풀어내는 경우 외에는 결국 스스로 생각을 다시 정리하면서 풀어야 한다.

개인적으로 이러한 풀이 과정은 자리에 앉아 머리를 싸맬 때보단 계속 생각하면서 걸어다닐 때 해답이 잘 발견되었던 것 같다. 복도를 계속 걸으면서 생각한다거나, 탄천을 헤매면서 생각한다거나...


하나. 문제 해답이 떠오르는 건 문제에 대한 깊이 있는 이해 과정이 거듭되어야 한다. (wicked problem적 특성)
둘. 문제의 인지와 해결 모두 우수하고 적극적인 그룹을 형성하여 논리적 토론을 거치는 것이 가장 중요한 단계이다. A-ha의 한 스텝을 제외하고는 이 과정을 통해 문제의 인지와 심화 그리고 해결의 대부분을 매우 좋은 효율로 이룰 수 있다.
셋. A-ha는 보통 정확하게 problem-solving의 mission을 맡은 사람이 만나게 된다. 그만큼 생각을 많이, 깊게 하는 것이 전제되어야 하기 때문이다.
넷. A-ha 자체의 순간은 몰입이나 이완 등의 과정과 무관한 시점에서 아주 비동기적으로 수많은 생각 중 하나의 한 연결에 이어져서 발생한다.

수요일, 6월 26, 2013

기억의 위조와 아하(A-ha) 현상


기억이란 게 얼마나 엉터리일수 있는지 가끔 놀랄 때가 있다.
"무의식의 기억 위조" 현상인데 우리가 기억을 저장할 때 어떤 느낌으로 저장하기 때문일 것이다.

오래되었지만 강렬한 기억은 강력한 위조인 경우가 많은데 낡아진 기억을 복원하기 위해 우리의 무의식은 주변의 비슷한 느낌을 키로 저장된 기억들을 사용하여 완벽(?)하게 재구성하기 때문이다.

수십년만에 페북으로 만난 후배를 마치 잘 알고 있었던 것처럼 느낄 때, 사실은 그 후배와 관련된 기억들은 유사한 이미지를 가진 다른 이의 것이었음을 점차 알게 되고 나중엔 그 이미지조차 원래 그 후배의 이미지가 아니었는데 기억 속에서 바꿔치기되어버렸음을 발견한다.

강렬한 위조였음을...

SW 기술의 기억도 다르지 않다. 흔히 지식이라고 부르는 것들이라고 뭐 특별히 다른 방식의 기억소에 저장하는 것이 아니니까..
중요한 지식, 선입견들 중 첫 인상이 강렬했던 것들은 강력한 방식으로 위조되는 경우가 많다. (난 절대 이런 기억의 정확성을 두고 내기를 하면 안된다 ㅠ)

그런데 어떻게 뇌는 이 수많은 기억들을 미묘한 느낌의 코드로 분류하여 저장하는 것일까?
그 메커니즘은 알수 없지만 기억력과 관련해서는 보통 매우 차분하게 몰입되는 경우가 가장 오래 남고 극도의 긴장 상태에서는 매우 짧은 기간 유지되는 기억 효율이 매우 높은 것으로 알려져있다.

이 사실은 차분할 때 작은 느낌의 차이까지 기억할 수 있고 장기 기억화될 여지가 많다는 뜻이 아닐까?

기억 능력과 아하 현상(a-ha effect, eureka effect)은 직접적인 연관이 없어보이지만 기억에서 차지하는 무의식(인지하지 못하는 뇌의 활동)과 느낌으로 표현할 수 있는 기억의 끄집어냄(검색?) 방식을 보면 유사한 메커니즘일 수 있을 것 같다.
다만 기억은 위조하여(!) 끄집어내는 것이고 아하 현상은 비슷한 것들을 무의식이 총합하여 추천한 것들 중에서 솟구쳐올리듯이 처리한다고나 할까!

P.S

A-ha 현상이 실재하는 것인지에 대해서 의견이 분분하다.
단지 오랫동안 풀어온 문제의 답을 재발견할 뿐이라는 주장도 있고, 비동기적이고 병렬적인 처리를 하는 우뇌의 활동이 주로 이런 답을 발명하듯이 만들어낸다는 주장도 있고, ... (이러한 우뇌의 활동 역시 우리가 인지하는 과정이 아니므로 무의식 활동의 일종이라고 볼 수 있다)

아인슈타인의 경우 외화(externalization)에서 주로 A-ha 현상을 경험했다고 한다.
별다른 게 아니라 복잡한 문제를 친구에게 하나씩 설명하고 토론하는 과정에서 스스로 해법을 발견하는 것이다.
대화를 통해 문제의 답을 찾는 것은 매우 흔한 과정인데 아인슈타인의 상대성 이론의 핵심인 시간과 속도의 관계는 이렇게 발견되었다고 한다.


일요일, 6월 02, 2013

코딩 잘하는 법에 대한 단상


글쓰는 법에 대한 가이드는 있어도 코딩하는 법에 대한 가이드는 보지 못한 것 같다.
글을 쓸 때에도 탑다운으로 (워드의 개요 모드outline mode 활용할 때처럼) 쓸 때와 글 가는 데로 붓 가는 데로 쓸 때가 다르듯이 코딩도 유사함을 가지고 있다.

논리적 설계와 아키텍처의 중요성을 강조하다가 막상 아키텍처 설계가 일단락되어 실제 코딩 단계로 넘어가면 어쩔줄 몰라하는 친구들이 있다.

물론 코딩 못하는데 설계만 아주 잘하는 건 일반적으로 가능한 이야기는 아니고 이런 이들의 설계는 구멍들이 있거나 현실성이 부족한 경향이 있다.

코딩을 설계를 기반으로 topdown 방향으로 진행하려면 인터페이스나 메소드 시그너처 혹은 커멘트 등을 통해 계속 논리 진행을 코드화해나가야 한다.
아주 디테일한 구현을 하나씩 해나가면서 그야말로 코드 가는 데로 하는 방식은 코드 몰입이 좋을 때 별다른 문제없이 잘 된다.
하지만 디테일 코딩을 하기에 논리적 분량이 많고 여러 가지 고려할 경우의 수가 많은 경우는 메소드 시그너처를 먼저 작성하고 (여의치 않은 경우 소스코드에 커멘트로 디테일 계획을 적어둔다) 디테일은 하나씩 채워나가는 형태가 더 효율적이다.
한마디로 코딩할 땐 구현해야할 모든 걸 코드에 반영하는데 한꺼번에 다 상세 구현으로 반영할 수없는 부분은 윤곽만 코딩하는 것이다.

이것은 그림을 그리는 과정과도 유사하다. 기본 스케치를 먼저 하는 것은 설계 후 주요 인터페이스 시그너처를 정의하는 것이라 볼 수 있고 실제 상세 터치는 어떤 부분은 아주 세밀하게 한번에 그리고 어떤 부분은 윤곽부터 조금씩 구체화하는 방식을 사용한다.
대부분 두 가지 방식이 모두 사용되어야 효율적인데 한번에 상세로 그리는 집중력이 필요한 부분은 그렇게 하고 생각이 끊어지는 여러 부분들은 그 포인트만 먼저 윤곽을 잡는 식인 것이다.

스스로 코딩도 하지만 멤버들의 교육과 성장을 함께 고민하면서 스스로에게 여러 가지 실험을 하게 된다.
논리적 사고의 방법, 창의 도출의 방법, 설계의 방법, 코딩의 방법, ...
결과물을 만드는 것만 목적이 아니라 결과물을 만드는 방법을 확인하고 공유하는 것도 중요한 미션이다.

안타깝게도 이러한 부분들이 대화로 전달될 수 있는 건 아닌 것 같다. 가이드일뿐이지 체득은 스스로들 해야 하는 것.

어떤 이에겐 너무 당연하겠지만 답답하게도 이를 몰라서 잠재력을 발휘못하는 사람들도 상당히 많은 것 같다.
코딩을 잘한다는 게 프로그래밍 언어를 잘 이해하는 것만이 아닌 것이다.

일요일, 5월 26, 2013

창의의 메커니즘

제가 주장하는 창의 메커니즘의 핵심은 좀 단순화하여 얘기하면 다음과 같이 요약될 것 같다.

"스스로 거듭 논리적으로 생각하면 누구나 해답을 찾을 수 있다" (개인 관점의 창의)


창의도 문제 해결의 관점에서 바라본다는 점에서 해답을 찾는 것이고 (생각한 문제와 다른 문제의 답이 나오는 수도 있지만) 수단은 '스스로'와 '거듭된 논리적 생각' 뿐이라는 거...


누구나 찾을 수 있다고 믿지만 다만 논리적이기 위해서는 생각의 훈련이 필요하고 거듭 생각하는 것도 쉽지 않다는 것을 지적하고 싶다.

또하나는 이 주장을 개인적 관점에서 확대하여 조직의 창의로 발전시키기 위한 부분이다.
조직(팀) 창의는 역시 반복 훈련과 적응 과정이 필요하다.

"팀 창의는 개인적 창의의 기반 위에서 이루어지는 것이며 다면적 소통을 통해 더나은 결론을 도출할 수 있다" (조직 관점의 창의)

스케줄, 기한, 여가 그리고 창의

소프트웨어 스케줄 계획과 기한

소프트웨어를 하다보면 스케줄 계획과 기한이 항상 맞지 않다.

상세한 수준에서 스스로 스케줄링을 하도록 권장하지만 그것을 기한과 맞춰야 하거나 또 큰 기한을 세워야 할 때면 항상 착오가 생긴다.

목표에 기한이 없으면 뒷쪽으로 갈수록 추동력이 떨어지지만, 기한이 합리성을 잃으면 역효과가 나게 마련인데..

예상과 계획은 늘 어긋나는데 경험과 풀어야 할 문제의 complexity 수준이 제한할 수 있으면(판단되고 제한이 되는 단계가 되면) 예상이 좀더 의미있는 값이 되는 것 같다.

창의적 조직에 대한 고민을 늘 하고 있는데 개인의 성장에 기반한 조직적 지혜의 개선이 가장 중요한 요소라고 생각하지만, 현실에서 마주치는 시간과 기한의 문제는 또다른 어려움이다.

여가와 창의의 관련성에 대한 반론


창의와 시간에 관련된 문제 중 흔히 여가가 창의에 도움을 준다는 주장이 있는데 개인적으로 이러한 주장에 대해서는 사례나 근거를 파악하기가 쉽지 않고 오히려 반례가 많다고 판단하고 있다.

개인적으로는 자발성과 능동성이 그리고 좀더 많은 시간을 몰입하여 생각하는 데에 할애하는 게 창의에 도움을 준다고 생각하는데, 기한이나 문제의 어려움 혹은 현실에서의 댓가와 같은 pressure를 개인이 너무 강하게 의식하게 되면 충분히 생각을 할 수가 없고 생각에 한계를 두게 되기 때문에 창의를 해치는 것은 분명하다.

다만 여가라는 표현은 그야말로 남는 시간을 뜻하는 것인데.. 남는 시간과 휴식이 창의와 연결된다는 근거는 거의 없다. 여러 창의의 발견 형태 중 3M과 같은 사례의 경우 다양한 시도와 조금은 우연성에 기반한 부산물의 재해석을 통한 창의의 형태에서는 주기적인 사고의 전환 즉 몰입하던 문제를 완전히 털어내고 다른 문제로 몰입하는 방식이 중요할 수 있다.
하지만, 그런 경우도 여가가 창의에 기여를 하는 것은 아니라고 생각된다.

여가가 사람에게 필요한가 하는 질문과 여가가 창의에 기여하는가 하는 질문은 전혀 다르기 때문에 사실에 대한 탐구를 이데올로기적으로 해석하거나 선악의 문제로 생각하는 건 맞지 않다고 본다. 이건 fact에 대한 문제이다.

그런데 가끔 혹자들이 창의에 연결하여 말하는 여가가 뜻하는 남는 시간은 무엇일까 하는 의문이 든다. 아무 생각없이 휴식하는 시간은 크게 창의에 기여하지 않는다. 왠지 그럴 것 같지만 그런 사례가 보이지도 실제 체험적으로 확인되지도 않는다.
여가가 업무 기한에 대한 pressure로부터 자유로운 시간을 뜻하는걸까?
늘 데드라인이 주어지는 업무 성격에서 오는 압박이 생각 자체를 억압하는 상황?
그것은 앞에서 언급한 데로 여가의 문제는 아니라고 본다.

뇌가 충분히 쉬어야 새로운 생각이 잘 떠오른다고 판단해서 많이 쉬도록 해야 한다는 주장이라면 뇌의 어느 메커니즘과도 맞지 않아서 설득력이 없다. 오히려 정신을 끊임없이 맑게 하면서 생각을 계속 이어주는 것이 더 큰 효과를 낸다는 것이 창의의 대부분의 검증 사례라고 본다.

(정신을 맑게 하는 것은 몰입을 위한 준비랄까 불필요한 잡념들을 내리는 것이니까 역시 뇌의 활동이다. 다만 다른 신경이나 근육처럼 뇌도 계속해서 긴장할수는 없고 휴식은 필요하다. 의식에서든 무의식에서든 뇌가 계속 활동한다는 것과 뇌를 특정 생각에 집중하기 위해 강하게 활성화시키는 건 많이 다르다. 뇌의 집중적 사용은 체력적으로도 열량 소모가 매우 심하다.)

목표, 기한, 여유, 몰입/flow


목표에 기한을 두는 것과 불필요한 pressure를 줄이고 좀더 detail에 집중할 수 있도록 하는 것이 일상적 체계가 갖춰야 할 기본이 아닐까 싶다. 개인이 혹은 조직이 창의를 만들려면 이러한 기본 위에서 훨씬 더 고도화된 정신 활동들을 필요로 한다.
창의성의 저해요인으로 타의에 의해 주어지는 심리적인 pressure 외에 비슷하지만 다른 이유인 조바심, 막연한 조급함도 경계해야 한다.

조바심을 내지 않는 것을 여유라기보다는 몰입이나 flow로 보는 것이 적합하다.

창의를 위한 실천적 방향

창의와 여가에 대한 가벼워보이는 주장들을 집요하게 따지는 이유는 창의를 내는 개인과 조직을 만드는 방향이 완전히 다르기 때문이다.

창의를 발명에 이르게 하는 아이디어라고 정의를 할수 있는데 그 발명이란 흔히 문제를 푸는 새로운 방법의 고안이라고 볼수 있다.
물론 문제 자체의 재해석을 포함해서..

창의로운 개인이나 조직으로 성장하기 위해 무엇을 해야 하는가인데..

더많은 생각을 자유롭게, 하지만 밀도있게 하는 것이 가장 중요한 요소라고 보고 있다.

여가와 여유와는 다른 관점일수밖에 없다.

오히려 생각의 시간과 밀도를 더 필요로 하는 것인데.. 이를 막는 장애 요소들을 완화하는 방법으로 환경에 따라 외압적 방식의 제거, 깊이있는 사고를 다시 검토할 수 있는 전환적 사고를 돕는 여러가지 운동이나 독서를 포함한 refresh 활동의 결합, 몰입을 위한 생각의 트레이닝 등이 제안될수 있다. 배타적이지 않고 모두 함께 배치할수 있는 수단일 것이다.

창의로운 개인이나 조직으로 변모하기 위해 가장 중요한 부분과 이를 보조하는 수단들이 바뀌면 그냥 아무것도 만들어지지 않을 것이다.
보조 수단은 그 자체로는 아무런 효과가 없고 핵심 수단을 계속 사용하기 위해 도움을 주는 것들이기 때문이다.


화요일, 5월 14, 2013

이화여대 특강 : Smart Software Engineer

오늘(2013년 5월 14일) 저녁에 있었던 이화여대 컴퓨터공학과 학부 4학년을 위한 특강 자료..

강의 자료는 예전에 명지대에서 했던 자료를 재작성했는데 아쉬움이 있지만 그래도 발표자료보다 내용 전달은 잘되었을 거라 생각합니다.

아무도 주무시지 않고 경청해주셔서 감사. ^^;



Smart software engineer from Kyung Koo Yoon

P.S 강의 자료에서 보완할 부분이 세 가지 정도. 강의 자료에는 빠져 있지만 세번째 항목을 제외하면 특강 때에는 언급한 내용입니다.

a. 뇌 활동 중 인지하는 부분과 인지 못하는 부분 (의식과 무의식)
b. wicked problem의 특성들
c. 소설 읽듯이 코드를 읽는 법 (논리적 사고의 연장선 상에서 코드 구조 가설-내가 구현한다면-을 먼저 세운 후 실제 코드를 보고 그 차이를 비교하면서 다시 읽어가는 방식)


일요일, 5월 05, 2013

goal, 잉여, 목적 활동, 잡상


목표(goal)는 수준과 시간의 의미를 함께 가지고 있다.

goal을 설정하는 것과 성취하는 것은 많은 경우 하나의 연속된(반복된) 과정이다.
goal 설정 시 수준을 반영하는 간단한 문장을 요구하는 편이지만 시간에 대한 부분은 늘 reasonable한 수준이라고 implicit하게만 요구한다.

스스로는 계속해서 수준과 시간을 수정해가야 하겠지만 manager 혹은 adviser가 판단할 수 있는 건 그 사람의 능력을 고려한 합리적인 노력 여부와 방법적인 부분 정도이다.

시간에 대한 한계를 먼저 설정한다는 건 매우 어려운 일이지만 시간을 무시하는 것은 또한 잘못된 일이다. "내가 마무리할 때가 마무리하는 것이다"라는 사고는 대부분 성과 측면에서 비효율적이며, 목표를 추진하는 사람의 성장에도 도움이 되지 않는다.

수준과 시간, 그리고 성장이란 화두가 적합하지 않은 영역도 있을 것이다.
아마도 그런 영역은 goal이란 표현도 적합하지 않을 것이다.

조금 시각을 다르게 해서 근원적인 문제를 떠올려보자.

왜 우리는 더 나은 성과와 성취, 성장을 얘기하는 걸까.
하고 싶은 만큼 일하고 그 결과를 나눠가지면 안되는 걸까.
엄청난 수준으로 생산력이 향상되면 과연 그게 가능한 것일까?

나는 그렇지 않다고 판단한다.
사람 자체의 생산력이 기술의 발전에도 불구하고 아무런 비용 없이 무한의 잉여를 주지는 못할 것이라고 본다.
물론 불필요한 일들은 크게 줄일 수 있으리라고 본다. 판단에 집중할 수 있고 상대적으로 변화와 개선의 사이클도 짧아질 수 있으리라고 본다.

그럼에도 불구하고 그건 그러한 통찰을 가능하게 하는 고도의 인간 활동의 숙련을 위해 보조하는 역할들을 할 거라고 본다.

적어도 잉여의 생산은 유럽의 복지에 대한 개념이 국내의 복지에 대한 개념과 다른 것처럼 노동 없이도 인간으로서 삶을 기본 보장하는 건 가능할 것이다.
하지만, 진보를 이끄는 힘들은 여전히 goal을 필요로 한다고 본다. 인간다운 삶에 대한 인식 수준도 기술의 진보와 사회의 진보에 따라 높아진다는 점을 고려할 때 사회의 어느 부분은 그러한 진보를 이끌어야 하고 그 영역은 좀더 goal-driven한 조직이어야 한다고 본다.

인간의 목적적 활동이 앞으로 수십세기 동안은 더욱 중요한 것이 아닐까 한다.
잉여가 인간을 인간답게 하는데 도움을 주겠지만 아직 그 잉여는 지구적 영역에서 보면 현실화되지 않았다.

개인의 형태로도 조직의 형태로도 goal이 유의미하다.
특히 하나의 결과물이 보다 많은 인간들에게 영향을 주기 원한다면 더욱 그렇다.

잠시 goal과 잉여, 목적 활동에 대해 정리되지 않은 생각을 던져본다.

목적 활동과 인간의 본성 관련하여 좀더 생각해보면..


마르크스가 본건 매우 선의적 존재로서의 노동자였고 아담 스미스가 본건 매우 이기적 존재로서의 경제 주체들이었던가.

인간은 그 어느쪽도 아니고 여러 성향이 혼재할뿐인데..

공동체가 인간의 긍정적 요소를 강화하는 효과를 가진다면 가족 혹은 우리라는 단위의 소속감이 매우 중요한 역할을 한다는 뜻일게다. 그 공동체가 선별적인 집단이라면 더욱 유리할 것도 같고..

실험의 방향은 선의적 공동체가 가능한가 하는 게 제니퍼소프트가 추구하는 것과 관련된 것 같고..
성과를 내고 성장하는 기술집단 공동체가 현재 고민하는 부분인데..
기술과 선의의 강화를 같이 추구할수 있을까 둘은 상호 관련이 있을까 아직 답을 내리지 못한 실험의 화두이다.

일요일, 4월 21, 2013

SW 프로젝트를 일반적인 정량화하려는 시도는 오류

한 페친이 프로젝트 정량화에 대한 글을 올려서 몇 가지 의견을 제시한 글들을 옮겨놓습니다.

"왜 정량화를 하려는지 목적이 무엇인가요? 또 프로젝트 결과란 무엇인가요? 프로젝트별 목표가 다르기 때문에 각 목표는 있을 수 있겠지만 sw 프로젝트 일반에 대한 정량화란 말 자체가 무엇인지 생각해보기 바랍니다. 가능한 것은 프로젝트별 목표이고 그나마 정성적인 요소들은 일반화된 기준의 수치화는 시도하는 게 무의미합니다."

"SW 프로젝트 결과물이란 SI이거나 SW 솔루션이거나 서비스이거나 하겠지요. 그 결과물의 점수를 일반적으로 점수화한다는 시도 자체가 피겨 스케이팅의 점수 채점을 객관화하는 것과 왜 비슷하다고 생각하는지 모르겠구요. 그에 앞서 왜 점수화를 하려고 하는지 편의적인 발상이 아닌가 하는 부분입니다. 일반화한 정량화는 비교가 가능한 정량화인데 그것을 추구하는 의도가 무엇인가요? SW에서 가장 경계하는 것 중 하나가 단지 있으면 좋을 것 같은 것입니다. 왜 하는지 모르고 하는 거죠. SW가 그냥 일반적인 목적을 갖지 않는다면 SW를 일반화한 평가가 의미가 있는 걸까요? 비교 분석하려는 평가 목표 자체가 문제가 있다고 생각합니다. 비교라는 건 엄밀한 제약 조건을 가지고 있어야 하는데 단순 논리에 의한 일반화의 오류가 보이기 때문에 얘기했습니다. SW에 대한 일반화된 정량화보다는 목표의 엄밀한 설정이 중요하다고 생각합니다."

"SW가 어떤 목적을 달성하기 위한 해결책인데 목적과 무관한 일반화된 평가 지표.. 그것은 비현실적인 생각인데 그것을 일반화하려는 무리한 시도 자체가 SW의 질적 수준을 저해한다고 생각합니다. 국내 SW 정책이 그런 정량주의에 기반하고 있죠. SW가 아닌 SW공학이 SW 정책을 입안하고... SI 프로젝트와 같이 SW 수준이 중요하지 않은 프로젝트에서나 가능한 걸 일반화하기도 하고.."

"프로젝트 결과를 정량화하는 게 도덕적 사회적 기준으로 한다는 걸 뜻하는 것이었나요? 그조차 정량화한다는 건 다른 의미인데요.. 주장하는 프로젝트 정량화가 개발하는 사람과 사회와 무슨 관련이 있는지? 제가 얘기한 건 일반화의 오류를 얘기한 것이고, 개별 프로젝트별로 성공의 잣대가 다를 수 있고 목적이 다르기 때문에 그 목적별로 계량화의 가능성을 부정한 게 아닙니다."

"네... 프로젝트의 평가에 사회적 가치와 개발자들에 대한 부분을 포함하고 싶다는 의지는 이해가 됩니다만, 정량화(계량화, 수치화)와 일반화(보편화)에 대한 부분은 저는 반대하는 입장입니다. 사회적 가치와 개발자 부분에 대한 얘기도 평가를 왜 하느냐 하는 목적과 관련이 있는 것입니다. 언뜻 보기에 국가 정책의 평가기준으로 개발하자는 것으로 보이나 소프트웨어 공학에서 그러한 부분을 다루지 않고 있었으므로 다른 영역의 문제로 보이고, 만약 프로젝트의 평가 기준에 사회적 기여나 개발자 부분(요즘 이슈가 되고 있는 농협 프로젝트 개발자와 같은 경우를 예방하려는?)을 포함해야 한다는 주장이라면 이는 기여를 어떻게 보고 개발자 이슈를 어떻게 보완할 수 있을까 하는 세부 방침에서는 아이디어가 필요하겠지만 전반적으로 좋은 의견이라고 생각되어 찬성입니다. 하지만 그런 부분을 포함하여 소프트웨어 프로젝트 결과를 정량화해서 일반적으로 적용할 수 있느냐 하는 건 반대하는 입장입니다."

"수치화하는 거야 할 수 있지요.. KPI나 BSC 개념을 프로젝트별로 적용하는 것도 가능하고.. 하지만 일반화하는 기준은 현실성이 없어서.."

소프트웨어에 대한 평가는 필요하겠지만 객관화된 방법론이 없는 것이라고 할까..

오히려 지식산업적 특성이나 창의성을 중시하기 때문에 과정을 중시한다.
과정에서 사람들(!)이 충분히 소통하였고 충분히 기술적 깊이를 공유하였는지 그 기반 위에서 아이디어를 솔루션에 기여하였는지.. 그런 부분이 가장 중요한 부분이고...
개인별로 성장을 위한 도전적 과제 설정을 중시하고..

게다가 만드는 사람이기 때문에 외부로부터 평가받는 건 애시당초 별로이다.. 쩝..
내부적으로야 과정을 알기 때문에 한계와 아쉬움, 개선점들이 늘 있지만...

"평가를 객관화할 수 없다는 논지이구요... 그래서 주관화하겠다는 거지요... 수치화와 객관화는 조금 다른데 천편일률적으로 적용할 수 있는 수치화는 객관화라고 볼 수 있구요, 각 프로젝트 혹은 각 제품별로 목표에 따른 수치화를 한다는 것은 주관화라고 볼 수 있겠네요. 주관적 평가라고 하더라도 그 수치 기준을 잡는 건 매우 어렵구요.. 각 프로젝트 혹은 개발 과정 상에서 기준을 합리적으로 계속해서 변경해가야 한다고 생각한답니다."

"객관화된 방법론이 없고, SW 공학 쪽에서 열심히 시도를 했지만 합리적인 결과물이 나오지 못했습니다. 그건 SW를 일반적으로 범주화하여 평가하겠다는 시도가 잘못되었다고 해석하고 있다는 거구요.. 사람의 키를 침대에 맞추려는 시도를 하겠다는 건 아니겠죠?"

"XP는 객관화된 시도에 반대하여 실질적인 내실화를 시도하는 흐름입니다. 소프트웨어 공학 쪽에서는 XP를 다시 범주화하여 agile이라고 부르고 있긴 합니다만..."

오픈 소스와 기술 능력에 대한 단상

10년전 얘기지만 면접볼 때 DB를 만든다고 한 친구가 있었다.
그 친구 말을 들어보니.. postgresql을 사용하고 일부 버그 리포트를 보내는 경험을 가진 친구였다.

왜 그는 스스로를 DB creator라고 착각하고 있었을까 하는 의문을 가졌었다.

open된 source code를 들여다보고 이해하게 되고 또 이슈 리포트나 수정한 코드를 커뮤니티에 보낸다고 그 사람이 그러한 모듈을 만들 수 있는 능력이 생기는 건 아니다.

maintain과 create는 엄청난 차이가 있다.

회사가 어려움을 겪으면서 maintain해야 할 코드의 양과 제품 수가 많이 늘어났지만 제품의 아키텍처와 성격을 이해하면 (혹은 잘 이해하지 못하는 경우에도) maintain은 대부분 가능했다.

하지만 scratch부터 무언가를 만들어야 하는 건 달랐다.
새로운 제품을 만든다는 건 훨씬 더 어려운 일이며, 새로운 버전을 만든다는 것도 maintain과는 비교할 수 없는 어려운 일이다.

open source를 통해 핵심 기술이 우리 것이 되는 것처럼 착각하는 경우가 종종 있다.
그냥 그렇지 않다. 그 open source의 새 버전을 주도적으로 설계하고 핵심 모듈을 코딩할 수 있을 때 우리 것이 되는 것이다.

다만 아키텍처라도 충분히 이해하는 데서 출발했으면 한다.
create나 evolve를 할 능력은 안되더라도 use는 할 수 있다. 그건 사실이다. use는 대부분 그렇게 어렵지 않으며 코드 이해도 어느 정도의 훈련만 되어 있다면 대부분 필요 기능 중심으로 파악이 가능하다.

하지만, use하고 있다고 혹은 일부 repair하고 있다고 create할 능력이 생겼다고 착각하진 말았으면 좋겠다.
그건 좀 많이 다르다. 설계와 구현 능력이 어디서 뚝 떨어지지 않는 이상..

코딩에 대한 단상


벌써 4월 하순이다.
열흘만에 제품 하나 프로토타이핑을 하겠다고 했는데 곧 한달이 다 되어간다.

다행히 due date이 한달 정도 연기되어서 여유(?)가 생긴 것도 있고
현실적으로 주중에는 일정이 너무 빠듯하여 코딩을 하긴 어려워 주말 중심으로 코딩을 하다보니..
(주중엔 정말 혼절하는 일이 잦고.. ㅠ_ㅠ)

그래도 그와중에 진전이 되고 다시 코더로서의 흐름이 되살아나고 있다.
역시 믿을 건 내가 짠 기존 코드들.. ㅠ_ㅠ

설계를 상당히 상세한 수준으로 진행하고 난 다음에 top-down으로 코딩을 스크래치부터 시작하는데..

코딩을 하면서 느끼는 안타까움은 설계를 열심히 하는 연구원들 중에 코딩을 못하는 친구들이 종종 있다는 것..
물론 설계도 팀 회의 수준에서 편하게 발표할 때와 세미나 형식으로 앞에 나와서 할 때는 차이가 많이 나고.. 세미나 형식에서는 역시나 논리적 발표를 못하는 문제가 보통 보이지만...

문제가 뭘까 많이 생각해보고 어떻게 개선할 수 있을까 고민 중인데 현재까지 판단은

1. 앉아서 하는 팀 발표는 개별 사안을 산발적으로 편하게 얘기해도 다 이해하고 보통은 공통된 지식 기반이 많아서 일부 이슈만 가볍게 터치하면 되지만, 서서 하는 세미나는 좀더 큰 주제를 깊이있게 얘기할 것을 요구하기 때문에 훨씬 큰 논리성을 요구한다.

부담도 크고, 논리적으로 생각을 정리하기 위해서도 bottom-up과 top-down을 통해 개념 모델을 여러 번 다음어야 하는데 이런 일을 부담스러워하고 실제로 잘 극복하지 못하는 것이다.
논리가 산발적이고 나열적인 수준이라고 할까.

2. 그런 데로 작은 이슈들을 모아서 어느 정도 설계가 된 후에도 코딩을 전혀 시작하지 못하는 경우가 있는데 이건 왜 이럴까 생각을 해보면..

설계는 큰 개념 모델을 통해 논리를 전개하지만 코딩은 철저하게 bottom 수준에서 시작해야 한다. task를 가능한 한 쪼개서 해야 하고 여러 개의 task를 동시에 머리에서 전개하면 진행하기 어렵다. 즉, 여러 개의 개념들을 논리적으로 추상화하여 동시에 바라봐야 하는 설계에 비해 코딩은 철저하게 task를 쪼개서 queueing하고 하나의 task에 집중해야 하며 가능한 한 연관된 task를 줄여야만 흐름을 타고 진행할 수가 있다. (물론 논리적 설계도 실제로는 이러한 과정을 계속 거치지 않으면 심화나 문제 파악이 제대로 되지 않는다. 생각의 divide & conquer 전략이 설계와 코딩에 필수다.)

SW 논리라는 건 철저하게 검증 가능한 방법으로 진행할 필요가 있다. 검증은 대부분 코딩 없이는 불가능하다. 아무리 논리적으로 완벽해보이는 가설이라도 코드를 통해 검증하지 않으면 가설에 불과한 것이다.

SW에서 믿을 건 코딩이다. 설계가 없으면 검증할 게 없으니 허망한 일이지만, 검증되지 않는 설계는 그냥 취향일 뿐이다. 그런 취향은 누구의 문제도 해결해주지 않는다.

안타까운데 극복하고 성장할 수 있을지 모르겠다. 이건 아무리 경험을 얘기하고 조언을 줘도 본인 스스로 그 흐름, 그 감을 이해하고 고통을 극복하지 않으면 이룰 수 없는 일이다.
누구나 맨땅에서 설계하거나 코딩할 때 혼자 버려진 황량감에서부터 시작한다는 거.

이를 극복 못하면 아무런 성과를 만들기 어렵다.
여기서 좌절하면 SW가 적성에 맞지 않는 것이다.

이를 극복하는 순간 늘 든든한 성취의 기쁨이 있다는 것..

월요일, 2월 11, 2013

Open Source Software, 기부 그리고 국가 정책


Open Source Software에 대한 여러 가지 찬반이 있는데 어느 한쪽 방향으로 판단하기는 쉽지가 않다.

공개라는 점은 공유를 전제로 한다.
오픈 소스 운동이 공개를 통해 공유의 범위를 넓힘으로써 소프트웨어 혁신의 출발점 수준을 넓혀온 점은 분명하다.

그런 반면 소프트웨어 저작 활동이 지식 노동이기 때문에 지적 노동의 가치를 어떻게 할 것인가 하는 측면에서는 여러 가지 복잡한 관점이 뒤섞인다.

많은 경우 단순히 기부의 관점으로 바라본다. 지적 노동을 공유 자산화하는 관점이다. GPL, LGPL, Apache/BSD License 등은 분명 그러한 측면이 강하다. 자산을 사적 이익으로 파생화하는 것을 허용하느냐 안하느냐의 관점 차이가 있지만 이렇게 공개된 소스들이 다수의 이익을 위한 기부가 된다는 점은 동일하다.
다만 그 기부가 개인적 기부인지 혹은 상업 회사가 고용한 저작의 기부인지의 차이는 있다.

하지만 이렇게 노동이 보상되지 않는 기부라면 직업적 노동으로는 한계가 있다.
소프트웨어 저작이 직업화되지 않고 기부 활동에 그친다면 그것은 오히려 새로운 소프트웨어 혁신을 저해하는 것 아닌가.

순수한 잉여 시간 노동의 기부를 하는 전문 소프트웨어 엔지니어가 있고, 또 상대적으로 직업적 압박으로부터 자유로운 학생들의 적극적인 기부도 있다.

그외에 상업적 이익을 간접적으로 올릴 수 있는 구글 같은 기업도 적극적으로 공개 소프트웨어 활동을 통한 지적 노동의 기부에 참여한다.

애플, 오라클, IBM과 같은 전통적인 소프트웨어 기업들은 공공재화된 공개 소프트웨어들을 활용하고 또 일부 기부를 통해 공개 소프트웨어의 결과물들을 자신들이 원하는 방향으로 이끌기 위한 활동을 하기도 한다.

기부가 아닌 경우도 존재한다.
일부 제한된 기능에서만 활성화된 커뮤니티를 통해 협업적으로 기부를 하고, 핵심 기능들은 상업용으로 비공개하는 방식을 통해 제한된 커뮤니티 버전만 기부하고 그 커뮤니티를 주도적으로 이끌며 상업용 버전은 판매함으로써 커뮤니티를 제한적으로 공유하고, 활성도를 통한 브랜드 가치를 높이는 데 사용하기도 한다.

우리나라에서 소프트웨어 정책을 국가적으로 공개 소프트웨어를 사용하게 하려는 움직임이 있다고 한다.

일반적으로 소프트웨어 기부는 직업적 소프트웨어 엔지니어들이 잉여의 시간을 활용하여 하거나 아니면 전문 기업들이 필요에 의해 기부하는 경우가 대부분이다. 아니면 뛰어난 학생들이나 공유를 신념으로 하는 엔지니어의 기부가 있을 것이다.

"왜?" 어떤 목적으로 하는지 궁금하지 않을 수 없다. 우리나라 소프트웨어 산업의 문제가 공유되지 않아서였던가? 공유 자체는 국적이 없지만, 결국 각 소프트웨어별로 몇몇 핵심 엔지니어들에 의해 주도된다는 점을 생각해보면 국적이 현실적으로는 존재할 수 밖에 없다.
어떻게 그런 핵심 엔지니어들을 양성하고 또 그들의 잉여를 기부할 수 있는 사회를 만들 수 있을까라는 생각을 해보면 정말 우리 소프트웨어 산업의 현실이 이러한 공유로의 기부를 주도하고 새로운 혁신을 만드는 처방이 국가적으로 공개 소프트웨어 사용을 강제하는 것일까 하는 의문이 든다.

잉여가 없는 사회에서 잉여에 의해 만들어진 것들을 사용하도록 강제한다는 것, 그냥 소프트웨어 포기 정책은 아닐까 싶다.

P.S 소프트웨어를 전혀 모르는 사람들이 오픈 소스를 하면 많은 사람들이 참여하기 때문에 버그도 없어지고 quality도 높아지는 것처럼 이야기를 하는 경우가 있는데 현실은 그렇지 않다.
뛰어난 엔지니어들이 참여하는 관심이 높은 일부 프로젝트만 코드 퀄리티가 높아지고 그렇지 않은 대부분의 공개 코드들은 무관심 속에 그저 공개만 되어 있을 뿐이다. 상용보다 공개 소프트웨어가 더 퀄리티가 높을 것이라는 주장은 비현실적이다. 그렇지 않다면 공개 소프트웨어의 M/A 서비스가 상업성을 가질 수 없을 것이다.

토요일, 1월 26, 2013

더 재미있게 사는 10 가지 간단한 방법

How To Be More Interesting (In 10 Simple Steps) - Forbes

어떻게 하면 좀더 재미있게 살 수 있을까?

Software를 얼마나 재미있게 할 수 있을까?

늘 갖고 있는 생각인데 저는 대부분 매우 재미를 가지고 일을 하는 편입니다.
새로운 것을 알게 되는 것이 매우 즐겁고 여러 사람들과 토론 속에서 문제를 해결해가는 과정은 때론 신비롭기도 하고 놀랍기도 합니다. 그 놀라움의 대상은 뛰어난 아이디어를 내는 다른 연구원일수도 있고 문제를 여러 토론 속에서 얼떨결에 해결해내고 있는 자신일수도 있습니다.

개인과 소규모 그룹, 그리고 그보다 더 큰 그룹을 유기적으로 연결하여 혁신 아이디어 체계를 구축하는 일이 현재의 본업이라고 생각하는데 그 출발점은 각 성원들이 흥미를 가지고 자신의 일과 관심 속에서 아이디어를 만들고 공유하고 또 발전시키는 것이라고 생각합니다.

재미있게 일하는 것은 여러 가지 아이디어를 적극적으로 매사에 적용해보는 것이 아닐까 생각해봅니다. 또 일을 하는 것이 아니라 늘 같지 않은 일로 만들 수 있는 적극성이 필요한 것이지요. 다행히 제 일인 소프트웨어는 늘 아이디어를 필요로 하고 아이디어에 따라 크게 달라집니다.

이 글은 벤다이어그램이나 그래프로 표현한 것이 재미있어서 옮겨봅니다.

1. 탐험하라.
아이디어, 장소, 의견을 탐험하라. 에코 체임버 안에 모든 지루한 사람들은 갇혀 있다.
(해야 할 일과 가야할 곳이 만나는 곳이 무한의 영역이라는 표현 재미있습니다.)







2. 발견한 것을 공유하라.
발견한 것을 인심좋게 공유하라. 모든 사람이 당신의 탐험을 함께 하지 않았다. 다른 사람들이 당신의 탐험, 모험을 대리경험할 수 있도록 하라.
(발견을 공유하지 않으면 발견이 많더라도 dumb 벙어리일 뿐이고 발견이 많고 이를 공유를 많이 하는 사람이 smart하다는 것. 공유하는 과정에서 더 발견이 많아지고 깨달음도 커지고 당연히 smart해지겠지요)






3. 무언가를 하라. 무엇이든 하라.
춤추고, 얘기하고, 만들고, 사람들을 사귀고, 놀고, 돕고, 만들어라.
무엇을 하는지가 중요한 게 아니라 무언가를 한다는 게 중요하다.
가만히 앉아 불만만 터뜨리는 것은 무언가를 하는 게 아니라 아무것도 안하는 것이다.
(먹고 자고 TV만 보고 이래서 흥미를 잃고 슬프게 되는 것이다.)






4. 타고난 특이 기질을 포용하라. 
누구도 아주 정상일 순 없다. 누구나 자신마다 고유한 변덕이나 사고방식이 있다. 이것들을 숨기려고만 하지 말라. 이것들이 흥미를 일으켜줄 수 있다.
(그림에서 보듯이 이상함은 특별한 존재로 만들어준다)






5. 이유 있게 행동하라.
어떤 것에 대해서도 막연히 비난하지 않는다면 아무도 당신을 비난하지 않을 것이다.
(이유와 열정이 둘 다 있어야 목적성이 생긴다)






6. 잘난척하지 말라.
자의식은 아이디어를 가로막는다. 알고 있는 지식 이상으로 오만하다면 다른 사람들이 기피할 것이다.
(조잡함과 지루함과 오류가 모두 자존심, 자기 도취와 관련되어 있다)







7. 일단 해보라.
일단 해보라. 새로운 아이디어를 가지고 뭔가를 해보라. 뭔가 특이한 것을 해보라.
항상 편안한 곳에만 머무른다면 결코 성장하지 못한다.
(왜? 해볼께! 여기가 바로 성장의 기회)








8. 시류를 따르지 말라.
다른 모든 사람이 하고 있다면 이미 늦은 것이다. 당신만의 일을 하라. 당신 스스로 만든 멋진 마차에 다른 사람들이 올라타게 될 것이다. 남들에게 끌려다니는 것보다 직접 운전하는 것이 훨씬 더 재미있다.
(따라하는 일이 많을수록 아이디어에 대한 갈망만 늘어날 것이다)







9. 용기를 키워라.
반대되는 의견을 갖고 기대치 않았던 길을 선택하는 데는 용기가 필요하다.  용기가 없다면 늘 주변에서 용기가 실제 있는 사람에 대한 얘기만 하게 될 것이다.
(두려움과 삶의 질은 반비례한다. 두려움을 극복하는 용기가 삶의 질을 높인다)







10. 잔소리꾼들 말을 듣지 말라.
지루하지만 안전하다. 아마도 이렇게 행동할지도 모르겠다. 잔소리꾼들은 모험을 할 수 있었지만, 해야 했었지만, 용기를 내지 않았던 사람들이다. 아마도 당신이 모험을 한다면 화를 낼 사람들일 것이다.
(할 수 있지만 하지 않으면 괴로울 뿐이다)