스토리 홈

인터뷰

피드

뉴스

조회수 1545

콘텐츠의 신들을 영접해보았다.(feat. 루프페스티발)

메디아티 주최 주관 루프페스티벌 12/05 12:00오랜만입니다. 요즘 음청나게 바빠서 통 글도 못쓰고 합정역 부근에서 벗어나지도 못한 채 노트북에 코박고 살고 있었어요. 그러다보니 12월이 와버리고 말았네요. 연말이 다가오면서 이래저래 마음도 두근두근하고 몸도 더욱 늙어가는 것 같아서 간만에 바깥바람을 좀 쐬야겠단 생각이 들었어요. 그래서 오늘은 명동성당근처의 커뮤니티 하우스 '마실' 에서 진행된 '루프페스티벌' 에 놀러갔답니다. 가히 콘텐츠의 신님들이 모인 행사라서 올림푸스 신전에 올라가는 기분으로 신성하게 계단을 밟았습니다.이번 글은 그 후기이자 리뷰이긴한데, 저는 2부가 끝난 뒤 호다닥 나와서 또 일을 하러 왔거든요. 아쉽게도 그래서 절반짜리 리뷰가 될 것 같아요. 뒷부분의 아름다운 얘기들을 듣지 못해 개아쉽지만 제가 아닌 누군가가 3,4부의 오져버린 인사이트를 공유해주실 것이라고 굳게 믿으며 제 리뷰는 '上편' 이라고 여겨주시면 감사하겠습니다.  절반짜리지만 인사이트는 견딜 수 없을 정도로 충만합니당.NOTICE가능하면 연사님들의 스피치를 고대로 담고싶었지만 말의 속도를 손가락이 도저히 따라갈 수 없어서 자르고 편집해서 제가 이해한대로 적어놨습니다. 그러니 혹시라도 연사님들의 말을 곡해하거나 슬퍼하시지 않으셨으면 좋겠습니다.(혹시 수정요청이 있으시다면 말씀해주세요.)키노트 세션#KEYNOTE퍼블리의 박소령대표님호다닥 뛰어왔지만, 박소령 대표님 스피치의 중간에 들어가게 되었어요. 명동성당 지하의 르빵에서 존맛탱빵들을 사왔는데 부시럭부시럭 비닐 소리들리지 않게 조심히 앞자리에 앉았어요. 한참 뭔가 얘기가 진행되고 있었는데 앞부분을 못들어서 들린 부분만 얘기할게요.군대나 스포츠팀처럼 '전략'을 기반으로 한 팀운영을 추구하신대요. 대표님은 지휘자, 내지는 일드'언내츄럴'의 소장역할(마츠시게 유타카)과 같이 팀원들이 일하고 움직일 수 있는 판을 만들어주는 역할을 하고 있다고 하셨어요. 리더가 직접 모든 실무의 디테일이 집착하는 것이 아닌, 조금 한 발 떨어져서. 또는 자신의 등을 보이며 전체를 지휘하는 역할을 했을 때, 좀 더 효율적인 조직이 만들어진다....라는 얘기인 것 같아요.마지막은 커피 오지게 마셔서 화장실 가느라 못들었지만, 어렴풋히 들리는 대표님의 말 중 띠용~뇌신각 종이 울렸던 내용은 '동력' 이란 단어였어요. 그래서 어떻게 무슨 힘으로 콘텐츠제작을 지속할 것인가..하는 거죠. 저처럼 끝을 잘 맺지 못하고 쉽게 흔들거리는 핑크뮬리같은 멘탈을 지닌 이들에게 가장 필요한 거예요. 동력말이죠. 저는 2019년에 어떤 힘으로 일을 해야할 지 생각을 해보았어요. 무엇이 절 움직일까요.... (카드값?..)카드값미니데모데이 세션#1더파크의 정우성대표님3가지채널에 3가지형식으로더파크의 정우성 대표님 세션이었어요. 저는 항상 우왕...콘텐츠 쩐다...라며 두 손모으고 콘텐츠에 좋아요만 누르고 사라지는 페친이죠. 간략하게 정리하면 다음과 같았어요.<채널>1. 넷플릭스2. 고전문학3. 세상모든것들의 리뷰.<형식>1. 비디오는 1-5분 홈페이지, 유튜브2. 오디오는 30-40분, 오디오클립3. 텍스트는 홈페이지이런 느낌으로다가 거의 매일올리고 계셨어요. 오져버렸당. 듣기만 해도 소름이 돋았어요. 두 분이서 운영하시는 데 날마다 콘텐츠를 쳐내는 건 정말 엄청난 일이예요..ㅠㅠ... 사실 이건 처음에 더파크의 방향성이 되게 잘 설정되어 있어서 가능했던 것 같아요. 방향성까지 대공개해주셨는데 다음과 같았어요. 대외비거나..그런건 아니겠죠?안정적인 콘텐츠 업데이트 스케쥴폭넓은 타이업 콘텐츠제작 가능성 확인단단한 취향의 공동체 확립캐릭터 상품, 이벤트 기획과 실행다른 미디어스타트업과 연대, 발굴. 육성 모색전문인력 고용이러한 방향성을 기준으로 출판, 영화, 자동차, 테크, 식음료, 정부기관, 나레이션 등 다양한 스펙트럼에서 리뷰 및 콘텐츠 제작을 진행중이라고 해요. 대표님의 체력과 지속력이 엄청나게 리스펙해요. 내 콘텐츠 만드는 것도 빡세서 전 한달 내내 바쁘면 이렇게 브런치 글도 못올리고 막 조회수때문에 뿌앵하거든요. 그런데 의뢰받은 콘텐츠를 거의 매일 만든다는 건 정말 ... 하아..(소름 앤 존경)#2널위한문화예술의 오대우대표님문화콘텐츠에 질문을 더하다.오대우대표님 말씀 : 문화예술이 지닌 지루한 이미지가 문제라고 생각해요. 수많은 정보를 한꺼번에 전달, 어려운 용어를 쓰면서 일방적인 소통에 그치는 홍보방식이 대다수니까요. 예술의 재미는 이야기에서 등장. 작품에 대한 다양한 관점을 공유하고 나누면서 재미가 발생하는 것이라고 생각해요. 그래서 커뮤니티가 중요하다고 생각합니다. 이 점을 콘텐츠로 풀어내기 시작했어요.예를 들면 백남준 선생님의 다다익선을 들어볼께요. 얼마 전 작품을 구성하고 있는 브라운관의 수명이 다했어요. 이것을 어떻게 다뤄야 할까요. 단순히 정보전달이 아닌 관점의 공유를 위해, 다양한 인터뷰와 나래이션을 통해 예술작품에 대한 복원 그리고 나아가 철학에 대한 고찰이 이루어질 수 있게 했어요.중요한 것은 타겟 자체를 다다익선에 대한 사전정보가 전혀 없다고 가정하고 상세하고 쉽게 설명했다는 점이예요. 손그림과 간단한 일러스트, 빠른템포, 직관성을 더했어요. 모바일 형식의 세로형식 영상제작과, 음악과 빠른템포를 통해 몰입도를 높였어요.콘텐츠를 '질문' 이라고 생각해요. 그러자 독자들이 대답을 하고 고민하기 시작했어요. 독창성이란 존재하는가? 라는 질문이나굴림체가 구려보이는 이유와 같은 일상접점의 질문같은 것들을 만들고 던져보았죠. 그러자 대중들의 반응이 생기기 시작하더라구요.내 생각 : 주옥같은 말(빠르게 읽지마)씀이라서 예수님말씀 옮겨적던 사도의 마음으로 타이핑했습니다. 콘텐츠에 질문이 포함되어 있어야 한다는 말은 정말 핵공감이예요. 사실 창작자가 뭔가 단정을 짓거나 정답이 나와있는 정보성 콘텐츠를 주었을 땐 끄덕거리고 난 후 생명력을 잃게 되거든요. 또는 어딘가에 저장되서 두 번 다시 빛을 보지 못한다거나 하는 식으로 말예요.(흔히 페북의 '저장됨'에 들어간 아이들처럼...그곳은 흡사 냉동실..)바이럴생각을 나눌 수 있는 명제를 던져주고 독자들 스스로 가지고 놀 수 있게끔 만드는 콘텐츠는 정말 강력한 파급효과를 지니게 되는 것 같아요. 인정?#3어피티의 박진영 대표님2534여성들의 미래를 만들어가는 콘텐츠박진영 대표님 말씀 : 2534여성들이 10년 뒤 자신의 미래에 대해 왜 확신하지 못하는가에 대한 문제의식을 발견했어요. 그래서 2534여성을 위한 생활미디어를 만들었죠. 그들에게 당면한 문제를 헤쳐나가야 할 테마를 주제로 콘텐츠 제작했어요. 그 첫번째가 '돈' 이었죠.일반적인 서적이나, 메인뉴스에서 남녀에 대한 경제프레임이 규정되어 있는 상태예요. 생산경제는 남자, 경제관리는 여자라는 프레임이 굳어진 상태랄까요. 그래서 그런 프레임을 벗어나서 정보의 레벨과 경계를 무너뜨려보고자 했어요. MONEY QNA : 뉴스레터 포맷을 활용하여 궁금했던 질문을 그들의 언어로 전달ASK_UPPITY :  1분요약 등의 짧은 영상콘텐츠를 통해서 자주묻는 질문들을 곧바로 대답해줌.(FAQ해결)머니로그 : 솔직한 돈 이야기. 어떻게 벌고 어떻게 쓰는지 7일간 직접 기록해 공유하는 코너.너의카드를보여줘 : 다양한 직종의 여성들이 자신의 카드를 꺼내서 얘기하는 코너(전)사무실내자리 : 사무실을 채우고 있는 소품들을 통해 소비와 지출에 대한 이야기를 하는 코너등등을 만들어서 진행중이예요. 그 결과7월중순런칭. 40건의 머니레터. 40%오픈율. 2천명 구독자 600명의 충성독자를 형성하게 되었고 8월 경 4번의 오프라인 세미나 이후 오프 커뮤니티의 가능성 발견했어요. 앞으로는 투자 세미나, 핀테크 컨퍼런스, 머니쇼 등을 계획 중이예요.내 생각 : 페친으로만 알던 대표님이지만 어피티의 콘텐츠는 페이스북에서 엄청 자주 접했던 것 같아요. 특히 마이너스통장에 대해 쉽게 풀어냈던 콘텐츠는 정말 기가 막혔어요. 슬라이드 카드뉴스를 끝까지 읽게 만드는 건 정말 어려운 일이거든요. 오대우 대표님은 콘텐츠에 질문을 더한다고 했잖아요. 어피티의 콘텐츠는 '쉬움'과 '실용성'에 포커싱한 것 같아요. 확실히 실질적인 고민과 니즈에 연결되면 실생활속에 녹아들어버리게 되잖아요. 이런 콘텐츠는 쉽게 머릿속에서 떨어지기 힘들죠! 기억에도 오래남구요. 다음에 다시 어피티의 콘텐츠가 올라오면 다시 누를 수 밖에 없기도 하구요. 저도 크게 배운 지점이예요. 난 어떻게 더 쉽고...실용적인 정보를 제공해야하는 걸까... 하아....쉽고 실용적이야!!!!#4뉴닉(Newneek)의 김소연 대표님밀레니얼을 위한 시사 콘텐츠김소연 대표님 말씀 : "요즘 젊은 애들 뉴스를 안봐" 라는 얘기에서 시작했어요.다양한 기사의 분석을 통해 간결하고 직관적인 문장으로 뉴스레터를 제작하고 있죠. 향후 계획은안전한 공론장 만들기 : 모더레이터가 있는 온오프 공론장여론 레포트 발송 : 젊은 세대의 여론을 솔직히 보여주는 페이퍼프리미엄 앱제작 이예요!알고리즘이 못이기는 사람이 분명히 있다고 생각해요. 재미,정의,합리,가치를 품은 '사람이 만드는' 뉴스레터를 만들어가고 있어요.내 변명 : - 겁나 좋은 말씀을 많이 해주셨는데 중간에 와이파이 끊겨가지고 저장이 안되버렸...므아아으ㅏ으ㅏ므ㅏ으ㅏ므ㅏ으ㅏ므아ㅡ아ㅡㅇ아아아아아아....죄송합니ㅏ아ㅡ으아으아아아...세션A#SPEECH인스파이어 : 안경찬한편의 브랜디드콘텐츠가 나오기까지.인스파이어는 아시아나와의 프로젝트에서 이색스포츠마케터. 라는 없던 직업을 만들었어요. 종이비행기 선수들이 아시아나의 가치(신항로개척)를 투영해서 풀어내기에 매우 적합했거든요. 이를테면 정밀함이나 철저함등의 교집합 말예요. 결국 브랜드가 지니고 있는 가치를 '인물' 이나 '아이템'에 투영해서 녹여내는 것이 중요하다고 하셨죵. 맞아요.브랜드는 겁나 크고 가치적이라서 그것을 대변할 수 있는 쪼꼬미가 반드시 필요해요. 눈에 보이지 않으면 머릿속에 남지 않기 마련이니까요. 뭔가 구체적인 오브제로 짠! 보여줘야 해요.의사결정에 관련한 얘기도 해주셨어요.브랜드콘텐츠의 의사결정과정에선 꽤나 보수적인 기획이 나오는 경우가 많다고 해요. 아무래도 브랜드이미지를 위해 조금의 리스키한 요소도 용납하고 싶지 않기 때문이겠죠. 그래서 사전에 무엇을 하면 안되는지를 먼저 규정하신다고 해요. 그게 되지 않으면 나중에 엎어지거나 일이 복잡해질 수 있으니까요. (겁나 핵공감과 눈물..)#패널토의안경찬, 채반석(14F), 도혜림(스페이스오디티), 이아리따(스브스뉴스PD).Q. 각 팀에서 어떤식으로 브랜디드콘텐츠를 만들고 있고, 커뮤니케이션과 제작과정은 어떤지.도혜림 : 다양한 방식으로 프로젝트를 진행하고 있는데 주로 선제안방식, 광고주가 선요청, 사내 비밀게시판에 올라온 광고의뢰에 대한 입찰 방식을 통해 진행하기도 해요.아리따 : 브랜디드와 디브랜디드를 같은 선상에서 제작하고 있어요. 광고가 아닌 협찬의 개념으로 콘텐츠제작를 제작하고 있어요. 그래서 캠페인이란 용어를 쓰고 있어요.안경찬 : 브랜드를 표현할 수 있는 페르소나를 설정하여 다큐형식으로 가치를 전달하고 있어요. 제안건에 대한 내부회의를 거쳐서 진행하죠. 직접적인 홍보는 피하고 있는 편이예요.Q. 콘텐츠제작에 있어서 커뮤니케이션 방식은 어떠한지?아리따 : 사전심의, 내부직원들 심의, 중간의 제작계획서, 협찬의뢰서 같은 절차적인 부분을 통해 내용조율을 하고 있어요. 스브스뉴스의 제1기준은 독자예요. 광고주나 상사, 협찬사가 아니죠.Q. 구독자들의 반응은 어떻게 매니징하시는지?도혜림 : 브랜디드와 오리지널 콘텐츠를 구분하는 것은 좀 무의미해진 것 같아요. 독자들의 반응은 그 둘을 구분하여 발생하지 않는 달까요. 광고에 대한 거부감이 줄어든 것 같아요. 이것은 광고에 대한 익숙해짐 또는 염증이 아니라 콘텐츠자체의 재미와 가치를 이해하기 시작했다고 생각해요.안경찬 : 광고를 광고가 아닌 것 처럼 숨기기 시작할 때 더욱 부작용이 많이 발생하는 것 같아요. 오히려 솔직하게 드러내되 퀄리티와 스토리에 신경을 쓰려고 합니다. 솔직하게 드러냈을 때 더욱 다양한 대화를 만들어낼 수 있는 것 같아요.아리따 : 1년 전만 해도 '이거 광고네?' 라는 반응이 있었어요. 현재는 그런 반응이 현저하게 줄어졌는데, 독자가 변한게 아니라 애시당초 그런 여지가 있는 콘텐츠는 제작하지 않기 시작했기 때문인 것 같아요. 채널의 색깔을 먼저 잘 만들어야 협찬사들의 브랜드도 그 색깔로 녹여낼 수 있다고 생각해요.세션B#SPEECH프리즘오브의 유진선취향과 안목 사이레알 힙한 영화매거진인 프리즘오브의 유진선님이예요. 취향에 대한 이야기를 해주셨죠. 취향이란 무엇이냐......하면 '하고싶은 마음이 생기는 방향' 이래요. 우워어어어어...제 취향은 꽤나 명확한 편이예요. 카레와 나루토와 와콤과 나무카페, 항정살 등등이랄까요. 실제로 돈을 쓰고 있는 분야죠. (헛소리) 중요한 건 창작자와 소비자의 취향의 상호작용이예요. 뭔 말이냐면, 창작자가 소비자를 분석해서 '이거 만들어야짓!' 하고 제작하는 게 아니라창작자가 소비자의 취향이 '이미' 맞아 있어야 하는 거죠. 개공감해요!! 왜냐면 핵노잼과 나와 코드가 맞지않는 콘텐츠를 만들다보면 엄청나게 괴롭거든요. 예전에 스트릿패션관련된 텍스트를 만든 적이 있었는데... 진짜 역대급으로 힘들었던 것 같아요. 글자 하나 쓸 때마다 벽돌 한 짐 나르는 기분.그래서 취향으로 돈을 번다는 것은 소비자가 '창작자의 안목' 에 돈을 쓴다는 얘기죠. 창작자의 취향에 취향과 시각이 더해지면 '안목' 이 되는 거잖아요. 항정살은 분명 존맛이지만, 특별한 항정살을 구별하고 찾아낼 수 있는. 또는 항정살의 어떤 부분에 집중할 것인지를 결정하는 건 '안목' 이니까요.그걸 위해서는 단순히 정보전달...그러니까 구글에 몇 번 찾아보거나 나무위키보면 대략 우르르 알수있는 내용들을 열거하는 콘텐츠가 아닌 좀 더 '시선' 중심적인 콘텐츠를 만든다고 해요.취향을 안목으로 발전시키고, 소비자와의 접점을 찾고, 그 취향에 확신을 갖는거죠.취향의 확신. 이건 정말 중요해요. 단순히 두루뭉술하게 난 그냥 이걸 좋아해~ 으헤헤... 에서 끝나는 게 아니라. 그게 왜 좋은지, 다른 사람들은 어떻게 생각하는지 등등을 입체적으로 분석해야 등장할 수 있는 것이거든요. 그런 깊이 있는 분석과 고찰이 '느낌'을 '능력'으로 바꿀 수 있는 것 같아요.#패널토의이가희(책읽찌라), 정우성(더파크), 유진선(프리즘오브), 오대우(널위한문화예술)Q. 아이템 선정의 기준은 어떠한지?정우성 : 빨리가고 싶은면 혼자가고, 멀리가고 싶으면 함께 가라고 하잖아요.저희는 빨리가는 팀이예요(와하하하) 두 명이서 움직이다보니 빠르게 움직이고 빠르게 실행합니다. 둘이 고민해서 이거다 하면 바로 진행하는 편이예요.유진선 : 콘텐츠의 밸런스를 고려하는 편이예요. 외국과 한국영화, 큰영화와 독립영화 등 다양하고 균형있는 콘텐츠 제작을 위해 노력해요.오대우 : (위에서 말했지만) 질문이 될만한 아이템을 찾아요. 내부적으로 던져봤을 때 그 문장의 매력과 질문, 대화의 끊이지 않는 진행을 관찰하는 편이예요.Q. '불한당' 을 소재로 펀딩을 진행했던 이유는? (to.유진선)유진선 : 원랜 선정이 어려운 영화였어요. 개봉일과 너무 가깝기도 했고, 연속해서 한국영화를 소개했기 때문이예요. 그런데 내부 수익모델 쇄신 목적으로 2~3개월 휴간을 앞두고 내부적으로 '하고싶은' 콘텐츠를 하나 만들자! 라는 얘기가 나왔었어요. 그 무렵 불한당에 대한 소개요청이 엄청나게 들어오기 시작했어요. 휴간의 목적이 수익구조 개선이었기에, 수익모델이 될 수 있도록 크라우드 펀딩으로 진행하게 되었죠.Q. Target Audience 가 있는지?오대우 : 20-29세의 문화예술 매니아라는 타겟을 잡고 있어요. 장르는 굉장히 근대적인 구분인 것 같아요. 그저 문화예술이라는 커다란 담론안에서 움직이려고 해요. 하지만 의도했던 뿐 아니소비자뿐 아니라 다른 사람들에게도 그 파급효과가 퍼져가는 것 같아요.유진선 : 타겟을 만들고 콘텐츠를 제작하진 않았어요. 오히려 만들고 나서 타겟이 형성된 경우가 있었죠. 대부분은 영화전체보단 '그 영화' 를 좋아하는 분들이 먼저 접근하게 되었어요.정우성 : 타겟오디언스...라는 말은 큰 의미가 없는 것 같아요. 타겟보단 콘텐츠가 스스로 날아가 꽂히는 곳이 곧 타겟이 되는 것 같아요. 콘텐츠가 스스로 움직일 수 있게 노력하고 있어요.Q. 담론을 만들어가는 노력은 어떻게 하고 있는지?유진선 : 처음 발간할 땐 500부만 찍자! 라는 생각으로 시작되었어요. 처음엔 이게 담론이 될 줄 몰랐죠. 하지만 이건 언론이었어요. 잡지가 만들어지고 퍼져나가고 나자 나름의 담론이 형성되기 시작되더라구요. 그런데 영화에 대한 팬진(팬메이드의 매거진)과의 차별성을 만들어야 겠단 생각이 들었고 개편하면서 영화 내적인 부분뿐 아니라 영화 외적인 부분...그러니까 사회적, 영화사적, 인문학적인 영역과의 접점을 만들어내기 시작했어요. 이게 사회와의 접점을 만들어내면서 프리즘오브만의 담론으로 만들어져가는 것 같아요.Q. 독자와의 관계는 어떻게 유지하시는지?정우성 : 못만들고 있어요 ㅠㅠ...흐어어...(청중 : 와하하) 둘 밖에 없다보니까 뭔가 다채롭게 하긴 힘들더라구요. 내년엔 오프라인으로 이어질 수 있는 기회를 만들어보고 싶어요. SNS상에서의 반응과 독자님들은 모두 다 기억하고 있어요~!유진선 : 독자층은 어느정도 형성이 된 것 같아요. 하지만 데이터로 명확하게 가시화되긴 좀 힘들다고 생각해요. 다만 저희가 20대때 만들었던 매거진은 20대가 독자층이었는데, 지금은 저희의 연령대와 맞는 독자층으로 바뀌어가고 있어요. 새로운 소비층을 발견해가고 있죠.Q. 작게 사업을 하는 입장에서 규모가 커지거나 사람이 많아지게 되면 지금의 기조를 유지할 수 있을까요?유진선 : 규모가 작다면 확실히 한계가 있는 것 같아요. 돈을 벌고 싶었다면 확실히 수익이 될만한 콘텐츠를 기획해야 했다고 생각해요. 하지만, 브랜드의 크기와 수익의 크기는 다르다고 생각해요. 브랜드가 끼칠 수 있는 파급력을 키워가는 것은 규모와는 상관없는 일이거든요. 때문에 브랜드와 수익 중 어떤 쪽의 기조를 가져갈지는 창작자의 선택이라고 생각해요.정우성 : 대중을 정의한다는 것은 어렵다고 느껴져요. 사람은 너무 복잡하고 그 사람이 그 사람이기도 한 거예요. 취향과 기호는 복합적이고 뒤섞일 수 밖에 없잖아요. 마니어와 메이저를 구분하지 않고 콘텐츠를 제작하고 있어요.까지 듣고 나오게 되었어요. 나머지 3,4부를 보지 못해서 슬픔이 이루 말할 수 없지만 앞선 인사이트만으로도 이미 가슴이 벅차서 3,4부까지 들었으면 볼빨갛게 상기된 변태같아 보였을 지도 몰라요. 명동 한복판에 허억허억 거리며 걸어가지 않아서 다행이라고 생각해요.콘텐츠를 제작하시는 분들의 에너지는 함께 있는 것만으로도 무선충전이 되는 듯 해요. 요즘 책상앞에서 좀 찌들어있긴 하지만 저도 내년에 이런저런 것들을 생각하고 있는터라 오늘 들은 내용들이 여러가지 계획에 영향을 미칠 것 같더라구요. 스압이 엄청난데 설마 여기까지 이 글을 보셨다면 굉장히 제 글이 재미있었나봐요. 감사합니다. 오늘의 두근두근 루프페스티발 리뷰는 여기서 마치겠숩니당. 앙뇽.
조회수 1884

일 잘하는 방법 하나 - 탁월한 질문하기

일을 잘 하기 위해서는 탁월한 질문을 할 줄 알아야 한다. 제때에 하는 탁월한 질문은 좋은 답변을 얻는 것을 넘어 내가 한 단계 도약할 기회로 돌아오기도 한다. 독서모임을 할 때도 좋은 질문, 즉 좋은 발제가 나올 때 대화가 한껏 풍성해진다. 독서모임의 만족도는 그 날의 발제문이 정한다. 그와 반대로 바보 같은 질문은 알맹이 없는 대답을 듣게 되는 것은 물론, 상대방에게 하여금 내 이미지를 깎아 먹게 만든다.  새삼스레 질문의 중요성을 체감하게 된 이유가 있다. 요즘 들어 처음이라 부를 일들을 잔뜩 부딪치고 있는 덕에 다른 사람에게 질문하는 상황이 많아졌기 때문이다. 그런데 번번이 질문에 대한 질문이 다시 날라온다거나, 대답을 들어도 문제 해결에 진척이 생기지 않는 경우들이 생겼다. 빠르게 해결하기는커녕 오히려 한 문제에 머무는 시간이 늘어났다. 무언가 잘못하고 있다는 생각이 들었다. 내가 질문을 던지는 과정은 이랬다. 1. 문제가 발생한다. 2. 문제 상황에 대해 검색해보며 이것저것 시도한다. 3. 여러 시도가 실패하면 문제의 해결 방법(How)을 물어본다. 이 과정에서 잘못된 것은 무엇인가? 많은 문제가 포함되어 있겠지만 가장 큰 문제는 질문하기 전에 혼자서 고민해보는 시간이 부족했다는 점이다. 충분한 고민 없이 던지는 질문은 답변을 듣고 문제를 해결할지라도 남는 게 없다. 나중에 비슷한 문제를 맞닥뜨려도 또다시 질문을 해야 하는 상황이 만들어진다.  원래의 나는 문제 해결을 위해 질문을 해본 경험이 별로 없었다. 예전에는 남에게 질문하는 것이 실례라고 생각해서 잘 하지 않았다면, 언젠가부터는 질문을 하기 위해 고민을 정리하는 일이 귀찮아서 하지 않았다. 문제는 여기서부터 시작되었다. 질문 하기 위해 고민을 정리해야 하는 상황이 만들어진다는 건 애초에 문제에 대한 정리가 되어있지 않았다는 것을 의미했다. 정확히 무엇이 문제인지, 예상되는 원인은 무엇인지 등 스스로 문제에 대해 정리가 되지 않으니 질문을 하려면 따로 정리가 필요했다. 결국 좋은 질문을 하려면 혼자 고민하고 정리해보는 시간이 많아야 하고, 정리된 내용 중 상대방이 더 잘 알 것 같은 부분만 추려내어 질문해야 한다. 그러다 보면 자연스레 일을 잘할 수밖에 없게 된다. 잘 돌이켜보면 트레바리에서 일하는 동안 질문 받는 상대방에게 하여금 질문이 썩 좋지 못하니 다르게 물어보라고 유도하는 피드백을 종종 받았다. 인제야 그 필요성을 통감하여 고쳐야겠다고 알아먹었고 주변에 질문을 잘하는 사람들을 유심히 관찰하며 살펴보았다.  1. 대체로 what이나 how보다는 why를 묻는다.why를 물을 때에도 문제의 원인을 묻기 이전에 내가 시도해본 것 중 이해가 되지 않는 포인트를 날카롭게 물어본다. 어쩌다 때려 맞춰 문제를 해결하더라도 왜 해결되었는지를 묻는다. why를 묻는 사람들은 질문하기 전에 이미 이것저것 시도해봤음은 물론이고 다음에 또 비슷한 문제에 시달리지 않고 싶어 한다. 2. 무엇을 알아야 하는지 묻는다.자신이 어느 부분에서 부족하여 이런 문제를 겪고 있는지 궁금해한다. 단순히 문제 해결을 하는 데에서 그치지 않고 이참에 약점을 메꾸려 한다. 문제를 많이 겪은 만큼 성장 하고 싶어 한다. 여태까지 발견한 방법은 이렇게 두 가지다. 앞으로 한참은 더 질문하는 법을 배워야겠지만 당장은 질문을 하기 전에 고민을 많이 하는 것부터 해보자. 그리고서 위의 방법들을 지켜서 질문해보자. 질문하는 일은 참 어렵지만 잘만 한다면 이미 비슷한 고민을 해봤던 다른 사람의 지식을 빠르게 얻을 수 있다. 대표님의 표현을 빌리자면 남의 뇌를 빌려 쓰는 것이다. 남의 뇌를 빌려 쓰면 시행착오로 보내는 시간을 줄일 수 있게 된다. 시행착오에 쓸 시간을 아끼면 내가 잘할 수 있는 일을 많이 할 수 있다. PS.마침 평소 애독하던 김형석 님이 직장 필살기: 질문의 기술이라는 글을 쓰셨다. 나처럼 질문을 잘해서 일을 잘해보고 싶은 직장인들이 읽어보면 도움이 될 글이다. 같이 읽어보면 좋다. 게다가 이렇게 유익한 글을 써주신 김형석 님은 2018년 5월부터 트레바리 클럽장으로 활동하실 예정이다!! (기승전 트레바리 자랑) #트레바리 #개발자 #CTO #스타트업일상 #Why #How #What #인사이트 #경험공유
조회수 7346

Kafka 모니터링

Kafka 도입 이후에 점진적으로 모니터링을 개선해나간다. Kafka와 그 제반 환경에 대해 이해한만큼 모니터링을 구성하고 모니터링 시스템에서 피드백을 받아 다시 학습하고 그렇게 배운 것을 토대로 다시 모니터링을 구성한다. 그 과정을 따라 나가며 Kafka 를 어떻게 모니터링하면 좋을지 알아보자.프로세스 모니터링아무래도 가장 기초적이면서 중요한 지표는 Kafka 프로세스가 잘 살아 있는지 확인하는 것이다. 다섯 대로 구성한 클러스터라면 상시 Kafka 프로세스가 확인되어야 한다. 만약 Kubernetes의 StatefulSet으로 Kafka 클러스터를 구성한 경우라면 Kafka 프로세스 다섯과 프로세스 모두를 엮는 서비스, 그러니까 로드밸런서 하나를 포함해 총 여섯 개의 프로세스를 확인해야 한다. DataDog(통칭 멍멍이)을 이용해 모니터링하는 경우라면 다음과 같이 설정하면 된다.Monitoring Kafka ClusterKafka는 Zookeeper를 이용하므로 ZooKeeper 역시 동일하게 모니터링하면 된다.DataDog을 이용한 메트릭 모니터링`dd-agent는 Kafka 관련 메트릭을 Broker, Consumer, Producer 세 측면에서 수집한다.Monitoring Kafka with DatadogMonitoring Kafka performance metrics위의 두 문서가 Kafka 모니터링의 상세한 측면을 기술하는데 멍멍이를 이용하지 않더라도 꼭 한번 읽어볼만하다. 두 문서가 매우 훌륭하므로 이 글에서는 Kubernetes 환경에 초점을 맞춰 주목할 점만 살펴본다.Kubernetes 환경에서 멍멍이 에이전트는 보통 PetSet으로 구성한다. 말인즉 Kubernetes Worker 한 대마다 에이전트를 한 대씩 띄워서 Worker 안에서 작동하는 모든 도커 인스턴스의 메트릭을 수집한다. 일단 에이전트를 설정하고 나면 아래와 같이 Kafka 모니터링이 정상 작동하는지 확인하면 된다.kube exec -it dd-agent-17vjg -- /opt/datadog-agent/agent/agent.py info kafka ----- - instance #kafka-kafka-0.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-1.broker-9999 [OK] collected 46 metrics - instance #kafka-kafka-2.broker-9999 [OK] collected 46 metrics - Collected 138 metrics, 0 events & 0 service checks Emitters ======== - http_emitter [OK]Broker의 경우는 설정하기가 비교적 쉽다. Kubernetes에서 Kafka 같은 Stateful cluster는 StatefulSet으로 구성하게 되는데 이때 호스트 주소가 kafka-0, kafka-1 같이 예측 가능한 이름으로 정해지기 때문에 kafka.yaml을 미리 작성해두기 쉽다.instances: - host: kafka-0.broker port: 9999 # This is the JMX port on which Kafka exposes its metrics (usually 9999) - host: kafka-1.broker port: 9999Producer와 Consumer 모니터링은 이와는 다르다. 구현하기 나름이지만 Producer 또는 Consumer가 되는 응용프로그램은 Stateless cluster일 때가 많고 그런 경우에는 Kubernetes에서 Deployment로 클러스터를 구성한다. 이때는 StatefulSet인 경우와 달리 호스트 주소가 worker-903266370-q3rcx와 같이 예측하기 힘들게 나오므로 에이전트에 미리 설정을 넣을 수가 없다. 상당히 까다로운 문제이다.Consumer 모니터링Kafka의 설계는 매우 단순하면서도 강력해서 감탄하곤 한다. 하지만 복잡한 문제를 단순하게 풀어냈다고 해서 이를 둘러싼 환경을 제대로 모니터링하는 것도 쉽다는 뜻은 아니다. 특히 Consumer groups이 제대로 제 몫을 하고 있는지 파악하기는 더 어렵다. Consumer group마다 모니터링 체계를 갖추자니 번거롭다. 게다가 그런 번거로움을 극복하더라도 Kafka에 문제가 있는 경우를 탐지하기는 여전히 어렵다. 예를 들어 Consumer에게 가야 할 메시지 중 5%가 실제로는 전달되지 않는다 하면 이를 Consumer가 알기는 어려울 것이다. 이 외에도 Consumer 측 모니터링이 엄청나게 까다로운 문제임은 Burrow: Kafka Consumer Monitoring Reinvented에서 잘 밝혔다.Burrow: Kafka Consumer Monitoring Reinvented에 등장하는 Burrow는 Kafka를 세상에 내놓은 LinkedIn 엔지니어링 팀이 개발한 Kafka 컨슈머 모니터링 도구이다. 커뮤니티에서는 대체로 현존하는 가장 뛰어난 모니터링 도구라고 인정하는 분위기이다. 그러니 다른 도구도 많지만 우선 Burrow로 모니터링을 강화하기로 한다.Burrow로 Consumer 모니터링하기Burrow는 Dockerize가 잘 되어 있기 때문에 사용하기 어렵지 않다. LinkedIn이 공식 도커 이미지까지 제공했더라면 더 좋겠으나 GitHub에 Dockerfile과 docker-compose.yml을 올려놓아서 도커를 잘 아는 사람이라면 큰 어려움 없이 바로 설정하고 설치할 수 있다. 컨테이너 환경의 관례대로 주요 설정을 환경변수로 미리 빼놨으면 더 좋았겠지만 …알람 받기Burrow는 문제가 생겼을 때 알람을 발송하는 기능이 있다. 위키에는 이메일 알람과 HTTP 알람(Webhook)을 어떻게 설정하는지 설명한다. 그런데 Burrow 소스코드를 살펴보면 문서화되지 않은 알람 기능도 있으니… 바로! Slack 알람을 제공한다. 아직 공식 문서가 없고 소스코드도 godoc 관례에 맞춰 설명해놓은 부분이 전혀 없기 때문에 소스코드를 읽거나 GitHub 이슈에서 논의된 내용을 토대로 설정해야 한다.[slacknotifier] enable=true url=https://hooks.slack.com/services/xxxx/xxxxxxxxxx group=local,critical-consumer-group group=local,other-consumer-group threshold=0 channel="#general" username=burrower interval=5 timeout=5 keepalive=30멍멍이로 메트릭을 꾸준히 수집하고 이슈가 생겼을 때 알람을 받고자 한다면 packetloop/datadog-agent-burrow를 이용하면 된다.This plugin will push the offsets for all topics (except the offsets_topic) and consumers for every kafka cluster it finds into Datadog as a metric.멍멍이 에이전트에 필요한 파일과 설정을 넣고 나면 아래와 같이 메트릭이 수집된다.kafka.topic.offsets 와 kafka.consumer.offsets 이렇게 두 개의 메트릭만 수집하지만 각 메트릭을 cluster, topic, consumer 세 개의 토픽으로 세분화하기 때문에 실제로는 꽤 다양한 지표를 멍멍이에서 확인하고 이용할 수 있다.알`람 설정하기앞서 살펴봤지만 프로세스 모니터링 등은 어렵지 않다. 클러스터에서 한대라도 빠지면 바로 알람을 받는다. 끝!하지만 그 외의 지표는 알람의 기준을 설정하기가 힘들다. 예를 들어 Burrow의 kafka.topic.offsets 값이 600이면 정상인가? 그렇다면 700은? 또는 400은? 도무지 감을 잡을 수가 없다. 이럴 때는 멍멍이가 제공하는 Outlier detection기능으로 알람을 걸면 쉽다. 이 기능은 쉽게 말해 평소와 다른 행동을 감지했을 때 알람을 보낸다. 그러므로 정상의 범위를 확실하게 모를 때 아주 유용하다.설정 자체는 DBSCAN 또는 MAD라는 알고리즘이 등장하는 것만 빼곤 여타의 모니터링과 다르지 않기 때문에 매우 쉽다.참고 문헌How to Monitor KafkaCollecting Kafka performance metricsOriginally published at Andromeda Rabbit.#데일리 #데일리호텔 #개발 #개발자 #개발팀 #인사이트 #기술스택 #스택소개 #Kafka
조회수 813

에이스프로젝트의 역할

그래서 에이스프로젝트에는 어떤 역할이 있나? 팀 야구 구단에는 단장과 감독이 있다. 단장과 감독은 둘 다 구단의 성공을 목표로 하지만 서로 다른 역할을 수행한다. 단장은 외부 커뮤니케이션에 대해 권한이 더 크고 감독은 선수의 육성을 책임진다. 감독과 단장이 리더의 각 역할을 나누어 수행하는 것처럼 에이스프로젝트도 기존 팀장의 역할을 팀 디렉터와 팀 매니저의 역할로 세분화해 수행하고 있다. 팀 디렉터는 팀원의 업무 역량을 이끌어 아웃풋을 퀄리티업 한다. 팀 매니저는 팀 문화를 주도하며 내적 동기부여를 유도해 팀원이 일하기 좋은 환경을 조성한다. 1. 팀 디렉터팀 디렉터는 팀원의 역량 개발과 성장을 책임진다.팀원 개개인의 전문성을 향상시키고 팀의 전문화에 관련된 의사결정을 한다.팀원이 더 나은 방향으로 성장하기 위해 필요한 인사 배치, 평가, 교육에 관여한다. * 구성원에게 적합한 업무와 역할을 배정한다* 직접 교육하거나 사외 교육을 지원한다* 팀원의 성장을 위한 평가와 피드백을 제공한다* 면접을 보고 팀원 채용 여부를 결정한다* 앞으로의 업무 발전 방향을 제시한다* 현재 진행되고 있는 작업물의 퀄리티 향상을 위해 도움을 준다  2. 팀 매니저협상 기술에는 소프트 스킬과 하드 스킬이 있다. 하드 스킬이 '지식'을 강조한다면 소프트 스킬은 정성적인 면에 더 초점이 맞춰져 있다. 팀 매니저는 구성원 간의 커뮤니케이션, 팀워크, 리더십 등을 활성화할 수 있는 소프트 스킬을 주로 활용하는 역할을 한다. 팀원들의 회사생활과 동기부여, 팀 문화를 책임진다.  * 주기적인 면담을 통해 팀원 개개인과 소통한다* 조직문화에 대해 팀원과 소통한다* 팀의 행정 업무를 수행한다* 팀 내 행사(회식, 워크샵, 스터디 등)을 운영한다   프로젝트 기능별로 구성된 팀과는 별개의 형태로 프로젝트 조직이 있다.프로젝트 내에서는 기획, 그래픽, 클라이언트, 서버 파트가 유기적으로 협업한다.프로젝트 조직은 전문화를 목표로 하는 팀과는 달리 성과/목표지향적인 조직으로 결정권이 PD에게 집중되어 있다.스크럼 마스터는 스케쥴 관리자, 각 파트 디렉터는 투수 코치, 타자 코치와 비슷하다고 볼 수 있다.     1. PDPD는 프로젝트 전체를 계획, 총괄, 감독하는 역할이다.PD는 프로젝트의 효율적인 성공을 위한 의사결정을 해야 한다.  * 프로젝트 총괄 의사결정권이 있다* 프로젝트 인원을 편성한다* 프로젝트 내 각 파트 분쟁을 중재한다* 비용 집행과 관련된 의사결정을 한다* 개발과 릴리즈 일정을 결정한다  2. 스크럼마스터스크럼마스터는 스크럼 프로세스를 관장하고 구성원의 스케쥴을 관리한다. 줄여서 '스마'라고 부른다. * 무리한 일정을 거부할 수 있다* 스크럼 회의를 주재한다* 구성원의 업무 진행상황을 파악한다  3. 파트 디렉터프로젝트 내 각 파트에서 만들어진 아웃풋에 대한 의사결정을 내리는 사람을 파트디렉터라고 한다.기획 파트 디렉터, 그래픽 파트 디렉터, 클라이언트 파트 디렉터, 서버 파트 디렉터가 있다.  * 맡은 파트의 아웃풋 퀄리티를 향상시킨다* 파트 구성원에게 업무를 배분한다'숟가락 얹기'를 금지한다최근 많은 회사들이 커뮤니케이션은 자유롭되 업무역량은 전문가적인 조직을 만들기 위해 고민하고 있다. 대기업이 창의적인 문화를 도입하기 위해 복장규정을 완화하거나 스타트업이 체계적으로 일하기 위해 여러 가지 규칙을 만드는 것도 보다 좋은 문화를 가진 회사, 일을 잘 해내는 회사를 만들기 위한 시도라고 볼 수 있다. 에이스프로젝트도 일하기 좋은 회사, 역량 있는 인재들이 함께하고 싶을 만한 회사를 만들어나가기 위해 여러 사람들이 모여 다방면으로 고민했다. 다양한 가치관을 가진 구성원들이 맡은 업무를 하는 와중에도 지금 우리에게 맞는 최선의 문화가 무엇인가에 대해 생각했다. 무수한 토론과 열띤 설득의 과정을 거쳐 나온 것이 지금의 역할 중심 문화다.요약하자면 역할 중심 문화는 역할은 있지만 직급은 없고, 직책은 있지만 위계는 없는 문화다. 기존의 팀장이 혼자서 결정하던 것들을 각 역할을 가진 사람들이 모여  함께 논의한다. 위계를 없애 의사결정 전에는 커뮤니케이션을 활발하게 하면서도 최종적으로 결정하고 책임지는 사람을 지정해  더 일하기 좋은 환경을 만든 데에 의의가 있다. 문화는 제도나 규범과 달리 반드시 지켜져야 하는 정해진 무엇이 아니기 때문에 계속해서 변화한다. 현재의 역할 중심 문화가 에이스프로젝트의 ‘정답’이라고 할 수는 없다. 실제로 역할 중심 문화를 운영하면서 예상하지 못한 문제가 드러나 이를 개선하기 위해 새롭게 고민하기도 했고 누군가 더 나은 방법을 제시해 그것을 도입해보기도 했다. 에이스프로젝트는 모두가 참여해 어제보다 오늘이 더 나은 회사를 만들어가고 있다. 
조회수 993

Team Profile: Meet Yonghyun

Read In KoreanAs a yet minuscule startup, each member holds a significant power over the overall atmosphere of the team. And in our ultimate quest to make big waves in the data world, we need to make sure that the people at the helm are at least kind of cool. We think we’ve done a pretty good job so far in assembling a society of unique but equally driven members.So we bring you this seven-part series, one of each devoted to interviewing each of our members in detail, to give you an in-depth glimpse into the people responsible for bringing you the future of machine learning with Daria. Plus, we peppered the interviews with questions from Dr. Aron’s “The 36 Questions that Lead to Love”*, cherry picked to make work appropriate and concise, but interesting.(*actually falling in love with our members highly discouraged)Yonghyun joined the XBrain team in August as a software engineer, and has worked closely with other members in constructing the software that Daria runs on. But his interests run beyond just making sure that Daria become the future star of machine learning and data science — Yonghyun is also an avid soccer player, and an enthusiastic dabbler of virtual and artificial reality. Learn more about him here!Yonghyun saves a few minutes of his day for some introspection/staring broodily out the windowHi Yonghyun! Start by telling us about your role.YH: I work with JM as a software engineer at XBrain, developing and testing our software infrastructure.How do you usually spend a work day?YH: I usually come to work around lunchtime, and devote my time to whatever needs to be done for the day. Today we worked on tests involving transferring data from MS SQL. I enjoy afternoon walks sometimes, and usually head home after working a little post-dinner.Tell us about the parts of your job that you most enjoy.YH: I enjoy transforming machine learning modules into Spark to fit with the cloud system, and looking at the code Suzin’s written in order to understand the process.What about the aspects that you least enjoy or find challenging?YH: Setting up the environment to test our systems is something I least enjoy. It’s frustrating, because you can follow all the steps and still go the wrong way.Pick one item on your desk that tells us something about you.YH: I don’t have a whole lot on my desk…so I would probably have to say my laptop. The very very big laptop provided to me by the company.Laptop in photo is larger than it appearsWhat made you want to become a software engineer?YH: I was originally majoring in History in college, but I was struck by how computer science could help you create something tangible. Programming helps turn your ideas into reality on the screen, which is something I was really drawn to.So why XBrain?YH: As an incoming programmer, you don’t really come across the opportunity to participate in the making of a product that’s still under development. It’s a good learning experience for me to watch Daria’s progress. Furthermore, because I started programming at a relatively later stage, I still need help with my mathematical background, which working here allows me to do.As the one of the newest additions to the team, tell us about your vision for XBrain.YH: I think my vision is one of becoming a household name for a machine learning tool that a lot of people use on the daily — Daria doing useful things in every facet of the world, big or small.What is your go-to work playlist?YH: When I’m coding, I usually prefer EDM, so stations like Hardwell On Air, and hip-hop as well.Recommend a movie for our next Cinema Society, please.YH: Watchmen (2009). Its protagonist Rorschach is an anti-hero, and the plot line is complex and interesting to follow.Where do you see yourself 10 years from now?YH: Career-wise, honestly I wouldn’t mind what I have right now — working a job that I love without getting too swamped with deadlines, with plenty of time for exercise and socializing, playing soccer with my friends.Given the choice of anyone in the world, whom would you want as a dinner guest?YH: Mark Zuckerberg, maybe? I’d like to hear about his ideas for the future.If you had to have dinner with one XBrain member, who would it be and why?YH: JP, our new machine learning engineer. I’d like to get to know him better, and he seems like an interesting person.Would you like to be famous? In what way?Nope.What would constitute a “perfect” day for you?YH: A day productive enough that I could go to bed without worrying about the next day.If you were able to live to the age of 90 and retain either the mind or body of a 30-year-old for the last 60 years of your life, which would you want?YH: The body of a 30 year old… I don’t think that youth isn’t everything when it comes to minds.For what in your life do you feel most grateful?YH: The privilege to have been able to learn and achieve everything I’ve wanted is something I’ll always be thankful for, and also the flexibility to be able to change directions I’m headed in.If you could wake up tomorrow having gained any one quality or ability, what would it be?YH: I’ve always wanted more drive to carry out the projects I’ve devised in my head, the ability to see things through no matter what.Is there something that you’ve dreamed of doing for a long time? Why haven’t you done it?YH: I’ve always wanted to learn how to cook. I lived in a dorm in college so I didn’t have the opportunity then, but now would be a good time as any.What is the greatest accomplishment of your life?YH: I would say my greatest accomplishment is putting my best efforts into learning and improving my mind, inside and outside of school.What is your most memorable XBrain moment?YH: My fondest memories are usually of events we held outside — the hike we went on in September, or the soccer game we had. I like that we got to bond as a team and get some exercise.If you knew that in one year you would die suddenly, would you change anything about the way you are now living? Why?YH: I haven’t been able to get decent sleep recently, so I’d probably give myself some time to rest.If you were going to become close friends with someone, please share what would be important for him or her to know.YH: I don’t have very strong likes or dislikes, so I usually get along with most people.What, if anything, should never be joked about?YH: You should never joke about the disadvantaged, or others’ insecurities.If you could sum up XBrain in three words or less?YH: Freedom. Consideration. Learning…. Is that too serious?#엑스브레인 #팀원소개 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑
조회수 1792

소프트웨어 개발자에게 성공이란...

소프트웨어 개발자들이 생각하는 ‘성공’이라는 단어와 키워드에는 어떤 것들의 의미를 포함하고 있을까? 한편으로는 단편적이고 획일적인 ‘성공’이라는 단어에 너무 많은 개발자들이 매몰되어 있는 것 아닌가 하는 생각을 해본다. 필자 스스로 실무경력 20년을 넘겨서 소프트웨어 개발을 하고 있는 경험을 바탕으로 주변의 성공한 개발자들에 대해서 혼자 생각해 보았다.일반적으로 의미의 ‘성공’이라는 것이 무엇을 의미하는 것인가에 대한 정의는 이번 칼럼의 말미에서 이야기하도록 하자. 정말 많은지 모를 대한민국에서 성공한 개발회사나 개발된 서비스들을 살펴보는 것부터 시작을 하는 것이 정답인지는 필자도 잘 모르겠다. 성공적인 서비스나 소프트웨어, 프로그램은 세상에 선보인다는 것. 그러한 것을 만들어낸 순수한 아이디어나 원천기술로 무장한 기술로 축적되었고, 그 아이디어를  뛰어넘어, 새로운 기술이라고 할 수 있는 것을 보유한 제품이나 상품들이 얼마나 되는지에 대해서부터 냉정하게 필자는 잘 모르겠다라고 먼저 인지하고 넘어가자. 아니, 다시 말하자면, 냉정하게 국내에서 그런 것을 본적이 별로 없는  듯하다.더욱더 삐딱하게 이야기하자면, 국내에서 성공한 개발 서비스들은 대부분 아류작이거나 남의 아이디어를 도용한 제품과 서비스들이 대부분이 아닌가라고 생각한다. 심지어는 특정 솔루션 시장은 오픈소스를 그대로 제품에 반영해 두고서는 자신의 제품인 것처럼 위장하는 사례까지 보이고 있으니, 과연 대한민국 소프트웨어 시장은 과연 얼마나 ‘성공’이라는 키워드를 그대로 사용해도 되는지에 대해서 매우 의문시된다.(물론, 필자의 삐딱한 시선에서만 그렇게 보일지도 모른다.)대한민국의 소프트웨어 시장에서 1위를 지키고 있다고 하는 서비스와 제품들이 되려면 어떻게 해야 하는가?. 삐딱하게 이야기하자면, 오로지, 대한민국에서 성공한 개발회사나 개발자가 되려면, 창의적인 아이디어나, 독특한 아이디어로 무장하는 승부수를 던지기 보다는, 해외의 서비스 중에 알차고, 괜찮은 것들에 대해서 관심을 가지는 것이 중요하다고 생각한다. ( 그래서, 영어공부를 잘해야 하는지도 모르겠다. )필자가, 대기업과 신규사업기획을 할 때에 작업하는 내용을 보고서는 경악을 금치 못했던 경험을 한적이 있다. 정말 상당한 컨설팅 금액( 수십억을 넘긴 비용 )을 지불해서, 대기업이 유명한 컨설팅업체를 통해서 신규사업에 대한 기획과 아이디어에 대한 컨설팅을 받는 것에 전문가의 한 사람의 참여했었다. 그런데, 그 중요한 작업의 모티브는 해외에서 이미 성공적으로 안착한 서비스에 대한 분석과, 한국에서의 서비스 시에 벌어질 일에 대해서 예측을 하는 일을 하고 있었다는 점이다. 새로운 아이디어가 아니라는 점이다.물론, 성공한 서비스를 도입해서, 로컬 화한다는 것 또한 매우 어려운 일이라고 생각하지만, 대부분의 새로운 기획이나 신규 서비스에 대한 작업들의 대부분을 이런 식으로 진행한다는 이야기를 들었을 때에 받은 충격은 정말 놀라운 경험이었다, 물론, 지나고 나서 생각해보니, 그렇게 놀랄만한 경험도 아니었는지 모르겠다. 대부분의 대기업들이 이런 식으로 한다는 이야기를 듣고 더 놀라기는 했지만. 물론, 이렇게 로컬화 한다는 것 자체도 대단한 도전이고 어려운 점이라는 것은 인정한다고 하지만, 이런 로컬화와 아류작에 대해서 비판적인 시야를 가진 필자의 생각은 그렇다.성공한 서비스들은 대부분 아류작들이다?냉정하게 국내에서 성공한 대부분의 서비스들은 아류작들이고, 복제본들이고, 독창적인 아이디어보다는 해외 서비스를 대부분 국내에 안착한 서비스라고 생각한다. 심지어 독창적인 mp3 플레이어마저도, 아이팟의 생태계가 한층 더 발전적인 시장을 창출했으니, 국내에서 만들어진 디지털적인 요소들 중에 독창적인 것이 얼마나 있는가?필자는 생각한다. 예술에 있어서 복제와 창작의 차이는 매우 크다는 것을. 물론, 소프트웨어 개발이 이런 예술에 비견될 정도의 가치를 부여해서 그런 것 만은 아니다. 소프트웨어 개발은 아이디어와 구현하고자 하는 추진력과 열정이 결합되어져서 만들어지는 최고의 가치 구현을 위한 세계이기 때문에 그렇게 생각할 뿐이다.필자가 좋아하는 만화 중에 ‘맛의 달인’이라는 만화에 나온 표현을 그대로 옮기자면 다음과 같은 장면이 나온다. 프랑스의 유명한 요리를 그대로 일본에서 구현하지만, 그 요리에 대한 평가는 ‘프랑스의 요리를 그대로 구현한 요리이다’. ‘매우 아름답지만 최저의 요리’라는 평가를 받는다. 그러한 최저의 요리라는 평가를 받은 이유는 ‘로컬화 한다는 것은 실정에 맞게 고치고, 연구 개발한 맛이라면 완벽하겠지만. 너무도 프랑스 요리와 똑같이 만든 것은 처절한 아류라는 점이다. 지금 먹은 요리에는 프랑스 요리사의 모습이 그대로 남아있다는 점. 원형이 프랑스의 것을 그대로 답습했다는 것.오리지널을 복사했다는 냉정한 평가는 정말 명확하다. 요즘 가장 국내에서 최근에 성공한 서비스를 이야기한다면, 카카오톡과 애니팡을 예로 들 수 있겠다. 다른 사람들은 어떻게 평가할지 모르지만, 정말 대단한 성공을 가진 것은 사실이다. 하지만, 둘 다 원형을 그대로 복사했을 뿐, 새로운 것은 아무것도 없다는 점이다. 아니, 오히려. 기존의 원형을 대한민국의 안 좋은 통신사의 서비스와 결합한 케이스라고 평가를 해야 정확하지 않을까 한다. 원형을 오히려 퇴보시킨 서비스라고 평가하고 싶다.카카오톡은 WatsApp을 그대로 복제했다. 대표적으로 등록되어진 전화번호로 연계하는 원형의 아이디어를 그대로 받아들였다. 하지만, 카카오톡의 새로운 신규 비즈니스 모델인 게임센터는 자체적인 생태계를 만들어서 통제하려 하는 기존의 통신사의 방식과 그다지 차이가 없다고 보인다. 뭐, 돈을 벌어야 하는 기업의 입장을 반대하는 것이 아니다. 단지, 필자의 삐딱한 시선으로는 진보를 위한 선택이 아니라, 퇴보를 위한 선택이었다는 점이 불편할 뿐이다.애니팡도 마찬가지이다. 기존의 게임방식을 그대로 복제했다. 그리고, ‘하트’라는 이름으로 무분별한 ‘스팸’을 활성화해서, 기존 통신사들이 SMS에서 얻어들이는 대량 SMS 발송을 통한 이익을, 그대로 실현한 점이다.물론, 카카오톡이나 애니팡의 ‘이익 실현 구조’는 매우 성공적으로 국내에 론칭한 것은 사실이고, 이러한 구조로 ‘돈’을 벌어야 한다는 점이 매우 안타까울 뿐이다. 개인적으로는 ‘국내’에서는 어느 정도 ‘돈을 버는 성공은’할 수 있지만, 해외에서까지 성공적으로 론칭할 것인지는 조금 의심스럽다. ( 어차피, ‘돈’을 벌면 성공이라는 관점으로는 매우 대성공이다. )넥슨의 카트라이더와 마리오 카드와 같이 일일이 나열하기에는 너무도 많은 사례들이 있어서 굳이 더 나열하지 않겠다.다만. 정말 중요한 것은 복사보다는 진짜가 더 좋다는 점이다. 가령, 오리지널이 존재하는 영역이나 예술과 같은 고부가가치의 영역에서는 ‘화가나 작가가 다른 사람의 작품을 흉내내면  웃음거리밖에 되지 않는다’는 점을 이야기하고 싶다. 필자 개인적으로는 ‘그런 웃음거리를 통한 수익실현’을 그렇게 높게 평가하고 싶지 않기 때문이다.대표적으로 통신사는 ‘스팸’과 ‘보이스 피싱’을 해결하지 못하는가? 에 대해서 필자는 그렇게 생각한다. ‘대량 SMS수입’을 포기하지 못하고, ‘전화번호를 통한 대량 통화의 수익’을 포기하지 못하는 구조적인 문제 때문에 그렇다고 생각한다.과거에 문제가 된 iOS6로 업데이트가 되면서 SKT 아이폰4S에서 발생한 전화번호 호출의 문제, ‘112 신고가 안 되는 아이폰’이라는 기사와 사건에 대한 문제의 근본적인 원인은 SKT가 국제표준 방식을 따르지 않아서 발생한 문제라는 것을 모르는 사람들이 정말 많다. 이 문제를 더 파고들어가면, 부당한 SMS수입을 얻고 있는 국내 통신사들의 부도덕한 점도 드러난다. 2003년 이후 3G 서비스(WCDMA)가 도입되었지만, 문자 메시지 국제표준이 기존의 80 byte에서 140 byte로 늘어났지만, 정작 통신사들은 국제표준규격을 지키지 않으면서 연간 수백억의 이익을 부당하게 얻어냈다. 다만. 아이폰4s 출시 당시 KT는 140바이트를 맞추었지만, SKT는 아직도 80 byte였다는 점을 예로 들고 싶다.국제표준을 따르거나, 해외의 서비스가 ‘돈’이 되는 것에는 빠르지만, ‘돈’이 안 되는 기준에는 미온적이고, 대처가 느린 것에 대해서는 참으로 훌룡(?)한 성공적인 방법이라고 평가를 굳이 필자와 같은 주변 사람이 할 필요가 있을까 한다. 그런 훌륭한 평가는 비싼 컨설팅 비용을 지불한 뛰어난 전문가들이 할 것이기 때문에...내 주변에 성공한 개발자와 성공한 벤처 사업가...성공한 개발자. 고급 승용차를 몰고, 출근하는 개발자의 모습을 본다면, 성공한 개발자의 향기를 느낄 수 있을까? 물론, 일반적으로 그럴 수 있다고 생각한다.자본주의 사회에서 ‘돈’은 그 사람을 평가하는 가장 기본적인 ‘수단’이기 때문이다. 성공하지 못한 필자는 아니지만, 필자 주변에는 고급 승용차인 BMW나 벤츠를 직접 몰고 다니는 성공한 개발자들이 여럿 있다. 그리고, 상당히 많다. 사업을 하는 사람으로부터, 프리랜서인 사람까지 매우 다양하다.분명, 그들은, 자신만의 서비스와 제품을 실현하였고, 시장에서도 안정적인 자신만의 브랜드를 확립하였고, 후배들로 존경을 받고 있으며, 직원들에게 비전과 꿈을 주고 있으며, 새로운 기술과 시장에 대해서 언제나 도전하고 있는 사람들이 있다.그들은 충분히 ‘성공’한 사람들이다.‘복제’와 ‘아류작’이 아니더라도. 독특한 자신들만의 서비스와 제품을 구현하여 성공한 개발자들이 분명 존재한다.그들의 성공요인을 주변의 사람으로서 살펴본다면, 몇 가지의 요인이 있다고 정의할 수 있다. 그것들을 필자의 주관적인 생각으로 정리해보면, 크게 4가지 정도로 정리할 수 있다고 본다.하나. 그들은 뛰어난 개발자는 아니었다.그들은 아주 탁월한 능력을 소유한 개발자들은 아니었다는 점이다. 그리고, 아주 뛰어난 학벌을 가진 개발자들도 아니었다. 개발자 동호회에서 만난 친구도 있고, 직장생활이나 사회생활에서 만난 사람도 있었지만. 그들은 아주 탁월한 재능을 지녔거나, 엄청난 코딩능력, 뛰어난 직관을 지닌 사람만은 아니었다.순수한 개발 능력만 놓고 본다면, 오히려, 뒤처지는 개발자들이었는지도 모른다. 하지만, 뛰어난 개발자들이나 아이디어를 가진 사람들과 친하게 지냈으며, 그들의 도움을 자연스럽게 얻어내는 소통의 달인은 아니었지만, 개발자 커뮤니티에 매우 즐겁게 활동을 하던 사람들이었다.둘. 그들은 우직하지만, 묵묵하게 자신의 상품과 아이디어를 다듬었다.그들은 하나의 아이디어가 실현되는 것을 쉽게 포기하지 않았다. 사업을 하기 전에는 그 아이디어를 실현하기 위해서 애썼고, 속한 회사가 아이디어에 대해서 낮은 평가를 하는 것에 대해서도 크게 실망하지 않았다. 오히려, 반대를 해도 해당 서비스와 제품, 기술에 대한 애정이 정말 높았으며, 그것을 실현하려고 매우 애썼다.처음에는 언제나 소프트웨어는 단순한 것부터 시작한다.그 단순한 것을 꾸준하게 다듬고, 소프트웨어에서 제품으로 다듬어서 시장에서 가치를 인정받을 수 있도록 수년 이상을 투자하고 노력해야만 얻어진다. 그것은 스티브 잡스도 똑같았다. iOS는 하루 이틀 만에 나온 소프트웨어가 아니기 때문이다.심지어, 몇 년 동안 밥을 굶더라도, 자신이 생각하는 가치를 실현하기 위해서 포기하지 않고 도전했던 우직한 도전이 오히려 성공을 만들어 내었다. 분명, 훌륭한 소프트웨어는 뛰어난 기술로 만들어지는 것만은 아니다는 것을 요 근래에서야 필자도 느낀다.필요한 가치가 적정한 가격에 구현되어진 것이 정말 필요하다는 점이다. 뛰어난 기술이 뛰어난 제품을 만드는 것이 아니라, 뛰어난 제품이 뛰어난 기술을 만든다는 것이다. 그것이 사용자들로 하여금, 또 다른 가치를 얻을 수 있는 기능을 제공한다는 것에 대해서 굳이 설명하지 않더라도, 그들은 그 아이디어와 생각을 실현하기 위해서 자신만의 길을 걸었다.정말 우직할 정도로... 필자 주변의 그들은, 몇 년을 일 년에 몇백만 원을 벌더라도, 그 꿈을 포기하지 않았다.셋. 시장과 세상의 시선을 그렇게 두려워하지 않았다. 자신의 ‘가치’와 ‘비전’을 실현했다.자신의 아이디어와 자신의 서비스, 제품을 지키기 위해서 약간의 주변 사람들에게 욕을  얻어먹는 것을  두려워하지 않는다. 필자가 아는 어떤 기업은 시장에서는 냉혈안이라는 말도 듣고, 불법 복제된 제품에 대해서는 가차 없는 소송도 불사하는 어떤 기업을 알고 있다. 하지만, 그 회사와 그 사장에 대해서 필자는 비난하지 않는다. 왜냐하면, 그는 기업 내부의 직원들에게는 절대 급여를 밀리지 않고, 야근을 시키지 않는 최고의 사장이었기 때문이다.시장과 타인에게는 가차 없지만, 자신이 생각한 비전을 실현한 회사를 만들기 위해서 언제나 최선을 다하는 사람이었을 뿐이다. 그리고, 자기 것을 지키기 위해서 애를 썼고, 직원들과의 거리도 언제나 적절하게 유지했다. 냉정하게 기업과 사업이라는 것은 자선사업이 아니라는 것을 잘 알고 있었다. 충분하게 돈을 벌고, 외제 승용차를 사장은 타고 다니지만 ( 외제 승용차를 타는 것도, 대한민국은 간단하다. 법인세를 충분하게 낼 정도로 수익이 생기면, 그 수익으로 차를 리스해서 타면 간단하다는 대한민국의 세법 구조 때문이다. ), 모든 직원들에게 그 이익을 100% 나누어주지는 않는다. 직원은 직원일 뿐이니까.그들은 회사의 재정이 힘들어지면 소속된 직원을 힘들기 전에 내보낼 줄도 알고, 필요하다면... 해고도 그리 어렵지 않게 결정하는 사람도 있다, 영업기밀을  들고나간 직원과 소송도 불사했다. 차라리, 친구와 따로 술을  마실지언정, 직원들과의 ‘관계’는 냉정하고 쿨한 관계를 유지했다. (물론, 그렇지만. 인간관계가 깨어지는 것을 매우 괴로워하는 사람들이다. 다만, 아래 직원들에게 속시원히 이야기를 못할 뿐이다. )넷. 필요한 기술자나 기술은 기필코 얻으려 노력했다.그들은 자신이 부족한 점을 잘 이해하고 있었다. 부족한 것을 오히려, 더 널리, 많이 이야기를 하였다. 그리고, 그것을 커버하기 위해서 매우 많은 노력을 한다. 다 잘하고자 하는 팔방미인이 되는 것이 아니라, 자신이 부족한 점을, 자신이 가장 잘하는 것으로 커버하려 애쓴 것이다. 전문적인 기술을 소유한 사람에게 도움 요청하는 것을 부끄러워하지 않고, 도와준 사람에게 충분한 대우나 접대를 잊지 않았다. 그래서, 그들이 도와달라고 하면, 주변의 전문가들이 아낌없이 그를 도와준다.그 이외에서 그들은 그렇게 ‘성실’하게 일하는 친구들은 아니었다. 실제, 사장이었던 그들이 직원의 입장으로 회사를 다닐 때에는 근태 문제로 지적을 받은 친구들도 꽤 많다는 점이다. 아마도, 사업이나 자신이 좋아하는 일을 하는 것과, 어떤 일이 주어진 상태에서 일을 하는 것은 분명 다른 지도 모르겠다. 직원일 때에 불성실하지만, 자신의 일을 할 때에 성실한 것은 전혀 상관관계가 없어 보인다. 한편으로는 ‘사장’이나 ‘자신의 일’을 하는 사람의 경우에는 특별하게 ‘근무시간’이라는 것 자체는 큰 의미가 없다는 점이 더 정답일 것이다. 하여간, 그들은 성공한 개발자들이고, 성공한 기업인이 되어 있었다. 자신만의 제품이나 서비스를 만들면 자연스럽게 ‘사장’이 되어버리는 것이 소프트웨어 업계의 현실인 듯하다.그렇다면, 대한민국에서 ‘성공’이란 ‘돈’을 의미하는가?강남의 최고급 아파트와 외제 승용차가 성공을 의미할까?자신의 뛰어난 기술력으로 커뮤니티에서 인정받고, 유명해진 명예를 얻는 것이 성공을 의미할까? 다른 사회현상을 생각하면서 다시 한번 비교해보자.요즘 개발자들도 오디션 프로에 영향을 받은 듯하다. 요즘 연예계 지망자들이나 배우나, 가수를 꿈꾸는 친구들이 선배나 멘토들에게 묻는 것이 언제나 똑같다고 한다.그것은 ‘빠르게 성공’하고 ‘빠르게 명예’를 얻는 방법이 무엇이냐 묻는 것이다.어렵고 복잡하고, 길게 걸리는 방법은 무시하고, 오디션 프로에서 1등을 해서, 빠르게 성공하는 방법만을 생각한다고 한다.물론, 그 방법도 있을 것이다.소프트웨어의 세계에도 똑같은 방법이 있다. 대표적인 방법이 유명대학을 가서, S 멤버쉽이 되고, 대기업에 입사해서 경력을 쌓은 다음, 해외의 서비스를 적당하게 분석하다가, 성공적으로 론칭한 서비스를 재빠르게 국내에 도입해서 성공에 이르게 하는 방법이 아마도 가장 빠른 방법일 수 있겠다.물론, 이 방법으로 ‘성공’을 쟁취하려 하는 개발자라고 하더라도. 비난하지 않는다.분명, 그 길은 대다수 ‘성공’이라고 부른다. 하지만, 그 길을 선택하고 집중하는 것 또한 매우 어렵고 힘든 길이다. 선택한다고 얻을 수 있는 길도 아니다.가령, 이 글을 읽는 독자가 학생이라면. 가장 먼저 명문대학을 가는 것부터 시작해야 할 테니, 당장, 이 내용을 덮어버리고, 국영수를 공부하는 것에 몰두해야 하기 때문이다.사실, 가장 넓게 알려진 성공으로 가는 길은 가장 가기 어려운 길인지도 모른다. 경쟁이란 정말 어렵고 힘들 것이라는 것을 잊지 말자.본론으로 다시 돌아와 보자. 개발자로서 '성공'이란 무엇을 의미하는가? 아니, 개발자로서 비전을  갖는다는 것은 무엇을 의미하는가?  원천적으로 개발자의 삶이란 어떻게 살아야 하나요라고 묻는다면,이 문제는 정말 어렵고, 사람마다 다르기 때문에 최선을 다하는 것이 정답이라라는 교과서적인 답변만 늘어놔야 하는지도 모르겠다.이점에 대해서는 이제는 폐간했지만 오랫동안 개발자들의 벗이 되었던 마이크로소프트웨어 잡지에 대해서 원망을  슬쩍해보자.그것은, 나에게 ‘정말 대단히 큰 재미’를 선사했다는 것이 나에게 가장 처음 다가온 충격이었는지도 모른다. 처음에 가진 꿈은 그냥, ‘소프트웨어 개발’을 통해서 삶을 영유할 수 있는 것만으로 나는 행복했다는 점이다. 그래서, 이 소프트웨어의 세계로 진입하게 된 마이크로소프트웨어에 대해서 원망을 해야 하는지도 모르겠다.하지만 필자는 소프트웨어로써 ‘개발자로서 성공’을 하기 위해서, 이 직업과 삶을 선택한 것이 아니라, ‘개발자로 살기 위해서’이 삶을 선택한 것이었다. 나이를 먹고, 무언가를 목표로 살아온 경험을  되돌아본다면, ‘돈’과 ‘명예’를 선택하지 않았을 때에, 오히려, ‘돈’과 ‘명예’를 얻지 않았는가 하다. 오히려, ‘돈’을 선택하던 시기에 ‘돈’을 더 많이 잃어버린 경험도 가지게 되었다.이제는 주변을  되돌아보면, 필자는 꽤 넓은 스펙트럼을 가지게 되었다는 것을 느끼게 된다. 한때는 고인이 되셨지만 대통령이셨던 분부터, 수천억을 소유한 재벌 총수, 의료재단과 대학법인을 소유하신 분, 병원의 원장님들을 비롯한 분들을 비롯하여, 출판계, 영화계, 물론. 다수의 소프트웨어 개발자들까지. 매우 넓은 사람 관계를 만들어본 것 같다.그중에 소프트웨어 개발자들은 참 착하고 바보스러운 사람들이 많은 것 같지만, 한편으로는 너무도 욕심이 많은 사람들이 존재하는 참, 신기한 동네이다.그리고, 여러 계층을 경험해보니. 모든 계층은 똑같이 피라미드 구조를 가지고 있다는 점이다. 대부분 다 똑같았다. 하층의 사람들은 싼 가격에 노동력과 지식을 제공하고, 상위 레벨에서는 적절한 대우 이상과 재미있고 신기한 일들을 많이 한다는 점이다. 이 부분은 어느 계층이나 똑같다.대표적으로 출판일을 경험했을 때에 자신의 이름이 들어간 편집장이 되는 사람과, 그것을 목표로 기획자로 일하는 직원의 급여 수준이나 처우, 대우는 정말 최고급 아키텍트와 SI 개발자를 비교하는 것 이상으로 그 상대 감은 소프트웨어 개발세 상의 것 이상으로 매우 컸다.행복한 개발자라고 한다면, ‘개발이 정말 재미있고’, ‘개발도 잘하고’, ‘소프트웨어 개발 피라미드의 상층부의 일’을 하고 있다는 사람이 있다면. 그 사람은 정말 행복할 것이다. 뭐, 그런 사람은 이 글을 읽고 있지도 않을 것이다.그러나, 개발이 재미있지 않거나, 개발을 뛰어나게 잘하지도 못하고, 소프트웨어 개발 피라미드의 하층부에서 일하고 있다면, 어떻게 생존해야 하는 가에 대해서 정말 심각하게 고민해야 한다.이 글을 읽는 독자가 이제 개발자의 길을 시작한 사람이라면 고민해라, 소프트웨어 개발을 비롯한 모든 전문적인 직업들은 새로운 것을 배우고, 익히고, 소모하면서 계속 변화되는 것을 즐길 줄 알아야 재미있는 직업이다. 그런 것이 아니라면, 정말 힘들고, 피곤하고 어려운 것이 전문직과 같은 직업이다. 만일 그런 것이 힘들다면 다른 일을 알아보는 것이 현명하다.소프트웨어 개발자들과 가장 비슷하게 일하는 웹디자이너들의 푸념이 있다.‘낮은 급여에 야근은 허구한 날, 거기에. 불투명한 미래’에 대한 그들의 이야기를 들으면서, 흔히 소프트웨어 개발자들은 그 질문에 답변한다. ‘너희들은 모니터라도 크지’라고. 대부분의 프로젝트들은 ‘분석’에 의해서 ‘일정’을 만들지 않고, ‘일정’을 통해서, ‘품질’을 선택한다고 봐야 한다.‘정말 하고 싶은 것이 무엇인가?’개발자들에게 물어보면, 대부분 당황하는 경우가 많다. 이것은 개발자이기 때문에 답변을 못하는 것이 아니라, 자신의 비전이나 꿈에 대해서 명쾌하게 정의하지 못하고 있기 때문이다. 주변의 초보 개발자들에게 이야기하고 싶은 점은...가끔은 수필집이나 여행기, 그리고. 다른 사람의 생각과 꿈에 대한 글을 많이 읽어보라고 권하는 것이다. 그러면, 그 비전과 꿈에 대해서 이야기해달라는 사람들이 꽤나 있고는 하다.문제는 그 비전은 누가 정해주는 것이 아니라, 자신이 생각하거나, 자신이 발견하는 것이 옳지 않냐고 다시 이야기를 해준다. 물론, 이렇게 이야기하는 사람도 있다.‘저는 이번 프로젝트에서 인정을 받아서, 다음 프로젝트를 수행할 때에는 팀장이 되고 싶어요!’라고 이야기할 수 있다. 하지만, 이런 ‘단기적인 비전’을 말하는 것은 아니다. 이런 ‘단기적인 비전’만을 따라가다 보면, 냉정하게 수단만 중요시 여기게 되고, 목적 자체를 잃어버린 인생의 방랑자가 될 가능성이 매우 크다.내가 생각하는 ‘성공’이란 과연 무엇인가?또 하나는, 그 ‘성공’의 목표를 너무 작게 가져도 문제이고, 너무 커도 문제라는 점이지만, 그래도, ‘꿈’과 ‘목표’가 있다는 것 자체가 재미있고, 신기하지 아니한가?‘성공은 자신이 정한 것을 이루는 것’을 의미한다고.그럼 ‘꿈’을 어떻게 정의하나요?1. 10년, 20년, 30년 후의 자신의 모습을 상상해보고 정의해봐라.2. 현재 내가 좋아하는 모든 것들을 적어봐라.3. 내가 가장 잘하고 가장 인정받는 것을 적어봐라.보통은 이렇게 끄적거리다 보면, 무언가가 조금은 구체적인 비전이 나올 수도 있지만, 아무렇지도 않은 것이 나올 수 있다. 하지만, 일단, 끄적이기 시작했다면, 다음번에는 좀 더 잘할 수 있다는 것이 중요하다. 가장 중요한 것은 ‘내가 비전에 대해서 생각하기 시작했다’는 점이다. 일단 작심 3일이라도 중요한 결정이다. 그것은, ‘결정’을 하고 ‘결심’을 하기 시작했다는 것이기 때문이다.일단, ‘써야 한다’. ‘생각은 생각일 뿐이다’주변의 개발자들이 가장 잘 못쓰는 말 중의 하나가 ‘머릿속에 다 있다’라는 말이고, ‘글로 쓰기에 너무 어려운 이야기’이다라는 이야기가 가장 잘못된 것이라는 것을 잘 모르는 경우가 많다.‘머릿속에 다 있다’라는 이야기는 한번 생각은 해봤으나, 결론을 내리지 못하였다는 이야기로 들리고, ‘글로 쓰기 어렵다는 이야기’는 그만큼 정리가 안되고, 그 일에 대해서 잘 모른다는 이야기와 똑같다.10년 20년 특정 도메인에서 일한 베테랑이라고 하는 개발자와 일을 할 때에, 자신이 하는 일은 너무도 복잡하여, 설계도나 다이어그램, 순서도, 타이밍 차트 등을 그릴 수 없다는 사람들이 있다.그들과 이야기하고, 그 업무를 다이어그램과 설계도로 만들어 주어도, 그들은 그것 말고, 설명이 안 되는 그 무언가가 있다고 이야기를 한다. 물론, 필자는 그때에 이렇게  이야기해준다.‘만일 그러한 것이 존재한다면. 그것은 당신만이 생각하는 경험이나 당신이 소중하게 생각하는 가치인지 모른다. 하지만, 그것은 어떤 지식이 되기에 매우 부족한 것일 수 있다. 지식은 설명하기 쉽고, 이해하기 쉬운 것이 지식이다. 설명하기 어려운 경험은 정규화되거나 전달되어지기 매우 어렵다’더 쉽게 이야기하면. ‘쉽게 설명하거나 글자로 남기지 못한다면, 당신은 그것에 대해서 잘 알고 있지 못한 것입니다’비전이나 목표 잡기가 너무 어려워요?!그렇다면, 당장 휴일에 컴퓨터를 내버려두고, 아이폰이나 패드와 같은 스마트하다고 우기는 디지털기기를 집안에 던져두고 여행을 떠나는 것이 현명한 방법이겠다. 그리고, 다른 매체를 들여다보고, 개발자 이외의 사람들을 만나서 이야기해보라라고 권유해야 하는 것이 맞을  듯하다.생각 이상으로 소프트웨어 개발자의 세계는 정말 좁다. 그리고, 단편적인 지식들과 단편적인 경험들만이 존재하는 세상인지도 모른다. 그래서, 소프트웨어 개발자들은 ‘관심의 폭을 넓히고,’ ‘자신을 확장’하는 것이 결론적으로는 더 뛰어난 개발자가 된다는 것을 나중에야 깨달을 것이다. 마지막으로 이야기한 한다면, 소프트웨어 개발자에게 ‘성공’이란 일단... 전혀 해보지 않았던 것을 도전해보는 것, 그리고. 삶은 소프트웨어 개발처럼 버전을 나누어서 설명하기 어렵다는 것을 이해하고. 무언가 계속 새로운 것에 도전한다는 것이 진정한 ‘성공’ 아닌가 한다.#와탭랩스 #와탭 #개발자 #개발 #프로그래머 #성공 #성공한개발자
조회수 3743

iOS에서 간결한 API 클라이언트 구현하기 (like Retrofit+GSON)

이 글은 안드로이드 개발에서 웹 서버 API 클라이언트를 간결하게 구현할 수 있도록 도와주는 강력한 오픈소스 라이브러리인 Retrofit과 GSON의 조합을 iOS 개발에서도 따라해보고 싶은 분들을 위해 작성되었습니다. Retrofit+GSON를 실제로 사용하는 좋은 예제는 다른 블로그 글에서도 찾아볼 수 있습니다.배경리디북스 서비스가 발전하면서 점점 복잡해지고, 자연히 앱의 기능도 다양해지기 시작했습니다. 기능이 다양해지면서 웹 서버와의 연동을 위한 API 종류도 늘어났고 앱 내에서 API 호출이 필요한 부분도 다양해지면서 관련된 중복 코드가 이곳 저곳에 산재하게 되었고 전체적인 코드 퀄리티 향상을 위해 이를 최소화하고 모듈화 할 필요성이 생겼습니다.안드로이드에서는 Pure Java로 작성되어 어노테이션을 통한 간결한 코드를 사용할 수 있게 해주는 Retrofit을 GSON과 연동하여 JSON 응답을 손쉽게 객체에 맵핑 하여 사용함으로써 이러한 문제를 성공적으로 해결할 수 있었습니다. 이후 iOS 개발을 진행하면서 비슷한 역할을 할 수 있는 도구가 있을까 찾아봤지만 마땅하지 않아 결국 사용 가능한 도구들을 이용해 비슷하게 따라해보기로 했습니다.목표Retrofit+GSON 조합을 최대한 따라해서 iOS 앱의 코드 퀄리티를 높이기 위한 작업을 진행하기는 하지만 모방하는 것 자체가 목적이 될 수는 없으므로, 구체적인 목적은 다음과 같은 것들로 상정해보았습니다.API 통신 부분을 모듈화하여 관련 중복 코드를 최소화하기NSArray, NSDictionary를 직접 사용하여 제어 했던 JSON 처리 부분을 추상화하여 모델 클래스를 정의, JSON 응답을 자동으로 객체에 맵핑 해서 사용할 수 있도록 하기필요한 것Retrofit과 GSON의 동작에 대한 이해AFNetworking비동기 HTTP 요청 처리에 용이하므로 기존에도 이미 API 호출을 위해서도 사용하고 있었습니다.이 글의 내용은 버전 2.6.3 기준입니다.Swift 언어와 그에 대한 이해사실 Objective-C를 사용해도 무방하지만, 작업 당시 Swift가 발표된 지 얼마 되지 않은 시점 이었기 때문에 시험 삼아 선택 되었으며 실제로 Swift가 Objective-C 대비 가진 장점들이 적지 않게 활용되었습니다.이 글의 내용은 버전 2.0 기준입니다.구조와 동작클래스 이름 앞에 붙어 있는 RB는 리디북스에서 사용하는 클래스 접두어 입니다.RBApiServiceAPI 통신을 담당하는 부분의 핵심은 중앙의 RBApiService 클래스를 포함한 상속 구조라고 할 수 있으며 상술하면 다음과 같습니다.AFNetworking에서, HTTP 요청 작업의 큐잉부터 시작과 종료까지 라이프 사이클 전반을 관리하는 역할을 하는 AFHTTPRequestOperationManager를 상속받는 RBApiService 클래스를 정의각 API들은 역할군에 따라 RBBookService(책 정보 관련 API), RBAccountService(사용자 계정/인증 관련 API) 등과 같은 RBApiService의 하위 클래스들의 메소드로 정의됨이 하위 클래스들이 AFHTTPRequestOperationManager의 역할을 그대로 이어받아 자신을 통해 이루어지는 API HTTP 요청 작업들을 관리이 설명에 따르면 웹 서버의 /api/foo/bar API를 요청하는 메소드는 RBFooService 클래스에 다음과 같이 정의될 것입니다.func bar(param1: String, param2: String, success: RBApiSuccessCallback, failure: RBApiFailureCallback) -> AFHTTPRequestOperation! { let paramters = ["param1": param1, "param2": param2] responseSerializer = RBJSONResponseSerializer(responseClass: RBFooBarResponse.class) return GET("/api/foo/bar", parameters: parameters, success: success, failure: failure) }RBApiSuccessCallback과 RBApiFailureCallback은 요청과 응답이 완료되고 각각 성공, 실패일 때 호출되는 람다 함수(Objective-C의 block에 대응되는 개념) 타입으로 다음과 같이 typealias를 통해 선언되어 있습니다. typealias RBApiSuccessCallback = ((operation: AFHTTPRequestOperation, responseObject: AnyObject) -> Void)? typealias RBApiFailureCallback = ((operation: AFHTTPRequestOperation?, error: NSError) -> Void)?GET 메소드는 AFHTTPRequestOperationManager의 메소드로 새로운 HTTP GET 요청 작업을 생성하고 큐에 넣은 뒤 그 인스턴스를 반환합니다. bar 메소드는 이렇게 반환된 인스턴스를 다시 그대로 반환하는데 API 호출을 의도한 측에서는 이 인스턴스를 통해 필요한 경우 요청 처리를 취소할 수 있습니다. API에 따라 GET 이외의 다른 방식의 요청이 필요하다면 POST, PUT, DELETE등의 메소드들 또한 사용할 수 있습니다.RBFooBarResponse 클래스는 이 API 호출의 JSON 응답을 맵핑하기 위한 모델 클래스입니다. 이 API 요청의 응답은 RBJSONResponseSerializer 클래스를 통해 사전에 정의된 규칙에 따라 적절히 RBFooBarResponse 인스턴스로 변환되고 이 모든 과정이 성공적으로 진행되면 RBApiSuccessCallback의 responseObject 인자로 전달됩니다.모델 클래스와 RBJSONResponseSerializer앞서 이야기했듯이 RBJSONResponseSerializer는 JSON 형태로 온 응답을 특정 모델 클래스의 인스턴스로 맵핑시키는 작업을 수행합니다(Retrofit+GSON 조합에서 GsonConverter의 역할에 대응한다고 볼 수 있습니다).iOS 개발에서 전통적으로 JSON을 다루는 방식은 Cocoa 프레임워크에서 기본적으로 제공하는 NSJSONSerialization 클래스를 이용하여 JSON Array->NSArray로, 그 외의 JSON Object는 NSDictionary로 변환하여 사용하는 방식입니다. 이러한 방식을 사용할 경우 별다른 가공이 필요 없다는 장점이 있는 대신 다음과 같은 문제들에 직면할 수 있습니다.데이터가 명시적으로 정의된 프로퍼티로 접근되지 않고 문자열 키 기반의 키-밸류 형태로만 접근되므로 데이터의 타입이 명시적이지 않아 타입 검사와 캐스팅이 난무하게 되어 가독성을 해침오타와 같은 개발자의 단순 실수로 인한 버그를 유발할 가능성도 커짐특히 오타로 인한 버그의 경우 명시적인 모델 클래스의 프로퍼티로 맵핑 해서 사용한다면 IDE가 에러를 검출해주거나 최소한 빌드 타임 에러가 발생할테니 미연에 방지할 수 있습니다. 이러한 문제는 사소한 실수로 인해 찾기 힘든 버그가 발생한다는 점과 코드 리뷰를 통해서도 발견하기가 힘들다는 점에서 지속적으로 개발자를 괴롭힐 수 있습니다.RBJSONResponseSerializer를 통한 인스턴스로의 변환은 이런 문제 의식에서 출발했고 Retrofit에 GSON을 연계하여 사용하기 위한 GsonConverter가 해결을 위한 힌트를 제공한 셈입니다.// AFJsonResponseSerializer는 NSJSONSerializer를 이용해 NSArray/NSDictionary로 변환하는 기본적인 작업을 해줌 class RBJSONResponseSerializer: AFJSONResponseSerializer { var responseClass: NSObject.Type! override init() { super.init() } required init(responseClass: NSObject.Type!) { self.responseClass = responseClass super.init() } required init(coder aDecoder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func responseObjectForResponse(response: NSURLResponse?, data: NSData?, error: NSErrorPointer) -> AnyObject? { // 파서를 직접 구현하는 건 노력이 많이 필요하므로 우선 AFJSONResponseSerializer를 이용해 NSArray/NSDictionary로 변환 let responseObject: AnyObject! = super.responseObjectForResponse(response, data: data, error: error) if let dictionary = responseObject as? NSDictionary where responseClass != nil { // 변환 결과가 NSDictionary이면서 responseClass가 정의되어 있다면 변환 작업 시작 return responseClass.fromDictionary(dictionary, keyTranslator: PropertyKeyTranslator) } // NSArray라면 JSON이 top level array로 이루어졌다는 뜻이므로 변환 불가로 보고 그대로 반환 // 혹은 responseClass가 정의되어 있지 않아도 그대로 반환 return responseObject } }Key translatorfromDictionary 메소드 호출 시 함께 인자로 전달되는 keyTraslator는 JSON에서 사용되는 키로부터 모델 클래스의 프로퍼티 이름으로의 변환을 나타내는 람다 함수로 개발자가 원하는 규칙에 따라 정의하면 됩니다. 위의 코드에서 사용 중인 PropertyKeyTranslator는 리디북스 API에서 사용 중인 규칙 및 Swift의 네이밍 컨벤션에 따라 다음과 같이 언더스코어(_) 케이스로 된 이름을 카멜 케이스로 바꾸는 형태로 정의되었으며 이는 GSON의 FieldNamingPolicy 중 LOWERCASE_WITH_UNDERSCORES와 유사합니다.let PropertyKeyTranslator = { (keyName: String) -> String in let words = keyName.characters.split { $0 == "_" }.map { String($0) } var translation: String = words[0] for i in 1..NSObject.fromDictionary 메소드fromDictionary 메소드는 NSDictionary로 표현된 데이터를 실제 모델 클래스의 인스턴스로 변환하는 작업을 수행하며 NSObject의 extension(Objective-C의 category 개념과 유사합니다)으로 정의하여 원하는 모델 클래스가 어떤 것이든지 간에 공통적인 방법을 사용할 수 있게끔 했습니다.extension NSObject { class func fromDictionary(dictionary: NSDictionary) -> Self { // keyTranslator가 주어지지 않으면 디폴트 translator 사용 return fromDictionary(dictionary, keyTranslator: { $0 }) } class func fromDictionary(dictionary: NSDictionary, keyTranslator: (String) -> String) -> Self { let object = self.init() (object as NSObject).loadDictionary(dictionary, keyTranslator: keyTranslator) return object } func loadDictionary(dictionary: NSDictionary, keyTranslator: (String) -> String) { // 주어진 dictionary에 포함된 모든 키-밸류 쌍에 대해 작업 수행 for (key, value) in (dictionary as? [String: AnyObject]) ?? [:] { // keyTranslator를 이용해 키를 프로퍼티 이름으로 변환 let keyName = keyTranslator(key) // 프로퍼티 이름을 사용할 수 있는지 검사 if respondsToSelector(NSSelectorFromString(keyName)) { if let dictionary = value as? NSDictionary { // 밸류가 NSDictionary면 해당 프로퍼티의 타입에 대해 fromDictionary 메소드 호출 if let ecls = object_getElementTypeOfProperty(self, propertyName: keyName) as? NSObject.Type { setValue(ecls.fromDictionary(dictionary, keyTranslator: keyTranslator), forKey: keyName) } else { NSLog("NSObject.loadDictionary error: not found element type of property. (key: \(keyName), value: \(dictionary))") } continue } else if let array = value as? NSArray { var newArray = [NSObject]() // 밸류가 배열이면 각 요소별로 작업 수행 for object in array { if let dictionary = object as? NSDictionary { // 배열 요소가 NSDictionary면 프로퍼티의 배열 요소 타입에 대해 fromDictionary 메소드 호출한 뒤 배열에 추가 if let ecls = object_getElementTypeOfProperty(self, propertyName: keyName) as? NSObject.Type { newArray.append(ecls.fromDictionary(dictionary, keyTranslator: keyTranslator)) } else { NSLog("NSObject.loadDictionary error: not found element type of property. (key: \(keyName), value: \(dictionary))") } } else if let object = object as? NSObject { // NSDictionary가 아니면 그대로 배열에 추가 newArray.append(object) } else { NSLog("NSObject.loadDictionary error: can't cast element. (key: \(keyName), value: \(object))") } } setValue(newArray, forKey: keyName) continue } else if value is NSNull { continue } // NSDictionary, NSArray가 아니면서 null도 아니면 그대로 사용 setValue(value, forKey: keyName) } } } }주어진 dictionary에 존재하는 모든 키-밸류 쌍에 대해 밸류가 가진 타입과 이에 대응하는 프로퍼티의 타입에 따라 적절히 프로퍼티에 대응될 객체를 구한 다음 Cocoa 프레임워크에서 제공하는 KVC를 이용해 채워넣습니다.프로퍼티 타입 정보 가져오기모델 클래스가 반드시 Int, String, Float과 같은 기본적인 타입들로만 이루어져 있을 필요는 없고 다른 모델 클래스의 인스턴스나 배열을 포함하고 있어도 타입 정보를 런타임에 가져와 재귀적으로 데이터를 채워나가는 것이 가능합니다. 프로퍼티의 타입을 알아내는 과정은 다음과 같이 Swift에서 제공하는 Mirror 구조체를 통해 이루어지는데 이는 마치 (이름에서도 느낄 수 있듯이) Java의 리플렉션을 떠올리게 합니다.// 타입 이름에서 특정 접두어("Optional", "Array", "Dictionary" 등)를 찾아 제거 func encodeType_getUnwrappingType(encodeType: String, keyword: String) -> String { if encodeType.hasPrefix(keyword) { let removeRange = Range(start: encodeType.startIndex.advancedBy(keyword.length + 1), end: encodeType.endIndex.advancedBy(-1)) return encodeType.substringWithRange(removeRange) } else { return encodeType } } // object의 타입에서 propertyName의 이름을 갖는 프로퍼티의 타입 이름을 반환 func object_getEncodeType(object: AnyObject, propertyName name: String) -> String? { let mirror = Mirror(reflecting: object) let mirrorChildrenCollection = AnyRandomAccessCollection(mirror.children)! // object의 타입 구조 children 중에서 propertyName을 찾음 for (label, value) in mirrorChildrenCollection { if label == name { // Optional 타입인 경우 "Optional" 접두어를 제외 return encodeType_getUnwrappingType("\(value.dynamicType)", keyword: "Optional") } } return nil } // object의 타입에서 propertyName의 이름을 갖는 프로퍼티의 타입 인스턴스를 반환 func object_getElementTypeOfProperty(object: AnyObject, propertyName name: String) -> AnyClass? { // 타입의 이름을 가져옴 if var encodeType = object_getEncodeType(object, propertyName: name) { let array = "Array" // "Array" 접두어로 시작할 경우 (배열인 경우) if encodeType.hasPrefix(array) { // "Array" 에서 "Array" 제외하고 T를 반환 return NSClassFromString(encodeType_getUnwrappingType(encodeType, keyword: array)) } let dictionary = "Dictionary" if encodeType.hasPrefix(dictionary) { // "Dictionary" 에서 "Dictionary", "K"를 제외하고 V를 반환 encodeType = encodeType_getUnwrappingType(encodeType, keyword: dictionary) encodeType = encodeType.substringWithRange(Range(start: encodeType.rangeOfString(", ")!.endIndex.advancedBy(1), end: encodeType.endIndex)) return NSClassFromString(encodeType) } // 커스텀 클래스 접두어를 가지고 있다면 그 타입 그대로 반환 if encodeType.hasPrefix(RidibooksClassPrefix) { return NSClassFromString(encodeType) } } return nil }RidibooksClassPrefix는 커스텀 클래스들의 접두어를 나타내는 상수이며(리디북스의 경우 앞서 이야기했듯 “RB”), 이 접두어가 붙어있는 경우에만 모델 클래스로 간주해 해당 타입 인스턴스가 반환됩니다.예시앞서 정의한 PropertyKeyTranslator를 사용했을 때, 위에 예시로 사용했던 /foo/bar API 요청의 JSON 응답과 모델 클래스 및 생성되는 인스턴스 형태의 예를 들면 다음과 같을 것입니다.(Int, Bool, Float과 같은 기존 NSNumber 기반의 타입을 가지는 프로퍼티들은 아직 정확한 원인은 알 수 없으나 nil 이외의 값으로 초기화 해주지 않으면 프로퍼티가 존재하는지 확인하기 위해 사용하는 respondsToSelector 메소드가 false를 뱉게 되어 사용할 수 없으므로 클래스 선언시 적절한 초기값을 주어야 합니다.{ "success": true, "int_value": 1, "string_value": "Hello!", "float_value": null, "baz_qux": { "array_value": [1, 2, 3] } }class RBFooBarResponse : NSObject { var success = false // true var intValue = 0 // 1 var stringValue: String! // "Hello!" var floatValue: Float! = 0.0 // nil var bazQux: RBBazQux! } class RBBazQux : NSObject { var arrayValue: [Int]! // [1, 2, 3] }맺음말이런 작업들을 통해 당초 목표했던 두 가지, API 통신 관련 중복 코드를 최소화 하면서 JSON 응답을 가독성이 더 좋고 실수할 확률이 적은 모델 클래스의 인스턴스로 자동 변환 하도록 하는 것 모두 달성하는 데에 성공했습니다.다만 모든 것이 뜻대로 될 수는 없었는데 Retrofit+GSON과 비교했을 때 플랫폼 혹은 언어의 특성에 기인하는 다음과 같은 한계들 또한 존재했습니다.Retrofit에서는 Java 어노테이션을 이용해 API 메소드의 인터페이스만 정의하면 됐지만 iOS 구현에서는 GET, POST 등의 실제 요청 생성 메소드를 호출 하는 것 까지는 직접 구현해줘야 함키->프로퍼티 이름 변환 규칙에 예외 사항이 필요할 때 GSON에서는 @SerializedName 어노테이션을 통해 손쉽게 지정할 수 있지만 iOS 구현에서는 예외 허용을 위한 깔끔한 방법을 찾기가 힘듬 (다만, 예외가 필요한 경우가 특별히 많지는 않기 때문에 큰 문제는 되지 않음)향후에는 HTTP 통신을 위해 사용 중인 AFNetworking(Objective-C로 작성됨)을 온전히 Swift로만 작성된 Alamofire로 교체하는 것을 검토 중이며 기존에 비해 좀 더 간결한 코드를 사용할 수 있을 것으로 기대하고 있습니다. 다만 Alamofire의 최신 버전이 iOS 8 이상을 지원하고 있어 iOS 7을 아직 지원 중인 리디북스인 관계로 언제 적용할 수 있을지는 아직 미지수입니다.#리디북스 #개발 #개발자 #iOS #iOS개발 #API #API클라이언트 #GSON #Retrofit #중복코드 #최소화 #API통신 #웹서버 
조회수 1410

나는 부족한 사람입니다 -1

창업자 인터뷰 – 첫 창업설 연휴가 끝난 2월의 어느 날, 옐로모바일 사무실 내 까페인 '클럽옐로'의 한 미팅 룸에서 이상혁 대표를 마주했습니다. “나는 수줍은 사람입니다”라는 오프닝으로 시작된 옐로모바일의 공식 블로그. 그 첫 컨텐츠로 이 회사의 창업자인 이상혁 대표의 인터뷰를 싣기 위해서였습니다. 2시간여 동안 진행된 대담은 생각보다 흥미진진했습니다. 차분한 목소리로 이어진 대화였지만, 높고 낮은 굴곡이 있었고, 좌절과 희망이 보였습니다. 긴 대화를 마치고 나자 바로 떠오른 제목이 바로 “나는 부족한 사람입니다” 였습니다.완벽하기는커녕, 어찌 보면 지극히 평범한 이 대표의 실패와 시행착오로 가득 찬 인생 이야기를 지금 여러분께 전해드리고자 합니다.바쁜 여러분을 위한 Y의 다섯 문장 요약!!1. 창업은 상상도 못했던 대학생, 교수가 되고자 대학원에 갔으나 세미나 발표를 잘 못한다고 교수님이 세미나 중에 나가버리셨다?2. 석사 졸업하고 처음 시작한 직장 생활, 일을 못 해 첫 인사고과 'D'의 충격3. 우연한 만남으로 시작된 첫 창업, 처음엔 잘 나가는 듯 했으나 수년 뒤 회사 존폐 위기4. 7년 만의 피벗 (Pivot) 결정, 통장 잔고 200만원의 순간 수십억 원대 투자 유치5. 2년 후 마침내 이룬 흑자 전환, 그러나 근심 걱정은 이어지고대표님 안녕하세요, 사내기자 Y입니다.반갑습니다. Y라니, 뭔가 007 영화의 코드네임 같네요.하하 그런가요? 실은 옐로모바일 (Yello Mobile)의 앞 글자이기도 하지만, 계속해서 “왜(Why)”를 묻고 의미를 찾아보잔 뜻에서 지어본 이름입니다. 그런 의미에서 오늘은 인간 이상혁이 왜 지금 이 자리에 있게 되었는지를 파헤쳐보려고 합니다.파헤치실 것 까지야… 조금 긴장되네요ㅎ해치지 않습니다  그럼 과거로 돌아가서 시작을 해볼까 해요. 옐로모바일이 두 번째 창업으로 알고 있는데요, 학생 때부터 창업을 계획하셨나요?전혀요. 전 대학에서 경영학을 전공했습니다. 열심히 공부하며 나름 학점도 잘 받고 했지만, 내가 좋아하고 잘 할 수 있는 것이 무엇인지 감을 잡기 어려웠어요. 깊은 고민 끝에 내렸던 결론은, ‘어떤 것을 정리해서 남에게 설명하는 것에는 조금 자신이 있다, 하지만 큰 무리 앞에 나서는 것은 자신 없다, 그러니 교수가 되는 것에 도전해보자’ 였습니다.교수요? 묘하게 어울리는 것 같기도 한데요?그런가요?그 당시를 회고해보면, 인터넷이 처음 생기고 한창 홈페이지라는 것이 유행하던 때 였어요. 이 때 창업해서 인터넷과 게임 사업을 했던 동기들이 오늘날 대한민국 대표 IT 기업들을 이끌게 되었죠. 하지만 전 스스로가 창업과는 거리가 먼 사람이라고 생각했어요. 오죽했으면 오프닝 에서 보셨듯이 제 이모님께서 기사를 보시고 “이 상혁이가 우리 상혁이냐”는 말씀을 하셨겠어요ㅎㅎ 아무튼, 교수가 되기 위해선 학위가 필요했고, 그래서 대학원에 가 마케팅을 공부하기 시작했습니다. 매주마다 논문을 읽고, 교수님과 선배들 앞에서 세미나 발표를 하는 것이 진짜 고역이었어요. 스스로 발표를 못한다고 생각한 적이 없었는데, 매 번의 세미나는 제게 공포의 순간으로 다가왔죠. 심지어 제가 발표를 너무 못한다며 교수님께서 중간에 나가버리신 적도 있었어요. 그렇게 2년이 지나자 그래도 어딜 가서 발표 못한다는 얘기는 더 이상 듣지 않게 된 것 같아요.당시 교수님께서도 지금의 대표님을 보시면 꽤나 놀라시겠어요ㅎㅎ 계속해서 박사 공부는 안 하셨나요?당연히 박사 학위가 필요했고, 이왕 하는 것 미국 아이비리그에 도전해보고 싶단 생각이 있었어요. 하지만 미국 학교는 학비가 훨씬 비쌌고, 가정 형편이 넉넉하지 않아서 재정적으로 손을 벌릴 곳도 없었기 때문에, 학비 마련을 위해 직장 생활을 시작해야 했어요. 군 문제도 해결해야 했고요. 그래서 석사 졸업 후 삼성SDS 정보기술 연구소에서 3년간 근무하게 되었어요. 무려 개발 직군으로요.개발이요? 경영학과에 마케팅 석사셨는데요?그래서 하루하루가 너무 힘들었어요. 물론 기본적인 개발은 배운 적이 있었지만, 서울대나 카이스트 전산과 출신 친구들 틈바구니에서 IT 개발 업무를 할 때의 자괴감이란 이루 말할 수가 없었죠. 처음 몇 달을 떠올리면 네 글자가 떠올라요. 월.급.루.팡.월급루팡이라니... 웃프네요ㅜㅠ 그 위기를 어떻게 극복하셨나요?첫 인사평가에서 D를 받았어요. D를 두 번 받으면 나가라는 소리라고 하더라고요. 큰 충격을 받고 ‘살아남아야 한다’라는 일념 하에 선배, 동기들을 괴롭혀가며 밤새 개발 공부에 매달렸어요. 그렇게 6개월 정도 지났을 때, 여전히 동기들보다는 못 했지만 그래도 월급루팡 신세는 모면할 수 있었던 것 같아요. 다음 고과에서 B를 받았거든요. :)진땀 나는 6개월이었겠어요정말 그랬죠. 실은 살면서 학업 등에 있어 한 번도 실패를 맛보거나 뒤쳐진 적이 없었거든요. 그래서인지 제 부족함을 마주했을 때의 충격이 더 컸던 것 같아요. 그 충격 가운데서 얻은 중요한 깨달음이 몇 가지 있었어요. 하나는, ‘내가 남보다 못할 수 있다는 것이 당연하다’는 것. 내가 경험하지 못한 영역의 선배들, 능력자들과 경쟁하면 나는 아무것도 아닌 존재가 될 수 있다는 깨달음이요. 거기서 이어진 두 번째 교훈은 ’이 세상에 혼자 할 수 있는 것은 없다’는 것. 수많은 분들께 도움을 받으면서 그 동안 내 공부, 내 일만 신경 썼던 스스로가 많이 창피했어요. 세상은 서로 도우면서 성장하는 곳이라는 것을 체감하면서 크게 성장할 수 있었던 시기였죠.지금 이 자리를 빌어 그 당시 사수였던 류대선 선배님과 동기들에게 감사의 말을 전하고 싶네요ㅎㅎ영상메시지라도…?그런 건 부끄러워서 싫어요….ㅠㅠ네 알겠습니다ㅋㅋ 그럼 그 이후 박사 진학을 하셨나요?아니에요. IT 회사에서 팀원들과 함께 일을 하면서 새로운 재미를 느끼기도 했고, 당시 한메일, 네이버 같은 국민 서비스들을 보면서 새로운 도전에 눈을 뜨게 되었어요. 나도 창업을 해볼 수 있지 않을까란 생각으로 인터넷 경매 서비스 사업 계획서를 만들어 조언을 구하고자 KAIST 교수님을 찾아 뵈었다가 연구실 선배를 만났고, 그 때 함께 창업을 해보지 않겠냐는 제안을 받았어요. 믿고 신뢰하던 선배들과 창업을 할 수 있다는 사실에 들떴고, 1998년 9월, 5명의 창업멤버 중 막내로 시작했던 회사가 디엠에스랩이었죠.교수에서 창업가라, 뭔가 급선회한 느낌인데요, 사업 아이템이 무엇이었나요? 게임? 인터넷 서비스?동기들이 인터넷이나 게임 관련 사업을 했을 때, 저희가 택했던 것은 SI (System Integration) 컨설팅이었어요. CRM 전략 컨설팅 및 관련 시스템 구축업무가 핵심이었죠. 명백히 보이는 시장을 공략하고자 했던 생각이 컸던 것 같아요.컨설팅이라… 그럼 주로 어떤 업무를 하셨나요? 개발? 영업?작은 벤처에 제대로 된 업무 정의가 어디 있겠어요. 제안서를 쓰고, 선배들 따라다니며 제안 발표를 하고, 영업을 통해 프로젝트가 수주되면 프로젝트 관리를 하고, 산출물을 만들어 결과 발표도 하고… 필요한 모든 업무에 함께했죠.지금까지의 경험과는 또 다른 종류의 일들이었을 것 같은데요?그렇긴 했지만 잘 해낼 수 있을 것이란 자신감이 있었어요. 그 것이 착각이라는 것을 깨닫는데 그리 오랜 시간이 걸리지 않았다는 것이 함정이지만요. 막상 부딪혀 보니, 제대로 할 줄 아는 것이 하나도 없었어요.외람된 말씀이지만, 능력자 이미지와는 거리가 조금 멀었네요…하하하 맞아요. 선배들이 옆에 앉아 불러주는 것들을 파워포인트로 정리하며 제안서를 썼어요. 그리고 대기업 경영진 앞에서 발표하는 선배들의 모습을 보면서, 나도 발표는 조금 한다고 생각했던 스스로가 부끄러워졌죠. 수준 자체가 달랐어요. 그렇게 발표를 잘 했다고 수주가 되는 것은 또 아니었어요. 계약을 성사시키기까지 고객사 실무자, 팀장, 경영진이 원하는 것을 파악하고 해결책을 제시하며 확신을 주는 과정도 결코 만만치 않았죠. 프로젝트가 시작돼도 쉬운 것이 하나도 없었어요. 늘어가는 새치에 한숨도 많이 쉬었던 것 같아요ㅎㅎ 이 과정을 7년 동안 계속했어요.7년씩이나요?네. 실은 그렇게 오래 할 것이라고 아무도 생각하지 못했어요. 많이 힘들기도 했고요. 그래도 제게는 엄청난 배움의 시간들이었어요. 생각하는 것을 말로 잘 풀어내고, 이를 다시 글로 잘 정리하는 것을 배웠고, 사람의 마음을 사는 영업은 어떤 것인지, 그리고 프로젝트 관리를 하면서 발생하는 수많은 이슈들을 어떻게 하면 잘 해결할 수 있는지 등등.그 정도 시간이면 사업이 많이 성장했겠어요.처음 사업을 시작했을 때는 그렇게 될 줄 알았어요. 근데 실상은 그렇지 못 했죠. 초기에는 연간 몇 억 원의 흑자가 났지만, 몇 년 지나지 않아 경쟁이 치열해지고, 저가 수주 때문에 수익성이 떨어졌어요. 더 시간이 흐르니 고객사의 수요가 줄고, 심지어 우리 직원들이 고객사로 이직하면서 우리는 단순한 외주업체로 전락하게 되는 과정을 보았죠.엄청 심각한 상황으로 들리는데요?맞아요. 이 때 깨달은 것이, 명함과 회사 홈페이지를 만들고 힘차게 시작한 사업을 유지하는 것이 정말 힘들다는 것이었어요. 사업을 통해 흑자를 내는 것도 힘들지만, 그것을 유지하는 것은 더 힘들구나. 이래서 많은 비즈니스의 라이프사이클이 길지 않구나. 경쟁환경, 시장환경이 변하니 많은 회사들이 망하는구나…이 위기를 어떻게 극복하셨나요?답이 잘 보이지 않았어요. 그래서 피벗 (Pivot)을 해야겠다고 생각했죠. 다른 기업을 위해 컨설팅 하는 것은 그만하고, 우리 사업을 하자고 말이에요.7년 차에 피벗이요? 절대 쉽지 않은 결정이었을 것 같은데…정말이지 여간 어려운 일이 아니었어요. 낮에는 기존 사업의 프로젝트를 진행하며 돈을 벌고, 밤에는 신규 사업을 계획했어요. 하지만 신규 사업이라는 것이 밤에 짬을 내어 고민하고 준비한다고 쉽게 만들어지는 것이 아니잖아요. 결국 어느 날 기존 사업의 프로젝트 수주를 중단했어요. 회사 자금도 거의 바닥난 상태에서 말이죠. 당시 대표이사였던 현진석 대표님이 급여 만드느라고 백방으로 뛰어다니며 고생해주신 덕분에 저희는 신규 사업을 만들어가는데 집중할 수 있었어요.엄청난 결단이었네요. 그렇게 해서 신규 사업은 무사히 시작할 수 있었나요?결국 시작한 사업이 마이원카드라고, 지갑에 다수의 포인트카드를 가지고 다니지 않아도 손쉽게 포인트를 적립해 주는 서비스였어요. 지금의 시럽과 유사한. 그리고 너무나 감사하게도 수십억 원의 투자 유치를 받아 회사가 기사회생할 수 있었죠. 투자 유치 직전 통장 잔고가 200만원 정도였던 것으로 기억해요.드라마가 따로 없네요. 그래도 덕분에 새로운 도전의 장을 열 수 있었겠어요.그랬죠. 투자 유치 과정에서 대주주가 외부 주주로 바뀌었고, 어떻게 하다 보니 창업 멤버 막내였던 제가 대표이사가 되어 있었어요. 이 때 처음으로 ‘대표’라는 자리의 막중함을 깨달았던 것 같아요. 지분 3~4%의 대표이사였고, 중간 중간 좋은 이직 제안들도 있었지만 흔들리지 않고 더욱 열심히 할 수 밖에 없었죠. 제게는 젊음을 바친 사업이었고, 제 분신과도 같다고 생각했거든요.  2년 간의 적자가 이어지고 투자금을 거의 소진해갈 무렵, 마침내 흑자 전환에 성공할 수 있었어요.거의 10년 가까이 첫 사업을 하시면서 우여곡절이 많으셨을 텐데, 가장 크게 느낀 점이 있다면?하나를 꼽긴 어렵지만, 그래도 가장 크게 고생하고 깨달은 것이 있다면 바로 ‘사람’.이룬 것이 많지 않은 작은 회사가 직원을 뽑는 것이 쉬운 일이 아니었어요. 지금도 많은 중소 기업 대표님들께서 갖고 계신 고민이겠지만, 마치 제가 인터뷰를 하는 것이 아니라 인터뷰를 당하는 느낌이랄까? 그렇게 하나 하나 공들여 채용한 직원들이 어느 날 불쑥 찾아와 “우리 회사는 비전이 뭐에요?”라고 따지면서 묻거나, 회식 자리에서 불만을 토로하며 하소연할 때, 대표이사로서 대답이 참 궁색해서 정말 많이 미안했죠. 하지만 더 힘들었던 것은 정들었던 직원들이 하나 둘 대기업이나 다른 회사로 떠나가는 일이었어요. 축하할 일이었지만 한 편으로는 상처도 많이 받았던 것 같아요. 그리고 서운함 보다는 그 친구들을 붙잡을 수 없는 회사라는 자괴감이 더 컸어요. 결혼하고 가정이 생긴 친구들에게 월급도 많이 올려주지 못했고, 복리후생도 변변치 못했으니까요.이 때 배운 정말로 소중한 것은, 창업자는 멋진 비전을 제시할 수 있어야 한다는 것. 그리고 그 비전이 비전으로만 끝나서는 절대 안되고, 무조건 사업을 성공시켜야 한다는 것이었어요. 그렇게 해야 함께 해준 소중한 직원들에게 나누어 줄 것이 생기니까요. 시장 환경, 경쟁 환경을 탓할 수 있을 만큼 창업자의 책임은 가볍지 않더라고요.어수룩했던 창업의 준비기부터 치열했던 10년간의 첫 창업 속 좌절과 성공까지, 이상혁 대표의 이야기를 들으면서 저 Y 또한 많은 것을 생각하게 되었습니다. 계속해서 흥미진진한 이야기를 이어나가고 싶지만, 분량 조절을 위하여 이 이후 이어진 첫 사업의 매각, 인수 회사에서의 새로운 도전, 그리고 옐로모바일의 창업에 대한 이야기는 다음 편에서 전해드리도록 하겠습니다. 짧지 않은 첫 이야기, 재미있게 읽히셨기를 바라며, 저는 다음 이야기로 찾아 뵙겠습니다. Y였습니다.
조회수 706

미국 소비자들을 아마존이라는 늪에 빠뜨리다.

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다. 이번 글은 입문 단계의 마지막이자 아마존 핵심 중의 핵심인 Prime & FBA 제도를 소개하고자 합니다. 중요한 내용이라 바로 본론으로 들어가도록 하겠습니다. 1부를 읽지 않으신 분들은 앞글을 읽고 오시길 추천드립니다. (링크 클릭 - 아마존의 4가지 덫 1부)3. Prime아마존 프라임 회원이 되면 다음의 혜택을 누릴 수 있습니다. 무료배송, 영화, 음악, 무제한 도서 제공 등을 말이죠. 혜택이 상당히 많아서, 자세한 내용은 아래 링크를 참고해주시길 바랍니다. (https://www.amazon.com/gp/help/customer/display.html?nodeId=200444160) 아마존이 자선사업을 하는 것이 아니기 때문에 연 회비를 받습니다. 과거 99달러에 위와 같은 혜택을 제공받았다가 2018년 5월 기준, 119달러로 인상되었습니다. 프라임 제도의 핵심은 바로 Lock-in 효과입니다. 미국 서부에서 동부로의 항공 운송 소요 기간이 6시간 정도라고 했을 때, 육로 배송으로 미국 전역을 이틀 내, 심지어 특정 상품과 지역의 경우 당일 배송을 한다는 것은 혁신 그 자체라고 할 수 있습니다. 그리고 그 혁신은 제프 베조스의 경영철학과 맞닿아 있습니다. ‘Customer Obsession’. 충성도 높은 아마존 프라임 회원의 수는 무려 1억 명이 넘습니다. Prime 제도에서 또 하나 주목해야 하는 것은 ‘Prime Day’입니다. 2017년 7월 15일에 열렸던 아마존 프라임 데이의 세일즈는 2016년 블랙프라이데이의 세일즈 규모를 능가했습니다. 엄청난 규모의 세일즈 규모도 놀랍지만, 2017년을 기준으로 아마존 프라임 데이가 중국과 인도, 멕시코까지 확대되었다는 점에서 프라임 멤버를 제대로 타겟팅하지 못하는 셀러들은 점점 더 아마존에서 도태될 가능성이 높아졌다고 말할 수 있겠습니다. (기존에는 미국, 영국, 스페인, 일본, 이탈리아, 독일, 프랑스, 캐나다, 벨기에, 오스트리아만 해당) 참고로, Prime이 없는 사람도 25불(과거, 49불) 이상 구매하면, 아마존에서 무료배송 서비스를 제공합니다. 단, 소요되는 기간이 2일 이내에서 약 10일 이내로 길어집니다. 4. FBAFBA는 Fulfillment By Amazon의 약자입니다. 보통의 경우, FBA를 단순히 아마존 창고를 통해 물류 서비스를 맡기는 것이라고 생각하실 수 있습니다. 실제로 아마존은 3개의 분산 입고 위치를 자체적으로 지정하여 빠른 배송을 가능하도록 노력하는 중입니다. 그런데 만약, 셀러가 파는 상품이 캘리포니아와 같은 서부에서만 팔린다면? 그땐, Premium placement 기능을 설정하여, 한 창고로 지정이 가능합니다. 하지만, FBA는 물류 이상의 가치가 있습니다. 바로 아마존이 CS 업무도 처리해준다는 것입니다. “Amazon also handles all customer service and product returns for "Fulfilled by Amazon" items.”미국, 특히 아마존의 경우 굉장히 소비자 친화적인 플랫폼이기 때문에 반품에 관대합니다. 따라서, 상품에 대한 문의나 클레임을 일일이 담당하는 일은 상당히 번거로울 수 있습니다. 법인이시라면, 해당 업무를 담당하는 직원을 추가 고용해야 할 수도 있습니다. 개인사업자라면 그 부담이 더 크다고 할 수 있겠죠. 따라서, 아마존의 FBA를 서비스를 애초에 이용하시는 것이 업무 진행에 있어서도 수월할 것입니다. 그뿐만 아니라, FBA를 이용하면 Prime Day의 혜택을 받는 상품으로 등록될 수가 있습니다. (To make the most of Prime Day, sign up for programs that make your products Prime eligible, such as Fulfillment by Amazon and Seller Fulfilled Prime) 그렇다면 여기서 질문, 이렇게 좋은 FBA를 안 하는 사람도 존재하는가? 네 맞습니다. 아마존이 자선사업가가 아니기 때문에, FBA 서비스 수수료를 청구하기 때문입니다. 그래서 FBM 방식으로 셀러가 자체 배송하는 경우도 있는 것입니다. 하지만, 한국에서 사업을 하거나, 해외에서 미국으로 물품을 보내시는 분들이라면? FBA는 선택이 아니라 필수라는 게 컨택틱의 생각입니다.   하지만, 셀러들이 판매하시는 상품, 상품이 속한 산업 군, 상품을 소비하는 고객의 트렌드와 성향, 시시각각 변화하는 아마존 정책이라는 변수들에 일일이 대응할 수 없기 때문에 컨택틱에서는 아마존 입문, 기초, 심화 과정 교육을 진행하고 있습니다. 컨택틱의 모든 교육은 파트너인 글로벌셀러 창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러 창업연구소의 홈페이지를 통해 접수 가능합니다. 오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정  그럼 오늘도 즐거운 글로벌 셀링 되세요!   감사합니다. 컨택틱서울특별시 강남구 강남대로 62길 11, 8층 (역삼동, 유타워)    대표 전화: 02-538-3939    이메일: [email protected]    홈페이지: https://www.kontactic.com  네이버블로그: https://blog.naver.com/kontactic   카카오브런치: https://brunch.co.kr/@allaboutamazon
조회수 1100

와이즈트래커 홈페이지 리뉴얼

와이즈트래커 홈페이지 리뉴얼 소식! 와이즈트래커 홈페이지가 새롭게 개편되었습니다. 그동한 내부에서는 어떻게 홈페이지에서 와이즈트래커 서비스를 쉽고 정확하게 전달할 수 있을지 고민이 많았는데요. 깊은 고민의 결과, 업데이트된 홈페이지에서는 와이즈트래커의 기능과 장점을 보다 효과적으로 파악할 수 있습니다.1. 메인페이지를 슬라이드로 구성해 와이즈트래커의 기능과 각 기능별 상세페이지로의 이동이 용이해졌습니다. 2. Feature 페이지를 Mobile Attribution (모바일 광고 성과 분석)과 Behavioral Analytics (사용자 행동 분석)으로 나누어 각 항목별 세부 기능 내용을 추가했습니다.   3. 사용자들이 서비스에 대한 궁금증을 빠르게 해결할 수 있도록 Pricing Guide 와 Support 페이지에 FAQ 항목을 추가했습니다.  평소 모바일 앱 분석 툴이 궁금하셨던 분들은 와이즈트래커 홈페이지를 통해 필요한 정보를 확인해보세요! 문의사항이나 개편된 홈페이지에 대한 피드백이 있다면 언제든 [email protected] 로 말씀 부탁드립니다. 와이즈트래커는 앞으로도 더 좋은 서비스로 발전할 수 있도록 노력하겠습니다.* WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #디자인 #기획 #개발 #홈페이지 #리뉴얼 
조회수 984

디지털 노마드를 꿈꾸며

들어가며웹 서비스를 운영하는 여느 회사들처럼 엘리스의 엔지니어링 팀도 ‘프론트엔드’ 팀과 ‘백엔드’ 팀으로 이루어져 있습니다.‘프론트엔드’는 앞쪽에서 유저와 직접 맞닿아 있는 부분을 말합니다. 엘리스와 같은 웹 서비스에서는 웹 브라우저에서 유저들에게 보이는 웹페이지를 HTML/CSS/Javascript를 이용해 만드는 사람들이 프론트엔드 엔지니어라고 할 수 있습니다.‘백엔드’는 유저의 눈에 보이지 않는 뒷부분을 말합니다. 백엔드는 프론트엔드에서 보내는 요청을 처리하고 데이터를 보내주는 역할을 하는데요, 엘리스는 현재 프론트엔드 엔지니어 3명과 백엔드 엔지니어 2명이 서비스 개발을 담당하고 있습니다.한 가지 놀라운 점은, 엘리스의 엔지니어링 팀을 비롯해 디자인 팀, 운영팀 등이 모두 한 곳에 모여있지 않다는 것입니다. 국내에서는 이러한 형태의 원격 근무를 도입한 회사를 찾아보기 어렵지만, 기술의 발전으로 변화한 환경에서 ‘디지털 노마드’를 하나의 생활 양식으로 도입하고자 하는 목소리는 증가하고 있습니다. 디지털 노마드는 쉽게 말하면 어디든 자신이 일하고 싶은 곳에서 원격으로 근무하는 사람을 뜻합니다. 엘리스는 회사 구성원 전체가 원격 근무가 가능한 디지털 노마드 회사를 꿈꾸고 있습니다.엘리스의 모든 개발 과정은 디지털 노마드의 꿈에 걸맞게 원격으로 이루어집니다. 물론 원격으로 함께 일하기 위해서는 효과적인 툴의 도움이 필요할텐데요, 디지털 노마드를 실현하기 위해 엘리스에서는 어떤 도구들을 사용하고 있을까요? 이 글에서는 프론트엔드 팀의 관점에서, 엘리스 웹사이트에 기능이 추가되는 과정과 사용되는 협업툴을 2017년 초에 개발된 ‘헬프센터’를 예로 들어 이야기해보겠습니다.엘리스의 프론트엔드 개발 싸이클엘리스에서 기능이 개발되는 대략적인 흐름은 다음과 같습니다.기획 - 디자인 - 구현 - 테스트 - 배포 & 모니터링여기서 각 단계는 엄밀히 나눠져있거나, 무조건 한 방향으로 흐르지는 않습니다. 구현을 하다가도 기획을 수정해야 하면 다시 처음으로 돌아가기도 합니다. 각 단계를 좀 더 자세히 살펴보도록 하죠.기획 단계어떤 기능이 왜 필요한지, 필요하다면 일의 중요도와 걸리는 시간은 어떤지 등을 엘리스의 연간 로드맵과 비전에 맞춰 논의하고 계획하는 단계입니다. 거의 모든 논의는 Slack이라는 온라인 협업 툴의 화상채팅에서 이루어집니다. 엘리스에는 ‘기획자’라는 역할이 명확하게 주어진 사람은 없습니다. 기본적으로 팀 리더가 의견을 취합하고 방향성을 제시하지만, 엔지니어링팀, 운영팀, 디자인팀 모두가 의견을 자유롭게 제안할 수 있습니다.2017년은 엘리스가 처음으로 대학교, 기업 등 기관 고객이 아닌 일반 사용자에게 수업을 제공하기 시작한 해입니다. 우리는 프로그래밍 학습을 하는 데 있어서 아주 중요한 요소 중 하나가 실습을 빠르게 많이 해보고 막혔을 때는 선생님에게 도움을 받을 수 있게 하는 것이라고 생각했습니다. 특히 프로그래밍을 한 번도 접해보지 않은 분들이 엘리스에서 처음으로 코딩학습을 시작하는 경우가 많았기 때문에, 이러한 사람들에게 효과적으로 도움을 줄 수 있는 기능이 무엇일지에 대한 많은 논의를 나눴습니다. 논의의 결과 개발하기로 결정한 것이 헬프센터입니다.Google Presentation으로 만들어진 초기 헬프센터의 컨셉 디자인 일부거시적 관점에서의 논의가 어느 정도 정리된 후에는 위 그림과 같이 구글 프리젠테이션으로 빠르게 만든 저수준(Low Fidelity) 디자인이 유용하게 쓰입니다. 이러한 저수준 디자인을 통해 개별 페이지의 상세한 디자인에 착수하기 전에 사용자 인터페이스와 경험(UI/UX)을 미리 설계해서 피드백을 주고받을 수 있습니다.기획 단계에서는 기능 요구사항이 현재 서비스 구조와 잘 어울리는지, 무엇이 가능하고 무엇이 하기 어려운지 등을 미리 잘 정해두어야 합니다. 그래야 개발 도중에 뒤엎는 일이 적기 때문입니다. 프론트엔드 엔지니어는 기획 단계의 요구사항을 잘 파악한 뒤에, 새로 기능을 개발하는 데 있어서의 제약사항이나 기존 구조에 대한 변경사항 등의 디테일을 백엔드 엔지니어와 함께 논의하면서 자세하게 정의해 나갑니다. 따라서 다른 팀의 사람들과 소통하는 능력은 프론트엔드 엔지니어에게 특히 중요한 역량이라고 할 수 있습니다.기획 단계에서 주고받은 논의 결과는 엘리스의 위키 페이지에 정리되고, 이슈 관리 도구인 Jira에 등록됩니다. 엘리스의 모든 팀원들은 위키 페이지와 Jira를 통해서 논의된 결과를 확인하고 일의 진행 상황을 파악하게 됩니다.주 사용 도구: Slack, Google Presentation, Confluence Wiki, Jira디자인 단계기능 개발에 필요한 각 페이지의 디자인이 고수준(High Fidelity)으로 만들어지는 단계입니다. 자세한 디자인에 들어가보고 나서야 파악되는 문제도 있기 때문에 디자인 단계에서도 기획에 대한 논의와 수정은 계속됩니다.디자인 단계에서의 논의 역시 Slack 채널에서 이루어집니다. 프론트엔드 팀과 디자인 팀은 온라인에서 디자인 페이지를 함께 보며 디자인에 대한 논의를 진행합니다.엘리스 디자인 팀에서는 주로 Sketch로 페이지 디자인을 합니다. Sketch로 디자인이 되고 나면 페이지 단위로 Invision에 업로드되는데, Invision에서는 다른 페이지로 넘어가는 링크뿐만 아니라 페이지 안에서의 인터랙션(스크롤 내리기, 클릭하기 등.)도 어느 정도 표현할 수 있습니다. 또한 각 요소의 색깔, 크기, 다른 요소와의 간격 등을 개발자가 볼 수 있어서 이를 토대로 페이지를 구현하게 됩니다.Invision에 업로드된 헬프센터 페이지 디자인새로운 페이지를 만들 때 중요한 것 중 하나는 기존 페이지에서 사용자가 경험했던 것을 비슷하게(Consistent) 유지하는 것입니다. 이는 사용자 경험 측면에서도 좋고, 엔지니어 입장에서도 비슷하지만 조금 다른 코드를 자꾸 만들 필요가 없어서 좋습니다. 엘리스 프론트엔드 팀에서는 일관성 있는 디자인을 돕기 위해 비슷한 상황에서 쓰이는 요소들을 모듈화하여 가져다 쓸 수 있는 elice-blocks라는 것을 만들었습니다.elice-blocks의 버튼에 대한 스타일 가이드실제 elice-blocks의 다양한 종류 button들이 구현된 예시요즘은 디자인 팀에서 elice-blocks를 최대한 활용하여 페이지 디자인을 하기 때문에 전보다 코드 품질도 올라가고 개발 속도도 더 빨라졌습니다.새로운 페이지에 대한 디자인이 나오면 프론트엔드 팀과 디자인 팀은 Slack에서 스크린 공유를 통해 Invision 페이지를 함께 보며 elice-blocks가 어떻게 사용되었고 어떻게 업데이트되어야 하는지도 논의합니다.주 사용 도구: Slack, Sketch, Invision구현 단계Jira에 기술된 기능 요구사항과 Invision 페이지를 보며 실제 코딩을 하는 단계입니다. 기획과 디자인 단계에서 충분한 논의가 되었다면 구현 단계에서 걸리는 시간이 많지 않을 수도 있습니다.현재 엘리스 아카데미에서 사용되고 있는 헬프센터의 모습현재 프론트엔드 팀은 3명뿐이라서 보통은 한 사람이 기능 하나씩을 맡아서 개발합니다. 이렇게 할 경우 개발 속도는 좀 빨라질 수 있으나 코드의 품질과 안정성이 떨어질 수 있다는 단점이 있습니다. 이를 보완하기 위해 각자가 할 일을 하면서도 짧은 시간 페어 프로그래밍을 하기도 하고, 완료된 기능에 대해서는 코드 리뷰를 진행합니다.페어 프로그래밍 역시 원격 상황에서 이루어집니다. 하지만 원격으로 안정적인 진행이 쉽지는 않았는데요, 여러 가지를 시도해본 결과 가장 안정적인 것은 Slack으로 화상채팅을 하면서 TeamViwer로 호스트의 컴퓨터를 함께 컨트롤하는 것이었습니다. 3명의 팀원 모두가 함께 진행한 적도 있었는데 무척 재미있더군요.코드 리뷰는 방대한 기능을 개발했을 경우에 팀 차원에서의 리뷰를 위한 화상 회의를 통해 진행됩니다. 또는 해당 기능을 이용하는 개발을 페어로 하기도 합니다. 기본적으로는 엘리스에서 소스코드 관리 도구로 사용하는 Gitlab 안에서 코드 리뷰가 이루어집니다.코드 리뷰 이외에 코드 품질을 높이는 비교적 쉬운 방법 중 하나는 팀의 코딩 스타일 가이드를 잘 정하고 이를 따르는 것입니다. 프론트엔드 팀은 Airbnb의 Javascript 스타일 가이드를 입맛에 맞게 수정해서 사용해왔습니다. 지금은 이를 좀 더 엄밀하게 적용할 필요성을 느껴 Javascript에 대해서는 eslint를, CSS에 대해서는 scss-lint를 이용하여 스타일을 맞추고 있습니다. 이 중 eslint는 후술할 테스트 단계에서도 사용됩니다.참고로 엘리스 프론트엔드는 React 로 구현되어 있는데 페이스북에서 React를 내놓은 아주 초반부터 React를 사용해왔습니다. 그래서 React의 최신 기술이 아닌 오래된 레거시 코드라고 할 만한 부분이 꽤 많습니다. 신규 기능 개발과 더불어 이전 코드를 리팩토링하고 자잘한 버그를 수정하는 것 또한 프론트엔드 엔지니어가 할 일입니다.주 사용 도구: Jira, Invision, Slack, TeamViwer, Gitlab, eslint, scss-lint테스트 단계구현된 기능이 실제로 사용자에게 전달되기 전에 다양한 테스트를 거치는 단계입니다. 가장 기본적인 테스트는 엔지니어가 직접 개발하면서 여러가지 경우의 수에서 의도한 대로 작동하는지 확인하는 것입니다. 여기에 자동화 테스트와 사람이 직접 하는 테스트가 추가됩니다. 엘리스에서 수행하는 자동화 테스트의 종류는 다음과 같습니다.빌드 테스트: 코드가 에러 없이 잘 빌드되는지 확인스타일 테스트: 코드가 엘리스 프론트엔드 팀의 스타일 가이드와 잘 맞는지 확인 (eslint)유닛 테스트: 개별 기능이 잘 동작하는지 확인통합 테스트: 기능의 추가가 전체 시스템에 영향을 미치지는 않았는지 전체 시스템의 동작을 확인자동화 테스트는 Gitlab의 지속적 통합(CI, Continuous Integration) 도구에 연결해두었기 때문에 Gitlab에서 새로운 커밋이 올라오면 자동으로 해당 테스트들이 통과하는지 확인합니다. 즉 코드 리뷰를 시작하기 전에 이미 자동화 테스트는 수행된 것이라고 볼 수 있습니다. 다만 아직까지 엘리스의 코드 규모에 비해 자동화 테스트가 커버하지 못하는 부분이 많기 때문에 이것을 차차 추가해나가고 있습니다.Gitlab의 CI 파이프라인이와 같이 구현과 자동화 테스트는 단계를 나누기 모호할 정도로 긴밀하게 연결되어있지만 굳이 단계를 나눈 이유는 사람이 직접 하는 테스트 때문입니다.자동화 테스트와 리뷰가 끝난 기능은 엘리스의 베타 서버에 올리고, 이를 Slack 채널을 통해 엘리스 팀원들에게 알립니다. 그러면 기획 단계에 참여한 사람들은 베타 서버에서 구현된 기능의 실제 동작을 확인하고 최초의 요구사항을 만족하는지 확인합니다. 확인한 사항에 대한 피드백은 Slack 채널에서 이루어지고 이때 미비한 점이나 버그가 발견되었다고 하면 다시 구현 단계로 돌아가게 됩니다. 요구사항이 잘 만족되었다면 이를 해당 기능에 대한 Jira 이슈에 표시하고 그 기능은 배포가 가능한 상태가 됩니다.주 사용 도구: Slack, Gitlab, Jira배포 및 모니터링 단계구현된 기능이 포함된 버전을 실제 프로덕션 서버에 올리고 확인하지 못한 버그가 발생하지 않는지 모니터링하는 단계입니다. 엘리스는 일주일에 한 번 배포를 기본 원칙으로 하는데, 개발된 것을 목요일까지 베타 서버에 올리고 테스트를 거쳐 목요일 밤이나 금요일에 배포합니다.2017년 11월 3주차의 두 번째 배포. 모든 이슈가 Resolved 상태다.모니터링을 위해 엘리스에서 사용하고 있는 Sentry는 Google Analytics(GA)와 같은 사용자 로그 수집 도구인데, GA와 다른 점은 에러 로그에 특화되어있다는 것입니다. 사용자가 경험한 자바스크립트 에러는 사용자가 어떤 과정을 거쳐 그 에러를 경험하게 되었는지와 함께 기록되고 리포트됩니다. Sentry로 기록되는 에러를 포함하여 다른 모든 종류의 로그는 자체 개발한 elice-logger를 통해 기록되고 있습니다.또한 엘리스에서는 Intercom이라는 사용자 소통 도구를 통해 피드백을 수집합니다. 로그인한 사용자라면 누구든지 ‘문의하기’로 엘리스 운영팀에게 메시지를 보낼 수 있습니다. Intercom에서 들어온 메시지는 Slack을 통해 엘리스 팀 전체에게 공유되고, Sentry에서 들어온 메시지 또한 그렇습니다.Slack으로 사용자 문의가 들어오면 이를 확인한 후에 고쳐야 할 버그라면 수정 작업에 들어갑니다. 버그 수정은 기획-디자인 단계가 문제 제기 단계로 바뀌는 것을 제외하면 기존의 기능 개발 싸이클과 동일합니다.소프트웨어 환경 A에서 권한 B를 가진 계정으로 행동 C를 할 때 원래 예상되는 결과는 D1이지만 현재는 D2가 일어난다라는 포맷으로 문제가 제기되면 이를 개발자가 확인한 후에 문제의 심각성을 파악하여 마찬가지로 구현, 테스트, 배포 및 모니터링을 단계를 진행합니다.주 사용 도구: Jira, Sentry, Intercom, Slack마치며이번 글에서는 디지털 노마드를 꿈꾸는 회사로서 엘리스가 어떤 도구들을 이용하여 기능을 추가하고 버그를 수정하는지를 이야기했습니다. 저는 엘리스가 언젠가 겨울에는 호주에서, 여름에는 캐나다에서 개발할 수 있는 회사가 되기를 소망하고 있습니다. 원격근무가 활성화된 것으로 유명한 회사들이 외국에는 많은데(Gitlab, Basecamp 등) 한국에서는 어떤 회사들이 어떤 도구를 이용하여 디지털 노마드를 실현하고 있는지 궁금하군요.photograph by Marco Verch위와 같은 개발 과정을 잘 해나가기 위해 엘리스의 프론트엔드 엔지니어들에게 필요한 역량은 이런 것들입니다.거시적 관점에서 회사의 비전/로드맵과 현재 하는 일이 잘 맞는지 판단하기기획자 역할을 하는 사람의 의도를 파악하고 이를 토대로 백엔드 엔지니어와 소통하여 개발 스펙 산출하기엘리스 프론트엔드의 스타일 가이드와 React의 좋은 패턴을 이용하여 고품질의 코드로 기능 구현하기각자의 일하는 방식을 존중하고, 함께 하는 세션에 적극적으로 참여하기자신이 구현한 기능을 책임지고 테스트와 유지보수하기여러가지 도구를 익숙하게 사용하며, 새로운 도구를 두려워하지 않고 빠르게 학습하기elice-blocks와 같이 작지만 유용한 내부 프로젝트들을 구현하기사용자의 메시지에 귀를 기울이지만, 그것을 있는 그대로 받아들이기보다 진짜 문제를 찾아서 해결하기물론 현재 저를 포함한 엘리스 팀원들 역시 이 모든 것을 유지하고 더 잘하기 위해 열심히 노력하는 중입니다. 본인에게 이러한 역량이 있거나, 그런 주변 사람을 알거나, 함께 디지털 노마드 회사를 만들고 싶거나, 또는 이 글을 읽고 엘리스의 프론트엔드 팀에 관심이 생기셨다면 주저없이, 연락주시기 바랍니다. 읽어주셔서 감사합니다.#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개 #채용 #프론트엔드 #개발자 #리모트 #재택근무
조회수 3213

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

목차미국 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 #인턴 #인턴후기 #인턴생활 #기업문화 #디자인 #디자인팀 #디자이너

기업문화 엿볼 때, 더팀스

로그인

/