스토리 홈

인터뷰

피드

뉴스

조회수 2333

왜 육각형인가요?

작년 중순 즈음, 데일리호텔의 로고가 새롭게 리뉴얼되었습니다. 기존에 '데일리호텔'이라는 명칭에 맞게 손바닥 위에 호텔의 아이콘이 올라가 있는 심벌 형태였는데요. 점차 사업의 방향이 더 넓게 확장되고, 데일리가 가져가고자 하는 기업 이념을 보여주고자 기존 형태에서 많이 변형된 현재의 로고가 탄생했습니다.로고 탄생 이후에 계속 듣던 질문. '왜 육각형인가요?'지금부터 그 이유와 심벌에 담긴 데일리만의 철학을 소개합니다.데일리가 가고자 하는 길로고를 제작하기 이전에 우리는 데일리가 걸어온 길이 어디였으며, 나아가고자 하는 방향이 어디인지 확립해야 했습니다. 많은 데이터와 고객 경험 사례들을 분석해본 결과 결국 데일리는 '특별함'에 초첨이 맞추어져 있다는 걸 알게 되었어요.또 위와 같이 정의된 키워드들을 가지고 브랜드 이미지를 시각적으로 표현하기 위해 아래와 같이 디자인 키워드와 표현 원칙을 정의하였습니다.'문'을 통해 '특별함'으로 다가가다데일리의 철학 '언제든 특별해질 수 있다'.그렇다면 그 '언제든'의 정의 또한 필요했습니다. 우리가 언제든 일상 속에서 만나는 동일한 패턴은 무엇일까를 생각하기 시작했어요.추출한 답은 '문'이었습니다.아침에 일어나 방문을 열고 거실에 나와 세면을 하기 위해 화장실 문을 통해 화장실에 들어가고, 현관문을 열고 회사로 향하는 패턴. 우리는 이와 같이 항상 동일한 문을 드나들고 있었습니다. 해서 데일리는 '언제든'을 '문(Door)'으로 정의하여 그 형태를 형상화시켜 쉐입을 제작하였습니다.'일상적인 문'을 뜻하는 쉐입그 반대에는, 일상적인 패턴에서 벗어나서 어디론가 떠나고 싶고, 멋있는 식사를 즐기고 싶어 하는(곧, 데일리가 추구하는) '특별함'을 나타내는 '문(Door)'의 쉐입을 제작하였어요.데일리가 지향하는 '호텔/레스토랑의 문'을 뜻하는 쉐입또한, 우리가 접하는 일상적인 문과, 특별함을 상징하는 호텔/레스토랑 문의 높이를 비교해보면 라이프스타일을 즐기기에 시간적, 금전적 부담을 느끼고 있기 때문에 쉽게 마을을 열지 못합니다. 여기서 데일리는 고객이 느끼는 부담적 마음의 문 높이를 채워줌으로써 라이프스타일에 한층 더 가까워질 수 있도록 조력자 역할을 해줍니다. 곧, 데일리의 미션인 '더 나은 하루, 더 나은 삶을 위해'를 이루기 위한 길이기도 하죠.이로써 견고해진 데일리의 심볼또 이렇게 제작된 심벌은 Connect, Precious, Perfect를 뜻하기도 합니다. 무슨 뜻이냐구요?하나_Connect. 잘 보시면 심벌이 모든 선으로 서로 이어져 있음을 볼 수 있습니다. 이는 고객들에게 특별한 경험을 연결 지어준다는 뜻을 지니고 있습니다.둘_Precious. 문을 형상화하여 심벌을 제작하였지만 완성된 형태를 보면 마치 보석과도 같습니다. 이는 사람들의 하루, 삶에 대해 소중히 여긴다는 뜻을 지니고 있습니다.셋_Perfect. 데일리의 심벌은 안정적인 구조를 지닐 수 있도록 견고한 선으로 균형 있게 제작되었습니다. 이런 심벌에서부터 나오는 완벽함은 탐색부터 예약, 그리고 경험까지 플랫폼으로써 추구하는 완벽함을 뜻합니다.마치며.이제 궁금증이 조금 풀리셨나요?우리는 하루에도 수십 번 많은 CI(Corporate Identity)들과 마주하게 됩니다. 어찌 보면 흔한 것일 수 있지만, 그 안에는 기업의 이념과 철학, 그 외의 많은 것들이 담겨있습니다. 그리고 그 CI가 품고 있는 뜻을 이루고자 지금도 이렇게 열심히 달리고 있는 거고요. 이제, 주위를 둘러보시면 많은 CI들이 각기 다른 미션/비전으로 아우성치고 있을 거예요.(ㅎㅎ) 그럼 다음에 더 재미있는 글로 찾아뵙겠습니다!작성자 : Creative팀 Blair Ahn#데일리 #디자인 #디자이너 #디자인팀 #로고 #로고디자인 #브랜드 #브랜딩 #인사이트 #후기 #일지
조회수 2224

평균 응답시간의 의미

어플리케이션 성능 분야에서 평균 응답 시간은 어플리케이션 서버가 사용자에게 요청 결과를 반환하는 데 걸리는 시간을 말합니다. 어플리케이션 서버의 응답시간은 일반적으로 밀리세컨드에 가깝지만 부하량에 따라 많은 시간이 걸리기도 합니다. 고객이 기다리는 시간 3초인터넷 초창기인 1999년 전자 상거래 사이트의 최적로드 시간은 8초 였습니다. 2006년도에 들어서는 4초까지 줄어들었습니다. 그리고 지금은 3초를 고객을 떠나게 만드는 시간으로 이야기 합니다. 구글 이 운영하는 더블클릭(https://www.doubleclickbygoogle.com/articles/mobile-speed-matters/)은 모바일 페이지가 로드되는데 3초가 지나면 사용자의 절반 이상이 서비스를 포기한다고 조사결과를 발표했습니다. 3초라는 시간 속에는 웹페이지의 렌더링 시간과 네트웍이 사용하는 시간등이 포함되어 있기 때문에 웹 어플리케이션이 소모해야 하는 시간은 실제로 밀리세컨드에 가깝습니다. 하지만 실제 서비스의 장애가 발생하면서 웹 어플리케이션의 평균 응답시간은 점점 길어지게 됩니다. 성능분석에서 평균 응답시간부하가 늘어나면서 임계치가 넘어가면 초당 처리량은 더이상 증가하지 않게 됩니다. 논리적으로 생각 해보면 초당 처리량이 더이상 증가하지 않은 상태에서 사용자만 늘어나면 TPS와 인지시간이 상수처럼 동작하므로 응답시간이 사용자에 비례하여 늘어나게 됩니다. [응답시간(Respons Time) = [동시사용자수 / 초당 요청수(TPS)] - 인지시간(Think Time)하지만 일반적인 상황에서 응답시간은 밀리세컨드 단위의 값이데 비해 인지시간은 3초에서 10초 이상의 값을 가지고 됩니다. 그럼 이번에는 성능을 분석하는 스토리를 만들어 보겠습니다. 우리가 영어 문장을 한글로 번역하는 웹 서비스를 만든다고 해 보겠습니다. 우리는 동시 사용자 100명을 예상하고 서비스를 만들고 있습니다. 여기서 서비스 특성상 사용자가 한번 번역을 요청하고 다음번 요청을 보내는데 평균 30초의 시간이 걸립니다. 마지막으로 최대 응답시간은 0.5초를 넘지 않도록 설계하려고 합니다. 이런 경우 우리가 목표로 하는 초당 요청수는 서비스를 동시에 사용하는 사람들의 요청을 시간으로 나누므로 계산식은 동시사용자수(100명)/(응답시간(0.5초) + 인지시간(30초)) 이고 결과값은 약 3.27이 됩니다.     초당 요청수(TPS) = 동시사용자수 / [응답시간(Respons Time) + 인지시간(Think Time)]이렇게 성능을 계산하는 과정에서 서비스의 처리시간 즉 응답시간은 인지시간에 비해 매우 적기 때문에 인지시간이 커지면 커질수록 TPS에 관여하는 비율이 0에 수렴하게 됩니다. 결론적으로 성능을 설계하는 시점에서 응답시간은 별로 중요한 이슈가 아니게 됩니다. 대신 인지시간이 중요해 집니다.인지시간(Think Time)이란?웹 서비스를 사용하는 사용자는 자신의 요청을 확인하는 시간이 필요합니다. 이렇게 이전 요청과 다음 요청 사이의 시간을 인지 시간이라고 합니다. 인지 시간은 사용자나 서비스 유형에 따라 다릅니다. 예를 들어 시스템 간 상호 작용은 사람이 관여하는 웹 서비스 상호작용에 비해 매우 낮은 인지 시간을 포함합니다. 또는 블로그 서비스에 비해 사전검색 서비스의 인지시간은 매우 짧을 것입니다. 서비스의 도메인을 분석하여 인지 시간을 결정하는 것은 매우 중요합니다. 인지시간을 사용하여 분당 완료해야 하는 요청 수는 물론 시스템에서 지원할 수 있는 동시 사용자 수를 계산할 수 있습니다. 튜닝 지표로서의 평균 응답시간현실에서 웹 서비스의 응답시간은 수식과 다르게 나타나게 됩니다. 그래서 많은 성능 분석 도구가 평균 응답시간을 보여주고 있습니다. 실제 성능 분석 도구들이 알려 주는 평균 응답시간은 수집 주기 동안에 수집된 트랜잭션의 응답 시간을 합산하여 평균한 값입니다.와탭의 서비스는 5초 간격으로 트랜잭션의 평균 응답시간을 계산합니다. 응답시간이 성능 지표보다 튜닝지표로서의 의미를 가집니다. 예를 들어 사용자가 적은 밤 시간에 배치잡과 같은 일부 응답시간이 길어짐으로써 사용자가 많은 낮보다 평균 응답시간이 더 길수도 있습니다. 하지만 실제 성능을 올리기 지표로써 응답시간은 매우 직접적입니다. TPS와 상관없이 평균 응답시간이 길어지는 요소가 있다면 주변 요소와 함께 평균 응답시간을 살펴봐야 합니다. #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 2011

[과거 스타트업 경험]2016년 상반기 실적 발표

저는 2013년 하반기부터 "사람은 곧 기업과 같은 유기체이다." 그리하여 "한 개인이 나 자신과 나 주위 생태계를 두고 기업처럼 생각하고 기업처럼 움직이면 위대한 기업을 일굴 수 있는 연습을 미리 할 수 있다."라고 생각을 하였습니다.그 당시 저의 롤모델 기업은 '구글'이였고 , 일단 구글이 하는 걸 사람이 하는 것처럼 따라해보자라고 생각을 하였습니다. 그래서 구글이 하는 사업과 프로젝트들을 CASE STUDY하고 그들이 관리하는 전사적 지표 OKR을 스스로한테 적용해보면서 정량적 분석을 시작했습니다. 그걸 -2013 하반기 부터 시작을 해서-2014 상반기-2014 하반기-2014(상반기+하반기)-2015 (상반기+하반기)기록하였습니다.그래서 2016년 또한 상반기 실적을 한번 분석해보고 전년도 대비 어떤 것들을 잘했고 못했는지를 판단해볼 생각입니다. 이를 통해 2016년 하반기는 더욱 전략적 한 분기를 보내어 더욱 성장할 수 있는 16년을 만들어보려고 합니다. 2x가 아닌 10x 을 목표로.[About startup]16년 1월에는 동동이라는 스타트업에서 마케팅부터 영업,기획 다양한 포지션에서 짧게 인턴을 생활을 하였습니다.이때 배웠던 것들, 업무를 했던 것들을 기록해놓았습니다.하나의 포지션에서 깊게 파고든 것이 아니기 때문에 업무에 대한 인사이트는 크지 않았습니다. 짧은 인턴동안 저는 보다 culture에 대해서 많이 배웠고, 여기에 대해 고민했던 시간이였던 것 같습니다. "어떻게 사람들을 회사의 문화로 동료들을사내 기업가가 되게할까?"16년 2월부터는 브리치라는 스타트업에 합류하게 됩니다. 2월 중순부터 ~ 3월까지는 패션 MD를 하면서 상품 등록 / 기획전들을 오픈하였습니다.사이트에 메인을 보면 맨 위에서 롤링되어 돌아가는 구좌들이 있는데, 여기를 메인 구좌라고 합니다.92volt 기획전,콘텐츠 포커싱소재/디테일 포커싱 여기에 들어갈 브랜드/샵을 정하고 상품을 정한 뒤 액셀에 콘텐츠를 기획하고 이것을 디자인쪽에 넘겨 커뮤니케이션 하면서 기획과 디자인의 fit을 맞춥니다.다 만들면 마케팅 쪽과 얘기해서 노출 스케줄을 잡습니다.스케줄 마감 기한은 협업을 하는데 있어서 매너라는 점,디자인은 예쁘게 보이게 시각화 하는 것이 아니라 사람들에게 직관적으로 메세지를 줄 수 있도록 로직을 시각화하는 것이라고 깨달았습니다.4월때부터는 조직 개편이 있으면서, 저는 상품쪽에서 -> 영업쪽으로 넘어왔습니다.(저는 영업이 천직인 것 같습니다.ㅋㅋㅋ) 이때부터 큰 퍼포먼스들을 내기 시작했습니다.제가 4월에 영업 78개, 5월에 6개, 6월은 45개,7월은 48개를 해서 4개월동안 177개를 했습니다.(5월에 급격히 갯수가 떨어진 것은 지마켓,11번가와 딜을 진행할 때 CS에 2주 투입이 되어서 영업을 거의 진행 못하였고 4월대비 6,7월달 영업 갯수가 떨어지는 것은 4월은 디자이너 온라인 영업을 진행했고 6,7월은 오프라인 매장 영업을 진행했기 때문입니다.5월에도 영업을 진행했으면 4개월 동안 한 200개는 만들었겠네요.제가 브리치 입사하기 전에 샵 DB가 150~200개정도 됬던 것 같습니다.)제가 브리치에 합류하게 되면서 영업의 속도와 양이 급격하게 변화했습니다. 그 이유는 '영업 채널'을 좀 더 효율적인 것에 투자를 했던 건데요.영업을 하기 위해 인스타 다이렉트 메세지를 활용했습니다.이를테면, 영업이라는 것도 PR하기 위해 기자들한테 메일 뿌리는 것과 흡사하다고 생각하는데요.업체 메일 주소를 리스트업 하고 한번에 제안서를 보내고 피드백이 오면 전화를 하고 미팅을 잡고 계약으로까지 이어지죠.이 방법을 중심으로 무언가 다른 영업 전략이 필요하다고 생각이 들었습니다.이렇게만 해서는 답장 올 때까지 기다려야되는 것도 있고, 움직이는 자투리 시간(출퇴근시간)에도 메일링은 하기 힘들죠. 이때 생각한 것은 "메세지 영업을 하자"가 된 것입니다.그래서 온라인쪽 디자이너 브랜드를 영업할 때에는 '인스타'채널을 활용하여 다이렉트로 영업을 했고 계약 전환율도 좋았고 모바일로 소싱하는 느낌이 꽤나 재밌었습니다. 그리고 인스타 오피셜에 보면 카톡 계정이 있는데, 카톡으로도 영업을 진행하였습니다. 좀 더 즉각적이고,실시간의 성격을 가진 채널을 활용해서 영업을 전개하니 속도가 굉장히 빨라졌습니다.인스타 다이렉트 영업 사진그리고 오프라인쪽 매장을 영업할 때에는 직접 로드에 가서 대표를 만나고, 혹은 위탁 판매 관련된 담당자를 만나서 얘기를 하는 식으로 진행되죠. 그래서 굉장히 영업 속도가 더딥니다.디자이너 브랜드에 비해 (오프라인으로 직접 가야되니깐요.) 더 빨리 소싱하기 위해선, 인스타처럼 소싱할 수 있는 채널이 필요한데, 그래서 네이버 '톡톡'을 활용하였습니다. 네이버도 저희와 비슷한 서비스인 스타일 윈도우를 운영하고 있습니다. 스타일윈도우는 오프라인 DB를 상당히 많이 보유하고 있고 저는 스타일 윈도우가 모아놓은 back data를 활용해서 효율적으로 영업을 전개합니다. 이때 스타일윈도우 혹은 스토어팜에서 고객과 샵이 소통하는 채널인 톡톡이 있는데요.저는 이것을 영업채널로 활용하였습니다. 즉 , 고객 채널을 영업 채널로 활용했던 것이죠.그래서 비약적인 갯수를 소싱할 수 있게 되었습니다.근데 제가 영업한 이 갯수들이 실질적으로 다 계약으로 전환된 건 아닙니다. 이 중에 몇 업체는 관리가 안되어 거래 진행이 안되고 있고(상품 등록), 몇 업체는 도중에 조건이 안맞아서 빠진다고 하고, 몇 업체는 입점시에 필요한 정보들의 준비가 안되고 있죠. 아마 이것들을 빼고나면 30~40개업체 정도가 빠질지 않을까 생각됩니다.그리고 제가 또 바꾼 변화로서는, 회사의 계약 문화를 아주 간편한 온라인 과정으로 바꿨는데요.이전에는 계약서 두 부를 뽑고 양쪽의 도장을 다 찍고, 두 부를 파트너사한테 보낸 다음, 파트너사가 한 부에 자기 도장을 찍고 그것을 다시 저희한테 보내는 복잡한 과정을 거쳤다면... (양쪽에서 우체국 등기로 일어나는 총 금전적 비용이 한 계약에 약 4~5천원 정도, 그러면 저는 약 140개정도 했다고 하면 140x5 = 70만원정도 절약) 현재는 모두싸인이라는 온라인 계약 서비스를 통해 간단한 회원가입을 하고, pdf 파일 계약서로 사이트에서 (모두싸인에서 1초만에 만든)도장을 찍고 메일로 주고 받는 걸로 진행하고 있습니다. 굉장히 많은 시간적 비용과 금전적 비용을 줄였고 영업 속도에도 굉장히 도움이 되었습니다.앞으로 남은 분기동안에는 영업 이외에 회사 문화가 어떻게 조직원들을 더 챌린지시키고, 동기부여시킬 수 있는 것들을 고민해보고 실제 도입해서 유의미한 결과를 가져올 수 있게 변화를 만들어낼 생각입니다.[About self-developement]블로그 글을 90개 포스팅을 하였습니다. 제 글중 현장에서 경험한 인사이트를 기록하는 공간인 '경험노트'에는 23개의 포스팅을 했습니다.전년도 대비 수치는 좀 떨어진 정도인데요.(작년도 하분기 포스팅이 약 150개) 경험의 질로 따졌을 때는 훨씬 수준이 올라와있는 정도입니다. 그리고 올해부터는 브런치 글쓰기를 조금씩 시작하기 시작했습니다. 이름하여.. O2O글쓰기인데, 글쓰는 형식은 크게 두 가지로 나눠서 쓰고 있습니다.제가 현장에서 경험하고 느낀 것들 + 제 생각을 더해 주제에 대해 좀 더 deep하게 들어가는 형식과 세미나 혹은 포럼에 참가하여 그 생생한 현장을 그대로 담는 글의 형식이죠.(여기도 조금 제 생각은 개입되구요.)에서 가장 공유가 많이 일어났던 글은 CS에 대한 글로 151개 공유수를 기록했고 에서 가장 공유가 많이 일어났던 글은 글로벌 패션 포럼에 대한 글로 182개를 기록하였습니다.글의 공유수가 획기적으로 늘어날 때는 아무래도 '인플루언서'가 제 글을 공유할 때 그렇다는 것을 확인하였습니다. 에서는 강하영님이 공유를 에서는 하정훈 이사님이 공유를 해주셨죠.제 브런치에 총 4개의 글이 실려있는데 총 공유수는 372입니다. 올해 목표는 한 포스팅이 500개 공유수를 넘길 수 있는 인사이트있는 글을 쓰는 것입니다.스타트업학회 CEO 페이스북 그룹그룹주소2016년 3월에는, 학교 과 선배와 학교 교육에 대한 문제점을 얘기나누고, 학생들의 잠재력이 발휘되지 못하는 점들을 얘기나누다가 , 이런 것들을 해결해줄 수 있는 학회가 있어야된다는 것에 목소리를 모았고, 그렇게 해서 스타트업을 연구하고 지식을 공유하고 실질적 경험을 해보는 CEO학회가 창립,첫 운영되었습니다.명지대에서는 스타트업(스타트업 바람을 넣는..ㅎㅎ?)이라는 조직을 만들고 활동을 하는 건 최초였습니다.저희는 매주 화요일 8시에 강의실에 모여 연구를 진행하였습니다.운영의 과정 속에서 느낀점은 1.사람이 살면서 혼자서 할 수 있는 위대한 일은 상당부분 제한된다는 점, 그래서 팀을 이뤄야한다는 것 2.조직을 하나의 통일된 비전 아래 모이게 하고 모두가 같은 방향을 바라보고 움직이게 하는 건 상당히 어렵다는 점 정도가 될 것 같습니다. 그리고 굉장히 뿌듯한 순간도 있었는데, 학회 인원 중 많은 도움을 받고 있다고 고맙다고 4명이 얘기해주었고 그 중 한명은 브리치에 파트타임으로 일하며 CS를 배우고 있고 그 중 한명은 WEPET에서 인턴을 하게 됩니다. 그리고 학회 친구들이 학교 '밖'으로 나가 스타트업 행사를 다니며 진짜 세계와 마주하고 있다는 사실입니다.저는 회사 다니면서 학회도 운영도 하고 커리큘럼도 기획하고, 정신이 없고 운영에 많이 미흡했지만 그 중 소수는 도움 받았고, 좋은 인사이트를 만들어가고 있다는 점이 기쁩니다.저는 이들이 더욱 성장해서 더 좋은 세상을 만들어가는데 일조할 것이라는 확실한 믿음이 있습니다.크게 스타트업,자기계발,학교를 주제로 상반기를 돌아보았습니다.제가 전년도에 부족했던 점은 (15년 글에 써놓았기를) 좀 더 빨리 실험해보고 실패하지 못했고,NO를 잘 못했고, 진짜 실력만 키우는데에 잘 집중못했다는 점입니다. 근데 이번해에는 사실 상당 부분 작년도 부족했던 부분들을 개선시켰습니다.그렇지만 빠른 실험과 빠른 실패에 대한 문제는 좀 더 잘해나가야 될 듯 합니다.이번 상반기에 가장 잘하지 못했고, 그리고 가장 중요하게 생각했던 것은 '지속성'에 대한 주제인데요. 뭔가 일을 하는데 있어서, (다짐을 했고,무엇인가 결과를 내야한다면) 지속하지 않으면 '가치'로 인정받을 수 없다는 점입니다. 아주 단순한 저의 삶 예시로는 운동이나 영어같은 것들을 들 수가 있겠네요.2016년의 하반기 목표는 운동과 영어는 정말 꾸준히 해나가고, 영업 이외에 마케팅 쪽에서 좀 더 퍼포먼스&실력을 기르면서 인재들이 최고의 역량을 뽐낼 수 있는 회사 문화를 만들어 가는 것에 집중할 생각입니다.그리고 아버지가 전기자재 도매쪽에서 사업을 오랫동안 해오셨는데, 현재는 디지털 변화에 대응하지 못하여 위기에 처해있습니다.그래서 이 부분에 대해서도 계속 고민해나가는 6개월을 보낼 것입니다.어떻게 보면 이것이 저의 인생의 최고의 기회일지도 모른다는 생각에..남은 하반기도 모두들 화이팅 하세요..!고객 만족을 위해 매일 매일 노력하는 대한민국 스타트업들 화이팅!#페오펫 #peopet #CEO #마인드셋 #경험공유 #인사이트
조회수 1980

2017 핫한 글로벌 스타트업 도시 TOP3 은?

불확실한 전망억만장자 도널드 트럼프의 미국 대통령 당선과 프랑스(4월 23일/5월 7일), 독일(10월 22일), 네덜란드 선거(3월 15일) 결과의 변수로 인해  글로벌 스타트업에 대한 미래가 불투명하다. 다양한 변수에도 불구하고 2017년 글로벌 스타트업 허브로 도약할 TOP 3의 도시는 어디일까? 1. 런던 영국 대표 스타트업 deliverooCBRE 리포트에 따르면 브렉시트(Brexit) 투표 결과에도 불구하고, 테크 기업들 사이에서 영국의 수도 런던은 유럽에서 가장 인기 있는 스타트업 도시로 선발됐다. 고공 성장을 하고 있는 영국 스타트업에 작년에만 무려 약 72억 파운드 (한화 약 10조)가 투자됐다.   참고 글: The 37 coolest startup CEOs in UK tech2. 파리 프랑스 대표 스타트업 blablacar세계에서 가장 큰 규모의 테크 인큐베이터 스테이션 F (Station F)가 4월 개소를 앞두고 있다. CBRE 리포트에 따르면 테크 스타트업 분야에서의 순위를 보면 파리는 런던과 버금간다.  또한 유니콘 기업으로 3500만 명 유저를 보유한 유럽 카풀 서비스 블라블라카(BlaBlaCar) 역시 파리에서 시작된 스타트업이다.        참고 글:  Startups worldwide can now apply to STATION F 3. 베를린 베를린 대표 스타트업 Sound cloud베를린에는 테크 관계자들이 손꼽는 스타트업들이 있다. 베를린에 본사를 둔 클루(Clue)는  최근 2000만 달러(한화 236억) 투자로 주목받고 있고, 베를린을 대표하는 스타트업에는 글로벌 온라인 유통 플랫폼 ‘사운드 클라우드(Sound cloud)’와 배달전문 기업 ‘딜리버리 히어로(Delivery Hero)’가 있다.         참고 글: 임정욱 스타트업얼라이언스 센터장 <나의 베를린 스타트업 답사기>    이미지 출처: 해당 홈페이지 스크린샷 & copyright cienpies design/ shutterstock.com #더팀스 #THETEAMS #스타트업 #TOP3 #글로벌스타트업 
조회수 772

앱 재사용율(Retention)이 앱 설치수보다 더 중요한 이유

사용자획득에 집중된 모바일 마케팅모바일앱 시장의 경쟁이 치열해지면서 새로운 사용자들을 유치하기 위한 마케팅 비용은 점차 상승하고 있습니다. 글로벌 조사에 따르면, CPI(Cost per Install) 광고 단가는 검색광고의 경우 평균 $8.63, SNS 플랫폼은 $5.84, 배너 및 비디오 채널은 $2.99로 한 명의 새로운 유저를 데려오기 위해 높은 비용이 든다는 것을 알 수 있습니다. (Souce : Singular)지금까지 대다수 모바일 마케팅의 성과 척도는 앱 사용자 획득에 있었기 때문에, 마케터들은 높은 단가에도 불구하고 광고를 통해 최대한 많은 사용자들이 앱을 설치하도록 만드는데 집중했습니다. (구글플레이 스토어의 앱인스톨 광고 )낮은 앱 재사용율(RETENTION), 이유는?하지만 여전히 저평가 되는 것은 앱을 설치한 대다수의 사용자들 중 지속적으로 앱을 사용하는 비율이 매우 낮다는 점입니다.Appboy의 2016년 글로벌 리포트에 따르면, 앱을 설치한 다음날 앱을 재사용하는 사용자 비율은 평균적으로 25% 보다 낮게 나타났습니다. 7일 뒤에 재사용율(Retention Rate)은 11%로 떨어졌고, 45일 뒤에는 5% 미만, 90일 뒤에는 4.1%를 기록했습니다.즉, 앱 설치형 광고를 통해 100명의 사람이 앱을 설치했다 하더라도, 그 중 다음날 앱을 재접속하는 사람은 25명 미만이고, 일주일 뒤에는 11명, 90일 뒤에는 오직 100명 중 4명만이 앱을 사용한다는 의미입니다.(Source; Appboy, Retention Report 2016)이와 같은 수치는 다른 조사에서도 유사하게 나타나고 있습니다. Quettra의 조사에 따르면, 평균적으로 앱 (안드로이드 기준) 을 설치한 다음날 77% 사용자가 앱을 떠나고, 30일 내에 90%, 90일 후에는 95%가 앱을 삭제하거나 더이상 방문하지 않는 것으로 나타났습니다.(Source; Quettra)실제 Wisetracker 를 이용하는 앱 서비스의 retention report를 보아도 위와 유사한 수치를 발견할 수 있습니다.(Source; Wisetracker의 retention report)이와 같이 낮은 Retention이 나타나는 이유는, 하루에도 수많은 앱들이 생겨나는 상황에서 사용자들은 다양한 앱을 테스트하는 동시에 1~3일의 짧은 시간 안에 그 서비스를 지속적으로 사용할지 그렇지 않을지를 결정하기 때문입니다.즉, 앱을 처음 방문했을때 사용자의 흥미를 끌지 못하면 다음날, 일주일, 3달 뒤에도 그가 앱을 지속적으로 사용할 확률은 매우 낮다고 볼 수 있습니다.앱 재사용율(RETENTION)을 높이기 위한 3가지 전략사용자가 앱에 처음 접속 시, 서비스를 쉽게 이해하고 매력적으로 느끼는지 파악합니다.앱 서비스의 회원가입 단계가 복잡하거나 UI/UX가 사용하기 어렵다면 서비스 이용을 포기할 확률이 높습니다. 앱을 설치한 사용자들이 회원가입 단계에서 이탈율은 얼마인지, 처음 사용자들의 페이지뷰, 체류시간은 얼마인지에 대한 데이터를 통해 처음 사용자들이 우리 서비스를 문제없이 사용하고 있는지 파악합니다. 만일 회원가입 특정 단계에서 이탈율이 높다거나 체류시간이 반복사용자에 대해 짧다면, 처음 사용자들이 우리 서비스를 어려워하거나 매력적으로 느끼지 못하고 있는 것이기 때문에 서비스 개선을 통해 Retention을 높여야 합니다.타겟팅 푸시메시지를 통해 사용자가 앱을 재방문하도록 유도합니다.푸시 메시지는 사용자가 앱을 재방문하도록 유도하는 효과적인 방법 중에 하나입니다. 푸시 메시지를 더욱 효과적으로 사용하기 위해서는 개개인에 맞춤화된 메시지 전달이 중요합니다. Wisetracker는 처음 방문자들의 데모그래픽 또는 방문행동 특성을 기반으로 ADID/IDFA를 추출해 각 그룹마다 타겟팅된 메시지를 보낼 수 있습니다.앱 사용자에게 개인 맞춤 리타겟팅 광고 및 콘텐츠를 보여줍니다.만약 커머스 앱을 다운받아 방문한 처음 사용자가 몇 개의 상품을 둘러본 뒤 앱을 종료했다면, 그에게 리타겟팅 광고를 통해 해당 상품을 다시 보여주는 것이 Retention을 높이는데 가장 효과적일 것입니다. 우리 서비스에 방문한 사용자들이 조회했던 콘텐츠 정보를 기반으로 리마켓팅 광고를 진행하거나, 해당 사용자가 앱에 접속 시 관련 콘텐츠를 보여줌으로써 Retention을 높일 수 있습니다.사용자 유지 > 사용자 획득기존 앱 마케팅 캠페인의 목표를 사용자 획득으로만 잡으셨다면 지금 앱 서비스의 Retention 리포트를 확인해 보시길 바랍니다. 하루가 지나고 30일이 지난 뒤 재사용율이 높지 않다면, 우리 비즈니스의 핵심 목표는 사용자 획득이 아닌 재사용율(retention) 을 높이고 앱 삭제율을 낮추는 것으로 나아가야 합니다. 2017년에는 Wisetracker를 통해 정확한 In-app 데이터를 분석하고, 앱 사용자들을 보다 깊게 이해함으로써 높은 Retention 을 달성할 수 있는 한 해가 되시길 바랍니다.
조회수 1292

[인스팅터스] 이브의 브랜드 전략팀을 소개합니다(with 데이터 분석가 N)

안녕하세요 :) EVE의 브랜드 전략팀(Brand Directing) 데이터 분석가 N입니다. 마케팅과 브랜딩 업무에서 데이터 분석을 맡아 진행중입니다.Q. 브랜드 전략팀이란 ? 저는 BD(Brand Directing)팀은 최전선에서 뛴다는 느낌이 강하다고 생각해요. 고객의 관점을 생각하는 경우가 많고 우리의 메시지가 잘 전달될 것인가, 제품이 좋은 고객경험을 만들 수 있을까에 대해 치열하게 고민하는 업무가 많아요. 사회적 가치를 추구하는 기업이면서 동시에 수익을 추구할지 구체적인 구상안과 전략을 수립하는 팀, 그와 관련한 업무 전반을 총괄하는 팀인 것 같아요. 다른 회사에서 흔히 말하는 마케팅을 총괄하는 팀인 만큼 크리에이티브한 역량, 미적 감각, 생각한 것을 언어로 풀어내는 감각, 논리적 분석을 하는 역량 등 다양한 역량을 가진 사람들이 모여있어요. 서로의 영역에서 각자가 지닌 전문성을 존중하고 적극적으로 도움, 피드백을 주려는 분위기의 팀입니다. Q. 브랜드 전략팀에서 어떤 업무를 하나요 ? 브랜드 전략 팀에서 '데이터 분석'이라는 직무의 스펙트럼은 정말 넓다고 생각해요. 정교한 모델링으로 예측 모형을 세우거나 프로그래밍으로 고객의 선호를 분석하는 일부터 각 마케팅 활동의 성과를 평가하거나 전략을 도출하는 일까지 포함하는 개념으로 많이들 사용한다고 생각해요. 그 중에서 현재 제가 담당하고 있는 업무는 고객데이터를 통해서 고객의 구매성향을 파악하거나 할인• 가격 재조정시의 수요 예측, 마케팅 기획안에 대해서 성과지표를 설정하는 일까지 데이터에 기반해 분석적 사고가 요구되는 업무 전반을 다루고 있다고 생각합니다. 퍼포먼스 마케팅을 포함하는 업무라고 말씀드릴 수 있을 것 같아요. 데이터 분석가 또는 퍼포먼스 마케터 업무에서 필요한 역량은 논리적 사고와 구조화 능력, 끈질김이라고 생각합니다. 데이터를 통해 얻어낸 인사이트를 연결하고 구조화, 고객의 행동이나 성과를 예측, 평가하는 가설을 수립하고 검증하는 과정에서 주관적 사고를 배제하고 정량적인 사실에 근거해 판단을 내릴 수 있어야 하기 때문입니다. 또한 가설수립과 검증 단계에서 피드백과 수정을 반복하는 것을 통해 끈질기게 발전을 위한 노력을 해야 합니다. 다른 의견을 가진 사람에게 억지 주장을 펴는 것이 아닌 자신의 완전한 논리로 설득하고 수긍하도록 만드는 과정은 많은 노력과 시간이 들지만 발전을 위해 필수적인 부분이기 때문입니다. 현재는 수요예측모델에 따라 가격설정을 진행하고 데이터 수집, 모델 수정작업과 광고 집행비용대비 최대의 성과를 내는 최적수준을 찾는 작업을 진행중입니다. Q. EVE에 지원하게 된 계기는 무엇인가요 ? 저는 독특한 경우라고 생각해요. 정책에 대한 양적 분석을 진행하는 전공 수업을 통해서 해당 직무에 관심을 갖게 되었고 지인에게 이브를 추천받아서 지원하게 되었습니다. 브랜드 자체에 대해서 매력을 느끼거나 가치에 공감해서 지원한 경우는 아니라는 점에서 특이한 경우라고 할 수 있겠네요. 그러나 임직원의 실력과 커리어 패스에 맞는 업무를 주도적으로 수행하고 거기서 인정받는 과정에서 만족을 느끼고 있습니다. 사회적 기업에서의 독특한 성장을 기대한다면 EVE는 참 매력적인 브랜드인 것 같아요.Q. 지원자에게 면접에 도움이 될 만한 TIP을 알려주세요 ! 보통 자기소개서에 많이 있는 꿈이 뭐냐, 자신이 바라는 5년 후의 모습이 무엇이냐 하는 질문에 대해 깊게 생각해보지는 않는다고 생각해요. 하지만 진지하게 자신의 미래를 고민하고 이브에서 일하면서 무엇을 얻고 싶은지 고민하고 오시면 좋을 것 같습니다. 어디에서나 자신이 하고싶은 업무가 무엇인지를 정확히 알고 있어야 회사와의 시너지가 크게 날 수 있으니까요! Q. 평소 취미나 업무 외 일상은 ? 제 직무는 끊임없이 스스로 공부해야만 자신의 역량을 기를 수 있다고 생각해요. 회사의 교육 지원프로그램의 도움을 받아 전문성을 기르기 위해 공부하고 있습니다. 아, 그리고 요새는 색감이 예쁜 옛날 영화들을 보는 재미에 빠져 있어요. 퇴근하고 시간이 많이 보장되어서 저녁에는 영화를 보는 것으로 힐링을 하곤 합니다. (데이터와 수열을 벗어나 예쁜 미디어의 세계로...)Q. 내가 꿈꾸는 Career Path는 ?데이터에 기반해서 미래에 대한 예측, 구체적이고 효과적인 전략을 세울 수 있는 역량이 있는 사람이 되고 싶다고 생각합니다. 실질적으로 미래에 얼마나 성장할 수 있을지, 가치를 가지게 될지에 대해 전망하고 그것을 달성시킬 수 있는 사람이 되고싶어요.Q. (정말 솔직하게) 회사의 장단점에 대해 말해주세요 ! 본인이 하고 싶은 업무와 프로젝트를 스스로 지정하고 창조하여 디벨롭을 거듭하고 이것이 곧바로 현업으로 이어질 수 있다는 점, 그 무한한 자율성과 시행범위가 회사의 큰 매력이라고 생각합니다. 그러나 이 말을 뒤집어서 말하면 업무에 있어서도 시행에 있어서도 체계를 스스로 세워야 한다는 것, 이에 따른 책임감과 노동력이 추가된다는 점을 단점으로 꼽고 싶네요. 많은 자유도와 그에 따른 책임 정도로 정리해볼 수 있을 것 같습니다.evecondoms.com☘️생식 건강을 가장 먼저 생각하기에, 자연을 닮은 제품을 지향하기에, 소비자의 권리와 기업의 양심을 잃지 않기에 - 그래서 EVE는 성인용품이 아닌섹슈얼 헬스케어(Sexual healthcare) 브랜드입니다. 이브에 대해 더 알아보고 싶으시다면 지금 이브의 홈페이지에 방문해보세요:)Click me!
조회수 1121

모바일웹 vs 모바일앱 장단점을 알아보자

모바일 채널을 구축할 때 웹으로 구현해야 할지 앱을 개발해야 할지 고민인 경우가 많습니다. 모바일웹과 모바일앱의 차이점을 알고 나면어 떤 것이 더 나을지 판단하는데 도움이 될 것이라 생각합니다.# 모바일웹과 모바일앱의 차이점우선 기술적인 관점에서 보면 모바일웹은 매우 대중적입니다. 많이 쓰이는 프로그래밍 언어인 PHP나 JavaScript로 제작하고, 수정과 관리가 편리한 HTML로 보여지며, 누구나 사용하는 웹 브라우저로 접근할 수 있습니다. 이 말을 쉽게 설명하면 충분한 수준의 개발자를 구하기 쉽고, 유지보수가 상대적으로 효율적이며, 유저가 사용하기 편리하다는 말입니다.모바일앱은 스마트폰 사용자의 경험(User Experience)에 최적화하기 좋은 방식입니다. 우선 플랫폼(Android, iOS 등)별 사용자의 특성에 따라 독특한 서비스를 구현할 수 있습니다. 그리고 웹 컨텐츠를 그대로 활용하거나(Hybrid), 인터넷 연결 없이도 이용 가능한 앱(Native)을 만들수도 있지요. 모바일웹과 모바일앱의 이런 차이로 인해 각각의 장점 역시 뚜렸하게 구분되는데, 대표적인 항목들을 살펴보도록 하겠습니다.#1 모바일 웹의 장점1) Immediacy (직접성)앱은 기본적으로 ‘설치’가 선행되어야 하는 반면 모바일웹은 모든 모바일 기기에서 빠르게 접근이 가능합니다.2) Compatibility (호환성)하나의 모바일 웹사이트는 수많은 종류의 모바일 기기와 유저가 접속할 수 있으며, 웹사이트 URL은 QR Code, SMS, NFC 등으로 쉽게 접근할 수 있습니다.3) Upgradability (업데이트 용이성)모바일웹은 컨텐츠나 디자인을 변경할 때 웹 표준에 맞춰 작업하면 되지만, 모바일앱은 OS별로 각각 수정해야 하며, 수정 이후에도 마켓의 정책 기준에 부합하지 못하면 등록이 거부될 수 있습니다.4) Findability (검색성)모바일웹을 열면 대부분의 경우 기본적으로 검색엔진이 나타나며, 사용자는 즉시 검색어를 입력해 자연스럽게 웹사이트로 접근할 수 있습니다. 그리고 각종 모바일 광고로도 노출이 가능하지요. 반면 앱의 경우 사용자의 주목을 이끌어내기 위해 막대한 광고비와 바이럴 효과를 만들어 내야 합니다.5) Time and Cost (투입 리소스)모바일웹은 모바일앱보다 더 적은 비용과 시간으로 개발 가능합니다. 그리고 상대적으로 수월한 유지보수 역시 모바일웹의 장점입니다. #2 모바일 앱의 장점1) Interactivity/Gaming (상호작용성, 특히 게임!)모바일 게임은 앱으로 구현하는 것이 최선입니다. 인터페이스 관점에서는 사용자의 다양한 터치 제스처에 유연하게 반응하며, 컴퓨팅 관점에서는 스마트폰의 하드웨어 스펙을 최대한으로 활용할 수 있기 때문입니다. 당연히 이는 사용자에게 높은 수준의  서비스 경험, 다시 말해 재미를 주게 됩니다.2) Personalization (개인화)개인별로 맞춤 컨텐츠를 제공하기 편리한데 주로 타겟팅 된 메시지(Push Notification)를 활용합니다. 이릴 통해 고객과의 실시간 소통과 이력 관리가 가능하다는 점에서 모바일앱의 가장 강력한 이점이기도 합니다.3) Performance (성능)웹보다 쉽고 빠르게 구동 가능하며 복잡한 계산와 리포트 등의 데이터를 처리하는 데 효과적입니다. 높은 성능과 보안이 요구되는 금융 서비스들이 앱을 선호하는 이융기도 합니다.4) Native Functionality or Processing (단말기의 기능 활용)단말기의 카메라, GPS 또는 각종 프로세싱 능력을 활용한 서비스를 제공하는 데에는 모바일앱이 훨씬 효과적입니다.5) No Connection Required (인터넷 없이 동작)네트워크 연결 없이도 기능들이 문제없이 작동할 수 있도록 개발이 가능합니다.종합해보면 모바일웹은 사용자의 접근성과 비용 효율성이 장점이라고 할 수 있으며, 모바일앱은 개인화와 높은 성능에 강점이 있습니다. “어느 것이 더 좋은가?”라는 접근방식 보다는 “무엇을, 어떤 목표를(Goal)를 달성할 것인가”와 같은 질문이 더욱 적합하고 할 수 있겠습니다.
조회수 4361

Flask로 만들어 보는 WSGI 어플리케이션

안녕하세요. 스포카 크리에이터팀 문성원입니다. 오늘은 WSGI(Web Server Gateway Interface)어플리케이션을 직접 작성해보고, 또 이런 작성을 보다 쉽게 도와주는 프레임워크 중 하나인 Flask에 대해서 알아보겠습니다.WSGIWSGI에 대해 기억이 가물하신 분들을 위해 지난 글의 일부를 잠깐 다시 살펴보죠.이 경우 uwsgi는 일종의 어플리케이션 컨테이너(Application Container)로 동작하게 됩니다. 적재한 어플리케이션을 실행만 시켜주는 역할이죠. 이러한 uwsgi에 적재할 어플리케이션(스포카 서버)에는 일종의 규격이 존재하는데, 이걸 WSGI라고 합니다.(정확히는 WSGI에 의해 정의된 어플리케이션을 돌릴 수 있게 설계된 컨테이너가 uwsgi라고 봐야겠지만요.) WSGI는 Python 표준(PEP-333)으로 HTTP를 통해 요청을 받아 응답하는 어플리케이션에 대한 명세로 이러한 명세를 만족시키는 클래스나 함수, (__call__을 통해 부를 수 있는)객체를 WSGI 어플리케이션이라고 합니다.글로는 감이 잘 안오신다구요? 그럼 코드를 보면서 같이 살펴봅시다. (모든 코드는 Python 2.7에서 테스트 되었습니다.)Hello World!def app(environ, start_response):    response_body = 'Hello World!'    status = '200 OK'    response_headers = [('Content-Type', 'text/plain'),                         ('Content-Length', str(len(response_body)))]    start_response(status, response_headers)        return [response_body]view rawgistfile1.py hosted with ❤ by GitHubapp은 일반적인 Python 함수지만, 동시에 WSGI 어플리케이션이기도 합니다. environ과 start_response를 받는 함수기 때문이죠.(PEP-333) 사실은 꼭 함수일 필요도 없습니다. 다음은 위의 app과 동일한 동작을 하는 WSGI 어플리케이션입니다.class App(object):    def __init__(self, environ, start_response):        self.environ = environ        self.start_response = start_response    def __iter__(self):        status = '200 OK'        response_body = "Hello World!"        response_headers = [('Content-Type', 'text/plain'),                            ('Content-Length', str(len(response_body)))]        self.start_response(status, response_headers)        yield response_bodyview rawgistfile1.py hosted with ❤ by GitHubApp는 Python 클래스(Class)로 environ과 start_response를 멤버 변수로 가지는데, 여기에는 약간의 트릭이 있습니다. 생성자(Constructor)인 App를 함수처럼 사용하게 하여 리턴되는 결과(실제로는 생성자를 통해 생성된 객체겠죠.)가 \_\_iter\_\_를 구현한 순회 가능한(Iterable) 값이 되게 하는 것이죠. (덤으로 이 객체는 발생자(Generator)를 돌려주게 됩니다.)그럼 이제 이 코드들을 실행하려면 어떻게 해야할까요? 그러려면 먼저 WSGI 규격에 맞게 어플리케이션을 실행시켜 줄 서버를 작성해야합니다. 하지만 다행히도 Python 2.5부터 제공되는 wsgiref.simple_server를 이용하면 간단히 테스트 해 볼 수 있습니다.(서버를 직접 작성하는 부분에 대해선 나중에 다루도록 하겠습니다.)from wsgiref.simple_server import make_serverhttpd = make_server('', 8000, app)httpd.serve_forever()view rawgistfile1.py hosted with ❤ by GitHub위 코드를 실행시킨 후에(당연히 app이나 App도 만들어져 있어야겠죠?) 웹 브라우져를 통해 localhost:8000으로 접속하면 작성한 어플리케이션의 동작을 확인할 수 있습니다.environ과 start_response테스트도 해봤으니 코드를 조금만 더 자세히 살펴봅시다. 함수 버젼의 app이나 클래스 버젼의 App모두 공통적으로 environ과 start\_response를 인자로 받아 요청을 처리하는 것을 확인할 수 있습니다. (당연한 이야기겠지만, 반드시 이름이 environ이나 start\_response일 필요는 없습니다만 편의상 이후 계속 environ과 start_response로 표기하겠습니다.)하나씩 살펴보자면, environ은 Python 딕셔너리(dictionary)로 HTTP 요청을 처리하는데 필요한 정보가 저장되어있습니다. HTTP 요청에 대한 정보는 물론, 운영체제(OS)나 WSGI 서버의 설정 등도 정의되어있지요. 다음 코드는 이러한 environ의 내용을 응답으로 주게끔 수정한 WSGI어플리케이션입니다.def dump_environ_app(environ, start_response):    response_body = "\n".join(["{0}: {1}".format(k, environ[k]) for k in environ.keys()])    status = '200 OK'    response_headers = [('Content-Type', 'text/plain'),                         ('Content-Length', str(len(response_body)))]    start_response(status, response_headers)        return [response_body]view rawgistfile1.py hosted with ❤ by GitHublocalhost:8000에 각종 쿼리 스트링(Query String)을 붙이거나, 브라우져를 바꿔가면서 확인해보면 출력되는 값이 바뀌는 것을 확인하실 수 있습니다.그럼 이제 start\_response를 한번 볼까요. start\_response는 일종의 콜백(Callback)으로 인터페이스는 다음과 같습니다. start_response(status, response_headers, exc_info=None) 실제 서버에서 어플리케이션으로부터 응답(Response)의 상태(Status)와 헤더(Header), 그리고 예외(Exception)의 유무를 확인받아 실행하게 되는데, status와 response_headers는 HTTP 응답 명세에 근거하여 작성하게 됩니다.Middleware지금까지 우리는 어떻게 WSGI 어플리케이션을 작성하는지에 대해 살펴봤습니다. 요청을 받아 처리하는 HTTP의 기본 기능에 충실한 어플리케이션이었죠. 그런데 일반적으로 우리가 작성하는 웹 어플리케이션에서 주로 다루게 되는 쿠키(Cookie), 세션(Session)에 대해서는 어떻게 처리해야 좋을까요? WSGI 명세에는 이러한 내용을 직접적으로 다루고 있지 않습니다. WSGI 자체는 서버나 프레임워크 자체가 아니라 서버가 어플리케이션과 통신하는 명세를 다루고 있기 때문이죠. 따라서 이러한 기능은 작성자가 직접 이를 구현해야 합니다. 그런데 이런 구현을 어플리케이션을 작성할때마다 하는건 너무 번거로운 일입니다. 그것보다는 이미 작성한 어플리케이션을 확장하는 것이 간단하겠지요. 이러한 확장을 위해 필요한 것이 WSGI 미들웨어(Middleware)입니다.미들웨어는 어플리케이션을 처리하기 전후의 처리나 environ의 추가등을 통해 작성된 어플리케이션을 확장할 수 있습니다. 다음은 쿼리 스트링의 \_\_method\_\_에 따라 HTTP 메소드(Method)를 임의로 변경하는 처리를 도와주는 간단한 미들웨어입니다.from werkzeug import url_decodeclass MethodRewriteMiddleware(object):    """        app = MethodRewriteMiddleware(app)    """    def __init__(self, app, input_name = '__method__'):        self.app = app        self.input_name = input_name    def __call__(self, environ, start_response):        if self.input_name in environ.get('QUERY_STRING', ''):            args = url_decode(environ['QUERY_STRING'])            method = args.get(self.input_name)            if method:                method = method.encode('ascii', 'replace')                environ['REQUEST_METHOD'] = method        return self.app(environ, start_response)view rawgistfile1.py hosted with ❤ by GitHubMethodRewriteMiddleware는 \_\_call\_\_를 통해 app을 대체하게 됩니다. (데코레이터(Decorator)가 생각나셨다면 정확한 이해십니다.)Flask미들웨어를 통해 어플리케이션을 확장하는 방법까지 알아봤습니다. 그러나 이것만 가지고 웹 어플리케이션을 만들기에는 아직 귀찮은 부분이 많이 남아있습니다. 각종 파라미터를 처리하기 위해서는 environ를 일일히 뒤져야하며, 요청에 대한 응답으로 전달할 HTML도 일일히 문자열로 적어야하죠. 이런 여러가지 불편함을 해결하기 위해 알아볼 것이 WSGI 마이크로프레임워크를 자처하는 Flask입니다. Flask는 WSGI 라이브러리인 Werkzeug를 만들기도 한 Armin Ronacher가 만든 프레임워크로 “마이크로”라는 수식어에 어울리게 아주 핵심적인 부분만을 구현하고 있지만, 유연하게 확장이 가능하게 설계된 것이 특징입니다.다시 한번 Hello World!우선 Flask를 시스템에 설치해야하는데, pip가 설치되어있다면 pip install flask로 설치 가능합니다.(환경에 따라 루트(root)권한이 필요할 수도 있습니다.) easy_install의 경우도 마찬가지로 easy\_install flask로 설치 가능합니다.설치가 완료되었으면 다음과 같이 아주 간단한 어플리케이션을 작성해봅시다.from flask import Flaskapp = Flask(__name__)@app.route("/")def hello():    return "Hello World!"if __name__ == "__main__":    app.run()view rawgistfile1.py hosted with ❤ by GitHubFlask(정확히는 Werkzeug)는 테스트를 위해 간단한 WSGI 서버를 자체 내장하고 있기 때문에 app.run을 통해 어플리케이션을 직접 실행할 수 있습니다.Route이번에 작성한 Flask 어플리케이션에는 이전까지 보지 못하던 개념이 들어 있습니다. app.route가 바로 그것인데요. 이 메서드는 URL 규칙을 받아 해당하는 규칙의 URL로 요청이 들어온 경우 등록한 함수를 실행하게끔 설정합니다. 위의 Hello World! 예제 같은 경우엔 “/”가 해당되겠지요. 또한 이런 규칙을 URL로 부터 변수도 넘겨 받을 수 있습니다.# http://flask.pocoo.org/docs/api/#[email protected]('/')def index():    [email protected]('/')def show_user(username):    [email protected]('/post/')def show_post(post_id):    passview rawgistfile1.py hosted with ❤ by GitHub이렇게 URL을 통해 처리할 핸들러를 찾는 것을 일반적으로 URL 라우팅(Routing)이라고 합니다. 이런 URL 라우팅에서 중요한 기능 중 하나가 핸들러에서 해당하는 URL을 생성하는 기능인데, Flask는 이를 url_for 메서드를 통해 지원합니다[email protected]('/')def index():    return ""@app.route('/')def show_user(username):    return [email protected]('/post/')def show_post(post_id):    return str(post_id)from flask import [email protected]("/routes")def routes():    return "".join([            url_for("index"),            url_for("show_user", username="longfin"),            url_for("show_post", post_id=3)            ])view rawgistfile1.py hosted with ❤ by GitHub보다 자세한 사항은 API 문서를 참고하실 수 있습니다.Template여태까지 우리는 요청에 대한 응답으로 단순한 문자열을 사용했습니다. 하지만 일반적인 웹 어플리케이션의 응답은 대부분이 그것보다 훨씬 복잡하지요. 이를 보다 쉽게 작성할 수 있게끔 도와주는 것이 바로 Flask의 템플릿(Template)입니다. Flask는 기본 템플릿 엔진으로 (역시 Armin Ronacher가 작성한)Jinja2를 사용합니다.기본적으로 템플릿엔진은 별도의 규칙(여기서는 Jinja2)에 맞게 작성된 템플릿 파일을 읽어 환경(Context)에 맞게 적용한 결과물을 돌려주는데 이 과정을 Flask에서는 render_template()가 담당하고 있습니다. 다음 코드는 hello.html이라는 템플릿 파일을 읽어서 이름을 적용한 뒤에 돌려주는 코드입니다.# from http://flask.pocoo.org/docs/quickstart/#rendering-templatesfrom flask import [email protected]('/hello/')@app.route('/hello/')def hello(name=None):    return render_template('hello.html', name=name)view rawgistfile1.py hosted with ❤ by GitHub쉽게 작성할 수 있게 도와준다고 해도, 템플릿 역시 나름의 학습을 필요로 합니다. 자세한 사항은 Jinja2의 API 문서를 참고하시기 바랍니다.RequestHTTP 요청을 다루기 위해서 때로는 environ의 내용은 너무 원시적일때가 있습니다. HTML 폼(Form)으로부터 입력받는 값이 좋은 예인데요. Flask에서는 request라는 객체(역시 Werkzeug에서 가져다가쓰는 거지만요)를 통해 이를 보다 다루기 쉽게 해줍니다. 다음은 HTML 폼으로부터 입력받은 message라는 값을 뒤집어서 출력하는 코드입니다.from flask import [email protected]("/reverse")def reverse():    message = request.values["message"]    return "".join(reversed(message))view rawgistfile1.py hosted with ❤ by GitHubSession로그인등으로 대표되는 요청간의 상태를 유지해야하는 처리에 흔히 세션(Session)을 사용하실 겁니다. Flask에서는 session객체를 지원합니다.# from http://flask.pocoo.org/docs/quickstart/#sessionsfrom flask import Flask, session, redirect, url_for, escape, requestapp = Flask(__name__)@app.route('/')def index():    if 'username' in session:        return 'Logged in as %s' % escape(session['username'])    return 'You are not logged in'@app.route('/login', methods=['GET', 'POST'])def login():    if request.method == 'POST':        session['username'] = request.form['username']        return redirect(url_for('index'))    return '''        <form action="" method="post">           <input type=text name=username>           <input type=submit value=Login>        </form>    '''@app.route('/logout')def logout():    # remove the username from the session if its there    session.pop('username', None)    return redirect(url_for('index'))# set the secret key.  keep this really secret:app.secret_key = 'A0Zr98j/3yX R~XHH!jmN]LWX/,?RT'view rawgistfile1.py hosted with ❤ by GitHubFlask는 기본적으로 시큐어 쿠키(Secure Cookie)를 통해 세션을 구현하므로 길이에 제한이 있습니다. 때문에 파일이나 DB기반의 세션을 구현하려면 Beaker와 같은 프레임워크를 통한 확장이 필요합니다.(하지만 이 또한 매우 쉽습니다.)#스포카 #개발 #개발자 #개발팀 #인사이트 #기술스택 #꿀팁 #Flask
조회수 625

[Buzzvil Culture] Buzzvil Training Session 2018 Q1

 버즈빌에서는 직무에 관계가 없다고 하더라도 각 개인의 성장을 위해 다양한 주제의 세션을 진행하고 있습니다. 2018년의 첫 번째 세션은 “문제의 발견과 해결”이라는 주제로 6주에 걸쳐 진행되었습니다. 6주동안, 문제를 발견하기 위한 전략적 사고의 기초, 문제의 발견과 진단에 도움이 되는 기술적인 지식, 발견해낸 문제에 대해 서로 잘 소통하고 논의하는데 도움이 되는 커뮤니케이션 방법 등 알찬 내용들로 세션이 진행되었습니다.  이번 포스팅에서는 마지막 세션으로 진행되었던 문제를 해결하기위해 세상으로 나가는 가장 적극적인 방법인 창업을 주제로한 “버즈빌 마피아” 세션에 대해 이야기해보려고 합니다. 이 세션은 버즈빌의 Founder이자 공동대표를 맡고 있는 John이 진행하여 주셨는데요. John은 대학시절 이토프와 데일리픽이라는 기업을 창업하여 각각 네이버와 티몬에 인수된 경험이 있는 창업의 베테랑입니다. 평소에도 버즈빌리언들에게 ‘불나방처럼 세상으로 퍼져나가 본인만의 창조물들을 만들어내기를 바란다’는 이야기를 해왔던 John은 이번 세션의 취지에 대해 이야기하며 버즈빌의 또 하나의 미션은 최대한의 경험, 시행착오를 통한 학습, 함께 진흙탕을 구르는 과정을 통해 “버즈빌 마피아”를 키워내는 것이라고 이야기 했습니다.  이번 세션을 통해 창업 아이디어 구상과 구체화, 팀빌딩과 위기극복, 엑싯에 대한 고민 등 창업에 대한 다양한 주제들에 대해 직접적인 경험에서 우러나오는 많은 이야기들을 나누어 주었는데요. 특별히 이번 세션에는 미리 창업에 대한 질문들을 받아 이에 대한 답변을 들어 볼 수 있는 시간이 있었기에 더욱 특별했습니다.단순히 조직이 성장할 뿐만 아니라 그 과정안에서 다양한 방법을 통해 개인이 세상의 문제를 해결하는 인재들로 스스로 성장할 수 있게 하는 것. 그것이 바로 버즈빌이 추구하는 “버즈빌 마피아” 정신이 아닐까 합니다.  “버즈빌 마피아” 정신이 녹아있는 버즈빌의 문화는 아래의 글들에서 더 만나보실 수 있습니다.
조회수 1129

에이스프로젝트 사내 동호회

먼저, 야구게임회사인 만큼 야구를 좋아하는 사람들이 가득한 에이스프로젝트!역시 회사의 핵심 동호회는 ‘야구 동호회’인데요.야구동호회는 구성원 2명이서 캐치볼을 하며 야구 경기를 하고 싶다는 생각에서 시작되었답니다.이외에도 다양한 취미를 공유하는 동호회들이 많이 있어요!구기종목의 대표 스포츠! 축구를 사랑하는 'FC ACE'부터PPT까지 만들어 탁구대를 얻어낼 만큼 열정적인 탁구인들의 ‘Table-Setter’,3, 4구, 포켓볼 가리지 않고 당구를 좋아하는 사람들이 모인 ‘ACE Billiards’, 스포츠 외에도 손으로 만드는 것을 좋아하는 사람들이 모인 수공예 동호회 ‘ACE Hands’까지!최근에는 그림 동호회 ‘Drawing Study’ 와 ‘ABC’라는 보드게임 동호회도 생겼답니다.그림을 그리고 싶은 사람들이 매주 1개 이상을 그리는 동호회인데요.동호회 회원은 대부분 그래픽팀이지만, 그림을 전공하지 않은 에이스인도 참여가 가능하다고 하네요!그래픽팀에게는 역량 개발의 시간이기도 한 'Drawing Study'작업물은 야구와 관련된 그림이 아닌 캐릭터, 사물, 아이콘 등 어떤 것이어도 상관없답니다.신규 입사자분들의 지지를 얻어 생겨난 보드게임 동호회입니다.보드게임은 누구나 쉽게 배우고 즐길 수 있고, 점심시간처럼 짧은 시간에도 재밌게 할 수 있어 인기가 점점 많아지고 있어요. 특히 점심시간의 식후 루미큐브는 에이스프로젝트에서 매일같이 볼 수 있는 일상으로 자리 잡았답니다!회사에 많은 동호회들이 생겨나면서 동호회 연합도 생겼어요.동호회 연합은 각 동호회의 회장과 총무가 모인 조직으로, 비정기적으로 회의를 합니다. 장비나 경비가 필요한 동호회는 이 회의에서 무엇이 필요하고 왜 필요한지, 얼마만큼의 예산 지원을 원하는지 이야기할 수 있습니다. 여기서 다른 동호회 회장들을 납득시키면 경비를 지원받을 수 있어요! 에이스프로젝트의 토론, 설득하는 문화가 적용된 사례 중에 하나라고 볼 수 있죠.재미있는 건 함께 하자는 모토 아래 신규 입사자들에게 동호회 홍보 활동도 열심이에요!같은 일상을 반복하는 직장인들에게 소소한 행복감을 줄 수 있는 에이스프로젝트의 동호회 문화!다양한 취미공유를 통해 행복지수가 높아진다면 출근이 더욱 즐거워지겠죠? 오늘은 같은 관심사를 갖고 있는 사람들이 재밌게 활동하고 있는에이스 사내 동호회를 소개해드렸는데요!일단 재밌기도 하지만(!) 우리 팀이 아닌, 그리고 내가 속한 프로젝트가 아닌 사람들과도 소통할 수 있는 좋은 기회이기도 해요.좋은 사람들과 재밌는 걸 함께한다면 회사생활의 즐거움이 두 배가 되겠죠?그럼 전 오늘 야구 연습이 있어서 이만!
조회수 1989

TPS 지표 이해하기

많은 초창기 스타트업들은 성능에 관심이 없습니다. 제품 만들기도 바쁜데 성능이 무슨 의미가 있을까 생각이 들죠. 당장 서비스에 사용자가 몰리면 아마존 오토스케일이 해결해 줄테니까요. 맞습니다. 빠르게 가치를 증명하는 스타트업이라면 서비스 초창기부터 성능에 관심을 가질 필요는 없습니다. 하지만 한달에 아마존 서비스 비용이 천만원이 넘어가기 시작하면 슬슬 우리 서비스가 합리적으로 인프라를 사용하고 있는지 고민하게 됩니다. 인프라 비용의 근거도 만들고 싶어지기 시작하죠. 시스템의 성능 지표를 확인 하고 싶어진다면 지금이 TPS 지표를 보실 때입니다. Whatap Application TPS MetricTPS 계산하기Transaction per second(TPS)는 초당 트랜잭션의 개수입니다. 실제 계산하는 방식은 일정 기간동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경합니다. 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시됩니다. 위에 그림에 두번째 행을 보시면 5개의 트랜잭션이 실행완료된 것을 볼수 있습니다. 이런 경우 TPS를 구하는 방법은 5 transaction / 5 sec 이므로 결과값은 1 TPS 가 됩니다. (와탭의 TPS 지표는 좀더 복잡하게 계산합니다. 와탭은 챠트의 추세를 보여주기 위해 5초 간격으로 30초 평균 TPS를 보여주고 있습니다.)Saturation Point 와 TPS서비스에 사용자가 지속적으로 늘어나면 어느순간부터 TPS가 더이상 증가하지 않는 상황이 발생합니다. 이렇게 증가하지 않는 지점을 Saturation Point라고 합니다. 위 그림은 서비스의 이상적인 상황입니다. 제대로 튜닝이 되지 않은 서비스는 Saturation Point를 지나면 오히려 TPS가 떨어지기도 합니다. 위 그림을 보면 서비스를 사용자는 300명이 넘어가면 TPS가 고정되면서 상대적으로 트랜잭션의 응답시간이 길어 질것을 예상할 수 있습니다.  좀더 스토리를 만들어 보면 이렇게 이야기를 할 수 있습니다. 위 그림을 보면 동시 접속 사용자가 300명이 넘어가면 TPS는 더이상 올라가지 않으므로 서비스의 정체 시간은 증가하기 시작할 것입니다. 300명의 요청사항에 대한 TPS가 50이라면 해당 요청 사항을 다 처리하는데 6초가 걸린다고 생각할 수 있습니다. 이렇게 TPS와 동시접속자를 미리 선정해봄으로써 서비스의 성능을 상상해 볼 수 있습니다.요점 정리TPS는 초당 트랜잭션의 갯수를 말합니다. TPS는 서비스 성능의 기준이 됩니다.평소 TPS 지표를 체그하세요. TPS를 통해 무슨 요일에 또는 몇시에 최대치가 되는지 확인하세요.  TPS가 더 이상 증가하지 않은 지점을 Saturation Point라고 합니다. Satuartio Point가 넘으면서 사용자가 몰리면 TPS가 고정된 상태에서 응답시간이 길어지게 됩니다.   #와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1047

초기 스타트업이 꼭 해야되는 집착 2가지

1) 고객 집착계속 고객한테 물어보고 그들이 원하는 걸 직접 들어봐야된다. 전화로 같이 떠들어야한다. 말은 쉽지만 생각보다 행동은 쉽지 않다. 근데 고객도 어떤 부분에선 그들도 자기가 뭘 원하고 있는지 모르고 있는 점도 있어 그들 말 속에서 어떤 욕망의 종류를 가지고 있는지 메슬로를 생각하며 끊임없이 딥하게 들어가야된다. 그리고 추상적으로 표현하는 건 계속 세그먼트 해가면서 재질문을 던진다. "좋은 것 같아요. 편한 것 같아요"같은 피드백은 인사이트가 없다. 좋다를 뭐라고 정의내리고, 편한 건 그들에게 있어서 정의가 무엇인지 아주 잘게 쪼개서 다시 질문한다. 이를 회사 차원에서 무엇을 실험해볼 수 있을지 생각해야된다. 이런 행위를 초기에는 많이 해야되는데(하는 행위는 스테이지가 올라가더라도 지속되지만 방법이 데이터 위주로 확인하고 정량적인 부분으로 A/B testing > mesuring > learning이 많아진다.) 고객이랑 친분이 없는 상태서 하면 귀찮게 하는 것 같고 짜증나니깐 처음 고객이랑 접점이 생기면 친구부터 되야한다. 고객은 첫 CS접점에서 친구처럼 느끼는 포인트들이 자주 생겨야한다. 이와 관련되서는 샤오미 얘기를 다룬 참여감이라는 책을 참조.2) 마케팅 집착마케팅 집착은 곧 회사 스테이지 별로 집착의 개념이 달라진다. 초기에는 무조건 프로덕에 집착해야된다. 위대한 제품을 만들기전까지 마케팅 개념을 외부에서 찾으면 안된다. 계속 제품안에 마케팅을 집어넣고 넣고 넣고 넣을대로 넣었다고 생각해도 또 넣고 위대하게 만들어야된다. 그 지표는 바이럴 지표다. 주변에 고객들이 아주 신나게 떠들어대고 추천하는 지표를 추적할 수 있는 고민과 방법을 조직은 가지고 있어야한다. 보통 실수를 범하는게 mvp 수준에서 얼핏 market fit 찾았다고 생각하고 sns 스폰 돌리거나 외부 마케팅을 급하게 진행한다. 또는 조금 스테이지에 있는 초기 기업은 기존 고객은 돌아가는 것처럼 보이니 신규 고객에 혈안이 된다. 투자도 받았겠다. 돈 쓰니 고객도 오겠다. 그렇게 착각에 빠져 점점 내부는 썩어간다. 보통 MVP를 만들어서 수정해서 그저 더 나은 MVP정도를 만들고 외부 마케팅을 시작하는 것이다. 근데 거기서 부터가 망하는 지름길이다. 그 다음은 MLP(minimum lovable product)를 만들어야한다. 여기까지도 많은 회사가 하지는 않는 것 같다. 근데 사랑받을 수 있는 수준도 사실 부족할 수 있다. MLP를 넘어 MGP (minimum greatable product)까지 하고 난 뒤 마케팅은 외부 영역으로 고민할 때다. 여기서부터 스케일업을 고민해야된다. 그때까지는 절대 외부 마케팅을 생각지도 못하게 위대한 프로덕에만 집착하도록 조직을 집중 또 집중시켜야된다.PPL. 페오펫에서는 위대한 개발자, 디자이너, 마케터를(CMO) 모시고 있습니다. 커피 한잔 하실 분은 연락주세요. 펫 산업에서의 완벽한 A to Z 수직 계열화를 꿈꿉니다. 한국에서 가장 밀도있는 생애주기 데이터를 압도적으로 쌓고 활용하는 데이터 플랫폼이 될 것입니다. #페오펫 #peopet #아이디어기업 #기업문화 #목표 #비전 #각오 #팀빌딩

기업문화 엿볼 때, 더팀스

로그인

/