10. ‘왜(why)?’ 질문 다섯 번 하기

<아마존 웨이>

마감시한의 압박을 받으며 일할 때는 종종, 문제나 기술 혹은 상황을 깊이 파고들고 진정으로 이해할 수 있는 충분한 시간이 없다는 조급한 기분이 든다. 지식 탐구와 지식 활용 사이에는 균형관계가 존재한다. 깊이 파고들 필요가 있을 때가 언제이고 추상적으로 다루거나 뭉뚱그리는 것이 유익할 때가 언제인지를 알려면, 무엇보다 경험이 필요하다. ‘왜?’ 질문 다섯 번 하기(Five Whys)는 말 그대로 왜냐고 묻는 질문을 다섯 차례 반복하는 기법이다. 아마존은 특정한 문제의 근원에 있는 인과관계를 깊이 탐구할 필요가 있을 때마다 그 기법을 사용했다. 그런데 왜 하필 다섯 번일까? 경험에서 볼 때 문제의 진짜 근원적인 원인을 확인하고 해결하기까지 일반적으로 다섯 번의 질문이 필요하기 때문이다. 지금부터 자세히 알아보자.

문제를 상세히 기술하라. 이것은 문제를 공식화하는 데에 도움이 될뿐더러, 팀 전체가 동일한 문제를 이해하고 그것에 초점을 맞추도록 하는 데도 유익하다.

그 문제가 왜 발생하는지를 묻고, 문제에 대한 설명 바로 아래에 그 질문에 대한 답을 적어보라.

당신의 대답이 문제의 근원적인 원인을 드러내지 못했다면, 또 다시 질문을 하고 그에 대한 답을 기록하라.

문제의 근원적인 원인이 밝혀졌다고 팀 전체가 합의할 때까지 두 번째와 세 번째 단계를 반복하라. 단, 다섯 번은 일반적인 경우이니 그것에 집착하지 말고 문제의 복잡성에 따라서 질문 횟수를 적절히 조절하라.

이제는 실질적인 예를 통해 다섯 번 질문하는 기법을 어떻게 사용할 수 있는지 알아보자. 어느 날 기술적인 장애가 발생했다고 가정하자. 먼저 문제를 정의해야 하는데, 가령 “토요일 저녁에 45분간 사이트가 다운돼 고객들이 서비스를 이용할 수 없었다.”는 식이다. 그 문제가 왜 발생했는지 스스로에게 물어보니 이런 대답이 나올지도 모르겠다. “다른 서비스로부터 전례가 없는 막대한 수요가 발생했다.”

그러나 당신을 포함해 팀 구성원 모두가, 이 대답은 서비스 중단에 대한 근원적인 원인을 알려주지 못한다고 생각할 수도 있다. 그래서 당신은 두 번째 질문을 하고 “우리 서비스가 종속된 서비스가 그런 수요를 처리하지 못했다.”는 답을 내놓는다.

이것은 세 번째 질문을 유발하고, “우리 서비스가 종속된 그 서비스가 자체적인 서비스 수준 협약서에 명시된 조건들을 충족시키지 못했다.”는 답을 도출한다.

이는 다시 네 번째 질문으로 이어지고 “그 서비스는 자체의 서비스 수준 협약서를 충족시킬 수 있는 충분한 서비스 용량을 갖추지 못했다.”는 결론이 나온다. 그러나 지금까지의 결론은 우리가 다른 누군가에게 책임을 전가하도록 만든다. 우리의 책임은 무엇일까?

그래서 당신은 다섯 번째 질문을 하고 마침내 최종적인 답을 얻는다. “나는 우리 서비스가 그런 조건과 예외적인 상황을 다룰 수 있도록 설계하지 않았다.”

와우! 드디어 진짜 원인이 밝혀졌다. 처음에는 문제의 원인이 “그들의 잘못이었어.”라고 결론 내려질 거라는 모호한 가정에서 출발했지만, 다섯 단계의 질문 과정을 거친 후에 마침내 진짜 대답이 나타났다. “우리의 기술 서비스가 예상되는 잠재적인 모든 조건을 원활하게 처리할 수 있도록 설계할 필요가 있다. 그렇다면 그런 기술 서비스를 어떻게 설계할 수 있을까?”

진짜 조건을 깊이 파고들고 또한 외부요소에 대한 의존성을 관리함으로써, 문제에 대한 진짜 대답을 찾을 수 있다.