어려운 문제를 풀어야 한다는 점에서 사업과 개발은 결을 같이 한다. 어려운 문제에 대한 해결책이 있는가?에 대한 질문에 대해서는 결을 같이 하지 않는다고 생각해왔다.
항상 확고한 답이 있고 선례가 있던 개발만 계속 해왔던 나에겐 당연한 생각이었다. 하지만 너무나도 촌스러운 디자인의 표지를 갖고 있는 '맥킨지는 일하는 방식이 다르다'라는 책은 이런 내 생각을 조금이나마 바꿔놨다.
맥킨지가 강조하는 '서로 배타적이면서, 부분의 합이 전체를 구성하는 것(MECE)'의 원칙이 그러하다. 이 원칙에 대해 읽으며 마이크로 서비스 및 SOLID principle 단일책임의 원칙이 떠올랐다. 우리가 개발을 할 때 하나의 객체가 갖고 있는 속성은 말 그대로 배타적이면서도 부분의 합이 전체를 구성해야만 한다. 그것이 올바른 개발이다. 마이크로 서비스 역시 각각의 서비스는 서로에게 배타적이어야 하고, 그와 함께 같이 어울리며 통합적인 서비스를 만들어내게 된다. 결국 어떠한 지식을 구성하는 법은 논리적인 분리법과 연결방식을 잘 이해하고 있는 것에서 출발한다.
문제를 작은 논리적인 집합으로 나누고 그에 맞는 해결법을 각각 두었을 때, 어떤 문제던 풀리게 된다. 사업과 개발은 이런 면에서 결을 같이 한다. 다만, 사업은 공급자와 수요자가 사람이기 때문에 어려운 심리적인 문제를 풀어야 한다는 요소가 하나 더 존재할 뿐이다.
그러나 개발에도 '사람'이라는 요소가 존재한다. 바로 협업이다. 이 책에서는 다음과 같은 구절이 나온다:
"사실이 갖는 힘에도 불구하고 비즈니스를 하는 많은 사람들이 사실을 두려워한다. 이들의 두려움은 사실을 알게 될 때 신들이나 상사들이 그것을 싫어하게 될지도 모른다는 이유 때문일 것이다. 이들은 사실을 외면하면 골치 아픈 사실이 없어진다고 생각하는지도 모른다. 그러나 현실은 그렇지가 않다. 사실을 외면하면 실패를 자초하게 된다. 결국에는 진실이 드러나기 때문인다. 사실을 겁내지 말아야 한다. 사실을 찾고 활용하되, 그것을 두려워하지는 말라. " 이를 통해 알 수 있는 것은 우선 사고쳤을 때, 실수했을 때, 솔직히 말하고 해결 하라는 것이다. 그리고 어쩌다가 어떤 문제를 발견하게 되었을 때 주변에 알리는 것 또한 협업에 있어 나의 신뢰도를 높일 수 있고 안전한 시스템을 만드는 것에 기여할 수 있다.
개발자들이 만나는 가장 큰 산인 '번아웃'은 컨설턴트도 자주 마주하는 문제이다. 이를 위해 "바다를 끓이지 않고", "계속해서 1루에 진출하는" 행위를 반복하도록 해야한다. 충분히 했다고 생각하면 중단하고, 하나의 큰 홈런을 치기 보다는 업무를 지속적으로 잘해내는 항상성을 발달시키자.
