디자이너 개발자 협업
디자이너와 개발자는 모두 현실적 구현을 목표로 한다는 점에서 같은 편이다. 그러나 디자이너가 먼저 상상하고 개발자가 나중에 구현하는 역할 순서 때문에 긴장 관계가 생기기 쉽다. 디자이너는 "현실을 모르는 꿈꾸는 사람", 개발자는 "디자인 의도를 꺾는 현실론자"라는 고정관념이 협업을 방해한다.
멀티탭 디자인 논란 사례가 이 관계를 잘 보여준다. 어느 방향으로 꽂아도 되는 멀티탭 디자인이 온라인에서 화제가 되었을 때, 엔지니어 다수가 "전기 기초 상식도 모른다"며 비판했다. 그러나 실제로 그 아이디어를 바탕으로 동작하는 프로토타입을 만들어 보인 사람이 나타났고, 심지어 외국에서는 10년 전에 유사 제품이 이미 출시된 사실도 밝혀졌다.
이 사례는 두 가지 관점을 제공한다. 첫째, 디자이너가 기술 한계를 모르고 낸 아이디어라도, 개발자가 의도를 파악해 구현 방향을 찾는 자세가 실질적인 결과물을 만든다. 둘째, 디자이너의 아이디어는 '답'이 아니라 '질문'이다. "아무 방향으로나 꽂을 수 없을까?"라는 질문으로 읽어줄 수 있는 개발자를 만날 때 USB-C 같은 혁신이 탄생한다.
협업의 전제 조건. 디자이너도 기술의 모든 것을 알 필요는 없지만, 목공예 디자이너가 나무의 특성을 알아야 하듯 자신이 설계하는 영역의 기술적 감각을 갖추려는 노력이 필요하다. 그 위에서, 기술을 모르는 디자이너의 질문에 비판 대신 구현 방법을 찾으려는 개발자가 있을 때 협업이 꽃핀다.
디자이너가 코딩을 배워야 하는 이유도 같은 맥락에서 설명된다. 코딩을 잘 한다고 훌륭한 디자이너가 되는 것은 아니지만, 훌륭한 디자이너가 되려면 코딩을 배워야 한다는 주장이다. 목공예 디자이너가 대패질을, 패션 디자이너가 바느질을 직접 할 줄 알아야 하듯, 디지털 서비스 디자이너도 최소한 HTML/CSS를 넘어 자바스크립트 같은 정식 프로그래밍 언어를 익혀야 한다는 것이다. 카네기멜론 디자인과 시절의 일화가 이를 뒷받침한다. 디자인 석사 과정에 자바 프로그래밍을 가르치던 교수는 "쉬운 스크립트 언어로 바꾸자"는 조교의 제안에, 이 수업의 목적은 학생을 프로그래머로 만드는 것이 아니라 '컴퓨터를 이해'하게 만드는 것이라며 단호히 거절했다. 컴퓨터가 무엇을 할 수 있고 없는지에 대한 기초적 이해 없이 디지털 디자인을 하는 것은, 나무의 옹이가 왜 생기는지 모른 채 무늬로만 보는 목공예 디자이너와 다르지 않다.
이 주장은 디자인 사고(Design Thinking)의 핵심—스스로 만들고 부수기를 반복하며 혁신을 이루는 과정—과도 연결된다. 과거 스크린 디자인은 디자이너 혼자 포토샵으로 만들어도 실제 제품의 90%에 근접했지만, 인터랙션이 있는 오늘날의 디자인은 혼자 만든 시안이 최종 제품 경험의 50%도 담아내지 못한다. 따라서 프로토타입 툴이든 코드든, 직접 만들어보는 능력의 중요성이 커졌으며, 그중에서도 프로그래밍은 컴퓨터의 원리를 가장 깊이 이해하게 해주는 방법이라는 것이다.
2012 pxd talks 강연 사례("성공하는 제품 디자인을 위한 비밀 무기"). NHN에서 약 15년간 개발과 UI 디자인을 모두 경험한 강사는 협업 갈등의 뿌리를 두 직군의 마인드셋 차이로 짚었다. 디자이너의 사고 범위가 '인터랙션 디자인 + 개발'에 머무는 반면, 개발자는 여기에 '퍼포먼스 + 유지보수 + 트러블 대응 + 테스트 + 변경 후 부작용'까지 고려해야 하므로, 디자이너에게는 사소해 보이는 변경이 개발자에게는 결코 쉽지 않다는 것이다. 이 강연은 인터랙션 디자이너의 역할을 개발자가 의지할 수 있는 전문가이자 여러 직군 사이의 중간자로 재정의한다. 제품개발 일정상 개발이 가장 마지막 단계에 위치해 여유가 없는 만큼, 디자이너가 다양한 의견을 사전에 종합해 개발자에게 전달하고 "하지 않아도 될 일"을 명확히 걸러주는 역할을 해야 한다는 것이다. 이를 위한 핵심 도구가 스토리보드인데, 최종 사용자는 결국 그것을 해석해 구현하는 개발자이므로 간결한 문장으로 작성해야 한다고 강조한다. 그 근거로 제시된 심리 실험은 흥미롭다 — 동일한 스펙이라도 정보량이 많아 보이거나 단순히 여백과 폰트 크기만 키워도 사람들은 더 많은 작업 시간이 걸릴 것으로 추정한다는 것이다. 개발자의 눈높이를 빠르게 체득하는 방법으로는 자바스크립트·jQuery 같은 진입장벽이 낮은 언어로 직접 프로토타이핑해볼 것을 권장했으며, 이렇게 개발을 이해하면 불필요한 기능을 빼는 적극적 협상도 가능해진다고 정리했다. 강연 전체를 관통하는 메시지는 '이해(Understanding)' — 사용자에 대한 이해뿐 아니라 함께 제품을 만드는 개발자에 대한 이해가 성공적인 제품 디자인의 비밀 무기라는 것이다.
KPCB(아마존·선·징가 등에 투자한 미국 대표 벤처캐피털)의 파트너 존 마에다(John Maeda)가 발표한 DesignInTech 2016 보고서는 이런 흐름을 통계로 뒷받침한다. 보고서는 (1) 기술 기업의 디자인 에이전시 인수 증가, (2) 디자이너가 공동창업자로 참여한 스타트업의 더 빠른 성장, (3) VC의 디자이너 파트너 영입 확대라는 세 흐름을 짚으며, 이렇게 부상하는 'Design in Tech'는 전통적인 디자인과는 다르다고 강조한다. 사업적 관점과 기술 이해를 갖추고 집요하게 사용자 만족을 추구하는 디자인만이 살아남으며, 코딩·데이터·통계·마케팅에 대한 이해가 필수라는 것이다. 보고서가 조사한 기술 기업 성공 디자이너들의 교육 배경도 이를 뒷받침하는데, 순수 미술/디자인 계열 정규 교육을 받은 비중은 절반 정도(약 1/2)에 그쳤고 이공계 정규 교육을 받은 비중이 1/3에 달했으며, 전체의 1/3 이상은 두 계열을 모두 정식으로 전공한 이력을 갖고 있었다. 업계 디자이너의 93.5%가 코딩을 배워야 한다고 응답했다는 조사 결과도 이 보고서에서 재확인되는데, 이는 코딩에 관심 있는 일반인을 대상으로 한 코드카데미 조사의 42.7%보다 훨씬 높은 수치다. 결국 '디자이너'가 중요하다는 말은 미대 출신이라는 뜻이 아니라, 디자인적 교양과 토대 위에 사업 성공에 필요한 다양한 기술을 함께 갖춘 사람을 가리키는 쪽으로 의미가 이동하고 있다.
핵심 내용
- 디자이너의 역할: 답이 아닌 질문을 제시하는 사람
- 개발자의 역할: 디자인 의도를 파악해 구현 방법을 찾는 사람
- 비판보다 "어떻게 만들 수 있을까?"라는 자세가 협업을 진전시킴
- 디자이너도 기술적 감각을 갖추려는 노력이 협업의 전제
- USB-C처럼 혁신적 결과물은 서로의 한계를 보완하는 협업에서 나옴
- 디자이너의 코딩 학습은 프로그래머 양성이 아니라 컴퓨터를 이해하기 위한 것
- 인터랙션 중심 디자인 시대에는 혼자 만들어보는 프로토타이핑·코딩 능력이 더 중요해짐
- DesignInTech 2016 보고서(KPCB, 존 마에다): 기술기업의 디자인 에이전시 인수, 디자이너 공동창업 스타트업의 성장, VC의 디자이너 파트너 영입 증가라는 세 흐름
- 기술기업 성공 디자이너의 교육 배경: 미술/디자인 정규 전공 약 1/2, 이공계 정규 전공 약 1/3, 두 계열 복수 전공이 1/3 이상
- 업계 디자이너의 93.5%가 코딩 학습 필요성에 공감(코드카데미의 일반 조사는 42.7%)
- 디자이너 마인드셋(인터랙션 디자인+개발) vs 개발자 마인드셋(+퍼포먼스+유지보수+트러블+테스트+부작용): 인식 범위 차이가 갈등의 근원
- 인터랙션 디자이너는 다양한 직군의 의견을 종합해 전달하는 중간자이자, 개발자가 의지할 수 있는 전문가
- 스토리보드는 최종 사용자인 개발자의 눈높이에 맞춰 간결하게 작성해야 함 — 정보량이 많아 보이면 작업시간을 더 오래 추정하는 심리 실험 결과가 근거
- 개발자 이해를 빠르게 체득하는 방법: 자바스크립트·jQuery로 직접 프로토타이핑해보기
관련 개념
- 디자인 사고 — 문제를 열린 질문으로 접근하는 태도, 만들고 부수기의 반복
- UX 커리어 로드맵 — 디자이너의 기술 이해가 커리어에 미치는 영향
- 디자인 시스템 — 디자이너·개발자 간 공통 언어와 협업 구조
- 프로토타이핑 툴 비교 — 디자이너가 직접 만들어보는 프로토타이핑 실무 도구
- 디자이너 창업과 스타트업 — 같은 DesignInTech 보고서에서 다루는 '디자이너 공동창업자' 관점
- 짝 디자인 — 짝 프로그래밍이라는 개발 문화의 협업 방식을 디자인 영역에 적용한 방법론
- 기획 디자인 개발 간극 — 정적인 기획·디자인 산출물과 동적인 구현 사이에서 프론트엔드 개발자가 겪는 현실적 간극
- 피그마 브라우저 렌더링 차이 — 픽셀·폰트 렌더링 방식 차이에서 오는 디자인-구현 간 오차의 기술적 원인
- DTALKS 샌프란시스코 디자인 세미나 — 샌프란시스코 디자이너들이 소통을 위해 프로그래밍을 배운 사례를 다룬 세미나 후기
- 디자인 가이드 문서 자동화 도구 — Zeplin·inVision 같은 핸드오프 툴이 있어도 결국 리스크는 남으므로 디자이너·개발자 모두 스스로 공부해야 한다는 같은 문제의식
출처
- 디자이너와 개발자 — 이재용, UX 가벼운 이야기
- UX 디자이너는 코딩을 배워야 할까 — 2016-03-09, 이 재용, UX 가벼운 이야기
- 디자이너와 기술교육 Design In Tech — 2016-04-14, 이 재용, UX 가벼운 이야기
- \[2012 pxd talks 11\] 성공하는 제품 디자인을 위한 비밀 무기 (Secret weapon for successful product design) — 2012-10-18, jun.ee, pxd talks