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

들어가며

논어에는 "배우고 때때로 익히면 또한 기쁘지 아니한가?" (學而時習之, 不亦說乎?)라는 말이 있다. 옛날 사람의 이야기이지만 우리가 현재 학교에서 교과서를 통해서 배우는 것과 같은 명시지(Explicit Knowledge)도 실천을 바탕으로 해야 한다는 것으로 알 수 있다. 우리는 우리가 학습 한 것 혹은 전문성을 바탕으로 하는 직업에서도 학습이 일어나고 수행(peform)하기도 한다. 그렇다면, 우리가 이해하는 지식의 모습은 어떨까? 이러한 지식을 얻기 위한 학습을 어떻게 얻을 수 있을까? 이런 이해를 바탕으로 한다면 어떻게 학습하는 것이 좋을까? 그리고 이러학 학습을 통해 생겨난 나의 지식은 어떻게 관리하는 것이 좋을까? 단편적일 수 있지만, AC2에서 학습한 근거 있는 방법들과 개인적으로 알게된 도구들을 포함하여 살펴 보자.

우리가 이해하는 지식의 모습.

지식을 이야기 하면 우리가 배운 것을 기억하고 있는 것이라고 간단히 이야기 할 수 있을 것이다. 기억은 보통 단기 기억(Short-term Memory)/작업 기억(Working Memory)와 장기 기억(Long-term Memory)로 이야기를 많이 한다. 암기 한다는 것이 결국은 우리 뇌에 그 기억을 심고 시간이 오래 지나도 그것을 잘 꺼내는 것이 필요하다. 우리는 경험 상으로 이렇게 더는 것이 쉽지 앓다는 것을 안다. 그리고, 이렇게 되기 위해 반복과 시간이 걸리는 경우가 많다는 것도 경험 상이나 이론으로도 알려져 있다. 어릴 때 부터 자주 꺼내어 쓰는 구구단이나 조선왕 순서가 이렇게 단기 메모리를 장기 메모리로 잘 옮겨 둔 사례가 될 수 있겠다.

그렇다면, 운동이나 작업과 같은 것들은 어떨까? 연구자들은 이러한 부분도 연구를 했다. 많은 전문성 연구에서 이를 다루고 있는데, 이와 관련된 한 가지 모델이 절차적 지식 혹은 기억(Procedural Memory)이라고 한다. 앞에서도 이야기했듯이, 단기 기억 혹은 작업 기억 에서 중요한 것은 기억을 인출하는 것이다. 앤더스 에릭슨과 월터 킨치[1]는 "장기 작업 기억(Long-Term Working Memory)"이라는 개념을 도입하여 일상적인 작업과 관련된 정보에 원활하게 접근할 수 있는 장기 기억의 "인출 구조(retrieval structure)"집합으로 정의하여 설명하고 있다. 이런 방식으로 장기 기억의 일부는 효과적으로 작업 기억으로 동작한다고 설명하고 있다. 다시 이야기 하자면, 우리가 하고자 하는 작업 같은 경우도 전문가의 지식 혹은 행동으로 가지고 싶은 지식의 경우 명시화 해서 시간을 들여 반복하는 것이 필요하다. 즉, 학습, 훈련하는 것이 필요한 것이다.

내가 사용하는 배우고 익히는 방법

기존에 방식은 책을 보고 배우고, 프로그래밍과 같은 실습이 필요한 것은 코드를 입력하고 돌려보고 프로젝트를 해보는 것으로 알고 있었다. 물론 영어와 같은 언어는 여러 메타학습적인 부분이 있어서 학습법도 찾아 보고 시도해 보면서 영어로 생각하고, 표현하는 훈련이 필요하다와 같은 내가 지금 사용하는 방법을 찾아 적용하기도 했다.

AC2에 참여 하고 나서 학습하는 방식이 추가 되고 바뀌었다. 특히, 김창준님의 "야생학습" 패치(AC2 Patch)를 듣고 나서는 기존의 책 읽는 방법 그리고 실행하는 것을 훈련하는 방식도 변하고 있는 상황이다. 여기서 이야기하는 것들은 여러 곳에서 배운 것들을 나에게 적용하고 있는 과정 중인 것이다. 그렇기 때문에 v1.x 라고 부르기보다는 보다는 v0.1 혹은 v0.x와 같은 진행형이라는 부분을 이야기하고 싶다.

내가 생각하기에 기존의 내가 쓰던 방식과 다른 것은 "협력적"으로 학습하는 것, "절차적 지식"을 위한 학습, 그리고 "형성 평가적"인 요소의 도입을 하는 것이다.

협력적인 학습의 경우는 김창준님이 Mental Representation관련해서 알려 주실 때 공유받았던 논문[2]에  나오는 내용으로 "그룹이 개인이 독립적으로 수행할 때 발생하지 않는 추상적인 표현을 창발(Emergence)한다는" 주장이다. 이러한 것이 의미있는 지식으로 발전할 수 있다. 그래서, 소그룹의 논의와 이를 공유하는 작업은 학습에서도 중요한 의미를 지닌다고 볼 수 있겠다. 책을 읽는 것도 혼자서 읽고 이야기 하는 것이 아니라 같은 책 혹은 다른 책을 읽는 모임에서도 서로가 책을 읽은 것을 가지고 이야기를 공유하는 것이 혼자 하는 것과는 다른 결과를 만들어 낸다. 나는 정기적인 독서 모임이 일주일 특히 주말에 2회가 있다. 특별한 사정이 있지 않으면 참석을 한다. 하나는 다른 책 혹은 같은 책의 다른 부분을 읽고 이야기하고, 다른 하나는 하나의 책을 정해 놓고 처음 부터 끝까지 같이 읽는다. 다른 형식임에도 공통적인 것은 내가 생각하지 못했던 것을 다른 사람들에게 배우는 것이다.

절차적 지식 학습을 위해 최근에 가장 많이 사용한 방법은 Outcome Observable Question (OOQ)를 이용한 Action Planning이었다. 내 개인적인 생각으로는 이것이 의도적인 수련(Deliberate Practice)과 의도적인 수행(Deliberate Performance)을 적용하는 것이라 생각한다. 이 방식은 AC2를 할 때, 김창준님의 Essense of Agility를 연습하는 방법이었지만, 이 방식은 행동으로 옮길 프레임워크가 있다면 적용이 가능하다. 예를 살펴보자, 예전에 변신철님이 알려 주신 책이었는데 "헤라클리이토스"의 "같은 강에 두 번 발을 담글 수 없다."라는 경구를 실천해 보자고 한다고 하자. 이 문장을 지나간 일은 어쩔 수 없으니, 앞으로 일어날 일에 집중하자고 해보자. 이를 중요한 Outcome으로 보고 이를 관찰할 수 있는 질문으로 바꾸어 "지나간 일 보다는 지금 혹은 곧 발생할 중요한 일은 무엇인가? 그것에 집중하고 있는가?"를 사용해 볼 수 있다. 그렇다면, 이를 기반으로 지금/오늘 나에게 중요한 문제에 대해서 적용해 볼 수 있다. "지나간 부분에 대해서 어쩔 수 없으니 지금 중요한 "임원 보고"에 대해서 준비하고 대응하자."와 같은 Action Plan을 짤 수 있다. 이러한 작업이 의도적 수련이 될 수 있고, 이를 기반으로 실재 실행과도 연결할 수 있다. 이 OOQ 기반 Action Plan을 여러 사람들과 피드백 받아서 한다면 더욱 효과가 좋다. 나는 매일 루틴 처럼 아침에 어제 Action Plan에 대해서 회고를 하고 새로운 Action Plan을 수행하면서 피드백을 받아 반복해서 진행되도록 했었다.

AC2를 하면서 알게된 한가지 효과적인 학습 방법은 형성 평가(Formative Assessment)를 사용하는 것이다. 우리에게 익숙한 학습의 평가는 배우고 난 것을 평가하는 총괄평가(Summative Assessment)를 하는 것이다. 즉, 수업 등의 진도가 나간 후에 마지막에 시험을 봐서 학습자가 얼마나 이해했는지를 평가하는 것이다. 형성 평가는 이와는 달리 중간에 학습자가 얼마나 이해하는지 보여 주게 하면서 학습의 효과를 높이는 것이라고 할 수 있다. 예를 들자면, 학습자들이 몇몇이 모여서 이해하고 있는 곳들을 나누고 함께 모여서 그것들을 나누면서 자신이 알고 있는 것을 확인하고 다른 사람들을 통해서 이해도를 높일 수 있다. 연구자들의 측면의 근거로서 흥미로운 것은 구글 Scholar를 검색해 보는 것이다. 2025년 2월 말에 검색 했을 때에는 형성 학습 관련한 논문이 총괄 평가와 관련된 논문의 약 7배가 많다는 것을 알 수 있다. 하지만, 아직도 현실에서는 총괄 평가가 많은 상황이다. 이러한 상황에서 사용 가능한 전략을 AC2에서 소개 받은 바가 있다. 총괄 평가 시스템이어서 바꾸기 어렵다면 중간 중간에 형성 평가 구간을 두는 것이 한 방법이다. 회사의 분기별 안전 교육에서도 문제 풀이를 중간에 보여주도록 바뀐 적이 있는데 이러한 모습을 반영한 것이라고 할 수 있다. 우리가 형성 평가 기준으로 학습하고 있을 때, 중간에 총괄 평가에해당 하는 시험 혹은 모의 시험들을 넣어서 피드백을 받는 것도 의미가 있다. 좀 더 구체적인 예를 드다면, 내가 영어를 잘 하기 위해서 평생 공부를 하지만, TOEIC, OPiC등 시험을 중간 중간 넣어서 피드백을 받아 성적을 살펴 보는 것이 이러한 방법이 될 수 있다.
 

내가 사용하는 나의 개인 지식 관리

또다른 학습의 과정은 알고 있는 것의 인출(Retrieval)이다. 다시 말해 알게 된 것, 알고 있는 것을 계속 끄집어 내는 것도 좋은 학습 중 하나이다. 이 부분은 나의 뇌에서 지식을 꺼내는 것도 있지만, 지식 관리 시스템에서 내용을 다시 보고 내 기억을 강화 하거나 지식 관리 시스템에 내용을 보강하는 것이. 이를 활용하게 하는 대표적인 것이 워크샵을 하거나 공유회를 하는 것이 될 수 있다. 여기에서는 일반적인 강의만 하는 것이 아니고 AC2의 워크샵 처럼 수련, 연습, 실행을 포함하는 것이 더 좋은 것이 보인다. 최근에는 동기 면담과 관련한 주제에 대해서 작게 공유회를 하였다. 이 때, 동기 면담의 중요한 기술 중의 하나인 반영(Refrelction)에 대해서 이야기도 하고, 이를 위한 간단한 연습을 포함하였다. 이러한 방식은 사람들에게 지식을 전달하는 과정이 포함되어 있지만 나한테는 또다른 학습이기도 한 것이다.

머리 속에 모든 것을 담아 둘 수 없기 때문에 두번 째 뇌라고 할 수 있는 메모앱은 지식 관리 시스템의 뼈대가 된다고 생각한다. 기존에 사용하던 메모앱은 Evernote, Google Keep 그리고 OneNote로 넘어가 사용하고 있었다. AC2를 하면서 다른 분들이 소개하는 것을 듣고는 OneNote에서 Obsidian으로 옮기기 시작했다. 하지만, 오래 사용한 OneNote의 모든 내용을 옮기는 작업은 하지 않고, 지속적으로 업데이트하는 문서를 짧게 먼저 옮기고 사용을 시작했다. 중간에 다시 OneNote에서 많이 참고하는 문서의 복사본을 만들어 옮겨 사용하였다. 현재 OneNote는 거의 열어 보고 있지 않다.

Obsidian은 Text 문서에 Markdown 형식으로 문서를 작성하면 이를 포매팅해서 보여 준다. 이는  단순하지만 불릿 포인트 같은 문서 포맷팅 뿐 아니라, 수학 수식도 작성이 가능하다. 무엇 보다도 문서간의 Link를 활용해서 제텔 카스텐을 지원한다. 처음에 강의 등으로 들은 내용이고, 내가 사용하는 방법은 아직도 어설프지만 나름 흉내 내보려고 하고있는 실정이다. 예를 들어 관련 있는 문서들이 처음에는 파편화 되어 생겨 난다. 그리고, 연결 될 대 문서 제목으로 링크를 만들어 연결 시키서 탐색이나 검색이 용이하게 이뤄진다.

Obsidian을 이용하고 나서 알게된 PARA 룰의 적용도 유용하다. PARA는 Project, Area, Resource, Archive 의 약자로 메모를 카테고리화 해서관리한다. 이와 관련된 YouTube와 온라인 교육을 들은 적이 있다. 교육에서 제안받은 데로 Inbox를 포함하여 5개의 큰 카테고리로 나눠어 메모를 분류하고 활용해서 급하게 만든 문서는 Inbox에 만들어 넣고, 간략하게 정리되면 Project 혹은 관련된 다른 폴더로 이동하게 된다. 물론 다른 폴더에 있는 것들도 완료되거나 하면 Archive등으로 이동하기도 한다. 회사의 메일을 정리하는 방법도 PARA 형태로 바꾸면서 모든 이메일을 백업하는 일은 포기한 상황이기도 하다.

블로깅은 AC2를 하기 전 부터 학습하던 것을 기록하는 도구로서 사용하였다. 특히, 메모 등으로 조각 난 정보들 중에서 이와 같은 글을 쓰거나 학습한 내용 중 다른 분들과도 공유하고 싶은 내용들을 위주로 정리해서 올리고 있다. 이 글도 블로그에 올라갈 것으로 기대한다. 블로깅의 중요한 축은 사람들의 피드백을 살펴 볼 수 있는 부분이다. 다른 블로깅 채널을 뚫어 볼까도 생각하고 있지만, 아직은 시도하기 전이기는 하다.

Anki가 지금까지 마지막으로 활용하게 된 도구이다. Anki는 암기(暗記)의 일본 발음으로 Flashcard 형태의 정보를 간격 반복(Spaced Repetition) 학습을 하게 도와주는 도구 이다. 이는 인출의 연습을 하게 도와 주는 도구로 이제 영어 단어 혹은 자격증 시험에 많이 활용하는 것을 볼 수 있다. 나도 영어로 시작해서 자격증 시험이나 기억하고 싶은 이론 등에 대해서 정리해 두고 살펴 보는 도구로 사용하기 시작했다. Obsidian과 연계하기 시작하면서 새로운 지식을 Obsidian에 정리하고 Anki의 Flashcard로 만들어 기억하고 싶은 것들을 더 자주 들여다 보면서 간격 반복 학습을 하도록 시도하고 있다. 이 부분에 대해서는 배휘동님의 가이드도 참고 하고 있다[3].

정리하며

여기서는 AC2를 하면서 여러 가지를 배우고 얻었지만, 기존에 내가 학습하던 방법과는 다르게 근거가 있는 도구나 방법들을 많이 배웠다. 그래서, 지식이라는 것에 대한 이해도 조금 더 가지게 되었고, 이러한 이해를 바탕으로 학습하는 벙법 및 도구를 얻게 되었다. 이를 기반으로 실용적인 지식 관리 도구들도 가지고 적용하게 되었다. 이 부분은 상당히 개인적인 경험이나 근거들을 기반으로 한 것으로 다른 분들도 이러한 참고하여 자신에게 맞는 방법을 찾아서 튜닝해서 사용할 수 있을 것이라 기대한다.

참고 문헌

[1]  K. Anders Ericsson and Walter Kintsch, "Long-Term Working Memory", https://kantor.comminfo.rutgers.edu/t/MLIS/551/public_dump/morris_a_11.html
[2] D. L. Schwartz "The emergence of abstract representations in dyad problem solving", The journal of the learning sciences, 1995
[3] 배휘동, "[GeekNight 2024] 인지과학 연구로 증명된 학습 보조 도구 Anki: 10배 더 효과적으로 활용하는 방법", https://www.stdy.blog/10x-effective-way-to-use-anki/

[1]에서 가장 와닫는 말은 "나는 밥 먹기 전에 설거지하는 전략을 섞어서 쓴다. 보통은 밥 먹고 나서 설거지하는 것이 좋은 생활 습관이지만, 설거지한 이득은 다음 밥 먹을 때가 되야 발생한다. " 이다. 그렇지만, under-engineering이 당연히 좋다고 하는 것만 같아서 약간은 불편했다. 맞는 것일까? 그렇다고, 나는 over-engineering을 추종하는 것인가라고 질문했을 때도 불편했다. 그러면서도, 내가 아는 것은 무엇일까 하면서 시간이 상당히 흘렀다. 글을 쓸 거라고 생각했지만, 생각이 충분히 자라지 못하고 있었다. 비 오는 아침에 떠오르는 것이 적어 본다.  
  
아내와 결혼하고 여러가지로 달랐다. 설거지 측면에서는 나는 요리를 하면서도 치워가면서 해야 했다. 그렇지만, 아내는 설거지는 가능한 늦게 하는 것이 좋다고 생각하는 것으로 보였다. 내가 요리하기 위해서 싱크대를 보면 시작하기 힘들어 보여 못하는 경우도 있었다. 그렇다고 해서, 나는 완벽했는가 생각해보면 그렇지 않다. 설거지 관련해서 아내가 나에게 핀잔을 주는 경우도 많았기 때문이다. 단지 달랐다고 해야 할 것 같다.  
  
"Hacker News"에서 진행된 "over-engineering과  under-engineering 사이의 균형 찾기"[2] 에 관한 토론에서 보아도 여러 의견이 있지만 여전히 under engineering이 우세인 것처럼 보인다. 미래는 예측하기 어렵고 복잡하고 성급한 일반화가 문제 될 수 있다는 것이다. 그러면서도, 조심스럽게 이야기 하는 것은 실용적 한계 내의 균형(balance)이다. 그렇다면, over-engineering은 무엇이고 under-engineering은 어떤 것인가? 우리는 어떻게 판단할 수 있는 것인가?  
  
앞의 에피소드에서도 이야기했지만, 배가 고파서 뭔가 해먹어야 하는데 설거지 때문에 아무것도 못하고 결국 시켜먹는다면 그것은 좋은 상황일까? 개발할 때에도 한걸음도 나아가기 어렵다면 이 상황과 비슷한 것 같다. 요구사항이 있고 진행을 해야 하는데 못하고 있다면 고민해야 한다. 내가 해야 하는 일이 한걸음도 나아가기 어렵다면? 팀이 해야 하는 일이 있는데 못한다는 결론만 난다면? 설거지 거리가 산더미처럼 쌓여 있는 것이 아닐까? 조금이라도 진전을 만들어야 한다.  
  
  
산더미 같은 설거지를 보고 힘이 빠지지만, 애자일 마인드를 장착하고 지금 보다는 좋게 만들자라고 생각하고 더 개선을 한 다음 요리를 해 먹는 것은 어떤가? 여러 가지 전략이 있겠지만, 요즈음 공감이 가는 문구[3]가 있다. "First do it, then do it right, then do it better"이 그것이다. 나는 동작하는 소프트웨어가 정말 중요하다고 생각한다. 동작하지 않는 것을 고쳐서 동작하게 되어도 배우지만, 쉽지 않고 어렵다. 동작한다면 조금 더 쉽게 배우고 더 좋게 만들 수 있다.  
  
다시 설거지로 돌아가 보자. 단순하게 하자. 우선 설거지를 하긴 해야 한다. 내가 요리하기 위한 공간도 만들어야 하고, 요리에 필요한 조리 도구도 정리해야 한다. 그것을 위해 고민하는 것 자체가 요리를 위한 설계이다. 혹시, 저녁까지 요리할 거라면 여력이 있다면 그것까지 고민하는 것이 좋겠다. 가족들과 함께할 것이라면 어떤 요리를 어느 정도 할 것 인지도 가족들과 이야기 하고 나눠야 한다. 그러고 나면, 설거지를 어느 정도 할지 정리가 된다. 이러한 상황을 개발과 빗대어 보면, 내가 under-engineering한 것인가? over-engineering한 것인가? 나 스스로와 팀과 밸런스를 맞춘 것이다.  
  
개발도 요리처럼 느껴진다. 나 혼자를 위해 요리하기도 하지만, 나와 아내 그리고 아이를 포함한 가족을 위해 하기도 한다. 정리해 보면, 포인트는 나 그리고 팀에 맞는 방법을 쓰고 있는가, 지금 하고 있는게 밸런스에 맞다는 걸 아는가 이겠다.  흑백논리로 under-engineering과 over-engineering으로 나누기 보다는 동작하는 소프트웨어를 통해서 나와 팀이 이 미묘한 밸런스를 배우고 찾아가고 있는가가 더 중요할 수도 있겠다.   
  
참고문헌  

[1] Youngrok Pak, "Simple Design" [https://youngrok.com/Simple%20Design](https://youngrok.com/Simple%20Design) 
[2] "Striking the Right Balance: Over-Engineering vs. Under-Engineering Software", [https://news.ycombinator.com/item?id=37063643](https://news.ycombinator.com/item?id=37063643) 
[3] Addy Osmani, "First do it, then do it right, then do it better" [https://x.com/addyosmani/status/314785735171518464?fbclid=IwZXh0bgNhZW0CMTEAAR0lMbyKE58a-O4zoeW9e3CNA03g0Sc7J5knTvnB_HZsvLqyohsG3RHoD0g_aem_igNvyHYBauJqmZckFYChjg](https://x.com/addyosmani/status/314785735171518464?fbclid=IwZXh0bgNhZW0CMTEAAR0lMbyKE58a-O4zoeW9e3CNA03g0Sc7J5knTvnB_HZsvLqyohsG3RHoD0g_aem_igNvyHYBauJqmZckFYChjg)

워드 커닝햄은 Wiki를 만든 유명한 프로그래머이다. 특히, 기술 부채(Technical Debt)라는 용어를 도입하기도 했다. 여기서는 이 기술 부채라는 용어를 다루고 있는 글을 이야기 해보자.
 
기술 부채라는 것은 [1]에서도 언급하듯이 소프트웨어 개발에서 발생하는 문제를 금융 부채에 비유한 것이다. 이글에서는, 초기 개발에서 빠르게 기능을 구현하기 위해 '부채'를 지는 것은 괜찮을 수 있지만, 이는 나중에 이는 갚아야 하는 '이자'와 함께 돌아오며 결국 원금까지 상환해야 한다는 점을 강조하는 것이라 볼 수 있다. 코드의 품질이 떨어지면 생산성이 낮아지는 것이 이자의 형태로 나타나는 것이고 이를 문제를 해결하는 것이 원금 상환하는 것까지 포함하는 것이다. 워드 커닝햄은 이 부채는 리팩토링을 통해 상환해야 한다고 한다. 상환하지 않으면 시간이 지남에 따라 문제들이 누적되어 전체 개발 조직이 만들 수 있는 진행 사항 자체가 멈출 수 있다고 보고 있다.
 
글에서도 이야기 하지만, 나는 기술 부채가 투자와 같은 것에 레버리지(Leverage)로서의 측면도 있다고 본다. 즉, 빠른 시장 출시를 위해 이 기술 부채를 활용하기도 한다. 기술 부채를 지는 것은 초기 제품을 더 빨리 시장에 출시하여 비즈니스 가치를 제공할 수 있게 한다는 것다. 이는 시장에 적기에 출시해서 이득도 얻을 수 있고, 또한 빠른 피드백을 얻고, 이를 바탕으로 제품을 개선하는 데 유리하기도 하다. 그러므로, 기술 부채를 전략적으로 사용하는 것은 스타트업이나 신제품 개발에서 중요한 전략이 될 수 있다. 즉, 단기적으로는 부채를 통해 빠르게 성과를 내고, 이후에 이 부채를 상환하는 방식으로 진행할 수 있는 것이다. 하지만, 우리가 자주 놓치는 것은 이 부채의 상환 계획이다. 다시 말해, 부채가 누적되지 않도록 지속적으로 관리해야 하는 것이다. 리팩토링 활동을 통해 생산성을 회복하고, 부채의 이자를 줄이는 것이 중요하다.
 
조금 더 구체적이지만 단순하게 생각해보자. 비유에 따라서 우리 접근 방법도 생각해 보자. 우리가 금전적으로 부채가 있다고 생각해보자. 무엇부터 해야 할까? 우선은 이자가 높은 부채 부터 갚아야 할 것이다. 그러므로, 기술 부채도 우선 순위를 정해서 이자와 원금을 먼저 갚는 것이 맞다. 우선 순위를 정했다면 실재로 내 금전적 상황에 따라서 아낄 것은 아끼고 이자와 원금을 갚아야 한다. 개발에서는 리팩터링과 개선 작업을 하는 것이다. 이는 코드의 구조, 중복, 복잡성 등 여러 측면에서 이루어질 수 있다. 부채를 갚아 본 이는 알지만, 정리가 되면 갚아야 하는 돈을 추가로 버는 듯한 느낌이어서 활력을 더 느끼기도 한다. 즉, 기술 부채 개념을 적절히 활용하면 초기 개발 속도를 높이고 장기적으로는 품질 유지와 개선을 할 수 있다. 하지만, 금융에 대한 비유에서 알 수 있듯이 시간을 어떻게 활용하고 밸런스 있게 운용하는지 고민하는 것이 더 중요하다.
 
 

참고 자료

[1] Jean-Louis Letouzey and Declan Whelan, " Introduction to the Technical Debt Concept ", https://www.agilealliance.org/wp-content/uploads/2016/05/IntroductiontotheTechnicalDebtConcept-V-02.pdf

문제 해결 방법은 여러가지가 있을 수 있다. 혼자서 열심히 고민하여 문제 해결 하는 방식도 있지만, 팀으로서 협력하는 것은 매우 효과적이다. 하지만, 현실은 늘 항상 들어 맞는 정답은 없다. 그래도, 성공적인 팀-협업적(Collaborative)으로 일하는 팀이 문제를 효과적으로 해결한다.

여기서는 김창준님의 함께 자라기[1]에서 이야기하는 소프트 스킬, 협력적 추상화, 그리고 전문가를 어떻게 팀으로 데려와 성공할 수 있는가의 측면에서 살펴 보자

하드 스킬(Hard Skill) vs 소프트 스킬(Soft Skill)

우리는 많은 경우, 특정 도메인에서 일을 한다. 전자 상거래, 소셜 미디어, 멀티미디어 등 여러 가지가 있을 수 있다. 이렇게 한 분야에서 일을 하다 보면 그 분야, 즉 도메인 지식(Domain Knowledge)가 증가한다. 뿐 만 아니라, 개발자라면 컴퓨터 언어, 자료 구조, 알고리즘과 같은 개발과 관련돈 공통된 지식도 증가하게 된다. 이러한 것은 우리가 문제를 해갈 하기 위한 기술 하드 스킬(Hard Skill)이라고 할 수 있다.

우리가 혼자서 일한다고 하면 이 하드 스킬만 키우면 문제 없다. 하지만, 우리가 여러 사람들과 일하게 되면 여러가지 다른 기술이 필요해 진다. 즉, 사회 생활을 하는데 도움이 되는 자본과 기술이 필요하다고 한다. 좀 더 구체적으로 이야기 하면 커뮤니케이션과 협업 능력과 같은 소프트 스킬(Soft Skill)이 중요하다. 숙련된 프로그래머/개발자들에게 이야기 들어 보면 이러한 소프트 스킬을 높이는 것도 강조하는 사람이 많다는 것을 알게 된다.

이 부분은 뒤에서 문제를 해결하는데 기본이 되는 것이라고 할 수 있다.

협력을 통한 추상화(Collaborative Abstraction)

대니얼 슈와르츠[2]의 연구에서는 한 명이 문제를 푸는 것 보다 두 사람이 문제를 푸는 차이에 대해서 설명하면서 두 사람이 문제를 푸는 경우가 문제 해결에서 추상화를 통해서 새로운 것을 발견하도록 도와 준다고 한다. 이는 둘이서 협력(Pair-work)하면서 다른 시각(perspective)를 받아 들이고, 이를 연결하기 위한 추상화 필요하다고 설명한다.

이러한 추상화는 단순히 서로를 이해하게 하기 위한 것 뿐 아니라 문제를 바라 보는 단계를 높인다. [1]에서 언급하듯이 전산학의 소프트웨어 공학나 많은 학문이 그렇듯이 이 추상화를 거쳐서 발전하게 되었다. 그러므로, 우리는 이러한 추상화를 더욱 일어나게 하기 위해서 협업을 해야 한다. 

전문가와 일하는 방법 (How to bring experts)

우리가 특정 분야의 문제를 해결하려면 전문가를 데리고 하는 것이 유리할 것이라는 것은 예측하기 쉽다. 하지만, 여기에는 함정이 있다. 울리의 연구[3]를 보면 전문가와 일하되, 협력적으로 조율(Coordination)하고 통합(Integrate)하라고 가이드 한다. 

그의 연구에서는 전문가 혹은 비전문가 팀이 협업을 하는지 하지 않는지를 나누어 비교 연구하였다. 즉, 다음과 같이 그룹을 나누었다.

1. 전문가 협업 개입

2. 전문가 비협업 개입

3. 비전문가 협업 개입

4. 비전문가 비협업 개입

어느 팀의 성과가 가장 좋았을까? 그렇다 전문가 협업이 가장 좋았다. 그렇다면, 꼴지팀은 어디였을까? 전문가 비협업이었다는 것이 매우 흥미롭다. [1]에서는 전문가를 데리고 오더라도, 정보를 공유하고 협력을 잘하기 위한 명시적인 도움이 필요하고 소셜 스킬이 뛰어난 제너럴리스트가 있으면 도움이 된다고 조언한다.

참고 문헌

[1] 김창준, "함께 자라기- 애자일로 가는 길", 인사이트 · 2018년

[2] D. L. Schwartz, "The emergence of abstract representations in dyad problem solving", The journal of the learning sciences, 1995

[3] A. W. Woolley, et al. "Bringing in the experts: How team composition and collaborative planning jointly shape analytic effectiveness." Small Group Research 39.3 (2008): 352-371.

1만 시간의 재발견[1]으로 알려진 안데르스 에릭슨은 의도적인 수련(Deliberate Practice)으로도 알려져 있다. 자신의 전문성을 키우기 위해 의도적으로 따로 연습하는 방법이라고 볼 수 있다. 개발자 혹은 자신의 전문성을 키우고 싶은 사람으로서 수련하는 방법의 좋은 예로 김창준님의 Facebook 포스트[2]를 보고, 조금 더 추상화 부분을 정리해 보았다. 그리고, 최근 그릿[3]을 읽으면서 알게 된 부분도 같이 붙여 메타인지를 해보자.
 

김창준님개발자의 의도적 수련 활동:

Grit의 내용

그릿[3]에서는 최고가 되고 싶으면 '의식적인 연습(deliberate practice)'을 수천, 수만 시간동안 하면 된다. 그러면서, 전문가들의 연습 방법에 대해 다음과 같이 설명하고 있다.

1. 도전적인 목표를 설정하고 전체 기술 중에서 아주 일부분에 집중한다. 이미 잘하는 부분 보다는 뚜렷한 약점을 개선하려고 노력한다. 아직 도달하지 못한 과제에 도전하는 것이다.
2. 도전적인 목표 설정 뒤에는 그 목표에 도달하기 위해 온전히 집중하고 비상한 노력을 한다. 음악가 같은 경우는 혼자 연습하는 시간이 다른 음악가와 함께 연주하는 시간보다 많다.
3. 가능한 빠른 피드백을 받고 싶어 한다. 부정적인 내용이 많다. 자신이 잘한 부분 보다 틀린 부분에 더 관심이 많은 것이다.

이 내용을 조금 더 구체화한 것이 김창준님의 방법이라고 할 수 있겠다.
 

결론은?

앞에서 이야기 한것 처럼 그릿에서 의도적 수련에 대해 정리하고 있다. 개발자의 입장에서는 김창준님의 구체적인 수련 방법을 참고하면 큰 도움이 될 수 있다. 다른 업무를 한다면? 추상적인 것을 통해서 자신의 업무를 대입해보는 것도 좋겠다.
 
 

참고 문헌

[1] 안데르스 에릭슨, "1만 시간의 재발견" 노력은 왜 우리를 배신하는가
[2] 김창준, "개발자의 의도적 수련," https://www.facebook.com/cjunekim/posts/5465539236807932
[3] 앤절라 더크워스, "그릿 GRIT", 비즈니스북스, 2016년 10월

"살리고 글쓰기"는 AC2 과정을 들으면서 알게된 글쓰기 방법으로 기존에 내가 글을 쓰던 방법과는 상당히 다른 부분이 있다. 내가 사용하던 예전 글쓰기는 기존 책의 구조와 비슷하게 개론에서 시작하여 각론으로 나아가는 글쓰기 방법이었다. 하지만 살리고 글쓰기는 애자일하게 글을 쓰는 방식으로 반복적(Iterative)으로 그리고 생성적으로 글을 쓴다.

예전의 방식이라면 어떤 주제를 적을 것인지 생각하고 이야기할 생각의 가지들을 만들어 그 부분들을 채워 갔을 것이다. 즉, 내가 이야기하려는 주제가 생각이 나더라도 전체적인 구조와 각론이 정해질 때까지 정리되지 않으면 글을 쓰기 시작하지 못하고 시간이 많이 걸렸다. 살리고 글쓰기를 할 때, 장점은 글감을 적고, 문장을 만들고, 거기서 글을 만들어 간다. 이렇게 반복적으로 글을 쓰는 것이다. 이렇게 작게 시작하므로 언제나, 어디서나, 낮은 에너지로 글을 쓸 수 있다. 이 글도, 내 핸드폰과과 내 랩탑 컴퓨터를 이용하여 썼다. 책상에서 버스에서 거실의 소파에서 반복적으로 글을 썼다.

살리고 글쓰기는 반복적으로 글을 쓰기도 하지만, 생성적(generative)으로 글을 쓴다. 앞에서 언급한 것과 같이 우선 하고 싶은 말에서 시작한다. 즉, 글감이 있다면 글을 쓰기를 시작할 수 있다. 단어에서 문장이 나오고, 거기에서 센터를 찾아 자연스럽게 나무가 가지를 뻗듯이 글을 펼쳐보는 것처럼 발전 시킨다. 이를 반복적으로 적용하여 글을 쓰면서, 새롭게 떠오르는 센터를 기준으로 계속 글을 써간다. 그러면서, 글이 어떻게 전체적으로 변하고 있는지 살피면서 계속해서 글을 써간다. 인공물이 아닌 자연에서 관찰되는 자연물과 같이 만들어 지도록 생성적으로 글을 쓴다. 이 글은 "살리고 글쓰기"를 배우고 배운 내용을 정리하고 연습하는 관점에서 발견한 센터들을 기준으로 반복적으로 생성적으로 글을 쓴 것이다.

나는 예전의 방법으로 글의 구조 잡는데 에너지를 다 쓰고 나서, 정작 글쓰기를 시작하지 못하는 경우가 너무 많았다. 살리고 글쓰기와 비교하여, 기존의 글쓰기는 글감이 있다고 하더라도 예상하는 글의 뼈대가 보일 때까지 충분한 고민을 하여야 하기 때문이다.  또한, 이러한 뼈대를 위한 구조나 로직을 먼저 생각하다 보면,  쓰려고 하는 글의 중요한 부분의 발견을 놓칠 수도 있다. 살리고 글쓰기의 경우는 이와 상반된 장점이 있다. 글을 쓸 때, 적은 에너지로 시작할 수 있다. 또한, 글을 쓰면서 전체와 센터를 고민하게 되므로 새로운 발견, 즉 창발적인 주제를 발견할 수도 있다. 이렇게 낮은 에너지 진입 장벽과 새로운 주제 발견이 글감과 관련된 글을 더 쓸 확률을 높여 준다.

살리고 글쓰기를 할 때 또 다른 장점은 글감을 적고 시작하고, 거기서 자연스럽게 발전되어 나가는 것이다. 이 때, 여러 가지 방법을 사용할 수 있을 것으로 생각이 들었다. 그 하나는 생각의 흐름데로 써본다는 것이다. 말하기에 대비하여 글쓰기의 장점은 뱉어 낸 생각을 이리 저리 정리하여 다듬을 수 있다는 것이다. 글의 살을 붙이는 또 다른 여러 가지 방법이 있다. 글감에 대해서 시간 순으로 써본다거나, 생각하는 주제 주변을 탐색하거나, 글감의 구조에 대해 살펴 볼 수 있다. 애자일적으로 접근하는 방법을 생각해 보면, 글감에 대해서 추상과 구체를 왔다갔다하는 방법 또한 좋은 방법이다. 즉, 추상적으로 설명하다가, 나의 경험과 같은 예, 즉 구체로 들어가면 된다. 이렇게 하여 글을 적다 보면 하고 싶은 글감에 살이 많이 붙는 것을 느낄 수 있다.

물론 기존 글쓰기 방법을 살리고 글쓰기에서 사용하는 방법을 배재할 필요까지는 없어 보인다. 기존 글쓰기에서 좋은 점들을 적용하는 것도 글을 좋게 만드는 좋은 방법들이다. 살리기 글쓰기를 알려주신 김창준님이 설명해 주신 내용 중 몇가지를 살펴 보자. 우선 해외 대학에서 글쓰기에 대해 가르치는 것 중 하나로 아키데믹 라이팅(Academic Writing)이 있다. 여기에도 여러 가지가 있지만, 창준님이 예로 들어 주신 것은 글을 문단(paragraph)로 구조화하는 것이다. 문단을 잘 나누어 글을 쓰면, 글이 단정하고 명료해 진다. 또 다른 하나는 글을 쓰고 소리 내어 읽어 보는 것이다. 예전에 유시민 작가의 글쓰기에 대한 책을 본 적이 있다. 여기에도 똑같이 언급되었는데, 글도 말이기 때문에 꼭 소리내어 읽어 보면서 정리하면 더 좋아 진다. 이렇듯 기존의 글쓰기에 좋은 방법도 살리고 글쓰기에 적용할 수 있다.

살리고 글쓰기를 알게 되고 얻은 가장 큰 것은 내 생각을 글로 조금 쉽게 펼쳐 나갈 수 있겠구나 하는 것이다. 하지만, 살리고 글쓰기의 방법을 배웠다고 바로 몸에 익혀지는 것은 아닐 것이다. 이제 시작이고, 수련이 필요한 것이다. 연습을 하면서, 빼먹지 않았으면 하는 것은 피드백을 받는 것일 것이다. 자, 이제 시작이다.

책을 읽는 다면 처음 부터 끝까지 눈으로 읽고 이해하는 것이 일반적이라고 생각 할 수 있다. 하지만, 공부나 연구를 업으로 하다 보니, 여러 다양한 방법들을 알게 되었다. 다른 많은 일들이 그렇듯이 이 것도 효과와 효율에 대해 이야기 해볼 수 있겠다. 효과와 효율, 비슷하면서도 다른 말이다. 효과는 어떤 일을 하고 원하는 "목표"를 얻게 되는 것을 의미하고 효율은 어떤 일을 할 때, "비용"이 얼마나 되느냐라고 할 수 있다. 나름 내가 알고 있는 방법이 있다고 자부했지만, 최근에 알게 된 방법을 포함하여 내가 사용했던 방법들을 포함하여 정리해 보자.

최근에 AC2를 통해 알게 된 효과적으로 책 읽는 방법은 내가 학위를 할 때 논문을 빠르게 읽는 방법과 유사했다. 이 때 조건은 이 분야를 잘 알아서 중요한 부분만 읽는 것과 비슷했다. 선행 과정으로 필요한 것은 글의 전체 구조를 보고 중요한 부분을 찾아 낸 후에 그 부분을 파악하는 것이다. 많은 논문은 구조가 비슷해서 이 것이 더 쉽게 적용된다. 책의 경우는 목차를 보고 어떤 부분을 읽을 것인지 결정을 한다. 책을 읽으며 내용을 파악할 때에도 가정(가추법/귀추법 abduction)을 하고 확인하여 읽는 부분도 최소화 하는 것이 필요하다. 또한, 마인드풀(mindful)하게 책을 읽어야 한다. 즉, 내가 책의 내용을 어떻게 사용할 것인지 계속 생각하면서 읽는 것이 효과를 높이는 방법이다.

논문을 읽는 경우도 내가 저작할 때 활용하기 위해서 이 논문이 다루는 문제가 무엇인지 그리고 어떤 새로운 방법으로 풀었는지를 나의 언어로 작성을 해두어야 했다. 논문을 읽을 수록 점점 읽기 쉬워졌는데, 하루에 10편도 넘게 읽을 수 있는 경우도 생겼다. 논문을 읽을 때, 지도 교수는 이 사람이 기존과 다른 "새로운 아이디어(novel idea)"가 무엇인지 그 것을 어떻게 증명해 보였는지 "내 문장"으로 정리할 것을 요구했다. 처음에는 그 부분을 논문에서 발췌했더니  "재구성(rephrase)"라도 꼭 해서 나의 말로 바꾸어야 한다고 강조하셨다. 이 부분이 되기 시작하면서 논문 읽는 능력이 늘어 나기 시작하고, 기존 알고 있던 다른 연구와 유사한 경우는 정말 30분도 안되서 정리가 되곤 했다. 그리고는 그 것들이 내가 쓰는 논문의 참고 문헌에 기반이 되기도 했다.

효율에 대해서 조금 더 생각해 보면, 책을 읽을 때 사용하는 에너지에 대해 생각해 볼 수 있다. 언제인가 책이 많아져 정리해야 할 때, 책을 스캔하여 둘 수 있다는 것이 가능하다는 것을 알게 되었다. 또한 이북도 서점에 많이 생기기 시작했다. 또한, 어느 유투버가 책을 스캔하는 것에 대해서도 설명하는 것을 본 후에 내 책을 스캔하고 혹은 이북으로 책을 구매 후에 책을 TTS(Text To Speech)를 이용해서 듣는 것을 시도해보기 시작했다. 사실은 오디오북을 시작하려고 했지만, 오디오북을 구할 수 있는 한계가 명확했다. 특히, 우리 나라 책에서는 그랬다. 이렇게 책을 스캔해서 읽는 이 부분은 나에게 혁명적이었다. 내가 운전을 하면서 혹은 운동을 하면서 들어도 라디오나 음악을 듣는 수준의 에너지로 책을 읽을 수 있었다. 나는 번역한 책을 퇴고 할 때도 들어서 3번 정도 들었다. 앉아서 번역본을 보면서 듣기도 하고, 차를 타고 다니면서 듣기도 하였다.

그렇다면, 효과와 효율은 서로 상반되기만 한 것일까? 학위를 하려면 정말 많은 논문을 읽어야 한다. 하지만, 처음에는 어느 분야의 초보자가 그렇듯이 에너지가 많이 들고 어려움이 많다. 나도 논문 한편에 일주일, 혹은 이주일을 읽어도 어려웠다. 이 후에도 어느 정도 이력이 붙었는데도 어려운 부분이 있었는데, 이는 논문의 난이도가 매우 높을 때이다. 나도 몇 편의 논문은 제출한 상황이었음에도 이런 경험이 있었는데, 참고할 논문[1] 내용이 수학적인 것이 너무 많고 난이도가 높아서 이해도가 낮은 경우였다. 이 때에 이 논문을 여러 번 필사하였다. 처음 읽을 때에는 내가 필요로 하다는 생각이 들었지만 내용이 잘 이해가 되지 않았다. 그래서, 두 번 정도 필사를 했고, 전반적인 흐름은 이해하지만, 여전히 이해가 되지 않은 부분도 있었다. 그러고 나서, 몇 번 더 필 사하고 나서 논문에서 여기서 이야기 하는 수식의 유도가 이해가 되기 시작했다. 최종에는 내가 필요로 하는 수식을 추출을 하였고 그 것을 활용하여 내 졸업 요건에 필요한 주요 저널 논문의 작성이 가능했다. 즉, 나의 에너지를 최대한 사용하여 목표에 도달하는 방법이었다. 효과와 효율을 고민하여 나의 최대한을 끌어 낸 경우였다고 생각된다.

앞에서 이야기 했 듯이 책을 읽을 때, 목적과 비용에 대해서 생각하면서 읽는 것이 필요하다. 그렇게 해야 효과적으로 효율적으로 할 수 있다는 부분이다. 목적의 경우, 어떻게 활용할 것인가 글을 쓰기 위한 것인가 아니면 학습을 위해 나의 행동에 어떻게 연결 할 것인가 고민하면서 읽는 것이 중요하다. 정확한 목표 없이 흥미를 위해서도 읽을 수 있다. 하지만, 목표를 분명히 하지 않으면 효과가 떨어질 수 있다. 효율 측면에서는 에너지를 많이 넣어야 하는가 적게 넣을 것인가도 고민해 볼 부분이다. 마치 산책을 하듯이 힘을 최대한 빼고 읽어야 하는 상황이 있을 수도 있고, 남극 탐험을 하듯 이 내가 가야 하는 목표를 향해 나의 에너지를 다 써야 한다면 어떻게 해야 할 것인가도 고민할 수 있는 것이다.

참조 문헌

[1] L. Xu and J. Heizer, "Media streaming via TFRC: An analytical study of the impact of TFRC on user-perceived media quality", Proceedings of IEEE INFOCOM, Jan. 2006, http://personal.ie.cuhk.edu.hk/~dmchiu/reading/infocom06_tfrc.pdf

다니엘 핑크의 "후회의 재발견", 원제는 "Power of Regret"[1]. 신철님 진원님께서 추천해 주셨던 것으로 기억하여 바로 주문하여 책을 받아서, Reading less를 시도해 보았다.

우리는 우리 의지대로 될 것이라는 "자유 의지"와 모든 일에는 이유가 있다는 "환경"의 교차점에 살고 있다고 저자는 이야기 한다. 여기서 불행이 발생했을 때, 거기서 부터 구원의 시퀀스(redemption sequence)로 가는지 아니면 다른 방향으로 오염 시퀀스(contamination sequence)가는지 이 두 가지 경우가 서로 우위를 차지하기 위해서 경합을 벌인다고 한다. 마치 디즈니의 인사이드 아웃에서 예전의 슬픈 기억도 가족들과 이겨내는 시퀀스가 연결될 것인지 아니면 거기에 머무를 것인지 바뀌기도 하는 것도 이와 관련되어 보인다.

저자는 또한, 스포츠에서 2위 선수의 내가 조금 더 "했더라면" 1위 했을 텐데라는 입장과 3위 선수가 "적어도" 4위를 하지 않아 메달을 땄다라는 것에서 누가 더 만족하고 있는가에 대한 차이도 이야기 한다. 그러면서, 감정을 바라보는 두 관점에 대해서 이야기 하는데, "무시해야 할 것"과 "중요한 것"이라는 입장에 대해서도 설명한다. 무시할 것이라는 입장은 감정을 묻어 두면 결국 직면해야 할 순간을 유예하는 것 뿐이라고 이야기 한다. 또한, "중요한 것"이라는 것은 감정이 우리 존재의 본질이라고 생각하고 "항상 자신의 감정을 믿어라"라고 이야기 한다. 나 예전에는 전자의 입장이었지만 후자의 입장을 가지고 있다.

저자는 책에서 위에 이야기 한 두 방법 이외에 새로운 접근 방법을 제안 한다. 그 감정에 대해서 "생각"을 보태어 "행동"으로 보다 나은 향샹된 성과와 보다 깊은 의미를 찾도록 하는 다른 접근 방법을 제시한다. 이것을 후회 최적화 프레임워크라고 부르고 있다.

참고

[1] 다니엘 핑크, "후회의 재발견 - 더 나은 나를 만드는, 가장 불쾌한 감정의 힘에 대하여", 김명철 (옮긴이) 한국경제신문

복잡계 3인방 오프라인 모임을 가졌다. 무엇보다도 린다 라이징의 이야기가 나와서 반가웠다. 그러고는, YouTube에서 다니엘 커너만의 "생각에 대한 생각(Thinking, fast and slow)"에 대한 그녀의 발표 [1, 2]를 들었다. 무엇보다도 그녀의 문제 해결 접근법이 매우 인상적이었다.

1. 문제를 정의한다. 크게 이야기 해보고, 종이 위에 써본다.

2. 데이터가 충분한가?
3. 해결하기 위해 최소한의 시간을 투자한다. (1번과 2번의 내용을 조정하기 위해서 사용하기도 한다) 10분이 넘지 않게 한다.

4. 적절한 해결 방안이 나오지 않는다면, 그 일에서 손을 놓는다. 아마도 다음과 같은 일을 할 수도 있다.

    - 다른 작업을 한다.

    - 서거나, 앉거나, 스트레칭을 한다.

    - 짧은 휴식(bio break)을 취한다.

    - 긴 휴식을 취한다. (운동, 식사, 다른 용무, 수면)
5. 인사이트가 없다면, 위 단계를 반복한다.
6. 시스템 1은 항상 옳지는 않다. 시스템 2가 최종 결정을 하게 한다.

아마도 이미 많은 사람들이 사용하는 방법일 것이다. 특히, 4번의 경우는 이미 알려진 아이디어를 찾아내는 방법이라 할 수 있다. 그녀의 발표에도 있는 스티브 잡스의 "Let's go for a walk"라는 인용에서도 대가들의 이 도구 사용에 대해서 슬쩍 살펴 볼 수 있을 것이다. 송 나라 시대의 구양수의 시상을 생각하는 세 가지 장소인, 침상, 마상, 측상과 연결 되기도 한다. 누군가가 놀리고 웃을지도 모르지만, 어려운 문제를 만나게 되면 나도 사용하던 방법들이기도 하다.

참고

[1] Linda Rising, "Thinking, fast and slow" slides, https://agile2018.sched.com/event/EU9Z/thinking-fast-and-slow-so-what-can-we-do-about-it-linda-rising

[2] GOTO conference, Linda Rising, "Thinking, fast and slow", https://youtu.be/XjbTLIqnq-o

[3] Microsoft Research, Daniel Kanhmen, "Thinking, fast and slow", https://youtu.be/C-4MM8sd3BE