오래된 SW 엔지니어의 평생 공부

업무를 하다 보면, 시키는 일만 하다가 문제를 해결하는 단계를 거쳐 문제를 만드는 단계를 거쳐 올라가게 되는 것을 경험하게 된다. 나는 이게 리더가 되어 가는 과정이라고 생각한다. 내 경험으로 비추어 보면, 소프트웨어 개발하는 사람들의 중요하게 생각하는 경력 방향이 조금씩 바뀐 것 같다. 어느 것이 더 중요하고 덜 중요하다고 생각하지는 않는다. 하지만, 방향성을 가지고 가는 것이 필요한 역량을 준비하는데 효율적이지 않을까 하는 생각한다.

개발자의 경력 방향

내가 생각하는 경력의 방향은 3가지 이다.

내 경력의 초창기에는 과제의 대한 넓은 이해를 바탕으로 제품 출시에 대해서 Risk가 되는 항목을 관리하는 것이 주요 목표인 Project Leader가 중요했다. 이런 부분에 대해서는 PMPBOK[1]과 같이 일반적인 프로젝트 관리(Project Management) 혹은 SW만을 위한 RUP(Rational Unified Process)와 같은 방법론을 중요하게 여기었다. 지금도 큰 회사들은 범위가 큰 제품을 다루기 때문에 이러한 프로세스를 도입하거나 혹은 자체 운영 프로세스를 운용하고 있다. 여러한 운영하는 역할을 가진 Leader들은 여전히 중요한 역할을 하고 있다.

또한, Agile Software가 소개 되면서, 목표 중심의 접근 방법에서 사람 중심, 소통 중심의 작고 기민한 개발 방법으로의 변화가 이루어지고 있다. RUP에서도 이러한 Agile한 접근 방법은 XP(eXtream Programming), Scrum, Kanban등 다양한 Practice들이 소개 되었고, 계속해서 표면적인 Practice만이 아닌 가치와 원칙들을 기반으로 시도되고 있다.

소프트웨어 개발자도 결국은 제품을 만드는 사람이고, 이 제품은 요구 사항을 구현하여 상품화 하는 것이다. 제품의 요구 사항은 당장 스마트폰만 보더라도 어플리케이션, 미들웨어, 시스템 소프트웨어와 같은 큰 분류가 있고, 좀 더 세밀하게 들어가면 해당 분야가 필요로 하는 지식이 전혀 다르다.

단적인 예로 Video 어플리케이션만 하더라도 비디오를 재생하는 부분, 그리고 압축되어 있는 비디오를 사용자가 볼 수 있도록 압축을 풀어 주는 부분,그리고 이 압축 풀린 비디오를 화면에 뿌려 주는 부분 그리고 이 동작을 통합하여 사용자와 연동하는 부분으로 세세하게 나눌 수 있다. 이러한 기술 분야(Technology Domain)가 엄밀히 말하면 모두 다르다고 할 수 있다. 비디오 압축을 풀어주는 Video CODEC 그리고 압축 풀린 화면을 그려주는 Graphic 부부분으로 Domain이 다르다고 할 수 있다. 이러한 분야별로 전문가인 Domain Expert들이 필요하게 되었고 이러한 인력들이 Technical Leader들이 떠오르기 시작했다.

요즘 소프트웨어 회사에서 인력 채용을 할 때에는 코딩 면접을 본다. 예전의 기술 면접과는 차이가 있다. 관련 분야의 Knowledge를 측정 하기 보다는 자료구조 및 컴퓨터 알고리즘에 대한 기본적인 이해, 그리고 실재로 프로그래밍을 할 수 있는 소양, 센스를 확인하는 듯한 느낌이 강하다. 즉, 회사에서 바라는 Software 개발자의 인재상이 바뀌고 있다는 생각이 든다. 이러한 개발 역량은 과제를 운영하거나 특정 분야의 지식으로 만으로는 부족하다고 보고, 실재로 작동하고 복잡한 소프트웨어를 설계하고 구현할 수 있는 인력들을 원하며, 이러한 소프트웨어 개발 역량을 가진 사람들을 Software Architect라고 부르고 있다. 

후배들에게 하는 조언

나는 위에서 이야기 한 Project Leader, Domain Expert 그리고 Software Architect를 개발자의 Career Path로 보고 후배들에게 조언을 하고는 한다.

사람들과 Interaction을 좋아하면서, 제품을 만들어 가는 관점에서 소프트웨어 개발에 관심이 높은 사람들에게는 Project Leader와 관련 내용을 소개하곤 한다. 특히, Agile Software Development에 대해서 많이 설명한다. 나는 XP의 Pair Programming이나 TDD 등에 대해서 관심을 가지고 있었었고, 지금은 Kanban을 일부 적용하면서 사람들과 소통에 대해서 관심을 가지고 있다. 이러한 부분을 소개하면서, 반응을 살피고, 관련 내용, 교육을 소개한다. 자격증도 있어서, 관심있으면 획득하는 것도 좋다고는 이야기 하지만, 꼭 필요한 것은 아니라는 내 생각도 이야기 해준다.

대학원 석사/박사를 희망하는 사람도 종종 있다. 요즘 유행하는 Machine Learning과 같은 학문적인 관심을 가지고 있는 사람들이다. 석사/박사를 하게 되면 무엇이 다른가에 대한 질문이기도 하다. 나는 학사는 내 전공이 어떤 분야인지 이해하는 과정이고, 석사는 해당 분야의 주어진 문제를 푸는 방법을 배우는 과정이라 설명한다. 박사는 한마디로 인류 지식의 지평을 넓히는 사람이라고이야기 한다. 즉, 특정 분야의 "의미있는 문제"를 찾아 다른 사람이 해보지 않은 "새로운 방법(Novel Way)"으로 해결하는 것이라고 설명한다. 이 방향이 Domain Expert가 되어 가는 과정이다. 

Software 개발 역량은(SW Development Competency)는 개발자로의 기본 능력이라고 생각한다. 그래서, 아직은 많은 고민을 하지 못한 후배들에게는 이 부분을 설명한다. 컴퓨터 언어, 알고리즘, 그리고는 설계 관련 이야기를 한다.  이와 같이 이야기 하는 이유는 두 가지 정도이다.

하나는 이 부분이 Software 개발자로서의 경쟁력이기 때문이다. 이야기 한데로, 여러 회사들이 인력 선발할 때 살피는 기본적인 부분이다. 신입이든 경력이든 개발자로 살아 남으려면 기본적으로 이부분이 준비 되어 있어야 한다.

또 하나는 생산성이 다르기 때문이다. 실재 업무는 새로운 기능을 구현을 하거나 기존 코드 (Legacy Code)의 이슈를 수정하는 것이 시작이다. 이 때, Software 개발 능력은 매일 사용해야 한다. 그렇기 때문에, 이 능력의 높고 낮음에 따라 생산성에서 큰 차이가 발생한다.

그래서 나는?

위의 어느 것을 선택하여 나아가던 선택의 문제이지 어느 것이 더 낮다고 이야기 하지는 않는다. 개인 선호도의 문제이기도 하다. 물론, 무시하기 어려운 것은 인력 시장의 선호도 혹은 관련 분야의 전망 또한 선택하는 사람 입장에서는 고려해야 할 부분일 수도 있다. 

하지만, 정말 훌륭한 Technical Leader로 가는 길은 여러 갈래길 나뉘어 져 있지만, 어느 순간에는 만나고 어느 순간에는 갈라진다고 생각한다. 위에서 이야기 한 3가지 방향 중 어떠한 것을 가더라도 서로를 완전히 때어 놓을 수 없고, 다시 만난다. 소프트웨어 제품을 만들다 보면, 사람들과 소통하고 Risk를 관리하는 방법을 배우게 된다. 특정 제품의 해당 기능을 구현하다 보면, 관련 Domain Knowledge가 쌓인다. 실재 개발을 하다 보면, 관련 컴퓨터 언어, 알고리즘 그리고 설계를 배우게 된다. 즉, 업무를 통해서 학습하게 된다. 

중요한 것은, 이런 부분을 자세히 살피지 않으면 알지 못할 수도 있다. 자신이 있는 단계에서 한단계 더 넘어 서려면 더더욱 그러하다. 그래서, 깨어 있어야 하고 공부해야 한다고 생각한다.

지금의 나는 다행이도 여러 가지 경험을 하고 있고, 오늘도 배우면서 좀 더 성장한 내가 되기 위해 고민하고 있다. 그래야, 후배들에게도 그들이 고민하는 부분에 대해서 나의 생각을 이야기 해주고, 그들이 선택하여 나아갈 수 있도록 해줄 수 있다고 믿고 있다.

[1] PMBOK Guide and Standard, https://www.pmi.org/pmbok-guide-standards

다시 공부를 시작하고 나서 부터, 다른 사람들은 어떻게 하는지 살펴 보게 되었다. 몇 가지 "사례"들을 찾았는데, 여기에 정리해 본다. 읽어 보고 공감이 가는 부분에 대해서 고민해 보라는 것이지, 이 것이 옳다고 주장하는 것은 아니다. 나도 공감이 가는 부분이 있고, 이 부분은 아니지 않나 하는 회의가 드는 부분도 있다.

소프트웨어 엔지니어의 역량 수준

회사의 어느 강의를 듣고 알게된 Programmer Competency Matrix[1]이다. 여기에는 Computer Science, Software Engineering, Programming, Experience, Knowledge의 큰 주제별로 나누고, 그 아래 상세 항목을 나누고 있다. 그리고, 상세 항목별로 개발자의 Level의 0에서 3까지 4단계로 설명하고 있다. 이 분야에 대해서 모두 동의 하지는 않지만, 특정 항목별 Level의 차이점이 있고 그 깊이가 다를 수 있다는 부분에 대해서는 공감이 간다. Computer Science 분야는 data structures, algorithms, System Programming으로 나누고 있고 입사 시험에 해당되는 코딩 시험들이 이 부분에 대해서 다루고 있으니 참고할만 하다. 

더 이상 초보 개발자가 아니라는 사실을 언제 알게 되나요? [2]

이 글도 Quora에서 발견한 글을 한글로 번역한 내용이지만, 공감이 가는 짧은 내용들이 있어서 몇가지 인용하고 짧은 생각을 추가해 본다.

"..다른 사람에게 코드 동작 방법을 설명하면서 다른 사람을 이해 시킨다."  이 문장은 여러 공부 방법 중에 통용 되는 것이다. 즉, 자기가 이해한 것을 다른 사람에게 가르치다 보면 더 배운다는 내용이다. "다른 사람의 도움 요청에 올바른 길로 이끌고 있음을 확신한다." 이부분도 유사한 내용이다. 

"필요한 정보를 찾는 장소를 안다." 요즘은 정보가 넘쳐 나서 Googling을 하거나 Stackoverflow를 뒤지거나 API 설명하는 Site를 읽거나 신기술을 소개하는 YouTube등을 보는 것이 일상 다반사가 되었다.  어디서 어떤 키워드로 검색을 해볼지, 키워드를 알게 되면 검색을 하고 책을 좀 더 읽다가 추가로 알게되는 키워드를 더 깊게 파보거나 하는 일은 너무 자연스러운 일이 되었다.

"프로그래밍 언어가 세부사항을 감추더라도 CPU 동작 방식을 이해한다." 이 부분은 내가 Computer Architecture 혹은 C 언어를 배우면서 Linux와 같은 OS의 메모리 운영 방식, 특히 Process/Thread의 개념을 이해하는 부분 또한 Programming Language에서 Stack 및 Heap을 어떻게 활용하는지, Object들이 Attribute와 Method를 어떻게 관리하는지, Garbage Collection은 어떻게 처리하는지 등을 이해하게 되는 부분을 간단히 설명하는 부분이다.

"자료구조아 알고리즘을 직면한 문제 풀기 위해 올바르게 선택할 수 있다." 이 부분도 책에 나와 있다고 그 내용을 액면 그대로 받아 들이기 보다는 "왜"를 생각하여 "어떻게" 활용하는지를 고민하는 것이 중요하다 생각한다. "바퀴를 다시 발명하지 않는다. 이미 알려진 프레임워크를 잘 사용한다." 이 부분도 모든 것을 새롭게 만들기 보다는 존재하는 Open Source를 최대한 잘 활용하고 거꾸로 이 부분의 발전을 Contribution하는 것도 고민하게 된다.

"가독성, 유지보수성, 이식성이 왜 중요한지 이해한다." 이 부분에 대해서는 예전에 대비해서는 성능, 최적화 부분에 대해서 대치되는면도 적지 않다. 하지만, 코드의 유지 보수 및 확장성은 점점 더 중요시 되어 가고 있다. 

"학습과 기량 연마가 끝나지 않는다는 것을 인정한다." 이 부분도 끝이 없다는 점을 더욱 더욱 느끼고, 내가 알고 있던 것이 틀리게 바뀌고 틀리다 생각했던 것이 지금은 맞는 경험을 점점 더 하게 된다.

마흔살 기획자 프로그래머 되다.[3]

이 글은 나보다도 나이가 많은 분이 기획자를 하다가 개발자로 커리어를 바꾼 분의 경험담이다. 글의 중요한 포인트는 2가지라고 이야기 하고 싶다.  첫번째는 "마음가짐"이다. 짧게 말하면, 바로 절실함이다. 자기가 하는 일에 꼭 필요한 것이 프로그래머여서, 결국은 자기가 프로그래머가 되겠다고 생각하고 덤볐다는 것이다. 여기에는 마음을 먹는 것도 중요하지만, 실행하는 것도 매우 중요하다는 생각이 든다.

그리고, 두 번째는 "효과적인 방법"이라고 하고 있는데, 이 부분은 여러가지가 있지만, 우선 몇가지 포인트만 들어서 이야기 하고자 한다.

무엇 보다도 정말 내가 현재로 필요하는 내용을 공부하는 것이라는 중요한 포인트를 지적하고 있다. 다른 사람들이 Java를 한다고, C++을 한다고 해서 그것을 하는 것이 아니고, 게임을 만들기 위해서 그 분야에서 유용한, ActionScript라는 언어를 배웠다는 것이다. 

"... 책을 3번 읽는다... ", 그것도 지하철에서 틈날 때 컴퓨터를 활용하지 않고 말이다. 나는 컴퓨터 언어는 백문이 불여일타라고 생각하는 사람이다. 하지만, 이 부분에 대해서는 일부분 공감이 가는 부분이 있다. 내가 박사 과정일 때, 이와 유사한 방법을 실재로 사용했다. 여러 논문을 읽었지만, 내가 참고해서 활용해야 모델을 도입하는 논문이 있었다. 완전히 수학이어서 전혀 이해가 가지 않았다. Journal 논문이었는데, 나는 3번 읽는 것을 넘어서 결국 필사까지 하였다. 어떤 이는 말한다. 모르면 외워라. 그리고 나면, 이해되는 순간이 온다.

"목표를 가지고 프로그래밍을 한다"라는 부분도 실용적인 접근 방법이고 기본이 쌓인 다음에는 Problem Based Learning이 동작한 것으로 보인다. 나는 이 부분은 앞에서 쌓은 기본 지식이 있기 때문에 가능하다고 생각한다.

"고수의 코드를 들여다 보다"에서는 여러 사람들을 통해서 배우는 것과 같다고 생각한다. 다른 공부 방법에서도 이야기 하지만, 서로 주고 받는 피드백, 좋은 코드 살펴 보는 것들이 매우 좋은 내용들이라 생각한다. 

남규진님의 학습에 실패한 이야기 [4]

이 글은 실패담이라고 되어 있다. 타산지석이라고도 할 수 있겠다. 하지만, 읽다 보면 꼭 실패담이라고 할 내용은 아니다. 우선 접근하는 방법이 Retrospective와 같이 좋았던 공부를 계속하는 것은 유지하되 좋지 않았던 부분들을 개선해 나가는 접근 방법이 좋았다.

우선 고치려고 하는 부분은 "막연한 목표 설정", "편안한 학습법" 이었다. 공부를 하면서 그 결과를 평가할 방법이 없는 접근 방법으로 진행했다고 한다. 단순히 책을 읽기만 하는 접근 방법이었다.

다시 결심하고 접근한 방법은 구체적인 계획과 목표를 세우고 접근하기로 하였다. 그래서, Toy Project를 위해 주제를 정하고, 이를 수행한다. 또한 배운 내용을 회사 업무(객체지향 규칙 적용)에 활용한다. 이전에 작성한 내용을 리팩토링하는 것까지가 새로운 계획이었다. 그리고, 법법도 단순 타이핑이 아니고, 일정 주기로 반복하며, 부숴도 좋은 장난감을 만들고, 다양한 방법을 통해 Feedback,을 받는 것이었다.

그러면서도, 좀 더 구체화가 필요해 보이기는 하지만, "왜" 하는가 하는 근원적인 목표도 찾아가는을 살펴 볼 수가 있었다.

프로그래머의 길, 멘토에게 묻다. 리뷰[5]

소프트웨어 크래프트맨쉽에 관한 책의 리뷰 블로그 글이다. 소프트웨어 크래프트맨쉽은 Agile 개발 방법론에서 한걸음 더 나아가 개발자들이 장인(Craftman)과 같이 길러져야 한다는 개념으로 정리된 것으로 알고 있다. 이미 여러 공감가고 눈이 내용들이 많다. 관련 책도 구매해서 일부 읽고 있어서 이 부분은 나중에 따로 정리하거나 여기에 추가해야 할 내용이다.

임백준님의 개발자의 평생 공부[6]

임백준님은 YouTube 영상도 있고 상당히 유명한 분으로 알고 있다. 최근에 발견한 이분의 잠언 형식의 글들에 공감가는 부분이 있어 후배들에게 공유하기 도 하기도 했었다. 몇가지만 추려 보겠다.

"지금 다니고 있는 회사에서 하는 일을 잘하기 위해서 노력하는 것이 가장 좋은 공부다." 이 부분은 방향성에 관한 것이기도 하다. 내가 하고 싶은 것과 해야 하는 것을 가능하면 일치 시키는 것이 나의 성장에 가장 큰 도움이 된다는 내용으로 나는 이해하고 있다.

"... 스스로 문제를 정의한다음, ... 그 문제를 풀어 보는 것이다..." 이 부분은 공부하는 방법으로 치면 최상 레벨의 접근 법이라고 생각한다. 반드시 해봐야 한다. 대학에서는 이러한 것을 박사 과정이라고 한다.

"겉만 핥는 것은 경박하고, 토끼굴에 빠지는 것은 우매하다. ... 균형을 잡는 ..." 늘 그렇듯이 균형은 중요하고 어렵다.

이 분도 이해 안되는 것은 암기하라고 한다. 그리고, 공부는 함께 해서 Feedback을 받으라고 한다.

김창준님의 사례[7, 8]

김창준님을 만난 것은, 회사에서 진행한 Agile 교육이었다. 교육 내용을 거의 모두 잊었지만, 아직 기억하는 부분은 Agile을 생활에 접목하시는 분이었다. 부부의 대화에서 Retrospective를 적용하는 방법에 대한 것이었다.

이 분의 사례는 상급 레벨에 해당하는 사례이다. 적어도, 컴퓨터 언어는 이제 능숙하게 다루고, 위에서 이야기하는 초보 개발자 수준은 벗어나야 한다. 내가 음악은 잘 모르지만, 잘하는 악기 연주자를 보면, 악보가 있으면 왠만하면 치고, 음악만 듣고도 코드를 따는 것도 힘들지만 할 수는 있는 단계가 아닐까하는 생각이다.

공부의 내용은 알고리즘, Design Pattern, Refactoring, XP에 관련된 내용이다.

알고리즘 공부에 대해서는 스스로 푸는 것에 대한 강조하고 있다. 이 부분은 다른 입장도 있을 수 있다. 수학 개념을 모르는데, 스스로 어떻게 풀 수 있는가? 위에 40대 프로그래머 시작하신 분도 처음에 이렇게 접근하지 못했다. 그래서, 고급 공부 방법이라고 한 것이다. 하지만, 이것도 자신의 경지의 문제일 수 있다. 즉, 고급 단게에서 그 단계를 지나 자신을 넘어 서기 위한 필요한 방법일 수 있다.

Design Pattern의 경우도 "왜"를 많이 강조한다. 결국에는 숨어 있는 가치, 의미를 이해하지 못하고 Design Pattern을 과하게 적용하려고 하는 경우를 지양하기 위한 것으로 이해된다.

Quo Vadis?

[2] 더 이상 초보 개발자가 아니라는 사실을 언제 알게 되나요?, http://jhrogue.blogspot.com/2018/03/b.html

[3] 마흔살 기획자 프로그래머 되다. http://www.ibatstudio.com/%EB%A7%88%ED%9D%94%EC%82%B4-%EA%B8%B0%ED%9A%8D%EC%9E%90-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8-%EB%90%98%EB%8B%A4/

[4] 남규진, 학습에 실패한 이야기 (우아한형제들 기술 블로그), http://woowabros.github.io/experience/2017/12/11/how-to-study.html

[7] 김창준님의 공부하는 법, http://cafe.daum.net/_c21_/bbs_search_read?grpid=LtXl&fldid=AoDe&datanum=6

[8] 김창준, 프로그래밍, 어떻게 공부할 것인가, https://mindscale.kr/course/how-to-learn-prg/lectures

계정이 휴면이 될 정도로 오랫동안 고민만 했다. 어떤 것을 적어야 할지 무엇을 적어야할지 말이다. 다른 사람들이 하는 것 처럼 공부하는 것을 정리하고자 하는 마음에 계정만 열어 놓은 것이다. 하지만, 어떻게 시작해야 할지 망설여 졌던 것이다. 휴일 전날 새벽 2시에 끄적이며 시작한 글이다. 겨우 마음을 다잡고 주절대는 것은 그래도 이게 몇개월이나마 내가 하려고 했던 것들이고 더 나아가 보려하기 때문이다. 이게 20년이라는 아주 오래된 경력 후에 다시 시작한 블로그이기 때문이다.

내가 왔던 길

다른 것을 다 재껴 놓고도, 모든 것을 내려 놓고도 나는 여전히 Software Engineer이고 싶다. 하지만 현실은 그렇지 못하다. 나는 소프트웨어를 개발한다. 전자공 학 전공이어서 학교에서 배운 것은 FORTRAN이었다. 하지만, 독학한 것은 C 언어 그리고 전산(Computer Science)에 대한 관심으로 친구들과 독학하고 수강까지 한 운영체제(Operating System)를 통해서, 소프트웨어 엔지니어의 길로 들어 서게 되었다.

나는 현재 관리자/매니저이다. 회사에서는 파트장 혹은 TL(Technical Leader)라고 불린이다. 40명 가까운 인력들의 개발 내용을 관리하여 제품에 문제 없이 상품화 되게하고, 인력들의 인사적인 부분까지도 관리, 소위 조직 관리도 진행하니 적절한 호칭이다. 하지만, 나의 내면에서는 소프트웨어 엔지니어(Software Engineer)라는 것을 버리지 못하고 있으니, 그것이 여기 정리하려는 공부의 첫 번째 이유이다.

공부하자

다른 회사의 예이지만, Google에서는 Technical Manager라는 직책에서도 여전히 개발 능력을 요구한다. 면접에서도 Coding 시험을 보고 평가하고 있다. 이것은 Manager라고 해서 조직관리 혹은 과제 관리만이 중요한 것이 아닌 실재로 Software 개발 능력 뿐 아니라 팀원의 Software 역량을 이끌어 갈 수 있는 기본적인 소양을 갖추고 있기를 기대하는 것으로 볼 수 있다. 이런 측면에서 나의 경쟁력 강화에도 의미가 있다고 생각된다.

회사에서 실무를 할 때에는 좌충우돌로 익힌 여러 실무들 익힌다. 하지만, 많은 회사들이 그러하지 않을까 싶은데 그 나마 조금 경력이 쌓이면 과제 관리하는 프로젝트 리더 (Project Leader, PL)가 되어 버린다. 나는 그 시점에서 박사 공부한다고 도망나왔다. 이 때, 다시 코딩하게 되면서 얼마나 좋았는지? 회사에 복귀 후에는 개발 업무를 다시 시작하게 되었어도 일정에 쫓기어 공부를 미루고 미루었다. 

많이 돌아왔지만, 이제서야 강의도 듣고 책도 보면서 스스로 공부하게 되는 보수 교육(補修敎育, Continuing Education , Further Education) 이라는 개념으로 공부한 것을 여기에 정리해보고자 한다.

내가 공부하고 여기에 정리해 놓는 것이 다른 이에게도 맞는지 모른다. 하지만, 적어도 나에게 공감이 가는 것들을 공부하면서 정리한 것이니 나에게는 도움이 된다고 생각하고 다른 분들께도 도움이 되길 기대 한다. 주제에 대해서 강의 들으면서, 관련된 책을 정리한 것을 옮겨 놓을 것이라 링크로 확인할수 있는 것들은 링크를 남기고, 나름 내가 정리한 책의 내용과 내가 이해하는 거 새로운 내용들도 정리해 보고자 한다.