과거의 오늘을 보여주는 한 SNS에서 5년전 내가 쓴 글을 만나게 되었다. 5년전 나는 출산을 3개월 정도 앞둔 임산부였고, 아프리카에서 돌아와 간신히 얻은 일자리를 포기한 경력중지상태였다. 글에는 당시 내가 느낀 불안함과 무기력함이 가득 담겨 있었다. 어떻게 잊을 수 있을까. 나는 그때의 내 마음이 너무나 또렷하게 기억이 난다. 아이를 만나는 것은 기대되는 일이고 축복임이 분명했지만, 내 마음 한 구석에는 ‘나는 이제 끝났어’ 라는 절망감이 늘 공존했었다.그렇게 출산 후 아이를 기르다가, 처음으로 용기를 내어 지원한 서류가 통과하여 면접을 보러 가던 날도 기억이 난다. 오랜만에 입은 정장 바지는 지퍼가 도무지 올라가지 않았고, 결국 수습할 수 없는 삐죽삐죽 잔디머리를 한 채로 면접을 보러 갔었다. 붙고 안 붙고를 떠나 그것은 나의 투쟁이고 오기였다. 아직 나는 살아있다는 외침임과 동시에, 지금이 아니여도 좋으니 언제라도 다시 용기를 내기 위한 예방주사 같은 도전이었다. 하지만 면접을 마치고 돌아오는 길에 나는 우울했다. 출산 후 아이를 키우는 동안 내가 얼마나 사회와 동떨어지게 되었는지를 온몸으로 느꼈기 때문이었다. 나는 확실히 긴장했고 위축되어 있었다. 누가 묻지도 않았지만, ‘사실 나는 아이를 키우는 엄마예요’ 라고 이야기를 해야 했던 것은 아니었을까 라는 생각도 들었다. 그 후로 꽤 오랜 시간, 나는 내가 가진 모든 능력이 모두 사라져 버린 것 만 같다는 생각에 몹시 큰 불안을 느꼈다.사실 한 회사를 운영하는 대표로 살고 있는 지금도, 여전히 나는 위축되는 마음을 종종 느끼곤 한다. 아이에게 예기치 못한 변수가 생길 때, 엄마이기에 어쩔 수 없는 시간의 제약을 느낄 때, 저녁에는 아이를 돌보느라 전화를 받을 수 없을 때.. 사회생활을 어렵게 하는 순간을 마주할 때 마다, 다른 보통의 사회생활을 하는 사람보다 항상 어딘가가 부족하다는 생각을 하게 된다.그런데 우리는 정말 엄마가 되면서 모든 능력이 멈추거나 사라지게 된걸까?  곰곰히 생각해보면 그렇지 않다. 과거의 내 모습을 생각해보면 오히려 지금의 나는 여러모로 깊고 넓어져있음을 느끼게 된다. 엄마라는 역할이 개발시킨 능력이 참 많다.이전에는 나와 다른 생각을 가진 사람을 수용하는 것이 참 힘들었지만 이제는 거의 다 견딜만하다는 생각이 든다. 아이의 울음소리 짜증소리 엄마미워 라는 그 땡깡을 하루에도 수십번 참아낼 만큼 인내력을 가지게 되었기 때문이다. 또 하루에도 수백번씩 무언가를 요구하는 아이를 키워내며 동시에 살림을 비롯한 여러 가지 일을 처리할 수 있는 멀티태스킹도 가능하게 되었다. 이전의 나는 다른 사람의 감정에 이렇게 까지 주의를 기울일 필요가 없었지만, 이제는  내 감정을 처리하려고 노력하는 것은 물론이고 아이에게 공감하고 민감해지려고 노력하게 되었다. 하기 싫으면 대충하거나 회피했던 내가 엄청난 책임감이 생겨, 아이 우는 소리에 벌떡벌떡 깨며, 졸린 눈을 비비며 아이를 돌보는 초능력도 갖게 되었다.그뿐인가? 아이를 키우며 어떤 어려운 일도 도망가지 않고 해결해보려고 노력하게 되었으며, 아이의 눈짓과 몸짓을 표정을 보며 왜 그렇게 하는지 눈치챌 만큼 엄청난 센스도 보유하게 되었다. 돌이켜 보면 엄마가 되기 전에는 도저히 할 수 없었던 많은 일들을 이제 나는 할 수 있게 되었다. 엄마로 살면서, 나는 이전보다 더 시간을 아끼며 집중하는 지혜를 갖게 되었다.그러고 보면, 엄마로 보낸 시간도 우리에겐 경력이다. 우리는 멈추지 않았고 사라지지 않았다. 아이를 돌보는 정신 없는 일상에서도 우리는 성장하는 방향으로 가고 있었다. 확실히 우리는 이전의 우리가 아닌 것이다. 우리가 엄마로 살면서 갈고 닦은 많은 능력은 엄마로서 뿐 만 아니라 어느 곳에서 어떤 일이든 할 수 있을 만큼 유용한 것이다. 회사라는 조직과 업무에 적응할 수 있는 기회와 용기가 우리에게 주어진다면, 조금만 가정과 일을 함께 해나갈 수 있는 환경이 주어진다면, 우리는 엄마경력기간 동안 갈고 닦은 모습을 발휘하며 일할 수 있을 것이다.나는 이제 엄마를 경력으로 부르기로 다짐했다. 아직은 사회가 엄마와 경력을 같은 선 위에 두지 않지만, 그렇게 부르고자 하는 작은 노력들은 반드시 필요하며 의미가 있다고 생각한다. 그리고 이러한 메시지를 만들어 가고자, 소셜벤처 몇 곳이 함께 엄마경력자인 여성들을 위한 프로젝트를 시작하려고 한다. 엄마라는 역할 안에 있는 나를 발견하게 하고 세상과 연결되는 과정을 만들어가며, 작지만 의미 있는 메시지를 사회에 전달해보고자 한다. 사소해 보이는 작은 움직임들이 모여, 엄마라는 역할을 바라보는 새로운 관점들이 모여 의미 있는 변화를 만들어가게 되길 기대해본다.#그로잉맘 #경단녀 #경력단절여성 #엄마도경력이다 #일하는엄마 #육아와일 #스타트업CEO #기업문화 #여성복지

안녕하세요, 비투링크의 소식을 전하는 미나 입니다 :)  어느 기업이나 '인재'가 중요하다고 말하지만, 특히 스타트업에서 구성원은 그 회사의 전부라 해도 과언이 아니라 생각합니다.'어떤 사람들이 함께 모여 어떤 가치를 가지고 일을 하는가?'가 회사의 정체성과 철학을 규정 합니다. 지금까지 파운더스 이야기만 전해드렸는데요, 비투링크에는 각자 개성이 뚜렷한 멋진 비투링커들이 있습니다!비투링크 (B2Link) 에 대해 궁금해하시는 분들을 위해 2017년부터 사내 이야기를 전해보려 합니다.그 속에 스며든 우리만의 가치와 비전을 많은 분들이 공감할 수 있기 바라며 :)비투링크에서는 매달 1명의 “이 달의 비투링커” 를 선정합니다!*여기서 이 달의 비투링커란? *     비투링크의 숨은 공신!! 드러나지는 않지만 (혹시 드러나도 할 수없음ㅋㅋ)  맡은 바 책임을 다하고, 비투링크를 위해 땀 흘리는 바로 당신!  당신의 소중한 땀과 눈물을 우리가 닦아줄게요 ♬♬[우리는 비투링커] 의 첫번째 주인공은 누구일까요? (궁금 궁금)2017년 1월의 비투링커 추천사: HJ 아무개님 :)2017년의 첫 [우리는 비투링커] 의 주인공은"You are my candy girl~~" Finance 팀 임지애 님 입니다 !!! 2017년 1월의 비투링커 임지애 님 ♥안녕하세요, 저는 비투링크 Shared Service Division 내 재무팀에서 전반적인 회계업무를 맡고 있는 임지애 입니다 :)처음에 '이 달의 비투링커' 소개영상에 제가 나올 때 오글거리면서도 너무 뿌듯하고 좋아서 얼굴 가리고 웃었어요! ㅋㅋ혹시 저 웃는거 보셨나요? 타운홀미팅이 끝나고, 다시 자리로 돌아갔는데 ㅋㅋ 혁진님 (CFO) 이 올해의 첫 비투링커가 된걸 축하한다고 해주셨는데, 괜히 더 뿌듯하고 어깨에 힘 바짝 들어가는거 있죠? ㅋㅋ 아무튼 저 너무 신났나요?기쁩니다 아주아주! :) 퇴근하고 혼자만의 시간을 많이 갖는 편이에요! 혼자 영화도 보러가고, 몸이 찌뿌둥 할 땐, 요가도 즐깁니다!요즘엔 집에서 저를 애타게 기다리는 호슴이 (애완용 고슴도치) 때문에 바로 집으로 갑니다 ㅋㅋ 제가 집에가면 막 뛰어나와요! (엄청 빠름)집에서 애완용 고슴도치 '호슴이' 를 키운다는 지애님 ㅋㅋㅋㅋ고슴고치 키우는 분은 저 정말 처음 봤습니다.... 근데 사진을 보니까 넘넘 귀여워요 ㅠㅠㅠ지애님의 애완 고슴도치 호슴이 ♥그리고, 모든 비투링커들은 개인 별명이 써있는 컵이 있습니다!지애님 컵엔 뭐가 써있나 봤더니.... 읭? '술 먹은 다음날' ? ㅋㅋㅋㅋ지애님 설명 좀 부탁 드립니다ㅋㅋ아..... 사람들이 다들 제 첫인상이 여성스럽고 얌전한 이미지라고 하더라구요. 물론 저 여성스럽습니다 ㅋㅋㅋ작년 5월에 전체 워크샵 때, 술을 마시고 춤을 춘 적이 있는데, 그때 제 반전 성격에 놀라신 분이 한 두분 아니라고들 하시더라구요. 그리고 원래 술마신 다음날엔 얼굴이 피곤해보이고, 아픈건 당연한거잖아요?!술 마신 다음날 제상태가 인상 깊으셨나봐요ㅋㅋ 그 때 이후로 제 별명이 이렇게 되버렸네요 ㅎㅎㅎㅎ 지애님 책상에 고스란히 올려져 있는 개인 컵 알고 보면, 반전 매력녀 :)제 피부가 많이 건조한 편이에요! 그래서 마스크팩을 즐겨하는데요. 비투링크에서는 분기별로 전직원 대상으로 패밀리세일을 해요 ㅋㅋ 그래서 그때 마스크팩을 종류별로 왕창 사서 씁니다. 또 주변 친구들한테 이거좋다고 써보라고 나눠주는 걸 좋아하구요! 요즘 꽂힌 브랜드는 단연 커먼랩스 '꿀타민 마스크팩' !! 정말 겨울철에 강추합니다 :) 저녁에 하고 자면, 아침까지 촉촉!올해 모든 비투링커가 각자 KPI를 달성하고, 목표매출액을 달성해 해외로 워크샵을 갔으면 하는 바램을.... 가져봅니다 ㅋㅋ사적으로는 , 올해는 꼭 가슴 설레이는 연애를 할겁니다 !!! ♥ 사랑꾼 !!!!! #비투링크 #팀원 #팀원소개 #팀원인터뷰 #인터뷰 #재무팀 #팀문화 #기업문화 #사내문화 #조직문화

할로윈! 다들 오늘만 사는 사람들 같아요  2018년 10월 31일 올해도 어김없이 할로윈데이가 돌아왔어요. 또 우리가 그냥 지나칠 수 없었죠 후후    [특명] 제비뽑기로 뽑은 코스튬 입고 하루 종일 일하기!       슈퍼 고퀄 아이템 대량 입고! 올해의 코스튬은 왓챠플레이에 있는 영화를 모티브로 선정했어요        두근두근 뭘 뽑게 될까요      옷을 입기 싫어하는 깍쟁이 백설공주      엘사 공주님은 넋이 나갔어요      뭐니뭐니해도 고객 안전이 제일이죠^^ – cs팀 담당자 (본인이 제일 위험해보여요)      음 승차감이 좋은걸   그렇게 한 바탕 소동이 지나간 후 우린 다시 일을 하기 시작했어요.      근데 아무것도 보이지 않아요       점심시간! 패기롭게 사무실 밖을 나섰어요.      혼란한 무리들.jpg    시선 강탈이었지만 우린 굴하지 않고 강남역 골목을 쏘다녔어요      밥먹어서_신남.gif    다들 정말 오늘만 사는 사람들 같았어요.    ?     우리 회사 최고 인싸님    뿅  할로윈도 최선을 다해서! 내년 할로윈은 어떨지 너무 기대돼요 >_<

Angular의 A마크를 알아본 프론트엔드 개발자님!이 글은 새로운 플랫폼을 개발하고 있는 타운컴퍼니 개발팀으로 당신을 모셔보려는 글이에요.이들이 당신과 함께 일하고 싶은 동료입니다..타운컴퍼니팀은 알고 있습니다.잘 만들어진 편리한 앱과 고객의 이탈률이 얼마나 밀접한 관계가 있는가를요.1%의 스타트업에는 1% 개발자가 필요하며 그들이 1%의 플랫폼을 만든다는 것을요.자율적이며 열정이 넘치는 팀으로 즐겁게 높은 수준의 개발을 할 수 있는 환경이죠!당신에게 즐거운 회사, 좋은 동료가 되어 줄 수 있습니다.급여는 협의 후 결정이니 원하는걸 말해봐요!좋은 동료를 얻을 수 있다면 그정도가 어렵겠어요 ; )우리는 현재 플랫폼(townus.co.kr)이 많이 부족하다는걸 알고 있어요.그래서 완전 멋있게 새롭게 만들고 있는 중입니다 :)일단 우리는 협업툴 JIRA와 Confluence, Slack을 사용하고 있어요.우리팀은 Agile 칸반을 바탕으로 테스트 주도 개발, 코드 리뷰, 페어프로그래밍으로 프로젝트를 진행하고 있죠.도메인이 잘 분석된 명세서가 Confluence에 정리되어 있고 사용자를 위한 깊은 고민이 녹아있는 디자인이 Zeplin에 올라가고 있어요.- Back-End는 Django(DRF) 기반으로 개발되고 있고, AWS, Vagrant, Docker같은 기술을 사용해요.- Front-End는 Angular 5를 사용해서 개발하고 있고, Less, RxJS, Webpack 등의 기술을 사용하고 있어요.Angular 상용 프로젝트 개발 경험이 있다면 격하게 환영하며 모십니다. 리엑티브 프로그래밍, Ionic 경험이 있다면 더 좋구요!엥 이거 완전 나 아니냐!? 라는 생각이 들었다구요? 그렇다면 얼른 지원해야지 뭐해요!무엇보다 개발을 즐기고 오픈소스활동을 좋아하는 사람이라면,종종 맛있는것도 먹으면서 많은 대화를 나눌수 있지 않을까요? :>우리 개발자는 맥주제조도 할 줄 알거든요 (겁나 맛이 좋더라구요)물론 당신에 대해 알 수 있는 Github 주소와 이력서를 보내준다면 우리가 연락하기 더 쉬울거에요!아! 참고로 보충역 산업기능요원 편입도 가능하니 문의가 필요하다면 언제든 환영이에요!타운컴퍼니팀에게 연락하고 싶다면 02–561–0950 잊지말아요,[email protected]로 메일 보내준다면 언제든 답변줄게요 :D#타운컴퍼니 #개발자 #채용 #팀빌딩 #조직문화

직장을 다니면서 혹시 이런 말을 접해 본 적이 있으신가요? ‘나 퇴사할 거야!’, ‘나 유튜브 시작할 거야!’. 이 두 가지 말은 몇 년 전까지 직장인 2대 허언이었는데요. 지금은 2대 허언이 바뀌지 않았을까 합니다. 링크드인 조사에 따르면, 밀레니엄 세대는 대학 졸업 후 32세 전까지 직업을 평균 2.85번 바꾼다고 해요. 평생직장의 개념이 퇴색하고 있고, 우수한 직원을 장기근속시키기 위해서 회사와 리더들에게 노력이 요구됨을 시사하고 있습니다."요즘 애들은 끈기가 없어! 라떼는 말이야."“요즘 애들은 끈기가 없어! 라떼는 말이야.”하지만 안타깝게도 기성세대들은 MZ세대의 배경을 이해하지 못한 채 불만을 토로합니다. 오늘은 MZ세대 팀원이 믿고 따르는 팀장, 리더의 조건을 알아보려 합니다. 밀레니얼 세대를 사로잡는 리더, 성과를 내는 리더가 되려면 어떻게 해야 할지 살펴보겠습니다.1. 진정성으로 신뢰를 얻는다.MZ세대는 가식적인 친절함보다 진정성 있는 리더를 원합니다. 진정성이란 말 그대로 마음에서 우러나는 참된 마음인데요. 팀장, 리더라고 하더라도 실수나 문제가 있을 때 슬쩍 넘어가는 게 아닌, 솔직하게 이야기하는 모습을 보여야 합니다. 예를 들어 진행하고 있던 업무가 무산되거나, 예정된 담당자가 변경되었다면 타당한 이유와 내용을 정확히 전달해야 합니다. 리더를 신뢰하는 직원은 안정감을 느끼게 된다고 하는데요. 팀장에 대한 신뢰도가 높은 직원일수록 위험을 감수하고 혁신적인 시도를 할 가능성이 높다고 하네요. MZ세대 팀원이 혁신적인 시도를 원하신다면 진정성 있게 대해주세요.2. 기회를 주고 인정한다.MZ세대는 수평적인 커뮤니케이션과 탈권위주의를 추구하는데요. 권위주의적 리더는 회사 정보나 권한, 목표를 독점할 때 생기게 됩니다. 팀장만 참여하는 회의가 있다면 일반 팀원에게도 회의 내용을 공유해 주세요. 모든 일을 알고 하는 것과 모르고 하는 일은 천지 땅 차이입니다.택시 기사가 되었다고 가정을 해보죠. 그리고 목적지를 알려주지 않는 손님이 탔다고 생각해 보세요. 갑자기 ‘우회전이요’, ‘좌회전이요’라고 말하는 불안한 상황. 택시 기사는 눈을 가리고 운전하는 것 같은 막막함을 느끼게 됩니다. 손님은 지름길로 갈 수 있었을 텐데 기회를 놓치거나, 갑작스러운 방향 전환으로 사고를 당할 수도 있죠.직원의 역량 강화를 위해 전체적인 맥락을 알려주시고, 업무의 기회를 주세요. 업무 기회가 없다면 MZ세대는 ‘이곳에서는 성장할 수 없겠구나’라는 생각을 하게 됩니다. MZ세대가 대기업을 퇴사하는 이유 중 하나는 기계 부품처럼 일하는 구조라고 하는데요. ‘언제까지 이거 해와’라는 업무 지시보다, 일의 목적과 취지, 맥락을 함께 설명해 주시는 게 좋습니다.3. 업무 환경을 개선한다.오픈서베이의 조사 결과에 의하면 3년 차 미만 또는 Z세대는 ‘메신저, 문자’를 통한 커뮤니케이션을 선호한다고 하는데요. 대면이 편한 베이비붐 세대와는 상반되는 결과입니다. 코로나19로 재택근무와 자율출퇴근제가 일상이 된 시대에 발맞춰 업무 환경을 개선해야 합니다.MZ세대는 청소년기부터 IT 기기와 인터넷, 스마트폰을 접했기 때문에 스마트한 환경에 익숙한데요. 업무를 할 때에도 여러 툴의 도움을 받아 일을 하죠. 기업용 업무 툴은 떨어져 있더라도 원활하게 커뮤니케이션을 할 수 있습니다. 채팅은 물론 화상회의도 가능하죠. 업무 관리 기능이 들어간 협업툴의 경우에는 모든 정보를 공유할 수 있어서 자연스럽게 수평적인 문화가 만들어지기도 하죠.  요즘 우리 사회에서는 일상 곳곳에서 세대 갈등을 마주하고 있습니다. 명절에 만난 친척 어른과 조카 사이에서, 회사의 부장과 신입 사원 사이에서, 지하철에서 만난 승객 사이에서도 서로의 입장을 생각하지 않아 갈등이 생깁니다. 자신이 보고 들은 경험만 강조한다면 이런 감정의 골은 점점 깊어지겠죠. 좋은 리더란 조직원 간의 갈등을 조성하기보다, 앞으로 조직을 이끌어 갈 세대를 명확히 이해하고 변화를 꾀하는 것. 직원을 배려하는 문화와 업무 환경을 구축하는 것이야말로 MZ세대 팀원을 지킬 수 있는 방법이 아닐까요.협업툴 플로우 바로가기

나의 진짜 썸도 부탁하는 누구냐 너.왠지 @miinzu고맙다 ㅋㅋㅋㅋㅋ...#카썸 #강남역 #역삼동 #여전히역삼동 #수연빌딩 #내빌딩이었으면 #이사 #회사이사 #사업장이전 #내사랑식물 #키울친구들이 #많아졌어요 #예쁘게키울게 #식물스타그램 #나무 #일스타그램 #CARSSUM #사무실풍경 #기업문화

React + Decorator + HOC = Fantastic!!지난 포스팅에서는 ES7의 Decorator 문법을 이용해 선언된 클래스와 그 프로퍼티들을 디자인 시간에 변경하는 법을 알아보았습니다. 그렇다면 리액트 컴포넌트와 Decorator가 만나면 어떤 시너지가 발생할까요?만약 ES7의 Decorator에 대해 모르신다면 지난 포스팅을 읽고 오시는 걸 권장합니다. 이 포스팅은 독자들이 Decorator에 대해 이미 알고 있다고 가정하고 작성됐습니다.Higher Order Component리액트 공식 문서를 보면 Higher Order Component(이하 HOC)를 다음과 같이 설명하고 있습니다.리액트 컴포넌트 로직을 재활용할 수 있는 고급 기법리액트에서 공식적으로 제공하는 API가 아니라 단순히 아키텍쳐이 설명으로는 HOC가 어떤 역할을 하는지 이해하기는 역부족이기 때문에 간단한 예제를 통해 HOC를 어떻게 작성하는지 알아보겠습니다.function withSay(WrappedComponent) {     return class extends React.Component {     say() {       return 'hello'     } render() {       return (                   {...this.props}           say={this.say} />       )     }   } } withSay 함수는 WrappedComponent를 인자로 받아 원하는 속성들을 결합해 새로운 컴포넌트를 반환합니다. 이렇게 만들어진 withSay 함수는 아래와 같이 사용 가능합니다.@withSay class withOutSay extends React.Component {     render() {     return (               {this.props.say()}           )   } } withOutSay 컴포넌트는 say 메소드를 가지고 있지 않습니다. 하지만 withSay 함수를 사용하니 say 메소드를 사용할 수 있게 됐습니다. 이처럼 컴포넌트를 인자로 받아 입맛에 맞게 바꾼 뒤 새로운 컴포넌트로 반환하는 기법을 HOC라고 부릅니다.그렇다면 HOC는 리액트에서 어떻게 사용을 해야 효율적일까요?Cross Cutting Concerns개발을 하다 보면 다음과 같은 상황에 직면하는 경우가 종종 있습니다.개발 전반에 걸쳐 반복해서 등장하는 로직그럼에도 불구하고 모듈화가 쉽지 않은 로직예를 들어 방명록 작성, 게시글 작성, 게시글 스크랩을 하는 컴포넌트들에서 유저 인증과 에러 처리의 과정이 필요하다고 했을 때 어떻게 코드를 디자인해야 할까요? 컴포넌트와 직접적으로 연관이 없는 기능들이 컴포넌트와의 결합이 너무 강해 쉽게 모듈화를 시키지 못합니다.그림 1. Cross Cutting Concerns의 예시이렇듯 코드 디자인적인 측면에서 공통적으로 발생하지만 쉽게 분리를 시키지 못하는 문제를 Cross Cutting Concerns라고 합니다. 이 문제를 끌어안고 가면 프로젝트의 코드는 쉽게 스파게티가 되고 나중에는 유지 보수를 하기 힘들어집니다.하지만 우리게에는 HOC와 Decorator가 있고 이를 이용해 이 문제를 쉽게 해결할 수 있습니다.유저 인증 문제를 HOC로 해결아래는 인증이 안된 유저에게 다른 페이지를 보여주는 코드입니다.class TeamChat extends React.Component {     constructor() {     super()     this.state = {       unAuthenticated: false     }   } componentWillMount() {     if (!this.props.user) {       this.setState({ unAuthenticated: true })     }   } render() {     if (this.state.unAuthenticated) {       return     }     return I'm TeamChat   } } 유저 인증을 전통적인 if-else 구문으로 구현했습니다. 당장 이 컴포넌트를 본다면 문제가 없어 보입니다. 어떻게 보면 정답처럼 보이기도 합니다. 하지만 유저 인증이 필요한 컴포넌트가 많아지면 상황이 달라집니다.100개의 컴포넌트에서 위와 같은 방식으로 유저 인증을 하고 있는데 유저 인증을 하는 로직이 변경된 상황을 생각해 봅시다. 100개의 컴포넌트 모두 유저 인증 코드를 바꿔야 하는 상황에 직면하게 됩니다. 전부 다 바꾸는 것도 일이지만 실수로 몇 개의 컴포넌트를 수정하지 않을 확률이 농후합니다. 당장에는 간단하지만 잠재적 위험을 안고 있는 위 코드는 아래와 같이 수정되어야 합니다.function mustToAuthenticated(WrappedComponent) {     return class extends React.Component {     constructor() {       super()       this.state = {         unAuthenticated: false       }      } componentWillMount() {       if (!this.props.user) {         this.setState({ unAuthenticated: true })       }     } render() {       if (this.state.unAuthenticated) {         return       }       return     }    } } HOC를 이용해 확장이 용이한 유저 인증 로직이 탄생했습니다!! 이렇게 만들어진 HOC는 아래와 같이 적용이 가능합니다.@mustToAuthenticated class TeamChat extends React.Component {     render() {     return I'm TeamChat   } } @mustToAuthenticated class UserChat extends React.Component {     render() {     return I'm UserChat   } } 기존의 코드와 비교했을 때 코드가 훨씬 간단해진 것을 확인할 수 있습니다. 비단 코드만 간단해진 것뿐만 아니라 아래와 같은 추가 효과를 기대할 수 있습니다.유저 인증 로직이 컴포넌트와 분리가 되어 자신이 맡은 역할에만 집중할 수 있습니다.유저 인증 로직이 바뀌어도 코드를 수정해야 할 곳은 하나의 컴포넌트뿐입니다.예시로 작성한 HOC는 최소한의 코드로만 작성된 예시입니다. 실제 제품에서 사용되기 위해서는 몇 가지 고려해야 할 사항이 있는데 이는 리액트 공식 문서를 참고해주세요.i18n 컴포넌트를 HOC로 작성채널 서비스는 한국어, 영어, 일본어를 지원하기 때문에 번역 기능이 필요했습니다. 초기에는 번역 서비스를 아래와 같이 구현했습니다.@connect(state => ({   locale: getLocale(state) }) class Channel extends React.Component {     render() {     const local = this.props.locale     const translate = TranslateService.get(locale)     return (               {translate.title}         {translate.description}           )   } } 처음에는 위와 같은 방식으로 번역 서비스를 구현하는 것이 괜찮았습니다. 하지만 번역을 제공해야 하는 컴포넌트가 많아지면 많아질수록 중복되는 코드가 많아지는 것을 보고 아래과 같이 HOC를 이용해 코드의 중복을 제거했습니다.function withTranslate(WrappedComponent) { @connect(state => ({     locale: getLocale(state)   }))   class DecoratedComponent extends React.Component {     render() {       const locale = this.props.locale       const translate = TranslateService.get(locale) return (                   {...this.props}           translate={translate} />       )    }   } } 이렇게 작성된 HOC는 아래와 같이 사용이 가능합니다.@withTranslate class Channel extends React.Component {     render() {     const translate = this.props.translate     return (               {translate.title}         {translate.description}           )   } } HOC의 작성 방법은 예시로 작성한 두 개의 HOC에서 크게 벗어나지 않습니다. 이를 응용해 자신의 프로젝트에 맞는 코드를 작성해보세요.중첩 가능한 HOCHOC는 여러 개를 중첩해서 사용할 수 있습니다.. 예를 들어 유저 인증과 i18n 서비스를 동시에 제공하고 싶을 때 두 HOC를 중첩해서 사용하면 됩니다.@mustToAuthenticated @withTranslate class Channel extends React.Component {     render() {     return (               {`Hello!! ${this.props.user.name}`         {translate.title}         {translate.description}           )   } } 마무리이상으로 리액트에서 HOC를 사용할 수 있는 상황과 작성 방법을 알아보았습니다. 본 포스팅에서 다루지는 않았지만 만능처럼 소개한 HOC에도 몇 가지 단점은 존재합니다.Component Unit Test를 할 때 문제가 있을 수 있습니다.HOC를 몇 개 중첩하면 디버깅이 힘들 수 있습니다.WrappedComponent에 직접적으로 ref를 달 수 없어 우회 방법을 사용해야 합니다.비동기 작업과 같이 사용하다 보면 예상치 못한 결과를 만날 수 있습니다.하지만 이러한 단점에도 불구하고 상속을 제공하지 않은 리액트에서 HOC는 많은 문제를 효율적으로 해결해주는 단비와 같은 존재입니다. 유명한 리액트 라이브러리들(react-redux, redux-form 등)은 이미 예전부터 HOC를 사용해 사용자들에게 편의를 제공해 왔습니다. 이러한 라이브러리들과 자신의 프로젝트가 직면하고 있는 문제에 맞는 HOC를 작성해 같이 사용한다면 우아하고 아름다운 설계에 한층 더 다가간 프로젝트를 발견할 수 있습니다.마지막으로 한 문장을 남기고 본 포스팅을 마치도록 하겠습니다.React + Decorator + HOC = Fantastic!!본 포스팅은 2017 리액트 서울에서 발표한 내용입니다. 발표 자료와 발표 영상을 확인해보세요.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지

초기에는 kube-aws가 만들어준 관리자 인증서를 통해 Kubernetes를 관리했는데 역시나 대내외적으로 여건이 바뀌니 변화가 필요했다. 내부적으로는 개발 인력이 늘고 여러 프로젝트가 동시 진행되니 Staging 환경이 급격히 바뀌는데 계정이 하나이니 누가 무슨 작업을 했는지 확인하기 어렵고 외부적으로는 경쟁사의 보안사고 등에 영향을 받아 보안을 강화할 필요가 생겼다. 하여 보안 관련 작업을 여럿했고 그 중 하나가 바로 GitHub와 Kubernetes를 OAuth로 엮는 일이다.기본적으로는 개발자 각자가 자신의 GitHub 계정으로 인증 토큰을 받고 이를 이용해 Kubernetes API에 접근하는 것이다. 전체적인 흐름은 How I built a Kubernetes cluster so my coworkers could deploy apps faster 등을 참고하면 이해하기 그리 어렵지 않다.1. Admin time should be saved (since they are also our developers)2. New users can generate their own credentials without needing the admin3. User credential is always private for security reasons4. Developers have their own space to experiment5. Project spaces can be accessed and changed by multiple users6. In the future, we may want to enable auditing to track changes다만 저들과 달리 Webhook 토큰 인증 플러그인을 직접 짜지 않고 coreos/dex를 이용했다. Dex를 이용하면 GitHub를 비롯해 다양한 OpenID, OAuth 2.0 인증 서비스와 Kubernetes 클러스터를 엮기 쉽다. 더욱이 kube-aws에 Dex가 통합되어서 설치하기도 쉽다.설치하기구구절절 어떻게 설정하는지 설명할 생각은 없는데 회사와 프로젝트에 따라 세부적인 차이가 꽤나 클 수 있기 때문이다. 그러니 대략적인 작업 순서를 간략히 기술하고 끝내려 한다.우선 kube-aws의 cluster.yaml를 보자.# # Enable dex integration - https://github.com/coreos/dex # # Configure OpenID Connect token authenticator plugin in Kubernetes API server. # # Notice: always use "https" for the "url", otherwise the Kubernetes API server will not start correctly. # # Please set selfSignedCa to false if you plan to expose dex service using a LoadBalancer or Ingress with certificates signed by a trusted CA. # dex: # enabled: true # url: "https://dex.example.com" # clientId: "example-app" # username: "email" # groups: "groups" # selfSignedCa: true # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. # connectors: # - type: github # id: github # name: GitHub # config: # clientId: "your_client_id" # clientSecret: "your_client_secret" # redirectURI: https://dex.example.com/callback # org: your_organization # # Configure static clients and users # staticClients: # - id: 'example-app' # redirectURIs: 'https://127.0.0.1:5555/callback' # name: 'Example App' # secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0' # # staticPasswords: # - email: "[email protected]" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. # hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" # username: "admin" # userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"우선 GitHub의 Organization Settings 메뉴로 가서 OAuth Apps에 Dex를 추가한다. 이때 Authorization calllback URL은 https://dex.example.com/callback가 된다.GitHub가 준 Client ID와 Client Secret를 cluster.yaml에 적어넣는다.dex: enabled: true url: "https://dex.example.com" clientId: "example-app" username: "email" groups: "groups" selfSignedCa: false # # # Dex connectors configuration. You can add configuration for the desired connectors suported by dex or # # skip this part if you don't plan to use any of them. Here is an example of GitHub connector. connectors: - type: github id: github name: GitHub config: clientId: "GITHUB_OAUTH_APP_CLIENT_ID" clientSecret: "GITHUB_OAUTH_APP_CLIENT_SECRET" redirectURI: https://dex.example.com/callback org: DailyHotel # # Configure static clients and users staticClients: - id: 'example-app' redirectURIs: 'https://kid.example.com/callback' name: 'Example App' secret: 'ZXhhbXBsZS1hcHAtc2VjcmV0'staticPasswords: - email: "[email protected]" # # bcrypt hash of the string "password". You can use bcrypt-tool from CoreOS to generate the passwords. hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W" username: "admin" userID: "08a8684b-db88-4b73-90a9-3cd1661f5466"여기서 dex.example.com은 kube-aws가 띄울 dex Deployment와 연결되는 서비스(ELB)의 도메인주소가 되어야 한다. 그런데 kube-aws는 Dex의 External service를 생성해주지 않으므로 아래와 같이 직접 서비스를 생성해야 한다. GitHub가 이쪽으로 콜백을 보내야 하므로 방화벽을 열어야 하고 회사 도메인 인증서를 붙일 것이므로 `selfSignedCa`값은 `false`로 한다.apiVersion: v1 kind: Service metadata: name: dex namespace: kube-system labels: app: dex component: identity dns: route53 annotations: domainName: dex.example.com service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: # the ports that this service should serve on - name: https port: 443 targetPort: 5556 protocol: TCP selector: app: dex component: identity type: LoadBalancer loadBalancerSourceRanges: - 0.0.0.0/0staticClients / example-app는 Dex에 포함된 예제 프로그램이다. 이를 이용하면 웹 브라우저를 통해 GitHub에 인증하고 토큰을 내려받을 수 있다. DailyHotel/kid 등의 도커 이미지를 사용하면 쉽게 띄울 수 있다. kube-aws는 이 예제 프로그램을 띄우지 않기 때문에 직접 올려야 한다.apiVersion: v1 kind: Service metadata: name: kid namespace: kube-system labels: app: kid dns: route53 annotations: domainName: "kid.example.com" service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:blahblah service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http service.beta.kubernetes.io/aws-load-balancer-ssl-ports: https spec: ports: - name: https port: 443 targetPort: 5555 protocol: TCP selector: app: kid type: LoadBalancer loadBalancerSourceRanges: - 사무실IP/32 --- apiVersion: extensions/v1beta1 kind: Deployment metadata: name: kid namespace: kube-system spec: replicas: 1 template: metadata: labels: app: kid spec: containers: - name: kid image: dailyhotel/kid:latest livenessProbe: tcpSocket: port: 5555 timeoutSeconds: 120 ports: - containerPort: 5555 env: - name: CLIENT_ID value: example-app - name: CLIENT_SECRET value: ZXhhbXBsZS1hcHAtc2VjcmV0 - name: ISSUER value: https://dex.example.com - name: LISTEN value: http://0.0.0.0:5555 - name: REDIRECT_URI value: https://kid.example.com/callback이때 example-app의 REDIRECT_URI는 Dex의 REDIRECT_URI와는 다르다는 점에 주목하자. 옵션의 이름이 비슷하기 때문에 헷갈릴 수 있다. 또한 CLIENT_ID와 CLIENT_SECRET은 cluster.yaml 중 GitHub connector 설정이 아닌 staticClients 설정에서 쓴 값이라는 점도 눈여겨볼 필요가 있다.이 정도만 주의하면 dex를 설치하고 설정하는 것은 어렵지 않다. 이제 인증하는 방법을 알아보자.인증하기웹브라우저로 kid에 방문해서 토큰을 받는다. 첫 화면에서 Login 버튼을 누른 후 GitHub 로그인을 하면 토큰이 나온다.GitHub Public profile 메뉴로 가서 Public email 설정을 확인한다. 공개 이메일이 없다면 하나 추가한다. 로그인시 사용자 아이디로 쓰기 위함이다.kubeconfig 파일을 열고 kubeconfig 파일을 열고 MY_PUBLIC_GITHUB_EMAIL에는 GitHub 공개 이메일 주소를 적고 VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN에는 앞서 받은 토큰을 적는다.apiVersion: v1 kind: Config clusters: - cluster: certificate-authority: credentials/ca.pem server: https://MY_KUBE_CLUSTER name: kube-aws-cluster contexts: - context: cluster: kube-aws-cluster namespace: default user: MY_PUBLIC_GITHUB_EMAIL name: kube-aws-context users: - name: MY_PUBLIC_GITHUB_EMAIL user: token: VISIT_KID_EXAMPLE_COM_AND_GET_TOKEN current-context: kube-aws-context인증 파일의 설정이 정확한지 확인하려면 kubectl --kubeconfig=./kubeconfig version을 실행해보자. 아래와 같이 Client/Server의 버전이 둘다 나오면 정상이다.$ kubectl --kubeconfig=./kubeconfig version Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.1", GitCommit:"b0b7a323cc5a4a2019b2e9520c21c7830b7f708e", GitTreeState:"clean", BuildDate:"2017-04-03T20:44:38Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"darwin/amd64"} Server Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.2+coreos.0", GitCommit:"79fee581ce4a35b7791fdd92e0fc97e02ef1d5c0", GitTreeState:"clean", BuildDate:"2017-04-19T23:13:34Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"}참고 자료johnw188/dex-exampleKubernetes / Authenticating#데일리 #데일리호텔 #개발 #개발자 #개발팀 #기술스택 #도입후기 #일지 #경험공유 #Kubernetes #Github

** 본 글은 문돌이 PM의 마케터 따라하기 시리즈 입니다.** 1화 보기 - 초기에 할만한 ASO (앱스토어 최적화) 팁모바일 앱 관련 분석지표, KPI같은걸 인터넷에 검색해 보면 ARPU, APPPU, ARPDAI, LTV 등등 무슨 코드 암호명같이 생긴 분석지표들에 대해 난해하게 설명하는 글들이 많다. 뭐, 물론 향후 매출을 일으키고 스케일이 나는 앱같은 경우 ARPU (사용자 당 평균 매출)을 모니터링 하는건 매우 중요하다고 한다. 하지만 나같이 초기에 매출도 없는 무료 SNS앱을 제로베이스에서 일구어나가야 하는 경우 저런 어려운 분석지표들을 공부하고 있으면 시간낭비다.본 글에서는 필자처럼 모바일 앱 세계의 완전 초보가 무료 앱을 완전 제로베이스에서 운영한다고 했을때 알아야 하는 모바일앱 지표 분석 방법론에 대해 설명하고자 한다. 본론에 들어가기 앞서, 모바일 앱의 다양한 지표를 트래킹 하기 위해서는 분석 툴이 필요한데, 이 툴에대해 소개하는것만 해도 한페이지가 소요되기 때문에 이건 다른 글들을 찾아보기 바란다. 여기서는 필자가 운영하는 바크 (Bark) 앱에서 사용중인 Fabric, 구글애널리틱스, 애플에서 기본 제공하는 아이튠즈 커넥트를 기준으로 설명하도록 하겠다.요즘 가장 핫한 분석툴 중 하나인 Fabric. 트위터에서 인수했다.우선 당신이 트래킹해야 하는 영역은 크게 다음 3가지가 있다.1. Acquisition (획득)2. Retention (유지)3. Referral (추천)1. Acquisition_ 새로운 사용자를 획득하기 위한 분석지표이 영역에서 가장 중요하게 트래킹 해야 하는 부분은 바로 '신규 유저가 어느 경로로 들어왔는가'를 집요하게 파는것이다. 초기에 코묻은 돈으로 발품 팔아가며 앱을 마케팅하고 있을 것인데, 내가 들이는 노력 만큼 신규 유저가 유입되고 있는지 체크하지 않으면 선택과 집중이 불가능하기 때문이다. 그렇다면 유저가 유입된 경로를 어떻게 추적하는가? 그건 바로 마케터가 베포하는 모든 URL에 추적 코드를 붙임으로써 가능하다. 크게 2가지 추적경로를 만들어야 하는데, 하나는 아이튠즈로 유입되는 추적코드, 하나는 웹사이트로 유입되는 추적코드 이다.아이튠즈로 유입되는 추적코드는 보통 다음과 같이 생겼다.https://itunes.apple.com/app/apple-store/id1100131438?pt=118117595&ct=Facebook-gangnamAd2&mt=8저기서 'ct='와 '&mt' 사이에 있는 'Facebook-gangnamAd2' 부분이 바로 추적코드 이다. 내가 만일 페이스북에 광고를 태우고 거기에 링크를 위와같이 만들어 놓으면, 그 링크를 클릭해서 아이튠즈로 유입되는 모든 트래픽은 'Facebook-gangnamAd2'라는 키워드가 기록되고, 아이튠즈 커넥트에서 저 키워드로 얼마나 유입이 됐는지 확인이 가능하다. (개발자한테 정기적으로 아래와 같이 생긴 키워드별 유입 숫자를 보여달라고 요청하자)아이튠즈 커넥트에서 Source 탭에서 확인 가능하다. (그냥 개발자한테 보여달라고 요청하자)그런데 여기서 두가지 발생하는 문제점이 있는데, 첫째는 저 링크가 너무 길어서 글 내에서 자리도 많이 차지하고 보기에도 지저분해 보인다는 것과, 둘째는 난 바로바로 결과를 알아야 하는데 아이튠즈 커넥트는 저 수치 업데이트가 보통 하루정도 지연된다는 것이다. 이를 말끔하게 해결하는 툴이 바로 구글에서 제공하는 URL Shortener 이다.저기 들어가서 URL을 goo.gl로 시작하는 아주 짧은 URL로 변경할 수 있고, 더 훌륭한 것은 간단한 통계 툴도 제공한다는 것이다. 아래 그림과 같이 실시간으로 현재 몇명이 이 링크를 클릭했고 (유니크클릭이다), 클릭이 발생한 채널이 어디인지 (페북이냐 웹이냐), 국가는 어디인지 등등의 결과를 실시간으로 확인 가능하다.구글의 URL줄이기 툴은 간단한 통계를 실시간으로 제공한다.이런식으로 모든 마케팅 컨텐츠의 URL에 추적코드를 붙여서 실시간으로 유입 결과를 확인하고 초기 반응이 좋으면 더 집중, 별로면 바로 내리거나 변경 등의 린한 초기 마케팅 활동이 가능해 진다.웹사이트로 유입되는 추적코드는 다음과 같이 생겼다.http://barkapp.co/?ref=Brunch여기서 '?ref=' 뒤에 있는 'Brunch' 부분이 추적코드이다. 이렇게 하면 내가 뿌려놓은 수많은 컨텐츠들에서 웹사이트로 유입된 유저들의 경로를 따로 추적 가능하다. 여기서 웹사이트로 유입된 유저들이 아이튠즈로 또 타고 들어갈 경우 저 추적코드를 유지하게 하는 것도 가능한데, 이건 개발자한테 물어보도록 하자.2. Retention_ 앱 내에서 유저가 얼마나 지속적으로 사용하는지를 관리하기리텐션은 신규유입보다 더 중요하다. 왜냐하면 신규유입이야 사실 마케팅 버짓과 밀접한 관계를 가지기 때문에 돈만 많으면 늘리는게 가능하다지만, 리텐션은 앱이 얼마나 퀄리티가 있느냐와 직결되는 문제이기 때문이다. 즉, 앱의 리텐션이 별로면 보통 다음 중 하나의 문제점을 가지고 있을 가능성이 크다.1. 앱이 추구하는 코어 가치를 제공하기에 기능적 완성도가 떨어진다.2. 유저가 느끼는 앱의 목적성이 모호하다.3. 코어 가치 자체가 가치가 없다.1번은 MVP로서 제공해야 하는 코어 기능들의 완성도가 떨어져서 유저가 불편을 겪거나 부족하다고 느끼는 경우이고, 2번은 유저가 이 앱을 왜 사용하는지 잘 모르는 경우이며, 3번은 그 앱이 제공하는 코어 가치 자체가 앱을 지속적으로 사용해야할 만큼 크리티컬하지 않은 경우를 의미한다.아무튼, 어떤 이유에서 리텐션이 떨어지는지를 분석하는건 소비자 리서치의 영역이기 때문에 여기서는 생략한다. (사실 필자도 잘 모른다) 다만 우리가 할 수 있는건 저 리텐션 수치와 관련된 가설을 수립하고 기능 추가, 수정 등을 통해서 끊임없이 테스트하고 결과적으로 봤더니 이 앱의 코어가치가 가치가 있네 없네를 따질 수 있다는 것이다.리텐션은 보통 다음 두가지 툴을 통해서 확인한다.첫번째는 아이튠즈 커넥트에서 기본적으로 제공하는 수치를 통해 확인하는데, 이렇게 생겼다. (역시 이것도 그냥 개발자한테 보여달라고 요청하자)아이튠즈 커넥트에서 제공하는 리텐션 차트이다. (역시 개발자에게 보여달라고 요청하자)위의 x축은 앱에 유입된 유저가 1일차에 얼마나 남아있는지, 2일차에는 또 얼마나 남아있는지...를 30일까지 보여주는 부분이고, y축은 그걸 날짜별로 보여주는 부분이다. 예를들어 위에서 5월 31일에 유입된 유저가 다음날 얼마나 남아있는지를 Day 1 리텐션이라 부르고 위의 표에서 58%가 그 숫자에 해당한다. 이 말은 처음 유입된 유저가 100명이라면 58명이 다음날 앱을 또 사용한 거다.하지만, 우리팀 개발자에 의하면 애플에서 트래킹하는 리텐션 수치의 정확도가 떨어지기 때문에 패브릭을 같이 봐줘야 한다고 한다. 패브릭에서는 Day1, Day7, Day30 리텐션만 그래프로 보여주는데 보통 숫자가 아이튠즈 커넥트 보다 낮다. 패브릭에서 Answers > MAU 섹션에 들어가면 하단에 나온다.패브릭에서 MAU 탭 하단에 보면 리텐션 차트가 나온다.패브릭에서 리텐션을 좀더 깊게 파는 방법이 있는데 뭐냐면, 일별로 앱 내에서 유저가 비활성 유저 - 낮은 활성 유저 - 중간 활성 유저 - 높은 활성 유저 사이를 왔다 갔다 하는 숫자를 보여주는 기능인데 이걸 매일 확인하면 이 앱의 리텐션이 죽어가는구나, 살고 있구나를 더 직관적으로 알 수 있다. 본 차트는 Answers > DAU 섹션 하단에 있다.일별로 유저의 활성도가 어떻게 움직이고 있는지를 패브릭에서 확인 가능하다.여기서 궁금한게, 내 앱의 리텐션 수치가 다른 앱과 비교해서 좋은지 나쁜지를 어떻게 아느냐인 건데, 이를 아주 자세하게 소개한 Andrew Chan의 블로그 글이 있으니 꼭 일독하길 바란다. 결과부터 얘기하면 Top 10 앱들은 보통 Day1 리텐션이 70%를 넘고, Day90까지 가도 반 이상이 살아있다.안드로이드 상위 탑 10, 50, 100, 5000 앱들의 평균 리텐션 추이3. Referral_ 유저가 내 앱을 얼마나 소문내고 다니는지 트래킹하기가장 어려운 부분이다. 내 앱을 사용하는 유저가 이 앱을 다른 사람에게 소개하는지를 어떻게 확인할까? 우리 앱에서는 앱 내에 아예 'Invite Friends' 버튼을 만들어 놓고, 여기에다가 유저 번호의 추적코드를 삽입해서 아이튠즈 커넥트에서 모니터링 하고 있다. 즉, 아래 버튼에 위의 아이튠즈 주소에서 추척코드 삽입하는 부분을 현재 유저 번호가 들어가게 해서 이 유저가 보내준 URL로 얼마나 신규 유저가 유입됐는지를 아이튠즈 커넥트에서 모니터링 하는 것이다. 바크 앱의 경우 한 유저가 20-30명씩 추천한 사람도 있다.추천하기 버튼에서 생성되는 URL에 유저 번호 추적코드를 삽입해 놓았다.지금까지 모바일 앱 세계의 완전 초보가 무료 앱을 완전 제로베이스에서 운영한다고 했을때 알아야 하는 모바일앱 지표 분석 방법론에 대해 알아보았다. 아마도 MAU니 DAU니, ARPU등의 이야기를 기대하고 온 분들은 실망하실수도 있는 얘기이지만 완전 제로베이스에서 시작하는 초기 앱의 경우 MAU같은거는 크게 의미가 없다. 이건 나중에 스케일을 키워서 얻어지는 결과값같은 거기 때문에 초기 부터 '아 우리앱의 DAU가 지금 100명이야, 어제는 50명이였는데 2배나 뛰었네..' 이런거 따지고 있는건 시간낭비라는 뜻이다. 그 보다는 위에 언급한 3개, 즉 Acquisition, Retention, Referral을 어떻게 모니터링하고 이를 초기 마케팅 활동에 반영해서 계속 린하게 튜닝해 나가느냐가 한 백배는 더 중요하다고 생각한다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기

앱 삭제수 분석이 중요한 이유모든 비즈니스에서 사용자 획득만큼 중요한 있다면, 기존의 고객들이 지속적으로 서비스/상품을 찾고 사용하도록 만드는 것입니다.특히, 모바일 앱 서비스의 경우 사용자가 손가락을 한번 움직이는 것만으로 스마트폰에서 앱을 삭제할 수 있기 때문에, 사용자 유지에 더욱 신경 써야 할 수 밖에 없습니다. 실제로 다수의 조사에서, 앱 설치 후 30일 내 90%가 넘는 사용자가 앱을 삭제하거나 사용하지 않는 것으로 나타났습니다. 만약 수백, 수천만원의 광고비를 들여 앱 설치수를 증가시켰는데, 대다수의 사용자가 한 달 뒤에 앱을 삭제한다면 앱 비즈니스 입장에서 큰 시간과 비용 낭비일 것입니다. (관련 포스팅: 앱재사용율(Retention)이 앱 설치수보다 중요한 이유)이 때문에 사용자가 지속적으로 앱을 사용하고 있는지 체크하고, 더 나아가 사용자가 우리 앱을 삭제하는 비율이 얼마나 되는지 파악해 해결방법을 찾는 것이 중요합니다.앱 삭제수를 분석하는 방법그렇다면 앱 삭제수는 어떻게 분석할 수 있을까요? 앱 삭제수 분석은 크게 Daily Ping Service 혹은 Silent Push Notification 방법으로 이루어집니다.와이즈트래커 분석 서비스의 경우, Android 는 Daily Ping Service 를 통해, iOS는 Silent Push Notification 방법으로 앱 삭제수 분석 데이터를 제공하고 있습니다. 아래 내용을 통해 와이즈트래커가 앱 삭제수를 분석하는 방법에 대해 자세하게 알아보도록 하겠습니다.ANDROID 앱 삭제수 분석 – DAILY PING SERVICEDaily Ping Service는 하루에 한번 앱에서 서버로 신호를 보내, 앱이 설치 되어있는지 삭제되었는지 분석하는 방법입니다. 각각의 사용자 앱은 고유의 식별코드를 가지고 있기 때문에, 특정 앱에서 신호가 오지 않는다면 해당 사용자는 앱을 삭제한 것으로 판단합니다.이러한 방법으로 앱 내 설치된 와이즈트래커 SDK는 하루에 한번 특정 시간에 서버로 알림을 보내고 서버에서는 알림이 오지 않은 사용자 앱들을 파악해, 앱 삭제수 데이터를 웹 대시보드로 보여줍니다. IOS 앱 삭제수 분석 – SILENT PUSH NOTIFICATIONSilent Push Notification이란 각 플랫폼의 푸시 메시지 전송 서버에 앱 사용자들에게 내용이 없는 (Silent) 푸시 메시지 전송을 요청해, 해당 서버로부터 앱을 삭제한 사용자에 대한 피드백을 받는 방식입니다.구체적으로, 와이즈트래커는 하루에 한번 Apple의 푸시메시지 전송 서버인 APNs (Apple Push Notification Service) 에게 앱 사용자들에게 Silent 푸시메시지를 전송하도록 요청합니다. 이 메시지는 내용이 없기 때문에 실제 사용자들에게는 팝업으로 나타나거나 보여지지 않습니다. Apple은 해당 메시지 전송 시, 앱을 삭제해 푸시 메시지를 받지 못한 디바이스들의 식별코드를 모아 와이즈트래커에 전달해줍니다. 이러한 정보를 바탕으로 와이즈트래커는 앱 삭제수 데이터를 파악해 보여줍니다. 앱 삭제수 분석의 정확성앱 삭제수 분석의 경우, 분석 방식의 특수성으로 인해 사용자가 앱을 삭제하지 않아도, 앱을 삭제한 것으로 처리되는 경우가 있습니다. 예를 들어, 와이즈트래커 SDK가 서버로 신호를 보내거나 APNs에 푸시메시지 전송을 요청한 시간에 해당 앱 사용자의 디바이스가 꺼져있거나, 네트워크 연결이 안되어 있다면 해당 사용자는 앱 삭제수에 포함됩니다.와이즈트래커는 앱 삭제수 분석의 정확성을 높이기 위해, 앱을 삭제한 것으로 간주된 사용자가 추후 지속적으로 사용하고 있는 것으로 파악될 경우, 기존 삭제수 데이터에 소급 적용해 업데이트 하고 있습니다.와이즈트래커 대시보드에서 앱 삭제수 파악하기실제 와이즈트래커 서비스에서 앱 삭제수는 다음과 같이 Retention 리포트에서 확인 가능합니다.각 날짜별로 앱을 설치한 사용자 그룹을 대상으로, 1일, 7일, 15일, 30일 뒤 앱 재사용수와 앱 삭제수를 Retention 리포트를 통해 한 눈에 파악할 수 있습니다. 위 서비스의 경우 앱 설치 하루 뒤에는 평균 47%, 30일 후에는 평균 67%의 앱 삭제율을 기록하고 있습니다.더 나아가 세그먼트 기능을 이용해 플랫폼, 성별, 연령대, 광고 채널 별로 나누어 앱 삭제수를 볼 수 있기 때문에, 어떤 특성의 그룹이 앱 삭제율이 높은지 파악할 수 있습니다.(페이스북 채널을 통해 앱을 설치한 사용자들의 앱 재사용/삭제수 리포트)또한 와이즈트래커는 앱 삭제 데이터를 더욱 가치 있게 활용할 수 있도록, 앱을 삭제한 사용자들을 타겟팅해 Re-acquisition 을 가능하게 하는 기능을 출시할 예정입니다.와이즈트래커의 앱 삭제수 분석 방법이나 앱 삭제수 리포트에 대해 더 궁금하신 분들은 [email protected]로 언제든 연락주세요! 앞으로도 와이즈트래커는 단순한 분석 데이터 제공을 넘어, 고객사가 데이터를 통해 인사이트를 얻고 지속적으로 성장하는데 도움이 되도록 노력하겠습니다.

한 번쯤 이 단어를 들어본 적이 있나요? 여러분이 '커뮤니티 매니저(Community Manager)'라는 단어를 들어본 적이 있다면, 이런 공간들을 알거나 방문해본 적도 있을 겁니다. 코워킹 스페이스(co-working space), 공유 공간, 협업 공간, 청년 공간, 마을 공간, 거점 공간 등등 다양한 이름과 형태를 가진 ‘커뮤니티 공간’을 말이죠. 다양한 커뮤니티 공간에서는 '커뮤니티 매니저'를 직업으로 하는 사람들을 만나볼 수 있다. ⓒ wework, 마이크임팩트스퀘어, 아트업서울, 무중력지대G밸리최근 몇 년 간 서울을 비롯한 전국 각지에는 다양한 형태의 ‘커뮤니티 공간’이 빠른 속도로 새롭게 만들어지고 있습니다. 이 흐름은 자연스럽게 공간 운영과 관리를 담당하는 사람들의 등장으로 이어집니다. 바로 ‘커뮤니티 매니저’라고 불리는 사람들이죠.  이들은 때론 공간을 넘나들며 다양한 활동과 문화를 만들어나가며, 커뮤니티 회복과 활성화, 사회적 가치 창출 등을 지향하기도 합니다.물론 각 공간/직무 등에 따라 이들에 관한 호칭은 다양합니다. 하지만 광범위하게 자주 쓰이는 것은 아무래도 ‘커뮤니티 매니저’인 듯합니다. (과연 그 단어가 적절한지 혹은 더 멋진 새로운 단어는 없을지에 대한 고민은 일단 차치하고) 그 낯설고 생소한 이름으로 활동하는 사람들이 ‘커뮤니티 공간’의 양적 확대와 더불어 많아지고 있습니다.    그런데 '커뮤니티 매니저'가 뭐하는 사람이죠?체인지메이커들을 위한 공유주택 '디웰하우스'에도 운영와 커뮤니티를 담당하는 '커뮤니티 매니저'가 있다.  ⓒ 루트임팩트‘커뮤니티 매니저’의 정확한 뜻은 무엇일까요? ‘커뮤니티 매니저’라고 하는 사람들은 구체적으로 무엇을 하고, 어떤 공통적인 특성을 가질까요? 실제로 얼마나 많은 ‘커뮤니티 매니저’들이 어떻게 일하고 있을까요? ‘커뮤니티 공간’과 ‘커뮤니티 매니저’는 또 어떤 관계가 있는 걸까요? 로모는 이제부터 ‘커뮤니티 매니저’와 관련된 여러 다양한 질문들을 던져보려 합니다. 그리고 그 질문의 답을 찾는 여정을 여러분과 함께 시작해보려고 합니다.왜 로모는 ‘커뮤니티 매니저’를 화두로 꺼냈을까요?       최근 연재를 시작한 <처음 만나는 커뮤니티 공간 디자인>에 이어, ‘커뮤니티 매니저’에 관한 이야기를 꺼낸 데에는 이유가 있습니다.그저 하나의 공간(a place)이 아니라 의미를 가진 공간(the place)이 되기 위해서는 다양한 요소들이 필요하다. ⓒ Tim Mossholder on Unsplash물리적 공간뿐만 아니라 그 공간의 정체성과 문화를 만들어가는 ‘사람’에 대한 이야기가 동시에 함께 이루어져야, 새롭게 조성되는 공간이 그저 하나의 공간이 아니라 다양한 사람들과 여러 비물질적인 가치들이 ‘공존’하는 유기적인 공간으로 기능할 수 있기 때문이죠.어쩌면 너무도 당연한 말로 들릴지 모르겠네요. 하지만 로모의 팀원들이 그동안 여러 지역에 수십 개의 커뮤니티 공간들이 조성/운영되는 과정에 직/간접적으로 참여해온 경험을 돌이켜보면, 꼭 그렇지만은 않습니다. 대부분 기획과 조성의 단계 이후 '운영'의 차원으로까지는 논의가 밀도 있게 이어지지 못합니다. 또한 운영주체와 인력의 문제 역시 '인건비 부담' 등을 이유로 크게 축소되어버리기 쉽고, 그나마 배치된 각 공간의 매니저들이 무엇을 어떻게 해야 하는가에 대한 이야기는 제대로 다루어지지 못한 채 "각자 알아서 눈치껏"의 수준에 머물고 맙니다. 실제로 로모의 팀원들이 지난 몇 년간 '커뮤니티 매니저'로 경험했던 현장도 크게 다르지 않습니다. '커뮤니티 매니저'의 정의와 역할은 불분명한 채, 아니 그보다도 "커뮤니티 매니저가 도대체 뭐길래?"라는 질문이 제대로 던져지거나 다뤄지지 못한 채, 일단 '커뮤니티 매니저'라는 이름으로 역할이 주어졌고 잘 수행해야 했습니다.  그렇다면 결국 의지할 곳은 현장뿐입니다. 맨 땅에 헤딩하듯이 때론 조심스럽게, 때론 과감하게 다양한 시도를 이어나가며 끊임없이 데이터를 축적해나갔고, 그 과정에서 소위 '커뮤니티 매니저'에 관한 우리만의 그림을 그려나갈 수밖에 없었습니다. 문제는 수많은 '커뮤니티 매니저'들이 유사한 상황에 처해있거나, 그럴 것이라 추측된다는 것입니다. 관련된 체계적인 교육이나 활용할 수 있는 자원, 서로의 경험과 노하우를 나눌 수 있는 네트워크도 부족하니까요. 결국 공간 운영의 경험과 노하우는 공유되거나 축적되지 못한 채, 커뮤니티 공간이 늘어나면 늘어날수록, 각 공간에서 다시금 '0'에서부터 시작하듯 고군분투하는 매니저들이 늘어날 뿐이죠.  결국은 ‘커뮤니티 공간의 질을 어떻게 높일까?’의 문제   그렇다면 '커뮤니티 매니저'가 해답이 될 수 있을까요?모든 문제를 손쉽게 해결할 수 있는 해답은 존재하지 않습니다. 단순한 결론은 때론 효과적일 수 있지만, 때론 중요한 맥락을 가려버리기도 합니다.‘커뮤니티 공간’이 잘 운영되기 위해서도, 다양한 요소들이 필요합니다. ‘하드웨어(hardware)’, ‘소프트웨어(software)’, ‘휴먼웨어(humanware)’, 이 세 가지 요소들이 각자 제 역할을 다 하며, 조화를 이루는 게 필수적입니다. (이 부분은 로모의 또 다른 브런치 매거진 <처음 만나는 커뮤니티 공간 디자인>에서 좀 더 자세히 전할 예정입니다.)그리고 그중 '휴먼웨어'가 꼭 ‘커뮤니티 매니저’에만 국한된 것도 아닙니다. 수많은 이용자들, 공간문화를 만들어나가는데 적극적으로 동참하는 소위 '단골'들, 유관된 다양한 협력 주체 및 기관들, 이들 모두가 공간의 질을 높이는 데 일정한 역할과 책임, 영향력을 행사합니다. 그래서 커뮤니티 공간은 특정 주체에 지나치게 의존하기보단, 커뮤니티 공간을 제대로 이해하는 다양한 주체들의 활동력과 네트워크에 기반하였을 경우보다 지속 가능할 수 있습니다. 다만 그럼에도 중요하고 분명한 사실은 현장에서 '커뮤니티 매니저'들이 '휴먼웨어'의 핵심을 차지하며, 공간의 '하드웨어'와 '소프트웨어'에도 강한 영향을 미친다는 점입니다. "설계자, 시공자, 운영자가 명확히 구분됐던 과거와 달리 최근에는 설계자, 시공자, 운영자의 간극이 좁아지는 사례가 증가하고 있다. 공간의 성패는 어쩌면 설계자보다 운영자가 쥐고 있는지도 모른다. 운영자의 취향과 캐릭터가 고스란히 반영된 공간을 조성하고 그 공간을 완성시키는 다양한 운영전략을 갖출 때 비로소 건축설계가 완성된다고 볼 수 있다" - 윤주원, 김주원, 김수정 공저 (건축도시공간연구소),  7쪽 中그래서 '커뮤니티 매니저'의 정의와 역할, 필수적인 역량이 무엇인지에 대한 문제들은 "각자 알아서 눈치껏"의 차원을 넘어서서, "커뮤니티 공간의 질을 어떻게 높일 수 있을까?"라는 질문 아래 구체화될 필요가 있습니다. 새로운 직업(군)으로서 커뮤니티 매니저  로모는 이제부터 새로운 직업(군)으로서 커뮤니티 매니저를 바라보고, 그에 대한 이야기를 본격적으로 꺼내보려 합니다. 커뮤니티 공간 안팎에서 벌어지는 A to Z를 발로 뛰며 해결하는 '커뮤니티 매니저'들을 하나의 직업군으로서 접근해야, 각 현장에서 개인들이 부딪히는 문제들과 그를 풀기 위한 각종 시행착오들이 흩어지지 않고 의미 있는 경험 자원으로 재해석될 수 있고, 각 공간 혹은 기관의 장벽을 넘어서서 우리 삶 속의 커뮤니티 공간의 질을 높이는 데 필요한 공유재가 될 수 있습니다. <커뮤니티 매니저가 뭐길래>, 앞으로의 이야기 로모의 새로운 프로젝트 <커뮤니티 매니저가 뭐길래>는 앞으로 구체적으로 이렇게 진행될 예정입니다. 먼저, 현재 일하고 있는 커뮤니티 매니저들의 현장성 있는 이야기들을 수집하고 기록할 것입니다. 여러 이야기 조각들을 짜 맞추어보면, "도대체 커뮤니티 매니저가 뭐길래?"라는 질문에 대한 윤곽이 나오겠죠. 그와 함께 현장의 실무자들이 주요하게 마주치는, 다르게 말하면 앞으로 풀어나가야 하는 구체적인 이슈들도 추려볼 수 있을 겁니다. 각자의 이야기가 모여, 함께 나눌 수 있는 서사가 되는 것이 기본이자 핵심이다 ⓒ Headway on Unsplash이야기들을 모은 다음에는, 이제 제대로 된 판을 만들어볼 차례입니다. 다양한 제안과 대안을 생산해내기 위한 담론장을 열어나갈 예정입니다. 커뮤니티 매니저들을 심층 인터뷰하며 발견한 주요 이슈들을 중심으로, 더 많은 커뮤니티 매니저들과 함께, 혹은 굳이 커뮤니티 매니저가 아니더라도 커뮤니티 공간 운영과 이번 프로젝트에 공감하는 사람들이 모두 모여 상상하고, 제안하고, 토론하는 자리도 열어보려 합니다. 그렇게 얼마간 함께 이야기를 하다 보면, 우리는 어쩌면 함께 발견할 수 있을지도 모릅니다. "커뮤니티 매니저가 뭐길래?"라는 질문의 끝에는, '커뮤니티 매니저'라는 애매모호하고 한정된 언어의 틀을 넘어서서, 우리의 고민들과 방향성을 더 적절히 담은, 더 멋지고 새로운 언어를 말이죠. 언어의 힘은 크니까요. 그 발견의 여정을 이제 시작합니다!  이번 편에서는 매거진 <커뮤니티 매니저가 뭐길래>를 왜 시작했는가에 대한 이야기를 중심으로 솔직하게 풀어보았습니다. 앞으로는 커뮤니티 매니저들의 인터뷰 내용을 바탕으로, 좀 더 구체적인 이야기들을 전할 예정입니다. 다음 편을 기대해주세요 :) 커뮤니티 매니저 심층 인터뷰에 참여해주세요! 서울에서 활동하고 있는 '커뮤니티 매니저'들의 이야기와 생각을 수집하고 있습니다.   인터뷰를 희망하시거나, 주변에 관련 일을 하고 있는 사람이 있다면, 아래 링크를 클릭해주세요! http://bit.ly/whoisacommunitymanagerBY 나무  CCO & Co-Founder다양한 삶의 방식과 공존 사례를 연구하고, 실험합니다. 루시드폴의 노랫말을 좋아합니다.   #로모 #기업문화 #조직문화 #사내문화 #기업소개

앞서 말씀드렸던 내용에 이어서 제품이 완성된 후에 이야기를 들려드리려고 합니다.제품을 구상하고 생산하기까지의 과정의 글은 링크로 삽입하니 참고 부탁드립니다!https://brunch.co.kr/@rr5ys5s/3시제품부터 양산 그리고 유통까지(1)태그솔루션 조명 브랜드 코스모블랑 생존기 | 하드웨어 기술창업에 관심을 가진건 2014년 6월부터였다. 사실 스타트업이라는 단어도 그때 인생에서 처음 들었던 것 같다. 그 후 2015년 1월 태그솔루션을 만들고 지금은 만 3년이 지나고 나 자신과 태그솔루션 모두 죽음의 고개를 넘어가고 있는 시점이다. 지금의 태그솔루션이 있기까지 나 자신의 무지함으로 겪은 어려움이 굉장히 많았고, 지금도 그 문제를brunch.co.kr/@rr5ys5s/3 https://brunch.co.kr/@rr5ys5s/4시제품부터 양산 그리고 유통까지(2)코스모블랑 양산 준비와 생산 시작 | 다시 돌아온 태그솔루션의 대표 박승환입니다. 제품의 양산 전 제품 구상부터 크라우드펀딩까지 과정을 1편에서 간략하게 설명드렸습니다. https://brunch.co.kr/@rr5ys5s/3 이번에는 좀 더 구체적으로 실제 양산의 프로세스에 대해서 말씀드리고, 그 과정에서 발생한 문제점들과 주의할 점에 대해서 공유를 하고자 합니다. 백문이불여일견 빠르게brunch.co.kr/@rr5ys5s/4 이제 실제로 생산 후에 우리가 했던 액션들에 대해서 구체적으로 적어보려고 합니다.실제로 양산한 조명의 수는 2000대로 현재는 900대 정도 재고가 남아있는 상황으로 약 3개월 동안 1100대의 코스모블랑을 판매할 수 있었습니다. 물론 와디즈 펀딩을 제외한다면 3개월 간 약 500대 정도를 판매했습니다.생각보다 판매가 부진했던 이유와 과정을 구체적으로 보기 이전에! 앞서 언급했던 내용을 간략하게 정리하고 넘어가겠습니다! 제품 생산 후 기본적으로 필요한 사항들(직접 생산을 안 하고 물건을 해외나 국내에서 받아와 대행 판매하시는 분들도 참고하셔도 좋을 것 같은 사항들)1) 제품 포워딩을 위한 물류업체 선정 2) A/S 및 소비자 정책결정 3) 제품 KC인증 ( 전자파 인증 )1. 물류 및 배송대행업체 선정많은 분들이 B2C의 단점을 많은 노동력을 필요로 하고 손이 많이 간다라고 평가한다.사실 백 프로 동의하진 않는다. 실제로 생산에서 배송까지는 회사만의 생산 및 배송 시스템과 정책만 규정하면 실제로 이 부분에서는 자체 노동력이 많이 들어가진 않는다. 단순히 판매자의 입장에서는 CS와 재고와 제품 관리 정도의 이슈만 존재하는 것이다. 실제로 B2C의 노동력이 투입되는 부분은 자체 판매 마케팅과 온오프라인 플랫폼에 입점하기 위한 영업과 관리 그리고 판매 이후의 CS에 대부분의 인력이 투입된다고 볼 수 있다. 국내 물류와 배송을 대행해주는 업체는 인천이나 파주 쪽에 많은 업체들이 분포해 있다. 업체 컨텍 역시 쉽게 구글링이나 지인을 통한 소개로 컨텍할 수 있다. 대부분 우리가 직접 배송 보내는 택배비용보다 저렴하므로 어느 정도 배송량이 갖춰진 상태에서는 꼭 물류 및 배송대행업체를 이용하는 걸 적극 추천한다. ( 택배상자와 포장방식에 대한 주문에 따라 가격은 조금씩 상이할 수 있습니다. 또한 물류량에 대한 기준이 업체별로 다를 수 있고 우리가 이용하는 업체의 경우에는 적은 양도 대응하는 아주 바람직한 물류업체입니다.  ) 사실 부피를 차지하는 제품의 물류창고와 배송을 동시에 해결한다는 가장 큰 장점이 있지만 관리나 오배송 등의 이슈는 발생할 수 있다. 이 부분의 경우 어느 정도 검증된 물류업체 ( 직접 눈으로 보고 시스템을 확인하는 게 좋습니다. )를 통해 진행한다면 그다지 큰 문제는 아니라고 생각된다."택배상자에 제품을 넣고 포장하고 운송장을 붙여서 택배기사에게 인계한다"를 "자동으로 주문정보를 넘기거나 메일로 주문정보에 대한 엑셀 파일만 전달한다"로 쉽게 관리가 가능해진다.물류업체에서 제공해주는 페이지위 이미지처럼 업체에서 제공해주는 물류를 관리하는 툴에 대한 권한이 주어지면 단순히 배송에 대한 내용과 현재 제품의 남은 재고 등을 파악할 수 있게 된다.2. 제품 KC 인증과 소비자정책 및 A/S국내 KC인증의 경우 생각보다 짧은 기간 내에 인증을 취득하는 것이 가능하다. 물론 인증의 종류에 따라 다르지만 대체적으로 많이 진행하는 전자파 인증의 경우 2주 이내에 대행업체를 통해 취득이 가능하다. 비용은 대략 100만 원 정도가 소요된다. (코스모블랑을 기준으로 설명드리기 때문에 금액과 기간은 다를 수 있다는 점을 양해 부탁드립니다.) 전기안전인증의 경우는 배터리를 사용하거나 저전력 제품인 경우 필요하지 않다. 자 판매를 위한 KC인증을 끝냈다. ( 물론 내부에 들어간 배터리의 경우 이미 KC 인증된 배터리를 활용했기 때문에 패스 ) 코스모블랑 전자파 인증서 일부자 이제 소비자를 위한 정책과 A/S의 기준을 정하도록 하자. 기준은 결국 보증기간이 가장 중요하다. 예를 들어 워런티를 1년 혹은 1달로 정하고 그 이후는 유상 수리 혹은 수리 불가 등 각 사업자의 환경에 맞게 정책을 확실하게 정하는 게 중요하다.우리는 1달 내 고장에 대해 워런티를 진행하였으며, 애초에 제품에 이상이 있을 경우 무상교환 그리고 사용 중 발생한 문제에 대해서는 (사용자의 부주의로 인한) 유상 A/S를 진행했다. 물론... 이 부분도 어려움이 있었다. 이유는 물류업체와 생산업체가 다른 곳에 위치하기 때문에 실제로 이 부분은 물류업체를 통하는 것이 아닌 생산업체에서 제품을 고쳐서 일반 택배로 보내주곤 했다. ( A/S 수가 적으니 가능한 방식이지만 그 수가 많아지면 분명 어지러운 상황이 발생할 수 있을 것이다.) 각종 판매 플랫폼에 입점하기 전에 이 부분이 정확하지 않으면 플랫폼 입점과 CS부분에서 어려움이 있을 수 있으니 명확한 기준을 정하자!드디어 워밍업은 끝나고 가장 중요한 판매가 남았다.판매를 위해 우리가 입점한 플랫폼을 단계별로 적어보았다.1단계 - 와디즈 ( https://www.wadiz.kr/ )2단계 - 카카오메이커스 ( https://makers.kakao.com/ ) 2.5단계 - 네이버스토어(자체몰), 게이즈샵(온오프라인) , 텐바이텐, 오늘의집, 펀샵, 아이디어스 등3단계 - 미미박스, 명동 면세점(오프라인), 화이트코튼(카카오선물하기)4단계(예정 및 계획) - 연예인 굿즈 제작 (미정....) 단계를 나눈 이유는 2단계까지는 해당 플랫폼에서 판매를 시작하면 일정기간 동안 외부 플랫폼에서 판매가 불가능하기 때문에 나눴으며, 각 플랫폼별 특징들에 대해서는 자세히는 적지 않으려고 한다. ( 잘못 적고 혼날 수도... 개인적으로 문의를 주시면 친절히 답변드리겠다. ) 결론부터 말씀드리면 판매는 입점이 전부가 아니다.입점을 하고 나서가 시작이다. 일반 사람들은 공통적으로 판매규모에 대한 오해를 굉장히 많이들 하신다.오프라인 매장에 입점했어? 백화점에 입점했어? 유명 플랫폼에 입점했어? " 너희 대박이구나! "라고 말해준다.하지만 판매를 한 번이라도 해본 사람은 입점이 전부가 아니라는 걸 알고 있을 것이다.우리는 실제로 위 플랫폼 중에서 몇몇 플랫폼에서 판매량이 최소 2개에서 10개도 안 되는 플랫폼도 존재한다. (물론 이 부분은 우리 제품의 가격이 비싸서이기도 하다... 뼈저리게 느끼고 있다... 슬프구나...)하지만 제품을 만들고 있는 분이나 판매를 예정이신 분이라면 플랫폼에 의존하기보다는 자체 채널을 통해 먼저 고객을 최대한 유치하는 것을 추천한다. 물론 안정적인 물량을 판매하고 있는 확실한 채널을 확보한다면 좋겠지만 실제 제품과 브랜드를 만들어서 판매하는 입장에서는 거의 불가능하다고 볼 수 있다. ( 장사를 하기 위해 중국에서 값싼 제품을 사 와서 재판매하는 건 가능할 수도 있다. )아 너무 말이 길어지고 있다...다음 화를 통해서 실제로 입점하기 위한 노력과 입점 후 전략그리고 자체 채널을 통해 판매하기 위한 노력, 오프라인 입점 결과에 대해서 구체적으로 적도록 하겠습니다.4번째 편이 메인이니깐 기대 많이 해주세요!아 참고로 우리의 본질은 코스모블랑이 아닙니다. 투명LED패널입니다.이 코스모블랑 다음 주제는 패널에 대한 내용으로 적도록 하겠습니다 :)To be continued...                                                                                     글쓴이 : 태그솔루션 박승환