스토리 홈

인터뷰

피드

뉴스

조회수 1217

옐로쇼핑미디어 그룹의 팀그레이프 최초 멤버, ‘임용택 PM’을 만나다

안녕하세요, 옐로모바일 사내기자 Y입니다! 옐로가족들의 숨은 매력과 스토리를 발굴해 소개하는 옐로인 인터뷰 네 번째 이야기입니다! 네 번째 옐로피플 주인공은 패션의, 패션에 의한, 패션을 위한 남자! 설립 6개월만에 85억원 규모의 투자를 유치하며 경쟁력을 입증한 패션 이커머스 기업 ‘팀그레이프’에서 엘레뉴를 담당하고 있는 ‘임용택 PM’입니다! 넘치는 패션센스로 대학생때부터 직접 본인의 옷을 만들어 입었다는 사연부터 팀그레이프의 최초 멤버로 합류하기까지…… 임용택 PM이 들려주는 옐로피플 스토리! 지금 바로 만나보세요! Y: 안녕하세요! 옐블 독자들을 위한 간단한 자기소개 부탁 드립니다.임: 안녕하세요 옐블 독자 여러분, 옐로쇼핑미디어 팀그레이프 신규사업에서 엘레뉴(http://elainue.co.kr/) 를 담당하고 있는 임용택 PM입니다. 반갑습니다 :)Y: PM이 정확이 어떤 일을 하는 직무인지 궁금합니다! 임: 우선 PM(product manager)은 신규 제품에 있어서 처음부터 상품 판매가 이뤄지기 전까지 거의 모든 일을 담당하는 매니저라고 보시면 돼요. 저는 팀그레이프에서 상품 기획단계부터 생산, 유통, 마케팅 기획, 모델 촬영까지 담당하고 있고요, MD와 SNS 담당자 등 팀원 관리까지 하고 있습니다. Y: 와… 직무소개만 들었는데 제가 다 피곤해지는 느낌이네요. 임: ㅋㅋ그렇죠? 팀그레이프도, 팀그레이프에서 제가 담당하고 있는 ‘엘레뉴’도 신규사업이라 더 일이 어마어마합니다. 심지어 엘레뉴는 오픈 한지 아직 3주밖에 안됐습니다.Y: 팀그레이프 전에도 패션분야에서 커리어를 쌓으셨나요? 임: 네. 처음에는 남성의류 편집숍 앤드류앤레슬리에서 셔츠 기획 생산을 담당했고, 맞춤정장 O2O 기업인 스트라입스에서는 상품기획 및 생산 팀장으로 있었습니다. Y: 완전 패션 인생(?)이군요! 패션분야를 선택하게 된 이유가 있었나요? 임: 원래는 멀티미디어학과로 입학했어요. 게임 개발자가 목표였거든요. 그런데 한국 대부분의 남성들이 그렇듯 군대 전역 전에 앞으로의 인생에 대한 고민을 해봤는데, 제 전공에서 충분한 만족감을 느끼지 못한다는 생각이 자꾸 들더라고요. ‘내가 지금까지 진짜로 좋아했던 것이 뭘까’라는 질문을 스스로에게 던져봤더니 답은 ‘옷’이라 생각되어 의류학과로 전과하게 됐습니다J 그 후로 직접 만든 옷도 입고 다니고 당시 여자친구에게도 제가 만든 세상에서 하나뿐인 옷도 선물했었어요ㅋㅋㅋ Y: 세상에! 세상에서 하나뿐인 옷이라니, 너무 로맨틱하자나요…ㅠㅠ임: 근데 촌스럽다고 안 입던데요 (슬픔)Y: (토닥토닥)Y: 자자 다음 질문으로 넘어가서, 옷 잘입는 팁이나 머스트 해브 아이템을 추천한다면? 임: 무조건 비싸기만 한 옷이 좋은건 아니에요. 화려한 스타일의 옷보다는 검정색, 네이비, 흰색, 회색 등 베이직한 색의 옷을 잘 매치해서 입는 것을 추천해요. 이 네 가지 색깔 안에서의 조합은 실패하기 힘드니까요! Y: 좋은 팁 감사합니다! 용택님은 처음 팀그레이프와 어떻게 인연이 닿았나요?임: 스트라입스에서 재직 중일 당시에 코트를 생산하려고 준비하고 있었습니다. 그때 지금 팀그레이프 대표님께서 생산에 도움을 주셨고요. 거기서 인연이 닿았는데, 생산이 끝나고 난 뒤에 대표님이 YSM에 ‘패션사업부’가 생기는데 같이 일을 해보지 않겠느냐고 제안을 주셨어요. 그래서 작년 5월에 패션사업본부 첫 번째 맴버로 들어오게 됐습니다. Y: 잘 자리잡은 기업에 있다가 초기 멤버로 오기 쉽지 않았을 것 같아요. 임: 네, 세팅멤버로 오는 것도 부담스러웠고 거의 남성복 위주로만 일을 하다가 여성복을 담당할 수 있을지에 대한 고민도 컸어요. 그렇지만 대표님과 더 같이 일해보고 싶었고, 대량생산 기획을 경험해보고 싶었기 때문에 오기로 결정 했어요. Y: 아무래도 초기 멤버만의 고충이 있었을 것 같아요. 가장 힘들었던 순간은 언제였나요? 임: 사실 제가 패션사업부 대표님보다 한 달 정도 먼저 입사했습니다. 팀에 저 혼자여서 외로웠던 게 가장 컸던 것 같아요. 그리고 팀그레이프는 미쳐라, 봉자샵, 메르시엘 등 여러 소호 브랜드를 가지고 있다 보니 다양한 일을 했어요. 미쳐라 오프라인 스토어를 열었을 때 가서 판매 지원을 하기도 했고, 메르시엘 래쉬가드 공장에 가서 물건을 핸들링하고 뽑기도 했어요. 여기저기 불려가고 심신이 힘들었죠 (ㅠㅠ)Y: 정말 몸이 열 개라도 모자랐겠어요! 그럼 반대로 보람을 느낀 적이 있나요?임: 엘레뉴가 오픈한 지 얼마 되지 않았을 때, 배송이 지연된 거예요. 온라인 쇼핑몰이란게 고객의 신뢰도가 정말 중요한데 배송 지연이 생기면 안되겠다고 판단해서 직접 물건을 고객님께 전달 드렸어요. 그때 고객님이 고맙다며 상품에 대해 만족한다는 문자를 보내주셨는데 아직까지 캡쳐해서 가지고 있을 정도로 뿌듯한 순간이었습니다.Y: 생긴지 얼마 안된 기업이지만, 팀그레이프만의 특별한 사내문화가 있나요? 임: 자랑하고 싶은 문화가 있는데, 저희는 한 달에 한 번 GWP(Good Work Place)라는 걸 진행해요. 한 달에 한번 오후에 다같이 단체활동을 하는 건데, 볼링도 치러가고 외부강사를 초빙해서 성격분석 같은 이벤트도 합니다. 팀원들과 업무 외의 액티비티를 함께 할 수 있어 수평적으로 대화도많이 하게 되고 더욱 친밀해 지더라고요. 이렇게 친밀도가 높아지니 결국 업무에서도 시너지로 이어지고, 정말 좋은 문화로 자리잡은 것 같아요 :)Y: 정말 부러운 사내문화네요! 임: 자랑한 김에 이거 하나만 더 할게요! YSM에서는 매월 셋째 주를 ‘런치데이’로 지정하고, 점심시간을 두 시간을 줘요. 이것만으로도 행복할 텐데 직원에게 만원씩 제공을 해줍니다. 런치데이에는 팀원들끼리 조금 멀리 나가서 특별한 음식을 먹고 오기도 해요! Y: 세상에…. 이보다 더 좋은 복지가 있을까 싶어요! Y: 앞으로는 어떤 일을 해보고 싶으신가요?임: 우선 패션쪽 일을 계속 하고 싶어요. 나중에 나이가 들면 고향인 목포에 내려가서 패션샵을 운영하고 싶은데, 제 롤모델이 여용기 선생님이거든요 :D 부산에서 마스터테일러로 활동하고 계신 분인데, 60대 중반인데도 옷을 정말 잘 입으세요. 그 분처럼 계속 패션쪽에서 종사하면서 스타일리쉬하게 살고 싶습니다. 출처 :여용기 인스타그램 (@yeoyoungki)Y: 마지막 질문입니다. 앞으로 팀그레이프에 바라는 점이 있다면?임: 지금 팀그레이프에는 20명 정도의 멤버들이 함께 일하고 있는데, 점점 팀원들이 늘어나고 규모가 커질 것 같아요. 회사 규모가 커져도 지금처럼 많은 대화들을 나누고, 다양한 아이디어를 제안할 수 있는 열린 기업문화를 유지했음 좋겠어요! 팀그레이프에 많은 응원을 부탁 드립니다. :)
조회수 755

독자의 시선을 예상하라 (2/2)

Overview“언덕 위에 나무가 있다.” 이 문장을 보고 어떤 풍경을 상상했나요? 독자는 간단한 문장 하나조차도 저마다 다른 상상력을 발휘합니다. 나무에 잎은 있는지 없는지, 언덕은 낮은지 높은지, 날씨는 맑은지 흐린지 등 독자가 겪은 개인적 경험이나 생각에 따라 다르게 생각하는 것이죠.1) 하지만 위의 문장을 본 사람이라면 최소한 ‘언덕’과 ‘나무’의 형태만큼은 떠올렸을 겁니다. ‘언덕’과 ‘나무’는 크리에이터가 꼭 전해야 하는 문장의 핵심 단어와 같습니다. 두 단어가 독자에게 온전히 전해지면 언덕 위에 나무가 있는 모습(메시지)이 떠올려지니까요. 신기합니다. 문장만으로 크리에이터의 머릿속에 있는 걸 그대로 독자의 머릿속에 옮길 수 있다니. 마치 ‘언덕’과 ‘나무’ 두 단어가 날개를 달고 날아다니는 것 같은 기분입니다.2) 하이퍼텍스트(Hypertext)의 가장 큰 특징이기도 하죠.하이퍼텍스트의 원리역삼동 사무실 구석에 앉아있는 내가 한 번도 만나지 않은 당신에게 언덕과 나무를 떠올리게 했던 것처럼 하이퍼 텍스트는 시공간의 제약을 완전히 벗어납니다. 이 글도 브랜디 랩스에 올린 순간부터 세계 여기저기를 날아다닐 수 있습니다. 내가 자고 있는 시간에도 남들은 검색만 하면 읽을 수 있으니까요. 어떻게 이런 일이 가능할까요?하이퍼텍스트의 원리우선 하이퍼텍스트의 원리를 살펴봅시다. 책을 예로 들면, 겉표지(starting point)에서부터 독서를 시작하는 건 모두 같지만 독자들은 각각 다른 방식으로 책의 내용을 상상하며 이어 나갑니다.(link) 만약 독자 A와 B가 “언덕 위에 나무가 있다”는 문장을 보고 같은 풍경을 상상했다면 그 둘은 서로의 상상을 공유하고 있는 셈입니다.(node-shared experience) 반면에 100명의 독자가 잔디 깔린 언덕을 상상해도 누군가는 혼자서 바위 언덕을 상상할 수도 있습니다. 그래도 괜찮습니다. 그것은 ’언덕’이라는 하나의 단어에서 떠올릴 수 있는 수많은 풍경 중 하나일 뿐이니까요.(node-unshared experience) 점들이 촘촘하게 모여 하나의 선을 이루는 것처럼 이런 상상들이 모여 크리에이터의 이야기가 독자에게 전달됩니다.3) 이제는 디지털로 모두가 연결되었습니다. 그만큼 상상의 규모도 더욱 커졌습니다.4) 크리에이터와 독자가 동시에 같은 콘텐츠를 볼 수 있기 때문에 곳곳에서 새로운 상상이 동시다발적으로 추가됩니다. 독자는 읽는 순서를 자유롭게 선택할 수 있습니다. 책의 기본적인 순서는 페이지로 정해지지만 하이퍼텍스트는 독자가 읽는 도중 건너뛰거나, 다른 글로 이동하거나, 읽는 도중 ‘뒤로 가기’를 클릭할 수도 있습니다. 컴퓨터와 인터넷의 특성 때문에 독자의 시선이 훨씬 자유로워진 것입니다.5) 메시지를 읽게 하는 방법독자가 자유롭게 상상할 수 있다고 해서 크리에이터의 역할에 위기가 찾아온 건 아닙니다. 앞서 본 언덕 위의 나무처럼 독자가 뭘 떠올리든 상상할 메시지(starting point)를 제공하는 건 여전히 크리에이터의 몫이기 때문입니다.5) 크리에이터라면 누구나 콘텐츠를 통해 독자에게 하고 싶은 말이 있을 테고, 그것이 잘 전해져야만 콘텐츠의 가치가 더욱 높아질 겁니다. 독자의 상상력을 자극하면서도, 메시지를 제대로 전하는 방법! 어떤 것이 있을까요.1.맥락 독자가 무언가를 떠올렸다는 건 상상이 되게끔 만들었다는 의미입니다. 예시를 하나 살펴보겠습니다. 한림대학교 강동성심병원은 병원 리모델링 공사를 하면서 ‘병원이 다시 태어났다’는 메시지를 전달하고 싶었습니다. 그래서 병원에서는 의사를 모델로 세워 확 바뀐 모습을 표현했습니다. 맥락의 예 / 한림대학교 강동성심병원 제공위의 두 포스터에 등장한 의사는 동일인물입니다. 하지만 이미지가 확 바뀌어 완전히 다른 사람처럼 보입니다. 청정무균시스템을 도입하고, 첨단 하이브리드 수술실을 오픈했다는 메시지를 전달하려고 의사의 확 바뀐 이미지를 대신 보여준 것입니다. 포스터에서는 ‘확 바뀌었다!’고 대놓고 말하진 않았지만, 사람들은 바뀐 병원의 모습을 상상할 수 있을 겁니다. 여기서 중요한 것은 두 개의 포스터를 비교하며 이미지 속에 담긴 메시지를 함께 읽어냈다는 점입니다. 아마 오른쪽의 포스터만 봤다면 ‘강동성심병원 거듭나다’라는 카피가 잘 와닿지 않았을 겁니다. 병원과 의사의 모습이 서로 어떤 상관관계가 있는지 알 수 없기 때문입니다. 그러나 비교 대상 덕분에 의사의 확 바뀐 이미지를 한눈에 볼 수 있었고, 메시지 또한 이해하는 데 도움이 됐습니다. ‘바뀌었다’는 말에 날개가 달려 하이퍼텍스트로 독자에게 날아간 순간이기도 합니다. 맥락은 사전적 의미로 ‘사물 따위가 서로 이어져 있는 관계나 계통’을 말합니다. 콘텐츠 맥락도 이와 비슷합니다. 위의 두 포스터를 통해 ‘동일인물이지만 달라 보인다’는 정보를 얻을 수 있었으니까요. 그 정보는 두 대상을 서로 비교하면서 자연스럽게 생각해낸 결과입니다. 콘텐츠의 맥락은 굳이 설명하지 않아도 상관관계를 읽어낼 수 있게 도와주는 정보인 셈입니다. 2.구체적 워딩 구체적 워딩은 주로 광고에서 사용하는 기법입니다. 누구나 알고 있는 쉬운 단어를 이용해 사람들의 머릿속에 무언가를 떠올리게 만드는 것이죠. ‘계란으로 바위치기’라는 말을 들었을 때 사람들은 자연스럽게 도저히 승산이 없는 경우를 떠올립니다. 구체적 워딩이기 때문입니다. 구체적 워딩의 예 / 엿츠 제공이 제품은 엿을 식품이 아닌 ‘욕’의 관점에서 접근해 다양한 상황과 연결하고 있습니다. 맛이나 신선도 등 제품 그 자체에 대해 설명하진 않았지만 훨씬 좋은 홍보 효과를 거뒀습니다. 덕분에 이 제품을 보는 사람은 엿과 야근의 맥락을 통해 짜증나는 상황을 떠올릴 수 있었죠. 특히 이 카피는 많은 간식 중 왜 엿을 먹어야 하는지를 정확히 짚어냈습니다. 그러므로 야근에 시달리는 회사원이 가판대의 많은 간식 중 엿을 집는 건 당연한 일입니다. Conclusion꼭 화려한 영상, 잘 찍은 사진이 아니어도 됩니다. 글만으로도 독자가 상상할 수 있게 도울 수 있으니까요. 상상은 머릿속에 그림을 그려줄 뿐 아니라 전하고자 하는 메시지까지 읽게 만듭니다. 엿 봉지처럼 한 단어가 다른 뜻도 포함하고 있다면 중의적 표현을 해보는 것도 좋은 방법입니다. (물론 판단은 독자의 몫입니다.) 콘텐츠에 중요한 정보 없이 쓸데없는 말만 가득하다면, 이제부터는 긴 설명이 필요 없도록 독자가 읽어야 할 부분을 정확하게 짚어주세요. 크리에이터가 제공한 단어 하나, 문장 한 줄이 독자에겐 큰 선물이 될 겁니다. 1) 콘텐츠는 크리에이터의 단독 작업만으로는 모든 것을 충족할 수 없다. 대신에 독자와의 상호작용으로 콘텐츠를 완성할 수 있다. 즉, 나무의 상태나 언덕의 모습을 상상하는 건 독자의 몫이며 이는 독자에게 유한 또는 무한의 자유를 주는 것과 같다. 2) 크리에이터가 온라인에 콘텐츠를 업로드하는 순간, 콘텐츠는 독자와 함께 즐기는 공유의 속성을 지닌다. 3) 크리에이터가 구체적으로 표현할수록 shared node는 더욱 많아진다. 4) 좋은 콘텐츠가 뭐냐고 물으신다면 5) 하이퍼텍스트를 독자가 읽는 방법은 검색, 훑어보기, 하이퍼링크, 건너뛰기, 조각내기 등이 있다. 6) 이와 관련해 이화여대 김애령 교수는 다음과 같이 언급했다. “하이퍼텍스트의 이면에는 그것을 구성하는 코딩(coding)에 있다. 하이퍼텍스트가 독자에게 무한한 경로의 선택권을 제공할 수 있으려면 그 텍스트를 설계하는 작가는 모든 가닥들과 결과들의 데이터를 미리 만들어 두어야 한다. 따라서 독자들의 선택권은 ‘가상적’이다.” (출처는 참고문헌 참조)참고문헌 조은하(2007), 디지털 스토리텔링, 한국근대문학연구, 제15호, 261-262심은진∙윤학로(2007), 하이퍼텍스트의 새로운 글쓰기: 프랑스 디지털 문화이론을 중심으로, 외국문학연구, 제26호, 33-48김애령(2017), 디지털 매체 시대의 읽기와 해석학의 과제, 현대유럽철학연구 제45집, 185장근우, 「콘텐츠의 정석」, 예문아카이브(2017)글장근우 대리 | People&Relations Managerjanggw@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #마케팅문화 #마케팅팀 #업무환경 #인사이트 #경험공유 #콘텐츠
조회수 4698

UI 사용성 평가, 쉽고 간편하게 하는 방법

최근 몇 년 새 린스타트업, 린 소프트웨어 개발 등 '린' 이야기를 많이 접하게 되었었다.학교 다닐 때만 해도 린스타트업이라는 단어는 잘 알지도 못했고 린 제조라는 단어가 훨씬 친숙했었는데 이제는 오히려 린 제조라는 말이 더 어색하게 들릴 정도다. 하여간 린스타트업이란 단어는 린 제조라는 에서 유래가 된 것이며 Lean(군더더기 없는) + Startup(자신들의 가설을 증명해가는 단계의 조직) 이 합쳐진 말인데, 바로 이 린스타트업에서 사용하는 소프트웨어 개발 프로세스가 린 소프트웨어 개발 방법론이고 기존 전통적인 워터폴 방법론과는 큰 차이점을 보인다. 이 두 가지 방법론을 비교하자면 아래 그림과 같다.워터폴과 린스타트업을 잘비교 설명하는 그림위 그림처럼, 워터폴 방법론 프로세스 에서는 바퀴, 차대, 카울 등의 단계를 차근차근 순차적으로 진행하여 완벽한 최종 제품 or 서비스인 자동차를 만들어 시장에 내놓는 방식이었고, 린스타트업의 프로세스는 보드, 킥보드, 자전거, 오토바이 등의 작은 단계마다 고객에게 가치를 제공할 수 있는 결과물로 시장에 내놓고 반응을 살펴가며 최종 결과물로 만들어가는 방식이라 할 수 있다. 기껏 자동차를 만들어 놨어도 팔리지 않으면 허사니까 작은 단계마다 시장을 즉시 접하고 파악하여 리스크를 줄이는데 목적이 있다.린스타트업 프로세스를 들여다보면 위 그림처럼 Build, Learn, Measure 과정을 계속 끊임없이 반복하며 원을 그리게 되는데, 이렇게 수 많은 원을 그리며 점차 완벽한 원 (=완벽한 제품 or서비스)를 만들어 나가게 된다. 그래서 린스타트업 책의 표지도 수많은 원이 그려져 있는 것이다.[린 스타트업 The Lean Startup] 책 표지이처럼 린스타트업 프로세스에서는 필연적으로 테스트 과정을 계속 반복하게 되는데, 어떻게 하면 이 테스트 과정에 투입되는 자원과 비용을 줄일 수 있을까? 이러한 질문의 좋은 해답이 [사용자를 생각하게 하지 마 Don't make me  think]라는 책에 잘 설명되어 있어서 소개하고자 한다.(소개할 내용은 BM을 검증하기에는 무리이며, 오직 UI의 사용성에 관한 부분이다.)사용성 평가 소개사용성 평가란?사용성 평가란 한 사람이 어떤 물건을 가지고 일반적인 과제를 수행하는 과정을 지켜보는 것이다. 대상은 웹사이트, 애플리케이션, 제품 프로토타입, 새 디자인을 담은 스케치 등이 될 수  있다. 그 과정에서 사용자가 혼란스럽다거나 답답하다는 느낌이 드는 지점을 찾아서 고치는 것이 사용성 평가의 목표다. FGI와의 큰 차이점은 그 물건에 대해 나누는 대화를 듣는데 그치는 것이 아닌 실제 사용하는 모습을 보는 것에 있다.개인적으로 단 한 명을 하더라도 꼭 해야 한다고 생각하는데, 왜냐하면 만든 사람은 조금만 지나도 너무나 많은 것을 알고 있기 때문에 새로운 관점으로 볼 수 없게 된다. 그럴 때 평가를 해보면 전혀 다르게 이용하는 사람들을 보며 새로운 시각이 열리게 된다.소개하는 사용성 평가는 전통적인 평가 방법이 아닌 'DIY  평가’라는 이름으로 시간과 예산, 전문지식과 공간에 제약받지 않고 누구나 쉽고 간편하게 진행할 수 있다. 전통적 평가방법이 많은 자원을 투입하여 가능한 모든 문제를 찾기  위해서였다면 DIY 평가방법은 적은 자원으로 당장 개선할 문제를 찾기 위한 목적이다.DIY 평가 방법평가 주기&시간한 달에 한번 오전 시간 정도면 충분하다. 그 정도의 주기와 시간이면 단순하므로 지키기가 쉽고, 평가로 얻은 결과만으로도 다음 평가까지 개설시킬 충분한 업무량이 생길 것이다.참여자적정 참여자 수는 3명이다. 전통적인 방법에 비해 3명은 표본으로 삼기엔 너무나 적은 수이며 따라서 모든 문제를 밝혀내기엔 부족한 인원수라는 것은 사실이다. 하지만 전혀 문제 되지 않는다. 왜냐하면 DIY 평가는 정량평가가 아닌 정성평가로써 데이터를 만들어 내기 위한 목적이 아니다. 또 모든 문제를 찾아낼 필요가 없다. 단 1회의 평가만으로도 찾아낼 수 있는 문제의 수는 고칠 수 있는 양을 채우고도 남는다. 또 3명을 넘겨 평가를 거듭해 보아도 점점 이미 알고 있는 중복되는 문제들만을  재확인하게 될 뿐이다.모집테스트에 참여할 사용자는 페르소나와 꼭 일치하는 사람을 고집할 필요는 없다. 그런 사용자를 찾기 위해서 노력하는 시간에 차라리 그냥 사전 지식이 없는 사용자로 조건을 완화하고 진행하여도 만족할 만큼 충분한 문제점을 발견할 수 있다. 또 조건을 완화할 경우 참여자를 쉽게 모집할 수 있게 된다. 우리는 서비스를 만들며 페이스북 그룹 몇 곳에다가 모집글을 올렸었는데 수 많은 참여자를 모집할 수 있었다. (그것도 자원봉사자로!)진행자참여자 옆에  1:1로 나란히 앉아서 평가 진행을 돕는 진행자 1명만 있으면 충분하다. 전문가가 아니라도 상관없다. 평가 용지와 스크립트를 보며 조금만 연습해도 충분히 잘 할 수 있다.평가 장소&도구캠코더와 마이크가 준비된 매직미러 딸린 조용한 방일 필요 없다. 편한 카페 같은 공간에서 노트북과 마우스, 화면 녹화 소프트웨어 정도면 충분하다.(도구 소개는 먼저 작성하였던 '스타트업 UI 프로젝트에서 사용한 10가지  도구’에서 좀 더 자세히 볼 수 있다)평가대상프로젝트 초반에  가까울수록 좋고 극단적으로는 디자인이나 개발 등이 전혀 이루어지지 않은 상태에서 자신의 서비스가 아닌 경쟁사의 서비스나 유사한 서비스를 사용하게 해봐도 된다. 서비스 와이어프레임 때 실시해봤고 프로토타입 때 실시해봤다 그리고 오픈 베타 중인 지금도 하고 있다.과제각 평가대상의 단계마다 평가하고 싶은 부분이 달라 과제가 달라지게 되는데 예를 들자면 만약 로그인 프로세스를 평가하는 목적이라면 계정 가입하기, 계정 로그인하기, 아이디 찾기, 비밀번호 찾기 같은 과제일 것이다.좋은 질문에서 좋은 해답을 찾는다고 한다. 좋은 과제를 준비하자.진행순서&방법1. 인사(4분)참여자가 진행과정을 이해한 상태에서 평가에 임할 수 있도록 진행방법을 설명한다2. 배경 질문(2분)참여자에 대해 몇 가지 질문을 던지다. 참가자의 긴장을 풀어주며 사전 지식을 가늠할 수 있다3. 둘러보기(3분)서비스 첫 화면의 첫인상으로 서비스가 제대로 이해를 전달하는지 파악한다.4. 과제(35분)평가의 핵심적인 부분으로 참여자가 일련의 과정을 수행하는 모습을 관찰하는 부분이다. 여기서 중요한 것은 참여자가 과제에 집중하되 본인이 생각하는 내용을 소리 내어 말하게 해야 한다. 말을 안 한다면 말하게끔 유도하는 질문을 던져야 한다. 예를 들면 “지금 어떤 생각이 드나요?”, “어디를 보고 계시죠?”, “이제 무엇을 할 건가요?” 등인데 질문할 때는 유도 질문하지 않도록 조심하여야 한다 참여자 스스로 과제를 수행해야 하는데 “가입 버튼을 찾고 계신가요?”라고 질문한다면 참여자에게 가입을  유도시키게 되기 때문이다.5. 심층질문(5분)과제 간에 행동을 유도할까 봐 미처 하지 못했던 질문을 할 수 있다.6. 마무리(5분)감사인사와 함께 마친다.(진행순서&방법에 대해 간략하게 소개하였는데 가장 중요한 부분인데도 불구하고 이 글에 함께 쓰기엔 어려워 따로 분리하여 자세히 써야 할 것 같다. 다음 글 쓸 때 소개할 예정인데 아마 12월 말에 소개할 예정이다.)평가 진행 후평가 후 일반적으로 파악할 수 있는 문제들이 3가지 있는데 소개한다.  1. 콘셉을 이해하지 못하는 경우무엇을 할 수 있는지 모르거나 또는 할 수 있을 거라 짐작했던 내용을 할 수 없게 된 것이다.2. UI 텍스트가 문제인 경우사용자가 사용하는 단어와 여러분이 사용하는 단어가 다른 경우다.3. 찾는 내용을 찾지 못하는 경우사용자가 원하는 것을 찾지 못하는 경우로써 더 눈에 띄도록 해야 하는 경우이다.문제들을 보다 보면 진짜 중요한 문제도 있고 덜 중요한 문제도 있을 테고 문제뿐 아니라 사용자들이 제안한 내용도 있을 거다 "이런이런 기능 있으면 좋겠어요"하고 말이다. 이러한 문제들은 아마 다 고치기 어려울 수 있다.때문에 팀원들이 모여서 관찰한 내용을 공유하고 고칠 문제와 고칠 방법을 정해야 할 텐데 어떻게 고칠 우선순위를 정해야 할까?1. 공동목록을 만든다평가 중에 목격한 문제들로만 가장 심각하다고 생각하는 문제를 3개씩 말하고  화이트보드 같은 곳에 적는다.새로운 문제를 더하려는 충동을 자제하고 새로운 기능에 대한 요청은 꼭 필요한 게 아니라면 배제한다.2. 가장 심각한 문제 10개 뽑는다공동목록을 만들며 중복되는 문제든 투표를 하든 10개만 뽑는다.3. 순위를 매긴다심각한 순서로 1~10위까지 순위를 매긴다.4. 목록을 정돈한다1위부터 차례대로 다음 평가전 한 달간 누가 어떻게 고칠 것인지 정한다 완벽하게 고치지 못하더라도 조치를 취한다는 것이 중요하다.5. 매우 쉽게 고칠 수 있는 목록은 따로 둔다심각하지 않고 매우 간단한 문제들은 별도로 모아 두어서 짧은 시간에 고칠 수 있을 때 고친다.지금까지 쉽고 간단하게 UI 사용성  평가하는 방법에 대해 글을 작성하였는데 본문에서 먼저 언급했던 것처럼 진행방법에 대해한 자세한 내용은 다음 글쓰기 때 따로 더 심층적으로 다루도록 하겠다.다음글 :https://www.theteams.kr/teams/143/post/64512참조 : [사용자를 생각하게 하지 마 Don't make me think], 구글 이미지 검색#텐시티 #디자인 #디자이너 #UI #UX #사용성개선 #사용성평가 #인사이트
조회수 1922

미안합니다! 스타트업을 거쳐간 분들!

미안합니다.고맙습니다.사랑합니다.진심을 담아서 감사함과 미안함을 전합니다.지금 우리회사의 최대 이슈는"신규직원 채용"이다.(출처: 구글, 너 내 동료가 되라)물론 지금의 멤버들에게도 월급을 지급하며,하루하루 치열한 전쟁터에서 생존을 위해몸부림치고 있는데...다들 연구원들 출신이다보니...총알과 총은 만들어놨는데,정작 쏠줄 아는 군인이 없는 격?우리에게 부족한 능력을 채워줄신규직원 채용을 위해이리저리 물어보고,추천 좀 해 달라고 졸라대고,꼬시러 돌아다니고...참 어렵다.하긴 제정신이 박힌 사람이라면,뭐가 아쉬워 스타트업에 합류하려 하겠는가.우리처럼 미친 부류들이나 뛰어드는거지.그리고 우리도 미친 부류를 찾고 있는거고.그러다보니여러 블로거들이나 웹에 게시된 정보를 따라이런저런 스타트업 입사 경험, 인턴 체험기, 멤버 합류에 관한이야기를 접하게 되었다.(출처: 네이버 르스누피님 블로그)처음 시작들은 다 열정과 패기가 넘쳤다.필자도 모르게 마음이 동기화되어젊은 모험가가 된 느낌에 절로 미소 지어졌다.근데 뒤로 갈수록...뜨거움은 사라지고,왜 이곳에 있는지,난 무엇을 하고 있는건지,정체성의 혼란을 겪는 글들로 이어졌다.더 뒤로 가니...결국은 회사에게 버림받았다는 표현,회사가 오래가지 못해 뿔뿔이 흩어진 이야기,처음과 달리, 약속을 지키지 않는 대표에 대한 실망,궁핍한 통장과 견디기 힘든 생활고로 좌절하는...안타깝고, 슬픈 이야기로 끝맺더라.읽고 있는 나 자신이부끄럽고, 미안한 마음이 들었다.생각해보면,부족한 창업자인 나를 믿고동행하고 있는 직원(멤버)들에게필자는 참으로 몹쓸 대표다.창업한지 1년 6개월이 지나고,창업준비기간부터 함께 한 동료들에게는나는 복지를 제대로 해준 것도 없고,월급도 뒤늦게 지급하게 되었다.그래서 창업자의 입장은 매우 잘 이해한다.그러나 스타트업의 직원 입장에서는 참 나쁜 사장이다.(출처: 영화 신세계 중에서  : 난 절대 협박이나 공포로 동료는 붙잡아두진 않았다.)그나마 멤버들이 날 떠나지 않았고,지금의 우리 회사가 생존해나가고 있다.조선의 거상 임상옥이라는 선배님은"사람을 남기는 장사"를 강조하셨는데...필자는 아직까지 그 경지까지 이르기에는부족한 것만 많아 부끄럽다.처음에 많은 시행착오와부족한 점을 너그러이 이해해 준 동료들!그래서 더더욱필사적으로 매출발생에 공들였고,이제는 한 2년 정도는 그래도 안정적으로회사 운영이 되지 않을까하는 조금의 안도감이 있다.어쨋든간에...필자는 어쩔 수 없는 찌질한 창업자이다.상황이나 환경 탓할 필요 없이직원 월급을 제때 지급 못 한 기록이 있으니나쁜 전력이 있는 사장이다.그래서 반성하고,늘 미안한 마음을 가지고 살아간다.다시 한 번죄송합니다.미안합니다.일부 창업자들은 동네가게에서 알바고용하듯이사람을 채용해서 부려먹는다.아니,그보다 더 독한 경우가 많다.알바는 그래도 최저시급이라도 주지.스타트업 직원에게 월급은 커녕 활동비조차 없이오히려 개인 비용을 쓰라고 강요하는 회사도 있더라.이럴땐 꼭 창업멤버라는 허울 좋은 말로 꼬시지.창업멤버면 창업멤버답게 귀하게 대접해 주던가.오히려 이건 노예부리듯이 식대도, 교통비도 없다.(출처:MBC 무한도전 무한상사 편)게다가 야근, 주말근무는 기본이다.스타트업이라 어쩔 수 없다고?주위에 멋진 사장님들이 많아서인지...다들 주 5일근무다.그리고 5시 반 칼퇴다.우리회사?우리는 직원야근은 없다.야근 수당 줄 돈까지는 부담스러워서...사연을 살펴보다보니...지분이라는 그럴듯한 미끼로사람 꼬드겨서 고생만 시키고나중에 팽해버리는 악질 중 악질 창업자도 있더라.(출처: 영화 약장수 중에서): 창업자 여러분! 우리는 약장수가 아니잖아요.특히, 무슨 공모전한다고, 무슨 아이디어대회나간다고열정으로 뭉쳐서 읏샤읏샤하자는창업 동아리(?)같은 모임들이 있던데....대회에서 수상 못 하면 어쩔 건데?혹시나 수상한다해도...그 다음은 어쩔건데?그냥 커리어 한 줄 늘릴려고순진한 사람들 모아서 소모품처럼 사용하고뿔뿔이 흩어지면 끝이냐?물론 대다수의 창업모임은 선하다.진짜로 잘 해주려고 한다.그러나 늘 소수의 못된 미꾸라지가진흙탕을 만들어버린다.창업자가 팀원이나 직원을 구할 때의최소한의 예의에 대하여 조금만 언급하겠다.요즘 여기저기 공고나 모임을 바라보면,스타트업들의 잘못된 방향으로팀원을 구하는 것 같은 느낌이 든다.팀원(동료) 또는 창업멤버.말은 그럴듯해도사실은 완전 고생길에다가불확실성과 매우 엄청 적은 보수,솔직히 이거 해달라고하는거참 예의없는거다.예의가 없음에도창업자는 삼고초려해서라도인재를 구해야한다.그러려면 적어도고용할 수 있는 최소한의 조건은갖추고 모셔라.1. 네가 나를 모르는데~ 난들너를 알겠느냐?잘 모르는 사람에게 창업 멤버가 되어달라고,팀원이 되어달라고 하는건 말이 안된다.정당한 월급주고 직원으로 채용해서서로 성장해 나가다가서로 협의해서 창업멤버나 동료로 영입하는거다.무턱대고 창업멤버,동료 운운하지 마라.온라인 카페나 모임등에무턱대고 창업멤버 구하는 분들...그 마음은 이해 못하는 건 아니나...그렇게 구한 창업멤버나 팀원을 믿을 수 있으려나?본인이 믿지 못하는 사람이당신의 기업을 어떻게 믿고 키워가지?2. 급하니까 드루와~ 일루 드루와~공모전 나갈거라고 창업 멤버가 되어달라,사업계획은 있는데이걸로 정부지원사업 될거니까 들어와달라,이런 말로 끌어들이지 말자.이 말인 즉,공모전 안되면 너 아웃,정부지원사업 안되면프로젝트 해산이란 말을교묘하게 숨긴 비겁한 말이다.그리고 그렇게 구한 사람이어떻게 팀원(동료)인가?필요할 때 부른소모품으로 생각하고 뽑은거지.솔직히 그러지 말자.(출처: 드라마 직장의 신 중에서)모두 자신의 인생이고,시간이고, 노력이고,그거 보상해줄 각오나 여력없으면서어떻게 멤버 운운하는 건지...진짜 필요한 멤버라면 사비 털어서라도영입해서 사업 이끌어나갈 생각을 하는거다.그리고 그 사람을 멤버로 만들기 위해비전을 공유할 수 있는시간과 설득과 노력의 시간이 필요하고,그 시간동안은 창업자가 비용을 지불할 능력이 있던가그럴 여유가 없으면 지불할 의사라도 보여야지(공증된 계약서)3. 우린 준비가 안된 스타트업이니까 이해하고 들어와~?(출처: 고쇼 중에서)"아직 예비창업자라서 그런데 일단 창업멤버가 되고나서나중에 법인 설립하면 그 때, 지분 나눠주던가 할께""넌 창업 멤버니까 보수는 없는게 당연하지. 우린 역전의 용사니까"참으로 잔악한 말이다.열정페이라는 말이 꼭 대기업에만 있는게 아니다.어느 순간 쬐금이라도 갑이라고 생각되는 쪽이을에게 강요하는 사회가 된 느낌이랄까?그리고 사실 스타트업 창업자는언제나 을이라는걸깨닫지 못한거다.우리 최소한 법인 또는 개인사업자라도 내고...그나마 회사라고 부를 수 있는 최소한은 하고...사람을 초대해야하는게 예의아닐까?공간이 없어 이리저리 커피숍을방황하며 창업하는거?물론~!그럴수는 있다.그 사정 잘 안다.나도 그 생활 참 오래 해 봤으니까그럴수록 직원에게오히려 더 미안해야하고,더 이해를 구해야한다.4. 제발 압박면접따윈 개나 줘라!(어디서 못 된 것만 배워가지고...그대로 써먹냐)취준생 시절..그러니까 2008년 쯤이었다.그때 면접을 다니면서 느낀건"왜이리 쓸데없는 걸(가족, 종교, 아버지 수입 등) 묻지?""면접장 분위기 참 답답하네~"경직된 분위기,상대를 압도하려는 질문들...물론 상대를 더 잘 알고,적합한 인재를 고르기 위해서 풍분한 노력을 기울여야겠지만근데솔직히 면접시간 동안에그 사람을 다 알수는 없다.쓸데없는 질문으로 시간 날리지말고핵심만 말하자.우리 회사의 상황,상대방이 원하는 것,우리가 원하는 것,조정 가능한 요인은 무엇인지,앞으로 우리 회사의 나아갈 방향과 그에 따르는 보상우리가 어쩔 수 없이 감당해야할 리스크와 그에 따르는 책임솔직히 까놓고 가야지 나중에 덜 힘들다.대신...처음은 더뎌질거 각오하고 해야한다.우리회사의 신규 채용이생각보다 늦어졌다.구색은 좀 맞추기 위해 이것저것 준비하고 있고레퍼런스를 만들다보니 생각보다 딜레이 되었다.왜냐하면,준비가 안된 회사니까 조금이라도 더 갖춰줘야그나마 찔끔이라도 직원들이 덜 불안하게 할 수 있다.그래서 초기 스타트업 창업자 동지들에게이런 부분은 꼭 지키고창업 멤버를, 동료를 구하면 어떨까제안해 본다.1. 회사를 제대로 설립해 놓기2. 공간과 사무에 관련된 기기 같은건 회사가 준비해주라(개인이 가지고 오라고 하지 말고...특히 노트북!)3. 적어도 최소한의 활동비용은 지불 할 정도의 여력은 만들어 놓기( 아님 그럴 각오를 법적증빙으로 해주던가)4. 직원보다 더 구하기 어려운게 창업 멤버고, 팀원이다.(제발 난이도 있다는 걸 알면 더 소중히, 더 심사숙고해서 모셔라)이왕이면 사전에직원으로 채용해서 키우던가,다른 회사 채용된 사람을 관찰해서 꼬시던가,다른 사장님과 전략적 제휴를 맺던가,그런 작업들을 통해 서로 알아가며팀원으로 만들어가는 거고, 동료가 되는게 가장 좋은거다.그리고 회사의 상황과 계획과 리스크를모두 손금보듯이 알게 되고, 자세히 설명해주고 난 후,그.럼.에.도.불.구.하.고창업 멤버가 되어준다면,팀원이 되어준다면,(출처: 구글, 삐에로)그 때부터는...기나긴 어둠의 터널을...지옥불 같은 험난한 사업의 길을...끊이지 않는 야근과,굶주린 강제적 다이어트,지속되는 생활고라는 과정을함께 가는거다~그리고 나서(출처: 무한도전 무한상사 중에서)이렇게 말하는 거다."이젠 돌이킬 수 없어. 네가 선택한거야."추신:이번 글은 필자가 네이버에서 가끔 글 올리는 블로그에서발췌해서 조금 각색했다.취미가 블로그에 글쓰기라서 시작한 브런치인데...은근히 중독성이 있어서...좀 무리했더니업무가 무지 로드되어...겁난다.동료들을 위해서라도 잠시 쉬엄쉬엄 글을 올려야겠다.(내 건강을 위해서라는 이유가 더 클 수도 있다)#클린그린 #채용 #고민 #창업자 #스타트업 #스타트업창업자 #스타트업고민 #팀원
조회수 1060

스푼 라디오 오디오 랩 팀의 Jason을 만나보세요!

인상이 좋은 비결은.. 원래 이렇게 생겼어요 (찡긋)오디오 랩 팀의 막내, 알고 보니 세상 모든 매력을 덕지덕지 붙이고 다니는 Jason을 인터뷰해보았습니다.근데 대체 왜 이렇게 인상이 좋은 거예요? 출처: 알파카 월드 - 제이슨 닮은꼴"그냥 정말 원래 이렇게 생겼어요 하하. 웃는 상이예요. 사실 어릴 땐 눈이 좀 더 찢어지고(?) 올라가 있어서 좋은 인상이 아니었는데, 좋은 인상으로 변하더라고요..(나이 탓인가..) 웃는 게 습관이 되어버렸어요"인싸도 아싸도 아닌 '그럴싸'"인싸요? 아니에요 인싸. 그냥 저는 좀 알고 보면 반전도 많고 '모순덩어리' 일뿐이에요. 그래서 저를 표현하는 한 마디도 저는 '모순덩어리'라고 할래요. 예를 들면, 저는 해병대 출신인데 수영을 못하고요. 이성적인 것 같은데 또 되게 감성적이에요. 발라드를 되게 좋아하는데 제 노래방 18번은 '거꾸로 강을 거슬러 오르는 저 힘찬 연어들처럼'이에요. 사색하는 거 좋아하는데 또 가만히 있는 건 싫어요. 시간 아깝더라고요. (빵긋) 사내 제이슨 feat. 카이와 헤이든 듣고 싶은 당신의 스푼 라이프오디오 랩팀은 어떤 부서인가요?"오디오 랩팀은 스푼 라디오에서 오디오 방송 통신 기술을 연구하고 개발하는 부서입니다. 저희의 궁극적 목표는 세계 최고 오디오 기술 플랫폼이 되는 것이에요. 그리고 오디오 랩에서 제가 하고 있는 업무는 안드로이드 OS 클라이언트에 오디오 기술 개발하는 업무를 맡고 있어요. 오디오 랩팀에 막내이긴 한데.. 재간둥이 역할은 제가 맡고 있지 않아요 하하.. 저희 팀의 재간둥이 역할은 Ben님께서 하고 계십니다"스푼에 입사하기까지"제 입으로 말해도 되나요? 저는 수학을 좋아하진 않았는데, 잘했어요. 국어랑 사회 같은 문과계열 과목을 싫어했는데 이공계 쪽이 저와 적성에 맞더라고요. 수학 1등급 나왔는데 메가스터디 박 XX 선생님께 이 자리를 빌려 감사드립니다. 인강이 저를 만들어주셨어요.저의 원래 장래희망은 항공기 정비사였어요. 언제부터 비행기를 좋아했는지 모르겠지만 초등학교 때부터였던 것 같아요. 고3 때 진로를 정해야 하는데 항공정비과와 전자공학과와 고민을 했었어요. 그러다가 결국엔 전자 공학과 에 진학하게 되었고 자연스럽게 꿈 하고 멀어지게 되더라고요. 사실 항공 소프트웨어 쪽으로 일을 하게 될 줄 알았는데 다른 쪽으로 방향이 틀어지다 보니 어느덧 30대가 되어 있었어요. 사실 처음에 저는 스타트업에서 일하게 될 줄 몰랐어요. 이직을 준비하던 차에 제가 직접 스푼 라디오를 사용해보고, 기사도 읽게 되었고 Neil(대표)의 세바시 강연을 보고 이곳에서 일하고 싶다! 비전이 있다!라고 생각해서 오게 되었어요"내가 함께 일하고 싶은 사람서글서글한 사람을 좋아해요. 제가 그렇게 잘 못하는 편이라서요. 낯을 좀 많이 가리는데 저와는 다른 성향인 사람이라면 시너지 효과가 날 것 같아요파일럿 제이슨알고 싶은 Jason의 이야기해병대 출신부터 비행기 조종사까지"제가 안 그래 보이지만.. 사실 해병대 출신이에요. 해병대 왜 갔냐고 물어보신다면, 멋있어 보여서 가게 되었어요. 그게 전부예요. 복식 호흡하는 게 멋있어 보이더라고요. 원래 하고 싶은걸 다 하면서 살자라는 위주인지라, 꼭 무엇이든 하고 말거든요. 원래 꿈이 비행기 조종사였는데 꿈을 못 이루었으니 취미로도 해보자!라는 생각이 들어서 시작하게 되었어요. 한국에서도 할 수 있는데 제약이 너무 많아서 회사를 그만두고 미국에 갔어요. 여태 모아둔 돈 다 쓰고 왔어요. 4개월 정도 미국에서 하루 10시간씩 비행을 했었는데, 정말 행복했어요. 고등학교 때는 사실 실용음악도 준비했었어요. 아카펠라 중창단에 속해있었는데 2학년이 되고 이걸 진로로 결정하기엔 아니라고 판단이 들어서 그만두긴 했지만요. 그래서 대학교에 들어가고 밴드부에 들어가서 보컬을 맡았었어요. 저 점심시간에 혼자 코노가요. 같이 가기엔 부끄러워서.. 혼자 갑니다"유노윤호의 열정, 최강창민의 쿨함"제가 원래 자소서에 경청을 잘하는 사람이라고 적었는데 사실 가끔 듣는 것도 귀찮아요 하하.. 그리고 본인 이야기하는 것도 민폐라고 생각해서 잘하지 않는데 인터뷰하다 보니 엄청 많이 하게 되었네요. 근데 또 제가 남한테 지는 거 안 좋아해서 벤이랑 운동 누가 더 많이 하나 내기해서 요즘 매일 아침 출근 전에 수영 배우고 있고 화, 목은 영어학원을 다니면서 자기 계발을 하고 있어요. 목표가 없으면 안 되는 것 같아서 늘 목표를 일부러 세워요. 그래서 예전엔 사진도 배우러 다녔어요. 아 참! 수영을 배우다 보니 요즘 새로운 목표는 '라이프 가드'를 하고 싶어 졌어요. 이렇게 하고 싶은걸 하면서 열정적이게 살게 된 계기는 아마 아버지의 영향이 큰 것 같아요. 아버지가 매일 이렇게 말씀해주셨거든요"꿈을 꾸고 살아라, 돈은 따라온다! 반려견 '나무'의 아빠 Jason"저희 집 강아지 이름이 '나무'인데요. 식목일이 생일이라서 나무라고 지었어요. (나무 이야기할 때 눈빛이 초롱초롱해지면서 나무의 사진 보여주시던 제이슨) 나무는 귀엽고요. 비가 오나 눈이 오나 항상 저를 반겨줘요. 그래서 고마운 친구예요. 회사랑 집이 거리가 좀 멀어서 자취를 할까 생각했는데, 그러면 강아지가 혼자 집에 있어야 하니 안쓰러워서 하고 싶지 않았어요. 제가 없더라도 다른 가족들이 나무를 보살펴 줄 수 있어서 다행이라고 생각해요.팀원들이 Jason을 한마디로 표현한다면?Ian: JSON - "가볍고 빠르고 효과적이어서"*JSON [JavaScript Object Notation] :경량의 DATA교환 형식Ben: 알파카계의 알파치노 - "알파카처럼 온순한 외모의 소유자이지만 속엔 야망과 강한 카리스마를 가진 남자라서"
조회수 4414

금융권이 좋아하는 스타트업 사업계획서 쓰는 법

 상대에게 무언가 바라는 것이 있을 때, 파워포인트 프레젠테이션, 잘 정돈된 A4용지 파일철, 좀 연배가 있다면 괘도를 준비해 가서 왜 우리를 선택해야 하는지 열변을 토하는 방법이 있다. 업계에서는 이런 것을 피칭(Pitching)이라고 한다. 아마 대부분의 스타트업 관계자들이 피칭에 사용하는 것은 사업계획서일 것이다. 내용은 간단하다. '어떤 사업에 어떻게 도전할 것이고, 얼마의 돈을 어떻게 집행하겠다' 하는 것을 담고 있으면 된다. '내가 벤츠를 몰고 다니고 싶으니, 나에게 돈 1,500만원을 보태어 달라. 취득 및 등록 절차가 끝나는 대로 당장 타고 다니겠다.'라는 것도, 원론적으로는 사업계획이다. 이렇게만 얘기하면 아이처럼 막무가내로 떼쓰는 것과 무엇이 다른가 싶은 생각에 고개를 절레절레 흔들 수도 있겠지만, 거기에 한 가지를 추가하면 이야기가 상당히 달라진다. 사업계획서를 손에 쥐고 투자자·기관 등을 찾아가는 사람은 당신 말고도 수십, 수백명이 더 있다는 사실이다. 이쯤 되면 내용은 아무래도 좋다. 결론은 '내 제안을 얼마나 매력있게 전달할 수 있는가'이다. 그런 의미에서, 요새 너무 자주 꺼내 쓰는 느낌이 좀 들지만, 나의 전 직장에서의 경험은 좀 더 다른 시각에서 사업계획서를 바라볼 수 있게 하는 좋은 토대가 되어주고 있는 것 같다. 일본에서 수위권에 드는 증권사의, 펀드를 총괄하는 부서쯤 되면, 별의 별 나라의 도통 들어보지도 못했던 회사에서 피칭이 들어온다. 말단 중의 말단이었던 나 역시 피칭 자리에 나가서 질문을 던지거나 자료를 검토하는 일을 많이 할 수 밖에 없었고, 그러다 보면 '어떤 매력적인 상품을 골라야 할까?'보다, '어떻게 거절해야 할까?'하는 쪽으로 생각이 바뀔 수 밖에 없게 된다. 그도 그럴 것이, 모든 피칭의 결론은 항상 '그래서 우리와 손잡으면 좋습니다'로 끝나기 때문이다. 그래서 나는, 다른 분야는 몰라도 금융권에 통할 만한 피칭 자료를 판별하는 데는 도가 텄다. 믿어도 좋다. 내 선에서 직접 제안을 거절한 회사만 손발가락으로 다 셀 만큼은 있기 때문에 하는 말이다. 이것도 본의 아니게 쌓은 나의 인사이트이니, 여러분을 위해 공유하면 좋지 않겠는가. 그래서 오늘은 '금융권' 양반네들이 좋아하실 만한 사업계획서를 쓰는, 다시 말하자면, 그 분들이 싫어하는 사업계획서를 피해 가는 요령을 알려드리고자 한다.*이런 느낌의 분들이 좋아하는 것을 알려드릴 생각이다.1. 결론부터 말하자 기본 중의 기본이다. 은행이나 증권 같은 회사들은 본 업무시간이 상당히 엄격하게 정해져 있다. 은행 셔터가 내려간 후에 통장을 개설하겠다며 문을 두들기면 어떻게 될까? 잡혀가지나 않으면 다행이다. 요새는 인터넷 뱅킹이 잘 되어있어 시간 외 대응도 잘 되는 모양이지만, 어쨌거나 금융기관은 시간에 매우 민감하며, 당신과 마주앉아 이야기하는 이 시간이 낭비인지 기회인지에 대해 상당히 이른 시점, 대부분은 대화가 시작된 지 1분 이내에 판단한다. 결론 없이 주절주절 말하는 것을 정말로, 엄청나게 싫어하기 때문이다. 말하자면 이런 것이다. 1) "결론은 명확합니다. 저희 회사에 투자하시면, 향후 3년 이내에 다음 스테이지 투자를 받아 귀사에 금전적 이득을 안겨드릴 수 있습니다. 근거는 세 가지입니다. 첫째로...." 2) "첫째로 ....하고, 또 ....하며, 마지막으로 ....하기 때문에, 저희 회사에 투자하시면 향후 3년 이내에 다음 스테이지 투자를 받아 귀사에 금전적 이득을 안겨드릴 수 있습니다." 2번 방식으로 말하면 일단 말을 시작한 지 5초도 안 되어 "그래서 결론이 뭔데?"라는 말을 듣는 신비한 체험의 프리패스를 끊어놓는 것과 같다. 물론 당신은 어렵게 잡은 피칭 기회를 위해 많은 연습을 했을 것이고, 그 연습 결과 우리 회사의 좋은 점을 전달하기 위해 세워놓은 계획들이 있었을 것이다. 하지만 입을 연 지 5초만에 저런 말을 들으면 패닉이 옴과 동시에 중학교 때 교과서에서만 보고 잊어버렸던 '아노미 상태'에 빠지는 아주 진귀한 경험을 하게 된다. 결국 말은 버벅거리고, 어떻게든 머릿속에 정리해놨던 결론들을 앞으로 끄집어내서 다시 말하려 하는데, 이게 잘 안 된다. 된다 해도 문제인 것이, 결론을 마지막에 말하는 것을 전제로 준비했기에, 결론을 앞에 갖다놓으면 논리 구조가 꼬인다. 'A이고 B니까 C이다'를 'C이다. A이고 B니까'라고 바꾸는 건 생각보다 어렵다. 그렇게 당신은 One of them이 되어 영혼이 탈곡기로 털린 채 터덜터덜 회사로 돌아가게 될 것이다. 대부분의 발표, 프레젠테이션에 대한 책이나 글타래에도, '두괄식으로 말하라'는 항목은 거의 기본으로 들어가 있다. 그렇기 때문에, 뭔가 대단한 팁이라도 주는 줄 알고 기대했다가 이런 기본적인 이야기를 강조하고 있으니 짜증이 날 수도 있다. 하지만 두 번, 세 번 강조해도 지나치지 않기 때문에 꼭 짚고 넘어가는 것이다. 금융기관은 결론이 앞에 오는 이야기를 아주 좋아한다.*결론은 버킹검, 그야말로 결론부터 말한 이 광고는 일세를 풍미했다.2. 생각은 혼자서 하는 것이다 뭔 소린가 싶을 것이다. 당연히 생각은 나 혼자 하는 것이고, 토론이나 토의는 나 혼자 한 생각을 공유하며 의견을 조율해 나가는 과정이니까. 여기서 하는 말은, 표현을 할 때, '~라고 생각합니다'라는 말을 절대 쓰지 말라는 뜻이다. 언어는 신비로운 것이어서, 같은 뜻도 여러 가지로 표현이 가능하다. 하지만 그 여러 표현 중에 '저는 ~라고 생각합니다'라고 말하는 순간, 아마추어의 느낌을 물씬 풍기게 된다. 다음 순간부터 상대방은 당신을 비즈니스 상대가 아니라 배우러 온 학생처럼 대하게 될 가능성이 크다. 확실하지 않은 상황이나 애매한 결론밖에 나지 않아 나의 생각, 나의 견해를 꼭 말해야 할 때는 이런 식으로 끝맺는 것이 좋다. '~로 예상한다.', '~일 것으로 상정한다.', '~라는 결론을 도출하였다.', '~라는 관점에 도달하였다.'.... 사업계획서는 당신의 생각을 쓰는 공간이 아니다. 합리적이고 이치에 맞는 말을 늘어놓아, 비지니스적 관점에서 상대방과 나 양자에게 어떠한 이득을 가져다 줄 수 있을지를 명확하게 전달하는 공간이다. 애초에 결론이 애매하면 안 되는 것이지만, 어찌됐든 그럴싸하게 포장해서 말하는 것이 그렇지 않은 것보다 백 배 낫다.*이런 사람들만 프로인 게 아니다. 우리는 모두 프로페셔널이다. 어설픔이 끼어들 자리는 없다.3. 근거는 명확하게, 논리는 간단하게, 문장은 명료하게 아까참에 1)번 방식으로 말했던 내용을 갖고 와서, 다시 조금 건드려 보도록 하자. 1) "결론은 명확합니다. 저희 회사에 투자하시면, 향후 3년 이내에 다음 스테이지 투자를 받아 귀사에 금전적 이득을 안겨드릴 수 있습니다." 2) "결론은 명확합니다. 저희 기술이 경쟁 타사에 비해 압도적으로 뛰어난 점을 생각하면, 향후 3년 이내에 다음 스테이지 투자를 받아 귀사에 금전적 이득을 안겨드릴 수 있습니다. 다음으로 브랜드 가치 면에서 검토하였을 때..." 3) "결론은 명확한 것이, 저희 회사에 투자하시면 향후 3년 이내에 다음 스테이지 투자를 받아 귀사에 금전적 이득을 안겨드릴 수 있고, 그 근거는 아마 세 가지로 압축할 수 있는데..." 1)번은 근거가 없거나 빈약하고, 2)번은 논리 전개가 복잡하며, 3)번은 문장의 맺고 끊음이 명료하지 않다. 글만 봐도 이렇게 짜증이 나는데, 이걸 갖고 아둥바둥 피칭하는 걸 눈앞에서 또 지켜보고 있자면, 굳이 금융기관 관계자가 아니더라도 머릿속에 네 글자가 떠오를 것이다. '시간낭비'라는. 펀드·보험·예금상품 등의 설명서를 보면 우리 모두 '내가 지금 읽고 있는 게 한국 말이 맞는가'하는 의문을 갖게 된다. 이런 것들은 일부러 그런 방식으로 쓰여진다. 가능한 한 어렵게 써서, 금융적인 문맹률을 높이는 것이 회사에 이득이 되기 때문이다. 그리고 평소에 그런 글을 많이 접하다 보면, 소위 말하는 '비문'이나 앞뒤가 안 맞는 말, 끝맺음이 없는 말, 명료하지 못한 말들에 상당한 스트레스를 받는다. 안 그래도 말 같지도 않은 말 부여잡고 일하느라 힘들어 죽겠는데, 피칭 자리에서까지 그런 말을 보고 있으면 대체 어떤 기분이 들겠는가. 그런고로, 핵심 파트를 구성하는 각 문장은 대체로 30자를 넘지 않는 것이 좋다. 'A는 B이다.', 'A이기 때문에 B할 수 있다.', '결론은 A이다.' 딱, 딱, 맺고 끊음이 확실해야 한다. 다른 문장은 조금 길게 늘어져도 좋다. 일단 핵심 부분, 결론 부분은 이렇게 써야 한다. 또, 논리 구조가 순환되거나, 모순되거나, 앞에서 했던 말을 뒤에서 부정하거나, 잘 생각해보면 뭔가 이상한 부분들이 들어있으면 영락없이 그 부분을 캐치해서 캐물어 올 것이다. 어차피 앞으로 있을 희망찬 미래에 대해 설명할 거라면, 최소한 앞뒤 맥락은 맞아야 하지 않는가. 알기 어려운 논리 구조로 짜여진 글은 결론의 신빙성을 크게 떨어뜨린다. 마지막으로, 근거는 명확해야 한다. 알기 어려운 근거를 토대로 도출된 결론은 도저히 이해하기 어렵다. '우리 회사는 여태까지 잘 버텨왔으므로→앞으로도 잘 버틸 것이다.' 같은 말을 하느니, '우리 아빠가 이 은행의 최대주주셔서→앞으로 우리 회사가 더 커질 것 같다' 쪽이 차라리 더 알기 쉽고 명확하다.*이 분도 이렇게 화를 내시는데....4. 표기, 단어의 통일, 그리고 특히 '숫자'...악마는 디테일에 숨어있다 앞에서는 '우리 회사'라고 하고 뒤에서는 '저희 회사'라고 하는 경우, 앞에서는 반말로 쓰다가 어느 부분에 갑자기 '~입니다.'로 끝나는 경우, 어떤 항목의 금액을 표시했는데 3자리수마다 쉼표를 넣지 않거나, 0 하나가 누락되거나 하는 경우, 일단 탈락이라고 생각하면 된다. 여러 사람이 한 사업계획서를 쓰거나, 의식의 흐름에 따라 글을 쓰다보면 자주 이런 일이 벌어진다. 특히 반말로 쓰다가 갑자기 존댓말이 나오는 경우가 심심찮게 보이는데, 그 순간 글을 쓴 상대의 수준을 의심할 수 밖에 없다. 퇴고조차 안 하고 계획서를 갖고왔다는 뜻이기 때문이다. 어떠한 개념, 단어의 표기에 대해서도, 전체적인 느낌과 방향을 일관되게 잡는 것은 매우 중요하다. 앞에서는 '피칭'이라고 쓰고, 뒤에서는 'Pitching'이라고 쓴다던가 하면 매우 보기 좋지 않다. 그리고, 무엇보다도, 숫자의 사용에 주의해야 한다. 숫자만 써있고 단위를 안 써놔서 백만원인지 천원인지 그냥 1원 단위인지 모르겠다거나, 3자리마다 쉼표를 넣지 않아 자리수 구별이 힘들다거나, 오탈자 때문에 도출될 수 없는 숫자가 나왔다거나 한 것을 발표 당일, 그 자리에서 알았다면, 최대한 정중하게 사과하고 정정한 후 그냥 마음을 비우는 게 좋다. 금융기관 사람들은 숫자들의 행간과 맥락을 읽는 것에 대해 묘한 자부심을 갖고 있다. 그런데 전년도 당기순이익이 58백만원이었다가 이번년도에 630백만원이 되었다면? 당장 그 부분에 대해 추궁이 들어올 것이다. 민감하게 반응하는 부분인 것이다. 숫자 하나가 있고 없고로 수 억, 수십 억이 왔다갔다 하는 세계에서 살아온 사람들은 자동적으로 이렇게 될 수 밖에 없다. 어차피 스타트업의 사업계획서라고 해 봐야, 앞으로 성장할지 망할지는 그야말로 신만이 아는 영역이다. 그러나 이 부분에 대해서, 소위 말하는 '가라'를 칠 때도, 터무니없는 수치를 넣어선 절대 안 된다. 향후 매출 예상의 증가율이 들쭉날쭉하다던가, '대충 이만큼 늘겠지'라는 생각으로 써넣은 부분에 대해서 호되게 털리고 나면, 처음에는 왜 이런 걸 가지고 난리를 치는지 잘 이해가 안 갈 것이다. 어차피 앞으로 우리 회사가 어떻게 클 지는 아무도 모르는데. 하지만 그들은 연속된 숫자의 나열에서 일정한 흐름을 찾는 일을 하는 사람들이기 때문에, 그 흐름이 흐트러져 있는 것을 숨은그림찾기에서 펜촉이랑 돛단배 찾아내는 것 보다 쉽게 알아낸다. 반드시 조심해야 한다. 내용보다 디테일을 세심하게 보는 사람도 있다.*악마는 프라다를 입고, 디테일에 숨어있다.5. 써보세요 숫자에 대해 이런 묘한 집착이 있다면, 당연히 좋은 쪽으로도 이용할 수 있다. 전년도 대비 금년 매출이 28.17% 성장할 것이라고 적었다면, 28.17%라는 수치가 나온 것에 대한 명확한 근거를 적어주자. '이 친구 일 좀 할 줄 아는 친구구만, 허허허'라는 말을 하진 않겠지만 대충 그런 느낌을 받을 수 있을 것이다. 근거로 댈 수 있는 것들은 찾아보면 아주 많다. 모든 비지니스 관련자들이 그렇게 생각하겠지만, 이 일을 함으로써 나에게 '어떤' 이득이 '얼마나' 떨어지는가에 대해서 적어주는 것 만큼 상대를 유혹하는 것이 없다. 객관적인 수치의 제시는 나의 주장을 더욱 공고히 하고 신뢰감을 심어주는 동시에, 상대가 나의 제안을 받아들이는 것에 대한 논리적 근거가 되어 준다. 물론, 정말 쓰잘데기 없는 수치를 집어넣으면 바로 역효과가 난다는 것을 명심해야 한다. 대충 싸잡아 계산해봤더니 80% 정도더라 하는 건 안 쓰느니만 못하다. 필요한 부분에 필요한 만큼만 사용해야 한다. 일종의 그로스해킹이라고 할 수도 있을텐데, 숫자에 민감한 사람들이 보는 자료이니만큼 온갖 것들에 수치를 제시하고 붙이면 그만큼 피로도가 가중된다. 무엇이든 적당히가 중요하다.*뭐든지 쓰기 나름이다. 최근, 이런저런 일로 다양한 형식과 다양한 분량의 사업계획서를 다양한 방법으로 쓰고 있다. 사업계획서라는 것을 여태 보기만 했지 써 본 적이 없던 나에게는 매 순간순간이 상당히 새로운 도전이었음과 동시에, 영혼을 갈아내는 듯한 고통을 맛보는 시간이었다. 사업계획서는, 사업에 대한 계획을 쓰니까 사업계획서라고 하는 것이다. 그리고 우리 모두가 알다시피, 세상엔 계획대로 진행되는 일이 별로 없다. 계획을 세워 그대로 따라가려 마음 먹어도 100% 계획대로 실행되는 일은, 내가 아는 한 단 하나도 없다. 어차피 실행여부도 불투명하고, 실현 가능성도 불투명한 것에 대해 계획을 세우고 논리를 전개해 나가려니 그야말로 사람이 갈려나가는 기분을 맛볼 수 있는 것이다. 그렇지만, 사업계획서는 외부에 우리 팀의 매력을 알리는 아주 효과적인 방법이기도 하다. 모든 것이 계획대로 흘러가지는 않지만, 큰 얼개만이라도 따라갈 수 있다면, 그렇게 함으로써 믿음과 신뢰를 줄 수 있다면 상대방은 우리를 충분히 매력적으로 느낄 것이고, 다양한 호혜적 관계를 맺음에 있어 그 바탕이 될 것이다. 그런 중요한 문서를 작성할 때에 상대의 특성과 성향에 따른 아주 작은 부분에서 이미지가 갈려버리는 것은, 결코 바람직한 일은 아니다. 하지만 이 사람들이 왜 그런지 이해하고, 그것들에 대해 아주 작은 배려를 하는 것으로 좋은 인상을 심어줄 수 있다면, 하지 않을 이유가 없는 부분이기도 하다. 현재의 나는 내 앞가림조차 잘 하고 있는 상황이 아니지만, 금융권에서 일하고 있었을 때의 경험을 공유하면서 조금이라도 그 효과를 보는 팀이 있기를 바라고 있다. 내가 줄 수 있는 것은 이런 것들 밖에 없으니, 다 같이 없는 처지에 조금이라도 나누며 돕고 살아야 하지 않겠는가. 그런 의미에서, 외국계 증권사의 업무가 궁금하거나, 피칭은 어떻게 이루어지는지, 펀드상품이나 보험상품의 취급, 증권 영업 같은 분야에 대해서 흥미가 있는 분들은 얼마든지 하단의 캐주얼 미팅 버튼을 통해 연락 주시기 바란다. 차 한 잔 정도 사드리면서 직접 만나 이야기를 나눠도 좋고, 채팅이나 메일로 간단한 궁금증만 해소해도 좋다. 항상 기다리고 있다.#더팀스 #THETEAMS #영업 #대기업경험 #사업계획서 #사업소개서 #IR피칭 #인사이트 #경험공유
조회수 4634

웹서버 로그 수집과 모니터링 설정

우리는 고객이 무엇에 관심 있어 하고 무엇에 관심 없어하는지, 어떤 것을 보았을 때 클릭해 들어가고 어떤 것을 보았을 때 사이트에서 이탈하는지 궁금해 합니다. 이러한 정보를 얻기 위해 봐야 할 것은 역시 웹서버의 접속 로그입니다.처음에는 매일 생성되는 로그 파일을 일일이 파싱해서 원하는 정보를 DB에 쌓는 방법을 이용했지만, 이러한 방식은 한계가 있었습니다. 저장할 수 있는 데이터의 양에 심각한 제한이 있었고, 따라서 처음에 얻고자 했던 데이터 이상의 것을 새로 추출할 수도 없었습니다.그래서 지금은 웹서버 로그를 하둡(Hadoop) 클러스터에 쌓고 있습니다. Google Analytics 같은 외부 분석툴을 사용하기도 하지만, 아무래도 데이터를 우리 손에 직접 들고 있는 것이 더 유연한 분석을 제공할 수 있지요. 클러스터에서 로그를 분석하려면 가장 먼저 로그 수집 시스템을 만들어야 합니다.이번 포스팅에서는 이 로그 수집 시스템이 어떻게 만들어져 있는지, 그리고 그보다 더 중요한 시스템의 모니터링을 어떻게 하고 있는지 설명하려고 합니다.Flume 에이전트 설정하기Apache FlumeApache Flume은 로그와 같은 데이터의 흐름(streaming)을 제어할 수 있게 해주는 도구입니다. 단순하면서도 확장성 높은 구조로 되어 있기 때문에 많은 시스템에서 채택하는 도구가 되었고, 리디북스에서도 Flume 을 사용하게 되었습니다.Flume 의 기본 구조는 단순합니다.기본적인 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)에이전트(agent)는 Source, Channel, Sink 로 이루어진 자바 프로세스이다.소스(source)는 외부에서 이벤트를 입력받아 채널(channel)로 전달하고, 채널은 이벤트를 저장하고 있다가 싱크(sink)로 전달한다. 싱크는 이벤트를 외부로 출력한다.한 에이전트의 Sink와 다른 에이전트의 Source가 같은 타입이면, 에이전트 간에 이벤트를 전달할 수 있다.굉장히 간단하지만 강력한 모델입니다. Flume 은 Avro, Thrift, Exec, HDFS, Kafka 등 다양한 라이브러리를 적용한 소스와 싱크를 미리 제공하고 있기 때문에, 사용자는 자기 입맛에 맞게 이를 조합해서 시스템을 구성할 수 있습니다.예를 들면 아래와 같습니다.좀 더 복잡한 에이전트 구성 (이미지 출처: Apache Flume 홈페이지)초기 에이전트 구성: Avro를 통해 클러스터에 로그 전송저희가 맨 처음 설정한 Flume 에이전트의 구성은 다음과 같습니다.초기 에이전트 구성각 웹서버ExecSource: exec 명령으로 실행된 프로세스의 표준 출력을 이벤트로 입력받음. (tail -F <로그파일>)MemoryChannel: 메모리상의 큐(queue)로 구현된 채널AvroSink: 클러스터에 상의 에이전트가 실행하는 Avro RPC 서버로 이벤트를 전송하둡 클러스터AvroSource: 웹서버의 에이전트가 Avro RPC 로 보내는 이벤트를 수신MemoryChannelHDFSSink: HDFS 상의 지정된 경로의 파일에 이벤트 내용을 출력각 웹서버에는 에이전트가 하나씩 실행되어서, 로그 파일에 새로 추가되는 로그를 클러스터에 전송합니다. 클러스터 상의 에이전트는 단 한 개 존재하는데, 웹서버로부터 전송받은 로그를 HDFS(Hadoop File System) 에 파일로 출력하는 역할을 합니다. 웹서버 에이전트와 클러스터 에이전트 간의 통신은 Avro RPC 로 하게 하였습니다. Flume 에서 기본적으로 AvroSource 와 AvroSink 를 구현하여 제공해 주는 것을 이용했습니다.사실은 클러스터 상의 에이전트가 Avro 서비스를 통해 데이터를 모아 주지 않고, 웹서버 상의 에이전트가 HDFSSink 를 이용해서 직접 클러스터에 파일을 쓰게 하더라도 대부분의 경우는 상관없습니다. 하지만 리디북스의 경우는 그렇게 할 수 없었는데, 왜냐하면 웹서버와 하둡 클러스터가 서로 다른 네트워크 상에 있기 때문입니다.리디북스의 웹서버는 국내 IDC에 존재하지만 하둡 클러스터는 Miscrosoft Azure 클라우드 내의 가상머신으로 실행되고 있습니다. 따라서 하둡의 네임노드(namenode)가 인식하는 각 노드의 사설 IP 주소를 웹서버들이 쉽게 접근할 수 없습니다. 이를 우회하는 다양한 방법을 시도해 보았지만 최종적으로는 Avro 서비스를 중간에 두어 해결하였습니다.모니터링 알람 설정하기JSON 리포팅 사용다음은 에이전트 프로세스를 모니터링하는 문제가 있었습니다. 예기치 않은 에러로 에이전트가 종료되어서 로그가 수집되지 않고 있는데 며칠 동안 모르고 있어서는 안되겠지요.Flume 에서는 모니터링 인터페이스도 여러가지를 제공하고 있는데, 그 중 가장 이용하기 간편한 것은 HTTP 를 통한 JSON reporting 이었습니다. 에이전트 자체가 HTTP 서비스로 작동해서, 특정 포트로 요청을 보내면 에이전트의 상태를 JSON 으로 정리하여 응답을 주게 되어 있습니다. 에이전트 실행시에 옵션 몇 개만 추가하면 바로 설정할 수 있기 때문에 매우 간단합니다.Health 페이지를 이용한 모니터링그런데 이 리포팅이 제대로 나오지 않으면 어떻게 알림을 받을 수 있을까요? 각 서버마다 JSON 리포팅을 요청해서 응답이 제대로 오지 않으면 이메일을 보내는 스크립트를 만들어서 cron 으로 5분마다 실행하는 방법도 있습니다. 하지만 이 스크립트가 제대로 동작하지 않거나, 이게 실행되는 서버가 다운되면?결국 스스로를 믿지 못하고 택한 방법은 외부 서비스 Pingdom을 이용하는 것이었습니다. 단, 외부 서비스가 각각의 웹서버에 직접 접근하여 리포팅을 요청하는 방식은 보안상 문제가 될 수 있어서 아래와 같이 보완하였습니다.웹 서비스 상에 health 페이지 구현. 이 페이지는 각 웹서버의 에이전트의 JSON reporting 포트로 요청을 보내서, 결과를 종합해서 다시 JSON 으로 보여줌.모든 에이전트가 정상적으로 리포트를 보내면 {“status”: “OKAY”} 를, 아니면 {“status”: “ERROR”} 를 보여줌.이 health 페이지의 내용을 모니터링하도록 Pingdom 설정. {“status”: “OKAY”} 가 응답에 없으면 알람 메일이 오도록 함.{ "status": "OKAY", "metrics": { "192.168.0.101": { "SOURCE.log_src": { ... }, "SINK.avro_sink": { "BatchCompleteCount": 562110, "ConnectionFailedCount": 294, "EventDrainAttemptCount": 56246850, "ConnectionCreatedCount": 31, "Type": "SINK", "BatchEmptyCount": 16, "ConnectionClosedCount": 30, "EventDrainSuccessCount": 56243927, "StopTime": 0, "StartTime": 1459135471379, "BatchUnderflowCount": 610 }, "CHANNEL.mem_channel": { ... } }, "192.168.0.102": { ... } } }Health 페이지의 Json내용JSON 리포팅의 문제이렇게 설정해 놓고, 며칠간 로그가 HDFS 상에 잘 수집되는 것을 확인하고 만족해 했습니다. 그런데 며칠간 신경을 쓰지 않은 사이, 다시 에이전트를 확인해 보니 모든 웹서버 에이전트가 죽어 있었습니다. HDFS에 로그도 쌓이지 않았구요.확인해 보니, MemoryChannel 의 설정 문제였습니다. byteCapacity 값을 실수로 너무 작게 설정해서, 채널 큐가 메모리 부족으로 터져나간 것이죠. 해당 문제는 byteCapacity 값을 늘려서 간단하게 해결했습니다.문제는 알람이 오지 않았다는 것이었습니다. 문제를 재현해 본 결과, 채널이 터져서 에이전트 실행이 중단되어도, 에이전트 프로세스는 죽지 않고 ExecSource 에서 실행한 자식 프로세스(tail -F)만 죽어 있었습니다. 이렇게 되면 JSON 리포팅도 정상적으로 나오기 때문에, 결국 JSON 리포팅으로는 이런 유형의 에러를 잡지 못한다는 결론이 나왔습니다.클러스터에 모니터링 설정하기결국 웹서버상에서 모니터링하는것 보다는 데이터를 최종 전달받는 하둡 클러스터 상에서 모니터링하는 것이 안정적이라 판단하였습니다. 다행히도, 하둡 클러스터에서 사용할 수 있는 꽤나 좋은 모니터링 도구가 이미 있었습니다.CDH 의 알람 트리거리디북스에서는 기본 하둡 패키지가 아닌, Cloudera에서 제공하는 하둡 배포판인 Cloudera CDH를 사용하고 있습니다. CDH는 클러스터 상에서 사용되는 서비스마다 각종 테스트를 자동으로 실행하여, 테스트가 통과되지 않을 때마다 메일로 알람을 보내줍니다. 그리고 웬만한 필수 테스트는 기본적으로 설정되어 있지만, 사용자가 커스텀 서비스를 직접 제작할 수도 있습니다. CDH가 각 에이전트의 소스, 채널, 싱크마다 초당 전송한 이벤트 개수 등의 측정치(metric)을 모두 기록하고 있기 때문에, 이 값들이 일정 수준 이상/이하가 될 때마다 알람이 트리거되도록 설정할 수 있습니다.CDH의 알람 트리거 편집 화면웹서버마다 알람 설정하기그런데 이것으로 끝이 아닙니다. 클러스터 에이전트는 각 서버에서의 트래픽이 모두 모이는 곳이기 때문에, 여기에서 모니터링을 하는 것은 웹서버 상에서 모니터링하는 것보다 기준이 애매해집니다.10대의 웹서버 중에 한 대만 문제가 생겼을 경우, 클러스터 에이전트가 받는 트래픽은 0으로 줄어드는 것이 아니라 90%로 줄어듭니다. 알람을 트리거하는 역치(threshold)를 평소 트래픽의 90%로 잡아야 한다는 것이지요. 그런데 트래픽이라는 것이 원래 날짜와 시간에 따라 달라지기 때문에, 이 역치값을 고정된 값으로 정할 수가 없습니다. 트래픽이 높은 때를 기준으로 하면, 트래픽이 낮아지는 새벽 시간마다 가짜 알람(false alarm)이 오게 되겠지요. 그렇다고 트래픽이 낮은 때를 기준으로 하면, 트래픽이 높은 때 웹서버 에이전트가 죽더라도 새벽이 될 때까지 알 수 없습니다.결국 클러스터 단에서도 각 웹서버마다 트래픽을 구분해 주어야 한다는 결론이 나옵니다. 다행히 한 에이전트가 여러 개의 채널과 싱크를 가질 수 있고, 이벤트 헤더의 내용에 따라 소스가 어느 채널로 이벤트를 보낼지 결정해 주는 채널 셀렉터 (Channel Selector)라는 것이 있습니다.웹서버 에이전트의 소스에서는 각 이벤트 헤더에 자기 호스트명을 달아 준다. (Interceptor 는 각 이벤트에 원하는 헤더를 달아주는 역할을 한다. HostInterceptor 이용)클러스터 에이전트는 1개의 소스와, 웹서버 대수만큼의 채널 및 싱크가 있다.클러스터의 소스는 이벤트의 host 헤더를 보고 그에 해당하는 채널로 이벤트를 전달한다. (MultiplexingSelector 사용)각 채널은 자신에게 대응되는 싱크에 이벤트를 전달하고, 싱크는 각자의 HDFS 경로에 이벤트를 파일로 출력한다.최종 에이전트 구성: 채널 셀렉터로 트래픽 나누기최종적으로 나온 에이전트의 구성은 다음과 같습니다.최종 에이전트 구성그리고 에이전트 설정 파일은 아래와 같이 작성했습니다.... log_to_avro.sources.log_src.type = exec log_to_avro.sources.log_src.command = tail -F /path/to/log/file log_to_avro.sources.log_src.restart = true log_to_avro.sources.log_src.channels = mem_channel log_to_avro.sources.log_src.interceptors = ts_ic host_ic # 호스트 인터셉터 설정 log_to_avro.sources.log_src.interceptors.ts_ic.type = timestamp # 이벤트 헤더에 timestamp 삽입 (날짜별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.type = host # 이벤트 헤더에 호스트명 삽입 (호스트별 구분을 위해) log_to_avro.sources.log_src.interceptors.host_ic.useIP = true # 호스트명 대신에 IP 사용 log_to_avro.channels.mem_channel.type = memory log_to_avro.channels.mem_channel.capacity = 10000 log_to_avro.channels.mem_channel.transactionCapacity = 10000 log_to_avro.channels.mem_channel.byteCapacityBufferPercentage = 20 log_to_avro.channels.mem_channel.byteCapacity = 10485760 log_to_avro.sinks.avro_sink.type = avro log_to_avro.sinks.avro_sink.channel = mem_channel log_to_avro.sinks.avro_sink.hostname = hostname.of.cluster.agent log_to_avro.sinks.avro_sink.port = 4141 ...웹서버 에이전트 설정파일... avro_to_hdfs.sources.avro_src.type = avro avro_to_hdfs.sources.avro_src.bind = 0.0.0.0 avro_to_hdfs.sources.avro_src.port = 4141 avro_to_hdfs.sources.avro_src.channels = c_101 c_102 avro_to_hdfs.sources.avro_src.selector.type = multiplexing # Multiplexing Selector 설정 avro_to_hdfs.sources.avro_src.selector.header = host # 호스트 이름으로 채널 나누기 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.101 = c_101 # 192.168.0.101 에서 온 이벤트는 c_101 채널로 avro_to_hdfs.sources.avro_src.selector.mapping.192.168.0.102 = c_102 # 192.168.0.102 에서 온 이벤트는 c_102 채널로 # 채널 c_101 설정 avro_to_hdfs.channels.c_101.type = memory avro_to_hdfs.channels.c_101.capacity = 10000 avro_to_hdfs.channels.c_101.transactionCapacity = 10000 avro_to_hdfs.channels.c_101.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_101.byteCapacity = 10485760 # 싱크 k_101 설정 avro_to_hdfs.sinks.k_101.type = hdfs avro_to_hdfs.sinks.k_101.channel = c_101 avro_to_hdfs.sinks.k_101.hdfs.fileSuffix = .log.gz avro_to_hdfs.sinks.k_101.hdfs.path = hdfs://namenode/path/to/logs/dir/%Y%m%d/%{host} # 날짜별, 호스트별로 다른 디렉토리에 avro_to_hdfs.sinks.k_101.hdfs.rollSize = 104857600 avro_to_hdfs.sinks.k_101.hdfs.rollInterval = 7200 avro_to_hdfs.sinks.k_101.hdfs.rollCount = 0 avro_to_hdfs.sinks.k_101.hdfs.fileType = CompressedStream avro_to_hdfs.sinks.k_101.hdfs.codeC = gzip # 채널 c_102 설정 avro_to_hdfs.channels.c_102.type = memory avro_to_hdfs.channels.c_102.capacity = 10000 avro_to_hdfs.channels.c_102.transactionCapacity = 10000 avro_to_hdfs.channels.c_102.byteCapacityBufferPercentage = 20 avro_to_hdfs.channels.c_102.byteCapacity = 10485760클러스터 에이전트 설정파일p.s. Flume 설정 파일은 변수 또는 외부 파일 include 등을 지원하지는 않아서, 위와 같이 반복되는 설정을 여러 번 써 주어야 합니다.호스트마다 CDH 알람 트리거 설정그리고 CDH 상에서도 웹서버 호스트의 개수만큼 알람 트리거를 만들어 줍니다. 초당 이벤트 개수가 0에 가깝게 떨어지면 알람이 오도록 해 주면 됩니다. 채널/싱크 중 어느 것을 기준으로 해도 크게 상관은 없는데, 저희는 싱크가 초당 이동완료한 이벤트 개수를 기준으로 했습니다.CDH에서의 알람 트리거 상태 화면이렇게 해 놓으면 또 한가지 좋은 점은, CDH가 알아서 차트를 그려 주기 때문에, 웹서버마다 트래픽 추이를 한눈에 볼 수 있다는 것입니다.HDFSSink의 초당 이벤트 개수 그래프맺음말지금까지 Apache Flume 과 CDH 를 사용해 로그 수집 시스템을 구성하고 모니터링을 설정한 후기를 살펴 보았습니다. 이 과정에서 느낀 점들을 한번 정리해 보겠습니다.첫째, 일견 간단해 보이는 기능이었지만 의외로 많은 시행착오를 거쳐야 했습니다. 아무리 간단해 보이더라도 각자의 상황에 맞추어 시스템을 설계하는 데에는 그에 맞는 고민을 거쳐야 합니다.둘째, 처음에는 로그가 일단 수집되게 하는 것이 가장 중요하다고 생각했는데, 실제로 겪어보니 모니터링이 훨씬 어렵고 중요한 문제라는 것을 알게 되었습니다. 어떤 기능이 일단 실행되도록 설정을 해 놓더라도, 그것이 매일 문제없이 실행됨을 보장받는 것은 또 다른 문제입니다.셋째, Health 페이지와 Pingdom을 이용한 웹서버 측의 모니터링은 JSON 리포팅의 문제 때문에 큰 쓸모가 없게 되었습니다. 하지만 꽤 유용한 테크닉이라는 생각이 들고, 어딘가에서는 비슷하게 이용할 수 있을 것 같습니다.마지막으로 CDH 쓰면 좋습니다. 많은 것들이 편해집니다.P.S. 리디북스 데이터팀에서는 이러한 로그 시스템을 함께 고민하고 만들어나갈 분들을 찾고 있습니다. 많은 관심 부탁드립니다.#리디북스 #개발 #서버 #서버개발 #모니터링 #로그 #Flume #CDH #로그수정 #인사이트
조회수 1094

CodeStar + Lambda + SAM으로 테스트 환경 구축하기

들어가기 전: 실제로 프로젝트와 팀원들과의 작업 환경을 구축한 경험을 바탕으로 작성했습니다. 한마디로 실화. Overview소스를 수정할 때마다 지속적인 테스트를 하기 위해 AWS lambda 로컬 테스트 환경, SAM을 결합해서 환경을 구축했습니다. 이번 글에서는 팀원을 추가하고 CodeCommit을 리포지토리로 사용하는 것도 소개하겠습니다. 예상 구성도테스트 환경 구축, 도저언!1. 팀원 추가하기 IAM 서비스를 이용해서 프로젝트를 같이 사용할 유저를 추가합니다. IAM에 유저를 추가하면 AWS 콘솔을 같이 사용할 수 있습니다. 사용자 추가를 클릭해 유저를 추가합니다. 팀원마다 한 개의 계정을 추가해야 합니다. 사용자 세부 정보 설정 > 엑서스 유형에서 ‘프로그램 방식 엑서스’와 ‘AWS Managrment Console 엑서스’를 체크합니다. 여기에서는 개발2팀 팀원인 강원우 과장의 계정을 생성했습니다.1) 비번은 귀찮으니 미리 세팅해둡시다. 유저 계정은 그룹을 생성해서 관리하면 편합니다. 그룹을 사용하면 보다 편리하게 계정 권한을 제어할 수 있기 때문입니다. 이번 예제에서는 그룹 이름을 codeStarGroup으로 만들었습니다. AWSCodeStarFullAcess를 정책으로 설정하고 ‘그룹생성’을 클릭해 그룹을 추가합니다. 2) codeStarGroup에 체크한 후, ‘다음: 검토’를 클릭해 진행합니다.‘사용자 만들기’를 클릭해 생성을 마무리합니다.계정 추가를 완료했습니다.사용자 이름(위의 예시에서는 kanggw)을 클릭하고, 뒤이어 ‘보안자격 증명’ 탭을 클릭합니다.콘솔 로그인 링크를 공유합시다. 링크를 입력하고 들어가면 그룹 로그인이 활성화가 되어있다는 걸 볼 수 있습니다.2. CodeStar 설정하기 프로젝트 인원을 무사히 추가했습니다. 이제 프로젝트를 만들어 봅시다. CodeStar 프로젝트 세팅 방법은 R&D본부 윤석호 이사님이 쓴 ‘애플리케이션 개발부터 배포까지, AWS CodeStar’를 참고해주세요.새 프로젝트를 생성합니다.python AWS Lambda를 선택합니다.프로젝트 이름은 ‘admin-lambda-API’로 입력하겠습니다. 그 후에 ‘다음’을 클릭합니다.‘프로젝트 생성’을 클릭합니다.우리는 Git을 이용해 로컬에서 직접 관리할 것이므로 ‘명령행 도구’를 선택한 후, ‘건너뛰기’를 클릭합니다.3분 만에 프로젝트가 생성되었습니다. 참 쉽죠?3. 프로젝트에 팀원 추가하기프로젝트를 같이 하려면 팀원을 추가해야겠죠. 팀원 추가는 codeStar 대시보드 좌측의 ‘팀’ 탭을 클릭하면 됩니다.‘팀원 추가’ 클릭IAM에서 등록한 팀원의 정보를 불러옵니다. ‘추가’를 클릭해 팀원을 추가합니다. 여기에서 중요한 사실 하나! 프로젝트의 소유자로 지정해야 소스 접근 및 코드 변경이 가능합니다.4. 코드 체크 아웃앞서 설명한 것처럼 직접 Git으로 소스를 받아야 하기 때문에 codeCommit으로 이동합니다. codeStar 대시보드 왼쪽 ‘코드’ 탭을 클릭하면 코드 내역들을 확인할 수 있습니다.‘URL 복제 > HTTPS’를 클릭해 경로를 복사합니다. 소스를 클론하기 전에 계정에 깃허용을 먼저 해주세요. IAM 돌아와서는 계정 설정을 변경해야 합니다.사용자 > kangww > 보안 자격 증명 탭 클릭 > HTTPS Git 자격 증명 > 생성Git에서 사용할 ID와 비밀번호를 받았습니다. 해당 정보를 팀원에게 전달합니다. 이제 workspace로 이동해 체크아웃을 시작합니다.git clone [복사한 경로] [id 입력] [pw 입력] clone이 완료 되었습니다. 이제 기본 프로젝트가 들어있기 때문에 바로 실행할 수 있습니다. 미리 설치된 SAM으로 실행해보겠습니다.이제 해당 경로에 이동해 SAM을 돌려서 정상적으로 구동되는지 확인해봅시다. (SAM설치 방식은 부록에서 소개합니다.) sam local start-api -p 3333 성공적으로 SAM이 구동되었습니다. (짝짝) http://localhost:3333 으로 접근해 결과를 확인할 수 있습니다. 이제 로컬에서 작업을 진행하면서 바로 바로 확인이 가능해졌습니다. 만약 동료와 함께 개발한다면 아래처럼 구동해야 자신의 IP에 접근할 수 있습니다.sam local start-api -p 3333 -host [자신의아이피] 글을 마치며CodeStar의 관리와 배포 기능은 강력합니다. 많은 부분을 알아서 해주니 고마울 뿐입니다.3) 이제 Lambda의 local 테스트 환경인 SAM을 이용해서 배포 전 과정까지 간편하게 테스트를 해보세요. 배포의 복잡함을 codeStar에서 해결하고 테스트를 하거나 개발을 할 때는 SAM을 이용해 효율적으로 업무를 진행합시다.글 쓰면서 발견한 다섯 가지1) codeDeploy > executeChangeSet 에 구동될 때 cloundFormation 이 자동 세팅 됩니다. 엄청 편합니다. API 배포가 진행되면 lambda에서 바로 수정하는 게 편합니다.2) codeCommit은 https 보다 ssh방식을 권장하며, https방식으로 하다가 꼬이면 여기를 클릭해 해결하세요.3) codeStar는 다음과 같은 추가 구성을 자동 세팅합니다.codeStar 용 S3 버킷codePipeLine용 S3 버킷cloundFormation 세팅lambda 세팅4) IDE를 cloud9을 사용하면 EC2 및 EBS가 생성되니 주의하세요. 그리고 생각보다 느립니다.5) 로컬에서 Git push를 하면 약 5분 정도 뒤에 최종적으로 배포됩니다.부록1)SAM을 설치하기 전, 여기를 클릭해 docker를 미리 설치하세요.2)SAM 설치 안내는 여기를 클릭하세요. ( npm install -g aws-sam-local )참고1)강원우 과장은 귀여운 두 달팽이, 이토와 준지의 주인이기도 하다. 2)AWSCodeStarFullAcess는 codestar 접근에 대한 권한을 부여한다.3)자동 배포까지 2~5분 정도 걸리는 게 어렵게 느껴질 수 있다.글천보성 팀장 | R&D 개발2팀chunbs@brandi.co.kr브랜디, 오직 예쁜 옷만#브랜디 #개발문화 #개발팀 #업무환경 #인사이트 #경험공유
조회수 1702

[피플] H자동차를 퇴사하고 더부스에 온 그녀, 심층 인터뷰 제 2탄!

[ 더부스팀 인터뷰 특별기획 2부 ]대기업 퇴사를 고민하고 있나요?꿀같은 설날 연휴의 끝.사무실 책상 앞에 다시 앉았더니답답하고 숨이 턱, 막혀오면서,회사 일은 손에 잡히지도 않고당장 집으로 뛰어가따뜻하고 포근한이불속으로 들어가고싶은 마음만 한 가득.연휴 금단 증상!마우스를 잡은 손이 덜덜 떨리지는 않나요?이렇게 일하기가 싫은데,나는 지금 행복한게 맞을까요?여기 비슷한 고민을 하다H자동차를 퇴사하고더부스 브루잉에 합류한,더부스 영업전략의SJ님을 소개합니다!"마음 가는 길 .죽 곧은길!"SJ님연세대학교 기계공학과 졸업前  현대자동차 재직現  더부스 영업전략/마케팅Q1. 자기소개를 한다면?저는 호기심이 굉장히 많은 편이에요. 얼어붙은 연못 위에 올라가 얼음이 잘 얼었나 직접 확인해보거나, 맥주집에서 '작은 잔과 큰 잔의 맥주 양 차이'를 직접 재보는 등 궁금한게 있으면 꼭 확인해야 직성이 풀리는 성격이죠. 엉뚱한 장난을 치는것도 굉장히 좋아하는데, 간섭받거나 구속받는건 굉장히 좋아하지 않아요. 어떻게 보면 멀쩡히 대학 나와 대기업에 입사한게 이상할정도로 사실 제도권에 그렇게 어울리는 성격은 아니죠 (웃음). 고등학교 때도 수업시간 내내 제가 읽고 싶은 책만 잔뜩 읽었거든요. 나중에는 선생님들도 쟤는 원래 그런다면서 포기했다니까요.Q2. 맥주는 얼마나 좋아하세요?많이 좋아해요!  대학생 시절 MT를 가면 냉장고에 소주만 한가득이었어요. 그렇지만 저에게 소주, 카스, 하이트 등의 술은 너무 맛없게만 느껴졌어요. 정말 이걸 정말 좋아서 먹나? 라는 생각이 들어서 별로 술을 즐기지 않았죠. 그런데 어느날 본격적으로 크래프트 비어를 접하고는.... 네, 집에 맥주 병을 모으고 있습니다.SJ님의 강아지 '진도리'Q3. 더부스에 조인하기 전에는 대학원에 다니셨다고 들었어요! 맞나요?네, 저는 대학 졸업 후 H자동차를 약 2년간 다니다가, 회사 일이 잘 안맞고 재미가 없어서, 그리고 더 공부해보고 싶은 분야가 생겨서 대학원에 진학했었어요. 회사를 처음 벗어나서 오랜만에 학교에 다시 갔을 때는, 세상에 아름다워 보였어요~ 하하하. 수업시간에 자꾸 혼자 웃음이 나올 지경이더라고요. 사람들이 미친여자라고 생각할까봐 실실 터져나오는 웃음을 꾹 참았어요~Q4. 그럼 어떻게 더부스에 조인하게 되셨나요?제가 맥주를 좋아하다보니 언젠가는 자신의 펍을 갖고 싶다는 생각을 갖고 있었어요. 그러다 어느날 경리단길의 '비어포긱스 테이스팅 룸(더부스에서 운영)'을 들렸는데 맥주가 너무 신선하고 맛있는거에요. 알고보니 유럽이나 미국에서 생산되는 맥주를 '차가운 상태 그대로' 서울까지 갖고 온다더라고요. 그래서 저도 꼭 비어포긱스 테이스팅 룸 같은 펍을 내고 싶어서 사장님에게 건너건너 연락을 했었는데, 나중에라도 따로 점포를 늘릴 생각이 없다고 하시더라고요. 속상했었는데... 나중에 더부스에서 직원을 뽑는다는 소식에 함께 하고 싶어 지원했고, 더부스팀에 합류하게 되었죠!(참고 : 현재 비어포긱스 테이스팅 룸은 잠시 운영이 중단된 상태. 미켈러바로 가면 됩니다!)Q5. 대학원 공부도 재미 없었던 것은 아니죠?하하, 그런건 아니에요. 대학원에서 신호처리/머신러닝 쪽을 공부했는데 흥미로웠어요. 예전부터 관심있었던 주제였거든요. 졸업 요건을 다 채운 후에, 더부스에 합류하게 되었죠. 공식적으로는 졸업이 아직 한 학기가 남았어요. 어떻게 보면 서로 전혀 무관한 커리어를 쌓아온 것 같지만, 대학원은 '나에게 더 잘맞는 일을 찾아나가는' 연장선상에 있었다고 생각해요. 대학원에서 배운 데이터를 처리하는 기술은 더부스의 영업전략을 세울 때도 도움이 되고 있습니다.Q6. 그렇다면 대학 졸업 후 대기업에 입사한 이유는 뭔가요?대부분의 친구들이 대학원에 진학 했었는데, 저는 학교를 벗어나 아직 안 해본걸 해보고 싶은 마음이 강했어요.  외국 연구소에서 인턴으로 일해보기도 했고, 대학생 시절 수학과외로 꽤 쏠쏠히 벌었지만, 학교 밖의 기업에서 일해본 적은 없었기 때문에 더 궁금했죠.Q7. H자동차에서는 어떤 것들이 맞지 않아 퇴사를 하신건가요?간단히 말하면 '재미가 없었'죠. 하지만 마냥 가볍기만 한 고민은 아니었어요! 스스로 성취감을 느낄 수 없는 일을 하는건 괴롭다는걸 입사 후에야 깨달았거든요. 대학 시절에는 전공 공부가 힘들지만 즐거워서, 그런 기분을 느껴본적이 없었어요. 회사안에서 사람들과 어울리는건 대부분 즐거웠지만요. 제가 한창 퇴사에 관해 고민하고 있을 때에도 회사 사람들에게 많은 조언과 위로를 받아서 항상 감사했죠. 회사를 떠나 저에게 더 잘맞는 일을 찾고 싶다는 마음이 강했어요. 그리고 저에게는 '당장 잘 먹고 잘 사는 문제' 보다 '즐겁고 행복하게 사는 것'이 더 중요한 가치라는걸 알게됬죠. 사람마다 중요하게 여기는 가치는 다른 법이잖아요? 그래서 제가 더 즐겁게 할 수 있는 일, 나에게 더 잘맞는 일, 성취감을 느낄 수 있는 일을 찾아 떠나고 싶었죠. 저는 용기를 낼 수 있어서 운이 좋았다고 생각해요. 아예 H자동차에 입사한 것을 후회하지는 않아요. 대기업에서만 경험할 수 있는 것들도 많이 배웠거든요.Q8. 본인의 일을 즐겁다고 느끼면서 회사를 다니는 회사원들이 얼마나 될까요?일반적인 대기업을 다니는 회사원들 중에 회사가 재미있어서 다니는 사람은 별로 없을거에요. 회사원의 90%이상은 '먹고 살아야 하니까' 등의 현실적인 이유로 회사를 다니겠죠. 실제로 제 주변에도 퇴사 고민을 하는 사람들이 많았어요. 다만 그 중 대대수는 실행에 옮기지 않고 하루 하루를 다시 버텨낼 뿐이라고 생각해요. 퇴사 한 이후에 퇴사 관련한 고민을 상담해달라는 연락을 많이 받았거든요. 모든 일이 항상 즐거울 수는 없지만, 일에서 느껴지는 괴로움이 즐거움보다 크다면, 자신이 원하는것이 무엇인지 뒤돌아보는 시간을 가지는게 현명한것 같아요. 스스로 즐거워서 몰입 할 수 있는 일을 찾는게 쉬운일은 아니거든요. 고민의 시간이 필요하다고 생각해요.Q9. 회사에 퇴사 이야기를 꺼내는건 쉬운 일이었나요?아니요. 저는 말 꺼내기가 정말 어려웠어요. 팀장님한테 좀 미안하더라고요. 그래서 친한 팀선배의 도움을 받았죠. 선배가 상사와 자리를 마련해 퇴사 이야기를 위한 멍석을 깔아줬어요. 하하. 인사고과 마감날이라 선배에게도 win-win이었죠(농담). 퇴사하겠다고 팀장님에게 확실히 이야기하고, 퇴사일을 정한 다음에는 퇴사일이 다가오는게 너무 설레서 D-day까지 설정해놨었던 기억이 나네요. 하하. 그 과정에서 다른 분은 '나도 회사가 재미없어서 팀을 옮겼는데, 큰 회사니까 회사 안에서 정답을 찾아보려고 팀을 옮긴것이었다.' 라는 조언을 해주시기도 했죠. 지난번 BK님의 이야기처럼 '동일한 문제(일이 재미없다는)' 에 관한 해결 방법이라도 각자 다른 방법의 해결책을 찾을 수 있는 것이니까요. 저에게는 그 솔루션이 퇴사였던 거죠.더부스 강남 1호점Q10. 지금까지의 결정에 후회는 없나요?네. 후회는 하나도 없어요. 아까 이야기 했듯이 회사에서도 드라마처럼 사표를 던지고 나올만한 결정적인 이벤트는 없었고, 하루 하루의 생각들이 쌓여져 퇴사 결정을 내린거니까요. 나름대로 매우 신중했어요. 고민 끝에 찬란한 20대, 30대에 하고 싶은 일들을 놔두고 하고 싶지 않은 일을 하며 시간을 채워간다면, 내가 내 젊음을 너무 헐값에 팔고 있는것이라고 결정을 내리게 된거에요. 그래서 앞으로는 자아성찰(?)을 통해 나에게 잘 맞는 일들을 찾아가려는 노력을 계속 해야겠다고 생각했죠.  물론 H자동차의 급여 수준이나 복지 혜택은 다른 회사들에 비해 매우 뛰어난 수준이었고, 퇴사 하는게 많이 아깝기도 했지요. 그리운 월급... 하하하. 그래도 "내가 하고 싶은 일"을 하는것보다 좋은건 없는 것 같아요. 이렇게 계속 시간이 지나 10년 정도의 시간이 흐른다면 안정감에 회사에 영영 정착할 것 같았어요. 그래서 저는 더더욱 한살이라도 어릴 때 빨리 더 나에게 잘맞는 일을 찾아야지라고 결심했죠. 그래서 저는 회사 이후의 대학원도 즐거웠고, 더부스는 더욱 즐겁네요. 저는 꽤 행복한 삶을 살고 있는것 같아요.SJ님의 동생이 그린 '진도리' 초상화Q11. 그럼 더부스에서 일하는게 그렇게 재밌나요?네. 아직 일을 시작한지 한달 밖에 안됐지만요. 하하.  더부스 캠퍼스에서는 아침, 낮, 저녁, 밤 언제든 맥주를 마셔도 됩니다(중요). 그리고 더부스 캠퍼스에서는 더부스의 마스코트인 귀여운 '하'와 '휴'가 있어요! 자유롭고, 행복한 곳이죠. 아이디어를 내놓는 과정들, 그걸 실현시키는 일들이 재밌어요. 반년후에는 이야기가 달라질지도 모르니, 인터뷰 또 할까요? (농담). 더부스에서는 대기업과 달리 "보고"를 위한 업무도 없고, 모두 젊고 창의적이에요. 팀원들도 각기 다른 배경을 갖고 있어 다채롭고요. 매력적일 수 밖에 없는 팀이죠. 그리고 대기업에서는 직원 한명 한명이 회사의 운명을 좌우하지는 못해요. 정해진 시스템 안에서 한 사람의 몫은 제한적이죠. 기업 입장에서는 그게 가장 합리적이기에, 누구나 대체 할 수 있는 일을 하게 되잖아요? 그러나 한 사람사람이 중요하고, 회사와 함께 성장해야 하는 스타트업에서는 개개인이 회사에 엄청 중요해요. 회사와 함께 성장을 해야되는데, 이런 즐거움은 대기업에서 누리기 힘들죠.더부스 멤버십카드와 홉(hop)Q12. 그래도 '스타트업'에서 일하면서 느끼게 되는 단점도 있을 텐데요!?스타트업은 '현재 기업의 가치'가 중요한것이 아니라 '기업의 미래 가치'가 중요한것이기에, 당연히 대기업에 비해 급여가 적어요.  H자동차에서 누렸던 통근버스, 의료비지원 등의 각종 복지 혜택도 다른 회사에 비하면 월등하죠. 당연한 이야기지만, 현실적으로 중요한 문제이기도 하잖아요? 그래서..... 더부스는 열심히 성장해야 하는데, 많이 도와주세요. 하하하. 더부스 브루잉의 판교 브루어리에서 새로 출시한 맥주들은 정말 맛있어서, 보다 더 많은 사람들이 이 즐거움을 같이 누렸으면 좋겠네요! 본격 음주 권장 인터뷰인가요?! 하하. 인터뷰 끝나고 저도 한잔 해야겠어요. (캠퍼스 한켠에서 판교에서 생산된 생맥주를 따라 마실 수 있어요. 행복하네요.)더부스의 공식 마스코트! 휴와 하Q13. 퇴사를 고민하고 계시는 분들께 조언을 한다면요?한 번 쯤, 마음대로 가는대로 살아도 괜찮아요. 왜 우리나라의 교육은 어렸을 때부터 공부 열심히 하라는 소리에 순응하고 꾹꾹 참는법을 가르치지 '하고 싶어 하는것을 찾는 법'은 잘 가르쳐주지 않잖아요? 그래서, 대부분은 내가 정말 좋아하는게 뭔지 진지하게 고민 할 수 있는 능력을 갖추지 못한 채로 어른이 되는거죠. 내가 정말 원하는것이 무엇인지, 그것부터 먼저 고민을 해보세요. 결국 고민의 끝에서 내린 결론이 '회사를 계속 다니는 것, 회사안에서 즐거움을 찾는것' 이라면 그것대로 '내가 선택한 일' 이니 좋은것 아닐까요? 당연히 어떤 사람은 대기업의 네임벨류, 안정적인 복지에서 행복을 찾을 수도 있잖아요. 반면 저 처럼 고민 끝에 내린 결론이 '회사를 떠나 다른 일을 하는것' 이라면 두려워하지 말고 떠나세요. 한번 뿐인 인생, 결정을 내렸다면 한살이라도 젊을 때 떠나야죠. 마음 가는 길, 죽 곧은 길! 드래곤라자의 명대사잖아요?!Q14. 더부스가 퇴사 상담 전문 기업으로 나서도 되겠네요! 하하.고민하고 계시다면, 언제든지 비밀 덧글로... (소근소근).Q15. 더부스의 다른 팀원들도 모두 대기업 출신인가요?아닙니다. 더부스 팀원 인터뷰 3탄 부터는 보다 더 다채로운 배경의 분들을 만날 수 있습니다. 기대해주세요.Q16. 마지막으로, 맥주 하나만 추천해주세요!미켈러의 스폰탄 시리즈요. 그런데 이 맥주는 사실 엄청 호불호가 갈리는 맥주이기도 해요. 좋아하는 사람은 매우 좋아하지만, 싫어하는 사람은 매우 싫어하거든요. 하하. 너무 재미있지 않나요? 저는 스폰탄 시리즈의 시큼하고 큼큼한 맛을 굉장히 좋아해요. 빠져들면 자꾸 이것만 찾게되죠.  크랜베리, 복숭아, 링고베리 등등 여러가지의 서로 다른 버젼이 있어요. 과일이 들어갔다고 해서 달콤하다고 생각하면 완전 틀린 생각이에요. 자연발효로 만들어진, 미켈러의 실험정신이 돋보이는 맥주죠. 궁금하면 도전해보세요.Make this Happen!새로움을 만들어나가는크래프트 비어 스타트업!#더부스브루잉컴퍼니 #팀원소개 #팀원자랑 #팀원인터뷰 #기업문화 #조직문화 #사내문화
조회수 1831

헷갈리는 UI, 스티비는 이렇게 씁니다.

어떤 버튼을 넣어드릴까요?세상에 온전하게 혼자 만든 물건은 매우 드뭅니다. (풀스택이라는 개념도 있지만) 웹서비스 역시 여러 사람의 협업으로 만듭니다. 슬로워크에서 운영하는 이메일마케팅 서비스 스티비도 예외는 아닙니다. 살짝 말씀드리면 스티비는 기획/PM 1명, 디자이너 1명, 개발자 2명이 만들고 있습니다. 큰 조직은 아니지만 소통의 틈은 늘 존재하기 마련입니다.그중 하나가 UI 용어입니다. 동상이몽이라는 말처럼 각자 웹서비스 개발을 해왔지만, 모두가 같은 상황과 맥락에서 학습한 것이 아니고, 머릿속에 그리는 이미지가 달라 사용하는 용어가 서로 다를 수 있습니다. 그리고 같은 용어를 사용하면서도 그 의미와 구현된 결과물이 다를 수 있습니다.“‘드롭다운’이 들어가야 해요”라고 요청받고 나온 결과물은 ‘버튼을 클릭하면 아래로 펼쳐지는 메뉴’일 수 있습니다. 하지만 요청한 사람이 실제로 원했던 것은 <select>일 수 있다는 것이죠. 이런 소통의 틈을 채우기 위해 우리는 장문의 기획서를 쓰고 시간과 공을 들여 프로토타이핑을 합니다. 시간과 인력 자원이 허락된다면 아주 좋은 과정입니다. 하지만 자원이 적은 스타트업 팀에게는 부담스러울 수 있습니다. 모든 것이 비용이죠. 그저 “‘드롭다운’은 아래로 펼쳐지는 메뉴이고, 옵션 선택을 위해서는 셀렉트(<select>)를 쓰자”고 미리 약속하면 많은 부분이 해결됩니다. 그래서 UI 용어 통일은 중요합니다.이런 것이 헷갈리고, 이렇게 씁니다.몇 가지 사례를 살펴보겠습니다. 서비스를 2년 가까이 만들어 오면서 헷갈렸던 용어와 서로 약속을 통해 바로 잡은 것들, 그리고 아직도 헷갈리는 것들이 섞여 있습니다. 그리고 다른 팀에서 사용하는 의미와 또는 웹표준과 다를 수 있습니다. 그저 “스티비는 이렇게 쓰는구나”하고 봐주시면 되겠습니다.1. 버튼(button)버튼은 생각보다 다양합니다사용자의 클릭을 끌어내는 버튼. 마우스와 키보드를 가지고 할 수 있는 많은 액션이 있지만 무언가를 클릭하는 것만큼 직관적이고 친숙한 UX는 없을 것입니다. 그 중심에 버튼이 있습니다. 어떤 때는 이동을, 어떤 때는 실행이나 취소를 위해 버튼을 클릭합니다.버튼의 개념과 역할은 아주 명확한 것처럼 보이지만 프론트엔드 개발자 입장에서는 때로 ‘링크’와 혼동될 때가 있습니다. 어떤 것은 로 만들어진 링크로 만들어야 하고, 어떤 것은 <button>으로, 또 어떤 때는 <input type=”submit”>처럼 하기도 합니다. 하지만 표현되는 결과물은 마우스를 올리면 색이 변하는 ‘버튼’이죠. 보통 는 페이지의 이동을 나타내고, <button>은 실행이나 취소, <input type=”submit”>은 양식의 전송을 말합니다.스티비에서는 ‘버튼’, ‘링크’, ‘링크 버튼’을 혼용해서 사용합니다. 결과물은 버튼이지만 개발자의 재량에 따라 어떤 방식으로 구현할지 정합니다. 위 용어들에 대한 추가 질문은 따로 하지 않습니다. 그리고 SPA 방식으로 개발된 탓에 실제로 구분이 명확히 되지 않는 경우가 있습니다.* 이렇게 씁니다.→ “개발자가 알아서 한다”2. 팝업(popup)과 모달(modal)pop하고 뜬다고 다 팝업은 아님다음으로 헷갈리는 것이 팝업과 모달입니다. 과거 ‘팝업’은 작은 새로운 윈도우를 띄우는 기능을 말했습니다. 최근 팝업 차단이나 모던 브라우저들의 다중탭 기능 덕분에 많이 사용하지 않는 기능이 되었습니다만 아직도 많이 사용되는 용어입니다. 그리고 모달은 비교적 최근에 등장한 개념으로 화면 위에 레이어를 덮어 마치 새로운 창이 나타나는 것처럼 보여주는 방식입니다.“이 부분은 모달로 해주시고요.”, “다음 페이지는 역시 같은 팝업에서 이동하는 것으로…”. 이처럼 초기에는 위 용어를 혼재하여 사용했습니다. 새로운 윈도우를 띄우는 상황은 없거나 매우 희박하므로 소통에 큰 문제는 없었습니다. 다만 모달은 ‘기존(부모) 페이지와 맥락을 달리하는…”이라는 함의를 가지고 있습니다. 이런 경우는 되도록 ‘모달’이라는 용어로 통일하려고 합니다.* 이렇게 씁니다. → 팝업/모달은 중에 하나를 선택하지는 않지만 열리는 상황과 맥락에 따라 용어를 구분하면 좋다. 구현은 하나의 통일된 템플릿으로 진행한다.3. 얼럿(alert)항상 경고만 하는 건 아닙니다‘얼럿’은 사용자가 무언가 잘못된 길로 갔을 때, “띵”하고 뜨는 그 경고창입니다. 과거에는 브라우저에 내장된 기본 기능을 많이 사용했지만, 디자인과 사용성을 위해 최근에는 디자인이 입혀진 레이어로 구현된 유사 얼럿이나 하단에 위치한 토스트얼럿UI 등 다양한 변형이 사용되고 있습니다. “사용자가 취소하려고 하면 이런 메시지로 경고를 해주세요”라는 요청을 받는다면 개발자는 이것을 단순히 alert()으로 처리할지 상단에 뜨는 예쁜 레이어로 띄웠다가 일정 시간이 지나면 없앨지, 하단에 커다랗게 보여줄지 고민이 됩니다. 앞서 살펴본 모달 형식의 경고도 있으니 혼란은 커집니다.대부분 서비스가 그렇겠지만 스티비는 미리 설계된 얼럿 디자인을 사용합니다. 보통의 경우 당연히 이 UI를 사용하고, 추가 액션이 필요하거나 화면의 가운데 모달 형식으로 보여줘야 할 경우라면 디자인 작업물에 명시합니다. 화면에 붉은 글씨로 보여주는 경우도 있어 이 부분은 대부분 디자인 결과물로 소통합니다.* 이렇게 씁니다.→ 디자이너가 각 상황과 맥락을 파악하며 적당한 경고 방식을 선택, 디자인 작업물에 배치하여 개발팀에 전달합니다. (디자인 결과물은 제플린으로 전달합니다)4. 드롭다운(dropdown)과 셀렉트(select)그 누르면 뭔가 아래로 스르륵 나오는 그거결과부터 말씀드리면 ‘드롭다운’과 ‘셀렉트’는 다른 UI입니다. 하지만 비슷한 역할을 하는 경우가 있어 혼용하여 사용되는 것 같습니다. ‘드롭다운’은 하위 메뉴가 숨겨져 있다가 사용자의 마우스 오버나 클릭에 숨겨진 메뉴를 보여주는 UI입니다. 셀렉트는 <select>태그로 구현되며 사용자에게 내재된 옵션값 중 하나(또는 여러 개)를 받기 위한 양식 UI입니다.예쁜 디자인을 위해 레이어로 구현된 드롭다운처럼 구현한 셀렉트도 있고, 셀렉트인데 옵션의 선택에서 그치는 것이 아니라 선택과 동시에 페이지가 이동된다든지 하는 액션을 가진 경우가 있어 혼란이 생긴 것으로 생각됩니다.* 이렇게 씁니다.→ 초기 기획 단계에서 이 둘은 명확히 구분합니다. 사용자에게 어떤 값의 입력(선택)을 요구하기 위해서는 셀렉트를 사용합니다. 이때 디자인은 변형될 수 있지만, 선택이라는 핵심 기능은 그대로 둡니다.버튼 뒤에 숨겨진 메뉴를 표현하기 위해서는 드롭다운을 사용합니다. 하위 메뉴에서 어떤 액션이 있어야 한다면 드롭다운으로 합니다. 구현은 기획에 맞추어 진행합니다.5. 인풋(input)입력하는 곳인데, 마우스 갖다데면 색 바뀌고요. 입력하는 동안은 다른 색으로…‘인풋’, ‘입력창’, ‘필드’ 등 여러 이름으로 불리웁니다. 사용자에게 텍스트 형식으로 어떤 내용을 입력받기 위한 UI로 보통은 그냥 사각형이고, 여기에 테두리(border)나 옅은 배경(background)를 주어 사용합니다.딱히 헷갈릴 일이 없긴합니다. 하지만 뭔가 용어 통일을 한다면? 아마도 ‘텍스트 입력’이나 ‘텍스트 인풋’이 적당하지 않을까 합니다. 결과물은 입력을 위한 상자이지만 구현은 보통 <input>태그로 합니다. 하지만 단순히 인풋이라고만은 할 수 없는 것이 <input type=”checkbox”>나 <input type=”radio”>, <input type=”submit”> 같은 예외가 있기 때문입니다. “인풋으로 해주세요”, “인풋 중에 뭐요?”같은 상황이 생길 수 있습니다. 그렇다고 ‘텍스트 입력’이라고 한다면 <textarea>와 혼동할 수 있습니다. 구현 과정을 생각하여 되도록 명확한 용어가 사용되는 편이 좋습니다.* 이렇게 씁니다. → 무엇을 입력할지 디테일한 전달 필요. 용어 통일은 조금 더 논의해 본다.마치며쓰임에 따라, 상황에 따라 다를 수 있는 UI 관련 용어들. 각자 편한 대로 쓰면 되지 왜 꼭 통일해야 할까요? 오히려 하나의 단어로 통일하는 순간 그 단어만 제한되는 것은 아닐까요? 개발 조직마다 다르겠지만, 스타트업이나 스타트업처럼 작고 빨라야 하는 조직에서의 팀원 사이의 이런 작은 ‘싱크’들은 매우 중요합니다. 드롭다운을 열심히 그렸는데, 실제로 필요한 건 셀렉트였다면? 이렇게 소통이 어긋났을 때 발생하는 시간과 자원의 낭비가 줄어듭니다. 세세한 UI까지 디자이너가 그리는 시간을 줄일 수 있습니다. 미리 약속된 UI(일종의 스타일 가이드)가 있다면 개발자는 상세 디자인 없이도 기존 것을 재사용하면 되기 때문입니다. UI 용어의 싱크만 잘해도 많은 시간을 절약할 수 있습니다. 그 시간에 더 많은 아이디어를 실험하고 구현해볼 수 있습니다.#슬로워크 #스티비 #UI #디자인 #디자이너 #인사이트
조회수 769

콘텐츠의 유혹

나는 핀다(Finda)의 마케터다. 마케터란 시장과 소비자에 대한 이해를 바탕으로, 상품을 전략적으로 홍보하고 소비를 유도하는 사람을 말한다. 마케터가 상품을 홍보하는 방법은 다양할 수 있다. 하지만 본질적으로 마케터의 역할은 상품을 ‘판매’하는 것에 있다. 하지만 나는 핀다에서 대부분의 시간을 상품 홍보나 광고가  아닌, 콘텐츠를 제작하는 데 사용하고 있다. 글을 쓰고, 예쁜 사진을 찍고, 이미지를 가공하며, 또 SNS에 업로드하기도 한다. 나는 일반적인 마케터처럼 직접 ‘판매’를 하지 않는다. 다만 ‘판매’를 유도할 수 있는 다양한 소통방식을 콘텐츠로 시도하고 있다. 나는 Finda의 콘텐츠 마케터다. 내가 콘텐츠, 정확하게는 콘텐츠 마케팅에 관심을 갖게 된 계기는 약 1년 전, 스페인으로 거슬러 올라간다. 당시 나는 스페인의 발렌시아(Valencia)라는 도시에서 지금처럼 글을 쓰고 있었다. 내 개인 블로그에  그곳의 삶을 이야기하는 건, 스페인 생활의 즐거움 중 하나였다. 해안도시인 발렌시아는 이맘 때 쯤부터 날씨가 서서히 더워져 7~8월에는 40도까지 올라간다. 나는 더위를 피해, 집에서 약 2분 거리에 있었던 카페를 매일같이 찾았다. 다른 카페에 비해 약 0.2유로씩 비싼 편이었음에도 내가 그곳의 단골이 되었던 이유는, 종업원 언니가 커피와 함께 건네주던 짧은 쪽지 때문이었다. 그녀는 모든 손님에게, 티슈에 짧은 인사말을 적어 커피나 맥주와 함께 건네주곤 했다. 그녀의 인사말은 ‘Qué guapa hoy! (오늘 참 멋지다!)’ 와 같은 단순한 것이었지만, 분명히 그녀의 정성이 담긴 감동이 있었다. 늘 사람들로 북적였던 그 곳. (적어도 내가 기억하는 한) 단 한 번도 광고를 한 적이 없었다. 주변의 다른 카페들은 문 앞에 그들이 판매하는 음식과 음료의 이름, 가격 등을 큼지막하게 써 붙였지만, 그저 페인트칠 된 칠판 광고판에, 재미있는 인사말들을 적어둔게 다였다. 소비자들은 음료나 음식에 대한 정보가 아닌, 광고판에 적혀 있는 인사말을 보고 카페 안으로 들어섰고, 그녀가 적어주던 쪽지에 감동받아, 다시 한번 그곳을 찾았다.절대 잊지 못할 Rawffee! ‘Qué guapa hoy! (오늘 참 멋지다!)’그 카페에서 그녀가 팔던 것은 아무것도 없었다. 오로지 콘텐츠로 사람을 유혹할 뿐이었다. 이와 같은 유혹작전(?)은 오늘날 여러 기업들이 택하고 있는 차별화 전략이란 생각이 들었다. 과거, 기업의 차별화 전략은 상품과 서비스의 질을 높이거나 가격을 낮추는 것에 집중되어 있었다. 하지만 기술의 발달로 상품 간의 차별성이 뚜렷하게 드러나기 어려워졌다. 이러한 상황에서 기업들이 찾은 돌파구는 메세지의 차별화 즉, 콘텐츠의 차별화였다.기업들이 차별화하는 콘텐츠란, 단순히 정보성 글이나 사진 등에 국한되지 않는다. 인문학이나 언어학에서 콘텐츠의 정의를 정확하게 내리지 못하는 것처럼, 오늘날의 콘텐츠가 의미하는 것 역시 다양하다. 기업의 상업적 콘텐츠는 글이나 사진, 영상 등을 포함해서 특정한 공간에서만 느껴지는 분위기, 브랜드, 기업의 가치 등을 모두 내포한다. 중요한 것은 사람들을 유혹하는 콘텐츠는 사람들이 본질적으로 원하는 일종의 가치적인 것을 담고 있다는 사실이다. 예를 들어, 카페를 찾는 사람들은 단순히 커피를 원하는 것이 아니라, 편안하고 아늑한 공간에서 음료를 마시며 다른 사람과 소통하기를 원한다. 혼자만의 시간을 보내길 원하는 사람일지라도, 완벽하게 독립되고 배제된 채 고독을 즐기기보다는, 적당한 경계를 유지한 상태에서 다른 사람의 존재를 느끼고 싶어 한다. 발렌시아의 그 종업원 언니가 건네주던 그 쪽지는 정확하게 그 역할을 수행했다. 고객과의 적당한 거리를 유지한 채, 그들과 대화하고 소통하는 역할을 한 것이다. 이렇게 그녀의 쪽지라는 콘텐츠는 소비자들의 감정적 니즈를 만족시켰다.  또 다른 예로, 14년 만에 부활한 종로서적이나 최근 인기를 끌고 있는 독립서점을 꼽아볼 수 있다. 그곳은 기존의 대형서점과는 분명히 다른 가치를 소비자들에게 전달한다. 주제별로 빼곡하게 배열된 책 대신, 큰 책상과 편안한 의자 그리고 커피가 고객들을 반긴다. 꼭 서점 같기도 하고, 카페 같기도 한 그곳은 편안한 공간에서 여유롭게 책을 읽고자 하는 소비자들의 감성적 니즈를 반영시킨 곳이다. 바쁘게 책을 고르고, 구석에 쪼그려 앉아서 책을 훑어보아야만 했던 기존의 서점들과는 다른 콘텐츠로 소비자들을 유혹하고 있는 것이다. “가구를 팔지 말고, 공간을 팔라”고 말했던 한샘의 최양하 회장의 이야기가 크게 와 닿는 시점이다. 결국, 콘텐츠가 담아야 하는 것은 소비자들의 니즈를 만족시키는, ‘업의 본질’인 셈이다.종로서점의 모습독립서점 위트앤시니컬 @한남본질을 담은 좋은 콘텐츠 옆에는 사람이 모이기 마련이다. 좋은 신문과 잡지는 많은 구독자를 가지고 있으며, ‘언론’이라는 본질적 업을 수행하는 뉴스의 시청률이 눈에 띄게 높다. 또한 소비자들의 감성적 니즈를 충족시키는 공간은 늘 사람들로 붐빈다. 결과적으로 중요한 것은, 콘텐츠가 얼마나 ‘업의 본질’을 잘 담았는가, 그리하여 소비자들을 잘 만족시키고 있는가에 대한 것이다. 이런 고민은 마케터로서 내가 해야 하는 일과 연결되었다. Finda는 금융 상품 비교 추천 플랫폼으로, 다양한 금융상품에 대한 데이터베이스를 기반으로 개인에게 맞는 상품들을 한곳에 모아 보여주는 서비스이다. 이러한 기업에서 콘텐츠 마케터로서 내가 해야 하는 일은, Finda의 본질적 업과 고객들의 진정한 니즈를 찾아서, 그것을 콘텐츠로 녹여내는 것이라고 생각했다. 입사 이후, 팀원들과 치열하게 고민하면서 찾은 이 공통점은 ‘금융시장에서 나타나는 정보의 비대칭성 해결’이었다.오늘날, 자산가 및 기업에 집중된 금융시스템으로 인해 많은 소비자는 금융 상품 선택에 어려움을 겪고 있다. 이러한 소비자들이 필요로 하는 것 중, Finda가 해결할 수 있는 것은 접근하기 어려운 금융정보에 대한 제공이었고,  나는 그들이 필요로 하는 콘텐츠를 만들어 금융의 비대칭성을 해결하고자 노력해왔다. 물론 고민의 순간들마다 고객들에게 온전히 전달되지는 못하기도 했다. 일례로 친구의 고민을 실제로 듣고 만들었던 콘텐츠가 고객들에게는 단순한 회사 홍보물로 비춰져, 많은 욕(?)을 먹기도 했다. 이러한 일이 있을 때 마다 내가 과연 올바른 방향으로 콘텐츠를 만들고 있는 것인가에 대해 고민하고 반성했다. 콘텐츠를 쓰는 그 과정의 무게가 너무 무거워, 작성한 콘텐츠를 6~7번 갈아 엎은 적도 많았다. 하트가 많아서 행복했는데……… 또르륵그래도 나는 매일 같이 쓴다.. 의지의 한승아...☆가끔 나를 덮쳐오는 여러 고민과 부담들에도 불구하고, 확실한 것은 나는 콘텐츠를 사랑한다는 것, 그리고 이를 기획하고, 고민하며 고객과 소통하는 모든 과정이 내게는 하나의 즐거움이라는 사실이다. 앞으로도 많은 고민을 바탕으로 콘텐츠를 써갈 예정이다. 이 과정에서 소비자의 니즈와, 업의 본질을 잊지 않기 위해 끊임없이 고민할 것이다. 나의 콘텐츠가 금융이 필요한 사람들을 유혹하는 그런 매력적인 콘텐츠가 되기를 바라며. 이만, 아디오스~!디지털 시대의 아날로그적 인간 Finda의 마케터, 한승아 드림 #핀다 #마케팅 #마케터 #인사이트 #철학 #팀원소개 #조직문화 #콘텐츠 #콘텐츠마케팅
조회수 1196

비트윈의 멀티티어 아키텍처를 위한 프레젠터 이야기

블로그 첫 글에서 비트윈의 시스템 아키텍처에 대해 다룬 적이 있습니다. 시스템 구성의 미래에 대한 계획으로 멀티티어 아키텍처에 대해 언급했었는데, 이는 프로토콜을 단순화시키고 배포 자동화를 가능하게 하기 위해서 클라이언트와 비즈니스 로직을 담당하는 서버 사이에 일종의 게이트웨이를 두는 것이었습니다. 그 외에도 여러 가지 필요성이 생겨 해당 역할을 담당하는 프레젠터라는 것을 만들게 되었고 비트윈의 채팅 시스템에 적용하게 되었습니다. 만드는 과정 중에 여러 기술적인 문제들이 있었고 이를 해결하기 위한 노력을 하였습니다. 이 글에서는 비트윈 시스템에서의 프레젠터에 대해 이야기 하고자 합니다.프레젠터¶프레젠터는 일종의 게이트웨이 입니다. 기존의 시스템에서는 클라이언트들이 ELB를 통해 채팅 서버에 직접 TCP 연결을 하였습니다. 하지만 비트윈 PC버전과 자체 푸시 서버를 만들면서 ELB로는 해결할 수 없는 부족한 점들이 생겼고, ELB의 부족한 점을 채워줄 수 있는 시스템이 필요하게 되었습니다. ELB를 대체하는 역할 외에도 다른 여러 필요했던 기능들을 제공하는 프레젠터를 만들기로 하였습니다.프레젠터는 ELB의 역할을 할 뿐만 아니라 여러 다른 기능들도 제공합니다.프레젠터의 기능¶패킷을 적절한 샤드로 중계¶비트윈에서는 커플 단위로 샤딩하여 같은 커플의 채팅 요청에 대해서는 같은 채팅 서버에서 처리하고 있습니다. Consistent Hash를 통해 커플을 여러 채팅 서버로 샤딩하고 ZooKeeper를 이용하여 이 정보를 여러 채팅 서버 간 공유합니다. 프레젠터 또한 ZooKeeper와 연결을 하여 어떤 채팅 서버가 어떤 커플을 담당하는지에 대한 정보를 알고 있도록 설계되어 있습니다. 따라서 프레젠터는 첫 연결 시 보내는 인증 패킷을 보고 해당 채팅 연결에서 오는 요청들을 어떤 채팅 서버로 보내야 할지 판단할 수 있습니다. 어떤 채팅 서버로 보낼지 판단하는 과정은 처음 한 번만 일어나며, 이후 패킷부터는 자동으로 해당 채팅 서버로 중계합니다.프레젠터의 이런 기능 덕분에 클라이언트는 더 이상 어떤 채팅 서버로 붙어야 하는지 알아내는 과정 없이 아무 프레젠터와 연결만 맺으면 채팅을 할 수 있게 되었습니다. 기존에는 클라이언트들이 여러 채팅 서버 중 어떤 서버에 붙어야 하는지 확인하는 작업을 한 후에 할당된 채팅 서버로 연결 맺어야 했습니다. 그래서 클라이언트가 채팅 서버와 연결을 맺기 위해 다소 복잡한 과정을 거쳐야 했지만, 이제는 클라이언트가 프레젠터의 주소로 연결 요청만 하면 DNS Round Robin 통해 아무 프레젠터와 연결하는 방식으로 프로토콜을 단순화할 수 있었습니다. 덕분에 새로운 채팅 서버를 띄울 때마다 ELB를 Warm-Up 시켜야 했던 기존 시스템의 문제가 없어졌습니다. 그래서 비트윈 개발팀의 오랜 염원이었던 채팅 서버 오토스케일의 가능성도 열렸습니다.많은 수의 연결을 안정적으로 유지¶PC버전과 푸시 서버를 만들면서 기존의 채팅 연결과 다르게 많은 수의 연결이 장시간 동안 유지 되는 경우를 처리할 수 있어야 했습니다. 기존에는 TCP 릴레이를 하도록 설정된 ELB가 연결들을 받아주었습니다. 한 머신당 6만 개 정도의 Outbound TCP 연결을 맺을 수 있는데, ELB도 트래픽에 따라 여러 대의 머신에서 돌아가는 일종의 프로그램이므로 이 제한에 걸린다고 생각할 수 있습니다. 따라서 많은 수의 연결을 맺어놓고 있어야 하는 경우 ELB에 문제가 생길 수 있다고 판단했습니다. (과거 ELB가 연결 개수가 많아지는 경우 스케일아웃이 안되는 버그 때문에 문제가 된 적이 있기도 했습니다) 또한 클라이어트 연결당 내부 연결도 하나씩 생겨야 하면 클라이언트가 연결을 끊거나 맺을 때마다 서버 내부 연결도 매번 끊거나 연결해야 하는 오버헤드가 발생합니다.이를 해결하기 위해 프레젠터에서는 TCP 연결을 Multiplexing하는 프로토콜을 구현하여 적은 수의 내부 연결로 많은 수의 클라이언트 연결을 처리할 수 있도록 하였습니다. 서버 내부에서는 고정된 개수의 몇 개의 연결만 맺어 놓고 이 연결들만으로 수많은 클라이언트 연결을 처리할 수 있습니다. 이처럼 TCP Multiplexing을 하는 것은 Finagle과 같은 다른 RPC 프로젝트에서도 지원하는 기능입니다.TCP Multiplexing 프로토콜을 통해 많은 수의 클라이언트 연결을 소수의 서버 내부 연결로 처리합니다.또한, 프레젠터는 많은 수의 SSL 연결을 처리해야 하므로 암복호화 로직을 실행하는데 퍼포먼스가 매우 중요하게 됩니다. 채팅 서버 한 대를 제거하거나 하는 경우 많은 연결이 한꺼번에 끊어지고 연이어 한꺼번에 연결을 시도하게 되는 경우가 있을 수 있는데, 이 때 대량의 SSL Handshaking을 하게 됩니다. 기존 서버들로 대량의 SSL Handshaking을 빠른 시간안에 처리하기 위해서는 높은 퍼포먼스가 필요합니다. Java로 작성된 프로그램만으로 이런 퍼포먼스 요구사항을 달성하기 어려우므로, 클라이언트와의 연결을 담당하는 부분은 OpenSSL, libevent를 이용한 C++로 코드로 작성하였습니다. 인증 패킷을 파싱하거나 패킷들을 릴레이 하는 등의 로직을 담당하는 부분은 Alfred라는 Netty를 이용하여 만든 인하우스 RPC 라이브러리를 이용해 작성되었습니다. 연결을 담당하는 부분은 TCP 연결을 유지하는 역할과 들어온 패킷들을 Netty로 작성된 모듈로 릴레이 하는 역할만 담당하므로 매우 간단한 형태의 프로그램입니다. 짧은 시간 안에 어럽지 않게 구현할 수 있었습니다.클라이언트의 연결을 받아주는 역할을 하는 부분은 C++, 실제 로직이 필요한 부분은 Java로 작성하였습니다.여러 네트워크 최적화 기술의 지원¶ELB에는 여러 네트워크 최적화 기술들을 아직 제공하지 않는 경우가 있습니다. 대표적으로 HTTP/2 혹은 SPDY, QUIC, TCP Fast Open 등이 있습니다. 특히 모바일 환경에서는 SSL Handshaking 등 부가적인 RTT로 인한 지연을 무시할 수 없으므로 이런 기술들을 이용한 초기 연결 시간 최적화는 서비스 퀄리티에 중요한 부분 중 하나입니다. ELB는 AWS에서 관리하는 서비스이므로 AWS에서 이런 기능들을 ELB에 적용하기 전에는 이용할 수 없지만, 프레젠터는 직접 운영하는 서버이므로 필요한 기능을 바로바로 적용하여 서비스 품질을 높일 수 있습니다. ELB에서 이미 제공하는 최적화 기술인 SSL Session Ticket이나 다른 몇몇 기술은 이미 적용되어 있고 아직 적용하지 않은 기술들도 필요에 따라 차차 적용할 예정입니다.프레젠터의 구현¶C++ 연결 유지 모듈¶프레젠터는 퍼포먼스를 위해 C++로 작성되었습니다. 이는 Pure Java를 이용한 암복호화는 프레젠터에서 원하는 정도의 퍼포먼스를 낼 수 없기 때문입니다. 처음에는 OpenSSL과 libevent를 이용해 작성된 코드를 JNI를 통해 Netty 인터페이스에 붙인 event4j라는 인하우스 라이브러리를 이용하려고 했으나, 코드가 복잡하고 유지보수가 어렵다는 점 때문에 포기하였습니다. 그 후에는 netty-tcnative를 이용해보고자 했으나 테스트 결과 연결당 메모리 사용량이 큰 문제가 있었고, 이를 수정하기에는 시간이 오래 걸릴 것 같아 포기하였습니다. 결국, 페이스북에서 오픈소스로 공개한 C++ 라이브러리인 folly를 활용하여 프레젠터를 작성하게 되었습니다. folly의 네트워크 API들이 OpenSSL과 libevent를 이용해 구현되어 있습니다.릴레이 로직¶프레젠터는 첫 인증 패킷을 파싱하여 릴레이할 채팅 서버를 판단하며, 이후의 패킷부터는 실제 패킷을 까보지 않고 단순 릴레이 하도록 설계하였습니다. 처음의 Netty 파이프라인에는 Alfred 프로토콜을 처리할 수 있는 핸들러들이 설정되어 있어 인증 패킷을 파싱 할 수 있으며 인증 패킷에 있는 정보를 바탕으로 어떤 채팅 서버로 패킷을 릴레이 할지 결정합니다. 그 이후 파이프라인에 있던 핸들러를 모두 제거 한 후, 읽은 byte 스트림을 Multiplexing Protocol 프레임으로 감싸서 그대로 릴레이 하는 매우 간단한 로직을 담당하는 핸들러 하나를 추가합니다. 덕분에 로직 부분의 구현도 매우 간단해질 수 있었으며, 채팅 서버에 API가 추가되거나 변경되어도 프레젠터는 업데이트할 필요가 없다는 운영상 이점도 있었습니다.Multiplexing Protocol¶프레젠터의 Multiplexing Protocol은 Thrift를 이용하여 직접 정의 하였으며, 비트윈 개발팀 내부적으로 사용 중인 RPC 라이브러리인 Alfred에 이 프로토콜을 구현하였습니다. Thrift를 통해 C++과 Java로 컴파일된 소스코드를 각각 프레젠터의 연결 처리 부분과 로직 처리 부분에서 이용하여 통신합니다. 프레젠터에서는 Multiplexing된 TCP 연결들을 Stream이라고 명명하였으며 이는 SPDY나 HTTP/2에서의 호칭 방법과 유사합니다. SPDY나 HTTP/2도 일종의 Multiplexing 기능을 제공하고 있으며, 프레젠터의 Multiplexing Protocol도 SPDY 프레임을 많이 참고하여 작성되었습니다.수 많은 클라이언트와의 TCP연결을 Stream으로 만들어 하나의 내부 TCP연결을 통해 처리합니다.Alfred에서는 Multiplexing 된 TCP 연결을 Netty의 Channel 인터페이스로 추상화하였습니다. Netty에서 TCP 연결 하나는 Channel 하나로 만들어지는데, 실제 Stream도 Channel 인터페이스로 데이터를 읽거나 쓸 수 있도록 하였습니다. 이 추상화 덕분에 비트윈 비즈니스 로직을 담당하는 코드에서는 Stream으로 Multiplexing 된 TCP 연결을 마치 기존의 TCP 연결과 똑같이 Channel을 이용해 사용할 수 있었습니다. 그래서 실제 비즈니스 로직 코드는 전혀 건드리지 않고 프레젠터를 쉽게 붙일 수 있었습니다.로드 밸런싱¶클라이언트는 Route53에서 제공하는 DNS Round Robin 기능을 이용하여 아무 프레젠터에 연결하여 채팅 요청을 날리게 됩니다. 하지만 무조건 동등하게 Round Robin 하게 되면 새로 켜지거나 하여 연결을 거의 맺지 않고 놀고 있는 프레젠터가 있는데도 연결을 많이 맺고 있는 기존 프레젠터에에 연결이 할당되는 문제가 생길 수 있습니다. 충분한 시간이 흐르면 결국에는 연결 개수는 동등하게 되겠지만, 처음부터 놀고 있는 프레젠터에 새로운 연결을 가중치를 주어 할당하면 로드를 분산되는 데 큰 도움이 될 것입니다. 그래서 Route53의 Weighted Routing Policy 기능을 이용하기로 하였습니다. 현재 연결 개수와 CPU 사용량 등을 종합적으로 고려하여 Weight를 결정하고 이를 주기적으로 Route53의 레코드에 업데이트합니다. 이런 방법으로 현재 로드가 많이 걸리는 서버로는 적은 수의 새로운 연결을 맺게 하고 자원이 많이 남는 프레젠터로 더 많은 새로운 연결이 맺어지도록 하고 있습니다.스케일 인/아웃¶AWS에서는 트래픽에 따라 서버 개수를 늘리기도 하고 줄이기도 하는 AutoScaling 이라는 기능이 있습니다. 프레젠터가 스케일 아웃될때에는 프레젠터가 스스로 Route53에 레코드를 추가하는 식으로 새로운 연결을 맺도록 할 수 있습니다. 하지만 스케일 인으로 프레젠터가 제거될 때에는 Route53에서 레코드를 삭제하더라도 함부로 프레젠터 서버를 종료시킬 수 없습니다. 종종 클라이언트의 DNS 캐싱 로직에 문제가 있어, Route53에서 레코드를 삭제되었는데도 불구하고 이를 업데이트하지 못해 기존 프레젠터로 연결을 시도하는 경우가 있을 수 있기 때문입니다. 따라서 프레젠터 클러스터가 스케일 인 될 때에는 기존의 모든 연결이 끊어지고 충분한 시간 동안 새로운 연결이 생기지 않은 경우에만 서버를 종료시켜야 합니다. AutoScaling Group의 LifeCycleHook을 이용하여 위와 같은 조건을 만족 시켰을 때에만 프레젠터 서버를 완전히 종료시키도록 하였습니다.못다 한 이야기¶프레젠터라는 이름이 이상하다고 생각하시는 분들이 있을 것으로 생각합니다. 멀티티어 아키텍처를 이야기할 때 프레젠테이션 티어, 어플리케이션 티어, 데이터베이스 티어로 구분하곤 하는데 이 프레젠테이션 티어에서 나온 이름입니다. 지금은 실제 프레젠터가 하는 역할과 프레젠테이션 티어가 보통 맡게 되는 역할에는 많은 차이가 있지만, 어쩌다 보니 이름은 그대로 가져가게 되었습니다.프레젠터에서 AutoScaling을 하기 위해 LifeCycleHook을 이용합니다. 이때 프레젠터를 위해 LifeCycleHook 이벤트를 처리하는 프로그램을 직접 짠 것이 아니라 비트윈 개발팀이 내부적으로 만든 Kharon이라는 프로그램을 이용하였습니다. Kharon은 인스턴스가 시작되거나 종료될 때 실행할 스크립트를 작성하고 인스턴스의 특정 위치에 놓는 것만으로 LifeCycleHook을 쉽게 이용할 수 있게 하는 프로그램입니다. Kharon 덕분에 비트윈 내 다양한 시스템에서 별다른 추가 개발 없이 LifeCycleHook을 쉽게 활용하고 있습니다. 후에 Kharon에 대해 자세히 다뤄보도록 하겠습니다.정리¶비트윈 개발팀에서는 오랫동안 유지되는 수많은 채팅 서버 연결들을 처리하고 클라이언트와 서버 간 프로토콜을 단순화시키는 등 여러 이점을 얻고자 ELB의 역할을 대신하는 프레젠터를 만들었습니다. 프레젠터를 만드는 과정에서 여러 기술적 문제가 있었습니다. 이를 해결하기 위해 C++로 연결 유지 모듈을 따로 작성하였고 Multiplexing Protocol을 따로 정의하였으며 그 외 여러 가지 기술적인 결정들을 하였습니다. 이런 과정에서 시행착오들이 있었지만 이를 발판 삼아 더 좋은 기술적 결정을 내리기 위해 고민하여 결국 기존 시스템에 쉽게 적용할 수 있고 쉽게 동작하는 프레젠터를 만들어 이용하고 있습니다.저희는 언제나 타다 및 비트윈 서비스를 함께 만들며 기술적인 문제를 함께 풀어나갈 능력있는 개발자를 모시고 있습니다. 언제든 부담없이 jobs@vcnc.co.kr로 이메일을 주시기 바랍니다!

기업문화 엿볼 때, 더팀스

로그인

/