스토리 홈

인터뷰

피드

뉴스

조회수 1659

HBase 설정 최적화하기 - VCNC Engineering Blog

커플 필수 앱 비트윈은 여러 종류의 오픈 소스를 기반으로 이루어져 있습니다. 그 중 하나는 HBase라는 NoSQL 데이터베이스입니다. VCNC에서는 HBase를 비트윈 서비스의 메인 데이터베이스로써 사용하고 있으며, 또한 데이터 분석을 위한 DW 서버로도 사용하고 있습니다.그동안 두 개의 HBase Cluster 모두 최적화를 위해서 여러 가지 설정을 테스트했고 노하우를 공유해 보고자 합니다. 아랫은 저희가 HBase를 실제로 저희 서비스에 적용하여 운영하면서 최적화한 시스템 구성과 설정들을 정리한 것입니다. HBase를 OLTP/OLAP 목적으로 사용하고자 하는 분들에게 도움이 되었으면 좋겠습니다. 아래 구성을 최적화하기 위해서 했던 오랜 기간의 삽질기는 언젠가 따로 포스팅 하도록 하겠습니다.HBaseHBase는 Google이 2006년에 발표한 BigTable이라는 NoSQL 데이터베이스의 아키텍처를 그대로 따르고 있습니다. HBase는 뛰어난 Horizontal Scalability를 가지는 Distributed DB로써, Column-oriented store model을 가지고 있습니다. 사용량이 늘어남에 따라서 Regionserver만 추가해주면 자연스럽게 Scale-out이 되는 구조를 가지고 있습니다. 또한, Hadoop 특유의 Sequential read/write를 최대한 활용해서 Random access를 줄임으로 Disk를 효율적으로 사용한다는 점을 특징으로 합니다. 이 때문에 HBase는 보통의 RDBMS와는 다르게 Disk IO가 병목이 되기보다는 CPU나 RAM 용량이 병목이 되는 경우가 많습니다.HBase는 많은 회사가 데이터 분석을 하는 데 활용하고 있으며, NHN Line과 Facebook messenger 등의 메신저 서비스에서 Storage로 사용하고 있습니다.시스템 구성저희는 Cloudera에서 제공하는 HBase 0.92.1-cdh4.1.2 release를 사용하고 있으며, Storage layer로 Hadoop 2.0.0-cdh4.1.2를 사용하고 있습니다. 또한, Between의 데이터베이스로 사용하기 위해서 여러 대의 AWS EC2의 m2.4xlarge 인스턴스에 HDFS Datanode / HBase Regionserver를 deploy 하였습니다. 이는 m2.4xlarge의 큰 메모리(68.4GB)를 최대한 활용해서 Disk IO를 회피하고 많은 Cache hit이 나게 하기 위함입니다.또한 Highly-Available를 위해서 Quorum Journaling node를 활용한 Active-standby namenode를 구성했으며, Zookeeper Cluster와 HBase Master도 여러 대로 구성하여 Datastore layer에서 SPOF를 전부 제거하였습니다. HA cluster를 구성하는 과정도 후에 포스팅 하도록 하겠습니다.HDFS 최적화 설정dfs.datanode.handler.countHDFS에서 외부 요청을 처리하는 데 사용할 Thread의 개수를 정하기 위한 설정입니다. 기본값은 3인데 저희는 100으로 해 놓고 사용하고 있습니다.dfs.replicationHDFS 레벨에서 각각의 데이터가 몇 개의 독립된 인스턴스에 복사될 것 인가를 나타내는 값입니다. 저희는 이 값을 기본값인 3으로 해 놓고 있습니다. 이 값을 높이면 Redundancy가 높아져서 데이터 손실에 대해서 더 안전해지지만, Write 속도가 떨어지게 됩니다.dfs.datanode.max.transfer.threads하나의 Datanode에서 동시에 서비스 가능한 block 개수 제한을 나타냅니다.과거에는 dfs.datanode.max.xcievers라는 이름의 설정이었습니다.기본값은 256인데, 저희는 4096으로 바꿨습니다.ipc.server.tcpnodelay / ipc.client.tcpnodelaytcpnodelay 설정입니다. tcp no delay 설정은 TCP/IP network에서 작은 크기의 패킷들을 모아서 보냄으로써 TCP 패킷의 overhead를 절약하고자 하는 Nagle's algorithm을 끄는 것을 의미합니다. 기본으로 두 값이 모두 false로 설정되어 있어 Nagle's algorithm이 활성화되어 있습니다. Latency가 중요한 OLTP 용도로 HBase를 사용하시면 true로 바꿔서 tcpnodelay 설정을 켜는 것이 유리합니다.HBase 최적화 설정hbase.regionserver.handler.countRegionserver에서 외부로부터 오는 요청을 처리하기 위해서 사용할 Thread의 개수를 정의하기 위한 설정입니다. 기본값은 10인데 보통 너무 작은 값입니다. HBase 설정 사이트에서는 너무 큰 값이면 좋지 않다고 얘기하고 있지만, 테스트 결과 m2.4xlarge (26ECU) 에서 200개 Thread까지는 성능 하락이 없는 것으로 나타났습니다. (더 큰 값에 관해서 확인해 보지는 않았습니다.)저희는 이 값을 10에서 100으로 올린 후에 약 2배의 Throughput 향상을 얻을 수 있었습니다.hfile.block.cache.sizeHBase 의 block 들을 cache 하는데 전체 Heap 영역의 얼마를 할당한 것인지를 나타냅니다. 저희 서비스는 Read가 Write보다 훨씬 많아서 (Write가 전체의 약 3%) Cache hit ratio가 전체 성능에 큰 영향을 미칩니다.HBase 에서는 5분에 한 번 log 파일에 LruBlockCache (HBase 의 Read Cache) 가 얼마 만큼의 메모리를 사용하고 있고, Cache hit ratio가 얼마인지 표시를 해줍니다. 이 값을 참조하셔서 최적화에 사용하실 수 있습니다.저희는 이 값을 0.5로 설정해 놓고 사용하고 있습니다. (50%)hbase.regionserver.global.memstore.lowerLimit / hbase.regionserver.global.memstore.upperLimit이 두 개의 설정은 HBase에서 Write 한 값들을 메모리에 캐쉬하고 있는 memstore가 Heap 영역의 얼마만큼을 할당받을지를 나타냅니다. 이 값이 너무 작으면 메모리에 들고 있을 수 있는 Write의 양이 한정되기 때문에 디스크로 잦은 flush가 일어나게 됩니다. 반대로 너무 크면 GC에 문제가 있을 수 있으며 Read Cache로 할당할 수 있는 메모리를 낭비하는 것이기 때문에 좋지 않습니다.lowerLimit와 upperLimit의 두 가지 설정이 있는데, 두 개의 설정이 약간 다른 뜻입니다.만약 memstore 크기의 합이 lowerLimit에 도달하게 되면, Regionserver에서는 memstore들에 대해서 'soft'하게 flush 명령을 내리게 됩니다. 크기가 큰 memstore 부터 디스크에 쓰이게 되며, 이 작업이 일어나는 동안 새로운 Write가 memstore에 쓰일 수 있습니다.하지만 memstore 크기의 합이 upperLimit에 도달하게 되면, Regionserver는 memstore들에 대한 추가적인 Write를 막는 'hard'한 flush 명령을 내리게 됩니다. 즉, 해당 Regionserver이 잠시 동안 Write 요청을 거부하게 되는 것입니다. 보통 lowerLimit에 도달하면 memstore의 크기가 줄어들기 때문에 upperLimit까지 도달하는 경우는 잘 없지만, write-heavy 환경에서 Regionserver가 OOM으로 죽는 경우를 방지하기 위해서 hard limit가 존재하는 것으로 보입니다.hfile.block.cache.size와 hbase.regionserver.global.memstore.upperLimit의 합이 0.8 (80%)를 넘을 수 없게 되어 있습니다. 이는 아마 read cache 와 memstore의 크기의 합이 전체 Heap 영역 중 대부분을 차지해 버리면 HBase의 다른 구성 요소들이 충분한 메모리를 할당받을 수 없기 때문인 듯합니다.저희는 이 두 개의 설정 값을 각각 0.2, 0.3으로 해 놓았습니다. (20%, 30%)ipc.client.tcpnodelay / ipc.server.tcpnodelay / hbase.ipc.client.tcpnodelayHDFS의 tcpnodelay 와 비슷한 설정입니다. 기본값은 전부 false입니다.이 설정을 true로 하기 전에는 Get/Put 99%, 99.9% Latency가 40ms 와 80ms 근처에 모이는 현상을 발견할 수 있었습니다. 전체 요청의 매우 작은 부분이었지만, 평균 Get Latency가 1~2ms 내외이기 때문에 99%, 99.9% tail이 평균 Latency에 큰 영향을 미쳤습니다.이 설정을 전부 true로 바꾼 후에 평균 Latency가 절반으로 하락했습니다.Heap memory / GC 설정저희는 m2.4xlarge가 제공하는 메모리 (68.4GB)의 상당 부분을 HBase의 Read/Write cache에 할당하였습니다. 이는 보통 사용하는 Java Heap 공간보다 훨씬 큰 크기이며 심각한 Stop-the-world GC 문제를 일으킬 수 있기 때문에, 저희는 이 문제를 피하고자 여러 가지 설정을 실험하였습니다.STW GC time을 줄이기 위해서 Concurrent-Mark-and-sweep GC를 사용했습니다.HBase 0.92에서부터 기본값으로 설정된 Memstore-Local Allocation Buffer (MSLAB) 을 사용했습니다. hbase.hregion.memstore.mslab.enabled = true #(default)hbase-env.sh 파일을 다음과 같이 설정했습니다. HBASE_HEAPSIZE = 61440 #(60GB) HBASE_OPTS = "-XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps"GC log를 Python script로 Parsing해서 STW GC 시간을 관찰하고 있습니다. 지금까지 0.2초 이상의 STW GC는 한 번도 발생하지 않았습니다.그 밖에 도움이 될 만한 설정들hbase.hregion.majorcompactionHBase는 하나의 Region에 대해서 여러 개의 StoreFile을 가질 수 있습니다. 그리고 주기적으로 성능 향상을 위해서 이 파일들을 모아서 하나의 더 큰 파일로 합치는 과정을 진행하게 됩니다. 그리고 이 과정은 많은 CPU usage와 Disk IO를 동반합니다. 그리고 이때 반응 속도가 다소 떨어지게 됩니다. 따라서 반응 속도가 중요한 경우에는, 이 Major compaction을 off-peak 시간대를 정해서 manual 하게 진행하시는 것이 좋습니다.저희는 사용자의 수가 상대적으로 적은 새벽 시간대에 crontab 이 실행시키는 script가 돌면서 전체 Region에 대해서 하나하나 Major Compaction이 진행되도록 하였습니다.기본값은 86,400,000 (ms)로 되어 있는데, 이 값을 0으로 바꾸시면 주기적인 Major Compaction이 돌지 않게 할 수 있습니다.hbase.hregion.max.filesizeHBase는 하나의 Region이 크기가 특정 값 이상이 되면 자동으로 2개의 Region으로 split을 시킵니다. Region의 개수가 많지 않을 때는 큰 문제가 없지만, 계속해서 데이터가 쌓이게 되면 필요 이상으로 Region 수가 많아지는 문제를 나을 수 있습니다. Region 수가 너무 많아지면 지나친 Disk IO가 생기는 문제를 비롯한 여러 가지 안 좋은 점이 있을 수 있기 때문에, split 역시 manual 하게 하는 것이 좋습니다. 그렇다고 Table의 Region 수가 너무 적으면 Write 속도가 떨어지거나 Hot Region 문제가 생길 수 있기 때문에 좋지 않습니다.HBase 0.92.1 에서는 기본값이 1073741824(1GB)로 되어 있는데, 저희는 이 값을 10737418240(10GB)로 늘인 후에 manual 하게 split을 하여 Region의 개수를 조정하고 있습니다.hbase.hregion.memstore.block.multipliermemstore의 전체 크기가 multiplier * flush size보다 크면 추가적인 Write를 막고 flush가 끝날때까지 해당 memstore는 block 됩니다.기본값은 2인데, 저희는 8로 늘려놓고 사용하고 있습니다.dfs.datanode.balance.bandwidthPerSec부수적인 설정이지만, HDFS의 Datanode간의 load balancing이 일어나는 속도를 제한하는 설정입니다. 기본값은 1MB/sec로 되어 있지만, 계속해서 Datanode를 추가하거나 제거하는 경우에는 기본값으로는 너무 느릴 때가 있습니다. 저희는 10MB/sec 정도로 늘려서 사용하고 있습니다.dfs.namenode.heartbeat.recheck-intervalHDFS namenode에만 해당되는 설정입니다.Datanode가 응답이 없는 경우에 얼마 후에 Hadoop cluster로부터 제거할 것인지를 나타내는 값입니다.실제로 응답이 없는 Datanode가 떨어져 나가기까지는 10번의 heartbeat가 연속해서 실패하고 2번의 recheck역시 실패해야 합니다. Heartbeat interval이 기본값인 3초라고 하면, 30초 + 2 * recheck-interval 후에 문제가 있는 Datanode가 제거되는 것입니다.기본값이 5분으로 되어 있는데, fail-over가 늦어지기 때문에 사용하기에는 너무 큰 값입니다. 저희는 문제가 있는 Datanode가 1분 후에 떨어져 나갈 수 있도록 이 값을 15,000 (ms) 으로 잡았습니다.Read short-circuitRegionServer가 로컬 Datanode로부터 block을 읽어올 때 Datanode를 통하지 않고 Disk로부터 바로 읽어올 수 있게 하는 설정입니다.데이터의 양이 많아서 Cache hit이 낮아 데이터 대부분을 디스크에서 읽어와야 할 때 효율적입니다. Cache hit에 실패하는 Read의 Throughput이 대략 2배로 좋아지는 것을 확인할 수 있습니다. OLAP용 HBase에는 매우 중요한 설정이 될 수 있습니다.하지만 HBase 0.92.1-cdh4.0.1까지는 일부 Region이 checksum에 실패하면서 Major compaction이 되지 않는 버그가 있었습니다. 현재 이 문제가 해결되었는지 확실하지 않기 때문에 확인되기 전에는 쓰는 것을 추천하지는 않습니다.설정하는 방법은 다음과 같습니다. dfs.client.read.shortcircuit = true #(hdfs-site.xml) dfs.block.local-path-access.user = hbase #(hdfs-site.xml) dfs.datanode.data.dir.perm = 775 #(hdfs-site.xml) dfs.client.read.shortcircuit = true #(hbase-site.xml)Bloom filterBloom filter의 작동방식에 대해 시각적으로 잘 표현된 데모 페이지HBase는 Log-structured-merge tree를 사용하는데, 하나의 Region에 대해서 여러 개의 파일에 서로 다른 version의 값들이 저장되어 있을 수 있습니다. Bloom filter는 이때 모든 파일을 디스크에서 읽어들이지 않고 원하는 값이 저장된 파일만 읽어들일 수 있게 함으로써 Read 속도를 빠르게 만들 수 있습니다.Table 단위로 Bloom filter를 설정해줄 수 있습니다.ROW와 ROWCOL의 두 가지 옵션이 있는데, 전자는 Row key로만 filter를 만드는 것이고, 후자는 Row+Column key로 filter를 만드는 것입니다. Table Schema에 따라 더 적합한 설정이 다를 수 있습니다.저희는 데이터 대부분이 메모리에 Cache 되고 하나의 Region에 대해서 여러 개의 StoreFile이 생기기 전에 compaction을 통해서 하나의 큰 파일로 합치는 작업을 진행하기 때문에, 해당 설정을 사용하지 않고 있습니다.결론지금까지 저희가 비트윈을 운영하면서 얻은 경험을 토대로 HBase 최적화 설정법을 정리하였습니다. 하지만 위의 구성은 어디까지나 비트윈 서비스에 최적화되어 있는 설정이며, HBase의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.
조회수 1749

Ginger T Project: About Us

진저티프로젝트는 세상을 변화시키는 사람들을 주목하고, 그들의 비전을 함께 꿈꾸고, 탁월한 조직으로 성장하도록 함께 고민하여 비영리섹터의 실제적변화를 돕는 공익프로젝트 컨설팅 전문회사입니다.진저티프로젝트는 비영리섹터의 건강한 성장과 탁월한 성과를 위한 구체적이고 실행가능한 변화를 지원합니다.우리는 NPO의 사회적 영향력이 건강하게 사회적으로 확산될 수 있기를 바랍니다.▶ 가치: 공감, 존중, 에너지, 열정적인사람, 확산적사고, 본질에 집중, 측정가능한 변화▶ 목적:Bring Real Change: 믿을 수 있는 변화(Change We can Believe)를 가져오는 서비스를 비영리, 자선사업의 모금, 커뮤니케이션, 경영, 교육 영역에 제공합니다.Connect NPO Professionals: 비영리컨설팅/경영전문성을 대내외적으로 구축합니다. 내적으로는 외부자극에 유연한 학습조직으로 운영, 외적으로는 비영리경영전문가 집단의 지원 네트워크 구축합니다.Appreciate Efficient/ Respected Work Environment: 비영리섹터의 효율적, 개방적 자원의 운영을 추구하며, 구성원의 라이프싸이클과 상황이 고려되는 업무환경/커리어패스를 추구합니다. ▶ 서비스: A. 비영리단체 서포트 프로젝트BIC Project 를 활용한 비영리단체 자가진단, 이슈파악, 솔루션 도출 (2일, 단체방문 1회): 주기적 BIC 멘토링 진행 (교육, 자가진단, 이슈파악), 단체 방문(모니터링, 문제해결), 온/오프라인을 통한 지속적 어드바이스 제공, 전문가 연계조직 전반/장기 컨설팅 (BIC Project 모듈 활용, 전문가집단과 협업, 6-12개월): 단체의 총체적/근본적 경영/관리 문제 해결 (6-12개월)슈별/소규모/단기 컨설팅 (BIC Project 모듈 필요 영역별 활용, 1-3개월): 모금솔루션 (모금스터디) 매니지먼스 솔류션 (투명성, 리더쉽, 자원관리, 시스템, 프로젝트)위탁운영서비스 (BIC Project 모듈 활용, 전문가집단과 협업, 1-2년): 비영리단체 운영을 위탁위임 받아 총체적 근본적/경영관리 문제 해결B. 비영리 연구/출판 프로젝트자선/비영리 사업의 기반이 되는 기초 조사 (현황파악, 욕구조사)자선/비영리 조직/역량강화를 위한 출판 사업C. 기업/기업재단 사회공헌 프로젝트기금사업관리 (기획, 운영, 평가)사회공헌프로젝트 (교육, 워크샵, 프로그램)스타트업 컨설팅 (사회적기업, 소셜벤쳐)▶ 사람들: 최경인 [email protected]전문영역: 통합 마케팅/소비자 조사, 모금/배분 사업 기획/관리, 국내외 비영리관련 연구조사2014 (현)진저티프로젝트 / 프로젝트팀장2011 - 2013 Give2Asia 한국지역 어드바이저2009 - 2010 아름다운재단 국제협력연구팀장2005 - 2007 포뎀대학 사회복지대학원2003 - 2004 아름다운가게 팀장1999 - 2003 한국피앤지유한회사 브랜드매니저서현선 [email protected]전문영역: 교육기획•교육컨설팅, 모금기획•모금조직관리2014 (현)진저티프로젝트 / 프로젝트팀장2011 (현) 여명학교 모금위원장2010 - 2011 Give2Asia 한국지역 어드바이저2008 - 2009 아름다운재단 나눔교육전문위원2002 - 2007 아름다운재단 국제협력연구팀장황선미 [email protected]전문영역: 비영리 조직관리(커뮤니케이션, 투명성, 모금, 리더쉽) 모금•배분•교육•연구 사업기획, 민간재단 및 기업사회공헌 트렌드 연구조사2014 (현)진저티프로젝트 / 프로젝트팀장2013 모금스터디 진행 및 모금컨설팅2003 - 2012 아름다운재단 사업국장2000 - 2002 품청소년문화공동체 홍주은 [email protected]전문영역: 기부문화 연구, 비영리 교육 및 번역 출판, 국내외 비영리 트렌드 조사2014 (현) 진저티프로젝트 / 프로젝트매니저2013 (현) 보스톤한미예술협회 펀드레이징 어드바이저2006 – 2009 아름다운재단 국제협력연구팀 기부문화연구소 담당 김지연 [email protected] (현) 진저티프로젝트/BIC프로젝트매니저2007-2009 부여군 청소년수련원2005-2007 군포시 당동청소년문화의집2003-2004 한국방송제작단(프로덕션)2002-2003 품청소년문화공동체 이슬기 [email protected] (현) 진저티프로젝트 / 프로젝트어시스턴트2014 (현) 여명학교 계절학기/방과후 프로그램 코디네이터2013-2014 끌리베에듀케이션(Kliebe Education) 교사, 통역사2013 에모리대학교(Emory University) 심리학 & 교육학 졸업 w/ honors2011-2013 에모리대학교(Emory University) 연구원2013 Marcus Autism Center Early Intervention Program 보조교사#진저티프로젝트 #회사소개 #서비스소개 #기업문화 #가치소개
조회수 2867

iOS 개발을 위한 11가지 노하우

Overview기고 제안을 받자마자 iOS 개발을 시작했을 때가 떠올랐습니다. 신대륙을 마주한 것 같았던 그때의 기분을 아직도 잊지 못하기 때문입니다. 당시까지만 해도 Android 개발만 했기 때문에 iOS는 그야말로 미지의 영역이었습니다. 게다가 개발을 시작하려고 조심스럽게 첫 발을 내딛은 순간, 입이 떡 벌어질 수밖에 없었죠.“이렇게 느린 IDE가 있다니…““개발자 프로그램이 뭐 이렇게 비싸?”XCodeXCode는 그동안 접했던 IDE 중에서도 가장 최악이었고, 개발자 프로그램 등록은 13만 원 상당의 비용을 지불해야 했습니다. 가장 중요한 건 맥 컴퓨터(Macintosh)를 보유해야만 했죠. 처음 개발을 시작하려니 넘어야 할 산이 매우 많았습니다. 맞습니다. 팜므파탈의 대명사 마타하리(Mata Hari)처럼 iOS 개발은 밀당과도 같습니다. 분명 매력적인 일이지만 XCode와 개발자 프로그램 등록은 빙산의 일각이기 때문입니다. iOS는 곳곳에 구덩이를 파고 초보 개발자들을 집어삼킬 준비를 하고있습니다. (예를 들면 리소스를 묶어놓은 R.java 파일 같은 레퍼런스가 없습니다. 흑.)그래서 준비했습니다. 수많은 초보 개발자들이 iOS의 구덩이를 피해갈 수 있는 팁을 말이죠.iOS의 구덩이를 피하는 11가지 방법1.비싼 맥(Macintosh)을 사세요.iOS 개발자에게 MacOS는 필수입니다. XCode가 MacOS만 지원하기 때문입니다. 오픈 소스로 공개된 Swift에는 제약이 없지만 XCode는 MacOS에서만 동작하는 제약이 있습니다. 따라서 맥은 iOS 개발자에게 가장 필요한 준비물입니다. 게다가 하드웨어 리소스를 많이 사용하는 XCode 탓에 더 크고, 더 비싸고, 더 아름다운 맥을 구매하셔야 합니다. Macbook이나 Macbook Air 모두 추천하지 않습니다. 15형 Macbook Pro 모델을 비롯해, Mac Pro나 iMac Pro 등의 고급 모델을 사용하면.. 개발이 잘 됩니다.2.돈을 내세요.iOS를 개발하려면 가장 먼저 Apple Developer Portal에서 연 129,000원의 개발자 프로그램에 등록해야 합니다. XCode를 사용해서 코드만 볼 것이라면 문제가 되지 않지만, 디바이스에 앱을 설치하고, 테스트하며, AppStore에 배포할 거라면 반드시 구매해야 합니다. 이 계정은 앞서 말한 것처럼 1년이 지나면 다시 구매해야 합니다. 만약 기업 개발자로 등록하려면 Enterprise Program이 따로 준비되어 있습니다. 기업을 위해 특화된 In-House 배포 등의 이점이 있습니다. 구매해야할 것이 꽤 많죠? 이제 익숙해져야 합니다.3.XCode를 설치하세요.XCode는 Mac App Store에서 설치할 수 있습니다. 용량이 크기 때문에 설치하기 전에 하드디스크 저장공간부터 확인하는 것이 좋습니다. 처음 실행하면 추가 컴포넌트를 다운로드하는 과정이 실행되고, 그 이후에 XCode를 사용할 수 있습니다. XCode와 관련된 자세한 내용은 아래에서 자세하게 다루겠습니다.4.어려운 것에 대비하세요.1)인증서‘들’XCode 설치 이후에도 몇 가지를 발급 받고, 셋업해야 합니다. 방 탈출 게임처럼 한 단계 한 단계 거치는 과정이 필요합니다. 첫 번째로 인증서‘들’을 발급받아야 합니다. 애플을 대신해 앱을 설치하고, 배포할 수 있는 권한을 위임 받는 과정입니다. 이 인증서들은 Apple Developer Portal의 ‘Certificates, IDS & Profiles’ 항목에서 발급 받을 수 있으며, MacOS의 키체인 앱을 이용해 개인 키를 생성하는 방식으로도 방식으로 발급 받을 수 있습니다. 2)디바이스 등록디바이스-iOS-에 개발한 앱을 설치하려면 애플 개발자 계정에 개발용 디바이스를 등록해야 합니다. 이 과정은 XCode에 신규 디바이스를 연결하고, 빌드 및 배포를 할 때 XCode가 알아서 합니다. 만약 디바이스를 보유하고 있지 않은 상황이라면 해당 디바이스의 UUID를 받아서 개발자 포털에 직접 등록할 수도 있습니다. 3)Bundle IDBundle ID는, 앱의 고유한 ID입니다. iOS가 앱을 식별할 때 사용하는 식별자이며, 보통 ‘com.companyname.appname’ 의 형식으로 회사나 개인의 도메인을 거꾸로 쓰는 것이 보편적입니다. 하지만 Bundle ID는 어디까지나 개발자가 결정하는 영역이므로 인스턴스 이름 지정하듯이 자신만의 고유한 방법을 사용해서 Bundle ID를 지정해도 문제가 없습니다. 4)Provisioning ProfileProvisioning Profile은 디바이스 정보와 앱 정보, 인증서 정보를 매핑해주는 Profile입니다. 최신 XCode에서는 이 Provisioning Profile을 자동으로 관리해주기 때문에 따로 신경쓰지 않아도 좋습니다.5.개발자 포럼에 질문하거나, StackOverflow에 질문하거나!질문하는 사람은 아름답습니다. 궁금하거나, 잘 안 풀리는 코드는 개발자 포럼에서 질문할 수 있습니다. 대신 영어 실력이 좋아야 합니다.크게 기대는 하지 않는 것이 좋습니다. 등록된 discussion에 대한 답글들이 ‘나도 같은 상황이다’, ‘나도 궁금한 점이다’ 등의 다른 개발자들의 답변 정도가 일반적이기 때문이죠.그들의 답변...저는 개발자 포럼보다 StackOverflow를 더 선호합니다. 참여하는 개발자 규모가 다르기 때문에 보다 양질의 정보를 빠르게 찾을 수 있습니다. (하지만 허위 정보도 존재합니다.) Vote 시스템으로 신뢰 높은 정보를 필터링할 수 있으나, 어떤 정보를 선택할지는 당신의 몫입니다.6. iTunesConnect와 친하게 지내세요.앱을 개발했다면, iTunesConnect를 통해 앱을 전 세계의 사용자들에게 배포할 수 있습니다. iTunesConnect는 iOS용으로 개발된 바이너리를 배포하는 등 앱 배포/테스트와 관련된 전반적인 사항들을 관리할 수 있는 포털입니다. AppStore에서 앱을 판매하려면 이 iTunesConnect를 통해 애플과 계약을 해야만 가능합니다. 출시할 앱을 등록하기도 하고, 앱의 사용자들이 어떤 경향을 보이는지 Trend Analysis를 확인할 수도 있습니다.iTunesConnectiTunesConnect에는 다양한 메뉴들이 있고, 앱을 배포하고 관리하는데 필요한 여러 툴이 있으므로 개발 중에 시선을 환기하고자 한다면 iTunesConnect를 한 바퀴 둘러보는 것도 좋습니다. 언젠가는 다 사용하게 될 테니까요.7.앱 개발을 마쳐도 XCode를 사용하세요.앱을 개발하고 iTunesConnect에 업로드하려면, XCode를 통해 간접적으로 바이너리를 업로드하게 됩니다. 서드파티 앱을 사용할 수도 있지만, 제가 주로 많이 사용하는 방식은 XCode입니다. 소스코드가 준비되었다면, XCode 메뉴의 Product > Archive 메뉴를 선택해 XCode가 배포용 앱을 빌드합니다. 빌드가 완료되면, 자동으로 Organizer 창이 열리면서 앱을 업로드할 수 있게 되죠. 이 때 미리 구매한 개발자 계정의 인증서가 준비되어 있어야 합니다. 모든 준비가 완료되고 아카이빙이 완료되면, Organizer의 Archives 탭에서 우측단의 ‘Upload to App Store…’ 버튼으로 바이너리 업로드를 진행할 수 있습니다.8.배포 전에 시험비행을 해봅시다.앱을 개발했다면, 테스트플라이트(TestFlight)를 통해 실제로 앱을 배포하기 전 ‘시험비행’을 할 수 있습니다. iTunesConnect에 관련 테스터들을 등록하고, 등록된 사용자들을 대상으로 미리 앱을 테스트할 수 있도록 요청하는 것이죠. 이 테스트플라이트에 배포된 바이너리를 그대로 AppStore에 배포하게 되므로, 테스트용으로 유용합니다.TestFlight테스트플라이트는 원래 iOS 배포 관리 솔루션을 제공하는 업체였지만 지금은 애플이 인수해 iTunesConnect에서 관리하도록 제공하고 있습니다.9.앱이 죽는다면 Organizer로 확인하세요.iOS는 충돌보고 Crash Report를 Organizer를 통해 오류를 확인합니다. 앱을 설치한 사용자가 동의하면 XCode는 iOS가 앱을 실행하면서 발생한 Crash Report를 애플에 자동으로 업로드합니다. 업로드된 Crash Report들은 XCode의 Organizer를 통해 다운로드하고, 확인할 수 있습니다. Organizer는 XCode > Window > Organizer 항목에서 실행하세요.Organizer와 Crash ReportCrash Report는 Organizer의 상단 Crashes 탭에서 확인이 가능합니다. 또 현재 보고 있는 Crash Report의 어느 부분에서 오류가 발생했는지 알고 싶다면 우측단의 ‘Open in Porject…’ 버튼을 눌러보면 됩니다.10.내 친구 XCode최근 XCode는 메이저 업데이트를 통해 사용성과 퍼포먼스를 향상시켰습니다. 하지만 이만큼 무겁고 느린 통합개발툴 IDE는 이클립스(Eclipse) 이후에 처음입니다. 안드로이드의 경우 IntelliJ 기반의 Android Studio로 쾌적한 개발환경을 제공하고 있는 반면, XCode의 업데이트는 퍼포먼스나 사용성 개선보다는 Swift의 메이저 버전 반영에 더 급급한 느낌입니다. (업데이트 때마다 속지만 ‘혹시 이번에는..’하고 또 속아 넘어갑니다.) XCode 사용을 위한 네 가지 팁을 소개합니다.1)XCode는 모노로그입니다.XCode는 로그를 따로 ‘예쁘게’ 볼 수 없습니다. 검은 화면에 흰 로그가 정리되지 않은 상태로 마구마구 출력됩니다. 개발자들에게는 쥐약같은 상황이죠. 이런 불편한 로그 출력 방식 때문에 저는 별도의 GlobalLogger 모듈을 작성해서 다음과 같은 스타일로 로그를 출력하도록 하고 있습니다.$$ BrandiLogger Error Log ##MESSAGE: Initial Parameter is not exist. ##LOCATION: BRLogPringer.swift @Line: 122 2)iOS개발자를 위한 휴식시간, 빌드 타임XCode의 빌드 타임은 개발자에겐 기나긴 휴식 시간입니다. 소스가 비대해질수록 퍼포먼스는 떨어지며, 담배 한 대를 태우고, 화장실에서 손을 씻고 들어와도 빌드가 절반도 안 된 상황을 마주할 겁니다. 빌드 타임을 줄이고자 구글링을 하면 몇 가지 팁을 발견할 수 있는데, 특히 빌드 타임을 가장 많이 단축할 수 있는 방법이 있습니다.짜잔! 공개합니다!먼저, 프로젝트 셋팅의 ‘Build Settings’ 항목에서 ‘Optimization Level’을 검색합니다. ‘Swift Compiler - Code Generation’ 항목을 찾을 수 있는데요. 여기서 Optimization Level의 Debug 항목을 ‘None’으로 설정하면, 빌드시간이 엄청나게 줄어든 것을 확인할 수 있습니다. Brandi iOS 버전의 소스코드는 원래 컴파일에 7분 이상이 소요되었지만, Optimization Level을 변경한 후 1분 내외로 단축되었습니다. Optimization Setting을 변경할 때는 꼭 Debug 항목만 변경하고, Release 버전은 기존 설정을 유지하는 것이 좋습니다. 그래야 빌드 과정에서의 버그를 막을 수 있기 때문이죠. 만약 이 설정으로 개발하던 도중 소스가 충돌되면 Command+Shift+K 단축키를 눌러 소스를 한 번 클린하고, 재빌드하세요. 충돌이 사라지는 경우가 많습니다. 빠른 빌드를 위해 종종 감수해야 하는 부분이기도 합니다. 3)Derived Data빌드가 자꾸 안되고 꼬일 때는 Derived Data 폴더를 삭제 해 보세요. Derived Data 폴더는 XCode > File > Project Settings(Workspace Settings) 항목에서 ‘Derived Data’ 항목 아래의 폴더 경로에서 접근할 수 있습니다. Derived Data 접근 경로Derived Data 폴더를 삭제하면 거짓말처럼 빌드 오류가 사라지는 기적을 만날 수 있습니다. 4)CocoaPods‘바퀴를 두 번 발명할 필요는 없다’는 격언이 있습니다. 이것을 개발에 적용하면 ‘잘 만들어진 라이브러리를 사용하라’ 정도가 되겠습니다. 개발자의 개발 시간을 현저하게 단축시키는 오픈소스 라이브러리. 이것들을 간편하게 사용하는 방식이 iOS에도 존재하는데, 바로 CocoaPods입니다. 프로젝트 Root 폴더에 Podfile을 생성하고, 원하는 오픈소스 라이브러리들을 명시한 후에 ‘pod install’ 명령어를 입력해주면….CocoaPods오픈소스 라이브러리가 설치되었습니다. 귀찮은 소스 다운로드와 임포트 과정을 거치지 않아도 됩니다. CocoaPods 설치와 사용에 관한 글은 구글링으로 쉽게 찾을 수 있습니다. 꼭 사용하길 권합니다.Mac App Store에서의 XCode 평점XCode는 느리고 불편합니다. 숨겨진 편의기능도 많지만 고질적인 빌드 문제와 사용성 문제를 마주하면 높은 평점을 줄 수가 없습니다. 그런데, 저만 그렇게 생각하진 않더라고요.(위 스크린샷 참조) XCode의 사용법은 기회가 되면 따로 정리하겠습니다.11.어떤 경우에도 대응할 수 있는 화면 구성을 원한다면, AutoLayoutiOS를 사용하면서, 금융권이나 쇼핑 앱들을 사용하다 보면 이런 상황이 발생합니다. 금융권 앱. 화면에 꽉 차지 않는 레이아웃 혹은 비정상적으로 커진 글씨본래 iOS는 단일 디바이스를 지향하는 플랫폼이었습니다. 아이폰 시리즈도 해상도가 변하지 않았기 때문에, 디바이스 종류가 많은 안드로이드처럼 다양한 스크린 사이즈를 지원할 필요가 없었습니다. 하지만 이제는 iPhone SE, iPhone 8, iPhone 8 Plus의 해상도에 iPhone X의 해상도까지 더해지면서 그야말로 ‘해상도 춘추전국시대’가 되었습니다.이런 다양한 해상도를 모두 지원하는 레이아웃을 구성하려면, iOS에서는 AutoLayout을 사용해야 합니다. AutoLayout은 Xib Editor에서 AutoLayout을 활성화하는 방식으로 사용할 수 있습니다. 거기에 한 가지 덧붙이면 Layout Constraints라는 개념도 있습니다. 레이아웃에 조건을 주는 방식입니다. 예를 들어 ‘어떤 해상도에서든 이 컴포넌트는 왼쪽 끝으로부터 10Point의 여백을 가지도록 한다’ 라는 식이죠. AutoLayout, Layout Constraint이 Layout Constraint를 이용하면 짧은 시간 안에 다양한 해상도를 지원하는 레이아웃을 쉽게 만들 수 있습니다. 가히 AutoLayout의 꽃입니다.ConclusionXCode/iOS 개발과 관련된 팁은 대부분 구글링으로 찾을 수 있습니다. 다룰 내용이 많지만 초보 iOS개발자들이 당황할 수 있는 내용을 중심으로 글을 썼습니다. 소소한 이야기지만, 분명 도움을 받을 수 있을 겁니다.글이정환 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #iOS #개발기 #업무환경 #인사이트 #경험공유 
조회수 823

공간 디자인의 중요성

2009년 가을, 독일 함부르크에 위치한 하겐베크 동물원(Tierpark Hagenbeck)에 방문하고나서 공간을 이해하는 관점이 완전히 달라졌다.100년이 넘은 역사를 자랑하는 하겐베크 동물원은 철장이 없는 방사식 동물원으로 유명하다. 같은 대륙의 동물들이 같은 장소에서 생활하게 하되 각 서식지 사이에 해자(성 주변에 둘러 판 도랑)를 만들어 서로 해치지 못하게 하는 방식을 세계 최초로 도입한 것이다. 사람의 시선에서는 해자가 보이지 않기 때문에 마치 광활한 평지에 여러 동물들이 자연에서 함께 어울려 사는 것처럼 보인다. 또한 습성에 따라 함께 지내는 것이 긍정적인 효과를 불러오는 동물들은 함께 서식하고, 많은 동물들이 인도에 자유롭게 활보하는 것으로도 유명하다.세계 최초의 방사식 동물원. 출처 : 하겐베크 동물원 페이스북 페이지 하겐베크 동물원은 우리 안에 갇힌 동물들을 "관찰"하는 공간이 아니었다. 동물들의 자연 서식지에 인간이 "방문"하는 공간으로 느껴졌다. 사람 중심의 공간이 아니라 그곳에 서식하는 동물 중심의 공간이었다. 이 경험이 신선한 충격이었던 가장 큰 이유는 아이들과 함께 동물원을 방문한 가족들의 모습 때문이었다. 동물원의 중요한 역할은 교육에 있다고 보는데, 이러한 방사식 공간 구성은 동물들의 자연 서식을 조금이나마 더 현실적으로 보여주고 생명 존중의 가치관을 훨씬 더 효과적으로 전달할 수 있다고 생각했다. 이때부터 공간을 연구하고 디자인하는 것에 큰 관심을 갖게 되었다. 호기심이 많다보니 궁금증이 생기면 끝없이 구글 검색을 하는 편인데, 공간의 효율성이 치명적인 역할을 하는 병원의 공간 연구, 창의성을 극대화하는 사무 공간 연구에 대해서 많은 논문을 뒤져보았다. 사실 당시 대학원 유학 준비를 시작할 때였는데 디자인씽킹(Design Thinking)의 근원지인 스탠포드 디자인 프로그램이 유일한 목표였던 나에게 새로운 호기심을 불러일으켰고, 마침내는 코넬 대학의 공간 디자인 연구 박사 과정에 동시 지원하기도 했다. (스탠포드에 진학하지 않았다면 지금 어떤 일을 하고 있을지 궁금하기도 하다.)공간에 대한 전문가는 아니지만 사무 공간 역시 공간을 사용하는 사람들에 대한 많은 배려가 필요하다고 생각한다. 단순히 넓은 공간에 좋은 책상과 의자를 배치하고, 회의실을 여러개 만들어두고, 비싼 인테리어 마감을 하는 것이 다가 아니다. 다양한 사람들과 하루동안 가장 많은 시간을 쓰는 사무 공간이야말로 과학적인 배려가 필수적이다. 디즈니, 3M, 페이스북과 같이 창의적이고 혁신적인 기업들이 공간 연구에 많은 리소스를 투자하여 홀로 집중할 수 있는 공간, 협업을 유도하는 공간 등의 다양한 조화를 만들어내는 이유가 여기에 있다.미흡하지만 개방과 폐쇄의 조화를 이루기 위해 직접 디자인한 렌딧의 사무 공간. 렌딧 민트가 포인트인 Lendit Wall 열린 커뮤니케이션을 위한 개방 공간 Creative Hall1:1 회의 공간. 답답함을 줄이기 위해 천장 개방전체적으로 개방된 공간에 각자의 자리가 있기 때문에 가끔씩 필요한 1인 집중 공간 Burning Man좀 더 편안한 분위기의 공용 휴식 공간
조회수 4092

[Tech Blog] Go 서버 개발하기

Go 서버 개발을 시작하며   특정 API만 다른 언어로 구현해서 최대의 성능을 내보자! 저희 서버는 대부분 Django framework 위에서 구현된 광고 할당 / 컨텐츠 할당 / 허니스크린 앱 서비스 이렇게 나눌 수 있는데 Python 이라는 언어 특성상 높은 성능을 기대하기가 어려웠습니다. 하지만 세가지 서비스에서 락스크린에서 어떤 컨텐츠나 광고를 보여줄지 결정하는 Allocation(할당) API 가 가장 많이 호출되고 있었는데 빈도로 보면 80% 정도로 높은 비중을 차지하고 있어서 이 Allocation API 들을 성능이 좋은 다른 언어로 구현하면 어떨까 하는 팀내 의견이 있었습니다. Why Go? 저는 예전부터 Java,  C# 등의 컴파일 언어에 익숙해서 기존 Java 와 C, 그리고 Go 라는 최근에 새로 나온 언어 중에서 아래 블로그글과 같이 여러 reference 들을 통해 성능이 좋다는 Go 로 이 API 들을 포팅하는 작업을 시작하게 되었습니다. Go 에 대한 첫 인상은 Java, C계열 언어보다 덜 verbose 보였고 python 보다는 strongly-typed, encapsulated 하다보니 자유도를 제한해서 코드를 보기 쉽게 하는 것을 선호하는 저의 성격과도 잘 맞는 언어였습니다.     출처: Carles Mateo, Performance of several languages서버 개발 환경   Server design How to import libraries  GVT (https://github.com/FiloSottile/gvt) – Go 는 vendering tool 을 통해 dependency 를 관리할 수 있습니다. GVT 의 경우 처음 도입했을 때 별로 유명하지 않았는데 사용법이 간단해서 도입하게 되었습니다. 아래와 같이 참조하고 있는 revision 을 관리해주며 update 통해서 최신 소스를 받아 올수 있습니다.   { "version": 0, "dependencies": [ { "importpath": "github.com/Buzzvil/go-env", "repository": "https://github.com/Buzzvil/go-env", "vcs": "git", "revision": "2d8489d40184a12c4d09d09ce1ff717e5dbb0745", "branch": "master", "notests": true }, ....  Design pattern  Go 언어에서는 package level cycling dependency 를 허용하지 않아서 좀더 명확한 구조를 만들기 좋았습니다. 예를들어 Service 에서는 Controller 를 참조할수 없고 Model 에서는 Controller / Service / DTO 등을 참조할수 없도록 강제했습니다. 모든 API 요청은 Route 를 통해 Controller 에게 전달되고 이 때 생성된 DTO (Data transfer object) 들을 Controller 가 직접 혹은 Service layer 에서 처리하도록 하였고 DB 에 접근할 때는 모델을 통해 혹은 직접 접근하도록 했지만 추후 구조가 복잡해지면 DB 쿼리 등을 담당하는 DAO (Data access object) 를 도입할 계획입니다   Libraries                  요소이름선택 이유NetworkGinWeb 서버이다 보니 네트워크 성능을 최우선으로 고려, 벤치마크 표를 보고 이 라이브러리를 선택Redis & cachego-redis역시 성능을 가장 중요한 지표로 보고 이 라이브러리 선택MysqlGormORM 없이는 개발하기 힘든 시대이죠. 여러 Database를 지원하고 ORM 중에서도 method chaining 을 사용하는 Gorm 을 선택Dynamoguregu dynamoAWS에서 제공하는 Dynamo 패키지를 그대로 사용하면 코드 양이 너무 많아지고 역시 method chaining 을 지원해서 선택Environment variablescaarlos0 envGo 에서는 tag 를 이용하면 좀더 코드를 간결하고 읽기 쉽게 사용할수 있는데 이 라이브러리가 환경변수를 읽어오기 쉽도록 해줌   Redis cache  func SetCache(key string, obj interface{}, expiration time.Duration) error { err := getCodec().Set(&cache.Item{ Key: key, Object: obj, Expiration: expiration, }) return err } func GetCache(key string, obj interface{}) error { return getCodec().Get(key, obj) }  Mysql  var config model.DeviceContentConfig env.GetDatabase().Where(&model.DeviceContentConfig{DeviceId: deviceId}).FirstOrInit(&config)  Dynamo if err := env.GetDynamoDb().Table(env.Config.DynamoTableProfile).Get(keyId, deviceId).All(&profiles); err == nil && len(profiles) > 0 { ... }  Environment variables  var ( Config = ServerConfigStruct{} onceConfig sync.Once ) type ( ServerConfigStruct struct { ServerEnv string `env:"SERVER_ENV"` LogLevel string .... } ) func LoadServerConfig(configDir string) { onceConfig.Do(func() {//최초 한번반 호출되도록 env.Parse(&Config) } }    Unit test   환경 구성 Test 환경에는 Redis / Mysql / Elastic search 등에 대한 independent / isolated 된 환경이 필요해서 이를 위해 docker 환경을 따로 구성하였습니다. Test case 작성은 아래와 같이 package 를 분리해서 작성했습니다.  package buzzscreen_test var ts *httptest.Server func TestMain(m *testing.M) { ts = tests.GetTestServer(m) // 환경 시작 tearDownElasticSearch := tests.SetupElasticSearch() tearDownDatabase := tests.SetupDatabase() code := m.Run() // 여기서 작성한 TestCase 들 실행 // 환경 종료 tearDownDatabase() tearDownElasticSearch() ts.Close() os.Exit(code) }  Mock server는 은 http.RoundTripper interface 를 구현해서 http.Client 의 Transport 멤버로 설정해서 구현했습니다. 아래는 Test case 작성 예제입니다.  httpClient := network.DefaultHttpClient mockServer := mock.NewTargetServer(network.GetHost(MockServerUrl)) .AddResponseHandler(&mock.ResponseHandler{ WriteToBody: func() []byte { return []byte(mockRes) }, Path: "/path", Method: http.MethodGet, }) clientPatcher := mock.PatchClient(httpClient, mockServer) defer clientPatcher.RemovePatch()  Unit test 관련해서는 내용이 방대해서 추후 다른 포스트를 통해 자세히 소개하도록 하겠습니다.  Infra API 요청 분할 AWS Application load balancer 여러 API 중에서 할당 API 를 제외한 요청은 기존의 Django 서버로 요청을 보내고 할당요청에 대해서만 Go서버로 요청을 보내도록 구현하기 위해 먼저 시도 했던 것은 AWS Application load balancer (이후 ALB) 였습니다. ALB 의 특징이 path 로 요청을 구별해서 처리할수 있었기 때문에 Allocation API 만 Go 서버 로 요청이 가도록 구현했습니다.  출처: Amazon Devops Blog, Introducing Application Load Balancer   하지만 이렇게 오랫동안 서비스 하지 못했는데 그 이유는 서버 구성이 하나 더 늘어나고 앞단에 ALB 까지 추가되다 보니 이를 관리하는데 추가 리소스가 들어가게 되어서 어떻게 하면 이러한 비용을 줄일수 있을까 고민하게 되었습니다.   Using docker & nginx  Go로 작성된 서버가 독립적인 Micro service 냐 아니면 Django 서버에서 특정 API 를 독립시켜 성능을 강화한 모듈이냐 의 정체성을 두고 생각해봤을때 후자가 조금더 적합하다보니 Go / Django 서버는 한 묶음으로 관리하는 것이 명확했습니다. Docker 를 도입하면서 nginx container 가 proxy 역할을 하고 path를 보고 Go container / Django container 로 요청을 보내는 구성을 가지게 되었습니다.  글을 마치며   시작은 미약하였으나 끝은 창대하리라 하나의 API를 이전했음에도 불구하고 Allocation API 에 대해서는 약 1/3, 서버 Instance 비용은 1/2.5 수준으로 감소했습니다.   설명: 기존 4개의 Django 인스턴스의 CPU 사용률이 모두 13% 정도 감소, Go 인스턴스의 CPU 사용율은 17% 정도   17 / (13 * 4)  ≒ 1 / 3  충분히 만족할만한 성과가 나와서 그 뒤로 몇가지 API도 Go 로 옮겼고 새로 작성하는 API 는 Go 환경 안에서 직접 구현하는 중입니다. 처음에는 호출이 많은 하나의 API 를 다른 언어로 포팅하기 위해 시작한 작업이었는데 Container 기술을 도입하는 등 서버 Infra 까지 변경하면서 상당히 큰 작업이 뒤따르게 되었습니다. 하지만 이 작업을 하면서 많은 동료들의 도움과 조언이 있었고 결국 완성할수 있었습니다. 이렇게 실험적인 도전을 성공 할수 있는 환경에 여러분을 초대하고 싶습니다! Go언어에 대한 문의나 좋은 의견도 환영합니다.
조회수 768

[Buzzvil People] Roy Kim, Head of Finance

 Buzzvil People에서는 다양한 배경과 성격 그리고 생각을 지닌 버즈빌리언들을 한 분 한 분 소개하는 시간을 갖습니다. 어떻게 버즈빌에 최고의 동료들이 모여 최고의 팀을 만들어가고 있는 지 궁금하시다면, 색색깔 다양한 버즈빌리언들 한분 한분의 이야기가 궁금하시다면, Buzzvil People을 주목해주세요.1. 간단한 자기 소개 부탁드립니다. 안녕하세요. 버즈빌의 BM(Business Management)팀에서 Head of Finance Role을 맡고 있는 Roy  Kim (김현우)입니다. 버즈빌에 조인한 건 2016년 8월 29일로, 이제 1년 6개월정도 지났습니다. 저는 4대문 안쪽의 현-마이크로소프트 한국 지사 건물이 있는 곳의 산부인과에서 태어났습니다. 가끔씩 저에게 지방출신이 아니냐고 물으시는 분들이 계신데.. 조선시대였으면 사대부들만이 가능하다는 4대문 안쪽에서 태어난 진정한 성골 서울사람입니다 🙂 태어난 후부터 중간에 잠깐 1.5년을 제외하고는 서울에서 초-중-고등학교를 졸업했고, 2001년부터 2009년까지 약 8년간 미국에서 생활했습니다. 사실 처음에는 1년간 어학연수를 하고 군대를 갈 생각이었으나..어찌저찌 하다보니 대학을 졸업하고 2년간 업무 경험도 쌓을 수 있었네요. 대학에서는 Economic를 전공했기 때문에, 졸업 후 관련 업종을 찾는데 집중했고, 운이 좋게 외교통상부의 해외공관의 경제담당관으로 근무했습니다. 제가 있던곳은 샌프란시스코 총 영사관이 었는데요, 주요 업무는 실리콘밸리 및 샌프란시스코의 비즈니스 네트워크를 만들고 관리하는 업무, 주요 경제 동향 파악 및 리포트 작성, 우리 기업의 현지 진출 지원 등의 업무였습니다. 이후, 좀더 액티브한 업무를 하고 싶어 영사관을 나와 현지 게임회사에서 근무하면서 Local Publishing을 담당했습니다. 해당 업무는 한국에서 미국 진출을 원하는 게임을 가져와서, 현지화 하는 작업을 진행하는 업체로 2~3개의 게임을 실제로 미국에서 런칭하는 등의 경험도 해보았네요.  이후에는 사실 살~짝 권태기가 왔습니다. 졸업과 동시에 일을 시작하기는 했지만, 아직도 제가 무엇을 좋아하고 무엇을 하고싶은지 모르고 있는 건 아닌가라는 고민도 들었구요. 해서 머리도 식힐 겸 영어강사를 시작했고 이 역시 나름 재미있게 하긴했으나, 장기적인 관점에선 재무/회계 역량을 더 발전시키고자 다시 인더스트리로 돌아오게 되었습니다.  버즈빌 입사 바로전까지 일하던 지오시스는 이베이지마켓의 Founder인 구영배사장님이 글로벌 오픈마켓을 지향하면서 런칭한 회사로, 저도 2012년까지는 지마켓의 일원으로 일하다가 지오시스에서 본격적으로 재무시스템기획을 맡으면서 업무를 시작했습니다. 주로 회사의 재무/회계 전반적인 시스템을 구축하는 업무를 맡았고, 업무에 대한 성과 등을 인정받아 팀장으로 팀원들과 함께 회사의 주요 시스템을 기획했습니다. 이때 제가 만든 어드민내 기능만 30가지가 넘었고, Finance를 위한 별도의 어드민을 개발하여 SAP와 연동하는 업무도 진행했습니다. 해당 업무는 정확히 재무회계로 볼수는 없지만, 해당 업무의 지식이 매우 필수적인 업무였기 때문에, 저는 이곳에서 재무회계 관련 업무의 기초지식을 쌓을 수 있었을 뿐만아니라 한국 외 싱가폴, 미국, 일본, 중국, 말레이시아, 홍콩, 인도네시아 법인을 모두 시스템으로 연동하여 관리하는 Role도 맡게 되었습니다.  3.5년쯤 해당업무를 진행하다, 회사의 본격적인 IPO 준비에 앞장서고자 세무 및 회계의 업무로 보직을 전환했고 이 과정에서 1,000억원 증자 및 국세청 세무조사 응대 등의 업무를 진행했습니다. 돌아보면 저에게 엄청난 경험과 성장을 할 수 있게 해 준 회사였지만, 지지부진한 성장과 스스로의 내적 어려움이 있었기 때문에, 회사를 떠나게 되었습니다. 2. 어떻게 버즈빌에 오시게 되셨나요? 이전 직장을 그만두고 이직을 알아보던 중 헤드헌터분이 강하게 추천을 해 주셨습니다. 사실…이직이 확정된 & 면접을 보러다닌 다른 기업들에 비해서는 버즈빌은 저에게 상당히 미지의 존재였기 때문에, 사실 처음에는 전혀 고려대상은 아니었습니다.  그럼에도 불구하고 이곳에 오게 된 계기에는 주변분들의 추천이 있었습니다. 이름을 직접 말씀 드릴 수는 없지만, John의 지인과 버즈빌의 파트너사 및 협력사 분들이 회사에 대해서 발전 가능성이 높고 제가 기여할 부분도 많다고 말씀해 주셨습니다.  사실.. 이전의 회사에서 100명부터 650명이 되는 과정에서 5년이 넘게 회사의 기초 Finance System을 설계했었습니다. 가깝게는 판매자의 정산 및 결제부터 멀게는 회사내의 보상체계까지 다양한 부분의 시스템을 기획하면서, 제 스스로 주어졌지만 사용하지 못한 휴가가 49일이나 됐습니다. 이렇게 일이 많은 회사보다는 그냥 제게 주어진 Task에 집중하면서, 다른 여러가지 사업구상을 할 수 있는 회사를 찾고 있던터라, 처음에 버즈빌에서 최종합격 통보를 주셨을 때 일이 많을 것 같아서 거절을 했었습니다.  하지만, 이후 다시 주변 분들이 너랑 잘 맞는 회사라는 말씀을 거듭 주셨고, 매우 부끄럽게 다시 연락을 드려서 기회가 있는지 물었습니다. 상당히 아이러니 한데요, 합격시켜주니 안간다고하고..알았다고 하니, 다시 가겠다고..이와 관련해서 내부에서도 이야기가 있었던 것으로 알고 있습니다 (저 사람은 들어왔다, 금방 나갈 것 이라고) 결과적으로 전 아직도 이곳에 있고 이곳이 좋습니다. 물론, 다른 기회를 잡았으면 어떨까하는 생각을 안한 것은 전혀 아니나, 이정도면 매우 만족한다고 볼 수 있습니다 3. 버즈빌에서 어떤 업무를 담당하고 계신가요? 제가 담당하는 업무는 Accounting and Finance 전반적인 업무를 진행하고 있습니다. 물론 이 외에도 회사의 여러가지 정책을 정립하고 수립하는 업무도 담당하고 있습니다업무를 나누자면 크게 3가지로 나눌 수 있습니다 1) 재무회계업무 2)IR업무 3)기타정책업무. 물론 회사에 따라서는 1)재무회계업무도 1-1 재무 / 1-2 회계 / 1-3세무 로 나누지만, Buzzvil은 아직 인력이 충분하지 않아 동 업무를 모두 같이 처리하고 있습니다   우선 1) 재무회계업무를 보면, 주로 하는 일은 재무관리가 있는데요. 간단하게 말씀드리면 회사의 입/출금을 관리하는 업무입니다. 입금의 경우 회사가 발생시키는 매출에 대해서 매출이 적절하게 회수됐는지 확인을 합니다. 반대로 출금의 경우에는 회사가 지불하는 다양한 서비스 경비에 대해서 비용이 적절하게 승인됐는지, 지불금액은 합리적인지 판단 후 출금을 처리하는 업무를 말합니다. 회계의 경우에는 앞에말씀 드린 입/출금 업무가 제대로 처리됐는지 장부상에서 관리하는 것을 말합니다. 흔히 회계를 단순한 내역정리라고 보시는 분도 계신데요. 회계는 장부를 통해 회사의 살림살이가 제대로 운영되는지 확인하는 기능입니다. 아쉽게 제가 입사하기 이전의 Buzzvil의 회계는 외부기장을 통해 작성되고 있었기 때문에, 장부의 금액에 대해서 회사내에 정확히 파악하시는 분이 없었습니다. 해서, 처음에 이 부분에 대한 파악 및 확인이 시급하였고, 지금은 적어도 어떤 Account의 어떤 비용이 있는지는 파악하고, 관련 내용을 COO 및 CEO, 외부 투자자들에게도 공유 드리고 있습니다  두번째로는 IR업무입니다. 물론 아직 상장을 하지 않은 법인이기 때문에, 정확한 의미의 IR이라고 볼수는 없는데요. 제가 현재 담당하고 있는 IR은 주로 투자자 응대입니다. 저희 회사에 투자한 투자자분들께서 회사의 실적등에 대해서 궁금해 하시기 때문에, 주로 분기별로 응대를 하고 있습니다. 그리고 지난해 Slidejoy를 인수하면서 개인투자자 분들도 많이 추가 되셨기 때문에, 이 분들에게도 관련 자료를 전달 드리고 있습니다. 만약 회사가 Going public으로 간다면, 그때는 관련업무의 depth가 지금보다는 더 깊어질 것으로 보고 있습니다. 따라서 이를 대비하기 위한 IR 자료 준비 등의 업무도 올해부터 시작하려고 하고 있습니다  마지막으로 담당하는 업무는 기타정책업무 입니다. 아직 회사에는 비용에 대한 기안/승인/집행 등과 관련된 프로세스가 정립되지 않았습니다. 따라서 관련 업무를 보다 체계화 시키는 업무를 진행하고 있습니다. 비용관련 정책의 경우 단순하게 BM에서 집행하는 비용 외, 전사에서 발생하는 모든 비용을 대상으로 관련 정책을 수립하고 있습니다. 아울러, 회사가 Going public을 진행하고 있기 때문에 관련해서 사전에 미리 준비해야하는 여러가지 사항에 대해서 처리하고 있으며, 이 중에서 정책적으로 결정해야 하는 일이 있으면, 관련 정책의 수립도 진행하고 있습니다   4. 스타트업에서 혹은 광고업계에서 일하는 느낌이 어떠세요? 굉장히 새롭습니다. 스타트업에서 근무해본 경험은 있지만 광고는 처음인터라, 물론 저의 업무특성상 업계에 크게 구애받지 않는 업무이긴 합니다만, 항상 새로운 Industry에 대해서 배우는 것은 저에게 매우 즐거운 일이라 생각합니다.  사실 버즈빌은 광고라기 보다는 광고 및 컨텐츠를 통해서 모바일 잠금화면이라는 새로운 생태계를 구성하는 업체라고 생각합니다. 이는 단순하게 새로운 컨텐츠를 제작하여 배포하는 것도 아니고, 광고만을 수주하여 고객에게 전달하는 것과는 다르다고 생각합니다.  이러한 면에서 사실 이전 회사에서는 접하지 못한 새로운 수익의 창출 및 고객의 니즈를 충족시킬 수 있다는 부분은, 저 스스로에게도 다양한 부분을 시사했던 것 같습니다. 제 개인적으로는 버즈빌이 광고업계라는 업종을 한정시키기 보다는, 모바일을 통한 Life Changer로서의 다양한 Role을 수행해 나가길 희망하고 있습니다  5. 이것만큼은 버즈빌이 참 좋다! 어떤 게 있으실까요? 우선 버즈빌의 자유로운 분위가 저는 매우 좋습니다. 물론 입사초에는 규정되지 않은 문화가 매우 어지럽고 비효율적이라는 느낌을 받은 것도 사실입니다. 이는 버즈빌의 문화의 잘못이라기 보다는, 제가 있던 곳들이 어쩌면 정형화된 분위기에서 저의 일만 하면 되는 분위기 였기 때문에, 그러한 차이에서 오는 약간의 불편함 이었다고 생각합니다.  보통 회사의 경우 인간적인 관계의 부분도 중요하지만, 공적인 일을 하는 장소라는 인식을 많이 가지고 있습니다. 소통도 상대적으로 덜할 수 밖에 없죠. 그렇지만 버즈빌은 자유로운 문화를 통해 서로 이야기 하고, 불편한 점을 고쳐나가기에 자유로움이 소통으로 더 극대화 되는 좋은 기폭제가 아닌가 생각하게 합니다.   개인적인 경험으로 미루어보아 말씀드려보자면, Top – down 시스템이 익숙한 회사에서 버즈빌에 조인하셨다면, 약간 업무적응에 힘들 수 있습니다 . 왜냐면, 뭔가 exact한 지시를 하는 사람이 없고, 그 지시를 내릴 수 있는 Level의 분들 중 어떤 분들은 중간관리자로 오신 분들보다관련 경험이 없을 수도 있기 때문입니다.  반대로 본인이 주도적 성격을 가지고 업무를 이끌어가는 분이라면 제 생각에는 이곳만큼 좋은 곳이 없습니다. 버즈빌은 Self-leader를 장려하고, 이러한 role에 대한 서로 존경하는  곳 입니다. 따라서, 본인이 하고자 하는 업무가 명확하다면 CEO와의 대화를 통해 이러한 부분을 구체화하고 이끌어 나갈 수 있습니다.  저의 경우에는 버즈빌 입사와 동시에 Finance System을 구축하고 싶다는 목표가 있었습니다. 물론, 아직 관련 계획을 진행하고 있지는 못하지만, 그 System의 기반이 되는 여러가지 데이터의 정리/분석 등을 통해 한단계 한단계 나아가고 있습니다. 만약 제가 과거와 같이 큰 업체이 있었다면, 저의 의견보다는 윗선의 의견을 수렴하여 프로젝트를 진행하는 Role을 맡고 있었을 것 입니다 . 6. 개인적인 목표나 꿈이 있으신가요? 있다면, 버즈빌에서의 경험이 어떻게 도움이 된다고 생각하시나요? 버즈빌의 많은 분들처럼 저 역시 창업에 대한 꿈이 있습니다. 이 곳에서 아이템에 대해서 말씀 드리기 어려우나 ^^; 개인적으로는 이전부터 하고 싶었던 창업의 아이템이 있어서, 만약 Buzzvil을 퇴사한다면 관련 사업을 진행하고 싶습니다. 그리고 이 사업을 하면서 버즈빌에서 느낀 여러가지 감정 및 업무 경험이 매우 큰 도움이 될 것이라고 생각합니다.  어떻게 살고싶냐는 질문은 매우 철학적인데요. 개인적으로는 많은 고민과 테스트를 하면서 살고 싶습니다. 저는 이전부터 다양한 분야에 관심이 많았고, 그중에서 가장 관심이 많은 부분은 ‘왜 사람들은 저런 생각을 할까’ ‘왜 저런행동을 할까’ 였습니다. 이것은 단순한 심리에 대한 파악이 아니라, 그 사람의 심리를 관통하는 철학은 무엇이고, 그 철학은 어떻게 생성되었기 때문에 그 사람 안에 깊숙히 스며들어 있는가 등 입니다. 좀 지루한 이야기일지 모르겠지만, 이렇듯 사람은 어떠한 철학, 종교에 영향을 받았고, 그 가치가 그 사람의 언어 및 행동 패턴을 변화시켰다고 생각하기에,  그 변화가 지금 그 사람의 문제에 대한 접근방식 및 결론 내는 부분에도 작용한다고 생각하고 있습니다.  따라서, 저는 앞으로 어떻게 살고 싶냐는 질문에, 지금처럼 이러한 것들에 대해서 다양한 고민을 하고, 저의 가설이 맞는지 증명하는 방향으로 인생을 살아갈 듯 합니다. 물론 이러한 고민이 저에게 어떠한 가치(예: 돈)를 줄지는 솔직히 모르겠습니다. 하지만, 나름 저만의 재미있는 세계를 가지고 인생을 살 수 있게 해줄수 있을것 같습니다. 그리고 또한, 행복한 가정을 꾸리고 가족과 함께 평안한 여생을 보내는 것도 제가 꿈꾸는 미래 중 하나 입니다  
조회수 557

직원 근무일정 스케줄링 과정과 시프티

직원 스케줄링 프로세스의 기본은 팀 또는 지점의 각 직원의 역할을 알고 일별 근무일정 패턴을 파악하는 것으로 시작됩니다. 팀이 제 능력을 발휘하려면 주어진 시간에 각 역할별로 특정 인력이 필요합니다. 바텐더를 할 수있는 사람이 휴가를 가거나 회사를 떠나면, 그 자리를 채울 수 있는 사람을 찾아야 합니다. 팀과 사업에 대해 알지 못한다면 각 직원을 올바른 직무에 배치하는 것이 불가능할 수 밖에 없습니다.근무일정을 잘 계획하기 위해서는 다음과 같은 4 가지 필수 단계가 필요합니다.1. 근무 가능 시간 (Availability) 수집하기스케줄을 잡기 전에 각 직원의 근무가능일과 시간대를 알아야 직원들이 일할 수 없는 근무일정을 짜지 않을 수 있습니다. 보편적인 절차 중 하나는 각 직원의 재임기간동안 근무 가능 시간대를 수집 한 다음 해당 월의 휴무 (유급 및 무급) 요청을 수집하는 것입니다. 우리는 지금까지 다음과 같은 두 가지 방법으로 각 직원의 근무 가능 시간을 수집하는 많은 관리자들을 발견하였습니다.첫 번째는 풀타임 직원이 변동되는 휴무일을 가지는 경우입니다. 예를 들어, 각 직원은 한달에 8일의 무급 휴무일을 가지지만 쉬는 날을 정하는 것은 각자의 몫인 경우입니다. 직원들은 자신들의 쉬는 날, 그리고 유급 휴가(연차 등)를 언제 쓸지를 서로 합의한 후에 승인을 위해 관리자에게 제출합니다. 직원들은 일할 날, 쉴 날을 자유롭게 선택할 수 있었고 이는 매장에 일할 직원이 없는 날이 없도록만 하면 되었습니다.둘 째로 파트 타임 직원이 많을 때, 보통 관리자가 근무 일정을 계획/조정할 수 있는 권한이 더 많았습니다. 이 경우 관리자는 모든 직원의 근무 가능 시간을 알아야 합니다.시프티는 근무 가능 시간 (availabilities) 기능과 직원의 휴무 신청 및 관리할 수 있는 기능을 2018 년에 개발할 계획입니다. 이를 통해 관리자가 근무일정 캘린더와 직원들의 근무 가능 시간 엑셀 사이에서 왔다 갔다 참고하며 스케줄하는 시간을 절약하고자 합니다. 시프티에서 발송하는 업데이트 소식 이메일을 자주 확인해주세요.2. 스케줄하기모든 직원의 한 달 치 근무 가능 시간을 수집한 후에는 시프티 스케줄러를 이용하여 다음 기간에 대한 근무표를 계획할 수 있습니다. 현재, 시프티는 다수 근무일정을 일괄적으로 스케줄하는 방법이 두 가지 있습니다. 이 두 멀티스케줄 기능을 사용하기에 앞서 근무일정 템플릿(들)을 생성하기 바랍니다.예) 근무일정 템플릿템플릿명지점직무근무 시간오픈강남역점바리스타6:30 am - 1:00 pm미들강남역점바리스타12:45 am - 9:00 pm마감강남역점바리스타7:30 pm - 11:00 pm............위 예시처럼, 직무별 근무일정 템플릿들을 모두 생성하였다면, 다음 두 가지 방법의 멀티스케줄을 이용하여 일정을 계획해보세요.A. 다수 템플릿 멀티스케줄직원이 여러 가지 근무일정을 변칙적인 날에 근무할 일정들을 일괄적으로 생성합니다. 한 직원을 선택한 다음 각 템플릿을 선택하여 달력의 근무할 날들을 선택합니다.  B. 다수 직원 멀티스케줄일정한 근무일정을 가진 다수 직원들의 일정을 일괄적으로 짜는 기능입니다. 다수 직원을 선택하고 각 직원에 대한 템플릿을 선택한 다음 근무할 날들을 선택합니다.“시프티 스케줄러가 없다면 많은 관리자들은 근무표 엑셀을 붙잡고 컴퓨터 앞에 종일 앉아있어야 할 지도 모릅니다. 시프티는 당신의 고통을 충분히 느낍니다. 이제 시프티를 시작해보세요.” 3. 직원에게 공유하기다음 달 일정이 확정되면 근무표를 공유하기 위해 어떤 채널을 이용하고 있나요? 스크린샷을 찍어 이메일로 보내고 있나요? 문자 또는 채팅방에서 보내나요? 직원들이 실제로 그 근무표를 숙지했는지는 어떻게 알 수 있을까요? 시프티를 통해 자동으로 직원에게 근무일정을 공유할 수 있으며 변경사항은 실시간으로 반영됩니다. 당신의 인생에서 더이상의 근무표 스크린샷은 없습니다.4. 플랜 B직원을 관리 할 때 항상 예외와 우발적 변동이 있습니다. 때로는 인력 부족으로 레스토랑 운영이 재앙에 빠질 수도 있습니다. 직원의 근무 가능 시간을 수집하여 우발적인 상황에 대비하세요.직원 스케줄링을 위한 절차 수립은 비즈니스 운영에 있어 필수입니다. 오늘날도 이러한 프로세스가 없어 관리자와 심지어 사장까지도 어려움을 겪는 경우가 많습니다. 직원들의 근무표를 계획하고 알맞은 인원을 할당하는 것은 그렇게 힘든 일이 아니어야 합니다. 위의 절차를 따라해 보고 차이점을 느껴 보시기 바랍니다!시프티 출퇴근기록기로 직원들의 출퇴근을 기록하는 것도 잊지 마세요.#시프티 #고객가치 #핵심가치 #기업소개 #서비스소개
조회수 702

실리콘밸리의 ‘새 숨은 병기', 디자이너의 창업

이제는 국내에서도 많이 알려진 실리콘밸리 회사 에어비앤비(Airbnb)와 핀터레스트(Pinterest)에는 공통점이 하나 있다. 바로 창업자가 디자이너 출신이라는 것. 에어비앤비는 RISD에서 산업디자인을 전공한 브라이언 체스키(Brian Chesky)가 2008년에 시작했다. 핀터레스트의 창업자 중 한 명인 에반 샤프(Evan Sharp)는 2010년 핀터레스트 창업 전, 콜럼비아 대학에서 건축을 전공하고 페이스북에서 제품 디자이너로 일했다. 이 밖에도 실리콘밸리의 많은 B2C(Business to Consumer) 회사에서 디자이너 출신의 창업 멤버들을 발견하는 건 어려운 일이 아니다. 국내에서는 배달의 민족을 서비스하는 우아한 형제들의 김봉진 대표가 가장 대표적인 디자이너 출신의 창업자이다. 필자 역시 2011년 스탠포드 대학원에서 제품 디자인을 공부하던 중 두번째 창업 회사인 스타일세즈(StyleSays)를 창업했었다.실리콘밸리에서 디자이너 출신 창업자들이 본격적으로 기지개를 켜기 시작한 건 2010년 무렵이다. 실리콘밸리의 새로운 무기, 디자이너의 창업에는 과연 어떤 비결이 숨어 있을까? 디자이너 출신의 창업가로서 다음과 같이 2가지 관점으로 해석해 보았다. 첫째, 디자이너는 사람들의 니즈(needs)를 발견하고 이를 위한 해결책을 고안해내는 것에 익숙한 사람들이다. 본래 산업 디자인이란 단순히 무언가를 시각적으로 아름답게 만드는 것이 아니라 사용자(user)를 위한 제품과 서비스를 개발하는 작업이다. 디자이너의 창업 역시 같은 선상에서 해석할 수 있다. 스마트폰이 대중화되면서 인터넷 접속이 일상화 되었고, 이는 다양한 B2C 서비스의 시작점이 되었다. 사용자들이 새로운 환경에 노출되면서 점점 더 많은 니즈를 갖게 되었고, 이러한 사용자의 니즈를 발견하고 새로운 해결책을 고안하는데 있어서 디자이너들의 능력이 십분 발휘되고 있는 것이다.둘째, 디자이너는 기획자, 개발자, 마케터 등 다양한 직군의 사람들과 의사소통하는 것에 익숙한 사람들이다. 창의적 사고는 다양한 분야의 사람들이 모여 만드는 고도화된 협업에 의해 이루어 진다. 문제는 서로 다른 직군의 사람들이 사용하는 언어가 마치 남자와 여자의 사고 방식과 언어가 다른 것 만큼이나 미묘하면서도 확연하게 다르다는 점이다. 이 때 디자이너들의 커뮤니케이션 능력이 촉매제로 작용하게 된다. 디자인 과정 자체가 다양한 사람들의 의견을 수렴해 무에서 유를 창조해 나가는 것이다 보니, 다수의 디자인 프로젝트를 경험한 디자이너들은 훌륭한 커뮤니케이터(communicator)인 경우가 많다.몇년 전부터 국내에서 프로그래밍(programming) 교육이 열풍이다. 초등학교 교과 과정에도 일부 포함되고 있다고 들었다. 프로그래밍 역시 단순히 코드를 짜는 것을 배우는 것이 아니라 논리적 사고 방식을 배우는 것이기 때문에 바람직한 변화의 방향이다. 디자인 교육 역시 마찬가지 영역에 포함되어야 한다고 믿는다. 디자인이 단순히 무언가를 보기 좋게 꾸미는 것이 아니라, 사람 중심적(human-centered)인 사고 방식과 다양한 커뮤니케이션 기술이 근간이 되는 복합적 사고 방식이라는 것을 이해해야 한다.
조회수 1053

스타트업 준비 check point!

지난주 금요일, 고려대학교 내 동아리의 초대를 받아서 session에 참석하게 되었다. 그 날의 주제는, 얼마 남지 않은 공모전을 준비하면서 처음으로 결과를 발표하고 서로 feedback을  주고받는 자리였다. 향기(fragrance) industry에서 스타트업인 paffem(파펨) 을 설립 및 운영하고 있고, 전략 컨설팅 경험이 있는 나를 초대해주어,  이런저런 피드백을 해주고 오게 되었는데...그 자리에서 생각난 것들이 공모전뿐만 아니라..  스타트업을  준비하는 데 있어 도움이 될 수 도 있다는 생각에 기록으로 남겨 보기로 하였다.1. 그 회사 입장에서 생각해 보기공모전을 개최하는 회사는 그 공모전을 왜 하게  되었을까?라는 생각을 해보고 아이디어를 만들어보는 학생들이 얼마나 될까?   조금만 거꾸로 생각해 본다면.. 그 회사가 그 공모전을 개최하는 이유를 생각해 볼 수 있는데, 그렇게 함으로써 그 회사가 듣고 싶은 이야기가 무엇인지를 찾을 수 있다는 생각에서이다. 참신한 아이디어를 들어보고 싶은 것인지? 아이면 실행해볼 만한 사업인 것인지? 또는 본인들의 브랜드를 대학생들에게 좀 더  각인시키고 싶은 것인지? 사실 세 가지 모두를 듣기를 원할 수도 있고,그런 고민들을 해보게 되면, 준비하는 과정에서 보다 목적이 분명한 아이디어들을 만들어 볼 수 있을 것이라는 생각이다. 이번 공모전을 개최한 H사의 경우는.. 130억 수준의 매출액을 발생시키고 있지만, 계속해서 이익률이 낮아지고 있는 상황에서, 실제적으로 조금 더 profitable 한 사업을 찾고 있는 중이라는 생각이고,  그중에 조금은 더 손에 잡히는 수익을 만들어줄 아이디어에 보다 좋은 평가를 할 가능성이 높다는 생각이다.2. 다른 큰 기업이 왜 아직까지 이것을 안 했을까?를 고민하지 말라...내가 다소 당황했던 것은, 그 학생들의 반응 중..그 아이디어가 그렇게 좋고 혁신적인 것이라면, 왜 기존의 기업들이 아직까지 시도하지 않았을 까요?라는 질문을 발표자에게 하고 있었다는 것이다. 그러한 질문은 아이디어에 대한 자신감의 하락을 야기할  수밖에 없는데.. 그 이유를 알기가 쉽지 않기 때문이다.  기업을 경험해본 사람이라면, 회사나 사람이나 얼마나 변화를 하기를 꺼려하는지 알 수 있을 것이고, 기업들이 생각보다 그리 새로운 것에 대해서 열심히 움직이지  않는다는 것을 알 것이다.물론 기업들이 이미 검토를 한 사업일 수도 있고, 아니면 진행하다가 여러 가지 이유로 Stop이 되었을 가능성도 있다. 하지만 경험상, 대부분의 기업들은 그러한 혁신적인 아이디어들을 할 생각을 못했기 때문에 안 하고 있다는 것이 현실이다. 학생들이 세상이 그리 합리적이지만은 않다 점과 그렇게 빠른 변화들이 발생하지도 않는 것을 알고 과감하게 생각해봤으면 좋겠다는 생각이 들었다.3. 빈칸 채우기가 아닌 고민의 결과를..최종 발표자료는 파워포인트로 30장 정도를 제출하는 것인데, 학생들이 일하는 방식은 마치 30장의 슬라이드에 하나씩 제목을 달아놓고 채워가는 듯한 인상을 강하게 받았다. 예를 들면, 이번 slide에는 마케팅 4P 중 product에 대해서 넣고, 다음 장에는 place, promotion,  price에 대해서  넣자!라는 것을 미리 고민해 두고 채워가는 것이다.물론 이렇게 접근하는 게 나쁜 것은 아니다. MECE 하게 생각을 정리할 수 있기 때문에 도움은 될 수 있겠으나.. 스스로의 고민과 아이디어를 그 범주 안에 가둬두는 부작용 또한 발생할 수 있다.어떤 고민을 더해서 아이디어와 생각을  발전시켜나갈까?라는 고민이 아니라, 이 빈칸을 어떻게 채워나가야 할지에 대한 고민을 하고 있었다. 생각의 범위를 스스로 확장시키지 못하도록 울타리를 치고 준비를 하는 모습이었다. 빈칸 채우기가 아니라.. 어떤 고민을 해야 할지를 찾아내고 그것을 발전시키는 곳에 시간을 쓰자.4. 누구나 할 수 있는 이야기는 빼자누구나 할 수 있는 이야기에 그 짧은 발표 시간, 그리고 준비하는 시간을 쓰고 있었다. "우리 제품은 20대가 타깃이기 때문에 SNS 중 페이스북과 인스타그램 그리고 네이버 메인에 광고를 할  예정입니다"라는 말을 대부분의 팀이 하고 있었는데.. (아마도 3번의 영향이 클 듯)  흠... 그건 누구나 할 수 있는 이야기 아닌가? 차라리  그것보다는 이 제품을 더 사람들에게 잘 설명하고 appeal 할 수 있는 메시지를 고민해야 하는 것 이 아닌가? 이러한 제품을 처음 보는 사람들에게 어떤 key word로 설명하고 그들이 호기심을 갖게 만들고, 그리고 제품에 대해서 설명할 기회를 얻고... 이런 것들에 대한 고민이 마무리된 후에 채널에 대한 이야기를 해야 귀에 들어오는 것이다.진지하게 고민하지 않고, 누구나 할 수 있는 이야기라면 차라리 빼는 것은 어떨까?5. 아이디어는 참신하나 실행에 대한 제안은 전무 (몰라도 너무 모른다)그날 저녁에는 3 팀이 발표를 진행하였는데, 아이디어들이 제법 참신하다는 생각이 들었다. 물론 아이디어가 좋은 것이 실제 실행이  마무리되기까지는 수차례의 조정과 변경이 필요하지만, 아무튼 아이디어로만 본다면 흥미로운 것들이 많았다.하지만, 실행에 대한 이야기들에서는 너무나도 무지를 드러내었는데.. 사업에 대한 지식이 없을  수밖에 없는 것이 너무나도 당연하지만, 그래도 몰라도 너무 모른다는 생각이 들었다.책상에 앉아서 파워포인트만 켜두고 고민을 했기 때문이라는 생각이다. 실제로 한번 field에 나가서 보는 게 얼마나 중요한지 아직 모른다. 직접 제조 공장을 방문하는 것이 어렵다면(실제로도 어렵다), 유통 채널에 가서라도  한 번씩 실제와 마주하는 것이 feasibility의 레벨을 엄청나게 올려줄 수 있다.6. 나가서 만나봐라! 서베이 100명이 중요한 게 아님본인들의 주장을 back up 하기 위해 서베이를 많이 하고 있었다. 본인들이 아이디어를 지원하고, 또한 합리화의 back up으로 좋은 방법은 될 수 있다. 하지만, 서베이의 특성상 대부분 긍정적인 대답을 줄  수밖에 없고, 또한 조사하는 입장에서는 그것들을 긍정적으로 해석할  수밖에 없다.그리고 서베이 100명의 결과가 모두 긍정적인 대답을 했다고 해서,  그것이 사업에서 성공하리라는 보장이 되는 것도 아니다. 차라리 나가서 잠재 고객을 관찰해보면 어떨까?엄청나게 혁신적인 사업 아이템들이 아니라면, 이미 소비자는 제품/서비스 형태가 아니라도 이미 유사한 방법을 통해 활용하는 경우를 볼 수 있다. 파펨의 경우도.. 제법 많은 수의 user들이 본인들이 구매한 향수를 소분해서 쓴다는 점에서 아이디어가 시작되었다. 나가서 관찰을 해본다면 단순히 서베이 100명의 결과보다도 좋은 insight를 얻어볼 수 있을 것이다. 물론 쉽지 않을 수 있겠지만.. ^^;;7. 가정이 가정을 낳기 시작하면 좋은 소리로 끝날  수밖에 없다.발표의 flow를 따라가다 보면, 중요한 논리적인 point에서 가정이 하나 나오고.. 그 뒤에  또다시 다른 가정이 그 위에 세워진다. 그러다 보면 당연히 이러한 제품/서비스는 환상적일  수밖에 없다. 즉 back up 없이 상상의 나래를 펼치고 펼쳐 좋은 아이디어라고 주장하기 시작하는 것이다.이런 건 냉장고에 코끼리를 넣는 방법이 1) 냉장고 문을 열고, 2) 코끼리를 넣고, 3) 문을  닫으세요..라고 말하는 것과 차이가 없다. 차라리 엄청나게 큰 냉장고를 가져와서  5톤짜리 코끼리가 들어가도록 하겠다는 말이 더 현실적이다.  한 단계 한 단계를 차근차근 검증해나가는 방법들을 찾아가는 고민을 하고 실행을 하자.  8. 파워포인트는 파워도 없고 포인트도 없다! 먼저 글로 써보자!발표를 위해서 모두 파워포인트를 사용하고 있었다. 아직은 열흘 정도의 시간이 있었는데.. 고민을 해서 생각을 발전시켜 나가는 것이 아니라, 파워포인트를 beautify 하는데 엄청나게 시간을 쓰고 있었다.언젠가 강연에서 발표자 분이.. 준비하신 파워포인트 자료를 켜지도 않고는 강의를 진행하시며..파워포인트는 파워도 없고 포인트도 없다!!라는 멘트를 하신 것이 기억이 났다. 발표 준비하던 친구들도 A4 용지를 꾸미기 위해 사진을 넣고 빼고 또 글자 위치를 바꾸고, 그래프를 그리고..  흠.. 그런 것들은 본질이 아니다.그 시간에 주제에 대한 고민을 좀 더 하고, 파워포인트는 제출 이틀 전에 만들어도 충분하다. 생각이 깔끔하게 정리되지 않은 상황에서는 파워포인트를 아예 켜지 말고, bullet point를 통해 계속해서 전달해야 할 message를 정리하는 것이 더 도움이 된다.  workflowy.com와 같은 서비스가 더 파워풀한 도구가 될 것이다.9. 실제로 한번 팔아보는 것을 가정해보자!좋은 상품/서비스를 이미 다 만들었다고 가정하고, 그것을 주변 타깃 고객에게 판매한다고 생각하고 고민을 해보는 것도 좋은 방법이라는 생각이다. 우리가 제시할 가격이 과연 고객이 수용할 만한 수준인 것인지? 우리가 설명할 때 사용하는 key word가 정말 고객들이 관심을 가져 볼 만한 것인지? 등등에 대해서 모르는 사람에게 판매해보는 연습을 해본다면  그곳에서도 많은 보완점들을 찾을 수 있을 것으로 생각된다.과연 내가 기획한 서비스를 사겠다는 사람이 있는지? 물론 10명에게 시도했을 때, 10명 모두 사겠다고 할 가능성이 높지는 않다.. 고객들의 다양한 배경, 니즈를 하나의 제품이 모두 만족시켜 주기는 쉽지 않기 때문이다. 단 5명 정도가 구매하겠다고 한다면 충분히 긍정적인 sign이라는 생각이고, 만약 한 명도 사지 않겠다고 한다면.. 계획을 처음부터 다시 고민해 봐야 하지 않을까?10. 발표 준비는 생각보다 쉽지 않다.발표를 듣는 사람들(심사를 하는)의 입장에서 생각해보자. 당일날 한 팀이 15분씩만  발표한다고 해도 엄청나게 지루한 하루가 될 것이다. 그럼 그 사이에서 어떻게  그분들의 관심을 얻을 수 있을지 고민해보는 것도 중요하다. 재미있는 아이디어가 있으면, 서두부터 그  아이디어부터 빵! 터트려 본다면 관심도를 쭉 높이는 방법도 좋을  듯하고,  혹은  하나하나 조곤 조곤 논리적인 설명이 필요하다면, 다른 전달방법.. 예를 들면 동영상을 사용할 수 도 있겠고.파펨이 지난 '15년 11월 11일 LOTTE Startupday에서 발표를 할 때 고민했던 것은, 당일 10개 회사가 발표를 하는 중에 어떻게 하면 조금 더 제품에 대한 설명을 더  잘할 수 있고, 관심을 가지게 할 수 있을까?  를 고민하다가..  파펨의 핵심은  "향"이고 그것을 반드시 체험하게  해주자!!라는 결론을 내렸다. 그래서 참석자들이 발표장(롯데시네마)에 입장하기 몇 시간 전, 모든 좌석의 책상 아래에 향수를 Spray 한 시향 지를 밀봉하여 부착해 두었고, 발표 중에 그것을 참석자 전원이 시향 해볼 수 있도록 하였다.이러한 시도들이 좀 더 발표자의 발표에 집중력을 더해줄 수 있는 요소들이 될 것이다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트
조회수 931

160310_페이스북 포스팅 복기

목적페이스북을 "오래된 여자친구처럼 대한다"라는 충격적인 피드백을 받았다(페이스북 사랑해). 다시 예전처럼 스위처 페이스북 페이지를 관계를 좋게 하기 위해(페이지 활성화하기 위해) "내가 무엇을 잘못하는지", "앞으로는 어떻게 해야 하는지" 등을 파악하려고 한다. 나아가 이를 원칙을 만들어 앞으로 함께 할 마케터가 배움에 있어 조금이나마 도움이 되면 좋겠다.상황 설명3월 28일 스위처 발매 한다는 내용을 포스팅한 상황나는 3월 28일 정식 판매를 앞두고 매주 2회씩 포스팅을 약속했고, 약속을 지키기 위해 1주 첫 번째 포스팅할 콘텐츠를 기획/제작하려고 했다.  결과포스팅 된 컨텐츠(포스팅 URL : https://www.facebook.com/switcher.io/posts/923636374421388)그 결과물로 위 사진의 콘텐츠를 포스팅하였다. 다음 포스팅 때는 더 효율적이고 효과적인 콘텐츠 생산을 위해 위 콘텐츠 작성 과정을 돌이켜보려 한다.단계 1. 독자 파악독자 파악 단계에서 다음과 같은 질문을 받았다.1. 현재 스위처 페이지 문맥상 어떤 포스팅부터 올려야 하는가?2. Audience는 누구인가?3. Audience의 TPO는 어떠한가?4. 콘텐츠의 목표(결괏값)는 무엇인가?5. 콘텐츠의 목표를 이루기 위해 설계는 타당한가?이에 나는 다음과 같은 답을 냈다.1. 스위처 외관2. 지난번 연락을 보냈던 구매 희망자 + 페이스북 포스팅을 보고 댓글을 남겨준 사람들.3. T : 포스팅 후 개별 연락받고 핸드폰을 확인한 순간.(20:00 이후)P : 메시지(문자/카톡) 받아 보고 링크를 눌러 열린 사이트O : 자신의 할 일을 마치고 숨을 고르는 상황.4. 포스팅 좋아요/댓글/도달 범위5. 네 과거 비슷한 내용의 콘텐츠를 작성했던 방식과 유사하게 설계하였습니다.여기서 문제는 구체적으로 Audience와 그들의 TPO를 말하지 못했다는 점이다. 현재 페이스북 페이지를 '좋아요' 누른 사람은 4000명 정도가 된다. 무의식 중에 이들"도" 위 콘텐츠의 독자(Audience)라고 생각했던 것 같다. 그래서 TPO가 저렇게 엉망진창 (그냥 일반 직장인 정도?)로 나온 것 같다.작살같이 날카로운 타깃팅이 안되니깐 정확히 뭘 말해줘야 할지도 모르니깐 기획단계에서 더 우왕좌왕했던 것 같다. 이 문제를 해결하기 위해 난 2가지 행동을 하였다.a. 페이스북 지난 포스팅 '좋아요' 눌러준 사람 파악지난 포스팅은 누가누가 좋아하셨나독자는 이미 정해져 있습니다. 제가 할 일은 이분들이 누구인지 확인하고 어떤 내용을 궁금해하실지 생각하고 글을 쓰는 것이겠지?한분 한분 살펴보니 대부분 스위처를 기존부터 알고 계셨던 분이셨다. 그렇다면 기존 스위처와 비교했을 때 개선된 부분을 보여주면 좋지 않을까? 생각했다. (우린 고객의 목소리를 중요시하니깐.)b. 고객 문의 파악하기고객 문의그래서 그동안 고객이 겪었던 문제를 다시 읽어보았다. 많은 문제 중 빈도수가 가장 높은 5가지를 선정하여 고객 의견이 반영된 모습을 보여주면 좋을 것 같았다.1. 1구 스위처 -> 2구 스위처2. 전원 on/off 버튼 추가  3. 새로운 부착방식4. 스위처 두께가 얇아짐5. 충전 단자 개선위 5가지 주제를 어떤 식으로 표현하면 좋을까? 생각을 하여 미디엄이 아닌 '카드 뉴스' 형식을 사용하는 것이 좋다고 생각하여 다음과 같은 초안을 준비해보았다.단계 2. 콘텐츠 기획하기손으로 그린 컨텐츠 초안5가지 주제를 포함한 콘텐츠를 만들기 위해 어떤 내용을 만들어야 할 요소를 그려보았다."어떤 내용을 담을 것인가?"에 대한 질문에는 타당한 기획이었지만 "어떻게 표현할 것인가?"에 대한 질문에는 타당하지 못했다.카드 뉴스는 이미지 내에 텍스트를 넣기 때문에 사진의 구도가 중요할 수 있다. 가령 1번 이미지에선 스위처가 가운데에 위치했고 2번 이미지에는 오른쪽, 3번 이미지에선 왼쪽에 위치하여 모든 이미지마다 텍스트 위치가 다 달라져 불필요한 편집이 필요하다. 이로 불필요한 작업시간이 추가되었기 때문이다.다음 포스팅 기획에는 어떤 방식으로 포스팅을 해야 하는가? 질문했을 때, 방식만 생각하는 것이 아니라 선정된 방식을 또 어떻게 표현할 것인가(말이 모호하군) 역시 생각해 보아야 한다고 생각했다.단계 3. 촬영촬영에서의 문제는 혼자 세팅&모델&촬영을 한다는 것이 어려웠다. 그리고 더 나은 사진을 원하다 보니 시간적인 배분에 문제가 있었던 것 같다.앞으로는 촬영 전 도움이 필요한 장면은 팀원에게 미리 양해를 구하고 도움을 요청하고한 컸다(이미지의 경우) 5분의 촬영 시간을 넘기지 않도록 해야겠다. (영상은 촬영하지 않아 모르겠군.)단계 4. 콘텐츠 제작http://tyle.io 라는 좋은 카드 뉴스 제작 사이트가 있다. 근데 글씨 크기 변경이나 이미지가 보이는 방식에는 아직 불편함이 있어, PPT로 제작하는 것이 더 나은 것 같다. '타일'에서 좋은 Form을 확인한 후 PPT에 해당 Form을 미리 제작해두고 이미지에 덮어 씌우는 방식으로 만들면 더 좋을 것 같다.단계 5. 포스팅 하기저걸 왜 못봤지.."publish 버튼"을 누르기 전에 3분간 바람을 쐬고 와서 다시 봐야 할 것 같다.2.8cm.. 왜 못 봤을까.. 왜..틀린 그림 찾기 하듯 Fresh 한 머리로 콘텐츠를 봐야 할 것 같다..단계 6. 결과 분석지난 주 2건의 포스팅 결과값 비교지난주 포스팅한 2개의 포스팅 결괏값을 비교해보았다.LPR은 그냥 만든 용어에요.. 헤헿..제품 디자인 콘텐츠를 올릴 때 '좋아요'를 100개 넘게 받는 것이 목표였는데, 91개밖에 받지 못했다."어떤 콘텐츠가 공유될까?", "콘텐츠의 어떤 요소가 공유를 자극할까?"라는 남규의 질문에 아직 답을 하진 못하겠다. 하지만 '공유'전에 '댓글'을 많이 달 수 있는 콘텐츠가 더 높은 도달률과 많은 좋아요를 달성한다는 것은 알고 있다. (이건 나중에 얘기하는 걸로.)그래서 다음 포스팅에는 '댓글'이 많이 달릴 수 있는 요소를 고민하고 추가해야겠다.-끝-#스위쳐 #Switcher #SNS마케팅 #SNS마케터 #마케터 #마케팅 #페이스북 #페이스북마케팅 #경험공유 #조언 #꿀팁 #고생담
조회수 1333

트래킹 툴의 앱 설치 측정 방법 (Install Tracking Method)

앱 마케팅 분석의 시작대부분의 마케팅이 디지털화된 이유는 다양하겠지만, 높은 수준의 마케팅 성과 분석이 가능하다는 점도 중요하게 작용했습니다. ‘디지털 마케팅을 잘한다’라는 말은 사실상 ‘숫자로 증명할 수 있다’는 의미로 이해되는 것이 요즘입니다. 첨단의 타겟팅 기술이 적용되는 앱 마케팅은 더욱 숫자에 민감한 영역입니다.앱 마케팅에는 ‘앱 설치’라는 허들이 있습니다. 앱 설치수를 늘리기 위한 TV 커머셜은 이젠 정말 흔한 일상이고, 앱 전용 쿠폰, 전용 상품, 캐시백 등으로 마진을 포기하는 투자도 감행됩니다. 그만큼 넘기 어려운 허들이라는 방증입니다. 앱 설치수 증가를 위해 많은 비용을 들였으니 당연히 정확하게 측정해야 하겠지요.그래서 앱 설치 숫자 파악에서부터 앱 마케팅 성과에 대한 분석이 시작된다고 봐야 합니다. 앱 설치 숫자를 어떻게 정확하게 파악할 수 있는지 WISETRACKER의 측정 방식을 설명하면서 이해를 도와드리려 합니다.앱 설치수(INSTALLS) 분석 방법1. 단말기 고유 식별자 확인Android 단말기는 ADID(Advertising ID), iOS 단말기는 IDFA(Identifier for Advertisers)라 불리는 고유 식별자가 있습니다. 이 식별자를 활용해 특정 식별자를 가진 단말기가 앱을 다운로드했는지 그리고 앱을 실행했는지 확인하는 것이 단말기 고유 식별자 확인법입니다.추적 URL 적용: WISETRACKER에서 생성한 추적 URL을 앱 설치 링크에 적용합니다. 그래서 사용자가 링크가 적용된 광고를 클릭하면 분석 프로세스가 시작됩니다.고유 식별자 전달: 사용자가 광고를 클릭하면 분석에 필요한 몇가지 정보가 WISETRACKER로 전송되는데 고유 식별자도 그중 하나입니다. 이 정보를 바탕으로 WISETRACKER는 특정 식별자를 가진 사용자가 언제, 어떤 채널을 통해 광고를 클릭했는지 확인하게 됩니다.앱 설치: 광고를 클릭한 사용자는 앱 마켓으로 이동해 앱을 설치합니다.고유 식별자 매칭: 사용자가 앱을 실행하면 다시 고유 식별자 정보가 WISETRACKER로 전송됩니다. WISETRACKER는 2)단계에서 확보한 식별자와 4)단계에서 전송된 식별자를 매칭하여, 식별자가 일치할 경우 1건의 앱 설치가 발행한 것으로 리포트합니다.이 방식은 고유값을 이용해 분석 대상을 확실하게 식별할 수 있기 때문에 측정 정확도가 높으며, 이론적으로 모든 단말기에 적용할 수 있기 때문에 측정 범위도 넓다는 장점이 있습니다. 그래서 WISETRACKER는 고유 식별자 확인법을 최우선순위로 활용하고 있습니다.하지만 사용자가 식별자 사용을 거부하거나(Opt Out), 식별자를 바꾸게 되면(Reset) 분석 정확도가 영향을 받는다는 단점이 있습니다. 식별자 사용을 거부할 경우 WISETRACKER는 다른 키값을 기준으로 앱 설치를 측정하며, 식별자를 바꾸는 경우엔 광고가 아닌 자연유입(Organic)된 설치로 측정합니다. 그러나 옵트 아웃과 리셋이 일상적으로 발생하지는 않으니 큰 문제는 되지 않습니다.첨언하자면 식별자만을 활용한 마케팅은 개인정보 관련한 이슈에서 자유롭습니다. 개인을 식별할 수 있는 정보는 포함하지 않으면서 마케팅 목적으로 활용할 수 있는 식별값이 필요했기 때문에 만들어진 것이 ADID나 IDFA입니다. 실제 이런 식별자는 어떠한 개인정보와도 연관성이 없는 무의미한 문자열의 조합으로 이루어져 있습니다.2.  GOOGLE PLAY INSTALL REFERRER구글 플레이를 경유해 앱을 설치할 때 활용하는 방법으로 추적 URL에 포함된 리퍼러(Referrer)를 기준으로 앱 설치를 측정하게 됩니다.추적 URL 적용: 리퍼러 파라미터(&referrer=)를 조합한 추적URL을 앱 설치 링크에 적용합니다. 사용자가 링크가 적용된 광고를 클릭하면 분석이 시작됩니다.리퍼러 전달: 사용자가 광고를 클릭했을 리퍼러 값이 WISETRACKER로 전송됩니다. 이제 WISETRACKER는 어떤 리퍼러가 언제 광고를 클릭했는지 확인하게 됩니다.앱 설치: 사용자는 구글 플레이에서 앱을 설치합니다. 이때 구글은 해당 사용자의 리퍼러를 앱에 포함시켜 설치되게 합니다.리퍼러 매칭: 앱이 실행되면서 리퍼러가 WISETRACKER로 전송됩니다. 2)단계에서 확보한 리퍼러와 매칭하며, 일치할 경우 앱이 설치된 것으로 리포트합니다.Android 점유율이 높은 국내 환경에 적용하기 쉽고, 리퍼러가 유실될 확률이 낮아 고유 식별자 분석만큼 정확도가 높습니다. WISETRACKER는 고유 식별자 측정을 사용할 수 없는 경우(옵트 아웃 또는 광고매체 설정), 다음 순서로 리퍼러 방식을 적용해 앱 설치를 측정하고 있습니다.하지만 구글 플레이를 사용하지 않는 환경(iOS, 그리고 서드파티 앱마켓)과 모바일웹으로 접속한 구글 플레이에서는 활용할 수 없는 것은 극복하기 어려운 단점입니다. WISETRACKER가 리퍼러 방식을 최우선 순위로 사용하지 않는 이유가 여기에 있습니다.3. 단말기 핑거프린팅고유 식별자와 리퍼러를 사용할 수 없는 환경(대표적으로 모바일웹 환경)에서는 단말기 핑거프린트를 기준으로 앱 설치를 측정합니다. 단말기 이름, 단말기 유형, OS 버전, IP 주소, 통신사 등 다양한 정보를 조합해 단말기를 식별할 수 있는 고유의 지문을 만든다는 개념으로 생각하시면 좋습니다.추적 URL 적용: WISETRACKER의 추적 URL을 앱 설치 링크에 적용합니다. 링크가 적용된 광고를 사용자가 클릭하면 분석이 시작됩니다.핑거프린트 전달: 사용자가 광고를 클릭했을 핑거프린트 값이 WISETRACKER로 전송됩니다. 이제 WISETRACKER는 어떤 단말기가 언제 광고를 클릭했는지 확인하게 됩니다.앱 설치: 사용자는 마켓에서 앱을 설치합니다.핑거프린트 매칭: 앱이 실행되면서 단말기의 핑거프린트가 WISETRACKER로 전송됩니다. 2)단계에서 확보한 값과 매칭하며, 일치할 경우 앱이 설치된 것으로 리포트합니다.핑거프린팅 방식은 어떠한 환경에도 적용할 수 있는 높은 범용성이 가장 큰 장점입니다. 그러나 모바일 기기의 특성상 IP주소 또는 위치정보가 달라질 수 있기 때문에 시간이 지남에 따라 측정의 정확도가 떨어진다는 것이 단점입니다.이런 단점 때문에 WISRTRACKER는 핑거프린팅을 마지막 순위로 적용하고 있으며, 광고 클릭 이후 24시간 이내의 핑거프린트만을 활용해 앱 설치를 측정하고 있습니다. 광고 클릭 시 수집된 핑거프린트의 유효기간을 24시간으로 설정해, 24시간이 경과한 값은 자연유입 설치로 리포트합니다.신뢰할 수 있는 방법을 선택하는 것이 중요 WISETRACKER는 하나의 앱 설치를 측정하기 위해 모든 환경에 대응할 수 있는 앱 설치 측정 방식를 구현하고, 광고 클릭과 앱 실행 두번의 터치 포인트에서 데이터 매칭을 통한 검증 프로세스를 진행합니다. 앱 설치에 대한 측정이 앱 마케팅 성과 분석의 시작이기 때문에 까다로운 과정이 필요한 것이 당연합니다.시작부터 Garbage Data가 들어온다면 그 데이터를 기반으로 한 성과 분석은 프로젝트를 잘못된 방향으로 이끌게 될 것입니다. 따라서 성과 분석을 통한 퍼포먼스 향상을 위해서는 시작부터 정확한 데이터를 확보할 수 있는 측정 방법을 설계하고 채택하는 것이 중요하다는 점을 잊지 않으시길 당부드립니다.
조회수 1734

스파크랩 투자 유치, 그리고 우리가 집중해야될 목표.

투자 확정은 9월 21일이였다. https://www.facebook.com/hyunil.filab/posts/1424721077604707?pnref=story그리고 9월 25일, 오늘 역삼 스파크 플러스 1호점으로 사무실에 입주했다. 지문 등록도 하고 회의실도 예약해서 앞으로 우리의 목표에 대해서 팀원들에게 나의 생각을 공유했다.올해는 어떻게든 BEP를 맞춥시다. 자생적으로 살아남아야 됩니다. 그러면 우리는 우리가 하고 싶은 걸 하면서 더 큰 미래를 만들 수 있을 겁니다.한번 더 글로벌 액설레이터가 필요하다면 다음 목표는 YC입니다. 사실 우리는 이미 YC에 온겁니다. YC 배치에서는 운동과 일만 합니다. 우리는 우리가 이루어할 공동의 목표를 잊지 않고 여기에 몰입하면 반드시 달성할 수 있습니다.그래서 우리의 목표는 올해 BEP를 맞추는 것이다. 10월, 11월, 12월 3개월 안에 맞출 수 있을까? 현재 팀원 4명 풀타임, 1명 파트 타임. 우리가 타겟하고 있는 강남 고객(특히 청담동의 페르소나)을 월 7건만 유치하면 (7마리 분양)가능하다고 판단된다. 7건을 위해서 무엇을 해야되는가? (핵심 활동 1)브리더 인터뷰 콘텐츠 포스팅, 2)메세지 아웃바운드 영업, 3)데일리 입양 가능 자견 포스팅) 4)퍼널 들어와서 매칭 안된 고객 계속 추적)1. 브리더 인터뷰 콘텐츠 확보 월 15개 포스팅, 이틀에 하나 꼴로 인터뷰 포스팅. (가능하면 더 많이) (이는 동시에 브리더 소싱/선별/영업이 동시에 이루어져야 하므로 가장 시간이 많이 드는 작업이다.)2. 시간날 때마다 인스타 다이렉트 메세지 영업  실험(매일 10명을 목표로)  (페이스북 메세지 효율은 상당히 좋았다. 타겟팅이 안되서 실제 전환까지는 힘들었지만.)3. 매일 입양 가능한 아이들 [부견-모견-자견] 1개 세트 업로드하기 ( 현실적으로 브리더 수에 따라 이것이 가능하기 때문에 힘들 수도 있다. 따라서 SKU를 최대한 중복 없는 느낌으로 잘 포스팅해서 피드 노출을 극대화 해야된다고 생각된다.)4. 우리의 이탈률은 [1] '가격'과 [2] '지속적인 응대 실패' 가 제일 컸다. 고객이 원하는 강아지라면 그 가격대에 살 수 없어서 다른 곳에서 강아지를 선택하는 경우가 이탈 대다수였다. (가끔 외모가 마음에 안들어서 이탈하는 경우도 종종) 이 문제는 참 어렵다.. 구찌와 같은 브랜드십과 퀄리티를 유지하면서도 가격은 몇십만원에 팔아야 된다는 의미다.. 이건 많이 고민중이다. [2]에 대해서는 우리가 좀 더 신경을 기울이면 충분히 수익으로 전환시킬 수 있는 부분이라서 신경써서 해야될 것 같다. +알파,오프라인 타겟 마케팅을 전통적인 방법으로 꾸준히 실험하면서 효율을 최적화시키는 것을 수시로 병행. 파트너십을 활용한 효율적인 노출(특히 예를 들어 분양 추천에 대한 문의가 꽤 있는 청담 우리 병원을 통한 모객), 그리고 리드를 넓히기 위한 각종 활동으로 고객이 유입되었을 때 퍼널을 계속 추적, UX를 계속 개선시키고 웹페이지가 어드민 시스템으로 가기 이전에 랜딩에서 충분히 후킹될 수 있는 디자인 작업과 글귀가 빠른 시일 내에 완성이 되어야 할 것 같다. (10월달) 그리고 SBA 프로그램에 10월 말 데모데이에서 마케팅 자금을 따와서 이제 돈을 태워보며 A/B테스트를 해봐야될 것 같다.2018.01.01 당당하게 달성했다는 글을 쓸 수 있도록...!!!우리가 받은 투자는 론치 투자라는 것을 받았다.나 혼자 생활비만 써도 겨우 겨우 살아갔는데 같이 일하는 팀원들까지 있으니 처음에 식비(회식비)라도 책임지자라는 마음에 애견샵에서 알바하는 것을 마음 먹었지만 ROI도 너무 안좋고 그렇게 강아지 판매&관리 하는 건 단 하루도 못 버틸 것 같았다. 그래서 내가 선택한 것은 "창업경진대회 알바" 였다.상금을 타면서 현금 500만원을 모았고 (큰 걸 한방했어야 하는데.. 짜잘한 것에서 1등 많이 해봤자...) Cj 올리브 네트웍스에서 주최한 경진대회에서 126팀 중 2등을 했고 거기 심사위원으로 있었던 스파크랩 대표님이 페오펫에 가장 좋은 점수를 주셨다. (여기서 창업허브 입주 공간도 얻게 되어 사실 사무실이 2개..) 그 인연으로 이렇게 스파크랩과 인연이 되었다.스파크랩 데모데이 6기 블로그 포스팅스파크랩 데모데이 8기 블로그 포스팅대학생때부터 스파크랩 데모데이에 갔다. 이 행사는 내 가슴을 정말 미치게 뛰게 만들었다. (지금도 나도 뭐 휴학한 대학생이지만...) 매번 나는 스파크랩 데모데이를 갈 때마다 저 무대에 반드시 오를 거다. 조금만 기다려라. 를 외쳤었다. 근데 생각보다 빨리 그 미래가 왔다. 상상의 힘은 강력하다. 먼 미래를 앞당기니깐.요즘 내가 자극받고 있는 사진, 휴대폰 잠금 화면페오펫은 하루 빨리 세계 시장에 뛰어들려고 한다. 우리의 가치를 한국 사람들에게만 알리는 것은 매우 안타깝다. 전 세계를 놀라게 만들고 싶다. 그리고.. 그를 통해 더 많은 사람들이 더 높은 꿈을 꾸게 만들고 싶다. 가치를 넘어서 영감을 주는 기업을 설립하고 싶다.상상의 힘은 강력하다. 먼 미래를 앞당기니깐.우리는 입양(분양)만으로 절대 안끝난다. 입양하고 난 뒤에 열리는 그 시장에서 우리의 독보적인 시장을 만드는 것을 목표로 한다. 내가 그리고 우리가 페오펫이 그렇게 생각하고 그렇게 할거기 때문에 그렇게 될거다. 그냥 그렇게 믿고 현재에 집중하는 것이다. 분양과 이커머스는 분명 다른 두 개의 사업이다. 그럼에도 불구하고 분양을 접점으로 브리더분들의 브랜딩을 통해 이커머스에서 새로운 도약을 만들 수 있는 기회가 분명히 존재한다고 상상하고 있다.상상한다고 비용이 드는 건 아니니깐. 꿈은 크게 꾸고 작고 빠르게 행동하자. 모든 일이 다시작은 미약하지만 끝은 창대하지 않는가. 그 거대한 비전을 상상하며 가능한 빨리 실패를 해보는 것이다. 한번 성공하면 계속 성공시킬 수 있다고 믿고 있다. 페오펫의 첫 성공을 통해 우주의 커다란 흔적을 남길 수 있는 여정의 계기가 되었으면 한다.#페오펫 #peopet #투자유치 #IR #자금조달 #자금유치 #스타트업 #생존기 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/