생각보다 훨씬 많은 분들이 '톤앤매너' 라는 말을 쓰고 있더라구요. 컨셉이란 말도 왕창 쓰고 있구요. 그런데 도대체 그게 정확히 뭔지 아는 분은 굉장히 드물었어요. 그래서 오늘은 이걸 좀 알아보려구 해욤. 톤을 살펴볼까요. 파스텔톤, 비비드톤, 팬톤(?), 화이트톤 등등... 이런톤 저런톤이 많아요. 톤은 색과 밝기를 의미해요. 어려운 말로 색채와 명암이죠. 어떤 색을 쓰는가.색이 진한가 연한가색이 밝은가 어두운가이걸 결정하는게 톤이예요. 매너를 살펴볼까요. 매너는 화풍이나 스타일을 의미해요. 몽유도원도를 그린 안견씨는 이곽파화풍의 영향을 받았어요. 침식된 흙산을 좋아하고, 선이 끊김없이 이어지는 느낌, 산의 아랫부분이 밝은 형태의 그림이죠. 고흐는 밀레와 램브란트 스타일의 밝디밝은 인상주의 화풍을 어둡게 변형시켰어요. 또한 곡선을 강하게 그리고 신기방기한 원근을 사용하죠. 이렇듯 사람이 만들어내는 모든 것에는 일정한 흐름이란게 있어요. 100사람이 만들면 100개의 서로 다른 작품이 나오겠지만 유심히 보면 4,5정도의 카테고리화 시킬 수 있거든요. 인간의 창의력은 완전히 새로운 걸 만들어내는 것이 아니라, A와 B를 섞어 새로운 C를 만드는 것과 같습니당. 디자인도 마찬가지예요. 세리프폰트를 활용한 정적이고 감성적인 느낌을 만들수도 있고, 여백을 늘리고 강직한 폰트로 고급스러움을 나타낼 수도 있어요. 아주 가는 획을 이용해서 날카롭거나 전문적인 느낌을 줄 수도 있고, 두껍고 둥근 선&폰트를 활용하여 통통한 아기돼지 마냥 귀여운느낌을 낼 수도 있어요.사람들은 어떤 대상에 부여하고 있는 메타포(=은유)가 있기때문에 가능한 일이지요.  마동석씨가 나오면 아 팔뚝이 있겠구나...드웨인 존슨이 나오면 가족을 구하겠구나...라는 고유한 메타포 말이예요. 화풍은 이렇듯 몇 개의 요소나 기법으로 메시지나 성격을 만들어내는 것을 의미해요. 고유한 아이덴티티는 물론이구요.컨셉을 알아볼께요.컨셉의 정의는 수도 없지만 어쨌든 중요한 건 '관통' 이예요. 톤과 매너가 디자인, 말투, 태도 등에 대한 얘기였다면 컨셉은 그 각각의 요소를 하나로 묶는 실과 같죠. 왜 그런 톤과 매너를 만드는가? 에 대한 근거이기도 하구요. 그러니 컨셉이 먼저 잡히고 톤앤매너가 나오는 게 순서상 맞아요.실상은 로고와 색깔을 잡고 나중에 의미부여를 하는 경우가 많지만요. 하지만 이게 틀렸다고만 볼 순 없을 것 같아요. 이론상으로야 컨셉 다음이 톤앤매너이지만, 현실적으론 컨셉은 그냥 '생각' 일 뿐이예요. 눈에 보이지 않으면 그 생각의 헛점이나 오류를 파악할 수 없죠. 또 시장성도!그래서 실상 눈으로 보이는 톤앤매너를 보고서야 컨셉 재정리가 들어가는 경우도 상당히 많답니다. 무조건 그건 이빨까는거고 그냥 의미부여일 뿐이야! 라고 말할 순 없죠. 다만 눈으로 나온 톤앤매너가 뭔가 조금 이상하다는 쌔한 느낌이 있는데도 무시하고 그냥 밀어붙여선 안되요.쌔하면 다시 해야해요.안쌔해도 다시 봐야해요. 컨셉 잡는 방법이 뭐 정해져있겠습니까. 사실 의식의 흐름대로 아무말을 하다보면 잡히는 경우도 있고, 브레인스토밍을 할 때도 있고 마인드맵을 할 때도 있고, 뒤통수에 총구를 겨눌수도 있고, 게임을 할 수도, 제비뽑기로 정할 수도 있는 것이죠.여기선 그냥 제가 컨셉 잡는 법을 말해보려고 해요.1. 데카르트는 천재예요.천장에 붙은 파리였던가 방충망에 붙은 파리였던가... 데카르트씨는 파리를 보고 사분면의 개념을 생각했다고 해요. 덕분에 우린 함수를 6년내내 배워야했고 대학에서도 배우고 지금도 쓰고 있고 비즈니스모델 잡을 때도 쓰고 심심하면 쓰고 있죠. 사분면이란 건 참으로 놀라운 도구예요.컨셉도 사분면을 활용하면 짱편해져요.x와 y축의 가로세로 두 선으로 이루어진 4개의 공간으로 이루어져있어요. x의 한 점과 y의 한 점이 만나 이루는 특정한 공간이 우리의 영역인 셈이죠.x는 가로선이예요. 0을 기준으로 +방향은 미래적의미를 담고있어요. 고객에게 줄 수 있는 가치가 미래적인 경우. P2P대출, 다이어트앱, 투자서비스, 캐시슬라이드, 영어공부 등등... 뭔가가 누적되고 쌓여야 그 가치가 온전해지는 경우죠.x축의 -방향은 과거의 의미를 담고 있어요. 누적과 저장을 통해 가치가 형성되는 경우죠. 커리어정리 서비스, 일기, 사진큐레이션, 데이터기반 무슨 서비스, 추억팔이 게임, 리뷰서비스 등등..이 이런 종류예요. 과거를 돌아보게 만들고, 과거로부터 누적된 것들이 현재에 도움을 주는 경우예요. y축의 +방향은 '있으면 더 좋은 거!' 예요. 현재도 충분히 괜찮은데 있으면 더더더더 좋은 어떤 것들. 대부분의 비즈니스모델이 이쪽에 속하는 것 같아요. 당신의 서비스가 생기기 전에도 사람들은 잘 지냈거든요. 하지만 생겨서 더 편리해진 경우죠.y축의 -방향은 '현재의 문제를 해결하는 것' 이예요. 상담서비스, 치유, 명상, 저소득층을 위한 복지정보 서비스 라던가 사회적기업이 추구하는 사회문제 해결에 관련한 서비스 일체를 의미해요. 현재 고객들의 상황이 0보다 아래여서 그걸 정상화시키기 위해 만든 것들이죠.y축의 +,- 구분이 좀 애매하긴 해요. 기준은 '소비자가 불편을 인지하고 있었는가?'  '그 불편이 생활이나 건강 전반에 해로운 영향을 끼치고 있었는가?'로 구분하는 편이예요. YES면 마이너스영역, NO면 플러스 영역이예요.2. 운동/방향성을 파악해볼 차례예요.사업은 사업자와 소비자가 있어야 가능해요. 누가 누군가에게 무언갈 주고받는 행위죠. 때문에 방향성과 운동성이라는게 있어요. 방향성은 이런거죠.짐캐리(부산역에 있는 짐보관서비스 스타트업) 처럼 소비자에게서 무언갈 받아서 저장하는 형태일수도 있고, 대부분의 커머스처럼 상품이나 서비스를 직접 제공하는 방향일수도 있어요. 가치를 달성하기 위해 누가 누구에게 다가가야 하는가? 가 이슈가 되요.운동성은 이런거예요.가치를 달성하기 위해 땀과 노력과 오랜시간 지속성이 필요한 것인가? 아니면 그냥 가만히 놔두기만 하면 되는건가? 라는 거죠. 이를테면 영어공부 앱은 운동성이 겁나 높은 서비스예요. 지속적으로 꾸준히 말하고 듣고 누르고 해야 소비자가 제 가치를 받을 수 있죠.하지만 물품보관서비스는 한번의 맡김만 있으면 돼요. 나머지는 사업자의 몫이죠. 때문에 운동성은 소비자, 사업자 각각의 양으로 판단할 수 있어요.3. 관계를 파악해요.우리와 소비자는 어떤 관계인지 파악해봐요. 아빠? 엄마? 형? 동생? 친구? 지인? 전문가? 해결사? 운동장? 땅과 잔디? 햇빛과 식물? 엔진과 엔진오일? 악어와 악어새? 등등... 특정한 관계가 잡혀야 그 관계 특유의 말투가 잡히고 성격이 부여되거든요.4. 문장으로 만들어요.애프터모멘트는 지금까지 당신이 쌓아놓은 생각과 어지러운 것들을 챡챡 정리해요. 하지만 제가 없다고 해서 사업체가 망하진 않아요. 잘 살아왔어요. 저는 더 큰 도움을 드리는 거예요. 그러니 저는 2사분면에 위치하고 있어요.방향성은 '제가 당신께 가는' 방향이예요. 제가 제안하고 직접 제작하고 제공하는 형태죠. 운동성은 둘 다 큰 편이예요. 소비자도 이것저것 많은 고민을 해야하죠. 물론 제가 좀 더 크긴 하겠지만요.저는 치우는 사람이예요....(!!!?) 집요하게 옆에서 잔소리를 하기도 하고 샤라랑해서 뭔갈 바꿔놓거나 치우기도 해요. 엄마가 늘 그러셨어요. 어지르는 사람 따로있고 치우는 사람 따로있다고. 네 저는 그 후자를 담당하고 있어요. 그래서 클라이언트님에게 발 좀 들어봐, 저기 비켜보라고 하기도 하고 등짝스매싱이나 이노무자식! 이노무자식!!.. 을 하기도....(그러진 않아요.) 5. 단어를 뽑아요.정리, 활발함, 다가감, 치우기, 보여주기, 드러내기, 따뜻함, 대화, 인정, 격려, 도전, 새로운 시도 등등... 치우는 사람이 지닌 여러개의 단어들이 있어요. 이 중 가장 맘에 드는 것을 몇 개 추려서 정리해요.6. 색을 정해요.제 로고색인 자색고구마 오사쯔 색깔은 노란색과 보라색으로 이루어져 있어요. 노란색이 뜻하는건 치유고 보라색은 매력이예요. 널브러진 걸 잘 정리해서 매력적으로 만들어요! 라는 뜻이예요. 물론 아무도 몰라요. 저만 알고있죠. 그럼 된 거 아닐까요. 사실 이런 과정은 누가 알아주길 바라서가 아니고 내 생각정리를 위해 필요한 과정이니까요.7. 매너를 정해요.초기엔 이렇게 가려고 했었죠.원랜 되게 가늘고 날카로운 로고로 가려고 했었어요. 그런데 그런 식이 되다보니 이제 사람들이 저랑 안어울린다는 말을 많이 하더라구요. 사실 저도 그렇게 전문성있게 막 정장입고 차키를 책상 옆에 두는 그런 스타일이 아닌지라 좀 어색하기도 했구요. 게다가 브런치엔 이렇게 아무말을 지껄이는데 막상 만나면 세상 진지해봐요. 물론 매력터지기도 하겠지만 한편으론 이질감이 장난 아닐거예요. 그래서 바꾸었어요.그래서 그냥 둥글고 두껍두껍하게 제 성격대로 모양새를 살렸어요. 전체적인 패턴도 '물들다'의 의미를 지닌 곡선과 잉크방울 모양이 주를 이루고 있어요.너무 스압이 길어지니 줄이도록 할께요. 줄이기 전에 3가지 중요한 사항을 말씀드리고 떠나도록 하겠습니다. ㅎㅎㅎ 이번이 마지막 위클리라서 많은 걸 얘기하고 싶었나봐요. 1. 문장이 구성되야 디자인이 나오는 거예요.디자인의 시작은 논리예요. 사고의 과정은 명쾌하고 정확해야 해요. 군더더기나 순환오류 없이 깔끔하게 정리된 문장이 있어야 제대로 된 디자인이 나오는 법이예요. 2. 디자인이 나와야 문장이 다시 보여요.그러나 어느 누구도 한 번에 완벽한 문장을 만들 수 없어요. 디자인이 나와서 눈으로 직접봐야 '아....이게 글러먹은 거였구나...' 라는 몸소 느낄 수 있어요. 그러니 완벽한 걸 만들어서 한번에 끝내려고 하지말고 계속 반복하고 수정하면서 다듬어 나가세요.3. 문장이든 디자인이든 혼자만 박수치지말고 공유하세요.이 과정은 강압적이면 안되요. 디자이너와 기획자, 마케터, 인턴까지 모두가 알고 있어야 하고 서로의 의견을 낼 수 있어야 해요. 물론 내가 꽂힌 디자인에 누가 반박하는게 유쾌하진 않지만 그럴거면 1인사업체를 하셔야겠죠?그동안 기이이이인 글을 읽어주셔서 매우 감사했습니다 :) 이번 위클리는 '디자이너 사용설명서' 라는 제 첫 책이 나와서 그 내용을 바탕으로 적은 것이긴 하지만, 책에 나온 내용이 똑같이 들어가있진 않아요. 브런치에선 브런치의 말투와 내용이 있으니까요. 책 못지 않게 이번 위클리도 작은 도움이 되었다면 오히려 제가 감사하고 뿌듯할 일입니다.애정해주셔서 감사하고, 못다한 이야기와 나머지 주저리는 '삶분의일' 매거진에서 또 계에에속 하도록 하겠습니다!!!~~ 빠이.안녕히들.

(출처: 미드 마법사 멀린 중에서)필자는 멘토라던가 컨설턴트가 아니라그냥 수많은 창업자 중 한 명일 뿐이다.몇 번 창업 해보다가금방 그만두고그걸 경력 삼아서훈수놀이하는소수의 자질 없는 창업 컨설턴트라던가,누구에게나 공개 되어있는정부지원책이나 인프라, 지원스케쥴 같은 걸컨트롤 C+ 컨트롤 V해서두 세시간 읽어주고컨설팅 수수료 챙겨가는일부 비양심적인 멘토들때문에좋은 선생님들이 설 자리를 잃고,좋은 멘토들을 만날 기회가 더 줄어들고,많은 창업자들이 더 방황한다.어떤 분이 그런 사람들을 일컬어"좀비멘토"라고 부르던데...딱 그 표현이 맞는듯하다.좀비기업, 좀비멘토좀비가 넘쳐나는 세상이다.어쨋든...멘토에 대한 선입견이 생길까봐노파심에 글을 남긴다.기본적으로 멘토링은 창업자에게유익한 선택보조 Tool(도구)이다.무슨 결정이든 선택은오롯이 대표자의 몫이겠지만우리의 인사이트는 생각만큼 그리 넓지않다.특히 개발자/연구자 출신이거나제품/서비스 영역에 좀 문외한인 컨셉형 기획자의 경우,매우 빈약한 인사이트와 사업에 대한좁은 편견 덩어리를 가지고 있다.동료들 중 현명한 멀린(아더왕의 스승)이있다면 모를까보통은 동료들도 창업자와 비슷하게생각하고, 원하는대로 보는 경향이 있다.그러다보니외부의 전문적인 식견을 가진 멘토들이 필요하다.이해관계가 없으니쓴소리도 거침없이 해 주고창업자 그룹이 몰랐던가, 애써 외면중인핵심 문제를 들춰내 줄 수 있는 멘토는선생님으로 모셔야 한다.(출처: 뭉크의 절규, 혼란스럽다)종편 방송을 보다가참 웃긴 모습을 보았다.전문가 패널로 등장한 어떤 분이A 방송채널에서는 "심리전문가"로 나와서 주절거리다가B 방송채널에서는 "정치평론가"라는 타이틀로 주절거린다.이러다 스포츠 채널까지 나와서"축구해설가"로 나오는건 아닌지 모르겠다.스타트업 관련 글을 보고 공감가서좀 찾아보니 하는 일이 창업컨설턴트란다.뭐 그럴수도 있지.창업컨설턴트라는 분야를 스타트업하는거겠지.근데 더 찾아보니까...참 애매모호하게상업적인 홍보인 거 같기도하고,친절하게 블로그나 홈페이지를 찾아갈 수 있도록실마리를 남겨두었다.뭐 그럴수도 있지.글을 쓰다보면, 의도하지 않게 드러날 수도 있지.다 읽고 나니까창업자의 경험담이라던가노하우라던가 공감 스토리라기 보다는컨설팅을 받아야겠다는 생각이 불현듯 든다.뭐 그럴수도 있지.요즘 내가 예민한가보다.다시 본론으로 돌아와서,멘토를 만나는 것은 쉽다면 쉽고,어렵다면 어려운 일이다.1. 강연이나 모임에서 만날 수 있는 멘토일단 강연이나 네트워크데이, 창업자 파티 같은 모임에들락거리면 많은 유명한 멘토님들을 마주 할 기회가 있다.대부분 매우 바쁜 분들이라명함 주고 받고 돌아서면, 연락이 지속되지 않는다.정말 도움받고 싶어서 멘토로 모시고 싶다면,엄청나게 매달리고, 귀찮게 하고, 꾸준히 괴롭혀야 가능하다.그리고 강연이나 모임에서 만난 멘토라고다 뛰어난 멘토는 아니다.어떤 분들은인맥이나 지인 또는 한두번의 유명세 때문에그 자리에 올라온 분들도 있기 때문이다.2. 현업 멘토현업에서 종사한 경력자 또는 전직자, 현직자만큼강력한 멘토는 드물다.물론 전직자의 경우, 더 얻을 수 있는 게 많다.(완전 공포판으로, 무시무시한 현실을 깨닫게 해 줄 것이다.)때로는 멘토이면서, 파트너를 얻을 수도 있다.일거양득이겠지만,한편으로는 비용부담이라던가기존 멤버와의 교통정리로 머리가 아프겠지만이런 멘토를 멤버로 얻을 수 있다면,해볼만한 딜이 아닐까?하지만,반대로 조심할 것은패배주의가 전염될 수 있다는 점이라던가,기존에 실패한 원인을 그대로 답습하게 되는 경우를주의해야한다.또한,동료로 받아들였는데중간에 아이템을 가지고 나가서다시 창업하는 사례도 있더라.현업 경험이 있다보니,아이템 가로채서 더 업그레이드 된 버전으로더 빨리 출시하는 못 된 사람도 있다.뭐 하나하나 다 의심하면 한도 끝도 없지만,그렇기 때문에 여러번 만나보고,심사숙고하여 결정해야 한다.3. 인간이 아닌 멘토바로 인터넷과 책!필자가 가장 자주 찾는 멘토가바로 도서관이나 서점의 책이며, 인터넷이다.전문 기술에 대한 멘토링도,창업자가 갖추지 못한 능력에 대한 멘토링도뭐든 가능한 전지전능한 멘토랄까?그리고 일단 뒤통수치거나일일이 스케쥴 잡거나 모셔오는 수고로움이 없다.(출처: 구글, 외로움)4. 때로는 감성의 멘토창업자는 외롭다.꼭 사업에 관한 멘토가 아니라삭막해져가는 정신에,그냥 하루 정도만 내 편이 되어줄 멘토가 필요하다.필자는 토끼같은 아내와 더 토끼같은 아이가 있어가능하다고 말하고 싶지만....사실은 다른 영역, 다른 분야지만같은처지의 창업자끼리 서로 멘토가 되어주는게더 편하고, 힘이 되더라.(여보~! 미안해요. 하지만 이게 진실이예요)5. 업무 최고의 멘토는 동료(직원)회사가 굴러가는거에 가장 민감하고 센서티브한 사람은 직원이다.사실 대표자는 이리저리 불려가고, 돌아다니고 하다보니회사에서 보내는 시간보다 바깥활동이 더 많을 수 있다.그런데...회사의 위험신호가 숫자로 환산되어대표에게 도달했을때는 이미 늦은 타이밍이다.그 숫자만큼 비용과 시간과 인력을 투입해서수정해나가야 하기에 스타트업에게는 치명적이다.하지만 실시간으로 가장 빨리 알아낼 타이밍은직원들을 통해 알 수 있다.회사의 분위기, 업무 과정 상의 사소한 트러블 등에 대해자신도 모르게 Daily check하고 모니터링하는 사람들이바로 직원들이다.다른 건 몰라도,직원들을 대할 때, 좋은 멘토 선생님 모시듯이경청해야 한다6. 고객, 협력사, 전문가 멘토링약간 식상할 내용이겠지만,"고객이 최고의 멘토입니다."란 말은 굳이 설명 안해도 되겠지?협력사의 조언이나 불만도,법무사나 회계사, 변리사 등 외주의뢰를 통해연계되어진 전문가 집단의 코멘트들도 좋은 멘토라는당연한 이야기.7. 그 외의 멘토필자의 은사 중에 대학교수님이 계시다.내가 졸업한 학교 교수님은 아니지만,어째저째 이쪽 일을 하면서 가까워지고,나와는 전혀 다른 인사이트로 재해석 해 주는 분이다.업무상 많은 대학교수를 알고 있지만주로 기술적인 멘토링이었다.하지만, 요즘은 다양한 분야의 교수들과인프라를 통해 여지껏 생각치도 못한콜라보 아이디어 컨셉이 되어간다.사업을 하다보면,1년에도 수 십번씩 발표자의 위치에서심사를 받곤 한다.그때, 가능하면 심사하신 분들을 기억하라.그리고 향후에 만나 멘토링을 받는 것도 좋은 방법이다.정말 수수료를 줘가면서컨설팅을 받아야할 상황은 따로 있다.그 때는 정말 외부에서 악역을 맡아줘야할 상황이거나매우 민감한 법률적, 제도적 규제를 피하기 위해서라던가시장/고객조사 등의 전문적인 영역에서 필요하다.하지만 찾아보면,우리가 소소하게 또는 상시로멘토링 받을 수 있는 멘토들이 즐비하다.다만,매칭이 안되고 있을 뿐이고,우리는 매칭을 위한최소한의 노력조차 안하고 있는 것 뿐이다.내가 좋아하는 약간 판타지적인아더왕의 이야기를 억지로 끼워 맞춰보자면,아더는 유약하고 풋내나는 15세 꼬맹이에 불과했다.하지만 멀린이라는 스승의 도움으로 그는 왕이 되었다고 한다.아더왕의 전설에는 엑스칼리버라는 칼을 뽑아 왕이 되었다고 하지만...사실 그 칼은 상징일 뿐이다. 절대로 칼이 왕을 만들어주지 않는다.오히려 아더왕은멀린의 조언과 가르침,평등한 발언권을 가진 원탁의 기사들과,평화와 안전이라는 서비스에 신뢰로 지불하는 백성 고객들(?)로구성된 스타트업 이야기랄까?엑스칼리버란 아이템은 단지 거들뿐!나는 아직도 더 많은 멀린을 찾고 있다.#클린그린 #스타트업 #스타트업창업 #초기창업 #조언 #인사이트 #구루 #스승 #멀린

영업에 대한 인식은 저마다 다릅니다.  하도 어렸을 때부터, 보험판매, 방문판매 이런 건 별로 멋진 직업이 아니라고 세뇌 되어서 인걸까요?  지금은 그게 뭐 어때서? 하지만, 저도 불과 몇년 전까지만 하더라도, 영업은 저랑은 관계 없는, 관심도 없고, 할줄도 모르고, 그런건 영업 사원에게 시켜야 한다는 고정관념이 있었습니다.  워낙 사업초기일때라, 나는 고결하기(?) 때문에 그런 일은 할 수 없다는 자존심이 남아있었을 때였습니다. 영업이란 뭘까요? 네이버 사전검색을 해보니, 너무 말이 어렵습니다.  패스. 내 서비스/상품을 누군가에게 적극적으로 또는 간접적으로 권유하는 일 아닐까요?  그러려면 영업할 상대가 있어야 합니다.  막막하니, 당장 생각나는 건 만만한 가족서부터 시작해서, 불알 친구들, 예전 직장동료들, 대학동기, 모임에서 만난 사람들, 친구의 친구들...인맥에 한계가 보이기 시작합니다. 여기서 제일 저지르기 쉬운 실수가, 영업 대상이 누군지 모르니, 아니 찾기가 어려우니, 일단 홍보를 하고 보자-라는 생각입니다. 먼저, 영업에 대한 인식 변화가 중요합니다. '아니 대표가 발로 뛰고, 어떻게 영업하란 말이냐?'그런 생각 드실 수 있어요.  맞는 말입니다.  어느 정도 자리를 잡았다면, 사장이 직접 여기저기 가방 메고 돌방하는게 우스워질 수 있습니다.  그러나, 아직 사업초기라면 이제 막 성장기에 들어가는 회사라면, 아직은 사장님이 영업을 직접 챙기셔야 합니다.  왜냐, 영업만 하고 끝이 아니라, 그 고객이 만족할 수 있도록 단골관리까지 이어져야 하고, 그 고객이 재구매까지 하기까지가 사업초기 성공을 말해주기 때문입니다.  수족 같이 말듣는 직원이 있지 않는 한, 초기에는 이 풀 프로세스를 사장님이 직접 챙겨야 합니다.   그리고 또 직원들에게 너도 이렇게 영업을 해와라- 지시할 때, '자기도 못하는 거 나한테 시켜'라는 뒷담화를 한다거나, 이건 이래서 안된다, 이런 영업은 안된다-라는 주장을 쉽게 말하지 못합니다. 대표도 발품 팔아 영업하는 데, 직원은 해본 적 없다, 자신 없다며 편히 일하면 누가 직원이고 누가 사장인가요.   어떤 업종이든 어떤 서비스이든, 고객은 정말 뻔합니다.  신규 아니면 기존 고객입니다.  신규고객을 발굴하는 것도 영업이지만, 기존 고객을 잘 관리하여 단골관리하는 것 또한 영업입니다.  또, 창업을 했다면, 지금 막 사업자등록증이 나왔다면 그 순간부터 만나는 모든 사람들이 내 잠재고객이 됩니다.  재구매 즉, 고객만족까지 염두하면서 영업을 하셔야 합니다.  단순히 (사이트라면) 방문자수, 매출증가액, 고객수 수치도 중요하지만, 제일 중요한 건 재구매율입니다.   투자자가 제일 관심 있게 보는 지표 중의 하나입니다. 재구매는 고객이 만족한다는 증거이고, 그게 입소문, 진짜 마케팅의 동력이 됩니다.   아무리 영화 제작사 홍보대행사가 수십억을 들여서 마케팅을 해도, 결국엔 "야 이번주에 뭐 재밌는 영화 없냐?' '야 ~~영화 이거 진짜 재밌어' 하는 입소문 마케팅이 진짜입니다.  여러분의 서비스/제품도, 여러분을 대신해서 직접 그걸 사용해본 고객이 그게 너무 좋아서 자기 친구들에게 침 튀기며, 마치 신식 정보를 알아서 자랑을 하듯, 얘기를 하게 끔 해야 합니다.  그렇게 한 사람 두사람 고객이 늘고 그들이 반복적으로 찾아오면서 매출은 순익분기점을 넘고, 이익이 발생하고 그러다 대박이라고 할 수 있는 시점에 다를 수 있게 됩니다. 셀프 질문사항0. 내 서비스/제품에 대한 확신이 있는지?1. 누구를 대상으로 영업해야 하는지 명확히 알고 있다?2. 영업에 필요한 준비물(브로슈어, 영업메일, 명함, 회사소개서PPT, 리플릿, 홈페이지, 웹 URL 등)3. 영업-전화상담-미팅-계약 프로세스화, 시스템화가 되어있는가?4. 나만큼 해줄 사람이 또 있는가? (직원 교육하기) #넷뱅 #업무프로세스 #업무환경 #창업자 #CEO #CEO가하는일

디자인 오더를 받을 때 디자이너님들께서 생각하셔야 하는 부분이 있습니다. 대개 클라이언트가 '이런 느낌으로 해주세요..' 라고 하는 건 대부분 뻥입니다!여기서 뻥이라고 함은, 의도적인 거짓말이 아니예요. 사실 사람들은 무엇을 어떻게 바꾸고싶은지 잘 모르는 경우가 많거든요. 그래서 자신이 원하는 것을 표현하는 과정에서 자꾸 어긋난 포인트를 잡게 되는 거예요. 이 때 본래의 취지와 니즈에서 벗어난 단어와 추상적인 표현들이 입밖으로 나오게 되죠. 대부분 이 표현들은 지나치게 뭉뚱그려져 있거나, 상징/연상되어 있는 경우가 많습니다. 생각과 표현의 괴리로 인한 '거리감' 이라고 말하는 편이 적절하겠네요.   인사이드아웃을 보신분들은 잠시 기억을 되새겨 볼까요. 기쁨이와 빙봉, 슬픔이가 무의식의 세계로 떨어진 이후 잠깐 '추상화'의 과정을 거칩니다. 그들은 점점 2차원 평면이 되었다가, 도형이 되고, 이내 본래의 형체를 알아보기 힘들정도로 단순해지기 시작합니다.그렇죠 바로 이 과정입니다. 대부분 사람들은 어떠한 기억을 구체적인 정보보단 이처럼 추상화과정을 거쳐 단순하게 기억합니다. 이를테면 국물을 입에 넣는 순간 용이 승천하고 눈앞에 美味가 떠올랐다고 해볼께요. 사실 그 맛을 느낄 때는 단짠, 얼큰, 시원, 들깨의 고소함, 육수의 진함, 향기, 빛깔, 식감 등등 온갖 다양한 정보들이 미뢰를 통해 뇌에 전해졌을 겁니다. 하지만, 1시간이 지난 후 머리가 기억하는 정보는 그냥 '맛있다.' 일 뿐이죠. 조금 더 정확하게 기억하자면 '존나 맛있다.' 정도랄까요.반대로 기억의 인출과정도 이 추상화된 개념을 꺼내는데에서 시작합니다. 사람은 구체적인 정보를 통째로 꺼내는 것이 아니라, 추상적인 단어를 하나 꺼낸 다음 그 위에 정보를 덧붙이기 시작합니다. 문제는 바로 이 과정에서 과연 올바른 정보들이 덧붙느냐...? 하는 것이죠.세련되면서도 빈티지한 느낌..이란 이상한 표현이 나오는 것은 이러한 정보의 전후관계에서 비롯됩니다. 뭔가 세련된 느낌이 되었으면 좋겠는데, 뒤에 딸려오는 정보들은 또 뭔가 베네딕트 컴버배치가 주연일 것 같은 영국 수사물의 고전적이고 클래식 양식이 합쳐졌으면 하는 거죠. 사람들은 생각보다 표현에 많은 단어를 쓰는 것에 익숙하지 않습니다. 우리는 살아가면서 사용하는 단어만 계속 사용하기 때문이죠. 우리가 쓰는 단어가 시각정보를 모두 표현하기에 부족하다보니 그냥 이것도 빈티지고 저것도 빈티지고 너도 빈티지 나도 빈티지가 되는 겁니다. 그냥 대강 비슷한 단어를 가져다가 붙이는거죠.내 생각 나도 몰라.클라이언트가 말한 빈티지를 '빈티지'라는 단어 그대로 해석하면 우주적혼란과 역사적인 고통을 경험하게 됩니다. 도대체 저 사람의 머릿속에 무엇이 떠올랐기에 그걸 빈티지로 퉁쳤을까? 를 바라보는 것이 먼저죠.도대체 저 사람의 머릿속에 무엇이 떠올랐기에 그걸 빈티지로 퉁쳤을까?를 바라보는 것이 먼저죠. 디자인 오더에는 유독 '~한 느낌' 이란 단어가 많이 쓰입니다. 그런 느낌을 주려고, 이런 느낌을 내주세요, 저 느낌처럼 가주세요... 등등. 추상적인 단어는 여러 감각들이 느꼈던 정보를 한꺼번에 담고 있습니다. 그런데 그걸 시각정보로 국한시키려니, 머리가 아파지기 시작하죠.예를 들어 내가 어제 갔던 그 예쁜 카페의 느낌을 포스터에 담고 싶은 거예요. 카페에서의 경험은 향기, 행동, 맛, 분위기, 소음, 느낌, 조명, 인테리어 등등 굉장히 다양한 감각의 집합입니다. 그런데 그걸 시각 하나로 압축시키려고 하니 말이 막히고 어려워집니다. 적당한 단어도 생각나지 않죠. 자세히 설명하기도 힘들구요. 그냥 대충 '감성적인 느낌' 이라고 축약해버리는 거예요. 문제는 정작 '감성적인 느낌이 뭔데요?' 라고 반문하면 또 그게 뭔진 잘 모르겠다는 것이죠. 이처럼, 사람은 자신의 경험을 언어로 설명하는 데 익숙하지 않습니다. 생각보다 훨씬 더 많이요. 훨씬!! 훨어어어어얼씨니이이인!!!!말로 표현을 못하겠지만 그런 느낌... '느낌' 이란 건 굉장히 구체적인 어떤 정보를 꺼내기위한 큰 그릇과도 같습니다. 문제는 그 정보가 나오기 전 그릇부터 나온다는 점이죠. 심지어 가끔 엉뚱한 그릇이 튀어나오면, 원래 꺼내려던 정보가 아닌 그릇에 맞는 정보가 느닷없이 등장하기도 합니다. 오늘은 그 그릇과 정보에 대해 알아보도록 합시다요.1. 감성적인 느낌명조체폰트와 히끄무레한 파스텔톤 색, 아웃포커싱되어 있는 뭔지 잘 모르겠는 사진들. 흔히 언스플래쉬나 Life of Pix, 또는 얼라우투에 올라올 듯한 사진이 합쳐진 느낌의 디자인을 의미합니다.막 이런 일본스럽고, 세로쓰기가 좀 있는데 명조명조한 느낌에 희뿌연 배경에 피사체 하나 덜렁있는 사진과 막 그런 것들있잖아요. 감성적인 느낌은 밝은 톤과 어두운 톤이 있는데, 클라이언트에게 위와 같은 밝은 톤 감성레퍼런스와이런 어두운 톤의 감성레퍼런스가 있습니다. 흔히 감성적이다...라고 하는 건 '정적인' 느낌을 많이 의미해요. 뭔가 카만히 바라보며 한떨기 눈물이 흐를 것 같은 감정의 여백과 임을 향한 그리움이 느껴지는 그윽한 느낌을 원하는 거죠. 그러니 뭔가 사람이 서있는 사진이나, 풍경사진, 사물 하나만 클로즈업 사진을 활용하시고, 명조체와 세로쓰기를 사용해보도록 합시다.2. 심플한 느낌심플하게 해달래서 진짜 심플하게 해주면 왜 이렇게 허하냐? 라는 불만이 돌아옵니다. 아니 심플하래 해달래서 심플하게 했는데 이게 왜 이렇게 심플하냐라고 하시면 제가 홍시를 먹은 것도 아니고 도대체 우라질.... 스럽겠지만. 클라이언트의 심플에는 한 가지 말하지 않은 전제조건이 있습니다.'내가 원하는 것을 다 넣으면서' + 심플심플한 느낌이란 건 디자이너가 생각하는 그것과는 다릅니다. 대개 일반인들의 심플은 "정렬이 챡챡 잘되어있는 상태" 를 의미합니다. 10개의 내용이 있다면 오른쪽에 조금, 왼쪽에 조금, 가운데에 조금...이것이 아니라. 그냥 왼쪽에 10개가 다 뭉쳐있는 거죠. 같은 폰트와 같은 모양으로 말이예요. 그리고 그림과 텍스트의 영역이 딱 분리되어 있으면 '아 심플하다' 라고 생각해요. 위 이미지처럼 말이예요. 그냥 정렬과 정돈이 잘 되어있는 상태를 '심플하다.' 라고 표현하는 경우가 많았습니다. 여백이 얼마나 있건 뭐 그건 중요하지 않아요. 내용이 얼마나 복잡하고 카테고리가 많냐 이것도 중요하지 않아요. 사업내용이 200개인 사업체입장에선 100개 내용은 '심플한 것' 이거든요. 그러니 심플의 기준은 상대방의 머릿속이 얼마나 복잡하냐에 따른 상대적인 것입니다. 위계맞춰서 챡챡 내용 왼쪽정렬해주도록 합시당.3. 빈티지한 느낌각진 영어폰트를 큼직하게 쓰고 노란색 톤을 쓰자는 얘깁니다. 가끔 세리프영문폰트를 써달라는 의미이기도 합니다. 그것도 아니라면 크라프트 종이 느낌의 누런 텍스쳐를 넣어봅시다. 노란색톤을 쓸때에는 회색톤을 함께 써주면 치직거리는 골드스타 TV앞에 모여 안테나를 잡고 있던 어릴 적의 향수를 되살릴 수 있습니다.빈티지하지만 세련된 느낌4. 모던한 느낌회색과 더불어 가늘디 가는 Light 폰트를 써달란 얘기입니다. 면과 선중에 선을 활용해보도록 합시다. 가늘디 가는 2px짜리 흰색 선을 써주면 키야아..소리가 나오면서 백두산 박수를 자아낼 수 있습니다.이런느낌으로다가5. 화려한 느낌화려....를 장식하는 건 컬러입니다. 요소보단 색감이 훨씬 강합니다. 오죽하면 무궁화 삼천리 화려강산에서 화려는 산세와 지형지물을 뜻하는게 아니라 오조오억개의 무궁화삼천리를 뜻하는 말 아니겠습니까. 그렇다고 원색을 쓰는 건 싸우자는 얘기이므로, 포인트 컬러와 서브컬러 3개정도를 알록달록하게 배치해보도록 합시다.6. 화려한데 심플한 느낌응용해볼까요. 물론 그냥 들으면 얼간이같은 표현이지만, 곰곰히 생각해봅시다. 화려는 컬러를 다양하게 쓰는걸 말하고, 심플은 잘 정돈된 걸 의미해요. 그럼 다양한 컬러를 쓰면서 정렬선을 잘 정리해달란 얘기입니다. 아래의 그림같은 느낌적인 느낌이랄까요.7. 빈티지한데 모던한 느낌마찬가지로 모르고 들으면 얼뱅충이같은 말이지만, 빈티지는 노란색+회색톤을 써달라는 거고, 모던은 가는 폰트와 선을 써달라는 얘기입니다. 특히 굵은 폰트와 가는 폰트를 잘 섞어서 쓰면 빈티지한테 모던한 비밀의 열쇠를 풀 수 있습니다.빈티지한테 모던함...8. 현대적인 느낌굵은 영문폰트와 강렬한 명암대비로 표현해달라는 그런 얘기입니다. 팝아트느낌을 줘도 좋습니다. 채도와 대비를 찐하게! 빡. 줘보도록 합시다. 특히 빨간색계열에 조금 어둡게시리 버건디한 느낌을 주면 검정과 조합이 기가 맥힙니다. 현대적인 색상이 뭔지 모르겠다 싶으면 요즘 출시되는 스마트폰의 색상을 관찰해봅시다. 뭐 이상하게 울트라 바이올렛이랄지, 코랄핑크랄지, 샤이니펄 그레이랄지... 이상한 이름을 달고 나오는 스폐셜에디션 컬러들이 현대적인 색상입니다.9. 그런 느낌 있잖아요.어제 핀터레스트에서 본 그 시안입니다. 함께 노트북을 켜고 핀터레스트에 뭐라 검색하셨는지 물어봅시다.10. 아..그 딱 강렬한 느낌.뭔가 하나를 아주 크으으으게 키워달란 얘깁니다.11. 엣지 있는 느낌어떤 요소하나에 포인트 컬러를 넣어달란 얘깁니다. 또는 클라이언트가 원하는 어떤 요소(리본이랄지, 반짝이랄지, 텍스쳐랄지..뭐든)하나를 거기에 꼭 넣어야겠다는 강력한 의지의 표현입니다.12. 차분한 느낌텍스트의 좌측하단 정렬13. 발랄한 느낌프리픽과 셔터스톡의 벡터이미지를 구매해라.14. 귀여운 느낌팬톤컬러를 사용해달라. 크리미한 느낌으로다가. 그리고 모서리를 둥글게 해달라. 폰트는 HG꼬딕씨15. 강조된 느낌폰트를 굵게, 키워달라. 적어도 1.5배 이상의 크기로 키워라. 또는 보색의 박스를 씌워라.16. 고급스러운 느낌예식장에 주로 쓰이는 필기체 영문 세리프 폰트와 금색 포인트컬러를 써달라. 테두리에 선을 넣어라. 블랙은 매트한 느낌의 R45, G45, B45 컬러를 써라.17. 디테일이 살아있는 느낌어딘가에 깨알같은 요소를 넣어달란 얘기인데, 주로 화살표, 불렛포인트, 박스, 하단바 등에 뭔가 깨알같은 무언가를 넣어달라는 얘기입니다. 주로 화살표를 선으로 세련되게 바꾸면 디테일한 느낌이 삽니다.18. 킨포크느낌가운데정렬, 채도살짝 날린 사진을 쓰고, 사진 밑에 텍스트를 써달라는 얘깁니다.19. 병맛느낌충주시 고구마 포스터나 에듀윌 B급 포스터 만들어달란 얘깁니다. 개인적으로 극강의 난이도라고 생각합니다. 혹시 이걸 요구한 곳이 공공기관이거나, 나이가 지긋하신 분이라면 요즘 유행하는 것들중에서 1,2달정도 약간 지난 것들을 써보도록 합시다. 오지고 지리고 렛잇고라던지, 전화 아이받니?, 영미이이!!~ 이런걸 넣어달란 얘기...랄까요.20. 키치한 느낌키치한 워딩을 써달라는 얘깁니다. 사실 키치라는 건 독일어로 '조악하고 뒤떨어진 요소'를 나타내는 미학용어이지만, 현재는 B급감성이 있지만 센스있고 재빠른 감각의 디자인 또는 그러한 표현을 의미하는 것으로 조금 바뀌었습니다. 보통 키치함! 하면 떠오르는 몇몇브랜드가 있는데. 배민이랄지, 피키캐스트라던지, 좋은부탄....(?) 등... 이거든요. 하지만 이들의 키치함은 디자인 자체보단 워딩과 이미지의 절묘한 조합과 허를 찌르는 기획에서 비롯되는 경우가 많습니다. 때문에 이러한 키치한 느낌을 만들어달라고 했을 땐 사실 아이디어 요정이 되어주세요~~라는 무리하면서도 돈이 많이 드는 부탁인 셈이죠. 그러니 계약서를 다시 쓰도록 합시다....Aㅏ...뭐 더 많이 있겠지만..힘들어서 못쓰겠네요. 사실 위에 말씀드린 게 뭐 정답은 아닐 겁니다. 말 그대로 느낌이란 건 사람마다 인식하는 것들에 따라 큰 차이가 생기는 부분이니까요. 상대방이 정확히 머릿속에 뭘 떠올리고 '그 느낌'을 얘기했는지 찾는 것이 중요하죠. 말씀드린 부분은 지극히 개인적인 경험에서 비롯된 것이니 참고용으로만 부탁드립니다.더불어 사람은 언어에 구속되는 경향이 굉장히 강합니다. 원래는 '좀 더 밝은 톤' 을 말하려고 했는데,그게 잘 생각이 나지 않아서'좀 더 부드러운 톤' 이라고 말했다고 해볼께요.머릿속에선 명도를 높이는 걸 그렸겠지만, 입으로 '부드러운 톤' 이란 단어가 나온 순간부터 명도는 온데간데 사라지고 없습니다. 부드러운 톤!!..이 입밖으로 나왔고 내 귀에 들리는 순간 내가 원하는 건 '부드러운 톤' 이 되는 거죠.내 희망사항이 명확하지 않고 두루뭉술할 때엔 아무말이나 내뱉게 되는데 그 아무말이 다시 생각을 지배하는 놀라운 순환구조를 보여주는 거예요. 디자이너는 그 순환구조 사이에서 정신을 바짝 차려야 해요. 자칫 말이 생각을 부르고, 생각이 다시 이상한 말을 부르는 마법의 다차원세계에서 도르마무 마냥 영원의 속박을 경험할 수 있으니까요.상대의 표현은 어디까지나 표현일 뿐 그게 팩트가 아니란 사실을 잘 기억해두도록 합시당~. 도대체 저 표현뒤에 숨겨진 진짜 기억은 무엇인지를 캐내는 것이 또한 디자이너의 역할이라고 할 수 있겠어요. 디자이너는 상대의 욕망을 구현해내는 사람이기도 하니까요 :)즐디자인.

한 번쯤 이 단어를 들어본 적이 있나요? 여러분이 '커뮤니티 매니저(Community Manager)'라는 단어를 들어본 적이 있다면, 이런 공간들을 알거나 방문해본 적도 있을 겁니다. 코워킹 스페이스(co-working space), 공유 공간, 협업 공간, 청년 공간, 마을 공간, 거점 공간 등등 다양한 이름과 형태를 가진 ‘커뮤니티 공간’을 말이죠. 다양한 커뮤니티 공간에서는 '커뮤니티 매니저'를 직업으로 하는 사람들을 만나볼 수 있다. ⓒ wework, 마이크임팩트스퀘어, 아트업서울, 무중력지대G밸리최근 몇 년 간 서울을 비롯한 전국 각지에는 다양한 형태의 ‘커뮤니티 공간’이 빠른 속도로 새롭게 만들어지고 있습니다. 이 흐름은 자연스럽게 공간 운영과 관리를 담당하는 사람들의 등장으로 이어집니다. 바로 ‘커뮤니티 매니저’라고 불리는 사람들이죠.  이들은 때론 공간을 넘나들며 다양한 활동과 문화를 만들어나가며, 커뮤니티 회복과 활성화, 사회적 가치 창출 등을 지향하기도 합니다.물론 각 공간/직무 등에 따라 이들에 관한 호칭은 다양합니다. 하지만 광범위하게 자주 쓰이는 것은 아무래도 ‘커뮤니티 매니저’인 듯합니다. (과연 그 단어가 적절한지 혹은 더 멋진 새로운 단어는 없을지에 대한 고민은 일단 차치하고) 그 낯설고 생소한 이름으로 활동하는 사람들이 ‘커뮤니티 공간’의 양적 확대와 더불어 많아지고 있습니다.    그런데 '커뮤니티 매니저'가 뭐하는 사람이죠?체인지메이커들을 위한 공유주택 '디웰하우스'에도 운영와 커뮤니티를 담당하는 '커뮤니티 매니저'가 있다.  ⓒ 루트임팩트‘커뮤니티 매니저’의 정확한 뜻은 무엇일까요? ‘커뮤니티 매니저’라고 하는 사람들은 구체적으로 무엇을 하고, 어떤 공통적인 특성을 가질까요? 실제로 얼마나 많은 ‘커뮤니티 매니저’들이 어떻게 일하고 있을까요? ‘커뮤니티 공간’과 ‘커뮤니티 매니저’는 또 어떤 관계가 있는 걸까요? 로모는 이제부터 ‘커뮤니티 매니저’와 관련된 여러 다양한 질문들을 던져보려 합니다. 그리고 그 질문의 답을 찾는 여정을 여러분과 함께 시작해보려고 합니다.왜 로모는 ‘커뮤니티 매니저’를 화두로 꺼냈을까요?       최근 연재를 시작한 <처음 만나는 커뮤니티 공간 디자인>에 이어, ‘커뮤니티 매니저’에 관한 이야기를 꺼낸 데에는 이유가 있습니다.그저 하나의 공간(a place)이 아니라 의미를 가진 공간(the place)이 되기 위해서는 다양한 요소들이 필요하다. ⓒ Tim Mossholder on Unsplash물리적 공간뿐만 아니라 그 공간의 정체성과 문화를 만들어가는 ‘사람’에 대한 이야기가 동시에 함께 이루어져야, 새롭게 조성되는 공간이 그저 하나의 공간이 아니라 다양한 사람들과 여러 비물질적인 가치들이 ‘공존’하는 유기적인 공간으로 기능할 수 있기 때문이죠.어쩌면 너무도 당연한 말로 들릴지 모르겠네요. 하지만 로모의 팀원들이 그동안 여러 지역에 수십 개의 커뮤니티 공간들이 조성/운영되는 과정에 직/간접적으로 참여해온 경험을 돌이켜보면, 꼭 그렇지만은 않습니다. 대부분 기획과 조성의 단계 이후 '운영'의 차원으로까지는 논의가 밀도 있게 이어지지 못합니다. 또한 운영주체와 인력의 문제 역시 '인건비 부담' 등을 이유로 크게 축소되어버리기 쉽고, 그나마 배치된 각 공간의 매니저들이 무엇을 어떻게 해야 하는가에 대한 이야기는 제대로 다루어지지 못한 채 "각자 알아서 눈치껏"의 수준에 머물고 맙니다. 실제로 로모의 팀원들이 지난 몇 년간 '커뮤니티 매니저'로 경험했던 현장도 크게 다르지 않습니다. '커뮤니티 매니저'의 정의와 역할은 불분명한 채, 아니 그보다도 "커뮤니티 매니저가 도대체 뭐길래?"라는 질문이 제대로 던져지거나 다뤄지지 못한 채, 일단 '커뮤니티 매니저'라는 이름으로 역할이 주어졌고 잘 수행해야 했습니다.  그렇다면 결국 의지할 곳은 현장뿐입니다. 맨 땅에 헤딩하듯이 때론 조심스럽게, 때론 과감하게 다양한 시도를 이어나가며 끊임없이 데이터를 축적해나갔고, 그 과정에서 소위 '커뮤니티 매니저'에 관한 우리만의 그림을 그려나갈 수밖에 없었습니다. 문제는 수많은 '커뮤니티 매니저'들이 유사한 상황에 처해있거나, 그럴 것이라 추측된다는 것입니다. 관련된 체계적인 교육이나 활용할 수 있는 자원, 서로의 경험과 노하우를 나눌 수 있는 네트워크도 부족하니까요. 결국 공간 운영의 경험과 노하우는 공유되거나 축적되지 못한 채, 커뮤니티 공간이 늘어나면 늘어날수록, 각 공간에서 다시금 '0'에서부터 시작하듯 고군분투하는 매니저들이 늘어날 뿐이죠.  결국은 ‘커뮤니티 공간의 질을 어떻게 높일까?’의 문제   그렇다면 '커뮤니티 매니저'가 해답이 될 수 있을까요?모든 문제를 손쉽게 해결할 수 있는 해답은 존재하지 않습니다. 단순한 결론은 때론 효과적일 수 있지만, 때론 중요한 맥락을 가려버리기도 합니다.‘커뮤니티 공간’이 잘 운영되기 위해서도, 다양한 요소들이 필요합니다. ‘하드웨어(hardware)’, ‘소프트웨어(software)’, ‘휴먼웨어(humanware)’, 이 세 가지 요소들이 각자 제 역할을 다 하며, 조화를 이루는 게 필수적입니다. (이 부분은 로모의 또 다른 브런치 매거진 <처음 만나는 커뮤니티 공간 디자인>에서 좀 더 자세히 전할 예정입니다.)그리고 그중 '휴먼웨어'가 꼭 ‘커뮤니티 매니저’에만 국한된 것도 아닙니다. 수많은 이용자들, 공간문화를 만들어나가는데 적극적으로 동참하는 소위 '단골'들, 유관된 다양한 협력 주체 및 기관들, 이들 모두가 공간의 질을 높이는 데 일정한 역할과 책임, 영향력을 행사합니다. 그래서 커뮤니티 공간은 특정 주체에 지나치게 의존하기보단, 커뮤니티 공간을 제대로 이해하는 다양한 주체들의 활동력과 네트워크에 기반하였을 경우보다 지속 가능할 수 있습니다. 다만 그럼에도 중요하고 분명한 사실은 현장에서 '커뮤니티 매니저'들이 '휴먼웨어'의 핵심을 차지하며, 공간의 '하드웨어'와 '소프트웨어'에도 강한 영향을 미친다는 점입니다. "설계자, 시공자, 운영자가 명확히 구분됐던 과거와 달리 최근에는 설계자, 시공자, 운영자의 간극이 좁아지는 사례가 증가하고 있다. 공간의 성패는 어쩌면 설계자보다 운영자가 쥐고 있는지도 모른다. 운영자의 취향과 캐릭터가 고스란히 반영된 공간을 조성하고 그 공간을 완성시키는 다양한 운영전략을 갖출 때 비로소 건축설계가 완성된다고 볼 수 있다" - 윤주원, 김주원, 김수정 공저 (건축도시공간연구소),  7쪽 中그래서 '커뮤니티 매니저'의 정의와 역할, 필수적인 역량이 무엇인지에 대한 문제들은 "각자 알아서 눈치껏"의 차원을 넘어서서, "커뮤니티 공간의 질을 어떻게 높일 수 있을까?"라는 질문 아래 구체화될 필요가 있습니다. 새로운 직업(군)으로서 커뮤니티 매니저  로모는 이제부터 새로운 직업(군)으로서 커뮤니티 매니저를 바라보고, 그에 대한 이야기를 본격적으로 꺼내보려 합니다. 커뮤니티 공간 안팎에서 벌어지는 A to Z를 발로 뛰며 해결하는 '커뮤니티 매니저'들을 하나의 직업군으로서 접근해야, 각 현장에서 개인들이 부딪히는 문제들과 그를 풀기 위한 각종 시행착오들이 흩어지지 않고 의미 있는 경험 자원으로 재해석될 수 있고, 각 공간 혹은 기관의 장벽을 넘어서서 우리 삶 속의 커뮤니티 공간의 질을 높이는 데 필요한 공유재가 될 수 있습니다. <커뮤니티 매니저가 뭐길래>, 앞으로의 이야기 로모의 새로운 프로젝트 <커뮤니티 매니저가 뭐길래>는 앞으로 구체적으로 이렇게 진행될 예정입니다. 먼저, 현재 일하고 있는 커뮤니티 매니저들의 현장성 있는 이야기들을 수집하고 기록할 것입니다. 여러 이야기 조각들을 짜 맞추어보면, "도대체 커뮤니티 매니저가 뭐길래?"라는 질문에 대한 윤곽이 나오겠죠. 그와 함께 현장의 실무자들이 주요하게 마주치는, 다르게 말하면 앞으로 풀어나가야 하는 구체적인 이슈들도 추려볼 수 있을 겁니다. 각자의 이야기가 모여, 함께 나눌 수 있는 서사가 되는 것이 기본이자 핵심이다 ⓒ Headway on Unsplash이야기들을 모은 다음에는, 이제 제대로 된 판을 만들어볼 차례입니다. 다양한 제안과 대안을 생산해내기 위한 담론장을 열어나갈 예정입니다. 커뮤니티 매니저들을 심층 인터뷰하며 발견한 주요 이슈들을 중심으로, 더 많은 커뮤니티 매니저들과 함께, 혹은 굳이 커뮤니티 매니저가 아니더라도 커뮤니티 공간 운영과 이번 프로젝트에 공감하는 사람들이 모두 모여 상상하고, 제안하고, 토론하는 자리도 열어보려 합니다. 그렇게 얼마간 함께 이야기를 하다 보면, 우리는 어쩌면 함께 발견할 수 있을지도 모릅니다. "커뮤니티 매니저가 뭐길래?"라는 질문의 끝에는, '커뮤니티 매니저'라는 애매모호하고 한정된 언어의 틀을 넘어서서, 우리의 고민들과 방향성을 더 적절히 담은, 더 멋지고 새로운 언어를 말이죠. 언어의 힘은 크니까요. 그 발견의 여정을 이제 시작합니다!  이번 편에서는 매거진 <커뮤니티 매니저가 뭐길래>를 왜 시작했는가에 대한 이야기를 중심으로 솔직하게 풀어보았습니다. 앞으로는 커뮤니티 매니저들의 인터뷰 내용을 바탕으로, 좀 더 구체적인 이야기들을 전할 예정입니다. 다음 편을 기대해주세요 :) 커뮤니티 매니저 심층 인터뷰에 참여해주세요! 서울에서 활동하고 있는 '커뮤니티 매니저'들의 이야기와 생각을 수집하고 있습니다.   인터뷰를 희망하시거나, 주변에 관련 일을 하고 있는 사람이 있다면, 아래 링크를 클릭해주세요! http://bit.ly/whoisacommunitymanagerBY 나무  CCO & Co-Founder다양한 삶의 방식과 공존 사례를 연구하고, 실험합니다. 루시드폴의 노랫말을 좋아합니다.   #로모 #기업문화 #조직문화 #사내문화 #기업소개

Overview“githubPage로 기술 블로그를 만들자!” “jekyll로 만들면 한두 시간이면 가능할 거야!” 지난 1월, 브랜디 기술 블로그 제작 작업을 시작했습니다. 다양한 삽질과 험난한 여정의 결과물인 기술 블로그의 제작 및 커스터마이징 과정을 소개하겠습니다.GithubPage는 Github에서 공식적으로 운영하는 블로그 서비스입니다. 이곳엔 개발자들의 경험이나, 코드가 업로드되어 있습니다. 저장 공간도 무료로 제공되고, 도메인 연결도 편리하게 할 수 있지만, 무엇보다 GithubPage 혹은 GithubIO라고 하면 개발자 스멜이 풀풀 나기 때문에 선택의 이유가 되는거 같습니다.GitgubPage 제작 프로그램은 jekyll, HEXO가 가장 많이 쓰입니다. 브랜디의 기술 블로그는 템플릿의 종류도 많고, 더 어울리는 jekyll을 선택했습니다. jekyll 공식 사이트는 여기를 클릭하세요. 한국어도 지원하니 아주 멋집니다. 변역된 문서가 2015년 11월 23일 문서인 게 함정이지만 기능의 거의 유사하기 때문에 문제될 것은 없습니다. 1. 준비물을 챙기자!$ gem install jekyll $ jekyll new my-awesome-site $ cd my-awesome-site /my-awesome-site $ jekyll serve ▲ jekyll 설치 스크립트이제 브라우저로 http://localhost:4000 에 접속합니다.메인에 내거는 것처럼 설치와 실행이 쉽지만 몇 초 만에 되진 않습니다. 설치가 몇 분 정도 걸리고 ruby나 bundler같은 선행 조건이 갖춰져야 하기 때문입니다.ruby는 있는데 bundler가 없다면 아래와 같이 설치하면 됩니다.gem install bundler 설치가 잘 되고, 사이트 생성 후 실행을 했다면 브라우저와 함께 기본 페이지가 뜹니다. 설치가 성공했다!2. 1차 멘붕, 이제 무엇을?설치는 제법 쉽게 했지만 ‘이제 무엇을 해야 하나’ 막막하기만 합니다. 블로그 작성에 대한 아무런 가이드도 없고, 페이지나 이미지 추가 확인 등의 작업을 커멘드로만 하려니 힘들고 아찔하기만 합니다.커멘드 지옥..jekyll admin을 검색했더니 이런저런 아이들이 나옵니다. 그중에 jekyll 공식 플로그인을 선택했습니다. jekyll-admin 공식 사이트 이미지그런데 사이트 메뉴얼만 보고 설치하기 쉽지 않습니다. 이제 막 jekyll 띄웠을 뿐인데 플로그인은 어떻게 추가하는지 알 길이 없습니다. 이런저런 삽질을 거듭하고 안 되는 영어를 해석하다 보니 얼떨결에 성공했습니다.추가한 프로젝트 root에 보시면 Gemfile이 존재합니다.아마도 사이트 제너레이트 시 실행되는 스크립트인 것 같습니다. 파일을 열고 아래와 같이 추가합니다.# 아래와 같이 한줄 추가해주세요 gem 'jekyll-admin', group: :jekyll_plugins 프로젝트 root로 이동해 설치를 요청합시다.bundle install 달라진 게 없어 보여도 http://localhost:4000/admin 으로 접속하니 아뉫! 관리자가 설치되었습니다. 이제 한시름 놓입니다.3. 마크다운, 넌 누구?마크다운을 잘 안다면 넘어가도 됩니다.관리자를 설치하고 나면 그나마 좀 할만하지만 막상 글을 쓰려고 보니 무언가 다릅니다. HTML이나 위지윅 에디터도 아니고 Textarea만 덩그러니 있기 때문입니다....마크다운은 위키나 Github페이지 설명 작성 등에 쓰이는 언어입니다.1) HTML을 어느정도 한다면 문법만 읽어도 금방 이해할 수 있습니다. 생각보다 어렵지 않아서 간단한 문서 작성은 수월하게 가능합니다. 무엇보다 코드를 붙여넣을 때 아주 좋습니다. ``` PHP 코드 내용 ```위의 그림처럼 작성하면 자동적으로 신텍스 하이트라이트가 적용되니 개발 코드를 전달하기 편리합니다.4. Posts? Pages? Static Files? Data Files?확실히 jekyll은 그동안 봤던 블로그나 워드프레스 등 유명한 블로그와는 많이 다릅니다. 일단 개념부터 짚어보겠습니다. PostsPost는 한 개의 글을 지칭합니다. 블로그의 글 하나입니다. 어느 정도 구축이 되면 Post에서 글만 작성해도 쉽게 운영할 수 있습니다.PagesPost처럼 계속 추가되는 형태가 아닌 고정 페이지를 작성할 때 씁니다. About이나, 채용, 회사소개 등 Post와 분리가 필요한 글을 작성할 때 유용합니다.Static Files정적 리소스를 올리는 기능입니다. 생각보다 버그가 많아서 사용하기 쉽지 않습니다. 저는 이 기능을 커스터마이징해서 약간 쓰기 쉽게 바꾸었지만 쉽지는 않았습니다. 자세한 관리자 커스터마이징은 나중에 다루겠습니다.Data Files정적 데이터를 다루는 기능입니다. 저자 관리나 공통 변수를 담아두면 편리하게 쓸 수 있는 기능입니다. 역시나 버그가 넘쳐납니다. 당분간은 그냥 파일을 직접 수정하는 게 나을 겁니다.5. 블로그 제목 등 설정을 바꾸고 싶다면관리자의 configuration 메뉴를 이용하거나, 프로젝트 루트에서 _config.yml 을 열고 수정해도 됩니다. 사이트에서 사용할 전역 변수나, 플로그인, 기본값 등을 관리해주기 때문에 자주 수정하는 파일입니다. 제목을 변경하려면 title을 찾아서 변경하면 됩니다. 그외의 하단 문구는 buttomtitle을 변경하면 됩니다. 아래 보이는 각종 정보들은 맞게 수정하면 되고, social: 밑에 있는 정보들은 나중에 페이스북 공유나, 트위터 공유 등으로 사용할 수 있습니다. 해당 정보가 없거나 공유를 원치 않는다면 share를 false로 변경합니다. _config.yml은 수정 후 재시작을 해야만 반영되므로 jekyll를 다시 실행하면 됩니다.6. 테마를 적용하자테마 기능은 jekyll를 선택한 가장 중요한 이유였습니다. 멋진 디자인과 추가로 구현된 특수한 기능들은 jekyll이 가지고 있는 큰 메리트입니다. 테마를 사용하려면 소스를 다운로드 받고 압축을 해제해 사용하거나 git checkout 하면 됩니다. 해당 폴더로 이동해 실행하면 테마를 쉽게 사용할 수 있습니다.jekyll serve jekyll은 테마가 완성된 프로젝트 개념이기 때문에 바로 사용이 가능하지만 마이그레이션 이슈가 있습니다. 마이그레이션은 _post의 있는 파일과 _page에 있는 파일을 그저 테마 프로젝트 폴더에 덮어쓰기하면 됩니다.아쉽게도 _config.yml파일은 다시 세팅하는 게 빠릅니다. 어드민 설정 부분도 다시 하면 됩니다. 테마마다 약간씩 기능이 달라 마이그레이션이 안 되는 경우도 있으니 테마는 초기에 선택하는 게 좋습니다. 브랜디 랩스는 Centrarium 테마를 적용했습니다.테마가 적용된 화면7. 글에 이미지를 어떻게 넣을까?글을 쓰면 참고자료로 쓸 이미지도 필요합니다. static file에 업로드 기능이 있지만 업로드를 하면 프로젝트 루트 폴더에 업로드되어 관리상 좋지 않습니다. 앞서 공유한 것처럼 해당 기능 개선에 대해서는 다루지 않을 것이기 때문에 수기로 이미지를 관리하는 방법을 소개하겠습니다.로컬 프로젝트 기준에서 _site는 제너레이트된 최종결과라고 할 수 있습니다. 그래서 _site 폴더에 assets와 같은 폴더가 있으나 그 폴더에 올리면 덮어쓰기와 동시에 초기화 되므로 반드시 프로젝트 루트의 assets에 파일을 올려주시면 됩니다. 폴더를 생성하는 것도 문제 없으므로 포스팅마다 이미지를 나누길 권장합니다. 이미지가 폴더에 복사가 되었다면 이제 글에 넣어봅시다.마크다운 위지윅을 이용해도 좋고 이미지 부분을 HTML코드롤 사용해도 좋습니다. 마크다운으로 이미지를 추가할려면 아래처럼 사용하면 됩니다.  assets/test.jpg적용된 이미지이미지의 사이즈나 정렬을 변경하는 건 다음에 다루겠습니다.8. Gnav 변경은 어떻게 할까?커스터마이징한 Gnav영역테마도 적용했고, 글도 쓸 수 있지만 안 쓰는 기능 삭제를 비롯해 손볼 곳은 아직 많습니다. (분명 한두 시간이면 된다고 했던 일이 2주째 수정 중입니다…) 화면 구성을 고치려면 프로젝트에 포함되어 있는 템플릿 파일을 고쳐야 합니다.템플릿은 Liquid 라는 언어로 구성되어 있으며, 문법이 좀 난해하지만 충분히 헤쳐 나갈 수 있습니다. 다만 어디서부터 어떻게 고쳐야 하는지를 파악하는 게 어렵죠. 문법은 공식 사이트를 참고하고, 사용 가능한 변수는 여기를 참고하면 됩니다.사용 가능한 변수는 site와 page로 나눌 수 있습니다. site는 _config.yml 설정한 내용과 jekyll이 지원하는 전역 변수들입니다. page는 해당 페이지에 지정된 세부 변수들입니다. 글의 제목이나 경로 내용들은 기본적으로 세팅되어 있습니다. 추가적인 값을 다루려면 post를 작성하면서 meta정보를 추가하면 됩니다.템플릿의 시작파일은 index.html이고, 페이지에 layout이 지정되었다면 _layouts 안에 있는 [layout].html이 됩니다. 기본적 틀은 _layout/default.html에서 파생됩니다. 그외 파츠로 사용되는 HTML파일은 _includes에 넣고 `{% include header.html %} 같은 방식으로 추가하면 됩니다. 우리 변경하려는 파츠는 header.html에 있습니다. site.pages에는 모든 페이지가 들어있기 때문에 그중에 gnav가 지정된 글만 상단에 노출되게 했습니다. 그리고 상단 글에 대한 정렬이 없기 때문에 좋은 방식은 아니지만 1~10까지 숫자를 기입하면 순서대로 나오게 코드를 구성했습니다. (site.pages에는 posts와 pages가 같이 나옵니다.){% for i in (1..10) %}   {% for page in site.pages %}     {% if page.title and page.gnav == i %}     {{ page.title }}     {% endif %}   {% endfor %}  {% endfor %} 글에 옵션을 지정한 화면이제 pages에서 상단에 노출하고 싶은 글만 gnav를 숫자로 부여해 노출할 수 있게 변경했습니다.9. 스타일 변경은 어떻게 할까?sass로 구성된 스타일의 변경은 심도있게 다루지 않으려고 합니다. sass를 처음 사용한 것도 있지만 내용이 너무 깊어지기 때문입니다. 스타일변경은 _sass 밑에있는 scss 파일을 변경하면 되고, 템플릿마다 구조가 다르기 때문에 열심히 찾는 수밖에 없습니다.10. 저자 기능을 추가해보자 (1)최고의 난이도를 자랑하는 신규 기능 추가입니다. 브랜디의 기술 블로그에서는 작성자를 클릭하면 작성자의 글만 따로 모아서 볼 수있습니다. 하지만 이 기능은 공식적으로 지원되는 것이 아니기 때문에 처음부터 만들어야 했습니다. 완성된 작성자 기능위의 이미지와 같은 기능을 구축하려고 collection을 사용했습니다. collection은 posts나 pages와 같이 그룹핑된 글 목록을 이야기 합니다. posts나 pages는 기본 세팅되어 있고, 약간(?)의 설정 변경으로 collection을 추가할 수 있습니다. 작성자의 메인 페이지가 필요하니 authors라는 collection을 추가해보겠습니다.# _config.yml collections:   authors:     title: Authors     output: true jekyll을 재시작하면 아래와 같이 Authors가 관리자에 추가된 것을 볼 수 있습니다.authors는 작성자 메인 페이지만 생성하면 되므로, 내용에는 작성자에 대한 소개글만 간략히 쓰면 됩니다. jekyll admin에 한글 버그가 있기 때문에 우선 영어로 작성하고, 제목을 다시 한글로 수정하면 됩니다.포스팅마다 저자의 정보가 공통적으로 나와야 하기 때문애 위의 전역변수에 authors를 추가해 따로 관리하게 했습니다.# data/authors.yml # authors 공용 변수   - name: chunbs     koname: 천보성 팀장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/chunbs.jpg   - name: kangww     koname: 강원우 과장     email: [email protected]     position: R&D 개발2팀     img: /assets/profile/kangww.jpg 그리고 작성자의 포스팅을 엮어주려고 작성자의 아이디가 같을 때, 포스팅으로 나오게 구성합니다.{% if post.author %} {% for author in site.data.authors %}   {% if post.author == author.name %}   {{author.koname}}   {% endif %}  {% endfor %}  {% endif %} 11. 저자 기능을 추가해보자 (2)데이터가 준비되었다면 저자 레이아웃을 추가해야 합니다.(이거 도대체 언제 끝날까요) 저자가 작성한 글만 노출되어야 하는 게 어려울 수도 있지만 jekyll의 구동 원리를 이해하면 손쉽게 할 수 있습니다.jekyll은 내용 수정이 발생되면 전체를 다시 컴파일하는 구조입니다. 다시 말해 일부 파일이 변경되면 노출되는 모든 html파일을 다시 랜더링해서 write하는 것입니다. author의 각 작성자 페이지는 컬렉션에 포함되어 있기 때문에 랜더링이 발생하고 site.posts엔 작성된 모든 페이지 정보가 있습니다. site.posts를 foreach를 돌리고, 저자가 일치하는 페이지만 리스트로 보여줍시다.{% for post in site.posts %} <!-- author 정보가 저자와 같은 경우만 리스트로 출력한다. --> {% if post.author == page.author %}       {{ post.title }}         {{ post.content | strip_html | truncatewords: 25 }}         {{ post.date | date: "%Y-%m-%d" }}           {% if post.author %}         {% for author in site.data.authors %}           {% if post.author == author.name %}           {{author.koname}}           {% endif %}         {% endfor %}       {% endif %}       {% if forloop.last == false %} {% endif %}   {% endif %} {% endfor %} Conclusionjekyll admin은 은근히 버그가 많습니다. 그래도 ‘md파일을 메모장으로 작성하세요’라고 하는 것보단 편하죠. 다양한 기술을 사용하기 때문에 어려울 수도 있겠습니다. 글에서 소개할 수 없거나, 너무 깊어지는 내용은 소개에서 제외했습니다. 양해를 부탁드립니다. 대신에 브랜디 랩스는 저의 피땀 눈물로 만들어졌다는 걸 기억해주세요… 기타jekyll의 기본값 설정을 이용하면 layout과 같은 공통적인 부분을 쉽게 설정할 수 있다.# _config.yml defaults:  - scope:     path: ''     type: posts   values:     #permalink: "/blog/:title/"     layout: post     cover: /assets/default.jpg     author:  - scope:     path: ''     type: authors   values:     layout: author     cover: /assets/author.jpg     subtitle: ~담당하고 있습니다.     author: 영문이름 jekyll admin이 버그가 많아서 업로드 기능은 커스터마이징 했다. 루비와 UI코드를 고쳐서 다시 빌드하는 어지러운 작업을 했다.만약 버그를 고치기 어렵다면 IDE로 파일을 직접 수정하는 게 안전하다. 참고 1)마크다운 작성법은 여기를 참고하세요.글천보성 팀장 | R&D 개발2팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유

페이스북을 통한 타겟팅 광고지금도 셀 수 없는 피드가 올라오는 페이스북은 타겟팅 광고를 위한 최적의 채널 중 하나입니다. 일상과 취향을 공유하는 공간이다 보니 페이스북에선 타인이 어떤 사람인지 쉽게 짐작할 수 있으며 반대로 내가 어떤 사람인지도 공개합니다. 페이스북은 이런 데이터를 바탕으로 사용자가 ‘관심을 가질만한 내용’을 타임라인에 노출하는데, 여기에는 광고도 포함됩니다.(페이스북 광고 타겟팅 설정 화면)위 그림은 페이스북이 제공하는 광고 타겟팅 옵션 중 하나인 ‘저장된 타겟’ 기능입니다. 하루 10억명 페이스북 사용자의 행동 데이터를 근거로 관심사별 타겟팅 옵션을 제공합니다. 올바른 대상을 쉽게, 그리고 상세하게 지정할 수 있도록 함으로써 사용자가 ‘관심을 가질만한 내용’의 광고를 내보내 광고의 맥락적 효과를 높이려는 의도가 있습니다.하지만 위에서 생성한 타겟이 완전하다고 할 수는 없습니다. 위 타겟팅을 통해 페이스북이 제시한 것은 ‘광고주의 서비스에 관심이 있을 것 같은 사용자’입니다. 달리 말하면 ‘서비스를 구매할 확률이 높은 사용자’라고 할 수 있는데, 이 ‘확률’을 더욱 높이기 위한 방법은 여전히 밀린 고지서처럼 남아 있습니다. 어떤 해결책이 있을까요?데이터 기반의 타겟팅 푸시 메시지화장품 회사의 멤버십 앱을 사용하며 겪었던 일로, 다음과 같은 내용의 푸시 메시지를 받았습니다.VIP 멤버십 만료 15일 전, 멤버십 혜택인 VIP 키트를 수령할 수 있는 근처 매장을 푸시 메시지로 안내날짜가 지나기 전에 혜택을 받을 수 있는 최선의 방법을 안내 받는 동시에, ‘매장 방문하는 김에 필요한 제품을 구입해야지’ 생각을 하게 만든 메시지였습니다. 실제로 매장에 방문해 키트를 받고 제품도 구입했으며, 조금만 더 구입하면 다음 등급이 된다는 안내까지 받았던 맥락적으로 훌륭한 마케팅이었습니다.자사의 데이터(First-Party Data)를 수집하고 분석해 확실한 타겟을 찾고 올바른 메시지를 보낸 결과입니다. 자사 데이터는 실제 우리 서비스를 이용한 고객들의 정보를 포함한 데이터입니다. 우리 서비스를 이용하고 있는, 즉 우리의 메시지를 진지하게 들어주는 청중(Audience)이 누구인지, 무엇을 좋아하며 어떻게 행동하는지에 대한 해답을 담고 있는 순도 높은 데이터입니다.자사 데이터를 활용하면 페이스북과 같은 광고채널이 제공하기 어려운 다음과 같은 조건으로 타겟을 필터링 할 수 있습니다.상품을 장바구니에 담은 후 구매하지 않고 3일이 지난 사용자최근 10일동안 홈페이지나 앱에 접속 기록이 없으며 기념일을 앞두고 있는 사용자앱을 설치한 후 일주일이 지났지만 구매 기록이 없는 사용자위 조건으로 필터링된 사용자만을 대상으로 마케팅 커뮤니케이션을 진행한다면 최소한의 비용으로 높은 효과를 거둘 수 있을 것입니다. 오디언스 타겟팅데이터를 어떻게 필터링 하는지는 와이즈트래커의 실제 메뉴를 보여드리면 이해가 빠를 것 같습니다. 디바이스와 앱의 컨디션, 사용자의 방문행동, 사용자 프로파일,사용자가 유입된 경로, 그리고 고객사의 비즈니스 특성을 고려한 맞춤필터를 제공합니다.(와이즈트래커 오디언스 타겟팅 설정 화면. 위와 같은 설정을 통해 3월 한달동안 대한민국 20대 남성 비회원 고객들의 ADID/IDFA 추출이 가능합니다. ) 이처럼 자사 데이터에서 특정 행동조건을 만족하는 사용자만 추출해 타겟팅하는 것을 오디언스 타겟팅(Audience Targeting)이라고 합니다. 오디언스 타겟팅으로 추출된 타겟은 페이스북 등의 외부 광고 플랫폼 등이 제공하는 제삼자 데이터(Third-Party Data)보다 정확도가 훨씬 높다는 장점이 있습니다.다만 추출된 데이터의 숫자 자체가 적어서 광고가 넓은 범위로 도달이 어렵습니다. 그리고 자사 데이터를 수집, 분석하는 시스템 구축이 필요한 것은 단점입니다. 따라서 자체 시스템 구축에 소요되는 기회비용을 고려해 외부 분석 솔루션을 도입하는 경우가 많으며, 모바일앱 채널은 강력한 인앱 분석 기능을 바탕으로 상세한 추출 옵션을 제공하는 와이즈트래커가 좋은 대안입니다. 오디언스 데이터의 결합자사 데이터에서 추출한 순도 높은 타겟과 광범위 도달이 가능한 제삼자 데이터를 결합하면 서로의 단점을 적절히 보완한 타겟 데이터를 생성할 수 있는데, 이런 경우를 넓은 의미에서의 오디언스 타겟팅이라고 말할 수 있으며 일반적으로 지금의 의미로 많이 쓰입니다. 이해를 돕기 위해 다시 페이스북을 예로 들어 설명하겠습니다. ( 페이스북의 ‘맞춤 타겟’ 옵션. 광고주가 원하는 특정 모바일 사용자만을 타겟팅 할 수 있도록 ‘모바일 광고주 ID’ 업로드가 가능합니다. 와이즈트래커로 추출할 수 있는 것이 바로 이 ID입니다.) 페이스북의 타겟팅 옵션 중 하나인 ‘맞춤 타겟’ 기능입니다. 타겟팅 옵션 중 가장 처음에 제공되며 그만큼 페이스북이 권장하는 기능입니다. 광고주가 업로드한 데이터와 일치하는 페이스북 사용자를 찾아 타겟팅하는 것이 핵심으로, 자사 데이터 중 ‘최근 30일간 구매 기록이 있는 사용자’의 이메일 주소를 업로드하면 해당 이메일을 페이스북 계정에 등록한 사용자에게만 광고가 노출되는 방식입니다.하루 10억명이 사용하는 페이스북에는 위에서 업로드한 최근 30일간 구매 기록이 있는 사용자’와 비슷한 성향의 사용자가 있게 마련입니다. 이를 위해 페이스북은 업로드된 자사 데이터의 오디언스와 가장 비슷한 사용자를 찾아주는 ‘유사 타겟’ 기능을 두번째 옵션으로 제공합니다. 결과적으로 광고주는 페이스북이 확보한 수많은 제삼자 데이터 중에서 광고주가 업로드한 자사 데이터와 유사한 패턴을 보이는 사용자를 대상으로 마케팅을 진행할 수 있는 것입니다.결국 자사 데이터를 활용한 오디언스 타겟팅은 타겟의 실제 행동과 관심사 데이터를 기반으로 하기 때문에 단순 인구통계 기반의 기존 타겟팅보다 퍼포먼스가 높을 수 밖에 없습니다. 그리고 제삼자 데이터와 결합해 가능성 높은 신규 타겟에게 선별적으로 메시지를 전달할 수 있습니다. 이런 오디언스 타겟팅을 효과적으로 진행하기 위해서 먼저 순도 높은 자사 데이터를 확보 할 수 있어야 합니다.이미 Legacy System을 통해 많은 데이터들이 수집되고 있을텐데요, 고객의 구매행동과 관련 데이터에서 타겟 오디언스를를 추출해 활용하는 것부터 시작해보는 것도 좋은 방법일 것 같습니다. * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #마케터 #마케팅 #꿀팁 #데이터분석 

임팩트 커리어 Y를 통해소셜섹터 마케팅 커리어를 경험한루트임팩트 전예진 님임팩트 커리어 Y 2기로 루트임팩트에서 인턴기간을 마친 전예진 님. 커뮤니티를 통해 사회에 선한 영향력을 미치고 싶다는 전예진 님의 이야기를 들어보자.대학교 2학년 재학중에 임팩트 커리어 Y 2기의 최연소 참가자가 된 예진 님(오른쪽)예진님을 소개해 주세요. 어떻게 사회혁신 커리어에 관심을 갖게 되었나요?고등학생 때 ‘소셜밸류’라는 교내동아리를 통해 사회적기업에 처음 관심을 가졌어요. 소셜벤처 경연대회에 나가보고, 협동조합 안내책자도 만들면서 소셜섹터의 존재를 알게 되었고요. 이후에는 대학교 창업동아리에서 잠시 활동하며 단순히 금전적 이익만 추구하는 것이 저에게 동기부여를 하지 못한다는 것을 깨달았습니다. 마침 휴학하고 새로운 경험을 하고자 했던 시기에 임팩트 커리어Y를 알게 되어 루트임팩트에서 인턴으로 일해보는 소중한 경험을 할 수 있었습니다.많은 회사들 중에 왜 루트임팩트에 지원하게 되었나요? 저는 아직 2학년이기 때문에 소셜섹터와 생태계 전반에 대한 이해를 하고 싶었어요. 그래서 생태계를 조성하고 있는 지원조직인 루트임팩트가 가장 먼저 눈에 들어왔어요. 대학 생활을 하면서 비슷한 가치관을 가진 친구의 영향을 받아서 관심이 더 깊어졌는데요. 서로 나누던 대화중에 커뮤니티를 통해 선한 영향력을 미치는 방법에 대한 이야기도 있었는데요. 루트임팩트가 그런 일을 하는 조직이라고 생각했습니다.부트캠프 교육기간 동안 가장 좋았던 것은 무엇인가요?본격적으로 일을 시작해서 가장 힘이 된 건 서로 응원하고지지해주는 동기들이었어요.'디지털마케팅 강의', '비즈니스 모델 이해하기'와 같은 강의들도 첫 인턴경험이라 살짝 겁을 먹은 저에게 차분한 마음가짐을 하도록 도와주었어요. 하지만 본격적으로 일을 시작해서 가장 힘이 된 건 서로 응원하고 지지해주는 동기(a.k.a 멋진 언니, 오빠들)들이었어요. 각자 자신의 자리에서 하고 있는 고민들을 서로 나누고 조언해주는 임팩트커리어 동기가 있어서 든든했습니다.인턴기간 동안 무슨 일을 했고, 어떤 성장을 했다고 생각하시나요? 저는 루트임팩트 마케팅팀에서 디지털마케팅 인턴으로 근무했습니다. 제가 했던 업무는 크게 SNS 채널 관리라고 할 수 있는데요, 기획부터 실행까지 업무의 자율성이 많이 보장되었어요. 구체적으로는 홈페이지의 체인지메이커 매트릭스 수정 및 번역, 루트임팩트 브런치 중 "People in 루트임팩트"관리, 디자인툴 배우기 및 적용하기, SNS월간홍보캘린더 관리, 그리고 루트임팩트와 헤이그라운드 인스타그램 기획 및 관리를 했습니다. 저의 배움과 성장을 응원하는 팀 분위기 덕분에 해보지 않았던 인스타그램 마케팅을 공부하고 기획하고 실행해볼 수 있었고, 미팅을 따라다니면서 다양한 소셜섹터 플레이어들을 만나 소셜섹터의 생생한 현장을 경험해볼 수 있었습니다. 커리어적으로는 소셜섹터를 넓게 이해할 수 있게 된 것, 이전보다 더 적극적인 행동을 해볼 용기가 생긴 것이 성장한 부분이 아닐까 생각합니다.헤이그라운드를 누비며 입주사 분들과의 인터뷰를 기획했던 예진 님.임팩트커리어 3기 지원자들에게 해주고 싶은 말과 함께 예진 님의 앞으로의 계획을 나눠주세요!아직 학업을 마치지 않은 재학생 분들도 앞으로 소셜섹터에서 일해보고 싶다면, 그리고 배우고 성장하고자 하는 열정이 있다면 열린 마음으로 도전하셨으면 좋겠어요. 저는 인턴 끝나고도 헤이그라운드를 자주 방문하고 있는데, 지금 사회혁신 컨설팅 대회에 참여해서 소셜벤처 비즈니스 모델을 구상하고 있어서 그래요! 우선 이 프로젝트를 열심히 하다가 복학해서 흥미로워 보이는 수업들을 마음껏 듣겠죠? 언젠가 소셜섹터에서 다시 만날 날을 기대합니다.#루트임팩트 #헤이그라운드 #임팩트커리어 #스타트업인턴 #마케팅인턴 #인턴마케터 #부트캠프 #소셜벤처 #커리어경험

지난번 초보 PM이 알아야 하는 초기 모바일앱 분석 101글에서 앱을 런칭한지 얼마 안된 극초기 단계의 스타트업에서 어떤 앱 운영 지표들이 필요한지에 대해 논의했었다. 읽어보지 못한 분들을 위해 간단히 요약하자면, (처음부터 BM이 붙어있는 앱이 아닌 이상) 1) Acquisition (획득), 2) Retention (유지), 3) Referral (추천) 이 3가지 사이클을 중점적으로 모니터링 하는게 중요하다... 라는 내용이었다. (본 글에서는 기본적 개념 설명은 생략할 예정이어서 앱 운영 지표가 생소하신 분들은 꼭 저 글을 먼저 읽고 오시길 권장한다)오늘 글에서는 여기에서 더 나아가 구체적으로 어떤 지표들을 데일리 베이스로 관리하면서 앱을 성장시켜야 하는지에 대한 방법론에 대해 그간 공부한 내용을 정리해 보고자 한다. 참고로 본 글의 내용은 앱이 성장하고 있는지를 일단위로 모니터링하기 위한 방법론이지 '성장하기 위한 방법론'에 대한 글이 아님을 명심하기 바란다.1. DAU, MAU의 환상에서 벗어나기언제나 필자가 강조하는 내용이다. 생각보다 많은 분들이 극 초기 단계의 서비스를 운영하면서 DAU (Daily Active Users), MAU (Monthly Active User) 지표만 목매고 있는 경우가 많다. 심지어 투자자들 중에서도 초기 단계 서비스를 점검하면서 `MAU가 몇명인가요?` 'DAU는 몇명인가요?' '총 다운로드는 얼마나 되요?' 달랑 이 3개만 물어보고 끝인 사람들도 종종 만나게 된다. DAU, MAU만 쳐다보고 있는게 왜 환상이냐면, 그건 두개 다 돈 처발라서 만들어내는게 가능한 지표이기 때문이다.좀 자세하게 썰을 풀어보기 위해 Day 1 리텐션이 30%도 안되는 어떤 앱서비스가 있다고 가정해 보자. Day 1 리텐션이 30% 이하라는 뜻은 그 앱을 깐 사람들의 70%이상이 다음날 앱을 비활성화 (또는 사용하지 않는) 시켜버린다는 뜻이다. Day 1이 30% 이하면 Day 7은 10%이하, Day 30은 거의 미미한 수준일 가능성이 높은 앱이다. 리텐션이 이정도면 이 앱은 사실 앱의 코어 가치 자체가 가치가 없거나 완성도가 매우 떨어지는 앱일 가능성이 높다. 그런데 만일 이 앱서비스를 하는 회사가 (또는 스타트업 팀이) 마케팅 버짓이 매우 많아서 하루에 페북 광고만 500만원씩 태우고 있다고 쳐보자. 페북에서 보통 평균 CPI가 1-2천원 수준이라고 하니 2천원을 적용하면 하루에 무려 2천명의 신규 유저가 유입되는 규모의 돈이다. 이 앱서비스가 매일 500만원씩 한달 1억 5천의 광고비를 태우면 어떤 DAU, MAU가 만들어질까? 계산의 편의성을 위해 리텐션이 Day 1가 30% -> 하루에 1%씩 리텐션이 감소해서 Day 30이 되면 1%가 된다고 가정해 보면 (보통은 Day 7까지 더 급격히 떨어지고 뒤로는 완만한 곡선을 그린다) 이 앱의 DAU는  2000, 2600, 3180, 3740 ... 이렇게 아름답게 성장하고 해당월 평균 DAU는 약 8천명, MAU는 해당월에 239,800명, 해당월 신규 다운로드는 6만이라는 숫자가 만들어진다.조금 과장 보태서 어떤 스토리가 가능해 지냐면, 이 앱의 대표가 약 5억원의 시드 (또는 엔젤)투자를 유치하기 위해서 정부지원사업+개인돈 긁어보아서 한달 열심히 지표 만든다음에 투자자들한테 5억원만 투자해주면 1년안에 백만다운로드, MAU 30만 이상의 중규모 단위의 앱으로 성장 가능하다는 나름의 근거숫자가 만들어 지는 것이다. 뭐 1억원 처발라서 3-5억원을 얻을 수 있는 딜이므로 창업자가 해당 앱에 완전 꽂혀있는 경우 충분히 발생가능한 스토리이다. 물론 VC분들은 그렇게 허투르지 않아서 저게 돈으로 만들어진건지 금방 들통나겠지만 (또는 분야에 따라 저정도 숫자로는 1억원 투자도 어림없는 경우도 있다) 필자가 강조하고자 하는 부분은 아무리 리텐션이 x같은 앱이라도 돈만 있으면 얼마든지 만들어지는게 DAU, MAU라는 숫자라는 점 이다. 또한 저정도 돈 태우고 있으면 앱스토어 피처도 되는 경우가 많아서 숫자는 저거보다 훨씬 더 불어날 수 있다. 따라서 초기 앱의 성장을 위해서 우선적으로 필요한 부분은 바로 이 DAU, MAU라는 숫자만 맹목적으로 쳐다보고 있는 환상에서 벗어나는 거다.리텐션이 x같아도 돈 처발라 만드는게 가능한 지표가 바로 DAU, MAU라는 놈이다.2. Acquisition (획득) 경로를 데일리로 점검이제 본론으로 넘어가서, 초기 앱에서 PM이 가장 신경써서 모니터링하고 데일리 마케팅에 반영해야 하는 지표는 단연코 Acquisition, 즉 획득지표이다. 전편 글에서 설명했듯이, Acquisition이란 매일 들어오는 신규 유저들이 어느 경로로 들어왔는가를 집요하게 데일리로 추적하는 지표를 의미한다. 추적하는 방법은 크게 2가지 방법이 있다.2-1. 앱 다운로드 링크에 추적코드 삽입보통 아이폰용, 안드용 앱을 모두 갖고 있으면 다운로드 링크를 하나로 통일해서 각각의 채널로 리디렉팅 시키는게 필요하다. 이때 추적코드를 포함시켜서 포워딩 해줘야 해당 클릭이 어느 마케팅 활동/채널에서 발생했는지가 추적 가능하다. 바크 앱의 경우 앱 다운로드에 추적코드를 다음과 같이 심어서 배포하고 있다.https://barkapp.co/download?ref=FacebookAd-HighSchoolAd-Busan-D3저기서 'ref=' 다음에 들어가는게 추적코드이고, 이 코드는 애플 유저의 경우 아이튠즈 링크에 다음과 같이 레퍼런스 코드로 전환되어 기록된다.https://itunes.apple.com/app/apple-store/id1100131438?pt=118117595&ct=FacebookAd-HighSchoolAd-Busan-D3&mt=8FacebookAd-HighSchoolAd-Busan-D3라는 추적코드가 아이튠즈 URL에 삽입되어 리디렉팅 되고, 저 링크가 클릭될때 마다 슬랙으로 실시간 모니터링도 가능해 진다.슬랙에서 다운로드 링크가 누군가에 의해 클릭될때 마다 이렇게 추적코드, 디바이스정보를 알림으로 설정해 놓을 수 있다.저걸 매일 쳐다보고 있으라는 뜻이 아니고, 하루에 저 채널에서 클릭이 얼마나 발생하는지를 내가 투입한 예산대비 효율관점으로 모니터링하는게 중요하다는게 핵심이다. 예를들어 본인의 마케팅 활동의 CPI 상한선이 500원으로 책정되어 있고, FacebookAd-HighSchoolAd-Busan-D3라는 마케팅에 오늘 100만원을 쏟아부었을 때 다운로드 컨버젼이 50%라고 가정한다면 적어도 저 링크에서 클릭이 오늘 1,000회 이상은 발생해 줘야 CPI 타겟을 맞출 수 있는 것이다. 역시 슬랙에서 내가 뿌린 추적코드가 하루에 얼마씩 클릭이 발생했는지를 리포트로 알림 받는것도 가능하다.슬랙에서 하루에 발생한 클릭 숫자를 정리해서 리포트로 알림받을 수 있다.2-2. 온라인에서 내 서비스가 얼마나 멘션되고 있는지 추적해주는 솔루션들 활용위의 2-1만 할 경우 문제가 뭐냐면, 내가 다운로드 링크로 뿌린거 외에 유저가 오가닉하게 내 앱에 대해 알게되고 이를 본인 채널로 언급하고 있거나 각종 기사, 트윗에 뜨는 트래픽들은 모니터링이 불가능하다는 점이다. 이런걸 가능하게 해주는 추적 서비스들이 시중에 널려 있는데, 우리는 그 중에서 notify.ly라는 서비스를 쓰고 있다. 이 서비스는 트위터, 유투브, 블로그 등등에서 내가 설정한 키워드, URL등이 언급될때 마다 크롤링을 통해 슬랙으로 알림을 주는 서비스이다.크롤이 가능한 거의 모든 사이트에서 내가 설정한 키워드가 언급될때 마다 슬랙으로 알림을 주는 서비스이다.우리는 이 서비스를 이용해서 바크 URL이 언급되거나 바크 관련 키워드들, 경쟁사 앱이 언급될때 마다 이렇게 슬랙으로 알림을 받으면서 모니터링 하고 있다. 이렇게 해 놓으면, 나중에 갑자기 트래픽이 터졌는데 그게 내가 뿌린 링크에서 터진게 아닐 경우 해당 서비스 멘션에서 그 소스를 찾아보는게 가능해 진다. 또한, 누군가 내 앱을 알아서 언급해 주고 있다는걸 실시간으로 아는것만으로도 기분이 좋아지고 사기가 진작되는 효과도 있다.이렇게 누군가 우리 앱을 언급하는 알림을 받을때 마다 사기가 진작되는 부가 효능도 있다.위에 언급된 두가지 방법 외에도 본인이 직접 구글이나 페북 검색을 통해 내 앱이 얼마나 언급되는지를 수동으로 찾아보는 방법도 있다. 가끔 시간이 남거나 위의 두가지 방법으로 도무지 트래킹이 안되는 트래픽이 있을때는 시도해 볼만 한데 자세한 방법은 생략한다.3. 앱 유저 활동성 모니터링내 앱에 들어오는 신규유저도 중요하지만 앱의 성장을 위해서는 유저의 활동성을 높은 수준으로 유지하는게 훨씬 더 중요하다. 여기서 설명하고자 하는 유저 활동성이란 내 앱을 다운받아 사용하고 있는 유저가 앱 내에서 얼마나 활성도를 띄고 있는지를 여러가지 각도에서 모니터링 하는걸 말한다. 크게 다음 3가지 방법이 있다.3-1. Low/Medium/High Activity User Flow유저들을 크게 Low Activity, Medium Activity, High Activity로 구분해서 유저들이 각 그룹에서 얼마나 이동하고 있는지를 데일리로 모니터링 하는 방법이다. 서비스별로 상이하긴 하지만 소셜앱의 경우 보통 정의는 일주일에 6일 이상 앱을 사용하고 있으면 High Activity, 3-5일이면 Medium Activity, 1-2일이면 Low Activity User로 분류한다. 이 플로우 차트는 Fabric을 사용하는 분들이라면 다음 그림과 같이 Daily New Users 탭 하단에서 일별로 확인 가능하다.패브릭을 사용하면 User Activity Flow Chart를 일별로 모니터링 할 수 있다.하지만 위 차트는 최근 한달 데이터밖에 확인이 불가능하기 때문에 필자는 위 숫자를 일별로 크롤해서 엑셀시트에 기록하여 관리하고 있다. 해당 지표가 어느정도 이상이 되야 적정수준인지는 비교가능한 데이터가 없어서 뭐라 말하긴 어렵지만, 본인은 High Activity 비율 약 30% 이상 유지를 목표로 운영중에 있다.High Activity User 비율을 일별로 기록하고 30% 이상 유지를 목표로 운영하고 있다.3-2. 활성도 3종세트 - Sessions per User / Session Duration / Stickiness본인이 개인적으로 앱 활성도 3종세트라고 부르는 지표들이 있다. 바로 1) 유저당 세션 수, 2) 평균 세션 시간, 3) Stickiness 라고 부르는 지표들이다. 하나씩 살펴보도록 하자.우선 유저당 세션수 (Sessions per User)는 보통 총 세션을 하루 유니크 유저수로 나눠서 계산하는데, 패브릭을 포함한 대부분의 툴에서 알아서 모니터링 해준다. 당연히 해당 숫자가 높아야 유저가 내 앱을 자주 찾는다는 뜻이고, 이 숫자 하나로 좋아지는 후행지표들이 수두룩 하다. 활성도에서 가장 주의를 기울여 관리해야 하는 지표이다.평균 세션시간 (Session Duration)은 한개의 세션이 종료될때 까지 평균 시간을 의미하는 지표로서, 역시 패브릭을 포함한 대부분의 툴에서 측정 가능하다. 평균 세션시간은 꼭 무조건 길어야 한다고 생각할 순 없다. 본인 앱의 코어서비스에 따라 다른것인데, 앱 내에서 특정 컨텐츠를 소비하는게 코어인 서비스라면 당연히 평균 세션시간이 짧아서는 곤란할 것이고, 반대로 다른 서비스들로 보내주는 중개 플랫폼 같은 경우나 사람들이 특정 목적이 있을때만 찾는 서비스 등은 평균 세션시간이 짧을 수도 있다.Stickiness는 사용자들이 얼마나 해당 서비스에 충성도를 보이는지를 보여주는 지표로서 보통 DAU/MAU로 계산한다. 해당 수식에서 유추할 수 있듯이 해당 퍼센트가 높을수록, 즉 월 1번 이상 방문자 중 데일리로 1번이상 방문하는 사람의 비율이 높을 수록 해당 앱은 유저들의 충성도가 높은 앱이라는 것을 보여주는 지표인 것이다. 본 수치는 본인이 사용하는 툴에서 보여주는 서비스도 있고 보여주지 않는 경우도 있다. (패브릭은 따로 보여주진 않는다) 이 경우 따로 DAU/MAU로 나눈 비율을 트래킹하면 된다. Stickiness 역시 무조건 높아야만 하는 수치는 아니다. 특히, 본인 서비스의 타겟이 좁을수록, 그리고 특정 타겟의 충성도가 일반적인 사람들에 비해 현저하게 구분되는 경우 이 수치가 낮을 수 있다. 실제로 얼마전 성공적으로 상장한 스냅의 Snapchat의 경우 이 수치가 48%인데, 페이스북의 75%에 비해 현저하게 낮다. 이걸 보고 숫자가 너무 낮아요~~ 이렇게 보면 안되고, 특정 유저 그룹이 열광적으로 반응하는 서비스가 스냅챗이구나~~ 하고 이해해야 한다. 아래 이미지는 요즘 가장 핫한 (틴더가 빠지긴 했지만) 소셜 서비스들의 주요 수치를 비교한 표인데, 스냅챗이 Stickiness와 평균 세션 타임이 현저하게 낮음에도 불구하고 유저당 세션 수가 매우 높은게 흥미롭다.출처: http://www.vertoanalytics.com3-3. User Engagement 지표 만들기위에 언급된 일반적으로 사용하는 지표들 외에 본인 앱의 코어와 관련된 기능들의 Usage Count를 모니터링하여 이를 User Engagement 지표로서 관리하는것도 중요하다. 예를들어 필자가 운영하는 바크 앱의 경우 유저들이 짖어대는 Bark Event Count와 사람들이 올린 드롭바크 포스트에 Happy 또는 Angry를 표현하는 Vote Count가 앱 활성도와 직결되는 기능이라 Bark Event Count + Vote Count를 합해서 User Engagement Count라는 지표를 모니터링 하고 있다.바크 앱은 Bark + Vote Count를 합한 지표를 User Engagement 지표로서 모니터링 하고 있다.4. Retention을 통으로 바라보지 않기알다시피 리텐션은 앱이 지속적으로 성장할 것인가를 가늠하기 위한 가장 중요한 지표이다. 아무리 돈을 처발라서 DAU, MAU를 높여놔도 리텐션이 떨어지면 그 마케팅 활동은 밑 빠진 독에 물 붓는 격이나 다름 없다. 보통 리텐션은 Day 1, Day 7, Day 30 이 3개를 기준으로 모니터링하는데, 중요한건 리텐션을 통으로 바라보는걸 주의해야 한다는 점이다. 무슨 말이냐면, 이 리텐션 데이터의 모수를 전체 유저와 특정 조건값에 해당하는 유저로 나누어서 비교 모니터링 하는게 필요하다는 뜻이다.예를들어 바크 앱과 같이 위치기반 소셜앱의 경우 초기에 리텐션의 모수를 전체 유저로 잡아버리면 리텐션 수치도 형편없을 분더러 중요한건 이 측정된 리텐션을 가지고 뭘 어떻게 해야 이 수치를 개선할 수 있는지가 막막해진다. 왜냐하면 위치기반 소셜앱은 해당 위치에 커뮤니케이션 할 유저가 유의미하게 많아져야 앱의 가치가 발생되는 속성을 지니기 때문이다. 따라서 위치기반 앱들은 특정 타겟 지역을 중심으로 리텐션을 따로 뽑아서 비교 모니터링 하는것이 꼭 필요하다. 바크 앱의 경우 나름의 기준이 있는데, 지역을 2km로 구역화 한 바크 존 내에 액티브 유저가 20명 이상 존재하는 지역을 '활성 바크존'이라고 정의하고, 전체 리텐션과 해당 존의 리텐션을 나눠서 모니터링하고 있다. 이를 통해 활성 바크존 VS 비 활성 바크존을 따로 분리해서 마케팅 활동 및 성과분석이 가능하다.바크는 리텐션을 전체 VS 활성바크존 두개로 나눠서 비교 모니터링하고 있다.5. 바이럴루프가 생기고 있는지 모니터링바이럴 루프의 개념에 대해서는 지난번 작성한 바이럴루프, 중요한건 알겠는데 어떻게 적용할래?글을 참고하길 바란다. 개념이 생소한 분들을 위해 간단히 요약하면 바이럴 루프는 다음과 같은 수식으로 계산된다.% of users who invites (전체 유저 중 추천행위를 하는 유저 비율) ×average number of people who were invited (한명이 끌어오는 유입량) ×% of sent invites accepted (초대를 받았을때 실제 다운로드 받는 비율, 일반적인 컨버젼 비율을 적용해도 관계 없음)이를 통해 계산된 숫자가 1을 넘으면 (즉, 100%를 넘으면) 바이럴 루프가 형성됐다고 부르고, 이게 형성되면 앱은 특별한 마케팅 활동을 하지 않더라도 유저가 알아서 주변 유저를 끌어오고는 레퍼럴 활동만으로도 성장하는 아름다운 그림이 그려진다.본인 앱에 바이럴루프가 생기고 있는지를 모니터링 하려면 우선 유저의 레퍼럴 활동 기작을 만들어주는게 중요하다. 다시말해서 1) 유저가 레퍼럴 활동에 참여하고자 하는 유인을 만들어주고, 2) 이 활동을 쉽게, 그리고 모니터링 가능하게 해주는 앱 내의 추천 인터페이스를 구현, 3) 해당 인터페이스를 통해 발생된 URL에서 발생하는 클릭량을 추적할 수 있는 기작을 만들어줘야 하는 것이다. 강조하지만 자세한 내용은 위의 바이럴 루프 글을 꼭 참고하길 바란다.바크 앱에서는 유저들에게 바크에너지라는 희소성 오브젝트를 통해 유저 추천행위를 하도록 유도하고 있고, 이 유저 추천행위는 앱 내에 URL 생성 버튼을 마련해 놓고, 그 버튼으로 공유할때 마다 해당 유저의 고유넘버가 추적코드로 삽입되도록 설계되어 있다. 해당 레퍼럴 활동에 참여하는 유저 수와 해당 유저가 끌어오는 유입량은 데일리로 모니터링해서 슬랙으로 알림을 띄우고 있다.바크는 앱 내에 공유버튼을 만들고 이를 클릭하면 자동으로 유저 고유 넘버가 추적코드로 삽입되는 공유 버튼을 만들어 운영하고 있다.본인 앱이 스냅챗 수준으로 사람들이 열광하는 앱이라면야 바이럴 지수가 항상 1이 넘겠지만, 대부분은 그렇지 않은게 현실이다. 즉, 이 숫자가 1이 넘을때도 아닐때도 있는데 중요한 점은, 유저의 레퍼럴 행위를 촉진할 수 있는 인터페이스 (혹은 마케팅 활동)을 기획하고, 해당 기획안이 실행됐을 때 바이럴 지수가 어떻게 변동하는지를 측정해서 가장 성과가 좋은 행위에 선택-집중할 수 있는 근거 데이터로 활용해야 한다는 것이다.일별로 바이럴지수를 모니터링하고, 이 활동을 촉진시킬 수 있는 각종 활동의 성과 분석 지표로 활용하는게 필요하다.이번 글에서는 초기 앱을 운영하는 스타트업이나 PM이 앱 서비스의 성장을 위해 어떤 지표들을 관리해야 하고, 이를 획득하는 방법, 그리고 실제 마케팅 및 앱 기획 활동의 근거 데이터로 활용하는 방법론에 대해 소개해 봤다. 다 읽고 나면 느끼겠지만, 초기 앱이 성장하는 바이럴 루프는 초보 PM이 알아야 하는 초기 모바일앱 분석 101 글에서 언급한 1) Acquisition (획득) -> 2) Retention (유지) -> 3) Referral (추천)으로 연결되는 큰 그림을 그릴 수 있느냐, 그리고 이 그림을 그리기 위해 어떤 활동들이 테스트되고 선택-집중의 사이클을 타고 있는지를 데이터에 근거해서 운영하고 있는가에 달려있다고 할 수 있다. 다시말해서, DAU니 MAU니를 따지고 있을 시간에 저 순환 루프가 형성되고 있는지를 따지고 있으라는 얘기이다.** 본 글은 문돌이 PM의 마케터 따라하기 시리즈 입니다.** 1화 보기 - 초기에 할만한 ASO (앱스토어 최적화) 팁** 2화 보기 - 초보 PM이 알아야 하는 초기 모바일앱 분석 101** 3화 보기 - 스타트업 브랜딩: 내가 보는 나와 너가 보는 나의 일치** 4화 보기 - 홍보영상 직접 제작해서 수백만원 절약해보자** 5화 보기 - 바이럴루프, 중요한건 알겠는데 어떻게 적용할래?** 6화 보기 - 인스타그램 노가다 마케팅 101** 7화 보기 - 문돌이도 간지나는 HTML 이메일좀 보내보자** 8화 보기 - 인스타 마케팅 헛수고를 줄이는 10가지 마케팅 방법론** 9화 보기 - 초기 스타트업의 무료 마케팅 채널** 10화 보기 - 프리미엄병에 걸리지 말자글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기

비트윈에서는 HBase를 메인 데이터베이스로 이용하고 있습니다. 유저 및 커플에 대한 정보와 커플들이 주고받은 메시지, 업로드한 사진 정보, 메모, 기념일, 캘린더 등 서비스에서 만들어지는 다양한 데이터를 HBase에 저장합니다. HBase는 일반적인 NoSQL과 마찬가지로 스키마를 미리 정의하지 않습니다. 대신 주어진 API를 이용해 데이터를 넣기만 하면 그대로 저장되는 성질을 가지고 있습니다. 이런 점은 데이터의 구조가 바뀔 때 별다른 스키마 변경이 필요 없다는 등의 장점으로 설명되곤 하지만, 개발을 쉽게 하기 위해서는 데이터를 저장하는데 어느 정도의 규칙이 필요합니다. 이 글에서는 비트윈이 데이터를 어떤 구조로 HBase에 저장하고 있는지에 대해서 이야기해 보고자 합니다.비트윈에서 HBase에 데이터를 저장하는 방법¶Thrift를 이용해 데이터 저장: Apache Thrift는 자체적으로 정의된 문법을 통해 데이터 구조를 정의하고 이를 직렬화/역직렬화 시킬 수 있는 기능을 제공합니다. 비트윈에서는 서버와 클라이언트가 통신하기 위해 Thrift를 이용할 뿐만 아니라 HBase에 저장할 데이터를 정의하고 데이터 저장 시 직렬화를 위해 Thrift를 이용합니다.하나의 Row에 여러 Column을 트리 형태로 저장: HBase는 Column-Oriented NoSQL로 분류되며 하나의 Row에 많은 수의 Column을 저장할 수 있습니다. 비트윈에서는 Column Qualifier를 잘 정의하여 한 Row에 여러 Column을 논리적으로 트리 형태로 저장하고 있습니다.추상화된 라이브러리를 통해 데이터에 접근: 비트윈에서는 HBase 클라이언트 라이브러리를 직접 사용하는 것이 아니라 이를 래핑한 Datastore라는 라이브러리를 구현하여 이를 이용해 HBase의 데이터에 접근합니다. GAE의 Datastore와 인터페이스가 유사하며 실제 저장된 데이터들을 부모-자식 관계로 접근할 수 있게 해줍니다.트랜잭션을 걸고 데이터에 접근: HBase는 일반적인 NoSQL과 마찬가지로 트랜잭션을 제공하지 않지만 비트윈에서는 자체적으로 제작한 트랜잭션 라이브러리인 Haeinsa를 이용하여 Multi-Row ACID 트랜잭션을 걸고 있습니다. Haeinsa 덕분에 성능 하락 없이도 데이터 무결성을 유지하고 있습니다.Secondary Index를 직접 구현: HBase에서는 데이터를 Row Key와 Column Qualifier를 사전식 순서(lexicographical order)로 정렬하여 저장하며 정렬 순서대로 Scan을 하거나 바로 임의 접근할 수 있습니다. 하지만 비트윈의 어떤 데이터들은 하나의 Key로 정렬되는 것으로는 충분하지 않고 Secondary Index가 필요한 경우가 있는데, HBase는 이런 기능을 제공하지 않고 있습니다. 비트윈에서는 Datastore 라이브러리에 구현한 Trigger을 이용하여 매우 간단한 형태의 Secondary Index를 만들었습니다.비트윈 HBase 데이터 구조 해부¶페이스북의 메시징 시스템에 관해 소개된 글이나, GAE의 Datastore에 저장되는 구조를 설명한 글을 통해 HBase에 어떤 구조로 데이터를 저장할지 아이디어를 얻을 수 있습니다. 비트윈에서는 이 글과는 약간 다른 방법으로 HBase에 데이터를 저장합니다. 이에 대해 자세히 알아보겠습니다.전반적인 구조¶비트윈에서는 데이터를 종류별로 테이블에 나누어 저장하고 있습니다. 커플과 관련된 정보는 커플 테이블에, 유저에 대한 정보는 유저 테이블에 나누어 저장합니다.각 객체와 관련된 정보는 각각의 HBase 테이블에 저장됩니다.또한, 관련된 데이터를 하나의 Row에 모아 저장합니다. 특정 커플과 관련된 사진, 메모, 사진과 메모에 달린 댓글, 기념일 등의 데이터는 해당 커플과 관련된 하나의 Row에 저장됩니다. Haeinsa를 위한 Lock Column Family를 제외하면, 데이터를 저장하기 위한 용도로는 단 하나의 Column Family만 만들어 사용하고 있습니다.각 객체의 정보와 자식 객체들은 같은 Row에 저장됩니다.또한, 데이터는 기본적으로 하나의 Column Family에 저장됩니다.이렇게 한 테이블에 같은 종류의 데이터를 모아 저장하게 되면 Region Split하는 것이 쉬워집니다. HBase는 특정 테이블을 연속된 Row들의 집합인 Region으로 나누고 이 Region들을 여러 Region 서버에 할당하는 방식으로 부하를 분산합니다. 테이블을 Region으로 나눌 때 각 Region이 받는 부하를 고려해야 하므로 각 Row가 받는 부하가 전체적으로 공평해야 Region Split 정책을 세우기가 쉽습니다. 비트윈의 경우 커플과 관련된 데이터인 사진이나 메모를 올리는 것보다는 유저와 관련된 데이터인 메시지를 추가하는 트래픽이 훨씬 많은데, 한 테이블에 커플 Row와 유저 Row가 섞여 있다면 각 Row가 받는 부하가 천차만별이 되어 Region Split 정책을 세우기가 복잡해집니다. RegionSplitPolicy를 구현하여 Region Split 정책을 잘 정의한다면 가능은 하지만 좀 더 쉬운 방법을 택했습니다.또한, 한 Row에 관련된 정보를 모아서 저장하면 성능상 이점이 있습니다. 기본적으로 한 커플에 대한 데이터들은 하나의 클라이언트 요청을 처리하는 동안 함께 접근되는 경우가 많습니다. HBase는 같은 Row에 대한 연산을 묶어 한 번에 실행시킬 수 있으므로 이 점을 잘 이용하면 성능상 이득을 얻을 수 있습니다. 비트윈의 데이터 구조처럼 특정 Row에 수많은 Column이 저장되고 같은 Row의 Column들에 함께 접근하는 경우가 많도록 설계되어 있다면 성능 향상을 기대할 수 있습니다. 특히 Haeinsa는 한 트랜잭션에 같은 Row에 대한 연산은 커밋시 한 번의 RPC로 묶어 처리하므로 RPC에 드는 비용을 최소화합니다. 실제 비트윈에서 가장 많이 일어나는 연산인 메시지 추가 연산은 그냥 HBase API를 이용하여 구현하는 것보다 Haeinsa Transaction API를 이용해 구현하는 것이 오히려 성능이 좋습니다.Column Qualifier의 구조¶비트윈은 커플들이 올린 사진 정보들을 저장하며, 또 사진들에 달리는 댓글 정보들도 저장합니다. 한 커플을 Root라고 생각하고 커플 밑에 달린 사진들을 커플의 자식 데이터, 또 사진 밑에 달린 댓글들을 사진의 자식 데이터라고 생각한다면, 비트윈의 데이터들을 논리적으로 트리 형태로 생각할 수 있습니다. 비트윈 개발팀은 Column Qualifier를 잘 정의하여 실제로 HBase에 저장할 때에도 데이터가 트리 형태로 저장되도록 설계하였습니다. 이렇게 트리 형태로 저장하기 위한 Key구조에 대해 자세히 알아보겠습니다.Column Qualifier를 설계할 때 성능을 위해 몇 가지 사항들을 고려해야 합니다. HBase에서는 한 Row에 여러 Column이 들어갈 수 있으며 Column들은 Column Qualifier로 정렬되어 저장됩니다. ColumnRangeFilter를 이용하면 Column에 대해 정렬 순서로 Scan연산이 가능합니다. 이 때 원하는 데이터를 순서대로 읽어야 하는 경우가 있는데 이를 위해 Scan시, 최대한 Sequential Read를 할 수 있도록 설계해야 합니다. 또한, HBase에서 데이터를 읽어올 때, 실제로 데이터를 읽어오는 단위인 Block에 대해 캐시를 하는데 이를 Block Cache라고 합니다. 실제로 같이 접근하는 경우가 빈번한 데이터들이 최대한 근접한 곳에 저장되도록 설계해야 Block Cache의 도움을 받을 수 있습니다.비트윈에서는 특정 커플의 사진이나 이벤트를 가져오는 등의 특정 타입으로 자식 데이터를 Scan해야하는 경우가 많습니다. 따라서 특정 타입의 데이터를 연속하게 저장하여 최대한 Sequential Read가 일어나도록 해야 합니다. 이 때문에 Column Qualifier가 가리키는 데이터의 타입을 맨 앞에 배치하여 같은 타입의 자식 데이터들끼리 연속하여 저장되도록 하였습니다. 만약 가리키는 데이터의 타입과 아이디가 Parent 정보 이후에 붙게 되면 사진 사이사이에 각 사진의 댓글 데이터가 끼어 저장됩니다. 이렇게 되면 사진들에 대한 데이터를 Scan시, 중간중간 저장된 댓글 데이터들 때문에 완벽한 Sequential Read가 일어나지 않게 되어 비효율적입니다.이렇게 특정 타입의 자식들을 연속하게 모아 저장하는 묶음을 컬렉션이라고 합니다. 컬렉션에는 컬렉션에 저장된 자식들의 개수나 새로운 자식을 추가할 때 발급할 아이디 등을 저장하는 Metadata가 있습니다. 이 Metadata도 특정 Column에 저장되므로 Metadata를 위한 Column Qualifier가 존재합니다. 이를 위해 Column Qualifier에는 Column Qualifier가 자칭하는 데이터가 Metadata인지 표현하는 필드가 있는데, 특이하게도 메타데이터임을 나타내는 값이 1이 아니라 0입니다. 이는 Metadata가 컬렉션의 맨 앞쪽에 위치하도록 하기 위함입니다. 컬렉션을 읽을 때 보통 맨 앞에서부터 읽는 경우가 많고, 동시에 Metadata에도 접근하는 경우가 많은데, 이 데이터가 인접하게 저장되어 있도록 하여 Block Cache 적중이 최대한 일어나도록 한 것입니다.Datastore 인터페이스¶비트윈에서는 이와 같은 데이터 구조에 접근하기 위해 Datastore라는 라이브러리를 구현하여 이를 이용하고 있습니다. HBase API를 그대로 이용하는 것보다 좀 더 쉽게 데이터에 접근할 수 있습니다. GAE의 Datastore와 같은 이름인데, 실제 인터페이스도 매우 유사합니다. 이 라이브러리의 인터페이스에 대해 간단히 알아보겠습니다.Key는 Datastore에서 HBase에 저장된 특정 데이터를 지칭하기 위한 클래스입니다. 논리적으로 트리 형태로 저장된 데이터 구조를 위해 부모 자식 관계를 이용하여 만들어 집니다.Key parentKey = new Key(MType.T_RELATIONSHIP, relId);Key photoKey = new Key(parentKey, MType.T_PHOTO, photoId); // 특정 커플 밑에 달린 사진에 대한 키Datastore는 Key를 이용해 Row Key와 Column Qualifier를 만들어 낼 수 있습니다. Datastore는 이 정보를 바탕으로 HBase에 새로운 데이터를 저장하거나 저장된 데이터에 접근할 수 있는 메서드를 제공합니다. 아래 코드에서 MUser 클래스는 Thrift로 정의하여 자동 생성된 클래스이며, Datastore에서는 이 객체를 직렬화 하여 HBase에 저장합니다.MUser user = new MUser();user.setNickname("Alice");user.setGender(Gender.FEMALE);user.setStatus("Hello World!"); Key userKey = new Key(MType.T_USER, userId);getDatastore().put(userKey, user);user = getDatastore().get(userKey);getDatastore().delete(userKey);또한, Datastore는 Key를 범위로 하여 Scan연산이 할 수 있도록 인터페이스를 제공합니다. Java에서 제공하는 Try-with-resource문을 이용하여 ResultScanner를 반드시 닫을 수 있도록 하고 있습니다. 내부적으로 일단 특정 크기만큼 배치로 가져오고 더 필요한 경우 더 가져오는 식으로 구현되어 있습니다.try (CloseableIterable> entries = getDatastore().subSibling(fromKey, fromInclusive, toKey, toInclusive)) { for (KeyValue entry : entries) { // do something }}Secondary Index 구현 방법¶HBase는 데이터를 Row Key나 Column Qualifier로 정렬하여 저장합니다. 이 순서로만 Sequential Read를 할 수 있으며 Key값을 통해 특정 데이터를 바로 임의 접근할 수 있습니다. 비트윈에서는 특정 달에 해당하는 이벤트들을 읽어오거나 특정 날짜의 사진들의 리스트를 조회하는 등 id 순서가 아니라 특정 값을 가지는 데이터를 순서대로 접근해야 하는 경우가 있습니다. 이럴 때에도 효율적으로 데이터에 접근하기 위해서는 id로 정렬된 것 외에 특정 값으로 데이터를 정렬할 수 있어야 합니다. 하지만 HBase에서는 이와 같은 Secondary Index 같은 기능을 제공하지 않습니다. 비트윈 개발팀은 이에 굴하지 않고 Secondary Index를 간단한 방법으로 구현하여 사용하고 있습니다.구현을 간단히 하기 위해 Secondary Index를 다른 데이터들과 마찬가지로 특정 타입의 데이터로 취급하여 구현하였습니다. 따라서 Index에 대해서도 Column Qualifier가 발급되며, 이때, Index에 해당하는 id를 잘 정의하여 원하는 순서의 Index를 만듭니다. 이런 식으로 원하는 순서로 데이터를 정렬하여 저장할 수 있으며 이 인덱스를 통해 특정 필드의 값의 순서대로 데이터를 조회하거나 특정 값을 가지는 데이터에 바로 임의 접근할 수 있습니다. 또한, Index에 실제 데이터를 그대로 복사하여 저장하여 Clustered Index처럼 동작하도록 하거나, Reference만 저장하여 Non-Clustered Index와 같이 동작하게 할 수도 있습니다. Datastore 라이브러리에는 특정 데이터가 추가, 삭제, 수정할 때 특정 코드를 실행할 수 있도록 Trigger 기능이 구현되어 있는데, 이를 통해 Index를 업데이트합니다. 데이터의 변경하는 연산과 Index를 업데이트하는 연산이 하나의 Haeinsa 트랜잭션을 통해 원자적으로 일어나므로 데이터의 무결성이 보장됩니다.못다 한 이야기¶각 테이블의 특정 Row의 Column들에 대한 Column Qualifier외에도 Row에 대한 Row Key를 정의 해야 합니다. 비트윈에서는 각 Row가 표현하는 Root객체에 대한 아이디를 그대로 Row Key로 이용합니다. 새로운 Root객체가 추가될 때 발급되는 아이디는 랜덤하게 생성하여 객체가 여러 Region 서버에 잘 분산될 수 있도록 하였습니다. 만약 Row Key를 연속하게 발급한다면 특정 Region 서버로 연산이 몰리게 되어 성능 확장에 어려움이 생길 수 있습니다.데이터를 저장할 때 Thrift를 이용하고 있는데, Thrift 때문에 생기는 문제가 있습니다. 비트윈에서 서버를 업데이트할 때 서비스 중지 시간을 최소화하기 위해 롤링 업데이트를 합니다. Thrift 객체에 새로운 필드가 생기는 경우, 롤링 업데이트 중간에는 일부 서버에만 새로운 Thift가 적용되어 있을 수 있습니다. 업데이트된 서버가 새로운 필드에 값을 넣어 저장했는데, 아직 업데이트가 안 된 서버가 이 데이터를 읽은 후 데이터를 다시 저장한다면 새로운 필드에 저장된 값이 사라지게 됩니다. Google Protocol Buffer의 경우, 다시 직렬화 할 때 정의되지 않은 필드도 처리해주기 때문에 문제가 없지만, Thrift의 경우에는 그렇지 않습니다. 비트윈에서는 새로운 Thrift를 적용한 과거 버전의 서버를 먼저 배포한 후, 업데이트된 서버를 다시 롤링 업데이트를 하는 식으로 이 문제를 해결하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 [email protected]로 이메일을 주시기 바랍니다!

젊은 꼰대가 더 노답인 이유'꼰대는 나이의 문제가 아니라 공감능력의 문제다.' 「무례한 사람에게 웃으며 대처하는 법」의 저자인 정문정 작가의 말이다. 몇번을 곱씹어 봐도 맞는 말이다. 적어도 내가 살아온 시간을 더듬어 보면 나이든 꼰대도 많았지만 또래인 꼰대도 적지 않았다. 특유의 허세와 과시가 불편했고 그들을 이해하기 위한 노력은 몇 배 더 힘들었다. 꼰대는 어디서든 환영받지 못한brunch.co.kr/@moonkka/30 새벽에 이 글을 읽었다.많은 호응과 인기가 있는 것을 보고 조금 안타까운 마음이 들었다. 언젠가부터 우리 사회의 추가 한 쪽으로 기울어져 있는 것은 아닌가하는 생각이 든다.공감과 부정. 따뜻함과 냉철함.안정과 성장.이 모든 것들은 서로 무엇이 더 중요하다고 말할 것도 없이 중요한 부분이며 균형을 이뤄야 한다고 생각한다. 그리고 사람 개개인의 가치관에 따라 그것이 조금 기울어질 수 있을지언정, 사회 전체의 기류에 있어 균형이 깨질 경우엔, 그것은 문제가 될 수 있다.내가 처음 창업했을 때 내 주변에는 나보다 어린 사람이 없었다. 주변의 형들, 형님들, 사장님들의 98%는 나를 동생처럼 여겼다. 그들은 나를 거리낌 없이 혼내고 조언해줬다. 물론 누가 싫은 소리를 하면 기분이 좋지는 않다. 당시엔 나도 크게 저항했고 지금도 그렇다. 그러나 늘, 돌이켜 생각하면 큰 천운이며, 인복인 것 같다.순간적인 감정을 조절하지 못하고 대들어서 감정적으로 상대방의 지혜를 막아서버린 자신에 대한 후회만 들 뿐이다.위 글에서 저자는 남의 일에 간섭하는 사람을 꼰대라고 표현했는데, 자신에게 공감만 할 줄 아는 사람만 내 측근으로 두게되면 지금의 내가 갖고 있는 시야 밖을 잘 보지 못한다. 누군가 내 일에 간섭하고 비판해주는 것은 무료 컨설팅과 똑같다. 글쓴이가 표현하는 ‘꼰대질’은 생각보다 큰 에너지를 필요로 한다. 숨가쁘게 남에 대해 조언해주다 보면 힘이 빠진다. 그 정도로 그 사람의 입장에서 내 시각을, 조언을 전달해줘야하는 매우 고차원적인 작업이다. 그 에너지를 누군가 나에게 주는 것 만으로 돌이켜보면 감사할 뿐이다.나이가 들면서 옛날만큼 날 혼내는 사람은 점점 줄어드는 것 같다. 그리고 언젠가는 나도 이런 기회를 더 많이 잃어버릴 것이다. 누군가로부터 훈계를 받고, 지혜를 얻고 성장하는데도 시기가 있는 것이다.언젠가부터 우리 사회는 ‘공감’을 최우선의 가치로 여기고 나머지는 모두 ‘꼰대질, 간섭’으로 묶어 평가절하 하는 것 같다.지식은 누구의 기분도 상하게 하지 않으나, 지혜는 때로는 우리의 심리적 안락에 위해를 가한다.지식은 난무하되 지혜는 없는 세상으로 가고자 하는 것이 맞는 것일까? 왜 성공한 사람들은 지금의 고통받는 사람들에게 공감을 해주고 거기서 멈추는 것일까. 왜 사람들이 원하는 이야기들만 해주고, 절대 다수로부터 사랑받고 싶은걸까.그들은 무엇으로 성공의 가도에 올랐을까. 무슨 지혜를, 무슨 이야기를 듣고 남들에게 자신의 의견을 말할 수 있는 위치까지 올라갔을까.왜 그 이야기는 하지 않는 것일까.나름대로의 성공을 하여 세상이 아름답게 보이면, 그 아름다운 세상을 보지못하는 사람들에 대한 연민이 생기는 걸까?꼰대소리를 듣기 싫어 조언을 잘 안하는 사람들도 이제 아주 많아졌다. 균형은 깨져가고 세대간 갈등은 심화되고 있다. 나와 같은 젊은층의 심리적 안락도 중요하지만, 선대의 지혜를 흡수하고 전수받는 것도 중요하다. 균형은 깨져선 안된다.나는 원래 꼰대라는 말을 싫어한다.그리고 정말 아쉽게도, 나는 이 분이 말하는 젊은 꼰대의 부류다.

Kubernetes 클러스터를 상용 환경에서 운영하기 위해서는 몇 가지 추가 구성요소를 설치해야 합니다. 예를 들어 Ingress를 만들더라도 실제로 트래픽을 받아줄 Ingress Controller를 설치해두지 않았으면 소용이 없습니다. 그리고 모니터링을 위해 컨테이너의 로그나 CPU/메모리 사용량 등을 수집, 조회할 수 있는 서비스도 필요합니다.다행히 이러한 추가 구성요소 또한 Kubernetes 클러스터 위에서 일반 애플리케이션과 거의 같은 방식으로 작동하므로 설치하는 것이 어렵지는 않습니다. 다만 클러스터를 원하는 대로 구성할 수 있는 만큼 선택의 폭이 넓어서 여러 가지 해법을 놓고 고민하게 될 수 있습니다. 이 글에서는 타다 서비스를 위해 Kubernetes 클러스터를 구성할 때 어떤 선택을 했는지, 특히 AWS 환경에서는 어떤 서비스들을 활용할 수 있는지 공유합니다.서비스를 외부에 노출: NGINX Ingress Controller + NLBIngress Controller 고르기Kubernetes에서 클러스터 내부 서비스를 외부에 HTTP(S)로 노출할 때는 Ingress를 사용할 수 있습니다. TLS 암호화, 로드밸런싱, 호스트명/경로 기반 라우팅 등을 제공해서 상당히 편리한데, Ingress가 실제로 작동하기 위해서는 Ingress Controller가 필요합니다.시중에는 다양한 종류의 Ingress Controller 솔루션이 나와 있습니다. 그중 Kubernetes 프로젝트에서 공식 지원하는 NGINX Ingress Controller와 AWS ALB 로드밸런서를 이용하는 AWS ALB Ingress Controller를 두고 고민을 했습니다.타다에서는 클라이언트(모바일 앱)에 실시간 이벤트를 전달하기 위해 gRPC를 사용하고 있어서 gRPC를 지원하지 않는 ALB는 선택할 수 없었습니다. 그리고 AWS ALB Ingress Controller는 현재 Ingress 하나마다 ALB를 1개 생성하는 구조여서 앞으로 노출할 서비스 수가 늘어난다면 비용 효율이 떨어진다고 판단했습니다. 따라서 NGINX Ingress Controller를 선택하게 되었습니다.NGINX Ingress Controller는 NGINX 웹서버를 기반으로 하므로 gRPC 모듈을 비롯하여 다양한 NGINX 모듈을 통해 굉장히 세세한 부분까지 설정할 수 있습니다. NGINX Ingress Controller는 Ingress나 Ingress가 가리키는 서비스의 엔드포인트에 변화가 생길 때마다 동적으로 NGINX 설정을 업데이트하는 방식으로 동작합니다.NGINX Ingress Controller 로드밸런싱NGINX Ingress Controller를 사용해도 외부에서 오는 트래픽을 적절히 분배해 줄 외부 로드밸런서는 필요합니다. AWS의 로드밸런서는 Classic ELB, ALB, NLB가 있습니다. 앞서 설명했듯이 ALB는 gRPC를 지원하지 않아서 Classic ELB를 TCP 모드로 사용하거나 NLB를 사용해야 합니다. Classic ELB는 동시에 많은 연결을 처리하려면 웜 업이 필요한 단점이 있어 NLB를 사용하기로 하였습니다.최근 NLB가 TLS termination을 지원하기 시작했지만, HTTP/2와 gRPC를 사용하기 위해 필요한 ALPN 정보를 설정할 수 없어서 NGINX 수준에서 TLS 암호화를 처리하고 있습니다. NLB 수준에서 TLS 처리를 하면 무료로 자동 갱신되는 ACM 인증서를 사용할 수 있는 등 여러 가지 이점이 있어서 아쉽습니다.Kubernetes에서 LoadBalancer 타입의 서비스를 생성하면 알아서 AWS 로드밸런서를 만들어줍니다. 하지만 이렇게 해서 NLB를 생성하는 방식은 아직 알파 기능입니다. 따라서 먼저 NodePort 타입의 서비스를 생성하여 모든 노드의 특정 포트에 NGINX를 노출한 다음, 별도로 생성한 NLB에 노드들이 속한 오토스케일링 그룹을 연결해주는 방식으로 직접 설정하게 되었습니다.정리해보면 외부에서 오는 트래픽을 처리할 때는 다음과 같은 과정을 거칩니다.모든 서브도메인(*.tadatada.com)은 NLB를 가리킵니다.NLB의 443 포트로 암호화된 HTTP 또는 gRPC 요청이 들어옵니다. NLB는 적절한 Kubernetes 노드 중 하나의 특정 포트(예: 30000번)로 요청을 전달합니다.Kubernetes 노드에서는 포트 번호를 보고 NGINX 서비스로 향하는 요청임을 알 수 있고 NGINX 컨테이너 중 하나로 요청을 전달합니다.NGINX는 복호화를 한 다음 HTTP Host 헤더를 확인하여 요청을 전달할 Ingress를 알아냅니다. 그리고 해당 Ingress의 엔드포인트 중 하나로 복호화한 요청을 프록시합니다.애플리케이션 컨테이너가 요청을 처리합니다.트래픽 흐름: NLB → NodePort → NGINX Ingress Controller → 내부 서비스Pod에 IAM 역할 부여: kube2iamS3, SQS 등 IAM으로 인증하는 AWS 서비스에 접근하려면 인증 정보가 필요합니다. EC2에서는 액세스 키를 직접 넣는 대신 EC2 인스턴스 프로파일로 인스턴스에 IAM 역할을 부여할 수 있습니다. 하지만 하나의 Kubernetes 노드 (=EC2 인스턴스)에는 여러 Pod이 실행될 수 있기 때문에 Pod마다 다른 IAM 역할을 부여하기를 원한다면 인스턴스 프로파일을 활용할 수 없게 됩니다. (인스턴스 프로파일에는 하나의 IAM 역할만 부여 가능)kube2iam을 사용하면 다음과 같이 Pod 어노테이션으로 IAM 역할을 지정할 수 있습니다.apiVersion: v1 kind: Pod metadata: name: aws-cli labels: name: aws-cli annotations: iam.amazonaws.com/role: role-arn spec: ... 설치나 사용법은 문서를 참고하면 어렵지 않은데, 원리를 간단히 설명해 보겠습니다. EC2 인스턴스 안에서는 특정 IP 주소(169.254.169.254)로 접속하면 EC2 메타데이터 API에 접근할 수 있습니다. AWS SDK는 EC2 메타데이터 API를 통해서 인스턴스 프로파일에 붙은 IAM 역할과 IAM 역할에 해당되는 액세스 키 쌍을 받아오게 됩니다.kube2iam은 모든 노드에 실행되면서 Pod 내부에서 EC2 메타데이터 서버 주소로 나가는 모든 요청을 가로챕니다. 그리고 인스턴스 프로파일 정보와 액세스 키 발급 요청을 kube2iam 서버가 대신 처리합니다. 따라서 Pod 안에서는 인스턴스 프로파일이 부여된 EC2 인스턴스 내부에 있는 것처럼 느껴지게 됩니다.추후 AWS SDK에 EKS 지원이 추가되면 별도로 데몬을 설치하지 않고도 Pod에 IAM 역할을 줄 수 있게 될 것으로 보입니다.로그 수집: fluentd + CloudWatch LogsKubernetes의 컨테이너가 stdout/stderr로 출력하는 로그는 노드에만 쌓이고 컨테이너를 재시작하거나 삭제하면 함께 삭제됩니다. 또한 노드의 디스크가 꽉 차는 것을 방지하기 위해 일정 크기를 넘으면 오래된 로그는 없어집니다. 그러므로 로그가 사라지지 않도록 계속 어딘가에 모아두어야 합니다.AWS에서 활용할 수 있는 로그 저장 서비스에는 CloudWatch Logs가 있습니다. fluentd를 DaemonSet으로 노드마다 하나씩 실행해서 컨테이너 로그를 CloudWatch Logs로 전송할 수 있습니다.CloudWatch Logs에 저장한 로그는 최근 나온 CloudWatch Logs Insights로 검색, 분석할 수 있습니다. 아직 나온 지 얼마 되지 않아서 기능이 많지는 않지만, 간단히 조회하는 용도로는 충분합니다.CloudWatch Logs Insights 사용 예모니터링: PrometheusEC2 인스턴스 하나에 서비스 하나를 띄워서 사용할 때는 CloudWatch로 CPU 사용률 등의 지표를 측정할 수 있었습니다. 하지만 Kubernetes를 사용하면 여러 서비스가 하나의 인스턴스에서 동시에 실행될 것이므로 인스턴스 수준의 지표는 무의미합니다. 특히 최소 실행 단위인 컨테이너 수준의 CPU 사용률 같은 값을 측정해야 하는데, CloudWatch를 사용하기에는 과금 체계가 적합하지 않습니다.기본 제공되는 5분 간격의 EC2 지표는 무료지만 CloudWatch에 커스텀 지표를 올리게 되면 지표 당 비용을 지불해야 합니다. 이 때 '지표'는 지표 이름 + 고유한 차원(dimension)의 조합입니다. 예를 들어 CPUUtilization이라는 이름의 지표가 PodName=server-aaaaaaaa과 PodName=server-bbbbbbbb라는 다른 차원으로 올라온다면 각각을 다른 지표로 취급합니다. 따라서 지표 수가 너무 많아지지 않게 조정해야 하는데 그러면 상세하게 모니터링하기가 어렵습니다.비용 문제도 있고, Kubernetes의 여러 가지 정보를 CloudWatch로 내보내는 기존 도구가 없었기 때문에 다른 방법을 찾아보게 되었습니다. 그래서 Kubernetes 모니터링을 위해 많이 사용하는 Prometheus를 선택했습니다. Prometheus를 온전히 사용하기 위해서는 다양한 컴포넌트들이 필요한데, Prometheus Operator Helm 차트를 사용하면 비교적 쉽게 구축할 수 있습니다.Prometheus는 Kubernetes 클러스터 모니터링 외에 애플리케이션 모니터링에도 사용할 수 있습니다. 타다의 애플리케이션들은 Spring Boot로 작성되어 있는데 Spring Boot Actuator와 Micrometer의 Prometheus 지원을 사용해서 애플리케이션 수준의 지표도 Prometheus로 모니터링하고 있습니다. 특히 Prometheus Operator를 사용하면 모니터링 대상을 추가할 때 Prometheus 설정 파일을 수정하지 않아도 Kubernetes에 ServiceMonitor 리소스를 등록하기만 하면 되어서 편리합니다.Prometheus로 수집된 지표는 Grafana 대시보드로 시각화하고, 정해진 조건에서 Alertmanager를 통해 PagerDuty와 Slack에 알림을 보냅니다.Grafana 대시보드의 모습자동 처리량 확장: Cluster AutoscalerKubernetes에서 자동 처리량 확장은 크게 두 종류로 나눌 수 있습니다. 먼저 Horizontal Pod Autoscaler로 CPU, 메모리 사용량에 따라 Pod의 수를 자동으로 조정할 수 있습니다. HPA가 실제로 동작하기 위해서는 오토스케일링을 위한 지표를 제공하는 Metrics Server를 설치해야 합니다. 그런데 부하가 증가해서 HPA가 Pod 수를 늘리려고 할 때 워커 노드에 여유가 충분하지 않으면 새로운 Pod을 실행할 수 없어서 소용이 없습니다. 이 때 워커 노드의 수를 자동으로 조정해주는 것이 Cluster Autoscaler입니다. Cluster Autoscaler는 노드 수를 증가시키기만 하는 것이 아니라 여유가 생겼을 때 노드 수를 자동으로 줄여서 불필요한 비용이 발생하지 않도록 해줍니다.AWS 환경에서 Cluster Autoscaler는 EC2 API를 통해 EC2 오토스케일링 그룹의 Desired Capacity 값을 필요한 노드 수로 조정하는 방식으로 작동합니다. 따라서 Cluster Autoscaler에는 EC2 API를 호출할 수 있는 IAM 권한을 주어야 합니다. 이를 위해 위에서 소개한 kube2iam을 사용할 수 있습니다. 그리고 Cluster Autoscaler가 오토스케일링 그룹을 자동으로 발견할 수 있도록 미리 정해진 태그를 붙여야 합니다.한 가지 주의할 점은 노드의 오토스케일링 그룹이 여러 가용 영역(AZ)에 걸쳐있으면 안 된다는 것입니다. 오토스케일링 그룹이 여러 AZ에 속한 경우 AZ 간 인스턴스 수의 균형을 맞추려고 하는데 이 과정에서 인스턴스가 예기치 않게 종료될 수 있습니다. 이 때 해당 노드에 실행되어 있던 Pod이 안전하게 종료되지 않을 수 있기 때문에 AZ마다 오토스케일링 그룹을 따로 만들고 AZ 간 균형은 Cluster Autoscaler가 맞추도록 설정해야 합니다.도움이 되는 링크들위에서 소개한 컴포넌트들은 다음과 같은 Helm 차트를 통해 설치해서 사용하고 있습니다.stable/nginx-ingressstable/kube2iamincubator/fluentd-cloudwatchstable/prometheus-operatorstable/metrics-serverstable/cluster-autoscalerEKS Workshop: AWS 환경에서 Kubernetes 운영할 때 참고할 만한 정보가 많이 있습니다.Kubernetes Slack 채널: #eks 채널에는 AWS 직원들도 접속해 있어서 높은 확률로 답변을 받을 수 있습니다.