문제 해결을 위한 방안
복잡한 문제를 핵심 요소로 분해하고 처음부터 다시 조립하기
회사마다, 조직마다, PM, PO가 하는 일은 조금씩 달라질 수밖에 없다. 맡게 된 프로덕트의 비즈니스의 성향이 B2B이냐, B2C인지도 다르고, 현재 우리 프로덕트의 숙성 상태, 도메인 등에 따라서도 다를 것이다. 나의 경우, 지난 조직에서는 3년간, 이미 10년 가까이 비즈니스를 운영하고 있는 프로덕트의 주문 시스템 백엔드를 담당하는 PO였었고, 현재 이직한 곳에서는 TTS라는 딥러닝 기술을 이용한 오디오 기반의 UGC 서비스를 만들고 있다.(11월 출시를 목표로 열심히 만드는 중이다)
이전 조직에서는 이미 있는 프로덕트에서, 아주 다양한 이해관계자들의 요구사항 속에서 가장 효율적으로 만들어서 비즈니스 임팩트가 큰 기능을 중심으로 프로덕트를 만들어야 하지만, 이제는 사용자를 나름의 논리와 근거를 가지고 상상해 가면서 새롭게 만들게 되었다. 만들면서 느끼는 거지만, 새로운 것이 꼭 좋은 것은 아니다. 이게 맞는지 아닌지 계속해서 고민하면서 최선의 답을 찾으면서 만들어야 하다 보니 삽질이 많아질 수밖에 없다. 최대한 삽질을 적게 하면서 제품팀의 방향성을 잡아 나가는 것이 현재 조직의 PM들에게 가장 요구되는 역량인 것이다.
그러다 보니 요즘 가장 고민하고 있는 것은 '문제 해결'이다. 문제가 생기기 전에 빠르게 문제점을 파악하고 '함께' 해결해 갈 수 있는 방향성을 찾거나, 혹시라도 문제가 발생하면 최대한 빠르게 효율적으로 해결하고 다시는 그런 문제가 또 발생하지 않도록 장치를 마련하는 것이 현재 조직의 PM에게 가장 요구되는 역량이라고 판단했다. 아직 나도 그런 역량이 크지 않아서 현재 조직장의 조언을 받아가면서 해당 역량을 성장시키고자 하면서 알게 된 것이 제1 원리 기반 사고 란 것으로, 한국어로는 번역이 잘 되어 있지 않은 거 같았지만, 그나마 (해당 기사)가 잘 설명되어 있었고, 나는 외국 블로그이지만 (이 블로그)를 참고로 해보았다.
가장 유명한 사례는 엘런 머스크로 (이 블로그) 도 함께 보면 좋다
1 원리 기반 사고 - First principle thinking
정리를 해보자면, 복잡한 문제를 겪게 되면, (1) 해당 이슈를 최대한 분해해서 (2) 해당 문제의 근본적인 요소만 남기고 (3) 해당 근본 요소를 바탕으로 새로운 해결책을 처음부터 다시 정의하는 것이 1 원리 기반 사고라는 것이다.
1 원리 기반 사고를 도와주기 위한 방안으로, 1. 소크라테스식 질문과 2. 5 why 등의 방법론이 있다
1. 소크라테스 문답법
찾아보니, 교육법으로도 많이 활용된다고 하며, 질문을 끊임없이 하고, 상대가 이 질문에 응답하다 보면 어느새 자기주장이 틀렸다는 것을 알게 되며, 비로소 무지(아는 것이 없음)를 자각하게 된다고 한다
이렇게 문답을 하다 보면, '내가 진짜 아는 것과 모르는 것'을 분리할 수 있게 된다고 한다. 해당 질문은 다음과 같은 프로세스로 진행한다고 한다
1. 스스로의 생각을 명확하게 하고, 왜 그런 생각을 하게 됐는지 설명한다
2. 도전적인 추정에 대한 답변 - 사실인지 아닌지 어떻게 알 수 있는지, 만약 반대로 하면 어떻게 되는지?
3. 증거 찾기 - 백업할 수 있는 방법, 출처에 대한 설명
4. 대안적 관점 고려 - 다른 사람들은 어떻게 생각할 수 있는지, 맞다는 것을 어떻게 알 수 있는지?
5. 결과 및 의미 검토 - 만약, 틀렸다면 어떻게 되는지, 틀린 것에 대한 결과는 어떻게 되는지?
6. 다시 원래 질문에 대답하기 - 왜 그렇게 생각하는지, 맞았는지, 추론과정에서 어떤 결론을 이끌수 있는지?
실제 소크라테스는 이러한 형태로 질문을 했다고 한다
소크라테스 : 자네는 정의가 무엇이라고 생각하는가?
트라시마코스 : 강자의 이익이 정의입니다.
소크라테스 : 강자도 물론 사람이겠지?
트라시마코스 : 예, 그렇지요.
소크라테스 : 그럼 강자도 실수를 하겠군
트라시마코스 : 네
소크라테스 : 그럼 강자의 잘못된 행동도 정의로운건가?
트라시마코스 : …
2. 5 whys
5 why는 원래 도요타에서 작업 환경에 대한 개선을 하기 위한 방안으로 활용했다고 한다. 이전 회사에서도 이슈가 생기면 이에 대해서 리포트를 할 때, 5 why를 통해서 시스템 장애 방지 대책 보고서를 작성하는데 활용했었던 경험이 있다. 꼭 장애가 아니라, 어떠한 문제가 생긴 것에 대해 '왜' 라는 질문 5번 해보기를 통해서 해당 문제를 분해하고 쪼갤 수 있다. 최근 이직한 회사에서 개발 일정이 예상보다 약 일주일이나 늦어져서(일주일이면 스프린트 하나라서 작은 이슈는 아니다) 이에 대해서 5 why로 분석해본 경험이 있었다.
1 why : 왜 개발일정이 늦어졌는지?
- 개발스펙 공유 일정이 늦어졌다
2 why : 왜 개발스펙 공유 일정이 늦어졌는지?
- 스펙을 잡으면서 고민되는 점이 많았는데, 이런 부분에 대한 고민을 오래 하다보니 공유 일정이 늦어졌다
3. why : 왜 고민을 오래 했는지?
이직한지 얼마 되지 않아서 경력자로써 잘 하는 모습을 보여주고 싶어서 고민을 오래 했다.
4. why: 왜 경력자로써 혼자 잘 해결해야 겠다는 생각을 했는지?
- 아직 회사 분위기도 모르고 사람들과 친하지 않아서 이런거 물어보는거 자체가 사람들에게 실망을 줄거 같았음
* 이렇게 why로 물어보다 보니까 첫번째로 아직 사람들과 친해지지 않아서 스스로 고민하는데 오래 걸렸다는것을 알게 되었다(이런경우 대부분 혼자 잡고 있는다고 답이 잘 나오지는 않는다). 그래서 이후에는 개발조직 구성원 모두와 1 on 1을 하면서 조금씩친 분을 쌓았으며, 1 on 1은 꾸준히 할 계획이다
분해와 추론에 대한 예시
chef와 cook의 차이로 이야기했다. 영어로는 둘 다 요리사지만, chef는 레시피를 만드는 사람으로 원료의 성분과 결합하는 방법등을 모두 알아, 레시피가 없어도, 정확한 레시피대로 재료가 없어도, 요리를 잘 만들수 있는 사람이고, cook를 레시피대로 만드는 사람으로 래시피가 없으면 요리를 잘 만들지 못하는 사람을 이야기한다. 이걸 보고 스스로 느낀 점은 IT 회사에서 프로덕트를 만드는 모두는 결국 chef가 되어야 한다고 생각했다
위에 링크로도 공유했지만 가장 유명한 사례는 엘런머스크이대. 화성에 가고 싶은데, 비용이 너무 비싸서 제 1기반 법칙의 사고로 뜯어봤더니, 로켓 만드는 재료의 가격이 2%밖에 안된다는것을 확인해서 로켓 원료를 구매해서 직접 만들기 위한 회사인 SpaceX를 세워서 기존의 1/10 가격으로 로켓을 만들면서 수익을 내고 있다고 한다.
결론
아직 해당 사고에 익숙하지 않지만, 계속해서 어떤 이슈나 문제가 생기면 제 1원리 기반 사고를 하면서, 문제 해결을 해볼 수 있도록 노력을 할 계획이다. 결국 진실이라고 생각되는 좀더 근원적인 부분으로 내려가서 거기에서부터 다시 의사결정에 이르는 논리를 쌓아올리는 사고법이 될것 같은데, 이러한 부분에 대해서 계속해서 나의 사례와 고민방안, 그리고 해결방법을 공유하다 보면 좀 더 해당 사고에 익숙해 지지 않을까?
