개발자와 디자이너가 (매우) 사이좋게 잘 지내는 방법
0. 당신은 아폴론인가요, 디오니소스인가요?
독일 철학가 니체 Nietzsche는 그의 책 '비극의 탄생'에서 "그리스 고전(비극)이 수천년간 사랑을 받는 이유는 개체의 질서와 균형,상태를 중요시하는 '아폴론적인 것'과 끊임없이 변화하는 혼돈의 생명력을 사랑하는 '디오니소스적인 것'의 조화에 있고, 이 대립의 조화가 예술을 완성한다" 고 이야기 합니다.
제가 이 말을 기억하게 된 놀라운 지점은 두가지입니다.
첫째는 중년이 되어 읽어도 어려운 이 책을 니체는 28살에 전재적인 통찰력으로 써 내려갔다는것과
둘째는 저의 경험상 니체가 말한 사실은-'예술의 완성은 '아폴론적인 것'과 '디오니소스적인 것'의 조화'- 오늘날 소프트웨어 기업이 제품/서비스를 만드는 과정에서도 변함없이 적용되고 있다라는 사실입니다.
많은 분들이 잘 아시겠지만, 아폴론은 태양신이자, 의술, 예언을 담당하는 신입니다. 다재 다능한 신이지만 사랑에는 실패합니다. 그 이유는 그의 본성인 '질서와 균형'에 있다고 합니다. 아마 사랑은 질서나 균형을 앞세우면 어려워지는 속성을 갖는가 봅니다. 그에 비해 디오니소스(로마신화에선 바쿠스로 불리며 어느 제약회사의 자양강장제 '박카스'가 여기서 이름을 따왔지요.)는 술, 풍요와 수확을 상징하는 신이니 질서 균형과는 좀 거리가 멉니다. 많은 사람들에게 사랑을 받았음은 의심의 여지도 없습니다. 이와 같이 이 두신은 태생부터 서로가 대립할 수 밖에 없는 성정을 갖고 있습니다.
많은 분들이 하루에도 수많은 아폴론과 디오니소스를 만나고 경험할겁니다. 사무실에서 마주치는 개발자와 프로덕트 디자이너 (이후에 그냥 '디자이너'로 통칭) 에게서도, 아폴론과 디오니소스의 모습은 쉽게 관찰이 됩니다. 한쪽은 프로세스, 태스크 중심으로 질서와 규칙을 최우선으로 하는데 반해서, 다른 한쪽은 인간의 감성과 반응에 집중하고, 순간 순간 나타나는 변화에 무게를 둡니다. 주로 개발자가 아폴론이고 디자이너가 디오니소스적 경향을 갖고 있다고 생각할수 있지만, 그 반대 경우도 충분히 많습니다. 한쪽에서는 '융통성 없고, 앞뒤 꽉 막혔다'라고 이야기 하고, 반대쪽에서는 '무슨 몽상가 구름잡는 이야기한다'라고 하기도 합니다. 서로 언쟁을 벌이기 십상이고, 이슈가 발생을 하면 서로에게 책임을 지우기 바쁜 대립적인 위치가 되기도 합니다. 이쯤되면 상위의 매니지먼트에서는 서로를 이해해야한다고, 디자이너들에게는 코딩교육을 받으라고 하고, 개발자들에게는 디자인프로세스 교육을 해보지만, 동기부여도 관심도 결여된 그 교육을 통해 특별히 변화되는것은 없습니다.
그러나 중요한 사실은 여러분이 어느쪽에 속해 있던 상관이 없다는 것입니다. 개발자와 디자이너의 협업은 시장에서 지속가능한 훌륭한 제품/서비스를 만들어 내기 위한 필수 요소입니다. 비록 개발자와 디자이너가 제품/서비스에 집중하는 관심 분야가 다르고 속한 조직이 다를 수도 있지만, 현 상황의 문제를 분석히고 창의적으로 해결하는데 두 역할의 협업은 필수입니다. 여러분이 거부할 수 없는 중요한 포인트는 어떠한 상황에서라도 매우 긴밀하게 함께 작업을 진행해야 하는 사이라는 것입니다.
지난번 글 <개발자와 PM이 (매우) 사이좋게 잘 지내는 방법> 에서도 이야기 했듯 저는 운이 좋게도 양쪽의 위치에 있어 보았습니다. 초기에 개발자일때는 디자이너그룹의 아주 작은 단면만 보고 그들을 평가했을뿐 그들을 이해하려는 노력도 하지 않았습니다. 어쩌면 어떤 방법으로 이해를 하면 되는지 어떻게 배워야 하는 스킬인지도 몰랐습니다. 그 이후에 디자이너 그룹으로 이동하니 제가 그전에 생각했던 것이 모자랐고, 그것이 아니었네 하는것들 뿐이더군요. 그래서 오늘은 그 경험을 기억하면서 두 그룹의 구성원들인 개발자와 디자이너들이 서로 신뢰하면서 사이좋게 잘 지내는 방법에 대해서 이야기 해 볼까 합니다.
1. 디자이너가 사랑하는 개발자 되기 (개발자가 할 일)
본인이 누구보다도 날카로운 이성의 소유자, 즉 아폴론적인 인간이라 생각하는 개발자들이 대부분이죠. 질서와 균형의 원리를 사랑하고, 프로세스와 태스크 중심 사고를 하는 멋진 여러분 개발자분들은 이제 다음의 4가지를 시도하고 익혀 사용해보면, 어떨까요?
A. 디자인 프로세스에 적극적으로 참여하고 의견을 전달하세요.
일반적으로 개발자들은 디자이너의 생산물에 별 불만없이-정확히 이야기하자면 별 관심없이- 자신의 작업만을 하는 경향이 있습니다. 개발자들의 관점은 온통 제품/서비스가 동작하는 기능의 구현에 맞추어 있기 때문인 까닭이지만, 특정한 기능이나 제품/서비스 개발경력이 오래 쌓이다 보면, 시니어 개발자가 디자이너에게 필요한 피드백을 줄 수 있는 경우는 생각보다 꽤나 많습니다. 예를 들어 이 상황에서는 어떤 UI/UX로 어떻게 동작하는것이 사용자나 고객이 쉽게 이해할 수 있는지를 알려줄 수 있습니다. 고객을 잘 알고, 고객의 업무를 잘 알기에 가능한 일이죠. 꼭 그런 시니어 개발자가 아니어도 상관없습니다. 당신이 개발자라면 오늘 부터라도 중요 디자인 프로세스 회의에 초대해 달라고 요청하십시오. 디자인 이란것이 디자이너 혼자가 아닌 사용자/고객, PM, 개발자가 함께 만들어가는 것이라는 사실을 인식하고 적극적으로 의견 개진을 해야 합니다. 회의에 참여하기 시작하면, 특별 디자인 프로세스 교육을 받지 않아도 자연스럽게 그 프로세스를 이해하게 됩니다. 또다른 장점은 디자인 중간 결과물(proposals, specs, notes, prototypes)에 대한 리뷰를 시작하면서 인데, 이 부분을 잘 활용하면 개발시간과 비용을 크게 줄일 수 있는 효과가 나타납니다. 초기 리뷰에서 발견할 수 있는 디자인오류등은 간단하게 디자인쪽에서 수정하면 되는것들인데, 리뷰를 적극적으로 하지 않거나 시간을 놓치게 되는 경우가 되어 스프린트가 넘어가면, 이제는 개발하는 쪽에서 그 문제를 해결해야 합니다. 어쩌면 그 해결방법이란 것이 그렇게 UX 친화적이지도 않을것입니다. 지금 스프린트 개발이 바쁘다는 이유로, 차기 스프린트 디자인 리뷰를 게을리 하면, 그 디자인은 고정되고, 개발 비용/시간이 올라가고 효율은 떨어집니다. 이때쯤 되면 디자인 그룹과의 관계도 슬슬 불편해 지기도 합니다.
B. 기술적 제약사항 technical constraints 에 솔직해 지세요.
위의 A번을 좀 더 확장시킨 부분입니다. 디자이너가 생산한 중간 결과물 리뷰중에 기술적 제약사항이 발생될것 같으면 그때는 적극적태도를 넘어서 용감해져야할 시기입니다. 확신하기 어려우면 언제까지 기술검증 technical feasibility test 을 해서 결과를 알려주겠다고 솔직히 의견을 밝힙니다. 혹시나 못한다고 하면 나를 실력없는 개발자로 여기지 않을까라는 두려움을 가질 필요는 없습니다. 기술적 제약 이유를 명확히 설명하고, 구현을 위한 대안을 제시함으로 디자이너나 PM으로부터 더욱 신뢰받는 개발자로 자리매김 할 기회입니다.
C. 디자이너를 개발회의에 초대하세요.
개발자인 내가 디자인 프로세스에 참여하듯, 개발프로세스의 중요 미팅에 책임 디자이너를 꼭 초대하십시오. 여기에는 두가지 큰 뜻이 있습니다.
첫째는 PM과 다른 매니저들이 참여하는 프로젝트 진행 미팅전에 디자인대로 구현되고 있는지를 리뷰/확인함으로 bad surprises를 방지하고 의견을 미리 정리할 수 있습니다. 덧붙여서 개발자와 디자이너가 서로 인간적인 유대관계를 가질 수 있는 기회로도 활용가능 합니다.
두번째는 전체적인 개발 프로세스(설계-개발-CI/CD-DevOps-etc)를 잘 모르는 디자이너의 경우, 개발 워크플로우를 자연스럽게 알려줌으로 개발에 대한 기본 이해와 디자인의 변경시 개발쪽에서는 어떤 프로세스가 어떻게 동작을 하고 핸들링이 되는지를 알게됨으로 상호간 업무 신뢰도가 높일수 있습니다.
D. 막판 디자인 변경Last-minute design change에 조금만 관대해 지세요.
디자인 그룹만의 실수로 릴리즈 직전에 UX/UI 디자인이 변경되는 경우는 거의 없습니다. 사용자 리서치, 사용자 테스트를 거치고 했더라도 고객의 요청이나 시장의 변화가 그 디자인의 변경을 요구하는 경우가 대부분입니다. 물론 디자인의 변경은 개발자에게 시간과 노력을 요구하지만, 개발자뿐만이 아닌 디자이너와 PM에게도 해당됩니다. 개발자에게 즐거운 일은 아니지만, 최종 결정은 PM의 책임이니, 디자인 그룹에 특별한 감정을 가질 필요는 없습니다. 디자이너는 나와 한팀이고, 이런 변경은 더 좋은 제품/서비스를 만들기 위한 필요한 과정이라 생각하면 좋겠습니다.
2. 개발자가 사랑하는 디자이너 되기 (디자이너가 할 일)
아이디어를 시각화하고, 문제를 창의적으로 해결하는데 첫 시작과 끝은 항상 여러분들 디자이너의 역할입니다. 자부심을 갖기에 충분한 일임에도 어느순간 개발자와 PM사이에서 그들을 지원하는 역할을 하고 있는 심정이기도 합니다. 개발을 알아야 한다니, 코딩교육을 신청해서 들어보기도 하지만, 내 적성과는 그리 맞지 않아 보입니다. 순간의 감정과 반응에 집중하고, 그 가운데서 최대가치인 행복감을 선물하는데 재능이 탁월한 디오니소스적인 성향을 가진 여러분들의 업무를 저 재미없고 지루한 개발자들이 이해하고 동감한다면 정말 멋진일 아닐까요? 아래에 제시해 드리는 4가지 팁을 활용해 보시면 어떨까요?
A. 개발자를 업무회의에 초대하세요.
위에서 개발자들에게 디자이너를 업무회의 초대하라고 조언한것과 같은 내용입니다. 일반 개발자들은 디자인프로세스에 대해서 잘 모릅니다. 사용자 리서치는 어떻게 하는것이고, usability testing, accessbility, inclusive design, 프로토타이핑은 어떠한 툴로 어떻게 하는지 무엇을 의미하는지 조차 잘 모릅니다. 누가 많이 알고 모르는지를 위함이 아닌, 서로가 최고의 제품/서비스를 만들기 위해 필요한 존재라는것을 이해하는게 우선입니다. 그리고 서로의 프로세스를 이해하면서, 서로간의 불확실한 면을 줄여가게 됩니다.
B. 인터랙션에는 어노테이션을, 와이어프레임 보다는 프로토타입으로 소통해 주세요.
개발자들을 문서를 그리 꼼꼼하게 읽는 성격이 되지 못합니다. 그것을 이해할 수 있는 주석이 달린 몇장의 그림이 있다면 훨씬 쉽고 빠르게 이해하는 경향이 있습니다. 디자이너 세계에서 명확하게 소통되는 것들이라고 해도 그 중간 결과물을 소비하는 개발자들에게는 더 이상 명확하지 않을 수 있습니다. 인터랙션에 따라서 버튼의 상태와 모양이 바뀌고, 스타일이 변화한다면, 최대한 자세하게 주석을 달아주세요. 또한 가능하다면 와이어프레임 보다 프로토타입이나 인터랙션을 설명하는 애니메이션으로 소통을 해 주었으면 합니다. 디자인계의 전설 켈리 형제의 말로 대신합니다.
“If a picture is worth 1000 words, a prototype is worth 1000 meetings.”
- Tom & David Kelley
C. 개발자 업무 진행 회의에 적극적으로 참여하세요.
여러분에게 코딩교육을 받으라고 하는게 아닙니다. 최소한 여러분과 함께 일하는 동료로서 개발자들은 어떻게 일을 하는지 이해하려는 노력을 부탁하는겁니다. Agile방법론이란 무엇이고, 어떻게 하는것인지, JIRA로 프로젝트를 관리한다는데 어떻게 사용하는것인지, 이번 스프린트에서는 주요 theme은 무엇이었고, 디자인대로 기능개발은 진행이 되고 있는지, 디자인 변경이 일어나면 어떻게 개발 프로세스에 영향을 주는지 이런것들을 알고 있는 만큼 이해의 폭도 넓어집니다. 그리고 이 회의 시간에, 디자인 가이드라인도 설명하고 개발자들에게 그 중요성을 알리는 기회로 활용하세요.
D. 사용자리서치 과정과 결과를 개발자와 공유해 주세요.
휴리스틱평가, 앙케이트, 인터뷰, 필드리서치등을 이야기해도 개발자들의 공감을 얻기는 쉽지 않습니다. 가능하다면 디자인 그룹이 진행하는 온라인 인터뷰에 객원으로 참여할 수 있도록 해주세요. 그럴 상황이 아니라면, 리서치 과정을 설명하고 "이번 사용자리서치 결과는 이런데 이것은 이런 의미이다." 라고 차근 차근 알려주세요. 이 과정은 프로덕트의 비전과 그 로드맵, 유저스토리를 모두 유효하게 하는 장점이 있습니다. 물론 이 부분의 한 축은 PM의 업무 영역이기도 하나, 사용자리서치는 일반적으로 디자인그룹에 속해있고, 그 그룹의 전문가가 전문 지식과 경험과 함께 설명하는것은 PM이 고객과 비즈니스를 설명하는것과는 또 다른 영향력을 가집니다.
3. 글을 맺으면서
글 처음에서 개발자와 디자이너는 아폴론과 디오니소스와 같은 대립적인 성향을 갖고 있는듯 하다고 시작을 했습니다. 누가 어떤 성향을 가졌는지는 중요하지 않습니다. 서로가 가진 대립을 조화롭게 만드는 것이 예술의 완성이라면, 우리가 사용자에게 제공하는 제품과 서비스 역시 아폴론과 디오스소스의 조화가 필요하겠지요. 디자이너와 개발자가 서로의 업무 언어를 이해하고, 기술을 상호 존중하고, 우선순위를 공유한다면, 완성도 높은 제품 서비스가 나오는것은 필요충분 조건이 만족되겠지만, 이 과정엔 거저 얻어지는것이 아닌 많은 노력과 비용이 필요합니다. 개인의 노력도 필요하지만, 그룹의 방향성과 매니지먼트의 의지가 선행되어야 가능합니다. 개발과 디자인은 어느쪽이 더 중요하고, 상위 하위의 개념이 아닌, 양쪽의 바퀴와 같은 구조입니다. 제대로 된 방향성을 갖기 위해선 같은 피치로 움직여야 합니다. 제 적은 경험이 이 글을 읽는 분들에게 조금이라도 도움이 되었으면 합니다. 오늘도 최고의 제품과 서비스를 위해 여러분의 시간, 재능, 노력을 아끼지 않는 여러분들 모두를 응원합니다. 감사합니다.
