일을 잘 하기 위해서는 탁월한 질문을 할 줄 알아야 한다. 제때에 하는 탁월한 질문은 좋은 답변을 얻는 것을 넘어 내가 한 단계 도약할 기회로 돌아오기도 한다. 독서모임을 할 때도 좋은 질문, 즉 좋은 발제가 나올 때 대화가 한껏 풍성해진다. 독서모임의 만족도는 그 날의 발제문이 정한다. 그와 반대로 바보 같은 질문은 알맹이 없는 대답을 듣게 되는 것은 물론, 상대방에게 하여금 내 이미지를 깎아 먹게 만든다.  새삼스레 질문의 중요성을 체감하게 된 이유가 있다. 요즘 들어 처음이라 부를 일들을 잔뜩 부딪치고 있는 덕에 다른 사람에게 질문하는 상황이 많아졌기 때문이다. 그런데 번번이 질문에 대한 질문이 다시 날라온다거나, 대답을 들어도 문제 해결에 진척이 생기지 않는 경우들이 생겼다. 빠르게 해결하기는커녕 오히려 한 문제에 머무는 시간이 늘어났다. 무언가 잘못하고 있다는 생각이 들었다. 내가 질문을 던지는 과정은 이랬다. 1. 문제가 발생한다. 2. 문제 상황에 대해 검색해보며 이것저것 시도한다. 3. 여러 시도가 실패하면 문제의 해결 방법(How)을 물어본다. 이 과정에서 잘못된 것은 무엇인가? 많은 문제가 포함되어 있겠지만 가장 큰 문제는 질문하기 전에 혼자서 고민해보는 시간이 부족했다는 점이다. 충분한 고민 없이 던지는 질문은 답변을 듣고 문제를 해결할지라도 남는 게 없다. 나중에 비슷한 문제를 맞닥뜨려도 또다시 질문을 해야 하는 상황이 만들어진다.  원래의 나는 문제 해결을 위해 질문을 해본 경험이 별로 없었다. 예전에는 남에게 질문하는 것이 실례라고 생각해서 잘 하지 않았다면, 언젠가부터는 질문을 하기 위해 고민을 정리하는 일이 귀찮아서 하지 않았다. 문제는 여기서부터 시작되었다. 질문 하기 위해 고민을 정리해야 하는 상황이 만들어진다는 건 애초에 문제에 대한 정리가 되어있지 않았다는 것을 의미했다. 정확히 무엇이 문제인지, 예상되는 원인은 무엇인지 등 스스로 문제에 대해 정리가 되지 않으니 질문을 하려면 따로 정리가 필요했다. 결국 좋은 질문을 하려면 혼자 고민하고 정리해보는 시간이 많아야 하고, 정리된 내용 중 상대방이 더 잘 알 것 같은 부분만 추려내어 질문해야 한다. 그러다 보면 자연스레 일을 잘할 수밖에 없게 된다. 잘 돌이켜보면 트레바리에서 일하는 동안 질문 받는 상대방에게 하여금 질문이 썩 좋지 못하니 다르게 물어보라고 유도하는 피드백을 종종 받았다. 인제야 그 필요성을 통감하여 고쳐야겠다고 알아먹었고 주변에 질문을 잘하는 사람들을 유심히 관찰하며 살펴보았다.  1. 대체로 what이나 how보다는 why를 묻는다.why를 물을 때에도 문제의 원인을 묻기 이전에 내가 시도해본 것 중 이해가 되지 않는 포인트를 날카롭게 물어본다. 어쩌다 때려 맞춰 문제를 해결하더라도 왜 해결되었는지를 묻는다. why를 묻는 사람들은 질문하기 전에 이미 이것저것 시도해봤음은 물론이고 다음에 또 비슷한 문제에 시달리지 않고 싶어 한다. 2. 무엇을 알아야 하는지 묻는다.자신이 어느 부분에서 부족하여 이런 문제를 겪고 있는지 궁금해한다. 단순히 문제 해결을 하는 데에서 그치지 않고 이참에 약점을 메꾸려 한다. 문제를 많이 겪은 만큼 성장 하고 싶어 한다. 여태까지 발견한 방법은 이렇게 두 가지다. 앞으로 한참은 더 질문하는 법을 배워야겠지만 당장은 질문을 하기 전에 고민을 많이 하는 것부터 해보자. 그리고서 위의 방법들을 지켜서 질문해보자. 질문하는 일은 참 어렵지만 잘만 한다면 이미 비슷한 고민을 해봤던 다른 사람의 지식을 빠르게 얻을 수 있다. 대표님의 표현을 빌리자면 남의 뇌를 빌려 쓰는 것이다. 남의 뇌를 빌려 쓰면 시행착오로 보내는 시간을 줄일 수 있게 된다. 시행착오에 쓸 시간을 아끼면 내가 잘할 수 있는 일을 많이 할 수 있다. PS.마침 평소 애독하던 김형석 님이 직장 필살기: 질문의 기술이라는 글을 쓰셨다. 나처럼 질문을 잘해서 일을 잘해보고 싶은 직장인들이 읽어보면 도움이 될 글이다. 같이 읽어보면 좋다. 게다가 이렇게 유익한 글을 써주신 김형석 님은 2018년 5월부터 트레바리 클럽장으로 활동하실 예정이다!! (기승전 트레바리 자랑) #트레바리 #개발자 #CTO #스타트업일상 #Why #How #What #인사이트 #경험공유

"대학원에 다니는 20대 후반 남자입니다. 꿈이 있어서 대학원에 왔지만 뭔가 점점 회피성으로 대학원을 온 것 같이 변질되어가는 것 같아서 걱정이에요. 과연 저는 꿈을 가지고 인생을 살아가는 것이 맞는 걸까요? 또래 친구들은 돈도 벌고 주말도 있고 여가생활을 잘 즐기는 것 같은데 저는 매일 똑같이 도서관으로 출퇴근하듯 살고 있어요. 지도교수님한테 논문으로 매일 혼나기만 하고.. 저는 도대체 무얼 위해 살고 있는 걸까요..?"- @tainssensu 님의 사연출처: 영화 '8마일'에미넴 주연의 영화 '8마일'에서 나온 대사다. 많은 사람들이 공감했고 아니 여전히 공감하는 대사다.'꿈'과 '현실'의 사이에서 고민하는 우리들을 대변하는 짤이 아닐까?어릴 적부터 우리는 많은 사람으로부터 질문을 받는다. 너는 커서 뭐가 될 거니? 꿈이 뭐니?그럼 우리는 부모님 또는 사회가 원하는 꿈(직업)을 말하곤 했다."저는 의사요! 저는 가수요! 연기자요!"생각해보면 나도 왜 내가 어릴 적 꿈이 변호사, 외교관이었는지 잘 모르겠다. 그저 학교에서 또는 부모님께서 말씀해주신 좋은 '직업'이라고 들었기 때문은 아니었을까? 하지만 나이가 들고 머리가 커가면서 우리는 현실을 마주한다. 내가 하고 싶던 꿈들이 진짜 나의 꿈이 아닌 걸 알아버려 당황스러울 때가 있는가 하면, 나의 꿈을 이루기 위해선 원하지 않는 현실과 맞서 싸워야 할 때도 생긴다. 정말 내가 원하는 꿈이 맞는 걸까? 누구나 꿈을 꾼다. 작건 크건 누구에게나 '꿈'은 한 번쯤 가져본다. 그렇지만 꿈을 향해 달려가다 보면 나도 모르게 혼란스러울 때가 있다. "이건 정말 내가 원하는 꿈일까?"라는 의문을 갖게 되는 시점도 있다. 아마 꿈이라는 건 어떠한 직업을 의미하는 건 아니었을까? 사회적으로 인정받는 타이틀의 직업이 언젠가 우리들의 꿈이 된 건 아닐까? 요즘 10대들의 꿈은  '유튜버' 또는 '건물주'라고 한다. 그렇게 사회의 트렌드에 맞게 우리들의 꿈도 목표도 변해가는 것 같다. 그런 본인의 꿈에 대해 의문이 생기기 시작했다면, 다시 한번 나를 돌아보고 나를 알아보는 시간을 가져보는 건 어떨까? 나는 어떤 사람이며, 무엇을 할 때 가장 행복하며 즐길 수 있는지를.타인의 시선에서 본 내가 아닌 내가 나를 먼저 이해해보는 시간이 정말 중요하다고 생각한다. 꿈이란, 오직 '직업' 타이틀만은 아니니까. 꿈을 꼭 이뤄야 성공한 걸까?꿈은 이뤄야만 할까? 반드시 내가 설정한 목표를 꼭 이루어야 행복해지는 걸까? 어릴 적 우리들의 꿈은 수십 번, 수백 번이 바뀌곤 했다. 꿈과 목표는 변할 수 있다고 생각한다. 가다 보니, 나의 길이 아닐 수도 있고 환경에 따라 또는 시간에 따라 바뀔 수도 있다. 목표한 무언가에 너무 연연하지 않았으면 좋겠다. 늘 삶은 우리가 원하는 대로, 계획한 대로 흘러가지는 않으니. 또 다른 목표가 생길 수도 있고, 그 길로 본인이 행복하다면 되는 거 아닐까? 우리는 너무 꿈을 거창하게만 생각했던 건 아닐까 라는 생각이 든다. 안녕하세요. @tainssensu 님, 스푼 라디오입니다. 꿈에 관련된 고민을 사연으로 보내주셨는데요. 고민이 많이 되실 거라 생각합니다. 목표가 있어서 대학원에 진학하셨지만 막상 도피성이라고 느껴지신다니 혼란스러울 것 같네요. 저의 개인적인 생각으론, 아마 원래 목표하셨던 것 이외에 다른 관심 또는 목표가 생기신건 아닐까 궁금합니다. 또는 주변 친구들과 비교하다 보니 현실에 만족감이 충족되지 않을 수도 있다고 생각합니다. 무엇보다 저는 그런 시기엔, 저를 먼저 돌아보고 제 스스로를 이해하려는 시간을 가져보는 게 중요하다고 생각합니다. 어쩌면 일시적인 감정일 수도 있으니까요. 현실과 꿈 사이에서 갈등하는 건 굉장히 평범하고 자연스러운 일이니까요. 시간이 조금 걸릴지라도, 혼자만의 시간을 반드시 가져보시길 추천해드립니다. 누구에게나 사연은 있다.당신의 사연, 고민을 함께 나누는 공간 스푼 라디오입니다.사연에 채택되신 스푼 유저분들께 스푼 라디오 공식 굿즈를 선물로 보내드립니다.여러분의 이야기를 듣고 싶습니다. 스푼 라디오에 사연을 보내주세요.사연에 채택되신 분들께 소정의 선물을 보내드립니다.자세한 사항은 [email protected]으로 문의 바랍니다.

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

안녕하세요. 미미박스의 소식을 전달하는 Ava입니다.오늘은 미미박스의 PO(Product Owner)는 어떤 업무를 하고 있는지 소개해드리려고 합니다!아직 당신이 만나지 못한 당신의 아름다움을 미미박스에서 만날 수 있도록, 상상과 협업을 통해 최고의 고객 경험을 만드는 미미박스의 PO(Product owner) !PO는 위에 말씀드렸듯 Product Owner의 약자입니다. Product는 미미박스 커머스 플랫폼, 안드로이드 앱, iOS 앱 등 미미박스가 제공하는 모든 서비스를 말하죠! PO는 미미박스 프로덕트의 오너로써 가장 근본적인 자리에서 '고객 경험'에 대한 고민을 하고 프로덕트를 만들어가고 있습니다. 이러한 업무를 하는 미미박스의 PO가 어떤 마음가짐을 가지고 있는지, 구체적으로 어떻게 일을 하는지 키워드와 함께 소개해드립니다. PO는 크게 두 가지를 계속 생각하는 일입니다.동시에 프로덕트를 매일 같이 살펴보고 버그가 있는지,고객 반응은 어떤지도 세심하게 살펴야 합니다. 즉, 프로덕트에 대한 목표를 설정하고, 회사 내의 협업을 이끌어 최고의 고객 경험을 만드는 프로덕트 살림꾼인 것이죠. 회사 전략에 따른 경영진의 요청, 고객의 소리, 내부 직원들의 피드백, 그리고 PO의 경험과 직관까지한 프로덕트는 수많은 목소리 가운데 있습니다. PO는 프로덕트가 지속적으로 성장할 수 있도록 이런 수많은 니즈의 우선순위를 설정하고 정의할 수 있어야 합니다. 우선순위가 정해졌다면 동료, 혹은 대표를 설득해서 끌고 나갈 수 있는 의지와 깊이가 있어야 합니다.PO는 조직의 협업을 이끄는 역할을 합니다. 크게 기술 조직과 영업조직을 연결하는 역할을 하죠. PO는 영업조직의 데이터, 정보, 전략을 받아 기술 조직에서 설계할 수 있도록 기획하고, 반대로 기술 조직에서 할 수 있는 것들을 파악하고 구현하여 영업조직 운영이 더 빠르게 될 수 있도록 기획합니다. PO는 혼자 아웃풋을 낼 수 있는 직무가 아닙니다. 프로덕트의 성장을 위해 영업, 프로모션, 디자인, 기술 등 다양한 조직과 끊임없이 커뮤니케이션해야 합니다. 우리는 왜 이걸 만들어야 하는지 설득과 토론을 통해서 전문가들이 유기체처럼 움직일 수 있도록 만들어야 하죠.  예를 들면 고객 경험을 개선하기 위해서 UX 디자이너와 커뮤니케이션을 통해 PO의 전략이나 콘셉트에 맞는 디자인을 스스로 고민하고 만들어 낼 수 있게 해야 합니다. 반대로 디자이너에게 미적인 감각을 요구하는 게 아니라 경청을 통해 실무자의 전략에 대한 의견이 얼마나 합리적인 지도 빠르게 이해할 수 있어야 합니다. 즉, 회사에 있는 전문성을 잘 융합해 최고의 고객 경험을 만드는 예술인 것이죠.미미박스의 PO는 파괴적 혁신과 기본적인 고객 경험, 이 두 가지 방향을 동시에 기획해야 합니다. 기본적으로 고객이 예측할만한 탄탄한 프로덕트를 구축할 수 있어야 합니다. 동시에, 기존 커머스와는 다른 파괴적 혁신을 품은 프로덕트를 기획해야 하죠.  이를 위해 기존의 프로덕트에 대해 계속 질문을 던져야 하고 개선, 혹은 혁신을 위한 위한 새로운 생각의 틀을 만들어가야 합니다.  현재 미미박스는 데이터를 통해 추천 경험을 강화할 계획을 가지고 있습니다. 자 여기서부터는 PO의 상상이 시작되는 것이죠PO는 어떤 팀에서 어떤 것을 구현할 수 있는지 파악하고 있어야 합니다. 미미박스의 PO인 Ryan은 풀스텍 개발자의 경력을 가지고 있으며, 타 커머스 업체에서도 일을 했었습니다.또한 프로덕트를 기획해본 경력이 있었죠. 이런 경력으로 테크팀에서 누가 뭘 구현할 수 있을지, 커머스에는 어떤 기능이 필요한지 빠르게 알 수 있습니다.즉, PO 직무를 하기 위해서는 기술적 배경지식(개발, 디자인 등)과웹&모바일 프로덕트 기획해본 경험이 있어야 합니다.두 번째는 커뮤니케이션 스킬입니다. 전략이나 콘셉트, 문제 등 추상적인 것을 정의하고,데이터를 기반으로 실무자들과 커뮤니케이션할 수 있어야 합니다.  마지막은 가장 중요한 건데요. 바로 문제 해결 의지입니다. PO는 스스로 목표와 전략을 설정하고 리드해야 하죠. 다양한 협업관계 속에서 깊이와 의지가 부족하다면 이것도 저것도 아닌 결과물이 나올 수 있어요. 그렇기 때문에 확고한 문제 해결 의지를 가지고 있어야 합니다. 다시 한번 미미박스를 살펴보세요. 당신의 상상을 펼칠 수 있는 부분이 보이나요?미미박스와 함께 게임체인저가 되어보세요!

최근의 서비스/애플리케이션의 개발 흐름은 멀티 플랫폼, 멀티 디바이스 시대로 넘어와 있습니다. 단순히 하나의 브라우저만 지원하면 되었던 이전과는 달리, 최근의 서버 프로그램은 여러 웹 브라우저는 물론이며, 아이폰, 안드로이드 애플리케이션과의 통신에 대응해야 합니다. 그렇기 때문에 매번 서버를 새로 만드는 수고를 들이지 않기 위해선 범용적인 사용성을 보장하는 서버 디자인이 필요합니다.REST 아키텍처는 Hypermedia API의 기본을 충실히 이행하여 만들고자 하는 시스템의 디자인 기준을 명확히 확립하고 범용성을 보장하게 해줍니다. 이번 글에선 현대 서비스 디자인을 RESTful하게 설계하는 기초적인 내용에 대해 정리하려고 합니다.REST란 무엇인가?REST는 Representational state transfer의 약자로, 월드와이드웹과 같은 분산 하이퍼미디어 시스템에서 운영되는 소프트웨어 아키텍처스타일입니다. 2000년에 Roy Fielding에 의해 처음 용어가 사용되었는데, 이 분은 HTTP/1.0, 1.1 스펙 작성에 참여했었고 아파치 HTTP 서버 프로젝트의 공동설립자이기도 합니다.REST는 HTTP/1.1 스펙과 동시에 만들어졌는데, HTTP 프로토콜을 정확히 의도에 맞게 활용하여 디자인하게 유도하고 있기 때문에 디자인 기준이 명확해지며, 의미적인 범용성을 지니므로 중간 계층의 컴포넌트들이 서비스를 최적화하는 데 도움이 됩니다. REST의 기본 원칙을 성실히 지킨 서비스 디자인은 “RESTful 하다.” 라고 흔히 표현합니다.무엇보다 이렇게 잘 디자인된 API는 서비스가 여러 플랫폼을 지원해야 할 때, 혹은 API로서 공개되어야 할 때, 설명을 간결하게 해주며 여러 가지 문제 상황을 지혜롭게 해결하기 때문에 (버전, 포맷/언어 선택과 같은) REST는 최근의 모바일, 웹 서비스 아키텍처로서 아주 중요한 역할을 하고 있습니다.중심 규칙REST에서 가장 중요하며 기본적인 규칙은 아래 두 가지입니다.URI는 정보의 자원을 표현해야 한다.자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)으로 표현한다.1번 사용자에 대해 정보를 받아야 할 때를 예를 들면, 아래와 같은 방법은 좋지 않습니다.GET /users/show/1 이와 같은 URI 방식은 REST를 제대로 적용하지 않은 구 버전의 Rails에서 흔히 볼 수 있는 URL입니다. 이 URI은 자원을 표현해야 하는 URI에 /show/ 같은 불필요한 표현이 들어가 있기 때문에 적절하지 않습니다. 본다는 것은 GET이라는 HTTP Method로 충분히 표현할 수 있기 때문이죠. 최근의 Rails는 아래와 같이 변경되었습니다.GET /users/1 자원은 크게 Collection과 Element로 나누어 표현할 수 있으며, 아래 테이블에 기초한다면 서버 대부분과의 통신 행태를 표현할 수 있습니다.ResourceGETPUTPOSTDELETERESTful Web Service HTTP methodsCollection URI, such as http://example.com/resources/컬렉션에 속한 자원들의 URI나 그 상세사항의 목록을 보여준다.전체 컬렉션은 다른 컬렉션으로 교체한다.해당 컬렉션에 속하는 새로운 자원을 생성한다. 자원의 URI는 시스템에 의해 할당된다.전체 컬렉션을 삭제한다.Element URI, such as http://example.com/resources/item17요청한 컬렉션 내 자원을 반환한다.해당 자원을 수정한다.해당 자원에 귀속되는 새로운 자원을 생성한다.해당 컬렉션내 자원을 삭제한다.이 외에도 PATCH 라는 HTTP Method에도 주목하시기 바랍니다. PUT이 해당 자원의 전체를 교체하는 의미를 지니는 대신, PATCH는 일부를 변경한다는 의미를 지니기 때문에 최근 update 이벤트에서 PUT보다 더 의미적으로 적합하다고 평가받고 있습니다. Rails도 4.0부터 PATCH가 update 이벤트의 기본 Method로 사용될 것이라 예고하고 있습니다.입력 Form은 어떻게 받아오게 하지?위의 예시를 통해 많은 행태를 표현할 수 있습니다만 새로운 아이템을 작성하거나 기존의 아이템을 수정할 때 작성/수정 Form은 어떻게 제공할지에 대한 의문을 초기에 많이 가집니다.정답은 Form 자체도 정보로 취급해야 한다는 것입니다. 서버로부터 “새로운 아이템을 작성하기 위한 Form을 GET한다”고 생각하시면 됩니다. Rails 에선 기본적인 CRUD를 제공할 때 아래와 같은 REST 인터페이스를 구성해줍니다.HTTPVerbPathactionused forGET/photosindexdisplay a list of all photosGET/photos/newnewreturn an HTML form for creating a new photoPOST/photoscreatecreate a new photoGET/photos/:idshowdisplay a specific photoGET/photos/:id/editeditreturn an HTML form for editing a photoPUT/photos/:idupdateupdate a specific photoDELETE/photos/:iddestroydelete a specific photo모바일 환경에 따라 다른 정보를 보여줘야 한다면?접속하는 환경에 따라 다른 정보를 보여줘야 할 때가 있습니다. 가령 모바일 디바이스에서 볼 때 다른 사용자 인터페이스를 제공한다든지 하는 경우인데요. 일부 애플리케이션은 독립적인 모바일 웹서비스를 개발한 후 단지 이를 이동시켜주기만 할 때가 있는데, 이는 어떤 경우에 좋지 못한 사용성을 보여줍니다. 모바일 뷰와 일반 웹페이지 뷰의 URI가 달라서 같은 정보를 공유할 때 각 환경에 적절한 디자인과 인터페이스로 보이지 않기 때문입니다.모바일에서 블로그를 구경하던 도중, 컴퓨터를 이용하고 있는 친구에게 자신이 보고 있는 내용을 보내주고 싶을 때가 있습니다. 티스토리 블로그는 모바일 뷰의 URI가 기존 URI와 달라서, 친구가 해당 URI를 데스크탑에서 열어도 모바일에 최적화된 정보를 받을 수밖에 없게 됩니다. 이 URI를 데스크탑에서 열어보시기 바랍니다.REST 하게 만든다면 URI는 플랫폼 중립적이어야 하며, 정보를 보여줄 때 여러 플랫폼을 구별해야 한다면 Request Header의 User-Agent 값을 참조하는 것이 좋습니다. 예를 들어 iPhone에서 보내주는 User-Agent 값은 아래와 같습니다.Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3 대부분 브라우저, OS 플랫폼은 HTTP Request를 보낼 시 보내는 주체에 대한 설명을 User-Agent에 상세하게 포함하여 통신하고 있기 때문에 요청자의 환경을 정확히 알 수 있습니다.버전과 정보 포맷을 지정할 수 있게 해야 한다면?오픈 API를 제공하거나, 클라이언트가 항상 최신 버전을 유지할 수 없는 환경이라면 서버에서 버전 협상을 지원해야 합니다. 서버가 버전 협상을 지원한다면 최신 버전으로 업데이트가 되더라도 구 버전의 정보 요청에 하위 호환하게 하여 서비스 적용범위를 넓게 유지할 수 있습니다. 이와 함께 클라이언트가 html로 정보를 받을지, json으로 받을지, xml로 받을지 선택할 수 있다면 더욱 좋을 것입니다.Header의 Accept 헤더를 이용해서 요청 환경에서 정보의 버전과 포맷을 지정할 수 있게 합니다. 아래는 Github API에 요청 시 쓰는 Accept 헤더입니다.application/vnd.github+json vnd.는 Vendor MIME Type으로, 서비스 개발자가 자신의 독자적인 포맷을 규정할 수 있게 HTTP 표준에서 제공하는 접두어입니다. vnd. 이후에 서비스 제공자 이름을 쓴 후, +로 문서의 기본 포맷을 표현해줍니다.이에 더해, Accept 헤더는 파라미터를 받을 수 있습니다. 많은 REST 지지자들은 이 파라미터를 이용해 버전 명을 지정하는 것을 권장합니다.vnd.example-com.foo+json; version=1.0 Ajax와 REST최근 빠른 속도의 웹서비스를 구현하기 위해 서비스 전체를 Ajax 통신으로 구동되게끔 HTML5 애플리케이션을 만드는 일이 많습니다. 서비스 전체를 Ajax 기반으로 구동되게 개발한다면 중복된 콘텐츠를 여러 번 전달하지 않아도 되고, 브라우저 렌더링 과정이 간소화되므로 더욱 빠른 서비스를 구축할 수 있습니다. 하지만 Ajax 기반의 서비스는 초기에 URL에 관련된 문제가 있어 REST한 서비스를 만들 때 애로사항이 있었습니다. 콘텐츠가 바뀌어도 URL은 그대로여서 친구에게 내가 보고 있는 콘텐츠를 보여줄 방법이 불편했기 때문이죠.최근엔 두 가지 방법으로 이를 보완할 수 있습니다. 첫 번째는 #! 기법으로, 구형 브라우저에서도 # 이하의 URL을 Javascript로 자유자재로 변경할 수 있다는 점을 이용한 방법입니다. 방법은 아래와 같습니다.Ajax 통신을 통해 이동되는 페이지의 URI는 현재 URI의 #! 이후에 붙인다.페이지가 처음 열릴 때, #! 이후로 URI가 붙어있다면 해당 URI로 redirect를 해준다.이와 같은 방법으로 Ajax 서비스를 만들면, 페이지를 이동한 이후에 URL을 친구에게 복사해서 전달해주어도 친구가 내가 보고 있는 콘텐츠를 볼 수 있으며, 구글에서 수집할 때 해당 #! 이하의 URL을 판별해서 제대로 수집해주기 때문에 검색엔진에도 성공적으로 노출될 수 있습니다.하지만 위 방법의 단점은 1. 상대방이 Javascript를 지원하지 않는 브라우저를 이용하거나 Javascript 기능을 꺼 놓았을 때 제대로 된 콘텐츠를 볼 수 없다는 것이며, 2. URI가 몹시 보기 지저분해진다는 것입니다. 두 번째 방법은 pushState라는 새로운 표준을 이용한 방법으로, javascript의 pushState를 통해 Ajax 통신 후에 변경된 컨텐츠의 URI을 제대로 바꿔줄 수 있습니다. 하지만 최신 표준을 지원하는 브라우저에서만 정상적으로 구동되기 때문에, 하위 호환에 신경을 써야 한다는 단점이 있습니다. pjax같은 프로젝트들이 하위 호환을 포함하여 이런 구현을 쉽게 하도록 도와주고 있습니다.언어언어별로 다른 URI의 서비스를 가지는 서비스들을 종종 볼 수 있습니다. 역시 좋지 못한 설계입니다. 한국어로 작성된 컨텐츠를 보고 있는 중 해당 콘텐츠를 미국인 친구에게 보여줄 일이 생겼다고 가정해봅시다. 단순히 URI를 복사해서 주는 것으로는 미국인 친구에게 내가 보고 있는 정보를 제대로 전달해줄 수 없다면 아주 불편할 것입니다.Request Header의 Accept-Language는 받고자 하는 언어를 명시하고 있습니다. 대부분 브라우저, OS 플랫폼은 사용자가 즐겨 쓰는 언어를 이 Header에 포함하여 요청을 만들고 있기 때문에, 해당 Header를 참조하여 그에 걸맞은 언어를 제공해주는 것이 가장 정확한 서비스를 제공해줄 수 있습니다.물론 이 방법만으로 부족한 점이 있습니다. 자신의 주 언어와 다른 언어의 세팅을 가지고 서비스를 이용하는 사용자도 있으며, 몇 가지 이유 때문에 해당 사이트만, 해당 순간에만 다른 언어로 정해서 보고 싶을 수 있기 때문입니다. 아쉽게도 일반적인 브라우저에서 언어 변경을 하는 인터페이스는 매우 불편하고 찾기 어렵게 되어있기 때문에, 서비스에서 이에 대한 추가 인터페이스를 제공해주지 않으면 일부 사용자를 잃거나 불편하게 할 수 있습니다. 보통은 Accept-Language보다 우선해서 적용하는 언어 옵션을 세션에 저장할 수 있게 하고, 이에 대한 변경 인터페이스를 서비스에서 제공해주는 식으로 문제를 해결할 수 있습니다.마치며REST는 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화해주고, HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해줍니다. 이번 글에서는 REST하지 않은 서버 설계를 통해 생길 수 있는 실질적인 문제들을 제시하고 REST 아키텍처가 이를 어떻게 해결해주는지 함께 보았습니다.‘REST가 완전한 정답이냐?’라고 한다면 이에 대해서는 아직 논의가 남아있습니다. 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 분명히 있으며 (PUT, DELETE를 사용하지 못하는 점, pushState를 지원하지 않는 점) 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값은 왠지 더 어렵게 느껴지기도 합니다.만일, 만들고 있는 서비스의 API가 널리 쓰여야 한다면 REST를 완전하게 적용한 디자인이 더 독이 될 수 있습니다. 많은 개발자는 별로 똑똑하지 못하며, HTTP 프로토콜에 대한 이해가 부족하여서 API가 어렵게 느껴질 수 있기 때문입니다. 그러므로 Google을 포함한 많은 기업의 서비스 API가 REST 스타일을 완전히 따르고 있진 않습니다.하지만 그럼에도 REST가 중요한 점은, 이를 제대로 구현하는 것이 서비스 디자인에 큰 부가이익을 가져다 줄 수 있으며, 많은 현대의 API들이 REST를 어느 정도로 충실하게 반영하느냐를 고민할 뿐이지 REST를 중심으로 디자인되고 있다는 점은 분명하기 때문입니다. REST를 얼마나 반영할 지는 API가 어떤 개발자를 범위에 두는지, 개발 기간이 얼마나 되는지, 함께 하는 동료의 역량은 어떠한지 등을 고려해서 집단마다 다르게 반영하게 될 것입니다.#스포카 #개발 #개발자 #개발팀 #꿀팁 #인사이트 #REST

크래커나인 팀에서는 사용자의 의견을 적극 반영하기 위해서 안드로이드 개발자 박형일님의 크래커나인 사용기 인터뷰를 해보았습니다.개발자 박형일님본인 소개를 부탁 드려요~저는 에이치나인에서 안드로이드 개발 파트를 담당하고 있는 박형일 입니다. 개발 경력은 12년 정도 됐구요.에이치나인에 입사한지는 4년 정도 됐습니다. 주로 외주 안드로이드 앱 개발 업무를 하고 있습니다.개발일을 꽤 오래 하셨네요. 시니어 개발자들은 코드를 직접 작성하는 것을 선호 하시는 것 같던데, 형일님은 어떠신가요?저도 코드를 직접 작성하는 것을 선호 하는 편입니다. 툴에서 생성되는 코드를 별로 신뢰하지 않아요. 제가 원하는 대로 안 나온다는 느낌을 많이 받거든요.그럼 크래커나인의 첫인상은 어떠셨나요? GUI 로 부터 코드를 생성해 주는 툴인데..처음엔 아이디어는 괜찮은데, 이게 과연 제대로 된 코드를 생성 해 줄까? 라는 의심이 들었죠. 꼭 사용 해 보고 싶은 프로그램은 아니었어요.크래커나인을 사용하신지는 얼마나 되셨죠?올해 6월쯤에 처음 접하여 2달 정도 된 같아요.어떤 프로젝트에 적용 해 보셨나요?회사에서 회의실 예약 시스템이 필요하다고 해서 회의실 예약 앱을 만들었어요.그 때 처음 사용 했죠. 공식 프로젝트가 아니라 디자이너 없이 웹에서 무료로 사용할 수 있는 Sketch 파일로 된 디자인 샘플을 받아서 혼자서 만들었어요.앱을 구성하는 화면은 대략 5~6개 정도로 간단한 프로젝트여서 가능 했죠. 지금은 외주 과제를 하고 있는데, 크래커나인을 사용 해서 하고 있어요.외주 같으면 주로 파워포인트로 작성된 GUI 가이드라인 문서를 보고 개발 하잖아요. 크래커나인을 사용하기 전에는 디자이너와 무엇을 통해서 개발에 필요한 디자인 정보를 얻으셨어요? 에이치나인에 있으면서 거의 대부분 GUI 가이드라인 문서를 보고 개발 했죠. 최근에 다른 프로젝트 팀에서 GUI 가이드라인 문서 없이 제플린을 쓰더라구요. 그래서 그것도 조금 써봤어요.제플린과 같은 기존의 유사 서비스와 비교해서 크래커나인은 어땠나요?GUI 가이드라인 문서를 보면서 개발을 하다 제플린을 써보니까 너무 편리하더라구요. 문서에서 원하는 정보 찾는게 불편했거든요.그래서 사실 처음 크래커나인을 사용 했을 때는 제플린과 큰 차이를 못 느꼈어요.근데 프로젝트를 진행 하다 보니 크래커나인의 코드 생성 기능이 있어서 좀 더 편리하다고 느껴지는 순간이 오더라구요. 제플린을 보고 개발 할 때는 코드나 수치를 직접 입력하다 보니 실수를 할 때도 있었고, 여전히 XML 작성하는 수고로움이 남아 있었거든요.근데 크래커나인의 레이아웃 코드 생성 기능을 사용해서 나온 XML 코드가 100% 는 아니지만 70~80%는 작업을 안해도 될 수준이더라구요. 그래서 XML 작성하는데 들이는 시간이 많이 줄어 들었어요.크래커나인을 익히는데 어렵지는 않으셨어요?타 서비스를 사용한 경험이 있어서 많은 부분 기능을 따로 매뉴얼로 보지 않아도 파악이 됐는데요.사용하는데 크게 문제는 없었던 거 같아요. 직관적으로 파악이 안 되는 기능은 사용하지 못한 것 같지만 따로 매뉴얼은 찾아보지 않았습니다.Cracker9의 어떤 기능이 가장 편리하셨나요?당연히 레이아웃 코드 자동 생성 기능이었습니다.손으로 직접 코딩 하지 않고 View들의 관계를 맺으면 자동으로 View의 관계와 속성을 xml 코드로 생성해주는 기능이 개발하는 데에 상당히 많은 도움이 되었습니다.Cracker9을 사용하면서 불편했던 점이나 개선했으면 하는 부분이 있었나요?Asset 이름이나 리소스(문자열, drawable) 이름이 해쉬값이나 text1, text2 이런 식으로 되어 있어 나중에 다 변경을 해 주어야 되었습니다. 이 부분은 개선이 되었으면 좋겠습니다.※ 위의 내용은 Cracker9 0.9.5 에서 개선되었습니다.Cracker9의 정식 버전으로 출시가 되면 사용할 의향이 있으신가요?네, 사용할 것 같아요. 가격만 너무 비싸지 않으면 전 무조건 사용하겠습니다.App을 만들거나 디자이너와 소통해야 하는 다른 개발자들에게 알려주고 싶은 Cracker9 사용 Tip이 있다면 알려주세요~디자이너가 텍스트나 이미지 단위로 View를 만드는데요. 개발자가 원하는 모든 View를 만들진 않기 때문에 Custom Layout 활용은 필수입니다.Custom Layout을 잘 활용하시면 원하시는 레이아웃 작업이 모두 가능합니다. 그리고, 오른쪽에 Tree Structure 패널이 있는데요.View의 트리 구조 순서로 레이아웃 xml 코드가 생성되기 때문에 어떻게 코드가 만들어질지 예상할 수 있어요. 물론 View의 순서나 부모/자식 관계는 마우스 드래그로 편집할 수 있습니다.마지막으로 Constraint Layout의 관계를 맺을 때, View가 작으면 정확하게 클릭하여 작업하기 어려울 수 있는데요. 당연하지만 View를 확대해서 연결 지으면 쉽게 작업할 수 있습니다.마지막으로 Cracker9에게 한 말씀해주세요~저는 안드로이드 App을 개발하면서 레이아웃 작업은 초반에 하는 시간 잡아먹는 노가다 작업이라고 생각을 했는데요.레이아웃을 자동으로 생성해주는 Cracker9을 사용하면서 더 이상 노가다라는 생각을 하지 않게 되었습니다. 아직은 Beta 버전이라 부족한 부분이 보이지만, 개선될 것이라고 믿고 계속 사용할 거 같아요.앞으로 발전하는 모습 기대하겠습니다 파이팅!#에이치나인 #디자이너 #개발자 #협업툴 #크래커나인 #솔루션기업 #팀원인터뷰 #기업문화 #조직문화 #팀원자랑

Phase IV.  서비스가 성숙해 갈 수 록 나에게 쌓이는 자산은 무엇일까?서비스와 상품이 성장해가면서 나에게 Asset을 만들어갈 수 있는 부분은 무엇일까? 회사의 업력이 성장하면서 더 가치가 있어질 수 있는 부분이  무엇일까?라는 질문은 내가 서비스를 기획하면서 항상 하는 질문인데, 서비스가 성공하게 되면 copycat이 등장하는 것은 당연할 것인데 그 상황에서 우리를 지켜줄 것이 이러한 Asset일 것이다.무엇이 있을꼬?라는 생각 중에.. 향수(향)를 설명할 방법이 참 없다라는 생각이 다시 한번 떠올랐다. 향은 직접 맡아보지 않고는 설명이 어렵다... 이것을 visualize 및 객관화할 수 있는 방법을 찾는 것이 우리의 asset을 쌓아가는 길이다.! 우리의 향을 사용한 고객들에게 feedback을 받아보자!Phase IIV. 강력한 브랜드를 어떻게 깰 수 있을까?향수 시장은 강력한 브랜드가 구축되어 있는 시장이다. 브랜드 loyalty가 있는.. 사실 로열티가 있다기보다는 브랜드가 있는 제품 중에 하나를 선택하는 시장에서 브랜드가 아닌 제품이 어떻게 이길 수 있을까? Trendy 함으로 브랜드를 깨어보자!!Phase IIIV. 4개 중에 3개? 4개 중에 2개? 3개 중에 2개?사실 처음 기획에서는.. 고객에게 그 계절에 어울리는 향수 3가지를 보내주는 서비스로 시작되었다. 하지만, 고객이 선택하는 즐거움을 느끼게 해주어야 본인의 판단에 대한 즐거움과 책임을 질 수 있다는 생각을 계속하고 있었기 때문에.. 고객에게 선택폭을 주기 위해.. 본인이 고를 수 있는 option으로 설계하고자 하는데, 어떤 방법이 적합할 것인가? 남자/여자 고객의 입장에서 보자면.. 2/3(셋 중 둘 선택)이라면 그냥 "남자+유니섹스" 조합으로 끝나버리고.. 2/4라고 한다면 유니섹스에서 어떤 것으로 고를까 고민을 살짝 할 테고, 3/4 라면 또 고민의 여지가 사라져버리는 옵션임.. 선택을 넣어줄 것인가? vs. 고민을 넣어줄 것인가?서비스를 고객에게 강요할 수 있겠는가? 특히나 개인의 취향이 매우 강조되고 있는 향수라는 상품에서?일단, Y축의 Perfume family와 X축의 Feminie/Unisex/Masculine의 축에서 향들을  맵핑해본 후에 어떤 것이 고객의 선호도에 더 크게 영향을 미치게 될 것인가를 고민해 보았다. 요즘의 성향으로 보자면 fragrance family가 더 크다는 판단인데 (Floral이 올지 woody가 올지 모르는 상황에서 하나를 받는 것은 뽑기 치고도 너무 큰 뽑기) 그래서 fragrance family를 중심으로 4개의 group을 만들고,  그중에 고객이 2가지를 선택하는 모델로 기획을 변경하였다.2000년 부터 2015년까지 출시된 향수들의 숫자를 카테고라이즈하여 파펨의 카테고리를 결정그리하여 파펨의 네가지 카테고리가 선정되었다. 쿠궁!!Phase 9. Hooked (습관을 만드는 신상품 개발 모델)?향을 안 뿌리는 고객에게 어떻게 해야 향을 뿌리게 만들고.. 뿌리던 고객에게는 더 뿌리게 만들어 볼 수 있을까? 어떤 nudge가 가해져야 이런 것들을 자연스럽게 인지시키고 사용하게 만들 수 있을까? 고객의 하루에서 가장 크게 변하는 것은 무엇일까? 낮 vs. 밤 / 회사 vs. 그 후 약속? 매달 상품을 기획할 때도.. 선택한 두 가지의 향이 저 기준에서 모두 적합할 수 있도록 기획을 해야겠다. 하나는 아침에 뿌리고.. 나머지 하나는 저녁에 퇴근하면서 뿌리세요.. 두 향수는 잘 어울릴 거예요 =)Phase 10. 계속해서 주변의 의견을 구해보다.만나는 분들에게 비즈니스 모델에 대한 의견을 구해본다.. 초반에는 negative가 강세이더니, 요즘은 positive가 강세이다. 본인들의 경험, 그리고 본인들이 가진 specialty를 바탕으로 하나 하나 조언을 해주신다. 모두들 고수인지라 그 하나하나가 굉장히 의미 있는 것들이다. 사람들을 찾아다니면서 만나지 않으면 얻기 불가능한 소중한 조언들이다.그리고 긍정적인 feedback 들을 들을 때마다 힘이 난다. 계속해서 한 걸음씩 전진하는 느낌이 중요하다.#파펨 #스타트업 #창업가 #창업자 #마인드셋 #인사이트

안녕하세요. 와이즈트래커입니다. 최근 많은 기업들이 앱을 만들어 배포하면서, 앱분석에 대한 니즈 또한 높아지고 있습니다.앱분석은 웹분석과 달라서 어렵게 느끼시는 분들이 많으신데요. 그래서 앱분석 전문 솔루션 ‘와이즈트래커’의 특장점을 한눈에 알 수 있도록 ‘Quick Service Guide’를 만들었습니다.모바일 비즈니스에서 성공하기 위해서는 사용자를 잘~모으는 것과 잘~유지하는 것이 가장 중요합니다. (너무 당연한가요?) 하지만 핵심을 파악해야 앱을 앞으로 어떻게 광고해야 할 지, 어떤 방향으로 리뉴얼을 해서 사용자들의 편의성을 높일 수 있을지 방향이 잡힌답니다.■ 와이즈트래커를 사용하면 좋은 점은 무엇인가요?1. 마케팅 성과 분석: 효과적인 마케팅 채널을 찾아드립니다마케터들의 직감에 의존해 광고 비용을 집행하던 시기는 끝났습니다. WISETRACKER는 광고 캠페인/채널/키워드 별 앱 이용자 유입 현황(Install)과 퀄리티 (ROI, LTV, Retention) 등을 비교/분석하여 고객사가 최적의 비용으로 효율적인 마케팅을 집행하도록 돕습니다.2. 사용자, 컨텐츠 분석: 앱 내 충성고객은 누구인지 핵심 컨텐츠는 무엇인지 파악해보세요. 지피지기면 백전백승! 앱 유저들이 어떤 특징을 가지고 있는지, 어떤 콘텐츠를 소비하는지 파악하면 전환율과 앱 유지율(Retention)을 높이도록 전략을 수립할 수 있습니다. WISETRACKER로 데모그래픽, 핵심 컨텐츠, Retention 등 앱 내 사용자, 컨텐츠에 대한 상세한 분석을 제공합니다.3. 성과/커머스 분석: 비즈니스 단계별 맞춤형 성과 분석을 통해 최상의 퍼포먼스를 만들어보세요. 지피지기면 백전백승! 앱 유저들이 어떤 특징을 가지고 있는지, 어떤 콘텐츠를 소비하는지 파악하면 전환율과 앱 유지율(Retention)을 높이도록 전략을 수립할 수 있습니다. WISETRACKER로 데모그래픽, 핵심 컨텐츠, Retention 등 앱 내 사용자, 컨텐츠에 대한 상세한 분석을 제공합니다.4. 푸시메시지 분석 & 오디언스 타겟팅: 개인화된 타겟팅을 통해 푸시메시지 최적화를 진행해보세요.푸시 메시지는 모바일에 특화된 커뮤니케이션 수단이지만 잘못 활용할 경우 부정적인 영향을 끼칠 수도 있습니다.WISETRACKER는 푸시 메시지 응답률과 전환 효과 분석 뿐 아니라, 고객의 데모그래픽/관심사에 따라 추출한 ADID/IDFA로 푸시 메시지 및 광고 최적화를 도와드립니다더 자세한 와이즈트래커 가이드를 보시려면 아래 링크를 클릭! 클릭!와이즈트래커 소개서 보기[서비스 이용 문의]아래의 연락처로 문의주시면 친절하게 상담해드리겠습니다.Tel : 02-6925-6636E-mail : [email protected] * WISETRACKER는 모바일 광고 성과 측정부터 In-app 이용자/컨텐츠 분석, 푸시메시지 최적화까지 지원하는 모바일 통합 분석/타겟팅 솔루션입니다. 와이즈트래커 솔루션의 무료체험을 원하실 경우 여기를 클릭해주세요.* WISETRACKER가 제공하는 무료 데이터 분석 컨설팅를 원하신다면 여기를 클릭해주세요.#와이즈트래커 #서비스소개 #스타트업소개

안녕하세요 대한민국 셀러들의 성공적인 아마존 진출을 도와주는 컨설팅 회사이자 대행사인 컨택틱의 이이삭 대표입니다.아마존에서 후기를 확보 하는 것은 굉장히 중요한 일입니다. 대부분의 고객들은 구매를 한다고 해도 한 개 조차 남기는 경우가 상당히 드뭅니다. 확률상, 100개의 주문 중에서 후기가 1개 생길까 말까 하는 정도입니다. 이 문제를 해결하기 위해서 많은 아마존 셀러들은 사람들은 자동 이메일 발송 프로그램의 도움을 받고 있고, 프로그램을 사용하지 않는 사람들은 구매자 한 명 한 명에게 일일이 이메일을 수동적으로 보내서 후기를 남겨달라고 재촉하기도 합니다. 당연히 수동적으로 이메일을 일일이 보내다 보면 인력적 제한이 생길 수밖에 없고 굉장히 번거롭게 됩니다. 따라서 아마존에서 본격적으로 판매를 하시는 분들은 거의 대부분 자동 이메일 프로그램 세팅을 합니다.하지만 과연 자동 이메일 발송 프로그램이 만능일까요? 과연 이런 프로그램을 세팅한다고 해서 후기가 순식간에 쌓일까요? 과연 그런 이메일을 받는 모든 이들이 후기를 기꺼이 남겨줄까요? 절대 아닙니다. 자동 이메일 발송 프로그램을 세팅하는 아마존 셀러 여러분은 반드시 아래 3가지 포인트를 숙지해야할 것입니다.첫째로, 주문한 고객에게 보내는 첫 번째 이메일 시퀀스(이메일 내용)에는 절대로 후기를 남겨달라는 내용을 언급해서는 안됩니다. 여러분이 만약 고객이라고 생각해보시기 바랍니다. 제품을 받고 만족할 수도 있고, 얼마든지 불만족할 수도 있습니다. 그리고 아직 후기를 남기지 않은거라면 단순히 시간이 없어서 후기를 안남긴 것일 수도 있고, 후기를 남기는 행위 자체가 귀찮아서 안남긴 것일 수도 있습니다. 그런 상황 속에서 판매자가 여러분에게 ‘첫 번째로 보내는 이메일 내용’으로써 “별 5점짜리 후기를 남겨주세요!” 라고 얘기한다면 당연히 반갑지는 않을 것입니다. 뭔가를 바라고 접근한 것처럼 보이는 그런 이메일은 그 누구에게도 환영받지 못하는 이메일이 됩니다. 이메일을 보낼 때에는 정말 고객에게 사심 없이 다가가는 말로 인사하는 것이 올바른 자세입니다.두 번째로, 고객과 인간적인 관계를 형성해야 합니다. 솔직히 놓고 보겠습니다. 당연히 여러분은 고객으로부터 후기를 얻는 게 최종 목표이며, 그런 의도를 가지고 이메일 팔로우업을 하는 것입니다. 하지만, 그 목표를 달성하기 위해서는 먼저 고객과 인간적인 관계를 형성해야 합니다. 고객이 주문한 순간부터, “구매해주셔서 감사합니다!” 그리고 제품이 도착했을 즈음에 “제품 잘 받아보셨나요? 배송 중에 문제 없으셨나요? 제시간에 도착했나요?” 그리고 배송이 완료된 이후 1주일 정도 지났을 시점에 “제품이 만족스러우셨나요? 제가 도와드릴 수 있는 게 있을까요?” 라고 물어보는 것이 순서입니다. 이렇듯이, 갑자기 등장해서 “후기를 주세요!” 라고 하는 게 아니라, 고객이 주문을 넣는 순간에서부터 그 여정이 시작 되는 것입니다.세 번째로, 자동 이메일 발송 프로그램의 진정한 올바른 사용법은 ‘주문을 한 고객들에게 일단 인사하는 용도’로 사용하는 게 맞는 것입니다. 고객이 이메일에 대한 회신을 할지 안할지도 모르는 상황에서 모든 고객에게 각각 인간적인 이메일을 수동적으로 하나하나 쓸 수 없습니다. 그렇기 때문에 위 두 번째 요점에서 언급한 것처럼, 주문 과정에 따라 자동 이메일 템플릿을 만들고, 그 과정 속에서 실제로 회신을 하는 고객들과 진정한 소통을 하는 것입니다. 이 때 진정한 소통이라 함은, 어쩔 수 없이 여러분 또는 여러분의 직원들이 실제로 이메일 하나하나 사람이 직접 이메일 회신을 하는 것을 말합니다. 이메일 회신에 대한 양식 조차도 프로그램의 힘을 빌리면 어쩔 수 없이 인공적인 느낌이 들 수밖에 없기 때문입니다.마지막 보너스를 하나 더 드리겠습니다. 후기를 남기고 안남기고를 떠나서, 지속적인 관계를 유지하기 좋은 방법은, 마치 제가 지금 여러분들을 위해서 이런 좋은 팁을 준비하고 공유하는 것처럼, 여러분 또한 여러분의 상품에 맞는 ‘e-book’ 또는 ‘꿀팁’ 관련 컨텐츠를 자동 이메일 발송 프로그램으로 고객들에게 보내주는 것 또한 좋은 방법입니다. 만약 주방 용품을 판매하는 셀러라면, 고객들에게 ‘요리’에 대한 e-book이나 요리 팁을, 만약 화장품을 판매하는 셀러라면 화장 방법이나 피부 관리 노하우를… 이런 식으로 고객들과 꾸준한 관계를 유지하는 것입니다.인간의 심리상 만족했을 때보다 불만족했을 때 후기를 남기는 경향이 높습니다. 만약 제품 자체에는 불만을 품고 있는 고객이라도, 아직 후기를 남기지 않은 ‘지금’을 잘 활용해서 고객의 소리를 듣고, 고객들을 응대하여, 발생했을 수도 있었을 악성 후기를 미연에 방지하는 것이 매우 중요하다고 볼 수 있습니다. 컨택틱의 모든 교육은 파트너인 글로벌셀러창업연구소와 접수하고 진행합니다. 교육 신청은 아래 링크나 글로벌셀러창업연구소의 홈페이지를 통해 접수 가능합니다.오프라인 아마존 입문 과정오프라인 아마존 기초/심화 과정온라인 아마존 입문 과정그럼 오늘도 즐거운 글로벌 셀링 되세요!감사합니다.컨택틱서울특별시 서초구 서초대로 356, 606호(서초동, 서초지웰타워)대표 전화: 02-538-3939이메일: [email protected]홈페이지: https://www.kontactic.com네이버 블로그: https://blog.naver.com/kontactic카카오 브런치: https://brunch.co.kr/@allaboutamazon유튜브 채널: https://www.youtube.com/c/kontactic

우리는 고객이 무엇에 관심 있어 하고 무엇에 관심 없어하는지, 어떤 것을 보았을 때 클릭해 들어가고 어떤 것을 보았을 때 사이트에서 이탈하는지 궁금해 합니다. 이러한 정보를 얻기 위해 봐야 할 것은 역시 웹서버의 접속 로그입니다.처음에는 매일 생성되는 로그 파일을 일일이 파싱해서 원하는 정보를 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 #로그수정 #인사이트

 일을 그만두고 여러 가지 백수짓을 하느라 굉장히(?) 바빴습니다. 포켓몬고도 열심히 하고 벌건 대낮에 맛집에 가서 맛있는 것도 먹고 낮술도 먹고요. 여러 백수 짓 중에 기억에 남는 짓(?)이 있습니다. 우선 그걸로 이야기를 시작해볼까 해요. 얼마 전에 속마음 버스 라고 카카오와 서울시에서 함께하는 서울시민 힐링 프로젝트를 다녀왔습니다. 대략적으로 설명드리자면요렇게 생긴 버스에서 둘이 앉아 각자의 속마음을 이야기하는 프로그램입니다. 버스라고 해서 그렇게 크지는 않고요. 버스 안에서 둘이 마주 앉아 이야기를 해요. 버스에는 2명씩 2팀이 참석을 하게 됩니다. 자, 이 포스트가 속마음 버스 광고가 아니니 이제 본론으로 넘어가기로 하죠. 죄송합니다. 속마음 버스에 타면 두 가지 규칙을 따라야 합니다.- 3분의 침묵을 지켜주세요!3분 동안 상대방이 이야기를 할 때, 절대 아무런 말도 하지 말고 듣기만 하세요. '응', '아니'와 같은 대꾸도 허락되지 않습니다.- 마음을 표현하세요!상대가 무언가 본인과 다른 생각이나 오해를 했을 때 그 순간 들었던 감정을 잘 기억하고 본인의 차례가 되면 아까 그 이야기를 들을 때 내 마음이 이랬어.라는 말부터 시작해보세요.항상 마음이 먼저 표현되어야 합니다. 제가 이 프로그램을 진행하면서 가장 인상 깊었던 포인트는 바로 '항상 마음이 먼저 표현되어야 합니다'라는 말이었습니다. 속마음 버스를 탔던 친구와 저는 여러 이야기들을 했습니다. 처음에는 시답잖은 이야기로 시작해서 점점 평소에는 이야기하기 껄끄러웠던 서로의 대한 이야기를 하기 시작했죠. 그중에선 물론 그 친구가 생각하는 저의 단점에 대한 이야기도 포함되어 있었습니다. 저는 친구가 이야기하는 저의 단점을 듣고 그 친구가 오해를 하고 있다고 생각해서 논리적으로 반박하려고 했습니다.나는 그 당시에 '이렇게' 생각해서 '그렇게' 행동했던 거야. 너는 오해하고 있어.마음속에선 저런 식으로 이야기를 시작하려고 했지만 속마음 버스의 두 번째 규칙에 따라 감정을 표현하기로 했죠.너의 이야기를 들으니 안타깝다.나는 그럴 의도가 아니었는데 그렇게 전달된 것 같아서 저 말 한마디에 친구의 긴장했던 표정이 순식간에 녹아 사라지는 것이 보였습니다. 평소 같았다면 논쟁으로 이어질 대화가 술술 잘 풀리는 것 같아 기분이 매우 좋았습니다. 이번에는 다른 예를 들어보도록 하겠습니다. "리더는 마지막에 먹는다(Leaders eat last)"로 유명한 사이먼 사이넥의 테드 강연 중에 "나는 왜 이 일을 하는가?"라는 제목의 강연이 있습니다.https://youtu.be/XfsKZ3jm8b8나는 왜 이 일을 하는가?  - 사이먼 사이넥 여기서 사이먼은 이렇게 이야기합니다.이 세상에 존재하는 모든 조직과 사람들은 자신이 ‘무엇을(What)’ 하는지 압니다. 100% 압니다.어떤 이들은 ‘어떻게’ 하는지도 압니다. 차별화, 가치제안, 프로세스 우선순위, 독창적 판매 제안…하지만 ‘왜’ 하는지 아는 개인이나 조직은 극히 드뭅니다. ‘돈(수익)을 벌기 위해서는 ‘왜’가 아닙니다.그건 그저 결과일 뿐이죠. 여기서 ‘왜’란 그 일을 하는 목적, 동기, 신념을 말합니다.당신 조직은 ‘왜’ 존재합니까? 당신은 ‘왜’ 아침마다 침대에서 일어나 하루 종일 무언가에 골몰합니까?애플이 나머지 경쟁사들과 같다면, 그들의 마케팅 메시지는 이럴 겁니다.“우리는 훌륭한 컴퓨터를 만들었습니다. 디자인이 유려하고 사용이 편리하며 사용자 친화적입니다. 한 대 사실래요?”......애플이 실제로 커뮤니케이션하는 방식은 이렇습니다.“우리가 하는 모든 일은 우리가 믿는바, 즉 현실에 도전하기 위함입니다. 우리는 ‘다르게 생각하기’의 가치를 믿습니다. 우리가 현실에 도전하는 방식은 모든 제품을 유려한 디자인, 편리한 사용법, 사용자 친화적으로 만드는 것입니다.그래서 이 훌륭한 컴퓨터가 탄생했습니다. 한 대 사시겠습니까?” 우리에게, 또 우리 앞에 있는 사람에게 더욱 다가오는 말은 What이 아니라 Why라고요. 우리들은 종종 착각하곤 합니다. 우리는 이성적인 인간이기 때문에 이성적으로 생각하고 논리적으로 판단해야 한다. 효율적으로 일만 잘된다면 감정은 배제시켜도 좋다라고요. 기계와 컴퓨터가 발전할수록 점점 우리는 그렇게 생각하도록 강요받고 그렇게 행동하는 게 당연한 것처럼 여겨지고 있습니다.무한도전, 그랬구나 게임중에서... 다른 사람의 마음을 움직이는 가장 효과적인 방법은 사이먼이 얘기했듯이 "너는 이걸(What) 해야 돼" 또는 "너는 이렇게(How) 해야 돼"가 아니라 "네가 왜(Why) 이걸 해야 할까?"입니다. 인간의 동기와 신념에 가장 맞닺아 있는 것은 왜(Why)이고 Why는 감정에 의해서 움직입니다. Why는 당신이 마음속에서 느끼는 것, 믿는 것, 하고 싶은 것을 기반으로 이루어집니다. 따라서 우리는 우리의 감정을 표현함으로써 내가 왜 이 이야기를 하는지 상대방에게 전달해야 하고 상대방의 이성이 아닌 마음을 움직이도록 노력해야 합니다. 구체적으로 다시 한번 이야기하자면,- 상대방에게 나의 생각(What or How)을 말하기"내가 생각하기에 너는 이런 것 같고, 이렇게 했으면 좋겠다"- 상대방에게 나의 감정(Why)을 말하기"나는 네가 이렇게 해서, 내 기분은 이렇다" 이제 우리는 감정이 왜 중요한지 알았습니다. 그런데 감정을 전달하는 일이 왜 이렇게 힘들까요? 연인과 가족을 포함한 다른 사람과 이야기를 할 때, 우리는 대부분 감정이 아닌 자신의 생각을 많이 말하곤 합니다. 자신의 생각을 자주 이야기하는 이유는 우리가 스스로 자신의 감정이 무엇인지 인지하거나 깨닫기 어렵거나 표현하는 게 서툴어서일 수도 있고, 자신의 구체적인 감정을 표현하게 되면 자신의 약한 마음을 드러내는 것이라고 생각해서 일 수도 있습니다. 다른 이유들이 많겠지만 안 그러려고 노력해야겠지요. 소수의 현대인들은 마음속에서 피어오르는 감정을 이성보다 더 낮은 레벨로 생각하고, 감정을 억누르기 이기기 위해서 논리적인 사고방식 또는 대화방식을 선택하곤 합니다. 논리적으로 상대방을 반박한다면 상대방이 그것을 머리로는 수용할 수 있어도 마음으로는 받아들이지 못할 가능성이 큽니다. 설상가상으로 싸움이 일어날 수도 있고 서로가 서로의 인격을 해치는 결과로 이어질 수도 있지요. 우리는 "감정적인 사람"이라는 말을 대부분 부정적으로 표현하거나 인식하곤 합니다. 그러나 요즘 들어 저 같은 경우는 감정을 솔직하게 표현하려고 애쓰는 편입니다. 음식점에서 서비스를 받아 기분이 좋을 때는 "아싸!"하고 입으로 외치기도 하고 가끔은 방방 뛰기도 해요. 나이가 계란 한판인데 너무 경박스러운 거 아니냐며 핀잔을 받을 때도 많지만 솔직한 감정표현을 몸소 실천 중입니다(다음에 이야기하겠지만 여러 상황에서 좋은 결과를 얻었고, 긍정적인 피드백도 몇 번 받았습니다). 반대로 기분이 안 좋을 때는 직설적으로 이야기하는 것도 실험 중에 있습니다. 우리는 이성의 힘에 기대어 스스로 너무나 많은 것을 포기하고 살고 있습니다(좋아하는 일도 사랑도...). 다음 포스팅에서는(언제 돌아올지 모르지만) 이 포스팅과 같은 맥락으로 "당신이 할 수 있는 일이 아니라 하고 싶은 일을 해야 한다"라는 주제로 이야기해보도록 하겠습니다.더 읽어볼 이야기인공지능 시대, '인감지능'을 믿는 이유 - 무인양품(MUJI) 카나이 마사아키 회장 인터뷰[TED] 나는 왜 이 일을 하는가? - 사이먼 사이넥[TED] 리더는 마지막에 먹는다 - 사이먼 사이넥공감능력이 뛰어난 사람들의 5가지 습관 - 고영성내재적 동기 vs 외재적 동기 - 완벽한 공부법, 고영성#비주얼캠프 #인사이트 #경험공유 #조언

오늘은 구글에서 블로그를 검색할 수 있도록 설정하는데에서 크게 삽질했다.. 구글 웹마스터에 사이트맵을 등록해야 했는데 그 사이트맵이 자꾸 테스트를 통과못해서 3시간이나 삽질했다.. ㅠㅠ계속 삽질하다가 찾은 이유는.. _config.yml 파일에 url 속성이 없어서 url을 가져오지 못해 생긴 문제였다. ㅠㅠ 정말 허무하고 신나고.. 아무튼 모든 문제를 해결하여 성공적으로 완료했으니 그 방법에 대해 정리하도록 하겠음.참고한 블로그: 스우의 게임서버와 클라이언트! 미친듯이 영어 검색어들로 오류를 찾으며 삽질했었는데 의외로 한글 블로그에서 이 부분에 대해 언급되어 있어 해결할 수 있었다. 감사합니다 ㅠㅠsitemap 생성하기1. sitemap.xml 파일 생성블로그의 root 디렉토리에 sitemap.xml 파일 생성.2. sitemap.xml 파일 작성하단의 코드를 복사하여 만들어준 sitemap.xml 파일에 붙여넣기.            3. url 설정추가_config.yml 파일에 url 설정이 없는 경우 url 설정을 추가하여 sitemap.xml에서 site.url 변수값을 사용할 수 있도록 해줌. (이 부분 때문에 무한 삽질 ㅠㅠ)4. 구글 웹마스터 툴에서 테스트 혹은 제출구글 웹마스터 툴에서 테스트 혹은 제출을 통해 만들어준 sitemap이 제대로 동작하는지 확인.여태 GA나 기타 여러가지를 설정하느라 공개하지 않았는데 이제서야 공개합니다.제 블로그는 https://heelog.github.io/about/ 입니다!#트레바리 #개발자 #안드로이드 #앱개발 #Jeykll #백엔드 #인사이트 #경험공유