이번 포스트에서는 JANDI가 검색엔진을 도입하게 된 배경과 어떤 작업을 했는지 공유하려고 합니다검색엔진 도입 배경JANDI는 사용자가 입력한 메시지를 검색하고 사용자가 올린 파일의 파일명/파일 타입을 검색하는 메시지/파일 검색 기능을 제공하고 있습니다. 데이터 저장소로 MongoDB를 사용하고 있는데 검색되는 필드에 인덱스를 걸고 정규 표현식을 이용하여 DB Like 검색(“DB는 검색을 좋아한다”아니에요;;)을 하고 있습니다.초기에는 데이터가 아담했는데, 서비스가 커감에 따라 사용자 증가하면서 생성되는 데이터도 많아졌습니다. 올 초에 데이터가 많아지면서 검색이 DB에 부하를 주고, JANDI 서비스에도 영향을 주게 되었습니다. 그래서 JANDI 서비스용 MongoDB와 검색 전용 MongoDB를 분리했는데 이는 임시방편이었고 언젠가는 꼭 검색엔진을 도입하자며 마무리를 지었습니다.시간은 흘러 흘러 4월이 되었습니다. 당시 메시지 증가량을 봤을 때 올해 안에 검색엔진을 사용하지 않으면 서비스에 문제가 될 거라고 판단이 되어 도입을 진행하게 되었습니다.검색엔진 도입의 목표는 다음과 같았습니다.현재 DB Like 검색과 비슷한 검색 품질이어도 좋다. (일정때문에)검색엔진 도입을 통해 검색이 JANDI 서비스에 영향을 주지 않도록 한다.색인을 위해서 주기적으로 JANDI의 MongoDB 데이터를 가져 와야 했지만, 이 작업이 JANDI 서비스에 큰 부하를 주지 않을 거라고 생각했습니다.검색엔진 후보로는 Solr, ElasticSearch, CloudSearch, ElasticSearch Service 가 있었는데 Solr를 선택했습니다.왜냐하면제가 경험한 검색엔진이 Solr 였습니다. 더군다나 2010년 초에 접했던 Solr 비해 많이 발전한 것 같아 개발자로서의 열정과 도전 욕구가 샘솟았습니다. SolrCloud pdf, WhyNoWarAWS에서 제공하는 검색 서비스는 많은 부분을 관리해준다는 면에서 솔깃했지만, Custom Analyzer는 적용할 수 없어서 선택하지 않았습니다.ElasticSearch에 크게 흔들렸지만 경험이없다 보니 공부하면서 프로젝트를 진행한다는 부담감이 커서 다음을 기약했습니다.작업 내용1. MongoImporter, Sharding. MongoImporter 수정현재 JANDI는 MongoDB를 데이터 저장소로 사용하고 있습니다. MongoDB의 데이터를 색인하기 위해 데이터를 검색엔진으로 가져와야 하는데 Solr에서는 DataImportHandler 기능을 제공하고 있습니다. 기본 DataImportHandler로 RDB 데이터는 가져올 수 있지만 이 외 MongoDB나 Cassandra 같은 NoSQL의 데이터를 가져오기 위해서는 따로 구현이 필요합니다. 구글신에게 물어봐서 SolrMongoImporter 프로젝트를 찾았는데 문제가 있었습니다. mongo-java-driver 버전이 낮아서(2.11.1) 현재 JANDI에서 서비스 되고 있는 MongoDB(3.0.x)의 데이터를 가져올 수 없었습니다.url: Reference compatibility MongoDB Java2.11.1에서 3.2.2로 버전을 올리고 변경된 api를 적용하는 작업, 빌드 툴을 ant에서 maven으로 변경하는 작업을 하였습니다. 마음의 여유가 된다면 P/R을 할 계획입니다.여담으로 DataImportHandler 작업과 함께 검색 schema 정하는 작업을 했는데 sub-document 형식이 필요하게 되었습니다. Solr 5.3부터 nested object를 지원한다는 article을 보았는데, nested object 지원 얘기를 보니 Solr도 text search 뿐 아니라 log analysis 기능에 관심을 가지는건 아닐까 조심스레 생각해봤습니다. (역시나… 이미 banana, silk 같은 프로젝트가 있습니다. Large Scale Log Analytics with Solr 에 관련된 이야기를 합니다.). Sharding. 그리고 Document Routing대량의 데이터를 처리하기 위해 한 개 이상의 node로 구성된 데이터 베이스에 문서를 나누어 저장하는 것을 sharding이라고 합니다. SolrCloud는 shard 생성/삭제/분리할 수 있는 API가 있고, 문서를 어떻게 나눌지 정할 수 있습니다. 어떻게 나눌지는 shard 생성 시 router.name queryString에 개발한 router 이름을 적어주면 됩니다. 그렇지않으면 Solr에서 murmur Hash 기반으로 문서를 나누는 compositeId router를 사용합니다. JANDI의 검색 기능은 Team 단위로 이루어지기 때문에 TeamId를 기준으로 문서를 나누기로 하고, compositeId Router를 사용했습니다. 실제 서비스의 문서 데이터를 색인 돌려서 각 node에 저장되는 문서 개수나 메모리/디스크 사용량을 확인했는데 다행히도 큰 차이가 나지 않았습니다.하나의 문서는 TeamId와 MessageId를 조합한 “TeamId + ! + MessageId” 값을 특정 field에 저장하고 해당 필드를 uniqueKey 지정했습니다. 간단한 수정으로 문서 분배가 되는점이 좋았고, 더 좋았던건 검색시 _route_ 를 이용해서 실제 문서가 존재하는 node에서만 검색을 한다는 점이 었습니다. 4년 전 제가 마지막으로 Solr를 사용했을 때는 사용자가 직접 shards queryString에 검색할 node를 넣어주어야 했습니다..../select?q=\*:\*&shards=localhost:8983/solr/core1,localhost:8984/solr/core1SolrCloud RoutingSolrCloud Routing2Multilevel CompositeId2. analyzer, queryParser. analyzerSolr에 기본으로 있는 text_cjk analyzer를 사용하였습니다. <!-- normalize width before bigram, as e.g. half-width dakuten combine --> <!-- for any non-CJK --> text_cjk는 영어/숫자는 공백/특수기호 단위로 분리해주고 cjk는 bigram으로 분리해주는 analyzer 입니다. analyzer는 이슈 없이 완성될 거라 생각했지만 오산이었습니다. 텍스트가 들어오면 token을 만들어주는 StandardTokenizerFactory 에서 cjk와 영어/숫자가 붙어있을 때는 분리하지 못해 원하는 결과가 나오지 않았습니다. 또한 특수기호중에 ‘.’(dot), ‘_‘(underscore)가 있을 때에도 분리하지 못했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfStandardTokenizerFactoryTopic검색개선_AB1021_AB제시CD.pdfCJKWidthFilterFactoryTopic검색개선_AB1021_AB제시CD.pdfLowerCaseFilterFactorytopic검색개선_ab1021_ab제시cd.pdfCJKBigramFilterFactorytopic검색개선_ab1021_ab제시cd.pdf원하는 결과topic 검색개선 ab 1021 ab 제시 cd pdf그래서 색인/검색 전에 붙어있는 cjk와 영어/숫자사이에 공백을 넣어주고 ‘.’와 ‘_‘를 공백으로 치환해주는 작업을 하였습니다. 색인은 Transform에서 처리하고 검색은 다음에 알아볼 QParserPlugin에서 처리했습니다.nametextInputTopic검색개선_AB1021_AB제시CD.pdfTransform 단계Topic 검색개선 AB 1021 AB 제시 CD pdfStandardTokenizerFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfCJKWidthFilterFactoryTopic 검색개선 AB 1021 AB 제시 CD pdfLowerCaseFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdfCJKBigramFilterFactorytopic 검색개선 ab 1021 ab 제시 cd pdf※ 추가 : 검색 결과를 보여줄때 어떤 키워드가 매칭되었는지 Highlight 해야했는데, 색인하기 전에 원본을 수정을 해서 Solr에서 제공하는 Highlight를 사용하지 못하게 됐습니다. 눈 앞의 문제만 바라보고 해결하기 급급했던 저를 다시금 반성하게 되었습니다.. queryParser앞에서도 언급하였지만, 색인뿐만 아니라 검색할 때도 검색어가 입력되면 검색하기 전에 붙어있는 cjk와 영어/숫자를 분리하고 ‘.’, ‘_‘를 공백으로 치환해주는 작업이 필요합니다. Solr에서 기본으로 사용하는 LuceneQueryParserPlugin 을 수정하였습니다.@Override public Query parse() throws SyntaxError { // 수정한 코드 String qstr = splitType(getString()); if (qstr == null || qstr.length() == 0) return null; String defaultField = getParam(CommonParams.DF); if (defaultField == null) { defaultField = getReq().getSchema().getDefaultSearchFieldName(); } lparser = new SolrQueryParser(this, defaultField); lparser.setDefaultOperator (QueryParsing.getQueryParserDefaultOperator(getReq().getSchema(), getParam(QueryParsing.OP))); return lparser.parse(qstr); } QParserPlugin3. DataImportHandler manageMongoImporter에서도 얘기했지만 Solr에서는 DB 데이터를 가져오는 DataImportHandler 기능을 제공 하고 있습니다. DataImportHandler Commands를 보면 총 5개의 명령을 제공하고 있는데, 그중 색인을 실행하는 명령은 full-import와 delta-import입니다. full-import 명령은 DB의 모든 데이터를 색인 하는 것을 말합니다. 색인 시작할 때의 시간을 conf/dataimport.properties에 저장하고 이때 저장한 시간은 delta-import 할때 사용됩니다. 전체 색인한다고 말합니다. delta-import 명령은 특정 시간 이후로 생성/삭제된 데이터를 색인 하는 것을 말합니다. 특정 시간이란 full-import 시작한 시간, delta-import가 최근 종료한 시간을 말합니다. full-import와는 다르게 delta-import가 종료된 시간을 conf/dataimport.properties에 저장합니다. 증분 색인 혹은 동적 색인이라고 하는데 여기서는 증분 색인이라고 얘기하겠습니다. 두 명령을 이용하여 JANDI의 메시지/파일을 색인 하기 위한 삽질 경험을 적었습니다.. 첫 번째 삽질full-import는 현재 active인 데이터를 가져올 수 있도록 query attribute에 mongo query를 작성하고, delta-import 는 특정 시간 이후에 생성된 데이터를 가져올 수 있도록 deltaQuery attribute에 mongo query를 작성합니다. 또한 deltaQuery로 가져온 id의 문서를 가져올 수 있도록 deltaImportQuery attribute에 mongo query를 작성하고, 특정 시간 이후에 삭제된 데이터를 가져올 수 있도록 deletedPkQuery 에도 mongo query를 작성합니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 정상적으로 동작은 했지만, 색인 속도가 실제 서비스에 적용하기 힘들 정도였습니다. 실행되는 mongo query를 확인했는데 다음과 같이 동작하였습니다.특정 시간 이후에 생성된 데이터를 색인하기 위해 약 (새로 생성된 문서개수 + 1) 번의 mongo query가 실행되었습니다. (batch size와 문서 갯수에 따라 늘어날 수도 있습니다.) 메신저 서비스 특성상 각각의 문서 크기는 작지만 증가량이 빠르므로 위 방식으로는 운영 할 수 없었습니다. 그래서 delta-import using full-import 를 참고해서 두 번째 삽질을 시작 하였습니다.. 두 번째 삽질full-imoprt 명령을 실행할 때 clean=false queryString을 추가하고 data-config.xml query attribute를 수정하는 방법으로 증분 색인 하도록 수정했습니다. 특정 시간 이후 생성된 문서를 가져오는 attribute인 deltaQuery와 deltaImportQuery 는 필요가 없어 지웠습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> <!-- if query="" then it imports everything --> 전체 색인은 /dataimport?command=full-import&clean=true 로 실행하고, 증분 색인은 /dataimport?command=full-import&clean=false(생성된 문서)와 …/dataimport?command=delta-import&commit=true(삭제된 문서)로 실행하도록 했습니다.정상적인 것 같았지만, 문제가 있었습니다.full-import, delta-import 명령을 실행하면 conf/dataimport.properties 파일에 전체 색인이 실행한 시작 시각 혹은 증분 색인이 최근 종료한 시간이 “last_index_time” key로 저장됩니다. 첫 번째 삽질에서 증분 색인시 delta-import 명령 한 번으로 생성된 문서와 삭제된 문서를 처리했지만, full-import와 delta-import 두개의 명령으로 증분 색인이 동작하면서 생성된 문서를 처리할 때도 last_index_time이 갱신되고 삭제된 문서를 처리할 때도 last_index_time이 갱신되었습니다.예를 들면증분색인 동작이 1분마다 삭제된 문서를 처리하고, 5분마다 생성된 문서를 처리 한다고 가정해보겠습니다. 3시 13분 14초에 delta-import가 완료되어 last_index_time에 저장되고, 다음 delta-import가 실행되기 전 3시 13분 50초에 full-import가 완료되어 last_index_time이 갱신되었다면, 3시 13분 14초부터 3시 13분 50초 사이에 삭제된 문서는 처리를 못 하는 경우가 발생합니다.Solr에서 dataimport.properties에 기록하는 부분을 수정하는 방법과 전체/증분 색인을 동작시키는 Solr 외부에서 특정 색인 시간을 관리하는 방법이 있었는데 Solr를 수정하는 건 생각보다 큰 작업이라 판단되어 외부에서 관리하는 방법으로 세 번째 삽질을 시작하였습니다.. 세 번째 삽질전체/증분 색인을 주기적으로 동작 시키는 곳에서 full-import&clean=false(생성된 문서) 처리할 때 필요한 마지막으로 색인 된 문서 id와 delta-import(삭제된 문서) 처리할 때 필요한 마지막으로 색인 된 시간을 관리하도록 개발하였습니다. 증분 색인 시 full-import&clean=false를 실행하기 전에 현재 색인 된 마지막 id 조회 후 해당 id보다 큰 데이터를 처리하도록 하였고, delta-import를 마지막으로 마친 시간을 따로 저장하다가 delta-import 실행 시 해당 시간을 전달하는 방법으로 수정하였습니다.<!-- data-config.xml --> <?xml version="1.0" encoding="UTF-8" ?> 마치며튜닝의 끝은 순정이라는 말이 있는데 IT 기술은 예외인 것 같습니다. 현재는 Solr의 기본 기능만으로 구성했지만, 고객에게 더 나은 서비스를 제공할 수 있는 시작점으로 생각하고, JANDI 서비스에 맞게 끊임없이 발전해나가겠습니다.감사합니다.참고Getting Started with SolrApache Solr 5.5.0 Reference Guide PDFApache Solr 6.1 - Analyzers, Tokenizers and FiltersRebalance API for SolrCloud issueYonik Blog#토스랩 #잔디 #JANDI #개발자 #개발팀 #개발후기 #인사이트

어딘가로 떠나는 퇴사 로망을 꿈꾸던 내게, 스타트업 행이라는 기회가 열려버렸다. 그리고 에이전시 UI 디자이너였던 내가, 스타트업 UX 디자이너가 됐다."괜찮아요? 지낼만해요?"라는 질문에는"후하, 심호흡 좀 하고 말할게요."라고 답하고 싶다.4달이 지난 이 시점에서, 어떤 변화가 있었는지 풀어 보려 한다.괜.찮.아.요?역할을 바꿨더니 모든 역할(기획자, 디자이너, 개발자)의 마음이 이해되기 시작했다.1. 기획자 입장수정을 해야 했던 기획자의 그 마음이 이해되더라이전에는 UI만 담당했기에 종종, 기획을 틀어버리는 기획자가 원망스러웠다. 사용자 경험을 고려해 전체 플로우를 짜 놓은 상태에서, 부분적으로 바뀐 기획안을 보고 있자면 물음표 투성이었다. 또한 약 200여 장 넘는 문서를 다루면서 바뀐 기획을 반영하는 데는 꽤 많은 공수가 들기도 했었기에 너그럽지 못했다.그런데 기획부터 UI까지 함께 하다 보니 기획자의 마음과 그 과정이 이해된다.막상 디자인(image)과 개발된 것(interaction)을 보면  더 나은 방향이 떠오르기에,머리는 하나지만 고민할 케이스는 수십 가지기에,어제의 내가 정답이 아니기에, 등등(문제는 오늘의 나도 정답이 아닐 수 있다)2. 디자이너-개발자 입장수정을 마주하는 그 마음도 이해되더라수정에 민감했던 나의 과거를 생각하며... 이제는 막을 수 없다면 줄이자 ^*^ 기획 단계에서 최대한 많은 파이의 고민을 하고, 구현 전에 디자이너-개발자와 함께 검토하는 시간을 가져야 오류를 최소화할 수 있다. (무려 시행착오 끝에... 오늘에서야 깨달았다!)고상하게 표현했지만, 후폭풍을 막기 위해서는 기획서를 두고 서로를 설득하기 위한 치열한 논의가 필요하다.3. UX 디자이너 입장나의 다음 스텝(진화과정)이 이해되더라이전에는 여러 프로젝트를 병행했기에 기획 쪽 이슈는 팀 내 시니어에게 전달받았고, 디자인-개발의 이슈의 경우엔 이슈 리스트로만  주고받았다. 또한 디자이너들과 소통할 일이 90%였고, 눈빛만 봐도 척하면 척이었기에 나의 역할을 잘 수행하는 것이 가장 큰 목표였다.하지만 이제는 '기획-디자인-개발' + 운영팀의 흐름을 항상 놓치지 않아야 할 역할이 되었다.이전에는 디자인 팀을 관리하는 PM(프로젝트 매니저)이 다음 스텝이었다면, 스타트업에서는 프로덕트를 관리하는 PO(프로덕트 오너)가 다음 스텝이라는 것.(지난해 함께 합류하게 된 개발자 호성님께서 '스크럼'이라는 프로젝트 방법론을 제시하셨다. '스크럼'을 실행한 지 2달 여째, 나는 나의 역할이 조금씩 이해되고 있다.)아우, 쓰고 보니 한참 멀었다.변화의 묘미근래에 스타트업 생활을 하면서 와 닿았던 두 대표님의 이야기가 있다." 지금까지도 그래 왔고, 앞으로도 새로운 것을 만들어나가는 사람들이기에 어려운 문제들과 상황들을 잘 해결하려고 부담 갖기보다 조금 더 즐기며 도전하는 마음가짐으로 맞이 합시다 "  8퍼센트 이효진 대표님" 스타트업 생활을 하면서 '이렇게 세상을 빠르게 변화시킬 수 있는 사람들과 함께 일을 할 수 있다는 것'이 큰 힘이 되었습니다. "패스트캠퍼스 이강민 대표님아직은 이해하는 단계지만, 이 무지막지한 모든 변화들이 스타트업에서만 겪을 수 있는 묘미인 것 같다.핀테크를 꿈꾸며... 열일중인 인(人)테크의 현장#8퍼센트 #에잇퍼센트 #협업 #사내문화 #조직문화 #팀플레이 #팀워크

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

이 글은 Business Insider에 실린 When Facebook Was Young And Trying To Attract Talent, It May Have Pulled This Brilliant Hiring Stunt At Stanford를 번역한 글입니다. SV Angel's의 데이빗 리는 Lerer Ventures의 CEO 모임에서 주목을 받았는데요, 왜냐하면 청중 가운데 한 CEO가 투자자에게, 뛰어난 인재를 데려오기 위한 스타트업의 혁신적인 채용 전략에 대해서 물어보았습니다. 페이스북 초기에 마크 저커버그가 사용한 전략에 대해서 언급했습니다. 리는 이 이야기가 그저 근거없는 소문이지만 이런 이야기를 들었다고 하더군요. 그러나 소문이라고 해도 너무 신선하고 너무 창의적이었습니다. 페이스북이 초기이고 유능한 인재를 찾아다닐 때, 관련있는 학생들을 찾기위해 스탠포드의 강의 개요와 해당 수업의 카탈로그를 참고했다고 합니다. 이미 페이스북은 캠퍼스에서 잘 알려져 있었죠. 예를 들어, 만약 페이스북이 엔지니어가 필요하다면, 엔지니어링 수업을 찾습니다. 관련있는 수업을 찾으면 해당 과목의 필독서 리스트를 함께 찾습니다. 저커버그와 그의 스태프는 스탠포드 도서관에 가서 위에서 언급한 필독서 안에 페이스북 포지션에 대한 전단지를 넣었다고 합니다. 학생들이 책을 꺼내면 페이스북이 남겨놓은 전단지를 찾을 수 있도록 말예요. 소문이었다고 해도 정말 좋은 전략임에 틀림없는 것 같습니다. 우선 해당 수업의 필독서를 찾아본다는건 굉장히 성실하다는 뜻이니까요. 우리나라에서 소프트웨어 개발에 관심있고 잘하는 학교가 어딘지 정말 궁금하네요. 저도 그 학교 도서관에 가보게요 :)#비주얼캠프 #인사이트 #경험공유 #조언

아이들과 오전에 놀아주고 집안일을 마치고 나서 지하철을 탔다. 파이콘에 가는 길이었다. 5년째 참석하다 보니 이제 모든 세션을 빡빡하게 들어야 한다는 부담이 없다. 그래서 늦었지만 여유로웠다. 가는 길에 습관적으로 본  페이스북 타임라인은 이미 파이콘 이야기로 가득했다. 인증과 세션 자료 그리고 개발자를 뽑고 싶어 하는 회사들의 홍보로. 피드에서 스포카에서 진행하는 도도 파이터 이벤트를 보고 "이건 뭐야?" 싶어서  링크를 눌렀다. 어이쿠 개발자 컨퍼런스에 이게 도대체 뭐야오. 깔끔하게 잘 만들었다. 예제 코드를 살펴보니 설명도 잘 되어 있고 간단하다. 도전해 보고 싶은 생각이 들었다. 지하철 자리에 앉아 테더링을 연결하고 코딩을 시작했다. (사실 이것이 내가 세션은 듣지 않고 이틀 동안 부스/이벤트 체험만 하게 된 계기가 될 줄은 몰랐다.)대단히 잘 할 생각은 없었다. 세상에 굇수는 많으니까. 참여에 의의를 둬야지 싶었다. 비록 설명에는 “인공지능 코드”를 작성하여 다른 참가자와 겨루는 “인공지능 격투 대전”이라고 되어 있지만 당연해 보이는 규칙만 구현하고 나머지는 랜덤으로 동작하게 해서 제출해 보자 싶었다. 코엑스에 도착한 후  조금만 더 작업해서 제출하려고 하는데 아무리 제출해도 제출이 되지 않고 다음과 같은 메시지만 받았다.  코드가 테스트를 통과하지 못했습니다.아니 랜덤 봇이랑 하면 잘만 이기는데 왜 통과를 못하는 거야! 하던 차에 다시 설명을 읽어 보니  가만히 있는 더미 에이전트를 상대로 이겨야 제출이 이루어집니다.란다. 먼저 가면 손해인지라 가까워지면 더 안 가고 제 자리에서 주먹질만 시켰더니 더미 에이전트를 못 이기나 보다. 그래서 5초 아래로 시간이 남고 지금까지 한 번도 안 싸웠으면 앞으로 가도록 했더니 테스트를 통과하고 제출이 되었다.  제출에 성공하고 기분 좋게 돌아다니면서 다른 부스도 구경하고 있는데 회사 슬랙으로 함께 파이콘에 참여하고 계신 동료 분이 메시지를 보내셨다.봇이 화끈하면 뭐햐나. 이기면 장땡!스포카 부스에서 사람들이 제출한 봇들을 랜덤으로 붙여 주는 모양이었다. 후후. 어찌 되었든 이겼다고 하니 기분이 좋군.첫날 마지막 행사인 라이트닝 토크에서 스포카 도도 파이터 개발자분의 발표가 있었다. 회사에서 파이콘을 준비하면서 한 달 가까이 준비했다고 한다. 그리고 최근 2주도 동안은 도도 파이터만 달렸다는 이야기를 해주셨다. 컨퍼런스 이벤트로 만든 게임의 퀄리티가 좋아서 감탄한 것도 있었지만 팀에서 개발자들에게 그런 여유를 줄 수 있는 것도 부러운 마음이 들었다. 좋은 회사다. 도도 파이터 토너먼트는 다음날 파이콘 정식 행사가 끝나고 열렸다. 기억으로는 80명 정도가 참여했었던 것 같다. 조별 토너먼트를 진행하고 우승자들을 모아서 다시 토너먼트를 하는 구조였다.   싸워라! 싸워라!조금 늦게 왔더니 자리가 없어서 가장 앞자리에 나왔는데, 내 봇의 차례가 될 때마다 github 계정의 내 얼굴이 스크린에 크게 나와서 부끄러웠다. 외국 친구들은 자기 얼굴 github 프로필에 잘 넣어 놓던데, 왜 우리나라 개발자들은 자기 사진을 안 넣는 걸까... 게다가 내 봇이 나오는 경기는 모두 지루하고 얍삽한 느낌이 있어서 왠지 더 부끄러웠다. 니가 올래? 내가 갈까?다행히 조별리그도 통과해서 결승 리그에 올라갔다. 사실 한 두경기만 이기면 좋겠다 했었는데, 결승 리그에 올라가니 왠지 욕심이 생겼다. 제일 그럴싸하게 싸운 경기운 좋게도 아슬아슬하게 16강부터 4경기를 모두 이겨서 우승을 하고 문성원 CTO님께 해피해킹 키보드도 상품으로 받았다. 기분이 좋으면서도 멋쩍기도 한 기분이다. 사실 이번 파이콘에 와서 여러 곳의 부스를 참여하고, 이벤트도 적극적으로 참여해 본 이유는 내년에 8퍼센트도 파이콘에 스폰서로 참여하고 싶어서 였다. 우리의 (잉여) 개발력도 보여주고, 다른 개발자 분들과도 적극적으로 교류하고 싶은 마음이었다. 그 바람이 꼭 이루어질 수 있게 다음 파이콘 때 까지 좋은 분들을 모시고, 회사의 성장을 만들어 나가야겠다는 생각이 들었다. 마지막으로 내 코드를 공개한다.  https://gist.github.com/leehosung/f784d9efc71dce12855739647dd98877다시 코드를 살펴보니 개선할 점도 여러 개 보인다. 하지만 기존에 제출한 코드를 보기 좋게 정리만 하고 주석만 붙여 보았다. 사실 별 특별한 것이 없는 코드다. 실제 작성하고 테스트하는 것에도 한 시간이 걸리지 않았다.다음에 이런 기회가 온다면 글을 읽으시는 분들도 가벼운 마음으로 도전해 보셨으면 한다.  성적이 좋으면 더 좋지만 나쁘면 또 어떠한가? 개발자인 우리만 즐길 수 있는 놀이인데.  #8퍼센트 #에잇퍼센트 #파이콘 #파이썬 #Python #Pycon #이벤트참여 #참여후기 #개발자 #개발

취업은 많은 대학생들의 목표다. 도서관에 가면 많은 학생들이 고시나 공무원 서적을 공부하고 있다. 영어공부를 하러 연수를 떠나고, 인턴이나 공모전에 힘쓰는 것도 대부분 취업을 위함이다. 막연한 스펙쌓기에 대한 지적은 많지만, 기업 입장에서 지원자의 이력을 안볼수는 없는 노릇이다. 이력서가 꽤나 효율적인 도구인 건 사실이다. 그래서 많은 대학생들은 기업에 보여줄만한 이력을 만들기 위해 많은 활동을 한다. 나 역시 그랬다. 인턴과 공모전 등을 준비하느라 분주한 시간들을 보냈다. 그런 와중에 대학생들에게 취업을 위해 또다른 무언가를 하라고 이야기하는 것은 부담스러운 내용이다. 그럼에도 나의 경험상, 종이신문을 읽는 습관이 꽤나 큰 도움이 되었기에 조심스럽게 이야기를 꺼내보려한다. 처음 종이신문을 본 이유처음에는 몇몇 선배들이 종이신문을 읽으라고 권했다. 스마트폰이 세상을 바꾸고 인터넷으로 실시간 기사를 볼 수 있는 시대에 종이신문이라니. 자연히 신문보기를 권하는 그 말을 대수롭지 않게 흘려들었다. 하지만 취업을 본격적으로 준비하면서는 생각이 달라졌다. 뭐랄까 마음 한구석에는 작은 불안감이 있었는데, 그것은 막연한 스펙쌓기로는 면접이나 그룹토의에서 잘할 수가 없겠다는 생각이었다. 면접에서는 특정한 사안에 대해서 나의 관점을 논리적으로 전달하는 능력이 필요했다. 성적표나 자기소개서에 나오는 몇줄의 이력이 커버할 수 없는 부분이었다. 그러려면 우선 세상에 무슨 일이 벌어지고 있는지 알아야했다. 그렇게 신문읽기의 필요성을 좀 더 느끼고 나니 종이신문을 구독할까 고민이 되기 시작했다. 선배들이 좋다고 하는데는 다 이유가 있겠지, 게다가 대학생은 50% 할인도 된다던데. 속는셈 치고 한번 구독해볼까하는 생각에 이르렀다. 그러던중 소위 좋은 직장에 취직한 선배가 얼굴을 파묻고 신문을 읽는 모습을 본 날, 나도 전화기를 들어 매일경제신문을 구독했다.어떤 신문을 봐야할까나는 취업준비 차원에서 신문읽기를 시작했기에, 지원하려는 기업과 부서의 특성을 고려했다. 삼성, 현대, SK, LG 등 일반적인 대기업의 취업을 지망한다면, 정치/사회기사보다는 경제뉴스를 집중해서 보는 것이 낫겠다고 생각했다. 한국경제, 매일경제 등의 경제지는 약 30개 지면을 대부분 경제기사에 할애한다. 당연히 지원하는 기업과 관련한 뉴스도 많았다. 최근 실적이나 기업의 중장기 방향성, 새로 출시한 신제품 등의 정보를 미리 알고 있는 것은 큰 무기가된다. 반면 언론사 취업을 준비했던 친구는 한가지에 집중하지 않고 다양한 종류의 신문을 읽었다. 대략 3-4개 종합일간지와 1개의 경제지를 챙겨봤던 것 같다.종이신문의 좋은점종이신문을 구독한 후 느낀 종이신문의 장점은 단순하면서도 아이러니했다. 종이신문을 읽으니 비로소 기사를 정독했다. 역설적이지만 돈을 낸다는 점이 오히려 장점이 되었다. 인터넷으로 기사를 보는 데에는 돈을 내지 않아도 된다. 기사의 퀄리티도 종이신문의 그것과 같다. 하지만 인터넷에는 집중을 방해하는 요소가 많고, 기사를 반드시 봐야하는 환경도 없다. 그래서 조금만 해이해져도 꾸준히 기사를 보지 않는다. 기사를 보겠노라 인터넷을 시작했다가, 쇼핑을 하거나 웹툰이나 스포츠 경기로 기사읽기를 끝낸 것은 많은 사람들의 공통 경험이다.반면 종이 신문은 실제로 돈을 지불한다. 돈을 내고 구독하는 신문은 그냥 버릴 수가 없다. 날짜가 지난 신문도 마음 편히 버리지 못한다. 돈이 아까우니까 괜히 신문을 펴 한두개라도 기사를 본다. 그게 바로 돈값을 하는 것이다. 돈주고 종이신문을 보는 것은, 공짜인 기사에 쓸데없이 돈을 쓰는 바보같은 행동이 아니라, 신문 기사를 볼 수 있는 환경에 투자하는 것이다. 종이신문을 볼 때 우리는 더 다양한 주제의 기사에 노출된다. 특정 기사를 읽는 동안 우리의 시야에 많은 기사들이 걸린다. 신문을 한장씩 넘기면서 왼쪽부터 오른쪽으로 기사를 한번 훑는 와중에 또 많은 헤드라인을 보게된다. 기사 옆에 또 기사가 있는 종이신문의 레이아웃은 클릭을 해야만 새로운 기사로 넘어갈 수 있는 인터넷보다 많은 기사보기에 효율적이다. 종이신문, 어떻게 보면 좋은가종이신문 읽기는 좋은 습관이지만 꾸준히 유지하기가 쉽지 않다. 며칠만 지나도 신문을 처음만큼 열심히 읽지 않게 된다. 이런 문제들을 해결하기 위해 내가 썼던 방법은 스터디를 만드는 것이었다. 나는 대학교 4학년때 1년동안 종이신문 읽기 스터디를 했다. 함께 취업을 준비했던 형과 매일 아침 8시에 도서관 1층에서 만나, 서로 인상깊었던 기사를 3개씩 공유했다. 자연히 더 좋은 기사를 찾기 위해 많은 기사를 보게됐고, 또 스터디라는 도구가 있으니 신문을 안 읽고 넘어가는 날도 없었다. 그리고 기사에 대한 이해도 깊어졌다. 누군가에게 설명하기 위해서는 기사에 대한 많은 이해가 필요했다. 질문에 답을 하기 위해 미리 예상 질문을 생각했고 또 관련된 다른 기사들을 찾아보기도 했다. 자연스러운 공부가 된 것이다. 종이신문을 읽는 삶그렇게 1년간 신문을 읽었다. 특정 기업과 산업에 치우치지 않고 경제 전반에 대한 이해가 높아졌고, 까다로운 경제용어와도 친숙해졌다. 아는 것이 늘어나니 면접에서 자신감도 생겼고, 목소리에 힘이 붙었다. 불어난 자신감만큼 배려심도 생겨서 집단토의에서도 부드럽게 리드를 할 수 있었다. 결과적으로 나는 면접까지 간 모든 기업에서 합격을 했다. 그리고 이제 직장 8년차인 나는 여전히 종이신문을 읽는다. 취업을 위해 시작한 작은 습관이 9년째 유지되고있다. 매일 아침 집앞에 놓인 신문을 통해 세상을 한번 훑어보는 것은 일상의 루틴이 되었다. 일간지는 매일 기사를 찍어내야하는 특성상 아주 깊은 내용을 담을 수 없는 한계가 있지만, 그만큼 넓은 분야의 기사를 빠르게 다룬다. 이제 세상은 'T자형' 인재를 넘어 '파이자(π)형' 인재를 원한다고 한다. 한 분야를 깊이있게 공부하기 위해서는 기초체력이 필요하다. 종이신문 읽기는 넓은 분야의 정보를 꾸준히 접해 지식의 기초체력을 탄탄히 할 수 있는 습관이다. 다시한번 종이신문 읽기를 권한다.by 취업에 도움이 되고픈 30대 직장인챌린저스, 확실한 목표달성 꾸준한 습관형성 앱www.chlngers.com

세상은 외로움을 회피하는방향으로 움직인다"왕따가 왜 무서운 건지 아니?""인간은 혼자일 때가 가장 두렵기 때문이야"사람들이 스마트폰과 SNS에 집착하는것은 누군가의 소식이 궁금해서도 아니고 재미있는 것을 찾기 위해서도 아니다. 외로움이 두렵기 때문이다. 외롭게 보이고 싶지 않기 때문이다.어딘가 소속되고 싶어하는 마음도, 누군가와 사랑하고 싶은 욕망도 그 처절한 외로움을 회피하고 싶어하기 때문이다.사랑은 세상에 나를 이해해주는 누군가가 존재한다는 위안감 때문에 가치가 있는 것이다.남들과 다른 것을 두려워하고, 어딘가 울타리를 벗어난 것에 불안함을 느끼는 것도 그렇게 함으로써 무리에서 벗어난 느낌을 무서워하기 때문이다.공유 경제의 현상으로 공간을 공유하고, 커뮤니티를 강화하는 것도 궁극적으로는 점차 핵가족화 되어가는 사회에서 나 혼자 남겨지는 것에 대한 반대급부 때문이다.모든 현상의 이면에는외로움에 대한 두려움이 숨어있다앞으로는 개인의 전문성만으로도 사회 생활이 가능해지는 1인 기업, 프리랜서, 원격 업무들이 늘어남에 따라 점차 외로움을 벗어나게 해주는 산업이 발달할 수 밖에 없다.애완동물 산업이 엄청난 속도로 커지고 있다는 것과 소규모 모임들, 데이트 만남 서비스가 확대 되어가는 것도 이것을 입증하는 현상들이다.이미 세상은 1인 가구가 보편적인 가정 형태의 하나인 시대가 되었다. 노인뿐만 아니라 비혼의 성인들, 그리고 결혼 생활을 중단한 많은 이들이 곳곳에 1인 가구를 이루고 있다. 인류 역사상 유래 없는 현상이다. 한번도 겪어보지 않은 일들을 마주하고 있기 때문에 사회 시스템은 아직 이 현상을 어떻게 대처해야 할지 준비가 되어있지 않다.그래서 뭐?그렇다.그래서 어쩌라구에 대한 답을 찾아야 한다.스마트폰은 외롭고 고립된 인간에게 무한한 연결을 가능하게 해준 빛이 되었던 것이다. 장소와 시간에 상관없이 누군가와 연결되어 있다는 심리적 소속감에 거리를 거닐면서도 밤에 잠을 이루기 전에도, 사회에서 인정받지 못한 스스로를 가상의 게임 공간에서 강인한 캐릭터로 위안 받는 세상을 이해해야 한다.지하철에서 하루 일과에 찌든 중년의 아주머니조차 줄맞춰 터트리는 모바일 게임에 빠질 수밖에 이유는 허무한 일상과 혼자라는 두려움을 벗어나는 간편한 탈출구이기 때문이다. 세상이 어떤 방향으로진화할 것인지에 대한 해답세상이 빠르게 변하더라도 인간의 본질적 욕망은 변하지 않는다. IT기술을 개발해야 하는 기업이나, 소셜 서비스를 발굴하는 스타트업들이나, 제도를 마련해야하고 정책을 펼치는 정치인들 모두 우리가 한번도 경험해보지 못한 형태의 새로운 고독을 직면해야할 인간의 문제를 심각하게 고민해야 할 것이다.모든 것의 중심에는 인간이 있어야 한다.명백한 것은 행복은 외로움의 반대 방향일 것이라는 것이다.외롭지 말자.

안녕하세요. 클라라입니다:)안녕하세요. 클라라입니다:)저희 미미박스에는 저를 비롯한 아홉 명의 인턴들이 일을 하고 있는데요~저희들은 서로를 ★MEMEGIRLS★라고 부른다며………여하튼, 원래 인턴과 대화해보면 그 회사에 대해 잘 알 수 있다고 하죠. (네, 제가 만들어낸 말입니다...)집중의 박수 짝짝짝!!!오늘부터 [미미걸스 인턴 인터뷰]를 올릴 예정이니 많이 기대해주세요 >_<첫번째 인턴 인터뷰 !!그 영광의 주인공은 바로글로벌커뮤니케이션 팀에서 일하고 있는 CHOHEE 초희!!!!!매력적인 목소리를 가진 밝은 에너지의 초희를 만나보시죠:) 뿅뿅첫번째 인턴 인터뷰 !!그 영광의 주인공은 바로글로벌커뮤니케이션 팀에서 일하고 있는 CHOHEE 초희!!!!!매력적인 목소리를 가진 밝은 에너지의 초희를 만나보시죠:) 뿅뿅Q. 안녕하세요 초희:)아침부터 인터뷰 응해주셔서 감사합니다 . 평소 초희의 하루 일과는 어떻게 되는지 알려주세요!A. 아침에 출근을 하면 세계 각국의 지사에서 온 요청들을 처리해요. 미미박스에는 총 다섯 개 국가에 지사를 두고 있어요. 미국, 중국, 대만, 싱가포르, 홍콩인데요. 지사마다 분위기도 다르고 집중하고 있는 업무도 달라서 지사에 맞게 요청을 처리하고 커뮤니케이션하는 게 저희 팀의 주 업무거든요. 저는 메이크업 브랜드를 담당하고 있는데, 예를 들어 새로 런칭하는 제품이 있을 때, 그 제품에 대한 이해를 바탕으로 교육자료나 컨셉보드를 번역해서 전달하는 일을 하기도 하고요. 화장품 같은 경우는 수출을 위해 위생허가를 받아야 하는데, 저는 중국과 대만의 위생허가를 담당하고 있어요. 위생허가의 원활한 절차를 위해 브랜드 오너들, 제조사, 그리고 위생허가 담당자들과 주로 커뮤니케이션을 하고 있어요. 또 매일 한 지사씩 돌아가면서 컨퍼런스 콜을 합니다. 그 콜을 하면서 지사가 어떻게 돌아가고 있는지, 서로의 이슈나 요청에 대한 의견을 나눕니다. 새로운 화장품을 출시할 때 제품의 이름이나 컬러명 등을 결정하는 일도 하는데요. 전 세계적으로 문화에 맞게 통용될 수 있는 이름을 지어야 하기 때문에 이 일 또한 글로벌커뮤니케이션팀에서 담당하고 있습니다. 예를 들어서 우리는 ‘로즈브라운’이라고 하면 대충 색감이 와닿잖아요, 근데 미국에서 색이름으로 너무 이상하다고 한 적이 있어요. 그런 미묘한 차이를 반영해서 어느 국가에서나 통용될 수 있는 이름을 찾아내는 거죠.Q. 그럼 화장품 성분이나 법률 지식도 많이 알아야 할까요? 글로벌커뮤니케이션에 가장 필요한 업무 능력이나 지식은 무엇일까요?A. 생각보다 화장품 지식은 금방 배우는 것 같아요. 몇 가지만 알면 어느 정도 이해할 수 있거든요. 근데 저는 여성이기 때문에 강점이 좀 있다고 봐요. 화장품 업계 모든 직무가 그렇겠지만, 일단 컨셉보드 같은 경우에 보자마자 직관적으로 그 내용을 이해할 수 있으려면 화장품 자체를 접할 기회가 있어야 하는 것 같고요. 그게 베이스가 되어있으면 용어적인 면에서는 금방 적응하고 배울 수 있어서 큰 문제는 없을 것 같네요.제가 느끼기에 가장 필요한 능력은 아무래도 영어인것 같아요. 지사들과는 직접 만날 수 없으니 화상통화와 메일로만 커뮤니케이션이 가능한데, 모든 지사들이 기본적으로 영어를 쓰기 때문에 영어가 가장 중요한 업무 능력인 것 같아요. 사실 영어보다 중요한 건 커뮤니케이션 스킬이에요. 저는 흔히 말하는 업무 능력들 중 많은 사람들이 커뮤니케이션 스킬이 중요하다고 했을 때는 감이 잘 오지 않았었어요. 이제는 제가 커뮤니케이션 팀에 있다 보니 그게 얼마나 중요한지 피부로 깨닫게 되는 것 같아요. 어떤 의사결정을 할 때에 지사와 본사에 있는 브랜드 담당자들이 굉장히 많이 부딪히거든요, 그럴 때 중간에서 서로 감정이 상하지 않으면서 좋은 결과를 도출할 수 있도록 조율해줄 수 있는 능력이 무엇보다 필요한 것 같아요!Q. 그럼 미미박스의 해당 직무에 지원하게 된 계기는 무엇이었나요?아침부터 인터뷰 응해주셔서 감사합니다 . 평소 초희의 하루 일과는 어떻게 되는지 알려주세요!A. 아침에 출근을 하면 세계 각국의 지사에서 온 요청들을 처리해요. 미미박스에는 총 다섯 개 국가에 지사를 두고 있어요. 미국, 중국, 대만, 싱가포르, 홍콩인데요. 지사마다 분위기도 다르고 집중하고 있는 업무도 달라서 지사에 맞게 요청을 처리하고 커뮤니케이션하는 게 저희 팀의 주 업무거든요. 저는 메이크업 브랜드를 담당하고 있는데, 예를 들어 새로 런칭하는 제품이 있을 때, 그 제품에 대한 이해를 바탕으로 교육자료나 컨셉보드를 번역해서 전달하는 일을 하기도 하고요. 화장품 같은 경우는 수출을 위해 위생허가를 받아야 하는데, 저는 중국과 대만의 위생허가를 담당하고 있어요. 위생허가의 원활한 절차를 위해 브랜드 오너들, 제조사, 그리고 위생허가 담당자들과 주로 커뮤니케이션을 하고 있어요. 또 매일 한 지사씩 돌아가면서 컨퍼런스 콜을 합니다. 그 콜을 하면서 지사가 어떻게 돌아가고 있는지, 서로의 이슈나 요청에 대한 의견을 나눕니다. 새로운 화장품을 출시할 때 제품의 이름이나 컬러명 등을 결정하는 일도 하는데요. 전 세계적으로 문화에 맞게 통용될 수 있는 이름을 지어야 하기 때문에 이 일 또한 글로벌커뮤니케이션팀에서 담당하고 있습니다. 예를 들어서 우리는 ‘로즈브라운’이라고 하면 대충 색감이 와닿잖아요, 근데 미국에서 색이름으로 너무 이상하다고 한 적이 있어요. 그런 미묘한 차이를 반영해서 어느 국가에서나 통용될 수 있는 이름을 찾아내는 거죠.Q. 그럼 화장품 성분이나 법률 지식도 많이 알아야 할까요? 글로벌커뮤니케이션에 가장 필요한 업무 능력이나 지식은 무엇일까요?A. 생각보다 화장품 지식은 금방 배우는 것 같아요. 몇 가지만 알면 어느 정도 이해할 수 있거든요. 근데 저는 여성이기 때문에 강점이 좀 있다고 봐요. 화장품 업계 모든 직무가 그렇겠지만, 일단 컨셉보드 같은 경우에 보자마자 직관적으로 그 내용을 이해할 수 있으려면 화장품 자체를 접할 기회가 있어야 하는 것 같고요. 그게 베이스가 되어있으면 용어적인 면에서는 금방 적응하고 배울 수 있어서 큰 문제는 없을 것 같네요.제가 느끼기에 가장 필요한 능력은 아무래도 영어인것 같아요. 지사들과는 직접 만날 수 없으니 화상통화와 메일로만 커뮤니케이션이 가능한데, 모든 지사들이 기본적으로 영어를 쓰기 때문에 영어가 가장 중요한 업무 능력인 것 같아요. 사실 영어보다 중요한 건 커뮤니케이션 스킬이에요. 저는 흔히 말하는 업무 능력들 중 많은 사람들이 커뮤니케이션 스킬이 중요하다고 했을 때는 감이 잘 오지 않았었어요. 이제는 제가 커뮤니케이션 팀에 있다 보니 그게 얼마나 중요한지 피부로 깨닫게 되는 것 같아요. 어떤 의사결정을 할 때에 지사와 본사에 있는 브랜드 담당자들이 굉장히 많이 부딪히거든요, 그럴 때 중간에서 서로 감정이 상하지 않으면서 좋은 결과를 도출할 수 있도록 조율해줄 수 있는 능력이 무엇보다 필요한 것 같아요!Q. 그럼 미미박스의 해당 직무에 지원하게 된 계기는 무엇이었나요?A. 음, 저는 사실 다른 직무, MD나 인사 직무에 대한 고민도 조금은 했었는데 제가 잘하는 게 외국어니까 그걸 가장 잘 살릴 수 있는 직무가 무엇인가 고민했어요. 그게 글로벌 커뮤니케이션이었어요.뒤통수 미인이다아~Q. 일하면서 있었던 가장 재미있는, 또는 힘들었던 에피소드를 알려주세요! A. 최근에는 저희 글로벌 브랜드 팀에서는 아임미미나 포니이펙트같은 브랜드가 어떻게 소비자들에게 더 잘 다가갈 수 있는지, 어떤 메시지를  어떻게 전달하면 좋을지 기존의 틀을 더 발전시켜보는 시간을 가졌었어요. 리서치도 해보고 다양한 사람들과 생각을 나누다 보니 저도 미미박스에 대한 이해도가 높아지고 아무래도 매일매일 처리하는 업무의 성격과 다르다 보니 정말 재밌게 느껴졌던 것 같고요!물론 힘든 일도 있습니다. 지사랑 연락하는 과정에서 갈등이 일어나기도 하니까요. 특히 문화적, 언어적 간극에서 오는 갈등이 많아요. 제품 이름을 정할 때, 한국 BM분들이 원하는 이름과 미국BM분들이 원하는 이름이 다르면 그 사이에서 갈등을 조율해야 하는데, 그 시간이 길어지거나 의견이 좁혀질 가능성이 안 보이면 지치게 되는 것 같아요. 근데 또 그 갈등을 잘 해결했을 때 보람이 있으니까 더 잘해야겠다는 생각도 들어요.Q. 인턴으로 일하면서 가장 만족스러운 부분은 뭘까요?Q. 일하면서 있었던 가장 재미있는, 또는 힘들었던 에피소드를 알려주세요! A. 최근에는 저희 글로벌 브랜드 팀에서는 아임미미나 포니이펙트같은 브랜드가 어떻게 소비자들에게 더 잘 다가갈 수 있는지, 어떤 메시지를  어떻게 전달하면 좋을지 기존의 틀을 더 발전시켜보는 시간을 가졌었어요. 리서치도 해보고 다양한 사람들과 생각을 나누다 보니 저도 미미박스에 대한 이해도가 높아지고 아무래도 매일매일 처리하는 업무의 성격과 다르다 보니 정말 재밌게 느껴졌던 것 같고요!물론 힘든 일도 있습니다. 지사랑 연락하는 과정에서 갈등이 일어나기도 하니까요. 특히 문화적, 언어적 간극에서 오는 갈등이 많아요. 제품 이름을 정할 때, 한국 BM분들이 원하는 이름과 미국BM분들이 원하는 이름이 다르면 그 사이에서 갈등을 조율해야 하는데, 그 시간이 길어지거나 의견이 좁혀질 가능성이 안 보이면 지치게 되는 것 같아요. 근데 또 그 갈등을 잘 해결했을 때 보람이 있으니까 더 잘해야겠다는 생각도 들어요.Q. 인턴으로 일하면서 가장 만족스러운 부분은 뭘까요?A. 일단, 직무 선택을 잘했다고 생각하는 게, 이 직무가 회사의 큰 그림을 볼 수 있는 일이라는 거예요. 좁은 범위의 일만 하는 게 아니라 브랜드 전체의 프로세스를 이해하고 전달하는 일이라서 가능한 것 같아요. 만약 좁은 범위의 일을 반복적으로 하는 일이었다면 저랑 맞지 않았을 것 같고, 일에 대한 주인의식도 안 생겼을 것 같은데, 제가 한 일이 어떤 영향을 미치고 그 결과도 직접 느낄 수 있어서 일하는 재미를 얻어 가는 것 같습니다. 그리고 인턴임에도 진짜 많이 배우고 많은 일에 관여할 수 있는 것 같아서 만족스러워요. Q. 글로벌 커뮤니케이션 일을 하면서 느꼈던, 미미박스가 갖고 있는 강점은 무엇인 것 같아요? 저는 미미박스가 글로벌 지사들의 말에 진심으로 경청하는구나, 하는 생각을 자주 하는데요. 제 주변 타사에서 일하는 분들 말씀을 들어보면 보통 본사에서 일방적으로 소통하는 경우가 정말 많아요. 그런데 미미박스는 각 지사와 매주 소통하고 그들이 하는 말을 귀 기울여 들으려고 진짜로 노력해요. 때로는 그게 지나친 게 아닌가 싶을 정도로요. 근데 그런 점에서 저는 미미박스가 글로벌로 뻗어나가기 위한 태도를 잘 실천하는 회사라는 생각이 들었어요. Q. 마지막으로, 누군가 글로벌 커뮤니케이션 인턴으로 지원하고자 한다면 해주고 싶은 말! A. 음... 저희 팀원들이 너무너무 좋거든요. 다른 팀은 제가 직접 경험하지 않아서 모르겠지만 저희 팀의 경우에 말 그대로 수평적인 문화가 잡혀있어요. 팀원들이 너무 좋아서 인턴을 하면서 가장 크게 얻어 가는 것 중 하나가 사람이라는 생각이 들 정도에요. 첫 직장에서 팀원들을 너무 잘 만난 것 같아서 감사하며 다니고 있습니다. 혹시라도 저희 팀에 지원하시게 된다면 좋은 사람들은 보장해드릴 수 있을 것 같네요 ^^초희의 사원증과 중요해 보이는 인터네셔널한 서류!!!!! ----------------오늘 인턴 직무 인터뷰 어떠셨나요?미미박스, 그리고 글로벌 커뮤니케이션에 대해 조금은 이해가 가셨는지 모르겠어요~.~다음 직무는 요즘 핫한 데이터와 관련된 직무가 될 예정이니 궁금하신 점 있으신 분들은아래 댓글을 쑝 달아주세요!클라라가 친절하게 직접 여쭤봐드리겠습니당 호호홍그럼 다음에 또 만나요, 제바아아아아아알~----------------오늘 인턴 직무 인터뷰 어떠셨나요?미미박스, 그리고 글로벌 커뮤니케이션에 대해 조금은 이해가 가셨는지 모르겠어요~.~다음 직무는 요즘 핫한 데이터와 관련된 직무가 될 예정이니 궁금하신 점 있으신 분들은아래 댓글을 쑝 달아주세요!클라라가 친절하게 직접 여쭤봐드리겠습니당 호호홍그럼 다음에 또 만나요, 제바아아아아아알~

비트윈에서는 서비스 초기부터 HBase를 주요 데이터베이스로 사용하였습니다. HBase에서도 일반적인 다른 NoSQL처럼 트랜잭션을 제공하지 않습니다. HBase, Cassandra와 MongoDB는 하나의 행 혹은 하나의 Document에 대한 원자적 연산만 제공합니다. 하지만 여러 행에 대한 연산들을 원자적으로 실행할 수 있게 해주는 추상화된 트랜잭션 기능이 없다면 보통의 서비스 개발에 어려움을 겪게 됩니다. 비트윈 개발팀은 이런 문제를 해결하기 위해 노력했으며, 결국 HBase에서 트랜잭션을 제공해주는 라이브러리인 Haeinsa를 구현하여 실제 서비스에 적용하여 성공적으로 운영하고 있습니다. VCNC에서는 Haeinsa를 오픈소스로 공개하고 이번 글에서 이를 소개하고자 합니다.Haeinsa란 무엇인가?¶Haeinsa는 Percolator에서 영감을 받아 만들어진 트랜잭션 라이브러리입니다. HAcid, HBaseSI 등 HBase상에서 구현된 트랜잭션 프로젝트는 몇 개 있었지만, 성능상 큰 문제가 있었습니다. 실제로 서비스에 적용할 수 없었기 때문에 Haeinsa를 구현하게 되었습니다. Haeinsa를 이용하면 다음과 같은 코드를 통해 여러 행에 대한 트랜잭션을 쉽게 사용할 수 있습니다. 아래 예시에는 Put연산만 나와 있지만, 해인사는 Put외에도 Get, Delete, Scan 등 HBase에서 제공하는 일반적인 연산들을 모두 제공합니다.HaeinsaTransaction tx = tm.begin(); HaeinsaPut put1 = new HaeinsaPut(rowKey1);put1.add(family, qualifier, value1);table.put(tx, put1); HaeinsaPut put2 = new HaeinsaPut(rowKey2);put2.add(family, qualifier, value2);table.put(tx, put2); tx.commit();Haeinsa의 특징¶Haeinsa의 특징을 간략하게 정리하면 다음과 같습니다. 좀 더 자세한 사항들은 Haeinsa 위키를 참고해 주시기 바랍니다.ACID: Multi-Row, Multi-Table에 대해 ACID 속성을 모두 만족하는 트랜잭션을 제공합니다.Linear Scalability: 트래픽이 늘어나더라도 HBase 노드들만 늘려주면 처리량을 늘릴 수 있습니다.Serializability: Snapshot Isolation보다 강력한 Isolation Level인 Serializability를 제공합니다.Low Overhead: NoSQL상에서의 트랜잭션을 위한 다른 프로젝트에 비해 오버헤드가 적습니다.Fault Tolerant: 서버나 클라이언트가 갑자기 죽더라도 트렌젝션의 무결성에는 아무 영향을 미치지 않습니다.Easy Migration: Haeinsa는 HBase를 전혀 건드리지 않고 클라이언트 라이브러리만 이용하여 트랜잭션을 구현합니다. 각 테이블에 Haeinsa 내부적으로 사용하는 Lock Column Family만 추가해주면 기존에 사용하던 HBase 클러스터에도 Haeinsa를 쉽게 적용할 수 있습니다.Used in practice: 비트윈에서는 Haeinsa를 이용하여 하루에 3억 건 이상의 트랜잭션을 처리하고 있습니다.Haeinsa는 오픈소스입니다. 고칠 점이 있다면 언제든지 GitHub에 리포지터리에서 개선에 참여하실 수 있습니다.Haeinsa의 성능¶Haeinsa는 같은 수의 연산을 처리하는 트랜잭션이라도 소수의 Row에 연산이 여러 번 일어나는 경우가 성능상 유리합니다. 다음 몇 가지 성능 테스트 그래프를 통해 Haeinsa의 성능에 대해 알아보겠습니다.아래 그래프는 3개의 Row에 총 6개의 Write, 3개의 Read연산을 수행한 트랜잭션의 테스트 결과입니다. 두 개의 Row에 3Write, 1Read 연산을 하고, 한 개의 Row에 1Read 연산을 한 것으로, 비트윈에서 가장 많이 일어나는 요청인 메시지 전송에 대해 시뮬레이션한 것입니다. 실제 서비스에서 가장 많이 일어나는 종류의 트랜잭션이라고 생각할 수 있습니다. 그런데 그냥 HBase를 사용하는 것보다 Haeinsa를 이용하는 것이 더 오히려 좋은 성능을 내는 것을 알 수 있습니다. 이는 Haeinsa에서는 커밋 시에만 모든 변경사항을 묶어서 한 번에 반영하기 때문에, 매번 RPC가 일어나는 일반 HBase보다 더 좋은 성능을 내는 것입니다.HBase 클러스터가 커질수록 트랜잭션 처리량이 늘어납니다. HBase와 마찬가지입니다.HBase 클러스터의 크기에 따른 응답시간 입니다. HBase와 다르지 않습니다..아래 그래프는 2개의 Row에 각각 한 개의 Write, 나머지 한 개의 Row에는 한 개의 Read 연산을 하는 트랜잭션에 대해 테스트한 것입니다. 각 Row에 하나의 연산만이 일어나기 때문에 최악의 경우라고 할 수 있습니다. 처리량과 응답시간 모두 그냥 HBase를 사용하는 것보다 2배에서 3배 정도 좋지 않은 것을 알 수 있습니다. 하지만 이 수치는 DynamoDB 상의 트랜잭션과 같은 다른 트랜잭션 라이브러리와 비교한다면 상당히 좋은 수준입니다.HBase보다 처리량이 떨어지긴 하지만, 클러스터가 커질수록 처리량이 늘어납니다.HBase보다 응답시간이 크긴 하지만 클러스터 크기에 따른 변화가 HBase와 크게 다르지 않습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

안녕하세요 크몽 개발팀입니다. 오늘은 일상적인 'IT 이야기'가 아닌 제가 맡고 있는 직책인'프론트엔드 개발자(Front-End Developer)'에 대해 포스팅을 해보고자 합니다.여러분들은 혹시 'Front End'라는 용어에 대해 알고 있으신가요? 저도 제일 처음 이 단어를 들었을땐 이게 대체 무슨 단어인가 했습니다.이 용어 외에도 'Back End'라는 단어도 있는데요, 물론 처음만나는 단어가 두개인만큼 두배로 어려워보일 수 있겠지만.. 놀라셨을 가슴 한번 쓸어내려드리고 전~혀 어렵지않다는 것을 차차 설명해드리겠습니다.----------------------------------------------------------------------------------------'프론트엔드'란??우선, 'Front End'라는 단어는 어떤의미의 단어일까요? 'W사'의 사전을 통해 알아보겠습니다.   한마디로 말씀드려서 '프론트엔드'는 사용자들에게 보이는 영역을 책임을 지는 것이며 '백엔드'는 시스템적인것으로 눈으로 보이지는 않지만 말 그대로 뒤에서 전산 처리를 하는 것을 말합니다.즉, '프론트엔드'는 시스템적으로 멋지게 만들어진 아이맥의 내부를 감싸는 껍데기를소비자들이 사고 싶게 만드는 디자인으로 구현하는 작업을 말하는 것입니다.크몽의 '조너선 아이브'같은 존재(?)라고 말씀드릴 수가 있겠군요.. 하하하하 (자뻑 죄송합니다(__);;)  '프론트엔드 개발자'의 목표는?'프론트엔드 개발자'의 미션은 두가지라고 말씀드릴 수가 있습니다.    첫번째로, 사용자들이 홈페이지를 친숙하고, 직접적으로 보여지도록 개발하는 것인데 딱 두가지!! 개발스킬과 미적감각을 동반하여야 합니다.여기서 중요한점은!! 쿤이는 디자인을 좋아라하지만 영감이 떠올릴만한 미술관과는 거리가 있다는 점점점점점점...앞으로 열심히 다녀보겠습니다!다시 본문으로 돌아가서..두번째는, 끊임없이 변화하는 웹세상에서 어떤툴과 테크닉을 썼는지 알고 있어야 한다는 점입니다.이 부분은 변화를 사랑하는 쿤이에겐 식은죽 먹기보다 쉽다고 하는게 맞겠네요!! (제발 그렇다고 해줘요..ㅠㅠ) '프론트엔드 개발자'가 쓰는 툴은?'프론트엔드 개발자'가 쓰는 툴의 몇몇은 웹사이트의 UI를 개발하는 툴에서 구할 수 있습니다. 첫번째로, 'HyperText Markup language'라고 불리는 'HTML' 되겠습니다.이 마크업언어는 어떤 웹사이트에서 중추적인 역활을 하는 그런 녀석입니다. 이 녀석은 말이죠... 자신의 이름을 문서의 앞뒤에 안써주면 자신의 정체도 모르는 그런녀석이구요,이 녀석의 명령어(태그)를 쓸땐 말이죠 명령어 끝에 닫는태그를 안해주면 크게는 문서 전체를 뒤죽박죽으로 만드는 그런 녀석이에요.어떨때는 파트너('CSS')와 함께 어디 놀러갈땐 각 장소(인터넷 익스플로어, 크롬 등..)에 따라 다른 매력을 발산해줘서 양파같이 까도까도 속을 모르는 그런 녀석이에요.두번째는, 'Cascading Style Sheet'라고 불리는 'CSS'입니다이 스타일 시트는 프레젠테이션효과를 주며 우리의 웹사이트가 단 하나밖에 없다는 희귀성을 부여할 수 있습니다. 이 녀석은 아까 말씀드렸듯이 'HTML'의 파트너에요. 남자는 여자하기 나름이란 말과 같이 'HTML'은 'CSS'하기 나름이라고 말씀드릴수가 있을 것같네요. 직접적으로 말씀드리자면 'HTML'이 몸이라고 보시면 'CSS'는 옷입니다. 'CSS'가 어떻게 스타일을 주는가에 따라서 웹사이트가 최신스타일룩을 보여줄 수도 있으며 잘못 쓴다면 90's 힙! to the 합!스타일을 보여 줄 수도 있습니다. 그래서 많은 사이트들이 사용자들에게 직접적으로 보여지는 스타일에 대해 신경쓰는 것이 이러한 이유라고 말씀드릴 수가 있습니다.세번째는, 'Content Management System'인 'CMS'입니다우리 한글로 표현하자면 내용관리시스템이란 것인데 아마 생소하실 것이라고 생각 듭니다. (실은 저도 생소했습니다ㅎㅎ)이 녀석은 한마디로 웹 사이트의 내용을 관리하는 시스템인데요.내용 관리 애플리케이션('CMA')과 내용 배포 애플리케이션('CDA')이 있는데요,그냥 약자로만 봤을 때엔 저기 아무 증권사나가서 한번쯤은 가입해야 될 것같은 분위기죠? 단호하게.. 아닙니다!! 연이자 2%할 것같은 'CMA'가 하는 일은 'HTML'에 들어갈 내용, 변경, 제거 등의 관리 프로그램이고,왠지 아이들의 미래를 위해 들어야될 것같은 'CDA'는 웹 사이트의 모든 수치(현행화)를 보고 편집할 수 있는 정보편집 프로그램입니다.우리가 흔히 볼 수 있는 형태로는 웹 기반 편찬(마법사템플릿 등), 형식 관리, 계정 제어, 데이터의 색인,테이터 탐색, 키워드 검색 등이 있을 수 있겠습니다.프론트엔드 개발자가 유의할 점은?프론트엔드개발자는 다음 두가지의 사항에 대해 유의해야 합니다.첫번째는, 접근성입니다. 앞서 말씀드렸듯이 이용자들에게 친숙한 모습으로 다가가야합니다.한번도 보지도 듣지도 못한 그런 UI로 이용자들에게 다가간다면 과연 잘 사용할 수 있을지가 문제일 겁니다.그런 맥락에서 말씀드리자면 모든기기에서 항상 똑같은 모습으로 이용자들을 맞이한다면각 기기에서 최적화 되지못한 화면들이 나와 이용자들에게 혼란을 줄지도 모를 일입니다.그렇기때문에 동적인 사이트를 만들어야 된다는 생각을 프론트엔드 개발자는 생각하고 있어야합니다.두번째는, 사용 간편성입니다. 만약 접근성이 좋아졌다고 하더라도 검색엔진에 최적화되지않은 사이트라면전세계적 검색사이트인 G사에서 사이트안의 컨텐츠와 연관된 내용을 검색하더라도 상위에 랭크 안되는 경우가 많습니다.그렇게 된다면 검색사이트로 원하는 사이트를 찾아들어가는 지금으로는 많은 잠재이용자들의 유입을 막아 더 이상 서비스가 성장하지못하는 상황까지 갈 수 있습니다.---------------------------------------------------------------------------------------- 이렇게 제가 하는일에 대해 포스팅을 하다보니 제가 맡은 업무가 우리 크몽서비스에 얼마나 큰 영향을 주는지 알 수 있었는데요... 갑자기 제 어깨에 곰한마리가 앉은 것같은 느낌이 드네요ㅠㅠㅠㅠ (아~ 피로야가라~!!!) 지금까지 제가 공부한 내용들을 간략하게 포스팅해보았는데요.담번엔 배운것들을 쓰는 과정을 시간이 허락한다면 보여줄 수 있는 포스팅으로 찾아 뵙겠습니다. :)#크몽 #개발자 #개발팀 #프론트엔드 #인사이트 #팀원소개

앱 삭제수 분석이 중요한 이유모든 비즈니스에서 사용자 획득만큼 중요한 있다면, 기존의 고객들이 지속적으로 서비스/상품을 찾고 사용하도록 만드는 것입니다.특히, 모바일 앱 서비스의 경우 사용자가 손가락을 한번 움직이는 것만으로 스마트폰에서 앱을 삭제할 수 있기 때문에, 사용자 유지에 더욱 신경 써야 할 수 밖에 없습니다. 실제로 다수의 조사에서, 앱 설치 후 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]로 언제든 연락주세요! 앞으로도 와이즈트래커는 단순한 분석 데이터 제공을 넘어, 고객사가 데이터를 통해 인사이트를 얻고 지속적으로 성장하는데 도움이 되도록 노력하겠습니다. * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #앱마케팅 #마케터 #인사이트 #성과분석 

스팀헌트 프로젝트를 시작한지 1년 반, 남들은 제품 만들기도 전에 백서 하나로 ICO부터 해서 돈 부터 끌어모아서 사업하는 이바닥에서 우리는 거꾸로 제품부터 만들어 1년 넘게 운영하다가 이제 IEO (Initial Exchange Offering)를 통해 펀드를 모집하고 있다. 우리가 이렇게 정 반대의 트리를 타게 된 1년 반의 여정을 아주 솔직하게 풀어보려고 한다.1. 심플한 시작2017년 여름. 비트코인이 2천불을 넘어 고공행진을 하려 용트림을 하던 그 시기. 이 글을 읽는 대부분의 사람들처럼 우리 팀 역시 이 "대세"에 합류하고자 블록체인 사업에 뛰어들었다.솔직히 세상을 바꾸겠다는 포부나 사토시 나카모토의 이상을 실현한다는 둥의 그런 거창한 목표따윈 있지도 않았다. 제품 개발을 즐기는 우리들에게 (그래서 해카톤 나가서 상 타오는게 취미인 우리들에게) 블록체인이란 그저 신기하고 재미난 장난감, 그리고 잘만 하면 뭔가 용돈벌이좀 되겠다는 생각이 전부였다.우리 팀은 원채 소셜쪽에 관심이 많았기에 (이 전에 했던 제품 역시 바크 (Bark)라는 개가되어 짖어보자는 요상한 컨셉의 소셜 앱이였다), 자연스럽게 스팀 (Steem)이라는 블록체인에 관심을 갖게 되었다. 솔직히 스팀잇 (스팀 블록체인에서 돌아가는 최초의 DApp) 보다는 컨텐츠와 보팅이라는 단 두개의 아주 심플한 단위를 가지고 복잡한 토큰 경제가 결합된 댑을 만들 수 있다는 점에 매료되어 미친듯이 스팀 위에서 할만한 아이템을 찾게 되었고, 마침 우리가 활발하게 활동하고 있던 "프로덕헌트 (https://www.producthunt.com/)"에 스팀 토큰 경제를 붙이면 뭔가 그림이 나올것 같다는 생각이 들어 바로 5개월동안 하던거 다 제껴두고 제품 만들기에 들어갔다.2017년 10월 31일 우리 이런거 개발중이라고 스팀 커뮤니티에 처음 공개한 글 - Introducing SteemHunt: Steem Fueled ProductHunt - Make money by discovering cool products every day(남들 팀 짜고 백서 부터 만들어서 신나게 ICO로 돈 긁어모으고 있을때 우리는 이러고 있었다...)2. 단 100명이지만 뜨거웠던 초기 유저드디어 2018년 3월 5일, 스팀 커뮤니티에 두둥~! 하고 스팀헌트라는 제품을 선보였다. 스팀헌트는 테크 얼리어답터들이 인터넷에서 발견한 테크 관련 신박한 제품들을 "나 오늘 이런거 발견했는데 어떰? ㅇㅈ?" 이런 느낌으로 간단하게 공유하고, 서로 니꺼가 쿨하네, 내꺼가 더 ㅇㅈ네 하면서 랭킹 경쟁을 벌이는 커뮤니티 사이트 이다. 이걸 스팀 위에서 돌림으로써, 저런 서로의 덕후심을 뽐내는 이들이 스팀 토큰 보상을 받을 수 있어 더욱 덕후활동을 더 열심히 하게 만드는 댑 (DApp) 인 것이다.우리가 비록 두명밖에 없는 작은 팀이지만 제품 하나 만드는 솜씨는 솔직히 그 어떤 스타트업들과 비교해도 자신 있었기에 당시 현존하는 블록체인 기반 댑들 중에서 가장 수려한 인터페이스를 (그냥 우리끼의 착각일수도 있는) 자랑하는 제품을 선보였다는 자아도취감에 빠져 있었다.2018년 3월 5일에 발표한 런칭 공지 - Introducing Steemhunt: Daily ranking of effortlessly cool products fueled by STEEM blockchain그러나 (바로 스팀 커뮤니티를 정복할거라고 자신했던) 기대감과는 다르게 초기 3달간 유저는 50-100명 수준을 맴돌았다. 사실 지금에와서 생각해 보면 처음부터 유저가 급작스럽게 늘지 않고 아주 적은수의 열성 유저들로만 2-3개월을 보낸것이 현재 헌트 플랫폼으로 발전시키게 된 원동력이 되었다.이 초기 100명의 유저가 얼마나 열성적인 유저였냐면, 그 당시 우리가 보유한 스팀파워가 아주 초라한 수준이었기 때문에 스팀헌트에 열심히 헌팅한다고 아무런 돈도 되지 않던 그 시절, 매일같이 하루도 빠짐없이 제품을 발견해서 헌팅하고, 서로 발견한 제품들 토론하면서 재밌어하고, 심지어 우리가 부탁하지도 않았는데 알아서 우리 제품을 유투브, 레딧 등에 매일같이 홍보하는 100명의 유저가 생겼다.(스팀헌트 시작한 날부터 무려 1년 넘는 시간동안 하루도 안빠지고 유투브에 스팀헌트 관련 영상을 올려주는 유투버이다. 물론 하루에 제품도 2-3개씩 공유하는 열성 헌터이다.)3. 토큰 경제를 붙이면서 드디어 비상 - 전 세계 댑 순위 7위까지 등극그 당시 수 많은 ICO들이 "유틸리티" 토큰을 주장하며 모금했던 수십 수백억이 시장에서 증발하던 시기였다. 우린 이런 생각을 하기 시작했다. 사탕 사먹으라고 발행한 백원짜리 동전을 손에 쥔 백명의 사람들이 사실 사탕 사먹으려는게 아니고 모두 이백원, 삼백원에 팔기위해 손에 쥐고 있는 사람들로 채워지니 그놈의 "유틸리티"가 생길리가 있나...그래서 우리는 커뮤니티를 유지/발전시키는 핵심 활동들, 그리고 그 공헌도를 매일 정량화시켜 토큰 바운티 보상으로 결합시켜서 무려 1년간 토큰 유틸리티를 만드는 실험인 헌트 토큰 바운티 프로그램을 시작했다. 특히, 헌터 활동의 리워드 풀을 형성하기 위한 스팀파워 임대를 기반으로 헌트 토큰을 가치로 환산해서 스왑해주는 스폰서 프로그램도 같이 시작하였는데, 이게 스팀 커뮤니티에서 대 히트를 치면서, 정말 유저 그래프가 아래처럼 치솟는 경험을 하게 된다. 이 무렵 스팀잇 재단으로부터 그 당시 싯가로 10억이 넘는 금액인 백만 스팀파워를 임대 투자 받으면서 스팀헌트는 스팀 커뮤니티의 명실상부한 탑 10 댑 (DApp)의 지위를 얻게 된다. 특히 전 세계 약 2,600개의 댑들의 실제 트랜젝션 데이터를 기반으로 매일 랭킹이 매겨지는 권위있는 사이트인 스테이트오브더댑스 (State of the DApps)에서 2019년 1월에는 전체 7위를 하기도 했다. 이 후에도 항상 상위 20위권을 계속 유지중이다. 특히 도박, 게임류를 제외한 소셜부문은 전체 5위를 계속 유지중이다. 4. 고난의 길 - 어뷰저와의 반년간의 처절한 싸움사실 조금 극단적으로 말하면, 이걸 경험해 보지 않은 대다수의 리버스 ICO들은 단언컨데 토큰 경제를 붙이는 순간 폭망할 것이다. 왜냐면 어떤 서비스더라도 '보상'행위가 붙는 순간 시스템을 어뷰징해서 더 많은 보상을 타가고자 하는 지능적인 어뷰저들이 대거 달라붙게 되고, 이를 시스템적으로 개선하지 못하면 아무리 백만, 천만단위를 자랑하던 서비스더라도 유저들이 일장춘몽처럼 사라지게 된다.우리 역시 리워드 풀의 규모가 커지면서 대규모의 지능적인 어뷰저들의 공격을 받기 시작했다. 이들과 싸우는 처절한 전투 이야기를 여기서 다 풀면 글이 너무 길어지기에, 짧게 요약하면, 우리는 이들의 행위를 시스템적인 디텍션 알고리즘과 커뮤니티기반의 감시 시스템, 그리고 공헌도에 대해 상대적으로 검증하는 유저 스코어 시스템을 도입하여 스케일이 가능한 수준으로 발전시켰다. 지금은 우리의 이 노하우를 다른 스팀 댑들과도 공유하는 블랙리스트 / 화이트리스트 데이터베이스까지 운영할 정도로 우리의 토큰 모델은 다른 어떤 블록체인 기반 댑들이나 리버스 ICO 프로젝트들과 비교해도 월등한 수준이라 자신한다.https://github.com/Steemhunt/whitelist/blob/master/steemhunt/blacklist.json5. 덕후심을 메이커에게 팔 수 있는 토큰 경제 - 헌트 플랫폼으로 확장스팀헌트가 이제 월 6-10만 정도의 트래픽, 온체인에서 15,000명 이상의 헌터들이 활동하는 유저 기반이 쌓이고, 온-오프 체인 기반의 토큰 모델이 정교하게 결합된 헌트 토큰 경제를 운영하다 보니, 이제 판을 더 크게 키우고자 하는 포부가 생기게 되었다.특히, 그간 숱하게 생겼다 사라진 "리워드 기반의 보상형 소셜" 댑들의 가장 큰 문제는 바로 이건데,유저들이 벌은 저 토큰의 사용성은 그래서 무엇?이거에 대해 명확한 답을 제시할 수 있는 댑 프로젝트가 많지 않은게 현실이다. 우리는 이에대한 해답으로, 스팀헌트라는 순수 커뮤니티를 기반으로 이들의 덕후심, 즉 얼리어답터들의 테크 제품에 대한 지식, 열정, 전파력등을 기업들이 자유롭게 활용 가능한 인플루언서 기반의 거래 플랫폼으로 발전시키는 헌트 플랫폼 계획을 발표하였다.헌트 플랫폼은 크게 다음 세가지 레이어로 돌아가는 메이커와 테크 얼리어답터간의 연결 플랫폼이다.커뮤니티 레이어: 광고 모델이 필요 없는 자생가능한 테크 커뮤니티인 스팀헌트가 플랫폼 전체의 기반 레이어로서 얼리어답터를 생태계로 공급하는 역할을 담당한다.댑/서드파티 레이어: 테크 메이커가 얼리어답터들과 다양한 형태의 가치교환이 가능한 리뷰헌트, 아이디어헌트와 같은 댑이 운영됨으로써 토큰의 사용성을 제공한다.메이커/컴퍼니 레이어: 얼리어답터들의 전파력을 활용하여 신제품 런칭의 파급력을 높이고자 하는 테크 메이커들을 지속적으로 유입시킨다.즉, 요약하면 스팀헌트를 통해 꾸준히 유입되는 테크 덕후들을 기업들이 리뷰헌트를 통해 다양한 리뷰 캠페인 거래를 제안할 수 있고, 아이디어헌트를 통해 크라우드펀딩을 진행함으로써 그들의 신제품 런칭에 테크 덕후들을 엮어서 런칭 버즈를 최대화 할 수 있는 플랫폼이다.이렇게 기업들이 테크 덕후들의 자원을 활용하기 위해 헌트 토큰을 사용하고, 헌터들 역시 기업들이 리뷰를 위해 할인된 가격으로 판매하는 제품들을 구매하거나 크라우드펀딩에 참여하기 위해 헌트 토큰을 사용함으로써 헌트 토큰이 계속 순환되는 경제를 만들고자 함이다.6. 우리의 아주 현실적인 포부우리가 하려는 헌트 플랫폼은 사실 탈중앙화로 세상을 바꾸는 것도, 어려운 기반기술로 나같은 문돌이들은 1도 이해 못할 메인넷 비전을 팔려는 것도 아니다. 우리의 비전은 사실 아주 심플하다.기업들이 테크 덕후들을 활용하여 글로벌 단위의 제품 런칭 마케팅을 펼칠 수 있는 가장 쉬운 플랫폼 구축지금까지는 기업들이 이런 얼리어답터들을 타겟팅 하려면 레딧이나 프로덕헌트, 혹은 테크 리뷰어들을 일일이 찾아서 마케팅을 제안하는 방식이였다. 특히 레딧은 각 서브레딧마다 고유의 문화와 룰이 있기 때문에, 거기에서 열심히 활동한 사람이 아니면 절대 접근 불가능한 속성도 존재한다.헌트 플랫폼은 이런 테크 덕후들이 스팀헌트라는 놀이터에 모여있고, 기업들은 리뷰헌트를 통해 이들에게 자신들이 근거지로 활동하는 레딧, 해커뉴스, 유튜브 등 각 채널에서의 리뷰 마케팅을 제안하고, 아이디어 헌트를 통해 이들만을 위한 한정판 발매, 제품 우선권등을 거래할 수 있는 크라우드 펀딩이 결합되어, 기업 입장에서는 비교적 저렴한 자원으로 효율적인 런칭 마케팅을 진행할 수 있는 플랫폼을 만드는 것이 우리의 목표이다.7. 아주 현실적인 팀과 커뮤니티스팀헌트 팀은 사실 단 두명이다. 이 글을 쓰고 있는 내가 (조영휘) 디자인과 마케팅을 담당하고 있고, 다른 한명 (김동혁)이 혼자서 개발을 도맡아 하는 중이다. 우리가 굳이 이렇게 극단적인 린 팀 (Lean Team)을 운영하는 이유는 (돈이 모잘라서이기도 하지만) 팀은 유저 스케일이 커지면서 거기에 fit이 가장 맞는 사람으로 충원해야 한다는 철학이 있기 때문이다.솔직히 아직 제품도 없고 유저도 없는 팀이 벌써 CEO, CSO, COO, CTO등등 C 레벨만 5명 이상, 개발, 운영 포함 수십명짜리 팀을 구성하는건 우리 철학에 맞지 않는 방식이다. 유저 스케일이 커지게 되면 원래 설계했던 R&R이 180도 바뀌게 마련인데 이걸 미리 예측해서 팀을 짜는게 절대로 불가능하기 때문이다.그러나 하루 수백개의 제품이 공유되고 수만명의 헌터들의 커뮤니티 관리를 위해서는 당연히 대규모 인력이 필요할 수 밖에 없다. 그래서 우리가 고안한 방법은 커뮤니티 관리 역할을 커뮤니티에서 선출하여 운영하는 매니저, 모더레이터, 큐레이터 롤 이다.우선 팀 급의 인력은 위에 설명한 두명의 팀원에 커뮤니티에서 선출된 두명의 매니저를 충원하여 운영하고 있다. 여기에 더해 커뮤니티에서 선발된 총 10명의 모더레이터가 커뮤니티에 공유되는 모든 컨텐츠를 점검하고, 저작권 침해 가능성을 방지하는 역할을 하고, 큐레이션 기여도가 가장 높은 상위 20명이 매주 선발되 visibility가 저조한 우수 컨텐츠들을 발굴하여 추천하는 역할을 수행하고 있다.8. 우리는 제품 전문가입니다모든 팀이 각기 자신 있는 분야가 있듯이, 우리 스팀헌트 팀이 가장 자신 있는 부분은 "섹시한 제품"을 만드는 것이다. 그게 블록체인 기반이던 아니던 상관 없이, 우리가 지금까지 그래왔고, 앞으로도 집중할 부분은 실제 유저가 열광하게 만드는 제품을 만들어서 pump and dump에 기반한 가치가 아닌 실 유즈 케이스에 기반한 가치를 만드는 일이다.우리의 이런 여정에 함께할 투자자를 IEO (Initial Exchange Offering)을 통해 모집 중이고, 이미 지난 3월 14일 - 18일까지 IDCM에서 진행한 1차 IEO에서는 타겟 금액의 146% 이상이 모이면서 성공적으로 완판이 되었다.뭔가 기승전토큰세일홍보로 글이 귀결되는듯 하여 심히 미안한 마음이 들긴 하지만, 혹시라도 제품도 없이 출처 불명의 (혹은 성사 가능성이 모호한) 각종 파트너십, 협약 등으로 점철된 토큰 세일에 지쳐 뭔가 다른 프로젝트 투자처를 물색하고 계신 분이라면, 우리 프로젝트를 한번 살펴봐주길 바라는 마음에 우리 2차 세일즈에 대한 홍보를 하고자 하니, 이 홍보가 거북하신 분은 여기서 창을 닫아 주시면 감사하겠다.헌트 플랫폼의 2차 세일즈는 3월 22일 (금) 부터 26일 (화)까지 프로비트 거래소에서 진행될 예정이다. 특히 이번 세일즈에서는 IEO 최초로 스팀 토큰을 지원하는 점 때문에 스팀 커뮤니티에서도 큰 관심을 받고 있다.IEO 페이지 확인 - https://www.probit.kr/ko-kr/ieo/hunt-round1/0글로벌 프로젝트인 만큼, 우리 공식 채팅 채널들은 죄다 English-only로만 운영중이다. 이에 한국 투자자분들의 불편을 해소하고자 IEO를 위한 임시 카카오톡 채팅방도 운영중이다.https://open.kakao.com/o/g1odiHhb혹시 이 프로젝트가 진짜로 어떻게 돌아가고 있는지, 헌터들이 어떤 식으로 활동하고 다니는지를 알아보고 싶으신 분은 우리 공식 디스코드 채널에 조인하시면 모든 커뮤니티 활동을 모니터링 할 수 있다.https://discord.gg/Zda7Trs스팀헌트 프로젝트의 모든 공식 발표는 스팀헌트 스팀잇 블로그를 통해 이루어지는데 아쉽지만 영어로만 발표된다 (한글버전은 내 개인 스팀잇 블로그인 @project7을 통해 확인할 수 있다).https://steemit.com/@steemhunt