우리는 '융합'에 주목합니다.이것과 저것, 기존에 있던 것과 없던 것 등등을 융합해 더 큰 가치 만들기를 좋아합니다.  현재 우리가 진행하는 비즈니스는 ‘커머스’와 ‘콘텐츠’의 융합입니다.‘디지털’이라는 키워드만으로는 설명이 부족할 만큼 고도화된 사회를 살아가고 있습니다.여기서 얻은 비즈니스적 단서는, “모바일로 영상을 쉽게, 완벽하게 보는 시대가 도래했다”는 것입니다.영상을 쉽게 볼 수 있는 플랫폼이 늘어났고, 덩달아 다양한 제작자들이 모습을 드러내는  그러한 영상 콘텐츠의 부흥기가 왔습니다.이에 우리는 “모두가 아끼고 즐기고 모이는 채널에 우리의 콘텐츠를 싣자”그리고 “우리의 콘텐츠로 참신하고 이로운 경험을 선사하자”고 마음 먹었습니다.참신하고 이로운 경험이 무엇일까? 고민했고,사람과 라이프스타일을 연구하면서 한 가지 사실을 얻었습니다."사람은 삶을 살아가면서 계속해서 문제를 만들어내고, 또 계속 해결해 나간다”는 것이었습니다.여기서의 ‘문제’는 ‘빈 곳(blank, 맹점)’입니다.일상에서 쉽게 지나치거나 너무나 당연해서 인지하지 못하는 부분들이죠."우리는 그러한 빈 곳을 채워주자"이에, 솔루션을 제공하자는 모토를 창출하게 됐습니다. Lifestyle needs solution 우리는 우리의 옷을 깨끗하게 빨아주는 세탁기, 그 자체는 깨끗할지 궁금했습니다.분석에 들어갔고, 과연 세탁조의 오염도와 위생상태는 심각했습니다.우리는 세탁기의 통(세탁조)을 간편하게 씻어내는 ‘세탁조크리너’를 세상에 공개했습니다.노후화된 수도관에서 발생하는 수질 오염물질은 ‘샤워기 필터’로 걸렀습니다.야식을 마음 편히 즐기는 동시에 소소한 식습관을 익힐 수 있게끔 ‘곤약 간편식’도 만들었습니다.이렇게 삶의 빈 곳을 메우는 기특한 브랜드가 20개, 제품 가짓수는 약 200여 개에 달합니다.아직 탐구하지 못한 영역이 많은 만큼, 브랜드와 제품, 솔루션은 계속 늘어날 전망입니다.또, 좋은 솔루션은 더 넓은 세상으로 들고 나갈 생각도 하고 있습니다.솔루션을 제공하는 상품을 기획하고, 이를 콘텐츠와 융합하기 위해우리는 정말 빡세게 ‘사고(Thinking)’ 합니다. 상품기획부터 콘텐츠제작, 촬영, 마케팅, 유통, 생산, 물류, 혁신, 수학, 과학, 철학까지,논리적으로 사고하기 위해 온 힘을 다합니다. 치열하게 싸웁니다.우리는 가설검증을 사랑합니다.적당한 것을 취하고 유지하지 않습니다. 효율을 높이기 위한 방법을 계속 고민합니다.한 번도 가지 않았던 길을 찾아보고 실험하고 끝내 성취감을 맛봅니다.  블랭크코퍼레이션 전체회의, 매주 월요일 오후 5시(프로 전원 참석)더 치열하게 빡세게 사고하라고, 밥, 집, 임신, 출산, 육아 등 모든 '걱정거리'는 블랭크가 해결합니다.더 속도 높여 사고하고 결정할 수 있도록 사내에서 모두 ‘세그웨이’를 타고 날아다닙니다.간식 사러 나가는 시간이 아까우니, 그냥 '편의점'도 회사 한 켠에 사 놓았습니다.주어진 시간에만 빡세게 일하라고 ‘정시퇴근’을 철저한 원칙으로 합니다시간을 쪼개어, 업무에 더 유용하게 사용하라고 ‘반반차’ 휴가도 제공합니다.심지어 종잣돈 걱정, 리프레시, 여행 걱정까지 블랭크가 책임집니다.진짜 마음 놓고 일에 몰입하도록 말입니다.현재의 사업인 제1단계 ‘콘텐츠+커머스’의 융합을 함께 경험하며 가시적인 성과를 내고 싶은 분.논리 있고 빠른 사고와 화끈한 결정으로, 자유의 고통을 느끼고 싶은 분.그리고 제2단계, 제3단계를 함께 찾아, 뚫고, 오르고 싶은 분.블랭크는 언제나 환영합니다. 블랭크코퍼레이션 마켓블랭크코퍼레이션 마켓

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요 버즈빌에서 나이(사내 2번째 고령자)를 담당하고 있는 Sales Manager Michael(염기찬)입니다. 운동을 굉장히 좋아하고요. 현재 사내에서 축구, 탁구, 농구를 하고 있습니다. 농구는 다른 회사에서도 종종 게스트로 초청돼 영업의 한 채널로 유용하게 쓰고 있네요. ^^ 원래는 제휴영업이 주 전공이었지만 광고영업도 별반 다를 것이 없다는 크나큰 착오로 인하여 초반에 큰 어려움을 겪었으나 어찌어찌 이겨내며 조금씩 영역을 확장하고 있네요. 컨펌이 돼도, 리젝이 돼도 빨리빨리 다음을 찾아야 하는 Sales팀의 최고령자입니다.  2. 어떻게 버즈빌에 오시게 되셨나요? 조그맣게 사업을 하다가 잘 안 되던 중 친한 후배가 연락처 하나를 건네며 거기에다 이력서를 한 통 넣으라고 하더군요. 이름을 보니까 제가 예전부터 알고 지내던 버즈빌의 최고령자 Steve이었습니다. 연락을 드리고 간단하게 티타임을 가지며 당당히 Business Development Team으로 면접을 보았으나 Sales팀으로 입사를 하게 됐습니다.  그 후배 덕에 버즈빌리언이 된지 어느덧 2년이 다 되었네요. 수평적이고 젊은 조직에 적응을 잘 할 수 있을까에 대한 주위 분들의 걱정이 많았지만 정신연령 자체가 낮다(?) 보니 아주 잘 적응하며 즐겁게 지내고 있습니다. 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 전 Sales Team에서 외부 영업을 담당하고 있고요. 저의 전문 분야는 금융과 프랜차이즈입니다. 프랜차이즈에서 오랫동안 경험을 쌓고 업계를 잘 이해하고 있다 보니 회사에서도 잘 밀어주고 있습니다.  주위의 매체사들, 대행사들을 포함한 업계 분들을 만나면 버즈빌의 연락을 이미 받은 경험이 있는 분이 많습니다. “여기도 버즈빌 왔다 갔어요?” , “여긴 안 왔겠지 했는데 역시나 왔다 갔군요..” 이와 같은 맥락의 말을 자주 하게됩니다. 그만큼 버즈빌 Sales Team의 전투력을 엿볼 수 있죠? ^^ 사실 전투력도 전투력이지만 버즈스크린의 특장점, 어필 포인트가 분명히 있는데 이 내용이 광고주에게까지 효과적으로 전달되는 경우가 많지 않아서 매출을 만들기 위해서는 직접 얼굴을 보고 자세하게 버즈스크린의 장점을 설명 해야 합니다. 그래서 저는 오늘도 열심히 발로 뛰고 있습니다.  4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 저는 제휴마케팅을 주로 하던 사람이었는데요. 같은 영업이라 크게 문제가 되지 않을 것이라 생각하고 광고업계로 들어왔는데 정말 큰 차이가 있더군요. 제휴는 나름 시간을 길게 가지고 양사 간의 이익 점을 서로 조율해나가는 부분이 있습니다. 반면, 광고영업은 짧은 시간에 모든 게 결정되기 때문에 항상 다음을 빠르게 만들어야 하는 부분이 있더라고요. 또한, 광고주의 분야마다 전략을 명확하게 수립하는 건 당연하고 순간순간마다 전략수정 등 임기응변이 훨씬 더 많이 필요하다는 걸 느꼈습니다. 그래서 피곤하기도 하고 약간 지칠 때고 있지만, 내가 살아있음을 느끼고 있어서 광고 쪽으로 온 것을 후회하지 않습니다.  5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? #문화가 좋은 기업 버즈빌은 어떤 회사냐면요.   자유, 책임과 주인의식이 공존하는 회사 주입이 아닌 스스로 느끼고 알아서 일 하는 회사  전 이게 책에서 혹은 바른 기업상 등에서 나오는 얘기라고만 느꼈었는데 버즈빌이 그런 회사라는 것에 대해 약간의 으쓱함이 생기네요. 회사에서 주는 문화적 혜택을 악용하는 사람들이 눈에 안 보이는 게(제 눈에만 그런가요? ^^) 정말 참 좋습니다! #자유로운 분위기를 형성 하는 버즈빌 이게 정말 최고의 업무적 혜택인 거 같습니다. 회사에 나오지도 않아도 각자 알아서 업무를 하는 걸 보면 스스로 안 할 수가 없는 분위기입니다. 이런 분위기가 만들어가는 게 정말 어려운데 그 어려운걸 버즈빌이 해내고 있네요.  6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 고1, 중2의 자녀를 둔 아빠 입장에서 역시 가족이 건강하고 부족함 없이 사는 것이 가장 큰 목표입니다. 그러기 위해서는 역시 열심히 일하고 있습니다. 안정적인 매출을 확보해 회사와 제가 모두 이익을 볼 수 있는 상황을 빨리 만들고자 열심히 뛰고 있습니다. 또한, 버즈빌에서의 나의 경험도 경험이지만 우리 버즈빌리언들이 현재까지 살아온 얘기들을 들으면 정말 배울 것이 많다고 느껴요. 나보다 훨씬 어린 친구들임에도 불구하고 너무나 알찬 인생을 살고 있습니다. 많은 정보를 찾고 그 정보로 내가 누릴 수 있는 혜택, 내가 가질 수 있는 경험을 마음껏 즐기고 있는 버즈빌리언의 모습이 정말 보기 좋습니다. 저도 앞으로 이러한 자세로 살고 싶고 제 아이들에게도 적극적으로 권하려고 합니다. 우리 버즈빌리언들이 100%까진 아니겠지만 그래도 크게 만족감을 느끼며 서로 오랫동안 얼굴 볼 수 있는 그런 회사를 계속 만들어 가고 싶습니다.    *버즈빌의 채용공고(전문연구요원 포함)를 확인하고 싶으면 아래 버튼을 눌러주세요!

 유난히 추웠던 겨울을 보낸 탓인지 조금씩 풀려가는 날씨와 점점 다가오는 봄이 반가운 요즘, 버즈빌에도 반가운 소식이 있습니다. 바로 5층 오피스 입주 소식입니다. 매년 계속되는 버즈빌의 성장과 더불어 늘어난 버즈빌리언들을 위해 지난 수개월간의 준비 끝에 드디어 5층 오피스를 오픈하게 되었는데요. 버즈빌리언들의 필요를 채워줄 뿐만 아니라 버즈빌의 가치를 고스란히 녹여낸 공간, 버즈빌 5층 오피스를 소개합니다.3층과 2층에 이어 세번째 오피스인 5층 오피스는 단순히 사무공간의 확장이 아닌 버즈빌리언들의 다양한 아이디어가 반영된 공간이라는 점에서 더욱 뜻 깊습니다. 대규모 인원이 들어갈 수 있는 대형 회의실부터 지친 몸과 정신을 달래줄 아늑한 수면실, 통통튀는 새로운 생각이 필요할 때를 위한 Creative Lab, 최고의 업무효율을 위한 집중의 공간인 Focus Room까지! 이런 5층 오피스를 만들기 위해 오랜기간 버즈빌리언들의 의견을 수렴하고 함께 논의 하는 시간을 가졌는데요. 그렇기에 버즈빌리언들이 정말 필요로 하는 부분을 채워줄 수 있는 공간으로 완성될 수 있었던 것 같습니다.  5층 오피스에서도 여전히 버즈빌의 문화가 살아 숨쉬는 캐치프레이즈를 찾아 볼 수 있는데요. 3층 오피스가 돈키호테에서 따온 버즈빌의 핵심가치를, 2층 오피스가 글로벌 진출의 희망을 담아 세계 각국의 도시이름을 컨셉으로 하고 있다면 5층의 컨셉은 ‘Idioms’ 입니다. 고전의 지혜를 담은 사자성어와 그 의미를 버즈빌 특유의 재치를 담아 해석한 문구들을 5층 오피스 곳곳에서 만나볼 수 있습니다.    “맹모삼천지교(孟母三遷之敎)” 라는 고사에서 알 수 있는 것처럼 주변환경은 개인에게 많은 영향을 끼치는데요. 필요를 채워 본인의 실력을 최대로 끌어낼 수 있고 버즈빌의 가치를 담아 흥미와 열정을 불러일으킨다는 점에서 버즈빌 오피스는 실력과 열정이 넘치는 버즈빌리언들에게 최고의 환경이 아닐까 합니다. 2018년, 새롭게 입주한 5층 오피스와 함께 더욱 새롭게 성장해 나갈 버즈빌의 모습을 기대해 봅니다.

녹음된 자신의 목소리를 들어본 사람이라면 알 것이다. 얼마나 어색하고 때론 거북하기까지 한지 말이다.다른 사람의 목소리는 직접 듣는 것과 녹음된 목소리 사이에 큰 차이를 느끼지 못하는 걸 보면 내가 알고 있는 나와 다른이가 인식하는 나와의 간극이 있다는 것을 미루어 짐작 할 수 있다.당연히 목소리 뿐만이 아닐 것이다.심지어 취미로 운동을 배우더라도 내가 의도하며 취하는 나의 자세와 실제 나의 모습 사이에는 꽤 큰 차이가 존재하는 걸 경험한다. 이 차이를 받아들이지 않는다면 일정 수준 이상의 실력이 늘지 않는다. 그 차이를 인식하고 간격을 조정하는 과정이 실력을 늘리는 방법이다.다시 목소리로 가보자.아니 소리가 아니라 언어로 가보자.내가 얘기하는 말들이 남들에게도 그대로 들릴까?소리가 아니라 '의미' 말이다.자신이 말하는 의도가 남들에게도 동일한 의도로 읽혀질까?언어는 우리가 사회생활을 영위하기 위한 가장 기초 도구이기도 하지만, 가장 전문적이고 강력한 무기이기도 하다.업무로 다양한 사람을 만나면서 느끼는 점은 상대방의 전문성은 특정 기술이나 행위를 통해서가 아니라 그 영역을 어떻게 표현하고 묘사하느냐의 차이에서 느껴진다는 것이다. 누구든 10분 정도 이야기해보면 상대방의 내공과 실력을 가늠할 수 있다.거꾸로 이야기하면 자신이 던지는 말 한마디 한마디가 나를 판단하는 중요한 단서라는 것이고, 자신이 전달하려는 의도와 상대방이 인식하는 내용이 일치하지 않다면 이건 매우 곤란한 상황을 야기할 수 있다. 아주 미묘한 차이이지만 그 차이가 누적될 경우에는 인생 자체가 잘 풀리지 않게 된다.주변에 이런 동료가 있었다. 사람이 워낙 좋고 업무에서도 경험도 많은 친구였는데, 직급이 올라갈 수록 조직에서 인정을 받지 못하는 것이었다. 일을 직접 같이 하지 않았던 타 부서 동료였는데, 실제로 같이 일할 기회가 생겨서 업무로  엮이게 되면서 문제가 무엇인지 알 수 있었다.아는 것은 많은데 이걸 명료하게 표현하지 못하는 것이다. 말이 길어지고 꼬리에 꼬리를 물며 부연설명이 계속 되는 것이다. 본인은 친절하게 자세히 얘기하고 있다고 느끼겠지만 듣는 사람은 도무지 무슨 이야기인지 이해가 안되는 것이다.세상 일은 항상 복잡하고 얽혀있게 마련이다. 문제를 해결한다는 것은 복잡한 현상을 명료하게 구분하고 이걸 일 단위로 나누어서 처리하는 과정이다. 말이 꼬인다는 것은 생각이 복잡하다는 것이고, 문제를 정확히 정의하지 못하기 때문에 해결책도 효과적으로 찾아내기 어렵다. 이런 리더와 함께 일하면 삽질의 연속일 가능성이 높아진다.이런 경우 특히 어려운 점은 보고의 순간이다. 요점 정리가 안되고 핵심을 집어내지 못하기 때문에 의사결정자에게 올바른 리포팅이 어렵다.더 심각한 문제는 자신의 문제를 잘 인식하지 못한다는 것이다. 자신은 최선을 다하는데, 상대방이 알아주지 못한다고 생각한다. 나는 충분히 얘기하는데 상대가 이해하지 못한다고 치부한다. 자신의 꾀꼬리같은 목소리가 상대에게 두꺼비같이 들린다는 것을 받아들이지 않는 것이다.사실 남의 얘기가 아닐 것이다.여전히 말은 어려운 영역이다.왜 국어시간이 중요한지 요즘 다시 깨닫게 된다.말은 평생 공부해야 하는 분야인 것 같다.나도 깊이 반성해 본다.

들어가며웹 서비스를 운영하는 여느 회사들처럼 엘리스의 엔지니어링 팀도 ‘프론트엔드’ 팀과 ‘백엔드’ 팀으로 이루어져 있습니다.‘프론트엔드’는 앞쪽에서 유저와 직접 맞닿아 있는 부분을 말합니다. 엘리스와 같은 웹 서비스에서는 웹 브라우저에서 유저들에게 보이는 웹페이지를 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와 같이 작지만 유용한 내부 프로젝트들을 구현하기사용자의 메시지에 귀를 기울이지만, 그것을 있는 그대로 받아들이기보다 진짜 문제를 찾아서 해결하기물론 현재 저를 포함한 엘리스 팀원들 역시 이 모든 것을 유지하고 더 잘하기 위해 열심히 노력하는 중입니다. 본인에게 이러한 역량이 있거나, 그런 주변 사람을 알거나, 함께 디지털 노마드 회사를 만들고 싶거나, 또는 이 글을 읽고 엘리스의 프론트엔드 팀에 관심이 생기셨다면 주저없이, 연락주시기 바랍니다. 읽어주셔서 감사합니다.#엘리스 #코딩교육 #교육기업 #기업문화 #조직문화 #서비스소개 #채용 #프론트엔드 #개발자 #리모트 #재택근무

ORDER BY 는 원하는 순서대로 자료를 출력하고 싶을 때 사용합니다. 편의를 위해 이전 글의 예제에서 MBR_NM 의 INDEX 인 IX_MBR_BAS_02 를 제거하고 진행하겠습니다. 이번 글에서는 이해-적용-출력-활용의 순서로 살펴볼게요. 지난 글 보기: 단일 TABLE을 SELECT하자!이해: ORDER BY의 오름차순과 내림차순SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 기본적인 ORDER BY는 위와 같이 사용합니다. 오름차순과 내림차순으로도 정렬할 수 있습니다. 오름차순일 때는 컬럼 뒤에 옵션을 넣지 않거나 ASC를 사용하고, 반대로 내림차순일 때는 DESC를 사용하면 됩니다.[오름차순]ORDER BY      MBR_NM ORDER BY      MBR_NM ASC [내림차순]ORDER BY      MBR_NM DESC 위의 Query(오름차순) 의 실행계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)내림차순 Query의 실행 계획을 보면 아래와 같이 표시됩니다.결과는 다음과 같습니다. (수행시간 3초)오름차순과 내림차순 정렬 Query를 보면 실행계획은 같고 결과는 다르게 나타납니다.실행계획을 보면 이렇게 표시됩니다.- table : TB_MBR_BAS - type : ALL - Extra : using filesort Extra의 using filesort는 DBMS에서 정렬을 한다는 의미로 퀵소트 알고리즘을 사용합니다. 실행계획의 내용을 풀어보면 “TB_MBR_BAS 을 전부(ALL) 읽은 후 정렬한다(using filesort)” 정도로 보면 됩니다.적용: INDEX와 정렬의 관계이번에는 삭제했던 MBR_NM의 INDEX인 IX_MBR_BAS_02를 다시 생성하고 수행해보겠습니다.CREATE INDEX IX_MBR_BAS_02 ON test.TB_MBR_BAS (MBR_NM); SELECT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; INDEX를 생성하고 실행계획을 보면 아래와 같이 표시됩니다.실행계획을 보면 몇 가지 달라진 게 눈에 띕니다.1. type : ALL -> index 2. key : 없음 -> IX_MBR_BAS_02 3. Extra : using filesort -> Using index 특히 Extra는 using filesort에서 Using index 로 바뀐 것을 알 수 있습니다. using filesort가 정렬을 한다는 것인데, 정렬을 하지 않고 어떻게 정렬해서 보여준다는 것일까요? INDEX를 이해하면 바로 알 수 있습니다. 일반적인 INDEX는 기본이 BTree INDEX 입니다. MySQL의 BTree INDEX는 오름차순 정렬 상태로 저장되어 있습니다. 이미 정렬한 상태로 저장되어 있는 INDEX를 사용하기 때문에 Query를 수행할 때 다시 정렬할 필요가 없죠. 그래서 using filesort가 나타나지 않는 겁니다.출력: Query 실행다음으로 성이 김 씨인 사람들의 이름을 순서대로 출력해보겠습니다. 여기서는 두 가지 Query를 이용해 비교해보겠습니다.예시 1)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE MBR_NM LIKE '김%' ORDER BY     MBR_NM  ; 예시 2)SELECT     MBR_NM FROM test.TB_MBR_BAS WHERE SUBSTR(MBR_NM,1,1) = '김' ORDER BY     MBR_NM  ; 예시를 보면 WHERE 절이 다릅니다. 예시1은 “MBR_NM이 ‘김’으로 시작하는 것을 오름차순 정렬해 보여주라는 것”이고, 예시2는 “MBR_NM의 첫 번째 글자가 ‘김’인 것을 오름차순 정렬해 보여주라는 것”입니다.이제 두 개의 Query 실행계획을 비교해보겠습니다.예시 1)예시 2)여기서 주의 깊게 봐야 할 컬럼은 type입니다. 다른 컬럼들은 TB_MBR_BAS의 테이블을 조회하면서 IX_MBR_BAS_02 INDEX만을 사용해 보여주겠다는 내용을 갖고 있습니다. IX_MBR_MAS_02 INDEX가 MBR_NM으로 정렬되어 있기 때문에 using filesort가 나타나지 않은 것입니다. 그렇다면 type에 range와 index는 어떤 차이가 있는 것일까요?range : where 조건에 조회하는 범위가 지정된 경우 나타납니다.예시1은 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX의 MBR_NM에서 ‘김’이 시작되는 위치부터 끝나는 위치까지 조회해 보여주라는 의미입니다. IX_MBR_BAS_02 INDEX를 이용해 ‘김’이 시작되는 위치로 바로 접근할 수 있는 것이 핵심입니다.index : index를 처음부터 끝까지 읽는다는 의미입니다.예시2는 TB_MBR_BAS를 조회하는데 IX_MBR_BAS_02 INDEX를 순서대로 읽어서 MBR_NM의 첫 글자가 ‘김’인 것을 보여주라는 의미입니다.두 개의 차이점을 꼽자면, range는 원하는 범위로 바로 접근해 값을 가져올 수 있는 것이고, index는 처음부터 끝까지 읽어서 그 값이 조건에 맞을 경우 가져오라는 것입니다. 따라서 예시1이 휠씬 성능이 뛰어난 Query라고 볼 수 있습니다. 결과는 모두 아래와 같이 출력됩니다.수행시간은 차이를 보였습니다. 예시1은 0.0041초, 예시2는 0.5초였는데요. 예시에서는 건수가 적기 때문에 큰 차이가 없는 것처럼 보이지만, 자료가 10배 또는 100배 많아진다고 생각해보세요. 엄청난 차이겠죠.활용: Query를 만들고 DISTINCT !마지막으로 Query 하나를 만들어보겠습니다. 1) MBR_NM의 중복을 제거하고2) 김 씨이면서3) 이름이 ‘혜’로 시작하는 사람을 먼저 출력하고4) 이외의 사람은 그 다음부터 오름차순으로 출력하려면 어떻게 만들어야 할까요?중복을 제거할 때는 일반적으로 DISTINCT 와 GROUP BY 두 가지를 사용합니다. 이번 글에서는 DISTINCT를 사용하겠습니다. 다음으로는 오름차순 정렬할 때 김 씨를 먼저 출력하는 것인데 조건문을 사용하여 김 씨인 것과 아닌 것을 구별해 우선순위를 주겠습니다. 다른 것은 위의 Query를 이행하면 됩니다. 먼저 DISTINCT를 넣고 수행해 보겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     MBR_NM  ; 실행계획은 다음과 같습니다.DISTINCT를 수행하면 Extra가 나타나며 group by로 표시됩니다. 여기서는 IX_MBR_BAS_02를 이용하여 gorup by(중복제거)하여 보여준다는 의미입니다. 수행하면 다음과 같은 값이 나옵니다.다음으로는 MBR_NM이 ‘김혜’로 시작하는 것을 먼저 보여주기 위해 ORDER BY 절에 CASE WHEN문을 사용하겠습니다.SELECT     DISTINCT     MBR_NM FROM test.TB_MBR_BAS ORDER BY     CASE         WHEN MBR_NM LIKE '김혜%'    THEN 0         ELSE 1     END     ,MBR_NM  ; 실행계획은 다음과 같습니다.ORDER BY에 조건이 들어가면서 INDEX의 순서대로 정렬한 것을 그대로 보여줄 수 없기 때문에 Extra에 Using temporary, Using filesort가 나타납니다. Using temporary는 가상 테이블을 만들어 사용하는 것인데, 다시 말해 가상 테이블을 만들어 다시 정렬하는 것입니다. 이에 대한 출력값은 다음과 같습니다.‘김혜’로 시작하는 사람이 먼저 나왔군요.글을 마치며지금까지 ORDER BY와 연관된 조건 처리를 알아봤습니다. 데이터를 더욱 체계적으로 나타내고 싶으신가요? ORDER BY를 이용해서 원하는 목적을 달성해보세요.글한석종 부장 | R&D 데이터팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발자 #개발팀 #인사이트 #경험공유

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법¶Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부¶페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조¶비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조¶비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스¶비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId);Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser();user.setNickname("Alice");user.setGender(Gender.FEMALE);user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId);getDatastore().put(userKey, user);user = getDatastore().get(userKey);getDatastore().delete(userKey);또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something }}Secondary Index 구현 방법¶HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기¶각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

지난번 초보 PM이 알아야 하는 초기 모바일앱 분석 101글에서 앱을 런칭한지 얼마 안된 극초기 단계의 스타트업에서 어떤 앱 운영 지표들이 필요한지에 대해 논의했었다. 읽어보지 못한 분들을 위해 간단히 요약하자면, (처음부터 BM이 붙어있는 앱이 아닌 이상) 1) Acquisition (획득), 2) Retention (유지), 3) Referral (추천) 이 3가지 사이클을 중점적으로 모니터링 하는게 중요하다... 라는 내용이었다. (본 글에서는 기본적 개념 설명은 생략할 예정이어서 앱 운영 지표가 생소하신 분들은 꼭 저 글을 먼저 읽고 오시길 권장한다)오늘 글에서는 여기에서 더 나아가 구체적으로 어떤 지표들을 데일리 베이스로 관리하면서 앱을 성장시켜야 하는지에 대한 방법론에 대해 그간 공부한 내용을 정리해 보고자 한다. 참고로 본 글의 내용은 앱이 성장하고 있는지를 일단위로 모니터링하기 위한 방법론이지 '성장하기 위한 방법론'에 대한 글이 아님을 명심하기 바란다.1. DAU, MAU의 환상에서 벗어나기언제나 필자가 강조하는 내용이다. 생각보다 많은 분들이 극 초기 단계의 서비스를 운영하면서 DAU (Daily Active Users), MAU (Monthly Active User) 지표만 목매고 있는 경우가 많다. 심지어 투자자들 중에서도 초기 단계 서비스를 점검하면서 `MAU가 몇명인가요?` 'DAU는 몇명인가요?' '총 다운로드는 얼마나 되요?' 달랑 이 3개만 물어보고 끝인 사람들도 종종 만나게 된다. DAU, MAU만 쳐다보고 있는게 왜 환상이냐면, 그건 두개 다 돈 처발라서 만들어내는게 가능한 지표이기 때문이다.좀 자세하게 썰을 풀어보기 위해 Day 1 리텐션이 30%도 안되는 어떤 앱서비스가 있다고 가정해 보자. Day 1 리텐션이 30% 이하라는 뜻은 그 앱을 깐 사람들의 70%이상이 다음날 앱을 비활성화 (또는 사용하지 않는) 시켜버린다는 뜻이다. Day 1이 30% 이하면 Day 7은 10%이하, Day 30은 거의 미미한 수준일 가능성이 높은 앱이다. 리텐션이 이정도면 이 앱은 사실 앱의 코어 가치 자체가 가치가 없거나 완성도가 매우 떨어지는 앱일 가능성이 높다. 그런데 만일 이 앱서비스를 하는 회사가 (또는 스타트업 팀이) 마케팅 버짓이 매우 많아서 하루에 페북 광고만 500만원씩 태우고 있다고 쳐보자. 페북에서 보통 평균 CPI가 1-2천원 수준이라고 하니 2천원을 적용하면 하루에 무려 2천명의 신규 유저가 유입되는 규모의 돈이다. 이 앱서비스가 매일 500만원씩 한달 1억 5천의 광고비를 태우면 어떤 DAU, MAU가 만들어질까? 계산의 편의성을 위해 리텐션이 Day 1가 30% -> 하루에 1%씩 리텐션이 감소해서 Day 30이 되면 1%가 된다고 가정해 보면 (보통은 Day 7까지 더 급격히 떨어지고 뒤로는 완만한 곡선을 그린다) 이 앱의 DAU는  2000, 2600, 3180, 3740 ... 이렇게 아름답게 성장하고 해당월 평균 DAU는 약 8천명, MAU는 해당월에 239,800명, 해당월 신규 다운로드는 6만이라는 숫자가 만들어진다.조금 과장 보태서 어떤 스토리가 가능해 지냐면, 이 앱의 대표가 약 5억원의 시드 (또는 엔젤)투자를 유치하기 위해서 정부지원사업+개인돈 긁어보아서 한달 열심히 지표 만든다음에 투자자들한테 5억원만 투자해주면 1년안에 백만다운로드, MAU 30만 이상의 중규모 단위의 앱으로 성장 가능하다는 나름의 근거숫자가 만들어 지는 것이다. 뭐 1억원 처발라서 3-5억원을 얻을 수 있는 딜이므로 창업자가 해당 앱에 완전 꽂혀있는 경우 충분히 발생가능한 스토리이다. 물론 VC분들은 그렇게 허투르지 않아서 저게 돈으로 만들어진건지 금방 들통나겠지만 (또는 분야에 따라 저정도 숫자로는 1억원 투자도 어림없는 경우도 있다) 필자가 강조하고자 하는 부분은 아무리 리텐션이 x같은 앱이라도 돈만 있으면 얼마든지 만들어지는게 DAU, MAU라는 숫자라는 점 이다. 또한 저정도 돈 태우고 있으면 앱스토어 피처도 되는 경우가 많아서 숫자는 저거보다 훨씬 더 불어날 수 있다. 따라서 초기 앱의 성장을 위해서 우선적으로 필요한 부분은 바로 이 DAU, MAU라는 숫자만 맹목적으로 쳐다보고 있는 환상에서 벗어나는 거다.리텐션이 x같아도 돈 처발라 만드는게 가능한 지표가 바로 DAU, MAU라는 놈이다.2. Acquisition (획득) 경로를 데일리로 점검이제 본론으로 넘어가서, 초기 앱에서 PM이 가장 신경써서 모니터링하고 데일리 마케팅에 반영해야 하는 지표는 단연코 Acquisition, 즉 획득지표이다. 전편 글에서 설명했듯이, Acquisition이란 매일 들어오는 신규 유저들이 어느 경로로 들어왔는가를 집요하게 데일리로 추적하는 지표를 의미한다. 추적하는 방법은 크게 2가지 방법이 있다.2-1. 앱 다운로드 링크에 추적코드 삽입보통 아이폰용, 안드용 앱을 모두 갖고 있으면 다운로드 링크를 하나로 통일해서 각각의 채널로 리디렉팅 시키는게 필요하다. 이때 추적코드를 포함시켜서 포워딩 해줘야 해당 클릭이 어느 마케팅 활동/채널에서 발생했는지가 추적 가능하다. 바크 앱의 경우 앱 다운로드에 추적코드를 다음과 같이 심어서 배포하고 있다.https://barkapp.co/download?ref=FacebookAd-HighSchoolAd-Busan-D3저기서 'ref=' 다음에 들어가는게 추적코드이고, 이 코드는 애플 유저의 경우 아이튠즈 링크에 다음과 같이 레퍼런스 코드로 전환되어 기록된다.https://itunes.apple.com/app/apple-store/id1100131438?pt=118117595&ct=FacebookAd-HighSchoolAd-Busan-D3&mt=8FacebookAd-HighSchoolAd-Busan-D3라는 추적코드가 아이튠즈 URL에 삽입되어 리디렉팅 되고, 저 링크가 클릭될때 마다 슬랙으로 실시간 모니터링도 가능해 진다.슬랙에서 다운로드 링크가 누군가에 의해 클릭될때 마다 이렇게 추적코드, 디바이스정보를 알림으로 설정해 놓을 수 있다.저걸 매일 쳐다보고 있으라는 뜻이 아니고, 하루에 저 채널에서 클릭이 얼마나 발생하는지를 내가 투입한 예산대비 효율관점으로 모니터링하는게 중요하다는게 핵심이다. 예를들어 본인의 마케팅 활동의 CPI 상한선이 500원으로 책정되어 있고, FacebookAd-HighSchoolAd-Busan-D3라는 마케팅에 오늘 100만원을 쏟아부었을 때 다운로드 컨버젼이 50%라고 가정한다면 적어도 저 링크에서 클릭이 오늘 1,000회 이상은 발생해 줘야 CPI 타겟을 맞출 수 있는 것이다. 역시 슬랙에서 내가 뿌린 추적코드가 하루에 얼마씩 클릭이 발생했는지를 리포트로 알림 받는것도 가능하다.슬랙에서 하루에 발생한 클릭 숫자를 정리해서 리포트로 알림받을 수 있다.2-2. 온라인에서 내 서비스가 얼마나 멘션되고 있는지 추적해주는 솔루션들 활용위의 2-1만 할 경우 문제가 뭐냐면, 내가 다운로드 링크로 뿌린거 외에 유저가 오가닉하게 내 앱에 대해 알게되고 이를 본인 채널로 언급하고 있거나 각종 기사, 트윗에 뜨는 트래픽들은 모니터링이 불가능하다는 점이다. 이런걸 가능하게 해주는 추적 서비스들이 시중에 널려 있는데, 우리는 그 중에서 notify.ly라는 서비스를 쓰고 있다. 이 서비스는 트위터, 유투브, 블로그 등등에서 내가 설정한 키워드, URL등이 언급될때 마다 크롤링을 통해 슬랙으로 알림을 주는 서비스이다.크롤이 가능한 거의 모든 사이트에서 내가 설정한 키워드가 언급될때 마다 슬랙으로 알림을 주는 서비스이다.우리는 이 서비스를 이용해서 바크 URL이 언급되거나 바크 관련 키워드들, 경쟁사 앱이 언급될때 마다 이렇게 슬랙으로 알림을 받으면서 모니터링 하고 있다. 이렇게 해 놓으면, 나중에 갑자기 트래픽이 터졌는데 그게 내가 뿌린 링크에서 터진게 아닐 경우 해당 서비스 멘션에서 그 소스를 찾아보는게 가능해 진다. 또한, 누군가 내 앱을 알아서 언급해 주고 있다는걸 실시간으로 아는것만으로도 기분이 좋아지고 사기가 진작되는 효과도 있다.이렇게 누군가 우리 앱을 언급하는 알림을 받을때 마다 사기가 진작되는 부가 효능도 있다.위에 언급된 두가지 방법 외에도 본인이 직접 구글이나 페북 검색을 통해 내 앱이 얼마나 언급되는지를 수동으로 찾아보는 방법도 있다. 가끔 시간이 남거나 위의 두가지 방법으로 도무지 트래킹이 안되는 트래픽이 있을때는 시도해 볼만 한데 자세한 방법은 생략한다.3. 앱 유저 활동성 모니터링내 앱에 들어오는 신규유저도 중요하지만 앱의 성장을 위해서는 유저의 활동성을 높은 수준으로 유지하는게 훨씬 더 중요하다. 여기서 설명하고자 하는 유저 활동성이란 내 앱을 다운받아 사용하고 있는 유저가 앱 내에서 얼마나 활성도를 띄고 있는지를 여러가지 각도에서 모니터링 하는걸 말한다. 크게 다음 3가지 방법이 있다.3-1. Low/Medium/High Activity User Flow유저들을 크게 Low Activity, Medium Activity, High Activity로 구분해서 유저들이 각 그룹에서 얼마나 이동하고 있는지를 데일리로 모니터링 하는 방법이다. 서비스별로 상이하긴 하지만 소셜앱의 경우 보통 정의는 일주일에 6일 이상 앱을 사용하고 있으면 High Activity, 3-5일이면 Medium Activity, 1-2일이면 Low Activity User로 분류한다. 이 플로우 차트는 Fabric을 사용하는 분들이라면 다음 그림과 같이 Daily New Users 탭 하단에서 일별로 확인 가능하다.패브릭을 사용하면 User Activity Flow Chart를 일별로 모니터링 할 수 있다.하지만 위 차트는 최근 한달 데이터밖에 확인이 불가능하기 때문에 필자는 위 숫자를 일별로 크롤해서 엑셀시트에 기록하여 관리하고 있다. 해당 지표가 어느정도 이상이 되야 적정수준인지는 비교가능한 데이터가 없어서 뭐라 말하긴 어렵지만, 본인은 High Activity 비율 약 30% 이상 유지를 목표로 운영중에 있다.High Activity User 비율을 일별로 기록하고 30% 이상 유지를 목표로 운영하고 있다.3-2. 활성도 3종세트 - Sessions per User / Session Duration / Stickiness본인이 개인적으로 앱 활성도 3종세트라고 부르는 지표들이 있다. 바로 1) 유저당 세션 수, 2) 평균 세션 시간, 3) Stickiness 라고 부르는 지표들이다. 하나씩 살펴보도록 하자.우선 유저당 세션수 (Sessions per User)는 보통 총 세션을 하루 유니크 유저수로 나눠서 계산하는데, 패브릭을 포함한 대부분의 툴에서 알아서 모니터링 해준다. 당연히 해당 숫자가 높아야 유저가 내 앱을 자주 찾는다는 뜻이고, 이 숫자 하나로 좋아지는 후행지표들이 수두룩 하다. 활성도에서 가장 주의를 기울여 관리해야 하는 지표이다.평균 세션시간 (Session Duration)은 한개의 세션이 종료될때 까지 평균 시간을 의미하는 지표로서, 역시 패브릭을 포함한 대부분의 툴에서 측정 가능하다. 평균 세션시간은 꼭 무조건 길어야 한다고 생각할 순 없다. 본인 앱의 코어서비스에 따라 다른것인데, 앱 내에서 특정 컨텐츠를 소비하는게 코어인 서비스라면 당연히 평균 세션시간이 짧아서는 곤란할 것이고, 반대로 다른 서비스들로 보내주는 중개 플랫폼 같은 경우나 사람들이 특정 목적이 있을때만 찾는 서비스 등은 평균 세션시간이 짧을 수도 있다.Stickiness는 사용자들이 얼마나 해당 서비스에 충성도를 보이는지를 보여주는 지표로서 보통 DAU/MAU로 계산한다. 해당 수식에서 유추할 수 있듯이 해당 퍼센트가 높을수록, 즉 월 1번 이상 방문자 중 데일리로 1번이상 방문하는 사람의 비율이 높을 수록 해당 앱은 유저들의 충성도가 높은 앱이라는 것을 보여주는 지표인 것이다. 본 수치는 본인이 사용하는 툴에서 보여주는 서비스도 있고 보여주지 않는 경우도 있다. (패브릭은 따로 보여주진 않는다) 이 경우 따로 DAU/MAU로 나눈 비율을 트래킹하면 된다. Stickiness 역시 무조건 높아야만 하는 수치는 아니다. 특히, 본인 서비스의 타겟이 좁을수록, 그리고 특정 타겟의 충성도가 일반적인 사람들에 비해 현저하게 구분되는 경우 이 수치가 낮을 수 있다. 실제로 얼마전 성공적으로 상장한 스냅의 Snapchat의 경우 이 수치가 48%인데, 페이스북의 75%에 비해 현저하게 낮다. 이걸 보고 숫자가 너무 낮아요~~ 이렇게 보면 안되고, 특정 유저 그룹이 열광적으로 반응하는 서비스가 스냅챗이구나~~ 하고 이해해야 한다. 아래 이미지는 요즘 가장 핫한 (틴더가 빠지긴 했지만) 소셜 서비스들의 주요 수치를 비교한 표인데, 스냅챗이 Stickiness와 평균 세션 타임이 현저하게 낮음에도 불구하고 유저당 세션 수가 매우 높은게 흥미롭다.출처: http://www.vertoanalytics.com3-3. User Engagement 지표 만들기위에 언급된 일반적으로 사용하는 지표들 외에 본인 앱의 코어와 관련된 기능들의 Usage Count를 모니터링하여 이를 User Engagement 지표로서 관리하는것도 중요하다. 예를들어 필자가 운영하는 바크 앱의 경우 유저들이 짖어대는 Bark Event Count와 사람들이 올린 드롭바크 포스트에 Happy 또는 Angry를 표현하는 Vote Count가 앱 활성도와 직결되는 기능이라 Bark Event Count + Vote Count를 합해서 User Engagement Count라는 지표를 모니터링 하고 있다.바크 앱은 Bark + Vote Count를 합한 지표를 User Engagement 지표로서 모니터링 하고 있다.4. Retention을 통으로 바라보지 않기알다시피 리텐션은 앱이 지속적으로 성장할 것인가를 가늠하기 위한 가장 중요한 지표이다. 아무리 돈을 처발라서 DAU, MAU를 높여놔도 리텐션이 떨어지면 그 마케팅 활동은 밑 빠진 독에 물 붓는 격이나 다름 없다. 보통 리텐션은 Day 1, Day 7, Day 30 이 3개를 기준으로 모니터링하는데, 중요한건 리텐션을 통으로 바라보는걸 주의해야 한다는 점이다. 무슨 말이냐면, 이 리텐션 데이터의 모수를 전체 유저와 특정 조건값에 해당하는 유저로 나누어서 비교 모니터링 하는게 필요하다는 뜻이다.예를들어 바크 앱과 같이 위치기반 소셜앱의 경우 초기에 리텐션의 모수를 전체 유저로 잡아버리면 리텐션 수치도 형편없을 분더러 중요한건 이 측정된 리텐션을 가지고 뭘 어떻게 해야 이 수치를 개선할 수 있는지가 막막해진다. 왜냐하면 위치기반 소셜앱은 해당 위치에 커뮤니케이션 할 유저가 유의미하게 많아져야 앱의 가치가 발생되는 속성을 지니기 때문이다. 따라서 위치기반 앱들은 특정 타겟 지역을 중심으로 리텐션을 따로 뽑아서 비교 모니터링 하는것이 꼭 필요하다. 바크 앱의 경우 나름의 기준이 있는데, 지역을 2km로 구역화 한 바크 존 내에 액티브 유저가 20명 이상 존재하는 지역을 '활성 바크존'이라고 정의하고, 전체 리텐션과 해당 존의 리텐션을 나눠서 모니터링하고 있다. 이를 통해 활성 바크존 VS 비 활성 바크존을 따로 분리해서 마케팅 활동 및 성과분석이 가능하다.바크는 리텐션을 전체 VS 활성바크존 두개로 나눠서 비교 모니터링하고 있다.5. 바이럴루프가 생기고 있는지 모니터링바이럴 루프의 개념에 대해서는 지난번 작성한 바이럴루프, 중요한건 알겠는데 어떻게 적용할래?글을 참고하길 바란다. 개념이 생소한 분들을 위해 간단히 요약하면 바이럴 루프는 다음과 같은 수식으로 계산된다.% of users who invites (전체 유저 중 추천행위를 하는 유저 비율) ×average number of people who were invited (한명이 끌어오는 유입량) ×% of sent invites accepted (초대를 받았을때 실제 다운로드 받는 비율, 일반적인 컨버젼 비율을 적용해도 관계 없음)이를 통해 계산된 숫자가 1을 넘으면 (즉, 100%를 넘으면) 바이럴 루프가 형성됐다고 부르고, 이게 형성되면 앱은 특별한 마케팅 활동을 하지 않더라도 유저가 알아서 주변 유저를 끌어오고는 레퍼럴 활동만으로도 성장하는 아름다운 그림이 그려진다.본인 앱에 바이럴루프가 생기고 있는지를 모니터링 하려면 우선 유저의 레퍼럴 활동 기작을 만들어주는게 중요하다. 다시말해서 1) 유저가 레퍼럴 활동에 참여하고자 하는 유인을 만들어주고, 2) 이 활동을 쉽게, 그리고 모니터링 가능하게 해주는 앱 내의 추천 인터페이스를 구현, 3) 해당 인터페이스를 통해 발생된 URL에서 발생하는 클릭량을 추적할 수 있는 기작을 만들어줘야 하는 것이다. 강조하지만 자세한 내용은 위의 바이럴 루프 글을 꼭 참고하길 바란다.바크 앱에서는 유저들에게 바크에너지라는 희소성 오브젝트를 통해 유저 추천행위를 하도록 유도하고 있고, 이 유저 추천행위는 앱 내에 URL 생성 버튼을 마련해 놓고, 그 버튼으로 공유할때 마다 해당 유저의 고유넘버가 추적코드로 삽입되도록 설계되어 있다. 해당 레퍼럴 활동에 참여하는 유저 수와 해당 유저가 끌어오는 유입량은 데일리로 모니터링해서 슬랙으로 알림을 띄우고 있다.바크는 앱 내에 공유버튼을 만들고 이를 클릭하면 자동으로 유저 고유 넘버가 추적코드로 삽입되는 공유 버튼을 만들어 운영하고 있다.본인 앱이 스냅챗 수준으로 사람들이 열광하는 앱이라면야 바이럴 지수가 항상 1이 넘겠지만, 대부분은 그렇지 않은게 현실이다. 즉, 이 숫자가 1이 넘을때도 아닐때도 있는데 중요한 점은, 유저의 레퍼럴 행위를 촉진할 수 있는 인터페이스 (혹은 마케팅 활동)을 기획하고, 해당 기획안이 실행됐을 때 바이럴 지수가 어떻게 변동하는지를 측정해서 가장 성과가 좋은 행위에 선택-집중할 수 있는 근거 데이터로 활용해야 한다는 것이다.일별로 바이럴지수를 모니터링하고, 이 활동을 촉진시킬 수 있는 각종 활동의 성과 분석 지표로 활용하는게 필요하다.이번 글에서는 초기 앱을 운영하는 스타트업이나 PM이 앱 서비스의 성장을 위해 어떤 지표들을 관리해야 하고, 이를 획득하는 방법, 그리고 실제 마케팅 및 앱 기획 활동의 근거 데이터로 활용하는 방법론에 대해 소개해 봤다. 다 읽고 나면 느끼겠지만, 초기 앱이 성장하는 바이럴 루프는 초보 PM이 알아야 하는 초기 모바일앱 분석 101 글에서 언급한 1) Acquisition (획득) -> 2) Retention (유지) -> 3) Referral (추천)으로 연결되는 큰 그림을 그릴 수 있느냐, 그리고 이 그림을 그리기 위해 어떤 활동들이 테스트되고 선택-집중의 사이클을 타고 있는지를 데이터에 근거해서 운영하고 있는가에 달려있다고 할 수 있다. 다시말해서, DAU니 MAU니를 따지고 있을 시간에 저 순환 루프가 형성되고 있는지를 따지고 있으라는 얘기이다.** 본 글은 문돌이 PM의 마케터 따라하기 시리즈 입니다.** 1화 보기 - 초기에 할만한 ASO (앱스토어 최적화) 팁** 2화 보기 - 초보 PM이 알아야 하는 초기 모바일앱 분석 101** 3화 보기 - 스타트업 브랜딩: 내가 보는 나와 너가 보는 나의 일치** 4화 보기 - 홍보영상 직접 제작해서 수백만원 절약해보자** 5화 보기 - 바이럴루프, 중요한건 알겠는데 어떻게 적용할래?** 6화 보기 - 인스타그램 노가다 마케팅 101** 7화 보기 - 문돌이도 간지나는 HTML 이메일좀 보내보자** 8화 보기 - 인스타 마케팅 헛수고를 줄이는 10가지 마케팅 방법론** 9화 보기 - 초기 스타트업의 무료 마케팅 채널** 10화 보기 - 프리미엄병에 걸리지 말자글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기

여러분은 중고 거래에 대해 어떻게 생각하시나요?혹시 '평화로운 그 곳'에서 물건을 사고 팔아본 경험이 있으신가요?꼭 익명의 인터넷 사이트 상이 아니라도 크고 작게, 누구나 한번쯤 해봤을 중고 거래.기억을 더듬어 보세요.오래 전 '아나바다'라는 슬로건이 성행하던 시절이 있었는데요. 단순히 아끼고 나누는 것 외에 같은 반 친구들, 한 동네 이웃들과 입지 않는 옷이나 사용하지 않는 물건 등을 바꿔 쓰고 다시 쓰는 알뜰살뜰하고도 가슴 따땃해지는 운동이었죠. 어디 그 뿐인가요? 매해 연말 '사랑나눔 바자회'라는 벼룩시장은 꿀같은 득템은 물론 수익금 일부가 사회 소외된 곳에 기부되어, 세상을 온화히 데우는 데에 동참할 수 있었던 좋은 장이었답니다.나에게서 의미를 잃은 것은 다른 이를 만나 가치를 되찾으며같은 방법으로 나 또한 누군가로부터 무의미해져 버린 것에서 새로운 가치를 찾는 것.도떼기마켓은 그 가치를 일깨우는 연장선 상에 있는 서비스입니다. 도떼기마켓은 보다 쉽고 편하며 안전한 중고 거래를 지향합니다. 당신 또한 우리를 통해 긍정과 호의의 중고 거래를 조우하길 소망합니다. 사람들로 하여금 새로운 라이프 스타일을 경험할 수 있도록 펼쳐진 너른 장이 되길 도떼기마켓은 기꺼이 자처합니다.지금부터 도떼기마켓의 탄생 비하인드 스토리들을 꺼내 들려 드리려고 합니다.이로써 당신의 생각 한켠에 자리한 중고 거래에 대한 인식이 이전보다 조금은 나아지길 기대해봅니다.' 중 고 '이거 지-인짜 좋은데... 뭐라 표현할 방법이 없거든요!3화 도떼기마켓은 '중개'하지 않습니다.: 도떼기마켓은 당신의 스타일을 구입합니다.3년 여 간 플리마켓을 개최해오며 제법 알찬 노하우가 쌓였다고 자부했습니다. 이정도면 생각하고 있는 것을 실행하기에 모자르지 않다고 판단했죠. 야심차게 시작한 도떼기마켓, 노하우만으로 개인간 중고 거래의 본질적인 문제점을 해결하기엔 턱없이 부족한 우리였습니다.다행인건, 이 사실을 깨닫는 데에 그리 오랜 시간이 걸리지 않았다는 거죠.  # 이러려고 중고거래 하나, 괴롭고 자괴감 들어..개인간 거래는 판매자가 해야 할 자질구레한 일들이 너무 많습니다. 성가시기 딱 좋은 일들로만 가득합니다.일단 사진을 찍어야 합니다. 그리고 업로드를 해야 합니다. '상세 사진'을 요구하는 프로 디테일러들의 귀찮은 재촬영 요청에 미리 대비하려면 발로 찍어도 요리조리 찍어내야 합니다. 여차저차 찍어낸 사진을 카페나 중고거래 앱 등에 올려둔 후 연락을 기다립니다. 하염없이 기다립니다. 기다리는 내가 심심할까봐 전국 방방곡곡의 또다른 판매자들이 내 게시물 위를 무서운 속도로 밟고 올라섭니다. 업데이트된 게시물이 많아 내가 올린 상품이 뒤로 밀리면 한 번씩 재업을 해줘야 합니다.드디어, 드디어, 드디어...!구매자가 나타납니다. 허나 그냥 순순히 사가면 그건 올바른(?)구매자가 아닙니다. 깎아 달라 합니다. 네, 뭐 이해 못하는 건 아니에요. 디스카운트 욕구는 본능에 가까운, 무의식이 지배하는 행동이라 할 수 있죠. 인정. 내가 구매자라도 그랬을 테니까요. 아니 그래도 그렇지.. 아직 쓸만하고 말짱해서 버리기엔 영 아까워 파는건데 사사건건 트집을 잡는 걸 듣고 있자니 괜히 속이 쓰리고 슬슬 분노가 치밀죠. 쌓인 정 때문일까요? 하... 사람이건 물건이건 쿨하게 이별하는 건 정말 어려운 일인가봅니다.그 많던 택배 상자는 누가 가져 갔을까. 평소엔 성가시게 굴던 빈 상자가 택배만 보낼라 치면 감감무소식입니다. 택배 박스를 찾으면요? 판매할 물건을 포장하고 택비 접수를 한 뒤, 보내야죠. 전전긍긍 기다리는 구매자에게 운송장 번호도 친절히 알려주고 걱정말라고 안심시키는 건 물론, 택배가 잘 도착했는지 확인까지! 이러다 구매자랑 정분나겠습니다.한 개 팔기도 이렇게 힘든데, 옷장 정리 후 한번에 대여섯개, 열 개 이상 팔려고 하면… 간편해졌다고 하더라도 직접 옷을 팔고, 실랑이하고, 배송에 확인까지 하는 건 여간 피곤한 일이 아닙니다.그래요, 팔아 치워보자며 마음을 다부지게 먹었던 우리가 결국 헌옷 수거함 앞에 서있는 이유기도 하죠. # 레몬마켓이 아닌, 피치마켓이 되어보자.판매자를 닦달해대는 구매자는 뭐 등 따숩고 편해서 그러나요?음, 조금 딱딱한 얘기를 하나 해볼까 합니다.중고 거래 시장은 속성상 상품 정보에 대한 판매자와 구매자(소비자)간의 정보 비대칭이 존재합니다. 필연적으로 말이죠. 이른바 레몬마켓(Lemon Market)이라 부르는 중고차 시장과 같은 맥락입니다. 구매자는 상대적으로 판매자만큼의 상품의 정보를 알지 못합니다. 이는 구매자로 하여금, 상품에 대한 불만족과 함께 사기를 당했다는 느낌까지도 주게 되죠. 결국 중고 상품에 대해 좋지 않은 인식을 심어주고, 중고 거래 자체에 대한 신뢰도 하락으로 이어지게 되는 거구요.아, 우린 이런 걸 원한 게 아니었는데...'쉽고 편한 중고 거래, 중고 상품에 대한 긍정적인 인식.'우리가 바란 건 이런 것들이죠. 보다 근본적인 부분에서 문제를 해결하고, 기존의 중고 거래와는 다른 차원의 혁신적인 편리함이 필요한 시점이었습니다. 무엇보다도 상품에 대해 객관적이고 정확한 정보를 제공함으로써 중고 상품 자체에 대한 신뢰를 회복하는 것이 중요했습니다.이 시장을 바꿔보리라. 직접 피치마켓(Peach Market)으로 만들어 보리라!(비장)# 당신의 스타일을 구입합니다.우리는 ‘중개자’에서 ‘중간(유통)자’가 되기로 결심하였습니다.판매자가 팔고자 하는 중고 의류를 도떼기마켓이 '직접' 구매하고 '직접' 케어해서 '직접' 판매하기로 한 것!중고 거래 과정에서 경험해야 하는 크고 작은 문제들을 우리가 대신 해결하기로 하였습니다. 당연히 사기를 당할 위험도 없어지는 거죠. 매의 눈을 가진 전문 패션 MD가 직접 옷을 검수하고 합리적인 판매금액을 제안합니다. 판매금액을 수락하면, 48시간 내에 통장으로 현금이 ‘안전’하게 입금됩니다. 더 이상 손품을 팔고, 발품을 팔고, 맘 고생할 필요가 없죠.무게(kg)당 몇 백원으로 쳐주는 터무니없는 헌 옷 매입 업체와는 결이 다릅니다. 도떼기마켓은 상품의 컨디션, 디자인, 트렌드 등 다양한 부분을 고려하여 합리적인 가격으로 구매하고 합리적인 가격으로 판매합니다. 그것도 중고 거래의 번거로운 일들을 모두 대신하면서 말이죠.도떼기마켓을 대표하는 역대 제비들도떼기마켓이 가져온 혁신적인 변화.빈티지 소셜 마켓에서, 중고 패션 마켓플레이스로 완벽하게 진화한 도떼기마켓이당신의 스타일을 구입합니다.어떻게? 바로 이렇게!다음 주, 도떼기마켓 비하인드 스토리 4회가 계속됩니다.#유니온풀 #도떼기마켓 #서비스 #서비스소개 #팀소개 #회사소개 

오프라인 고객 분석 솔루션 워크인사이트를 개발해 온 조이는 최근 온라인 접객 서비스 채널을 런칭했습니다. 이 글은 채널과 관련된 기술 블로그의 첫번째 글로 채널 데스크 프론트엔드(웹, 윈도우, OSX)의 기술 스택 및 개발 환경을 소개하도록 하겠습니다.React채널 개발을 처음 시작할 당시 (지금으로부터 1년 전) 에 워크인사이트 대시보드 및 기타 사내 툴에서는 AngularJS 1을 사용하고 있었습니다. 비교적 적은 코드로 복잡한 애플리케이션을 빠르게 만들 수 있는 점에는 만족했지만 퍼포먼스면에서는 아쉬운 부분이 많았습니다. 따라서 새로운 프레임워크 및 라이브러리를 리서치 했고 매우 가볍고 렌더링 퍼포먼스 면에서 AngularJS 1 대비 우위에 있던 React 를 사용하기로 결정했습니다.컴포넌트의 설계 패턴은 Redux를 만든 Dan이 제안한 Container 와 Presentational 컴포넌트를 구분하는 방식으로 설계하고 있습니다. 따라서 Container 가 data fetch 및 update 등의 액션을 실행하고 Presentational 컴포넌트들을 조합하여 렌더링을 하게 됩니다.React를 실제 1년째 사용해 본 결과 저를 비롯한 팀원들은 매우 만족하고 있습니다. 구조, 스타일, 동작을 한 컴포넌트로 묶어 재사용성이 매우 높아졌으며 React의 휴리스틱한 Dom diff algorithm 덕분에 렌더링 퍼포먼스에서도 많은 이득을 얻을 수 있었습니다.Facebook Flux Utils아키텍쳐는 페이스북이 제안한 flux 철학에 따라 설계되었습니다. flux를 구현하기 위한 기본적인 유틸리티 기능을 제공하는 Flux Utils을 사용합니다. Flux의 많은 구현체 중에 요즘 가장 인기인 Redux도 고려했었습니다. 저희가 프로젝트를 시작할 당시에 Redux는 5~6개월밖에 되지 않은 프로젝트였고 거의 Dan의 1인 프로젝트였기 때문에 향후 메인터넌스를 장담할 수 없다고 판단했습니다. 그보다는 페이스북이 만든 Flux Utils가 그런 면에서는 더 안전할 거라고 생각했던 것이죠.약 1년 정도 Flux Utils로 개발해오며 몇 가지 문제를 겪게 되었습니다. 애플리케이션이 커지면서 관리해야할 State가 많아지고 그들 사이의 의존성 관리 때문에 Store의 복잡도가 빠르게 증가했습니다. 그에 따라 테스트가 어려워지고 올바른 유닛테스트를 위해서는 테스트 코드 역시 매우 복잡해지는 문제가 있었습니다.그래서 Redux를 다시 리서치하게 되었고, 결론적으로 “단일 Store, 다수Reducer” 라는 Redux의 철학을 통해 State 관리 로직(Reducer)을 단순하고 테스트도 쉽게 유지할 수 있겠다는 생각을 하게 되었습니다. 뿐만 아니라 그 동안 설계와 관련되어 고민하고 필요한 경우 저희 스스로 개발해서 사용하던 많은 부분이 Redux의 서브 프로젝트 형태로 (redux-actions, redux-thunk, reselect 등) 개발되어 사용되고 있는 것을 발견해서 Redux로의 마이그레이션을 결정했고 현재 진행 중에 있습니다.Electron이 글의 도입부에서 이야기한 것처럼 채널 데스크는 윈도우용, OSX용 애플리케이션으로도 제공됩니다. 채널 개발 초기 당시 윈도우, OSX 각각 네이티브로 만들 리소스가 부족했기 때문에 웹 기술 기반으로 네이티브 앱을 만들 수 있는 다양한 솔루션들을 리서치했고 그 중 Electron을 선택하게 되었습니다.Electron은 제가 정말 좋아하는 제품인 Slack, Simplenote에서 사용하고 알려져 있고 국내에서는 Remember 등에서 사용하고 있습니다. 초기 개발 당시에는 안정성에 의문을 제기하는 개발자들도 많았고 저희도 여러 문제와 삽질(인증, 패키징, 이슈 레포팅의 어려움, 메모리릭 등등)을 많이 겪긴 했습니다만 개인적으로는 충분히 프로덕션에 쓸 수 있을 정도 수준이라고 생각합니다. 무엇보다 프론트엔드 개발자가 매우 적은 노력으로도 네이티브 데스크탑 앱을 만들 수 있는 장점이 다른 모든 문제점을 상쇄하고도 남습니다.언어개발 언어로는 자바스크립트 ES6를 사용합니다. 언어를 선택할 당시에도 여러 옵션이 있었는데 가능하면 실험적이지 않고 표준을 사용하는 것이 미래 유지보수에 안전하다고 판단했습니다. 또한 다른 자바스크립트 대안 언어를 사용하지 않더라도 ES6 (일부 ES7 포함) 스펙도 충분히 효율적인 개발이 가능하다고 생각했습니다.코딩 스타일은 기본적으로 Airbnb의 코딩 스타일 가이드라인을 따르며 조이의 상황과 맞지 않는 부분은 엔지니어들과 상의 후 수정해서 사용하고 있습니다. 스타일 체크는 ESLint로 자동화한 뒤 Circle CI와 붙여서 모든 풀리퀘스트에 대해 점검하고 있습니다.테스트초기 개발할 때는 테스트 코드를 별도로 붙이지 않았습니다. 고객의 요구와 기타 상황에 따라 기획과 설계가 크게 변경되기도 했고 그 때마다 기민하게 반응하기 위해서, 어느 정도 확립된 제품이 되기 이전에는 테스트 코드는 작성하지 않는 것이 좋다고 판단했습니다. 이제는 많은 부분이 확정되었고 안정성이 중요해지기 시작했으며 애플리케이션이 커지면서 자동화된 테스트는 필수가 되기 시작했기에 최근에 도입을 하고 있습니다.테스트를 위한 도구는 Jest, Enzyme 등을 사용합니다. Presentational 컴포넌트에 대한 테스트는 props에 따라 원하는 형태로 렌더링이 이루어지는지, 이벤트에 따라 콜백이 잘 실행되는지 등의 Spec 을 작성합니다. Container 컴포넌트에 대한 테스트는 각종 이벤트 및 동작을 시뮬레이션하고 그에 따라 Action이 잘 발생하는지 또는 내부 state가 잘 변경되는지를 테스트합니다. 또한 Store (또는 Reducer), Action Creator, Model, Util 등 모든 구성 요소에 대한 테스트를 붙이려고 노력하고 있습니다. 유닛 테스트가 아닌 e2e 테스트 혹은 css 스타일 테스트 등은 하지 않고 있습니다.빌드 및 배포현재 채널 데스크는 Client-side rendering을 합니다. 초기 로딩 속도가 느리다는 단점이 있어서 Server-side rendering으로의 전환도 고려하고 있습니다. 이미 Node.js 를 사용하고 있어서 Isomorphic Javascript의 형태로 어렵지 않게 전환이 가능합니다.작성된 자바스크립트는 Babel로 컴파일되고 Webpack으로 번들화됩니다. css를 포함한 각종 리소스들 역시 Webpack을 통해 처리됩니다. 웬만한 작업은 npm과 Webpack으로만 자동화하려고 했으며, Electron과 관련된 작업(패키징, 인증 등)들만 gulp를 이용해 자동화됩니다. 모든 리소스들은 Node.js + express 서버로 Serving 되고, Node.js 앱은 Docker로 빌드되어 AWS EC2로 배포됩니다.마무리이상으로 채널 데스크 프론트엔드의 기술 스택을 소개해드렸습니다. 앞으로 각 부분 별로 저희 팀이 고민해 온 문제들과 해결 방법을 공유하고자 합니다. 뛰어난 개발자 분들의 많은 관심과 피드백 부탁드립니다!#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

백엔드 서비스로 Python을 사용한다면 만나게될 상황을보다 쉽게 해결하기 위한 와탭의 Python APM, 개발하게 된 이유입니다.파이썬은 배우기 쉽고, 어디서나 실행되는 언어라고 이야기되며, 인기도 높습니다. 생각보다 많은 곳에서 배울 수 있으며, 혼자 배우기도 좋습니다. 그런데, 이 규모가 확대되어서 스타트업의 경우에 Python을 사용하여 백엔드 서비스를 개발하는 경우를 찾는 것이 어렵지 않습니다. 또는, 수학적인 알고리즘이거나 ML(머신러닝)과 같은 영역이거나 블록체인등에서 Python을 사용하여 API geteway나 broker를 사용하는 경우에 한정한 상황을 고려하고 있습니다.Python으로 백엔드 서비스를 만들 때에는 성능과 설계 부분에 대해서 많은 걱정을 하게 됩니다. 이런 상황을 만나게되는 개발자는 여러가지 문제를 만나게 됩니다. 그 문제에 와탭은 집중합니다.!와탭은 백엔드 서비스를 Python으로 개발시에 만나게 되는 상황을 가장 최우선으로 생각하게 되었습니다.Python으로 '설계', '개발'되고 '테스트'된 후에 '배포'되는 상황에서 서비스의 불완전함과 속도상의 문제, 리소스의 불협화음등을 '유지보수'하는 단계를 '성능 튜닝'이라고 정의하고, 이를 고려한 상황을 보다 단순화하는 것이라고 생각하게 되었습니다. 이를 어떻게 처리하느냐가 와탭 Python의 핵심 가치라고 생각하였습니다.----- 이 부분은 Python korea 페이스북에서 '배권한'님이 지적하신 내용을 기반으로 일부 첨언되었습니다.----- python native 개발자들에게는 불필요한 설명에 해당됩니다.파이썬은 분명, 읽기 쉽고 사용하기 쉬운 것은 장점이며, 라즈베리파이 위에서 동작되는 기민함은 정말 매력적입니다. <- 원래 문장.(* 현재에는 jvm도 동작합니다. 하지만, 작고 기민하게 다양한 IoT 디바이스에서 폭넓게 활용되는 것은 파이썬의 장점은 분명하지 않나 합니다. 이 부분에 대한 지적이 있어서 첨언합니다. )내부 구성상 비동기식으로 쓰레딩이 아니라, 단일 이벤트 루프를 사용하는 비동기식 작성은 매우 효과적입니다. <- 원래 문장.(* 이 부분도 asyncio나 gevent등에 대한 이야기이고, CPython의 언어 구현상 GIL때문에 쓰레드가 비효율적이라는 이야기를 거론하고 싶었으나, 일반적으로 파이썬에 대한 언어를 사용할때에 대부분 사용하는 이유가 단일 이벤트 루프기반의 비동기식 작성이 매우 일반적으로 사용되기 때문에, 이렇게 서술되었습니다. 하지만, 이런 설명은 백엔드로 Python을 사용하는 경우에 대부분의 프레임웍들에서 처리되고 있기 때문에 서술이 불분명하다는 지적이 있었습니다. 당연, 백엔드 서비스를 개발할때에 사용되는 wsgi interface등에 맞추어서 서술되는 경우에는 이런 설명이 무의미합니다.다만, 이렇게 서술한 이유는 Java를 기반으로 APM이 개발되어졌기 때문에 이 부분에 대한 서술이나 설명이 필요하다고 생각한 저의 과도한 설명이 되겠습니다.이 부분은 Python Native개발자들에게는 불필요한 설명이 되겠습니다. 하지만, 백엔드 서비스를 개발하면서 만나게될 환경에서는 이 부분에 대한 이해가 어느정도 필요하다고 생각되어 서술된 내용이라고 생각해주시면 감사하겠습니다. )----------------------------------------------------------------------------------------------------------------------이 방식은 복잡한 자원 경쟁이나 교착상태를 발생하지 않게 되며, 기본 코딩과 유지보수를 정말 수월하게 만들어 줍니다. 그만큼 일관성이 높은 수학 알고리즘을 구현하는데 매우 적합합니다. 하지만, 냉정하게, 비즈니스 로직이나 분기가 많은 업무 로직에 적합한 언어는 아닙니다.하지만, 수학적 알고리즘 기반의 주요 모듈 위에 데이터베이스가 일부 필요하고, 웹서비스의 형태로 가동되는 구조라면 파이썬은 매우 훌륭한 선택이 되고 있으며, 생각보다 많이 사용됩니다.그런 이유 중의 하나는 파이썬의 멀티패러다임 구성과 같은 구성에서는 자바에서처럼 굳이 프린트를 위해서 객체지향 클래스를 만들 필요 없이 간단한 함수형 스타일도 가능하게 구성이 됩니다. ( 자바 8에서는 이런 함수 기능도 추가되었습니다. )단순한 구조와 방식 때문에 파이썬 개발은 요즘처럼 ML이나 AI 등의 기술적 요소들이 많이 사용되는 환경에서는 매우 효과적입니다. 백엔드 파이썬 개발이 많이 보이게 되는 이유이기도 하죠.또한, 파이썬 개발의 단점이라고 지적되던 문제들도 현재에는 실행 속도 문제는 사실상 큰 문제가 되지 않는 상황입니다. 일례로, 파이파이(PyPY)로 실행된 파이썬 코드는 웬만한 수준의 C 코드보다 빠르게 동작합니다.굳이 더 지적하자면, 모바일 컴퓨팅과 브라우저에 따른 웹 애플리케이션 클라이언트는 굳이 파이썬으로 작성할 필요성을 느끼지 못한다고 이야기하는 정도입니다.하지만, 이런 파이썬 개발에 가장 큰 문제가 있습니다.테스팅 없이는 동작하기 어렵고,실제 동작 환경에서만 등장하는 오류의 발생파이썬의 특성상 동적 입력 형태에 따르는 더 많은 테스팅을 필요로 하고 있으며, 실제 실행시간에만 나타나는 오류를 찾는 것이 가장 큰 문제가 있습니다. 이 부분은 수많은 파이썬 개발자들을 괴롭히고 있습니다.( 단편적으로 파이썬 개발환경이 매우 고도화되어있지 않으며, 파이썬으로 백엔드 서비스를 만들 것이라고 예측하지 못한 점도 있을 것입니다. 앞으로 파이썬 개발이 더 고도화 되기를 기원합니다. )이 가장 큰 문제를 잡기 위해서와탭은 집중하였습니다.파이썬 백엔드 개발 시의 문제 해결!물론, Python도 디버깅에 대한 지원 유틸리티가 존재합니다.pdb라는 파이썬 디버깅 모듈을 통해서 Step over/Step into, 중단점(breakpoint) 설정, 콜 스택 검사, 소스 리스팅, 변수 치환 등을 할 수 있습니다.‘Phthon -m pdb 파이썬 파일. py’의 형태로 디버그 동작 화면에서 세부적인 동작을 트레이스 해보는 방식을 사용하거나, pdb모듈을 import 한 후에 pdb.set_trace()를 중단하고 싶은 부분에 넣어서 사용하는 방식도 사용됩니다. 또한, 디버그 세션을 사용하는 방식이며, PDB를 사용하여 디버깅하는 방식들도 흔하게 사용됩니다.PyCharm, PTVS, Spyder 등의 IDE를 사용해서 디버깅을 하는 방법은 전통적인 개발환경과 동일하게 사용할 수 있습니다.하지만, 이 방식들은 백엔드 서비스에는 맞지 않게 되며 개발자들은 백엔드 서비스 동작시에 디버그 추적을 위한 로그를 거는 방식을 흔하게 사용하게 됩니다. ( 너무도 전통적인 방식이죠. )정말 백엔드로 파이썬을 사용하고 있다면, 오류 추적이나 동작 메커니즘을 추적한다는 것은 매우 귀찮고 번거로운 작업이 됩니다.만들어지는 파이썬의 모든 파일에 해당 로그를 넣었다가 빼었다가, 배포의 오류를 만나는 상황까지 매우 번거로운 작업들이 끊임없이 반복되게 됩니다. 이런 상황들을 추적하기 위한 APM의 추적 기능들을 찾게 됩니다.또한, Python의 특징상 수학 알고리즘으로 구성된 API 중개인의 형태를 취할 경우에 DB에 대한 접근을 위한 ORM에서의 추적과 외부 웹 호출들이 뒤섞이게 되면서 오류 추적은 매우 짜증스러운 단계로 진화되게 됩니다.Python으로 백엔드 개발을 하게 되면만나게 되는 매우 짜증스러운 상황이죠.그래서, 와탭의 Python APM은 이 문제에 집중하기 위해서 와탭 고유의 문제 해결 방식을 그대로  아키텍처로 적용하여서 개발시에 편하고 빠르게 성능을 추적할 수 있도록 제작되었습니다. Python 백엔드 개발을 위한 최선의 방향을 제시합니다.Python개발자는 와탭의 APM을 설치하면 매우 손쉽게 웹 트랜잭션의 단계, 에러 추적, 클래스 추적, DB의 형태 및 Slow Query추적, 외부 호출 메커니즘의 구성 등을 설치 이후부터 빠르게 추적할 수 있으며, 개발자의 실수이거나 다른 외부 호출의 문제, DB와의 관계 등을 빠르게 잡아낼 수 있습니다.에러를 추적하기 위한 로그를 동작한다던지, 실환경시에 배포를 다시 한다던가 하는 귀찮은 작업을 모두 제거하는 것뿐만 아니라, 매우 통계적으로 의미 있는 와탭의 트랜잭션 추적 메커니즘을 사용할 수 있게 됩니다.파이썬을 기반으로 백엔드를 구성하는 곳이라면,와탭 APM은 매우 의미 있는 결과를 도출할 수 있습니다.와탭 Python의 세부적인 기능을 조금 더 상세하게 설명드리겠습니다.가장 먼저, 실시간 트랜잭션 모니터링!5초 주기로 트랜잭션을 수집하는 와탭의 방식은 서버의 부하를 최소화하면서 가장 의미 있는 데이터들을 수집하고 데이터 기반으로 오류와 트랜잭션을 빠르게 추적할 수 있게 합니다.파이썬 개발 시의 동작성을 체크하기 위한 와탭만의 고유의 진행 중인 트랜잭션 실시간 모니터링 기능인 아크 이퀄라이져와 동작된 웹 트랜잭션의 종료시간을 기준으로 시각화하여 동작된 트랜잭션의 상황을 한눈에 파악할 수 있습니다.와탭 Python APM위의 그림을 보면, Active Transaction으로 불리는 원형( 아크 이퀄라이져라 함 )으로 실제 동작중인 트랜잭션의 개수와 동작속도 등을 체크할 수 있으며, Hitmap을 통해서 종료된 트랜잭션의 속도를 시각화하여 볼 수 있습니다. 이 두 개의 시각화 만으로도 느린 트랜잭션을 추적 관리할 수 있습니다.Python 트랜잭션 추적 및 분석개발자는 단지 APM을 동작시켰을 뿐이지만, postgreSQL 데이터베이스에 연결하고 SQL문장을 주고받는 부분들을 하나의 시각화된 관점으로 나열해서 확인할 수 있습니다.각각의 동작 시간을 추적하는 것은 물론이고, 이 내용은 ORM으로 매핑된 상태에서도 SQL의 동작 순서대로 시각화되기 때문에 순서가 꼬이거나 문제가 발생되는 부분들을 손쉽게 찾아볼 수 있게 합니다.이외에도 와탭 APM( Java, Node, PHP 등의 모든 APM)에 기본적으로 제공되는 트랜잭션 추적 모듈 이외에도 사용자가 원하는 모듈 추적에 대한 기능들을 플러그인 형태로 정의할 수 있습니다. 더 복잡한 추적을 위해서 와탭의 고유기능을 추가적을 확대 사용이 가능합니다.WHATAP_HOME 의 plugin.json파일에 적절한 내용을 수정하여 특정 모듈의 데이터를 추적할 수 있습니다. 특정 모듈의 데이터를 추적하거나, 사용자 별로 원하는 모듈을 추적할 수 있습니다.*사용 안내:•[module_name]: 추적하고자 하는 대상의 모듈 명. import 하는 모듈 명 이기도 하다.•[class_name]: 추적하고자 하는 대상의 클래스 명. 없다면 ‘’(empty string)으로 사용한다.•[def_name]: 추적하고자 하는 대상이다.•args_indexes: 추적하고자 하는 대상의 아규먼트 인덱스. 여러 개일 경우 , 로 구분한다.•kwargs: 추적하고자 하는 대상의 키워드 명. 여러 개일 경우 , 로 구분한다.Plugin 기능 사용위의 예제에서는 Plugin과 SQL update문장의 순차적인 실행,세부 Plugin 설정에서 사용자의 모듈명, 추적 클래스 명, 추적대상과 아규먼트 인덱스, 키워드 등을 추적할 수 있습니다.*사용 예:plugin.json{"[module_name]": {      "class_name": "[class_name]",      "def_name": "[def_name]",      "args_indexes": ", ",      "kwargs": ", "},"httplib2": {      "class_name": "Http",      "def_name": "request",      "args_indexes": "1",      "kwargs": "method"},"faker.providers.address": {      "class_name": "Provider",      "def_name": "street_address",      "args_indexes": "",      "kwargs": ""}}두 번째, 데이터베이스를 매핑한 ORM과 SQL의 순서와 속도, Slow Query!매우 당연하게 파이썬을 기반으로 백엔드 개발을 할 경우에 데이터베이스를 사용하게 되며, 이에 대한 Slow Query와 관련된 추적하는 것이 개발자에게 필요하게 됩니다. 향후, RDS기반을 사용하게 되면 Query추적은 대부분의 데이터베이스 처리에 기본이 될 것입니다.현재 지원되고 있는 mysql / postgresql에 대하여 SQL Query, Fetch Count, SQL Query수행 시간을 수집합니다.Python개발 시에 RDBMS(관계형 데이터베이스 관리 시스템)를 선택하면 거의 항상 ORM(객체 관계 매핑) 라이브러리를 함께 사용하게 됩니다.특히, 파이썬에서는 이런 ORM라이브러리가 다양하고 사용하기 쉽기 때문에, 매우 흔하게 사용하고 있습니다.ORM의 장점으로는 쿼리를 생성하거나 추상화하는 대신, 데이터 베이스 시스템에 대한 접근을 쉽게 할 수 있는 장점이 있습니다. 다만, 이러한 장점 때문에 실제 만들어진 쿼리가 어떠하고 쿼리 수행 시간이 얼마나 걸리는지에 대해서는 추적이 어렵다는 점이 있습니다.이처럼, 파이썬의 특징상 ORM(객체 관계 매핑) 라이브러리를 사용할 경우에 추상화된 쿼리가 어떻게 동작하고, 실제 어떤 상황으로 발생 및 동작되는지를 한눈에 파악할 수 있게 합니다.ORM으로 매핑된 SQL의 순차적인 동작 상태 파악그리고, 세 번째. 외부 호출 추적파이썬 백엔드 개발 시에 사용되는 외부 호출(request/httplib2)등의 외부 호출과 관련된 호출 정보 및 수행 시간 등을 수집합니다.외부 호출을 사용하는 경우에는 각각의 호출에 대한 지연시간에 대해서 세밀하게 추적해야 하므로, 이와 관련된 에러와 지연시간 등을 추적하는 것은 매우 중요한 개발 시의 관점입니다.Python 외부 호출 추적마지막 중요 관점 네 번째는, 튜닝을 위한 다양한 프로파일 데이터의 제공을 이야기할 수 있습니다.와탭의 파이썬 에이전트는 위에서 나열되는 성능 저하를 위한 요소들의 전체적인 관점에서 수집하고 그 데이터들을 시각화할 수 있습니다.데이터베이스를 효율적으로 사용하고 있는지, 사용하는 ORM툴과 매핑과의 관계, 쿼리와 쿼리의 수행 시간과 상태에 대한 추적, 외부 호출시간과 각각의 지연되는 외부 호출과의 관계와 순서 등이 전체적으로 백엔드로 개발되는 Python의 성능 튜닝에 영향을 주게 되는 것이죠.그 이외에도 전체적으로 백엔드 서비스의 TPS, 응답 시간, 서비스 리소스 사용량과 어떤 에러가 발생되고 있는지를 알 수 있습니다.서비스 사용자가 사용하는 상세한 정보들을 프로파 일릉 함으로써 이들의 연관관계를 한분에 파악하게 해줍니다. 와탭에서 관리되는 프로파일 정보는 - 트랜잭션, SQL Query, 외부 HTTP호출, Error, User Agent, Client IP 등의 상관관계들입니다.그리고, 덤으로... Python이 설치 운영되는 전체적인 패키지의 버전을 한눈에 파악할 수 있는 것은 너무도 당연한 기능입니다.설치된 Python 패키지 확인그리고, 와탭의 DNA를 그대로 이어받은 APM이기 때문에, 기본적인 APM의 기능들을 대부분 담고 있습니다. 처음 와탭 APM을 접하시는 분들을 위해서 간단하게 설명드리면 다음과 같습니다.CUBE 메뉴는 시간을 기점으로 와탭 Python APM이 설치된 이후부터 현재까지의 모든 상황들을 추적 관찰할 수 있습니다. 주말에 오류 간 난 상황이라던지, 특정 오류의 발생 시점을 알고 있는 경우에 빠르게 해당 문제가 발생한 위치나 SQL 등을 추적할 수 있습니다.상세한 일간, 주간, 월간 리포트나 MAU 등을 추적할 수 있는 리포트 기능들은 와탭만이 가지고 있는 장점에 해당됩니다.Python으로 백엔드 웹서비스를 개발하고 계시다면, WHATAP Python APM은 개발과 운용을 매우 풍요롭고 빠르게 해줍니다.파이썬 백엔드 서비스 개발자라면 와탭 APM!

   전자상거래 시장의 규모가 하루가 다르게 커져가고 있다. 이제 대부분의 소비자는 오프라인 매장보다는 인터넷쇼핑몰을 더 선호하는 흐름을 타고 있다. 굳이 발품을 안팔아도 되고 가격비교도 편하기 때문이다. 전자상거래 시장의 성장과 함께 관련 기업들 또한 동반 성장하고 있다. 그 중 하나가 바로 웹뜰이다. 본지는 고객과의 신뢰를 가장 중요시 하며 최고의 맨파워로 책임경영을 펼치고 있는 웹뜰의 이태경 대표를 만났다.   최근 전자상거래 시장의 성장과 맞물려 귀사는 패션브랜드 e-비즈니스 사업을 활발히 펼치고 있는 것으로 알고 있다. 우선 회사에 대해 간략히 소개해 달라.   웹뜰(주)는 패션브랜드의 성공적인 온라인 비즈니스 모델을 컨설팅하고, 기획 및 판매 운영하는 회사다. 온라인 유통 분야의 전문가들이 모여 여러 패션브랜드들과 파트너십을 갖고 성공적인 사례를 만들어가고 있다. 우리는 위탁, 매입, 생산, 컨설팅 등의 형태로 패션브랜드들의 온라인 쇼핑몰 판매를 주력사업으로 삼고 있다.   지난 2008년 설립돼 10년차를 맞이했다. 회사를 설립한 배경은? 그리고 그 간 걸어온 길에 대해 알고 싶다.   본인은 의류학과를 전공했고, 패션브랜드에서 온라인 팀장으로 근무하면서 이 분야에 관심을 가지게 돼 본격적으로 일을 시작하게 됐다. 직장생활을 하면서 해당 업무를 성공적으로 수행해 제법 인정을 받았고 여러 회사로부터 스카웃 제의도 받았으나 큰 관심이 없었다. 솔직히 말하면 사회 초년생 시절부터 사업을 하고자 하는 의지가 있었다. 회사 설립 배경을 살펴보면 온라인 마켓이 성장하는 시기에 체계적으로 판매하는 업체가 많지 않다는 것을 파악하고 처음에는 간단히 컨설팅을 하다가 그 누구보다 잘 판매하고 운영할 자신이 있어서 본격적으로 사업을 시작하게 된 것이다.   현재 조직은 어떻게 구성돼 있나? 또 물류센터 등 회사 인프라에 대해서도 궁금하다.   크게 MD, 물류, CS, 웹디자인, 경영관리 부서로 구성돼 있다. 물류는 3군데서 운영하고 있는데 한군데가 직영이며 2곳은 3자물류를 활용하고 있다. 향후 물류센터 구축에도 관심을 가지고 있다.   패션, 온라인 판매 사업 주력   전자상거래와 관련, 현재 다양한 사업을 전개하고 있는 웹뜰의 가장 주력 사업이 무엇인지 궁금하다. 그리고 그 이유는?   다양한 사업이 있지만 패션 카테고리 온라인 판매 사업이 주력 사업이다. 그 이유는 이 사업이 처음으로 펼친 사업이고, 회사에서 가장 큰 매출을 차지하기 때문이다. 간단 명료한 이유다.   주요 고객사는 어떻게 형성돼 있나? 그리고 향후 타겟층이 궁금하다.   판매처는 오픈마켓, 소셜커머스, 패션전문몰, 종합몰, 백화점몰, 폐쇄몰 등이다. 자세히 언급하면 하프클럽, 패션플러스, 11번가, 옥션, G마켓, 티몬, 위메프, 쿠팡, GS이숍, 롯데닷컴, 신세계몰, H몰, AK몰, 카카오톡 선물 등 꽤 유명한 기업들이다. 우리는 향후 국내 온라인 외에 해외 판매를 준비하고 있다.   귀사는 고객과의 신뢰를 가장 중요시 여긴다고 했다. 고객과의 신뢰 구축을 위해 가장 신경써야 할 부분은?   무엇보다도 정확한 상품 정보 제공과 정확한 배송이다. 그리고 고객과의 신뢰도 중요하지만, 저희가 신뢰를 언급했던 부분은 상품 공급처와의 신뢰 구축도 포함된다. 상품 공급처의 목적에 맞게 운영 계획을 짜고 공급받은 물량 기준 판매율, 매출 목표 달성을 반드시 이행하도록 하면서 신뢰를 구축해 나가고 있다. 그래서 오랫동안 거래하고 있는 브랜드들이 많아지고 있는 것이다. 파크랜드, 인디에프, 아이더 등이 대표적인 경우다.   고객사 제품 브랜딩 초점   그렇다면 경쟁업체 간 우위를 점하기 위한 귀사의 특징 및 장점에 대해 설명해 달라.   우선 브랜드별 체계적인 관리력이 우수하고 브랜드별 매출 효율 가장 높다. 다음으로 촬영, 디자인 등 브랜딩을 위해 노력하고 있다는 점이다. 우리는 새로운 시도를 통해 리딩 업체로 거듭나고 있다. 또 빠르게 변화하는 온라인 시장에 가장 빠르게 대응하고 적응해 앞서가는 점도 눈여겨 볼 부분이다. 미자막으로 위탁 판매 외 매입, 온라인 전용 상품 기획에 참여해 높은 판매율 기록하고 있다.   이태경 대표님의 경영철학에 대해 듣고 싶다.   입점몰, 고객, 직원과의 약속 이행을 가장 중요하게 생각한다. 다시 말해 신뢰를 소중히 여기는 것이다. 그리고 좋은 상품을 좋은 가격에 소싱해서, 대중에게 제공하는 것도 중요하다고 생각한다. 뿐만 아니라 가장 먼저, 가장 열심히, 가장 정직하게 업무를 해나간다면 성공할 수 있다고 생각한다.   갈수록 조직문화가 발달하는 이 시대에 웹뜰의 복지현황 및 사회 공헌활동에 대해서 알고 싶다.   우선 월별로 팀비를 지원해 팀 단합을 고취하고 있으며 체력단력비, 도서, 각종 교육비, 소모임 활동비 등을 지원하고 있다. 이와 함께 쾌적한 휴계실를 완비하고 있다. 또 전사적으로 분기별로 문화 활동, 체육대회, 워크숍을 진행하고 있으며 장기근속자에게 포상을 하고 여름휴가일수를 추가적으로 지급해 애사심을 갖게 만들고 있다. 이와 함께 매월 목표달성에 따른 인센티브, 매월 우수사원 선정 인센티브, 매년 최우수사원 선정 인센티브, 매년 손익 분배 전직원 인센티브를 지급해 직원들을 만족시키고 있다. 여성 직원들이 많은 편이라 여성 직원들을 위해 작은 것 하나까지 신경쓰려고 하고 있다.   화주사가 물류기업을 선택할 때 가장 중요하게 생각하는 부분에 대한 대표님의 견해는?   물류기업 대표와 센터장, 우리 책임자가 얼마나 책임을 지고 실무에 관여하는지를 중요하게 생각한다. 그리고 약속이행을 잘하고 신뢰도가 높고 믿을 수 있는 사람인지를 중점적으로 본다. 이를 위해 온라인 판매, B2C를 다양하게 경험했고, 현재 운영하고 있는지를 따져본다. 아울러 여러 가지 변수에 빠르게 대응하고 인력수급이 원활한지를 살펴본다. 인프라의 경우 비용 측면(평수, 인력, 시설 등)에서 얼마나 효율적으로 운영을 잘하는지 알아본다.   중소기업에게 길잡이가 되는 것   회사를 이끌어 오시면서 가장 보람된 순간과 힘들었던 순간은 언제인가?   가장 보람된 순간은 온라인 매출이 적었던 브랜드를 매출 1위로 만들었을 때와 고객이 역시 웹뜰이라고 할때다. 그리고 웹뜰 출신의 직원들이 업계에서 중요한 역할을 하고 있을때와 회사에 애사심을 갖는 직원들이 조금씩 늘어날 때 뿌듯하다. 그리고 소기업들에게 작게나마 길잡이가 되어줄때 보람을 느낀다. 힘들었던 순간은 지속적으로 성장시킨 브랜드가 정치적인 요인으로 계약이 갑자기 종료될 때 많이 안타까웠다. 그리고 오랫동안 아끼던 직원이 퇴사할때 심정이 착잡하다.   웹뜰의 중장기적인 비전에 대해 듣고 싶다. 또 향후 목표가 무엇인지 알고 싶다.   패션 외 카테고리를 확장하는 것이다. 특정 카테고리에 한정되지 않고 다양한 좋은 상품들을 지속적으로 소싱하는게 목표라고 할 수 있다. 또 국내 뿐 아니라 해외 브랜드를 수입하고 국내 상품들을 해외에 수출해 글로벌한 기업으로 커 나가는 것도 또다른 목표다. 다른 한편으로 디자인, 아이디어, 생산력만 가지고 있는 소기업들의 고민인 유통을 해결해주고 싶기도 하다. 인재양성 측면에선, 실력있는 온라인MD를 업계에 계속 전문적으로 양성하는게 목표다. 솔직히 이 분야에 전문인재가 너무 없는 것 같다.   마지막으로 <물류와 경영> 독자들에게 인사말 한마디 부탁 한다.   유통의 절반이 물류라고 생각한다. 최근 유통이 진화하고 있는데 유통과 함께 물류가 동반 성장하길 진심으로 바란다.      원문 링크 #웹뜰 #인터뷰 #대표인터뷰 #해외브랜드 #브랜드관리 #온라인패션몰 #패션 #MD