전체 피드 목록

사람들이 중독적으로 사용하는 제품/서비스를 만드는것은 모든 PM/마케터의 꿈이다. 생각해보라. 내가 만든 앱을 많은 사람들이 하루에도 수십번씩 사용하고, 지하철 이동중에, 화장실에서, 심지어 회의중에도 틈날때 마다 강박적으로 접속하는 서비스가 바로 내가 만든 제품이라는 생각은 상상만해도 흥분된다. 물론 모바일 게임분야에는 이런 중독성을 띄는 제품들이 도처에 널려있지만, 비 게임 영역에서는 이정도 급의 제품들이 많지 않은게 사실이다. 예를들어 주변에 'LoL에 중독됐다'는 사람은 쉽게 찾을 수 있어도, '카카오톡에 중독됐다'는 사람은 찾기가 쉽지 않다. 그만큼 어떤 서비스에 '중독됐다'는 상태는 아무 제품 영역에서나 달성 가능한 것이 아니라 해당 상태를 달성시키기 위한 특정 조건들이 있는데, 오늘 글에서는 그 2가지 비밀에 관한 이야기를 해볼까 한다.제품/서비스에 중독됐다는 것의 의미일단 특정 사용자가 어떤 제품/서비스에 '중독됐다'는 것의 의미를 명확하게 정의내릴 필요가 있다. 제품의 중독성을 어떻게 측정할 수 있을까? 유저 별 하루 평균 세션수를 측정해서 이게 하루에 20회 이상이면 중독됐다고 말할 수 있는건가? Day 30 리텐션이 60%이상을 꾸준히 유지하고 있으면 제품이 중독적이다 라고 말할 수 있을까? DAU/MAU로 측정되는 Stickiness가 항상 50% 이상을 유지하고 있으면 제품이 중독적인 것인가? (제품의 사용성을 측정하는 다양한 분석 지표에 관한 글은 이 전에 쓴 초기 스타트업의 모바일앱 지표 분석 방법론 글을 참고하도록 하자)물론 위와 같은 다양한 지표로 해당 제품의 중독성을 가늠해 볼 수는 있으나 중독된 상태 자체를 증명해 내지는 못한다. 내 제품을 우리 유저들이 정말 중독적으로 사용하고 있는지를 증명해내기 위해서는 위에 언급한 지표들과 함께 유저의 제품 사용 플로우를 함께 들여다 본 후에 다음 명제를 반드시 분석해야 한다.유저가 내 제품/서비스를 필요할때 접속하는가? 아니면 필요치 않아도 습관적으로 접속하는가?이 두가지를 명확하게 구분하는것은 제품이 중독적인가를 판단하는데 매우 중요하다. 예를 들어보자. 국민 메신저라 불리는 카카오톡의 유저 1명당 일 평균 실행횟수는 2016년 7월 App Ape 리포트 기준 거의 30회에 다다른다고 한다. 페이스북이 일 평균 실행횟수가 Verto Metrics의 2016년 9월 기준 11회 정도라고 하는데 카카오톡의 실행횟수가 월등하게 높은 수치임을 알 수 있다. (물론 두 데이터의 소스가 달라서 직접비교는 어렵다는걸 감안해야 한다.)이런 견지에서 카카오톡은 중독적인 서비스라고 말할 수 있는가? 본인은 그렇지 않다라고 주장하는 이유는 해당 앱 실행이 '습관적으로 접속하는게 아니라 필요에 의해서 접속하는것' 이기 때문이다. 사람들이 카카오톡을 사용하는 패턴을 관찰해 보면 누군가에게 메시지를 보내야 하거나 누군가에게 새로운 메시지 알람이 떴기 때문에 접속을 하지, 틈날때 마다 강박적으로 카카오톡을 먼저 켜서 대화를 탐색하고 메시지를 날리는 사람들은 그리 많지 않을 것이다. 즉, 이런 견지에서 내 제품/서비스가 중독적이다의 정의는 다음과 같이 내릴 수 있다.유저들이 내 제품/서비스를 높은 빈도로, 그리고 습관적으로 사용하고 있다.그렇다면, 이렇게 내 서비스를 습관적으로 사용하게 만드는 서비스들에는 그렇지 않은 제품들과 어떤 차이가 있을까? 이 비밀에 대해 제법 명쾌한 해답을 제시하고 있는 책이 하나 있다. 개인적으로 스타트업 하는 사람들이 무슨 바이블처럼 떠 받들고 있는 피터틸의 '제로투원'보다 백배는 더 도움이 되는 책이라고 생각한다. 바로 니르 이얄 (Nir Eyal)의 '훅 (Hooked)'이라는 책이다.개인적으로 제로투원보다 백배는 도움이 되는 내용이 많이 담겨져 있는 책이라고 생각한다.저자인 니르 이얄이 피터틸 처럼 직접 대규모 스케일업을 이뤄본 스타트업 유경험자는 아니고 오히려 학자에 더 가까운 사람이라 그런지 책의 개념에 나와있는 사례들은 사실 별로 공감되지는 않는다. 다만 해당 책에서 제시하고있는 핵심 개념, 즉 '사람들이 습관적으로 사용하는 제품들이 공통적으로 지니고 있는 속성'에 대해 아주 명쾌한 2가지 개념을 제시하고 있는 부분이 있어서 오늘 글에서 간단히 소개하고자 한다.첫째, 보상을 잘 던지는것 보다 중요한 건 보상을 원하는 열망을 잘 해소시키는 인터페이스를 만드는 것이다심리학 교과서에 단골처럼 출연하는 유명한 실험이 하나 있다. 바로 1940년대에 제임스 올즈 (James Olds)와 피터 밀너(Peter Milner)의 쥐 실험이다. 실험 내용은 다음과 같다.두 사람은 실험용 쥐들의 뇌에 전극을 심었고 이를 통해 쥐들이 대뇌 측좌핵 (nucleus accumben)이라는 조그만 부위에 스스로 약한 전기 자극을 가할 수 있게 했다. 그러자 이 쥐들은 얼마 안가 그런 자극에 중독되고 말았다. 쥐들은 음식과 물을 포기하고 심지어 전기가 흐르는 격자판을 통과해야 하는 고통을 감수하면서까지 자극 전달 레버를 계속 누르려 했다.몇년 후에 같은 내용의 실험을 사람에게도 실시했는데 동일한 수준의 결과가 나왔다. 즉, 두뇌에서 즐거움, 열망등과 같은 감정을 관장하는 중추를 발견한 순간이다. 이 둘의 실험에 의하면 그 뇌의 부분을 자극하는 어떤 기작이 존재하면 사람들이 미쳐서 중독될거라고 쉽게 판단해 버릴 수 있으나, 최근에 실시된 한 실험은 더 중요한 비밀에 관해 밝혀내고 있다.스탠퍼드 대학의 브라이언 넛슨 (Brian Knutson) 교수는 기능자기공명영상 기계를 사용해 사람들이 도박을 할 때 두뇌 혈류량에 나타나는 변화를 측정하는 실험을 실시했다. 실험 참가자들이 도박을 하는 동안 두뇌의 어떤 부위가 점점 활성화되는지를 살펴본 것이다. 그런데 보상 (이 경우, 도박으로 돈을 따는 것)을 받긴 하지만 그것이 기대했던 것일 때는 대뇌 측좌핵이 활성화되지 않는다는 놀라운 사실을 발견했다.위의 연구에서 주지해야 할 점은 바로 '우리의 행동을 유도하는 것은 보상 그 자체에서 느끼는 기분이 아니라 그런 보상에 대한 열망을 완화시키고자 하는 욕구'라는 사실이다. 무슨 말이냐면, 우리가 심리적으로 흥분된 상태를 경험하려면 특정 보상을 받고자 하는 열망이 필요한데, 중요한건 이 열망 자체를 제시하는것 보다 중요한게 열망을 완화시켜주는 인터페이스라는게 핵심이다.예를들어 틴더와 같은 데이팅 앱을 생각해 보자. 틴더 앱에서 우리가 원하는 보상은 명확하다. 바로, '맘에 드는 이성과 연결되는 것' 이다. 앱에서 특정 상대와 매칭되는 순간 그 자체가 우리에게는 보상이 되는 것이다. 그렇다면, 틴더는 그 보상만 계속 제공해 주면 유저들이 앱에 중독성을 띌까? 많은 사람들이 이 보상 자체에만 집중하는 경향이 있는데 더 중요한건 그 보상을 받고자 하는 열망이 해소되는 순간에 있다. 틴더에는 매칭이 되서 서로 대화를 나누는 순간이 바로 그것이다. 유저가 틴더에 계속 중독이 되려면 1) 'It's a Match!' 라는 보상을 주는 기작과 함께 2) 매칭이 되어 그 상대와 대화를 나누게 되어 내가 가지고 있던 열망이 완화되는 인터페이스가 잘 작동해야만 유저의 뇌의 대뇌 측좌핵을 흥분시키는게 가능해 지는 것이다. 즉, 유저가 아무리 매치됐다는 알림을 많이 받아도, 해당 상대와 대화로 연결되는 인터페이스가 잘 작동하지 않는다면 '뭐 매치되도 또 묵묵무답이겠지..' 라고 생각하면서 보상에 대한 열망이 완화되지 않고 스트레스로 쌓이게 되어 중독성을 잃게 되는 것이다.틴더가 중독성을 띄기 위해서는 It's a Match!라는 보상기작 보다 매칭 이후에 대화로 연결되는 보상에 대한 열망을 해소시켜주는 단계가 잘 작동해야 한다.반대로 페이스북의 경우를 보자. 페이스북에서 사람들의 중독성을 자극하는 보상기작은 무엇일까? 바로 이 지구본 아이콘에 버블로 달리는 Notification이다. 페이스북은 당신이 사회적으로 관심받고 있는 존재다 라는 보상을 노티피케이션으로 던져준다. 누군가 내 글에 라이크, 댓글 등을 달때라던지, 내가 단 댓글에 누가 또 댓글을 단다던지, '나'라는 존재에 사람들이 관심을 표현하는 모든 종류의 행동을 다 인터페이스화 해서 노티피케이션이라는 훌륭한 보상기작에 담아놓은 것이다.페이스북 중독의 핵심은 이 노티피케이션의 숫자 그 자체의 보상이 아니라, 바로 이 노티피케이션 숫자를 kill하는 순간, 즉 내 보상의 열망이 해소되는 순간에 있고, 페이스북은 이 인터페이스를 자연스럽게 설계해서 페이스북에 어느정도 시간투자를 하는 유저들이라면 누구나 보상 해소가 자연스럽게 이루어지도록 유도하고 있다.페이스북에 중독되는 마법의 순간은 노티피케이션 아이콘에 버블이 뜨는 순간이 아니라, 그 버블을 kill하면서 대뇌 측좌핵을 자극하는 순간에 있다.따라서, 본인 서비스에 유저들이 중독되게 만들고 싶으면 다음 3가지 개념을 꼭 고민해 봐야 한다. 1) 유저들의 어떤 열망을 자극하고자 하는지, 2) 해당 열망을 어떤 보상의 형태로 제공할 것인디, 그리고 가장 중요한 3) 보상에 대한 열망이 해소되는 인터페이스를 구현하는 것이다.둘째, 보상을 반드시 가변적으로 던져줘야 한다인간의 뇌는 '휴리스틱 (heuristic)'이라는 아주 훌륭한 인터페이스가 있어서 수많은 복잡한 감정이나 결정들을 최대한 효율적으로 처리할 수 있게 만든다. 이게 뭐냐면, 인간의 뇌에는 반복적인 절차나 경험을 그룹화해서 미리 저장해 놓는 인터페이스가 따로 있어서 어떤 일이나 감정이 반복적으로 발생하면 그에 대한 대처 역시 자동적으로 발생하도록 저장해 놔서 해당 자극이 발생할 때 마다 힘들게 사고처리를 하지 않아도 대처가 가능하도록 만들어놓은 아주 효율적인 시스템인 것이다. 직장에서 상사한테 깨질때 마다 습관적으로 담배피러 간다던지, 화장실 표지판의 색깔이 파란색이면 남자화장실, 빨간색이면 여자화장실일거라고 자동적으로 생각하고 파란색으로 들어갔다가 봉변을 당한다던지 하는 류의 행동이 모두 휴리스틱에 기반한 행동들이다.우리가 주목해야 하는 점은 바로 본인 서비스에서 제공하고 있는 보상이 반복적이거나 습관적인 패턴으로 제공이 되고 있으면 유저의 뇌에서는 이 자극을 휴리스틱 인터페이스로 처리할 가능성이 다분히 높아진다는 점이다. 즉, 위의 페이스북의 예시에서 노티피케이션의 버블 숫자가 내가 항상 앱에 접속할 때 마다 같은 숫자로 떠 있다던지, 틴더에서 It's a Match!라는 메시지가 너무 반복되는 패턴으로 뜬다던지 하면, 처음에는 해당 보상에 흥분하던 소비자가 점차 그 흥미를 잃고 해당 자극은 휴리스틱 인터페이스로 처리되어 더이상 대뇌 측좌핵을 자극하지 못하게 되는 것이다.하지만, 해당 보상이 최대한 간헐적으로, 예측하지 못하는 패턴으로 제공되면 오히려 유저가 해당 보상을 얻기 위해 더욱 열정적으로 달려드는 패턴을 보이는 경우가 많은데, 이 심리적 행동을 설명하는 아주 유명한 실험이 있다.1950년대에 스키너 (B.F. Skinner)라는 심리학자가 가변성이 동물의 행동에 미치는 영향에 관한 연구를 실시한 적이 있다. 그는 레버를 누를 때 마다 음식물이 나오도록 특수 제작한 상자 안에 비둘기들을 집어넣었다. 올즈와 밀너의 실험용 쥐와 마찬가지로 비둘기들은 레버를 누르는 것과 음식이 나오는 것 간의 인과관계를 학습했다. 다음 단계에서 스키너는 여기에 가변성을 추가했다. 비둘기가 레버를 건드릴 때 마다 음식물이 나오는 것이 아니라 무작위로 정한 횟수만큼 비둘기가 레버를 건드리면 기계에서 음식물이 나오도록 변화를 가한 것이다. 어떤 때는 레버를 누르면 음식물이 나오지만 또 어떤 때는 나오지 않았다. 스키너는 이런 간헐적 보상이 비둘기가 레버를 두드리는 횟수를 급격히 증가시킨다는 사실을 발견했다. 가변성을 추가하자 그가 의도했던 행동의 수행 빈도가 급증했던 것이다.이 스키너의 실험이 의미가 있는 것은, 보상기작을 최대한 간헐적이고 상대방이 예측하기 불가능한 패턴으로 제공하기 시작하면 해당 유저를 거의 미칠정도의 수준으로 중독시키는게 가능해 진다는걸 암시하고 있기 때문이다. 이걸 페이스북의 예시에 적용해 보자. 페이스북은 게시물 노출 알고리즘의 복잡함과 정교함을 통해 이 부분의 목표를 달성하고 있다. 많은 사람들이 페이스북 노출 알고리즘이 대략 이러이러할 경우 노출 확률이 높아진다 정도의 이야기는 하고 있어도 그 누구도 어떤 인풋과 조건값이 있을때 어떤 노출빈도가 형성되어 내 노티피케이션 버블을 만들어 내는지에 대해 알고 있지 못한다. 따라서 수 많은 유저들이 다양한 종류의 포스팅을 올리고 해당 글에 라이크가 얼마나 달리는지를 중독적으로 쳐다보고 있게 만들며, 언제는 라이크가 마구마구 달릴때도 있고, 또 어떤때는 내 예상보다 훨씬 적게 달릴때도 있게 만듦으로써 보상기작 자체를 간헐적으로 제공하고 있다. 이 간헐적 보상을 통해 페이스북은 해당 보상의 가치를 최대한 끌어올려서 유저로 하여금 레버를 미친듯이 눌러대는 비둘기 마냥 중독적으로 노티피케이션을 쳐다보게 만들고 있는 것이다.지금까지의 내용을 간단히 정리해 보면 다음과 같다.내 제품/서비스가 중독적이게 만들기 위해서는 우선 1) 유저가 내 서비스에서 제공하는 보상을 얻고싶다는 열망을 가지게 만들어야 하고, 2) 보상기작보다 중요한 건 보상을 완화시키고 싶은 열망을 해소시키는 인터페이스를 잘 구축해 놓는 것이며, 3) 보상을 반드시 간헐적으로, 예측 불가능한 패턴으로 던져줘야 한다.니르 이얄의 'Hooked' 책에는 이런 내용 외에도 사람들이 습관적으로 사용하게 만드는 서비스들이 공통적으로 지니고 있는 속성들에 대해 잘 정리되어 있으니 한번 읽어보면 많은 도움이 될 것이다. 다만, 앞서 말한바와 같이 저자가 학구파이다 보니 저자가 제시하고 있는 사례들이 크게 설득력 있진 않아서 다 읽고 나면 뭔가 뜬구름만 잡아대는 교과서같은 느낌을 받을 수도 있다. 하지만, 저자가 제시하는 개념 자체를 잘 이해해서 본인만의 사례, 또는 본인 제품에 대입해서 잘 고민해 본다면, 분명 '제로투원'보다 얻어가는게 백배는 많을거라는 본인의 말에 공감이 갈 것이다.** 본 글은 문돌이 PM의 마케터 따라하기 시리즈 입니다.** 1화 보기 - 초기에 할만한 ASO (앱스토어 최적화) 팁** 2화 보기 - 초보 PM이 알아야 하는 초기 모바일앱 분석 101** 3화 보기 - 스타트업 브랜딩: 내가 보는 나와 너가 보는 나의 일치** 4화 보기 - 홍보영상 직접 제작해서 수백만원 절약해보자** 5화 보기 - 바이럴루프, 중요한건 알겠는데 어떻게 적용할래?** 6화 보기 - 인스타그램 노가다 마케팅 101** 7화 보기 - 문돌이도 간지나는 HTML 이메일좀 보내보자** 8화 보기 - 인스타 마케팅 헛수고를 줄이는 10가지 마케팅 방법론** 9화 보기 - 초기 스타트업의 무료 마케팅 채널** 10화 보기 - 프리미엄병에 걸리지 말자** 11화 보기 - 초기 스타트업의 모바일앱 지표 분석 방법론글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기

지난 1월 말, 새해를 맞아 잔디에 새로운 기능이 업데이트되었습니다. 바로 잔디 커넥트에 관한 내용인데요, 협업에서 많이 쓰이는 몇 가지 외부 서비스를 잔디와 쉽게 연동해서 더욱 효율적인 업무 커뮤니케이션을 할 수 있게 되었습니다. 많은 고객분들이 이번 업데이트를 기다려주신 만큼, 저희 개발팀 또한 기대에 보답하고자 지난 몇 주의 스프린트 동안 열심히 준비했습니다. 이번 글에서는 커넥트 동작 방식을 설명하고 그 개발 과정에서 저희가 겪은 시행착오를 비롯한 여러 값진 경험들을 공유하고자 합니다.Integration? Webhook!연동: [기계] 기계나 장치 따위에서, 한 부분이 움직이면 다른 부분도 함께 잇따라 움직임.앞서 말한 대로 잔디 커넥트는 여러 웹 서비스들과 잔디를 연동할 수 있는 기능입니다. 서로 다른 웹 서비스를 연동하기 위해선 한 서비스 내에서 특정 이벤트가 발생 했을 때 다른 서비스로 해당 이벤트를 알려주는 연결 고리가 필요합니다. 이때 해당 연결 고리 역할을 위해 대표적으로 사용되는 기법이 웹훅(WebHook) 입니다. 웹훅은 user-defined HTTP callbacks, reverse APIs 등으로 불리는데, 간단히 설명하자면 웹 서비스에서 공개한 API가 아닌 사용자가 직접 지정한 주소(URL)로 특정 이벤트가 발생 시 HTTP Request를 보내주는 기법입니다. 예를 들어,새로운 일정이 등록된 경우(Google Calender)요청한 Pull Request가 Merge된 경우(GitHub)카드에 새로운 코멘트가 작성된 경우(Trello)이러한 이벤트가 발생했을 때 사용자가 매번 이벤트가 발생했는지 확인하지 않아도 서비스가 먼저 알려줄 수 있도록 일종의 알림을 등록하는 것이죠. 잔디 커넥트는 이와 같은 특징을 이용해서 각각의 웹 서비스에서 제공하는 웹훅을 잔디의 메시지 형태로 전달하는 기능입니다.일반적으로 웹훅은 이벤트에 대한 알림을 외부로 전달하는 것을 말합니다. 이 부분에서 중요한 것은 전달 방향인데, 서비스 내부에서 외부로 전달하기 때문에 이를 Outgoing Webhook으로 부르기도 합니다1. 같은 맥락에서 반대로 생각해보면 외부에서 서비스 내부로 특정 데이터를 전달하는 경우이니 Incoming Webhook이 됩니다. 앞서 웹훅을 reverse API라고 했는데 이를 다시 뒤집으니 결국 서비스 내부로 통신하는 제한적인 API와 같은 역할을 합니다. 굳이 용어를 구분한 이유는 API와 달리 접근하려는 서비스의 별도 인증 절차를 거치지 않고도 사용자가 생성한 웹훅의 URL을 인증 토큰으로 사용하며 약속된 Request Body 포맷만 알고 있다면 자유롭게 사용할 수 있기 때문입니다.개념 설명이 다소 길어졌지만, 이번 잔디 커넥트 기능에 대해 용어나 개념이 낯설다는 피드백이 생각보다 많았기 때문에 이번 글을 통해 더 많은 분들이 웹훅을 이해하는 데 도움이 될 수 있으면 좋겠습니다.구현에 앞서서비스를 운영한지 1년 정도 지난 시점에서 저희 내부적으로는 백엔드의 기술 스택 변경 및 각 서비스 분리에 대한 갈증이 있었습니다. 하지만 이미 서비스를 운영 중이기 때문에 안정성이 최우선시 되는 만큼 꽤 부담스러운 숙제로 미뤄둘 수밖에 없었고요. 때마침 커넥트 기능은 숙제를 시험해볼 만한 좋은 기회임에는 분명했지만, 새로운 기술 스택을 바로 서비스에 적용하기엔 오히려 개발 효율이 떨어질 것이라는 판단하에 일단 서비스 분리에만 집중하기로 했습니다.기본적으로 API와 DB를 기존 서버와 분리하고 웹훅 데이터를 저장하기 위한 큐와 해당 데이터를 처리하는 배치 서버 또한 모두 기존 서비스와 분리해서 최대한 결합도를 제거했습니다. 이런 설계 덕분에 추후 사업 전략이나 각 국가의 특성에 맞춰 커넥트 기능을 어렵지 않게 포함하거나 제외할 수 있게 되었습니다. 전반적인 저희 잔디 백엔드 아키텍쳐에 대해서는 아직 한 번도 소개 해드린 적이 없으니 다음에 따로 주제로 선정해 집중적으로 다뤄보도록 하겠습니다.동작 방식잔디 커넥트가 동작하는 방식은 기본적으로 다음과 같습니다.Incoming Webhook URL 생성 - 외부 서비스 웹훅 등록 - 웹훅 수신 - 메시지 작성 연동 대상 서비스마다 조금씩 차이가 있지만, 기본적으로 모두 위와 같은 방식으로 동작하기 때문에 단계마다 나누어 설명하겠습니다.1. Webhook URL 생성Webhook URL은 https://wh.jandi.com/connect-api/webhook/{teamId}/{webhook-token}와 같은 형태로 생성됩니다. hostname을 별도로 설정함으로써 기존 API 서버와의 분리는 물론이고, nginx의 Limiting the Request Rate 설정을 이용해서 호출되는 웹훅 요청 수를 효과적으로 제한할 수 있었습니다. webhook-token은 중복을 피하면서 각 웹훅에 대한 유효성을 검증할 수 있도록 여러 키를 조합한 md5 hash 값을 이용했습니다.이렇게 생성된 URL은 Incoming Webhook 뿐만 아니라 Google Calendar 등의 서비스에 등록하는 콜백 URL로 사용합니다.2. 외부 서비스 웹훅 등록웹훅을 등록하는 방법은 서비스에 따라 API를 이용하거나 수동으로 직접 등록할 수 있습니다. 사용자가 직접 웹훅을 등록하는 방법은 웹훅 URL만 생성해서 전달하면 등록 과정의 추가 처리가 필요 없어서 간단하지만, 서비스마다 등록하는 방법이 조금씩 다르고 다소 복잡하게 느껴지는 문제가 있습니다. 반대로 각 서비스에서 제공하는 API를 이용해 웹훅을 등록하면 사용자의 부담을 많이 줄일 수 있지만, 그만큼 내부적으로 처리해야 할 작업이 많아집니다. 그래서 구현 초기에 꽤 많은 시간을 투자할 수밖에 없었고 그 과정에서 아래와 같은 어려움을 겪었습니다.웹훅 관련 API를 사용하려면 먼저 인증을 받아야 하는데 서비스마다 제공하는 인증 방식이 조금씩 달라서 이를 통합하는 모델을 만들기가 쉽지 않았습니다. 요약하자면 기본적으로 accessToken을 사용하지만, 인증 방식에 따라 부가적으로 필요한 데이터가 서로 조금씩 다른것이죠. 가령, 구글캘린더는 만료 일시와 토큰 갱신을 위한 refreshToken 값을 별도로 갖고 있어야 합니다. 또 한가지 놓치기 쉬운 부분은 인증 폐기(revoked) 관련한 데이터 처리인데 저희가 경험한 바로는 인증이 폐기되었을 때 별도로 웹훅 알림을 주지 않기 때문에 반드시 인증의 유효성을 확인하는 추가 로직이 필요합니다.대부분의 사무실이 그렇듯이 저희 또한 공유기를 이용해 내부 네트워크를 구성하고 있습니다. 게다가 백엔드 파트는 개개인의 로컬 가상 서버에 동일한 환경을 설정해놓고 개발을 하므로2보통 경우엔 외부(public network)에서 들어오는 요청을 받을 수 없습니다. 그렇다고 매번 외부 네트워크에 있는 서버에 배포 후 테스트하기가 어려우니, 저희는 각 로컬 서버마다 고유 포트 번호를 나눠 갖고 WAN이 물린 공유기의 포트 포워딩을 알맞게 설정한 뒤에 네트워크 터널링 유틸리티인 ngrok을 이용해 내부와 연결되는 public 주소를 생성해서 외부 서비스와 문제없이 통신할 수 있었습니다.3. 웹훅 수신웹훅을 통해 들어오는 Request는 일단 정상 응답을 하는 게 좋습니다. 서비스마다 최초 웹훅 등록 시 유효한 URL인지 확인하는 테스트 요청을 하는데 이때 정상 응답을 하지 못하면 아예 등록조차 처리되지 않습니다. 또한, 정상적으로 등록된 이후 특정 이벤트에 해당하는 웹훅 요청에 대한 응답에도 주의할 필요가 있는데, 만약 에러 응답이 반복되면 일정 시간 동안 각 서비스에서 아예 해당 웹훅을 발송하지 않도록 제한이 걸려 더 이상 테스트를 진행할 수 없는 경우도 있었습니다.따라서 일단 웹훅 요청이 들어오면 teamId와 webhook-token 값으로 올바른 웹훅인지 검증한 후 서비스별 큐에 Request header와 body를 포함한 데이터를 전달한 뒤 바로 응답하고, 큐에 쌓인 데이터는 커넥트 종류별로 배치 서버가 돌면서 처리하게 됩니다. SQS를 사용함으로써 늘어나는 데이터에 대한 안정성을 확보하고 각각의 배치 서버를 독립적으로 분리해서 구현함으로써 자연스레 확장성(scalability)도 보장할 수 있게 되었습니다.4. 메시지 작성웹훅 데이터를 잔디의 메시지로 변환하는 역할은 배치 서버가 담당합니다. 서비스별로 데이터 포맷이 다르므로 해당 데이터를 파싱 및 처리하는 Worker 또한 각각 구현했습니다. 사실 커넥트 기능에서 가장 핵심적인 역할을 하는 부분인 만큼 가장 많은 공수가 드는 작업이였던 것 같습니다.서비스마다 정해놓은 웹훅 이벤트와 잔디 커넥트에서 제공하고자 하는 알림이 서로 완전히 일치하지 않아서 이를 서로 연결하는 작업연동 서비스의 문서가 잘 정리되어 있지 않아서 일일이 필요한 동작을 취하고 그에 따라 들어오는 데이터를 정리하는 작업잔디 계정 언어에 따라 메시지 L10N3을 적용하는 작업커넥트 메시지를 전달하기 위해 기존 멤버와 다른 커넥트 봇을 구현하는 작업등 요약하기 어려울 정도로 크고 작은 이슈들이 많았습니다. 그 내용이 너무 다양해서 모두 상세히 기록하긴 어렵지만, 개중에 도움이 될만한 내용을 추려서 아래 따로 정리했으니 관심 있으신 분들은 참고하시면 좋을 것 같습니다.서비스별 집중 탐구커넥트 구현 일정을 최대한 앞당기기 위해 저희는 개발자들끼리 각각의 커넥트 종류 별로 전담해서 작업하는 전략을 취했습니다. 제가 대표로 글을 작성하기는 하지만 보다 정확하고 구체적인 정보를 전달하는 것이 좋겠다는 생각에 개발을 담당하신 분들과의 짧은 인터뷰 형식을 빌려 공유하겠습니다.- Google CalendarQ. 기술적으로 난이도가 높았던 작업을 소개해달라.전반적으로 어려운 작업이 있었다기보단, 캘린더 특성상 세세하게 처리할 부분들이 많아 설계와 구현이 어쩔 수 없이 복잡해졌다. 가장 골치 아팠던 작업은 일정 알림을 타임존(Time Zone)에 따라 각각 알맞은 시간에 전달하는 작업인데, “잔디 계정의 타임존”, “구글 캘린더의 타임존”, “개별 일정의 타임존” 이렇게 3가지를 모두 고려해서 경우마다 기준이 되는 타임존을 결정하는게 엄청 까다로웠다. 심지어 구현 후 테스트를 하는 과정에서도 출력된 시간이 올바로 표시된 것인지조차 헷갈려서 디버깅하는데 한참 고생할 수 밖에 없었다.웹훅을 등록하고 관리하는 부분도 꽤 복잡했는데, 구글 답게(?) 웹훅에도 만료 기간이 존재한다는 것이 포인트다. 때문에 만료되기 전에 반드시 재등록 및 과거 웹훅 삭제 작업을 하는데, 효과적으로 처리하기 위해 “웹훅을 받을 때마다 만료 기간을 확인”, “등록된 일정이 많지 않아 웹훅을 받지 못하는 경우도 있으니 별도의 배치서버가 하루 단위로 확인” 이렇게 두 가지 로직을 넣어서 자동으로 웹훅을 유지하도록 구현했다.또한, 다른 연동 서비스와 달리 구글은 웹훅 콜백으로 들어오는 요청에 해당 이벤트에 대한 데이터를 직접 담아주지 않기 때문에 key를 가지고 한 번 더 API 호출을 통해 필요한 데이터를 가져와야 한다는 점도 주의해야 한다. 요청해야 할 API 문서는 비교적 잘 정리된 편이지만, 같은 요청에 대해서도 인자를 어떻게 보내는지에 따라 그 응답이 제각각이기 때문에 응답 값에 대해 무조건 신뢰하고 처리해서는 안 된다. 당연히 존재할 것으로 생각한 필드 값에 빈 배열이 들어와서 일정 관련된 데이터를 일부 날리고 나서야 깨달았다.. -_-Q. 가장 처리해야 할 이슈가 많았다고 알고 있는데, 그중에서도 기억에 남는 이슈가 있을 것 같다.너무 많은 이슈를 동시에 처리하다 보니 특별히 기억에 남는 이슈는 없다. 다만 아직도 왜 그랬는지 확실한 이유는 알 수 없지만, 언젠가 한 번 구글에서 웹훅을 아예 전달해주지 않았던 경우가 있었다. 과도한 요청으로 limit이 걸린 것도 아니었는데, 갑자기 웹훅이 안들어오니깐 우리로서는 어떻게 풀어볼 방법이 없었다. 그러다 나중에 확인해보니 대략 12시간쯤 지나고 나서 그동안 밀려있던 웹훅 데이터가 한 번에 밀려서 들어와 있더라. 다행히 그 이후로 지금까지 한 번도 재현되지 않는걸 보니, 혹 동일한 증상을 겪는다면 당황하지 말고 기다려 보시라.반복 일정을 다루는 것도 꽤 골치 아픈 이슈인데, 왜냐하면 일정이 있을 때 마다 웹훅 알림을 주지 않고 처음 등록된 시점에서 한 번만 정보를 알려주기 때문에 등록된 시점 이후의 일정은 내부적으로 계속 등록해줘야 한다. 기본적으로 구글 캘린더는 RFC-55454 표준을 따르지만, 실제 전달되는 데이터 중 일부는 표준과 조금 다른 부분이 있었다. 특히 반복 일정(recurrence) 관련 데이터 포맷이 조금 다르므로 캘린더 데이터를 파싱하기 위해 만약 외부 library를 사용한다면 별도의 예외처리가 필요하다. 더욱 더 까다로운 건 사실 등록된 반복 일정이 수정되거나 삭제되는 경우인데, 이때 “특정 일정만 삭제”, “지금 시점 이후의 일정 모두 수정” 등 워낙 케이스도 많고 각각을 테스트 하는 것도 쉽지 않기 때문에 작업 시간이 꽤 오래 걸렸다. (심지어 아직 확인하지 못한 드문 케이스에서는 잠재된 버그가 있을 수도…)Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?구글 캘린더 API는 Webhook 보단 Push Notification 키워드를 많이 사용한다. 푸시 노티라는 게 좀 다른 카테고리에서 많이 쓰이는 용어이기도 하다 보니 코드 리뷰 등의 커뮤니케이션을 할 때 혼동이 좀 있었던 것 같다.물론 서비스 요구사항마다 다르겠지만, 잔디 같은 경우엔 요구사항에 맞춰 계속 설계를 변경 및 개선하다 보니 결과적으로 너무 복잡해져 효율이 떨어지는 코드를 작성할 수밖에 없었다. 처음부터 연동을 생각하기보다는 아예 캘린더 자체 기능을 베이스로 설계하고 데이터만 구글에서 가져온다 생각했다면 개발 생산성이 더욱 좋았을 것 같다.- TrelloQ. 기능을 구현하면서 느낀 아쉬웠던 점과 좋았던 점을 짚어달라.트렐로 공식 API 문서가 더 명확했다면 좀 더 개발이 수월했을 것이다. 문서가 RESTful하게 end-point path는 간결하게 잘 정돈되어 있지만, 각 요청 parameter에 대한 설명이나 response 데이터 등이 명확하게 정리되지 않아서 적합한 API를 찾거나 불명확함을 걷어내기 위한 테스트를 하다 보니 전반적으로 시간이 길어지고 비효율적이었던것 같다.그에 반해 트렐로에서 웹훅 이벤트를 발생시키기 위한 유저 액션들이 비교적 간단하고, 그에 따른 콜백 리퀘스트 또한 누락 없이 빠르게 잘 들어와서 그나마 쉽게 테스트를 할 수 있었다.Q. 기능 구현을 위해선 반드시 알아야 할 웹훅 이벤트 종류 및 데이터에 대한 문서는 정리가 전혀 안 되어있다고 하던데 정말인가?그렇다. 처음엔 좀 당황했지만, 그래도 방법이 없으니 일일이 경우마다 테스트해보면서 직접 정리를 하려고 했다. 하지만 각 웹훅마다 큰 구분만 있고 세세한 데이터는 너무 다양해서 깔끔하게 정리하기가 어려워 따로 공유를 위한 문서를 만들지는 못했다. 예를 들자면 트렐로에서 updateCard 라는 action type의 웹훅 데이터를 보내주는데, 그 데이터만 보고 “Card Archive”, “Description 수정/삭제”, “Due date 등록/수정”, “카드 이동” 등의 여러 가지 서로 다른 이벤트를 구분해야 한다. 근데 그 구분하는 방법이 특정 flag가 있는 게 아니라서 각 data를 모아놓고 역으로 분리하다 보니 코드를 깔끔하게 작성하기가 어려움은 물론, 추후 트렐로 측 데이터의 변동이 있을 때의 품질을 보장할 수 없는 리스크를 안고 구현할 수밖에 없었다.Q. 그 밖의 도움이 될만한 노하우나 꿀팁이 있다면?만약 트렐로와 어떤 형태로든 연동하려고 한다면, 설계 전에 모든 API에 대해 꼼꼼히 살펴보고 웹훅 이벤트 또한 직접 테스트해서 일단 전체적으로 리스트업을 정리하는 게 보다 생산성에 도움이 될 것이다. 트렐로를 잘 알고 있더라도 서비스 내부에서 “보드”, “리스트”, “카드”가 어떤 상관관계를 가지는지 미리 정리해보는 것도 좋다.사소하지만 좀 특이했던 점은 웹훅을 처음 등록할 때 해당 URL로 확인 요청을 한번 하는데, 이때 요청은 HTTP method가 POST가 아닌 HEAD로 들어온다. 그래서 반드시 동일한 URL의 HEAD 요청에 대해서도 정상 응답을 할 수 있도록 구현해야 한다.마무리잔디 커넥트를 구현하면서 특히 서비스 품질과 개발 속도 간의 밸런스에 대한 고민을 많이 했습니다. 초반에 서비스 종류별로 작업을 분리하고 각각의 방식으로 설계한 뒤 나중에 정리하는 전략이다 보니 공통으로 가져갈 수 있는 DB 모델이나 서비스 로직이 많아서 이를 통합하기 위해 반복 작업을 할 수밖에 없었는데 이 부분이 저희 내부적으로 느낀 가장 아쉬운 부분이 아니었나 생각합니다. 기능 중 많은 부분이 외부 서비스에 의존적이다 보니 생각하지도 못한 크고 작은 이슈들이 발생해서 일정 산출에도 꽤 어려움을 겪었습니다.커넥트 기능을 출시한 이후로 꽤 시간이 지났음에도 불구하고 이슈 백로그(Backlog)를 보니 아직도 개선할 부분이 많이 남아있는 듯 합니다. 그렇지만 이번에 기반이 되는 작업을 최대한 튼튼히 하기 위한 많은 시행착오를 거쳤기에, 추후 연동되는 커넥트 종류를 늘려나가는 시점5에 보다 효과적으로 개발할 수 있을 것이라 기대하면서 이번 글을 마치겠습니다.Slack API 문서 참고 ↩vagrant의 box로 서로의 로컬 개발 환경을 동일하게 유지하고 있습니다. 참고로, 현재 저희 서버 환경은 Local - Dev - Staging - Production으로 구성되어 단계별로 상황에 알맞게 배포하고 있습니다. ↩Localization의 약어. 잔디는 아시아 시장에 최적화된 서비스를 제공하고자 한국어, 일본어, 중국어 간체자(중국), 번체자(대만/홍콩), 영어 총 5가지 언어를 지원합니다. ↩아이캘린더(iCalendar)로 불리는 인터넷 캘린더의 데이터 포맷에 관한 표준. IETF 문서참고 ↩구체적인 시점은 말씀드리기 어렵지만, 더욱 좋은 사용성을 제공하고자 유저분들의 설문조사를 진행하고 있으니 많은 참여 부탁드립니다. ↩#토스랩 #잔디 #JANDI #개발후기 #일지 #인사이트

스토리 홈

인터뷰

피드

뉴스

Node.js 이해하기

일본 스타트업 적응기#6 「어려움」

사업엔 정답이 없다

덕업일치를 이룬 옐로오투오 로컬사업부 신입왕, 이휘재 매니저

중독적인 서비스의 2가지 비밀

안드로이드와 자동화 툴

[제일 컬처] 마법사, 빗자루, 촛불… 그리고 #입사식

iOS 개발을 위한 11가지 노하우

게임은 마약이 아니라 약이다

JANDI CONNECT 개발기

영화관에서 ‘치킨’ 어때요? CJ CGV F&B사업팀 이홍철 님

[개발] 개발자는 왜 체크남방을 입는가?

당신이 놓치고 있던, 측정 항목 : Dwell Time

IR자료 작성을 위한 소소한 팁

아마존 리스팅 최적화에 대한 고찰

문돌이가 개발자랑 일할만큼만 프로그래밍 익히기