by
Oct 22. 2023
#20 과신으로부터 발생하는 '지식의 착각'
2023년 42주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/67
다음 회고 ☞ https://brunch.co.kr/@327roy/69
인트로
#1 요즘 근황
#인트로
요즘은 회사에서 아주 바쁜 날들을 지내고 있다. 1) 사내 프로젝트를 진행하며 이와 관련된 행사에 참여하거나, 2) 8월부터 말부터 집중하던 제품의 MVP 출시, 3) 그리고 조직 이동 준비 등 여러 이벤트가 동시에 겹친 상황이다. (심지어 전사 3분기 성과발표 행사의 MC도 진행했다.)
그래서 하나씩 잘 풀기 위해 시간을 들이는 중.
일단 저 중에서 가장 큰 이벤트는 맡고 있던 제품이 바뀌는 것(조직 이동)인데, 도메인은 HR과 관련되긴 했지만 변화의 가장 큰 특징은 웹 기획에서 모바일 기획을 하게 된다는 것이다. 현재 회사에는 지금 몸을 담고 있던 조직에 계신 분과 연이 되어 입사하게 된 것이지만, 4개월 정도만에 옆 동네로 떨어지게 된 격. 이것은 아쉽고.. 그럼에도 불구하고 필요한 경험이라고 생각했던 모바일 기획을 하게 되는 것에 대해서는 긍정적이다.
모바일 앱의 경우 제공할 수 있는 정보가 웹보다 한정적이며, 타깃의 접근성 등 관리해야 할 요소도 많고, 관련되어 학습해야 할 것이 더 뚜렷해질 것이기 때문에 적당한 기대감을 가지는 중이다.
좋은 경험을 잘 얻을 수 있길 바란다.
노트
#2 과신으로부터 발생하는 '지식의 착각'
#서비스정책서 #기획
이번 주 인상 깊게 읽었던 아티클 중 ‘지식의 착각’이라는 아티클이 있다.
좋았던 것은 아티클을 읽으면서 나 또한 과거에 경험한 것들에 대해 공감하고, 내가 겸손해야 하는 이유에 대해서 한번 더 생각할 수 있었다는 점.
지식의 착각이란 내가 아는 것보다 훨씬 많이 알고 있다고 착각하는 것을 의미한다. 예를 들어 웹 디자인 영상을 몇 개 보고 디자인에 대해 통달한 것처럼 말하는 것이나 GTM을 심어서 지표 추적하는 것에 대한 글을 몇 개 읽고 막연히 나도 잘할 수 있다고 자신감을 가지는 상황을 말할 수 있다. 이 경우 일종의 말만이가 되기 쉽다(말만이 = 말만 하는 사람).
이 아티클에서 읽을 수 있는 내용 중 기억에 남는 것은 ‘사람들은 자신이 무엇을 모르는지 알 수 없다는 것’. 이전에 다룬 회고의 ‘아는 만큼 보인다’는 내용과도 연관지어 생각할 수 있다.
이에 대한 또 다르게 기억에 남는 것은 ‘기술 습득에 대한 착각’이 있다. 관찰을 통해 배운 지식을 과대평가("나는 깊이 알고 있다!" 생각하는 것) 하기도 한다는 점이 특징이다. 이에 대해 미 노스웨스턴대에서 한 실험을 한 것이 재밌다.
1. 참가자들에게 다트 던지는 법, 문워크 추는 법 등의 다양한 기술을 설명한 영상을 최대 20회까지 반복해서 시청해 달라고 요청한 후,
2. 실험자들에게 영상의 기술을 스스로 시도하기 전 얼마나 잘할 수 있을 것 같은지 평가해 달라고 했다.
3. 참가자 대부분은 단순한 영상 시청만으로도 기술 습득에 도움이 되리라 예측했다. 반복 시청 횟수가 커질수록 자신감은 더욱 커졌다.
실험 결과는? 실험자들은 배웠다고 말한 것이 무색할 정도로 기술 습득을 하지 못했다.
결국 지식의 착각이 반복되고 강해질수록 불러오는 후폭풍(일종의 근자감)이 커지게 된다. 우리는 이에 대한 경계가 항상 필요하다는 것이 이 아티클의 교훈. 이에 대해서 아티클은 아래의 방법을 제시한다.
1. 신중히 생각하기: 막연하게 '이렇게 하면 될 것'이라고 생각하는 대신, 시간을 더 들여 목표 달성까지의 과정을 단계별로 신중히 생각해 본다.
2. 전문가 리뷰: 전문가에게 리뷰를 요청하는 방법이다. 예를 들어, 나의 경우에는 다른 시니어 기획자분에게 업무에 대한 피드백을 요청하는 것을 말할 수 있다.
밑에 있는 내용은 ‘스티븐 슬로먼’이 발간한 책, ‘지식의 착각’에서 다루는 내용이다.
'지식의 착각'은 경제학에서 지식의 저주라고 부르는 개념의 이면이다. 우리가 무엇인가를 알 때 남들은 그것을 모르리라 생각하기는 어렵다. 가령 우리는 어떤 곡의 리듬에 맞춰 가볍게 책상을 두드릴 때 남들이 무슨 곡인지 모르는 것을 보고 놀란다. 본인에게는 익숙한 소리로 들리기 때문이다. 적어도 내 머릿속에서는 무척 익숙하다. 내가 어떤 상식적인 문제의 답을 알면 (예컨대 ‘사운드 오브 뮤직’에 출연한 배우는 누구인가?) 남들도 다 알 것이라고 생각한다.
#2 이 모든 게 기획이다.
#기획
요즘 회사를 다니고 삶을 살면서 느끼는 것은, 이 모든 것이 기획의 결과라는 것이다. 기획의 사전적 의미를 보면 아래와 같다.
”어떤 대상에 대해 그 대상의 변화를 가져올 목적을 확인하고, 그 목적을 성취하는 데에 가장 적합한 행동을 설계하는 것을 의미한다.” - 네이버 사전
그리고 영어로 뜯어보면 기획을 Planning으로 말하고 있다. Plan과 비슷해 보이지 않는가? Plan은 계획을 의미한다. 이 단어에서 말하는 것처럼 기획은 계획을 만들어 내기 위한 과정이라고 생각할 수 있고, 결국 계획은 일종의 결과물을 의미한다. 이 관점으로 보면 우리는 기획이 ‘특수한 목적을 성취하기 위해 적합한 행동을 계획하는 것’이라고 이해할 수 있다.
그래서 기획은 사실 우리 누구나 하고 있는 것이다. 내일 무슨 일을 할지 써 내려가는 것도 업무일정에 대한 기획이 될 것이고, 제품의 사업 로드맵을 구상하는 것은 사업 기획이 될 것이고, 행사를 기획하는 것은 행사 기획이 될 수 있다.
그런 의미에서 각 영역에서 기획을 리드하는 사람들을 보면 대단하다는 생각이 든다. 항상 그들에게는 열정이 가득하고, 어떻게든 잘 이끌어 나간다는 추진력이 있기 때문이다.
예를 들어 오늘 회사 행사에서 행사를 총괄하신 PD님. 행사를 잘 진행하기 위해 협업을 주도하고, 문제를 해결하고, 관객(고객)의 호응을 살피며 마지막엔 피드백을 수집한다. 행사를 기획하는 사람이나 나처럼 서비스(제품)를 기획하는 사람이나 큰 맥락에서는 다를 것이 크게 없다.
중요한 것은 결국 열정을 잘 간직하고 열심히 하는 것이 아닐까.
그래서 나는 이 세상 모든 기획자들을 응원한다.
p.s.
기획을 할 때 어떤 것을 ‘설계(Design)’한다고도 표현한다. 그래서 기획과 디자인은 어떤 결과물을 만드는 과정이라면 어디에 붙어도 자연스럽다.
아마 그래서 기획과 디자인은 파생어가 많은 것이 아닐까? 콘텐츠 기획, 브랜드 기획, 사업 기획, 전략 기획, 서비스 기획, 제품 기획 등 말이다. 재밌는 것은 '기획'이라는 단어를 '디자인'으로 바꿔도 꽤나 자연스럽다. 단 통념상 디자인은 조금 더 외관에 대한 디자인인 느낌이 강할 뿐이지.
https://brunch.co.kr/@ebraim/131
#3 테넌트란?
#테넌트 #파라미터 #라우터 #URL
SaaS 제품을 기획하고 테스트할 때 ‘테넌트’라는 말을 자주 듣는다. 특히 현재 담당 중인 제품의 경우 기업마다 웹 도메인을 따로 발급하고 있는 상황인 만큼 심심하면 들리는 단어다.
개발에서의 테넌트는 파고들수록 어렵지만, 보편적으로 소통할 때는 변하지 않는 도메인 주소 앞단에 위치하는 ‘가변적인 주소’를 지칭한다.
예를 들어 아래 URL에서는 테넌트는 ‘327roy’가 될 것이다.
https://327roy.microsoft.com/royahn?keyword=%as%02%3d
그 뒤 불변한 도메인 주소인 'microsoft.com'이 따라온다.
그 뒤에 붙은 ‘/royahn’의 경우에는 보통 라우터라고 소통하는 편이다.
예시 사진 ⓒ 327royhttps://maily.so/saascenter/posts/de82fda4
#4 할 일 관리
#할일 #프로젝트관리 #업무
이직한 후, 나는 특히 ‘진행 중인 일’을 관리하는 것에 신경을 많이 쓰고 있다. 정확히는 ‘할 일, 진행 중인 일’에 대한 것들. 할 일을 신경 쓰는 이유는 누락하는 업무가 없게 하기 위함이고, 진행 중인 일을 신경 쓰는 이유는 효율적으로 일을 하기 위함이다.
특히 진행 중인 일은 나한테서 발생하는 병목현상을 확인할 때 꽤나 유용하다. 만약 며칠 동안 진행 중인 업무를 달고 있게 된다면, 업무가 쌓이는 구간이 보이기 때문이다(칸반Kanban의 개념과 흡사하다.).
반대로 업무를 어느 정도로 세분화해서 할 일, 진행 중인 일로 정제해야 할지 판단하기 어렵다. 일단 세분화는 고민과 시간을 필요로 한다. 그리고 지나친 세분화는 1) 일을 위한 시간을 추가로 사용해야 하고, 2) 어느 정도로 세분화해야 할지 기준을 잡기 어렵다는 단점을 가지고 있다.
만약 너무 세분화하면 그 업무들은 To-do 리스트와 다를 것이 없고, 세분화를 잘하지 못하면 1) 업무에 대한 진척도 파악과 공유가 힘들어지고, 2) 새로운 업무가 ‘진행 중인 일’로 격상될 때 앞선 업무를 쳐내기 어려워진다. 즉 동기저하와 업무의 병목이 발생하는 듯한 착각을 일으킬 수 있다는 것.
결국은 세분화도 적정선을 타야 한다. 그리고 이번 주에 느낀 것은 아직 나는 내가 진행해야 하는 일에 대한 적절한 세분화와 관리에 많이 미숙하다는 점. 회사에서 업무 시 관리하는 체크리스트들이 (여러 외부 요인이 존재했다고는 하지만) 한동안 진행 중인 일로서 존재하다가 오늘이 되어서야 우르르 완료 처리 되는 것을 보고 느꼈다.
결국 이것은 내가 맡은 일에 대한 적절한 세분화를 못했다는 것을 의미한다. 세분화를 지금 보다는 더 해보되, 너무 자잘한 행동 단위로 너무 세분화되지 않도록 시도해 볼 필요가 있다. 하루 내지 이틀 단위의 업무로 쪼갤 수 있으면 베스트일 듯.
#5 좋은 소통의 조건
#맥락공유 #경험 #소통
한국에서 유명한 개발자, 테오 님의 글을 읽었다. 주 내용은 '개발자가 협업을 잘하기 위한 마음가짐과 태도'에 중점을 두고 있다. 협업의 중요성과 어떻게 개발자가 협업을 잘할 수 있는지에 대해 이야기하고 있으며, 좋은 협업을 위한 테오 님의 개인적인 생각과 지침을 제시하는 글이다.
일을 잘하는 개발자에 대해서 얘기를 하며, 결국에는 개발자 또한 단순 코더에서 멈추는 것이 아니라 문제해결사가 되어야 한다는 것이 글을 관통하는 의미다.
ⓒ https://velog.io/@teo/collaboration