스토리 홈

인터뷰

피드

뉴스

조회수 1624

2017 NDC 리뷰) 크립돈 퓨처 미디어와 하츠네미쿠

 이번글은 덕력이 솟구친다는!!!은 아니고요(진짜 아니에요), 혹시 "하츠네 미쿠"라는 캐릭터를 보신 적 있으신가요?하츠네 미쿠! 설마 처음보는 분들이 계신가요?? 출처: https://ec.crypton.co.jp/pages/prod/vocaloid하츠네 미쿠는 VOCALOID(보컬로이드)로서, 간단히 설명하면, 야마하에서 만든 음성 엔진입니다(자세한 내용은 링크를 확인!). 해당 엔진을 기반(자세히는 VOCALOID2인데... 아, 저는 잘 몰라요 진짜예요...)을 기반으로 크립톤 퓨처 미디어사가 아티스트를 만들고, 이를 지적 재산권(이하 IP라고 하겠습니다)으로 창출해 낸 사례입니다! 해당 세션은 이 보컬로이드가 성공할 수 있게 된, 창작자들에게 프로그램 번들 시디를 팔던, 크립톤 퓨처 미디어사가 새로운 미디어와 아트의 중심에 설 수 있게 된 이유를 들을 수 있게 된 좋은 시간이었습니다. 앞으론 말이 매우 딱딱하니 이점 히해해 주세요~! 시작하겠습니다!씨디파는 회사가 인터넷 시대를 맞이하며 겪게 된 위기, 그리고 해결방안. 앞서 말씀드렸든, 크립톤 퓨처 미디어(이하 크립톤이라고 하겠습니다)는 창작자들을 위한 서비스(또는 프로그램)를 번들 또는 디스크 형식으로 판매하는 회사였습니다. 그리고 새로운 세대로 들어서면서, 해당 사업이 사양되고 있고(디스크 판매> 콘텐츠 다운로드의 변화), 특히 음악 제작 서비스의 경우, 작은 시장의 규모 때문에 비즈니스에 대한 한계를 느끼고, 새로운 사업 영역을 펼쳐나가기 위해 방향 모색하기 시작했다고 합니다. 그리고 크립톤이 생각할 수 있는 "자사가 가장 잘할 수 있는 것"을 생각해 보았을 때, "소리"라는 콘텐츠를 방점으로 서비스를 응용해 나가면서 스팩트럼을 넓히자!라는 생각을 했다고 합니다. 그래서 시작한 것이 바로, 보컬로이드!라는 것이었죠.보컬 합성 기술(보컬로이드) + IP의 도입은 처음부터 성공적이진 않았습니다. 처음 크립톤은 야마하의 보컬로이드 기술을 기반, Leon과 Lola라는 소프트웨어를 제작,  당사에서 유통을 시작했을 때에는, 타깃 유저를 잡는데 실패해 매출에 전혀 도움이 되지 않았다고 합니다(아래 사진을 보면 왠지 알 거 같...)첫 보컬로이드 레온과 로라입니다..... 음... 입술이 매력적 이네요.... 출처: http://vocaloid.wikia.com/wiki/Forever_(Zero-G_song) 그 이유는 해당 서비스를 사용할 것이라고 타게팅한 아티스트들의 경우, 목소리에 관해 리얼함을 추구하는 데, 해당 소프트웨어는 하드웨어로 조정하는 음과 음성들이 리얼함이 다소 떨어져 전혀 니즈가 없었던 것이죠.그래서 트립톤은"해당 서비스를 진짜 사용하는 유저들은 어떤 사람들 일까?"에 대한 고려를 기반으로,"메이코"라는 일본어로 노래하는 보컬로이드를 제작, 흥미를 끌 수 있도록 캐릭터를 모티브로 하는 커버 디자인 작업 시작(안드로이드 아니 보컬로이드 이니깐요!)이제는 버전 쓰리가 된 메이코! (출처:http://vocaloid.wikia.com/wiki/MEIKO) 첫 출시 당시, 거부감도 있었지만, 당시 KPI 목표인 500개를 훌쩍 넘어 3,000개의 판매 성공을 거뒀고, 성공의 요인은 패키징 디자인과 단순한 아티스트뿐만이 아닌, 다양한 콘텐츠에 관심을 가지는 다양한 유저들을 유저들을 이끌 수 있는 요소들이 있어서 라고 판단하였다고 합니다. (서비스를 사용할 것이다 라는 사용자의 경험에 대한 고려를 더 많이 한 포인트라고 생각되는 부분이지요!)메이코 이후 드디어 그분을 만들어 내는 것을 준비합니다.크립톤은 이때부터 정말로 사용자들이 무엇을 원하는가에 대한 생각을 많이 한 것 같다고 보이는 포인트입니다. 메이코의 등장 이후, "하츠네 미쿠"라는 캐릭터 산업으로 만들어 내는 것을 준비합니다. 그리고 해당 캐릭터를 하나의 "사업전략"으로 생각해 낸 이유는 메이코의 KPI달성도 있겠지만, "사람의 목소리와 극히 다른 목소리로 노래를 부르게 된다면, 이상하지 않을까?라는 부분을 오히려 역으로 기획, "인간이 아닌 다른 안드로이드가 하는 노래"라는 새로운 존재로서 IP를 만들어 버린 것이죠!또,  캐릭터를 기반으로 다양한 성격을 가질 수 있도록 "성우"라는 시스템을 집어넣어 "특별한 존재"라는 특징 성을 추가하였고, 기존의 보컬로이드는 "인간의 가수를 대체하는 것"이었으나, 하츠네 미쿠는 "안드로이드 가 부르는 진짜 보컬로이드"라는 접근을 통해 새로운 존재를 만들고, 메이코 디자인을 기반으로, "아이돌 라이즈 된 새로운 사이버 가수"를 만든 것이죠!아아.... 이제 고인이 되신 사이버 가수 아담... (http://beautinaru.tistory.com/196 또한, 해당 콘텐츠를 기반으로 음악을 만들었던 유저들에게 레트로 한 마크들을 집어넣어서 예전에는 이랬었지 라는 향수를 불러일으키고, 해당 콘텐츠를 기반으로 다시 작업을 할 동기를 줄 수 있도록 유저들의 의견을 듣고 반영하는 일들을 굉장히 많이 했다고 합니다!그리고 하츠네 미쿠의 진정한 아이덴티티를 생성합니다. 그것은 바로 Chain of Co-creation!!!하츠네 미쿠가 이렇게 성장할 수 있었던 이유는 저는 하나만 꼽으라 라고 한다면 이쁘잖아요! 가아니라... "확산 가능 여부"에 대한 많은 고려가 있었기에 가능했다고 생각합니다.인터넷 덕분에 음악 등을 만드는 사람들이 쉽게 업로드하고 공유할 수 있는 많은 플랫폼들이 생성되는 현실.덕이 많은 분들이 공유를 통해 자아실현을 하는 공감대를 형성할 수 있는 움직임이 확산.콘텐츠가 콘텐츠를 만들고 퍼져나가는 순기능적인 부분들이 늘어나는 현상들을 확인하고,2차 3차 저작물을 통한 확산> Chain of co-creation의 순선환 적인 기능들이 생겨나는 것이죠!! 그리고 그런 상황을 기반으로, 궁극적으론,모든 사람들이 제작자가 될 수 있는 현실 상황을 받아들이고,제작할 수는 있지만,  저작에 관련한 법률 등에서 막히는 상황을 막기 위해, 창작자들의 창작활동을 돕고, 실제 업로드된 콘텐츠를 기반으로, 실제 사업이 일어날 수 있는 방향으로 전개합니다!그리고 수익화를 통해서 창작자들이 창작활동 = 수익활동이 될 수 있도록 플랫폼 화를 추진한 것이죠!그래서 처음 하츠네 미쿠가 나온 2007년부터 10년이 지난 지금까지도 "보컬로이드"의 선두 주자로 전 세계적으로 콘서트를 다니며 성공적인 투어를 하고 있습니다.투어는 계속된다. (출처: http://mikuexpo.com/) 저는 하츠네 미쿠가 단지 덕후들의 승리라고 요만큼도 생각하지 않습니다.하츠네 미쿠를 성장시킬 수 있었던 건 "우리가 제공하는 서비스가 어떤 유저들에게 더 많은 강점이 있고, 해당 유저들은 어떤 행동을 통해서 자아를 성찰할 수 있을까? 그리고 해당 행동을 통해 유저가 얻는 궁극적인 이익들이 잇을까?"를 생각했던, 크립톤의 유저를 생각하는, 유저의 직접적인 경험을 서비스에 반영하려고 하는 강한 의지가 해당 서비스를 성공시킬 수 있게 한 요인이라고 생각해요. 그런 의미에서 저에겐 정말로 뜻깊고 즐거웠던 세션이었습니다!P.S.: 이제 슬슬 NDC2017 영상들이 올라오기 시작하네요! 관심 있는 분들은 https://ndc.nexon.com/main에서 확인해 보세요~오늘도 긴 글 읽어주셔서 감사합니다! 다소 글이 엉망진창이라도 이해해 주세요! #코인원 #블록체인 #기술기업 #암호화폐 #스타트업인사이트
조회수 1549

8퍼센트 '프로덕트' 팀 인터뷰

안녕하세요, 8퍼센트입니다.8퍼센트는 다양한 매체와 콘텐츠로 이야기를 전하고 있습니다. 이번엔 인터뷰를 통해 8퍼센트를 이루고 있는 각 팀들의 이야기를 들어보며 고객에게 더 가까이 다가가고자 합니다. 그 첫 번째 주인공은 서비스 개발을 담당하는 ‘프로덕트’ 팀입니다.Q. 안녕하세요, 인터뷰를 위해 프로덕트 팀 허재영 님과 이호성 CTO님이 자리해주셨는데요. 먼저, 8퍼센트의 제품을 만드는 프로덕트팀은 구체적으로 어떤 일을 하시나요?A. 프로덕트 팀은 8퍼센트의 서비스를 만드는 팀입니다. 고객들이 8퍼센트를 이용하는 데 있어서 불편함이 없도록 서비스를 개선하고 유지하는 역할을 하고 있습니다. 예를 들어 기존의 인터넷 기반 금융 서비스는 공인인증서, Active X를 보면 알 수 있듯이 사용자의 편리함에 초점을 두고 있지 않습니다. 저희의 역할은 사용자들에게 더 편리하고 효율적인 금융 생활을 할 수 있도록 새로운 금융서비스를 시도하는 것입니다.Q. 새로운 금융시스템을 구축하고 운영해나가는 과정이 쉽지 않을 것 같은데, 그것에 대해 어려움과 극복해낸 경험이 궁금합니다.A. 8퍼센트는 이미 만들어진 솔루션을 사용하거나 외주를 통해 시스템을 구축하는 기존의 회사들과 다르게 직접 바닥부터 금융 시스템을 쌓고 있습니다. 금융시스템은 정확함과 안정성을 빼놓을 수 없는데 사용자가 많아지고 시스템이 거대해질수록 생각지 못한 부분에서 오류가 생기게 됩니다. 이러한 오류는 회사의 손실을 발생시키고, 고객들의 신뢰를 잃게 합니다. 위와 같은 일이 발생하지 않게 시스템을 정밀하게 설계하는 것은 기본이고 추가로 발생하는 문제들에 대해 올바르게 대처하는 것이 금융 시스템을 구축하고 운영하는 과정입니다. 물론 힘든 과정이지만 단계별로 시스템을 구축하는 것이 앞으로 남들과 다른 서비스를 제공할 수 있는 기반이 된다고 생각합니다.서비스 초기, 지급 프로세스에 문제가 있었던 적이 있었는데, 이를 인지하고 그에 대한 대응을 진행했습니다. 또한, 대응에 그치지 않고 테스트와 수정한 부분에 대해 제대로 동작하고 있는지 알아보는 QA(Quality Assurance) 프로세스를 갖추는 계기가 되었습니다. Q. 그렇게 만들어지는 8퍼센트 서비스만의 차별화된 점은 무엇인가요?A. 첫 번째는 '자동 투자'입니다. 자동 투자를 선택하게 되면 예치금과 상환된 투자금이 지속적으로 재투자됩니다. 따라서, 고객이 직접 신경 쓰지 않아도 자산을 쉽게 불릴 수 있습니다. 두 번째는 '스페셜딜'입니다. 일부 스페셜딜은 기업이 제공하는 서비스를 투자자가 직접 체험해볼 수 있으며, 이를 통해 고객은 투자 이외의 부수적인 혜택을 누릴 수 있습니다. 소개해드릴 마지막 차별점은 다양한 업체와의 제휴입니다. 8퍼센트는 현재, 기존 금융권에 있는 많은 금융 회사들과 제휴를 맺고 있습니다. 기존 금융 회사가 오랜 시간 쌓아놓은 시스템과 노하우, 그리고 8퍼센트의 서비스를 합쳐 좋은 서비스를 제공하는 것은 저희 서비스의 강점이 된다고 생각합니다. 또한, 기존 금융권뿐 아니라 토스와 같은 스타트업과의 제휴 역시, 토스 플랫폼에서 간편하게 8퍼센트 서비스를 이용할 수 있다는 점에서 이런 다양한 제휴는 저희만의 차별점이 된다고 생각합니다.Q. 8퍼센트 서비스에는 정말 다양한 장점이 있는 것 같습니다. 이렇게 좋은 서비스를 구상할 때 중요하게 생각하는 기준이 무엇인가요?A. 프로덕트 팀에서는 제품을 구상하는 데 있어서 ‘고객들에게 전달될 수 있는 가치’, ‘안정성과 정확성’, ‘사용성’ 이렇게 세 가지 기준을 중요하게 생각하고 있습니다. 금융 서비스는 대부분 돈으로 환산되는 가치를 추구합니다. 프로덕트 팀이 추구하는 금전적인 가치 역시 투자를 했을 때 돈을 벌고, 대출을 통해 돈을 절약하는 것입니다. 이러한 금전적 가치는 개인과 개인들이 서로 연결되어 발생한다는 점에서 사회적 가치에 기여한다 생각합니다. 또한, 핀테크 서비스들이 나오기 이전에 투자와 대출은 상당히 무겁고 다가가기 힘든 면이 있었습니다. 그래서 프로덕트 팀에서는 투자와 대출로 이뤄진 8퍼센트 서비스를 이용자가 손쉽게 쓸 수 있게 만드는 ‘사용성’이 제품을 구상하는 데 있어서 중요한 기준이 됩니다. 예를 들어, 토스 플랫폼을 통해서 저희 투자 서비스를 이용할 수 있게 하는 것도 ‘사용성’을 높이는 것의 일환입니다.Q. 얘기를 들어보니 명확한 기준을 통해 좋은 서비스가 나오는 것 같습니다. 8퍼센트 투자나 대출 서비스를 직접 이용하시나요? A. 모두가 소액부터 거액까지 다양하게 투자 서비스를 직접 체험하고 있습니다. 이는 고객의 입장에서 생각해볼 기회가 되어 일하는데 좋은 자극이 됩니다. ‘개밥 먹기’라고 개 사료를 만드는 회사에서 실제로 먹어보면서 제품이 어떤지 테스트하는 것에서 유래한 말이 있습니다. 8퍼센트 역시 이런 '개밥 먹기' 테스트를 꾸준히 하고 있습니다. 상품 2.0이 처음 출시되었을 때, 직접 소액 대출을 받아 안내, 혹은 연체 문자가 잘 오는지 등 대출 프로세스를 경험하기 위해서 대출 서비스를 이용했습니다. 물론 회사 내부 관계자에게 대출하기 위해 투자자를 모은다는 것은 윤리적인 문제가 있기 때문에 딜을 내부로만 열어서 회사 분들이 투자한 것만으로 모집했습니다. 신용등급은 당연히 떨어지지 않았고 상환하며 아직 잘 쓰고 있습니다.Q. 현재 P2P 금융 법제화에 대한 논의가 활발히 진행되고 있는데, 과거 새로운 규제가 생겼을 때 대처한 경험이 궁금합니다.A. 지금까지 가장 큰 변화는 작년 5월 가이드라인이 시행되면서 일어났습니다. 그전까지 투자자들로부터 모집한 자금은 회사의 소속으로 되어있었는데, 회사가 부도가 나게 되면 그 돈이 압류되어 투자자들의 돈을 못 빼는 현상이 발생할 수 있었습니다. 가이드라인에서 제시한 부분 중 가장 큰 것이 바로 이에 대한 것입니다. 투자자의 돈을 제삼자가 보관하게 해라 즉, 금융기관이 그 돈을 보관하게 하라는 것인데 이를 위해 농협과 함께 설계부터 시작해 지금의 시스템을 만들었습니다. 농협 측에 자금을 보관하고 저희가 시스템상으로 자금의 흐름을 요청하는 식으로 자금이 직접 저희를 통하지 않고 P2P 거래가 이루어지게 되었습니다.Q. 프로덕트 팀의 대처 능력이라면 법제화 같은 변화에서도 흔들림 없는 서비스를 제공할 수 있을 것 같습니다. 마지막으로 프로덕트팀의 목표는 무엇인가요?A. 프로덕트 팀에서는 항상 ‘우리가 바라는 프로덕트가 무엇일까?’ 고민합니다. 개발자로서 가장 안타까운 것은 열 명의 팀원들이 서로 힘내서 만들어내는 서비스가 사라지는 것입니다. 더 나아가, 사라지지 않는다는 것은 사회적인 가치를 인정받는다는 것입니다. 물론 돈을 만들어낸다는 얘기이기도 하지만 우리가 열심히 만든 자식과도 같은 서비스의 사회적인 가치를 인정받고 지속가능하게 하는 것이 최종적인 목표입니다. 특히 이번 18년도 1분기에 8퍼센트의 단기적 성장과 함께 미래 계획이 구체화 되고 그에 대한 긍정적인 확신이 생겨 큰 동기부여가 되었습니다. 8퍼센트 고객들도 더 편리하고 효율적인 서비스를 만들어갈 저희와 끝까지 동행해주셨으면 좋겠습니다.인터뷰는 8퍼센트의 모든 팀을 소개할 때까지 계속되니 많이 기대해주세요:)> 8퍼센트 서비스 보러 가기 #8퍼센트 #에잇퍼센트 #프로덕트팀 #프로덕트 #인터뷰 #팀원소개 #팀소개
조회수 3323

경험 부족한 스타트업의 devops 도입기 1편

개발과 운영을 함께 devops - 출처당분간의 일기 내용앞으로 몇 개월 간 신생 스타트업 I/O가 어떻게 devops를 자기네만의 스타일로 조직에 안착시켜 나가는지 그 시행착오를 생생하게 공유하는 일기를 쓰려고 합니다.첫 번 째 편인 오늘의 이야기는 두 가지 내용을 다룹니다.devops 도입배경: 어떻게 하다가 devops를 도입하기로 했는지 그 배경에 대에서 이야기 합니다.devops 필요성 인지: 가장 먼저 소프트웨어팀이 devops 필요성을 느끼도록 시도한 스터디 세미나에 관한 이야기를 합니다.devops 도입 도중에 실패할 수 있습니다. 그래서 1편이 마지막 연재일 수 있습니다. 혹은 온갖 개고생을 해가면서 결국 devops를 성공적으로 조직에 안착시켜 tech기업다운 모습을 갖출 수 도 있습니다. 정답은 시간이 얼마간 흐른 뒤에야 알 수 있겠죠? 무언가를 조직에 도입하는 스토리를 사후적으로 그러니까 프로젝트가 끝난 후에 쓰게된다면 프로젝트 과정의 생생함이 퇴색됩니다. 힘들었던 추억도 되돌아보면 미화되듯이 그 당시에 골치아팠던 일들을 그 당시에 써놓지 않으면 까먹을 때가 꽤나 많습니다. 한 편으로는 이렇게 칼자루를 뽑아놔야 반드시 devops를 성공시키기 위해 제가 더 처절해질 수 있을 것 같습니다. 제 나약한 마음이 바뀌지 않기 위해 devops 시작과 동시에 연재물도 함께 시작하겠습니다.devops 도입배경스위처 M 앱이 출시된지 약 한 달 정도 되었습니다.경영을 해오면서 항상 위기의식을 느끼고 있지만 이번에는 조금 심상치 않았습니다.“아.. 라이브서비스를 하기엔 현재 I/O의 소프트웨어 역량이 심각하게 부족하구나! 하드웨어 역량이 Critical Path일 줄 알았는데 되려 소프트웨어가 우리의 발목을 잡고 있구나..”그동안 하드웨어 멤버들은 초심자의 마음과 책임감을 동시에 갖고 무서운 속도로 성장해왔습니다. 새로운 버전의 스위처(M)에 적용된 기구설계 수준, Supply chain 관리 능력, 블루투스 모듈 성능은 이전 버전(W) 비할바가 안됩니다. 놀랄만큼 일취월장 했습니다. 단적인 예로 현재 스위처M의 블루투스 연결 거리는 오픈필드에서 70m이상 나옵니다. 이전 세대인 스위처W의 연결거리가 약 20m 미만임을 감안하면 연결성이 300%이상 좋아졌다고 볼 수 있습니다.반면 소프트웨어팀은 여전히 초보적인 수준을 벗어나지 못하고 있습니다. 전공분야라는 자만심에 소프트웨어를 밑도 끝도 없는 구렁텅이에 밀쳐 넣고있는 제 자신을 발견 했습니다. 창피했습니다. 가장 중요하다고 볼 수 있는 초기고객으로부터 어처구니없는 버그 리포팅을 받을때면 쥐구멍으로라도 숨고 싶었습니다. Customer Service역할까지 도맡아하는 마케터가 수 많은 컴플레인을 대응하느라 정말 고생이 많았습니다.심각한 문제는 소프트웨어팀이 문제의 원인이 무엇인지 조차 잘 모르고 있다는 사실이었습니다. 그저 열심히 다음 피쳐를 개발하기 위해 코드를 짜내는 데에만 자신을 몰아붙이고 있었습니다.그 모습은 한 편의 코메디 영화를 보는 것 같았습니다.<디버깅루프>(1) 배포한 기능에 버그가 처음으로 발견됩니다.(2) “엇 이상한데? 그럴리가 없는데?” 일단 현실을 부정하고 지켜봅니다.(3) 한 두 명의 문제가 아니라는 버그리포팅이 들어옵니다.(4) 부랴부랴 원인을 추측하고 핫픽스 코드를 짜기 시작합니다.(5) 개발을 마치고 일단 배포해 봅니다.(6) 그런데 해결될 줄알 았던 버그가 다시 보고됩니다.그렇게 상황은 2번으로 돌아가 이 디버깅루프를 몇 바퀴 돌고난 후에야 잠잠해집니다.하하… 개판이구나 — 출처:구글 이미지 검색허나 이미 많은 고객들이 불쾌한 UX를 겪고 난 뒤… 이대로는 도저히 구상하는 I/O의 큰 그림에 도달할 수 있을 것 같지 않아, 당분간 제가 CTO역할을 도맡아서 하려고 합니다. 벤 호로위츠가 쓴 Hardthing에서 C-level의 포지션이 비어있을 경우 진짜 적임자가 나타나기 전까지는 그 역할을 CEO가 직접 수행하기를 권장합니다. 이제까지 바쁘다는 핑계로 조직 부채, 기술 부채를 안고왔었는데 최근 Event3 사고를 겪으면서 이젠 이 부채들을 털어내고 나아가야 겠구나 결심하게 되었습니다. 직접 현장으로 다이빙해서 소프트웨어 엔지니어들과 함께 악전고투하기로 했습니다.린스타트업에서 말하는 5-why기법을 적용해보니. 근본적인 원인은 이것이였습니다.주먹구구식으로 Product Live service가 운영(operation)된다.엔지니어들의 코드 퀄리티가 낮아서가 아니었습니다. 알고리즘을 몰라서가 아니었습니다. 디자인 패턴을 몰라서도, 함수형 패러다임을 이해하지 못해서도, 동시성 문제를 몰라서도가 아니었습니다. 되려 I/O의 소프트웨어 엔지니어들의 CS 기본기는 나쁘지 않습니다. 저희는 엉클밥, 켄트백, 마틴파울러를 존경합니다.바보야, 문제는 코딩이 아니야!문제는 경제가 아니야, 바보야!저희 팀의 제일 큰 문제점은 그냥 예전 처럼 새로운 feature 코드를 찍어내는일이 Product Live service operation의 전부라는 사고방식입니다. 배포되는 코드가 얼마나 신뢰할만한지에 대한 고민은 전혀 없고 밀어내기식으로 다음 기능을 추가하는 데만 몰두했습니다. 실상 지금의 스위처에는 새로운 기능을 추가하기위해 코딩을 할때가 아니었는데 말이죠. 쿼리 속도를 높이기 위해 인덱싱을 고민 할 때가 아닌데 말입니다. 정작 Product Live service operation에 필요한 일들(tasks)을 수행하고 있지 않았기 때문에 이 문제가 발생한건데 말이죠.린스타트업의 MVP 관점을 포기하고 완벽한 제품을 내보낸다는 의미가 아닙니다. 그 Minimum Viable Product 조차 제대로 작동이 못시키는 문제를 바로잡기 위해서 입니다. 스크럼으로 조직 tasks를 관리해왔지만 소프트웨어팀은 devops로 거듭나야할 때가 왔음을 느꼈습니다.최소한의 검증 절차도 없이 버그가 담긴 소프트웨어가 고스란히 고객에게 전달되는 악몽을 더 이상 마주해선 안됩니다. 불편함을 겪는 고객을 위해서라도 경쟁력을 잃어가는 조직을 위해서라도 곁에서 힘들어하는 동료들을 위해서라도 소프트웨어팀은 변해야만 했습니다.devops 필요성 인지멤버들에게 제가 방금까지 이야기한 문제점을 전달하고 각자 devops가 무엇인지 공부하기로 했습니다. 일주일간 리서치를 마친 후 한 명씩 돌아가면서 devops가 무엇인지 발표하는 세미나를 진행했습니다. 결론부터 말해 devops 필요성에 대한 공감대 형성은 성공적으로 첫 걸음을 뗀듯 합니다. 모두들 세미나를 준비하면서 그동안 무엇이 문제인지 조차 모르는 상황은 벗어나 보였습니다. 한 명쯤은 “devops는 필요없습니다. 지금처럼 해도돼요!”라는 반응을 예상하기도 했는데, 모두가 겸손의 자세로 지금까지의 문제를 반성하고 변화의 필요성을 절감했습니다. 끊임없이 성장하려는 자세를 가진 I/O 멤버들에게 참 고맙습니다.우린 여기에서 어디쯤..?펌웨어 개발자는 우리의 현재 모습이 위의 그림에서 나오는 원숭이조차 안되는 것 같다고 고백 하기도 했습니다. 그만큼 I/O 소프트웨어팀은 변화를 갈망하는 단계로 무사히 넘어왔습니다. 성공적으로 devops의 필요성 공감대를 형성 시킬 수 있었던 요인은 slow-start 덕분인듯합니다. 초기 고객분들이 실험대상이 된것 처럼 말해 죄송하지만, 작은 규모로라도 Live를 진행하고 거기서 작게나마 사고를 치도록 내버려둔 환경이 devops의 필요성을 받아들이는 데 큰 역할을 했습니다.만약 처음부터 무리해서 스케일업을 시도했다면 그래서 감당할 수 없는 수준의 사고가 동시다발적으로 터졌다면 저희는 자멸하고 말았을 겁니다. 아니, 기다리는 많은 고객들의 기대감에 지레 겁먹고 최대한 소프트웨어 출시 일정을 늦췄겠죠. 그리고 그렇게 절벽에서 등 떠밀리듯이 제품을 출시해서 줄을 잇는 버그 리포팅을 받아보며 평정심을 잃고 말았을 것입니다. 그러나, 감당할 수 있는 수준으로 제품 판매수량을 조절했기 때문에 개발자가 문제를 직시해볼 기회를 가졌고 devops의 필요성은 조직에 쉽게 받아들여질 수 있었습니다.물론 devops 세미나를 진행하면서 안좋은 냄새(징조)를 맡기도 했습니다. 저에게는 행운이죠. 사전에 미리 문제를 파악할 수 있어서. 그 냄새는 도구만능주의 였습니다. devops 도달하기 위해서는 시중에 존재하는 다양한 tool들을 최대한 빠르게 도입해야 할것만 같은 느낌을 말합니다. devops tool들만 제대로 구축한다면 devops도 저절도 실현될것 같은 기대감에 젖습니다. 이 도구만능주의가 만연해지면 devops의 본질은 보지 못한 채 최신 tool 사용에만 집착하게되는 오류를 범하고 맙니다.다행이 I/O의 도구만능주의는 심각한 수준까진 아니고 누구나 초기에 충분히 실수할 수 있는 미약한 수준이었습니다. 사실 제가 예전 스타트업에서 스크럼을 도입할 때도 빠졌던 도구만능주의가 묘하게 겹쳐보여서 낌새를 비교적 빠르게 눈치 챌 수 있었습니다.출처 : 구글 이미지 검색devop는 문화와 운동(movement)입니다. 즉, 무형에 가까운 개념입니다. tool이 아니라 행위(action)와 사상(idea)에 역점을 둬야 합니다. tool은 그저 거들 뿐이죠.간단한 사고실험을 해보겠습니다. 모든 microservices의 설정들을 chef와 puppet으로 관리하고 뱀부나 젠킨스로 빌드-배포-리포팅 파이프라인까지 구축한 devops팀이 있다고 가정해 보겠습니다. 달리 말해, 이 팀은 커맨드 입력 한 번으로 방금 짠 코드를 고객에게 배포할 수 있습니다. 어느날 이 팀에 속한 개발자 A가 지난 일주일간 개발해온 피쳐를 지금 막 마무리 지었습니다. 이어서 A는 devops tool로 구축한 배포 파이프라인 이용해 아주 간단하게 새로운 기능을 업데이트 하기로 했는데요. 과연 괜찮을까요? 최신 devops tool로 중무장 했으니 문제가 없을 것 같습니다. 잠시 후 그렇게 배포된 기능을 써본 고객들이 컴플레인을 걸어옵니다. 잠시 화장실을 다녀온 엔지니어는 허겁지겁 hotfix 코드를 다시 짭니다. 그래도 괜찮습니다. A가 속한 팀은 최신 devops tool이 구축되어 있기 때문에 금방 hotfix를 재배포할 수 있으니까요. 그런데 이장면 어디서 익숙하지 않나요? 앞에서 소개한 디버깅루프와 비슷해 보입니다.출처 : 구글 이미지 검색과연 이게 devops일까요? tool들을 전부 사용하는게 진정 devops의 실현일까요?코드를 리뷰하지도 자동화된 테스트 코드를 실행해보지도 않은 상태에서 지속적 배포는 그저 똥을 더 자주 고객에게 전달하는 것과 다르지 않습니다.높은 품질의 제품은 보장할 수 없습니다. 그렇다면 우리는 무엇부터 해야할까요?Next Iteration저는 장황한 계획을 혐오합니다. 계획을 짜내느라 쏟는 에너지와 시간이 너무 아깝고 무엇보다 계획대로 진행될 확률이 낮기 때문입니다. 대신 저는 스타트업 환경에 맞는 방식으로 일하기를 선호 합니다. 비교적 긴 시간이 필요한 프로젝트 성격의 일을 할 땐 북극성의 위치만을 기억합니다. 쉽게 말해 우리가 산출해야하는 프로젝트 결과물만 생각합니다. 북극성까지 도달하는 정해진 길 따위는 없다고 가정합니다. 혹시 있었다 해도 그냥 잊어버립니다. 스타트업의 리스크는 워낙 변화무쌍하거든요.계획 대신 무던히 아래 두 가지 행동을 반복합니다.(1) 고개를 들어 몸이 북극성 향하도록 합니다.(2) 고개를 숙여 한 발짝 전진합니다.출처 : 구글 이미지 검색프로젝트가 끝날 때 까지 위의 두 가지 과정만을 반복하려고 합니다. 저는 이 과정을 baby step이라고 하는데요. 욕심내지 않고 작게 작게 한 번에 하나씩 차근차근 진행하는 방식입니다. 지금 내 딛은 한 걸음이 틀릴 수도 있습니다. 그러나 괜찮습니다. 한 걸음 나아간 다음에는 반드시 고개를 들어 내가 북극성과 가까워졌나 멀어졌나 확인하면 되거든요. 방향이 맞다는 판단이 서면 한 걸음 더 나아가고 틀린 예감이들면 방향을 조절하면됩니다. 만약 판단이 애매하면 더 끌리는 쪽을 택하면 됩니다. 단, 절대 바닥만을 주시한채 두 걸음 이상 걷지 않습니다.devops까지 도달하는 데 지름길은 전혀모릅니다. 하지만, devops라는 북극성은 저에게 명료하고 분명한 목표입니다. devops에 조금이라도 가까워지기 위해 지금 당장 해야하는 가장 중요한 일이 무엇인지 세미나를 진행하면서 그리고 세미나를 돌아보면서 치열하게 고민했습니다. 그렇게 집중하고나니 당장해야 하는 일 3가지는 다음과 같았습니다.(1)코드리뷰(2)테스트코드 작성(3)이슈 관리 프로세스이 세 가지의 일이 정답이 아닐 수 있습니다. 정답인지 아닌지는 얼마간 시간이 흐른 후에야 알 수 있겠죠? 다만, 저희는 늘 저희가 하던 방식대로 용기를 갖고 baby step을 무던히 수행해 나갈 것입니다. 다음화는 위의 세 가지 일을 진행하면서 겪은 시행착오를 공유해 보도록 하겠습니다.긴 글 읽어 주셔서 고맙습니다.#스위쳐 #Switcher #DevOPS #데브옵스 #개발자 #개발 #개발문화 #디버깅 #버그수정 #인사이트
조회수 1070

Jeykll에서 플러그인 없이 sitemape 생성하기

오늘은 구글에서 블로그를 검색할 수 있도록 설정하는데에서 크게 삽질했다.. 구글 웹마스터에 사이트맵을 등록해야 했는데 그 사이트맵이 자꾸 테스트를 통과못해서 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 #백엔드 #인사이트 #경험공유
조회수 7153

클라우드 서비스 이해하기 IaaS, PaaS, SaaS

클라우드 컴퓨팅은 인터넷으로 가상화 된 IT 리소스를 서비스로 제공하는 것을 의미합니다. 그리고 클라우드 컴퓨팅에서 가상화 하여 서비스로 제공하는 대상은 인프라스트럭쳐, 플랫폼, 소프트웨어입니다. AWS와 Azure가 대중화되면서 클라우드를 인프라스트럭쳐의 가상화 개념으로만 이해하기도 하지만 클라우드는 인프라스트럭쳐 뿐만이 아니라 플랫폼과 소프트까지 포함하는 온라인의 모든 영역을 다루는 꽤 광범위한 개념입니다. 그렇기 때문에 클라우드는 분야별 특성별로 나누어서 이해하는 것이 좋습니다. 클라우드 서비스의 종류는 아래와 같이 크게 3가지로 나눌 수 있습니다. Infrastructure as a Service (IaaS, 아이아스, 이에스)서비스로 제공되는 인프라스트럭처입니다. 개발사에 제공되는 물리적 자원을 가상화합니다. Platform as a Service (PaaS, 파스)서비스로 제공되는 플랫폼입니다. 개발사에 제공되는 플랫폼을 가상화합니다.Software as a Service (SaaS, 사스)서비스로 제공되는 소프트웨어입니다. 고객에게 제공되는 소프트웨어를 가상화합니다.클라우드 구분하여 알아보자IaaS: 서비스로 제공하는 인프라스트럭쳐클라우드 인프라스트럭처 서비스는 확장성이 높고 자동화된 컴퓨팅 리소스를 가상화하여 제공하는 것입니다. IaaS는 컴퓨팅, 네트워킹, 스토리지 및 기타 인프라스트럭쳐를 사용하기 위한 서비스이며 사용자는 필요할 때 마다 서비스를 통해 리소스를 구입할 수 있습니다.(IaaS는 한국에서 이아스 또는 아이아스로 부르며 영미권에서는 이에:스 또는 아이아스로 발음합니다.)PaaS: 서비스로 제공하는 플랫폼클라우드 플랫폼 서비스는 주로 응용 프로그램을 개발 할 때 필요한 플렛폼을 제공하는 것입니다. PaaS는 사용자 정의 응용 프로그램을 개발하고 사용할 수있는 개발자를위한 프레임워크를 제공합니다. 개발사는 미들웨어를 설치하지 않고도 미들웨어에서 제공하는 API를 사용하여 소프트웨어를 개발할 수 있습니다. SaaS : 서비스로 제공하는 소프트웨어클라우드 애플리케이션(소프트웨어) 서비스는 사용자에게 제공되는 소프트웨어를 가상화하여 제공하는 것입니다. SaaS는 타사 공급 업체가 관리하는 사용자에게 응용 프로그램을 제공하기 위해 인터넷을 사용합니다. 대부분의 SaaS 애플리케이션은 웹 브라우저를 통해 직접 실행되므로 클라이언트 측에서 다운로드 나 설치가 필요하지 않습니다.무엇을 제공하는가클라우드는 온라인의 광범위한 영역을 모두 다루는 광범위한 영역입니다. 클라우드 서비스들은 제공하는 범위에 따라 IaaS, PaaS, SaaS로 나뉘고 있으므로 각각의 클라우드 서비스가 제공하는 내역을 살펴보는 것은 클라우드를 이해하는 데 많은 도움이 됩니다.  IaaS: 물리적 자원 제공IaaS는 고객에게 서버, 네트웍, OS, 스토리지를 가상화하여 제공하고 관리합니다. IaaS는 가상화 된 물리적인 자산을 UI형태의 대시보드 또는 API로 제공합니다. IaaS의 고객들은 서버와 스토리지를 접근할 수 있지만 사실상 클라우드에 있는 가상 데이터 센터를 통해 리소스를 전달받는 형태입니다. IaaS는 기존의 데이터센터에서 제공받던 물리적인 자산을 완벽하게 가상화하여 제공하기 때문에 서버 사양의 변경 등 물리적 자산의 수정이 필요한 경우 기존의 방식에 비해 훨씬 빠른 대응이 가능합니다.IaaS의 제공업체는 서버, 하드 드라이브, 네트워킹, 가상화 및 스토리지를 관리하며 고객은 OS, 미들웨어, 애플리케이션 및 데이터와 같은 자원들을 관리해야 합니다. PaaS: 소프트웨어 개발을 돕는 플랫폼 제공PaaS는 고객에게 OS, 미들웨어, 런타임과 같은 소프트웨어 작성을위한 플랫폼을 가상화하여 제공하고 관리합니다. 이 가상화 된 플랫폼은 웹을 통해 제공되며 개발자는 운영 체제, 소프트웨어 업데이트, 저장소 또는 인프라에 대한 관리 없이 소프트웨어 개발에 집중할 수 있습니다.PaaS를 사용하면 기업에서는 특수 소프트웨어 구성 요소를 사용하여 PaaS에 내장 된 응용 프로그램을 설계하고 만들 수 있습니다. 이러한 응용 프로그램 또는 미들웨어는 특정 클라우드 특성을 채택 할 때 확장 가능하고 가용성이 높습니다.SaaS: 고객이 사용하는 소프트웨어 제공SaaS는 고객을 대신하여 소프트웨어와 데이터를 제공하고 관리합니다. 패키지 또는 On-Prems 방식이라고 하는 기존의 소프트웨어 전달 방식과 다르게 SaaS는 개별 컴퓨터에 응용 프로그램을 다운로드하고 설치할 필요가 없습니다. SaaS를 통해 서비스를 공급하는 업체는 데이터, 미들웨어, 서버 및 스토리지와 같은 모든 잠재적 인 기술적 문제를 관리하기 때문에 고객은 유지 보수 및 지원을 간소화 하면서 비지니스에 집중 할 수 있습니다.클라우드의 장점과 단점클라우드 인프라 서비스를 사용할 때의 장점과 클라우드 소프트웨어 서비스를 사용할 때의 장점은 다를 수 밖에 없습니다. 이에 3가지 클라우드 서비스의 장점과 단점을 각각 설명합니다. IaaS: 장점비용물리적 자원을 소비 형태로 사용하기 때문에 고정비가 들지 않습니다.속도물리적 자원을 즉시 소비할 수 있습니다.관리물리적  자원에 대한 관리를 논리적인 영역으로 대체할 수 있습니다.물리적 자원에 대한 자동화 된 배포가 가능합니다.물리적 자원에 대한 안정적인 운영을 벤더에 맞길 수 있습니다.물리적 자원에 대한 규모의 확장 또는 축소가 자유롭습니다.  PaaS: 장점비용필요한 플랫폼만 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다. 속도개발 및 배포 프로세스를 빠르게 확보할 수 있습니다.관리소프트웨어 유지 관리가 쉬워집니다.가상화 기술을 기반으로 구축되어 비즈니스가 변함에 따라 리소스를 쉽게 확장 또는 축소 할 수 있습니다.응용 프로그램의 개발, 테스트 및 배포를 지원하는 다양한 서비스를 제공합니다.수많은 사용자가 동일한 개발 응용 프로그램에 액세스 할 수 있습니다.PaaS: 단점특정 플랫폼 서비스에 종속될 수 있습니다.SaaS: 장점SaaS는 소프트웨어 설치, 관리 및 업그레이드와 같은 지루한 작업에 소요되는 시간과 비용을 크게 줄임으로써 직원과 회사에 많은 이점을 제공합니다. 따라서 기술 직원이 조직 내에서 보다 긴급하고 중요한 문제에 집중할 수 있습니다. 비용소프트웨어를 소비 형태로 사용하기 때문에 비용 부담을 덜 수 있습니다.속도즉시 사용이 가능합니다. 관리소프트웨어를 설치할 물리적 자원이 필요하지 않습니다.언제 어디서든 접근가능합니다.SaaS: 단점커스터마이징이 어렵습니다. 클라우드 언제 적용해야 하는가IaaS: 빠른 변화를 원한다면스타트업이나 중소기업에게 IaaS는 훌륭한 옵션이므로 하드웨어나 소프트웨어를 설치하는데 시간과 돈을 낭비 할 필요가 없습니다. IaaS는 응용 프로그램과 인프라를 완벽하게 제어하고자하는 대규모 조직에 유용하지만 실제로 소비되거나 필요로하는 것을 구매하려는 경우에만 유용합니다. 빠르게 성장하는 기업의 경우, IaaS는 요구 사항이 변화하고 발전함에 따라 특정 하드웨어 나 소프트웨어에 전념 할 필요가 없으므로 좋은 선택이 될 수 있습니다. 또한 필요에 따라 확장 또는 축소 할 수있는 많은 유연성이 있으므로 새로운 응용 프로그램에 어떤 요구가 필요한지 확실하지 않은 경우 도움이됩니다.PaaS: 신속한 개발을 원한다면PaaS를 이용하는 것이 유익하거나 필요한 경우가 많이 있습니다. 동일한 개발 프로젝트를 수행하는 여러 개발자가 있거나 다른 공급 업체도 포함해야하는 경우 PaaS는 전체 프로세스에 뛰어난 속도와 유연성을 제공 할 수 있습니다. PaaS는 사용자 정의 된 응용 프로그램을 만들려는 경우에도 유용합니다. 또한이 클라우드 서비스는 비용을 크게 절감 할 수 있으며 앱을 신속하게 개발하거나 배포하는 경우 발생하는 몇 가지 문제를 단순화 할 수 있습니다.SaaS: 비지니스에 집중하고 싶다면보안상 민감한 사항이 아니라면 모든 기업에게 SaaS는 훌륭한 옵션입니다. 또한 협업이 필요한 단기 프로젝트라면 SaaS 를 도입하는 것이 훨씬 유리합니다. 일반적으로 On-Prems 솔루션은 모바일 액세스를 지원하지 않기 때문에 모바일 액세스가 필요한 경우에도 SaaS를 사용하면 비용가 시간을 절약할 수 있습니다.클라우드 서비스 예클라우드는 적용된 분야별로 이해해야 합니다. 아래는 분야별 서비스 예입니다. IaaSAmazon Web Services (AWS), Microsoft Azure, DigitalOcean, Google Compute Engine (GCE)PaaSAWS Elastic Beanstalk, Windows Azure, Heroku, Google App EngineSaaSGoogle Apps, Dropbox, Salesforce, WhaTap마무리지금도 많은 기업의 임원분들이 클라우드의 적용 여부에 대해 고민을 하고 있으며 많은 스타트업들이 클라우드 기반의 서비스를 만들어 가고 있습니다. 회사에 클라우드를 도입해야 한다면 IaaS를 도입할 지, PaaS를 도입할 지 아니면 SaaS를 도입해야 하는지 알고 있어야 합니다. 그리고 자사의 서비스가 클라우드 기반의 서비스라면 고객에게 왜 도입해야 하는지 쉽게 설명할 수 있어야 합니다. 제가 다니는 와탭랩스(whatap.io)는 국내에서 드물게 SaaS 모니터링 서비스를 제공하고 있습니다. 2015년 1월에 시작한 서비스는 이제 만 4년을 달려가고 있습니다. 앞으로 한국에서 더 많은 클라우드 서비스들이 나왔으면 합니다. #와탭랩스 #개발자 #개발팀 #클라우드서비스 #서비스소개
조회수 2882

웹 플러그인 개발기 - iframe의 재발견

채널 웹 플러그인을 개발하며 겪은 문제들과 우리 팀의 해결책을 소개합니다. 채널 웹 플러그인은 SDK의 형태로 고객사 웹사이트에 붙어서 고객이 매니저와 대화할 수 있는 인터페이스를 제공합니다. 이 글을 쓰고 있는 당시 약 2300개의 채널이 개설되었고, 하루 약 180만 명의 일반 유저가 웹사이트에 붙은 저희 플러그인을 보고 있습니다.플러그인은 고객사 웹사이트 (이하 호스트 웹사이트라고 함) 의 HTML 도큐멘트에 붙어서 실행됩니다. 이 말은 실행 환경 (자바스크립트, CSS, DOM 환경 등) 을 우리가 컨트롤하지 못한다는 것을 의미합니다. 이것이 일반적인 웹서비스와 플러그인 개발의 가장 큰 차이점이고 사실상 많은 이슈들은 이 차이로부터 기인합니다. 또 이것에 대응하기 위해 프레임워크의 선택부터 개발, 배포에 이르기까지 훨씬 신경 써야할 부분이 많았습니다. 이 글에서는 그 중 호스트 웹사이트와의 실행 환경 공유에 따른 문제들을 자바스크립트와 CSS로 나누어 나열하고 iframe 을 이용하여 해결한 과정에 대해 설명하겠습니다.채널 홈페이지에 웹 플러그인이 붙은 모습1. 자바스크립트와 관련된 이슈1-1. 네임스페이스 공유에 따른 충돌 문제브라우저에서 자바스크립트는 글로벌 네임스페이스를 공유합니다. 이 속성 때문에 플러그인에서 window 를 접근해서 수정한다던가 글로벌로 객체를 정의해서 사용하면 호스트 웹사이트에 영향을 미칠 수 있습니다. 이 문제는 코딩할 때 아래 항목을 주의하는 정도로 큰 비용 없이 방지할 수 있습니다.플러그인의 최상위 네임스페이스를 만든다.(ex. window.CHPlugin)플러그인에서 사용하는 모든 객체는 최상위 네임스페이스 아래에 정의되도록 한다.(ex. window.CHPlugin.outObject)window 객체에 접근할 때는 수정하거나 추가하는 부분이 없도록 주의한다.(ex. [removed] = function(){}와 같은 코드는 사용하면 안 됨. 기존에 [removed] 이벤트가 날아감)사용하는 라이브러리들 중에 window에 바인딩하는 것이 없는지 체크하고 있으면 직접 수정하여 모듈화한다. (ex. lodash는 기본적으로 window 에 _ 객체를 생성함)이건 사실 플러그인이 아니더라도 주의해야하는 거죠..1-2. 에러로 인한 오동작 가능성더 어려운 문제는 바로 예측하기 어려운 오동작의 가능성이 있다는 것입니다. 호스트 웹사이트에서 동작하는 자바스크립트에서 에러가 날 경우 플러그인의 동작에도 영향을 미칠 수 있으며, 반대로 플러그인에서 에러가 발생해서 호스트 웹사이트의 코드 실행을 멈출 수 있다는 것입니다. 양방향으로 영향을 미칠 수 있는 것이죠. 특히 후자의 경우는 우리의 실수로 고객사의 서비스에 피해를 끼칠 수 있으니 쉽게 넘길 문제는 아닙니다.아이디어 1: try/catch를 적절히 처리한다?이를 해결하기 위해 가장 쉽게 생각할 수 있는 방법으로는 호스트 웹사이트 쪽에서 try/catch를 적절하게 처리하도록 가이드를 하는 방법입니다. 예를 들어 플러그인 코드의 바깥 쪽에 try/catch처리를 하고 호스트 웹사이트의 자바스크립트에도 적당하게 처리를 하면 되지만 이 방법은 현실적으로 어려움이 있습니다. 우리의 타겟 고객사들은 일반 쇼핑몰들이고 이들은 대부분 개발자가 없거나 쇼핑몰 빌더를 이용해 만들어진 사이트들이기 때문에 개발력이 없는 경우가 많습니다. 또 설사 개발력이 있다 하더라도 플러그인을 붙이기 위해 가이드할 것이 너무 늘어나는 문제가 있죠.아이디어 2: 자바스크립트 실행 순서를 강제한다?생각해볼 수 있는 또 다른 방법은 호스트 웹사이트의 코드와 플러그인 코드의 실행 순서를 명확히 정해서 한 방향의 영향이라도 차단하는 것입니다. 예를 들어 플러그인 코드가 호스트 웹사이트의 코드보다 항상 먼저 실행되도록 고객사에게 가이드한다면 우리의 코드는 항상 문제 없이 실행될 것이고 호스트 웹사이트에서 에러가 발생하더라도 영향을 받지 않을 것입니다. 하지만 이 방법 역시 마음에 들지 않았는데요 양방향의 영향을 모두 차단하지는 못하기 때문입니다. 그리고 더욱 큰 문제는 플러그인은 한 번 실행되고 끝나는 단순한 스크립트가 아니라 계속해서 실행이 되는 애플리케이션이기 때문에 사실상 소용이 없습니다.2. CSS와 관련된 이슈채널 웹 플러그인은 UI도 포함합니다. 플러그인의 DOM이 호스트 웹사이트에 붙어있기 때문에 플러그인의 스타일을 정의하는 CSS도 호스트 웹사이트에 Inject 되어야합니다. 호스트 웹사이트의 CSS와 플러그인의 CSS가 같은 스코프에 존재하기 때문에 우리가 의도한 스타일이 제대로 표현되지 않을 가능성이 있습니다. 실제로 이 문제는 런칭 초기에 우리를 가장 괴롭혔던 문제입니다. 쉽게 생각해볼 수 있는 방법은 아래와 같습니다.플러그인의 CSS에 네임스페이스를 둔다.(플러그인 CSS가 호스트 웹사이트 CSS에 주는 영향을 차단함)CSS 의 우선순위를 이해하고 플러그인 CSS의 우선순위가 항상 높도록 처리한다. (CSS Specificity 링크 참조)하지만 위처럼 처리하더라도 모든 경우에 대해 해결이 되는 것은 아닙니다. 주된 이유는 우리가 개발을 할 때 모든 CSS 속성을 정의하지 않기 때문입니다. 플러그인에서 정의하지 않은 속성을 호스트 웹사이트에서 사용한다면 호스트 웹사이트의 스타일이 적용될 것입니다. 또 특수한 경우이긴 하지만 만약 호스트 웹사이트에 !important 가 적용되어 있다면 그 속성이 덮어씌워지게 됩니다.!important는 사용하지 맙시다..ㅜ아이디어: 스타일 Normalizing?여기에서 의미하는 Normalizing은 모든 DOM 엘리먼트에 가능한 모든 CSS 속성의 기본값을 정의하는 것을 의미합니다. 크로미움을 기준으로 모든 CSS 속성 목록은 이 곳을 참조하시면 됩니다. 이것을 바탕으로 normalize.css를 만들어 적용했습니다.이 방법을 적용한 이후로는 스타일이 오버라이딩되는 문제는 어느 정도 해결되었습니다. 물론 !important에 대한 대응은 여전히 되지 않지만요. 그런데 예상하지 못한 부작용이 발생했는데 첫번째는 디버깅할 때 크롬 인스펙터가 도저히 사용하지 못할 정도로 느리다는 것입니다. 두번째는 CSS가 inheritance 가 안 되고 기본 엘리먼트 셀렉터의 우선순위가 높아서 직접 코딩해야하는 CSS가 2~3배는 길어지는 불편함입니다. 위 두 이유로 개발 피로도가 상당히 높아져서 머지 않아 다른 방법을 알아보게 되었습니다.3. iframe 도입위에 나열한 문제들을 해결할 수 있는 아이디어로 iframe을 리서치하게 되었습니다. 사실 iframe은 최근 웹서비스에서는 잘 사용하지 않기도 하고, 보통은 사용하지 않는 것을 권장하기도 하죠. 따라서 저희 팀에서도 처음에는 고려사항이 아니었는데요 우리와 유사하게 채팅 인터페이스를 제공하는 인터콤에서 iframe 을 적용한 것으로부터 아이디어를 얻어왔습니다.원래 목적에 맞게 사용하지 않으면 독이 됩니다.iframe은 HTML 도큐멘트 안에서 또 다른 도큐멘트를 임베드합니다. iframe 내에 있는 도큐멘트는 호스트 도큐멘트와 자바스크립트 스코프가 분리되어 있고, CSS가 적용되는 스코프 역시 분리되어 있습니다.이런 속성 때문에 위에 나열한 문제들을 원천 차단할 수 있습니다. 자바스크립트 스코프가 분리되어 있기 때문에 글로벌 네임스페이스에 접근해도 호스트 웹사이트에는 전혀 영향이 없고, 자바스크립트의 에러로 인해 다른 쪽 자바스크립트까지 실행을 멈추는 오동작을 막을 수 있습니다. CSS 역시 Normalizing 을 하지 않더라도 호스트 웹사이트와 플러그인은 완벽히 분리가 됩니다.4. iframe 의 단점iframe을 도입하여 1, 2번에 나열한 문제들은 해결했지만 그에 따른 작은 문제들도 발생했습니다. 첫번째는 iframe도입 시 가장 먼저 고민해야할 부분인데 바로 3rd-party cookie 문제입니다. iframe 안에서 로드되는 도큐멘트는 3rd-party 컨텐츠로 인식합니다. IE에서는 기본 설정이 3rd-party cookie 허용을 하지 않기 때문에 쿠키를 사용해서 인증을 구현한 경우 문제가 될 수 있습니다.두번째는 도큐멘트가 분리됨에 따라 발생하는 코딩상의 여러 불편함들입니다. 여기에서는 범위를 벗어나 더 자세하게는 설명하지 않겠지만 도큐멘트가 분리되니 조금 더 신경써야할 것들이 있었습니다.저희 팀의 경우 쿠키 인증 방식이 아닌 토큰 형태의 인증도 지원을 하고 있었기 때문에 첫번째는 크게 문제되지 않았고 두번째 문제도 얻는 이득에 비하면 불편함을 감수하는 편이 훨씬 좋다는 판단이 들어서 도입을 결정했습니다.마무리플러그인 개발을 시작할 당시에 우리 팀은 웹 SDK 형태의 프로젝트 개발 경험이 없었습니다. 리서치를 해도 플러그인 개발과 관련된 아티클이나 리소스 그리고 보일러플레이트 프로젝트도 많지 않았습니다. 프레임워크, 아키텍쳐를 선택하는 것부터 프로젝트를 구성하는 것부터 개발, 배포 및 운영에 이르기까지 일반적인 웹서비스를 개발할 때와 조금 다른 고민들을 해왔던 것 같습니다. 앞으로 저희가 해 온 고민을 공유하려고 합니다. 저희와 같은 플러그인, SDK 형태의 제품을 개발하고 계신 분들에게 도움이 되었으면 좋겠습니다.#조이코퍼레이션 #개발자 #개발팀 #인사이트 #경험공유 #일지
조회수 2154

왜 차세대 SaaS는 페이스북처럼 될 것인가.  

사람들이 매일 사용하는 서비스 중 가장 유용한 것은 무엇일까?대부분의 경우에 있어, 그것은 Slack, Gmail 혹은 Excel 같은 SaaS 툴이 아닐 것이다. 그것은 바로 페이스북이다.페이스북으로 할 수 있는 모든 것들에 대해 생각해보자.친구들에게 메시지 보내기 영상 통화 하기 뉴스 보기 이벤트 기획하기 사진과 동영상 공유하기사람들은 페이스북에 얼마나 많이 의지하고 있는 지 종종 잊어버리지만, 페이스북은 이미 우리의 일상 생활에 아주 깊숙이 자리잡고 있다. 오늘날에는 수 백만 개의 서비스가 존재하지만, 그들은 그럼에도 만족할 줄을 모른다. 그리고 페이스북은 SaaS 회사들이 할 필요가 있는 것들을 정확히 집어서 하고 있다.On-premise(인하우스 서비스)에서 SaaS(클라우드 컴퓨팅)로SaaS는 “Software as a Service.” 의 약자이다. 페이스북은 사실 기술적으로 SaaS라기 보다는, 일종의 소비자 네트워크 서비스라고 할 수 있다. 하지만 페이스북만큼 많은 서비스를 제공하는 곳은 존재하지 않는다. 페이스북이 이렇게까지 성공한 것은 그 서비스 내에서 유저들의 이용률을 크게 늘렸기 때문이다. 다른 SaaS 기업들은 이 부분을 더 신경 써야 될 필요가 있다. 이용률이야말로 지금 SaaS 비즈니스의 생존에 있어 그 어느 때보다 중요하기 때문이다.그 이유는 다음과 같다. 예전에, 소프트웨어는 회사의 컴퓨터 네트워크에 실제 물리적으로 깔려야만 했다. 소프트웨어 판매업자들은 대기업에 라이선스를 팔기도 했고, 그런 기업들은 해당 소프트웨어 이용을 위해 Accenture나 CSC 같은 회사에 돈을 지불하기도 했다. 당시 판매업자들은 라이선스를 많이 팔기만을 원했지, 얼마나 많은 사람들이 그 소프트웨어를 쓸 지에 대해선 관심이 없었던 것이다.그리고 1999년, Salesforce의 공동 창업자인 Marc Benioff는 새로운 모델을 소개하며 다음과 같이 말했다.“설치하는 데만 수 개월이 걸리고 하드웨어와 네트워킹에 엄청난 투자를 요구하는 비싼 CD-ROM 소프트웨어를 기업들에게 파느니, 우리는 클라우드 컴퓨팅이라고 알려진 모델을 통해 Software-as-a-Service(SaaS)를 팔기로 했다. 기업들은 이제 유저의 수에 맞춰 서비스를 이용한 만큼 비용을 지불해야 할 것이고, 그런 서비스들은 인터넷, 클라우드를 통해 즉시 제공될 것이다.”구독 기반(subscription-based) 소프트웨어는 회사 내부의 데이터 센터가 아닌 웹 브라우저를 통해 제공된다. 이는 소프트웨어 개발자로 하여금 언제든지, 즉각적으로 그들의 고객에 접근할 수 있게 해주었다. 어느 순간, 유저를 만족시키는 일은 CIO(Chief Information Officer)나 시스템 통합업체의 책임이 아니게 된 것이다. 그 일은 이제 소프트웨어 판매업자가 하게 되었다.이러한 클라우드 컴퓨팅 방식은 SaaS 소프트웨어로 하여금 생존을 위해 끊임없이 자신들의 가치를 어필하게끔 만든다. 그리고 SaaS 회사들은 계속해서 자신들의 소프트웨어를 이용하는 소비자들을 확보하기 위해 많은 양의 돈을 쓰고 있다. 이는 과거 기업 고객들에게 소프트웨어 라이선스를 팔러 다니던 때와는 180도 달라진 상황인 것이다. 오늘날의 SaaS 회사들은 예전처럼 높으신 몇몇 분들을 만나 무언가를 사라고 설득할 필요가 없다. 그저 이용자들이 자신들의 제품을 계속 사용하게끔 유도하면 되는 것이다.페이스북은 SaaS의 새로운 모델이다이제 페이스북을 한 번 살펴보자. 페이스북은 클라우딩를 통해 지속적으로 서비스를 제공한다. 그들은 광고를 통해 돈을 벌기 때문에, 그들의 가장 중요한 목표는 사람들로 하여금 계속 서비스를 이용하게 하는 데 있다. CIO들을 만나서 큰 계약을 체결하는 데 시간을 쓸 바에야 그 100분의 1초도 안 되는 시간에 12억 명의 사람들에 서비스를 파는 것이 더 낫다는 것이다.페이스북이 딱 한 가지 신경 써야 될 것이 있다면 그것은 사람들이 지금보다 더 적극적으로 페이스북을 이용하게끔 만드는 것에 있다.“우리의 최우선 목표는 모바일 장치나 개인용 컴퓨터를 통해 사람들을 연결시켜주고 공유하게끔 하는 유용하고 매력적인 서비스를 창조하는 것에 있습니다.” – 미국증권협회 기업정보 페이지의 페이스북 파일에서페이스북이 사람들의 관심을 많이 받을수록, 그들은 더 많은 광고를 사람들에게 보여줄 수 있다. 페이스북에게 있어서, 그러한 관심은 아주 중요한 것이다. 더 많은 관심을 받는 다는 것은 더 많은 성장과 확장의 기회를 갖는 다는 것을 의미하기 때문이다. 이것은 드롭박스나 Slack과 같이 바텀업 방식으로 성장한 SaaS 기업들이 새겨들어야 할 점이다. 유저들이 서비스를 쓰는 시간이 많아진다면, 앞으로 그들에게 더 많은 다른 서비스를 쓰게 만들 수 있기 때문이다.앞으로 페이스북이 더 성장하고 발전하려면 유저의 관심이 필요하다. 그래야 여러 방면에서 이용률을 늘릴 수 있는 방법을 찾을 수 있기 때문이다. 이제 여기서 페이스북이 그들 서비스의 이용률과 성장을 이뤄낸 3가지 방법에 대해서 소개해 보도록 하겠다. 모든 SaaS 기업들은 비슷한 방법으로 자신들의 이용률과 성장을 이뤄낼 수 있을 것이다.페이스북은 이용률을 측정하여 현재 운영하는 서비스를 최적화 시켰다페이스북은 이용률을 늘리기 위해 새로운 서비스를 내놓는다페이스북은 다른 앱들과 통합하는 과정을 거쳤기 때문에 페이스북을 쓰지 않는 사람들조차 페이스북을 쓰게 되었다페이스북이 이용률을 어떻게 늘렸는지에 대해 좀 더 깊이 이야기해 보도록 하겠다. 그러고 나면 페이스북의 노하우를 다른 SaaS에 어떻게 적용할 수 있을 지 분명하게 보여줄 수 있을 것이다.이용률 측정을 통해 서비스의 최적화를 이뤄낸다지금 사람들이 어떻게 서비스를 이용하고 있는 지 모르고 있다면 그들에게 당신의 서비스를 사용하게 만들 수도 없을 것이다. 페이스북은 이용률을 늘리는 방법에 대해 집요하게 연구해왔기 때문에 좋은 사례로 들기에 적합하다.핵심은 사람들이 지금 하고 있는 것, 그리고 그들이 원하는 것을 정확하게 아는 것에 있다. 페이스북은 단순히 월 이용자 수나 일 이용자 수를 알아보려 애쓰지 않는다. 왜냐하면 그런 수치들은 사용자들이 그 서비스를 통해 무엇을 하는지를 전혀 설명하지 못하기 때문이다. 대신 페이스북은 서비스 이용의 질적인 부분에 집중한다. 사람들이 페이스북을 통해 무엇을 이루려고 하는 지와 그들이 실제로 그렇게 할 수 있는 지에 대해서 말이다.이 부분에 있어 페이스북의 대표적인 전략 중 하나가 바로 10일안에 친구 7명 만들기이다. 일찍이, 페이스북은 10일안에 7명의 친구를 만드는 사람은 페이스북을 계속 사용할 확률이 훨씬 더 높다는 사실을 알게 되었다. 일단 이것을 알게 되자, 그들은 신규 유저들이 7명의 친구를 만날 수 있게 하기 위해 가진 모든 수단을 쓸 수 있게 된 것이다.바로 지금도, 페이스북은 새로운 친구를 추가할 것을 사람들에게 계속해서 권장한다. 왜냐하면 이것이야 말로 네트워크를 이루는 데 있어서 가장 가치 있는 부분이기 때문이다.페이스북 계정을 만들자마자, 유저들은 뉴스 피드 상단에 새로운 친구를 추가하시겠냐는 메시지가 뜨는 것을 볼 수 있다.아래 사진은 유저들이 다른 페이지를 둘러 보는 동안 뜨는 사이드바인데, 보다시피 그들이 알 수 있을 법한 사람들을 친구로 추가하게끔 권장하고 있다.또한 페이스북은 뉴스 피드와 같이 그 기능을 최대한 활용하기 위해 더 많은 친구들을 추가할 것을 권장하고 있다.페이스북은 이런 전략을 앞으로도 고수할 것이다. 2017년, 페이스북은 “Discover people” 이라는 새로운 기능을 출시했다. 이는 당신으로 하여금 프로필을 업데이트 하게끔 유도하고 기존에 친구가 아니더라도 같은 이벤트에 참여하는 경우 서로를 연결시켜 준다.페이스북은 사람들이 자신들의 서비스를 계속 이용하게 만들기 위해 기나긴 세월 동안 노력해왔고 앞으로도 그럴 것이다. 그들은 친구 최적화를 빠르게 해줄 뿐만 아니라 흥미를 잃은 사람들도 쉽게 다시 돌아올 수 있도록 여러 요인들을 제공해준다. 페이스북의 성장 전담 부서를 이끌고 있는 Chamath Palihapitiya은 “당장의 단기적인 이익에만 집중하지 않기 위해서는 절제력이 필요하다.” 라고 말한다. 페이스북은 초창기부터 무엇보다 사람들의 이용률이야말로 그들의 성패를 좌우한다는 것을 알고 있었다. 사람들의 주된 목표를 파악해서 이용률을 장기적으로 늘리는 것이 그들의 제1과제 였던 것이다.Trello는 어떻게 유저들이 쉽게 직장 동료를 추가하도록 만들었는가페이스북과 똑같이, Trello는 유저들이 무엇을 하는지를 이해하고 그들이 원하는 걸 더 많이 하게 도와주는 방식으로 이용률을 올렸다. Trello의 핵심적인 가치는 사람들이 프로젝트를 협력하게끔 만드는 것이었기 때문에, 그들이 그렇게 하도록 도움을 줘서 자신들 서비스의 가치를 보여줘야 했다.그래서 Trello가 직장 동료를 추가하는 방식은 놀라울 정도로 쉽게 되어 있다. 이는 페이스북이 친구를 추가하는 방식과 정확히 똑같다. 페이스북이 사람들로 하여금 쉽게 친구를 추가하게 하여 소셜 네트워크의 가치를 입증했다면, Trello는 쉽게 동료들을 추가하게 하여 프로젝트 협업 툴로써의 가치를 입증했다.Trello는 유저들로 하여금 이름이나 이메일 주소로 아는 사람들을 등록할 수 있게 만들었다. 유저들은 코드나, ID, 링크 같은 것 없이도 사람들을 쉽게 추가할 수 있다. 심지어 다른 사람들이 Trello를 사용하는지도 알 필요가 없다. 어찌 됐든 Trello를 통해 사람들을 찾아보고 확인해 볼 수 있는 것이다.또 만약 Trello를 한 번이라도 썼던 사람이라면 더욱 쉽게 목록에 추가할 수 있다.이런 방식을 통해 이용자들은 아무런 마찰 없이 많은 동료, 협력자들을 통해 프로젝트를 공유할 수 있다. 즉, Trello의 핵심 가치를 이루게 되는 것이다. 이는 사람들에게 Trello가 얼마나 유용한 서비스인지를 빠르고 쉽게 이해시켰다. 또한 이는 더 많은 사람들이 더 많은 프로젝트를 하게끔 유도했고, 결국 모두가 Trello를 더 많이 이용하게 되었다.Slack은 어떻게 이용률을 늘려왔는가이렇게 사용자의 이용률에 집중해서 성장을 이루고 있는 유명한 SaaS 기업이 또 하나 더 있다. Slack이 바로 그 기업인데, Slack은 메시지를 매끄럽게 전송하는 역할 하나에만 전념하고 있다.Slack은 자신들의 서비스를 이용해 2000개 이상의 메시지를 보낸 적 있는 팀들은 Slack의 가치를 알고 있기 때문에 앞으로도 계속 서비스를 사용할 것이라고 예측한다. 왜냐하면 Slack의 통계에 따르면, 다른 요소들이 어떻든 간에, 2000개 이상의 메시지를 보낸 팀들 중 93%가 지금까지도 Slack을 사용하고 있기 때문이다. 그래서 이용률을 늘리기 위해선, 메시지를 보내는 것을 더 쉽게 만들어야 하는 것이다. Slack의 공동 창업자인 Stewart Butterfield 역시도 이 목표를 위해 사람들이 실제로 어떻게 Slack을 쓰고 있는가에 대해서 생각해보았다.“처음으로 Slack을 쓰려고 온 사람이 되었다고 생각해 보는 겁니다. 특히 진짜 사회생활을 하는 사람들 말이죠. 상사에게 Slack을 쓰라고 해서 쓰게 된 사람, 아침 먹을 시간도 없어서 짜증이 난 사람, 주말이 오기 전에 프로젝트를 끝낼 수 있을지 걱정하는 사람… Slack을 면밀히 살펴봐서, 이런 사람들에게 먹히지 않을 것 같은 요소들을 생각해 내는 겁니다. 냉정하게 보는 거에요. 최고의 서비스를 주기 위해서 말이죠.”Slack은 메시지 전송에 따르는 불편함을 개선하면서 이용률을 늘려왔다. 그러한 개선의 예를 들어 보자면, 누군가가 Slack에서 링크를 걸었다고 했을 때, Slack은 그 링크에 대한 간단한 정보를 미리 보여준다. 즉, 사람들은 링크를 보려고 앱에서 빠져나와야 될 필요가 없는 것이다. 나중에 다시 그것을 확인해보기도 편하고 말이다.이런 시스템상의 개선점들이 Slack을 성장하게 만들었다. 메시지를 보내는 것에 있어서 사람들이 원하는 부분을 아주 쉽게 할 수 있게 만들었기 때문이다.이렇듯 페이스북, Trello, Slack은 모두 실제 이용자들이 원하는 것을 이해하고 그들이 그것을 쉽고 빠르게 할 수 있는 서비스를 제공하고 있다. 아래에 이런 SaaS 기업들이 어떻게 자신들의 서비스를 통해 이용자들에게 도움을 줬는지 요약해보았다.페이스북의 10일안에 친구 7명 만들기, Slack의 2000개 이상의 메시지 보내기, Dropbox의 파일 한 개 업로드 하기 등과 같이 그들은 수치로 표시되는 목표를 세웠다. 이러한 목표는 당신의 팀으로 하여금 무엇이 가장 이용률을 끌어오는데 중요한 지를 확인시켜줄 뿐만 아니라 그들에게 목표 달성을 위한 구체적인 숫자를 알려준다.핵심적인 기능들을 사람들이 이용하게 하려면 그것을 직관적으로 만들어야 한다. Raymond Loewy(미국의 전설적인 산업 디자이너)에 따르면, 성공적인 서비스는 사람들이 당장 사용하기에 편해야 한다고 한다. 예를 들어, 페이스북이 처음 “On this day” 서비스를 도입한 것은 유저들로 하여금 무언가 새로운 것을 하는 걸 권하기 위해서였다. 하지만, 이 서비스는 여전히 유저들에게 친숙한 태그, 공유하기 기능들을 사용하고 있다.유저들의 참여를 막을 만한 요소들을 찾아서 없애야 한다. 사용자들이나 얼리 엑세스 베타 테스터 등과 이야기를 해봐서 무엇이 서비스에 있어 가장 짜증나는 요소인지 알아내야 한다. “이거 어떻게 하는 건지 모르겠어요” 라던가 “이게 좀 쉽게 됐으면 하는데…” 와 같은 불만들에 귀기울여야 한다. 이런 장애물들을 제거하면 유저들이 서비스를 이해하기 더 쉽고 그 서비스의 가치를 파악하는 것 역시 쉬워진다.즉, 현재 가지고 있는 서비스 내에서 이용률을 끌어올리려면 유저들에게 무엇이 가장 도움이 되고 의미가 있는지 파악하는 것이 가장 중요하다고 할 수 있다.이용률을 늘리기 위해 서비스를 추가한다이용률을 끌어올린다는 것은 단순히 사람들로 하여금 기존의 서비스를 계속 쓰게 만드는 것 만을 의미하지는 않는다. 당신은 끊임없이 실험을 해보고 새로운 서비스를 제공해서 유저들이 서비스를 통해 더 많은 것들을 얻을 수 있도록 해야 한다.페이스북은 기존에 그들이 가진 서비스가 수명이 다할 것을 걱정해서 계속 실험을 하고 이용자들이 앞으로 무엇을 원할지를 예상해왔다.페이스북의 직원 가이드북을 보면, 새로운 직원들은 그들의 팀이 계속 새로운 생각을 하게끔 자극 할 것을 권장하고 있다.그 결과, 페이스북은 끊임없이 혁신하고, 또 그만큼 실패를 경험하고 있다.페이스북은 스냅챗으로부터 이용자들을 뺏어오기 위해 2012년 별도의 앱인 Poke를 출시한다. 그런데 이 앱은 대실패작이 되었고 페이스북은 얼마 지나지 않아 앱스토어에서 이 앱을 삭제하게 되었다.2014년에 페이스북은 이용률을 늘리기 위한 일환으로 슬링샷이라는 앱을 출시했다. 이 앱은 사진과 함께 메시지를 보내면 스냅챗과 같이 몇 초안에 사라지는 것이 특징인데 불과 1년만인 2015년에 앱스토어에서 내려가게 되었다.또 페이스북은 2016년 Quick Update라는 것을 시도했다. 이는 스냅챗과 비슷한 기능을 페이스북 앱에 추가시키는 것이었는데, 이런 기능을 유저들을 대상으로 그룹테스트 해 본 결과 반응이 좋지 않아 결국 공식적으로는 출시되지 못하게 되었다.이런 좋지 않은 결과들은 페이스북이 혁신에서 실패하고 있다는 소문을 자아냈다. Jason Calacains 같은 논평가는 이에 대해 “페이스북의 앱 플랫폼은 망하기 위해서 혁신을 하는 것인가?” 라고 하기도 했다.하지만 페이스북의 이런 계속되는 시도는 결국 그들을 새로운 기회로 인도했다. 그들은 스냅챗의 스토리 기능을 페이스북과 인스타그램에 도입하려고 시도해 왔는데 이 과정에서 마침내 페이스북 라이브라는 새로운 서비스를 만들어냈다. 이 서비스는 대히트를 쳤고, 이제 회사, 미디어, 그리고 유명인사들까지 모두 페이스북의 라이브 스토리를 사용하고 있다.이렇듯 페이스북이 큰 성공을 거둘 수 있었던 이유는 그만큼 실패도 많이 해봤기 때문이다. 그들은 그저 사람들이 관심 가질 만한 새로운 무언가를 계속 만드는데 집중할 뿐이다. 왜냐하면 이런 시도야말로 궁극적으로 이용률을 더 많이 올릴 수 있는 방법이기 때문이다.드롭박스 역시 이용률을 높게 유지하기 위해 새로운 서비스를 만들고 있다SaaS 기업들은 현재의 서비스보다 한 걸음 더 앞선 서비스 제공을 통해 이용률을 끌어올릴 수 있다. 그들은 지금 하는 것 이외에 이용자들이 무엇을 더 원하고 더 신경 쓸까를 생각해 볼 필요가 있다.그 예로 드롭박스의 드롭박스 페이퍼를 들 수 있다. 드롭박스는 원래 파일 공유 서비스였다. 하지만 오늘날, 드롭박스는 파일을 공유하는데 있어 다양한 방법을 제공해준다. 만약 드롭박스가 처음 서비스 이외에 유저들이 뭘 더 원할 것인 지를 생각해보지 않았다면 결국 이용률을 올릴 방법이 바닥나서 망하게 됐을 것이다.즉 드롭박스는 단순한 파일 공유 서비스에서 사람들이 함께 일하는 걸 더 쉽게 만들어 주는 일종의 팀 협업 툴로 자신들의 브랜드를 쇄신한 것이다. 이러한 재브랜딩 과정과 함께, 드롭박스는 2015년에 “창조적인 업무를 위한 새로운 형태의 파일 편집 툴” 이라는 신규 서비스인 드롭박스 페이퍼를 런칭했다.드롭박스 페이퍼는 단순히 문서와 파일을 저장하는 데 드롭박스를 쓰는 것이 아니라, 이제 문서와 파일을 만드는 데에도 드롭박스를 쓸 수 있게 만들어 주었다. 드롭박스 페이퍼는 사람들이 더 많이 서비스를 이용하게 만들었는데, 이는 파일 공유를 넘어 사람들간의 협업을 더 쉽게 해준다는 추가적인 옵션을 제공해줬기 때문이다.드롭박스가 이렇게 새로운 서비스를 만들려는 이유는 생존하기 위해서이다. 이 산업에 있어 망하는 일은 너무나 쉽게 일어나기 때문이다. Intercom의 Des Traynor는 다음과 같이 이를 설명한다.“원래 이쪽 산업이란 게 이런 겁니다, 기술이란 것의 특성 자체가 이런 것이죠. 모든 서비스가 결국 다 죽어 없어지게 되어있습니다. 만약 내 말이 사실이 아니라고 생각한다면 저에게 그렇지 않은 경우를 알려주세요. 한때는 SaaS 비즈니스가 절대 안 망할 것 같은 시절도 있었습니다. 하지만 더 이상은 아니에요.”만약 당신이 유저들이 당장 원하는 것에 대해서만 생각하고 있다면, 이미 망하고 있는 것이다. 성공적인 SaaS 기업들은 항상 유저들이 미래에 뭘 원하게 될 지에 대해서 생각한다. 아래에 SaaS 기업들이 어떻게 소비자들의 미래 욕구와 새로운 서비스에 대해 예측하려 하는 지 정리해보았다.당신의 경쟁자들, 그리고 왜 유저들이 그들의 서비스를 이용하는지 이해하라. 온라인 포럼 등을 보고 사람들이 경쟁사의 서비스를 어떻게 평가하는지를 알아내라. 이를 통해 당신은 사람들이 무엇을 원하는지, 그 방향이 어디로 향하게 되는지에 대한 통찰력을 얻게 된다. 이런 과정은 서비스의 확장과 새로운 서비스를 실험해 볼 수 있는 기회도 제공해준다.당신의 서비스를 사용했을 때 유저들이 무엇을 할 수 있을지를 생각해 봐야 한다. 유저들이 당장 요구하는 것만 만드는 것이 아닌 그들이 앞으로 원할 것이 무엇인지를 한 발 앞서 생각해 보는 것이다. 예를 들어, 아마존이 최근 개시한 새로운 서비스인 “Your idea” 리스트를 보자. 이 서비스는 유저들이 쇼핑을 하면서 비록 구입 하진 않더라도 커뮤니티에 자신이 생각한 리스트를 보여주고 싶은 욕구를 미리 연구해서 나온 결과물이다.가장 효과적이면서도 남들이 쉽게 예상하기 힘든 기능들을 우선순위로 짜는 것이 좋다. Gusto의 Tomer London은 서비스를 만들고 그것을 개선시킬 때, 가장 좋은 기능은 타인이 예측하기 어려움에도 불구하고 사용자 경험을 개선시키는데 가장 효과적인 것들이라고 한다. 사람들이 서비스를 통해 무엇을 가장 하고 싶어하는 지를 이해하고 그들을 도와줄 더 쉽고 나은 방법들을 생각해본다면 가장 효과적인 기능에 대한 단서를 잡을 수 있다. 남들이 예측하기 어려운 방법들은 당신이 처한 경쟁 지형에 대해 이해함으로써 알아갈 수 있다. 서비스 이용률을 늘리기 위해 다른 서비스와 통합한다우물 안의 개구리처럼 서비스를 홀로 제공하려 한다면 최대한의 이용률을 얻기란 요원하다. 당신은 새로운 서비스를 내놓음으로써 이용률을 늘릴 수 있지만, 그것으론 충분하지 않다. 유저들은 항상 다른 서비스 역시도 사용하고 있다. 당신이 이길 수 있는 방법은 당신의 서비스를 다른 서비스에 포함시킴으로써 사람들이 그 서비스를 쓸 때, 당신의 서비스도 쓰게 만드는 것이다.당신이 페이스북 웹사이트나 앱을 통해 페이스북을 쓰고 있지 않더라도, 당신은 페이스북을 사용하고 있는 것이나 마찬가지이다.페이스북을 이용해서 다른 서비스에 로그인 할 수 있다당신은 다른 웹사이트의 컨텐츠를 페이스북에 공유할 수 있다당신이 작업하는데 쓰는 서비스를 페이스북에 연결시킬 수 있다.티켓마스터를 통해 공연 티켓을 구매하는 것 역시도 페이스북으로 할 수 있다.페이스북은 다른 서비스들과도 완전히 통합이 되었기 때문에 사람들은 페이스북 인터페이스를 다른 서비스에서 보더라도 전혀 이상하게 생각하지 않는다. 심지어 어떤 경우에는, 페이스북 계정이 없다면 다른 사이트에 가입하기 어려울 때도 있다.페이스북이 다른 서비스와 더 통합이 될수록 당신은 더 페이스북을 쓰게 되고 그것을 필요로 하게 된다. Social Capital LP의 공동 경영자인 Arjun Sethi는 이점에 대해 다음과 같이 말한다.“페이스북이 권장하는 행동들이 일종의 문화가 되고 있어요. 페이스북은 그냥 가만히 앉아서 다른 서비스가 자신의 특징들을 베끼는 걸 보고만 있지 않았습니다. 자신들의 서비스를 다른 곳에 아주 쉽게 통합될 수 있게 만들었고 그 과정에서 핵심적인 이득은 다 챙겨갔습니다.”이것은 페이스북의 신중한 성장 전략의 일환이다. 다른 서비스의 개발자들이 페이스북을 쉽게 그들의 서비스에 통합할 수 있게 만듦으로써, 그냥 자신들의 서비스 내에만 머물러 있는 것에 비해 훨씬 더 많이 사람들이 페이스북을 사용하게끔 만들었다.Slack 역시도 다른 툴과 쉽게 통합이 가능하다페이스북이 다른 소셜, 라이프스타일 서비스들과 통합해서 유저들을 끌어모은 것처럼, Slack 역시도 자신들의 서비스를 다른 관련된 툴들과 통합할 수 있게 만들었다.Front와 같은 이메일 클라이언트와의 통합은 사람들로 하여금 Slack에서 바로 이메일을 관리할 수 있게 하였다.Slack은 또 Stripe와 통합을 하였는데, 이로 인해 사람들은 Slack 내에서 고객 결제 데이터를 보고 관리할 수 있게 되었다.Google Docs와의 통합으로 Slack 앱을 나가지 않고도 구글 문서 활동들을 볼 수 있게 되었다.Slack은 서드 파티의 통합을 장려하기 위해 거대한 앱 생태계를 구축하고 있다. 2015년에, 그들은 앱과 관련해서만 8천만 달러의 벤처 펀드를 만들었다. 2016년에, Slack은 자신의 플랫폼 내에 600개 이상의 앱을 보유하게 되었다. 그래서 이메일을 관리하거나, 고객과 커뮤니케이션을 하거나, 제품 분석 결과를 보는 것 등을 하러 다른 곳으로 일일이 가는 대신에 Slack 유저들은 기존 자신들의 서비스를 통해서 그 모든 것들을 할 수 있게 되었다.페이스북과 Slack은 그들 서비스의 유저들이 사용할 만한 다른 서비스들과 통합을 통해 이용률을 올렸다. 당신 서비스의 이용자들도 알고 있는 이런 기술의 생태계 속에 당신의 서비스를 끼워 넣는 방법에 대해 아래에 정리해 보았다.당신의 서비스를 사용하는 유저들의 워크플로우 대해 생각해보고 그것을 개선시킬 수 있는 점들에 대해서 추측해보라. 예를 들어, HubSpot을 이용하는 기업들의 궁극적인 목적은 사람들을 광고로 유인해서 실제 고객으로 만드는 데 있다. 그래서 HubSpot은 그 목적을 더 잘 수행하기 위해 자신들의 CRM 툴을 페이스북의 광고 관리 프로그램인 Adespresso와 통합할 수 있 게 만들었다. 즉, 사람들이 페이스북 광고를 클릭하게 되면 그 유저의 정보는 자동으로 그들의 CRM에 업로드가 된다.다른 유명 서비스들과의 통합을 통해 그들의 규모가 가진 이점을 가져오는 것이 좋다. 눈에 잘 띄는 서비스와의 통합은 당신의 서비스 역시도 눈에 잘 띄게 만들어준다. 잠재적 유저들에게 당신의 서비스를 소개할 수 있는 기회를 더 얻을 수 있을 뿐만 아니라, 다른 유명 서비스가 가진 브랜드 신뢰성 역시도 가져올 수 있다. 만약 당신의 회사가 아직 작다면, 유명하고 접근하기도 쉬운 Slack이나 페이스북과 같은 서비스와 함께 시작하라.Zapier를 활용해서 다른 서비스들과의 통합을 도모해라. Zapier에 호환이 되도록 앱을 만든다면, 유저들로 하여금 당신이 아직 직접적으로 통합을 제안하기 어려운 다른 앱들과 통합할 수 있는 옵션을 제공해 주는 것과 다름이 없다. 이 방법은 당신의 서비스가 아무리 독특하다 할지라도 그것을 유저들의 워크플로우에 집어넣는 데 도움이 된다.서비스를 개선시키는 데 있어 한 가지 방법만 써서는 이용률을 끌어올리는 데 한계가 있다. SaaS 기업들이 정말로 유저들로 하여금 그들의 서비스를 계속 좋아하고 이용하게끔 만들려면, 할 수 있는 모든 방면에서 이용률 최적화를 해야 한다. 기존의 서비스 내에서 할 뿐만 아니라, 새로운 서비스, 다른 유저들에게 이미 필요한 다른 서비스와의 통합을 해서라도 말이다.차세대 SaaS를 만드는 것에 대해SaaS 서비스들은 점점 더 무용지물이 되어 가는 경우가 많고 사라지는 서비스들도 많다. 만약 SaaS 기업들이 왜 사람들이 그들의 서비스를 쓰는 지 이해하지 못한다면, 그들은 계속 성장할 수 없을 것이고 유저들도 이탈할 것이다.지금까지의 내용을 정리하자면 페이스북은 이용률과 성장을 도모할 수 있는 매우 포괄적이면서도 단순한 방법 3가지를 생각해냈다. 사람들이 현재의 서비스를 더 많이 사용하게 만드는 것, 새로운 서비스를 통해 더 많이 사용하게 만드는 것, 그리고 다른 서비스와의 통합을 통해 자신의 서비스를 더 이용하게 만드는 것. 이 3가지이다. 그리고 이렇게 이용률을 올린다는 것은 성공을 의미한다.미래에 가장 성공적인 SaaS 기업 역시 이용률에 중점을 두게 될 것이다. 지금까지 페이스북을 모델로 삼아 설명한 것처럼, 이것들이 SaaS 기업이 앞으로 더 나은 서비스를 만드는 방법이 될 것이다.원문 : 프로덕트해빗#더팀스 #THETEAMS #SaaS #인사이트 #페이스북
조회수 1059

[사람이 서비스다] #4 JD, 안드로이드앱 개발 담당

셀잇은 기존 중고거래 시장에서 이용자들이 겪는 불편과 불안감을 해소하기 위해 등장한 서비스라는 자부심을 가지고 구매자와 판매자를 잇는 접점이 되고자 합니다. 이를 위해 서비스를 기획하고 실행하는 저희 구성원들에 대한 이야기를 간간히 들려드리고자 합니다. 좋은 서비스든 아이디어든 결국 사람이 하는 일이니까요-저희가 어떤 생각을 품고 어떤 마음가짐으로 살아가는지에 대해 진솔하게 풀어보고자 합니다. 이 청년들의 이야기, 한 번 들어보실래요? Interviewee: JD (제이디, 개발팀 / 안드로이드앱 개발 담당)Interviewer: Austin (오스틴, 마케터)  우선 자기소개부터 간단히 해주시죠. 흔해 빠진 소개일랑 집어치우고! 최대한 자신을 우리에게 알려봐요! 정~ 뭐라고 쓸지 모르겠으면 자기 이름으로 삼행시라도 해보세요. 우선 저에게 이런 귀찮은 일을 안겨준 브라이언에게 감사의 인사를 전하는 바입니다. 덕분에 독무대에 이어 다시 한번 불면증에 시달리게 되었어요. 그건 브라이언에게 개인적으로 앙갚음(?)을 해주시고, 본인 소개부터 해주세요. 저도 바쁘답니다. 안녕하십니까? 저는 전남 해남의 작은 시골 마을에서 2남 중 장남으로 태어나 안드로이드 개발을 하고 있는 JD라고 합니다. 원래는 게임 개발이 하고 싶어서 프로그래밍 공부를 시작하였지만 어쩌다 보니 앱을 개발하고 있네요. (뭐, 뭐지? 이 ‘신입사원의_패기.wav’ 같은 느낌은?) 그럼 현재 셀잇에서 개발자로 일하시겠군요. 그럼 본인이 하는 일 중에서 이건 나만의 스페셜티다! 하는 부분은 무엇인가요? 당연히 안드로이드 개발입니다. 우리 회사에서 저 밖에 못하는 거죠~(찡긋) (찡...찡긋?) 하하하;; 네네 그렇군요. (셀잇이 잘 되는 이유가 이거였군. 정상적인 놈이 없는...) 그게 다인가요? 개발하시다가 잘 안풀리거나 열 받을 때는 어떻게 하나요? 자세한 건 ‘영업비밀’이니까- 전 안풀리면... 음- (한참을 생각한다)잠을 잡니다. (역시 오늘도 산으로 가는건가…) 아…(포기한 듯) 얼마나 자나요? 한 20분 정도 짧게 자요. 사실 잔다기보다는 자는 척을 하면서 생각을 하는거죠. 읭? 굳이 자는 척을 해야 될 필요가 있나요? 그냥 대놓고 생각하면 안되는건가요? 안됩니다! 온전한 집중을 위해서 자는 척을 해야 해요. (정적) 인터뷰 하는 중에 월드시리즈까지 끝나버렸네요... 올해 모든 야구가 끝나버렸어요 ㅠ (후우... 내가 이걸 왜 시작했을까...) 그럼 일 얘긴 그만하고(더 할 수도 없겠어;;) 업무 외의 시간에는 주로 뭘 하시나요? 듣자하니 야구를 좋아하는 것 같은데- 야구를 봅니다. 한국 야구는 기아를 응원하고, 메이저리그는 한국 선수들이 진출한 팀들을 응원하고 있어요. 주말에는요? 주말이면 아침에 일어나서 메이저리그 두 경기 정도 보고 오후에는 한국 야구를 보면서 하루를 보냅니다. 이제 야구 시즌도 다 끝나서 다가오는 겨울이 두렵습니다ㅠ 차라리 야구선수로 전향하시는게- 만약 실력이 문제라면 사회인 야구팀이라도 해보시는건요? 그건 돈도 많이 들고, 일단 귀찮고-부상 위험도 크고, 일단 귀찮고-그냥 친구랑 캐치볼 하는 것으로 만족합니다. 그리고 일단 귀찮고- 커피나 한 잔 하실래요? 커피나 마시면서 다른 얘기로 넘어가죠~ 괜찮습니다. 저는 카페인 마시면 안되서- 아, 그럼 그냥 계속 하죠. (여자랑은 술 마시고 나랑은 커피도 안 마시냐?-_- 쳇, 근데 이해되네...) 중고에 대해서 어떻게 생각하세요? 중고를 바라보는 가치관 같은게 있으시면 말씀해 주세요. 제가 환경 문제에 관심이 많습니다. 중고거래가 보편적으로 활성화 된다면 상대적으로 공산품의 생산량이 줄어들게 되고, 이는 지구의 자연 환경에 도움이 되지 않을까 합니다. (응? 뭔가 익숙한데?) 제가 예전에 쓴 글을 보신건가요?… 네~ 꼭 중고 거래가 활성화되서 지구 환경을 지켜주세요… 그럼 마지막으로 셀잇에서 이루고 싶은 것은 무엇인가요? 주로 컴퓨터 부품들을 중고 거래를 이용해 구매했던 적이 있는데요. 항상 직거래를 했지만 정상 작동하는지 불안했던 기억이 있습니다. 집에 와서 컴퓨터에 장착해 보고서야 안심을 하곤 했었는데, 셀잇을 이용하면 최소한 이런 걱정 없이 믿고 안심하며 거래할 수 있는 서비스로 자리 잡을 수 있었으면 합니다. 아니 이건 셀잇이 나아갈 방향이고~ 저는 제이디 본인 개인의 목표에 대해서 물은거예요. 셀잇이 곧 저입니다. 화, 화이팅...! (후우...) 이런 자리가 부끄럽죠? 가슴 속에 뜨거운 뭔가가 있는게 보이지만 굳이 밝히지 않으시겠다면 앞으로 안드로이드 앱을 통해 그 뭔가를 제가 찾아보겠습니다. (빨리 끝내려 애쓴다;;) 인터뷰는 이 정도로 마치는 것으로 하고~ 셀잇에서 칭찬하고 싶은 사람 한 명만 꼽아주세요. 이유도 함께 말해주세요. 전 네이쓴을 칭찬하고 싶습니다. 특유의 친화력과 유머러스함으로 주변 사람들을 기분 좋게 만들어주는 아주 훌륭한 팀원이기 때문입니다. 로봇입니까? 네? 아닙니다. 그럼 오늘 수고하셨습니다. 아! 최근에 셀잇 앱 2.0이 배포됐는데 감회가 남다를 것 같 같은~ 어떠세요? 딱히 이렇다할 소감은 없습니다만 이용자분들이 이전보다 더 편하게 서비스를 이용할 수 있었으면 하는 바람입니다. (로봇 맞네...) 넵- 수고하셨습니다. (하아... 네이쓴이라... 다음엔 우주로 가겠구만...)#셀잇 #번개장터 #인터뷰 #팀소개 #팀인터뷰 #팀원소개 #기업문화 #조직문화 #회사문화 #사내문화
조회수 2881

Eclipse 디버거 사용법

꽤 많은 분들이 디버거의 존재 자체를 모르고 있거나 혹은 디버거가 있다는 사실은 알아도 그 효용성에 의문을 제기하곤 합니다. 왜냐하면, 우리에겐 Log 클래스나 혹은 printf같은 훌륭한(?) 디버깅 도구가 있다고 생각하기 때문이죠. 물론 이렇게 필요한 변수를 찍어보면서 어떤 곳에서 버그가 있는지를 알아보는 일이 잘못된 일은 아닙니다만 복잡한 여러 상황이 맞물려 재현되는 버그는 이러한 고전적인(?) 방법을 써서 알아보기가 매우 어렵습니다.원인을 정확히 그리고 빨리 파악하려면 디버거의 사용법을 숙지하고 사용하는 것이 가장 좋습니다. 대부분의 개발 환경에서 디버거를 제공하는데 다행히 이클립스에서도 쓸만한 디버거를 내장하고 있습니다.오늘 포스팅에서는 이클립스 디버거 사용법에 대해 다루어 볼까 합니다.이클립스 디버거 뷰이클립스는 디버거 뷰를 제공하여 디버거를 사용할 수 있도록 합니다. 디버거 뷰는 어디에서 확인할 수 있을까요? 바로 우측 상단에 Debug 뷰에 들어가면 그곳에서 확인할 수 있습니다.디버깅의 시작그렇다면 어떻게 디버깅을 활성화한 상태로 프로그램을 실행할 수 있을까요? 상단 메뉴의 Run에서 프로그램을 실행할 때 Debug를 이용하여 프로그램을 실행하면 디버거가 작동하게 됩니다.브레이크 포인트 설정과 뷰보통 디버깅을 할 때 가장 먼저 하는 일이 브레이크 포인트를 잡는 일입니다. 브레이크 포인트를 에러가 일어나는 라인이나 혹은 의심이 가는 변수를 추적할 수 있는 라인쯤에 잡아놓고 프로그램을 디버깅하면 해당 라인을 실행할 때 디버거가 작동하게 되고 그곳에서 프로그램을 라인 별로 진행해가며 관찰을 진행할 수 있게 됩니다.브레이크 포인트 설정은 매우 간단합니다. 편집기 왼쪽에 파란 부분(마커 바)을 더블 클릭하게 되면 파란 원이 생기는데 이 원이 브레이크 포인트입니다. 혹은 오른 클릭하여 Toggle break point를 누르면 됩니다. 설정 후 다시 더블 클릭하게 되면 브레이크 포인트가 사라지게 됩니다.또한, 디버그의 브레이크 포인트 뷰에서 지금까지 걸어놓은 모든 브레이크 포인트들의 위치를 확인할 수 있고 활성화/비활성화, 삭제도 할 수 있습니다. 여러 브레이크 포인트가 걸려있을 때에는 이 탭에서 확인하고 관리하는 것이 더 편합니다.또한, 디버깅을 진행하고 있는 도중에도 다른 의심이 가는 라인에 브레이크 포인트를 걸 수 있습니다.스텝 단위 진행지정한 브레이크 포인트에 다다르면 동시에 디버거가 작동하게 되고 그 라인부터 스텝 단위의 진행을 할 수 있게 됩니다.이제 이 뷰의 버튼들을 이용하여 현재 상황을 진행하거나 되돌릴 수 있습니다. 자주 사용하는 버튼의 사용법을 알아보면Resume : 다음 브레이크 포인트를 만날때까지 진행합니다.Suspend : 현재 작동하고 있는 쓰레드를 멈춥니다.Terminate : 프로그램을 종료합니다.Step Into : 메서드가 존재할 경우 그 안으로 들어가 메서드 진행 상황을 볼 수 있도록 합니다.Step Over : 다음 라인으로 이동합니다. 메서드가 있어도 그냥 무시하고 다음 라인으로 이동합니다.Step Return : 현 메서드에서 바로 리턴합니다.Drop to Frame : 메서드를 처음부터 다시 실행합니다.등이 있습니다.실제로 디버깅 화면에서 버튼들을 눌러보면 쉽게 그 쓰임새를 아실 수 있습니다.변수의 상태 확인을 쉽게 해주는 변수 뷰디버깅을 진행하는 도중 변수의 값이나 객체의 상태를 알고 싶은 상황이 생기게 됩니다. 현재 의심이 가는 변수 이외에도 이 변수에 영향을 끼칠 다른 변수들이나 객체들의 상황을 실시간으로 검사할 필요가 있을 때 변수 뷰를 이용하면 도움을 얻을 수 있습니다.이곳에서 변수나 객체의 상태를 확인하고 변수의 상황에 대해서 저장할 수 있습니다. 변수나 객체의 상황을 모두 저장해서 클립보드에 붙이고 싶은 일이 생기면 해당 변수를 오른클릭 후 Copy Variables를 선택합니다.편집 창으로 돌아가 변수에서 Command + shift + i를 누르게 되면(혹은 오른 클릭 후 Inspect를 선택) Inspector 창이 뜨게 됩니다. 이 창에서 다시 한번 Command + shift + i를 누르면 해당 변수를 Expression 뷰로 보내게 되고 이곳에서 지속해서 변수의 상태를 관찰할 수 있게 됩니다.Expression 뷰 이용Expression 뷰에서는 변수 이름을 입력하거나 수행해보고 싶은 명령어를 직접 입력하여 그 결과 값을 관찰할 수 있습니다. 결과 값을 관찰할 뿐만 아니라 Expression에 써놓은 변수들은 명시적으로 지우지 않는 이상 계속해서 관찰을 수행하기 때문에 변해가는 상황을 지속해서 관찰할 일이 있는 변수나 명령문을 등록해놓기에 좋습니다.Display 뷰 이용디스플레이 뷰에서는 현 문맥에서 사용할 수 있는 명령어를 실행하거나 변수의 값을 조작하는 일을 수행하기에 적합한 환경을 제공합니다. Expression에서도 비슷한 기능을 제공하지만, 디스플레이 뷰를 이용하는 것이 더 편합니다. 메모장과 같이 쉽게 쓰고 지울 수 있기 때문입니다.또한, 원본 코드의 수정 없이 편하게 현재의 맥락을 변화시킬 수 있는 것이 가장 큰 장점이라고 볼 수 있습니다.필요한 명령어들을 적어놓은 후 실행하고 싶은 부분만 드래그하여 수행하거나 혹은 값을 리턴받을 수 있습니다. 지금은 boolean변수 하나의 값을 바꿔보기도 하고 조건 값에 따라 무언가를 리턴 받도록도 해놓은 상황을 스크린 샷으로 담아보았습니다.값을 반환받고 싶을 때는 두 번째 버튼을, 단순히 실행만 할 때에는 세 번째 버튼을 누르면 됩니다.두 번째 버튼을 눌러 값을 반환받는 상황입니다.단순히 실행만 하려면 세 번째 버튼을 누릅니다.브레이크 포인트에 조건 걸기브레이크 포인트에 조건을 거는 것이 굉장히 유용할 때가 있습니다. 특히 반복문안에 들어가 있는 코드들을 디버깅할 때 유용하지요. 반복문의 경우 모든 상황을 검사한다기보다는 특정 조건에서 값이 어떻게 들어가는지를 분석하는 경우가 더 많은데 이러한 상황을 검사하기 위해서 브레이크 포인트에 조건을 걸어야 합니다.브레이크 포인트를 거는 과정까지는 똑같습니다. 브레이크 포인트를 건 후 그 포인트에서 오른 클릭을 하면 Breakpoint properties 옵션이 있는 것을 확인할 수 있습니다. 이 옵션에서 조건문을 설정하여 디버거의 활성화 조건을 설정할 수 있습니다.먼저 Conditional을 활성화하여 어떤 조건에서 디버깅 화면으로 전환할지를 쓰면 되는데 이 창에 조건식을 쓰면 됩니다.또 hit count를 이용하여 조건을 걸 수도 있습니다. hit count에 값을 적용하면 해당 라인에 브레이크 포인트가 hit count만큼 잡힌 이후 디버깅 화면으로 전환하게 됩니다. hit count옵션은 반복문에서 한 100번쯤 이후에 디버깅을 시작하고 싶거나 하는 일이 생길 때 유용하게 쓸 수 있습니다.#스포카 #개발 #개발자 #꿀팁 #조언 #인사이트 #디버거 #디버깅 #디버그 #Eclipse
조회수 979

[Tech Blog] Software architecture: The important stuff

마틴 파울러는 Software architecture 를 “무엇이건 간에 중요한 것들(The important stuff whatever it is)” 이라고 정의합니다. 조금은 재미있는 정의지만, 그 정의를 도출하기 위해 제시한 다른 정의를 들어보면 고개를 끄덕이게 합니다.  Software architecture 는 전문 개발자들이 같은 생각을 가지고 이해하는 시스템 디자인입니다. Software architecture 는 이른 시기에 정해져야 하는 디자인 결정들입니다. 혹은 여러분이 “아, 처음부터 좀 더 잘 생각하고 할 껄”이라고 후회하는 바로 그 결정들입니다. Software architecture 는 또한 바꾸기 어려운 결정들의 집합입니다.  결국 무엇을 중요하게 생각할 것인가, 그것이 Software Architecture 라는 의미입니다. Why is it important? 왜 중요한지 설득하지 못한다면 사실 중요하지 않은 것일지도 모르죠. 그래서 왜 Software Architecture 이 중요한지 짚어보고자 합니다. 쿠팡은 Microservice architecture 로 전환하는 여정을 글로 남겼는데요. 블로그 글의 제목을 “행복을 찾기 위한 우리의 여정” 이라고 지었습니다. (좋은 글이니 읽어보시길!) 다시 말해서, Software Architecture는 개발가자 더 좋은 제품을 만들 수 있는 길이기 때문에 중요하다고 말합니다. 그러나 좋은 Software Architecture를 만드는 일은 쉽지 않습니다. 블로그 글을 인용 해보겠습니다: “여기 저렴한 제품과 비싼 제품이 있습니다. 비싼 제품은 software architecture 가 잘 고려되어 있고, 저렴한 제품은 시스템 디자인에 대한 고민 없이 구현되어 있습니다. 하지만 두 제품은 겉으로 보기에 차이가 없습니다. 소비자가 보기에 똑같이 보이고, 똑같은 기능이 있으며, 성능 또한 같습니다. 어떤 제품을 사야할까요?” 소비자는 제품을 만든 개발자의 행복을 위해 더 비싼 제품을 선택하지는 않습니다. 개발자 역시 동료들에게 “내가 행복하려면 시간과 돈이 좀 더 들더라도 좋은 software architecture 를 구성해야 해.” 라고 주장하기엔 설득력이 부족하죠. Software architecture 가 왜 중요한지 모두가 공감하려면 경제적인 입장에서 그 중요성을 설득해야 합니다. “내부 품질을 좀 포기하더라도 이번 릴리즈에 더 많은 기능들이 들어가야 해.” 라는 의견에 “안돼 우리(개발자)는 더 전문적으로 구성해야 해.”라는 의견으로 대응하면 항상 질 수 밖에 없습니다. 장인 정신과 경제 논리 사이의 싸움에서는 경제 논리가 항상 이겨왔거든요.   Cumulative functionality over Time Software architecture 를 고려하지 않으면서 제품을 개발하면 초기에는 기능 추가 속도가 빠를 수 있지만, 시간이 흐름에 따라 제품의 기능 증가 속도는 점차 느려집니다. 이미 구현된 기능들과 코드가 새로운 기능을 추가하는데 걸림돌이 되기 때문입니다. 한편, 좋은 설계를 지속적으로 건강하게 유지하고, 주기적으로 리팩토링을 하고, 코드를 깨끗하게 유지한다면 시간이 흘러도 기능 추가가 느려지지 않을 수 있습니다. 오히려 기능을 추가하기 위해 수정해야 할 곳들이 명확하고 모듈화 또한 잘 되어있기 때문에 시간이 갈 수록 기능 추가가 더욱 빠르게 진행될 수 있습니다. 새로운 개발자가 참여하는 시점에도 시스템을 더욱 빠르게 이해하고, 더 빠르고 안전하게 기능을 추가할 수 있게 됩니다. 결국 장기적으로 더 많은 기능을 생산하고 빠르게 고객에게 전달하기 위해서 개발팀은 좋은 디자인과 설계에 대해 깊게 고민해야 합니다. What is the best software architecture? 옳은 software architecture 는 없습니다. 상황에 따라 해답은 다를 수 있습니다. Microservice architecture 가 좋다고 해서 모든 것에 대한 답이 microservice architecture 인 것은 아니고, 마찬가지로 어떤 시스템이 monolithic architecture 로 구현되어 있다고 해서 뒤쳐져 있는 것도 아닙니다. 모든 선택에는 Tradeoff 가 있기 마련이니까요. 유선 통신 시스템을 구성한다고 생각해 볼까요? 우리 나라처럼 인터넷이 잘 구성된 상황에서 Skype 로 할 수 있는 통화는 무료이고, 품질도 좋고, 영상 통화까지 됩니다. “Skype 만세! 인터넷을 통한 통신이 항상 옳습니다!” 라고 외치려던 시점에 정전이 되었습니다. 방금 외친 외침은 멀리 가봐야 옆집 정도 닿겠죠. 한편 기존 유선 전화 시스템은 느리고 화상 통화도 안되지만, 전화선 자체에 전원이 공급되고 있기 때문에 정전 시에도 통화가 가능합니다. 전쟁 상황이나 기타 재난 등에도 반드시 통신이 가능해야 하는 곳은 유선 전화 시스템이 꼭 필요할 것 같습니다. 은행 시스템도 적절한 예시가 될 수 있습니다. 비밀번호 입력, 전화 인증, OTP 확인하는 등 은행 업무는 왜이리도 복잡할까요? 그냥 비밀번호 기억해주고 로그인 유지해주면 참 편할텐데 말이죠. 안전하기 위해서겠죠. 여러분의 자산은 소중하니까요. 사용성(Usability)과 안전성(Security)은 종종 둘 사이를 조절해야 하는 Tradeoff 입니다. 만들려는 제품과 시스템, 환경, 시기와 조건 등에 따라서 적절한 architecture 는 달라집니다. 좋은 architecture 를 선택할때 개발자는 선택한 것의 대척점에 있는 무언가를 포기 해야합니다. 그렇기에 software architecture 는 기술적인 범주 안에서만 고려되면 안되고, 구현하고자 하는 비지니스를 매우 잘 이해하고 고려해서 적용해야 합니다. What are you going to do? 이미 구성된 software architecture 를 변경하는 것은 굉장히 어렵습니다. 이미 구성되어 있는 것들을 상세하게 알고 있어야 하고, 비지니스의 요구 사항을 수용해야 하며, 이미 존재하는 기능이 변경 도중 문제 없이 동작해야 합니다. 또한 기존 시스템에 기여한 개발자들과 변경 사항에 대한 공감대를 이뤄야 하며, 겉으로 보기에 당장 변화가 없는 것에 대한 비용에 대해 많은 사람들을 설득해야 합니다. 최근 Buzzvil 에서는 Architecture Task Force 팀을 구성하였습니다. 이를 통해 전체적인 설계를 정비하고 모든 개발팀이 구조적으로 같은 이해를 할 수 있도록 분석, 조사, 계획 수립, 실행에 옮길 예정입니다. 지속적인 공유를 통해 전사적인 공감대를 유지하고 체계적인 문서화와 가이드라인을 통해 모든 팀원이 함께 실행하며 성장할 수 있는 기반을 준비하게 될 것입니다. 궁극적으로 전사 프로젝트와 모든 팀이 더욱 빨리 움직일 수 있는 software architecture 를 구성하고, 이를 통해 더 많은 기능을 더 빠르게 전달할 수 있게 할 것입니다. 아직 해야할 일들이 많이 남아있지만 제대로 계획하고 빠르게 움직인다면 충분히 좋은 결과를 만들 수 있을 것 같습니다. 당장은 눈에 보이는 변화가 없을지라도, 좋은 디자인에 대한 고민과 실행이 우리가 궁극적으로 바라는 비전과 목표에 한 걸음 더 빠르게 다가가는 올바른 길이라고 믿습니다.   *버즈빌에서 개발자를 채용 중입니다. (전문연구요원 포함)작가소개 Whale, Chief Architect “Keep calm and dream on.”
조회수 5564

AWS Instance Scheduler Bot 적용기

이 포스팅은 총 2부로 이어지며 현재는 2부입니다.1부 : AWS 비용 얼마까지 줄여봤니?2부 : AWS Instance Scheduler Bot 적용기1부에서 AWS 비용을 절감하기 위한 Instance Scheduler에 대한 소개를 하였습니다. 2부에서는 Instance Scheduler의 설정을 손쉽게 변경하기 위한 Bot을 적용한 사례에 대해서 소개합니다.Bot의 필요성Instance Scheduler의 설정을 변경하기 위해서는 정보를 담고 있는 Dynamo DB 의 데이터를 변경해야 합니다. AWS Console을 이용하여 직접 수정할 수도 있지만 여전히 불편하고 느립니다. 더군다나 이를 이용하는 사용자가 DB Table의 구조와 AWS Console 사용법을 알고 있어야 하고 비 개발자라면 더 쉽지 않은 문제입니다. 하지만 Bot을 이용하면 사용자는 어려운 DB Query나 구조를 알아야 할 필요도 없고 손쉽게 채팅 메시지를 통해 Bot에게 질의하고 처리 결과를 응답받을 수 있습니다.Outgoing WebhookJANDI에서는 Incoming Webhook과 반대되는 개념으로 Outgoing Webhook을 제공합니다. 특정 키워드로 시작하는 메시지가 있을 경우 내용을 설정된 URL Endpoint에 POST로 Webhook을 보내줍니다. Webhook을 수신한 곳에서는 일련의 처리 후 메시지 데이터 형식을 맞춰 응답하게 되면 채팅창에 메시지를 표시하게 됩니다. 이를 통해 다른 외부 시스템과 연동할 수 있습니다.POST Data예를 들어 날씨 키워드로 Outgoing Webhook을 생성했다면 /날씨 메시지가 시작될 때 다음과 같은 데이터가 Webhook으로 발송됩니다.{ "token": "YE1ronbbuoZkq7h3J5KMI4Tn", "teamName": "Toss Lab, Inc.", "roomName": "토스랩 코리아", "writerName": "Gloria", "text": "/날씨 서울", "keyword": "날씨", "createdAt": "2017-07-19T14:49:11.266Z" } token을 이용하여 요청의 유효성 체크를 할 수 있고 text를 적절히 파싱 하여 요청에 부합하는 처리를 할 수 있습니다.ResponsePOST Data를 적절히 처리 후 결과를 채팅창에 응답 메시지를 표시하고 싶다면 아래와 같은 JSON Data를 Response body에 넣어주면 됩니다.{ "body" : "서울의 현재 날씨", "connectColor" : "#FAC11B", "connectInfo" : [{ "title" : "온도", "description" : "최고:28.00, 최저:24.00, 현재: 24.30" }, { "title": "날씨", "description": "흐리고 비" }] } 이를 이용하여 Instance Scheduler에도 적용해봤습니다.Schedule BotSchedule Bot은 Instance Scheduler의 Lambda 함수에 함께 포함되어 작동하며 스케쥴 조회 / 예외 설정, 서버 강제 시작/중지, 서버 상태 조회 등의 기능을 수행합니다.API Gateway와 Lambda 함수를 연결하여 Endpoint URL을 생성하고 Outgoing Webhook URL로 설정하여 Webhook으로 Lambda 함수가 실행될 수 있도록 하였습니다. Lambda 함수는 Cloudwatch를 통해서 실행되면 Scheduler가 작동되고 API Gateway를 통해 실행되면 Schedule Bot이 작동됩니다.Schedule Bot 명령어Schedule Bot은 다음과 같은 명령어를 수행합니다./서버 help : 도움말 /서버 [스케쥴명] status : 현재 서버 상태 조회 /서버 [스케쥴명] info : 오늘의 스케쥴 조회 /서버 [스케쥴명] info [YYYY-MM-DD] : 특정일 스케쥴 조회 /서버 [스케쥴명] exception info : 오늘의 스케쥴 예외 조회 /서버 [스케쥴명] exception info [YYYY-MM-DD] : 특정일 스케쥴 예외 조회 /서버 [스케쥴명] exception set [YYYY-MM-DD] [start|stop] [h:m] : 예외 설정 /서버 [스케쥴명] exception del [YYYY-MM-DD] [start|stop] : 예외 삭제 /서버 [스케쥴명] force_start : 서버 강제 실행 /서버 [스케쥴명] force_stop : 서버 강제 중지 Schedule Bot 작동 화면Schedule Bot은 서버병이라는 컨셉으로 인격화(?)에 힘썼습니다.스케쥴 정보 조회서버 상태 조회서버 강제 시작/중지명령어 오류마무리AWS 기반의 서비스를 운영하는 스타트업이라면 더욱더 현실적으로 부딪히는 비용 문제에 대해서 저희가 고민한 내용과 솔루션에 대해서 공유하였습니다.아직 적용기간이 길지 않아 절감비용에 대해 수치적인 데이터를 언급하기는 힘들지만 많은 금액이 절감될 거라 예상하고 있습니다.저희와 같은 고민을 하고 있다면 Instance Scheduler를 적극 권장합니다.#토스랩 #잔디 #JANDI #개발 #개발자 #AWS #도입후기 #일지 #인사이트 #경험공유
조회수 1098

자바스크립트 기초 문법 정리 Part 3

함수와 이벤트에 대한 내용이 이렇게 간략할지 몰라 따로 파트를 나누어 포스팅을 진행하였는데 불필요한 나눔이 되었네요. 하지만 곧 더 간략하고 직관적으로 볼 수 있도록 기초 문법 총 정리 포스팅을 하도록 하겠습니다. 혹여 참고 문서로 본 포스팅을 보시는 분들은 곧 올라오는 총정리 포스팅을 참고하시면 좋을 것 같습니다.함수function 함수명() {    실행문;    return 데이터;}참조 변수 = function() {    실행문;}function 함수명() {(매개 변수1, 매개 변수2)    실행문;}   이벤트<button id="btn" onclikc="alert('event!')">버튼></button>이벤트 종류onmouseover - 마우스가 지정한 요소에 올라갔을 때 발생.onmouseout - 마우스가 지정한 요소에 벗어났을 때 발생.onmousemove - 마우스가 지정한 요소를 클릭했을 때 발생.ondvlclick - 마우스가 지정한 요소를 연속 두 번 클릭했을 때 발생.onkeypress - 지정한 요소에서 키보드가 눌렸을 때 발생.onkeydown - 지정한 요소에서 키보드를 눌렀을 때 발생.onkeyup - 지정한 요소에서 키보드를 눌렀다 떼었을 때 발생.onfocus - 지정한 요소에 포커스가 갔을 때 발생.onblur - 지정한 요소에 포커스가 다른 요소로 이동되어 잃었을 때 발생.onchange - 지정한 요소의 하위 요소를 모두 로딩했을 때 발생.onunload - 문서를 닫거나 다른 문서로 이동했을 때 발생.onsubmit - 폼 요소에 전송 버튼을 눌렀을 때 발생.onreset - 폼 요소에 취소 버튼을 눌렀을 때 발생.onresize - 지정된 요소의 크기가 변경되었을 때 발생.onerror - 문서 객체가 로드되는 동안 문제가 발생되었을 때 발생.참고문헌:Do it! 자바스크립트+제이쿼리 입문 - 정인용JavaScript 튜토리얼 문서 (http://www.w3schools.com/js/default.asp)티스토리 블로그와 동시에 포스팅을 진행하고 있습니다.http://madeitwantit.tistory.com#트레바리 #개발자 #안드로이드 #앱개발 #Node.js #백엔드 #인사이트 #경험공유

기업문화 엿볼 때, 더팀스

로그인

/