엔지니어(개발자)와 일하는 방법

by Julie Zhuo

(페이스북 디자인 디렉터 / Product design director @ Facebook. )

원문 url 링크 : https://medium.com/the-year-of-the-looking-glass/a3163ff1eced

(앞 문장은 똑같아서 생략) 엔지니어(이하 개발자)는 팀의 마법사이다. 몇 번만 기획서하고 디자인을 가지고 몇 번만 탭을 하면 짜잔! 실제 동작을 하게 되니 말이다. 디자이너인 당신은 그들의 박식하고, 자기 비판적이며, 스크립트친화적 방식을 어떻게 맞춰나갈 수 있을까? 계속 읽어 보시길.

개발자들은 아이디어를 실제로 구현하는 사람들이다.

개발자는 훌륭한 제안을 실현시켜준다. 그리고 이것은 절대로 잊어서는 안되는 사실이다. 당신 회사 직원이 5명, 500명, 5000명이 있다고 해도 엔지니어는 ‘리소스’ 취급 받아서는 안된다. 그들은 근본을 만드는 사람들이고, 당신의 제품이 동작하도록 만드는 모든 것들을 책임지고 있는 사람들이다. 일이 되게 만드는 사람들이고, 그것도 빨리 되게 하는 사람들이다. 탄탄하고, 믿음직스럽고 100만, 1억 유저에까지 확장할 수 있도록 도와준다. 일반적으로 혁신하고, 새로운 알고리듬으로 기술을 발전시키며, 수십조의 입력이 가능하도록 만들고 그것이 의미를 가질 수 있도록 만들어 주는 사람들은 다름아닌 개발자들이다.

그러니까 정리하면 개발자들은 쩐다는 말이다.

말하자면 이런 거지.

뭔가 만들어 보고 싶다고? 그럼 개발자 한 두명만 설득하면 된다.

진짜로, 이거면 된다. 전설적인 제품에 대한 이야기는 늘 이런 식으로 시작된다. 친구 두명이 모여서 주말에, 맥주 몇캔 따고 해킹하다가 PM이 합류하고, 매니저가 합류하고. 기본적인 블록부터 만들어 나가게 된다. 아이디어, 디자인, 그리고 적용. 이런 식이다. 이 때문에 우리는 개발자와 가까이 지내야 하는 것이다.

다른 시나리오를 하나 들어볼까? 제품의 작은 부분이 당신을 짜증나게 만든다. 정말 짜증이 나서, 견딜 수가 없고. 디자인의 ‘그 부분’이 잘못된 것 같아서 견딜 수가 없게 만든다. 어떻게 해야 할까?

A. 다음 팀 회의 시간에 발제해서 할 일 리스트에 올라가고 우선순위 정해지고 또 뭐 이거저거해서 다른 (아직 입사도 안한) 개발자가 할건데 그 사람은 이 일 하기 전에 해야 할 일이 또 있고….

B. 개발자와 친하니까, 그사람 책상에 간다. 5분 정도 수정해달라고 말하고, 수정한 거 커밋하는 거 보고 자리로 온다. (어쩌면 80년대 커버 밴드용 티셔츠 디자인 같은 걸 해줘야 하겠지만.. 일러스트는 잘 하잖아요?)

어떤 버전으로 가면 더 빠르게 수정할 수 있을까?

더 말할 필요 없겠지.

함께 일하는 개발자가 좋은 디자인의 가치를 알아준다면, 일은 훨씬 쉬워진다.

함께 일하는 개발자가, 목업에서 채울 수 없는 빈칸을 알아서 채워주고, 하나 하나 물어보지 않고 알아서 잘 한다면? 마진 값 다 안물어보고 포토샵 열어서 마진 잰 다음 알아서 입력한다면 정말 끝내주겠지. 심지어 디자인을 더 좋게 만들 수 있는 제안을 던지기까지 한다면? 만약 첫 번째 디자인 적용 버전이 나왔는데, 시안하고 다른 게 하나도 없다면 정말 그 개발자, 정확하고 디테일한 놀라운 사람이겠지.

그런 개발자하고 어떻게 일하냐고? 뭐, 채용하면 되겠지. 할 테면 해보시라. 쩌는 UI 개발자는 정말 구하기 힘드니까.

아니면 당신이 직접 개발자에게 좋은 디자인을 알아볼 수 있도록 교육을 하는 방법이 있다. 어떻게? 시안을 그냥 던지지 말고, 당신이 뭘 하는지 설명해보시라. 작업물의 가치와, 제안하는 디자인이 왜 만들 가치가 있는지 설명해라. 시안과 정확하게 일치하는 빌드가 왜 가치가 있는지 알 수 있도록 해 줘라. 뭔가 구리다고 할 때에는, 무슨 생각으로 그런 말을 하는지 알 수 있도록 해 줘라.

여기선 관계 형성이 중요하다. 사람들은 그들이 중요히 여기는 가치를 사람들과의 대화를 통해 바꾼다. 구식이지만 효과적인 방법이다(“이 전략에 대해서는 뉴요커의 “느린 아이디어"란 글이 잘 설명해주고 있다).

상당수 개발자들은 디자인 디테일을 보는 눈이 없다. 하지만 많은 개발자들은 UX를 중요하게 여기고 더 좋게 만들고 싶어한다. 모든 개발자들이 UI 디테일 작업을 좋아할 거란 말은 아니다. 하지만 적어도 왜 해야 하는지 아는 건 도움이 된다.

디자인을 잘 이해하고 가치를 볼 줄 아는 개발자라면, 디자인이 좀 더 빠르고, 더 훌륭하게 적용될 것이기 때문이다.

개발 제한사항을 미리 알고, 시간 절약하자.

"만약에"로 시작해서 상상하기란 참 쉬운 일이다. 만약 우리가 당신의 생각을 읽고, 원하는 걸 정확하게 알아내서 보여줄 수 있다면? 이 버튼을 눌렀을 때 파티클 효과와 불이 번쩍거리게 할 수 있다면?

기술적/시간적 제약을 미리 알지 못한 채 답 없는 디자인과 사랑에 빠지는 실수를 범하지 마시라(승부를 걸어볼만한 디자인이라고 해도, 제약사항을 알아두는 작업은 더 탄탄한 근거를 만들어 줄 것이다). 최악의 경우는 될 일도 없는 디자인에 공을 들여서 완성까지 해 버리는 일이다.좋은 디자이너는 적고, 문제는 많다. 이런 비효율에 버릴 시간은 없다.

따라서 뭔가 끝내주는 아이디어가 떠올랐지만 뭔가 좀 찜찜하다면 바로 개발자에게 물어보시라.

물론, 이 반대의 경우도 말이 된다.

지금 디자인이 얼마 정도 완성된 상태인지 알려줘서, 개발자의 시간도 절약하자.

디자인을 넘기긴 했는데, 적용되고 나야 좀 멀쩡할 지 아닐지 모르겠다면, “변경될 수 있어요”라고 명확하게 알려줘라. 개발자들이 밤새서 디자인 다 입혀놨더니 다음 날 아침에 “헐 오늘 디자인 다 엎어짐요 ㅋ” 라는 메모 받는 것 이상으로 열받는 일은 없다. 공들여 만든 최종 버전의 코드를 다 지워버려야 할 지도 모르니까.

물론, 한번 쓴 코드를 절대 지워버리지 않는 개발자는 없다. 코드 갈아 엎는 건 디자이너나 마찬가지로 업무의 일부니까. 좋은 개발자는 여러분의 작업 과정이 개판이라는 것을 이해하고, 실제 돌아가기 전까지는 좋을지 아닐지 확신도 없으며, 모든 건 변경될 여지가 있다는 걸 이해하고 있다. 디자인은 갈아엎히기 마련이다. 하지만 어떤 부분이 변경될 여지가 있고, 어떤 부분이 확정된 버전인지 확인해 주는 일은 개발자가 코드 설계하는 데 큰 도움이 된다.

디자인 한 대로 앱이 나오게 하는 최선의 방법은 개발자와 가까이 일하는 것이다.

말하자면, 정말로 디자인 적용할 때 가까이 있어 보시라. 같은 공간에서 모두가 같이 호흡을 맞추고 있다면, 정말 일이 쉬워진다. 이슈가 떠오르고, 해결되는 게 정말 빠르다.

제품이 만족스럽게 나오지 않았을 때 책임 전가하긴 참 쉽지. 내 시안은 쩔었는데 개발자가 제대로 못해서 그래. 그런 생각은 버리시라. 당신은 포토샵 시안을 가지게 되는 게 아니라, 사용자들이 만나는 실제 제품을 가지게 되는 거다. 뭔가 적용이 제대로 되지 않았다면 가만있지 말고 뭔가를 해라. 가서 적용 끝난 버전 보여달라고 하고 디테일 챙기고.. 실제 개발 하는 과정에서 개발자가 질문이 있는지 없는지, 옆에서 붙어있거나, 버그 발견하면 알려줘서 고칠 수 있게 해 주거나.. 

그렇다, 이건 당신 제품이다. 주인의식을 가져야 한다.

개발자들을 사로잡는 가장 빠른 방법은, 당신의 디자인 자체에 빠삭한 것이다.

'디테일 중심적이다' 라는 말을 디자이너에게 쓰는 건 사실 좀 웃긴 일이다. 사실 대부분의 디자인들이 굉장히 많은 부분을 빼먹어서 결국 개발자들에게 지적을 당하고 있으니 말이다.

개발자들의 디자인 영웅이 되고 싶은가? 당신의 디자인 솔루션에 완결성을 주고, 극단의 상황들을 고려해 보시라.

국제화 : 다른 언어로 표시되면 지금 디자인이 어떻게 보일까? 레이아웃에 위협적인 독일어의 긴 단어들이 들어간다면?

에러 화면 : 네트워크 에러가 생기거나, DB 크래시가 생기면 화면이 어떻게 보이나?

사용자 극단 : 정보가 하나도 없는 사용자라면 이 페이지를 어떻게 보여줘야 할까? 혹은 정보가 너무 너무 많으면 어떻게 할까?

트랜지션 : 화면 A가 B로 넘어가려면 정확하게 어떻게 동작해야 할까? 훌륭한 툴은 여기서 엄청 큰 도움이 된다. 자세한 사항은 "디자인(그리고 좀비 세계멸망)에서 살아남기"라는 글을 참고하시길.

이런 부분을 디자인하는 것은 이런 부분까지 모두 고려했다는 자부심을 줄 뿐만 아니라, 개발자가 효과적으로 시스템을 설계하고, 얼마나 시간이 걸릴지 측정하는 데도 도움이 된다. 이런 완결성 있는 디자인이 막판에 생각 못한 문제들로 엉망진창이 되는 문제를 막을 수 있다는 장점이 있다는 것은… 말할 것도 없다. 

그러니 선의를 가지고 디자인을 완결지으시라. 이상적인 케이스를 위해서만 디자인하지 말고, 시안의 판타지랜드에서 벗어나시라. 모든 개발자가 알고 있듯, 결국은 출시되는 제품만이 중요한 것이니 말이다.

-

* 역주

이것이 드디어 마지막이네요. 앞의 두 편과 묶어서 읽어보시면, 뭔가 와닿는 게 있지 않을까 생각됩니다. 

PM(기획자) : http://radiofun.tumblr.com/post/59066267101/pm

디자이너 : http://radiofun.tumblr.com/post/58410010027

엔지니어를 개발자로, PM을 기획자로 약간 꼬아 번역한 것은 그게 좀 더 와닿을 것 같아서 썼습니다만, Julie Zhou가 정확하게 개발자와 기획자를 염두에 두고 쓴 글은 아닙니다. 사실 디자이너도 마찬가지고요. 어쨌든 우리 입장에서 제품 개발의 세 기둥은 (일반적으로) 기획-개발-디자인이니 여기에 맞춰서 읽어주시면 어떨까 싶네요.

앞으로도 좋은 글 소개할 기회가 있으면 좋겠습니다. 졸렬한 번역 읽어주셔서 감사합니다.

[출처] http://radiofun.tumblr.com/post/60279994804