스토리 홈

인터뷰

피드

뉴스

조회수 2439

JANDI 검색엔진 도입기

이번 포스트에서는 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 #개발자 #개발팀 #개발후기 #인사이트
조회수 1146

제니퍼소프트가 말하는 APM의 진짜 가치(2)

어떤 APM에 투자해야 하는가?APM 분야가 당초 기대를 뛰어넘는 수준의 효과를 발휘하고 있다는 사실에는 의심의 여지가 없다. 아울러 APM 솔루션을 이용하는 층이 더 넓어지고 있다는 점 역시 사실이다. 그러나 정작 어떤 APM 솔루션이 적합한지에 대해서는 오히려 혼란스러운 측면이 있다. 접근법, 방법론 등이 다양하고 이에 따라 정보가 넘쳐나고 있기 때문에 더욱 그렇다. 각각의 기업 환경에 적절한 APM을 선택하기 위해서는 먼저 그간 흐름을 살펴볼 필요가 있다.2010년 즈음에는 APM의 역할 범위에 대한 정의를 두고 논란이 있었다. 크게 WAS 성능 모니터링과 엔드투엔드(BTM, EUM) 모니터링으로 업계의 시각이 갈렸다. 그 이유는 애플리케이션 상태를 최적으로 유지하기 위해 ‘어떤’ 애플리케이션 대해, ‘어디’를, ‘어떻게’ 관리해야 하는지를 두고 벤더마다 관점이 달랐기 때문이었다.이러한 논란은 사실 아직 완전히 끝난 것은 아니다. 그러나 WAS APM 분야의 성장세가 더 두드러지고 있으며, 이를 APM으로 정의하는 분위기가 확산되고 있다. 모든 비즈니스 트랜잭션을 모니터링(BTM)하고 관리하는 솔루션의 경우 방대한 커스터마이제이션 및 유지보수 업무가 수반되며, 이에 따라 특정 업종에 한정적인 SI 분야의 특성을 보이고 있기 때문이다. WAS APM을 중심으로 어떤 APM을 선택해야 하는지를 정리하면 다음과 같다. - 안정성 높은 제품: 안정성은 APM의 가장 중요한 부분임에는 두말할 여지가 없다. APM 기술적인 특성상 웹 서비스의 중추를 담당하는 WAS와 함께 동작하기 때문이다. 이러한 이유로 WAS에 영향을 최소화하여 모니터링 하는 기술은 APM의 가장 중요하고 미션크리티컬한 사항이다. 다양한 고객의 환경에서 검증된 제품이 아닐 경우에는 도입 시 수많은 테스트를 거쳐야 하는 등, 추가적인 비용이 발생할 수 있다.- 실시간 모니터링이 가능한 제품: APM을 도입하는 주요 이유는 문제가 발생할 때 이를 빠르게 파악하고 이를 쉽게 해결할 수 있도록 하는 위해서다. 이를 위해서는 현재 수행되고 있는 서비스를 모니터링 하여 병목이 되는 원인을 빠르게 찾는 것과, 샘플링되지 않은 초 단위 성능데이터를 모니터링 하여 실제 문제가 발생하는 시점에 이를 인지하는 것이 중요하다.- 지속적인 업그레이드를 반영할 수 있는 패키지 제품: APM제품은 패키지 제품으로 지속적인 업그레이드를 통해 기능을 개선하고 발전해 나가야 한다. 고객의 환경에 따라 개발이 다르게 된다면, 지속적인 기술 개발을 통한 업그레이드를 하기 어렵다. 고객은 한번의 투자로 지속적으로 모니터링을 해야 하는데 SI가 필요하다면 지속적으로 투자가 되어야 하고 이는 ROI를 개선할 수 없다. SI가 필요한 제품의 경우 차세대나 새로운 서비스를 오픈 할 경우 추가 비용이 발생한다. 반면 패키지 제품의 경우는 별도의 비용 없이 오히려 추가로 업그레이드되는 기능을 지속적으로 제공 받아 더욱 활용도가 높아지게 된다.- 직관적인 UI/UX를 통해 즉각적인 장애 인지가 가능한 제품: APM의 중요성이 높아지면서 누구나 어렵다고 생각하는 APM을 쉽게 활용할 수 있도록 하는 것은 기업입장에서 많은 장점을 가진다. 특히 수많은 관제실에서 활용되고 있는 제니퍼 대시보드는 서비스의 현재 상황을 직관적이고, 다이나믹하게 표현함으로써, 문제 발생 시 이를 즉각적으로 인지하여 빠른 시간 안에 문제를 해결할 수 있도록 돕는다. 한편 이러한 UI/UX의 지속적인 강화를 위해 제니퍼는 'JUI'라는 오픈소스 프로젝트를 진행하고 있다.- 쉬운 관리 및 통합 모니터링이 가능한 제품: 기업/조직이 비즈니스에 이용하는 웹 애플리케이션이 폭증하고 있다. 제니퍼소프트의 고객사 중에도1,000개 이상의 인스턴스를 설치해 활용하는 곳이 많다. APM을 설치, 업그레이드, 설정, 로그 확인 등의 업무를 일일이 해야 한다면 무시할 수 없는 부하가 된다. 수백, 수천 대의 서버를 손쉽게 관리하고 통합해서 모니터링 할 수 있는 기능은 필수다.- 강력한 분석 기능을 가진 제품: APM 솔루션의 핵심 원리, 즉 모니터링 하고자 하는 데이터를 수집하는 기술은 10년 전과 지금이 그리 다르지 않다. 그러나 애플리케이션 환경이 지속적으로 변화하고, 복잡도 또한 증가하고 있어서, 이에 대한 성능분석은 전문성과 지속적인 연구개발이 필요한 분야이다. 애플리케이션 성능에 대한 깊은 통찰을 바탕으로 실질적인 문제해결을 할 수 있는 분석기능을 갖추고 있는 APM을 선택하는 것이 중요하다. 웹 서비스의 확산, 이제 시작일 뿐비즈니스가 나날이 디지털화 되어가고 있다. 모바일과 클라우드라는 파괴적 트렌드는 이제 시작일 뿐이며, IoT는 완전히 새로운 서비스를 창출할 것이 확실시된다. 웹 애플리케이션의 트랜잭션이 증가하고 복잡화되는 환경 속에서 기업은 필수 애플리케이션의 성능을 보장하면서도 확장성과 대응성을 확보할 방안을 고민해야 할 시점이다. 과거 ‘있으면 좋은 제품’에서 이제 모든 기업들의 ‘꼭 있어야 하는 제품(Must Have)으로 진화한 APM의 진짜 가치를 발견하길 바란다.
조회수 1199

체스 말의 시각에서 벗어나기

아 이건 이래서 안될 것 같고, 저래서 안될 것 같은데.. 이 시장은 없어.이 기능은 안쓸거야.. 이건 연매출 10억은 할 수 있어도 1000억은 못할 것 같은데..최근의 고민이었다. 사업을 시작하고 나이가 들면서 경험은 강화됐고, 지적으로도 많이 성장했다. 그런데, 오히려 그러한 지적 성장은 오히려 나를 아무것도 못하게 만들었다. 어떠한 행위를, 어떠한 아이디어를 실행에 옮기고자 할 때, 그것이 안 되는 이유가 수백 가지가 떠오른다. 계속해서 이길 수 없는 이유만이 내 머릿속을 떠돈다. 그것을 깨버리고 이기는 전략을 짜려니, 머릿속에 콘셉트들의 파편만 떠돌아 명확하게 단순화할 수 없는 지경에 이르렀다.그렇게 비캔버스로 여러 아이디어를 끄적이던 도중, 내 시각이 체스 말의 시각 같다는 생각이 들었다. 수없이 죽고 죽어 체스판 위에서 사라진 체스 말이 잔뜩 움츠려 들어, 어디로 이동해야 하는지 좁은 시선으로 찾아보듯 나 또한 지고 싶지 않다는 이유로, 편협하고 미시적인 시각으로 '지지 않을 방법'만 찾고 있는 것 같았다.그제야, 내가 체스 말 안에 들어가서 세상을 보고 있었다는 것을 깨달을 수 있었다. 사업에서 버려야 할 것은 감정인데, 내 감정이 지나치게 많이 들어가 있었다. 마치 '사업=나=비캔버스'와 같은 사고방식으로 인해, 지고 싶지 않은 마음이 매우 감정적으로 내 사고방식을 틀어막고, 시야를 좁히는 꼴이었다.이제까지는 지지 않기 위한 전략을 찾기 위해 사업의 전체적 콘셉과 무관한 서비스의 특정 기능과 같이 아주 작은 부분에서의 변화를 주도해왔다. 그러나 '체스 말에서 기어 나와 체스판을 바라보자'라는 시각은 내 모든 것을 흔들고 있다.이 미세한 마인드 컨트롤이 끼치는 영향은 생각보다 크다. 마치 사격을 할 때, 사격하는 입장에서 아주 조금만 각도를 틀어도 수백 미터 떨어진 곳에서는 큰 각도의 차이를 가져오는 것과 같다.사업을 해본 사람이라면 알겠지만, 정신적, 심리적 무능감과 박탈감, 좌절감은 사업의 성과와 상관없이 찾아온다. 매일 밤, 가슴 뛰는 콘셉과 아이디어가 떠올라 설레는 마음으로 잠들더라도, 아침에 일어나면 수십 가지의 '안 될 이유'가 머릿속을 감싸는 것이 현실이다. 자신감과 확신은 매일, 매 시간, 매 분 파도처럼 들썩인다.혼자서도 수많은 생각을 했지만, 사실 체스 말 안에서의 고민은 이러한 현상을 해결하는 데 도움을 주지는 않았던 것 같다. 나의 약 반년의 걸친 심리적, 정신적 무능감과 박탈감을 이겨낼 수 있게 도와준 것은, 단 몇 권의 책과 몇 편의 영화, 그리고 약 1주일간의 미국 출장이었다. 즉, 체스 말 바깥으로 나와 내가 바라보는 세상을 확장할 때, 오히려 그 효과가 크다.운동과 같이 나의 한계를 이겨내는 것은 나를 채찍질하여 이겨낼 수 있으나, 사업은 나의 한계를 이겨낸다고 해서 이기게 만들 수 있는 것이 아니기 때문에, 오히려 '이기기 위한 전략'을 만들어 내기 위해 물불을 안 가리는 것이 더 중요하다고 생각한다. 고객을 만나던, 사람들 만나던, 영화를 보던, 여행을 가던, 책을 보던, 무슨 수를 써서라도 이길 수 있는 전략을, 이길 수 있는 콘셉을 떠올리는 게 중요한 것 같다.일본의 기업인 고야마 마사히코는 사장에게 가장 중요한 것은 '속전속결'이라고 말하였다. 다양한 의사결정이나 문제에 대해 70%의 확신 만으로도 빠르게 결정을 내리는 것이 중요하다고 말한다. 근데, 사업이 감정이 많이 들어가면 들어갈수록, 더 시각이 좁아지면 좁아질수록 100%의 확신으로 결정을 내리고 싶어 하게 된다.감정을 버리고, 냉정하게 체스 말 하나가 죽더라도 체스판에서 승리하면 된다는 생각으로 시각을 전환하면 조금은 더 결정을 더 빠르게 더 과감하게 내릴 수 있게 되는 것 같다.횡설수설하였지만, 뻔한 말로 들릴 수 있는 한 줄의 문장이 진짜 도움이 된다. 나는 자기계발 콘텐츠로 먹고 사는 사람이 아니기 때문에 한 번 믿어봐도 좋은 것 같다.체스 말에서 기어 나와 체스판을 바라보자. 유니클로의 야나이 다다시 회장처럼 1승 9 패해도, 그 1승만으로 이기는 게임을 만들어낼 수 있을지도 모른다.
조회수 4864

Gradle Dependency 분리하기

본 포스팅은 아래 코드를 보시면 좀 더 이해하기 쉽습니다.build.gradledependencies-variable.gradledependencies-classpath.gradledependencies-app.gradleGradle 의 역할Gradle 은 이제 안드로이드 개발에 있어서 그 중심이 되는 빌드 환경입니다. 안드로이드 빌드에 대한 기본 설정 뿐만 아니라 빌드에 필요한 Task 를 지정하거나 의존성을 추가할 수 있습니다.특히 의존성에서 일반적인 서비스들은 다양한 오픈소스를 활용하게 됩니다. 네트워크 라이브러리, 이미지 라이브러리, DI 라이브러리, Support 라이브러리,Play-Service 라이브러리 등등 이젠 프로젝트를 시작함에 있어서 기본적으로 10개 이상의 라이브러리를 추가하게 됩니다. 이러한 라이브러리들이 많아질수록 필연적으로 빌드 스크립트가 길어지게 됩니다. 이는 나중에 빌드에 관련된 코드를 추가/수정할 때 유지보수에 영향을 끼치게 됩니다.Gradle 의존성 분리하기토스랩에서는 꽤 많은 숫자의 라이브러릴 사용하고 있습니다. 테스트용 라이브러리들까지 포함해서 60여개의 라이브러리를 쓰고 있습니다. 이러한 라이브러리 코드들이 1개의 빌드 스크립트 안에 포함되어 진다면 라이브러리의 버전을 변경하거나 수정하는 작업을 할 때에는 불가피하게 시간이 소요될 수 밖에 없습니다.그에 따라 Gradle 에서 라이브러리들을 변수화 해서 분리하는 작업을 하였습니다.1. 라이브러리 변수화 하기ext { retrofit = 'com.squareup.retrofit2:retrofit:2.1.0' retrofit2_gson = 'com.squareup.retrofit2:converter-gson:2.1.0' retrofit2_rxjava2 = 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:2.1.0' } 가장 간단한 변수화였습니다. 하지만 Retrofit 은 관련 라이브러리들이 함께 수반되기 때문에 버전명을 다시 분리하였습니다.2. 라이브러리 버전 변수화 하기ext { retrofit_version = '2.1.0' retrofit = "com.squareup.retrofit2:retrofit:$retrofit_version" retrofit2_gson = "com.squareup.retrofit2:converter-gson:$retrofit_version" retrofit2_rxjava2 = "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$retrofit_version" } 하지만 버전명과 라이브러리이름이 함께 있는 것이 깔끔해보이진 않습니다. 그래서 아래와 같이 바꿨습니다.3. 라이브러리 이름과 버전의 분리ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] 실제에는 다음과 같이 사용하면 됩니다.dependencies { compile rootProject.ext.dependencies.retrofit2 compile rootProject.ext.dependencies.retrofit2_gson compile rootProject.ext.dependencies.retrofit2_rxjava2 } 이제 라이브러리를 변수화 해서 분리를 하였습니다.이제 변수로 지정한 라이브러리들은 build.gradle 파일안에 존재하게 됩니다.// build.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] buildscript { // blah blah } 라이브러리가 3개뿐이니 깔끔해보이는군요. 하지만 토스랩의 라이브러리는 60여개 입니다. 변수명도 60여개라는 말이죠. 그래서 라이브러리 변수들만 파일을 분리하기로 했습니다.4. 라이브러리 변수를 파일로 분리하기// dependencies-variable.gradle ext { retrofit = '2.1.0' } ext.dependencies = [ retrofit2 : "com.squareup.retrofit2:retrofit:$ext.retrofit", retrofit2_gson : "com.squareup.retrofit2:converter-gson:$ext.retrofit", retrofit2_rxjava2 : "com.jakewharton.retrofit:retrofit2-rxjava2-adapter:$ext.retrofit_rxjava2", ] // build.gradle apply from :'dependencies-variable.gradle' buildscript { // blah blah } 이제 좀 교통정리가 되어가는 기분이네요.하지만 app 의 build.gradle 을 보았습니다.// app 의 build.gradle apply plugin: 'com.android.application' dependencies { // 라이브러리 60개 compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } android { // 중략 } 뭔가 잘못되어 가고 있습니다. 여전히 dependencies 가 큰 부분을 차지하고 있습니다.5. app.dependencies 분리하기이제 dependencies 를 분리할 차례입니다.// dependencies-app.gradle repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 compile rootProject.ext.dependencies.library.okhttp3 compile rootProject.ext.dependencies.library.okhttp3_logging compile rootProject.ext.dependencies.library.stetho_okhttp3 } // app 의 build.gradle apply from: 'dependencies-app.gradle' 이제 dependencies 와 관련된 스크립트가 분리되었습니다.하지만 저 apply from 이 항상 app 의 build.gradle 에 따라 붙어야 하는 것이 아쉽습니다. 그래서 buildscript 에 아예 추가하기로 하엿습니다.6. 빌드 스크립트에 dependencies 추가 동작하기먼저 빌드 스크립트용 스크립트를 만들겠습니다.// dependencies-classpath.gradle rootProject.buildscript.repositories { jcenter() } rootProject.buildscript.dependencies { classpath rootProject.ext.dependencies.classpath.android } 그리고 buildscript 가 시작될 때 모든 dependencies 스크립트가 인식할 수 있게 하겠습니다. 인식할 스크립트는 다음과 같습니다.dependencies-variable.gradle - 라이브러리 변수 저장dependencies-classpath.gradle - 빌드용 스크립트 저장dependencies-app.gradle - 라이브러리 추가 스크립트 저장rootProject 의 build.gradle 를 아래와 같이 변경합니다.// rootProject 의 build.gradle buildscript { apply from: "dependencies-variable.gradle" apply from: "dependencies-classpath.gradle" } apply from: 'dependencies-app.gradle' 위와 같이 변경을 하면 빌드스크립트가 동작하는 시점에 변수를 인식하고 빌드용 스크립트를 인식합니다.하지만 앱용 라이브러리 추가 스크립트는 아직 준비가 덜 되었습니다. “app” 프로젝트가 인식이 된 시점에 라이브러리가 추가되어야 하기때문에 처음 만들었던 스크립트로는 한계가 있습니다.그래서 아래와 같이 변경하겠습니다.// dependencies-app.gradle rootProject.allprojects { project -> if (project.name == 'app') { project.afterEvaluate { repositories { jcenter() } dependencies { compile fileTree(dir: 'libs', include: ['*.jar']) compile rootProject.ext.dependencies.library.retrofit2 compile rootProject.ext.dependencies.library.retrofit2_gson compile rootProject.ext.dependencies.library.retrofit2_rxjava2 } } } } afterEvaluate 는 프로젝트의 인식이 완료되면 동작이 되는 함수이기 때문에 모든 것이 끝나고 dependencies 가 추가되는 것으로 이해하시면 됩니다.정리위의 과정을 거침으로써 gradle 파일은 좀 더 나뉘었지만 app 의 build.gradle 은 안드로이드 프로젝트 그 자체에 집중 할 수 있도록 하였습니다.이렇게 나누었던 본래의 목적은 의존성 라이브러리와 코드 품질 관리용 스크립트가 1개의 스크립트 파일에 담겨지면서 관리하는 데 있어서 큰 문제가 발생하게 되었습니다. 그에 따라 각각을 나누고 그 목적에 맞도록 각가의 파일 만들었습니다.라이브러리의 변수용 파일buildscript 용 classpath 를 관리하는 파일본 프로젝트의 라이브러리 의존성 관리 파일참고 소스Github : https://github.com/ZeroBrain/DataBind-MVVM-Sample#토스랩 #잔디 #JANDI #개발 #개발후기 #인사이트
조회수 2416

미니 벽지 샘플북 이벤트-기획부터 제작까지 두번째의 비하인드스토리

안녕하세요.다시 찾는 인테리어 (주) 두번째입니다.많은 고객님들이 다음과 같은 질문을 하곤 합니다. 두번째도배 홈페이지에서 제품을 볼 수도 있고시공 사례에서 사용된 벽지도 안내하고 있지만,역시 나에게 맞는 벽지를 확실히 아는 방법은직접 보고 고르는 것만큼 좋은 것은 없을 거에요.직접 벽지나 장판 샘플을 보고 싶은 분들을 위해오프라인 쇼룸도 운영하고 있는데시간이 없어서, 거리가 너무 멀어서 등의 이유로오프라인 쇼룸에 방문하고 싶어도하지 못하시는 고객님들도 많이 계셨는데요.'집에서 인테리어 준비하자!'라는 모토로방문하지 않아도 실제 벽지 샘플을 볼 수 있도록이번 무료 벽지 샘플북 이벤트를 기획하게 되었답니다^^두꺼운 샘플북 대신 간편하게 볼 수 있으면서도처음 샘플북을 받았을 때 기분이 좋아지는미니 샘플북을 제작하기 위해다양한 디자인을 구상해본 결과!깔끔하고 귀여운 원통형에미니 샘플북을 담아서 전달하기로 했어요.제작 과정 미니 벽지 샘플북의 표지와 내지에 들어갈 내용도하나하나 고심하면서 작성해나갔답니다.샘플북에서 볼 수 있는 벽지는 지금까지 도배 시공을 하면서가장 인기 있는 색상 32가지를 선별해서 구성을 했어요.샘플북 제작 비용이 생각보다 만만치 않아서이번엔 저희 직원들이 손수 벽지 재단부터 포장까지모든 과정을 정성을 들여 진행을 했어요.제작할 샘플북 크기와 수량에 맞춰서32가지 종류의 벽지를 하나하나 재단하는 과정이생각보다 공이 많이 들어가는 작업이었답니다.샘플북 크기에 맞게 잘린 벽지에는제품 번호와 이름을 스티커로 다 붙여주었어요.이 모든 전 과정이 다 수작업이라니!!!그래도 어느새 벽지 하나하나씩 준비가 마무리 되어가고 있네요.사무실에서 갑자기 시작된 가내수공업에개발팀장님까지 합류해주셨네요.마케팅팀부터, 개발자, 디자이너까지두번째 직원들이 모두 한마음으로 열심히 일한 결과배송을 기다리는 박스가 차곡차곡 쌓였습니다.정말 열심히 만들었던 만큼꼭 필요한 고객분들에게 전달되었으면 좋겠습니다. 9~10월 이사철 맞이 이사 도배하시는 분,지금 도배가 눈앞에 닥친 분 등등꼭 필요한 분들이 받아보실 수 있으면 좋겠습니다.샘플북을 받아보시기 원하시는 분들은 두번째도배 홈페이지에서신청해주세요 ^^ 두번째도배홈페이지 바로 가기
조회수 1004

flake8-import-order-spoqa

안녕하세요. 스포카 프로그래머 홍민희입니다.스포카 사내에서는 파이썬 코드의 스타일을 맞추기 위해 flake8을 사용해왔습니다. PEP 8 스타일을 준수하게 해주고, 안 쓰는 임포트를 꼭 지우게 하는 등의 좀더 구체적인 규칙도 지키게 해주는 린트 도구입니다. 사실상의 표준이기 때문에 파이썬을 이미 쓰고 있는 분들이라면 많이들 알고 계실 것입니다.그렇지만 import문의 사용에 대해서는 우리가 원하는 것만큼의 규칙을 제공하지 않아서, 예전부터 동료 강효준 님이 import-order를 별도로 만들어서 써왔습니다. 만들었을 당시에는 import문의 쓰임에 대한 린트 도구가 없었기 때문에 유용하게 써왔고, 다른 파이썬 오픈 소스 프로젝트에서도 유용할 것 같다고 생각하여 쓰인지 1년쯤 지난 뒤에 오픈 소스로 공개했습니다.하지만 flake8과는 다르게 외부 커뮤니티에서 널리 쓰이지는 못했고, 사실상의 표준이 되었다면 편집기 연동 등이 이뤄졌겠지만, 그에 미치지는 못했습니다. pre-commit hook이나 CI에서나 검사가 이뤄지기 때문에, 코딩을 마쳤다고 생각한 이후에 뒷북으로 실수를 바로잡는 일이 많아 불편했습니다.그 뒤로 시간이 지나자 커뮤니티에서는 flake8-import-order라는 도구가 나와서 사실상의 표준이 됐습니다. 이미 많은 편집기에서 연동이 되는 flake8의 확장으로 구현됐기 때문에 편집기에서 즉시 확인이 가능했고, 더 많은 옵션도 제공했습니다. 그렇지만 cryptography 프로젝트 사람들이 만든 도구다보니, cryptography 스타일 및 Google 스타일 등 몇 가지만 제공했고, 이 도구를 활용하려면 스포카에서 3년 넘게 쓰이던 import 스타일을 포기하고 사내의 모든 코드를 전부 수정하는 난리를 피우거나, flake8-import-order에 스포카 사내 스타일을 옵션으로 추가하거나, 프로젝트를 포크해서 별도로 유지보수하며 써야 했습니다.사내 모든 코드를 전부 수정하는 것은 쉽지도 않을 뿐더러, 스포카에서 쓰이던 스타일에도 나름의 논거는 있기 때문에 쉽게 포기하기는 힘든 결정이었습니다. 일부 프로젝트부터 옮겨가는 시도도 있었으나, 같은 회사에서 코드마다 스타일의 일관성이 달라지는 혼란이 있었습니다.저는 flake8-import-order에 스타일을 추가하는 것을 주저했습니다. Google 스타일처럼 문서화가 이미 아주 자세히 되어 있지도 않고 유명하지도 않은, 일개 회사의 사내 스타일을 사실상의 표준 린트 도구의 7번째 공식 지원 스타일로 추가하는 것이 이뤄질 개연성이 낮다고 봤습니다.그래서 프로젝트를 포크하기로 마음먹은 것이 보름 전쯤입니다. 그런데 코드를 열어보니 좀더 나은 아이디어가 떠올랐습니다. flake8-import-order의 코드를 고치지 않고 런타임에 스타일을 확장 가능한 플러그인 구조를 추가하면, 스포카에서 쓰는 import 스타일을 별도 패키지로 구현할 수도 있다는 생각이 든 것입니다. 당시 flake8-import-order의 스타일 구현은 Style의 기반 클래스를 상속받는 식으로 이뤄져 있었고, 다만 스타일의 목록이 하드코딩되어 있는 것이 문제였습니다. 막상 코드를 읽어보니 플러그인 구조를 도입하는 것이 어렵지 않을 것이라는 생각이 든 것입니다.파이썬 생태계에서는 서로 다른 패키지 사이에서 런타임에 확장 가능한 의존성 주입을 위해 setuptools 시스템이 엔트리 포인트라는 개념을 제공합니다. 예를 들어 국제화 라이브러리인 Babel은 파이썬 이외의 프로그래밍 언어에서도 gettext 문자열을 extract할 수 있게 하기 위해, 확장 가능한 babel.extractors 엔트리 포인트를 노출합니다. 그리고 별도의 템플릿 언어인 Jinja는 해당 템플릿 엔진을 쓸 때 국제화도 대응할 수 있도록, babel.extractors 엔트리 포인트에 Jinja 언어를 해석하는 jinja2.ext.babel_extract를 주입합니다.저는 같은 개념을 활용하여, flake8-import-order가 flake8_import_order.styles라는 엔트리 포인트를 노출하게 하는 패치를 제출했고, 다행히도 업스트림에 받아들여졌습니다.flake8-import-order를 런타임에 확장할 수 있는 구조가 됐으니, flake8-import-order 위에서 스포카의 import 사용 가이드를 구현하는 것은 어렵지 않은 작업이었습니다. 어차피 스포카의 파이썬 코딩 스타일은 대부분 PEP 8을 그대로 따르고 있었고, 따라서 flake8-import-order에 이미 존재하는 스타일 구현에서 몇 부분만 덮어씌우는 것으로 충분했기 때문입니다.위와 같은 장광설 끝에, 그래서 이번에 소개하려고 한 스포카의 파이썬 import 린트 도구는 flake8-import-order-spoqa입니다. 만든지 보름이 지난 뒤에 소개하는 것은, flake8-import-order에 제출한 패치가 포함된 0.12가 PyPI에 릴리스될 때까지 기다려야 했기 때문입니다.사용법은 어렵지 않습니다. pip로 flake8-import-order-spoqa를 설치한 뒤에, flake8 설정에 다음 옵션을 추가하면 됩니다.[flake8]import-order-style = spoqa#스포카 #개발 #개발자 #개발팀 #개발팁 #꿀팁 #인사이트
조회수 1841

게놈 빅데이터 시대 :: 몇명의 게놈이 해독 되었을까?

$1000 게놈 시대가 본격적으로 개막된 2015년 이래, 대규모 게놈 해독 프로젝트가 다양하게 전개되고 있다. 현재까지 진행되어온, 혹은 앞으로 진행 계획이 확정 발표된 이런 대규모 게놈 해독 프로젝트들을 정리해 보고, 앞으로의 게놈 산업이 어떻게 변화해 나갈지 가늠해 본다.대규모 게놈 해독 프로젝트들대규모 게놈 해독 프로젝트들1000 Genome 1000 Genome을 통해 얻어진 게놈 정보는 표준 게놈( GRCh 37, 38 등) 구축에 활용되었으며,  거의 대부분의 게놈 분석에서 기본적으로 활용되고 있다. 최초의 대규모 게놈 해독 프로젝트로, 2008년 부터 2015년 까지  Phase1~3의 단계를 거치며,  총 26개 인종 집단의 2,504명의 게놈이 해독되었다.Project  : http://www.internationalgenome.org/ ExAC( Exome Aggregation Consortium ) Broad institute 의 Daniel MacArthur 랩이 주도하여 전세계 연구 기관의 Exome data 를 모은 Meta data 프로젝트로, 현재 까지 60,706명의 Exome 데이터가 모여  단백질 코딩 영역인 exome 영역의 genetic variation 에 대해 가장 체계적이고 깊이 있는 정보를 제공하는 DB로 성장했다.  이 DB는 위에 소개된 1000 genome data 를 포함하고 있기도 하다.얼마전 막을 내린 2016 ASGH에서는 126,216명의 Exome 과 15,136명의 Whole genome 도합 14만여 명의 게놈을 포괄하는 ExAC의 2차 버전인 gnomAD 가 발표 되어, 명실 상부 현재 까지 지구상에서 가장 많은 인간 게놈을 쌓은 공개 DB 로 자리 메김하고 있다.ExAC Paper : http://www.nature.com/nature/journal/v536/n7616/full/nature19057.htmlExAC : http://exac.broadinstitute.org/gnomAD : http://gnomad.broadinstitute.org/Genomics England( 영국인 10만명 게놈 프로젝트 )영국의 10만 게놈프로젝트는 영국 공영 의료 보험을 담당하는 NHS 주도로 주창되었는데, 후에 이를 통해 얻어지는 다양한 IP  확보를 위해 영국 보건부가 100% 지분을 가지는 'Genomics England' 라는 회사를 설립해 영국인 10만명 프로젝트를 주관하게 했다.Genomics England는 회사 이름 임과 동시에 10만 게놈 프로젝트를 지칭하는 또 다른 이름이기도 하다.NHS가 주도하는 만큼 암과 희귀 질환 등  다양한 질병 cohort 를 포함시켜, 특정 질병에 대한  유전적 연관성을 이해하고 정밀의학/예방의학으로  영국 국가 의료 서비스를 효율과 질을 개선하는데 가장 큰 목표가 있다.현재 까지 목표의 약 10%인 12,000여개 게놈이 해독되었고, 게놈 이외 cohort 집단의 다양한 phenotype 정보들을 방대하게 수집하고 있고, 추후 효율적 정보 활용을 위해 phenotype 정보를 표준화 하여 수집하고 있다고 한다.Genomics England : https://www.genomicsengland.co.uk/ 관련 포스트 : http://goldbio.blogspot.kr/2013/04/blog-post.html  GenomeAsia 100K ( 아시안 10만 게놈 프로젝트  )한국의 마크로젠, 싱가폴 난양과학기술대학, 인도의 MedGenome 이 설립 파트너사로 참여하고, 마크로젠 서정선 회장이 4인의 최고 운영 위원 중 한명으로 참여하여, 한국이 leading role 로 참여하는 아시안 10만 게놈 프로젝트.총 20여개 아시아 국가 국민의 게놈이 해독될 예정이고, 앞으로 3년 안에 완료하는 것을 목표로 하고 있다.서양인을 위주로 진행되어온 게놈 정보 인프라를 아시안 인종에 그대로 적용할 때 어느 정도의 error 를 감수할 수밖에 없다.  아시안 10만 게놈 프로젝트가 완성이 되면, 아시안 인종적 특성이 반영된 게놈 정보를 바탕으로 보다 정밀한 게놈 의학 등 활용이 가능해 질 수 있다.다만, 10만 게놈 프로젝트를 위한 재원 마련, 다국적 프로젝트인 만큼 일괄적 리더쉽 하에 목표한 3년 안에 10만명의 게놈 해독을 완료하는 것은 쉽지 않을 것으로 생각한다. ( HiseqX-10 을 1년 내내 돌려서 1만 5천명의 게놈 해독 임을 감안한다면 더더욱 ... )GenomeAsia : http://www.genomeasia100k.comPMI의 100만 게놈 프로젝트 오바마 정부의 PMI( Precision Medicine Initiative )의 일환으로 NIH 가 주관해 100만명의 cohort 를 모집해 게놈을 포함한 포괄적인 의료 정보를 모아 정밀의료를 위한 Genome-Phenome 정보 인프라를 구축하려는 프로젝트.2016년 cohort 모집을 시작해 4년 정도 일정으로 100만명의 cohort 에 대한 데이터 수집을 완료할 목표를 가지고 있다.  NIH 가 주도하고, NCI 는 수집된 cohort 중 암환자 그룹에 집중해 맞춤형 치료법 개발에 집중할 계획을 가지고 있다.PMI : https://www.nih.gov/precision-medicine-initiative-cohort-program Autism Genome Sequencing Project구글, 토론토 대학, 자폐증 치료를 위한 비영리 단체 Autism speaks 가 함께 힘을 모아 1만명의 자폐증 환자의 게놈을 해독해 자폐증 원인 유전인자를 찾아내려는 목적을 가진 프로젝트. 현재 까지 전체 목표 중 75%인 7500명의 게놈 해독이 완료되었다.현재 까지 해독된 게놈을 토대로, 총 64개의 자폐증 원인 유전자를 찾아냈고, 이 중 13개는 알려지지 않았던 유전자가 새롭게 발굴된 것이라 한다.  자폐증 게놈 프로젝트를 통해 얻어진 이런 원인 변이를 통해 치료제 개발 등으로 이어져 성공 사례로 남는다면, 이와 유사하게 특정 질병의 원인 변이를 찾으려는 대규모 게놈 해독 프로젝트가 우후죽순 처럼 난립하게 될 거라 생각하고, 신약개발의 한계에 다다른  다국적 제약사들 역시 질병 게놈 해독  대열에 동참하지 않을까? 이미 Astrazeneca가 이런 목적을 가지고 역사상 가장 대규모의 게놈 해독 프로젝트를 진행하기로 결정했다. 이 내용은 바로 뒤에 이어진다.MSSNG : https://www.mss.ng Autism speak on Google Cloud : https://cloud.google.com/customers/autism-speaksAstrazeneca의 200만 게놈 프로젝트 거대 다국적 제약사 아스트라제네카가 10년 계획으로 200만명의 게놈을 해독해 신약개발에 활용하려는 목적을 가지고 진행되는 프로젝트로 현재 까지 발표된 게놈 정보 데이터 사업 중 가장 큰 규모.이를 위해 콜럼비아 대학의 저명한 유전학자 David Goldstein을 최고 과학 고문으로 영입했고( 대학 교수 직과 겸임),   Welcome trust Sanger institute, Human longevity 등과 협력 체제를 다지고, 게놈 해독에는 아스트라제네카가가 대규모 게놈 해독 설비를 갖추는 대신, 이들 기관의 설비를 활용하게 될 예정이다.( Human Longevity가 50만명 이상의 게놈을 해독할 것이라 한다 )200만이란 숫자가 들어가는 만큼, 서양인, 아시아인, 아프리카인 등 모든 major 인종을 수십만씩 포괄할 예정으로, 이 프로젝트가 계획대로 진행이 된다면, 더 이상의 large scale genome data project 는 필요가 없을 정도가 될거라 본다.AstraZeneca는 이 프로젝트를 통해 질병을 일으키는 희귀 변이( rare variant) 들을 찾아내는데 집중할 계획을 가지고 있다. 실제 질병의 발병에는 공통변이(common variant) 보다 각 개인이 가진 희귀 변이들이 더 큰 역할을 하고 있고, 이런 희귀 변이들은 또한 인종 특이적으로 질병에 관여하는 경우들이 많아, 다양한 인종, 다양한 특질을 가진 개인을 포괄해야만 의미 있게 이런 질병 연관 희귀 변이들을 찾아낼 수가 있다. 바로 이런 context 에서 AstraZeneca가 이런 엄청난 규모의 게놈 해독 프로젝트를 기획한 것으로 보인다.사실, 이런 목표는 위에 언급한 David Goldstein을 이 프로젝트의 최고 과학 고문으로 영입한 것에서 드러난다. David Goldtein은 CDCV( Common disease, common variant ) 즉, 일반 질병은 일반 변이에 의해 발생한다는 큰 가설 하에 지금 까지도 널리 수행되고 있는 GWAS 연구의 '종말'을 선언 하고 ( 참조: http://scienceblogs.com/geneticfuture/2008/09/16/david-goldstein-on-the-failure/ ), 희귀 변이 연구에 집중해야 한다고 설파하고 실천해 온 과학자다.23andMe현재 약 150만명 고객의 게놈 데이터를 축적하고 있고, 데이터를 활용한 비즈니스, 신약개발을 이미 시작한 기업. 23andMe의 데이터는 100만개 SNP chip 기반의 genotype 데이터로, 위에 언급한 데이터들이 WES/WGS 인 것을 감안하면 데이터의 잠재 가치는 상대적으로 많이 떨어진다고 할 수 있다.SNP chip 을 기반으로한 대중 소비자유전학 서비스로, 가격을 낮게해 더 많은 고객을 유치하는 것과 WES/WGS으로 데이터의 가치를 더 할 수는 있지만 비싼 비용으로 적은 숫자의 고객을 유치하는 것 사이의 tradeoff 를 꾸준히 고민하고 있을 것이라 본다.하지만, WES 의 가격이 매우 낮은 수준으로 내려오고, 개인 게놈 시대가 열리기 시작하는 시점이 곧 눈 앞에 닥친 지라, 머지 않은 미래에  WES/WGS 으로 게놈 해독 플랫폼을 바꿀 가능성이 있다.23andMe는 다국적제약사 Genentech 과 긴밀한 관계로 신약개발로 사업 확장을 꾀하고 있는데, 이런 움직임이 AstraZeneca의 200만 게놈 프로젝트, 그리고 게놈을 크게 신경 쓰지 않고 있었던 다른 다국적제약사들에게도 게놈 정보 확보 전쟁에 뛰어들게하는 자극제가 되고 있을거라 짐작한다.Human longevity Human longevity는 인간게놈프로젝트의 영웅 크레이그 벤터의 reputation에 기반해 수천억원의 투자를 받아 현재 지구상에서 가장 담대하고 빠르게 게놈 해독 정보를 쌓아가고 있는 회사다. 현재 까지 26,000개 이상의 게놈 해독을 완료했고, 그 중에 1만여명의 게놈 정보를 분석해 최근 논문을 출판했다.위에 소개된 Astrazeneca 프로젝트에서도 50만건 이상의 게놈 해독을 하기로 계약이 된 것으로 보도가 되기도 했는데,  지금 까지의 행보를 보면 대규모 게놈 해독 프로젝트를 진행하는 곳들 중 가장 빠르고 많은 인간 전장 게놈( WGS ) 정보를 쌓아갈 곳이 될 것 같아 보인다.10K 논문 : http://www.pnas.org/content/113/42/11901.abstract* 일본의 1,070명 게놈 프로젝트(http://www.nature.com/articles/ncomms9018 ), 한국의 1,100 게놈 프로젝트, 최근 핀란드 게놈 프로젝트 등 소개된 내용 이외 대규모 게놈 해독 프로젝트들이 다수 존재하나, 필자의 게으름으로 요 정도 선에서 정리 했습니다.빅 게놈 데이터 시대그저 많이 읽기만 해선 의미 없다. 수십만, 수백만의 사람의 게놈을 그저 해독한다고, 의미 있는 '지식'이 생산되지 않는다. 게놈 주인의 Phenotype 정보와 Lifelog 정보가 게놈 정보와 합쳐져야 해당 phenotype에 영향을 미치는 유전적 요인을 찾아낼 수 있고, 이런 타고난 유전적 특성에 매일매일의  식습관, 운동량, 환경요소( chemical exposure ,etc )들이  건강 유지와 질병의 예방에 어떤 영향을 끼치는지를 파악해 낼 수 있다.PMI, Genomics England, Human longevity 등은 대규모의 게놈 해독과 함께 연구에 참여한 cohort 집단 개개인의 PHR, EMR, wearable device 등을 통한 lifelog 정보 수집 등 게놈 이외의 포괄적인 개인 건강 정보를 수집해 게놈 해독의 가치를 극대화 하는 형태로 전체 프로젝트를 계획해  진행을 하고 있다.대규모 게놈 해독 프로젝트로 부족하다. 게놈과 phenome 을 포괄하는 정보를 '연구 목적'으로 모으는 대규모 게놈 프로젝트를 통해서 게놈을 통해 해결할 수 있는 문제들을 풀어낼 수 있을 만큼 충분한 정보를 모을 수 있을까? 위에 소개된 대규모 게놈 해독 프로젝트들 중 가장 많은 게놈을 모은 곳은 23andMe 다. 위에 소개된 게놈 해독량의 88%가 23andMe 에서 나왔다. 사실 23andMe는 대규모 게놈 해독 프로젝트를 진행한 적이 없다. 23andMe 는 '유전적 근원을 알고 싶어하는 고객', '유전적인 신체적 특징, 질병에 대한 위험도를 알고 싶어하는 고객' 에게 게놈을 읽어 solution을 제공해 줬을 뿐이다.IT 시장을 생각해 보자. 개인용 컴퓨터 사용이 개인에 미치는 영향을 연구하기 위해 10만명의 연구집단을 모집해 연구했다면? 그 보다 '게임'을 하기 위해, '타자기를 대신하는 워드프로세서'를 사용하기 위해 전세계 수천만, 수억명의 사람들이 컴퓨터를 구입해 사용하면서 자연스럽게 개인용 컴퓨터의 사용이 개인에게 미치는 심층적인 분석을 가능하게 했다.데이터가 아닌 '문제'를 해결하는 솔루션을 고민하자.  수백만, 수천만명의 사람의 게놈 정보를 모아, 의미 있는 게놈 정보 플랫폼이 되고자한다면, '공짜 게놈 보급' 과 같이 일차원적인 게놈 해독에 목멜 것이 아니라,  사람들이 가지고 있는 '문제'를 게놈을 통해 해결하는 '제품'을 공급해야 한다.그런 의미 있는 제품을 공급할 수 있는 곳이 수백만 수천만명의 고객 게놈을 모아 진정한 게놈 플랫폼으로서 게놈을 통한 다양한 문제를 해결해 낼 수 있을거라 본다.데이터가 중요하다고 데이터를 모으려고 노력할 것이 아니라, 게놈을 통해 해결할 수 있는 의미 있는 '문제'가 무엇인지에 집중하고, 그 문제를 해결하는 제품을 만들어 공급을 할 생각을 해야 한다.게놈을 통해 Next google, facebook이 되고 싶다면, 이런 맥락에서 사업을 고민해야 할 거라 본다. 다행히 아직 이런 제품이 지구상에 없다. 아직, 당신에게도 기회가 있다.#3billion #운영 #인사이트 #스타트업 #마인드셋 #시장분석
조회수 1424

스푼 라디오 안드로이드 개발자 Yong을 소개합니다!

 정말 좋아하는 일을 하면, 주말 또는 정해 놓고 쉬는 날이 없습니다. 어디선가 호탕한 웃음소리가 나면 백발백중 'Yong'의 웃음소리라는 것을 안다. 듣는 다른 이 또한 웃게 만드는 매력적인 웃음의 소유자 안드로이드 개발자이자 클라이언트팀의 리더 용을 지금 소개합니다.호탕한 웃음의 원천이요?"저는 기본적으로 일을 즐겁게 하자 라는 생각으로 일을 합니다. 함께 웃으면서 일하면 서로 함께 기분이 좋아지잖아요! 그게 저의 호탕한 웃음의 원천인 것 같습니다. 다른 분들께 매력적으로 보인다는 것은 처음 알았네요 :) 그리고 저는 원래 웃음이 많은 사람입니다"듣고 싶은 당신의 스푼 라이프클라이언트팀이 궁금합니다."클라이언트 팀은 세 파트로 나뉘어있습니다. IOS, AOS 그리고 Web입니다. 저희 팀은 다른 많은 부서들과 긴밀한 협업을 통해 제품에 대한 틀을 정의하고 프로그래밍이라는 구현 작업을 통해 제품을 만들어 사용자들에게 가치를 전달하고 있습니다. 저희는 사용자들에게 제품을 이용하는 편의성을 제공하며 사용자 상호 간의 소통의 창구적인 역할을 하게 됩니다. 또한, 사용자들의 다양한 행위를 통해 스푼은 사용자들에게 재미, 감동, 그 이상의 의미를 전달합니다. 결과적으로 사용자들이 인식하고 보고 느끼는 모든 것이자 스푼의 가치를 전달하는 최종적인 결과물이라고 할 수 있겠습니다. 그리고 저는 현재 팀에서 클라이언트 팀 리더이자 안드로이드 개발을 담당하고 있습니다."개발자 그리고 팀 리더가 되기까지"저는 원래 전공이 하드웨어 분야였습니다. 사실 원대한 꿈은 없었지만 제 스스로가 이공계에 마땅한 사람이라는 것은 알 고 있었어요. 하드웨어와 소프트웨어 가리지 않고 무언가를 개발하는 것을 좋아한다는 걸 알았거든요. 제가 진로를 선택했을 땐 안드로이드 개발이 구현되기 전이었어요. 그래서 서버랑 클라이언트(윈도우)이 둘 중에 진로를 선택해야 했었고 첫 회사에서 UI 쪽으로 업무를 시작하게 되었어요. 사실 애초 UX/UI에 관심이 많았고 적성에 맞다는 걸 느꼈어요. 제가 만든 제품을 누군가가 사용하는 것을 육안으로 보고 싶었거든요. 개발은 정말 보람된 일이자 저에게 자부심이기도 합니다.개발자로서 코딩만 하다가 팀 리더가 되어보니, 리더가 정말 힘든 일이라는 것을 알았어요. 어쩌면 코딩보다 더 어려운 일인 것 같아요. 상대방을 이해하고, 또 이해시키고 공감해야 하니까요. 제가 일을 하면서 가장 행복할 때는, 함께 한다는 느낌을 받을 때인 것 같습니다. 예를 들어서 아이디어 회의를 할 때 모두가 같은 마음으로 함께 이루어간다고 생각이 들 때가 가장 뿌듯하더라고요."함께 일하고 싶은 사람 저는 솔직한 사람을 좋아합니다. 본인의 생각을 진솔하게 이야기하고, 공감대를 잘 형성할 수 있는 사람이요. 결국 일은 사람과 사람이 함께 하니까요.  알고 싶은 Yong의 이야기나를 표현하는 한마디 - '바람'저는 자유로운 사람이 되고 싶어요. 바람처럼 유유자적하면서, 무언가 하고 싶은 것이 있을 때 자유롭게 즐길 수 있으며, 구속받지 않는 삶을 살고 싶습니다.나만의 스트레스 해소법"제가 게임을 정말 좋아해요. 거의 모든 온라인 게임은 다 했던 것 같아요. 와우, 블리자드, 배그, 오버워치 등등 정말 많이 했는데 사실 지금은 잘 안 하는 것 같아요. 예전에 마케팅팀 테드랑 주말마다 함께 온라인에서 만나서 게임을 했었는데 테드가 결혼하고 저도 아이와 함께 시간을 보내다 보니 점점 게임을 안 하게 되더라고요. 게임을 왜 좋아하냐고요? 일단 재미있잖아요! 그리고 스트레스 푸는데 아주 좋아요. 게임에 몰두하고 나면 잡생각이 없어지거든요. 게임도 개발과 비슷해요. 온전히 집중해서 하지 않으면 모든 게 틀어지거든요. 게임은 집중력 향상에도 굉장히 좋습니다!"개발은 '예술'과 같아요 "주말에 집에서 일하는 이유요? 일이 많아서나 해야 해서 하는 것은 아니에요. 단지 자유롭게 하고 싶을 때 하는 편입니다. 좋아하고 즐거운 일이니까요! 개발은 하나의 예술이라고 생각합니다. 화가가 요일을 정해놓고 그림을 그리지 않는 것처럼 개발자도 똑같아요. 좋아하는 일을 한다면 그건 일이 아니라고 생각이 들거든요. 저에게 개발은 그렇습니다. 제게 개발은 재미있는 하나의 예술과 같아요"Yong은1. 사진, 그림, 음악 등 예술에 관심이 아주 많습니다!(피아노 독주회, 전시회에 종종 가신다고 합니다. 특히나 클래식과 재즈를 좋아합니다)2. 가리는 음식은 없지만, 한식류를 좋아합니다!팀원들이 Yong을 한마디로 표현한다면?Edward Jung 曰: 웃지만 무서운 관리자 - “언제나 웃음으로 대하시지만 내가 웃는 게 웃는 게 아니야라고 느껴짐…”Julia Na 曰: 행복한 리더 - "호탕한 웃음소리가 트레이드 마크. '행복하세요'라고 말하며 팀원들에게 긍정기운을 전파합니다."Michael Chung 曰: 따뜻한 마음을 가진 개발자 - “팀원들 하나하나 직접 챙기기 때문”Roy Choi 曰: 온화한 아버지 - "개발 실력은 기본, 팀원들을 챙기며 일정 조율 및 커뮤니케이션 능력까지 겸비한 그는 클라이언트팀의 아버지"Raymond Hong 曰: 허허실실 웃음 가득 리더 - "꼼꼼히 팀원과 프로젝트를 챙기기 때문"
조회수 1385

"서울 어디를 가든 패스트파이브가 보였으면 좋겠어요"

독특한 팀, 개성 넘치는 사람들로 가득한 패스트파이브. 지금까지 다양한 팀에 속한 분들을 소개해드렸는데요, 오늘 Humans of FASTFIVE에서 만나볼 분은 이름도 생소한 프로덕트 본부, 그중에서도 서비스운영팀을 맡고 계신 홍유현 님입니다. 패스트파이브를 더 예쁘고 편안한 곳으로 만들기 위해 ‘이것저것’ 하는 유현 님의 이야기를 들어보시죠. Q. 유현 님 안녕하세요, 간단한 자기 소개를 부탁드립니다.안녕하세요, 패스트파이브 프로덕트 본부의 서비스운영팀장 홍유현입니다. 저를 한마디로 소개해보라고 하셨는데, 패스트파이브의 로다주라고 소개하고 싶네요. (*위 인터뷰 내용은 편집부의 의견과 다름을 밝힙니다.) 영화 <어벤져스>에서 엔지니어, 혹은 수리공 역할을 하잖아요. 그 느낌이 비슷하다고 생각합니다. Q. 프로덕트 본부와 서비스운영팀에서 하는 일은 어떤 것들인가요?프로덕트 본부는 패스트파이브가 제공하는 공간과 서비스, 커뮤니티에 대해 고민하고 구체적인 서비스를 만들어가는 곳이에요. 굉장히 다양한 일을 하는 팀입니다. 사실 저희 팀이 처음 만들어질 때 이름 후보가 여러 개 있었거든요. 그중 하나가 ‘이것저것 팀’이었어요. 직관적이긴 하죠. 원래는 한 팀 안에 디자인, 개발 파트 등이 분화되지 않은 채로 다 들어있었거든요. 지금처럼 나누어진 지 얼마되지 않았죠. 그래서 ‘이것저것 팀’이라는 이름이 더 어울렸을 수도 있겠네요. 저희 팀의 목적을 말씀드리면 저희가 하는 일이 쉽게 이해될 것 같아요. 저희의 궁극적인 목적은 팀이 없어지는 거예요. 멤버가 원하는 것을 캐치해서 실현시키는 게 서비스운영팀의 역할이기 때문에 언젠가는 멤버들이 더 바랄 게 없어지는 상태, 그래서 팀이 필요 없어지는 상태가 되기를 바라죠. Q. 설명을 들을수록 궁금해지네요. 더 구체적인 설명이 필요할 것 같습니다. 유현 님의 하루 일과를 소개해주세요. 어제 뭐 하셨나요?오전에는 14호점 커피 머신을 세팅했어요. 얼마 전에 오픈한 강남3호점이요. 커피머신의 원두나 커피의 양 등이 저희가 제공하는 종이컵에 맞춰서 세팅되어 있었거든요. 그런데 요즘 Go Green 캠페인을 하면서 텀블러 사용이 많이 늘었잖아요? 보통 텀블러는 종이컵보다 많은 양이 들어가서 조절이 필요하더라고요. 오전에는 그 세팅을 했습니다.자동으로 커피 양을 맞춰주는, 강남3호점의 멋진 커피머신!오후에는 강남/역삼 지부의 지점들을 돌면서 현장 체크를 했어요. 최근 신규 지점이 많이 오픈하고 있는데, 그렇다고 기존 지점에 소홀하면 안 되잖아요. 어떤 부분을 발전시켜야 할지 직접 보면서 체크합니다. 저는 그 과정을 ‘못생김을 없앤다’고 불러요. 더 예쁘고 편한 것으로 교체하죠. 예를 들어 어제는 강남 지점에서 보안업체와 미팅을 했어요. 건물과 보안업체, 패스트파이브 사이에서 의견을 조율해서 불편한 부분을 편하게 만들었죠. 오늘은 15호점인 을지로1호점에 들어갈 물품 견적을 내고 발주해야 하고, 각 지점 커뮤니티 매니저분들에게 온 연락들을 처리해야 돼요. (늘 통화 중이시더라고요.) 통화도 하고, 메신저나 문자로도 계속 연락을 받죠. 어떤 날은 오전에만 열 통 가까이의 문의 전화를 받기도 합니다. Q. 서비스운영팀에서는 어떤 가치를 가장 중시하나요?조금 주관적이기는 해요. 일단 어떤 물품을 구매할 때 패스트파이브의 공간과 어울리는지를 가장 먼저 고려합니다. 라운지, 바, OA존과 어울리는지 생각하죠. 물론 실용성도 빼놓을 수 없습니다. 멤버들이 이 물건과 공간을 더 편하고 유용하게 사용할 수 있도록 고민해야 하죠. 이런 것들을 고려하다 보니 어떤 물품 하나를 찾고, 알아보고 구매하는 데 거의 일주일 가량이 걸릴 때도 있습니다. 신규 지점이 거의 매달 오픈하고 있어서 요즘에는 물품 구매와 관련한 업무가 많은 편이에요. 비용을 절감해야 하는 동시에 비용을 사용하고 있으니 어렵네요. Q. 지금까지 맡았던 일 중 가장 어려웠던 일은 뭔가요?패스트파이브의 퀄리티에 맞는 제품을 찾는 일이 어려워요. 부끄럽지 않은 물품을 구매해서 채워 넣어야 하는데, 패스트파이브가 운영하는 공간의 수준이 점점 올라가다보니 제 기준도 높아지더라고요. 한국 시장에서는 아예 찾을 수 없는 경우도 많고요. 패스트파이브는 국내에서 처음으로 공유오피스를 시작했기 때문에 아주 작은 것 하나를 결정할 때도 시행착오를 거치게 되는데요, 그 과정이 쉽지는 않지만 꼭 필요한 일이라고 생각합니다. 패스트파이브의 역할은 멤버들이 일의 본질에 집중할 수 있도록 돕는 것입니다. 서비스운영팀은 그 일을 멤버와 가장 가까운 곳에서 하고 있는 셈이죠. 저는 서비스운영팀이 매일매일 패스트파이브의 가치를 실현하는 중이라고 믿습니다. 멤버들이 본인의 일을 제외한 다른 것에는 신경쓸 필요가 없도록 만드는 게 제 목표고요.   Q. 패스트파이브가 어떤 브랜드가 되었으면 하시나요?강남, 홍대, 잠실, 을지로… 서울 어디를 가든 패스트파이브가 보였으면 좋겠어요. 멤버들이 어디에 있어도 패스트파이브를 찾을 수 있고, 패스트파이브 간판을 보고 잠시 들러서 업무를 보고 나올 수 있는 그런 곳이 되었으면 합니다. 어디에나 사무실이 있는 셈이니 정말 편리하지 않을까요? 그리고 이제는 오피스뿐만 아니라 카페와 주거 서비스까지 제공할 예정이니 허황된 꿈은 아니라고 생각합니다. 조만간 패스트파이브라는 브랜드를 중심으로 라이프스타일이 구성되는 날이 왔으면 좋겠네요. 일상 대화에서 스타벅스가 ‘카페’라는 말을 대체하기도 하잖아요. 그것처럼 패스트파이브가 ‘오피스’, ‘사무실’이라는 말을 대체하는 모습을 보고 싶고요.  개인적인 목표를 말씀드리자면, 패스트파이브의 모든 멤버들이 입주하는 순간부터 행복한 경험을 할 수 있었으면 좋겠습니다. 제가 그렇게 만들어드리고 싶고요. Q. 서비스운영팀에서 새로운 팀원을 뽑는다면 어떤 분과 함께 일하고 싶으신가요?지금은 15호점까지 운영 중이지만 곧 30호점, 100호점까지 지점이 늘어나면 분명히 훨씬 더 많은 팀원이 필요하겠죠. 우선 남을 위하고 배려할 줄 아는 마음을 가진 분이면 좋겠습니다. 다른 사람의 입장에서 생각할 줄 알아야 패스트파이브 멤버들이 원하는 점을 잡아낼 수 있을 테니까요. 또 업무 능력 면에서는, 저희가 ‘이것저것 팀’이잖아요. 많은 경험을 해보신 분이 좋을 것 같습니다. 집에서나 학교에서, 혹은 여행을 가서 할 수 있는 작은 경험들이 이 팀에서는 큰 도움이 될 수 있거든요. 프라모델 조립이나, 학교 행사 기획 혹은 모르는 지역에서 길을 찾았던 경험 등이요. "하지만 난 일이 좋다"보통 다능은 무능이라고 하지만 서비스운영팀에서는 다능이 능력입니다. 여러 업무를 수행할 수 있는 멀티플레이어가 필요한 곳이거든요. 저희 팀에서는 새로운 팀원분이 가진 여러 능력을 충분히 발휘할 수 있도록 도와드리고 지원할 겁니다. 그러니 ‘나는 특출난 능력이 없는 것 같아’라고 생각하지 않으셨으면 좋겠습니다. 많이 도와드릴 테니 지원해주세요! Q. 마지막으로 하고 싶으신 말 자유롭게 부탁 드립니다.   훌륭한 팀원분을 영입하고 싶은 마음이 커서, 회사 홍보를 좀 할게요. 제가 패스트파이브에 들어오고 싶었던 이유 중 하나는 이곳의 문화였어요. 첫 면접날 굉장히 신기하다고 생각했어요. 대표님이 반바지 입고 모자를 쓰고 계셨거든요. 이런 자유로운 분위기가 좋았죠. 그 분위기 안에서 제가 원하는 일을 할 수 있었고요. 멤버들에게 해주고 싶은 일이 생기면 자유롭게 실행할 수 있는 분위기라고 할까요? 더 많은 분들과 패스트파이브의 문화를 만들어나가고 함께 일하고 싶습니다. 다양한 일을 하고 있지만 결국 전부 패스트파이브의 멤버들을 위한 것이라는 유현 님과의 인터뷰, 재미있게 읽으셨나요? 앞으로도 멤버들의 든든한 멀티플레이어가 되어주실 것 같네요! 그럼 저희는 다음 인터뷰로 돌아오겠습니다. 읽어주셔서 감사합니다 :)- 패스트파이브 마케팅팀 드림
조회수 1210

Event-Driven Programming

Overview마이크로 서비스 사이의 결합도를 낮추고 비동기적인 문제들을 처리할 때는 Event-driven 아키텍쳐가 유용합니다. 이번 글에서는 AWS에서 제공하는 SNS Topic을 이용해 Event-Driven을 알아보겠습니다. Event-Driven Programming프로그램의 제어 흐름이 이벤트의 발생에 의해 결정되는 컴퓨터 프로그래밍 패러다임입니다. publish/subscribe (이하 pub/sub)메시징서버리스 및 MSA에서 안정성 및 확장성을 높이기 위하여 사용되는 비동기 서비스 통신 방법입니다. 게시된 메시지를 다른 시스템에 비동기적으로 전달하고, Topic을 구독하는 모든 구독자는 모든 메시지를 받을 수 있습니다. 특히 게시자는 누가 구독하고 있는지 알지 않아도 되고, 구독자도 메시지의 출처를 알 필요는 없습니다. pub/sub 메시징 기본 / 출처: AWS Compute BlogAmazon SNS Topicpub/sub 방식의 메시징 서비스입니다. AWS의 여러 서비스들이 SNS에 이벤트를 게시할 수 있습니다. SNS Event Publishers / 출처: AWS Compute Blog위의 그림과 같이 구독자는 게시자 서비스에서 트리거된 이벤트에 응답해 필요한 작업을 진행합니다. 예시로 Elastic Transcoder 서비스에서의 Topic을 활용해보겠습니다. 네 가지의 순서를 거칩니다.1. SNS 토픽 생성2. Elastic Transcoder 등록Optional 항목인 Notification 영역에서 상태별 이벤트를 설정할 수 있습니다. On Completion Event에 위에서 생성한 Topic을 선택해 이벤트를 전달받도록 설정합니다. 3. SNS Topic에 구독자로 등록트랜스 코딩이 완료 후 처리할 프로세스를 가진 Lambda 함수 생성하여 위에서 생성한 SNS Topic에 구독자로 등록합니다. 현재 SNS Topic에서 제공하는 프로토콜은 HTTP, HTTPS, Email, Email-JSON, Amazon SQS, Application, AWS Lambda, SMS가 있습니다.4. 서비스 간 이벤트 전달출처: AWS Compute BlogSNS Topic으로 이벤트를 제공하는 AWS 서비스 중 하나를 살펴봤습니다. 이를 이용하면 마이크로 서비스 간에 이벤트를 전달하고 서비스의 분리 및 확장에 유용하게 사용할 수 있습니다.Conclusion오늘은 SNS Topic을 이용한 Event-Driven을 알아봤습니다. 다음 글에서는 마이크로 서비스에서 사용할 수 있는 AWS 서비스들을 다뤄보겠습니다.참고Event-Driven Computing with Amazon SNS and AWS Compute, Storage, Database, and Networking Services글이상근 팀장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 906

우리 고객의 다른 브랜드 소비 행태를 알아야 하는 이유 | Shared Customer Seminar

우리 고객의 다른 브랜드 소비 행태를 알아야 하는 이유– 오픈서베이 Shared Customer Seminar 주요 내용 정리우리 브랜드 고객의 소비 행태를 여러분은 얼마나 알고 있나요? 우리 브랜드 고객의 소비 행태를 파악하는 일도 쉽지 않지만, 우리 브랜드에서 일어난 소비는 고객의 전체 소비 중 많아봤자 1%일 뿐입니다. 모든 고객은 여러 카테고리에 걸쳐 다양한 브랜드를 소비하기 때문이죠. 다시 말해 나머지 99%를 알지 못한다면 고객의 전체 소비 행태를 파악할 수 없다는 의미입니다.그렇다면 우리 브랜드를 포함한 고객의 전체 소비 행태를 아는 방법이 궁금해집니다. 오픈서베이는 지난 7월 4일, 위 고민을 해소할 방법을 공유하는 ‘쉐어드 커스터머(Shared Customer)’ 세미나를 개최했습니다. 그간 수집한 매장 방문 및 구매 데이터를 기반으로 소비자의 교차 구매와 교차 방문을 분석한 결과를 공개한 겁니다. 본 글은 세미나 내용 요약과 현장 스케치로 구성됩니다.* 아래는 오픈서베이 황희영 대표의 발표 중 일부를 옮겨적은 내용입니다.Shared Customer 세미나 발표를 맡은 오픈서베이 황희영 대표(사진. 오픈서베이) | 내 고객 데이터가 말해주지 않는 것“아리따움에서 지난 3개월 동안 비슷한 금액을 소비한 두 고객에게 같은 마케팅 메시지를 보낼 수 있을까?” Shared Customer 세미나 주제의 핵심은 이렇게 요약할 수 있습니다. 두 고객은 같은 기간 각각 6,000원, 3,500원만큼의 지출을 했는데요. 같은 1 만원 이하 지출 고객이라도 아리따움에서 적게 쓴 이유는 다를 수 있기 때문입니다. 아리따움은 1만 원 이하 저 지출 고객에 대해 기본적으로 3가지 가설을 세울 수 있습니다.1. 소비 여력 자체가 적은 경우2. 뷰티 카테고리의 소비 여력/관심이 적은 경우3. 소비 여력도 있고 뷰티 관심도 있지만 아리따움에서의 소비가 적은 경우위 3가지 중 고객이 어떤 가설에 해당하는지에 따라 마케팅 메시지는 각기 달라져야 합니다. 문제는 아리따움이 알 수 있는 데이터는 두 사람의 아리따움 내 소비 행태뿐이라는 겁니다. 이것만으로는 두 고객 중 소비 여력 자체가 적은 지, 뷰티 카테고리에 관심이 없는지, 타 뷰티 매장을 주로 이용하는지 등 어떤 가설에 해당하는지 알 수 없다는 거죠. 즉, 고객에게 알맞은 마케팅 활동을 할 수 없다는 겁니다.그럼 두 고객의 타 브랜드 소비 행태를 알 수 있다면 어떨까요? 사실 위 데이터는 오픈서베이가 조사한 두 패널의 3개월간 지출 내역입니다. 아리따움은 물론 뷰티 카테고리 내 다른 브랜드 지출 정보와 타 카테고리까지 걸친 전체 소비 행태를 알 수 있습니다. 아리따움 내부 데이터만으로는 알 수 없는 아리따움 고객의 전체 소비 행태 데이터죠. 아래 표를 함께 보겠습니다.  아리따움에서 1만원 이하 지출하는 소비자 A, B의 전체 소비 행태 데이터(자료 중 일부)편의상 왼쪽 소비자를 A, 오른쪽을 B라 지칭하겠습니다. A는 미샤에서 약 16만 원, 올리브영에서 약 10만 원, 토니모리에서 4만 4천 원을 써서 3개월간 뷰티 관련 총 34만 원을 지출했습니다. 반면 B는 아리따움 외 에뛰드하우스에서 4,800원을 지출해 뷰티에서 총 8,300원을 소비했습니다.이렇게 두 소비자의 뷰티 카테고리 전체 지출은 34만 원과 8,300원으로 큰 차이가 있다는 걸 알 수 있습니다. 자연스럽게 A는 소비 여력도 있고 뷰티 제품에 대한 관심도 있지만 아리따움에서의 소비가 적은 경우인 3번째 가설을 적용할 수 있게 됩니다.다음으로 B에게 맞는 가설을 찾기 위해 타 카테고리 지출 내역도 살펴보겠습니다. 타 카테고리에서도 두 소비자의 소비 행태는 달랐습니다. A는 뷰티 및 미용 관련으로 94만 원 지출한 걸 포함해 3달간 총 580만 원을 소비했는데, B는 온라인 쇼핑 33만 원 등 3달간 총 140만 원을 지출했습니다. 이를 통해 B는 소비 여력 자체가 적고 특히 뷰티 카테고리의 관심도가 적은 1, 2번 가설임을 확인할 수 있습니다.이렇듯 다른 매장 구매 내역을 분석해 두 소비자에게 각기 다른 마케팅 메시지를 적용해야 한다는 걸 알기까지는 자사 브랜드의 고객 데이터는 물론 고객의 타 브랜드 소비 데이터를 함께 분석해야 한다는 걸 알 수 있습니다. 이러한 개념을 바로 ‘Shared Customer’라 부릅니다. | 우리 고객의 타 브랜드 소비 행태를 안다면그럼 우리 브랜드 고객의 교차 방문 및 교차 구매 데이터는 그저 소비자를 좀 더 잘 이해하기 위해서만 필요한 걸까요? Shared Customer 데이터는 브랜드 운영에 있어서 강력한 무기가 됩니다. 특히 동일 카테고리 내, 서로 다른 카테고리 간, 그리고 온·오프라인 채널 간 Shared Customer 분석은 브랜드 차원에서 크게 세 종류의 의사결정에 활용할 수 있습니다.Shared Customer 분석 활용법 3가지(자료 중 일부) | ① 동일 카테고리 내 분석첫 번째는 동일 카테고리 내 Shared Customer 분석입니다. 이는 한 소비자의 특정 카테고리 내 전체 지출 중 우리 브랜드 지출이 차지하는 비중을 알기 위해 쓰이는 ‘지갑 점유율, 쉐어오브월렛(Share of Wallet)’이라는 개념으로도 알려져 있습니다.이를 통해 아리따움에서 지출이 많을수록 구매 빈도가 함께 오르는 뷰티 브랜드를 알 수 있습니다. 반대로 아리따움과 상반된 관계를 갖는 브랜드도 있습니다. 이렇게 보완 브랜드와 경쟁 브랜드를 명확히 인지한다면 카테고리 내 방어 및 확장 전략을 자세히 수립할 수 있습니다.참고로 Shared Customer 데이터에 따르면 아리따움과 보완 관계에 있는 브랜드는 에뛰드 하우스, 경쟁 관계의 브랜드는 올리브영으로 나타났습니다. 즉, 올리브영을 제외하면 모든 뷰티 매장이 아리따움과 직접적인 경쟁 관계는 아니라는 것이죠.3개월 간 아리따움 구매 금액별 뷰티 매장 Shared of Wallet(자료 중 일부) | ② 서로 다른 카테고리 간 분석두 번째는 서로 다른 카테고리 간 Shared Customer 분석입니다. 이를 통해서는 내 브랜드 고객의 취향, 관심사, 라이프스타일을 촘촘히 알 수 있습니다. SPA 브랜드 중 유니클로와 자라, H&M의 고객 특성은 어떻게 다른지 알아봤습니다. 각 브랜드 고객의 다른 카테고리 간 교차 방문 데이터를 분석한 것입니다.먼저 각 브랜드 방문 고객은 다른 카테고리의 어느 브랜드를 자주 이용할지 타 브랜드 교차 방문 데이터를 살펴봤습니다. 크게 뷰티, 식음료, 문화, 패션 카테고리로 색깔을 구분했습니다. H&M은 패션 브랜드 중심인 반면 유니클로와 자라는 뷰티, 문화, 식음료 브랜드에 고루 관심을 보였습니다.다음으로 각 브랜드 고객은 어떤 이유로 위와 같은 소비 행태를 보이는지 궁금해집니다. 고객이 무엇을 하는지 알더라도 그 사람이 대체 누구인지와 왜 그렇게 행동하는지는 알 수 없으니까요. 이렇게 소비행태를 단순히 현상적으로 관찰하는 데 그친다면 Shared Customer의 필요성이 쉽게 와닿지 않을 겁니다.이에 오픈서베이는 위 데이터에 패널 프로필과 리타겟팅 조사 결과를 결합합니다. 사전 동의한 오베이 앱 패널 대상으로 신용카드 결제 정보와 매장 방문 데이터가 있기 때문에 가능한 분석 방법입니다. 이를 통해 패널의 성별, 연령, 거주지역, 직업 등 기본적인 정보를 알 수 있고 가구 구성, 소득 등 추가 정보를 필요할 때마다 수집할 수 있습니다.이후 궁금한 고객 대상으로 리타겟팅 조사를 합니다. 특정 패널의 프로필이나 과거 어떤 설문에 응답했는지 알 수 있으니 최근 3개월간 유니클로, 자라, H&M 매장 방문자를 대상으로 한 번 더 설문조사를 진행하는 겁니다. 그 결과는 아래 표를 통해 확인하겠습니다.유니클로, 자라, H&M 방문자 대상 리타겟팅 조사(자료 중 일부)H&M에 자주 가는 고객은 가격 민감도 관련 응답과 여러 브랜드를 돌아다니면서 맞는 스타일을 찾는다는 응답이 전반적으로 많았습니다. 즉, 가격에 민감해 발품을 팔아서 스타일에 맞는 옷을 찾는 것이죠. 반면 유니클로는 패션 관여도와 트렌드 민감도는 낮은데 패션 이외의 관여도가 높으며 품질이나 편안함을 중시합니다. 자라는 패션 민감도와 트렌드 민감도가 높아 다른 브랜드보다 약간 더 프리미엄 한 고객군으로 확인됩니다.이어서 의류 구매 시 고려하는 요소와 각 브랜드별 지불 의향 가격대를 알아봤습니다. 유니클로는 소재와 품질, 자라는 스타일과 디자인, H&M은 스타일과 디자인뿐만 아니라 가격 대비 가치를 가장 많이 꼽았습니다. 이처럼 얼핏 비슷해 보이는 세 SPA 브랜드 방문 고객의 행태 데이터를 살펴본 뒤 가설을 세우고 리타겟팅 설문 조사를 진행하면 세 브랜드 고객의 360º 라이프스타일을 분석할 수 있습니다.  위 방법은 또한 상관관계가 높은 타 카테고리 브랜드와의 Co-Promotion 전략을 수립할 때 활용할 수 있습니다. 우리 브랜드 고객의 취향, 관심사, 그리고 라이프스타일을 알게 되면 Co-promotion 및 Collaboration 기회를 만들 수 있기 때문입니다. 예를 들어 “우리 브랜드가 교보문고일 때 제휴하기 적합한 커피전문점 브랜드가 무엇일까?”라는 고민을 할 때 의사결정의 근거로 활용할 수 있는 겁니다.위 SPA 브랜드 때와 마찬가지로 스타벅스, 할리스커피, 폴바셋의 방문 고객은 다른 카테고리의 어느 브랜드를 자주 이용하는지 분석했습니다. 같은 커피전문점이더라도 스타벅스 고객은 타 카테고리에서 주로 GS25와 올리브영, ABC마트를 자주 가는 반면, 할리스커피와 폴바셋은 반디앤루니스와 교보문고를 자주 이용한다는 걸 알 수 있습니다.커피전문점 방문빈도와 상관관계가 높은 카테고리 및 브랜드(자료 중 일부)그렇다면 교보문고가 기존 고객의 구매 유도를 위한 프로모션을 할 때는 교차 방문자가 많은 할리스커피나 폴바셋이 적합하며, 신규 고객 유입을 원할 때는 교차 방문자가 적은 스타벅스가 더욱 적합하다는 걸 판단할 수 있게 됩니다. 물론, 교차 방문 분석뿐만 아니라 후보 파트너 브랜드의 고객 특성과 브랜드 이미지 역시 충분히 고려해야 합니다. | ③ 온·오프라인 채널 간 분석마지막은 온·오프라인 채널 간 Shared Customer 분석입니다. 이는 특히 이마트 등 오프라인 유통 브랜드가 온라인 채널 확장 시 벤치마킹하거나 경쟁 대상으로 삼아야 할 쇼핑몰을 분석할 때 활용할 수 있습니다.오프라인 기반 대형마트 브랜드 중 이마트, 홈플러스의 고객은 온라인 쇼핑 카테고리의 어느 브랜드를 자주 이용하는지 분석했습니다. 이마트 고객은 쿠팡, 홈플러스는 지마켓을 가장 많이 이용했습니다. 몇 년 전 마케팅 시장에서 이슈가 된 ‘이마트와 쿠팡의 기저귀 최저가 전쟁’의 배경을 어느 정도는 이해할 수 있겠습니다.대형마트 구매빈도와 상관관계가 높은 무점포유통 브랜드 상위 5개(자료 중 일부)그럼 다른 듯 비슷해 보이는 이마트와 홈플러스 고객의 교차 구매 데이터는 왜 다소 다르게 나타난 걸까요? 이마트와 홈플러스의 주 이용 고객, 쿠팡과 지마켓의 주 이용 고객에게 리타겟팅 설문 조사를 진행하니 상관관계가 높은 브랜드 간 공통점을 발견할 수 있었습니다.먼저 홈플러스를 주로 이용하는 고객은 쇼핑의 가장 기본적인 속성인 익숙함과 가격 혜택을 이마트 주 이용 고객보다 더 중요하게 여겼습니다. 놀랍게도 지마켓의 주 이용 고객 역시 쿠팡보다 익숙함과 가격 혜택을 중요하게 생각했습니다. 반대로 이마트와 쿠팡 고객은 상품 구성이나 배송과 같은 추가적인 속성을 중시합니다.즉, 서로 다른 온·오프라인 브랜드라도 고객이 중요하게 여기는 가치가 같을 경우 교차 고객을 가질 수 있다는 겁니다. 위 분석 방법 및 사례와 관련된 자세한 내용은 발표 자료 전문을 통해 확인할 수 있습니다. | Q & A질의응답 세션의 주요 내용을 정리해드립니다.Q. 브랜드 간 상관관계를 잘 파악해서 성공·실패한 마케팅 선례도 있나요?A. 아쉽게도 이런 조사 방법이 가능하게 된지 얼마 되지 않아 공개할 수 있는 성공 사례를 소개해 드리기 힘듭니다. 다만 타 브랜드와 Co-Promotion을 준비하면서 오픈서베이를 이용한 고객의 흥미로운 피드백이 있었는데요. 조사 전부터 어떤 브랜드랑 프로모션 하면 좋겠다는 생각은 했다고 합니다. 이유는 간단하게도 “왠지 그럴 것 같으니까”요. 그런데 내부 설득이 힘들었다고 합니다. 제휴 프로젝트는 설득할 결제 라인도 복잡하고 비용도 많이 드니까요. 그런데 오픈서베이와의 설문조사를 통해 명확한 데이터를 얻었고 이는 곧 내부 설득을 위한 근거 자료로 활용됐습니다. 또 생각도 못 했던 부분에서 추가적으로 발견한 인사이트가 매우 가치 있었다고 하네요. Q. 결제 내역 데이터로 구매한 상세 제품 분석까지 가능한가요?A. 카드사와 비슷한 협업해 본 분들이 종종 물어보는 질문입니다. 결국 결제 내역으로 알 수 있는 데이터는 결제 금액이지 상세 품목은 아니니까요. 오픈서베이는 결제 데이터로 영수증을 수집하는 방식으로 진행합니다. 현재 정기 수집하는 데이터는 편의점 결제 내역인데, 패널이 편의점에서 물건을 구매하고 영수증 사진을 찍어 업로드하면 그 내역을 디지털화해 데이터베이스를 만드는 시스템입니다.현재 편의점 외에는 영수증 내역을 정기적으로 수집하고 있지는 않지만 프로젝트 단위로 편의점 외 특정 매장의 구매 내역을 확인하고 싶다면 의뢰를 통해 진행 가능하며, 편의점 데이터는 이미 자체적으로 기획해 데이터를 쌓고 있기 때문에 궁금한 경우 문의 주시면 얼마나 제공 가능한지 답변드릴 수 있습니다. Q. 올리브영처럼 브랜드 단위의 대중적인 트렌드가 있으면 타 카테고리의 모든 브랜드가 올리브영과 상관관계가 높다고 나올 것 같아요. 그럼 교차 방문 및 구매 데이터 분석이 의미 없는 것 아닐까요?A. 오히려 반대입니다. 특정 브랜드가 완전 메가 트렌드인 경우는 타 브랜드와의 상관관계 계수가 높게 나타나지 않습니다. 어떤 브랜드를 조사해도 메가 트렌드 브랜드를 다 이용한다고 나올 테니까요. 가장 정확한 사례는 편의점입니다. 어떤 브랜드든 편의점과의 교차 구매 비중은 높게 나옵니다. 이 경우 상관관계 그래프는 상관없다고 나올 거에요. 그런데 올리브영의 경우는 특정 브랜드를 구매할수록 더 구매하거나 덜 구매한다는 경향이 분명 존재하는 브랜드입니다. 넓은 메가 트렌드의 일부긴 하지만 여전히 특성 있는 사람들이 활용한다는 뜻이죠. | Shared Customer Seminar지난 7월 4일, 디캠프에서 열린 쉐어드 커스터머 세미나는 다양한 채널에서 셀 수 없는 제품과 브랜드가 쏟아지는 시대에 자사 고객 데이터만으로는 소비자를 온전히 이해할 수 없다는 문제의식을 공유하는 분들을 위해 준비한 자리입니다. 고객의 성향을 이해하고 더 많은 구매를 끌어내기 위해서는 ‘내 고객이 다른 어떤 곳을 방문하는지’, ‘다른 무엇을 사고 있는지’ 파악해야 된다는 해결책을 제시하는 자리기도 합니다. 뿐만 아니라 발표와 질의응답 세션 외 오픈서베이의 전문성 있는 어카운트 매니저와 Q&A 부스도 마련돼 여러 고민을 직접 나눌 기회도 제공했습니다.오픈서베이 Shared Customer 세미나 현장(사진. 오픈서베이)세미나에서는 이외에도 아리따움과 이니스프리의 대체 및 보완 관계에 있는 뷰티 브랜드가 무엇인지, 카테고리 및 브랜드별로 함께 프로모션하기 좋은 커피 브랜드는 무엇인지, 온·오프라인 쇼핑몰별로 공유하는 고객 성향은 어떤지를 브랜드 별 예시와 함께 소개했습니다. 이에 세미나 전체 내용이 궁금하신 분은 아래 이메일로 오픈서베이 데이터 팀에 문의주시길 바랍니다.| 오픈서베이 팀E. [email protected]. 02-3019-7849#오픈서베이 #데이터분석 #시장분석 #마케터 #마케팅 #서비스소개
조회수 1209

파이 스타트업 (Pie Startup)

startup founder로써 경험에서 나오는 이야기! 하지만 아직은 확실한 결과를 얻은  것이라기보다는... 효과적으로 되고 있다!! 정도의 의견이니 한번 귀담아 들어주시길 바라며. ^^;;난 신촌에서 대학을 다녔는데, 당시 이대 쪽에 미고(MIGO)라는 빵집이 유명해지고 있을 때였다. 그 시절 빵집들은 동네 빵집에서 파리바게트와 같은 프랜차이즈 형태로 진화하고 있었던 상황에서 당시 미고라는 빵집은 한두 단계 정도는 더 앞서고 있었다. 처음 그 집 케이크를 먹을 때의 두 가지 놀라움!! 하나는 맛의 수준이 확연히 다르다는 것이었고, 또 다른 하나는 너무 비싸다는 것이었다.  그중에 내가 좋아하던 케이크는.. 1mm 수준의 빵이 한 겹 한 겹 쌓이고, 그 사이에 생크림이  한 번씩 발라진 것이었는데... 그 맛은 빠바 정도에서는 상상도 할 수 없는 수준이었다. 조금 서치를 해보니.. 그것의 이름은 크레이프 케이크!! 빵 이야기로 시작한 것은.. 오늘 쓰고 있는 글의 제목이 파이 스타트업 이기 때문!(정식 제목은 크레이프 케이크이지만... 그냥 원래 떠올랐던 파이라는 이름을 계속 쓰기로 함 ^^;;) 파펨을 만들어가는 과정에 대한 글들을 보신 독자라면 알고 계시겠지만, 파펨을 시작하기 위한 준비기간(약 6개월)에는 서비스의 70% 정도는 혼자서 준비를 다 만들었다라고 생각하는데... 그 후부터 론칭 전까지는 내가 혼자서 할 수 없는 영역이었던 개발(coding), 디자인의 영역에 전문성을 갖춘 분들이 조인하여 지금의 모습을 갖추고 있다. 대부분 스타트업을 만들 때, Marketing, IT,  Operating과 같이 기능 중심으로 조직을 구성하고, 또한 그 분야에 전문성이 있는 사람들을 모아서 일을 하기 시작하지만, 그와 같이 조직을 구성하게 되면, 1) 기능/부서 간 커뮤니케이션 부족의 문제,  2) ownership과 책임에 대한 문제, 3) 원활한 일 처리의 문제.. 등등이 발생할  수밖에 없다. 예전 그루폰 코리아에서 CMO로 일하던 당시의 경험을 떠 울리면.. 각각 부서의 head들과 미팅을 하면, 정말 이 사람들이 모두 "이 회사의  성장"이라는 동일한 목표를 위해 본인들의 의견을 개진하고, 특정 의견에 반대를 하는  것인가?라는 생각이 들 때가 많았다. 일반적인 조직 구성은 이런 모습. 저렇게 새로로 구성되어 부서간의 단절이 어쩔 수 없이 발생한다. 내가 파이 스타트업(Pie startup)이라는 나름의 naming을 하게 된 것은... 한 겹 한 겹의 layer (실제 빵을 만드시는 분들은 이 용어를 어찌 쓰는지 모르겠지만) 가 모여서 회사를 만들어간다는 경험을 실제로 하고 있기 때문이다. 준비기간 동안에는 '나'라는 한 겹의 사람이 회사의 모든 것을 담당해야 했다. 론칭 전이기 때문에 대부분이 기획과 파트너사(주로 제조) 들과의 커뮤니케이션, 그리고 몇몇 서류 작업 정도였기 때문에 그리 큰 부담은 없었다. 디자인 영역에서도 파워포인트로는 어느 정도 내가 원하는 수준의 디자인 결과물을 구현할 수 있었기 때문에.. 한 겹으로도 서비스의 70% 정도까지는 완성이 가능했다. 그러던 중, 이제는 사이트를 만들어야 하는 시간이 다가왔고, 내가 감당할 수 없는 부분인 coding이 문제로 나타났다. 물론 내가 스스로 공부해서 진행할 수 있겠지만, 그 비효율을 감당할 수는 없고.. 그래서 새로운 한 겹을 찾아내었다. 그래도 코딩에 대한 기본적인 지식 (실제로 코딩은 할 수 없으나.. 뭐가 뭔지 대화는 할 수 있는 수준이랄까? ^^;;)을 어느 정도는 가지고 있었고, 또한 내가 기획한 사이트의 prototype을 다음의 OVEN이라는 툴을 활용해서 이미 준비해둔 상황이었다. 두 겹!!그다음으로는 디자인 영역. 앞에 말한 것과 같이 나는 나름 디자인 센스(?)를 가지고 있고, 그것을 포토샵이나 AI와 같은 툴을 다루지는 못했지만, 손으로 또는 파워포인트로 구현이 가능했기 때문에 어느 정도까지는 끌고 올 수 있었으나.. 세 번째 겹으로써 "Creative/Designer"가 절실히 필요한 상황에 부딪히게 되었고, 현재 함께 일하고 있는 Art director가 대단한 인연의 끈으로  조인하게 되었다. 세 겹!!여기 까지만 본다면.. 동일하게 기능으로 구성된 조직으로 보일 수 있다. 하지만.. 지금까지 조인한 사람들은 기능별로 두께만 다를 뿐, 하나의 "겹"으로써 회사의 기능을 담당하는데, 물론 본인의 전문성을 가진 분야가 하나씩은 반드시 있고... 그 외의 것들도 모두 담당하는 것이다. Pie startup에서는 모두 대부분의 영역에 대해서 실제로 업무를 해야한다. 하지만, 구성원들은 각자의 전문영역이 하나씩은 꼭 필요하다. (어두운 영역이 core skill)예를 들면, Paffem에서는 모두가 마케팅을 담당한다. 1인 1 마케팅 채널 관리를 한다. 나는 Facebook을 통해 주로 정보 전달 채널을 관리하고, Art director는 인스타그램을 통해 감성적인 이미지 중심으로 마케팅 채널을 운영한다. 새롭게 조인할 Operation을 중심 역할로 하실 분은 구체적 정보 채널인 blog를 운영해야 한다. 또한 각각의 마케팅 채널을 통해 들어오는 CS 사항들도 각 채널 운영자가 처리한다. 또한 우리는 모두 출고가 있을 때 박스를 포장한다. 사실 단순히 박스를 포장한다면, 그냥 아르바이트를 써도 되겠지만, 출고가 단순히 박스 포장만을 의미하는 것은 아니다. 포장을 하면서도 이 package를 어찌 개선해 볼지? 어떻게 하면 포장에 들어가는 시간을 줄여갈 수 있을지 고민하는 시간이다. 이러한 과정 중에 본인이 가진 강점의 영역에서 문제를 파악하고 개선해나갈 의견을 낼 수 있는 것이다. 이렇게 하면 회사 전체가 무엇을 하고 있는지에 대한 view가 생긴다. 예를 들어, 관리 시스템에서 결제고객 정보를  다운로드하고 그 자료를 택배회사의 form에 맞도록 가공하고, 또 송장을 출력하고, 박스에 부착하고.. 하다보면서, 어느 곳에서 시간 소비가 많은지? 그 이유가 무엇인지? 를 파악할 수 있게 되고, 그 문제 해결은 developer가 해결해줄 수 있다. 파펨의 경우, 고객정보 다운로드 후.. 엑셀을 통해서 배송 정보를 다시 택배회사에 업로드 해야 하는데, 이 과정에서 불필요한 작업들이 많이 발생하고 있었다. 해결 방법으로는 1) 택배회사의 양식에 맞도록 시스템을 개선 또는 2) 엑셀 sheet에 함수식으로 사전에 작업을 해두고, data를 입력되면 자동으로 변환하는 방식 이 있는데.. 우리는 개발자의 시간을 다른 곳에 사용하고, 간단히 엑셀 sheet를 변경하는 방식으로 이 문제를 해결하였다. 또한 예전에 Groupon에서 일하면서 답답했던 것 중 하나가... 사고는 영업/마케팅/운영에서 치고, 그 뒤처리는 모두 CS로 전가된다는 점이었다. 그분들의 감정노동이 어머어마했지만, 본인들이 맡은 업무가 CS이기 때문에 자신들이 저지르지도 않은 고객들의 불만을 처리하는 일만을 해야 했고, 사실 그렇게 운영하는 게  맞는가?라는 생각을 많이 했었다. 지금 조직에서는 각 채널별로 들어오는 고객의 불만 사항을 고객과의 communication 채널을 담당하고 있는 사람들이 해결한다. (대부분의 고객 불만은 우편으로 발송된 샘플을 받지 못했다 이지만..) facebook 메신저나 이메일을 통해 불만이 들어오면 내가 대응하고, 인스타그램이나 전화를 통해 들어오는 CS는 다른 분이 해결한다. 이러한 고객 불만 사항에 대해서도 모두 알고 있어야 한다는 생각이고, 각자의 전문 영역에서 이러한 사항들에 대한 해결책을 만들어 가야 하며.. 그렇기 위해서는 Pie Startup이 필요하다는 것이다. 문제의 원인은 다양한 곳에서 발생하고,그 문제의 해결 또한 다양한 영역에서의 고민과 작업이 필요하다.물론 이러한 조직이 모든 조직에 해당되는 것은 아닐 것이다. 작고 빠른 조직에 어울리는 운영 방침이라는 생각이고, 조직원이 하나의 영역에 전문성을 가지면서도 "all round player"라는 재능까지 가지고 있어야 운영이 가능하다. 내가 생각하는 paffem은 10명이서 100억의 매출을 만드는 것이 목표인데, 그 목표 하에서는 이러한 조직 운영이 가능하다는 생각이다. (왜  10명인가?라는 것은 다시 한번 다뤄야 하는 주제일 텐데.... 가장 큰 이유는 10명이 넘으면 조직이 하나가 되어 일하는데  장애가 되기 때문이다. 요건 추후 업데이트 예정) 한 겹 한 겹이 쌓이고 쌓여 하나의 "걸작" 파이가 되어 간다. PS. 이 글은 계속해서 업데이트를 해나갈 예정이다. 나에게도 시행착오가 있을 수 있고, 또한 추가로 언급하고 싶은 포인트가 생길지 모르기 때문이다. #파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

기업문화 엿볼 때, 더팀스

로그인

/