Why 'why'?
질문에 제대로 답할 줄 아는 것과 제대로된 질문을 할 줄 아는 것.
2014년
부터 2016년까지 뉴욕에서 석사 과정을 공부하던 시기 동안, 기존에 내가 공부했던 분야나 회사에서 업무로 접했던 분야와는 다른 전공을 선택했었기 때문에 공부를 하는 2년 내내 새벽 1시 이전에 잠이 들었던 적이 없었을 정도로 바빴었던 기억이 난다. 비록 얕은 수준이긴 했지만 Front-end, Back-end 코딩을 배웠었고, physical computing에 필요한 기초적인 회로를 다룰 줄 알아야 했기 때문에, 매 프로젝트마다 '하루 벌어서 하루 밥 먹고 사는' 생활이 반복되기 일쑤였다. 그래도 어찌어찌해서 교수님이 주신 reference 자료와 인터넷을 뒤적거려가며 밤새 준비해서 간 프로젝트의 프로토타입이 그럭저럭 볼 만할 정도로 구현되기라도 하면, 다음날 수업시간에 자랑스럽게 발표를 시작하는데- 시작하자마자 내 말문을 막는 교수님의 질문들. '왜 그 프로젝트를 한 거니?', '그건 왜 그렇게 구현한 거지?', '왜 이런 형태로 만든 거니?'
졸업 후에 실리콘 밸리에서 다시 일을 시작했는데, 한국에서의 직장 생활과 여러 가지로 다른 점이 많았지만 그중 하나가 내가 직접 프리젠테이션을 해야 되는 경우가 많아졌다는 점이다. 한국에서는 내가 내 위의 파트장(혹은 그룹장)에게 보고를 하면 그 뒤로는 내 상사가 그 윗선에게 보고를 하는 경우가 대부분이어서 불만이었는데이었는데, 여기서는 직급과는 별개로 본인이 한 프로젝트는 본인이 잘되든 망하든 책임지는 구조와 문화이기 때문에 몇 단계 위의 리더십에게 하는 프리젠테이션의 기회도 종종 갖게 된다. 열심히 작업한 내용을 갈고 닦아서 프리젠테이션을 시작하면 발표 내용에 듣는 이들의 몇 번인가 끄덕거리는 고개를 확인한 후에 마음을 좀 놓을라 치면 가장 먼저 나를 긴장시키는 질문들을 한다. '왜 이렇게 했어?', '왜 이 디자인으로 결정한 거야?'
"왜?" vs "Why?"
한국에서 학교나 회사를 다닐 때는 '왜?'라는 질문을 잘 안 하고, 들을 일도 별로 없었던 것 같다. 그도 그럴 것이, 대개의 경우 '왜?'라는 질문은 많은 경우 부정적인 뉘앙스가 숨겨져 있기 때문에, '왜?'라는 질문을 듣는 것 자체가 크게 환영할 만한 일은 아니었다. 가령 '왜 그렇게 만들었어?'라는 질문에는, '내 생각에는 이해가 잘 안 되는데' 라던가 '내 생각은 좀 다른데'라는 식의 반대하는 의견이 전제되기 마련이었다. 때문에, 내가 한국에서 학교와 회사를 다닐 때 '왜 이렇게 디자인했어?'라는 질문을 누군가에게 받게 되면, 여러 가지의 이유를 대가면서 '이렇게 밖에 할 수 없었다'라는 것을 강조했었다. 내가 어떤 것을 디자인했을 때 필연적으로 이렇게 생길 수밖에 없는 이유를 방어적으로 찾는 것이다.
재밌는 것은 내가 잘 된 디자인을 발표하게 되면 가장 많이 들었던 질문이 '이거 어떻게 만든 거야?'와 같은 류의 것들이다. 내가 왜 이렇게 만들었는지 나의 의도와 생각, 논리를 궁금해하기보다는 어떻게 만들었는지 방법적인 것들을 궁금해한다. 아마도 잘 된 디자인과 그렇지 않은 디자인과의 차이가 발생하는 요인을 '어떻게 만들었느냐'의 관점으로 보기 때문일 것이다. 이 때문에 허접한 컨셉이라도 잘 만들어진 것이 허접하게 만들어진 좋은 컨셉보다 좋은 평가를 받는 경우가 많았다.
반면에 내가 미국에서 공부하고 일하면서 수 없이 들어온 'why?'로 시작되는 질문들은 그 목적과 성격이 한국에서의 그것들과 많이 다르다. 이곳에서 'why?'로 질문하는 것은 대부분 어떤 선입견이 없이 정말 그 의도가 궁금해서 물어보는 것이다. 가령 내가 어떤 디자인을 발표하고 나서, 'Why do you think the design should be like that?'라는 질문을 듣는다면 나는 그 디자인을 선택한 분명한 '나의 이유'를 설명해서 그들을 설득해야 한다. 내가 어떤 선택을 할 수밖에 없는 외부적인 이유를 늘어놓는 것이 아니라, 내가 디자인을 진행하면서 고민했던 흔적들, 그리고 그 고민의 결과물을 이끌어내게 된 합리적인 이유를 설명해야 한다. 이때 나의 생각을 제대로 이야기하지 못하고 '음... 그거 개발 스펙이 그것밖에 안돼서', '우리 임원이 그렇게 결정해서'라는 식으로 말하면, (좀 과장해서) 나는 디자이너로써 무능한 인력이 된다. 설령 방금의 예처럼 개발 스펙이 뒷받침해주지 못한다 하더라도, '제한된 개발 스펙이 있기 때문에 그 안에서 최대한 구현할 수 있는 범위의 디자인은 A안이고, 시간과 인력이 좀 더 투자가 된다면 좀 더 개선된 디자인인 B안을 구현할 수도 있다'라는 식으로 디자이너로써 나의 생각을 주도적으로 펴 나가는 것이 중요하다.
Why important 'why'?
'왜?'라는 질문을 하는 것이나 듣는 일은 한국인이라면 아마 누구나 어색해하고 크게 긍정적으로 반응하지 못할 것이다. 그러나 이곳에서 'why?'라는 질문은 하는 쪽이나 듣는 쪽이나 비교적 환영받는 일이다. 질문을 받는 사람의 입장에서는 본인의 생각과 주장을 표현할 수 있는 좋은 기회이며, 질문하는 사람 또한 그런 것을 듣고 싶어 하기 때문이다. 처음에는 단순히 문화적인 차이라고 생각했었는데, 실리콘 밸리에서 여러 사람들과 일을 하는 경험이 많아질수록 왜 'why?'라는 질문이 중요한지 깨닫게 되었다.
Answering to 'why?'
'Why?'라는 질문에 제대로 답할 줄 아는 사람은, 소위 말해 '생각이 있는' 사람이다. 뚜렷한 주관이 있고 논리가 있어서 어떤 일을 맡기더라도 기본적으로 일을 풀어갈 줄 아는 사람이다. 이런 사람들은 누군가 일을 결정해주기 기다리기보다는 주도적으로 일을 진행해간다. 주도적으로 일을 진행한다는 의미는 임의대로 일을 결정해서 추진한다는 뜻이 아니라, 어떤 때에 어떤 일을 해야 하는지, 누구와 상의해야 하는지, 혹은 어떤 난관에 봉착했을 때 어떤 것을 해결해야 하는지, 심지어 어떤 것을 모르는지도 정확히 구분할 줄 안다는 뜻이다. 프로젝트의 리더이든 멤버이든 간에 일을 주도적으로 이끌어가지 못한다면 역할과 책임이 분명한 이곳에서 성과를 내기는커녕 살아남기도 어려워진다.
Asking 'why?'
'Why?'라는 질문을 제대로 할 줄 아는 사람은, 언제나 잠재된 문제점들이 수면 위로 올라오기 전에 그것들을 발견할 줄 아는 사람들이다. 우리가 학교에서 공부할 때 흔히 교수님들이 Problem solving을 강조했던 것을 기억할 수 있을 것이다. 하지만 Problem solving 보다 중요한 것은 Discovering Problem 하는 능력이다. 이미 발생한 문제에 대해 '어떻게 해결하지?'라고 접근하는 것보다, 문제 발생 이전에 잠재적인 문제를 미리 발견하고 해결할 수 있다면 회사 입장에서는 시간, 인력, 경제적으로 엄청난 리소스를 절약할 수 있고, 사용자의 입장에서도 문제를 겪지 않아도 되니 Win-Win 할 수 있게 된다. 이 때문에 대부분의 프로젝트를 시작할 때 첫 단계인 리서치에서 잠재된 문제점을 파악하기 위해 상대적으로 많은 시간을 투자한다. 정확하게 문제점을 짚어내는 것이 문제를 세련되게 풀어내는 것 이상으로 중요하기 때문이다.
seh
