정답이 없는 문제를 너무 고민만 하지 말고, 한 번이라도 부딪혀 보자.
선택의 모순(Paradox of Choice)이라는 말이 있다. 간단히 말하면 '선택지가 많아질수록, 오히려 선택이 힘들어지고, 선택에 대해서 만족하기도 어렵다'라는 의미다. 요즘 같이 정보가 넘쳐나는 시대에는 더욱 선택하기가 어려워진다.
직장 생활에서도 '선택의 모순' 상황은 언제든 생긴다. 예전보다 회사 시스템이 발전하여 원하는 자료는 얼마든지 회사 DB에서 검색할 수 있고, 검색어만 잘 입력하면 인터넷에서 방대한 정보를 얻을 수 있다. 아는 게 너무 많아서 오히려 결정이 늦어지는 상황이 자주 발생한다. 그런데, 직장 생활에서의 '선택의 모순'은 여기에 두 가지의 변수가 더해진다.
첫 번째, 우리는 직장 생활 이전에는 늘 정답을 선택하는 학습을 했고 정답을 강요받았으나, 직장 생활에서 접하는 대부분의 선택은 정답이 없다는 점이다. 이러한 상황은 후배든 선배든 종류는 다르지만 꽤 큰 어려움을 가져다준다.
후배는 본인의 선택이 '정답'이 아닐 경우 본인이 실패를 야기한 것으로 간주될 것이 두려워 선택을 주저하게 된다. 팀장이 '너는 어떻게 생각하냐?'고 물었을 때, '정답을 이야기하지 못하면, 난 인정받지 못한다'는 강박에 제대로 입도 못 떼는 경우가 발생하기도 한다. 팀장이 그런 의도로 물어보지 않았음에도 불구하고. 선배라고 다를 건 없다. 이들은 경험이 많지만, 그만큼 마인드셋(문제를 해결하고, 우선순위를 정하는 방식)이 고정적으로 바뀌게 된다. 더군다나 이들이 풀어야 하는 문제는 후배 사원이 풀어야 하는 문제보다 더욱 복잡하고 예측하기 어려움에도 불구하고, 경직된 마인드셋으로 접근하기 때문에 문제를 풀 때 겪는 어려움은 후배 사원 못지않다.
선배 사원의 예를 들어보자. 예전의 경험으로는 생산량이 증가하면 생산 장비의 유지보수 비용이 함께 증가하고, 유지보수 비용이 증가하는 수준은 투입되는 재료가 비쌀수록 증가하는 경향이 보였기 때문에, 선배 사원은 유지보수 비용을 계산하는 Logic에 재료비를 Factor로 넣었다. 그런데, 이 경우 '가격은 비싸지만, 공정 Step 수를 현저히 줄일 수 있는 재료'를 쓰는 상황이 발생하면 Logic은 맞지 않는다. 즉, 장비 가동시간이 짧아져 전체 원가는 감소해야 함이 맞는데, 위 선배가 짠 Logic대로라면 재료비가 증가하면 그대로 생산 원가가 증가하기 때문이다.
두 번째, 어려움은 어렵게 찾은 정답을 정답이라고 하지 못하는 홍길동 같은 상황이 회사에서는 자주 발생한다는 것이다. 특히 실무 레벨에서 며칠을 고민하여 만든 답(예를 들자면 큰 프로젝트의 진행 방향, 전략)의 초안을 팀장에게 주면 난도질 되어 책상에 놓이는 경우나, 임원 발표를 하면 '원점 재검토' 지시를 받는 경우가 대표적인 예이다. 아무리 논리적으로 설명을 하려고 해도 '아 됐고' 한마디면 끝이다.
또한, 회사는 유관 부서 조직 논리가 매우 강하게 작용한다. 아무리 내가 정답을 들고 가도 이해 관계자 중 한 명이 드러눕듯 반대를 하면, 정답이 선택되지 않는다. 최적의 쓰레기 매립장 부지가 NIMBY로 인해 엉뚱한 지역으로 재선정되는 사례와 매우 비슷하다.
삼국지연의에 나오는 제갈량을 보면 적들이 언제, 어디서, 어떻게 쳐들어오는지를 정확히 예측하고, 그에 맞게 '맞춤형' 전략을 내놓는다. 심지어 적의 심리까지 완벽히 파악하고, 그를 역이용한다. 한 편의 연극 같은 그의 계책을 경험한 장수들은 늘 전투 후 제갈량에게 '군사의 계책은 귀신과 같소.'라는 말로 경의를 표한다.
반면, 조조는 제갈량과는 좀 다르다. 조조는 한 60%쯤 이길 것 같으면 깊게 생각하지 않고, 일단 군사를 일으켰다고 한다. 그리고 일단 붙어보면서 적의 약점을 파악하는 데 주력하고, 적의 약점을 파악하는 순간 '최대로 병력을 집중하여 최대한 빠른 속도로' 약점을 집요하게 파고드는 스타일로 전쟁에서 승리했다고 한다. (조조가 적벽대전에서 패했던 이유를 풍토병과 더불어 수상전에서는 조조 스타일로 속도전을 펼치기 어려웠기 때문으로 해석하기도 한다)
회사에서 어떤 위치에 있고, 어떤 역할을 하는지에 따라서 다르겠으나, 당신이 하는 모든 일의 Risk와 향후 상황을 모두 예측하여 맞추긴 어려울 것이다. 그리고 상황은 변화무쌍하게 바뀐다. 지금 기준으로 Risk 예측이 100% 맞더라도 내일이 되면 틀릴 수도 있는 상황이 충분히 발생할 수 있다.
예를 들어서 개발 프로젝트를 기획했을 때 예상했던 Risk가 3~4가지였다면, 프로젝트를 진행하면서 몇 가지 Risk가 추가로 도출된다. 그리고 각 Risk 간 해결책이 상충하는 경우도 자주 발생한다. 모든 Risk를 해결하지 못하는 상황이 되면, 결국 해결해야 하는 Risk의 우선순위를 결정할 수밖에 없다. 프로젝트를 다시 기획 단계로 되돌릴 수도 없다. 결국 프로젝트를 발의한 사람이 해결해야 한다. 그리고 Risk의 우선순위는 유관 부서별로 다르므로 모든 사람을 만족 시키는 정답은 애초부터 존재하지 않는다. 즉 '모든 Risk를 예측하지 못한 것은 당신 잘못이 아니다. 직장에서 겪는 문제는 정답도 과정도 정해진 것이 아무것도 없다. 정답을 찾겠다고 몰두하면 당신 시야만 좁아진다. 문제가 생기면 너무 걱정만 하지 말고 부딪혀 보면서 해결하자.'이다.
Agile은 90년대 Microsoft에서 당시 인터넷 브라우저를 독점하고 있던 Netscape를 이기기 위해 Internet Explorer를 만들면서 처음 적용한 방식이다. Microsoft는 일단 먼저 빠르게 Alpha version을 출시하여 사용자들에게 피드백을 받으면서 지속적으로 빠르게 프로그램을 Upgrade 하였고, 매일 통합 테스트를 했다. 처음 Alpha version이 출시된 지 9개월 만에 정식 출시가 되었고, 이후 Netscape는 사장되었다. Agile은 특정한 방법론도 아니고, 명확한 절차가 있는 것도 아니다. 다만, 당신이 하는 일의 최종 목표를 빠르게 달성하기 위해서 유연하고 민첩하게 대응하는 업무 방식이다.
(IT 업계 이외에도) 대부분의 회사가 폭포수 모델과 유사하게 일을 할 것이다. 폭포수 모델은 대부분 '기획→디자인→개발→인증→적용→유지보수'의 과정을 따른다. 폭포수 모델은 단계별 엄격한 심사를 진행하고, 전체가 아닌 각 단계에서의 완성도를 중요하게 생각하므로 각 단계별로 시간이 오래 걸린다. 그러나 더 큰 문제는 개발 혹은 인증 단계에서 문제가 발생할 경우 다시 기획 단계로 돌아가는 일이 자주 발생하므로 개발 엔지니어들의 스트레스 가중을 야기하게 된다. 최근 많은 회사들이 업무 효율성 제고를 위해서 이 Agile 방식에 대해서 적극적으로 검토 중이라고 한다.
그런데, 아마 대부분 회사가 Agile 방식으로 일하지 않고 있고, Agile 방식으로의 변화도 많은 시간이 필요할 것이다. 대부분 사람들은 기존의 폭포수 모델과 같이 일하는 데 익숙해져 있을 것이다. 다만 회사에서 일할 때 항상 같은 방법론으로 정답을 찾으려고 하면, 정답을 못 찾거나 정답을 찾는데 너무 많은 시간이 걸릴 수도 있다. 즉, 동일한 문제여도 일하는 방식을 상황에 맞게 달리 가져가는 유연함을 가져야 한다고 생각한다. 정육점에서 발골을 할 때와 사과를 깎을 때의 칼이 같다면, 너무 비효율적이지 않겠는가?