디자이너가 개발 배우기 vs 개발자가 디자인 배우기
나는 왜 이렇게 살고 있는가
굳이 두가지 경우를 비교해야 할 이유는 없다. 그저 비전공자였던 내가 개발을 배우는 과정에서 종종 떠올랐던 생각을 적어보았다.
혹시나 오해를 방지하기 위해 말하자면, 이것은 어디까지나 평균적인 신입 개발자 혹은 디자이너로 일할 수 있을 정도의 실력을 쌓는데까지의 '배우기'에 대한 이야기일 뿐이지, '훌륭한' 디자이너와 개발자가 되기까지 필요한 노력을 이야기하는 게 아니다.
'니가 뭔데 이런걸 적냐'라고 궁금해 하실 분이 계실거 같아서, 간단하게 소개를 하고자한다.
첫 취업을 했던 2014년부터 지금까지 계속해서 스타트업에서 일하고 있고, 아마 앞으로도 그러지 않을까 싶다. UI/UX 디자이너로 커리어를 시작했지만 2019년부터는 본격적으로 프론트 개발자 포지션을 함께 담당해, 현재는 픗픗아카데미 (edu.ppss.kr) 서비스의 기획, 디자인, 프론트엔드 / 백엔드를 모두 담당하고 있다. 백엔드도 담당하고 있다고 했지만 잘한다고 한적은 없다. 사람이 없어서 필요하니까 하는 상태.
간단한 소개를 마쳤으니 얼른 본론을 시작해보도록 하자.
*2022년 3월 기준 업데이트 : 픗픗아카데미는 그로스쿨로 분사했고 도메인도 (https://groschool.kr/)로 변경됨. 필자는 현재 대체자산 투자 플랫폼 트위그 (https://twig.money/)를 개발하고 있음.
프로토타이핑을 위한 개발
2014년 작은 스타트업에서 app과 web의 UI 디자인을 담당하다보니, 프로토타이핑을 빠르게 구현해야 하는 경우가 많았다. 사실 누가 요구했다기 보다는 디자인을 설득하기 위해 스스로 필요했다. 디자인을 공부한 사람이 전체 인원 중 나 혼자다 보니, 인터렉션이나 트랜지션이 많은 디자인의 경우 다른 직군의 사람들에게 정적인 시안만으로는 설명하기가 어려운 부분이 많았다.
지금이야 Fuse나 Protopie 처럼 전문적인 프로토타이핑 툴들도 많고, sketch나 figma에서도 기본적인 화면 전환정도는 제공해주지만, 당시에는 맥북도 없어서 adobe illustrator나 photoshop으로 디자인작업을 진행하고, 필요한 경우 영상(!)으로 프로토타입을 제작하여 보여주기도 했다.
그러다보니 에셋작업이야 한번 해두면 되지만, 레이아웃과 요소들의 간격(gutter나 padding, margin)을 조절해야 하는 경우에는 전체 화면의 요소들을 일일히 재배열해줘야 했다. 특히 반복되는 요소들의 리스트인 경우 그 과정은 정말 끔찍했다.
다행히 전부터 포트폴리오 홈페이지를 만들면서 html과 css는 아주 잘 다루지는 못해도 어느정도 개념을 갖고 있는 상태였고, 좀 더 설득력있는 프로토타이핑을 하기 위해 계속 사용하다보니 웹 퍼블리싱에 대한 이해도도 점점 높아졌다. 이는 스스로의 작업에 대한 만족감을 높여줬음은 물론이고, 함께 작업하는 기획자와 개발자분들과의 의사소통에도 큰 도움을 줬다.
한 페이지를 작업하거나 특정 컴포넌트만 작업할 때에는 html과 css만으로도 어느정도 커버가 가능했다. 하지만, 여러 페이지를 작업해야 하는 경우, 똑같은 레이아웃 요소들을 페이지마다 전부 복붙해야 했고, 나중에 한 요소를 업데이트 하면 전체 페이지 파일들을 다 수정해야 했다.
이를 해결하기 위해 js(Javascript)가 필수적으로 필요해졌고, 이전부터 좀 더 디테일하고 다양한 인터렉션을 구현하기 위해 js의 필요성을 느끼고 있었던 터라 본격적으로 js를 공부하기 시작했다.
사실, html과 css는 적어도 문법적으로 그렇게 어렵지 않고, 사용자의 약간의 실수 정도는 브라우저가 커버해주는 경우가 많아 접근하기에 그렇게 어렵진 않았다.
물론 이는 처음 접근하기에 어렵지 않을 뿐이지, 실제 프로덕션 레벨로 사용하기 위해서는 접근성 및 브라우저 호환성 등 고려해야 할 부분들이 굉장히 많다. 'HTML & css are not programing language' 라며 html과 css를 무시하는 밈들이 많은데, 이에 대해서는 워낙 논란이 많고 좋은 글을 써주신 분들이 많아 더 이야기하지는 않도록 하겠다.
하지만 js의 경우 본격적으로 프로그래밍의 기본이 되는 요소들 - 변수, 반복문, 조건문, 타입 등- 을 다루어야 하다보니 처음부터 개념적으로 숙지해야할 것들이 많았다. 하지만 그럼에도 워낙에 체계적이고 기본부터 잘 설명해주는 곳들이 많아, 시간을 쏟더라도 내가 어디까지 배웠고 이게 어떤 개념과 어떻게 연결되는지 알기가 어렵지 않았다. 무엇보다 논리의 영역이다보니,
무언가를 잘못하면 잘못되었다고 알려주거나 아예 동작하질 않기 때문에 내가 잘못했다는 것을 알 수 있다.
에러를 내뿜는게 얼마나 고마운 일인지 디자인을 공부해보기 전엔 잘 모를거다피드백을 혼자서도 얻을 수 있는가
디자인과 개발의 가장 큰 차이가 여기에 있는 것 같다. 디자인의 경우 아주 간단한 것을 디자인하더라도 이게 잘된 디자인인지 아닌지 '디자인적인 안목이 있는 다른 사람' 에게 보여주기 전까지는 알 수가 없기 때문이다.
당장 대학에서 기초전공 수업을 어떻게 진행하지는만 봐도 알 수 있는 부분인데, 디자인학과에서 이루어지는 수업들의 대부분은 약간의 이론을 배우는 시간을 제외하면 거의 모든 시간동안 피드백을 받는 시간들로 이루어져있다. 전공 기초과목인 드로잉부터 시작해서, 디자인의 기초가 되는 타이포그래피, 편집, 영상 등 모든 수업이 그렇다. 그만큼 피드백이 중요한 분야이고 그를 통해서만 성장할 수 있다.
구체적인 예를 들어 보자면, 드로잉 시간에는 '선 긋기'를 한다. 일단 단순하게 직선을 긋는다. 선을 긋는 것은 쉽다. 하지만 강약과 텐션을 유지하면서 유려한 선을 긋는 것은 매우 어렵다. 그렇다면 선을 수백 수천번 긋다보면 자연스레 선이 좋아질까? 물론 어느정도는 좋아질 수 있겠지만, 빠른 성장을 위해서는 그 전에 '어떤 선이 좋은 선인가'를 눈으로 알아볼 수 있어야만 내가 지금 그린 선이 좋은 선이지, 나쁜 선인지 알수가 있다. '아는 만큼 보인다'는 말 만큼이나 '볼 수 있는 만큼 그릴 수 있다'.
이는 단순한 선 긋기에서 끝나지 않고, 인체를 그리거나, 색을 배합하거나, 글자간의 간격을 보거나, 화면의 레이아웃을 잡는 등 모든 디자인 작업에 적용된다. '보는 눈'이 없는 상태에서는 좋은 디자인과 나쁜 디자인은 구별할 수 있더라도, 좋은 디자인과 덜-좋은 디자인을 구별하는 능력이 현저히 떨어질 수 밖에 없다.
따로 디자인을 전공하지 않더라도 디자인을 잘하는 사람들도 있다. 그럼 그 사람들은 혼자서 어떻게 성장한 것일까? 알고보면 그 사람들은 피드백을 받는 대상이 교수가 아니었을 뿐이지, 온라인 커뮤니티로부터든 클라이언트로부터든 수많은 피드백을 받으며 실력을 쌓아나간 경우가 많다.
이런 점에 있어서는 정말 '독학'으로만 디자인이나 개발을 공부한다고 했을 때, 디자인보다는 개발이 더 학습하기 용이하지 않은가 하는 생각이 든다. 혼자 공부하더라도 적어도 컴퓨터로부터 지속적인 피드백을 받을 수 있기 때문이다.
어쩌면 내가 중증 아싸라 주변에 피드백 구할 사람이 없어서 그렇게 느끼는지도 모르겠지만 암튼 그럼.
개발 또한 기본적인 학습 이후 더 나은 개발자가 되기 위해서, 혹은 더 좋은 코드를 쓰기 위해서는 디자인과 마찬가지로 피드백이 무척 중요하다는 걸 항상 느낀다. 지금도 회사에서 혼자 개발을 담당하고 있다보니, 개발 커뮤니티와 컨퍼런스 등을 통해서라도 다른 개발자들의 코드와 생각을 자주 접하려고 노력하고 있다.
여기까지 쓰고보니 급 피곤함이 몰려온다.
빠른 마무리
다음 글에서는 디자이너로써 효과적으로 개발을 공부하기 위해서는 어떻게 하면 될지, 개인적인 경험을 통해 써볼 예정이다. 혹시나 글이 기대가 된다면 좋아요, 구독, 알림설정... 이 아니라... 가 아니라? 그러고보니 브런치에도 좋아요 구독이 있었다 혼자 개발하느라 지친 이 사람을 위해 페북 친구 추가를 해주도록 하자. 댓글도 환영이다.
