계약서는 꼼꼼히 읽고 사인합시다 – 『대체 뭐가 문제야』

언젠가부터 온갖 리소스가 죄다 일 더 잘하기 위한 힌트로 보인다.

『대체 뭐가 문제야?』는 문제를 바르게 인식, 또는 발견하는 법에 대한 책이다. ‘일’이라 불리는 대부분의 (모든?) 활동은 조금 뒤로 물러나 보면 비슷한 형태다. 문제를 정의하고, 해결할 방법을 고안하고, 도출된 방안을 실행하고, 결과를 평가하고, 다시 문제 정의로 돌아간다. 그런 관점에서, ‘일 잘 하는 사람’을 곧 ’문제를 잘 푸는 사람’으로 정의할 수 있을 것이다.

“문제란 바라는 것과 인식하는 것 간의 차이다.”

밑줄 칠 내용이 많은 책이었지만, 그 중 가장 깊게 인상에 남은 문장이다. 나는 이 문장을 이렇게 받아들였다: 상황 자체가 본질적으로 “문제적”인지, 그렇지 않은지 나뉘지 않는다. 인식하는 사람과 방법에 따라 누군가에겐 문제인 것이 다른 누군가에겐 문제가 아닐 수 있다. 문제는 현재 상태(인식하는 것) 하나 만으로가 아닌, 현재 상태와 원하는 상태(바라는 것) 둘 다가 명확해진 상황에서 그 둘 간의 간극으로 정의되기 때문이다.

이 문장을, 그리고 ‘일을 잘하는 사람은 곧 문제를 잘 푸는 사람이다’라는 명제를 받아들인다면, 다음 두 명제가 자연스레 따른다.

• 문제를 잘 푸는 사람은 바라는 것과 인식하는 것 사이의 차이를 잘 좁히는 사람이다.
• 일을 잘하기 위해선 먼저 바라는 것이 무엇인지, 그리고 인식하는 것(즉, 현 상태)가 어떤지, 마지막으로 둘 간의 간극을 어떻게 메꿀지를 파악하는 능력이 필요하다.

나의 업인 소프트웨어 제품 개발을 예로 들어보자. 제품을 만들고, 세상에 내놓고, 고객이 사용하기 시작하면 이르든 늦든 고객으로부터 다양한 요청이 들어온다. ‘A 기능을 만들어달라’, ‘B 기능을 이렇게 바꾸어달라’ 등등. 이때 이런 요청이 들어오는 족족 그대로 받아들여 A 기능을 만들고, B 기능을 요청대로 바꾸는 일은 사실은 적절한 대응이 아닐 가능성이 높다. 왜일까?

충분히 깊게 파고들고 그들의 이야기를 들어보면, 고객은 우리 제품에 A 기능이 있는지, B 기능이 어떤 식으로 동작하는지 사실은 별 관심이 없다. 고객의 진짜 문제가 ‘A 기능이 없다’, ‘B 기능이 부족하다’는 식으로 정의되는 경우는 드물다. 그보다는 ‘특정한 목표(원하는 것)을 달성하고 싶은데, 지금 제품으로 달성할 수 없는 것 같다(인식하는 것).’와 같은 모습이고, 고객의 요청 자체는 ‘(A 기능이 있으면, B 기능이 다르면, …) 나의 목표를 달성할 수 있을 것 같다’ 라는 생각의 발로임을 자주 발견하게 된다. 이런 경우, A 기능의 개발, B 기능의 수정이 고객의 목표 달성을 돕기 위한 최선의 방안이 아닌 경우가 잦다. 심지어 그 목표를 해결할 수단은 이미 제품 안에 존재하고, 오히려 그 기능을 고객이 인지하기 어려운 것이 진짜 문제인 상황도 종종 있다. 어느 쪽이든, 그 판단은 훨씬 많은 맥락과 디테일을 알고 있는 만드는 사람이 더 잘 할 수 있다. 훌륭한 해결책은 고객의 요청 자체를 문제로 인식하기보다 고객이 요청하게 만든 이유 – 우리 제품이 충족하지 못하는 요구사항 – 을 먼저 깊게 이해하고 그를 해소하기 위한 최적의 방법을 고민하는 자세에서 나온다.

같은 관점을 고객 요청에서 한 발짝 물러나 협업, 일반적인 업무 상황에도 적용할 수 있다. 나의 업인 프로그래머를 예로 들어보자. 특정 API 엔드포인트, 컴포넌트의 성능을 100배 개선한 프로그래머가 있다. 또는 앞으로 5년간 생길 수 있는 모든 유즈케이스를 만족하는 굉장히 유연한 시스템을 3달 만에 설계한 프로그래머라든지. 이들을 괄목할 엔지니어링 적 성과를 달성한 뛰어난 동료로 칭하는 것은 자연스러운 수순으로 보인다.

하지만 정말 그럴까? 실제로는 이들이 ‘없는 문제’를 풀었을 가능성이 항상 존재한다. 100배 느린 원래 버전의 프로그램도 이미 사용자들은 아무런 불만이 없이 쓰고 있었고, 오히려 그 개선 때문에 더 급한 버그가 뒤로 밀려 방치되었다면 어떨까? 마찬가지로 향후 5년을 보고 설계한 그 시스템은 사업적 검증을 거치기 전이었는데, 검증 결과 고객이 전혀 생기지 않아, 1년이 채 안 되어 전체 프로젝트를 폐기할 수도 있다. 즉, ‘인식하는 것’만으로는 당연히 해야 할 것 같은 일이 ‘바라는 것’과 함께 바라보면 그다지 중요치 않은 일일 수 있다. 다르게 표현하자면, 컨텍스트를 빼놓고 어떤 행동이 ‘일 잘하는’ 것에 해당하는지 논하는 것은 넌센스다. 진공 속에 존재하는 일은 없다. 따라서 일 잘하는 방법 역시 진공 속에 존재할 수 없다. 스티븐 코비의 말을 빌리면, 사다리가 올바른 벽에 기대져 있지 않다면 매 걸음을 뗄 때마다 잘못된 곳에 더 가까워지기만 할 뿐이다.

그러므로 일을 잘 하기 위한, 문제를 잘 해결하기 위한 가장 첫 단계는 다양한 층위의 ‘바라는 바’를 파악하는 것이다. 이 조직이 궁극적으로 달성하려는 목표는 무엇인가? 그 목표를 달성하는 과정에 있어, 이 조직이 나에게 기대하는 역할은 무엇인가? 단기적으로, 그리고 장기적으로 그 역할을 잘 수행하기 위해서 요구되는 작업은 무엇이고, 그 작업의 달성도를 어떻게 측정하고 소통할 수 있나?

물론 조직의 바람만큼이나 나의 바람 또한 염두에 두어야 할 것이다. 어떤 환경 속에서 나에게 요구되길 바라는 모습(바라는 것)과 나에게 요구되는 모습(인식하는 것)이 다른 상황은 드물지 않다. 그런 경우, 그 불합치의 발견이 곧 새로운 문제의 발견이다. 남은 선택은 나에게 기대되는 역할, 그리고 그 기대와 나 사이의 간극이라는 두 끝 중 어느 쪽을 당겨올지 – 떠날지 또는 맞출지 – 뿐일 것이다.

뱀발: 원제인 『Are Your Lights On?』은 번역판 제목과는 다소 동떨어져 있다. 어떤 의미인지 궁금했는데, 책 후반부의 한 에피소드에서 확인할 수 있었다. 번역판 제목으로 살리기 어려웠을 이유는 짐작이 가지만, 책의 내용을 함축하는 원제를 살리지 못한 것은 다소 아쉽다.