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

애자일 소프트웨어 개발 중에서 처음 제안이 되기도 했고, 가장 극단적인 방법이 Extreme Programming(XP)이라고 볼 수 있다. 프로세스 적인면에서 특히 그렇다. 또한 짝 프로그래밍(Pair programming), 지속적인 통합(Contiunous Integration), 테스트 주도 개발(Test-drinven development)와 같은 많은 실천법이 다른 개발에서도 채용되기도 했다.

여기서는 마틴 파울러의 2004년도 글[1]을 요약한 것이다. 원문을 읽어 보면 알게되지만, 마틴 파울러는 켄트 벡과 같은 좀 더 극단적인 XP 추종자들 보다는 더 실용적고 다른 접근 방법에 대해서도 열려 있는 것으로 보인다. 이 부분은 아키텍처 설계에 대한 관점에서 부터 크게 차이가 난다.

계획 설계(Planned Design)과 진화적 설계(Evolutionary Design)

마틴은 프로젝트 초반에 충분한 시간을 들여 소프트웨어 설계하고 진행하는 기존의 방식을 계획 설계라고 하고 XP와 같이 설계하는 단계 없이 점진적인 개발에서 나오는 소프트웨어도 아키텍처 혹은 구조가 있다고 하고 이를 진화적 설계로 불렀다.

애자일 개발에서 진화적 설계에 대해서 일반적인 비판은 임시 방편의 모음이라는 것이다. 마틴은 글에서 "우선 코딩하고 문제는 나중에 고친다(code and fix)"라고 설명하고 있다. 그리고, 시간이 지남에 따라 점점 더 코드에 기능을 추가하기 힘들어 지고 버그 수정 비용도 기하급수적으로 증가한다고 지적한다.

그렇다면, 반대로 계획 설계에는 문제가 없는가? 계획 설계에서는 설계자와 구현 담당자가 분리된 경우 종종 있다. 이러한 환경은 구현을 하는 동안에 해결해야 하는 문제를 설계자가 생각할 수 없어 문제를 만들기도 한다. 또한, 많은 개발자가 경험하지만, 요구 사항은 지속적으로 변하게 되어 있다. 이러한 문제들도 계획된 디자인을 유연하게 만들지 못하고 결국에는 "우선 코딩하고 문제는 나중에 고친다"의 접근법을 사용하게 된다고 마틴은 주장한다.

XP에서의 진화적 설계가 가능하게 하는 실천법

마틴은 이러한 문제의 해결법이 바로 XP에서 사용하는 실천법이라고 한다. 즉, 지속적인 테스팅(TDD)과 지속적인 통합(Continous Integration)이다. XP에서는 구현하기 전에 요구 사항을 테스트하는 테스트 코드를 만들고 이를 구현하고, 구현된 테스트 케이스들이 기존 코드의 동작을 보장하는 테스트 주도 개발(Test Driven Development)를 사용한다. 이를 통해서 다른 팀이 개발하는 기능의 통합도 매시간 혹은 매일하게 된다 (Continous Integration).

그 유명한 리팩토링[2]을 쓴 마틴은 리팩토링의 효과도 강조한다. 주먹구구의 느슨한 구조의 재구성과 비교해 XP에서 이야기하는 리팩토링은 아주 강력한 효과를 제공한다고 이야기 하고, 마틴으 켄트 벡으로 부터 이를 배우고 난 후에 자신이 책까지 썼다고 이야기 한다. XP에서 이야기하는 리팩터링은 TDD를 위한 테스트 코드가 존재해야 하고, 기능을 추가하지 않은 상태에서 구조를 변경하는 것이다. 리펙터링의 단순한 예제들을 따라해 봐도 이러한 것이 주는 효과는 분명하다.

디자인 패턴에 대한 마틴의 의견은?

나도 애자일 선언문[3]의 12가지 원칙 중 가장 좋아하는 부분이 "단순성이 -- 안 하는 일의 양을 최대화하는 기술이 -- 필수적이다(Simplicity--the art of maximizing the amount of work not done--is essential)"이다. 마틴도 이 단순성을 매우 강조한다. 즉, 현재 단계에서 필요한 것만 구현하는 것이다.

디자민 패턴에 대해서도 마틴은 다음과 같은 조언을 한다. XP 추종자들에게 하는 조언이기는 하지만, 애자일리스트에게는 누구에게나 적용될 수 있다.

• 패턴에 대해 학습하는 시간을 미리 해두자.
• 패턴을 언제 적용할 것인지 시기에 집중한다. 너무 일찍 적용하지 않도록 하자.
• 먼저 가장 단순한 형태로 패턴을 구현하는 방법에 집중하고 복잡한 것은 나중에 추가하자.
• 패턴을 넣었지만 충분한 효과가 없다고 생각되면 과감히 제거하라.

아키텍처 키우기

이 글[1]에서 마틴 파울러의 유명한 소프트웨어 아키텍처에 대한 정의가 나오기도 한다. 그는 소프트웨어 아키텍처를 시스템의 변경하기 어려운 부분인 시스템의 핵심 요소(core element)의 개념(notion)이라고 정의 한다.

물론 마틴은 자신을 켄트 벡과 같은 극단적인 XP 추종자가 아니라고 인정하면서 초기 소프트웨어 아키텍처가 필요하다고 이야기 한다. 하지만, 이 설계가 확정되어서 바뀌지 않는다고 생각하지 않는다. 도리어 초기 결정에 문제가 있을 수 있다는 것을 인정하고 과감하게 변경할 수 있어야 한다고 이야기 한다.

예를 들어 Enterprise Java Bean(EJB)와 같은 개발 언어는 초기에 결정해야 하는 중요한 결정일 수 있다. 그렇다면 EJB를 쓸지 않을지 결정은 프로젝트의 초기에 하는 것이 좋을까 가능한 늦게 하는 것이 좋을까? 당연히 가능한 초기에 결정하는 것이 좋을 것이다. 그렇다면, 과제를 시작하면서 바로 결정하는 것이 가장 좋을 것이다. 다시 생각해 보자. 그렇다면, 우리 과제에 EJB가 필요한지 아닌지 어떻게 알 수 있을까? 이를 확인하기 위한 진행이 가장 먼저 선행되어야 할 수 있다. 그 결과 EJB를 프로젝트에서 쓸지 아니면 쓰지 않을지 아키텍처적으로 결정하고 진행할 수 있을 것이다. 이 것이 마틴이 주장하는 소프트웨어 아키텍처를 진화적으로 활용하는 요체라고 할 수 있다.

전통적인 XP 추종자들은 아마도 데이터베이스가 필요할 때까지 데이터베이스를 적용하는 것을 가능한 미룰 것이다. 하지만, 마틴은 많은 사용자가 사용하는 시스템에서 다량의 데이터가 있다면 첫날 부터 데이터 베이스를 고려하고, 복잡한 비지니스 로직이 보이면 도메인 모델을 아키텍처에 넣으라고 조언한다.

문서화(UML 사용하기)

문서는 애자일리스트에게서는 적과 같다. 그렇기 때문에 UML에 사용도 그렇게 치부되어 왔다. 하지만, 많은 애자일을 따르는 개발자들이 단순화 된 UML을 사용하는데 이 또한 마틴에게 영향 받은 것을 보인다.

마틴은 다이어그램을 잘 사용하기 위한 조언도 제공한다.

1. 다이어그램의 일차적 가치는 소통이므로 이를 읽을 독자를 먼저 두어야 한다. 즉, 중요한 것은 넣고 덜 중요한 것은 빼는 것이 중요하다고 강조한다.
2. 어려운 작업일 수록 모여서 빠르게 설계 세션을 가지는 것이 중요하다고 이야기 한다. 하지만, 이 세션은 짧고, 중요한 사항만 다르며, 결과물은 최종 디자인이 아닌 스케치로 간주한다.
3. 이러한 선행 설계는 잘못된 부분이 반드시 있을 수 있다는 것을 인정하고, 구현하면서 발경하면 디자인을 변경해야 한다는 것이다. 
4. 디자인을 변경한다고 해서 다이어그램을 변경할 필요가 없다. 디자인을 이해하는데 도움이 되었다면 충분하고 그 다이어그램은 버려도 된다.
5. 다이어그램이 지식 전달(Knowledge Transfer)할 때에도 유용고 중요한 문제를 요약하고 강조하는 역할을 한다. 하지만, 코드가 가장 자세한 정보의 저장소임을 잊지 말자.

경력이 쌓이면 아키텍트가 되길 원하나요?

결론 부터 이야기 하면, 마틴은 테크니컬 리드가 되라고 이야기 한다. 아키텍트라고 하면 개발 업무에서 멀어지고 코딩을 하지 않는 높은 사람처럼 보인다. XP에서 하듯이 경험많은 개발자는 자신의 기술을 강화하고 팀의 여기 저기를 다니며 코칭과 가르침을 주는 것이 더 의미있다고 주장한다.

여기서 고민을 해보자. 이글은 2004년도의 글이다. 2022년 내가 알고 있는 테크니컬 리드의 상반되는 양쪽 극단은 어떤 것일까? 아마도 자신의 도메인에서 경험이 아주 많은 아키텍트가 있을 것이고, 다른 한쪽에는 실무 능력을 아주 무섭게 키운 소프트웨어 장인(Software Craft)가 있을 수 있겠다. 이 두 사람 모두 자신과 연결된 사람들에게 긍정적인 영향을 끼치며 프로젝트가 좋은 방향으로 흘러가게 기여하고 있다고 가정해 보자.

아키텍트는 코딩이나 심지어 코드리뷰도 전혀 하지 않을 것이다. 그가 하는 일은 도메인의 지식을 넓히기 위해 트렌드를 익히고, 매일 다이어그램을 그리고 이를 기반으로 몇몇의 모듈 개발 팀의 일부 인력들(리더 혹은 그 팀의 아키텍트일 수 있고 개발자 일 수도 있다)과 소통하며 방향을 잡을 것이다. 또한, 이 인력들에게 아키텍처 설계에 대해 코칭하고 가르치고 있을 것이다. 소프트웨어 장인은 늘 자신의 개발 역량을 강화하기 위해 반복 연습(카타, 태권도의 품새 같은 연습 루틴)을 하고 새로운 기술을 익힐 것이다. 자신의 담당 모듈의 완성도를 높이며, 자신이 속해 있는 동료들과 협력하며 그들을 코칭할 수 있는 것을 생각해 볼 수 있다. 

이 둘은 서로 다르지만, 또한 비슷한다. 자신의 역량을 강화하고, 프로젝트를 위해 기여를 하며, 주변에 있는 동료들을 코칭하며 가르칠 것이다. 우리는 이 두 사람 사이에 어디엔가 있을 것이다. 그렇다면, 올바른 길을 가고 있는 것이라고 이야기 하고 싶다.

가역성(Reversibility)

마틴은 글에서 애자일 방법론에서 가역성의 중요합에 대해서 이야기 한다. 이 부분이 아키텍처에서도 중요하다는 것이다. 즉, 진화적 설계의 측면에서 되돌리기 쉬운 것은 덜 중요한 것이고 되돌릴 수 없는 결정이 중요한 결정이라는 것이다. 이러한 평가를 위해서 미래의 변경이 얼마나 어려울지 실험해 보는 것도 의미가 있다고 이야기 한다.

진화적 설계가 일어나고 있는가?

마틴은 진화적 설계가 일어나는지 파악하는 것이 어려운 일이라고 한다. 최근에는 프로그램 구조에 대해서 정량적/객관적 측정방법도 제안이 되고 있다. 하지만, 마틴은 이 부분은 주관적인 사실 정성적/주관적 측정이 되어야 하는 부분이라고 주장한다. 개발자가 아닌 이해당사자들은 이 부분에 대해서 이해하기 어려울 것이다. 고객의 경우를 생각한다면 자신들이 지불하고 있는 소프트웨어가 이 후에 기능을 추가하려면 더 많은 비용이 들 것인지 아닌지 알 수 없다는 것이다.

마틴은 구체적인 방법 대신 몇가지 제안을 한다.

• 개발자의 이야기를 들어 보자. 코드베이스가 변경하기 어렵다고 불평한다면, 이를 심각하게 받아들이고 문제를 해결할 시간을 주어야 한다.
• 얼마나 많은 코드가 버려지고 있는지 살펴 보자. 건강한 리팩토링을 하고 있다면 꾸준히 나쁜 코드는 삭제되고 있다. 버려지는 코드가 없다면 리팩토링이 충분하지 않다는 것이 거의 확실하다.

이러한 제안에도 불구하고 이 지표 또한 남용될 수 있다. 하지만, 우수한 개발자들의 의견은 매우 가치가 있다고 마틴은 주장한다.

참고 문헌

[1] Martin Folwer, "Is Design Dead?", https://martinfowler.com/articles/designDead.html

[2] 마틴 파울러, "리팩터링 2판 (리팩토링 개정판) - 코드 구조를 체계적으로 개선하여 효율적인 리팩터링 구현하기", 한빛미디어, 2020, 역자 남기혁

다음 글[1]에 있는 내용을 요약한 것이다.

얼마나 아키텍처링을 해야 하는가?

여기서도 애자일에서도 [2]에서와 같이 소프트웨어 아키텍처가 필요하다고 이야기 하고 있다. 애자일 측면에서는 창발(emegence)한다고 이야기 하고, [2]에서는 진화적 설계라는 이름이로 이야기 하고 있다. 특히, 요사이는 DevOps등도 채용되고 있기 때문에 계획된 설계 보다는 진화적 설계가 더 널리 받아들여 지고 있다.

[1]에서 아키텍처링이 얼마나 진행되어야 하는가에 대해서는 [2]에서와 마찬가지로 "적정하게(Just Enough)"라고 이야기 한다. 기본적으로 구출할 프로젝트나 제품에 따라 다르다고 하는 부분은 일치한다. 또한, 어느 시점에 하느냐의 경우도, 스프린트 제로 혹은 일부 스프린트(이터레이션, 반복)에서 진행해야 하는 것도 필요하다고 이야기 한다. 하지만, 어떻게 하느냐의 부분은 달라진다.

진화적 설계의 입장에서 위에서 언급한 것 같이 여러 번의 스프린트에서 재설계(소위 리팩터링)으로 아키텍처가 확정된다면, 초기에 충분한 선행 설계(Upfront Design)가 있는 것이 나을 수도 있었다. 저자는 이러한 것 때문에 이런 결정이 섯부르게 처리한 것이고 지연과 막대한 기술 부채를 발생시킨다고 이야기 하고, 이것이 도리어 애자일 철학에 모순된다고 주장한다. 

큰 기업에서의 소프트웨어 아키텍처 및 애자일 접근법

이 세셕이 [1]의 가장 중요한 부분이라고 할 수 있다.

처음에는 작은 스타트업으로 시작했던 기업이 크게 성장하는 경우에도 여전히 애자일 개발 방법론이 적용된다. 이는 자기조직화(Self-organized)되어 있고 작은 팀들이 책임지고 있는 기능들은 애자일하게 개발이 된다. 예측하기 힘든 여러 상황에서 팀은 이를 해결하며 적응적으로 개발을 진행한다. 특히, 이 애자일리스트들은 이러한 과정 속에서 자신들의 소프트웨어 아키텍처가 창발(emgerge)한다고 믿는다.

그렇지만, 앞에서 이야기 한데로 이러한 여러 팀이 있는 경우라면 회사의 전체 시스템을 이해하기 어렵고 기업에 가지는 전체의 맥락을 이해하기 어려우며 팀이 여러 중복 솔루션이나 호환성을 떨어 뜨릴 수도 있다. 이를 위해서 이러한 문제를 다룰 수 있는 전담인력들이 필요할 수 있다. 즉, 애자일과는 반대 방향일 수 있으나 중앙 집중적인 방법으로 관리되어 참조 아키텍처(Reference Architecture)으로 관리되어야 한다.

두 가지 측면이 반대이고 호환되지 않는 것 처럼 보일 수 있다. 하지만, [1]에서는 SAFe의 Agile Architecture를 설명하면서 이 두가지가 호환되며 상호보완적이라고 주장한다. 기존과 가장 다른 점은 자기조직화팀의 새로운 디자인을 선행 디자인으로 만들어지는 전체 아키텍처에 통합하면서 진행하는 것이다. 저자는 이를 리트로-피딩(retro-feeding, retrospective, 회고)이라고 한다.

이러한 접근법에서 두 가지 장점을 강조한다.

1. 의도적 아키텍처를 각 팀이 참조하여 필요로 하는 솔루션을 구축할 수 있다.
2. 그러면서도, 팀이 어느 정도의 혁신할 수 있는 여력을 가지고, 이를 의도적 아키텍처에 포함하게 개선하고, 다른 팀이 이를 활용할 수 있게 한다.

이렇게 하기 위한 구조로는 Spotify의 챕터를 [1]에서는 이야기 하지만, 일반적으로 시스템 아키텍트와 어플리케이션 아키텍트 처럼 역할을 나누어 수행할 수도 있을 것으로 보인다.

참고 자료

[1] Miguel Arlandy, "Software Architecture and Agile. Are they both really compatible?" , Feb 19, 2019

https://medium.com/quick-code/software-architecture-and-agile-are-they-both-really-compatible-c1eef0afcbb1

[2] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010 https://technical-leader.tistory.com/89

이 부분은 소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)[1]의 2장에 나온 내용을 정리한 것이다.

아키텍처와 설계

저자는 아키텍처와 설계를 비교 설명한다. 이를 수행하는 아키텍트와 개발자의 역할이 다음과 같다고 이야기 한다.

아키텍트는 아래 사항을 수행한다

1. "비즈니스 요구사항"을 분석하여 "아키텍처 특성(Architecture Characteristics, ~bilities ~성)"을 도출/정의하고
2. 어떤 "아키텍처 패턴"과 "아키텍처 스타일"이 해당 문제 영역에 적절한지 선택하여
3. 각종 "컴포넌트(시스템 구성 요소)"를 만든다.

개발자는 다음 역살을 수행한다.

1. 아키텍트의 수행 결과인 "아티팩트(artifact 산출물)"이 전달되면, 컴포넌트의 "클래스 다이어그램(상세 설계)"를 그린 뒤
2. "UI 화면"을 만들고
3. 소스 코드를 개발/테스트 한다.

이 부분에 대해서는 이견이 있을 수 있다. 상세 설계에 해당한다고 보이는 부분도 아키텍처에서 중요하다고 할 수 있는 품질 속성(Quality Attribute, 이 책에서는 아키텍처 특성이라고 하고 있다.)과 관련될 수 있고 이 부분이 아키텍처와 관련된 산출물에 포함되어 설명될 수 있기 때문이다. 이 책에서는 이러한 내용은 명시되어 있지는 않지만, 아키텍트와 개발자의 소통의 중요성을 이야기 하면서 언급되고 있다.

기술 폭(Technical Breadth)

아키텍트이든 개발자 이든 자신이 알고 있는 기술 세부의 범위는 한정적일 수 밖에 없다. 그렇다면, 아키텍트의 이 범위가 어떻게 될까? 책의 저자는 "내가 알고 있는 것", 내가 모른다는 사실을 아는 것" 그리고 "내가 모른다는 사실조차 모르는 것"으로 지식을 설명한다.

저자는 여기에서 지식의 깊이(Depth)와 폭(Breadth)를 구분하면서 개발자는 이 기술의 폭을 넓혀야 한다고 주장한다. 이 지식의 폭을 넓혀야 하는 이유 중에 하나가 다양한 분야에 전문성을 유지하려고 하면, 어느 하나에도 전문성을 충분히 확보하지 못할 수 있기 때문이다. 두 번째는 김빠진 전문성(stale expertise)이 나타나 자신은 첨단이라고 이야기 하지만, 실상은 낡은 정보만 가지고 있는 경우가 생긴다는 것이다.

정도의 차이는 있을 수 있으나 자신의 전문성을 가지고 다른 분야에도 얕지만 넓은 지식을 가지는 T자형 인재 혹은 제너럴라이징 스페셜리스트(Generalizing Specialist)[2]가 좋은 인재상으로 이야기 된다. 여기서도 깊이와 폭으로 이해될 수 있다. 마치 스펙트럼으로 살펴 보면, 한 분야의 깊이만 아주 깊은 학교의 교수, 전문가를 한쪽 끝으로 생각할 수도 있고 넓이만 아주 넓은 강연자, 이야기꾼을 반대쪽 한쪽 끝으로 생각할 수 있다. 경력이 높은 개발자와 경험이 많은 아키텍트는 모두 이 사이에 있을 것이고 개발자는 스페셜리스트에 이키텍트는 제너럴리스트에 가까울 수 있다. 하지만, 이키텍트들도 획일적으로 한 포인트에 머무르는 것이 아니고, 이 깊이와 폭이 가지각색인 것을 쉽게 예상할 수 있다.  

트레이드오프 분석

저자들은 아키텍처 사고(Architectural Thinking)의 요체를 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것이라고 한다. 책에서는 간단하지만 좋은 비교를 통해서 이 부분이 담고 있는 내용이 어떤 것인지 설명한다. 대표적인 소프트웨어 아키텍처 설계 방법인 속성 주도 설계(ADD, Attribute Driven Design)[3]에서는 품질 속성을 요구사항으로 도출해 내고 여기에 맞는 설계 전략 혹은 아키텍처 패턴/스타일을 적용[4]하는데, 여기에서 다루게 되는 것이 결국은 트레이드오프가 된다고 볼 수 있다.

책[1]에서는 경매 시스템을 구현할 때 컴포넌트 간의 연결을 Queue 혹은 Topic을 사용하였을 때, 트레이드오프에 대해서 논의 한다. 실재 설계할 때에는 접근 방법이 다르지만, 여기서는 우선 두 기술의 장점/단점을 비교하여 트레이드오프가 두드러지게 하였다.

Queue/Topic의 장단점 비교

실재로는 어떻게 될까? 여러 요인이 있겠지만 시스템의 품질 속성과 같은 여러 요소들에 따라 더 적절한 기술을 선택해 가는 것이 아키텍처 설계가 된다.

아키텍처와 코딩 실무 간의 균형 맞추기

이 책의 저자 뿐 아니라 다른 책의 저자들도 이야기 하지만, 아키텍트도 개발자로서 코딩 실무를 놓지 말아야 한다는 이야기를 많이 한다. 저자는 특히 이러한 균형을 맞추는 여러가지 방법을 제안하고 있고, 아주 실용적인 예들이기도 하다.

1. 개념 증명(Proof of Concept, PoC)를 주주 해보자
2. 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채(Technical Debt) 스토리나 이키텍처 스토리에 전념한다.
3. 개발 이터레이션을 하는 도중에 버그를 잡는다.
4. 개발팀 일상 업무를 간소화 하거나 자동화 하는 간단한 커맨드라인 도구나 분석기를 만든다. 아키텍처 컴플라이언스 보장을 자동화 하는 피트니스 함수 측정기로 쓸 수 있는 아치유닛(ArchUnit)을 이용할 수 있다.
5. 자주 코드 리뷰를 한다.

4번 자주 하고 있는 것 중에 하나이다. 또한, 5번은 코드의 흐름을 놓치지 않을 수 있는 좋은 접근 방법이기도 하다.

참고 문서

[1] 마크 리처즈, 닐 포드, "소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)", 한빛 미디어, 이일웅 옮김, 2021

[2] 위르헌 아펄로, "매니지먼트 3.0" 에이콘, 조승빈 옮김. 2019

[3] 렌 베스, 폴 클레멘츠, 릭 캐즈먼, "소프트웨어 아키텍처 이론과 실제, 개정 3판" 에이콘, 전병선 옮김, 2015 

[3] "Software Architecture: 어떻게 설계 할 것인가?," https://technical-leader.tistory.com/35

"신호와 소음"은 "슈퍼 예측"에서도 언급되었고 또한 미국 선거 예측으로 유명한 네이트 실버의 책이다. 책이 크게 4개의 섹션으로 나뉘어 있다. 첫 번째 섹션인 '예측에 대한 근본적인 의문들'에서는 여러 사례들을 통해서 예측에 관해 이야기를 한다.

1장 '경제: 경제 붕괴, 왜 전문가들은 예상하지 못하는가'에서는 리먼 브라더스를 시작으로 한 경제 붕괴에 대한 이야기이다. 많은 이들이 이 사건을 블랙 스완이라고 한다. 하지만, 이 사건을 배경으로 하는 영화 '빅 쇼트'에서도 나오지만, 여러 조짐이 시장에서 보였다. 책에서도 주택가격 폭락은 블랙 스완이 아니고, 모두 알고 있지만, 이야기 하지 않고 큰 문제를 가리키는 '방 안에 들어와 있는 거대한 코끼리'였다고 이야기 한다.

특히 이 장에서는 위험과 불확실성에 대해서 구분하여 설명한다. 위험은 가격을 설정할 수 있다. 측정할 수 있는 위험의 예에는 포커에서 하나가 틀린 스트레이트가 완성될 확률은 정확히 1/11이라고 한다. 반면에 불확실성은 측정하기 어려운 위험이다. 불확실성에 대한 예측은 100배 빗나갈 수도 있고, 1000배 빗나갈 수도 있다. 저자는 위험은 자유시장 경제의 바퀴에 윤활유를 칠하지만, 불확실성은 바퀴를 갉아 멈춰 서게 한다고 이야기 한다.

특히, 시장 경제에서 탐욕과 공포는 변덕스럽다고 이야기 한다. 이 둘은 시장의 균형을 만들지만, 또 둘 사이의 균형은 언제든 흔들릴 수 있다고 이야기 한다. 탐욕 과잉은 거품 그리고, 공포 과잉은 공황을 만들어낸다고 설명한다.

빅 쇼트 영화에도 나왔지만, 역사적으로 일어나지 않았다고 그것이 일어나지 않을 것이라 믿는 것은 문제가 있다. 부동산은 안전하다고 믿는 것은 문제가 있다는 것이다. 또한, 여유 마진이 없는 경우 조금만 잘못되어도 겉잡을 수 없다는 것이다. 또한 빅 쇼트 영화에서 계속 나오는 것이 자산의 평가가 구조적인 문제로 계속해서 잘못되고 있었다는 것이다. 즉, 표본 외 상황이 발생하고 그에 대한 대비가 되어 있지 않은 상태에서 위기가 왔던 것이라 볼 수 있다.

2장에서는 네이트 실버가 유명해진 선거 결과를 예측 하는 것에 대한 이야기를 한다. 여기서는 "슈퍼 예측"의 테틀록의 그 이전 연구인 '전문가의 정치적 판단(Expert Political Judgement EPJ)'를 언급한다. 특별히 여기서 인용한 부분은 전문가들의 경우 하나같이 동전을 던져 판단을 내릴 때보다 낫지 못했다라는 매우 공격적인 비판이다. 그러면서, 예측을 하는 사람들을 고슴도치와 여우 두 부류로 나눠서 설명한다. 그러면서, 여우는 경험에서 예측을 업데이트 하면서 정확도가 높아진다. 반면, 고슴도치는 자기 편견의 강화 가능성이 더 높아져서 정확도가 더 나빠진다고 설명한다. 즉, 우리는 분석 작업에서 어느 한쪽을 응원하는 마음은 접어두고, 여우의 접근 방법으로 우리가 다루는 사실 그 자체에 접근할 필요가 있다고 주장한다.

예측하는데 도움이 될 수 있는 여우의 원칙은 다음과 같다고 설명한다.

1. '확률적으로 생각하라'라는 것이다. 즉, 결과가 일어날 가능성을 범위로 제시하는 것이다. 이 것은 실제 현실에서의 불확실성을 가장 정직하게 표현하는 것이라 볼 수 있다.

2. 날마다 새로운 예측을 하라는 것이다. 상황은 계속해서 달라질 수 있다. 그리고, 옛날의 예측이 잘못된 것이 분명하다면 어제의 예측이 매달릴 이유는 없기 때문이기도 하다.

3. 집단지성을 활용하라는 것이다. 책에서는 집단 예측이 개인 예측보다 10~25% 정확하다고 언급한다.

저자는 예측 작업을 할때 양적인 접근을 좀더 선호한다. 그러면서, 객관적이라는 것이 계량적(Quantitive)와 동의어로 사용한다고 이야기 한다. 또한, 객관적이라는 것을 개인적 편향과 편견 너머에 있는 진리를 바라본다는 뜻이라고 이야기 하고 있다. 이렇게 하기 위해서 계량적으로 측정하는 것도 편견을 배재하는데 도움이 될 수 있다고 생각한다.

'예측에 대한 근본적인 의문들' 섹션의 마지막 3장에서는 "야구: 야구경기는 왜 모든 '예측'의 모델이 되는가'이다. 제목에서도 알 수 있듯이, 야구에서의 예측에 관한 것이고 이것은 영화 '머니볼'로도 알려진 머니볼에 대해서 이야기 하고, 최근에 한국에서도 유명했던 드라마 '스토브 리그'도 생각하게 하는 챕터였다.

저자는 좋은 야구 예측 시스템은 다음 세가지 기본 사항을 갖추어야 한다고 이야기 하면서, 아래와 같이 설명한다.

1. 각 선수의 통계 자료가 갖는 맥락의 의미 설명하기

2. 실력과 운을 분리하기

3. 노화곡선(선수가 나이와 성적의 관계) 이해하기

우선 야구 선수에 대한 예측을 이야기 한다. 즉, 한 선수가 언제까지 좋은 성적을 내며 뛸 수 있을까가 중요한 질문일 수 있다. 사실 야구 선수의 실력은 고정된 게 아니라 끊임없이 변한다. 바로 여기 예측가의 도전과제가 있다고 저자는 이야기 한다. 이론적인 노화곡선은 '평균적으로 볼때만'매끄러운 곡선 모양이다. 선수는 신인에서 시작하여 스물 일곱살에 절정기를 맞고 떨어지기 시작한다. 그러나 실재로 선수 개개인의 측면에서 보면 노화는 선수마다 다른 속도로 진행된다. 또한, 지독할 정도로 소음이 많다.

머니볼적이 측면에서 이 예측을 활용해야 하는 사람들이 스카우터일 것이다. 하지만, 머니볼이 처음에는 성공했을지 모르지만 통계학자들이 계속적으로 성공을 한 것이 아니다. 스카우터들도 혼합 방식의 접근법을 사용하는 것이다. 즉, 보이지 않는 요소들도 고려하는 것이다.

책에서는 정신적 도구 상자(mental toolbox)라고 소개하는 어떤 선수가 메이저리그에서 성공할 것으로 예측하는데 도움이 된다고 그가 믿는 지적/심리적 능력 다섯 가지를 소개한다.

(1) 준비성과 노동 윤리 : 날마다 프로답게 프로 수준의 기량을 펼쳐야 한다. 일정한 량의 훈련을 반드시 해야한다.

(2) 집중과 초점 : 선수가 경기중에 취하는 태도와 관련이 있다.

(3) 경쟁심과 자신감 : 실패의 두려움을 극복할 정도로 더 높은 성공을 거두고야 말겠다는 바람과 각오가 있는가

(4) 스트레스 관리와 겸손 :

(5) 적응력과 학습 능력 : 새로운 정보를 얼마나 성공적으로 처리하는가? 조언에 귀를 기울이는가? 변화에 어떻게 대응하는가?

책에서는 머니볼이 죽었다고 이야기 한다. 죽었다고 이야기 하기에는 과장된 느낌이 있다. 이미 모든 사람들이 그것을 채용하고 있기 때문이다. 만일 그것을 채용하지 않았다면 다 뒷쳐졌을 것이다. 어찌 보면 머니볼만 보던 사람들은 다른 사람들이 하고 있는 유용한 것을 놓치기 때문에 도리어 뒷쳐질 수도 있다. 그렇다면 진정한 머니볼은 죽었을지 모른다. 좋은 발상을 했다더라도 금방 다른 사람들이 달려 들어 그걸 베끼고 그들 자신을 제쳐 버리기 때문이다.

최근에 보고 있는 미드 Foundation의 대사가 생각이 난다. “You can't save yourselves, but you can save your legacy.”

참고 문헌

[1] 네이트 실버 저/이경식 역, '신호와 소음 미래는 어떻게 당신 손에 잡히는가,' 2014년 07월 11일

조지 페어뱅크스의 "Just Enough Software Architecture: A Risk-Driven Approach"[1]은 성공적으로 소프트웨어를 만드는 것이 "가능한 실패를 예상하고 실패할 수 있는 설계를 피하는 것을 의미"한다고 이야기 한다. 그렇기 때문에 실패 리스크를 찾고 이것에 매핑하는 소프트웨어 설계 테크닉을 적용하는 것이라고 한다.

책에서 말하는 리스크 주도 모델의 경우는 다음과 같은 단계를 거치면서 반복하는 과정이라고 말한다.

1. 리스크 식별/우선 순위 지정
2. 적용할 테크닉 선택/적용
3. 리스크 감소의 평가

소프트웨어 개발은 설계만으로 끝나는 것이 아니고 구현을 해야 한다. 그러므로 다음과 같은 예의 논리를 바탕으로 진행하는 것을 제안한다.

"A, B 그리고 C를 리스크로 식별하고, B는 매우 중요하다. 이를 위한 테크닉 X와 Y를 통해 B의 리스크를 줄일 수 있다고 판단했다. 결과물인 설계를 평가했을 때, B의 리스크가 충분히 완화되어 구현을 계속 했다."

리스크란 무엇인가?

책에서 이야기 하는 리스크의 정의는 "인지된 실패 확률*인지된 영향"이라고 정의 한다. 즉, 인지되지 않은 실패 혹률을 리스크로 판단할 수 없고, 실패로 인한 소프트웨어 프로젝트로의 영향도 파악할 수 없다면 리스크는 확인할 수 없는 것이다.

리스크의 구분은 크게 엔지니어링 및 프로젝트 관리 리스크로 나눈다. 일반적으로 엔지니어링 리스크는 제품의 분석, 설계 및 구현과 관련된 사항이고, 프로젝트 관리 리스크는 일정, 작업 순서, 팀 규모 등과 관련된 것들이다. 여기서 말하는 리스크는 엔지니어링 리스크와 관련되고 이를 해결하기 위한 엔지니러링 테크닉을 적용하는 것이 일반적이다.

리스크의 식별의 경우는 요구 사항에서 하는 것이 일반적이다. [2]에서 설명한 것과 같이 소프트웨어의 요구 사항에서 아키텍처적으로 중요한 요구 사항(Acrhitectural Significant Requirement, ASR)을 추출과 연결 시켜 보면, 추출된 요구 사항(기능적 그리고 비기능적 요구사항/품질 속성)에서 중요한 것을 찾는 것이 기존 방법과 다르게 리스크라는 관점에 중점에 두고 선정하는 것이 차이일 수 있다. 여기서 가장 달성하기 어려운 것을 찾는 것이 방법이라고 할 수있다.

개발하는 소프트웨어의 도메인에 따라 주로 발생하는 원형적 리스크(Prototypical Risk)도 있다. 예로는 아래와 같은 것들이 있다.

적용 테크닉

리스크를 인식하고 나면 리스크를 줄일 수 있을 것으로 예상 되는 테크닉(Techique)을 적용할 수 있다. 조지 페어뱅크스는 기존에 방식에서 지혜를 얻고 있다. 소프트웨어 아키텍처 설계에서 사용되는 전술(Tactics)[3] 혹은 패턴(Pattern)을 예로 들고 있다.

이와 같은 테크닉은 수 없이 많을 수 있다. 하지만, 시간과 돈을 낭비하지 않으려면 우선 순위가 지정된 리스크 목록을 가장 잘 줄이는 테크닉을 선택해야 한다. 즉, 최적화 문제로 생각하고 접근해야 한다. 이러하듯, 엔지니어링 리스크를 완전히 제거할 수 없는 이유는 주로 프로젝트 관리 리스크인 비엔지니러링 리스크와 균형르 이루어야 하기 때문이라고 책[1]에서는 이야기한다.

이와 같은 제약 뿐 아니라 적용할 테크닉의 선택을 위해서 문제의 종류(답을 찾는 문제/증명 문제), 모델의 종류(분석 모델 및 유추 모델)에 따라 다르다고 한다. 그리고, 설계를 바라 보는 관점이라고 할 수 있는 뷰타입(Viewtype)의 경우는 리스크와 테크닉의 쌍(Pair)에 효과를 다르게 하기 때문에 어떤 것이 적절한지 매칭(matching)을 고려해야 한다고 이야기 한다.

언제 멈추는가?

소프트웨어 아키텍처를 설계에는 중요한 두가지 질문은 "어떤 테크닉을 사용하는가?" 그리고 "얼마나 설계와 아키텍처를 수행하는가?"라고 할 수 있다. 리스크 주도 설계에서는 아주 단순히 답한다면 "충분히 리스크가 줄어 들 때까지 설계한다"가 답일 수 있다.

이를 위해서는 설계에 들이는 노력은 "리스크에 상응해야 한다"라고 한다. 저자는 아버지의 집앞에 우편함을 만드는 이야기를 하면서 단순하게 땅을 파고 우편함을 묻기만 하면 될 일을 위해서 측량을 한다거나와 같은 높은 건물 건축에서 사용되복잡한 설계나 리스크를 측정하는 테크닉을 적용할 필요가 없다는 것이다.

불완전해 보일 수 있지만, 리스크 모델에서는 리스크가 인식되는 영역만 설계한다는 부분과 리스크 평가가 주관적인 평가라는 부분 또한 언급한다. 이 부분은 단점일 수 있지만, 여전히 장점이기도 하다. 

계획된 설계와 진화적 설계

책[1]에서는 소프트웨어 개발에 사용되는 설계 접근 방식을 계획된 설계(Planned design)과 진화적 설계(Evolutionary design)으로 나눈다. 리스크 주도 설계는 이 두가지 설계 방식에 모두 적용 가능하다고 책에서는 주장한다.

진화적 설계의 경우, 주로 애자일 소프트웨어 개발 방식에서 사용하는 방식이다. 시스템이 구현됨에 따라 설계가 확장되기 때문에 지협적이고 파편화된 설계 결정이 여러 문제를 발생 시킨다. 이러한 단점을 해결하는 방법으로 리펙터링(Refactoring), 테스트 주도 설계(Test drivn design), 지속적인 통합(Continous integration)이 제안되어 채영되고 있다. 여전히 아키텍처적 입장에서는 좋은 지침에 제공되고 있지 않다고 지적하고 있다.

계획된 설계는 진화적 설계의 반대쪽 끝에 있다고 설명하며, 실재 구현 이전에 설계를 자세하게 작성하는 것이다. 하지만, 이는 지나친 선행 설계(Big Design Up Front BDUF)라고 비판을 받는다. 앞에서도 이야기 한 저자의 아버지 우편함에 대한 예가 주요 내용이라고 볼 수 있다.

위의 두 가지는 양쪽 극단이다. 마치 스펙트럼 같은 것일 수 있다. 이 중간에는 최소 계획된 설계(Minimal planned design) 또는 작은 선행 설계(Little Design Up Front LDUF)가 있다. 

이러한 접근 방법들은 서로 다른 지지자들이 있다. 또한 책에서는 만병통치약이 없듯이 다른 시스템에서는 다른 방법이 적절하다고 이야기 한다. 또한 둘은 다르고, 장점 또한 다르다. 이케텍처 설계를 한다는 것은 장기적인 관점을 가지고 시스템 전체의 속성을 보장하는 장점을 가진다. 진화적 설계는 앞에서 살펴 보았듯이 리펙터링, TDD 그리고 지속적 통합(CI)의 장점을 활용할 수 있다.

프로세스에 적용하기

리스크 주도 소프트웨어 설계를 여러 프로세스에 적용하기 위해서 몇가지 프로세스의 특징을 우선 아래와 같이 정리하고 있다.

우선 애자일 개발 프로세서인 eXtream Programming(XP)에서는 일반적으로 설계 작업이 없지만 반복 제로(Iteration zero)를 두고 설계 작업을 할 수 있다. 이렇게 반복적인 작업에서 리스크 주도 기반 접근법은 각 단계에서 필요한 만큼 설계 작업을 진행할 수 있다.

대표적인 애자일 프로세스인 스크럼은 기능 중심적 접근 방법으로 백로그에 구현할 기능을 관리한다. 여기에도 리스크 주도 접근법을 적용할 수 있다. 일반적인 기능 백로그는 제품 책임자(Product Owner)가 담당한다. 재품 책임자는 엔지니러링 리스크를 파악하기 어렵다. 대신 소프트웨어 팀이 리스크를 파악하고 이를 시스템의 테스트 가능한 기능으로 만들어 백로그에 넣을 수 있다. 이는 각 반복이 끝날 때 회고(Reflection/Retrospective)의 결과로 도출될 수 있다. 제품 책임자는 백로그 중에서 우선 순위에 따라 각 단계에 수행할 내용을 결정할 수 있다.

정리해보면...

리스크 주도 설계 접근 방식의 주요 내용은 설계에 많은 비용이 들기 때문에 리스크를 찾아 내고 이에 적절한 테크닉을 필요한 만큼 반복적으로 적용한다는 것이다. 이는 현재 소프트웨어 개발에서 적용되고 있는 양극단의 소프트웨어 개발 방법에서 모두 적용할 수 있다고 책에서는 주장하고 있다.

특히, 애자일 혹은 반복적 개발에서 알 수 있는 주요한 내용 중 하나가 설계가 항상 개발 프로세스의 앞부분에서만 진행되어야 하는 것은 아니라는 점이다. 후반부에 설계를 하게 되면설계를 변경하기 어려운 부분도 있을 수 있으나 구현하려고 하는 소프트웨어를 초기에는 잘 알지 못하는 문제점도 있다는 것을 책에서는 지적하고 있다. 소프트웨어 개발이 지식을 얻어 가는 과정이라면, 이를 이를 소프트웨어 설계 및 아키텍처링에 적용하는 방법으로서 리스크 주도 접근 방식의 장점과 적용하는 방법에 대해서도 흥미로운 재안을 하고있다.

참고 도서

[1] George Fairbanks, "Just Enough Software Architecture: A Risk-Driven Approach," 2010

[2] "Software Architecture: 어떻게 설계 할 것인가?," https://technical-leader.tistory.com/35

[3] 렌 베스 , 폴 클레멘츠 , 릭 캐즈먼, "소프트웨어 아키텍처 이론과 실제, 개정판 3판" 2015년, 에이콘출판

[4] Design Pattern 배우기, https://technical-leader.tistory.com/7?category=1015396 

애니 듀크의 "결정: 흔들리지 않고 마음먹은 대로", 이 책은 포커에서 돈을 거는 베팅(betting)이라는 표현을 빌어 결정(decision)에 대해 설명한다. 저자는 우리의 삶을 좌우하는 요인이 두가지라고 이야기 한다. 그것은 의사 결정의 질과 운이다. 둘의 차이점을 알고 결정에 돈을 거는 것 즉, 베팅하듯 사고하는 것이라고 이야기 한다. 처음에는 와닿지 않을 수 있지만 책을 읽다 보면 이것이 다구나 라고 이해할 수 있을 것이다.

이 책은 예측에서 많이 이야기 하는 야구 경기를 예로 시작한다. 결과적으로는 패한 경기의 감독의 이야기를 하면서 그가 결정한 투수 교체에 대해서 그 결과로 판단하는 이야기를 가장 처음 한다. 그녀는 자신의 포커 커리어에서 경험 많은 선수들에게 배운 결과로 판단하는 것이 얼마나 위험한지 이야기 한다. 그녀는 포커 경기를 하면서 단기적으로 몇번의 패가 좋지 않았다는 이유만으로 전략을 바꾸고 싶은 충동이 들더라도 포커 선배들은 꿋꿋이 그것을 이겨내야 한다고 조언했다.

그녀는 포커에는 불확실성이 존재하기 때문에 결정에 대해 가장 빠르게 배울 수 있는 의외의 장소라고 말한다. 저자는 포커에서 성공하려면 타고난 재능보다, 본인의 의도대로실행하는 방법을 찾는 것이 더 중요하다고 이야기 한다. 흔한 의사결정 함정을 피하고 이성적으로 결과로 부터 교훈을 얻고, 의사결정 과정에서 최대한 감정을 배제하며 전략을 실행해야 한다고 이야기 한다. 이것은 우리가 다른 의사 결정을 할 때에도 마찬가지이다.

의사 결정을 할 때 함정은 여러 곳에 도사리고 있다. 저자는 자신이 다 알고 있다는 위험한 착각을 버려야 한다고 한다. 쉬운 예로 동전을 던져서 나오는 확률은 어떠한가? 50:50이라고 이야기 할 것인가? 이것은 이론적이지만, 우리가 던지려고 하는 동전은 실재로 그 확률을 가지고 있을까? 그러므로, 누군가 아무 동전을 던지고 확률을 묻는다면, 우리는 '확실하지 않다.'라고 이야기해야 맞을 것이다.

우리가 이러한 불확실성을 기꺼이 받아들일 때 더 나은 의사결정자가 될 수 있는 까닭은 여러가지가 있는데 그 중 두가지 있다고 저자는 말한다. 첫 번째는 '확실하지 않다'는 그저 이 세상을 좀 더 정확히 묘사한 말일 뿐이기 때문이다. 두 번째는 확실하지 않다는 걸 받아들이면 흑백논리의 함정에 빠질 가능성이 줄어들기 때문이다.

그리고, 이와 같은 불확실성은 생각보다 자주 발생한는 이변도 포함하고 있다. 예를 들어 선거에서 어떤 후보가 60대 40이나 70대 30의 승률이 전망된다고 해보자. 저자는 이 후보가 질 가능성이 얼마나 높은지(물론 그 반대의 경우도) 뼛속 깊이 알고 있다. 즉, 60%로 이긴다고 예상된다는 이야기는 40%의 확률로 진다는 뜻이라는 것이다. 저자는 이러한 불확실성의에 대해 알고, 틀림에 대해서 다시 정의하고, 자산의 추측이 자원 배분마저 좌우한다는 걸 인정해야 한다고 주장한다.

우리는 생존에 필요한 기술의 경우 1형 오류(긍정 오류)를 저질러 치러야 하는 대가는 2형 오류(부정 오류)의 대가보다 덜했다. 달리 말해, 나중에 후회하는 것보다는 미리 조심하는게 낫다는 것이다. 우리는 직접적으로 경험하는 것들, 특히 우리 목숨이 달린 경우에는 믿음에 관한 대단한 의심을 발동시키지 않았다. 우리는 스스로를 편협하지 않고 새로운 정보에 따라 믿음을 얼마든지 바꿀 수 있는 사람이라고 생각하지만 실재로는 그 반대라는 것이다. 우리는 '새로운 정보에 걸맞게 믿음을 바꾸기'는 커녕 그 정보를 '우리의 믿음에 맞추어 해석'하는 것이다.

그렇다면, 우리가 의사결정을 내릴 때 어떻게 하는 것이 좋을까? 우리의 믿음에 있어서 단순히 자신이 있는지 없는지가 아니라 얼마나 자신이 있는지 생각하는것이 바람직 할 것이다. 이를 색으로 표현한다면 흰색 혹은 검은색 이라기 보다는 중간의 어디인가 있는 회색이 될 것이다.

결정을 하는데 학습은 어떤 역할을 할까? 의사 결정에 대한 실천을 해야 하는 시간에 가까운 피드백이 많이 발생할 때 학습이 일어난다고 한다. 그렇다면, 포커 게임은 아주 이상적인 학습 환경이 될 것이라고 저자는 이야기 한다. 베팅을 하고, 상대로 부터 즉각적인 반응을 얻고, 그 판에서 이기거나 진다. 이야기한 것과 같이 결정에 대한 피드백이 즉각적으로 일어난다.

하지만, 결과를 통해 얻을 수 있는 피드백은 성공과 실패 뿐일 경우가 많다. 그러므로, 그 뒤에 숨어 있는 내용을 다 알 수 없다. 이유는 결과물에서 무엇이 우리의 잘못이고 무엇이 아닌지 알기 쉽지 않다. 앞에서도 이야기했 듯이 결과물의 질에서부터 되짚어가 믿음이나 의사결정의 질을 판가름할 수 없기 때문이다. 달리 말하면, 불확실성이 개입되어 있어 결과가 실력 때문인지 운 때문인지 모르기 때문에 학습속도를 늦추기 때문이라고도 할 수 있다. 그렇다면, 결과보다는 과정에 대해 피드백을 받아야 한다고 볼 수 있다.

그렇다면, 결정을 하기 위해서 우리가 선택지를 만들어 놓고 결정을 내릴 때, 중간값 없이 옳고 그름으로 나눠어야 하는가? 저자는 아니라고 한다. 왜냐하면, 흑백논리가 의도적 합리화와 자기위주편향 모두를 촉진시키기 때문이라고 한다.
이와 다르게 포커에서 베팅하듯 생각해면 대안적인 가설들, 자기위추편향이라는 경로와 반대되는 결론을 뒷받침하는 이유들을 열린 마음으로 탐색할 수 있다고 이야기 한다. 반대되는 생각을 더 자주, 진지하게 탐색하면 진실에 더 가까이 갈 수 있다고 이야기 한다.

또한 같은 목표로 모인 다양한 사람들의 시너지를 얻는 것에 대해서도 이야기 한다. 이는 특정 시각을 일방적/의도적으로 합리화 시도, 편향을 증폭하고, 자신의 믿음을 지키게 만들고, 의사 결정 과정을 왜곡, 집단 순응 사고하게 하는 확증적 사고에서 벗어나게 한다고 한다. 대신에 대안적 시각/가설을 공평하게 개방적으로 고려하고 객관성을 장려한고 편향에 맞서는 논쟁을 받아들이는 탐색적 사고를 돕는다고 주장한다.

그렇다고, 팀을 만든다고 그냥 얻어 지는 것이 아니고, "진실추구 규율의 청사진"을 가져야 한다고 이야기 한다. 이는 다음과 같은 규율을 가져야 한다고 이야기 한다.
1. 그룹 내 진실 추구와 객관성, 열린 마음을 보상하며 정확성에 집중
2. 자신의 의견이 나 주장에 대해 설명할 책임(사전에 고지되어야함)
3. 다양한 생각에 대한 개방성
다시 말해 진실을 추구 하려는 공동의 목표를 가진 그룹의 규율은 개인의 편향에 도전하는 다양한 시각을 독려하고 권장해야 한다고 말한다.

팀이 토론을 할 때, 진 게임에 대해서 보다는 승리한 게임에 대해 이야기하는 것(이기기까지의 과정에서 한 실수를 찾아내야 할지언정)이 덜 고통스럽다. 그렇기 때문에 이러한 새로운 습관을 훈련할 때에 도움이 된다. 애자일에서 회고할 때, 잘하고 있는 부분에 대해서 이야기 하는 것도 이런 맥락이지 않을까?

결정을 할 때, 책임 연습이란 책임 연습이란 우리의 행동이나 믿음에 대해 다른 사람에게 해명할 용의나 의무라고 한다. 투자를 할 때, 손실 한계를 정해 놓고 자기 위주 편향을 피하기 위한 방법도 이와 유사하다고 할 수 있다.를 말한다. 내기는 일종의 책임 연습이다. 계속 이기고 있을 때도 마찬가지이지만, 지고 있는 순간에는 내가 운이 나빠서인지, 실력때문인지 알기 힘들기 때문에 정신을 차리고 우선 멈춰야 한다.

책의 5장에 새로운 결정 기준을 제시하는 사람들들의 이야기를 한다.

첫 번째가 머튼의 공유 주의(공산주의와 혼동하지 말기를)라는 규범을 이야기 하는데, 이는 그룹 내에서 데이터를 공동으로 소유한다는 뜻이다. 공유를 원칙으로 삼아야만 완전하고 열린 의사소통이 가능하다고 주장한다.
데이터와 정보를 공유하는 것은 진실 추구 규범의 다른 요소들처럼 먼저 합의를 필요로 한다.
그리고, 조금이라도 관련될 수 있는 정보는 뭐든 추가하는 식으로 만전을 기해야 한다. 평가할 때에도 필요에 따라 세부적인 내용까지 뽑아내기 위해 서로에게 질문을 던져야 한다.

두 번째의 경우는, 여러분이 싫어하는 그 사람이 때때로 옳은 말도 한다는 것을 인정하라 것이다. 우리는 좋은 아이디어 또는 나쁜 아이디어만 가진 사람은 없다는 사실을 자주 잊곤 한다. 예를 들어 정치판이 양극화되어 있는 상황에서도 진보주의자들은 보수주의 언론을 더 읽고, 보수주의자들 역시 반대 접근도 해야 한다고 이야기 한다.

세 번째는 이해관계가 시야를 흐리지 않도록 주의하라고 이야기 하면서, 무사무욕주의(Disinterestedness 사심이 없음)가 중요하다고 설명한다.

네 번째는 여러 곳에서 이야기 하고 있는 '악마의 변호인'이다. 악마의 변호인은 확실해 보이는 내용에도 반대하는 사람이라고 간단히 말할 수 있따. 이 방법으로 불확실성을 받아들이고 이것을 소통하는 방식에 녹여넣으면 '대립만 일삼는 반대'는 눈 녹듯 사라진다고 이야기 한다. 애초에 '확실하지 않다'는 것 부터 시작하기 때문이라고 말한다.

마지막 6장에서 지금까지 이야기한 결정과 관련된 몇가지 도구에 대해서 이야기 하고 정리한다.

모든 후회하기에 가장 좋은 때는 결정을 내리기 전이다. 이렇게 할 수 있는 도구는 '미래의 자신이 이 결정에 대해 어떻게 생각할 것인가', 아니면 '과거의 자신이 이런 결정을 내렸다면 오늘 우리가 그것에 대해 어떻게 생각할 것인가'를 상상해 보는 것으로 가능하다.

10-10-10 법칙이 좀 더 상세한 방법이다. 여러분의 선택은 10분 후에 어떤 결과를 가져올 것인가? 10개월 후에는? 10년 후에는? 이 일련의 질문으니 책임 연습 대화(진실 추구 그룹에서도 장려한다)가 포함된 정신적 시간여행을 유발한다고 한다.

앞에서도 이야기 했지만, 일단 멈추어야 악순환을 피할 수 있다고 이야기 한다. 저자는 틸트(Tilt)에 대해서 이야기 하는데 나쁜 결과는 감정에 영향을 미칠 수 있고, 이것이 감정적이고 비합리적인 의사결정을 내리게 하며, 이는 더 많은 나쁜 결과를 가져와 향후 계속해서 의사결정 능력에 부정적인 영향을 미칠 수 있다고 이야기 한다.

또하나의 도구로 백캐스팅(backcasting)과 사전부검(pre-morterm)을 이야기 한다. 백캐스팅은 어떤 일에 성공했다고 가정하고 '나는 왜 성공하였는가?'라고 질문해보는 것이다. 즉, 미래의 지도를 그리기 위해 목표에서부터 거꾸로 돌아오는 것을 말한다. 사전부검은 백캐스팅과 상호보완적이다. 사전부검은 부정적인 미래를 상상한다. 긍정적인 공간과 부정적인 공간 모두 갖지 못하면 완성된 그림이라고 하기 어렵다.

필립 테틀록과 댄가드너의 슈퍼 예측은 다른 사람들 보다 예측을 잘 하는 사람들에 대한 이야기이다. 실재로 이런 사람들이 있는가? 있다면 그들은 어떻게 다른가에 대해 이야기 한다.

나도 마찬가지였지만, 이책을 스터디 그룹과 읽기 시작할 때에는 예측에 대해서는 회의적이었다. 즉, 예측이란 틀릴 수 밖에 없다고 생각하였다. 이 책은 이에 대해서 내가 어떤 부분을 제대로 알고 있고, 어떤 부분을 잘 못 생각하고 있었는지 알려 주었다.

저자는 자신을 '낙관적 회의주의자'라고 불러도 좋다고 한다. 이는 예측은 허구라고 하는 사람들과 예측이 가능하다고 하는 사람들 가운데 어디 즈음이라는 이야기일 수 있다.

저자가 연구를 책의 서두에 먼저 이야기 하는 중요한 결론 2가지는 첫째, 예지력은 실제로 있다는 것과 둘 째는 슈퍼예측가들의 성적을 그렇게 좋게 만든 요인이 있다는 사실이다.

이에 대해서 믿고 믿지 않고는 읽는 사람들의 몫일 수도 있지만, 내가 알고 있던 것과의 차이는 생각이나 예측이라는 것에 대한 틀과 그 내용을 받아 들이는 방법도 차이가 많이 난다. 또한 책에서는 이와 관련된 여러가지 내용을 먼저 이야기 한다.

'생각에 관한 생각' 그리고 노벨상 수상자로 유명한 대니얼 카너먼은 사람이 생각하는 방식을 시스템 1과 시스템 2을 나누어 설명한다. 시스템 1은 증거가 많지 않은 상황에서 빨리 결론을 내리도록 만들어진 장치이고, 시스템 2는 우리가 잘 아는 의식적인 사고 영역이라고 한다. 시스템 1에서 일어나는 과정으로 몇십 분의 1초 사이에 자동적으로 빠르고 완벽하게 이루어진다. 그림자를 본다. 털컥! 걸음아 날 살려라 하며 뛴다. 이것이 시스템 1이다. 시스템 2는 우리가 집중하기로 선택한 모든 것으로 구성된다. 

일반적으로 시스템 1이 먼저 튀어 나온다. 시스템 1은 배경에서 빠른 속도로 꾸준히 달리고 있다. 하지만, 시스템 2는 그 답을 심문하는 일을 맡는다.  내 답에 대해 누군가 꼬치꼬치 따지고 들어와도 내가 견뎌낼 수 있을까? 증거를 댈 수 있을까?를 생각하는 것이 시스템 2라고 한다. 이 시스템 2가 중요할 수 있다. 하지만 시스템 1은 이 보다 먼저 동작한다. 무언가에 대해서 의심을 하고 시스템 2를 지속적으로 동작 시켜 시스템 1에 이러한 보정이 포함되도록 훈련해야 한다.

저자는 예측과 관련해서 2가지 부류로 나누어 설명한다. 하나는 고슴도치형 하나는 여우형이다. 고슴도치형은 빅 아이디어 전문가로 예측을 할 때 대담하게 90~100%로 예측한다. 이와는 다르게 여우형은 절충적 전문가로 어떤 질문에 대해 60~70%로 예측한다. 각각의 예측에 대해 이 후 평가를 해보면 대부분의 측면에서 이기는 쪽은 늘 여우형이다. 하지만, 여우형은 언론에서 그닥 좋은 대우를 받지 못한다. 우선 여우는 자신감도 없어 보인다. 무엇이 '확실하다'거나 '불가능하다'라고 말하지 않는다. 그리고 '아마'라는 표현을 즐겨 사용한다. 그들의 말은 복잡할 뿐만 아니라 거기엔 '그러나'와 '한편' 같은 어정쩡한 단어가 많이 섞인다. 그러다 보니, 이런 유형의 사람들이 TV에 나온다면 변덕스럽고 줏대가 없으며 불명확하다고 할 것이다.

저자는 예측을 하는 테크닉으로 페르마이징, 외부 관점, 내부관점, 그리고 관점 통합하기를 이야기 한다.

페르마이징은 쉽게 말하면 문제를 좀 더 작은 문제로 나누어 어림짐작하기를 통해 답을 구하는 과정이다. 예를 들어 '시카고에 피아노 조율사가 몇명인가?'라는 질문에 답하기 위해서는 시카고의 대략적인 인구수, 그리고 평균 가족 구성 인원, 가구당 피아노 보유율, 그리고 대략적인 피아노 조율 빈도를 추정하여 총 필요한 조율량을 추측할 수 있다. 그런 후, 피아노 조율사의 한대 조율 시간과 처리 가능한 업뮤량의 추정을 통해서 필요로 하는 대략적인 피아노 조율사의 수를 예측하는 것이다. 이러한 방식으로 주어진 문제에 대해서 예측을 할 수 있다.

책에서는 누구나 따라 할 수 있는 수퍼 예측가들이 예측에 접근하는 방식에 대해 설명한다. 간단히 말하면 외부 관점에 내부관점으로 조정하여 종합적으로 예측을 하는 것이라고 한다. 이를 위해서 문제를 성분에 따라 풀어헤친다. 아는 것과 모르는 것을 철저히 구분하고, 가정을 조사하는 것이다. 우선 외부 관점의 측면, 즉 비교론적인 관점에서 보면서, 문제의 고유성보다는 그것을 더 넓은 범위의 특수 사례로 취급하여 예측을 수행한다. 그리고, 내부 관점, 즉 문제의 고유성을 부각시킨다. 나의 견해와 다른 사람의 견해의 유사성과 차이점을 확인한다. 이 것은 대중의 지혜를 뽑아내는 여러가지 방법에 주목해야 한다. 책에서는 잠자리의 눈에 비유를 하며, 이 모든 다양한 견해를 예리한 단일 시야로 통합하는 과정이 필요하다고 이야기한다. 

마지막으로, 아주 세분화된 확률을 사용하여 판단을 가능한 정확하게 표현한다. 책에서는 예측은 정반합의 과정이라고 말하면서 활용 가능한 정보의 변화에 맞춰 계속 업데이트 해야하는 한시적인 판단이라고 말한다. 저자는 외부 관점과 내부 관점을 종합하는 것이 끝이 아니라, 좋은 출발일 뿐이라 한다. 마치, 우리가 애자일 프로세스를 통해서 업무를 수행하듯 반복적(Iterative)하게 수퍼 예측가는 자신만의 견해를 도출하기 위해 종합할 수 있는 다른 견해들을 끊임없이 찾아 필요에 따라 예측을 수정한다. 그렇기 때문에, 수퍼 에측가들은 신념을 사수해야 할 보물이라기 보다는 검증해야 하는 가설로 다룬다.

영화 '빅 쇼트'는 리먼 브라더스 파산으로 시작했던 경제 위기를 배경으로 한 영화이다. 여기서도 헷지펀드의 퀀트(Quant 정량적 분석 Quantative Analysis을 수행하는 사람)가 나온다. 책에서는 이렇듯 수학을 잘하는 사람들이 더 예측을 잘하는가에 대한 질문도 던진다. 저자는 일부러 예측에는 수학이 그리 필요하지 않다고 이야기 한다. 그래도 예측에 대해서 간단히 수학적인 의미는 파악해 보자. 예측에 대한 확률은 크게 나누면 3가지 설정이 있다고 할 수 있다. 바로, 멘탈 디이얼을 '얼아난다' '일어나지 않는다' 그리고 '아마도'로 설정하는 것`이다. 이러한 언어로 표현되는 어떤 예측에 대해서 틀렸다고 단정해서는 안된다. 예를 들어 '어떤 일이 일어날 확률이 74%'라는 말은 '그렇지 않을 확률이 26%'라는 의미도 되기 때문이다. 이렇게 예측하는 사람들은 확률을 말하라고 할 때 50%를 훨씬 더 많이 사용한다. 그 때 50%는 '아마도'를 의미한다. 50%를 너무 자주 사용하는 사람의 예측은 정확하지 않다고 봐도 큰 무리가 없다. 

저자는 슈퍼 예측에 필요한 개인적인 역량으로서 성장 마인드 세트(Growth Mindset)을 이야기 한다. 심리학자인 캐롤 드웩은 '성장 마인드세트를 가진 사람은 자신의 능력을 노력의 산물'이라고 하고 그 노력 만큼 '성장'시킬 수 있다고 한다.
대부분의 사람들은 소위 '고정적 마인드세트(Fixed Mindset)'를 가지고 있다. 고정적 마인드세트를 가진 사람은 생긴대로 사는 것이라고 믿는다. 그들은 능력은 만들어지거나 개발되는 것이 아니라 드러나는 것일 뿐이라고 주장한다.
이것을 예측과 연결해서 생각해 보면, 성장 마인드 세트를 가진 예측가들은 새로운 아이디어를 끊임없이 수집했고 필요하면 서슴지 않고 생각을 바꾼다. 그들은 이렇게 하는데 망설치지 않고, 실수를 당당히 인정하고 새로운 생각을 받아들이는 것을 자랑스러게 생각한다. 즉, 실패는 실수를 확인하고 새로운 대안을 찾아내 다시 시도하는 학습의 기회였다.  이렇게하면, 시행 횟수가 많아지면 착오가 줄고 기술은 세련되어진다. 어떤 일에 능숙해 지는 비결은 비행기나 아주 어려운 기술을 배우는데 필요한 것과 마찬가지로 실제로 그일을 하면서 보내는 시간의 양이 결정한다.  그러나 무작정 하는 연습으로 항상 실력이 향상되는 것은 아니다. 연습을 해도 조심할 부분을 알고 정보를 바탕으로 어떤 연습이 가장 좋은 것인지 알고 연습해야 한다. 이 밖에도 효율적인 연습은 분명하고도 시의적절한 피드백과 함께 해야 한다. 실패를 통해 배우려면 언제 실패하는지 알아야 한다. 실패했다는 것을 알면 무엇이 잘못되었는지 생각하고 수정하여 다시 시도해야 하는 것이다.

팀으로서의 슈퍼 예측 집단은 현명할 수도 있고, 무모할수도 있으며, 둘다일수도 있다. 즉, 집단은 어떤 구성원들 이더라도 하기 나름이다라는 것이다. 저자들이 발견한 잘 동작하는 슈퍼팀은 극단적인 집단사고와 온라인 논쟁의 폐해를 피했다. 무엇보다 다음과 같은 규칙을 잘 지켰다고 한다. 

• 서로에 대한 예의를 잃지 않으면서도
• 상대방에 대해 비판을 제기하고 무지를 인정하고 
• 도움을 요청하는 분위기를 조성하는 그들만의 문화가 큰 위력을 발휘했다. 

나도 다음과 같이 "팀은 단순히 부분의 합이 아니다. 집단이 집합적으로 생각하는 방법은 집단 그 자체의 발현적(emergent) 속성으로, 각 멤버 내부의 사고 과정일뿐 아니라, 멤버들간의 의사소통 패턴의 속성이다."에 동의한다.


그렇다면, 슈퍼 예측가들의 리더는 어떠해야 할까? 책에서는 히틀러가 지배하던 시대의 유명한 장군인 헬무트 폰 몰트케 이야기를 한다. 암울했던 시기의 인물이기 때문에 그 사람에게서 무엇을 배울 것이 있는가 의심할 수 있다. 책의 저자도 그 부분에 대해서 조심 스러운이 있다. 몰트케의 유산이라 이르면서 그가 한말을 인용한다. "전쟁에서는 모든 것이 불확실하다.", "무엇보다 중요한 것은 자신의 계획을 무조건 신뢰해서는 안 된다는 점이었다.", "적의 주력 부대와 처음 마주치는 순간 효력이 계속 확실하게 유지되는 작전은 없다."와 같은 말이다. 여기서 반전은 나도 계속 좋아하는 인용인 "계획대로 승리한 전투는 없지만,계획없이 승리한 전투도 없다"를 이야기한 아이젠하워가 독일의 군 통수권자보다 몰트케의 철학을 더 확실하게 이해하고 있었다고 저자는 이야기 한다. 이러한 철학도 슈퍼 예측팀을 이끄는 리더들 즉, 여러 슈퍼 예측가들의 종합한다는 입장에서는 이와 같이 불확실한 부분을 이야기하는 것일 수 있다는 것이다.

저자는 "결정, 흔들리지 않고 마음먹은 대로"의 애니 듀크가 말하는 특이한 형태의 겸손에 대해서도 이야기 한다. 프로 포커 플레이어 였던 그녀는 자신감 뒤에는 늘 위험이 도사리고 있다는 것을 잘 알고 있었다. 그녀는 게임에 임했을 때 겸손은 적을 앞에 두었을 때의 겸손과는 전혀 다르다고 이야기 한다. 포커 테이블에 앉으면 누구와도 해볼 만하다는 자신감을 갖지만, 그렇다고 해서 내가 게임의 원리를 완전히 터득하고 있다는 말은 아니라고 이야기 한다.

저자는 슈퍼 예측가가 되기 위해 추가적으로 몇가지 알아 두어야 할 사항에 대해서도 이야기한다.
첫 번째는 대니얼 카너먼의 시스템 2의 교정을 시스템 1으로 가져오는 것이다. 사람들은 원래 빠르고 무의식적인 시스템 1이 만드는 실수를 찾아 내기 위해 의식적인 시스템 2를 반성적으로 사용할 수 있다. 예측을 아주 잘하는 사람들도 어쩔 수 없이 편하고 직관적인 사고 모드에 빠지고마는 것이다. 시스템 2를 소홀히 한 탓이다. 일부 슈퍼 예측가들은 시스템 2의 교정에 아주 능숙하며, 가령 물러서서 외부 관점을 받아들이는 행동이 아예 습관화되어 있는 것으로 보인다고 한다. 사실 이런 과정은 아예 시스템1의 일부로 편입되어 있는 경우도 있다고 한다. 

그리고, 잘못된 이분법을 버리는 것이다. 나심 탈레브가 이야기 했던 블랙스완이라고 불린 사건이 있다. 실재로 검은색 백조들은 완전히 검은 색이 아니고, 회색이라고 한다. 흰색이라고 믿었기 때문에 회색을 검은색이라고 이야기 하는 것이다. 즉, 블랙 스완이라고 불리는 사건들은 그 조짐이 있었다는 것이다. 앞에서 이야기 했던 리먼 브라더스 파산의 경우도 빅 쇼트에서 이를 예측하고 확인하는 과정에서 보이듯이 갑작스럽게 발생한 것이 아니고 그 조짐이 시장에서 보이고 있었다는 것이다. 그렇기 때문에 빗나갈 예측에 대한 계획을 세울 필요가 있다. 앞에서 이야기한 아이젠하워의 명언과 같이 "계획은 아무 소용이 없다. 그래도 계획은 반드시 필요하다"를 다시 한번 생각해 보고 이에 대해 대비가 필요할 수 있다.

앞에서 이야기 했듯이 나도 예측에 대해서는 매우 부정적이었다. 복권에 대해서도 그렇게 생각하여 필요없는 것이라 생각했다. 하지만, 이 책은 이를 바라 보는 나의 자세를 바꾸는 계기가 되었다. 책에서 이야기 했듯이 예측이 가능한 좋은 질문을 선별하고 (10년후 예측 같은건 불가능하다.), 알수있는 부분과 알수 없는 부분으로 분해하여 가정을 검토 후 추측해 보자. 습관적으로 외부 관점에서 질문을 제기하자. 그리고 나서 내부 관점을 고려하자. 업데이트는 귀찮지만 장기적으로 유익하다. 잡음속에서 미묘한 신호를 골라내고, 자신의 은근한 희망이 스며들지 않도록 경계하자. 정반합, 잠자리의 눈을 가지고 모든 견해를 하나의 이미지로 만들자. 불확실성의 정도를 더욱 자세히 구분하자. 실패/성공 후에 반드시 회고를 하자. 성공에 대해 관신하면 안되고 실패로부터 교훈 찾자. 질문을 하고, 건설적인 대립하자. 직접 예측하고, 피드백을 통해 앞으로 잘 가는지 확인하자. 

기존의 연구자들은 센스메이킹을 조금씩 다르게 정의하고 있다. 센스메이킹이라는 용어를 처음 만들어낸 칼 웨익은 조직내에 진행되는 '여러 현상'을 '메이크 센스하게 하는 것(Making of sense)'이라고 하고, 워터맨(Waterman)에 의하면 '모르는 것을 구조화'하는 과정으로, 링과 랜즈(Ring and Rands) '개인들이 그들이 처한 환경에 대한 인지적 지도를 개발화는 과정'이라 정의한다. 경영측면에서의 센스메이킹은 '조직의 내/외부에서 진행되는 불확실하고 복잡한 상황을 명백하게 이해하게 하고 그 이해에 바탕을 둔 행동을 취하게 하는 인지 과정'으로 정의한다.
책[1]에서는 영화 본 아이덴티티에서 주인공의 상황자각력을 예로 들면서, 센스메이킹은 상황자각력이 모여서 이루어지는 것이라 하고 있다.

책에서는 센스메이킹 원칙을 5가지로 설명하고 있다. 

원칙 1 현재진행형(ongoing)은 상황에 의미를 부여하고 진행되는 상황을 보아야 한다는 것을 의미한다. 상황을 정지된 사진, 스냅샷으로 보는 것을 의미 하지 않고, 현재진행형(ongoing)인 현실(reality), 과거-현재-미래로 이어지는 맥락을 본다는 것을 의미한다.
원칙 2는 센스메이킹은 회고(retrospective)의 과정이라는 것이다. 회고를 통해 일어난 상황을 돌아 보며 질서(order)를 부여하고자 노력하는 것이다.
원칙 3은 주어진 상황을 이해하기 위해 정당화(justification)가 필요하다는 것이다. 사람들은 주어진 상황이 '합리적'으로 보이게끔(make situations rationally accountable)노력한다. 즉 '내가 경험하고 있는 사건'이 '말이 되는 사건'이라고 스스로를 설득시키고 그 사건의 발생 자체를 이해하려고 노력한다. 그 과정에서 필요한 것은 '정당화'이다.
원칙 4 추정(presumption)은 미루어 생각하여 결정하는 것을 의미한다. 현실을 해석(interpretation)하는 과정 우리가 가지고 있는 잘못된 추정들이 올바른 해석을 방해/제약하여 잘못된 결과를 가져올 수도 있다고 이야기 한다.
원칙 5은 100%의 정확성(accuracy)이 아니라 그럴듯함(plausibility)에 대한 것이다. 넓은 현실(wider reality: 실제 사건이 일어나는 현실세계를 말한다)'에 대한 이미지를 만들어 낸다. 이것은 '비교적 정확하다고 생각하는 현실'이다. 여기서는 '정확성 보다는 그럴듯함'을 추구한다는 것으로 '그럴듯한 추론(plausible reasoning)' 귀추법(Abductive reasoning)이라고 한다.
이 원칙들을 정리해 보면, 센스 메이킹이란 상황을 돌아 보면서 단편적으로 보지 않지만 가장 근접한 답을 찾는 것이고, 실패의 가능성은 당연히 존재하는 것을 인정한다. 실패의 경우, 재빠르게 궤도를 수정하여 파국을 모면하는 것으로 반복적(Iterative)으로 돌아보며(retrospective) 그럴듯한 결론(plausible conclusion)을 내고 행동(action)한다.

책에서는 센스메이킹을 다양한 사례를 들면서 설명한다. 맨 협곡의 참극, 임진왜란이 그 예이다. 특히, 임진왜란은 나심 탈레브의 '블랙 스완'에 해당한다고 설명한다. 챌린저 호 폭발 사건, 항공 모함, 탑건 프로그램에서의 사후 강평에 대해서도 이야기 한다. 특히, 항공 모함이나 사후 강평은 구성원 간의 상호작용 측면에서 매우 흥미로왔다.

기업에서 센스메이킹을 키우는 방법에 대해서도 제언을 하는데, 7가지 포인트를 이야기 한다.

1. '한군데에서의 정보에만 의존하지 마라'라고 이야기 한다. 
'신호와 소음' 작가인 네이트 실버의 표현에 따르면 혼합방식(hybrid approach)으로 정보를 모아 작성된다. 야구의 경우, 즉 통계자료만이 아닌 스카우트들이 선수를 직접만나고 작성한 리포트 등이 포함된 1차 자료와, 순전히 통계자료로만 구성된 2차 자료를 혼합해 사용하는 것이다. 이 부분은 TV 드라마 '스토브 리그'가 생각나는 부분이다.

2. 현장의 목소리를 들어라
디자인 싱킹으로 유명한 아이디오는 병원의 응급실 디자인을 진행할 때 공간의 동선 관련 질문을 위한 인터뷰에서 다양한 이해 관자자들과 했다. 하지만, 간과한 이해 관계자가 있었으니 바로 환자였다. 만일 '응급실에서의 환자의 경험'이라는 생생한 1차 자료가 없는 상태의 응급실 디자인은 중요한 사용자를 간과한 수준 이하의 디자인이 되었을 것이다.

3. 효율적인 센스메이킹을 위해서 조직 내에서만 통용되는 암호가 필요할 수도 있다.
웨익과 로버츠의 항공모함 연구에서 나오는 컬렉티브 마인드(Collective Mind)를 가진 조직에서는 구성원이 자신의 일을 하면서 자신의 일이 그 사회 시스템 내에서 어떤 역할을 하는 지 확실히 인지(representation)하고, 자신의 행동을 그 시스템의 일부로 연결할 수 있어야 한다고 지적한다.

4. 공감능력을 통한 팀워크를 키워라
여러 다른 책에서도 언급된 픽사의 브레인트러스트 회의는 영화 '토이 스토리' 제작 과정에서 자연스럽게 생겨난 후 사용되고 있다고 한다. 간단히 이야기 하면 여러 직원들을 한 방에 모아놓고 서로 솔직하게 의견을 애기하도록 장려하는 것이다. 모든 참가자는 공평한 기회를 갖되 경영진이 감독을 뜻을 뒤엎을 수는 없다. 이 때 발언자들은 계급을 내려 놓고 이야기 하며 스토리에 대한 이해를 전제로 어떤 모진 발언도 가능하지만, 감정적인 비난은 금지 한다. 이러한 부분은 사후강평(AAR)과 일맥 상통한다.

5. 회의나 사후강평 장소의 크기와 레이아웃도 중요하다.
상명하복의 조직에서 누가 리더의 심기를 거슬리는 보고를 하려하겠는가? 이런 경우 리더가 센스메이킹을 잘못하게 되면 해당 조직은 잘못된 방향으로 나아갈 확률이 크다. 그렇기 때문에, 수평적이고 자유로운 의사소통은 센스메이킹의 첫걸음이라고 이야기 한다. 이 부분은 구글의 아리스토텔레스 프로젝트에서 언급된 우수한 팀의 조건 중 가장 중요하다고 이야기된 심리적 안전과 연결된다. 즉, 내가 무슨 말을 해도 괜찮은 분위기가 형성이 되어야 한다. 

6. 반드시 '악마의 변호인'을 두라: 이스라엘의 대실수(Mehdal)
월드워 Z에서 좀비를 대비할 수 있었던 모사드의 10번째 사람이 있다. 9명이 같은 의견을 내더라도 1명은 반대 의견을 내는 시스템이라 할 수 있다. 이와 같은 악마의 변호인(Devil's Advocate)이 있다고 해서 그것이 모든 예상치 못한 참사를 미연에 방지하는 것은 절대 아니다. 조직이 갖고 있는 자원과 시간의 제약 때문에, 모든 위험 요소를 고려해 업무를 처리하거나 전략을 짜는 것은 현실적으로 불가능하다. 그러나 악마의 변호인이 제기한, '만에 하나 일어날 수 있는 사건'이 발생할 때, 그런 제도가 있는 조직과 없는 조직의 대처는 하늘과 땅 차이일 것이다.

7. 흩어져 있는 점들을 연결하라
결국 기업의 능력은 흩어진 점들을 연결하여 지식의 활용을 잘 하는 데 있다는 것인데 여기서의 지식은 꼭 조직 내의 지식 만을 의미하지는 않는다. 조직 외부에 존재하는 지식이나 자원의 활용도 기업에게는 매우 중요하다. MS의 QDOS 사례, 애플의 도시바 HDD건을 사례로 이야기 한다.

개인의 센스메이킹 높이기에 대해서는 다음과 같이 제언한다.

1. 꾸준히 신문 읽기
저자는 뉴스가 '현재의 세상이 어떻게 돌아가는지'를 아는데 가장 효율적인 수단이라고 주장한다. 하지만, 팩트와 주장과 의견을 구분해야 하고 꾸준히 많은 내용을 읽는 것이 중요하다고 한다.

2. 뱅뱅이론에서 벗어나기
저자는 뱅뱅이론을 자신이 위치하고 있는 진영의 논리에 파묻혀 놓치는 부분을 지적하는데 사용한다. 이를 극복하기 위해 사실 파악을 위해서는 여러 진영의 글을 읽는 것이 필요하다는 의견이다.

3. 100% 정확성(accuracy)보다 그럴듯함(plausibility 또는 probabilistically)을 쫓기
여기서는 '슈퍼 예측'에 나온 인간의 2가지 부류를 이야기 한다. 고슴도치형 인간은 모든 것을 하나의 렌즈로 보는 사람들, 즉 일원적인 사람들이라고, 반면 여우형 인간은 다원주의자이자 여러 개의 렌즈로 사물을 보는 사람들이라고 한다. 
예측에 관련해서는 이 신중파들은 성실하고, 셍사한 정보를 모았으며, 자기와 다른 시각에 대해 개방적이었고, 지속적으로 정보를 업데이트하는 노력을 보였고, 자신의 접근이 틀렸다고 생각하였을 때 방향을 바꾸는 것에 망설임이 없었다. 
즉, 그럴 가능성이 높은(probabilistically) 것에 배팅하는 사람들이었고 이야기 한다.

4. 페르마이징(fermizing)하기: 시카고 피아노 조율사 수
때로는 확률과 어림짐작 계산을 통한 분석능력도 필요하다고 이야기 한다. 시카고에 피아노 조율사를 예측하는 문제에 접근 하는 방법으로 문제를 좀 더 작은 문제로 나누어 어림짐작하기를 통해 답을 구하는 과정을 페르마이징이라고 한다.

5. 집단 지성을 적극적으로 활용하기
팀으로 일하는 것의 장점은 많은 이들이 알고 있다. 하지만 이를 위해 대인 관계 능력이나 감성 지능도 중요하다.

저자는 책을 마무리 하면서, 마크 트웨인의 이야기를 언급한다. '역사는 똑같이 되풀이 되지는 않지만, 그 라임은 맞는다(History Does Not Repeat Itself, But It does Rhyme).' 그러면서, 다른 기업의 사례연구를 통한 학습이나 벤치마킹이 의미있다고 주장한다.
또한 이러한 밴치마킹의 사례의 선정의 경우, 회사의 상황에 따라 선택하는 것을 제안한다. 즉, 중년 이상의 오래된 기업은 꾸준한 개선을 통해서 여전히 잘하고 있는 타 기업 사례가 훨씬 유용할 것이라고 주장하기도 한다

[1] 김양민, '불확실을 이기는 전략 : 센스메이킹'