카테고리 보관물: 기술

왜 레진코믹스는 구글 앱 엔진을 선택했나

프리미엄 웹툰 서비스, 레진코믹스는 2013년 6월에 오픈했다. 이후 사용자는 꾸준히 늘고 있고, 고화질로 서비스되는 만화의 양도 어마어마해지고 있다! 간단해 보이지만 “적은 인원으로, 서비스를 빠르게 시작하면서도 늘어나는 트래픽을 안정적으로 처리해야” 하는 자그마치 3개의 조건이 합쳐진 컴비..미션…;

스타트업인 우리에게는 구글 앱 엔진이 해결책이었다.

아직 서비스는 개선할 사항이 정말 많고, 가야할 길이 한참 멀었지만 사용기를 공유하기로 했다. 아마존을 사용하여 서비스를 구축한 사례들은 많이 나오고 있는데 앱엔진은 별로 공유가 안되는 것 같다. 누군가가 서비스를 시작한다면 앱엔진을 고려해보면 좋겠고, 혹시나 내가 처음에 겪은 것들이 마찬가지로 어렵다면 조금이나마 도움이 되면 좋겠다.

그런 생각을 하던 차에 GDG Seoul(구글개발자그룹) 정기 Meetup에 기회를 얻어 발표한 슬라이드이다. 주 대상은 앱엔진을 아는데 실제 서비스는 안해보신 분들이다. 앞에서는 ‘왜 레진코믹스는 구글 앱엔진을 선택했나’ 에 대해서 정리했다. 뒷 부분은 사용하고 있는 기능들 중심으로 알아두면 좋을 것들을 설명했는데, 슬라이드만 봐서는 이게 뭔가 싶을 것 같다. 좀 더 풀어내는 글은 따로 정리하려고 한다. 🙂

광고

아마존의 제품 개발 방법 Working Backwards

헉 이게 아니었는데 달리다보니 너무 멀리왔어 @.@

나폴레옹의 잘 알려진 일화가 있다.
알프스산맥의 거친 눈보라를 뚫고 백만대군의 절반을 잃으며 드디어 정상에 올랐는데 나폴레옹이 말했다.
“이 산이 아닌가봐” 두둥…
그래서 내려와 병사들을 다독여 다른 산에 겨우 올랐는데 그가 또 입을 열었다.
“아까 저 산이네”
…ㅠ.ㅠ
그러자 부하들이 “저 놈은 나폴레옹이 아니네” 라고 했다는~ (?)

방향의 중요성을 나타내는 이야기이다. 🙂

회사, 팀 또는 개인들은 각자가 만드는 가치를 사용자에게 전하기 위해 여러 노력을 기울인다. 그런데 중간중간 ‘이거 좋을 것 같아!’ 라는 기능이 있어서 살을 붙이고, 혹은 안붙이고, 여러 피드백과 상황에 따른 판단들을 반영하다보면 길을 잃거나 생각한 것과 달리 멀리 돌아가기도 한다. 나폴레옹 이야기처럼 끔찍한 상황은 아니겠지만 말이다. 😉 만들어나가는 단계들이 어디를 향해 있는지, 과연 가치에 집중하여 제대로 가고 있는가 확인하는 것은 매우 중요하다. 뚝딱뚝딱 또는 우당탕탕하며 만들어진 제품과 가치는 최종적으로 사용자, 고객에게 전달되게 된다.

아마존은 그 고객에 주목하여 시작한다. 🙂
이름하여 Working Backwards, 아마존의 제품 개발 방법론이다.
이것은 바로 고객으로부터 시작해서 거슬러 올라가는 작업을 말한다.

이하는 트윗에 링크된 아래 두 페이지의 내용의 일부를 섞어 번역한 것이다:


고객부터 시작하여 거꾸로 작업하기

아마존에는 널리 사용되는 “Working Backwards” 라 불리는 접근방식이 있다.
제품에 대한 아이디어로 시작해서 고객들을 그것에 고정시키는 것이 아니라, 고객으로부터 시작해서 거슬러 올라가는 작업을 말한다. 어느 경우에나 적용할 수 있지만, 이 접근은 특히 새 제품이나 기능을 개발할 때 중요하다.

1. 보도자료 작성

먼저 PM은 완성된(될) 제품에 대한 내부 보도자료를 작성하는 것으로 시작한다. 이 보도자료의 대상 독자는 새로 업데이트된 제품을 구매할 고객 또는 툴과 기술에 대한 내부 고객일 수 있다. 보도자료는 제품이 무엇이고 왜 이러한 제품이 있는지, 다시 말해 기능들은 무엇이고 이점은 무엇인지를 간단하게 설명해야 한다. 고객이 가진 문제와 함께 현재 나와있는 솔루션들이 어떻게 실패했는지 말하면서, 새 제품은 기존 제품을 어떻게 대체할 것인지의 내용에 주안점을 둔다. 매우 명확해야 하고 요점을 짚어야 한다. 보도자료를 작성하는 것은 이 제품에 대해 내부적으로 어떻게 생각하고 있는 것이 아닌, 세상 사람들이 그 제품을 어떻게 볼지를 명백하게 한다. 나열된 제품의 강점들이 별로 매력적이지 않다면 고객들은 설치하지 않을 것이다. PM은 그 이점들이 정말 타당하다고 생각될 때까지 보도자료를 반복 수정해야 한다. 이것은 제품 자체를 반복 개발하는 것보다 비용이 훨씬 적게 들고 더 빠르다!

다음은 보도자료 개요의 예이다:

  • 제목 – 독자(대상 고객)가 이해할 방법으로의 제품을 명명한다.
  • 부제 – 상품에 대한 수요자가 누구이고, 그들이 얻을 혜택을 설명한다. 타이틀 아래에 오직 한 문장으로만 한다.
  • 요약 – 제품과 그 혜택을 요약한다. 독자가 다른건 읽지 않을 것이라 가정해서 문장을 잘 만들어야 한다.
  • 문제점 – 제품이 해결한 문제를 설명한다.
  • 해결법 – 그 문제를 어떻게 멋지게 풀어냈는지 설명한다.
  • 인용 – 회사 대변인으로부터의 인용문을 넣는다.
  • 시작하기 – 시작하기 쉽다는 것을 설명한다.
  • 고객 인용 – 가상 고객이 어떤 혜택을 경험했는지 표현하는 인용을 제공한다.
  • 맺음말과 해야할 것 – 정리 후, 독자가 다음에 해야 할 포인터를 준다.

보도자료는 한장 정도로 작성하고, 문단마다 3-4 문장으로 제한하며 과한 부분은 잘라내야 한다. 명세서를 쓰는 것이 아니다. 보도자료로는 고객이 얻는 것에 집중하도록 하고 다른 비즈니스 및 실행에 대한 내용은 FAQ를 붙일 수 있다.

“Oprah-speak” (오프라 윈프리 쇼) 식으로 보도자료를 작성한다. 소파에 앉아 오프라에게 제품을 설명하고나서 그녀가 청중들에게 그것을 설명하는 것을 듣는다고 상상해보자. 이것은 “Oprah-speak” 이지, “Geek-speak” 이 아니다.

프로젝트가 개발 단계로 가면 이 보도자료는 시금석과 등대가 될 수 있다. 팀은 스스로에게 “우리가 이 보도자료에 있는 것을 만들고 있나?” 라는 질문을 던질 수 있다. 만일 보도자료에 없는 것을 (또는 지나친 것을) 만드는데 시간을 쓰고 있다면 왜 그런지 물어봐야할 것이다. 이것은 제품 개발이 고객에게 강점을 가져다 주는 것에 집중하도록 하고 관계없는 것은 더 이상 하지 않도록 한다.

2. FAQ 문서 작성

보도자료를 통해 제공되는 뼈대에 살을 붙일 수 있는 곳이다. 이것은 보도자료를 공개했을 때 받을 질문들과 이것이 왜 좋은지 명시하는 내용을 포함한다. 사용자의 입장에 서서 받을 수 있는 모든 질문들을 고려해봐라.

3. 고객 경험을 정의

제품으로 하게 될 여러가지에 대한 고객 경험을 세밀한 항목들로 설명한다. 사용자 인터페이스 경우 각 화면에 대한 목업을 만들 수 있다. 웹 서비스 경우는 사용자들이 어떻게 사용할지에 대한 유스케이스를 코드 스니펫을 포함하여 작성한다. 이것의 목적은 사용자가 이 제품으로 어떻게 그들의 문제를 풀어냈는지에 대해 스토리를 말하는 것에 있다.

4. 사용자 설명서 작성

사용자 설명서는 제품이 어떤 것이고 어떻게 써야하는지에 대해 정말 알기 위해 사용하는 것이다. 사용자 설명서는 일반적으로 컨셉, 사용법, 레퍼런스의 세 섹션으로 나뉘며 그 안에는 제품을 사용하기 위해 알아야만 하는 모든 것이 들어간다. 사용자 타입이 하나 이상이라면, 하나 이상의 사용자 설명서를 쓴다.

이 프로세스를 따르는 것은 concept-to-delivery (브레인스토밍, 토론, 논쟁) 주기를 놀랍도록 줄였다. 왜냐하면 팀과 관계자들이 제품의 결국 보여질 모습을 보는 것보다 일찍 동의했기 때문이다.
이 프로세스는 사용자들을 중심에 두고, 프로세스에 걸쳐 간결함과 명확함을 이끈다. 고객에서 시작해서 거꾸로 작업하는 것은 효과적이며 사용자를 제 위치에 있게 하는 매우 효율적인 프로세스이다.


보도자료 작성 예

아래는 현재 베타 서비스되고 있는 Veckon 을 예로 하여 보도자료를 작성해본 것이다.

스타트업 Veckon, 웹 기반 화상통신 서비스 ‘Veckon’ 출시

누구나 바로, 다중 화상통신을 가장 쉽게 할 수 있는 방법

국내 주목받는 스타트업인 Veckon 은 업계 최초로 가입단계 없는 웹 기반 비디오 커뮤니케이션 ‘Veckon (http://www.veckon.com)’ 서비스를 12일 베타 오픈했다.
Veckon 은 별도의 설치과정 없이 누구나 바로 간편하게 무료로 화상통신할 수 있는 서비스이다.

다양한 화상통신 서비스가 이미 마켓에 있지만, 상대방과 동일한 기기나 앱이 있어야하며 서로 간에 확인 후에야 가능하다. 또한 반드시 가입절차를 거쳐야 할 뿐더러 사용법을 익혀야해서 바로 사용하기엔 번거롭다.

Veckon 은 가입절차가 없어 매우 간편하며, 누구든지, 웹브라우저가 있으면 언제 어디서나 사용할 수 있다. 사이트의 시작버튼을 누르기만하면 채팅방이 바로 개설되며, 생성된 URL 주소를 단지 상대방과 공유하기만 하면 된다. 해당 URL로 접속하는 누구나 통신할 수 있기 때문에 그룹 채팅도 가능하며, 원거리 화상회의에 매우 유용하다. WebRTC (Web Real-Time Communication) 기술이 지원되는 웹브라우저이어야 하며 현재는 Chrome, Chrome mobile(Android), Firefox 가 해당된다.

Veckon 의 메인 개발자인 이원제 CTO는 이날 서울 선릉 D.CAMP에서 열린 간담회에서 “다양한 의사소통 수단 중 보고 말하는 방법은 굉장히 강력함에도 불구하고 정작 화상통신과 회의는 아직 미성숙한 시장과 문화에 머물러 있다”며, “사용자들이 더욱 쉽고 간편하게 웹을 통해서 화상통신을 하고, On/Offline의 경계를 이어 진심이 담긴 소통이 이루어지도록 서비스를 개선해 나가겠다”고 말했다.

Veckon 서비스는 홈페이지(http://www.veckon.com)를 통해 회원가입없이 바로 사용할 수 있다.

베타 서비스의 사용자인 김ㅇㅇ 성형외과 원장은 “성형 상담시 굳이 병원에 직접 방문하지 않아도 되고 가입이 필요없어 환자들의 부담을 덜게 되었다”며, “웹을 통한 고화질 화상회의라는 점이 중국 등의 해외 환자들과 쉽게 연결해주어 환자들과 병원관계자 모두 만족스러워 하고 있다”라고 말했다.

Veckon 의 가입없는 웹 서비스라는 특징에서 앞으로 화상통신이 개인만이 아니라 비즈니스 등으로 어떻게 확장할 수 있을지 귀추가 주목된다. Veckon 은 홈페이지(http://www.veckon.com)에서 베타 서비스를 시작했으며 블로그(http://blog.veckon.com)도 함께 운영중이다. 문의사항은 트위터(@veckoninc)와 페이스북 페이지(http://www.facebook.com/Veckon)를 활용하면 된다.[/dropshadowbox]

정리

얼마 전에 읽은 책인 인생학교 – 일 에서는 드라마틱하긴 하지만 자신의 부고 기사를 써보는 것이 어떠하냐고 권한다. 훗날 인생을 돌아봤을 때 내가 한 일이나 했으면 좋았을 것 같은 일들을 써보는 것은 뒤늦게 후회하지 않게 하는 놀랍고도 효과적인 방법이라고 말한다. Working Backwards 도 비슷한 맥락이라고 생각한다. 🙂
전에 서비스 초기 기획 단계에 보도자료를 작성해서 내부 관계자분들께 피드백을 받은 경험이 있다. ‘이런거 하려고 해요!’ 를 설명하기에 좋았다. 할 수 있는 한 빨리 피드백을 받으라는 애자일 모델링 원칙에도 맞는다. 방법론에 대한 무조건적인 적용은 좋지 않다고도 생각하고, 실제 본격 개발 단계로 들어가지 못해서 위 방법에 대해 전체 프로세스에 걸친 경험이 없다. 하지만 사용자 중심으로 사고하고, 방향을 잊지 않도록 하는 접근방식은 의미있고 배울만하다고 생각한다.
사용자 중심으로, 길을 잃지 않고 많은 사람들이 즐거움을 느끼는 서비스를 제대로 만들었노라고 내 부고 한켠에 적히길 바란다. 😉

구글의 Snippets, 업무관리 이메일 시스템

나의 업무 일정을 자신이 직접 관리하면서도, 다른 사람들의 업무까지 한 눈에 볼 수 있는 구글의 Snippets 를 사용하여 생산성을 높여보자 🙂

Snippets

Snippets 소개를 대신하는, 작년 말에 팀장님 (@xguru) 으로부터 받은 메일이다.

기술전략팀,

구글 사내에 운영하는 Snippets 라는 이메일 시스템에 대한 이야기 입니다.
http://blog.idonethis.com/post/16736314554/silicon-valleys-productivity-secret

매주 금요일이 되면, 직원들에게 메일이 한통 날아가는데,
이거에다가 지난주에 한일과, 다음주에 할일들을 적어서 회신을 보내면,
그게 자동으로 취합되어서, 월요일 아침에 이메일로 받고,
공개된 웹사이트에 게재되어 사내에 공개됩니다.
이걸 누가 파이썬 + 구글앱엔진으로 공개한게 있네요.
https://github.com/kushal/snippets

Volunteership 과 잉여를 늘 강조하셔서 역시나 누가 해보란 말이 없다. 😉
흥미를 느낀 나는 GAE 를 처음으로 만져보며 Snippets 를 올렸다. 그리고 팀에서 세달간 운영하며 사용해볼 수 있었다. 아래는 매주 금요일에 오도록 설정한 리마인더 메일과 웹사이트에 보이는 화면이다. 회사 업무 관련이라 내용은 삭제했다.

Snippets Reminder

Snippets Public Site

사용법은 매우 간단하다. Snippets 에 가입하고 팀명을 태그로 넣는다. 그리고 원하는 사람이나 태그를 follow 한다. 메일이 오면 자신의 업무내역을 적어 회신하면 된다. 그러면 그 내용이 웹사이트에 보이고, 내가 follow 한 사람들의 업무내역은 월요일에 다이제스트 메일로 수신하게 된다.

사용해보며 내가 느낀 키워드는 자기관리, 그리고 시간절약이었다.

내가 직접 작성한 한일과 할일의 pair 가 웹사이트에 계속 쌓이기 때문에, 미처 못한 것이나 계속 미뤄지는 것이 눈에 쏙 들어왔다. 사실 이것은 곧잘 있는 일인데도 불구하고, ‘내가 작성했는데 내가 못했다!’ 라는 것이 굉장히 신경쓰였다. 따라서 일의 우선순위와 분배도 보다 신경쓰게 되고, 너무 타이트하거나 너무 느슨하지 않게 업무를 조율해야 했다. 그리고 적었으니깐 꼭 해내려는 의지가 더 생기고 말이다. 동기부여가 더 된 것이다.
또 좋았던 점은 시간을 절약하는 업무 공유 방식이었다. 우리팀 같은 경우는 하나의 프로젝트만 하는 것이 아니었고 각자 담당이 달랐다. 그러니 매번 주간회의를 통해 시간을 맞추고 한명씩 돌아가며 Synchronous 하게 듣는 것은 그다지 좋은 방식이 아니었다. (물론 필요할 때는 모여 짧은 회의를 하였다.) Snippets 를 통해 다른 사람의 업무내역을 다이제스트 메일로 받기 때문에, 그저 다른 메일 확인하듯이 ‘내가 가능할 때’ 메일을 열어 업무를 공유받았다. 이것은 효율적이고도 시간절약 하는데 도움이 되었다고 생각한다.

Snippets 운영하기

직접 구현해도 좋겠지만, 나는 공개된 것 ( https://github.com/kushal/snippets ) 을 조금 수정하여 사용하였다.
Python 으로 개발되었고, GAE 에 올라가기 때문에 Google App Engine SDK for Python 이 필요하다. 이것을 설치하면 GAE Launcher 와 커맨드라인툴 모두 설치된다. 난 이전에 GAE 경험이 없었는데, 초보임에도 매우 쉬웠고 또한 사용해볼 구실이 생겨 기뻤다.

  1. 먼저 프로젝트 코드를 받는다. 나는 fork 해 따로 사용하긴 했다.
    $ git clone git://github.com/kushal/snippets.git
  2. GAE My Applications 에서 새 앱을 생성한다.
  3. 소스를 생성한 이름에 맞게 수정한다. app.yaml 과 emails.py 를 수정하면 된다.
  4. GAE Launcher 또는 커맨드로 배포한다.

그러면 웹 – {앱명}.appspot.com 과 메일 – snippets@{앱명}.appspotmail.com 을 통해 Snippets 를 바로 사용할 수 있다.

완전히 그대로 쓸 수는 없어서 조금 수정했던 부분은 아래와 같다.

  • 타임존을 KST로 변경
  • 가입 계정이 소문자로 들어가도록 변경. 왜냐하면 구글계정을 읽어올 때 대문자가 섞여 가입되는 바람에 메일 발송시 계정 체크하면서 누락되는 문제가 있었다.
  • 서명, 답변 패턴 추가. 사용자가 보통 업무내역을 회신으로 보내기 때문에 불필요한 서명이나 답변은 trim하여 Datastore에 입력하게 되어있다. 그래서 우리팀에 맞게 패턴을 조금 수정했다.
  • 리마인더/다이제스트 메일 발송 시각 변경

수정내역은 https://github.com/curioe/snippets 에 있다.

이 프로젝트는 GAE 에 올라가기 때문에 인증방식이 구글계정, 구글앱스도메인으로 제한되는 것이 단점이었다. 그래서 임의로 Datastore 에 저장된 가입계정을 회사 메일로 바꿔놓는 작업을 하기도 했지만, 가입할 때 Snippets 메일에 대한 form 을 따로 구성하는 것도 한 방법인 것 같다. 아니면 GAE 가 아닌 곳에 새로 구현하거나. 😉

정리

실리콘밸리의 생산성 비밀이란 제목의 위 블로그 글에서는, 어느 산업에서든지 사람간의 협력을 필요로 하므로 사람관리가 핵심 문제인데 실리콘밸리는 단순히 ‘사람을 관리’ 하는 데서 그 해결책을 찾지 않는다고 말한다. Scalable 한 관리 모델을 만들고, Snippets 와 같은 프로세스로 투명하고 자율적으로 해결한다고 얘기하고 있다. Snippets 는 중간관리자 없이 투명하게 엔지니어 개인이 스스로 관리할 수 있게 돕는다. 게다가 평소에 사용하는 이메일을 그대로 활용하면 되므로 실용적이고, 동시에 비동기적으로 업무 공유가 되므로 업무 중단을 되도록 줄여준다. 업무 중심이 된다는 것은 모든 불필요한 요소를 제거하기 위해 어떻게 프로세스를 형식화하는지에 집중하는 것을 의미한다. 구글의 Snippets 만이 아니라, 페이스북의 Colbert 도 있고, Zynga, Palantir, Square 에서도 이와 비슷한 프로세스를 갖고 있다고 한다.

내가 예전에 일했던 회사 중 한 곳은 사람관리의 일환으로 출퇴근 시간과 매일 한 일을 각각의 시스템에 입력하도록 했었다. 나와 동료들은 습관처럼 시스템에 로그인하여 어제의 일을 복사해 붙여넣곤 했다. 그리고 잘 모르는 사람과 앉아 긴긴 주간회의를 가진 적도 많았다.
그런데 /** 구조조정으로 */ 세달밖에 운영할 수 없었던 Snippets 를 난 이제 개인용으로 따로 올려 스스로 사용하고 있다. 위 블로그에서는 ‘의미있는 목표를 향한 진행은 경제적인 것이나 위로부터의 압박보다 더 큰 동기부여를 준다’는 하버드 경영대학원의 연구결과를 전하는데 내가 그 증인이 되어버렸다. 😉 Snippets 를 혼자 사용해서 아쉽긴 하지만, 주 단위 계획과 실행 관리에는 그만인 것 같다. 실리콘밸리에서의 이직이 자유로운 이유가 반우스개로 오픈소스에 있다는데 Snippets 도 어느 면에서는 마찬가지인 것 같다. 내 메일에 내가 한 일이 다 남아있으니 말이다. 🙂