스토리 홈

인터뷰

피드

뉴스

조회수 1567

슬라운드 브랜드 아이덴티티(B.I) 개발기 - 3화

[브랜드 기본요소 중 첫번째.  로고와 심볼만들기]지난 2화에서 슬라운드 브랜드 아이덴티티 개발방향설정을 위해 브랜드 기본요소들이 적용된 현상황을 진단하고,  슬라운드가 추구하는 브랜드 철학과 가치를 살펴봤습니다.이번 글에서는 앞서 설정한 개발방향을 토대로 탄생한 브랜드 기본요소들에 대해이야기해보려고 합니다.1. 먼저 가장 중요한 로고 개발 배경.로고는 브랜드의 이름표 입니다. 앞서 멋있는 말들로 설정한 브랜드 철학과 핵심가치들을  이 작은 이름표에 어떻게 녹여내면 좋을까요? 슬라운드 철학에서 도출해낸 디자인 키워드들슬라운드의 철학을 디자인적으로 풀어내는 단게!1) 첫번째 개발 포인트 : 힘을 너무 빼지도 말고 주지도 말고 '균형찾기!'단순히 예쁘고 보기좋은 이미지를 만들기에 앞서 슬라운드의 철학을 잘 꾀어낼 수 있는 이미지를 찾는 작업을 시작했습니다.사실 슬라운드의 브랜드 철학과 가치를 말로만 바라보면진지하고, 정직하고, 집념있고, 전문적인 이미지들로 가득차서 매우 무겁게 느껴져요.글자 그대로 진정성과 신뢰가 키워드니까 진지하게 궁서체? 장인처럼 볼드한 세리프로?여러 서체들로 슬라운드를 바라보는데 무언가 계속 거리감이 느껴졌습니다.로고 스터디의 흔적들.. 서체를 새로 만들어야 하나.. (방황중)진정성과 신뢰와 같은 가치는 이미지로 포장하고 '나 믿음직스럽습니다. 진지해요.'하고힘을 준다고 생기는 게 아닌 것 같았어요.오히려 힘을빼고 덜어내고 담담하게 나의 자리에서 이야기하는 모습,포장하고 꾸미기보다 본질에 충실한 모습 등이 슬라운드가 추구하는 진정성과 좀더 가깝게 느껴졌어요.그래서 볼드하고 장식된 느낌이 없는 산세리프 서체들로 다시 적용해보기 시작했습니다.힘을빼려는 의도가 있긴 했지만 또 너무 베이직한 느낌의 이미지가 되어버리니너무 약해보였어요. (슬라운드는 강한데..)그래서 또다시 산세리프냐.. vs 세리프냐..의 고민이 시작되었습니다.우리의 사장님들은 나에게 많은 시간을 허락해주지 않는데..조금씩 조급해지기 시작했어요..ㅋㅋ그러다 문득 중도를 택해보기로 합니다.바로 길산스(Gil Sans)! 모더니즘을 대표하는 서체 - 길 산스 / 창시자 에릭 길 (인상부터 강렬..)20세기 모더니즘을 반영한 대표적인 두 가지 서체가 있습니다.바로 독일의 푸투라(Futura)와 영국의 길 산스 (Gil Sans) 인데요.두 서체 모두 타이포그래피 역사에서 매우 중요한 서체들로 탄생 이후 현재까지여러 분야에서 많은 사랑을 받고 있지만, 전통성 계승이라는 부분에서 차이가 있습니다.제가 선택한 길산스는 전통과의 소통을 통해 탄생한 실험적인 서체입니다.영국을 대표하는 실험적인 서체  길산스!모던한 산세리프의 기하학적인 형태와 골격을 유지하고 있지만, 전통적인 세리프가 가지고 있는 모양과 비례를 그대로 적용한!즉, 산세리프의 간결함과 세리프의 우아함을 잘 조화시킨 '융합형 서체' 입니다.당시 유럽에서 유행하던 모더니즘의 일환인 '실험 정신'에 기인한 시도라고도 평가받고 있고,일반적인 모던서체들과 비교했을때, 보다 무게감 있는 비례임에도 불구하고투박하기보다 은은하고 우아한 느낌이 듭니다. 슬라운드 로고 중간단계슬라운드에 적용해보니 기본적인 산세리프보다 힘이 좀 더 생긴 느낌이에요.다만 길산스의 'S'에 세리프의 붓터치가 너무 많이 남아있어서 스르르 잠드는 편안한 인상을 담기 위해 좀더 부드러운 느낌으로 변형해서 적용했습니다. 1) 두번쨰 개발 포인트 : 기본과 기준의 차이!일단 길 산스로부터 중도의 균형점을 찾은것 같긴 한데, 그럼에도 불구하고 아직은 슬라운드에 밀착된것 같지 않았어요. 특히 'S'를 부드럽게 변형하고 나니 뭔가 힘이 부족한 느낌..슬라운드는 베이직 하면 안되는데.. 좀더 고집이 필요해.. 매트리스도 고밀돈데..라며곰곰히 생각해다가 문득  '기본과 기준'이라는 단어가 동시에 떠올랐습니다. 슬라운드를 구입해서 사용하는 고객들의 리뷰에서도 느낄 수 있듯이많은 고민을 통해 신중하게 구매한 슬라운드 매트리스가 '좋은 매트리스의 기준'이 되고 있다는 생각이 들었고 이 '기준'이라는 이미지를 좀더 강하게 표현해도 좋을 것 같았습니다.그래서 기준을 어떻게 시각화 할 것이냐는 고민하다가! (고민이 정말 끝이 없네요..)기본과 다르게 기준은 명확한 지점이 있다는 포인트에서 직관적으로 '기준점'을 만들어 보기로 했습니다.- image 04 - 기준점 뜻 (계산하거나 측정할때 기준이 되는 점 / 어떤 것을 할 때 기준이 되는 생각이나 사실)점과 동행하게 된 워드마트 로고그래서 최종적으로 슬라운드는 이름표에 점 (dot)을 데리고 다니게 되었습니다.슬라운드가 좋은 매트리스의 기준입니다!ㅋㅋ한편, 심볼이미지 보다는 워드마크 타입의 로고가 여러 터치포인트에 활용도가 높아서 워드마크타입을 메인 로고로 사용하기로 했지만, 웹이나 모바일의 프로필 썸네일에서는워드마크타입이 가독성이 떨어졌습니다. (인스타, 카카오톡, 페이스 북 등을 보면 작은 동그라미에 이름표를 넣어야 하죠)그래서 웹, 모바일, 원형 썸네일 등에 적용할 수 있도록 심볼타입의 모노그램을 추가로 계획했습니다.스르르 스탬프 도장 - 모노그램 심볼'기준'이라는 컨셉을 표현하기 위해 도장을 꽝 찍은 이미지에서 모티프를 얻었고,Slound의 'Sleep soundly'라는 부드러운 어감을 전달하려고 열린원의 형태를 적용했습니다.힘을빼지도 주지도 말고, 균형점 찾기! 라는 미션을 통해 슬라운드의 로고와 모노그램이 새로 탄생했습니다.다음화에서는 슬라운드 아이덴티티 컬러에 대해 이어서 소개할 예정입니다.(이미 어느정도 보여지긴 했지만.. 아직 포인트 컬러는 공개가 안되었어요!)파랑파랑+엄격군청 슬라운드가 좀 더 편안하고 진정성 있는 색을 보여주게 되는 과정을 기대해주세요. :)
조회수 1231

Android Wear 개발하기 - VCNC Engineering Blog

비트윈 팀은 지난달 비트윈에 Android Wear 앱 기능을 릴리즈했습니다. 즐거운 개발 경험이었지만, 힘들었던 점도 많았습니다. 어떤 과정을 통해서 개발하게 되었고, 내부 구조는 어떻게 되어 있는지, 신경 쓰거나 조심해야 할 점은 어떤 것들이 있는지 저희의 경험을 공유해보려고 합니다. 이 글을 통해 Android Wear 앱 제작을 고민하는 개발자나 팀이 더 나은 선택을 하는 데 도움이 되고자 합니다.Android Wear에 대해Android Wear는 최근 발표된 구글의 새 웨어러블 플랫폼입니다. 공개된 지 얼마 되지 않았음에도 불구하고 완성도 있는 디바이스들이 출시된 상태이며, 기존의 웨어러블 기기보다 기능과 가격이 매력 있다는 평가를 받고 있습니다. 또한, 2014 Google I/O에서 크게 소개되고 시계를 참가자들에게 나눠주는 등, 구글에서 강하게 밀어주고 있기 때문에 상당히 기대되는 플랫폼입니다.Android Wear의 알림 기능은 연결된 mobile1 기기와 연동됩니다. 예를 들어 메시지를 받았을 때 mobile과 wear에서 모두 알림을 받아볼 수 있고, Google Now와 연동하여 교통, 날씨 등 상황에 맞는 알림을 제공합니다.또, 여러 가지 앱들의 다양한 기능을 음성으로 제어하도록 하여 사용자에게 기존의 시계와는 완전히 다른 경험을 주고 있습니다.한국에서는 Google Play Store의 기기 섹션에서 구매가 가능합니다.Android Wear 개발하기Android Wear는 Android 플랫폼을 거의 그대로 사용하기 때문에, Android 개발 경험이 있는 개발자라면 아주 쉽게 개발을 시작할 수 있습니다. 비트윈에서는 구글의 80:20 프로젝트를 패러디한 100+20 프로젝트를 통해 개발을 진행하게 되었습니다. (하던 일을 다 해내면서 시간을 내어 진행한다는 의미로 100+20 프로젝트입니다. 하지만 가끔은 '20' 부분에 너무 몰입하여 0+20이 되기도 한다는 게 함정입니다...)Activity, Service 등 Android의 기본 component들을 모두 그대로 사용 가능하며, 손목에 찰 수 있는 크기의 화면에서 유용하게 사용할 수 있는 WearableListView, GridViewPager 같은 새 widget들이 추가되었습니다. 구글 개발자 사이트의 wearable training 섹션에서 자세한 안내를 볼 수 있습니다.비트윈의 아이디어비트윈 Android Wear 기능의 컨셉은, 항상 몸에 착용하는 Wear의 특징을 살려, '커플이 떨어져 있더라도, 항상 함께 있는 느낌을 주기' 였습니다. 그래서 아래와 같은 기능들이 기획되었습니다.Feel His/Her Heart (그대의 심장박동 느끼기): 상대방의 심장박동을 진동으로 재현해주기Where He/She Is (그/그녀는 어느 방향에 있을까?): 상대방의 위치를 나침반과 같은 형태로 보여주기 (안심하세요. 여러분. 방향만 알려주고 정확한 위치는 알려주지 않습니다!)Feel Memories (메모리박스): 언제든 추억을 떠올릴 수 있도록 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현하지만 이 아이디어들은 하루 만에 망하게 됩니다.메인 아이디어였던 심장박동 느끼기는 사용자가 요청하면 상대방의 시계에서 심장박동이 측정되어 사용자에게 상대방의 심장박동을 진동으로 재현해주는 멋진 기능이었습니다. 하지만 이 아이디어를 낼 때 심박센서가 탑재된 Android Wear 기기가 없었던 게 함정이었습니다.다음날 Android Wear Bootcamp에 참가하여 심박센서가 작동하는 삼성 Gear Live 기기를 사용해 볼 수 있었습니다. 결과는 충격이었습니다. 생각과는 달리 심박박동 측정 결과가 나오는데 10~20초가 걸리고, 그나마도 측정되는 동안은 올바른 위치에 시계를 차고 가만히 있어야 했습니다. 결국, 이러한 제약 때문에 사용자들이 실제로 유용하게 사용할 수 있는 기능이 될 수 없었습니다.그래서 계획을 수정하여 현실적으로 구현 가능한 기능들을 먼저 만들어 보기로 했습니다.목소리로 답변하기: 상대방에게 온 메시지에 Android Wear Framework에서 제공하는 음성인식을 이용하여 목소리를 텍스트로 바꾸어서 답장하기이모티콘 답변하기: 이모티콘을 사용자가 선택하여 이모티콘으로 답장하기비트윈 메모리박스: 비트윈의 기존 기능인 메모리박스(추억상자)를 Android Wear에서 구현처음의 원대한 계획에서 뭔가 많이 변경된 것 같지만, 기분 탓일 겁니다.내부 구현비트윈 Android Wear 앱은 크게 두 가지 기능을 가지고 있습니다. 하나는 상대방에게 메시지를 받았을 때, 메시지 내용을 확인하고 여러 가지 형태로 답장할 수 있는 Notification 기능이고, 다른 하나는 Wear에서 원래 Application의 일부 기능을 시작 메뉴를 통하거나 목소리로 실행시킬 수 있게 해주는 Micro App입니다. 해당 기능들의 스크린샷과 함께 내부 구조를 설명하겠습니다.우선 Notification 부분입니다. 앱 개발사에서 아무 작업도 하지 않더라도, 기본적으로 Android Wear Framework이 스크린샷 윗줄 첫 번째, 네 번째 화면과 같이 예쁜 알림화면과 Open on phone 버튼을 만들어 줍니다. 여기에 추가적인 기능을 붙이기 위하여 WearableExtender를 이용하여 목소리로 답장하기, 이모티콘 보내기 버튼을 덧붙였습니다.비트윈 Android Wear 스크린샷 - Notification둘째로는 Micro App 부분입니다. 여기에는 이모티콘 전송과 메모리박스를 넣었습니다. 이 부분은 일반적인 Android 앱을 만들듯이 작업할 수 있습니다비트윈 Android Wear 스크린샷 - Micro App화면을 보면 무척 단순해 보이지만 내부 구조는 간단하지가 않습니다. 연결된 화면들을 만들어내는 코드가 한곳에 모여있지 않고, 각기 다른 곳에 있는 코드들을 연결하여야 하기 때문입니다. Notification 하나를 만들 때에 Framework에서 만들어주는 1, 4번째 화면, Notification에 WearableExtender를 이용하여 덧붙이는 2, 3번째 화면, 그리고 다시 Framework에서 만들어주는 목소리로 답장하기 화면, 그리고 Wear 쪽의 Micro App을 통해 구동되는 이모티콘 선택 화면과 같이 여러 군데에 나누어 존재하는 코드가 연결됩니다.하나의 앱처럼 느껴지는 화면이지만 각각 다른 곳에 코드가 쓰여있습니다.그러면 이번에는 각 화면이 어떻게 연결되는지 알아보겠습니다.사용자가 상대방으로부터 받은 메시지를 Android Wear의 Notification으로 확인하고, 답장으로 이모티콘을 보내고자 하는 상황을 가정해 봅시다. 사용자가 Send Emoticon 버튼을 눌렀을 때 이모티콘 선택화면을 보여주고 싶은데, 이 행동에 대한 pending intent를 wear 쪽의 micro app이 아닌, mobile 쪽에서 받게 되어 있습니다. 이 때문에 아래의 표와 같이 mobile 쪽에서 pending intent를 받은 뒤 다시 wear 쪽으로 이모티콘 선택 화면을 보여주라는 메시지를 전송해줘야 합니다.이모티콘 전송 과정이번에는 메모리박스를 보겠습니다. 메모리박스도 단순한 화면이지만 mobile 쪽과 통신하여 내용을 불러와야 하므로 생각보다 해야 하는 일이 많습니다. Android Wear Message API와 Data API를 이용하여 데이터를 주고받아 사진을 화면에 보여줍니다.메모리박스를 보여주는 과정개발 시 신경 써야 하는 점개발하면서 주의 깊게 신경 써야 하는 점들이 있습니다.첫 번째로 코드 퀄리티입니다.Android Wear는 아직 성숙하지 않은 플랫폼이기 때문에 많은 사람이 받아들인 정형화된 패턴이 없습니다. 앞서 살펴보았듯이, 간단한 기능을 구현하려고 해도 상당히 복잡한 구조를 가진 앱을 만들게 되기에, 코드 퀄리티를 높게 유지하기 어려웠습니다비트윈 팀에서는 EventBus를 활용하여 코드를 깔끔하게 유지하려고 노력하였습니다. 이러한 문제를 해결할 수 있는 Guava의 Concurrent 패키지나, RxJava 등의 도구들이 있으니 익숙한 도구를 선택하여 진행하는 것을 추천합니다. 또한, 구글의 Android Wear 코드랩 튜토리얼의 내용이 매우 좋으니, 한번 처음부터 수행해 보면 좋은 코드를 만들 수 있는 아이디어가 많이 나올 것입니다.두 번째로는 원형 디바이스 지원 및 에러 처리입니다.처음부터 원형 디바이스를 신경 쓰지 않으면 마무리 작업 시 상당한 고통을 받게 됩니다. 원형 디바이스에 대한 대응법은 Android 개발자 트레이닝 사이트의 wearable layout 섹션에 자세히 나와 있습니다. 현재는 원형 디바이스를 처리하는 프레임웍에 약간 버그가 있지만, 곧 수정될 것으로 생각합니다.사용자 입력이 있을 때, 그리고 에러가 났을 때 적절하게 처리해주는 것은 제품의 완성도에 있어 중요한 부분입니다. Android Wear Framework에서 제공하는 ConfirmationActivity등을 활용하여 처리하면 됩니다.마지막으로 패키징입니다.자동 설치 패키징은 비트윈 팀에서도 가장 고생했던 부분입니다. Android Wear는 본체 앱을 설치하면 자동으로 함께 설치되는데, 앱이 정상작동하기 위해서는 몇 가지 까다로운 조건이 있습니다.build.gradle 의 applicationId 를 wear와 mobile 양쪽 모두 똑같이 맞춰야 합니다.Wear app의 AndroidManifest에 새롭게 선언한 permission이 있다면 mobile 쪽에도 포함해 주어야 합니다.기본적으로, 똑같은 key로 서명합니다. 다른 key로 sign 하는 경우는 문서를 참고해서 신경 써서 합니다.위 항목들은 아주 중요한 내용이지만 아직 문서화가 완벽하지 않으니 주의 깊게 진행해야 합니다.후기개발 과정에서 여러 가지 어려움이 있었지만, 무척 즐거웠던 프로젝트였습니다!우선 새로운 플랫폼에서 새로운 제품의 아이디어를 내고 만들어내는 과정이 많은 영감과 즐거움을 주었습니다.두 번째로는 Android Wear를 포함한 버전 출시 이후 구글플레이의 Android Wear 섹션 및 추천 앱 섹션에 올라가게 되어 홍보 효과도 얻을 수 있었습니다. 또한, 구글의 신기술을 적극적으로 사용하고자 하는 팀에게는 구글 쪽에서도 많은 지원을 해주기 때문에 도움도 많이 받았습니다.세 번째로는 기존의 Android 개발과 비슷하여 접근하기 쉬우면서도, 원하는 것을 구현하려면 상당히 도전적이어서 재미있었습니다.다만 조심해야 할 점은, 구글에서 적극적으로 밀고 있는 프로젝트라고 해서 다 성공하는 것은 아니라는 점입니다. 얼마만큼의 시간과 자원을 투자할지는 신중하게 생각하면 좋겠습니다.정리Android Wear는 새로운 기술과 플랫폼에 관심이 많은 개발자, 혹은 팀이라면 시간을 투자해서 해볼 만한 재미있는 프로젝트입니다. 하지만 완성도 있는 좋은 제품을 만들기 위해서는 생각보다 할 일이 많으니 이를 신중하게 고려하여 결정해야 합니다.끝으로 2014 GDG Korea Android Conference에서 같은 주제로 발표하였던 슬라이드를 첨부합니다.<iframe class="speakerdeck-iframe" frameborder="0" src="//speakerdeck.com/player/a1415af04644013234cf7a3f7c519e69?" allowfullscreen="true" mozallowfullscreen="true" webkitallowfullscreen="true" style="border: 0px; background: padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 750px; height: 563px;">구글의 튜토리얼 등에서 지칭하는 것과 마찬가지로, 이 글에서도 Android Wear와 연결된 휴대폰을 mobile이라 하겠습니다.↩
조회수 3214

열정 넘치는 디자이너, 바로 나

목차미국 HCI 석사 준비1. 필요한 정보 습득- UI/UX/Product/Interaction Design 관련 대학원 목록- 미국 대학원 지원 준비- 미국 대기업에 다니는 디자이너들에 대한 정보 수집- 미국 대기업이 원하는 디자이너의 역량- 디자이너가 알아야 할 툴들 공부2. 열정으로 닥치는 대로 공부 & 경험- Dribbble & Behance 보고 따라 해 보기- 혼자 하는 프로젝트, 포트폴리오 콘텐츠 만들기- 디자인 관련 밋업, 스터디, 컨퍼런스 참가- 남는 시간 활용 (아티클, 블로그, 유튜브 강의 등)- 기본적인 웹 코딩 배워놓기- 스타트업 또는 회사 경험대학원에서.. 그리고 인턴쉽 지원1. 학교 수업 및 프로젝트- 첫 학기의 승부- 배워보고 싶은 것들 vs. 배워야 하는 것들 vs. 아쉽지만 버려야 할 것들- 실시간 포트폴리오 업데이트- 교내 프로젝트 외 다른 도전2. 조교- 조교의 혜택과 이점- 지원할만한 연구실 목록 작성- 연구실 지원 준비- 열심히 일하기3. 인턴쉽 지원 준비- 회사들에 대한 지식 및 공부- Referral- 이력서 디자인- 포트폴리오 외 어필할 방법4. 경험담을 글로 풀어내기- 개인 블로그 시작- 디자이너에게 블로깅이란?5. 회사 지원 및 인터뷰- Google Analytics를 통한 방문자 분석- Recruiter와의 대화- Interviewer 파악하기- 실전짧은 소개현재 난 Georgia Institute of Technology에서 HCI (Human Computer Interaction) 석사를 전공하고 있다. 그 전에는 University of Michigan - Ann Arbor에서 Psychology를 전공했다. 지금 이 글을 시점에는 미국 Facebook에서 Product Design Intern으로 근무하고 있다. 많은 디자이너와 다르게 디자인 전공이 처음에는 아니었기 때문에 내가 여기까지 오기까지의 경험담을 정리한 글을 쓰고 싶었다. 최대한 다양한 정보를, 그리고 나만의 노하우를 적고 싶었고 100% 만족스럽진 않지만 그래도 누구에겐 도움이 됐으면 좋겠다. 이렇게 관심 가지고 나의 글을 읽으러 들어와 주셔서 매우 감사하다.미국 HCI 석사 준비1. 필요한 정보 습득UI/UX/Product/Interaction Design 관련 대학원 목록당연하게도 내가 제일 먼저 한 것은 미국에 있는 모든 디자인 관련 대학원 목록 정리였다. 캐나다와 미국에서 오랫동안 살아서 그런지 일단은 미국으로 돌아가서 공부하고 커리어를 쌓고 싶은 꿈이 있었다. 미국으로 돌아가 일을 하려면 미국 대학원을 나오는 게 제일 빠른 방법인 것을 알고 있었던 나는 서둘러 인터넷을 뒤지기 시작했다. 책상에 앉아 Google이나 Quora와 같은 곳에서 디자인 관련 석사 프로그램들을 마구 찾고 정리하기 시작했는데, 생각보다 리스트가 길어져서 추리는데 만해도 시간이 오래 걸렸다. 내가 정리한 종류별 학교 목록은 여기에서 볼 수 있다.찾는 도중 깨달은 점은 생각보다 UX 디자인 관련 대학원들이 너무나도 많다는 것이었고 최근 들어 많은 프로그램들이 개설된 것을 볼 수 있었다. 그리고 누구라 할 것 없이 그동안 배출한 학생들의 인턴쉽이나 취직 데이터를 보여주면서 어필하기도 했다. 나 같은 경우에는 HCI (Human Computer Interaction)라는 컴퓨터 공학, 디자인 그리고 심리학 외에 여러 학문을 융합한 학과가 너무나도 끌렸기 때문에 그쪽 관련 대학원들을 집중해서 봤다. 찾다 보니 카네기멜론, 조지아텍, 워싱턴, 미시간, 인디아나 등의 학교들이 유명하고 경쟁률도 상당히 높다는 것을 알게 되었고 하루라도 빨리 준비를 서둘러야겠다고 마음먹었다.미국 대학원 지원 준비일단 대부분의 학교들은 지원할 때 대학교 성적표, 포트폴리오 (optional인 곳도 있지만),  Statement of Purpose (자기소개서), GRE 점수, TOEFL, 교수님 또는 직장상사 추천서 등이 필요하다. 포트폴리오 같은 경우에는 웹사이트나 PDF 파일로 제출할 수 있으며 디자인 배경이 아닌 학생일 경우에는 지원하지 않아도 되는 경우도 있다. 자기소개서는 대부분 온라인 지원양식에 첨부파일로 넣거나 직접 Input field에 쓴다. 대게 왜 대학원을 지원하는 것에 대한 질문이고 나의 배경과 나의 꿈에 대해 설명하라는 경우가 많다. GRE는 학교마다 공지하는 평균 점수대가 웹사이트에 공지돼 있는 경우를 볼 수 있는데 솔직히 정말로 못 보지 않는 이상 큰 의미는 없는 것 같다. GRE는 Verbal, Quant 그리고 Essay로 나누어지는데 박사 지원을 하는 게 아닌 이상 Verbal은 155점만 넘으면 안전한 것 같고 Quant는 한국사람이라면 160점은 넘을 수 있기 때문에 오히려 조금이나마 플러스 요인이 되는 것으로 알고 있다. 마지막으로 Essay는 3.5점만 넘으면 웬만한 수준은 되는 걸 보여주는 것이기 때문에 괜찮은 것 같다 (분명 더 잘 보면 좋긴 하다). 나는 사실 GRE를 처음 공부할 때 해커스학원을 끊어보긴 했지만 한국식 문제풀이 방식에 익숙하지 않아서 그냥 학원을 취소하고 집에서 단어만 집중적으로 외웠다. 개인적인 생각으론 GRE 만점을 맞기를 목표를 하기보다는 적당한 점수를 목표로 한 다음에 포트폴리오나 자기소개서 같은 것에 집중을 하는 게 현명한 것 같다. TOEFL은 같은 경우에는 미국대학교를 졸업하면 면제를 주는 학교는 몇몇 있지만 카네기멜론 같은 경우에는 인정해주지 않기 때문에 어쩔 수 없이 시험을 봤어야 했다.여기서 자기소개서에 대해서 내 생각을 잠시 얘기를 하자면 난 그게 학교 측에서 꼭 읽어보는 중요한 서류라고 생각된다. 사람마다 각기 배경이 다르고 대학원에 지원하고 싶은 적절한 이유가 있으며 대학원을 통해 이루고자 하는 명확한 목표가 있기 때문에 학교 입장에서는 나에 대한 전반적인 정보를 한 번에 스냅샷으로 볼 수 있는 글이 된다. 나 같은 경우에는 지원서를 쓸 때 처음 기계공학으로 대학교를 들어가고 심리학으로 전과할 때까지 그리고 그 후, 디자인에 "디"자도 모른 상태로 처음 HCI나 UX 관한 이야기들을 접했을 때 모든 것을 다 내려놓고 거기에 심취하게 된 내용으로 출발했다. 그 후, 혼자 피땀 나는 노력으로 독학을 하고 여러 사람들을 만나서 영감도 얻고 정보도 얻으면서 전반적인 디자인 관련 실력과 지식을 늘려갔고 전문적인 교육을 받기 위해 대학원에 지원한다는 내용을 썼다. 스토리 사이사이에 녹아든 나의 디자인에 대한 열정과 포트폴리오를 코딩해서 직접 만들어본 것 등을 토대로 최대한 Strong Case를 만들었던 것 같다. 자기소개서에서는 자신만의 특이한 스토리가 있어야 모든 것이 비로소 흥미로워지고 "이 학생은 아직 많이는 모르지만 대학원을 통해서 정말 많이 성장할 수 있겠구나"라는 생각을 가지게 하는 것이 중요한 것 같다.다음, 포트폴리오에 대해서 좀 더 자세히 언급하자면 나 같은 경우에는 대학교를 심리학으로 졸업했기 때문에 웹사이트는커녕 Static 한 포트폴리오조차도 없었다. 아니 다시 말하자면, 포트폴리오는커녕 디자인이 관련된 것은 정말 하나라도 가진 게 없었다. 대부분의 학교들은 포트폴리오가 Optional이 었지만 뭔가 없으면 불리할 것 같았다. 결국 나에게는 8월부터 12월까지 4개월 남짓의 시간이 있었는데 크게는 두 가지의 길이 있었다. 하나는 Squarespace나 Wix 같은 웹사이트를 쓰고 디자인 결과물을 몇 개라도 만들어서 포트폴리오를 채워보려고 노력하는 것, 그리고 또 하나는 직접 포트폴리오 홈페이지를 코딩으로 만들어 보는 것이었다. 사실 그 당시에 무작정 학원을 끊어서 HTML/CSS/JS 기초를 잠시 배워봤는데 너무나도 적성에 잘 맞았다. 수업이 끝나면 혼자 집에 가서 복습도 하고 혼자 예습도 해봤는데 온라인에 나와있는 정보들이 너무나도 많아서 금방 학원에서 나가는 진도가 너무 느린 것처럼 느껴졌다. 나중에는 학원을 가지 않고 혼자 집에서 직접 여러 가지를 만들면서 최대한 빨리 배우려고 노력했다. 지금 생각해도 코딩 같은 경우에는 마냥 유튜브 강좌를 듣는 것보단 직접 간단한 것이라도 만들어보는 것이 실력 향상에 가장 많은 도움을 줬던 것 같다. UX 포트폴리오에 대해서 잠시 쓴 블로그도 있다 추가로 내가 코딩을 공부하고 포트폴리오를 직접 코딩하겠다고 마음먹은 것 중 하나는, 대학원 지원 이력서에 HTML/CSS/JS를 할 줄 안다고 쓰고 아무런 결과물을 보여주지 않는 것보다는 허접하지만 그래도 뭐라도 보여주는 것이 결과를 완전히 바꿀 수 있는 비장의 카드라고 생각했기 때문이다. 김칫국을 마시면서 부끄럽지만 혼자 침대에 누워서 학교 면접관에 빙의해서 이렇게 생각도 해보았다. "심리학 갓 졸업한 학생이 혼자 코딩을 공부해서 포트폴리오를 만들었다니! 참 열정이 대단하군!"이라고...미국 대기업에 다니는 디자이너들에 대한 정보 수집대학원 지원 준비를 밤낮으로 하는 도중, 꾸준히 한 것이 몇 개 더 있다. 하나는 좀 Creepy 하게 들릴 수 있지만 난 항상 시간이 날 때마다 LinkedIn을 통해서 내가 관심 있는 대학원에 다니는 사람들이 어느 기업에 인턴쉽이나 정직원으로 갔는지 프로파일 스토킹을 했다. 그냥 검색하면 나오는 정보이기에 찾는 것은 매우 수월했지만 흥미롭고 전율이 흘렀던 점은 몇몇 학생들은 정말로 내가 꿈에 그리는 회사에 다니고 있는 것이었다. LinkedIn에 나와있는 이력서를 보게 되면 그 사람이 다니는 학교는 어디였는지, 들었던 수업은 어떤 것들인지, 포트폴리오는 어떤 식으로 디자인돼있고 프로젝트들은 어떤 것들이 있는지 등을 관심 있게 눈여겨봤다. 몇 개의 포트폴리오들은 시간이 가는 줄 모르고 보고 북마크로 저장하기도 하면서 "언젠간 나도 저렇게 돼야지"라고 생각했다. 하지만 반대로 어떤 포트폴리오 웹사이트들은 둘러보기가 불편한 경우도 있었으며 디자인 경험이 많지 않은 내가 봐도 전체적인 느낌이 생각보다 별로 였던 것들도 있었다. 이렇듯이, 여러 사람들의 포트폴리오를 보는 것들이 나에게 많은 영감과 자극을 주었다. 닮아야 할 것들 그리고 닮지 말아야 할 것들 또한 많이 느끼고 얻어간 것 같다.미국 대기업이 원하는 디자이너의 역량내가 했던 것들 중 또 다른 하나는, 미국에 많은 사람들이 아는 구인구직 사이트를 통한 디자인 직종 분석과 회사가 포스팅하는 디자이너 모집글들을 시간 날 때마다 하나씩 읽어보는 것이었다. 미국에서는 대부분 LinkedIn Jobs, Indeed 그리고 Glassdoor와 같은 곳이 있는데 난 거기서 매일 같이 Product Designer, UX Designer 그리고 Interaction Designer 등 여러 디자이너 직업을 찾아보았고 회사마다 다른 이름의 직책과 뽑는 시기, 그리고 지원방식이 있는 것을 알게 되었다. 정직원은 물론이거니와 인턴쉽에 관한 정보도 끊임없이 노트에 쓰기도 하고 머릿속으로도 정리했다. 예를 들어 구글 UX Design Intern은 1월 초에 지원이 열리고 페이스북 Product Design Intern은 12월 전에 마감이 되는 등, 이런 꿀 정보들은 지금 생각해보면 대학원에 들어가서 다른 친구들보다 빨리 포트폴리오를 정리하고 지원할 수 있는 계기를 마련해 준 것이 아닌가 라고 생각한다. 정보가 힘이다!디자이너가 알아야 할 툴들 공부"난 디자이너예요 또는 난 디자이너가 되고 싶어요"라고 말하기 위해서 제일 중요한 것 중 하나가 바로 Skill Set이다. 흔히 디자인을 모르는 사람들이 디자인을 생각하면 스케치보다는 포토샵을 더 많이 말하는 경우가 있는데 아무래도 요즘은 스케치 시대다. 지금 내가 인턴으로 있는 페이스북에서도 전부다 스케치를 쓴다. 하지만 내가 처음 디자인 툴을 공부해야겠다고 마음먹었을 때 배운 것은 포토샵이나 일러스트레이터다. 하지만 점점 포토샵보단 스케치를 쓰는 트렌드가 왔고 당연히 학생으로선 트렌드를 따르는 게 자연스러웠다. 게다가 스케치는 포토샵으로는 할 수 없는 여러 추가 기능들이 있었으며 너무나도 편리했다. 스케치를 써본 사람이라면 아마 대충 알 것이다. 이런 디자인 툴들 말고도 와이어 프레이밍이나 프로토타이핑 또한 요즘 디자이너가 갖춰야 할 능력임을 알았기에 많이 다운로드하여보고 실제로 툴마다 몇 가지를 만들어보기도 했다. 시간이 지나다 보니 선호하는 툴들이 생겨났고 Framer나 Origami는 특히 페이스북 그룹에 가입했다. 커뮤니티가 매우 잘 돼있었고 다른 사람들이 만든 파일을 들여다보거나 모르는 게 있으면 질문도 해보았다.2. 열정으로 닥치는 대로 공부 & 경험Dribbble & Behance 보고 따라 해 보기매일매일 피와 땀을 흘리며 디자인 관련 툴들을 손에 익혔다. 단축키를 서서히 익혀가고 스케치 같은 경우에는 Symbol사용에 익숙해졌고 각종 유용한 Plug-in들도 활용해보는 등 점점 나의 실력은 향상되어갔다. 실력을 향상하는데 가장 도움이 많이 됐던 것은 Dribbble이나 Behance에 나오는 맘에 드는 디자인들을 따라 해 보는 것이었다. 가끔 대중교통을 이용할 때나 집에서 자기 직전, 정말 멋있다고 생각했던 디자인들을 스크랩이나 스크린샷으로 저장을 해놓고 최대한 똑같이 만들어보았다. 처음에는 그림자나 색깔 사용이 익숙하지 않아서 애를 먹었다. 하지만 그럴 때일수록 혼자 연구도 해보았고 각종 시행착오를 통해 최대한 비슷하게 만들 수가 있었다. 그러다 보니 제법 실력이 늘게 되었고 특히 폰트를 적절히 트렌트에 맞추어 사용하는 법도 제법 많이 늘기 시작했다. 색의 배합도 많이 개선되었고 타이포그래피 연습도 꾸준히 했다. 지금도 딱히 비주얼적으로 뛰어난 디자이너라고 할 수는 없지만 개인적으로 모든 디자이너가 꼭 그럴 필요는 없다고 생각하기 때문에 현재에 매우 만족하고 있다. 하지만 지금도 Dribbble에 업데이트를 시간이 날 때마다 하는 등 많은 노력을 하고 있다.혼자 하는 프로젝트, 포트폴리오 콘텐츠 만들기아까 대학원 지원 당시 나의 포트폴리오에 대해서 살짝 얘기를 해보았는데 이런 궁금증을 가졌으리라고 생각된다. "웹사이트의 윤곽은 만들었다 치고 도대체 그 안에 어떤 내용을 넣었을까?" 다시 말하지만 대학교를 디자인 외의 전공으로 졸업했기 때문에 디자인 관련 프로젝트는커녕 아예 넣을만한 소재가 없었다. 하지만 포트폴리오 윤곽은 다 만들었는데 내용이 없으면 그저 빈 껍데기밖에 안된다. 그래서 혼자 고민 또 고민을 했는데 아무래도 혼자라도 프로젝트를 해보는 게 최선의 방법임을 깨달았다. 처음에는 평소에 사람들이 많이 사용하는 앱들을 다운로드하여서 혼자 Audit을 해보고 "어떻게 하면 더 좋은 UX를 만들 수 있을까? 어떻게 하면 디자인을 더 이쁘게 또 실용적이게 할 수 있을까?" 란 질문들을 던져보면서 프로젝트를 진행해 보았다. 혼자 방에 앉아 인터넷으로 리서치도 해보고, 워드에 나의 생각도 적어보고, 와이어 프레이밍도 연필로 쓱싹쓱싹 해보았다. 딱히 어떤 특출 난 아이디어를 학교 측에 보여주고 싶다기보다는 UX분야에 충분한 관심이 있고 혼자 무작정 해볼 만한 열정이 있으며 그것을 실현 가능하게 끔 하는 디자인 툴 사용 능력이 있다는 것을 증명하고 싶었다.짧은 시간 동안 여러 프로젝트들을 했는데 날씨 앱을 프로토타이핑까지 해서 더 재미있게 만들어보았고 캐릭터 디자인도 해보고, 각종 아이콘 디자인, 그리고 스타벅스 같은 유명 사이트들을 코딩으로 재현해보았다. 뭐든 관련이 있으면 일단 최대한 웹사이트에 추가로 넣어보았고 나의 200%를 보여주고 싶었기 때문에 콘텐츠를 덜 넣는 것은 상상도 못 하였다. 솔직히 그 당시에 나의 포트폴리오를 보면 당장 구멍으로 숨어버리고 싶겠지만 그 당시 면접관의 눈에는 나름 심리학을 나온 디자인에 "디"자도 모르고 코딩의 "코"자로 모를만한 학생의 열정을 높이 샀으리라 생각한다.디자인 관련 밋업, 스터디, 컨퍼런스 참가여기서 알아야 할 것은, 나는 결코 방에 틀어박혀 4개월 내내 공부만 하고 대학원 준비를 한 건 아니다. 페이스북이나 온오프믹스를 통해 각종 디자인 Meetup이나 스터디 또는 HCI 컨퍼런스에 참가하기도 했다. 그중 기억나는 스터디는 이준원 님과 진행한 Framer 스터디인데 일요일 아침마다 매우 재미있게 참가하고 많이 배워갔던 시간이었던 것 같다. 처음에 Framer에 대해서 알고 배울 때에는 너무나도 재밌었는데 모르는 것도 많아서 페이스북 그룹에 스터디가 있는지 궁금했었다. 그때 운이 좋게도 준원 님께서 스터디를 개설하고 주도해 주셨고 그때 정말 많이 배웠던 것 같다. 이렇게 무작정 실무 디자이너들이나 다른 학생들과 같이 스터디도 해보고 직접 얘기도 듣고 하는 것이 디자인이나 크게는 IT필드에 대한 전반적인 지식을 많이 쌓게 해 준 것 같다. 게다가 너무나도 멋진 디자인을 하시는 디자이너분들을 보면서 주먹을 꽉 쥐고 "언젠간 나도 저렇게 될 거야!"라는 생각을 하며 집에 돌아와 더 이를 갈고 열심히 했다. 지금도 같은 생각이지만 이런 이벤트나 모임들은 나가는 것이 정말로 많은 Motivation과 Inspiration이 되는 것은 분명 사실이다. 앞으로도 기회가 된다면 많이 참가하고 싶다.남는 시간 활용 (아티클, 블로그, 유튜브 강의 등)어렸을 때부터 지겹도록 듣는 말, 자투리 시간 활용. 항상 전교 1등들은 말한다, 화장실 가는 시간도 공부에 최대한 활용했다고... 여기서 내가 말하고 싶은 건 그 정도는 아니지만, 어느 정도까지는 열정과 관심만 있다면 할 수 있다는 것이다. 지금까지도 계속 말했지만 나는 버스에서나 지하철에서나 택시에서나 아니면 집에 잠들기 전에 시간 활용을 최대한 신경 써서 했던 것 같다. 대학원 지원 마감까지는 4개월이라는 짧은 시간밖에 없었던 것도 있지만 대학원을 지원하고도 입학은 보통 8월이나 9월이었기에 시간도 많이 남은 것을 알고 있었다. 게다가 대학원에 입학해서 실제로 수업을 듣고 프로젝트를 친구들과 진행해야 하기까지에는 많은 배경지식과 디자인/코딩 지식이 많이 필요할 것만 같았다. 학교에 가서 비실비실 끌려다니기보다는 프로젝트를 주도하고 열심히 하고 툴도 적절히 활용할 줄 아는 디자이너가 되고 싶었기에 매일매일 끊임없이 배웠다.조금 여유가 된다 싶으면 UX 관련 아티클이나 블로그를 많이 찾아봤고 운동할 때나 잠들기 전에는 유튜브 강의를 통해 많은 지식을 흡수했다. 그저 Google에 UX만 쳐도 쏟아 나오는 정보에 감탄을 금치 못했고 정말로 이 분야가 Hot하다는 것에 안도감을 느끼기도 했다. 또 놀라웠던 것은 너무나도 방대한 정보가 인터넷상에 판을 쳤고 전문적인 지식, 세세한 튜토리얼부터 취업하는 방법, 인터뷰 보는 방법, 포트폴리오 만드는 방법, 디자인 툴에 대한 설명, 비교 등 봐도 봐도 끝이 없었다. 하지만 시간이 가는 줄 모르게 너무 재미있었고 어떤 것들은 나의 능력 밖임을 깨달았을 때는 속상하기도 했다. 지금도 너무나도 많은 것들을 모르는 나 자신을 보며 스스로를 자책하고 채찍질한다. 지금 이 글을 쓰는 순간에도 배우고 싶은 것들이 너무나도 많다 그리고 배워야 할 것들이 너무나도 많다.기본적인 웹 코딩 배워놓기아까 잠시 말했지만 여기서 더 자세히 말해보려고 한다. "코딩, 과연 디자이너에게 필요한 스킬인가?" 나는 솔직히 코딩 중에서도 Front-end Development, 즉 HTML/CSS/JS에 관한 기본지식은 디자이너가 배우면 좋다고 생각한다. 실제로 많은 사람들이 "Should Designers Learn How To Code?"라는 질문들을 던지면서 디자이너가 코딩을 왜 배우냐라고 비아냥거리는 경우도 있는데 솔직히 내가 지금까지 코딩을 배워서 이득을 본 것을 생각하면 진짜 이런 말들을 들으면 서운하다. 대학원을 지원할 때 허접했지만 내가 손수 코딩한 웹사이트가 좋은 점수를 따게 해주었고 대학원에 들어가서도 새롭게 만든 나의 포트폴리오가 페이스북이나 다른 회사들 인터뷰를 볼 때 면접관의 눈썹을 올리게 해주었다. 게다가 학교에서 프로젝트를 할 때는 스케치 같은 툴로 하는 디자인뿐만 아니라 프로젝트를 위해 웹사이트를 만들어야 하거나, Framer로 프로토타이핑할 때, 다른 친구들보다 눈에 띄는 Impact를 줄 수 있었다.최근 페이스북 인턴쉽에서는 사람들이 실제로 사용하는 프로덕트에 내가 코드를 써서 리뷰도 받고 그것이 패스가 돼서 결국 프로덕션 되기도 했다. 솔직히 내가 엄청난 것을 만진건 아니지만 그래도 충분히 눈에 띌만한 개선을 한 건 사실이다. 그리고 엔지니어들 중 나랑 프로젝트를 같이 진행하는 Front-end 쪽에 집중하는 엔지니어가 있는데 걔랑 내가 만든 디자인에 대해서 회의를 할 때면 조금이라도 아는 척할 수 있는 자신감도 가질 수 있었다. 그렇기 때문에 나는 만나는 디자인 공부를 하는 학생이나 친구들을 볼 때 코딩은 적어도 기본적인 HTML/CSS/JS는 배워놓으면 좋다고 목에 핏대를 세우면서 얘기한다. 어떤 곳은 디자이너가 코드를 쓰면 싫어한다는 소리가 있는데 (코드가 읽기 힘들거나 더럽게(?) 코딩돼서?) 적어도 페이스북에서는 그런 얘기는 안 하는 것 같다. 내가 만약에 좀 더 깨끗이, 짧게 쓸 수 있다면 엔지니어가 시간 날 때 가르쳐 준다. 애초에 건들지 못할 것은 무작정 덤비면 안 되지만 내 능력 안에 할 수 있는 조그마한 일들은 항상 있기 마련이다. 엔지니어가 바빠서 다른 일들을 먼저 해야 되고 굳이 지금 해결해야 할 일이 아니라면 내가 물어버리고 천천히 시행착오를 통해 해보면 된다. 그렇게 배우는 거다.스타트업 또는 회사 경험시간은 정말 눈 깜짝할 사이에 흘렀다. 결국 12월쯤인가 아마 모든 대학원에 나의 지원서를 넣었던 것 같다. 마감일 전까지 부랴부랴 모든 것을 쏟아부었고 혹시나 빠진 것들이 있는지 확인, 또 확인했다. 포트폴리오 같은 경우에는 지원서를 넣고도 결과가 대충 나오기 시작하는 2,3월까지 언제든 학교 측에서 열람할 수 있기 때문에 수시로 업데이트를 했다. 그리고 꾸준히 블로그도 읽고 디자인 연습도 하고 LinkedIn에 다른 디자이너 스토킹도 하고... 그렇게 반복적인 것을 하던 중에 번뜩 생각난 아이디어가 있었다. "혼자 공부만 하지 말고 실제로 일을 해보면 어떨까?"그 당시 지원한 대학원을 모두 떨어질 것이라고는 생각하지 않았다. 그래서 입학 전 까지는 많은 시간이 남았다고 판단을 내렸고, 때문에 실제로 일 경험을 해보고 싶었다. 어느 날, 컴퓨터 앞에 앉아 구인구직 사이트들을 막 뒤지기 시작했다. 처음에는 대기업을 지원하고 싶었지만 디자인 인턴을 뽑는 곳이 많이 없었을뿐더러 대기업에서 배우는 것보다 스타트업이나 작은 기업에서 더 많은 것을 배울 수 있을 거라는 생각을 했었다. 그래서 관심 있는 곳에 이력서를 넣어보기 시작했다. 인턴쉽이든 정직원이든 나는 그저 경험을 쌓으려고 지원했다. 최대한 오래 일해보고 싶은 마음에 무슨 일은 하는 회사인지 딱히 많이 따져보지도 않았던 것 같다. 그 정도로 너무나도 배우고자 하는 열정이 넘쳤고 디자이너라는 직함을 달고 일을 해보고 싶었다.그때 운이 좋게도 몇몇 작은 회사들에서 연락이 왔다. 전화로 대충 면접을 보고 방문 인터뷰까지 거쳤는데 그중 해외에서도 좀 알려진 회사에서 인턴쉽 기회를 주었다. 사실 회사 측에서는 인턴쉽을 거치고 정직원을 뽑고 싶었을 텐데 그 당시에는 대학원 지원을 마친 때라 결과가 나오지도 않았는데 대학원을 간다고 하면 이상하게 보일까 봐 그냥 인턴쉽 경험만 하여야겠다는 생각이 강했던 것 같다. 그 당시에 나를 가이드해주던 디자이너분이 계셨는데 일도 열심히 하시고 되게 잘하셨던 것 같다. 기본적인 디자인 과제도 매일 내주셨는데 실력 향상에 정말로 많은 도움이 되었다. 그리고 짧은 몇 개월이었지만 정말로 값진 경험을 했다. 생각보다 많은 것을 배우고 비주얼 디자인 쪽으로 많이 연습도 했으며 이력서에 한 줄이라도 쓸 수 있게 되어서 매우 뿌듯했다.대학원에서.. 그리고 인턴쉽 지원1. 학교 수업 및 프로젝트첫 학기의 승부아까 언급했듯이 나는 대학원에 들어가기 전에 엄청나게 많은 정보를 습득하고 들어갔다. 내가 원하는 회사의 입사 지원이 대충 언제 열리고 언제 닫히는지, 준비해야 할 것들은 무엇인지 그리고 어떻게 나 자신을 포지셔닝해야 하는지에 대한 것들에 대한 준비를 학교 시작과 동시에 시작했다. 석사 프로그램은 2년이라 여름방학 때 모두 다 인턴쉽을 하러 떠난다. 인턴쉽은 돈도 벌고 경험도 쌓을 수 있는 좋은 기회이거니와 졸업 전 다른 정직원, 특히 New Grad position에 지원할 때 많은 어드밴티지가 있다. 그리고 전 세계에서 알고 있는 구글, 페이스북, 아마존 등의 회사들에서의 인턴경험은 첫 출발선을 성공적으로 장식할 수 있는 목표이다. 그래서 난 좋은 회사에서 인턴쉽 오퍼를 받는 것이 제일 중요하다고 생각했다. 그리고 그러기에는 1학년 1학기 때 최대한 많은 수업을 들어서 포트폴리오에 넣을 프로젝트를 최대한 많이 넣어야겠다고 생각했다. 왜냐하면 인턴쉽 지원은 대부분 11월에 시작해서 2월 말 정도면 끝난다. 분명 4월까지도 구하는 회사들이 있는데 대부분 이름 있는 유명회사들은 인턴 구하는 데는 문제가 없기 때문에 자리가 없어지기 마련이기 때문이다. 그렇게 되면 2학기 때 하는 프로젝트들은 사실상 포트폴리오에 넣지 못하게 되고 1학기 때의 프로젝트만이 인터뷰를 볼 때 설명할 수 있는 위치에 놓이게 된다.배워보고 싶은 것들 vs. 배워야 하는 것들 vs. 아쉽지만 버려야 할 것들그 누구처럼 나도 학교에 처음 입학하고 들을 만한 수업들을 볼 대 배워보고 싶은 것들이 너무 많았다. AR/VR, IoT 등 모바일이나 웹을 벗어나서 여러 가지 프로젝트를 해보고 싶었다. 하지만 그 당시 확실히 내가 제대로 깨달았던 건 인턴쉽을 위해서는 최대한 모바일과 웹 관련 프로젝트가 있는 것이 중요했다. 대부분의 회사들은 UX Designer나 Product Designer 포지션을 구할 때 모바일이나 웹 관련 프로젝트를 제일 눈여겨보는데 포트폴리오가 대부분 AR/VR에 관련돼 있는 것들이라면 생각보다 지원할 수 있는 회사나 포지션 폭이 확 좁아진다. 몇몇 친구들은 이런 것들을 생각보다 생각해서 고르지 않아서 내 눈엔 포트폴리오가 약간 중간에 붕 뜬 느낌이 들었다. 게다가 그런 와중에 이력서에 스케치나 Framer를 할 줄 안다고 쓰는 건 회사 측에서는 물음표를 던질 수밖에 없는 계기를 줄 수밖에 없다. 그래서 나는 배워보고 싶은 것들이 많았지만 1학기만큼은 대부분의 프로젝트들을 모바일과 웹에 집중했다. 그리고 솔직히 제일 기본이 되고 사람들이 제일 많이 익숙한 그쪽에 많은 경험과 배경지식이 없었기 때문에 확실히 짚고 넘어가고 싶었다. 무엇보다 내가 갈고닦은 디자인과 프로토타이핑 실력 또한 그쪽에 집중되어있었기 때문에 더욱더 수업을 조심해서 골라 들었다. 수업이 말이 나와서 말인데 조지아텍에서는 프로젝트 관련 수업도 있지만 이론만 배우는 수업도 있다. 하지만 포트폴리오에 결과물이 있으려면 프로젝트 중심의 수업이 좋기 때문에 그런 것들도 고려해서 수강하였다.실시간 포트폴리오 업데이트내가 학교가 시작하자마자 시간이 날 때마다 신경 쓴 것 중에 하나는 바로 포트폴리오를 다시 만드는 것이었다. 대학원 지원용 포트폴리오는 디자인이 나쁘진 않았지만 새롭게, 훨씬 더 이쁘게 그리고 더 나은 경험으로 무장한 웹사이트를 만들어보고 싶었다. 아마 학교 시작 후 한 달 동안까지도 학교 공부만큼 포트폴리오 웹사이트를 코딩하는데 시간을 많이 투자했던 것 같다. 목표를 세웠을 때는 10월 중순 정도쯤까지 완성시켜서 서서히 끝나가는 학교 프로젝트들을 쉽게 집어넣을 수 있게 윤곽을 잡으려고 했지만 나도 모르게 집중해서 하다 보니 밤을 새우는 경우도 잦아졌고 조금조금씩 완성이 돼가는 나의 웹사이트를 보면서 하루라도 빨리 세상에 빛을 보게 해주고 싶었다. 수업 중간에 시간이 비면 혼자 조용한 곳을 찾아 음악을 들으면서 코딩을 했던 기억이 난다. 서서히 고치며 때로는 몇 시간째 했던 것을 확 엎기도 해서 여기까지 왔지만 아직도 개선하고 추가, 또는 빼고 싶은 것들이 몇 개 있다.석사 1학년 1학기 때는 정말로 많이 바빴다. 나에게는 삶의 여유를 즐길만한 시간이 없었고 분명 다가올 인턴쉽 지원과 인터뷰 등이 곧 다가올 것을 직감했다. 10월 중순 때만 해도 몇몇 회사들을 서서히 인턴쉽 채용공고를 내기 시작했고 그때마다 나의 프로젝트들이 성공적으로 한걸음, 한걸음 다가서길 바랬다. 그리고 한 단계씩 프로젝트들이 진화할 때마다 사진 찍고, 기록하고, 배운 점들, 개선해야 할 점들을 정리해서 포트폴리오에 집어넣기 시작했다. 친구들 중에는 포트폴리오를 만들지 않은 경우도 있었고 딱히 인턴쉽에 대해 많은 대비를 하지 않거나 정보도 많이 모르는 친구들도 있었다. 게다가 도대체 왜 이렇게 빨리 포트폴리오를 신경 쓰고 업데이트를 매주 하는지 이해를 못해하는 친구들도 있었다. 하지만 내 머릿속엔 지원시기는 11월부터였으며 학교 프로젝트는 대부분 학기말인 12월 중순에 끝나는 것을 감안하면 모든 프로젝트의 프로세스를 도큐멘팅하고 편집하는 것은 한꺼번에 하면 정말 하기 싫어질 만큼 오래 걸릴 것을 누구보다 잘 알고 있었다. 게다가 12월 말 겨울 방학에 포트폴리오를 업데이트하고 서서히 지원을 하기에는 놓치는 회사들도 몇몇 있었고 빨리 지원할수록 인터뷰를 따내는데 어느 정도 이점도 있다고 생각했기 때문에 난 내 갈 길을 걸었다.교내 프로젝트 외 다른 도전사실상 1학년 1학기 때 3개 이상의 제대로 된 프로젝트를 하는 것은 매우 힘든 일이다. 특히 내가 다니는 조지아텍에서는 1학년 1학기 때 친구들과 같이 들어야 하는 필수 과목들이 있어서 한정이 되는 경우도 있었다. 하지만 분명 적어도 한 개 정도는 더 들을 수 있는 여유가 있었기에 이론 강의보다는 프로젝트를 통해 배우는 강의를 택했다. 그렇지만 결국 포트폴리오에 집어넣을 수 있는 학교 프로젝트는 많아야 3개였다. 포트폴리오 웹사이트에 프로젝트가 3개밖에 없다고 해서 나쁜 것이 결코 아니지만 뭔가 더 어필할 수 있는 것들이 있을 거라고 믿었다. 그리고 그런 기회는 예상보다 빨리 찾아왔다. 바로 그것은 교내에서 있는 해커톤, 디자이너톤 그리고 각종 대회였다.꼭 우승을 차지해야겠다는 생각은 많이 하지 않았고 오히려 참가하는데 의미를 두고 며칠 동안의 프로젝트지만 그래도 열심히 해서 포트폴리오에 넣어볼 수 있도록 할 정도의 퀄리티까지 뽑아보고 싶었다. 그리고 만약 상을 받는다면 분명 이력서나 포트폴리오 한편에 자랑도 할 수 있으리라 기대감도 없지 않아 있었다. 몇 날 며칠 동안 밤새고 친구들과 디자인도 해보고 프로토타입도 만들어보고 여러 가지를 해보았는데 생각보다 재미있었다. 게다가 운이 좋게도 몇 번 상을 수상해서 포트폴리오에 넣을 수도 있었다. 추가로 학교에서 했던 프로젝트 중 2개는 실제로 교내 대회에서 2번 2등을 하는 영광을 얻기도 했다. 이런 것들 모두 포트폴리오 웹사이트에 사진과 함께 실었으며 모든 사람에게 나의 열정과 동시에 실력을 보여 줄 수 있는 무기가 되지 않았나 싶다.  2. 조교조교의 혜택과 이점내가 알기론 적어도 HCI 대학원들 중에서는 조교를 못하는 대학원도 있고 조교를 하더라도 금전적 혜택이 그만큼 크지 않은 대학원도 있다. 내가 다니는 조지아텍의 장점은 대학원 학생들이 GRA (Graduate Research Assistant)나 GTA (Graduate Teaching Assistant)로 연구실이나 수업에서 조교를 할 수 있는 기회가 그래도 다른 대학원보다는 많다는 것이다. 우리 학교에서는 조교가 되면 그 학기의 학비는 면제가 되고 GRA는 연구실이나, GTA는 가르치는 수업마다 시급이 다르지만 최소 매달 1,000불에서 2,000불까지 받을 수 있다. 따지고 보면 한 학기에 학비가 대충 2,000만 원을 훌쩍 넘기는 것을 생각하면 조교가 되면 거의 2,500만 원 정도는 오히려 벌게 되는 셈이다. 이런 금전적 혜택이 있기 때문에 많은 친구들이 하고 싶어 하지만 모두 다 조교를 할 수 있는 게 결코 아니다. 내 경험으로는 컴퓨터 공학 배경이 있는 학생들이 GRA를 받기가 쉬운데 코딩을 할 줄 알아서다. 그렇지만 분명 연구실마다 디자이너가 필요한 경우가 있을 수가 있고 교수님이 하시는 연구에 보조나 조금이나마 웹 개발 또는 프로토타이핑 등 도움을 줄 수 있는 프로젝트가 있을 수 있기 때문에 열심히 발 벗고 찾아봐야 한다.사실 조교가 되면 이로운 건 금전적인 것뿐만이 아니다. 많은 LinkedIn 프로파일에서 보면 알듯이 결국 이런 것도 이력서에 쓸 수가 있다. 결국에는 한 학기 또는 더 길 게의 나만의 경력이고 특히 GTA보다는 GRA가 여러 프로젝트를 할 수 있기 때문에 추가적으로 이익인 부분도 있다. 게다가 결국엔 회사 면접을 볼 때 할 말이 남들보다 한 가지는 더 있는 것일뿐더러 나의 능력이 학교에서 이미 검증되었다는 것을 증명하는 것이기도 하다. 실제로 내가 페이스북 인터뷰를 볼 때 면접관이 내가 GRA였을 때의 경험담에 대해 잠시 얘기를 해달라는 부탁을 하기도 했다.지원할만한 연구실 목록 작성다시 말하지만 다른 학교는 어떤지 잘 모른다. 하지만 조지아텍 같은 경우에는 HCI 웹사이트에서 연구실들에 관한 정보를 쉽게 찾을 수 있다. 나는 학교에 들어가기 전, 한국에 있었을 때부터 교내에 있는 연구실을 전부다 찾아보고 지원할만한 프로젝트가 있는 연구실을 대충 정리했다. 몇몇 교수님이나 연구실에 있는 박사 학생에게 여름 방학 기간에 이메일을 보내봤지만 솔직히 운이 정말 좋지 않은 이상 힘들다. 대부분의 답변은 일단 학교에 오면 다시 얘기하자는 얘기뿐이었다. 실제로 내가 알기로도 연구실마다 뽑을 수 있는 인력과 비용 등을 정하는 것이 생각보다 까다로운데 그런 것들이 100% 갖춰져 있지 않은 기간이다 보니 아무것도 모르는 사람한테 선뜻 자리를 내어주는 것은 말도 안 되는 것 같다. 하지만 시간 날 때 참여할 만한 연구실을 미리 찾아 놓는 것은 학교에 입학했을 때 분명 도움이 많이 된다.  연구실 지원 준비사실 나는 운이 좋게도 1학기 때부터 조교를 할 수 있었다. 첫 학기에는 학비 면제까지는 아니었지만 그래도 시급이 매우 쌔서 돈은 생각보다 많이 벌 수 있었다. 게다가 매우 행복했던 점은 이른 시기에 이력서에 한 줄이라도 더 세길 수 있는 것, 그리고 뭔가 첫 단추를 잘 끼운듯한 느낌이었다. 처음 지원할 때 무작정 지원서를 모든 연구실에 뿌린 것이 아니라 그전에 정확히 내가 관심 있고 나를 관심 여겨줄 만한 연구실을 찾아놨기 때문에 2,3개의 이메일만 보내면 됐다. 이메일 속에는 나의 이력서와 대학원 때 지원했던 포트폴리오 웹사이트, 내가 가지고 있는 Skill Set 그리고 내가 어느 프로젝트에 도움이 될 수 있을 만한지를 어필하는 메시지도 같이 써서 보냈다.내가 있는 연구실 이메일이 내 학교 이메일과 연동이 되어있어서 가끔가다가 연구실에 관심을 보이는 학부나 다른 대학원생들이 이메일을 이력서 첨부해서 보내는 경우가 있는데 정말 성의 없는 경우도 있고 누가 봐도 복붙을 했다시피 보낸 이메일도 간혹 눈에 뜨인다. 하지만 그중에서도 정말 성의 있게 목표가 명확한 이메일도 오는데 확실한 건 우리 연구실 매니저가 답장을 그런 사람에게는 솔직하게 잘 해주고 면접을 보러 오라는 경우도 자주 있다. 역시 사람과 사람의 관계에서는 그런 것들도 신경 써서 하는 게 좋은 것 같음을 또 한 번 느끼는 계기가 됐다.열심히 일하기나 같은 경우에는 1학년 2학기 때 GRA가 돼서 더 많은 책임감과 프로젝트를 해보고 싶었기 때문에 그 누구보다 열심히 주어진 역할에 임했다. 분명 학비 면제라는 매우 좋은 옵션도 있기 때문에 연구실에서 생각보다 많은 시간을 보냈다. 나 자신이 어느 회사의 한 명의 파트타임 직원이라고 생각하고 정직원으로 되기 위해 열심히 일하고 어필해야 한다고 생각했다. 정말 운이 좋았던 것은 뽑은 사람들 중에서 디자이너가 한 명도 없어서 대부분 디자인 관련 일들은 내가 도맡아 했다. 우리 연구실에서 주최하는 교내 대회 포스터 디자인이라던지 앱이나 웹사이트 관련 디자인들도 내가 맡아했으며 연구실 홈페이지 업데이트에 대해서도 많은 부분은 내가 관리하기 시작했다. 그래서인지 영향력이 조금씩 커지기 시작했고 정말 감사하게도 나에게 2학기 때 GRA를 할 수 있는 기회를 주었고 인턴쉽이 끝나고 돌아가면 2학년 1학기와 2학기 때도 같은 연구실에서 GRA를 할 수 있는 기회를 주었다.3. 인턴쉽 지원 준비회사들에 대한 지식 및 공부기본적으로 회사에 지원을 하려면 지원하고자 하는 회사가 무엇을 하는 회사이며 내가 지원하는 롤이 어떤 것임을 분명히 알아야 한다. 이름은 들어봤지만 정확히 무엇을 하는 회사가 어떤 Vision이 있으며 디자이너가 회사 내에서 하는 역할 같은 것들에 대한 정보는 많이 없어서 따로 지원하기 전에 시간을 투자해서 알아봐야 했다. 실제로 그 회사들을 다니는 디자이너들의 포트폴리오도 들여다보고 LinkedIn 프로파일에 나와있는 정보도 눈여겨봤다. 하지만 몇몇 회사들은 내가 정말로 일을 하고 싶은 회사였기에 이 모든 과정이 너무나도 가슴 뛰는 일이었다. 심심할 때 Glassdoor나 Quora라는 사이트에 가서 회사와 디자이너 타이틀을 치면 생각보다 많은 Review나 댓글들을 볼 수 있다. 분명 거기에 나와있는 정보가 최신이 아닐 수도 있고 정확하지 않을 수도 있지만 그래도 아예 모르는 것보다는 좋은 정보들이 있었다. 또 하나의 정말 좋은 방법은 인맥을 만들어서 직접 물어보는 것이다.Referral미국에서는 인터뷰를 따내기 위한 제일 쉽고 빠른 방법은 Referral을 받는 것이다. 수천 개 또는 수십만 개의 지원서를 리쿠르터들이 일일이 하나하나씩 읽어볼 순 없으니 어느 정도 직원 추천에 의존하는 것 같다. 나 같은 경우에는 운이 좋게도 내가 가고 싶은 회사에는 적어도 한 명씩 친구나 선배가 있어서 Referral을 받는 게 어렵진 않았다. 하지만 한두 개의 가고 싶었던 회사들에는 아는 사람이 없었기에 1학년 1학기 때 같은 학교 졸업생이나 페이스북 그룹, 또는 LinkedIn Messaging을 통해서 공통분모가 될만한 사람과 연락해서 친해지도록 노력했다. 이처럼 만약에 아는 사람이 없다면 꾸준한 온라인/오프라인 네트워킹을 통해 인맥은 미리 만드는 것이 좋은 것 같다. 실제로 몇몇 디자인 관련 페이스북 그룹에서 자신의 Dribbble, Behance, Codepen, 블로그 등을 소개하는 사람들이 있는데 그런 식으로도 자신의 영역을 넓혀 가는 것도 하나의 방법인 것 같다.이력서 디자인지금까지 포트폴리오에 대한 이야기는 많이 했지만 이력서 얘기는 자세히 하지 않은 것 같다. 개인적인 생각으로는 제일 중요한 건 역시 포트폴리오지만 이력서도 분명 엄청 중요하다. 대게 포트폴리오에는 이력서를 다운로드할 수 있게 하거나 직접 써넣는 경우가 있는데 어쨌든 회사에 지원하려면 이력서를 PDF 파일로 내야 한다. 이력서에 대부분 넣는 내용은 자신에 대한 간단한 소개, 학교, 일 경험, 쓸 줄 아는 툴들 외 수상경력 등이다. 디자인 같은 경우에는 학점은 그렇게 많이 중요하지 않다. 많은 회사에서는 심지어 학점을 물어보지도 않는다. 그만큼 포트폴리오를 많이 본다는 것인데, 포트폴리오를 들여다보기 전에 이력서를 먼저 보는 것으로 알고 있다. 이력서에 나와있는 학교, 프로젝트 또는 일했던 회사들이 흥미로우면 포트폴리오로 넘어가는 형식이라서 이력서가 어쨌든 나의 첫인상이 된다. 그래서 많은 디자이너들의 이력서를 보면 이 모든 것을 다 넣는 동시에 자신의 Creative 한 디자인을 뽐내는 경우가 많다. 내 생각에는 시간을 투자해서 이력서를 차별화시키는 것은 정말 좋다고 생각한다. 하지만 당연히 읽기 쉬워야 하며 흑백으로 프린트해서도 깔끔하게 나와야 하는 등 신경 쓰는 게 필요하다.포트폴리오 외 어필할 방법결국 회사에 지원할 때는, 이력서 첨부파일, 포트폴리오 주소, 자기소개 및 지원사유 등이 있는데 많은 회사들은 Additional Link라고 해서 다른 디자인 관련 웹사이트들이 있으면 첨부로 넣으라고 한다. 뭐든 추가로 넣는 것은 나쁠 것이 없기 때문에 나 같은 경우에는 내 Dribbble, Medium, LinkedIn주소를 넣었다. 이 외에도 Behance, Codepen, Github 같은 곳을 추가로 넣을 수가 있으며 이력서나 포트폴리오에 넣지 못한 작업물이 나와있는 웹사이트를 올려도 좋은 어필이 될 수 있다.4. 경험담을 글로 풀어내기개인 블로그 시작맨 처음에 말했듯이 내가 처음 디자인을 접했을 때 Medium이나 다른 웹사이트들에 나와있는 각종 아티클과 블로그들이 나에게 정말 많은 도움을 주었다. 회사들에서 퍼블리쉬되는 글들도 많았지만 그중에는 현업에서 종사하는 디자이너들이 쓴 글들도 상당히 많았다. 크게 봤을 때는 글의 종류는 반반이었던 것 같다. 하나는 전문적인 지식을 얘기하는 글들이고 또 하나는 자신의 경험담을 주로 쓰는 글들이었다. 난 내가 대학원에 처음 들어와서 공부를 하기 시작했을 때 나의 이야기를 글로 풀어보면 어떨까에 대한 생각을 많이 했었다. 처음에는 HCI 석사에 대한 경험담을 집중적으로 쓰고 싶었는데 그 이유 중 하나는 디자인 관련 글들은 많았지만 이 주제에 관한 글들은 많이 찾아보기 힘들었을뿐더러 지금도 그렇지만 그 당시에도 정말 많은 사람들이 HCI 석사를 지원 희망하는 것을 몸으로 느낄 수 있었기 때문에 어느 정도의 사람들이 읽어주리라 생각했기 때문이다.그래서 한 자 한 자 써 내려가고 대학원 관련 글 말고도 페이스북에서 인터뷰한 글들도 Dribbble에 관한 글들도 나의 Medium에 쓰게 되었다. 조금씩 사람들이 공감을 많이 해주고 팔로워도 생각보다 많이 늘어나다 보니 더 열심히 좋은 글들을 써야겠다고 생각했다. 그중, 심리학 배경으로 UX 하기와 포트폴리오에 대한 글을 썼는데 생각보다 반응이 엄청 뜨거워서 Muzli와 Sidebar에 소개되는 등 폭발적인 조회수를 기록하게 되었다. 이때부터는 정말로 글 쓰는 것에 대해서 큰 재미를 느끼게 되었고 글 쓰는 것에 대해서도 많이 신중해지기 시작했다. 모르는 것들은 찾아도 보고 배우게 되었고 무조건 발행을 하는 것이 아니라 어떤 것에 대해 쓸 것인지에 대해 플랜을 짜고 Structure를 짜고 계속 고쳤다. 스토리텔링에 신경을 많이 썼다. 그리고 그것은 정말로 큰 도움이 됐다.디자이너에게 블로깅이란?개인적인 생각이지만 디자이너에게 글을 잘 쓰는 능력은 가지면 매우 좋은 어드밴티지인 것 같다. 가끔 온라인에 나와있는 유명 디자이너들의 블로그를 읽을 때면 집중해서 확 읽어버리는데 내용도 내용이지만 짜임새가 매우 매끄러워서 읽다가 넘기는 적이 별로 없었다. 하나 더 최근에 계속 느낀 건 프로젝트를 포트폴리오 웹사이트에 도큐멘팅하거나 회사에서 프로젝트에 대해서 모든 것을 기록할 때 계속 글을 쓴다는 것이었다. 디자이너의 업무 중 많은 것들은 실제로 스케치로 디자인하는 것도 있고 수많은 미팅들도 있지만 어딘가에 글을 쓰는 것은 정말로 많다.  나는 모든 프로젝트를 진행할 때 Problem Statement에 대해서 정확히 짚고 넘어간다. 때문에 어떤 것이 문제인지, 왜 이게 문제인지, 누구를 위해서 내가 이 문제를 푸는지, 마지막 결과는 어떤지 등에 관한 글을 쓴다. 그리고 다른 팀원들과 소통할 때도 Structure이 잘 돼있는 글을 보여준다.5. 회사 지원 및 인터뷰Google Analytics를 통한 방문자 분석회사에 지원서를 넣고 나면 적어도 몇 주 동안은 연락이 없다. 진짜 빠른 경우에는 일주일 만에도 답장이 오는 경우가 있지만 인턴쉽 같은 경우에는 시간이 좀 더 걸리는 것 같다. 내 포트폴리오 웹사이트에는 방문을 하긴 하는지가 제일 궁금한데 제일 쉽게 알아낼 수 있는 방법은 웹사이트에 Google Analytics Tracking Code를 삽입하는 것이다. 하기가 정말 쉬워서 온라인에서 하는 방법을 찾으면 아마 쉽게 알아낼 수 있을 거다. Tracking Code를 넣고 Google Analytics툴에 들어가면 어느 지역에서 방문했는지, 네트워크는 무엇인지 (회사 이름인 경우가 많다) 그리고 어느 페이지에 얼마큼 머물렀는지 까지 분석해볼 수가 있다. 게다가 실시간 정보도 다 보이기 때문에 지금 나의 웹사이트에 들어온 사람들을 볼 수 가있다.나 같은 경우에는 내가 지원한 어느 특정 회사에서 들어오면 매우 기뻐했다. 그리고 실제로 인터뷰를 보기 한두 시간 전에 면접관들이 들어와 보는 것을 경험으로 깨달아서 나중에는 전화나 화상통화 면접을 보기 전에 그 사람들이 어떤 프로젝트를 눈여겨보는지 실시간으로 봤다. 그래서 짧은 시간이지만 면접관이 더 오래 머무른 프로젝트에 대해서 마음속으로 연습 또 연습을 하면서 전략적으로 준비했다.Recruiter와의 대화대부분 처음에 인터뷰를 보자고 회사에서 연락이 오면 찬스는 정말 높아진 것이다. 대부분의 서류들이 사실 필터가 되는 경우가 많고 인터뷰를 보자고 이메일 오는 경우는 지원자 수에 비해서 턱없이 적기 때문이다. 회사마다 진행되는 단계가 다르지만 인턴쉽 같은 경우에는 리쿠르터와 먼저 대화를 한다. 대충 리쿠르터가 적절한 시간에 전화를 해서 지원자의 관심사와 스킬을 인턴이 필요한 팀과 매칭을 하기도 하는 이유이기도 하지만 크게는 지원자에 대해서 더 알아가는 동시에 프로세스를 설명해 주는 시간이다. 어떤 경우에는 실제로 리쿠르터와 전화하고 나서 인터뷰를 더 이상 진행 못하는 경우도 있는 거로 봐서는 절대로 가볍게 해서는 안 되는 단계임은 분명하다. 페이스북 같은 경우에는 디자인 리쿠르터가 따로 있어서 디자인 관련된 전문적인 것도 물어봤었다. 하지만 인터뷰를 본 다른 회사들은 그런 것들보단 나에 대해서 General 하게 알고 싶어 했다.Interviewer 파악하기리쿠르터와 Screening 단계를 하고는 대부분 디자인 관련 직업의 면접관과 전화나 화상통화를 한다. 어떤 회사들은 직접 회사로 불러서 On-site 인터뷰를 진행하는 경우도 있지만 인턴쉽은 대부분 전화로 끝난다. 리쿠르터와 시작부터 끝까지 이메일로 연락을 주고받는데 전화연결방법, 면접관에 대한 정보 등을 전달해준다. 면접관에 대한 정보는 흔하게는 이름과 직책만 주는 경우가 대부분인데 LinkedIn이나 Facebook 같은 곳을 찾아보면 쉽게 찾을 수 있다. 특히 LinkedIn으로는 그 면접관이 어디서 일했었고 어느 프로젝트를 했으며 그 사람에 대한 전반적인 느낌을 알 수가 있다. 면접관과 처음 몇 마디를 나눌 때는 공감대가 있는 것이 분위기를 업시켜주고 시작을 산뜻하게 출발하게 도움을 주는데 여기서 몇 가지 자신과 공통된 점을 설명하 거나하면 그래도 라포르를 형성하는데 어느 정도 기여를 한다. 하지만 너무 Creepy 하게 스토킹을 한 것처럼 느껴지면 이상하기 때문에 조심해야 한다.실전실제로 면접관과 전화를 할 때 회사마다 다르지만 꼭 하는 것은 포트폴리오 리뷰이다. 내가 지금 까지 한 프로젝트 중 제일 잘 했다고 생각한 프로젝트나 면접관이 관심 있는 프로젝트를 2개에서 많게는 3개까지 설명하게 된다. 대부분 프로젝트가 어떤 것인지에 대한 설명부터 시작하게 되고 프로젝트 중 나의 역할, 힘들었던 점, 배운 점 등을 설명하는데 중간중간에 면접관이 궁금한 점들도 물어본다. 이것에 대해 Medium에 글을 쓴 것이 있는데 관심이 있으면 여기에서 찾아보길 바란다.마무리하며...많은 디자이너 분들이 재미있는 블로그들을 써주시는데 순수 디자인 백그라운드가 아닌 상태에서 지금까지 오기까지의 이야기는 흔하지 않은 것 같아서 그동안 내가 느낀 점을 써보자고 다짐했다. 쭉 써가다 보니 어느샌가 많이 길어지게 되었고 "설마 시람들이 이걸 다 읽을까..."라는 고민도 했었다. 나의 소중한 시간을 투자하고 그동안의 기억을 되돌려서 한 자 한 자 신중히 써 내려간 만큼 많은 학생분들 또는 현업에 종사하시는 디자이너 분들에게 조금이라도 도움이 되었으면 한다.항상 하는 말이지만, 아직도 갈길은 멀다. 실력에 비해 너무나도 과분한 기회가 주어졌고 그 기대에 조금이라도 더 부합하기 위해 밤낮으로 열심히 노력했다. 세상에는 정말로 뛰어난 디자이너분들이 계시며 언젠간 그들과 어깨를 나란히 하고 더 창의적이고 밝은 디자이너가 되고자 나는 앞으로도 노력할 거다. 읽어주셔서 너무나도 감사하고 앞으로도 좋은 글로 찾아뵙고 싶다.감사합니다.#페이스북 #Facebook #인턴 #인턴후기 #인턴생활 #기업문화 #디자인 #디자인팀 #디자이너
조회수 1195

vulcan과 buildpack을 이용한 Heroku 바이너리 배포

vulcan과 buildpack을 이용한 Heroku 바이너리 배포안녕하세요. 스포카 개발팀에서 서버 관련 개발 업무를 담당하고 있는 문성원입니다. 오늘은 저희가 사용하는 PasS(Platform as a service)인 Heroku에 직접 바이너리를 빌드하여 올리는 방법을 함께 알아보겠습니다.Why?________________________________________지난주 저희 개발팀은 새로운 상점 사진을 출력하기 위해 한 사진을 비율이 다른 이미지로 바꿔서 저장하는 작업을 해야 했습니다. 다행히 이 문제는 Seam carving, 혹은 Liquid rescaling으로 불리는 방법, 그리고 이를 구현한 ImageMagick과 그 Python 바인딩인 wand로 쉽게 해결할 수 있을 것 같았습니다. (Seam carving과 wand에 대해서는 이 글을 읽어보시는 것을 권합니다.)그런데 막상 서비스에 배포하려니 한가지 문제가 있었습니다. 저희는 최근 서비스를 Heroku에서 운영 중인데, 이 Heroku에 ImageMagick 라이브러리는 깔렸었지만, liblqr이 없어 Liquid rescalig이 불가능한 상태였던 겁니다. 개발자의 로컬에서 테스트할 때야 소스를 받아서 직접 빌드라도하면 되지만 이 고지식한 PasS에서 그건 무리였죠.결국, 저희는 Heroku의 배포 도구인 buildpack과 바이너리를 빌드하기 위한 서버인 Vulcan에 대해서 조사했습니다.Workflow________________________________________Heroku 앱에 사용할 바이너리를 만드는 데는 크게 2가지 과정이 필요합니다. 먼저 빌드 서버인 Vulcan을 통해 필요한 바이너리를 Heroku(정확히는 아마존 EC2)용으로 빌드해야하며, 이를 buildpack을 통해 새로 만들거나 운영 중인 앱에 적용해야 합니다.재미있는 점은 Vulcan 서버 역시 Node.js로 작성된 Heroku 앱이기때문에 buildpack을 적용할 수 있습니다. 즉 위와 같은 상황이라면 먼저 liblqr을 빌드한 뒤 이를 Node.js 용 buildpack에 적용해서 Vulcan에 올린 뒤 ImageMagick을 빌드해야 합니다.I am a Vulcan, bred to peace________________________________________우선 Vulcan부터 깔아보겠습니다. (Ruby와 Heroku 계정이 필요합니다. 경우에 따라선 sudo가 필요할 수 있습니다.)$ gem install vulcan그다음 빌드에 사용할 서버 애플리케이션을 vulcan 커맨드를 통해 만듭니다. (눈치채신 분도 계시겠지만 앱 이름은 적당히 바꿔서 지으셔야 에러가 안 납니다.)$ vulcan create vulcan-dodo-dev혹시 모르니 만들어진 서버의 업데이트를 한번 해줍시다.$ vulcan update --app vulcan-dodo-devIf I could change to liquid…________________________________________이제 본격적으로 빌드를 해봅시다. 먼저 필요한 건 liblqr입니다. 소스를 적당한 디렉터리에 내려받아 풀어둡니다.$ wget http://liblqr.wikidot.com/local--files/en:download-page/liblqr-1-0.4.1.tar.bz2$ tar xzf liblqr-1-0.4.1.tar.bz2최신 소스를 원하신다면 git 저장소를 복제하셔도 됩니다.$ git clone git://repo.or.cz/liblqr.git편하신 대로 소스를 다 내려받으셨다면 이제 앞서 생성한 Vulcan을 통해 이를 빌드해봅시다.$ cd liblqr$ vulcan buildVulcan은 현재 디렉토리의 소스를 모두 묶어서 EC2상의 서버로 올린 뒤 그 서버에서 빌드한 바이너리를 다시 사용자의 컴퓨터로 내려줍니다. 이제 이를 buildpack을 통해 Vulcan 서버(vulcan-dodo-dev)에 적용해야 합니다.Buildpack is ready________________________________________buildpack을 직접 만들어 적용하는 건 아주 쉽습니다. 우선 다음 명령어로 Node.js용 buildpack을 복제합니다.$ git clone git://github.com/heroku/heroku-buildpack-nodejs.git그다음에는 Heroku용으로 빌드된 liblqr을 Heroku 앱 빌드시 포함시키기 위해 bin/compile파일의 마지막에 다음 코드를 추가합니다. (앞서 빌드한 liblqr을 외부에서 접근할 수 있게끔 적당한 장소(ex. Amazon S3, 혹은 Dropbox의 Public 디렉터리등)에 올려둬야 합니다.)# liblqr                                                                                  LIBLQR_BINARY="https://dl.dropbox.com/u/55786385/liblqr-1-0.4.tgz"                        SPOQA_VM_VENDOR="vendor/spoqa/liblqr"                                                    mkdir -p $1/SPOQA_VM_VENDOR                                                            curl $LIBLQR_BINARY -o - | tar -xz -C $1/$SPOQA_VM_VENDOR -f -이제 buildpack을 커밋(commit)한뒤 적당한 공개 저장소(ex. github) 등에 올려(push)둡니다. 그리고 나선 아까 만든 Vulcan 앱(vulcan-dodo-dev)의 buildpack을 다음 명령어로 지정합니다.$ heroku config:set BUILDPACK_URL=https://github.com/spoqa/heroku-buildpack-nodejs.git --app vulcan-dodo-dev마지막으로 Vulcan 앱을 업데이트하여 새 buildpack을 반영시킵니다.$ vulcan update --app vulcan-dodo-dev확인을 위해서 Vulcan 앱에 들어가 보는 것도 좋습니다.$ heroku run bash --app vulcan-dodo-devheroku run bash --app vulcan-dodo-devRunning `bash` attached to terminal...~ $ ls vendor/ls vendor/spoqa  gemsIt’s a kind of magic________________________________________이제 liblqr을 이용해서 ImageMagick을 빌드해보죠. 기본적으로는 liblqr을 빌드할때와 다르지 않지만 ./configure를 통해 옵션을 줘야 하기에 build 커맨드가 좀 복잡해집니다.vulcan build -p /tmp/ImageMagick -c "export PKG_CONFIG_PATH=/app/vendor/spoqa/liblqr/lib/pkgconfig && export CFLAGS=-I/app/vendor/spoqa/liblqr/include/lqr-1 && LD_LIBRARY_PATH=/app/vendor/spoqa/liblqr/lib && ./configure --prefix=/tmp/ImageMagick --with-lqr && make install" -v조금만 자세히 살펴보면, -p 옵션으로 내려받을 경로를 지정하고 -c 옵션으로 실제 빌드에 사용할 커맨드를 지정합니다.(-v는 짐작하시다시피 확인을 위한 verbose 옵션입니다.) 앞서 수정한 buildpack에서 liblqr은 /app/vendor/spoqa/liblqr 밑에 설치되게끔 되어있기에 PKG_CONFIG와 CFLAGS 설정을 추가해주고 --with-lqr을 줘서 LQR 딜리게이트(Delegate)를 활성화 시킵니다.On your mark________________________________________이렇게 만들어진 ImageMagick 바이너리와 liblqr 바이너리를 실 서버에 적용할 buildpack에 추가해주면 이 험난한 여정도 끝입니다. 앞서 했던것처럼 대상 서버에 맞는 buildpack을 똑같이 복제합니다. (여기서는 Python을 사용합니다.)$ git clone git://github.com/heroku/heroku-buildpack-python.gitbin/compile을 고치는 것도 추가해야 할 라이브러리가 2개라는 점만 빼면 거의 같습니다.# ImageMagick with lqr                                                                                                                  LQR_BINARY="https://dl.dropbox.com/u/55786385/liblqr-1-0.4.tgz"IMAGE_MAGICK_BINARY="https://dl.dropbox.com/u/55786385/ImageMagick-6.8.tgz"IMAGE_MAGICK_WITH_LQR_DIR="vendor/ImageMagick+lqr"mkdir -p $1/$IMAGE_MAGICK_WITH_LQR_DIRcurl $IMAGE_MAGICK_BINARY -o - | tar -xz -C $1/$IMAGE_MAGICK_WITH_LQR_DIR -f -curl $LQR_BINARY -o - | tar -xz -C $1/$IMAGE_MAGICK_WITH_LQR_DIR -f -똑같이 고친 buildpack을 커밋, (적당한 저장소에) 푸시하고 대상 서버의 BUILDPACK_URL을 바꿔줍니다.$ heroku config:set BUILDPACK_URL=https://github.com/spoqa/heroku-buildpack-python.git --app dodo-dev바뀐 buildpack을 적용하기 위해서 빈 커밋을 만들어 새로 배포해보겠습니다.$ git commit --allow-empty -m "empty commit"$ git push heroku master마지막으로 대상 서버의 설정을 바꿔줍니다.$ heroku config:set MAGICK_HOME=/app/vendor/ImageMagick+lqr LD_PRELOAD=/app/vendor/ImageMagick+lqr/lib/libMagickCore.so --app dodo-dev#스포카 #개발 #개발자 #개발팀 #개발팁 #꿀팁 #인사이트
조회수 1414

샌프란시스코 테크 업계 인터뷰 1: Facebook, Fivestars

제품을 담당하는 팀이 일하는 방식은 제품 그 자체에 영향을 줍니다. 어떠한 기능을 어떤 주기로 사용자에 배포할 것이냐에 대한 결정을 하는 과정이기 때문에 구체적인 결과물에 영향을 끼치기도 하지만 누가 기능을 만들고 디버깅 하고 그 업무에 대한 조직의 시각에 따라 결과적으로는 제품의 품질에도 영향을 미칩니다.구태의연한 말이지만 테크 업계에서 일하는 방식에 있어 정답은 없습니다. 제품과 조직은 끊임없이 변화하고 이에 맞추어 일하는 방식도 바뀌어야 하기 때문에 지난 해에 불합리하다고 여기던 방식이 올해는 검토해 볼 만한 것이 될 수도 있습니다. 일하는 방식 그 자체도 협의를 거쳐 지속적으로 개선하는 과정이 필요합니다.일하는 방식과 함께 제품 그리고 조직마다 프로덕트 매니저의 역할과 권한도 바뀝니다. 비즈니스에 제품이 기여하는 정도에서부터 조직 내 이해관계자와의 관계까지 제품과 조직의 모든 요소가 프로덕트 매니저의 일하는 방식을 바꿉니다. 스포카 프로덕트 매니저의 경우, 서비스 백로그 관리의 역할도 담당하기 때문에 유동적인 일하는 방식에 따른 결과는 제품에 다시금 반영됩니다.이번 샌프란시스코 테크 업계 인터뷰는 위와 같은 가정 하에 ‘스포카는 앞으로 어떤 방식으로 일할 것인가’라는 질문에 대한 참고할 사례를 수집하기 위하여 진행하였습니다. 닭과 계란 문제일 수 있지만 이것은 ‘스포카는 어떤 제품을 만들고자 하는가’하는 고민과 맞닿아 있습니다.인터뷰는 총 5회에 걸쳐 아래와 PM 분들과 진행 되었습니다. 흔쾌히 인터뷰에 응해 주신 모든 분들께 감사드립니다. 각 인터뷰이와 나눈 이야기 중 인상적이었던 부분을 발췌하여 2개의 포스팅에 걸쳐 공유하겠습니다.Stephanie Shum(Director Product Management at Facebook)David Park (Refereum COO)Michael Hsu (Product Manager at FiveStars)Chris Nguyen (VP Product at Bleacher Report)홍성철 (Product Manager at Udemy)정대영 (Product Manager at Intuit)Stephanie Shum(Director Product Management at Facebook) & David Park (Refereum COO)좌측에서부터 Stephanie Shum, 옥지혜, David Park제품팀에 대한 동기부여는 PM의 중요한 역할 중 하나입니다. 팀에의 동기부여를 어떻게 하나요?S: 모든 제품팀의 구성원은 실제 사용자가 사용하는 제품을 만들고 그것이 비즈니스 임팩트가 있을 때 신나게 일할 수 있다. 그리고 제품이 전달하는 가치가 유의미하고 수익을 창출할 때 즐거워한다. 실제 사용자를 만날 수 있는 기회를 제공하고 팀에서 작업한 내용의 비즈니스 임팩트를 지속적으로 공유해야 한다.D: 엔지니어로 일할 당시에 중요하다고 생각하지 않는 것을 만들고 심지어 배포도 하지 못했을 때 가장 의욕이 떨어졌다. 진행 중인 작업의 사업적인 의미를 알리거나 테스트를 진행하는 이유를 팀에 설명할 수 있어야 한다. 사람들은 똑똑하고 쓸모 없는 것을 만드는 일을 싫어한다. 엔지니어를 이해하는 것은 매우 중요하다. 모든 엔지니어와의 원온원 면담을 진행하여 팀의 상태를 알고 그들이 행복할 수 있도록 노력해야 한다.S: 사람을 움직이는 것이 무엇인지 알아야 한다. 어떤 사람은 제품에 대한 스토리텔링에 흥미를 가지기도 하고 데이터 기반의 설득이 효과적인 사람도 있고 신기술에 관심을 보이는 사람도 있다. 나는 각자의 자기효능감을 느낄 수 있도록 실제 사용자와 대면하는 경험을 주는 것이 중요하다고 생각한다.제품팀이 잘 하고 있는지에 대하여 어떠한 잣대로 평가하나요?S: 제품팀이 행복하고 제품이 목표를 달성하고 있다면 잘 하고 있는 것이다. 페이스북은 서로에 대한 피드백에 대하여 열린 편이라 의견 교환이 빠르게 자주 이루어진다. 제품팀의 직무 만족도에 있어 업무 외적인 부분도 PM이 관장하는 영역이다. 이를테면 모종의 이유로 팀의 분위기가 침체 되었을 때 팀 전체 티타임을 가지면서 휴식할 수 있도록 유도하는 것도 PM의 역할이다. 어찌 보면 PM의 역할은 파티 플래너와 같다.D: 제품팀의 모든 평가는 제품의 비즈니스 임팩트에 달려있다. 유능한 피엠은 적절한 시점에 제품에 필요한 기능을 배포하는 데에 있다.제품의 목표를 달성하지 못했을 때의 경험을 공유 해주세요.S: 목표 달성을 하지 못함으로 인해서 무엇을 얻었는지가 명확하다면 그것은 실패가 아니다. 이를테면 페이스북의 경우, 매해 안정적으로 셧다운 했거나 유의미한 실패를 한 팀의 PM에게 상을 준다. 특정 팀은 수립된 전략에 따라 제품을 만들었다. 결과적으로는 목표를 달성하지 못했는데 개발 과정에는 문제가 없었으나 수립된 전략의 재검토가 필요하다는 결론이 났다. 그 팀의 PM이 그 해의 수상자였다.기술 조직이 아닌 팀과의 커뮤니케이션은 쉽지 않습니다. 영업 조직과의 커뮤니케이션에 있어 팁이 있나요?S: 제품팀의 인원이 주기적으로 현장에서 실제 사용자와 주변환경을 마주할 수 있도록 하자. 영업 조직에게 제품팀이 영업환경에 대하여 진지하게 생각한다는 것을 보여줄 필요가 있다. 반대로 영업과 사업개발 조직은 사용자 피드백의 필터가 되어야 한다. 이들은 수많은 의견을 청취하지만 모든 내용을 제품팀에 전달하지 않아야 한다. 비즈니스상 필요하다고 생각하는 몇 가지를 추려 제품팀에 전달하고 제품팀은 이를 실행할 수 있는 계획을 세우는 일을 담당한다. 서로의 일에 대한 존중과 공감 그리고 제품과 사용자와의 밀접한 관계를 언제나 염두에 주는 것이 중요하다.D: 인정 역시 중요하다. 제품팀의 인원을 포함하여 기술 조직이 아닌 팀과의 협업이 있는 프로젝트가 런칭한 경우, 모두가 볼 수 있는 메일 등을 통해 감사를 전하는 것도 팁이다.Michael Hsu (Product Manager at FiveStars)Fivestars 인터뷰 진행을 위해 게스트 체크인 중스스로가 유능한 PM이라는 것을 어떤 잣대로 평가 하나요?M: PM의 역할과 권한은 제품마다 그리고 조직마다 모두 다르다. 과거의 경험을 미루어 볼 때, 회사의 규모를 불문하고 PM은 그 자신이 제품의 성공을 책임 지는 사람이다. 따라서 구체적으로 무슨 일을 하는지 보다는 제품이 성공하기 위해서라면 다양한 일을 해야 한다.나는 3가지를 중점적으로 생각한다 - “제품(팀)이 사업목표에 기여하고 있는가”, “제품(팀)이 각 고객에게 유의미한 가치를 전달하고 있는가”, “각 팀(원)이 자신이 이루고자 하는 바를 달성하고 있는가”. 자원이 한정적이라는 것을 언제나 잊어서는 안된다. 최대의 비즈니스 임팩트를 낼 수 있는 선택을 해야 하고 이를 하기 위해 업무에 우선순위를 부여함에 있어 단호 해야 한다.현재 담당하고 있는 팀의 구성은 어떻게 되어 있나요?M: 제품팀만 두고 보았을 때, 전체 인원 중 10%가 운영만을 전담하는 팀이다. 영업인원 대비 비율은 1:7 정도에 해당한다. 이외의 팀은 각자 새로운 기능을 만드는 업무를 담당한다. (서비스 특성 상 버그가 많을 수 밖에 없는데, 운영 팀의 동기부여는 어떻게 하는지?) 우리 조직의 경우 신규 기능 개발 보다 기존 서비스 유지보수에 엔지니어들이 관심이 많다. 실제 사용자가 사용하는 것을 보고 왔을 때는 더욱 그러한 편이다.조직 내 PM이 모자라는 상황일 때 어떤 방식으로 일할 수 있을까요?M: 권한을 위임한다. 유저 스토리 작성, 기능 요구사항 구체화 하는 일 등 가시화 되지 않는 일지만 반드시 진행해야 하는 일을 팀원에게 위임하는 방법이 있다. 이 때 각 기능의 개발을 위한 비용과 시간 계산 등에 대한 책임도 함께 질 수 있도록 하는 것이 좋다.기능에 대한 요구사항은 어떻게 수렴하나요?M: 각 팀 단위로 스프린트에서 진행할 티켓을 정하고 백로그 관리를 담당하게 된다. 이 절차는 기술적인 요구사항이 한정적인 자원 안에서 처리 된다는 점과 비즈니스 임팩트의 여하에 따라 우선순위를 정하는 협상의 과정이라는 것을 가시화 한다는 점에서 유효하다. 요구사항을 발의 하는 사람은 어떠한 배경에서 해당 기능을 제안을 하고 그것이 가져올 비즈니스 임팩트에 대한 내용을 포함하여 발의할 수 있어야 한다.우선순위를 결정함에 가장 중요한 잣대는 비즈니스 임팩트를 얼마나 발생시킬 수 있느냐이다. 운영팀이 대응할 버그를 결정함에 있어서도 데이터를 기반으로 한다. 신규 기능에 대한 요구사항은 이 회의체에 접근하기 이전에 필터링 되어 발의되며 마찬가지로 기존 업무와의 우선순위를 조정하여 스프린트 항목을 정한다.Chris Nguyen, 홍성철님과 정대영님의 인터뷰와 인터뷰를 통해 얻은 인사이트는 다음 포스팅에서 다룹니다. 마지막으로 스포카는 현재 제품을 함께 만들어 나갈 PM을 채용 중입니다. 관심 있으신 분들의 많은 지원 부탁 드립니다.#스포카 #기업문화 #조직문화 #팀원소개 #인터뷰 #회사소개
조회수 2563

Next.js 튜토리얼 3편: 공유 컴포넌트

* 이 글은 Next.js의 공식 튜토리얼을 번역한 글입니다.** 오역 및 오탈자가 있을 수 있습니다. 발견하시면 제보해주세요!목차1편: 시작하기2편: 페이지 이동 3편: 공유 컴포넌트 - 현재 글4편: 동적 페이지5편: 라우트 마스킹6편: 서버 사이드7편: 데이터 가져오기8편: 컴포넌트 스타일링9편: 배포하기개요Next.js는 전부 페이지에 관한 것입니다. React 컴포넌트를 export하고 그 컴포넌트를 pages 디렉터리 안에 넣어 페이지를 생성할 수 있습니다. 그러면 파일 이름을 기반으로 고정된 URL를 가지게 됩니다.export 된 페이지들은 JavaScript 모듈이므로 다른 JavaScript 컴포넌트를 이 페이지들 안에 import 할 수 있습니다.이는 어떤 JavaScript 프레임워크에서든 가능합니다.이번 편에서는 Header 컴포넌트를 만들고 여러 페이지들에서 사용해 볼 예정입니다. 마지막에는 하나의 Layout 컴포넌트를 구현하고 어떻게 이것이 여러 페이지들의 모양을 정의하는데 도움이 되는지 살펴볼 것입니다.설치이번 장에서는 간단한 Next.js 애플리케이션이 필요합니다. 다음의 샘플 애플리케이션을 다운받아주세요:아래의 명령어로 실행시킬 수 있습니다:이제 http://localhost:3000로 이동하여 애플리케이션에 접근할 수 있습니다.Header 컴포넌트 구현하기Header 컴포넌트를 구현해봅시다.다음과 같은 components/Header.js를 추가해주세요.이 컴포넌트는 애플리케이션에서 이용가능한 페이지에 대한 두 개의 링크가 있습니다. 또한 보기 쉽도록 링크를 스타일링 하였습니다.Header 컴포넌트 사용하기다음으로 페이지들 안에 Header 컴포넌트를 import하고 사용해봅시다. index.js 페이지를 다음과 같이 변경해주세요:about.js 페이지도 똑같이 변경할 수 있습니다.지금 http://localhost:3000로 이동하면 새로운 Header가 보이고 페이지 이동이 가능합니다.이 애플리케이션에서 간단한 몇 가지를 수정해봅시다!- 애플리케이션을 종료하세요.- conponents 디렉토리의 이름을 comps로 바꾸세요.- ../components/Header 대신에 ../comps/Header로부터 Header를 import 하세요.- 애플리케이션을 다시 실행시키세요.동작하나요?- 네- 아뇨. "컴포넌트를 찾을 수 없습니다"라는 에러가 발생합니다.- 아뇨. "컴포넌트는 components 디렉토리 안에 있어야합니다"라는 에러가 발생합니다.- 아뇨. "comps는 잘못된 디렉터리입니다"라는 에러가 발생합니다.컴포넌트 디렉토리예상대로 잘 동작합니다.꼭 특정한 디렉토리에 컴포넌트를 둘 필요는 없습니다. 원하는 대로 이름을 설정할 수 있습니다. 특정한 디렉토리는 pages 디렉토리뿐입니다.pages 디렉토리 안에 컴포넌트를 생성할 수 있습니다.Header 컴포넌트는 이를 가르키는 URL이 필요하지 않기 때문에 pages 디렉토리 안에 두지 않았습니다.레이아웃 컴포넌트애플리케이션 안의 다양한 페이지에서 공통의 스타일을 사용할 예정입니다. 이를 위해 공통 레이아웃 컴포넌트를 만들고 각 페이지에서 사용할 수 있습니다. 여기 예시가 있습니다:components/MyLayout.js에 다음의 내용을 추가해주세요:위와 같은 코드를 작성하면 다음같이 원하는 페이지에서 레이아웃을 사용할 수 있습니다:http://localhost:3000 페이지로 이동하여 확인할 수 있습니다.이제 레이아웃에서 {props.children}을 지워보고 무슨일이 일어나는지 살펴봅시다.무슨 일이 일어날까요?- 아무 일도 일어나지 않을 것이다- 표시되는 페이지의 내용이 사라질 것이다- "레이아웃은 내용이 필요합니다"라는 에러가 발생할 것이다- 브라우저의 컴포넌트에 대한 경고 메시지가 표시될 것이다하위 컴포넌트 렌더링하기{props.children}을 삭제하면 Layout은 아래와 같이 Layout 엘리먼트 하위에 둔 내용들을 랜더링하지 못합니다:이것은 레이아웃 컴포넌트를 생성하는 방법 중 하나입니다. 다음은 레이아웃 컴포넌트를 생성하는 다른 방법들입니다: 컴포넌트들 사용하기공유 컴포넌트를 사용하는 두 가지 경우를 다뤘습니다.1. 공통 Header 컴포넌트2. 레이아웃스타일을 지정하고 페이지 레이아웃 및 기타 원하는 모든 작업에 컴포넌트들을 사용할 수 있습니다. 더불어 NPM 모듈에서 컴포넌트를 import 하고 사용할 수도 있습니다.#트레바리 #개발자 #안드로이드 #앱개발 #Next.js #백엔드 #인사이트 #경험공유
조회수 3107

HIG 비교 분석

HIG__HIG__는 __Human Interface Guidelines__의 약자로 비주얼 적인 디자인 규칙을 설명하고, 작업 동작에 대한 설명과 기능적인 설명을 통해 애플리케이션 __개발을 어떻게 하면 좋을지에 대한 방식을 추천한 개발 문서__입니다. 그 대표적인 예로 iOS HIG와 Android HIG 두 개가 있습니다. 이번 글에서는 두 가지의 HIG 대한 특징에 대해 알아봅시다.iOS HIGiOS HIG는 iOS의 애플리케이션을 개발하는 데 있어서 아주 중요한 문서입니다. 왜냐하면 이 문서가 앱 개발을 할 때 __기본적으로 지켜줘야 할 부분들을 설명__하고 있고, 그 내용이 지켜지지 않을 시 __App store에서 거절(reject) 될 수 있기 때문__입니다. 따라서 iOS HIG를 꼭 읽고 가이드라인에서 제시한 기준에 따라 개발을 하셔야 합니다.iOS HIG는 아래와 같은 내용을 담고 있습니다.플랫폼의 특성휴먼 인터페이스 원칙어플리케이션 디자인 전략iOS로 전환한 어플리케이션 사례사용자 경험 가이드라인iOS 기술 가이드라인iOS UI 요소 가이드라인아이콘과 이미지 가이드라인Android HIGAndroid HIG 또한 개발할 때 참고하면 좋습니다. iOS HIG처럼 기본적으로 지키지 않으면 거절(reject) 되거나 하지는 않지만, __Android가 제공해주는 다양한 기능을 설명__해주었습니다. 하지만 해당 문서는 플랫폼의 특성 등의 UI 요소들에 대한 내용이 부족하므로 __Android Design을 함께 참고 해서 보시면 개발하시는 데 도움__이 되실 것입니다.Android HIG와 Android Design는 아래와 같은 내용을 담고 있습니다.애플리케이션 개발 원칙어플리케이션의 비주얼 스타일 가이드 라인Android UI 패턴 가이드라인아이콘 디자인 가이드라인작업 디자인 가이드라인메뉴 디자인 가이드라인두 HIG의 애플리케이션 개발 가이드라인 비교iOS : iOS HIG안에 휴먼 인터페이스 원칙을 보면 사용자가 직접 선택해야 한다든지, 눈으로 보고 선택해야 된다든지 하는 내용이 있습니다. 그것을 보면 iOS는 사용자 중심 관점을 가진 개발 가이드라인이라는 것을 알 수 있고, 개발자에게 애플리케이션 개발 전략에 대한 내용도 가이드라인에서 제시하고 있습니다.Android : Android HIG안에 애플리케이션 개발 원칙을 보면 강력한 화면과 소리로 즐거움을 제공하거나, 다양한 기능에 대한 내용이 있습니다. 그것을 보면 Android는 심미성 중심 관점, 기능성 중심 관점을 가진 개발 가이드라인이라는 것을 알 수 있고, 개발자에게 애플리케이션 개발에 대해 iOS와 달리 개발 전략보다는 다양한 기능이 있으니 개발자의 자유에 맡겨 다양하게 개발하는 것을 가이드라인에서 제시하고 있습니다.두 플랫폼에 대한 UI 가이드라인 비교플랫폼에 따른 UI 크기 설정의 차이iOS : iOS는 디바이스들이 한정되어 있기 때문에 아이콘이나 레이아웃이 일정합니다. 따라서 iOS HIG에서 제시한 UI 크기를 지켜주셔야 합니다.Android : Android는 디바이스들이 해상도가 다 다르고 디스플레이들이 다양하다 보니 레이아웃 최적화를 해야 합니다. Android Design에서 이를 해결하는 방법으로 두 가지 방법을 제시하였습니다. 기본이 되는 중간 크기에서 일정 비율로 높이거나 줄이고 아니면 아예 큰 크기의 디스플레이로 시작하여 필요하다면 일정비율로 줄이는 방법을 권장하고 있습니다.터치 동작에 의한 플랫폼의 행동 비교iOS HIG는 터치 동작을 드래그나 대상을 선택하는 행동을 하는 것으로 정의하였습니다.Android Design에서는 터치 동작을 단순한 터치와 오래 누름을 통한 터치 두 가지로 나누어 정의하였습니다. 단순한 터치는 iOS HIG와 같으나 오래 누름을 통한 터치는 컨텍스트 메뉴나 컨텍스트 액션 바를 사용하는 데 이용됩니다.알림 기능에 대한 비교두 플랫폼 모두 짧은 단어들로 명시하기를 원합니다. 그러나 기술적인 문제나 어떤 설명이 필요한 상황이면 사용자에게 충분히 설명해야 합니다.iOS : iOS HIG에 경우 알림 버튼이 2개일 경우 항상 왼쪽 버튼이 어두운색이어야 하고 오른쪽은 밝은색이어야 한다고 정의합니다. 왜냐하면 가끔 사용자가 내용을 읽어보지 않고 버튼을 누르는 경우도 있기 때문에 오른쪽 버튼은 안전한 기본 작업을 수행하게 하여야 합니다. 위험성을 가진 액션을 제공할 경우 취소버튼을 오른쪽 버튼으로 하여 밝게 해야 합니다. 그렇지 않은 안전한 액션일 경우 취소 버튼을 왼쪽에 어둡게 배치해야 합니다.Android : Android Design에서는 알림 버튼의 배치나 색에 대하여 어떠한 가이드라인을 제시하지 않았습니다. 그러나 배치와 색에 관하여 다양한 디자인을 사용할 수 있도록 다양한 배치와 색에 대해 기술하였습니다.BAR 기능에 따른 비교1현재 뷰의 제목을 나타냅니다. 그리고 뷰의 이동을 나타낼 수 있는 버튼을 추가할 수 있으며, 뷰에 있는 내용을 관리할 수 있는 버튼을 추가할 수 있습니다.2뷰나 모드를 빠르게 전환을 할 때 주로 사용합니다. 모드 요소들에 대한 기능 버튼을 가지는 기능으로서 사용하면 안됩니다.3디스플레이를 전환할 때 주로 사용합니다. 위의 Bar와의 뷰나 모드전환보다는 더 크게 디스플레이가 전환한다고 생각하시면 더 알아들으시기 쉬우실 것입니다. 그리고 액션을 제공하거나 모드 요소들에 대한 기능 버튼을 제공할 때 사용합니다.차이점Tool BarBottom BarTab BarTop BarNavigation BarMain Action BariOSAndroid가이드라인에서 주로 버튼의 사이즈나 최대 몇 개까지 버튼을 배치하는지에 기술하였습니다. 그리고 Tab Bar와 Tool Bar 모두 아래에 있어 사용하기 때문에 두 가지를 같이 사용하지 못합니다.가이드라인에서 주로 버튼을 기능에 따라 다양한 모양으로 나누었습니다. 그리고 iOS와는 달리 Top Bar와 Bottom Bar의 위치가 나뉘어 있어서 두 가지의 기능을 동시에 사용 가능합니다.각 플랫폼별 고유 기능iOS : iOS HIG에서 iOS만의 고유 기능을 들자면 그 대표적인 예로 액션 시트를 들겠습니다. Tool Bar에 있는 버튼을 눌러서 일종의 선택을 표현하는 기능입니다. 액션 시트는 위에 있을수록 사용자 눈에 잘 띄고 위험성 있는 버튼은 빨간색으로 사용해야 합니다. 그리고 사용자가 가끔 홈 버튼을 누르려다 화면의 아래쪽을 누르는 경우가 있으므로 맨 아래 버튼은 취소 버튼으로 해야 합니다.Android : Android HIG에서 Android만의 고유 기능을 들자면 그 대표적인 예로 Holo와 Navigation Bar에 대해 들겠습니다. 둘 다 이번에 ICS 로 업그레이드되면서 나온 기능입니다. Holo에 경우 단조로운 Android의 스타일을 다양하게 바꾸기 위해 나온 기능입니다. Android의 Navigation Bar의 경우 iOS의 Navigation Bar와 엄밀히 말하면 다릅니다. Virtual Navigation Bar로 예전에 디바이스에서 버튼으로 있던 것을 Bar 형태로 가지고 온 것입니다.글을 마치면서이번 글에서는 대략 두 종류의 HIG에 대해 다뤄 봤습니다. 실제로 저희 앱에 가이드라인의 내용을 적용하였고 가이드라인에 대한 자세한 내용이 궁금하시면 아래의 링크를 참조해 주시길 바랍니다.iOS HIG : iOS Human Interface GuidelineAndroid HIG : Android Human Interface GuidelineAndroid Design : Android ICS Design#스포카 #HIG #디자인 #애플리케이션 #앱디자인 #프로토콜 #협업 #가이드라인 #인사이트 #꿀팁
조회수 2286

[Buzzvil People] Kay Kim, Chief Finance Officer

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 김규홍입니다. 버즈빌에서는 Kay(케이)로 불리고 있습니다. 저는 한국 공인회계사이고 딜로이트안진회계법인에서 사회생활을 시작했습니다. 회계법인에서는 감사와 M&A부서에서 일했으며 이후 쿠팡 회계팀장, 옐로오투오 재경 실장을 거쳐 작년 4월부터는 버즈빌의 CFO를 맡고 있습니다. 퇴근하면 육아에 집중해야 하는 두 아이의 아빠이기도 합니다. 회사와 가정 모두 가장 바쁜 시기에 있어 정신이 없지만, 하루하루 즐겁게 지내고 있습니다. 2. 어떻게 버즈빌에 오시게 되셨나요? 회계법인을 퇴사하고 스타트업 업계로 들어오면서 좋은 스타트업에서 CFO가 되는 목표를 가지게 되었습니다. 저는 몇 번의 이직을 통해 경력을 개발해 왔으며, 스스로 CFO 업무가 가능하다고 판단한 시점에서 헤드헌터를 통해 버즈빌을 소개 받았습니다. 처음에는 관심이 있던 업종이 아니어서 큰 관심이 없다고 거절했었는데, 마침 버즈빌에 대해 알고 있던 지인이 좋은 피드백을 주셔서 면접을 보게 되었습니다. 면접을 보면서 제 선입견이 좋은 방향으로 변하게 되었고, 면접 과정에서 회사의 대표님들(John & Young)과 많은 이야기를 나누면서 이런 사람들이 이끌어가는 회사라면 같이 한번 일해보고 싶다는 생각이 들어서 합류를 결정하였습니다.  3. 버즈빌에서 어떤 업무를 담당하고 계신가요? CFO를 맡고 있으며, 회계/세무/IR 등 재무 관련 업무를 총괄하고 있습니다. 현재는 회사의 재무 정보가 신뢰성을 담보한 상태에서 적시성을 가질 수 있도록 시스템을 만드는 것에 집중하고 있습니다. 이를 위해 back office의 개선, 수익 인식기준의 변화, ERP 도입 등을 진행하였으며, IFRS 전환  및 내부회계 관리제도의 도입 등의 프로젝트도 진행할 예정입니다. 기존의 투자자와의 커뮤니케이션, 신규 투자자의 발굴 등의 IR 업무도 주요 업무입니다. 추가로 버즈빌은 글로벌 비즈니스를 추구하는 회사임에 따라 해외 자회사와의 거래와 관련하여 이전가격세제(TP) 이슈를 사전에 준비하고 해외 자회사 관련 연결재무제표 작성 및 공시도 준비하고 있습니다. 4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 제가 스타트업에서 일하게 될 것이라고 처음 회계사가 되었을 때는 상상도 하지 못했습니다. 그 당시에는 스타트업이라는 용어조차 생소했던 것으로 기억합니다. 회계법인에서 쿠팡으로 이직하는 시점에서 스타트업이라는 존재를 알게 되었고, 당시에는 큰 기대 없이 스타트업에서 일하게 되었는데 그 이후 운이 좋아 잘 풀렸다고 생각합니다. 회계업계는 굉장히 보수적이고 안정적인 면을 추구하는 경향이 강해서 도전적이고 계속 변하는 스타트업은 서로 간에 잘 연결이 되지 않습니다. 저는 회계일을 하는 사람 중에서는 굉장히 특이하게 호기심이 많고 새로운 것을 하는 것을 좋아해서 스타트업과 잘 fit 되는 것 같습니다. 5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? 처음에 영어 이름을 쓰라고 했을 때 굳이 이렇게까지 해야 할까 하는 생각이 있었는데, 영어 이름을 쓰고 자연스럽게 부르게 되니 수평적인 소통이 되어서 좋습니다. 그리고 본인의 업무역량도 뛰어나지만, 다른 직무의 인원과 다양한 주제를 가지고 커뮤니케이션을 하고자 하는 의지를 가진 직원들이 너무 많아 신기하다는 생각이 들고 저도 자연스러운 자극을 받고 있습니다. 경력이 많아지면서, 내가 생각하는 틀에 맞춰 세상을 해석하게 되는 경향이 강해지는데 버즈빌에서 일하면서 저 자신에 대해서 많이 돌아보게 되는 계기가 되었습니다. 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 저는 스타트업이 결국 나라의 미래라고 생각합니다. 스타트업을 통해 자수성가한 세대들이 국내 부호 순위에 들어가고 있으며, 이러한 분들이 스타트업 생태계에서 액셀러레이터, 엔젤투자자 등의 역할을 수행하며 생태계를 키우고 있습니다. 지금은 꿈과 열정, 실력을 갖춘 인재들이 본인의 자본 없이 사업을 시작하고 키워갈 수 있는 환경이 서서히 갖추어 지고 있는 단계에 들어섰다고 판단합니다. 저는 제가 지금까지 스타트업 업계에서 일하면서 쌓은 많은 경험을 바탕으로 스타트업 생태계를 조금 더 좋은 방향으로 발전시키고, 이를 통해 조금 더 좋은 사회를 만들 수 있도록 기여하는 것이 꿈입니다. 
조회수 864

마케터의 인생을 편하게 해줄 앱 키워드 성과 자동분석

키워드 성과 자동분석은 ‘원래 당연히 되는 기능 아님?’이라고 생각하실 수도 있지만 상황이 조금 달라졌습니다. 유저가 키워드 광고를 클릭하고 데스크탑 또는 모바일 홈페이지로 이동했다면 이 케이스는 ‘당연히’ 자동 분석이 됩니다. 그러나 키워드 광고를 클릭했는데 앱스토어 또는 앱 실행으로 연결된다면? 분석이 되게 만들 수는 있지만 ‘자동분석’은 불가능입니다.‘그 정도는 수작업으로 분석해도 괜찮겠네’라고 생각하시는 분들이 있을 것 같습니다. 분석 시스템 개발을 업으로 하는 저희 역시도 처음엔 그렇게 느꼈었으니 말이지요. 그러나 실무에서의 몇가지 케이스를 접하고 나서 완전히 잘못된 생각이었다는 것을 알게 되었습니다. 와이즈트래커가 키워드 성과 자동분석을 개발한 계기이기도 합니다. Unhappy Case 1 – 모빌리티 앱대리운전이나 카쉐어링 등의 모빌리티 분야는 불가피하게 앱을 통해야 제대로된 서비스를 이용할 수 있습니다. 스마트폰의 GPS를 이용해서 위치정보를 파악해야 하기 때문이죠. 상황이 이렇다 보니, 모바일에서 네이버 키워드 광고를 클릭하면 실제 서비스로 연결되지 않고 앱 설치를 권유하는 브릿지 페이지로 이동하는 경우가 많습니다. 이 광고의 KPI는 앱 설치와 앱에서의 전환이 되겠지요.문제는 각각의 키워드가 얼마만큼의 앱 설치를 만들어 내는지 자동분석이 되지 않는 다는 점입니다. 자동으로 안되니 수동으로 해야지요. 키워드마다 트래킹 URL을 입력하는 식으로 말입니다. 키워드가 100개 이내라면 할만 할 텐데, 이게 수백 개 단위가 되면 정말이지 혼자서는 감당을 못합니다. 차라리 인형 눈알을 붙이고 말지요. 그런데 그것이 실제로 일어났습니다.교양 있게 표현하면 Brute-force 알고리즘, 시쳇말로 노가다. 중간에 하나만 틀려도 폭망이다.우선 트래킹 URL을 600개 생성합니다. 이 URL을 키워드에 붙여넣고 저장하는 작업을 또 600번 합니다. 도합 1200번의 노가다 끝에 ‘다시는 이 미친 일을 하기 싫다’는 생각이 가장 처음 들었다고 합니다. 이런 말도 안되는 일을 피해갈 방법이 없을지 문의를 주셨고 와이즈트래커는 뚝딱뚝딱 기능을 개발했습니다. Unhappy Case 2 – 이커머스 앱검색어에 가장 민감한 분야가 이커머스일 것입니다. 기본적으로 상품의 개수만큼 키워드가 늘어납니다. 게다가 최근에는 ‘미세먼지 마스크 추천’이나 ‘가성비 좋은 발렌타인데이 선물’처럼 구문을 검색하는 경우가 늘고 있습니다. 이제는 구문 단위로 대응해야 해서 관리하는 키워드가 늘어날 수 밖에 없는 구조입니다. 키워드가 늘어나면 광고비도 비례해서 증가할 것입니다.이렇게 키워드 광고가 엄청나게 많다 보니, 광고를 통해 모바일웹으로 들어와서 상품만 살펴보고 실제 구매는 추가 할인을 받기 위해 앱에서 끝내는 유저도 있을 것 같습니다. 그런데 어떤 키워드가 유저를 앱으로 많이 이동시키는지 알 수 없다는 것이 현업에서의 고민이었죠. 이것만 알아낸다면 “키워드 광고 성과가 이렇게 높습니다. 저를 전적으로 믿으셔야 합니다.”라고 할 수 있는데 데이터가 없다는 것이 문제였습니다.‘앱에서 구매하면 할인’을 보고 웹에서 앱으로 넘어가는 경우, 얼마나 될까?이커머스 고객사에 키워드 자동분석을 적용한 결과는 아주 인상적이었습니다. 전체 앱 인스톨 중 약 7% 정도가 웹 광고를 통해 발생하고 있었으며, 이 중 80%는 검색 광고의 영향을 받는 것으로 나왔으니까요. 인스톨을 7% 정도 늘리기 위해서 증액해야 하는 광고비를 생각하면 결코 무시할 수 있는 수준이 아니라는 이야기. 게다가 이렇게 유입된 유저의 약 10%가 구매고객으로 전환했으니 그야말로 대박이었죠. 자동분석은 이렇게 동작해요내용은 꽤 단순합니다. 자동분석이기 때문이죠. 실무자가 할게 없습니다. 자동분석이니까요!1. 유저가 네이버에서 ‘마스크’를 검색했습니다. 파워링크에 광고들이 떠있는데요, 이 중에서 쿠팡을 클릭했습니다. 2. 키워드 광고를 클릭하니 쿠팡 모바일웹으로 연결 됐습니다. 화면 하단에 ‘앱 할인’ 배너가 있네요. 이걸 클릭합니다.2-1. 만약 ‘앱 할인’ 배너를 눌렀는데 단말기에 앱이 없는 상태라면? 앱을 설치할 수 있는 스토어로 넘어가게 되죠. 앱을 설치하고 실행합니다. 3. 앱을 실행하니 ‘마스크’ 화면이 나옵니다. 이제 상품들을 살펴보면 되겠네요. 정리하자면 [네이버에서 ‘마스크’ 키워드 광고 -> 모바일웹 -> 앱 설치]로 이어진 케이스입니다. 이 과정에서 1건의 앱 설치가 발생했지요. 마케터가 아무런 설정을 하지 않아도 와이즈트래커는 이 상황을 [‘마스크’ 키워드를 통한 1건의 앱 설치]로 ‘자동분석’합니다. 가만히 있어도 리포트에 데이터가 착착 쌓입니다. 우리가 만들었지만 신박하군요! 손발이 편안한 마케팅을 위하여마케팅 오토메이션 솔루션의 수준이 높아져서 그것이 대중화되면 분명 지금보다 손이 덜 가는 환경에서 실무를 진행할 수 있을 것입니다. 그때가 될 때 까지는 머리 속에서 행복회로를 굴리며 버티는 정신이 필요할지도 모르겠습니다.그렇다고 하더라도 수백개 키워드에 일일이 트래킹 URL을 박아 넣는 일은 지금이라도 사라져야 합니다. 위의 두가지 사례와 비슷한 문제가 있다면 와이즈트래커에 알려주세요!
조회수 1015

[어반테이스트] 와인과 함께한 곱창싸롱!

"지그므은~~~~ 곱.창.시.대!"(출처) MBC '나 혼자 산다'2018년 동시대를 살고 있는 분이라면 요즘 이 음식을 빼놓을 수가 없죠.바로바로 '곱창'먹어도 먹어도 질리지 않고,생각할수록 설레이는 음식이에요 ><어반테이스트라는 맛집탐방 복지문화가 시작되고 '왜 곱창 먹고 오신 분이 없을까....'의문이 들던 찰나에!드.디.어. 곱창 테이스트를 즐긴 팀이 생겼어요! 곱창 맛집 썰을 풀기 전에 잠깐! 곱창 지식 좀 풀고 가실게요 <알면 쓸데 있는 곱창지식>(출처) doopedia.co.kr곱창은 소의 작은 창자 즉 소창을 말하는데 보통 소의 내장을 통틀어 이야기 한대요!왼쪽에서부터 순서대로 양깃머리, 벌양, 간/처녑, 막창(홍창)왼쪽부터 곱창, 대창첫 번째 위가 양, 두 번째 위가 벌양, 세 번째 위가 처녑, 마지막 위를 막창이라고 하고, 위 다음에 연결된 소장과 대장을 각각 소창, 대창이라고 해요!식당에서 양곱창이라고 하는 것은 양(羊)의 곱창이 아니라 첫 번째 위인 양을 의미합니다. [양깃머리]양깃머리(특양)는 양에서도 두툼한 부위로 여러 내장들 중 가장 비싸고 주로 구이용으로 사용합니다. 소 한마리에서 나오는 특양 부위의 양이 많지 않아서 가격이 비싸다는....기름기가 없는 담백한 맛이고 기름진 대창과 잘 어울려서 양대창으로 묶어 부르기도 한대요. [벌양]벌양은 벌집양이라고 불리고 모양이 벌집(honey comb)을 닮아서 그렇게 이름을 붙였대요. [처녑]세 번째 위인 처녑은 1000장의 잎사위가 붙어있는 모습이라 천엽(千葉)이라고 부르기도 한대요. 구이용으로 거의 사용하지 않고 주로 간과 함께 생으로 먹는다고 합니다.저희도 애피타이져로 모둠 구이가 익는 동안 간과 처녑을 먹었지용~[막창]막창은 소의 마지막 위로 홍창이라고도 불리고 대구지역에서 유명합니다. [대창]소창 다음에 연결된 것으 좀 더 굵은 대창입니다. 원래 모습이 바깟쪽에 기름이 달려 있는데 그것을 뒤집어 안쪽으로 넣은 것입니다. 대창의 기름은 콜레스테롤 수치를 올리므로 많이 먹으면 건강에 좋지 않습니다만, 너무 고소하고 부드럽고 맛 있어서 일단 고민하지 말고 먹읍..시다![염통]염통은 심장을 말하고  가장 빨리 익기 때문에 먼저 먹어야 합니다!★ 먹는 순서 ★간, 천엽 -> 염통 -> 벌양, 양 -> 대창 -> 막창, 소창(참고) http://egloos.zum.com/hsong/v/3163122)그럼 어느정도 지식을 습득했으니이제 곱창 먹방 후기를 풀도록 하겠습니다 :) "와인과 함께한 곱창싸롱!"- 영업시간: 00시~24시 - 주소: 서울 강남구 언주로93길 31 (지번: 역삼동 677-1)  곱창싸롱 <지도보기>이번 테이스트는 역삼역 곱창 맛집 '곱창싸롱'이에요 !곱창 테이스트 멤버는 개발팀의 현목님, 종훈님과 CRO 강록님입니다!팀 결성 후 퇴근시간에 맞춰회사에서 5분거리에 있는 곱창싸롱을 갔습니다!"아 신난다~ 이 지역 곱창 몬스터는 내가 다 잡아야지~""우리 저기를 향해 갈꺼에요~"드디어 입성! 할렐루야!이것은 곱창싸롱의 메뉴입니다!모둠구이 200g (곱창+대창+막창+염통) --- 1.6만곱창 200g 1.8만막창 200g 1.6만대창 200g 1.6만특양 150g 1.9만염통 200g 1.2만깍양밥 1인분 1.2만(깍두기+특양+비빔양념+계란크러스트)이외에도곱창전골 1.2만올치다다 1.0만등의 메뉴가 있어요!저희 어반 테이스트 4기가 공략한 메뉴는 모듬구이와 깍양밥!모둠구이 3인분가운데 돌돌 말린 것부터 반시계방향으로 곱창, 대창, 염통, 막창이여요 :)물론 오발탄, 연타발 등 비싼 곱창집에 비해선 퀄리티가 좋진 않지만 그래도 저렴한 가격치곤 제법 맛있었어요 ㅎㅎ간과 천엽! 기름장에 찍어먹으면~~ 츄릅!곱창집에서 올리브를??여기는 그린, 블랙 올리브를 허브와 오일에 살짝 볶아서 나오는 것 같아요! 독특한 향이 납니다~~~~~기본으로 세팅할 때 한번 주시고 원하면 추가로 주문해야 할 것 같아요. 따로 메뉴가 있네요. 강록님이 대파 양념을 첨가하여 요리를 하신 맛나보이는 곱창 대파구이~깍양밥 1인분 /  12,000원 볶음밥류 치고는 비싼편이지만 요거요거 맛있었어요!곱창싸롱은와인을 가져가면 인당 5천원의 와인콜키지로 맛있는 곱창과 와인을 즐길 수 있습니다!테이블에 앉아서 먹을 수도 있고, 양철통 위의 스텐리스 테이블에서도 스툴에 앉아 먹을 수 있어요~그래서 현목님이 이날 와인을 준비해 오셨다는.. ㅋㅋㅋ"이거슨 스페인산 마트표 맛난 와인입니다. 3병에 2만원정도로 할인할 때 (집더하기에서) 사왔는데 맛있어요." - 문믈리에Campo Lindo Chrianza 스페인 Rioja 지역 와인. Cabernet Sauvignon, Tempranillo 품종 블랜딩. 2014년 빈티지. 와인과 곱창의 만남! 제법 신선하죠?와인과 곱창의 조합은 처음이었지만 제법 신선하면서 감동적이였습니다 ㅋㅋㅋ우리의 곱창싸롱 점수는?(5점 만점에)곱창싸롱은역삼역 인근 저렴하면서 이색적인 곱창을 즐기고 싶은분에게 추천합니다 :)곱창먹고 행복지수 120%취한거 아닙니다.....다음 '어반 테이스트'도 기대해 주세요 :) 출처: https://blog.naver.com/urbanbaseinc 
조회수 2168

안드로이드와 자동화 툴

모바일은 플랫폼의 생태계와 규모에 비해 개발자들이 처리해야 할 것이 매우 많습니다.서버나 타 플랫폼들 또한 개발자들의 영역이 많지만 그 영역들이 세분화되고 전문화되어 가고 있습니다. 데이터베이스, 백엔드, 프론트웨어, 인프라, DevOps 와 같이 점점 분야별로 심화되고 독립성을 갖추어 가고 있습니다.하지만 모바일은 각 플랫폼의 개발자들이 전체적인 아키텍쳐, 프론트, 내부용 데이터베이스, 리소스 관리, 배포 등이 해당 플랫폼의 소수의 개발자들에게 광범위하게 공존합니다. 다양한 분야가 전문화되기엔 변화가 잦고 규모가 점 형태로 구성이 된 경우가 많기 때문입니다.그렇기 때문에 반복적이고 불필요하게 비용이 소모되는 작업일수록 자동화 해서 최대한 코드 작성 본연에 업무에 집중할 수 있도록 환경을 구성하는 것이 중요합니다.토스랩 안드로이드 팀은 2015년 초부터 조금씩 자동화 환경을 구성하여 현재는 아래와 같습니다.다국어 문자 관리 자동화이미지 관리 자동화CI다국어 문자 리소스 자동화1. 다국어 글로벌 담당자의 원본 문서토스랩은 다국어 지원을 위해 글로벌 번역 문서를 관리하고 있습니다. 문서는 Google Drive 를 통해서 관리되고 있으며 기획/개발 파트에서 다국어 지원을 위한 리소스를 기입하면 각 언어의 담당자들이 해당 언어를 번역하고 있습니다.구성은 아래와 같습니다ABCDEFGH영어한국어일본어중국어-간체중국어-번체웹키ios 키안드로이드 키2. 기존 작업기존에는 해당 언어의 번역 데이터를 추가하기 위해 개발 파트에서 수동으로 각 언어의 리소스 파일에 추가하는 형태로 진행하였습니다.이러한 작업의 단점은 언어별 리소스 파일에 키-값 형태의 문자 리소스를 추가하는 작업을 반복적으로 해야 한다는 것입니다. 또한 반영이 된 후에 수정된 문자에 대해서 반영하기가 매우 어렵고 실수도 빈번하게 발생합니다.이러한 가능성을 최소화 하기 위해 자동으로 문자 리소스를 갱신하는 작업을 진행하였습니다.3. 안드로이드 파트를 위한 별도 필터 파일 추가|A|B|C|D|E|F| |—-|—-|—-|—-|—-|—-| |영어|한국어|일본어|중국어-간체|중국어-번체|안드로이드 키|가급적 원본 파일에 대한 조작을 피하기 위해 안드로이드용으로 Read-Only SpreadSheet 를 별도로 생성하였습니다.해당 작업을 위해 Google SpreadSheet Script 를 사용하였습니다.4. 자동화 툴 작업자동화 툴의 역할은 크게 3가지였습니다.안드로이드용 필터 파일을 다운로드한다.Spread-sheet를 분석해서 다국어용 자료구조로 변환한다.다국어용 자료구조를 XML 파일로 변경한다.툴은 Python 스크립트로 작업하였습니다.5. Gradle Task 로 추가별도의 Python 파일을 실행해도 되지만 Gradle Task 로 추가하여 Android Studio 에서도 Task 를 실행할 수 있도록 하였습니다.개발팀에서 안드로이드 키를 원본 문서에 추가한 후 Gradle Task 실행하면 바로 반영되도록 하였습니다. 기존의 방식과 가장 큰 차이점은 Merge 시 충돌 이슈에 대해서 더이상 관여하지 않아도 된다는 것입니다. 가장 최근 시점을 기준으로 자동화 Task 를 실행하면 모든 리소스가 최신화되기 때문에 충돌이 난다하더라도 무시하고 새로 Task 를 실행함으로써 충돌에 의한 이슈를 완전히 배제하고 작업할 수 있다는 장점이 생겼습니다.더 나아가 현재는 Android 용 리소스 Key를 기획 팀에서 기획시 적용하도록 하기로 현재 논의되고 있습니다. 이러한 논의가 반영된다면 더이상 리소스 관리에 있어서 개발파트에서 관리 할 필요가 없어지므로 다국어 리소스에 반영해야할 리소스 또한 최소화 될 것이라 기대하고 있습니다.이미지 리소스 자동화1. 기존 작업앱에 사용되는 디자인 리소스는 이슈 트래커와 JANDI 의 디자인 토픽을 통해서 전달 받아 작업을 하였습니다.이런 작업 형태는 이미지 관리가 분산 될 뿐만 아니라 일관성 있는 전달 방식이 아니기 때문에 누락건이 언제든지 존재할 수 있습니다.그래서 디자인 리소스에 대한 관리를 디자인 팀이 주도적으로 하며 개발팀에서는 빠르고 편하게 이미지를 전달 받을 수 있도록 하기 위해 자동화 툴을 만들었습니다.2. 개선 작업토스랩의 디자인 팀에서 사용하는 저장소는 권한에 따라 접근이 가능하도록 API 를 제공하고 있습니다. Read-Only 권한을 부여받은 후 API 를 통하여 이미지를 다운로드하도록 툴을 구성하였습니다.툴은 Python 스크립트로 구성하였습니다.3. Gradle Task 로 추가문자 리소스와 마찬가지로 별도로 Gradle 로 툴을 이용할 수 있도록 하기 위해 별도의 Task 를 정의하여 사용하도록 하였습니다.자동화된 리소스의 관리문자와 이미지를 자동화로 관리한다 하더라도 개발자가 필요에 따라 임의로 추가/수정하는 리소스가 존재 할 수 있습니다.이를테면 다운로드한 이미지 리소스를 활용한 Selector-Drawable 과 같은 것들입니다.이에 따라 자동화 처리된 리소스들은 별도의 관리를 위해 추가적으로 ResourceSet 을 만들었습니다. android { // ...중략 sourceSets { main.res.srcDirs += ${별도의_리소스_경로} } } 이러한 방식을 통해서 자동화된 리소스와 추가적한 리소스를 분리하여 발생할 수 있는 문제를 최소화 하였습니다.지속적 통합 (Continuous Integration, CI)자동화와 관련되어서 결코 빠질 수 없는 내용입니다. 빌드, 테스트, 배포, 리포팅에 이르기까지 이 모든 과정에 있어서 자동화 되지 않았다면 상상하기 어려운 작업들입니다.토스랩에서는 Jenkins 를 활용하여 빌드-테스트-리포팅을 하고 있습니다.1. 빌드 대상빌드의 의미는 최소한 컴파일 오류가 발생하지 않는 코드들이 최종 상태로 관리되고 있음을 의미합니다. 그러기 때문에 언제나 중앙 저장소에 반영되었거나 반영될 예정의 소스들은 항상 빌드 대상이라고 볼 수 있습니다.안드로이드 팀은 내부적으로 빌드 대상이 되는 브랜치를 아래와 같이 정의하였습니다.개발된 이슈가 최종적으로 반영된 브랜치 (develop)Github 에서 코드에 변경이 발생하면 이를 Jenkins 로 통보하여 해당 브랜치를 빌드합니다.개발 브랜치에 반영을 위해 코드리뷰 중인 브랜치 (features, fixes)Github 에 새로운 Pull-Request 가 발생하면 Jenkins 로 통보하여 해당 브랜치를 빌드합니다.테스트와 리포팅은 이 시점부터 발생한다고 볼 수 있습니다.2. 빌드빌드를 하는 과정에 기본적인 정적 분석을 사용하고 있습니다. 코드의 Convention 이나 복잡도 등을 측정하고 이를 분석하여 수정할 부분을 파악하기 위해서입니다.3. 테스트안드로이드팀은 작년 중순까지 Robolectric 이라는 Test Framework 을 사용하였으나 여러가지 이슈로 인하여 현재는 Android Test Support Library 를 사용하고 있습니다. ATSL 은 에뮬레이터를 필요로 하기 때문에 Jenkins 서버에 에뮬레이터를 구동하여 Test-Bed 를 구성하였습니다.빌드 과정에서 정적 분석이 완료되면 테스트 코드를 동작 시킵니다.테스트 된 결과는 JUnit Test Report 와 Jacoco Coverage Report 를 받고 있습니다.4. 결과 리포트빌드, 테스트 결과는 Jenkins 에서 별도로 관리되고 있지만 모든 동작들은 자동화 되어 관리되기 때문에 별도의 장치가 없다면 알아채기 어렵습니다.좀 더 빠른 피드백을 받기 위해 JANDI-Webhook 기능을 이용하여 결과 리포팅을 바로 받아 확인 할 수 있도록 하였습니다. 또한 Github Pull-Request 화면에서 Build-Status 연동하여 코드리뷰 하는 과정에서 잠재적 오류를 찾을 수 있도록 하였습니다.※ 빌드된 결과물의 배포는 내부적인 정책으로 현재는 하지 않고 있습니다만, 현재 가용 가능한 리소스 안에서 해결 방안을 찾고 있습니다.총평자동화의 가장 큰 목적은 반복적이지만 시간을 소요하기엔 가치가 떨어지는 작업을 단순화 하기 위함이었습니다. 여기서 오는 가장 큰 의미는 관리에 소요되는 시간을 최소화함으로써 생산성을 향상 시켰다는 데에 있습니다.특히 다국어 리소스와 이미지 리소스를 자동화 하기 위한 작업은 소요된 시간이 극히 미미하지만 그 효과는 매우 긍정적이라 할 수 있습니다.CI 는 초기 설정뿐만 아니라 관리가 매우 어려운 작업입니다. 해당 시스템을 총체적으로 알고 있다는 가정에서 해야 하며 정책적으로 규정해야 하는 것들도 있습니다. 하지만 결과물 그 자체에 대한 관리를 위해서는 없어서는 안되는 도구이며 정적분석과 자동화 테스트 등 다양한 효과를 얻을 수 있기 때문에 많은 개발자들에게 권장하고 싶습니다.#토스랩 #잔디 #JANDI #개발 #효율 #자동화툴 #업무환경
조회수 687

앱 어트리뷰션 가이드 - 입문

앱 어트리뷰션 툴은 앱 마케팅의 필수 도구로 자리잡았고 갈수록 활용범위가 증가하고 있습니다. 그러나 툴을 사용하는 현장에서는 ‘어렵다’라는 반응이 여전합니다. 그래서 이번 ‘앱 어트리뷰션 가이드 (A Walkthrough of App Attribution)’에서는 툴 유저들이 공통적으로 느끼는 어려움을 해소할 수 있는 내용을 다뤄보려 합니다.가이드는 어트리뷰션과 연관된 주요 개념과 기술에 대한 설명을 주로 다루게 됩니다. 이를 통해 어트리뷰션 툴이 필요할 수 밖에 없는 이유와 애드테크 생태계에서의 역할, 그리고 복잡한 어트리뷰션 기능들이 왜 필요하며 어떤 원리로 동작하는지에 대한 이해를 높이는 것이 목적입니다.첫번째 글인 ‘앱 어트리뷰션 가이드 – 입문’에서는 어트리뷰션 툴이 등장하게 된 배경과 문제 해결 방법을 설명합니다. 등장 배경: 과금 기준이 다르다웹에서 집행하는 키워드 광고를 클릭하면 바로 웹사이트로 연결되고 사이트에 방문한 상태가 됩니다. 광고 클릭 자체가 사이트 방문인 셈입니다. 광고 클릭이 트래픽을 늘려 주었으니 클릭당 비용(Cost Per Click, CPC)을 지불하는 것이 합리적입니다.그러나 앱 광고를 클릭하면 앱이 열리지 않습니다. 스토어를 거쳐 단말기에 앱을 설치한 후 실행까지 해야 앱을 방문한 상태가 됩니다. 결국 광고 클릭이 앱의 트래픽을 직접적으로 늘려주지 못하며, 설치된 앱이 실행 되어야만 트래픽이 늘어납니다. 그래서 설치된 앱의 최초 실행수(Cost Per Install, CPI)를 기준으로 비용을 지불하는 것이 합리적입니다.트래픽을 늘려준 액션에 광고비를 지불하는 것이 합리적이다. 그래서 앱은 CPC가 아닌 CPI를 사용한다.이런 이유로 CPI는 앱 생태계의 광고비 과금 기준으로 자리잡습니다. 하지만 기준을 CPI로 변경하는 초기에는 장애물이 있었습니다. 광고를 통해서 몇 개의 앱이 설치 되었는지를 정확하게 알 수 없었기 때문입니다. 앱 설치 숫자를 확인하는 것은 간단한 일인데 왜 문제가 되는지 의문을 가질 수도 있겠지만, 조금 깊이 들여다보면 생각보다 어려운 문제임을 알 수 있습니다.우선 전체 앱 설치 중에 광고를 통한 설치가 몇 건인지 분리해 내기가 쉽지 않습니다. 플레이 스토어나 앱스토어에서 그날 그날의 설치 개수를 확인할 수 있지만, 그 중에 몇 개가 유료 광고로 인한 설치인지는 보여주지 않기 때문입니다. 이렇게 되면 광고 매체에 확인해 볼 수 밖에 없습니다.하지만 매체 역시 앱 설치 개수를 모르는 것은 마찬가지 입니다. 매체는 자신이 관리하는 영역에서 클릭이 발생한 것을 감지함으로써 유저가 광고를 클릭하고 스토어로 넘어간 것은 알 수 있으나, 스마트폰에서 앱이 실행되는 것은 매체의 관리 영역 바깥의 일이므로 유저가 클릭 이후에 앱을 받아서 실행을 했는지 그렇지 않은지는 분명하게 알 수 없습니다. 결국 광고주와 매체 모두 광고를 통한 앱 설치 숫자를 알지 못하기 때문에 CPI를 기준으로 광고비를 산정할 수 없는 문제가 남게 됩니다. 어트리뷰션 툴이 문제를 해결하는 방법이 문제를 해결하기 위해 등장한 것이 앱 어트리뷰션 툴입니다. 어트리뷰션 툴의 핵심 역할 중 하나는 성공적으로 설치된 앱들 중에서 광고의 영향을 받은 앱 설치가 얼마나 되는지를 측정해 내는 일입니다. 광고주와 매체 모두 정확하게 측정할 수 없었던 이 수치를 어트리뷰션 툴이 어떤 방법으로 측정하는지를 요약하면 다음과 같습니다.1. 트래킹 URL 활용유저에 의해 광고가 클릭 되는 것을 분석하기 위해 광고물에 트래킹 URL을 세팅합니다. 트래킹 URL이 설정되어 있는 광고를 유저가 클릭하게 되면, 어트리뷰션 툴은 어떤 매체의 광고가 언제 누구로부터 클릭 되었는지를 알 수 있게 됩니다. 어트리뷰션 툴은 이 정보를 측정한 뒤 유저를 앱 설치 페이지로 리다이렉트 시킵니다.2. 분석 SDK를 앱에 삽입설치된 앱이 실행까지 되는지를 분석하기 위해서 앱 자체에 분석 도구를 삽입합니다. 분석 SDK는 앱의 네이티브 영역(OS의 언어로 작성되었으며 앱의 구조를 이루는 부분)에 적용하며 앱이 실행되는 시점에 함께 동작하는 것이 장점입니다. 앱 실행 직후에 분석 SDK가 동작함으로써 앱 실행에 영향을 준 트래픽 소스(광고인지 아닌지, 광고라면 어떤 매체인지)를 검출하게 됩니다.3. 클릭 데이터와 실행 데이터를 대조광고를 통해 앱이 설치(또는 실행)되었는지를 정확하게 확인하기 위해 1번의 클릭 데이터와 2번의 실행 데이터를 대조합니다. 클릭 데이터를 통해서는 누가 언제 어떤 매체를 클릭 했는지를 알 수 있으며, 실행 데이터를 통해서는 누가 언제 어떤 매체로 유입되어 앱을 실행 했는지를 알 수 있습니다. 따라서 클릭 데이터와 실행 데이터가 정확하게 일치하는 경우에는 광고를 통한 앱 설치로 판단하게 됩니다.어트리뷰션 툴 사용자가 트래킹 URL을 만들어서 배포하는 일, 앱 개발자가 분석 SDK를 앱에 삽입하는 일, 트래킹사가 데이터를 대조하여 리포팅 하는 일 모두가 결국 광고를 통한 앱 설치를 분류해 내기 위해서 반드시 필요한 작업입니다. 어느 하나라도 부족하면 정확한 측정이 어려울 수 밖에 없겠지요.다음 글에서는 어트리뷰션의 한 축을 담당하는 트래킹 URL에 대해서 알아보도록 하겠습니다.

기업문화 엿볼 때, 더팀스

로그인

/