디자이너/기획자 인기도 체크
나는 개발자들이 선호하는 사람일까?
IT쪽에서 일하는 앱/웹서비스 등등을 디자인하는 디자이너/기획자라면 일과시간 대부분을 부대끼며 사는 사람들이 개발자들일 것이다. 특히 요즘같이 개발자만능 시대에 한번쯤은 이런 생각 해봤을거다.
과연 나는 개발자들이 선호하는 디자이너/기획자 일까?
참고로 필자가 주 역할이 디자이너라서 체크리스트스가 "디자이너" 위주로 되어 있는데, 저걸 "기획자"로 대입해서 체크해봐도 크게 무리는 없을듯 하다. 지금까지 겪은 개인적 경험에 기반해서 개발자들이 선호할만한 디자이너의 업무방식 25가지를 골라봤다. 본인에게 해당하는 항목이 많을수록 당신은 개발자들이 같이 일하고 싶어하는 디자이너/기획자일 확률이 높다. 본인에게 해당하는 항목이 10개 미만으로 나오는 디자이너라면, 솔직히 앱/웹서비스쪽 디자이너로 일하는게 괜찮을지 한번 고민해볼 필요 있다고 생각한다.
1. 디자인 들어가기 전에 그냥 종이에다가 대략적인 레이아웃 스케치해서 개발자들이랑 상의해본 후에 디자인 작업에 들어간다.
가끔 본인이 디자인 구상한다고 금쪽 같은 시간에 한 몇일씩 자기 혼자 고민고민하면서 인비젼같은 곳에 멋드러지게 프로토타입으로 얹혀서 개발회의 하자고 하는 디자이너들이 있다. 일단 본인은 그거 하고 있을 시간에 개발자들은 할일이 없기도 하고, 저렇게 가져가면 이런저런 이유로 어차피 본인이 기획한 디자인 시안은 이미 저 안드로메다로 날라가 있을거다.
그럴 시간에 아예 처음부터 개발자들이랑 종이나 칠판에 레이아웃/플로우를 쓱삭쓱삭 그려보고, 초기 버전에 꼭 포함시킬 기능들 & 나중에 해도 되는 것들에 대한 견적을 먼저 뽑은 다음에 디자인작업을 시작하면 개발자들도 그 시간에 미리 필요한 밑작업들을 진행할 수 있다.
2. 사용 플로우 전체를 모두 짠 후에 한번에 모든 디자인 페이지를 정확히 디자인해서 넘겨주기 보다는, 각 기능단위/페이지단위별로 마무리 될 때마다 개발자에게 넘겨준다.
개발자들이랑 상의하기도 전에 자기 혼자 나르시시즘에 빠져 온갖 플로우/세부 디자인 완벽하게 잡아놓은 디자인 시안을 던져주면 보통 개발자들은 멘붕에 빠질 가능성이 높다. 분명 과스펙이거나 아예 구현이 불가능한 인터페이스도 있을거고, 무엇보다도 프론트에 얹히다 보면 디자인단계에서는 몰랐던 이슈나 더 효과적인 아이디어가 생겨서 디자인을 다시해야 하는 경우가 다반사다.
그러기 보다는 각 플로우 청크별로 디자인 시안이 나오는대로 전달하는게 훨씬 효율적이고 개발자도 작업하기 더 수월하다. 물론 개발속도가 빛의속도인 개발자랑 일할경우 마감시간에 쫓기는 작가같은 압박감을 느끼며 일할수도 있다.
3. 디자인 파일 전달할때 개발자에게 선호하는 네이밍 형태를 꼭 물어본다.
코딩을 한번이라도 해본 사람이라면 대략 알겠지만 우리가 프론트에서 보는 각종 이미지, 아이콘들은 해당 컴포넌트 파일들이 서버 어딘가에 업로드 되어 있고 프론트에서는 그걸 호출해주는거고, 코드에는 그 파일명을 콜하는 부분이 들어간다. 그래서 이걸 효율적으로 하기 위해 개발자들은 자기들 나름의 파일명 정하는 규칙이 있다.
디자이너들은 이걸 미리 개발자한테 물어보고 각 컴포넌트별 명칭을 이 규칙에 맞게 정해주는 습관이 필요하다. 그걸 무시하고 자기 멋대로 파일명을 붙여서 전달해 버리면, 심한경우 수백-수천개나 되는 파일명을 개발자가 일일이 수정해야하는 노가다가 발생한다.
4. 에러 페이지, Empty States 같은거 빼먹지 않고 꼭 챙겨서 디자인해준다.
초보 디자이너들이 가장 많이 실수하는건데, 꼭 보이는 페이지만 디자인해서 넘겨주고 "난 이제 끝!" 하는거다. 일반적인 앱/웹서비스라면 Empty States라고 해서, "아무런 데이터가 없을 경우 뭘 보여줘야 하는가"에 관한 페이지가 정말 많이 발생한다. 운이 좋게도 고급 프론트 개발자들이랑 일할 경우 디자이너가 이런거 빼먹어도 개발자가 알아서 채워버리는 경우도 많은데, 그렇지 않을 경우 데이터가 없는 상황에서 텅텅 빈 제품을 맞이할 가능성이 높다. 예를들면 다음과 같은 상황이 대표적인 Empty States 이다.
- 소셜앱인데 아직 팔로잉 하는 계정이 없어서 타임라인에 보여줄 데이터가 없다.
- 액티비티 로그를 보여줘야 하는 대시보드인데 아직 활동로그가 없다.
- 쇼핑몰의 구매이력 페이지인데 구매 이력이 없다.
- 프로필 이미지가 보여야 하는 곳인데 해당 유저가 프로필 사진을 안올렸다.
...
또한 에러페이지 역시 마찬가지인데, 잘못된 링크로 접속된 상황, 예기치 못한 에러가 발생했을때, 로딩이 오래걸릴 때 등등 발생 가능한 수 많은 에러상황에 대한 디자인 시안을 알아서 기획해서 주는 디자이너가 되야한다.
5. 마진, 폰트크기, 색깔 사용 등에 어느정도 패턴이 있어서 디자인 시안에 빠진 내용이 있더라도 개발자가 알아서 유추 가능한 나름의 디자인 스탠다드가 있다.
이건 디자인 가이드라인이 아주 세세하게 정해져 있는 큰 기업들의 경우 (혹은 아예 디자인이 컴포넌트화 되어 있어서 디자이너는 그냥 그거 불러다 쓰면 되는...) 크게 상관없을 수 있지만, 그렇지 않은 스타트업의 경우 아주 중요한 내용이다. 디자이너가 각 컴포넌트 사이의 마진, 폰트 크기, 색깔 사용 등이 규정되어있지 않고 중구난방으로 디자인될 경우, 개발자 역시 중구 난방으로 개발한 결과물을 보게될 것이다.
그렇지 않고 나름 각 상-하위 박스마다 마진을 결정하는 룰이 있고, 각 색깔/폰트마다 사용되어지는 룰이 명확할 경우 개발자 역시 정의되지 않은 페이지를 개발할때 나름 이 룰을 따라서 개발하게 되고, 그렇게 탄생한 제품이 더 균형감 있게 된다.
6. 다크모드를 고려한 배색 디자인을 한다.
이건 요즘 다크모드가 유행하면서 새로 생겨난 현상이다. 다크모드의 경우 브라우저에서 지 맘대로 밝은색 어두운색을 반전시켜 버리는데, 로고나 아이콘 색깔, 폰트 색깔을 이거 고려 안하고 디자인하다 보면 개발자는 본인이 직접 다크모드 띄워보면서 알아서 색깔을 바꿔주는 노가다를 해야하는 상황이 발생한다. 애초에 다크모드를 고려해서 색이 반전되도 괜찮은 배색을 하는게 가장 현명하고, 그게 불가능하다면 적어도 다크모드에서 색깔을 바꿔달라고 개발자에게 따로 메모를 남기는게 좋다.
7. 전혀 새로운 디자인 형태는 시도하기 전에 개발자랑 꼭 상의해 보고 결정한다.
실험정신이 뛰어난 디자이너인데 그 실험적 디자인을 개발자랑 상의도 안하고 자기 마음대로 구현해서 던져주는 디자이너랑 일해야 한다면? 개발자들은 상상만 해도 끔찍할 거다. 통상 이런 공식이 성립한다.
"실험적인 디자인 = 날코딩이 필요한 디자인"
웹사이트를 디자인하는데 사이트가 스크롤하면 좌우로 넘어가다가 갑자기 상하로 스크롤이 획획 바뀐다던지, 그리드를 무시한 박스가 막 튀어나온다던지, 현란한 그래픽을 SVG 벡터로 만들어서 반응형은 개발자가 알아서 코드 계산해서 적용해야 한다던지...
실험적인 디자인을 하려면 그 전에 반드시 개발자랑 상의해서 서로 쌍욕나오는 상황을 만들지 않는게 중요하다.
8. 추가 기능을 결정할때는 이게 개발량이 얼마나 될지를 반드시 체크해서 우선순위를 보고 디자인한다.
디자이너로서 어떤 기능을 추가하고자 할때 당신에게는 고작 1 -2 디자인 페이지 분량일지라도 개발자에게는 수 많은 모듈을 손대야하는 기능일 수 있다. 예를들어보자. 어떤 소셜 앱에서 유저들에게 "인기 많은" 인플루언서에게 자동으로 "verified" badge를 달아주는 기능을 추가하고 싶다고 해보자. 디자이너 (혹은 기획자)한테는 그저 "일주일 동안 컨텐츠를 몇번 이상 올리고, 개별 컨텐츠별 라이크가 몇개 이상이 되고..." 이런 로직 정하고 배지를 나이스하게 디자인해서 넘겨주는 일이라면, 개발자의 경우 "저 로직별 데이터를 불러오려면 어떤 API가 필요하고, 어떤 쿼리를 짜야하고, 유저가 저 인플루언서 페이지를 보는 상황에서 발생하는 이벤트, 인플루언서가 본인 뱃지 페이지를 보는 상황의 이벤트..." 등등 수없이 많은 모듈을 건들여야 하는 복잡한 기능일 수 있다.
보통은 저런경우 개발자가 대충 머리 굴려보고 "아휴, 저거 지금 하려면 어려워요~" 하고 한문장으로 말하고 마는데, 가끔 디자이너들이 "아니 xxx개발자님은 맨날 뭐 하나 추가하려고 하면 맨날 어렵다는 말만 하세요?" 하고 불만을 토로하는 경우가 있다. 아주 위험한 상황이다.
9. 애니메이션을 과도하게 떡칠한 디자인 시안을 넘겨주지 않는다 (feat. 그걸 프로토타입 툴에 잘 얹혀놓고 개발자보고 알아서 개발하라고 던져주는 사람).
각종 트랜지션, 버튼 애니메이션을 과도하게 넣는 디자이너들이 종종 있다. 이걸 개발쪽 생각 안하고 마구마구 시전해서 프로토타입 툴에 입혀서 던져주게 되면 개발자가 뒤에서 칼을 갈고 있을 가능성이 높다. 사실 애니메이션은 사용성 측면에서 명확한 이득을 주는 상황이 아니라면 왠만하면 피하는게 맞다. 로딩 시간도 느려지고 코드도 길어지고, 집중도를 떨어뜨리는 요소가 되기도 한다.
그럼에도 불구하고 반드시 애니메이션이 필요한 디자인의 경우, 이미 모듈화가 되어 있는 애니메이션이라서 그냥 콜만 하면 되는 효과를 사용한다던지, 라이브러리에서 찾아서 적용한다던지, 그것도 아니면 개발자에게 사전에 물어본다던지 해서 결정하는 습관을 가지자.
10. 개발자가 딱 보고 디자인 의도가 뭔지 모를만한 디자인은 절대 하지 않는다.
가끔 개발자가 개발하다가 "디자이너님, 이건 여기서 왜 튀어나오는거죠?" 하고 물어보면, "네 그건 xxxx함을 잘 표현하기 위해서예요" 하고 대답하는 경우가 있다. 일단 이 상황에서 "개발자"라는 종족이 저걸 물어볼 정도면 일반적인 사용자들도 분명 어색해할 수 있는 느닷없는 출현이라는 뜻이다. 또한, 이런 의도가 불분명한 디자인이 많아질 경우 개발자 역시 혼란스럽기 때문에 예상치 못한 버그가 속출할 수 있다. 뭔가 장문의 부연설명이 필요한 디자인이라면 이미 실패한 디자인이다.
11. "반응형"을 꼭 고려한 디자인을 한다.
요즘은 화면 사이즈가 수백개에서 보이는 시대에 살고있다 보니 디자이너들이 이걸 다 고려하면서 완벽하게 디자인하는건 구글/애플급 초거대기업 아니면 거의 불가능하다. 따라서 훌륭한 디자이너는 "반응형"을 고려해서 디자인을 한다. 여기서 많이들 오해하는게 있는데, 반응형을 고려한다는게 각종 스크린상황에서 디자인을 다 기획한다는 뜻이 절.대.로. 아니다. 오히려 그건 정말 개발자에게는 극혐인 디자인이 된다 (웹사이트의 경우 미디어 쿼리를 세세하게 다 날코딩 해줘야한다는 뜻이니...).
반응형을 고려한다는건 디자인 레이아웃이 스크린사이즈가 늘고 줄어도 커스톰 코딩이 필요없이 "반응"하는게 가능한 디자인을 말한다. 예를들면 데스크탑에서는 테이블 형태의 레이아웃이 갑자기 박스 형태로 바뀌어야 한다던지, 디자인 컴포넌트 정렬이 바뀌거나 없어져야 한다던지, 전혀 새로운 컴포넌트를 출현시켜야 한다던지... 이런것들은 모두 해당 스크린 상황에서 커스톰 코딩을 요구하는 디자인들이다.
이런게 나쁘다는 뜻은 아니고, 디자인할때 저런 가능성을 최대한 줄이고 꼭 필요한 부분에서만 커스톰 코딩을 요구하는 디자인을 잘 한다... 이게 곧 "반응형"을 잘 고려해서 디자인한다... 라는 뜻이다.
12. 프론트 개발자가 백엔드 개발자에게 쌍욕 들을만한 과도한 API설계가 필요한 디자인은 왠만하면 시전하지 않는다.
통상 디자이너-프론트개발자-백엔드개발자 이렇게 구성된 팀의 경우, 디자이너가 이러이러한 기능 구현을 요청하면 프론트개발자는 서버에서 불러와야 하는 내용들을 백엔드개발자에게 요구하고, 백엔드개발자는 그걸 프론트에서 콜 할 수 있도록 API로 만들어준다. 이런 프로세스를 잘 알고 있는 디자이너의 경우 프론트 개발자가 과도한 수준의 API설계가 필요한 개발건을 가지고 백엔드 개발자에게 가야하는 상황을 잘 만들지 않는다. 백엔드 > 프론트 개발자에게 쌍욕이 전달되면 프론트 > 디자이너에게는 그 배가되는 쌍욕이 전달될 수 있음을 명심하자.
13. og:image, 메타데이터, 키워드, 파비콘 등등 웹사이트에 기본적으로 포함되야하는 내용들을 알아서 챙겨서 넘겨준다.
og:image는 이 사이트가 공유될때 표시할 썸네일 이미지들, 메타데이터는 이 사이트의 타이틀, description, 키워드, 서치엔진에서 보여줄 네비게이션 항목 등등을 말하며, 파비콘은 브라우저의 창 상단에 보면 보이는 아주 작은 로고 (모바일에서는 이걸 홈 스크린에 북마크 할 경우 이 파비콘이 이미지로 설정된다)를 말한다.
이런 디자인 요소를 개발자가 요구하지 않아도 알아서 잘 만들어서 전달하면 개발자에게 아주 사랑받는 디자이너/기획자가 될 수 있다. 왜냐면 개발자가 하기에 아주 귀찮은 작업이기 때문이다.
14. 폰트를 2개 이상 떡칠하지 않고, Handwriting 형태의 폰트는 대표님이 시키지 않으면 절대 시전하지 않으며, 왠만하면 구글 폰트에서 라이선스 제약이 없는거로만 사용한다.
사용하는 폰트가 늘어날수록 사이트의 로딩속도도 느려지고, 특히 Handwriting 형태의 폰트 (손글씨 스타일 같은거)는 폰트 파일 사이즈 자체가 극악한 수준이데, 이런걸 개발자에게 가져가면 난색을 표하는 경우가 많다. 폰트는 왠만하면 구글 폰트로 사이트에 코드 한줄이면 자유자재로 불러올 수 있고 라이센스 걱정도 안해도 되는 폰트로 디자인하는 습관을 가지자.
15. 쉐도우 떡칠된 디자인은 왠만하면 시전하지 않는다.
쉐도우가 떡칠되어 있으면 일단 각 오브젝트마다 마진 계산도 안맞고, 정렬도 틀어지기 때문에 쉐도우는 가급적 꼭 필요한 경우에만 주는게 좋은데, 꼭 필요할때는 개발자에게 이거 쉐도우까지 잡아서 파일 넘겨줄지, 박스 쉐도우는 니가 알아서 코딩할건지를 꼭 먼저 물어본다. 가끔 파일로 넘겨줄 경우 디자인 파일에 그루핑이 잘못되어 있어서 쉐도우가 잘리는 현상도 발생하는데, 그런거 고려 안하고 던져주는 디자이너라면... 미리 애도를 표한다.
16. 픽셀 기준으로 오브젝트 스케일 조정할때 소숫점 생길수 있는데, 반드시 정수로 조정해서 시안 넘겨준다.
특히 벡터기반 디자인툴을 쓰는 디자이너가 자주 하는 실수인데, 특정 오브젝트의 스케일을 퍼센티지로 조정할때 픽셀기반으로는 소숫점이 생기는 경우가 많다. 이걸 정수로 조정하지 않고 그냥 전달하게 되면 개발자는 보통 임의로 정수로 맞혀서 올리거나, 진짜 특이한경우 소숫점까지 정확하게 구현해버리는 개발자들도 있다. 전자던 후자던 간에 유저가 보기에는 눈으로 구분도 못하는 영역인데 여기에 소중한 개발력을 낭비하게 되니 이 얼마나 아까운 상황인가.
17. 검정색 아니고 나만의 의도가 있는 검정같아 보이는 회색을 쓸 경우 hex code를 꼭 말해준다 (흰색도 마찬가지).
애플 이후로 많은 디자이너들이 검정색 같은 짙은 회색 혹은 흰색 같은 옅은 회색으로 떡칠한 디자인을 시전하는 경우가 많아졌다. 그게 나쁘다는 뜻은 아니고, 그런 디자인을 하면 꼭 hex code를 개발자에게 명시해 줘야 한다. 그렇지 않으면 개발자는 눈으로 봤을때 걍 검정색이니 #000000 적용해 버릴텐데, 나중에 디자이너가 이걸 보고 "아니 개발자님 제가 이거 일부러 #151515로 한건데 이걸 그냥 검정색으로 해버리면 어떡하나요~~" 이러고 앉아있으면 개발자들 뒷담화에 중심에 설 수 있다. 굳이 중요한 의도가 있지 않고서야 검정계열이면 그냥 #000000을, 흰색계열이면 #FFFFFF을 쓰는게 개발자도 편하다.
18. 그루핑 (혹은 폴더링)으로 떡칠하지 않는다.
초보 디자이너가 많이 하는 실수중 하나인데, 자기 디자인파일을 잘 정리한다고 오브젝트들을 강박적으로 폴더링하는 경우가 있다. 예를들면 A랑 B를 그룹지었고, 이걸 또 C랑 그루핑하고, 이런애들 3개를 또 같이 그루핑하고... 이렇게 그루핑으로 떡칠된 오브젝트를 디자인파일로 내보낼 경우 소수점 마진이 계속 잡힐 수 있다.
이게 왜 문제냐면, 이미지로 된 아이콘인데 이게 어딘가 정렬이 안맞아 보이는 현상이 발생할 수 있는데, 디자이너는 이게 지 실수임에도 불구하고 개발자한테 가서 "아니, 개발자님 여기 아이콘이 정렬이 안맞는데 이런 디테일좀 좀 신경써주세욧!" 하고 호통치다가 또 뒷담화의 대상이 되는 경우가 많기 때문이다.
19. 특정 오브젝트 정렬시킬때 개발자가 날코딩해야하는 상황 만들지 않는다.
간혹 특정 일러스트가 좌우 균형이 안 맞는 그림일 경우, 디자이너는 이걸 자기 눈으로 보기에 중앙을 맞춘다고 위치를 중앙에서 살짝 옆으로 커스톰하게 정렬시킨 후 개발자에게 던져주는 경우가 있다. 이런 오브젝트가 많아질 경우 개발자는 그걸 구현하기 위해서 매 오브젝트마다 날코닝을 해줘야 한다. 만일 디자이너가 그걸 고려해서 해당 일러스트의 좌/우에 여백을 조금 줘서 파일을 전달하면 개발자는 그냥 text-align: center; 한줄이면 끝날 디자인이다.
20. 수정 요청은 톡/이메일/전화/찾아가기 시전하지 않고 그냥 깃허브에 이슈로 남긴다.
디자이너가 뭐 수정하고 싶을때 마다 슬랙에서 톡을 보낸다던지, 찾아가서 귀찮게 하는 디자이너들이 있다. 그러면 개발자는 뭐 하고 있다가 중간에 흐름이 끊기기도 하고, 우선순위상 나중에 해야할 일이 치고들어오는 경우도 발생한다. 왠만하면 깃허브에 이슈로 남겨서 개발자에게 넘겨주면, 개발자가 알아서 우선순위 정하고 본인 개발일정에 넣을 수 있기 때문에 개발자가 좋아하는 디자이너가 된다.
21. 기기마다 디자인대로 나오는지 체크하는건 개발자 책임이 아니고 (디자이너로서) 내가 챙겨야 하는 일이라고 생각한다.
웹사이트의 경우 프론트 개발자들은 주로 개발도구에서 스크린 사이즈 바꿔가면서 기기별 디자인 체크하는데, 문제는 이게 실제 모바일 브라우저에서 다르게 동작하는 경우가 종종 발생한다. 개발자에게 사랑받는 디자이너들은 이걸 본인 책임으로 생각하고 알아서 개발자에게 이슈 티켓 만들어서 정리해준다.
22. 모달 (팝업창) 디자인은 정말 최선의 방법이 없을때만 시전한다.
모달로 뜨는 창은 사용성 면에서도 좋은 선택은 아니지만 개발적으로는 더 복잡한 선택이기도 하다. 특히 모달 상태에서 스크롤이 길어지는 경우 버그가 속출하거나 반응형 디자인이 무너지는 경우가 많다 (모달에서는 아예 구현이 불가능한 인터페이스도 많다). 디자이너로서 모달창은 정말 최선의 방법이 없을때만 시전하는 습관을 가지자.
23. 특정 이벤트가 발생한 이후의 디자인까지 알아서 만들어 던져준다.
한 이벤트가 발생하면 그 후속 페이지가 달라지는 경우가 있다. 예를들면 유저가 어떤 포스트를 삭제했을 때, 삭제한 후에 그 유저를 어느 페이지로 보내야 하는가와 같이 어떤 이벤트로 인해 해당 유저의 위치나 상태가 바뀌는 경우를 말한다. 이런걸 디자이너가 알아서 챙겨서 디자인을 전달해 주면 개발자가 아주 이뻐한다.
24. 얼러트 메시지, 벨리데이션 체크 메시지 디자인, 문구같은거 알아서 다 디자인해서 전달해준다.
23번이랑 비슷한건데, 유저가 패스워드를 잘못 쳤다던지, 데이터가 없는걸 입력했다던지... 등등 수 많은 얼러트 메시지, 벨리데이션 체크 메시지가 발생할 수 있는데 이걸 알아서 디자인해서 전달해주면 역시 개발자가 아주 좋아한다.
25. "이게 그렇게 어려운거냐"고 그 어떤 상황에서도 개발자에게 징징거리지 않는다.
사실 비개발자 입장에서 아주 간단해 보이는 기능 하나도 개발자 입장에서는 여러가지로 고려해야 하는 경우가 많은데, 이럴때마다 비개발자가 "이게 그렇게 어렵나용?" 이런말 듣는거 싫어하는 개발자가 참 많다. 그런 징징거림이 하나 둘 쌓이다 보면 본인이 어느새 개발자들 뒷담화의 중심에 서있게 된다. 보통 개발자가 난색을 표하는건 분명 내가 모르는 이유가 있는거니까 왠만하면 징징거리지 말고 다른 방법을 찾아보는 습관을 기르자.
사실 위에 있는 내용들은 필자가 약 5년간 스타트업에서 구르면서 대부분 겪었던 병크들의 모음이기도 하다. 물론 저 중에 상당수는 지금도 잘 못 지키고 있는 경우도 많다. 또한 저 반대 상황, 즉, 디자이너/기획자들이 선호하는 개발자들도 가능하다. 물론 상대적으로 개발자 몸값이 더 높기 때문에 그런 체크리스트는 가치가 별로 없다는게 문제지만 ㅜㅜ
글쓴이는 노마드태스크 (Nomadtask)라는 퀘스트 기반의 글로벌 마케팅 캠페인 플랫폼의 Co-founder 및 디자이너로 일하고 있다. 원래는 비즈니스를 전공하고 기획자로 일하다가 스타트업을 창업하고 본업을 스타트업 파운더+디자이너로 전향했는데, 그 과정에서 득템한 다양한 스킬들을 연재하고 있다.
노마드태스크 - https://nomadtask.com/
