카테고리 보관물: Uncategorized

스타트업 3년 사용기

스타트업에서 3년 동안 일하면서 경험하고 느낀 사용기이자 감상기이다.
GDG 8월 미트업에서 발표했었는데, 앞에 서기까지 참 용기가 나질 않았다. orz “써보니 좋더라” 하는 기술 소개나 “저처럼 삽질하지 마세요 ㅠ.ㅠ” 같은 개발팁 전달도 아니고, 모든 사람들이 속한 회사와 처한 상황이 다 다른데 한 스타트업의 3년 사용기라니! 회사가 아직 Exit 을 한 것도 아니며, 더 오래 일하신 분들까지 듣고 계셔서 좀 민망하기도 했다.
정작 나는 개발자로 큰 기업에서만 일해봤고 스타트업이 어떤 곳인지 아무것도 모르고 있었다. 그러다가 스타트업에 초기멤버로 합류하게 되었고, 아무것도 없을 때부터 시작해서 최근까지 회사가 성장하는 모습을 볼 수 있었다. 배운 것도 느낀 것도 많았기 때문에, 개인 이야기임에도 불구하고 이렇게 공유를 하면 관심있는 누군가에겐 딱 한 줄이라도 도움이 되지 않을까 싶었다.

배경정보: 개발자, 큰 기업만 다녔음, 첫 스타트업, 초기멤버로 조인, B2C 플랫폼 서비스, 다양한 직군, 월급나옴, 투자받음

아기 키우기  –  모든 아기는 다 다르다.

스타트업은 아기 키우는 것과 같다고 흔히 비유하곤 한다. 아기는 누군가 꼭 돌보아야 하고 여러 성장단계를 거치며 자라게 되는데, 스타트업도 많은 것들이 부족한 상태에서 멤버들이 서비스를 만들고 조직을 세팅하고 자금조달을 하고 여러 과정을 거치며 성장하게 된다. 그런데 모든 아기가 조금씩 다르듯이 스타트업도 모두 다르다. 어떤 비즈니스를 하느냐, 멤버 구성이 어떻게 되어있느냐, 초기 자본 사이즈는 얼마만큼이냐 등등 많은 것들이 다르다. 참고로 내가 다닌 스타트업 같은 경우는 B2C 플랫폼 서비스를 하였고, 런칭한 날부터 감사하게도 매출이 발생했고 꽤 빠른 속도로 성장하고 계속 크는 중이다.

대기업 vs 스타트업  – 안정감 vs 성취감 & 참여감

이전에 대기업만 세 곳을 다니며 느낀점은, 큰 기업은 이미 회사가 커지면서 많은 것들이 정비된 상태이기 때문에 대체로 조직이 단단하게 굳어있는 편이고, 프로세스가 잘 되어 있다는 것이다. 비즈니스 모델이 지속되고 확장되어 왔기 때문에 상대적으로 안정적이지만, 대신 직원으로서 회사 존립에 대한 위기감이나 예민감도 상대적으로 떨어지게 된다. “시키는대로 해야지” 라고 말하면서 의사 결정에 대한 납득 없이 일하는 경우도 있다.
하지만 초기 스타트업은 조직이 말랑말랑(?) 하다. 니팀내팀 없음 = 사람이 없다. 사람이 없어서 세팅 본인이 다 해야 한다. 기술 스타트업이 아니라면 개발직군이 주변에 별로 없어서, 어떻게 하면 좋을지 논의할 대상이 부족하고 심지어 외롭기까지 하다. ;_; 대신 거기서 오는 성취감은 정말 엄청나다. 그리고 의견을 내면 의사 결정에 어느정도 영향을 끼치게 되면서 ‘아 내가 정말 참여하고 있구나!’ 라는 느낌을 받게 된다.

위기감

큰 회사에서 위기 의식을 가지란 말을 들으면, 난 일개 멤버인데 임원들만의 리그 아닌가 하고, “그래~ 위기야 위기지만 잘리기야 하겠어” 라는 말도 서로 주고 받는다. (하지만 정말 구조조정 겪어봄 orz) 그런데 스타트업에서는 정말 쭈뼛쭈뼛하다. 특히나 B2C 라면 앱스토어와 결제시스템과 같이 큰 플랫폼들에 의존할 수 밖에 없는데 가끔 애매모호한 정책으로 앱 등록시 리젝 당하기도 하고, 스토어에서 앱이 사라지기도 한다. 한번은 회사에서 구글플레이스토어에 등록된 앱이 내려간 적이 있었는데, 그 날이 안드로이드 개발자분이 회사에 처음 오신 날이었다. 안드로이드 앱 개발하려고, 이전 회사 퇴직하고 눈누난나 왔는데 앱이 없어졌다! … 각종 정책이라고 쓰고 규제라고 읽는 룰들도 많고, 구성원들이 며칠 머리 맞대고 고민하며 애써서 만든 기능이 오픈되고서 이틀 뒤면 다른 사이트가 똑같이 베끼기도 한다. 경쟁사 중에서 독보적이면 참 좋겠지만, 리소스와 자본이 상대적으로 빵빵한 다른 큰 회사의 한 팀과 생존을 두고 경쟁하게 될 수도 있다.

사용자 증가 > 운영업무 증가 > 가능한 한 자동화

사용자가 늘어나면서 서비스가 잘되거나 비즈니스가 잘되는 것을 보여주는 지표들을 보면 정말 기쁘다. 하지만 한쪽에 집중하느라 미뤄둔 것들에서 주로 운영업무가 발생한다. 내부 툴일 수도 있고, 상대적으로 잘 보여지지는 않는 부분에서, 필요하긴 하지만 당장은 아닌 것들에서 수동으로 업무를 처리하게 된다. 어떨 땐 신규 기능 개발보다 단순 운영업무 처리 비중이 높아지기도 한다. 반성의 얘기이기도 한데, 익숙해진다는 것은 처리가 빨라졌단 뜻으로 좋기도 하지만 대신 개선할 것을 미루게 되기 때문에 주의가 필요하다. 우선순위가 자꾸 밀려오다가, 막상 할 수 있을 여력이 되었을 때는 ‘음 뭘 고쳐야 하지?’ 또는 ‘그냥 쓰지 뭐..’ 하는 마음이 들기도 해서, 좀 더 효율적으로 일하려는 개선 의지도 중요한 거 같다. 개발에서의 운영 업무만이 아니라 회사 내에 모든 운영 업무가 해당된다고 생각한다.

문제들이 드러남  – 모두가 문제를 인식하고 나누는 것이 중요

업무가 항상 매끄럽게 되면 얼마나 좋겠냐마는, 모든 일이 다 계획한대로 되지 않으며 계획조차 우당탕탕 할 때가 많다. 서비스는 라이브 중이니 바로 처리해야 할 이슈도 많고, 부족했던 것들이 잔뜩 보이고, 모든 일의 우선순위가 다 높은 것만 같다. 특히나 초기에는 정해진 프로세스도 없고, 모여서 여기서 얘기하면 저기서 처리하거나, 들어오는 CS 답변을 나눠서 하고, SNS 를 통해서 홍보도 나눠서 한다.
그런데 난 이런것이 초기에는 자연스럽다고 생각한다. 이전에도 같이 했었던 사람들끼리 이전과 비슷한 서비스를 비슷한 방식으로 만든다면야 이런 일이 덜하겠지만, 이 세 조건이 합쳐져서 소위 세련되게 일하는 스타트업이 얼마나 될까? 다만 여러가지 발생하는 문제들을 함께 인식하고 나누는 것이 중요한 것 같다. ‘이것은 너의 문제, 나는 무엇 담당이니 이것만 할 것이다.’ 라는 태도는 서로에게 도움이 되지 않는다. 이런 작은 것들로 팀웍이 다져지기도 한다. 부족한 프로세스를 잡아가고, 구멍난 자리에 사람을 뽑거나 해서 근본적으로 해결해가는 것도 물론 중요하다.
또한 일을 잘 하고 있을 땐 아무도 신경 안쓰다가 문제가 튀어 나와야지만 모든 시선이 그곳에 가고 그 자리와 책임이 더 크게 보이기도 한다. 평소에 각 자리에서 본인이 얼만큼 많은 것을 하고 있는지, 또 어떻게 잘 일하고 있는지, 일정이나 사람이 얼만큼 부족하다는 표현을 하는 것이 필요하다. 특히나 개발자나 여러 실무자들이 챙겨야 할 이슈라고 생각한다.

손 부족  –  적절한 사람을 적절한 타이밍에

회사와 서비스가 커지고 복잡해지면서 일손이 점점 부족해진다. 하지만 사람들이 더 들어온다고 해서 내 일이 줄어들지는 않는다. 커뮤니케이션 코스트가 더 늘어날 수도 있고, 일을 처리하거나 해치우는 사람 뿐 아니라 회사를 더 키울 비즈니스 과제를 물고 들어오는 분들도 있기 때문이다. 정말 많이 커져야 일이 좀 줄어드는 것 같다. 그리고 어떤 자리에 지금 당장 사람이 필요한데 그제서야 사람을 뽑으려고 하면 시간이 많이 소요되고, 그렇다고 너무 앞을 내다보면 맞지 않는 일에 사람을 뽑을 수도 있다. 적절한 시기에 적절한 사람을 뽑는게 중요하고 스타트업일수록 리더가 잘 해야 하는 것이라고 생각한다. 그리고 사람이 들어오면 빠르게 점프인해서 업무 성과를 내주길 바라면서 그만한 프로세스는 갖춰있지 않아, 결국 알아서 해주길 기대하는 모습이 될 때가 있다. 이 부분이 서로에게 어려운 부분 같다.

프로세스 정비 / 조직화  –  회사마다 모두 다 다르다

회사가 커지면서 같이 움직이는지, 같은 생각을 하고 있는지 확인하는 것이 필요하다. 그렇기 때문에 프로세스와 조직을 잘 정비해가는 것은 필수과정이라고 생각한다. 이 과정에서 특히 성장통이 있을 수 있다. 그런데 정비 자체에 집중하는 것이 아니라, 어떻게 효율적으로 일할 것인지, 어떻게 일하는 사람을 편하게 할 것인지의 본질에 집중해야 하는 것이 맞다. 그래야 구성원들의 공감을 더 얻을 수 있고, 프로세스를 지속적으로 개선해갈 수 있다.
그리고 모든 회사가 성격이 다 다르듯이 프로세스도 조금씩 다를 수 밖에 없다. 저 회사에서 성공적인 것이 이 회사에서는 안맞을 수도 있다. 조직에 맞게 최적의 것을 찾아가는 과정이 필요하다고 생각한다.

문화  – 시작이자 끝

이런 저런 얘기를 하고 있지만 가장 기반이 되는 것은 문화라고 생각한다. 작은 회사는 기업문화가 시작이자 끝이다! 왜냐하면 문화가 일하는 방식이나 구성원들의 행복감에 미치는 영향이 크기 때문이다. 어떻게 하기로 하자는 규칙이나 정책 같은 것들이 모든 것을 커버할 수는 없다. 문화는 구성원들 모두가 만들어 가는거지만 리더의 의지가 한 몫 하는 것 같다.

번아웃  –  공감과 격려가 필요해요

스타트업에서 정말 빠져서 일하다가 보면 번아웃이 오기도 한다. 이 늪에서 나오기 위해서는 역시 동료나 멘토의 파워가 중요한 것 같다. 고민을 함께 나누는 공감 상대, 또 “잘하고 있어, 누구라도 힘들꺼야, 난 너를 믿어” 라고 신뢰를 보내주며 격려해주는 대화상대가 큰 도움이 된다. 나를 격려해줄 사람을 찾는 것만 아니라 누군가에게 내가 힘이 되줄 수 있는 사람이라는 것도 잊지 말아야겠다~ 번아웃에는 안빠지는 것이 더 좋을텐데, 그러기 위해서는 중간중간 작은 성취감을 느끼는 것이나, 어떤 형태로든 인정받아야 하는 것 같다. 사실 어려운 문제이고 정답은 잘 모르겠다. @@

기술 부채  – 그때는 맞고 지금은 틀리다

3년 전에 처음 서비스를 개발하면서 상황상 일정이 한달반 정도 밖에 없었다. 인프라를 관리하거나 모니터링 시스템을 개발할 여력도 부족했던 상황에서 백엔드로 구글앱엔진을 선택했다. 그리고 하이브리드앱으로 개발했는데 이것이 스타트업 사례가 되면서 다른 스타트업에서 따라하는 경우가 있었다. 정작 회사 서비스와 요구사항은 점점 복잡해지면서 네이티브 앱으로 바꾼지 오래되었고, 백엔드도 좀 더 복잡한 기술 스택으로 확장하고 있다. 처음엔 사용자와 트래픽이 얼만큼 늘어날지 몰랐고, 혼자서 기능 개발하는 것만도 시간이 많이 걸렸다. 하지만 이후에 개발자들이 더 합류했고 요구사항이 더 복잡해졌기 때문에, 그때는 앱엔진을 선택한게 잘한 것이고 지금은 점점 의존도를 줄여나가는 것이 잘한 선택이라고 생각한다. 서비스 오픈, 1년, 2년, 3년 지났을 때의 서비스의 상황과 기술은 다 다를 수 밖에 없다.
각 과정에서 이렇게 쓰는 기술들이 ‘아 넘 급하니 이렇게 해두자’ 고 처음부터 부채로 인식하고 선택되는 경우도 있고, 그때는 최고의 선택이었으나 지나고보니 서비스가 복잡해지면서 부채가 되는 경우도 있다. 결국 ‘기술’ 부채이기 때문에 개발자가 일해서 갚아야 하지만, 비즈니스의 일정상 그리고 그때 가지고 있는 리소스 상 최선의 선택을 했던 것이기 때문에, 기술부채는 개발자나 개발팀의 부채가 아니라 회사가 함께 갚아가야 하는 것이라는 인식이 필요하다. 과거에 잘 빌려 썼기 때문에 여러 스타트업들이 서비스를 적절한 시기에 딜리버리한 것이라고 믿는다. 물론 빚덩이가 불어나기 전에 조금씩 잘 갚아나가는 것도 중요하다~

스타트업 중독

돌이켜보면 참 고생스러웠다. 미친듯한 일정을 맞춰야 하는데 이미 잠은 몇주째 제대로 못자서 눈물을 흘리며 키보드를 친 적도 있다. ㅠ.ㅠ 그럼에도 스타트업에서 일하는 것이 큰 경험이었고 많이 배웠다. 실리콘밸리에서는 부트스트랩 하고나서, 지분이나 스톡옵션 기간만 채운 후에 계속 이직하는 사람이 많다고 들었다. 조직 세팅하고 크는 것이 재밌기 때문이라고.
그래서 중독이란 표현을 썼는데, 변화가 빠르고 주도적으로 할 수 있는 스타트업이 정말 힘들어도 즐거워서 다음에도 또 이 길로 가지 않을까 싶다~!

슬라이드 쉐어: http://www.slideshare.net/curioe_/3-65668400

광고

후기: Women Techmakers in Seoul 티타임 – 2015년 3월

왜죠?
왜 여자개발자들끼리만 모여야 하나요?

굳이 말하자면 괜히 부끄럽지만 그동안 여성개발자들끼리만 모이는 국내 오프모임에 나간 기억이 없다. ㅠ.ㅠ
그렇다고 여러 다른 개발자 모임에 잘 나가는 것도 아니지만(…), 필요하거나 듣고 싶은 개발자 컨퍼런스, 세미나 등이 딱히 성별을 가리지 않으니깐.
이유를 못 찾았었기 때문이다.
나마저 ‘왜죠?’ …오잉도잉

그런데 그러던 내가 며칠 전 여러 사람의 도움을 빌려, Women Techmakers (WTM) 라는 타이틀로 여성개발자들끼리 모이는 티타임을 가졌다.
운영진으로 소속되어 있는 GDG Seoul 커뮤니티 내의 소모임 형태로 진행했다.
즉 직접 주최하고 직접 쓰는 후기 겸 잡담 호*-_-*호 (aka. 후기가 하나도 없어서 ㅠ)

아니 그래서 왜죠?
왜 이 모임을 가졌는지 티타임 행사 진행 전부터 돌아가보면~~
사실 정말 얼마 안되었다. 한달 전에 문득 다른 분들이 어떻게 지내는지 궁금해졌다.
큰 회사에 있을 때는 그래도 여성 개발자분들이 주변에 계셔서 오며가며 보았는데 지금 회사에서는 두 명 뿐이라 어떻게 일하는지 궁금하기도 하고..
‘여성 개발자들끼리 소규모로 모여서 두런두런 얘기하면 재미있지 않을까?’ 라는 생각이 들었다.
그런데 그 뒤에 계속 따라오는 질문이 굳이 우리끼리 모여서 뭘 하지? 였다. 다른 분들도 이렇게 모이고 싶어할까? 그리고 온다면 무슨 얘길 나누고 싶어할까? 원하는 게 뭘까?
이래저래 생각하다보니 아고 나 정말 다른 여성 개발자분들 모르는구나 싶었다.
그래서 처음에는 “궁금한 상태”라는 이유 그대로, 만나서 얘기해보자라고 티타임을 진행하기로 하였다.

그러던 중 블로그 글 하나를 읽게 되었다.
“Coding Like a Girl” ( 번역: 소녀처럼 코딩하기 )

간단히 요약해보면, 여성 개발자로 일하면서 겪은 일들을 (// 정말 공감가는 일들을) 주욱 이야기 한다.
여성스럽게 입었더니 개발자로 안보더라는 이야기. 너 디자이너 같아, 회계사 같아.
( 나도 종종 겪은 일인데, 이 말을 들으면 ‘아 오늘은 예쁘게 입었다는 뜻이구나?’ 라고 생각이 들면서 기분이 좋다가도 음? 하면서 알쏭달쏭한 기분이 든다. 나도 여잔데 여자 개발자처럼 입으려면 어떻게 입어야하지ㅠ.ㅠ? 개발 못한다는 이야기인가? #아냐 #맞아 가로줄무늬 입으면 되는가봉가? )
또는 컨퍼런스에서 발표를 할 때 드레스를 입었을 때보다 청바지를 입었을 때 더 제대로 된 질문을 받을 수 있었다라던가, 슬라이드 자체 내용보다는 너무 분홍색을 많이 썼어 혹은 말투를 그렇게 하지 말라는 피드백들이 들어왔다고 말한다. 그 외 등등..
이 글에서는 그렇게 말하는 사람들에게는 그러지 말라고 얘기하면서 한편, 여성들에게는 원하는대로 입고 그 자리에 있으라고 얘기한다. 여성스럽게, 화려하게, 팬시하게… 있고 싶은대로 있으라고. 게이머로서, 프로그래머로서, 그리고 게임디자이너로 있으면서 말이다.
이게 개발자가 어떤 모습이어야 하는지에 대한 사람들에 대한 생각을 바꾼다고 전한다. 여자 개발자에 대한 인식을 바꾸기 위해서 우리가 여자 개발자다우면 된다고 말한다.

실제로 작년에 갔던 모컨퍼런스에서 있었던 일인데, 미모의 여성분이 자신의 프로젝트를 설명하면서 기술과 경험에 대한 공유를 하는데 질문이 “직접 개발하신거에요?” 였다. orz
아직은 이쪽에 여성들이 너무 없어서 생기는 일인 것 같다.
그래.. 점점 많아지면 괜찮지 않을까?
기술 분야에 여성들이 있는 것이 자연스러워지면 좋겠다.
여성 개발자들끼리 그때까지 이렇게 모이면 좋지 않을까?
나 개인적으로는 그렇게 여성 개발자들이 모이는 티타임에 의미를 부여했고, GDG Seoul 운영자분들과 회사 CTO님의 응원과 구글코리아의 후원, 그리고 다른 여성 IT업계분들의 도움으로 모임이 만들어졌다.

하지만 무슨 대단한 모임 아니고 그냥 티타임. ㅠ.ㅠ (일년만에 글 쓰다보니 소심 ㅠ.ㅠ)
하지만 정말 즐거웠어서 계속 쓰자. (엉엉 이 글은 망했어)

행사 소개
타이틀은 Women Techmakers in Seoul 티타임
때는 2015년 3월 19일 목요일 저녁
장소는 마이크임팩트 스튜디오 살롱
구글코리아의 후한 후원으로 분위기 좋은 까페에서 모임을 가질 수 있었다.

신청받기
구글 Docs 로 신청을 받았다. 서른 분 정도 모시고 얘기 나누려고 했는데 첫 날 예상인원을 넘겼다. 1년 정도 커뮤니티 내 불특정 다수를 대상으로 한 무료 정기모임을 진행 하다보니 신청자의 70% 정도가 참석하면 굉장히 좋은 참석률이란 것을 알았다. 그렇게 참석자는 25여명 정도 되었다.
기억에 남는 것은 성별을 확인하는 폼이 있었는데 남성분의 입력이 딱 하나 있었다. 팀원을 보낸다며 잘 챙겨달라는 한 팀장님의 메시지였다. 🙂


순서
Google 권순선님의 킥오프 멘션을 시작으로 다음 순서로 진행되었다.

1. 오프닝: 모임 소개/취지
2. 여성 개발자가 모여야 하는 이유 (이해민님, Google Product Manager)
3. 티타임
4. 라이트닝 토크

WTM?
Women Techmakers (WTM) 은 기술 분야의 여성들을 위한 Google 의 글로벌 프로그램이자 브랜드이다. 다양한 사람들로부터 나오는 다양한 관점들이 더 나은 결정을 내리거나 더 나은 상품들을 만들 수 있다고 믿는데, Tech 분야에는 여성 수가 남성의 수에 비해 월등히 적다. 그래서 Google 에서는 Diversity 지원 프로그램이나 환경들을 만들면서 나아질 수 있다고 생각하고, 기술 분야의 여성들을 위한 커뮤니티나 필요한 리소스들을 지원하고 있다. 최근에는 Code School 과 파트너십으로 3개월 바우처도 지원했다. WTM 은 기술 분야 여성들의 인식을 제고시키고, 다른 사람들로 하여금 이 분야에 들어오게 영향을 주는 것에 목적을 두고 있다.
권순선님의 WTM에 대한 설명과 함께 서로서로 구실을 만들어서 적극적으로 자주 모이라는 권유는 정말 좋았다. 🙂
이후에 위에 내가 정리한 것처럼 티타임을 갖게 된 이유를 아주 조리없게 설명하고(??) 이해민님의 강연을 들었다.

함께 감상한 “Like a girl” 영상

여성 개발자가 모여야 하는 이유
이해민님의 여성개발자가 모여야 하는 이유에 대한 강연은 정말 와닿았다. 작년에는 WTM 모임을 200여명 정도 규모로 하면서 나누고 싶은 이야기들을 폼으로 받았었는데 회자되었던 것 중 하나가 육아 고민이었다고 하셨다. 그런데 일년이 지난 우리는 아직도 같은 고민을 하고 있다고 말이다. 육아로 휴직 후에 복직을 하였을 때, 나는 능력이 이~만큼인데 그보다 못한 일을 받을 것 같다는 고민들과 함께.. 내년이면 달라질까? 이번 모임에 육아를 하시는 개발자분들은 한두분밖에 안계셨지만, 미혼의 여성 개발자들도 다들 한번씩은 하는 고민일꺼다. 이 문제를 우리는 해결할 수 있을까? 이것은 여성만이 해야하는 고민이 아니다. 남성들도, 사회도 함께 고민해야 하는 사회 전반의 문제이고 톱니바퀴 돌아가듯이 함께 개선이 되어가야 한다는 얘기를 하셨다.
그러면 우린 왜 모여야할까?
함께 공감할 사람이 필요하기 때문이라고. (끄덕끄덕)
내가 정리한 포인트는 그렇다. 🙂 적지만 그만큼 서로 얘기를 들어주고 함께 가야한다고.
더불어 후학이란 단어를 언급하시면서 본인을 롤모델로 삼는 사람을 5명 만들라고 권고하셨는데.. ㅠ.ㅠ 뜻은 깊은데 굉장히 어려운 과제인 것 같다. 단 한명이라도 누군가에게 크고도 좋은 영향을 끼친다는 것은 어렵기 때문에..
그럴 정도로 각자의 목표를 세우고 바르게 걸어가라는 말로 이-_-해;

티타임
그리고 그룹을 둘로 나누어 한시간 정도 티타임을 가졌다.
이름 / 하고 있는 일(파트,언어) / 출몰지 / 요즘 가장 시간을 들이는 일 / 하고 싶지만 시간이 없어서 못하는 일 / 하고 싶은 말
종이에 각자 내용을 적고, 돌아가며 얘기한 후에 자유 주제로 이야기를 했다.
하고 있는 일 얘기 나누는데 어찌나 찌릿찌릿하던지… GDG Meetup 후 네트워크로 뒷풀이를 할때면 어떤 일 하냐고 얘기 나누는 게 거의 남성분들이었기 때문에 그런지, 이 시간 여성 개발자분들이 다양한 분야에서 자기가 맡은 일을 얘기할 때 혼자만의 감동이 있었다.
자유 주제가 걱정이 되어서 분위기메이커 개발자도 섭외하고 나름 노력이 있었는데 마지막엔 시간이 모자랄 정도였다. 회사에서 즐거운 점이나 어려운 점에 대한 얘기나, 참여하는 다른 커뮤니티 소개, 항상 일하는 상태여야 하니 개발환경이나 인프라가 중요하다는 좋은 얘기들까지~ 다양한 이야기들이 오갔다. 만나보고 싶었단 얘기가 가장 많았다.
얘기에 폭 빠져서 다음 진행을 못할 뻔 했다.

라이트닝 토크
시간이 모자라서 한 분밖에 얘기를 못했는데 PyLadies Seoul 소개였다. 그리고 여성개발자가 모여야 하는 이유에 대한 답을 이렇게 내렸다며 얘기해주셨다.
“여자들끼리 모이면 어때서~ ;-)”
웃음이 나오면서도 공감이 갔다.

앞으로

앞으로 우린 어떤 모습으로 만날까 고민하는 것을 공유했었는데, 이렇게 티타임도 좋고, 스터디를 하고 싶단 얘기가 많았다. 그리고 한 개발자분께 재밌고 유익하게 들었던 주제가 있었는데 부탁드렸더니 해주신다 해서 조만간 또 한번 모일 것 같다. 🙂

주변에서도 여성 개발자들이 얼마 없다보니 어떻게 대해야 할지 모르겠다는 얘길 많이 해주신다.
아직은 작지만, 이렇게 모이다보면 개발자 되고 싶단 여성분들이 많아지거나 그만두는 분들이 적어지면서 사람들도 늘어나지 않을까? 또한 다양한 활동들로, 단순히 숫자만이 아니라, 우리의 지식과 경험도 높이면서 여성 개발자들에 대한 인식이 서로 간에 자연스러워지면 좋겠다.

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

프리미엄 웹툰 서비스, 레진코믹스는 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 도 어느 면에서는 마찬가지인 것 같다. 내 메일에 내가 한 일이 다 남아있으니 말이다. 🙂