당신이 개발자와 소통하기 어려운 진짜 이유(上)
화성에서 온 프로덕트 디자이너, 금성에서 온 개발자
이케아 호랑이 인형이 전자담배를 피우던, 아주 예전은 아닌 과거에...
학제간 수업에서 두 공대 친구들과 프로젝트를 진행한 적이 있다. 우리는 논의 끝에 배를 쓰다듬으면 입을 벌리고 녹음된 음성을 말하는 똥강아지 장난감을 만들기로 했다. 그런데 항상 기구 시안을 설계하면 공대생들은 이렇게 얘기하는 것이다.
"오케이, 근데 작업을 실제로 해 보기 전에는 이게 될 거라고 말할 순 없어."
이게 무슨 말이냐? 디자이너인 우리는 답답했다. 그럼 일정은 어떻게 짜고, 프로젝트 진행은 어떻게 하지? 그날 우리는 디자인과 개발이라는 멀리 떨어진 두 커다란 산봉우리 위에서 서로를 향해 소리 지르는 듯한 지독한 답답함을 느꼈다.
신은 무슨 이유로 이과와 문과가 함께 만나 일하게 했을까? 그 운명이 참으로 기구하다. 준비되지 않은 만남은 충돌을 낳는 법, 개발자 분들과의 경험을 바탕으로 개인적인 성찰을 이야기해 보려 한다.
신은 대체 무슨 생각으로...1. 개발자가 사고하는 방법
한 철학 수업에서 과학의 역사에 대한 흥미로운 이야기를 들은 적이 있다. 기존에 비물질적인 것과 물질적인 것이 뒤섞여 존재하던 중세의 과학철학이, 데카르트 이후 질적 가치는 배제하고 양적 가치를 위주로 사고하게 되었다는 것이다. 이것이 근대 철학의 시작이며, 그 결과가 오늘날의 2진법을 위시한 산업혁명과 컴퓨터의 발명이라고 한다.
좌표계의 개념을 최초로 제시한 데카르트데카르트는 몸이 선천적으로 약해서 허구한 날 침대에 누워 있었다고 한다. 여느 때와 다름없이 병상에 누워 있던 그는, 우연히 천장에 붙은 파리의 위치를 수학적으로 표현할 방법을 고민하다가 좌표계를 발명했는데, 알다시피 이것은 대상을 가로와 세로 x축과 y축 좌표 위에 놓고 물리적 공간을 설명하는 수학적 도구다. 바로 이 좌표계의 발명이 컴퓨터가 가상공간을 인식할 수 있게 하는 포문을 열었다고 해도 과언은 아닐 것이다.
데카르트는 이렇게 물리적인 대상을 0과 1로 치환하는 형이하학적 인식론에 근거해서 우리 주변을 둘러싼 경험 세계를 설명하고자 했다. 이것이 현대인의 유물론적 사고 회로를 담당하는 기계론적 사고관이다.
이렇게 현대 과학은 기계론적 사고를 바탕으로 성장했다. 그렇기 때문에 오늘날 과학적이고 기술적인 일에 종사하는 이들은 대상을 이해함에 있어 질적 측면은 배제하고 양적인 것을 인지하는 데 익숙하다.
기계론적 사고관은 현대 과학을 발전시킨 중요한 지적 시스템 중 하나다. 2. 프로덕트 개발에서의 질과 양
국립국어원의 표준국어대사전에 따르면 질과 양은 다음과 같이 정의되어 있다.
질質: [명사] 사물의 속성, 가치, 유용성, 등급 따위의 총체.
양量: [명사] 세거나 잴 수 있는 분량이나 수량.
즉, 질은 대상에 따라 다르게 해석될 수 있는 가변적인 것이고, 양은 대상이 다르더라도 다르게 해석되지 않는 확실한 것이다. 프로덕트 제작 프로세스의 관점에서는 이렇게 이해할 수 있다.
질
질은 사용자들이 서비스를 이용하면서 느끼는 모든 경험과 감정이다. 사용자 경험 피라미드에서는 사용자의 경험을 유용성, 신뢰성, 사용성, 편의성, 감성, 의미성의 여섯 단계로 구분한다. 이밖에 실제 서비스를 기획하면서 고려하는 질적인 요소는 기호, 맥락, 멘탈 모델 등이 있다.
이 요소들은 모두 디자이너가 기본적으로 고려하는 것들이다. 어떤 것을 만듦에 있어 이것들이 고려되지 않는다면, 그것은 디자인 작업이 아니라고 말할 수도 있다.
양
양은 작업량, 일정, 개발 속도, 기능이 작동하는지, 아닌지에 관한 것이다. 이는 모두 실제로 동작하는 프로그램을 만들 때 중요하며, 애자일 개발 프로세스에서 가장 중요하게 고려된다. 애자일이 개발 분야에서 도입되었다는 사실을 상기하면 어렵지 않게 이해할 수 있을 것이다.
애자일 방법론에서 스프린트를 적용하는 이유도 개발 속도를 추적하고, 기간 안에 개발 가능한 요구사항의 양을 파악하는 데 있다.
3. 두 집단의 서로 다른 뿌리
우리와 함께 일하는 개발자는 컴퓨터 공학을 기반으로 논리적이고 공학적인 일을 하는 사람이다. 이들은 대학에서 컴퓨터의 하드웨어, 소프트웨어 공학을 공부했다. 이들의 뿌리를 거슬러 올라가면, 기계공학을 다루는 엔지니어들, 그리고 더 거슬러 올라가면 물리학, 공학 수학에 이르기까지 일반적으로 디자이너가 딱딱하고 어렵다고 생각할 수 있는 학문 영역을 포함한다. 이들은 기계적 사고, 시스템적 사고를 통해 있음(1)과 없음(0)과 같은, 계산할 수 있고 확실한 것을 중요시하는 경향이 있다.
양적 가치가 중요한 직업의 계보
프론트엔드 개발자
백엔드 개발자
컴퓨터 공학자
기계공학자
물리학자
순수 수학자
...
반면, 디자이너들은 이전에 공예가였고, 예술가였다. 산업이 발전하면서 예술가, 공예가였던 사람들이 산업 디자이너라는 이름으로 종사하게 되었다. 이 산업 디자이너가 오늘날 디지털, 모바일 프로덕트에 대한 디자인을 수행함으로써 UX/UI 디자이너와 프로덕트 디자이너가 되었기 때문에, 이들의 사고방식은 가변적인 질에 대한 관심이 기본으로 전제되어 있다.
질적 가치가 중요한 직업의 계보
프로덕트 디자이너
그래픽 디자이너
패션 디자이너
건축가
공예가
순수 예술가
...
수백 년 전의 디자이너는, 공예가였다. 우리와 그들의 직업적 뿌리를 고려한다면, 이 두 부류의 사고 회로가 꽤나 다르다는 것을 이해할 수 있다. 특히 이렇게 서로 다른 사고법을 가진 디자이너와 개발자에게 있어 자주 충돌하곤 하는 지점은 작업을 진행함에 있어 무엇을 '기본'이라고 생각하느냐이다.
4. 일을 시작하기 위해 필요한 최소한의 것
말하기에 앞서 이 점을 분명히 해두고 싶다.
디자이너가 양적인 척도를 고려하지 않는다거나, 개발자가 질적으로 더 좋은 프로덕트를 만드는 데 관심이 없다는 말은 이 글에서 말하려는 바가 아니다. 그런데 디자이너와 개발자가 더 좋은 것을 만들기 위해 무엇을 고려하는지에 초점을 맞춰 설명하면, 내가 전달하고자 하는 바와 다르게 의미가 왜곡된다는 점을 깨달았다. 초안을 개발자 분들에게 보여주고 나서야 그 사실을 깨달았다.
더 좋은 것을 만들기 위해 무엇을 하는지가 아닌, “일을 시작하기 위해 필요한 최소한의 것이 무엇인지에 초점을 맞춰야 글의 의도가 오해 없이 전달되겠다고 생각했다.
그래서 지금부터 서로 다른 두 전문가가 일을 하기에 앞서 필수적으로 고려하는 것, 이것이 없으면 일을 시작할 수 없는 것에 대해 말하려고 한다. 그리고 이는 디자이너와 개발자가 서로 꽤 다르다.
얼마 전에 친한 개발자에게서 파이콘이라는 개발자 포럼의 유튜브 영상을 추천받았다. 여러분도 한 번 영상을 시청해보시길 바란다.
"기획자가 한 번 추천한 음식은 당분간 추천하지 말라고 했다."
김다현 - PyCon Korea 2021 [유튜브 링크]
여기에서 '당분간'이라는 단어가 의미하는 바는 무엇인가? 이는 다분히 질적인 단어다. 숫자로 표현할 수 없다는 소리다. 누군가는 한 달, 또 누군가는 일주일, 다른 사람은 하루, 심지어는 한 시간으로 해석해도 문제없는 단어다, 이 '당분간'이라는 말은. 이러면 개발자는 일을 할 수 없다. 개발자가 일을 시작하기 위해서는 명확한 양적 척도가 주어져야 한다.
프로덕트 디자이너의 입장에서 '당분간'이라는 말은 아마 대충 며칠 정도를 의미하는 말일 것이다.
본 영상에서는 기획자가 기획 내용을 명확하게 전달하지 않았기 때문에, 영상에서 해당 발표를 하는 개발자 분은 이 '당분간'이라는 말을 '3일'로 스스로 정의하고 개발을 진행하셨다.(이에 대한 기획을 스스로 하신 셈, 매우 굉장). 하지만 이 경우 디자이너의 기획 의도와는 약간 다르게 구현될 수도 있다.
이렇게, 디자이너는 질적인 척도를 가지고 일을 하고, 개발자는 질적 척도를 양적 척도로 전환해야 일을 시작할 수 있다.
디자이너
이 버튼은 어떤 색인가?
시간을 위에 표기할 것인가, 아래에 표기할 것인가? 왜 그래야 하는가?
사용자가 온보딩에서 "지루한 감정"을 느끼지 않으려면 페이지를 어떻게 구성해야 하는가?
개발자
일주일에 몇 번 푸시를 보낼 것인가?
사용자 데이터를 어디에 저장할 것이며, 용량은 충분한가?
이 기능을 구현하기에 앞서 백엔드에서 선행되어야 하는 작업은 무엇인가?
물론, 좋은 디자이너와 좋은 개발자는 프로덕트 개발의 질과 양, 양쪽 모두를 고민한다. 하지만 일을 시작하기 위해 기본적으로 필요로 하는 척도는 서로 다르다. 디자이너는 양적 척도 없이 디자인과 기획을 진행할 수 있고, 개발자는 양적 척도가 있어야 개발을 시작할 수 있다. 그렇기 때문에 커뮤니케이션 과정에서 서로 종종 뭔가를 빠뜨리기도 하고, 더 중요한 게 무엇인지 의견 충돌이 일어나기도 한다.
5. 마치며
개발자의 사고 체계는 프로덕트 디자이너와 조금은 다른 방식으로 작동한다. 이는 개개인의 성격에 기인한 것이라기보다, 그들의 직업적 뿌리 자체가 디자이너와 다른 노선상에 있기 때문이다.
이쯤 되면 개발자와 프로덕트 디자이너가 소통하기 어려운 것은 운명이므로 그대로 받아들여야 하는 것 아니냐는 생각이 들 수도 있다. 그런데 두 직군 모두 공통으로 중요하게 발휘해야 할 역량이 있다. 바로 논리적인 사고다.
개발자가 기계론적 사고, 과학적 접근법으로 무장한 것과 마찬가지로, 디자이너들도 디자인 씽킹 그리고 사회과학적 연구방법을 무기로 사용할 수 있다. 그리고 이 능력들은 모두 논리적 사고Logical Thinking라는 기초적인 지적 능력을 전제로 하고 있기 때문에, 충분히 손쉽게 이를 활용해 그들과 소통할 수 있다.
사무실을 가만히 관찰해보면, 주변에 개발자와 쉽게 소통하는 프로덕트 디자이너가 한두 명은 있을 것이다. 크고 작은 개인차가 분명 있겠지만, 이들은 공통적으로 논리적으로 커뮤니케이션한다는 특징이 있다. 우리도 같은 방법을 활용해서 개발자와 소통할 수 있을 것이다.
논리적인 소통이 무엇인가에 관해서는 다음 글에서 좀 더 자세히 다뤄 보고자 한다.
(다음 편에서 계속됩니다.)
참고자료
1. "기획자가 한 번 추천한 음식은 당분간 추천하지 말라고 했다." 김다현 - PyCon Korea 2021
