Talk about Software with hani

흔히들, CEO들이 의사결정을 할 때 사용하는 합리적인 의사결정이라는 게 있죠. 문제를 철저하게 분석하고, 대안을 다양하게 모색한 뒤, 해결책을 선택해서 실천하는 것. 이런 방법은 CEO의 전유물이 아닙니다. 우리가 회사에서 매일 부딪히는 다양한 문제를 해결할 때, 대개 사용하는 방법이죠. 하지만 실용지능에서는, 합리적인 의사결정은 중간관리자 수준에서 효과적이라고 주장합니다.

이 책에서 말하길, 뛰어난 경영자들은 합리적인 의사결정보다 직관이라는, 논리적으로 설명할 수 없는 식스센스로 최적의 답을 찍고, 바로 실행에 옮긴다고 합니다. 물론 CEO들의 의사결정은, 일견 비합리적으로 보이고, 우리가 직장에서 흔히 경험하는 무식한 사장님들의 지시사항이라고 부르는 것에 속하기도 하지만.

CEO수준에서 자행되는 무대뽀식 의사결정 과정이 간혹 효과적인 이유는, 다양한 이해당사자들이 얽혀있는 조직 속에서 발생하는 문제를 명확하게 밝혀내기란, 불가능할 때가 흔하기 때문입니다. 즉 복잡하게 얽힌 문제를 분석하는 데 집중하기보다 해결책을 실천함으로써, 이해당사자들이 어떤 반응을 보이는지, 문제가 어떻게 변하는지 살펴 봄으로써, 해결책을 효과적으로 다시 수정해서 적용할 수 있습니다.

이 방법이 효과적이려면, 해결책을 결정하는 CEO의 직관이 뛰어나야 하고, 해결책을 던졌을 때 부딪히는 이해당사자들의 역학관계를 잘 조율할 수 있어야 합니다. 그렇지 않다면, CEO의 일단 해보고 두고보자는 업무지시는 조직을 혼란에 빠트릴 수 있습니다.

물론 전 CEO가 아니기 때문에, 이런 방법이 옳은지 경험적으로 주장할 수 없는 한계가 있습니다. 다만 중간관리자로서 제 경험이나 일반인으로서 제 경험을 봤을 때, 의미 있는 결과를 얻으려면 고민하기보다 실천해야 한다는 생각이 듭니다. 제 오른손 옆에 있는 마우스를 옮기려는 생각을 백만년 동안 하기보다, 귀찮지만(?) 오른손을 뻗어서 마우스를 움직이는 게 더 쉽기 때문이죠. ㅋ.

1980년대 코카콜라의 미국 음료시장의 점유율은 약 35퍼센트였다. 코가콜라 직원들은 이 점유율을 한계치로 받아들였다. … 그래서 점유율을 올리는 게 아니라 지키는 데 열중할 수 밖에 없었다. ‘펩시’라는 유일한 적을 상대로 벌이는 전투였기 때문에 단 0.1퍼센트라고 해도 중요하지 않을 수 없었다. 그러니 더러는 0.1퍼센트의 점유율을 유지하려는 비용 때문에 배보다 배꼽이 더 큰 상황이었다. …

이 고질병을 로베트토 고이주에타 회장이 해결했다. 고이주에타 회장은 직원들에게 이렇게 물었다.

“전 세계적으로 한 사람이 마시는 액체의 평균은 얼마입니까?” 답은 64온스 였다. “그렇다면 한 사람이 마시는 코카콜라의 평균은 얼마입니까?” 답은 2온스였다.

“마지막으로 묻겠습니다. 코카콜라의 위 점유율은 얼마나 됩니까?” 코카콜라의 진정한 적은 펩시가 아니라 물, 커피, 우유, 요구르트였다.

from 만만한 출판기획

프로젝트를 수행하면서 출제자(=고객)가 낸 문제를, 출제자의 시각으로 바라봤을 때, 답이 없는 경우가 매우 흔하죠. 이럴 때, 문제 자체를 바꿀 수 없다면 문제를 바라보는 시각, 즉 프레임을 바꾸는 순간. 의외로 쉽게 문제가 풀릴 때가 있습니다. 그럴 때, 프레임의 힘을 다시 한번 느끼죠.

얼마 전에 구글을 지탱하는 기술을 읽었습니다. 재미있는 이야기가 많았는데, 관심을 끄는 이야기는, 구글의 개발환경이었습니다(물론 분량이 매우 적었기 때문에, 구글의 개발환경에 대해서 자세히 알 수 없는 아쉬움이 있었죠). 특히 개발이 끝난 소스는, 개발자가 아닌 다른 사람이 반드시 검토를 한다는 이야기가 흥미로웠습니다. 물론 검토함으로써, 소프트웨어의 품질이 높아진다는 구글러의 이야기도 있었죠.

구글에서도 효과적으로 사용한다는 검토는, 소프트웨어 분야의 전유물이 아닙니다. 전자제품 설계가 끝나고 나서, 설계 검토(Design Review, DR)를 실시하도록 대부분의 전자제품 회사에서는 설계 프로세스에 명시해 두죠. 예전에 전자제품의 기구 설계 설계 관련한 컨설팅 프로젝트에 참여했을 때, 설계실장님이나 프로젝트 리더들이 설계 검토가 중요하다고 생각하고, 설계자들에게 DR을 꼭 실시하도록 지시하는 것을 많이 봤습니다.

설계 프로세스에 DR이 명시되어 있거나 윗분들의 엄한 지시가 있어도, 설계자들은 DR을 잘 수행하지 못했습니다. DR을 수행하면, 설계자들이 생각하지도 못한 문제를 발견하거나, 제품이 양산 되기 전에 문제점을 미리 발견해서 해결할 수 있기 때문에, 제품 개발 후단의 업무가 줄어든다는 장점이 있습니다. 이런 장점들은, 경험하지 않은 설계자들도 선험적으로 알고 있었죠.

그렇다면, 설계자들은 이렇게 좋은 DR을 왜 실시하지 않았을까요?

언제나 그렇듯이, 설계 시간이 부족하다는 이유로 형식적으로 DR을 진행하거나, 어쩔 때 생략하고 넘어갔습니다. 물론 프로젝트 리더들도 DR의 중요함을 강조했지만, 실상 양산 일정이 촉박하게 다가오면 일단 설계자들의 능력을 믿고 설계도를 타부서로 넘기는 경우가 많았습니다.

전자제품을 만드는 곳에서 DR을 효과적으로 수행하지 못하는 이유는, 어디에서 많이 들어본 변명이 아니신지요? 맞습니다. 소프트웨어를 만드는 우리 일터에서도 늘상 부딪히는 불만과 비슷합니다.

“그거 하면 좋은 줄 알겠는데, 개발할 시간도 부족해서요. 우리 회사에서 불가능해요.”

소프트웨어의 검토 방식은 다양하죠. 즉 짝 프로그래밍, 버디 리뷰(buddy review), 동료 검토, 워크스루, 정식 검사(formal code inspection) 등이 있습니다.* 어떤 검토 방식을 선택해서 업무에 적용해도, 나름의 효과를 얻을 수 있습니다. 제 경험을 보면, 짝 프로그램의 비용이 가장 낮고 효과가 가장 좋죠. 짝 프로그래밍에 비해서, 정식 검사가 비용이 가장 높지만, 발견하는 결함이 가장 적었습니다.**

***

물론 검토가 소프트웨어 분야의 전유물은 아니지만, 검토는 제품을 개발하는 조직보다 소프트웨어를 개발하는 조직에 훨씬 효과적이고 꼭 필요합니다. 제품을 만드는 조직에서는, 스펙을 잡고 설계도를 그리고 나서, 양산을 하기 위해서 생산 부서, 품질 부서 등에서 검증작업을 별도로 수행하기 때문에, 설계상의 오류를 제품 개발 뒷단계에서 어느 정도 잡아낼 수 있습니다.

하지만 소프트웨어 개발 조직에서는, 특히 SI 프로젝트인 경우 전문 테스터가 프로젝트에 투입될 때가 가뭄에 콩 나듯하고, QA가 하는 일은 체크리스트에 있는 항목을 검토하는 수준에 머물거나, 단위 테스트는 교과서에 나오는 이야기로 생각할 때가 흔하기 때문에, 소프트웨어를 설계하거나 만들면서 발생하는 버그는, 고객이 찾아주는 일상다반사의 것이 됩니다. 이럴 때,  바로 소프트웨어의 품질을 높이는 방법으로서 검토가 매우 효과적이라고 생각합니다.

* from Manage It!

** (제 경험상) 짝 프로그램이 비용 대비 효과가 가장 뛰어나고 정식 검사가 가장 효과적이지 않은 이유는, 한번 검토할 때 살펴 봐야 하는 코드의 양과 검토에 필요한 설계 지식의 양에 있습니다.

짝 프로그래밍을 하면 검토의 범위가 함수나 매우 작은 모듈 단위에 국한되죠. 검토 범위가 매우 좁기 때문에, 다양한 관점에서 코드를 검토할 수 있습니다. 하지만 정식 검사를 한다면, 매우 큰 모듈이나 프로그램 전체가 될 때가 있기 때문에, 정식 검사가 자칫 로직이나 버그를 검토하는 자리가 아닌 코딩 룰 정도나 주석을 Copy & Paste를 하지 않았는지 살피는 자리가 되죠.

짝 프로그래밍을 수행하면 검토자와 작성자의 코드를 비슷하게 파악하기 때문에, 검토 수준이 매우 깊습니다. 이에 반해 정식 검사를 수행할 때, 코드를 미리 배포해도 정식 검사 참석자들이 단 시간 안에 작성자만큼 코드를 파악하지 못할 때가 흔합니다. 그렇기 때문에, 정식 검사는 들인 시간에 비해서 효과적이지 못할 때가 잦습니다.

• 그는 탁월한 능력을 가지고 있다.
• 그는 능력이 탁월하다.

• 그는 돈을 많이 가지고 있다.
• 그는 돈이 많다.

• 그는 꿈을 많이 가지고 있다.
• 그는 꿈이 많다.

• 영희는 두 아이를 갖고 있다.
• 영희는 아이가 2명 있다.

우리 사회에서는, 많이 소요하는 게 미덕이 되는 듯합니다. 가치관이 소유 중심으로 옮겨 가다 보니, 말버릇이나 글버릇도 소유 중심으로 바뀌는 것 같습니다. 소유 중심의 글쓰기와, 존재 중심의 글쓰기, 어떤 게 더 익숙하시나요?