디자인 씽킹(Design Thinking) 하라.

새롭게 디자인 하기

by 노연석

스텐퍼드 대학의 d.school이라고 들어 보셨나요? d.school에서는 Design Thinking Process(5단계)를 통해 학생들을 교육을 하고 있다고 하는데요. 책을 통해 접했는데 이 프로세스를 처음 봤을때 어디서 많이 본 것 같았습니다. 프로그램(소프트웨어)를 개발하는 프로세스와 유사한데 개발 할때 <요구사항 청취-요구사항 정의-설계-개발-테스트/디플로이>의 프로세스로 진행하는데 정말 비슷하다고 생각 했습니다.

저는 프로그램 개발자로 20년 이상 일을 했습니다. 물론 지금도 그 분야에서 일을 하고 있고요. 이 프로세스를 보면서 업으로만 생각하던 프로세스를 생활에 적용해 보는 것도 괜찮겠다라는 생각을 해 봤고 실천 해 보고자 합니다.


자, 그러면 Design Thinking Process vs Program Development Process 2가지를 비교하여 설명 해 보겠습니다.


1단계. 공감하기 - Empathize vs 요구사항 청취
Design Thinking
관찰, 대화, 체험, 인터뷰 등을 통해서 상대방의 마음을 이해하고 깨닫는 행위를 말하며, 관찰대상에 주관적인 판단을 배제 해야 합니다. 상대방의 마음을 이해한다는 것은 결국 문제가 무엇인지를 찾아내기 위한 단계인거죠.

Program Development
일반적으로 제품을 사용하는 사람들에게 제품에 필요한 기능, 구성, 구조등을 설문, 인터뷰 등을 통해 수집하고 정리하는 단계.사용자, 즉 고객이 요청하는 사항을 가감없이 그대로 기록을 하죠. 기존의 것을 개선할때는 역시 문제를 발굴하는 단계라고 할 수 있습니다.


2단계. 문제를 새롭게 정의하기 - Define vs 요구사항 정의
Design Thinking
1단계 통해서 상대방에 대한 이해, 깨달은 내용을 기반으로 상대방의 입장에서 문제를 새롭게 바라보고 정의하는 행동으로, 사장 입장에서 직원들이 하는 행동이 마음에 들지 않을때, 내가 직원이 되어 그 입장에서 생각해 보는, 즉 같은 눈높이에서 보고 느낀 것을 토대로 정의 하는 것이다.

Program Development
일반적으로 소프트웨어를 사용자에게 제품에 필요한 기능, 구성, 구조 등을 설문, 인터뷰 등을 통해 수집하고 정리하는 단계 입니다. 조사한 요청하는 사항을 가감없이 그대로 기록을 하죠.


3단계. 아이디어 발굴하기 - Ideate vs Design
Design Thinking
이 단계는 2단계에서 정의한 문제 해결을 위한 아이디어를 도출하고, 나누고 정리하는 과정이라고 할 수 있습니다. 아이디어를 도출 하는 방법은 브레인스토밍, 스토리보드, 마인드맵 등을 활용 합니다. 그외 다른 기법들이 있다면 수단과 방법을 가릴 필요는 없습니다. 도출된 내용들은 정리하고 우선순위를 정하는 작업을 진행합니다.

Program Development
2단계에서 정의한 내용을 기반으로 기능, 구조, 프로그램, 데이터베이스 등의 설계를 하는 단계로 소프트웨어에 따라 여러가지 항목으로 설계가 진행 됩니다. 건축에서도 유사하기 기초설계, 상세 설계등을 진행 한다.


4단계. 시제품 만들기 - Prototype vs Prototype/Coding
Design Thinking
말 그대로 Prototype 입니다. 완벽하게 만들기보다 빠르게, 단순하게 만들고 최대한 빨리 반복해서 만들어 보는 과정을 진행하면서 시도도 빠르게 실패도 빠르게 하면서 반복을 하는 것이 중요 합니다. 빠르게 진행하여 실패를 통해서 완성품을 만들어 가면 된다고 보면 되겠습니다.

Program Development
설계한 내역을 기반으로 개발에서도 Prototype을 만들어보고(생략할때도 있음) 결정 후 Coding을 진행합니다. 소프트웨어 분야마다 다르겠지만 홈페이지와 같은 프로그램을 개발한다고 할때 화면, 비즈니스로직, 인터페이스 등과 같은 프로그램 Coding을 합니다.


5단계. 테스트 및 검증 하기 - Test vs Test/Deploy
Design Thinking
만들어진 Prototype이 2단계에 정의한대로 만들어지고 작동을 하는지 테스트 및 검증을 하는 단계로 이 단계에서 나온 문제점, 결함 등은 다시 4단계로 돌아가서 보완하고 테스트를 다시하는 반복(Iteration)을 계속 수행하여 완벽한 제품을 만들어가면 됩니다.

Program Development
이 부분은 Design Thinking과 거의 동일하다고 봅니다. Coding이 완료된 프로그램을 요구사항에 정의 한대로 테스트하고 보완하는 작업을 수행합니다.



저는 너무도 익숙하고 늘 하던 거라 많이 거부감이 없습니다. 사실 어떤 일을 할때 이런 프로세스로 진행을 한다는 것은 매우 힘든 일입니다. 5단계를 거치려면 아무리 작은 일이라도 많은 시간이 소요 됩니다. 하지만 이 프로세스를 제대로 따른 다면 결과적으로 실패를 할 확율이 적어 집니다. 왜냐하면 4단계에서 이미 작은 실패들로 성공을 만들어 가기때문 입니다.


물론, 극히 드물지만 5단계를 모두 거치고 실패를 하는 경우도 있습니다. 실패를 했다면 그건 정의하기Define)를 잘못하여 그 이후의 프로세스들도 다 잘못 될수 밖에 없기 때문 입니다.

프로그래머들에게는 유명한 몇컷짜리 그림이 있는데 개발에 참여한 고객, PM(Project Manager), 설계자, 개발자 등 똑같은 요구사항을 서로 다르게 이해하고 다른 결과물을 만들어 냅니다.


이렇게 말이죠.
개발 세상에서 흔한 오류

※ 그림 출처 : 유엔젤 테크니컬라이트 손대리 블로그


위 그림과 같은 문제가 발생하는 것은 앞서 말씀 드린 요청사항에 대한 정리, 즉 요구사항 정의를 제대로 하지 않았기때문에 발생하며 목표나 주제가 정해지면 목표를 달성하기 위한 정의를 올바르게 해야 한다는 것입니다. 혼자 하는 일이면 실패해도 리스크가 적겠지만 다른 사람들과 같이 하는 일이라면 더욱 더 중요한 사항이고 특히, 회사의 일이라면 엄청난 비용의 손실로 돌아 옵니다.


사실 이런 프로세스를 나에게 대입 해 보는 것은 도전해 볼만한 일이기는 하지만 일단 어떤 목표를 세웠다면 그 목표를 달성하기 위해 무엇보다 중요한 것은 꾸준히 끝까지 갈 수 있는 습관을 들이는 것 입니다. 습관을 들이고 거기에 이런 프로세스를 적용하면 실패할 확율을 1%라도 줄일 수 있다고 저는 생각 합니다.


2020.01.31 금요일 1월의 마지막날, 건강하고 의미있는 삶을 살기 위해 새롭게 디자인 중...