스토리 홈

인터뷰

피드

뉴스

조회수 3553

인스타그램 마케팅 5대 궁금증

내 블로그를 구독하시던 분들은 인스타슈가라는 인스타그램 마케팅 자동화 툴을 약 5개월째 운영중인걸 알고계실텐데 벌써 3400개 이상의 고객사에서 사용중이고 2500만개 이상의 활동데이터가 싸일 정도로 규모가 커져 버렸다. 이렇게 많은 고객사+개인을 상대하며 비즈니스를 하다 보니 인스타그램 마케팅 관련해서 공통된 질문들을 많이 받게 된다. 이 기회에 이를 정리해 보는것도 의미가 있을 것 같아, 지금까지 인스타슈가 라이브챗을 통해 문의받은 약 600여건의 질문내용 중 가장 빈도높은 것 5개만 뽑아봤다. (인스타슈가 비즈니스가 궁금하신 분들은 인스타그램 마케팅 DO & DON'T을 참고해 주세요~)1. 인스타그램 채널 운영하면 매출이 늘어날까요?인스타그램 마케팅을 처음 시작하시는 분들이 가장 궁금해하는 부분이다. 특히 소규모 업체, 쇼핑몰 등에서 가장 궁금해 한다. 아쉽지만 결론부터 말하면 "직접적으로 연결되지는 않습니다" 이다. 우리가 측정한 데이터로는 평균 컨버젼, 즉 팔로워 수 대비 하루 평균 프로필 링크 클릭율이 약 3~7%대에 형성되는 편이다. 이건 링크 클릭만을 산정한거고 여기서 실 구매로 연결되는 컨버젼까지 감안해 보면 사실 인스타그램으로 다이렉트하게 매출을 일으키는 부분은 통상 1% 미만으로 생각하는게 합리적이다. 즉, 인스타는 매출을 직접적으로 발생시킬 수 있는 마케팅 채널이 절대로 아니다. 그럼에도 불구하고 인스타그램 채널로 마케팅을 하는 이유는? 그건 인스타그램이 FAN-BASED MARKETING 채널로서 매출에 미치는 간접적 효과가 어마하기 때문이다.잘 운영되는 인스타그램 채널은 보통 다음과 같은 특징을 지니고 있다.- 팔로워의 모수보다는 실제 교감이 발생하는 활성 팔로워에 집중한다.- 팔로워들과 댓글로 활발하게 대화한다. ("소통해요" "피드 느낌 좋아요" 이런 댓글들을 말하는게 아니다.)- 제품의 직접적인 어필 보다는 이를 일상적 컨텐츠로 잘 녹여낸 사진들이 올라온다. (이건 있다가 더 자세하게 설명하겠음)- (해당 브랜드가 제법 규모가 있어 다양한 마케팅 채널을 운영중이라면) 인스타그램 채널만의 독자적인 톤&매너, 할인행사 등으로 뭔가 팔로우를 유지할만한 가치가 있게 해준다.위 내용 말고도 컨텐츠 하나하나에 쓰는 내용이나 특정 팔로워를 띄워주기 한다던지, 아무튼 인스타 채널을 잘 운영하는 브랜드의 특징은 "인스타그램 계정을 팔로워 한다는 것의 의미"를 가장 충실히 잘 수행하면서 차곡차곡 팬 규모를 쌓아나가서 이를 통해 간접적인 매출효과 뿐 아니라 브랜드의 신뢰도, 로얄고객층 형성 등의 보다 중장기적 목표를 가지고 운영한다는 점에 있다.2. 우리 브랜드 공식 인스타그램 계정이니까 제품이나 브랜드 관련 컨텐츠만 올려야 할까요?생각보다 많은 기업계정들이 이 부분을 상당히 오해하고 있다. 인스타그램에서 저게 본인 브랜드의 "공식 계정"이니의 여부는 전혀 상관이 없다. 즉, 공식계정이라고 제품샷이 도배된 컨텐츠 운영을 해야한다는 강박관념에 빠져서는 안된다는 뜻이다. 본인이 스타벅스급으로 사람들이 알아서 좋아해주는 브랜드가 아니라면 다음 사항을 유념해야 한다.기업계정을 맞팔해주는 경우는 1) 나도 팔로워를 늘리고 싶은데 기업계정들이 가장 맞팔을 잘해주니까 맞팔해주는 경우, 2) 그 기업계정의 컨텐츠가 진짜 마음에 들거나 내가 평소 관심있었던 분야라서 해주는 이 딱 2개 케이스밖에 없는데, 100명이 맞팔을 한다면 1번이 거의 80% 이상의 비중을 차지한다.자, 그러면 1번의 이유로 들어온 사람들을 내 팔로워로 붙들어서 향후에는 내 브랜드에 관심갖게 만드려면? 당연히 그들 피드에서 컨텐츠가 튀어야 하고 그들 피드를 광고성 컨텐츠로 도배해서는 안된다. 이런상황에서 당신이 계속 특색도 없는 제품관련 샷만 도배한다면 당연히 맞팔을 했다가도 언팔율이 높아질수 밖에 없고, 언팔율이 높아지면 당연 팬을 형성하는것도 불가능해진다.그렇다면 어떤 컨텐츠가 좋은 컨텐츠일까? Bad case를 소개하면 해당 기업에서 컴플레인이 올수 있기 때문에 Good case만 몇가지 소개해 보겠다. (아, 참고로 인터넷이나 책같은 곳에서 말해주는 베스트 케이스니 이런거 보면 뭐 대부분 스벅, 나이키 등등 이런급 계정을 얘기하는데, 그들 인스타가 잘 운영되는건 그들의 인스타그램 전략이 좋아서가 아니라 그냥 그 브랜드 자체가 파워풀해서임을 명심해야한다. 내 브랜드력이 저 급이 아닌데 저 계정들을 베스트케이스라고 보고 배우자.. 정말 1도 도움이 안되는 예시다.)1) 제품샷이지만 "인스타틱하고 엣지가 있는" 컨텐츠들이어서 언팔하고 싶은 느낌이 안드는 계정들여기에 해당되는 계정들은 보통 다음과 같은 공통된 특징이 있다.- 엣지가 있다. 즉, 피드에서 확실히 단일 컨텐츠가 튀어보인다.- 잡지에 나오는 정형화된 모델샷들이 아니다.- 제품 말고도 본인 브랜드들에 대한 다양한 스토리를 소개한다.Wear Your Label (@wearyourlabel)SpheroNineteenth Amendment2) 대기업 브랜드 아니고서야 오피셜 브랜드라고 계정도 오피셜일 필요가 있을까? 창업자 본인의 페르소나로 본인 제품을 잘 띄우고 있는 계정들 (특히 패션, 아트 분야일수록 이 전략이 더 유효한 경우가 많다)여기에 소개된 계정들은 보통 다음과 같은 공통된 특징이 있다.- 창업자 본인을 메인 페르소나로 빼서 자기 제품을 띄우고 있다.- 역시 컨텐츠에 엣지가 있다.- 본인의 라이프를 통해 내 브랜드가 어필하고싶은 메시지를 강하게 전달한다.Jordan Washburn (Well-dressed Wayfarer 창업자)Young Bae (Diamond Tatto Studio 창업자) JI Eon Lee (하플리 창업자)3) 컨텐츠도 나쁘지 않으면서, 팔로워 한명한명을 마치 내 상점에 방문하는 고객을 응대하는것 처럼 정성을 다해 소통하다보니 팔로워 수에 비해 계정 활성도가 매우 뛰어난 계정들여기에 소개된 계정들은 보통 다음과 같은 공통된 특징이 있다.- 사진에 달리는 댓글 하나하나에 영혼없는 응대가 아닌 실제 보이스로 반응해준다.- 적은 규모라도 팔로워들만 대상으로 다양한 이벤트를 상시 운영해서 이 계정을 팔로워할 가치가 있게 한다.- 팔로워 규모가 크지 않아도 댓글이나 (소통해요~ 이런댓글 말고) 라이크수가 왠만한 K찍힌 계정들을 능가한다. (사실 이런 계정들이 진짜 알짜배기 계정들이라 할 수 있음)김해 금란다원 (@twiny2k)랩노쉬 (@labnosh_official)페티앙북스 (@petianbooks)사실 1번, 2번 케이스는 크리에이티브도 뛰어나야 하고, 모델의 역할이 매우 중요해서 스타트업이나 자영업 계정에서 시도하기에는 조금 어려운 면이 있다. 하지만 3번 케이스의 경우 누구나 조금만 노력을 기울이면 쉽게 활성팔로워들을 키워나갈 수 있고, 이들 중 반드시 당신 브랜드의 소비자로 전환되는 루프가 형성될 수 있으니 인스타그램 마케팅을 막 시작하신 분들은 꼭 3번 케이스를 중심으로 연구하길 바란다.3. 팔로워 수가 많을수록 우리 컨텐츠 노출도 비례해서 많아지나요?결론부터 말하면 "그렇지 않습니다"이다. 유저수가 많지 않고 노출 알고리즘이 단순했던 인스타그램 초창기에나 내가 컨텐츠를 포스팅하면 시간순으로 팔로워들 피드에 모두 노출이 됐지만 페이스북에 인수된 이후 지금은 어마어마하게 복잡한 노출알고리즘이 운영중이다. 특히 2016년 3월을 기점으로 어마어마한 변화, 즉 팔로워들의 포스트를 시간순으로 배열하던 방식을 완전히 버렸는데, 이에 대한 내용은 인스타그램의 공식 공지사항을 읽어보자.2016년 3월, 인스타그램은 기존의 시간순 노출을 버리고 새롭게 태어났다.사실 위의 글만 가지곤 인스타그램 알고리즘이 도대체 어떻게 진화하고 있는지 알길이 없으니, 수 많은 사람들의 분석글을 참고해 볼 필요가 있는데, 이 글들을 다 읽어보라고 하면 욕먹을 수 있으니 당신이 기억해야 하는 가장 중요한 내용을 정리해 보면 다음과 같다. 단계별 반응도에 따른 포스트 퀄리티 인덱스 (QI)가 일정 수준을 넘지 않으면 노출량이 줄어든다.무슨 말이냐면, 예를들어 팔로워가 100명이면 100명에게 모두 컨텐츠를 노출하지 않고 평소에 내 사진에 반응이 자주 있었던 사람들, 또는 내 프로필을 자주 방문했던 사람들 위주로 일부 노출한다. 여기서 일정비율 이상의 초기 반응을 얻는 포스트는 QI값이 높아져서 그 다음 그룹에 노출되고, 또 반응이 좋으면 그 다음 그룹... 이렇게 사다리 타기 방식으로 노출이 된다. 따라서, 당신의 QI값이 별로라면 팔로워가 아무리 많아도 노출이 잘 안될 수 있고, 당신의 QI값이 월등하면 적은 팔로워로도 노출 짱짱맨이 될 수 있다. 시중에 있는 유령/허위 네트워크로 5분만에 팔로워 찍어주는 서비스를 절대로 사용해서는 안되는 이유가 바로 여기에 있다. 팔로워가 만명인데 반이상이 허위 팔로워 찍혀있는거면 당연히 QI가 안나오니 컨텐츠 노출이 잘될리가 없다. 보통 팔로워가 막 K 찍혀있는데 컨텐츠에 라이크가 막 50개도 안달려 있거나, 컨텐츠에 라이크가 막 1000개 넘게 찍혀있는데 댓글은 가뭄에 콩나듯 달린 포스트들은 백퍼 이런 케이스에 해당한다.포스트 노출에 가장 중요한 요소는 양적인 팔로워 수 보다는 "활성팔로워 수"인데, 이게 높아야 QI지수가 높아지기 때문이다.** 인스타그램 노출 알고리즘 관련 분석글들 중 가장 잘된것만 몇개 추려봤으니 궁금하신 분들은 아래 링크 글들을 참고해 주길 바란다. (제법 out-dated 된 글들도 있으니 알아서 취사선택 바람)Instagram's got a new way to determine which photos show up in your feed — here's how it works (인스타그램 관계자가 한 말이라 제법 신뢰도가 있는 글)Understanding the Instagram Algorithm: 7 Key Factors and Why the Algorithm is Great for Marketers (위 글을 기반으로 나름의 상상력을 펼쳤는데 제법 그럴싸 해 보이는 글)How the News Feed Algorithms Work on Facebook, Twitter & InstagramHow do news feed algorithms work? (Quora, 첫번째에 있는 Abhinav Sharma의 답변을 참고하자)4. 컨텐츠 올릴때 해시태그를 많이 달 수록 노출이 많아지나요?결론은 "그렇지 않습니다" 이다. 필자도 사실 옛날에는 그런줄 알았다. 해시태그를 달면 해시태그 검색에 걸리고, 해시태그 서핑을 타고 들어온 오가닉 유입, 혹은 얻어걸린 탑 포스트에서 들어오는 유입이 많아질 거라 생각했는데, 어느날 우리 개발자가 "저렇게 해시태그 스팸질을 하는 꼴을 인스타가 그냥 놔둘것 같진 않은데 우리 한번 제대로 파보자" 해서 한달동안 인스타슈가를 통해 쌓인 수천만건의 DB를 분석했더니, 컨텐츠에 달리는 해시태그 수랑 노출량은 전혀 관계가 없다는 결과가 나왔다. 그 이유를 나름 추정해 봤는데, 인스타그램에서 해시태그 스패밍 이슈 해결을 위해 한 포스트에 태그를 많이 달수록 각 태그별 웨잇을 나눠서 분산시키기 때문이다. 무슨 말이냐면, 태그를 0-1개를 달때 1이라면, 10개를 달면 1/10이 10개가 되서 결국 1이 되는 개념이다. 이에대한 자세한 분석 결과는 우리 개발자가 쓴 인스타그램 #해시태그는 많이쓸수록 좋을까? 글을 참고해 주길 바란다.이렇게 해시태그 스팸 + 복붙할 시간에 컨텐츠나 댓글에 신경쓰자5. 라이크를 많이 받아야 탑 포스트에 노출되나요?이것도 결론은 "반드시 그렇지만은 않습니다" 이다. 탑 포스트 노출 로직은 더 베일에 싸여 있는데, 예전에 레딧의 한 유저가 실험을 해 본 글이 유명하다 - How to get to Instagram "top-posts" almost instantly (물론 2년전 글이기도 하고 개인이 자기 계정으로 실험해본거니 신빙성이 떨어지나, 그 로직 자체는 그럴싸 하다) 이 글에 의하면, 컨텐츠를 포스팅 한 후 24시간 이내에 라이크를 일정 수준 이상 받게되면 탑 포스트에 올라가고 (이걸 Growth Index라고 부른다), 한 해시태그에서 일정 기간동안 GI가 높은 포스트들을 번갈아 가면서 보여준다. 즉, 단순히 포스트에 라이크가 가장 많다고 탑 포스트에 계속 올라가 있는게 아니라는 뜻이고, 실제로 필자도 몇번 실험을 해봤는데 이 글의 로직이 어느정도 신빙성 있다.이제 탑포스트에 올라가는것 조차 복잡한 알고리즘이 돌아가고 있고, 계속 GI를 측정하면서 순환되기 때문에 굳이 비싼돈 들여 허위 라이크 구매하는 서비스를 사용할 필요가 없어졌다.지금까지 인스타슈가를 통해 접수되는 질문들 중 사람들이 가장 궁금해하는 토픽 5개를 뽑아 정리해 봤다. 아무쪼록 이 글이 위와 같은 질문을 상습적으로 받는 인스타그램 마케팅 담당자님들 (또는 광고주를 상대하는 대행사 분들)에게 조금이나마 도움이 됐으면 좋겠다.여기 아래부터는 우리가 서비스하는 인스타슈가라는 인스타그램 마케팅 자동화 솔루션을 (대놓고) 광고하려고 하니, 광고에 알러지가 있으신 분들은 여기서 창을 닫아주시기 바란다. (제발 "다 읽어보니 기승전광고네"라고 욕하지 말아주세요 ㅠㅠ)본인 브랜드가 스벅, 나이키 급도 아니고, 그렇다고 엄청난 컨텐츠력이 있는 상황도 아닌데 완전 제로베이스에서 인스타그램 팔로워를 늘려나가는건 결국 엄청난 노가다 작업이 수반된다. 노가다 작업이란건 뭐냐면, 맞팔류 태그들이나 빅태그들을 돌아다니면서 내 비즈니스 타겟에 맞는 사람들 계정을 선팔하며 돌아다니다 보면, 그들 중 일부가 맞팔을 해주게 되고, 이렇게 생긴 팔로워들을 잘 관리하면서 꾸준히 노가다를 하면 계정 활성도가 높은 몇천명대 인스타 계정을 누구나 만들수 있는 방법인데, 참 사람이 하기에는 너무 불쌍하고 고된 작업이다.시중에 이런 작업을 대신 해주는 프로그램들을 돈받고 파는 업체들이 매우 많이 있으나, 대부분은 다음과 같은 문제점을 앉고 있다.1) 설정해놓은 태그에서 최신 포스트의 계정을 무작위로 선팔하기 때문에 성인, 스팸계정, 내 비즈니스와 전혀 상관없는 계정들이 대거 걸리게 된다.2) 인스타그램에서는 사실 위와 같은 프로그램의 사용을 정책상 금지하고 있어서 계정별로 활동 리밋을 12-24시간 기준으로 정해놓는데, 물론 공개된 데이터가 아니다. 위의 프로그램들은 대부분 이런 리밋을 고려치 않고 설계되있고, 유저가 속도를 임의로 조절하면서 돌리도록 되있는데, 이러다가 계정이 기능블락에 걸리다가 심한 경우 disabled 먹는 경우도 다반사다.3) 비즈니스 계정들이 대거 걸린다. 내가 B2B 하는거 아니라면 대부분 인스타에서 "소비자"를 팔로워로 타겟하고 싶을텐데, 맞팔로 걸리는 계정들이 거진 "비즈니스"계정들이라, 심지어 같은 경쟁사들, 동종업체들끼리 모두 맞팔이 되어있는 경우도 다반사다.아무튼, 위에 언급한 문제 말고도 프로그램을 써서 팔로워를 늘리는거에는 정말 수만가지의 문제점들이 있어서, 작년에 우리가 직접 사용할 스크립트를 만들어 우리 계정 + 주변 스타트업 계정들 도와주다 보니 엄청난 퀄리티를 자랑하는 스크립트로 유명해져서 아예 정식 비즈니스가 된게 바로 인스타슈가라는 솔루션이다.인스타슈가 - https://instasugar.co/<iframe width="940.000000" height="529.000000" src="//play-tv.kakao.com/embed/player/cliplink/vdf62MgDwepuMGxRDaeyxpN@my?service=daum_brunch§ion=article&showcover=1&showinfo=0&extensions=0&rel=0" frameborder="0" allowfullscreen="">이 솔루션이 월등한 이유는 다음과 같다.1. 40여가지 이상의 기준으로 타겟할 유저를 결정2. 머신러닝 기반의 봇계정이 돌아다니며 수집하고 있는 160만건 이상의 성인, 스팸계정 DB를 통해 99.8%의 정확도로 스팸계정 필터링3. 해당 계정이 개인 계정인지, 비즈니스 용도인지를 검증하여 비즈니스 필터링 모드가 on 되어 있으면 비즈니스 계정들을 94%의 정확도로 필터링4. 인스타그램의 활동 리밋양을 추정하고 이 범위 내에서 최대효율을 내는 확률모델을 통해 가장 팔로워 전환 확률이 높을것으로 추정되는 계정들만 타겟함5.대시보드 -  현재 프로그램이 움직이는 로그, 타겟팅 해시태그 설정, 프로그램의 상태, 시작 및 정지, 다양한 특수 기능들을 모두 실시간으로 확인 & 통제 가능6. 안정성 - 해당 계정에 기능블락이나 특정 이슈가 생기는걸 실시간 감지하여 자동 정지, 속도 조절, 자동 재생 등이 통합적으로 이루어짐인스타슈가 사이트 회원가입 후 계정 연결하면 무료로 체험해 볼 수 있는 10명 토큰을 지급하고 있으니 관심있으신 분들은 체험해 보길 바란다. (무료라고 기능이 딸리고 그런거 아님. 유료나 무료나 동일한 토큰을 지급해 드립니다.)인스타슈가 웹사이트 바로가기
조회수 841

[중요] 아마존 US 수수료에 대한 세금 징수 공지

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 주식회사 컨택틱의 이이삭 대표입니다.2019년 6월 1일부터 아마존 US에서 몇 종류의 수수료 (판매수수료, FBA수수료 등)에 대한 세금을 특정 주에 사업이 설립된 판매자로부터 징수하기 시작합니다. 이 변화에 대해 여러분들이 알고 계셔야할 사항은 무엇이 있을까요? 딱 1가지만 기억하세요.1. 한국 판매자들은 전혀 영향받지 않습니다.매번 아마존에 대한 새로운 정책, 프로그램, 이벤트, 변화 등이 생길때마다 여러분께서는 대표적으로 이 한 가지 질문에 대해서 걱정하실겁니다: ‘나한테 영향이 있는 내용인가?’ 그리고 ‘내가 제대로 이해한건가?’ 입니다. 특히나 세금처럼 민감한 주제는 당연히 눈여겨봐야할 것입니다. 그래서 저는 정말 깔끔명료하게 결론부터 알려드리고자 합니다. 이 정책 변화는 한국 판매자들에게 전혀 영향주지 않습니다.Photo by Kelly Sikkema on Unsplash우선, 가장 눈여겨봐야할 내용은 ‘어떤 수수료에 대한 세금을 징수하는건가’입니다. 크게 봐서 두 가지 수수료에 대해 세금이 징수된다고 보면 되는데요, 1) Selling on Amazon Fees (아마존 판매수수료), 2) FBA Service Fees (FBA를 이용할 때 기타 서비스에 대한 수수료)입니다. 2번에 대해서 주의해야 하는게, FBA 배송대행 수수료에 대해서 부과하는 게 아니예요! 사람들이 주로 FBA 수수료라고 할 때 생각하는 게 FBA 배송대행 수수료입니다. 가장 낮게 평가되는 게 $2.41 정도 하고, 무게나 부피에 따라 천차만별로 결정되는 아마존의 FBA 배송대행 수수료는 다시 한 번 말씀드리지만 이 정책에 영향 받지 않습니다! 사람들이 거의 이용하지도 않는 amazon prepping service (라벨링, 포장, 테이핑 서비스 등)에 대해 부과한다는 내용입니다.다음으로 눈여겨봐야할 내용은 ‘누구에게 해당하는 내용인가’입니다. 이것도 두 가지로 봐야하는데요, 첫 번째, Selling on Amazon Fees는 다음과 같은 미국 주에 사업이 설립된 판매자들에게만 해당합니다: Connecticut, the District of Columbia, Hawaii, South Dakota or West Virginia. 만약 여러분의 사업이 위 주에 설립된 사업자가 아니라면 (당연히 이 글을 읽고 계신 여러분은 한국 사업자들일거라 아니라고 생각합니다만), 세금이 징수되지 않습니다. 두 번째, FBA service fee에 대한 세금은 모든 판매자에게 적용되는겁니다. 근데 거의 사용하지도 않는 FBA service fee에 대한 세금 징수예요. 굉장히 헷갈릴 수 있어서 또 강조할게요… FBA shipping fee에 대한 세금이 아니라 FBA service fee에 대한 세금입니다. 이건 모든 판매자들에게 적용되는 내용이며, 배송이 이루어진 FBA 창고가 속한 주의 세율이 적용됩니다 (평균적으로 4~10% 내외).아마존으로부터 위 정책 변화에 대한 이메일을 받은 여러 한국 판매자들이 걱정부터 앞섰을거라 생각합니다. 제가 여러분들을 대신해서 정말 꼼꼼히 이메일을 읽어봤고, 위와 같이 정리해드렸습니다. 참고하실 수 있도록 아래에도 이메일 사본을 첨부해드렸습니다.이 공지에 대한 서론이자 결론은 ‘한국 판매자들은 아무 걱정 없이 평소대로 판매해도 된다’는 것입니다. 따라서 여러분들은 안심하시고 평소처럼 열심히 판매에만 집중하시면 됩니다!Amazon Seller Services로 부터온 이메일 - 1Amazon Seller Services로 부터온 이메일 - 2컨택틱의 모든 교육은 파트너인 글로벌셀러창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러창업연구소의 홈페이지를 통해 가능합니다.오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: [email protected]홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon유튜브 채널: https://www.youtube.com/c/kontactic
조회수 1209

2017년의 첫 시작, 유어 마이 캔디걸 임지애님 :)

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

수평적 조직은 정말 좋은 것일까?

 최근 채용행사나 면접 자리에서 지원자들에게 흔히 듣는 말이 있다. '어느 정도 규모 있는 회사에서 일을 했었는데, 의견을 쉽게 말할 수 있는 분위기도 아니고 주어진 일만 하는 것이 너무 힘들어서 비교적 자유로운 분위기의 스타트업으로 이직을 결심했어요.' 결론부터 말하자면, 반은 맞고 반은 틀린 말이다. 자유로운 분위기의 대기업도 있고, 수직적 조직문화의 스타트업도 있기 때문이다. 물론 보편적 관점에서 보았을 때, 스타트업이 구성원의 의견에 더 귀를 기울이고, 주어진 일 보다는 스스로 문제를 찾고 해결해야 하는 것은 맞지만, 세상 만사 늘 그렇듯 내가 원하는 대로만 일이 흘러가는 것은 아니다. 이 글을 쓰고 있는 나 역시 그렇지만, 대부분의 구직 경험이 있는 사람들은 수직적인 조직에 상당히 익숙해져 있는 편이다. 피라미드 구조와 경직된 조직문화의 끝판왕 군대는 말할 것도 없고, 선생님과 학생, 선배와 후배, 부장과 사원, 그리고 갑과 을...우리가 일상적으로 접하는 조직 또는 관계성은 대부분 수직적이고, 체계적이다. 그래서 우리들은 알게 모르게 창의력과 유연한 사고를 동경하고, 구글이나 밸브처럼 '비교적' 수평적이면서도 개인의 발상과 자유를 존중해주는 기업이 더 좋은 기업이라는 생각을 품고 있는지도 모른다. 그러나 다시 또, 늘 그렇듯, 세상 만물에는 이유가 있는 법. 수직적인 조직문화가 악습과 폐습에 불과하다면 우리 삶과 맞닿은 그 많은 조직들이 모두 수직적으로 이루어졌을 리가 없다.  그래서 오늘은, 다양한 시각에서 세상을 보자는 쓸데없이 거창한 기치 아래, 수직적인 조직의 장점과 수평적인 조직의 단점을 적어보려고 한다. 수직적인 조직의 문제점이야 여러분이 그동안 숱하게 겪어왔을테니 그 부분은 건너뛰고, 수평적인 조직의 장점이야 여러 매체에서 수없이 접했을테니 이 부분 역시 건너뛰고.1. 찬물에도 위아래가 있으면 뭐가 좋을까? 수직적 조직의 장점은 간단하다. 큰 규모의 집단을 체계적으로 굴릴 수 있고, 그로 인해 집단의 이익을 극대화할 수 있다는 점이다. 5명으로 구성된 조직에서, 사장 밑에 부사장이 있고, 그 밑에 부장이 있고, 그 밑에 과장이 있고 또 그 밑에 사원이 있다고 한다면, 내가 내릴 수 있는 평가는 지극히 명료하고도 단순하다. '군대놀이 그만하세요.' 하지만, 500명으로 구성된 조직에 위계가 없다면, 여기에 대한 평가 역시 아주 쉬울 것이다. '오합지졸들만 애써 모아놨네.' 정확히는 기억나지 않지만 좋아하던 소설에 나온 말로, '분열을 할 수 있으면 군대이다'라는 문구가 있었다. 가령 5,000명의 군중이 그저 모여있을 뿐이라면 그것은 평범한 집단에 불과하지만, 그 집단이 발을 맞추어 걸을 수 있다면 군대가 될 수 있다는 뜻이다. 비록 지나치게 수직적일지라도 잘 짜여진 체계가 집단에 부여하는 힘은 그만큼 효율적이고 강력하다. 뛰어난 보상체계로서의 역할 역시 무시할 수 없다. 내가 아무리 많은 일을 뛰어나게 해낸다고 해도, 다른 사람과 나를 규정짓는 무언가가 없다면 의욕이 떨어질 수 밖에 없다. '당신은 우리 회사에서 100년을 일한다고 해도 과장 이상으로 승진할 수 없습니다'라는 말을 들었다고 한다면, 아무리 돈을 많이 준다고 해도 한 번 정도는 퇴사를 생각하게 되지 않을까? 반대로, 대리, 과장, 부장, 임원이 되기 위해 열과 성을 다해 일하는 사람을 우리는 얼마나 많이 보았는가? 그리 달갑지 않은 부분이겠지만, 조직의 개편 또는 조정이 아주 쉽고 명확하다는 것도 큰 장점이다. 병렬한 다른 부서와 쉽게 성과를 비교할 수 있고, 책임 소재가 분명하다. 영업 1부의 실적이 영업 2부보다 낮다면 영업 1부에 대해서만 고민하면 되고, 회사 전체가 갈피를 못 잡고 휘청거리는 경우라면 임원진에 대해서 경영의 책임을 묻는 극단적인 방법을 택할 수도 있다. 어디에 어떤 문제가 있는지 비교적 쉽게 파악이 가능한 것이다. 물론 여러분이 익히 겪어온 바와 같이, 이런 장점들이 때로는-혹은 대부분의 경우-바로 단점으로 작용하기도 한다. 잘 짜여진 수직적 조직체계는 집단의 도덕성과 이성을 마비시키기도 하며, 더 높은 직급과 직위를 위해 수단과 방법을 가리지 않는 경우도 비일비재하고, 문제가 되는 일부를 쉽게 도려내어 버리는 문화가 정착될 수도 있다. 그럼에도 불구하고, 수직적인 조직문화는 무시할 수 없는 장점을 갖고 있다.2. 우리는 모두 친구!....어, 저희 아버지랑 동갑이세요...? 사실 이 부분을 전달하고 싶어서 이 글을 시작하게 된 것이나 마찬가지이다. 수평적 조직문화라고 하면 무언가 좋아보이고, 새롭고 편해보이겠지만, 나름의 고충이 있다. 가장 먼저, 무임승차하는 사람을 잡아내기 힘들다는 점이 있다. 한 명의 리더 또는 리더 없이 유기적으로 움직여서 일을 해야 하는 수평적 조직의 특성상, 내가 일을 조금 덜 하거나 더 하는 것이 크게 눈에 띄지 않는다. 예를 들어서, 더팀스의 영업 담당인 내가 네트워킹에 나간다고 해놓고 어디 PC방이나 사우나에서 놀고 있다고 해도 그걸 알기는 쉽지 않으며, 반대로 밤낮없이 사람들을 만나고 술자리를 가지며 간을 혹사시킨다고 해도 당장 극적인 변화가 일어나지는 않는다. 조직 전체가 아주 서서히 병들게 되는 것이다. 그렇다고 서로가 서로를 신뢰하지 못해 감시하거나 참견하게 되면 삽시간에 조직이 와해되어 버린다. 두번째는 자유로운 만큼 책임이 크다는 점이다. 의견을 쉽게 낼 수 있고, 그 의견이 받아들여지는 빈도 역시 수직적인 문화의 조직에 비해 상당히 높다. 그럼 그 다음은? 책임을 져야 한다. 다른 구성원들의 생각과 다른 의견을 냈고, 그 의견이 받아들여졌다면, 내가 옳았음을 입증해야 한다. 발언권이 강하다는 것은 딱 그만큼의 무게로 돌아온다. 자유롭게 의견을 말하는 것에서 끝나는 것이 아니다. 누군가는 그 의견에 딸려오는 업무를 처리해야 하는데, 높은 확률로 그것은 당신이 된다. 3일째 같은 옷을 입으며 떡진 머리와 시꺼매진 눈시울로 '너무 쎄게 질렀나...'하는 생각을 하게 될지도 모른다는 것을 항상 생각해야 한다. 비슷한 맥락이지만, 주어진 일만 처리하는 것이 아니라 하고싶은 일, 할 수 있는 일을 스스로 찾아서 해야 한다는 것도 상당한 부담이다. 당장 해야 할 일이 없어 보이는데, 뭔가 우리 회사는 나이스하게 돌아가는 것 같지 않고...그렇다면 작은 것 하나라도 일단 부여잡고 일을 해야 한다. 누가 시켜서 하는 일이라면 차라리 된다, 안 된다 견적이라도 나올텐데, 내가 찾아서 일을 하려니 당최 성공기준을 뭘로 잡아야 할 지도 모르겠고, 그렇다고 난 할 일이 없다며 무임승차를 할 수도 없는 노릇이다. 아주 가끔은, 시키는 일만 똑바로 해주면 되던 시절이 그리울 때가, 아주 가끔 있기도 하다. 이렇게 편향된 시점으로 조직론에 대해 글을 썼지만, 역시 중요한 것은 적절한 조화이다. 부, 과 별로 잘게잘게 쪼갠 업무를 맡기는, 전근대의 극단적인 수직적 조직은 그 부작용이 오히려 성장을 저해하는 결과를 낳았고, TF시스템의 도입이나 사내 존칭/직급 호칭 폐지와 같은 것으로 나타나고 있다. 반대로 극단적으로 수평적인 조직은...친구들끼리 사업하면 망한다는 말이 왜 격언처럼 전해져 오는지만 봐도 알 것이다. 더팀스의 경우, 대표님을 중심으로 자유롭게 의견을 교환하는 수평적인 조직문화를 갖고 있다. 각자가 직급이나 직위는 다르지만 모두 한 명의 '팀원'으로서 의견을 말할 수 있고, 발언권이나 업무 권한, 역량을 제한하는 것은 아무 것도 없다. 대표님부터가 팀원들에게 의견을 강요하지 않고 합당한 이유를 들어 설득하려 하시기 때문인 것도 있고, 누군가가 강하게 어떤 의견을 제안한다면 '그렇게까지 말한다면 꼭 필요한 일이겠지'라는 팀원들간의 깊은 신뢰가 작용하기 때문에, 수평적이면서도 효율높은 조직문화를 구축해 올 수 있었다. 하지만 우리라고 예외는 아니기에, 대체로 같은 방향을 보고 있긴 하지만 '정확하게' 같은 목표를 바라보고 있지 않아 혼선이 빚어졌던 것을 깨닫고 명료한 목표 설정을 위한 긴급회의를 잡거나, 업무의 우선순위를 명확히 정해 문제를 해결하려 한다(대략 연 2~3회 정도 주기로 이런 오차를 좁히는 것 같다). 거기에 다들 무임승차만은 죽어도 하기 싫어하는 성격인 탓에 평균적으로 1주일에 4일 정도는 오버워크를 하고, 어느 날은 일이 너무 많아 '아 정말 힘들다, 나는 왜 이렇게 일이 많은걸까'라는 생각이 들어 주위를 슬쩍 둘러보면 아무도 나보다 일을 덜 하는 사람이 없다는 것에 충격을 받기도 한다. 그리고 도저히 결정하기 힘든 안건이 있을 때 6~7시간의 끝장토론을 거쳐 최종적인 의사결정을 내리기도 한다. 나름 이상적인 조직문화라 자부하는 더팀스이지만, 이런 고충이 있다. 거기에, 만약 서비스가 점점 성장하여 팀원이 15명, 20명이 된다면, 더 이상 이런 시스템을 유지할 수는 없을 것이다. 최소한 TF체제, 아니면 어느 정도 수직적인 요소를 결합한 체제가 되어야 합리적으로 조직이 기능하는 순간을 맞이하게 될 것이기 때문이다. 그래서, 수평적인 조직문화 하나만을 보고 이직을 결심하는 사람이 있다면, 꼭 하나 말해주고 싶은 것이 있다. '조직문화가 수평적이라고 마냥 좋은 게 아니더라고요...'#더팀스 #THETEAMS #수평적조직문화 #팀워크 #팀플레이 #기업문화 #스타트업일상 #업무환경 #시스템구조론
조회수 832

5분만에 끝내는 앱 어트리뷰션

2018년에도 그랬듯이 우리는 항상 시간이 부족합니다. 많은 시간을 들여 높은 수준의 성과를 만들어 내야 하지만, 그 성과를 이루기 위해 필요한 학습에는 충분한 시간을 할애할 수 없습니다. 우리의 현장은 학교가 아니니까요!2019년 업무에 앱 어트리뷰션이 골치거리가 될 것 같다면 지금 이 글이 도움이 될 것입니다. 북마크 해놓고 틈틈이 읽어보세요. 어트리뷰션의 기본적인 개념, 전체적인 흐름, 각 부분이 연결되어 동작하는 매커니즘을 습득할 수 있습니다. 그리고 더 깊이 있는 학습이 필요하다면, 각 챕터 마지막에 있는 ‘+ 더 알아보기’를 참고해 보세요.1. 시작 – 광고 클릭위와 같은 광고를 클릭하면 랜딩 페이지로 이동하게 됩니다. 거의 대부분 플레이 스토어 또는 앱스토어로 이동하게 될 것입니다. 그런데 어트리뷰션이 가능하기 위해서는 이런 광고들에 조금 특별한 URL이 세팅되어 있는데 이것을 ‘트래킹 URL’ 또는 ‘트래킹 링크’ 등으로 부릅니다.http://ads.wisetracker.co.kr/wa/wiseAdw.do?_wtno=502&_wthst=trk.wisetracker.co.kr&_wts=P1535606238444&_wtc=C1535606305460&_wtm=C0000013&_wtaffid={wff_id}&_wtbffid={wffsub_id}&_wtcid={clk_id}&_wtgpid={GAID}&_wtidfa={IDFA}&_wtdl=http://www.wisetracker.co.kr&_wtp=2트래킹 URL은 위 예시처럼 길고 심란하게 생겼습니다. URL을 봐도 이해가 되지 않으니 긴 설명은 하지 않겠지만 이것만은 꼭 기억해 주세요. 유저가 광고를 클릭하면 1)유저에 대한 정보를 URL에 싣고서, 2)URL이 바라보고 있는 트래킹 서버로 연결됩니다.+ 트래킹 URL 자세히 알아보기2. 경유 – 정보 수집광고를 클릭하면 스토어로 즉시 이동하는 것이 아닙니다. URL이 가리키는 트래커 서버를 잠깐 스치고 스토어로 이동합니다. 트래커 서버를 스치는 그 잠깐의 순간에, 트래커는 URL에 실려있는 정보들을 수집한 다음 유저를 스토어로 리다이렉트 시킵니다.만약 광고에 트래킹 URL이 없다면? 트래커 서버를 스쳐갈 일도 없으니 아무런 정보도 수집되지 않고, 결과적으로 어트리뷰션이 불가능하겠지요.3. 스토어 – 앱 다운로드광고를 클릭한 유저의 단말기가 Android 라면 플레이 스토어, iOS 라면 앱 스토어에 랜딩되어 앱을 다운로드 하게 됩니다. 더 이상 설명할 것이 없으니 넘어가시죠.4. 앱 실행 – 2차 정보 수집드디어 다운로드된 앱이 처음으로 실행 되었습니다. 앱이 실행되면 앱에 미리 삽입되어 있던 분석 SDK도 함께 실행되면서 분석 기능을 수행합니다. 분석한 정보는 트래커 서버로 전송하지요. 여기에서 중요한 사실은 앱이 실행 되어야만 분석이 동작한다는 점입니다. 분석 SDK는 앱과 한 몸입니다. 앱이 실행되어야 분석 SDK도 실행되면서 기능을 시작할 수 있습니다. 따라서 단말기에 다운로드 되었지만 실행되지 않은 앱은 분석도 불가능합니다.5. 어트리뷰션 & 포스트백위의 모든 과정을 거치며 트래커 서버에는 두 종류의 데이터가 수집되어 쌓이게 됩니다. ‘2. 경유’ 단계에서 수집한 데이터와 ‘4. 앱 실행’ 단계의 데이터가 그것입니다. 트래커는 이 두 데이터를 대조합니다. 광고를 클릭한 유저와 앱을 실행한 유저가 동일한지를 살펴보는 것입니다.두 데이터가 일치한다면 광고를 통해 1 건의 설치가 발생했다는 것으로 판단합니다. 이 판단 행위를 ‘인스톨 어트리뷰션’이라고 부를 수 있겠네요. 1건의 어트리뷰션이 이뤄지기 위해서 앞의 과정들이 필요하다는 것을 이해할 필요가 있습니다.이렇게 어트리뷰트 된 데이터를 광고 매체로 보내는 것을 포스트백이라고 합니다. 예를 들어 어트리뷰션 결과 ‘ABC’라는 매체를 통해서 인스톨이 발생했다면, 트래커는 해당 매체에게 ‘ABC 광고를 통해서 인스톨 1건 발생’했다는 것을 포스트백 합니다. 이렇게 되면 ‘ABC’ 매체는 포스트백 데이터를 근거로 비용을 청구할 수 있고, 광고 효율을 최적화 할 수 있습니다.+ 어트리뷰션 메소드 더 알아보기+ 포스트백 더 알아보기다음 글에서는 웹 환경에서 집행하는 CPC 키워드 광고를 통한 앱 유입 분석에 대한 내용을 다뤄보겠습니다.
조회수 882

[Buzzvil Culture] 버즈빌 2018년 가을 체육대회

 날이 많이 시원해진 가을날 버즈빌리언은 서울 장충체육관에 함께 모여 매년 열리는 체육대회에 참가해 버즈빌리언 답게 활기 넘치는 모습을 한껏 보여주었습니다. 즐거움으로 가득했던 2018 버즈빌 가을 체육대회의 현장으로 여러분들을 초대합니다.  보통 체육대회에서 사회자가 ‘이번 게임에 참가할 분들, 앞으로 나와주세요!’라고 하면 모두 쭈뼛쭈뼛하기 마련인데요. 승부욕이 넘치는 버즈빌리언은 망설임 없는 적극적인 모습을 보이며 활기찬 분위기를 조성했습니다. 여기에 James와 Jayden의 매끄러운 입담이 가득했던 사회로 진행돼 한층 더 재미있었습니다. 버즈빌의 재미와다채로운 회식을 책임지는 Fun Club의 기획 아래 이날 버즈빌리언은 4개의 조로 편성돼 환호성이 넘쳤던 판 뒤집기, 꼬리잡기, 피구, 농구, 줄다리기 등의 게임을 즐겼습니다.  결국 누가 이겼을까요? 바로 Ben, Caitlyn, Ekko 등 멋진 운동 신경을 자랑하는 쟁쟁한 분들이 포함된 1조의 승리로 체육대회가 마무리됐습니다. 우승한 모든 팀원은 어깨와 팔의 건강을 챙기는 안마기를 하나씩 받았습니다! 모두가 부러워하는 핫 아이템 이었습니다. 이날 각자 소속된 부서와 상관없이 개발자든, 마케터든 서로 잘 어울리며, 우승을 위해 달려가는 모습이 참 인상적이었습니다. 다른 기업은 자기가 소속된 팀의 구성원이 아니라면 교류하는 기회가 많지 않을 텐데요. 버즈빌리언은 어떻게 다른 팀의 사람들과 친하게 지낼 수 있을까요.  우선 버즈빌은 다양한 동호회, 문화생활, 스터디 모임 지원으로 모든 버즈빌리언이 친하게 지내고 함께 성장할 수 있도록 문화 복합 공간 같은 분위기를 조성합니다. 또한 버즈빌에는 미션팀이라는 게 존재합니다. 한 미션 팀에는 각 팀에서 필요한 인재들로 형성돼 회사에서 필요한 미션을 하나씩 수행합니다. 이렇듯 버즈빌은 다양한 배경의 사람들이 서로에게 자극을 주고 시너지 효과를 낼 수 있는 독특한 문화를 만들기 위해 노력합니다. 그러기 때문에 버즈빌의 단체 활동에는 장난기와 웃음이 가득한 게 아닐까요?얼마 전 버즈빌의 공식 블로그에서 소개된 버즈빌 2018 Walkathon을 기억하시나요? 이날 TOP 3가 드디어 발표됐습니다. 1위부터 순서대로 Benjamin, Lucas, Ahreumong의 이름이 호명됐는데요. 상품으로는 운동화 상품권이 주어졌습니다. 앞으로도 걸으면서 몸과 마음이 건강해지는 버즈빌리언이 되기를 기대합니다.  이번 체육대회와 Walkathon은 버즈빌의 친목도모와 몸이 건강해질 수 있도록 준비된 이벤트입니다. 앞으로도 재미있는 행사로 버즈빌리언에게 좋은 추억을 선물할 수 있는 버즈빌이 되도록 노력하겠습니다.    *버즈빌에서 함께할 인재를 채용 중입니다. (전문연구요원 포함) 지금 바로 지원해보세요!
조회수 498

목표 달성을 위해 왜 협업툴이 필요할까요?

안녕하세요 협업툴 플로우입니다.2021년 2분기가 지나고 어느덧 8월입니다. 벌써 2021년의 반이 지나갔습니다. 다들 올해 정한 개인의 목표는 얼마큼 이루셨나요? 저는 상반기에 수영을 배우려고 했지만 코로나로 인해 아직 시도조차 못했습니다. 개인의 목표와 마찬가지로 회사에서도 매년 목표를 정하고 달성률을 체크하는데요. 이번 포스팅은 기업 목표를 달성하기 위해 필수 조건인 협업툴에 대해 알아보려 합니다.협업툴이란 무엇인가?협업툴이란 여러 사용자가 별개의 작업 환경에서 하나의 프로젝트를 동시에 수행할 수 있도록 만들어주는 소프트웨어입니다. 새로운 개념 같아 보이지만 협업을 위한 솔루션은 이전부터 존재했는데요. 전화, 팩스 그리고 우리에게 익숙한 이메일도 커뮤니케이션을 위한 툴이나 협업툴의 한 축으로 볼 수 있습니다. 이후 무선 인터넷과 개인 모바일 기기의 보급이 가속화 되면서 협업툴에도 변화가 생기기 시작했는데요. 바로 우리가 가장 많이 사용하는 메신저 형태 협업툴의 출현입니다.협업툴하면 메신저 형태의 소프트웨어라고 생각하시는 분들이 많습니다. 협업툴을 영어로 하면 콜라보레이션 툴인데요. 단순히 커뮤니케이션만 가능한 메신저의 협업툴이 아닌 파일과 문서를 주고받고 음성/화상 회의가 가능하고, 업무를 등록하고 (To-Do-List) 관리하는 콜라보레이션 툴이 진정한 협업툴이라고 할 수 있습니다. 단순한 사내 메신저가 협업툴이라고 생각하면 큰 오산입니다!왜 협업툴을 도입해야 하나요?이메일과 USB, 외장 하드로 업무를 주고받으며 잘 쓰고 있는데, 왜 번거롭게 협업툴을 도입해야 하냐고요? 코로나로 인해 재택근무를 하면서 파일이 회사에 있어 곤란했던 적이 있으셨을 겁니다. 갑자기 USB와 외장하드가 뻑나서 자료가 날아간 경험도 있으실 거고요. 이메일을 찾다가 담당자에게 결국 통화를 해서 재전송을 요청했던 일, 카카오톡에서 파일 다운로드 기간이 지나 자료를 날려먹은 경험도 있으실 거고요. 만약 협업툴을 사용하고 있었더라면 어땠을까요?클라우드(SaaS)에 보관된 파일을 언제 어디서나 안전하게 확인할 수 있고 편집할 수도 있었을 겁니다. 정신없게 아무런 규칙 없이 쌓여있는 이메일에서 벗어나 업무별로 분리된 자료를 쉽게 찾아볼 수 있고요.오픈서베이의 업무툴 트렌드 리포트 2021을 살펴보면 연령대가 높을수록 개인 메신저인 카카오톡으로 업무 소통을 하는 경우가 많았습니다. 나이가 낮을수록 사내 메신저를 쓰는 경우가 많았고요. 요즘 젊은 사람들은 일과 개인 생활을 분리하는 걸 중요시한다는 리포트 결과가 아닐까 생각합니다. MZ 세대와 함께 일하기 위해서 앞으로 채용 페이지 한편에 "협업툴을 사용합니다."라는 문구가 꼭 필요할지도 모릅니다. 사족이 길었습니다. 협업툴을 써야 하는 가장 큰 이유는, 일이 편해지고 성과가 올라가기 때문입니다. 업무 성과뿐만 아니라 직원의 만족도도 대폭 올라갑니다.어떤 협업툴을 도입해야 하나요?코로나19가 터지고 난 뒤 국내, 해외 할 것 없이 협업툴이 우후죽순 생겨났습니다. 앞서 협업툴의 개념에 대해 이야기해 드렸는데요. 단순히 메신저 기능을 지원하는 협업툴이 많이 생겨났습니다. 메신저만 지원하는 협업툴의 경우에는 의사소통을 하기에 개인용 메신저보다 편할지 모르지만, 기업의 목표 달성과는 거리가 있습니다. 협업툴을 도입할 때 프로젝트 차원의 관리가 되는지 꼭 한번 확인해보셔야 합니다.✅ 메신저형 협업툴슬랙, 팀즈, 카카오워크, 네이버웍스, 플로우, 잔디✅ 프로젝트형 협업툴지라, 아사나, 트렐로, 플로우또 한 가지 고려해야 할 점은, 우리 회사의 정책에 맞는가입니다. 대기업이나 금융사, 법률사무소 등 개인 정보가 중요시되거나 별도의 보안 정책이 있는 기업의 경우 해외 협업툴을 사용할 수 없습니다. 사내에 있는 서버에 설치를 해서 내부망에서만 운용을 해야 하죠. 흔히 말하는 인트라넷만 가능한 대기업에서는 협업툴을 사용하기 어려웠습니다. 하지만 협업툴 플로우의 경우에는 서버 설치형 (온프레미스)가 가능하기 때문에 많은 기업에서 사용 중에 있습니다.일의 효율과 생산성을 증가시키고, 직원들의 스트레스를 줄일 수 있는 방법 중 하나는 협업툴의 도입이 아닐까 생각합니다. 백 번을 설명해도 한 번 써보고 체험해보는 게 중요합니다. 협업툴을 도입해서 2021년 하반기에는 꼭 목표 달성을 하시면 좋겠습니다.협업툴 플로우 바로가기
조회수 1651

금융 테크놀로지와 #개발

여름은 언제 끝날까? 주말부터 더위에 지친 오늘, 단비 같은 시원한 소식이 핀다에 찾아왔다.한국형 핀테크 세계 금융 판도 흔든다`제1회 매경 핀테크 어워드` 11기업 선정핀다 장려상 수상!매일경제에서 주최한 Fintech Awards에서 #Finda 가 장려상을 수상했다는 소식. (감사합니다!) 한 주의 시작을 청량감 가득한 시원한 뉴스로 시작하다니 흥이 절로 난다.금융상품 비교 추천 플랫폼으로서 Finda 이외에도 온라인 가상화폐인 '비트코인(Bitcoin)'을 활용한 신개념 해외송금 서비스 업체 '센트비' 등 총 11개의 핀테크 기업이 선정되었다. 지금까지 걸어온 우리의 걸음마에 시원한 바람을 넣어주는 것 같아 핀다 가족들이 더 힘이 나는 날이다.나는 개발자이다.핀다에서 금융상품의 검색을 시작의 용이성을 시작으로 금융 테크놀로지에 기여하고자 하는 개발자이다. #핀테크스타트업 '핀다'와 함께한 나의 이야기를 해보고자 한다.  개발 경력 10년이 넘어버린 때. 지금으로부터 2-3년 전쯤일 게다. 한창 늘어져만가는 시점에서 같이 일하던 회사 이사님이 솔깃한 제안을 해왔다. #스타트업 #Startup! WHAT?경력으로도 가늠하겠지만, 적지 않는 나이이기도 했고, 오래전 말아먹은(?) 안 좋은 기억도 어렴풋이 남아있다. (무엇인지에 대해서는 구체적으로 적진 않겠다ㅎ) 그렇지만, 뭔가의 변화가 필요했던 시점에... 나의 귓가를 울리는 새로운 단어 Start up. 뭐랄까. 단비와도 같은? 오늘 매경에서 수상한 그런 '단비'보다 문자 그대로 '꼭 필요할 때 알맞게 내리는 비 = 단비' 같은 결정적인 모먼트.하여튼 그러했다.돌파구가 필요했던 시점. 적절했다.라고나 할까.2년을 좁디좁은 사무실에서 그야말로 쉼 없이 뒹굴었다. 그 사이 늦은 결혼에 낳은 늦둥이도 세상 빛을 보았고 세상은 더욱더 팍팍해졌으며 더불어 2년의 시간이 무색해져 버릴 만큼의 성적표가 떨어져 버린 거다.다시 새로운 무언가를 찾아야 했던 시절. 딱히 어떤 목표랄까 기대 같은 건 없이 가벼이 만났던 인연이 지금 내가 이 자리에 있게 된 운명 같은 것이었다고 말할 수 있겠다.스타트업 + 핀테크 개발자로 변신개발 13년 차에 다시 시작한 스타트업.게다가 그 핫하다는 핀테크 바닥이란 말이다.어찌할 바를 모르던 모바일 개발자 덕분에 한 달을 투여했던 API 개발은 모두 쓸모없는 일이 되어버렸다. 그나마 소득이라면 그 한 달의 기간 동안 같이 얘기하고 토론했던 Co-Founder 두 분과의 인연은 깊어졌다. 그 덕에 기대도 못했던 핀테크 업체의 개발 헤더 자리에 비비고 앉게 되어 버렸다. 물론 내 의지가 전혀 없었다고 얘기할 순 없겠지만 말이다. (사실은 매우 의욕적이었다.)하지만 개발일이라는 게 서로 얼굴 맞대며 일해도 어려운 것을, 한 달이 넘게 떨어져 있었으니 서로 일정을 맞추기도 어려웠고 서로의 상황이 달라 업무 상호 확인도 어려운지라 제대로 돌아가기가 힘들었다. 결국 모바일 버전의 프로토타입은 접어두고 "그래~! 웹 버전으로 시작하자"였다. 어차피 만들어둔 API도 있겠다, 프런트엔드만 올리면 되는 일.그리 시작한 "FINDA"의 웹서비스 개발은 드. 디. 어 지난 1월에 세상에 빛을 보게 되었다. 아직 조금 모자란 "Beta"라는 이름을 걸고 말이다. 눈물이 다 날 지경이었다. 론칭 며칠 전까지만 해도 할 수 있을까? 였는데.. 할 수 있게 되다니.빠른 시일 내에 베타 서비스로 완성을 해야 했으나, 마음에 차지 않는 부분들이 여럿 있을 수밖에 없었다. 최종적인 모습인 "개개인의 성향과 상황에 따른 맞춤 추천 서비스"를 지향하기 위해선 많은 부분들이 필요했던 것. 여러 상품들을 담아두고 싶은 마음에 여러 방면으로 두 대표님들이 뛰어다니던 차, 금감위에서 오픈 API를 제공하기로 한다는 소식이 들렸다. 오호~! 뭔가 될 법한 일에는 이리도 딱 맞는 기회가 주어지는구나.금감원 API를 통해 상품군의 다변화와 다루는 금융 상품들의 개수도 많이 늘렸다. 덕분에 손봐야 하고 신경 써야 하는 일들이 많이 늘긴 해야 했지만 무언가 서비스가 성장하고 있다는 느낌이라. 방문자 수도 꾸준히 늘어 갔고 심심치 않게 외부 피드백도 손에 쥐게 되었다. 그렇게 한두 달이 정신없이 지나가고...핀다 서비스 테크놀로지- 개발자의 시선으로정식 론칭! 대망의 4월, 이젠 정말 실전이다. 정식 서비스 론칭은 베타 서비스 론칭에 비해서 그나마 수월했다. 베타 서비스 론칭 때 이미 겪은 바도 있었으니 미리미리 준비해 둔터일 게 다. 그래도 서비스 론칭인데 수월했다고는 하나 정신없는 건 어쩔 수 없는 모양.정식 서비스를 론칭한 후 핀다팀은 서비스 전반에 대해 다시금 되돌아보는 시간을 갖기로 했다. 이른바 Finda Hackathon~! 각 팀별로 서비스에 대한 생각과 앞으로 나아가야 할 방향 그리고 준비해야 할 사항 등에 대해 열띤 토론이 이어졌다. 개발자로서도 꽤나 의미 깊은 시간이 아니었나 싶다. 솔직히 시간에 쫓겨 개발에 몰두하다 보면 전체적인 그림을 못 보고 지엽적인 문제에 치중하게 될 때가 많은데, 이렇게라도 시간을 내어 서비스 전반에 걸쳐 되돌아볼 수 있는 시간을 가진다는 게 여러 가지 면에서 좋은 방법인 듯싶다.론칭 후에도 할 일이 많다. 서비스를 키워나가야 하기 때문. 마케팅팀도 보강되었고 지속적으로 인력도 늘어갔다. 외부 업체와의 MOU도 점차 늘려 나갔고  그에 따라 서비스에 상품군과 기능들도 많이 늘어왔다. 개발팀의 업무량도 자동적으로 증가. 상품에 대한 소비자들의 직접적인 의견을 들을 수 있는, 그리고 그에 따라 1) 상품 선택에 도움이 되는 리뷰 기능의 확충, 2) 소비자들이 상품의 조회에 그치지 않고 선택한 상품의 가입을 보다 더 쉽게 이룰 수 있도록 3) 상품 조회에서부터 선택, 가입에 이르는 플로워를 다방면으로 테스트하고 개선시켜 나간다든가 하는 일들이 많아졌다. 게다가 4) CMS 등의 내부 시스템의 개발까지 그야말로 눈코 뜰 새 없는 시간의 연속이었다.#육아코딩 집에서도 눈코뜰새 없이 열일 중ㅎ https://www.instagram.com/leepublic/론칭 이후 4개월이 지난 지금.건방지게 느껴질 수도 있지만 당연히 발전적이다. 여전히 성장할 여지(Room to Grow)가 상당히 많다. 그간 상품 수도 많이 늘었고, 서비스의 개선도 지속적으로 이루어져, 실질적은 성과들도 조금씩은 나타나기 시작했다. Stay hungry! 아직도 부족함을 느끼는 건 나만의 욕심은 아닐 것이다. 금융 소비자의 정보 불균형을 해소하겠다던 가치와 신념에 있어 정말 새발의 피만큼의 진전을 이루었겠지만 말이다.그래도 서로 비교할 수 있고, 간단한 몇 가지 항목만으로도 쉽게 상황에 맞는 상품을 볼 수 있다는 것만으로도 많은 시간과 기회비용을 아낄 수 있는 방법을 제기할 수 있어서 다행이라고 생각하고 있다. 솔직히, 나 스스로도 은행 대출을 끼고 집을 구입했던 사람으로서 어디 가서 물어보기도 힘들고 일일이 은행 사이트들을 찾아다니며 비교하기도 힘든데, 진작에 이런 서비스가 있었더라면 몇 번이고 써봤을 거다. 이건 진심이다.아직 해야 할 일은 많이 남아 있다. 처음부터 세세한 부분까지 모두 파악하는 건 어렵겠지만 개개인의 재정상태, 소비형태, 삶의 방식 등의 여러 가지 데이터를 기반으로 대출 및 예적금, 나아가 향유할 수 있는 금융생활에 대한 조언자, 설계자가 되고 싶고 또 그렇게 만들어갈 생각이다. 십원짜리 하나 쓰는 것도 잔소리할 테세다.사람을 기반으로 한 금융 테크놀로지를 꿈꾸며...그러기 위해선 "사람"에 대한 고민이 제일 필요한 일일 게다. 빅데이터라든가, 대용량 처리 시스템이라든가, 클라우드 서비스라든가, 금융 데이터 분석을 위한 Pandas나 데이터의 연관 관계 분석을 위한 딥러닝이라든가. 기술적인 부분들도 매우 중요하고 또 이루어져야 할 일이기도 하지만 그 무엇보다 중요한 건 역시 "사람"이 아닐까 싶다.DVD대여 회사로 출발하여 이제 글로벌 컨텐츠 공룡으로 인정받는 넷플릭스(Netflix) 성공의 기반은 기술도 아니고 콘텐츠도 아니었다. 바로 "사람"에 집중했던 것. 넷플릭스는 #하우스오브카드 (House of Card) 드라마를 출시하면서 “우리는 시청자들이 무엇을 보고 싶어 하는지 잘 알고 있으며, 분석 알고리즘을 통해 누가 케빈 스페이스 혹은 정치 드라마를 좋아하는지 파악하여 그들에게 추천할 것이다”라고 자신 한 바 있다.모든 데이터의 중심에는 "사람"이 있었다. "사람"에 대한 이해 위에 기술을 기반으로 콘텐츠를 입혀 개개인에게 보다 사람답게 다가갔던 게 성공의 열쇠가 아니었나 싶다.핀다 또한 그러한 길을 걸어가야 할 터,나 또한 사람을 기반으로 한 기술의 발전을 꿈꿔볼 일이다.핀다의 금융 테크놀로지이혁 드림Hyek from FindaHead of Engineer#핀다 #개발팀 #개발자 #팀원소개 #조직문화
조회수 1538

무럭무럭 자라는 잔디 CX 꿈나무, Hannah를 만나다

* 2016년 작성된 글입니다편집자 주: 잔디와 함께 하고 있는 멤버는 총 52명. 국적, 학력, 경험이 모두 다른 이들이 어떤 스토리를 갖고 잔디에 합류했는지, 무슨 일을 하고 있는지 궁금해하는 분들이 많습니다. 잔디 블로그에서는 이 궁금증을 해결해 드리고자  ‘맛있는 인터뷰’를 통해 ‘잔디’ 멤버들의 이야기를 다루고자 합니다.(음식점의 이름이 본인의 이름과 같은 글자로 끝난다는 이유로 선택받은 핑크솔747)오늘 인터뷰를 위해 생각한 음식점이 있는가?내 한국 이름은 한솔이다. 그래서 핑크솔로 결정했다. 라임 좋지 않은가? 그리고 핑크솔 어감이 예쁘니까. 회사 근처 음식점 중 가장 예쁜 것 같다. 참고로 난 핑크솔로부터 일체의 협찬을 받지 않았다.자기소개 부탁한다반갑다, 잔디 CX 팀에서 일하고 있는 Hannah다. 한국 이름은 한솔이다.잔디 CX 팀에서는 어떤 일을 주로 하는가?고객 응대와 사용자 경험을 개선하는 일을 주로 도맡아 하고 있다. 처음 팀이 셋업되었을 때, CS(Customer Service)팀이었지만 사용자 경험까지 아우르고 싶어서 최근 CX (Customer Experience)팀으로 이름을 바꾸게 되었다. 최근에는 사용자 경험에 대한 A to Z를 개선하고 있어 조금 정신없이 지내고 있다. 조금 정신없이 지내고 있다는 점을 꼭 알리고 싶다.  (고객 만족을 위해 불철주야 노력하는 CX팀)잔디에 입사하게 된 계기를 알려달라스타트업에서 일하게 될지 몰랐다. 아니 꿈에도 몰랐다. 잔디에 합류하기로 한 결정적 계기는 같은 팀에서 일하고 있는 Jinho님이었다. 잔디와 같은 곳에서 함께 일 하는 게 얼마나 큰 장점 인지를 조목조목 설명해주셨다.  사실 잔디에 들어오기 전 생각이 많았다. 앞으로 뭘 해야 하나 고민하다가 ‘스타트업에서 배울 게 많지 않을까?’란 생각을 하게 되었다. 경영학도로서 대기업 영업/마케팅 분야에 가겠다고 살아왔는데, 과연 그게 내가 인생을 살아가는데 정답일까라는 의구심을 갖게 되었다.그렇다면 내가 할 수 있는 것은 무엇일까? 에 대해 생각하다가 결국 잔디를 선택했다. 모든 건 선택의 연속이다. 난 대기업보다 스타트업에서 내가 배울 게 많고, 장기적으로 내 인생을 풍요롭게 해줄 거라는 믿음에 스타트업을 선택한 것이다. 무엇보다 함께 일 하는 잔디의 멤버들이 너무 좋다. 그렇기 때문에 잔디에 온 것을 후회하지 않는다.잔디에 들어오겠다고 했을 때 부모님의 반응은?코멘트가 없었다. 교수는 자기 연구 시간 등이 확실하고 방학도 있으니 사실 부모님은 내심 내가 교수가 되기를 원하셨던 것 같다.  잔디에 합류하게 된 가장 큰 계기가 Jinho님이라고 했다. 그는 누구인가?현재 잔디 CX 팀에서 함께 근무하고 있다. 난 아부지라고 부른다. 정말 든든한 존재이다. Jinho님 자랑을 하자면 성격이 정말 꼼꼼하다. 사실 난 덤벙대는 성격인데 Jinho님이 꼼꼼하셔서 업무 궁합이 잘 맞는다. 물론, 나만 이렇게 생각할 수 있다. 또 회사일 뿐만 아니라 개인적으로 어렵고 고민되는 일을 인생 선배처럼 물어볼 수 있고 정말 아낌없는 조언도 해주시는 고마운 분이다.(GWP에서 준비한 크리스마스트리와 Secret Santa 선물들)요즘엔 사내에서 GWP(Great Working Place Campaign)도 함께 하고 있다. 소개 부탁한다GWP는 Great Working Place의 줄임말이다. 말 그대로 잔디의 업무환경 개선을 위한 팀이라고 생각하면 될 것 같다. 크게는 얼마 전 진행한 할로윈 파티부터 작게는 탕비실 냉장고 음식 채우기까지 책임지고 있다고 보면 된다. 할 일이 많다. 이 점을 강조하고 싶다. 현재 통계팀의  Hugo와 함께하고 있는데 너무 재미있다. 정말. 시간 가는 줄 모를 정도로 말이다. 하하하하. 이런 우리의 모습을 보고 ‘쟤네 놀고 있는 거 아님?’ 이라고 생각하는 것 같아 슬슬 후임자를 물색하고 있다. 한 번 겪어봤으면 좋겠다. 정말 재미있다. 물론 할 일이 많다.주말은 어떻게 쉬고 있는가?요리! 요즘 요리에 푹 빠졌다.맛있는 인터뷰를 위한 다소 작위적인 답변인 것 같다그렇지 않다. 정말로 요리에 푹 빠졌다. 지난주, 카레를 만들어 먹었는데 정말 맛있었다. 물론, 내 입맛에 맛있기에 다른 사람은 모르겠지만. 마리텔에서 준구 엄마가 하는 거 보고 따라했는데 정말 소름 돋게 맛있었다. 토마토를 주로 이용한 카레인데 기회가 되면 도전해보길 빈다. 며칠 전엔 봉골레를 해 먹었다. 집에서 만들어 먹으니 조개를 정말 원하는 만큼 넣어 먹을 수 있어서 즐거웠다. 한가득 말이다. 모시조개를 좋아해 정말 많이 넣었다.(봉골레인지 조개찜인지 헷갈릴 정도의 조개 양)하지만 이 메뉴들을 모두 아우르는 절정의 메뉴가 있다. 바로 사케동이다. 사케동은 만들기도 쉽지만 맛은 일품이다.Hannah님이 그리는 잔디의 모습이 궁금하다즐거운 잔디로서 사람들이 조금 더 즐겁게 사용하는 협업툴 서비스가 되었으면 좋겠다. CX 팀에 있다 보니 다양한 고객사와 이야기할 기회가 많은데 아직까지는 사용자들이 잔디를 100% 활용해 즐겁게 일하고 있지 못하는 것 같다. 우리가 잔디를 사용하는 것처럼 말이다. 이를 위해 CX 팀에서는 재미있는 잔디 활용 팁을 이메일로 사용자분들께 전달하고 있다. 스팸 메일처럼 보일 수 있지만 꽤 재미있는 팁들이니 꼭 확인해 주셨으면 좋겠다.얼마 전 들었던 UX 강의에서 ‘UX보다 중요한 건 pleasure’라는 메시지가 가장 와 닿았다. UX가 조금 불편하더라도 유저가 제품을 사용하는데 즐거움을 느낀다면, 그 불편함을 잘못 느낀다고 하다. 아이팟도 처음 나왔을 때는 인식도 안 되었다고 한다. 그럼에도 불구하고 성공할 수 있었던 이유는 바로 pleasure에 있었다. 잔디에도 그런 pleasure가 많은데, 사람들이 잘 모르니 많이 알려주고 싶다. 이번에 모바일에 새로 구현된 Easter egg*도 정말 재미있는 기능이다. 유저가 잔디를 더욱 재미있는 게 사용할 수 있는 요소를 늘려나가고 싶다.* Easter egg는 개발자가 서비스에 숨겨 놓는 히든 기능으로 제품에 재미를 주는 요소 중 하나이다. 잔디의 Easter Egg는 유저의 재미를 위해 본 포스팅에서 공개하지 않으려고 한다. – 편집자 주마지막은 맛있는 인터뷰의 공식 코너, ‘어서 말을 해’다. Kevin님의 질문이었던 ‘잔디에서 개선하고 싶거나 있었으면 하는 복지가 있다면?’에 대한 대답을 듣고 싶다점심 식대가 지원됐으면 좋겠다. 주변 친구 중 점심 식대를 지원하는 아이들을 보면 좀 부럽다. 아니 많이 부럽다. 그리고 비즈니스 팀원끼리 워크샵을 한 번 다녀왔으면 좋겠다. 다른 사람들은 어떤 일을 하고 있는지 그리고 어떤 생각을 가지고 있는지 허심탄회하게 이야기를 나눌 수 있는 토론 자리가 마련되었으면 한다.다음 인터뷰이를 위한 질문도 함께 말해달라2016년 발렌타인 계획은?#토스랩 #잔디 #JANDI #CX #CustomereXperience #팀원소개 #팀원인터뷰 #팀원자랑 #조직문화 #기업문화 #사내문화
조회수 1560

응답시간 분포도

애플리케이션의 성능 개선은 웹 트랜잭션의 응답시간을 분석을 통해 이뤄집니다. 와탭의 응답시간 분포도는 대규모 트랜잭션 분석이 가능한 Heatmap 형태로 제공되고 있습니다. 와탭을 사용하는 사용자는 응답시간 분포도를 통해 웹 서비스의 응답시간이 느려지는 것을 알 수 있을 뿐만 아니라 패턴 분석을 통해 느려진 원인을 예측할 수도 있습니다. 와탭의 응답시간 분포도Y 축: 트랜잭션 응답시간을 의미합니다. 10s는 트랜잭션이 시작에서 종료까지의 시간이 10초가 걸렸다는 것을 의미합니다.X 축: 트랜잭션이 종료된 시간을 의미합니다.■: 트랜잭션이 발생한 위치에 색이 칠해집니다. 청색 계열은 정상적인 트랜잭션을 의미합니다. 노랑색과 붉은 색 계열은 에러가 발생한 트랜잭션을 의미합니다. 색상의 농도는 해당 영역에 발생한 트랜잭션의 밀도를 상대적으로 표시합니다.  와탭의 응답시간 분포도는 트랜잭션의 응답시간을 시각화하는 것입니다. 웹 서비스의 트랜잭션을 시각화 할 뿐만 아니라 추적하고자 하는 영역을 드래그하여 트랜잭션의 진행상황을 추적하는 것도 가능합니다.  추적하고 싶은 트랜잭션을 드래그 하는 모습와탭의 응답시간 분포도에서 트랜잭션을 선택하면 분석 화면으로 넘어갑니다. 해당 애플리케이션 서버 정보를 통해 선택된 트랜잭션이 어느 애플리케이션 서버에서 발생했는지 알 수 있습니다.애플리케이션과 선택된 트랜잭션 정보 화면분석하고 싶은 애플리케이션 서버를 클릭하면 해당 애플리케이션 서버에서 발생한 트랜잭션 목록을 확인 할 수 있습니다. 최종적으로 APM을 통해 확인하고 싶은 내용이 트랜잭션의 디테일한 정보일 것입니다. 와탭의 APM은 트랜잭션을 시각화하고 시각화된 트랜잭션을 선택하면 선택된 트랜잭션의 목록을 애플리케이션 서버 별로 분류하여 선택할 수 있는 구조를 가지고 있습니다. 이것은 능동적으로 웹 애플리케이션을 분석할 수 있는 최적화된 흐름이라고 생각할 수 있습니다. 사용자가 응답속도 분포도를 통해 선택한 트랜잭션 목록#와탭랩스 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 1551

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의 사용 목적에 따라서 달라질 수 있음을 말씀드리고 싶습니다. 그래서 단순히 설정값을 나열하기보다는 해당 설정이 어떤 기능을 하는 것인지 저희가 아는 한도 내에서 설명드리려고 하였습니다. 위의 글에서 궁금한 점이나 잘못된 부분이 있으면 언제든지 답글로 달아주시길 바랍니다. 감사합니다.
조회수 1071

테이블이냐, 컬렉션이냐, 그것이 문제로다!(KOR)

편집자 주 외래어 표기법에 따르면 ‘원어에서 띄어 쓴 말은 띄어 쓴 대로 한글 표기를 하되, 붙여 쓸 수도 있다.’고 규정하고 있다.(제3장 제1절 영어의 표기, 제10항과, 컴퓨터 전문어, 전기 전문어 등) 즉 ‘원칙’과 ‘허용’이 모두 가능하다는 의미다. 이를 바탕으로 여러 표기 용례를 참고한 결과, TableView는 ‘테이블뷰(원칙)’로 표기해야 하나, 본문에서는 독자의 가독성을 높이기 위해 ‘테이블 뷰(허용)’로 표기한다. 응용하여, CollectionView는 ‘컬렉션 뷰’로, TableViewCell은 ‘테이블 뷰 셀’ 등으로 띄어 쓴다. Overview앱에서 데이터를 사용자에게 보여줄 땐 여러 가지의 모습으로 나타납니다. 설정 앱처럼 목록으로 보여줄 때도 있고, 사진 앱처럼 그리드(grid) 형식으로 보여줄 때도 있습니다. 이처럼 데이터를 보여줄 때 많이 사용되는 뷰는 테이블 뷰(UITableView) 또는 컬렉션 뷰(UICollectionView)입니다. 각자 특징이 있기 때문에 앱의 성격에 따라 적절한 뷰를 사용해야 합니다. 왜냐하면 목록을 보여주는 디자인을 바꿀 때, 다시 개발해야 하는 수고를 덜 수 있기 때문입니다. 이번 글에선 각각의 뷰를 간략하게 알아보겠습니다. 목록 형식의 설정 앱과 그리드 형식의 사진 앱 스크린샷테이블 뷰(UITableView)단일 열에 배열된 행을 사용해 데이터를 표시하는 뷰입니다. 수직 스크롤만 가능하며, 테이블의 개별 항목을 구성하는 셀은 테이블 뷰 셀(UITableViewCell) 객체입니다. 테이블 뷰는 이 객체들을 이용해 테이블에 표시되는 행을 그립니다. 여러 행은 하나의 섹션 안에 구성될 수 있으며, 각 섹션은 헤더(header)와 푸터(footer)를 가질 수 있습니다. 섹션과 행은 인덱스 번호로 구별하는데, 번호는 0부터 시작합니다. 테이블 뷰는 plain과 grouped 스타일 중 한 가지의 스타일을 가질 수 있습니다. Plain 스타일은 보통 목록 스타일입니다. 섹션의 헤더와 푸터는 섹션 분리기(inline separators)로 표시되고 스크롤을 할 때 해당 섹션 안에 있는 콘텐츠 위에 나타납니다. Grouped 스타일은 시각적으로 뚜렷한 행 그룹을 표시하는 섹션이 있습니다. 섹션의 헤더와 푸터는 콘텐츠 위에 나타나지 않습니다. 아래와 같은 사진을 보시면 확연히 차이를 볼 수 있습니다. plain 스타일의 연락처 앱과 grouped 스타일의 설정 앱테이블 뷰의 많은 메소드들은 인덱스패스(NSIndexPath) 객체를 매개변수 또는 리턴 값으로 사용합니다. 테이블 뷰는 해당하는 행의 색인 인덱스와 섹션 인덱스 값을 가져올 수 있게 인덱스패스의 범주를 선언합니다. 또한 색인 인덱스와 섹션 인덱스 값을 가지고 인덱스패스를 만들 수 있습니다. 특히 여러 섹션이 있는 테이블 뷰는 섹션 인덱스 값이 반드시 있어야 행의 인덱스 번호로 구별할 수 있습니다.override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> AttractionTableViewCell {         // Table view cells are reused and should be dequeued using a cell identifier.         let cellIdentifier = "AttractionTableViewCell"              guard let cell = tableView.dequeueReusableCell(withIdentifier: cellIdentifier, for: indexPath) as? AttractionTableViewCell else {             fatalError("The dequeued cell is not an instance of AttractionTableViewCell.")         }                 let attraction = attractions[indexPath.row]                 cell.attractionLabel.text = "\(indexPath.row). \(attraction.nameWithDescription)"         cell.attractionImage.image = attraction.photo                 cell.attractionImage.tag = indexPath.row                 attraction.indexPath = indexPath                 ...                 return cell     } 위의 코드는 데이터 소스(data source) 메소드로, 테이블 뷰의 특정한 위치에 셀을 추가합니다. 다시 말해, 이 메소드는 테이블 뷰가 ‘표시할 새로운 셀이 필요할 때마다’ 특정 행에 노출할 정보가 있는 셀을 만들고 리턴하는 걸 말합니다. 매개변수로 필요한 셀 객체의 행을 가리키는 indexPath 값을 전달합니다. 그리고 indexPath의 row 값을 이용해서 attraction이라는 배열 인덱스로 활용하고, 셀에 표시할 정보들을 설정합니다. 여기서 attraction 배열은 관광 명소들의 정보들이 담고 있는 배열인데, 1행은 첫 번째로 저장한 관광 명소, 2행은 두 번째로 저장한 관광 명소 등 순서대로 설정하도록 indexPath.row 값을 이용하는 것입니다. indexPath의 row 값과 배열의 인덱스 값은 0부터 시작하기 때문입니다. 해당 예제는 섹션이 1인 경우이기 때문에 섹션 인덱스 값이 없지만, 섹션이 여러 개 있다면 반드시 섹션 인덱스 값을 이용해서 설정해야 합니다.테이블 뷰 객체는 데이터 소스(data source)와 델리게이트(delegate)가 필요합니다. 데이터 소스는 UITableViewDataSource 프로토콜을 구현해야 하고, 델리게이트는 UITableViewDelegate 프로토콜을 구현해야합니다. 데이터 소스는 테이블 뷰가 테이블을 만들 때 필요한 정보를 제공하고 테이블의 행이 추가, 삭제 또는 재정렬할 때 데이터 모델을 관리합니다. 델리게이트는 화면에 보이는 모습과 행동을 담당합니다. 예를 들어 표시할 행의 수, 사용자가 특정 행을 터치했을 때, 행의 재정렬 등과 같은 것입니다.override func numberOfSections(in tableView: UITableView) -> Int {         // #warning Incomplete implementation, return the number of sections         return 1     }      override func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {         // #warning Incomplete implementation, return the number of rows         return attractions.count     } 위의 두 소스는 데이터 소스가 필수적으로 구현해야 하는 메소드입니다. 하나는 섹션의 개수를 리턴하고, 또 하나는 한 섹션 안에 있는 행의 개수를 리턴합니다.테이블 뷰는 수정 모드에서 행을 추가, 삭제, 재정렬할 수 있습니다. 각 행은 테이블 뷰 셀에 연관된 editingStyle에 따라서 추가, 삭제, 재정렬을 할 수 있는데, 예를 들어 editingStyle이 insert라면 추가하는 메소드를 실행하고, delete면 삭제하는 메소드를 실행합니다. 행의 showsReorderControl 속성이 true라면, 재정렬하는 메소드를 실행할 수 있습니다.// Override to support editing the table view.     override func tableView(_ tableView: UITableView, commit editingStyle: UITableViewCellEditingStyle, forRowAt indexPath: IndexPath) {         if editingStyle == .delete {             // Delete the row from the data source             ...                 // delete rows and attractions and reload datas             attractions.remove(at: indexPath.row)             tableView.deleteRows(at: [indexPath], with: .middle)             tableView.reloadData()         } else if editingStyle == .insert {             // Create a new instance of the appropriate class, insert it into the array, and add a new row to the table view         }     } 위 소스는 editingStyle이 delete일 때 셀을 삭제하고 테이블 뷰를 다시 로드하는 기능을 구현한 것입니다.테이블 뷰를 만드는 가장 쉽고 권장하는 방법은 바로 스토리보드에서 테이블뷰컨트롤러(UITableViewController)를 이용해서 만드는 겁니다. 런타임에 테이블뷰컨트롤러는 테이블 뷰를 만들고 델리게이트와 데이터 소스를 자기 자신으로 할당합니다.컬렉션 뷰(UICollectionView)컬렉션 뷰는 테이블 뷰에서 할 수 있는 모든 것을 할 수 있습니다. 섹션을 가질 수 있고, 인덱스패스 값을 이용해서 셀을 구별합니다. 이 셀들은 컬렉션 뷰 셀(UICollectionViewCell)의 서브 클래스이며 데이터 소스(UICollectionViewDataSource)와 델리게이트(UICollectionViewDelegate)가 필요합니다. 셀을 추가, 삭제, 재정렬하는 기능도 구현할 수 있습니다. 그렇다면 컬렉션 뷰와 테이블 뷰를 구분하는 특징은 무엇일까요? 바로 레이아웃입니다. 컬렉션 뷰는 여러 개의 열과 행으로 셀을 표현할 수 있습니다. 예를 들어, 그리드(grid) 형태로 아이템의 목록을 보여줄 수 있습니다. 그래서 수직 스크롤뿐만 아니라 수평 스크롤도 할 수 있습니다.스토리보드에서 디자인한 테이블 뷰 셀과 컬렉션 뷰 셀위 스크린샷에서 테이블 뷰와 컬렉션 뷰의 가장 큰 차이는 바로 셀입니다. 테이블 뷰에서는 하나의 열에 여러 행을 표시하는 형식이기 때문에, 셀의 모습을 행에 맞춰서 디자인합니다. 하지만 컬렉션 뷰는 열과 행을 만들 수 있기 때문에, 꼭 행의 모습이 아니더라도 다양한 모습으로 셀을 디자인할 수 있습니다. 컬렉션 뷰 셀의 가장 큰 특징이기도 하죠. 위처럼 셀을 디자인하고 앱을 실행하면 아래의 화면이 나타납니다.테이블 뷰와 컬렉션 뷰의 앱 화면 차이또한 컬렉션 뷰는 레이아웃 객체가 있습니다. 기존에 제공하는 flow layout을 사용해도 괜찮지만, 본인이 원하는 레이아웃 모양을 custom layout을 만들어서 사용합니다. 이를 담당하는 프로토콜은 UICollectionViewDelegateFlowLayout 입니다.func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, sizeForItemAt indexPath: IndexPath) -> CGSize {         let fullWidth = collectionView.frame.size.width - (self.CGFLOAT_INSET_WIDTH * 3) - (self.CGFLOAT_ITEMSPACING * 3)         let width = fullWidth/3         return CGSize(width: width, height: width + self.CGFLOAT_HEIGHT_ATTRACTIONCELL_DEFAULT)     }         func collectionView(_ collectionView: UICollectionView, layout collectionViewLayout: UICollectionViewLayout, insetForSectionAt section: Int) -> UIEdgeInsets {         return UIEdgeInsetsMake(self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH, self.CGFLOAT_LINESPACING_VERTICAL, self.CGFLOAT_INSET_WIDTH)     } 위 소스에서 collectionView(:layout:sizeForItemAt:) 메소드는 해당하는 셀의 사이즈를 설정하고, collectionView(:layout:insetForSectionAt:) 메소드는 섹션 안에 margin을 설정합니다.여러 모양의 셀을 이루어 하나의 뷰 화면을 구현할 수도 있습니다. 섹션마다 셀을 만들어 각각 다른 모습의 셀을 설정하고, 한 화면에 다양한 모습의 셀을 가진 뷰를 만드는 것입니다. 예를 들어, 헤더, 메뉴, 본문, 푸터 각각 셀을 만들어서 원하는 모양으로 만들고, 하나의 뷰 컨트롤러에 셀을 조합해서 한 화면에 나타나게 할 수 있습니다. 이 방법을 사용하면 자주 사용하는 셀을 재활용할 수 있습니다. 똑같은 헤더와 푸터 셀을 여러 번 만들지 않고 기존의 셀을 재활용하면 시간도 절약하고, 훨씬 깔끔한 소스를 만들 수 있을 겁니다.브랜디 앱 스크린샷 일부위의 스크린샷처럼 여러 화면에서 보여줘야 할 똑같은 뷰가 있을 때, 셀 xib 파일을 만들고 컬렉션 뷰에서 셀을 섹션별로 설정 및 사용하면 재활용하기 좋습니다.Conclusion지금까지 테이블 뷰와 컬렉션 뷰의 특징들을 살펴봤습니다. 한마디로 정리하면 테이블 뷰는 가장 간단한 목록을 만들 수 있습니다. 컬렉션 뷰는 다양한 모습의 목록으로 커스터마이징(Customizing)할 수 있습니다.그렇다면 우리는 어떤 것을 선택해야 할까요? 구현할 목록이 얼마나 복잡한지에 따라 선택은 달라집니다. 테이블 뷰는 간단하고 보편적인 목록을 만듭니다. 반면에 컬렉션 뷰는 특정한 모습의 목록을 만들 수 있습니다. 그래서 테이블 뷰는 목록이 간단하고 디자인 변경이 없을 때만 사용하길 권장합니다. 하지만 나중에 디자인이 바뀔 수도 있다면 컬렉션 뷰를 사용하는게 더 좋겠죠.Simple is the best! 간단하게 구현할 수 있는 건 테이블 뷰를 사용합시다. 테이블 뷰에서 구현하기 힘들다면 컬렉션 뷰를 이용해 개성 있는 목록을 마음껏 만들어봅시다!참고UITableView - UIKit | Apple Developer DocumentationUICollectionView - UIKit | Apple Developer Documentation 글김주희 사원 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/