[부자 아빠가 싫어하는 말]

• 모두가 이렇게 하니까 우리도 그렇게 해야만 해.
• 할 수 없다.

• 당신이 그 일을 할 수 있다고는 생각하지 않습니다.

[부자 아빠가 강조하는 바]

• 똑똑한 사람은 자기보다 더 똑똑한 사람들을 고용한다.
• 학교는 좋은 고용주가 아니라, 좋은 직원들을 기르는 곳이다.

• 자산과 부채의 차이를 알고, 부채와 지출을 줄이도록 노력하며, 수입을 창출할 수 있는 자산을 사는 데만 신경을 써야한다.
• 부자는 자산을 산다. 가난한 사람들은 지출만 한다. 중산층은 부채를 사면서 자산이라고 생각한다.

• 내가 없어도 되는 사업 : 주인은 나지만, 다른 사람들이 운영
• 주식
• 채권
• 뮤추얼 펀드(최근에는 비추천)
• 수입을 창출하는 부동산
• 어음이나 차용증
• 지적 재산권에서 나오는 로열티 : 음악, 원고, 특허 등
• 그 밖의 가치가 있거나 수입을 창출하거나 즉시 시장성이 있는 것

• 회계 지식
• 투자 지식
• 시장에 대한 지식
• 법률 지식 - 세금 혜택, 소송에서 보호를 받음

[사람들이 부자가 되지 못하는 다섯 가지 이유]

• 두려움 : 일찍 투자를 시작하고, 잃는 것에 대한 두려움을 없애자
• 냉소주의 : 나는 똑똑하지 않아, 내가 투자한 후에 경제가 무너지면 어쩌지? 이런 생각을 하지 말자
• 게으름
• 나쁜 습관
• 거만함 : 끊임 없이 학습하라

Ref) 부자 아빠 가난한 아빠 1

7월 읽은 책 목록

[리팩토링] 마틴 파울러 2017.06.26 ~ 2017.07.10

[비즈니스 블록체인] 윌리엄 무가야 2017.07.11 ~ 2017.07.13

[부분과 전체] 베르너 하이젠베르크 2017.07.18 ~ 2017.07.29

  7월에는 철학, 컴퓨터 공학, 과학 책 등을 가리지 않고 읽었다. [존재와 시간]이 너무 어려와서 서론만 읽고 나중으로 미룬 것이 아쉬웠다. 이 책은 추석에 시간이 많을 때 천천히 읽으려고 한다. 당분간 금융 지식을 쌓기 위해 관련된 책을 읽을 것 같다. [부자들의 음모]라는 책을 읽고 영향을 많이 받았기 때문이다. 당장 먹고 살만할 때, 나중을 위해 대비하기 위해서다.

 [부자 아빠 가난한 아빠] 시리즈로 인기를 끈 로버트 기요사키라는 사람이 쓴 책이다. 어떤 책을 볼까 하다가 제테크 책을 알아보던 중, 2012년 전에 집필된 제테크 책들이 사내 도서관에 비치되어있는 것을 확인하고 빌렸다. 최근 사내도서관의 신간 도서는 전부 업무와 관련된 도서만 구매하기 때문에, 이런 책들이 있는지 처음 알았다.

  이 책에서 저자가 주장하는 바는, 일반적인 학교 교육에서는 금융 지식에 대해 가르치지 않고, 막연하게 공부를 열심히 해서 좋은 직장에 들어가기 위한 교육만 가르친다고 한다. 좋은 학교에 나와서 기껏해봐야 의사나 변호사 밖에 될 수 없고, 금융 소득을 벌어들이는 능력은 가르쳐주지 않는 것이다. 이런 것들은 과거에 부자들이 자신들이 원하는 교육 체계를 세웠기 때문이다. 부자들을 위해서 일을 하고나서 임금을 받는 시스템을 구축하고 싶었기 때문에, 금융 지식에 대한 교육을 가르치지 않기로 했다는 점이다.

  저자는 자본 이득과 현금 흐름에 대한 차이를 알고, 현금 흐름에 따라 투자를 하기 권장한다. 자본 이득과 현금 흐름을 다음과 같이 정의한다.

[자본 이득]

• 부동산(거주나 건물 가격의 상승을 위해 구매한), 주식, 채권, 뮤추얼 펀드, 연금, 저축 등
• 자기 자본 가치가 떨어질 경우, 손실이 막대함

• 임대 사업(매달 현금이 들어오는 부동산), 인세와 같은 지적 재산권, 자기 회사 설립 등
• 가치가 떨어져도 손실이 거의 발생하지 않음

  일반적인 사람들이 자본 이득에만 관심을 가지고, 현금 흐름에는 관심을 가지지 않는다고 말하고 있다. 자본 이득에만 투자를 이유를 다음과 같이 열거해놨다.

• 사람들이 대부분 그 차이를 알지 못한다.
• 경제가 성장할 경우, 자본 이득을 취하기가 쉽다.
• 많은 금융 지식이 필요하다. 자본 이득은 사놓고 가격이 오르길 기다리기만 하면 되지만, 현금 흐름은 잠재적인 수입과 비용에 대해 알아야 하고, 투자 계획을 세워야 한다.
• 사람들은 게으르다. 오늘을 위해만 살 뿐 내일은 걱정하지 않는다.
• 집 값이나 주식이 폭락하면 정부가 해결해 줄 것이라고 기대한다.

  [부분과 전체] 이 책은 독일의 이론물리학자 베르너 하이젠베르크가 죽기 얼마 전에 자신의 생애동안 연구를 하면서 다른 지식인들과 나눴던 대화를 회고한 책이다. 책에서 거론된 사람들 중에는 닐스 보어, 아인슈타인, 조머펠트, 플랑크 등 과학자들이 대부분이다. 이들과 나눴던 내용을 살펴보면 특정 과학에 대한 자신의 이론이 맞는지 증명하기 위해 논리적으로 상대방을 설득하기 위한 기술들이 엿보인다.

   하이젠베르크는 '물질은 입자임과 동시에 파동이다'라는 이론을 통해 노벨 물리학상을 받은 것으로 유명하다. 이 이론을 토대로 양자역학의 발전에 큰 기여를 하였다. 2차 대전 때에는 나치의 압박하에 어쩔 수 없이 독일군을 위해 일을 했는데, 이 때 독일군이 핵무기를 사용하지 않도록 하기 위해 일부러 핵무기 개발을 하지 않았다. 하지만, 미국이 핵무기를 사용했을 때 자신의 이론을 토대로 많은 사람들을 죽였기 때문에 과학자로서 자책감을 느꼈다고 한다.

  책은 하이젠베르크가 어렸을 때부터 나이가 들었을 때까지 나눴던 대화 들의 순서로 진행된다. 여러 과학자들과 대화를 나눌 때 특정 과학 이론이 등장하긴 하지만, 이론에 대한 수식이 나타나지 않기 때문에 인터넷에서 이론에 대한 개념만 찾아본다면 이 책을 읽는데에는 크게 문제가 없다. 그리고 양자역학에 대한 대화 뿐만 아니라, 2차대전 상황에서 나치에 대한 자신의 입장 등 정치, 사회적 대화들을 많이 살펴볼 수 있다. 이런 대화들을 통해서 하이젠베르크의 통찰력이나 논리력, 그리고 나치에 맞서 독일을 다시 구해내겠다는 강력한 의지 들도 엿볼 수 있다.

  이 책을 구매할 때 같이 산 책이 있는데, 바로 하이데거의 [존재와 시간] 이었다. 첫 장의 서론을 읽고 이해가 되지 않아 포기하고, 곧 바로 [부분과 전체]를 읽기로 마음먹었다. [존재와 시간]은 추석 연휴 때 읽는 것으로 하고, 그 때를 대비하여 인문학 책을 계속 읽어 책 읽는 능력을 키워야할 것 같다. 

  [리팩토링]이라는 이름의 이 책은 컴퓨터 공학에서 아주 유명한 책이면서 저자인 마틴 파울러를 유명하게 만든 책이기도 하다. 그리고 켄트 백과 같은 사람들도 이 책의 집필에 참여하였다. 이 책은 객체지향 프로그래밍에서 코드의 유지보수를 위한 교과서와 같은 책이다. 이 책의 초판이 나온 지 10년이 훨씬 넘었지만, 객체지향 프로그래밍에 있어서 놓치면 안되는 것들을 아직까지 많이 알려주고 있다.

  이 책은 리팩토링에 대한 개론을 언급하는 것으로 시작한다. 저자는 리팩토링을 수행하면 코드 관리뿐만 아니라, 프로그램의 성능도 향상시킬 수 있다고 주장한다. 그 뒤에, 수 십가지의 리팩토링 기법을 소개한다. 평소에 당연하다고 생각했던 사항부터, 전혀 알지 못한 내용까지 책에서 발견할 수 있었다. 책의 마지막에는 작은 리팩토링 사항들을 조합하여 여러 단계의 큰 리팩토링을 실시하는 예를 소개하는 것으로 이 책을 마친다.

  리팩토링에 관한 기법은 웹 상에서 쉽게 찾아서 볼 수 있고, 지금은 이보다 더 많은 리팩토링 방법들이 많이 있기 때문에 블로그에 따로 기록하지는 않았다. 하지만 아래 링크에 리팩토링에 대한 개론을 남겨놓았다.

http://goscala.tistory.com/category/%EC%BB%B4%ED%93%A8%ED%84%B0%EA%B3%B5%ED%95%99/Refactoring

  리팩토링 개론에서 가장 흥미롭게 본 부분은, 상급자와의 의견이 맞지 않아 리팩토링을 하지 말라는 지침(예를 들어 마감 일정이 얼마 남지 않아 시간이 모자라서...)을 받았을 때 상급자 몰래 리팩토링을 실시하는 것이 나중에 프로그램의 질을 위해서 더 좋다는 내용을 주장한다. 실제로 프로젝트를 완성했을 때 유지보수를 하는 것은 관리자가 하는 것이 아니라, 실무자가 수행을 해야한다. 유지보수 관점에서 힘든 사항들이 처음에는 드러나지 않기 때문에, 나중을 위해서 리팩토링을 수시로 수행하는 것이 맞다고 생각한다. 하지만, 이런 것들을 생각하는 관리자가 몇이나 있을까 싶다. 당장의 눈 앞의 성과만을 위해서 예외 처리나 유닛~필드 테스트까지 수행을 생각하는 것을 꺼려하는 관리자가 많다. 그 이유가 너무 많지만, 일단 본인들이 프로그래밍에 대한 경험이 별로 없이 관리자의 위치로 올라간 탓이 크다. 사내에서 프로그래밍 경험이 풍부한 관리자가 언제쯤 나타날지가 궁금하다. 아마도 지금 재직하고 있는 부서에서는 그럴 가능성이 아주 낮다. 정치를 잘하는 사람보다는 기술적으로 실력이 뛰어난 관리자를 찾아 떠나야할 시점이다.

프로젝트 폴더에서 현재 업로드 되어있는 파일을 제외한 모든 파일을 ignore 하기

  현재 git에 push 되어있는 코드를 제외한, 나머지 불필요한 파일들이 새로 추가된 경우가 있다. 이 때, 모든 파일들을 직접 .gitignore에 기록하는 것은 참 힘들다. 이 때, shell script를 이용하여 .gitignore 파일에 추가하는 방법이 있다.

git status --porcelain | grep '^??' | cut -c4- >> .gitignore

  .gitignore 파일이 없을 경우, .gitignore 파일을 생성시키면서 업로드 목록을 제외하려면 다음과 같이 실행한다.

echo "$(git status --porcelain | grep '^??' | cut -c4-)" > .gitignore

git으로 코드 작성 시 원하지 않는 파일을 업로드 안하기

  git으로 코드를 작성해 배포를 할 때, 업로드를 하지 않기 위한 파일들이 존재할 때가 있다. 이 때, .gitignore 파일을 작성하여, 불필요한 파일들을 업로드 목록에서 제거한다.

- git 프로젝트 디렉토리에서 .gitignore 파일 작성 후에 Terminal에 다음과 같이 입력

git rm -r --cached .
git add *
git commit -m ".gitignore update"
git push
git push -u origin master

Github에 Local Project를 처음 올릴 때, Command line을 통하여 올리는 방법

- github.com 에서 프로젝트를 생성한 뒤, repository 주소를 알아놓음

- Terminal 프로그램에서 Local Project 폴더로 이동한 후, 다음과 같이 명령어를 실행

git init
git add .
git commit -m "[My Message]"
git remote add origin [address of git repository]
git push origin master

Big Data Analysis with Scala and Spark

  week2에서는 RDD를 가지고 Reduction Operation 작업을 어떻게 하는지 설명한다. 또, Pair RDD 및 이를 활용한 데이터 조작 방법 등을 설명한다. RDD에서 Transformation 작업을 수행할 때마다 해당 작업을 실행하는 것이 아닌, Lazy Evaluation을 활용하여 작업을 뒤로 미룬다. 그러다가 특정 순간에 Action 작업을 수행하면 뒤로 미뤄진 작업들과 함께 한꺼번에 작업을 수행하여 결과물을 내놓는다. 마지막으로 여러 RDD들을 하나로 합치는 Join 동작도 설명한다. Spark에서 사용하는 명령어들은 SQL에서 사용하는 명령어와 비슷한 명령어를 가지고 있다.

  week3에서는 다행스럽게도(?) 과제가 없다. 대신에 아주 중요한 개념인 Shuffling을 설명한다. Shuffling은 Cluster간에 데이터들이 네트워크를 통하여 이동한다는 개념이다. 예를 들어 key를 가진 Pair RDD에서 join()과 같은 작업을 수행하면 Cluster 안에서 기준없이 섞인 key, data 셋들이 특정한 key로 구분된 Partition들로 각 Cluster에서의 데이터들이 이동한다는 개념이다. 그래서, Shuffling 작업이 수행되기 전에, 불필요한 작업들을 모두 수행하고(reduce작업 등을 통한 데이터 축소) 필요할 때에 Shuffling 작업을 수행하라는 것이 week3 의 전반적인 내용이다. 또 Partition을 효율적으로 나누는 여러가지 방법 등을 소개한다.

  week4는 마지막 주차인데, 내가 생각하기에는 두 주 분량의 강의를 하나로 합친 것과 같은 중요함과 강의 량을 보여주고 있다. 우선 Structured vs Unstructured Data를 설명하면서 Structured data나 semi-structured data에서는 Spark SQL 및 DataFrames를 사용하라고 주장한다. DataFrame는 csv, json 등 기존에 알려진 데이터 형식을 이용하여 Query를 작성했을 때, RDD 및 Scala Higher-order Function을 직접 사용하는 것처럼 번거로운 작업을 하지 않고도 아주 최적화된 함수들을 제공한다. 프로그래밍을 할 때, 데이터를 다루는 일을 하다보면 DataBase에서 등장하는 Query나 각종 이론들이 계속 등장한다. DB에 관한 개념이 부족하다면, 나처럼 DataFrame을 다룰 때 오히려 RDD를 다룰 때보다 더 애를 먹을 수 있다. 마지막으로, DataSets에 대하여 설명한다. DataSet은 Spark 2.0 이후에 등장한 개념으로, RDD와 DataFrame를 합쳐 놓은 것이라고 간단하게 생각할 수 있다. RDD의 Higher-Order Function 및 DataFrame의 Query 등을 함께 사용할 수 있다.

Parallel programming

  week3 부터는 Scala에서 쓰이는 다양한 Data-Parallel Programming 을 알려준다. 기존 Collection에서 .par 함수를 호출하면 바로 Parallel한 Collection을 얻을 수 있다. 그리고 FoldLeft 는 Parallel 하게 동작할 수 없다는 것을 설명한다.

  foldLeft의 정의는 다음과 같다.

foldLeft[B](z: B)(f: (B, A) => B): B

  foldLeft를 진행 중, f 함수의 리턴 타입 A가 B와 같지 않다면, foldLeft의 다음번 차례에서 함수 매개변수 인자인 B의 위치에 들어갈 수 없다. 이러한 특성 때문에 foldLeft는 Palallel하게 사용할 수 없다.

  foldLeft 대신, fold와 foldLeft를 조합한 aggregate 함수를 제공한다. aggregate 함수는 재귀함수를 통해 Parallel 하게 fold 함수를 진행하다가 특정 threshold보다 낮을 경우에 foldLeft를 수행한 뒤, 다시 합치는 모습을 보여준다.

  그리고, week 3에서 K-means 알고리즘을 토대로한 연습문제를 제공하는데, 이런 심도있는 연습문제를 통해 Parallel Programming이나 Scala 등의 Functional Programming이 어떤 방식으로 쓰일 수 있는지 알려준다.

  마지막 week4에서는 Combinator이라는 trait와(Java에서의 Interface와 비슷한 개념) Conc-tree라는 듣도 보도 못한 새로운 자료구조를 알려준다. Scala의 Collection 들은 Combinator trait의 combine() 함수를 통하여 Parallel 하게 동작하기 위해 쪼개졌던 작은 sub-collection 들을 다시 합치는 동작을 제공한다. Array, Set, Tree 등을 combine할 때 최적화 하기 위한 동작이 서로 다르기 때문에, combine() 함수를 통하여 추상화를 제공한다고 볼 수 있다.

  week4 의 마지막으로 가면서 Conc-Tree 자료구조와 이를 Parallel하게 동작시키기 위한 Combiners 를 소개한다. Conc-Tree 에 특정 element를 추가할 때 걸리는 시간 O(1) 과 Conc-Tree 에 다른 Conc-Tree를 Concatenation을 할 때 O(log N) 을 보장하기 위해 Binary Count System을 사용한다. Concatenation을 할 때 트리의 노드 균형을 맞추기 위해 AVL tree나 Red-Black Tree에서 볼 수 있는 회전 동작도 구현하고 있다. 연습문제를 풀 때, Conc-Tree를 직접 구현하지 않기 때문에 자세하게 살펴보지는 않았지만, 이런 자료구조가 있다는 것을 알고 나중에 사용하면 될 것 같다는 생각이 들었다.

  Parallel Programming 수업을 들었을 때 중요하게 생각한 점은, Associativity 와 Commutativity 같은 수학 개념이 사용되었다는 것이다. 고 수준의 프로그래밍을 할 때, 항상 나의 발목을 잡는 것이 수학 이론이다. 알고리즘에서만 수학이 사용되는줄 알았지만, 다양한 분야에서 수학을 기본으로 프로그래밍을 하고 있다. 처음부터 수학을 다시 공부할 수는 없으니, 문제를 해결하려고 할 때 수학이 등장한다면, 대충 넘어가지 말고 머리 속에 꾸겨 넣어서 다음 task로 넘어가야 겠다.