Design Spectrum E01 후기
화성에서 온 디자이너, 금성에서 온 개발자
디자인 스펙트럼
지난 2월 18일 토요일에 강남 D2 스타트업 팩토리에서 진행되었던 Design Spectrum 첫 번째 오프라인 이벤트에 참가를 했었습니다. (재밌었습니다.)
Design Spectrum은 IT분야 디자이너들을 위한 커뮤니티로, 그동안 정기적인 오프라인 교류를 가진 커뮤니티가 드문 것에 아쉬움을 느꼈던 현업 디자이너분들이 모여 준비해주신 커뮤니티입니다.
(Design Spectrum 페이스북 페이지 : https://www.facebook.com/sharedesignspectrum)
출처 <Design Spectrum 페이스북 페이지>현재 Design Spectrum을 운영 중이신 몇 분은 작년에 LET:Interaction Design&Prototyping 워크숍도 주최하신 적이 있는데, 그때 참여했던 저는 워크숍 세미나와 패널토크를 통해 많은 인사이트와 리플래쉬를 받았었고, 깊은 생각을 하게 했줬던 경험이 있었기에 Design Spectrum 모임에도 큰 기대를 가지고 있었습니다. (재미있었습니다.)
이 때문인지 2월 11일 오후 5시에 진행되었던 참가자 선착순 모집에 저는 10분 전부터 학생 때 수강 신청한다는 마음가짐으로 긴장한 상태로 대기를 했었고, 정각에 칼 같은 신청을 했었습니다. 100명이라는 많은 인원을 모집해서 그런지, 예상외로 6시까지 여유롭긴 했었습니다.
이번 오프라인 이벤트에선 '화성에서 온 디자이너, 금성에서 온 개발자'라는 주제로 디자이너와 개발자와의 협업에 대한 이야기를 들을 수 있었습니다. 1부는 디자이너 분들의 각자의 경험과 생각을 공유하는 프레젠테이션을, 2부는 디자이너 분들과 개발자 분들의 패널토크가 있었습니다.
<참여 스피커>
디자이너 : 윤성권(acciio), 이정영(라인), 정희연(스포카)
개발자 : 김태호(레진코믹스), 이준원(네이버), 정원희(프리랜서), 조은(우아한 형제들)
Design Spectrum 이벤트를 참여하기 위해 강남으로 가는 길은 무언가를 배우러 가는 긴장감이 아닌 디자이너들의 '이야기'를 들으러 가는 편안함이었습니다. 그들의 이야기를 듣고 공감하고, 생각에 빠지는 것은 분명 즐거울 것이라 생각했습니다.
1부 : 프레젠테이션
1부는 디자이너 프레젠테이션으로 윤성권(acciio), 이정영(라인), 정희연(스포카) 디자이너 세분의 경험을 기반으로 한 이야기를 들을 수 있었습니다. 저는 업종이 다른 관계로(?) 실무에 대한 건 100% 공감하지 못했지만, 개인적인 공부와 관심으로 이야기의 맥락은 이해할 수 있었습니다.
세분은 과거 개발 사이드 쪽을 몰랐기에 생겼던 개발자와의 마찰과 답답함(?), 이를 해결하기 위해 어떠한 것을 해오셨는지 이야기해주셨습니다.
정희연 님께선 버튼과 레이아웃 배치 구현을 예시로 디자인 산출물이 어떤 원리로 구현되며, 코딩을 공부하시면서 알게 되었던 개발자의 고충과 작업 방식을 알려주시면서 왜 디자이너와 개발자 간의 밀당이 이뤄지는지 자신의 경험을 기반으로 이야기를 해주셨습니다.
윤성권 님께선 실무 초기 자신이 알던 단위와 개발의 단위의 차이에서 왔던 어려움에 대한 이야기에서부터 발전해온 인간의 측정 방식의 역사를 매우 재밌게 풀어주셨습니다. 그리고 didot 폰트에 대한 이야기와 함께 표현이 먼저인가? 기술이 먼저였던가? 에 대한 이야기와 각자의 언어(디자이너와 개발자)에 어떻게 접근하면 좋을까에 대한 이야기를 해주셨습니다.
이정영 님께선 시안 상태와 산출물과의 괴리감에 대한 이유들을 과거에 하셨던 인터랙션 디자인 위주로 예시를 보여주시면서 경험 기반으로 이야기해주셨습니다. 원하는 인터랙션 모션들을 개발자에게 어떻게 효율적으로 설명할까? 에 대한 고민부터 개발자가 왜 안된다고 했는지 알기 위해 하셨던 경험담을 공유해주셨습니다.
아래는 발표 내용을 간략하게 큰 맥락만으로 간추린 것입니다.
(각 섹션의 모든 내용들을 녹음하긴 했지만, 내용이 너무 많기도 하고 개인적인 후기이기에 매우 생략하겠습니다)
(제가 두서없이 쓸 것 같은데 양해 바랍니다..)
정희연(스포카)
과거 시안 상태의 완벽함이 왜 산출물로 나오면 이상할까?라는 의문을 가졌다. 개발자의 이유로 디자인 스펙이 깎여 나오는 점이 매우 답답했다.(이때 나왔던 조각상 사진으로 비유하신 자료는 정말 재밌고 함축적이었습니다. 사진을 찍질 않아 자료가 없어 아쉽군요..)
그들(개발자)의 언어를 모르니 쉬워 보이는 것도 안 되는 경우에는 너무 답답했고, 때문에 코딩을 공부하기 시작했다. 코딩을 하면서 그들의 언어를 알게 됐고, 왜 안 되는 건 안되는지, 쉬워 보였던 것도 결코 간단하지 않았다는 걸 알게 되었다.(동시에 귀찮아서 안된다고 했던 것도 알 수 있게 됨.)
디자이너는 매번 모든 걸 맨땅의 헤딩으로 새롭게 만드는 것이 아니라, 소스의 활용 / 툴 세팅 등으로 작업의 방식이 존재한다. 이는 개발자도 마찬가지다. 개발자도 이런 자신의 작업 방식의 범주안에서 해결할 수 있으면 해결하려고 한다. 우리는 서로 이걸 모르기에 오해가 생겨난다.
개발자가 디자이너에게, 디자이너가 개발자에게 각자의 이런 부분을 공유하면 순탄한 협업과 소통이 이뤄질 것이라 본다.
디자이너가 코딩을 아는 것은 건축가가 건축디자인을 할 때 건축 자재나 건물을 쌓아 올리는 방식을 아는 것과 같다. 이는 시공 실무를 하는 것과는 다르다. 건축가가 시멘트를 옮기고 하는 건 아니니깐..
내가 디자인한 제품이 어떻게 만들어지는지에 대한 원리는 알아야 한다고 본다.
희연님은 과거 가이드를 십진수로만 해서 줬던 몰랐기에 했던 실수부터 해서, 버튼에 들어가는 레이블 정렬 방식에 대해서도 디자이너와 개발자는 다른 방식으로 생각하고, 어떻게 구현되는지 보여주시는 등 버튼과 레이아웃 배치들을 예로 들어 개발 방식에 대해 많은 디자이너가 의문을 가지는 부분을 경험담을 통해 풀어주셨습니다. 그리고 코딩을 공부하면서 도움이 되었던 툴과 학습 방식을 공유해주셨습니다.
마지막에 건축가로 비유해주신 말이 매우 인상 깊었습니다.
디자이너도 제품을 만드는 사람이기에 자신의 생각과 설계가 담긴 산출물이 어떤 원리로 어떻게 구현되는지 아는 것과 모르는 것은 초기 시안 단계부터 완성까지 과정 속에서 큰 차이를 가질 것이라 생각됩니다.
윤성권(acciio)
언제 내가 가장 힘들어했었나? 웹 디자인을 처음 접할 때였다. 포토샵에선 '12pt=12px'이었는데, 개발자가 자꾸 '12pt=16px'이라 했다. 측정 방식의 차이 때문에 초기에 많은 어려움을 가졌다.
도량에 대해서 이야기를 하고자 한다. 예부터 이어져온 다양한 측정 방식이 있다. 환경과 상황에 따라 다양하게 발전 해온 측정 방식들은 현시대의 디지털 개발환경에도 이어졌다.
서양에선 예부터 '12'를 좋아했고 12진법을 많이 사용했다. 12는 많은 약수를 가졌다.
72 dpi의 최초 매킨토시부터 ms의 승부욕으로 시작된 더 높은 해상도에 대한 이야기.
12pt=16px의 이유는 css에서 96px=72pt로 나온다. 포토샵에서 '12pt=12px'였던 이유는 도큐먼트 설정 시 72 dpi로 세팅을 했었기 때문. 96 dpi로 설정하면 12pt=16px로 나오게 된다.
아이폰이 나오면서 모바일 시대가 도래하고 해상도의 기준이 바뀌었다. 그리고 아이폰 레티나의 등장으로 이는 더 심해졌다. 이에 따라 기업의 디바이스 발전에 대응하는 기준과 가이드들을 만들기 시작했다.
didot 이야기. 제작자의 좀 더 완벽한 인쇄를 위한 열정은 기술을 개발하게 되는 단계까지 가게 됨. 표현을 위한 기술의 개발.
각자의 철학에 따라 기술의 방향은 달라짐. 모두를 위한 구글의 폰트와 최고의 모습을 위한 애플의 폰트.
기술이 먼저일까? 표현이 먼저일까?
인쇄자가 인쇄 기술을 알듯 우리는 무엇을 아는 게 중요할까? 개발자와 커뮤니케이션을 위한 최소 단위가 무엇인가? 답은 서로의 '도량'을 알고 이해하는 것이라 생각한다.
기술이 표현에 영감을 줄 때도 있고, 표현을 위한 기술의 발전도 있기에 둘을 구분시키는 건 무의미한 것 같다.
중요한 건 마음. 어디까지 할 것인가? 서로의 언어를 알고 접근하면 새로운 세상의 열릴지도..?
성권님의 프레젠테이션을 들으면서 개인적인 반성을 했습니다. 그동안 전 내가 왜 이 해상도로 작업하게 되었을까에 대한 호기심을 가지지 않았던 것 같습니다. 그냥 이렇게 나왔으니 이거에 따르고만 있었습니다. 이것을 모른다고 반성하는 것이 아니라, '모든 것에는 이유가 있다.'라는 개인 모토를 가지고 있는데, 이에 대한 이유를 알아보려고 하지 않았던 것에 대한 반성입니다.
성권님의 프레젠테이션은 즐거운 역사수업을 들은 기분과 함께 기초로 돌아가 깊은 생각에 빠지게 해주셨던 것 같습니다.
이정영(라인)
힘들게 고민하고 고민하여 완벽한 시안을 뽑은 것 같은데, 구현된 산출물을 보면 왜 이상할까?
디자이너가 새로운 걸 만들고자 하면 개발자는 기존의 것을 자연스럽게 가자고 한다.(갤 오가의 너구리 용병 로켓을 만들고 싶어 하는데, 이런 너구리는 세상에 없다며 동물원에서 볼 수 있는 너구리고 가자고 하는 상황)
그리곤 개발자는 커스텀을 거부하게 된다. 우리 디자이너는 커스텀을 하고 싶어 한다. 이를 위해선 개발자와의 갭을 줄이고 싶었다.
한 때 나의 디자인은 시안 png까지가 내 것이라 생각했다. 그리고 이게 이쁘면 되었다고 생각했다.
하지만 지금은 구현된 산출물까지 모든 과정이 나의 디자인이며, 이것이 현 ui디자이너의 올바른 자세가 생각한다. 하지만 디자인 검수 과정에서 오는 소모성이 심한 커뮤니케이션과 디테일을 위한 나의 행동이 디자이너와 개발자의 각자의 효율성 차이로 인한 마찰로 관계가 미묘하게 악화되는 상황이 자주 발생했다.
모바일 시대가 도래하면서 앱은 무조건 화면 전환이 있고, 때문에 디자이너는 인터랙션을 신경 쓰고 이를 담당하는 게 중요해졌다. 이런 이유로 프로토타이핑의 중요성을 대두되었고, 워크플로우에 추가되었다.
인터랙션 모션 개발을 위한 가이드를 개발자에게 전달할 때 각자의 모션 감의 차이로 커뮤니케이션의 어려움이 많았다.("슝~ 쇽~ 이런 느낌입니다!" , "????") 때문에 효율적인 전달법을 원했고, 그들의 언어를 알아보기 시작했다. 모션 구현의 원리를 알게 되면서 좀 더 효율적이고 명확한 전달이 가능해졌던 것 같다.
플랫폼마다 코드와 가이드가 다르다. 그리고 모든 개발자가 프론즈 엔드에 관심이 깊은 것이 아니다.
완성도에 욕심이 있다면 구현의 원리와 언어를 이해하는 것이 좋은 것 같다.
저는 게임 ui디자이너라 보통 ui 모션을 직접 작업하여 빌드에 적용하지만, 가끔 데이터 이슈 인해 개발자 분의 도움을 빌려 코드로 모션을 세팅해야 하는 경우가 있습니다. 이때 이야기를 나누면서 모션의 디테일을 설명하는데 가끔 "쇽~! 슝~!"을 쓸데가 있는데, 그러면 저도 민망하고 개발자분도 갸우뚱했던 적이 있었습니다. 대화가 '슝~'하고 끝나버린 상황이었죠. 그 뒤 이런 이슈가 생기면 직접 구글링을 하며 관련 모션 코드 예문을 보고 값을 전달하고 맞춰가니 확실히 알아가는 과정만 어려웠지.. 그 뒤는 명확하고 빨랐었습니다.
정영님 말씀처럼 디테일과 완성도를 챙기고 싶다면, 내 디자인이 구현되는 원리는 아는 것이 중요하다고 생각합니다.
많은 분들이 공감을 하셨는지 웃음소리가 계속 들렸던 유쾌한 프레젠테이션이셨습니다.
(세분 모두 감사했습니다~!)
2부 : 패널토크
개인적으로 패널토크를 좋아합니다. 개인적인 의견, 여과 없는 의견들을 들을 수 있는 시간이기 때문입니다.
패널토크는 1부에 프레젠테이션을 하셨던 디자이너분들과 개발자 네 분과 함께 주로 디자이너와 개발자의 협업 방식에 대한 이야기들을 나눴습니다.(소통, 작업방식, 이해관계 등)
각자의 입장에 대한 이야기와 협업 시 왜 이런 말을 했었는지 등을 이야기해주셨는데 주로 개발자 패널분들의 이야기를 많이 들었던 것 같습니다.
패널토크 자리가 [개발자] - [디자이너]로 구성되어 사회자 셨던 지홍 님이 대결구도는 아니니 오해하지 말라고 하셨지만, 개인적으로 은근 대결 구도로 느껴져서 몰입감이 높아져서(?) 좋았습니다.
패널토크를 다 듣고 나니 디자이너와 개발자는 작업 방식이 다를 뿐, 서로 같은 점이 더 많았던 것 같습니다. 서로를 몰랐기에 생겼던 답답함의 오해들이 많았던 것 같습니다.
패널토크는 Design Spectrum 신청 때 받으셨던 질문들을 추려서 주제화하여 진행되었습니다.
패널토크도 프레젠테이션과 마찬가지로 모두 녹음은 했지만, 내용의 큰 맥락만 추려서 공유드리겠습니다.
"개발자 입장에서 인상적이었던 디자이너와의 협업 경험"
- 이준원(네이버) : 과거 서로의 입장을 모르니 협업 과정에서 갈등이 많았다. 최근 제플린 같은 툴처럼 툴들의 발전으로 많이 해소된 편인 것 같다. 예전에 자신을 설득시키기 위해 디자이너가 설득을 위한 근거와 애플의 휴먼 인터페이스 가이드를 공부하여 오신 적이 있었는데, 매우 인상적이었다. 개발자들은 특성상(?) 가이드에 꼼짝 못 하는 편이다.
- 김태호(레진) : 서로 언어와 툴이 다르기에 이에 대해 이해해주는 게 중요한 것 같다. 머티리얼 디자인이 생겼을 때 서비스에 이를 적용하는 일이 생겼는데, 가이드를 보며 서로 제안하고 수긍해가며 함께 만들어갔던 협업했던 경험이 인상 깊었다. "왜 이렇게 해야 하나요?"보단 "그래요? 이렇게 해봐요."하며 서로를 존중했고 결과적으로 좋은 산출물을 만들 수 있었던 것 같다.
- 조은(우아한 형제들) : 실무 초창기 서로의 입장에서의 디테일을 찾다 보니 오는 커뮤니케이션의 어려움이 많았다. 1개를 수정하면 3개의 이슈가 터져 나오는 상황도 존재. 처음으로 디자이너 분과 술을 마셨다.
입장 차이에 오는 반대의 케이스가 많았다. 수정의 범위를 명확하게 정의하면서 작업했던 것이 좋았던 것 같다.
- 정원희(프리랜서) : 항상 프로젝트를 진행하면 개발자와 디자이너의 대결구조가 되는 경우가 많았던 것 같다. 제로섬 게임을 하게 되는 경우가 많았다. 디자인이 좋아지면 개발 부하가 커지고, 디자인이 나빠져야지 개발 입장에서 수월해지는 경우.
디자이너분이 디자인을 하시면서 구현 이슈에 대한 질문을 계속 해온 적이 있었는데, 이때의 경험은 디자인이 끝나고 개발을 하는 것이 아니라 함께 만들어간다는 느낌을 줘서 인상 깊었다.
"개발자들 입장에서 디자이너분들이 해줬으면 하는 것"
- 정원희(프리랜서) : 디자이너마다 커뮤니케이션의 온도 차이가 있었다. 같은 요구도 어떤 식으로 하느냐에 따라 다르다. 냉담한 반응은 상대로 냉담하게 한다.
- 조은(우아한 형제들) : 개발 시 상항을 고려해줬으면 하는 것. 이에 대한 정리. 구현하는 개발자를 한 번쯤 고려해줬으면 하는 것. 요구 사항을 해주고 싶어도 정말 해줄 수 없는 상황들이 생각보다 많다.
- 김태호(레진) : 상황에 따른 가이드가 이슈 발생 전 고려돼서 왔으면 하는 것.(ex/버튼 속 레이블이 길어지는 상황 때 어떻게 처리할 것인가?)
- 이준원(네이버) : 피드백에 대한 반영시 QA이전에 와주셨으면 QA 들어가기 전이었으면 가능한 것도 QA 들어가고 난 뒤에는 매우 힘든 경우가 많다. 피드백은 QA전에 해주시면 더 잘 반영해줄 수 있다.
"디자이너 입장에서 개발자들이 해줬으면 하는 것"
- 이정영(라인) : 디자인 사이드에선 개발에 대한 공부를 하는 추세이다. 하지만 개발 쪽에선 디자인 사이드에 대한 관심이 상대적으로 부족해 보인다. 함께 만들어 가는 것인데, 이에 대한 피드백이 아쉽다. 서로에 대한 관심이 필요한 시점. 서로에 대한 의미있는 리액션이 중요한 것 같다.
- 정희연(스포카) : 개발자가 안된다는 것들. 코딩 공부를 해보니 정말 안되더라. 하지만 일정이나 이런저런 이유로 그냥 안된다고 하면서 사실은 할 수 있는 경우도 있다. 이런 경우 디자이너의 노동도 생각해줬으면 한다.
- 윤성권(acciio) : 디자이너는 왜 안되는지 알고 싶어 한다. 보통 안 되는 이유를 설명해주지 않는 경우가 많은데 해줬으면 한다. 디자인도 디자이너의 많은 노동이 담겨있다. 때문에 안될 땐 이에 대한 합당한 이유를 알고 싶다. 서로 알려주고 배우는 태도가 중요한 것 같다.
"디자이너 요구들 중에 대표적으로 안 되는 것들."
- 이준원(네이버) : 인터랙션에 관련된 요청은 QA전에 해주시는 게 좋다. 예전에 QA 중에 레퍼런스를 주시면서 특정 인터랙션을 해달라는 요구를 받은 적이 있는데, 이걸 하려면 코드와 로직을 다 찾아봐야 한다. QA기간에는 정말 어려운 일이다. 특히 인터랙션 코드는 디자인 구현 코드들 중에서 상대적으로 복잡한 편이다. 디자이너분들이 심미적인 걸 중시하듯, 개발자도 코드의 정갈함에 많은 신경을 쓰고 있다.
- 김태호(레진) : 복잡한 레이아웃인 경우, 안드로이드 화면 크기들을 다 대응해줘야 하는데 이런 거에 대한 가이드가 없다면 상황이 어려워지는 경우가 많다.
- 조은(레진코믹스) : i와 안드로이드 구버전을 제외하곤 대부분 구현은 가능하다. 일정상의 문제나 구현에 비해 코스트가 큰 경우라 판단될 때 요구를 들어주기 힘든 경우가 많다.
- 정원희(프리랜서) : 대부분 일정상의 문제로 인한 것들이 많은 편이다. 애니메이션의 커스텀은 보통 코드가 더러워지는 경우가 많다.
"디자인 사이드에서 코딩을 공부하는 추세인데 개발자 입장에서 어떻게 생각하는가?"
- 정원희(프리랜서) : 디자이너가 코딩을 하더라도 코딩으로 프로젝트에 기여하는 건 어렵다. 툴의 차이는 크다. 하지만 구조를 알기 위한 코딩 공부는 적극 추천한다.
- 조은(우아한 형제들) : 디자이너가 코딩 공부하는 건 권장. 개발자이기에 디자인의 디테일을 잡기가 어려운 경우가 많다. 작업의 중점 또한 다르다. 개발자는 어떻게 하면 효율적이고 빠른 코드를 짜는가에 집중한다. 반대로 디자이너는 완벽한 화면에 대한 고민들을 한다. 때문에 화면과 애니메이션 디테일에 대한 갭이 큰 편.
디자이너의 코딩은 개발자의 입장보단 경영자의 인식이 더 중요하다고 생각한다. 만약 디자이너가 코드도 본다면 그만큼 일정을 더 줘야 하는데 그러지 않는 경우가 많은 편이다. 경영선에서 비용적으로 다가가니 안타깝다.
- 김태호(레진) : 디자이너가 안드로이드 레이아웃 코드를 짜는 건 딱히 효율적이라 생각하지 않는다. 하지만 디자이너가 xml를 직접 해보고 안 되는 거에 대한 감을 잡아보는 경험은 추천한다.
- 이준원(네이버) : 모션의 대한 레퍼런스를 자주 가져오는 편인데, 그전에 한번 구현 코딩을 경험해보는 걸 추천한다. 이에 대한 공수를 공감하고, 로직의 전달에 대한 이해도를 높여 협업의 효율을 올리는 건 좋은 것 같다.
"디자이너 입장에서 디자이너가 코딩을 하는 것"
- 윤성권(acciio) : 툴의 발전으로 인해 보는 것으로도 거의 이해할 수 있는 시대이다. 코딩을 해야 돼? 안 해야 돼? 에 대한 답은 없는 것 같다. 개인에 따르는 것이다. 대신 자기가 하고 싶은 게 있다면 그걸 할 수 있는 위치에 자신을 가져다 두는 게 실력인 것 같다. 어디까지 배우느냐 보단 난 무엇이 하고 싶고, 뭐가 필요한데.. 그것을 할 수 있는 역량에 자신을 가져다 둘 수 있느냐를 생각하는 게 중요하다.
- 정원희(스포카) : 디자인 시스템을 개발자에게 정확히 전달하는 정도가 적당하다. 구조를 아는 것. 그 외의 심화 학습은 본인에게 맞고 재밌으면 하는 것이라 생각한다.
- 이정영(라인) : 영어를 배우는 것과 비슷하다고 생각한다. 영어를 배운다고 바로 스피킹이 되는 것이 아니다. 하지만 배워가면서 알아가는 것들이 많다. '뭔가 만들어 보겠어!'보단 커뮤니케이션을 위한 방향이 맞다고 생각한다. 나의 산출물은 어디까지 인가를 생각하고 이것이 구현 까지라면 욕심을 가져볼 만하다.
사실 위에 작성한 것보다 소중하고 알찬 이야기들이 많았습니다. 글 쓰기 능력 부족으로 효과적으로 전달하지 못해 정말 아쉽습니다.
Design Spectrum은 디자이너들에게 무언가를 가르쳐 주려고 하기보단, 이야기를 공유하여 생각의 여지를 만들어 주는 것 같습니다. 그래서 이벤트가 끝나고 집으로 돌아가는 길에 이런저런 많은 생각 잠겼던 것 같습니다.
패널 분들이 리스크를 극복하기 위해 능동적으로 스스로 해왔던 노력들의 이야기를 들으며 많은 걸 배웠던 것 같습니다. 한편으로 그동안 이것저것 계획만 세워두고 여러 가지 이유들을 핑계 삼아 잘 실행하지 못하고 합리화시켜왔던 과거가 부끄럽기도 했습니다. 역시 말보단 행동인 것 같습니다.
오프라인 이벤트가 끝나고 가장 먼저 든 생각은 "재밌었다."였습니다.
Design Spectrum에서 오갔던 이야기들을 정말 편안하고 즐겁게 경청했던 것 같습니다.
3월 오프라인 이벤트가 기다려지네요.
출처: 윤성권님 프레젠테이션