‘수요자의 진짜 문제 발견’, ‘문제에 공감’, ‘가치 유무 판단’, ‘빠른 실패 교정’. 디자인씽킹(Design Thinking)의 키워드다. 디자인씽킹이라고 해서 디자이너들에게만 필요한 사고 방식은 아니다. 기업, 교육, 개발 현장에서 쓰일 수 있는 생각 방법이자 도구다. 독일 기업인 SAP가 이 디자인씽킹을 세계적으로 보급하고 있다. 국내에선 SAP 혁신팀이 이 업무를 맡았다. 이 팀에 소속된 디자인씽킹 전담 마크맨인 최송일 SAP 파트너와 이야기를 나눴다. 장혜림 기자 [email protected]

150123_sap_choi1.jpg

“디자인씽킹을 적용하면 조직의 의사결정 과정이 달라집니다. 기존엔 문제 해결에 초점을 맞췄다면 이제 문제 발견 단계에서 솔루션을 고민하게 됩니다.”

최송일 파트너는 디자인씽킹을 어느 분야에서나 적용할 수 있다고 강조했다. 어떤 조직이든 의사결정 방식이 있게 마련인데 원래 어땠는지, 디자인씽킹을 적용하고 나서는 어떻게변했는지 구체적으로 설명했다.

“업무나 결과물을 중간 평가 받을 때 원래는 머리 속에서만 ‘맞을까, 틀릴까’를 고민했겠지만 디자인씽킹 과정에는 프로토타입 개발이 포함돼 있습니다. 프로토타입을 최대한 빨리 실패시키고 피드백을 받아서 최종 솔루션에 다가가죠. 또 이 프로세스의 첫 단계인 ‘공감(Empathy)’ 덕분에 디자인씽킹은 인간중심적인 사고 방식이기도 합니다.”

디자인씽킹이 개발자에게 줄 수 있는 함의로는 무엇이 있을까. SAP랩스의 개발자로 커리어를 시작한 최송일 파트너는 애자일 소프트웨어 개발과 디자인씽킹의 밀접한 연관성을 이야기했다. 애자일 개발 방법론은 어느 특정 방법론을 지칭하는 것이 아니고 기민하게, 자원 낭비를 최소화한 개발 방법론을 포괄적으로 일컫는다. 개발 기획은 물론이고 소프트웨어를 배포할 때 개발자에게 자율성을 부여해 스케줄을 유연하게 조절할 수 있는 시스템이다.

“개발자 분들은 애자일의 장점을 많이 들어보셨을 거에요. 그중 제가 주목하고 싶은 건 ‘리그레이션 버그’에요. 5년 동안 SAP 신제품 유지보수팀의 개발자로 일하면서 부끄럽지만 어떤 부분의 결함을 수정하고 나서 다시 그곳의 버그를, 혹은 다른 데에 결함을 발견하는 경우가 많았어요. 소프트웨어 개발 과정에서 개발자와 품질관리자(QA가 의사소통하는 과정이 부족했던 거죠. 사실 리그레이션 버그는 하나의 예일 뿐이에요. 개발자 사이에서, 개발자와 QA 사이에서 소통이 초기부터 이뤄지지 않아서 소프트웨어를 다 만들고 나서 문제점을 발견하는 경우가 부지기수죠. 그런데 애자일 방법론을 도입하며 달라졌어요. 버그도 줄고 개발 과정도 빨라졌고요. 무엇보다 소통이 잘돼 좀더 역동적이 되었죠.”

그는 애자일을 ‘눈에 보이는 결과물 즉 프로토타입을 보고 피드백을 주고 받는 컨셉, 철학’이라고 설명했다. 개발자로서 방법론에 관심을 갖다 보니 인적자원 관리를 하고 싶었다. 그래서 기회를 잡아 스크럼 마스터(Scrum Master)로서 팀원들에게 애자일 방법론을 교육했다. 스크럼 마스터는 애자일 방법론을 적용하는 과정에서 발생하는 문제를 해결하는 코치를 일컫는다. 관리자의 위치는 아니다. 업무 지시를 내려서 따르게만 하는 프로세스를 싫어하는 최 파트너로서는 최적의 직무였다.

그러다 2013년 디자인씽킹을 접했다.

design_thinking.jpg