by
Jun 17. 2023
문제 정의 노하우 (1) - 문제를 단순화하자
기획자라 부르든, 프로덕트 매니저라 부르든, 프로덕트 오너라 부르든, 혹은 그 이외의 직무든 모든 직무에서 이른바 '일잘러의 역량'으로 '문제 정의'를 꼽는다.
어언 1년 전 즈음, 관련해서 퍼블리에 글을 올린 적이 있는데 이후 1년 동안 다시 일을 하고, 문제를 정의하(려고 노력하)는 과정에서, 새로 생각이 정리된 바가 있어 간단히 공유한다.
1. 복잡한 문제란 무엇인가
어떤 연차든, 어떤 직무든, 어떤 분야든 우리는 모두 문제를 해결한다. 그리고 그 문제를 잘 풀고 싶다.
그런데 복잡함 문제는 풀기 어렵다. 또는 어려운 문제란 복잡한 문제다.
여기서 이야기하는 '복잡한 문제'란
1) 너무 여러 가지 단서 조항, 고려 사항, 전제 조건들이 붙거나
2) 너무 여러 가지 목표를 가지고 있는 문제를 일컫는다.
예컨대 "시원한 음료수 한 잔을 마시고 싶다"는 문제를 푸는 경우와, "시원하지만 그렇다고 너무 차갑지는 않고, 요즘 제로(Zero)가 대세인 만큼 당은 추가되지 않으면서도 아스파탐 그 특유의 애매한 단맛 대신 좀 더 그럴싸한 맛을 내면서, 자다가 화장실 가긴 귀찮으니까 양은 너무 많지 않은 그런 음료수 한 잔을 마시고 싶다"는 문제를 푸는 일은 분명 다르다. 전자는 '시원한' 것만 고려하면 되지만, 후자는 고려할 사항이 너무 많으니까.
또는 "시원하게 갈증도 해소하면서 동시에 배도 채우고 필수 영양소도 가득했으면 좋겠다"는 문제 역시 복잡한 문제다. 하나의 문장, 하나의 문제 안에 1) 갈증 해소 2) 배 채우기 3) 영양소 충족하기라는 세 가지 목표를 가졌으니까.
2. 복잡한 문제가 좋지 않은 이유
이런 복잡한 문제가 좋지 않은 이유는 단순히 말이 장황하거나 어렵기 때문만은 아니다. 복잡한 문제는 말 그대로 일의 복잡도(complexity)를 증가시키기 때문인데, 복잡도가 증가하면 아래와 같은 몇 가지 문제들이 발생한다.
1) 애초에 문제가 복잡한 문제는 그 안에 여러 가지의 가설을 품고 있다. 그래서 그 가설을 검증하기 위해 알아내야 할 것들이 여러 가지인데, 이를 쭈욱 펼쳐보는 순간 기획자나 리더 본인이든, 그의 요청에 따라 일을 해야 하는 동료든 모두 이에 압도당한다.
2) 그래서 당장 무엇부터 하면 되는지, 다음 스텝이 보이지 않는다. "어... 알겠는데... 그래서 저희가 뭘 하면 되는 거죠?"
3) 설령 무언가를 일단 한다고 하더라도, 이 문제를 풀었을 때의 모습이 명확하게 그려지지 않는다. 그래서 무엇을 위해 이 일을 하는지, 무엇을 향해 가고 있는지 자꾸 잊게 되거나 틀린 방향으로 가게 된다
4) 너무 여러 가지 가설을 검증하고자 하기에, 그 결과를 너무 오랜 시간이 지나서 혹은 너무 많은 노력과 비용을 들이 고나서야 볼 수 있게 된다. 리스크가 증가한다.
3. 문제를 단순화하는 노하우
그럼 그 크고 복잡한 문제는 어떻게 쉽게 만들 수 있을까? 어떻게 복잡하지 않게, 즉 '단순하게' 만들 수 있을까? 이때 단순화된 문제란 '하나의 목표 또는 하나의 가설만 담긴 하나의 문장'의 형태를 지닌다. 이를 위한 방안으로 다음과 같은 몇 가지를 시도해 볼 수 있다.
1) 모든 내용을 아우를 수 있는 포괄적인 문장으로 작성하기
- before : 시원한데 당분도 없고 그렇다고 맛도 너무 낯설지 않으면서 청량감 있는 음료수를 마시고 싶다
- after : 제로 콜라를 마시고 싶다
>> 물론 논리적으로는 세상의 모든 "시원한데 당분도 없고 그렇다고 맛도 너무 낯설지 않으면서 청량감 있는 음료수"가 "제로 콜라"를 의미하지는 않는다. 때에 따라 이는 "제로 사이다" 일 수도 있고 "제로 토닉워터" 일 수도 있다. 그러나 핵심은 누가 봐도 쉽게 이해할 수 있 단 하나의 표현으로 정리되었다는 점이다.
2) AND, OR, BUT을 제외하자
- before : 시원한데 당분도 없고 그렇다고 맛도 너무 낯설지 않으면서 청량감 있는 음료수를 마시고 싶다
- after : 시원한 음료수를 마시고 싶다
>> 아무리 구조상 하나의 문장이라고 하더라도 그 안에 '그리고(AND)', '또는(OR)', '그러나(BUT)' 같은 말들이 추가되기 시작하면 이는 사실상 하나의 문장이 아니다. 하나의 문장의 형태를 하고 있는 여러 문장이다. 이는 앞서 지적한 '여러 개의 가설' 또는 '여러 개의 조건' 혹은 '여러 개의 목표'를 지닌 문장이 된다.
>> 물론 때에 따라 정말로 내가 원하는 게 단순히 시원하기만 한 음료수가 아닐 수 있다. 문제는, 시원한데 당분도 없고 그렇다고 맛도 너무 낯설지 않으면서 청량감 있는 음료수를 찾는 일은 분명 상대적으로 크고 복잡하며 그만큼 리스크가 큰 문제다. 단순히 음료수의 사례가 아닌 비즈니스의 경우였다면 과연 어떨까?
3) 여러 개로 나누어 차근차근 해결해 나가자. 일단 하나만 먼저 해결하자. 동시에 해결하려 하지 말자.
- before : 시원한데 당분도 없고 그렇다고 맛도 너무 낯설지 않으면서 청량감 있는 음료수를 한 번에 찾으려 한다
- after : 시원한 음료수를 찾아본다 > 그중에서 당분이 없는 걸 찾아본다 > 다시 그중에서 익숙한 맛을 찾아본다 > 그중에서 탄산감이 있는 걸 찾아본다
>> 하나의 문장에는 하나의 명제, 하나의 가설, 하나의 목표, 하나의 조건만 있는 게 가장 단순하다. 그러나 반드시 여러 조건과 목표, 명제를 달성해야 한다면 그 모든 걸 동시에 병렬로 해결하려 하지 말고, 직렬로 하나씩 차근차근 해결해 보자. 여러 개의 문제를 동시에 다루는 건 저글링과 같다. 대부분 못한다. 잘하는 사람도 그 수에 한계가 있다.
4. 단순한 문제가 좋은 이유는 설명하고 설득하기 쉽기 때문
이렇게 풀고자 하는 문제를 단순하게 (재)정의하는 궁극적인 이유는, 단순한 문제가 설명과 설득이 쉽기 때문이다. PM으로서 매월 목표를 제안하거나, 아이디어를 구하기 위해 질문을 정리할 때마다 늘 뼈저리게 느낀다. 아무리 복잡해 보이는 사안이더라도 단순하게 정리해 가면 직무와 연차를 불문하고 '아~ 그런 거구나?'라고 이해하는 반응이 돌아오고, 잘 정리하지 못한 경우라면 아리송하다는 듯한 표정이 지나간다.
결국 기획자, PM, 리더, 팀장 등 이끄는 포지션에 놓인 사람은 '이런 문제를 풀어야 합니다!'라고 제안하는 역할일 뿐, 그 문제를 직접 풀 줄은 모른다. 이를 위해 설명하고, 설득한다. 잘 설명하고 설득하려면 이해가 쉬워야 한다. 이해가 쉬우려면 문제가 단순해(보여야) 한다.
그리고 이처럼 내가 풀고자 하는 문제, 답을 구하고자 하는 질문은 항상 누가 봐도 이해할 수 있는 명료한 형태여야 한다.
5. 그런데, 단순하게 만들려고 너무 오래 고민하는 것도 리스크다
그럼 복잡한 문제를 단순화하는 게 너무나 중요하니, 이 과정이 마무리되지 않았다고 해서 완성될 때까지 심사숙고하고, 꽁꽁 숨기면 되는 걸까? 실은 그게 가장 큰 리스크일지도 모른다. 아무것도 진행되지 않은 채, 아무런 피드백도 받지 못한 채 시간이 흘러가고 있으니까. 어쨌든 문제를 단순하고 명료하게 (재)정의하는 이유는 그것을 풀기 위해서다. 그런데 (재)정의하느랍시고 너무 많은 시간이 흘러가면 이는 애초에 문제를 단순하게 (재)정의하는 이유에 어긋난다.
또한 생각이 정리되지 않을 때엔, 제3자의 시선이 문제를 단순화하는 데 도움이 될 수 있다, "음... 그러니까 000 하자는 거죠?" "어... 맞아요..! 그거네요..!"
기획자, PM, 팀장, 리더가 무책임하게 그래도 되냐고? 뭐 어쩌겠는가. 이끄는 이가 동료들에게 게문제를 여전히 조금 복잡한 상태로 가져왔다고 해서 고용주가 그를 해고하길 하겠는가 혹은 연봉이나 복지를 박탈하겠는가?
아주 뻔뻔한(?) 생각이 드는 날이면, 'PM인 내가 정의하지 못한 문제면 어차피 정의하지 못한다. 이게 지금 상황에서의 최선의 결과물이다.'라는 생각을 하기도 한다. 또는 'PM인 내가 제대로 정의하지 못했다고 팔짱 끼고 탓만 하고 있으면 어차피 실패는 전부 다 같이 하는 건데, 이걸 굳이 나만 홀로 고민할 필요가 있을까?' 같은 생각도 든다.
그러니 복잡한 문제는 단순하게 정의하자. 그런데 그게 잘 안되면, 일단 정리된 대로 공유하고 논의하자. 안 되는 걸 어떻게든 하려고 혼자 오래 끙끙대는 것 역시 문제를 복잡하게 만드는 중일지도 모른다.
