늘 급한 일로 쫓기는 개발자를 위한 제언⋯ 일의 우선순위와 문제해결

프로젝트를 진행하다 보면 문제가 계속 발생합니다. 어느 날 한 직원이 “왜 출근하면 항상 밤새 시스템이 망가져 있는 걸까요. 슬픕니다”라고 하는 겁니다. 그래서 제가 말했습니다. “이게 안 망가져 있으면 우리가 출근을 안 했겠지. 잘렸겠지. 매일 뭔가가 망가지니까 우리가 즐겁게 매일 일하는 거야.”

문제는 항상 발생합니다. 일이란 문제를 잘 정리하고 계산하고 해결하는 행위입니다. 문제가 재발되지 않게 해결하는 게 중요합니다. 고로 문제 자체를 싫어하면 안 됩니다.

위기관리 프로세스를 예로 들어보겠습니다. 위기관리 프로세스를 준비하면 위기가 발생하지 않습니다. 준비를 했으니까요. 우산을 계속 들고 다니면, 비가 와도 위기가 아닙니다. 들고 다니다가 쓰면 되니까요. 그런데 우산을 가지고 다니지 않으면, 비가 올 때 위기 상황이 되는 겁니다. 그래서 위기관리를 하면 위기가 안 오고, 위기관리를 안 하면 위기가 옵니다.

문제는 필연적으로 계속 발생합니다. 그러므로 문제 해결 시스템을 갖추면 시간 낭비를 줄일 수 있습니다. 문제 해결 시스템을 어떻게 만들어야 할까요? 시스템을 만들려면 문제 해결을 단계별로 나눠야 합니다. 문제 정의부터 문제가 해결되었는지 확인하기까지 과정을 총 6단계로 나눠볼 수 있습니다.

문제는 도처에 도사립니다. 그리고 한둘이 아닙니다. 어떤 문제를 먼저 해결할지 우선순위를 정해야 합니다. 모든 문제를 완벽하게 해결할 수는 없기 때문입니다. 그래서 1단계는 ‘문제 고르기’입니다. 2단계는 ‘고른 문제 정의하기’입니다. 예를 들어 ‘너무 더워서 일할 수 없다’라는 문제가 있다면, ‘더위란 무엇인지, 몇 도가 되면 더운지, 원하는 온도는 몇 도인지’, 이런 식으로 문제를 정의합니다. 3단계는 ‘문제 분석하기’입니다. ‘더워서 생산성이 떨어진다, 땀이 흘러 수건으로 닦아야 된다’ 등 문제의 원인과 결과를 분석합니다.

4단계는 ‘해결책 찾기’입니다. ‘더우니까 선풍기 갖다 놓을까, 에어컨 갖다 놓을까, 밖에 나가서 일할까?’ 고민하는 겁니다. 해결책은 여러 가지여야 합니다. 해결책이 하나여서는 안 됩니다. 저는 해결책이 단 하나일 때는 그 해결책을 적용하지 않습니다. 만약에 그걸 적용했다가 해결이 안 되면 더 위험한 상황이 될 수 있기 때문입니다. 여러 가지 해결책이 있어야, 하나가 실패했을 때 잽싸게 다른 해결책을 시도할 수 있습니다. 문제 하나에 해결책이 하나만 있을 수는 없습니다. 문제 하나에 여러 해결책을 고안한 뒤 제일 좋은 해결책을 골라야 합니다. 이것이 문제 해결의 핵심입니다.

5단계는 ‘선택한 해결책을 실행해도 되는지 결정권자에게 승인받기’입니다. 제일 좋은 방안을 골랐다고 곧바로 실행하면 안 됩니다. 결정권자와 이야기한 뒤 실행해야 합니다. 결정권자에게 해결책을 보여주고 이해와 동의를 구한 뒤 진행합시다. 그렇지 않으면 우리가 해결책을 선택할 때 고려하지 못했던 결정권자만 아는 이유로 모든 일을 처음부터 다시 해야 할 수도 있습니다.

마지막 6단계는 ‘문제가 해결되었는지 확인하기’입니다. 에어컨과 선풍기 중 고민하다가, 에어컨으로 결정했다고 해봅시다. 결정권자가 돈이 많이 들어도 에어컨 설치에 동의했으면, 이제 시원하게 모두가 즐겁게 일하면 됩니다. 그런데 설치했다고 끝이 아닙니다. 얼마간은 계속 확인해야 합니다. 온도가 낮은지, 모두가 행복한지, 문제 해결 상태가 지속되는지 측정해야 합니다.

참고로 문제 해결뿐 아니라 모든 일에서 목표^goal, 계획^plan, 실행^action, 측정^measure 이 네 가지는 중요합니다.

목표가 있어야 의미가 있고, 계획이 없으면 무엇도 할 수가 없으며, 실제 실행해야만 뭐든 결과가 나옵니다. 모든 결과를 측정/분석해서 더 좋은 목표로 수정하거나 아니면 계획을 더 좋게 바꾸어서 다시 실행해 원하는 결과가 나올 때까지 이 과정을 반복해야 합니다. 이 방법론은 지금까지 이야기한 문제 해결 방식에도 동일하게 녹아 있습니다. ‘목표는 문제 해결하기’, 계획은 ‘여러 해결책 마련하기’, 실행은 ‘일부 해결책을 골라서 행동하기’, 측정은 ‘문제가 해결됐는지 확인하기’입니다. 문제 해결 상태는 반드시 유지되어야 합니다. 안 그러면 의미가 없습니다. 만약에 해결된 상태가 유지되지 않는다면 다시 문제를 풀어야 합니다.

제한된 시간을 효과적으로 사용하려면 산적한 문제를 효과적으로 분류하고 대응해야 합니다. 현재 역량으로 풀 수 있는 문제와 풀 수 없는 문제가 있습니다. 따라서 문제를 발견했다면 경중과 해결 가능성을 따져야 합니다. 예를 들어 직원들이 연봉이 낮다고 항의한다고 합시다. 회사가 돈이 없다면 더 줄 수 없으니 현실적으로 해결할 수 없는 문제가 됩니다. 중요하고 풀 수 있는 문제는 풉시다(do it). 중요한데 풀 수 없다면 미래로 미뤄둬야 합니다(postpone). 풀 수는 있지만 중요하지 않다면 위임합니다(delegate). 할 수 있는 일이라고 다 해야 하는 건 아닙니다. 중요하고 풀 수 있는 일의 우선순위가 높습니다. 다음 그림은 우선순위를 정할 때 사용하는 시간 관리 매트릭스를 문제 선별용으로 약간 변형한 버전입니다(우선순위에서는 X 축이 ‘긴급도’입니다).

이 도표의 핵심은 중요하지 않고 할 수 없는 일을 무시^ignore하는 영역입니다. 해결 못할 일에 시간을 낭비하지 않도록 아예 뇌에서 지워버리는 겁니다. 존재하지 않는 것처럼요.

블리자드에서는 아침마다 버그 리뷰를 했습니다. 아침 리뷰 때마다 30개 정도씩 버그가 새로 추가됩니다. 매일 고쳐도 매일 버그가 늘어나니 항상 500개 정도가 유지됩니다. 그중 400개는 몇 달째 쌓여 있는 겁니다. 중요성이 낮고 해결까지 드는 시간을 확보하기도 어려운 문제들이죠. 그래서 400개를 지우자고 했습니다(무시하기), 괜히 리뷰하는 데 시간만 들어간다고요. 그래서 정말로 지웠냐고요? 지웠습니다. 그리고 평소와 같이 매일 30개 버그가 쌓였고, 일부 버그는 고치고(문제 풀기), 일부 버그는 수정하지 않기로 결정하고(무시하기), 일부 버그는 추가 테스트 요청을 했습니다(위임하기). 중요하다고 판단한 100개만 리뷰하면 되기 때문에 시간을 절약할 수 있었습니다. 이처럼 중요도가 낮거나 해결할 수도 없는 일이라면 (리소스 때문이든 능력 때문이든) 머릿속에서 지워버리는 것도 방법입니다. 그렇지 않으면 낭비로 연결되기 때문입니다. 할 수 있는 일, 중요한 일, 해결할 수 있는 문제에 집중합시다. 재발하지 않도록 해결책을 만듭시다.

우선순위대로 일하고, 문제를 해결하고, 낭비를 없애고, 사람들의 역할을 연결해야 합니다. 단순히 일정 잡고 열심히 일하도록 격려하는 역할이 프로젝트 관리라고 오해하기 십상입니다. 하지만 프로젝트 관리는 생각보다 많은 일을 포함합니다.

핵심은 ‘우선순위 정하기’입니다. 우선순위의 기본은 ‘급한가 급하지 않은가?’, ‘중요한가 중요하지 않은가?’에 있습니다. 앞서 얘기한 ‘중요한 데 할 수 있는가 없는가’와 비슷하게 들립니다만, 약간 다른 측면에서 보는 겁니다. 급한 거는 바로 느껴지지만 중요도는 잘 느껴지지 않습니다. 대개는 생각할 시간이 없고, 눈앞에서 당장 닥친 일만 하다 보니까 급한 것 위주로 일하게 됩니다.

찰스 험멜이 쓴 《늘 급한 일로 쫓기는 삶》이라는 책이 있습니다. 우리는 늘 급한 일로 쫓깁니다. 만약에 여러분이 매일 너무 급하게 살고 계속 시간에 쪼들린다면, 뭔가 잘못되고 있다는 겁니다. 중요한 일을 해야지 급한 일의 늪에 빠져서는 안 됩니다. 할 일을 고를 때 급한가 급하지 않은가를 따지지 말고, 한 발 물러서서 ‘중요한가 중요하지 않은가’를 먼저 생각해야 합니다. 급한데 중요하지 않은 일에 시간을 다 써버리면, 그 사이에 급하지 않았지만 중요했던 일이 아주 시급하고 중요한 일로 다가오게 됩니다. 중요한 데 시급한 일이라니! 상상만 해도 무섭군요. 그러니 ‘중요하고 급한’ 일로 분류될 일은 초기에 처리해서 없애버려야 합니다. 그러고 나서는 ‘중요하지만 안 급한 일’ 위주로 처리하면 됩니다. 그래야 자신이 삶을 주도하고 시간을 주도하면서 프로액티브^proactive하게 살아갈 수 있습니다. 급한 일만 하면 일에 쫓겨다니고 끌려다니게 됩니다.

예를 들어 이야기해봅시다. 업무 중에 여기저기서 전화가 오고, 이메일이 옵니다. 그러면 당장 그 일들을 처리하느라 너무 바쁩니다. 그러다가 하루를 다 써버립니다. 이는 외부에서 오는 것에 반응하는 리액티브^reactive 한 삶입니다. 원래 직장 생활이 그런 거 아니냐고 생각할 수 있지만, 이걸 뒤집을 수 있습니다. 이메일이 오면 언제까지 하겠다고 답장하고, 전화가 오면 지금 다른 일을 하고 있으니 언제 다시 연락을 주겠다고 하는 거죠. 아니면 다른 사람에게 일을 넘겨줄 수도 있습니다. 업무 요청을 전부 즉시 처리하는 게 아니라 마감일을 정하거나, 거부하거나, 위임해서 관리해야 합니다. 일종의 대기열을 만들어서 하나씩 차근차근하면 됩니다. 중요한 일은 앞으로, 덜 중요한 일은 뒤로.

우선순위 정리는 시간과 업무 두 측면 모두에 필요합니다. PM이라면 팀 전체의 시간과 업무의 우선순위를 정리해야 합니다. PM이 우선순위를 제대로 정하지 못하고 헤매면 팀 전체가 헤맵니다.